201971010231-毛玉贤 实验四 团队作业1：软件研发团队组建

201971010231-毛玉贤 实验四 团队作业1：软件研发团队组建

---

一、实验目的与要求

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/2019nwnucs
本次作业要求链接	https://edu.cnblogs.com/campus/xbsf/2019nwnucs/homework/12578
团队名称	发际线跟我作队
团队的课程学习目标	（1）实验三作业互评。 （2）组建软件项目研发团队。
这个作业在哪些方面帮 助团队实现学习目标	（1）可以克隆其他同学的项目运行体验，比较感受自身项目的不足。 （2）结对方式学习有利于两人思想交流。
团队博客链接	https://github.com/Mao-cpu/Algrithm_platform

二、实验内容与步骤

1、任务一：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成以下任务，具体要求如下：

（1）对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。

博客链接	评论内容
被评论作业的博客链接	https://www.cnblogs.com/byg-zyy/p/16074525.html
被评论作业的Github项目仓库链接	https://github.com/BYG-0105/Knapsack-0-1
201971010259-张圆圆	①博文结构：本篇博客结构层次分明、色彩恬淡爽朗、给人舒适感受，整体排版干净整洁，不拖泥带水。博主在细节的把控上则显得游刃有余，右侧目录让人一目了然，纵观全篇，能快速锁定自己寻找的部分，体验感好。博主的配色方面，整体偏元气橘调，给人活泼、开朗的感觉，让人心情愉悦，很棒！ ②博文内容：本篇博客内容全程干货，博主通俗易懂的解释，让人收获满满，在内容的分配上也是详略得当，张弛有度。不仅对本次实验中新增的遗传算法、日志记录等功能有详尽的解释，而且对实验二中要求的动规、贪心、回溯、排序、散点图等内容也做了详尽解释，足以看出博主的细心与用心。将算法代码与内容解释放在一起，更是方便让人理解，代码注释也恰到好处！总体推荐阅读！ ③博文结构与PSP中“任务内容”列的关系：可以看出博文整体结构基本对应了PSP中的“任务内容”，在进行计划分析后，也得出了需求分析，生产设计文档，有自己的编码规范风格（java、python），有具体的设计，以及编码、测试、修改代码（完善功能）、提交代码、提交博文、事后总结等过程。 ④PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究：本篇博客的PSP中，可以看出绝大部分实际完成需要的时间都超过了计划共完成需要的时间，只有设计复审（审核设计文档）、具体设计、测试是在计划时间内完成的，本人认为实验三本身也是有一定难度的，对于（比如像我）一些同学，没有将以前，前后端学过的知识很好地融会贯通到一起做开发，其实就比较会浪费时间，因为在这个过程中遇到的各种问题，都需要学生之间去查阅解决，所以耗费的时间长些，也就“合乎情理”之中了，但虽然在这样的条件下，该组还是较高完成度的完成了本次作业，虽付出了时间，但一切都是值得的。 ⑤给出这个结对小组在进度计划方面可以提高的具体建议：在代码规范方面：建议博主每次在用编程语言开发时，尽量都遵守一套自己大框架基本相同的编码规范，形成自己的编码风格；在具体代码方面：两个人可以先交流好自己的思想后，分发任务，并做好接口的整合，在产生不一致意见时，理智分析，哪种更合适；在代码复审方面：可以分为两部分分别检查，然后互换复盘检查，效率高，时间相对少。均为本人一些拙见，希望博主越来越好！！！

（2）克隆任务3项目源码到本地机器，阅读并运行代码，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。

• 1.2.1 克隆项目：

• 1.2.2 复审核查表：

注意事项	内容
概要部分
代码符合需求和规格说明么？	符合
代码设计是否考虑周全？	是
代码可读性如何？	结构化清晰，可读性好
代码容易维护么？	容易复用与维护
代码的每一行都执行并检查过了吗？	是
设计规范部分
设计是否遵从已知的设计模式或项目中常用的模式？	是
有没有硬编码或字符串/数字等存在？	没有
代码有没有依赖于某一平台，是否会影响将来的移植？	没有，不影响移植
在本项目中是否存在类似的功能可以通过调用而不用全部重新实现？	没有
有没有无用的代码可以清除？	没有
代码规范部分
修改的部分符合代码标准和风格么？	符合
具体代码部分
对于调用的外部函数，是否检查了返回值或处理了异常？	已检查并处理
参数传递有无错误，字符串的长度是字节的长度还是字符的长度，是从0开始计数还是从1开始计数	没有
边界条件是如何处理的？switch语句和default分支是如何处理的？循环有没有可能出现死循环？	没有使用switch语句，不会出现死循环
对资源的利用，有无可能存在资源泄露？有没有优化的空间？	没有资源泄露，存在优化空间
效能
代码的效能如何？最坏的情况是怎么样的？	效能较好，最坏情况：有时算法求解时间微长
代码中，特别是循环中是否有明显可优化的部分？	无
对于系统和网络的调用是否会超时？如何处理？	没有对网络进行调用，没有超时
可读性
代码可读性如何？有没有足够的注释？	注释足够，可读性强
可测试性
代码是否需要更新或创建新的单元测试？	不需要，代码结构性强，可以直接单元测试

（3）阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：

A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；

• 使用过程：程序运行后，app进入注册界面，填写个人信息后，注册成功，登录后，点击界面右上角角标可以选择文件数据，主界面下有计算动态规划、贪心、回溯、遗传、绘图、排序的按钮，可以点击对应的按钮得到相应的结果；

• 测试照片：

B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？

• 软件功能实现情况
  • 通过克隆测试后，体验了数据导入、贪心算法、回溯算法、动态规划、遗传算法，绘制散点图、进行单位重量价值比排序、日志记录这些功能，缺点之一是没能将四大算法计算出的结果以可视化的形式展示在app界面上，以及日志记录也是在本地20220204.txt文件中显示的，并未在app界面中显示，在绘制散点图的过程中发现，当后期数据量大时，气泡图会无法显示，整体功能大约完成95%；
• 优缺点
  • 优点：用户使用方便，可以在手机上直接使用，app界面清晰简洁；
  • 缺点：有些功能还不是特别的完善，还可以在优化提升；
• 改进意见
  • app页面遇到较长文字时，在界面上显示不太清晰，界面还可以再美化；

C. 从学历、年龄、专业、爱好、收入等方面概括实验三任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求都是什么？

• 用户特征：该软件主要针对的应该是17-26岁的高中或大学生，正在学习从事或者接触有关计算机方面的用户群体，可以是专业人士，也可是不同专业，但对此有兴趣的学生，爱好技术编程的学生、此类人群大部分是学生，所以大多可能处于没有收入的状态；
• 表面需求：能够选择数据0-9中的任意数据，通过特定的算法求解结果，并能显示查看结果以及绘图，供自己学习测试使用；
• 潜在需求：能够选择任意有效数据，选择特定算法，求解结果并显示。

（4）经过（1）-（3）的工作，你们一定有充分的理由给评价作业选择一个结论:a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐。

• 评价：e) 好，不错
• 理由：首先从用户角度，该app可以直接下载到手机上运行测试，使用方便，体验感好；其次从功能实现上，该app不仅有实验二中要求的基本功能，也加入了用户注册、登录页面，测试过程中所绘制的图形保存到本地图库时，也会先同用户获取访问相册的权限，在其他数据的选择、排序、四大算法的计算等功能上，实现也比较完整，完成度高。

（5）结合（1）—（3）的评论体会，迭代改进本小组实验三的任务3（项目仓库的Fork、Clone、Push、Pull request、Merge pull request数据变化情况）。

• 1.5.1 迭代改进本小组的项目

• 仓库链接：https://github.com/Mao-cpu/Algrithm_platform

• 主界面美化

• 文本框加背景色（排序为例）

• 1.5.2 fork记录

• 1.5.3 更新commit记录

• 新增push记录

• 新增commit（3次）

• 美化细节（如下）

• 具体代码（主界面）

  • 文本框颜色只需要在定义时设置背景颜色backgroud为lightskyblue即可（代码很少，不作展示）；

• 1.5.4 更新release记录

2、任务二：团队组建

（1）在实验三结对基础上，结对小组两两自由组合，组建软件项目研发团队；

• 2.1.1 队名

  • 发际线跟我作队

• 2.1.2 团队成员组成，按以下列表形式给出，个人博客地址需加超链接，在备注中标记团队组长（PM）

成员学号	成员姓名	个人博客地址	备注
201971010115	蒋敏敏	https://www.cnblogs.com/20010201jmm/p/16119581.html
201971010157	张颖	https://www.cnblogs.com/mingjiang-/p/16113265.html
201971010231	毛玉贤	https://www.cnblogs.com/Moki231/p/16106385.html	PM

• 2.1.3 成员风采：介绍每位队员的风格、擅长技术、编程兴趣、希望的承担的软工角色(文档、开发、测试、PM等)、一句话宣言等；阅读《现代软件工程—构建之法》第7章，理解MSF的9点基本原则

• 成员介绍

成员	擅长技术	编程兴趣	风格	承担角色	一句话宣言
201971010115_蒋敏敏	python、C	比较喜欢人工智能、游戏开发方面	实干型，动手能力强，喜欢一个人解决问题	开发测试	实践出真知
201971010157_张颖	C、java	对做微信小程序、网站情有独钟	总结性强，适应性强 ，对文字敏感	文档设计与测试	不塞不流，不止不行
201971010231_毛玉贤	C++、python	喜欢前端、系统开发	偏理论性强，能够提出新需求，想法新颖	开发与测试	夏虫不可语冰，井蛙不可语海

