团队项目用户验收评审——《WAP团队》

团队项目用户验收评审——《WAP团队》

1、验收准备的相关文档链接:

2、验收意见的验收意见表链接:

3、关于源代码管理的10 个问题

(1) 你的团队的源代码控制在哪里?用的是什么系统?如何处理文件的锁定问题?

我们的项目在github上托管,采用git的方式进行版本控制,这个是我们在开发伊始就达成的共识,针对这种多人多任务的开发模式,我们认为git是再好不过的选择,于是我们从开发到现在一直采用这种方式
我们团队的在处理文件的锁定问题上是不加锁的,也就是说我们的成员可以自由迁入迁出。由于现阶段的开发规模比较小,于是为了最大化效率,我们没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁,显然可以保证源代码修改的同步性,减少不必要的冲突和错误,但是这样的缺点是显而易见的,由于缺乏了并行性,项目开发的效率就被极大地降低了,极端情况下很有可能因为一个人的失误,导致全队项目的搁浅。反之,我们采用自由迁入迁出的方式,则与前者的优缺点互反了。的方式,则与前者的优缺点互反了。

(2) 如何看到这个文件和之前版本的差异? 如何看到代码修改和工作项 (work item),缺陷修复 (bug fix) 的关系

github进行更新后,可以看到本地的版本和最新的版本之间的不同之处。 同时,在本地上传自己的文件到分支之后也可以查看自己或者是别人上传的文件在以前的版本的基础上,修改了哪些地方。 点开项目的commit的记录,点击相应的SHA版本哈希值之后可以进入到如下的页面 我们在上面图片里面可以看到的是”+”标注的是在原文件的基础上增加的代码的记录,”-“标注的是在原文件的基础上删掉的代码的部分,颜色显示也不同。 其实我们团队是以任务为单位和模块进行的开发,这种开发模式在任务分配之处就已经给该任务提供了描述。 之后在完成任务push之前还要在commit时加上任务完成情况的描述,方便我们在以后通过git log指令产看相应的git的记录。这样的双向映射的机制保证了我们每一次提交的版本目的明确,特征鲜明。

  (3) 如果某个文件在你签出之后已经被别人修改,并且签入了,那么你在签入你的修改的时候, 如何合并不同的修改(merge)? 你用了什么工具来帮助你?

在git中执行合并即可自动合并Git修改的部分。但是,也存在无法自动合并的情况。如果在远程数据库和本地数据库的同一个地方都发生了修改的情况下,因为无法自动判断要选用哪一个修改,所以就会发生冲突。另外,git会显示本地数据库和远程数据库同一个地方的不同修改,这时候就需要我们手动解决冲突,暂时没有想到什么好的工具可以解决不借助人力自动解决这个问题,只能依据规定和协商解决这一问题。

(4) 你有20个文件都是关于同一个功能的修改,你要如何保证这些文件都同时签入成功(修改的原子性),或者同时签入不成功?

git作为一个成熟的源代码版本管理系统本身就可以保证在签入时的原子性,所以在我们的项目开发流程中没有遇到部分修改可以上传而某些部分的修改不能上传的混乱状态。

(5)你的PC 上有关于三个功能的修改, 但是都没有完成,有很多文件处于半完工的状态,这时你要紧急修改一个新的 bug,如何把本地修改放一边,保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。

 

(6)规范操作和自动化

(7)如何给你的源代码建立分支?

(8) 一个源文件,如何知道它的每一行都是什么时候签入的,为了什么目的签入的 (解决了哪个任务,或者哪个bug)?

(9) 如何给一个系统的所有源文件都打上标签,这样别人可以同步所有有这个标签的文件版本?

一般来说我们会有两个版本的‘Last Known Good’,一个是刚写完的源代码,另一个是经过运行测试之后的调整源代码。我们会采取后面这种版本,因为一般来说这是较优的那种。然后在上传到github上,根据commit记录大家就可以同步这个版本。

(10)你的项目的源代码和测试这些代码的单元测试,以及其他测试脚本都是放在一起的么? 修改源代码会确保相应的测试也更新么?你的团队是否能部署自动构建的任务?

我们没有选择自动测试,也没有在Git上支持自动测试,测试都是自行手动测试,保证编译和运行正常。

4、验收过程

      本次验收主要是采用团队互评的方式,两个团队根据各自准备好的相关的验收资料分别对各个小组的开发的系统进行验收。每个组分工好角色,在验收场景,通过甲方、乙方的方式进行验收,记录人员记录验收的情况,最后总结。

5、实施过程场景照片

6、团队成员的具体分工、占整个实验任务的工作量比例及完成各自任务的实际时间

小组成员 具体分工 占整个实验任务的工作量比例 实际时间
马宏伟 后台、前端完善,系统演示 19% 7h
周欣 前端完善,博客撰写,资料整合,项目主持 20%
8h

乌勒扎 PPT制作、系统演示前准备 17% 6h
杜有海 过程文档 14% 3h
马麒 实施文档 15% 3h
郝明宇 验收过程相应资产填写及校队 15% 3h

