一、关于十个问题的回答
1、你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
答： 团队项目在Github上托管，采用git的方式进行版本控制。团队的在处理文件的锁定问题上是不加锁的，为了防止项目提交的冲突，我们提前约定，每次修改代码前，先git pull，修改之后git push并在团队群中说一声“代码已更新”。
2、如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。
答：git pull进行更新后，可以看到本地的版本和最新的版本之间的不同之处，同时，本地上传自己的文件时，也可查看到修改了哪些地方。
点开项目的commit的记录，点击相应的SHA版本哈希值之后可以进入到如下的页面 ，下图是为了解决可视化慢的问题以及设备无法删除的问题时对代码进行增删的记录图，”+”标注的是在原文件的基础上增加的代码的记录，”-“标注的是在原文件的基础上删掉的代码的部分，颜色显示不同。
3、如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？
答： 在git中执行合并即可自动合并Git修改的部分。但是，也存在无法自动合并的情况。如果在远程数据库和本地数据库的同一个地方都发生了修改的情况下，因为无法自动判断要选用哪一个修改，所以就会发生冲突。git会显示本地数据库和远程数据库同一个地方的不同修改，这时候就需要我们手动解决冲突，暂时没有想到什么好的工具可以解决不借助人力自动解决这个问题，只能依据规定和协商解决这一问题。
部分上传修改记录：
4、你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
答： git作为一个成熟的源代码版本管理系统本身就可以保证在签入时的原子性，所以在我们的项目开发流程中没有遇到部分修改可以上传而某些部分的修改不能上传的混乱状态。
5、你的PC 上有关于三个功能的修改， 但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改
答：这个时候我们只要在本地新建一个分支，然后在新的分支上进行bug的修复就好。当前分支的内容就被保存在原地。
6. 规范操作和自动化
你的团队规定开发者签入的时候要做这些事情：
- 运行单元测试，相关的代码质量测试。
- 代码复审 （要有别的员工的名字）
- 和这次签入相关的issue 编号， 任务/task， 缺陷/bug 编号，等等， 以备查询。
请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？ （高级功能， 代码提交之后， 相关bug 的状态会改动为 “fixed”， 并且有链接指向这次签入。
答：我们没有这样的工具，我们每次完成一个功能会自己测试好久，将基本能考虑到的情况是尝试一次，之后再提交，尽量降低出差错的可能。
7、 如何给你的源代码建立分支？
答：本地创建新的分支
命令如下：git branch [branch name]
查看所有分支
命令如下：git branch -a
切换到新的分支
命令如下：git checkout [branch name]
（注：由于这些操作是在之前的工作中完成的，当时没有截图，重新操作需要删除分支再重新创建，为避免麻烦故此处省略了截图，只贴取了相关的执行命令）
8、一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？
团队规定成员提交commit时，记录原由。因此在GitHub上可以看到具体是哪位负责人，何时提交的代码。
9、如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
这个并没有特别的标签，一般是通过提交时间，或者通过某个功能以及commit记录的信息来确定某个版本，得到得到“Last Known Good”。
10、 你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？
团队没有使用自动测试的框架，我们每次完成功能后，会对各模块手动测试。我们团队也没有部署自动构建，为了方便，我们通过写的脚本快速部署。
二、项目文档
验收之前，本项目组已准备好以下几类文档：
1) 开发总结文档
2) 需求文档：包括需求规格说明书，需求变更文档等
3) 设计文档：包括概要设计，详细设计，数据库设计等
4) 测试文档：包括测试方案，内部测试报告，第三方测试报告等
5) 实施文档：包括实施，部署方案，用户手册，维护手册等
6) 过程文档：包括项目周报，会议纪要等
github链接：https://github.com/524633094/Software-engineering-project/tree/master/docs
三、项目验收过程
项目汇报阶段：由老师担任主持人，主要技术人员张琪进行PPT讲解，汇报本项目的项目背景、开发过程、功能简介、工作总结，并对本系统进行演示，由老师和其他同学对本项目进行提问，该团队成员进行解答，在此同时，老师根据项目讲解情况、项目完成度以及答疑情况对本项目进行评分。
项目验收阶段：本次项目验收会议成员为Miracle-House 团队和本团队的全体成员，先有本项目做工作汇报和总结，接着，本团队主要技术人员进行系统实现过程简述和系统演示，再由合作团队的组长检查系统安装和运行、系统功能以及系统开发等相关文档，填写项目验收意见表。
https://v.youku.com/v_show/id_XMzY5NjQ3NTM4OA==.html?spm=a2h3j.8428770.3416059.1 四、实验执行过程
1、燃尽图
本次实验任务我们基本按照了燃尽图进行实现，但也略有出入，前期较计划时间完成的快速，后期相比于计划时间，我们时快时慢，最终还是依照计划时间完成了工作。
2、实验场景照片
- 测试过程
- 讨论过程
五、任务安排
| 团队成员 | 具体分工 | 占整个实验任务的工作量比例 | 完成各自任务的实际时间 |
| 张琪 | 后台代码改善；真实用户体验WEB端等 | 18.5% | 10h |
| 张永琪 | 剪辑Green Cloud系统视频；APP端利用测试用例进行测试等 | 18.5% | 10h |
| 付恩丽 | WEB端完善出错代码；撰写博客；数据库文档完善；制作团队项目总结PPT等 | 18% | 10h |
| 火忻 | 真实用户体验WEB端；完善WEB端测试用例，并进行测试等 | 15% | 8h |
| 刘丽 | 剪辑Green Cloud系统视频；APP端利用测试用例进行测试等 | 15% | 8h |
| 刘琼 | 完善登录测试用例；完善WEB端测试用例，并进行测试；撰写博客等 | 15% | 8h |
六、心得体会
这一段时间我的任务是完善自动化模块，例如浇水控制等，我是按照前期的需求结合自己的理解完善了自动浇水。但是在给同学体验时，大家对这个模块其实并不是很满意。
在前期获取需求时，有人喜欢自动浇水，有人喜欢手动浇水，我万万没想到在我结合了自动加手动浇水之后的结果时大家都不是很满意，这中间一定发生了什么问题。。。经过我的询问与思考，我认为我们团队没有为我们的用户描绘一个准确的画像，用户群体应当更加精准，精准的用户画像会让我们知道我们服务的目标群体到底需要什么。
- 张永琪
此次项目，确为复杂。从硬件到软件，从WEB到APP，遇到很多问题。 说简单了，也就是植物的精细化养殖。 但就一个单一的方向，要做完善实属不易。此次项目，我主要负责的APP端，尽管说APP做的并不复杂，功能并不多，但就数据是实时获取，折腾了好久。数据的实时获取又引发内存溢出等等问题。这个过程用“艰难”、“痛苦”形容并不为过。幸好最后的结果还算不错，收获也不少。唯一让我感到不满的是在这个需要认真准备考研的重要时期，花费了大量的时间在这个项目上，实在是不划算。最后，不得不感谢我们这个团队，大家都很努力，各尽其职，都用心去完成这个项目，我感到很荣幸。尤其是能和我们技术大咖CTO一起合作，真的是幸福，好多的问题不再是问题，他的优秀也带动了我们的小团队。Just do it! Fighting!
- 付恩丽
测试阶段相对来说比较顺利，由于硬件设备的限制，测试让用户体验比较麻烦，团队成员忙着测试与整理项目文件，这几天beta冲刺阶段团队成员都挺辛苦的，感谢大家，我们是一个团队，加油。
- 火忻
终于，一学期的时间课程到现在接近了尾声，最棒的是到今天为止我们的项目和任务总算全部完成啦，开心(*^▽^*)~ 在开展项目的这段时间，完成我们项目的同时，通过查看他人博客的展示以及与其他同学的交流等方式，让我见识到了不少优秀的项目。最大的感触就是，无论是任何一个项目，哪怕其规模再小或是功能再简单，只要能真正帮助到用户，让用户感觉到这个到这个东西确实是被他们所需要的，那这个项目就有了它的价值。抓住一个关键点，尽最大努力进行优化完善从而更好的解决用户的痛点问题是我们不懈的追求。
- 刘丽
我们的项目在Alpha冲刺阶段基本完成，在Beta阶段则是进一步的改善和测试，以及各文档的整理，通过真实用户的使用和反馈对系统的各方面作进一步的改善。在测试过程当中，发现有不少细心不足的地方，或者有些逻辑考虑的不够周全的地方，图表界面不够美观等等，小组成员经过分工合作不断对系统进行了完善。在Beta冲刺阶段，我主要负责系统的视频剪辑、部分文档的整理和完善以及团队项目验收表的制作。在这个过程中我学到了视频剪辑的相关知识，在图表界面优化的问题上，我对插件的使用更加熟练，在委托和核实的问题上，对一些逻辑问题理解的更加透彻，数据库语句也用的更加灵活。
- 刘琼
我们的项目Alpha冲刺阶段已经基本完成，现在进行的都是进一步完善的工作，包括代码再优化、文档整理、测试系统及APP端、验收工作的准备。此次任务中，我主要负责完善登录测试用例，完善WEB端测试用例，并进行测试，撰写博客等几方面，在这几项工作中，不仅需要积极的工作态度，还需要细心和耐心。通过一步步的完成，我学习到了许多，也收获到了许多，感谢我们这个团队！
- 总结陈述
Green Cloud系统提出来之后，感觉挺新颖的，我们大家想着可以做好这个项目，但在实现过程中发现自己在软件开发过程中存在许多误区，慢慢的意识到我们这个项目的复杂性超出了自己最初的定义，技术以及经验的不足，我们适当的降低了功能复杂性，APP主要功能模块有植物环境监测、自动化控制、植物信息查询以及相关设备的管理。我们的项目已经基本完工，但还是有些预想的附加功能还未实现，还有存在部分bug没有发现，我们后期还会不断地改进和修复。
本次项目开发快要告一段落了，这段时间每个成员都辛苦了，特别是张琪和张永琪，两个主力付出了很多，其他成员也做出了应有的贡献，所以才有了最后项目的完成。这个阶段最大的收获就是学会了协调成员，加强了表达能力和协调能力，充分激发了自己的组织潜能，锻炼了自己的工作能力，算是一件特别棒的事情。这段时间自己也成长了很多，很荣幸能够处在这么优秀的团队当中，非常的自豪和骄傲，谢谢我的每位队员，我自己在团队以及项目管理上经验不足，没有做好的地方希望大家见谅。
最后，谢谢代老师和同学们对我们项目的肯定以及后期开发过程的建设性意见和建议。
一、关于十个问题的回答
1、你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
答： 团队项目在Github上托管，采用git的方式进行版本控制。团队的在处理文件的锁定问题上是不加锁的，为了防止项目提交的冲突，我们提前约定，每次修改代码前，先git pull，修改之后git push并在团队群中说一声“代码已更新”。
2、如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。
答：git pull进行更新后，可以看到本地的版本和最新的版本之间的不同之处，同时，本地上传自己的文件时，也可查看到修改了哪些地方。
点开项目的commit的记录，点击相应的SHA版本哈希值之后可以进入到如下的页面 ，下图是为了解决可视化慢的问题以及设备无法删除的问题时对代码进行增删的记录图，”+”标注的是在原文件的基础上增加的代码的记录，”-“标注的是在原文件的基础上删掉的代码的部分，颜色显示不同。
3、如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？
答： 在git中执行合并即可自动合并Git修改的部分。但是，也存在无法自动合并的情况。如果在远程数据库和本地数据库的同一个地方都发生了修改的情况下，因为无法自动判断要选用哪一个修改，所以就会发生冲突。git会显示本地数据库和远程数据库同一个地方的不同修改，这时候就需要我们手动解决冲突，暂时没有想到什么好的工具可以解决不借助人力自动解决这个问题，只能依据规定和协商解决这一问题。
部分上传修改记录：
4、你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
答： git作为一个成熟的源代码版本管理系统本身就可以保证在签入时的原子性，所以在我们的项目开发流程中没有遇到部分修改可以上传而某些部分的修改不能上传的混乱状态。
5、你的PC 上有关于三个功能的修改， 但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改
答：这个时候我们只要在本地新建一个分支，然后在新的分支上进行bug的修复就好。当前分支的内容就被保存在原地。
6. 规范操作和自动化
你的团队规定开发者签入的时候要做这些事情：
- 运行单元测试，相关的代码质量测试。
- 代码复审 （要有别的员工的名字）
- 和这次签入相关的issue 编号， 任务/task， 缺陷/bug 编号，等等， 以备查询。
请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？ （高级功能， 代码提交之后， 相关bug 的状态会改动为 “fixed”， 并且有链接指向这次签入。
答：我们没有这样的工具，我们每次完成一个功能会自己测试好久，将基本能考虑到的情况是尝试一次，之后再提交，尽量降低出差错的可能。
7、 如何给你的源代码建立分支？
答：本地创建新的分支
命令如下：git branch [branch name]
查看所有分支
命令如下：git branch -a
切换到新的分支
命令如下：git checkout [branch name]
（注：由于这些操作是在之前的工作中完成的，当时没有截图，重新操作需要删除分支再重新创建，为避免麻烦故此处省略了截图，只贴取了相关的执行命令）
8、一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？
团队规定成员提交commit时，记录原由。因此在GitHub上可以看到具体是哪位负责人，何时提交的代码。
9、如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
这个并没有特别的标签，一般是通过提交时间，或者通过某个功能以及commit记录的信息来确定某个版本，得到得到“Last Known Good”。
10、 你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？
团队没有使用自动测试的框架，我们每次完成功能后，会对各模块手动测试。我们团队也没有部署自动构建，为了方便，我们通过写的脚本快速部署。
二、项目文档
验收之前，本项目组已准备好以下几类文档：
1) 开发总结文档
2) 需求文档：包括需求规格说明书，需求变更文档等
3) 设计文档：包括概要设计，详细设计，数据库设计等
4) 测试文档：包括测试方案，内部测试报告，第三方测试报告等
5) 实施文档：包括实施，部署方案，用户手册，维护手册等
6) 过程文档：包括项目周报，会议纪要等
github链接：https://github.com/524633094/Software-engineering-project/tree/master/docs
三、项目验收过程
项目汇报阶段：由老师担任主持人，主要技术人员张琪进行PPT讲解，汇报本项目的项目背景、开发过程、功能简介、工作总结，并对本系统进行演示，由老师和其他同学对本项目进行提问，该团队成员进行解答，在此同时，老师根据项目讲解情况、项目完成度以及答疑情况对本项目进行评分。
项目验收阶段：本次项目验收会议成员为Miracle-House 团队和本团队的全体成员，先有本项目做工作汇报和总结，接着，本团队主要技术人员进行系统实现过程简述和系统演示，再由合作团队的组长检查系统安装和运行、系统功能以及系统开发等相关文档，填写项目验收意见表。