| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/ |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 我的课程学习目标 | 学习团队软件项目流程（TSP）、团队成员协作要求；掌握敏捷流程原则及相关概念 |
| 这个作业在哪些方面帮助我实现学习目标 | 学习团队软件项目流程，学习团队案例等方面 |
| 结对方学号-姓名 | 201771010127—王艳 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/JAVA-729/p/12624399.html |
1、实验目的与要求
（1）学习团队软件项目流程（TSP）、团队成员协作要求。
（2）掌握敏捷流程原则及相关概念。
2、实验内容和步骤
任务1：在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价，具体要求如下：
汪慧和&杨野
案例作业博客链接：https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
案例作业项目仓库链接：https://github.com/yy202901582/DieaseSubmitSystem
（1）对案例博文作业进行阅读并进行评论。
（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。
二级防疫部门负责人可输入各自学院筛选查看:
按姓名查询个人情况：
按地区查询：
按有无感染的状态查询：
图标可视化，可以根据出现的字段生成相应的图表：
学院，饼状图和柱状图显示：
师生比：
所在地：
感染情况：
信息填报：
定时提醒：
数据显示：
通过阅读了案例方的代码规范，对每个模块进行了简单介绍，列举了涉及的关键代码和使用的一些方法，还总结了代码规范中命名风格、常量定义以及代码格式的规定，有助于我们在编程时引起重视；将源码从githup克隆后，在自己的电脑上运行，第一次测试时只是重新导入了一下项目中所用的包就顺利完成运行，通过阅读代码，代码编写按照了代码规范中的要求，由于有相应的注释，代码阅读起来也很容易理解；再浏览案例方的博客中的相应说明，更便与理解本次项目中的相应实现的功能，也体会到了在开发此系统的想法与我们小组开发此系统的想法的差异，比如他们实现的定时提醒功能我是通过邮箱的方式，总之通过对比，收获很多。
（3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
案例作业博客链接：https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
案例作业项目仓库链接：https://github.com/yy202901582/DieaseSubmitSystem
软件功能总结：案例方开发的疫情填报系统实现了由学生或者教师填报每日疫情填报、各二级部门疫情防控工作负责人可查看本部门人员疫情汇总、实现了可视化的统计图、按姓名所在地等可以查询具体的情况以及附加功能按定时填报功能；在填报基本信息的模块种除了姓名需要填写之外其他选项都是用下拉框的选择新式，这种的设计节约了填报人的时间，但是在填报时没有学号，在学校由于存在同名同姓的情况，因此由学号或工号唯一标识一名学生或教师会更准确些；在统计图采用了多种方法有饼状图和柱状图很完整，对于定时提醒的功能设计也很不错，但是存在一个bug,就是到时间之后填报人关闭窗口还是会多次提醒，在这个设计上我想要是能有个确认提醒就更完美了；未实现的功能是可【导出】查询列表的EXCEL文件。
填报时没有学号或者工号的填报，无法准确确认是哪一个人，因为存在同名同姓的人，用姓名不易区分。
填报时会显示多次提醒，填报人收到提醒后无法点击确认提醒。
任务2：与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
软件团队的特点
- 团队有一致的集体目标，团队成员要一起完成目标，一个团队的成员不一定要一起工作。
- 团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队的模式
- 蜂窝模式：基于直觉形成的团队模式，是一个欢乐而随意的模式。
- 主治医师模式：各司其职，为主治医师服务。首席程序员，负责主要模块的设计和编码，其他成员从各个角度支持他的工作。
- 明星模式：主治医师模式的极点。简单理解就是首席程序员的最大利益，全部工作都由一个人完成。
- 社区模式：每个人参与自己感兴趣的方向。这种模式的好处是“众人拾柴火焰高”，如果每个人都发挥自己的优势，那么就达到很好的效果。
- 业余剧团模式:每个团队在不同的项目会挑选不同的角色，大家可以平等地讨论。
- 秘密团队：软件项目在秘密条件下进行，别人不知道他们具体做什么。这种模式的好处是团队内部有极大的自由，较高的热情，没有外界的干扰。
- 特工团队：有特殊技能的专业人士，负责解决一些棘手而紧迫的问题。
- 交响乐团模式：交响乐团的演奏模式。当某个软件处于稳定成长的阶段，开发团队就会采取这种模式。
- 爵士乐模式：与交响乐队模式对立。
- 功能团队模式：具备不同能力的人平等协作，共同完成一个功能。
- 官僚模式：几个人报给一个小头目，几个小头目报给一个中头目，依次而上。
瀑布模型及其变形
- 瀑布模型：瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落：
（1）瀑布模型的局限性
- 各步骤之间是分离的，但是在软件产生过程中的步骤不能这样严格分离出来；
- 回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；
- 最终产品知道最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
（2）瀑布模型的适用范围
-
如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
-
产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；
-
使用的技术非常成熟，团队成员都很熟悉这些技术；
-
负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
-
瀑布模型的各种变形
（1）生鱼片模型
这个模型解决了各个步骤之间的分离的缺点，同时也带来了一些困扰究竟什么时候上上一个阶段会结束？
（2）大瀑布带着小瀑布
为了解决不同子系统之间的进度不易，技术要求迥异，需要区别对待的问题，引入了子瀑布模型
渐进交付流程
渐进交付流程是史蒂夫.迈克康奈尔在1996年总结的，但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中：
MVP:Minimal Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。
具体的做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。
MBP:MVP也有它的适用范围，和它相对应的，是Maximal Beautiful Product（最强最美产品，MBP）的思路，如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，为何不把产品最全、最美的形态展现出来，一举征服用户？大家可以回顾第一版的iPhone（2007年）和 iPad（2010），它们是MVP么？显然不是。如何能做到MBP？这对产品团队有更高的要求。
敏捷流程
在软件工程的语境里，敏捷流程是一系列价值观和方法论的集合。
敏捷流程图：
敏捷的步骤：
第一步:找出完成产品需要做的事情一Product Backlog。
Backlog翻译成“积压的工作”、“待解决的问题”、“产品订单”，都可以。产品负责人领导大家对于这个Backlog中的条目进行分析、细化、理清相互关系、估计工作量等工作。每一项工作的时间估计单位为“天”。
第二步:决定当前的冲刺( Sprint )需要解决的事情一Sprint Backlog。
以小时为单位，如果一个任务的估计时间太长(如超过16个小时)，那么它就应该被进一步分解。订单上的任务是团队成员根据自己的情况来认领。如果团队成员能主导任务的估计和分配，他们的能动性会得到较大的发挥。
第三步:冲刺。
冲刺期间，团队通过每日例会(ScrumMeeting)来进行面对面的交流，每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建，让大家每天都能看到一个逐渐完善的版本。
理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则
TSP( 团队软件过程)由美国卡内基梅隆大学软件工程研究所提供，可以帮助软件开发组织建立成熟和纪律性的工程实践，生产安全和可信的软件。TSP支持CMM中的16个关键过程域，在实际应用中取得了良好的效果。实施TSP，是改进软件过程的有效途径之一。TSP作为成熟的软件过程，对产品、项目以及过程本身都有明确的量化指标进行度量，有大量的数据需要收集、整理和分析运算。
- 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
- 团队的各个成员对团队的目标、角色、产品都有统一的理解。
- 尽量使用成熟的技术和做法。
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- 增加团队的自我管理能力。
- 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
这些原则虽然抽象，但是每个团队在做Postmortem的时候（Postmortem是指软件项目结束以后，对产品的回顾以及读开发过程的分析），可以对照检查,看看自已的团队在刚刚过去的软件生命周期中到底提高了多少。
和小伙伴的聊天讨论
任务3：在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。
案例2019春季计算机学院软件工程 (北京航空航天大学)：https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2685
1.团队项目作业发布账号链接：https://www.cnblogs.com/PureMan6/p/11038754.html
2.团队项目仓库github链接：https://github.com/swearitagain/EduCnblogs2.0
3.陈述你选择该团队项目进行分析的理由
在浏览了所有的团队项目之后，最终选择了这款，因为我们本学期这门课就是采用了博客园完成对软件工程的学习，此款博客园app正好给我们带来便利；而且还有一点上学期学习了安卓开发，开发了一款游戏最终的要求也是在手机端运行，正好这次的app也是手机端，可以回顾一下以前的学习，此外就是想体验手机博客园app，看看里面有哪些功能，人家团队是如何实现了，最终在他们身上学习，获取经验。
4.结合项目系列博客文档，总结项目团队成员的分工合作情况；
邵旭哲：PM，主要负责所有博客撰写；
蒋锋，陈治齐，胡俊崧：开发人员；
吴枫：测试人员；
吴昊：开发（任务没有其他开发人员那么多），负责开会。
项目进展过程中，在不同阶段又有不同的分工：
5.结合项目系列博客文档，评价项目的软件项目过程特点（TSP）（5分）；
（1）该软件项目团队首先从管理层了解产品需求和项目目标，随后制定计划来实现这些目标；
（2）团队根据负责具体执行的的角色制定了详细的计划，队员对于项目目标以及产品有人都十分明确；
（3）团队制定了项目计划以及奖罚制度，有助于增加团队的自我管理能力和积极性；
（4）要求每个队员在将自己完成的任务进行测试后再交给下一个队员继续进行工作，这样能够在早期就发现问题并及时改正，不会造成各做各的，最后才发现问题再去弥补的局面。
（5）每一次循环，都以启动阶段开始。在启动阶段，所有成员一起制定策略、过程和完成工作的计划。启动阶段以后，团队按照自己定义的过程完成工作。
TSP作为成熟的软件过程，对产品、项目以及过程本身都有明确的量化指标进行度量，有大量的数据需要收集、整理和分析运算。该软件项目过程特点符合规范要求，也是我们在后期进行团队项目时需要去学习的。
6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？（5分）；
未包含代码规范文档
7.下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图。
登陆之后有三个模块，"我的博客，我的班级和我"
点击“ 我的博客" 可以查看个人博客列表，点击任意作业可以转发、收藏、评论
点击”我的班级”，可以查看公告、作业、博文、还有投票
点击“我”可以查看个人基本信息，还有一些操作
可以设置日程提醒，黑暗模式等
存在的bug1,博客园登录时，点击“记住我”。当退出后重新再次登录时又得重新输入账号和密码，未起到“记住我”的功能。
存在的bug2,登录之后会弹出“身份过期，请重新登录”但是这个才刚刚登录，有效期短暂。
存在的bug3，系统在设置黑暗模式时会自动提示“部分页面不支持”
8.评价该团队项目是否值得继续开发，并陈述理由？
我认为值得继续开发，因为对于我们来说，使用app很方便了解到博客园的相关信息，虽然比起电脑端，手机百度也可以登录博客园，但是由于手机端的博客园界面小，显示了博客园所有的信息，我们要翻阅和查询很久才能找到，比较麻烦。有了这款aap，我们就能随时查看博客园老师发布的相关信息，使用起来超级方便，此外此app中还有日程提醒，只要进行相关的设置后就能再也不用担心忘交作业了,改团队项目的功能对于我们来说是太实用了，只要完善一下存在的bug就更完美。
任务四 《实验四 软件项目案例分析》各项任务实际花费的时间
| 任务 | 耗时 |
|---|---|
| 任务1 | 1h |
| 任务2 | 2h |
| 任务3 | 2h |
| 任务4 | 0.2h |
总结：
通过阅读案例方的博客并运行案例疫情填报系统，体验了案例方的疫情填报系统，与我们小组开发的系统相比较后，有了很深感触；任务二通过和结对伙伴讨论着学习软件开发中的不同的开发流程如：瀑布模型，渐进式交付和敏捷流程、软件团队软件项目流程（TSP）、团队成员协作要求等知识点，我感觉这种交流我对我理解一些不懂的概念有很大的作用，而且效率也高；任务三是我们讨论后基于上学期安卓开发的学习的前提下最终决定做的，通过手机端下载和体验app，对我们很便利；本次实验的完成对我们以后团队的学习有了一定的基础。