201871010133-赵永军 实验四 团队作业1：软件研发团队组件

项目	内容
课程班级博客链接	班级博客
这个作业要求链接	作业要求
团队名称	缔造
团队的课程学习目标	1、组建软件项目研发团队； 2、完成实验任务； 3、培养合作意识，提升软件开发效率
这个作业在哪些方面帮助团队实现学习目标	1、通过成立软件项目研发团队，使得软件开发效率更高； 2、通过团队企业微信群的建立联系。
团队博客链接	缔造

---

一、实验目的与要求

• 实验三作业互评。
• 组建软件项目研发团队。

二、实验内容与步骤

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

• 对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
• 克隆任务3项目源码到本地机器，阅读并运行代码，找出项目代码的5个以上bug，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
• 阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
  • 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
  • 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
  • 从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
• 经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
• 结合（1）—（3）的评论体会，迭代改进本小组实验三任务3。

---

被评论的同学：

被评论的同学	201871010130-周学铭
被评论博客的作业链接	作业链接
被评论作业的Github项目仓库链接	仓库链接

被评论的内容：

• 符合（1）要求的评论
  
• 克隆任务3项目源码到本地机器
  
• 阅读并运行代码，找出项目代码的5个以上bug
  • 项目运行：
    
    
  • bug
    （1）单击按钮确定选择文件的选项遮住了右边的3个图标，导致右边的3个图标无法使用。
    （2）最左边选择项点击无法指示，鼠标放上面才会显示。
    （3）将文件上传成功后可以设置一个提示界面。
    （4）在文件选择界面，应设置错误提示，当选择超过两个文件时，有错误提示。
• 符合（2）要求的代码核查表

提出问题	执行情况
概要部分
代码符合需求和规格说明么？	代码符合需求和对反说明。
代码设计是否考虑周全？	考虑周全。
代码可读性如何？	可以顺利读下去。
代码容易维护么？	不太容易维护。
代码的每一行都执行并检查过了吗？	是的，都可以执行。
设计规范部分
设计是否遵从已知的设计模式或项目中常用的模式？	遵从。
代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）？	没有，不会影响移植，任何平台都可以。
开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？	可以用；存在，有些代码是可以调用的
有没有无用的代码可以清除？（很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件中有很多注释掉的代码，这些代码都可以删除，因为源代码控制已经保存了原来的老代码）	基本清楚完毕了。
代码规范部分
修改的部分符合代码标准和风格么?	修改的部分不太符合代码标准和风格。
具体代码部分
有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？	对错误都进行了处理，没有异常。
参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度，是以0开始计数还是以1开始计数？	无错误；本项目中是以0开始计数。
边界条件是如何处理的？switch语句的default分支是如何处理的？循环有没有可能出现死循环？	switch语句的default分支返回false，没有出现死循环。
有没有使用断言（Assert）来保证我们认为不变的条件真的得到满足？	有。
对资源的利用是在哪里申请，在哪里释放的？有没有可能导致资源泄露（内存、文件、各种GUI资源、数据库访问的连接，等等）？有没有优化的空间？	在对数据库进行操作之前申请数据库连接资源，操作完毕之后释放申请的资源；不会导致资源泄露；可以优化使用断言来保证我们认为不变的条件
数据结构中有没有用不到的元素？	没有。
效能
代码的效能（Performance）如何？最坏的情况如何？	达到了具体任务的要求。
代码中，特别是循环中是否有明显可优化的部分（C++中反复创建类，C#中 string 的操作是否能用StringBuilder 来优化）？	没有，已经比较优化了。
对于系统和网络调用是否会超时？如何处理?	目前没有出现超时的现象。假如出现了我们会杀毒；整理系统，减少运行的进程，释放内存、cpu，释放c盘空间。
可读性
代码可读性如何？有没有足够的注释？	可以顺利读取；代码有足够的注释让我们读懂
可测试性
代码是否需要更新或创建新的单元测试？针对特定领域的开发（如数据库、网页、多线程等），可以整理专门的核查表。	可以继续开发，摆脱传统的命令行方式，更为实用。

• 阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
  • 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
    
  • 散点图：
    
  • 数据排序：
    
  • 动态规划算法：
    
    
  • 回溯算法：
    
  • 数据库：
    
  • 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
    1、软件功能
    经过上述测试，该软件功能有:
    （1）将数据写入数据库
    （2）绘制散点图
    （3）对数据项集排序
    （4）求解0/1背包问题最优解
    （5）将求解结果写入文件
    该软件将任务3要求的功能软件解决了
    2、优点
    （1）人机交互页面简单整洁，便于使用
    （2）各个功能都实现了，即功能完善
    （3）数据库设计较好，很好的存储了大量数据
    （4）存储最优解等使用弹出框，使用效果较好
    3、功能方面的意见
    （1）可以添加更多的算法，满足更多用户的需求
    （2）设置一个登陆页面，完善软件的使用
  • 从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？

