软件项目管理用到的相关模型

软件工程的相关模型

螺旋模型
限制条件:
? 适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此
? 适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义)
? 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
优点:
? 设计上的灵活性,可以在项目的各个阶段进行变更.
? 以小的分段来构建大型系统,使成本计算变得简单容易
? 客户始终参为保证了项目不偏离正确方向以及项目的可控性
? 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互.
? 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品.
缺点:
很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求.
核心:
在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚.在定义最重要的功能时,去实现它,然后听取客户的意见,之后再进入到下一个阶段.如此不断轮回重复,直到得到您满意的最终产品
每轮循环包含如下六个步骤:
? 确定目标,可选项,以及强制条件
? 识别并化解风险
? 评估可选项
? 开发并测试当前阶段
? 规划下一阶段
? 确定进入下一阶段的方法步骤.
模型:

快速原型模型
优缺点:
? 优点：克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。　　
? 缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
原型类型:
? 探索型原型:目的是要型清用户的需求,确定所期望的特性,并探索各种方案的可行性。它主要针对开发目标模糊,
? 实验型原型:主要用于设计阶段,考核；实现方案是否合适,能否实陋
? 演化型原型:主要用于及早向用户提交一个原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到用户的认可后,将原型系统不断扩充演变为最终的软件系统
原型的运用方式:
? 抛弃策略是将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的。
? 附加策略是将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略
模型:

增量模型
构件思想:
? 第一构件完成软件提供的基本最核心的功能
? 后面的增构件是为了第一构件提供服务提供功能的
? 而且避免难题退后,首先完成的应该是高风险和重要部分
困难:
每个新的构件集成到现有的软件结构中必须破坏原来以开发的产品,所以必须定义很好的接口
优点:
? 短时间内向用户提供可完成部分工作的产品
? 逐步增加产品功能可以使用户有时间了解和适应新产品
? 开放结构的软件拥有的维护性明显好于封闭结构的软件
缺陷：
? 容易退化为边做边改模型，从而使软件过程的控制失去整体性　
? 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
模型:

演化模型
思想:
演化模型主要针对事先不能完整定义需求的软件开发.用户可以给出待开发系统的核心需求,并且当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现
开发顺序:
? 根据用户的核心需求,设计,编码,测试,后提交用户
? 精化:根据以能满足用户核心需求的核心系统上,增加用户反馈的其他全部功能
优点:
? 任何功能一经开发就能进入测试以便验证是否符合产品需求
? 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
? 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
? 大大有助于早期建立产品开发的配置管理
缺点:
? 主要需求开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性
? 缺乏严格过程管理的话,这生命周期模型很可能退化为“试－错－改”模式
? 不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响

V模型

RAD（Rapid Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。
中文名
快速应用开发
外文名
Rapid Application Development
简 称
RAD
阶段步骤
需求分析、概要设计
阶段步骤
V模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。
需求分析
即首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能，这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。
概要设计
主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
详细设计
对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。
软件编码
按照详细设计好的模块功能表，编程人员编写出实际的代码。
单元测试
按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。
集成测试
经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
系统测试
经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。
验收测试
主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到预期的效果。
对应关系
一般来讲：单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。
验收测试与用户需求对应，是非设计流程。
缺陷及解决
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
适用范围
V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联 软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

RUP模型
摘取链接：https://www.cnblogs.com/W-Juan/p/7590711.html
RUP模型
　　RUP（Rational Unified Process)，统一软件开发过程，是一个面向对象的且基于 络的程序开发方法论。因为RUP相当于一个计划，主要是为开发提供一个步骤，所以说RUP是面向过程的。
　　每种软件开发过程模型都有一个软件生命周期。如瀑布模型的软件生命周期是从可行性分析、需求分析、系统设计等到最后的系统测试与部署。而RUP软件开发过程模型的软件生命周期则分为初始、细化、构造、移交四个过程，稍后会对这四个阶段进行阐述。接下来跟大家分享一下RUP的三大特征。
　　1.RUP特征
(1)用例驱动。即RUP 使用用例模型描述系统的功能需求, 并将用例模型作为系统的核心,。用例是用户与系统之间的交互, 我的理解就是相当于瀑布模型中进行概要设计时所画的用户用例图，主要描述相关功能是被什么角色用户使用。开发人员通过用例模型可以详细地知道每个用户角色具有哪些功能模块。因此所有的设计开发都是以用例模型为中心的。
(2)以构架为中心。以构架为核心是指在开发系统之前首先根据需求确定系统的体系结构, 也就是软件产品表现形式和构建方式,。这就相当于修一座房子，我们首先要搭一个框架，接下来所有的砖瓦水泥都围绕这个框架展开。因此，构架设计师主要关注的是系统的总体框架模型和核心功能的分析设计，后期系统所有的分析设计工作都围绕这个基本构架来扩展。
(3)迭代的、增量式开发。顾名思义，就是一个不断迭代增强的过程。可以是增加系统功能，或者修改某些功能。迭代增量式开发的特征能快速的发布产品，同时迭代可以在原来已经开发好的产品上进行增强修改，加强了与客户之间的需沟通，降低了软件开发的风险。
　　2.软件生命周期
　　RUP模型的软件生命周期中，每个阶段开始时都有一个特定的目标，结束时有里程碑。每个阶段结束前都有一个里程碑评估该阶段的工作，只有通过里程碑评估才可进入下一阶段。并且每个阶段有一个或多个迭代，而每一次迭代都包括了需求分析、设计、实现与测试，又都是一个完整的开发过程。如图所示。
　　
　　RUP软件开发的生命周期是一个二维的软件开发模型。横轴为时间组织，主要体现开发过程的动态结构，可以理解为阶段或者周期。纵轴为内容组织，主要体现开发过程的静态结构，可以理解为工作流。如图所示。

