201772020113-李清华 实验四 软件项目案例分析
| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/ |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 我的课程学习目标 | 学习团队软件项目流程（TSP）、团队成员协作要求。掌握敏捷流程原则及相关概念。 |
| 这个作业在哪方面帮助我实现学习目标 | 通过学习别人的结对项目来提高自己，理解瀑布模型及了解结对开发的好处 |
| 结对方姓名-学号 | 赵栋-201771010 |
| 结对方本次博客作业链接 | |
| 1、实验目的与要求 | |
| （1）学习团队软件项目流程（TSP）、团队成员协作要求。 | |
| （2）掌握敏捷流程原则及相关概念。 | |
| 2、实验内容和步骤 | |
| 任务一： | |
| 在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价，具体要求如下： | |
| （1）对案例博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。 | |
| （2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。 | |
| （3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。 | |
| 1.案例作业博客链接 | |
| 2.案例作业项目仓库链接 | |
| 3.符合（1）要求的博客评论 | |
 |
|
| 4.符合（2）要求的系统运行截图、软件功能总结 | |
| 导入项目时由于环境不同，不熟悉这个开发工具，解决了很多报错但是这个错误暂时还无法解决： | |
 |
|
| 代码我没看出来什么问题，作者的博文有助于代码理解。项目源码中也有关键注释。 | |
| 5.符合（3）要求的总结，代码运行存在的问题截图为证 | |
| 任务二： | |
| 与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则； | |
| 由于没能联系上结对伙伴，所以后面部分由我单独完成。 | |
 |
软件项目团队的特点:
（1）团队有一致的集体目标,团队要一起完成这个目标。
（2）团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队的模式:
（1）主治医师模式：有一个首席程序员，其他成员从各种角度支持他的工作。
（2）明星模式：主治医师模式运用到极点蜕化为明星模式，关键在于让团队利益最大化而不是明星利益最大化，在于明星陨落后团队的价值依然能够保持。
（3）社区模式：由很多志愿者参与，大部分人不拿报酬，一些成功的社区项目都有很严格的代码复审和签入的质量控制。
（4）业余剧团模式：这样的团队在每一个项目中，不同的人会挑选不同的角色。这些人也许会换一个完全不同的角色类型，各人在团队中听从一个中央指挥的指导和安排。
（5）秘密团队：项目在秘密状态下进行，团队内部有极大的自由，往往能完成看似不可能的任务。
（6）特工团队：由一些具有特殊技能的专业人士组成，一出手就能解决难题。
（7）交响乐团模式：当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式。
（8）爵士乐模式：和“交响乐团模式”在很多方面都对立，但是两种模式都各有优势。
（9）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。这个功能完成后这些人又重新组织，和别的角色一起去完成下一个功能。
（10）官僚模式：层层领导的模式，这种模式会有官僚主义的隐患。
瀑布模型及其变形:
原始的瀑布模型描述了单向的，不可逆的生产过程。这种模型直接运用于软件工程会有各种缺陷。温斯顿提出了瀑布模型的改进办法，例如在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题。如图所示。
温斯顿又指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本，在此基础上收集反馈，改进各个步骤并交付一个最终的版本。
为了解决瀑布模型的问题，在实践中又产生了许多变形：
（1）生鱼片模型：各相邻模块像生鱼片那样部分重叠。
（2）子瀑布模型：为了解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题。要把各个子系统统一到最后做系统测试的阶段，难度很大。而且用户只有到了最后才能看到结果。
渐进交付流程、敏捷流程等典型软件过程模型特点:
渐进交付流程有两个特点：MVP和MBP。MVP是最小可行产品，把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。MBP是最强最美产品，把产品最全最美的形态展现出来一举征服用户。这对团队有很高的要求。
与传统开发方法相比，在敏捷开发的整个过程中，有以下几个主要的特点：
（1）敏捷开发的过程有着更强的适应性而不是预设性。
（2）敏捷开发的过程中，更加的注重人的因素。
（3）在敏捷开发的过程中，整个项目是测试驱动的而不是文档驱动的。
卡内基梅隆大学（CMU）软件工程学院总结的TSP原则：
（1）使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
（2）团队的各个成员对团队的目标、角色、产品都有统一的理解。
（3）尽量使用成熟的技术和做法。
（4）尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
（5）制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
（6）增加团队的自我管理能力。
（7）专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
任务三：
在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。
- 2016级计算机科学与工程学院软件工程 (西北师范大学)
- 2019秋福大软件工程实践Z班 (福州大学)
- 2019春季计算机学院软件工程 (北京航空航天大学)
这里我选择3.2019春季计算机学院软件工程 (北京航空航天大学)
1.团队项目作业发布账号链接
2.团队项目仓库github链接
3.陈述你选择该团队项目进行分析的理由。
该团队开发的是博客园APP续写，开发项目比较实用，采用的开发语言和开发工具我也相对比较熟悉，可以通过跟踪分析他们开发过程中遇到的问题来提高自己。
4.结合项目系列博客文档，总结项目团队成员的分工合作情况。
该项目团队PM（产品经理）2人（其中一人兼任测试），开发 3人，测试 2人。总体来看，他们的分工较为明确，而且团队成员能力都不错，对开发进度的把控都很好，经常会有会议来总结、讨论开发进度以及开发过程中遇到的困难。
5.结合项目系列博客文档，评价项目的软件项目过程特点（TSP）
该团队采用了交响乐团模式，软件迭代稳定，团队内部经常有交流，团队自我管理能力比较好。团队从一开始就制定了切合实际的计划和承诺，团队的各个成员对团队的目标、角色、产品都有统一的理解，使用了成熟的技术和做法，并且对数据进行了尽可能多的收集。
6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
该团队项目github仓库里没有包含代码规范文档。
7.下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图。
软件界面：
软件使用体验良好，UI设计和交互都比较美观友好，功能比较实用，但很多细节可以继续改进优化。
该软件暂未发现严重的功能bug。但是有个很影响体验的就是黑暗模式打开博文后就不渲染了，而且在进行黑暗模式的切换时底下的功能按钮会变浅色。
8.评价该团队项目是否值得继续开发，并陈述理由？
该团队项目值得继续开发。因为这是一个很实用的项目，对于经常使用博客园的用户来说有一款功能强大的博客园手机APP再好不过了。可以继续改进界面设计，对里面的功能进一步完善，例如可以做到和PC网页版几乎相同的功能等等。有bug的地方还需要修改。
3、《实验四 软件项目案例分析》各项任务实际花费的时间
| 内容 | 计划时间（min） | 实际完成时间（min） |
|---|---|---|
| 任务一 | 120 | 240 |
| 任务二 | 120 | 120 |
| 任务三 | 480 | 480 |
| 4、感受和体会 | ||
| 本次实验完成的不是很好，主要是自己基础不行，导致很多问题需要花费大量时间上网查阅资料解决。阅读代码也比较吃力。但在实验的过程中也有收获，巩固了理论课所学的知识，同时也看到了自己的知识水平还很差，离案例的水平还很远。希望自己能够继续努力。 |