7、各成员项目总结

    (1)周欣:每一次都认真对待,认真去做,无论结果如何,好与坏,依然努力。对于本次项目,虽然不是主要负责人,但是对于每一次作业实验,我确实兢兢业业地去完成。但是,每一次结果却都不理想,有可能别人觉得没有什么,但是对于付出了辛劳和努力的同学无疑是一种打击,不但打击了我们完成作业的信心,更是打击了我们努力坚持的心。然而,最后,我想说虽然获得的成绩与付出不成正比,但是,也学到了方方面面很多知识,增益我所不能,如果再有这样的学习机会,一定会换一种方式去对待。另外,在这最后,谢谢老师的指导,对于项目的不足之处,我们会继续改进。

    (2)马宏伟:本次项目由团队成员进行开发,代码由我主导编写,最终程序完成了基本功能,界面和详细功能不够完善,主要是详细设计方面存在一些不足,以后会改进的。

    (3)乌勒扎:我们的系统是从教师和学生的双方利益出发而开发的。开发期间我们分工合作,发挥了各个队友间的特长,以达到最好的效益和质量,因为能力的限制,每个人负责的模块有大有小,但最重要的是大家的共同努力,大家都学到了很多东西,这个项目是对我们大三第二学期这半年来所学知识的一次总结和检测,我们认为只有通过这样的项目实训,对我们所学知识的一次全面检测,从而使我们认识到知识内容的不足和知识框架的缺陷之处,然后有的加以弥补知识。由于我们能力有限,做出来的和我们想象中的还差一点,我们会继续努力做的更好,也很感谢我们的老师和助教团队,为我们做了这么多,因为有了这次的团队经验,我觉得对我们以后工作学习上都会有很大的帮助,无论做出来的如何,我们每个人都学会了制作软件的过程。

    (4)杜有海:此次实验加深了对数据库基本原理和理论的理解,巩固了对系统分析与设计的应用,进一步提高我们综合运用所学知识的能力。同时也发现很多学过的东西没有理解到    位,不能灵活运用于实际,不能很好的用来解决问题。另外,在结对过程中,痛队员之间的不断磨合与努力,我们可以一步一步地改进我们的设计,提高我们的专业知识与能力等等。非常感谢拥有这样的机会去学习。

    (5)马麒:任务的顺利完成离不开老师的帮助和小组成员的共同努力,虽然我们小组只有几个人,但我们是一个有组织,有效率,有团队精神的小组。在任务的完成中有明确的分工,有共同的目标,让我深刻的体会到什么叫有效率的团队。为以后的学习和处理此类问题有了很好的前车之鉴。

(6)郝明宇:此次实验加深了对数据库基本原理和理论的理解,巩固了对系统分析与设计的应用,进一步提高我们综合运用所学知识的能力。同时也发现很多学过的东西没有理解到位,不能灵活运用于实际,不能很好的用来解决问题。队员们分工合作,彼此相互学习到很多。

8、项目组总结

       通过一学期的学习,七次团队协作。到目前,基本上完成了项目的开发,前期所预想的功能也实现了。虽然有不足的地方,但我们会继续改进,把系统完善,希望可以用于市场,起到应有的作用。虽然,前面的几次学习有些东西被否定了,我们小组成员也受到了很大的打击,付出了一个学期的努力,却换来那不如意的成绩。但是,最终,对于我们自己所做的东西,我们仍然会把它努力做好。另外,在这一学期的学习中也学到了很多知识,对于软件的开发不再是一张白纸,至少我们知道开发软件需要经过哪些过程,需要做哪些工作等等。还有,对于软件的测试需要怎么去做,有哪些测试的方法可以使用,用户和开发人员能对软件测试做什么工作,对软件的验收我们要做哪些相关的准备工作等等。总而言之,经过本次的学习,使我们受益匪浅,增益我们所不能。

原文地址:https://www.cnblogs.com/tdlr/p/9248689.html

时间: 2024-10-08 09:32:32

团队项目用户验收评审——《WAP团队》的相关文章

《A_Pancers》团队项目用户验收评审

团队项目用户验收评审 一.关于源代码管理的10 个问题: 1.你的团队的源代码控制在哪里?用的是什么系统?如何处理文件的锁定问题? 我们的项目都在github上面,用的win10系统,并且我们的文件没有锁定. 2.如何看到这个文件和之前版本的差异? 如何看到代码修改和工作项 (work item),缺陷修复 (bug fix) 的关系. git pull进行更新后,可以看到本地的版本和最新的版本之间的不同之处.同时,在本地上传自己的文件到分支之后也可以查看自己或者是别人上传的文件在以前的版本的基

《Blue_Flke》团队项目用户验收评审

一.关于源代码管理的10 个问题: 1.你的团队的源代码控制在哪里?用的是什么系统?如何处理文件的锁定问题? 答:团队项目在Github上托管,采用git的方式进行版本控制.使用win7系统,团队的在处理文件的锁定问题上是不加锁的. 2.如何看到这个文件和之前版本的差异? 如何看到代码修改和工作项 (work item),缺陷修复 (bug fix) 的关系? 答:点开项目的commit的记录,点击相应的SHA版本哈希值之后可以看到代码的修改内容. 3. 如果某个文件在你签出之后已经被别人修改,

