201771010105—达拉草 实验四 软件项目案例分析

项目	内容
课程班级博客连接	https://www.cnblogs.com/nwnu-daizh/
这个作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
我的课程学习目标	（1）学习团队软件项目流程（TSP）、团队成员协作要求。（2）掌握敏捷流程原则及相关概念。
这个作业在哪些方面帮助我实现学习目标	让我了解了团队项目的相关流程、特点
结对方学号——姓名	201771010104——狄慧
结对方本次博客作业连接	https://www.cnblogs.com/dhlll/p/12669888.html

1.实验的目的与要求

（1）学习团队软件项目流程（TSP）、团队成员协作要求。
（2）掌握敏捷流程原则及相关概念。

2.实验内容与步骤

任务一、在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价

选择实验三优秀案例：王之泰&韩腊梅组
案例作业博客链接：https://www.cnblogs.com/hanlamei/p/12574378.html
案例作业项目仓库链接：https://github.com/YHwzt/Query-system-web

• 对博文的评论：
  

• 克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码

  • 克隆项目源码到本地机器：
    
    

  • 运行代码：
    注册界面：
    
    
    登录界面：
    
    
    以学生和教职工身份登录能填写信息：
    
    
    
    以学院的身份登录可以查看疫情信息：
    
    
    以学校身份登录可以查看、删除、导出信息：
    
    

• 对案例的总结以及代码设计的不足与问题：
  代码实现的功能：

  • 三级注册登录功能，并对每个级别用户做出功能使用的限制。
  • 一级登录学生和教职工可以填写信息。
  • 二级登录以学院身份登录可以查看疫情信息。
  • 三级登录以学校身份登录可以查看、删除、添加、导出等功能。
  • 还有附加功能提醒用户填写疫情信息。
    通过对代码的运行以及系统的使用发现这个系统的功能基本全面，通过对他们组的项目的学习，我明显的认识到了我们的差距。上次的实验我们组没能实现信息的可视化，以及Excel的导出，但他们不仅都实现了还实现了附加功能，所以值得我们去学习。
  • 问题：可以对代码不必要的行进行删改，以便更简洁。

任务二、与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；

• 团队的特点：

  • 团队有一致的集体目标，要一起完成这个目标，但一个团队的成员不一定要同时工作。
  • 团队成员有各自的分工，互相交流合作，共同完成任务。

• 团队的模式：

  • 主治医生模式（Chief Programmer Team）
    这样的软件团队中，有首席程序员，他负责处理主要模块的设计和编码，其他成员各司其职，从各种角度支持他的工作。

  • 明星模式（Super-star Model）
    这种模式就是主治医师模式运用到极致的模式，在这里明星的光芒盖过了团队其他人的总和。

  • 社区模式（Community Model）
    社区一般都有很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量。社区不意味着随意，成功的社区项目有很严格的代码复审和质量控制。

  • 业余剧团模式（Amateur Theater Team）
    在这样的团队中，每个人会挑选不同的角色，下一个项目中这些人也许会换一个完全不同的角色类型。每个人在团队中听从一个中央指挥的安排，互相交流学习，但是在竞争性比较强的团队中不会存在完美的民主氛围。

  • 秘密团队（Skunk Work Team）
    这种秘密状态开发的好处是团队内部有极大的自由，没有外界的干扰（介绍项目、听从指示等），一般这样的团队拥有独特的使命，很大的自由度，所以往往能够发挥超高的效率完成看似不可能的任务

  • 特工团队（SWAT）
    这样的团队由一些有特殊技能的专业人士组成，负责解决一些棘手又紧迫的问题，如安全性服务团队。

  • 交响乐团模式（Orchestra）
    当某个软件处于稳定成长阶段时，很多的开发团队就会采用这种模式，该模式下的各成员各司其职，负责的部分各不相同，而且每个成员专门处理类似的问题，大家都很专业，由指挥统领全局。

  • 爵士乐模式（Jazz Band）
    与交响乐团相比，该模式的成员职责不固定，不专门处理类似的问题，没有统一的指挥，各自即兴发挥。这种模式强调个性化的表达，强有力的互动。

  • 功能团队模式（Feature Team）
    很多开发团队采用这种模式，每个小组内具备不同能力，负责不同部分的同事们平等协作，共同完成一个功能。在这个功能完成之后，这些人又重新组织和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。小组内的交流比较频繁。

  • 官僚模式（Bureaucratic Model）
    这种模式出现于大机构的组织架构，几个人报告给一个小头目，几个小头目再汇报给上一级。这种模式成员之间不仅有技术方面的合作，还有组织上的领导关系，因为团队不同难以绩效评估，导致很多无谓的算计。

• 瀑布模型：
  这个模型是从其他成熟行业，如建筑工程，借用来的，这些“硬”行业的产品一旦大规模生产，要再返回去修改就非常困难，这个模型就描述了这种单向的、不可逆的生产过程。

  温斯顿对这个模型的缺陷也提出了改进的方法：

  • 温斯顿指出在做大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题。
    

  • 温斯顿指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。
    

• 瀑布模型的局限性：

  • 软件生产过程中各步骤之间是分离的。
  • 回溯修改很难甚至不可能，但是实际开发中回溯需要时时回溯。
  • 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。

