202210-团队9527 实验五 团队作业2：软件项目案例分析

项目	内容
课程班级博客链接	19卓越
这个作业要求链接	实验五 团队作业2
团队名称	团队9527
团队的课程学习目标	（1）学习团队软件项目流程（TSP）、软件项目团队的角色分工，软件项目经理的职责。（2）掌握敏捷流程原则及相关概念。（3）软件案例分析。
在实现学习目标方面的帮助	（1）掌握团队软件项目的流程。（2）明确了团队分工，并使团队成员职责清晰
团队博客链接	团队9527

• 任务一 以团队协作学习方式，阅读《现代软件工程—构建之法》第5、6章内容，理解并掌握软件项目团队的特点和模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；阅读《现代软件工程—构建之法》第9章内容，了解软件项目团队设置项目经理的缘由、项目经理的职责。

  • 1.软件项目团队的特点和模式
    软件项目团队的特点：（1）团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作,例如接力赛跑。（2）团队成员有各自的分工，互相依赖合作，共同完成任务。王屋村搬砖的“非团队”成员则是各自行动，独立把任务完成,有人不辞而别，对其他的搬砖人无实质影响。
    软件项目团队模式：
    （1）主治医师模式：这样的软件团队中,有首席程序员(Chief Programmer ),他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作(（后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。佛瑞德·布鲁克斯在主管IBM System 360项目时就采用了这种模式。
    （2）明星模式：主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用。
    （3）社区模式：社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴;或者捡到的柴火质量太差，最后火也就熄灭了。“社区”并不意味着“随意”，一些成功的社区项目（例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签入的质量控制。
    （4）业余剧团模式：这样的团队在每一个项目（剧目)中，不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在竞争性强烈、创造性要求高的团队,不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。
    （5）秘密团队：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。21世纪的一些创业团队也是处于类似状态。这种模式的好处是:团队内部有极大的自由，较高的热情，没有外界的干扰。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。
    （6）特工团队：就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
    （7）交响乐团模式：当某个软件领域处于稳定成多长阶段的时候，众多大型软件公司的开发团队就会采取这种模式，例如微软公司的Office软件，从 Office 97、Office XP、Office 2003、Office 2007....
    （8）爵士乐模式：热闹的角度看,和交响乐团相比,这种模式有以下特点。不靠谱。他们演奏时都没有谱子。没有现场指挥，平时有编曲者协调和指导乐队，和迈尔斯常年合作的编曲吉尔·伊文斯( Gil Evans)也是很有造诣的音乐家。也有模式,迈尔斯(姑且称之为架构师)先用小号吹出主题,然后他到一旁抽烟去了,其余人员根据这个主题各自即兴发挥;最后迈尔斯加入，回应主题，像是对曲子的总结。人数较少。
    （9）功能团队模式：很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。在这个功能完成之后,这些人又重新组织,和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。这些功能小组也称为Feature Crew，小组内的交流比较频繁。
    （10）官僚模式：这种模式脱胎于大机构的组织架构,几个人报告给一个小头目，几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导,同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难,因为各自头顶上都有不同的老板。

  • 2.瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点
    （1）瀑布模型及其变形
    瀑布模型：瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
    瀑布模型的变形：生鱼片模型：生鱼片模型(各相邻模块像生鱼片那样部分重叠)这个模型解决了各个步骤之间分离的缺点,同时也带来了一些困扰——究竞什么时候上一个阶段会结束呢?
    
    大瀑布带着小瀑布：为了解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题，引入了子瀑布模型：在这种瀑布群下，要把各个子系统统一到最后做系统测试的阶段，在这样的开发流程中，用户只要到了最后才能看到结果。
    
    （2）渐进交付流程
    渐进交付流程：它试图将复杂的项目进行分阶段拆解，通过持续进行小型闭环迭代降低交付成本和时间。当系统的主要需求和架构明确之后，软件团队进去了一个不断演进的循环之中（开发→发布→听取反馈→根据反馈做改进）。
    
    MVP-Minimum Viable Product,最小可行产品,又称为Minimal Feature Set,最小功能集。
    具体的做法是:把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。例如，一个社交网站已经有很多用户，都是免费的，产品团队想设计一个付费的VIP服务，MVP的做法可以是这样—在目前的用户入口页面中加一个“VIP服务”的链接,指向一个简单的介绍页面（用最小成本做出来）。观察到底有多少用户点击这个链接。如果点击量太小，那么这个VIP服务就不用做了。
    （3）敏捷流程
    敏捷流程：敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
    特征：
    迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周；
    增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品；
    开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见；
    持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成，有些项目则每天都在这么做；
    开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人；
    （4）Rational Unified Process统一流程（ RUP)
    从瀑布模型开始的各种模型都有一个共同点:重计划，重事先设计，重文档表达。这一类的方法中集大成者要算Rational统一流程(Rational Unified Process，RUP ) 。RUP把软件开发的各个阶段整合在一个统一的框架里。要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程( Discipline）或者工作流( Workflow )。简介如下。

    • 业务建模：业务建模( Business Modeling)工作流用精确的语言（通常是UML)把用户的活动描述出来。这个词有时也翻译为“商业建模”，但并不是只有存在金钱交易的商业活动才能符合建模的要求，任何和客户的正常工作相关的业务活动（例如政府为居民提供网上服务，学生到图书馆借书）都是建模的对象。
    • 需求:有了用例之后，开发人员和用户（或者用户代表）要分析并确认软件系统得提供什么样的功能来满足用户的需求，功能有什么约束条件，如何验证功能满足了用户需求。
    • 分析和设计︰分析和设计(Analysis & Design)工作流将需求转化成系统的设计。
    • 实现：在实现(Implementation)工作流中，工程师按照计划实现上一步产出的设计，将开发出的组件（Module)，连同验证模块（例如:单元测试）提交到系统中。
    • 测试 ：测试工作流要验证现阶段交付的所有组件的正确性、组件之间交互的正确性，以及检验所有的需求已被正确地实现。在这个过程中，发现、报告、会诊、修复各种缺陷，在软件部署之前保证质量达到预期要求。
    • 部署：部署(Deployment)工作流的目的是生成最终版本并将软件分发给最终用户。
    • 配置和变更管理：配置和变更管理工作流(Configuration and Change Management )负责管理RUP各个阶段产生的各种工作结果（例如源代码控制系统管理和备份各种源文件)，要记录修改人员、修改原因、修改时间等属性，有些团队还可以考虑并行开发、分布式开发等。
    • 项目管理：软件项目管理工作流（Project Management)负责平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功地在各个阶段交付达到要求的产品。
    • 环境：环境（Environment)工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。

    （5）RUP四个阶段的介绍

    • 初始阶段——此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里，大致的成本和预算是多少，系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标里程碑。
    • 细化阶段——它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功。
    • 构造阶段——在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑:初始功能( Initial Operational )里程碑。此时的产品版本也常被称为“beta”版。
    • 交付阶段——团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代，基于用户的反馈，团队利用这些迭代对系统进行修改、调整。除了对功能的调整，团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑:产品发布里程碑。

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

  • 4.了解软件项目团队设置项目经理的缘由、项目经理的职责。
    （1）软件项目团队设置项目经理的缘由：在软件项目的设计与实现之中，有一些问题是程序员不愿意花时间去做，例如：和客户交谈，组织用户调查，发现用户需求；了解和比较竞争对手的产品；怎么让软件变得可用、有用；如何改进团队流程。
    （2）项目经理的职责
    ①带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计;
    ②管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰);
    ③创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导,而不是障碍;4．代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级;
    ④分析并带领其他成员对缺陷/变更需求形成一致意见，并确保实施;
    ⑤带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件;
    ⑥收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。
    团队协作学习内容
    

