一.beta冲刺
beta冲刺第一、二天：https://www.cnblogs.com/ruanjgc/p/9226434.html
beta冲刺第三天：https://www.cnblogs.com/ruanjgc/p/9231636.html
beta冲刺第四天：https://www.cnblogs.com/ruanjgc/p/9235953.html
二.关于源代码管理的10 个问题：
1.你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题?
答：团队项目在Github上托管，采用git的方式进行版本控制。使用win7系统，团队的在处理文件的锁定问题上是不加锁的，下面phone.rar是我们项目的源代码。
2.如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系?
答：之前版本操作复杂，可控制度低很难操作，本系统的主要优势是适合中老年人对信息更新速度低这些上很有优势，可以使用git相关命令来查看当前没有添加到本地仓库的内容修改情况，当前添加到本地仓库但没有提交到托管平台的内容提交情况，以及查看任意两个提交版本之间的改动情况；代码修改应当包括工作项提交和缺陷修复，可以从commit记录查看修改情况。
3. 如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)?你用了什么工具来帮助你？
答：在git中执行合并即可自动合并Git修改的部分。但是，也存在无法自动合并的情况，如果在远程数据库和本地数据库的同一个地方都发生了修改的情况下，因为无法自动判断要选用哪一个修改，所以就会发生冲突。git会显示本地数据库和远程数据库同一个地方的不同修改，这时候就需要我们手动解决冲突。
4. 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
答：用IDEA的资源库同步的功能，这个功能可以显示有冲突的文件（用红色标注），在签入的时候，先把冲突文件更新下来，与本地自己要签入的文件进行一轮merge，然后再把20个文件一起签入即可。
5.你的PC 上有关于三个功能的修改， 但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改?
答：在当前master分支开一个新的分支brach对文件进行改写。当前master分支开一个分支bug进行bug的修复，修复完成之后与master进行合并，完成了功能的实现的brach分支之后再与master分支进行合并。
6. 规范操作和自动化
你的团队规定开发者签入的时候要做这些事情：
- 代码复审 （要有别的员工的名字）
- 和这次签入相关的issue 编号， 任务/task， 缺陷/bug 编号，等等， 以备查询。
请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？
答：我们团队没有这样的工具
7. 如何给你的源代码建立分支？
答：本地创建新的分支：git branch [branch name]
查看所有分支：git branch -a
切换到新的分支：git checkout [branch name]
8. 一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的？
答：根据交付信息来知道它是什么时候签入的，为什么签入的，在我们签入的时候，会有签入的时间，后面的备注会写着什么目的签入的。
9. 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
答：通过提交时间，或者通过某个功能以及commit记录的信息来确定某个版本，得到“Last Known Good”。在github上每次就该并提交的时候将自己所写的内容标记好，在后同步的时候就能够清晰。
10. 你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？
答：我们团队的项目源代码和单元测试以及其它测试脚本不是在一起的，在写好代码后，进行手动测试，修改源代码后，测试会更新，没有部署自动构建的任务。
三.项目文档
文档准备： 验收之前，本项目组已准备好以下几类文档：
1) 开发总结文档
2) 需求文档：包括需求规格说明书，需求变更文档等
3) 设计文档：包括概要设计，详细设计，数据库设计等
4) 测试文档：包括测试方案，内部测试报告，第三方测试报告等
5) 实施文档：包括实施，部署方案，用户手册，维护手册等
6) 过程文档：包括项目周报，会议纪要等
项目概况PPT
项目概况ppt包括以下几个部分：
1) 项目背景和简介
2) 合同执行情况汇报
3)开发过程：记录项目开发过程中的一些重要事件
4) 系统功能简介
5)项目应用成果展望
github链接:https://github.com/13993013291/ruanjianguigexuqiu
四.项目验收过程
汇报阶段：由老师担任主持人，主要技术人员妥志福进行PPT讲解，汇报本项目的项目背景、开发过程、功能简介、工作总结，并对本系统进行演示，由老师和其他同学对本项目进行提问，该团队成员进行解答，在此同时，老师根据项目讲解情况、项目完成度以及答疑情况对本项目进行评分。
验收阶段：本次项目验收会议成员为对不对团队及其团队全体成员，先有本项目做工作汇报和总结，接着，本团队主要技术人员进行系统实现过程简述和系统演示，这些工作结束以后，由对不对团队进行提问，本项目成员解答，最后由对不对团队的组长填写项目验收意见表。
五.实验执行过程
1.燃烬图：
2.实验场景照片：
六.任务安排
|
验收会议名单及验收会议议程
|
牛瑞鑫
|
15%
|
1.5h
|
|
总结及撰写博客，填写项目验收意见表
|
王胜海
|
20%
|
2h
|
|
软件测试
|
邓英蓉
|
15%
|
1.5h
|
|
制作汇报PPT
|
马中林
|
15%
|
1.5h
|
|
项目汇报，文档整理
|
妥志福
|
20%
|
2h
|
|
回答源代码管理的十个问题
|
董润园
|
15%
|
1.5h
|
七.心得体会
王胜海： 在本次项目中，我们小组通过讨论，调查，分析等方式和策略认真的完成了这次实验；在项目中，我们大家一起动手，一起参与讨论，最后汇总得到一个最佳的方案，得到了这次项目中的最优解，让我们的项目趋于完善。通过这次项目我学到了很多知识，也学到了很多项目解决的方案方法。
妥志福：本次实验负责的是后台逻辑的整理，通过与小组成员的商量与探讨，在书写后台功能的过程中，通过网上查阅相关资料找到了解决思路，不断在解决问题中成长。
牛瑞鑫：通过用户需求的调研，更加明确了系统功能，方便了系统设计与开发。通过前端界面设计与前端代码的书写，与小组成员的沟通，对前端出现的一些问题相关概念有了一定的理解。
马中林：在本次项目中，负责的是团队项目系统设计说明书和详细设计说明的撰写，通过课堂上老师的讲解对理论知识有了进一步的理解。
邓英蓉：在本次项目中，负责软件的测试工作，通过这次测试之后，首先我发现测试并不是一个人的任务，在团队其他队员的积极帮助中，我对测试有了一定的了解。测试时始终都需要和开发与设计人员进行良好的沟通，对软件要有全面的了解，根据测试目的和测试计划，搭建测试环境，生成测试数据。
董润园：通过小组讨论以及网上查阅相关的资料书写了《软件编码规范说明书》，负责了项目的测试工作，发现规范的编码格式可以使得代码有更好的可读性，良好的代码规范是完成任务的一个重要前提。在本次项目的开发中也遇到了许多问题，通过和团队其他成员的讨论得到了解决，将以前所学的理论知识应用到了实践中。