• 瀑布模型的变形：

  • 生鱼片模型：这种模型的各相邻模块像生鱼片那样部分重叠，解决了各步骤之间分离的缺点
    

  • 子瀑布模型：它解决了各子系统之间进度不一，技术要求不同，需要区别对待的问题
    

• 渐进交付的流程（Evolution Delivery）、MVP和MBP
  渐进交付这种模式比较接近于迭代式开发流程，当需求和架构基本明确后，软件团队进入了一个不断演进的循环中。

  • MVP（Minimum Viable Product）流程的核心是把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见，这样就不至于拖了很久弄好第一版，结果用户没有购买意愿的尴尬局面。MVP的思想和渐进交付类似，但是它更强调用户的反馈。
  • MBP（Maximal Beautiful Product）是与MVP相对的一种模式，它把产品最全、最美的形态都展现出来，一举征服用户。

• 敏捷流程：
  “敏捷流程”是一系列价值观和方法论的集合。
  敏捷开发的原则：

  • 持续地交付有价值的软件以满足顾客需求；
  • 敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势；
  • 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
  • 业务人员和开发人员在项目开发过程中应该每天共同工作；
  • 以有进取心的人为项目核心，充分支持信任他们；
  • 无论团队内外，面对面的交流始终是最有效的沟通方式；
  • 可用的软件是衡量项目进展的主要指标；
  • 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
  • 只有不断关注技术和设计，才能越来越敏捷；
  • 保持简明---尽可能简化工作量的技艺---极为重要；
  • 只有能自我管理的团队才能创造优秀的架构、需求和设计；
  • 时时总结如何提高团队效率，并付诸行动。

• TSP原则：
  优秀的模式和流程都有一些共同点，这些共同点抽象总结为TSP（Team Software Process）原则：

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

• 与结对方交流的截图：
  
  
  
  
  

任务三、：在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。

1. 2016级计算机科学与工程学院软件工程 (西北师范大学)

2. 2019秋福大软件工程实践Z班 (福州大学)

3. 2019春季计算机学院软件工程 (北京航空航天大学)
   我们选用的是2019春季计算机学院软件工程 (北京航空航天大学)这个项目

• 1.团队项目作业发布账号链接：https://www.cnblogs.com/PureMan6
• 2.团队项目仓库GitHub链接：https://github.com/swearitagain/EduCnblogs2.0
• 3.陈述你选择该团队项目进行分析的理由：
  • 在这次的学习中可以有机会看看其他学校的学生做的项目。
  • 这个项目做的博客园的APP，而我们一直也在用，还有就是之前没接触过关于APP开发的，所以比较感兴趣。
• 4.结合项目系列博客文档，总结项目团队成员的分工合作情况

团队成员	分工
吴昊	开发人员，Scrum Master，负责主持每日例会
邵旭哲	PM，负责博客撰写
胡俊崧	开发人员
蒋锋	开发人员
陈治齐	开发人员
吴枫	测试人员

• 5.结合项目系列博客文档，评价项目的软件项目过程特点（TSP）
  软件项目过程的特点：

  • 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
  • 团队的各个成员对团队的目标、角色、产品都有统一的理解 。
  • 团队的自我管理能力很强，基本每个阶段都有开例会，进行交流。
  • 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
  • 争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。

• 6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
  
  该项目的GitHub上没有项目的编码规范的文档，以及开发说明，所以对于后面进行开发的人来说会有点难度和麻烦。

• 下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图。

  • 从仓库clone到本地测试：
    

  • 下载APP进行体验：
    作为一款手机端使用的APP，我觉得这个项目开的很好，因为我使用的感觉很方便，而且界面也简单美观，方便使用。
    登录界面与网页一样：
    
    验证的界面，界面简单美观：
    
    各个功能：
    我的博客：
    
    我的班级：
    
    
    我的个人个人信息：
    
    
    

  • 存在的功能不足：
    黑暗模式对部分页面还不支持：
    
    发布投票的时候显示有错误，但是其实是发布成功的：
    
    
    添加了一个问题后，没有删除功能，不是特别方便：
    
    发布的投票，按删除没有作用：
    
    

• 7.评价该团队项目是否值得继续开发，并陈述理由？
  我觉得这个团队的项目值得继续开发，因为博客园的这种APP不是很多，我在应用商店搜了一下好像有3个左右，我下载了其中一个发现就是比这个多了博客的推送这些。其实我个人比较喜欢这个，因为这个有专门的班级博客区，用起来很方便。所以我觉得这个项目值得继续开发，把这些功能更加完善一下会很好。

任务四：记录完成《实验四 软件项目案例分析》各项任务实际花费的时间

任务	花费时间（min）
任务一	200
任务二	180
任务三	220
任务四	90

任务五：请谈谈完成本次作业的感受和体会。

在这次的实验我测试了上次项目的优秀案例，我还测试了其他高校的软件工程团队的项目。通过这次的实验我了解了软件工程团队项目的流程，有很多值得学习的东西，也认识到了自己与其他人的差距。在任务二的学习过程中与结对同伴一起交流学习了软件项目团队的特点、软件团队的模式、瀑布模型及其变形和TSP原则等。