| 项目 | 内容 |
| ---- | ---- | ---- |
| 课程班级博客链接 | 班级博客 |
| 这个作业要求链接 | 作业要求 |
| 团队名称 | 永远的Ace |
| 团队的课程学习目标 | （1）找出上次作业完成的好的小组，学习借鉴并且评价。（2）学会组建软件项目研发团队。（3）在团队交流群中，共同探讨团队创建相关事宜。 |
| 这个作业在哪些方面帮助团队实现学习目标 | （1）浏览优秀作业，弥补自己的不足。（2）学会团队协作完成项目，在团队协作过程中增强自己的弱势，发扬自己的长处。（3）创建了团队交流群，为以后开展工作更加方便。 |
| 团队博客链接 |团队博客 |
博客正文
任务1：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成以下任务，具体要求如下：
（1）对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
（2）克隆任务3项目源码到本地机器，阅读并运行代码，找出项目代码的5个以上bug，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
（3）阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
C. 从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
（4）经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
（5）结合（1）—（3）的评论体会，迭代改进本小组实验三任务3。1、被评论作业的博客链接 ：评论链接
2、评论仓库链接
3、博客评论截图：
4、代码复审核查表：
- 5个Bug:
- 功能不完善，部分功能未实现。
- 异常处理遗漏，处理不正。
- 更新环境验证问题。
- 算法求解过程时间有点长，用户体验不好。
- 代码可进一步加以优化，增强可读性。
| 内容 | 结果 |
| ---- | ---- | ---- |
| 概要部分 | |
| 代码能符合需求和规格说明么？ | 基本符合 |
| 代码设计是否有周全的考虑？ | 大体功能实现，部分功能为实现 |
| 代码可读性如何？ | 可读性较好 |
| 代码容易维护么？ | 可维护性较好 |
| 代码的每一行都执行并检查过了吗？ | 检查过 |
| 设计规范部分 | |
| 设计是否遵从已知的设计模式或项目中常用的模式？ | 已遵从 |
| 有没有硬编码或字符串/数字等存在？ | 不存在 |
| 代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）？ | 不会 |
| 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？ | 可以 |
| 在本项目中是否存在类似的功能可以调用而不用全部重新实现？ | 可以 |
| 有没有无用的代码可以清除？ | 存在部分 |
| 代码规范部分 | |
| 修改的部分符合代码标准和风格么（详细条文略）? | 符合 |
| 具体代码部分 | |
| 有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？ | 已检查并处理 |
| 参数传递有无错误 | 无 |
| 边界条件是如何处理的？Switch语句的Default是如何处理的？循环有没有可能出现死循环？ | 没有 |
| 有没有使用断言（Assert）来保证我们认为不变的条件真的满足？ | 没有 |
| 有没有可能优化？ | 有 |
| 数据结构中是否有无用的元素？ | 否 |
| 效能 | |
| 代码的效能（Performance）如何？最坏的情况是怎样的？ | 整体较好 |
| 代码中，特别是循环中是否有明显可优化的部分？ | 没有|
| 对于系统和网络调用是否会超时？如何处理? | 否 |
| 可读性 | |
| 代码可读性如何？ | 可读性良好 |
| 可测试性 | |
| 代码是否需要更新或创建新的单元测试？ | 不需要 |
5、符合（3）要求总结：
- A：软件的使用过程：
动态规划求解：
回溯法求解： - B:任务3软件的基本功能都实现了，软件使用过程中，数据基本合适，功能比较完善，界面简洁美观，如果在功能实现方面更加完善一点就会更好。
- C：本软件产品所适用的用户应该是计算机专业大学生或者与从事相应专业的人群，表面需求是完成某项学习或者工作中的任务，潜在需求是对产品不熟悉，对产品的功能还不太满足。
6、符合（4）要求结论 - （d 好，不错。
阅读了《构建之法》的5-6章：
| 内容 | 解释 |
| ---- | ---- | ---- |
| 团队的特点 | 1.团队有一致的集体目标，团队要一起完成这个目标。一个团队的成员不一定要同时工作。2.团队成员有各自的分工，互相依赖合作，共同完成任务。 |
| 软件团队的模式 | |
| 主治医师模式 | 首席程序员“主刀”（负责处理主要模块的设计和编码），其他成员“为主刀医师服务”（从各种角度支持他的工作）。 |
| 明星模式 | 主治医生模式运用到极致，可以蜕化为明星模式。 |
| 社区模式 | 社区很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。 |
| 业余剧团模式 | 个人在团队中听从一个中央指挥的指导和安排。 |
| 秘密团队 | 软件团队进行一些秘密的软件项目。 |
| 特工团队 | 软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而紧迫性的问题。 |
|交响乐团模式 |家伙多，门类齐全；各司其职，各自有专门场地，演奏期间没有聊天、走动等现象；演奏都靠谱，同时看指挥的；演奏的都是练习过多次的曲目，重在执行。 |
| 爵士乐模式 | 不靠谱；没有现场指挥；人数较少。 |
|功能团队模式 | 具备不同能力的同事们平等协作，共同完成一个功能。 |
| 官僚模式 | 几个人报告给一个小头目，几个小头目报告给中头目，依次而上。 |
感受和体会：
本次作业通过分析测试上一次实验的高分同学的博文作业及代码，发现同样的作业要求相比较下自己的和别人的差距，从别人的作业里学习到自己不会的东西，收获很多；其次，阅读了《构建之法》的5-6章，学习软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，以及TSP原则；最后通过测试其他高校的软件工程团队项目与博客阅读学习，更加深刻的学习团队软件项目过程的特点，收获了很多，同时认识到自己的不足，以后需要更加努力。
