常见的软件过程模型
常见的软件过程模型
瀑布模型
瀑布模型的特点：
-
阶段具有顺序性和依赖性：
前一阶段结束后一阶段开始，前一个阶段输出文档，后一个阶段输入文档。
-
推迟实现观点:
瀑布模型在编码前设置系统分析、系统设计，推迟程序物理实现，保证前期工作扎实。
-
质量保证观点:
瀑布模型每阶段坚持两个重要做法:
一是每阶段都必须完成完整、准确的文档。软件开发时人员间通信、运行时期维护的重要依据。
二是每阶段结束前对文档评审。
瀑布模型图：
带反馈环的瀑布模型图：
传统瀑布模型过于理想化，但人在工作过程中不可能不犯错误，所以实际瀑布模型带反馈环。
瀑布模型的优点：
提高软件质量，降低维护成本，缓解软件危机。
瀑布模型的缺点：
模型缺乏灵活性，无法解决需求不明确问题。用户不经过实践提出完整准确需求不切实际。
快速原型模型
快速原型模型的特点：
快速建立反映用户主要需求的原型系统，反复由用户评价修正需求，开发出最终产品。
快速原型模型图：
快速原型模型的优点：
-
确定需求上优于瀑布模型（通过原型与用户交互）；
-
提供学习手段，通过开发原型和演示原型对开发者和使用者了解系统都有积极作用；
-
有的软件原型可以成为最终产品的一部分。
快速原型模型的缺点：
- 快速建立的系统结构加连续修改可能导致产品质量低下原型系统的内部结构可能不好。
增量模型
增量模型特点：
又称渐增模型，开发软件时将软件产品作一系列增量构件设计、编码、集成和测试。
区别于瀑布和快速原型模型：
-
瀑布和快速原型模型是一次把满足所有需求产品提交给用户。
-
增量模型是分批向用户提交产品。
增量模型图：
增量模型的优点：
- 较短时间向用户提交可完成有用工作产品；
- 用户有充裕时间学习适应产品；
- 软件结构必须开放，方便向现有产品加入新构件。
增量模型的缺点：
- 做到第三个优点有些困难。
风险更大增量模型：
-
前述增量模型在实现构件前完成总体的需求分析、规格说明和概要设计，相对来说风险较小。
-
风险更大增量模型：确定用户需求后，各构件集并行构建。
风险更大的增量模型图:
螺旋模型
螺旋模型特点：
- 1988年B.Boehem提出，加入风险分析，常指导大型软件项目。
软件风险：超期、超预算、行业竞争等
笛卡尔坐标四象限表达四方面活动：
-
制定计划：确定目标、选定方案、设定约束条件。
-
风险分析：评估方案，识别和消除风险。
-
实施工程：软件开发
-
客户评估：评价开发工作，计划下一阶段工作。
-
沿螺线自内向外每旋转一圈开发出更完善新版本。
螺旋模型图：
螺旋模型优点：
- 大型软件开发项目有较好的风险控制；
螺旋模型缺点：
-
需要风险评估的经验；
-
契约开发通常需要事先指定过程模型和发布产品
-
普及不如前述模型
喷泉模型：
喷泉模型特点：
- 面向对象生命周期模型，体现迭代和无缝特性。
- 迭代：求精，系统某部分常被重复工作多次，相关功能在每次迭代中逐渐加入演进系统。
- 无缝：分析、设计、编码各阶段间不存在明显边界。
喷泉模型图：
喷泉模型优点：
- 无缝，可同步开发，提高开发效率，节省开发时间，适应面向对象软件
喷泉模型缺点：
- 可能随时加各种信息、需求与资料，需严格管理文档，审核的难度加大.。
Rational统一过程
Rational统一过程特点：
- 由Rational软件公司推出的一种软件过程，该过程强调以迭代和渐增方式开发软件。
- Rational统一过程是一个二维生命周期模型。
Rational统一过程图：
- RUP有9个核心工作流，包括6个核心过程工作流和3个核心支持工作流。
- RUP有4个连续阶段，每个阶段有明确目标，通过一次或多次迭代完成。
Rational统一过程优点：
-
不断的版本发布成为一种团队日常工作的真正驱动力；
-
将发现问题、制定方案和解决过程集成到下一次迭代；
-
迭代开发，降低风险；
-
更好地安排产品开发的辅助过程。
敏捷过程与极限编程模型：
敏捷过程：
- 目的：为了使软件开发团队具有高效工作和快速响应变化的能力。
4个价值观宣言：
-
个体和交互胜过过程和工具
-
可以工作的软件胜过面面俱到的文档
-
客户合作胜过合同谈判
-
响应变化胜过遵循计划
极限编程模型特点：
- 适合于小团队开发
- 是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。
- 是一种近螺旋式的开发方法。
- 将复杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
极限编程关注的重点
极限编程是一种开发管理模式，它强调的重点是角色定位、敏捷开发、追求价值。
-
角色定位。
极限编程把用户非常明确地加入到开发的团队中，并参与日常开发与沟通会议。
-
敏捷开发。
敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期的方法，发布周期可缩短到周、日，完成一个小的功能模块，可以快速测试并及时展现给用户，以便及时反馈。
-
追求价值。
极限编程把软件开发变成自我与管理的挑战，追求沟通、简单、反馈、勇气，体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，情绪高涨，认真投入，开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。
极限编程模型图：
- 极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了“测试→编码→重构（设计）”的软件开发管理思路。
极限编程的应用原则:
极限编程的12个实践是极限编程者总结的经典实践，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。
-
小版本。
为了高度迭代，向用户展现开发的进展，小版本发布是一个可交流的好办法，用户可以有针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连续性，所以小版本也需要总体合理的规划。
-
规划游戏。
用户需求，以用户故事的形式，由用户负责编写。极限编程不追求统一的用户需求收集，也不是由开发人员整理，而是采取让用户编写，开发人员分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次迭代，每次迭代完毕后再行修改。用户故事是开发人员与用户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的，沟通一定是顺畅的。
-
现场客户。
极限编程要求用户参与开发工作，用户需求就是用户负责编写的，所以要求用户在开发现场一起工作，并为每次迭代提供反馈。
-
隐喻。
隐喻让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为对业务的专业术语开发人员不熟悉，用户又不理解软件开发的术语，因此首先要明确双方使用的隐喻，避免产生歧义。
-
简单设计。
极限编程体现跟踪用户的需求变化，既然需求是变化的，所以对目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，势必会增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括4个方面含义：通过测试；避免重复代码；明确表达每步编码的目的，代码可读性强；尽可能少的对象类和方法。由于采用简单的设计，所以极限编程没有复杂的设计文档要求。
-
重构。
重构是极限编程先测试后编码的必然需求，为了使整体软件可以先进行测试，对于一些软件要开发的模块，先简单模拟，让编译通过，到达测试的目的；然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。
-
测试驱动开发。
极限编程是以测试开始的，为了可以展示用户需求的实现，测试程序优先设计，测试是从用户实用的角度出发的，从用户实际使用的软件界面着想，测试是用户需求的直接表现，是用户对软件过程的理解。测试驱动开发，也就是用户的需求驱动软件的开发。
-
持续集成。
集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成（整体测试）是与用户沟通的依据，也是让用户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。
-
结对编程。
这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个人编码，一个人检查，增加专人审计是为了提高软件编码的质量。经常变换两个人的角色，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。
-
代码共有。
在极限编程里没有对文档进行严格管理，代码为开发团队所共有，这样有利于开发者的流动管理，这是因为所有人都熟悉编码。
- 编码标准。
编码是开发团队中每个人的工作，没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些像编码人员的隐喻。
- 每周40小时工作。
极限编程认为编程是一种愉快的事件，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。
微软过程：
微软过程的各个阶段：
- 规划阶段
开展市场调查研究，结合公司战略形成产品的远景目标。
- 设计阶段
根据产品远景目标，完成软件功能规格说明和总体设计，确定产品开发的主要进度。
- 开发阶段
完成产品中所有构件的开发工作。
- 稳定阶段
实行全面的内部和外部测试，最终形成可发布的RTM版本
- 发布阶段
确认产品质量符合发布标准后，发布产品及相关消息