• 任务二 以团队协作学习方式，从B、C、D三个软件案例分析任务中选择一个课题来进行。案例分析任务来源参考链接：https://blog.csdn.net/SoftwareTeacher/article/details/119166747
  选择任务案例B

B）很多开发人员和IT专业的学生都在移动设备上学习、工作、社交，在移动设备上的APP 能满足这类目标用户的需求么？这类APP会被微信公众号取代吗？ 请试用并分析 CSDN App功能（下载链接是：https://www.csdn.net/app/）， 例如：点击 App 的首页下方正中间的那个 “动态” 按钮，打开后的微社区，就是大家要分析的动态功能， 可以在 “动态” 中发布几个动态，看看你的城市有哪些IT行业的网友。

• 团队各位成员花几天时间至少使用 <被评测软件>5次, 成为<被评测软件>的持续使用者，记录每位成员使用的时间和时长。

成员	使用时长(h)
梁春云	3
李治江	2
李健康	2

• 汇总<被评测软件> 解决了你们什么问题？ <被评测软件>在数据量/界面/功能/准确度上各有什么优缺点? 用户体验方面有问题么？
  （1）解决了在移动端方面阅读和学习CSDN的内容，也可以更方便的分享和查阅最近的程序员之间的日常和知识。
  （2）数据量：内容丰富，涉及许许多多的层面，有编程软件方面，有语言方面，还有学习方面；没有明显的缺点；界面：界面排版整洁，各个内容板块分区也很直观；功能：每个用户都可以免费上传自己的文章和程序，但是其他用户下载和阅读时却受到限制；准确度：软件中的大部分文章具有一定的参考性，且内容也比较通俗易懂，但是在上传自己的程序模块时，具有比较大的错误引用。
  （3）在用户体验方面，可以允许大量的程序员在平台上相互交流，也能把其当作一个学习软件和资源库，但是在资源的获取方面，建议可以授予用户少量的资源获取资格，或者通过推广软件获得资源下载资格。