• 《现代软件工程—构建之法》第7章——MSF的9点基本原则

  • 1.推动信息共享与沟通( Foster open communications )
  • 2.为共同的远景而工作( Work toward a shared vision )
  • 3.充分授权和信任( Empower team members )
  • 4.各司其职，对项目共同负责( Establish clear accountability and shared responsibility)
  • 5.交付增量的价值( Deliver incremental value )
  • 6.保持敏捷，预期和适应变化( Stay agile, expect and adapt change)
  • 7.投资质量( Invest in quality)
  • 8.学习所有的经验( Learn from all experiences )
  • 9.与顾客合作( Partner with internal and external customers )

• 2.1.4 组建团队企业微信群，给出群成员截图

• 2.1.5 团队特色描述，言简意赅的描述团队特点或核心竞争力

• 特点：风格明确，各司其职，互相交流，共同进步，团队包容性强，氛围融洽，有共同的价值观和行为规范；

• 核心竞争力：团队成员各有各的闪光点，三人能力互补，学习能力教强，积极向上，对事物充满兴趣。

（2）申请开通团队博客，点击链接https://www.chaojibiaoge.com/U/url/7lxwx4sx提交团队信息，将团队博客加入到班级博客；

• 提交团队信息

  

• 加入班级博客

  

（3）阅读《现代软件工程—构建之法》第5章内容

• 第五章 团队与流程 总结

• <5.1> 非团队和团队

  • 非团队特点：临时组建、乌合之众、无合作协作、做完任务就走人；
  • 团队特点：团队有一致集体目标，团队一起完成该目标；团队成员有各自分工，互相依赖合作，共同完成任务。

• <5.2> 软件团队的模式

  • 主治医师模式：像在手术台一样，有一个主刀医师，其他人负责协助主刀医师
    • 优点：初衷很好，一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工作
    • 缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其他学生打酱油”
  • 明星模式：主治医师模式运用到极点
    • 优点：对“明星”个人的成长进步可能会有所帮助
    • 缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低
  • 社区模式：由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬
    • 优点：“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制
    • 缺点：：“只烤火，不拾柴”，“拾到的柴火质量太差”
  • 业余剧团模式：团队中各人扮演各人的角色
    • 优点：在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论
    • 缺点：：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。
  • 秘密团队：有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么
    • 优点：团队内部有极大的自由，较高的热情，没有外界的干扰。
    • 缺点：：不可能成为普遍模式，只会针对个别项目。
  • 特工团队：：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题
    • 优点：效率高
    • 缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式
  • 交响乐团模式：各司其职，像交响乐队一样
    • 优点：各司其职，重在执行
    • 缺点：呆板
  • 爵士乐模式：与交响乐模式存在相当多的对立
    • 优点：领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结
    • 缺点：人员不能太多
  • 功能团队模式：具备不同能力的同事们平等协作公共完成一个功能
    • 优点：效率高
    • 缺点：每个小组必须与其他小组就编程规范达成一致
  • 官僚模式：脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次向上
    • 优点：有助于技术的交替与互补
    • 缺点：容易掺杂一些追名逐利，往往会使团队效率大打折扣

• <5.3> 开发流程

  • 写了在改模式
    • 要写一个有实际用户、解决实际需求的软件，这个方法缺点太大；

  

  • 瀑布模式
    • 前一阶段完成后，您只需要去关注后续阶段，但各个阶段之间极少有反馈；只有在项目生命周期的后期才能看到结果；

  

  • 瀑布模式的各种变形
    • 为了解决瀑布模型的各种问题，人们在实践中提出了各种模型；

  

  • 统一流程（RUP）
    • 最小可行产品，又称为最小功能集把产品最核心的功能用最小的成本实现出来（或描绘出来），然后快速征求用户意见；

  

  • 老板驱动的流程

    • 开发流程由行政领导主导或公司老板驱动；

  • 渐进交付的流程，MVP,MBP

    • 当系统的主要需求和架构逐渐明确后，软件团队进入了一个不断演进的循环中：

  

  • TSP的原则
    • ①使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。
    • ②团队的各个成员对团队的目标、角色、产品都有统一的理解。
    • ③尽量使用成熟的技术和做法。
    • ④尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
    • ⑤制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）。
    • ⑥增加团队的自我管理能力。
    • ⑦专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）

3、任务三：完成《实验四 团队作业1：软件研发团队组建》博文作业

（1）记录完成《实验四 团队作业1：软件研发团队组建》各项任务实际花费的时间

任务内容	实际花费时间（min）
任务一	101
任务二	109
确定团队名称	2
确认成员信息	10
组建群聊、申请团队博客、 申请团队github地址	39
加入班级博客	3
学习MSF	25
阅读第五章	30
任务三	54

（2）谈谈完成本次作业的感受和体会

• 本次作业，在实验三的基础上两两组合，不仅运行了别人的优秀项目，体会到多角度实现客户需求的想法和技术，还构建了团队，团队成员都比较喜欢交流，有利于提升我们团队协作的能力，以及个人水平，在以后的学习工作中相信都会受益匪浅。