| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 课程学习目标 | 1.学习团队软件项目流程（TSP）与团队成员协作要求；2.掌握敏捷流程原则及相关概念。 |
| 这个作业在哪些方面帮助我实现学习目标 | 1.掌握团队项目开发的大致流程与相应的要求；2.了解了敏捷开发流程的基本原则。 |
| 结对方学号-姓名 | 201771010103-陈亚茹 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/980303CYR/p/12643395.html |
一：在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价。
1.案例作业博客链接
https://www.cnblogs.com/litinghua/p/12534838.html
2.案例作业项目仓库链接
https://github.com/wyq1998/System-second
3.对案例博文作业的评论
4.案例项目的系统运行截图、软件功能
已经克隆案例作业到本地。
系统的功能：
- 系统实现了采集全校师生员工疫情信息的功能。
- 二级防疫部门和其他人填报的页面是是权限分开的两个相同页面。
- 防疫部门普通工作人员可以浏览所有填报信息。
- 二级部门负责人可以浏览本部门所有成员填报信息，增删查本部门填报信息并得到感染情况统计图。
- 防控办负责人可以浏览所有成员的填报信息，并实现更全面的增删查和以及学生和教职工分别的信息汇总。
- 实现了定时填报提醒功能。
系统功能界面截图：
-
学生登录
-
学生信息提交
-
教师信息提交
-
二级防疫部门负责人提交
-
学号查询
-
时间查询
-
姓名模糊查询
- 感染情况查询
存在的Bug和问题截图
- 没有填写任何信息，点击增加，却显示添加成功。
- 此作业虽然显示了提醒功能，但是这个功能运行时存在问题，打开界面，填入提醒时间后运行，提醒一直不停止，只能被迫停止项目才能停掉提醒功能。
- 用户想要时间准确查询，可是前面输入的学号却没有消除，给用户造成学号和时间查询混乱
- 导出到excel中，文本框中填入什么没有提示，而且填入shi，不报错，不弹出提示框。
阅读代码规范文档
总体来说，该组同学的作业完整的实现了要求的功能，博文作业设计大方。并且案例博文对设计介绍，功能说明，类与类之间的关系等等都有详细的说明，这使得我们在运行学习她的代码时非常方便。博文思路清晰，一遍阅读过去就可以获取我们想要的信息，非常值得我学习和借鉴。
5.本组博文作业及代码设计存在问题与不足。
-
博客作业中软件设计部分缺少一个流程图，因为一般的项目一个界面登陆进去就可以进行各种操作。然而此项目却分了好几个登录界面，比较复杂。并且用了数字表示不同类型的登录，这样文字叙述既不简洁又不明了，达不到一目了然的效果。若果做一个流程图，就可以十分清楚显示。
-
代码设计存在冗余部分，在TestFly.java中涉及了没有使用到的数据库，并且运行时有一点点小错误。
-
还有登录界面可以稍微做一点美化，不然界面十分单调。只有两行文字。
二：与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
1. 软件项目团队的特点
（1）. 团队有一致的集体目标，团队要一起完成这个目标。
（2）. 团队成员有各自的分工，互相依赖合作，共同完成任务。
2. 软件团队的模式
（1）. 一窝蜂模式：最初的十分随意的软件团队模式，经过一段时间的演变将转变为后续的其他模式；
（2）. 主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
（3）. 明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
（4）. 社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
（5）. 业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
（6）. 秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
（7）. 特工团队：团队由专业人士组成，负责一些紧急问题的解决（如此次新冠疫情）；
（8）. 交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
（9）. 爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
（10）. 功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
（11）. 官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
3. 瀑布模型及其变形
瀑布模型产品遵循 [分析→设计→实现（制造）→销售→维护] 这一流程，其描述了单项的、不可逆的生产过程。由于严格的瀑布模型存在诸多缺陷，因此温斯顿提出了对瀑布模型的改进如图2.1.1，其中他提出了相邻步骤间的回溯与模型的再运行以收集反馈进行产品改进，他也强调了文档的重要性。
瀑布模型的局限性:
各步骤之间是分离的，但是软件生产过程中各个步骤不能这样严格分离出来；
回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；
最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
瀑布模型的适用范围：
如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；
使用的技术非常成熟，团队成员都很熟悉这些技术。
负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
瀑布模型的变形主要有生鱼片模型、大瀑布带着小瀑布、子瀑布模型等，但每个模型均有其缺陷。
4.渐近交付的流程图如下:
5.敏捷流程的原则:
在软件工程中“敏捷流程”是指一系列价值观与方法论的集合，其与现有的做法对比如图
6. TSP原则
使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
团队的各个成员对团队的目标、角色、产品都有统一的理解；
尽量使用成熟的技术和做法；
尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
增加团队的自我管理能力；
专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
尽早并持续地交付有价值的软件以满足顾客需求；
敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势；
经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
业务人员和开发人员在项目开发过程中应该每天共同工作；
以有进取心的人为项目核心，充分支持信任他们；
无论团队内外，面对面的交流始终是最有效的沟通方式；
可用的软件是衡量项目进展的主要指标；
敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
只有不断关注技术和设计，才能越来越敏捷；
保持简明---尽可能简化工作量的技艺---极为重要；
只有能自我管理的团队才能创造优秀的架构、需求和设计；
时时总结如何提高团队效率，并付诸行动。
7.学习内容的QQ截图
三：在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。
选择2019春季计算机学院软件工程 (北京航空航天大学)
1.团队项目作业发布账号链接
https://www.cnblogs.com/PureMan6/p/10739662.html#4
2.团队项目仓库github链接
https://github.com/swearitagain/EduCnblogs2.0
3. 选择该团队项目进行分析的理由
我和队友大致浏览了软件团队的项目和他们的往期博客作业，发现这个团队的APP功能复杂，设计完整。实现内容较为丰富。
还有这个APP有博客作业提醒功能。感觉比较实用。其次，纵观整个开发过程，这个软件的开发成本还是比较小的，在可以承受的范围之内。再者，开发的软件要面向市场，由于博客园使用的人很多，所以若果完善以后，就会有用户使用。
4.项目团队成员的分工合作情况
每个队员在开工前期都有明确的分工。
5.项目的软件项目过程特点（TSP）
团队秉着独立负责的原则，按TSP原理进行管理，每个成员都要担任一个角色。项目使用了敏捷开发流程，这种开发流程节奏快，效率高，对成员的专业能力要求较高，TSP团队软件过程是为开发软件产品的开发团队提供指导。整个项目过程中，团队每一天都会重新明确分工，完成相应的任务。遵循一个确定的、可重复的过程并迅速获得反馈，这样才能使学习和改革最有成效。注意及时总结经验教训，团队成员始终处于边开发边学习的状态，当学员在项目中面临各种各样的实际问题时，都通过自主学习得以解决。
6.该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
该团队项目github仓库的源代码文件结构里面没有包含代码规范文档。
7.项目最简单直观的使用体验，功能性bug截图。
- 使用体验
系统功能齐全，较重要的功能都得以实现。团队提供了二维码，可以在手机上扫码下载使用，非常方便快捷。这是一大特点。
我用这个APP在查看博客作业截至时间时省时省力，而且一目了然。
博客作业提醒功能对我们非常有用处，以前博客作业只会在快要截截至时通过邮箱发送一份邮件。
软件使用功能截图
- 主界面
- 状态栏消息提醒功能
- 浏览博文页面
- 账号所在班级列表页面展示(每个班级和仓库一样，选择之后整个软件只显示本班级所在的相关信息)：
- 作业提交情况
软件bug
- 软件后台运行一段时间之后会显示身份信息过期，但软件实际上仍然可以正常使用。
- 软件投票功能不稳定(一旦成功发布，则没有办法删除)：
软件页面显示存在问题：
- 提交列表中未显示提交人数。
- 班级列表中一个班级头像不能显示(但是在网页端这两个班级都是有头像的)。
- 仅能显示手机屏幕宽度的内容，缺少一个滑动条(为了对比明显，此功能在暗黑模式下展示,暗黑模式位于设置功能目录下，实现不完整。
8.评价该团队项目是否值得继续开发，并陈述理由。
我觉得该项目值得继续开发。
这是一款功能比较多的APP，虽然还存在一些许的缺陷和不足之处。但是设计复杂，工作做的很足，可见是付出了努力。由于我们能发现不足之处，所以就会有改进的地方。
这个APP涉及博客园这一领域，首先就对我们使用博客园的人就有帮助，这个APP可以满足基本的博文浏览和提交功能，还对博客园本身存在的不便之处添加了一些实际可用的功能，所以可以继续开发完善。
记录完成《实验四 软件项目案例分析》各项任务实际花费的时间。
| 任务 | 耗时 |
|---|---|
| 任务1 | 2h |
| 任务2 | 3h |
| 任务3 | 5h |
| 任务4 | 3h |
实验总结：
本次实验任务中通过测试优秀案例和优秀软件开发项目，让我认识到学习的知识远远不足，自身还存在很多问题。通过学习，对软件团队项目的流程有了一定掌握,有很多开发经验和技术值得学习借鉴。还有学习团队软件项目流程（TSP）以及其它相关概念。对基础知识有了更好的理解。通过测试北京航空航天大学的团队项目案例，感觉他们的项目质量高，团队协作能力强，实现的软件功能复杂，这是值得我们学习的。