特征
职业	学生
学历	本科
年龄	20-25岁
专业	计算机专业
爱好	编程
收入	5k+
表面需求	获取一些算法的代码进行研究
潜在需求	用编程语言实现动态规划等算法，研究其代码，掌握许多算法，提升自己的编程能力。

• 经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
  • e）非常推荐。经过我自己的使用，这个软件用起来很方便。
• 结合（1）—（3）的评论体会，迭代改进本小组实验三任务3。
  • 项目迭代改进要点说明：在我们项目提交的过程中，我们会提交多次，每次提交的都是我们改动或新添加的代码。我们这次在上次的基础上添加了新功能，包括将数据的解写到文件中，将数据库中的数据显示在前端，并将前端进行完善。
  • 美化界面，改进中。

---

• 小结
  • 在完成这次任务的过程中，我更进一步地感受到了自己与别人的差距。通过测试运行别人的程序，我发现了许多的不足，看了别人设计的软件功能，给我的感触很深，我也发现了许多值得我学习的地方，我明白了自己应该克服困难，努力提升自己的能力。

---

阅读《现代软件工程一构建之法》 第7章、第17章,理解MSF的9点基本原则和团队成员绩效

• 推动信息共享与沟通( Foster open communications )
  MSF团队模型与过程模型都是建立在“信息共享与沟通”原则之上的，其要求除技术机密和安全性等信息采取必要的保护措施外，其余信息全部保留并公开，且应当公开并告知所有人。除此之外，团队成员交流沟通要简洁明了；
• 为共同的远景而工作( Work toward a shared vision )
  其中“共同的远景”指的是产品的远景，不管是应用软件还是行业软件，我们首先要明确项目的目标，要保证无二义性，并且可以达到，一般来说，“远景”是由“有远见的人”提出的，然后再公开讨论，消除误解，凝聚共识。
• 充分授权和信任( Empower team members )
  授权( Empower)有两个意思:一是给某人权力和权威;二是给予某人更多自信和自尊。在一个高效的团队中，所有成员都应该能得到充分的授权，他们有权在职权范围内按照自已的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。
• 各司其职,对项目共同负责( Establish clear accountability and shared responsibility )
  每个角色要各司其职，如果出了什么问题，那么这个角色就要负责，团队的各个角色合起来，对整个项目最终的成功负责，在项目进展的过程中，要明确who，what，when，why，职责图如下：
  团队模型和关键质量目标

关键质量目标	小组角色	出口条件
按约束条件交付产品	程序管理	我们的项目是在时间/资源的条件内交付的么？
按产品规格说明交付产品	开发	我们是否按照功能说明完成了各项功能？
保证所有问题都得到处理	测试	我们发现了所有的问题，而且都有处理方案吗？
产品部署和后续管理	发布管理	客户是否能快速方便地部署产品和进行后续管理？
让产品更好用	用户体验	产品是否适应用户的使用习惯？易用易学？
让客户满意	产品管理	客户是否（在总体上）满意我们的项目

• 交付增量的价值( Deliver incremental value )
  我们的项目都应该是出于商业目的，如果没有商业的需求，再酷的技术也没有用，一个项目的商业价值，只有在它被成功发布并且运行时候，才能体现出来，所以，MSF过程模式包括了开发和发布阶段。在MSF团队模型中，“用户体验”代表了用户的利益，“产品管理”这个角色代表了客户的利益，保证了产品能够为客户提供商业价值。
• 保持敏捷,预期和适应变化( Stay agile, expect and adapt change )
  在软件工程中，唯一不变的就是变化，所以我们要预期变化，而不是期望变化。比如一个产品项目需求的生存周期是18个月，如果超过这个期限，产品还没做出来，那就几乎不必做了，因为用户的需求已经发生了变化。
• 投资质量( Invest in quality )
  之所以叫投资，是很有道理的。投资要讲效率，投资要讲时机，投资是长期的；团队成员应该有这样的共识，防止缺陷的发生成为团队质量控制的首要任务，所有的角色都应该对质量保障负责。
• 学习所有的经验( Learn from all experiences )
  我们要学习过去的经验，同时也要避免让过去的经验妨碍解决现在的问题，MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这样做的好处就是大家对最近的成败记忆犹新，能够提供比较准确和全面的反馈，如果发现错误，立马研究解决方案。
