| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/2018CST |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/14660499.html |
| 团队名称 | The Superego |
| 团队课程学习目标 | 1.思维方面，有利于构建软件项目合作意识。 2.学习经验方面，学会如何去完成结对软件项目。 |
| 这个作业在哪些方面帮助团队实现学习目标 | 1.熟悉软件项目结对合作开发流程，并开发出本次软件项目。 2.通过阅读完成质量较高的项目小组的代码，了解其思想，进行代码复审，进而提高自身能力。 |
| 团队博客链接 | 团队博客链接 |
实验内容
任务一：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成以下任务，具体要求如下：
- 对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
- 克隆任务3项目源码到本地机器，阅读并运行代码，找出项目代码的5个以上bug，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
- 项目克隆
- BUG总结
1.绘制散点图更新不及时，有浏览器缓存
2.回溯算法求解过程太长，用户体验不是很友好
3.没有算法测评报错信息，用户提交成功后需要长时间等待
4.在无工作人员的介绍下，用户不能轻松的运行其该项目
5.算法求解时间过长，时间复杂度高 - 代码核查表如下：
- 项目克隆
| 复审内容 | 复审结果 |
|---|---|
| 1.概要部分 | |
| 代码符合需求和规格说明么？ | 基本符合 |
| 代码设计是否考虑周全？ | 考虑周全 |
| 代码可读性如何？ | 采用了优秀的设计框架，代码可读性好。 |
| 代码容易维护么？ | 对于不同的功能模块，分别存储在不同的类中，维护较为容易。 |
| 代码的每一行都执行并检查过了吗？ | 是的 |
| 2.设计规范部分 | |
| 设计是否遵从已知的设计模式或项目中常用的模式？ | 采用了MVC设计模式 |
| 有没有硬编码或字符串/数字等存在？ | 无 |
| 代码有没有依赖于某一平台，是否会影响将来的移植？ | 否 |
| 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？ | 能 |
| 有没有无用的代码可以清除? | 没有 |
| 3.代码规范部分 | |
| 修改的部分符合代码标准和风格吗？ | 符合规范 |
| 4.具体代码部分 | |
| 有没有对错误进行处理?对于调用的外部函数，是否检查了返回值或处理了异常? | 没有处理异常值 |
| 参数传递有无错误,字符串的长度是字节的长度还是字符(可能是单/双字节)的长度是以0开始计数还是以1开始计数? | 没有 |
| 边界条件是如何处理的? switch语句的default分支是如何处理的?循环有没有可能出现死循环? | 未使用switch语句；循环不会出现死循环。 |
| 有没有使用断言（ Assert）来保证我们认为不变的条件真的得到满足? | 未使用断言。 |
| 数据结构中有没有用不到的元素? | 有 |
| 5.效能 | |
| 代码的效能（Performance）如何?最坏的情况是怎样的? | 运行效率较低。 |
| 代码中，特别是循环中是否有明显可优化的部分(C++中反复创建类，C#中 string的操作是否能用StringBuilder来优化）? | 无 |
| 对于系统和网络的调用是否会超时?如何处理? | 没有对网络的调用 |
| 6.可读性 | |
| 代码可读性如何?有没有足够的注释? | 关键语句都有注释，可读性高 |
| 7.可测试性 | |
| 代码是否需要更新或创建新的单元测试? | 不需要 |
- 阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
-
A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
a.绘制散点图
b.回溯法求解
c.动态规划求解
d.动态测评
-
B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
a.基本解决了。
b.优缺点如下：
1）数据量：可对任意一个数据集都可以实现相关要求；
2）界面：区分了四个功能模块，但界面美观程序还有待加强；
3）功能：基本功能基本实现，但对于算法部分还有待提高。
c.改进意见：对于遗传算法的实现还有待优化，前端页面的人机交互还有待加强，对于该项目使用的Spring boots框架，只使用了其中一点点的特性，在后续的学习中还要好好学习研究。 -
C. 从职业、学历、年龄、专业、爱好、收入等方面概括实验三任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
a.职业:学生或相关算法研究人员
b.学历:本科及以上
c.年龄:15岁以上
d.专业:与算法设计相关的专业
e.爱好:编程、算法
f.收入:不限
g.表面需求:D{0-1}算法求解以及可视化分析
h.潜在需求:回溯算法、动态规划算法以及遗传算法的对比分析
-
- 给评价作业选择一个结论:
- d) 好，不错，此次核查评论的过程也给予了我很大的启发。
- 结合评论体会，迭代改进本小组实验三的任务3。
- 已对任务三进行改进。
任务二：团队组建
-
在实验三结对基础上，结对小组两两自由组合，组建软件项目研发团队
- 已根据小组情况，与陈来弟、公海瑜组建了软件项目研发团队。
-
申请开通团队博客，点击链接提交团队信息，将团队博客加入到班级博客
- 已开通团队博客并加入到了班级博客，团队信息已提交，详情可点击这里在团队博客中查看。
-
阅读《现代软件工程—构建之法》第5章内容
-
团队模式的几种形式
1.一窝蜂模式：最初的一窝蜂形式的软件团队模式，经过一段时间的演变将转变为其他模式；
2.主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
3.明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
4.社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
5.业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
6.秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
7.特工团队：团队由专业人士组成，负责一些紧急问题的解决；
8.交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
9.爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
10.功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
11.官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。 -
瀑布模型及其各种变形
1、瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。
2、瀑布模型的变形有生鱼片模型和大瀑布带着小瀑布。
a.生鱼片模型
b.大瀑布带着小瀑布
-
渐进交付流程
渐进交付流程是 Steve McConnell 在1996 年总结的，但是它其实已经很接近现在大家谈论的比较多的迭代式开发流程。在系统的主要需求和架构明确之后, 软件团队进入了一个不断变化的evolution 循环中: [开发 -> 发布 -> 听取反馈 -> 根据反馈做改进 ]
-
TSP原则：
1.使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
2.团队的各个成员对团队的目标、角色、产品都有统一的理解；
3.尽量使用成熟的技术和做法；
4.尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
5.制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
6.增加团队的自我管理能力；
7.专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
-
-
感受和体会:在本次作业中，我选择了李岩松小组项目成果进行测试、复审，他们这组的作业代码功能实现的完整性比较高。所以于我而言此次复审的过程就是一个学习的过程，让我充分认识到了自己的不足，也更加意识到应该多向优秀的同学看齐。在阅读《构建之法》这本书时，我了解到了什么是团队和非团队、TSP原则，以及绩效管理等各种关于团队的内容，使我受益颇多。本次组建团队的过程中，我们也是费了一定的功夫，我们意识到组建一个合适的团队不仅要考虑各成员的学习能力，还要考虑对方性格方面是否适合、学习态度是否端正等多方面因素。本次组建团队之后，也让我更加下定决心要在之后的学习中多提升自己的能力，成为一个对自己有用、对团队有用、对社会有用的人。