RUP软件生命周期主要分为以下四个阶段：（参考：https://wenku.baidu.com/view/8021e7779b6648d7c0c74601.html）
　(1)初始阶段
　　　· 确定项目的软件范围和边界条件
　　　· 识别系统给关键用例（是确定该项目的软件范围和边界条件的重要条件）
　　　· 展示系统的候选架构
　　　· 预估整个项目的费用、时间安排和风险
　(2)细化阶段
　 · 细化初始化阶段模型
　 · 为项目建立支持环境（创建开发按理、创建模板、准则等）
　　　· 建立健全的体系结构，制定详细的项目计划
　　　· 精化风险评估
　(3)构造阶段
　　　· 资源管理、资源控制和过程优化
　　　· 完成组件开发并进行测试
　　　· 利用构想制定的准则对发布的产品进行评估
　(4)交付阶段
　　　交付阶段主要是确保软件对用户是可用的,可以跨越几次迭代。
　　　· 产品测试并修复系统bug
　 · 制作用户手册并完善相关文档
　　　· 培训用户和维护人员
　　RUP模型在开发过程中，为每个开发人员提供了必要的模板、准则和指导。所有开发人员都严格按照制定好的模板和准则进行开发，极大程度降低了软件开发过程中管理不一致的风险，提高了团队生产力。同时，其迭代和增量式开发的思想也能快速发布产品，提高了工作效率。　　
XP模型

摘取链接：https://www.cnblogs.com/W-Juan/p/7595132.html

XP模型

首先是团队合作。每种软件开发过程模型都强调团队合作，但XP与众多模型不同的是，只要是对项目作出贡献的人，都是团队中的一员，其中包括用户。因为从项目的计划到最后验收，用户才是最清楚自己需求的人。并且不是每个成员的工作别人不能插手，而是互相交流协作的。
　结对编程。在XP中，所有的代码都是由两个程序员在同一台机器上一起写的。或许这一点很难理解，虽然我们常说人多力量大。但是在开发软件项目这件事情上，我们从来都不希望和别人一起编写同一段代码。因为每个人的想法和编程习惯都不一样。但使用XP模型确强行要求执行这一点，而后来事实也证明，这样极大地提高了工作强度和工作效率。毕竟这样做保证了所有的代码、设计和单元测试都至少被另一个人检查复核过。并且在项目开发过程中，对人员流动较大的项目，这是一条很好的策略。
　集体拥有代码。在许多模型中，项目开发之初都会对开发人员进行功能模块的分工，对应功能模块的开发人员只负责维护自己功能，并且他们也不喜欢别人随意修改自己的代码。这就导致开发团队人员互相之间都不了解彼此的功能，也不熟悉彼此的代码。这就使得代码维护具有很大的局限性（因为可能由于负责某一功能的程序员技术的局限性导致维护困难）。但XP中却是大家共同拥有代码，在前面也已经提到，每个成员都可以阅读别人的代码，并发现和纠正其中的错误。这样所有代码都是整个团队共同开发完成的，而不是只是一两个技术较牛的人写的。并且由整个团队所有人开发出来的系统，代码质量都非常好。当然，这样做的基础是每个成员都严格遵循项目开发的代码规范。
3.过程
· 计划项目（PlanningGame）
　　主要预测交付日期前可以完成多少工作，现在和下一步的工作内容有哪些。针对这两个问题，XP中又提出了软件发布计划和周期开发计划两个过程。软件发布计划主要是分析用户需求，制定一个大致的计划。而周期开发计划则是前面提到的，XP把复杂的系统划分为多个
· 验收测试
　　与瀑布模型不同的时，XP模型的验收测试不是在所有软件功能都完成之后再进行测试，而是用户对每个周期完成时所发布的系统进行评估，这样软件开发对用户来说更具有实际意义，也体现了XP作为一种近螺旋式开发方式的特点。同时，验收测试和测试驱动的开发也保证了各个周期所发布的产品的一致性和可靠性。
· 小规模发布
　　即前面提到的，XP模型把复杂的软件开发过程分解为多个周期，将系统分解为多个简单的活动或者任务。因此每个周期开发的需求都是用户需要的东西，XP模型就要求频繁地发布软件，可能的话，应该每天都发布一个新的版本，在对系统某一部分做了修改或者完善之后，也应该立刻发布新版本。