• 与顾客合作( Partner with internal and external customers )
  产品团队与顾客的合作交流是MSF所提倡的，其中“我觉得”和“用户觉得”是两码事，所以要主动和顾客沟通交流，全面了解用户的需求。

---

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

团队和流程

团队

• 主治医师模式(Chief Programmer Team, Surgical Team)
  就像在手术台，上那样，有一个主刀医师，其他人(麻醉，护士，器械)各司其职，为主刀医师服务。这样的软件团队中，有首席程序员(Chief Programmer)，他1她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。佛瑞德.布鲁克斯在主管IBM System 360项目时就采用了这种模式。
• 明星模式(Super-star Model）
  主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子4。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，迈克尔.乔丹说过，“Talent wins games, teamwork wins championship."一些摇滚乐团的团队成员个性非常突出，团队时时都处于解体的边缘。
• 社区模式(Community Model）
  社区由很多志愿者参与，每个人参与自已感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴;或者捡到的柴火质量太差，最后火也就熄灭了。“社区” 并不意味着“随意”，一些成功的社区项目( 例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签人的质量控制。
• 业余剧团模式(Amateur Theater Team)
  这样的团队在每一一个项目(剧目)中，不同的人会挑选不同的角色。在下一个剧目中,这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥(导演)的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在竞争性强烈、创造性要求高的团队，不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。
• 秘密团队(Skunk Work Team)
  一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发Macintosh之后的系统时，就有两三个团队在不同时期进人秘密状态开发。21 世纪的一些创业团队也是处于类似状态。这种模式的好处是:团队内部有极大的自由，较高的热情，没有外界的干扰(不用每周给别人介绍项目进展，听领导的最新指示，等等)。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。
• 特工团队(SWAT)
  就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
• 交响乐团模式(Orchestra)
  交响乐团的演奏有下面的特点。
  • 家伙多，门类齐全。
  • 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
  • 演奏都靠谱，同时看指挥的。
  • 演奏的都是练习过多次的曲目,重在执行。
• 爵士乐模式(Jazz Band)
  • 不靠谱。他们演奏时都没有谱子。
  • 没有现场指挥，平时有编曲者协调和指导乐队，和迈尔斯常年合作的编曲吉尔.伊文斯(GilEvans)也是很有造诣的音乐家。
  • 也有模式,迈尔斯(姑且称之为架构师)先用小号吹出主题，然后他到一旁抽烟去了,其余人员根据这个主题各自即兴发挥;最后迈尔斯加入，回应主题，像是对曲子的总结。
  • 人数较少。
• 功能团队模式(Feature Team)
  很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
• 官僚模式(Bureaucratic Model)
  这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种结构有一-重大隐患，在做绩效评估的时候，各个小老板、中老板都要为自己手下的弟兄们争名夺利，而有意无意地忽略了全局最优的绩效评估标准，导致很多无谓的算计、纠结、甚至有人会贬低别的团队的贡献。

流程

• 写了再改模式(Code- and-Fix)
  这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
  • “只用一次”的程序
  • “看过了就扔”的原型
  • 一些不实用的演示程序
• 瀑布模型(Waterfall Model)
  尽管狭隘定义的瀑布模型有着这样那样的问题，可它还是一个反映人类解决问题思路的常用模型。它在软件工程实践中的局限性在于:
  • 各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来
  • 回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯
  • 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用
  • 如果产品的定义非常稳定，但是产品的正确性非常重要，需要每-一步的验证
  • 产品模块之间的接口、输人和输出能很好地用形式化的方法定义和验证
  • 使用的技术非常成熟，团队成员都很熟悉这些技术
  • 负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流
• 瀑布模型的各种变形
  为了解决瀑布模型的问题，大家在实践中提出了各种变形:
  • 生鱼片模型(各相邻模块像生鱼片那样部分重叠)
    这个模型解决了各个步骤之间分离的缺点，同时也带来了一些困扰——究竟什么时候上一个阶段会结束呢?
  • 大瀑布带着小瀑布
    为了解决不同子系统之间进度不一,技术要求迥异，需要区别对待的问题，有人引入了子瀑布模型：
    在这种瀑布群下，要把各个子系统做到最后做系统测试(System Test)的阶段，难度不是一般的大啊!另外，在这样的开发流程中，用户只有到了最后才能看到结果，用户真是等不起。
• Rational Unified Process统一流程(RUP)
  从瀑布模型开始的各种模型都有-个共同点:重计划，重事先设计，重文档表达。这一类的方法中集大成者要算Rational统一流程( Rational Unified Process, RUP)。RUP把软件开发的各个阶段整合在一个统一的框架里。
  要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程(Discipline)或者工作流(Workflow)。简介如下。
  • 业务建模
    为用户提供软件，就要理解目前用户的业务流程，但是精通计算机语言细节的工程师并不能马上理解对用户活动和期望值的各种自然语言描述。为了解决这个问题，业务建模(Business Modeling)工作流用精确的语言(通常是UML)把用户的活动描述出来。这个词有时也翻译为“商业建模”，但并不是只有存在金钱交易的商业活动才能符合建模的要求，任何和客户的正常工作相关的业务活动(例如政府为居民提供网上服务，学生到图书馆借书)都是建模的对象。这个工作流的结果通常是用例( Use Case) ,后面章节对用例有专门介绍。
  • 需求
    有了用例之后，开发人员和用户(或者用户代表)要分析并确认软件系统得提供什么样的功能来满足用户的需求，功能有什么约束条件,如何验证功能满足了用户需求。这就是需求
    工作流的作用。
  • 分析和设计
    分析和设计(Analysis & Design)工作流将需求转化成系统的设计。这一步结束之后，团队成员就能知道系统有哪些子系统、模块，它们之间的关系是怎样的。
  • 实现
    在实现(Implementation)工作流中，工程师按照计划实现上一步产出的设计,将开发出的组件(Module)，连同验证模块(例如:单元测试)提交到系统中。同时，工程师们集成由单个开发者(或小组)所产生的结果,通过手工或自动化的手段,把可执行的系统搭建出来。
  • 测试
    测试工作流要验证现阶段交付的所有组件的正确性、组件之间交互的正确性，以及检验所有的需求已被正确地实现。在这个过程中，发现、报告、会诊、修复各种缺陷，在软件部署
    之前保证质量达到预期要求。
  • 部署
    部署(Deployment)工作流的目的是生成最终版本并将软件分发给最终用户。具体过程可以参考本书“稳定和发布阶段”一章。
  • 配置和变更管理
    配置和变更管理工作流(Configuration and Change Management)负责管理RUP各个阶段产生的各种工作结果(例如源代码控制系统管理和备份各种源文件)，要记录修改人员、修改原因、修改时间等属性，有些团队还可以考虑并行开发、分布式开发等。
  • 项目管理
    软件项目管理工作流(ProjectManagement)负责平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功地在各个阶段交付达到要求的产品。
  • 环境
    环境( Environment)工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
  • 初始阶段
    此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里(我们的系统究竟和什么别的外部实体打交道)，大致的成本和预算是多少，系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标(Lifecycle Objective)里程碑。
  • 细化阶段
    它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板并准备工具。细化阶段结束时，项目到达了第二个重要的里程碑:生命周期结构( Lifecycle Architecture)里程碑。
  • 构造阶段
    在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。此时的产品版本也常被称为“beta” 版。
  • 交付阶段
    这时候，团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代(betal, beta2 等)，基于用户的反馈，团队利用这些迭代对系统进行修改、调整。除了对功能的调整，团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑:产品发布( Product Release)里程碑。
• 老板驱动的流程(Boss-Driven Process)
  有下面几个因素：
  • 当软件订单的获得不是主要靠技术实力，而是靠个人关系，或者暗箱操作的时候，老板的能力决定了一个团队是否能获得订单，既然软件的具体功能并不重要(或者哪个团队做水平都差不多)，那么老板说做什么就做什么。
  • 在大型企业内部，软件功能往往由行政体系来决定。
  • 有些老板比一般技术人员更懂市场和竞争。
  • 软件团队尚未成熟，不懂得如何独立地进行需求分析，不懂得如何对行政领导有技巧地说“不”，也不知道如何说服利益相关者同意并支持正确的项目方向。既然不能驱动团队成员，那只能靠外力来驱动了。
• 渐进交付的流程(Evolutionary Delivery)，MVP和MBP
  下面几个条件满足一个即可：
  • 时间到了。
  • 钱花光了。
  • 用户满意了（或者很不满意，不再给钱了）。
    MVP——Minimum Viable Product ,最小可行产品,又称为Minimal Feature Set,最小功能集。
• TSP的原则
  • 使用妥善定义的流程，流程中的每- -步都是可以重复、可以衡量结果的。
  • 团队的各个成员对团队的目标、角色、产品都有统一的理解。
  • 尽量使用成熟的技术和做法。
  • 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
  • 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
  • 增加团队的自我管理能力。
  • 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。