目录
第2章 软件过程成熟度
2.1 过程成熟度标准
3个基本概念
- 软件过程能力
- 软件过程性能
- 软件过程成熟度
2.1.1 软件过程不成熟的特点
- 软件过程能力低,不能按预定计划开发出客户满意的产品,项目拖延、费用大大超出预算已成惯例。
- 过程性能的不可预见性,对进度和预算估计、产品质量的目标缺乏历史数据和有效方法的客观基础,开发的进度、成本和产品的质量都难以预测。
- 过程的不可视性,软件过程缺乏定义、缺乏文档和缺乏跟踪,在整个软件过程中,不清楚每个阶段进出的标准、执行的方法和规则。
- 过程的不稳定性,实际的、具体的操作过程是在一个项目开始后临时拼凑而成,每个项目都不一样。
- 过程的被动性、缺乏改进的主动性。
2.1.2 软件过程成熟的标准
- 软件过程能力高,具有全组织范围的管理软件开发和维护过程的能力。
- 软件过程性能可预见性,对进度、预算和质量做出现实的和准确的估计和预测。
- 软件过程规范化,可遵循的标准、规则和指导性原则。
- 过程的一致性
- 过程的丰富性
- 过程的可视性
- 过程的稳定性
- 过程的不断改进
2.2 能力成熟度模型概述
2.2.1 CMM的基本内容
- CMM是软件过程能力成熟度模型(Capacity Maturity Model,CMM)的简称,是卡耐基-梅隆大学软件工程研究所为了满足美国联邦政府评估软件供应商能力的要求,于1986年开始研究的模型,并于1991年正式推出了CMM 1.0 版。
- CMM描述一条从无序的、混乱的过程到成熟的、有纪律的过程的改进途径,描绘出软件组织如何增加对软件开发和维护的过程控制,如何向软件工程和管理的优秀文化演变等方面的指导
CMM的起源和结构
- CMM建立的目的。
- CMM的起源
- 内容和结构
2.2.2 系统工程能力模型
国际系统工程委员会(International Council on Systems Engineering,INCOSE)基于各种工程标准为评估系统工程能力建立了对照表。在此期间,该对照表发展为成熟的能力模型,称为系统工程能力评估模型(Systems Engineering Capability Assessment Model,SECAM)。SECAM扩充了连续式模型——软件过程改进和能力确定模型(Software Process Improvement Capability dEtermination,SPICE)的概念,但是比SE-CMM更加明确地注重在系统工程实践上,采用EIA632标准作为过程模型设计参考的基础。
2.2.3 集成化产品开发模型
- 从美国国防工业协会(National Defense Industrial Association, NDIA)的许多大公司来看,IPPD概念是大型软件开发过程模型的基础,并得到国防部(Department of Defense, DOD)的鼎力相助 。
- IPPD强调在贯穿整个生命周期期间所有技术及业务的相关人员的参与,这些人员包括顾客、供应商以及产品和产品相关过程的开发者,涉及的业务如测试与评价、制造、支持、培训、销售、采购、财务、合同以及处置过程。
2.2.4 CMMI介绍
模型学科 | 源模型 |
软件 | SW-CMM,草案版本2.0 |
系统工程 | EIA/IS 731 |
集成化产品与过程开发 | IPD-CMM, 版本0.98 |
2.3 过程成熟度级别
CMM/CMMI成熟度的5个等级
2.3.1 成熟度等级的行为特征
- 初始级具有明显的不成熟过程的特点
- 可重复级/受管理级建立了管理软件项目的方针和实施这些方针的规程,使软件项目的有效管理过程制度化,有能力去跟踪成本、进度和质量。一个有效过程可特征化为已文档化的、已实施的、可培训的和可测量的软件过程
- 已定义级包含一组协调的、集成的、适度定义的软件工程过程和管理过程,具有良好的文档化、标准化,使软件过程具有可视性、一致性、稳定性和可重复性,软件过程被集成为一个有机的整体
- 已管理级的软件过程是量化的管理过程。在上述已定义级的基础上,可以建立有关软件过程和产品质量的、一致的度量体系,采集详细的数据进行分析,从而对软件产品和过程进行有效的定量控制和管理。
- 优化级不断改善组织的软件过程能力和项目的过程性能,利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息,使持续过程改进成为可能。为了预防缺陷出现,组织有办法识别出弱点并预先针对性地加强过程
2.3.2 理解成熟度等级
- 理解可重复级和已定义级 注意力逐渐从技术问题转向组织体系和管理问题
- 理解定量管理级和优化级
2.3.3 成熟度等级的过程特征
- 第2级,焦点开始集中在软件过程的管理上,一个受管理的过程则是一个可重复的过程 。从管理角度可以看到一个按计划执行的并且阶段可控的、规范化的软件开发过程
- 第3级,通过裁剪组织的标准软件过程来建立自定义的软件过程
- 第4级,对软件产品的质量、开发进度和其它开发目标进行有效的评估和预测
- 第5级,其焦点是软件过程的持续改进
2.3.4 CMMI过程域
2.3.5 CMM和CMMI过程域的比较分析
级别 | CMM 过程域 | CMMI 过程域 |
2 | 需求管理 软件项目规划 软件项目追踪与监控 软件子合同管理 软件质量保证 软件配置管理 | 需求管理 项目计划 项目监督和控制 供应商合同管理 过程和产品质量管理 配置管理 度量和分析 |
3 | 软件过程要点 软件过程定义 培训计划 软件集成管理 软件产品工程 组间协作 同级评审 | 组织级过程焦点 组织级过程定义 组织级培训 集成化群组 集成化项目管理 组织级集成环境 需求开发 技术解决方案 产品集成 验证 确认 风险管理 决策分析和解决方案 |
4 | 过程量化管理 质量管理 | 项目定量管理 组织级过程性能 |
5 | 错误预防 技术更改管理 过程更改管理 | 因果分析和解决方案 组织级改革和实施 |
2.4 软件过程的可视性
2.5 过程能力和效能预测
2.6 软件过程框架
2.6.1 软件过程环境和过程框架
软件过程环境的内容
- 不同的过程对象。
- 不同的过程层次。
- 过程资源的差异。
- 过程文化的差异。
- 开发类型不同。
软件过程框架
2.6.2 软件过程文化
过程文化的类型
- 过程至上,奉过程为教条,一切围绕着过程,组织、质量和效率都服从于过程,过程的执行严格,过程结果可靠、稳定,认为生产的“东西”是过程的一个节点,只是全局的一部分。但效率较低,缺乏灵活性、创造性。
- 以过程为焦点,关注过程,强调过程的重要性,但不拘于过程,让过程服从于质量和效率、服从于组织的业务目标……
- 过程只能起辅助作用,人决定一切, 过程可能流于形式……
2.6.3 PSP/TSP和CMM组成的软件过程框架
PSP/TSP/CMM之间的关系
组织的过程目标