| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 课程学习目标 | （1）学习团队软件项目流程（TSP）、团队成员协作要求。 （2）掌握敏捷流程原则及相关概念。 |
| 实现目标 | （1）学习到了团队软件项目流程（TSP）、团队成员协作要求。 （2）掌握了敏捷流程原则及相关概念。 （3）运行了同行代码，在实践中学习到了许多。 |
| 结对方学号-姓名 | 201771030122-王瑞梅 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/xcp-yyqx/p/12669980.html |
任务一：
1.案例作业博客链接：https://www.cnblogs.com/litinghua/p/12534838.html
2.案例作业项目仓库链接：https://github.com/wyq1998/System-second
3.评论截图：
4.系统运行截图：
软件功能总结：
（1）用户注册时分级。
（2）可实现不同角色分别登陆。
（3）学生/教职工可填报疫情信息。
（4）二级部门管理人员可以实现查看疫情信息。
（5）疫情信息支持多属性可视化查看。
（6）可实现人员添加功能。
（7）可导出疫情信息。
（8）可实现填报提醒。
bug：
插入信息时出现乱码问题：
5.本组项目不足：
- 我们组实现了基本功能，附加功能基本没有实现，通过案列博客的学习，本组项目还有很多需要改进，通过学习其他组的项目，我觉得我们的项目做的不够好，后面会进一步的完善。
- 程序没有明显的bug，数据过多时查询的速度可能会非常慢，这个问题是电脑服务器的问题。
任务二：
软件项目团队的特点：
1.团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。
2.团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队的模式：
一窝蜂模式、主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队（SWAT）、交响乐团模式（Orchestra）、爵士乐模式（Jazz Band）、功能团队模式（Feature Team）、官僚模式（Burewucratic Model）。
瀑布模型是一个反映人类解决问题思路的常用模型。
它在软件工程中的局限性在于：
1.各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来；
2.回溯修改很困难甚至不可能，但是软件生产过程需要时时回溯；
3.最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
瀑布模型的适用范围：
1.如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
2.产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证；
3.使用的技术非常成熟，团队成员都很熟悉这些技术；
4.负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
瀑布模型的各种变形：
生鱼片模型：解决了各个步骤之间分离的缺点。
大瀑布带着小瀑布：解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题。
渐进交付流程：（很接近迭代式开发流程）。
当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中。
CMU软件工程学院总结的TSP原则：
1.使用妥善定义的流程，流程中的每一步都是可以重复，可以衡量结果的；
2.团队中的每个成员对团队的目标、角色、产品都有统一的理解；
3.尽量使用成熟的技术和做法；
4.尽量多地收集数据（也包括对团队不利的数据），并用数据来帮助团队做出理性的决定；
5.指定切合实际的计划和承诺，团队计划要由负责具体执行的角色来制定（而不是从上级而来）；
6.增加团队的自我管理能力；
7.专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
敏捷流程：“敏捷流程”是一系列价值观和方法论的集合。
敏捷开发的原则是：
1.尽早并持续地交付有价值的软件以满足客户需求；
2.敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势；
3.经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
4.业务人员和开发人员在项目开发的过程中应该每天共同工作；
5.以有进取心的人为项目核心，充分支持信任他们；
6.无论团队内外，面对面的交流始终是最有效的沟通方式；
7.可用的软件是衡量项目进展的主要指标；
8.敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去。
9.只有不断关注技术和设计，才能越来越敏捷；
10.保持简明-尽可能简化工作量的技艺-极为重要；
11.只有能自我管理的团队才能创造优秀的架构、需求和设计；
12.时时总结如何提高团队效率，并付诸行动。
敏捷的步骤：
第一步：找出完成产品需要做的事情；
第二步：决定当前的冲刺需要解决的事情；
第三步：冲刺；
第四步：得到软件的一个增量版本，发布给用户，然后在此基础上又进一步计划增量的新功能和改进。
讨论截图：
任务三：
1.项目选择
| 项目 | 链接 |
|---|---|
| 项目名称 | 博客园APP续写 |
| 发布账号 | https://www.cnblogs.com/PureMan6/ |
| github仓库 | https://github.com/swearitagain/EduCnblogs2.0 |
2.选择理由
(1)我觉得不同院校学生的设计思维会有很大的不同，选择其它学校的同学的项目，是想体会一下他们的项目设计思想。
(2)通过这次软件工程的学习，我觉得博客园在我们计算机学院的同学的学习生活中很有用处，但手机端的普及很少，虽然有网页版的功能很齐全，但还是觉得APP实现的话使用会更方便；
(3)感觉项目难度不是很大，使用到的开发技术也了解一点，因此分析项目时比较容易上手；
基于以上几点，我选择了这个团队项目进行分析。
3.项目团队成员分工合作情况
此次项目团队参与人员总共有8名。
在项目前期有6名人员，其中2人担任PM，3人负责开发，2人负责测试（这是因为一个人即负责PM，又负责测试）。在项目开发后期，新入组了两名成员，其中一名替代了原来的测试人员，一名参与到开发任务中。
两个PM主要来负责把握整个项目的进度、发布完成调查问卷、完成项目的各种规格说明书、所有博客的撰写、整理例会报告、组织开会，了解后期的项目版本的发布渠道并进行发布。3个开发人员进行确定好的每个功能的编码，需要时学习相关的知识，阅读相关的代码，对测试时发现的bug进行修复。测试人员负责测试开发人员每个阶段编写好的代码，并发现其中存在的问题，学习相关的测试知识。
合作体现在PM在需要时也会学习相关的新知识，参与到开发任务中，帮助开发人员进行代码编写。开发小天使们在完成自己的任务后也会主动在测试人员测试之前进行一些小测试，承担了一些界面优化、bug修复的工作，在编写测试单元时开发和测试也进行了良好的沟通协作。
4.项目的软件项目过程特点（TSP）
(1)经过阅读该项目系列博客文档，该项目实施过程中使用了妥善的定义流程，流程中的每一步都是可以重复、可以衡量结果的。
(2)团队的各个成员对团队的目标、角色、产品都有统一的理解。
(3)使用到的Android的开发技术也比较成熟。
(4)也制定了切合实际的计划和承诺，团队计划由2个PM负责具体执行。
(5)团队的自我管理能力也比较强。
5.代码规范文档
通过查看项目github仓库源代码文件，可以看出来该项目的源代码文件很齐全。项目代码规范、配置文件、包括一些修改的文件、以及在开发阶段涉及的各种规格说明文档全部都包含。
6.团队项目代码运行情况
-
使用体验
(1)第一感觉就是APP界面简洁美观，使用起来也很方便；
(2)只要登录便会通知学生即将截止的作业和距离截至所剩余时间；
(3)历史记录功能(可查看自己的浏览记录)；
(4)添加了投票功能 -
运行情况
-
存在的BUG
1.登录成功时界面会显示授权码：
2.提交列表无法显示：
7.评价该团队项目是否值得继续开发，并陈述理由：
我觉得该团队项目值得继续开发，博客在我们的学习生活中很有用处，我自己也经常在博客上学习一些知识点，他们的分享总结有的写的特别好，好多人在遇到一个难点解决之后就会通过博客记录下来，把博客当成笔记一样在做，而网页版的在查看的时候会有一些其它的信息干扰，如果可以开发出一个APP，我觉得在写博客，阅读博客等方面会方便很多的，主要可以在用户界面方面和功能方面做改进，当前界面有点简陋可以做美化，功能也不是特别全面，可以做进一步修改，如果有机会能和这样的团队一起学习，相信一定会进步不少。
任务四：
-
完成各项任务实际花费时间
任务 花费时间/(h) 任务1 5 任务2 3 任务3 10 任务4 2
本次作业感受和小结
在这次实验过程中，我发现看懂别人写的代码是如此困难和吃力，下载运行过程中也遇到了许多困难，还是自己功底不够，不过通过这次的学习，我寻找到了别的同学做软件项目的思考过程和方法，如果能将他们的思维和方法运用到我本人平时的学习过程中，那将是非常完美的。