MBA智库文档管理项目管理适用于开发的能力成熟度集成模型.doc

适用于开发的能力成熟度集成模型.doc

下载

Malen_10

596页 | 3.33MB | 8次下载 |

3.5

(2人评价)

我要评价：

投诉举报

用手机看文档

扫一扫,手机看文档

下载

开通VIP

CMMI for Development Version CMMI for Development Version Pittsburgh, PA 15213-3890 适用于开发的能力成熟度集成模型 (CMMI-DEV) 版 CMU/SEI-2006-TR-008 ESC-TR-2006-008 为了更佳产品的过程改进 CMMI 产品团队 August 2006 在著作权下可无条件流通。 This work is sponsored by the . Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the . Department of Defense. Copyright 2006 by Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON® UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at -7013. For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site ( The following service marks and registered marks are used in this document: Capability Maturity Model® CMM® CMM IntegrationSM CMMI® IDEALSM SCAMPISM CMMI, CMM, and Capability Maturity Model are registered in the . Patent and Trademark Office. CMM Integration, SCAMPI, and IDEAL are service marks of Carnegie Mellon University. 此文档由美国国防部赞助。软件工程学院是由美国国防部提供官方基金所成立的研究开发中心。卡内基美隆大学版权所有 2006。无担保卡内基美隆大学软件工程学院系以文档交付时的状况提供文档。卡内基美隆大学对任何明示、默示的事情不做任何担保，其中包括但不限于符合特定用途的担保和适售性，尤其是使用此文档所产生的结果。卡内基美隆大学对于任何关于免除专利，商标或著作权侵害不做任何担保。使用此报告内的任何商标不能以任何方式侵害商标所有人的权利。内部使用。复制此文档或利用此文档衍生的文档，只要版权及无担保的声明包含于所有的复制文档及衍生文档内，可允许于内部使用。外部使用。复制此文档或利用此文档衍生的文档于外部或商业用途，应向软件工程学院授权中心提出申请。此文档是卡内基美隆大学软件工程学院，官方提供资金成立的研究开发中心，执行联邦政府合同号码FA8721-05-C-0003 所产生。美国政府拥有免技术权利金政府使用许可，以全部或部分或任何方式使用，复制或公布此文档。或根据版权许可条款-7013 允许他人做相同的事。有关于购买SEI报告复本的信息，请拜访我们网站的出版物部分( 此文档使用下列服务标章及注册商标： Capability Maturity Model® CMM® CMM IntegrationSM CMMI® IDEALSM SCAMPISM CMMI、CMM 及Capability Maturity Model 注册于美国专利商标局。CMM Integration、SCAMPI 及IDEAL 是卡内基美隆大学的服务标章。 CMMI 中文版发刊词面对产业与市场全球化的变革，产业快速响应市场变化的不二法便是回归检视核心的获利关键能力—过程。稳定的过程，忠实反应出企业的质量改进脉络、成本降低策略与缩短上市速度的能力，因此，掌握并改进过程即为企业创造获利空间的利器。 CMMI 严谨规范不仅符合持续改进的精神，着重过程、讲究细节更是大型系统工程架构开发的基础。卡内基美隆大学软件工程学院，协同政府机构、产业界共同研究开发CMMI 模型，于二十多年前首次将质量管理的概念带入软件开发过程管理，迄今仍秉持持续改进精神不断开发演进，将全球一流顶尖企业之最佳实践加入模型中，其卓越之贡献可由逐年递增的引用组织数及反馈改进成果报告中窥见。财团法人信息工业策进会长期投入软件工程的研究与部署工作，于2005 年获得SEI 支持出版CMMI v 中文版，对华文社会在导入、应用CMMI 提供极大的便利，并促进质量与生产力的提升。 CMMI v 版以中文版为基础，历时14 个月，并经内外部及独立审查，终于完成；特别要对本书的外部审查委员、独立审查人员及翻译小组致意，感谢他们对本书出版的投入，期各界对软件产业有识之士共同关注并持续帮助推动软件质量提升。财团法人信息工业策进会执行长陈铭宪 2007 年11 月 CMMI-DEV 中文版序产业关键之钥-软件信息科技开发以实现人类之梦想而不断创新精进。伴随着高度信息化的生活及多样化的科技产品，从瞬息万变的市场处处可见软件的影响力，其可谓为满足功能需求的关键之钥。软件生命周期随着市场快速变化而趋短，企业面临着需要质量优良、快速上市、成本精准掌控的考验，因此企业参与全球化竞争，其软件工程的精进修练已成必要。 CMMI 是美国国防部委托卡内基美隆大学软件工程学院(SEI)开发出来的，作为采购者评估供应者(开发者)的过程能力度与组织成熟度的标准，也可作为厂商提升产品(系统、软件、硬件)开发过程管理水平的参考。自1991 年起CMMs 陆续开发应用于许多专业领域，较著名的包含了系统工程、软件工程、软件采购、及集成的产品与过程开发(Integrated Process & Product Development) 等模型。由于使用单位快速增加及实务应用需要而于2000 年集成软件工程、系统工程、集成式产品开发等专业领域而发表了集成式模型CMMI 版，于2002 年加入委外作业管理后而为版。 CMMI 持续其不断改进的精神，在2006 年8 月发表CMMI 版，这个版本应用「群集」(constellations)概念，以一组核心组件的集合，提供高度共同内容给特定应用模型，将最佳实践扩展至新领域，包含2006 年公布的CMMI-DEV 开发模型(CMMI-Development) 、2007 年11 月发表的CMMI-ACQ 采购模型(CMMI-Acquisition) ，以及正在规划开发中的服务模型(CMMI-Service) 。此重要改变的意义在于同步提升供需双方在开发、采购及服务等各面向的过程管理能力，以达到双赢的效果。 CMMI-DEV 开发模型，系以开发者角度规范思考过程模型，目的是为了帮助组织改进其产品与服务之开发及维护过程。与前版相较其内容的差异部分主要如下：1.将阶段式与连续式两种表述合并以一体呈现；2.新增并强化硬件开发相关范例；3. 简化集成的产品与过程开发数据；4. 纳入委外作业管理延伸在基础模型中；其它如限定评估结果的最长效期为三年。中文版的制作除随英文版做上述内容变更外，也就版之勘误更正并增强译文之阅读性。 CMMI-DEV 中文版的制作过程依循严谨的程序。在SEI 的授权下，我们依据翻译成员之擅长领域分为项目管理、过程管理、工程以及支持等四个翻译小组，期间以同侪审查、查核会议及讨论的方式完成初稿，然后邀请外部专家审查。外部专家意见涵括文意、表达、词性、用字甚至标点符点等282 则。之后再经独立审查小组之审查。翻译小组对各方意见均逐一处理，往返推敲再修正定稿。 CMMI –DEV 中文版已制作完成，预期可对全球软件产业开发多有参考。在此，谨向所有参与人员致敬，谢谢他们的贡献。财团法人信息工业策进会资讯工程研究所所长范长康 2007 年11 月中文版参与人员指导人员吴明机经济部工业局罗达生经济部工业局廖振资经济部工业局綦淑媛经济部工业局外部审查范长康财团法人信息工业策进会张子龙财团法人信息工业策进会张文贵私立东海大学陈振楠关贸网络(股)有限公司庄顺吉升峰信息(股)有限公司彭永兴工业技术研究院鼎升数字科技(股)有限公司中冠信息(股)有限公司独立审查洪肇奎国立成功大学刑承中 MITRE Cooperation 陈杏村芝加哥大学翻译团队李治平财团法人信息工业策进会林文质财团法人信息工业策进会陈莉莉财团法人信息工业策进会黄永祥财团法人信息工业策进会黎兆滨财团法人信息工业策进会刘景华财团法人信息工业策进会欧世文财团法人信息工业策进会前言能力成熟度集成模型 (Capability Maturity Model® Integration,CMMI®)是一个针对产品与服务开发的过程改进成熟度模型。它包含开发与维护活动的最佳实践，涵盖产品从起始到交付与维护的生命周期。最新版本的CMMI模型集成了开发与维护所必需的知识体系，例如软件工程、系统工程、硬件与设计工程、工程服务与采购等，这些在过去都是个别阐述。适用于开发的CMMI (Capability Maturity Model® Integration for Development, CMMI-DEV ) 取代之前适用于软件工程及系统工程的CMMI (CMMI-SE/SW)，以真实地反映这些知识体系的广泛集成，以及组织的模型应用。CMMI-DEV 对于产品与服务的开发与维护活动，提供广泛集成的解决方案。 CMMI-DEV 版是利用CMMI 的「群集」概念，持续更新CMMI 版。「群集」提供一组核心过程组件，能够以附加过程的方式，来扩充成为具备高共同内容的特定应用模型(如CMMI-DEV, CMMIACQ 等)。其中CMMI-DEV 是针对开发领域，最早公布的特定应用模型。目的 CMMI-DEV的目的是为了帮助组织改进其产品与服务的开发与维护过程，它源自于CMMI 架构的最佳实践集合。针对特定领域，CMMI架构允许产生多个模型、培训课程与评估方法，以支持CMMI产品系列的开发。群集是针对某个领域的CMMI 组件集合，其中包含模型、培训教材，以及评估相关文档。目前版本的模型架构支持三个已规划的群集：开发、服务与采购。本份文档包含CMMI-DEV 群集，并且包含基本的CMMI-DEV 与附加IPPD 的CMMI-DEV(CMMIDEV+IPPD)。「附加」是将特定额外内容扩充到群集的机制。假如你目前没有使用IPPD ，就忽略被标记为「IPPD 附加」的信息，你使用到的模型即为CMMI for Development 模型。与CMMI 版不同之处，是用单一模型文档描述过程改进的阶段式与连续式表述，而不是用个别文档描述阶段式与连续式表述。将这两种表述的模型内容统一描述的做法，最早开始于CMMI: Guidelines for Process Integration and Product Improvement 这本书中。感谢Peter Gordon、出版商Addison-Wesley 与本书作者Mary Beth Chrissis 、Mike Konrad 与Sandy Shrum，使我们能够使用这本书的手稿，当做开发CMMI 版本的基础 [Chrissis 2003]。致谢许多精英参与CMMI 产品系列的产品团队，三个主要参与这个开发的群组是推动组、产品团队、配置控制委员会。推动组指导及批准产品团队的计划，提供CMMI 项目重要问题的咨询，确认包含各种不同有兴趣的社群。产品团队撰写、审查、修订、讨论及认可CMMI 产品系列的架构及技术内容，包括架构、模型、培训及评估教材。开发活动是根据各种不同的来源。这些来源包含推动组所提供的一份A-规格与每一次释指导详述、来自于使用者社群的变更请求、来源模型以及来自于其他干系人的草案 [SEI 2004]。配置控制委员会是一个控制CMMI 模型与Introduction to CMMI 培训课程变更的正式机制。因此，此群组通过审查所有被提议的基线变更，以及只批准满足已识别问题及符合下一个版本准则的变更，来确保产品系列生命周期的完整性。附录C 列出参与开发CMMI 版本的群组成员。读者群本模型的读者群包括任何对开发与维护环境的过程改进有兴趣的人。无论你是否熟悉能力成熟度集成模型的内容或是你正在寻求信息以开始进行你的改进工作，这份文档都将有助于你。本模型的预期读者包含想要使用评估来了解自身目前所处情况的人、已经知道该从哪里进行改进的人、刚刚开始进行的人以及想要对CMMI for Development 群集有一般性了解的人。本文档的组织本文档可以由SEI网站取得以提供组织过程改进指导。它主要被组织为三个主要部分： • 第一单元—关于CMMI for Development • 第二单元—通用目标、通用实践以及过程域（Generic Goals and Generic Practices, and the Process Areas） • 第三单元—附录与词汇第一单元「关于CMMI for Development」包含以下五章： • 第一章，「简介」，提供一个CMMI 与CMMI for Development 群集的广泛概述。本章以过程改进的概念来引导你，并且描述用于过程改进的模型历史以及不同的过程改进方法。 • 第二章，「过程域组件」，描述CMMI for Development 过程域下的所有组件。 • 第三章，「试着合而为一」，组合模型组件与解释成熟度等级及能力度等级的概念。 • 第四章，「过程域间的关系」，针对CMMI for Development 下所有过程域的互动关系做更深的剖析。 • 第五章，「使用CMMI 模型」，描述CMMI 在过程改进与标竿学习上的采用与使用路径。第二单元，「通用目标、通用实践以及过程域」，包含所有CMMI for Development 群集必要的及期望的组件。它也包含相关参考的组件，包括组件名称、子实践、注释与典型的工作产品。第二单元包含23节。第一节包含通用目标与通用实践，说明它们如何被使用以及描述它们与过程域的关系。其余的22节，每一节都描述一个CMMI for Development 的过程域。为了使这些过程域容易被找到，它们是以首字母的缩写字来排序。每一节均包含目标描述、最佳实践与范例。第三单元「附录与词汇」包含4 个信息资源： • 附录A，「参考数据」，提供参考信息以便你可以找到有关CMMI for Development 的原始纪录，例如报告、过程改进模型、产业标准及书籍等。 • 附录B，「缩写字」，定义本文档所使用的缩写字。 • 附录C，「CMMI for Development 项目的参与者」，包含参与CMMI for Development 版本开发的人员及组织名单清单。 • 附录D，「词汇」，定义CMMI 所使用的许多术语。如何使用本文档无论你是刚接触过程改进与CMMI或是已经熟悉CMMI，第一单元都可以帮助你了解为什么CMMI for Development 是用来改进开发与维护过程的最佳模型。刚接触过程改进的读者假如你不熟悉过程改进或是CMM®概念，我们建议你先开始阅读第一章，「简介」。第一章将会给你一个过程改进的整体概念，并且解释CMMI是什么。接下来，浏览第二单元，包含通用目标、通用实践和特定目标及特定实践，去感觉（get a feel）此模型下的最佳实践的范围。将注意力放在每一节要开始前的目的与前言说明。在第三单元，在开始使用CMMI for Development 前，仔细阅读附录A 的参考文献以及挑选部分你认为有助于你阅读的额外原始资料。彻底阅读缩写字与词汇以熟悉CMMI 的用语，然后，回到第二单元做更详细的阅读。有过程改进经验的读者假如你刚接触CMMI，但是有其它过程改进模型的经验，例如软件能力成熟度模型版本、系统工程能力成熟度(例如EIA 731)，你可以立即认识到有许多相似之处 [EIA 1998]。我们建议你阅读第一单元来了解CMMI与其它过程改进模型的差异，但是你可能想要更快速的阅读部分章节。简略的阅读第二单元时，从模型中找出你会试行的最佳实践。识别熟悉的内容，可以让你感觉什么是新的，以及哪些模型中的内容是你已经知道的。接着下来，回顾词汇以了解相同名称术语在本文档与你所知道的过程改进模型中的定义差异。许多内容将有可能重复，但是他们可能有部分差异。熟悉能力成熟度集成模型的读者假如你在之前已经回顾（reviewed）或是使用过CMMI 模型，你可以很快的认识CMMI 所讨论的内容以及所呈现的最佳实践。版本与版本的差异被更细微的解释在SEI 网站上的release notes。这些差异反映版本使用者所提出的改进建议。以下是版本所做的改进： • 两种表述一体呈现。 • 移除进阶实践与一般共同特征的内容。（The advanced practice and common feature concepts have been removed） • 通用目标与通用实践的描述移到第二单元。 • 新增硬件部分。 • 统一所有的词汇定义。 • IPPD 实践的合并与简化。不再有任何单独处理IPPD 的过程域。 • 供应商协议管理(SAM)与集成的供应商管理(ISM) 被合并，并移除供应商来源。 •通用实践详细说明新增第三级的通用实践。 •新增过程域如何支持通用实践执行的解释。 •新增内容以确保项目开始时可以布署标准过程。反馈信息你可以通过各种不同的渠道找到有关于CMMI的额外信息，例如：CMMI 模型的背景与历史及使用CMMI 模型的效益。这些渠道被列在附录A 以及被发表在CMMI 网站— [SEI 2]。欢迎任何有关改进CMMI 产品系列的建议，有关如何提供反馈的信息，请参阅CMMI 网站：。如果有任何问题，请送电子邮件到cmmi-comments@ 。修订记录版本号修订时间修订内容修改人 2008年5月根据台湾版繁体中文版，用office转换为简体版，对不一致的地方进行了修改。宋涛 2008年7月将PPQA里的“评估”（evaluate）修改为“评价”；将文档中的“议题”修改为“问题”。Appraise 是评估的含义。修改了其他用此不准确的地方。宋涛目录 4CMMI 中文版发刊词 8前言 8目的 9致谢 10读者群 12如何使用本文档 14反馈信息 18关于CMMI for Development 191 简介 332 过程域组件 463 试着合而为一 674 过程域间的关系 815 使用CMMI 模型 88通用目标与通用实践及过程域 89通用目标与通用实践 114原因分析与解决方案（CAR 5级） 129配置管理（CM 2级） 146决策分析与解决方案（DAR 3级） 161集成的项目管理 + IPPD （IPM 3级） 195度量与分析（MA 2级） 216组织创新与部署（OID 五级） 238组织过程定义+ IPPD （OPD 3级） 261组织过程焦点（ODF 3级） 283组织过程绩效（OPP 4级） 298组织培训（OT 3级） 316产品集成（PI 3级） 336项目监控（PMC 2级） 351项目策划（PP 2级） 380过程与产品质量保证（PPQA 2级） 392量化项目管理（QPM 4级） 418需求开发（RD 3级） 441需求管理（REQM 2级） 454风险管理（RSKM 3级） 476供应商协议管理（SAM 2级） 497技术解决方案（TS 3级） 526确认（VAL 3级） 541验证（VER 3级） 560附录与词汇 561附录A. 数据资料 561公开的资料 564Regularly Updated Sources 565附录B. 缩写字 568附录C. CMMI-DEV 项目参与人员 574D.词汇第一单元关于CMMI for Development 1 简介现在，越来越多企业想要使产品和服务的交付做得更好、更迅速与更便宜。同时，在二十一世纪的高科技环境里，几乎所有的组织都发现所开发的产品和服务越来越复杂。今天，单一企业通常不会开发产品与服务的所有组件。更普遍的情况是，一部分组件自行开发，一部分组件采购，然后将所有的组件集成成最终产品或服务。组织必须能够管理与控制这样复杂的开发与维护过程。今天，这些组织需要一个集成方法，解决涉及到企业整体环境的问题。组织资产的有效管理是经营成功的关键。本质上，这些组织是产品及服务的开发者，需要一个管理开发活动的集成方法，作为达成经营目标的部分方法。在目前的市场上，有成熟度模型、标准、方法论与指导，可以帮助组织改进经营方式。但是，大多数可利用的改进方法专注于经营的特定部分，并没有针对许多组织今天所面对的问题采取系统的方法。由于专注于改进经营上的一个领域，这些模型不幸地使组织永远存在高烟囱(难以沟通)和障碍。能力成熟度集成模型(Capability Maturity Model® Integration, CMMI®) 凭借优越专业领域的集成模型，提供一个机会来避免或排除这些高烟囱(难以沟通)和障碍。CMMI for Development 包含处理应用于产品及服务的开发活动的最佳实践。它处理涵盖产品生命周期从构思到交付与维护的实践。强调建立与维护整体产品所必需的工作。关于能力成熟度模型在帮助组织开发与维护质量产品及服务的研究中，SEI 发现，组织可以专注数个改进经营的维度。图说明组织一般会专注的3个重要维度：人员、过程与方法，以及工具与设备。图三个重要的维度但是什么将一切都结合在一起呢？答案是你组织中所使用的过程。过程允许你校准（align）你执行的经营方式，允许你处理扩大规模，并提供一个方式，集成如何让事情做得更好的知识。过程允许你善用你的资源与审视经营趋势。这不是说人员与技术不重要。我们现今生活的世界，技术有规律的每十年改变一次。同样，人员在事业生涯中一般会在多家企业工作。我们生活在一个动态的世界。专注于过程，提供处理世界每次变动所需要的基础建设，以及最大化人员的生产力，并且让技术的使用更具有竞争力。制造业早就认知到过程的效果（effectiveness）与效率(efficiency)的重要性。今日，许多制造业与服务业的组织认识到质量过程的重要性。过程帮助人员更敏捷的工作而非费力工作及一致性改进，来参考组织人员符合经营目标。有效的过程也提供导入与使用新技术的工具，以符合组织的经营目标。在1930 年代，瓦特．萧华德开始利用统计质量管理原理，致力于过程改进 [Shewhart 1931]。这些原理被威廉．爱德华．戴明[Deming 1986]、菲力普．克劳斯比[Crosby 1979]、约瑟夫．朱兰[Juran 1988] 重新定义。瓦兹．韩福瑞、罗恩．雷迪斯及其他人开始在IBM 与SEI [Humphrey 1989]内延伸这些原理至软件。韩福瑞的书「管理软件过程，Managing the Software Process」提出基本原理与观念的描述，有许多成为能力成熟度模型的基础。 SEI 认定过程管理的前提是「一个系统或产品的质量会高度受到开发并维护它的过程质量影响」，并且定义CMMs 来具体化这个前提。这个前提里的信念在全世界的质量活动中都可以得见，国际标准组织/国际电子技术委员会(ISO/IEC)标准的内容就是一个证据。 CMMs 专注于改进组织的过程。它们包含一到多个专业领域的有效过程的必要元素，并且描述由混乱且不成熟的过程到专业且可提升质量与效果的成熟过程的演进改进途径。 SEI 首先针对软件组织设计能力成熟度模型，并出版一本书「The Capability Maturity Model: Guidelines for Improving the Software Process 」[SEI 1995]。 SEI 的书将几乎是一个世纪以前的原理应用在持续过程改进。这个过程改进方法的价值已经通过时间考验。组织已有提升生产力与质量及更精确与可预测进度与预算的经验[Gibson 2006] 。能力成熟度集成模型的演进自1991 年后，CMMs 开始在各种专业领域上开发。一些比较著名的模型包含系统工程、软件工程、软件采购、人力管理及开发，以及集成产品与过程开发(IPPD)。虽然这些模型已经被证实对不同产业的许多组织有益，然而使用多个模型是有问题的。许多组织想要将它们的改进成果扩展到组织中的其它群组，然而每个群组使用的特定专业领域模型的差异，包含架构、内容与方法，却限制这些组织改进成功的能力。再者，使用未经组织内及跨组织集成的模型，就培训、评估和改进活动而言是昂贵的。 CMMISM 项目的成立旨在厘清使用多种能力成熟度模型的问题。CMMI 产品团队初始的任务是集成三个来源模型： 1. 软件能力成熟度模型(SW-CMM) 版草案C [SEI 1997b] 2. 系统工程能力模型(SECM) [EIA 1998] 3. 集成产品开发能力成熟度模型(IPD-CMM) 版 [SEI 1997a] 将这些模型集成成单一的改进架构，以供寻求企业全面过程改进的组织使用。选择这三个来源模型，是因为它们被广泛的采用于软件及系统工程社群，以及它们对组织过程改进的不同方式。采用具普遍性且被重视的模型作为来源数据，CMMI 产品团队创造一组紧密结合的集成模型，此模型既能被目前使用来源模型者采用，又能被那些对能力成熟度模型概念尚生疏者所采用。因此，CMMI 是SW-CMM、SECM 与IPD-CMM 的演进结果。开发一组集成模型，不仅是单纯地将现有的模型组合起来。藉由使用提升共识的过程，CMMI 产品团队建立可容纳多种专业领域，并有足够弹性以支持不同来源模型方法的架构 [Ahern 2003]。图 : 能力成熟度模型家族的历史自CMMI 版本正式发表后，我们已经看到这个改进架构可以被应用于其它有兴趣的领域 [SEI 2002a, SEI 2002b]。为了应用到多个有兴趣的领域，这个架构将最佳实践分群到我们所谓的「群集」。群集是建立模型、培训教材与评估文档之CMMI 组件的集合。最近，CMMI 模型架构已经改良，以支持多个群集，以及群集与其成员模型间分享最佳实践。从两个新群集开始工作：一个是针对服务（CMMI for Services ），另一个是针对采购（CMMI for Acquisition ）。虽然CMMI for Development 加入了服务开发含组件、消耗品与人员的组合，以满足服务需求，它仍不同于规划中专注于服务交付的CMMI for Services。在2006 年以前，于社群中所使用的CMMI 模型，现在可视为CMMI for Development 群集的一部分。适用于开发的CMMI CMMI for Development 群集包含2个模型：CMMI for Development + IPPD 与CMMI for Development （不包含IPPD）。这两个模型共享许多内容，这些共享的领域是完全相同的。然而，CMMI for Development + IPPD 包含IPPD 附加的目标与实践。目前，只有一个模型已经被发表。在CMMI for Development +IPPD 模型中包含群集内全部完整且可以利用的实践，你可以从这个内容取得其它模型。假如你现在没有使用IPPD，请忽略标示为「IPPD 附加」的信息，即你使用的是CMMI for Development 模型。假如出现需求或是扩展开发群集，这个架构允许产生与发表其它模型。 CMMI for Development 是这三个来源模型的指定继承模型。SEI 已经淘汰软件能力成熟度模型与IPDCMM。EIA 已经淘汰SECM。这三个模型由CMMI for Development 代替。 CMMI 模型的最佳实践已经过了广泛的审查过程。CMMI 版本经过公开审查并在试行活动中使用。 CMMI 产品团队评估超过3000个变更请求，以建立CMMI 版本。不久之后，发表细微修正的CMMI 版本。版本包含来自于初期使用反馈的改进指导，公开审查所提交超过1500个变更请求，以及来自于变更控制过程的数百个意见。 CMMI 版本是通过CMMI 使用者所提交将近2000个变更请求，当做来源所开发的。这些变更请求中，有超过750个是与CMMI 的内容直接相关。如同你所见到的，不只是CMMI被广泛的采用，CMMI 也从所收到的社群反馈进行改进。 CMMI for Development 的范围 CMMI for Development 是一个涵盖应用于产品与服务的开发与维护活动的参考模型。许多产业的组织，包含航天产业、银行产业、计算机硬件产业、软件产业、国防产业、汽车制造产业与电信产业，使用CMMI for Development。 CMMI for Development 群集中的模型包含使用在开发与维护的实践，涵盖项目管理、过程管理、系统工程、硬件工程、软件工程与其它支持过程。CMMI for Development + IPPD 模型也涵盖集成团队使用于开发与维护活动。 IPPD 附加的群组在CMMI 中，「附加」使用于包含特定使用者有兴趣的内容，在CMMI for Development 群集中，包含处理IPPD 的附加内容。附加IPPD 群组涵盖IPPD 方法，包含参考组织在产品生命周期中，达到相关干系人实时合作的实践，以满足客户需要、期望与需求[DoD 1996 ] 。当使用支持IPPD 方法的过程时，你应该将这些过程与组织的其它过程集成。为了支持那些使用与IPPD 相关的过程，CMMI for Development 群集允许组织随意地选择附加IPPD 群组。当你选择CMMI for Development + IPPD，你选择的是CMMI for Development 模型，并额外加上所有的IPPD 附加。当你选择CMMI for Development，你选择的模型不包含IPPD 附加。为了简洁文档，本文档第一单元中，我们使用「CMMI for Development」可能是这些模型中的任何一个。解决CMM 家族的差异看法能力成熟度模型的定义允许社群开发模型，以支持不同的过程改进方法。只要一个模型对一或多个的专业领域包含有效过程的必要元素，并且描述由混乱的不成熟过程到有纪律且可改进质量与效果的成熟过程的演进改进途径，它就可视为是能力成熟度模型。CMMI 使用两种不同的表述：连续式与阶段式，帮助你进行过程改进与评估。连续式表述帮助组织选择一个过程域（或一组过程域）和改进与其相关的过程。这个表述使用能力度等级，描述与个别过程域有关的改进。阶段式表述使用预先定义的几组过程域，以定义组织过程改进的途径，这个改进途径使用成熟度等级描述。每一个成熟度等级提供一组过程域，描述不同的组织行为。选择表述假如你对过程改进没有经验，并且不熟悉阶段式或连续式表述，无论你选择哪一个表述，你都不会出错，因为有许多有根据的理由指出，可以选择两者中的任何一个表述。假如你已经使用能力成熟度模型，并且熟练一个特定的表述，我们建议你继续使用这个表述，因为它将使得转换到能力成熟度集成模型的过程更容易。当你完全对能力成熟度集成模型满意，你才能决定使用其它的表述。因为每一个表述都有其优越之处，有些组织会在其改进项目的不同时间点上，使用两种表述解决特定的需求。在接下来的章节中，我们提供每一个表述的优点与缺点，参考你决定哪一个表述对你的组织是最好的。连续式表述当使用CMMI 模型进行过程改进时，连续式表述可提供最大的弹性。一个组织可以选择改进单一过程相关的问题点的绩效，或是可以使用多个领域以密切配合组织的经营目标。连续式表述也允许一个组织将不同的过程改进至不同的等级。但组织在选择上仍有一些限制，因为有一些过程域是彼此相依的。假如你知道在你的组织中需要改进的过程，以及了解CMMI 中过程域间的相依性。对你的组织而言，连续式表述是一个好的选择。阶段式表述阶段式表述提供系统化与结构化的方式，一次一个阶段达到以模型为基础的过程改进。达成每一个阶段可确保有足够的过程基础建设，可作为下一个阶段过程改进的基础。过程域是以成熟度等级组织，并且对过程改进做一些推测工作。阶段式表述根据成熟度等级规定执行过程改进的顺序，它定义一个组织由初始级到已优化级的改进路径。达到每一个成熟度等级可确保有足够的过程基础建设，可作为下一个成熟度等级的基础，并且允许持续与渐进的改进。假如你不知道要选择哪一个过程开始进行改进，阶段式表述对你而言是一个好的选择。它给你一组特定的过程，针对每一个阶段进行改进。这组过程的决定，是来自于十多年过程改进的研究和经验。连续式与阶段式表述的比较表比较每一个表述的优势，能够帮助你决定哪一种表述适合你的组织。表连续式与阶段式表述的优势比较连续式表述阶段式表述授予明确的自由度来选择最符合组织经营目标与减少组织风险范围的改进顺序使组织有一个已定义且被证实的改进路径增加每一个过程域能力度透视度专注在一组过程域，此组过程域为每一成熟度等级的特征，提供组织特定的能力允许对不同过程执行不同等级的改进以简单的形式汇总过程改进结果—单一成熟度等级数目一种新方法仍未有数据证明其与投资回报率有关连建立在一个相对长期的使用历史，包含项目研究与数据以证明投资回报率你的决策因素当选择表述时，有三种类型的因素可能影响你的决定：经营、文化与现状。经营因素当组织在经营目标上有成熟知识，很可能有一个强大的过程对应到其经营目标。这样的组织可能发现连续式表述有利于评估其过程，以及决定组织过程支持及符合经营目标的程度。如果组织产品线专注于决定要改进跨组织的过程，它最好使用阶段式表述。阶段式表述将参考组织在改进上选择要专注改进的重要过程。同一个组织也可能利用产品线来改进过程。那样的话，它可能选择连续式表述—每一个产品线有不同的能力度评估等级。这两种表述都是有效的。最重要的考量是哪些经营目标是你希望你的过程改进项目要支持的与这些经营目标如何用两种表述校准。文化因素当选择表述与组织部署过程改进计划的能力有关时，要考虑文化因素。例如，如果企业文化是以过程为基础且对过程改进有经验，或是有特定过程需要快速地改进，组织就可能选择连续式表述。若组织缺乏过程改进经验，可能选择阶段式表述，阶段式表述提供要发生的变更及顺序的额外指导。现状假如一个组织对其它模型有阶段式表述的经验，当使用CMMI 时，它可能希望继续使用阶段式表述，尤其是组织已经跨组织投入资源及部署过程，这与阶段式表述相关。会继续使用连续性表述亦是如此。为什么不是两种表述? 不管是使用于过程改进或评估，这两个表述是设计来提供相同的结果。这两种表述的CMMI 模型内容几乎相同。因此，组织只要选择一个表述即可。事实上，组织可能发现此二种表述是通用的。组织很少完全地实行前述的某一种表述。在过程改进上成功的组织经常定义一个改进计划，此改进计划专注在组织的唯一需要，然后使用阶段式与连续式表述的原则。例如，选择阶段式表述并位于成熟度第1级的组织，常常会在实行成熟度第2级的过程域时，执行位于组织成熟度第3 级下的组织过程焦点过程域。另一个例子，组织选择连续式表述，指导其内部过程改进工作，然后选择阶段式表述进行评估。你的过程改进方法为了要展示如何使用这个模型，让我们看两个不同的情节。情节1 是一个电子系统开发者想要使用连续式表述来改进它的产品开发过程。情节2是一个已经使用IPPD与软件能力成熟度模型的软件开发公司，现在想要使用能力成熟度集成模型，这个公司目前达到软件能力成熟度的第3级。情节1 在情节1中，你使用连续式表述，并选择对你的经营目标是重要的过程。由于有22 个过程域可以选择，当在开始时，过多的过程域通常使我们会不知如何着手。你需要缩小你的焦点。举例来说，你也许发现到竞争对手的产品总是比你的产品还要早发布，因此你可能选择专注于改进你的工程与项目管理过程。建立在这个决定上，选择所有的工程过程域当成一个开始点：产品集成、需求开发、需求管理、技术解决方案、确认与验证。你也选择项目策划与项目监控。你在此点上决定一开始要专注八个过程域仍然是过多的，然后你决定需求过程是问题的真实所在。所以你选择需求开发与需求管理过程域，开始你的改进工作。接着下来你要决定需求领域需要改进到多好。你有任何的过程已经在需求领域上吗？如果你并没有，你的过程改进目标可能要从能力度第1级开始。您的每一个项目都有需求开发及管理过程，但是它们却不是已管理的过程？举例来说，方针、培训和工具无法执行以支持过程。假如您有需求过程，但是它们并没有支持的基础建设，您的过程改进目标也许是在能力度等级第2级。你有所有的需求开发与管理过程，并且它们已被管理，但是每一个项目执行的过程却是有差异的？例如，您的需求诱导过程无法在跨组织中被一致地执行。假如以这个项目来看，您的过程改进目标也许是在能力度等级第3级。你有一致性地管理与执行你的需求开发及管理过程，但是没有用客观方式去控制和改进这些过程吗？假如以这个项目来看，你的过程改进目标也许是在能力等级第4 级。你想要确保您根据量化目标所选择的适当子过程可以最大化你的经营？假设是如此，你的过程改进目标也许是针对所选择的过程到能力度等级第5级。在每个过程域的描述下，记得要去看「适用于硬件工程」、「适用于系统工程」与「适用于软件工程」的强化。使用没有特定标记与被框线标记为「仅适用于连续式表述」的所有信息。如你在这个情节所见到的，你需要了解哪些过程需要改进以及每一个过程要达到的成熟度。这个进行方式反映了连续式表述的根本准则。情节2 在第二个情节中，你是一间使用IPPD 与软件能力成熟度模型的软件开发公司，你想要使用能力成熟度集成模型。你选择成熟度第2 级与第3 级的过程域，以及选择CMMI for Development + IPPD 模型。这个选择包含成熟度等级第2级下的七个过程域：需求管理、项目策划、项目监控、供应商协议管理、度量与分析、过程与产品质量保证、配置管理。它也包含成熟度等级第3 级下的11 个过程域：需求开发、技术解决方案、产品集成、验证、确认、组织过程焦点、组织过程定义、组织培训、集成的项目管理、风险管理及决策分析与解决方案。你也会包含IPPD 附加在内。因为你在软件能力成熟度模型中，已经被评等为成熟度第3级，所以只要看那些包含在CMMI 内，但却未包含在软件能力成熟度模型内的过程域。这些过程域包含度量与分析、需求开发、技术解决方案、产品集成、验证、确认、风险管理及决策分析与解决方案。确认你的组织是否存在这些过程，即使它们没有被软件能力成熟度模型描述。假如有任何合适的过程可以与这些过程域对应，或是与软件能力成熟度模型之其它过程域对应，执行差异分析去对照这些目标及实践，以确保你解决每一个CMMI 过程域的意图。记住，每一个你所选择的过程域，察看标记为「适用于软件工程」与「IPPD 附加」的信息。使用没有特定标记与被框线标记为「仅适用于阶段式表述」的所有信息。如你所见，这份文档所提供的信息可以有各种使用方式，审视你的改进需要。能力成熟度集成模型的整体目标是提供一个可以一致地分享过程改进最佳实践的架构与表述，但是仍有足够的弹性解决社群变更的需要。 2 过程域组件这一章说明每一个过程域、通用目标与通用实践的组件。了解这些组件的意义，对于有效使用第二单元的信息是重要的。假如你不熟悉第二单元，在阅读本章之前，你可能要快速浏览通用目标与通用实践的章节以及相关过程域的章节，以针对内容与版面编排取得一般性的理解。必要的、期望的及参考的组件 CMMI 模型组件被群组成三个类型――必要的、期望的与参考的――反映如何解释它们。必要的组件必要的组件是说明一个组织要满足某一个过程域所需要达成的成果。这个成果必须很明显地被一个组织的过程所执行。在CMMI 中的特定目标及通用目标是必要的模型组件。目标满足是在评估中决定某过程域是否有达成或满足的基础。期望的组件期望的组件说明一个组织要达成某一个必要的组件所需要执行的作法。期望的组件用来指导要执行改进或评估的个人与团体。期望的组件包含特定实践和通用实践。在目标被认定已满足之前，实践或其可行的替代方案，都必须表现于组织已规划和已实行的过程之内。参考的组件参考的组件提供详细描述以帮助组织开始着手思考，如何达成必要的组件与期望的组件。子实践、典型的工作产品、强化、通用实践详细说明、目标和实践的标题、目标和实践的批注及参考数据都是参考的模型组件的例子。 CMMI的词汇并不是CMMI 模型的必要的、期望的及参考的组件。你必须以词汇中之术语在模型组件出现时的上下文来诠释它的意义。第二单元相关的组件汇总与第二单元有关的模型组件，并说明它们的关系，如图所示。图能力成熟度集成模型的组件下面章节提供模型组件的详细说明。过程域过程域是一个领域下相关实践的集合，当它们共同执行时，满足一系列被视为对改进该领域是重要的目标。这里有22个过程域以首字母缩写方式依序排列： • 原因分析及解决方案(CAR) • 配置管理(CM) • 决策分析与解决方案(DAR) • 集成项目管理+IPPD(IPM+IPPD)6 • 度量与分析(MA) • 组织创新与开发(OID) • 组织过程定义+IPPD（OPD+IPPD） • 组织过程焦点(OPF) • 组织过程绩效(OPP) • 组织培训(OT) • 产品集成(PI) • 项目监控(PMC) • 项目策划(PP) • 过程与产品质量保证(PPQA) • 量化项目管理(QPM) • 需求开发(RD) • 需求管理(REQM) • 风险管理(RSKM) • 供应商协议管理(SAM) • 技术解决方案(TS) • 确认(VAL) • 验证(VER) 目的目的说明过程域的目的，目的是参考的组件。例如，组织过程定义过程域的目的是「组织过程定义(OPD)的目的是建立与维护一套可以使用的组织过程资产与工作环境标准」。前言过程域的前言是说明过程域所涵盖的主要观念，是参考的组件。例如，在项目策划过程域的前言例子是「规划始于定义产品及项目的需求」。相关过程域相关过程域列出与过程域有关的过程域参考数据，并反映过程域间高等级的关系。相关过程域是参考的组件。项目策划过程域的相关过程域章节的参考数据，例如「请参考风险管理过程域，有关识别与管理风险的部分，以获得更多信息」。特定目标特定目标描述必须用来满足该过程域唯一的特征。特定目标是必要的模型组件以及被使用在评估中判断某个过程域是否满足。例如，配置管理过程域的其中一个特定目标是「建立与维护基线的完整性」。只有特定目标下的说明是必要的模型组件。特定目标的标题（前有目标编码）与该目标有关的任何注释视为参考的模型组件。通用目标通用目标之所以称为「通用」是因为相同的目标说明可适用于多个过程域。通用目标描述必须能够呈现执行过程域过程制度化的特征。通用目标是必要的模型组件，被使用在评估中判断一个过程域是否满足。（通用目标的详细描述，请参看通用目标与通用实践章节）。通用目标的例子是「过程制度化为已定义过程」。只有通用目标下的说明是必要的模型组件。通用目标的标题（前有目标编码）及任何与目标有关的注释被视为参考的模型组件。特定目标与实践摘要特定目标与实践摘要提供特定目标高层的摘要。特定目标是必要的组件，特定实践是期望的组件，特定目标与实践摘要是参考的组件。特定实践特定实践是一种活动的说明，它对达成相关的特定目标是重要的。特定实践说明能够达成过程域特定目标期望结果的活动。特定实践是期望的模型组件。例如，项目监控过程域的一个特定实践是「依据项目计划所识别的承诺，监督承诺」。只有特定实践下的说明是期望的模型组件。特定实践的标题（前有实践编码）及任何与该特定实践有关的注释，被视为参考的模型组件。典型的工作产品典型的工作产品章节列出特定实践所产出的范例。这些范例称之为典型的工作产品，是因为除了这些具代表性的范例之外，还有其它的工作产品也是有效的，但未被列出。典型的工作产品是参考的模型组件。例如，项目监控过程域中特定实践「依照项目，监督项目策划参数的实际值」的一个典型的工作产品是「重大偏差的记录」。子实践子实践是一个详细说明，提供解释与执行特定或通用实践的指导。子实践可能以规范的文字描述，但是实际上是一个参考的模型组件，只提供可用于过程改进的想法。例如，项目监控过程域中特定实践「对问题采取纠正行动」的一个子实践是「决定与文档化所需解决已识别问题的适当活动」。通用实践通用实践之所以称为「通用」是因为相同的实践可适用于多个过程域。通用实践被视为达成相关的通用目标的重要活动。通用实践是期望的模型组件。例如，通用目标「过程制度化为已管理的过程」下的通用实践「提供足够的资源执行过程、开发工作产品与提供过程服务」。只有通用实践的说明是期望的模型组件。通用实践的标题（前有实践编码）与该实践有关的任何注释，被视为参考的模型组件。为了降低此信息的重复性以及节省用来呈现此信息的页数，只有通用实践的标题、叙述与详细说明会显示在过程域。（通用实践的完整描述请参看通用目标与通用实践章节）。通用实践的详细说明通用实践详细说明是参考的模型组件，它出现在各过程域，并提供指导以说明通用实践要如何应用于过程域。例如，项目策划过程域的通用实践「建立与维护策划与实施项目策划过程的组织方针」的详细说明是「这个方针建立估计规划参数，决定内部与外部承诺，与开发管理项目计划的组织期望」。支持参考的组件在很多地方，需要进一步的数据来描述一个概念。这种参考的数据是以下列组件方式提供： • 注释 • 范例 • 强化 • 参考数据注释注释是紧密附带在任何其它模型组件的文字。它可能提供细节、背景或原由。注释是参考的组件。例如，在原因分析与解决方案过程域中，伴随特定实践「执行在原因分析中开发且被选择的活动建议」的注释是「只有证明为有价值的变更才应该被考虑广泛实行」。范例范例包含文字与项目清单的组件，通常用框线加以区隔。范例会紧密附带在任何其它组件中，并提供更多的例子，以厘清观念或说明活动。范例是参考的组件。下面在过程与产品质量保证过程域中，伴随在子实践「当它们在项目中无法解决时，文档化无法遵循的争议」下的特定实践「与员工及管理者沟通质量争论，并确保无法遵循的争论已解决」的范例。解决项目中无法遵循争论的方法的范例： • 修改不符合项。 • 变更所违反的过程描述、标准或程序。 • 取得无法遵循的豁免书。强化（Amplifications）强化是一个与特定专业领域有关的注释或范例。本模型中的专业领域为硬件工程、系统工程与软件工程。每一个强化使用其专业领域的名称加以标记。例如，软件工程的强化标记为「适用于软件工程」。强化是参考的模型组件。强化的例子，在项目策划过程域中的特定实践「建立与维护整体项目计划内容」下，这个强化说明「适用于硬件工程：对于硬件，规划文档常常参考到硬件开发计划。准备生产的开发活动可能包含在硬件开发计划或是定义在个别的生产计划内」。参考数据参考数据是指相关过程中附加或是更详细的信息。参考数据会紧密伴随在任何其它模型组件。参考数据是参考的模型组件。例如，在量化项目管理过程域的特定实践「根据历史稳定与能力数据，选择包含项目定义过程的子过程」下，所伴随的参考数据「有关组织过程资产库，应该包含已知与所需能力的过程组件，请参考组织过程定义过程域」。编码系统特定及通用目标以流水号的方式编码。每一个特定目标的编码以SG 开头(例如：SG1)。每一个通用目标的编码以GG开头(例如：GG2)。每个特定实践的编码以SP 开头，其后有数字 (例如：SP )。x 对应特定目标的编号，而y 是特定目标之下特定实践的序号。以项目策划过程域的特定实践编码为例，第一个实践的编码是SP ，第二个是SP 。每个通用实践的编码以GP 开头，其后有 (例如：GP )。 x 是对应通用目标的编号，y 则是通用目标之下通用实践的序号。例如，GG2 下的第一个通用实践的序号是，第二个是。印刷惯例本模型的印刷惯例是设计来帮助你有效地选择与使用你所需要的部分。我们描述的模型组件格式允许你在页面中快速地找到它们。图到是第二单元中过程域的范例页面。它们显示不同的过程域组件，并以标记让你可以识别它们。注意组件在印刷上的差异，你就可以容易地识别出每一个。图原因分析与解决方案的范例页面图验证的范例页面图集成的项目管理+IPPD 的范例页面表述的特定内容在第二单元中，每一个过程域的目标章节下，你会注意到一些通用实践的组件被框起来并命名为「仅适用于阶段式」、「仅适用于连续式」或「连续式/成熟度3-5 级」。没有标记的组件可应用于两种表述。标记为「仅适用于阶段式」的组件只在你使用阶段式表述中才使用。标记为「仅适用于连续式」的组件只在你使用连续式表述中才使用。（看图的例子）标记为「连续式/成熟度3-5 级」的组件只在你使用连续式表述或是要进行成熟度第3级、第4级与第5级时才可以使用。所以如果你进行阶段式表述成熟度第2级的评等时，并不应用这些组件。附加附加可以是参考的内容、特定实践、特定目标或过程域，以延伸模型范围或强调使用上的特定观点。在本文档中，所有的附加都应用于IPPD。组织培训过程域中附加的范例，出现在特定目标1「建立组织培训的能力」之后。附加描述「集成的团队成员需要跨职能的培训、领导才能培训、人际关系技能培训，以及集成适当经营与技术功能所需技能的培训。针对潜在的广泛需求及需求提供者背景，可要求未参与需求开发的相关干系人参加产品设计专业领域之培训，以取得对于需求范围有全面性了解及需求间互动关系的承诺」。 3 试着合而为一既然已经向您介绍CMMI 模型的组件，你需要了解它们如何合而为一，以符合你的过程改进需要[Dymond 2004]。在本章中，我们介绍等级的概念与显示过程域如何被组织与使用。为了完成此目的，我们需要再回顾第一章一开始的讨论。了解等级 CMMI 使用等级，说明组织建议的演进途径，组织想要改进开发与维护产品与服务的过程。等级也是评估中评等活动的产出。评估可以在全公司（通常是小型）或是小群组中执行，小群组就像是项目群组或是公司内的一个部门。 CMMI 支持两种改进途径。一个途径是针对组织所选择的一个过程域（或多个过程域），使组织能够渐进地改进过程。另一个途径是组织渐进地解决连续的一组过程域，使组织改进一组相关的过程。这两种改进途径与第1章所探讨的两种表述使用的两种等级类型有关连。对于连续式表述，我们使用术语「能力度等级」。对于阶段式表述，我们使用术语「成熟度等级」。无论你选择哪一种表述，等级的概念都是相同的。等级描述改进从一个不清楚定义的状态到使用量化信息，决定与管理改进的状态，这个改进必须符合组织经营目标。为达到一个特定等级，组织必须满足过程域或一组过程域中所有适当的目标。无论是能力度等级或是成熟度等级，它们被当做改进的目标。这两种表述也提供执行过程改进的方法，以达到经营目标。这两种表述提出相同的必要内容与使用相同的模型组件。连续式与阶段式表述的结构图说明连续式与阶段式表述的结构。当你看到这两种表述的架构，对您而言立刻注意到其差异。阶段式表述使用成熟度等级，然而连续式表述使用能力度等级。图连续式与阶段式表述的结构在你比较这两种表述的相似性后，有什么是让你有印象的？这两种表述有许多相似的组件（例如：过程域、特定目标与特定实践），并且这些组件有相同的等级与结构。图从高层观点中有什么不容易立即看出的。是连续式表述专注在以能力度等级度量的过程域能力。而阶段式表述专注在以成熟度等级度量的组织成熟度。这些CMMI维度（能力度/成熟度）使用在标竿学习与评估活动，并且指导组织的改进工作。 • 能力度等级，属于连续式表述，应用于个别过程域的组织过程改进的达成。这些等级对一个过程域有递增地改进过程的方式。有六个能力度等级，编号为0到5。 • 成熟度等级，属于阶段式表述，应用于跨过程域的组织过程改进的达成。这些等级有预测下一个从事的项目的一般产出的方式。有五个成熟度等级，编号为1到5。表为六个能力度等级与五个成熟度等级的比较。你可以察觉到这两种表述中，有4个等级的名称是相同的。差异之处在于阶段式表述并没有成熟度第0级，而是以成熟度第1 级的名称为起始级。所以，这两种表述的开始点是不同的。表能力度与成熟度等级的比较等级连续式表述的能力度等级阶段式表述的成熟度等级等级 0 不完整级(Incomplete) 无(N/A) 等级 1 执行级(Performed) 初始级(Inital) 等级 2 管理级(Managed) 管理级(Managed) 等级 3 定义级(Defined) 定义级(Defined) 等级 4 量化管理级(Quantitatively Managed) 量化管理级(Quantitatively Managed) 等级 5 已优化级(Optimizing) 已优化级(Optimizing) 连续式表述关心选择特定的过程域进行改进，以及该过程域期望的能力度等级。在这个背景下，一个过程是否已执行或不完整是重要的。所以，名称「不完整」作为连续式表述的开始点。由于阶段式表述关心组织的整体成熟度，无论个别过程是已执行或不完整都不是主要焦点。所以，名称「初始」作为阶段式表述的开始点。能力度等级与成熟度等级两者均提供一个度量方式，以度量组织能够并实行改进他们的过程到多好。然而，过程改进的相关方法是不同的。了解能力度等级为支持使用连续式表述，所有的CMMI 模型在它们的设计与内容中反映能力度等级。能力度等级包含与过程域有关的通用目标及相关的通用实践，可以改进该过程域有关的组织过程。当您满足每一个能力度等级下的通用目标与其通用实践，您就能获得在那个过程域的过程改进效益。有六个能力度等级，标示由编号0 到编号5 如下： 0. 不完整级 1. 执行级 2. 管理级 3. 已定义级 4. 量化管理级 5. 已优化级事实上，能力度等级第2 级到第5级有意的使用与通用目标2 到5 相同的术语，因为每一个通用目标与实践反映你会实行的目标与实践之能力度等级的意义（通用目标与实践的更多信息，请参看通用目标与通用实践段落）。每一个能力度等级简短说明如下：能力度第0 级：不完整级「不完整过程」是一个没有执行或部分执行的过程。无法满足过程域的一个或多个特定目标，以及因为没有制度化部分执行过程的理由，这个等级没有通用目标。能力度第1 级：执行级能力度第1 级过程特征为「已执行过程」。已执行过程是满足过程域特定目标的过程，它支持并使所需工作能够产出工作产品。由能力度第1 级所导致的重大改进可能会随着时间而失去，因为它们没有被制度化。应用制度化（CMMI 能力度第2 级到第5 级的通用实践）可以确保维护改进。能力度第2 级：管理级能力度第2 级过程特征为「已管理过程」。已管理过程是一个已执行的过程(能力度第1 级)，具有基本的基础建设支持过程。它会根据方针策划与实施过程；任用具备技能的人员，并给予足够的资源以产出可控制的产品；纳入相关的干系人；监督、控制及审查；并评估遵循过程说明的程度。能力度第2 级所反映的过程规范，确保现有的实践能在有压力的情况下，仍维持运作。能力度第3 级：定义级能力度第3 级过程特征为「已定义过程」。已定义过程是一个已管理过程（能力度第2 级）。过程根据组织的定义指导定义组织标准过程，并纳入工作产品、度量与其它过程改进信息至组织过程资产。能力度第2级与第3级间的重要差异在标准、过程说明与程序的范围。在能力度第2级中，每一个过程特定案例(例如，特定项目)中标准、过程说明与程序可能颇有差异。能力度第3级，项目的标准、过程说明与程序由组织标准过程定义而得，以符合特定项目或组织单位。所以，除了定义指导允许的差异外，因而更具一致性。其它能力度第3 级的重要差异是，过程通常说明的比能力度第2 级还要严谨。一个已定义过程清楚地说明目的、输入、入口准则、活动、角色、度量、验证步骤、输出，出口准则。在能力度第3 级中，通过了解过程活动之互动关系及过程、工作产品与服务的详细度量，能够更主动的管理过程。能力度第4 级：量化管理级能力度第4级过程特征为「已量化管理过程」。已量化管理过程是一个已定义过程(能力度第3级)，使用适当的统计和其它量化的技术进行控制。建立质量和过程绩效的量化目标，并以该目标为管理过程的准则。以统计的术语了解质量和过程绩效，并在过程生命周期受到管理。能力度第5 级：已优化级能力度第5级过程特征为「已优化过程」。已优化过程是一个已量化管理过程(能力度第4级)，利用了解过程中的共同变异原因，改进过程。已优化过程以渐进与创新的改进，专注于持续改进过程绩效。记住，能力度第2级到第5级使用相同的通用目标2到5的术语，这些术语的详细说明，显示在通用目标与通用实践段落。能力度等级的进展过程域能力度等级的达成，是凭借通用实践或在过程域中相关过程的适当替代方案的应用。达到一个过程域之能力度第1级，等同于说该过程域相关的过程是「已执行过程」。达到一个过程域之能力度第2 级，等同于说有方针可以指出你会执行这个过程。有执行计划、提供资源、分配责任、执行培训、控制执行过程相关的所选择的工作产品等等。换句话说，一个能力度第2级的过程是有规划与监督的，就像任何项目或支持活动一样。达到一个过程域的能力度第3级，即认为有一个组织标准过程存在于过程域中，并且可以根据项目需要定义。因为它们根据组织标准过程定义，所以组织过程更具一致性的定义与应用。达到一个过程域的能力度第4级，即认为这个过程域是一个关键的经营驱力，此驱力是组织想要使用量化与统计技术执行管理。这个分析使组织对所选择的子过程的绩效更加透明，使组织在市场上更有竞争力。达到一个过程域的能力度第5 级，即认为你所选择的子过程稳定，并且你想要降低过程的共同变异原因。记住，变异在任何过程中是自然发生的，因此虽然改进所有过程在概念上是可行的，但是将所有过程都改进至第5级是不经济的。再说一次，你将专注于那些会参考你，符合你经营目标的过程。了解成熟度等级为支持使用阶段表述，所有的CMMI 模型在其设计与内容中反映成熟度等级。成熟度等级包含预先定义的一组过程域与相关的特定与通用实践，以改进组织整体绩效。组织的成熟度等级提供一个方式，在一个项目领域或是一组项目领域下，预测组织绩效。当组织过程改进工作专注于可管理数目的过程域，而且组织改进逐渐增加那些领域的熟练度，经验显示组织会做到最好。成熟度等级在组织过程改进中是一个已定义的演进水平。每一个成熟度等级会使一个重要的组织过程子集合变得成熟，为提升到下一个成熟度做准备。凭借达成度量成熟度等级预先定义的一组过程域中特定与通用目标。有五个成熟度等级，每一个等级都是进行下一个等级的基础，标示由编号1 到5： 1. 初始级 2. 管理级 3. 定义级 4. 量化管理级 5. 已优化级记住，成熟度第2级到第5级使用相同术语，如同能力度第2 到第5 级。这是有其目的的，因为成熟度等级与能力度等级的概念是互补的。成熟度等级的使用特征为一组相关过程域的组织改进，而能力度等级特征为个别过程域的组织改进。成熟度第1 级：初始级在成熟度第1 级中，过程通常是混乱的。组织通常没有提供稳定的环境维持过程。这些组织的成功，往往依赖组织成员的能力与英雄主义，而不是使用一套经过证实的过程。除了混乱的环境之外，成熟度第1级的组织也经常可产生会运作的产品和服务；不过它们经常会超过项目的预算且不符合进度。成熟度第1级组织的特征为过度承诺的倾向、在紧急关头放弃过程，以及没有能力复制成功经验。成熟度第2 级：管理级成熟度第2 级中，可确保组织的项目是按照方针策划与实施过程；项目雇用具备技能的人员，并给予足够的资源，产出可控制的产品；纳入相关的干系人；监督、控制与审查；以及评估遵循过程说明的程度。成熟度第2级所反映的过程规范，可提供帮助以确保现有的实践在有压力的情况下，仍维持运作。在这些实践实行时，项目依计划执行和管理。成熟度第2级，工作产品的状况及服务的交付情形，在已定义的时间点（例如：重要里程碑及重要任务完成）是可以透明管理的。承诺是由相关的干系人所建立，并视需求修订。适当的控制工作产品。工作产品和服务满足其特定的过程说明、标准及程序。成熟度第3 级：已定义级成熟度第3 级，过程被适当地描述特征与了解，并以标准、程序、工具与方法说明。建立与改进组织标准过程，是成熟度第3级的基础。标准过程被使用来确保跨组织的一致性。项目根据定义指导，定义组织标准过程，以建立它们的定义过程。（参考组织标准过程的词汇定义）。成熟度第2级与第3级间的重要差异在标准、过程说明与程序的范围。在成熟度第2级中，每一个过程案例（例如；特定项目）中标准、过程说明与程序可能有很大的差异。成熟度第3级中除了定义指导允许的差异外，项目的标准、过程说明与程序由组织标准过程定义而得，以符合特定项目或组织单位，因而过程更具一致性。其它成熟度第3 级的重要差异是，过程通常说明得比成熟度第2 级还要严谨。一个已定义过程清楚地说明目的、输入、入口准则、活动、角色、度量、验证步骤、输出，出口准则。在成熟度第3 级中，过程通过了解过程活动的互动关系及工作产品与服务的过程详细度量，以更主动的管理过程。成熟度第3级中，组织必须使成熟度第2级的过程域变得更成熟。成熟度第2级未处理的属于通用目标3 的通用实践，可应用于达成成熟度第3级。成熟度第4 级：量化管理级成熟度第4级，组织与项目针对质量与过程绩效建立量化目标，并使用它们当做管理过程的准则。量化目标是基于客户、最终使用者、组织与过程执行者的需要。以统计的术语了解质量与过程绩效，并在过程生命周期受到管理[SEI 2001]。对所选择的子过程，收集与统计分析过程绩效的详细度量。质量与过程绩效度量值被合并到组织度量资产库，以支持以事实为基础的决策 [McGarry 2000]。适当地定义过程变异的特殊原因，修正特殊原因的源头，以预防下次发生。（请参考过程变异的特殊原因的词汇定义）。成熟度第3 级与第4 级的重要差异在过程绩效的可预测性。在成熟度第4 级中，过程绩效使用统计与其它量化技术控制及量化预测。成熟度第3 级中，过程通常仅量化预测。成熟度第5 级：已优化级成熟度第5级，组织根据过程变异共同原因的量化了解，持续改进它的过程。（参考过程变异的共同原因的词汇定义）。成熟度第5级通过渐增与创新过程及技术改进，专注于持续改进过程绩效。建立组织量化过程改进目标，且持续修改以反映经营目标的变动，以及用作管理过程改进的准则。依量化过程改进目标，度量与评估部署过程改进的影响。已定义过程与组织标准过程是可度量的改进活动目标。成熟度第4级与第5级的重要差异在所解决的过程变异类型。在成熟度第4级中，组织关心解决过程变异的特殊原因，以及提供结果的统计预测。虽然过程可能产出可预测的结果，然而这个结果可能不足以达成所建立的目标。在成熟度第5级中，组织关心过程变异的共同原因，以及变更过程（转移过程绩效的平均值或降低内在有经验的过程变异），以改进过程绩效，并且达成已建立的量化过程改进目标。成熟度等级的进展组织可以逐渐达成组织成熟度的改进。先由项目等级达成，持续到较高等级(整个组织等级的持续性过程改进)，使用定量和定性数据做决策。既然已改进的组织成熟度与一个组织可以达到的预期结果的改进范围有关，它也是预测组织下一个项目一般结果的一个方法。例如：在成熟度第2级，组织通过建立良好的项目管理过程，已由无特定章法提升到有制度可循。当组织达成所设定的成熟度等级中所有过程域的一般及特定实践时，就提升了组织成熟度，并获得过程改进的好处。因为每一成熟度等级都是下一个等级的基础，尝试略过某一个成熟度，通常会有反效果。同时，你必须了解过程改进的工作应该专注于组织经营环境的需要，在较高成熟度等级的过程域可能解决组织或项目的目前需要。例如：寻求自成熟度第1级升级到成熟度第2 级的组织，通常被建议成立一个过程组，但是此过程组却是属于成熟度第3级的「组织过程焦点过程域」才会说明的内容。虽然过程组并不是组织成熟度第2级组织的必要特征，但是过程组可以是一个有效方法，以帮助组织达到成熟度第二级。这种情况有时候称为「建立成熟度第1 级的工程过程组，以带动组织到成熟度第2级」。成熟度第1 级的过程改进活动可能主要依赖过程团队成员的洞察力和能力，一直到拥有支持较专业及广泛改进的基础建设。组织可以在任何时间着手于特定的过程改进，甚至在准备进入成熟度等级所建议的特定实践之前即可着手。然而在这些情况下，组织应该了解到这些改进的成功是有风险的，因为能让这些改进成功的基础并未建置完成。面对压力时，缺乏适当基础的过程可能会在最需要它的时候失败。倘若缺乏成熟度第2级管理阶层的实践，即已定义过程，这是成熟度第3级组织的特征，就可能会发生问题。例如：管理阶层可能会承诺一个未经妥善规划的进度，或是无法控制基线需求的变更。同样地，许多组织收集了成熟度第4级所需详细的数据，却因为过程与度量定义的不一致，而无法诠释这些数据。另一使用较高成熟度等级过程域所属过程的例子为构建产品的过程。当然，我们期望成熟度第1级的组织，会执行需求分析、设计、集成及验证等活动。不过这些活动到成熟度第3级时才会描述。在成熟度第3 级，会以连贯且集成良好的工程过程来描述这些活动。工程过程补足项目管理能力，可将相关活动就定位，使工程改进不致于因混乱的管理过程而迷失。过程域两种表述针对过程域的观点是不同的。图比较过程域如何使用在连续式与阶段式表述中的观点。图连续式与阶段式表述的过程域连续式表述使组织能够选择那些过程域或是一组有互相关连的过程域，选择过程改进努力的专注以为组织及其经营目标带来最大利益。虽然因为过程域间的相依性，使得组织在选择上有一些限制，但是组织仍然有相当多的自由选择。为支持使用连续式表述，过程域组织成4种类型：过程管理、项目管理、工程与支持。这些类型强调过程域间存在的关系，并且讨论于第四章。当你选择过程域时，你也必须选择在这些过程域中过程需要成为多少成熟度（例如：选择适当的能力度等级）。能力度等级与通用目标及实践支持个别过程域相关的过程改进。举例来说，一个组织可能希望努力于某个过程域达到能力度第2级，以及在另一个过程域达到能力度第4 级。当一个组织达到一个能力度等级时，它将这些相同过程域中的一个设为下一个能力度等级的目标，或是决定扩大视野及解决更大数量的过程域。这个选择一般以目标摘要来说明。目标摘要是用来定义所有必须要解决的过程域及其每一个目标能力度等级，然后这个摘要会影响有哪一些目标与实践，组织将在过程改进工作中解决。大多数组织在最低情况下会将能力度第一级当做目标，它要求过程域的所有特定目标均需达成。所以，将高于能力度第一级当做目标的组织，会专注于组织内所选择过程的制度化，实行相关的通用目标与实践。相反地，你将会看到阶段式表述鼓励你，注意成熟度等级所属的过程域。过程域被成熟度等级所组织，以强化这个概念。阶段式表述提供由成熟度第1级到第5级之预先定义的改进路径，包含达成每一个成熟度等级过程域之目标。为了支持阶段式表述，过程域群组成成熟度等级，指出实行哪些过程域以达成每一个成熟度等级。例如，成熟度第2级中，有一组过程域是组织要用来指导它们过程改进的，直到达成所有过程域的目标。一旦达成成熟度第2级，组织会专注于成熟度第3 级的过程域等等。每一个过程域的通用目标也是预先定义的。通用目标2应用在成熟度第2级，而通用目标3 应用于成熟度3-5级。表提供所有过程域的清单与其相关的类别及成熟度等级。为了解释过程域组件如何被呈现在每一个表述下，我们必须讨论表述如何解决特定实践。表过程域与其相关的类别及成熟度等级过程域类别成熟度等级原因分析与解决方案支持 5 配置管理支持 2 决策分析与解决方案支持 3 集成项目管理+IPPD 项目管理 3 度量与分析支持 2 组织创新与部署过程管理 5 组织过程定义+IPPD 过程管理 3 组织过程焦点过程管理 3 组织过程绩效过程管理 4 组织培训过程管理 3 产品集成工程 3 项目监控项目管理 2 项目策划项目管理 2 过程与产品质量保证支持 2 量化项目管理项目管理 4 需求开发工程 3 需求管理工程 2 风险管理项目管理 3 供应商协议管理项目管理 2 技术解决方案工程 3 确认工程 3 验证工程 3 通用目标与实践通用目标是必要的组件，应用于所有过程域。图说明通用目标与通用实践。所有的通用目标与实践都会在连续式表述中使用。（通用目标与实践的更详细说明，请参考通用目标与通用实践章节）。在你改进的工作中，你设定为目标的能力度等级，将决定哪些通用目标与实践，将应用到你所选择的过程域。图 : 通用目标与通用实践在阶段式表述中，只使用通用目标2 与3，说明在图中灰色部分所强调的通用实践。当你试着达到成熟度第2 级，你使用成熟度第2 级的过程域，以及使用通用目标2 与其通用实践。注意，不使用通用目标4 与5 以及它们相关的实践，是因为并不是所有过程都要被「提升」到已定义过程之上。只有选择的过程与子过程将会量化管理与已优化，哪些选择的过程与子过程解决成熟度第4 与第5 级的过程域。当你达到成熟度第3 级、第4 级与第5 级，你适当的使用成熟度等级的过程域，以及使用较低成熟度等级的过程域。此外，通用目标3 与其相关的通用实践（包含通用目标2 与其相关的通用实践），应用到这些所有过程域。这个意思是即使你已经达到成熟度第2 级评等，为了达到成熟度第3 级评等，你必须回到成熟度第2 级的过程域，并且同样地应用通用目标3 与其相关的通用实践。表述比较表汇总两种表述的差异。表比较连续式与阶段式表述连续式表述阶段式表述组织依据其过程改进目标，选择过程域与能力度等级。组织依据成熟度等级，选择过程域。使用能力度等级度量改进。能力度等级： • 度量跨组织的特定过程域的能力度。 • 等级从0 到5。使用成熟度等级度量改进。成熟度等级： •度量跨组织的一组过程域成熟度。 •等级从1 到5。能力度等级摘要当做目标与追踪过程改进绩效。成熟度等级当做目标与追踪过程改进绩效。对等的阶段式允许一个组织使用连续式表述进行过程改进并引申成熟度等级以当做评估的一部分。并不需要一个对等的机制来反推连续式表述。对等的阶段式对等的阶段式是一个比较使用连续式表述与阶段式表述之结果的方式。在本质上，假如你在连续式表述中使用能力度等级度量所选择过程域相关的改进，你如何将它与成熟度等级做比较呢？这有可能吗？到目前为止，我们没有讨论详细的过程评估。 SCAMPISM 方法用来评估使用CMMI的组织，其中一项评估结果是评等 [Ahern 2005]。假如评估使用连续式表述，评等就是能力度等级摘要。假如评估使用阶段式表述，评等就是成熟度等级（例如：成熟度等级3）。能力度等级摘要是过程域清单，以反映每一个过程域达成的能力度等级。这个摘要使组织能够追踪其过程域的能力度等级。当它呈现组织每一个过程域的实际进展时，这个摘要是一个达成摘要。或者，当它呈现组织的已规划过程改进目标，这个摘要是一个目标摘要。图说明目标摘要与达成摘要。每一个长方条灰色的地带呈现已经达成的。未遮蔽的部分呈现有待完成的，以符合目标摘要。图达成摘要与目标摘要的例子达成摘要与目标摘要的比较，使组织能够规划与追踪每一个所选择的过程域的进展。当使用连续式表述时，维护能力度等级摘要是明智的。目标阶段是一个循序的目标摘要，以说明组织要遵循的过程改进路径。当建立目标摘要时，组织应该专注通用实践与过程域的从属关系。假如有通用实践依赖某个过程域，当该过程域未实行时9，无论执行通用实践或是提供必要产品，通用实践可能会比较没有效果。虽然有许多理由使用连续式表述，但是能力度等级摘要所提供的评等能力，对于提供组织一个一般性的方式与其它组织进行比较是有限的。如果每一个组织选择相同过程域，能力度等级摘要可能会有用。然而，成熟度等级可以用于每一年组织比较，而且已经提供一组预先定义的过程域。因应这个情况，建立对等的阶段式。对等的阶段式组织能够使用连续式表述的评估，以转换能力度等级摘要到相关的成熟度等级的评等。更有效用来描述对等的阶段式的方式，是提供一个连续的目标摘要，每一个都是对等于阶段式表述中的成熟度等级评等。这个结果是目标阶段，它对等于阶段式表述的成熟度等级。图显示当使用连续式表述来对等于成熟度等级的第2 级到第5 级之必须达成的目标摘要一览。每一个能力度等级字段遮蔽的区域呈现对等于成熟度等级的目标摘要 Name Abbr ML CL1 CL2 CL3 CL4 CL5 Requirements Management REQM 2 Target Profile 2 Project Planning PP 2 Project Monitoring and Control PMC 2 Supplier Agreement Management SAM 2 Measurement and Analysis MA 2 Process and Product Quality Assurance PPQA 2 Configuration Management CM 2 Requirements Development RD 3 Technical Solution TS 3 Product Integration PI 3 Verification VER 3 Validation VAL 3 Target Profile 3 Organizational Process Focus OPF 3 Organizational Process Definition +IPPD OPD +IPPD 3 Organizational Training OT 3 Integrated Project Management +IPPD IPM +IPPD 3 Risk Management RSKM 3 Decision Analysis and Resolution DAR 3 Organizational Process Performance OPP 4 Target Profile 4 Quantitative Project Management QPM 4 Organizational Innovation and Deployment OID 5 Target Profile 5 Causal Analysis and Resolution CAR 5 图目标摘要与对等的阶段式以下概述对等的阶段式规则： • 达成成熟度第2 级，所有成熟度第2 级指定的过程域，必须达到或高于能力度第2 级。 • 达成成熟度第3 级，所有成熟度第2 与第3 级指定的过程域，必须达到或高于能力度第3 级。 • 达成成熟度第4 级，所有成熟度第2、第3 与第4 级指定的过程域，必须达到或高于能力度第3 级。 • 达成成熟度第5 级，所有过程域，必须达到或高于能力度第3 级。这些对等的阶段式的规则与表格是完整的。但是你可能会问为什么目标摘要4 及5 没有扩展至CL4 与CL5。这个理由是成熟度第4 级的过程域，说明选择的子过程已稳定为基础，组织与项目的质量和过程绩效目标在某种程度上。不是每一个过程域，都会被选择进行处理，以及CMMI 并没有预先假设哪一些过程域，会被选择进行处理。所以，一个过程域之能力度第4 级的达到无法预先决定，因为这个选择依赖组织中成熟度第4 级之过程域的实行。所以，图并没有显示目标摘要4 扩展至CL4，即使有些过程域会达到能力度第4 级。成熟度第5 级的情况与目标摘要5 是相似的。对等的阶段式之存在，不应该阻止连续式表述的使用者，建立扩展至能力度第3 级以上的目标摘要。该目标摘要在某种程度上，由组织的选择所决定，以符合组织经营目标。 4 过程域间的关系在这一章节中，我们说明过程域间的互动关系，以参考你理解过程改进的组织观点，以及哪些过程域建立在其它过程域的实行。用两个维度来呈现过程域间的关系。第一个维度包含个别过程域的互动关系，显示信息与成果如何由一个过程域流到另一个过程域，这一章节使用多个图形与说明，这些互动关系参考你理解过程域改进的广泛观点。第二个维度包含过程域类的互动关系。有一些过程域被分类为基本，而其它分类为进阶。这些分类说明基本过程域的实行应该早于进阶过程域，以确保符合成功实行进阶过程域的必要条件。过程改进成功的起始必须由组织经营目标所驱动，举例而言，一个典型的经营目标是降低产品推出市场所需要的时间。这个经营目标驱动过程改进目标可能是改进项目管理过程以确保如期交付，这些改进依赖项目策划与项目监控过程域中的最佳实践。 CMMI 过程域的四种类别过程域可分成下列四类： • 过程管理 • 项目管理 • 工程 • 支持虽然我们将过程域分成上述四类，以讨论其间的互动。然而不论它们如何归类，过程域间常有互动，且彼此相互影响。例如：决策分析与解决方案过程域中提供解决正式评估的特定实践，该评估会使用于技术解决方案过程域，以便从备选方案中选定技术解决方案。技术解决方案过程域归类在工程类过程域，而决策分析与解决方案过程域归类在支持类过程域。了解CMMI 模型过程域间的互动，以及哪些是属于基本或是进阶的过程域，将会参考你用有益与有生产力的方式应用CMMI。以下各节说明各类别内过程域间的互动关系，以及简略的说明过程域与其它类别过程域的互动关系。不同类别的过程域间的互动关系，说明在第二单元各过程域的相关过程域的参考数据，参见第二章可以得到更多关于参考数据的信息。过程管理过程管理类过程域涵盖有关定义、规划、部署、实行、监督、控制、评估、度量及过程改进的跨项目的各种活动。 CMMI 的过程管理类过程域，包括下列内容： • 组织过程焦点 • 组织过程定义+IPPD • 组织培训 • 组织过程绩效 • 组织创新与部署基本过程管理类过程域基本过程管理类过程域提供组织能力，以记录与分享最佳实践、组织过程资产，以及跨组织的学习。图提供基本过程管理类过程域之间，以及与其它过程域类间互动关系的鸟瞰图。如图所示，基于对组织过程和过程资产的现况优点和缺点之了解，组织过程焦点过程域帮助组织规划、实行及部署组织过程改进。图基本过程管理类过程域可由多种方法得到备选的组织过程改进方案。这些方法包括过程改进建议书、过程的度量、实行过程时的学习心得，以及过程评估和产品评估活动的结果。基于组织过程需要与组织目标，组织过程定义过程域建立与维护组织标准过程、工作环境标准及其它资产。其它资产包括生命周期模型的说明、过程定义指导及与过程相关的文档及数据。项目定义组织标准过程以产生已定义过程，而其它资产则用以支持该已定义过程的定义和实行。执行该已定义过程的经验与工作产品，包括度量数据、过程说明、过程成果及学习心得，将适当的集成至组织标准过程和其它资产中。在附加IPPD 的部分，组织过程定义+IPPD 提供针对项目的IPPD 规则与指导。组织培训过程域识别组织的策略培训需要和实务培训需要，这些培训通常是整个项目和支持团队的共同需要。尤其是开发执行组织标准过程所需技能的开发和取得培训。培训的主要项目包括：有管理的培训开发计划、文档化的计划、具有适当知识的人员，以及度量培训计划成效的机制。进阶过程管理类过程域进阶过程管理类过程域使组织具备进阶的能力，以达成其质量与过程绩效的量化目标。图是进阶过程管理类过程域之间及与其它过程域类间互动关系的鸟瞰图。每一进阶过程管理类过程域取决于开发与部署过程及支持资产的能力，而基本过程管理类过程域提供这能力。图进阶过程管理类过程域如图所示，组织过程绩效过程域，由组织经营目标导引出质量与过程绩效的量化目标。组织提供项目和支持团队共同的度量、过程绩效基线及过程绩效模型。这些额外的组织资产对项目和支持团队支持关键子过程的量化项目管理和统计管理。组织分析其已定义过程所收集的过程绩效数据，以开发对产品质量、服务质量及组织标准过程的过程绩效的量化了解。组织创新与部署过程域，选择与部署所建议的渐进和创新改进方案，改进组织能力，以符合其质量和过程绩效目标。配合组织经营价值与目标，经授权的团队参与有希望的渐进和创新改进方案的识别。必须以部署该备选改进方案的可能效益与可预见成本，以及可用于部署的资金等量化的理解为基础，选择部署改进方案。项目管理项目管理类过程域，包含与项目的规划、监督及控制有关的项目管理活动。 CMMI 的项目管理类过程域，包括下列内容： • 项目策划 • 项目监控 • 供应商协议管理 • 集成的项目管理+IPPD • 风险管理 • 量化项目管理基本项目管理过程域基本项目管理过程域解决有关建立与维护项目计划、建立与维护承诺、依计划监督进展、采取改进活动与管理供应商协议。图提供基本项目管理类过程域之间，以及与其它过程域类间互动关系的鸟瞰图。如图所示，项目策划过程域包括开发项目计划、适当地纳入干系人的参与、取得对计划的承诺，以及维护计划。当使用IPPD 时，干系人代表的意义不只是产品与过程开发的技术专家，同时也是产品与过程开发的经营密切关系人。图基本项目管理类过程域规划由需求开始，定义产品与项目的需求(即图中的「建造什么」)。项目计划包含项目所执行的各种项目管理和开发活动。项目审查对项目造成影响的其它计划，这些计划来自许多相关的干系人，并建立这些相关的干系人对项目贡献的承诺。举例而言，这些计划包含配置管理、验证及度量与分析。项目监控过程域，包括监督活动和采取纠正行动。项目计划指明项目监督的适当等级、进度审查频率及用以监督进度的度量。进度主要由实际进度和计划进度的比较来决定。当实际的状况和期望的数值有明显差异时，应采取适当的纠正行动。这些行动可能包括重新进行规划。供应商协议管理过程域，解决取得由供应商执行工作部分的项目需要。积极识别满足项目需求的产品来源。选择供应商与建立供应商协议，以管理供应商。藉由监督所选择的工作产品与过程，追踪供应商的进展与绩效，适当地修订供应商协议。执行验收审查与测试供应商所生产的产品组件。进阶项目管理类过程域进阶项目管理类过程域，解决包括：定义组织标准过程以建立项目的已定义过程的活动、从组织的工作环境标准制定项目工作环境、与相关干系人(包括供应商)协调与合作、管理风险、组成与维持执行项目的集成团队，以及量化管理项目的已定义过程。图提供进阶项目管理类过程域之间，以及与其它过程域类间互动关系的鸟瞰图。每一进阶项目管理类过程域，决定于项目策划、监督及控制的能力，而基本项目管理类过程域提供这能力。图进阶项目管理类过程管理集成的项目管理过程域建立与维护由组织标准过程所定义的项目已定义过程，项目使用该过程以管理项目。项目使用组织过程资产，并贡献结果到组织过程资产中。项目工作环境由组织工作环境标准所建立与维护。项目的管理确保与项目有关的干系人可适时的协调合作。为达此目的必须进行：提供干系人参与的管理；重要相依项目的识别、协商及追踪；以及与有关的干系人协商项目问题的解决方案。在附加IPPD 的部分，集成的项目管理+IPPD 建立与维护项目的共同愿景与项目的集成团队结构。然后建立集成团队来执行项目工作，确保适当的跨团队合作。虽然在项目策划和项目监控过程域已包含风险的识别与监督，但风险管理过程域采取持续性和前瞻性的管理风险方法，这些活动包括风险参数的识别、风险评价及风险降低。量化项目管理过程域，应用量化和统计的技术，以管理过程绩效和产品质量。项目的质量和过程绩效的目标是建立在组织的目标上。项目的已定义过程包含过程组件和子过程，其过程绩效是可以预测的。至少达成项目质量和过程绩效目标的重要子过程所经验的过程变异是可以理解的。当识别出过程变异的特殊原因时，应采取纠正行动（参见词汇表中过程变异的特殊原因之定义）。工程工程类过程域，包含所有工程专业领域皆可共享的开发活动和维护活动。工程类过程域使用一般工程术语所撰写，所以任何技术专业领域有关的产品开发过程（例如：软件工程或机械工程），都可以使用它们进行过程改进。工程类过程域也将不同工程专业领域的过程，集成成单一的产品开发过程，以支持产品导向过程改进策略。这种策略是以基本的经营目标为对象而非特定的技术专业领域。这个作法可使过程有效的避免趋向组织的「高烟囱(难以沟通)」心态。工程类过程域应用于开发领域(例如：软件产品、硬件产品、服务或过程)中，任何产品或服务的开发。 IPPD 的技术基础，建立于健全的系统工程方法上，此方法包含产品生命周期阶段的开发。工程类过程域提供这个技术基础。因而IPPD 的实行，对工程类过程域的特定实践有强化作用，特别强调同步开发和专注于产品生命周期的所有阶段。 CMMI 的工程类过程域，包括下列内容： • 需求开发 • 需求管理 • 技术解决方案 • 产品集成 • 验证 • 确认图提供六个工程过程域之间互动关系的鸟瞰图图工程类过程域需求开发过程域识别客户需要，并将其转换为产品需求。分析产品需求，以产生高层的、概念性的解决方案。然后将产品需求加以配置，以建立初始的产品组件需求。同时衍生其它有助于定义产品的需求(即衍生需求)，并将其配置到产品组件中。产品和产品组件需求，应以开发者所了解和使用的用语，清楚的说明产品绩效、设计特色、验证需求等。需求开发过程域提出对技术解决方案过程域的需求，而在技术解决方案过程域将需求转换为产品架构、产品组件设计及产品组件本身(例如：程序制作及制造)。需求开发过程域也提出对产品集成过程域的需求，而在产品集成过程域会将产品组件加以组合，并验证其接口确保接口符合需求开发所提的接口需求。需求管理过程域的重点在于维护需求，此过程域说明取得需求和控制需求变更的活动，确保其它的相关计划和数据保持在最新状况，并提供由客户到产品，以及到产品组件的需求追溯性。需求管理确保需求变更已反映于项目计划、活动及工作产品中。变更的周期可能影响到其它的工程类过程域，所以需求管理是动态的，并常常递归于事件发生的顺序。需求管理过程域是有控制和有纪律的工程设计过程的基础。技术解决方案过程域，开发产品组件的技术相关数据，以供产品集成过程域或供应商协议管理过程域使用。使用想要选择出已优化设计所建立的准则，检查备选方案。这些准则因产品而有明显的差异，取决于产品的类别、操作环境、绩效需求、支持需求，以及成本或交付进度。选择最终解决方案的任务，会利用决策分析与解决方案过程域的特定实践。技术解决方案过程域引用验证过程域的特定实践，在设计期间和最终产品建造之前，执行设计验证和同行评审。验证过程域确保所选定的工作产品，符合其特定的需求。验证过程域选择工作产品和验证方法，以验证工作产品是否符合其特定的需求。验证通常是渐进式的过程，由产品组件开始验证，最后是完全组合的产品的验证。验证也强调同行评审。同行评审是经证实的方法，可在产品开发与维护时及早移除缺陷，并对开发与维护中的工作产品和产品组件，提供有用和深入的了解。确认过程域逐步地确认产品是否符合客户需要。确认可以在操作环境或模拟的操作环境执行，与客户协调「确认的需求」是这个过程域的重要组件。确认过程域的范围，包括产品、产品组件、经选定的中间工作产品及过程的确认。这些需要确认的元素可能时常需要再次验证和再次确认。在确认时所发现的问题，通常在需求开发或技术解决方案过程域中解决。产品集成过程域包含产生可能的最佳集成顺序、集成产品组件，以及交付产品给客户有关的特定实践。在实行产品集成过程时，产品集成过程域使用验证和确认的特定实践。在产品集成前，验证过程验证接口及产品组件间的接口需求是否相符，是集成过程的必要项目。在操作环境进行产品集成时，使用确认过程域的特定实践。工程类过程域的递归与反复许多过程标准都同意，有两种可以应用过程的方式。这两种方式称为递归与反复。递归发生在系统结构中，一个过程应用于系统元素的连续层次。一个应用的产出，被使用来作为在系统结构中另一个等级的输入。例如：确认过程设计应用于整体组合产品、主要产品组件，以及组件之组件。你应用确认过程于产品多久，完全取决于产品的规模与复杂度而定。反复发生在同一个系统层次的过程重做。一个过程的实行产生新的信息并反馈到其它相关过程。这个新的信息一般会升高一些问题，而这些问题必须在结束过程前解决。举例而言，大多数的反复可能发生在需求开发与技术解决方案间。过程的重复应用可以解决升高的问题，反复可以确保在应用下一个过程前的质量。工程类过程域（例如需求开发或是验证）会针对一个产品反复实行，以确保在交付产品到客户前，这些工程类过程域已充分地满足。而且，工程类过程域可以应用于产品组件，举例而言，有一些在验证与确认过程域中的过程所引起的问题，可以在需求开发或产品集成过程域中的过程解决。这些过程域的递归与反复，使项目在交付产品到客户前，可以确保所有产品组件的质量。支持支持类过程域包含支持产品开发与维护的活动。支持类过程域所解决的过程，在执行其它过程时会使用。一般而言，支持类过程域解决的过程以项目为对象，而针对组织时，会以比较通用的方式解决过程。例如：所有的过程域都会使用「过程与产品质量保证」，以提供所有过程域的过程和工作产品的客观评估。 CMMI 的支持类过程域，包括下列内容： • 配置管理 • 过程与产品质量保证 • 度量与分析 • 决策分析与解决方案 • 原因分析与解决方案基本支持类过程域基本支持类过程域，解决所有的过程域都会使用的基本支持功能。虽然所有支持类过程域依赖其它过程域的输入，基本支持类过程域提供参考实行几个通用实践的支持功能。图提供基本支持类过程域之间，以及与其它类过程域间互动关系的鸟瞰图图基本支持类过程域度量与分析过程域提供特定实践，以支持所有的过程域。该特定实践以度量方法，引导项目与组织调整度量需要与目标。该度量方法提供客观的结果，可使用于作有根据的决策，并采取适当的纠正行动。过程与产品质量保证过程域提供特定实践，以支持所有的过程域。该特定实践，依据过程说明、标准及程序，客观地评估所执行的过程、工作产品及服务，并确保解决审查所发现的任何问题。藉由提供项目人员和各等级管理者，对项目生命周期中的过程与相关工作产品之适当的可见度及反馈，过程与产品质量保证过程域可支持高质量产品与服务的交付。配置管理过程域使用配置识别、配置控制、配置状态纪录及配置审计，建立与维护工作产品的完整性，支持所有的过程域。纳入配置管理的工作产品，包括交付客户的产品、指定的内部工作产品、采购的产品、工具，以及用来产生与说明这些工作产品的其它项目。工作产品可能纳入配置管理的例子包括：计划、过程说明、需求、设计数据、图表、产品规格、程序代码、编译码、产品数据文档，以及产品技术的出版品。进阶支持类过程域进阶支持类过程域提供项目与组织改进过的支持能力。每一个进阶支持类过程域依赖其它过程域的特定输入或实践。图提供进阶支持类过程域间，以及与其它过程域间互动关系的鸟瞰图图进阶支持类过程域利用原因分析与解决方案过程域，项目成员识别被挑选出来的缺陷之原因及其它问题，并且采取行动以预防它们在未来发生。当项目已定义过程是识别缺陷原因的主要目标时，他们针对组织标准过程，提出过程改进提案，全组织将防止缺陷再发生。决策分析与解决方案过程域支持所有过程域，决定哪一个问题应该要进行正式评估过程，并针对它们实行一个正式评估过程。 5 使用CMMI 模型现今产品的复杂度要求组织如何用一个集成观点从事经营。企业利用多个部门或群组产出产品与服务，CMMI 可以降低跨企业的过程改进成本。为了达到集成的观点，CMMI 架构包含一般术语、一般模型组件、一般评估方法与一般培训工具。这个章节说明组织如何使用CMMI 产品系列，改进它们的质量、降低它们的成本及已优化它们的编程，除此之外判断它们的过程改进计划的工作满意程度。采用能力成熟度集成模型研究显示对于过程改进起步最有影响的，是通过有力高层管理者的赞助，建立强大的组织支持。为了得到有力高层管理者的赞助，让高层管理者发觉别人使用CMMI 进行过程改进的绩效结果是很有参考的。有关于CMMI 绩效结果的进一步信息，请参考SEI 网站： [SEI 3]。高层管理者一旦承诺成为过程改进赞助者，就必须主动参与以能力成熟度集成模型为基础的过程改进工作。高层管理赞助者的执行活动包含（但是没有限制）以下： • 影响组织采用CMMI。 • 选择最佳的人员来管理过程改进工作。 • 亲自监控过程改进工作。 • 成为过程改进工作显而易见的提倡者与发言人。 • 确保提供足够的资源使得过程改进的努力能够成功在充分的高层管理者赞助后，下一步骤为建立一个强大、技术上能胜任的过程组，此过程组代表相关的干系人，以指导过程改进工作。对于开发软件密集系统为任务的组织，过程组可能包含代表跨组织中不同专业领域的工程师，以及其它根据经营需求被选择来促进改进的成员。举例来说，系统管理者可能会专注于信息科技的支持，然而销售代表可能专注于集成客户的需要。这两种成员可能会对过程组有很大的贡献。一旦你的组织决定采用CMMI，规划可以由一个改进方法开始，例如IDEALSM(初始、诊断、建立、行动与学习)模型。有关于IDEAL 模型的进一步信息，请参考SEI 网站： ideal/ [SEI 1] 你的过程改进计划使用CMMI 产品系列，帮助建立你的组织过程改进计划。针对这个目的使用CMMI 产品系列可以是相当非正式过程，涉及了解与应用CMMI 最佳实务于组织中，或者，它可以是一个需要广泛培训、建立过程改进基础建设、评估等的正式过程。影响你计划的选择应用CMMI 到你组织的过程改进，你必须做出三个选择： 1. 选择组织的单位 2. 选择模型 3. 选择表述选择要纳入你的过程改进计划中的项目是重要的。如果你选择的群组过大，可能会使初始改进时所需的工作量太多。选择也应该要考虑到群组的同构型。(例如：尽管他们都是软件工程师，但是他们是否都是工作在相同产品或是经营线等等)。选择要使用的模型是依据你的组织有兴趣要进行改进的领域。你不仅必须选择一个群集(例如：开发、采购或服务)，而且你也要决定是否要包含任何附加(例如：IPPD)。因为CMMI 模型的建立方式，选择要使用哪种表述的过程有一些指导。如果你的组织喜欢成熟度等级与阶段式表述，你的改进途径已经定义好了。若你的组织喜欢连续式表述，你几乎可以选择任何过程域或是一组过程域来指导改进，虽然在做这些选择时，应该考虑过程域之间的相依性。在过程改进计划与活动进展时，其它重要的选择也必须决定，包含该使用哪个评估方法、应该评估哪个项目、如何确保员工培训和应该培训哪些员工。能力成熟度集成模型 CMMI 模型说明已决定的最佳实践，组织发现这些实践有助于生产力并有用于达到它们的经营目标。无论你的组织是哪种类型，应用CMMI 最佳实践时，你必须使用专业判断，针对你的现况、需求和经营目标来解释它们。虽然过程域描述一个组织承诺过程改进的特征，你必须使用CMMI、你的组织、经营环境与特定情况的深入的知识，解释过程域。当你开始使用CMMI，改进你的组织过程时，将你真实世界的过程与CMMI 过程域对应。这个对应参考你做初始判断，以及之后追踪你的组织符合你所使用CMMI 模型的等级，并识别改进的机会。解释实践时，考虑使用哪些实践，以及决定这些实践如何满足过程域目标的程度是重要的。CMMI 模型并没有明确规定或暗指某些特定过程适合任何组织或项目。相反地，CMMI 对于策划与实施组织经营目标所选择要改进的过程，说明最基本的必要准则。 CMMI 实践有目的地使用非特定的词组，如同「相关的干系人」、「适当的」、「如有需要」来兼容于不同组织和项目的需要。项目的特定需要也可能会在生命周期中的不同时间点上有所差异。使用能力成熟度集成模型的评估很多组织发现度量它们进展的价值，藉由执行评估，然后获得成熟度等级评等或是能力度等级达成摘要。这些评估通常为下列一到多个理由而执行： • 要决定组织过程对应到CMMI 最佳实践到怎样程度，以及识别要进行改进的领域。 • 为了向外部客户与供应商报告组织过程对应到CMMI 最佳实践的程度。 • 为了符合一个或多个客户在合同上的需求。组织使用CMMI 模型评估，必须遵循Appraisal Requirements for CMMI(ARC) 文档上的需求定义。这些评估方式专注在识别改进机会与比对CMMI 最佳实践及组织内部过程。评估团队使用CMMI 模型与符合ARC 的评估方法来指导它们的组织评估，并且报告他们的结论。然后这些评估结果被(例如：过程组)用来规划组织的改进。能力成熟度集成模型的评估需求 ARC 文档说明数个评估类型的需求。一个完整可标竿学习的评估类型被定义成评估类型A，较不正规的方法被定义成评估类型B 或C。ARC 文档是设计用以帮助跨评估方法的一致性，以及参考评估方法之开发者、赞助者及使用者了解其它相关方法的权衡选择 [SEI 2006a]。取决于评估目的与环境性质，一个类型可能会优先于其它类型。有些时候，自我评价、初始评估、快速察看、小型评估、渐增评估或是外部评估是适当的，然而其它时候一个正式基线比较评估是适当的。以ARC 的需求为基础，一个特定的评估方法宣告为ARC Class A、ARC Class B 或ARC Class C 评估方法。这个ARC 的需求是在设计这个方法时，由方法开发者所处理。更多有关于ARC 的信息可以利用SEI 网站 SCAMPI 评估方法一般已接受用来执行CMMI 模型评估的方法为SCAMPI评估方法，SCAMPI方法定义文档(MDD) 定义确保评估等级一致性的规则，对于跨组织的基线比较，评估必须确保一致性的等级，特定成熟度等级的达到或是一个过程域的满足对于不同被评估组织而言都必须代表相同的情况。 SCAMPI评估家族包含Class A、Class B 与Class C 评估方法。SCAMPI A是最严谨以及唯一会产出评估等级的方法。SCAMPI B针对模型范围提供另一种选择，但是实践的特性描述是固定于一个尺度上以及针对已被执行的一般方法上实行。SCAMPI C根据使用者定义的尺度提供广大的选择，包含针对过程执行规划方法特征。更多有关于SCAMP方法的信息可以利用SEI 网站 2006b]。评估考量选择会影响以CMMI 为基础的评估包含以下所述： • 哪一个CMMI 模型用来评估（对于群集而言，这个选择可能是CMMI for Development 模型与CMMI for Development +IPPD 模型两者之一）。 • 制定评估范围，包含要评估的组织单位、要调查的CMMI 过程域以及要评估的成熟度等级与能力等级。 • 选择评估方法。 • 选择评估团队成员。 • 由要评估的个体选择要进行访谈的评估参与者。 • 建立评估产出（例如：评比或是特定案例发现）。 • 建立评估限制条件（例如：现场审查时间）。 SCAMPI MDD 容许在评估中使用预定选项选择。这些评估选项是设计用来参考组织校准CMMI以符合其经营需求与目标。 SCAMPI 评估计划与结果的文档化必须包含评估选择的说明、模型范围与选择的组织范围。这份文档会确认评估是否有符合基线比较的需求。当组织想要针对多个部门或群组进行评估时，CMMI 集成方法使得模型的规模经济与评估培训成为可能。评估方法可以针对多个部门提供个别或是集成的结果。针对CMMI产品组的评估准则和用于评估其它过程改进模型的准则相同，这些准则包含以下： • 高层管理支持 • 专注在组织经营目标 • 访谈的保密 • 已文档化评估方法的使用 • 使用过程参考模型（例如：CMMI 模型）作为基础 • 团队合作方法 • 专注于过程改进的活动能力成熟度集成模型的相关培训无论你的组织现在是过程改进的新手或是已经熟悉过程改进模型，培训是组织能力中采用CMMI的关键元素，SEI 及其伙伴提供一系列基本课程，但是你的组织可能想要利用内部教育来补充这些课程，这个方法允许你的组织专注于提供更大的经营价值的区域。 SEI 及其伙伴提供Introduction to CMMI 课程，这个课程提供一个CMMI 模型的基本简介。SEI 也提供Intermediate Concepts of CMMI 课程给那些规划要成为熟悉CMMI 之采用与评估的人。举例而言，在过程组中将要指导改进的人、想要教授Introduction to CMMI 课程的人。目前有关于CMMI 的培训信息可以利用SEI 网站第二部分通用目标与通用实践及过程域通用目标与通用实践概述本节详细的描述所有通用目标及通用实践---直接说明过程制度化的模型组件。过程域中，通用目标及通用实践出现在过程域的最后。通用实践的详细说明出现在通用实践之后，以表达这些实践如何独特的应用于过程域中。通用目标及通用实践的全部内容在过程域中不会重复（例如：省略了子实践、笔记、范例，及参照）。取而代之的只有通用目标及通用实践的标题及叙述。当说明过程域时，通用实践的详细内容可参照本节。过程制度化制度化在过程改进中是很重要的观念。在通用目标及通用实践叙述中，制度化意指过程已根深蒂固在工作的执行，以及执行过程的承诺与一致性。当压力来时，制度化过程仍被维持。然而，当需求及目标因过程而改变，过程的执行也需要改变以确保仍然有效。通用实践描述这些制度化观念的活动。制度化的等级包含于通用目标中，并以个别目标相关的过程名称来表达，如表所示。表通用目标及过程名称通用目标过程的开发 GG 1 已执行过程 GG 2 已管理过程 GG 3 已定义过程 GG 4 量化管理过程 GG 5 已优化过程在接下来的过程叙述中，将描述过程制度化的开发。已执行过程已执行过程是一种过程，为必要完成的工作以产生工作产品，并满足过程域的特定目标。已管理过程已管理过程是已执行过程，依据方针被规划及执行；任用拥有充足资源的技术人员生产已控制的产出；涉及相关干系人；被监督、控制及审查；以及遵循过程叙述来评估。建立过程的需求及目标。工作产品的状态及服务交付在已定义时间点（例如：在主要的里程碑及主要工作的完成）中的管理是显而易见的。在工作执行中及相关干系人间建立承诺，必要时进行修订。由相关干系人审查及控制工作产品，其工作产品及服务满足特定的需求。已执行过程及已管理过程间的主要区别在于被管理的程度。已管理过程是有规划的（计划可能是集成性计划的一部分），并依照计划来管理过程的执行。当正确的结果及绩效很明显与计划脱轨时，应采取纠正行动。已管理过程达到计划的目标，且以制度化达成绩效的一致性。已定义过程已定义过程是一个已管理过程，根据组织的定义指导定义组织标准过程，拥有已维护的过程叙述，并纳入工作产品、度量与其它过程改进信息至组织过程资产。组织过程资产是与描述、执行及改进过程相关的人为产物，之所以被称为资产，是因为通过开发或获取组织经营目标而取得，且对于期望能提供现在及未来经营价值的组织来说，也算是投资。建立并持续改进已定义过程的基础－组织标准过程。标准过程描述已定义过程期望的基本过程组件。标准过程同时描述这些过程组件间的关系(例如：顺序与接口)。组织层面的基础架构，支持现在与未来使用已建立并持续改进的组织标准过程（有关「标准过程」的定义，请参见词汇表）。项目的已定义过程提供规划、执行及改进项目工作和活动的基础。项目不只有一个已定义过程（例如：一个用于开发产品，另一个用于测试产品）。已定义过程的清楚陈述如下： • 目的 Purpose • 输入 Inputs • 入口准则 Entry criteria • 活动 Activities • 角色 Roles • 度量 Measures • 验证步骤 Verification steps • 输出 Outputs • 出口准则 Exit criteria 已管理过程与已定义过程的主要区别，在于过程说明、标准及程序的应用范围。在已管理过程中，过程说明、标准及程序应用于特定项目、团队或组织功能群。同一组织内，两个项目的已管理过程可能非常不同。另一个主要的区别，在于已定义过程比已管理过程描述更详细，执行更严谨，这意味着改进信息更容易了解、分析与使用。最后，通过了解过程活动的相互关系，以及过程、工作产品和服务的详细度量，来管理已定义过程，并提供更多的洞察力。已量化管理过程已量化管理过程是一个已定义过程，使用统计和其它量化的技术进行控制。产品质量、服务质量及过程绩效属性，在整个项目中是可测量（measurable）及控制的。量化目标是根据组织标准过程的能力、组织企业的目标，与客户、最终使用者、组织及过程执行者的需要，以及提供的可用资源而设定。执行过程的人直接从事量化的过程管理。对生产产品的整体过程执行量化管理，并对整体过程绩效有重要贡献的子过程进行统计管理。针对这些已选定的子过程，收集过程绩效的详细度量资料，并进行统计分析。识别过程变异的特殊原因，并适当收集特殊原因的来源，以避免未来再度发生。将质量和过程绩效的度量结果，纳入组织度量资产库（organization’s measurement repository），以支持未来以事实为基础的决策。过程绩效的量化管理活动包含如下： • 识别置于统计管理的子过程 • 识别并度量产品与过程属性，该属性对质量与过程绩效有重要贡献 • 识别并处理子过程变异的特殊原因(以已选定的产品与过程属性，及已选定进行统计管理的子过程为基础) • 以识别绩效在常态范围为目标，管理每一已选定的子过程(例如：以已选定的产品与过程属性为基础，使子过程绩效具统计稳定性与可预测性) • 预测过程能力，以符合已建立的量化质量与过程绩效目标 • 当决定已建立的量化质量与过程绩效目标无法符合时，采取适当的纠正措施以上描述的纠正措施包括：改变目标，或确保相关干系人对绩效差距具量化的了解，并同意此绩效差距。已定义过程与已量化管理过程的主要区别，在于过程绩效的可预测能力。已量化管理过程意指使用适当的统计和其它量化的技术，管理一个过程的一至多个子过程，因此可预测未来的过程绩效。已定义过程仅提供量化的可预测性。已优化过程已优化过程是一个已量化管理过程，改变与适应已量化管理过程，以符合重要的趋势与项目的经营目标。已优化过程通过渐进与创新的技术改进，致力于持续的过程绩效改进。识别、评估及部署那些处理过程变异的共同原因，缺陷与其它问题根本原因的过程改进，和可度量的组织过程改进。以下列二者的量化了解为基础选择改进方案：过程改进方案对达成组织过程改进目标的预期贡献，以及执行时的成本和对组织的冲击。组织过程的绩效是持续改进的。系统化管理与部署已选定之渐进与创新的技术改进至组织。根据量化过程改进的目标来度量与评估部署过程改进的效果。已优化过程，藉由改变平均值或减少变异的方式改变过程，以回归稳定的状态。这些改变意图改进过程绩效，以便达成组织已建立的过程绩效目标。已量化管理过程与已优化过程的主要区别，在于已优化过程藉由处理过程变异的共同原因而持续改进。已量化管理过程焦点于克服过程变异的特殊原因，并提出统计上可预测的结果。虽然过程或许可以产生可预期的结果，但结果本身却未必足以达成预期的目标。过程间的关系通用目标逐步开发，所以每个目标为下一个的基础。结论如下： • 已管理过程是已执行过程 • 已定义过程是已管理过程 • 已量化管理过程是已定义过程 • 已优化过程是已量化过程如此，按照顺序应用，通用目标描述渐进式制度化的过程，从已执行过程到已优化过程。达到过程域的GG1，就等于达到该过程域的通用目标。达到过程域的GG2，就等于可管理该过程域的过程绩效。有方针及有计划执行过程，并提供资源，分配责任如何执行培训过程，控制执行过程所选定的工作产品，等等。换句话说，规划及监督该过程就像任何项目或支持活动一样。达到过程域的GG3，假设存在组织标准过程，可定义为所使用的过程。定义可能对标准过程没有任何改变，换句话说，所使用的过程与标准过程可能是完全一样的。使用众所皆知的标准过程也是定义，因为已决定不需更进一步修改。每个过程域描述多样活动，有些是重复执行的。你可能需要定义其中一个已执行的活动，来导出新功能或环境。举例来说，你有一个开发或获得组织培训的标准，但没有包含网络在线培训。当准备开发或获得网络在线课程时，你可能需要定义标准过程，来导出特定的挑战及网络在线培训的利益。达到过程域的GG4 或GG5 概念上是可实行的，但除不经济外，也许在延长阶段中，产品领域会趋于稳定，或者过程域或专业领域是关键经营的驱动者。通用目标及通用实践本节描述所有通用目标及通用实践，相关的子实践、笔记、案例，以及参照。以数列顺序来排列通用目标，从GG1 到GG5，通用实践也以数列顺序及其所支持的通用目标来排列。如同前面所述，子实践、笔记、案例，以及参照不会在过程域中重复出现；通用目标及通用实践的细节只在此出现。 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 执行特定实践执行过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。此特定实践的目的在于产出工作产品与履行服务，该工作产品与服务是执行本过程所预期的结果。这些实践可能以非正式且未遵循书面的过程说明或计划的方式来执行。这些实践执行的精确度端视管理或执行该项工作的人员而定，不同的人执行，其差异可能相当大。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行过程。此通用实践的目的，在于定义组织对过程的期望，并使组织中的干系人都能了解这些期望。一般而言，资深管理人员（senior management）担负着建立与沟通组织的指导原则、方向及期望的责任。来自资深管理阶层的指示，不一定都称为「方针」。不论如何称呼或如何告知，存在于组织中的指示，都是对通用实践的期望。 GP 策划过程建立并维护用来执行过程的计划。此通用实践的目的，在于决定执行过程和达成已设定目标时所需的资源、准备执行过程所需的计划、准备过程说明，以及取得相关干系人对该计划的同意。实际上，每一过程域对通用实践的应用不尽相同。当应用于项目监控过程域时，本通用实践所说的策划，可能通过项目策划过程域相关的过程来实现。当应用于项目策划过程域时，项目策划过程域的通用实践就会设定项目策划过程的期望。必须了解本通用实践会强调在模型的其它地方已设定的期望，或设定新的期望。有关建立及维护项目计划，请参考项目策划过程域，以获得更多信息。计划的建立包含将计划文档化及提供过程说明。计划的维护包括进行更新以反应纠正措施，需求或目标的改变。执行过程的计划，包括下列基本项目： •过程说明 •过程的工作产品和服务的标准及需求 •过程绩效的特定目标(例如：质量、进度、循环时间，以及资源的使用) •过程的活动、工作产品及服务间的相依性 •执行过程所需的资源，包含资金、人力及工具 •责任与授权的分配 •执行与支持过程所需的培训 •控制的工作产品及其控制的等级 •度量需求以深入了解过程、工作产品，以及服务的绩效 •纳入已识别的干系人 •过程的监控活动 •过程的客观评价活动 •过程和工作产品的管理审查活动子实践 1.定义并记录执行过程的计划。此计划可能是一份独立的文档，可能包含在另一范围更广的文档中，也可能散布在不同的文档里。若散布在不同的文档里，就必须确保任务分工的一致性。文档可用存储媒体或纸本方式保存。 2. 定义并记录过程说明。过程说明包含相关的标准和程序，可视为过程规划的一部分，或者当做规划的参考。 3.与相关的干系人审查此计划，并取得他们的同意。此动作在于审查已规划的过程是否符合现行的方针、计划、需求及标准，以便向相关的干系人提出保证。 4. 视需要修订计划。 GP 提供资源提供充分的资源，以执行过程、开发工作产品及提供过程服务。此通用实践的目的，在于确保需要时能获得执行过程所需的资源。资源包含充分的资金、合适的硬件设施、有技能的人力及适当的工具。「充分」一词的诠释则视许多因素而定，而且随时可能改变。不充分的资源可以靠增加资源，或减少需求、限制及承诺来解决。 GP 分配责任分配过程的责任与授权，以执行过程、开发工作产品及提供过程服务。此通用实践的目的，在于整个执行过程和达成指定结果的过程中，都有人能负责任。被分配责任的人一定要取得适当的授权，以执行该责任。可以用详细的工作说明或文档(如执行过程的计划)来分配责任。在过程的生命周期内，只要责任的分配和接受都能获得保证，动态的责任分配也是执行本通用实践的一种合理方法。子实践 1. 分配整体性的责任与授权，以执行过程。 2. 分配责任及授权以执行过程的特定工作。 3. 确定被分配责任与授权的人，都能了解和接受。 GP 培训人员根据需要培训人员，以执行或支持过程。此通用实践的目的，在于确保人员具有必要的技巧和专业知识，以执行或支持过程的执行。提供执行工作的人员适当的培训，并针对与执行工作人员互动的人员，实施概要培训以提供指导。培训的进行方式，包括自修、自我引导的培训、在线学习、在职培训、同行指导及正式的课堂培训等。培训可建立对过程的共识，以及传授执行过程时所需的技巧和专业知识，所以培训可提供帮助以成功地执行过程。有关培训人员来执行或支持过程，请参考组织培训过程域，以获得更多信息。 GP 管理配置将指定的过程工作产品，纳入适当等级的控制。此通用实践的目的，在于建立并维护过程的指定工作产品(或其说明)在它整个生命周期的完整性。在执行过程的计划中须特别识别什么是指定的工作产品，以及该工作产品被纳入适当控制的等级。不同的工作产品，以及在不同的时间点，所适用的控制等级可能不同。对某些工作产品而言，进行版本控制可能就足够。也就是不论过去或者现在，工作产品在某段时间所用的版本都很清楚，而且改变都在控制下进行。版本控制通常都由工作产品的拥有者(可能是个人、小组或团队)单独控制。有时将工作产品置于正式或「基线(baseline)」的配置管理是非常重要的。这种类型的控制会在事先设定的时间点，定义和建立基线。这些基线会被正式审查及同意，并当做工作产品进一步开发的基础。有关将工作产品纳入配置管理，请参考配置管理过程域，以获得更多信息。在版本控制与正式的控制之间，可能有其它等级的配置管理。在不同的时间点，经识别的工作产品可能纳入不同等级的控制之下。 GP 识别并纳入相关干系人根据计划识别并纳入过程相关干系人。此通用实践的目的，在于建立并维护干系人在过程执行期间预期的参与程度。依描述干系人参与之适当计划所述，将相关的干系人纳入。将干系人适当地纳入，以参与下列活动： • 规划 • 决策 • 承诺 • 沟通 • 协调 • 审查 • 评估 • 需求定义 • 问题或问题的解决方案有关纳入干系人的项目策划，请参考项目策划过程域，以获得更多信息。规划干系人参与的目的，在于确保干系人与过程间必要的互动，但又不致于使太多相关的小组或个人阻碍过程的执行。子实践 1. 识别与过程有关的干系人，并决定其参与的方式。由输入的供应者、输出的使用者，以及过程活动的执行者之中，识别出相关的干系人。一旦识别相关的干系人，也会规划相关的干系人在过程活动的参与程度。 2. 将这些身份识别的方式，与项目策划人员或其它适当的规划人员一起分享。 3. 依据规划的方式，纳入相关的干系人。 GP 监控过程根据本过程的执行计划，监控过程，并采取适当的纠正措施。此通用实践的目的，在于执行直接的日常过程监控。维护过程适当的能见度，以便于必要时，采取适当的纠正措施。过程监控包括过程或过程所产生之工作产品参数的度量工作。有关监控项目与实行纠正措施，请参考项目监控过程域，以获得更多信息。有关度量，请参考度量与分析过程域，以获得更多信息。子实践 1.度量实际的绩效，并与过程的执行计划进行比较。度量的对象为过程、工作产品及服务。 2.审查过程的实际执行结果，是否与过程的执行计划相符。 3.与第一线负责过程的管理者审查过程的活动、进度及结果，并识别可能的问题。此审查的目的，在于提供第一线管理者对过程适当的了解。这类审查的进行时机可以是定期的，也可以在事件发生时才进行。 4.识别并评价与过程的执行计划有显著差异的影响。 5.识别发生在执行过程时和过程执行计划的问题。 6.当需求与目标不符合、问题被识别，或进度严重落后于过程执行计划的要求时，采取纠正措施。采取纠正措施之前，应先考虑其潜在风险（inherent risks）。纠正措施可涵盖下列内容： •采取补救措施，以修补有缺陷的工作产品或服务 •变更过程的执行计划 •调整资源包含人员、工具及其它资源 •对已承诺事项的变更进行沟通 •确保需求和目标的改变能符合要求 •终止工作 7. 追踪纠正措施直到关闭。 GP 客观评价遵循程度根据本过程的说明、目标、标准及程序，客观评价过程的遵循程度，并解决不符合的情况。此通用实践的目的，在于提供可信的保证，确保过程根据计划执行，并遵循该过程的说明、标准及程序。某种程度来说，是藉由评价过程的已选定工作产品，来执行通用实践（有关「客观陪你感觉」的定义，请参见词汇。）有关遵循程度的客观评估，请参考过程与产品质量保证过程域，以获得更多信息。基本上，非直接负责管理或执行过程活动的人员，可进行遵循程度的评价。大部分的情况下，由下列人员执行遵循度的评价：组织中非本过程或项目的人员或非本组织的人员。因此即使在过程面对压力(如进度落后或预算超过)的情况下，亦可提供遵循程度的可信赖保证。 GP 与高层（Higher Level）管理人员审查各状况与高层管理人员审查过程的活动、状况及结果，并解决问题。此通用实践的目的，在于使高层管理人员对过程的执行有适当的了解。「高层管理人员(higher-level management) 」包括高于直接负责过程管理阶层的所有阶层的管理人员。特别注意的是，高层管理者包含资深管理阶层。本通用实践所指的审查的管理人员，是指提供负责整体过程指导的管理人员，而不是执行日常过程监控的管理人员。不同的管理人员对过程的信息需要会有所不同。上述的审查能确保在过程策划与实施时，有充分的信息以进行决策。因此这类审查的进行时机，可以是定期的，也可以在事件发生时才进行。 GG 3 制度化已定义过程将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义过程的说明。此通用实践的目的，在于建立并维护过程的说明。过程的说明，为满足某种特定状况的需要，自组织标准过程定义而来。组织应有一套涵盖过程域的标准过程与定义指导，依据某项目或组织单位的需要定义该标准过程。有了已定义过程，会减少组织执行过程的差异，而且更能有效率地分享过程资产、数据及学习心得。有关组织标准过程和定义指导，请参考组织过程定义过程域，以获得更多信息。有关建立及维护项目的已定义过程，请参考集成项目管理过程域，以获得更多信息。已定义过程的描述，提供过程规划及过程执行的基础，也提供过程相关活动、工作产品及服务的管理基础。子实践 1.自组织标准过程中，选择已包含过程域且最适合某项目或组织功能需要的过程组。 2.根据组织的定义指导，定义已选定的过程，以建立已定义过程。 3.确保已定义过程，已适当的说明组织的过程目标。 4.记录已定义过程和定义的纪录。 5.视需要修订已定义过程的说明。 GP 收集改进信息收集由规划和执行过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。此通用实践的目的，在于收集进行规划和执行过程时的信息和产品。通过执行本通用实践，相关信息和产品可存放于组织过程资产中，并可供正在(或将要)规划和执行相同或相似过程的人员使用。相关信息和产品存放于组织度量资产库和组织过程资产库中。相关信息，包括各种活动所投入的工作量、某特殊活动所注入或移除的缺陷数，以及学习心得等。有关组织度量资产库、组织过程资产库，以及纳入资产库的工作产品、度量及改进信息，请参考组织过程定义过程域，以获得更多信息。有关贡献工作产品、度量及文档化的经验，给组织过程资产，请参考集成项目管理过程域，以获得更多信息。子实践 1. 将过程和产品的度量数据存放到组织度量资产库中。过程和产品的度量数据，主要是组织标准过程所定义的共同度量。 2. 提交相关文档，以纳入组织过程资产库。 3. 记录过程的学习心得，以纳入组织过程资产库。 4. 提出组织过程资产的改进建议。 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。本实践的目的，在决定并自相关干系人取得关于过程特定量化目标的协议，这些量化目标能表达产品质量、服务质量及过程绩效。有关如何设定项目已定义过程的子过程之量化目标，请参考量化项目管理过程域，以获得更多信息。量化目标可能为特定过程而定，或者它们可能为较广的范围而定义(例如：为一组过程)，在往后的案例，这些量化目标可能分配至某些被涵盖的过程。这些量化目标是用来判断产品、服务与过程绩效是否满足客户、最终使用者、组织管理及过程执行者的准则。这些量化目标超越传统最终产品的目标，它们同时包括用来管理持续达成目标的中间目标。它们部分地反映组织标准过程的展示绩效。当参与的过程是稳定的，并落入常态范围的目标范围内，这些量化目标应设定可能达成的数值。子实践 1. 建立过程有关的量化目标。 2. 分配量化目标至过程或其子过程。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定过程的能力，是否达成已建立之量化质量与过程绩效目标。本通用实践的目的是稳定一个或多个已定义(能力度第三级)过程的子过程之绩效，该过程使用适当的统计和其它量化的技术，并对整体绩效有重要贡献。稳定已选定子过程来支持过程的预测能力，以达成已建立的量化质量与过程改进目标。有关为统计管理、监督子过程绩效及其它稳定子过程绩效方面，选择子过程，请参考量化项目管理过程域以获得信息。一个稳定的过程展现没有过程变异特殊原因的重要指针，在子过程的常态范围所建立的限制下，稳定的子过程是可预测的。稳定子过程的变异，是由于一个稳定系统的偶然原因，而且变异的强度可小可大。预测过程的能力以达成已建立的量化目标，需要量化了解子过程的贡献，这对达成这些目标，以及持续建立和管理过渡的量化目标是重要的。已选定的过程与产品度量纳入组织度量资产库，以支持过程绩效分析与未来以事实为基础的决策。子实践 1. 统计管理一个或多个子过程绩效，对整体过程绩效有重要贡献。 2. 预测过程的能力以达成已建立的量化目标，考虑统计管理子过程绩效。 3. 将已选定的过程绩效度量，纳入组织过程绩效基线。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保过程的持续改进，以实现相关的组织经营目标。此通用实践的目的，在于选择系统化部署过程与技术改进项目，以促成符合所建立的质量和过程改进目标。有关选定及布置渐进及创新的改进方法，以可度量式地改进组织过程及科技，请参考组织创新及布置过程域，以获得更多信息。灵活和创新的已优化过程，有赖于被充分授权之工作团队的参与，并且配合组织的经营价值与目标。可藉由加速学习和分享学习的方法，加强组织对改变和机会的快速反应能力。过程改进是每个人的责任，它也会导致持续改进的循环。子实践 1. 建立与维护量化过程改进目标，以支持组织的经营目标。量化过程改进目标可能是个别过程的特定目标，或为较广的范围而定义(例如：一组过程)，而个别过程对达成这些目标做出贡献。个别过程的特定目标通常由为较广范围所建立的量化目标配置而来。这些过程改进目标，主要由组织的经营目标和过程能力的详细了解衍生而来，这些目标是用来判断过程绩效是否量化改进组织能力，以满足经营目标的准则。这些过程改进目标时常设定高于目前过程绩效的数值，并且可能需要渐进与创新的技术改进，以达成这些目标。这些目标也可能经常修订，以持续驱动过程改进(例如：当达成目标，可能设定再高于新过程绩效的新数值)。这些过程改进目标，可能与「建立过程的量化目标」通用实践的目标相同或更精确。只要它们可以作为成功过程改进的驱动与准则。 2.识别过程改进项目，这些改进项目对过程绩效会产生可度量的改进。过程改进包括渐进的改变与创新的技术改进，通常个别规划、执行与管理追求创新技术改进的工作量。时常执行试行。藉由分析过程绩效与识别重要度量改进的特定机会，决定处理过程特定领域的工作量。 3.以量化的预期效益、估计成本与影响，以及过程绩效度量的改变为基础，定义策略并管理已选定过程改进项目的部署。量化估计这些改进项目的成本与效益，并度量实际的成本与效益。相对于组织量化的过程改进目标，效益是主要的考量。同时对组织标准过程与已定义过程进行改进。管理过程改进的部署，包括变更的试行与适当的进行实施的调整、处理潜在与实际的部署障碍、减低对不断努力的瓦解，以及管理风险。 GP 纠正问题的根本原因识别并纠正过程的缺陷与其它问题的根本原因。此通用实践的目的，在于分析在量化管理过程中，所造成缺陷和其它问题的原因，纠正此类缺陷与问题的根本原因，并避免缺陷及问题未来再度发生。有关识别并纠正所选缺陷的根本原因，请参考原因分析与解决方案过程域，以获得更多信息。虽然原因分析与解决方案过程域有项目背景，其亦可应用于其它背景的过程。根本原因分析可有效益地应用在非量化管理的过程。但是本通用实践仍着重在量化管理过程，虽然在过程外可能发现最终根本原因。应用通用实践本节参考你更了解通用实践，并提供信息，以诠释及应用通用实践到你的组织。通用实践对所有过程域来说，是共性的组件，目的在于提醒你把事情做对，并期望成为模型组件。举例来说，当达成项目策划过程域的通用实践时，同时你也在建立及维护定义项目活动的计划。应用通用实践到项目策划过程域，是在建立及维护计划，以执行项目策划过程()。当应用通用实践到本过程域，是在提醒你去规划与建立与项目计划相关的活动。当你满足组织培训过程域的特定目标时，也就是在开发项目及组织人员的技巧及知识，以致于能更有效果及有效率地执行他们的角色。当应用同样的通用实践()到组织培训过程域，特定实践能提醒你去规划，与开发组织人员技巧及知识相关的活动。支持特定实践的过程域通用目标及通用实践是模型组件，用以直接陈述跨组织的过程制度化，很多过程域同样地陈述支持通用实践实施的制度化过程。了解这些关系，将有助于有效率地执行通用实践。这些过程域包含一个或多个特定实践，实施时，可能完全执行一个特定实践，或者是产生用于执行特定实践的工作产品。举配置管理过程域及“ 在适当控制等级中，选定过程的指定工作产品”的例子来说。为执行一个或多个过程域的通用实践，你可能选择执行配置管理过程域，全部或部分地执行特定实践。另一个是组织过程定义过程域及“ 建立及维护已定义过程叙述”的例子。为执行一个或多个过程域的通用实践，应该先执行组织过程定义流程领域，全部或部分地建立组织过程资产，用以执行特定实践。表描述(1)支持执行特定实践的过程域，及(2)特定实践及其紧密相关过程域间的递归关系。过程改进利用存在于特定实践及其相关的过程域间自然的合作方式，这两种关系的种类要牢记。表特定实践及过程域关系特定实践在特定实践的实施上，过程域的角色实践如何递归地应用于其相关的过程域 GP 策划过程项目策划：对所有与项目相关的过程域（除项目策划本身外），项目策划过程可以完全实行。应用于项目策划过程是“规划计划”的特点，并包含规划项目的规划活动 GP 提供资源 GP 分配责任项目策划：部分的项目策划过程，实行了“项目策划执行项目所需资源的计划”，对所有与项目相关的过程域(也许除最初的项目策划本身外) ，支持及的实行，并藉由识别所需过程、角色，及职责，以确保项目所需的适当任职、机构、设备，以及其它资产，是安全的。 GP 培训人员组织培训：组织培训过程支持的实行，可藉由培训策略或组织全面的培训需求，给将执行或支持过程的人员，以应用到所有过程域。项目策划：项目策划过程实行项目策划”执行项目所需的知识及技巧计划”，以及组织培训过程，对于所有项目相关的过程域，支持的完整实行。应用于组织培训过程，包含执行组织培训活动的培训，其陈述了管理、创造及完成培训所需要的技巧。 GP 配置管理配置管理：对于所有项目相关的过程域，以及部分组织过程域，配置管理过程可完整实行。应用于配置管理过程，包含了配置管理产生之工作产品的变更及版本控制。 GP 识别及涉及相关干系人项目策划：项目策划过程中，有关实行项目策划” 干系人参与计划”，对于所有项目相关的过程域，同样可完整实行的干系人部分（前二个子实践）。项目监控：项目监控过程中，有关实行项目项目监控” 监督干系人参与”，对于所有项目相关的过程域，有助于实行第三个子实践。集成项目管理：集成项目管理过程中，有关实行集成项目管理”管理干系人参与”，对于所有项目相关的过程域，有助于实行第三个子实践。应用于项目策划过程，包含了项目策划活动中，相关干系人的参与。应用于项目监控过程，包含相关干系人在项目监控活动的参与。 GP 应用于集成项目管理过程，包含了相关干系人在集成项目管理活动的参与。 GP 监控过程项目监控管理：对于所有项目相关的过程域，项目监控管理过程可完整实行。度量与分析：对所有过程，而不只是项目相关过程来说，度量与分析过程域提供有关度量、分析与记录资讯的一般指导，可用于建立度量，来监督过程的实际绩效。应用于项目监控过程，包含监控项目的监控活动。 GP 目标评估遵循过程与产品质量保证：对于所有过程域（也许除了过程与产品质量保证本身），过程与产品质量保证过程可完整实行。应用于过程与产品质量保证过程，包含质量保证活动的目标评价。 GP 与更高管理阶级审查状态项目监控管理：在项目监控过程中，有关实行项目监控” 进行进度审查” 及”进行里程碑审查”，对于所有项目相关过程域，支持的实行，其完整度端视这些审查的较高管理阶级而定。 GP 建立已定义过程集成项目管理：在集成项目管理过程中，有关实行集成项目管理”从项目成立到整个项目周期，建立及维护项目已定义过程”，对于所有项目相关的过程域，可完整实行。组织过程定义：对所有过程，而不只是项目相关过程来说，组织过程定义过程建立实行所需的组织过程资产。应用于集成项目管理过程，包含为了集成项目管理活动，而建立已定义过程。 GP 收集改进信息集成项目管理：在集成项目管理过程中，有关实行项目管理”提供工作产品、度量及文档化的经验给组织过程资产”，对于所有项目相关的过程域，可完整实行。组织过程焦点：在组织过程焦点过程中，有关实行组织过程焦点”从规划及执行过程中，取得过程相关工作产品、度量及改进信息，并合并到组织过程资产中”，对于所有过程域，可部分或完整实行。组织过程定义：对所有过程，组织过程已定义过程建立实行所需的组织过程资产。应用于集成项目管理过程，包含收集从规划及执行集成项目管理活动中，所取得的改进信息。 GP 建立过程的量化目标量化项目管理：量化项目管理过程中，有关实行量化项目管理”建立及维护项目的质量及过程绩效目标”，对于所有项目相关过程域，从各特定过程取得的目标，可支持的实行。如果这些目标为量化项目管理子实践5 及8 的一部分，则量化项目管理过程完整地实行。组织过程绩效：在组织过程绩效过程中，有关组织过程绩效”建立及维护组织质量及过程绩效的量化目标”，对于所有过程域，支持的实行。应用于量化项目管理过程，包含建立量化项目管理活动的量化目标。应用于组织过程绩效，包含建立组织过程绩效活动的量化目标。 GP 稳定详细过程绩效量化项目管理：量化项目管理过程中，有关实行量化项目管理GP2” 统计管理详细过程绩效”，对于所有项目相关过程域，以及相对应的统计管理详细过程，可支持的完整实行。组织过程绩效：对所有过程，而不只是项目相关过程来说，组织过程绩效过程建立实行所需的组织过程资产。应用于量化项目管理过程，包含在量化项目管理活动中，已选定详细过程的稳定性。 GP 确保持续过程改进组织创新部署：组织创新部署过程，对于所有过程域，可完整实行，提供质量及过程绩效目标给已定义的组织。（如果已实行组织过程绩效过程域，就如同是后者）。应用于组织创新部署过程，包含在组织创新及部署活动中，确保持续过程改进。 GP 纠正问题的根本原因原因分析及解决方案：对于所有项目相关的过程域，原因分析及解决方案过程可完整实行。应用于原因分析及解决方案过程，包含在原因分析及解决方案活动中，识别缺失的根本原因及其它问题。这些过程域通常较早以完整或部分来实行，提早或同时与相关的通用实践共同执行，以提供通用实践在这些过程域的相依性，以及很多流程领域所呈现更多完整的观点。应用通用实践到特定的过程域，似乎是多余的，但事实上，并非如此。这样来想也许是正常的，应用“建立已定义过程”，到项目策划及项目监控过程域，效果如同集成项目管理的第一个特定实践。“使用从组织标准过程定义的已定义过程，来执行项目”。虽然有些部分是重迭，通用实践应用于这两个过程域中，提供已定义过程涵盖了项目策划及项目监控活动。已定义过程无需涵盖支持活动（如配置管理）、其它项目管理过程（如供应商协议管理），或工程过程。相反地，集成项目管理过程领域的项目已定义过程，涵盖了所有适当的项目管理、工程，和支持过程。原因分析与解决方案（CAR 5级）成熟度第五级的支持类过程域目的原因分析与解决方案(Causal Analysis and Resolution, CAR)的目的，在于识别造成缺陷和其它问题的原因，并采取行动以避免未来再度发生。简介原因分析与解决方案，包括下列活动： • 识别并分析造成缺陷和其它问题的原因 • 采取特定行动，以移除造成缺陷及问题的原因，并避免此类缺陷及问题未来再度发生藉由原因分析与解决方案以改进质量和生产力避免将缺陷导入产品。在缺陷发生后再进行侦测是不符合成本效益的。更有效的方式是，将原因分析与解决方案的活动集成到项目的每个阶段，以避免缺陷的发生。既然缺陷和问题可能发生于先前的其它项目或现有项目的稍早阶段，原因分析与解决方案的活动可以作为各项目间沟通学习的机制。分析所发生的缺陷和其它问题的种类，以识别其趋势。依对已定义过程及其如何实施的了解为基础，判定缺陷的根本原因及未来可能发生的地方。原因分析也可以运用于与缺陷无关的问题上，例如：原因分析可用来改进质量属性，如周期时间等。这种分析可由改进建议、仿真、动态系统模型、工程分析、新的经营指示或其它项目所启动。当对所有的缺陷进行原因分析并不实际时，必须在预估的投资与预估的质量、生产力、周期时间的报酬之间做取舍，选择缺陷目标。在某些情况下，也许需要新的度量来分析过程变更的影响，但度量过程应准备妥当，并使用已定义的度量。有关建立度量与分析的目标、识别待执行的度量与分析、取得和分析度量数据，以及报告结果等，请参考度量与分析过程域，以获得更多信息。原因分析与解决方案活动提供项目一个机制，以便在项目等级评估其过程，并找寻可实施的改进措拖。当改进措施在项目等级的实施被认定为有效时，这些信息可扩展至组织等级。有关通过所建议的改进措施和行动建议，以改进组织等级的过程，请参考组织创新与部署过程域，以获得更多信息。本过程域的参考性数据的前提为特定实践适用量化管理过程。在不考虑此前提的情况下，本过程域的特定实践也可适用，不过会降低所产生的价值。有关「稳定过程」和「过程变异的共同原因」的定义，请参见词汇。相关过程域有关过程绩效的分析与已选定之项目过程的能力度之度量的产生，请参考量化项目管理过程域，以获得更多信息。有关针对组织过程和技术改进的选择与部署，请参考组织创新与部署过程域，以获得更多信息。有关建立度量与分析的目标、识别待执行的度量与分析、取得和分析度量数据，以及报告结果等，请参考度量与分析过程域，以获得更多信息。特定目标及实践摘要 SG 1 决定造成缺陷的原因 SP 选择待分析的缺陷数据 SP 分析原因 SG 2 处理造成缺陷的原因 SP 实施行动建议方案 SP 评价变更的效果 SP 记录相关数据各目标的特定实践 SG 1 决定造成缺陷的原因有系统地决定造成缺失和其他问题的根本原因。根本原因是缺陷的源头，若移除根本原因，那么就移除或减少缺陷。 SP 选择待分析的缺陷数据选择缺陷和其它问题数据，以进行分析。典型的工作产品 1. 选定待进一步分析的缺陷和问题数据子实践 1. 收集相关的缺陷或问题资料。相关缺陷资料，举例如下： • 客户反映的缺陷 • 终端使用者反映的缺陷 • 同行评审时发现的缺陷 • 测试时发现的缺陷有关问题资料，举例如下： • 需要纠正措施的项目管理问题 • 过程能力的问题 • 过程期间的度量 • 各过程的挣值（earned value）度量(例如：成本绩效指标) • 资源流量、适用率、或反应时间度量有关工作产品的验证，请参考验证过程域，以获得更多信息。有关统计化管理，请参考量化项目管理过程域，以获得更多信息。 2. 决定需进一步分析的缺陷和其它问题。在决定哪些缺陷需进一步分析时，应考虑缺陷的影响、发生频率、缺陷间的相似性、分析成本、所需的时间和资源、安全性考量等等。选择缺陷和其它问题的方法，举例如下 • 柏拉图分析 Pareto analysis • 直方图 Histograms • 过程能力分析 Process capability analysis SP 分析原因针对所选的缺陷和其它问题，进行原因分析，并提出处理的行动方案。原因分析的目的，在于藉由分析相关数据和产生实施的行动建议，以开发所识别问题的解决方案。典型的工作产品 1. 行动建议方案子实践 1. 与负责执行该项工作的人共同分析原因。通常以会议的方式，与了解缺陷和其它问题的人，针对所选的缺陷和其它问题，共同进行原因分析的研究，而最了解缺陷的人通常也是负责执行该项工作的人。执行原因分析的时机，举例如下： • 当稳定过程无法满足它的质量和过程绩效目标时 • 在工作执行期间，当缺陷数目或已识别问题数量多到需要召开额外会议时 • 当工作产品与其需求之间存在非预期的差异时有关达成项目质量和过程绩效目标，请参考量化项目管理过程域，以获得更多信息。 2. 分析所选的缺陷和其它问题，以决定它们的根本原因。在识别根本原因之前，可依缺陷的类型和数量先将它们分类。决定根本原因的方法，举例如下： • 因果图，即鱼骨图 • 检查表 3. 依据根本原因，将所选的缺陷和其它问题分类进行。原因的类别，举例如下： • 培训不足 • 沟通中断 • 没有说明工作的所有细节 • 人为操作错误(例如：打错字) • 过程缺乏 4. 建议并记录需要实行的行动方案，以避免未来发生类似的缺陷或其它问题。建议的行动方案可能包括对下列的变更： • 有问题的过程 • 培训 • 工具 • 方法 • 沟通 • 工作产品特定的行动方案，举例如下： • 针对共性的问题和技术，提供培训以避免再度发生 • 变更过程，使易犯错的步骤不再发生 • 过程的局部或全部自动化 • 将过程活动重新排序 • 增加避免缺陷的过程步骤，例如：增加工作启动会议，以审查共同的缺陷和行动方案，并避免再度发生行动建议方案，通常记录下列各项： • 行动建议的发起人 • 问题说明 • 缺陷原因说明 • 缺陷原因类别 • 提出问题的阶段 • 识别出缺陷的阶段 • 行动建议的说明 • 行动建议的类别 SG 2 处理造成缺陷的原因有系统地处理造成缺失和其他原因的根本原因，以避免未来再度发生。项目依已妥善定义的过程运作，若项目仍然发生问题，项目会系统化的分析其运作方式，并实施过程变更，以消除所选问题的根本原因。 SP 实施行动建议方案实施原因分析所开发的行动建议方案。行动建议方案描述必要工作，用以移除经过分析之缺陷和问题的根本原因，并避免它们再度发生。只有证明此变更有价值，才可考虑将其广泛实施。典型的工作产品 1. 已选定要实施的行动建议 2. 改进建议子实践 1. 分析各种行动建议，并决定优先级。排定行动建议优先级的准则，包括： • 未处理缺陷的意涵 • 实施过程改进措施以避免缺陷的成本 • 对质量的预期影响 2. 选择将实施的行动建议。 3. 产生实施行动建议的行动项目。行动项目所提供的信息，举例如下： • 负责实施的人 • 受影响领域的描述 • 必须被告知行动状况的人 • 下一次进行状况审查的日期 • 关键决策的理由 • 实施行动的描述 • 识别和纠正缺陷所需时间和成本 • 不解决问题的预估成本实施行动建议必须执行下列各项工作： • 分配工作 • 协调执行工作的相关人员 • 审查各项结果 • 追踪各行动项目至关闭为止针对特殊复杂的变更，可先进行实验。实验的举例如下： • 使用暂时性已修订的过程 • 使用新工具行动项目可分配给原因分析团队、项目团队，或组织内其它的成员。 4. 识别并移除可能存在于其它过程和工作产品的类似缺陷。 5. 识别并记录组织标准过程的改进建议。有关组织标准过程之改进建议的选择与部署，请参考组织创新与部署过程域，以获得更多信息。 SP 评估变更的效果评估变更在过程绩效上所产生的效果。有关过程绩效的分析与已选定过程的能力度之度量的产生，请参考量化项目管理过程域，以获得更多信息。一旦在项目内部署已变更的过程，应检查变更所产生的效果，以便收集相关证据来证明该过程变更确已纠正问题和改进绩效。典型的工作产品 1. 绩效和绩效变更的度量子实践 1. 适当的度量项目已定义过程的绩效变更。本子实践决定所选的变更对过程绩效是否有正面影响及其影响程度。对项目已定义设计过程的绩效变更，以设计文档在缺陷密度的变更为例：通过同行评审，比较实施改进措施前后所统计的缺陷数变化。在统计过程控制图表上，这些变更可由其平均值的变化看出。 2. 适当的度量项目已定义过程的能力。本子实践决定已挑选的变更对满足其质量与过程绩效目标的能力是否有正面影响，该质量目标系由相关的干系人决定。对项目已定义设计过程的能力变更，以将该过程停留在过程规格内之能力的变更为例：通过同行评审，比较实施改进措施前后所统计的缺陷幅度变化。在统计过程控制图上，这些变更可由其已降低的控制区间看出。 SP 记录相关数据记录原因分析和解决方案相关数据，以供项目和组织使用。记录数据，使其它项目和组织可做适当的过程变更并达成相似结果。记录下列数据： • 分析之缺陷和其它问题的数据 • 决策的理由 • 原因分析会议的行动建议方案 • 行动建议方案所导出的行动项目 • 原因分析与解决方案活动的成本 • 解决方案之已定义过程绩效变更的度量典型的工作产品 1. 原因分析与解决方案的纪录各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将界定输入的工作产品转换为输出的工作产品，并支持与促进过程领域特定目标的达成 GP 实施特定实践实施原因分析与解决方案过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织方针，以规划和执行原因分析与解决方案过程。详细说明：本方针建立组织期望，以识别及有系统的处理造成缺陷及其它问题的根本原因。 GP 规划过程建立并维护执行原因分析与解决方案过程的计划。详细说明：本计划用于执行原因分析与解决方案可包括(或参照) 项目策划过程域的描述项目计划。不同于本过程域的特定实践所描述的行动建议和相关的行动项目。本通用实践所谓的计划，乃在说明项目整体的原因分析与解决方案过程(可能由组织所维护的标准过程定义而成)。而过程的行动建议和相关的行动项目则强调移除特定根本原因所需的活动。 GP 提供资源提供充足的资源，以执行原因分析与解决方案过程、开发工作产品及提供过程服务。详细说明：提供的资源，举例如下： • 数据库系统 • 过程模型工具 • 统计分析软件包 • 工具、方法及分析技术，如：石川图(Ishikawa)或鱼骨图、柏拉图分析、直方图、过程能力研究、控制图等 GP 分配责任分配原因分析与解决方案过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员根据需要培训人员，以执行或支持原因分析与解决方案过程。详细说明：培训主题，举例如下： •质量管理方法(例如：根本原因分析) GP 管理配置将指定的原因分析与解决方案过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 行动建议方案 • 已选定要实施之改进建议的行动建议 • 原因分析与解决方案的纪录 GP 识别并纳入相关的干系人根据计划识别并纳入原因分析与解决方案过程相关的干系人。详细说明：干系人参与的活动，举例如下： • 进行原因分析 • 评价行动建议 GP 监控过程根据本过程的执行计划，监控原因分析与解决方案过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 已移除之根本原因的数目 • 原因分析与解决方案过程中每项目例在质量或过程绩效的改变 • 执行已选定行动建议活动的进度 GP 客观评价遵循程度根据本过程的说明、标准及程序，客观评估原因分析与解决方案过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 决定缺陷的原因 • 处理造成缺陷的原因审查的工作产品，举例如下： • 已选定要实施的行动建议方案 • 原因分析和解决方案的纪录 GP 与高层管理人员审查各状况与高层管理人员审查原因分析与解决方案过程的活动、状况及结果，并解决问题。仅适用于连续式表述GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义原因分析与解决方案过程的说明。 GP 收集改进信息收集由规划并执行原因分析与解决方案过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息的例子，包括如下： • 行动建议方案 • 尚未关闭之行动建议数，以及其帐龄 • 行动建议状态报告仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化管理过程。 GP 建立过程的量化目标建立并维护原因分析与解决方案过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定原因分析与解决方案过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保原因分析与解决方案过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正原因分析与解决方案过程之缺陷与其它问题的根本原因。配置管理（CM 2级）成熟度第二级的支持过程目的配置管理(Configuration Management, CM)的目的，在使用配置识别、配置控制、配置状态记录及配置审计，来达到建立与维护工作产品的完整性。简介配置管理过程域，包含下列活动： • 识别所选定的工作产品的配置，这些工作产品在特定的时间点会组成基线 • 控制配置项的变更 • 建立或提供规格，以便从配置管理系统建造工作产品 • 维护基线的完整性 • 提供正确的状态和目前的配置数据给开发人员、最终使用者及客户纳入配置管理的工作产品，包含交付客户的产品、指定的内部工作产品、取得的产品、工具，以及其它用以产生或描述这些工作产品的项目。(有关「配置管理」的定义，请参见词汇。) 供应商和项目可能都需要将取得的产品纳入配置管理。供应商协议中应建立执行配置管理的规定。应建立并维护用以确保数据之完整性和一致性的方法。请参考「供应商协议管理」过程域，以获取更多有关建立及维护供应商的协议信息。可能纳入配置管理的工作产品，举例如下： • 计划 • 过程说明 • 需求 • 设计数据 • 图表 • 产品规格 • 程序代码 • 编译器 • 产品数据文档 • 产品技术文档工作产品的配置管理可以在许多不同层次的精细度上执行。配置项可分解为配置组件和配置单元。本过程域只使用「配置项」这个术语。因此，在这些实践中，在适当的时候，配置项可诠释为「配置组件」或「配置单元」。(有关「配置项」的定义，请参见词汇) 基线是配置项持续演进的稳定基础。举例来说，已审核的产品说明是一个基线，它包含需求、需求追溯表、设计、特定专业项目及使用者文档，成为内部一致的版本。当基线开发完成，就会纳入配置管理系统。基线的变更与自配置管理系统所建造的工作产品的发布，通过配置管理的配置控制、变更管理及配置审计等功能，进行有系统的控制与监督。本过程域不只适用于项目的配置管理，也适用于组织工作产品(如标准、程序及复用链接库)的配置管理。配置管理着重于工作产品(包含已交付的系统)在管理面和技术面的严格控制。配置管理过程域涵盖执行配置管理功能的实践，也适用于已纳入配置管理的所有工作产品。相关过程域有关开发计划和工作拆分结构，请参考项目策划过程域，以获得更多信息。工作拆分结构可用于有关绩效分析和纠正措施，请参考项目监控过程域，以获得更多信息。特定目标及实践摘要 SG 1 建立基线 SP 识别配置项 SP 建立配置管理系统 SP 建立或发布基线 SG 2 追踪并控制变更 SP 追踪变更申请 SP 控制配置项 SG 3 建立完整性 SP 建立配置管理纪录 SP 实施配置审计各目标的特定实践 SG 1 建立基线建立由已识别的工作产品所组成的基线本特定目标涵盖用以建立基线的特定实践。「追踪并控制变更」特定目标所涵盖的特定实践用以维护基线，而「建立完整性」特定目标的特定实践则用以记录和审计基线的完整性。 SP 识别配置项识别将纳入配置管理的配置项、组件及相关的工作产品。配置识别为下列项目的选择、建立及说明： • 交付客户的产品 • 指定的内部工作产品 • 取得的产品 • 工具及其它项目工作环境的资本资产 • 其它用以产生或说明这些工作产品的项目纳入配置管理的项目，包含用于说明工作产品需求的规格和接口文档；也包含其它的文档，例如：测试结果。可依据它对于定义产品的重要性，来决定是否纳入配置管理。「配置项」是被指定要纳入配置管理的物理，它可能包含组成某基线的数个相关工作产品。这种逻辑上的编组，提供较容易的识别和存取控制。应根据规划时所定的准则，选取需纳入配置管理的工作产品。典型的工作产品 1. 已识别的配置项子实践 1. 根据文档化的准则，选择配置项和组成这些项目的工作产品。在适当的工作产品层次中，选择配置项的准则，举例如下： • 可能被两个(含)以上小组共享的工作产品 • 会随着时间而变更的工作产品，其变更原因可能是发生错误或变更需求 • 数个相互依存的工作产品，当其中一个改变时，将会影响到其它的工作产品 •对项目具有极高重要性的工作产品可组成配置项的工作产品，举例如下： • 过程说明 • 需求 • 设计 • 测试计划和程序 • 测试结果 • 接口说明 • 图表 • 原始码 • 工具(如编译器) 2. 指定每个配置项唯一的识别码。 3. 识别每个配置项的重要特性。配置项的特性，包含作者、文档格式或档案格式，以及程序代码所使用的语言。 4. 识别每个配置项纳入配置管理的时间点。何时将工作产品纳入配置管理的准则，举例如下： • 在项目生命周期的各阶段 • 当工作产品准备好可进行测试的时候 • 工作产品需要某种程度控制的时候 • 成本和进度的界限 • 客户需求 5. 识别每个配置项的负责人。 SP 建立配置管理系统建立并维护一个配置管理与变更管理的系统，以便控制工作产品。配置管理系统包含：存储媒体、运作程序，以及存取配置系统的工具。变更管理系统包含：存储媒体、运作程序，以及记录和存取变更申请的工具。典型的工作产品 1. 配置管理系统，内含被控制的工作产品 2. 配置管理系统的存取控编程序 3. 变更申请数据库子实践 1. 在配置管理中，建立多重控制等级的机制。通常会根据项目目标，风险及/或资源来选择控制等级。控制等级可能因项目生命周期、开发时的系统种类及特定项目需求而异。控制等级，举例如下： • 建立-由作者控制 • 工程-当变更发生时，通知相关的干系人 • 开发-由低层配置控制委员会控制 • 正式-由与客户参与的高层配置控制委员会控制控制等级可从简易追踪开发中配置项变更的非正式控制到正式配置管理过程变更基线的正式配置控制。 2. 在配置管理系统中，存取配置项。配置管理系统的举例如下： • 动态(或作者)的系统，包含目前正在产生或修订的组件。它们在开发者的工作场所，而且由作者所控制。属于动态系统的配置项，由版本控制来控制。 • 主要(或受控制)的系统，包含目前的基线和基线的变更。属于主要系统的配置项，完全由本过程域的配置管理来控制。 •稳定的系统，包含已发布使用之各种基线的保存档。稳定的系统完全由本过程域的配置管理来控制。 3. 在配置管理系统的不同程度控制机制下，分享和移转配置项。 4. 存储和复原已归档保存的配置项版本。 5. 存储、更新及取出配置管理纪录。 6. 从配置管理系统中，产生配置管理报告。 7. 保存配置管理系统的内容。配置管理系统的保存功能，举例如下： • 配置管理档案的备份和复原 • 配置管理档案的归档保存 • 配置管理错误的复原 8. 必要时，修订配置管理结构。 SP 建立或发布基线建立或发布供内部使用和交付给客户的基线。基线是一组经正式审查和同意的规格或工作产品，也是未来开发或交付的基础，而且只能通过变更控制程序才能改变此基线。基线表示对一个或多个配置项及相关项目之识别的指定。当产品演进中，有几个基线可用来控制产品的开发与测试。系统工程适用基线共同的地方包含系统层次的需求、系统组件层次的设计需求，以及开发结束/制造前的产品定义。这些被称为「功能基线(functional baseline)」、「配置基线(allocated baseline)」及「产品基线(product baseline)」。软件工程适用软件基线可以是已指定唯一识别码的一组需求、设计、程序代码档案以及相关的可执行码、版次档和使用者文档(相关的项目)。典型的工作产品 1. 基线 2. 基线说明子实践 1. 在建立或发布配置项的基线之前，取得配置控制委员会的授权。 2. 只有来自配置管理系统的配置项，才能建立基线或发布基线。 3. 记录基线所含的配置项。 4. 使目前最新的基线，随时可供使用。 SG 2 追踪并控制变更跟踪并控制已纳入配置管理工作产品的变更本特定目标所涵盖的特定实践用来维护基线，这些基线是由「建立基线」特定目标所涵盖的特定实践所建立。 SP 追踪变更申请追踪配置项的变更申请。变更申请不只用于新的需求或需求的变更，也可用于工作产品的故障或缺陷。分析变更申请，以决定此变更对工作产品、相关工作产品、进度及成本的影响。典型的工作产品 1. 变更申请子实践 1. 启动变更申请，并记录于变更申请数据库。 2. 分析变更建议和所需的修改所造成的影响。藉由活动来评估变更，以便确保此变更与所有的技术需求和项目需求的一致性。评估变更所造成的影响，也应考虑目前项目或合同之外的需求。如配置项被数个产品所使用，则该配置项的改变或许可以解决目前的问题，但也可能造成其它应用上的新问题。 3. 如果变更申请会影响其它基线，应与相关的干系人一起审查这些变更申请，并取得他们的同意。执行变更申请审查时，让合适的人参与决定，并记录每一变更申请的处理方法和决策理由，包含成功的准则、简单的行动计划及变更是否符合需要等。执行处理方法所提的行动，并将结果告知相关的干系人。 4. 追踪变更申请的状态直到关闭。系统的变更申请，须用有效和实时的方式处理。一旦开始处理变更申请，重要的是，当已批准的行动已产生作用，应尽速将之关闭。若行动一直不关闭，结果将不只是更长的待处理状态清单，它可能导致成本和困扰的增加。 SP 控制配置项控制配置项的变更。需要控制工作产品基线的配置，控制包含追踪每一配置项的配置、必要时批准新的配置，并更新基线。典型的工作产品 1. 配置项的修订历史纪录 2. 基线的归档(archives) 子实践 1. 在整个产品生命周期，控制配置项的变更。 2. 变更后的配置项，在纳入配置管理系统之前，必须获得适当的授权。举例来说，授权可来自配置控制委员会、项目经理或客户。 3. 针对同时受某些变更影响的配置项，在签入或签出配置管理系统时，必须设法维护这些配置项的正确性和完整性。签入和签出的步骤，举例如下： • 确认这些修订已取得授权 • 更新配置项 • 将旧基线归档保存，并取出新基线 4. 执行审查，以确保该变更没有对基线造成意料外的影响。例如：确保变更没有影响系统的安全及(或)机密。 5. 适当记录配置项的变更和变更的理由。如果接受对工作产品的变更建议，则须识别完成修改工作产品及其它受影响部分的进度表。配置控制机制可以定义成多种变更类别。例如：有些不影响其它组件的组件变更，其批准过程可以较简化。已变更的配置项，须经审查和批准后才能发布。若未经发布，变更并不算正式生效。 SG 3 建立完整性 Integrity of baselines is established and maintained. 「建立基线」特定目标的过程用于建立基线，「追踪并控制变更」特定目标的过程用于维护基线，而本特定目标所涵盖的特定实践则用以记录和审计基线的完整性。 SP 建立配置管理记录建立并维护描述配置项的记录。典型的工作产品 1. 配置项的修订历史记录 2. 变更过程的记录 3. 变更申请的备份 4. 配置项的状态 5. 不同基线间的差异子实践 1. 详细记录配置管理活动，使他人知道每个配置项的内容和状态，并能复原配置项的先前版本。 2. 确保相关的干系人，能存取和了解配置项的配置状态。沟通配置状态信息的活动，举例如下： • 提供存取权限给经授权的最终使用者 • 备妥基线的备份，以供经授权的最终使用者使用 3. 标示基线的最新版本。 4. 识别组成某基线的配置项的版本。 5. 描述前后版本基线间的差异。 6. 必要时修订配置项的状态和历史纪录(指变更及其它行动)。 SP 实施配置审计实施配置审计以维护配置基线的完整性。配置审计确认最终的基线和文档有遵照特定标准或需求，并适当记录审计结果。(有关「配置审计」的定义，请参照词汇。) 审计种类举例如下： • 功能配置审计(FCA)-审计的执行是在验证配置项的测试功能特征，达到功能基线文档所指定的需求，而且操作及支持文档已完整及满足。 • 物理配置审计(PCA)-审计的执行是在验证建置的配置项遵照技术文档的定义。 • 配置管理审计-审计的执行是在确认配置管理纪录及配置项的完整性、一致性及正确性。典型的工作产品 1. 配置审计结果 2. 行动项目子实践 1. 评价基线的完整性。 2. 确认配置管理纪录已正确识别配置项。 3. 审查配置管理系统中，配置项的结构和一致性。 4. 确定配置管理系统中，配置项的完整性和正确性。依据计划中所述的需求和已批准之变更申请的处理为基础，来判断内容的完整性和正确性。 5. 确定符合适用的配置管理标准和程序。 6. 追踪审计的行动项目直到关闭。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施配置管理过程的特定实践，以开发工作产品并提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织方针，以规划和执行配置管理过程。详细说明：本方针建立组织对下列活动的期望：建立和维护基线；追溯和控制工作产品的变更(在配置管理下)；以及建立和维护基线的完整性。 GP 规划过程建立并维护执行配置管理过程的计划。详细说明：执行配置管理过程的计划可包含于项目计划或被项目计划所参考，项目计划在项目策划过程域中描述。 GP 提供资源提供充足的资源，执行配置管理过程、开发工作产品及提供过程服务。详细说明：可用于本过程域的资源(工具)，举例如下： • 配置管理工具 • 数据管理工具 • 归档及复制工具 • 数据库程序 GP 分配责任分配配置管理过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持配置管理过程。详细说明：培训的主题，举例如下： • 配置管理人员的角色、责任及权力 • 配置管理标准、程序及方法 • 配置数据库系统 GP 管理配置将指定的配置管理过程工作产品，纳入适当等级的控制。详细说明：请参照表的通用目标和通用实践，以获得更多关于GP 的信息及配置管理过程域的关联性。纳入控制的工作产品，举例如下： • 存取清单 • 变更状态报告 • 变更申请数据库 • 配置控制委员会会议纪录 • 已归档保存的基线 GP 识别并纳入相关的干系人依计划识别并纳入配置管理过程相关的干系人。详细说明：干系人参与的活动，举例如下： • 建立基线 • 审查配置管理系统报告，并解决问题 • 评价变更配置项的影响 • 执行配置审计 • 审查配置管理审计的结果 GP 监控过程依本过程的执行计划，监控配置管理过程，并采取适当的纠正措施。详细说明：用于监控的度量和工作产品，举例如下： • 配置项变更的数量 • 配置审计的执行数量 • 配置控制委员会或审计活动进度 GP 客观评价遵循程度依本过程的说明、标准及程序，客观评估配置管理过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立基线 • 追踪并控制变更 • 建立并维护基线的完整性审查的工作产品，举例如下： • 基线的保存档 • 变更申请数据库 GP 与高层管理人员审查各状况与高层管理人员审查配置管理过程的活动、状况及结果，并解决问题。仅适用于阶段式表述 GG 3 及其实践不应用于成熟度第二级评等，但应用于成熟度第三级和更高级评等。仅适用于连续式/阶段式表述第3－5级将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义配置管理过程的说明。 GP 收集改进信息收集由配置管理过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息的例子，包括如下： • 配置项目的状态趋势 • 配置审计结果 • 变更申请报告仅适用于连续式表述 GG 4 制度化已量化管理过程 GP 建立过程的量化目标建立并维护配置管理过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定配置管理过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保供配置管理过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正配置管理过程之缺陷与其它问题的根本原因。决策分析与解决方案（DAR 3级）成熟度第三级的支持类过程域目的决策分析与解决方案(Decision Analysis and Resolution, DAR)的目的，在于利用正式的评估过程，依据已建立的准则评估各种已识别的备选方案，以分析可能的决策。简介决策分析与解决方案过程域包含建立指导，以决定什么问题需要正式评估过程，然后引用正式评估过程解决问题。正式评估过程为一结构化的方法，依据已建立的准则评估备选解决方案，并决定推荐的方案来解决问题。正式评估过程包含下列的活动： • 建立评估备选方案的准则 • 识别备选解决方案 • 选择评估备选方案的方法 • 使用已建立的准则与方法，评估备选解决方案 • 依据评估准则，从备选方案中选择建议方案本文中要表达「解决问题的备选解决方案」时，将使用「备选解决方案(alternative solutions)」或「备选方案(alternatives)」。正式评估过程是减少决策的主观性，并有较高的可能性选择一符合相关干系人多样需求的解决方案。本过程域主要应用于选定技术的重要事项，正式评估过程也可应用于许多非技术的问题，特别当项目开始规划，问题有多种备选解决方案与评估准则时，适合使用正式评估过程。设备或软件的替代方案研究是正式评估过程的典型范例。在项目策划期间，识别哪些特定问题需要正式评估过程。典型的问题包括：选择架构或设计的备选方案、使用复用或现成品组件、选择供应商、工程支持环境或相关工具、测试环境、交付的备选方案以及后勤和生产。正式评估过程也可用于解决自行开发或采购的决策、制造过程的开发、配销位置的选择及其它决策。建立指导，以决定何时使用正式评估过程来解决非规划的问题。当问题涉及中高风险或问题会影响达成项目目标的能力时，指导通常建议使用正式评估过程。正式评估过程有不同的形式、准则类型及使用的方法，例如：较不正式的决策，其分析可能花费几小时、只使用几条准则(如有效性和建置的成本)，以及产生一两页报告；但是较正式的决策可能需要个别计划、几个月的工作量、制订与批准准则的会议、模拟、原型、试用及大量的文档。正式评估过程可使用量化或非量化的准则。量化准则使用权重以反映准则的相对重要性；非量化准则使用较主观的等级划分(如：高、中、低)。较正式的决策可能要求完整的替代方案研究。正式评估过程识别与评估各种备选解决方案。选定最后方案的过程，可能包括反复的识别与评估活动。在评估期间，已识别的备选方案，可能部分的被组合、新出现的技术也可能改变备选方案，而供应商的经营情况在评估期间也可能改变。所建议的备选方案伴随选定之方法、准则、备选方案及建议理由的文档，此文档将分送给相关干系人，并提供正式评估过程的纪录及理由，它对其他未来遇到相似问题的项目是有参考的。整个项目中，部分决策涉及正式评估过程，其它决策则否，就像之前所述，建立指导以决定哪些问题是属于正式评估过程。相关过程域有关一般的项目策划，请参考项目策划过程域，以获得更多信息。有关建立项目已定义过程，请参考集成的项目管理过程域，以获得更多信息。项目已定义过程包含每一选定问题的正式评估过程，并纳入对无法预知的问题，引用正式评估过程的使用指导。有关识别风险及降低风险，请参考风险管理过程域，以获得更多信息。正式评估过程经常用以解决已识别的中、高风险问题。选定的解决方案通常会冲击风险降低计划。特定目标及实践摘要 SG 1 评估备选方案 SP 建立决策分析指导 SP 建立评估准则 SP 识别备选解决方案 SP 选择评估方法 SP 评估备选方案 SP 选择解决方案各目标的特定实践 SG 1 评估备选方案使用已建立的准则，根据评估的备选方案做出决策。在产品或项目的任何时间点都可能识别出需正式评估过程的问题。目标为尽早识别问题，使得有较充裕时间解决该问题。 SP 建立决策分析指导建立并维护指导，以决定哪些问题须经正式评估过程。不是每个决策都足够重要到需要正式评估过程。若没有明确的指导，在重要与不重要之间的选择会不清楚。一个决策重要与否，与项目及环境相关，并由已建立的指导加以决定。用来决定何时需要正式评估过程的典型指导，包含如下： • 当某决策与经评价之中高度风险主题有直接关系时 • 当某决策与在配置管理下的工作产品的变更有关时 • 当某决策会导致进度延误超过某一比例或特定的时间时 • 当某决策影响达成项目目标的能力时 • 当正式评估过程的成本与决策冲击相比较是合理时 • 当招标中有合法契约时有关决定哪些问题属于中高风险，请参考风险管理过程域，以获得更多信息。使用正式评估过程的时机，举例如下： • 在材料采购上，当20%材料零件耗用80%材料成本时 • 在设计实现决策上，当技术设计失误可能酿成巨灾时(例如：飞行项目的安全) • 各种可能重大降低设计风险、工程变动、周期进度、反应时间及生产成本的决策(例如：在公布工程绘图与生产建造前，使用印刷方法评价外型与符合的能力。) 典型的工作产品 1. 何时引用正式评估过程的指导子实践 1. 建立指导。 2. 适当时，将指导的使用并入已定义过程中。有关建立项目已定义过程，请参考集成的项目管理过程域，以获得更多信息。 SP 建立评估准则建立并维护用来评估备选方案的评估准则及其相对排序。评估准则提供评估备选解决方案的基础。将准则排序，以使得排序最高的准则代表对评估有最大的影响。 CMMI 模型的许多其它过程域参考本过程域，正式评估过程也在许多地方使用。因此，在某些情况下你会发现准则已经定义于其它的过程中。本特定实践不建议再次开发相同的准则。记录评估准则，以避免后续决策猜疑的可能性或忘掉作成该决策的原因，依据已明确定义及建立的准则所作的决策，可排除干系人的认同障碍。典型的工作产品 1. 评估准则的纪录 2. 准则重要性排序子实践 1. 定义评估备选解决方案的准则。准则应可追溯到需求、场景、经营项目假设、经营目标或其它已记录的来源。考量的准则类型包括如下： • 技术限制 • 环境冲击 • 风险 • 所有权及生命周期成本 2. 定义评估准则分级的范围与等级。可运用非数字的值或将评估参数和权重数值结合的公式，建立评估准则之相对重要性的等级。 3. 将准则排序。依据定义的范围与等级将准则排序，以反映需求、目标及相关干系人的优先级。 4. 评估准则及其相对的重要性。 5. 渐进开发评估准则以改进其有效性。 6. 记录选用及舍弃评估准则的理由。记录选用的准则及理由，以证明解决方案的正当性，或作为未来参考与使用。 SP 识别备选解决方案识别解决问题的备选解决方案。尽可能请干系人提出广泛的备选方案，干系人的技能和背景皆不相同，其建议有助于识别和解决各种假设、限制及偏见。头脑风暴会议通过快速互动与反馈可刺激有创意的备选方案。充分的备选方案可能也不足提供分析，当分析进行时，其它方案应加到可能的候选解决方案清单内，在决策分析与解决方案过程初期，考量与产生多样的备选方案，可增加做成可接受的决策的可能性，且该决策的结果较易理解。典型的工作产品 1. 已识别的备选方案子实践 1. 执行文献搜索。文献查询可发觉组织内外曾做过的事情，可提供对下列有更深的了解：问题、考虑的备选方案、执行障碍、既有的替代方案研究及类似决策的学习心得。 2. 除了问题的解决方案之外，识别纳入考量的备选解决方案。评估准则是识别备选方案的有效起点。评估准则识别相关干系人的优先级及技术、后勤或其它挑战的重要性。组合既有方案的关键属性可能产生额外的方案，且有时侯是更具说服力的方案。诱导相关干系人提出备选方案。可有效地使用头脑风暴、访谈及工作小组等方式以发现备选方案。 3. 记录提议的方案。 SP 选择评估方法选择评估方法。依据已建立的准则，用以评估备选方案的方法，其范围从模拟到使用机率和决策理论，这些方法必须小心选择。方法的详细程度应与成本、进度、绩效及风险的冲击相称。虽然许多问题只需一种评估方法，但有些问题可能需要多种方法。举例来说，模拟可加强替代方案研究，以决定那个设计备选方案最符合特定的准则。典型的工作产品 1. 已选择的评估方法子实践 1. 以分析决策的目的与可用以支持该方法之信息的可用性为基础，来选择方法。例如：在需求定义不明确的情况下，用来评估技术解决方案的方法，可能会与在需求定义明确的情况有所不同。典型的评估方法包含下列： • 模型与仿真 • 工程研究 • 编程研究 • 成本研究 • 经营机会研究 • 调查 • 依据经验与原型加以推断 • 使用者审查与评论 • 测试 • 一个或一组专家的判断(例：Delphi 方法) 2. 依据专注于手边的问题，而不受无关问题过度影响的能力，选择评估方法。模拟的结果，会被解决方案中没有直接相关问题的随意活动所曲解。 3. 决定支持评估方法所需的度量。考量对成本、进度、绩效及风险的冲击。 SP 评估备选方案使用已建立的准则与方法，评估备选方案。评估备选方案包括：分析、讨论及审查。反复的分析有时是必要的。可能需要支持分析、实验、原型、演练或模拟，以支持评分及结论。准则的相对重要性经常是不精确的，且解决方案的整体效果往往在执行相关分析工作之后才会明显。若各备选方案的评分结果差距不大，则可能无法从备选解决方案中明确选出最佳者。应鼓励对准则及假设条件的挑战。典型的工作产品 1. 评估结果子实践 1. 使用已建立的评估准则与选定的方法，评估提议的备选解决方案。 2. 评估各种评估准则的假设条件，以及支持该假设条件的各种证据。 3. 评估是否有价值观念的不确定性影响备选解决方案的评估，并给予适当的解决。例如：假若分数可在两数值中改变，该差异是否足以区分最后方案？分数的差异是否代表高风险？为克服这些疑虑，可进行一些模拟、执行进一步的研究或修改评估准则。 4. 必要时，执行模拟、塑模、原型及试行，以测试评估准则、方法及备选解决方案。未经试验的准则，其相对的重要性以及支持数据或功能，可能造成对解决方案实用性的质疑。准则及其相对的优先级与规模大小，可试用于一些备选方案以进行测试。试用这些评估准则，使准则得以在解决方案中进行渐进的影响性评估。若试用显现问题，则应考虑不同的准则或备选方案，以避免偏差。 5. 若建议的备选解决方案无法通过测试时，考量新的备选解决方案、准则及方法。并重复评估活动，直到备选方案能通过测试。 6. 记录评估结果。记录增加新备选方案或方法、准则变动的理由，以及中间评估的结果。 SP 选择解决方案依据评估准则，从备选方案中选择解决方案。选择解决方案包含对于备选方案评估结果，赋予权重。必须评价执行解决方案有关的风险。典型的工作产品 1. 解决重大问题的建议解决方案子实践 1. 评价执行建议解决方案相关的风险。有关如何识别与管理风险，请参考风险管理过程域，以获得更多信息。决策经常在信息不完备的情况下进行，因信息不完备而制定的决策可能有实质的风险。当决策必须依照特定的进度、时间及资源进行时，可能无法收集完备的信息。因此，日后可能需要重新分析在信息不完备时所制定的危险决策。应监督已识别的风险。 2. 记录建议解决方案的结果及理由。记录选择某解决方案与拒绝另一解决方案的理由是很重要的。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施决策分析与解决方案过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义的过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织方针，以规划和执行决策分析与解决方案过程。详细说明：本方针建立组织的期望，使用正式评估过程，分析可能的决策以进行决策。正式评估过程系依已建立的准则评估已识别的备选方案。本方针也应提供哪些决策需要正式评估过程的指导。 GP 规划过程建立并维护执行决策分析与解决方案过程的计划。详细说明：项目计划通常包含(或参考)执行决策分析与解决方案过程的计划，项目计划在项目策划过程域中说明。 GP 提供资源提供充足的资源，以执行决策分析与解决方案过程、开发工作产品及提供过程服务。详细说明：提供的资源包含下列工具： • 模拟及塑模工具 • 原型工具 • 执行调查的工具 GP 分配责任分配决策分析与解决方案的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员需要培训人员，以执行或支持决策分析与解决方案过程。详细说明：培训的主题，举例如下： • 正式决策分析 • 依准则评估备选解决方案的方法 GP 管理配置将指定的决策分析与解决方案过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 何时引用正式评估过程的指导 • 包含建议解决方案的评估报告 GP 识别并纳入相关的干系人依计划识别并纳入决策分析与解决方案过程相关的干系人。详细说明：干系人参与的活动，举例如下： • 建立哪些问题须经正式评估过程的指导 • 建立评估准则 • 识别并评估备选方案 • 选择评估方法 • 选择解决方案 GP 监控过程依本过程的执行计划，监控决策分析与解决方案过程，并采取适当的纠正措施。详细说明：用于监控的度量与工作产品，举例如下： • 使用正式评估过程的本益比 • 交易研究的执行编程 GP 客观评价遵循程度依据过程说明、标准及程序，客观地评估决策分析与解决方案过程、工作产品及过程服务，并解决不符合的情况。详细说明：审查的活动，举例如下： • 使用已建立的准则与方法，评估备选方案审查的工作产品，举例如下： • 何时引用正式评估过程的指导 • 包含建议解决方案的评估报告 GP 与高层管理人员审查各状况与高层管理人员审查决策分析与解决方案过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义决策分析与解决方案过程的说明。 GP 收集改进信息收集由规划并执行决策分析与解决方案过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 考虑备选方案的数目 • 评估结果 • 重要问题的建议解决方案仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护决策分析与解决方案过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定决策分析与解决方案过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保决策分析与解决方案过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正决策分析与解决方案过程之缺陷与其它问题的根本原因。集成的项目管理 + IPPD （IPM 3级）成熟度第三级的项目管理类过程域目的简介集成的项目管理(Integrated Project Management, IPM)的目的，是依据组织标准过程所定义而成之集成的已定义过程，来建立和管理项目，以及相关的干系人的参与。 IPPD 补充对于集成的产品与过程开发(IPPD)，集成的项目管理(IPPD)也涵盖建立项目共同愿景，以及建立集成团队来实现项目的目标。集成的项目管理包含下列事项： • 定义组织标准过程，以建立项目已定义过程。 • 使用项目已定义过程管理项目。 • 根据组织工作环境标准，建立项目的工作环境。 • 使用组织过程资产，并对其产生贡献。 • 在产品的开发过程中，使相关干系人所关心的事均被识别、考虑及适当的处理。 • 确保相关干系人以协调及实时的态度执行工作：(1)处理产品与产品组件需求、计划、目标、问题及风险；(2)实现他们的承诺；以及(3)识别、追踪及解决问题。 IPPD 补充集成的项目管理(IPPD)包含下列事项： •由项目建立及为项目建立的共同愿景。 •建立负有达成项目目标任务的集成团队。由组织标准过程调整而来之集成及定义的过程称为项目已定义过程。项目工作量、成本、进度、人员、风险及其它因素的管理，与项目已定义过程的工作项目息息相关。项目已定义过程的实施与管理，通常描述于项目计划中，而某些活动可能包含于影响项目的其它子计划，诸如质量保证计划、风险管理策略及配置管理计划。因为每个项目的已定义过程均从组织标准过程定义而来，项目间的相异性通常会减少，且项目可以更容易分享过程资产、数据及学习心得。此过程域同时也规范所有与项目相关活动的协调，举例如下： • 开发活动，例如：需求开发、设计及验证 • 服务活动(例如，交付、服务台、营运及客户联络) • 采购活动(例如，招标、合同监控及移转至营运) • 支持活动(例如：配置管理、文档、营销及培训) 规划与管理项目内部或外部相关干系人间的工作接口与互动，以确保整体项目的质量与产品的完整性。定义项目已定义过程与项目计划时，相关的干系人可适当参与。与这些相关干系人定期的进行审查与交流，并适当的注意协调的问题，以确保参与项目的每个人，适当的了解项目的状态、计划及活动。(相关干系人的定义，请参考词汇)定义项目已定义过程时，依需要建立正式的接口，以确保适当的协调与合作。本过程域适用于任何组织架构，包括如线性组织、矩阵组织或集成团队。此术语应该在合适的组织架构中，适当地加以解释。相关过程域有关规划项目，请参考项目策划过程域，以获得更多信息。有关监控项目，请参考项目监控过程域，以获得更多信息。有关识别干系人及其适当的参与项目，请参考项目策划过程域，以获得更多信息。有关同行评审，请参考验证过程域，以获得更多信息。有关组织过程资产及工作环境标准，请参考组织过程定义过程域，以获得更多信息。有关定义一个度量与分析的过程，请参考度量与分析过程域，以获得更多信息。 IPPD 补充有关创立组织规则及指导，请参考组织过程定义+IPPD 过程域，以获得更多信息。特定目标及实践摘要 SG 1 使用项目的已定义过程 SP 建立项目的已定义过程 SP 使用组织过程资产规划项目活动 SP 建立项目工作环境 SP 集成计划 SP 使用集成计划管理项目 SP 贡献组织过程资产 SG 2 与干系人协调与合作 SP 管理干系人参与 SP 管理相互依存关系 SP 解决协调问题 IPPD 补充 SG 3 实行IPPD 原则 SP 建立项目共同愿景 SP 建立集成团队架构 SP 配置需求给集成团队 SP 建立集成团队 SP 确保接口团队间的合作各目标的特定实践 SG 1 使用项目的已定义过程项目执行须使用组织标准过程所识别的流程。项目已定义过程必须包含组织标准过程，该标准过程说明采购或开发与维护产品所需的所有过程。产品相关的生命周期过程，如制造与支持过程，与产品同步开发。 SP 建立项目的已定义过程有关组织过程资产库，请参考组织过程定义过程域，以获得更多信息。有关组织过程需求与目标，以及部署组织的标准过程至项目，请参考组织过程焦点过程域，以获得更多信息。项目已定义过程由经过定义的过程所组成，提供项目形成一个集成的、连贯的生命周期。 IPPD 补充项目的已定义过程以下列过程支持IPPD •使集成的项目管理环境在组合或分布式团队时，更经得起考验。 •选择项目的集成团队架构 •分配有限的人力资源 •建立跨集成团队之间的沟通项目已定义过程应该满足项目合同与经营上的需求、机会及限制，其设计是要提供最适合项目的需求。项目已定义过程以下列要素为基础： • 客户需求 • 产品与产品组件需求 • 承诺 • 组织过程需求与目标 • 组织标准过程及定义指导 • 运作环境 • 经营环境在项目一开始时，建立项目的已定义过程，有助于确保项目人员及干系人执行一套有效建立项目初步需求和计划所需的活动。当项目进行时，项目已定义过程会更详细说明并修订，更能符合项目需求及组织过程需要及目标。且当组织标准过程改变时，项目已定义过程可能需要随着修订。典型的工作产品 1. 项目已定义过程子实践 1. 从组织过程资产，挑选一个生命周期模型。会影响生命周期模型选择的项目特性，举例如下： • 项目大小 • 人员实施过程的经验及熟悉程度 • 周期时间及可接受的缺陷等级等限制 2. 从组织标准过程，挑选最适合项目需要的标准过程。 3. 依据定义指导，定义组织标准过程及其它的组织过程资产，产生项目的已定义过程。有时候，可用的生命周期模型与标准过程不足以符合特定项目的需求，或项目不能产出需要的工作产品或度量。在此情况下，项目须征求偏离组织需求的批准。豁免权是为了这样的目的而提供。 4. 适当的使用组织过程资产库的其它成果。其它成果可能包括如下事项： • 学习心得文档 • 样板 • 范例文档 • 估计模型 5. 记录项目的已定义过程。项目已定义过程，涵盖项目所有的工程、管理及支持活动，以及与干系人间的接口。项目活动，举例如下： • 项目策划 • 项目监控 • 需求开发 • 需求管理 • 供应商管理 • 配置管理 • 质量保证 • 风险管理 • 决策分析与解决方案 • 产品开发与支持 • 招标 6. 对项目已定义过程，进行同行评审。有关进行同行评审，请参考验证过程域，以获得更多信息。 7. 必要时，修订项目的已定义过程。 SP 使用组织过程资产规划项目活动有关组织过程资产与组织度量资产库，请参考组织过程定义过程域，以获得更多信息。典型的工作产品 1. 项目的估计值 2. 项目计划子实践 1. 以项目已定义过程的工作项目与工作产品为基础，进行估计及规划活动。了解项目已定义过程不同工作项目与工作产品之间的关系，以及了解干系人所扮演的角色，是开发实际计划的基础。 2. 使用组织度量资产库来估计项目的规划参数。估计通常包含下列事项： • 使用来自本项目或类似项目之适当的历史资料 • 说明并记录现行项目与引用历史资料之项目间的相似与不同处 • 独立验证历史资料 • 记录用以选择历史数据的原因、假设及理由考量相似与不同处的参数，举例如下： • 工作产品与工作项目属性 • 应用领域 • 设计方法 • 运作环境 • 人员经验组织度量资产库所包括的数据，举例如下： • 工作产品的规模大小或其它工作产品的属性值 • 工作量 • 成本 • 进度 • 人员配置 • 缺陷 • 响应时间 • 服务能量 • 供应商绩效 SP 建立项目工作环境根据组织工作环境标准，建立与维护项目的工作环境。一个项目的适当工作环境包括设施、工具与设备的基础建设，人员用以有效执行工作，以支持企业与项目目标。工作环境及其组件维持在组织工作环境标准中所指定之绩效与可靠度水平。当需要时，项目的工作环境或部分组件可以内部自行开发或购自外部的供应商。 IPPD 补充有效的工作环境参考项目利用IPPD，使用组合或分布式集成团队去执行工作。双向沟通媒体应该让项目所有相关干系人易于使用。项目工作环境可能包含产品集成、验证与确认的环境，或其可能为分立环境。有关组织过程资产，尤其是组织度量资产库，请参考组织过程定义过程域，以获得更多信息。有关建立及维护项目产品集成环境，请参考产品集成过程域的建立产品集成环境特定实践，以获得更多信息。有关建立及维护项目验证环境，请参考验证过程域的建立验证环境特定实践，以获得更多信息。有关建立及维护项目的确认环境，请参考确认过程域的建立确认环境实践，以获得更多信息。典型的工作产品 1. 项目的设备及工具 2. 项目工作环境的安装、营运及维护手册 3. 使用者调查与结果 4. 使用、绩效及维护纪录 5. 项目工作环境的支持服务子实践 1. 规划、设计及安装项目的工作环境。如同其它产品一样，项目工作环境的关键点是需求导向。以任何其它产品开发相同的严格度探索工作环境的功能性及操作性。绩效改进、成本及风险间可能须取舍，个别举例如下： • 绩效改进可能包括及时沟通、安全、保密及可维护性。 • 成本可能包括资本费用、教育培训及支持架构、现有环境的拆卸及处置，以及环境的营运及维护。 •风险可能包括工作过程及项目瓦解。设备及工具，举例如下： • 办公软件 • 决策支持软件 • 项目管理工具 • 需求管理工具，设计工具 • 配置管理工具 • 评估工具 • 测试及（或）评估设备 2. 对项目工作环境提供持续的维护及营运支持。工作环境的维护与支持可以用组织内部能力或外聘来达成。维护及支持方法举例如下： • 聘用人员来执行维护及支持 • 培训人员来执行维护及支持 • 维护及支持外包 • 开发所选用工具的专家使用者 3. 维护项目工作环境构成组件的资格。组件包括软件、数据库、硬件、工具、测试设备，以及适当的文档。软件资格包括适当的检定，硬件及测试工具资格则包括分类与调校纪录以及分类标准的可追溯性。 4. 定期的审查工作环境符合项目需求及支持合作的程度，并适时采取行动。可能采取的行动举例如下： • 增加新的工具 • 采购额外的网络、设备、教育培训及支持 SP 集成计划有关建立及维护项目计划，请参考项目策划过程域，以获得更多信息。有关组织过程资产，特别是组织度量库，请参考组织过程定义过程域，以获得更多信息。有关识别度量及度量活动并使用分析技术，请参考度量与分析过程域，以获得更多信息。有关定义及分析风险，请参考风险管理过程域，以获得更多信息。有关组织过程需要与目标，请参考组织过程焦点过程域，以获得更多信息。本特定实践延伸为建立及维护项目计划的特定实践，以陈述额外的规划活动，例如纳入项目已定义过程、与相关干系人协调、使用项目过程资产、纳入同行评审计划，以及建立工作目标性的入口及出口准则。项目计划的开发应适当说明组织、客户、供应商及最终使用者之当前和期望的需要、目标与需求。 IPPD 补充集成团队的计划包括在本集成计划中。如果要部署一个复杂、多层次的集成团队架构，开发完整的项目计划与及项目已定义过程可能需要反复多次的努力。典型工作产品 1. 集成计划子实践 1. 集成其它影响项目的计划。影响项目的其它计划可能包括： • 质量保证计划 • 配置管理计划 • 风险管理策略 • 文档管理计划 2. 将用来管理项目的度量定义与度量活动，纳入项目计划。被纳入的度量，举例如下： • 组织的共性度量 • 附加的项目特定度量 3. 识别并分析产品与项目接口的风险。产品与项目接口的风险，举例如下： • 不完整的界面描述 • 无法取得工具或测试设备 • 无法取得的现成品组件 • 不适当或无效的团队接口 4. 安排工作顺序时，考虑关键性开发因素与项目风险。进度安排时的考量因素，举例如下： • 工作项目的规模大小与复杂度 • 集成与测试问题 • 客户与最终使用者的需求 • 关键资源的可用性 • 关键人物的可用性 5. 将对工作产品执行同行评审的已定义过程，纳入计划。有关同行评审，请参考验证过程域，以获得更多信息。 6. 在项目的培训计划中，纳入执行项目已定义过程所需的培训。这项工作通常包含与提供支持的组织培训团队协商。 7. 建立客观的入口与出口准则，以授权工作拆分结构(WBS)所描述之工作的启动与完成。有关工作拆分结构，请参考项目策划过程域，以获得更多信息。 8. 确保项目计划与相关干系人的计划相容。通常会审查计划与计划变动的兼容性。 9. 识别如何解决相关干系人之间的冲突。 SP 使用集成计划管理项目有关组织过程资产，请参考组织过程定义过程域，以获得更多信息。有关组织过程需求及目标，以及与组织的其它单位协调过程改进活动，请参考组织过程焦点过程域，以获得更多信息。有关管理风险，请参考风险管理过程域，以获得更多信息。有关项目监控，请参考项目监控过程域，以获得更多信息。典型的工作产品 1. 执行项目已定义过程所产生的工作产品 2. 已收集的度量(实际的)与进度纪录或报告 3. 已修订的需求、计划及承诺 4. 集成计划子实践 1. 使用组织过程资产库，实施项目已定义过程。这项工作通常包括下列事项： • 从组织过程资产库，将合适的成果纳入项目 • 使用自组织过程资产库中的学习心得来管理项目 2. 使用项目已定义过程、项目计划及影响项目的其它计划来监控项目的活动和工作产品。这项工作通常包括下列事项： • 利用已定义的入口与出口准则，授权工作的启动，并决定工作的完成 • 监控对项目的规划参数有重大影响的活动 • 使用将引发调查和适当行动的度量阈值，来追踪项目的规划参数 • 监控产品与项目接口的风险 • 以执行项目已定义过程的工作项目与工作产品的计划为基础，管理外部与内部承诺了解项目已定义过程中不同工作项目与工作产品间的关系、干系人所扮演的角色，以及完整定义的控制机制(例如：同行评审)，可达成较好且明显的项目绩效及较佳的项目控管。 3. 取得并分析所选择的度量数据，以管理项目与支持组织的需求。有关定义取得与分析度量的过程，请参考度量与分析过程域，以获得更多信息。 4. 定期审查，并将项目绩效与组织、客户及最终使用者之当前和期望的需要、目标及需求，作适当的调整。这项审查包括组织过程需要与目标的调整。达成调整的措施，举例如下： • 加速进度，并对其他的规划参数与项目风险，作适当的调整 • 改变需求，以反应市场机会或客户与最终使用者需求的变更 • 终止项目 SP 贡献组织过程资产有关过程改进建议，请参考组织过程焦点过程域，以获得更多信息。有关组织过程资产、组织度量资产库及组织过程资产库，请参考组织过程定义过程域，以获得更多信息。本特定实践说明从项目已定义过程的过程收集信息。典型的工作产品 1. 针对组织过程资产所提出的改进措施 2. 从项目所收集之实际的过程与产品度量 3. 文档(如示范的过程描述、计划、培训模块、检查表及学习心得) 4. 项目定义及执行组织标准过程的相关过程成果。子实践 1. 针对组织过程资产，提出改进方案。 2. 保存过程与产品度量数据于组织度量资产库中。有关记录规划与重新规划的资料，请参考项目策划过程域，以获得更多信息。有关记录度量数据，请参考项目监控过程域，以获得更多信息。通常包括下列事项： • 规划资料 • 重新规划资料 • 度量项目纪录的数据，举例如下： • 工作项目描述 • 假设 • 估计值 • 修订的估计值 • 记录的数据与度量的定义 • 度量 • 使度量与执行活动及产出工作产品产生关联的相关信息 • 重新估计、评价其合理性及新工作之衍生估计值所需的相关信息 3. 提交可能会纳入组织过程资产库的文档。文档，举例如下： • 过程描述范例 • 培训模块 • 计划范例 • 检查表 4. 记录项目的学习心得，以纳入组织过程资产库。 5. 为支持组织过程监控活动，提供与定义及执行组织标准过程相关的过程成果。有关在新的及现有项目中，由组织活动来了解标准过程的部署程度，请参考组织过程焦点过程域的监控实施特定实践，以获得更多信息。 SG 2 与相关干系人协调与合作 SP 管理干系人参与根据项目集成及已定义过程，管理相关干系人的参与。有关识别干系人、干系人的适当参与，以及建立并维护承诺，请参考项目策划过程域，以获得更多信息。典型的工作产品 1. 协调活动的议程与进度 2. 问题纪录(如客户需求、产品及产品组件需求、产品架构与产品设计等问题) 3. 解决相关干系人问题的建议子实践 1. 与应参与项目活动的相关干系人协调。相关的干系人应已定义在项目计划中。 2. 确保产出的工作产品满足承诺，并符合承接项目的需求。有关工作产品可接受度的决定，请参考验证过程域，以获得更多信息。这项工作通常包括下列事项： • 由相关的干系人适当的审查、展示或测试每项工作产品集成的项目管理(IPM+IPPD) • 项目产出的每项工作产品，由接收工作产品的其它项目代表，作适当的审查、展示或测试 • 解决验收工作产品的相关问题 3. 提出建议与协调的措施，以解决产品与产品组件间之需求、架构及设计的误解与问题。 SP 管理相互依存关系有关识别干系人、适当参与及建立并维护承诺，请参考项目策划过程域，以获得更多信息。典型的工作产品 1. 与相关的干系人审查所产生的缺陷、问题及行动项目 2. 重要依存关系 3. 满足重要依存关系的承诺 4. 重要依存关系的状态子实践 1. 与相关的干系人进行审查。 2. 识别每一重要依存关系。 3. 以项目的进度为基础，建立每一重要依存关系的必要天数与计划天数。 4. 对每个重要依存关系中，负责提交工作产品和承接工作产品之人员，审查承诺的履行并取得协议。 5. 记录重要依存关系与承诺。承诺文档通常包括下列事项： • 承诺的描述 • 识别承诺人员 • 识别负责满足承诺的人员 • 明确说明满足承诺的时机 • 明确说明用来判定承诺是否满足的准则 6. 追踪重要的依存关系与承诺，并采取适当的纠正措施。有关追踪承诺，请参考项目监控过程域，以获得更多信息。追踪重要的依存关系通常包括下列事项： • 评估延迟与提早完成的影响，以及它对未来活动及里程碑的冲击 • 尽可能与负责人员解决实际与潜在的问题 • 将负责人员未解决之实际与潜在的问题，提升至适当的管理阶级 SP 解决协调问题协调问题，举例如下： • 迟来的重要依存关系与承诺 • 产品及产品组件需求与设计缺陷 • 产品等级的问题 • 无法取得关键的资源或人员典型的工作产品 1. 相关的干系人协调问题 2. 相关的干系人协调问题的状况子实践 1. 识别与记录问题。 2. 与相关干系人沟通问题。 3. 与相关干系人解决问题。 4. 将相关干系人无法解决的问题，提报至适当的管理者。 5. 追踪问题到关闭。 6. 与相关干系人沟通问题的状态及解决。 IPPD 补充 SG 3 应用IPPD 原则本特定目标及实践的目的，在于建立IPPD 环境，使集成团队有效达成项目需求并产出优良产品。 SP 建立项目的共同愿景项目并非单独运作，了解组织任务、目标、期望及限制，能使项目与组织方向、活动及共同愿景密切结合，并有助于建立协调项目活动的共同目的。为达此，了解项目与外部干系人之间的接口，以及所有内外部相关干系人的目标与期望，是重要的。建立共同愿景时须考虑： • 外部干系人的期望与需求 • 项目领导者、团队领导者与团队成员的期待与期望 • 项目的目标 • 项目将建立的条件与结果 • 项目须维护的接口 • 由接口团队所建立的愿景 • 由外在权威人士所加的限制(例如：环境规则) • 当致力于达成目标时的项目运作(含原则与行为两者) 当建立共同愿景时，项目的所有人员应受邀参加。虽然可能有一份建议草稿，但应让更多人有机会表达与被倾听他们真正关心的事务。共同愿景要能清楚表达中心思想体系(价值、原则及行为)，以及对项目每个成员渴望的未来能做出保证。有效的沟通策略是整个项目执行共同愿景并使之清晰的关键。公布共同愿景是项目承诺共同愿景的公开宣告，并提供机会给其它人员以检定、了解及调整他们的活动往共同方向。沟通与协议共同愿景，并且取得IPPD 补充干系人的承诺。当有新的项目成员加入时，有效率的沟通也显得特别重要。项目的新进人员常常需要更多或特别的注意，以确保其了解愿景，愿意支持并准备遵循愿景来执行工作。典型的工作产品 1. 共同愿景文档 2. 沟通策略 3. 颁布的原则、共同愿景说明、任务说明及目标(例如：海报、随身卡及简报) 子实践 1. 在目的或任务、愿景、价值与目标上，清楚表达项目的共同愿景。 2. 达成对项目共同愿景的共识。 3. 建立对内与对外沟通项目共同愿景的策略。 4. 为需要被告知项目共同愿景的不同听众，制作合适的简报。 5. 检视项目及个别的活动与工作，是否符合项目共同愿景。 SP 建立集成团队架构产品需求、成本、进度、风险、资源规划、经营过程、项目的已定义过程以及组织指导，皆属用以评估建立定义集成团队及其责任、授权与相互关系的基础。典型的集成团队架构，是以工作拆分结构的产品导向等级为基础。若工作拆分结构不是产品导向、产品风险不一致及资源受限，会发生更复杂的结构。 IPPD 补充集成团队架构是动态的物理，随着人员、需求及工作性质的异动而调整，并能处理许多困难。对小项目而言，集成团队架构可视整个项目为集成团队。应持续不断地监控集成团队架构，以发现机能不全、管理不善的接口，以及人员与工作的不协调。当绩效无法符期望时，应采取纠正措施。有关构成及组成集成团队的建立组织规则与指导，请参考组织过程定义+IPPD 过程域中，集成团队特定实践之建立原则与指导，以获得更多信息。典型的工作产品 1. 产品与产品架构的评价，包含风险与复杂度。 2. 集成团队架构子实践 1. 建立集成团队架构。集成团队架构有赖于： • 产品风险及复杂度 • 风险的地点及型态 • 集成风险，包括产品组件的接口与团队内部的沟通 • 资源，包括拥有适当技能的人员 • 有效率的合作受限于团队大小 • 项目外部干系人的团队关系需求 • 经营过程 • 组织结构集成团队架构应基于，项目已定义过程和共同愿景、组织标准过程，以及组织过程资产可应用于团队与团队间架构的了解。 2. 定期评估与修订集成团队架构，使最符合项目需要。 IPPD 补充产品需求或架构的变动会影响团队结构。持续不断地监督集成团队架构，以侦测问题，例如：管理不善的接口，以及工作分配与人员执行工作的不协调。当绩效无法符预期时，应采取包括评价部署团队与架构的纠正措施。团队架构的变更包括如下： • 团队除役一段时间（例如：当已完成长期的制造或验证时） • 当团队在服务项目上不再具成本效益时，解散该团队 • 合并团队以达成运作的效率 • 当识别须开发的新产品组件时，增加团队 SP 分配需求至集成团队在任何团队形成之前，先完成集成团队需求的分配，以验证集成团队架构是可行的，且涵盖所有必要需求、责任、职权、工作项目及接口。一旦确认架构，选定集成团队负责人来建立该架构中的各别团队。典型的工作产品 1. 每一集成团队的责任分配 2. 各集成团队有责任满足之工作产品需求、技术接口及经营接口(如成本会计及项目管理) 3. 集成团队负责人清单子实践 1. 分配工作项目、责任、交付的工作产品，以及相关需求及接口至适当的集成团队。集成团队的经营、管理及其它非技术性的权责，是 IPPD 补充典型的工作产品 1. 团队领导人清单 2. 团队成员分配到各集成团队的清单 3. 集成团队规章 4. 用来评估集成团队绩效的度量 5. 定期的集成团队状况报告子实践 1. 选择各集成团队的领导者。在选择领导者的组织及项目方向范围上，通常视产品风险及复杂度，或具有组织需要培养新领导者的功能。依照组织方针，团队负责人可选择团队领导者，或由团队成员间投票选出。 2. 分配资源给各集成团队[s1]。分配人员与其它资源给各集成团队。与团队讨论这些项目，以确保资源及人员足以完成工作，并能与其它团队成员共处。 3. 规范各集成团队。团队规章是团队成员间，以及团队与其负责人间对工作预期及绩效等级的契约。规章建立了权利、保证、特权，以及授与同意权来组织及执行团队所分派的需求及接口、责任与工作项目。集成团队及其负责人开发团队规章，视为谈判活动。当双方都批准时，团队规章制定了被认可的管理权力协议。规章包括下列几方面： • 如何接受分配 • 如何评估资源及投入 • 如何完成工作 • 谁来检讨及审查工作 IPPD 补充 • 如何批准工作 • 如何交付及沟通工作 4. 当团队领导人或其它成员发生重大变更时，审查集成团队架构中的集成团队组合及配置。这种变更可能严重影响团队完成目标的能力。需要审查新组合与新责任间的契合度，若新组合无法满足，需要改变团队组合或调整团队责任。 5. 当团队责任变更时，审查团队组合及任务分派。责任变更通常发生在项目从一阶段进行至下一阶段时。举例来说，当详细设计完成，以及配置和集成产品组件开始时，愈不需要团队设计技术。 6. 管理团队整体绩效。规章应指定如何度量团队及个别绩效，也应包括在项目中团队的关键成功因素。 SP 建立整合团队建立并维护架构中的集成团队。有集成团队负责人建立集成团队架构中的集成团队。本流程包括选择团队领导者及团队成员，以及根据需求分配建立各集成团队团队规章。同时也包含提供必要资源，以完成指派给团队的工作。有关建构成及组成集成团队的建立组织规则与指引，请参考组织过程定义＋IPPD过程领域，集成团队特点执行方法之建立规则与指引以获得更多资讯。 SP 确保跨团队间的合作确保跨团队间的合作。以团队组成的项目，其成功的作用在于集成团队如何有效率及成功地与其它团队合作，以达成项目目标。团队合作可藉由控制工作团队接口而达成。有关管理干系人参与、重要相互依存关系及解决合作问题，请参考本过程域之相关干系人的协调与合作特定目标，以获得更多信息。有关建立组织期望及规则，引导集成团队如何共同工作，请参考组织过程定义(IPPD) 过程域中，集成团队建立原则与指导之指定实践，以获得更多信息。典型工作产品 1. 工作产品所有权协议 2. 团队工作计划 3. 承诺清单子实践 1. 建立与维护在项目或跨团队间，工作产品所有权的界限。 2. 建立与维护在跨团队间，投入、产出与工作产品的接口与过程。 3. 开发、沟通与分配在跨团队间，与工作产品或团队接口相关的承诺清单与工作计划。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施集成的项目管理过程过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义的过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行集成项目管理过程。详细说明：本方针建立组织期望：从项目开始到项目全期，建立及维护项目已定义过程，并使用项目已定义过程来管理项目，以及与相关的干系人协调合作。 IPPD 补充本方针应用IPPD 原则，建立组织期望。 GP 规划过程建立并维护用来执行过程集成项目管理的计划。详细说明：集成项目管理过程计划，结合项目策划及监控过程计划。在集成项目管理中，描述实施规划相关实践计划，是规划项目策划过程的一部分。项目策划过程域提及，在集成项目管理中，实施监控相关实践计划，可包含（或参考）项目计划。有关通用实践与项目策划过程间的关系，请参考通用目标与通用实践表，以获得更多信息。 GP 提供资源提供充分的资源，以执行集成项目管理过程、开发工作产品及提供过程服务。详细说明：提供的资源，举例如下： • 问题追踪与困境报告的相关资料 • 群组软件 • 视讯会议 • 集成的决策数据库 • 集成的产品支持环境 GP 分配责任分配集成项目管理过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持集成项目管理过程。详细说明：培训的主题，举例如下： • 定义组织标准过程，以符合项目的需求 • 以项目已定义过程为基础，管理项目的程序 • 使用组织度量资产库 • 使用组织过程资产 • 集成的管理 • 群组之间的协调 • 群组问题的解决 IPPD 补充培训的主题，举例如下： •建立项目的共同愿景 •团队建立 GP 管理配置将指定的集成项目管理过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 项目已定义过程 • 项目计划 • 影响项目的其它计划 • 集成计划 • 自项目中收集到的实际过程与产品度量 IPPD 补充纳入控制的工作产品，举例如下： •项目共享愿景 •集成团队架构 •集成团队规章 GP 识别并纳入相关的干系人依计划识别并纳入集成项目管理过程相关干系人。详细说明：有关通用实践GP 与本过程域之管理干系人参与实践间的关系，请参考通用目标与通用实践表，以获得更多信息。干系人参与的活动，举例如下： • 解决定义组织过程资产的问题 • 解决项目计划与影响项目的其它计划之间的问题 • 审查项目的绩效，以调整现行的与期望的需要、目标及需求 IPPD 补充干系人参与的活动，举例如下： • 建立项目的共同愿景 • 定义项目的集成团队架构 • 产生集成团队 GP 监控过程依过程的执行计划，监控集成项目管理过程，以执行过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 项目已定义过程变动的次数 • 定义组织标准过程的进度与工作量 • 接口协调问题趋势(例如：已识别与已关闭的数量) • 项目定义活动的进度 IPPD 补充用于监控的工作产品，举例如下： •项目共同愿景的使用性与有效性 •集成团队架构的使用性与有效性 •集成团队规章的使用性及有效性 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估集成项目管理过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立、维护及使用项目已定义过程 • 与相关干系人的协调与合作 IPPD 补充审查的活动，举例如下： •使用项目的共同愿景 •组织集成团队审查的工作产品，举例如下： • 项目已定义过程 • 项目计划 • 影响项目的其它计划 IPPD 补充审查的工作产品，举例如下： •集成团队架构 •集成团队规章 •共同愿景叙述 GP 与高层管理人员审查各状况与高层管理人员审查集成项目管理过程的活动、状况及结果，并解决问题。仅适用于过程式表述 GG 3 制度化已定义过程本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义集成项目管理过程的说明。详细说明：有关通用实践与集成项目管理过程域间的关系，请参考通用目标与通用实践表，以获得更多信息。 GP 收集改进信息收集由规划和执行集成项目管理过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：有关通用实践与集成项目管理过程域间的关系，请参考通用目标与通用实践表，以获得更多信息。工作产品、度量、度量结果与改进信息，举例如下： • 项目已定义过程 • 项目使用数个定义选项，来创造已定义过程 • 接口协调问题趋势（例，已识别与已关闭数量） • 为取得规划项目相关的资产，项目个人读取PAL 的次数。 • 召开面对面会议的费用纪录，相对于使用协调设备的会议，如视讯及音讯设备。 IPPD 补充工作产品、度量、度量结果与改进信息，举例如下： •集成团队规章 •项目共同愿景仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化管理过程。 GP 建立过程的量化目标建立与维护集成的项目管理过程的量化目标，该目标用来处理以客户需要与经营目标为基础的品质与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定集成项目管理过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为最佳化过程。 GP 确保持续的过程改进确保集成项目管理过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正集成的项目管理过程之缺陷与其它问题的根本原因。度量与分析（MA 2级）成熟度第二级的支持类过程域目的度量与分析(Measurement and Analysis, MA)的目的在开发与维持度量能力，以支持管理之信息需求。简介度量与分析过程域包括： • 指定度量与分析的目标，并使其配合已识别的信息需求与目标 • 指定度量、分析技术、数据收集、数据存储以及报告与反馈机制 • 执行数据的收集、存储、分析及报告 • 提供客观的结果以做出有根据的决策，并采取适当的纠正措施将度量与分析活动集成到项目过程中，可支持下列活动： • 客观的规划与估计 • 根据建立的计划和目标，追踪实际绩效 • 识别与解决过程相关问题 • 提供将度量纳入未来增订过程的基础执行度量功能的同行，不一定需参与组织层面的计划。度量功能可以集成至个别项目，或其它的组织功能(例如：质量保证)。度量活动最初的重点是在项目，而度量功能在处理组织面与(或)企业面的信息需求上，亦经证明确实有用。为支持度量功能，度量活动应支持多层次的信息需求，包括业务、组织单位及项目及当组织成熟时，支持减低重工。项目可选择在项目特定存储库中存储项目的数据与结果。当数据更广为各项目分享时，可存放于组织度量资产库。针对供应商提供的产品组件进行度量与分析，对有效管理项目的质量与成本是必要的。通过谨慎的管理供应商协议，可深入了解支持供应商绩效分析的数据。相关过程域有关估计项目属性和其它规划信息需求，请参考项目策划过程域，以获得更多信息。有关监控项目绩效信息需求，请参考项目监控过程域，以获得更多信息。有关管理度量工作产品，请参考配置管理过程域，以获得更多信息。有关满足客户需求和相关信息需求，请参考需求开发过程域，以获得更多信息。有关维持需求的可溯性和相关信息需求，请参考需求管理过程域，以获得更多信息。有关建立组织度量资产库，请参考组织过程定义过程域，以获得更多信息。有关了解变异和适当使用统计分析技术，请参考量化项目管理过程域，以获得更多信息。特定目标及实践摘要 SG 1 安排度量与分析的活动 SP 建立度量目标 SP 指定度量 SP 指定数据收集与存储程序 SP 指定分析程序 SG 2 提供度量结果 SP 收集度量资料 SP 分析度量数据 SP 存储数据与结果 SP 沟通结果各目标的特定实践 SG 1 安排度量与分析的活动度量目标与活动要配合已识别的信息需求与目标。本目标涵盖的特定实践，可同时处理或依任意顺序处理： • 建立度量目标时，专家经常先考量识别度量和分析程序的必要准则，同时也会考量数据收集与存储程序的限制。 • 在处理度量规格、数据收集或存储等细节之前，先识别需进行的必要分析，通常是重要的。 SP 建立度量目标建立并维护度量目标，此度量目标衍生自己识别的信息需求与目标。度量目标记录完成度量与分析活动的目的，并识别基于数据分析的结果，需要采取何种行动。度量目标的来源可能是管理、技术、项目、产品或过程实施的需要。度量目标可能受限于现行的过程、可用的资源或其它的度量考量。需要判断投入度量工作的资源与度量结果的价值是否相当。度量与分析的过程及结果，将影响已识别的信息需求与目标的修改。信息需求与目标的来源，举例如下： • 项目计划 • 项目绩效的监控 • 与管理人员和其它具有信息需求的人员进行访谈 • 已建立的管理目标 • 策略计划 • 经营计划 • 正式需求或合同义务 • 再发的或其它棘手的管理或技术问题 • 其它项目或组织的经验 • 外部的产业标竿 • 过程改进计划度量目标举例如下： • 减少交付时间 • 减少生命周期总成本 • 完整交付指定功能 • 改进优先等级的质量 • 改进优先客户满意度评等 • 维护与改进采购/供应商的关系有关估计项目属性和其它规划信息需求，请参考项目策划过程域，以获得更多信息。有关项目绩效信息需求，请参考项目监控过程域，以获得更多信息。有关满足客户需求和相关信息需求，请参考需求开发过程域，以获得更多信息。有关维持需求的可追溯性和相关信息需求，请参考需求管理过程域，以获得更多信息。典型的工作产品 1. 度量目标子实践 1. 记录信息需求与目标。记录信息需求与目标，以维持后续度量与分析活动的可追溯性。 2. 排定信息需求与目标的优先级。并非所有最初识别的信息需求都需要度量与分析，在可用资源的限制下，必须排定优先级。 3. 记录、审查及更新度量目标。仔细考量度量与分析的目的与预期的用途是重要的。记录度量目标，并交由管理人员和其它相关的干系人审查，必要时并予更新，使得接续的度量与分析活动可以追溯，并参考确保分析活动可适当的说明信息需求与目标。让度量与分析结果的使用者参与设定度量目标与决定行动计划是重要的。让提供度量资料的人员参与也是适当的。 4. 必要时提供反馈，以调修和厘清信息需求与目标。设定度量目标后可能需修订和厘清识别的信息需求与目标。信息需求的初始描述可能不清楚或模糊。现存的需求和目标之间可能产生抵触。对一个已经存在的度量，要求精确的目标可能是不切实际的。 5. 维持度量目标和指定的信息需求与目标之间的可溯性。对于「为何要作这项度量？」这样的问题，必须要有好的答案。当然，也可以改变度量目标，以反映不断开发的信息需求与目标。 SP 指定度量指定度量以说明度量的目标。将度量目标调修为精确的、可量化的度量。度量包括「基础」度量与「衍生」度量，基础度量数据得自于直接度量，衍生度量数据来自其它数据，通常结合多个基础度量而得。一般使用的基础度量，举例如下： • 工作产品规模大小的估计及实际度量(例如：页数) • 人力与成本的估计及实际度量(例如：人时) • 质量度量(例如：缺陷数、依严重程度区分的缺陷数) 一般使用的衍生度量，举例如下： • 挣值(Earned Value) • 进度绩效指标(SPI) • 缺陷密度 • 同行评审涵盖度 • 测试或验证涵盖度 • 可靠度度量(例如:平均失败时间) • 质量度量(例如：依严重程度区分的缺陷数/总缺陷数) 衍生度量通常以比例、混合指标或其它合计度量来表示。衍生度量由基础度量产生，通常比基础度量更具数量可信度和说明意义。典型的工作产品 1. 基础与衍生度量规格子实践 1. 依据文档化的度量目标，识别可能的度量。度量目标被调修为特定的度量，根据度量的名称和单位，将这些可能的度量予以分类。 2. 识别已经存在且可以说明度量目标的度量。度量规格可能已经存在，或许早期为其它目的而建立，或存在于组织的某处。 3. 指定度量的操作定义。以精确和明白的方式陈述操作定义，有下列两个重要准则： •可沟通：度量什么？如何度量？度量的单位是什么？包括或排除什么？ •可重复：在相同的定义下，度量是否可以重复执行，且获得相同的结果？ 4. 将度量排序，并予以审查及更新。请可能的最终使用者和其它相关的干系人，对所建议之度量规格的适当性进行审查。可设定或改变排序，必要时可更新度量规格。 SP 指定数据收集与存储程序指定度量数据如何获得与存储。明确规范收集方法可确保适当的收集正确的资料，也参考更进一步厘清信息需求和度量目标。注意存储和取用程序，可帮助确保数据将来的可用性及可存取性。典型的工作产品 1. 数据收集与存储程序 2. 资料收集工具子实践 1. 识别由目前工作成果、过程或交易产生的数据来源。在指定度量时，可能已有现行的数据来源。不论相关的数据是否已收集，适当的资料收集机制可能已存在。 2. 识别目前没有资料，但需要的度量。 3. 为每一项需要的度量，指定数据收集与存储的方法。明确的描述资料如何收集、从何处收集及何时收集，并描述收集有效数据的程序。数据以容易取得的方式存储以便于分析，并决定数据是否需存储，以作为再分析或撰写文档之用。通常考量的问题包括如下： • 是否已经决定数据收集的频率，以及在过程中执行度量的时点? • 是否已经建立将度量结果自数据收集处转移到数据存储库、其它数据库或最终使用者处所的时序? • 谁负责取得资料? • 谁负责数据存储、取得及安全维护? • 是否已开发或取得必要的支持工具? 4. 建立数据收集的机制与过程指导。数据收集与存储的机制需与其它一般工作过程集成。数据收集的机制可以包括人工/自动的表格与样板。负责这项工作的人员，提供清楚简明的指导以正确执行工作。视需要提供培训，说明收集数据的过程，以便收集完整与正确的资料，并减轻负责提供和记录数据人员的负担。 5. 适当且可行时，支持资料收集自动化。自动化的支持可以参考收集更完整与正确的资料。自动化的支持，举例如下： • 时间戳记的活动日志 • 成果的静态或动态分析然而，有些资料没有人工介入无法收集(例如：客户满意度或其它人为判断)，且为了自动化建立所需的基础建设可能相当昂贵。 6. 对数据收集与存储程序加以排序，并进行审查及更新。数据收集与存储程序的适当性与可行性，必须经过负责提供、收集及存储数据人员的审查，他们对于如何改进现行的过程或建议其它有用的度量和分析，具备洞察力。 7. 必要时更新度量与度量目标。基于以下的条件，度量与度量目标需要重新排定优先级： • 度量的重要性 • 取得资料所需的代价考量因素包括取得这个数据是否需要新的表格、工具或培训。 SP 指定分析程序指定度量数据如何分析与报告。事先指定度量的分析程序，可确保执行适当的分析与报告，以说明已记录的度量目标(亦说明了信息需求和目标，因其为度量目标的基础)。此方法也是必要资料收集的一种查核。典型的工作产品 1. 分析规格与程序 2. 数据分析工具子实践 1. 指定将要执行的分析与将准备的报告，并排定优先级。及早注意所执行的分析，以及分析报告呈现的方式。应符合下列准则： • 分析可以清楚的说明度量目标。 • 表达结果的方式，能让需处理此结果的人员清楚了解。在可取得的资源内排定优先级。 2. 选择适当的数据分析方法与工具。有关了解变异和适当使用统计分析技术，请分别参考量化项目管理过程域之「应用统计方法了解变异」和「选择度量与分析技术」特定实践，以获得更多信息。考量点通常包括如下： • 选择视觉显示方法和其它呈现技术(例如：饼图、长条图、柱状图、雷达图、线条图、分布图或表格) • 选择适合的叙述统计方法(例如：算数平均数、中数或众数) • 当无法或无必要检验每一数据元素时，决定统计取样的准则 • 当出现缺少数据元素时，决定如何处理分析 • 选择适当的分析工具叙述统计通常用于数据分析，以执行下列事项： • 审查指定度量的分布(例如：集中趋势、变化程度、资料点呈现异常变异) • 审查指定度量之间的相互关系(例如：以产品生命周期的不同阶段或产品组件来比较缺陷) • 显示随着时间的变化 3. 指定分析数据和沟通结果的管理程序。考量点通常包括如下： • 指定适合的人员和团体负责分析数据和简报结果 • 决定分析数据和简报结果的时间 • 决定沟通结果的方式(例如：进度报告、传送备忘录、书面报告或工作人员会议) 4. 审查并更新分析与报告的内容和形式。所有提出的分析与报告的内容和形式应予审查和修正，包括分析方法和工具、管理程序及优先级。相关干系人的咨询应该包括预期的最终使用者、赞助者、数据分析人员及数据提供人员。 5. 必要时，更新度量与度量目标。正如同度量需求会导引数据分析，清楚的分析准则会影响度量。以数据分析程序为基础，某些度量规格可能会进一步调修，其它度量可能并不需要，或发现需要其它的度量。当描述度量如何分析和报告时，可能同时会建议调修度量目标。 6. 指定评估分析结果有用性及评估度量与分析活动的准则。评估分析结果有用性的准则，可以考虑下列项目的应用程度： • 分析结果是否(1)适时提供、(2)容易了解，以及(3)可用来制定决策。 • 分析工作的执行成本不应比它提供的效益高。度量与分析活动的评估准则可考虑下列项目的应用程度： • 资料缺少与不一致的数量是否超出阈值。 • 资料取样是否有偏差(例如：仅调查满意的使用者以评估最终使用者满意度，或只评估不成功的项目以决定整体生产力)。 • 度量资料是否可重复(例如：统计上的可靠性)。 • 统计的假设是否满足(例如：关于数据的分布或关于度量单位的合适性) SG 2 提供度量结果根据度量结果，此度量结果说明已识别的信息需求与目标。进行度量和分析的主要理由，是要处理已识别的信息需求与目标。以客观证据为基础的度量结果，能够参考监测绩效、履行契约义务、制定有根据的管理与技术决策，以及采取纠正措施。 SP 收集度量资料获得指定的度量资料。取得需分析的数据，并检查其完整性和集成性。典型的工作产品 1. 基础度量数据集与衍生度量数据集 2. 数据完整性测试的结果子实践 1. 获得基础度量数据。视需要收集数据，包括已使用的与新指定的基础度量。现存数据可从项目纪录或在组织其它地方收集。需注意，以前已收集并放置于现行的数据库、文档纪录或正式存储库中的数据，可能无法再使用。 2. 产生衍生度量数据。重新计算所有衍生度量的值。 3. 检查数据一致性，使其尽可能接近原始数据。所有度量在说明或记录数据的过程中可能发生错误，最好能在度量与分析周期的初期识别这些错误，并能指出所缺资料的来源。检查应包括详查缺少的数据、超出所订范围的数据值，以及不寻常的型态和度量间的相关性。下列工作特别重要： • 测试和修正人为判断分类的不一致(亦即决定工作人员根据相同信息而做出不同分类决策的频率，否则称作「互相转译的可靠度」)。 • 以经验审查用来计算衍生度量之度量间的关系，如此可确保未忽视重要差异，以及传达衍生度量的预期的意义(否则称作「准则有效性(criterion validity)」)。 SP 分析度量数据分析与解释度量数据。依照计划分析度量数据，并视需要执行额外的分析。分析结果需由相关的干系人审查，并记录将来分析所需做的修正。典型的工作产品 1. 分析结果与报告草案子实践 1. 进行初步分析并解释结果，并导出初步结论。数据分析的结果很少可以显而易见。解释结果与产生结论的准则应予明确的陈述。 2. 必要时，执行额外的度量与分析，并准备进行简报。规划的分析结果可能提出进行额外、非预期分析的建议。此外，为适当完成计划内的分析工作可能识别下列需求，例如：调修现行度量、计算额外的基础度量，或为额外的原始度量收集资料。相同地，为了准备初步分析结果的简报，可能识别出额外、未预期的分析需要。 3. 与相关的干系人审查初步分析结果。在分析结果广泛传布之前，对结果的初步解释及其表达的方式加以审查是否适当。在初步结果发表之前予以审查，可以避免不必要的误解，并改进资料分析与呈现方式。进行审查的相关干系人包括预期的最终使用者、赞助者、资料分析人员及提供人员。 4. 为未来的分析调修准则。可改进未来工作之学习心得，经常来自于执行数据分析和准备结果时。类似状况，当有调修指定的信息需求与目标的构想时，改进度量规格及数据收集程序的方式可能会变得明显。 SP 存储数据与结果管理和存储度量数据、度量准则和分析结果。存储度量相关信息，使未来能更及时和经济的使用历史数据与结果。此信息也对数据诠释、度量准则及分析结果，提供充分的说明内容。存储的信息通常包括如下： • 度量计划 • 度量规格 • 已收集的资料 • 分析报告和简报数据存储的信息包含或参考下列信息：了解和解释度量的信息，以及评价其合理性及适用性之信息(例如：进行项目之间的比较时，不同的项目可能使用不同的度量规格)。衍生度量的数据集通常可以重新计算，所以不需要存储，可能较适合存储衍生度量的摘要(例如：图表、结果表格或报告)。如果可以有效重建中间分析的结果，这中间分析结果不需要个别存储。项目可在项目特定存储库中存储项目特定的数据与结果。当资料于项目间广泛的共享时，可以存放在组织度量资产库。有关建立组织度量资产库，请参考组织过程定义过程域的「建立组织度量资产库」特定实践，以获得更多信息。有关管理度量工作产品，请参考配置管理过程域，以获得更多信息。典型的工作产品 1. 存储数据清单子实践 1. 审查数据以确保完整性、一致性、正确性与及时性。 2. 根据数据存储程序来存储数据 3. 确定存储的内容仅提供适当的团体与人员使用。 4. 防止数据不当使用。防止数据及相关信息不当使用的例子包括：控制数据的存取权限及教育同行适当使用数据。不当使用数据之情形，举例如下： • 揭露秘密信息 • 由于不完全、不相关或其它误导的信息，而造成错误的解释 • 不当的评估同行的绩效或进行项目评比 • 责难特定人员的正直与诚实。 SP 沟通结果向所有相关的干系人报告度量与分析活动的结果。用实时、有用的方式，向所有相关的干系人报告度量与分析的结果，以支持制订决策与帮助采取纠正措施。相关的干系人包括预定的使用者、赞助者、数据分析人员及数据提供人员。典型的工作产品 1. 交付的报告和相关的分析结果 2. 能参考诠释分析结果的相关信息或指导子实践 1. 及时告知相关的干系人度量结果。度量结果因为有预期目的，因此需及时传达。报告如果未能分送给所有需要知道结果的人，则报告不太可能会被使用。在可能的范围内，度量结果的使用者应亲自参与设定目标与决定度量与分析行动的计划，就如同他们执行企业的部分任务一般。进度和中间结果定期持续告知使用者。有关度量结果的使用，请参考项目监控过程域，以获得更多信息。 2. 帮助相关的干系人了解结果。以清楚简明的方式，对相关的干系人报告结果，。报告必须易于了解、诠释，并且与指定的信息需求及目标清楚连结。对不是度量专家的从业者而言，很难从数据中自行诠释其涵义，选择度量方式应了解下列原因： • 如何与为何指定基础度量和衍生度量 • 如何取得数据 • 如何使用数据分析方法解释结果 • 结果如何说明信息需求帮助了解结果的活动，举例如下： • 与相关的干系人讨论结果 • 提供内含背景与解说的备忘录 • 对使用者进行度量结果的简报 • 提供关于适当使用和了解度量结果的教育培训。各目标的通用实践仅适用于连续式表述GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施度量与分析过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行度量与分析过程。详细说明：本方针建立组织的期望，使度量目标与活动和已识别的信息需求与目标相一致，并提供度量结果。 GP 规划过程建立并维护用来执行度量与分析过程的计划。详细说明：项目计划可以包含(或参考)执行度量与分析过程的计划。项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行度量与分析过程、开发工作产品及提供过程服务。详细说明：度量人员可以是专职或兼职，亦可组成一个小组，同时支持多个项目度量活动。其它提供的资源，举例如下： • 统计软件包 • 支持通过网络收集数据的软件包 GP 分配责任分配度量与分析过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持度量与分析过程。详细说明：培训的主题，举例如下： • 统计技术 • 数据收集、分析及报告过程 • 与目标相关度量的开发(例如：目标问题矩阵) GP 管理配置将指定的度量与分析过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 基础度量和衍生度量规格 • 数据收集和存储的程序 • 基础度量数据集和衍生度量数据集 • 分析结果和报告草案 • 数据分析工具 GP 识别并纳入相关的干系人依计划识别并纳入度量与分析过程相关干系人。详细说明：干系人参与的活动，举例如下： • 建立度量目标与程序 • 评价度量资料 • 给负责对原始数据提供分析和结果的人，提供有意义的反馈 GP 监控过程依过程的执行计划，监控度量与分析过程，并采取适当的纠正措施。详细说明：用于监控的度量与工作产品，举例如下： • 使用进度及绩效度量的项目，占整个组织项目的百分比 • 度量目标达成的百分比 • 收集与审查度量资料的进度 GP 客观评价遵循程度依过程的说明、目标、标准及程序，客观评估度量与分析过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 安排度量与分析活动 • 提供度量结果审查的工作产品，举例如下： • 基础度量和衍生度量规格 • 数据收集和存储的程序 • 分析结果和报告草案 GP 与高层管理人员审查各状况与高层管理人员审查度量与分析过程的活动、状况及结果，并解决问题。仅适用于阶段式表述GG 3 和其实践不适用于成熟度第二级评等，但对于成熟度第三级和更高等级评等而言，是适用的。仅适用于连续式/成熟度第3－5级将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义配置管理过程的说明。 GP 收集改进信息收集由度量与分析过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息的例子，包括如下： • 资料即时状态 • 资料整合性测试结果 • 资料分析报告仅适用于连续式表述GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护度量与分析过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定度量与分析过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保度量与分析过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正度量与分析过程之缺陷与其它问题的根本原因。组织创新与部署（OID 五级）成熟度第五级的过程管理类过程域目的组织创新与部署(Organizational Innovation and Deployment, OID)的目的，在于选择与部署具渐进和创新效果的各种改进措施。这些改进措施以可度量的方式，改进组织过程和技术，也支持由组织经营目标导出的质量和过程绩效目标。简介组织创新与部署过程域藉由改进措施的选择与部署，加强组织能力，以满足其质量和过程绩效目标(有关「质量和过程绩效目标」的定义，请参见词汇)。本过程域所用的术语「改进」系指可变更组织过程和技术的所有构想(含已证明及未证明的)，以更符合组织的质量和过程绩效目标。本过程域所说明的质量和过程绩效目标，可包括： • 改进的产品质量(例如：功能、绩效) • 提升的生产力 • 减低的周期时间 • 更高的客户和最终使用者满意度 • 因应变更功能、增加新特性或采用新技术，较短的开发和生产时间 • 减少交付时间 • 减少适应新技术及经营需要的时间这些目标的达成有赖于成功的建立一个基础架构，以促成并鼓励所有同行，提出组织过程和技术的可能改进措施。这些目标的达成也有赖于有效地评估与部署所建议的改进措施。所有同行都能参与过程和技术的改进活动，而且有系统的收集和处理同行的建议。在广泛部署之前，具重大变革之未经实验、高风险或创新的改进建议，应进行试行以评估其影响。自过程和技术的改进建议中挑选改进措施，以部署至整个组织的准则如下所列： • 对组织现行质量和过程绩效的量化了解 • 组织的质量和过程绩效目标 • 部署过程和技术改进后，质量和过程绩效改进的预估值 • 部署过程和技术改进的预估成本，以及可用于该部署的资源和资金必须衡量过程和技术改进带来的预期效益与其成本和对组织的冲击，并在变更与稳定之间小心取得平衡。变更太大或太快，组织将无法承受，而且会毁坏组织的学习投资，亦即破坏组织的过程资产。而一成不变的稳定也会导致停滞不前，使不断变动的经营环境腐蚀组织的经营地位。对新的与进行中的项目，适当地部署改进措施。本过程域的「过程和技术改进」系指对过程本身，以及对过程或产品技术(包括项目工作环境)之渐进和创新的改进。本过程域的参考性数据的撰写前提为特定实践适用量化管理过程。在不考虑此前提的情况下，本过程域的特定实践也可适用，不过会降低所产生的价值。本过程域的特定实践补充并扩大组织过程焦点过程域的特定实践。本过程域专注于过程改进，乃以下列两项量化的知识为基础进行过程改进：组织标准过程和技术，以及其在可预知情境下所期望的质量和绩效。在组织过程焦点过程域中，并没有关于改进之量化基础的假设。相关过程域有关将已部署的过程改进措施纳入组织过程资产，请参考组织过程定义过程域，以获得更多信息。有关过程改进建议的征求、收集及处理，以及协调将过程改进的部署纳入项目已定义过程，请参考组织过程焦点过程域，以获得更多信息。有关提供最新培训以支持过程和技术改进的部署，请参考组织培训过程域，以获得更多信息。有关质量和过程绩效目标，以及过程绩效模型，请参考组织过程绩效过程域，以获得更多信息。质量和过程绩效目标用以分析和选择所要部署的过程和技术改进建议。过程绩效模型则用以量化创新所带来的冲击和效益。有关建立度量与分析的目标、识别待执行的度量与分析、取得和分析度量数据，以及报告结果等，请参考度量与分析过程域，以获得更多信息。有关协调将过程和技术改进之部署纳入项目已定义过程和项目工作环境，请参考集成的项目管理过程域，以获得更多信息。有关改进建议和创新的正式评估，请参考决策分析与解决方案过程域，以获得更多信息。特定目标及实践摘要 SG 1 选择改进措施 SP 收集并分析改进建议 SP 识别并分析创新 SP 试行改进措施 SP 选择改进措施以便部署 SG 2 部署改进措施 SP 规划部署计划 SP 管理部署工作 SP 度量改进效果各目标的特定实践 SG 1 选择改进措施选择有助于符合质量与过程绩效目标的各种过程与技术改进措施。 SP 收集并分析改进建议收集并分析过程与技术的改进建议。必须分析每个过程和技术的改进建议。通常不需要详细评估容易了解其效益及影响的简单过程和技术改进措施。简单的过程和技术改进措施，举例如下： • 增加一个项目至同行评审检查表。 • 将对供应商所进行的技术和管理两项审查，合并为单一的技术／管理审查。典型的工作产品 1. 已分析的过程和技术改进建议子实践 1. 收集过程和技术的改进建议。过程和技术改进建议记录对特定过程和技术之渐进和创新的改进建议。组织中的管理者和成员，以及客户、最终使用者及供应商，都能提出过程和技术改进建议。在提议到整个组织实施之前，过程和技术改进措施应先局部实施。过程和技术改进建议的来源，举例如下： • 过程评估的调查结果和建议 • 组织质量和过程绩效的目标 • 客户和最终使用者的问题，以及客户及最终使用者满意度的数据分析 • 项目绩效与质量和生产力目标比较的数据分析 • 技术绩效度量的分析 • 过程和产品标竿学习工作的结果 • 缺陷原因的资料分析 • 过程活动的度量成效 • 项目工作环境的度量成效 • 过程和技术改进建议于其它地方成功采用的范例 • 先前提出之过程和技术改进建议的反馈 • 项目经理和成员自发的构想有关过程和技术改进，请参考组织过程焦点过程域，以获得更多信息。 2. 适当地分析过程和技术改进建议的成本和效益。如果过程和技术改进建议的本益比太高，应予排除。评估成本和效益的准则如下： • 满足组织质量和过程绩效目标的贡献程度 • 对减轻已识别之项目和组织风险的影响 • 对项目需求、市场状况及经营环境等变更的快速反应能力 • 对相关过程和资产的影响 • 收集和定义数据的成本，该数据用以支持过程和技术改进建议之度量与分析 • 改进建议的预期期限不能改进组织过程的过程和技术改进建议，应予排除。过程绩效模型可以洞察过程变更在过程能力和绩效上的影响。有关过程绩效模型，请参考组织过程绩效过程域，以获得更多信息。 3. 识别具创新的过程和技术改进建议。「识别并分析创新」特定实践也识别并分析创新的改进。「识别并分析创新」特定实践用以主动寻求和找出创新改进，而本特定实践用于分析被动收集的建议。「识别及分析创新」特定实践的「寻求」主要是从组织外找寻。创新改进的识别通常藉由审查过程和技术改进建议，或积极调查和追踪其它机构所使用或研究文献所记载的创新着手。创新可能由内部的改进目标或外在经营环境所激发。创新的改进通常是过程的重要变更，它代表自旧有做事方法的一种脱离，例如生命周期方法论的变更。创新的改进也可能包括支持过程、加强过程，或使过程自动化之产品的变更。例如：使用现成品以支持过程。创新改进，举例如下： • 先进的计算机和相关硬件产品 • 新的支持工具 • 新的技术、方法、过程或生命周期模型 • 新的接口标准 • 新的复用组件 • 新的管理技术 • 新的质量改进技术 • 新的过程开发和部署支持工具 4. 识别部署过程和技术改进建议的潜在障碍和风险。部署过程和技术改进的障碍，举例如下： • 本位主义和狭窄的眼光 • 不清楚或不坚定的经营理念 • 缺少短期效益和可见的成功 • 对每个人的期望不清楚 • 同一时间有太多的变更 • 缺少相关的干系人的参与和支持影响过程和技术改进部署的风险因素，举例如下： • 改进措施与现有过程、价值观及潜在最终使用者技能的兼容程度 • 改进的复杂度 • 实施改进的困难度 • 在全面部署前，展示改进价值的能力 • 在某些方面(如工具和培训)进行大额、前期投资的正当理由 • 因现有技术已成功地被大量成熟的最终使用者所采用，故无法克服的「技术障碍」 5. 估计部署每个备选过程和技术改进建议所需的成本、工作量及进度。 6. 在大规模部署前，先选择一些过程和技术改进建议进行试行。依据定义，创新通常代表重大变更，所以大部分的创新改进应先试行。 7. 记录每个过程和技术改进建议的评估结果。 8. 监督每个过程和技术改进建议的状况。 SP 识别并分析创新识别并分析能增加组织质量与过程绩效的创新改进措施。「收集并分析改进建议」特定实践系分析被动收集的建议，而本特定实践系主动寻求和找出创新改进措施，而且主要是从组织外找寻。典型的工作产品 1. 备选的创新改进措施 2. 所建议之创新改进措施的分析子实践 1. 分析组织标准过程，以决定这些创新改进措施对哪些领域最有参考。执行这些分析，以决定达到组织质量和过程绩效目标具关键性的子过程，以及可加以改进的备选子过程。 2. 调查研究可改进组织标准过程的创新改进措施。创新改进的调查，可包括： • 有系统地留意领先的工作相关技术和技术趋势 • 定期寻求市面上可用的创新改进措施 • 收集来自项目和组织的创新改进建议 • 有系统地审查外界使用的过程和技术，并与组织内部所使用的相互比较 • 识别已成功使用创新改进的领域，并审查这些改进措施的数据和经验文档 • 识别集成新技术到产品及项目工作环境的改进措施 3. 分析具潜力的创新改进措施，以了解它们对过程组件的效果，并预测它们对过程的影响。过程绩效模型提供基础，以分析过程组件变更的可能影响。有关过程绩效模型，请参考组织过程绩效过程域，以获得更多信息。 4. 分析具潜力之创新改进措施的成本和效益。如果创新改进的本益比太高，应予排除。 5. 针对可导致改进组织过程或技术的创新改进措施，制作过程和技术改进建议。 6. 在大规模部署之前，应选择创新改进措施进行试行。依据定义，创新通常代表重大变更，所以大部分的创新改进应先试行。 7. 记录创新改进措施的评估结果。 SP 试行改进措施试行过程与技术改进措施，以选择适合部署的措施。在大规模部署之前，适当地试行创新改进，以评价新的和未经证明的重大变更。本特定实践可与原因分析与解决方案过程域的「实施行动建议书」特定实践重迭实施，例如：当整个组织或跨多个项目实施原因分析与解决方案的时候。典型的工作产品 1. 试行的评估报告 2. 试行的学习心得子实践 1. 规划试行计划。在规划试行计划时，定义用以评估试行结果的量化准则是重要的。 2. 审查试行计划，并取得相关干系人的同意。 3. 提供咨询和帮助予执行试行计划的人员。 4. 在具有大规模部署性的环境下，执行每个试行计划。 5. 按照计划，追踪试行的情况。 6. 审查并记录试行的结果。试行结果是使用在进行试行规划时，所定义的量化准则加以评估。审查并记录试行的结果，通常包括： • 决定是否结束试行、重新规划并继续试行，或进行过程和技术改进的部署 • 更新配合试行之过程和技术改进建议的安排 • 适当的识别并记录新的过程和技术改进建议 • 识别并记录在试行时所遇到的问题和学习心得 SP 选择改进措施以便部署选择过程与技术的改进措施，以便在组织内部署。推动整个组织的过程和技术改进措施，其选择方式是以可量化的准则为基础，而该准则是由组织的质量和过程绩效目标衍生而来。典型的工作产品 1. 已选定用以部署之过程和技术的改进措施子实践 1. 排定过程和技术改进措施的部署优先级。优先级是以预估本益比的评估为基础，该本益比与质量和过程绩效目标有关。有关质量和过程绩效目标，请参考组织过程绩效过程域，以获得更多信息。 2. 选择要在组织内部署的过程和技术改进措施。过程改进措施的评选系以其优先级和可用资源为基础。 3. 决定如何部署每个过程和技术改进措施。何处可以部署过程和技术改进措施，举例如下： • 组织过程资产 • 组织的产品系列 • 组织的能力 • 组织的项目 • 组织的团队 4. 记录评选过程的结果。评选过程的结果，通常包括： • 评选候选改进措施的准则 • 每个改进建议的处理方式 • 每个改进建议之处理方式的理由 • 每个选定的改进措施将变更的资产 SG 2 部署改进措施针对组织的过程与技术，持续及有系统地推广各种可度量的改进措施。 SP 规划部署计划针对已选定的过程与技术改进措施，建立并维护部署计划。每个过程和技术改进的部署计划，可包含在组织创新和部署计划中，也可以个别文档记载。本特定实践的实施，补足了组织过程焦点过程域中，部署组织过程资产的特定实践，并加入量化数据的使用，来指导部署，与决定有关质量及过程绩效目标的改进价值。有关部署组织过程资产，请参考组织过程焦点过程域，以获得更多信息。本特定实践规划个别过程和技术改进的部署。而「规划过程」通用实践则注重广泛的规划活动，它涵盖本过程域的特定实践。典型的工作产品 1. 已选定之过程和技术改进措施的部署计划子实践 1. 决定如何调整每个过程和技术改进措施，以便在整个组织内部署。在有限范围(如单一项目)内的过程和技术改进，如果要适用于全组织，或许须进行一些修正。 2. 决定必要的变更，以便部署每个过程和技术改进措施。部署过程和技术改进措施，须进行的变更，举例如下： • 过程说明、标准及程序 • 工作环境 • 教育培训 • 技能 • 现有承诺 • 现有活动 • 对最终使用者的持续支持 • 组织文化和特色 3. 识别各种策略，以便克服每个过程和技术改进措施部署时的潜在障碍。 4. 建立度量和目标，以决定每个过程和技术改进措施相对于组织经营目标的价值。决定过程和技术改进价值的度量，举例如下： • 投资报酬 • 过程或技术改进的成本回收所需时间 • 项目或组织过程绩效的已度量改进 • 藉由过程和技术改进，减轻之项目和组织风险的数目和类型 • 对项目需求、市场状况及经营环境的变更快速反应的能力有关建立度量与分析的目标、识别待执行的度量与分析、取得和分析度量数据，以及报告结果等，请参考度量与分析过程域，以获得更多信息。 5. 记录每个过程和技术改进措施的部署计划。 6. 审查每个过程和技术改进措施的部署计划，并取得干系人的同意。 7. 必要时，修订每个过程和技术改进措施的部署计划。 SP 管理部署工作针对已选定的过程与技术改进措施，管理其部署情况。本特定实践可与原因分析与解决方案过程域的「实施行动建议书」特定实践重迭实施，例如：当整个组织或跨多个项目实施原因分析与解决方案的时候。主要差异在于原因分析与解决方案过程域的规划，是用于管理如何移除项目已定义过程之缺陷或问题的根本原因，而组织创新与部署过程域的规划，是用于管理如何部署符合组织经营目标之组织过程和技术的改进措施。典型的工作产品 1. 最新的培训教材(以反映已部署的过程和技术改进措施) 2. 过程和技术改进措施部署活动的纪录 3. 已修订的过程和技术改进措施之度量、目标、优先级及部署计划子实践 1. 使用部署计划，监督过程和技术改进措施的部署情形。 2. 协调组织内过程和技术改进措施的部署活动。部署的协调活动，包括： • 协调每个过程和技术改进之项目、支持小组及组织中各小组的活动。 • 协调相关之过程和技术改进的各项部署活动。 3. 以受控制、有纪律的适当方式，快速部署过程和技术改进措施。快速部署过程和技术改进措施的方法，举例如下： • 使用划红线、过程变更通告，或其它纳管过程的文档，作为暂时的过程说明 • 渐进地部署过程和技术改进措施，而非一步完成 • 对过程和技术改进措施的早期采用者，提供广泛的顾问咨询，以代替已修订的正式培训 4. 适当地把过程和技术改进措施集成至组织过程资产。有关组织过程资产，请参考组织过程定义过程域，以获得更多信息。 5. 将过程和技术改进措施的部署，适当地融入项目已定义过程。有关部署组织过程资产，请参考组织过程焦点过程域，以获得更多信息。 6. 提供适当的咨询服务，以支持过程和技术改进措施的部署。 7. 提供最新的培训教材，以反映组织过程资产的改进。有关培训教材，请参考组织培训过程域，以获得更多信息。 8. 确认所有过程和技术改进措施的部署皆已完成。 9. 决定已定义过程满足质量和过程绩效目标的能力，是否受到过程和技术改进措施的负面影响。必要时，采取纠正措施。有关量化管理项目已定义过程以达成项目所设定的质量和过程绩效目标，请参考量化项目管理过程域，以获得更多信息。 10. 记录并审查过程和技术改进措施部署的结果。记录并审查结果，包括： • 识别并记录学习心得 • 识别并记录新过程和技术的改进建议 • 修订过程和技术改进的度量、目标、优先级及部署计划 SP 度量改进效果针对已推广的过程与技术改进措施，度量其效果。有关建立度量与分析的目标、识别待执行的度量与分析、取得和分析度量数据，以及报告结果等，请参考度量与分析过程域，以获得更多信息。本特定实践可与原因分析与解决方案过程域的「评估变更的效果」特定实践重迭实施，例如：当整个组织或跨多个项目实施原因分析与解决方案的时候。典型的工作产品 1. 部署过程和技术改进效果度量的纪录子实践 1. 度量部署每个过程和技术改进措施所需的成本、工作量及进度。 2. 度量每个过程和技术改进措施的价值。 3. 度量改进措施在达成组织质量和过程绩效目标的进度。 4. 分析改进措施在达成组织质量和过程绩效目标的进度。必要时，实行纠正措施。有关过程绩效分析，请参考组织过程绩效过程域，以获得更多信息。 5. 存储度量结果于组织度量资产库中。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施组织创新与部署过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行组织创新与推进过程。详细说明：本方针建立组织对下列活动的期望：识别及部署过程和技术改进措施，以有助于满足质量和过程绩效目标。 GP 规划过程建立并维护用来执行组织创新与推进过程的计划。详细说明：本计划用于执行组织创新与部署，不同于本过程域的特定实践所描述的部署计划。通用实践所谓的计划，乃在说明本过程域特定实践的广泛规划，从收集和分析改进建议，一直到改进影响的度量。而特定实践的部署计划则强调部署个别过程和技术改进建议时所需的规划。 GP 提供资源提供充分的资源，以执行组织创新与部署过程、开发工作产品及提供过程服务。详细说明：提供的资源，举例如下： • 模拟软件包 • 原型工具 • 统计软件包 • 动态系统模型 • 订阅在线技术数据库及发布刊物 • 过程模型工具 GP 分配责任分配组织创新与部署过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持组织创新与部署过程。详细说明：培训主题，举例如下: • 规划、设计及进行试行 • 成本/效益分析 • 技术移转 • 变更管理 GP 管理配置将指定的组织创新与部署过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 试行的学习心得纪录 • 已修订之过程和技术改进的度量、目标、优先级及部署计划 • 最新的培训教材 GP 识别并纳入相关的干系人依计划识别并纳入组织创新与部署过程相关干系人。详细说明：干系人参与的活动，举例如下： • 审查过程和技术的改进建议，该建议对过程绩效或客户和最终使用者满意度可能有重大影响。 • 提供组织有关过程和技术改进部署活动的结果和状态的反馈。反馈通常包括： • 通知提出过程和技术改进建议的人，有关对其建议的处理方式。 • 定时通知干系人有关选择与部署过程和技术改进的计划和状态。 • 准备并分发过程和技术改进之选择与部署活动的摘要。 GP 监控过程依过程的执行计划，监控组织创新与部署过程，并采取适当的纠正措施。详细说明：用于监控的度量，举例如下: • 质量的变更 • 过程绩效的变更 • 部署已选定改进措施活动的进度 GP 客观评价遵循程度依过程的说明、目标、标准及程序，客观评估组织创新与部署过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 选择改进措施 • 部署改进措施审查的工作产品，举例如下： • 部署计划 • 已修订之过程和技术改进的度量、目标、优先级及部署计划 • 最新的培训教材 GP 与高层管理人员审查各状况与高层管理人员审查组织创新与部署过程的活动、状况及结果，并解决问题。仅适用于连续式表述GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义组织创新与部署过程的说明。 GP 收集改进信息收集由规划和执行组织创新与部署过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 从相关干系人的经验分享，识别来自于先前技术植入推行时的阻碍 • 因部署创新所记录的成本与效益度量 • 相似开发过程的比较报告，用以识别改进效率的可能性。仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护组织创新与部署过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定组织创新与部署过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保组织创新与部署过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因界定并纠正组织创新与部署过程的缺失与其他问题的根本原因。组织过程定义+ IPPD （OPD 3级）成熟度第三级的过程管理类过程域目的简介组织过程定义的目的是建立并维护可用的组织过程资产与工作环境标准。 IPPD 补充适用于IPPD，组织过程定义+IPPD 也包含组织规则与指导的建立，以能使用集成团队执行工作。组织过程资产使整个组织有一致的过程绩效，并且提供组织一累积性、长期性效益的基础。(「组织过程资产」的定义在词汇中) 组织过程资产库是收集数据项的地方，并由组织维护，以提供组织人员及项目使用。组织过程资产库收集的数据项包括：过程与过程组件的说明、生命周期模型的说明、过程定义指导、过程相关的文档及数据。组织过程资产库允许全组织共享最佳实践与学习心得，以支持组织学习与过程改进。项目引用组织标准过程，将其定义成项目定义的过程。而其它组织过程资产可用来支持定义或建置已定义过程。工作环境的标准是用来建立项目工作环境。标准过程由其它过程或过程组件所组成。过程组件是过程定义的基本单位(例如：原子)，它说明一致性执行工作的活动与工作项目。过程架构提供在标准过程中连接过程组件的规则。组织标准过程可包含多个过程架构。「标准过程」、「过程架构」与「过程组件」的定义，请参见词汇。依组织过程定义过程域的建置，组织过程资产可以多种方式组织起来。举例如下： • 生命周期模型的说明，可以成为组织标准过程的一部分文档，或是独立成另一文档。 • 组织标准过程可以存储在组织过程资产库，或是单独存储。 • 可用单一存储库存储度量及过程相关文档，或是二者分开存储。相关过程域有关组织过程相关的事项，请参考组织过程焦点过程域，以获得更多的信息。特定目标及实践摘要 SG 1 建立组织过程资产 SP 建立标准过程 SP 建立生命周期模型说明 SP 建立定义准则及指导 SP 建立组织度量资产库 SP 建立组织过程资产库 SP 建立工作环境标准 IPPD 补充 SG 2 促成IPPD 管理 SP 建立授权机制 SP 建立集成团队规则与指导 SP 平衡团队与原隶属组织的责任各目标的特定实践 SG 1 建立组织过程资产建立并维护组织过程资产。 IPPD 补充集成的过程强调同步而不是循序列的开发，它是执行IPPD 的基石。产品开发过程及产品相关的生命周期过程(如制造过程开发与支持过程开发的过程)同步执行。集成的过程应该包含代表产品生命周期各阶段经营与技术功能的干系人所提供的信息，也需要有效的团队工作过程。 SP 建立标准过程建立并维护组织标准过程。在企业中，标准过程可定义成多个层次，并且能以架构性层次互相关联。例如：一个企业的标准过程，可由个别组织(例如：部门或地点)进行定义，以建立自己的标准过程。标准过程可按各个组织经营领域或产品线定义而得。因此组织标准过程可以参照在组织层次所建立的标准过程，以及在组织较低层次所建立的标准过程。某些组织可能只有单一层次的标准过程。(「标准过程」与「组织的一组标准过程」的定义，请参见词汇。) 多个标准过程可能同时存在，以满足不同的应用领域、生命周期模型、方法及工具的需要。过程架构描述过程组件之间的关联，组织标准过程包含过程组件(例如：估算工作产品规模大小的组件)，而这些组件在一个或多个过程架构中互相关联。过程可能由一些过程或过程组件组成。组织标准过程通常包括技术、管理、行政、支持及组织的过程。 IPPD 补充在IPPD 环境，组织的一组标准过程包括项目用来建立共同愿景的过程。组织标准过程应涵盖组织与项目所需的全部过程，包括成熟度第2 级的过程域。典型的工作产品 1. 组织标准过程子实践 1. 分解个别的标准过程为构成的过程组件，使详细到足以了解并说明过程。每个过程组件包含一组紧密相关的活动。过程组件的说明可能是供填写的样板、供完整组合的组件、供进一步细致化的抽象概念，或供定义或不经修改即可采用的完整说明。这些组件以充分详尽的方式说明，以致于过程经完整地定义后，经过适当培训与具备技能的人员能够一致地执行。过程组件，举例如下： • 产生工作产品规模大小估计的样板 • 工作产品设计方法的说明 • 可定义的同行评审方法 • 执行管理审查的样板 2. 识别每一过程组件的重要属性。重要属性，举例如下： • 过程的角色 • 适用的标准 • 适用的程序、方法、工具及资源 • 过程绩效目标 • 入口准则 • 输入 • 需收集与使用的产品与过程度量 • 验证点(例如：同行评审) • 输出 • 界面 • 出口准则 3. 识别各过程组件的关联。关联，举例如下： • 过程组件的次序 • 过程组件之间的接口 • 与外部过程的接口 • 过程组件之间的相依性说明过程组件之间关联的规则叫做「过程架构」，过程架构涵盖重要的需求与指导。这些关联的详细规格包含于已定义过程中，而已定义过程是由组织标准过程定义而得。 4. 确保组织标准过程是遵循适用的方针、过程标准与模型，以及产品标准。遵循适用的过程标准与模型，通常以制作组织标准过程与相关过程标准及模型的对照表来证明，而且这个对照表可作为未来评估时有用的输入数据。 5. 确保组织标准过程能满足过程需要与组织目标。有关建立并维护组织过程的需要与目标，请参考组织过程焦点过程域，以获得更多的信息。 6. 确保组织标准过程中的各个过程，都能恰当地集成。 7. 记录组织标准过程。 8. 对组织标准过程执行同行评审。 9. 必要时，修订组织标准过程。有关同行评审，请参考验证过程域，以获得更多的信息。 SP 建立生命周期模型说明建立并维护生命周期过程模式的说明，经批准后在组织中使用。对于不同的客户与不同的情况，可能开发多个生命周期模型，因为只有一个生命周期模型可能不适用于所有情况。生命周期模型常用来定义项目的阶段，同时组织对每一产品与服务种类，可能定义不同的生命周期模型。典型的工作产品 1. 生命周期模型的说明子实践 1. 根据项目与组织的需要，选择生命周期模型。项目的生命周期模型，举例如下： • 瀑布式 • 螺旋式 • 演进式 • 渐进式 • 反复式 2. 文档化生命周期模型的说明。生命周期模型可以成为组织标准过程说明的一部分文档，或独立成另一文档。 3. 对生命周期模型执行同行评审。有关执行同行评审，请参考验证过程域，以获得更多的信息。 4. 必要时，修订生命周期模型的说明。 SP 建立裁剪准则及指导建立并维护组织标准过程的裁剪准则及指南。 IPPD 补充制作定义准则与指导时，须包含同步开发以及与集成小组运作的考量。例如：如何定义制造过程，其结果将有赖于在产品开发后再依序进行，或像在IPPD 环境中，产品开发时同步进行而有所不同。以资源分配过程为例，如果项目是与集成小组运作，也会作不同的定义。定义准则及指导说明下列事项： • 如何引用组织标准过程及组织过程资产，以产生已定义过程 • 已定义过程必须满足必要的需求(例如：对于已定义过程非常重要的组织过程资产的子集合) • 列出可选择的项目及选择的准则 • 执行与记录过程定义时必须遵循的程序定义的原因，举例如下： • 为新的产品线或主机环境而定义过程 • 为特定的应用或应用类别(例如：启动开发、维护或制作原型)而将过程客户化 • 更详尽的过程说明，以使已定义过程能够执行在定义与定义过程的弹性以及确保全组织过程的适当一致性之间，须作平衡。弹性是需要的，以满足范围的变量，例如：专业领域，客户特性，成本、进度及质量取舍分析，工作的技术难度，以及执行过程的人员经验。在组织中须有一致性，以能够适当满足组织标准、目标及策略，并且能够分享过程数据与学习心得。定义准则与指导允许标准过程就是已定义过程，不需要定义。典型的工作产品 1. 组织标准过程的定义指导子实践 1. 识别用以定义组织标准过程的选择准则及程序。准则与程序，举例如下： • 由组织批准的生命周期模型中进行选择的准则 • 由组织标准过程中选择过程组件的准则 • 为了适合特定过程的特性与需求，定义选定的生命周期模型与过程组件的程序定义行动，举例如下： • 修改生命周期模型 • 组合不同生命周期模型的组件 • 修改过程组件 • 替换过程组件 • 重新排列过程组件的顺序 2. 识别文档化已定义过程的标准。 3. 针对组织标准过程的需求，识别用以提出及取得豁免权批准的程序。 4. 文档化组织标准过程的定义指导。 5. 对定义指导执行同行评审。有关执行同行评审，请参考验证过程域，以获得更多的信息。 6. 必要时，修订定义指导。 SP 建立组织度量资产库建立并维护组织度量资产库。有关使用组织度量资产库于规划项目活动，请参考集成的项目管理过程域的「使用组织过程资产规划项目活动」特定实践，以获得更多信息。存储库包含与组织标准过程相关的产品度量与过程度量。存储库也包含或引用了解与解释度量，并评价其合理性与适用性所需的信息。例如：引用度量的定义以比较不同过程的相同度量。典型的工作产品 1. 组织标准过程的共同产品与过程度量的定义 2. 组织度量资产库的设计 3. 组织度量资产库(即存储库结构及支持环境) 4. 组织度量数据子实践 1. 决定组织存储、取用及分析度量的需要。 2. 定义组织标准过程中产品及过程的共同度量。共同度量是根据组织标准过程而选出。所选定的度量是有能力提供过程绩效之可视性，以支持预期的商业目标。共同共同度量可能会因不同的标准过程而不同。度量的操作定义说明收集正确数据的程序及在过程中的数据收集点。一般共同使用的度量类型，举例如下： • 工作产品规模大小(例如：页数)的估计值 • 工作量及成本(例如：人时)的估计值 • 规模大小、工作量及成本的实际度量 • 质量度量(例如：发现的错误数量、错误的严重程度) • 同行评审的涵盖度 • 测试涵盖范围 • 可靠性度量(例如：平均故障次数) 有关定义度量，请参考度量与分析过程域，以获得更多的信息。 3. 设计及配置度量资产库。 4. 识别存储、更新及取用度量的程序。 5. 对于共同度量的定义，以及存储与取用度量的程序，执行同行评审。有关执行同行评审，请参考验证过程域，以获得更多的信息。 6. 将指定的度量放入存储库。有关收集与分析资料，请参考度量与分析过程域，以获得更多的信息。 7. 使过程度量资产库的内容，能够让组织及项目恰当地使用。 8. 当组织需求变更时，修订度量资产库、共同度量及程序。共同度量需要修订的时机，举例如下： • 新增过程 • 修订过程及需要新过程度量 • 需要更细节的数据 • 需要更具清晰度的过程 • 需要淘汰的度量 SP 建立组织过程资产库建立并维护组织过程资产库。存储在组织过程资产库的数据项，举例如下： • 组织方针 • 已定义过程的说明 • 程序(例如：估计程序) • 开发计划 • 采购计划 • 质量保证计划 • 培训教材 • 过程的辅助工具(例如：检查清单) • 学习心得报告典型的工作产品 1. 组织过程资产库的设计 2. 组织过程资产库 3. 已选定将要放入组织过程资产库的数据项 4. 组织过程资产库数据项的目录子实践 1. 设计并配置组织过程资产库，包括组织过程资产库的结构及支持环境。 2. 识别数据项纳入组织过程资产库的准则。纳入的数据项主要依据它们与组织标准过程的关联性。 3. 识别存储与取用数据项的程序。 4. 将已选择的数据项纳入组织过程资产库中，并编入目录，使之容易参考及取用。 5. 使数据项可供各项目使用。 6. 定期审查个别数据项的使用情况，并引用其结果以维护资产库的内容。 7. 必要时，修订组织过程资产库。需要修订组织过程资产库的时机，举列如下： • 新增数据项 • 淘汰数据项 • 变更现有数据项版本 SP 建立工作环境标准建立和维护工作环境标准。工作环境标准允许组织及项目，从共享的工具、培训及维护中获益，同时从大量采购中节省成本。工作环境标准描述所有相关干系人的需要，并考量生产力、成本、可用性、保全性及工作地点健全、安全性，以及人因工程因素。工作环境标准包括定义与/或使用豁免的指导，能让工作环境标准适应并符合特定需要。工作环境标准，举例包括： • 工作环境操作、安全及保全性的程序 • 标准工作站的硬件及软件 • 标准应用软件及其定义指导 • 标准生产及机器等级 • 请求及批准定义或豁免的过程典型工作产品 1. 工作环境标准子实践 1. 评估适合组织之市售可用的工作环境标准。 2. 实行现存工作环境标准，并以组织过程需要及目标为基础，开发新的工作环境标准来弥补差距。 IPPD 补充 SG 2 促成IPPD 管理提供组织规则及指引，来管理集成团队的营运。如果能成功的长期维持组织基础建设，来支持及提倡IPPD 的观念，是具关键性的。这些规则及指导所提倡的观念，例如：集成团队，以及容许在不同的等级做授权的决策。通过其规则及指导，组织显示对于IPPD 及集成团队成功的承诺。 IPPD 规则及指导成为组织标准过程及项目已定义过程的一部分。组织标准过程有能力提倡及加强来自于项目、集成团队及人员所期望的行为。这些期望行为以方针、操作程序、指导，和其它组织过程资产作为典型的沟通形式。 SP 建立授权机制建立及维护授权机制，能够及时做决策。在成功的IPPD 环境，必须建立责任及授权的透明渠道。当集成团队承担授权太多或太少，与决策者不明确时，组织任何等级都可以提出问题。文档化与部署清楚定义集成团队的授权的组织指导，都可避免这些问题。当授权给人员或集成团队，且决策降至较低的适当等级，IPPD 的实施引发领导阶层的挑战，因为需要文化改变。有效果及有效率的沟通机制，在集成工作环境中，对于及时和明智的决策是关键的。一旦建立了集成团队项目架构及提供培训，也必须提供处理授权、进行决策，和问题解决的机制。有关进行决策，请参照决策分析及解决方案过程域，以获得更多信息。典型工作产品 1. 针对人员及集成团队的授权规则及指导 2. 决策指定的规则及指导 3. 问题解决的文件子实践： 1. 决定授权给人员或集成团队不同等级的规则及指导。集成团队授权应考虑的因素，包括下列： . 授权团队选择自己的领导者 . 授权团队建立子团队（例如：产品团队组成集成子团队） . 集合做决策的等级 . 集合团队决策所需的共性等级 . 集成团队内，不同冲突及意见如何陈述及解决 2. 决定不同决策形态所使用的规则及指导，以做出不同种类的团队决策。 3. 定义使用决策指定规则及指导的流程。 4. 定义当问题发生时无法在该等级做决定的问题解决方案过程。有关与干系人解决问题，请参照集成项目管理过程领域中，解决协调问题特定实践，以获得更多信息。 5. 维护授权机制及决策的规则及指导。 SP 建立集成团队的规则及指导建立及维护组织规则及指导，以架构及组成集成团队。。集成团队的运作规则及指导可用以定义及控制团队如何相互影响以完成目标。这些规则及指导也提倡有效集成团队的工作量、高绩效、及生产力。集成团队成员必须了解工作的标准，并根据这些标准来参与。典型工作产品 1. 架构及组成集成团队的规则及指导子实践 1. 建立架构及组成集成团队的规则及指导。组织过程信息能帮助项目来架构及实施集成团队。这样的信息包括如下： . 团队架构指导 . 团队组成指导 . 团队授权及责任指导 . IPPD执行技巧 . IPPD管理风险指导 . 建立沟通及授权的指导 . 团队领导者选择情境 . 团队职责指导 2. 定期期望、规则及指导，引导集成团队如何共同工作。这些规则及指导，建立了跨集成团队的组织实践的一致性。 • 集成团队间的接口，如何建立与维护 • 如何接受指派 • 如何使用资源及输入 • 如何完成工作 • 谁来检查、审查及批准工作 • 如何批准工作 • 如何交付及沟通工作 • 报告链 • 报告需求（成本、进度及绩效状态）、度量及方法 • 进度报告的度量及方法 3. 维护架构及组成集成团队的规则及指导。 SP 平衡团队及原隶属组织的责任建立及维护组织指引，以帮助团队成员平衡团队及隶属组织责任。隶属组织是组织的一部分，当团队成员不属于集成团队，就可被分配。隶属组织也可称为功能组织、隶属基础、隶属办公室，或直接组织。隶属组织通常负责其成员的职涯成长（例如：绩效评估，及培训以维护功能性与领域的专门知识）。在IPPD 环境中，报告程序及职等系统都认为成员的责任应专注于集成团队，而非隶属组织。然而，集成团队成员的责任对于隶属组织也是重要的，特别对于过程的执行与改进。应平衡项目、功能，和职涯成长及进阶间的工作量与责任。协调工作量以符合在团队环境的经营目标的同时，组织机制应支持隶属组织。有时团队坚持跳脱在组织的生产生活，在集成团队解散后，并无隶属组织，让团队成员回去。因此，必须有解散集成团队的指导，并维持隶属组织。典型工作产品 1. 平衡团队及隶属组织责任的组织指导 2. 绩效审查过程，同样考虑到功能监督人员及团队领导者的输入子实践 1. 建立隶属组织责任的指导，以提倡集成团队行为。 2. 建立团队管理责任，以确保集成团队成员可适当地报告给其隶属组织。 3. 建立绩效审查过程，以考虑从隶属组织及集成团队领导者的输入。 4. 维护平衡团队及隶属组织责任的指导。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施组织过程定义过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。本通用目标反映在阶段式表述的位置 GP 建立组织方针建立并维护组织的方针，以规划和执行组织过程定义过程。详细说明：方针为建立组织的期望，以建立并维护标准过程可供组织使用，并且使组织过程资产能够在全组织中使用。 GP 规划过程建立并维护用来执行组织过程定义过程的计划。详细说明：本执行组织过程定义过程计划是组织过程改进计划的一部分(或参照)。 GP 提供资源提供充分的资源，以执行组织过程定义过程、开发工作产品及提供过程服务。详细说明：过程组通常管理组织过程定义活动，且通常由专业人员所组成，主要责任是联系组织过程改进。过程组是由过程的负责人，以及在各种专业领域上有经验的人员作支持，举例如下： • 项目管理 • 适当的工程专业领域 • 配置管理 • 质量保证其它提供的资源，举例如下： • 数据库管理系统 • 过程模型工具 • 网页的制作及浏览器 GP 分配责任分配组织过程定义过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持组织过程定义过程。详细说明：培训的主题，举列如下： • CMMI 与其它过程及过程改进参考模型 • 过程的规划、管理及监督 • 过程模型与定义 • 开发可定义的标准过程 • 开发工作环境标准 • 人因工程学 GP 管理配置将指定的组织过程定义过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 组织标准过程 • 生命周期模型的说明 • 组织标准过程的定义指导 • 共性产品与过程度量的定义 • 组织度量数据 IPPD 补充纳入控制的工作产品，举例如下： •人员与集成团队的激励规则与指导 •问题解决的组织过程文档 GP 识别并纳入相关的干系人依计划识别并纳入组织过程定义过程相关干系人。详细说明：干系人参与活动，举例如下： • 审查组织标准过程 • 审查组织的生命周期模型 • 解决定义指导相关的问题 • 评价共性过程与产品度量的定义 • 审查工作环境标准 IPPD 补充干系人参与的活动，举例如下： •建立与维护IPPD 授权机制 •建立与维护组织规则与集成团队的结构与组成的指导 GP 监控过程依过程的执行计划，监控组织过程定义过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 项目使用组织标准过程的过程架构与过程组件的百分比 • 组织标准过程的每一过程组件之缺陷密度 • 由于人因问题的工作补偿请求的数目 • 过程或过程变更开发的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估组织过程定义过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立组织过程资产 IPPD 补充审查的活动，举例如下： •决定提供给人员及集成团队的授权等级的规则与指导 •建立与维护问题解决过程审查的工作产品，举例如下： • 组织标准过程 • 生命周期模型的说明 • 组织标准过程的定义指导 • 组织度量数据 IPPD 补充审查工作产品，举例如下： • 人员与集成团队的授权规则与指导 • 组织过程文档 GP 与高层管理人员审查各状况与高层管理人员审查组织过程定义过程的活动、状况及结果，并解决问题。仅适用于连续式表述GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反应连续式表述的位置 GP 建立已定义过程建立并维护已定义过程的说明。 GP 收集改进信息收集由规划和执行组织过程定义过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 纳入组织过程资产库的学习心得 • 纳入组织度量资产库的度量数据 • 修改组织标准过程变更改进建议单的状况 • 无标准定义需求的纪录 IPPD 补充工作产品、度量、度量结果及改进信息，举例如下： •集成团队输入的绩效审查状况仅适用于连续式表述GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护组织过程定义过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定组织过程定义过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保组织过程定义过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正组织过程定义过程之缺陷与其它问题的根本原因。组织过程焦点（OPF 3级）成熟度第三级的过程管理类过程域目的组织过程焦点(Organizational Process Focus, OPF) 的目的在于以充分了解现行组织过程及过程资产的优点与缺点为基础，规划、执行与部署组织过程改进。简介组织过程包括组织与项目所使用的所有过程。组织过程与过程资产的可能改进由不同的来源取得，包括过程的度量、执行过程的学习心得、过程评估的结果、产品评估活动的结果、以其它组织过程标竿比较的结果，以及组织中其它改进构想的建议。过程改进源于组织需要的范围，以实现组织的目标。组织鼓励将要执行过程的人，参与过程改进活动。帮助与管理组织过程改进活动的责任(包括协调其它的参与)，通常分配给过程组。组织应提供长期的承诺及所需的资源，以支持过程组，以及确保有效与适时的部署改进。为了保证整个组织过程改进的投入人力，有充分的管理与实行，必须要有详细的规划。组织过程改进规划的成果为过程改进计划。组织过程改进计划说明评估规划、过程行动规划、试用规划及部署规划。评估计划说明评估的时间与进度、评估的范围、执行评估所需的资源、执行评估所采用的参考模型及评估的后勤支持等。过程行动计划通常由评估的结果导出，并且以评估时所发现的缺点为目标，制作如何执行改进的文档。如果描述于过程行动计划中的改进，在整个组织中部署前，决定先在小团体作测试，则会制作试用计划。最后，部署改进时，采用部署计划，该计划说明整个组织何时及如何部署改进。组织过程资产说明、执行及改进组织过程(「组织过程资产」的定义，请参考词汇)。相关过程域有关组织过程资产，请参考组织过程定义过程域，以获得更多的信息。特定目标及实践摘要 SG 1 决定过程改进机会 SP 建立组织过程需要 SP 评估组织过程 SP 识别组织过程改进 SG 2 策划与实施过程改进 SP 建立过程行动计划 SP 执行过程行动计划 SG 3 部署组织过程资产及进行经验教训总结 SP 部署组织过程资产 SP 部署标准过程 SP 监督执行 SP 协调过程经验纳入资产库各目标的特定实践 SG 1 决定过程改进机会定期与在需求的时候，识别组织过程的优点、确定及改进机会。可通过与过程标准或模型的比较，决定组织过程的优点、缺点及改进机会。过程标准或模型例如：CMMI 模型或国际标准组织(ISO)的标准。过程改进应该特别选择，以实现组织的需要。 SP 建立组织过程需要建立并维护组织过程需求及目标的说明。 IPPD 补充集成的过程强调同步而不是循序开发，它是执行IPPD 的基石。产品开发过程与产品相关的生命周期过程(如制造过程开发与支持过程开发的过程)同步执行。集成的过程需要包容代表产品生命周期各阶段经营与技术功能的干系人所提供的信息，也需要有效的团队工作过程。 IPPD 补充有效的团队工作过程，举例如下： •沟通 •合作决策 •问题解决 •团队建立必须了解组织过程运作的经营范围。组织经营的目标、需要及限制决定组织过程的需要与目标。重要的过程考虑项目通常包括：财务、技术、质量、人力资源及市场等问题。组织过程的需要与目标，涵盖下列各方面： • 过程特性 • 过程绩效目标，例如：产品上市时间与交付项目质量 • 过程有效性典型的工作产品 1. 组织的过程需要及目标子实践 1. 识别适用于组织过程的方针、标准及经营目标。 2. 检查相关的过程标准及模型，以建立最佳实践。 3. 决定组织过程绩效目标。过程绩效目标可以用定量或定性的术语表达。有关建立度量目标，请参考度量分析过程域，以获得更多信息。过程绩效目标，举例如下： • 周期 • 缺陷除去率 • 生产力 4. 定义组织过程的重要特性。组织过程的重要特性，根据下列项目来决定： • 组织中正在使用的过程 • 组织所利用的标准 • 组织客户通常强加的标准过程特性，举例如下： • 用来说明过程的详细程度 • 使用的过程符号 • 过程的详细组成 5. 记录组织过程的需要与目标。 6. 需要时，修订组织过程的需要与目标。 SP 评估组织过程定期在需求的时候，评估组织过程，以维持对于过程优点与缺点的了解。执行过程评估的理由，举例如下： • 识别出应改进的过程 • 确定进度并且使过程改进的效益显而易见 • 满足客户与供应商关系的需要 • 鼓舞与支持如果过程评估后，没有接着执行以评估为基础的行动计划，则在过程评估中所获得的同意会被严重的忽略。典型的工作产品 1. 组织过程评估的各种计划 2. 说明组织过程优缺点的评估调查报告 3. 组织过程的改进建议子实践 1. 取得高层管理人员对过程评估的赞助。高层管理人员的赞助包括承诺让组织的管理人员及职员参与过程评估，并且提供资源及经费以进行评估调查报告的分析与沟通。 2. 定义过程评估的范围。过程评估可在整个组织执行或在组织的一小部分执行，例如：一个项目或经营领域。过程评估的范围说明下列各项： • 评估所涵盖的组织定义(例如：地点或经营领域) • 在评估中能代表组织的项目与支持功能的识别 • 将接受评估的过程 3. 决定过程评估的方法与准则。过程评估可能以许多形式进行。组织的需要与目标会随时间而变更，过程评估应满足组织的需要及目标。例如：评估可依据过程模型，如CMMI 模型或依据国家或国际标准，如ISO9001 [ISO 2000]。评估也可以用标竿比较的方式与其它组织作比较。评估方法可假设下列各种特性：耗费的时间及工作量、评估组的组成，以及调查的方法与深度。 4. 过程评估的规划、进度安排及准备。 5. 执行过程评估。 6. 记录与交付评估活动与调查报告。 SP 识别组织过程改进识别组织过程及过程资产的改进。典型的工作产品 1. 可能的过程改进的分析 2. 组织过程改进的识别子实践 1. 决定可能的过程改进。可能的过程改进，可通过执行下列工作而决定： • 度量过程并分析度量结果 • 审查过程的有效性与合适性 • 检阅定义组织标准过程所得到的学习心得 • 检阅执行过程所得到的学习心得 • 审查组织管理者、职员及其它相关的干系人提出的过程改进建议 • 向组织高层管理者及领导者请求提供对于过程改进的意见 • 检查过程评估及其它过程相关审查的结果 • 检阅其它组织改进构想的结果 2. 决定可能的过程改进的优先级。决定优先级的准则如下： • 考虑执行过程改进所需的预估成本及工作量 • 针对组织改进的目标及优先级，评估预期的改进 • 决定过程改进可能遭遇的障碍，并提出克服这些障碍的策略参考决定可能的改进，并定出执行的优先级的技术，举例如下： • 比较组织目前情况与最佳情况的差距分析 • 可能改进的着力点分析，用以识别过程改进可能遭遇的障碍及克服这些障碍的策略 • 因果分析，用以提供可比较之不同改进之可能效果的信息 3. 识别并记录将要执行的过程改进。 4. 修订计划中的过程改进清单，以维持其最新状况。 SG 2 策划与实施过程改进策划与实施组织过程与过程资产改进的过程活动。成功的执行改进，需要过程负责人(也就是执行过程及支持组织的人)参与过程行动策划与实施。 SP 建立过程行动计划建立并维护过程行动计划，以实现组织过程与过程资产的改进。建立并维护过程行动计划，通常包括下列各种角色的参与： • 管理委员会建立策略，并督导过程改进活动 • 过程组人员帮助与管理过程改进活动 • 过程行动组定义并执行改进 • 过程负责人管理部署 • 过程参与人员执行过程参与有助于在过程改进中获得效益，并且能增进有效部署的可能性。过程行动计划是详细的执行计划。这些计划与组织过程改进计划不同的地方，在于它们规划特定的改进，以处理通常于评估时发现的缺点。典型的工作产品 1. 组织批准通过的过程行动计划子实践 1. 识别策略、方法及行动，以实行已识别的过程改进。在总结成正规使用以前，新的、未经证明的及重大的变更需先经过试用。 2. 建立过程行动组，负责执行行动。执行过程改进行动的团队及人员叫做「过程行动组」，过程行动组通常包括过程的负责人及执行过程的人员。 3. 制作过程行动计划。过程行动计划通常涵盖下列项目： • 过程改进基础架构 • 过程改进目标 • 将进行的过程改进 • 规划及追踪过程行动的程序 • 试用与执行过程行动的策略 • 执行过程行动的责任及授权 • 执行过程行动的资源、进度及工作分配 • 决定过程行动有效性的方法 • 过程行动计划的风险 4. 与相关的干系人审查并讨论过程行动计划。 5. 必要时，审查过程行动计划。 SP 实施过程行动计划实施过程行动计划。典型的工作产品 1. 各个过程行动组的承诺 2. 执行过程行动计划的状况与结果 3. 试点计划子实践 1. 使相关的干系人可容易取得过程行动计划。 2. 各过程行动组讨论和记录其承诺，如需要并修订其行动计划。 3. 依据过程行动计划追踪进度及承诺。 4. 与过程行动组及相关的干系人联合审查过程行动的进度及结果。 5. 规划需要的试用，以测试所选择的过程改进。 6. 审查过程行动组的活动及工作产品。 7. 对执行过程行动计划的问题加以识别、记录及追踪至关闭。 8. 确保执行过程行动计划的结果能符合组织过程改进的目标。 SG 3 部署组织过程资产并且进行经验教训总结在组织中推广组织过程资产，并将过程相关经验纳入至组织过程资产中。此特定目标中的特定实践描述持续进行的活动。每一项目的生命期间，可能出现项目可从组织标准过程及其变更中获益的新机会。标准过程及其它组织过程资产的部署，必须在组织中持续予以支持，特别对于新项目刚启动时。 SP 部署组织过程资产在组织中推广过程资产。组织过程资产的部署，或是组织过程资产变更的部署，必须用有次序的方式执行。某些组织过程资产或过程资产的变更，对组织的某些部门可能不适用(例如：由于客户的需求或目前执行的生命周期阶段)。因此，必要时，正在执行过程或即将执行过程的人员，以及其它组织功能(例如：培训及质量保证) 的人员参与部署，是很重要的。有关如何组织过程资产库来支持并启动组织过程资产的部署，请参考组织过程定义过程域，以获得更多的信息。典型的工作产品 1. 在组织中部署组织过程资产及其变更的计划 2. 部署组织过程资产及其变更的培训教材 3. 组织过程资产的变更记录文档 4. 部署组织过程资产及其变更的支持材料子实践 1. 在组织中部署组织过程资产。部署时，执行的活动通常包括下列项目： •识别执行过程人员应采用的组织过程资产。 •决定如何让组织过程资产可供使用(例如：藉由网站) •识别如何传达组织过程资产的变更 •识别支持组织过程资产的使用所需的资源(例如：方法与工具) •规划部署 •帮助使用组织过程资产的人员 •确定能提供使用组织过程资产人员所需的培训有关培训的协调，请参考组织培训过程域，以获得更多的信息。 2. 记录组织过程资产的变更。记录组织过程资产变更有两个主要目的： • 使变更能够传达 • 了解组织过程资产变更与过程绩效及结果的关系 3. 在组织中部署组织过程资产的变更。部署变更时，通常包括下列各项活动： • 决定哪些变更适合执行过程的人员 • 规划部署活动 • 安排成功转换过程变更所需的支持 4. 提供组织过程资产使用的指导与咨询。 SP 部署标准过程在项目启动时，推广组织标准过程至项目，并在每个项目生命周期内，适当的推广最新的过程变更至项目中。新项目使用已证明且有效的过程，以执行关键的早期活动是重要的(例如：项目策划、接受需求及取得资源)。当对组织标准过程的变更对项目有益时，项目也应该定期更新已定义过程，以总结最新的组织标准过程变更至项目中。定期更新参考确保所有项目的活动，获得其它项目学习心得的全部效益。有关组织标准过程与定义指导，请参考组织过程定义过程域，以获得更多信息。典型的工作产品 1. 组织的项目清单及每一项目过程部署状况(例如：现有与规划的项目) 2. 新项目部署组织标准过程的指导 3. 已识别的项目，定义组织标准过程及执行过程的纪录子实践 1. 识别组织内已启动的项目。 2. 识别将从执行组织现有标准过程获益的进行中项目。 3. 对已识别的项目，建立执行组织现有标准过程的计划。 4. 帮助项目定义组织标准过程，以符合项目需要。有关定义组织标准过程，以符合项目独特的需要与目标，请参考集成的项目管理过程域，以获得更多信息。 5. 维护已识别项目定义与执行过程的纪录。 6. 确保过程定义产生的已定义过程，已纳入过程符合度审计计划中。过程符合度审计是项目活动依据项目已定义过程的客观评估。 7. 当组织标准过程更新时，识别哪些项目应执行变更。前述子实践说明如何部署至组织标准过程变更至已识别的项目。 SP 监督实施对所有项目，监督组织标准过程的执行及过程资产的使用。藉由监督执行，组织确保组织标准过程与其它过程资产，适当地部署至所有项目。监督执行也参考组织了解组织过程资产的使用及在组织中何处使用。监督执行也参考建立广泛的内涵，以解释与使用过程及产品度量、学习心得、以及由项目取得的改进信息。典型的工作产品 1. 监督项目过程的执行结果 2. 过程符合评估的状况与结果 3. 审查选定的过程成果(过程定义与执行的部分产出)的结果子实践 1. 监督项目使用组织过程资产及其变更。 2. 审查选定的过程结果(每一项目生命期间的产出)。审查选定的过程结果(每一项目生命期间的产出)，确保所有项目适当的使用组织标准过程。 3. 审查过程符合评估的结果，以决定组织标准过程部署的优良。有关依据适用的过程说明、标准及程序以客观的评估过程，请参考过程与产品质量保证过程域以获得更多信息。 4. 识别、记录与追踪有关执行组织标准过程的问题至关闭。 SP 协调过程相关经验纳入资产库纳入过程相关的工作产品、度量及来自规划与实施过程的改进信息，至组织过程资产。典型的工作产品 1. 过程改进建议 2. 过程学习心得 3. 组织过程资产的度量值 4. 组织过程资产的改进建议 5. 组织过程改进活动的纪录 6. 组织过程资产及其改进的信息子实践 1. 定期审查组织标准过程及相关的组织过程资产相对于组织经营目标的有效性及适用性。 2. 取得使用组织过程资产的反馈意见。 3. 导出来自于定义、试用、执行及部署组织过程资产的学习心得。 4. 使组织中的人员能够适当地取得有用的学习心得。为了保证能适当地使用学习心得，可能必须采取一些行动。不适当的使用学习心得，举例如下： • 评估人员绩效 • 判断过程绩效或结果避免不适当的使用学习心得的方法，举例如下： • 控制学习心得的取得 • 教育人员如何适当地使用学习心得 5. 分析组织的共同度量。有关分析度量，请参考度量与分析过程域，以获得更多的信息。有关建立组织度量资产库，包括共同度量，请参考组织过程定义过程域，以获得更多的信息。 6. 评估在组织中使用的过程、方法及工具，并开发用来改进组织过程资产的建议。评估通常包括下列各项： • 决定哪些过程、方法及工具，可能用在组织的其它的部门 • 评估组织过程资产的质量与有效性 • 识别组织过程资产的可能改进 • 决定组织标准过程及定义指导的符合程度 7. 使组织中的人员适当地充分运用组织的过程、方法及工具。 8. 管理过程改进建议。过程改进建议能够说明过程与技术改进两者。管理过程改进建议的活动，通常包括下列各项： • 征求过程改进建议 • 收集过程改进建议 • 审查过程改进建议 • 选择要执行的过程改进建议 • 追踪过程改进建议的执行过程改进建议，应适当地以过程变更要求或问题报告方式做成文档。有些过程改进建议可总结纳入组织过程行动计划。 9. 建立并维护组织过程改进活动的纪录。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施组织过程焦点过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标在此出现反映其在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行组织过程焦点过程。详细说明：本方针建立组织的期望，以决定过程使用的过程改进机会，并在组织中策划与实施过程改进的活动。 GP 规划过程建立并维护用来执行组织过程焦点过程的计划。详细说明：执行组织过程焦点的计划通常叫做「过程改进计划」。这个过程改进计划与本过程域中特定实践说明的过程行动计划不相同。在此通用实践的计划为此过程域中所有实践的广泛规划，从组织过程需要的建立到总结过程相关经验纳入组织过程资产。 GP 提供资源提供充分的资源，以执行组织过程焦点过程、开发工作产品及提供过程服务。详细说明：提供的资源，举例如下： • 数据库管理系统 • 过程改进工具 • 网页的制作工具与浏览器 • 群组软件 • 质量改进工具(例如：因果图、相关图、柏拉图) GP 分配责任分配组织过程焦点过程的责任与授权，以执行过程、开发工作产品及提供过程服务。详细说明：为了过程改进，通常会建立二个团队并分配责任： (1) 过程改进的管理指导委员会，以提供资深管理人员的赞助；(2) 过程组，以帮助并管理过程改进活动。 GP 培训人员依需要培训人员，以执行或支持组织过程焦点过程。详细说明：培训主题，举例如下： • CMMI 与其它过程及过程改进的参考模型 • 规划并管理过程改进 • 工具、方法及分析技术 • 过程模型 • 部署技术 • 变更管理 GP 管理配置将指定的组织过程焦点过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 过程改进建议 • 组织已批准的过程行动计划 • 部署组织过程资产的培训教材 • 新项目部署组织标准过程的指导 • 组织过程评估计划 GP 识别并纳入相关的干系人依计划识别并纳入组织过程焦点过程相关干系人。详细说明：干系人参与活动，举例如下： • 在过程改进活动中，与过程负责人协调合作，过程负责人即目前或未来执行过程与支持组织的人(例如：培训的工作人员与质量保证代表) • 建立组织过程的需要与目标 • 评估组织过程 • 执行过程行动计划 • 在执行试用以测试所选择的改进建议时，相互协调与合作 • 部署组织过程资产及组织过程资产的变更 • 沟通规划、执行与部署过程改进活动相关的计划、状况、活动及结果 GP 监控过程依本过程的执行计划，监控组织过程焦点过程，并采取适当的纠正措施。详细说明：用于监控的度量，举例如下： • 提出、接受或执行之过程改进建议的数量 • CMMI 成熟度等级或能力度等级 • 项目使用现有组织标准过程(或定义同一版本)的百分比 • 有关执行组织标准过程的问题趋势(例如：识别问题的数量及关闭问题的数量) GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观组织过程焦点评估过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 决定过程改进机会 • 规划并协调过程改进活动 • 在项目启动时，部署组织标准过程审查的工作产品，举例如下： • 过程改进计划 • 过程行动计划 • 过程部署计划 • 组织过程评估计划 GP 与高层管理人员审查各状况与高层管理人员审查组织过程焦点过程的活动、状况及结果，并解决问题。详细说明：这些审查通常是由过程组及过程行动组以简报的型式，向管理委员会报告。简报的主题，举例如下： • 过程行动组所开发的改进状况 • 试用的结果 • 部署的结果 • 达到重要里程碑的进度状况(即评估的准备度或达到组织选定的目标成熟度等级或能力度等级摘要的进度) 仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标在此出现反映其在连续式表述的位置。 GP 建立已定义过程建立并维护已定义过程的说明。 GP 收集改进信息收集由规划和执行组织过程焦点过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 排定候选过程改进的优先级的准则 • 说明组织过程优缺点的评估调查报告 • 依据进度说明改进活动的状况 • 已识别的项目，定义组织标准过程及其执行的纪录仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护组织过程焦点过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定组织过程焦点过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保组织过程焦点过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正组织过程焦点过程之缺陷与其它问题的根本原因。组织过程绩效（OPP 4级）成熟度第四级的过程管理类过程域目的组织过程绩效(Organizational Process Performance, OPP)的目的在于建立并维护量化模型，以藉此了解组织用于支持质量与过程绩效目标之标准过程的绩效，并提供过程绩效数据、基线及模型，以便以量化方式管理组织的项目。简介过程绩效是遵循过程而达成之实际结果的度量，过程绩效以过程度量(例如：工作量、周期时间及缺陷移除的有效性)，以及产品度量(例如：可靠度、缺陷密度、能力、反应时间及成本)来描述其特性。组织的共同度量由过程及产品度量所构成，可用以总结组织内个别项目之过程的实际绩效。这些度量的组织数据被分析以建立度量结果的分布及范围，并藉以描述组织内个别项目执行此过程的预期绩效。在本过程域，「质量及过程绩效目标」这个名词涵括产品质量、服务质量及过程绩效的目标及需求。如同上述的概念，「过程绩效」一词包含质量，然而，为强调质量的重要性，因此使用「质量及过程绩效目标」而不是只使用「过程绩效目标」。预期过程绩效可用来设定项目的质量及过程绩效目标，亦可作为与实际项目绩效比较的基线。本信息用于以量化方式管理项目。每个已量化管理的项目依序地提供实际的绩效结果，以成为组织过程资产之基线数据的一部分。相关的过程绩效模型用于展现过去及目前的过程绩效，并预测过程的未来结果。例如：在产品验证活动中所识别的缺陷度量，可用来预测交付产品的潜在缺陷。当组织对各项关键过程产品及服务特性具有度量、资料及分析技术时，就可以进行下列事项： • 决定过程的表现是否具备一致性或有稳定的趋势(亦即，具可预测性)。 • 识别绩效在常态范围的过程，此常态范围在不同的过程执行团队是一致的。 • 建立相关的准则，以识别过程或子过程是否应采统计管理，并决定用于此管理程序的相关度量及分析技术。 • 识别显示不正常(例如：偶发或不可预测的)行为的过程。 • 识别组织标准过程中可改进的任何一面。 • 识别实行最佳之过程。相关过程域有关过程绩效基线及模型的使用，请参考量化项目管理过程域，以获得更多信息有关如何指定度量，以及收集及分析资料，请参考度量与分析过程域，以获得更多信息。特定及实践摘要 SG 1 建立绩效基线及模型 SP 选定过程 SP 建立过程绩效度量 SP 设定质量及过程绩效目标 SP 建立过程绩效基线 SP 建立过程绩效模型各目标的特定实践 SG 1 建立绩效基线及模型建立并维护基准及模式，用以描述组织标准过程预期过程绩效的特性。建立过程绩效的基线与模型之前，应先决定哪些过程适合度量(「选定过程」特定实践)、哪些度量对决定过程绩效是有用的(「建立过程绩效度量」特定实践)，以及这些过程的质量与绩效目标(「设定质量及过程绩效目标」特定实践)。这些特定实践彼此相互关联，而且可能需同时执行以选定合适的过程、度量，以及质量与绩效目标。通常过程、度量或质量与绩效目标的选择都会限定其它两者的选择，例如：选定特定的过程之后，度量及质量与绩效目标的选择就可能受限于过程本身。 SP 选定过程于组织标准过程中，选定将纳入组织过程绩效分析的过程或子过程。有关组织过程资产结构，请参考组织过程定义过程领域，以获得更多信息。组织标准过程包含一组标准过程，而标准过程又由众多的子过程所组成。将统计的管理技术应用到组织标准过程的所有过程或子过程，通常是不可能、没有效果且不符合经济效益的。以组织及项目的需要及目标为基础，选择纳入量化过程绩效分析的过程及(或)子过程。选择过程或子过程作为组织分析的准则，举例如下： • 子过程对主要经营目标的关系 • 目前与子过程相关之有效历史数据的可利用性 • 目前这些资料的变动程度 • 子过程稳定性(例如，可比较案例的稳定绩效) • 可用以建立预测模型之公司或商业信息的可用性在选择过程或子过程时，可指出过程或子过程是稳定之项目数据的存在是个有用的准则。典型的工作产品 1. 纳入过程绩效分析的过程或子过程清单 SP 建立过程绩效度量建立并维护纳入组织过程绩效分析的度量的定义。有关如何选定度量，请参考度量与分析过程域，以获得更多信息。典型的工作产品 1. 所选定过程绩效度量的定义子实践 1. 决定哪些组织质量与过程绩效的经营目标必须由哪些度量来说明。 2. 选定能适当洞察组织质量与过程绩效的度量。如何选择能适当洞察组织经营目标的度量，可使用「目标问题度量(Goal Question Metric )」的相关作法。选择度量的准则，举例如下： • 度量与组织经营目标的关联性 • 度量对整个产品或服务生命期的涵盖度 • 度量是否能确实表现过程绩效 • 度量的可用性 • 度量的客观程度 • 度量数据的收集频率 • 度量受过程或子过程改变的控编程度 • 度量可用以代表使用者对于有效过程绩效观点的程度 3. 将所选定的度量纳入组织的共同度量。有关如何建立组织过程资产，请参考组织过程定义过程域，以获得更多信息。 4. 必要时修订度量。 SP 设定质量及过程绩效目标设定并维护组织质量与过程绩效的量化目标。组织的质量与过程绩效目标，应具有下列属性: • 以组织的经营目标为基础 • 以项目过去的绩效为基础 • 用以度量过程绩效，例如：产品质量、生产力周期时间或反应时间 • 受限于原有的变异或选定之过程或子过程的常态范围典型的工作产品 1. 组织质量与过程绩效目标子实践 1. 检视质量与过程绩效相关的组织经营目标。经营目标，举例如下： • 在特定期间内完成某一特定版本产品的开发工作。 • 对特定服务形式，达到平均反应时间小于指定时间 • 在预估成本的目标百分比内，交付产品的功能 • 减少指定百分比的产品维护成本。 2. 定义组织质量与过程绩效的量化目标设定过程或子过程度量(例如：工作量、周期时间及缺陷移除的有效性)、产品度量(例如：可靠度及缺陷密度)，以及适当服务度量(例如：容量及反应时间)的目标。质量与过程绩效目标，举例如下： • 达成指定的生产力。 • 交付少于指定之潜在缺陷数的工作产品。 • 在过程绩效基线的指定百分比内，缩短交付时间。 • 以某百分比，减少现有及新产品的整个生命周期成本。 • 指定产品功能的交付百分比。 3. 定义组织质量与过程绩效目标的优先级。 4. 与相关的干系人审查和协商组织质量与过程绩效目标及其优先级，并取得其承诺。 5. 必要时修订组织质量与过程绩效的量化目标。组织质量与过程绩效量化目标的修订时机，举例如下： • 当组织经营目标改变时 • 当组织过程改变时 • 当实际的质量与过程绩效与目标有极大差异时 SP 建立过程绩效基线建立并维护组织过程绩效基线。组织过程绩效基线是组织标准过程之不同详细程度的绩效度量，这些过程包括： • 相联过程的次序 • 涵盖整个项目的过程 • 开发个别工作产品的过程组织可能需要多套的过程绩效基线，以描述组织次团体绩效的特性。用以分类组织次团体的准则，举例如下： • 产品线 • 经营种类 • 应用领域 • 复杂度 • 团队规模大小 • 工作产品规模大小 • 从组织标准过程选出的过程组件组织标准过程所容许的定义动作，可能会显著影响纳入过程绩效基线数据的兼容性，定义的结果应列入建立基线的考量。根据容许的定义，绩效基线可能分别针对每一种定义种类。有关过程绩效基线的运用，请参考量化项目管理过程域，以获得更多信息。典型的工作产品 1. 组织过程绩效的基线数据子实践 1. 从组织各项目收集度量结果。度量时正在使用的过程或子过程应加以记录，以便日后可适当的使用此纪录。有关资料的收集及分析，请参考度量与分析过程域，以获得更多信息。 2. 从收集的度量数据及分析结果，建立并维护组织的过程绩效基线。有关设定度量与分析的目标、设定欲执行的度量与分析、收集与分析度量结果及报告结果，请参考度量与分析过程域，以获得更多信息。过程绩效基线系由分析收集的度量数据，以建立结果的分布与范围所衍生而来，其描述组织的个别项目，在使用选定过程或子过程的预期绩效。应使用来自项目之稳定子过程所取得的度量结果，其它数据可能不可靠。 3. 与相关干系人审查组织过程绩效基线，并达成协议。 4. 将组织过程绩效信息纳入组织度量资产库，以供整个组织使用。项目可使用组织过程度量基线，以估计过程绩效的常态范围。有关如何建立组织度量资产库，请参考组织过程定义过程域，以获得更多信息。 5. 比较组织过程绩效基线与相关的目标。 6. 必要时修订组织过程绩效基线。组织过程绩效基线的修订时机，举例如下： • 当过程改变时 • 当组织的结果改变时 • 当组织的需要改变时 SP 建立过程绩效模型建立并维护组织标准过程的过程绩效模式。配合其它过程、产品及服务度量获得的数值，过程绩效模型可用来估计或预测一个过程绩效度量的数值。这些过程绩效模型，通常使用由整个项目执行过程所收集的过程及产品度量数值，来推估非到项目执行过程后段才能度量的目标达成进度。过程绩效模型运用范围如下: • 组织运用它们以估计、分析及预测与组织标准过程相关的过程绩效。 • 组织运用它们以评价组织改进活动的(潜在)投资报酬。 • 项目运用它们以估计、分析及预测其已定义过程的过程绩效。 • 项目运用它们以选择使用的过程或子过程。这些度量及模型用来提供必要的洞察力及能力，以预测对经营有价值的关键过程及产品特性。模型可能有用的项目相关领域，举例如下： • 进度及成本 • 可靠度 • 缺陷识别及移除比率 • 缺陷移除有效性 • 潜在的缺陷估计 • 反应时间 • 项目进度 • 上述领域的组合过程绩效模型，举例如下： • 系统动态模型 • 可靠度成长模型 • 复杂度模型有关过程绩效模型的使用，请参考量化项目管理过程域，以获得更多信息。典型的工作产品 1. 过程绩效模型子实践 1. 以组织标准过程及组织过程绩效基线为基础，建立过程绩效模型。 2. 以组织过去的结果及目前的需要为基础，调整过程绩效模型。 3. 与相关干系人审查过程绩效模型，并达成协议。 4. 支持过程绩效模型在项目的运用。 5. 必要时修订过程绩效模型。过程绩效模型的修订时机，举例如下： • 当过程改变时 • 当组织的结果改变时 • 当组织的需要改变时各目标的通用实践仅适用于连续式表述GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施组织过程绩效过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行组织过程绩效过程。详细说明：本方针建立组织的期望，以建立并维护组织标准过程的过程绩效基线。 GP 规划过程建立并维护用来执行组织过程绩效过程的计划。详细说明：执行组织过程绩效过程的计划可包含于组织改进计划或由其引用参考(组织改进计划在组织过程焦点过程域中描述)，或是记录于另一个的计划，仅描述执行组织过程绩效的过程。 GP 提供资源提供充分的资源，以执行组织过程绩效过程、开发工作产品及提供过程服务。详细说明：可能需要统计及统计过程控制(SPC) 等特殊的专业知识，以建立组织标准过程的过程绩效基线。其它可用的资源工具，举例如下： • 数据库管理系统 • 系统动态模型 • 过程模型化工具 • 统计分析软件包 • 问题追踪软件包 GP 分配责任分配组织过程绩效过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持组织过程绩效过程。详细说明：培训的主题，举例如下： • 过程及过程改进模型化 • 计量及统计方法(例如：估计模型、柏拉图分析及控制图) GP 管理配置将指定的组织过程绩效过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 组织的质量与过程绩效目标 • 所选定过程绩效度量的定义 • 组织过程绩效的基线数据 GP 识别并纳入相关的干系人依计划识别并纳入组织过程绩效过程相关干系人。详细说明：干系人参与的活动，举例如下： • 建立组织质量与过程绩效目标及其优先级 • 审查并解决有关组织过程绩效基线的问题 • 审查并解决有关组织过程绩效模型的问题 GP 监控过程依过程的执行计划，监控组织过程绩效过程，并采取适当的纠正措施。详细说明：用于监控的度量及作产品，举例如下： • 工作产品及工作项目属性变化对组织过程绩效影响的趋势(例如：规模大小成长、工作量、进度及质量) • 用于建立过程绩效基线之度量的收集与审查进度。 GP 客观评价遵循程度依过程的说明、目标、标准及程序，客观评估组织过程绩效过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立过程绩效基线及模型审查的工作产品，举例如下： • 过程绩效计划 • 组织质量与过程绩效目标 • 所选定之过程绩效度量的定义 GP 与高层管理人员审查各状况与高层管理人员审查组织过程绩效过程的活动、状况及结果，并解决问题。仅适用于连续式表述GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义组织过程绩效过程的说明。 GP 收集改进信息收集由规划和执行组织过程绩效过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 过程绩效基线 • 由于与过程绩效度量定义不一致，所剔除度量数据的百分比仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护组织过程绩效过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定组织过程绩效过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保组织过程绩效过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正组织过程焦点过程之缺陷与其它问题的根本原因。组织培训（OT 3级）成熟度第三级的过程管理类过程域目的组织培训(Organizational Training, OT)的目的在于开发人员的技能与知识，使其有效执行他们的任务。简介组织培训包括两方面的培训：一是配合组织策略性经营目标的培训，一是满足项目与支持团队共同需要的实务培训。个别项目与支持团队阶层负责处理其识别的特定培训需要，而且不包含在组织培训范围之内。项目与支持团队负责识别及提出他们的特定培训需要。有关项目所识别的特定培训需要，请参考项目策划过程域，以获得更多的信息。组织培训计划包括下列各项： • 识别组织所需要的培训 • 取得并提供培训以满足需要 • 建立并维护培训能力 • 建立并维护培训纪录 • 评价培训成效有效的培训需要对需求、规划、教学设计及适当培训媒体 (例如：规范手册、计算机软件) 进行评价，并需要一培训过程数据的存储库。如同组织过程一样，培训的主要组件包括一套被管理的培训开发计划、计划书、具特定专业与其它知识领域的专精人员，以及用以度量培训计划成效的机制。主要根据执行组织标准过程所需的技能来识别过程培训需求。有关组织标准过程，请参考组织过程定义过程域，以获得更多的信息。某些技能可有效的通过课堂以外的方式传授(例如：非正式的顾问指导)，其它技能则需要较正规的培训方式(例如：课堂教学、网络教学、自修或正式的在职培训计划等)。以培训需求与需解决之绩效落差的评价为基础，采用正规或非正规的培训方式。本过程域所使用的「培训」字眼，泛指正规或非正规培训方式的学习活动。依据企业执行新的或正在进行的活动中，应用培训所获取的技能与知识的有用性来度量培训成功与否。技能与知识可以是技术的、组织的或人际关系的。技术性技能是指项目或过程所需之设备、工具、材料、数据及过程的使用能力。组织技能是指依据员工的组织结构、角色与责任，以及一般性运作原则与方法有关的行为。人际关系技能是指项目及支持团队在组织及社会关系中，成功执行所需的自我管理、沟通及人际关系的能力。「项目及支持团队」一词，经常使用于过程域本文的叙述，用来指明组织阶层的观点。相关过程域有关组织过程资产，请参考组织过程定义过程域，以获得更多信息。有关项目所识别的特定培训需求，请参考项目策划过程域，以获得更多信息。有关如何应用决策准则，以决定培训方法，请参考决策分析与解决方案过程域。特定目标及实践摘要 SG 1 建立组织培训能力 SP 建立战略级培训需求 SP 决定哪些培训需求是组织的责任 SP 建立组织培训的实施计划 SP 建立培训能力 SG 2 提供必要的培训 SP 实施培训 SP 建立培训纪录 SP 评价培训成效各目标的特定实践 SG 1 建立组织培训能力建立并维护用以支持组织管理与技术任务的培训能力组织应识别培训需求，以增进执行企业活动必要的技能与知识。一旦需求被识别，即可提出满足这些需求的培训计划。 IPPD 补充集成团队成员必须接受跨职务培训、领导能力培训、人际关系技能培训，以及集成适当的经营与技术功能所需的培训。在产品与过程开发时，必须有各种不同工作背景的人员参与作业，并将各种可能的需求纳入开发过程。在此种开发方式下，非需求开发团队的相关干系人必须接受产品设计相关的跨职务培训，以承诺需求，并完整掌握各类需求的内容与需求间的关系。 SP 建立战略级培训需求建立并维护组织的战略级培训需求藉由弥补重大知识的落差、引用新技术或实施重大行为变更，战略级培训需要说明长期的目标，以建立能力。战略级策划通常往后看二至五年。战略级培训需求的来源，举例如下： • 组织的标准过程 • 组织的战略级经营计划 • 组织的过程改进计划 • 企业等级的想法 • 技术评价 • 风险分析 IPPD 需要领导与人际关系的技能，超过传统得开发环境。在IPPD 环境，强调的特定技能包括： •集成所有适当的经营与技术功能及其过程的能力 •与他人沟通与协调的能力典型的工作产品 1. 培训需求 2. 评价分析子实践 1. 分析组织的战略级经营目标与过程改进方案，以识别未来潜在的培训需求。 2. 记录组织的战略级培训需求。培训需求的种类，举例如下(但不限于所举范例)： • 过程分析与文档制作 • 工程(例如：需求分析、设计、测试、配置管理及质量保证) • 服务交付项目 • 供应商的选择与管理 • 管理(例如：估计、追踪及风险管理) • 灾难复原与运作的持续性 3. 决定实施组织标准过程所需的角色与技能。 4. 记录组织标准过程中各角色所需的培训。 5. 记录维护安全、保全及持续经营运作所需的培训。 6. 必要时，修订组织的战略级需求及所需的培训。 SP 决定哪些培训需求是组织的责任决定哪些培训需求是组织的责任，以及哪些是个别项目或支持团队的责任。有关项目及支持团队特定的培训计划，请参考项目策划过程域，以获得更多信息。组织培训除了满足战略级培训需求外，同时也要满足跨项目与支持团队的共同培训需求。项目及支持团队的主要责任，是识别与提出他们的特定培训需求。组织培训的工作人员，仅须负责提出跨项目及支持团队的共同培训需求，例如：多项目共同的工作环境培训。然而，有些情况是在培训资源允许及组织培训优先的前提下，在组织培训的工作人员与项目及支持团队协商后，可能会提出额外的培训需求。典型的工作产品 1. 项目与支持团队的共同培训需求 2. 培训承诺子实践 1. 分析由不同项目与支持团队所识别的培训需求。项目与支持团队需求的分析意指识别能够最有效满足整个组织的共同培训需求，这些需求分析的活动，通常是先从项目与支持团队阶层中，察觉到未来的培训需求。 2. 与不同项目和支持团队协调如何满足他们的特定培训需求。在培训资源允许及组织培训优先的前提下，由组织培训的工作人员提供支持。适合由项目或支持团队执行的培训，举例如下： • 项目应用或服务领域的培训 • 项目或支持团队所使用之特殊工具与方法的培训 • 安全、保全与人际关系的培训 3. 记录将提供予项目与支持团队的培训承诺。 SP 建立组织培训的实施计划建立组织培训的实施计划组织培训的实施计划是与培训内容和组织责任相关的计划，对个人有效的执行其角色是必要的。此一计划解决短期培训的执行，会因应相关因素的变化(如需求或资源)与培训成效的评估而进行周期性的修订。典型的工作产品 1. 组织培训实施计划。子实践 1. 建立计划内容。组织培训实施计划，通常包含下列内容： • 培训需求 • 培训主题 • 以培训活动及其相依性为基础的进度表 • 培训所使用的方法 • 培训教材的需求与质量标准 • 培训工作项目、角色及责任 • 所需的资源，包括：工具、设备、环境、人员、技能与知识。 2. 建立对计划的承诺。为使计划有成效，有必要记录负责执行与支持计划人员的承诺。 3. 必要时，修订计划与承诺。 SP 建立培训能力建立与维护培训能力，以满足组织的培训需求。有关如何应用决策准则，以选择培训方法与开发培训教材，请参考决策分析与解决方案过程域。典型的工作产品 1. 培训教材与支持物品子实践 1. 选择适当的方法，以满足特定的组织培训需求。许多因素可能会影响培训方法的选择，包括听众特定的知识、成本与进度、工作环境等。选择方法时，必须考量在既定的限制下，提供最有效的技能与知识的方法。培训方法，举例如下： • 教室培训 • 计算机辅助教学 • 自修 • 正式的师徒传授课程 • 视频教学 • 用图解说明的演讲 • 午餐讨论会 • 有系统的在职培训 2. 决定内部自行开发或自外部取得教材。决定内部开发培训或自外部取得培训的成本与效益。可用以决定获取知识、技能最有效率方式的准则，举例如下： • 绩效目标 • 准备项目执行的可利用时间 • 经营目标 • 内部专业人才的可用性 • 外部培训来源的可用性外部培训来源，举例如下： • 客户提供的培训 • 可取得的商业化培训课程 • 学术课程 • 专业研讨会 • 专题讨论会 3. 开发或取得培训教材。培训可由项目、支持团队、组织或外部组织来提供。无论提供来源为何，组织培训的工作人员，应协调培训的取得与实施。培训教材，举例如下： • 课程内容 • 计算机辅助教学 • 教学录像带 4. 培训或寻求合格讲师。为确保由组织内部提供的讲师具备必需的知识与教学技能，可订定发掘、培训、评定内部讲师的准则。若是由外部机构提供培训，组织培训的工作人员可以检视该外部机构如何选定讲师人选。选定讲师的方式也可作为选取或持续引用外部培训机构的因素之一。 5. 于组织培训课程中，说明培训内容。每个课程在培训说明中所提供的信息，举例如下： • 培训涵盖的主题 • 预期的培训对象 • 参加培训的必备条件与准备事项 • 培训目标 • 培训期间 • 课程计划 • 课程的完成准则 • 允许培训豁免的准则 6. 必要时，修订培训教材与支持物品。培训教材与支持物品可能需修订的时机，举例如下： • 培训需求改变(例如：与培训主题相关的新技术可取得时) • 培训的评估结果识别出变更需求(例如：培训成效调查、培训计划绩效评价或教学评价表的评估) SG 2 提供必要的培训提供个人必要的培训，使其能有效地执行任务。选择受训人员时，应考量下列事项： • 参与受训目标人选的背景 • 受训的必备资格 • 人员执行任务所需的技能与能力 • 针对跨专业的技术管理培训需求，包括项目管理 • 管理人员接受适当组织过程培训的需求 • 对安排特定工程领域基本工作方式，以支持人员的质量管理、配置管理及其它相关支持功能的培训需求 • 提供关键功能领域之开发能力的需求 • 维护个人能力与资格，以运作与维护对众多项目共同的工作环境。 SP 实施培训依据组织的培训实施计划提供培训典型的工作产品 1. 实施的培训课程子实践 1. 选择需接受培训以有效执行其角色的受训人员。培训的目的是要传授知识与技能予组织内执行各种任务的人员。某些人已拥有必须圆满执行指定任务所必要的知识与技能。对于这些人而言，可以免除培训，但应小心谨慎，避免培训豁免权被滥用。 2. 排定培训进度，包括任何必要的资源(如设备及讲师)。培训应规划和排定进度。培训的提供，对预期的工作绩效有直接影响。因此，最佳的培训对于预期的工作绩效有立竿见影的效果。这些期望常包含下列： • 使用特定工具的培训 • 个人如何执行新程序的培训 3. 进行培训。培训应由有经验的讲师执行。如果可以的话，培训应在非常类似实际的执行情况下实施，并包括活动以模拟实际的工作情况。此方法包括用以开发能力之工具、方法及程序的集成。培训应与工作责任结合，如此一来，在职的活动或其它外来的经验，在培训后合理的时间内，将可强化其培训。 4. 追踪培训是否依计划进行。 SP 建立培训纪录建立并维护组织培训的记录有关项目或支持团队如何维护培训纪录，请参考项目监控过程域，以获得信息。本实践的范围，是在组织等级所执行的培训。对于项目或支持赞助的培训纪录的建立及维护，由个别项目或支持团队负责。典型的工作产品 1. 培训纪录 2. 更新于组织存储库的培训子实践 1. 对于每项培训课程或其它批准的培训活动，保存所有完成与未完成培训的学员纪录。 2. 保存所有豁免特定培训之人员的纪录。允许豁免培训的理由必须加以记录；学员必须取得负责经理及其直属经理的批准才可豁免特定培训。 3. 保存所有成功完成指定之必要培训的学员纪录。 4. 让适当人员可取得培训纪录，作为分配工作的考量。培训纪录可以作为培训组织所开发之技能数据表的一部分，以提供人员经验及教育的总结，以及组织所负责的培训。 SP 评价培训成效评价组织培训计划的成效。应存在决定培训成效的过程(即：培训是如何符合组织的需求)。评价培训成效的方法，举例如下： • 受训内容的测验 • 受训后对受训人员的调查 • 经理对受训后效果的满意度调查 • 教育软件内建的评价机制针对项目与组织目标，培训所产生的附加价值可用度量来评价，不同培训方法的需求也必须加以注意，例如：将培训团队视为一个整体的工作单位。当实行度量时，绩效目标应与课程参与者分享，且绩效目标应是清楚、显著及可验证的。培训成效评价的结果应用以修订上述「建立培训能力」特定实践所述的培训教材。典型的工作产品 1. 培训成效调查 2. 培训计划绩效评价 3. 教学评估表 4. 培训测验子实践 1. 评价进行中或已完成项目，以决定人员知识是否足以完成项目工作。 2. 针对已建立的组织、项目或个人学习(或绩效)目标，提供评价每一培训课程成效的机制。 3. 取得学员有关培训活动是否符合其需求的评估。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本流程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程领域特定目标的达成。 GP 实施特定实践实施组织培训过程的特定执行方法，以开发工作产品与提供服务，达成过程领域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行组织培训过程。详细说明：本方针建立组织的期望，以识别组织策略性培训需求，并提供该项培训。 GP 规划过程建立并维护用来执行组织培训过程的计划。详细说明：用以执行组织培训过程的计划与本过程域中特定实践所述的组织培训实施计划是不同的，在本通用实践所说的计划应说明本过程域所有特定实践的广泛规划，由建立策略性培训需求，一直到组织培训绩效评价；相对的，本特定实践所谓的组织培训实施计划则应叙述个别培训实施的定期性规划。 GP 提供资源提供充分的资源，以执行组织培训过程、开发工作产品及提供过程服务。详细说明：人员(全职或兼职、内部或外部)及技能需求，举例如下： • 主题专家 • 课程设计人员 • 教学设计人员 • 讲师 • 培训管理人员培训可能需要特殊设备，当需要时，应开发或购买组织培训过程域活动所需的设备。用于执行组织过程领域活动的工具，举例如下： • 用于分析培训需求的工具 • 用于培训的工作站 • 教学设计工具 • 开发简报教材的相关数据的软件包 GP 分配责任分配组织培训过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持组织培训过程。详细说明：有关通用实践GP 与组织培训过程域关系，请参考表通用目标与通用实践，以获得更多信息。培训的主题，举例如下： • 知识与技能需求分析 • 教学设计 • 教学技巧(例如：培训人员的培训) • 主题的更新培训 GP 管理配置将指定的组织培训过程工作产品，纳入适当等级的控制。详细说明：纳入配置管理的工作产品，举例如下： • 组织培训实施计划 • 培训纪录 • 培训教材及支持物品 • 教学评估表 GP 识别并纳入相关的干系人依计划识别并纳入组织培训过程相关干系人。详细说明：相关干系人参与的活动，举例如下： • 建立培训需求与培训成效沟通协调的环境，以确保符合组织培训的需求 • 识别培训需求 • 审查组织培训的实施计划 • 评价培训成效 GP 监控过程依本过程的执行计划，监控组织培训过程，并采取适当的纠正措施。详细说明：用于监控的度量，举例如下： • 已实施的培训课程数(例如：规划的相较于实际的) • 受训后的评价 • 培训计划质量调查评价 • 交付培训的进度 • 课程开发的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估组织培训过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 识别培训需求并取得培训 • 提供必要的培训审查的工作产品，举例如下： • 组织培训实施计划 • 培训教材与支持物品 • 教学评价表 GP 与高层管理人员审查各状况与高层管理人员审查组织培训过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义组织培训过程的说明。 GP 收集改进信息收集由规划和执行组织培训过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 培训成效调查结果 • 培训计划绩效评价结果 • 课程评估 • 顾问群的培训需求仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护组织培训过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定组织培训过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保组织培训过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正组织培训过程之缺陷与其它问题的根本原因。产品集成（PI 3级）成熟度第三级的工程类过程域目的产品集成(Product Integration, PI)的目的，在于将产品组件组合为产品、确保已集成的产品适当地运作及交付产品。简介产品集成过程域说明，将产品组件集成成更复杂的产品组件或完整的产品。此领域的范围，是依据已定义的集成顺序与程序，在一个阶段或渐进的阶段，逐渐地组合产品组件，以达成完整的产品集成。整个过程域中，产品及产品组件的意涵也包括服务及其组件。产品集成的关键点，为产品与产品组件的内部与外部接口的管理，以确保接口间的兼容性。在整个项目进行中，应注意接口管理。产品集成不只是在完成设计与制造时，进行一次产品组件的组合而已。产品集成可使用下列重复过程渐进执行，包括：组合产品组件、评估已组合的产品组件，再组合更多的产品组件。这集成过程，首先分析与模拟(例如：相关串联、快速原型、虚拟原型及物理原型)，并稳定的进展，逐渐增加更多实际的功能，直到达成最终产品。在每一次连续的「建造」时，原型(虚拟、快速或物理)被建造、评估、改进，并基于评估过程所得到知识再建造。虚拟对物理原型的要求程度，决定于设计工具的功能、产品的复杂度与有关的风险。以此方式集成产品，有很高的可能性会通过产品验证与确认。就一些产品及服务而言，最后的集成阶段，会在产品部署于预期的运作场所时进行。相关过程域有关识别接口需求，请参考需求开发过程域，以获得更多信息。有关定义接口与集成环境(当需要开发集成环境时)，请参考技术解决方案过程域，以获得更多信息。有关验证接口、集成环境及渐进组合的产品组件，请参考验证过程域，以获得更多信息。有关执行产品组件与已集成产品的确认，请参考确认过程域，以获得更多信息。有关识别风险与使用原型于降低接口兼容性及产品组件集成之风险，请参考风险管理过程域，以获得更多信息。有关使用正式评估过程，以选择适当的集成顺序与程序及决定集成环境之采购或开发，请参考决策分析与解决方案过程域，以获得更多信息。有关管理接口定义之变更与信息发布，请参考配置管理过程域，以获得更多信息。有关获得产品组件或部分的集成环境，请参考供应商协议管理过程域，以获得更多信息。特定目标及实践摘要 SG 1 准备产品集成 SP 决定集成顺序 SP 建立产品集成环境 SP 建立产品集成程序与准则 SG 2 确保接口兼容性 SP 审查接口说明的完整性 SP 管理接口 SG 3 组合产品组件并交付产品 SP 确定欲集成的产品组件已准备就绪 SP 组合产品组件 SP 评估已组合的产品组件 SP 包装并交付产品或产品组件各目标的特定实践 SG 1 准备产品集成完成产品集成的准备。准备产品组件的集成，包含建立并维护集成顺序、执行集成的环境及集成程序。「准备产品集成」特定目标的特定实践的关系，如下述：第一个特定实践决定产品与产品组件集成的顺序。第二个特定实践决定用来完成产品，或集成产品组件的环境。第三个特定实践开发产品与产品组件集成的程序与准则。在项目初期便开始集成的准备动作，且与技术解决方案过程域的实践同步开发集成顺序。 SP 决定集成顺序决定产品组件的集成顺序。集成的产品组件可能包含交付产品的一部分与测试设备、测试软件或其它像是配件的集成项目。一旦已分析替代的测试与组合的集成顺序，就选择最佳的集成顺序。产品集成顺序提供产品组件的渐进的组合及评估，并为纳入其它可取得之产品组件或高风险产品组件的原型，提供一个没有问题的基础。集成顺序应与技术解决方案过程域中解决方案的选择及产品与产品组件的设计和谐一致。有关使用正式评估过程，以选择适当的产品集成顺序，请参考决策分析与解决方案过程域，以获得更多信息。有关识别与处理集成顺序相关的风险，请参考风险管理过程域，以获得更多信息。有关移交取得的产品组件，与产品集成顺序需处理的产品组件需求，请参考供应商协议管理过程域，以获得更多信息。典型的工作产品 1. 产品集成顺序 2. 选择或拒绝集成顺序的理由子实践 1. 识别待集成的产品组件。 2. 识别产品组件集成时，将执行的验证[s2]。 3. 识别备选的产品组件集成顺序。可包含定义特定工具与测试设备，以支持产品集成。 4. 选择最佳集成顺序。 5. 定期审查产品集成顺序，必要时予以修订。评价集成顺序，以确保生产与交付进度之差异，不会对集成顺序有不利的影响，或不会危及早期所做的决定。 6. 记录制定与搁置决策的理由。 SP 建立产品集成环境建立并维护支持产品组件集成所需的环境。有关自制或采购的决策，请参考技术解决方案过程域，以获得更多信息。产品集成环境可自外部取得或自行开发。为了建立环境，必须开发设备、软件，以及其它资源采购或自制的需求。这些需求在实现与需求开发过程域相关的过程时产生。产品集成环境可能包含现有组织资源的复用。采购或自行开发产品集成环境的决策，在技术解决方案过程域相关的过程中说明。产品集成过程之每一步骤所需的环境，可包括测试设备、仿真器(代替无法取得的产品组件)、实际设备的部分及记录装置。典型的工作产品 1. 已验证的产品集成环境 2. 产品集成环境的支持文档子实践 1. 识别产品集成环境的需求。 2. 识别产品集成环境的验证准则与程序。 3. 决定自制或采购所需的产品集成环境。有关集成环境的采购，请参考供应商协议管理过程域，以获得更多信息。 4. 若无法采购合适的环境，则自行开发集成环境。对无前例、复杂的项目而言，产品集成环境是一项重大的开发工作。因此它会包括项目策划、需求开发、技术解决方案、验证、确认及风险管理。 5. 整个项目进行时，维护产品集成环境。 6. 产品集成环境的某些部分不再使用时，进行处置。 SP 建立产品集成程序与准则建立并维护产品组件集成的程序与准则。产品组件的集成程序所包含事项，如：执行渐进集成的次数，以及在每一阶段需执行之预期测试与其它评估的细节。准则可指出产品组件可进行集成或其可接受性的准备度。产品集成的程序与准则，说明如下： • 建立组件的测试阶层 • 接口的验证 • 效能偏差的阈值 • 产品组合与其外部接口的衍生需求 • 允许的替代组件 • 测试环境参数 • 测试成本的限度 • 执行集成时，质量与成本的取舍 • 正确运作的机率 • 交付率及其差异 • 订货到交货所需的时间 • 人员可用性 • 集成设备/生产线/环境的可用性。准则可定义如何验证产品组件及期望的功能，并定义如何确认与交付组合的产品组件与最终已集成的产品。准则可限制允许产品组件通过测试仿真的程度，或限制用来作为集成测试的环境。适当地将部分的组合进度及准则与工作产品的供应商分享，以减少延期或组件错误的发生。有关与供应商的沟通，请参考供应商协议管理过程域，以获得更多的信息。典型的工作产品 1. 产品集成程序 2. 产品集成准则子实践 1. 建立并维护产品组件的产品集成程序。 2. 建立并维护产品组件集成与评估的准则。 3. 建立并维护已集成产品的确认与交付准则。 SG 2 确保接口兼容性确保组件内部及外部接口是相容的。许多产品集成问题，起源于未知或无法控制的内部及外部接口。有效的管理产品组件接口的需求、规格及设计，可确保已实现之接口的完整与兼容。 SP 审查接口说明的完整性审查接口说明的范围与完整性。除产品组件接口外，接口应包括产品集成环境中的所有接口。典型的工作产品 1. 接口类别 2. 每个类别的接口清单 3. 接口与产品组件及产品集成环境的对照表子实践 1. 审查接口数据的完整性，并确保已涵盖所有接口。考虑所有的产品组件，并准备一张关系表。接口通常分成三种主要类型：环境、物理及功能。这些类别的典型接口类型包括：机械、流体、声音、电子、气候、电磁、热、讯息，以及人机或人因接口。可分类于此三种类型的接口(如，机械或电子组件)，举例如下： • 机械接口(例如：重量及规模大小、重力中心、操作零件间隙、维护所需空间、固定连接、移动连接、由轴承结构所接收的震动与振动) • 噪音接口(例如：结构所传动的噪音、空气中传动的噪音、听音) • 气候接口(例如：温度、湿度、压力、盐度) • 热接口(例如；热散、轴承结构的热传导、空调特性) • 流体接口(例如：淡水入口/出口、船运/海岸产品的海水入口/出口、空调、压缩空气、氮、燃料、润滑油、排出气体出口) • 电气接口(例如：网络电力供应消耗量的电流变换量与尖峰量、电力供应与通讯无敏感控制信号；敏感信号[如，模拟连接]；分配信号[微波等]；符合TEMPEST 标准地面信号) • 电磁接口(例如：磁场、无线电与雷达连接、光频连接波、同轴电缆与光纤电缆) • 人机接口(例如：声音合成、声音识别、显示器[模拟显示盘、电视屏幕、或液晶显示器、指示器的光发射电子组件]、人工操控装置[踏板、操纵杆、操作球、操作键、按钮、触控屏幕] ) • 讯息接口(例如：来源、终点、刺激、协议及数据特征) 2. 确保产品组件与接口已标注记号，以确保容易与正确的连接产品组件。 3. 定期审查接口说明的充份性。建立接口后，必须定期审查接口说明，以确保现有接口说明与正在开发、处理、生产或购买中的产品并无偏差。产品组件接口说明应与相关干系人共同审查，以避免误解、减少延期，并避免开发无法正常运作的界面。 SP 管理接口管理产品与产品组件的内部与外部接口之定义、设计与变更。接口需求驱动集成产品组件所需接口的开发。在产品开发初期便开始管理产品与产品组件接口。接口的定义与设计不只影响产品组件与外部系统，也影响验证与确认的环境。有关接口需求，请参考需求开发过程域，以获得更多信息。有关产品组件间的接口设计，请参考技术解决过程域，以获得更多信息。有关接口需求变更的管理，请参考需求管理过程域，以获得更多信息。有关发布接口说明(规格)的变更，以使每个人知道接口的最新状态，请参考配置管理过程域，以获得更多信息。接口管理包括维护接口在整个产品周期的一致性，以及解决冲突、不符合及变更问题。供应商取得的产品、与其它产品或产品组件间的接口管理，对项目的成功有关键性影响。有关管理供应商，请参考供应商协议管理过程域，以获得更多信息。除产品组件的接口外，接口应包括集成环境中的所有接口，以及用于验证、确认、操作及支持之其它环境的所有接口。需记录、维护接口的变更，并使其容易取用。典型的工作产品 1. 产品组件与外部环境的关系表(例如：主电源、用来固定的产品、计算机汇流系统等) 2. 不同产品组件间的关系表 3. 适用时，已同意之每对产品组件间的接口清单 4. 接口控制工作组会议报告 5. 更新接口的行动方案 6. 应用程序接口(API) 7. 已更新的接口说明或协议子实践 1. 确保接口在整个产品生命周期的兼容性。 2. 解决冲突、不符合及变更问题。 3. 维护项目参与人员可取得的接口数据存储库。一个共享、可存取的接口数据存储库，提供一机制，以确保每人都知道最新接口数据存放处，及其取得和使用。 SG 3 组合产品组件并交付产品组合已验证的产品组件，并交付已集成、已验证及已确认的产品。依据产品集成顺序与可用的程序，进行产品组件集成。集成前，每一产品组件应确定与其接口需求相符合。产品组件被组合成更大、更复杂的产品组件，并检查已组合的产品组件能正确的相互操作。持续此过程，直到完成产品集成。在集成过程中，如识别出问题，应记录问题，并启动纠正措施过程。确保依据产品集成顺序与可用的程序，组合产品组件成更大、更复杂的产品组件。及时接收所需的产品组件与适合人员的参与，将促成产品组件成功地集成成产品。 SP 确定欲集成的产品组件已准备就绪在产品组合前，确定欲组合成产品的产品组件已被适当的识别、并依据其说明运作，以及确定产品组件接口符合接口说明。有关确认产品组件，请参考确认过程域，以获得更多信息。有关产品组件的单元测试，请参考技术解决过程域，以获得更多信息。本特定实践的目的，在确保已适当识别的产品组件符合其说明文档，并能依产品集成顺序与可用程序实际组合。检查产品组件的数量、明显的损害及产品组件与接口说明间的一致性。执行产品集成，最终要负责检查，以确定所有事情在产品组件组合前皆已就绪。典型的工作产品 1. 已接收产品组件的验收文档 2. 交付的收据 3. 已检查的包装清单 4. 异常报告 5. 豁免权子实践 1. 当产品组件变成可用于集成时，尽快追踪所有产品组件的状态。 2. 依据产品集成顺序与可用程序，确保产品组件已交付至产品集成环境中。 3. 确定收到每个正确识别的产品组件。 4. 确保每一接收的产品组件符合其说明。 5. 依期望的配置，检查其配置状态。 6. 在连接产品组件前，执行所有物理接口的预先检查(例如：目视检查与使用基本度量)。 SP 组合产品组件依据产品集成顺序与可行程序，组合产品组件。本特定实践的组合活动与下一个特定实践的评估活动交互执行，由最初产品组件组合成中间产品组件，再组合成完整的产品。典型的工作产品 1. 已组合的产品或产品组件。子实践 1. 确保产品集成环境已准备就绪。 2. 确保正确地执行组合顺序。记录所有适当的信息(例如：配置状态、产品组件的序号、型式及仪器校正日期)。 3. 适当地修订产品集成顺序与可用程序。 SP 评估已组合的产品组件评估已组合产品组件的接口相容性。有关验证已组合的产品组件，请参考验证过程域，以获得更多信息。有关确认已组合的产品组件，请参考确认过程域，以获得更多信息。本评估包含使用可用的程序与环境，检查及测试已组合的产品组件之绩效、适用性或完成度。评估的执行如同已识别的产品集成顺序与可用程序，评估可适当地分阶段进行。产品集成顺序与可用程序可定义较精炼的集成和评估顺序，而非仅为产品架构的检查。例如：如果某产品组件的组合是由四个较不复杂的产品组件组成，则集成顺序未必需要四个组件同时集成及检查。而是这四个组件可能逐步集成，一次一个，并在每次组合后执行检查，以确保组合的产品组件符合产品架构中的规格。另一方面，产品集成顺序与可用程序被认定为只有最终评估才是最佳的实施方式。典型的工作产品 1. 异常报告 2. 接口评估报告 3. 产品集成摘要报告子实践 1. 依据产品集成顺序与可用程序，评估已组合的产品组件。 2. 记录评估结果。评估结果包含如下： • 集成程序的任何定义要求 • 产品配置的任何变更(备用零件、新品) • 评估程序的偏差 SP 包装并交付产品或产品组件包装已组合的产品或产品组件，并交付给适当的客户。有关包装前验证产品或产品组件组合，请参考验证过程域，以获得更多信息。有关包装前确认产品或产品组件组合，请参考确认过程域，以获得更多信息。某些产品的包装需求，可能说明于规格与验证准则中，当客户自行存放及运送产品时，此项尤其重要。在此状况下，包装说明可能有环境的范围及压力条件的批注。在其它状况下，下列因素可能较为重要： • 经济且易于运输(例如：货柜装货) • 可说明性(例如：收缩性包装薄膜) • 拆封的容易与安全性(例如：锐利边缘、装订方式的强度、儿童保护、包装材质环保、重量) 集成组件所做的调整在工厂中集成产品组件所做的调整，可能与安装于作业现场时组件调整有所不同。在此状况下，为客户而做的产品纪录簿应予使用，以记载此特定的参数。典型的工作产品 1. 已包装的产品或产品组件 2. 交付的文档子实践 1. 审查需求、设计、产品、验证结果及文档，以确保影响产品包装与交付的问题，已被识别与解决。 2. 利用有效的方法，包装与交付已组合的产品。软件工程适用软件包装及交付方法，举例如下： •磁带 •磁盘 •影印文档 •光盘 •其它电子发布，例如：因特网 3. 满足包装与交付产品的适用需求与标准需求及标准的例子，包括安全、环境、保全、运输，以及销毁。软件工程适用软件包装与交付的需求及标准，举例如下： •存储及交付媒体的类型 •软件原始及备份版本的保管人 •必要的文档 •版权 •提供的授权 •软件安全性 4. 准备产品安装的运作场所。准备运作场所，可能是客户或最终使用者的责任。 5. 交付产品与其相关文档，并确定收到收据。 6. 在运作场所安装产品，并确定可正确操作。安装产品可能是客户或最终使用者的责任。某些情况下，需要确认可正确操作是极少的(例如：检查程序)。另有些状况，已集成产品最后的验证，是在操作现场执行。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施产品集成过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行产品集成过程。详细说明：本方针建立组织的期望，以开发产品集成顺序、程序与环境、确保产品组件间的接口兼容、组合产品组件，以及交付产品与产品组件。 GP 规划过程建立并维护用来执行产品集成过程的计划。详细说明：执行产品集成过程的计划，说明在本过程域中所有特定实践，从产品集成的准备一直到最终产品的交付的完整规划。 GP 提供资源提供充分的资源，以执行产品集成过程、开发工作产品及提供过程服务。详细说明：产品组件接口的协调，可由外部与内部接口的代表人员所组成的接口控制工作组达成，该工作组可诱导接口需求开发的需要。组合与交付产品可能需要特殊设备。必要时，将采购或开发产品集成过程域中活动所需的设备。其它提供的资源，如下列工具： • 原型工具 • 分析工具 • 模拟工具 • 接口管理工具 • 组合工具(例如：编译器、执行档制作档、接合工具、钓钩及固定设备) GP 分配责任分配产品集成过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持产品集成过程。详细说明：培训主题，举例如下： • 应用领域 • 产品集成程序与准则 • 组织的集成与组合设备 • 组合方法 • 包装标准 GP 管理配置将指定的产品集成过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 接收产品组件的验收文档 • 已检查组合过的产品与产品组件 • 产品集成顺序 • 产品集成程序与准则 • 已更新的接口说明或协议 GP 识别并纳入相关的干系人依计划识别并纳入产品集成过程相关干系人。详细说明：从下列人员中选择相关的干系人：客户、最终使用者、开发者、生产者、测试人员、供应者、营销人员、维护人员、销毁人员，以及其它可能被产品及过程影响或可能影响产品及过程的人。干系人参与的活动，举例如下： • 审查接口说明的完整性 • 建立产品集成顺序 • 建立产品集成程序与准则 • 组合与交付产品与产品组件 • 评估后，沟通检查结果 • 沟通新的、有效的产品集成实践，让受影响的人员有机会改进绩效。 GP 监控过程依本过程的执行计划，监控产品集成过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 产品组件集成摘要(例如：产品组件组合策划与实施，以及发现的例外数目) • 集成评估问题报告的趋势(例如：问题数量与关闭数量) • 集成评估问题报告处理时间(例如：每一问题报告悬而未解决的时间) • 执行特定集成活动的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估产品集成过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立并维护产品集成顺序 • 确保接口兼容性 • 组合产品组件与交付产品审查的工作产品，举例如下： • 产品集成顺序 • 产品集成程序与准则 • 已接收产品组件的验收文档 • 已组合的产品与产品组件 GP 与高层管理人员审查各状况与高层管理人员审查产品集成过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义产品集成过程的说明。 GP 收集改进信息收集由规划和执行产品集成过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果和改进信息，举例如下： • 产品组件、例外报告、配置状态的确认、以及准备程度检查结果的取得纪录。 • 产品集成全部开发工作量(实际完成加上预估完成)占的百分比 • 产品集成过程中，在产品及测试环境所发现的缺陷 • 产品集成所产生的问题报告仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护产品集成过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定产品集成过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保产品集成过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正产品集成过程之缺陷与其它问题的根本原因。项目监控（PMC 2级）成熟度第二级的项目管理类过程域目的项目监控(Project Monitoring and Control, PMC)的目的在了解项目进度，以便在项目执行绩效严重偏离项目计划时，可采取适当的纠正措施。简介文档化的项目计划是监控各项活动、沟通状态及采取纠正措施的基础。项目进度主要决定于工作产品、工作属性、工作量，以及成本的实际值与规定于里程碑或项目进度的控制阶层或工作拆分结构(WBS) 的规划值的比较结果。当执行绩效重大偏离原订计划时，适当的能见度可促使采取及时的纠正措施。如果重大偏离未解决，则会阻碍项目达成目标。这些实践使用「项目计划」一词，以代表控制项目的全盘计划。当项目实际状况重大偏离预期值时，适当地采取纠正措施。所采取的纠正措施可能需要重新进行项目策划，而重新规划可能包括修订原计划、订定新的协议，或在现行计划中增加额外的降低活动。相关过程域有关项目计划，其内容包含如何指定适当的项目监控等级、用于监控项目进度的度量及已知风险，请参考项目策划过程域，以获得更多信息。有关度量、分析及记录信息的过程，请参考度量与分析过程域，以获得更多信息。特定目标及实践摘要 SG 1 依计划监控项目 SP 监控项目策划之各项参数 SP 监控承诺事项 SP 监控项目风险 SP 监控数据管理 SP 监控干系人的参与 SP 进行进度审查 SP 进行里程碑审查 SG 2 管理纠正措施直到关闭 SP 分析问题 SP 采取纠正措施 SP 管理纠正措施各目标的特定实践 SG 1 依计划监控项目依据项目计划监控项目实际执行绩效与进度。 SP 监控项目策划之各项参数依据项目计划监控项目策划数据的实际值。项目策划参数构成项目进度与执行绩效的代表性指针，它包含工作产品与工作项目、成本、工作量、进度等属性。工作产品与工作项目的属性包含如规模大小、复杂度、重量、形状、安装或功能等。监控通常包含度量项目策划参数的实际值、比较实际值与计划的估计值，以及识别其重大偏离。记录项目策划参数的实际值，包含记录前后相关的信息，以帮助对度量的了解。分析重大偏离的影响，以决定须采取之纠正措施是属于本过程域的第二个特定目标及其特定实践。典型的工作产品 1. 项目执行绩效的纪录 2. 重大偏离的纪录子实践 1. 依进度表监控项目进度。进度监控通常包含： •定期度量活动与里程碑的实际完成度 •将活动与里程碑的实际完成度，与项目计划所记录的进度表互相比较 •识别与项目计划预估进度表的重大偏差。 2. 监控项目的成本与耗用人力。耗用人力与成本的监控，通常包括： •定期度量实际耗用的人力与成本，以及成员分配 •将实际的投入人力、成本、人员配置与培训，与项目计划所记载的估计值与预算互相比较 •识别与项目计划之预算的重大偏差 3. 监控工作产品与工作项目的属性。有关工作产品与工作项目的属性，请参考项目策划过程域，以获得更多信息。监控工作产品及工作项目之属性，通常包括： • 定期度量工作产品与工作项目的实际属性，例如：规模大小或复杂度(及属性的变更) • 将实际工作产品与工作项目的属性(含属性的变更)，与项目计划所记载的估计值互相比较 • 识别与项目计划之估计值的重大偏差 4. 监控所提供与使用的资源。有关规划的资源，请参考项目策划过程域，以获得更多信息。资源举例如下： • 物理设施 • 用于设计、制造、测试及操作的计算机、外围装置及软件 • 网络 • 安全环境 • 项目成员 • 过程 5. 监控项目人员的知识与技能。有关规划执行项目所需的知识与技能，请参考项目策划过程域，以获得更多信息。监控项目人员的知识与技能，通常包括： •定期度量项目人员知识与技能的获得状况 •将实际获得的培训，与项目计划所记载的互相比较 •识别与项目计划之估计值的重大偏差 6. 记录项目策划参数的重大偏差。 SP 监控承诺事项依据项目计划监控所识别的承诺。典型的工作产品 1. 承诺审查纪录子实践 1. 定期审查承诺(包含外部及内部的)。 2. 识别尚未满足或有重大风险无法满足的承诺。 3. 记录承诺审查的结果。 SP 监控项目风险依据项目计划监控所识别的风险。有关识别项目风险，请参考项目策划过程域，以获得更多信息。有关风险管理活动，请参考风险管理过程域，以获得更多信息。典型的工作产品 1. 项目风险监控纪录子实践 1. 在项目目前情况及环境下，定期审查记载风险的文档。 2. 一旦有新增信息，修订风险文档以反应改变。 3. 与相关干系人沟通风险状态。风险状态，举例如下： • 风险发生机率的改变 • 风险优先级的改变 SP 监控数据管理依据项目计划监控所识别的数据管理。有关识别哪些类型的数据应该列管及如何规划其管理，请参考项目策划过程域的「规划数据管理」特定实践，以获得更多信息。项目数据管理计划一旦订定，就必须监控数据的管理，以确保管理计划的完成。典型的工作产品 1. 数据管理纪录子实践 1. 定期审查数据管理活动，是否依项目计划所述。 2. 识别与记录重大问题及其影响。 3. 记录数据管理活动审查的结果。 SP 监控干系人的参与依据项目计划监控所识别的干系人参与。有关识别相关的干系人及规划他们适当的参与，请参考项目策划过程域的「规划干系人之参与」特定实践，以获得更多信息。在项目策划时，一旦识别干系人，且已指定他们在项目内的参与程度，就必须监控其参与，以确保有适当的互动。典型的工作产品 1. 干系人参与的纪录子实践 1. 定期审查干系人参与的情形。 2. 识别与记录重大问题及其影响。 3. 记录干系人参与情形的审查结果。 SP 进行进度审查定期审查项目的进度、执行绩效及问题。进度审查是对项目的审查，以使干系人了解状况。这些项目审查可能是非正式的审查，且可能未在项目计划中明确说明。典型的工作产品 1. 项目审查结果纪录子实践 1.定期与相关干系人，沟通所分配之活动与工作产品的状态。审查人员可适当地包含：管理者、项目成员、客户、最终使用者、供应商及组织内其它相关干系人。 2.审查收集与分析度量的结果，以控制项目。有关度量与分析项目绩效数据的过程，请参考度量与分析过程域，以获得更多信息。 3.识别与记录重大问题以及与项目计划的偏差。 4.记录任何工作产品与过程所识别的变更要求与问题。有关如何管理变更，请参考配置管理过程域，以获得更多信息。 5.记录审查的结果。 6.追踪变更要求和问题报告直到关闭。 SP 进行里程碑审查在项目里程碑点，审查项目的完成情况及执行结果。有关里程碑规划，请参考项目策划过程域，以获得更多信息。里程碑审查应在项目策划时予以规划，里程碑审查通常是正式的审查。典型的工作产品 1. 里程碑审查结果纪录子实践 1. 在项目进度的重要时间点（如阶段的完成），与相关的干系人进行审查。审查人员可适当地包含：管理者、项目成员、客户、最终使用者、供应商及组织内其它相关干系人。 2. 审查项目的承诺、计划、状态及风险。 3. 识别并记录重大问题及其影响。 4. 记录审查、行动项目及决策的结果。 5. 追踪行动项目直到关闭。 SG 2 管理纠正措施直到关闭当项目的执行绩效或结果重大偏离计划时，管理纠正措施直到关闭。 SP 分析问题收集与分析问题，并决定采取必要的纠正措施以解决问题。典型的工作产品 1. 需要采取纠正措施的问题清单子实践 1. 收集问题，以备分析之用。从审查及其它过程的执行，收集问题。收集的问题，举例如下： • 通过执行验证与确认活动所发现的问题 • 项目计划估计值中，项目策划参数的重大偏离 • 尚未满足的承诺(内部或外部的) • 风险状态的重大改变 • 资料存取、收集、隐私或安全的问题 • 干系人的代表性或参与的问题 2. 分析问题，以决定采取纠正措施的必要性。有关纠正措施准则，请参考项目策划过程域，以获得更多信息。如果未解决需采取纠正措施的问题，可能妨碍项目达成其目标。 SP 采取纠正措施对识别的问题，采取纠正措施。典型的工作产品 1. 纠正措施计划子实践 1. 决定并记录须采取的适当行动，来解决已识别的问题。当项目计划需重新规划时，请参考项目策划过程域，以获得更多信息。可能的行动，举例如下： • 修改工作说明书 • 修改需求 • 修订估计值与计划 • 再协商承诺事项 • 增加资源 • 变更过程 • 修订项目风险 2. 与相关干系人，审查将采取的纠正措施，并取得协议。 3. 协商内部与外部承诺的改变。 SP 管理纠正措施管理纠正措施直到结项。典型的工作产品 1. 纠正措施结果子实践 1. 监控纠正措施直到完成。 2. 分析纠正措施的结果，以决定纠正措施的有效性。 3. 决定并记录适当行动，以修正纠正措施与规划结果的偏离。采取纠正措施的学习心得，可以作为规划与风险管理过程的输入。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施项目监控过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行项目监控过程。详细说明：本方针建立组织的期望，以依项目计划监控执行绩效，当实际执行绩效或结果重大偏离原计划时，管理纠正措施直到关闭。 GP 规划过程建立并维护用来执行项目监控过程的计划。详细说明：执行项目监控过程的计划可以是描述于项目策划过程域之项目计划的一部分(或由其引用参考)。 GP 提供资源提供充分的资源，以执行项目监控过程、开发工作产品及提供过程服务。详细说明：所提供的资源，举例如下列工具： • 成本追踪系统 • 工作量报告系统 • 行动项目追踪系统 • 项目管理与进度控制计划 GP 分配责任分配项目监控过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持项目监控过程。详细说明：培训主题，举例如下： • 项目监控 • 风险管理 • 数据管理 GP 管理配置将指定的项目监控过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 项目进度与其状态 • 项目度量资料与分析 • 实获值报告 GP 识别并纳入相关的干系人依计划识别并纳入过程相关干系人。详细说明：参考表有关通用目标与通用实践，以取得更多关于通用实践与项目监控过程域中之监控干系人参与实践关系的信息。项目干系人参与的活动，举例如下： • 依计划评价项目 • 审查承诺事项及解决问题 • 审查项目风险 • 审查数据管理活动 • 审查项目进度 • 管理纠正措施直到关闭 GP 监控过程依本过程的执行计划，监控项目监控过程，并采取适当的纠正措施。详细说明：参考表有关通用目标与通用实践，以取得更多通用实践GP 与项目监控过程域关系的信息。用于监控的度量及工作产品，举例如下： • 未关闭与关闭的纠正措施数目 • 每月财务资料收集、分析及报告之进度与状态 • 执行审查的次数及类型 • 审查进度(规划的与实际的及落后目标日期的对照) • 收集分析监控资料的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估项目监控过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 依项目计划监控项目绩效 • 管理纠正措施直到关闭审查的工作产品，举例如下： • 项目绩效的纪录 • 项目审查结果 GP 与高层管理人员审查各状况与高层管理人员审查项目监控过程的活动、状况及结果，并解决问题。仅适用于阶段式表述 GG 3 及其实践不应用于成熟度第二级评等，但可应用于成熟度第三级和更高级评等。仅适用于连续式/阶段式表述第3-5 级 GG 3 制度化已定义过程将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义项目策划过程的说明。 GP 收集改进信息收集由项目监控过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息的范例包括下列： • 重大偏差的记录 • 构成偏差的准则 • 纠正措施的结果仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化管理过程。 GP 建立过程的量化目标建立并维护项目监控过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定项目监控过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保项目监控过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正项目监控过程之缺陷与其它问题的根本原因。项目策划（PP 2级）成熟度第二级的项目管理类过程域目的项目策划(Project Planning, PP)的目的，在建立并维护用以定义项目活动的计划。简介项目策划过程域包括： • 开发项目计划 • 与干系人适当的互动 • 取得对计划的承诺 • 维护项目计划规划开始于用以定义产品与项目的需求。规划包括：估计工作产品及工作项目的属性、决定资源需求、协商承诺、产生进度，以及识别和分析项目风险。订定项目计划可能需要反复上述活动。项目计划提供执行及控制项目活动的基础，以完成对项目客户的承诺。项目进行时，项目计划常因下列情况而须修订：需求及承诺变更、不准确的估计、纠正措施及过程变更。说明规划及重新规划的特定实践，包含在本过程域之内。在本过程域的通用与特定实践中，全部使用「项目计划」这个术语，来描述控制项目的全盘计划。相关过程域有关产品及其组件之需求开发，请参考需求开发过程域，以获得更多信息。产品及产品组件之需求与需求变更，是规划及重新规划之基础。有关规划及重新规划所需的管理需求，请参考需求管理过程域，以获得更多信息。有关风险识别与管理，请参考风险管理过程域，以获得更多信息。有关把需求转成产品及其组件解决方案，请参考技术解决方案过程域，以获得更多信息。特定目标及实践摘要 SG 1 建立估计值 SP 估计项目范围 SP 建立工作产品与工作项目属性的估计值 SP 定义项目生命周期 SP 决定工作量与成本的估计值 SG 2 开发项目计划 SP 建立预算和进度 SP 识别项目风险 SP 规划数据管理 SP 规划项目资源 SP 规划所需知识和技能 SP 规划干系人之参与 SP 建立项目计划 SG 3 取得对计划的承诺 SP 审查影响项目的各种计划 SP 调整工作和资源水平 SP 取得计划承诺各目标的特定实践 SG 1 建立估计值建立并维护项目策划参数的估计值。项目策划参数包括项目从事下列活动所需之所有信息：规划、组织、用人、督导、协调、报告及预算。规划参数的估计值应有可信赖的基础，以逐渐建立信心，使得任何以此估计值为基础所做的计划，都有能力支持项目目标。估计这些参数值时，通常考虑的因素举例如下： • 项目需求，包括产品需求、组织需求、客户需求及可影响项目的其它需求 • 项目范围 • 已识别的工作项目及工作产品 • 技术方法 • 已选定的项目生命周期模型(例如：瀑布式、渐进式、螺旋式等) • 工作产品与工作项目的属性(例如：规模大小或复杂度) • 进度 • 把工作产品与工作项目属性转换成投入工时与成本的模型或历史性数据 • 决定所需材料、技能、工时及成本的方法(模型、数据、算法) 为了干系人对项目计划的审查与承诺，以及在项目执行过程中维护项目计划，记录估计理由与支持性的数据是必要的。 SP 估计项目范围建立高层工作拆分结构（WBS），以估计项目的范围。工作拆分结构随项目进行而渐进开发。初始期的最高层WBS用于初期估计。开发WBS时，把整个项目分成一组可管理的相互连结的组件。WBS通常是产品导向的结构，提供一种纲要结构，以识别与安排工作管理的逻辑单元，该逻辑单元称之为「工作包(work packages)」。通常，WBS 提供工作分配、进度安排及权责的参考与组织的机制，并作为规划、安排及控制项目工作的基本架构。有些项目会使用「合同WBS 」一词，以代表合同中的WBS(可能是整个的WBS)。并非所有的项目都会有「合同WBS」(例如公司内部资助的开发案)。典型的工作产品 1. 工作项目描述 2. 工作包描述 3. 工作拆分结构子实践 1. 以产品架构为基础，开发工作拆分结构。工作拆分结构提供纲要结构以安排项目工作，该工作环绕所支持的产品。工作拆分结构应确认下列事项： •识别风险与风险降低工作 •项目交付项目，及支持活动所需的工作 •为了获得技能与知识的工作项目 •开发工作所必须的支持计划，如：配置管理、质量保证及验证等计划 •非开发类项目的集成与管理工作 2. 识别工作包，须详细到足以估计项目工作项目、责任及进度。在工作项目及组织角色与责任方面，最高层的WBS用来帮助度量项目工作量。至于细节则描述于更低层的WBS，有助于开发实际可行的进度计划，从而减少预留管理空间的需要。 3. 识别会从外部取得的工作产品(或者是工作产品的组件)。有关从项目外部来源获得工作产品，请参考供应商协议管理过程域，以获得更多信息。 4. 识别将再使用的工作产品。 SP 建立工作产品与工作项目属性的估计值建立并维护工作产品与工作项目属性的估计值。规模大小是许多模型用来估计工作量、成本及进度的主要输入。这些模型也可根据连结、复杂度及结构作为输入的基础。规模大小估计的工作产品种类，举例如下： • 交付类及非交付类工作产品 • 文档与档案 • 可运作及支持的硬件、刃体和软件规模大小之度量方式，举例如下： • 功能数 • 功能点 • 原始码行数(SLOC) • 类别(Class)与对象(Object)数量 • 需求数 • 接口的数目与复杂度 • 文档页数 • 输出及输入数 • 技术风险项目数量 • 资料数量 • 集成电路逻辑闸的数目 • 零件的数目(例如以洗好的电路板、组件与机械零件) • 物理限制(例如重量与容量) 这些估计值应与项目需求一致，俾决定项目之工作量、成本及进度。每个规模大小属性，均应指定一个相对困难度与复杂度的等级。典型的工作产品 1. 技术方法 2. 工作项目及工作产品的规模大小及复杂度 3. 估计模型 4. 属性估计值子实践 1. 决定项目的技术方法。技术方法决定产品开发的高层策略。它包括架构特性的决策，例如采用分布式或主从式架构；应用最先进的技术或较成熟的技术，例如机器人、复合材料、或人工智能；以及对产品更广泛的功能期望，例如安全性、机密性及人体工学等方面的需要。 2. 使用适当方法决定工作产品及工作项目的属性，以估计资源需求。决定规模大小及复杂度的方式，应以经过确认之模型或历史数据为基础。我们对产品特性与属性的关系了解越多，决定属性的方法也将随之渐进开发。现行方法，举例如下： • 用于IC 设计的逻辑闸数目 • 用于软件的LOC 或功能点数 • 用于系统工程的需求数量/复杂度 • 用于标准住宅的平方呎数 3. 估计工作产品及工作项目之属性。 SP 定义项目生命周期定义项目生命周期阶段，并据此建立规划工作的范围。决定项目生命周期的阶段，为评估与决策之规划阶段作准备。这通常与资源及技术方法重大承诺的合理决策点有关。这样的决策点在修订项目方向与决定未来工作范围与成本上，提供可达成的计划结果。项目生命周期各阶段的定义，有赖于需求的范围，项目资源的估计，以及项目的本质。较大型的项目可能包含多个阶段，例如观念探索、开发、制造、操作与配置。在这些阶段中，可能会需要子阶段。开发阶段可能包含的子阶段有需求分析、设计、制造集成与验证。软件项目阶段之决定，通常包含软件开发模型的选择与改进，以说明项目活动间的相互关系与适当次序。根据开发策略，也可能还需要有下列中间阶段：原型制作、功能渐进或螺旋模型周期。了解项目生命周期对下列工作是必要的：决定规划工作的范围、决定开始规划的时机及决定计划修订之时机与准则(关键里程碑)。典型的工作产品 1. 项目生命周期阶段 SP 决定工作量与成本的估计值依据估计理由，估计工作产品和工作项目所需项目工作量和成本。工作量及成本的估计值，通常根据模型分析的结果，或应用于规模大小、活动及其它规划参数的历史资料而来。对这些估计值之信心，是来自估计模型的逻辑原理及历史数据的本质。有时候历史数据不适用，例如工作欠缺前例或工作项目类型与模型不合。所谓工作欠缺前例(在某种程度)，是指以前从未有人做过相似的产品或组件，或是开发小组以前从未做过。欠缺前例的工作风险通常较大，必须多做一些研究以便建立合理的估计基线，通常在管理上也须多预留一些空间。当使用这些模型时，必须记录项目的独特性，以确保在初始规划阶段所做的假设均达成共识。典型的工作产品 1. 估计理由 2. 项目工作量估计值 3. 项目成本估计值子实践 1. 收集估计模型或历史数据，俾用于将工作产品及工作项目的属性，转换成工时及成本的估计值。在软件工程领域，已开发出许多参数化模型，以帮助估计成本及进度。并不建议只使用这些模型作为估计的单一来源，因为它们所依据的历史项目资料，可能并不适合你的项目。使用多种估计模型及(或)多种估计方法可以确保估计上的高度信心。来自于先前执行项目的历史数据，包括成本、工作量及进度，以及考虑不同项目规模及复杂度的调整因素。 2. 估计工作量及成本时，应纳入支持基础环境所需的项目。支持的基础环境包含从产品开发及维护的观点所反映的资源需求。在评估人力与成本时，应考虑在开发环境、测试环境、制造环境、用户终端环境，以及上述任何组合所需的内在基础资源。内在基础资源包含如下： • 重要的计算机资源(例如：硬盘及网络容量) • 开发环境与工具(如原型工具、装配、计算机辅助设计与仿真) • 设施、机械与设备(如测试平台与记录的仪器) 3. 用估计模型及(或)历史资料，估计所需工作量及成本。用来估计工作量及成本的输入，通常包括： • 专家(群)所提供的判断估计(例如：Delphi 预估法) • 风险因素，包括工作欠缺前例的影响程度 • 执行工作所需之核心能力与关键角色 • 产品与产品组件需求 • 技术方法 • 工作拆分结构 • 工作产品与预期变更之规模大小估计 • 对外采购工作产品之成本 • 已选定之项目生命周期模型与过程 • 生命周期成本估计 • 在工程环境下的工具提供能力 • 执行工作的管理人员与幕僚人员之技能水平 • 所需知识、技能和培训 • 所需设施(例如：办公室、会议室及工作站) • 所需工程设施 • 编程能力 • 差旅 • 工作项目、工作产品、硬件、软件、人员及工作环境之安全程度 • 客服中心及产品保证之服务等级协议 • 直接人工与间接费用 SG 2 开发项目计划建立并维护项目计划，以作为管理项目的基准。项目计划以项目需求及已建立的估计值为基础，是用来控制项目执行的正式核定文档。项目计划应考虑所有项目生命周期的各阶段。项目策划时应确保所有影响项目的计划与主计划之间的一致性。 SP 建立预算与进度建立并维护项目预算与实践。项目预算及进度，要依据已开发的估计值来安排，并确保预算分配、工作复杂度、工作项目的依存关系均已适当考量。事件驱动且有资源限制的进度安排，已被证明能有效处理项目风险。若工作开始之前，就清楚识别完成时将要展示的成果，则有下述好处：提供事件处理的时间弹性、对预期成果的共识、较佳的项目状态愿景，以及较精确的项目工作项目状况掌握。典型的工作产品 1. 项目进度表 2. 进度相依关系 3. 项目预算子实践 1. 识别重要的里程碑。里程碑用来帮助确定交付项目能如期完成。里程碑可以事件或日期为基线。若以日期为基线，一旦决定日期就很难更改。 2. 识别进度安排的假设前题。当开始开发进度时，通常需要假设某些活动的期程。这些假设通常涉及一些缺少估计数据的工作项目。识别这些假设前题，可提供对全程之信心程度(不确定性)的洞察力。 3. 识别限制条件。应尽早识别影响管理方案弹性的限制因素。检验工作产品与工作项目的属性，常会促使这些因素浮现。这些属性可包括：工作项目之工期、资源需求、输入及输出。 4. 识别工作项目的相依关系。项目工作项目若依某一次序进行，通常可缩短完工时间。这需要先识别工作项目的先后顺序，以决定最佳的次序。可用于决定工作项目最佳次序的工具，举例如下： • 关键路径法(CPM) • 计划评核术(PERT) • 资源限制编程法 5. 定义预算与进度。建立并维护项目预算及进度通常包括下列事项： • 定义资源与设施已承诺或已预期的可用时段 • 决定项目活动的时间阶段 • 决定附属进度的分类 • 定义项目活动间的相依关系(先后顺序关系) • 定义支持精确进度度量所需的编程活动及里程碑 • 识别交付客户产品的里程碑 • 定义适当工期的项目活动 • 定义适当时间间隔的里程碑 • 根据满足进度与预算要求之信心度，定义管理上需预留的空间 • 用适当的历史数据来验证进度 • 定义渐增的经费需求 • 记录项目的假设与理由 6. 建立纠正措施准则。建立构成严重偏离项目计划的判断准则。度量的问题与问题对决定何时采取纠正措施十分重要。纠正措施可能需要重新策划，重新策划包括修订原计划、建立新协议，或减少目前计划内的活动。 SP 识别项目风险识别并分析项目风险。有关风险管理活动，请参考风险管理过程域，以获得更多信息。有关风险监测活动，请参考项目监控过程域的特定实践，以获得更多信息。须识别或发现风险，并进行分析以支持项目策划。本特定实践必须延伸到影响项目的所有计划，以确保与所识别之风险相关的相关干系人之间的接口，已有适当的安排。项目策划风险的识别与分析，通常包括下列各项： • 识别风险 • 分析风险以决定其影响程度、发生机率及可能发生问题的时间点 • 排列风险的优先级典型的工作产品 1. 已识别的风险项目 2. 风险的影响程度及发生机率 3. 风险的优先级子实践 1. 识别风险。风险识别包括识别会负面影响工作成果与计划的各种潜在问题、危险、威胁及弱点。在分析风险之前，必须先以容易了解的方式，识别及描述风险。识别风险时，最好能采用定义风险的标准方法。可使用风险识别及分析工具，以帮助识别可能的问题。风险识别及分析工具，举例如下： • 风险分类 • 风险评价 • 查核表 • 结构化访谈 • 头脑风暴 • 绩效模型 • 成本模型 • 网络分析 • 质量因素分析 2. 记录风险。 3. 与相关的干系人审查已记录风险之完整性与正确性，并取得其同意。 4. 适当地修订风险。已识别的风险须要修订的情况，举例如下： • 新风险已被识别 • 当风险变成问题 • 风险已消失 • 项目环境有大幅变动 SP 规划数据管理规划项目数据的管理 IPPD 补充当集成团队由多个小组所组成时，项目数据包括单一小组或跨小组所使用或开发的数据。数据是多种型式的文档，用以支持计划的全部领域(例如：行政管理、工程、配置管理、财务、后勤、质量、安全、制造及采购)。数据可能有多种型式(例如：报告、手册、笔记、图表、规格书、档案或往来书函)。数据可存放于各种媒体(例如：不同材质的印刷本或绘图本、照片、电子媒体或多媒体)。数据可能是交付项目(例如列于合同中的项目)，或是非交付项目(例如：非正式数据、市场研究及分析数据、内部会议纪录、内部设计审查文档、学习心得及行动数据)。数据分送方式也有多种方式，包括可用电子方式传送。项目数据需求，应就数据项的格式与内容，按共同或标准的数据需求来建立。统一的数据项内容及格式，使数据内容更容易了解，亦有助于数据资源的一致性管理。收集每份文档的理由必须要很清楚。这工作包括分析和验证项目交付及非交付项目、合同及非合同数据需求，以及客户提供的数据。资料收集时，经常没有清楚的了解将如何使用该数据，收集数据的成本很高，应该只在需要时才收集。典型的工作产品 1. 数据管理计划 2. 列管资料总表 3. 数据内容及格式描述 4. 对使用者与供应者的数据需求清单 5. 隐私需求 6. 安全需求 7. 安全程序 8. 数据检索、复制及分发机制 9. 项目资料的收集进度 10. 待收集的项目数据清单子实践 1. 建立确保数据的隐私与安全的需求及程序。并非每个人都有取用项目数据的需要或权限。必须建立程序，以识别什么人可在什么时候取用什么数据。 2. 建立将数据存盘及取用已存盘数据的机制。取用的信息应该以容易了解的型式(例如：电子型式或从数据库的计算机输出)表达，或以其原始建立的型式表达。 3. 决定待识别、收集及分发的项目资料。 SP 规划项目资源规划执行项目所需的必要资源。 IPPD 补充组成集成团队时，项目资源规划应考虑集成团队的用人需求。按照估计初始值，定义项目资源(人工、机器/设备、材料及方法)及执行项目活动的资源需求数量。同时也提供更多的信息，以展开用来管理项目的工作拆分结构。先前开发的高层WBS (当作估计机制)，通常藉由将高层WBS 分解为代表单一工作单元的工作包而展开，工作包可分别分配、执行及追踪。如此细分能分配管理责任，并提供较好的管理控制。工作拆分结构的每一工作包或工作产品，应指定唯一的识别符号(例如：数字)以便追踪。WBS 可按需求、项目活动、工作产品或上述的任意组合而建立。配合WBS，建立每一工作包工作描述的说明书。典型的工作产品 1. WBS 工作包 2. WBS 工作说明书 3. 依项目规模大小及范围的用人需求 4. 关键设施/设备表 5. 过程/工作过程的定义及图表 6. 计划行政管理需求表子实践 1. 决定过程需求。必须识别、定义用以管理项目的过程，并与所有干系人协调，以确保项目执行期间能有效率的操作。 2. 决定用人需求。项目的用人应依WBS 的工作包来安排。工作包的分割是从达成项目需求着眼，将需求分做工作项目、执行角色及责任做考量。用人需求必须考虑每个职位所需的知识与技能，如「规划所需知识和技能」特定实践所述。 3. 决定设施、设备及组件需求。就某些意义来说，多数项目都是独一无二的，因此需要某些独特的资产，以完成项目目标。及时决定并取得这些资产，对项目成功极为重要。需及早识别有生产前置时间的项目，以决定如何处理。即使所需资产不是独特的，收集一份包括全部设施、设备及零件(例如：项目成员工作所需的计算机数目、应用软件、办公空间等等)的清单，可提供常被忽视的工作范围方面的洞察力。 SP 规划所需知识和技能规划执行项目所需的知识与技能。有关将知识与技能的信息并入项目计划，请参考组织培训过程域，以获得更多信息。将知识导入项目，包含项目成员的培训以及从外界获取知识。用人需求必须根据执行项目所需之知识与技能而定。典型的工作产品 1. 技能需求的详细记载 2. 用人及聘雇新人计划 3. 数据库(例如：技能及培训) 子实践 1. 识别执行项目所需的知识与技能。 2. 评价可用的知识与技能。 3. 选择提供所需知识与技能的机制。机制举例如下： • 内部培训(公司与项目) • 外部培训 • 用人及聘雇新人 • 向外采购所需技能要选择以内部培训或外部采购来取得所需知识与技能，应依公司内的培训能力、项目进度及经营目标来决定。 4. 将选定的机制并入项目计划。 SP 规划干系人之参与规划已识别的干系人参与。 IPPD 补充组成集成团队时，对干系人参与的规划应深入到集成团队等级。藉由识别项目代表的人员类型与功能需要，以及描述他们在特定项目活动的关联和互动程度，来识别项目生命周期各阶段的干系人。制作干系人和项目活动的二维矩阵对照表以实现关联是很方便的形式。矩阵的每一格(即每一纵横坐标交叉点)，即可用来描述某一干系人，在某特定活动中的关系和被期望参与该活动的角色与份量。要让干系人的参与发挥效用，必须慎选相关的干系人。项目每个主要活动，都应识别出会受该活动影响的干系人，以及有项目技术来引导该活动的干系人。相关干系人的名单应随项目生命周期阶段而调整。先期的项目工作(如需求和设计决策) 会影响到后期工作，故应确保列名于项目后期生命周期阶段的相关干系人，能及早表达对影响他们的需求与设计决策的意见。干系人互动计划应包括的内容，举例如下： • 相关干系人名单 • 干系人参与的理由 • 项目生命周期各阶段中相关干系人的角色与责任 • 干系人间的关系 • 项目生命周期各阶段中干系人对项目成功的重要性 • 所需的资源(例如：培训、材料、时间、经费)，以确保干系人的互动 • 干系人分阶段互动的进度本特定实践之实施与前述「规划所需知识与技能」实践应相互分享或交换相关信息。典型的工作产品 1. 干系人参与计划 SP 建立项目计划建立并维护全盘的项目计划内容。在说明所有相关规划项目，以取得所有要执行该计划的个人、团体、组织的相互了解、承诺、及执行时，一份书面计划是必要的。项目的计划，以逻辑的方式定义了所有层面的人力；项目生命周期的考量；技术及管理工作；预算与进度；里程碑；数据管理、风险识别、资源与技术的需求；以及干系人的识别和互动。基础架构的描述包含有项目成员间责任与授权的关系、管理阶层以及组织的支持。软件工程适用软件的规划文档通常为下列之一： •软件开发计划 •软件项目计划 •软件计划硬件工程适用对于硬件，规划文档通常是指硬件开发计划。制造准备时的开发活动，可能包含在开发计划或定义在不同的制造计划。用于美国国防部的计划范例包含如下： • 集成主计划-一份事件驱动式的计划，记录重要的产出，以及该产出在项目的营运及技术方面上的成功/失败准则，并将各产出与关键事件相结合。 • 集成主进度-集成网络是多层次的计划工作进度，用以完成记录文档集成主计划的工作人力。 • 系统工程管理计划-详细说明项目中集成技术人力的计划。 • 系统工程主进度-事件导向的进度，包含了所有有技术上的关键产出，每个产出都要有可度量的准则，要能成功的实现，以通过所识别的事件。 • 系统工程详细进度-详细的与时间相关工作项目导向的进度，用以说明系统工程主进度中的特定日期与里程碑。满足相关规划事项的计划文档，对执行及支持该计划之个人、团队及组织，必须达成共同的了解、承诺及执行。项目计划须以逻辑的方式定义所有的工作面向：项目生命周期考量、技术及管理工作项目、预算及进度、里程碑、数据管理、风险识别、资源及技能需求，以及干系人的识别与互动。基本环境的描述应包括项目成员、管理人员及支持单位间的权责关系。典型的工作产品 1. 全盘项目计划 SG 3 取得对计划的承诺建立并维护对项目计划的承诺。计划必须获得负责执行及支持人员的承诺才生效。 SP 审查影响项目的计划审查影响项目的所有计划，以了解项目承诺。 IPPD 补充当集成团队组成时，其集成工作计划均属须审查的计划。其它过程域所开发的计划，通常包括与全盘项目计划同类的信息。这些计划可能提供额外且详细的指导，应配合与支持全盘项目计划，以指出权责与控制的人。影响项目的所有计划应予审查，以确保达成使项目成功所需的范围、目标、角色及关系的共识。很多影响项目的计划描述于每个过程域的规划过程的通用实践中。典型的工作产品 1. 影响项目计划的审查纪录 SP 调整工作和资源水平调整项目计划，以反映可用的资源与预估的资源。 IPPD 补充当集成团队组成时，若各集成小组分散于多处，或有人同时参与一个或多个项目的多个集成团队，要特别注意资源承诺问题。为使所建立的项目是可行的，获取相关的干系人的承诺，以及调整预估与实际可用资源之间的差距是重要的。调整的方式通常包括：降低或延后技术效能的需求、争取更多资源、找寻增进生产力的方法、委外、调整项目人员的技能组合、修订影响项目的所有计划或进度表。典型的工作产品 1. 已修订的方法与对应的预估参数 (例如：较好的工具、使用现成品组件) 2. 重新协商的预算 3. 已修订的进度 4. 已修订的需求表 5. 重新协商的干系人协议 SP 取得计划承诺从负责执行与支持计划的相关干系人取得承诺。 IPPD 补充集成团队组成时，集成团队计划必须被团队成员、其它接口团队、全项目及团队所选以定义应用标准过程的负责人所接受。取得承诺涉及所有项目内外部相关干系人之间的互动。做了承诺的个人及小组应有信心在预定之成本、进度及执行的限制条件下完成工作。通常先做一个暂时性的承诺较为适当，以容许工作启动，并进行相关研究，当增加信心至适当程度，需要得到充分的承诺。典型的工作产品 1. 承诺要求纪录 2. 承诺纪录子实践 1. 识别所需支持，并与相关干系人协商承诺。可用WBS 为检查表，以确保所有工作项目都获得承诺。干系人互动计划应识别所有取得承诺之对象。 2. 记录所有组织的承诺，包括完整的及临时的，并确保由适当等级的人员签署。承诺须文档化，以确保一致的相互了解，并可追踪及维护。临时性的承诺应附有相互关系的风险描述。 3. 适时与资深管理人员一起审查内部承诺。 4. 适时与资深管理人员一起审查外部承诺。管理者可能具有必要的洞察力及权威，以降低与外部承诺相关联的风险。 5. 识别项目内、项目间及组织单位间各组件的接口承诺，以利监督。定义良好的接口规格是承诺的基础。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施项目策划过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行项目策划过程。详细说明：本方针建立组织的期望，以规划参数估算、安排内外部承诺、开发管理项目的计划。 GP 规划过程建立并维护用来执行项目策划过程的计划。详细说明：参考表通用实践与过程域关系已取得更多关于通用实践和项目策划过程域的信息。 GP 提供资源提供充分的资源，以执行项目策划过程、开发工作产品及提供过程服务。详细说明：项目策划时，可能需要特殊专业能力、设备及设施。在项目策划时所需的特殊专业能力，举例如下: • 有经验的估计人员 • 编程人员 • 特定领域专家(例如: 产品专业及技术) 其它资源提供的工具，举例如下： • 电子表格程序 • 估计模型 • 项目策划及编程软件 GP 分配责任分配项目策划过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持项目策划过程。详细说明：培训主题，举例如下： • 估计 • 预算 • 谈判 • 风险识别及分析 • 数据管理 • 规划 • 编程 GP 管理配置将指定的项目策划过程工作产品，纳入适当等级的控制。详细说明：应置于控制的工作产品，举例如下： • 工作拆分结构(WBS) • 项目计划 • 数据管理计划 • 干系人参与计划 GP 识别并纳入相关的干系人依计划识别并纳入项目策划过程相关干系人。详细说明：参考表通用实践与过程域关系，以取得更多关于通用实践以及在项目策划过程域中规划干系人参与此一执行方向间的信息。干系人参与的活动，举例如下： • 建立估计值 • 审查并处理项目风险有关之完整性与正确性 • 审查数据管理计划 • 制定项目计划 • 审查项目计划并处理工作及资源问题 GP 监控过程依过程的执行计划，监控项目策划过程，并采取适当的纠正措施。详细说明：用于监控的度量，举例如下： • 计划修订次数 • 各次计划修订之成本、进度及工作量之差异 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估项目策划过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立估计值 • 开发项目计划 • 取得对项目计划的承诺审查的工作产品，举例如下: • 工作拆分结构 • 项目计划 • 数据管理计划 • 干系人参与计划 GP 与高层管理人员审查各状况与高层管理人员审查项目策划过程的活动、状况及结果，并解决问题。仅适用于阶段式表述 GG 3 和其它实践不实行于成熟度第二级评等，但对于成熟度第三级和更高及评等而言，是实行的。仅适用于连续式/成熟度第3-5 级GG 3 制度化已定义过程将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义项目策划过程的说明。 GP 收集改进信息收集由规划和执行项目策划过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息的范例包括下列： • 项目数据馆结构 • 项目属性估计 • 风险发生的影响与机率仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护项目策划过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定项目策划过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保项目策划过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正项目策划过程之缺陷与其它问题的根本原因。过程与产品质量保证（PPQA 2级）成熟度第二级的支持类过程域目的过程与产品质量保证的目的，在提供成员与管理阶层客观洞察过程与相关工作产品。简介过程与产品质量保证过程域包括： • 依据适用的过程说明、标准及程序，客观评价所执行的过程、工作产品及服务 • 识别并记录不符合项 • 对项目成员与管理人员，提供质量保证活动结果的反馈 • 确保不符合项已经处理过程与产品质量保证过程域藉由提供项目成员和各阶层的管理人员，对于项目生命周期中的过程和工作产品提供适当的能见度和反馈，以支持交付高质量的产品和服务。过程与产品质量保证过程域的实践可确保实行所规划的过程，而验证过程域的实践则确保满足特定的需求。这两个过程域可从不同的观点检视同样的工作产品，项目应注意将投入的重复性降到最低。过程与产品质量保证评价的客观性，是项目成功的关键(「客观评价」的定义，详见词汇)。客观性可藉由独立与使用准则来达成。由未参与生产工作产品的人，依据准则进行评价，经常混合使用不同的方法、较不正式的方法，可用于涵盖日常的活动，较正式的方法，则周期性的使用以确保客观性。执行客观评价的方法包含如下： • 由独立的质量保证组执行的正式审计 • 执行不同形式的同行评审 • 深入的实地审查(办公桌审计) • 工作产品分布式的审查和评论传统上，为了提供客观性，质量保证组常独立于项目之外。但对于某些组织而言，在并非独立的状况下实施过程与产品质量保证，可能也很适合。例如：在一个具有开放、质量导向文化的组织，过程与产品质量保证的角色由同行部分或全部担任，且质量保证功能可能植入于过程之中。对小型组织而言，这可能是最可行的方法。如果质量保证功能植入于过程中，必须处理下列几个问题以确保客观性。执行质量保证活动的每个人必须接受质量保证培训。执行工作产品质量保证活动的人员，应该与直接参与开发与维护工作产品的人员有所区隔。质量保证人员必须有独立的报告渠道，以对组织适当管理等级报告，必要时让不符合项向上反应。例如：以同行评审作为执行客观评价的方法： • 参加同行评审的人要接受培训并被分配角色。 • 分配未参与生产工作产品的同行评审成员，担任QA 的角色。 • 已具有支持品保活动的检核表。 • 缺陷会成为同行评审报告的一部分，且加以追踪，并于必要时提升到项目之上的层次。质量保证工作应开始于项目建立的初期，参与建立项目的计划、过程、标准及程序，为项目增加价值，并满足项目和组织方针的需求。执行质量保证的人员参与建立计划、过程、标准及程序，可确保符合项目的需要，在执行质量保证评价时，也相当有用。此外，需指定项目将进行评估的特定过程及相关工作产品。此项指定以抽样或客观准则为基础，而且与组织方针、项目需求及需要相符合。当识别不符合项时，尽可能先在项目内处理与解决，无法在项目内解决的不符合项，需提升到适当的管理阶层解决。本过程域主要用于评价项目的活动和工作产品，但它也用于评价非项目活动和工作产品，例如：培训活动。对于这些活动和工作产品，「项目」这个术语，应予适当的解释。相关过程域有关识别需要客观评价的过程和相关工作产品，请参考项目策划过程域，以获得更多信息。有关满足特定需求，请参考验证过程域，以获得更多信息。特定目标及实践摘要 SG 1 客观评价过程与工作产品 SP 客观评价过程 SP 客观评价工作产品及服务 SG 2 提供客观的洞察力 SP 沟通并确保解决不符合项 SP 建立纪录各目标的特定实践 SG 1 客观评价过程与工作产品客观评价执行的过程、相关的工作产品及服务，对适用的过程说明、标准及程序的遵循程度。 SP 客观评价过程根据适用的过程说明、标准及程序，客观评估所指定的执行过程。质量保证评估的客观性是项目成功的关键。须定义质量保证报告的渠道及如何确保客观性。典型的工作产品 1. 评估报告 2. 不符合的报告 3. 纠正措施子实践 1. 提倡鼓励员工参与识别并报告质量问题的环境(建立该环境成为项目管理的一部分)。 2. 建立并维护明确陈述的评价准则。本子实践的目的，是以经营需要为基础提供准则，例如： • 评价的标的是什么 • 过程评价的进度或频率 • 如何进行评价 • 必须参与评价的人员 3. 使用上述准则评估所执行之过程，对过程说明、标准及程序的遵循程度。 4. 识别评价时发现的每一个不符合事项。 5. 识别能改进未来产品及服务过程的学习心得。 SP 客观评价工作产品及服务根据适用过程说明、标准和程序，客观评价指定的工作产品及服务。典型的工作产品 1. 评估报告 2. 不符合的报告 3. 纠正措施子实践 1. 取样时，根据文档化的取样准则，选择需评估的工作产品。 2. 建立并维护明确陈述的准则，以供评估工作产品。本子实践的目的，是以经营需要为基础提供准则，例如： • 评估的标的 • 评估工作产品的进度或频率 • 如何进行评价 • 必须参与评价的人员 3. 使用上述准则评价工作产品。 4. 在工作产品交给客户前，评价工作产品。 5. 在开发过程的已选定里程碑中，评价工作产品。 6. 根据过程说明、标准及程序，对工作产品及服务进行渐进式或渐增式的评价。 7. 识别评价时发现的每一个不符合事项。 8. 识别能改进未来产品及服务过程的学习心得。 SG 2 提供客观的洞察力客观跟踪与沟通不符合项，并确保解决问题。 SP 沟通并确保解决不符合项沟通质量问题，并和成员与管理者确保解决不符合项。评价时发现的不符合项，反映出对适用标准、过程说明或程序缺乏遵循。不符合项的状况可提供质量趋势的指针。质量问题包括不符合项和趋势分析的结果。当不符合项不能在项目内解决时，使用已建立的向上反映机制，确保适当的管理阶层可以解决问题。追踪不符合项直到解决为止。典型的工作产品 1. 纠正措施报告 2. 评价报告 3. 质量趋势子实践 1. 尽可能与适当的成员解决每一个不符合项。 2. 当不符合项在项目内无法解决时，需予以记录。项目内解决不符合事项的方法，举例如下： • 修改不符合处 • 修改违反的过程说明、标准或程序 • 取得不符合项的豁免 3. 不符合项在项目内无法解决时，提升到适当的管理阶层，以了解问题并采取行动。 4. 分析不符合项，以了解是否有质量趋势需要识别和处理。 5. 确定相关干系人及时知道评估的结果和质量趋势。 6. 定期与分配的管理者审查未关闭的不符合项和趋势，以了解问题并采取行动。 7. 追踪不符合项直到解决为止。 SP 建立纪录建立并维护质量保证活动的记录。典型的工作产品 1. 评价纪录 2. 质量保证报告 3. 纠正措施的状况报告 4. 质量趋势报告子实践 1. 详细记录过程与产品质量保证活动，以了解状况和结果。 2. 视需要修正质量保证活动的状况与历史。各目标的通用实践仅适用于连续式表述GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施过程与产品质量保证过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行过程与产品质量保证过程。详细说明：本方针建立组织的期望，以客观评估过程与相关工作产品，遵循适用的过程说明、标准及程序的程度，并确保解决不符合项。本方针建立将过程与产品质量保证功能放置于所有项目的组织期望。过程与产品质量保证必须充分的从项目管理独立出来，以便能客观指出并报告不符合项。 GP 规划过程建立并维护用来执行过程与产品质量保证过程的计划。详细说明：项目计划通常包含(或参考)执行过程与产品质量保证过程的计划。项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行过程与产品质量保证过程、开发工作产品及提供过程服务。详细说明：提供的资源，举例如下： • 评价工具 • 追踪不符合事项的工具 GP 分配责任分配过程与产品质量保证过程的责任与授权，以执行过程、开发工作产品及提供过程服务。详细说明：为预防主观或偏见，须确保已分配过程与产品质量保证之责任与授权的人员，能充分独立且客观的执行评估。 GP 培训人员依需要培训人员，以执行或支持过程与产品质量保证过程。详细说明：培训的主题，举例如下： • 应用领域 • 客户关系 • 项目的过程说明、标准、程序及方法 • 质量保证目标、过程说明、标准、程序、方法及工具 GP 管理配置将指定的过程与产品质量保证过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 不符合的报告 • 评价纪录与报告 GP 识别并纳入相关的干系人依计划识别并纳入过程与产品质量保证过程相关干系人。详细说明：相关的干系人参与的活动，举例如下： • 建立过程与工作产品客观评价的准则 • 评价过程与工作产品 • 解决不符合项 • 追踪不符合项直到解决 GP 监控过程依过程的执行计划，监控过程与产品质量保证过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 策划与实施客观过程评价的差异 • 策划与实施客观工作产品评价的差异 • 客观评价的进度 • 特定的客观评价进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估过程与产品质量保证过程的遵循程度，并解决不符合的情况。详细说明：参考表格通用目标和通用实践去获得更多关于在通用实践和过程与产品质量保证过程域。审查的活动，举例如下： • 客观评价过程与工作产品 • 追踪与沟通不符合项审查的工作产品，举例如下： • 不符合的报告 • 评价纪录与报告 GP 与高层管理人员审查各状况与高层管理人员审查过程与产品质量保证过程的活动、状况及结果，并解决问题。仅适用于阶段式表述GG 3 的目标及其实践，不是成熟度第二级评等的必要项目，但它们是成熟度第三级和更高等级评等的必要组件。仅适用于连续式/成熟度第3-5 级 GG 3 制度化已定义过程将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义过程与产品质量保证过程的说明。 GP 收集改进信息收集由规划和执行过程与产品质量保证过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息的范例包括下列： • 评估记录 • 质量趋势 • 不符合的报告 • 纠正措施的状况报告 • 项目质量报告的成本仅适用于连续式表述GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护过程与产品质量保证过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定过程与产品质量保证过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保过程与产品质量保证过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正过程与产品质量保证过程之缺陷与其它问题的根本原因。量化项目管理（QPM 4级）成熟度第四级的项目管理类过程域目的量化项目管理(Quantitative Project Management, QPM)过程域的目的，在于以量化的方式管理项目已定义过程，以达成项目既定的质量及过程绩效目标。简介量化项目管理过程域包括以下事项： • 设定并维护项目质量及过程绩效目标 • 以过程绩效基线或模型的稳定性及能力的历史资料为基础，识别组成项目已定义过程的适当子过程 • 从项目已定义过程中，选定采统计化管理的子过程 • 监控项目，以决定是否符合项目的质量及过程绩效目标，并识别适当的纠正措施 • 选定用于统计化管理所选定子过程的度量及分析技术 • 运用选定的度量及分析技术来建立并维护对所选定子过程变异的理解 • 监控所选定子过程的绩效，以决定子过程是否符合其质量及过程绩效目标，并识别纠正措施 • 将统计及质量管理数据记录于组织度量资产库此处所识别的质量与过程绩效目标、度量及基线，是由组织过程绩效过程域的内容开发而来。因此，实施量化项目管理过程域相关的过程(例如：度量定义与度量数据等)，将成为组织过程绩效过程域所指组织过程资产的一部分。为有效说明本过程域的特定实践，组织应已建立一组标准过程及相关的组织过程资产，例如：每一项目用来建立其已定义过程的组织度量资产库及组织过程资产库。项目已定义过程是为项目而构成的集成且藕合之生命周期的一组子过程，其一部分是由组织标准过程挑选及定义而来。有关「已定义过程」在CMMI 产品系列中如何使用的说明(参考词汇的定义)。项目也应该以确保能取得供应商工作的度量与进度数据。要成功的完成本过程域的特定实践必须与供应商建立有效的关系。过程绩效是实际过程绩效结果的一个度量，过程绩效以过程度量(例如：工作量、周期时间及缺陷移除的有效程度)及产品度量(例如：可靠度、缺陷密度及反应时间)来表示。子过程是一个更大已定义过程的定义组件，例如：一个典型的组织开发过程，可由需求开发、设计、产品制作、测试及同行查核等子过程所构成。必要时，这些子过程又可再进一步分解为其它子过程或过程组件。量化管理的一个基本要素是要对估计值要有信心(也就是说，要能够预测项目质量及过程绩效目标的达成度)。需要统计化管理的子过程是基于可预测的绩效需要来选定。(有关「统计化管理过程」「质量与过程绩效目标」与「量化管理过程」的定义，请参见词汇) 量化管理的另一个基本要素是要了解实际过程绩效差异的本质及差异程度，并认知在什么时候，项目实际绩效并无法帮助达成项目质量及过程绩效目标。统计化管理涉及统计化的思维及各种统计技术的正确运用，如执行图(run charts)、控制图、信赖区间、预测区间及假设验证等统计技术。量化管理是运用由统计化管理所得到的资料，来帮助项目预计是否能达成其质量及过程绩效目标，并识别必须采取的纠正措施。本过程域应用于管理一个项目，但其相关的概念可运用于管理其它小组与功能群。将这些相关概念应用于其它小组与功能群，并不必然对达成组织经营目标有所参考，但可能可以帮助这些小组与功能群控制其过程。其它小组与功能群，举例如下: • 质量保证 • 过程定义及改进 • 工作量报告 • 客户抱怨处理 • 问题追踪及报告相关过程域有关如何监控项目与采取纠正措施，请参考项目监控过程域，以获得更多信息。有关设定度量目标、指定度量及分析项目，取得及分析度量，以及提供度量结果，请参考度量与分析过程域，以获得更多信息。有关组织质量及过程绩效目标、过程绩效分析、过程绩效基线及过程绩效模型，请参考组织过程绩效过程域，以获得更多信息。有关包含组织度量资产库的组织过程资产，请参考组织过程定义过程域，以获得更多信息。有关建立并维护项目已定义过程，请参考集成的项目管理过程域，以获得更多信息。有关如何识别缺陷及问题原因，并采取行动以预防未来再度发生，请参考原因分析与解决方案过程域，以获得更多信息。有关选定及部署改进措施，以支持组织质量及过程绩效目标，请参考组织创新与部署过程域，以获得更多信息。特定目标及实践摘要 SG 1 量化管理项目 SP 设定项目目标 SP 组合已定义过程 SP 选定纳入统计化管理的子过程 SP 管理项目绩效 SG 2 统计化管理子过程的绩效 SP 选定度量及分析技术 SP 应用统计方法了解变异 SP 监控子过程的绩效 SP 记录统计管理数据特定目标的特定实践 SG 1 量化管理项目根据质量及过程绩效目标，以量化的方式管理项目。 SP 设定项目目标设定并维护项目质量及过程绩效目标。事先思考要将哪些组织标准过程纳入项目的已定义过程并参考相关过程绩效的历史数据，经常能对设定项目质量及过程绩效目标的工作有所参考，藉由这些事前的思考将有助于设定实际可行的项目目标。日后当知道项目实际的绩效并且更容易预测时，也许需要修订项目的目标。典型的工作产品 1. 项目质量及过程绩效目标。子实践 1. 审查组织的质量及过程绩效目标。审查的目的是要确保项目了解项目运作的整体经营背景。项目的质量及过程绩效目标是依据整个组织的目标开发而来。有关组织质量及过程绩效目标，请参考组织过程绩效过程域，以获得更多信息。 2. 识别客户、最终使用者及其它相关干系人，对质量及过程绩效的需求及优先级。应识别需要与优先级的质量及过程绩效属性，举例如下： • 功能性 • 可靠度 • 可维护性 • 可用性 • 期间 • 可预测性 • 适时性 • 准确性 3. 识别如何度量过程绩效。考量组织所建立的度量是否适用于评价进度，以履行客户、使用者及其它干系人的需要及优先级。必要时，需补充其它额外的度量。有关度量的定义，请参考度量与分析过程域，以获得更多信息。 4. 定义并记录项目可度量的质量及过程绩效目标。定义并记录项目的目标包括以下事项： • 纳入组织的质量及过程绩效目标 • 记录目标及目标的度量方法，这些目标须能反映质量与过程绩效需要，以及客户、最终使用者和其它干系人的优先级可能采用的项目目标质量属性，举例如下： • 失败的平均间隔时间 • 关键性资源的使用状况 • 交付产品的缺陷数量及其严重性 • 客户对所提供服务的抱怨数量与严重性可能采用的项目目标过程绩效属性，举例如下： • 在产品验证活动中，缺陷移除的百分比(可依验证活动类型分类，例如：同行查核及测试) • 未发现的缺陷比率 • 产品交付(或服务开始)第一年内，所发现的缺陷数量及缺陷密度(依严重性) • 周期时间 • 重做时间的百分比 5. 于适当时机，针对生命周期每一阶段，推衍出过渡性目标，以监控达成项目目标的进度。预测过程未来结果的一个方法是：运用过程绩效模型，并使用在产品验证活动(例如：同行查核及测试)所识别的过渡性缺陷度量，来预测未来交付产品的潜在缺陷。 6. 解决项目质量及过程绩效目标间的冲突(例如：如果一个目标没有妥协，另一个目标将无法达成)。解决冲突相关的活动包括： • 设定各项目标的相对优先级 • 依长期经营策略及短期需要，衡量各项备选目标 • 邀集客户、最终使用者、高层管理人员、项目管理人员及其它有关的干系人参与取舍的决定 • 必要时修订目标以反映冲突解决的结果 7. 从来源建立项目质量及过程绩效目标的可追溯性。目标的来源，举例如下： • 需求 • 组织的质量及过程绩效目标 • 客户的质量及过程绩效目标 • 经营目标 • 与客户及潜在客户讨论 • 市场调查「质量机能展开(QFD)」是识别及追踪这些需求及优先级的一个方法。 8. 定义并协商供应商的质量及过程绩效目标。有关建立并维护供应商协议，请参考供应商协议管理过程域，以获得更多信息。 9. 必要时修订项目质量及过程绩效目标。 SP 组合已定义过程以过去的稳定性及能力资料为基础，选定组成项目的以定义过程的子过程。有关建立并维护项目已定义过程，请参考集成的项目管理过程域，以获得更多信息。有关包含已知及必需能力之过程组件的组织过程资产库，请参考组织过程定义过程域，以获得更多信息。有关组织过程绩效基线及过程绩效模型，请参考组织过程绩效过程域，以获得更多信息。从组织标准过程的过程组件及组织过程资产库的过程产品，识别子过程。典型的工作产品 1. 用以识别纳入项目已定义过程备选子过程的准则 2. 纳入项目已定义过程的备选子过程 3. 确定纳入项目已定义过程的子过程 4. 所选定的子过程缺乏过程历史绩效数据时，所识别的风险子实践 1. 建立用以识别有效备选子过程的评估准则。识别的基础包括： • 质量及过程绩效目标 • 具体的过程绩效数据 • 产品线标准 • 项目生命周期模型 • 客户需求 • 法规 2. 决定欲纳入统计化管理及从组织过程资产所取得的子过程，是否适合实行统计化管理。某子过程如果有以下的历史纪录，可能将更适合实行统计化管理： • 过去类似的案例具稳定的绩效 • 过程绩效数据满足项目质量及过程绩效目标历史数据主要是由组织过程绩效基线取得，不过，并不是所有子过程都有这些数据。 3. 分析子过程的相互关系，以了解子过程间的关连性以及各子过程的度量属性。可采用的分析技术，如系统动态模型及仿真方法。 4. 识别无任何子过程满足质量及过程绩效目标时的风险(也就是说，没有具能力的子过程或不了解子过程的能力)。即使某子过程并未被选为采用统计化管理，其历史数据及过程绩效模型，亦可能可以指出该子过程未能满足质量及过程绩效目标。有关风险的识别及分析，请参考风险管理过程域，以获得更多信息。 SP 选定欲纳入统计化管理的子过程从项目已定义过程中，选定欲纳入统计化管理的子过程。选定纳入统计化管理的子过程通常是同步及重复进行的过程，以识别可用的项目与组织的质量及过程绩效目标、选定子过程，以及识别用以度量与控制的过程及产品属性。通常在选择过程、质量与过程绩效目标或度量的属性时，选择其中一者会限制其它二者，例如：选定一个特别的过程之后，相关的度量属性与过程绩效目标都会因选定的过程而受限制。典型的工作产品 1. 统计化管理所要追求的质量及过程绩效目标 2. 用于选定纳入统计化管理子过程的准则 3. 纳入统计化管理的子过程 4. 应度量及控制之子过程的已识别过程及产品属性子实践 1. 识别项目有哪些质量及过程绩效目标将纳入统计化管理。 2. 识别用以选择对达成既定质量及过程绩效目标最有影响且极具绩效可预测性之子过程的准则。用于选定子过程的准则来源，举例如下： • 与质量及过程绩效相关的客户需求 • 客户所设定的质量及过程绩效目标 • 组织所设定的质量及过程绩效目标 • 组织的绩效基线与模型 • 其它项目子过程稳定的绩效 • 法规 3. 利用选取准则选定将被统计化管理的子过程。可能无法对某些子过程进行统计化管理(例如：新的子过程及正在试行的技术。) 在某些情形，应用统计技术于某些的子过程可能不符经济效益。 4. 识别用以度量与控制子过程的产品及过程属性。产品及过程属性，举例如下： • 缺陷密度 • 周期时间 • 测试涵盖度 SP 管理项目绩效监控项目，以决定是否符合其质量及过程绩效目标，并于适当时机识别纠正措施。有关分析及使用度量，请参考度量与分析过程域，以获得更多信息。进行本项比较的前提之一是：项目已定义过程所选定的子过程已采统计化管理，并充分了解其过程能力。特定目标2 对于统计画管理所选定的子过程，提供详细的说明。典型的工作产品 1. 项目质量及过程绩效目标达成度的估计值(预测值) 2. 达成项目质量及过程绩效目标的风险文档 3. 达成项目目标过程中，用以解决缺陷的行动措施文档子实践 1. 定期审查每个子过程的绩效及每个选定纳入统计化管理之子过程的能力，以评估达成项目质量及过程绩效目标的进度。参考该子过程既定的质量及过程绩效目标，来决定每个所选定子过程的过程能力，这些目标是从项目质量及过程绩效目标中，以项目整体的观点推衍而来。 2. 定期审查生命周期中每个阶段性目标的实际达成状况，以评估达成项目质量及过程绩效目标的进度。 3. 追踪供应商质量及过程绩效目标的达成状况。 4. 运用关键属性度量所调整的过程绩效模型，以估计达成项目质量及过程绩效目标的进度。一些到项目生命周期后期才能度量的进度，可运用过程绩效模型加以估计，例如：可运用过程绩效模型，并使用同行查核时的过渡度量，预测交付产品时的潜在缺陷。过程绩效模型用于估计进度目标该目标一定要在项目生命周期的未来阶段，才能度量。例如运用过程绩效模型，并使用同行查核时的过渡度量，预测交付产品时的潜在缺陷。有关过程绩效模型，请参考组织过程绩效过程域，以获得更多信息。此处的调整是以执行先前子实践所得的结果为基础。 5. 识别并管理达成项目质量及过程绩效目标的相关风险。有关识别及管理风险，请参考风险管理过程域，以获得更多信息。风险的来源，举例如下： • 组织度量资产库内缺乏稳定性及能力数据 • 子过程缺乏绩效或能力 • 供应商未能达成其质量及过程绩效目标 • 对供应商的能力缺乏深入了解 • 用于预测未来绩效的组织过程绩效模型内不正确 • 预测过程绩效(估计进度)时的缺陷 • 其它与所识别缺陷相关的风险 6. 决定并记录在达成项目质量和过程绩效目标的过程中，用以解决缺陷的行动措施。这些行动措施的目的，是要规划及部署正确的活动、资源及进度，以尽可能将项目带回正轨，以达成项目目标。在达成项目目标过程中，用以解决缺陷的行动措施，举例如下： • 改变质量或过程绩效目标，使得这些目标在项目已定义过程的预期范围内。 • 改进项目已定义过程的实行过程，以减小其常态的变异性(在不必移动平均值的情形下，藉由减小变异，将项目绩效带回项目目标之内) • 实行可能满足目标及管理相关风险的新子过程及技术。 • 识别这些缺陷的风险及降低风险的策略 • 终止项目有关采取纠正措施，请参考项目监控过程过程域，以获得更多信息。 SG 2 统计化管理子过程绩效以统计化方式管理项目的已定义过程之子过程绩效。此特定目标描述在本过程域中用以达成「量化管理项目」特定目标的重要活动，此特定目标的特定实践描述如何统计化管理依第一个特定目标下的特定实践所选取的子过程，当这些选定的子过程被统计化管理时，便可确定各子过程达成目标的能力，藉此，就可能预测项目是否可以达成其目标，此即为量化项目管理的关键。 SP 选定度量及分析技术选定将用于统计化管理所选定子过程的度量及分析技术。有关设定度量目标，定义、收集及分析度量，以及修订度量及统计分析技术，请参考度量与分析过程域，以获得更多信息。典型的工作产品 1. 用于(或建议采用)统计化管理所选定子过程之度量及分析技术的定义 2. 度量的操作定义，它们在子过程的收集点，以及如何确定度量的完整性。 3. 度量的可追溯性，可回溯至项目质量及过程绩效目标 4. 支持自动化数据收集的工具化组织支持环境子实践 1. 从支持统计化管理的组织过程资产中，识别共性度量。有关共性度量，请参考组织过程定义过程域，以获得更多信息。可运用产品线或其它分层准则将共性度量分类。 2. 识别此物理所需的额外度量，以涵盖所选定子过程的关键产品及过程属性。在某些情形，度量可能是研究导向的，应特别标示这些度量。 3. 识别适用于统计化管理的度量。选择统计化管理度量的关键性准则如下： • 可受控制(例如：改变子过程的实践，是否能改变度量值？) • 适当的绩效指标(例如：以子过程达成重要目标的程度来看，其度量是否是个好的指标？) 子过程度量，举例如下： • 需求变动性 • 规划参数估计值相对于度量值的比例(例如：规模大小、成本及进度) • 同行评审的涵盖度及效率 • 测试涵盖度及效率 • 培训的成效(例如：培训计划的完成比例及测验分数） • 可靠度 • 项目生命周期各阶段新增或发现缺陷占总缺陷的百分比 • 项目生命周期各阶段所工作量占总工作量的百分比 4. 制定度量的操作定义，它们在子过程的收集点，以及如何确定度量的完整性。说明操作定义时，必须明确而不含糊，以下是两个重要的说明准则： • 明确传达：说明度量的内容、如何进行度量、度量的单位，以及纳入或排除的度量项目。 • 可重复性：度量是否可以重复，在于是否给予相同的定义以获取相同的结果。 5. 分析指定度量与组织及项目目标之间的关联性，并推衍出目标，说明每个选定子过程的度量属性，必须符合的特定目的之度量或范围。 6. 配置支持统计化度量资料收集、推导及分析的工具化组织支持环境。工具化的基础包括： • 组织标准过程的描述 • 项目已定义过程的描述 • 组织支持环境的能力 7. 识别适用于子过程统计化管理的适当统计分析技术。「一双鞋子无法适合所有人」的观念可应用到统计分析技术。决定某一特定的统计技术是否适用的因素，不仅是度量的类型，更重要的是：度量如何使用、实际情况是否确保可应用该技术等。选择的适当性须随时加以了解探究。统计分析技术的范例将在下个特定实践中说明。 8. 必要时修订度量及统计分析技术。 SP 应用统计方法了解变异运用选定的度量及分析技术，以建立并维护对所选定自过程的变异的了解。有关收集、分析及运用度量结果，请参考度量与分析过程域，以获得更多信息。收集并分析过程及产品度量数据，可以了解部分的过程变异性，藉此可以进一步识别及说明造成变异的特殊原因，以达成预期的绩效。过程变异的特殊原因是过程执行时产生非预期性的改变，特殊的原因也称为「可指定的原因」，因为这些原因可以识别、分析及说明，以预防变异重复发生。识别变异的特殊原因应先区隔系统变异的共同原因，区隔的方式包括使用极端的数值或其它由子过程或相关工作产品收集而来可辨别的数据形式，有关过程变异的知识、判断异常型态来源的洞察力是发掘特殊原因时应具备的能力。过程变异异常型态的来源，包括： • 与过程不符 • 数个子过程对数据产生的不明影响 • 子过程内部活动的顺序与时机 • 子过程的未控管输入 • 子过程执行时环境的改变 • 进度压力 • 不恰当的数据取样或组合典型的工作产品 1. 收集的度量 2. 每个选定子过程之度量属性的过程绩效常态范围 3. 与每个选定子过程之度量属性的过程绩效常态范围相比较的过程绩效子实践 1. 针对具适当历史绩效数据的子过程，设定试验性质的常态范围。有关组织过程绩效基线，请参考组织过程绩效过程域，以获得更多信息。属性的常态范围是变异发生的正常范围，所有过程在执行过程中，均会出现过程及产品度量数值上的一些变异。但存在的问题是：这些变异是起因于过程正常执行的共同变异原因，或是起因于某些应加以识别并解决的特殊原因。当一子过程开始执行时，设定试验性的常态范围，有时可从该子过程或相类似过程的先前实例、过程绩效基线或过程绩效模型取得合适数据，这些数据通常包含于组织度量资产库。执行子过程时，可收集特定案例的资料，以更新及取代试验性的常态范围值。不过，如果有疑虑的流程已经过大幅的定义，或情况已和过去的执行状况有很大的差异，度量资产库的数据可能就不适当，且不应该使用。在某些情形，可能没有类似的历史数据(例如：当引进一项新的过程、进入一个新的应用领域或子过程已有显著改变时)。针对这些情形，应使用子过程的初期过程数据，建立试验性的常态范围，这些试验性的常态范围应随着过程的进行，适时地调修及更新。决定数据是否可进行比较的准则，举例如下： • 产品线 • 应用领域 • 工作产品及任务属性(例如：产品规模大小) • 项目规模大小 2. 依选定的度量，收集执行子过程时的度量数据。 3. 针对每一度量属性，计算过程绩效的常态范围。计算常态范围之处，举例如下： • 控制图 • 信赖区间(针对分配参数) • 预测区间(针对将来的结果) 4. 识别变异的特殊原因。在控制图中，侦测过程变异特殊原因的一个准则范例是：一个落在3 个标准差控制界限外的数据点。侦测发生变异特殊原因的准则，是以统计理论及经验为基础，并考量经济上的可行性。当增列准则时，虽可以更容易识别特殊原因，但出现假警报的机会将增加。 5. 分析过程变异的特殊原因，以确认异常发生的原因。分析变异特殊原因之理由的技术，举例如下： • 因果关系图(鱼骨图) • 实验设计 • 控制图(应用于子过程输入或较低层次的子过程) • 分群法(依对子过程实行的了解，将数据分割至较小的群组，参考区隔特殊原因) 一些异常可能仅是统计分配的极端值而不是问题，实行过程的人通常是最具分析并了解变异特殊原因能力的人。 6. 当识别变异的特殊原因之后，决定应采取什么纠正措施。移除变异的过程特殊原因并不是要改变子过程，而是说明子过程在某种程度上执行的错误。有关采取纠正措施，请参考项目监控过程域，以获得更多信息。 7. 必要时针对所选定子过程的每一度量属性，重新计算其常态范围。以预示子过程已经改变的度量值为基础(而不是以预期或随意的决策为基础)，重新计算(统计方法估算)常态范围。常态范围需要重新计算的时机，举例如下： • 对子过程有累进的改进 • 子过程部署新的工具 • 部署新的子过程 • 所收集的度量数据指出，子过程的平均值已经永久性改变，或子过程的变异已经永久性改变 SP 监控子过程的绩效监控所选定子过程的绩效，以确认这些子过程满足其质量及过程绩效目标的能力，并于适当时机识别纠正措施。本特定实践的目的是要： • 以统计的方式从子过程的预期，决定过程的行为 • 评价过程达成其质量及过程绩效目标的机率 • 以过程绩效数据统计分析为基础，识别要采取的纠正措施。纠正措施可包含：重新协商受影响的项目目标、识别及实施替代的子过程，或识别并度量更低等级的子过程，以了解绩效数据更多的细节。这些行动是要帮助项目运用合格过程。有关「合格过程」的定义，请参见附录C 词汇。所选定子过程的能力与其质量及过程绩效目标相比较的先决条件之一是：对其度量属性而言，子过程的绩效要具稳定性及可预测性。应针对已设定(衍生)目标的子过程及度量属性，分析其过程能力，并不是所有纳入统计化管理的子过程或度量属性，都要分析其过程能力。历史数据可能不足以初步决定一过程是否合格，也有可能子过程绩效的常态范围估计值，与质量及过程绩效目标逐渐产生差距。无论是上述何种情形，统计控制隐含着监控其能力及稳定性。典型的工作产品 1.每一所选定子过程过程绩效的常态范围与其(衍生)目标的比较 2.每一子过程的过程能力 3.每一子过程解决过程能力缺陷的行动子实践 1.比较质量及过程绩效目标与度量属性常态范围的差异。本比较对子过程的每一度量属性，评估其过程能力。这些比较可以图形的方式表示，藉由图形可显示出常态范围估计值与目标间的相对关系，或作为过程能力指针，用来摘要目标与常态范围间的相对关系。 2.监控质量及过程绩效目标，以及选定之子过程过程能力的变化。 3.识别并记录子过程的能力缺陷。 4.决定并记录解决子过程能力缺陷所必要的行动。当所选定子过程的绩效未能达成其目标时，可采取的行动，举例如下： •改变质量及过程绩效目标，使其落入子过程的过程能力范围内 •改进现行子过程的实施过程，以减小其常态的变异性(在不必移动平均值的情形下，藉由减小变异性，将常态范围落入目标范围内) •实行有可能满足目标及管理相关风险的新过程组件、子过程及技术 •针对每一子过程的过程能力缺陷，识别这些缺陷的风险及风险降低策略有关采取纠正措施，请参考项目监控过程域，以获得更多信息。 SP 记录统计管理数据将统计的及质量管理资料记录于组织度量存储库。有关管理及存储数据、度量定义及度量结果，请参考度量与分析过程域，以获得更多信息。有关组织度量资产库，请参考组织过程定义过程域，以获得更多信息。典型的工作产品 1. 记录于组织度量资产库的统计及质量管理数据各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施量化项目管理过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行量化项目管理过程。详细说明：本方针建立组织的期望，依质量及过程绩效目标，进行量化项目管理，并对项目已定义过程中所选定的子过程，进行统计化管理。 GP 规划过程建立并维护用来执行量化项目管理过程的计划。详细说明：执行量化项目管理过程的计划可包含在项目计划(或者被参考)。项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行量化项目管理过程、开发工作产品及提供过程服务。详细说明：可能需要统计及统计过程控制等特殊的专业知识，以识别所选定子过程统计化管理所需的技术，项目成员需运用统计工具及技术，以执行统计化管理工作。可能也需要统计学的特殊专业知识，以便分析及解读统计化管理所取得的度量资料。提供的其它资源/工具，举例如下： • 系统动态模型 • 测试涵盖度自动化分析工具 • 统计过程及质量控制软件包 • 统计分析软件包 GP 分配责任分配量化项目管理过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持量化项目管理过程。详细说明：培训的主题，举例如下： • 过程模型化及分析 • 过程度量数据选择、定义及收集 GP 管理配置将指定的量化项目管理过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 纳入项目已定义过程的子过程 • 度量的操作定义、度量数据在子过程的收集点，以及如何判定度量的完整性 • 收集的度量 GP 识别并纳入相关的干系人依计划识别并纳入量化项目管理过程相关干系人。详细说明：干系人参与的活动，举例如下： • 设定项目目标 • 解决项目质量及过程绩效目标的问题 • 评估所选定子过程的绩效 • 识别并管理在达成项目质量及过程绩效目标过程中的风险 • 识别必须采取的纠正措施 GP 监控过程依本过程的执行计划，监控量化项目管理过程，并采取适当的纠正措施。详细说明：用于监控的度量，举例如下： • 纳入统计化管理的子过程摘要(例如：计划纳入统计化管理的子过程数量、目前正以统计化管理的子过程数量及具统计稳定性的子过程数量) • 已识别之变异特殊原因的数量 • 当度量与分析的活动周期与量化管理活动相关时，它资料收集、分析与报告的进度。 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估量化项目管理过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 依质量及过程绩效目标进行量化项目管理 • 对项目已定义过程的子过程进行统计化管理审查的工作产品，举例如下： • 包含于项目已定义过程的子过程 • 度量的操作定义 • 收集的度量 GP 与高层管理人员审查各状况与高层管理人员审查量化项目管理过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义量化项目管理过程的说明。 GP 收集改进信息收集由规划和执行量化项目管理过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息，举例如下： • 项目的统计画与质量管理数据的纪录，包含如依已建立项目过渡性目标，定期审查统计化管理子过程的实际执行绩效，所得到的审查结果。 • 过程与产品质量保证报告，用以识别在执行上虽不一致但符合的统计化子过程。仅适用于连续式表示 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护量化项目管理过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定量化项目管理过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保量化项目管理过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正量化项目管理过程之缺陷与其它问题的根本原因。需求开发（RD 3级）成熟度第三级的工程类过程域目的需求开发(Requirements Development, RD)的目的，在于产出并分析客户、产品及产品组件的需求。简介本过程域描述客户、产品及产品组件等三种需求，这些需求说明相关干系人的需要，包括与产品生命周期各阶段 (如，验收测试准则)及产品属性(如，安全性、可靠性、与维护能力等) 有关的需要。需求也包括选择某设计解决方案而产生的限制条件。例如：与现成品集成的需求。所有开发项目都有需求，从项目于维护活动的项目案例来看，产品或产品组件的变更，是基于现有需求、设计、或实现的变更。需求变更可能来自顾客或使用者所记载的变更请求单，或来自于需求开发过程的新需求形式。不论需求来源或型式，变更所驱动的维护活动也要加以管理。需求是设计的基础，需求的开发包括下列活动： • 诱导、分析、验证，以及沟通客户的需要、期望及限制，以获得客户需求，并达成干系人的共识 • 收集和协调干系人的需要 • 开发产品的生命周期需求 • 建立客户需求 • 建立与客户需求一致的原始产品及产品组件需求因为客户也可能提出特定的设计需求，本过程域讨论所有客户的需求，而非局限于产品层次的需求。客户需求可进一步调修为产品及产品组件需求。除客户需求外，选定的解决方案也可能衍生产品及产品组件需求。整个过程域中，产品及产品组件的意涵也包括服务及其组件。在整个产品生命周期中识别并修订需求。对设计决策、后续的纠正措施，以及产品生命周期各阶段所产生的反馈进行分析，以了解它们对衍生及已配置需求的影响。需求开发过程域包括三项特定目标。「开发客户需求」特定目标说明如何定义完整的客户需求，以使用于产品需求开发。「开发产品需求」特定目标说明如何定义完整的产品和产品组件需求，以使用于产品和产品组件设计。「分析并确认需求」特定目标说明客户、产品及产品组件需求须执行的必要分析，以定义、衍生及了解需求。第三项特定目标的特定实践，用以辅助前两项特定目标的特定实践。需求开发过程域的过程和技术解决方案过程域的过程，可彼此相互循环互动。对竞争的备选方案进行分析，以了解、定义及选用各层次的需求。这些分析活动包括： • 分析产品生命周期每阶段的需要和需求，包括：相关干系人的需要、操作环境，以及反映所有客户及使用者之期望和满意的因素(如安全性、保密性及负担能力) • 开发操作观念 • 定义必要的功能功能的定义，也称为「功能分析」，与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。在对象导向的软件设计里，它相当于定义所谓的「服务」或「方法」。功能、功能的逻辑群组，以及它们和需求之间关连的定义，就是所谓的「功能架构」。对产品架构更细层次不断地分析，直到获得足够的细节以进行产品的详细设计、采购及测试。通过分析需求的结果及操作概念(包括功能性、支持、维护及销毁)，制造或生产的概念会产生出更多的衍生需求，包括下列考量： • 不同类型的限制 • 技术的界限 • 成本和成本因素 • 时间限制和进度因素 • 风险 • 客户或使用者所暗示但未明确陈述之问题的考量 • 开发者独特的经营考量、规定及法律等所产生的因素逻辑物理的层次架构(功能及子功能，对象类别及子类别)，建立在反复开发的操作观念里。需求经过调修、衍生，才能配置到该逻辑物理。需求和逻辑物理再被配置于产品、产品组件、人员、或相关过程。在需求开发和分析时，纳入相关干系人的参与，藉此使他们了解需求的演进过程。本活动持续向相关干系人提供保证：需求已适切定义。相关过程域有关管理客户及产品需求、取得需求提供者同意、取得需求执行者承诺及维护追溯性，请参考需求管理过程域，以获得更多信息。有关如何使用需求开发过程域的输出，以及开发替代方案和设计，以用于调修和衍生需求，请参考技术解决方案过程域，以获得更多信息。有关接口需求和接口管理，请参考产品集成过程域，以获得更多信息。有关验证最终产品是否符合需求，请参考验证过程域，以获得更多信息。有关确认如何依照客户需要建置产品，请参考确认过程域，以获得更多信息。有关需求相关风险的识别和管理，请参考风险管理过程域，以获得更多信息。有关确保重要工作产品的控管，请参考配置管理过程域，以获得更多信息。特定目标及实践摘要 SG 1 开发客户需求 SP 诱导需要 SP 开发客户需求 SG 2 开发产品需求 SP 建立产品与产品组件需求 SP 配置产品组件需求 SP 识别接口需求 SG 3 分析并确认需求 SP 建立操作概念及场景 SP 建立必要功能的定义 SP 分析需求 SP 分析需求以取得平衡 SP 确认需求各目标的特定实践 SG 1 开发客户需求收集干系人需要、期望、限制及接口，并转换成客户需求。干系人(例如：客户、最终使用者、供应商、配置人员、测试人员、制造人员，与后勤支持人员)的需要，是决定客户需求的基础。进行干系人之需要、期望、限制、接口、操作概念，以及产品观念的分析、协调、调修及详细说明，以转换成客户需求。干系人的需要、期望、限制及接口，经常被粗略的识别或相互矛盾。因为必须清楚识别和了解干系人的需要、期望、限制及界限，在整个项目的生命周期里可使用反复的过程，以达到这目标。为帮助此必要的循环过程，最终使用者或客户的代表，通常会加入此过程，以说明其需要并帮助解决矛盾。组织的客户关系或营销部门，以及来自人际工程或支持部门的开发团队成员，可视为此类的代表。在研拟和解决客户需求时，也应考虑客户的外在环境、法规及其它限制。 SP 诱导需要诱导干系人提出有关产品生命周期各阶段的需要、期望、限制及接口。诱导不只是积极识别尚未经客户明确提出的新增需求。新增的需求应描述各种生命周期的活动，以及它们对产品的影响。诱导需要的技术，举例如下： • 技术展示 • 接口控制工作组 • 技术控制工作组 • 中间时期的项目审查 • 由最终使用者取得的问卷、访谈及操作场景等数据 • 操作的审查和最终使用者的工作分析 • 原型和模型 • 头脑风暴 • 质量功能展开 • 市场调查 • 试用版本的试用 • 由文档、标准或规格等来源中抽取 • 观察现行产品、环境及工作过程的样式(patterns) • 使用案例(use cases) • 经营案例分析 • 采取反向工程(针对现有产品) • 客户满意度调查可能未被客户识别的需求来源，举例如下： • 经营策略 • 标准 • 经营环境要求(例：研究室、测试其它设施、信息科技基础建设等) • 技术 • 现有产品或产品组件(可复用产品组件) Direct Artifact Example: Artifacts indicating stakeholder needs, expectations, and constraints (implicit and explicit) Indirect Artifact Example: - Results of requirements collection methods (., Interviews, prototypes, requirements analyses, market surveys, use cases., product domain analysis) - Evidence of customer interaction - Results of requirements reviews to remove conflicts 子实践 1. 与相关的干系人一起参与，并使用方法，以诱导出需求、期望、限制及外部接口。 SP 开发客户需求转换干系人的需求、期望、限制及接口为客户需求。来自相关干系人的各种输入，须经合并、取得遗漏的信息，以及解决冲突等过程，并记录为客户需求。客户需求可包括与验证和确认有关的需要、期望及限制。某些情况来说，客户提供项目的一套需求，或者之前项目活动的需求产出。以这些情况来说，客户需求与相关干系人的需要、期望、限制及接口可能有所冲突，所以在冲突适当解决之后，需要转换成被认可的客户需求。代表产品生命周期的所有阶段的相关干系人，应包括经营及技术功能。因此，所有与产品生命周期相关的过程概念，都应与产品的概念同步考量。客户需求来自信息充分的决策，同时考量需求在经营面与技术面的影响。典型的工作产品 1. Customer requirements客户需求（直接证据） 2. Customer constraints on the conduct of verification执行验证时的客户限制（直接证据） 3. Customer constraints on the conduct of validation执行确认时的客户限制（直接证据）子实践 1. 转换干系人的需要、预期、限制及接口，成为客户需求。 2. 定义验证及确认时的限制。 SG 2 开发产品需求调整并详细说明客户需求，以开发产品级产品组件需求。分析客户需求并开发操作概念，以衍生更详细和精准的需求，此需求称为「产品与产品组件需求」。「产品与产品组件需求」说明产品生命周期每一阶段的相关需要。衍生需求是由限制、对某些隐含问题的考量及某些因素而间接产生，这些问题在客户需求基线中并未明确说明；而这些因素是基于所选用的架构、设计，以及开发者独特的经营考量等而产生。需求须以后续的、较低阶的需求及功能架构再检查，并调修优先的产品概念。配置需求于产品功能及产品组件，包括对象、人员及过程，并记录需求到功能、对象、测试、问题，或其它物理的追溯性。已配置的需求及功能是组成技术解决方案的基础。当开发内部组件时，须定义新增的接口，并建立接口需求。有关维护双向追溯性，请参考需求管理过程域的「维护需求的双向追溯性」特定实践，以获得更多信息。 SP 建立产品与产品组件需求以客户需求为基础，建立并维护产品与产品组件的需求。客户需求可能以客户术语表示，且以较不具技术的方式描述。产品需求则是以专业术语表示这些客户需求，以用来进行设计的决策。「质量机能展开」是此转换的范例，它描述客户期望与技术参数的对应关系。例如：「结实的门」可能对应到尺寸规模大小、重量、适合、湿度及共振频率。「产品与产品组件需求」强调客户、经营，以及项目目标和相关属性(如有效性和负担能力)的满足。衍生需求也包括其它生命周期阶段的成本和绩效(如，生产、操作及销毁)，以与经营目标兼容。需求管理过程域涵盖需求变更的管理，而本特定实践的「维护」部分，涵盖因已批准的需求变更而引起的需求修改活动。有关管理需求变更，请参考需求管理过程域，以获得更多信息。典型的工作产品 1. 衍生需求 2. 产品需求 3. 产品组件需求子实践 1. 以专业术语开发产品与产品组件设计的需求。针对产品架构设计所需之重要的产品质量和绩效，开发架构需求。 2. 由设计决策衍生需求。有关开发解决方案以产生其它衍生需求，请参考技术解决方案过程域，以获得更多信息。技术的选用会引进其它的需求。例如：运用电子学将增加特定技术的需求，如电磁干扰的界限。 3. 建立并维护需求间的关连性，并考量在变更管理和需求配置时的影响。有关维护需求追溯，请参考需求管理过程域，以获得更多信息。需求间的关连有助于评估变更的影响。 SP 配置产品组件需求配置产品组件需求。有关配置需求到产品和产品组件，请参考技术解决方案过程域，以获得更多信息。本实践提供信息以定义需求配置，但必须和技术解决方案过程域的实践互动，以建立配置需求的解决方案。上述中所定义的解决方案，其产品组件的需求，包括所配置的产品绩效、设计限制，以及符合需求和有助于生产的合适、形式及功能。假使较高层需求的指定绩效归属于两组或以上的产品组件时，该绩效必须进行切割，并单独配置到各个产品组件，就像是衍生需求一样。典型的工作产品 1. 需求配置表 2. 暂时性的需求配置 3. 设计限制 4. 衍生需求 5. 衍生需求间的关系子实践 1. 配置需求于功能。 2. 配置需求于产品组件。 3. 配置设计限制于产品组件。 4. 记录已配置需求间的关系。关系包括依赖性，在这情境下，某需求的改变可能会影响其它的需求。 SP 识别接口需求识别接口需求。定义功能之间(或对象之间)的接口。功能接口可能衍生出替代方案的开发，替代方案在技术解决方案过程域中描述。有关接口管理以及产品和产品组件的集成，请参考产品集成过程域，以获得更多信息。定义产品架构中所识别之产品与产品组件间的接口需求，并将它们当做产品与产品组件集成的一部分来控制，它们也是架构定义中不可缺少的部分。典型的工作产品 1. 接口需求子实践 1. 识别产品内部及外部的接口(例如：功能分割或对象之间的接口)。在设计工作进行的过程中，产品架构可能受技术解决方案过程的影响，而产生产品组件和项目外部组件间的新接口。必须识别产品有关之生命周期过程的接口。与测试设备、传输系统、支持系统及制造设施之间的接口，都属于这类接口。 2. 开发已识别界面的需求。有关在设计过程中，如何产生接口需求，请参考技术解决方案过程域，以获得更多信息。例如以软件的来源、目的地、刺激及数据特征，和硬件的电子及机械的特征，来定义接口需求。 SG 3 分析并确认需求分析并确认需求，并开发所要功能的定义。「分析并确认需求」特定目标的特定实践，支持「开发客户需求」和「开发产品需求」两个特定目标的需求开发过程。本特定目标的特定实践涵盖需求的分析，以及确认需求是否符合使用者预期。执行分析，以决定为求满足干系人的需要、期望、限制及接口，对原计划的操作环境会产生哪些影响。视产品的范围而定，可行性、任务需要、经费限制、市场潜力及采购策略等都必须纳入考量，并建立必要功能的定义。所有产品的特定使用形式均应考量，并产生对时间敏感之功能顺序的时间点分析。分析的目的，在于决定可满足干系人需要、期望及限制之产品概念的可能需求，再将这些概念转换为需求。与此活动同时进行的是，依据客户的输入和初步的产品概念，决定用以评估产品有效性的参数。确认需求，以增加最终产品在使用环境中，可按照期望运作的可能性。 SP 建立操作概念及场景建立并维护操作概念及其相关的场景。场景一般而言是指使用产品时可能发生的事件顺序，以明确说明干系人的某些需要。相对的，产品的操作概念通常是依据设计方案和场景而来。例如：卫星的通讯产品与地面的通讯产品，它们的操作概念是不同的。在研拟原始操作概念时，其替代方案通常尚未定义。所以，在需求分析时，开发概念性的解决方案。在进行解决方案的决策时，调修操作概念，进而开发出详细的需求。正如某产品的设计决策可能变成产品组件需求，操作概念也可能变成产品组件的场景(需求)。开发操作概念及场景逐步开发，以利产品组件解决方法的选择，使得在实现后将满足产品的预期使用。不管哪一种工程，操作概念及场景描述了产品组件与环境、使用者，及其它产品组件的互动关系。包括营运、产品部署、交付、支持（含维护及营运）、培训、处置，以及所有的模型和状态等相关的操作概念与场景，都应予以描述。如果操作顺序用以表达客户需求而非操作概念，则场景可能包含了操作顺序。典型的工作产品 1. 操作概念 2. 产品或产品组件安装、操作、维护及支持概念 3. 销毁概念 4. 使用案例 5. 依时间演化的场景 6. 新需求子实践 1. 开发操作概念和场景，包括适当的功能、绩效、维护、支持及销毁。识别并开发场景，此场景须与干系人各详细等级的需要、预期及限制一致。经此建议的产品或产品组件应可如预期运作。 2. 定义产品或产品组件的操作环境，包括界限和限制。 3. 审查操作概念和场景，以调修需求并发现新需求。操作概念和场景的开发是个反复的过程。应定期举行审查，以确保其结果与需求一致。审查可采用逐步审查的形式。 4. 产品与产品组件一经选定，就开发详细的操作概念，以定义产品、最终使用者及环境之互动，并满足操作、维护、支持及销毁的需要。 SP 建立必要的功能定义建立并维护必要的功能定义。功能的定义，也就是所谓的「功能分析」，描述哪些是产品预期该做的，包括，行动、顺序、输入、输出，或其它说明如何使用产品的信息。功能分析与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。在对象导向的软件设计里，它相当于定义所谓的服务或方法。功能、功能的逻辑群组，以及它们和需求之关连的定义，就是所谓的「功能架构」。有关「功能架构」的定义，请参见词汇。典型的工作产品 1. 功能架构 2. 活动图和使用案例 3. 对象导向分析和已识别的服务或方法子实践 1. 分析和量化最终使用者需要的功能。 2. 分析需求，以识别逻辑或功能分割(如子功能)。 3. 依已建立的准则(如类似的功能、绩效或耦合)，将需求分割成群组，以促进和专注于需求分析。 4. 在产品开发的整个过程，考量具有时效性之功能的顺序。 5. 配置客户需求于功能分割、对象、人员或支持组件，以支持解决方案的综合。 6. 配置功能及绩效需求于功能及子功能。 SP 分析需求分析需求，以确保其必要性和充分性在操作概念和场景的说明下，分析在产品架构某一阶的需求，以决定其是否必要且可满足较高层的目标。经过分析的需求就变成产品架构中较低层需求的基础，而较低阶的需求通常是更详细且精准的。定义需求时，必须能了解它与更高层需求和已定义功能的关系。决定应识别哪些需求，以追踪技术的进展，也是重要的行动之一。例如：在整个开发过程，产品的重要性或软件产品的规模大小，可依其风险程度加以监控。有关用于支持此分析的验证方法，请参考验证过程域，以获得更多信息。典型的工作产品 1. 需求缺陷报告（直接证据） 2. 用来解决缺陷的需求变更建议（间接证据） 3. 关键需求（直接证据） 4. 技术绩效度量（间接证据）子实践 1. 分析干系人的需要、期望、限制及外部接口，以移除矛盾，并总结成相关主题。 2. 分析衍生需求，以决定是否满足更高层需求的目标。 3. 分析需求，以确保是完整、可行、可实现及可验证的。虽然「设计」决定某特殊解决方案的可行性，本子实践可以了解哪些需求会影响可行性。 4. 识别对成本、进度、功能、风险或绩效有重大影响的关键需求。 5. 识别技术绩效度量，以便于开发阶段时进行追踪。有关度量的用途，请参考度量与分析过程域，以获得更多信息。 6. 分析操作观念及场景，以调修客户需要、限制及接口，并发现新需求。此分析可能产生更详细的操作观念及场景，同时也衍生新需求。 SP 分析需求以取得平衡分析需求，并在干系人的需要和限制间取得平衡。干系人的需要和限制，可说明成本、进度、绩效、功能、再使用的组件、维护能力，或风险。典型的工作产品 1. 需求相关风险的评价子实践 1. 使用经验证的模型、仿真及原型等，以分析干系人之需要和限制间的平衡。分析的结果，可用以降低产品的成本与开发产品时的风险。 2. 执行需求及功能架构的风险评价。有关执行客户及产品需求和功能架构的风险评价，请参考风险管理过程域，以获得更多信息。 3. 检查产品生命周期概念，以分析它对需求风险的影响或冲击。 SP 确认需求确认需求以确保最终产品在使用者环境下如预期的运行。在开发工作的初期，与最终使用者执行需求确认，俾使需求能够引导开发工作，并导致成功之最终确认的信心。此活动应与风险管理活动集成。成熟的组织，通常会以更复杂的方式使用多种技术来执行需求确认，扩大确认的基础，以包括其它的干系人需要和期望。这些组织通常会使用分析、模拟或原型等方法，以确保需求满足干系人的需要和期望。需求确认的技术，举例如下： • 分析 • 模拟 • 原型 • 示范典型的工作产品 1. 分析方法和结果的纪录子实践 1. 分析需求以识别最终产品不能于使用者环境下适当运作的风险。 2. 以产品展示(如，原型、仿真、模型、情境及场景)，以及取得相关干系人的反馈，寻求需求的足够性和完整性。有关产品及产品组件的确认及确认执行，请参考确认过程域，以获得更多信息。 3. 于设计成熟时，在需求确认环境下进行设计的评价，以识别确认问题，并揭露未叙明的需要和客户需求。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施需求开发过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行需求开发过程。详细说明：本方针建立组织对下列活动的期望：收集干系人需要、明确地陈述产品及产品组件需求，以及分析和确认需求。 GP 策划过程建立并维护用来执行需求开发过程的计划。详细说明：执行需求开发的计划可以是项目计划的一部分，项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行需求开发过程、开发工作产品及提供过程服务。详细说明：应用领域的特殊专业知识、诱导干系人需要的方法，用于指定及分析客户、产品，以及产品组件需求的方法及工具等可能是必要的。可用于本过程域的资源(工具)，举例如下： • 需求规格工具 • 仿真及模型工具 • 原型工具 • 场景定义及管理工具 • 需求追踪工具 GP 分配责任分配需求开发过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持需求开发过程。详细说明：培训主题，举例如下： • 应用领域的专业知识 • 需求定义及分析 • 需求诱导 • 需求规格及模型 • 需求追踪 GP 管理配置将指定的需求开发过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 客户需求 • 功能架构 • 产品及产品组件需求 • 界面需求 GP 识别并纳入相关的干系人依计划识别并纳入需求开发过程相关干系人。详细说明：从下列人员中选择相关的干系人：客户、最终使用者、开发人员、制作人员、测试人员、供应商、市场营销人员、维护人员、报废处理人员，以及其他会影响产品及过程或受产品及过程所影响的人。干系人参与的活动，举例如下： • 审查需求的足够性，以满足需要、预期、限制及接口的要求。 • 建立操作观念和场景 • 评价需求的足够性 • 建立产品与产品组件需求 • 评价产品成本、进度及风险 GP 监控过程依本过程的执行计划，监控需求开发过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 成本、进度及重做所需的工作量 • 需求规格的缺陷密度 • 开发一组需求的活动进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估需求开发过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 收集干系人需要 • 明确地陈述产品与产品组件需求 • 分析并确认产品与产品组件需求审查的工作产品，举例如下： • 产品需求 • 产品组件需求 • 界面需求 • 功能架构 GP 与高层管理人员审查各状况与高层管理人员审查需求开发过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义需求开发过程的说明。 GP 收集改进信息收集由规划和执行需求开发过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 含糊不清的产品需求清单 • 产品生命周期各阶段的需求数量 • 需求配置过程的经验分享仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护需求开发过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定需求开发过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保需求开发过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正需求开发过程之缺陷与其它问题的根本原因。需求管理（REQM 2级）成熟度第二级的工程类过程域目的需求管理(Requirements Management, REQM)的目的，在于管理项目产品及产品组件的需求，并识别这些需求与项目计划及工作产品间的差异。简介「需求管理过程」管理项目所开发或接受的技术性、非技术性需求，以及组织加给项目的需求。尤其是如果组织实施「需求开发」过程域，它的过程所产生的产品及产品组件需求，也要纳入需求管理过程的管理。在所有的过程域中，当使用产品及产品组件这个专门名词时，也意指包含服务及其组件的意思。当组织实施需求开发、需求管理及技术解决方案等过程域，它们相关的过程将会紧密联系并同步执行。项目实行适当的步骤，确保确定的需求是受管理的，以支持项目策划和执行的需要。当项目从已明确的需求提供者收受需求时，应与其一起审查，以便在需求纳入项目计划前，先行解决有关问题并避免误解。一旦需求提供与接受的双方达成协议，须再取得项目成员对需求的承诺。当需求渐进开发时，项目需管理需求的变更，并识别计划、工作产品，以及需求间可能产生的差异。需求管理也需记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求之间的双向追溯性。(「双向追溯性」的定义，请参考词汇。) 所有开发项目都有需求。以专注于维护活动的项目来看，产品或产品组件的变更是基于现有需求、设计及开发的变更。如有需求变更，可能是记录在客户或使用者的变更请求上，也可能是从需求开发过程中所产生的新需求。不论来源或形式，因需求变更所引起的维护活动，应依此原则管理。相关过程域有关将干系人的需要转成产品需求，以及决定如何将需求配置于产品组件，请参考需求开发过程域，以获得更多信息。有关将需求转为技术解决方案，请参考技术解决方案过程域，以获得更多信息。有关项目计划如何反映需求，以及项目计划如何因需求变更而修订，请参考项目策划过程域，以获得更多信息。有关基线和如何控制需求的配置文档的变更，请参考配置管理过程域，以获得更多信息。有关以需求为基础的项目活动和工作产品之追踪与控制，以及采取适当的纠正措施，请参考项目监控过程域，以获得更多信息。有关与需求有关的风险识别与处理，请参考风险管理过程域，以获得更多的信息。特定目标及实践摘要 SG 1 管理需求 SP 理解需求 SP 取得需求承诺 SP 管理需求变更 SP 维护需求的双向追溯性 SP 识别项目工作与需求间的差异各目标的特定实践 SG 1 管理需求管理需求，并识别需求与项目计划及工作产品间的差异。本实践藉由进行下列活动，使项目能全程维护一组最新及已核定的需求： • 管理所有的需求变更 • 维护需求、项目计划及工作产品间的关系 • 识别需求、项目计划及工作产品间的差异 • 采取纠正措施有关决定需求的可行性，请参考技术解决方案过程域，以获得更多信息。有关确保需求能反映客户的需要和期望，请参考需求开发过程域，以获得更多信息。有关采取纠正措施，请参考项目监控过程域，以获得更多信息。 SP 理解需求与需求提供者一起理解需求的意义。当项目成熟且需求已衍生后，全部的项目活动或专业领域将接受需求。要避免需求不知不觉的到来，须建立准则，以指定需求接受的适当渠道和正式的来源。执行需求接受活动时，须与需求提供者一起分析需求，以确保对需求的意义能达成共识。此分析和对话的结果，才是被议定的需求。典型的工作产品 1. 区别适当需求提供者的准则清单 2. 需求评估和接受准则 3. 依准则进行分析的结果 4. 经议定的需求子实践 1. 建立区别适当需求提供者的准则清单。 2. 建立客观的需求评估及接受准则。缺乏评估及接受准则常常导致需求确认不够充分、昂贵的重做成本，或客户退货。需求评估及接受准则，举例如下： • 清晰而适当地表达 • 完整 • 相互的一致性 • 可个别识别 • 可适当地实现 • 可验证(可测试) • 可追溯 3. 分析需求，以确保其符合已建立之准则的要求。 4. 与需求提供者达成需求共识，使项目成员可对需求承诺。 SP 取得对需求的承诺取得项目成员对需求的承诺。有关承诺的监督，请参考项目监控过程域，以获得更多信息。 IPPD 补充组成集成团队(integrated teams)时，项目成员就是集成团队和其成员。对其他集成团队的互动也是一项需求，对此需求的承诺，其重要性一如对产品及其它项目需求的承诺一般。上一个特定实践用于处理如何与需求提供者达成需求的了解，本特定实践则处理如何取得项目成员的承诺和同意，这些项目成员是负责执行需求之必要活动的人员。在项目进行期间，需求将渐进开发，尤其是在需求开发过程域和技术解决方案过程域之特定实践的说明中。在需求逐渐开发的情况下，本特定实践确保项目成员对当时已核定需求的承诺，以及对项目计划、活动及工作产品所造成之变更的承诺。典型的工作产品 1. 需求影响评价(Requirements impact assessments) 2. 需求和需求变更承诺的纪录子实践 1. 评价需求对现有承诺的影响。需求变更或新需求发生时，评估其对项目成员的影响。 2. 协商并记录承诺。在项目成员对需求或需求改变承诺之前，对现有承诺的改变，应先协商。 SP 管理需求变更当需求与项目实施期间开发时，管理需求的变更。有关维护和控制需求基线，并使需求及其变更数据能为项目运用，请参考配置管理过程域，以获得更多信息。在项目执行期间，造成需求变更的原因甚多。当需要改变或工作进行中衍生新需求时，就可能需要变更现有的需求。如何有效率和有效果地管理这些新增需求或变更需求是很重要的。要有效分析变更所造成的影响，必须知道每一需求项目的来源，并记录变更的原因。然而，项目经理或许要追踪需求变更程度的适当度量，以决定是否要实施新的或修订现有的控制方式。典型的工作产品 1. 需求状况表 2. 需求数据库 3. 需求决策数据库子实践 1. 记录所有的需求和需求变更，不论是项目本身产生的或外界的要求。 2. 维护需求变更纪录，以及每次变更的理由。维护变更的历史纪录，有助于追踪需求变更的状况。 3. 从相关干系人的观点，评估需求变更的影响。 4. 确保项目人员能取得需求和变更的资料。 SP 维护需求的双向追溯性维护需求与工作产品间的双向追溯性。本特定实践的目的，在于维护每一阶产品组件需求的双向追溯性。(「双向追溯性」的定义，请参考词汇。)当有效地管理需求，就可建立从原始需求至低层需求的追溯性，亦可建立由低层需求至原始需求的追溯性。如此一来，双向追溯性可帮助确定已处理所有原始需求，以及所有低层需求皆可追溯至有效的来源。需求追溯性也可以涵盖与其它物理的关系，例如：中间和最终产品、设计文档的变更、测试计划及工作项目。追溯性应包括水平及垂直关系，例如：跨界面。在进行需求变更对项目计划、活动及工作产品的影响评价时，特别需要追溯性。典型的工作产品 1. 需求追溯表 2. 需求追踪系统子实践 1. 维护需求追溯性，确保已记录低阶(或衍生)需求的来源。 2. 维护需求追溯性，从需求到衍生需求，以及需求配置到功能、接口、对象、人员、过程及工作产品。 3. 制作需求追溯表。 SP 识别项目工作与需求间的差异识别需求与项目计划及工作产品间的差异。有关监控项目计划及工作产品与需求是否一致，以及视需要采取纠正措施，请参考项目监控过程域，以获得更多信息。本特定实践用以找出需求与项目计划及工作产品间的差异，并启动修正的纠正措施。典型的工作产品 1. 差异纪录，包括差异来源、条件及理由 2. 纠正措施(corrective actions) 子实践 1. 审查项目计划、活动及工作产品，是否与需求及需求变更相符。 2. 识别差异来源及其理由。 3. 当需求基线有变动时，识别有关计划及工作产品所需的变更。 4. 启动纠正措施。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施需求管理过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行需求管理过程。详细说明：本方针建立组织对下列活动的期望：管理需求，以及识别需求与项目计划及工作产品间的差异。 GP 规划过程建立并维护用来执行需求管理过程的计划。详细说明：执行需求管理的计划通常是项目计划的一部分(或可参照)，项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行需求管理过程、开发工作产品及提供过程服务。详细说明：可用于本过程域的资源(工具)，举例如下： • 需求追踪工具 • 追溯工具 GP 分配责任分配需求管理过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持需求管理过程。详细说明：培训的主题，举例如下： • 应用领域的专业知识 • 需求定义、分析、审查及管理 • 需求管理工具 • 配置管理 • 谈判及冲突解决 GP 管理配置将指定的需求管理过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 需求 • 需求追溯表 GP 识别并纳入相关的干系人依计划识别并纳入需求管理过程相关干系人。详细说明：从下列人员中选择相关的干系人：客户、最终使用者、开发人员、制作人员、测试人员、供应商、市场营销人员、维护人员、报废处理人员，以及其他会影响产品及过程或受产品及过程所影响的人。干系人参与的活动，举例如下： • 解决需求了解的问题 • 评价需求变更的影响 • 沟通双向追溯性 • 识别项目计划、工作产品及需求间的差异 GP 监控过程依过程的执行计划，监控需求管理过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 需求变动率(即需求变更的百分比) • 需求协调的进度 • 所建议的需求变更的分析进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估需求管理过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 管理需求 • 识别项目计划、工作产品及需求间的差异审查的工作产品，举例如下： • 需求 • 需求追溯表 GP 与高层管理人员审查各状况与高层管理人员审查需求管理过程的活动、状况及结果，并解决问题。详细说明：针对组织外部承诺的变更建议，必须与高层管理人员审查，以确保所有的承诺可以完成。仅适用于阶段式表述 GG3 及其实践，不是成熟度第二级评等的必要项目，但它们是成熟度第三级和更高等级评等的必要组件。仅适用于连续式/成熟度第3-5 级 GG 3 制度化已定义过程将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义过程与产品质量保证过程的说明。 GP 收集改进信息收集由规划和执行需求管理过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息的范例包括下列： • 需求追溯表 • 基线设定后，无费用的需求变更数量 • 解决含糊不清需求的经验分享仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护需求管理过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定需求管理过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保需求管理过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正需求管理过程之缺陷与其它问题的根本原因。风险管理（RSKM 3级）成熟度第三级的项目管理累过程域目的风险管理(Risk Management, RSKM)的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划风险处理活动，并于必要时启动之，如此可将不利于完成目标的影响降低。简介风险管理是一个持续的、前瞻的过程，此过程是管理的重要部分。风险管理应该强调可能会危害到重要目标的问题。持续的风险管理方法可以有效预测并降低对项目有重大影响的风险。有效的风险管理是通过相关的干系人的合作与参与，及早且积极的识别风险，如同项目策划过程域所述的「干系人参与计划」一样。需要具备领导相关干系人的优越领导能力，以建立自由、公开及讨论风险的环境。风险管理须同时考虑有关成本、进度、绩效及其它风险的内部及外部来源。因为在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低及较不具破坏性，所以，早期及积极的风险侦测是重要的。风险管理可以区分成三部分：定义风险管理策略、识别及分析风险，以及处理已识别的风险，包括必要时，执行风险降低计划。如同项目策划过程域和项目监控过程域所示，组织初期可能只专注于识别风险，以及当这些风险发生时采取行动。风险管理过程域描述这些特定实践之演进，以有系统的规划、预测及降低风险，使对项目的冲击降至最低。虽然风险管理过程域主要强调的是项目，但观念亦可应用在管理组织的风险。相关过程域有关项目风险识别及干系人参与的规划，请参考项目策划过程域，以获得更多信息。有关监控项目风险，请参考项目监控过程域，以获得更多信息。有关使用正式评估过程以评估选择及降低已识别风险的备选方案，请参考决策分析和解决方案过程域，以获得更多信息。特定目标和实践摘要 SG 1 风险管理准备 SP 决定风险来源和类别 SP 定义风险参数 SP 建立风险管理策略 SG 2 识别并分析风险 SP 识别风险 SP 评估、分类及排序风险 SG 3 降低风险 SP 开发风险降低计划 SP 执行风险降低计划各目标的特定实践 SG 1 风险管理准备准备执行风险管理。建立并维护用来识别、分析及降低风险的策略，以执行风险管理的准备工作。风险管理策略通常记录于风险管理计划中。风险管理策略说明用来控制风险管理计划的特定活动和管理方法。这包括识别风险来源、风险分类的计划，以及用来有效处理评估、限定和控制风险的参数。 SP 决定风险来源和类别决定风险来源和类别。识别风险来源提供一种基础，以系统化检视随时间而改变的状况，发觉影响项目达成目标的情况。风险来源来自项目的内部及外部。在项目进行过程中，可能识别其它的风险来源。建立风险类别提供一种机制以收集和组织风险，并对比较严重影响项目目标的风险，保持适当的警觉和注意。典型的工作产品 1. 风险来源清单(内部及外部) 2. 风险类别清单子实践 1. 决定风险来源。风险来源是项目或组织内造成风险的基本因素，项目有许多内部及外部的风险来源。风险来源是识别风险发生的共同来源，典型的内部及外部风险来源包括下列各项： • 不确定的需求 • 无前例的工作量─无法取得预估值 • 不可行的设计 • 不存在的技术 • 不实际的进度估计值或配置 • 不充分的人员配置和技能 • 成本或资金问题 • 不确定或不充分的分包商能力 • 不确定或不充分的供应商能力 • 与实际或潜在客户，或与业务代表的不充分沟通 • 营运连续性的中断很多风险来源经常未做充分规划就已被接受。越早识别内部和外部的风险来源，即可尽早识别风险，并在项目初期执行风险降低计划，以排除风险的发生，或降低发生时的严重性。 2. 决定风险类别。风险类别表达「贮存仓」的概念，用来收集和组织风险。识别风险类别的原因之一是它可帮助未来集成风险降低计划的各项活动。决定风险类别时，可考虑下列因素： • 项目生命周期模型的各阶段(如：需求、设计、制造、测试与评估、交付、汰除) • 使用的过程类型 • 使用的产品类型 • 计划管理的风险(如：合同风险、预算/成本风险、进度风险、资源风险、绩效风险、支持能力的风险) 风险分类表可作为风险来源和类别的架构。 SP 定义风险参数定义用来分析及分类风险的参数，以及用以控制风险管理投入的参数。用来评估、分类和排序风险的参数，包括下列各项： • 风险可能性(即风险发生的机率) • 风险结果(即风险发生的影响和严重性) • 驱动管理活动的阈值风险参数提供共同且一致的准则，用以比较需要管理的各种风险。没有这些参数，则由风险导致的非预期变更，将很难估计其严重程度；在风险降低计划中，也很难排定必要行动的优先级。典型的工作产品 1. 风险评估、分类及排定优先级的准则 2. 风险管理需求(例：控制与批准等级、再评价的时间间隔等) 子实践 1. 定义一致性的准则，以评估及量化风险的可能性及严重程度。通过使用一致性的准则(例如：可能性和严重程度的范围)，可共同了解不同风险之冲击，使能适度的检查，并保证获得管理者注意。在管理不同的风险方面(例如：人员安全相对于环境污染)，保证最终结果的一致性是重要的(例如：环境污染的高风险和人员安全的高风险一样重要)。 2. 定义每个风险类别的阈值。对每一风险类别，可建立阈值以决定风险的可接受性或不可接受性、风险的优先级，或管理行动启动装置。阈值的范例，举例如下： • 项目阈值值可建立为：当产品成本超过目标成本百分之10，或当成本绩效指标(CPI)降到以下时，可与资深管理阶层共同研商。 • 进度阈值值可建立为：当进度绩效指标(SPI) 降到以下时，可与资深管理阶层共同研商。 • 绩效阈值值可建立为：当关键项目(如处理器使用率或平均反应时间)超过预期设计的百分之125 以上，可与资深管理阶层共同研商。对每个已识别的风险，建立若干个监控点，以更积极的监控风险，或通知执行降低风险计划。这些数值日后可再调修。 3. 定义某风险类别阈值的范围。并未限制风险以量或质的方式评价。范围的定义(或范围的条件)，可用来限定风险管理投入程度，以避免资源过度消耗。范围的订定，可排除某个类别的风险来源，亦可排除任何发生小于某个频率的情况。 SP 建立风险管理的策略建立并维护风险管理的策略。详细风险管理策略说明的事项如下： • 风险管理投入的范围 • 使用于风险识别、风险分析、风险降低、风险监控及沟通的方法及工具 • 项目特定的风险来源 • 如何组织、分类、比较及集成风险 • 对已识别风险采取行动的参数，包括可能性、结果及阈值 • 风险降低所使用的技术，例如：原型制作、试行、模拟、备选方案设计或渐进式开发 • 定义风险度量，以监控风险状况 • 风险监控或再评价的时间间隔风险管理策略应由共同的成功愿景所导引，这愿景从交付产品、成本及对任务之适用性的观点，来描述对未来项目结果的期望。风险管理策略通常记录于组织或项目的风险管理计划。风险管理策略由相关的干系人审查，以增进承诺和了解。典型的工作产品 1. 项目风险管理策略 SG 2 识别并分析风险识别并分析风险，以决定其相对的重要性。风险的严重程度会影响用于处理已识别风险的资源，以及何时需要适当之管理阶层关切的决定。分析风险需要自已经识别的内外部来源识别风险，而后评估每一风险，以决定可能性和发生结果。风险分类提供处理风险所需的信息，它是依据已建立的风险类别，以及风险管理策略所开发的准则来进行评估。为了有效率的处理和有效的应用风险管理资源，可把相关风险组成不同的群组。 SP 识别风险识别并记录风险。 IPPD 补充需考虑集成团队执行项目时的特殊风险，例如：团队外部或团队内部间失去协调所导致的风险。识别可能会负面影响工作投入或计划的潜在问题、危险、威胁及弱点等，是完整及成功的风险管理的基础。必须先用容易明了的方式，识别与描述风险，才可以适当的分析与处理风险。用简洁的叙述记录风险，包括风险发生的内容、条件及结果。风险识别应是有组织及透彻的方法，以找出在达成目标的过程中可能发生或实际的风险。为了有效起见，风险识别不应试图说明每一可能事件，而无论其是否极不可能发生。使用由风险管理策略开发出来的类别与参数，以及已识别的风险来源，可提供适用于风险识别的规范及效率。已识别的风险是启动风险管理活动的基线。风险清单应定期审查，以重新检查可能的风险来源和状况变更，以揭露自风险管理策略前次更新以来，忽略或不存在的风险与来源。风险识别活动着重于风险的识别，而非给予责难，管理者不应使用风险识别活动的结果来评估个人的绩效。识别风险的方法有很多，典型的识别方法如下： • 检查项目工作拆分结构的每个组件以找出风险。 • 使用风险分类表来评价风险。 • 访谈主题事务专家。 • 由类似产品的比较来审查风险管理投入。 • 检查学习心得文档或数据库。 • 检查设计规格和协议书需求。典型的工作产品 1. 已识别的风险清单，包括风险发生的内容、条件及结果。子实践 1. 识别与成本、进度及绩效相关的风险。检查成本、进度及绩效风险对项目目标的冲击程度。可能有潜在风险不在项目目标的范围内，却对客户的利益非常重要。例如：开发成本、产品取得成本、备品(或替代品)成本及产品处理(汰除) 成本等风险隐含在设计中。客户可能并未考虑到支持现场产品或交付服务的所有成本。客户虽然未必需要主动管理那些风险，但应被告知风险。适当时，应该在项目和组织等级，检查并实施此种决策的机制，尤其是对于影响验证与确认产品能力的风险。除了以上所识别的成本风险外，其它的成本风险包含与赞助资金额、资金估计及预算分配有关的问题。进度风险包括与规划的活动、主要事件及里程碑相关的风险。绩效风险包含与下列相关的风险： • 需求 • 分析与设计 • 新技术应用 • 物理规模大小 • 形状 • 重量 • 生产与制造 • 功能绩效及操作 • 验证 • 确认 • 绩效维护属性绩效维护属性是指某些特征，这些特征会让使用中的产品或服务保有原先所要求的绩效，例如：维持安全和保密绩效。还有其它非属成本、进度或绩效上的风险类别。以下是其它风险的范例： • 与罢工相关的风险 • 供应来源缩减 • 科技循环时间 • 竞争 2. 审查可能影响项目的环境因素。项目经常疏忽的风险，包含那些被认为在项目范围外的风险(即项目无法控制他们是否发生，但可降低其冲击)，例如：天气，影响营运持续性的自然或人为灾害，政治变化及电信故障。 3. 审查工作拆分结构所有组件，作为风险识别的一部分，以帮助确保所有的工作投入均已考虑。 4. 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑。有关识别项目风险，请参考项目策划过程域，以获得更多信息。 5. 记录风险之内容、条件及可能的结果。风险说明通常以标准的格式记录，包含风险内容、条件及发生的结果。风险内容提供额外的信息，可容易了解风险的意义。在记录风险内容时，要考虑风险出现的相对时间顺序，以及风险周遭的环境或条件，因风险会带来关切、疑虑或不确定性。 6. 识别每一风险相关的干系人。 SP 评估、分类及排序风险利用定义的风险种类及参数，评估及分类每个已识别的风险，并决定其相对的优先处理顺序。在指定每个已识别的风险相对的重要性时需要风险评估，以决定在何时需给予适当的管理阶层注意。依据风险间相互关系将风险汇集起来，并于某汇集等级上开发方案，通常是有用的。当一个风险由较低等级风险向上汇集而形成时，必须小心谨慎，以确保未忽略重要之较低等级的风险。总体来说，风险评估、分类及排序的活动，有时被称为「风险评价」或「风险分析」。典型的工作产品 1. 风险清单，包含各风险的优先级子实践 1. 利用已定义的风险参数，评估已识别的风险。根据定义的风险参数，评估每个风险并指定数值，数值可包括可能性、结果(严重性或冲击度) 及阈值。可集成这些指定的风险参数值以产生额外的度量，例如：风险曝光程度可用来排列风险的优先级，以便处理。通常具有3 到5 个数值的量尺，可用来评估可能性和结果。例如：可能性可分类为微乎其微、不太可能、可能、非常可能，或近乎确定。结果(严重性或冲击度)的范例，举例如下： • 低 • 中 • 高 • 可忽略 • 微小 • 重要 • 严重 • 灾难机率值经常用来量化可能性。结果通常和成本、进度、环境冲击或人员度量值相关(例：人力时间损失和伤害的严重程度)。此评估经常是困难且费时的工作，可能需要特定的专门知识或群组技术，以评价风险和获得对排定优先级的信心。此外，优先级随着时间进展可能需要重新评估。 2. 依照定义的风险类别，将风险分类并分组。将风险归类到已定义的风险类别，可提供一个根据风险的来源、分类表或项目组件，检查风险的方法。相关或相同的风险可归成一类，以便有效处理，并记录相关风险之间的因果关系。 3. 排列降低风险的优先级。依据指定的风险参数，决定每个风险相对的优先级，应使用清楚的准则来决定风险的优先级。排定优先级的目的是为了确定降低风险的资源能用在最有效的范围，使其对项目有最大的正面影响。 SG 3 降低风险适当地处理及降低风险，以减少对目标达成的不力因素。处理风险的步骤，包括制订风险处理方案、监控风险，以及超过所定义的阈值时，执行风险处理活动。对于选定的风险，应制订和执行风险降低计划，以主动减少风险发生的潜在冲击。除试图降低风险，亦应包括紧急应变计划(contingency plan)，以处理可能发生的风险冲击。在风险管理策略中，定义启动风险处理活动的风险参数。 SP 制订风险降低计划根据风险管理策略所定义的对项目影响最大的风险，制订风险降低计划。针对每个关键性的风险，制订可选择的活动、替代方案、返回点，并对每个风险皆有建议的行动过程，是风险降低计划的关键组件。特定风险的风险降低计划包括规避、降低及控制风险发生可能性的技术和方法，或风险发生时遭受的损失程度(有时称作「紧急应变计划」)，或上述两者。监控风险，当风险超过设定的阈值时，展开风险降低计划，以使受冲击的部分回归到可接受的风险等级。只有风险结果评定为高或无法接受时，才对该风险制订风险降低计划和紧急应变计划，其它的风险可能仅是接受，并简单地监控。风险处理方案，通常包括下列各种备选方案： • 风险规避：改变或降低需求，但仍符合使用者需要 • 风险控制：采取主动的步骤，以降低风险 • 风险移转：重新配置设计需求，以降低风险 • 风险监控：就指定之风险参数的变化，观察并定期重新评估风险 • 风险接受：对风险有认知，但不采取任何动作通常，特别针对「高」风险，应产生一种以上的风险处理方法。在中断营运持续力的案例中，风险管理的处理方法举例如下： • 保留资源以因应中断事件 • 适当可使用的支持设备清单 • 主要的备援人员 • 紧急应变系统的测试计划及结果 • 紧急事件的后续程序 • 紧急事件中，主要联络人及信息资源的散播清单在很多情况中，风险会被接受或被观察。若风险被判定太低而不需正式的风险降低计划，或当似乎没有降低风险的可行方法，则通常接受该风险。假如接受一个风险，就必须记录决定的理由。在绩效、时间或风险曝光程度(可能性和结果的组合)的阈值能客观定义、验证及记录之后，风险才可观察。必要时才能启动风险降低计划，或紧急应变计划。应尽早且充分地考虑技术的展示、模型、仿真及原型，作为风险降低计划的一部分。典型的工作产品 1. 每个已识别风险之处理方案的纪录 2. 风险降低计划 3. 紧急应变计划 4. 负责追踪及解决每个风险的人员清单子实践 1. 决定风险的等级及阈值，以定义风险在什么情况下是变成无法接受，并启动风险降低计划或紧急应变计划。风险等级(利用风险模型导出)是一种度量，由达成目标的不确定性和无法达成目标的结果所组成。必须清楚了解并定义风险程度和阈值，因风险程度和阈值会限定规划的或可接受的绩效范围，以提供方法来了解风险。为了确保适当的排序(根据严重性)和相关管理响应，正确的风险分类是必要的。可设定多重阈值，以启动不同等级的管理响应。通常在设定执行紧急应变计划阈值之前，会先设定好执行风险降低计划的阈值。 2. 识别负责处理每个风险的个人或团队。 3. 决定实施每个风险之风险降低计划的成本效益比。应检验风险降低活动产生的效益相对于将耗用的资源。就如同其它的设计活动，需要开发替代计划，并评价每个替代计划的成本与效益，而后选择最佳的计划来实行。有时，风险可能很重大且效益很小，但仍需降低风险，以减少无法接受之结果的发生机率。 4. 开发项目整体的风险降低计划，以协调个别的风险降低计划和紧急应变计划。完整的风险降低计划可能无法负担。所以，应作取舍分析，以对风险降低计划排定优先级。 5. 针对选取的关键风险，制订当其发生时的紧急应变计划。需要时，在风险变成问题前，制订和实施风险降低计划，以主动降低风险。尽管有最佳的努力，有些风险可能无法避免且成为冲击项目的问题。对关键的风险制订紧急应变计划，描述项目在冲击发生时，可能采取的行动。定义处理风险的预先动作计划的意图，不是降低风险(风险降低计划)，就是响应风险(紧急应变计划)，但无论那一种，都是管理风险。有些风险管理文献可能把紧急应变计划当作风险降低计划的同义词或一部分，这些计划也可能与风险处理计划或风险行动计划一起说明。 SP 执行风险降低计划定期监控每一风险的状况，并适当地执行风险降低计划。为了在工作期间有效控制和管理风险，需遵守事先安排的计划，定期监控风险及其状况，以及风险处理活动的结果。风险管理策略定义风险状况应再评价的间隔。这个活动可能导致发现新风险，或可能需要重新规划或重新评价新风险的处理方案。在任一情况，风险可接受的阈值应与风险状况比较，以决定是否需要执行风险降低计划。典型的工作产品 1. 更新后的风险状况清单 2. 更新后的风险可能性、结果及阈值的评价 3. 更新后的风险处理方案清单 4. 更新后的风险处理行动清单 5. 风险降低计划子实践 1. 监控风险状况。风险降低计划启动后，仍然要监控风险。评价阈值以检查是否要执行紧急应变计划。应使用定期监控的机制。 2. 提供方法，以追踪未完成的风险处理行动项目，一直到关闭。有关追踪行动项目，请参考项目监控过程域，以获得更多信息。 3. 当监控的风险超过定义的阈值时，引用选定的风险处理方案。风险处理经常只对判断为「高等」或「中等」的风险。对于已知风险，风险处理策略可能包括避免、降低及控制风险可能性的技术和方法，或控制风险(预期的事件或情况)发生时，遭受损失程度的技术和方法，或上述两者。因此，风险处理包括风险降低计划和紧急应变计划。开发风险处理的技术，以避免、降低及控制不利项目目标的冲击，并根据可能的冲击，提出可接受的结果。处理风险的活动，需要适当的资源并安排于计划与基线进度表之中。重新规划的工作需要密切考虑前后相接的或有相依性之工作启动或活动的影响。有关修订项目计划，请参考项目监控过程域，以获得更多信息。 4. 针对每个风险处理活动，建立进度或某段期间的绩效，包括起始日期和预计的完成日期。 5. 对每个计划提供持续性的资源承诺，以使风险处理活动成功的执行。 6. 收集风险处理活动的绩效度量。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施风险管理过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行风险管理过程。详细说明：本方针建立组织对风险管理策略的期望，并识别、分析及降低风险。 GP 规划过程建立并维护用来执行风险管理过程的计划。详细说明：项目计划通常包含(或参考)执行风险管理过程的计划。项目计划在项目策划过程域中说明。本通用实践所需要的计划，涵盖此过程域所有特定实践完整的规划，特别地，提供降低风险的整体处理方法，但对特定工作项目，是与降低风险计划(包括紧急应变计划)有所区分的。相反的，实践所需要的风险降低计划，描述更确定的项目，例如：驱动风险处理活动的风险程度。 GP 提供资源提供充分的资源，以执行风险管理过程、开发工作产品及提供过程服务。详细说明：提供的资源，包括下列工具： • 风险管理数据库 • 风险降低工具 • 原型制作工具 • 模块化和模拟 GP 指定责任分配风险管理过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持风险管理过程。详细说明：培训主题，举例如下： • 风险管理观念和活动(例如：风险识别、评估、监控、降低) • 风险降低的度量选择 GP 管理配置将指定的风险管理过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 风险管理策略 • 已识别的风险项目 • 风险降低计划 GP 识别并纳入相关的干系人依计划识别并纳入风险管理过程相关干系人。详细说明：干系人参与的活动，举例如下： • 建立可自由及开放讨论风险的合作环境 • 审查风险管理策略和风险降低计划 • 参与风险识别、分析及降低风险活动 • 沟通及报告风险管理状况 GP 监控过程依本过程的执行计划，监控风险管理过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 已识别、管理、追踪及控制的风险数目 • 对每个评价的风险，其风险曝光程度和风险曝光程度的改变，且当作一个管理保留的摘要百分比 • 为风险降低计划的变更活动(例如：过程、进度、资金) • 非预期风险的发生 • 风险分类的变动性 • 比较降低风险之预估和实际的投入和冲击 • 风险分析活动的进度 • 特定降低行动的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估风险管理过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立并维护风险管理策略 • 识别并分析风险 • 降低风险审查的工作产品，举例如下： • 风险管理策略 • 风险降低计划 GP 与高层管理人员审查各状况与高层管理人员审查风险管理过程的活动、状况及结果，并解决问题。详细说明：以定期和事件导向为基础，与适当的管理阶层审查项目状况，以便发现潜在的项目风险，并提供适当的纠正措施。基本上，这些审查包括最严重风险和主要风险的参数摘要(例如：风险的可能性和结果)，以及降低风险的投入状况。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义风险管理过程的说明。 GP 收集改进信息收集由规划和执行风险管理过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果及改进信息，举例如下： • 风险参数 • 风险类别 • 风险状态报告仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护风险管理过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定风险管理过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保风险管理过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正风险管理过程之缺陷与其它问题的根本原因。供应商协议管理（SAM 2级）成熟度第二级的项目管理过程域目的供应商协议管理(Supplier Agreement Management, SAM)的目的，在管理供应商产品的取得。简介供应商协议管理过程域，包含下列各项活动： • 决定待取得产品的取得方式 • 选择供应商 • 建立并维护供应商协议 • 执行供应商协议 • 监督选择供应商过程 • 评估选择供应商工作产品 • 接受交付的取得产品 • 移交已取得产品给项目本过程域主要说明取得将交付给项目客户的产品和产品组件。在所有过程域中，当使用产品及产品组件这样的专有名词时，也意指包含服务及其组件的意思。可能由项目取得的产品及产品组件，举例如下： • 子系统(例：飞机的导航系统) • 软件 • 硬件 • 文档(例：安装、操作者与使用者手册) • 零件及材料(例：仪表、开关、轮子、钢铁及原料) 为减低项目风险，本过程域也可适用于取得不交付给客户的产品及产品组件，而是用来开发及维护产品或服务（举例：开发工具及测试环境）。典型地，项目取得的产品，决定于产品规划及开发的早期阶段。技术解决过程域提供实践，以决定可从供应商取得的产品及产品组件。本过程域不直接适用于供应商集成到项目团队的约定，以及使用者与产品开发者（例：集成团队）相同的管理过程和报告。这些情形通常是由其它过程或功能(可能是项目的外部功能)来处理。不过，本过程域的一些特定实践可用于管理这类供应商的正式协议。根据经营的需要，供应商可能有多种型态，包括内部的供应商(亦即是组织内部，项目之外的供应商)、制造与研发的供应商，以及商业化的供应商等。有关「供应商」的定义，请参见词汇。建立正式协议以管理组织与供应商的关系。正式协议是指一个组织（代表项目）与供应商间的任何法律协议，它可能是一份合同书、授权／许可、服务水平协议，或者是协议备忘录。根据本正式协议（意即是供应商协议），供应商交付产品给项目。相关过程域有关监控项目及采取纠正措施，请参考项目监控过程域，以获得更多信息。有关如何定义需求，请参考需求开发过程域，以获得更多信息。有关管理需求，包括从供应商取得之产品的需求追溯，请参考需求管理过程域，以获得更多信息。有关如何决定哪些产品与产品组件可由供应商处取得，请参考技术解决方案过程域，以获得更多信息。特定目标及实践摘要 SG 1 建立供应商协议 SP 决定取得方式 SP 选择供应商 SP 建立供应商协议 SG 2 满足供应商协议 SP 执行供应商协议 SP 监督选定的供应商过程 SP 评估选定的供应商的工作产品 SP 接受取得的产品 SP 移交产品各目标的特定实践 SG 1 建立供应商协议建立并维护与供应商的协议。 SP 决定取得方式决定欲取得的每一个产品或产品组件的取得方式。有关如何识别须取得哪些产品和产品组件，请参考技术解决方案过程域，以获得更多信息。有许多取得方式可供项目使用，以取得产品和产品组件。取得方式，举例如下： • 采购现成品（off-the-shelf COTS） • 通过合同的协议得到产品 • 由内部供应商处得到产品 • 由客户处得到产品 • 上述各种方式的组合（., contracting for a modification to a COTS product or having another part of the business enterprise codevelop products with an external supplier）通过合同修改现成品或通过外部供应商与企业内其它部门共同开发产品需要现成品时，须关切产品的评估及选择，对项目来说，供应商可能也是关键。选择决策的思考要件，包含专利权问题及产品的可供应性。典型的工作产品 1. 产品和产品组件的取得方式清单 SP 选择供应商评估供应商满足项目指定需求与已建立准则的能力，选择供应商。有关选择供应商的正式评估方法，请参考决策分析与解决方案过程域，以获得更多信息。有关指定的需求，请参考需求管理过程域，以获得更多信息。应建立准则，以反映项目成败的重要因素。重要因素，举例如下： • 供应商的所在地 • 供应商类似工作经验及执行纪录 • 工程能力 • 可执行工作的成员和设施 • 相似应用的先前经验典型的工作产品 1. 市场研究 2. 备选的供应商名册 3. 优先选择的供应商名册 4. 趋势研究或评估准则的其它纪录、备选供应商的优缺点分析，以及选商的理由 5. 邀商文档和需求子实践 1. 建立并记录评估潜在供应商的评估准则。 2. 识别潜在的供应商，并分发邀商文档和需求。执行本活动的事前进行的方法是，做市场研究来识别取得备选产品的潜在来源，备选产品包括供应商的客制化产品及现成品。有关过程及技术改进的来源，以及如何试行及评估此改进的案例，请参考组织创新及部署过程域，以获得更多信息。 3. 依据评估准则，评估厂商建议书。 4. 评估各备选供应商的相关风险。有关评估项目风险，请参考风险管理过程域，以获得更多信息。 5. 评估备选供应商执行工作的能力。评估备选供应商执行工作之能力的方法，举例如下： • 评估类似应用的经验 • 评估类似工作的执行状况 • 评估供应商的管理能力 • 评估供应商的能力 • 评估可执行工作的成员 • 评估可用设施和资源 • 评估项目与备选供应商共同工作的能力 • 评估在项目计划及承诺中，备选现成品的冲击当评估现成品时，应考虑下列事项： • 现成品的成本 • 将现成品并入项目的成本及工作量 • 安全性需求 • 未来产品发布的利益及冲突未来现成产品的发布可能提供附加功能，以支持项目已规划或已期望的加强功能，但也有可能的结果是供应商无法持续支持目前版本。 6. 选择供应商。 SP 建立供应商协议建立并维护供应商间的正式协议。 IPPD 补充当组成集成团队时，须与供应商协调团队成员资格，并纳入协议内容。协议须识别任何集成性的决策制定、报告的需求(经营面及技术面)，以及需要供应商参与的替代方案研究。采购者必须妥善安排供应商的工作量，以支持IPPD 的工作。正式协议是指一个组织(代表项目)与其供应商间的任何法律协议，因此，它可能是一份合同书、授权/许可、服务水平协议或协议备忘录。如果审查、监督、评估、验收测试活动的执行，对于取得或已取得的产品来说是适当的话，协议内容就应该指定。典型的工作产品 1. 工作说明书 2. 合同 3. 协议备忘录 4. 许可协议书子实践 1. 必要时，修订供应商须履行的需求(例：产品需求、服务水平需求)，以反映供应商与项目的协商结果。有关修订需求，请参考需求开发过程域，以获得更多信息。有关需求变更的管理，请参考需求管理过程域，以获得更多的信息。 2. 记录项目将提供给供应商的内容。包含： • 项目供给的设施 • 文档 • 服务 3. 记录供应商协议。供应商协议应包含：工作说明书、规格、协议条款及条件、交付清单、进度表、预算及已定义的验收过程。子实践通常包含： • 建立工作说明书、规格、协议条款及条件、交付清单、进度表、预算及验收过程 • 识别项目与供应商中，被授权负责变更供应商协议的人员 • 识别需求如何变更，与如何决定、沟通及描述供应商协议的变更 • 识别须遵循的标准和程序 • 识别项目和供应商间的关键依存关系 • 识别项目监督供应商的形式及深度、程序，以及用以监督供应商绩效的评估准则，包括监督过程的选择及评估工作产品 • 识别供应商审查的方式 • 识别供应商对取得产品之持续维护与支持的责任 • 识别取得产品的保证、所有权及使用权 • 识别验收准则在某些选择现成品的案例中，除了产品授权，还可要求供应商协议。与现成品供应商的协议，包含的范围举例如下： • 大量采购的折扣 • 在许可协议下，相关干系人的范围，包括项目供应商、团队成员，以及项目客户 • 未来的加强计划 • 现场支持，例如询问及问题报告的响应 • 目前不在产品上的附加功能 • 维护支持，包括产品丧失一般可用性的支持 4. 周期性审查供应商协议，以确保正确反映与供应商及目前风险的项目关系，以及市场条件。 5. 在履行协议或任何变更前，确保与协议有关的各方人士都已了解并同意所有需求。 6. 必要时，修订供应商协议，以反映供应商过程或工作产品的变更。 7. 必要时，修订项目计划和承诺事项，包括项目过程或工作产品的变更，以反映供应商协议内容。有关修订项目计划，请参考项目监控过程域，以获得更多信息。 SG 2 满足供应商协议项目与供应商的协议必须满足双方。 SP 执行供应商协议与供应商共同执行供应商协议所指定的各项活动。有关监控项目及采取纠正措施，请参考项目监控过程域，以获得更多信息。典型的工作产品 1. 供应商进度报告和绩效度量资料 2. 供应商审查文档和报告 3. 追踪行动项目直到关闭 4. 产品文档和文档交付的佐证文档子实践 1. 据供应商协议所定义的事项，监督其进度和工作情况，包括进度、工作量、成本及技术的绩效。 2. 供应商协议所指定的事项，进行供应商审查。有关执行审查，请参考项目监控过程域，以获得更多信息。审查有正式与非正式审查两种，包含下列步骤： • 审查准备 • 确保相关的干系人参加 • 执行审查 • 识别、记录及追踪所有行动项目直到关闭 • 准备审查摘要报告，并分发给相关的干系人 3. 供应商协议所指定的事项，进行供应商技术审查。技术审查通常包含： • 适当提供清楚的项目客户和最终使用者之期望和需要给供应商 • 审查供应商的技术活动，并验证供应商对需求的诠释和实现是否符合项目的诠释 • 确保已满足技术的承诺，且技术的问题均及时沟通和解决 • 取得供应商产品的技术信息 • 提供适当技术信息和支持给供应商 4. 供应商协议所指定的事项，与供应商进行管理审查。管理审查通常包含： • 审查关键性的依存关系 • 审查与供应商有关的项目风险 • 审查进度表及预算技术及管理审查可以一起进行。 5. 由审查结果，改进供应商的绩效，以建立和培养可长期合作的优良供应商。 6. 监督与供应商有关的风险，必要时采取纠正措施。有关监控项目风险，请参考项目监控过程域，以获得更多信息。 SP 监督选定的供应商过程选择、监督及分析供应商所使用的过程。在项目和供应商各自负责一些必须紧密合作之过程情况下，监督这些过程将有助于避免接口的问题。所选来进行监督的过程必须考虑供应商过程对项目的冲击。大型项目中，若有开发关键组件的重要子合同，监督主要过程是一定要做的。大多数的供应商协议针对尚未开发的产品、或者对较小及不关键组件的产品时，可能决定不选择监督过程。这两个极端中，应考虑到选择被监督的过程的整体风险。如未谨慎的执行监督，可能会出现二种极端状况，一种是具侵略性且繁重，另一种是没有参考且无效。所以，应有充分的监督，以尽早发现可能会影响供应商履约能力的问题。监督执行时若没有足够的关心，极端表现是侵略性及烦人的，另一种极端表现是无法获得信息及无效率的。尽可能早一点有足够监督能力，来发觉问题，这会影响供应商的能力，是否满足供应商协议的需求。对所选择过程的分析活动，包括取得所监督的供应商过程的数据，并进行分析，以决定是否存在严重的问题。典型的工作产品 1. 已选定要被监督的过程或不选择的理由清单 2. 活动报告 3. 绩效报告 4. 绩效曲线 5. 差异报告子实践 1. 识别对项目的成功具关键性的供应商过程 2. 监督已选择的供应商过程，以符合协议的需求 3. 分析已选定的供应商过程的监督结果，以尽早发现可能会影响供应商履约能力的问题。趋势分析可使用内部和外部数据。有关记录验证与分析的结果，请参考验证过程域，以获得更多信息。有关采取纠正措施，请参考项目监控过程域，以获得更多信息。 SP 评估所选定的供应商工作产品针对客户化产品的供应商，选择及评估工作产品。本实践的使用范围，限定于提供客户化产品项目的供应商，特别是因其复杂度或关键性，导致程序上的风险。本特定实践的目的，在于评估供应商所生产的工作产品，以尽早发现会影响供应商履约能力的问题。经选定用以进行评估的工作产品，应包括可尽早洞察质量问题的关键性产品、产品组件及工作产品。典型的工作产品 1. 选定用以监督的工作产品清单或不选定理由清单 2. 活动报告 3. 差异报告子实践 1. 识别对项目的成功具关键性的工作产品，以尽早发现问题。对项目成功具关键性的工作产品，举例如下： • 需求 • 分析 • 架构 • 文档 2. 评估已选择工作产品评估工作产品，确保以下事项： • 衍生需求是可追溯至较更高层的需求 • 架构是可行性的，并满足产品未来的成长及再使用的需要 • 产品的操作和支持文档是足够的 • 工作产品之间是一致的 • 产品及产品组件（例，客制的、现成的及客户提供的产品）可以被集成 3. 针对评估所识别的缺点，决定行动方案，并记录之。有关采取纠正措施，请参考项目监控过程域，以获得更多信息。 SP 接受取得的产品在接受取得的产品前，确保其已满足供应商协议。根据供应商协议所指定的事项，在接受产品之前，须完成验收审查和测试，以及完成配置审计。典型的工作产品 1. 验收测试程序 2. 验收测试报告 3. 差异报告或纠正计划子实践 1. 定义验收程序。 2. 验收审查或测试前，先与相关的干系人审查验收程序，并取得他们的同意。 3. 验证所取得的产品，满足其需求。有关验证产品，请参考验证过程域，以获得更多信息。 4. 确认所取得的产品，满足其非技术性的承诺。可能包含确认适当的授权/许可、保证书、所有权、使用权，以及支持或维护协议，均已妥当安排，且所有支持物资均已收到。 5. 记录验收审查或测试的结果。 6. 未通过验收审查或测试的工作产品，建立行动方案，并取得供应商的同意。 7. 识别、记录及追踪所有行动项目直到关闭。有关追踪行动项目，请参考项目监控过程域，以获得更多信息。 SP 移交产品移交从供应商取得的产品给项目。在取得的产品移交到项目以供集成之前，须执行适当的规划和评估，以确保能顺利移交。有关集成取得的产品，请参考产品集成过程域，以获得更多信息。典型的工作产品 1. 移交计划 2. 培训报告 3. 支持和维护计划子实践 1. 保有适当设施以接收、存储、使用及维护所取得的产品。 2. 确保与接收、存储、使用及维护所取得产品有关的人员皆获得适当培训。 3. 确保在执行所取得产品的存储、配送及使用时，皆依据供应商协议或授权/许可所指定的条款及限制的规定。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施供应商管理过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。 GP 建立组织方针建立并维护组织的方针，以规划和执行供应商协议管理过程。详细说明：本方针建立组织对下列活动的期望：建立、维护及满足供应商协议。 GP 规划过程建立并维护用来执行供应商协议管理过程的计划。详细说明：本计划有关执行供应商协议管理过程，可以是一部分(或参照)项目计划，而项目计划在项目策划过程域中说明。本计划的某些部分是由项目以外的独立团队执行，如合同管理。 GP 提供资源提供充分的资源，以执行供应商协议管理过程、开发工作产品及提供过程服务。详细说明：可用于本过程域的资源(工具)，举例如下： • 优先的供应商清单 • 需求追踪工具 • 项目管理及进度工具分配责任 GP 分配责任分配供应商协议管理过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持供应商协议管理过程。详细说明：培训主题，举例如下： • 与供应商协商及共同工作有关的规定及经营实务 • 取得的规划及准备 • 现成品的取得 • 供应商的评选 • 协调及冲突解决 • 供应商管理 • 取得产品的测试及移交 • 取得产品的接收、存储、使用及维护 GP 管理配置将指定的供应商协议管理过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 工作说明书 • 供应商协议 • 协议备忘录 • 子合同 • 优先选择的供应商名册 GP 识别并纳入相关的干系人依计划识别并纳入供应商协议管理过程相关干系人。详细说明：干系人参与的活动，举例如下： • 建立评估潜在供应商的评估准则 • 审查潜在的供应商 • 建立供应商协议 • 与供应商解决争论的问题 • 审查供应商的工作绩效 GP 监控过程依本过程的执行计划，监控供应商协议管理过程，并采取适当的纠正措施。详细说明：用于监控的度量，举例如下： • 供应商需求的变更次数 • 供应商协议在成本和进度的差异 • 供应商工作产品评估已完成（规划的相对于实际完成的）数量 • 供应商过程评估已完成（规划的相对于实际完成的）数量 • 选择供应商及建立协议的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估供应商协议管理过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 建立并维护供应商协议 • 满足供应商协议审查的工作产品，举例如下： • 供应商协议管理计划 • 供应商协议 GP 与高层管理人员审查各状况与高层管理人员审查供应商协议管理过程的活动、状况及结果，并解决问题。仅适用于阶段式表述 GG 3 的目标及其实践，不是成熟度第二级评等的必要项目，但它们是成熟度第三级和更高等级评等的必要组件。仅适用于连续式表述式成熟度第3-5 级 GG 3 制度化已定义过程将过程制度化为已定义过程。 GP 建立已定义过程建立并维护已定义过程与产品质量保证过程的说明。 GP 收集改进信息收集由规划和执行供应商协议管理过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息的范例包括下列： • 供应商审查的结果 • 用于选商的交易研究 • 供应商协议的改版历史记录 • 供应商绩效报告 • 供应商工作产品及过程评估的结果仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护供应商协议管理过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定供应商协议管理过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保供应商协议管理过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正供应商协议管理过程之缺陷与其它问题的根本原因。技术解决方案（TS 3级）成熟度第三级的工程类过程域目的技术解决方案(Technical Solution, TS)的目的，为设计、开发及实现需求的解决方案。解决方案、设计结果及实现成品包括产品、产品组件，以及与产品相关生命周期的单一过程或适当组合的过程。简介技术解决方案过程域适用于产品架构的任何等级，且适用于所有产品、产品组件、产品相关生命周期过程。整个过程域中，产品及产品组件的意涵也包括服务及其组件。本过程域专注于下列事项： • 评估与选择解决方案(有时称为「设计方案)、「设计概念」或「初步设计」」，满足适当的配置需求。 • 对选定的解决方案开发详细设计(详细到包括制造、程序制作，或实现设计为产品或产品组件所需的信息)。 • 实现设计成产品或产品组件。基本上，这些活动相互支持。某种程度的设计，有时相当详细，可能需要选择解决方案。原型或试行可用来作为取得足够知识，以开发技术相关数据或一组完整需求的方法。技术解决方案的特定实践，不仅适用于产品及产品组件，也适用于产品相关生命周期的过程。产品相关生命周期过程的开发，与产品或产品组件的开发有关。这种开发包括选择与定义现有过程(包含标准过程)以供使用与开发新过程。技术解决方案过程域相关的过程，接受来自需求管理过程的产品与产品组件需求。需求管理源自于需求开发过程的需求，将需求纳入适当的配置管理，并维护他们对先前需求的追溯性。就维护或运维的项目而言，需要维护活动或重新设计的需求可能由使用者的需要或产品组件潜伏的瑕疵所驱动。新需求可能来自于操作环境的变更，这些需求在产品验证的时候，通过比较实际绩效与指定绩效而识别出不被接受的绩效落差，可以被发掘出来。技术解决方案过程域相关的过程应用以执行维护或运维的设计工作。相关过程域有关需求配置、操作观念的建立及接口需求定义，请参考需求开发过程域，以获得更多信息。有关同行评审及对产品和产品组件是否满足需求之验证，请参考验证过程域，以获得更多信息。有关正式评估，请参考决策分析与解决方案过程域，以获得更多信息。有关管理需求，请参考需求管理过程域，以获得更多信息。需求管理过程域之特定实践执行时，与技术解决方案过程域的特定实践交互作用。有关改进组织的技术，请参考组织创新与部署过程域，以获得更多信息。特定目标及实践摘要 SG 1 选择产品组件解决方案 SP 开发备选解决方案及评选准则 SP 选择产品组件解决方案 SG 2 开发设计 SP 设计产品或产品组件 SP 建立技术相关数据 SP 使用准则设计接口 SP 执行自制、购买或复用分析 SG 3 实现产品设计 SP 实现设计 SP 建立产品支持文档各目标的特定实践 SG 1 选择产品组件解决方案从备选方案中，选择产品或产品组件解决方案。选择解决方案之前，应考量备选解决方案及其相关优点。建立在分析备选解决方案时所使用的关键需求、设计问题及限制条件。架构特性提供产品改进与演进的考量基础，并按相对成本、进度、绩效及风险，考虑是否采用现成品作为产品组件。现成品(COTS)可直接或修改后使用，有时候这种现成品须进行接口修改或对部分特性进行客制化，以符合产品需求。良好设计过程的指针之一，是在比较与评估各种备选解决方案后，才进行设计方案的选择。通常在设计选择时要处理架构、客制或采用现成品及产品组件模块化的决定。有些决策需要使用正式的评估过程。有关正式评估过程的使用，请参考决策分析与解决方案过程域，以获得更多信息。有时寻找解决方案，只需检查相同需求的备选实例，而不必涉及其下层产品组件的需求配置。在产品架构的底层(组件)即为一例。有些情况，有些方案已预先决定(例如：某特定方案已被直接指定，或是调查可供使用的产品组件，如现成品)。一般而言，解决方案是整套的。亦即，在定义产品组件的下一层时，一起建立每个组件的解决方案。备选方案不单是对同一需求的不同处理方式，也反映需求配置于组件，构成解决方案的不同思考。此处的目标是将整体的解决方案已优化，而非个别设计的优劣。因此，与需求开发过程域有密切互动，以支持产品需求暂时性的配置到各产品组件，直至选定解决方案并建立「最终」配置。产品组件解决方案是由备选解决方案所选出，而产品相关的生命周期过程就在这些产品组件解决方案之中。例如：制造、交付与支持过程就是产品相关的生命周期过程。 SP 开发备选解决方案及评选准则开发备选解决方案及评选准则。有关取得将需求配置到产品组件的备选解决方案，请参考需求开发过程域中，配置产品组件需求指定实践，以获得更多信息。有关建立用于决策的准则，请参考决策分析与解决方案过程域，以获得更多信息。 IPPD 补充选择备选解决方案的活动以及决策分析与替代方案研究的问题，都需要相关干系人的参与。这些干系人代表经营与技术功能，以及同步开发的产品与产品相关的生命周期过程 (例如：制造、支持、培训、验证及销毁)。以此方式，重要的问题在产品开发的早期就会浮现出来，并在这些问题变成高成本的错误之前就予以处理。需要识别及分析备选解决方案，以便就成本、进度及绩效，选择最均衡的解决方案。这些解决方案，是以已建议的产品架构为基础，来说明关键产品质量，以及扩展可行解决方案的设计空间。「开发与设计」特定目标的特定实践，提供更多关于开发可能的产品架构，使其能结合产品备选解决方案的信息。备选解决方案通常包含将备选需求配置到不同的产品组件。这些备选解决方案在产品架构中，也包括现成品解决方案的使用。与需求开发过程域相关的过程，也可用于提供更完整及健全的临时性需求配置到备选解决方案。备选解决方案涵盖可接受的成本、进度及绩效的范围。产品组件需求与设计问题、限制及准则一起用于开发备选解决方案。评选准则通常必须强调成本(例如：时间、人员、费用)、效益(例如：绩效、性能、有效性)及风险 (例如：技术、成本及进度)。详细的备选解决方案及评选准则的考量因素可包括下列： • 成本(开发、制造、购买、维护及支持) • 绩效 • 产品组件及产品相关生命周期过程的复杂度 • 对产品操作与使用条件、操作模型、环境及产品相关生命周期过程变异的坚固程度 • 产品扩充性与成长性 • 技术界限 • 建造方法及材料的敏感度 • 风险 • 需求与技术的演进 • 废弃 • 最终使用者与操作者的能力与界限 • 现成品的特性这里所列为最基本的考量因素。组织应开发与经营目标一致的备选方案筛选准则，以缩小备选清单。产品生命周期的成本期望能越小越好，但常非开发组织所能控制。客户可能不愿支付短期内较高成本，来换取最终会随着产品生命周期而降低成本的功能。在此情况下，至少应提醒客户，任何会降低生命周期成本的潜在机会。用来选择最终解决方案的准则须提供成本、效益及风险之间的平衡方法。典型的工作产品 1. 备选解决方案筛选准则 2. 新技术的评估报告 3. 备选解决方案 4. 最终选择的评选准则 5. 现成品的评估报告子实践 1. 识别筛选准则，以作为选择备选解决方案的考量因素 2. 识别现有技术与具竞争优势的新产品技术有关改进组织技术，请参考组织创新与部署过程域，以获得更多信息。项目应识别应用于现有产品及过程的技术，并在整个项目生命周期，监督目前使用技术的进展。项目应识别、选择、评估及投资新技术，以获得竞争优势。备选解决方案可包括新开发的技术，但亦可包括不同应用的成熟技术或维持现有方法。 3. 识别能满足需求的备选现成品有关评估供应商，请参考供应商管理过程域，以获得更多信息。这些需求包括下列： • 功能性、绩效、质量及可靠性 • 产品保证书的条款 • 风险 • 供应商对后续的产品维护及支持的责任 4. 产生备选方案 5. 取得每一备选解决方案的完整需求配置。 6. 开发选择最佳备选解决方案的准则。准则应包括产品生命周期设计问题的处理，例如：易于加入新技术或利用商用产品的能力等。例如：与开放式设计或开放架构概念有关的准则，都应列入评估。 SP 选择产品组件解决方案选择最能满足所建立准则的产品组件解决方案。有关建立产品组件的配置需求及产品组件间之接口需求，请参考需求开发过程域之「配置产品组件需求」及「识别接口需求」等特定实践，以获得更多信息。选择最能满足准则的产品组件，即建立需求配置给产品组件。低阶需求的产生来自于备选方案的选择，并用来开发产品组件的设计。主要以功能性的观点描述产品组件间的接口需求。文档中也包含产品对外活动及项目的物理接口描述。记录方案的描述及选择理由。在开发过程中，渐进开发技术相关资料为技术解决方案及开发详细设计，并实现设计。维护选择理由的纪录对后续的决策十分重要。这种纪录可使后续的干系人免于重做，也可在某些适用的应用环境下，提供对技术应用的深入见解。典型的工作产品 1. 产品组件选择决策及理由 2. 需求及产品组件间相关性的纪录 3. 解决方案、评估及理由的纪录子实践 1. 依据操作概念、操作方式及操作状态所建立的评选准则，评估各备选解决方案/解决方案组。针对每一个备选解决方案，开发产品操作及使用者互动的时序场景。 2. 依据备选解决方案的评估，评价评选准则之适用性，必要时，更新准则。 3. 识别并解决与备选技术方案及需求有关的问题。 4. 选择能满足已建立之评选准则的最佳解决方案。 5. 建立与所选择之备选方案关联的需求，此即为该产品组件的配置需求。 6. 识别将复用或取得的产品组件解决方案。有关取得产品及产品组件，请参考供应商协议管理过程域，以获得更多信息。 7. 建立并维护解决方案、评估及理由的文档。 SG 2 开发设计开发产品或产品组件的设计。产品或产品组件的设计，必须提出适当的内容，这不仅是为了实现，也是为了产品生命周期阶段，如修正、重新采购、维护、维持及安装。设计文档提供相关的干系人，对于设计的相互了解之参考，并在产品的开发与后续的生命周期阶段，支持未来设计上的改变。完整的设计描述，记录于技术相关数据中，该相关数据含有格式、安装、功能、接口、制造过程特性及其它参数等完整的特征与参数。已建立的组织或项目的设计标准(例如：检查清单、样板、对象架构)，形成达成高度定义与完整性之设计文档的基础。 IPPD 补充集成团队在设计产品的同时，也设计适当的产品相关的生命周期过程。适当时，这些过程可挑选自组织标准过程且不经修改。 SP 设计产品或产品组件开发产品或产品组件的设计。产品设计包含两阶段，在执行上可能相互重迭：初步设计与详细设计。初步设计建立产品功能与架构，包含产品组成区块、产品组件识别、系统状态与模型、主要的内部接口，以及外部产品接口。详细设计完整的定义产品组件的结构与功能。有关开发架构需求，请参考需求开发过程域，以获得更多信息。架构定义由需求开发过程的开发架构需求而来。这些需求代表产品成功的关键质量与效能。当建立详细产品设计时，架构定义结构化元素与协调的机制，使其直接满足需求或支持需求的达成。架构包含标准与设计规则，用来管理产品组件的开发与接口，就像能参考产品开发者的指导一样。「选择产品组件解决方案」特定目标的特定实践中，包含更多关于使用产品架构作为备选解决方案基础的信息。架构师设定并开发产品的模型，对产品组件所包含的软硬件做需求配置的判断。多个支持备选解决方案的架构，经开发与分析以找出针对架构需求的优缺点。操作概念与场景用来产生作为调修架构的使用案例与质量场景。它们也用来评估架构的合适性，以满足架构评估期间的期望目标，并在产品设计过程中定期地执行。有关开发用来作为架构评估的操作概念与场景，请参考需求开发过程域之「建立操作概念及场景」特定实践，以获得更多信息。定义架构的工作项目，举例如下： • 建立功能区块的结构化关联，与功能区块内的组件以及功能区块间的接口规则 • 建立软件主要的内部接口与外部接口 • 识别产品组件及其之间的接口 • 定义协调机制(例：针对软件及硬件) • 建立基础建设的能力与服务 • 开发产品组件样板或类别与框架 • 建立设计规则与授权，以制定决策 • 定义过程/执行绪的模型 • 定义软件到硬件的实际部署 • 识别主要复用的方法与资源在详细设计期间，完成产品架构的细节、完整定义产品组件，以及完整描述接口。产品组件的设计可能针对某些质量或效能特性而进行已优化。设计者可评估既有产品或现成品，以作为产品组件。当设计成熟时，追踪需求(该需求已指定给较低阶的产品组件)，以确保这些需求已满足。有关追踪产品组件需求，请参考需求管理过程域，以获得更多信息。软件工程适用详细设计专注于软件产品组件的开发。定义产品组件的内部结构、产生数据纲要、开发算法及建立启发法，使得产品组件功能满足所配置的需求。硬件工程适用详细设计专注于电子、机械、光电，及其它硬件产品及其组件的产品开发。开发电子概图及电路图、产生机械及光学封装模型，并开发制造及封装过程。典型的工作产品 1. 产品架构 2. 产品组件设计子实践 1. 建立并维护准则，以评估设计。除预期的效能外，用以建立设计准则的属性，举例如下： • 模块化 • 清晰 • 简单 • 可维护 • 可验证 • 可移植性 • 可靠性 • 准确性 • 安全 • 可扩充 • 可使用 2. 识别、开发或取得适合于产品的设计方法。有效的设计方法能具体表现大范围的活动、工具及描述的技术。方法是否有效，视情况而定。两家公司在他们所专长的产品上，或许都有非常有效的设计方法，但是这些方法在合作上也许就不那么有效。复杂度高的方法，对未经培训的设计者而言，就未必是有效的方法。方法是否有效，也要看它能提供设计者多少的帮助，以及其成本效益。例如：一个需要多年时间的原型设计，可能不适用于简单的产品组件，但在开发无前例可循、昂贵及复杂的产品时，却可能会是最佳选择。使用工具的方法是非常有效的，因工具可确保设计将包括所有必要实现产品组件设计的属性。例如：设计工具「知道」制造过程的能力，在设计的容忍误差中说明制造过程的差异。增进有效设计的技术与方法，举例如下： • 原型法 • 结构化模型 • 对象导向设计 • 精实系统分析 • 物理关联模型(E-R models) • 设计复用 • 设计样式 3. 确保设计遵循所应用的设计标准与准则。设计标准的范例，举例如下(部分或全部的「标准」可能是设计准则，特别是标准尚未建立时)： • 操作人员接口标准 • 测试脚本 • 安全标准 • 设计限制(例：电磁兼容性、讯号完整性及环境面) • 生产限制 • 设计的容忍范围 • 零件标准(如生产的废弃物与废品) 4. 确保设计遵循已配置的需求。必须考虑已识别的现成品组件。例如：将现有产品组件放入产品架构可能会修改需求与需求的配置。 5. 记录设计。 SP 建立技术相关数据建立并维护技术相关数据。技术相关数据提供开发者在开发产品或产品组件时，详细的描述。该数据在各种情况下，也提供采购的弹性。例如以绩效为主的合同或依设计图建造。设计结果记录于技术相关数据中。在初步设计期间产生技术相关数据，以记录架构定义。在整个产品生命周期中必须维护技术相关数据，以记录必要的产品设计细节。技术相关数据提供产品或产品组件的说明(包含未视为个别产品组件之产品相关生命周期过程)，以支持产品取得策略，或产品生命周期的实现、生产、工程及后勤支持阶段。这些说明包含必要的设计配置定义与程序，以确保产品或产品组件应有的效能。它包含所有可用的技术数据，例如：绘图、相关清单、规格、设计描述、设计数据库、标准、效能需求、提供的质量保证及组装细节。技术相关数据包含用来实现之已选定的备选解决方案。若该信息适合产品或产品组件的型态(例如：原料与制造需求，对软件服务或过程相关的产品组件可能没有参考)，技术相关数据应包含下列信息： • 产品架构描述 • 已配置的需求 • 产品组件描述 • 产品相关生命周期过程描述，如未描述于个别产品组件 • 关键产品特性 • 必要的物理特性与限制 • 界面需求 • 原料需求(原料清单与原料特性) • 建造及制造需求(针对原先的设备制造商与现场支持) • 用来确保达成需求的验证准则 • 整个产品生命周期中的使用条件(环境)和操作/使用场景、操作的方式与状态、支持、培训、制造、废弃及验证 • 决定的理由与特性(需求、需求配置及设计选择) 由于设计说明包含大量数据，且这些数据对产品组件成功的开发可能是关键，因此建议要建立组织数据与选择数据内容的准则。使用产品架构来组织数据与抽象化观点，使得感兴趣的问题或特性能以清晰与切题的方式呈现，是一个特别有用的方法。这些观点包含： • 客户 • 需求 • 环境 • 功能 • 逻辑 • 安全性 • 资料 • 状态/模型 • 结构 • 管理这些观点都记录在技术相关数据中。典型的工作产品 1. 技术相关数据子实践 1. 决定设计阶层数目及每一设计阶层文档的适当阶层。决定需要以文档记录与执行需求追溯之产品组件阶层的数目(例如：子系统、硬件配置项、电路板、计算机软件配置项、计算机软件产品组件、计算机软件单元)，对管理文档成本与支持集成及验证计划都非常重要。 2. 已配置的产品组件需求、架构及较高层的设计为基础，执行详细设计。 3. 记录设计数据于技术相关数据中。 4. 记录关键 (例如：对成本、进度或技术绩效有重要影响)决策或定义的理由。 5. 必要时修改技术相关资料。 SP 使用准则设计接口使用已建立的准则来设计产品组件接口。接口设计包含下列： • 起源 • 终点 • 软件的影响事件与数据特性 • 硬件的电子、机械与功能特性 • 沟通的服务渠道接口准则经常反映出详细的重要参数清单。必须定义这些参数，或最起码要进行调查，以确保其适用性。这些参数通常是某特定产品的特性(如软件、机械的、电子的、服务)，并常与安全、保密、耐久性及任务的关键特性有关。有关识别产品及产品组件接口需求，请参考需求开发过程域中，识别接口需求的特定实践，以获得更多信息。典型的工作产品 1. 接口设计规格 2. 接口控制文档 3. 接口规格准则 4. 所选之接口设计的理由子实践 1. 定义接口准则。这些准则可以是组织过程资产的一部分。有关建立并维护组织过程资产，请参考组织过程定义过程域，以获得更多信息。 2. 识别与其它产品组件相关的接口。 3. 识别与外部项目相关的接口。 4. 识别介于产品组件与产品相关生命周期过程的接口。举例来说，这接口可包括所制造的产品组件与制造过程中用于组装的配件间的接口。 5. 应用准则于界面设计的备选方案。有关识别准则与依据准则来选择备选方案，请参考决策分析与解决方案过程域，以获得更多信息。 6. 记录已选取的接口设计与理由。 SP 执行自制、购买或复用分析根据已建立的准则，评估产品组件是要开发、购买或复用。决定要取得哪些产品或产品组件，通常称为「自制或采购分析」，通常是以项目需求的分析为基础。自制或采购分析从项目早期的设计开始，在设计过程阶段持续进行，完成时，决定产品要自行开发、由外部取得或复用。有关决定产品或产品组件的需求，请参考需求开发过程域，以获得更多信息。有关管理需求，请参考需求管理过程域，以获得更多信息。影响自制或购买决策的因素包含如下： • 产品所提供的功能以及这些功能如何符合项目的需要 • 可用的项目资源与技术 • 内部自行开发与外购的成本比较 • 关键的交付日期与集成日期 • 策略联盟，包含高层的经营需求 • 可用产品的市场分析，包含现成品 • 可用产品的功能与质量 • 潜在供应商的技能与能力 • 对核心竞争力的影响 • 有关外购产品的授权、保证书、权责及界限 • 产品可用性 • 所有权问题 • 风险降低可使用正式评估方法以进行自制或购买的决策。有关定义准则及备选方案，以及执行正式评估，请参考决策分析与解决方案过程域，以获得更多信息。一如技术的渐进开发，选择开发或采购产品组件的理由也是一样。虽然复杂的开发工作量会使大家倾向于购买现成品，但生产力与工具的进步，却又会使大家抱持相反的看法。现成品的文档可能不够完整或正确，而且在将来未必会提供支持。一旦决定购买现成的产品组件，其需求就用以建立供应商协议。有时，所谓「现成品」在目前的市场也可能缺货。例如：某种型号的飞机或引擎等，它们并非真正的现成品，但随时可以制造。在某些情况，这类非开发项目的使用，是因为绩效上的特殊理由，还有其它产品特性上的限制。在这种情况下，需求与验收准则就必须包含在供应商协议中，并加以管理。在其它的状况下，现成品就如它们字面上的意思一样(如字处理软件)，供应商并没有需要被管理的协议。有关如何说明产品组件的取得，以便执行采购，请参考供应商协议管理过程域，以获得更多信息。典型的工作产品 1. 设计与产品组件复用的准则 2. 自制或采购分析 3. 选择现成品组件的指导子实践 1. 开发产品组件设计复用的准则。 2. 分析设计以决定产品组件要自行开发、复用或采购。 3. 当采购或选择非开发的项目(现成品、政府的成品及复用)时，分析维护所隐藏的代价。维护的含义，举例如下： • 与未来现成品的发布有兼容性 • 供应商变更的配置管理 • 非开发性项目的缺陷与其解决方案 • 非计划性的废置 SG 3 实现产品设计依照设计，实现产品组件及相关的支持文档。从「开发设计」特定目标的特定实践所建立的设计，实现产品组件。实现工作通常包括产品集成及终端使用者文档制作前，所需的产品组件单元测试。 SP 实现设计实现产品组件设计。一旦完成产品设计，接着就是将之实现为产品组件。实现的特性与产品组件的种类有关。产品阶层最高层设计的实现，包含下一级每个产品组件的规格。此活动包含配置、调修及验证每一产品组件。同时也涉及多样的产品组件开发工作间的协调。有关需求的配置与调修，请参考需求管理过程域，以获得更多信息。有关接口管理与产品及产品组件的集成，请参考产品集成过程域，以获得更多信息。实现的特性，举例如下： • 已撰写程序代码。 • 数据已文档化。 • 服务已文档化。 • 电子及机械零件已制造。 • 产品独特的制造过程已放入实际作业中。 • 过程已文档化。 • 设施已建造。 • 原料已生产(例如：一项产品特有的原料可能是一种石油、燃料油、润滑油，或是一种新的合金)。典型的工作产品 1. 已实现的设计子实践 1. 使用有效的方法实现产品组件。软件工程适用软件程序制作的方法，举例如下： •结构化程序设计 •对象导向程序设计 •自动化产生程序代码 •软件程序代码复用 •使用合适的设计模型硬件工程适用硬件制造方法，举例如下： •闸门等级组合 •电路版设计（位置及路线） •计算机辅助设计图 •事后设计模拟 •制造方法 2. 遵循适当的标准与准则。实现制作的标准，举例如下： • 程序语言标准(例：软件程序语言标准及硬件描述语言) • 绘图需求 • 标准零件清单 • 制造零件 • 软件组件的结构及阶层 • 过程及质量标准制作的准则，举例如下： • 模块化 • 明确 • 简单 • 可靠性 • 安全性 • 可维护性 3. 对选定的产品组件，执行同行评审。有关执行同行评审，请参考验证过程域，以获得更多信息。 4. 适当时对产品组件执行单元测试。请注意，单元测试不限于软件。单元测试涵盖个别硬件或软件单元或先前已集成的相关项目群组。有关验证方法与程序，以及关于验证工作产品是否依据所指定的要求，请参考验证过程域，以获得更多信息。软件工程适用单元测试的方法，举例如下： •叙述涵盖度测试 •分支涵盖度测试 •述词涵盖度测试 •路径涵盖度测试 •边界值测试 •特殊值测试硬件工程适用单元测试的方法，举例如下： •功能性测试 •辐射检查测试 •环境测试 5. 必要时修订产品组件。在实现阶段发生了未能于设计阶段预见的问题时，就是修订产品组件时机的范例之一。 SP 建立产品支持文档建立并维护产品使用文档。本特定实践开发并维护用于产品安装、操作及维护的相关文档。典型的工作产品 1. 终端使用者培训教材 2. 使用者手册 3. 操作手册 4. 维护手册 5. 在线求助子实践 1. 审查需求、设计、产品及测试结果，以确保影响安装、操作及维护等项文档的相关问题已被识别并解决。 2. 运用有效的方法，制作安装、操作及维护的文档。 3. 遵循适当的文档制作标准。文档制作的标准，举例如下： • 与指定的文字处理软件相容 • 可接受的字型 • 章节及分页的编码 • 与指定的文体手册一致 • 缩写的使用 • 安全分级的标示 • 国际化的需求 4. 在生命周期的初期阶段就制作安装、操作及维护等文档的初始版本，以供相关的干系人审查。 5. 执行安装、操作及维护等文档的同行评审。有关执行同行评审，请参考验证过程域，以取得更多信息。 6. 必要时修订安装、操作及维护文档。需要修订文档的时机，举例如下： • 需求变更 • 设计变更 • 产品变更 • 已识别的文档错误 • 识别出来预见的修改各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施基础实践实施技术解决过程的特定实践，以开发工作产品与提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行技术解决过程。详细说明：本方针建立组织的期望，以反复处理下列工作：选择产品组件解决方案、开发产品及产品组件之设计与实现产品组件设计。 GP 规划过程建立并维护用来执行技术解决过程的计划。详细说明：执行技术解决方案过程的计划可以是项目计划的一部分(或参考)，项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行技术解决过程、开发工作产品及提供过程服务。详细说明：需求的开发、设计及实现，可能要使用特殊设施。如有必要，应开发或购买在技术解决方案过程域各活动所需设施。提供的资源，举例如下： • 设计规格工具 • 仿真器及模型工具 • 原型工具 • 场景定义及管理工具 • 需求追踪工具 • 交互式文档制作工具 GP 分配责任分配技术解决过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持技术解决过程。详细说明：培训主题，举例如下： • 产品及产品组件应用领域 • 设计方法 • 接口设计 • 单元测试技术 • 标准(例如：产品、安全、人为因素、环境) GP 管理配置将指定的技术解决过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 产品、产品组件、过程、服务及接口设计 • 技术相关资料 • 接口设计文档 • 设计与产品组件复用的准则 • 已实现的设计(例如：软件程序代码、已装配的产品组件) • 使用者、安装、操作及维护文档 GP 识别并纳入相关的干系人依计划识别并纳入技术解决过程相关干系人。详细说明：在下列人员中考量相关的干系人：客户、最终使用者、开发者、制造者、测试人员、供应商、市场营销人员、维护人员、报废处理人员及其他可能影响或被产品及过程所影响的人。干系人参与的活动，举例如下： • 开发备选方案及评选准则 • 取得外部接口规格及设计说明之核可 • 开发技术相关资料 • 评价产品组件自制、采购、复用的备选方案 • 实现设计 GP 监控过程依本过程的执行计划，监控技术解决过程，并采取适当的纠正措施。详细说明：用于监控的度量及工作产品，举例如下： • 重做所花费的成本、进度及工作量 • 在产品及产品组件设计所涉及的需求比率 • 产品、产品组件、接口及文档的规模大小与复杂度 • 技术解决方案之工作产品的缺陷密度 • 设计活动的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估技术解决过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 选择产品组件解决方案 • 开发产品及产品组件设计 • 实现产品组件设计审查的工作产品，举例如下： • 技术相关资料 • 产品、产品组件及接口设计 • 已实现的设计(如：软件程序代码、装配好的产品组件) • 使用者、安装、操作及维护文档 GP 与高层管理人员审查各状况与高层管理人员审查技术解决过程的活动、状况及结果，并解决问题。仅适用连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义技术解决过程的说明。 GP 收集改进信息收集由规划和执行技术解决过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息，举例如下： • 制造、购买或复用的分析结果 • 设计缺陷密度 • 应用新方法及工具的结果仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护技术解决过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定技术解决过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保技术解决过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正技术解决过程之缺陷与其它问题的根本原因。确认（VAL 3级）成熟度第三级的工程类过程域目的确认(Validation, VAL)的目的，在于展示置于预期环境中的产品或产品组件，可满足其预期的使用需求。简介所有的产品均可于其任何的预期环境中(例如：操作、培训、制造、维护及支持服务)执行确认活动。可用于工作产品的确认方法，亦能使用于产品及产品组件上。(整个过程域中，产品及产品组件的含义也包括服务及其组件) 选择工作产品（例如：需求、设计、原型）的基础在于，何种最佳指针能衡量产品及产品组件可满足使用者需要的程度，因此在整个产品生命周期，可早点并逐步执行确认。确认环境应能表达产品及产品组件的预期环境，同时亦能表达适用于工作产品确认活动的预期环境。确认证明所提供的产品符合预期的使用需求，而验证说明工作产品是否适当的反映了特定需求。换言之，验证确保「你把事做对了」，而确认确保「你做了对的事」。确认活动使用与验证类似的方法，例如：测试、分析、检查、展示或模拟。通常，确认活动包含了最终使用者及其它相关干系人。确认与验证活动经常同时执行，且可能使用部分相同的环境。有关验证活动，请参考验证过程域，以获得更多信息。若有可能，执行确认应将产品或产品组件置于其预期环境中运作。确认可能使用全部或部分的预期环境，使用工作产品执行确认，可让问题在项目生命周期中，通过相干系人的参与来及早发现。服务的确认活动可应用于工作产品，例如建议书、服务目录、工作说明书，以及服务纪录。当确认问题识别后，还需参考需求开发、技术解决方案或项目监控过程域的实践，并予解决。本过程域互为基础的特定实践说明如下： • 「选择需确认之的产品」特定实践识别需确认的产品或产品组件，与用来执行确认的方法。 • 「建立确认环境」特定实践决定用来执行确认的环境。 • 「建立确认程序与准则」特定实践依照选定的产品特性、使用者限制、确认方法与确认环境来开发确认程序与准则。 • 「执行确认」特定实践依照方法、程序及准则来执行确认。相关过程域有关需求确认，请参考需求开发过程域，以获得更多信息。有关将需求转成产品规格，以及识别影响产品或产品组件设计的确认问题识别后，实行纠正措施，请参考技术解决方案过程域，以获得更多信息。有关验证产品及产品组件合于需求，请参考验证过程域，以获得更多信息。特定目标及实践摘要 SG 1 确认准备 SP 选择需确认之产品 SP 建立确认环境 SP 建立确认程序与准则 SG 2 确认产品或产品组件 SP 执行确认 SP 分析确认结果各目标的特定实践 SG 1 确认准备执行确认准备。准备活动包含选择需确认的产品与产品组件，建立并维护确认环境、程序及准则。所选定的确认项目可能仅包含产品，也可能包含适当等级的产品组件，该产品组件可用以建立产品。任何产品或产品组件均可确认，包括替换、维护及培训产品等。准备执行产品或产品组件确认所需环境。环境可以购置或制订规格、设计及建造。确认环境可考虑产品集成及验证所使用的环境，以减低成本并提高效率或生产力。 SP 选择须确认之产品选择须确认的产品及产品组件，及每一产品及产品组件使用的确认方法。根据产品及产品组件与使用者需要的关系，来选择需确认之产品与产品组件。必须决定每个产品组件确认的范围(例如：操作行为、维护、培训及使用者接口)。可被确认的产品及产品组作，举例如下： • 产品及产品组件的需求与设计 • 产品及产品组件（例如：系统、硬件单元、软件、服务文档） • 使用者接口 • 使用者手册 • 培训教材 • 过程文档收集执行确认的需求与限制，然后依据确认方法展示出满足使用者需求的能力，来选择确认方法。确认方法不只定义产品确认的技术，也会主导设施、设备及环境的需求。这会导出由需求开发过程所处理的低层产品组件需求，也可能产生衍生需求，例如测试集与测试设备的接口需求。这些需求均传送到需求开发过程，以确保产品或产品组件能于可支持确认方法的环境中执行确认。确认方法应于项目生命周期初期即做选择，才能让干系人清楚的了解与同意。适当时，确认方法说明产品与产品组件的开发、维护、支持及培训。确认的方法，举例如下： • 与使用者讨论，可能在正式审查的场合 • 原型展示 • 功能性展示（例如：系统、硬件单元、软件、服务文档、使用者接口） • 培训教材的试行 • 由最终使用者及其它相关干系人执行产品及产品组件的测试 • 分析产品及产品组件（例如：模拟、塑模、使用者分析）硬件工程适用硬件确认活动包括，以塑模执行形式、定义及机械设计的功能的确认；热模；维护性及可靠性分析；时序展示；以及电子或机械产品组件的电子化设计仿真。典型的工作产品 1. 需确认的产品或产品组件清单 2. 每一产品或产品组件的确认方法 3. 每一产品或产品组件执行确认的需求 4. 每一产品或产品组件的确认限制子实践 1. 识别项目生命周期中，产品或产品组件确认的主要原则、特性及阶段。 2. 决定需确认何种类型的使用者需要(操作、维护、培训或支持)。产品或产品组件于其预期作业环境中，必须是可维护及可支持的。本特定实践说明可能伴随产品一起交付的维护、培训及支持服务。展示维护工具在实际产品上运作，是于作业环境中评估维护概念的范例之一。 3. 选择需确认的产品与产品组件。 4. 选择用以确认产品或产品组件的评估方法。 5. 与相关的干系人共同审查产品或产品组件的确认选择、限制及方法。 SP 建立确认环境建立并维护支持确认工作所需的环境。确认环境的需求可由下列产生：所选择的产品或产品组件、工作产品的类型(例如：设计、原型、最终版本)及确认的方法。这会产生采购或自行开发设备、软件或其它资源的需求。这些需求会提供给需求开发过程进行开发。确认环境可能包含现有资源的再利用，在此状况下，必须安排这些资源的运用。确认环境包含的要素类型举例如下： •测试工具与需确认产品的接口(例如：范围、电子设备、探针) •暂时嵌入的测试软件 •可将计算机内部数据移转出来，进一步分析或重新执行的记录工具 •以软件、电子设备或机械设备仿真过的子系统或组件 •仿真的接口系统(例如：为测试海军雷达的虚拟战舰) •实际接口系统(例如：为测试雷达与弹道追踪设施的飞行器) •设施及客户供应的产品 •操作及使用前述各要素的熟练人员 •专用于计算或网络测试的环境(例如：仿真作业的电讯网络测试环境，或由通讯主干、交换机以及为实际集成与确认所建立的系统，上述三者组成的设施) 及早选择需确认的产品或产品组件、确认需使用的工作产品及确认方法，可确保确认环境于需要时已经备妥。执行确认所需环境必须谨慎控制，以便复制、分析结果及再次确认有问题部分。典型的工作产品 1. 执行确认的环境子实践 1. 识别确认环境需求。 2. 识别客户供应品。 3. 识别可复用的项目。 4. 识别测试设备及工具。 5. 识别可复用及修改的确认资源。 6. 详细规划资源的可用性。 SP 建立确认程序与准则建立并维护确认程序与准则。定义确认程序与准则，以确保产品或产品组件置于其预期使用环境中，会符合预期使用需要。验收测试项目及程序可能合于确认程序的需要。确认程序与准则包含维护、培训及支持服务的测试及评估。确认准则的来源，举例如下： • 产品与产品组件需求 • 标准 • 顾客验收准则 • 环境绩效 • 绩效偏差的阈值典型的工作产品 1. 确认程序 2. 确认准则 3. 维护、培训及支持服务的测试及评估程序子实践 1. 审查产品需求，以确保影响产品或产品组件确认的问题已经识别并解决。 2. 记录用来确认选定的产品或产品组件的环境、操作场景、程序、输入、输出及准则。 3. 当确认环境设计渐趋成熟时，评价设计以识别确认问题。 SG 2 确认产品或产品组件确认产品或产品组件，已确保在预期作业环境中可适用。确认方法、程序及准则是用来确认所选择的产品与产品组件，以及相关的维护、培训及支持服务。此项确认是在适当的确认环境中进行。整个产品生命周期中，都要执行确认活动。 SP 执行确认对选定的产品及产品组件执行确认。为让使用者接受，产品或产品组件置于预期作业环境中，其工作表现必须完全符合预期要求。执行确认活动，并依据已建立的方法、程序及准则，收集结果数据。适当时，记录已执行的确认程序及执行时所发生的偏差。典型的工作产品 1. 确认报告 2. 确认结果 3. 确认对照表 4. 执行程序的纪录 5. 操作展示 SP 分析确认结果分析确认活动的结果。由确认测试、检查、展示或评估产生的数据，应予分析并与所定义的准则比对。分析报告应指出需求是否符合，如有偏差，报告需记载成功或失败的程度，并将可能失败的原因分类。所收集的测试、检查或审查结果，需和已建立的评估准测比较，以决定是否继续进行，或处理属于需求开发或技术解决方案过程域的需求或设计问题。分析报告或确认文档可能指出，测试结果不佳乃是确认程序或执行环境的问题。典型的工作产品 1. 确认缺陷报告 2. 确认问题 3. 程序变更请求子实践 1. 比较实际及预期结果。 2. 按已建立的确认准则识别问题。包括识别于预期作业环境下执行不佳的产品或产品组件，或识别确认方法、准则及(或)环境问题。 3. 分析确认缺陷数据。 4. 记录分析结果并识别问题。 5. 利用确认结果，将实际度量及绩效，与预期使用或操作需要进行比较。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施确认过程的特定实践，以开发工作产品并提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式过程域 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行确认过程。详细说明：本方针建立组织的期望，以选择需确认的产品及产品组件、选择确认方法、建立并维护确认程序、准则与环境，确保产品及产品组件于其预期操作环境下，能符合使用者的需要。 GP 规划过程建立并维护用来执行确认过程的计划。详细说明：执行确认过程的计划包含(或参考)在项目计划。项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行确认过程、开发工作产品及提供过程服务。详细说明：产品及产品组件的确认可能需要特殊设施。必要时，这些确认所需的设施可以自行开发或采购。其它提供的资源，举例如下： • 测试管理工具 • 测试项目产生器 • 测试涵盖分析器 • 仿真器 • 负载、压力及绩效工具 GP 分配责任分配确认过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持确认过程。详细说明：培训主题，举例如下： • 应用领域 • 确认原则、标准及方法 • 预期使用环境 GP 管理配置将指定的确认过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 需确认的产品或产品组件清单 • 确认方法、程序及准则 • 确认报告 GP 识别并纳入相关的干系人依计划识别并纳入确认过程相关干系人。详细说明：从下列人员中选择相关的干系人：客户、使用者、开发者、生产者、测试人员、供应者、营销人员、维护人员、销毁人员，以及其他可能被产品及过程影响或可能影响产品及过程的人。干系人参与的活动，举例如下： • 选择要确认的产品与产品组件 • 建立确认方法、程序及准则 • 审查产品及产品组件确认结果，并解决问题 • 与顾客或使用者解决问题客户或使用者的问题，当与下述基线需要项目有重大差异时，需予特别解决： • 合同或协议书的豁免权(什么、何时，以及哪些产品、服务或制造的产品) • 额外的深入研究、试验、测试或评估 • 合同或协议书可能的变更 GP 监控过程依本过程的执行计划，监控确认过程，并采取适当的纠正措施。详细说明：用以监控的度量及工作产品，举例如下： • 确认活动完成次数(计划及实际) • 确认问题报告趋势(例如：问题数及关闭数) • 确认问题报告处理时间(即每一问题报告悬而未决的时间) • 特定确认活动的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估确认过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 选择须确认的产品及产品组件 • 建立并维护确认方法、程序及准则 • 确认产品或产品组件审查的工作产品，举例如下： • 确认方法、程序及准则 GP 与高层管理人员审查各状况与高层管理人员审查过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义确认过程的说明。 GP 收集改进信息收集由规划和执行确认过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息，举例如下： • 产品组件原型 • 确认环境之可用时间的百分比 • 每个开发阶段中，通过确认所发现的产品缺陷数量 • 确认分析报告仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护确认过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定确认过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保确认过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正确认过程之缺陷与其它问题的根本原因。验证（VER 3级）成熟度第三级的工程类过程域目的验证(Verification, VER)的目的，在于确保选定的工作产品符合其指定的需求。简介验证过程域包括：验证准备、验证执行及纠正措施识别。验证包括产品及中间工作产品的验证，将其与选定的客户需求、产品需求及产品组件需求加以比较。整个过程域中，产品及产品组件的含义也包括服务及其组件。验证是一种渐进式过程因为它发生于产品及工作产品的开发过程中，从需求验证开始，经工作产品到最终完成产品的验证。互为基础的本过程域特定实践说明如下： • 「选择需验证的工作产品」特定实践识别需验证的工作产品、执行验证的方法及每一工作产品需满足的需求。 • 「建立验证环境」特定实践能决定执行验证所需使用的环境。 • 「建立验证程序及准则」特定实践开发与需验证的工作产品、需求、方法及验证环境特性配合的验证程序与准则。 • 「执行验证」特定实践依据可行的方法、程序及准则执行验证。验证工作产品可实质增加产品符合客户需求、产品需求及产品组件需求的可能性。验证及确认过程域相似，但强调不同重点。「确认」展现所提供的产品(或即将提供的产品)符合其预期使用需求，而「验证」强调工作产品是否适当反映其指定的需求。换句话说，验证确保「你把事做对了(you built it right) 」，确认确保「你做了对的事(you built the right thing)」。同行评审是验证的重要部分，也是经证实可以有效去除缺陷的机制。开发一套了解工作产品及产出过程的方法，以利防止缺陷并识别过程改进的有利机会。同行评审为有系统的检查工作产品，以识别缺陷及其它变更需求。此项工作是由产品制作人员的同行来执行。同行评审的方法，举例如下： • 检查 • 结构化逐步审查相关过程域有关产品或产品组件置于预期环境中，可符合其预期使用需求，请参考确认过程域，以获得更多信息。有关产生与开发客户、产品及产品组件需求，请参考需求开发过程域，以获得更多信息。有关需求管理，请参考需求管理过程域，以获得更多信息。特定目标及实践摘要 SG 1 验证准备 SP 选择待验证的工作产品 SP 建立验证环境 SP 建立验证程序及准则 SG 2 执行同行评审 SP 准备同行评审 SP 进行同行评审 SP 分析同行评审数据 SG 3 验证工作产品 SP 执行验证 SP 分析验证结果各目标的特定实践 SG 1 验证准备执行验证准备。事前准备可确保验证措施已植入于产品及产品组件需求、设计、开发计划及进度中。验证包含工作产品的选择、检查、测试、分析及展示。验证方法包括(但不限于)检查、同行评审、审计、逐步审查、分析、模拟、测试及展示。与同行评审有关的实践，如特定验证方法，都包含在特定目标2中。验证准备亦需对支持工具、测试设备及软件、仿真、原型系统及设施加以定义。 SP 选择待验证的工作产品选择需要确认的工作产品及每个工作产品使用的验证方法。工作产品选择的基线在于其对符合项目目标及需求，以及可说明项目风险的贡献程度。待验证的工作产品包含与维护、培训及支持相关的服务。工作产品的验证需求包含验证方法。验证方法说明验证工作产品的方法，以及验证特定的工作产品符合其需求的特定方法。软件工程适用验证方法，举例如下： •路径涵盖度测试 •负载、压力及绩效测试 •以决策表为基础的测试 •以功能分解为基础的测试 •测试项目复用 •验收测试系统工程适用系统工程的验证通常包括，原型制作、塑模，与仿真以验证系统设计（及配置）的足够性。硬件工程适用硬件工程的验证通常需要参数化的方法，用来考量不同环境情况（例如：压力、温度、震动、湿度）、不同输入范围（例如：输入电力可能介于20 至32 伏特，当规划的正常值为28 伏特）、零件与零件的容忍问题所引起的变异数，以及其它变量。硬件验证除了对不确定的互相影响存疑外，通常大多数的变量会分开测试。选择验证方法通常始于参与定义产品及产品组件需求，以确保需求可以验证。验证方法必须说明再次验证如何执行，以确保工作产品经过重新制作后不会引发不可预期的缺陷。供应商应参与选择的过程，以确保项目所实行的方法对于供应商环境是适当的。典型的工作产品 IPPD 补充验证方法应与产品及产品组件设计同时开发，并不断反复检讨修订。 1. 需接受验证的工作产品清单 2. 每个工作产品的验证方法子实践 1. 识别需验证的工作产品。 2. 识别每个工作产品须符合的需求。参考需求管理过程域的「维护需求的双向追溯性」特定实践，以帮助识别每一工作产品的需求。 3. 识别可用的验证方法。 4. 定义每个工作产品的验证方法。 5. 提出需验证的工作产品、需满足的需求及使用的验证方法，以与项目计划集成。有关协调项目策划的信息，请参考项目策划过程域。 SP 建立验证环境建立并维护支持验证工作的环境。须建立环境以便执行验证。执行验证所需的环境可以购买、自行开发、再利用、修改已存在的环境，或以上所列的组合，端视项目的需求而定。验证所需的环境取决于需验证的工作产品及所使用的方法。同行评审仅需文档、资料、审查人员及会议室。产品测试可能需要仿真器、场景产生器、数据量降低工具、环境控制及与其它系统的接口。典型的工作产品 1. 验证环境子实践 1. 识别验证环境需求。 2. 识别可复用及修改的验证资源。 3. 识别验证设备及工具。 4. 取得支持验证的设备及环境，例如：测试设备及软件。 SP 建立验证程序与准则建立并维护所选定的工作产品的验证程序与准则。 IPPD 补充验证程序与准则应与产品及产品组件的设计同时且反复开发。定义验证准则，以确保工作产品符合需求。验证准则的来源包括： • 产品与产品组件的需求 • 标准 • 组织方针 • 测试类型 • 测试参数 • 测试质量与测试成本间取舍的因素 • 工作产品类型 • 供应商 • 建议书与协议典型的工作产品 1. 验证程序 2. 验证准则子实践 1. 必要时，为工作产品与现成品，制作广泛且集成的验证程序。 2. 必要时，开发与调修验证准则。 3. 识别预期结果、观察中允许的误差及其它符合需求的准则。 4. 识别支持验证所需的设备及与环境有关的组件。 SG 2 执行同行评审对选定的工作产品执行同行评审。同行评审为有条理的检查工作产品，识别需移除的缺陷并建议其它需变更事项。此项工作乃由产品制作人员的同行执行。同行评审是重要而且有效的验证方法，通过检查、结构化逐步审查或其它经证实的审查方式来执行。同行评审主要应用于项目工作产品上，亦可应用在其它工作产品，例如：由支持团队开发的文档及培训教材。 SP 准备同行评审准备对选定的工作产品进行同行评审。同行评审的准备工作，通常包括：识别受邀参与每一工作产品审查的人员、识别必要参与的主要审查人员、准备及更新同行评审需使用的数据，例如：检查表、审查准则及同行评审进度等。典型的工作产品 1. 同行评审进度 2. 同行评审检查表 3. 工作产品的入口及出口准则 4. 需再次举行同行评审的准则 5. 同行评审培训教材 6. 已选定待审查的工作产品子实践 1. 决定采用哪一种同行评审类型。同行评审的类型，举例如下： • 检查 • 结构化逐步审查 • 主动审查 2. 针对同行评审时所应收集的资料，定义其需求。有关识别及收集数据的信息，请参考度量与分析过程域。 3. 建立并维护同行评审的入口及出口准则。 4. 建立并维护再次审查工作产品的准则。 5. 建立并维护检查表，以确保工作产品审查的一致性。检查表包括的项目，举例如下： • 架构原则 • 设计指导 • 完整性 • 正确性 • 维护性 • 共同缺陷的类型视工作产品及同行评审的特性修改检查表，并由开发检查表的同行及可能的使用者审查检查表。 6. 开发详细的同行评审进度，包括同行评审的培训日期及审查所需数据的完成进度。 7. 工作产品分发前，需先确保其符合同行评审入口准则。 8. 提早分发工作产品及其相关信息给审查人员，使审查人员有足够的准备时间。 9. 适当地分配人员所担任的角色。审查人员的角色，举例如下： • 负责人 • 读者 • 记录者 • 作者 10. 先行审查工作产品，以准备进行同行评审。 SP 进行同行评审针对所选定的工作产品进行同行评审，并由同行评审的结果识别问题。执行同行评审目的之一，即是能及早发现并去除缺陷。同行评审是随着工作产品的开发逐步进行。此种审查为结构化的，但并非管理审查。可以针对规格、设计、测试及实现活动的关键工作产品，以及特定的规划性质工作产品执行同行评审。同行评审重点应为被审查的工作产品，而非工作产品的制作人员。同行评审发现的问题，应与工作产品的主要制作人员沟通，以便修正。有关追踪同行评审发现的问题，请参考项目监控过程域。同行评审须强调下列指导：必须充分准备、须于控制下执行、须记录一致且充分的数据 (例如：执行正式审查) 及须记录行动方案。典型的工作产品 1. 同行评审结果 2. 同行评审问题 3. 同行评审数据子实践 1. 依分配的角色进行审查。 2. 识别并记录工作产品的缺陷及其它问题。 3. 记录审查结果，包括行动方案。 4. 收集同行评审资料。有关数据收集，请参考度量与分析过程域，以获得更多信息。 5. 识别行动方案并与相关的干系人沟通问题。 6. 若已定义的准则指出需要性，则需再次执行审查。 7. 确保符合审查的出口准则。 SP 分析同行评审资料分析同行评审的准备、执行及结果资料。有关获得与分析同行评审资料，请参考度量与分析过程域，以获得更多信息。典型的工作产品 1. 同行评审资料 2. 同行评审行动方案子实践 1. 记录同行评审准备、执行及结果的数据。典型的数据通常包括产品名称、产品规模大小、评审成员、评审类型、每一评审人员的准备时间、评审会议时间、缺陷数、缺陷类型及发生处等。其它可能收集的工作产品信息，例如：规模大小、开发阶段、所检查的操作模型及被评估的需求。 2. 保存数据，以便日后参考及分析。 3. 保护数据，以确保同行评审数据无不当使用。使用数据评估人员绩效、将审查结果归属到个人的绩效上是不当使用同行评审数据的范例。 4. 分析同行评审资料。可用来分析的同行评审资料，举例如下： • 被植入的阶段缺陷 • 相对于期望时间或速率的准备时间或速率 • 相对于期望数量的缺陷数量 • 已发现的缺陷种类 • 缺陷的原因 • 缺陷解决方案的冲击 SG 3 验证工作产品依照所指定的需求，验证所选定的工作产品。使用验证的方法、程序及准则，并在适当的验证环境中，来验证已选择的工作产品及其它相关的维护、培训，及支持服务。整个产品生命周期都应该执行验证活动。与同行评审有关的实践，定位为或如同特定验证方法，包含在特定目标2中。 SP 执行验证对选定的工作产品执行验证。于产品及工作产品开发过程中，逐步执行验证，促使及早发现问题，并能及早移除缺陷。验证结果节省了耗用在寻找问题过程中，将问题独立出来及重做的可观成本。典型的工作产品 1. 验证结果 2. 验证报告 3. 展示 4. 执行程序纪录子实践 1. 依据需求，针对选定的工作产品执行验证。 2. 记录验证活动的结果。 3. 由工作产品的验证结果，识别行动方案。 4. 记录所执行的验证方法，以及在执行中发现与可行方法及程序的偏差。 SP 分析验证结果分析所有验证活动的结果真实的结果必须与验证准则比较，以决定可接受性。记录分析结果，作为验证执行的证据。对于每一工作产品，所有可用的验证结果需逐项分析，以确保工作产品符合需求。因为同行评审为验证方法之一，同行评审数据必须包括在分析活动中，以确保验证结果已经充分分析。分析报告或实践的纪录，可能指出不良的验证结果肇因于验证方法、准则或基础环境架构的问题。典型的工作产品 1. 分析报告(例如：绩效统计值、不符合事项的原因分析、实际产品与模型的比较、趋势等) 2. 问题报告 3. 验证方法、准则及环境的变更需求子实践 1. 比较实际与预期结果。 2. 以验证准则为基线，识别未符合需求的产品，或识别方法、程序、准则及验证环境的问题。 3. 分析与缺陷有关的验证资料。 4. 记录所有分析结果并制成报告。 5. 运用验证结果，比较实际度量及绩效与技术性绩效参数间的差异。 6. 提供缺陷如何解决的信息(包含验证方法、准则及验证环境)，并开始实施纠正措施。有关纠正措施的实施，请参考项目监控过程域之纠正措施实践，以获得更多信息。各目标的通用实践仅适用于连续式表述 GG 1 达成特定目标本过程将识别输入的工作产品转换为输出的工作产品，并支持与促进过程域特定目标的达成。 GP 实施特定实践实施验证过程的特定实践，以开发工作产品并提供服务，达成过程域的特定目标。 GG 2 制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述 GG 3 制度化已定义过程本通用目标反映在阶段式表述的位置。 GP 建立组织方针建立并维护组织的方针，以规划和执行验证过程。详细说明：本方针建立组织对建立并维护验证方法、程序、准则与验证环境、以及对执行同行评审及验证选定的工作产品的期望。 GP 规划过程建立并维护用来执行验证过程的计划。详细说明：执行验证过程的计划可包含在(或参考)项目计划。项目计划在项目策划过程域中说明。 GP 提供资源提供充分的资源，以执行验证过程、开发工作产品及提供过程服务。详细说明：验证选定的工作产品可能需要特殊设施，这些验证过程域活动所需要的设施可以自行开发或采购。某些验证方法可能需要特别的工具、设备、设施及培训(例如：同行评审可能需要会议室及受过培训的会议主席，有些验证测试可能需要特殊测试设备以及熟悉设备使用的人员)。其它提供的资源，举例如下： • 测试管理工具 • 测试项目产生器 • 测试涵盖分析器 • 仿真器 GP 分配责任分配验证过程的责任与授权，以执行过程、开发工作产品及提供过程服务。 GP 培训人员依需要培训人员，以执行或支持验证过程。详细说明：培训主题，举例如下： • 应用或服务领域 • 验证原则、标准及方法(例如：分析、展示、检查、测试) • 验证工具及设施 • 同行评审准备及作业程序 • 会议协调技巧 GP 管理配置将指定的验证过程工作产品，纳入适当等级的控制。详细说明：纳入控制的工作产品，举例如下： • 验证程序与准则 • 同行评审培训教材 • 同行评审资料 • 验证报告 GP 识别并纳入相关的干系人依计划识别并纳入验证过程相关干系人。详细说明：从下列人员中选择相关的干系人：客户、使用者、开发者、生产者、测试人员、供应者、营销人员、维护人员、销毁人员，以及其它可能被产品及过程影响或可能影响产品及过程的人。干系人参与的活动，举例如下： • 选择需验证之工作产品与验证方法 • 建立验证程序及准则 • 执行同行评审 • 评价验证结果并识别纠正措施 GP 监控过程依本过程的执行计划，监控验证过程，并采取适当的纠正措施。详细说明：用以监控的度量及工作产品，举例如下： • 验证摘要(例如：计划与执行验证的次数、发现的缺陷数，并将缺陷依验证方法或类型分类) • 每一缺陷类型发现的缺陷数 • 验证问题报告趋势(例如：问题数量及关闭数量) • 验证问题报告状况(例如：每一问题报告悬而未解的时间) • 特定验证活动的进度 GP 客观评价遵循程度依本过程的说明、目标、标准及程序，客观评估验证过程的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下： • 选择需验证的工作产品 • 建立并维护验证程序与准则 • 执行同行评审 • 验证所选定的工作产品审查的工作产品，举例如下： • 验证程序与准则 • 同行评审检查表 • 验证报告 GP 与高层管理人员审查各状况与高层管理人员审查验证过程的活动、状况及结果，并解决问题。仅适用于连续式表述 GG 3 制度化已定义过程将过程制度化为已定义过程。本通用目标反映在连续式表述的位置。 GP 建立已定义过程建立并维护已定义验证过程的说明。 GP 收集改进信息收集由规划和执行验证过程所衍生的工作产品、度量、度量结果及改进信息，以支持组织过程与过程资产的未来使用与改进。详细说明：工作产品、度量、度量结果与改进信息，举例如下： • 同行评审纪录包括，执行时间及平均准备时间 • 每个开发阶段中，通过验证所发现的产品缺陷数量 • 验证及分析报告仅适用于连续式表述 GG 4 制度化已量化管理过程将过程制度化为已量化过程。 GP 建立过程的量化目标建立并维护验证过程的量化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。 GP 稳定子过程绩效稳定一个或多个子过程的绩效，以决定验证过程的能力，是否达成已建立之量化质量与过程绩效目标。 GG 5 制度化已优化过程将过程制度化为已优化过程。 GP 确保持续的过程改进确保验证过程的持续改进，以实现相关的组织经营目标。 GP 纠正问题的根本原因识别并纠正验证过程之缺陷与其它问题的根本原因。第三部分附录与词汇附录A. 数据资料公开的资料 Ahern 2003 Ahern, Dennis M.; Clouse, Aaron; & Turner, Richard. CMMI Distilled: A Practical Introduction to Integrated Process Improvement, Second Edition. Boston: Addison-Wesley, 2003. Ahern 2005 Ahern, Dennis M.; Armstrong, Jim; Clouse, Aaron; Ferguson, Jack R.; Hayes, Will; & Nidiffer, Kenneth E. CMMI SCAMPI Distilled: Appraisals for Process Improvement. Boston: Addison-Wesley, 2005. Chrissis 2003 Chrissis, Mary Beth; Konrad, Mike; & Shrum, Sandy. CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley, 2003. Crosby 1979 Crosby, Philip B. Quality Is Free The Art of Making Quality Certain. New York: McGraw-Hill, 1979. Curtis 2002 Curtis, Bill; Hefley, William E.; & Miller, Sally A. The People Capability Maturity Model Guidelines for Improving the Workforce. Boston: Addison-Wesley, 2002. Deming 1986 Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering, 1986. DoD 1996 Department of Defense. DoD Guide to Integrated Product and Process Development (Version ). Washington, DC: Office of the Under Secretary of Defense (Acquisition and Technology), February 5, 1996. Dymond 2004 Dymond, Kenneth M. A Guide to the CMMI: Interpreting the Capability Maturity Model Integration. Annapolis, MD: Process Transition International Inc., 2004. EIA 1994 Electronic Industries Alliance. EIA Interim Standard: Systems Engineering (EIA/IS-632). Washington, DC, 1994. EIA 1998 Electronic Industries Alliance. Systems Engineering Capability Model (EIA/IS-731). Washington, DC, 1998; (Note: This model has been retired by EIA.) GEIA 2004 Government Electronic Industries Alliance. Data Management (GEIA-859). Washington, DC, 2004. Gibson 2006 Gibson, Diane L.; Goldenson, Dennis R. & Kost, Keith. Performance Results of CMMI-Based Process Improvement. (CMU/SEI-2006-TR-004, ESC-TR-2006-004). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006. Humphrey 1989 Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. IEEE 1990 Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE, 1990. ISO 1987 International Organization for Standardization. ISO 9000: International Standard. 1987. ISO 1995 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 12207 Information Technology—Software Life Cycle Processes, 1995. . ISO 1998 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 15504 Information Technology—Software Process Assessment, 1998. ISO 2000 International Organization for Standardization. ISO 9001, Quality Management Systems—Requirements, 2000. ISO 2002a International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15939 Software Engineering—Software Measurement Process, 2002. ISO 2002b International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15288 Systems Engineering—System Life Cycle Processes, 2002. ISO 2006 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 15504 Information Technology—Software Process Assessment Part 1: Concepts and Vocabulary, Part 2: Performing an Assessment, Part 3: Guidance on Performing an Assessment, Part 4: Guidance on Use for Process Improvement and Process Capability Determination, Part 5: An Exemplar Process Assessment Model, 2003-2006. Juran 1988 Juran, Joseph M. Juran on Planning for Quality. New York: Macmillan, 1988. McGarry 2000 McGarry, John; Card, David; Jones, Cheryl; Layman, Beth; Clark, Elizabeth; Dean, Joseph; & Hall, Fred. Practical Software Measurement: Objective Information for Decision Makers. Boston: Addison-Wesley, 2002. SEI 1995 Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995. SEI 1997a Integrated Product Development Capability Maturity Model, Draft Version . Pittsburgh, PA: Enterprise Process Improvement Collaboration and Software Engineering Institute, Carnegie Mellon University, July 1997. (Note: This model was never officially released and is no longer publicly available.) SEI 1997b Software Engineering Institute. Software CMM, Version (Draft C), October 22, 1997. (Note: This model was never officially released and is no longer publicly available.) SEI 2001 Paulk, Mark C. & Chrissis, Mary Beth. The 2001 High Maturity Workshop (CMU/SEI-2001-SR-014). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, January 2002. SEI 2002a CMMI Product Development Team. CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version Staged Representation (CMU/SEI-2002-TR-012, ESC-TR-2002-012). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002. SEI 2002b CMMI Product Development Team. CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version Continuous Representation (CMU/SEI-2002-TR-011, ESC-TR-2002-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002. SEI 2002c Software Engineering Institute. Software Acquisition Capability Maturity Model (SA-CMM) Version (CMU/SEI-2002-TR-010, ESC-TR-2002-010). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002. SEI 2004 Software Engineering Institute. CMMI A-Specification, Version . (February 2004). SEI 2005 Software Engineering Institute. CMMI Acquisition Module (CMMI-AM) Version (CMU/SEI-2005-TR-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, May 2005. SEI 2006a CMMI Product Development Team. ARC , Appraisal Requirements for CMMI, Version (CMU/SEI-2006-TR-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 2006. SEI 2006b CMMI Product Development Team. SCAMPI , Standard CMMI Appraisal Method for Process Improvement, Version : Method Definition Document (CMU/SEI-2006-HB-002). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, July 2006. Shewhart 1931 Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: Van Nostrand, 1931. Regularly Updated Sources SEI 1 Software Engineering Institute. The IDEAL Model. SEI 2 Software Engineering Institute. CMMI Frequently Asked Questions (FAQs). SEI 3 Software Engineering Institute. CMMI Performance Results. 附录B. 缩写字 API application program interface应用程序接口 ARC Appraisal Requirements for CMMI CMMI 评估需求 CAD computer-aided design计算机辅助设计 CAR Causal Analysis and Resolution (process area) 原因分析与解决方案(过程域) CCB configuration control board配置控制委员会 CL capability level能力度等级 CM Configuration Management (process area) 配置管理(过程域) CMM Capability Maturity Model能力成熟度模型 CMMI Capability Maturity Model Integration能力成熟度集成模型 CMMI-DEV CMMI for Development CMMI 适用于开发 CMMI-DEV+IPPD CMMI for Development +IPPD CMMI 适用于含集成的产品与过程开发 COTS commercial off the shelf现成品 CPI cost performance index成本绩效指标 CPM critical path method关键路径方法 CSCI computer software configuration item计算机软件配置项 DAR Decision Analysis and Resolution (process area) 决策分析与解决方案(过程域) DoD Department of Defense国防部 EIA Electronic Industries Alliance电子工业协会 EIA/IS Electronic Industries Alliance/Interim Standard电子工业协会过渡期标准 EPG engineering process group工程过程组 FCA functional configuration audit功能配置审计 GG generic goal通用目标 GP generic practice通用实践 IBM International Business Machines国际商业机器公司 IDEAL Initiating, Diagnosing, Establishing, Acting, Learning启始、诊断、建立、行动、学习 IEEE Institute of Electrical and Electronics Engineers电子电机工程学会 INCOSE International Council on Systems Engineering国际系统工程协会 IPD-CMM Integrated Product Development Capability Maturity Model集成的产品开发能力成熟度模型 IPM Integrated Project Management (process area) 集成的项目管理(过程域) IPM+IPPD Integrated Project Management +IPPD (process area) 集成的项目管理含IPPD(过程域) IPPD integrated product and process development集成的产品与过程开发 ISO International Organization for Standardization国际标准组织 ISO/IEC International Organization for Standardization and International Electrotechnical Commission国际标准组织与国际电机协会 MA Measurement and Analysis (process area) 度量与分析(过程域) MDD Method Definition Document方法定义文档 ML maturity level成熟度等级 NDI nondevelopmental item非开发项目 NDIA National Defense Industrial Association国家国防工业协会 OID Organizational Innovation and Deployment (process area) 组织创新与部署(过程域) OPD Organizational Process Definition (process area) 组织过程定义(过程域) OPD+IPPD Organizational Process Definition +IPPD (process area) 组织过程定义含IPPD(过程域) OPF Organizational Process Focus (process area) 组织过程焦点(过程域) OPP Organizational Process Performance (process area) 组织过程绩效(过程域) OT Organizational Training (process area) 组织培训(过程域) OUSD (AT&L) Office of the Under Secretary of Defense (Acquisition, Technology, and Logistics) 国防部助理部长办公室(采购、技术及后勤) P-CMM People Capability Maturity Model人员能力成熟度模型 PA process area过程域 PCA physical configuration audit物理配置审计 PERT Program Evaluation and Review Technique计划评核与审查技术 PI Product Integration (process area) 产品集成(过程域) PMC Project Monitoring and Control (process area) 项目监控(过程域) PP Project Planning (process area) 项目策划(过程域) PPQA Process and Product Quality Assurance (process area) 过程与产品质量保证(过程域) QA quality assurance质量保证 QFD Quality Function Deployment质量功能展开 QPM Quantitative Project Management (process area) 量化项目管理(过程域) RD Requirements Development (process area) 需求开发(过程域) REQM Requirements Management (process area) 需求管理(过程域) ROI return on investment投资回报率 RSKM Risk Management (process area) 风险管理(过程域) SA-CMM Software Acquisition Capability Maturity Model软件采购能力成熟度模型 SAM Supplier Agreement Management (process area) 供应商协议管理(过程域) SCAMPI Standard CMMI Appraisal Method for Process Improvement CMMI 过程改进标准评估方法 SECM Systems Engineering Capability Model系统工程能力模型 SEI Software Engineering Institute软件工程学院 SG specific goal特定目标 SP specific practice特定实践 SPI schedule performance index进度绩效指标 SW-CMM Capability Maturity Model for Software or Software Capability Maturity Model软件能力成熟度模型 TS Technical Solution (process area) 技术解决方案(过程域) URL uniform resource locator统一资源寻址器 VAL Validation (process area) 确认(过程域) VER Verification (process area) 验证(过程域) WBS work breakdown structure工作拆分结构附录C. CMMI-DEV 项目参与人员许多精英从一开始就是产品组的成员，一直从事建立与维护CMMI 产品系列。本附录列出参与CMMI 版的人员。本开发团队有四个主要小组：产品团队、赞助组、推动组及配置控制委员会。这些小组的现有成员如下所列，如要知道前几年更完整的参与人员清单，参考模型版之附录C。产品团队产品团队审查由CMMI 使用者提出变更CMMI 产品系列的变更要求，包括架构、模型、培训及评估材料。开发活动依据变更要求、推动组提供的V 版指导及配置控制委会成员的输入数据。 V 版发布的计划经理为Mike Phillips，他协调下列团队的努力成果。模型团队成员 Armstrong, Jim (Systems and Software Consortium) Bate, Roger (Software Engineering Institute) Cepeda, Sandra (RD&E Command, Software Engineering Directorate) Chrissis, Mary Beth (Software Engineering Institute) Clouse, Aaron (Raytheon) D'Ambrosa, Mike (BAE Systems) Hollenbach, Craig (Northrop Grumman) Konrad, Mike (Software Engineering Institute) Norimatsu, So (Norimatsu Process Engineering Laboratory, Inc.) Richter, Karen (Institute for Defense Analyses) Shrum, Sandy (Software Engineering Institute) SCAMPI 更新团队成员 Busby, Mary (Lockheed Martin) Cepeda, Sandra (RD&E Command, Software Engineering Directorate) Ferguson, Jack (Software Engineering Institute)16 Hayes, Will (Software Engineering Institute) Heil, James (. Army) in memoriam Kirkham, Denise (Boeing) Masters, Steve (Software Engineering Institute) Ming, Lisa (BAE Systems) Ryan, Charlie (Software Engineering Institute) Sumpter, Beth (National Security Agency) Ulrich, Ron (Northrop Grumman) Wickless, Joe (Software Engineering Institute) 培训团队成员 Chrissis, Mary Beth (Software Engineering Institute) Gibson, Diane (Software Engineering Institute) Knorr, Georgeann (Software Engineering Institute) Kost, Keith (Software Engineering Institute) Matthews, Jeanne (Software Engineering Institute) Shrum, Sandy (Software Engineering Institute) Svolou, Agapi (Software Engineering Institute) Tyson, Barbara (Software Engineering Institute) Wickless, Joe (Software Engineering Institute) Wolf, Gary (Raytheon) 架构团队成员 Bate, Roger (Software Engineering Institute) Chrissis, Mary Beth (Software Engineering Institute) Hoffman, Hubert (General Motors) Hollenbach, Craig (Northrop Grumman) Ming, Lisa (BAE Systems) Phillips, Mike (Software Engineering Institute) Scibilia, John (. Army) Wilson, Hal (Northrop Grumman) Wolf, Gary (Raytheon) 硬件团队成员 Armstrong, Jim (Systems and Software Consortium) Bishop, Jamie (Lockheed Martin) Cattan, Denise (Spirula) Clouse, Aaron (Raytheon) Connell, Clifford (Raytheon) Fisher, Jerry (Aerospace Corporation) Hertneck, Christian (Siemens) Nussbaum, Winfried (Siemens) Phillips, Mike (Software Engineering Institute) Zion, Christian (THALES) 试行团队成员 Brown, Rhonda (Software Engineering Institute) Chrissis, Mary Beth (Software Engineering Institute) Ferguson, Jack (Software Engineering Institute) Konrad, Mike (Software Engineering Institute) Phillips, Marilyn (Q-Labs, Inc.) Phillips, Mike (Software Engineering Institute)20 Tyson, Barbara (Software Engineering Institute) 质量团队成员 Brown, Rhonda (Software Engineering Institute) Kost, Keith (Software Engineering Institute) McSteen, Bill (Software Engineering Institute) Shrum, Sandy (Software Engineering Institute) 赞助者 CMMI 版由政府及工业界赞助，政府赞助由美国国防部提供，特别是国防部助理部长办公室(采购、技术及后勤)( OUSD [AT&L])，工业界赞助由国家国防工业协会(NDIA)的系统工程委员会提供。 Rassa, Bob (NDIA Systems Engineering Division) Schaeffer, Mark (OUSD [AT&L]) 推动组推动组指导与批准V 版产品团队的计划，提供重大CMMI 项目问题的咨询，与确保来自众多有兴趣团体的参与。推动组成员 Baldwin, Kristen (OUSD [AT&L] DS/SE) Chittister, Clyde (Software Engineering Institute) D'Agosto, Tony (. Army RDECOM-ARDEC) Gill, Jim (Boeing Integrated Defense Systems) Kelly, John (NASA HQ) Lundeen, Kathy (Defense Contract Management Agency) McCarthy, Larry (Motorola, Inc.) Nicol, Mike (. Air Force ASC/EN) Peterson, Bill (Software Engineering Institute) Rassa, Bob (Raytheon Space & Airborne Systems) Weszka, Joan (Lockheed Martin) Wilson, Hal (Northrop Grumman Mission Systems) Zettervall, Brenda (. Navy, ASN/RDA CHENG) 官方推动组成员 Anderson, Lloyd (Department of Homeland Security) Bate, Roger; chief architect (Software Engineering Institute) Drake, Thomas (National Security Agency) Phillips, Mike; CMMI program manager (Software Engineering Institute) Sumpter, Beth (National Security Agency) Yedlin, Debbie (General Motors) 推动组支持：采购 Gallagher, Brian (Software Engineering Institute) 推动组支持：变更控制委员会 Konrad, Mike (Software Engineering Institute) 变更控制委员会变更控制委员会为控制CMMI-DEV 模型V 版变更的正式机制。这个组负责审查针对基线的变更并且只批准符合版相关准则的变更，以执行产品集成。变更控制委员会成员 Atkinson, Shane (Borland/TeraQuest) Bate, Roger (Software Engineering Institute) Bernard, Tom (. Air Force) Chrissis, Mary Beth (Software Engineering Institute) Croll, Paul (Computer Sciences Corporation) Gristock, Stephen (JPMorganChase) Hefner, Rick (Northrop Grumman Corporation) Jacobsen, Nils (Motorola) Konrad, Mike (Software Engineering Institute) Osiecki, Lawrence (. Army) Peterson, Bill (Software Engineering Institute) Phillips, Mike (Software Engineering Institute) Rassa, Bob (Raytheon) Richter, Karen (Institute for Defense Analyses) Sapp, Millee (. Air Force) Schoening, Bill (Boeing and INCOSE) Schwomeyer, Warren (Lockheed Martin) Smith, Katie (. Navy) Wolf, Gary (Raytheon) 无投票权变更控制委员会成员 Brown, Rhonda (Software Engineering Institute) Shrum, Sandy (Software Engineering Institute) D.词汇 CMMI 词汇定义用于CMMI 模型的基本术语。词汇通常是数个字的术语，包含一个名词与一个或一个以上的限制修饰词。(此规则有部分例外，词汇中也有一个字的术语说明)。为有系统的说明适合CMMI 的定义，我们咨询许多的来源出处。首先我们参考韦氏在线字典()及来源模型(如EIA 731,SW-CMM V2. draft C 及IPD-CMM )。如有需要我们也参考其它标准，包括下列： • ISO 9000 [ISO 1987] • ISO/IEC 12207 [ISO 1995] • ISO/IEC 15504 [ISO 2006] • ISO/IEC 15288 [ISO 2002b] • IEEE [IEEE 1990] • SW-CMM • EIA 632 [EIA 1994] • SA-CMM [SEI 2002c] • P-CMM [Curtis 2002] 我们开发词汇乃是基于「使所有模型的使用者都了解专门术语」之重要性的认知。同时文字与术语在不同的内文与环境，有不同的意义。CMMI 模型的词汇用来记载文字与术语的意义，应是使用最广泛且应为CMMI 产品使用者所了解的。验收准则产品或产品组件必须符合的准则，以让使用者、客户或其它经授权的物理能接受该产品或产品组件。验收测试让使用者、客户或其它经授权的物理决定是否对接受产品或产品组件，所执行的正式测试。(请参见「组件测试」。) 达成摘要连续式表述中，在提升能力程度时，一组过程域与其相关的能力度，表示组织于每个过程域的进度。(请参见「能力度摘要」、「目标摘要」及「目标阶段式」。) 采购通过合同取得产品(物品及服务)的过程。采购策略根据供应的来源、采购的方法、需求规格的类型、合同或协议的类型及相关的采购风险以决定产品与服务之采购的特定方法。补充在CMMI 产品系列中，清楚注记的模型组件含有特定的使用者有兴趣的信息。CMMI 模型中，所有的补充说明带有相同的名称(如IPPD 补充说明) 可当作一组来选用。足够的通过这些字词的使用，你可以依组织的经营目标来诠释模型的目标及实践。当使用任何CMMI 模型的时候，你必须诠释实践使其适用于贵组织。而在模型的目标及实践中使用这些字词，可以用来说明其中的某些活动并不是一直都要进行。(请参见「适当的」及「视需要的」) 配置的需求将较高层需求的所有或部分绩效及功能，赋予较低阶架构组件或设计组件的需求。替代的实践可用以替代CMMI 模型中，一个或多个一般或特定实践的实践，该实践在达成CMMI 的一般或者特定目标时，具有相同的效果。替代的实践未必与一般或特定的实践是一对一的替代关系。强化强化(amplifications) 是参考的模型组件，包含特定专业领域的相关信息。例如：想找软件工程的专业领域强化，可以在模型中寻找标示为「软件工程适用(For Software Engineering)」的标签。此方式也适用于找其它专业领域强化的信息。评估在CMMI 产品系列中，「评估(appraisal)」是指一群培训有素的专家，以评估的参考模型(reference model) 为基础，对一个或多个过程进行检验，至少做到决定其优点及缺点。(请参见「评价」及「能力评估」) 评估调查结果评估调查结果识别出评估范围内过程改进最重要的问题、问题或机会。评估调查结果是根据证实的客观证据推论得到。评估参与者在评估时，提供数据的组织单位成员。评估评等如同CMMI 评估数据所定义的，由评估组对于(a)CMMI 的目标或过程域、(b)过程域的能力度，或(c)组织单位的成熟度，指定评分。通过执行评估方法定义的评等过程来决定评等。评估参考模型如同CMMI 评估数据所定义的，评估组将已实施的过程活动与此CMMI 模型相互关连。评估范围定义评估的界限，包含将被调查运作过程的组织界限与CMMI 模型界限。适当的通过这个字词的使用，你可以依组织的经营目标来诠释模型的目标及实践。当使用任何CMMI 模型的时候，你必须诠释实践使其适用于贵组织。而在模型的目标及实践中使用这些字词，可以用来说明其中的某些活动并不是一直都要进行。(请参见「足够的」及「视需要的」) 视需要的通过这个字词的使用，你可以依组织的经营目标来诠释模型的目标及实践。当使用任何CMMI 模型的时候，你必须诠释实践使其适用于贵组织。而在模型的目标及实践中使用这些字词，可以用来说明其中的某些活动并不是一直都要进行。(请参见「足够的」及「适当的」) 评价在CMMI 产品系列中，组织为了本身过程改进的目的所进行的一种评估。「评价」在CMMI 产品系列中使用的意义与日常使用的意义相同(例如:风险评价)。(请见「评估」及「能力评估」) 过程变异的可指定原因在CMMI 中，以「过程变异的特殊原因」来替代「过程变异的可指定原因」以确保一致性，两者皆有相同的定义。(请参见「过程变异的特殊原因」。) 审计在CMMI 过程改进的工作中，依据特定的准则(例如:需求)，客观的检验一项工作产品或一组工作产品。基础度量一个物理的明确特性或特征，以及将其量化的方法。(请参见「衍生度量」。) 基线经正式审查及同意的一组规格或工作产品，据以用作未来开发的基础，而且仅能由变更控编程序变更。(请参见「配置基线」及「产品基线」) 双向追溯性两个或更多个逻辑物理间可辨识的双向关联(如指向与来自某个物理)。(请参见「需求追溯性」及「追溯性」) 经营目标 (请参见「组织经营目标」。) 能力评估由一组受过培训的专业人员所作的评估，以作为选择供应商、依合同监督供应商、或决定与强制实施诱因之辨识工具。评估用来洞察供应商组织的过程能力，参考决策者做更好的采购决定、改进分包商的绩效及提供采购组织的洞察力。(请参见「评估」及「评价」。) 能力程度个别过程域内过程改进达到的程度，能力度由过程域内适当的特定及通用实践所定义。(请参见「通用目标」、「通用实践」、「成熟度等级」及「过程域」。) 能力度摘要在连续式表述中，一组过程域与其对应的能力度。(请参见「达成摘要」、「目标摘要」及「目标阶段式」。) 当摘要用来表示在提升能力度过程中，组织于每个过程域的进度，这个摘要可能是达成摘要。或者当它用来表示过程改进的目标时，可能是目标摘要。能力成熟度模型模型包含一个或多个专业领域的有效过程之基本组件。它也描述渐进的改进途径，从随兴的不成熟的过程到具有改进质量及有效性的有纪律的成熟过程。有能力的过程能满足其特定的产品质量、服务质量及过程绩效目标的过程。(请参见「稳定过程」、「标准过程」及「统计化管理过程」。) 原因分析分析缺陷以找出其原因。变更管理审慎使用各种方法，以达成产品或服务的变更或建议的变更。(请参见「配置管理」。) 组织CMMI 组件的基本结构，包括目前CMMI CMMI 架构模型中的共同组件、模型产出的规则及方法、评估方法(包括相关的产出)及其培训教材。这个架构可让新的专业领域加到CMMI 中，并使它可与现有专业领域集成。(请参见「CMMI 模型」及「CMMI 产品系列」) CMMI 模型 CMMI 架构可产生可能模型的整个集合，CMMI 模型为其中一个模型。因此依照各组织的需要，可由CMMI 架构产生不同的模型，目前有许多CMMI 模型。(请参见「CMMI 架构」及「CMMI 产品系列」) CMMI 模型组件任何组成CMMI 模型的主要结构组件，一些CMMI 模型的主要组件包括特定实践、通用实践、特定目标、通用目标、过程域、能力度及成熟度。 CMMI 产品系列以CMMI 观念所开发的整套产品，这些产品包括架构本身、模型、评估方法、评估数据及各种培训。(请参见「CMMI 架构」及「CMMI 模型」。) 过程变异的共同原因因过程各组件间彼此正常与预期的交互作用，而存在的过程变异。(请参见「过程变异的特殊原因」。) 操作概念 (请参见「操作概念(operational concept)。」配置审计执行审计以验证配置项或一组配置项配置基线符合特定的标准或需求。(请参见「审计」、「配置项」、「功能性配置审计」及「物理性配置审计」。) 配置基线配置信息是指产品或产品组件生命中某一特定时间的信息，配置基线加上以这些基线为主所核可的变更，构成目前的配置基线。(请参见「产品生命周期」。) 配置控制配置管理的组件包含评估、协调、核可或不核可，以及正式建立配置识别后对配置项所做的变更。(请参见「配置识别」、「配置项」及「配置管理」。) 配置控制委员会负责评估及对配置项提出之变更的核可或不核可，而且确保核可的变更均已执行的一组人。(请参见「配置项」。)配置控制委员会又称为「变更控制委员会」。配置识别配置管理的组件包含选择产品的配置项、指定唯一的识别，以及记录其功能与物理的特性于技术文档。(请参见「配置项」、「配置管理」及「产品」。) 配置项为了配置管理所指定的一组工作产品，在配置管理过程中视为单一物理。(请参见「配置管理」。) 配置管理配置管理应用技术与管理的引导与监督之专业培训，来(1)识别与记录配置项功能与物理的特性、(2)控制这些特性的变更、(3)记录与报告变更的处理与执行的状态，以及(4)验证符合特定的需求。(请参见「配置审计」、「配置控制」、「配置识别」及「配置状态纪录」。) 配置状态纪录配置管理的组件包含记录与报告有效管理一个配置所需的信息。这个信息包括核可的配置识别清单、配置预期变更的状态，以及核可变更的执行状态。(请参见「配置识别」及「配置管理」。) 连续式表述一种能力成熟模型架构，在每一特定的过程域中，能力度提供处理过程改进的建议顺序。(请参见「能力度」、「过程域」及「阶段式表述」。) 承包商（请参见「供应商」。）纠正措施修复某种状况、除去错误或调整状态的行动或行为。现成品可向商业供应商购买的项目。(COTS 代表「commercial off the shelf」。) 客户负责验收产品或授权付款的团体(可能是个人、项目或组织)。客户是项目的外部单位(当IPPD 使用集成团队时，可能除外)，但未必是组织的外部单位。客户可能是较高层的项目。客户是干系人的一部分。(请参见「干系人」。) 大部分使用这个名词时，意指上述定义。然而，有些情况“客户”意含其它相关的干系人。(请参见「客户需求」。) 客户需求以客户可接受的方式，诱导、集成及解决产品相关干系人对需要、期望、限制及接口冲突。(请参见「客户」。) 数据无论纪录的形式与方法的纪录信息，包括技术数据、计算机软件文档、财务信息、管理信息、事实、任何能够沟通、存储与处理的数量或数据数据管理在数据生命周期，对经营与技术数据规划、获取及提供管理之有规律的过程与系统，能与数据需求有一致性。缺陷密度每单位产品的缺陷数(如每千行程序代码的问题报告单数)。已定义过程一个已管理过程，此过程是根据组织的定义指导，从组织标准过程所定义而来；包含维护过程说明及对组织过程资产贡献工作产品、度量与其它的过程改进信息。(请参见「已管理过程」。) 衍生度量两个或多个基础度量的数学函数所导出的数据。(请参见「基础度量」。) 衍生需求在客户需求中并未明显陈述的需求，但可(1) 自上下文的需求推论（如应用的标准、法律、方针、通用实践及管理决策），或(2)自指定产品组件所需的需求推论。衍生需求亦可在分析与设计产品或系统的组件时产生。(请参见「产品需求」。) 设计审查对设计之正式的、文档化的、完整的及有系统的检验，以评估设计需求与符合这些需求的设计能力，识别问题并提出解决方案。开发在CMMI 产品系列中，不仅是开发的活动，还包括维护活动。受益于CMMI 最佳实践的项目，可以专注于开发或维护，或者两者并行。开发计划用以指导、执行及控制一个或多个产品之设计与开发的计划。(请参见「产品生命周期」及「项目计划」。) 专业领域在CMMI 产品系列中，当选择CMMI 模型(如系统工程)时，可使用的知识体系(bodies of knowledge)。CMMI 产品团队未来也计划将其它的知识体系集成到CMMI 架构中。文档文档是数据的集合，不论其记录媒体。文档通常具有永久性，而且可由人或机器来阅读。所以，文档包括书面文档与电子文档。企业集团企业集团由多个公司所组成。公司可能由位于不同地点及拥有不同客户的多个组织所组成。(请参见「组织」。) 入口准则在可成功开始工作投入之前，必须出现的状态。对等的阶段式目标阶段式由连续式表述所产生。使用目标阶段式的结果可与阶段式表述的成熟度比较。(请参见「能力度摘要」、「成熟度」、「目标摘要」及「目标阶段式」。) 不论使用何种CMMI 表述，此阶段式允许于组织、企业及项目之间进行进度的标竿学习。组织可能执行某些CMMI 模型的组件超越其对等的阶段式部分组件。对等的阶段式只是一个度量，以成熟度的立场说明一个组织相对于其它组织的成熟度。建立并维护在CMMI 产品系列中，你将遇到目标与实践中常含有「建立并维护(establish and maintain)」字词。这个字词所包含的意义，不仅是建立并维护，它还有书面化与使用的涵义。举例而言，「建立并维护组织方针，以策划与实施组织的过程焦点过程」的意思，不仅是整理过的方针，还必须有书面记载，并于整个组织中执行。证据 (请参见「客观证据」。) 高级主管人员 (请参见「资深管理人员」。) 出口准则在可成功结束工作投入之前，必须出现的状态。期望的CMMI组件能解释执行什么可满足一个必要之CMMI 组件的CMMI 组件。模型的使用者可明确的执行期望的组件，或执行与这些组件相同意义的替代实践。特定与通用实践皆是期望的CMMI 组件。调查结果 (请参见「评估调查结果」。) 正式评估过程一种结构化的方法，依据已建立的准则评估备选解决方案，并决定推荐的方案，以解决问题。架构 (请参见「CMMI 架构」。) 功能分析检验已定义的功能来识别完成该功能所需的所有子功能；识别功能的关系与接口(内部及外部)，并在功能架构中呈现；可自高层绩效需求引导，并将这些需求指定给下层的子功能。(请参见「功能架构」。) 功能架构功能的阶层式安排，其内部及外部(聚集本身的外部)的功能接口、外部的物理接口、相关功能，以及绩效需求及设计限制。功能配置审计执行审计以验证配置项的开发已满足的完成，配置项在功能或配置配置识别的绩效与功能特性已达成，以及操作与支持文档已完成与满意。(请参见「配置审计」、「配置管理」及「物理配置审计」。) 通用目标必要的模型组件，说明制度化过程实施过程域必须呈现的特性。(请参见「制度化」。) 通用实践期望的模型组件，对达成相关的通用目标相当重要。与其通用目标相关连的通用实践，说明为达成通用目标结果的期望活动及贡献过程域相关过程的制度化。通用实践的详细说明有参考的过程组件，出现在通用实践之后，提供通用实践如何应用到过程域的指导。目标必要的CMMI 组件，可能是通用目标或特定目标。当在CMMI 模型看到目标字词时时常参考到模型组件(例如通用目标与特定目标)。( 请参见「通用目标(goal) 」、「目的(objective)」及「特定目标」。) 硬件工程应用有系统化、有纪律的及数量化方法，将一组使用文档化的技术表示干系人需要、期望与限制之需求，转换为设计、实施及维护有形的产品。(请参见「软件工程」及「系统工程」。) 在CMMI 中，硬件工程代表所有的技术领域(例如：电子、机械)，转换需求与构想为有形及可生产的产品。高层管理提供过程方针与整体性指导，并非提供日常过程监督与控制的人员。此种人员在组织中高于负责过程的中层管理人员。可能是(但不一定是) 资深管理人员。(请参见「资深管理人员」。) 不完整的过程未执行或只执行部分的过程(又称为能力度第0 级)。该过程域的一项或多项特定目标未达成。参考的CMMI 组件可参考模型使用者了解模型必要与期望组件的CMMI 组件。这些组件包括范例、详细解释或其它有参考的信息。子实践、批注、参考数据、目标标题、实践标题、来源、典型的工作产品、强化及通用实践详细说明等，都是参考的模型组件。制度化经营企业根深蒂固的方法，组织经常性的遵守，就像公司文化的一部分。集成的产品与过程开发产品开发的系统化方法，使相关的干系人在产品生命周期中做到适时的合作，以更能符合客户的需要。集成团队一组具备完整技能与专业知识的人员，能适时合作并承诺交付特定的工作产品。集成团队成员对工作产品生命期各阶段提供适当的技能与支持，并能共同负责交付指定的工作产品。集成团队应包括来自组织、专业领域及功能的授权代表，他们对于工作产品的成功都有利害关系。接口控制配置管理中的过程，包括：(1)由一个或一个以上的组织所提的二个或多个配置项，识别与其接口相关的所有功能与物理特性的过程，以及(2)在执行之前，确保对这些特性提出的变更，是经过评估与核可的过程。(请参见「配置项」及「配置管理」。) 生命周期模型将一个产品或项目的生命周期分成数个阶段。已管理过程已执行的过程依照方针策划与实施；雇用有技能的人有足够资源生产受管理的产出；纳入相关的干系人；有监督、控制与审查；以及评估遵循过程说明程度。(请参见「已执行的过程」)。管理人员在CMMI 产品系列中，管理人员提供技术与管理的方向与控制给其责任区域内执行工作与活动的人员。管理人员传统的功能包括：责任区域内规划、组织、领导及控制工作。成熟度等级过程改进的程度，在一组事先定义的过程域中，其所有的目标皆达成。(请参见「能力度」及「过程域」。) 协议备忘录二个或多个团体之间了解或协议必须遵守的文档。(又称为「备忘录」。) 自然界限过程的本质以过程绩效的度量来表示，有时称为「过程的声音」。使用如控制图、信赖区间与预测区间的技术，来决定变异是来自于共同原因(即过程是可预测的或「稳定的」)，或来自于某些可以且应找出并移除的特殊原因。非开发项目(NDI) 采购或开发过程中，于使用之前即已开发完成的供应项目，该项目可能只需要较小的修改，以符合其目前期望的使用需求。非技术需求合同规定、承诺、条件及条文，将影响产品或服务如何获得。例如：交付的产品、交付现成品(COTS)与非开发项目(NDIs)的数据权、交付日期及有出口准则的里程碑。其它的非技术需求包括培训需求、场地需求及部署进度等。目标在 CMMI 产品系列中，「目标(goal)」一词已有特定的用途，即使用于「通用目标」与「特定目标」中。所以，当模型中需要表达日常使用之「目标(goal)」的意义时，会以「目标(objective)」来表示。(请参见「目标(goal)」。) 客观证据如CMMI 评估数据、文档或面谈结果，用来当做模型实践的实施与制度化的指标。客观证据的来源能包括工具、简报文档及访查。客观评估依据准则审查活动与工作产品，将审查人员的主观与偏见减至最小。由独立的质量保证功能人员，针对需求、标准或程序所执行的审计是客观评估的范例。(请参见「审计」。) 观察如同CMMI 评估资料，「观察」是一份书面的纪录，用以表示评估组成员在评估资料收集活动中，对于所见所闻的了解。该书面纪录可以用报告表的格式，也可以用其它的表格来记录，只要可以保存信息的内容即可。操作概念一个物理使用或操作方法的一般描述。(又可称为「操作概念(concept of operations)」。) 操作场景想象之事件顺序的描述，包括产品与其环境与使用者的相互作用，以及产品组件之间的相互作用。操作场景用来评估系统的需求与设计，并验证与确认系统。已优化过程根据了解过程变异的共同原因，而改进的量化管理过程。以渐进与创新的改进，已优化过程焦点于过程绩效范围的持续改进。(请参见「过程变异的共同原因」、「已定义过程」及「量化管理过程」。) 组织一个行政管理结构由成员共同管理一个或多个项目。这些项目有共同的资深管理人员，并在相同的方针下运作。不过在CMMI 模型中，「组织」也可以是只有一个人以执行某功能的小组织；如果在大组织中，这些功能可能由一组人执行。(请参见「企业集团」及「组织单位」。) 组织成熟度组织明显且一致地部署过程的程度，这些过程已文档化、已管理、已度量、已控制及持续改进。组织成熟度可由评估来度量。组织方针通常由资深管理人员所建立的指导原则，组织采纳后将会影响并决定决策。组织过程资产过程的说明、实施及改进有关的成果(artifacts) (如方针、度量、过程说明及过程实行支持工具等。)，「过程资产」指出开发或取得这些成果的目的，在于满足组织的经营目标。过程资产也代表组织的投资，并预期这些投资会提供目前及未来的经营价值。(请参见「过程资产库」。) 组织单位组织中接受评估的部分。组织单位部署一个或多个过程，这些过程具有一致性的过程范围，并在一致性的经营目标下执行。组织单位通常是较大组织的一部分，然而在小组织中，组织单位可能就是整个组织。组织经营目标绩效参数资深管理人员所开发的策略，用来确保组织永续存在及增强其获利率、市场占有率，以及其它影响组织成功的因素。(请参见「质量与过程绩效的目标」及「量化目标」。) 当应用至系统工程的活动时，这样的目标包括降低系统集成阶段需求变更的次数、减少开发周期时间、增加开发的第一或第二阶段错误发现的数目、减少客户所报告的缺陷数等等。组织度量资产库收集与提供过程与工作产品之度量数据的存储库，尤其是与组织标准过程相关的数据。存储库包含或参考实际的度量数据或其参照的数据，以及了解与估计度量数据所需的相关信息。组织过程资产库用来存储与使有用过程资产库。它使组织中定义、实施及管理过程的人员，可以取得这些有用的过程资产。这信息库包含过程相关文档，如方针、已定义过程、检查表、学习心得的文档、样板、标准、程序、计划、及培训教材等。组织标准过程组织中引导所有活动之过程的定义。这些过程说明涵盖基本的过程组件(process elements)(及其相互的关系，如次序与接口)。而且这些基本的过程组件必须合并到整个组织的项目所执行的已定义过程中。标准过程使整个组织具有一致的开发活动与维护活动，也是长期之稳定性及改进的重要条件。(请参见「已定义过程」及「过程组件」。) 委外 (请参见「采购」。) 同行评审在工作产品开发期间，由工作同行对工作产品所执行的审查，以识别须移除的缺陷。在CMMI 产品系列中，使用「同行评审(peer review)」，而不使用「工作产品检查(work product review)」。(请参见「工作产品」。) 绩效参数有效性的度量与其它的主要度量，用来指导与控制开发的进行。已执行的过程完成整个必要工作以产生工作产品的过程。该过程域的特定目标皆须符合要求。物理配置审计执行审计以验证所建立的配置项，符合技术文档的定义与说明。 (请参见「配置审计」、「配置管理」及「功能配置审计」。) 已规划的过程指包含说明与计划之文档化的过程，说明与计划应彼此协调，而且计划应包括标准、需求、目标、资源及工作分配等。方针 (请参见「组织方针」。) 过程在CMMI 产品系列中，活动可视作CMMI 模型中实践的实施。这些活动可以对照到CMMI 过程域的一个或多个实践，以允许模型有用于过程改进及过程评估。(请参见「过程域」，「子过程」及「过程组件」。) 在通用目标与通用实践的叙述与说明，「过程」字词有特别的用法。「过程」如同使用再第二部分时，是指实施该过程域的一个过程与许多过程。过程行动计划通常是评估结果后的计划，针对评估时发现的缺陷，记录如何实施改进。过程执行团队记录于过程行动计划中，负责开发及执行组织过程改进活动的团队。过程与技术改进对过程或产品技术渐进与创新的改进。过程架构标准过程中，过程组件间的次序、接口、相互依赖，以及过程组件间的其它关系。过程架构也说明过程组件与外部过程(例如：合同管理) 间的接口、相互依赖及其它关系。过程域一组同属某领域及相关的实践，当共同执行时，可以达成一组目标，而这些目标对该领域的重大改进是重要的。对连续式表述与阶段式表述所有的CMMI 过程域而言，都是共同的。过程资产组织认为达到某过程域目标有用的任何事物。(请参见「组织过程资产」。) 过程资产库过程资产的收集，可用于组织或项目。(请参见「组织过程资产库」。) 过程属性过程能力的可度量特性，可适应用于任何过程。过程能力遵循一个过程可达到之预期结果的范围。过程定义定义与描述过程的行动。过程定义的结果为过程说明。(请参见「过程说明」。) 过程说明以文档化的表达方式，表示执行一组活动以完成某特定的目的，该文档提供过程主要组件的操作定义。这文档以完整、明确及可验证的方式，指定过程的需求、设计、行为或其它的特性。它可能也包括决定这些规定是否符合的程序。过程说明可见于活动、项目或组织等级。过程组件过程的基本单位。以子过程或过程组件的方式定义过程，子过程可以继续分解成其它的子过程与/或过程组件，但过程组件则不能继续分解。每一个过程组件包含一组关系密切的活动(例如：估计组件、同行评审组件)。可使用待完成的样版、待调修的摘要，或待修正或使用的说明，来描述过程组件。过程组件可以是一项活动或工作。过程组帮助定义、维护及改进组织所使用之过程的专家群。过程改进用来改进组织过程绩效与成熟度的行动计划，以及该计划的成果。过程改进目标采用可度量方式所建立一组目标特性，用以改进现有过程的指导。度量方式可以是产品结果的特性(例如：质量、绩效、标准的符合程度等)，或是过程执行的方式(例如：除去多余的过程步骤、合并过程步骤、改进周期时间等)。(请参见「组织经营目标」及「量化目标」。) 过程改进计划基于充分了解现在组织过程与资产的优点与缺点，为达成组织过程改进的目标的计划。过程度量用来度量过程及其产品的定义、方法与活动，其目的是了解该过程及记述其特征。过程负责人负责定义与维护过程的个人(或团队)。在组织等级，过程负责人是负责描述标准过程的个人(或团队)。在项目等级，过程负责人是负责描述已定义过程的个人(或团队)。因此在不同等级责任中，一个过程可能有多个过程负责人。(请参见「已定义过程」及「标准过程」。) 过程绩效遵循一个过程所达成实际结果的度量。是由过程度量(如工作量、周期时间及缺陷移除的效率)与产品度量(如可靠度、缺陷密度及反应时间)所描述。过程绩效基线遵循一个过程所达成实际结果的特性纪录，用来作为比较实际过程绩效与预期过程绩效的标竿。(请参见「过程绩效」。) 过程绩效模型描述过程与其工作产品的属性间的关系，它们自历史的过程绩效数据开发而来，并使用项目所收集的过程与产品度量加以调校，以及来预测后续过程达成的结果。过程定义为了某特定目的而制作、修改或改编过程说明。例如：项目自组织标准过程定义其已定义过程，以符合项目的目标、限制及环境。(请参见「已定义过程」、「组织标准过程」及「过程说明」。) 产品在CMMI 产品系列中，产品是指预定交付给客户或最终使用者的工作产品。产品的形式依不同的情况而异。(请参见「客户」、「产品组件」、「服务」及「工作产品」。) 产品基线配置管理中已核可的初始技术数据包(包括软件、原始码清单)，在其生命周期的生产、操作、维护及后勤支持中定义配置项。(请参见「配置项」及「配置管理」。) 产品组件在CMMI 模型中，产品组件通常指产品中较低阶的工作产品，产品组件通过集成以组合成产品，产品组件可以有许多层次。(请参见「产品」及「工作产品」)。产品组件需求产品组件的完整规格，包含适合、表格、功能、绩效及其它需求。产品生命周期从产品的构想开始，到产品不再使用的期间，通常分几个阶段。组织可能同时为多个客户生产多个产品，单一产品生命周期的描述可能不足。所以组织可以定义一组经验证的产品生命周期模型。这些模型通常可以从公开的刊物上寻得，但多半须定义才能适用于组织。产品生命周期可包含下列的阶段：(1)概念/愿景；(2)可行性研究；(3)设计/开发；(4)生产；(5)废除。产品线拥有共同的及已管理特性的一系列产品，可满足某一部分市场或任务的特定需要。产品相关的生命周期过程与产品生命周期一个或多个阶段相关的过程(例如：从概念设计到产品汰除)，例如：制造与支持过程。产品需求将客户的需求调修成开发者的语言，将隐含的需求变成明确的衍生需求。(请参见「衍生需求」及「产品组件需求」。) 开发者使用产品需求来指导设计与产品的制作。产品系列 (请参见「CMMI 产品系列」。) 摘要 (请参见「达成摘要」与「目标摘要」。) 计划 (1)一个项目。(2)一组相关的项目及支持它们的基础架构，包括目标、方法、活动、计划及成功的度量。(请参见「项目」。) 项目在CMMI 模型中，一组受管理的相关资源，以便交付一项或多项产品给客户或最终使用者。项目有明确的开始点(例如项目启动)及依据计划执行。这个计划大多以文档记载，并说明将交付与实现的产品、所使用的资源与经费、工作项目及工作进度表。一个项目也可以由多个项目组成。(请参见「项目启动」。) 项目管理人员在CMMI 产品系列中，负责策划、督导、控制、组织及推动项目的人。项目管理人员负责满足客户的需求。项目计划计划提供执行与控制项目活动的基础，以处理对项目客户的承诺。项目策划包括估计工作产品与工作项目的属性、决定所需的资源、协商、承诺、产生进度，以及识别与分析项目风险，有时需要重复些活动足以建立项目计划。项目进度与绩效根据执行项目计划所达成者，包括工作量、成本、进度及技术绩效。项目启动组相关的资源被指示去开发或交付一个或多个产品给客户或最终使用者。(请参见「项目」。) 项目已定义过程织标准过程定义而得的已集成与定义的过程。(请参见「已定义过程」。) 原型评等产品或产品组件的初步类型、形式或实例，可作为后续阶段或最终完成产品的模型。这个模型(物理的、电子的、数字的、分析的等)可用于下列(及其它)目的： • 评价新的或不熟悉技术的可行性。 • 评价或降低技术风险。 • 确认需求。 • 展示重要的特性。 • 证明产品合格。 • 证明过程合格。 • 描述绩效或产品的特性。 • 说明物理的原理质量产品、产品组件或过程本身特性的能力，以满足客户需求。质量与过程绩效的目标产品质量、服务质量、与过程绩效的目标与需求。过程绩效目标包括质量；然而，在CMMI 产品系列中为了强调质量的重要性，所以使用质量与绩效目标字词而不是过程绩效目标。质量控制保证管理以有计划的与系统化的方法，引用已定义的过程标准、实践、程序及方法。用于满足质量需求的操作技术与活动。(请参见「质量保证」。) 量化目标以量化的度量表示期望的目标值。(请参见「过程改进目标」及「质量与过程绩效的目标」。) 量化管理过程已经以统计及其它量化技术来控制的已定义过程，在整个项目过程中，产品质量、服务质量及过程绩效的属性是可度量与控制的。(请参见「已定义过程」、「已优化过程」及「统计化管理的过程」。) 评等 (请参见「评估评等」。) 参考资料参考的模型组件，它指导在相关的过程域中更多详细的信息。参考模型当作度量某些属性之标竿的模型。相关的干系人识别参与某特定活动与纳入计划的干系人。(请参见「干系人」) 表述 CMM 组件的组织、使用及展示。总体而言，显然有两种方法表示最佳实践：阶段式表述与连续式表述。必要的CMMI 组件在过程域中，要达成过程改进的必要CMMI 组件，这些组件在评估中用以决定过程的能力。特定目标与通用目标是必要的模型组件。需求 (1)使用者解决问题或达成目标所需的条件或能力。(2)产品或产品组件必须符合或拥有的条件或能力，以满足合同、标准、规格或其它正式提出的文档。(3)记录(1)或(2)所述之条件或能力的文档。需求分析以客户需要、期望及限制的分析；操作观念；人员、产品及过程的预期使用环境；以及度量的有效性为基础，来决定产品特定的绩效与功能的特征。需求诱导使用有系统的技术，例如原型与结构化调查，以主动识别与记录客户与使用者的需要。需求管理管理项目收到或产生的所有需求，包括技术与非技术的需求，以及组织对项目的需求。需求追溯需求与相关需求、实施及验证间可识别的关连。(请参见「双向追溯性」及「追溯性」。) 投资回报率输出(产品)相对于生产成本的收益比，用以决定组织是否由产生产品的执行行动中获得利益。风险分析风险的评估、分类及设定优先级风险识别有组织且完整的方法，以寻找达成目标时可能的或实际的风险。风险管理一个有组织、分析式的过程，用以识别可能造成伤害或损失的来源(识别风险)；评价及量化已识别的风险；以及开发并于必要时执行适当的方法，来避免或处理可能造成巨大伤害或损失的风险原因。风险管理策略一个有组织、技术的方法，用以识别可能造成伤害或损失的原因(识别风险)；评价及量化已识别的风险；以及开发与并于必要时执行适当的方法，来避免或处理可能造成巨大伤害或损失的风险原因。通常风险管理是为项目、组织或开发产品的组织单位而实行。根本的原因缺陷的源头，一旦去除，缺陷会减少或清除。资深管理人员在CMMI 模型中，一个组织中，层次够高的管理角色。资深管理人员主要专注于组织永续的经营，而不是短期的项目及合同的顾虑与压力。资深管理人员有权分配或重分配资源，以支持组织过程改进的有效性。(请参见「高层管理」。) 符合以上条件的管理人员都可以是资深管理人员，包括组织负责人。资深管理人员的同义词有「执行长(executive)」与「高层主管(toplevel manager)」，但为了确保模型的一致性及实用性，CMMI 模型里并不使用这两个同义词。服务在CMMI 产品系列中、服务是无形与不可存储的产品。(请参见「产品」、「客户」、「工作产品」及「服务」。) 共同愿景一种指导原则的共识，包括任务、目标、期望的行为、价值及最终结果。共同愿景由项目所开发与使用。软件工程 (1)应用系统化、有纪律的及量化的方法，来开发、操作及维护软件。(2)关于第(1)项方法的研究。(请参见「硬件工程」及「系统工程」。) 招标准备招标文档及选择供应商(承包商)的过程。过程变异的特殊原因缺陷的原因是特有的某些瞬间情况，而不是过程本身所造成。(请参见「过程变异的共同原因」。) 特定目标必要的模型组件说明必须要呈现以满足该过程域的独特属性。(请参考「能力度」、「通用目标」、「组织经营目标」及「过程域」。) 特定实践对达成相关的特定目标是重要的期望类模型组件。特定实践说明一组活动，这组活动被期望可达成某过程域的特定目标。 (请参见「过程域」及「特定目标」。) 稳定过程当所有过程变异的特殊原因皆已移除，且避免再发生，以致只留下过程变异的共同原因。(请参见「有能力的过程」、「过程变异的共同原因」、「标准过程」、「过程变异的特殊原因」及「统计化管理的过程」。) 阶段式表述一种模型架构，当达到一组过程域的所有目标，则建立了一成熟度等级；每一等级是后续等级的基础。(请参见「成熟度」及「过程域」。) 干系人在CMMI 产品系列中，承担计划执行结果或受计划影响的个人或团体，干系人可能包括项目成员、供应商、客户、最终使用者及其它。( 请参见「客户」及「相关的干系人」。) 标准在CMMI 模型中，当名词使用的「标准(standard)」是指一个正式且具强制性的需求，这些需求被开发及用来规定具有一致性的开发方法 (例如：ISO/IEC 标准、IEEE 标准、组织的标准)。我们使用与「标准」有相同意义的其它术语来代表一般日常意义的「标准」(例如：典型的、传统的、通常的或惯例)。标准过程基本过程的操作定义，用来指导组织共享过程的建立。标准过程描述基本的过程组件，期望这些过程组件可包含在任何已定义过程中，它也描述这些过程组件之间的关系(如顺序与接口)。(请参见「已定义过程」。) 工作说明书完成项目所需之协议工作的说明。统计的可预期度量化过程的绩效，可由统计及其它量化的技术所控制。统计过程控制以统计的方法分析过程与度量过程的绩效，可识别过程绩效，变异的共同与特殊原因，并将过程绩效维持在某一范围内。(请参见「过程变异的共同原因」、「过程变异的特殊原因」及「统计化管理的过程」。) 统计技术应用统计方法的分析技术(例如：统计过程管制、信赖区间及预测区间)。统计化管理的过程已以统计技术管理的过程，此过程已被分析、识别过程变异的特殊原因，且绩效维持在明确识别的范围内。(请参见「有能力的过程」、「过程变异的特殊原因」、「稳定过程」、「标准过程」及「统计过程控制」。) 子实践提供指导诠释与执行特定或通用实践，为参考的模型组件。子实践以规范式的文字描述，仅提供可用于过程改进的意见而不具强制性。子过程较大过程的部分过程。子过程能再细分为子过程及/或过程组件。(请参见「过程」、「过程说明」及「过程组件」。) 供应商 (1)一个可交付购买产品或提供服务的实体。(2)个人、合伙、公司、法人、协会或其它的服务机构，与采购者有协议(合同)，在协议(合同)的条款下进行设计、开发、制造、维护、修订或供应商品。维持确保产品可供最终使用者与客户操作的过程。「维持」确保已完成维护，不论客户或最终使用者是否正使用该产品，产品皆在可操作的状况下。系统工程横跨不同专业领域，控制整个技术与管理投入之方法，用来将客户的需要、期望及限制，转换成为产品的解决方案，并在产品生命周期内支持该解决方案。(请参见「硬件工程」及「软件工程」) 包括技术的绩效度量定义，集成工程的特性来建立产品的架构，以及支持生命周期过程的定义，用来平衡成本、绩效及进度的目标。定义定义过程为了特定目的，制作、改变或调整过程说明。举例而言，某项目通过定义组织标准过程，来建立一套已定义过程，以符合项目的目标、限制及环境。定义指导组织指导，能让项目、团队及组织功能通过适当的定义标准过程，以符合他们的使用。在CMMI 模型中，组织标准过程只是一般性的说明，不见得可直接用来执行过程。定义指导可辅助为项目建立已定义过程的人。定义指导的内容涵盖：(1)选择一标准过程，(2)选择一经验证的生命周期模型，以及(3) 定义所选择的标准过程及生命周期模型，以符合项目的需要。定义指导说明定义时哪些内容是否可修改，并识别哪些过程组件是可修改的对象。目标摘要在连续式表述中，一组过程域与其相关的能力度，可表示过程改进的目标。(请参见「达成摘要」及「能力度摘要」。) 目标阶段式在连续式表述中，用来描述过程改进途径，以供组织遵循的一系列目标摘要。(请参见「达成摘要」、「能力度摘要」及「目标摘要」。) 技术相关数据如果下列信息适合产品与产品组件的类型(例如：原料与制造需求可能不适用于软件服务与过程的产品组件)，技术数据包可包括下列各项： • 产品架构说明 • 配置的需求 • 产品组件说明 • 产品相关的生命周期过程说明，如果不是以个别产品组件来说明时 • 主要的产品特性 • 必要的物理特性与限制 • 界面需求 • 原料需求(原料需求表及原料特性) • 生产与制造需求(对原始设备制造商与现场支持)） • 确保需求已达成的验证准则。 • 整个产品生命周期中，操作、支持、培训、制造、汰除与验证的使用(环境)条件与操作/使用场景、模型与状态。 • 决策与特性的理由说明(需求、需求配置、设计选择) 技术需求欲采购或开发的产品或服务的内容(属性)。测试程序为某特定测试的准备、执行及结果评估的详细说明。追溯性两个或更多个逻辑物理(如需求、系统组件、验证或工作项目)间可辨识的关联。 (请参见「双向追溯性」及「需求追溯性」。) 替代方案研究根据准则与系统化分析，评估各个方案，以选择能达成目标的最佳方案。培训正式与非正式学习选项，可包括课堂培训、非正式指导：上网培训、自我引导学习及正式工作中培训计划。对每一情况的学习是基于选择培训需要的评价及欲解决的绩效落差。典型的工作产品某特定实践的产出范例之参考的模型组件。这些范例之所以称为典型的工作产品，是因为除了这些具代表性的范例之外，还有其它的工作产品也是有参考的，但未被列出。组件测试个别的硬件或软件单元或一组相关单元的测试。(请参见「验收测试」。) 确认证实所提供的产品(或即将提供的产品)，符合其预期的使用需求。换句话说，「确认」确保「你做了正确的事」(请参见「验证」。) 验证证实工作产品是否适当的反映其指定的需求。换句话说，验证确保「你做对了」。(请参见「确认」。) 版本控制建立与维护基线及识别基线的变异，使还原至前一个基线成为可能。工作拆分结构工作项目的安排、其彼此之间的关系，以及与最终产品之间的关系。工作产品在CMMI 产品系列中，一个过程所产出的有用结果。工作产品包括档案、文档、产品、产品组件、服务、过程说明、规格及出货单。工作产品与产品组件的主要差异，在于工作产品不必要是产品的一部分。(请参见「产品」及「产品组件」。) 在CMMI 模型中，许多地方使用了工作产品及服务字词。虽然工作产品的定义已包含服务，但在讨论中，使用这个字词强调工作产品包括了服务。工作产品与工作项目属性产品、服务及项目工作的特性，可帮助估计项目的工作量。这些特性的项目包括如：规模大小、复杂度、权重、表格、安装与功能。它们通常作为输入以推得其它的项目及资源的估计值(如工作量、成本、进度)。 CMMI 架构是基本结构，用来组织CMMI 组件，并且将其集成成为CMMI 群集与模型。评估是经由受过专业训练之团队针对一到多个过程进行审视，并使用一个参考模型(例如：CMMI) 来当做决定优势与劣势的基准。 SEI 的网站位于「过程域」是在一个区域中相关连的最佳执行方法群集，当被共同实行时，会满足一组被认为重要且具有显著改善该区域的目标。我们将会在第2 章详述这个概念。电子工业联盟731(EIA 731) 也肯定CMMI。过程域的名称有包含「+IPPD」是因为其包含IPPD 的目标与执行方法。IPPD 的特定内容称之为IPPD 附加。所有包含「IPPD 附加」的过程域其名称后面都有「+IPPD」更多有关于评估的信息，请参考Appraisal Requirements for CMM 与Standard CMMI Appraisal Method for Process Improvement Method Definition Document [SEI 2006a, SEI 2006b] SCAMPI 方法被描述在第五章。请参考表通用目标与通用实践章节，已获得更多信息有关通用实践与过程域的相依性当使用CMMI 具有附加IPPD 组时，组织过程定义(OPD)仅有一个目标(Goal)应用。当使用CMMI 具有附加IPPD 组时，集成的项目管理(IPM)仅有一个目标(Goal)应用。看能力成熟度集成模型产品系列的词汇定义经验显示最重要会影响过程改进与评估的成功的因素是高层管理者的支持当通用实践与过程域无直接关系，混淆的风险就会降低，所以在表中并不描述所有递归的关系（例如：通用实践、及） Team Leader Co-Team Leaders Team Leader Team Leader Team Leader Co-Team Leaders Team Leader Government Co-Chair Industry Co-Chair Configuration Control Board Chair 关于CMMI for Development PAGE 2 中文简体化by Song,tao 2008

联系我们

智库文档公众号

客服微信

适用于开发的能力成熟度集成模型.doc

下载

相关专题更多

联系我们

意见反馈

相关专题 更多

联系我们

意见反馈

相关专题更多