软件工程团队项目第一次Sprint评审

第一组:9-652 作品:炸弹人 评价:已经完成了界面的设计和基本功能,游戏已初具雏形.这款游戏可玩性很强,是个很不错的项目.但是对游戏并没有进行深入开发,不能持续的吸引玩家的兴趣,容易引起玩家的厌倦感.应该适当的增加一些新颖的玩法,比如像炸弹的爆炸的范围,闯关的难度的设计,或者多人对战等等.总之,对于这款作品还是非常期待的. 第二组:hzsy 作品:图文转换 评价:这款作品的实用性非常强,很符合我们日常生活中的需要.但是在演示的过程中,我只看到了软件的页面,并没有看到软件实现了哪些具体的功能.

团队项目用户调查报告

用户需求调研报告 项目名称: “渴了么”手机订水app软件 项目编号 调研主题: 用户需求 访谈时间:2015.4.13 调研地点: 访谈部门: 参与人员: 檀威  陈志利   赵永恒  范德一 1. 访谈目的 通过本次访谈,我们要充分了解同学们对这个订水软件的具体的需求,比如界面样式,需要哪些功能,以及更加人性化的设计,从而使我们在整体上有个具体的把握,为我们以后的详细设计打下良好的基础. 2. 主要议题 1.访谈总体流程 首先找到一群目标用户的代表来讨论用户想要什么功能,对界面样式的要求,用

团队项目 用户及场景分析

典型用户模板: 用户1 姓名:楚子航 年龄:20 收入:无 比例:较小 典型场景:想要整理自己上课所记的笔记,或者对某些内容的想法 环境:宿舍,自习室 生活/工作情况:大学生,热爱学习,经常去自习 知识层次和能力:受教育程度高,对电脑极其熟悉 用户的动机.目的和困难:想要整理自己所学的知识,和别人交流学习内容,但是舍友并不喜欢学习 偏好:热爱学习 用户2 姓名:路明非 年龄:20 收入:无 比例:较高 典型场景:考试在即,但是没有复习,书上没有丝毫笔记,很慌 环境:宿舍,自习室 生活/工作情况:

团队项目-用户场景分析

1.帮你校园资讯平台的基本角色 (1)信息获得者 (2)信息发送者 (3)广告商 (4)管理员 (5)捣乱者 2.典型用户 名字 小雯 性别.年龄 女,20岁 职业 学生 收入 0元 知识层次和能力 本科大学在校生, 熟练使用手机 生活/工作情况 经常玩手机,无时无刻不在玩,同时喜欢丢三落四和八卦 动机,目的,困难 自己经常丢三落四,放假回家赶火车,经常快到火车站,忘记带身份证,还需要回去拿:因为自己有美貌,经常被舍友调侃表白墙的事情,自己却不知道. 用户偏好 八卦,丢三落四 用户比例 60%

A_Pancers团队作业4—基于原型的团队项目需求调研与分析

任务1:实施团队项目软件用户调研活动. (1)用户调研对象:我们的项目软件是基于安卓系统的音乐播放器,以设计出操作简单的音乐播放器为目的,所以本次用户调研的对象主要以身边的老人为主,对他们听音乐,听戏曲的情况进行了解,看他们对于音乐播放器有何需求,有何期待:并将我们设计出的项目模型对他们进行介绍,听取他们的意见和建议.另外考虑到为了获取更加全面的需求其他年龄阶段的人为辅助调研对象(例如:身边的同学.家长.朋友等). (2)调研方式:对于老人这个用户对象我们采取了面对面采访的方式进行调研,而对于其

第11组 团队项目-需求分析报告

组长博客:团队项目-需求分析报告 整体计划安排 截止时间 任务 11.01 前端和后端商议确定接口,UI完成首页,前后端完成项目构架搭建,确定模块并分配任务 11.15 完成前端主体部分,对接后端接口 11.18 测试,修改,改善性能,检查代码,发布Alpha版本 11.23 项目完善+用户使用反馈+测试计划改进 12.1 根据反馈和需求进行新版本的模块编写,发布Beta版本 12.4 正式版本完善+用户手册 团队分工 alpha 版本需要做哪些事情 完成预先规定的功能需求 分工明细 前端: 陈

团队项目的质量保障

质量是项目开发中及其重要的一点,只有高质量的软件产品才能让客户感到满意.团队设定质量保障使软件开发变得有条理,让项目能够按时.按质交付. 在质量保障中应先建立SQA小组,让SQA小组与软件工程师配合来保证软件质量. 在质量保障中,应有如下工作: (1)制定项目的SQA计划,SQA计划中包括对项目的审查方式,审查周期以及对项目制订标准.         (2)对项目进行技术复审.在每次阶段性的开发工作完成后,都要对项目进行审查,主要目的发现项目中的规格说明错误或设计错误,尽量在项目早期发现软件错误