1. 传统软件过程模型

1.1 瀑布模型Waterfall model

特点：线性模型、阶段间具有顺序性和依赖性、具有推迟实现的观点。
瀑布模型是一种使用广泛、以文档为驱动的模型，每个阶段都有与之相关联的里程碑和可交付的产品，每个阶段结束前完成文档审查，及早改正错误。

• 实际使用的都是带反馈的瀑布模型
  
• 瀑布模型缺点
  1. 增加工作量：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
  2. 开发风险大：由于开发模型是线性的。用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
  3. 早期错误发现晚：早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
  4. 不适应需求变化：不能反映实际的开发方式，软件开发需要迭代；无法适应需求不明确和需求的变化。
     瀑布模型适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗。

1.2 V模型

上层出现问题，则逐级下沉来修复。

1.3 原型模型（降低需求不明确的风险）

原型化模型、快速原型模型。

原型prototype:一个部分开发的产品，是客户和开发人员能够对计划开发的系统的相关方面进行检查。如图书借阅系统：主要界面、智能家居系统：少量室内信息监视和电器控制。

原型化的目的：明确并完善需求，如演示原型；研究技术选择方案，如技术验证原型。

原型结果：抛弃原型；把原型发展成最终产品。

原型模型的优缺点：

• 优点：减少需求不明确带来的风险
• 缺点：构建原型采用的技术和工具不一定主流；快速建立起来的系统加上连续的修改可能导致原型质量低下；设计者在质量和原型中进行折中；客户意识不到一些质量问题。
• 适用场景：客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时原型模型是很好的选择。

1.4 增量模型（降低需求变化风险）

增量：满足用户需求的一个子集，能够完成一定功能、小而可用的软件。例如文字处理软件：

• 增量模型
  
  

• 增量方式：增加新功能和迭代优化
  

• 增量模型特点
  增量模型是一种非整体开发的模型，是一种进化式的开发过程。
  增量模型从部分需求出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善。
  如此反复进行，直至软件人员和用户对所设计的软件系统满足为止。
  增量模型结合了原型模型的基本要素和迭代的特性，采用了基于时间的线性序列，每个线性序列都会输出该软件的一个增量。
  每个增量的开发可用瀑布或快速原型模型。

• 增量模型优缺点
  优点：

  1. 增量概念的引入，不需要提供完整的需求，只要有一个增量出现，开发就可以进行；
  2. 软件能够更早投入市场；
  3. 在项目的初始阶段不需要投入太多的人力资源；
  4. 开放式体系结构，便于维护；
  5. 产品逐步交付，软件开发能够较好地适应需求的变化；
  6. 能够看见软件中间产品，提出改进意见，减少返工，降低开发风险。

缺点：

1. 每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量；
2. 软件必须具备开放式体系结构（困难）；
3. 易退化成边做边改的方式，使软件过程控制失去整体性。

1.5 螺旋模型

软件开发的风险：交付的产品用户不满意、产品不能按时交付、开发成本超过预算、产品开发期间关键开发人员离职、产品投入市场前竞争对手发布功能相近价格更低产品……

螺旋模型：把产品活动和风险管理结合起来控制风险。分为4个工作周期：制定计划、风险分析、实施工程、用户评估。

• 典型迭代过程：
  
• 螺旋模型优缺点
  优点：
  1. 螺旋模型强调原型的可扩充性和可修改行，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力，支持用户需求的动态变化；
  2. 原型可看作可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供看了方便；
  3. 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。

缺点：

1. 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟交付时间；
2. 使用该模型需要相当丰富的风险评估经验和专门知识，要求开发队伍水平较高，否则会带来更大风险。

适用场景：适用于需求不明确或者需求可能发生变化的大型复杂的软件系统，支持面对过程。面对对象等多种软件开发方法，是一种具有广阔前景的模型。

1.6 喷泉模型

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
软件开发早期定义对象，整个开发过程充实和扩充对象。
各个阶段使用统一的概念和表示方法，生命周期各阶段无缝连接。

• 优点：喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
• 缺点：由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。喷泉模型要求严格管理文档使得审核的难度加大，尤其是面对可能随时加入的各种信息、需求与资料的情况。

2. 现代模型

2.1 基于构件的开发模型

