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

Posted 2020-11-21 tdlr

团队项目用户验收评审——《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、项目组总结

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