201871030118-雷云云 实验四 团队作业1：软件研发团队组建个人博客
| 项目 | 内容 |
|---|---|
| 课程班级博客 | 班级链接 |
| 这个作业要求链接 | 作业链接 |
| 团队名称 | 佩琪小分队 |
| 团队的课程学习目标 | 1. 继续熟练github的相关操作； 2.根据文档和团队交流确立开发流程； 3.团队相互学习交流提升个人技术水平； 4.通过使用他组的软件项目，总结和反思自己，加以修改； 5、通过团队项目学习软件工程； |
| 这个作业在哪些方面帮助团队实现学习目标 | 1.通过团队的组建，在完成项目时有助于取长补短； 2.相互了解彼此的特长兴趣便于以后的合作； 3.理解了一个团队中目标统一的重要性； |
| 团队博客链接 | 团建博客链接 |
任务1：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成以下任务，具体要求如下：
1.对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
点评作业博客链接
被评论作业的Github项目仓库链接
点评截屏
2.克隆任务3项目源码到本地机器，阅读并运行代码，找出项目代码的5个以上bug，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
| 1．概要部分 | |
|---|---|
| （1）代码能符合需求和规格说明么？ | 是 |
| （2）代码设计是否有周全的考虑？ | 否 |
| （3）代码可读性如何？ | 良好 |
| （4）代码容易维护么？ | 容易 |
| （5）代码的每一行都执行并检查过了吗？ | 是 |
| 2．设计规范部分 | |
| （1）设计是否遵从已知的设计模式或项目中常用的模式？ | 是 |
| （2）有没有硬编码或字符串/数字等存在？ | 否 |
| （3）代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）？ | 否 |
| （4）开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？ | 不能完全实现 |
| （5）在本项目中是否存在类似的功能可以调用而不用全部重新实现？ | 是 |
| （6）有没有无用的代码可以清除？ | 有 |
| 3．代码规范部分 | |
| （1）修改的部分符合代码标准和风格么（详细条文略）? | 符合 |
| 4．具体代码部分 | |
| （1）有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？ | 无 |
| （2）参数传递有无错误，字 | 无 |
| （3）边界条件是如何处理的？Switch语句的Default是如何处理的？循环有没有可能出现死循环？ | 无死循环 |
| （4）有没有使用断言（Assert）来保证我们认为不变的条件真的满足？ | 无 |
| （5）有没有可能优化？ | 有 |
| 5．效能 | |
| （1）代码的效能（Performance）如何？最坏的情况是怎样的？ | |
| （2）代码中，特别是循环中是否有明显可优化的部分？ | 无 |
| （3）对于系统和网络调用是否会超时？如何处理? | |
| 6．可读性 | |
| 代码可读性如何？ | 良好 |
| 7．可测试性 | |
| 代码是否需要更新或创建新的单元测试？ | 不需要 |
| 我在使用该软件的使用过程，在本次使用过程中我发现了很多问题（个人）： |
（1）数据没有保存到数据库中，读取的文件是自己本地的；
（2）读取文件错误，与该博主实验三中所展示的不一致；
（3）当换文件读取时，进行数据的查询时与读取文件1.txt的结果一样；
（4）绘制的散点图与博主博客中展示的一样，那意味着散点图的绘制也是存在问题的；
（5）当进行选择算法求解时，只有动态规划算法并且执行结果错误，也是与博主博文中展示的不一致。
（6）根据数据集的内容来看，本次排序结果也是错误的。
3.阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
以下为我本次体验的结果，以图例展示：
图1.进行数据的查询
图2.散点图的绘制
图3.排序
图4.动态规划算法解决背包问题
图5.读取文件
图6.绘制散点图
图7.排序
B.总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
功能：
1.web页面
2.文件读取
3.绘制散点图
4.对数据集进行排序
5.动态规划算法解决0-1背包问题
缺点：
文件读取有误
界面过于单调
用户使用时，应该有选择选项会更好（没有提示）
C. 从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
职业:学生和从事软件开发的人
学历:一般为大专及以上
年龄:18-35
专业爱好:计算机专业和数学专业爱好计算机编程、网站开发、偏爱算法研究
收入:8000-15000
需求：了解该软件项目的功能，使用网站界面显示算法结果需要良好的人机交互界面以及掌握前后端的技术将算法更好地展示。
（4）经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
一般
（5）结合（1）—（3）的评论体会，迭代改进本小组实验三任务3。
经过评论、运行该小组的作业，因为在我们小组没有完成界面的部分，所以在本次迭代中，实现界面的代码编写；
本小组的GitHub账号链接：链接
fork
Pull request
Clone
任务二.团队建设
1.队名：佩琪小分队
2.团队成员，按以下列表形式给出，个人博客地址需加超链接，在备注中标记团队组长（PM）;
| 成员学号末五位 | 成员*名 | 个人博客地址 | 备注 |
|---|---|---|---|
| 03009 | *诚 | 博客地址 | PM |
| 03133 | *作朝 | 博客地址 | 成员 |
| 30140 | *婷婷 | 博客地址 | 成员 |
| 30118 | *云云 | 博客地址 | 成员 |
3.成员风采：介绍每位队员的风格、擅长技术、编程兴趣、希望的承担的软工角色(文档、开发、测试、PM等)、一句话宣言等；阅读《现代软件工程—构建之法》第7章、第17章，理解MSF的9点基本原则和团队成员绩效
成员风采：
| 成员 | 风格 | 擅长技术 | 编程兴趣 | 希望承担的软工角色 | 宣言 |
|---|---|---|---|---|---|
| *诚 | 动手能力较强，善于沟通，乐于交际 | python | 爬虫 | PM | 我曾踏足山巅，也曾进入低谷，二者都让我受益良多 |
| *作朝 | 认真严谨，韧性十足，有较强的团队精神 | python | python | 开发 | 只要路是对的，就不怕路远 |
| *婷婷 | 积极向上，善于思考，有较强的上进心，具有吃苦耐劳的精神，做事细心谨慎，责任心强。 | Python | web前端 | 文档 | 人生在勤，不索何获 |
| *云云 | 仔细认真，积极主动，性格开朗，待人友好，良好的沟通能力 | python | python | 测试 | 两粒种子，一片深林 |
| MSF的9点基本原则和团队成员绩效 |
（1）推动信息共享与沟通（Foster open communications）
（2）为共同的远景而工作（Work toward a shared vision）
“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。这个目标必须是明确的，没有二义性，这个目标不是当前就能达到，必须是通过努力才能达到的；
（3）充分授权和信任（Empower team members）
这一点的关键是“授权”这个词，授权（Empower）有两个意思：
给某人权力和权威
给予某人更多自信和自尊在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划
MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的
充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段。
（4）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
在项目进展的过程中，对于每一项任务，每个人都要明确以下几点。
Who：谁负责
What：做什么，具体的执行方案，什么叫做“做好了”
When：什么时候开始，什么时候结束
Why：为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？
与“信息共享与沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”—知道别人在做什么，为什么，以及整个项目的目标
（5）交付增量的价值（Deliver incremental value）
现在的软件产业，特别是和互联网相关的产业，变化非常快，用户希望产品团队经常提供更新，以适应新的需求。我们要保证在两个方面保证客户的利益：
（6）保持敏捷，预期和适应变化（Stay agile, expect and adapt change）
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化
除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段
（7）投资质量（Invest in quality）
对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。
（8）学习所有的经验（Learn from all experiences）
在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题
这一原则有两个含义——把经验总结出来分享经验
MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。
在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团
4.阅读《现代软件工程—构建之法》第5章内容
-
团队共有的特点
（1）团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作；
（2）团队成员有一定的分工，互相依赖合作，共同完成任务。 -
软件团队的模式
（1）一窝蜂模式： 这种模式存活时间不长，这样的团队可能是一个欢快而随意的模式
（2）主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
（3）明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
（4）社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
（5）业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
（6）秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
（7）特工团队：团队由专业人士组成，负责一些紧急问题的解决；
（8）交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
（9）爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
（10）功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
（11）官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
-
团队开发流程
（1）写了再改模式
（2）瀑布模式
（3）瀑布模型的各种变形
（4）Rational Unified Process （统一流程（RUP））
（5）老板驱动的流程
（6）渐进交付的流程
