实验十二 团队作业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的修复就好。当前分支的内容就被保存在原地。
我们团队没有使用这样的工具，我们在开发之前对编码做了规范，我们每次完成一个功能会自己测试好久，进行完单元测试后，将没有bug的代码提交Github。
- 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 |
- 木冬梅：
在此次进行模拟验收的过程中，发现有自己不懂的很多的东西，但验收结束后，很多困惑都得以解答，因此很多时候在实践中体会到的知识点远胜
- 张存慧：
- 姚慧霞：
- 绽玉林：
- 李金平：
- 严龙：
曾经以为程序就是软件,软件就是程序。学习这门课程第一个收获是,知道了二者的不同之处。以前做过的一些小型的软件比如加密软件,我也只是在程序旁边附上一个软件的说明,看来已经很接近作坊了。不过大的项目没有接触过,用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生,使得人们不得不探索新的解决方法。
经过代老师的讲解,理解了软件工程,就是一套用于软件的团队开发,以提高软件质量和程序员工作效率为目的的规范。其核心就是,对于软件开发的5个重要组成部分:需求分析,设计,编码,调试,维护,如何组织这5个部分的工作,以及如何完成每一个工作，一个学期的软件工程让我有了更多的知识储备，掌握了更多的技能才能更好的走向社会。