201971010125-李涛 实验四 团队作业1：软件研发团队组建
| 课程班级博客 | |
| 作业要求 | |
| 团队名称 | |
| 我的课程学习目标 | （1）实验三作业互评。 （2）组建软件项目研发团队。 |
| 作业对我实现目标的帮助 | （1） 选择优秀项目，学习借鉴，提升自身实力。 （2）创建团队，了解团队成员。 |
| 团队博客链接 |
实验内容
任务一：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成任务并撰写个人博客。
| 选定项目博客 | |
| 选定项目的GitHub地址 |
1、 对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
2、克隆任务3项目源码到本地机器，阅读并运行代码，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
- 克隆任务3项目源码到本地机器，阅读并运行代码
- 代码核查表
| 概要部分 | |
| 代码符合需求和规格说明么？ | 代码基本符合需求和规格说明 |
| 代码设计是否考虑周全？ | 代码设计有周全的考虑 |
| 代码可读性如何？ | 代码可读性还不错 |
| 代码容易维护么？ | 代码容易维护 |
| 代码的每一行都执行并检查过了吗？ | 代码的每一行都执行并检查过了 |
| 设计规范部分 | |
| 设计是否遵从已知的设计模式或项目中常用的模式？ | 代码遵从已知的设计模式或项目中常用的模式 |
| 代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）？ | 代码没有依赖于某一平台，不会影响将来的移植 |
| 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？ 在本项目中是否存在类似的功能可以调用？ |
代码基本能用已有的Library/SDK/Framework中的功能实现 |
| 有没有无用的代码可以清除？ | 没有无用的代码可以清除 |
| 修改的部分代码符合标准和风格吗? | 符合标准和风格 |
| 具体代码部分 | |
| 有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？ | 对所出现的错误进行了修改，对于调用的外部函数检查了返回值并且处理了异常 |
| 参数传递有无错误，字符串的长度是字节还是字符的长度？ 是以0开始计数还是以1开始计数？ |
参数传递无误，字符串的长度是字节的长度，是以0开始计数的 |
| 边界条件是如何处理的？switch语句的default分支是如何处理的？循环有没有可能出现死循环？ | switch语句的default分支返回false，没有出现死循环。 |
| 有没有使用断言（Assert）来保证我们认为不变的条件真的得到满足？ | 无。 |
| 对资源的利用是在哪里申请的, 在哪里释放的？有没有可能导致资源泄露？有没有优化的空间？ | 都在内存中完成，很有可能泄露 |
| 数据结构中有没有用不到的元素？ | 无，整体比较简洁 |
| 效能 | |
| 代码的效能（Performance）如何？最坏的情况如何？ | 达到了具体任务的要求。 |
| 代码中，特别是循环中是否有明显可优化的部分？ | 有 |
| 对于系统和网络调用是否会超时？如何处理? | 未出现超时现象 |
| 可读性 | |
| 代码可读性如何？有没有足够的注释？ | 可读性较强，有足够的注释 |
| 可测试性 | |
| 代码是否需要更新或创建新的单元测试？ | 可以接着开发，增加更多的功能 |
3、阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
3.1 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
软件的使用过程：运行软件后，进入首页面，首界面有两个功能，一个是算法选择，里面包含四种算法的选择，另一个是其他，里面包含绘制散点图和排序，这两个功能选择是分开的。当选择算法功能，将对读入的数据进行计算，然后将最优解和时间保存在结果部分；如果选择其他里面的绘制散点图，将得到一张以价值重量为横轴、价值为纵轴的数据散点图。
首页面：
功能界面：
- 导入数据测试，采用动态规划算法，运行结果如下：
- 以价值重量为横轴、价值为纵轴的数据散点图如下：
3.2 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
- 软件产品基本解决了功能需求，但是无法承受过大的数据量。
- 优点：每个功能都很详细的标明，用户需要什么功能可以选择。
- 缺点：同一类功能零散的放在页面上，导致页面不整洁，不美观，并且页面之间的跳转并不流畅。
- 改进方法：可以为按钮增添监听事件onclick，以实现多个页面之间的跳转。
3.3 从学历、年龄、专业、爱好、收入等方面概括实验三任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求都是什么？
- 职业：学习计算机专业的学生和编程人员或者计算机相关方面的老师
- 学历：本科以上
- 年龄：18岁以上
- 专业：计算机相关专业或者与编程有关的其它学科
- 爱好：对计算机深入研究或者编程爱好者
- 收入：月薪8000+
- 表面需求：熟悉算法，解决{0-1}背包问题
- 潜在需求：融合知识，提高思维和编程能力。
3.4 经过（1）-（3）的工作，你们一定有充分的理由给评价作业选择一个结论:a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
- d) 好，不错
3.5 结合（1）—（3）的评论体会，迭代改进本小组实验三的任务3
首界面
二级页面添加功能
GitHub信息更新
任务二：团队创建
1、 在实验三结对基础上，结对小组两两自由组合，组建软件项目研发团队；
1.1、 队名：繁星
1.2、 团队成员组成
| 成员学号 | 成员姓名 | 备注 | |
|---|---|---|---|
| 201971010106 | 陈玉英 | 博客地址链接 | PM |
| 201971010117 | 刘春丽 | 博客地址链接 | |
| 201971010125 | 李涛 | 博客地址链接 |
1.3、 成员风采
- 详细介绍
| 陈玉英 | 自然型 亲和，随意 |
c，c++，python； 代码分析，审核 ; 统筹管理 |
python，c,设计分析 | PM，开发 | 与其临渊羡鱼，不如退而结网 |
| 刘春丽 | 少女型 活泼，灵动 |
文档分析； 资料整合； java和算法分析 |
java，算法分析 | 测试优化 | 总要有一个人赢，为什么不能是我 |
| 李涛 | 温柔型 温柔，细腻 |
界面美化； 项目安排； python |
前端开发，页面美化 | 开发，协调 | 大步向前，回头才有惊喜 |
- 现代软件工程—构建之法》第7章，理解MSF的9点基本原则
- 推动信息共享与沟通
所有的信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人；牵涉到技术机密和安全性信息要采取必要的保护措施。 - 为共同的远景而工作
同心同德、；
做产品，要明确项目目标，目标必须明确，最终可以达到，不空泛。 - 充分授权和信任
在一个高效的团队中，所有成员都应该得到充分的授权；
他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺；
团队的顾客也认为团队能兑现承诺，并进行相应的规划。 - 各司其职，为项目共同负责
每个角色都有自己的职责，出了问题，相应的角色就要负责。 - 交付增量的价值
项目应该出于商业目的，没有商业需求，再酷的技术也没有用。 - 保持敏捷，预期和适应变化
需要预期变化，不是期望变化；
团队内部也会有变化，比如人员离职，技术提高，需要保持敏捷的身段。 - 投资质量
对质量的重视，引发对质量的投资。 - 学习所有的经验
学习过去的经验，同时，避免过去的经验解决现在的问题。 - 与顾客合作
项目是团队成员做的，但是项目的商业价值由用户说了算。
- 推动信息共享与沟通
1.4、 组建团队企业微信群，给出群成员截图
1.5、 团队特色描述，言简意赅的描述团队特点或核心竞争力；
- 性格互补，擅长技术相辅相成，关系融洽；
2、 申请开通团队博客，点击链接（https://www.chaojibiaoge.com/U/url/7lxwx4sx）提交团队信息，将团队博客加入到班级博客；
- 已开通团队博客并加入班级。
3、阅读《现代软件工程—构建之法》第5章内容
- 团队的特点：
- 团队有一致的集体目标，团队要一起完成这个目标。一个团队的成员不一定要同时工作。
- 团队成员有各自的分工，互相依赖合作，共同完成任务。
- 软件团队的模式：
- 主治医师模式
首席程序员“主刀”（负责处理主要模块的设计和编码），其他成员“为主刀医师服务”（从各种角度支持他的工作）。 - 明星模式
主治医生模式运用到极致，可以蜕化为明星模式。 - 社区模式
社区很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。 - 业余剧团模式
个人在团队中听从一个中央指挥的指导和安排。 - 秘密团队
软件团队进行一些秘密的软件项目。 - 特工团队
软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而紧迫性的问题。 - 交响乐团模式
家伙多，门类齐全；各司其职，各自有专门场地，演奏期间没有聊天、走动等现象；演奏都靠谱，同时看指挥的；演奏的都是练习过多次的曲目，重在执行。 - 爵士乐模式
不靠谱；没有现场指挥；人数较少。 - 功能团队模式
具备不同能力的同事们平等协作，共同完成一个功能。 - 官僚模式
几个人报告给一个小头目，几个小头目报告给中头目，依次而上。
- 主治医师模式
- 开发流程
写了再改模式适用于以下任务：- 只用一次的程序
- 看过了就扔的原型
- 一些不实用的演示程序
瀑布模型适用于以下情况： - 如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证
- 产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证
- 使用的技术非常成熟，团队成员都很熟悉这些技术
- 负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流
任务三：完成《实验四 团队作业1：软件研发团队组建》博文作业
- 已完成并发布软件研发团队博客
1、 完成各项任务实际花费的时间
| 任务内容 | 计划完成的时间（min） | 实际完成时间（min） |
|---|---|---|
| 任务 | 60 | 60 |
| 任务分配 | 20 | 15 |
| 团队创建 | 30 | 35 |
| 团队信息了解 | 60 | 60 |
| 构建之法 | 120 | 100 |
| 任务1 | 80 | 90 |
| 任务2 | 60 | 80 |
| 任务3 | 60 | 50 |
2、 完成本次作业的感受和体会
— 团队的创建，熟悉了团队人员。人多力量大，团队性格互补，合理的分工，事半功倍；团队的沟通非常重要，及时有效的沟通，能够避免不必要的重复工作。
