<Dare To Dream>团队项目用户验收评审

实验十二 团队作业8—团队项目用户验收评审

任务1：团队作业Beta冲刺

• Beta冲刺第一天：http://www.cnblogs.com/Dare-To-Dream/p/9226994.html
  
• Beta冲刺第二天：http://www.cnblogs.com/Dare-To-Dream/p/9231421.html
  
• Beta冲刺第三天：http://www.cnblogs.com/Dare-To-Dream/p/9231455.html
  
• Beta冲刺第四天：https://www.cnblogs.com/Dare-To-Dream/p/9235895.html
  

任务2：关于源代码管理的10 个问题

1. 你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
    我们团队使用GitHub作为代码管理工具进行代码的管理。使用的win7系统。文件没有被锁定，所有团队内部人员都可以自由签出文件，每个人可根据自己的需要修改自己负责的模块。
2. 如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系？
　 进入github团队项目仓库，点开项目的提交记录，点击文件详情，便可看到这个文件与之前版本的差异。
我们在上面图片里面可以看到的是”+”标注的是在原文件的基础上增加的代码的记录，”-“标注的是在原文件的基础上删掉的代码的部分，颜色显示也不同。 
　其实我们团队是以任务为单位和模块进行的开发，这种开发模式在任务分配之处就已经给该任务提供了描述。

3. 如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)?你用了什么工具来帮助你？
    通常情况下，可以在git中执行合并即可实现自动合并Git修改的部分。但是，也存在被修改的部分发生冲突或无法自动合并的情况。也存在无法自动合并的情况。当修改的内容冲突时，应查看冲突内容，手工修改冲突，完成提交，然后使用git merge命令合并。通过git 版本控制工具既可完成。对于无法完成自动合并的原因在于远程数据库和本地数据库的同一个地方都发生了修改，系统无法自动判断要选择远程数据库还是选择本地数据库进行修改，所以会发生冲突。当然，git会显示本地数据库和远程数据库同一个地方的不同修改，所以我们可以根据git的显示手动解决问题。

4. 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
    git作为一个成熟的源代码版本管理系统，可以保证git服务器远程提供的修改操作具有原子性，这样就保障了整体修改的原子性。当然，在签入之前，一定要先对比处理有冲突的文件。在本地仓库中修改的文件都要统一经过commit为新的本地版本后，再push至远程分支。
5. 你的PC 上有关于三个功能的修改， 但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。
    在本地新建一个分支，然后在新的分支上进行bug的修复就好。当前分支的内容就被保存在原地。

6. 规范操作和自动化

    你的团队规定开发者签入的时候要做这些事情：

    - 运行单元测试，相关的代码质量测试。

    - 代码复审 （要有别的员工的名字）

    - 和这次签入相关的issue 编号， 任务/task， 缺陷/bug 编号，等等， 以备查询。

      请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？  （高级功能， 代码提交之后， 相关bug 的状态会改动为  “fixed”， 并且有链接指向这次签入。）

    我们团队没有使用这样的工具，我们在开发之前对编码做了规范，我们每次完成一个功能会自己测试好久，进行完单元测试后，将没有bug的代码提交Github。

7. 如何给你的源代码建立分支？

• git add 
• git commit -a：查看所有分支
• git branch [branch name]：创建分支
• git checkout [branch name]： 切换分支
• git push origin [branch name]

8. 一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？
    对于我们团队来讲每一次的任务都是由同一个人负责上传源文件，他在上传时会给文件打上标签，而且在签入的时候会有commit的记录保留，所以每一次的提交都可谓是目的明确，特征显著。至于“追责”问题，github上面有每一次的提交的记录，对应着非常容易找到相关负责人。
9. 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
    这个在每一次提交的时候没有特别的标记。我们团队一般会根据任务提交时的commit记录的时间推测这个版本是哪一个。还有就是我们团队都是大家讨论后，然后确定哪个版本是最好的，这样所有人就知道是哪个版本了。

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

      我们团队的源代码和测试这些代码的单元测试，以及其他测试脚本没有放在一起的。 至于测试的更新方面，还没有完成。 自动构建的任务也不能部署。

任务3：项目文档

团队项目Github仓库链接：https://github.com/Sophur/Team-Project

任务4：验收意见表

验收意见表Github仓库链接：https://github.com/Sophur/Team-Project

任务5：

1、验收过程：

　　在第十七周的实验课上，我们团队(Dare To  Dream)和FBG团队对对方软件产品进行验收评审，并形成验收意见。具体情况如下：

首先由我们组长绽玉林担任主持人，组织验收会对FBG团队项目进行验收。验收首先从“系统安装和运行”的验收我们的主演目标是检查系统

是否按照设计方式进行部署，是否对系统进行了正确的配置，系统是否能正常使用。其次再从“系统功能的验收”主要目标是检查系统各项功

能是否使用正常等。最后从“ 从系统各类文档的验收”进行验收在验收时我们的主要目标是：检查是否提交相关手册或说明书，文档与系统是