• 将<被评测软件>推荐给你们周围需要这样的软件朋友或同学, 记录你对这位用户使用体验的采访，记录采访提要如下：

1） 介绍这位用户的背景和需求 (他们为何要用这个软件/网站， 有什么痛点，还有别的需求吗？)
2） 请这位用户使用10 分钟 <被评测软件> 的基本功能 ，上传用户使用<被评测软件>的照片
3） 概述用户使用<被评测软件>的过程, 评判这位用户的问题解决了么?
4） 采访这位用户对产品有什么改进意见?

（1）测试用户为西北某高校本科生，由于在Python安装第三方库时，总是需要pip，为此，需要在本软件中寻找能否避免或者解决这一问题。

（2）上传用户使用被测评软件的照片：



（3）用户在我们的请求下使用了CSDN APP，首先进行了注册：

然后在我们的指导下搜索了关键词：Python、pip、自动：

最后寻找到了目标文章。
在经过我们的询问后，这位用户一步步的按照文章的内容操作后，成功地解决了自己的问题。


（4）采访用户对软件的改进意见如下：

• 部分资源的下载和使用需要用户支付一定的金额，可以适当放宽条件；

• 可以建造一个自己的软件分享圈子，方便与好友分享一些好的文章和算法；

• 可以看到商城中有一些课程的学习和程序源码都是需要支付部分费用来使用和学习的，建议先免费使用一部分，然后在让用户根据自己的使用体验决定是否继续使用。

• 本次作业各项任务实际花费时间

任务	时间(min)
任务1	40
任务2	65
采访	30
总结	15
任务3	85

• 本次作业的感受和体会

姓名	感受与体会
梁春云	通过本次软件工程小组项目，我对于“合作”有了真正的认识。在团队合作过程中，我们各司其职，分工明确，这样使得我们团队任务顺利推进，这也恰巧说明了多人合作能够带来1+1>2的效果。
李健康	在本次作业的完成过程中，本团队的每个成员都承担了一定的工作量，在团队组长的带领下，我们进行了线上线下的会议讨论，大家很快达成了的目标上的一致，明确分工快速完成了任务。
李治江	本次作业是我们团队的第二次协作，在经过了上一次的团队协作后，在本次任务中我们互相配合起来更加的得心应手，效率更高。团队也能够更加快速的分工并完成，加深了团队成员之间的默契，相信在之后的合作中越来越好。