总的来说，XP模型就是为满足用户需求而存在的。不仅让用户参与到开发中来，并且其小规模发布和验收测试也让用户切实感受软件的存在。个人比较喜欢XP模型的核心实践，让人感觉软件开发的过程不那么枯燥和痛苦，而是积极向上。

Scrum模型

Scrum是什么你是软件开发领域资深“程序猿”，一定对这一概念非常熟悉！
Scrum是一种迭代式增量开发过程，通常用于敏捷开发。Scrum大概诞生于1990~1995年之间，由美国软件类资深专家Jeff Sutherland和Ken Schwaber联合提出。发展到今天，Scrum敏捷开发框架已经相当成熟，在软件的实际开发过程中起着非常重要的作用。
Scrum敏捷开发为什么重要r> Scrum英文翻译过来是橄榄球里的“争球”的意思，Scrum是一个框架，基于这一框架模型，人们可以采用适合自己的方法解决复杂问题，同时帮助帮助开发团队实现价值最大化，比如提高成产能力，加大团队的创造力等等。随着Scrum的深化发展，它不只是用来管理项目开发，还被用于运维团队的维护，以及企业的计划管理。

Scrum的代名词是“简单”、“轻量级”、“对复杂工作的把控”。在Scrum框架中，开发人员可以设计复杂项目的管理流程，包括产品规划管理、软件开发预期结果等。并且，我们还可以对和所有过程相关的要素进行持续改进，包括产品、团队和工作环境等。Scrum框架主要包括四个部分，即角色、事件、工件和规则，每一个组件都为Scrum最终目标服务。从最初为管理者和产品负责人而设计，到后来被用于全球范围内的市场、技术和产品研发。今天，Scrum框架已经被应用于更广泛的领域，包括各类软件产品开发、产品发布以及云产品（包括公有云、私有云、混合云）的构建等。
从具体的应用场景看，Scrum被用于软件、硬件开发，无人车的自动驾驶，学校、政府里面的市场营销、运营，以及个人在 会生活中的日常行为规划等。
如何把Scrum敏捷方法付诸于实践r> 尽管，IT技术正在快速迭代，市场上也出现了各种各样的新理念，但是Scrum一直是众多企业最理想选择。Scrum属于渐进式、迭代式，开发人员可逐步优化预期目标，并且能控制风险。借助过往经验，对过程进行控制，是Scrum一直被高度认可的最根本原因。
至于，何时用Scrum的公司会有不同的选择。大体来看，开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作，这样的团队基本是6-10人的团队。并且，整个团队已经有了一定的经验沉淀。另外，团队成员中要有一个Scrum master，作为整个团队的组织者和管理者，他是Team Leader和Product owner的粘合剂，可以及时地为团队成员提供帮助。
如何对整个过程进行控制rum 采用迭代、增量的方法来优化可预见性并控制风险。
具体而言，主要通过三大支柱支撑起每个过程控制的实现：
1、透明性：透明度是指，在软件开发过程的各个环节保持高度的可见性，所有参与人员都保持共同的过程认知。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须让所有人对已完成过程同步知晓。
2、检验：整个团队必须不断检查Scrum工件，并朝着sprint冲刺目标前进，用以识别重大偏差。这一过程应于熟悉整个流程的人来执行。
3、适应：如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
上述所有检查和调整可通过Sprint计划、每日例会、Sprint冲刺评审、Sprint冲刺回顾来实现。
Scrum的核心价值观是：承诺、勇气、集中注意力、开放和尊重。整个团队由产品负责人、开发团队和管理员组成。团队成员可以是自行组织，也可以跨职能、跨部门。这种团队组成形式为项目开发提供了更大的灵活性和便利性。自行组织的团队可以避免不了解项目的人来领导，而跨职能、跨部门的组织架构，每个人都是团队中最重要成员，更能体现以项目为核心的理念，大大提高了生产力和创造性。
总之，Scrum 敏捷就是一种不停尝试、不停调整、不停优化的状态。它能把复杂的项目拆分成易于实践的任务，从而持续高效地帮助项目落地。当然，任何 一个撇开实践谈敏捷的理论都是“耍流氓”，要想让Scrum发挥最大价值，还要结合软件开发的实际情况，具体问题具体分析。先从一点入手，然后过度到最佳状态。

DevOps模型

方法二：《精益思想》中推荐的行动计划

成熟度模型：