第七章 软件生存周期过程与管理
第一节 软件生存周期过程概述
软件生存周期
软件生存周期是软件产品或系统的一系列相关活动的全周期。从形成概念开始，历经开发、交付使用、在使用中不断修订和演化，直到最后被淘汰，让位于新的软件产品。
国际标准化组织于1995年发布《ISO/IEC软件生存周期过程12207-1995》，该标准针对“什么需要去做”这一需要，描述了软件过程及活动和任务，回答了软件开发需要做哪些基本“映射”。
该标准按过程主题把软件生存周期过程分为3类：
基本过程：与软件生存直接相关的活动集
-
获取过程
-
供应过程
-
开发过程
-
运行过程
-
维护过程
支持过程：有关各方按它们的目标所从事的一系列相关支持活动集
- 文档过程
- 配置管理过程
- 质量保障过程
- 验证过程
- 确认过程
- 联合评审过程
- 审计过程
- 问题解决过程
组织过程：与软件生产组织相关的活动集
- 管理过程
- 基础设施过程
- 培训过程
- 改进过程
软件生存周期过程是软件生存周期中的一系列相关过程。
为了表述软件开发需要做什么活（映射）引入过程、活动、任务3个术语。
过程是软件生存周期中活动的一个集合，活动是任务的一个集合，而任务是将输入变换为输出的操作。
过程类→过程→活动→任务
第二节 过程描述
在《ISO/IEC系统与软件工程——软件生存周期过程12207-2008》标准中把软件生存周期过程分为7个过程组。
供应过程
活动1：机遇标识
活动2：供应方投标
任务1：需求评审
任务2：做出有关投标或接受合同的决定
任务3：准备一份提案
活动3：合同协商
任务1：与获取方就提供的软件产品或服务，协商合同条文
任务2：请求对合同的修改，作为变更控制机制的一个成分。
活动4：合同执行
任务1：进行获取需求评审
任务2：定义或选择一个适合项目范围、粒度和复杂性的生存周期模型。
任务3：
……
软件实现过程
活动：软件实现策略
任务1：开发人员选择合适的生存周期模型
任务2：实施人员
任务3：实施人员选择合适的标准、方法、工具和编程语言
任务4：开发进行该过程活动的计划
任务5：对不用交付的软件项的处理。
软件需求分析过程
软件确认过程
软件验证过程
软件体系结构设计
第三节 应用说明
是对标准《ISO/IEC系统与软件工程-软件生存周期过程12207-2008》的应用说明。
系统和软件
软件是整个系统的组成部分。
区分系统需求分析和软件需求分析。
与《ISO/IEC系统生存周期15288》的关系
当系统中包括非常重要的非软件因素时，要应用《ISO/IEC系统生存周期15288》。
组织层和项目层
项目可能由组织执行
过程之间的时序关系
没有明确过程、活动、任务之间的时间依赖的序列。
支持活动之间的迭代和再现。
过程分解
把过程划分为一些小的“片段”
生存周期模型和阶段
剪裁
第四节 软件生存周期模型 ★
软件生存周期模型是一个包括软件产品开发、运行和维护中有关过程活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止。
1.瀑布模型
自上而下具有相互衔接的固定顺序。
每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。
瀑布模型的贡献（优点）：
- 在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么有一个规约。
- 在系统构造之前有一个设计阶段，它鼓励规划系统结构
- 每一阶段都有评审，允许获取方和用户的参与
- 前一步作为下一步被认可的、文档化的基线，并允许基线和配置早期接受控制。
瀑布模型存在的问题：
- 要求客户能够完整、正确和清晰地表达他们的需求，并要求开发人员一开始就理解这一应用。
- 由于需求的不确定性，使设计、编码和测试阶段都可能发生延期，并且当项目接近结束时，出现了大量的集成和测试工作。
- 在开始的阶段中，很难评估真正的进度状态，并且直到项目结束之前都不能演示系统的功能。
- 在一个项目的早期阶段，过分地强调了基线和里程碑处的文档，并可能需要花费更多的时间用于建立一些用处不大的文档。
瀑布模型适用情况：
- 需求已被很好的理解和定义
- 过程设计人员也很清楚：开发组织非常熟悉为实现这一模型所需要的过程。
2. 增量模型
在给出整个系统需求的体系结构的基础上，首先完整地开发系统的一个初始子集，如包含需求子集{1，2，5，9}的版本，发布并于运行；然后，根据这一子集建造一个更加精细的版本，如包含需求子集{{1，2，5，9}，{3，6，4，10，7，11}}的版本，如此不断地进行系统的增量开发。
增量模型适用于“技术驱动”的软件产品开发。
增量模型的优点：
- 第一个可交付版本所需要的成本和时间是较少的，从而可减少开发由增量表示的小系统所承担的风险。
- 由于很快发布第一个版本，因此可以减少用户需求的变更。
- 允许增量投资，即在项目开始时可以仅对一个或两个增量投资。
增量模型的缺点：
- 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。
- 如果需求不想早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。
- 由于进度和配置的复杂性，可能会增大管理成本，超出组织的能力。
增量模型的适用情况：
- 在开始开发时，需求很明确，且产品还可被适当分解为一些独立的，可交付的软件。
- 在开发中，期望尽快提交其中的一些增量产品。
3. 演化模型
演化模型主要针对事先不能完整定义需求的软件开发。
- 用户提出待开发系统的核心需求，软件开发人员首先开发一个核心系统并投入运行；
- 用户提出反馈（精化系统、增强系统能力的需求）；
- 接着，软件开发人员根据用户反馈实施开发的迭代过程；每一迭代过程由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集；
- 如果在一次迭代中有的需求不能满足用户，可在下一次迭代中修正。
该模型可以表示为：
第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->……
实际上，这个模型可看作是重复执行的多个“瀑布模型”。 一旦理解需求，就可以像实现瀑布模型那样开始设计和编码。
演化模型的不足：
即使很好的理解需求或设计，也很容易弱化需求分析阶段的工作。
4. 螺旋模型
螺旋模型是在瀑布模型和演化模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。
4个方面的活动：
- 制定计划——确定软件目标，选定实施方案，弄清软件开发的限制条件
- 风险分析——分析所选方案——考虑如何识别和消除风险
- 实施工程——实施软件开发
- 客户评估——评价开发工作，提出修正意见
沿螺旋线自内向外每转一圈便开发出一个更为完善的、新的软件版本；每一圈螺旋线的风险分析后，作出是否继续下去的判断。如果风险太大，开发者和用户无法承受，项目就可能会终止。多数情况下沿螺旋线的活动会继续下去，自内向外逐步延申，最终得到所期望的系统。
如果对所开发的项目的需求已有了较好的理解或较大的把握，便可以采用普通的瀑布模型，就只需要经历单圈螺旋线；如果对所开发的项目需求理解较差，就要经历多圈螺旋线。
与演化模型和增量模型相比，同样使用了瀑布模型作为一个嵌入的过程，即分析、设计、编码、实现、维护的过程，并在框架和全局体系结构方面是等同的。
螺旋模型的适用场景：项目的开发风险很大或客户不能确定系统的需求。
5.喷泉模型
以用户需求为动力，以对象为驱动的模型，主要用于采用面向对象技术的软件开发项目，体现了软件创建所固有的迭代和无间隙的特征。
第五节 过程规划与管理
过程规划与管理是软件项目管理的一项重要工作。把过程管理称为软件生存周期管理过程，包括过程建立、过程评估、过程改进，强调了过程规划（P）、过程检测（C）、过程执行（D）、过程调整（A）。
1.过程建立
- 选择软件生存周期模型
- 细化所选择的生存周期模型
- 为每一个活动或任务标识合适的实例数目
- 确定活动的时序关系，并检查信息流
2.关于软件生存周期过程的监控
- 软件生存周期过程的监控
- 软件生存周期过程改变所产生的影响的评估
- 改变的实施
- 实现改变
第八章 集成化能力成熟度模型（CMMI）
上一章主要内容是如何管理一个项目的生存周期过程，包括过程建立与监控。对于软件开发组织而言，更关心整个组织过程改善的问题。
第一节背景和原理
1.集成化能力成熟度模型CMMI
CMMI的目的：帮助软件企业对软件工程进行管理和改进，增强开发与改进功能，从而能按时，不超预算地开发出高质量的软件。
该模型基于过程途径思想，通过过程把软件质量的3个支撑点——受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统/产品。
2.CMMI集成的模型
软件CMM、产品集成开发CMM、系统工程CMM
第二节 CMMI的模型部件
CMMI是一种过程改善框架。
1.过程改善（Process Improvement）
是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
2.CMMI的模型部件
- 由一些过程域组成，过程域有自己的确定专用目标和公共目标。
- 每个专用目标和公共目标的实现，分别依赖一些实践。
- 每个专用实践有自己的子实践和确定的典型工作产品；每个公共实践有自己的子实践和公共时间的精化。
- 每个过程域还有意图陈述、简介性注释以及相关过程域。
一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件。3.过程域
CMMI有22个过程域，分为四类。
| 过程域类名 |
包括的过程域 |
| 项目管理类 |
规划、监控、定量项目管理、集成项目管理、风险管理、提供方协议管理 |
| 工程类 |
需求开发、需求管理、技术解决方案、产品集成、确认、验证 |
| 支持类 |
配置管理、过程和产品质量保证、测量与分析、原因分析与解决、决策分析与解决 |
| 过程管理类 |
组织过程定义、组织过程性能、组织过程培训、组织过程关注、组织创新与部署 |
第三节 CMMI的等级
CMMI引入两种类型的“等级”：能力等级、成熟度等级，描述了两种过程改善的演化路径。
1.能力等级
能力等级是一种过程改善路径，该路径可使组织针对单一过程域不断改善该过程域。
0级： 未完成级
1级：已执行级
2级： 已管理级
3级： 已定义级
4级： 已定量管理级
5级： 持续优化级
2.组织成熟度等级
成熟度等级也是一种过程改善路径，该路径可使组织通过关注一组过程域不断改善一组相关的过程域。
CMMI的阶段式表示模型定义了5个成熟度等级，在持续的过程改进上，每一等级都是构成下一阶段基础的一个层次，这些等级用从1到5的数字表示。
1级：初始级
2级： 已管理级
3级： 已定义级
4级： 已定量管理级
5级： 持续优化级
3.成熟度等级与能力等级的关系
为了达到成熟度2级，2级中所包含的所有过程域必须达到能力等级2级或更高级。
为了达到成熟度3级，2级、3级中所有过程域必须达到能力等级3级或更高级。
为了达到成熟度4级，2级、3级、4级中所有过程域必须达到能力等级4级或更高级。
为了达到成熟度5级，所有过程域必须达到能力等级5级或更高级。
第四节 过程域举例
两个过程域：项目规划（2级）和需求开发过程（3级）。