第六章软件过程管理

软件项目管理 第六章软件过程管理

本章内容提要 • 软件过程与过程管理 • CMMI概述 • CMMI的成熟度等级及其过程域 • CMMI的应用 • PSP，TSP与CMMI • 敏捷软件开发方法

第一节软件过程与过程管理 • 软件过程(Software Processes)是指软件开发人员开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例和用户手册）的一套行为、方法、技术及变换过程。 • 不能把软件过程简单地理解为软件产品的开发流程。

从大量项目实践中归纳总结出的行之有效的过程称为最佳实践(Best Practices)。 • 软件过程管理就是对最佳实践进行有效的积累，形成可重复的软件过程，使最佳实践在组织范围内共享。软件过程管理可将个人能力转变为企业的能力。

软件过程管理的主要内容包括过程定义和过程改进。软件过程管理的主要内容包括过程定义和过程改进。 • 过程定义是指对最佳实践进行总结，形成一套稳定的、可重复的软件过程。 • 过程改进是指根据实践中对软件过程的使用情况，对软件过程中的偏差和不足之处进行不断优化。

软件过程管理和软件项目管理的关系 • 互相依赖，互相促进组织级过程资产 Improve Tailor 项目过程 When project coming !!!

第二节 CMMI概述 • CMMI( Capability Maturity Model Integration)即能力成熟度模型集成，由CMM (Capability Maturity Model)发展而来，它最早是应用于软件业的一个过程改进模型，为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。后来随着应用的推广和模型本身的发展，CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。

CMMI的历史 • 1991年，美国卡耐基梅隆大学软件工程研究所（SEI）推出了能力成熟度模型CMM，CMM的作用各主要有两方面： • 为软件客户提供评价软件开发商能力的方法。 • 帮助软件开发商改进其软件过程，提高成熟度。

CMMI的历史 • 随着CMM在软件界应用的不断推广，其它相关学科和领域也采用它的模式，开发出了许多类似于CMM的模型。 • SE-CMM (System Engineering CMM) 系统工程CMM，应用于系统工程管理。 • SA-CMM (Software Acquisition CMM) 软件获取CMM，应用于软件获取（采购）方的能力成熟度模型。

CMMI的历史 • IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发CMM，应用于集成系统产品的开发管理。 • P-CMM (People CMM)：人员能力成熟度模型，应用于人力资源管理。 • 为了以示区别，常把CMM叫做SW-CMM。 • 同一个组织可能会应用多个过程改进模型，但多个过程改进模型的并存可能会引起冲突和混淆。

CMMI的历史 • CMMI为工业界和政府部门提供了一个集成的能力成熟度模型产品集，消除了不同模型之间的不一致和重复，降低了过程改进的成本。 • CMMI覆盖了软件工程、系统工程、集成产品开发和系统采购，以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 • CMMI 1.0版于2000年发布，2002年又发布了1.1版，2006年发布了1.2版。

CMMI的历史 • CMMI是目前世界公认的软件产品进入国际市场的通行证。一般来说，通过CMMI认证的级别越高，就越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。 • 2000年6月，国务院颁发了《鼓励软件产业和集成电路产业发展若干政策》，其中第17条中明确规定“鼓励软件出口型企业通过CMM认证，其费用通过中央外贸发展基金适当予以支持”。随后各省市、高新区、软件园都出台了对通过CMM的企业给予资金奖励的制度。

软件过程成熟度 • 软件过程成熟度指一个具体的软件过程被明确和有效地定义、管理、度量、控制和实施的程度。 • 软件组织成熟的过程是一个不断改进、循序渐进的过程，而不是通过革命性的革新快速实现的。

不成熟组织与成熟组织的对比

CMMI中的成熟度等级 • 初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 • 已管理级：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

CMMI中的成熟度等级 • 已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。 • 量化管理级：分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理活动有一个作出结论的客观依据，能够在定量的范围内预测性能。

CMMI中的成熟度等级 • 优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

CMMI中的成熟度等级 • CMMI是一个引导软件组织不断走向成熟的过程模型。优化管理级不断改进的过程量化管理级可预见的过程已定义级标准一致的过程已管理级有纪律的过程初始级

成熟度等级的结构 成熟度等级过程域1 过程域2 过程域n … 特定目标共性目标特定实践共性实践

CMMI的关键过程域 • 每个成熟度等级包含若干个关键过程域（Key Process Area，KPA）。 • KPA表示当软件组织改进软件过程时必须集中精力解决的关键问题。 • 一个组织要想达到某个成熟度等级，必须满足该等级（以及较低等级）包含的KPA的所有要求，满足每个KPA的所有目标。

CMMI的关键过程域

CMMI的关键过程域(续）

CMMI的能力等级 • 能力等级（Capability Level, CL）是指在一个单独的过程域中执行的良好程度。 • CMMI包括6个能力等级： • CL0，不完整级：过程域的一个或多个目标没有被满足。 • CL1，已执行级：过程通过转换可识别的输入工作产品，产生可识别的输出工作产品。能实现过程域的特定目标。

CMMI的能力等级 • CL2，已管理级：过程作为已管理的过程制度化。 • CL3，已定义级：过程作为已定义的过程制度化。 • CL4，量化管理级：过程作为量化管理的过程制度化。 • CL5，优化级：过程作为优化的过程制度化。

CMMI是什么？ • CMMI指明该做什么，但没有指明如何做，它不是方法论，没有给出特定应用领域内的专门技术。 • CMMI是一个用于改进软件产品和管理过程的结构化模型，但是仅描述软件过程的本质属性，并非涉及软件工程的所有问题。 • CMMI是从软件过程角度定义了成熟的软件过程的实践活动，但是对于成熟的软件组织而言，人的因素和技术的因素也同样重要。

CMMI过程改进需要多长时间？有何效果？ • 一般需要2年才能把成熟度提升一级（建议安排1.5年到2年）。 • 根据CMU-SEI的统计，软件企业在引入CMM后劳动生产率平均增长了35%；错误比率平均减少39%；平均成本回报率为5：1。

第三节 CMMI的成熟度等级及其过程域 3.1 初始级 • 过程 • 极少存在或使用稳定的软件过程。（过程无秩序） • 各种条例、规章制度互不协调，甚至互相矛盾。（开发无规范）

初始级 • 人员 • 依赖个人努力和精英人物； • 项目组成员的工作方式就是哪里出现危机就去哪儿解决。 • 技术 • 引进新技术是很大的风险。 • 度量 • 不收集和分析数据。

初始级 • 注意：有些组织制定了一些软件工程规范，但如果这些规范没有覆盖基本的关键过程域，且执行没有政策、资源方面的保证时，那么该组织仍然被视为处于初始级成熟度。

初始级 • 改进方向 • 建立项目管理过程，实施规范化管理，保障项目的承诺。 • 进行需求管理，建立客户与软件项目之间的共同理解，使项目真正反映客户的要求。 • 建立各种软件项目计划。如：软件开发计划、配置管理计划、风险管理计划等。 • 开展软件质量保证活动。

3.2 CMMI已管理级 特征： • 进行较为现实的承诺，按以前在同类项目上的成功经验建立必要的过程准则以确保再一次成功。 • 逐个项目地建立基本过程管理条例来加强软件过程能力。 • 建立了基本的项目管理过程来跟踪成本、进度和功能，包括：需求管理、计划和跟踪监控、质量管理、配置管理、子合同管理。通过执行这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

特征： • 管理工作主要跟踪软件经费支出、进度和功能，识别在承诺方面出现的问题。 • 采用基线（baseline）来标志进展，控制完整性。 • 定义了软件项目的过程标准，并遵循它。 • 通过子合同建立有效的供求关系。

CMMI已管理级 • 过程 • 软件开发和维护过程是相对稳定的，但过程建立在项目级别，而非企业级别。 • 软件工程过程受控于有效的工程管理过程，先前的成功经验可以被重复使用。 • 问题出现时，有能力识别并纠正，承诺可以兑现。

CMMI已管理级 • 人员 • 理解管理的必要性并对管理有承诺。 • 注意人员的培训。 • 技术 • 建立技术支持活动，并有稳定的计划。 • 度量 • 有计划地收集、分析有关项目过程和产品的数据。

已管理级的改进方向 • 不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织机构的标准软件过程。将改进组织机构整体软件过程能力作为软件组织的责任。 • 确定全组织机构的标准软件过程，把软件工程及管理活动集成到一个稳固而确定的软件过程中。从而可以跨项目改进软件过程效果。 • 建立软件工程过程小组（SEPG），长期承担评估与调整软件过程的任务，以适应未来软件项目的要求。

已管理级的改进方向 • 积累数据：建立组织机构的软件过程库及软件过程相关的文档库。 • 加强人员培训。

已管理级的关键过程域 • 需求管理 • 项目计划 • 项目监督与控制 • 供应协议管理 • 过程与产品质量保证 • 配置管理 • 度量与分析

需求管理 • 需求管理（Requirements Management, ReqM）是指在客户和项目组之间就客户的需求建立一个协议并加以管理。该协议包括技术需求和非技术需求两个方面，它构成了整个产品生命周期中估计、计划、执行和跟踪项目活动的基础。 • 目标 • 控制系统的需求，为工程和管理活动建立基线。 • 保持计划、产品和活动与系统的需求一致。

需求管理过程 需求管理划分为以下5个独立的过程： • 需求获取：通过与用户的交流，对现有系统的观察及对业务的分析，从而开发、捕获和修订用户的需求。 • 需求分析：也称需求建模，是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 • 需求规格：以开发人员可用的技术形式，描述一个产品所应具有的特征和性质，形成需求规格说明书。

需求管理过程 • 需求验证：开发人员和用户对需求规格进行分析和验证。 • 需求变更：采用正式的审批流程来管理需求的变更，使需求变更产生的影响是可控的。变更审批流程包括4个主要活动：变更申请、变更评估、批准/拒绝变更、实现变更。

项目计划 • 项目计划（Project Planning）的目标是为实施和管理项目制定合理的计划。 • 要制定合理的计划，就要对需要完成的工作做出比较实际的估计，并为完成这些工作建立一些必要约定。 • 项目计划首先对要进行的工作、项目的约束条件和项目的目标进行描述。

项目计划 • 项目计划过程包括如下步骤：定义项目的生命周期，确定项目的范围，估计项目的规模、成本和所需资源，制定项目的进度计划，确定并评估项目风险。

项目监督与控制 • 项目监督与控制（Project Monitoring and control）的目标是随时掌握项目的实际开发过程，使得当项目的执行活动与计划相背离时，管理部门能采取有效的措施。 • 当选定的工作产品已完成或处在选定的里程碑时，将实际的项目规模、工作量、成本和进度与计划相比较，以确定工作进展情况。当肯定不能满足计划时，采取相应的调整措施，包括修改开发计划以反映实际的进度情况，对余下的工作重新计划，或采取相应的措施改进过程运行性能。

供应协议管理 • 供应协议管理（Supplier Agreement Management）的目标是选择合适的供应商，并对产品获取过程进行管理。 • 对软件项目来说，常需要采购一些软件或硬件产品，也有可能把项目的一部分外包给第三方来做，而采购和外包可以认为是风险最大的活动之一。

供应协议管理的主要活动 • 确定产品的获取类型（如购买商品化产品、通过合同获取等）。 • 根据供应商的能力选择产品供应商。 • 与供应商建立和维护正式的协议。 • 与供应商共同履行协议中所规定的活动。 • 选择、监督和分析供应商的生产过程。 • 评估供应商的工作产品。 • 在接收产品前确保供应协议已得到满足。 • 将产品从供应商转移到当前项目中。

过程与产品质量保证 • 过程与产品质量保证（Process and Product Quality Assurance）为项目管理者提供项目过程和相关产品的适当的可见性，从而为交付高质量的产品和服务提供支持。 • 在该过程与中，产品质量评估的客观性对项目的成功是至关重要的，可以通过设立独立的质量保证组或应用一些标准来达到这种客观性。 • 质量保证工作应尽早开始，在项目初期就应制定相应的计划、标准和规程。

过程与产品质量保证的主要活动 • 根据过程描述、标准和规程，客观地评估所执行的过程。 • 根据过程描述、标准和规程，客观地评估工作产品和服务。 • 交流质量问题并确保不一致项得到解决。不一致项是指在质量评估过程中所发现的与标准、过程描述和规程不一致的地方。

配置管理 • 配置管理（Configuration Management）是通过配置标记、配置控制、配置状态审核和配置审计来建立和维护工作产品的一致性。

度量与分析 • 度量与分析（Measurement and Analysis）过程域的目标是开发和维持度量能力，从而能够支持管理信息需求。 • 将度量与分析集成到项目过程中，主要有以下几方面的作用： • 支持客观的计划和估计。 • 跟踪实际性能，并与计划和目标对比。 • 识别和解决与过程相关的问题。

第六章 软件过程管理