否一致，是否正确无误。经过详细的验收我们发现该团队项目基本合格。

2、本次实验的场景照片：

3、我们团队的具体分工如下：

姓名	具体任务	工作量比例	完成时间
绽玉林	1.项目演示前准备工作 2.撰写博客	16%	8h
李金平	1.撰写开发总结文档 2.撰写设计文档	18%	10h
姚慧霞	1.撰写Beta冲刺博客 2.撰写过程文档	18%	12h
木冬梅	1.撰写项目验收表 2.回答源代码管理的问题	16%	9h
张存慧	1.撰写实施文档 2.整理文档	16%	10h
严龙	１.制作PPT ２.撰写测试文档	16%	8h

 

4、心得体会：

• 木冬梅：

  　 在此次进行模拟验收的过程中，发现有自己不懂的很多的东西，但验收结束后，很多困惑都得以解答，因此很多时候在实践中体会到的知识点远胜

于单纯的理论灌输,当然代老师在软件工程这门课上用的教学方式自己还是非常认同的。从个人项目到团队项目，不知道写了多少文档，也不记得做

了多少工作，挑灯夜读的情况不少见，当初不明白这样做的目的，只有在最后验收的时候才深切体会到之前做这些工作的重要性，也发现了自己工作

上的一些不足。技能得到提升，更深切地领悟软件工程课程的真正含义，体会团队合作，这些都在潜移默化当中对自己留下了深刻的印象，没白学，也没白辛苦。

• 张存慧：

　　团队作业的任务终于结束了，也意味着软件工程这门课也接近尾声。虽然团队的软件系统做的不是很完美，但是是所有团队成员努力的成果。汇报完项目时感觉一身轻，但同时我也知道日后自己需要学习和改进的地方还有很多。团队合作的时候我们团队没有发生一些不必要的不愉快，一方面是因为我们分工明确，一方面是团队成员之间是互相帮助，体谅彼此的，很荣幸和他们成为队友。

• 姚慧霞：

　　从最初的需求分析、原型设计、详细设计、编码开发到最后的测试验收，这一路走来着实不容易，也深刻的意识到了光有理论知识是不可行的，在实践中学习才是最有效，做直接的学习方式。当然，实践不可能没有理论的支撑。

• 绽玉林：

　　虽然我们刚开始一窍不通，但是随着作业的一步步的深入以及老师的循循善诱，最终我们得到了一个让人满意的结果，这期间有想过放弃，想过敷衍，但是最终在团队的督催以及共同努力下，为了我们共同的目标还是坚持了下来。虽然我们做的不如别的团队，但是我们也有我们的特点，这是我们共同努力的结果，希望在以后的学习生涯中，弥补我们之前的不足，有则改之无则加勉。

• 李金平：

　　一路走来有愉快也有悲哀，有失落也有痛快，愉快的是我们团队没有因为困而倒下，悲哀的是自己曾经的努力不足，失落是因为没有按时完成任务，痛快是因为我们的努力有了结果。希望我们在人生的道路上记得我们一起坚持过，一起奋斗过，要用我们这一学期学到的东西去应对我们工作中的问题，这一学期学到的知识，以及对软件工程的深入了解，都将对我们有启发式的作用，希望以后能再接再厉，勇往直前。

• 严龙：

　　未接触软件工程之前一直都很想学这门课程,因为觉得这门课很牛,是那些有工程师称号的高手才摆弄的东西。学了一个学期的软件工程课,终于知道了个软件工程的大概。学的时候总觉得很抽象,理解起来好像不难,但总是摸不着头脑一种很茫然的感觉。
　　曾经以为程序就是软件,软件就是程序。学习这门课程第一个收获是,知道了二者的不同之处。以前做过的一些小型的软件比如加密软件,我也只是在程序旁边附上一个软件的说明,看来已经很接近作坊了。不过大的项目没有接触过,用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生,使得人们不得不探索新的解决方法。
　　经过代老师的讲解,理解了软件工程,就是一套用于软件的团队开发,以提高软件质量和程序员工作效率为目的的规范。其核心就是,对于软件开发的5个重要组成部分:需求分析,设计,编码,调试,维护,如何组织这5个部分的工作,以及如何完成每一个工作，一个学期的软件工程让我有了更多的知识储备，掌握了更多的技能才能更好的走向社会。

 

5、团队总结：

　　通过一个学期的紧张学习，通过繁忙的项目作业，我们学到的不只是课本上的知识，更对软件工程有了更深刻的了解。软件工程并不只是我们以前所认为的写代码，写代码只是众多流程中的一部分而已，我们需要更多的是与团队的合作，如何提高团队的效率才是我们所需要解决的问题。通过这门课程的学习，我们要认识到的一点就是客户至上，因为不管你做的有多完美，有多么先进的功能，要是客户不满意，那你的工作就毫无意义，所以如果我们不想从头再来，就必须在用户需求上下很大的功夫，只有需求明确了，我们才能一步步展开我们的工作。希望我们在以后的工作中严格遵守软件工程的原则不要以自己的想法为目标进行工作。