| 项目 | 内容 |
|---|---|
| 班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12369881.html |
| 学习目标 | 学习团队软件项目流程、团队成员协作要求；掌握敏捷流程原则及相关概念。 |
| 本作业在哪方面帮我完成学习目标 | 通过进一步和结对同伴的学习，了解自己的不足 |
| 结对方姓名 | 201771030113-李志龙 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/zhilong12/p/12676729.html |
一.实验三得分100分以上作业中，选一案例进行评价
1：实验三优秀案例推荐：张芹&李佩杉组
（1）该组项目仓库链接
（2）该组博客作业链接-张芹 该组博客作业链接-李佩杉
（3）评论截图
2：体验案例项目源码，总结问题，体会案例博文。
（1）clone案例源码到本地机器
（2）阅读项目代码规范文档如下。
（3）运行代码。
①用户登陆
②打卡上报
③二级部门登陆
④二级部门查询
⑤生成柱状图
⑥防控办登陆
⑦防控办查询
生成柱状图及导出Excel
(4)运行案例项目代码总结
经过一段时间的测试，该软件除了不能修改和删除信息以外，其他功能都很完善，程序也有提醒的功能，但是必须报出软件一直打开才可以；源代码符合提交的代码规范，注释也很清晰明了；但导出Excel部分好像有点问题，虽然现实已经导出Excel，但我在我的硬盘中没有找到；
总体来说这个软件是比较成功的。
（5）实验三不足之处
没有用户信息的修改和删除功能，导出的Excel文件没有找到，界面较为简陋。
二.协作学习：阅读《现代软件工程—构建之法》第5-6章内容
1.理解并掌握软件项目团队的特点
（1）. 团队有一致的集体目标，团队要一起完成这个目标。
（2）. 团队成员有各自的分工，互相依赖合作，共同完成任务。
2. 软件团队的模式
（1）. 一窝蜂模式：最初的十分随意的软件团队模式，经过一段时间的演变将转变为后续的其他模式；
（2）. 主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
（3）. 明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
（4）. 社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
（5）. 业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
（6）. 秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
（7）. 特工团队：团队由专业人士组成，负责一些紧急问题的解决（如此次新冠疫情）；
（8）. 交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
（9）. 爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
（10）. 功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
（11）. 官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
3. 瀑布模型及其变形
瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。
瀑布模型产品遵循 [分析→设计→实现（制造）→销售→维护] 这一流程，其描述了单项的、不可逆的生产过程。由于严格的瀑布模型存在诸多缺陷，因此温斯顿提出了对瀑布模型的改进如图,他提出了相邻步骤间的回溯与模型的再运行以收集反馈进行产品改进.
瀑布模型主要适用于以下情况：
（1）. 如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
（2）. 产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；
（3）. 使用的技术非常成熟，团队成员都很熟悉这些技术。
（4）. 负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
4.渐进交付流程
渐进交付流程由史蒂夫·迈克康奈尔与1996年总结，较接近于迭代式开发流程。其主要指当系统的主要需求和架构明确后，软件团队将进入如图所示的循环中，该循环将一直进行直至项目的资金不足、项目时间不够或产品能使用户满意为止。
5.敏捷流程
敏捷流程遵循以下开发原则：
（1）. 尽早并持续地交付有价值的软件以满足顾客需求；
（2）. 敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势；
（3）. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
（4）. 业务人员和开发人员在项目开发过程中应该每天共同工作；
（5）. 以有进取心的人为项目核心，充分支持信任他们；
（6）. 无论团队内外，面对面的交流始终是最有效的沟通方式；
（7）. 可用的软件是衡量项目进展的主要指标；
（8）. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
（9）. 只有不断关注技术和设计，才能越来越敏捷；
（10）. 保持简明————尽可能简化工作量的技艺————极为重要；
（11）. 只有能自我管理的团队才能创造优秀的架构、需求和设计；
（12）. 时时总结如何提高团队效率，并付诸行动。
6..理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则
TSP原则主要有以下七点：
（1）. 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的
（2）. 团队的各个成员对团队的目标、角色、产品都有统一的理解；
（3）. 尽量使用成熟的技术和做法；
（4）. 尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
（5）. 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
（6）. 增加团队的自我管理能力；
（7）. 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
7.讨论截图展示
三.选取一院校团队项目测试分析
1.选取北京航空航天大学2019春季计算机学院软件工程的PureMan团队项目
（1）该组博客园链接
（2）github仓库链接
（3）选择该团队项目分析的理由
首先想看看名校学生做的项目到底怎么样，我们之间的差距到底有多大，其次呢，我移动端的知识比较薄弱，希望能从中学习，提高自己。最后，移动端的博客园很方便，在以后的学习中经常可以用到。
2.总结该团队成员分工合作情况
PureMan6的团队总共有7个人,七个人分工各不相同，有两个PM和PM测试人员，有四个开发员，还有一个软件测试人员。
PureMan6开发人员负责实现客户端的功能，界面。其他人主要需要调用博客园提供的API，配合一些组件，来实现功能。最开始的分工是大家各自负责自己的功能，然后在例会上交流遇到的障碍或者取得进度，确定把功能加入哪里，保证大家大家UI的统一，同时也有两位开发定期统一所有的界面和美化。测试人员负责完成客户端的兼容性测试、压力测试，各个功能的集成测试。项目经理负责完成各种文档，组织开会，安排任务推进项目，与相关人员沟通，做调研，推广。
3.评价项目的软件项目过程特点（TSP）
该团队写了几十篇博客文档，虽然没有明说，但我看出来该团队应该使用了功能团队模式，每个成员都有自己的角色，对自己所要开发的产品有一个共识。而且团队在研发期间不断地收集数据和用户反馈，进一步对产品进行改进。关于项目流程，都是RUP统一流程，而且该团队每个阶段几乎都有例会。
4.该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
有代码规范，而且还有其他各种说明文档，如图所示
5.下载团队项目代码，尝试部署并使用，描述使用体验，找出至少两个功能性bug
存在的问题
一些机型无法使用黑夜模式，应该是软件没有更新的缘故吧
手机端没有渲染
6.评价该团队项目是否值得继续开发，并陈述理由？
非常值得继续开发，该软件已经可以投入使用，对于我来说，极大地方便了我在没有电脑的情况下也能浏览我的博客。这款app它可以满足我们在手机端查看博客以及评论等功能，我觉得只要有需求，就值得继续开发。
四.《实验四 软件项目案例分析》各项任务实际花费的时间
| 任务 | 花费时间(h) |
|---|---|
| 任务一 | 4.0 |
| 任务二 | 7.0 |
| 任务三 | 12.5 |
| 任务四 | 1.5 |
五.感受与体会
通过这次自主学习和同伴之间的相帮助，我发现我还有很多不足的地方，对比起名校的学生，我还差的很远很远，今后我应该沉下心来，学好技术。
其次，通过学教材的知识，掌握了喝多开发的流程模式和方法，这对我以后的项目有很大的帮助。