201871010130-周学铭 实验四 团队作业1：软件研发团队组建
| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | 18卓越班 |
| 这个作业要求链接 | 实验四 团队作业1 |
| 团队名称 | 卡其脱离太 |
| 团队的课程学习目标 | 1.实验三作业互评。 2.组建软件项目研发团队。 |
| 这个作业在哪些方面帮助团队实现学习目标 | 1.通过作业的点评，以及clone运行等，可以更好地掌握到结对编程以及代码复审等环节的重要性。 |
| 团队博客链接 | 卡其脱离太 |
（1）对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
- 被评论的同学：
| 被评论同学 | 201871030102_崔红梅 |
|---|---|
| 被评论作业的博客链接 | 201871030102_崔红梅 实验三 结对项目—《D{0-1}KP 实例数据集算法实验平台》项目报告 |
| 被评论作业的仓库链接 | shiyan3 |
- 评论内容：
| 要求 | 内容 |
|---|---|
| 博文结构 | 博文结构划分合理，排版整洁，错落有致，具有段落感。同时 ，对于一些重要的点，都用列表或者表格的方式进行了表示，具有观看体验。 |
| 博文内容 | 博文内容充实： 1.对于任务一：指出了《现代软件工程—构建之法》第四章的四个重点，并进行了精简的概括，突出了重点。 2.对于任务二：对结对方的评论中肯有价值，代码核查认真负责。 3.对于任务三：采用了优秀的设计框架，对任务的分离做的较为优秀。同时界面美观，基本完成了数据库连接以及对实验二的迭代开发。截图较为完善，可以感受到你们对这次实验完成的极为认真。 |
| 博文结构与PSP中“任务内容”列的关系 | 博主的博文撰写流程是按照PSP的主要流程一步一步走下来的，具有较好的整体构思。 |
| PSP的差异化分析与原因探究 | 博主PSP实际完成时间大约是计划时间的两倍，差距过大。主要问题是出现在对实验二进行可视化图形界面迭代的过程中，原因可能是对该框架不熟悉，后面还需要好好学习，提高开发效率。 |
| 建议 | 对于任务二：最好还是能够将结对方程序的运行截图(主要是目前对方程序的一些不足之处)贴出来，并加以指正迭代。 对于任务三： 1.最好能做一下软件设计的说明，比如用到了哪些技术，具有什么样的优缺点等。 2.需要在github仓库中补交sql文件，不然项目无法运行。 3.对于遗传算法的实现还有待优化。 4.前端页面的人机交互还有待加强。 |
（2）克隆任务3项目源码到本地机器，阅读并运行代码，找出项目代码的5个以上bug，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
-
项目克隆：
-
项目运行：
-
代码审查表：
| 说明 | 内容 |
|---|---|
| 概要部分 | |
| 代码符合需求和规格说明么？ | 基本符合，但部分功能完成度较差。 |
| 代码设计是否考虑周全？ | 考虑周全 |
| 代码可读性如何？ | 采用了优秀的设计框架，代码可读性好。 |
| 代码容易维护么？ | 对于不同的功能模块，分别存储在不同的类中，维护较为容易。 |
| 代码的每一行都执行并检查过了吗？ | 是的 |
| 设计规范部分 | |
| 设计是否遵从已知的设计模式或项目中常用的模式？ | 采用了MVC设计模式 |
| 有没有硬编码或字符串/数字等存在？ | 没有，采用的都是符合命名规范的变量名 |
| 代码有没有依赖于某一平台，是否会影响将来的移植？ | 没有 |
| 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？ | 能调用 |
| 有没有无用的代码可以清除? | 没有 |
| 代码规范部分 | |
| 修改的部分符合代码标准和风格吗？ | 符合规范 |
| 具体代码部分 | |
| 有没有对错误进行处理?对于调用的外部函数，是否检查了返回值或处理了异常? | 没有处理异常值 |
| 参数传递有无错误,字符串的长度是字节的长度还是字符(可能是单/双字节)的长度是以0开始计数还是以1开始计数? | 没有 |
| 边界条件是如何处理的? switch语句的default分支是如何处理的?循环有没有可能出现死循环? | 采用哨兵处理边界；没有使用switch语句；循环不会出现死循环。 |
| 有没有使用断言（ Assert）来保证我们认为不变的条件真的得到满足? | 程序较为简单，所以没有使用断言。 |
| 数据结构中有没有用不到的元素? | 有 |
| 效能 | |
| 代码的效能（Performance）如何?最坏的情况是怎样的? | 运行效率较低。 |
| 代码中，特别是循环中是否有明显可优化的部分(C++中反复创建类，C#中 string的操作是否能用StringBuilder来优化）? | 无 |
| 对于系统和网络的调用是否会超时?如何处理? | 没有对网络的调用 |
| 可读性 | |
| 代码可读性如何?有没有足够的注释? | 关键语句都有注释，可读性高 |
| 可测试性 | |
| 代码是否需要更新或创建新的单元测试? | 不需要 |
- BUG汇总：
| BUG说明 | 建议 |
|---|---|
| BUG1:没有创建index文件并进行相关配置，导致无法直接进入index界面) | 建议完善Index文件，这样只需要输入IP地址以及端口号就可以进入其主界面了，并且需要设置拦截除主界面外随意进入其他界面(路由转发)。 |
| BUG2:进行数据存储操作后，没有跳出相关的提示，无任何变化，只有查看数据库才知道数据存储了数据 | 建议增加几个提示语句 |
| BUG3:必须手动输入文件名、组数等信息 | 建议可以制作一个下拉框，这样可以方便用户选择，而不会因为输入错误而无法执行 |
| BUG4:运行后，文本框的数据会消失，且没有进行错误处理 | 需要进一步完善 |
| BUG5:遗传算法未完全实现 | 还需要好好学习遗传算法的相关知识 |
（3）阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
-
A：体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片：
-
新导入的数据库文件：此时表格数据为空。
-
项目主界面：(BUG1:没有创建index文件并进行相关配置，导致无法直接进入index界面)
- 查询源代码，手动输入相关网站进入主界面：
- 查询源代码，手动输入相关网站进入主界面：
-
数据存储：(BUG2:进行数据存储操作后，没有跳出相关的提示，无任何变化，只有查看数据库才知道数据存储了数据)
-
散点图绘制：(BUG3:该BUG后面几个页面都有，即必须手动输入文件名、组数等信息，建议可以制作一个下拉框，这样可以方便用户选择，而不会因为输入错误而无法执行。同时这里没有进行错误处理。)
- 输入符合规定的数据(文件名：idkp1-10.txt；组数：3)
- 输入无效数据
- 输入符合规定的数据(文件名：idkp1-10.txt；组数：3)
-
数据排序：
-
算法求解：
- 输入相关数据：
- 运行求解：(BUG4:运行后，文本框的数据会消失)
- (BUG5:遗传算法未完全实现)
- 输入相关数据：
-
-
B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
- 实现部分：该组对于任务3要求的功能软件基本上解决了，包括迭代了实验二的基础功能；数据库存储；GUI界面。
- 待完善部分：针对于遗传算法，该组同学的完成度不高。
| 项目评价 | 优点 | 缺点 |
|---|---|---|
| 数据量 | 对任意一个数据集都可以实现相关要求 | 无 |
| 界面 | 区分了四个功能模块 | 界面美观程序还有待加强，最好能用一些成熟的前端UI框架 |
| 功能 | 基本功能基本实现 | 但对于算法部分还有待提高 |
改进意见：对于遗传算法的实现还有待优化，前端页面的人机交互还有待加强，对于该项目使用的Spring boots框架，只使用了其中一点点的特性，在后续的学习中还要好好学习研究。
- C. 从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
| 职业 | 学历 | 年龄 | 专业 | 爱好 | 收入 | 表面需求 | 潜在需求 |
|---|---|---|---|---|---|---|---|
| 学生或相关算法研究人员 | 本科及以上(或者一些相关爱好者，如OI选手等) | 13~45 | 与算法设计相关的专业 | 算法爱好者 | 不限 | D{0-1}算法求解以及可视化分析 | 回溯算法、动态规划算法以及遗传算法的对比分析 |
（4）经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
结论：(d):好，不错
基本功能基本都已实现，但是页面的布局以及算法的实现等方面还有待进步。
（5）结合（1）—（3）的评论体会，迭代改进本小组实验三任务3。
-
项目迭代：
- 仓库链接：https://github.com/1094493924/knapsack
- 针对BUG1：实现了路由转发。
- 针对BUG2：存储完成后，有信息提示。
- 针对BUG3：实现一个提示框。
- 针对BUG4：进行错误提示。
- 针对BUG5：遗传算法的实现。
-
提交记录：
-
提交记录
-
创建分支以及合并
-
阅读《现代软件工程—构建之法》第7章、第17章，理解MSF的9点基本原则和团队成员绩效
- MSF的9点基本原则：
- 推动信息共享与沟通（Foster open communications）
- 所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到的技术机密、安全性等信息要采取必要的保护措施
- 为共同的远景而工作（Work toward a shared vision）
- 这个目标必须是明确的，没有二义性；这个目标不是当前就能达到，必须是通过努力才能达到的；这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情对项目的远景没有帮助，你应该和老板提出来。
- 充分授权和信任（Empower team members）
- 平等协作---成员之间、团队之间是平等协作的关系；充分授权给团队和成员。
- 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
- 无责任的旁观者和有重大责任的当局者的看法自然是不一样的。对此事负责的角色要自己拿主意。
- 重视商业价值（Focus on delivering business value）
- 如果你还没有能说清楚你的产品解决了什么问题，为谁解决问题，为什么你的产品会解决这些问题，以及客户怎样付钱让你解决问题，那你就不应该贸然创业。
- 保持敏捷，预期变化（Stay agile,expect change）
- 软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一-时刻很明确，然后保持不会变。但要注意，我们是预期变化，不是期望变化。
- 投资质量（Invest in quality）
- 不是质量第一，而是解决用户的问题第一。
- 学习所有的经验（Learn from all experiences）
- 把经验总结出来；分享经验。是为了：让团队成员从别人的成果和失败的例子中学到东西；帮助新项目重复以往成功的做法；培育团队总结的习惯和“批评与自我批评”的文化。
- 与顾客合作（Partner with internal and external customers )
- MSF强调产品团队与顾客的交流与合作，并不是产品团队拿到合同之后，就闭门造车，直到产品完成才告诉用户，给他们一个惊喜。
- 推动信息共享与沟通（Foster open communications）
阅读《现代软件工程—构建之法》第5章内容
-
5.1 非团队和团队
- 团队与非团队的区别是什么？
- （1）团队是一群志同道合的人聚集在一起专注于某一件事，互相鼓励，不离不弃，具有“契约精神”；
- （2）非团队是一群乌合之众，可以随时一拍而散，各自行动，对其他人不理不顾，只在乎自己利益最大化，不在乎是否会影响其他人。
- 团队与非团队的区别是什么？
-
5.2 软件团队的模式
- 主治医师模式(Chief Programmer Team, Surgical Team)
- 就像在手术台，上那样，有一个主刀医师，其他人(麻醉，护士，器械)各司其职，为主刀医师服务。这样的软件团队中，有首席程序员(Chief Programmer)，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。佛瑞德.布鲁克斯在主管IBM System 360项目时就采用了这种模式。
- 明星模式(Super-star Model)
- 主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，迈克尔.乔丹说过，“Talent wins games, teamwork wins championship."一些摇滚乐团的团队成员个性非常突出，团队时时都处于解体的边缘。
- 社区模式(Community Model）
- 社区由很多志愿者参与，每个人参与自已感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴;或者捡到的柴火质量太差，最后火也就熄灭了。“社区” 并不意味着“随意”，一些成功的社区项目( 例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签人的质量控制。
- 业余剧团模式(Amateur Theater Team)
- 这样的团队在每一一个项目(剧目)中，不同的人会挑选不同的角色。在下一个剧目中,这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥(导演)的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在竞争性强烈、创造性要求高的团队，不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。
- 秘密团队(Skunk Work Team)
- 一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发Macintosh之后的系统时，就有两三个团队在不同时期进人秘密状态开发。21 世纪的一些创业团队也是处于类似状态。这种模式的好处是:团队内部有极大的自由，较高的热情，没有外界的干扰(不用每周给别人介绍项目进展，听领导的最新指示，等等)。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。
- 特工团队(SWAT)
- 就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
- 就像电影电视中的特工组“加里森敢死队”等- -样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决--些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题s。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
- 交响乐团模式(Orchestra)
- 交响乐团的演奏有下面的特点。
- 家伙多，门类齐全。
- 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
- 演奏都靠谱，同时看指挥的。
- 演奏的都是练习过多次的曲目,重在执行。
- 交响乐团的演奏有下面的特点。
- 爵士乐模式(Jazz Band)
- 不靠谱。他们演奏时都没有谱子。
- 没有现场指挥，平时有编曲者协调和指导乐队。
- 也有模式。
- 人数较少。
- 强调个性化的表达，强有力的互动，对变化的内容给予有创意的回应。
- 功能团队模式(Feature Team)
- 很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
- 官僚模式(Bureaucratic Model)
- 这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种结构有一重大隐患，在做绩效评估的时候，各个小老板、中老板都要为自己手下的弟兄们争名夺利，而有意无意地忽略了全局最优的绩效评估标准，导致很多无谓的算计、纠结、甚至有人会贬低别的团队的贡献。
- 主治医师模式(Chief Programmer Team, Surgical Team)
-
流程
- 写了再改模式(Code-and-Fix)
- 这个流程的好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
- “只用一次”的程序
- “看过了就扔”的原型
- 一些不实用的演示程序
- 这个流程的好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
- 瀑布模型(Waterfall Model)
- 当软件行业还在年幼的时期，它从别的成熟行业（硬件设计,建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循：分析→设计→实现（制造）→销售→维护，这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。
- 各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来
- 回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯
- 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用“最终产品直到最后才出现”是很令人头痛的局限性。
- 当软件行业还在年幼的时期，它从别的成熟行业（硬件设计,建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循：分析→设计→实现（制造）→销售→维护，这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。
- Rational Unified Process 统一流程(RUP)
- 老板驱动的流程(Boss-Driven Process)
- 渐进交付的流程(Evolutionary Deliverry)，MVP和MBP
- MVP——Minimum Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。
- 正如所有的方法论那样，MVP也有它的适用范围，和它相对应的，是Maximal Beautiful Product（最强最美产品，MBP）的思路，如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，为何不把产品最全、最美的形态展现出来，一举征服用户？
- TSP的原则
- 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
- 团队的各个成员对团队的目标、角色、产品都有统一的理解。
- 尽量使用成熟的技术和做法。
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- 增加团队的自我管理能力。
- 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
- 写了再改模式(Code-and-Fix)
-
本次作业的感受和体会：
1.本次实验通过复审完成质量较高小组的项目成果，进一步发现了自己的不足。同时经过对项目的复审，找出了一些BUG，再通过这些找到的BUG对自己的项目进行复审，进一步完善了自己的项目，体会到了复审的重要性。
2.通过团队建设，各个成员都介绍了自己的特长，以及希望承担的工作，从中我们认识到了通过团队配合，取长补短，我们团队的核心竞争力才会变得更加强大。
