1.3 过程模型

在软件过程管理的研究中，专家提出过许多模型，下面介绍几个典型的模型。一个组织的过程体系建设可以参考以下过程模型。

1.CMM/CMMI

软件能力成熟度模型（Capability Maturity Model for Software，SW-CMM）是由美国卡内基·梅隆大学（Carnegie Mellon University）软件工程研究所（Software Engineering Institute）（CMU/SEI）建立的。为了保证软件产品的质量，80年代中期，美国联邦政府提出对软件承包商的软件开发能力进行评估的要求。因此，美国卡内基·梅隆大学软件工程研究所（CMU/SEI）于1987年研究发布了软件过程成熟度框架，并提供了软件过程评估和软件能力评价两种评估方法，以及软件成熟度提问单。4年之后，CMU/SEI将软件过程成熟度框架进化为软件能力成熟度模型（SW-CMM），并发布了最早的SW-CMM 1.0版。经过两年的试用，1993年SEI正式发布了SW-CMM1.1版，这是目前使用最为广泛的版本。CMM主要侧重于项目在研发过程中的管理。

自1991年SW-CMM首次发布后，CMU/SEI又开发了其他成熟度模型，包括：系统工程、采购、人力资源管理和集成产品开发等。虽然各个模型针对的专业领域不同，但彼此之间也有一定的重叠，毕竟它们同出一辙；另外，这些模型在表现形式上又有不统一之处：系统工程模型是连续式的，而其他模型采用了分级式。当SEI开始开发新一代成熟度模型的时候，其发起人提出了新的要求：整合不同模型中的最佳实践，建立统一模型，覆盖不同领域，供企业进行整个组织的全面过程改进。所以，SEI于2001年12月正式发布了能力成熟度集成模型（Capability Maturity Model Integration，CMMI）1.1版本，这次发布标志着CMMI的正式使用。SEI也正式宣布，将不再维护SW-CMM的CBA-IPI评估方法。在CMMI 1.1发布后的两年内，SEI还提供有关SW-CMM 和CBA-IPI主任评估员的培训，并接收评估数据，但这一切已于2003年12月底正式停止。这里需要注意的是，SEI并没有废除CMM模型，而是以CMMI的SCAMPI评估方法取代CMM的CBA-IPI评估方法。CMM/CMMI主要应用在两大方面：能力评估和过程改进。

CMM/CMMI的思想来源于已有多年历史的产品质量管理和全面质量管理。Watts Humphrey和Ron Radice在IBM公司将全面质量管理的思想应用于软件工程过程，收到了很大的成效。SEI的软件能力成熟度框架就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型中融合了全面质量管理的思想，以不断进化的层次反映了软件过程定量控制中项目管理和项目工程的基本原则。CMM/CMMI所依据的想法是只要不断地对企业软件工程过程的基础结构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发制造能力，从而能按时、不超预算地制造出高质量的软件。

在CMMI模型组件中，SE/SW是核心，SE/SW/IPPD、SE/SW/IPPD/SS是在此基础上扩展而来的。CMM模型基于众多软件专家的实践经验，是组织进行软件过程改善和软件过程评估的一个有效的指导框架。CMMI项目更为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。

SEI评估报告显示，从1996年到2003年，全球有2000多个组织进行了CMM/CMMI评估，其中大部分为商业组织，有将近一半的组织规模在100人以下。这些数据表明，CMM/CMMI评估已经引起软件及IT企业的高度关注，并且这种评估同样适合中小企业。

2.PSP/TSP

美国卡内基·梅隆大学软件工程研究所（CMU/SEI）主持研究与开发的CMM/PSP/TSP技术，为软件工程管理开辟了一条新的途经。PSP（个体软件过程）、TSP（团队软件过程）和CMM为软件产业提供了一个集成化的、三维的软件过程改革框架，如图1-5所示。PSP注重于个人的技能，能够指导软件工程师如何保证自己的工作质量，TSP注重团队的高效工作和产品交付能力，CMM注重于组织能力和高质量的产品，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。

PSP（Personal Software Process）是一种可用于控制、管理和改进个人工作方式的自我持续改进过程，是一个包括软件开发表格、指南和规程的结构化框架。PSP与具体的技术（程序设计语言、工具或者设计方法）相对独立，其原则能够应用到几乎任何的软件工程任务之中。PSP能够说明个体软件过程的原则；帮助软件工程师做出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。

TSP（Team Software Process）指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍，始终以最佳状态来完成工作。TSP实施集体管理与自我管理相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。

PSP和TSP是专门设计来优化及规范化个人和团队工作的，通过让个人和团队使用这些预定义的标准流程来建立可测量的目标，跟踪目标的完成情况，从而提高质量。从整个企业角度来看，所有经验证明PSP、TSP能加速CMM在企业范围内的实施，同时也是维持过程改进的需要。开发人员通过PSP的实践能够学到软件过程管理和项目管理方面最先进的技能和最佳实践管理，要开发高质量的软件就要求开发软件的每个工程师都能高质量地完成工作；作为开发团队，TSP的实施能够在较短时间内建立高绩效的团队，确保团队开发产品的质量、安全性。

3.敏捷模型

2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭的问题，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal，特征驱动软件开发（Feature Driven Development，FDD），自适应软件开发（Adaptive Software Development，ASD），以及最重要的极限编程（Xtreme Programming，XP）。极限编程是1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的，它是为了适应快速的需求变化而积累的最佳实践。

在敏捷软件开发中的各个方法集也都在相似的理念下各自拥有抽象或具体的过程管理模型。

4.IPD

IPD（Integrated Product Development，集成产品开发）是一套领先的、成熟的产品开发的管理思想、模式和方法，是业界流行的最佳实践，它的起源是美国20世纪80年代出现的PACE（产品及周期优化法）理论。IPD作为先进的产品开发理念，其核心思想概括如下：

（1）新产品开发是一项投资决策。IPD强调要对产品开发进行有效的投资组合分析，并在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、终止还是改变方向。

（2）基于市场的开发。IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此，IPD把正确定义产品概念、市场需求作为流程的第一步。

（3）跨部门、跨系统的协同。采用跨部门的产品开发团队（Product Development Team，PDT），通过有效的沟通、协调及决策，达到尽快将产品推向市场的目的。

（4）异步开发模式，也称并行工程。就是通过严密的计划、准确的接口设计，把原来的许多后续活动提前进行，这样可以缩短产品上市时间。

（5）重用性。采用公用构建模块（Common Building Block，CBB）提高产品开发的效率。

（6）结构化的流程。产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡。