【培训课件】软件过程的管理与改进(共64张)

1、软件过程的管理与改进 1 软件过程管理与改进概述 2 度量软件过程 3 能力成熟度模型CMM 4 个体软件过程PSP 5 团体软件过程TSP 6 内容总结1 软件过程管理与改进概述软件过程的发展1984年第一届国际软件过程讨论会正式提出，软件工程又一次认识上飞跃。1、软件过程的概念-软件过程是指人们开发和维护软件及其相关产品所采取的软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动。其中软件相关产品包括项目计划、设计文档、源代码、测试用例一系列活动。其中软件相关产品包括项目计划、设计文档、源代码、测试用例和用户手册等。和用户手册等。软件产品的质量主要取决于产品开发和维护的软件过程的质

2、量。一个有效的、软件产品的质量主要取决于产品开发和维护的软件过程的质量。一个有效的、可视的软件过程能够将人力资源、物理设备和实施方法结合成一个有机的整可视的软件过程能够将人力资源、物理设备和实施方法结合成一个有机的整体，并为软件工程师和高级管理者提供实际项目的状态和性能，从而可以监体，并为软件工程师和高级管理者提供实际项目的状态和性能，从而可以监督和控制软件过程的进行。督和控制软件过程的进行。IEEE广义软件过程：包括软件的采购、开发、维护、运作、获取、管理、广义软件过程：包括软件的采购、开发、维护、运作、获取、管理、支持支持ISO 12207分成三个过程：基本过程、支持过程、组织过程分成三个

3、过程：基本过程、支持过程、组织过程研究目的：管理和改进软件过程研究目的：管理和改进软件过程软件过程管理：对软件产品及对强化软件系统的开发、维护和支持所涉软件过程管理：对软件产品及对强化软件系统的开发、维护和支持所涉及的工作过程进行管理及的工作过程进行管理软件过程改进：为了更有效的达到优化软件过程的目的而实施的改善或软件过程改进：为了更有效的达到优化软件过程的目的而实施的改善或改变其软件过程的系列活动。改变其软件过程的系列活动。1 软件过程管理与改进概述2、软件过程改进的实际意义： 软件过程实例：软件组织在进行具体软件项目时采用的软件过程。 成功的改进带来的价值：提高效率、减少错误、保证进度、提

4、高质量 软件过程管理改进：是软件组织评估和认证的基础，也是竞标软件项目的基础。 软件组织角度看软件过程管理和改进：有利于组织获得认证以提高竞争力；从产业角度，可以提高产业整体水平和竞争力（印度）1 软件过程管理与改进概述3、软件过程建模与软件过程改进的理论与方法： 软件过程模型：又称软件工程开发模型或软件生命周期模型，是软件开发全部过程、资源和任务的结构框架。包括组织、功能、行为及其他方面。 如件过程建模：通过过程设计和过程定义来建立过程模型的活动。包含两种常用方法： 结构化：基于模块化思想，进行结构化分析、设计和编程 面向对象：用面向对象的分析、设计、编程及测试方法为软件过程建模。目前的主流

5、方法。用UML工具进行具体建模。 过程管理改进的理论：以统计过程控制理论为基础，内容包括：过程的可控性，如何改进使其产生预期结果，如何在度量和统计基础上进行过程改进。1 软件过程管理与改进概述 软件过程管理的职责： 定义过程 度量过程 控制过程 改进过程4、过程改进的模式和体系、过程改进的模式和体系 目标驱动模式目标驱动模式 预先设定目标自顶向下制定过程度量或评价模型，有目的预先设定目标自顶向下制定过程度量或评价模型，有目的的开展改进活动。的开展改进活动。 缺陷驱动模式缺陷驱动模式 根据过程缺陷反馈的信息，进行有针对性的改进活动根据过程缺陷反馈的信息，进行有针对性的改进活动1 软件过程管理与改

6、进概述 过程改进体系：过程改进体系： ISO 9001：服务行业的通用标准，后追加了：服务行业的通用标准，后追加了ISO 9000-3，包含了软件，包含了软件组织满足组织满足ISO认证的认证的20个条款个条款 CMM：是指关注软件开发的过程体系，明确强调持续的软件过程改进。：是指关注软件开发的过程体系，明确强调持续的软件过程改进。专用于软件的。专用于软件的。 Trillium SPICE BOOTSTRAP5、过程改进的原则和步骤、过程改进的原则和步骤 最普遍的原则：最普遍的原则： 改进建立在评价和度量基础之上改进建立在评价和度量基础之上 是一个持续过程是一个持续过程 活动本身应作为一个过程改

7、进项目完成活动本身应作为一个过程改进项目完成 将过程度量用于对改进过程进行监控，及时对改进活动作必要的调整将过程度量用于对改进过程进行监控，及时对改进活动作必要的调整 适当重复软件过程的评价活动适当重复软件过程的评价活动1 软件过程管理与改进概述5、过程改进活动的组织和实施、过程改进活动的组织和实施 改进活动涉及的问题：改进活动涉及的问题： SPI立项立项 成立成立SPI小组小组 SPI计划计划 制定制定SPI意义：意义： 明确特定项目活动的目标、目标期限和预计输出明确特定项目活动的目标、目标期限和预计输出 项目分解成有特定操作目标的有限任务，使项目更易完成项目分解成有特定操作目标的有限任务，

8、使项目更易完成 保证任务的优先次序和协调，阐明各任务间关系保证任务的优先次序和协调，阐明各任务间关系 帮助高层管理者、帮助高层管理者、SPI项目成员和相关从业者建立完成特定承诺项目成员和相关从业者建立完成特定承诺 作为交流工具，确保作为交流工具，确保SPI过程被正确的看到和理解过程被正确的看到和理解 度量和反馈度量和反馈 渐进和革命渐进和革命 建立基准建立基准 约定约定 普遍建立过程改进意识普遍建立过程改进意识2度量软件过程度量：是对对象进行量化处理。就是采集数据和分析数度量：是对对象进行量化处理。就是采集数据和分析数据。据。软件有关的度量有：软件有关的度量有： 软件产品度量软件产品度量 软件

9、项目度量软件项目度量 软件质量度量软件质量度量 软件错误和缺陷度量软件错误和缺陷度量 软件过程度量：是软件过程改进的基础软件过程度量：是软件过程改进的基础 软件过程改进度量：软件过程改进本身作为一个过程软件过程改进度量：软件过程改进本身作为一个过程也需要度量也需要度量2度量软件过程1、度量软件过程的步骤：、度量软件过程的步骤： 制定度量计划制定度量计划 确定过程问题确定过程问题 选择与定义度量选择与定义度量 规划如何将度量与软件过程集成规划如何将度量与软件过程集成 与软件过程集成与软件过程集成 采集数据采集数据 数据的保存数据的保存 分析过程行为分析过程行为2、过程行为分析技术、过程行为分析技

10、术 分析过程行为的目的是对过程稳定行进行测试和评价，找出异分析过程行为的目的是对过程稳定行进行测试和评价，找出异常过程行为模式，发现和纠正可归属的原因，进行过程能力分常过程行为模式，发现和纠正可归属的原因，进行过程能力分析析2度量软件过程 过程的稳定性分析：一个稳定的过程的可度量特征或过程性能过程的稳定性分析：一个稳定的过程的可度量特征或过程性能的基础分布是始终唯一的，对稳定性进行测试，需要专门的统的基础分布是始终唯一的，对稳定性进行测试，需要专门的统计处理计处理 异常过程行为模式分析：找出过程中异常行为的规律和特点，异常过程行为模式分析：找出过程中异常行为的规律和特点，以便发现问题的症结。以

11、便发现问题的症结。 过程能力分析：过程能力指的是通过这个过程能达到的结果。过程能力分析：过程能力指的是通过这个过程能达到的结果。过程能力分析除了明确过程能力，还要将过程能力与客户或企过程能力分析除了明确过程能力，还要将过程能力与客户或企业需要进行比较，如果不能满足客户需要，必然要对过程改进业需要进行比较，如果不能满足客户需要，必然要对过程改进是由美国是由美国卡内基卡内基- -梅隆大学软件工程研究所梅隆大学软件工程研究所(CMU/SEI)推出的评估软件能力与成熟推出的评估软件能力与成熟度的一套标准。并提供了度的一套标准。并提供了和和两种评估方法和软两种评估方法和软件成熟度提问单。件成熟度提问单。

12、4年之后，年之后，SEI将软件过程成熟度框架进化为将软件过程成熟度框架进化为该标准基于众多软件专家的实践经验，侧重于软件开发过程的管理及该标准基于众多软件专家的实践经验，侧重于软件开发过程的管理及工程能力的提高与评估，是国际上流行的软件生产过程标准和软件企业成工程能力的提高与评估，是国际上流行的软件生产过程标准和软件企业成熟度等级认证标准，它更代表了一种管理哲学在软件工业中的应用。熟度等级认证标准，它更代表了一种管理哲学在软件工业中的应用。 目前，目前，。为推动我国软件产业的发展，促进软件企业向正规化和国际化迈进，。为推动我国软件产业的发展，促进软件企业向正规化和国际化迈进，应进一步引入和推广

13、应进一步引入和推广CMM认证。认证。19991999年提出年提出CMMICMMI集成能力成熟度模型，也叫综合能力成熟度模型。包括：集成能力成熟度模型，也叫综合能力成熟度模型。包括：CMM SWCMM SW（软件工程（软件工程CMMCMM）、）、CMM SECMM SE（系统工程（系统工程CMMCMM）、）、CMM/SE/SW with IPPDCMM/SE/SW with IPPD（集成的产品和过程开发）、（集成的产品和过程开发）、CMM SACMM SA（系统采办）。来源于（系统采办）。来源于CMM2.0CMM2.0草案，草案，1.11.1版本版本20032003年年1 1月正式发布。月正式

14、发布。PSPPSP个体软件过程，如果没有个体过程意识和过程能力的支持，不可能提高个体软件过程，如果没有个体过程意识和过程能力的支持，不可能提高能力成熟度。能力成熟度。19951995提出提出PSPPSPTSPTSP团体软件开发过程：提供如何提高软件开发小组本身的知识和技能的方团体软件开发过程：提供如何提高软件开发小组本身的知识和技能的方法。法。19961996提出提出TSPTSP。TSPiTSPi专门用于开发小组。专门用于开发小组。软件过程成熟度是指一个软件过程被明确定义、管理、度量和控制软件过程成熟度是指一个软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程能力持续改善的过程

15、，成熟度代表软的有效程度。成熟意味着软件过程能力持续改善的过程，成熟度代表软件过程能力改善的潜力。件过程能力改善的潜力。成熟度等级用来描述某一成熟度等级上的组织特征，每一等级都为成熟度等级用来描述某一成熟度等级上的组织特征，每一等级都为下一等级奠定基础，过程的潜力只有在一定的基础之上才能够被充分发下一等级奠定基础，过程的潜力只有在一定的基础之上才能够被充分发挥。挥。成熟级别的改善包括管理者和软件从业者基本工作方式的改变，组成熟级别的改善包括管理者和软件从业者基本工作方式的改变，组织成员依据建立的软件过程标准执行并监控软件过程，一旦来自组织和织成员依据建立的软件过程标准执行并监控软件过程，一旦来

16、自组织和管理上的障碍被清除后，有关技术和过程的改善进程能迅速推进。管理上的障碍被清除后，有关技术和过程的改善进程能迅速推进。 CMM将软件过程的成熟度分为将软件过程的成熟度分为5 5个级别个级别 ，如图所，如图所示，示，5 5个等级分别是：个等级分别是：初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级1 1、初始级（、初始级（InitialInitial）2 2、可重复（、可重复（RepeatableRepeatable）3 3、已定义级（、已定义级（DefinedDefined）4 4、已管理级（、已管理级（ManagedManaged）5 5、优化级（、优化级（Op

17、timizingOptimizing）SW-CMM为每个软件组织建立和改善软件过程提供了一个阶梯式的过为每个软件组织建立和改善软件过程提供了一个阶梯式的过程成熟度框架，这一框架由程成熟度框架，这一框架由5 5个成熟度等级构成。除初始级以外，其余的成个成熟度等级构成。除初始级以外，其余的成熟度等级都包含了若干个关键过程区域，每个关键过程区域又包含了若干熟度等级都包含了若干个关键过程区域，每个关键过程区域又包含了若干个关键实践，这些关键实践按照个关键实践，这些关键实践按照5 5个共同特点加以组织。个共同特点加以组织。 成熟度等级初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化

18、级初始级（初始级（InitialInitial）在初始级，企业一般不具备稳定的软在初始级，企业一般不具备稳定的软件开发与维护环境。项目成功与否在件开发与维护环境。项目成功与否在很大程度上取决于是否有杰出的项目很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队。此时，经理和经验丰富的开发团队。此时，项目经常超出预算和不能按期完成，项目经常超出预算和不能按期完成，组织的软件过程能力不可预测。组织的软件过程能力不可预测。初始级初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级可重复级可重复级(Repeatable): (Repeatable): 在可重复级，组织建立了管理

19、软件项在可重复级，组织建立了管理软件项目的方针以及为贯彻执行这些方针的目的方针以及为贯彻执行这些方针的措施。组织基于在类似项目上的经验措施。组织基于在类似项目上的经验对新项目进行策划和管理。组织的软对新项目进行策划和管理。组织的软件过程能力可描述为有纪律的，并且件过程能力可描述为有纪律的，并且项目过程处于项目管理系统的有效控项目过程处于项目管理系统的有效控制之下。制之下。可重复级可重复级初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级已定义级（已定义级（DefinedDefined）：）：在已定义级，组织形成了管理软件开在已定义级，组织形成了管理软件开发和维护活动的组织

20、标准软件过程，发和维护活动的组织标准软件过程，包括软件工程过程和软件管理过程。包括软件工程过程和软件管理过程。项目依据标准定义自己的软件过程进项目依据标准定义自己的软件过程进行管理和控制。组织的软件过程能力行管理和控制。组织的软件过程能力可描述为标准的和一致的，过程是稳可描述为标准的和一致的，过程是稳定的和可重复的并且高度可视定的和可重复的并且高度可视已定义级初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级已管理级（已管理级（ManagedManaged）：）：在已管理级，组织对软件产品和过程在已管理级，组织对软件产品和过程都设置定量的质量目标。项目通过把都设置定量的质

21、量目标。项目通过把过程性能的变化限制在可接受的范围过程性能的变化限制在可接受的范围内，实现对产品和过程的控制。组织内，实现对产品和过程的控制。组织的软件过程能力可描述为可预测的，的软件过程能力可描述为可预测的，软件产品具有可预测的高质量软件产品具有可预测的高质量已管理级已管理级初始级初始级可重复级可重复级已定义级已定义级已管理级已管理级优化级优化级优化级（优化级（OptimizingOptimizing）：）：在优化级，组织通过预防缺陷、技术在优化级，组织通过预防缺陷、技术创新和更改过程等多种方式，不断提创新和更改过程等多种方式，不断提高项目的过程性能以持续改善组织软高项目的过程性能以持续改善

22、组织软件过程能力。组织的软件过程能力可件过程能力。组织的软件过程能力可描述为持续改善的。描述为持续改善的。优化级优化级优化级表表1 1描述了描述了SW-CMM不同成熟度等级过程的可视性和过程能力。不同成熟度等级过程的可视性和过程能力。等级等级成熟度成熟度可视性可视性过程能力过程能力1初始级初始级有限的可视性有限的可视性一般达不到进度和成本的目标一般达不到进度和成本的目标2可重复级可重复级里程碑上具有管理可视性里程碑上具有管理可视性由于基于过去的性能，项目开由于基于过去的性能，项目开发计划比较现实可行发计划比较现实可行3已定义级已定义级项目定义软件过程的活动具项目定义软件过程的活动具有可视性有可

23、视性基于已定义的软件过程，组织基于已定义的软件过程，组织持续地改善过程能力持续地改善过程能力4已管理级已管理级定量地控制软件过程定量地控制软件过程基于对过程和产品的度量，组基于对过程和产品的度量，组织持续地改善过程能力织持续地改善过程能力5优化级优化级不断地改善软件过程不断地改善软件过程组织持续地改善过程能力组织持续地改善过程能力可视性与过程能力的比较SW-CMM的关键过程区域 过程分类过程分类成熟度等级成熟度等级管理过程管理过程组织过程组织过程工程过程工程过程 5、优化级、优化级 技术改革管理技术改革管理过程更改管理过程更改管理缺陷预防缺陷预防4、已管理级、已管理级 定量过程管理定量过程管理

24、软件质量管理软件质量管理3、已定义级、已定义级集成软件管理集成软件管理组间协调组间协调组织过程焦点组织过程焦点组织过程定义组织过程定义培训大纲培训大纲软件产品工程软件产品工程同行评审同行评审2、可重复级、可重复级需求管理需求管理软件项目策划软件项目策划软件项目跟踪与监督软件项目跟踪与监督软件子合同管理软件子合同管理软件质量保证软件质量保证软件配置管理软件配置管理 1、初始级、初始级无序过程无序过程除了初始级外，每一成熟度等级又由若干个关键过程区域除了初始级外，每一成熟度等级又由若干个关键过程区域(Key Process (Key Process Areas)Areas)构成。关键过程区域指出为

25、了达到某个成熟度等级所要着手解决的问构成。关键过程区域指出为了达到某个成熟度等级所要着手解决的问题。达到一个成熟度等级，必须实现该等级上的全部关键过程区域。要实现题。达到一个成熟度等级，必须实现该等级上的全部关键过程区域。要实现一个关键过程区域，就必须达到该关键过程区域的所有目标。一个关键过程区域，就必须达到该关键过程区域的所有目标。每个等级内容按三个层面组织：关键过程域（KPA）共同特点关键实践关键过程区域关键过程区域KPA(Key Process Areas)(Key Process Areas)是一组相关的活动，可按照上表描述，是一组相关的活动，可按照上表描述，也可按照图描述。也可按照图

26、描述。 初始级初始级需求管理需求管理软件项目计划软件项目计划软件项目跟踪与监督软件项目跟踪与监督软件子合同管理软件子合同管理软件质量保证软件质量保证软件配置管理软件配置管理可重复级可重复级软件机构过程关注点软件机构过程关注点软件机构过程定义软件机构过程定义培训计划培训计划整体化软件管理整体化软件管理软件产品工程软件产品工程组间合作组间合作同行评审同行评审已定义级已定义级定量过程管理定量过程管理软件质量管理软件质量管理已管理级已管理级过程变更管理过程变更管理预防故障预防故障技术变更管理技术变更管理优化级优化级关键过程域关键实践：关键实践：对软件组织的能力成熟度有关键意义的实践共同特点五个：共同特

27、点五个：承诺能力活动监控验证CMM常见关键过程域(1) 需求管理(requirements management)建立客户的软件项目需求，並使项目开发人员与客户对软件需求产生一致的理解。这是软件项目规划(SPP)和管理(SPTO)的基础，需求变更依赖于配置管理(SCM)的变更控制流程。在项目实施过程中，最突出的现象就是项目组成员没有完全理解需求，软件需求不稳定，客户经常变更需求，无法有效控制需求变更，需求变更往往造成项目延期和费用超支。 CMM要求的需求管理的基本流程可如所示。该流程描述了软件工程组开始获取原始需求，汇总为系统需求，分配系统需求，复审软件需求，软件需求必须文档化形成需求文档，此

28、文档必须经过相关组和个人的评审，通过评审之后才纳入配置管理，为需求文档建立基线。软件项目计划、活动及软件工作产品，应和软件需求的变化保持一致。 a. 获取需求和确认需求以Use case（用例）为单位，以Rational Requisite Pro作为需求管理工具，使用Rational Rose进行维护Use case和Use case Model。 b. 通过访谈，从客户处获取原始需求，形成需求文档。 c. 分析软件需求形成Use case描述文档，与客户共同确认需求，向客户展示Use case文档，获得客户认可。 d. 建立基线的需求必须通过相关组的审查，包括：系统分析组、设计组、编码组、

29、测试组、质量保证组、配置管理组、文档管理中心及个人。通过审查，项目组成员发现需求是否可行、是否完善、是否清晰、是否可进行测试。 e. 通过审查后，将需求文档纳入配置管理，为需求创建基线。需求管理步骤：需求管理步骤： f. 通过工具管理，对需求进行跟踪，尽快找出需求变更受影响的需求及工件，并了解需求的实现情况。 g. 客户确认后如需变更，项目小组成员向其说明变更的影响，并有可能增加费用及时间，尽量控制客户的需求。需求变更的流程按配置管理的变更流程执行。 h. 一旦需求发生变更，项目计划、活动、工序随之变更，并重新提交相关组和个人复审。 i. 实际项目需求管理中应用的文档有： 项目需求管理流程定义

30、、项目需求复审流程定义、项目需求及状态跟踪流程定义、需求获取表格、需求状态报告、需求复审报告、需求变更报告、需求跟踪报告(2)软件项目计划(software project planning)制定实施软件工程与管理软件项目的工作计划。CMM软件项目计划根据纳入配置管理后的软件需求进行项目估算，并依据文档化的流程，形成项目计划文档。项目计划文档经复审后纳入配置管理，由项目开发人员遵循，并据此跟踪检查计划的执行。项目计划文档在复审过程中，如果项目计划对风险估算不足或存在其它问题，就需要对项目计划文档重新修正，以获得项目组和高层管理者的支持。 a) 项目采用 Microsoft Word 拟定计划文

31、档，以 Microsoft Project 拟定计划的进度表。 b) 项目经理根据项目软件需求进行估算，确定进行项目选择的生命周期、项目规模、所需的人员、时间、进度、资源、风险等内容。将估算的结果形成估算过程文档，并拟定软件开发计划。 c) 软件开发计划内容包含：软件项目计划、迭代计划、进度时间表、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划。软件项目计划的实际应用模式如下：软件项目计划的实际应用模式如下： d) 估算过程文档和软件项目计划文档必须通过相关组的审查，以获得相关组及个人的支持，包括：系统分析组、设计组、编码组、测试组、

32、质量保证组、配置管理组、文档管理中心及个人。通过审查，发现并修正项目估算和项目计划的偏差。只有获得了支持，软件项目组在开发过程中才能尽量避免或消除风险。 e) 在高层管理者复审通过后，项目经理指定人员或参与拟定软件开发计划其它部分，并由相关组和个人复审。 f) 配置管理人员将软件开发计划文档纳入配置管理。 g) 实际项目中应用的文档有： 制定项目计划流程定义、项目估算流程定义、项目评估表、资源评估表、软件开发计划模板（包括：软件项目计划、迭代计划、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划）、进度时间表、制订软件开发计划的指南。(

33、3) 软件项目跟踪和监督(software project tracking and oversight)根据软件开发计划管理软件项目，随时掌握软件项目的实际开发过程。按照项目计划对软件开发的进度和阶段产品进行跟踪和评审，当软件项目的执行状况与软件项目计划发生较大偏差时，管理机构必须采取有效控制措施，必要时根据项目的实际完成情况和结果，修订项目计划。 CMM软件项目跟踪与监控的基本流程可如所示。该流程描述了软件项目组根据文档化的估计、承诺、计划跟踪和审查软件成果，并基于实际调整计划。文档化的软件项目计划被用作跟踪软件活动、了解状态和修正计划的基础。项目经理根据项目开发计划跟踪项目的执行情况，定

34、期形成项目进度报告，并与项目开发计划进行对比，发现问题，根据实际情况对软件开发计划进行修正。掌握了这个核心，实施软件项目跟踪与监控活动就很容易了。 a) 项目组使用 Rational 的工具进行管理，将 Microsoft Project 拟定的项目计划进度表导入 ClearQuest，主要以 ClearCase 和 ClearQuest 作为跟踪监控工具。 b) 项目经理每周根据项目的实际执行情况，拟定项目的进度报告。然后召集项目小组成员，对进度报告进行确认和修正。 c) 项目经理对照计划与实际执行情况，发现差距并将其纪录成问题报告，其中包括：费用、进度、风险、人员、资源状况等。 d) 由高

35、层管理者复审进度报告及问题报告，并敦促项目经理修正其计划及解决项目存在的问题和风险。 e) 实际项目中应用的文档有： 项目跟踪与监控流程定义、项目进度报告、项目进度指标收集指南。 项目计划跟踪与监控采取如下方式：项目计划跟踪与监控采取如下方式：( 4 ) 软 件 分 包 合 同 管 理 ( s u b c o n t r a c t management)根据商业联盟、过程能力和技术等因素选择高质量的软件承制方，承制软件项目的部分子项目。制订子项目承制方的工作任务和项目计划文档，它是主承制方跟踪检查和监督子项目过程和产品的依据。(5) 软件质量保证(quality assurance)评审软件

36、产品和活动，检验它们是否与应用的标准和规程保持一致，对发现的问题应采取必要措施予以解决。软件质量保证的基本流程可如所示。该流程描述了软件质量保证计划的形成与复审，SQA人员根据质量保证计划开展质量保证活动，发现问题，跟踪解决问题，并最终向高层管理者汇报项目的执行情况。质量保证计划一般包含项目过程采用的标准（如：项目计划估算过程、计划过程、测试过程、复审过程、开发过程、风险管理等）以及软件工作产品的标准（如：编码标准、接口定义标准等）。软件质量保证过程 a) 项目质量保证人员以Microsoft Word拟定项目质量保证计划文档，以Microsoft Project拟定项目质量保证活动的进度表。

37、 b) 由质量保证经理或高层管理者指定项目的质量保证人员。项目的质量保证人员在项目开发计划复审通过之后，拟定项目的质量保证计划，并提交给项目经理和质量保证经理或高层管理者复审。 c) 质量保证人员根据计划对项目执行的活动进行定期审计，记录与项目流程定义不一致的问题，并形成报告。 d) 质量保证人员组织人员对产出的工作产品进行复审，以验证其是否与项目采用的标准一致，并形成报告。 e) 将审计和复审发现的问题记录到项目的问题跟踪进度表中，跟踪并协调问题的解决情况，并定期向高层管理者汇报。如果不能解决的由高层管理者协助解决。 f) 项目经理或高层管理者定期检查质量保证人员的活动。 g) 实际项目中应

38、用的文档有： 项目质量保证流程定义、质量保证计划、流程审计报告、软件工作产品复审报告、质量保证计划进度表、SQA问题跟踪解决进度表。(6)软件配置管理(configuration management)保证软件项目生成的产品在软件生命周期中的完整性。在给定时间点上确定软件配置，如工作产品及其说明。系统的控制软件配置的变化并在整个软件生命周期中维护配置的完整性和可跟踪性。软件配置管理可以分为两方面的内容，一是配置项的识别和管理，另一方面是变更管理。a. 配置项管理的基本流程可如所示，该流程描述了软件工程组在进行开发过程中，生成软件工作产品，识别配置项，为配置项创建基线。配置管理项最显著的特征就是

39、包含版本号或发布日期。实际项目管理经常不知道该如何识别区分配置项和基线。 b. 变更管理描述了纳入配置管理的配置项进行变更的完整流程。根据新需求、项目进度报告、客户意见反馈、软件工作产品复审记录等不同的原因提出变更申请，由项目小组或变更控制委员会（SCCB）分析其影响，确定变更请求的拒绝、接受或搁置，并根据不同的决定进行不同的处理，一直到变更请求被处理。一旦采用了严格的变更控制管理流程，才能了解变更造成的影响，所有项目组成员才了解变更，形成共识，接受变更。缺少对变更有效的控制，往往会造成配置管理的无序，导致项目返工、延期，甚至失败。 a) 项目设定配置管理人员，以Rational ClearC

40、ase为配置管理工具，根据项目计划拟定项目的配置管理计划文档，以Microsoft Project拟定项目配置活动的进度表。 b) 项目的配置管理计划包含以下内容：配置管理工具、目录结构、识别配置项的方法、配置项命名、创建配置管理库、基线管理、配置审计、配置状态报告、变更管理等。 c) 在ClearCase创建项目的VOB（版本对象库），创建项目小组成员的工作区和集成区，项目组成员只在各自的工作区Check in 或Check out操作，由配置管理人员进行合并，标识出软件配置项。 d) 由配置管理人员负责在适当的时机（如：里程碑处或迭代结束）创建基线，晋升基线，下降基线，并由其负责备份和恢复

41、基线。软件配置管理的方法软件配置管理的方法 e) 根据配置管理计划对项目的配置项和基线定期（或里程碑处）进行审计，以验证其是否与项目配置计划或项目开发计划一致。 f) 所有的变更请求首先向配置管理人员提出，由配置管理人员对变更请求进行分析确定其影响，组织变更评审小组。 g) 一旦同意变更，由配置管理人员Check out需变更的配置项，然后对配置项进行变更，变更完成后再由配置管理人员Check in到配置管理库中。 h) 由SQA人员定期审计配置管理的活动。 i) 实际项目中应用的文档有： 项目配置管理计划制定流程定义、项目配置管理活动流程定义、项目配置管理计划、配置状态报告、基线审计报告（见

42、附表）、配置项变更申请表、项目配置管理活动进度表、配置管理工具操作指南能力成熟度模型集成CMMI1能力成熟度模型集成CMMI的产生 软件能力成熟度模型CMM取得了成功，产生了很大影响。 系统工程、系统安全工程、集成化产品开发等许多工程学科和领域也都参照CMM建立自己的能力成熟度模型，如SE-CMM、People CMM、IPD-CMM、FAA-iCMM等。 模型的繁衍导致模型框架、术语等方面的矛盾和不一致。 当某一工程项目涉及若干个学科和领域后，这种矛盾就十分突出了。能力成熟度模型集成CMMI的产生 CMM公布后的若干年内工程环境更加复杂，工程规模更大、参与工程项目的组织和人员更多、范围更广泛

43、，工程的施工涉及多学科、交叉学科、并行工程、及更多的国际标准。这些新的变化促使美国国防部、美国国防工业协会和SEI/CMU共同开发一种新的模型CMMI（Capability Maturity Model Integration）。能力成熟度模型集成CMMI CMMI项目在1998年正式启动 来自业界、政府部门和SEI/CMU三个方面的170多人，经过两年的工作于2000年发布 CMMI-SE/SW/IPPD V1.0 CMMI-SE/SW/IPPD v1.0的主要参考模型 软件学科的SW-CMM 系统工程学科的EIA/IS 731 集成化产品和过程开发领域的IPD CMM v0.98能力成熟度

44、模型集成CMMI CMMI继承了SW-CMM的阶段式表示法和EIA/IS 731的连续式表示法。 软件学科的两种表示法均采用统一的24个过程域，它们在逻辑上是等价的。 对同一组织采用两种模型分别进行CMMI评估应该得到相同的结论。2 阶段式模型和连续式模型1) 阶段式模型阶段式模型基本沿袭SW-CMM模型框架，仍保持五个“成熟度等级”，但过程域做了一些调整和扩充，如表2.23所示 过程域的阶段式分组成熟度等级 过程域L2可重复级 需求管理 项目计划 配置管理 项目监督和控制 供应商合同管理 度量和分析 过程和产品质量保证L3己定义级 需求开发 技术解决方案 产品集成 验证 确认 组织级过程焦点

45、 组织级过程定义 组织级培训 集成化项目管理 风险管理 集成化的团队 决策分析和解决方 组织级集成环境L4 己管理级 组织级过程性能 项目定量管理L5 优化级 组织级改革和实施 因果分析和解决方案2) 连续式模型 连续式模型没有与组织成熟度相关的几个阶段。 连续式模型将24个过程域按照功能划分为过程管理、项目管理、工程、支持 四个过程组。表2.24 连续式模型的过程域分组连续式分组 过程域 过程管理 组织级过程焦点 组织级过程定义 组织级培训 组织级过程性能 组织级改革和实施项目管理 项目计划 项目监督和控制 供应商合同管理 集成化项目管理 风险管理 集成化的团队 项目定量管理工 程 需求管理 需求开发 技术解决方案 产