近年来得到广泛应用，改变大型软件开发方式。考虑的焦点是集成，而非实现。
构件/组件：系统中模块化的、可更换的部分；实现特定的功能；对实现进行封装，暴露一组接口。例如：动态链接库（.dll）,浏览器插件

1. 需求分析。与其它过程模型相同
2. 构件分析。根据需求搜索构件；如果没有完全匹配的构件，则需要修改构件或者修改需求
   考虑重用和集成
3. 系统设计。与其他过程模型不同；考虑重用和集成；如果没有可重用的构件，则设计新软件
4. 开发集成。将构件集成到系统中；开发新软件。

• 基于构件的开发模型的优缺点

优点：

1. 软件复用思想；
2. 降低开发成本和风险，加快开发进度，提高软件质量。

缺点：

1. 模型复杂；
2. 商业软件不能修改，会导致修改需求，进而导致系统不能完全符合客户需求；
3. 无法完全控制所开发系统的演化；
4. 项目划分的好坏直接影响项目结果的好坏。

2.2 统一过程RUP:Rational Unified Process

基于面对对象方法学，使用统一建模语言UML(Unified Modeling Language).
特色：用例和风险驱动，以架构为中心，迭代的增量开发过程。适合大团队大项目。
从3个视角描述软件开发过程：

1. 动态视角：随时间变化的阶段

2. 静态视角：所进行的活动
   

3. 实践视角：可采用的良好实践建议
   6条最佳实践：

   1. 迭代式开发：需求变更是不可避免的，每次迭代产生一个可交付版本，用户反馈，减少风险；根据客户的轻重缓急来规划增量，先开发和交付优先级最高的增量；
   2. 管理需求：采用用例分析来捕获需求，由用例驱动设计和实现；对需求及其变更进行管理；
   3. 基于构件体系结构：采用基于构件的体系结构；提高软件复用率；
   4. 可视化建模：使用同一建模语言（UML）对系统进行可视化建模；
   5. 验证软件质量：软件质量评估贯穿整个开发过程的所有活动；全体成员参与；
   6. 控制软件变更：描述如何控制和跟踪软件的变更。

• 静态结构
  

• 动态结构
  

2.3 敏捷开发

总体目标：“可能早地、持续地对有价值的软件的交付”使客户满意。
敏捷软件开发宣言：个体交互、可工作软件、客户合作、响应变化。即用户至上原则

敏捷开发方法：

• 极限编程:eXtreme Programming/XP
• 自适应软件开发Adaptive Software Development/ASD
• 并列争球法:Scrum
• 动态系统开发方法Dynamic System Development Method/DSDM
• 水晶法:Crystal
• 特征驱动开发:Feature-DrivenDevelopment/FDD
• 精益软件开发:Lean Software Development/LSD

敏捷软件过程是基本原理和开发准则的结合。

极限编程

把好的开发实践运用到极致。

四大价值观：沟通、简单性、反馈和勇气。
5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
12个最佳实践：

• 极限编程优缺点
  优点：快速响应变化和不确定性；可持续开发速度；适应商业竞争环境下的有限资源和有限时间。
  缺点：测试驱动开发可能导致通过测试但非用户期望；重构而不降低质量困难。
• 适用场合
  适用于需求模糊且经常改变的场合适合商业竞争环境下的项目。

3. 选择软件过程模型

• 选择软件过程模型遵循原则：
  1. 软件过程模型是不断发展的
  2. 各种软件过程模型各有优缺点和适用场合，不同软件往往需要不同软件过程模型
  3. 选用时不必拘泥于某种模型
  4. 可组合多种模型
  5. 可根据实际创造新的模型
• 如何选择软件过程模型
  1. 前期需求明确的情况下，尽量采用瀑布模型
  2. 用户无系统使用经验，需求分析人员技能不足的情况下，尽量借助原型模型
  3. 不确定因素很多，很多东西无法提前计划的情况下，尽量采用增量型或螺旋模型
  4. 需求不稳定的情况下，尽量采用增量模型
  5. 资金和成本无法一次到位的情况下，可采用增量模型
  6. 对于完成多个独立功能开发的情况，可在需求分析阶段就进行功能并行，每个功能内部都尽量遵循瀑布模型
  7. 全新系统的开发必须在总体设计完成后再开始增量或并行
  8. 编码人员经验较少的情况下，尽量不要采用敏捷或迭代模型
  9. 增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则
• 案例