datasheet
超过460,000+ 应用技术资源下载
pdf

CMMI_V1.3简体中文版.pdf

  • 1星
  • 日期: 2015-08-03
  • 大小: 3.31MB
  • 所需积分:1分
  • 下载次数:2
  • favicon收藏
  • rep举报
  • 分享
  • free评论
标签: CMMI_V1 3简体中文版

CMMI_V1.3简体中文版

CMMI®开发模型,版本 1.3 CMMI-DEV,1.3 版 CMMI 产品团队 为开发更好的产品与服务而改进过程 2010 年 11 月 技术报告 CMU/SEI-2010-TR-033 ESC-TR-2010-033 软件工程过程管理项目 有版权约束的无限制分发 http://www.sei.cmu.edu This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2010 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. This document may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other external and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu. 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 252.227-7013. For information about SEI publications, please visit the library on the SEI website (www.sei.cmu.edu/library). The following service marks and registered marks are used in this document: Capability Maturity Model Carnegie Mellon CERT CMM CMMI CMM Integration IDEALSM SCAMPISM CMMI, CMM, CERT, CMM Integration, Carnegie Mellon, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office. SCAMPI and IDEAL are service marks of Carnegie Mellon University. 本报告为以下机构编写: SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 本报告中的观点与发现不应被视为美国国防部的正式立场。其出版是为了科 学与技术的信息交流。 此项工作由美国国防部发起并资助。软件工程研究所是由美国国防部发起并 资助、由联邦政府提供资金的研究与开发中心。 版权所有:卡内基梅隆大学,2010 年 无担保 卡内基梅隆大学与软件工程研究所拥有的本资料“按现状”提供。卡内基梅 隆大学对任何明示或暗示的事项不做任何担保,其中包括但不限于其适用性、 适销性、排他性或使用本资料所产生的结果。卡内基梅隆大学对于专利、商 标或著作权方面的侵权责任免除不做任何担保。 本报告中任何商标的使用都没有以任何方式侵害商标所有人权利的意图。 内部使用。只要版权与“无担保”声明包含在所有的复制文档以及衍生著作 内,允许复制本文档或编写本文档的衍生著作供内部使用。 外部使用。无需申请正式的许可,允许对本文档进行无任何修改的完全复制,并以书面或电 子形式进行免费分发。其它任何外部的并且/或者是商业的用途则需要请求许可。许可请求 应发送至软件工程研究所的 permission@sei.cmu.edu。 本著作于履行联邦政府与卡内基梅隆大学订立的、与运作联邦政府资助的研 究与开发中心软件工程研究所有关的联邦政府合同(编号 FA8721-05-C-0003) 期间所创建。美国政府拥有免版税政府用途许可,能够以全部或部分或任何 方式使用、复制或公布此项工作。政府根据版权许可条款 252.227-7013,允 许他人出于政府目的进行同样操作。 欲 了 解 有 关 SEI 出 版 物 的 信 息 , 请 访 问 SEI 网 站 中 的 书 库 (www.sei.cmu.edu/library)。 本文档使用以下服务标记与注册标记:Capability Maturity Model Carnegie Mellon CERT CMM CMMI CMM Integration IDEALSM SCAMPISM CMMI,CMM,CERT,CMM Integration,Carnegie Mellon 及 Capability Maturity Model 已注册于美国专利与商标局。 SCAMPI 与 IDEAL 是卡内基梅隆大学的服务标记。 简体中文版序(原文) Over the last couple decades, China has emerged as a world-class economic power. People around the world often find themselves surrounded by products “made in China.” Most are labor-intensive products such as toys and textile goods, but, increasingly, many are higher quality products that require significant, large-scale engineering work. Success in such more complicated endeavors requires disciplined and mature development processes. Using the Capability Maturity Model Integration (CMMI) as a guide for process improvement has been important to many companies’ journeys to more robust and predictable processes that help achieve business success. It is no exaggeration that China has become one of the most active adopters of CMMI. Data from the Software Engineering Institute shows that China has reported more CMMI appraisals than any other country—including the United States—for several years in a row. China has impressed the world not only by its unprecedented economic growth, but also by its passion in pursuing best practices, such as those found in CMMI. I am very pleased that the Simplified Chinese version of CMMI for Development (CMMI-DEV) is now available. This will certainly give the CMMI community in China a better tool to overcome the language barrier to understanding the true essence of CMMI. With this translation, we expect to see even more success stories of Chinese organizations achieving world-class performance as reflected in both product and performance measures. I would like to extend my appreciation to all the participants of this translation project, especially to their leader Mr. Yue Zhao, who is a vigorous CMMI advocate and seasoned CMMI practitioner. The translation was by no means a straightforward endeavor. In addition to the significant amount of time devoted to the task, the project pursued several approaches to ensure translation quality, including establishing an independent verification team, setting a 100% internal review requirement, adopting an incremental and iterative translation process, and creating a keyword database and automatic matching system. We have confidence that the whole CMMI community in China and elsewhere will benefit from their dedication to translate CMMI accurately in both letter and spirit. Paul D. Nielsen Director and Chief Executive Officer Software Engineering Institute Carnegie Mellon University December 26, 2012 简体中文版序(译文) 经过几十年,中国已然成为一支世界级的经济力量。世界各地的人们时常 发现自己置身于“中国制造”产品的包围之中,其中多为玩具、纺织品等 劳动密集型产品。然而渐渐地,需要大量规模化工程工作的、更具品质的 产品亦已为数不少。要成功从事这样更为复杂的工作,就需具备规范成熟 的开发过程。对很多公司来说,在使他们的过程更扎实、更可预测,以助 力其业务成功的旅程中,使用能力成熟度模型集成(CMMI)作为改进指 南具有重要意义。 毫不夸张地说,中国已成为 CMMI 的最活跃采用方之一。软件工程研究所 的数据显示,中国所呈报的 CMMI 评估总数已经连续数年超过了包含美国 在内的其它任何国家。中国令世界所瞩目的,不仅是其前所未有的经济增 长,还有其追求最佳实践的热情,比如那些存在于 CMMI 之中的最佳实践。 如今有了 CMMI 开发模型(CMMI-DEV)简体中文版,我为此感到十分欣 慰。毫无疑问,这将提供给中国的 CMMI 群体一种更好的工具,去克服语 言障碍,从而理解 CMMI 的真谛。我们由此可以期盼更多中国组织的成功 案例,他们能够达成世界级的绩效水准,并以产品度量和绩效度量进行展 现。 我衷心地感谢参加此次翻译项目的所有成员,尤其是带领团队的赵悦先生, 他既是一位充满活力的 CMMI 倡导者,也是一位身经百战的 CMMI 实践者。 翻译工作绝非易事。该项目除了投入大量的时间,还采取了多种方法来确 保翻译质量,包括建立了独立的验证团队,设定了百分之百的内部审查要 求,采用了增量式与迭代式并用的翻译过程,同时创建了关键字数据库和 自动匹配系统。我们坚信,中国乃至其它地方的整个 CMMI 群体都将受益 于他们为形神兼备地精准翻译 CMMI 而作出的尽心奉献。 卡内基梅隆大学软件工程研究所 所长兼首席执行官 保罗  D  尼尔森 2012 年 12 月 26 日 译者序 CMMI 开发模型(CMMI-DEV)简体中文版在我们翻译小组与验证小组的 携手努力下,历经几次反复终得以完成。早在 2007 年,我们便通过美国 卡内基梅隆大学软件研究院,取得了软件工程研究所的翻译授权。那时, CMMI 在中国正遍地开花,以 CMMI 为主题的 SEPG 中国大会也进行得风 生水起。我们难免羁绊于各种大小事务,不知不觉耽误了翻译工作的进程。 直至今年年初,我们再一次全力以赴,以一年的辛苦劳作,CMMI 官方中 译本终于完稿。对此我们如释重负,因为我们深知业界对 CMMI 中译本已 经期盼多年,我们贸然开始的这项艰巨工作最终没有再次让大家失望。 经过十几年的历程,CMMI 在中国业已枝繁叶茂,CMMI 年评估数量已经 连续数年处于全球第一。固然这只是中国经济高速发展的一个缩影,但无 可否认,CMMI 模型在中国成为软件与系统工程行业过程改进最主流标准 的既成事实,亦源于 CMMI 体系自身的价值。唯因其结构之严谨、内容之 完整、阐述之具体、方法之系统,方奠定其在产业界的举足轻重地位。将 CMMI 博大精深之旨,以另一种迥异的语言精确而流畅地进行表达,是我 们的一项极富挑战性的工作。 为此,我们的翻译工作不可谓不小心翼翼。除设立独立验证组进行客观审 查之外,模型的每一行翻译都首先经过翻译组的内部评审。在翻译组解决 了内部评审的数千条问题点的基础上,独立验证组仍然提出数以千计的问 题点,我们再不惮其烦逐个解决。我们的期许在于,以这样事无巨细、悉 究本末的态度,去追求一次经典的翻译过程。事实上,无论是翻译组还是 验证组,所有成员均为 CMMI 业界之历练之士。执著于这样严格的翻译流 程,或许是我们内心深处对 CMMI 的痴迷所使然,而这样的痴迷不免渗透 至译文的字里行间,假如读者在阅读中能够感知一二,并因此受益,即可 给我们以极大宽慰。 当然绝非老套之语,或因才疏学浅,或因时间仓促,翻译中难免有所疏漏, 恳请读者指正,并予以见谅。 卡内基梅隆大学软件研究院 CMMI 模型翻译组组长 赵悦 2012 年 12 月 11 日 CMMI-DEV 1.3 版简体中文翻译参加人员 以下人士参加了 CMMI-DEV 1.3 版的简体中文翻译工作。成员姓名在各小 组中以姓名的汉语拼音字母顺序排列,姓名后列出的是翻译完稿时该成员 所代表的组织。 翻译组成员 • 陈豪,苏州华隆信息科技有限公司 • 华国红,中兴通讯股份有限公司 • 王岩,中国惠普有限公司 • 吴超英,北京航空航天大学 • 吴言,苏州华隆信息科技有限公司 • 徐明庆,北京赛柏科技有限责任公司 • 许娓,北京赛柏科技有限责任公司 • 袁庆平,北京高迈致远信息技术有限公司 • 赵悦,卡内基梅隆大学软件研究院(组长) 验证组核心成员 • 李巍,循序咨询(上海)有限公司(组长) • 任仲泉,循序咨询(上海)有限公司 • 张圣洁,循序咨询(上海)有限公司 验证组外围成员 • 居德华,华东理工大学 • 宋骏,普华永道信息技术(上海)有限公司 • 王青,中国科学院软件研究所 • 张凯,循序咨询(上海)有限公司 翻译工作支持人员 • Mike Konrad,Software Engineering Institute(翻译组支持) • Malcom Patrick,循序咨询(上海)有限公司(验证组支持) 前言 CMMI 开发模型,版本 1.3 目的 鸣谢 CMMI®(Capability Maturity Model® Integration,能力成熟度模型集成) 模型系列是帮助组织改进其过程的最佳实践的集合。这些模型由来自产 业界、政府以及软件工程研究所(Software Engineering Institute,SEI) 的成员所组成的产品团队开发完成。 本模型,称为 CMMI 开发模型(CMMI for Development, CMMI-DEV), 为开发产品与服务提供了全面的、集成化的系列指南。 CMMI-DEV 模型为开发型组织应用 CMMI 最佳实践提供了指南。模型中的 最佳实践关注于开发高质量产品与服务的活动,以满足客户与最终用户的 需要。 CMMI-DEV模型 1.3 版是生成自CMMI1.3 版架构与框架 1的、来自政府与 产业界的有关开发的最佳实践集合。CMMI开发模型基于CMMI模型基础 (CMMI Model Foundation)或简称CMF(即所有CMMI模型与群集 2共 同的模型组件)并纳入了开发组织的工作,以便使CMMI适合在产品与服 务的开发中使用。 许多杰出人士参与了 CMMI 产品套件 1.3 版的开发。三个主要的小组是 CMMI 指导小组,CMMI 产品团队与 CMMI 配置控制委员会(Configuration Control Board,CCB)。 指导小组指导并批准产品团队的计划,为重大的 CMMI 产品问题提供咨询 建议,并确保各种利害关系方的参与。 指导小组以向开发型组织提供最佳实践的重要性为认识,对开发群集的开 发工作进行监督。 产品团队编写、评审、修改、讨论包括框架、模型、培训与评估资料的 CMMI 产品套件的结构与技术内容并达成一致。开发活动基于多种输入。这些输 入包括一份 A-规格说明、由指导小组提供的每次发布的特定指南、源模型、 来自用户群体的变更请求、以及从试点与其他干系人处收到的输入。 1 CMMI 框架是将 CMMI 组件进行组织、并将其结合成为 CMMI 群集与模型的基本结构。 2 群集是 CMMI 组件的集合,用于构建所关心领域(如,开发、采购、服务等)的模型、培训资料以及评估相关的文档。 前言 i CMMI 开发模型,版本 1.3 CCB 是正式的机制,用于控制 CMMI 模型、评估相关文档与 CMMI 导论 培 训的变更。因此,该小组通过对所有提议的基线变更进行评审,并仅批准 那些能解决已识别问题、并满足下次发布准则的变更,来确保产品套件在 整个生命期内的完整性。 附件 C 列出了参与开发 CMMI-DEV 1.3 版的各小组成员。 受众 CMMI-DEV的受众包括处在开发环境中的任何对过程改进感兴趣的人员。 无论你熟知能力成熟度模型,或是正在寻求信息来开始改进你的开发过程, CMMI-DEV都会对你有所助益。该模型同样适用于想要使用一个参考模型 对其开发相关的过程进行评估 3的组织。 本文档的组织方式 本文档分为三个主要部分: • 第一部分:关于 CMMI 开发模型 • 第二部分:通用目标与通用实践以及过程域 • 第三部分:附录与术语表 第一部分:关于 CMMI 开发模型,分为五章: • 第一章:引言,提供 CMMI 与 CMMI 开发群集的概要观点、过程改进 的概念、以及用于过程改进的模型的历史与不同的过程改进途径。 • 第二章:过程域组件,描述CMMI开发模型过程域 4的所有组件。 • 第三章:合而为一,将所有模型组件组合起来,并解释成熟度级别与 能力等级的概念。 • 第四章:过程域之间的关系,提供对 CMMI-DEV 过程域的含义及相互 联系的深入看法。 • 第五章:使用 CMMI 模型,描述开发型组织采用并使用 CMMI 进行过 程改进的路径,以及进行基准比较的实践。 第二部分:通用目标与通用实践以及过程域,包含此 CMMI 模型中必需的 组件与期望的组件的全部,还含有相关的说明性的组件,包括子实践、注 释、实例与工作产品实例。 第二部分包含 23 个小节。第一小节包含通用目标与通用实践,剩下的 22 个小节中每一节阐述 CMMI-DEV 中的一个过程域。 为使这些过程域容易被找到,这些小节以过程域缩略语的字母顺序进行组 织。各小节包含对目标、最佳实践与实例的描述。 3 评估是指由经过培训的专业团队,使用参考模型(如 CMMI-DEV)作为确定强项与弱项的基础,对一个或多个过程所做的检 查。 4 过程域是指某一领域内的一组相关实践,当它们共同得到实施时,能满足一组对于在本领域作出改进较为重要的目标。这一 概念在第二章有详细描述。 ii 前言 CMMI 开发模型,版本 1.3 第三部分:附录与术语表,分为四小节: • 附录 A:参考资料,含有诸如报告、过程改进模型、行业标准、与 CMMI-DEV 相关的书籍等参考资料,用来查找文档化的信息源。 • 附录 B:缩略语,定义了模型中使用的缩略语。 • 附录 C:CMMI 版本 1.3 项目参加人员,包含参加 CMMI-DEV 1.3 版 开发的团队成员名单。 • 附录 D:术语表,定义了 CMMI-DEV 中使用的很多术语。 如何使用本文档 前言 无论你是过程改进的新手、CMMI 的新手,或者已经熟知 CMMI,第一部 分都能帮助你理解为何 CMMI-DEV 是你改进开发过程所要使用的模型。 新接触过程改进的读者 如果你刚刚开始接触过程改进或能力成熟度模型(Capability Maturity Model,CMM®),我们建议你先阅读第一章。第一章中包含了过程改进 的概述,解释了 CMMI 究竟是什么。 接着略读第二部分,包括通用目标与实践、特定目标与实践,以对模型中 包含的最佳实践的范围有大体了解。尤其注意各过程域开始的目的与简介 部分。 在第三部分,浏览附录 A 的参考资料,并选择你认为在接着使用 CMMI-DEV 之前值得阅读的额外资料。浏览缩略语与术语表,以对 CMMI 语言进行熟悉。然后,再回过去阅读第二部分的详细内容。 具备过程改进经验的读者 如果你是一位新接触 CMMI 的读者,但你拥有其它过程改进模型的经验, 如软件 CMM 或系统工程能力模型(即 EIA731),你会很快认识到它们在 结构与内容上的很多相似之处[EIA 2002a]。 我们建议你阅读第一部分来理解 CMMI 与其它过程改进模型的不同之处。 如果你有其它模型方面的经验,你或许要对先阅读哪些小节进行选择。阅 读第二部分时,可以找一下你已经使用过的模型中的最佳实践。通过识别 熟悉的资料,你会理解哪些内容是全新的,哪些是继承的,哪些是你已了 解的模型中的熟悉内容。 下一步,检查术语表,以理解有些术语同你已了解的过程改进模型中所使 用的有怎样的区别。虽然很多概念是重复的,但它们可能有不同的叫法。 熟知 CMMI 的读者 如果你之前阅读过或使用过 CMMI 模型,你会很快认出所讨论的 CMMI 概念与所描述的最佳实践。与以往一样,CMMI 产品团队为 1.3 版的发布 对 CMMI 所做的改进是由用户反馈驱动的。变更请求经过了慎重的考虑、 分析与实施。 在 CMMI-DEV1.3 版中,你预期能看到的一些重大改进有: • 对高成熟度过程域进行了重大的改进,以体现业界的最佳实践,改进 包括:将过程域“组织级创新与部署”(Organizational Innovation and Deployment, OID )更名 为“组织 级绩效 管理” ( Organizational Performance Management,OPM),并增加了一个新的特定目标与 几个新的特定实践。 iii CMMI 开发模型,版本 1.3 • 对模型架构进行了改进,简化对多个模型的使用。 • 对说明性的资料进行了改进,包括修改了工程类实践来体现产业界的 最佳实践,并增加了对使用敏捷方法的组织的指南。 • 改进了术语表中的定义与模型术语,以加强模型的清晰性、准确性与 易用性。 • 删除了 4 级与 5 级的通用目标与通用实践,并且取消了能力等级 4 级 与 5 级,以便将高成熟度适当专注于业务目标的达成之上。其实现可 通过将能力等级 1 级至 3 级应用于高成熟度过程域(原因分析与解决、 量化项目管理、组织级绩效管理与组织级过程性能)。 可访问 http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/以获取更完整详细 的改进列表。 其它信息与读者反馈 许多有关 CMMI 的信息来源罗列在附录 A 中,并发布在了 CMMI 网站 http://www.sei.cmu.edu/cmmi/。 欢迎提出对 CMMI 的改进建议。有关如何进行反馈,请见 CMMI 网站 http://www.sei.cmu.edu/cmmi/tools/cr/。有关 CMMI 的任何问题,都可发 送邮件至 cmmi-comments@sei.cmu.edu。 iv 前言 目录 CMMI 开发模型,版本 1.3 前言 ···········································································································i 目的 ············································································································ i 鸣谢 ············································································································ i 受众 ··········································································································· ii 本文档的组织方式·························································································· ii 如何使用本文档····························································································· iii 新接触过程改进的读者 ·····················································································iii 具备过程改进经验的读者 ··················································································iii 熟知 CMMI 的读者 ···························································································iii 其它信息与读者反馈 ······················································································· iv 第一部分 关于 CMMI 开发模型 ······················································ 1 1 引言 ·······································································································3 关于过程改进································································································ 3 关于能力成熟度模型······················································································· 4 CMMI 的演化历程 ·························································································· 5 CMMI 开发框架 ····························································································· 7 CMMI 开发模型 ····························································································· 7 2 过程域组件 ······························································································9 核心过程域与 CMMI 模型 ················································································ 9 必需的组件、期望的组件与说明性的组件 ···························································· 9 必需的组件 ···································································································· 9 期望的组件 ···································································································· 9 说明性的组件 ································································································· 9 与第二部分相关联的组件 ················································································10 过程域 ········································································································ 10 目的陈述 ····································································································· 11 简介 ··········································································································· 11 相关过程域 ·································································································· 11 特定目标 ····································································································· 11 通用目标 ····································································································· 11 特定目标与特定实践概要 ················································································ 12 特定实践 ····································································································· 12 工作产品实例 ······························································································· 12 子实践 ········································································································ 12 通用实践 ····································································································· 12 通用实践详细说明 ························································································· 12 附加部分 ····································································································· 13 支持的说明性组件 ·························································································13 注释 ··········································································································· 13 实例 ··········································································································· 13 参考 ··········································································································· 13 编号格式·····································································································14 排版规范·····································································································14 目录 v CMMI 开发模型,版本 1.3 3 合而为一 ······························································································· 19 理解级别·····································································································19 连续式表示法与阶段式表示法的结构 ·································································19 理解能力等级 ·······························································································21 能力等级 0 级:不完整级 ················································································ 22 能力等级 1 级:已执行级 ················································································ 22 能力等级 2 级:已管理级 ················································································ 22 能力等级 3 级:已定义级 ················································································ 22 能力等级的提高 ···························································································· 22 理解成熟度级别 ····························································································23 成熟度级别 1 级:初始级 ················································································ 24 成熟度级别 2 级:已管理级 ············································································· 24 成熟度级别 3 级:已定义级 ············································································· 24 成熟度级别 4 级:已量化管理级 ······································································· 24 成熟度级别 5 级:优化级 ················································································ 25 成熟度级别的提高 ························································································· 25 过程域 ·······································································································26 等价阶段式定级 ····························································································29 达成高成熟度 ·······························································································32 4 过程域之间的关系 ··················································································· 33 过程管理类 ··································································································33 过程管理类的基础过程域 ················································································ 33 过程管理类的高级过程域 ················································································ 35 项目管理类 ··································································································36 项目管理类的基础过程域 ················································································ 36 项目管理类的高级过程域 ················································································ 38 工程类 ·······································································································39 工程类过程的递归与迭代 ················································································41 支持类 ·······································································································42 支持类的基础过程域 ······················································································ 42 支持类的高级过程域 ······················································································ 43 5 使用 CMMI 模型 ······················································································ 45 采用 CMMI ··································································································45 你的过程改进项目 ·························································································46 影响项目的选择 ····························································································46 CMMI 模型 ··································································································46 使用敏捷方法时对 CMMI 的解读·······································································47 使用 CMMI 评估 ···························································································47 CMMI 评估需求 ····························································································48 SCAMPI 评估方法·························································································48 评估方面的考虑 ····························································································49 CMMI 的相关培训 ·························································································49 第二部分 通用目标与通用实践以及过程域 ····································· 51 通用目标与通用实践 ··················································································· 53 概述 ··········································································································53 过程制度化 ··································································································53 已执行的过程 ······························································································· 53 vi 目录 CMMI 开发模型,版本 1.3 已管理的过程 ······························································································· 53 已定义的过程 ······························································································· 54 过程之间的关系 ···························································································· 54 通用目标与通用实践 ······················································································55 通用实践的应用 ····························································································98 支持通用实践的过程域 ···················································································99 原因分析与解决(CAR)··········································································· 103 配置管理(CM) ····················································································· 111 决策分析与解决(DAR)··········································································· 121 集成项目管理(IPM)··············································································· 129 度量与分析(MA)··················································································· 143 组织级过程定义(OPD) ·········································································· 157 组织级过程关注(OPF) ··········································································· 167 组织级绩效管理(OPM) ·········································································· 177 组织级过程性能(OPP)··········································································· 191 组织级培训(OT) ··················································································· 201 产品集成(PI) ······················································································· 211 项目监督与控制(PMC) ·········································································· 223 项目计划(PP) ······················································································ 231 过程与产品质量保证(PPQA)··································································· 249 量化项目管理(QPM) ············································································· 255 需求开发(RD) ······················································································ 269 需求管理(REQM) ················································································· 283 风险管理(RSKM) ················································································· 289 供方协议管理(SAM)·············································································· 301 技术解决方案(TS) ················································································ 311 确认(VAL) ·························································································· 327 验证(VER) ·························································································· 335 第三部分 附录 ········································································ 345 附录 A:参考资料 ···················································································· 347 附录 B:缩略语 ······················································································· 353 附录 C:CMMI 版本 1.3 项目参加人员·························································· 359 附录 D:术语表 ······················································································· 367 目录 vii CMMI 开发模型,版本 1.3 viii 目录 CMMI 开发模型,版本 1.3 第一部分 关于 CMMI 开发模型 1 CMMI 开发模型,版本 1.3 2 1 引言 CMMI 开发模型,版本 1.3 关于过程改进 如今,更好、更快、更经济地交付产品与服务,是众多公司比以往任何时 候都梦寐以求的愿望。同时,在 21 世纪的高科技环境里,几乎所有组织 都意识到他们所开发的产品与服务正变得日益复杂。而复杂产品或服务的 所有组件由单个组织包揽开发的情况日渐稀有。更为常见的是,一些组件 在内部开发而另一些组件则对外采购;其后再将所有组件集成起来,成为 最终产品或服务。对如此复杂的开发与维护过程,组织必定要有能力进行 管理并控制。 如今要应对这些组织所面临的问题,所需要的是一些企业整体的解决方案, 而与其相得益彰的,则是一条集成化的途径。有效的组织级资产管理是业 务成功的关键。究其本质,这些组织固然是产品与服务的开发者,而开发 活动仍然需要一种管理方式,以此作为达成其业务目标的有机组成。 纵观当今之业界,既有各式成熟度模型、标准、方法论和指南等,自然可 以帮助组织改进其经营方式。然而,现有的改进方法大多只关注于业务的 某一特定部分,而非采用系统化途径来解决众多组织所面临的问题。囿于 其仅对业务单一领域进行改进的事实,这些模型均不幸延续了组织中既存 的隔阂与障碍。 CMMI 开发模型(CMMI® for Development,CMMI-DEV)带来了机会, 让我们避免或消除这些隔阂与障碍。构成 CMMI 开发模型的,是在产品与 服务的开发活动中处理问题的最佳实践。模型所提出的实践,涵盖了产品 从概念构想直至交付与维护的整个生命周期,所突出的重点是构建并维护 整个产品所需从事的工作。 CMMI开发模型包括 22 个过程域。在这些过程域中,有 16 个核心过程域, 1 个共享过程域 5,以及 5 个开发活动所特有的过程域。 CMMI 开发模型全部实践所关注的,是开发者组织之中的活动。五个关注 于开发活动特有实践的过程域,所应对的是:需求开发、技术解决方案、 产品集成、验证和确认。 软件工程研究所(Software Engineering Institute,SEI)就促进组织如何 开发并维护高质量产品与服务展开研究,并认为组织改进业务的关注点可 集中在几个方面。图 1.1 展示了组织典型关注的三个重要方面:人员、规 程与方法、以及工具与设备。 5 核心过程域是指所有 CMMI 模型共同具备的过程域。共享过程域是指被至少两个 CMMI 模型、但不是所有模型所共享。 引言 3 CMMI 开发模型,版本 1.3 定义了任务之间关系 的规程与方法 B A D C 具备技能 受到培训 拥有干劲 的人员 过程 工具与 设备 图 1.1 三个重要方面 将这些结合到一起的是什么?那就是组织中所使用的过程。过程使业务方 式协调一致;过程支撑业务的规模化发展与术业精进的知识整合;过程还 促进资源的有效利用与对业务趋势的把握。 这并不是说人员与技术无关紧要。我们身处的时代是技术飞速发展的时代。 类似地,人们的职业生涯往往也要经历许多公司。我们就生活在这样一个 日新月异的世界。对过程的关注为我们提供了必需的基础与稳定性,来应 对变化莫测的世界,最大化人们的生产力,并运用技术赢得竞争优势。 长期以来,制造业便意识到了过程有效性与效率的重要性。如今,制造业 同服务业的很多组织更意识到了高质量过程的重要性。过程有助于组织的 员工以更具智慧的、更为一致的工作方式去满足业务目标,而不是只会埋 头苦干。有效的过程还提供了一种手段,便于组织以最能满足其业务目标 的方式来引进并使用新技术。 关于能力成熟度模型 能力成熟度模型(Capability Maturity Model®,CMM®),包括 CMMI, 都是对现实世界的简化表述。能力成熟度模型包含了有效过程的基础元 素。这些元素建立在 Crosby、Deming、Juran 与 Humphrey 等人发展出 的概念的基础之上。 在 20 世纪三十年代,Walter Shewhart 开始用他的统计质量管理原理从事 过程改进工作[Shewhart 1931]。这些原理由 W. Edwards Deming [Deming 1986],Phillip Crosby[Crosby 1979]与 Joseph Juran[Juran 1988]进行了提炼。Watts Humphrey,Ron Radice 与其他人又进一步扩 展了这些原理,并在 IBM(International Business Machines,国际商用机器公 司)与 SEI 的工作中将这些原理应用到了软件领域[Humphrey 1989]。 Humphrey 的著作《Managing the Software Process(管理软件过程)》 所 描 述 的 基 本 原 理 与 概 念 则 成 为 众 多 能 力 成 熟 度 模 型 ® ( Capability Maturity Models®,CMMs®)的基础。 4 引言 CMMI 开发模型,版本 1.3 SEI 采纳了过程管理的假设前提,即“系统或产品的质量很大程度上受影 响于所使用的开发与维护过程的质量”,并定义了体现这一前提的多个 CMM。我们可以在全球的质量运动中看到对这一前提的信仰,并在国际标 准 化 组 织 / 国 际 电 工 委 员 会 ( International Organization for Standardization/International Electrotechnical Commission, ISO/IEC) 的系列标准中得到印证。 CMM 关注于改进组织内部的过程,所包含的是单学科或多学科的有效过 程的基础元素,描述了从随意、不成熟的过程到提高了质量与有效性的、 有秩序、成熟的过程的演进道路。 同其它 CMM 类似,CMMI 模型给出了制订过程所使用的指南。CMMI 模 型并非过程或过程描述。组织实际使用的过程取决于很多因素,包括应用 领域以及组织架构与规模。尤其是,CMMI 模型的过程域与组织使用的过 程往往并非一一对应。 SEI 创建的第一个 CMM 模型面向软件组织而设计,并成书出版,题为《The Capability Maturity Model: Guidelines for Improving the Software Process (能力成熟度模型:软件过程改进指南)》[SEI 1995]。 如今的 CMMI 所应用的,是在近一个世纪前就已被引入至永无止境的过程 改进循环中的原理。这一过程改进方法的价值得到了时间的检验。很多组 织都经历了生产率的增长、质量的提升、周期时间的改进,并且进度与预 算变得更为准确并可预测[Gibson 2006]。 CMMI 的演化历程 CMM 集成(CMM Integration®)这一项目的建立就是为了解决使用多个 CMM 的问题。选择模型并组合成单一的改进框架,其初衷是给从事企业 级过程改进的组织使用。 开发一套集成的模型不仅仅是简单地把现有的模型资料组合在一起。 CMMI 产品团队采用了促进达成共识的过程,构建出一个可以容纳多个群 集的框架。 首个开发出的模型是 CMMI 开发模型(当时被简单称为“CMMI”)。图 1.2 展示了演化至 CMMI1.3 版本的各个源模型。 引言 5 CMMI 开发模型,版本 1.3 CMM 的历史 软件 CMM 1.1 版(1993) INCOSE SECAM (1996) 系统工程 CMM 1.1 版(1995) 软件 CMM 2.0 版 草稿 C(1997) 软件采购 CMM 1.03 版(2002) EIA 731 SECM (1998) 集成产品开发 CMM (1997) CMMI 采购模型 1.2 版(2007) 1.02v1版.0(22(020000)0) 1.1v1版.1((22000022)) CMMI 开发模型 1.2 版 (2006) CMMI 服务模型 1.2 版 (2009) CMMI 采购模型 1.3 版(2010) CMMI 开发模型 1.3 版(2010) CMMI 服务模型 1.3 版(2010) 图 1.2:CMM的历史 6 最初,CMMI 是一个结合了以下三个源模型的模型:软件能力成熟度模型 (Capability Maturity Model for Software,SW-CMM)2.0 版草稿 C,系 统工程能力模型(Systems Engineering Capability Model,SECM)[EIA 2002a ] , 和 集 成 产 品 开 发 能 力 成 熟 度 模 型 ( Integrated Product Development Capability Maturity Model,IPD-CMM)0.98 版。 选择以上三个源模型是由于它们在组织中的成功应用或者是它们采用的 过程改进方法具有前景。 第一个 CMMI 模型(1.02 版)设计给从事企业级过程改进的开发型组织使 用。它于 2000 年发布。两年后 1.1 版发布,又过了四年 1.2 版发布。 到发布 1.2 版时,另外两个 CMMI 模型又处在了酝酿之中。由于此次计划 中的扩增,第一个 CMMI 模型的名称需要进行改变,成为了 CMMI 开发模 型,群集的概念也自此产生。 6 EIA 731 SECM 是电子工业协会标准 731,或系统工程能力模型。INCOSE SECAM 是国际系统工程协会系统工程能力评估 模型[EIA 2002 a]。 6 引言 CMMI 开发框架 CMMI 开发模型 CMMI 开发模型,版本 1.3 CMMI 采购模型于 2007 年发布。由于它建立在 CMMI 开发模型 1.2 版的 基础之上,因而也被命名为 1.2 版。两年后,CMMI 服务模型发布。它建 立在另外两个模型基础之上,并且也被命名为 1.2 版。 2008 年开始计划制订 1.3 版,以确保三个模型之间的一致性,并改进所有 模型中高成熟度的资料。1.3 版的 CMMI 采购模型[Gallagher 2011,SEI 2010b]、CMMI 开发模型[Chrissis 2011]和 CMMI 服务模型[Forrester 2011,SEI 2010a]于 2010 年 11 月发布。 CMMI 框架给出了所需的结构,用来生成 CMMI 模型、培训与评估等组件。 为允许在 CMMI 框架中使用多个模型,模型组件又进行了分类,分为通用 于所有 CMMI 模型的组件或适用于某个特定模型的组件。通用资料被称为 “CMMI 模型基础(CMMI Model Foundation)”或称“CMF”。 CMF 的组件同时也是基于此框架生成的每个模型的组成部分。这些组件与 适用于所关注领域(如:采购、开发、服务)的资料结合,就形成一个模 型。 这样的 CMMI 组件的集合就定义为一个群集:这些组件用于构建针对所关 注领域(例如采购、开发、服务)的模型、培训材料和评估相关文档。开 发群集的模型被称为“CMMI 开发模型”或“CMMI-DEV”。 CMMI 开发模型是一个参考模型,涵盖了开发产品与服务的活动。来自很 多行业的组织,包括航空航天、银行、计算机硬件、软件、国防、汽车制 造与电信等,都使用 CMMI 开发模型。 CMMI 开发模型所包含的实践覆盖了项目管理、过程管理、系统工程、硬 件工程、软件工程与其它用于开发与维护的支持过程。 应使用专业判断与常识来为组织解读模型。也就是说,尽管模型描述的过 程域刻画了被多数用户视为最佳实践的行为,仍应结合深入的 CMMI-DEV 知识、组织的约束与业务环境来解读过程域与实践。 引言 7 CMMI 开发模型,版本 1.3 8 引言 2 过程域组件 CMMI 开发模型,版本 1.3 本章将描述各过程域、通用目标及通用实践的组件。了解这些组件内容对 有效使用第二部分的资料来说十分重要。如果对第二部分还不熟悉,你可 以在阅读本章之前先简单浏览一下通用目标与通用实践小节以及几个过 程域小节,以便对其内容与布局有大致了解。 核心过程域与 CMMI 模型 所有的 CMMI 模型都生成自 CMMI 框架。该框架包括了所有的目标与实践, 用以生成属于 CMMI 群集的 CMMI 模型。 所有的 CMMI 模型都包含 16 个核心过程域。这些过程域论及的基本概念 对任一关注领域(即采购、开发、服务)的过程改进来说都是基础。核心 过程域中的有些资料在所有群集中内容相同。而另一些资料的内容可能会 有所调整,来应对特定的关注领域。因此,核心过程域的资料可能并不完 全相同。 必需的组件、期望的组件与说明性的组件 模型组件被分为三类——必需的、期望的与说明性的——这种分类体现了 应如何对它们进行解读。 必需的组件 必需的组件是在给定过程域中对实现过程改进来说必不可少的 CMMI 组件。 这样的成果必须在组织的过程中以可视的方式得到落实。在 CMMI 中,必 需的组件是特定目标与通用目标。在评估中,采用目标满足度作为决定某 个过程域是否得到满足的基础。 期望的组件 期望的组件是描述了实现必需的 CMMI 组件的重要活动的 CMMI 组件。期 望的组件指导那些实施改进或执行评估的人员。在 CMMI 中,期望的组件 是特定实践与通用实践。 在目标被认为得到满足之前,所描述的实践或其可接受的备选,必须在组 织已计划并实施的过程中得到体现。 说明性的组件 说明性的组件是帮助模型用户理解 CMMI 必需的组件与期望的组件的 CMMI 组件。这些组件可以是实例框、详细解释或其它有用信息。子实践、 注释、参考、目标标题、实践标题、来源、工作产品实例以及通用实践详 细说明都是说明性的模型组件。 说明性资料在理解模型时扮演重要的角色。仅仅使用一句目标或实践陈述 来充分描述组织必需的或期望的行为往往是不可能的。模型的说明性资料 提供了必要信息,以达到对目标与实践的正确理解,因此不可以忽略。 过程域组件 9 CMMI 开发模型,版本 1.3 与第二部分相关联的组件 与第二部分相关联的模型组件的关系总结如图 2.1 过程域 目的陈述 简介 相关过程域 Sp特ec定ific目Go标als Ge通ne用ric目Go标als Spe特cif定ic P实ra践ctices 工T作ypi产ca品l W实or例k Products Su子bp实rac践tices Ge通ner用ic P实ra践ctices S子ubp实ra践ctices 通用实践 S详ub细pr说ac明tices 图示: 必需的 期望的 说In明fo性rm的ative 图 2.1:CMMI 模型组件 以下小节给出了 CMMI 模型组件的详细描述。 过程域 过程域是某一领域内的一组相关实践,当它们共同得到实施时,能满足一 组对于在本领域作出改进较为重要的目标。(见术语表中“过程域”的定 义。) 22 个过程域按字母顺序排列如下: • 原因分析与解决(Causal Analysis and Resolution:CAR) • 配置管理(Configuration Management:CM) • 决策分析与解决(Decision Analysis and Resolution:DAR) • 集成项目管理(Integrated Project Management:IPM) • 度量与分析(Measurement and Analysis:MA) • 组织级过程定义(Organizational Process Definition:OPD) • 组织级过程关注(Organizational Process Focus:OPF) • 组织级绩效管理(Organizational Performance Management:OPM) • 组织级过程性能(Organizational Process Performance:OPP) • 组织级培训(Organizational Training:OT) • 产品集成(Product Integration:PI) • 项目监督与控制(Project Monitoring and Control:PMC) • 项目计划(Project Planning:PP) • 过程与产品质量保证(Process and Product Quality Assurance:PPQA) • 量化项目管理(Quantitative Project Management:QPM) 10 过程域组件 CMMI 开发模型,版本 1.3 • 需求开发(Requirements Development:RD) • 需求管理(Requirements Management:REQM) • 风险管理(Risk Management:RSKM) • 供方协议管理(Supplier Agreement Management:SAM) • 技术解决方案(Technical Solution:TS) • 确认(Validation:VAL) • 验证(Verification:VER) 目的陈述 目的陈述描述了过程域的目的,属于说明性的组件。 例如,“组织级过程定义”过程域的目的陈述是“组织级过程定义 (Organizational Process Definition,OPD)的目的在于建立并维护一套 可用的组织级过程资产、工作环境标准以及团队规则与指南。” 简介 过程域的简介小节描述了过程域所涉及的主要概念,属于说明性的组件。 例如,“项目监督与控制”过程域的简介中写道“当实际状态与预期情况 显著偏离时,就要酌情采取纠正措施。” 相关过程域 相关过程域小节列出了至相关过程域的引用,反映过程域之间高层次的关 系。相关过程域小节属于说明性的组件。 例如,“项目计划”过程域的相关过程域小节中的一条引用是“参阅‘风 险管理’过程域以以进一步了解如何识别、分析并缓解风险。” 特定目标 特定目标描述了为满足过程域而必须呈现出的独特特征。特定目标属于必 需的模型组件,并在评估中用于帮助确定过程域是否得到满足。(见术语 表中“特定目标”的定义。) 例如,“配置管理”过程域中的一个特定目标是“基线的完整性得到建立 与维护。” 只有特定目标陈述才是必需的模型组件。特定目标的标题(前面标有目标 编号)以及与目标相关联的注释则被视为说明性的模型组件。 通用目标 通用目标之所以被称为“通用”,是因为同样的目标陈述适用于多个过程 域。通用目标描述了把某一过程域相关过程制度化所必须呈现的特征。通 用目标属于必需的模型组件,并在评估中用于确定过程域是否得到满足。 (更多有关通用目标的详细描述,请见第二部分的“通用目标与通用实践” 小节。见术语表中“通用目标”的定义。) 通用目标的一个实例是“过程得到制度化为已定义的过程。” 只有通用目标陈述才是必需的模型组件。通用目标的标题(前面标有目标 编号)以及与目标相关联的注释则被视为说明性的模型组件。 过程域组件 11 CMMI 开发模型,版本 1.3 特定目标与特定实践概要 特定目标与特定实践概要提供了对特定目标与特定实践的高层次的总结。 特定目标与特定实践概要属于说明性的组件。 特定实践 特定实践是对活动的描述,该活动被认为在达成所关联的特定目标方面具 有重要性。特定实践描述活动,这些活动预期带来在过程域的特定目标的 达成。特定实践属于期望的模型组件。(见术语表中“特定实践”的定义。) 例如,“项目监督与控制”过程域中的一条特定实践是“对照项目计划, 监督所识别的承诺。” 只有特定实践陈述才是期望的模型组件。特定实践的标题(前面标有实践 编号)以及与特定实践相关联的注释则被视为说明性的模型组件。 工作产品实例 工作产品实例列出了特定实践的输出例子。工作产品实例属于说明性的模 型组件。(见术语表中“工作产品实例”的定义。) 例如,“项目监督与控制”过程域中“监督项目计划参数”特定实践的一 个工作产品实例是“重大偏差记录”。 子实践 子实践是为解释和实施特定实践或通用实践提供指导的详细描述。子实践 的措辞可能会让人感觉是规定的作法,不过它们实际仅旨在为过程改进提 供可能有用的思路。(见术语表中“子实践”的定义。) 例如,“项目监督与控制”过程域中“采取纠正措施”特定实践的一个子 实践是“确定所需的适当措施并将其文档化,以处理已识别的问题。” 通用实践 通用实践之所以被称为“通用”,是因为相同的实践适用于多个过程域。 与通用目标相关联的通用实践描述了一些活动,这些活动被认为对通用目 标的达成具有重要意义,并且有助于过程域所关联过程的制度化。通用实 践属于期望的模型组件。(见术语表中“通用实践”的定义。) 例如,“过程得到制度化为已管理的过程”通用目标中的一条通用实践是 “提供充分的资源,以执行过程、开发工作产品并提供过程的服务。” 只有通用实践陈述才是期望的模型组件。通用实践的标题(前面标有实践 编号)以及与实践相关联的注释则被视为说明性的模型组件。 通用实践详细说明 通用实践详细说明出现在通用实践之后,为该通用实践在某一过程域的特 定应用提供指导。通用实践详细说明属于说明性的模型组件。(见术语表 中“通用实践详细说明”的定义。) 例如,“项目计划”过程域中“建立并维护组织级方针,以计划并执行过 程”通用实践的详细说明是“要估算计划的参数,做出内部的与外部的承 诺,并且制订管理项目的计划。为此,本方针建立了组织级期望。” 12 过程域组件 CMMI 开发模型,版本 1.3 附加部分 附加部分是得到明确标记的模型组件,它含有特定用户所关心的信息。附 加部分可以是说明性的资料、特定实践、特定目标或整个过程域,它延伸 了模型的范围或突出了其使用上的某一特别的方面。在 CMMI 开发模型中 不存在附加部分。 支持的说明性组件 在模型中,有很多地方需要进一步的信息来描述某个概念。此类说明性的 资料通过以下组件的形式进行提供: • 注释 • 实例 • 参考 注释 注释是可以伴随几乎任何其它模型组件出现的文本。它能提供详情、背景 或依据。注释属于说明性的模型组件。 例如,伴随“原因分析与解决”过程域中“实施行动提议”特定实践出现 的注释是“只有那些经证明有价值的变更才应该被考虑广泛实施。”。 实例 实例由文本与一列条目组成,往往置于文本框中,可以伴随几乎任何其它 组件出现。实例提供了一个或多个例子来澄清某个概念或所描述的活动。 实例属于说明性的模型组件。 下面是伴随“过程与产品质量保证”过程域中“沟通并确保不符合问题的 解决”特定实践下的“当不符合问题在项目内不能得到解决时,将其文档 化”子实践出现的实例。 项目内解决不符合问题的方法的实例有: • 修正不符合问题 • 变更所违反的过程描述、标准或规程 • 获得豁免以放行不符合问题 参考 参考指向相关过程域中额外的或更为详细的信息。它能够伴随几乎任何其 它模型组件出现。参考属于说明性的模型组件。(见术语表中“参考”的 定义。) 例如,伴随“量化项目管理”过程域中“组成已定义的过程”特定实践出 现的参考有“参阅‘组织级过程定义’过程域以进一步了解如何建立组织 级过程资产。” 过程域组件 13 CMMI 开发模型,版本 1.3 编号格式 特定目标与通用目标都是依次连续编号。每个特定目标以前缀 SG 开头(如 SG 1)。每个通用目标以前缀 GG 开头(如 GG 2)。 特定实践与通用实践同样也是依次连续编号。每个特定实践以前缀 SP 开 头,紧接便是以 x.y 形式排列的编号(如 SP 1.1)。x 与该实践对应的目 标编号相同。y 则是该特定目标下特定实践的序号。 以“项目计划”过程域下的特定实践的编号为例,第一条特定实践的编号 是 SP 1.1,第二条则是 SP 1.2。 每个通用实践以前缀 GP 开头,紧接便是 x.y 形式排列的编号(如 GP 1.1)。 x 与通用目标编号相对应。y 则是该通用目标下通用实践的序号。例如,与 GG 2 相关联的第一条通用实践编号是 GP 2.1,第二条则是 GP 2.2。 排版规范 本模型中使用的排版规范的设计使你能够轻易识别并选择模型组件,其格 式安排使你能够快速找到页面上的模型组件。 图 2.2,2.3 与 2.4 是从第二部分的过程域中选择的样例页面;它们展示了 不同的过程域组件,并加以标签以易于识别。需要注意的是,为方便识别, 各种组件都使用不同的排版方式。 14 过程域组件 CMMI 开发模型,版本 1.3 图 2.2:DAR 过程域样例页面 过程域组件 15 CMMI 开发模型,版本 1.3 图 2.3:CAR 过程域样例页面 16 过程域组件 CMMI 开发模型,版本 1.3 图 2.4:通用目标与通用实践样例页面 过程域组件 17 CMMI 开发模型,版本 1.3 18 过程域组件 3 合而为一 CMMI 开发模型,版本 1.3 在对 CMMI 模型的组件有所了解之后,还需要理解这些组件是如何组合在 一起来满足过程改进的需要。本章会介绍级别的概念,并展示如何组织并 使用过程域。 CMMI 开发模型并不规定项目或组织必须遵循特定的过程顺序,或每天必 须开发出一定数量的产品,或必须达成特定的绩效指标。模型所规定的是 项目或组织应该具备应对开发相关实践的过程。项目或组织可将其过程映 射至本模型中的过程域,以确定这些过程是否具备。 过程至过程域的映射使组织能够对照 CMMI 开发模型来追踪组织进行过程 更新或创建时的进展。但不要期望 CMMI 开发模型中的每一个过程域能够 一一对应至组织或项目的过程。 理解级别 CMMI开发模型推荐使用渐进的路径供组织改进其开发产品或服务的过程, 并采用级别来描述这一渐进的路径。级别也可以是评估 7中评定活动的结 果。评估可应用于整个组织或小一些的组,如一组项目或一个部门。 CMMI 支持两种使用级别的改进路径。一条路径使组织能够逐步改进其选 定的单个过程域(或一组过程域)所对应的过程。另一条路径使组织能够 以增量方式应对层次相继的过程域集合来改进相关的过程集。 这两种改进路径与两种类型的级别相关联:能力等级与成熟度级别。这些 等级或级别对应至两种过程改进方法,称作“表示法”。这两种表示法被 称为“连续式”与“阶段式”。使用连续式表示法使你能够达成“能力等 级”。使用阶段式表示法使你能够达成“成熟度级别”。 为达到某一特定的级别,不管是能力等级或成熟度级别,组织都必须满足 预定进行改进的过程域或过程域集合中的所有目标。 这两种表示法都能够提供对过程进行改进的方式,以达成业务目标,两者 也都提供了相同的要素,并使用相同的模型组件。 连续式表示法与阶段式表示法的结构 图 3.1 展示了连续式表示法与阶段式表示法的结构。这两种结构之间的区 别微妙却重大。阶段式表示法相对于模型整体,使用成熟度级别来描述组 织过程总体状态的特征;而连续式表示法则相对于单个过程域,使用能力 等级来描述组织过程状态的特征。 7 参阅 CMMI 评估需求(Appraisal Requirements for CMMI)与过程改进的标准 CMMI 评估方法(Standard CMMI Appraisal Method for Process Improvement)的方法定义文档,以对评估有进一步的了解[SEI 2011a,SEI 2011b]。 合而为一 19 CMMI 开发模型,版本 1.3 连续式表示法 过程域 特定目标 通用目标 能力等级 特定实践 通用实践 阶段式表示法 过程域 成熟度级别 特定目标 通用目标 特定实践 通用实践 图 3.1:连续式表示法与阶段式表示法的结构 比较这两种表示法,其相似性可能令你印象深刻。两者有很多相同的组件 (如:过程域、特定目标、特定实践等),并且这些组件拥有相同的层级 与配置。 从图 3.1 的概要视图中不能立即清楚了解的是,连续式表示法的关注点在 于由能力等级度量的过程域能力,而阶段式表示法的关注点在于由成熟度 级别度量的总体成熟度。CMMI 的这一尺度(能力/成熟度尺度)被用于 基准比较与评估活动,并且用于指导组织的改进工作。 能力等级适用于组织在单个过程域的过程改进达成情况。这些等级作为一 种手段,增量式地改进与给定过程域相对应的过程。四个能力等级用数字 0 至 3 进行编号。 成熟度级别适用于组织内横跨多个过程域的过程改进达成情况。这些级别 作为一种手段,改进与一组给定过程域相对应的过程(即成熟度级别)。 五个成熟度级别用数字 1 至 5 进行编号。 20 合而为一 理解能力等级 CMMI 开发模型,版本 1.3 表 3.1 将四个能力等级与五个成熟度级别进行对比。注意在两种表示法中, 有两个等级的名称是相同的(即已管理级与已定义级)。区别在于不存在 成熟度级别 0 级、没有能力等级 4 级或 5 级;另外在 1 级时,能力等级 1 级与成熟度级别 1 级所使用的名称不同。 表 3.1 能力等级与成熟度级别的对比 级别 连续式表示法 能力等级 阶段式表示法 成熟度级别 0级 不完整级 1级 已执行级 初始级 2级 已管理级 已管理级 3级 已定义级 已定义级 4级 已量化管理级 5级 持续优化级 连续式表示法涉及选择一个特定的过程域进行改进,以及确定对这个过程 域预期达到的能力等级。在这种情况下,过程已得到执行或仍不完整,这 一点是重要的。因此,采用名称“不完整级”作为连续式表示法的起点。 阶段式表示法涉及选择某一成熟度级别下的多个过程域进行改进;单个过 程已得到执行或仍不完整就不是首要关注点。因此,采用名称“初始级” 作为阶段式表示法的起点。 能力等级与成熟度级别都提供了一种改进组织过程的方式,并对组织能够 并切实改进其过程的程度进行度量。然而,与过程改进相关联的途径却有 所不同。 为支持对连续式表示法的使用,所有的 CMMI 模型在其设计与内容方面都 体现了能力等级。 四个能力等级定名为 0 级至 3 级,每一级是一个层次,作为继续进行过程 改进的基础。 0. 不完整级 1. 已执行级 2. 已管理级 3. 已定义级 当某等级下的所有通用目标都得到满足时,过程域的该能力等级就被达成。 事实上,能力等级 2 级与 3 级使用的名称和通用目标 2 与通用目标 3 相同 是有意为之,因为这些通用目标与实践的每一条都反映了目标与实践的能 力等级的意义。(参阅第二部分的“通用目标与通用实践”章节以进一步 了解通用目标与通用实践。)对每一能力等级的简短描述如下。 合而为一 21 CMMI 开发模型,版本 1.3 能力等级 0 级:不完整级 不完整的过程是没有得到执行或部分得到执行的过程。过程域的一个或多 个特定目标没有得到满足,并且该等级下通用目标也不具备,这是因为没 有理由对一个部分执行的过程进行制度化。 能力等级 1 级:已执行级 能力等级 1 级的过程被描述为已执行的过程。已执行的过程是完成所需工 作而产生工作产品的过程;过程域的特定目标得到满足。 尽管能力等级 1 级会取得重要改进,但如果未得到制度化,那些改进经过 一段时间后可能会丢失。利用制度化(CMMI 能力等级 2 级与 3 级的通用 实践)有助于确保改进得以保持。 能力等级 2 级:已管理级 能力等级 2 级的过程被描述为已管理的过程。已管理的过程是一种已执行 的过程,这种过程按照方针得到计划和执行;雇用有技能的人,具备充分 的资源以产生受控的输出;使相关干系人参与其中;得到监督、控制与评 审;并且对其过程描述的遵守程度得到评价。 能力等级 2 级所体现的过程规范有助于确保现有实践在有压力的情况下得 以保留。 能力等级 3 级:已定义级 能力等级 3 级的过程被描述为已定义的过程。已定义的过程是一种已管理 的过程,这种过程按照组织的裁剪指南,从组织的标准过程集中裁剪得到; 它具有受维护的过程描述;并且将过程相关经验贡献给组织级过程资产。 能力等级 2 级与 3 级之间的关键区别在于标准、过程描述与规程的范围。 在能力等级 2 级中,标准、过程描述与规程在过程的每个特定实例中(如 在某一特定项目中)都可能有很大的不同。在能力等级 3 级中,项目的标 准、过程描述与规程是从组织的标准过程集中裁剪得来,以适应特定的项 目或组织级单位,因而就更为一致,除非是裁剪指南所允许的差别。 另一关键区别在于能力等级 3 级的过程描述往往比能力等级 2 级更为严谨。 已定义的过程清晰地陈述了目的、输入、入口准则、活动、角色、度量项、 验证步骤、输出与出口准则。在能力等级 3 级中,通过使用对过程活动之 间相互关系的理解,并使用过程及其工作产品的详细度量项,过程得到了 更为积极的管理。 能力等级的提高 过程域的能力等级的达成通过应用了通用实践、或应用了与过程域相关联 过程的合适替代实践来实现。 达到过程域的能力等级 1 级等同于说与该过程域相关联的过程是已执行的 过程。 22 合而为一 CMMI 开发模型,版本 1.3 达到过程域的能力等级 2 级等同于说具备方针表明将执行过程。具备执行 的计划,资源得到了提供,职责得到了分派,执行过程的培训得到了提供, 与执行过程相关的所选工作产品得到了控制,等等。换而言之,能力等级 2 级的过程能够如同任何项目或支持活动那样得到计划与监督。 达到过程域的能力等级 3 级等同于说存在与该过程域相关联的组织级标准 过程,该过程可根据项目的需要被裁剪。组织内的过程现在得到了更为一 致的定义与应用,因为它们的基础都是组织级标准过程。 组织在其选定进行改进的过程域达到能力等级 3 级之后,可以继续其改进 旅程来应对高成熟度过程域(组织级过程性能,量化项目管理,原因分析 与解决与组织级绩效管理)。 高成熟度过程域关注于改进那些已实施过程的性能。高成熟度过程域描述 了使用统计与其它量化技术来改进组织级过程与项目过程,以便更好达成 业务目标。 当组织以这种方式继续其改进旅程时,能够通过首先选择 OPP 与 QPM 过 程域来获得最大收益,并将这些过程域带到能力等级 1 级,2 级与 3 级。 这样,项目与组织能够将过程的选择和分析与其业务目标更加紧密地保持 一致。 在 OPP 与 QPM 过程域达到能力等级 3 级之后,组织能够选择 CAR 与 OPM 过程域来继续其改进道路。这样,组织能够使用统计与其它量化技术来分 析业务绩效以确定性能方面的不足,并识别与部署有助于满足质量与过程 性能目标的过程改进与技术改进。项目与组织使用原因分析来识别并解决 影响性能的问题,并且促进最佳实践的传播。 理解成熟度级别 为支持对阶段式表示法的使用,所有的 CMMI 模型在其设计与内容方面都 体现了成熟度级别。成熟度级别由可改进组织整体绩效的、预先定义好的 过程域集合中相关的特定实践与通用实践组成。 组织的成熟度级别提供了描述其绩效特征的方式。经验表明,当组织每次 过程改进工作所专注的过程域在数量上易管理时,组织能够做到最好;那 些领域随着组织的改进,也需要不断成熟。 成熟度级别是组织级过程改进的预定义的演进平台。每一个成熟度级别使 组织过程中重要的子集合成熟,并为其走向下一个成熟度级别做准备。成 熟度级别通过与预先定义好的过程域集合相关联的特定目标与通用目标 的达成情况进行度量。 五个成熟度级别定名为 1 级至 5 级,每一级是一个层次,作为继续进行的 过程改进的基础。 1. 初始级 2. 已管理级 3. 已定义级 4. 已量化管理级 5. 持续优化级 合而为一 23 CMMI 开发模型,版本 1.3 记住成熟度级别 2 级与 3 级使用和能力等级 2 级与 3 级相同的名称。这种 名称上的一致性是有意而为之,因为成熟度级别与能力等级的概念是互补 的。成熟度级别被用于描述相对于一个过程域集合的组织级改进特征,而 能力等级被用于描述相对于单个过程域的组织级改进特征。 成熟度级别 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 级,组织与项目建立了质量与过程性能的量化目标并将其 用作管理项目的准则。量化目标基于客户、最终用户、组织、过程实施人 24 合而为一 合而为一 CMMI 开发模型,版本 1.3 员的需要。质量与过程性能以统计术语的形式得到理解,并在项目的整个 生命期内得到管理。 针对选定的子过程,过程性能的具体度量项得到了收集与统计分析。在选 择需要分析的子过程时,理解不同子过程之间的关系及其对达成质量与过 程性能目标所产生的影响十分关键。这种方法有助于确保使用统计与其它 量化技术的子过程监督能应用于对业务最有整体价值的地方。过程性能基 线与模型能用于帮助设定有助于达成业务目标的质量与过程性能目标。 成熟度级别 3 级与 4 级的关键区别在于对过程性能的可预测性。处于成熟 度级别 4 级时,项目绩效与选定的子过程的性能得以使用统计与其他量化 技术进行控制,预测则部分地基于对精细粒度的过程数据的统计分析。 成熟度级别 5 级:优化级 处于成熟度级别 5 级时,组织基于对其业务目标与绩效需要的量化理解, 不断改进其过程。组织使用量化的方法来理解过程中固有的偏差与过程结 果的原因。 成熟度级别 5 级关注于通过增量式的与创新式的过程与技术改进,不断地 改进过程性能。组织的质量与过程性能目标得到建立,然后被不断修改来 体现变化的业务目标与组织级绩效,并被用来作为管理过程改进的准则。 部署的过程改进的效果通过使用统计与其它量化技术来进行度量,并与质 量与过程性能目标进行比较。项目已定义的过程、组织标准过程集与作为 支撑的技术都是可度量的改进活动的目标。 成熟度级别 4 级与 5 级的关键区别在于管理与改进组织级绩效的关注点。 处于成熟度级别 4 级时,组织与项目关注于子过程层面对性能的理解与控 制,并使用其结果来管理项目。处于成熟度级别 5 级时,组织使用从多个 项目收集来的数据对整体的组织级绩效进行关注。对数据的分析识别出绩 效方面的不足与差距。这些差距用于驱动组织级过程改进,并产生绩效方 面的可度量的改进。 成熟度级别的提高 组织可以实现其成熟度的累进式进步,从实现对项目级的控制开始,直至 最高级别,即在整个组织范围的绩效管理与持续的过程改进,并使用定性 的与定量的数据进行决策。 提高了的组织级成熟度与组织能够达成的预期范围内的改进结果相关联, 因而,成熟度也是预测组织今后项目大致结果的一种方法。例如,在成熟 度级别 2 级,通过建立扎实的项目管理,组织已经由随意的状态提升到规 范的状态。随着组织达成某一成熟度级别中一系列过程域的通用目标和特 定目标,组织在提升组织级成熟度的同时也收获了过程改进带来的收益。 由于每一成熟度级别都为下一级别打下必要的基础,因此,在成熟度级别 上的跳级尝试往往会导致反效果。 同时,需要认识到的是,过程改进活动应该关注于以组织的业务环境为背 景的组织需要上,并认识到更高的成熟度级别中的过程域可以应对组织或 项目的当前的与未来的需要。 例如,试图从成熟度级别 1 级迈向成熟度级别 2 级的组织常常被鼓励成立 一个过程组,而过程组的建立由成熟度级别 3 级的过程域“组织级过程关 注”所应对。虽然过程组并非成熟度级别 2 级组织的必要特征,但是它可 以成为组织达成成熟度级别 2 级途径中的有用部分。 这个情形有时被描述成建立一个成熟度级别 1 级的过程组来引导成熟度级 别 1 级的组织走向成熟度级别 2 级。成熟度级别 1 级的过程改进活动可能 25 CMMI 开发模型,版本 1.3 主要依赖于过程组人员的洞察力与能力,直到具备了能够支持更规范与更 大范围改进的基础。 组织可以选择任何时间开始过程改进,即使还没有准备好迈向某些特定实 践所处的成熟度级别。然而,在这种情况下,组织应该理解这些改进的成 功存在风险,因为进行成功制度化的基础尚未完成。缺乏适当基础的过程 有可能在最需要它们的时候被舍弃——当面临压力时。 当成熟度级别 2 级的管理实践有所缺失时,作为成熟度级别 3 级组织特征 的已定义的过程可能处于较大风险之中。例如,管理层可能对一个计划得 很糟糕的进度安排去作出承诺,或者不能控制已形成基线的需求的变更。 类似地,很多组织过早地去收集具有成熟度级别 4 级特征的数据,却发现 由于过程和度量定义的不一致导致这些数据难以解读。 使用与较高成熟度级别相关联过程域中过程的另一个例子存在于构建产 品的过程中。我们当然期望成熟度级别 1 级的组织会进行需求分析、设计、 集成与验证。然而,这些活动直到成熟度级别 3 级时,才会得到描述,并 被定义为紧密结合的、融为一体的工程类过程。成熟度级别 3 级的工程类 过程与已具备的正在逐渐成熟的项目管理能力互为补充,这样,工程类改 进就不会因随意的管理过程而丢失。 过程域 过程域在两种表示法中的展示方式不同。图 3.2 比较了过程域如何在连续 式表示法与阶段式表示法中进行使用的视图。 26 合而为一 合而为一 CMMI 开发模型,版本 1.3 连续式 目标概览图 选定的过程域 过程域 1 过程域 2 过程域 3 过程域 4 过程域 N CL1 CL2 CL3 目标能力等级 阶段式 选定的成熟度级别 成熟度级别 5 级 成熟度级别 4 级 成熟度级别 3 级 成熟度级别 2 级 SAM REQM PPQA PP P MC MA CM =为达成成熟度级别 3 级而选择进行过程改进的过程域组 图 3.2:连续式和阶段式表示法中的过程域 连续式表示法通过选择过程域或者一系列相互关联的过程域,使得组织能 够选择其过程改进工作的关注点,从而最大程度上有益于组织及其业务目 标。尽管过程域之间的依赖关系会给组织的选择带来一些限制,组织在选 择时仍然具有相当程度的自由度。 为方便那些使用连续式表示法的组织,过程域被划分为四类:过程管理类, 项目管理类,工程类与支持类。这些类别突出了过程域之间的一些关键性 联系。 27 CMMI 开发模型,版本 1.3 有时会提到一种非正式的过程域分组:高成熟度过程域。四个高成熟度的 过程域分别是:组织级过程性能,量化项目管理,组织级绩效管理与原因 分析与解决。这些过程域专注于改进已实施过程的性能,这些过程性能与 组织的业务目标紧密相连。 一旦选好了过程域,你还必须选定与过程域关联的那些过程要成熟到何种 程度(即选择适当的能力等级)。能力等级、通用目标与通用实践支持的 是与单个过程域关联的过程的改进。例如,组织可能希望这个过程域达到 能力等级 2 级,而另一个过程域达到能力等级 3 级。当组织达到某一能力 等级,就将目光转向同一过程域的下一个能力等级,或者决定扩展范围, 实施更多的过程域。在大多数过程域都达到能力等级 3 级之后,组织就能 将其注意力转向高成熟度过程域,并追踪其中各个过程域的能力直至能力 等级 3 级。 对过程域与能力等级组合的选择一般通过目标概览图进行描述。目标概览 图定义了需要应对的所有过程域以及每一个目标能力等级。这份概览图决 定了组织过程改进活动中需要应对的目标与实践。 大多数组织对其所选的过程域,至少会选择能力等级 1 级作为目标,这要 求达成所有选定过程域的特定目标。然而,将目标定于高于能力等级 1 级 的组织会通过实施通用目标与通用实践,来专注于组织内所选过程的制度 化。 阶段式表示法提供了一条从成熟度级别 1 级到成熟度级别 5 级的改进之路。 这条道路要求达成各成熟度级别中的过程域的目标。为了支持那些使用阶 段式表示法的组织,过程域按照成熟度级别来分组,用以指明达成各成熟 度级别需要实施的过程域。 例如,成熟度级别 2 级包含了一系列的过程域,组织可以使用这些过程域 来指导它的过程改进,直到组织达成所有这些过程域中的所有目标。一旦 达成成熟度级别 2 级,组织就将关注点转移到成熟度级别 3 级的过程域, 依此类推。适用于每个过程域的通用目标也已预设完成。通用目标 2 适用 于成熟度级别 2 级,通用目标 3 适用于成熟度级别 3 级到 5 级。 表 3.2 列出了 CMMI 开发模型的过程域及其关联的类别与成熟度级别。 表 3.2 过程域、类别与成熟度级别 过程域 原因分析与解决 (Causal Analysis and Resolution,CAR) 配置管理 (Configuration Management,CM) 决策分析与解决 (Decision Analysis and Resolution,DAR) 集成项目管理 (Integrated Project Management,IPM) 度量与分析 (Measurement and Analysis,MA) 组织级过程定义 (Organizational Process Definition,OPD) 类别 支持类 成熟度 级别 5 支持类 2 支持类 3 项目管理类 3 支持类 2 过程管理类 3 28 合而为一 CMMI 开发模型,版本 1.3 组织级过程关注 过程管理类 3 (Organizational Process Focus,OPF) 组织级绩效管理 过程管理类 5 (Organizational Performance Management,OPM) 组织级过程性能 过程管理类 4 (Organizational Process Performance,OPP) 组织级培训 过程管理类 3 (Organizational Training,OT) 产品集成 工程类 3 (Product Integration,PI) 项目监督与控制 项目管理类 2 (Project Monitoring and Control,PMC) 项目计划 项目管理类 2 (Project Planning,PP) 过程与产品质量保证 支持类 2 (Process and Product Quality Assurance,PPQA) 量化项目管理 项目管理类 4 (Quantitative Project Management,QPM) 需求开发 工程类 3 (Requirements Development,RD) 需求管理 项目管理类 2 (Requirements Management,REQM) 风险管理 项目管理类 3 (Risk Management,RSKM) 供方协议管理 项目管理类 2 (Supplier Agreement Management,SAM) 技术解决方案 工程类 3 (Technical Solution,TS) 确认 工程类 3 (Validation,VAL) 验证 工程类 3 (Verification,VER) 等价阶段式定级 等价阶段式定级是一种方式,用来比较使用连续式表示法所产生的结果和 使用阶段式表示法所产生的结果。从本质上来说,如果你使用连续式表示 法的能力等级来度量相对于选定过程域的改进,你如何将其转换为成熟度 级别?这样的转换是否可能? 直到现在,我们都还没有很详细地讨论过程评估。SCAMPISM方法 8被用 来评估使用CMMI的组织,评估的一个结果是评定[SEI 2011a,Ahern 8 过程改进标准 CMMI 评估方法(Standard CMMI Appraisal Method for Process Improvement,SCAMPI)在第五章进行描述。 合而为一 29 CMMI 开发模型,版本 1.3 2005]。如果使用连续式表示法进行评估,那么评定就是一份“能力等级 概览图”。如果使用阶段式表示法进行评估,那么评定就是一个“成熟度 级别评定”(例如成熟度级别 3 级)。 能力等级概览图是过程域及其对应的所达成的能力等级的列表。这份概览 图使组织能够根据过程域来追踪组织的能力等级。当能力等级概览图表现 了组织在各过程域的进展时,即称之为“达成情况概览图”。或者,当它 表现了组织所计划的过程改进的目标时,概览图被称为“目标概览图”。 图 3.3 展现了一份目标概览图与达成情况概览图的结合。每一条的灰色部 分表示已经达成的情况。空白部分表示为满足目标概览图仍需完成的部分。 需求管理 项目计划 项目监督与控制 供方协议管理 度量与分析 过程与产品质量保证 配置管理 能力等级 1 级 能力等级 2 级 能力等级 3 级 图 3.3 目标与达成情况概览图结合的实例 达成情况概览图与目标概览图的对比使得组织能够计划并追踪每个选定 过程域的进度。使用连续式表示法时,对能力等级概览图进行维护是可取 的做法。 目标阶段由目标概览图序列组成,描述了组织需要遵循的过程改进之路。 当组织建立目标概览图时,需要注意通用实践和过程域之间的依赖关系。 如果某一通用实践依赖于某个过程域来执行这一通用实践,或提供一个必 备的工作产品,而当这个过程域未实施时,该通用实践的有效性可能会大 大降低。 9 尽管使用连续式表示法的理由很多,但由能力等级概览图得出的评定结果 只具备有限的能力来为组织提供可以与其它组织进行一般性比较的方法。 如果每个组织选择了相同的过程域,那么就可以使用能力等级概览图;然 而多年来,组织之间都是用成熟度级别来进行比较,并且成熟度级别已提 供了预设好的过程域集合。 9 见第二部分通用目标与通用实践小节中的表 6.2 以进一步了解有关通用实践与过程域之间的依赖关系。 30 合而为一 合而为一 CMMI 开发模型,版本 1.3 鉴于以上情况,等价阶段式定级应运而生。等价阶段式定级能让使用连续 式表示法的组织将能力等级概览图转化成关联的成熟度级别评定。 描述等价阶段式定级的最有效方式是提供一系列的目标概览图,每个目标 概览图等价于阶段式表示法的成熟度级别评定,体现在目标概览图中列出 的过程域中。结果就是目标阶段式定级,等价于阶段式表示法的成熟度级 别。 图 3.4 展示了使用连续式表示法时必须达成的目标概览等价对应至成熟度 级别 2 级至 5 级的概要情况。能力等级一栏的阴影区域代表等价于某一成 熟度级别的目标概览图。 名称 配置管理 度量与分析 项目监督与控制 项目计划 过程与产品质量保证 需求管理 供方协议管理 决策分析与解决 集成项目管理 组织级过程定义 组织级过程关注 组织级培训 产品集成 需求开发 风险管理 技术解决方案 确认 验证 组织级过程性能 量化项目管理 原因分析与解决 组织级绩效管理 缩略语 CM MA PMC PP PPQA REQM SAM DAR IPM OPD OPF OT PI RD RSKM TS VAL VER OPP QPM CAR OPM ML CL1 CL2 CL3 2 2 目标概览 2 2 2 2 2 2 3 3 目标概览 3 3 3 3 3 3 3 3 3 3 4 目标概览 4 4 5 目标概览 5 5 图 3.4:目标概览图与等价阶段式定级 以下规则对等价阶段式定级进行了概括: • 要达成成熟度级别 2 级,所有归入成熟度级别 2 级的过程域必须达成 能力等级 2 级或 3 级。 • 要达成成熟度级别 3 级,所有归入成熟度级别 2 级与 3 级的过程域必 须达成能力等级 3 级。 • 要达成成熟度级别 4 级,所有归入成熟度级别 2 级、3 级与 4 级的过 程域必须达成能力等级 3 级。 31 CMMI 开发模型,版本 1.3 • 要达成成熟度级别 5 级,所有过程域必须达成能力等级 3 级。 达成高成熟度 使用阶段式表示法时,当你达成成熟度级别 4 级或 5 级时,你就达到了高 成熟度。达成成熟度级别 4 级涉及实施成熟度级别 2 级、3 级与 4 级的所 有过程域。同样,达成成熟度级别 5 级涉及实施成熟度级别 2 级、3 级、4 级与 5 级的所有过程域。 使用连续式表示法时,达到高成熟度可借助等价阶段式定级概念进行。当 除组织级绩效管理(Organizational Performance Management,OPM) 与原因分析与解决(Causal Analysis and Resolution,CAR)之外的所有 过程域都达成了能力等级 3 级时,使用等价阶段式定级而等价于阶段式成 熟度级别 4 级的高成熟度就已达到。当所有过程域都达成了能力等级 3 级 时,使用等价阶段式定级而等价于阶段式成熟度级别 5 级的高成熟度就已 达到。 32 合而为一 4 过程域之间的关系 CMMI 开发模型,版本 1.3 过程管理类 本章将描述过程域之间的关键关系,帮助你了解组织的过程改进视图以及 过程域如何依赖于其它过程域的实施。 多个过程域之间的关系,包括从一个过程域流向另一个过程域的信息与产 物——本章使用图与描述进行说明——帮助你从更广的角度着眼过程的 实施与改进。 成功的过程改进举措必须由组织的业务目标来驱动。例如,一项常见的业 务目标是加快产品投放市场的时间。源于此目标的过程改进目标可能是对 项目管理过程进行改进以确保及时交付;这些改进依赖于“项目计划”过 程域与“项目监督与控制”过程域的最佳实践。 虽然我们在本章对过程域进行了分组,以便简化对它们之间关系的讨论, 但是每个过程域之间不论其分组、类别、级别,都经常相互作用,并且相 互产生影响。例如,“决策分析与解决”过程域(成熟度 3 级支持类过程 域)含有应对正式评价过程的特定实践,这些特定实践在“技术解决方案” 过程域中用于从备选解决方案中选择技术解决方案。 了解存在于 CMMI 过程域之间的关键关系有助于以有益而富有成效的方式 应用 CMMI。过程域之间的关系在各过程域的“参考”部分,并且特别在 第二部分中各过程域的“相关过程域”小节,有更为详细的描述。参阅第 二章以进一步了解“参考”部分。 过程管理类过程域包含跨项目的活动,这些活动与过程的定义、计划、部 署、实施、监督、控制、评估、度量及改进相关。 CMMI-DEV 中的五个过程管理类过程域是: • 组织级过程定义(Organizational Process Definition,OPD) • 组织级过程关注(Organizational Process Focus,OPF) • 组织级绩效管理(Organizational Performance Management,OPM) • 组织级过程性能(Organizational Process Performance,OPP) • 组织级培训(Organizational Training,OT) 过程管理类的基础过程域 过程管理类的基础过程域为组织提供了一种能力,以将最佳实践、组织级 过程资产与经验教训文档化并在整个组织范围内分享。 图 4.1 展示了过程管理类的基础过程域之间以及与其它过程域类别之间的 互动关系鸟瞰图。如图 4.1 所示,“组织级过程关注”过程域帮助组织基 于对组织的过程与过程资产当前的强项与弱项的理解,计划、实施并部署 组织级过程改进。 过程域之间的关系 33 CMMI 开发模型,版本 1.3 高层管理人员 组织的过程需 要与目标 组织的业务目标 OPF 资源与协调 对项目与支持组进行的有关标 准过程与资产的培训 OT 标准过程与 其它资产 培训需要 OPD 标准过程、工作环境标准 与其它资产 改进信息(如:经验教训、数据与 产物) 项目管理类、支持类 与工程类过程域 OPD = 组织级过程定义 OPF = 组织级过程关注 OT = 组织级培训 过程改进提议;过程定义、评估与部署的参与 图 4.1:过程管理类的基础过程域 组织过程的候选改进可以通过各种渠道获得。这些活动包括过程改进提议、 过程的度量、过程实施中的经验教训、以及过程评估与产品评价活动的结 果。 “组织级过程定义”过程域基于过程需要与组织的目标,建立并维护组织 的标准过程集、工作环境标准与其它资产。这些其它资产包括生命周期模 型的描述、过程裁剪指南以及与过程相关的文档与数据。 项目对组织的标准过程集进行裁剪,以建立其已定义的过程。其它资产对 裁剪与已定义过程的实施进行支持。 执行这些已定义过程所得到的经验与工作产品被适当地纳入组织的标准 过程集与其它资产中,这些经验与工作产品包括度量数据、过程描述、过 程产物与经验教训。 “组织级培训”过程域识别组织的战略培训需要以及项目与支持组共同的 战术培训需要。特别是,培训得到开发或获取,用于发展执行组织标准过 程集所必需的技能。培训的主要组件有已管理的培训开发项目、已文档化 的计划、拥有适当知识的员工、以及度量培训项目有效性的机制。 34 过程域之间的关系 CMMI 开发模型,版本 1.3 过程管理类的高级过程域 过程管理类的高级过程域为组织提供了一种提升了的能力,以达成其质量 与过程性能的量化目标。 图 4.2 展示了过程管理类的高级过程域之间以及与其它过程域类别之间的 互动关系鸟瞰图。各过程管理类的高级过程域依赖于开发并部署过程与支 持性资产的能力,而过程管理类的基础过程域则提供了这种能力。 改进 组织 绩效能力 OPM 源于改进试点 的成本与收益 高层管理 人员 业务目标 质量与过程目标 OPP 质量与过程度量项、基 线、性能目标与模型等 项目管理类、支持 类与工程类过程域 公共度量项 绩效能力数据 开发并部署标准过程 与其它资产的能力 过程管理类的基础过程域 OPM = 组织级绩效管理 OPP = 组织级过程性能 图 4.2:过程管理类的高级过程域 如图 4.2 所示,“组织级过程性能”过程域从组织的业务目标中衍生出质 量与过程性能的量化目标。组织为项目与支持组提供公共度量项、过程性 能基线与过程性能模型。 这些附加的组织级资产为组成已定义过程提供支持,这些已定义过程能够 达成项目的质量与过程性能目标并支持量化管理。组织对从这些已定义过 程中收集的过程性能数据进行分析,以达成对产品质量、服务质量与组织 标准过程集的过程性能的量化理解。 在“组织级绩效管理”过程域中,过程性能基线与模型得到分析,用来理 解组织满足其业务目标的能力,并衍生出质量与过程性能目标。基于这样 的理解,组织主动选择并部署增量式的与创新式的改进,以对组织绩效取 得可度量的改进。 选择待部署的改进是基于对部署候选改进所产生的可能收益与预测成本 的定量理解。组织还可以适当地调整业务目标和质量与过程性能目标。 过程域之间的关系 35 CMMI 开发模型,版本 1.3 项目管理类 项目管理类过程域涵盖了与项目的计划、监督和控制相关的项目管理活动。 CMMI-DEV 中的七个项目管理类过程域是: • 集成项目管理(Integrated Project Management,IPM) • 项目监督与控制(Project Monitoring and Control,PMC) • 项目计划(Project Planning,PP) • 量化项目管理(Quantitative Project Management,QPM) • 需求管理(Requirements Management,REQM) • 风险管理(Risk Management,RSKM) • 供方协议管理(Supplier Agreement Management,SAM) 项目管理类的基础过程域 项目管理类的基础过程域应对建立并维护项目计划、建立并维护承诺、对 照计划监督进度、采取纠正措施、以及管理供方协议等相关的活动。 图 4.3 展示了项目管理类的基础过程域之间以及与其它过程域类别之间的 互动关系的鸟瞰图。如图 4.3 所示,“项目计划”过程域包括制订项目计 划、使相关干系人参与、获取对计划的承诺、以及对计划进行维护。 36 过程域之间的关系 纠正措施 PMC CMMI 开发模型,版本 1.3 状态、问题、过程评价与产品评价 的结果,度量项与分析 纠正措施 重新计划 状态、问题、评审 与监督的结果 监督什么 产品与产品 组件需求 REQM 产品与产品 组件需求 构建什么 PP 做什么 工程类过程域与支持类过程域 承诺 SAM 供方协议 供方 PMC = 项目监督与控制 PP = 项目计划 REQM = 需求管理 SAM = 供方协议管理 计划 度量需要 产品组件需求、技术问题、完成的产品 组件、验收评审与测试 图 4.3:项目管理类的基础过程域 计划始于定义了产品与项目的需求(图 4.3 中的“构建什么”)。项目计 划涵盖项目所执行的各种项目管理与开发活动。项目对来自各种相关干系 人的、影响项目的其它计划进行评审,并与那些干系人就其对项目的贡献 建立起承诺。例如,这些计划涵盖了配置管理、验证和度量与分析。 “项目监督与控制”过程域包含监督与控制活动的实践以及采取纠正措施 的实践。项目计划规定了进展评审的频率和用于监督进度的度量项。确定 进度主要通过将项目状态与计划进行对比。当实际的状态显著偏离预期的 值时,需要适当地采取纠正措施。这些措施可以包括重新计划,而这需要 使用“项目计划”过程域的实践。 “需求管理”过程域对需求进行维护。它描述了获得并控制需求的变更, 并确保其它相关计划与数据保持最新状态的活动。它提供了从客户需求到 产品需求到产品组件需求的需求可追溯性。 “需求管理”过程域确保需求的变更能够体现在项目计划、活动与工作产 品中。这一变更周期可能影响工程类过程域;因此,需求管理是动态且经 常循环发生的事件序列。对一个受控且规范的工程过程来说,“需求管理” 过程域是其基础。 “供方协议管理”过程域应对项目需要,以获取由供方完成的那部分工作。 可用于满足项目需求的产品来源得到了主动识别。供方得到了选择,供方 协议得到了建立以管理供方。 过程域之间的关系 37 CMMI 开发模型,版本 1.3 供方的进度与绩效按照供方协议中所规定的方式得到了追踪,供方协议得 到了适当的修改。对供方所完成的产品组件进行了验收评审与测试。 项目管理类的高级过程域 项目管理类的高级过程域对诸如以下活动进行应对:建立从组织的标准过 程集中裁剪得到的已定义过程,根据组织的工作环境标准建立项目的工作 环境,与相关干系人进行协调与协作,为项目的执行组建并维持团队,量 化管理项目,以及管理风险。 图 4.4 展示了项目管理类的高级过程域之间以及与其它过程域类别之间的 互动关系的鸟瞰图。各项目管理类的高级过程域都依赖于计划、监督并控 制项目的能力,而项目管理类的基础过程域则提供了这些能力。 过程性能目标、 基线与模型 统计管理数据 QPM 由不稳定的过程造成的风险暴露值 组织的标准过程,工作环 境标准与支持性资产 量化目标、统计管理的 子过程、项目已组成的 过程与已定义的过程 RSKM 过程管理类过程域 团队组建的 规则与指南 经验教训、计划 与绩效数据 已识别的风险 IPM 项目的共 同愿景 项目已定义的过 程与工作环境 项目已组成的 过程与已定义 的过程 风险分类与参 数、风险状态、 风险缓解计划 与纠正措施 用于构建团队 的产品架构 协调、承诺、待解决的问题 执行工程过程与支持过程的团队 项目绩效数据 工程类与支持类过程域 项目管理类的基础过程域 IPM = 集成项目管理 QPM = 量化项目管理 RSKM = 风险管理 图 4.4:项目管理类的高级过程域 “集成项目管理”过程域建立并维护从组织的标准过程集中裁剪得到的项 目已定义的过程(“组织级过程定义”过程域)。项目使用项目已定义的 过程进行管理。 项目使用组织级过程资产并向其作贡献,根据组织的工作环境标准建立并 维护项目的工作环境,根据组织的规则与指南建立团队。项目的相关干系 人通过对关键依赖的识别、协商与追踪、并解决协调方面的问题来及时协 调其工作。 38 过程域之间的关系 工程类 CMMI 开发模型,版本 1.3 尽管在“项目计划”过程域与“项目监督与控制”过程域中覆盖了风险的 识别与监督,但“风险管理”过程域采用了持续、前瞻式的方法,通过诸 如风险参数识别、风险评估与风险缓解等活动对风险进行管理。 “量化项目管理”过程域建立了质量与过程性能的目标,组成有助于达成 那些目标的已定义过程,并对项目进行量化管理。项目的质量与过程性能 目标以组织与客户所建立的目标为基础。 项目已定义的过程的组成使用了统计与其它量化技术。这样的分析使项目 能够预测是否可以达成其质量与过程性能目标。 在预测的基础上,项目可以调整其已定义的过程,或者协商变更质量与过 程性能目标。所选子过程的性能随着项目的进展得到细致的监督,以帮助 评价项目是否处于达成其目标的轨道之上。 工程类过程域涵盖了工程学科所共有的开发与维护活动。工程类过程域的 书写使用了通用的工程术语,这样,涉及产品开发过程(如软件工程、机 械工程等)的任何技术学科都能够将其用于过程改进。 工程类过程域还将不同工程学科的关联过程整合到单一的产品开发过程 之中,来支持以产品为导向的过程改进策略。这样的策略瞄准的是实质性 的业务目标,而非特定的技术学科。这种过程方法有效避免了组织级“烟 囱”型隔阂思想的倾向。 工程类过程域适用于开发领域中任何产品或服务的开发(如,软件产品、 硬件产品、服务、过程等)。 CMMI-DEV 中的五个工程类过程域是: • 产品集成(Product Integration,PI) • 需求开发(Requirements Development,RD) • 技术解决方案(Technical Solution,TS) • 确认(Validation,VAL) • 验证(Verification,VER) 图 4.5 展示了五个工程类过程域之间的互动关系的鸟瞰图。 过程域之间的关系 39 CMMI 开发模型,版本 1.3 项目管理类过程域 产品与产品 组件需求 备选解决方案 RD 需求 需求 产品组件 TS 产品 PI 客户 需求、产品组件、工作产品、验证 与确认报告 VER VAL PI = 产品集成 RD = 需求开发 TS = 技术解决方案 VAL = 确认 VER = 验证 客户需要 图 4.5:工程类过程域 “需求开发”过程域识别客户需要并将这些需要转化为产品需求。产品需 求的集合被加以分析,生成高层次的概念解决方案。该需求集合随后被分 配,以建立最初的产品组件需求集合。 再衍生出其它有助于定义产品的需求,并分配至产品组件。该产品与产品 组件的需求集合清晰地描述了产品的性能、质量属性、设计功能、验证需 求等等,并通过开发人员能够理解并使用的术语进行描述。 “需求开发”过程域提供需求至“技术解决方案”过程域,在此处需求被 转换为产品架构、产品组件设计与产品组件(如通过编码、制造等)。需 求也被提供给“产品集成”过程域,在此处产品组件被组合起来,接口得 到验证,以确保其符合“需求开发”过程域所提供的接口需求。 “技术解决方案”过程域开发产品组件的技术数据包,用于“产品集成” 过程域或“供方协议管理”过程域。备选解决方案被考察,并基于已建立 的准则选择最优设计。这些准则可以因产品不同而有显著区别,这取决于 产品类型、操作环境、性能需求、支持需求以及成本或交付进度。选择最 终解决方案的工作会用到“决策分析与解决”过程域中的特定实践。 “技术解决方案”过程域依赖于“验证”过程域中的特定实践,以在设计 过程中并在最后的构建之前,执行设计验证与同级评审。 “验证”过程域确保选定的工作产品满足规定的需求。“验证”过程域选 择工作产品与验证方法,用于对照规定的需求对工作产品进行验证。一般 40 过程域之间的关系 CMMI 开发模型,版本 1.3 来说验证是一个增量式的过程,从产品组件的验证开始,通常以对完全组 装了的产品进行验证为结束。 验证也应对了同级评审。同级评审是一种经实践检验了的方法,用于尽早 移除缺陷,并为正在开发或维护的工作产品与产品组件提供有价值的洞察。 “确认”过程域对照客户需要,增量式地对产品进行确认。确认可以在操 作环境或模拟的操作环境下执行。在确认的需求方面与客户进行协调是该 过程域的重要元素。 “确认”过程域的范围包括对产品、产品组件、选定的中间工作产品与过 程的确认。这些已确认的要素常常需要再次验证与再次确认。确认中发现 的问题往往在“需求开发”过程域或“技术解决方案”过程域中得到解决。 “产品集成”过程域包含的特定实践与建立集成策略、进行产品组件集成、 以及向客户交付产品等相关联。 “产品集成”过程域在实施产品集成过程时使用了“确认”过程域与“验 证”过程域中的特定实践。“验证”过程域的实践在产品集成之前验证了 产品组件的接口与接口需求。接口验证是集成过程中的必要事件。在操作 环境中进行产品集成时,就要使用到“确认”过程域中的特定实践。 工程类过程的递归与迭代 多数过程标准都同意,过程的应用可以有两种方式。这两种方式被称为递 归与迭代。 当过程应用于系统结构内层次相继的系统元素时,所发生的就是递归。一 次应用的结果被用作系统结构内下一层次的输入。例如,验证过程可以被 设计用于整个已装配的产品,或用于主要的产品组件,甚至用于组件的组 件。将验证过程应用至产品的何种深度,完全取决于最终产品的规模与复 杂度。 当过程在同一系统层次重复时,所发生的就是迭代。实施一个过程会产生 新的信息,该过程再将所产生的新信息反馈至相关的过程。这样的新信息 往往会引出一些在过程完成之前必须解决掉的问题。 例如,迭代很可能发生在需求开发与技术解决方案之间。这些过程的重复 应用能够解决所引出的问题。迭代能够在下一个过程的应用之前确保质量。 工程类过程(如需求开发、验证等)可以在一个产品上重复实施,以确保 在交付给客户之前,这些工程类过程得到了充分的处理。工程类过程还可 以再被进一步应用于产品的组件。 例如,一些由“验证”过程域和“确认”过程域的关联过程所引出的问题 能够由“需求开发”过程域或“产品集成”过程域的关联过程进行解决。 这些过程的递归与迭代使得项目在产品交付给客户之前,能够确保其所有 组件的质量。 项目管理类过程域同样是可递归的,因为项目有时会嵌套在项目之中。 过程域之间的关系 41 CMMI 开发模型,版本 1.3 支持类 支持类过程域涵盖了支持产品开发与维护的活动。支持类过程域应对执行 其它过程时使用到的过程。总的来说,支持类过程域应对面向项目的过程, 并能够应对通用于组织的过程。 例如,“过程与产品质量保证”过程域能够与所有的过程域一起使用,来 对全部过程域中所描述的过程与工作产品提供客观评价。 CMMI-DEV 中的五个支持类过程域是: • 原因分析与解决(Causal Analysis and Resolution,CAR) • 配置管理(Configuration Management,CM) • 决策分析与解决(Decision Analysis and Resolution,DAR) • 度量与分析(Measurement and Analysis,MA) • 过程与产品质量保证(Process and Product Quality Assurance,PPQA) 支持类的基础过程域 支持类的基础过程域应对所有过程域都使用到的基本支持功能。尽管所有 的支持类过程域都依赖于其它过程域作为输入,支持类的基础过程域所提 供的支持功能同样有助于一些通用实践的实施。 图 4.6 展示了支持类的基础过程域之间以及与其它所有过程域之间的互动 关系鸟瞰图。 度量与分析 MA 信息需要 所有过程域 配置项与 变更请求 受控的配置项、 基线、配置报告 质量与不符合 问题 过程与工作产品、 标准、规程 PPQA CM CM = 配置管理 MA = 度量与分析 PPQA = 过程与产品质量保证 图 4.6:支持类的基础过程域 “度量与分析”过程域通过其特定实践为所有过程域提供支持。这些特定 实践通过用于支持管理信息需要的度量途径,来指导项目与组织将度量需 要与目标协调一致。结果可用于进行有依据的决策,并采取适当的纠正措 施。 42 过程域之间的关系 CMMI 开发模型,版本 1.3 “过程与产品质量保证”过程域通过其特定实践为所有过程域提供支持。 这些特定实践对照适用的过程描述、标准与规程,客观地评价已执行的过 程、工作产品与服务,并确保这些评审中出现的任何问题都得到解决。 “过程与产品质量保证”过程域贯穿项目的整个生命期,为项目成员与各 级管理层提供对过程与关联工作产品适当的可视性与反馈,以此支持高质 量产品与服务的交付。 “配置管理”过程域通过使用配置识别、配置控制、配置状态记录与报告、 配置审计等手段,建立并维护工作产品的完整性,以此为所有过程域提供 支持。置于配置管理下的工作产品包括交付给客户的产品、指定的内部工 作产品、采购的产品、工具与其它用于创建并描述这些工作产品的项。 可置于配置管理下的工作产品实例有:计划、过程描述、需求、设计数据、 图纸、产品规格说明、代码、编译器、产品数据文件与产品技术出版物。 支持类的高级过程域 支持类的高级过程域为项目与组织提供改进了的支持能力。这些过程域中 的每一个都依赖于来自其它过程域的具体输入或实践。 图 4.7 展示了支持类的高级过程域之间以及与其它所有过程域之间的互动 关系鸟瞰图。 CAR 过程改进提议 缺陷、其它问题与 成功事例 所有过程域 CAR = 原因分析与解决 DAR = 决策分析与解决 选定的问题 正式的评价 DAR 图 4.7:支持类的高级过程域 项目成员使用“原因分析与解决”过程域来识别所选结果的原因,并采取 措施防止未来负面结果的发生,或充分利用积极的结果。尽管根本原因分 析与行动计划的初始目标是项目已定义的过程,但有效的过程变更也能导 致过程改进提议提交至组织的标准过程集。 “决策分析与解决”过程域确定哪些问题需要采用正式评价过程,并对其 使用正式评价过程,以此为所有过程域提供支持。 过程域之间的关系 43 CMMI 开发模型,版本 1.3 44 过程域之间的关系 5 使用 CMMI 模型 CMMI 开发模型,版本 1.3 采用 CMMI 现今产品的复杂性要求以一个集成化的观点来看待组织如何开展业务。对 于那些依靠多个职能或团队达成目标的企业,CMMI 能够减少整个企业范 围的过程改进成本。 为达成这一集成化的观点,CMMI 框架包含了共同的术语、共同的模型组 件、共同的评估方法与共同的培训材料。本章描述了组织如何使用 CMMI 产品套件,不只是去改进其质量、降低其成本并优化其进度,还去衡量其 过程改进项目开展得如何。 研究表明,过程改进最有力的第一步是通过高层管理人员的强大发起与资 助来构建组织级支持。为赢得高层管理人员的发起与资助,向他们展示那 些其他人经历过的、使用 CMMI 改进其过程的绩效结果通常是有益的 [Gibson 2006]。 可访问 SEI 网页 http://www.sei.cmu.edu/cmmi/research/results/,以进一 步了解有关 CMMI 的绩效结果。 一旦高层管理人员承诺作为过程改进的发起人,则必须积极参与基于 CMMI 的过程改进工作。由高层管理人员作为发起人所执行的活动包括但 不限于以下这些: • 影响组织,使其采用 CMMI • 选择优秀人员管理过程改进工作 • 亲自监督过程改进工作 • 成为过程改进工作的可视的倡导者与发言人 • 确保具备充分的资源,使过程改进工作成功 有了高层管理人员的充分发起与资助,下一步就是建立一个代表相关干系 人的强大的、有技术能力的过程组来指导过程改进工作。[Ahern 2008, Dymond 2005] 对于以开发软件密集型系统为使命的组织,过程组可能包括那些代表组织 内不同学科的人员,以及基于驱动改进的业务需要而选定的其他成员。例 如,系统管理员关注于信息技术方面的支持,而市场代表则关注于集成客 户的需要。这两类成员都可以为过程组做出有力贡献。 一旦你的组织决定采用 CMMI,计划工作可以始于某种改进方法,例如 IDEALSM 模型(初始[Initiating],诊断[Diagnosing],建立[Establishing], 执行[Acting]与学习[Learning])[McFeeley 1996]。可访问 SEI 网站 http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm 以 进 一步 了解 IDEAL 模型。 使用 CMMI 模型 45 CMMI 开发模型,版本 1.3 你的过程改进项目 要使用 CMMI 产品套件来帮助建立组织的过程改进项目。出于此目的而对 产品套件的使用可以是相对非正式的过程,涉及到的是理解 CMMI 最佳实 践,并将其应用于你的组织。或者,该过程也可以是一个正式的过程,涉 及到的是广泛的培训、过程改进基础架构的创立、评估及其它。 影响项目的选择 要将 CMMI 应用于组织进行过程改进,你必须做出三个选择: 1. 选择组织的一部分。 2. 选择模型。 3. 选择表示法。 选择将要参与过程改进的项目极为关键。如果选择一个过于庞大的团队, 对初始的改进工作来说可能会过于吃力。选择还应该考虑到组织、产品与 工作的同质性(即,组员是否都是同一学科的专家,他们是否都为同一产 品线或业务线工作,等等)。 选择合适的模型对成功的过程改进项目来说也十分重要。CMMI-DEV 模型 专注于开发高质量产品与服务的活动。CMMI-ACQ 模型专注于启动并管理 采购产品与服务的活动。CMMI-SVC 模型专注于向客户与最终用户提供高 质量服务的活动。在选择模型时,应当适当考虑组织与项目的首要关注点, 以及满足业务目标所必需的过程。在选择合适的模型时,也应当考虑组织 所专注的生命周期过程(如:概念、设计、生产、部署、运作、维护、废 弃等)。 要选择适合你过程改进观念的表示法(能力等级或成熟度级别)。不管选 择哪种,你都能选择几乎任何过程域或过程域组来指导改进,当然在进行 选择时还应考虑过程域之间的依赖关系。 随着过程改进计划与活动的进行,还必须进行其它重要的选择,包括是否 使用评估、应该使用哪种评估方法、应该评估哪些项目、如何保证员工的 培训以及应该培训哪些员工等等。 CMMI 模型 CMMI 模型描述了组织所找到的对达成其业务目标富有成效且实用的最佳 实践。无论何种组织,你必须使用专业的判断力,根据你所处的境况、你 的需要与业务目标解读 CMMI 的最佳实践。 当你在目标或实践中看到诸如“充分的”、“适当的”或“必要时”等词 语时,更要强化判断力的使用。这些词语用于那些并非在所有情形下都同 等相关的活动。要使用在你组织中能起作用的方式来解读这些目标与实践。 尽管过程域描绘了致力于过程改进的组织的特征,你必须使用对 CMMI、 对你的组织、对业务环境以及所涉及的具体情形等的深入知识来解读过程 域。 当你开始使用 CMMI 模型来改进你组织的过程时,要将你实际的过程映射 至 CMMI 的过程域。这样的映射使你能够对照正在使用的 CMMI 模型对你 的组织进行初步的符合度判断以及后续跟踪,也能够使你识别改进机会。 为了解读实践,重要的是要对这些实践使用时所处的整体情形进行考虑, 并确定在此情形下,这些实践能够在多大程度上满足过程域的目标。CMMI 46 使用 CMMI 模型 CMMI 开发模型,版本 1.3 模型并不指定或暗示任何过程,认为其适合于任何组织或项目。相反, CMMI 描述了所需的最低准则,以此对组织基于业务目标选择加以改进的 过程进行计划与实施。 CMMI 实践特意使用非特定性的短语,诸如“相关干系人”、“适当地”、 “必要时”等,以包容不同组织与项目的需要。项目的具体需要在其生命 期的不同时间点也未必相同。 使用敏捷方法时对 CMMI 的解读 CMMI 实践被设计成能够在各种不同情形下提供价值,因此陈述时使用了 通用性的术语。由于 CMMI 并不对任何特定的开发方法表示认可,因此 CMMI 几乎没有提供任何专属于特定方法的信息。因此,那些不具备在与 当前相类似的环境下实施 CMMI 经验的人会发现对 CMMI 的解读不那么直 观。 为了帮助那些使用敏捷方法的人员在其环境中解读 CMMI 实践,在选定的 过程域中添加了注释。这些注释往往增加在 CMMI-DEV 中下列过程域的 简介部分:CM、PI、PMC、PP、PPQA、RD、REQM、RSKM、TS 与 VER。 所有的注释都以文字“在敏捷环境下”开始,并且都位于实例框内以帮助 你容易地辨认出这些注释,同时提醒你这些注释只是如何解读实践的实例, 因此它们对于过程域的实施既不必要也不充分。 存在多种敏捷的方法。短语“敏捷环境”与“敏捷方法”是所有遵守敏捷 开发宣言[Beck 2001]的开发或管理方法的简称。 此类方法具备以下特征: • 由客户直接参与产品开发 • 使用多个开发迭代来了解并演进产品 • 客户愿意分担决策与风险的职责 许多开发与管理方法具备这些特征中的一项或多项,但并没有被称为“敏 捷”。例如,有些团队可大致上说成是“敏捷”团队,尽管没有使用敏捷 这一术语。而即使你并未使用敏捷方法,你仍可能在这些注释中发现一些 价值。 需谨慎使用这些注释。你对过程域的最终解读在充分满足 CMMI 过程域的 目标与实践的同时,也应该能够适合各种具体情况,包括组织的业务目标、 项目目标、工作组目标或团队目标。正如前文所提到的,注释应被视为实 例,对过程域的实施既不必要也不充分。 针对敏捷开发方法所给出的指导,一些通用的背景知识与动机在 SEI 的技 术笔记 CMMI 或敏捷:为何不两者并用!(CMMI or Agile: Why Not Embrace Both!)[Glazer 2008]中可以找到。 使用 CMMI 评估 很多组织进行了评估,获得了成熟度级别评定或能力等级达成情况概览图, 从中找到了度量他们所取得进展方面的价值。进行这些类型的评估往往是 出于以下一个或多个原因: • 确定组织过程相比 CMMI 最佳实践的完善程度,并识别可改进之处 • 告知外部客户与供方有关组织过程相比 CMMI 最佳实践的完善程度 使用 CMMI 模型 47 CMMI 开发模型,版本 1.3 • 满足一个或多个客户的合同需求 使用 CMMI 模型的组织,其评估必须符合 CMMI 评估需求(Appraisal Requirements for CMMI, ARC)[SEI 2011b]文档中定义的需求。评估 专注于识别改进机会,以及将组织的过程与 CMMI 最佳实践进行对比。 评估团队使用 CMMI 模型与符合 ARC 的评估方法来指导他们对组织的评 价,并进行最终的结论报告。评估结果被用于(如:为过程组所用)计划 组织的改进。 CMMI 评估需求 CMMI 评估需求(Appraisal Requirements for CMMI, ARC)文档描述了 几种评估类型的需求。完全的基准式评估被定义为 A 类评估方法。较为非 正式的方法被定义为 B 类或 C 类方法。ARC 文档设计用于帮助改进评估 方法间的一致性,并帮助评估方法的开发者、发起人与用户理解如何在各 种方法间进行相关的权衡。 根据评估的目的与环境的性质,一种类别可能会优先于其它类别。有时自 我评估、初始评估、快速查看或迷你评估、或外部评估都可能合适;而其 它场合,正式的基准式评估则是合适的。 基于评估方法开发者在设计该方法时所应对的 ARC 需求中的不同集合, 特定的评估方法被宣布为 ARC 的 A 类、B 类或 C 类评估方法。 SEI 网页 http://www.sei.cmu.edu/cmmi/tools/appraisals/提供了关于 ARC 的进一步信息。 SCAMPI 评估方法 SCAMPI A 类评估方法是普遍认可用于使用 CMMI 模型来实施 ARC A 类 评估的方法。SCAMPI A 类方法定义文档(SCAMPI A Method Definition Document,MDD)定义了确保 SCAMPI A 类评估评定一致性的规则[SEI 2011a]。为了与其他组织进行基准比较,评估必须确保具有一致的评定。 达成具体的成熟度级别,或满足某一过程域,对不同的已评估的组织必须 具有相同的意义。 SCAMPI 评估系列包括 A 类、B 类、C 类评估方法。SCAMPI A 类评估方 法是正式认可的、最为严谨的方法,仅有该方法能够给出具有基准特性的 评定。SCAMPI B 类与 C 类评估方法为组织提供了改进信息,其结果与 SCAMPI A 类评估的结果相比更为非正式,但仍然有助于组织识别改进机 会。 SEI 网 页 http://www.sei.cmu.edu/cmmi/tools/appraisals/ 提 供 了 关 于 SCAMPI 方法的进一步信息。 48 使用 CMMI 模型 CMMI 开发模型,版本 1.3 评估方面的考虑 对基于 CMMI 的评估产生影响的选择有: • CMMI 模型 • 评估范围,包括待评估的组织级单位、待审查的 CMMI 过程域,以及 待评估的成熟度级别或能力等级 • 评估方法 • 评估小组组长与小组成员 • 从评估实体中选取的待访谈的评估参与人员 • 评估输出(如:评定、特定于实例的发现) • 评估约束(如:现场时间) SCAMPI MDD 允许在评估中对预设选项进行选择使用。这些评估选项被 设计用于帮助组织使 CMMI 与其业务需要和目标协调一致。 CMMI 评估计划与结果应该始终包括对评估选项、模型范围与选定的组织 级范围的描述。这一文档确定了评估是否能够满足进行基准比较的需求。 对那些想要评估多个职能或团队的组织,CMMI 的集成化途径能够让模型 与评估的培训获得规模化的经济效果。一种评估方法就可以为多个职能单 位提供单独的或联合的结果。 以下的 CMMI 评估原则与其它过程改进模型评估中使用的原则相同: • 高层管理人员的发起与资助 10 • 专注于组织的业务目标 • 为被访谈人员保密 • 使用文档化的评估方法 • 使用过程参考模型(如:CMMI 模型) • 协作的、团队式的途径 • 专注于过程改进行动 CMMI 的相关培训 不管你的组织是刚开始过程改进,或已熟悉过程改进模型,培训仍是组织 采用 CMMI 时所具备能力的关键元素。SEI 与其合作伙伴网络提供了一套 初始课程,但你的组织可能希望通过自己的授课来对这些课程进行补充。 这样的途径使组织能够专注于具有最大业务价值的领域。 SEI 与其合作伙伴网络提供了入门课程:CMMI 开发模型导论。SEI 还提 供了高级培训给那些计划在 CMMI 的采用或评估方面更加深入地进行参与 的人们——例如,那些要作为过程组的一员指导改进的人们、那些要领导 SCAMPI 评估的人们以及那些要讲授 CMMI 开发模型导论 课程的人们。 SEI 网页 http://www.sei.cmu.edu/training/ 提供了 CMMI 相关培训的最新 信息。 10 经验表明影响成功的过程改进与评估的最关键因素就是高层管理人员的发起与资助。 使用 CMMI 模型 49 CMMI 开发模型,版本 1.3 50 使用 CMMI 模型 CMMI 开发模型,版本 1.3 第二部分 通用目标与通用实践以及过程域 51 CMMI 开发模型,版本 1.3 52 CMMI 开发模型,版本 1.3 通用目标与通用实践 概述 本节详细描述了 CMMI 的所有通用目标与通用实践——直接就过程制度化 方面进行阐述的模型组件。当你在应对各个过程域时,请参阅本节以获取 所有通用实践的详细内容。 通用实践的详细说明位于通用实践之后,为通用实践如何在各过程域中进 行独特的应用提供指南。 过程制度化 制度化是过程改进中的一个重要概念。当制度化在通用目标与通用实践的 描述中被提及时,就意味着该过程已根植于工作的执行方式中,并且具有 过程履行(即执行)的承诺与一致性。 已制度化的过程在有压力的情况下更可能得到保持。然而,当过程的需求 与目标发生变化时,过程的实施可能也需要改变,以确保其依然有效。通 用实践描述了应对有关制度化的这些方面的活动。 制度化的程度通过通用目标进行具体化,并通过如表 6.1 所示的、与各目 标相关联的过程名称予以表达。 表 6.1 通用目标与过程名称 通用目标 过程的进步 GG 1 GG 2 GG 3 已执行的过程 已管理的过程 已定义的过程 过程制度化的进步,其特征通过以下各过程的描述予以阐明。 已执行的过程 已执行的过程是指完成了所需工作而满足过程域的特定目标的过程。 已管理的过程 已管理的过程是已执行的过程,其计划与执行依据方针进行;该过程使用 拥有充足资源的、有技能的人员产生有控制的输出;使得相关干系人进行 参与;得到了监督、控制与评审;其过程描述的遵守程度得到了评价。 该过程可以通过某个项目、某个组或某个组织级功能进行实例化。过程的 管理关注于制度化,以及诸如成本、进度与质量目标等为该过程建立的其 它具体目标的达成情况。由已管理的过程提供的控制有助于确保所建立的 过程在压力情况下得以保持。 过程的需求与目标由组织建立。工作产品与服务的状态在已定义的时间点 (如:主要里程碑点,主要任务的完成节点)对管理层具有可视性。在那 些执行工作的人员与相关干系人中建立起了承诺,并在必要时对承诺进行 修改。与相关干系人一起评审了工作产品,并对工作产品进行了控制。这 些工作产品与服务满足所规定的需求。 通用目标与通用实践 53 CMMI 开发模型,版本 1.3 已执行的过程与已管理的过程之间的关键区别在于过程得到管理的程度。 已管理的过程得到了计划(该计划可以是一份更全面的计划的一部分), 并且过程的执行依据计划得到了管理。当实际结果与执行情况显著偏离计 划时,会采取纠正措施。已管理的过程能达成该计划的目标,并得到了制 度化以实现执行上的一致。 已定义的过程 已定义的过程是已管理的过程,该过程根据组织的裁剪指南,从组织的标 准过程集中裁剪而来;拥有得到维护的过程描述;并将过程相关的经验贡 献至组织级过程资产。 组织级过程资产是与过程的描述、实施及改进相关的产物。之所以称其为 资产,是因为这些产物的开发或获取是为了满足组织的业务目标,它们体 现了组织的投入,以期待为当前与未来的业务带来价值。 组织的标准过程集是已定义过程的基础,其建立与改进随时间的推移而进 行。标准过程描述了过程的基本元素,这些元素将会纳入任何已定义的过 程中。它也描述了这些过程元素间的关系(例如顺序、接口)。支持组织 标准过程集当前与未来使用的组织级基础设施得到建立并不断改进。(见 术语表中“标准过程”的定义。) 项目已定义的过程为项目任务与活动的计划、执行及改进提供了基础。项 目可以拥有不止一个已定义的过程(如:一个用于开发产品,另一个用于 测试产品)。 已定义的过程清晰地描述了如下内容: • 目的 • 输入 • 入口准则 • 活动 • 角色 • 度量项 • 验证步骤 • 输出 • 出口准则 已管理的过程与已定义的过程之间的关键区别在于过程描述、标准与规程 的适用范围。对于已管理的过程,其过程描述、标准与规程适用于特定的 项目、组或组织级功能。因此,同一组织内的两个项目,其已管理的过程 可能并不相同。 另一项关键区别在于,相比已管理的过程,已定义的过程描述更为详细, 执行更为严格。这一区别意味着改进信息更容易被理解、分析并使用。最 后,已定义过程的管理建立在更为深入的理解之上,包括在过程活动的相 互关系方面的理解,以及在过程、过程工作产品与过程服务的详细度量项 方面的理解。 过程之间的关系 通用目标不断演进,这样每个目标都为下个目标提供了基础。于是就有了 以下结论: • 已管理的过程是已执行的过程。 • 已定义的过程是已管理的过程。 54 通用目标与通用实践 CMMI 开发模型,版本 1.3 因此,通用目标如得到循序渐进的运用,就描述了一个制度化程度不断进 步的过程,从制度化为已执行的过程到制度化为已定义的过程。 达成过程域的 GG 1,就等于说你达成了该过程域的特定目标。 达成过程域的 GG 2,就等于说你管理了与该过程域相关联的过程的执行。 具有一个方针,表明你将会执行该过程。具有执行该过程的计划。具有所 提供的资源、所分派的职责、关于怎样执行过程的培训,所选定的执行该 过程产生的工作产品得到了控制,等等。换言之,过程就如同任何项目或 支持活动那样得到了计划与监督。 达成过程域的 GG 3,就等于说存在组织级标准过程,能够对其进行裁剪 得到你将要使用的过程。裁剪的结果可能并未对标准过程做任何改变。换 言之,所使用的过程与标准过程可以完全相同。“按原样”使用标准过程 也是裁剪,因为所做出的选择就是无需修改。 每一过程域都描述了多种活动,其中的一些被反复执行。你可能需要对其 中某项活动的执行方式进行裁剪,用来应对新的能力或情形。例如,你可 能有一个关于开发或获得组织级培训的标准,而这一标准并未考虑基于网 络的培训。当你准备开发或获得基于网络的课程时,就可能需要对标准过 程进行裁剪,来应对基于网络的培训所特有的挑战与收益。 通用目标与通用实践 本节描述所有的通用目标与通用实践,及其相关联的子实践、说明、实例 与参考。通用目标按照数字顺序排列成 GG 1 到 GG 3。通用实践也按数 字顺序排列在各自所支持的通用目标之下。 GG 1 达成特定目标 过程域的特定目标得到过程的支持,过程的支持通过将可识别的输入工作产品转换 为可识别的输出工作产品来实现。 GP 1.1 执行特定实践 执行过程域的特定实践,以开发工作产品并提供服务来达成过程域的 特定目标。 本通用实践的目的在于产生工作产品与交付服务,这些产品与服务是实施 (即执行)过程所期望得到的。这些实践能够以非正式方式完成,而不用 遵循文档化的过程描述或计划。执行这些实践的严格程度取决于管理与实 施该项工作的个人,并可能有很大的差异。 通用目标与通用实践 55 CMMI 开发模型,版本 1.3 GG 2 制度化为已管理的过程 过程得到制度化为已管理的过程。 GP 2.1 建立组织级方针 建立并维护组织级方针,以计划并执行过程。 本通用实践的目的在于定义对过程的组织级期望,并实现这些期望对组织 中受影响的人员的可视化。一般来说,高层管理人员负责建立并沟通组织 的指导原则、指示与期望。 并非所有来自高层管理人员的指示都带有“方针”的标签。存在适当的组 织级指示是本通用实践所期望的,无论其被称作什么,或通过什么手段进 行传达。 CAR 详细说明 要对所选结果的原因分析进行识别、并对其进行系统化处理。对此,本方 针建立了组织级期望。 CM 详细说明 要建立并维护基线,追踪并控制工作产品的变更(置于配置管理之下), 以及建立并维护基线的完整性。对此,本方针建立了组织级期望。 DAR 详细说明 要使用正式的评价过程,遵循已建立的准则,对已识别的多个备选方案进 行评价,以选择性地分析可能的决策。对此,本方针建立了组织级期望。 本方针还应就哪些决策需要正式的评价过程提供指南。 IPM 详细说明 要从项目开始贯穿项目的整个生命期,建立并维护项目已定义的过程,并 使用项目已定义的过程来管理项目,同时与相关干系人协调并协作。对此, 本方针建立了组织级期望。 MA 详细说明 要使度量目标和活动与所识别的信息需要协调一致,并与项目目标、组织 级目标或业务目标协调一致,并且提供度量结果。对此,本方针建立了组 织级期望。 OPD 详细说明 要建立并维护一套标准过程供组织使用,使组织级过程资产在全组织内可 用,并且为团队建立规则与指南。对此,本方针建立了组织级期望。 OPF 详细说明 要确定所使用的过程的改进机会,计划、实施并在整个组织范围内部署过 程改进。对此,本方针建立了组织级期望。 OPM 详细说明 要利用统计与其它量化技术分析组织的业务绩效,以确定绩效上的不足, 并识别与部署有助于满足质量与过程性能目标的过程与技术改进。对此, 本方针建立了组织级期望。 OPP 详细说明 要建立并维护组织标准过程集的过程性能基线与过程性能模型。对此,本 方针建立了组织级期望。 56 通用目标与通用实践 CMMI 开发模型,版本 1.3 OT 详细说明 要识别组织的战略培训需要并提供相应培训。对此,本方针建立了组织级 期望。 PI 详细说明 要制订产品集成策略、编制产品集成规程并开发产品集成环境;确保产品 组件之间的接口兼容性;装配产品组件;并交付产品与产品组件。对此, 本方针建立了组织级期望。 PMC 详细说明 要对照项目计划来监督项目进展与绩效,并且当实际情况或结果显著偏离 计划时,管理纠正措施直至关闭。对此,本方针建立了组织级期望。 PP 详细说明 要估算计划的参数,做出内部的与外部的承诺,并且制订管理项目的计划。 对此,本方针建立了组织级期望。 PPQA 详细说明 要对过程与相关联的工作产品是否遵守所适用的过程描述、标准与规程进 行客观评价;并确保不符合问题得到解决。对此,本方针建立了组织级期 望。 本方针还为过程与产品质量保证存在于所有项目之中建立了组织级期望。 过程与产品质量保证必须充分独立于项目管理人员,从而在识别并报告不 符合问题时具有客观性。 QPM 详细说明 要在以下场合使用统计与其它量化技术以及历史数据:在建立质量与过程 性能目标时,在组成项目已定义的过程时,在选择对于理解过程性能来说 至关重要的子过程属性时,在监督子过程性能与项目绩效时,以及在执行 根本原因分析以解决过程性能方面的缺失时。对此,本方针建立了组织级 期望。尤其是,本方针对过程性能度量项、基线与模型的使用建立了组织 级期望。 RD 详细说明 要收集干系人的需要,制订产品与产品组件需求,并且分析与确认那些需 求。对此,本方针建立了组织级期望。 REQM 详细说明 要管理需求并识别需求与项目计划和工作产品之间的不一致。对此,本方 针建立了组织级期望。 RSKM 详细说明 要定义风险管理的策略,并对风险进行识别、分析与缓解。对此,本方针 建立了组织级期望。 SAM 详细说明 要建立、维护并满足供方协议。对此,本方针建立了组织级期望。 TS 详细说明 要对选择产品或产品组件的解决方案、开发设计方案并予以实现的迭代式 周期进行处理。对此,本方针建立了组织级期望。 通用目标与通用实践 57 CMMI 开发模型,版本 1.3 VAL 详细说明 要选择需确认的产品与产品组件;选择确认的方法;建立并维护确认的规 程、准则与环境,以确保产品与产品组件在其预期的操作环境中满足最终 用户的需要。对此,本方针建立了组织级期望。 VER 详细说明 要建立并维护验证的方法、规程、准则与验证环境,并执行同级评审,对 选定的工作产品进行验证。对此,本方针建立了组织级期望。 GP 2.2 计划过程 建立并维护计划,以执行过程。 本通用实践的目的在于确定需要什么来执行过程并达成已建立的目标,以 准备执行过程的计划,准备过程的描述,并获得相关干系人对计划的同意。 应用通用实践的实际含义在每一过程域中都不尽相同。 例如,当本通用实践描述的计划活动应用于“项目监督与控制”过程域时,它 能够在与“项目计划”过程域相关联的过程中得到完全实现。然而,当本通用 实践应用于“项目计划”过程域时,还设立了对项目计划过程本身得到计划的 期望。 因此,本通用实践可以加强 CMMI 模型中其它部分的期望,也可以设立应 满足的新期望。 参阅“项目计划”过程域以进一步了解如何建立并维护定义项目活动的计 划。 建立计划包括将计划与过程描述文档化。维护计划包括对其进行更新,以 反映纠正措施或者需求或目标的变更。 执行过程的计划通常包括: • 过程描述 • 过程的工作产品与服务的标准与需求 • 过程执行的特定目标与其结果(如:质量、时间尺度、周期时间、资源使 用等) • 过程的活动、工作产品与服务之间的依赖性 • 执行过程所需的资源(如:资金、人员、工具等) • 职责与职权的分派 • 执行与支持过程所需要的培训 • 要控制的工作产品以及所适用的控制级别 • 为过程的执行、其工作产品、其服务等提供深入理解的度量需求 • 相关干系人的参与 • 监督并控制过程的活动 • 对过程的客观评价活动 • 对过程与工作产品的管理评审活动 58 通用目标与通用实践 CMMI 开发模型,版本 1.3 子实践 1. 定义执行过程的计划并将其文档化。 该计划可以是一份独立的文档,或嵌在一份更为全面的文档中,还可以 分布于多个文档中。在计划分布于多个文档中的情况下,要确保谁做什 么在各处是一致的。文档可以是纸质或电子文档。 2. 定义过程描述并将其文档化。 包含相关标准与规程的过程描述可作为执行过程的计划的一部分,或通 过引用的形式包含在计划中。 3. 与相关干系人评审计划并获得他们的同意。 计划的评审包括评审所计划的过程能否满足所适用的方针、计划、需求 与标准,从而向相关干系人提供保证。 4. 必要时修订计划。 CAR 详细说明 执行原因分析与解决过程的计划可含在“项目计划”过程域所描述的项目 计划中(或被其引用)。此计划不同于该过程域的一些特定实践中描述的 行动提议及其关联的行动计划。本通用实践所要求的计划是处理项目的总 体原因分析与解决过程(或许从组织维护的标准过程之中裁剪得到)。相 反,过程行动提议及其关联的行动项则涉及用来处理分析中的具体根本原 因所需的活动。 CM 详细说明 执行配置管理过程的计划可含在“项目计划”过程域所描述的项目计划中 (或被其引用)。 DAR 详细说明 执行决策分析与解决过程的计划可含在“项目计划”过程域所描述的项目 计划中(或被其引用)。 IPM 详细说明 集成项目管理过程的计划将项目计划过程与监督控制过程的计划结合到 一起。有关执行“集成项目管理”中与计划相关的实践的计划工作,被视 为对项目计划过程进行计划的一部分得到处理。而有关执行“集成项目管 理”中与监督与控制相关的实践的计划,则可含在“项目计划”过程域所 描述的项目计划中(或被其引用)。 MA 详细说明 执行度量与分析过程的计划可含在“项目计划”过程域所描述的项目计划 中(或被其引用)。 OPD 详细说明 执行组织级过程定义过程的计划可作为组织的过程改进计划的一部分(或 被其引用)。 OPF 详细说明 执行组织级过程关注过程的计划,常被称为“过程改进计划”,与该过程 域的特定实践中所描述的过程行动计划并不相同。本通用实践所要求的计 划涉及为该过程域中所有特定实践而制订的综合计划,从建立组织级过程 需要开始,直至将过程相关经验纳入组织级过程资产。 通用目标与通用实践 59 CMMI 开发模型,版本 1.3 OPM 详细说明 执行组织级绩效管理过程的计划不同于该过程域的特定实践中描述的部 署计划。本通用实践所要求的计划涉及为该过程域中所有特定实践而制订 的综合计划,从维护业务目标开始,直至评价改进效果。相反,本特定实 践所要求的部署计划是对选定改进进行部署而需要的计划。 OPP 详细说明 执行组织级过程性能过程的计划可含在“组织级过程关注”过程域所描述 的组织过程改进计划中(或被其引用)。或者此计划也可形成一份单独的 文档,仅描述为组织级过程性能过程而制订的计划。 OT 详细说明 执行组织级培训过程的计划不同于该过程域的特定实践所描述的组织级 培训战术计划。本通用实践所要求的计划涉及为该过程域中所有特定实践 而制订的综合计划,从建立战略培训需要开始,直至评估组织级培训的有 效性。相反,该过程域的特定实践所要求的组织级培训战术计划所涉及的 是定期为培训交付而进行的计划。 PI 详细说明 执行产品集成过程的计划涉及为该过程域中所有特定实践而制订的综合 计划,从产品集成的准备开始,直到交付最终产品。 执行产品集成过程的计划可以是“项目计划”过程域所描述的项目计划的 一部分(或被其引用)。 PMC 详细说明 执行项目监督与控制过程的计划可以是“项目计划”过程域描述的项目计 划的一部分(或被其引用)。 PP 详细说明 参阅“通用目标与通用实践”章节中表 6.2,以进一步了解通用实践 2.2 与“项目计划”过程域之间的关系。 PPQA 详细说明 执行过程与产品质量保证过程的计划可含在“项目计划”过程域所描述的 项目计划中(或被其引用)。 QPM 详细说明 执行量化项目管理过程的计划可含在“项目计划”过程域所描述的项目计 划中(或被其引用)。 RD 详细说明 执行需求开发过程的计划可作为“项目计划”过程域所描述的项目计划的 一部分(或被其引用)。 REQM 详细说明 执行需求管理过程的计划可作为“项目计划”过程域所描述的项目计划的 一部分(或被其引用)。 RSKM 详细说明 执行风险管理过程的计划可含在“项目计划”过程域所描述的项目计划中 (或被其引用)。本通用实践所要求的计划涉及为该过程域中所有特定实 践而制订的综合计划。特别是,此计划提供了风险缓解的总体方法,但又 不同于针对具体风险的缓解计划(包括应急计划)。相反,该过程域的特 60 通用目标与通用实践 CMMI 开发模型,版本 1.3 定实践所要求的风险缓解计划所涉及的是更为专注的事项,例如触发风险 处理活动的等级。 SAM 详细说明 执行供方协议管理过程的计划的一部分可作为“项目计划”过程域所描述 的项目计划的一部分(或被其引用)。然而,计划的另一部分往往处于项 目之外,由诸如合同管理那样的小组负责。 TS 详细说明 执行技术解决方案过程的计划可作为“项目计划”过程域所描述的项目计 划的一部分(或被其引用)。 VAL 详细说明 执行确认过程的计划可含在“项目计划”过程域所描述的项目计划中(或 被其引用)。 VER 详细说明 执行验证过程的计划可含在“项目计划”过程域所描述的项目计划中(或 被其引用)。 GP 2.3 提供资源 提供充分的资源,以执行过程、开发工作产品并提供过程的服务。 本通用实践的目的在于确保计划所定义的、执行过程所必需的资源在需要 时可用。资源包括充分的资金、适当的实体设施、有技能的人员以及适当 的工具等。 对于术语“充分的”,其解释取决于诸多因素,并且可能随着时间而变化。 资源不充分可以通过增加资源或者减少需求、约束与承诺等手段来解决。 CAR 详细说明 所提供资源的实例有: • 数据库管理系统 • 过程建模工具 • 统计分析软件包 CM 详细说明 所提供资源的实例有: • 配置管理工具 • 数据管理工具 • 归档与复制工具 • 数据库管理系统 DAR 详细说明 所提供资源的实例有: • 模拟器与建模工具 • 原型工具 • 进行调查的工具 通用目标与通用实践 61 CMMI 开发模型,版本 1.3 IPM 详细说明 所提供资源的实例有: • 问题追踪与故障报告软件包 • 群件 • 视频会议 • 集成化的决策数据库 • 集成化的产品支持环境 MA 详细说明 拥有适当专长的人员为度量与分析活动提供支持。可能由一个度量小组来 担当这一角色。 所提供资源的实例有: • 统计软件包 • 支持通过网络收集数据的软件包 OPD 详细说明 通常由一个过程组来管理组织级过程定义活动。该组的人员配备往往由一 组核心专业人士组成,其主要职责是协调组织级过程改进。 该小组得到过程负责人与具备诸如以下各种学科专长的人员支持: • 项目管理 • 适当的工程学科 • 配置管理 • 质量保证 所提供资源的实例有: • 数据库管理系统 • 过程建模工具 • 网页生成器与浏览器 OPF 详细说明 所提供资源的实例有: • 数据库管理系统 • 过程改进工具 • 网页生成器与浏览器 • 群件 • 质量改进工具(如因果图、亲合图、帕累托图等) 62 通用目标与通用实践 CMMI 开发模型,版本 1.3 OPM 详细说明 所提供资源的实例有: • 模拟软件包 • 原型工具 • 统计软件包 • 动态系统建模 • 订阅在线技术数据库与出版物 • 过程建模工具 OPP 详细说明 为组织的标准过程集建立过程性能基线的工作可能需要统计与其它量化 技术方面的特殊专长。 所提供资源的实例有: • 数据库管理系统 • 系统动态模型 • 过程建模工具 • 统计分析软件包 • 问题追踪软件包 OT 详细说明 所提供资源的实例有: • 主题专家 • 课程设计人员 • 教学设计人员 • 讲师 • 培训管理员 培训工作可能需要特殊设施。必要时,要开发或购买“组织级培训”过程 域中活动所要求的设施。 所提供资源的实例有: • 用于分析培训需要的工具 • 用于培训的工作站 • 教学设计工具 • 制作演示材料的软件包 PI 详细说明 产品组件接口的协调工作可由“接口控制工作组”来完成,该工作组由代 表外部接口与内部接口的人员所组成。这样的组可用于挖掘需要,以进行 接口需求的开发。 产品的装配与交付工作可能需要特殊设施。必要时,要开发或购买“产品 集成”过程域中活动所要求的设施。 通用目标与通用实践 63 CMMI 开发模型,版本 1.3 所提供资源的实例有: • 原型工具 • 分析工具 • 模拟工具 • 接口管理工具 • 装配工具(如编译器、编译生成文件、连接工具、钻模、固定装置等) PMC 详细说明 所提供资源的实例有: • 成本追踪系统 • 工作量汇报系统 • 行动项追踪系统 • 项目管理与进度编制程序 PP 详细说明 项目计划可能需要特殊专长、设备与设施。 进行项目计划的特殊专长有: • 经验丰富的估算人员 • 编制进度的人员 • 所适用领域的技术专家(如产品领域、技术等) 所提供资源的实例有: • 电子表格程序 • 估算模型 • 项目计划与进度编制软件包 PPQA 详细说明 所提供资源的实例有: • 评价工具 • 不符合项追踪工具 QPM 详细说明 可能需要统计学方面的、并能够将其用于过程性能分析的特殊专长,以定 义量化管理中使用的分析技术。对来自统计分析的度量项进行分析与解读 也可能需要统计学方面的特殊专长;然而,团队在进行日常工作时也需要 充分的专长来支持其对过程性能的基本理解。 所提供资源的实例有: • 统计分析软件包 • 统计过程与质量控制软件包 • 辅助团队在尽量不依赖额外的专家协助的情况下分析他们自己的过程性 能的脚本与工具 64 通用目标与通用实践 CMMI 开发模型,版本 1.3 RD 详细说明 在应用领域、挖掘干系人需要的方法、明确说明并分析客户、产品与产品 组件需求的方法与工具等方面可能需要特殊专长。 所提供资源的实例有: • 需求规格说明工具 • 模拟器与建模工具 • 原型工具 • 场景定义与管理工具 • 需求追踪工具 REQM 详细说明 所提供资源的实例有: • 需求跟踪工具 • 可追溯性工具 RSKM 详细说明 所提供资源的实例有: • 风险管理数据库 • 风险缓解工具 • 原型工具 • 建模与模拟工具 SAM 详细说明 所提供资源的实例有: • 首选供方列表 • 需求跟踪工具 • 项目管理与进度编制程序 TS 详细说明 将需求的解决方案进行开发、设计并实现的工作可能需要特殊的设施。必 要时,要开发或购买“技术解决方案”过程域中活动所要求的设施。 所提供资源的实例有: • 设计规格说明工具 • 模拟器与建模工具 • 原型工具 • 场景定义与管理工具 • 需求跟踪工具 • 交互式文档化工具 VAL 详细说明 产品或产品组件的确认工作可能需要特殊设施。必要时,要开发或购买确 认工作所要求的设施。 通用目标与通用实践 65 CMMI 开发模型,版本 1.3 所提供资源的实例有: • 测试管理工具 • 测试用例生成器 • 测试覆盖度分析器 • 模拟器 • 负载测试、压力测试与性能测试工具 VER 详细说明 所选产品的验证工作可能需要特殊设施。必要时,要开发或购买“验证” 过程域中活动所要求的设施。 某些验证方法可能需要特殊工具、设备、设施与培训(如:同级评审可能 需要会议室与受过培训的主持人;某些验证测试可能需要特殊的测试设备 以及使用这些设备的有技能的人员)。 提供的资源实例有: • 测试管理工具 • 测试用例生成器 • 测试覆盖度分析器 • 模拟器 GP 2.4 分派职责 分派职责与职权,以执行过程、开发工作产品并提供过程的服务。 本通用实践的目的在于确保在过程的整个生命期中都存在执行过程与达 成所规定结果的责任。所分派的人员必须拥有执行所分派职责的适当职权。 职责的分派可以使用详细的岗位描述来进行,或使用如过程执行计划那样 的活文档来进行。职责的动态分派是实施本通用实践的另一种合理方式, 只要在过程的整个生命期中都能够确保职责的分派与接受。 子实践 1. 分派执行过程的总体职责与职权。 2. 分派执行过程的特定任务的职责与职权。 3. 确定人员理解并接受分派给他们的职责与职权。 OPF 详细说明 典型地,为过程改进建立以下两个小组,并分派职责:(1)过程改进管 理指导委员会,提供高层管理人员的发起与资助,与(2)过程组,促进 并管理过程改进活动。 PPQA 详细说明 职责分派至执行过程与产品质量保证评价的人员,使他们拥有足够的独立 性与客观性来防范主观性与倾向性。 TS 详细说明 任命一位首席或主任架构师来监管技术解决方案,并拥有设计决策的职权, 这有助于保持产品设计与演进的一致性。 66 通用目标与通用实践 CMMI 开发模型,版本 1.3 GP 2.5 培训人员 必要时,培训过程的执行或支持人员。 本通用实践的目的在于确保人员拥有执行或支持过程所需要的技能与专 长。 为将要执行工作的人员提供适当的培训。为那些与执行工作的人员有交互 的人员提供概要培训使其了解情况。 提供培训的方法的实例有:自学;自主培训;自定进度的程序化教学;正式的 在岗培训(on-the-job training);辅导;以及正式的课堂培训等。 培训建立起对过程的共同理解,并传授执行过程所需的技能与知识,从而 支持过程的成功执行。 参阅“组织级培训”过程域以进一步了解如何发展人员的技能与知识,使 其能够有效并高效地执行他们的角色。 CAR 详细说明 培训主题的实例有: • 质量管理方法(如:根本原因分析) CM 详细说明 培训主题的实例有: • 配置管理人员的角色、职责与职权 • 配置管理标准、规程与方法 • 配置库系统 DAR 详细说明 培训主题的实例有: • 正式决策分析 • 对照准则评价备选解决方案的方法 IPM 详细说明 培训主题的实例有: • 为满足项目需要对组织的标准过程集进行裁剪 • 基于项目已定义的过程对项目进行管理 • 组织度量库的使用 • 组织级过程资产的使用 • 集成化的管理 • 组间协调 • 团队形式的问题解决法 通用目标与通用实践 67 CMMI 开发模型,版本 1.3 MA 详细说明 培训主题的实例有: • 统计技术 • 数据收集、分析与汇报过程 • 目标关联度量的开发(如 :目标-问题-度量项法 [Goal Question Metric]) OPD 详细说明 培训主题的实例有: • CMMI 与其它过程与过程改进参考模型 • 计划、管理与监督过程 • 过程的建模与定义 • 可裁剪的标准过程的制订 • 工作环境标准的制订 • 人体工程学 OPF 详细说明 培训主题的实例有: • CMMI 与其它过程改进参考模型 • 过程改进的计划与管理 • 工具、方法与分析技术 • 过程建模 • 主持技术 • 变更管理 OPM 详细说明 培训主题的实例有: • 成本收益分析 • 试点的计划、设计与执行 • 技术转化 • 变更管理 OPP 详细说明 培训主题的实例有: • 过程与过程改进的建模 • 统计与其它量化方法(如:估算模型、帕累托分析、控制图等) 68 通用目标与通用实践 CMMI 开发模型,版本 1.3 OT 详细说明 培训主题的实例有: • 知识与技能需要的分析 • 教学设计 • 教学技术(如培训师培训[train the trainer]) • 主题进修培训 PI 详细说明 培训主题的实例有: • 应用领域 • 产品集成的规程与准则 • 组织内用于集成与装配的设施 • 装配方法 • 打包标准 PMC 详细说明 培训主题的实例有: • 项目的监督与控制 • 风险管理 • 数据管理 PP 详细说明 培训主题的实例有: • 估算 • 预算编制 • 协商 • 风险的识别与分析 • 管理数据 • 计划 • 进度的编制 PPQA 详细说明 培训主题的实例有: • 应用领域 • 客户关系 • 项目的过程描述、标准、规程与方法 • 质量保证目标、过程描述、标准、规程、方法与工具 通用目标与通用实践 69 CMMI 开发模型,版本 1.3 QPM 详细说明 培训主题的实例有: • 基本的量化分析(包括统计分析),这样的分析有助于进行过程性能的分 析、历史数据的使用以及对何时需要纠正措施的识别 • 过程的建模与分析 • 过程度量数据的选择、定义与收集 RD 详细说明 培训主题的实例有: • 应用领域 • 需求的定义与分析 • 需求挖掘 • 需求规格说明与建模 • 需求的跟踪 REQM 详细说明 培训主题的实例有: • 应用领域 • 需求的定义、分析、评审与管理 • 需求管理工具 • 配置管理 • 协商的进行与冲突的解决 RSKM 详细说明 培训主题的实例有: • 风险管理的概念与活动(如:风险的识别、评价、监督、缓解等) • 选择用于风险缓解的度量项 SAM 详细说明 培训主题的实例有: • 与供方进行协商并一起工作的法规与业务实践 • 采购的计划与准备 • 商用现货产品的采购 • 对供方的评价与选择 • 协商的进行与冲突的解决 • 供方管理 • 已购产品的测试与移交 • 已购产品的接收、存储、使用与维护 70 通用目标与通用实践 CMMI 开发模型,版本 1.3 TS 详细说明 培训主题的实例有: • 产品与产品组件的应用领域 • 设计方法 • 架构方法 • 接口设计 • 单元测试技术 • 标准(如:产品、安全性、人员因素、环境等) VAL 详细说明 培训主题的实例有: • 应用领域 • 确认的原则、标准与方法 • 预期使用环境 VER 详细说明 培训主题的实例有: • 应用或服务领域 • 验证原则、标准与方法(如:分析、演示、审查、测试等) • 验证的工具与设施 • 同级评审的准备与规程 • 会议的主持 GP 2.6 控制工作产品 将所选择的过程工作产品置于适当的控制级别。 本通用实践的目的在于建立并维护所选择的过程工作产品(或其描述)在 其使用寿命内的完整性。 所选择的工作产品在执行过程的计划中进行明确识别,同时明确说明适当 的控制级别。 不同的控制级别适用于不同的工作产品与不同的时间点。对有些工作产品 来说,进行版本控制可能已经足够,这样就可以了解在过去或现在的任何 给定时间点所使用工作产品的版本,并且变更的纳入是受控的。版本控制 往往处于工作产品所有者(可能是个人、小组或团队)的单独控制之下。 有时,将工作产品置于正式的或者是有基线的配置管理之下会很重要。此 类控制包含了在预先确定的节点定义与建立基线。这些基线得到了正式评 审与批准,并作为进一步开发所指定的工作产品的基础。 参阅“配置管理”过程域以进一步了解如何使用配置识别、配置控制、配 置状态记录与报告以及配置审计来建立并维护工作产品的完整性。 介于版本控制与正式配置管理之间的其它控制级别也是可能的。所识别的 工作产品可能在不同时间点被置于各种不同的控制级别之下。 通用目标与通用实践 71 CMMI 开发模型,版本 1.3 CAR 详细说明 置于控制之下的工作产品实例有: • 行动提议 • 行动计划 • 原因分析与解决记录 CM 详细说明 置于控制之下的工作产品实例有: • 访问列表 • 变更状态报告 • 变更请求数据库 • 变更控制委员会会议记录 • 归档的基线 DAR 详细说明 置于控制之下的工作产品实例有: • 何时应用正式评价过程的指南 • 含有所推荐的解决方案的评价报告 IPM 详细说明 置于控制之下的工作产品实例有: • 项目已定义的过程 • 项目计划 • 影响项目的其它计划 • 集成的计划 • 项目中收集的的过程与产品的实际度量 • 项目的共同愿景 • 团队结构 • 团队章程 MA 详细说明 置于控制之下的工作产品实例有: • 度量目标 • 基本度量项与衍生度量项的规格说明 • 数据收集与存储规程 • 基本度量与衍生度量数据集 • 分析结果与报告草稿 • 数据分析工具 72 通用目标与通用实践 CMMI 开发模型,版本 1.3 OPD 详细说明 置于控制之下的工作产品实例有: • 组织的标准过程集 • 生命周期模型的描述 • 组织的标准过程集的裁剪指南 • 产品与过程的公共度量项集合的定义 • 组织的度量数据 • 团队结构与组建的规则与指南 OPF 详细说明 置于控制之下的工作产品实例有: • 过程改进提议 • 组织的已批准的过程行动计划 • 用于部署组织级过程资产的培训材料 • 向新项目部署组织的标准过程集的指南 • 组织的过程评估计划 OPM 详细说明 置于控制之下的工作产品实例有: • 从对改进进行的确认工作中得到的文档化经验教训 • 部署计划 • 已修改的改进度量项、目标、优先级等 • 已更新的过程文档与培训材料 OPP 详细说明 置于控制之下的工作产品实例有: • 组织的质量与过程性能目标 • 所选择的过程性能度量项的定义 • 组织过程性能的基线数据 • 过程性能模型 OT 详细说明 置于控制之下的工作产品实例有: • 组织级培训战术计划 • 培训记录 • 培训材料与支持性产物 • 讲师评价表格 通用目标与通用实践 73 CMMI 开发模型,版本 1.3 PI 详细说明 置于控制之下的工作产品实例有: • 所接收的产品组件的验收文档 • 已评价的装配完成的产品与产品组件 • 产品集成策略 • 产品集成规程与准则 • 更新了的接口描述或协议 PMC 详细说明 置于控制之下的工作产品实例有: • 项目进度与状态 • 项目的度量数据与分析 • 挣值报告 PP 详细说明 置于控制之下的工作产品实例有: • 工作分解结构 • 项目计划 • 数据管理计划 • 干系人参与计划 PPQA 详细说明 置于控制之下的工作产品实例有: • 不符合项报告 • 评价日志与报告 QPM 详细说明 置于控制之下的工作产品实例有: • 包含在项目已定义的过程中的子过程 • 度量项的操作定义、其在子过程中的收集点以及如何确定度量项的完整性 • 已收集的度量 RD 详细说明 置于控制之下的工作产品实例有: • 客户的功能性需求与质量属性需求 • 必需的功能与质量属性定义 • 产品与产品组件需求 • 接口需求 74 通用目标与通用实践 CMMI 开发模型,版本 1.3 REQM 详细说明 置于控制之下的工作产品实例有: • 需求 • 需求可追溯矩阵 RSKM 详细说明 置于控制之下的工作产品实例有: • 风险管理策略 • 已识别的风险项 • 风险缓解计划 SAM 详细说明 置于控制之下的工作产品实例有: • 工作说明书 • 供方协议 • 协议备忘录 • 子合同 • 首选供方列表 TS 详细说明 置于控制之下的工作产品实例有: • 产品、产品组件与接口的设计 • 技术数据包 • 接口设计文档 • 设计准则与产品组件复用准则 • 已实现的设计(如:软件代码、安装的产品组件等) • 用户文档、安装文档、操作文档与维护文档等 VAL 详细说明 置于控制之下的工作产品实例有: • 需确认的选定产品与产品组件列表 • 确认的方法、规程与准则 • 确认报告 VER 详细说明 置于控制之下的工作产品实例有: • 验证的规程与准则 • 同级评审的培训材料 • 同级评审的数据 • 验证报告 通用目标与通用实践 75 CMMI 开发模型,版本 1.3 GP 2.7 识别相关干系人,并使之参与 识别过程的相关干系人,并使之按计划参与。 本通用实践的目的在于建立并维护在执行过程时所期望的相关干系人的 参与。 要使干系人按照适当的干系人参与计划所描述的那样进行参与。使得干系 人适当地参与以下活动: • 计划 • 决策 • 承诺 • 沟通 • 协调 • 评审 • 评估 • 需求定义 • 问题与事项的解决 参阅“项目计划”过程域以进一步了解如何计划干系人的参与。 计划干系人参与的目标在于确保过程必需的交互得以完成,又不会听任涉 及数量过多的团体与个人阻碍过程的执行。 在具体任务中可能成为相关干系人的干系人实例,依据场合可包括个人、团队、 管理层、客户、供方、最终用户、运行与支持人员、其它项目、以及政府监管 机构等。 子实践 1. 对与过程相关的干系人及其适当的参与进行识别。 可从过程活动的输入提供者、输出使用者和活动执行者之中识别相关干 系人。一旦识别出相关干系人,就要对他们参与过程活动的适当级别进 行计划。 2. 在适当的情况下,与项目计划人员或其他计划人员分享这些识别结果。 3. 使相关干系人按计划参与。 CAR 详细说明 干系人参与的活动实例有: • 执行原因分析 • 评估行动提案 CM 详细说明 干系人参与的活动实例有: • 建立基线 • 评审配置管理系统报告并解决问题 • 评估配置项变更的影响 • 执行配置审计 • 评审配置管理审计的结果 76 通用目标与通用实践 CMMI 开发模型,版本 1.3 DAR 详细说明 干系人参与的活动实例有: • 建立指南,用以确定哪些问题需要采用正式评价过程 • 定义需要解决的问题 • 建立评价准则 • 识别并评价备选方案 • 选择评价方法 • 选择解决方案 IPM 详细说明 干系人参与的活动实例有: • 解决与组织级过程资产的裁剪相关的问题 • 解决项目计划与影响项目的其它计划之间的问题 • 评审项目的进展与绩效,以与当前及预计的需要、目标与需求相一致。 • 创建项目的共同愿景 • 定义项目的团队结构 • 构成团队 MA 详细说明 干系人参与的活动实例有: • 建立度量目标与规程 • 评估度量数据 • 提供有意义的反馈给那些负责提供原始数据的人,而分析与结果依赖于这 些原始数据 OPD 详细说明 干系人参与的活动实例有: • 评审组织的标准过程集 • 评审组织的生命周期模型 • 解决与裁剪指南相关的问题 • 对过程与产品的公共度量项集合的定义进行评估 • 评审工作环境标准 • 建立并维护授权机制 • 建立并维护团队结构与组建的组织级规则与指南 通用目标与通用实践 77 CMMI 开发模型,版本 1.3 OPF 详细说明 干系人参与的活动实例有: • 就过程改进活动与下列人员进行协调与协作:过程所有者、正在执行或将 要执行过程的人员以及支持组织(如:培训人员、质量保证代表等) • 建立组织级过程需要与目标 • 对组织的过程进行评估 • 实施过程行动计划 • 就试点的执行进行协调与协作,以测试所选择的改进 • 部署组织级过程资产及其变更 • 就与过程改进的计划、实施与部署相关的计划、状态、活动与结果进行沟 通 OPM 详细说明 干系人参与的活动实例有: • 对可能有助于满足业务目标的改进提议进行评审 • 向组织就有关改进部署活动的准备程度、状态与结果提供反馈 典型地,反馈涉及以下方面: • 向提交改进提议的人员告知对他们的提议的处置 • 定期沟通业务绩效与业务目标对比的结果 • 定期向相关干系人告知选择与部署改进的计划与状态 • 准备并分发对改进的选择与部署活动所进行的总结 OPP 详细说明 干系人参与的活动实例有: • 建立组织的质量与过程性能目标及其优先级 • 评审并解决有关组织的过程性能基线方面的问题 • 评审并解决有关组织的过程性能模型方面的问题 OT 详细说明 干系人参与的活动实例有: • 建立协作的环境来讨论培训需要与培训有效性,以确保满足组织的培训需 要 • 识别培训需要 • 评审组织级培训战术计划 • 评估培训的有效性 78 通用目标与通用实践 CMMI 开发模型,版本 1.3 PI 详细说明 干系人参与的活动实例有: • 建立产品集成策略 • 评审接口描述的完整性 • 建立产品集成的规程与准则 • 装配并交付产品与产品组件 • 评价后,沟通结果 • 沟通新的、有效的产品集成过程,以便为影响到的人员提供机会,来改进 其过程性能 PMC 详细说明 干系人参与的活动实例有: • 对照计划对项目进行评估 • 对承诺进行评审并解决问题 • 对项目风险进行评审 • 对数据管理活动进行评审 • 对项目进展进行评审 • 管理纠正措施直至关闭 PP 详细说明 干系人参与的活动实例有: • 建立估算 • 评审并解决有关项目风险的完整性与正确性方面的问题 • 对数据管理计划进行评审 • 制订项目计划 • 对项目计划进行评审并解决有关工作与资源方面的问题 PPQA 详细说明 干系人参与的活动实例有: • 建立对过程与工作产品进行客观评价的标准 • 对过程与工作产品进行评价 • 解决不符合问题 • 追踪不符合问题直至关闭 通用目标与通用实践 79 CMMI 开发模型,版本 1.3 QPM 详细说明 干系人参与的活动实例有: • 建立项目目标 • 解决项目的质量与过程性能目标之间的问题 • 选择所使用的分析技术 • 评价所选择的子过程的过程性能 • 识别有关达成项目的质量与过程性能目标方面的风险,并进行管理 • 识别应采取的纠正措施 RD 详细说明 干系人参与的活动实例有: • 对需求在满足需要、期望、约束与接口方面的充分性进行评审 • 建立操作概念与操作、维持、开发的场景 • 对需求的充分性进行评估 • 为客户需求区分优先级 • 建立产品与产品组件的功能需求与质量属性需求 • 对产品的成本、进度与风险进行评估 REQM 详细说明 干系人参与的活动实例有: • 解决有关需求理解的问题 • 对需求变更的影响进行评估 • 沟通双向追溯性 • 识别需求、项目计划与工作产品之间的不一致 RSKM 详细说明 干系人参与的活动实例有: • 建立协作的环境来对风险进行自由开放的讨论 • 对风险管理策略与风险缓解计划进行评审 • 参与风险识别、风险分析与风险缓解活动 • 沟通并汇报风险管理状态 SAM 详细说明 干系人参与的活动实例有: • 建立对潜在供方进行评价的准则 • 对潜在供方进行评审 • 建立供方协议 • 与供方一起解决问题 • 对供方绩效进行评审 80 通用目标与通用实践 CMMI 开发模型,版本 1.3 TS 详细说明 干系人参与的活动实例有: • 制订备选解决方案与选择准则 • 取得对外部接口的规格说明与设计描述的批准 • 开发技术数据包 • 对产品组件的自制、购买或复用的备选方案进行评估 • 实现设计 VAL 详细说明 干系人参与的活动实例有: • 选择待确认的产品与产品组件 • 建立确认的方法、规程与准则 • 对产品与产品组件的确认结果进行评审并解决问题 • 与客户或最终用户一起解决问题 要解决与客户或最终用户之间的问题,尤其是当他们的基准需要发生显著偏离 时。解决方案的实例有: • 合同或协议中的豁免条款(何事、何时与为何产品) • 附加的深入研究、试验、测试或评价 • 合同或协议的可变更之处 VER 详细说明 干系人参与的活动实例有: • 选择待验证的工作产品与验证方法 • 建立验证规程与准则 • 执行同级评审 • 评估验证结果并识别改正措施 GP 2.8 监督并控制过程 对照执行过程的计划,监督并控制过程,并采取适当的纠正措施。 本通用实践的目的在于对过程进行日常的直接监督与控制。通过维护对过 程适当的可视性,必要时就能够采取适当的纠正措施。对过程进行监督与 控制可能涉及到对过程或其产生的工作产品的适当属性进行度量。 参阅“度量与分析”过程域以进一步了解如何开发并保持用于支持管理信 息需要的度量能力。 参阅“项目监督与控制”过程域以进一步了解如何提供对项目进展的了解, 以在项目绩效显著偏离计划时采取适当的纠正措施。 子实践 1. 对照执行过程的计划,评价实际的进展与绩效。 评价是针对过程、过程的工作产品与过程的服务。 2. 对照执行过程的计划,评审过程的完成情况与结果。 通用目标与通用实践 81 CMMI 开发模型,版本 1.3 3. 与负责过程的直接管理人员一起对过程的活动、状态与结果进行评审, 并识别问题。 这些评审旨在基于对过程的日常监督与控制,为直接管理人员提供对过 程适当的可视性,并辅之以 GP 2.10 中描述的与上级管理层一起进行的 定期的以及事件驱动的评审。 4. 对执行过程中与计划产生显著偏离时的影响进行识别与评价。 5. 对执行过程的计划中的问题与过程执行中的问题进行识别。 6. 当未满足需求与目标时、当识别出问题时、或者当执行过程的进展与 计划有显著差别时,采取纠正措施。 采取纠正措施之前应考虑内在风险。 纠正措施可以包括: • 采取补救行动来修复有缺陷的工作产品或服务 • 对执行过程的计划进行变更 • 调整资源,包括人员、工具与其它资源 • 协商对已建立承诺所进行的变更 • 促成对必须满足的需求与目标所进行的变更 • 终止工作 7. 追踪纠正措施直至关闭。 CAR 详细说明 用于监督与控制的度量项与工作产品实例有: • 已分析的结果的数量 • 原因分析与解决过程中每个实例产生的质量或过程性能的变更 • 将所选定的行动提议进行实施的活动进度 CM 详细说明 用于监督与控制的度量项与工作产品实例有: • 配置项变更的数量 • 实施配置审计的数量 • CCB 活动或审计活动的进度 DAR 详细说明 用于监督与控制的度量项与工作产品实例有: • 使用正式评价过程的成本收益比 • 执行权衡分析的进度 82 通用目标与通用实践 CMMI 开发模型,版本 1.3 IPM 详细说明 用于监督与控制的度量项与工作产品实例有: • 项目已定义的过程的变更数量 • 裁剪组织的标准过程集的进度与工作量 • 接口协调问题的趋势(即已识别的数量与已关闭的数量) • 项目裁剪活动的进度 • 项目共同愿景的使用与有效性 • 团队结构的使用与有效性 • 团队章程的使用与有效性 MA 详细说明 用于监督与控制的度量项与工作产品实例有: • 使用进展与绩效度量项的项目百分比 • 已应对的度量目标的百分比 • 收集并评审度量数据的进度 OPD 详细说明 用于监督与控制的度量项与工作产品实例有: • 使用组织标准过程集中过程架构与过程元素的项目百分比 • 组织标准过程集中各过程元素的缺陷密度 • 过程或过程变更的开发进度 OPF 详细说明 用于监督与控制的度量项与工作产品实例有: • 已提交的、已接受的或已实施的过程改进提议的数量 • 已取得的 CMMI 成熟度级别或能力等级 • 组织级过程资产的部署进度 • 使用当前的组织标准过程集的项目百分比(或当前集合的裁剪后版本) • 与实施组织的标准过程集相关联的问题趋势(即已识别的问题数量、已关 闭的问题数量) • 达成过程需要与目标的进展 OPM 详细说明 用于监督与控制的度量项与工作产品实例有: • 与业务目标相关的质量与过程性能的变更 • 实施改进并对改进进行确认的进度 • 部署所选定改进的活动进度 通用目标与通用实践 83 CMMI 开发模型,版本 1.3 OPP 详细说明 用于监督与控制的度量项与工作产品实例有: • 组织的过程性能中与工作产品和任务属性变更相关的趋势(如:规模增长、 工作量、进度、质量等) • 对用于建立过程性能基线的度量项进行收集与评审的进度 OT 详细说明 用于监督与控制的度量项与工作产品实例有: • 已交付的培训课程的数量(如计划与实际相比) • 对培训后评价的评定结果 • 培训项目质量调查评定结果 • 培训交付的进度 • 课程开发的进度 PI 详细说明 用于监督与控制的度量项与工作产品实例有: • 产品组件的集成概览图(如:已计划的与已装配的产品组件零件,已发现 的异常数量) • 有关集成评价的问题报告趋势(如已记录的数量与已关闭的数量) • 有关集成评价的问题报告时效(即每个问题报告处于开放状态的时长) • 进行具体集成活动的进度 PMC 详细说明 用于监督与控制的度量项与工作产品实例有: • 开放与已关闭的纠正措施的数量 • 月度财务数据收集、分析与报告的进度与状态 • 已执行的评审的数量与类型 • 评审的进度(已计划的对比实际的与延误的目标日期) • 将监督数据进行收集与分析的进度 PP 详细说明 用于监督与控制的度量项与工作产品实例有: • 计划的修订数量 • 每次计划修订中的成本偏差、进度偏差与工作量偏差 • 项目计划的开发与维护进度 PPQA 详细说明 用于监督与控制的度量项与工作产品实例有: • 已计划的与已执行的客观过程评价的偏差 • 已计划的与已执行的客观工作产品评价的偏差 • 客观评价的进度 84 通用目标与通用实践 CMMI 开发模型,版本 1.3 QPM 详细说明 用于监督与控制的度量项与工作产品实例有: • 子过程属性的概览图,子过程的过程性能为达成项目目标所具有的风险或 关键因素提供了洞察(如:通过统计技术选出的需监督的数量,当前正在 监督的数量,过程性能已稳定的数量) • 已识别的偏差的特殊原因的数量 • 度量与分析周期中数据收集、分析与汇报等活动的进度,因其与量化管理 的活动相关 RD 详细说明 用于监督与控制的度量项与工作产品实例有: • 返工的成本、进度与花费的工作量 • 需求规格说明的缺陷密度 • 开发需求集合的活动的进度 REQM 详细说明 用于监督与控制的度量项与工作产品实例有: • 需求的易变性(发生了变更的需求的百分比) • 对需求进行协调的进度 • 对提议的需求变更进行分析的进度 RSKM 详细说明 用于监督与控制的度量项与工作产品实例有: • 已识别、管理、追踪并控制的风险数量 • 每条已评估风险的风险暴露值与风险暴露值的变更,以及作为管理储备的 汇总百分比 • 风险缓解计划的变更活动(如:过程、进度、资金等) • 未预料到的风险的发生 • 风险分类的易变性 • 有关风险缓解工作量与影响,其估算与实际之间的比较 • 风险分析活动的进度表 • 具体缓解措施的行动进度表 SAM 详细说明 用于监督与控制的度量项与工作产品实例有: • 提供给供方的需求的变更数量 • 依据供方协议得出的成本与进度偏差 • 选择供方并建立协议的进度 通用目标与通用实践 85 CMMI 开发模型,版本 1.3 TS 详细说明 用于监督与控制的度量项与工作产品实例有: • 返工的成本、进度与花费的工作量 • 在产品设计或产品组件设计中已处理需求的百分比 • 产品、产品组件、接口以及文档工作的规模与复杂度 • 技术解决方案的工作产品的缺陷密度 • 设计活动的进度 VAL 详细说明 用于监督与控制的度量项与工作产品实例有: • 完成的确认活动的数量(已计划的对比实际的) • 有关确认的问题报告的趋势(如已记录的数量与已关闭的数量) • 有关确认的问题报告的时效(即每个问题报告处于开放状态的时长) • 具体确认活动的进度 VER 详细说明 用于监督与控制的度量项与工作产品实例有: • 验证概览图(如:已计划的与已执行的验证的数量,以及所检出的缺陷的 数量;或者以验证方法或类型进行归类的缺陷的数量) • 以缺陷类别区分的所检出缺陷的数量 • 有关验证的问题报告趋势(如:已记录的数量,已关闭的数量) • 有关验证的问题报告状态(即每个问题报告处于开放状态的时长) • 具体验证活动的进度 • 同级评审的有效性 GP 2.9 客观评价遵守程度 对照过程描述、标准与规程,对过程与所选工作产品的遵守程度进行 客观评价,并处理不符合的情况。 本通用实践的目的在于提供可信的保证,确保过程与所选的工作产品按照 计划得到了实施,并且遵守过程描述、标准与规程。(见术语表中“客观 评价”的定义。) 参阅“过程与产品质量保证”过程域以进一步了解如何客观地评价过程与 工作产品。 评价遵守程度的工作通常由不直接负责管理或执行过程活动的人员来从 事。很多情况下,对遵守程度的评价都由过程外部或项目外部的组织内人 员来进行,或者由组织外人员来完成。因此,即使在过程处于压力之下的 时候(例如:工作落后于进度时,工作超出预算时),仍然能够取得对遵 守程度的可信保证。 CAR 详细说明 经过评审的活动实例有: • 确定结果的原因 • 对行动计划的结果进行评价 86 通用目标与通用实践 CMMI 开发模型,版本 1.3 经过评审的工作产品实例有: • 选定进行实施的行动提议 • 原因分析与解决的记录 CM 详细说明 经过评审的活动实例有: • 建立基线 • 追踪并控制变更 • 建立并维护基线的完整性 经过评审的工作产品实例有: • 打包的基线 • 变更请求数据库 DAR 详细说明 经过评审的活动实例有: • 使用已建立的准则与方法,对备选方案进行评价 经过评审的工作产品实例有: • 何时启用正式评价过程的指南 • 包含推荐解决方案的评价报告 IPM 详细说明 经过评审的活动实例有: • 建立、维护并使用项目已定义的过程 • 与相关干系人协调并协作 • 使用项目的共同愿景 • 组织团队 经过评审的工作产品实例有: • 项目已定义的过程 • 项目计划 • 影响项目的其它计划 • 工作环境标准 • 共同愿景陈述 • 团队结构 • 团队章程 通用目标与通用实践 87 CMMI 开发模型,版本 1.3 MA 详细说明 经过评审的活动实例有: • 使度量与分析活动协调一致 • 提供度量结果 经过评审的工作产品实例有: • 基本度量项与衍生度量项的规格说明 • 数据收集与存储的规程 • 分析结果与报告草案 OPD 详细说明 经过评审的活动实例有: • 建立组织级过程资产 • 确定构成和组建团队的规则与指南 经过评审的工作产品实例有: • 组织的标准过程集 • 生命周期模型的描述 • 组织标准过程集的裁剪指南 • 组织的度量数据 • 人员与团队的授权规则与指南 • 组织级过程文档 OPF 详细说明 经过评审的活动实例有: • 确定过程改进机会 • 计划并协调过程改进活动 • 在项目启动时在项目中部署组织的标准过程集 经过评审的工作产品实例有: • 过程改进计划 • 过程行动计划 • 过程部署计划 • 组织的过程评估计划 OPM 详细说明 经过评审的活动实例有: • 对过程性能数据进行分析,以确定组织满足已识别的业务目标的能力 • 使用量化的分析来选择改进 • 部署改进 • 使用统计与其它量化技术来度量已部署改进的有效性 88 通用目标与通用实践 CMMI 开发模型,版本 1.3 经过评审的工作产品实例有: • 改进提议 • 部署计划 • 修订的改进度量项、目标、优先级与部署计划 • 更新的过程文档与培训资料 OPP 详细说明 经过评审的活动实例有: • 建立过程性能基线与模型 经过评审的工作产品实例有: • 过程性能基线 • 组织的质量与过程性能目标 • 所选的过程性能度量项的定义 OT 详细说明 经过评审的活动实例有: • 识别培训需要并使培训可用 • 提供必要的培训 经过评审的工作产品实例有: • 组织级培训战术计划 • 培训资料与提供支持的产物 • 讲师评价表 PI 详细说明 经过评审的活动实例有: • 建立并维护产品集成策略 • 确保接口兼容性 • 装配产品组件并交付产品 经过评审的工作产品实例有: • 产品集成策略 • 产品集成规程与准则 • 已接收的产品组件的验收文档 • 已装配的产品与产品组件 PMC 详细说明 经过评审的活动实例有: • 对照项目计划,监督项目进展与绩效 • 管理纠正措施直至关闭 通用目标与通用实践 89 CMMI 开发模型,版本 1.3 经过评审的工作产品实例有: • 项目进展与绩效的记录 • 项目评审结果 PP 详细说明 经过评审的活动实例有: • 建立估算 • 制订项目计划 • 获得对项目计划的承诺 经过评审的工作产品实例有: • WBS • 项目计划 • 数据管理计划 • 干系人参与计划 PPQA 详细说明 经过评审的活动实例有: • 客观地评价过程与工作产品 • 追踪并沟通不符合问题 经过评审的工作产品实例有: • 不符合报告 • 评价日志与报告 QPM 详细说明 经过评审的活动实例有: • 使用质量与过程性能目标来管理项目 • 使用统计与其它量化技术来管理所选定的子过程 经过评审的工作产品实例有: • 项目已定义过程的组成 • 度量项的操作定义 • 过程性能分析报告 • 已收集的度量 90 通用目标与通用实践 CMMI 开发模型,版本 1.3 RD 详细说明 经过评审的活动实例有: • 收集干系人需要 • 制订产品与产品组件的功能需求与质量属性需求 • 制订架构需求,明确说明产品组件是如何组成并设计,以达成具体的端对 端的功能需求与质量属性需求 • 分析产品与产品组件需求并对其进行确认 经过评审的工作产品实例有: • 产品需求 • 产品组件需求 • 接口需求 • 必需的功能与质量属性定义 • 在架构方面具有重要性的质量属性需求 REQM 详细说明 经过评审的活动实例有: • 管理需求 • 确保项目计划、工作产品与需求之间的协调一致 经过评审的工作产品实例有: • 需求 • 需求可追溯矩阵 RSKM 详细说明 经过评审的活动实例有: • 建立并维护风险管理策略 • 识别并分析风险 • 缓解风险 经过评审的工作产品实例有: • 风险管理策略 • 风险缓解计划 SAM 详细说明 经过评审的活动实例有: • 建立并维护供方协议 • 履行供方协议 通用目标与通用实践 91 CMMI 开发模型,版本 1.3 经过评审的工作产品实例有: • 供方协议管理计划 • 供方协议 TS 详细说明 经过评审的活动实例有: • 选择产品组件的解决方案 • 开发产品与产品组件的设计 • 实现产品组件的设计 经过评审的工作产品实例有: • 技术数据包 • 产品、产品组件与接口的设计 • 已实现的设计(如:软件代码、组装的产品组件等) • 用户文档、安装文档、操作文档与维护文档等 VAL 详细说明 经过评审的活动实例有: • 选择待确认的产品与产品组件 • 建立并维护确认的方法、规程与准则 • 对产品或产品组件进行确认 经过评审的工作产品实例有: • 确认的方法 • 确认的规程 • 确认的准则 VER 详细说明 经过评审的活动实例有: • 选择验证的工作产品 • 建立并维护验证的规程与准则 • 执行同级评审 • 验证所选定的工作产品 经过评审的工作产品实例有: • 验证的规程与准则 • 同级评审检查单 • 验证报告 92 通用目标与通用实践 CMMI 开发模型,版本 1.3 GP 2.10 与上级管理层一起进行状态评审 与上级管理层一起对过程的活动、状态与结果进行评审,并解决问题。 本通用实践的目的在于为上级管理层提供对过程的适当可视性。 上级管理层包括组织内那些高于过程直接负责人的管理层级别。特别需要 说明的是,上级管理层可以包括高层管理人员。参与这些评审的管理人员 是那些为过程提供方针与总体指导的人员,而并非那些直接对过程执行日 常监督与控制的人员。 不同的管理人员对过程信息有不同需要。这些评审有助于确保在计划与执 行过程时能够做出有信息依据的决策。因此,所期望的是这些评审既有定 期进行的,也有事件驱动型的。 OPF 详细说明 这些评审通常由过程小组或过程行动小组以简要汇报的形式呈现给管理 指导委员会。 演示的主题实例有: • 过程行动小组制订的改进的状态 • 试点的结果 • 部署的结果 • 达成重大里程碑的进度状态(如:评估的准备程度、达成既定的组织级成 熟度级别或能力等级概览图的进展情况) OPM 详细说明 这些评审通常由负责绩效改进的人员以简要汇报的形式呈现给上级管理 层。 演示的主题实例有: • 改进领域,识别自对当前绩效与业务目标的比较分析 • 过程改进的挖掘与分析活动的结果 • 确认活动(如试点)的结果与期望收益之间的比较 • 部署了改进之后的绩效数据 • 部署的成本、进度与风险 • 未达成业务目标的风险 REQM 详细说明 与上级管理层一起评审对外部承诺所提议的变更,以确保所有的承诺都能 得到兑现。 RSKM 详细说明 与适当级别的管理层一起对项目风险状态进行评审,并以定期的方式与事 件驱动的方式进行,从而为项目风险暴露值的可能性与适当的纠正措施提 供可视性。 通常这些评审包含对以下内容的汇总:最关键的风险、关键风险参数(如 风险的可能性与后果)与风险缓解工作的状态。 通用目标与通用实践 93 CMMI 开发模型,版本 1.3 GG 3 制度化为已定义的过程 过程得到制度化为已定义的过程 GP 3.1 建立已定义的过程 建立并维护已定义过程的描述。 本通用实践的目的在于建立并维护从组织的标准过程集中裁剪得到的过 程描述,以应对具体实例的需要。组织应该具备覆盖过程域的标准过程, 同时拥有裁剪这些标准过程的指南,以满足项目或组织级功能的需要。具 备了已定义的过程,就能降低在全组织范围内执行过程方面的差异性,从 而能够有效地分享过程资产、数据与经验总结。 参阅“集成项目管理”过程域以进一步了解如何建立项目已定义的过程。 参阅“组织级过程定义”过程域以进一步了解如何建立标准过程并建立裁 剪准则与指南。 已定义过程的描述为计划、执行并管理活动、工作产品以及与过程相关联 的服务提供了基础。 子实践 1. 从组织的标准过程集中选择那些覆盖了过程域并且最大程度地满足 了项目需要或组织级职能需要的过程。 2. 根据组织的裁剪指南,对所选的过程进行裁剪,以此建立已定义的过 程。 3. 确保组织的过程目标在已定义的过程中得到适当的处理。 4. 将已定义的过程与裁剪的记录文档化。 5. 必要时修改已定义过程的描述。 GP 3.2 收集与过程相关的经验 收集源于过程的计划与执行的、与过程相关的经验,以支持组织过程 与过程资产未来的使用与改进。 本通用实践的目的在于收集过程相关的经验,包括源于过程的计划与执行 的信息与产物。过程相关的经验实例有工作产品、度量项、度量结果、经 验教训与过程改进建议。对信息与产物进行收集,这样它们能够被包含在 组织级过程资产中,使那些(或那些将要)计划与执行相同或相似过程的 人员可以使用。信息与产物被存储在组织的度量库与组织的过程资产库中。 相关信息的实例有各种活动所花费的工作量、某一具体活动中注入或移除的缺 陷、经验教训等。 参阅“集成项目管理”过程域以进一步了解如何为组织级过程资产做贡献。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 子实践 1. 将过程与产品的度量项存储至组织的度量库。 过程与产品的度量项主要是那些定义于组织标准过程集的公共度量项集 合中的度量项。 2. 提交文档以便将其包含于组织的过程资产库中。 3. 将来自过程的经验教训文档化,以将其包含于组织的过程资产库中。 94 通用目标与通用实践 CMMI 开发模型,版本 1.3 4. 提议对组织级过程资产的改进。 CAR 详细说明 过程相关的经验实例有: • 行动提议 • 开放的行动计划的数量及其处于开放状态的时长 • 行动计划状态报告 CM 详细说明 过程相关的经验实例有: • 配置项状态的趋势 • 配置审计结果 • 变更请求时效报告 DAR 详细说明 过程相关的经验实例有: • 考虑过的备选方案的数量 • 评价结果 • 解决重大问题的推荐解决方案 IPM 详细说明 过程相关的经验实例有: • 项目已定义的过程 • 项目为创建其已定义的过程而运用的裁剪选项的数量 • 接口协调问题趋势(即:已识别的数量、已关闭的数量) • 项目成员为项目相关的资产而访问过程资产库的次数 • 举行面对面的会议较之举行使用如电话会议、视频会议等协同设备的会 议,其相关费用记录 • 项目的共同愿景 • 团队章程 MA 详细说明 过程相关的经验实例有: • 数据当前性状态 • 数据完整性测试的结果 • 数据分析报告 通用目标与通用实践 95 CMMI 开发模型,版本 1.3 OPD 详细说明 过程相关的经验实例有: • 提交经验教训至组织的过程资产库 • 提交度量数据至组织的度量库 • 为修改组织的标准过程而提交的变更请求的状态 • 非标准的裁剪请求的记录 OPF 详细说明 过程相关的经验实例有: • 用于划分候选过程改进优先级的准则 • 涉及组织过程的强项与弱项的评估发现 • 改进活动对照进度的状态 • 对组织的标准过程集进行裁剪并将其在所识别的项目中实施的记录 OPM 详细说明 过程相关的经验实例有: • 从过程性能数据与业务目标的对比分析中获得的经验教训 • 文档化的成本与收益的度量项,这些度量项来自于对改进的实施与部署 • 相似开发过程的对比报告,用以识别潜在的效率上的改进 OPP 详细说明 过程相关的经验实例有: • 过程性能基线 • 因与过程性能度量定义不一致而被拒绝的度量数据的百分比 OT 详细说明 过程相关的经验实例有: • 培训有效性调查的结果 • 培训项目绩效评估的结果 • 课程评价 • 来自顾问组的培训需求 PI 详细说明 过程相关的经验实例有: • 产品组件接收记录,异常报告记录,配置状态确认记录与准备度检查结果 记录 • 产品集成占开发工作量总和的百分比(迄今为止实际的加上对完成工作所 需的估算) • 产品集成过程中,在产品与测试环境中发现的缺陷 • 源于产品集成的问题报告 96 通用目标与通用实践 CMMI 开发模型,版本 1.3 PMC 详细说明 过程相关的经验实例有: • 显著偏离的记录 • 构成偏离的准则 • 纠正措施的结果 PP 详细说明 过程相关的经验实例有: • 项目数据库的结构 • 项目属性的估算 • 风险的影响与发生的概率 PPQA 详细说明 过程相关的经验实例有: • 评价日志 • 质量趋势 • 不符合报告 • 纠正措施的状态报告 • 项目质量报告的成本 QPM 详细说明 过程相关的经验实例有: • 来自项目的量化管理数据记录,包括对子过程的过程性能进行的定期评审 的结果,这些子过程被选择用以针对项目已建立的中期目标进行管理 • 对过程性能模型所建议的改进 RD 详细说明 过程相关的经验实例有: • 被认为意义含糊的产品需求列表 • 项目生命周期每个阶段引入的需求数量 • 源于需求分配过程的经验教训 REQM 详细说明 过程相关的经验实例有: • 需求可追溯矩阵 • 基线建立完毕后无资金支持的需求变更数量 • 解决含糊需求时取得的经验教训 通用目标与通用实践 97 CMMI 开发模型,版本 1.3 RSKM 详细说明 过程相关的经验实例有: • 风险参数 • 风险类别 • 风险状态报告 SAM 详细说明 过程相关的经验实例有: • 供方评审的结果 • 用于选择供方的权衡分析 • 供方协议的修订历史 • 供方绩效报告 TS 详细说明 过程相关的经验实例有: • 自制、购买或复用的分析结果 • 设计的缺陷密度 • 应用新方法与工具的结果 VAL 详细说明 过程相关的经验实例有: • 产品组件的原型 • 确认环境的可用时间的百分比 • 每一开发阶段通过确认发现的产品缺陷数量 • 确认的分析报告 VER 详细说明 过程相关的经验实例有: • 含有执行时间与平均准备时间的同级评审记录 • 每一开发阶段通过验证发现的产品缺陷数量 • 验证的分析报告 通用实践的应用 通用实践是可以应用于所有过程域的组件。要将通用实践视为提醒。其目 的在于提醒你正确地做事,属于期望的模型组件。 例如,考虑通用实践“建立并维护计划,以执行过程。”(GP 2.2)。当 其被应用于“项目计划”过程域时,该通用实践提醒你对制订项目计划所 涉及的活动进行计划。当其被应用于“组织级培训”过程域时,同样的通 用实践提醒你对开发组织内人员的技能与知识所涉及的活动进行计划。 98 通用目标与通用实践 CMMI 开发模型,版本 1.3 支持通用实践的过程域 如果说通用目标与通用实践是直接应对过程在组织范围内制度化的模型 组件,那么很多过程域则通过支持通用实践的实施来应对制度化。了解这 些关系有助于你有效地实施通用实践。 此类过程域含有一个或多个特定实践,当其被实施时,某一通用实践也能 得到完全的实施,或产生工作产品用于某一通用实践的实施。 一个实例就是“配置管理”过程域与 GP 2.6,“将所选择的过程工作产品 置于适当的控制级别。”在一个或多个过程域中实施该通用实践时,你也 可以选择全部或部分地实施“配置管理”过程域,来实施该通用实践。 另一个实例是,“组织级过程定义”过程域与 GP 3.1,“建立并维护已定 义过程的描述。”在一个或多个过程域中实施该通用实践时,你应该首先 全部或部分地实施“组织级过程定义”过程域,来建立实施该通用实践所 需的组织级过程资产。 表 6.2 描述了(1)支持通用实践实施的过程域(2)通用实践及与其密切 关联的过程域之间的递归关系。记住这两种类型的关系很重要,以便在过 程改进中利用通用实践与其相关联的过程域之间的自然协同作用。 通用目标与通用实践 99 CMMI 开发模型,版本 1.3 通用实践 GP 2.2 计划过程 GP 2.3 提供资源 GP 2.4 分派职责 GP 2.5 培训人员 GP 2.6 控制工作产品 表 6.2 通用实践与过程域的关系 过程域在通用实践实施中的角色 通用实践如何递归式应用于其相关联的 过程域 11 项目计划:“项目计划”过程能够完全 应用于项目计划过程的 GP 2.2 的特征 实施所有项目相关过程域的 GP 2.2(“项 可被描述为“为计划进行计划”,覆盖 目计划”过程域自身除外)。 的是为项目计划的活动所进行的计划。 项目计划:项目计划过程中实施了“项 目计划”过程域的 SP 2.4“计划项目资 源”的部分为所有项目相关过程域的 GP 2.3 与 GP 2.4(可能除了最初的“项 目计划”过程域本身)的实施提供支持。 这样的支持通过识别所需的过程、角色 与职责来确保恰当的人员配置、设施、 设备与其它项目所需资产的到位来进 行。 组织级培训:组织级培训过程为所有过 程域应用 GP 2.5 时的实施提供支持。具 体的支持方式是使将要执行或支持该过 程的人员可以获得应对战略或组织内培 训需求的相关培训。 应用于组织级培训过程的 GP 2.5 覆盖 的是为执行组织级培训的活动所进行的 培训,应对的是管理培训、创建培训与 完成培训所必需的技能。 项目计划:项目计划过程中实施了“项 目计划”过程域的 SP 2.5“计划所需的 知识与技能”的部分与组织级培训过程, 为所有项目相关过程域的 GP 2.5 的实 施提供完全支持。 配置管理:配置管理过程能够完全实施 应用于配置管理过程的 GP 2.6 覆盖的 所有项目相关过程域与一些组织级过程 是配置管理活动产生的工作产品的变更 域的 GP 2.6。 与版本控制。 GP 2.7 识别相关干系 人,并使之参与 项目计划:项目计划过程中实施了“项 目计划”过程域的 SP 2.6“计划干系人 的参与”的部分能够完全实施所有项目 相关过程域的 GP 2.7 中干系人识别的 部分(最前面的两个子实践)。 项目监督与控制:项目监督与控制过程 中实施了“项目监督与控制”过程域的 SP 1.5“监督干系人的参与”的部分能 够有助于所有项目相关过程域中 GP 2.7 的第三条子实践的实施。 应用于项目计划过程的 GP 2.7 覆盖的 是项目计划活动中相关干系人的参与。 应用于项目监督与控制过程的 GP 2.7 覆盖的是项目监督与控制活动中相关干 系人的参与。 应用于集成项目管理过程的 GP 2.7 覆 盖的是集成项目管理活动中相关干系人 的参与。 集成项目管理:集成项目管理过程中实 施了“集成项目管理”过程域的 SP 2.1 “管理干系人的参与”的部分能够有助 于所有项目相关过程域中 GP 2.7 的第 三条子实践的实施。 11 当通用实践与过程域之间的关系不那么直接时,引起困惑的风险降低了。因此,我们并没有将表中所有的递归关系进行描述 (如通用实践 2.3,2.4 与 2.10) 100 通用目标与通用实践 CMMI 开发模型,版本 1.3 通用实践 过程域在通用实践实施中的角色 通用实践如何递归式应用于其相关联的 过程域 11 GP 2.8 监督并控制过程 项目监督与控制:项目监督与控制过程 应用于项目监督与控制过程的 GP 2.8 能够完全实施所有项目相关过程域的 覆盖的是对项目的监督与控制活动进行 GP 2.8。 的监督与控制。 度量与分析:“度量与分析”过程域对 所有的过程,而不仅是项目相关的过程, 提供了有关度量、分析与记录信息的通 用性指导,这些信息能够用于建立监督 过程性能的度量项。 GP 2.9 客观评价遵守程 度 过程与产品质量保证:过程与产品质量 应 用 于 过 程 与 产 品 质 量 保 证 保证过程能够完全实施所有过程域的 过 程的 GP 2.9 覆盖的是对质量保证活 GP 2.9(“过程与产品质量保证”过程 动与所选择的工作产品的客观评价。 域自身可能除外)。 GP 2.10 与上级管理层一 起进行状态评审 项目监督与控制:项目监督与控制过程 实施了“项目监督与控制”过程域 SP 1.6 “进行进展评审”与 SP 1.7“进行里程 碑评审”的部分,以支持,可能是完全 支持,所有项目相关过程域 GP 2.10 的 实现,这取决于上级管理层在这些评审 中的参与。 GP 3.1 建立已定义的过 程 GP 3.2 收集与过程相关 的经验 集成项目管理:集成项目管理过程中实 施了“集成项目管理”过程域的 SP 1.1 “建立项目已定义的过程”的部分能够 完全实施所有项目相关过程 域 的 GP 3.1。 应用于集成项目管理过程的 GP 3.1 覆 盖的是建立集成项目管理活动的已定义 过程。 组织级过程定义:组织级过程定义过程 为所有过程,而不仅是项目相关的过程, 建立了实施 GP 3.1 所需的组织级过程 资产。 集成项目管理:集成项目管理过程中实 施了“集成项目管理”过程域的 SP 1.7 “为组织级过程资产做出贡献”的部分 能够部分或完全实施所有项目相关过程 域的 GP 3.2。 应用于集成项目管理过程的 GP 3.2 覆 盖的是收集源于计划与执行集成项目管 理活动的过程相关经验。 组织级过程关注:组织级过程关注过程 中实施了“组织级过程关注”过程域的 SP 3.4“将经验纳入到组织级过程资产 中”的部分能够部分或完全实施所有过 程域的 GP 3.2。 组织级过程定义:组织级过程定义过程 为所有过程建立了实施 GP 3.2 所需的 组织级过程资产。 通用目标与通用实践 101 CMMI 开发模型,版本 1.3 考虑到通用实践对这些过程域的依赖,以及这些过程域多能提供的更为全 面的视角,这些过程域往往会尽早予以实施,实施可部分可整体,早于或 与关联的通用实践的实施同步进行。 也有一些情况,将通用实践应用于某一特定过程域的结果会使得整个过程 域看起来多余,而事实上并非如此。将 GP 3.1“建立已定义的过程”应用 于“项目计划”过程域与“项目监督与控制”过程域,较之于“集成项目 管理”过程域的第一项特定目标“使用项目已定义的过程”,将两者的效 果视为相同是合乎情理的。 尽管的确会有一些重叠的情况,但是将该通用实践应用于这两个过程域还 是提供了覆盖项目计划活动以及项目监督与控制活动的已定义的过程。不 过这些已定义的过程并不一定覆盖支持类活动(如配置管理)、其它项目 管理过程(如集成项目管理)或其它过程。与此相对照,由“集成项目管 理”过程域提供的项目已定义的过程则覆盖了所有合适的过程。 102 通用目标与通用实践 CMMI 开发模型,版本 1.3 原因分析与解决(CAR) 成熟度 5 级支持类过程域 目的 原因分析与解决(Causal Analysis and Resolution,CAR)的目的在于识 别所选结果的原因并采取行动,以改进过程性能。 简介 “原因分析与解决”通过预防缺陷或者问题的引入以及识别并适当纳入优 秀过程性能的原因,改进质量与生产率。 原因分析与解决过程域包括如下活动: • 识别并分析所选结果的原因。所选结果可以体现缺陷与问题,其在未 来的发生可以预防;或者体现可在项目或组织中实施的成功事例。 • 采取行动以完成: o 移除原因并预防同类型的缺陷及问题将来再度发生 o 主动分析数据以识别潜在问题并预防其发生 o 将成功的原因纳入过程,以改进将来的过程性能 依靠在缺陷与问题引入之后对其进行检测,成本效益不高。通过将原因分 析与解决活动集成到项目的每个阶段,对缺陷与问题进行预防更为有效。 因为其它项目或当前项目的较早阶段或任务可能已经遇到过类似的结果, 所以原因分析与解决活动是项目间沟通经验教训的机制。 所遇结果的类型得到分析以识别趋势。基于对已定义的过程及其如何实施 的理解,确定这些结果的根本原因及其将来的影响。 因为对所有结果执行原因分析并不现实,所以通过对质量、生产率与周期 时间的估算投入与估算回报进行权衡分析,选择需要执行原因分析的目标。 度量与分析过程应该已经存在。尽管在有些情况下可能需要新度量定义、 重定义或澄清定义,现有已定义的度量项可以用于分析过程变更的影响。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 原因分析与解决活动为项目在局部级别评价其过程以及寻找可以实施的 改进提供一种机制。 当改进被判断为有效时,信息被提交给组织级别以便有可能在组织级过程 中部署。 本过程域的特定实践适用于被选择量化管理的过程。虽然在其它情况下使 用本过程域的特定实践可以增加价值,但是结果可能无法对组织的质量与 过程性能目标产生相同程度的影响。 原因分析与解决(CAR) 103 CMMI 开发模型,版本 1.3 相关过程域 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 参阅“组织级绩效管理”过程域以进一步了解如何选择并实施将要部署的 改进。 参阅“量化项目管理”过程域以进一步了解如何量化地管理项目,以达成 项目已建立的质量与过程性能目标。 104 原因分析与解决(CAR) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 确定所选结果的原因 SP 1.1 选择需要加以分析的结果 SP 1.2 分析原因 SG 2 处理所选结果的原因 SP 2.1 实施行动提议 SP 2.2 评价已实施行动的效果 SP 2.3 记录原因分析的数据 按目标排列的特定实践 SG 1 确定所选结果的原因 所选结果的根本原因得到系统化的确定。 根本原因是原因链的初始要素,该链导向所关注的结果。 SP 1.1 选择需要加以分析的结果 选择需要加以分析的结果。 这个活动可以由事件引发(反应式),或者可以定期得到计划,例如在新 阶段或任务的开始(主动式)。 工作产品实例 1. 将在初始分析中使用的数据 2. 初始分析的结果数据 3. 所选需要深入分析的结果 子实践 1. 收集相关数据。 相关数据的实例有: • 客户或最终用户报告的缺陷 • 同级评审或测试中发现的缺陷 • 高于预期的生产率度量项 • 需要纠正措施的项目管理问题报告 • 过程能力问题 • 按过程的挣值度量(例如,成本绩效指数) • 资源生产能力、利用或响应时间的度量 • 服务履行或服务满意度问题 2. 确定哪些结果要深入分析。 在确定哪些结果要深入分析时,考虑其来源、影响、发生频率、相似性、 分析成本、所需时间与资源、安全性考虑等等。 原因分析与解决(CAR) 105 CMMI 开发模型,版本 1.3 选择结果的方法的实例有: • 帕累托分析 • 直方图 • 属性的箱线图 • 失效模式与影响分析(failure mode and effects analysis,FMEA) • 过程能力分析 SP 1.2 3. 正式地定义分析范围,包括对所需或期望改进的明确定义、受影响的 干系人、受影响的目标等等。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的 决策。 分析原因 对所选结果执行原因分析,并提出对其进行处理的行动。 此分析的目的在于,通过分析相关结果数据并产生将要实施的行动提议, 定义处理所选结果的行动。 工作产品实例 1. 根本原因分析结果 2. 行动提议 子实践 1. 与负责执行任务的人共同进行原因分析。 通常在会议中,与理解所选被研究结果的人共同进行原因分析。对所选 结果有最深刻理解的人通常是负责执行任务的人。在引发结果的事件发 生后,尽量就近对实时数据进行分析是最有效的。 执行原因分析时机的实例有: • 当稳定的子过程不满足其规定的质量与过程性能目标时,或者当子过 程需要得到稳定时 • 任务进行中,需要召开原因分析会议时 • 当工作产品相对其需求显现出意外偏离时 • 当多于预期的缺陷从较早阶段逃逸到当前阶段时 • 当过程性能超出预期时 • 在新阶段或任务的开始 参阅“量化项目管理”过程域以进一步了解如何执行根本原因分析。 2. 分析所选结果以确定其根本原因。 分析过程性能基线与模型可以帮助识别潜在根本原因。 依赖于结果的类型与数量,用多种方式对结果进行研究以确保所有潜在 根本原因得到调查,可能是有益的。考虑对结果既进行分组研究又进行 单独研究。 106 原因分析与解决(CAR) CMMI 开发模型,版本 1.3 用于确定根本原因的方法的实例有: • 因果(鱼骨)图 • 检查表 3. 基于其根本原因,将所选结果进行组合并分组。 在有些情况下,结果可能受多重根本原因影响。 原因组别或者类别的实例有: • 培训与技能不足 • 沟通中断 • 没有解释任务的所有细节 • 手工环节中犯错(例如,键盘输入) • 过程缺陷 在合适的情况下,于组内或者跨组寻找趋势或者征兆。 4. 创建行动提议,其将所要采取的行动文档化,以预防类似结果在将来 发生或者将最佳实践纳入过程。 过程性能模型可以通过对影响及投资回报的预测,支持行动提议的成本 收益分析。 所提议预防性行动实例包括对如下条目的变更: • 有疑问的过程 • 培训 • 工具 • 方法 • 工作产品 纳入最佳实践的实例有: • 创建活动检查单,其加强对常见问题及其预防技术的培训或沟通 • 改变过程以使易出错步骤不发生 • 将过程的全部或部分自动化 • 将过程活动重新排序 • 添加过程步骤,例如任务启动会议,以评审常见问题及其预防行动 原因分析与解决(CAR) 107 CMMI 开发模型,版本 1.3 行动提议通常将如下信息文档化: • 行动提议的起因 • 对所要处理结果的描述 • 原因的描述 • 原因类别 • 识别的阶段 • 行动的描述 • 实施行动提议所需的时间、成本及其它资源 • 从实施行动提议中期望获得的收益 • 不修复问题的估算成本 • 行动提议类别 SG 2 处理所选结果的原因 所选结果的根本原因得到系统化的处理。 按照定义完善的过程运行的项目系统化地分析需要改进的地方,并实施过 程变更以处理所选结果的根本原因。 SP 2.1 实施行动提议 实施所选择的、在原因分析中制订的行动提议。 行动提议描述必要的任务以处理所分析结果的根本原因,进而预防或减少 负面结果的发生或再发生,或者纳入已实现的成功。针对所选行动提议, 制定并实施行动计划。只有那些经证明有价值的变更才应该被考虑广泛实 施。 工作产品实例 1. 所选将实施的行动提议 2. 行动计划 子实践 1. 分析行动提议并确定其优先级。 对行动提议划分优先级的准则有: • 对结果不进行处理会带来的影响 • 实施过程改进以对结果进行处理的成本 • 对质量期望的影响 过程性能模型可以用于帮助识别多个行动提议间的交互作用。 2. 选择待实施的行动提议。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的 决策。 3. 为实施所选行动提议,创建行动计划。 108 原因分析与解决(CAR) CMMI 开发模型,版本 1.3 行动计划中所提供信息的实例有: • 负责实施的人 • 对改进的详细描述 • 受影响领域的描述 • 将要被通知状态的人员 • 进度 • 耗费的成本 • 下一个对状态进行评审的日期 • 关键决策的依据 • 对实施行动的描述 4. 实施行动计划。 为实施行动计划,如下任务应得到执行: • 进行分派。 • 对做工作的人进行协调。 • 对结果进行评审。 • 跟踪行动项直到关闭。 对特别复杂的变更可能进行试验。 试验的实例有: • 使用临时修改的过程 • 使用新工具 SP 2.2 行动可能分派给原因分析团队成员、项目团队成员或者组织的其他成员。 5. 寻找可能存在于其它过程与工作产品中的类似原因,并适当采取行动。 评价已实施行动的效果 评价已实施行动对过程性能产生的效果。 参阅“量化项目管理”过程域以进一步了解如何选择度量项与分析技术。 一旦已变更的过程部署到整个项目,评价变更的效果以验证该变更改进了 过程性能。 工作产品实例 1. 对过程性能以及过程性能变更的分析 子实践 1. 对项目中受影响过程或子过程的过程性能变更进行度量与分析。 本子实践确定所选变更是否已经正面影响过程性能及影响程度。 原因分析与解决(CAR) 109 CMMI 开发模型,版本 1.3 项目已定义的设计过程中,过程性能变更的一个实例可能是为了满足质 量与过程性能目标对预测的设计能力的变更。 另一个实例可能是,依照改进实施前后通过同级评审所统计度量的,设 计文档中缺陷密度的变更。在统计过程控制图上,这个过程性能变更可 能表现为均值的改进、偏差的降低或两者皆有。 SP 2.3 统计与其它量化技术(例如,假设检验)可以用于比较前后基线以评估 变更的统计显著性。 2. 确定变更对达成项目的质量与过程性能目标产生的影响。 通过理解过程性能数据的变化已经如何影响了项目的质量与过程性能目 标,本子实践确定所选的变更是否对满足这些目标的能力产生了正面影 响。通过对影响与投资回报进行预测,过程性能模型可以帮助评价。 3. 如果对过程或子过程的改进没有产生期望的项目收益,确定适当的行 动并将其文档化。 记录原因分析的数据 记录原因分析与解决的数据,以供各项目与整个组织使用。 工作产品实例 1. 原因分析与解决的记录 2. 组织级改进提议 子实践 1. 记录原因分析的数据并让数据可用,以使其它项目可以进行适当的过 程变更并取得类似的结果。 记录如下内容: • 所分析结果的数据 • 决策的依据 • 来自原因分析会议的行动提议 • 从行动提议产生的行动计划 • 分析与解决活动的成本 • 由解决活动产生的、已定义过程的过程性能变更方面的度量项 2. 当已实施行动对项目有效时,适当为组织提交过程改进提议。 当改进被判断为有效时,信息可以提交到组织级以便有可能纳入组织级 过程。 参阅“组织级绩效管理”过程域以进一步了解如何选择改进。 110 原因分析与解决(CAR) CMMI 开发模型,版本 1.3 配置管理(CM) 成熟度 2 级支持类过程域 目的 配置管理(Configuration Management,CM)的目的在于使用配置识别、 配置控制、配置状态记录与报告以及配置审计,来建立并维护工作产品的 完整性。 简介 “配置管理”过程域涉及以下活动: • 识别所选工作产品的配置,其在给定的时间点上组成基线 • 控制对配置项的变更 • 构建或提供规格说明,以便从配置管理系统构建工作产品 • 维护基线的完整性 • 向开发人员、最终用户与客户提供准确的状态与当前的配置数据 置于配置管理下的工作产品包括向客户交付的产品、指定的内部工作产品、 采购的产品、工具以及在创建并描述这些工作产品时使用的其它项。(见 术语表中“配置管理”的定义。) 可能置于配置管理下的工作产品的实例有: • 硬件与设备 • 图纸 • 产品规格说明 • 工具配置 • 代码与库 • 编译器 • 测试工具与测试脚本 • 安装日志 • 产品数据文件 • 产品技术出版物 • 计划 • 用户故事 • 迭代工作清单 • 过程描述 • 需求 • 架构文档与设计数据 • 产品线计划、过程与核心资产 采购的产品可能需要由供方与项目都置于配置管理之下。供方协议中应建 立执行配置管理的规定。确保数据完备且一致的方法应得到建立与维护。 参阅“供方协议管理”过程域以进一步了解如何建立供方协议。 工作产品的配置管理可按多个粒度级别执行。配置项可以分成配置组件与 配置单元。在本过程域中只使用术语“配置项”。所以,在这些实践中“配 配置管理(CM) 111 CMMI 开发模型,版本 1.3 置项”适当时可解释为“配置组件”或“配置单元”。(见术语表中“配 置项”的定义。) 基线为配置项的持续演变提供稳定的基础。 基线的一个实例是已批准的产品描述,包括内部一致的需求版本、需求可追溯 矩阵、设计、特定学科条目与最终用户文档。 随着基线内容得到开发,基线被纳入配置管理系统。通过配置管理的配置 控制、变更管理以及配置审计功能,对基线的变更以及从配置管理系统所 构建的工作产品的发布得到系统化地控制与监督。 本过程域不仅适用于项目的配置管理,也适用于组织级工作产品,如标准、 规程、复用库与其它共享的支持资产等的配置管理。 配置管理关注工作产品的管理与技术方面的严格控制,包括交付的产品或 服务。 本过程域覆盖执行配置管理职能的实践,也适用于置于配置管理之下的所 有工作产品。 对于产品线,由于产品线下各产品之间以及核心资产与产品的多个版本之 间的核心资产共享,配置管理还涉及另外需要考虑的事项。(见术语表中 “产品线”的定义。) 在敏捷环境中,配置管理是非常重要的,因为需要支持频繁变更、频繁构建(通 常每天)、多条基线与多个配置管理支持的工作区(例如,为个人、团队、甚 至结对编程)。敏捷团队可能陷入困境,如果这个组织没有:1)将配置管理 自动化(例如,构建脚本、状态记录与报告,完整性检查)并 2)将配置管理 作为单独的一套标准服务加以实施。在敏捷团队启动时,就应该识别负责确保 配置管理活动正确实施的人。在每个迭代开始时,重新确定配置管理支持的需 要。配置管理被谨慎地集成到各团队的工作节奏中,把焦点集中在尽量减少对 团队的干扰,以使工作完成。(见第一部分中的“使用敏捷方法时对 CMMI 的解读”。) 相关过程域 参阅“项目监督与控制”过程域以进一步了解如何对照计划监督项目,并 管理纠正措施直至关闭 参阅“项目计划”过程域以进一步了解如何制订项目计划。 112 配置管理(CM) CMMI 开发模型,版本 1.3 SG 1 建立基线 SP 1.1 识别配置项 SP 1.2 建立配置管理系统 SP 1.3 创建或发布基线 SG 2 跟踪并控制变更 SP 2.1 跟踪变更请求 SP 2.2 控制配置项 SG 3 建立完整性 SP 3.1 建立配置管理记录 SP 3.2 执行配置审计 按目标排列的特定实践 特定目标与特定实践摘要 SG 1 建立基线 所识别的工作产品的基线得到建立。 本特定目标包括建立基线的特定实践。“跟踪并控制变更”特定目标下的 特定实践则用于维护基线。“建立完整性”特定目标下的特定实践则记录 并审计基线的完整性。 SP 1.1 识别配置项 识别将置于配置管理下的配置项、组件与相关的工作产品。 配置识别是下列各项的选择与规格说明: • 交付给客户的产品 • 指定的内部工作产品 • 采购的产品 • 工具及项目工作环境的其它重要资产 • 用于创建并描述这些工作产品的其它项 配置项可以包括硬件、设备与有形资产,也可以是软件与文档。文档可以 包括需求规格说明书与接口文档。其它用于识别产品或服务配置的文档, 例如测试结果,也可以包括在其中。 “配置项”是为配置管理指定的实体,它可以包含构成基线的多个相关工 作产品。这种逻辑分组为有效识别与受控访问提供便利。为配置管理选择 工作产品应基于计划期间所建立的准则。 工作产品实例 1. 已识别的配置项 子实践 1. 基于文档化的准则选择配置项与组成配置项的工作产品。 配置管理(CM) 113 CMMI 开发模型,版本 1.3 在适当工作产品层次上选择配置项的准则的实例有: • 由两个或多个组使用的工作产品 • 由于错误或需求变更预期会随着时间变更的工作产品 • 相互依赖的工作产品(即:当其中一个改变时,将会导致其它工作产 品的变更) • 对项目成功至关重要的工作产品 可能作为配置项一部分的工作产品的实例有: • 设计 • 测试计划与规程 • 测试结果 • 接口描述 • 图纸 • 源代码 • 用户故事或故事卡 • 声明的业务用例、逻辑或数值 • 工具(例如,编译器) • 过程描述 • 需求 2. 为配置项分派唯一标识。 3. 明确说明每个配置项的重要特征。 配置项的重要特征包括作者、文档或文件类型、软件代码文件的编程语 言、最低的适于销售的特征以及配置项服务的目的。 4. 明确说明每个配置项纳入配置管理的时机。 确定何时将工作产品纳入配置管理的准则的实例有: • 当工作产品准备好进行测试的时候 • 项目生命周期的阶段 • 对工作产品所期望的控制程度 • 成本与进度的限制 • 干系人的需求 114 配置管理(CM) CMMI 开发模型,版本 1.3 SP 1.2 5. 识别负责每个配置项的所有者。 6. 明确说明配置项之间的关系。 将配置项之间存在的关系类型(例如,父子、依赖)纳入配置管理结构 (例如,配置管理数据库)中,有助于管理变更的效果与影响。 建立配置管理系统 建立并维护用于控制工作产品的配置管理与变更管理系统。 配置管理系统包括存储介质、规程与访问系统的工具。配置管理系统可以 包括多个子系统,它们具有适合每个配置管理环境的不同的实现。 变更管理系统包括存储介质、规程以及记录并访问变更请求的工具。 工作产品实例 1. 具有受控工作产品的配置管理系统 2. 配置管理系统访问控制规程 3. 变更请求数据库 子实践 1. 建立多级控制的管理机制。 控制等级的选择通常基于项目目标、风险与资源。控制等级可能因项目 生命周期、开发的系统类型与特定项目需求有所不同。 控制等级的实例有: • 不受控:任何人可以变更 • 工作进行中:作者控制变更 • 已发布:指定的权限授权并控制变更,当进行变更时,通知相关干系 人 控制等级可以从非正式控制到正式的配置控制,前者是对开发期间的配 置项更改所作的简单跟踪,后者使用基线,其变更只能作为正式配置管 理过程的一部分。 2. 提供访问控制以确保对配置管理系统授权的访问。 3. 在配置管理系统中存储并检索配置项。 4. 在配置管理系统中的控制等级间共享并传递配置项。 5. 存储并恢复配置项的存档版本。 6. 存储、更新并检索配置管理记录。 7. 从配置管理系统中创建配置管理报告。 8. 保存配置管理系统的内容。 配置管理系统保存功能的实例有: • 备份并还原配置管理文件 • 配置管理文件的存档 • 从配置管理错误中恢复 9. 必要时,修订配置管理结构。 配置管理(CM) 115 CMMI 开发模型,版本 1.3 SG 2 SP 1.3 创建或发布基线 创建或发布供内部使用以及交付给客户的基线。 基线表示为在一个特定时间点,将一个标识符赋予一个配置项或配置项及 其相关实体的集合。随着产品或服务的演进,可以使用多个基线控制开发 与测试。(见术语表中“基线”的定义。) 硬件产品同软件与文档一样也应该包含在基础设施相关的配置基线中(例 如,软件、硬件),并作为包含软硬件交互的系统测试的准备。 一组常见的基线包括系统级需求、系统元素级设计需求以及在开发结束/ 生产开始的产品定义。这些基线通常被分别称为“功能基线”,“已分配 基线”与“产品基线”。 软件基线可以是一组需求、设计、源代码文件及其相关联的可执行代码、 构建文件与用户文档(相关联的实体),它们被分派了唯一的标识符。 工作产品实例 1. 基线 2. 基线的描述 子实践 1. 在创建或发布配置项的基线前,从 CCB 获得授权。 2. 仅从配置管理系统中的配置项创建或发布基线。 3. 将基线所包含的配置项集文档化。 4. 使当前的基线集随时可用。 跟踪并控制变更 置于配置管理下的工作产品的变更得到跟踪与控制。 在“建立基线”特定目标下的特定实践建立基线后,本特定目标下的特定 实践用来维护基线。 SP 2.1 跟踪变更请求 跟踪对配置项的变更请求。 变更请求不仅应对新需求或需求变更,也可应对工作产品的故障与缺陷。 分析变更请求,以确定变更将对工作产品、相关工作产品、预算与进度带 来的影响。 工作产品实例 1. 变更请求 子实践 1. 发起变更请求并记录在变更请求数据库中。 2. 分析变更请求中提议的变更与修复的影响。 通过确保变更与所有技术及项目需求一致的活动来评价变更。 评价变更对直接的项目或合同需求之外的影响。对在多个产品中使用的 配置项的变更可能解决一个直接问题,而在其它应用中又引发一个问题。 评价变更对发布计划的影响。 3. 对变更请求分类并划分优先级。 116 配置管理(CM) CMMI 开发模型,版本 1.3 SP 2.2 识别紧急请求,适当时提交给紧急权限。 将变更分配到将来的基线中。 4. 与相关干系人一起评审将要在下个基线中处理的变更请求,并达成一 致。 与适当的参加者一起进行变更请求的评审。记录每一变更请求的处置与 决策理由,包括成功准则、适当时一份简要的行动计划、以及变更满足 的或不满足的需要。执行处置中要求的行动并将结果汇报给相关干系人。 5. 跟踪变更请求的状态直到关闭。 要及时有效地处理纳入系统的变更请求。一旦变更请求得到处理,只要 切实可行,以适当的经批准的行动尽快关闭此请求非常关键。让措施长 时间处于未关闭状态会让状态列表变得过于庞大,反而会导致附加的成 本与混乱。 控制配置项 控制配置项的变更。 对工作产品基线的配置保持控制。这种控制包括跟踪每个配置项的配置、 必要时批准新的配置、以及更新基线。 工作产品实例 1. 配置项的修订历史 2. 基线的存档 子实践 1. 在整个产品或服务的生命期,控制对配置项的变更。 2. 在变更后的配置项进入配置管理系统前,获得适当的授权。 例如,授权可来自配置控制委员会、项目经理、产品负责人或客户。 3. 以维护配置项的正确性与完整性的方式,在配置管理系统中检入并检 出配置项以纳入变更。 检入与检出步骤的实例有: • 确定这些修订得到授权 • 更新配置项 • 将旧基线归档,并检索新基线 • 为该项的变更作备注 • 关联对相关工作产品的变更,例如需求、用户故事与测试 4. 执行评审以确保变更没有对基线造成意外的影响(例如,确保变更没 有危及系统的安全性或保密性)。 配置管理(CM) 117 CMMI 开发模型,版本 1.3 SG 3 5. 适当时记录配置项的变更与变更的理由。 如果接受对工作产品提议的变更,则识别将变更纳入工作产品及其它受 影响区域的进度。 可针对变更类别裁剪配置控制机制。例如,对于不影响其他组件的组件 变更的批准考虑可用较低严格度。 已变更的配置项,需经配置变更的评审与批准后才能发布。直到发布后, 变更才正式生效。 建立完整性 基线的完整性得到建立与维护。 基线通过“建立基线”特定目标相关的过程得到建立,通过“跟踪并控制 变更”特定目标相关的过程得到维护,基线的完整性则通过本特定目标下 的特定实践进行应对。 SP 3.1 建立配置管理记录 建立并维护描述配置项的记录。 工作产品实例 1. 配置项的修订历史 2. 变更日志 3. 变更请求记录 4. 配置项的状态 5. 基线间的差异 子实践 1. 足够详细地记录配置管理行动,使得每个配置项的内容与状态都可知, 且能恢复以前的版本。 2. 确保相关干系人能访问并了解配置项的配置状态。 配置状态沟通的活动实例有: • 给授权的最终用户提供访问权限 • 使基线副本对授权的最终用户随时可用 • 当配置项检入、检出、变更、或对变更请求做出决定时,自动提醒相 关干系人 3. 明确说明基线的最新版本。 4. 识别组成特定基线的配置项的版本。 5. 描述连续的基线间的差异。 6. 必要时,修订每个配置项的状态与历史(即:变更,其它行动)。 118 配置管理(CM) CMMI 开发模型,版本 1.3 SP 3.2 执行配置审计 执行配置审计,以维护配置基线的完整性。 配置审计确定所产生的基线与文档符合规定的标准或需求。配置项相关的 记录可以保存在多个数据库或配置管理系统中。在这种情况下,配置审计 应该适当延伸到这些其它的数据库以确保配置项信息的准确性、一致性与 完备性。(见术语表中“配置审计”的定义。) 审计类型的实例有: • 功能配置审计(functional configuration audits,FCAs):这种审计的执 行验证配置项的开发已经符合要求地完成,该项已经达到功能基线或已分 配基线中规定的功能与质量属性特征,而且操作与支持文档是完备的并符 合要求。 • 物理配置审计(physical configuration audits,PCAs):这种审计的执行 验证所构建的配置项符合对其定义并描述的技术文档。 • 配置管理审计:这种审计的执行确定配置管理记录与配置项是完备的、一 致的与准确的。 工作产品实例 1. 配置审计结果 2. 行动项 子实践 1. 评估基线的完整性。 2. 确定配置管理记录正确地识别配置项。 3. 评审配置管理系统中各项的结构与完整性。 4. 确定配置管理系统中各项的完备性、正确性与一致性。 配置管理系统内容的完备性、正确性与一致性基于计划中所述的需求与 已批准的变更请求的处置。 5. 确定符合适用的配置管理标准与规程。 6. 跟踪来自审计的行动项直到关闭。 配置管理(CM) 119 CMMI 开发模型,版本 1.3 120 配置管理(CM) CMMI 开发模型,版本 1.3 决策分析与解决(DAR) 成熟度 3 级支持类过程域 目的 简介 决策分析与解决(Decision Analysis and Resolution,DAR)的目的在于 使用正式的评价过程,遵循已建立的准则,对已识别的多个备选方案进行 评价,以分析可能的决策。 “决策分析与解决”过程域涉及建立指南,用以确定哪些问题需要采用正 式评价过程,并应用正式评价过程来解决这些问题。 正式评价过程是一个结构化的方法,它遵循已建立的准则,对多个备选解 决方案进行评价,以确定一个推荐的方案。 正式评价过程包含以下活动: • 建立评价备选方案的准则 • 识别备选解决方案 • 选择评价备选方案的方法 • 使用已建立的准则和方法评价备选解决方案 • 基于评价准则从备选方案中选择所推荐的方案 本过程域中并非每次都用“解决问题的备选解决方案”这一短语,而是用 “备选解决方案”或者“备选方案”简短地进行替代。 正式评价过程能够降低决策的主观性,并更有可能选出满足相关干系人多 方面要求的解决方案。 虽然本过程域主要用于技术关注点,但正式评价过程可适用于许多非技术 问题,在制订项目计划时则尤为如此。具有多种备选方案并具有评价准则 的各类问题均适合采用正式评价过程。 正式评价过程的典型实例有设备或者软件权衡分析。 在计划过程中,应识别出需要采用正式评价过程的具体问题。典型问题有: 选 择 架 构 或 设 计 的 备 选 方 案 , 使 用 可 复 用 或 商 用 现 货 ( commercial off-the-shelf,COTS)组件、供方的选择、工程支持环境或相关工具、测 试环境、交付备选方案、以及物流和生产等。正式评价过程还能解决以下 问题:自制或购买决策、制造工艺的开发、分销地点的选择、以及其它决 策。 需要为决定何时采用正式评价过程建立指南,以处理未能计划到的问题。 指南通常建议针对涉及中高影响度风险的问题,或影响项目目标达成能力 的问题,采用正式评价过程。 对问题进行妥善定义有助于界定所要考虑的备选方案的范围。合理的范围 (即,既不过分宽泛,也不过分狭窄)将有助于做出恰当的决策以解决所 定义的问题。 正式评价过程在正式程度、准则的类型、以及采用的方法等方面可以有所 不同。相对非正式的决策可能只需要分析几个小时,使用很少几条准则(如 决策分析与解决(DAR) 121 CMMI 开发模型,版本 1.3 相关过程域 有效性、实施成本),最后生成一两页纸的报告。更加正式的决策可能需 要独立的计划,花费几个月的时间,开会进行准则的制订和批准,进行模 拟、原型、试点、以及大量的文档化工作。 正式评价过程可采用数字化的或非数字化的准则。数字化的准则使用权重 来反映准则的相对重要性。而非数字化的准则使用主观的分级尺度(如: 高、中、低)。更加正式的决策可能需要进行全面的权衡分析。 正式评价过程识别并评价备选解决方案。最终解决方案的选定可能包括反 复的识别与评价活动。对已识别的备选方案可能从中抽取不同部分进行合 并,出现的新技术可能改变备选方案,供方的经营情况在评价期间也可能 发生变化。 所推荐的备选方案一并带有所选定的方法、准则、备选方案、以及推荐的 依据等方面的文档资料。这些文档被分发给相关干系人,作为正式评价过 程及其依据的记录。这些对其它遇到类似问题的项目会有所帮助。 在整个项目的生命期中,有些决策会使用正式评价过程,有些决策则不用。 正如前文所述,应该建立指南来决定哪些问题需要采用正式评价过程。 参阅“集成项目管理”过程域以进一步了解如何建立项目已定义的过程。 参阅“风险管理”过程域以进一步了解如何识别与分析风险,并缓解风险。 122 决策分析与解决(DAR) CMMI 开发模型,版本 1.3 SG 1 评价备选方案 SP 1.1 建立决策分析指南 SP 1.2 建立评价准则 SP 1.3 识别备选解决方案 SP 1.4 选择评价方法 SP 1.5 评价备选解决方案 SP 1.6 选择解决方案 按目标排列的特定实践 特定目标与特定实践摘要 SG 1 评价备选方案 使用已建立的准则评价备选方案,并以此作为决策的基础。 任何时候都可能识别出需要使用正式评价过程的问题。目标应该是尽早识 别出问题,以便有尽量充足的时间来解决问题。 SP 1.1 建立决策分析指南 建立并维护用以确定哪些问题需要使用正式评价过程的指南。 并非所有决策都重要到需要使用正式评价过程。如果没有明确的指南,就 难以在无关紧要与举足轻重之间做出选择。一个决策是否重要,依赖于项 目及其所处环境,并根据已建立的指南进行确定。 为确定何时需要使用正式评价过程,典型的指南有: • 决策与中高影响度风险的问题有直接关系 • 决策与变更在配置管理下的工作产品有关 • 决策会引起超过一定比例或一段时间的工期延误 • 决策影响到项目达成其目标的能力 • 与决策影响相比,正式评价过程的成本合理 • 招标过程中存在法律义务 • 当相互竞争的质量属性需求会导致有重大区别的架构备选方案时 参阅“风险管理”过程域以进一步了解如何对风险进行评价、分类并确定优先 级。 可能使用正式评价过程的活动实例有: • 在 20%的零部件占了 80%的原材料成本时,进行关于原材料采购的决策 • 在技术上的性能故障可能导致灾难性故障(例如:与飞行安全有关的零件) 时,进行设计与实现的决策 • 进行可能大大降低设计风险、减少工程变更、缩短项目周期或响应时间, 或者降低生产成本的决策(例如:发布工程图纸和生产制造之前,使用光 刻模型来评估外形与安装匹配能力。) 决策分析与解决(DAR) 123 CMMI 开发模型,版本 1.3 SP 1.2 工作产品实例 1. 关于何时应用正式评价过程的指南 子实践 1. 建立用以确定何时使用正式评价过程的指南。 2. 将指南的使用适当地纳入已定义的过程。 参阅“集成项目管理”过程域以进一步了解如何建立项目已定义的过程。 建立评价准则 建立并维护评价备选方案的准则,以及这些准则的相对等级。 评价准则为评价备选解决方案提供了基础。将准则分级,使等级最高的准 则对评价的影响最大。 模型中的许多其它过程域都会引用到本过程域,正式评价过程可以在很多 场合使用。因此你会发现在某些情况下,准则已经在另一个过程中得到定 义。本特定实践不建议准则的再次制订。 对于待解决的问题和待做出决策的明确表述,有助于集中分析的焦点。这 样的表述也有助于定义评价准则,以减少决策在事后遭到质疑,或做决策 的理由被遗忘的可能性。依据已明确定义及建立的准则所做出的决策,能 够消除干系人认同决策的障碍。 工作产品实例 1. 文档化的评价准则 2. 准则重要性的等级 子实践 1. 定义评价备选解决方案的准则。 准则应该能够追溯到需求、场景、业务的案例假设、业务目标、或其它 文档化的来源。 需要考虑的准则类型有: • 技术限制 • 环境影响 • 风险 • 业务价值 • 对优先级的影响 • 总体拥有成本和生命周期成本 2. 为评价准则进行分级定义范围和尺度。 评价准则的相对重要性尺度的建立,既可使用非数字的值,也可通过公 式将评价参数关联至数字化的权重。 3. 对准则进行分级。 根据已定义的范围和尺度将准则进行分级,以反映相关干系人的需要、 目标、以及优先级。 4. 对准则及其相对重要性进行评估。 124 决策分析与解决(DAR) CMMI 开发模型,版本 1.3 SP 1.3 SP 1.4 5. 完善评价准则以提高其有效性。 6. 将选择或弃用评价准则的依据文档化。 关于选择准则和依据的文档,可用于证明解决方案的合理性,或者供日 后的参考和使用。 识别备选解决方案 识别用以解决问题的备选解决方案。 在可行的情况下,通过从尽可能多的相关干系人那里征求意见,可以得到 范围更为广泛的备选方案。来自技能多样、背景多样的不同干系人的观点, 能帮助团队识别并处理各种主观判断、制约因素和倾向性。头脑风暴会议 可以通过快速的交流与反馈,激发出创新性的备选方案。 分析开始时可能还没有足够多的候选解决方案。随着分析的进行,其它备 选方案应加入到潜在的候选解决方案列表中。在决策分析与解决过程的早 期,生成并考虑多种备选方案,能够提高形成可接受决策的可能性,同时 该决策的后果也更有可能得到理解。 工作产品实例 1. 识别的备选方案 子实践 1. 进行文献检索。 文献检索能够发现组织内部和外部其他人所做过的事情。这样的检索有 助于深入理解问题、所考虑的备选方案、实施中的障碍、业已存在的权 衡分析以及从类似决策中所汲取的教训等。 2. 除了随问题一起提供的解决方案以外,识别值得考虑的其它备选方案。 评价准则是识别备选方案的有效起点。评价准则能够识别相关干系人的 优先级,以及技术、后勤或其它挑战的重要性。 将业已存在的备选方案之中的关键属性进行组合可能会产生额外的,有 时甚至更好的备选方案。 从相关干系人那里征求备选方案。头脑风暴会议、访谈或工作小组等方 式都能用来有效地发现备选方案。 3. 将所提议的备选方案文档化。 选择评价方法 选择评价方法。 对照已建立的准则去评价备选解决方案的方法,其范围可从模拟到使用概 率模型与决策理论。应该对这些方法进行认真的选择。方法的详细程度应 当同成本、进度、绩效和风险影响相匹配。 虽然很多问题可能只需要使用一种评价方法,有些问题却可能需要多种方 法。例如,为确定哪个备选设计方案最符合某一特定准则时,模拟可能会 有助于权衡分析。 工作产品实例 1. 选定的评价方法 子实践 1. 基于分析决策的目的,以及用于支持该方法所用信息的可用程度,选 择方法。 决策分析与解决(DAR) 125 CMMI 开发模型,版本 1.3 例如:在需求定义薄弱的情况下采用的评价方法,可能与需求定义良好 时不同。 典型的评价方法有: • 测试 • 建模与模拟 • 工程分析 • 制造分析 • 成本分析 • 商业机会分析 • 调查 • 基于实地经验和原型的推断 • 最终用户评审与评论 • 专家或专家组提出的判断(例如:德尔菲法[Delphi method]) SP 1.5 2. 选择最能够关注当前问题而不受次要问题过多影响的评价方法。 模拟的结果可能被解决方案中与当前问题不直接相关的偶发性活动所扭 曲。 3. 确定支持评价方法所需的度量项。 考虑对成本、工期、绩效和风险等产生的影响。 评价备选解决方案 使用已建立的准则和方法,评价备选解决方案。 评价备选解决方案包括分析、讨论和评审。分析有时需要进行几轮迭代。 可能需要用到辅助分析、实验、原型、试点、或模拟等来支持评分和结论。 准则的相对重要性往往是不精确的,而且一个解决方案的整体效果通常在 进行分析之后才会变得明显。在评分结果差距微小的情况下,备选解决方 案中的最佳选择或许并不明显。此时应该鼓励挑战准则和所做的假设。 工作产品实例 1. 评价的结果 子实践 1. 使用已建立的评价准则和选定的方法,评价所提议的备选解决方案。 2. 对与评价准则相关的假设以及支持这些假设的证据进行评价。 3. 分析评判备选解决方案分值的不确定性是否会影响到评价工作,并对 这些不确定性进行适当处理。 例如:如果得到的分数在两个分值间波动,其差异是否足以影响最终解 决方案的选择?这样的波动是否预示了一项高影响度的风险?为解决这 些疑虑,除了其他的方法之外,可以进行模拟、进一步的分析、或者修 改评价准则。 4. 必要时通过模拟、建模、原型、或试点等对评价准则、方法、以及备 选解决方案进行预演。 126 决策分析与解决(DAR) CMMI 开发模型,版本 1.3 SP 1.6 未经测试的准则及其相对重要性、以及未经测试的支持数据或函数等可 能会导致解决方案的效力受到质疑。可对一组备选方案进行试用来测试 准则及其优先顺序和尺度。对所选定的一系列准则的这些试用,能够用 来评价准则对一项解决方案的累积影响。如果试用揭示出问题,则可以 考虑不同的准则或备选方案以避免偏差。 5. 如果提议的备选方案测试结果不佳,则考虑新的备选解决方案、准则、 或方法;重复进行评价直到备选方案有良好的测试结果。 6. 将评价结果文档化。 将新增备选方案或方法以及变更准则的依据,以及中间评价的结果文档 化。 选择解决方案 基于评价准则,从备选方案中选择解决方案。 选择解决方案包括对备选方案的评价结果进行权衡考虑。应评估实施解决 方案的关联风险。 工作产品实例 1. 解决重大问题的推荐解决方案 子实践 1. 对实施所推荐解决方案的关联风险进行评估。 参阅“风险管理”过程域以进一步了解如何识别与分析风险,并缓解风 险。 决策经常在信息不完整的情况下必须做出。因信息不完整,这样的决策 可能伴随有重大的风险。 当必须根据特定的进度做出决策时,可能缺少收集完整信息的时间和资 源。因此,在信息不完整时做出的带有风险的决策在日后可能需要进行 再次的分析。已识别的风险应得到监控。 2. 将推荐解决方案的结果和依据文档化,并与相关干系人进行沟通。 重要的是既要记录下为什么选择某一解决方案,也要记录为什么弃用另 一项解决方案。 决策分析与解决(DAR) 127 CMMI 开发模型,版本 1.3 128 决策分析与解决(DAR) CMMI 开发模型,版本 1.3 集成项目管理(IPM) 成熟度 3 级项目管理类过程域 目的 集成项目管理(Integrated Project Management,IPM)的目的在于从组 织的标准过程集中裁剪得到集成的已定义过程,并以此为依据建立并管 理项目以及相关干系人的参与。 简介 “集成项目管理”涉及以下活动: • 在项目启动时,通过裁剪组织的标准过程集建立项目已定义的过程 • 用项目已定义的过程管理项目 • 基于组织的工作环境标准,为项目建立工作环境 • 建立旨在达成项目各项目标的团队 • 使用组织级过程资产并为其做贡献 • 在项目期间,使相关干系人关注的事项得以识别、考虑并在适当的时 候得到处理 • 确保相关干系人(1)协作、及时地执行他们的任务;(2)处理项目 的需求、计划、目标、问题与风险;(3)实现他们的承诺;(4)识 别、跟踪与解决协调问题 从组织的标准过程集中裁剪得到的、集成的、已定义的过程叫做项目已定 义的过程。(见术语表中“项目”的定义。) 管理项目的工作量、成本、进度、人员、风险以及与项目已定义过程中的 各项任务息息相关的其它因素。项目已定义过程的实施与管理通常在项目 计划中描述。某些活动可能在影响项目的其它计划中涉及,例如质量保证 计划、风险管理策略与配置管理计划。 因为每个项目已定义的过程都裁剪自组织的标准过程集,通常项目间的差 异性会被降低,各项目可以比较容易地分享过程资产、数据与经验教训。 本过程域也处理与项目相关的所有活动之间的协调,例如: • 开发活动(如需求开发、设计、验证) • 服务活动(如交付、帮助台、运营、客户联系) • 采购活动(如招标、协议监督、移交运营) • 支持活动(如配置管理、文档、市场、培训) 计划并管理项目内、外部的相关干系人之间的工作接口和交互,以保证所 有努力的质量和完整性。相关干系人可适当参与项目已定义过程和项目计 划的定义。与相关干系人进行定期的评审与交流,以保证协调问题获得适 当的关注,并且涉及项目的所有人都能适当地了解状态、计划与行动。(见 术语表中“相关干系人”的定义。)定义项目已定义的过程时,可能有必 要建立正式的接口,以保证适当的协调与协作。 本过程域适用于任何组织结构,包括采用线性组织、矩阵型组织或者团队 结构的项目。相关术语应当在所处的不同组织架构中得到适当的解读。 集成项目管理(IPM) 129 CMMI 开发模型,版本 1.3 相关过程域 参阅“验证”过程域以进一步了解如何执行同级评审。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 参阅“组织级过程定义”过程域以进一步了解如何建立并维护一套可用的 组织级过程资产、工作环境标准以及团队规则与指南。 参阅“项目监督与控制”过程域以进一步了解如何对照计划监督项目。 参阅“项目计划”过程域以进一步了解如何制订项目计划。 130 集成项目管理(IPM) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 使用项目已定义的过程 SP 1.1 建立项目已定义的过程 SP 1.2 使用组织级过程资产计划项目活动 SP 1.3 建立项目工作环境 SP 1.4 集成各类计划 SP 1.5 使用集成的计划管理项目 SP 1.6 建立团队 SP 1.7 为组织级过程资产做出贡献 SG 2 与相关干系人协调并协作 SP 2.1 管理干系人的参与 SP 2.2 管理依赖 SP 2.3 解决协调问题 按目标排列的特定实践 SG 1 使用项目已定义的过程 项目的进行得以使用从组织标准过程集裁剪得到的已定义的过程。 项目已定义的过程包含了来自组织的标准过程集的过程,这些过程说明了 采购、开发、维护或者交付特定产品所必须的所有过程。 产品相关的生命周期过程,例如制造与支持过程,与产品同步进行开发。 SP 1.1 建立项目已定义的过程 从项目启动开始并贯穿项目生命期的始终,建立并维护项目已定义的 过程。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产并 建立组织的度量库。 参阅“组织级过程关注”过程域以进一步了解如何部署组织级过程资产并 部署标准过程。 项目已定义的过程由为项目构成一个集成的、连贯的生命周期的一组已定 义的过程组成。 项目已定义的过程应满足项目的合同需求、运营需要、机会与约束。其设 计以最适应项目需要为目的。 项目已定义的过程依据以下因素: • 干系人需求 • 承诺 • 组织级过程需要与目标 • 组织的标准过程集与裁剪指南 • 操作环境 • 业务环境 在项目启动时建立项目已定义的过程,有助于确保项目人员与相关干系人 实施一系列活动,以有效地建立项目初始需求集和计划。随着项目的进展, 项目已定义的过程的描述会被细化与修订,以更好地满足项目需求与组织 的过程需要和目标。另外当组织的标准过程集变更时,项目已定义的过程 可能也需要修订。 集成项目管理(IPM) 131 CMMI 开发模型,版本 1.3 工作产品实例 1. 项目已定义的过程 子实践 1. 从组织级过程资产中现有的模型里,选择一个生命周期模型。 能够影响生命周期模型选择的项目特性实例有: • 项目的规模或复杂性 • 项目策略 • 人员实施过程的经验与熟悉程度 • 约束,如周期时间与可接受的缺陷级别 • 客户回答问题并对增量提供反馈的可能性 • 需求的清晰度 • 客户期望 2. 从组织的标准过程集中选择最适合项目需要的标准过程。 3. 依据裁剪指南,对组织的标准过程集与其它组织级过程资产进行裁剪, 以形成项目已定义的过程。 有时已有的生命周期模型与标准过程并不足以满足项目需要。这种情况 下,项目应寻求对于其偏离组织要求的批准。豁免就是为实现这一目的 而提供的。 裁剪包括使用组织的公共度量项并明确说明额外的度量项来满足项目的 信息需要。 4. 适当地使用组织过程资产库中的其它材料。 其它材料可以包括: • 经验教训文档 • 模板 • 范例文档 • 估算模型 5. 将项目已定义的过程文档化。 项目已定义的过程涵盖了项目的所有活动以及项目与相关干系人的接口。 132 集成项目管理(IPM) CMMI 开发模型,版本 1.3 项目活动的实例有: • 项目计划 • 项目监督 • 供方管理 • 质量保证 • 风险管理 • 决策分析与解决 • 需求开发 • 需求管理 • 配置管理 • 产品开发与支持 • 代码评审 • 招标 SP 1.2 6. 对项目已定义的过程进行同级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 7. 必要时修订项目已定义的过程。 使用组织级过程资产计划项目活动 使用组织级过程资产与度量库来估算并计划项目活动。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 如有可能,则将以往计划与执行活动的结果作为被估算工作量的相对范围 与风险的预测因子。 工作产品实例 1. 项目估算结果 2. 项目计划 子实践 1. 使用项目已定义过程的任务与工作产品作为对项目活动进行估算与 计划的基础。 对于项目已定义过程的诸多任务与工作产品之间关系的理解,以及对于 相关干系人所执行角色的理解,是制订一个可行的计划的基础。 2. 在项目计划参数的估算中,使用组织的度量库。 该估算通常包括: • 该项目或类似项目的适当历史数据 • 当前项目与提供历史数据的项目间的异同点 • 确认过的历史数据 • 选择该历史数据的原因、假设与依据 • 众多有经验的项目参加者的论证 集成项目管理(IPM) 133 CMMI 开发模型,版本 1.3 用于考量异同点的参数实例有: • 工作产品与任务属性 • 应用领域 • 人员经验 • 设计与开发方法 • 操作环境 组织的度量库中的数据实例有: • 工作产品规模或其它工作产品属性 • 工作量 • 成本 • 进度 • 人员配备 • 响应时间 • 服务能力 • 供方绩效 • 缺陷 SP 1.3 建立项目工作环境 基于组织的工作环境标准,建立并维护项目的工作环境。 一个项目的适当的工作环境由设施、工具与设备的基础设施构成,人员用 以有效执行其工作,以支持业务与项目的目标。工作环境及其组件需要维 持一定的、由组织工作环境标准所指定的性能与可靠性水平。项目工作环 境或其组件可以根据实际需要由内部开发或者从外部来源采购。 项目工作环境可能包含产品集成、验证与确认环境,也可能是各自单独的 环境。 参阅“产品集成”过程域中的“建立产品集成环境”特定实践以进一步了 解如何为项目建立并维护产品集成环境。 参阅“确认”过程域中的“建立确认环境”特定实践以进一步了解如何为 项目建立并维护确认环境。 参阅“验证”过程域中的“建立验证环境”特定实践以进一步了解如何为 项目建立并维护验证环境。 参阅“组织级过程定义”过程域中的“建立工作环境标准”特定实践以进 一步了解工作环境标准。 工作产品实例 1. 项目的设备与工具 2. 项目工作环境的安装、运行与维护手册 3. 用户调查与结果 134 集成项目管理(IPM) CMMI 开发模型,版本 1.3 4. 使用、性能与维护记录 5. 为项目工作环境提供的支持服务 子实践 1. 为项目计划、设计并安装工作环境。 与其它任何产品一样,项目工作环境的关键点也是需求驱动的。对于工 作环境的功能与质量属性的考察应像其它任何产品开发项目一样严格。 可能有必要在质量属性、成本、风险之间做一定取舍。以下各给出一些 实例: • 对质量属性的考虑可以包括实时通讯、安全性、保密性与可维护性。 • 成本可以包括资本支出、培训、支持结构、现有环境的拆卸与处置以 及环境的运作与维护。 • 风险可以包括工作流与项目的异常中断。 设备与工具的实例有: • 办公软件 • 决策支持软件 • 项目管理工具 • 测试与评价设备 • 需求管理工具与设计工具 • 配置管理工具 • 评价工具 • 集成工具 • 自动化测试工具 2. 为项目工作环境提供持续的维护与运作支持。 工作环境的维护与支持可通过组织内部挖潜或组织外部雇佣来实现。 维护与支持方法的实例有: • 雇佣人员进行维护与支持 • 培训人员进行维护与支持 • 签订维护与支持合同 • 为所选用的工具培养专家级用户 3. 维护项目工作环境组件的合格证明。 组件包括软件、数据库、硬件、工具、测试设备以及适当的文档。软件 的合格证明包括适当的认证。硬件与测试环境的合格证明包括校准与调 试记录以及对校准标准的可追溯性。 集成项目管理(IPM) 135 CMMI 开发模型,版本 1.3 4. 定期评审工作环境满足项目需要与支持协作的程度,并适当地采取措 施。 可能采取的措施实例有: • 添加新工具 • 采购额外的网络、设备、培训与支持 SP 1.4 集成各类计划 集成项目计划与影响项目的其它计划,以描述项目已定义的过程。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产, 特别是,如何建立组织的度量库。 参阅“组织级过程关注”过程域以进一步了解如何建立组织过程需要与确 定过程改进机会。 参阅“项目计划”过程域以进一步了解如何制订项目计划。 本特定实践将建立并维护项目计划的特定实践进行拓展,以描述额外的计 划活动,如纳入项目已定义的过程、与相关干系人协作、使用组织级过程 资产、纳入同级评审计划以及建立任务客观的入口与出口准则等。 项目计划的制订应适当考虑组织、客户、供方以及最终用户的、当前的与 规划中的需要、目标与需求。 工作产品实例 1. 集成的计划 子实践 1. 将影响项目的其它计划与项目计划集成起来。 影响项目计划的其它计划有: • 质量保证计划 • 风险管理策略 • 验证与确认计划 • 移交至运营与支持的计划 • 配置管理计划 • 文档计划 • 人员培训计划 • 设施与后勤计划 2. 将用于管理项目的度量项定义与度量活动纳入到项目计划中。 应被纳入的度量项实例有: • 组织的公共度量项 • 项目特定的、额外的度量项 参阅“度量与分析”过程域以进一步了解如何开发并保持用于支持管理 信息需要的度量能力。 136 集成项目管理(IPM) CMMI 开发模型,版本 1.3 3. 识别并分析产品与项目接口风险。 参阅“风险管理”过程域以进一步了解如何识别并分析风险。 产品与项目接口风险的实例有: • 不完整的接口描述 • 缺乏工具、供方或测试设备 • 缺乏 COTS 组件 • 不充分或无效的团队接口 4. 考虑关键的开发与交付要素以及项目风险,排定任务进度顺序。 在进度排序时考虑的要素实例有: • 任务规模与复杂度 • 客户与最终用户的需要 • 关键资源的可用性 • 关键人员的可用性 • 集成与测试问题 SP 1.5 5. 将对项目已定义过程的工作产品执行的同级评审纳入到计划中。 参阅“验证”过程域以进一步了解如何执行同级评审。 6. 将执行项目已定义的过程所需的培训纳入到项目培训计划中。 本任务通常包含与组织级培训团队协商他们所提供的支持。 7. 建立客观的入口与出口准则,以授权启动与完成工作分解结构(work breakdown structure,WBS)中描述的各项任务。 参阅“项目计划”过程域以进一步了解如何估算项目范围。 8. 确保项目计划与相关干系人的计划适当兼容。 通常应对计划及其变更进行兼容性评审。 9. 确定如何解决相关干系人之间产生的冲突。 使用集成的计划管理项目 使用项目计划、影响项目的其它计划以及项目已定义的过程来管理项 目。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 参阅“组织级过程关注”过程域以进一步了解如何建立组织过程需要、部 署组织级过程资产以及部署标准过程。 参阅“项目监督与控制”过程域以进一步了解如何提供对项目进展的了解, 以在项目绩效显著偏离计划时采取适当的纠正措施。 参阅“风险管理”过程域以进一步了解如何识别与分析风险,并缓解风险。 工作产品实例 1. 执行项目已定义的过程所产生的工作产品 2. 收集的度量项(即实际的)与状态记录或报告 集成项目管理(IPM) 137 CMMI 开发模型,版本 1.3 3. 修订的需求、计划与承诺 4. 集成的计划 子实践 1. 使用组织的过程资产库实施项目已定义的过程。 该项任务通常包含以下活动: • 将组织过程资产库中的成果适当地纳入到项目中 • 使用组织的过程资产库中的经验教训来管理项目 2. 使用项目已定义的过程、项目计划及影响项目的其它计划来监督与控 制项目的活动与工作产品。 该项任务通常包含以下活动: • 使用已定义的入口与出口准则来授权任务的启动并确定任务的完成 • 监督可能明显影响项目计划参数实际值的活动 • 使用将会触发调查与适当行动的可度量的阈值来跟踪项目参数 • 监督产品与项目接口风险 • 基于项目已定义过程的任务与产品的计划,管理外部与内部承诺 对于项目已定义过程的任务与工作产品间关系的理解以及对于相关干系 人所执行角色的理解,与完整定义的控制策略(如同级评审)一起,可 以更清晰地了解项目的绩效,并更好地控制项目。 3. 获得与分析所选定的度量,以管理项目并支持组织需要。 参阅“度量与分析”过程域以进一步了解如何获得度量数据并分析度量 数据。 4. 定期评审项目绩效,并适当地使之与组织、客户以及最终用户当前的 和期望的需要、目标及需求保持一致。 该评审包括与组织的过程需要及目标的协调一致。 达成协调一致的行动实例有: • 对其它计划参数与项目风险进行适当调整,变更进度 • 变更需求或承诺,以响应市场机会或客户、最终用户需要的变化 • 终止项目、迭代或发布 5. 处理选定的、可能影响项目目标的问题的原因。 需要采取纠正措施的问题的确定与分析,是在“项目监督与控制”过程 域的“分析问题”与“采取纠正措施”特定实践中进行的。适当时,项 目可定期地评审以前其它项目或本项目早期阶段所遇到的问题,并对选 定问题进行原因分析,以确定如何防范可能明显影响项目目标的问题的 重复发生。对于作为原因分析活动的结果所实施的项目过程变更,应进 行效果评价,以确保该过程变更已经防范了重复发生并提高了绩效。 138 集成项目管理(IPM) CMMI 开发模型,版本 1.3 SP 1.6 SP 1.7 建立团队 建立并维护团队。 项目采用团队的方式进行管理,这些团队反映了组织关于团队结构、组建 与运作的规则与指南。(见术语表中“团队”的定义。) 在建立团队结构之前建立项目的共同愿景,团队结构可以基于 WBS 建立。 对于小的组织,整个组织及其相关外部干系人可以被视为一个团队。 参阅“组织级过程定义”过程域中的“建立团队的规则与指南”特定实践 以进一步了解如何建立并维护团队的结构、组建与运作的组织级规则与指 南。 将相关干系人纳入团队,是确保与他们的协调与协作的最佳方式之一。 在需要多个产品或服务开发组织相互协作的客户环境中,建立一个由影响 总体成功的所有各方代表参加的团队是很重要的。这些代表能帮助确保这 些组织间的有效协作,包括及时地解决或协调问题。 工作产品实例 1. 文档化的共同愿景 2. 分配到各个团队的成员列表 3. 团队章程 4. 定期的团队状态报告 子实践 1. 建立并维护项目的共同愿景。 形成共同愿景时,理解项目与项目外部干系人之间的接口是非常关键的。 该愿景应在相关干系人中分享并获得他们的同意与承诺。 2. 建立并维护团队结构。 评估项目 WBS、成本、进度、项目风险、资源、接口、项目已定义的过 程与组织级的指南,以建立一个适当的团队结构,包括团队职责、权限 及相互关系。 3. 建立并维护每个团队。 建立并维护团队包括为每个团队选择团队领导、团队成员并建立团队章 程。也包括提供所需的资源以完成赋予该团队的任务。 4. 定期评估团队结构与组成。 应对各团队进行监督,以发现不同团队间工作的不一致性、管理不善的 接口以及给团队成员的任务不匹配等。当团队或项目绩效未能满足期望 时采取纠正措施。 为组织级过程资产做出贡献 将过程相关经验贡献给组织级过程资产。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产、 建立组织的度量库以及建立组织的过程资产库。 参阅“组织级过程关注”过程域以进一步了解如何将经验纳入组织级过程 资产。 本特定实践阐明的是如何将来自项目已定义过程中部分过程的信息贡献 给组织级过程资产。 集成项目管理(IPM) 139 CMMI 开发模型,版本 1.3 工作产品实例 1. 针对组织级过程资产的改进建议 2. 从项目中收集的实际过程与产品度量项 3. 文档(如可做为范例的过程描述、计划、培训模块、检查单、经验教 训) 4. 项目裁剪与实施组织标准过程集的相关过程成果 子实践 1. 向组织级过程资产提交改进建议。 2. 将过程与产品度量项存入组织的度量库中。 参阅“度量与分析”过程域以进一步了解如何获得度量数据。 参阅“项目监督与控制”过程域以进一步了解如何监督项目计划参数。 参阅“项目计划”过程域以进一步了解如何计划数据管理。 这些过程与产品度量项通常包括: • 计划数据 • 重新计划数据 由项目记录的数据实例有: • 任务描述 • 假设 • 估算 • 修订的估算 • 对所记录的数据与度量项的定义 • 度量项 • 将度量项与所执行的活动、所产生的工作产品关联起来的背景情况信 息 • 重建已有估算、评价其合理性以及对新工作进行估算所需的相关信息 3. 提交可能会被纳入到组织的过程资产库的文档。 文档实例有: • 可做为范例的过程描述 • 培训模块 • 可做为范例的计划 • 检查单与模板 • 项目信息库的框架 • 工具配置 4. 将项目经验教训文档化,以纳入到组织的过程资产库中。 140 集成项目管理(IPM) CMMI 开发模型,版本 1.3 SG 2 5. 提供与裁剪、实施组织的标准过程集相关的过程成果,以支持组织的 过程监督活动。 参阅“组织级过程关注”过程域中的“监督实施”特定实践以进一步了 解组织为理解标准过程在一个新的或已有项目中的部署范围所采取的行 动。 与相关干系人协调并协作 项目与项目相关干系人之间的协调与协作得到开展。 SP 2.1 管理干系人的参与 管理相关干系人在项目中的参与。 依据项目的集成计划与已定义过程来管理干系人的参与。 参阅“项目计划”过程域以进一步了解如何计划干系人的参与并获得对计 划的承诺。 工作产品实例 1. 协作活动的议程与进度 2. 相关干系人问题的解决建议 3. 记录的问题(如与干系人需求、产品与产品组件需求、产品架构、产 品设计相关的问题) SP 2.2 子实践 1. 与应该参加项目活动的相关干系人展开协作。 相关干系人应已在项目计划中得到确定。 2. 确保为满足承诺而产出的工作产品符合接收者的需求。 参阅“验证”过程域以进一步了解如何验证选定的工作产品。 产出的满足承诺的工作产品可以是服务。 该任务通常包括: • 对每个由相关干系人产出的工作产品进行适当的评审、演示或测试 • 对每个由项目为其它项目生产的,并由该项目代表接收的工作产品, 进行适当的评审、演示或测试 • 解决与工作产品验收相关的问题 3. 提出建议与协调措施,以解决对需求的误解与问题。 管理依赖 与相关干系人共同识别、协商并跟踪关键依赖。 工作产品实例 1. 与相关干系人一起评审时产生的缺陷、问题与行动项 2. 关键依赖 3. 对于处理关键依赖的承诺 4. 关键依赖的状态 子实践 1. 与相关干系人一起进行评审。 集成项目管理(IPM) 141 CMMI 开发模型,版本 1.3 2. 识别所有关键依赖。 3. 基于项目进度建立每个关键依赖的需要日期和计划日期。 4. 与负责提供或接收工作产品的一方,就针对每个关键依赖的承诺进行 评审并达成一致。 5. 将关键依赖与承诺文档化。 承诺记录通常包括: • 对承诺的描述 • 识别承诺方 • 识别履行承诺方 • 明确何时履行承诺 • 明确承诺是否被履行的判定标准 SP 2.3 6. 跟踪关键依赖与承诺,并采取适当的纠正措施。 参阅“项目监督与控制”过程域以进一步了解如何监督承诺。 跟踪关键依赖通常包括: • 评价延迟或提前完成对于未来活动与里程碑的影响 • 尽可能地与责任方共同解决实际与潜在的问题 • 将负责的个人或团体无法解决的实际与潜在的问题进行适当的升级 处理 解决协调问题 与相关干系人共同解决问题。 协调问题的实例有: • 产品与产品组件的需求与设计缺陷 • 延迟的关键依赖与承诺 • 产品级的问题 • 无法获得关键的资源或人员 工作产品实例 1. 相关干系人的协调问题 2. 相关干系人的协调问题的状态 子实践 1. 识别并记录问题。 2. 向相关干系人沟通问题。 3. 与相关干系人一同解决问题。 4. 将与相关干系人无法解决的问题上报到适当的管理人员。 5. 跟踪问题直至关闭。 6. 就问题的状态与解决,与相关干系人展开沟通。 142 集成项目管理(IPM) CMMI 开发模型,版本 1.3 度量与分析(MA) 成熟度 2 级支持类过程域 目的 简介 度量与分析(Measurement and Analysis,MA)的目的在于开发并保持 用于支持管理信息需要的度量能力。 “度量与分析”过程域涉及以下活动: • 明确说明度量与分析的目标,使其与所识别的信息需要及项目、组织 级或业务目标协调一致 • 明确说明度量项、分析技术以及数据收集、数据存储、报告与反馈的 机制 • 实施分析技术以及数据收集、数据报告与反馈的机制 • 提供客观的结果,这些结果可用于做出有根据的决策以及采取适当的 纠正措施 度量与分析活动集成到项目过程中支持以下的活动: • 客观的计划与估算 • 对照建立的计划与目标跟踪实际的进展与绩效 • 识别并解决过程相关的问题 • 为将来把度量纳入其它过程提供基础 为实现度量能力所需的员工可以属于也可以不属于单独的组织层面的项 目。度量能力可以集成到个别项目或其它组织级职能中(例如:质量保证)。 度量活动最初的关注点在项目级。然而,度量能力可能证明对组织与企业 层面的信息需要也是有用的。为了支持这个能力,度量活动应该支持多级 别的信息需要,包括业务、组织级单位与项目,以随着组织成熟度的提高 将返工减到最少。 项目可以在其特定的存储库中保存项目特定的数据与结果,但是当数据将 要被广泛使用或被分析以支持确定数据趋势或基准时,数据可存放在组织 的度量库中。 为有效管理项目质量与成本,对供方提供的产品组件进行度量与分析极为 重要。对供方协议的细致管理可深入了解支持供方绩效分析的数据。 度量目标是从来源于项目、组织级或业务目标的信息需要导出的。在这个 过程域中,术语“目标”在没有“度量”限定的情况下使用时,它表示项 目、组织级或业务目标。 度量与分析(MA) 143 CMMI 开发模型,版本 1.3 相关过程域 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“配置管理”过程域以进一步了解如何使用配置识别、配置控制、配 置状态记录与报告以及配置审计来建立并维护工作产品的完整性。 参阅“组织级过程定义”过程域以进一步了解如何建立组织的度量库。 参阅“项目监督与控制”过程域以进一步了解如何监督项目计划参数。 参阅“项目计划”过程域以进一步了解如何建立估算。 参阅“量化项目管理”过程域以进一步了解如何量化管理项目。 参阅“需求管理”过程域以进一步了解如何维护需求的双向可追溯性。 144 度量与分析(MA) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 使度量与分析活动协调一致 SP 1.1 建立度量目标 SP 1.2 明确说明度量项 SP 1.3 明确说明数据收集与存储的规程 SP 1.4 明确说明分析规程 SG 2 提供度量结果 SP 2.1 获得度量数据 SP 2.2 分析度量数据 SP 2.3 存储数据与结果 SP 2.4 沟通结果 按目标排列的特定实践 SG 1 使度量与分析活动协调一致 度量目标和活动与所识别的信息需要和目标协调一致。 本特定目标下的特定实践可以并行处理或按任意顺序处理。 建立度量目标时,有经验的人通常提前考虑明确说明度量项与分析规程的 必要准则。同时他们也考虑数据收集与存储规程带来的限制。 通常在专注于度量规格说明、数据收集或存储的细节之前,重要的是先明 确将要进行的分析。 SP 1.1 建立度量目标 建立并维护从所识别的信息需要与目标中导出的度量目标。 度量目标将度量与分析的目的文档化,并明确说明基于数据分析结果可能 采取措施的种类。度量目标还可以识别预期的行为变化,作为实施度量与 分析活动的结果。 度量目标可能受限于现有过程、可用资源或其它度量相关的考虑因素。可 能需要判断结果的价值是否与投入这项工作的资源相当。 反之,对已识别的信息需要与目标的修改,又可看作是度量与分析的过程 及结果所带来的影响。 信息需要与目标的来源可能有: • 项目计划 • 项目绩效监控 • 与管理人员和其他有信息需要者的访谈 • 已建立的管理目标 • 战略计划 • 业务计划 • 正式需求或合同责任 • 重复发生的或其它棘手的管理或技术问题 • 其它项目或组织级实体的经验 • 外部行业基准 • 过程改进计划 度量与分析(MA) 145 CMMI 开发模型,版本 1.3 度量目标的实例有: • 提供进度波动与进展的洞察 • 提供实际规模与计划比较的洞察 • 识别计划外的增长 • 在整个产品开发生命周期内评价缺陷检测的有效性 • 确定修复缺陷的成本 • 提供实际成本与计划比较的洞察 • 对照计划评价供方进展 • 评价规避信息系统弱点的有效性 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“项目监督与控制”过程域以进一步了解如何监督项目计划参数。 参阅“项目计划”过程域以进一步了解如何建立估算。 参阅“需求管理”过程域以进一步了解如何维护需求的双向可追溯性。 工作产品实例 1. 度量目标 子实践 1. 将信息需要与目标文档化。 2. 为信息需要与目标划分优先级。 对所有最初识别的信息需要都进行度量与分析既不可能也无此必要。需 要在可用资源限制下,设定优先级。 3. 将度量目标文档化,并对其进行评审与更新。 仔细考虑度量与分析的目的与预期用途。 将度量目标文档化,并提交管理层与其他相关干系人评审,必要时进行 更新。这样做使后续度量与分析活动的可追溯性成为可能,并有助于确 保分析活动恰当地应对所识别的信息需要与目标。 重要的是,让度量与分析结果的使用者参与度量目标设定以及行动计划 的决定。让提供度量数据的人员参与进来可能也是合适的作法。 4. 必要时提供反馈信息,以细化并澄清信息需要与目标。 作为设定度量目标的结果,所识别的信息需要与目标可能被细化与澄清。 信息需要的初始描述可能存在歧义。已有的需要与目标之间可能存在冲 突。对一个已存在的度量项的精确目标可能不切实际。 5. 维护度量目标对所识别的信息需要与目标的可追溯性。 对“我们为什么度量这个?”的提问,应该永远有好的答案。 当然,度量目标也可以修改,以反映不断发展的信息需要与目标。 146 度量与分析(MA) CMMI 开发模型,版本 1.3 SP 1.2 明确说明度量项 明确说明应对度量目标的度量项。 将度量目标细化为精确的、可计量的度量项。 项目与组织级工作的度量通常可以追溯到一个或多个度量信息类型。这些 类型包括:进度与进展、工作量与成本、规模与稳定性以及质量。 度量项可以是基本的或衍生的。基本度量项的数据通过直接度量得到。衍 生度量项的数据来自于其它数据,一般通过组合两个或多个基本度量项。 通常使用的基本度量项的实例有: • 工作产品规模的估算与实际度量项(例如,页数) • 工作量与成本的估算与实际度量项(例如,人时数) • 质量度量项(例如,按严重性分类的缺陷数) • 信息安全性度量项(例如,已识别的系统弱点的个数) • 客户满意度调查分数 通常使用的衍生度量项的实例有: • 挣值 • 进度性能指标 • 缺陷密度 • 同级评审覆盖度 • 测试或验证覆盖度 • 可靠性度量项(例如,平均失效间隔时间) • 质量度量项(例如,按照严重性分类的缺陷个数/总缺陷个数) • 信息安全性度量项(例如,已规避的系统弱点的百分比) • 客户满意度趋势 衍生度量项通常以比例、合成指标或其它聚合的汇总度量项来表示。衍生 度量项比生成它们的基本度量项从量化角度更加可靠,且解释起来更有意 义。 在信息需要、度量目标、度量类型、基本度量项与衍生度量项之间存在直 接关系。这种直接关系在表 MA.1 中使用一些常用的实例进行了描述。 度量与分析(MA) 147 CMMI 开发模型,版本 1.3 表 MA.1:度量关系实例 项目、组织级或业务 目标实例 缩短交付时间 成为率先上市的产 品 信息需要 估算的交付时 间是何时? 度量目标 提供进度波动与 进展的洞察 度量信息 类型 进度与进 展 基本度量项实例 任务的估算与实际 的开始及结束日期 衍生度量项实例 里程碑绩效 按时完成项目的百 分比 通过降低产品与服 务的成本来增加市 场份额 交付规定的功能 规模与成本的 估算准确性如 何? 范围或项目规 模增加了吗? 提供实际规模与 成本相对于计划 偏差的洞察 提供实际规模相 对于计划的偏差 的洞察,识别计 划外的增长 规模与工 作量 工作量与 成本 规模与稳 定性 估算与实际的工作 量与规模 估算与实际的成本 需求数 功能点数 进度估算的准确性 生产率 成本绩效 成本偏差 需求易变性 规模估计的准确度 估计功能点个数和 实际功能点个数对 比 代码行数 新增、修改与复用 的代码数量 不影响成本的前提 下,交付给客户的产 品的缺陷降低 10% 在交付之前,缺 陷在哪里注入 以及哪里被发 现? 在整个产品生命 周期中,评价缺 陷检测的有效性 质量 按生命周期阶段注 入及发现的缺陷个 数 产品规模 生命周期阶段的缺 陷检出比率 缺陷密度 返 工 成 本 有 多 确定修复缺陷的 成本 少? 成本 按生命周期阶段注 返工成本 入及发现的缺陷个 数 修复缺陷花费的工 时 劳动力成本单价 减少信息系统弱点 未 解 决 的 系 统 评价缓解系统弱 信息保证 弱点的量级? 点的有效性 已识别的系统弱点 已缓解的系统弱点 个数与已缓解的系 百分比 统弱点个数 148 度量与分析(MA) CMMI 开发模型,版本 1.3 SP 1.3 工作产品实例 1. 基本度量项与衍生度量项的规格说明 子实践 1. 基于文档化的度量目标识别备选度量项。 度量目标被细化成为度量项。按度量项的名称与单位对备选度量项进行 分类并明确说明。 2. 维护度量项对度量目标的可追溯性。 备选度量项之间的相互依赖关系得到识别,使后续的数据确认与备选分 析成为可能,以支持度量目标。 3. 识别现有的并且已经应对度量目标的度量项。 度量项的规格说明可能已经存在,或许是早先为其它目的建立的,或是 组织中别处建立的。 4. 明确说明度量项的可操作定义。 以精确且没有歧义的方式对可操作定义进行陈述。它们满足两个重要的 准则: • 沟通:已经度量了什么,如何度量的、度量项的单位是什么、以及已 经包括或排除了什么? • 可重复性:在相同的定义下,度量可以重复,以得到相同的结果吗? 5. 对度量项进行优先级划分、评审与更新。 与潜在的最终用户和其他相关干系人一起,评审所建议的度量项规格说 明的适宜性。设置或更改优先级,必要时更新度量项的规格说明。 明确说明数据收集与存储的规程 明确说明如何获得并存储度量数据。 收集方法的明确规格说明有助于确保适当地收集正确的数据。该规格说明 也有助于进一步澄清信息需要与度量目标。 适当注意存储与检索规程有助于确保数据的可用性与可访问性,以便将来 使用。 工作产品实例 1. 数据收集与存储规程 2. 数据收集工具 子实践 1. 识别现有的数据源,它们是从当前工作产品、过程或事务中产生的。 明确说明度量项时,可能已经识别了现有的数据源。无论是否采集了有 关的数据,适当的采集机制可能已经存在。 2. 识别那些需要数据但数据当前不可用的度量项。 3. 为每个需要的度量项详细说明如何收集并存储数据。 明确的规格说明包括数据收集与存储的内容、方式、地点及时间,以确 保数据的有效性并支持后续分析与编写文件之用。 度量与分析(MA) 149 CMMI 开发模型,版本 1.3 通常需要考虑的问题有: • 是否已经确定了收集的频率以及在过程中的哪些点进行度量? • 是否已经建立了必须满足的时间表,确保度量结果及时从收集点转移 到存储库、其他数据库或者最终用户? • 谁负责获得数据? • 谁负责数据的存储、检索以及安全性? • 是否已经开发或采购了必要的支持工具? 4. 创建数据收集机制与过程指南。 将数据收集与存储机制和其它正常工作过程妥善地集成在一起。数据收 集机制可以包括手工或自动化的表格与模板。对负责进行该工作的人提 供有关正确规程的清晰简明的指南。必要时提供培训,以阐明收集完备 且准确数据的必要过程,并使提供并记录数据的人员的负担减到最小。 5. 适当且可行时,支持自动化收集数据。 自动化支持的实例有: • 有时间标志的活动日志 • 产物的静态或动态分析 SP 1.4 6. 对数据收集与存储规程进行优先级划分、评审及更新。 与负责提供、收集并存储数据的人员一起,评审所建议规程的适宜性与 可行性。他们还可能对如何改进现有过程提供有用的见解,或者能够建 议其它有用的度量项或分析。 7. 必要时更新度量项与度量目标。 明确说明分析规程 明确说明如何分析并沟通度量数据。 事先明确说明分析规程,确保能进行适当的分析与报告以应对文档化的度 量目标(从而也应对作为它们基础的信息需要与目标)。这个方法也是对 实际是否收集了必要数据的一种检查。分析规程应该说明所有进入分析的 数据(不论来源于项目、组织的度量库或其它来源)的质量(例如,年龄, 可靠性)。为有助于选择适当的分析规程并评价分析的结果,应当考虑数 据的质量。 工作产品实例 1. 分析说明与规程 2. 数据分析工具 子实践 1. 明确说明要进行的分析与要准备的报告,并划分优先级。 在早期注意将要进行的分析,以及报告结果的方式。这些分析与报告应 满足以下准则: • 分析明确地应对了文档化的度量目标。 • 结果的展示对于结果报告的受众是清楚易懂的。 可能需要为可用资源划分优先级。 150 度量与分析(MA) CMMI 开发模型,版本 1.3 2. 选择适当的数据分析方法与工具。 需要特别注意的问题有: • 可视化显示方法与其它展示技术的选择 (例如,饼图,柱状图,直 方图,雷达图,线条图,散点图及表格) • 适当的描述性统计的选择(例如,算术平均,中位数与众数) • 当不可能或不需要检查每个数据元素时,统计抽样准则的决定 • 如何处理出现数据元素缺失情况下的分析的决定 • 适当的分析工具的选择 描述性统计通常用于数据分析,以执行以下活动: • 检查规定的度量项的分布(例如,中心趋势,偏差程度,揭示异常偏 差的数据点) • 检查规定的度量项之间的相互关系(例如,产品生命周期不同阶段的 缺陷对比,产品不同组件的缺陷对比) • 显示随时间的变化情况 参阅“量化项目管理”过程域中的“选择将用于量化管理的度量项与 分析技术”特定实践以进一步了解如何适当使用统计技术与理解偏差。 3. 明确说明分析数据并沟通结果的管理规程。 需要考虑的问题通常有: • 识别负责分析数据并展示结果的人员与小组 • 确定分析数据并展示结果的时间表 • 确定沟通结果的方式(例如,进展报告、传阅备忘录,书面报告或员 工会议) 4. 评审并更新规定的分析与报告的建议内容与形式。 所有建议的内容与形式都应该经过评审与修订,包括分析方法与工具、 管理规程以及优先级。被咨询的相关干系人应该包括最终用户、发起人、 数据分析人员与数据提供人员。 5. 必要时,更新度量项与度量目标。 正如度量需要驱动数据分析,分析准则的澄清则会影响度量。依据为数 据分析规程建立的规格说明,一些度量项的规格说明可能会进一步细化。 其它一些度量项可能被证明是不必要的,或者可能发现还需要其它度量 项。 通过对如何分析并报告度量项进行明确说明,也可能得到度量目标本身 需要细化的建议。 6. 明确说明准则,以评价分析结果的效用以及度量与分析活动的执行。 评价分析结果效用的准则可能说明如下条目适用到的程度: • 提供的结果及时、清晰易懂并用于做决策。 • 相对其提供的收益而言,该工作的成本不高。 度量与分析(MA) 151 CMMI 开发模型,版本 1.3 评价度量与分析活动执行情况的准则可能包括如下条目适用到的程度: • 数据遗漏或标示为不一致的数目超过规定的阈值。 • 采样中存在选择偏见(例如,只调查满意的最终用户来评价最终用户 的满意度,或者只评价不成功的项目来确定总的生产率)。 • 度量数据可重复(例如,统计上的可靠性)。 • 统计假设已被满足(例如,关于数据的分布,关于适当的度量尺度)。 SG 2 提供度量结果 应对所识别的信息需要与目标的度量结果得到提供。 进行度量与分析的主要原因是要应对所识别的源于项目、组织级与业务目 标的信息需要。基于客观证据的度量结果能够帮助监督进展与绩效,履行 供方协议中文档化的职责,做出有根据的管理与技术决策,并使采取纠正 措施成为可能。 SP 2.1 获得度量数据 获得规定的度量数据。 获得分析所必需的数据,并检查其完备性与完整性。 工作产品实例 1. 基本与衍生的度量数据集 2. 数据完整性测试的结果 子实践 1. 获得基本度量项数据。 必要时,为以前使用过的与新规定的基本度量项收集数据。从项目记录 或组织的其它地方收集现有的数据。 2. 产生衍生度量项的数据。 所有衍生度量项的值都是新计算出来的。 3. 尽可能靠近数据源执行数据完整性检查。 所有度量在说明规格或记录数据过程中都易发生差错。最好能在度量与 分析周期的早期,识别这些差错与遗漏数据的来源。 检查可能包括搜索遗漏数据、越界数据值、以及异常模式与度量项间的 相关性。特别重要的是进行下列事项: • 测试并纠正由于人为判断而造成的分类不一致(即,确定人们根据相 同信息作出不同分类决策的频率,又称为“编码者之间的信度”)。 • 基于经验检查用来计算附加的衍生度量项的那些度量项之间的关系。 这样做能确保没有忽视重要区别,以及衍生度量项能传达出它们的预 期含义(又称为“准则效度”)。 152 度量与分析(MA) CMMI 开发模型,版本 1.3 SP 2.2 SP 2.3 分析度量数据 分析并解释度量数据。 根据计划分析度量数据,必要时进行附加的分析,与相关干系人一起评审 结果,并标注未来分析所必需的修订。 工作产品实例 1. 分析结果与报告的初稿 子实践 1. 进行初始分析、解释结果、并得出初步结论。 数据分析的结果很少是不言自明的。应明确说明用于解释结果与得出结 论的准则。 2. 必要时,进行额外的度量与分析,并准备用于展示的结果。 计划的分析结果可能建议(或需要)进行附加的未预料到的分析。此外, 这些分析可能识别出需要细化现有度量项、计算附加的衍生度量项,以 恰当地完成计划的分析,或者甚至需要为附加的基本度量项采集数据。 类似地,在准备介绍的初始结果时,也可能识别出需要附加的、未预料 到的分析。 3. 与相关干系人一起评审初始结果。 可能比较恰当的做法是,在广泛分发并沟通初始结果前,先对结果的初 始解释及其展示方式加以评审。 在初始结果发布之前进行评审可以预防不必要的误解,并能带来数据的 分析与展示的改进。 一起评审的相关干系人包括预期的最终用户、发起人、数据分析员与数 据提供者。 4. 为未来的分析细化准则。 从进行数据分析与准备结果中,常可得出能改进未来工作的经验教训。 同样,改进度量规格说明与数据收集规程的途径,以及如何细化已识别 的信息需要与目标的想法,都会逐渐变得清晰。 存储数据与结果 管理并存储度量数据、度量规格说明与分析结果。 存储度量相关信息使其作为历史数据与结果能够被及时地、经济有效地使 用。为数据、度量准则与分析结果的解释提供充分的背景情况,也需要这 些信息。 存储的信息通常有: • 度量计划 • 度量项的规格说明 • 已收集的数据集 • 分析报告与介绍资料 • 数据保存周期 存储的信息包含或指向其它为理解并解释度量项以及评估其合理性与适 用性所需的信息(例如,在项目间比较时,不同项目所用的度量规格说明)。 度量与分析(MA) 153 CMMI 开发模型,版本 1.3 通常,衍生度量项的数据集可以重新计算,不需要存储。然而,保存基于 衍生度量项的摘要(例如,图表,结果表格,报告文本)可能是适当的。 如果可以有效地重构中间的分析结果,就不必单独存储它们。 项目可以选择在项目特定的仓库中存储项目特定数据与结果。当数据在项 目间共享时,这些数据可以存放在组织的度量库中。 参阅“配置管理”过程域以进一步了解如何建立配置管理系统。 参阅“组织级过程定义”过程域中的“建立组织的度量库”特定实践以进 一步了解如何建立组织的度量库。 工作产品实例 1. 已存储的数据 子实践 1. 评审数据以确保其完备性、完整性、准确性与当前性。 2. 根据数据存储规程存储数据。 3. 使存储内容仅供适当的组与人员可用。 4. 防止存储信息被不当使用。 防止数据与相关信息不当使用的方法的实例包括,控制数据的访问,并 教育人们适当地使用数据。 SP 2.4 不当使用数据的实例有: • 秘密提供的信息遭到泄漏 • 不完备、偏离背景情况或另外的误导信息造成的错误解释 • 将度量项用于不当地评价人员绩效或者对项目进行评级 • 对个人诚信的指责 沟通结果 与所有相关干系人沟通度量与分析活动的结果。 采取及时、可用的方式,向相关干系人沟通度量与分析过程的结果,以支 持决策制定并帮助采取纠正措施。 相关干系人包括最终用户、发起人、数据分析人员与数据提供人员。 工作产品实例 1. 交付的报告与相关分析结果 2. 帮助解释分析结果的相关背景情况信息或指南 子实践 1. 让相关干系人及时获悉度量结果。 在可能的程度内,使度量结果的用户亲身参与设置目标并确定度量与分 析的行动计划,并作为其常规业务方式的一部分。定期让用户获悉进展 与中间结果。 参阅“项目监督与控制”过程域以进一步了解如何进行进展评审。 2. 帮助相关干系人理解结果。 154 度量与分析(MA) CMMI 开发模型,版本 1.3 以清楚简明、适合于相关干系人的方式沟通结果。这些结果可被理解、 易于解读,并清楚地与所识别的信息需要与目标相联系。 对不是度量专家的实践者而言,分析的数据通常达不到不言自明的程度。 度量结果的沟通需要清楚以下几点: • 如何以及为何指定基本与衍生度量项 • 如何获得数据 • 如何基于使用的数据分析方法来解释结果 • 结果如何应对信息需要 帮助他人理解结果而采取的措施实例有: • 与相关干系人一起讨论结果 • 在文档中提供背景与解释说明 • 向用户简要说明结果 • 提供关于适当使用并理解度量结果的培训 度量与分析(MA) 155 CMMI 开发模型,版本 1.3 156 度量与分析(MA) CMMI 开发模型,版本 1.3 组织级过程定义(OPD) 成熟度 3 级过程管理类过程域 目的 简介 组织级过程定义(Organizational Process Definition,OPD)的目的在于 建立并维护一套可用的组织级过程资产、工作环境标准以及团队规则与指 南。 组织级过程资产使得整个组织具有一致的过程执行,并且为组织提供一个 累积的、长期收益的基础。(见术语表中“组织级过程资产”的定义。) 组织的过程资产库通过让整个组织内共享最佳实践与经验教训来支持组 织级学习与过程改进。(见术语表中“组织级过程资产”的定义。) 组织的标准过程集也描述与供方之间标准的交互。供方交互由下面典型的 事项所描述:期望供方提供的交付物、适用于那些交付物的验收准则、标 准(例如,架构与技术标准),以及标准里程碑与进展评审。 组织的“标准过程集”经过项目裁剪,以创建项目定义的过程。其它组织 级过程资产用来支持裁剪并实施已定义过程。工作环境标准用来指导项目 工作环境的创建。团队规则与指南用来帮助团队的结构、组建与运作。 “标准过程”由其它过程(即,子过程)或过程元素所组成。“过程元素” 是过程定义的基础(即,原子级)单元,过程定义描述了一致执行工作的 活动与任务。过程架构为连接标准过程的过程元素提供规则。组织的标准 过程集可以包含多个过程架构。 (见术语表中“标准过程”、“过程架构”、“子过程”以及“过程元素” 的定义。) 组织级过程资产可能以多种方式组织,这取决于“组织级过程定义”过程域的 实施。包括的实例有: • 生命周期模型的描述可以是组织级标准过程集的一部分,也可以单独进行 文档化。 • 组织的标准过程集可以存储在组织的过程资产库中,也可以单独存储。 • 一个单一的存储库可以包含度量与过程相关的文档,也可以将二者分开存 储。 相关过程域 参阅“组织级过程关注”过程域以进一步了解如何部署组织级过程资产。 组织级过程定义(OPD) 157 CMMI 开发模型,版本 1.3 SG 1 建立组织级过程资产 SP 1.1 建立标准过程 SP 1.2 建立生命周期模型描述 SP 1.3 建立裁剪准则与指南 SP 1.4 建立组织的度量库 SP 1.5 建立组织的过程资产库 SP 1.6 建立工作环境标准 SP 1.7 建立团队的规则与指南 特定目标与特定实践摘要 按目标排列的特定实践 SG 1 建立组织级过程资产 一套组织级过程资产得到建立与维护。 SP 1.1 建立标准过程 建立并维护组织的标准过程集。 在一个企业中,标准过程可能在多个层次定义,并且它们可能在层级上相 互关联。例如,一个企业可能有一套标准过程集,由企业的单个组织(例 如,部门、地点)裁剪以建立它们的标准过程集。该标准过程集也可以为 组织的每个业务领域、产品线,或者标准服务进行裁剪。尽管某些组织可 能仅有一个级别的标准过程,但是“组织的标准过程集”可以指建立在组 织级别的标准过程以及建立在较低层次的标准过程。(见术语表中“标准 过程”与“组织的标准过程集”的定义。) 可能需要多个标准过程以应对不同应用领域、生命周期模型、方法论及工 具的需要。组织的标准过程集包含过程元素(例如:工作产品规模估算元 素),而这些元素可能按照描述过程元素间关系的一个或多个过程架构得 到相互连接。 组织的标准过程集通常包括技术、管理、行政、支持以及组织级过程。 组织的标准过程集作为整体应当涵盖组织与项目所需的所有过程,包括成 熟度 2 级过程域所涉及的那些过程。 工作产品实例 1. 组织的标准过程集 子实践 1. 将每个标准过程按组成过程元素分解,详细到了解并描述该过程所需 要的程度。 每个过程元素包含紧密相关的一组活动。过程元素的描述可以是供填写 的模板、待完成的片段、待细化的抽象、或供裁剪或未经修改就可使用 的完整描述。这些元素描述得非常详细,从而过程完整地定义之后,能 够由经过适当培训且具备技能的人员一致地执行。 158 组织级过程定义(OPD) CMMI 开发模型,版本 1.3 过程元素的实例有: • 生成工作产品规模估算的模板 • 工作产品设计方法论的描述 • 可裁剪的同级评审方法论 • 执行管理评审的模板 • 嵌入在工作流工具中的模板或任务流 • 对供方资格进行预审以作为优先供方的方法描述 2. 明确说明每个过程元素的关键属性。 关键属性的实例有: • 过程角色 • 适用的标准 • 适用的规程、方法、工具以及资源 • 过程性能目标 • 入口准则 • 输入 • 验证点(例如,同级评审) • 输出 • 接口 • 出口准则 • 产品与过程度量项 3. 明确说明过程元素间的关系。 关系的实例有: • 过程元素顺序 • 过程元素间的接口 • 与外部过程的接口 • 过程元素间的相互依赖 描述过程元素之间关系的规则被称作“过程架构”。该过程架构包含必 要的需求与指导。这些关系的详细规格说明包含在从组织标准过程集裁 剪而得到的已定义过程的描述中。 4. 确保组织的标准过程集遵循适用的方针、标准与模型。 对适用的过程标准与模型的遵守程度通常依据开发一个组织标准过程集 与相关过程标准和模型的映射表来得到证明。此映射表对未来的评估是 有用的输入。 5. 确保组织标准过程集满足组织的过程需要与目标。 参阅“组织级过程关注”过程域以进一步了解如何建立组织级过程需要。 6. 确保在组织的标准过程集包含的过程之间有适当的集成。 组织级过程定义(OPD) 159 CMMI 开发模型,版本 1.3 7. 将组织的标准过程集文档化。 8. 对组织的标准过程集进行同级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 9. 必要时,修订组织的标准过程集。 需要修订组织标准过程集时机的实例有: • 当过程的改进得到识别时 • 当原因分析与解决数据预示某过程需要改变时 • 当过程改进提议得到选择以在整个组织部署时 • 当组织的过程需要与目标得到更新时 SP 1.2 建立生命周期模型描述 建立并维护得到批准在组织中使用的生命周期模型的描述。 由于唯一的生命周期模型可能不适用于所有情况,因此可能需要针对不同 的客户或在不同的情况开发生命周期模型。生命周期模型常常用来定义项 目的阶段。同时组织对每一交付的产品与服务类型可能定义不同的生命周 期模型。 工作产品实例 1. 生命周期模型描述 子实践 1. 基于项目与组织的需要选择生命周期模型。 生命周期模型的实例有: • 瀑布式或连续式 • 螺旋式 • 进化式 • 增量式 • 迭代式 2. 将生命周期模型描述文档化。 生命周期模型可以作为组织的标准过程描述的一部分进行文档化,或者 它们可以分别文档化。 3. 对生命周期模型进行同级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 4. 必要时,修订生命周期模型的描述。 160 组织级过程定义(OPD) CMMI 开发模型,版本 1.3 SP 1.3 建立裁剪准则与指南 建立并维护组织标准过程集的裁剪准则与指南。 裁剪准则与指南描述如下: • 如何使用组织的标准过程集与组织级过程资产创建已定义的过程 • 已定义过程必须满足的需求(例如:组织级过程资产的某个子集对于 任何已定义过程都是必要的) • 可能运用的选项以及在选项之间选择的准则 • 执行过程裁剪并将其文档化时必须遵循的规程 裁剪理由的实例有: • 使过程适应于新的产品线或工作环境 • 将过程描述细化以便产生可被执行的已定义过程 • 为一个应用或一类相似的应用定制过程 在裁剪与定义过程的灵活性方面,要适当与确保整个组织过程的一致性之 间进行平衡。需要一定的灵活性,从而应对环境中存在的可变因素,例如 领域;客户的性质;成本、进度以及质量权衡分析;工作的技术难度;以 及执行过程的人员经验。需要整个组织的一致性,以便适当满足组织级标 准、目标以及策略,并且能够分享过程数据与经验教训。 裁剪是一项关键的活动,它允许由于项目或部分组织的特定需要而对过程 进行受控的变更。直接关系到关键业务目标的过程与过程元素通常应该被 定义为必选项,但是非关键或者仅间接影响业务目标的过程与过程元素可 以允许更多的裁剪。 裁剪的多少可能也取决于项目的生命周期模型、供方的使用以及其它因素。 裁剪准则与指南可以允许按照标准过程执行,无需裁剪。 工作产品实例 1. 组织的标准过程集的裁剪指南 子实践 1. 为裁剪组织的标准过程集明确说明选择准则与规程。 准则与规程的实例有: • 从组织已批准的生命周期模型中进行选择的准则 • 从组织的标准过程集中对过程元素进行选择的准则 • 为适应过程特征与需要而对所选生命周期模型与过程元素进行裁剪 的规程 • 为应对信息需要而对组织公共度量项进行调整的规程 组织级过程定义(OPD) 161 CMMI 开发模型,版本 1.3 裁剪的实例有: • 修订生命周期模型 • 组合不同生命周期模型的元素 • 修订过程元素 • 替换过程元素 • 将过程元素重新排序 SP 1.4 2. 明确说明用于文档化已定义过程的标准。 3. 明确说明用于提交对组织标准过程集的豁免并获得批准的规程。 4. 将组织标准过程集裁剪的指南文档化。 5. 对裁剪指南执行同级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 6. 必要时修订裁剪指南。 建立组织的度量库 建立并维护组织的度量库。 参阅“集成项目管理”过程域中的“使用组织级过程资产计划项目活动” 特定实践以进一步了解如何在计划项目活动中使用组织的度量库。 该存储库包含与组织的标准过程集相关的产品度量项与过程度量项。它也 包含或引用必要信息,以理解并解释度量项,并评估其合理性与适用性。 例如,度量项的定义用于比较不同过程的类似度量项。 工作产品实例 1. 组织标准过程集的产品与过程公共度量项集合的定义 2. 组织的度量库的设计 3. 组织的度量库(即,库结构、支持环境) 4. 组织的度量数据 子实践 1. 确定组织的需要,以存储、检索并分析度量。 2. 为组织标准过程集定义一套过程与产品公共度量项集合。 在公共集合中选择度量项,选择时考虑度量项能够多大程度上为达成业 务目标的关键过程提供可视性,并关注在整个组织与项目中对成本、进 度以及绩效有显著影响的过程元素的能力。公共度量项集合可能会因标 准过程不同而不同。 已定义的度量项包括与协议管理有关的一些度量项,其中的一些可能需 要从供方那里收集。 度量项的可操作定义详细说明收集有效数据的规程以及过程中收集数据 的点。 162 组织级过程定义(OPD) CMMI 开发模型,版本 1.3 通常所使用的度量项类别实例有: • 工作产品规模的估算(例如,页) • 工作量与成本的估算(例如,人时) • 规模、工作量与成本的实际度量项 • 测试覆盖度 • 可靠性度量项(例如,平均故障时间) • 质量度量项(例如,所发现的缺陷数、缺陷的严重性) • 同级评审覆盖度 3. 设计并实现度量库。 度量库的功能包括: • 支持项目间度量数据的有效比较与解释 • 提供充分的场景说明以便让新项目在库中迅速识别并访问类似项 目数据 • 通过使用项目自己的与其它项目的历史数据,促进项目改善其估算 的准确度 • 帮助理解过程性能 • 必要时,支持过程或子过程可能的统计管理 4. 明确说明存储、更新及检索度量项的规程。 参阅“度量与分析”过程域以进一步了解如何明确说明数据收集与存储 的规程。 5. 对公共度量项集合的定义以及存储、更新并检索度量项的规程执行同 级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 6. 将规定的度量项加入度量库中。 参阅“度量与分析”过程域以进一步了解如何明确说明度量项。 7. 使度量库的内容能够让组织与项目适当地使用。 8. 当组织的需要改变时,修订度量库、公共度量项集合以及规程。 可能需要修订公共度量项集合时机的实例有: • 增加新过程 • 过程得到修改且需要新的度量项 • 要求更细的数据粒度 • 对过程要求更大的可视性 • 度量项已舍弃 组织级过程定义(OPD) 163 CMMI 开发模型,版本 1.3 SP 1.5 建立组织的过程资产库 建立并维护组织的过程资产库。 在组织过程资产库中存储的物品实例有: • 组织级方针 • 过程描述 • 规程(例如,估算规程) • 开发计划 • 采购计划 • 质量保证计划 • 培训材料 • 过程辅助工具(例如,检查单) • 经验教训报告 工作产品实例 1. 组织过程资产库的设计 2. 组织过程资产库 3. 选定的将纳入组织过程资产库中的物品 4. 组织过程资产库中物品的目录 子实践 1. 设计并实现组织过程资产库,包括库结构与支持环境。 2. 明确说明将物品纳入库的准则。 主要基于物品与组织标准过程集的关系来选择物品。 3. 明确说明存储、更新及检索度量项的规程。 4. 将所选物品加入库中并将它们分类以易于参考与检索。 5. 使物品对项目可用。 6. 定期评审每个物品的使用情况。 7. 必要时修订组织的过程资产库。 可能需要修订该库的时机的实例有: • 增加新的物品 • 一些物品已舍弃 • 物品的当前版本已改变 164 组织级过程定义(OPD) CMMI 开发模型,版本 1.3 SP 1.6 建立工作环境标准 建立并维护工作环境标准。 工作环境标准使组织及项目从公共工具、培训及维护中获益,同时从批量 采购中节省成本。工作环境标准应对所有相关干系人的需要,并考虑生产 率、成本、可用性、保密性及工作地点健康、安全性,以及人体工程学的 因素。工作环境标准可能包括裁剪与使用豁免的指南,允许调整项目的工 作环境以满足需要。 工作环境标准的实例有: • 工作环境的运行、安全及保密规程 • 标准的工作站硬件与软件 • 标准应用软件及其裁剪指南 • 标准的生产及校准设备 • 请求与批准裁剪或豁免的过程 SP 1.7 工作产品实例 1. 工作环境标准 子实践 1. 评价已经商业化且适合组织的工作环境标准。 2. 采用现有工作环境标准,并基于组织的过程需要及目标开发新的工作 环境标准以弥补差距。 建立团队的规则与指南 建立并维护团队的结构、组建与运作的组织级规则与指南。 团队的运作规则与指南定义并控制团队如何创建及相互作用以完成目标。 团队成员应该了解工作的标准,并按照标准来参与。 在建立团队规则与指南时,要确保它们遵守所有影响团队使用的本地及国 家的法规或法律。 建立团队结构包括定义团队的数量、每个团队的类型以及如何使架构中的 每个团队与其它团队相关联。组建团队涉及制定团队章程、为团队成员与 团队负责人分配任务,以及提供每个团队完成工作的资源。 工作产品实例 1. 团队结构与组建的规则与指南 2. 团队运作规则 子实践 1. 建立并维护授权机制从而能够及时做出决策。 在一个成功的团队环境中,明确定义团队授权机制的组织级指南被记录 成文档并得到部署,从而使得传递职责与职权的清晰渠道得以建立。 2. 建立并维护团队结构与组建的规则以及指南。 组织级过程定义(OPD) 165 CMMI 开发模型,版本 1.3 组织级过程资产可以有助于项目构成并实现团队。这样的资产可能包括: • 团队结构指南 • 团队组建指南 • 团队职权与职责指南 • 建立沟通、职权与上报线路的指南 • 团队负责人选择准则 3. 定义指导团队如何协同工作的期望、规则以及指南。 这些规则与指南为团队间的一致性建立组织级实践并可能包括: • 如何建立并维护团队间的接口 • 如何接受与转移任务 • 如何使用资源与输入 • 如何完成工作 • 由谁检查、评审并批准工作 • 工作怎样得到批准 • 工作如何交付并沟通 • 谁向谁报告 • 有哪些汇报的需求(例如,成本、进度及绩效状态)、度量项及方法 • 使用了哪些进展报告的度量项与方法 166 组织级过程定义(OPD) CMMI 开发模型,版本 1.3 组织级过程关注(OPF) 成熟度 3 级过程管理类过程域 目的 简介 相关过程域 组织级过程关注(Organizational Process Focus,OPF)的目的在于,基 于对组织过程与过程资产当前的强项与弱项的透彻理解,计划、实施并部 署组织级过程改进。 组织的过程包括组织及其项目使用的所有过程。对组织的过程与过程资产 的候选改进从各种来源获得,包括过程的度量、在过程实施中得到的经验 教训、过程评估的结果、产品与服务评价活动的结果、客户满意度评价的 结果、参考其它组织过程进行基准比较的结果以及来自组织中其它改进倡 议的建议。 过程改进以组织的需要为背景进行,并用于应对组织的目标。组织鼓励执 行过程的人在过程改进活动中的参与。促进并管理组织过程改进活动的职 责通常被分派给过程组,职责中包括对其他人的参与进行协调。组织提供 发起并资助过程组以及确保有效及时地部署改进所必需的长期承诺与资 源。 为了确保整个组织的过程改进工作得到充分管理并实施,仔细进行计划是 必需的。而其计划活动的结果,在过程改进计划中进行文档化。 “组织过程改进计划”涉及评估计划、过程行动计划、试点计划以及部署 计划。评估计划描述评估的时间表与进度、评估的范围、执行评估所需的 资源、执行评估参照的参考模型以及评估的后勤。 过程行动计划通常从评估产生并且把以评估发现的弱项为目标的改进将 要如何实施文档化。有时,过程行动计划中描述的改进在整个组织部署之 前,应该在一个小组上进行测试。在这些情况下,产生试点计划。 当将要部署改进的时候,制定部署计划。这个计划描述改进将要何时及如 何在整个组织部署。 组织级过程资产用于描述、实施并改进组织的过程。(见术语表中“组织 级过程资产”的定义。) 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 组织级过程关注(OPF) 167 CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 确定过程改进机会 SP 1.1 建立组织级过程需要 SP 1.2 评估组织的过程 SP 1.3 识别组织的过程改进 SG 2 计划并实施过程行动 SP 2.1 建立过程行动计划 SP 2.2 实施过程行动计划 SG 3 部署组织级过程资产并纳入经验 SP 3.1 部署组织级过程资产 SP 3.2 部署标准过程 SP 3.3 监督实施 SP 3.4 将经验纳入到组织级过程资产中 按目标排列的特定实践 SG 1 确定过程改进机会 组织过程的强项、弱项与改进机会定期地以及在必要时得到识别。 可以比对过程标准或模型,如 CMMI 模型或 ISO 标准,确定强项、弱项与 改进机会。过程改进应该得到选择以应对组织的需要。 过程改进机会可以作为变更业务目标、法律与监管要求的结果,以及基准 比较研究的结果出现。 SP 1.1 建立组织级过程需要 建立并维护组织过程需要与目标的描述。 组织的过程在应被理解的业务环境中运行。组织的业务目标、需要与约束 决定组织的过程需要与目标。通常,与客户满意度、财务、技术、质量、 人力资源及市场等相关的问题是过程的重要考虑因素。 组织的过程需要与目标覆盖的方面有: • 过程的特征 • 过程性能目标,例如上市时间与交付的质量 • 过程有效性 工作产品实例 1. 组织的过程需要与目标 子实践 1. 识别适用于组织过程的方针、标准以及业务目标。 168 组织级过程关注(OPF) CMMI 开发模型,版本 1.3 标准的实例有: • ISO/IEC 12207:2008 系统与软件工程–软件生命周期过程[ISO 2008a] • ISO/IEC 15288:2008 系统与软件工程–系统生命周期过程[ISO 2008b] • ISO/IEC 27001:2005 信息技术–安全技术–信息安全管理系统–需求 [ISO/IEC 2005] • ISO/IEC 14764:2006 软 件 工 程 – 软 件 生 命 周 期 过 程– 维 护 [ ISO 2006b] • ISO/IEC 20000 信息技术–服务管理[ISO 2005b] • CMMI 的保证关注[DHS 2009] • NDIA 系统保证工程指导手册[NDIA 2008] • 弹性管理模型[SEI 2010c] 2. 考察相关过程标准与模型以寻找最佳实践。 3. 确定组织的过程性能目标。 过程性能目标可以用量化或定性的术语表达。 参阅“度量与分析”过程域以进一步了解如何建立度量目标。 参阅“组织级过程性能”过程域以进一步了解如何建立质量与过程性能 目标。 过程性能目标的实例有: • 客户满意评定达成某个值 • 确保产品可靠性至少是某个百分比 • 按某个百分比降低缺陷注入率 • 给定的活动达成某周期时间 • 按给定百分比改进生产率 • 简化需求批准工作流 • 改进交付给客户的产品质量 4. 定义组织过程的关键特征。 基于如下内容确定组织过程的关键特征: • 当前正在组织中使用的过程 • 组织强制的标准 • 组织的客户通常强制的标准 组织级过程关注(OPF) 169 CMMI 开发模型,版本 1.3 过程特征的实例有: • 详细水平 • 过程的记法 • 粒度 SP 1.2 5. 将组织的过程需要与目标文档化。 6. 必要时,修订组织的过程需要与目标。 评估组织的过程 定期以及在必要时,对组织的过程进行评估,以维护对其强项与弱项 的理解。 可以出于如下理由进行过程评估: • 为识别待改进的过程 • 为确认进展并使过程改进的收益可见 • 为满足客户——供方关系的需要 • 为激励并促进认同 如果没有后继基于评估的行动计划,过程评估中得到的认同可能被严重削 弱。 工作产品实例 1. 组织的过程评估计划 2. 针对组织过程的强项与弱项的评估发现 3. 组织的过程改进建议 子实践 1. 获得高层管理人员对过程评估的发起并资助。 高层管理人员的发起与资助包括让组织的管理人员与员工参与过程评估 并且提供资源与资金以对评估发现进行分析与沟通的承诺。 2. 定义过程评估的范围。 过程评估可以对整个组织进行或者对组织中较小的部分进行,例如单个 项目或者业务领域。 过程评估的范围涉及如下内容: • 将由评估覆盖的组织(例如:场所、业务领域)的定义 • 对将要在评估中代表组织的项目及支持职能的识别 • 待评估的过程 3. 确定将用于过程评估的方法与准则。 过程评估能以许多形式发生。它们应该应对可能随时间变化的组织需要 与目标。例如,评估可以基于过程模型,如 CMMI 模型,或者基于国家 或国际标准,如 ISO 9001[ISO 2008c]。评估也可以基于与其它组织 的基准比较,在此对比中可能有助改进的组织级绩效的实践得到识别。 170 组织级过程关注(OPF) CMMI 开发模型,版本 1.3 SP 1.3 评估方法的特征可能不同,包括时间与工作量、评估团队的构成、以及 调查的方法与深度等。 4. 为过程评估制订计划、进度并做准备。 5. 进行过程评估。 6. 将评估的活动与发现文档化并交付。 识别组织的过程改进 识别组织的过程与过程资产的改进。 工作产品实例 1. 对候选过程改进的分析 2. 对组织过程改进的识别 子实践 1. 确定候选过程改进。 候选过程改进通常通过执行如下活动确定: • 对过程进行度量并对度量结果进行分析 • 对过程的有效性与适合性进行评审 • 评估客户满意度 • 评审从裁剪组织的标准过程集得到的经验教训 • 评审从过程的实施中得到的经验教训 • 评审由组织的管理人员、员工与其他相关干系人提交的过程改进提议 • 从组织中的高层管理人员与其他领导处征求对过程改进的输入 • 对过程评估与其它过程相关评审的结果进行考察 • 对其它组织级改进倡议的结果进行评审 2. 为候选过程改进划分优先级。 划分优先级的准则如下: • 考虑实施过程改进的估算成本与工作量。 • 对照组织的改进目标与优先级评价期望的改进。 • 确定对过程改进的潜在障碍并制订克服这些障碍的策略。 帮助确定可能的待实施改进并为之划分优先级的技术实例有: • 将实施过程改进的估算成本及工作量与其关联的收益进行比较的成 本收益分析 • 将组织当前的情况与最优情况进行比较的差距分析 • 对潜在改进的力场分析,其目的在于识别潜在障碍以及克服那些障碍 的策略 • 为不同改进的潜在效果提供信息,进而可以对其进行比较的因果分析 3. 识别待实施的过程改进并将其文档化。 4. 修订已计划的过程改进列表以保持它的当前性。 组织级过程关注(OPF) 171 CMMI 开发模型,版本 1.3 SG 2 计划并实施过程行动 过程行动得到计划与实施,以应对组织的过程与过程资产的改进。 改进的成功实施需要过程负责人、执行过程的人以及支持组织的人在过程 行动的计划与实施中的参与。 SP 2.1 建立过程行动计划 建立并维护过程行动计划,以应对组织的过程与过程资产的改进。 建立并维护过程行动计划通常涉及如下角色: • 设定策略并监管过程改进活动的管理指导委员会 • 促进并管理过程改进活动的过程组 • 定义并实施过程行动的过程行动团队 • 管理部署的过程负责人 • 执行过程的实践者 干系人的参与有助于获得对过程改进的认同并提高有效部署的可能性。 过程行动计划是详细的实施计划。这些计划不同于组织的过程改进计划, 不同之处在于过程行动计划针对为处理弱项而定义的改进,这些改进通常 由评估发现。 工作产品实例 1. 组织的已批准的过程行动计划 子实践 1. 识别策略、方法及行动以应对所识别的过程改进。 新的、未经证明的、以及重大的变更在纳入常规使用前进行试点。 2. 建立过程行动团队以实施行动。 执行过程改进行动的团队及人员称作“过程行动团队”。过程行动团队 通常包括过程负责人以及执行过程的人。 3. 将过程行动计划文档化。 过程行动计划通常覆盖: • 过程改进基础设施 • 过程改进目标 • 待处理的过程改进 • 对过程行动进行计划并跟踪的规程 • 对过程行动进行试点并实施的策略 • 实施过程行动的职责与职权 • 实施过程行动的资源、进度以及分派 • 确定过程行动有效性的方法 • 过程行动计划相关的风险 4. 与相关干系人对过程行动计划进行评审并协商。 5. 必要时,修订过程行动计划。 172 组织级过程关注(OPF) SG 3 CMMI 开发模型,版本 1.3 SP 2.2 实施过程行动计划 实施过程行动计划。 工作产品实例 1. 过程行动团队间的承诺 2. 实施过程行动计划的状态与结果 3. 试点计划 子实践 1. 使过程行动计划对相关干系人来说随时可用。 2. 协商过程行动团队间的承诺并将其文档化,在必要时修订他们的过程 行动计划。 3. 对照过程行动计划跟踪进展与承诺。 4. 与过程行动团队以及相关干系人进行联合评审,以监督过程行动的进 展与结果。 5. 为测试所选过程改进需要的试点制订计划。 6. 对过程行动团队的活动与工作产品进行评审。 7. 识别实施过程行动计划时遇到的问题,将其文档化并跟踪直到关闭。 8. 确保实施过程行动计划的结果满足组织的过程改进目标。 部署组织级过程资产并纳入经验 组织级过程资产在组织内得到全面部署,并且与过程相关的经验得以纳入组织级过 程资产。 本特定目标下的特定实践描述持续性的活动。受益于组织级过程资产及其 变更的新机会可能出现于每个项目的整个生命期。标准过程以及其它组织 级过程资产在组织中的部署,特别对正在启动的新项目,应该持续得到支 持。 SP 3.1 部署组织级过程资产 在组织内全面部署组织级过程资产。 对组织级过程资产或者其变更的部署应该以有序的方式进行。有些组织级 过程资产或者其变更可能并不适合用于组织的有些部分(例如因为干系人 需求或者当前正在实施的生命周期阶段)。因此,必要时让正在或者将要 执行过程的人,与其它的组织职能(例如培训、质量保证)一样参与部署 是重要的。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 工作产品实例 1. 将组织级过程资产及其变更在整个组织部署的计划 2. 以部署组织级过程资产及其变更为目标的培训资料 3. 组织级过程资产变更的文档 4. 以部署组织级过程资产及其变更为目标的支持资料 子实践 1. 在整个组织部署组织级过程资产。 组织级过程关注(OPF) 173 CMMI 开发模型,版本 1.3 作为过程资产部署的一部分得到执行的典型活动有: • 识别哪些组织级过程资产应该被执行过程的人采用 • 确定如何使组织级过程资产可用(例如通过网站) • 确定对组织级过程资产的变更如何得到沟通 • 识别为支持组织级过程资产使用而需要的资源(例如方法、工具) • 为部署制订计划 • 协助使用组织级过程资产的人 • 确保培训对使用组织级过程资产的人可用 参阅“组织级培训”过程域以进一步了解如何建立组织级培训能力。 2. 将过程资产的变更文档化。 将组织级过程资产的变更文档化服务于两个目的: • 为沟通变更提供手段 • 理解组织级过程资产变更与过程性能及结果变更的关系 3. 在整个组织部署对组织级过程资产所作的变更。 作为部署变更的一部分得到执行的典型活动有: • 确定哪些变更对执行过程的人是适当的 • 为部署制订计划 • 为变更的成功过渡所需的支持作安排 SP 3.2 4. 对组织级过程资产的使用提供指导与咨询。 部署标准过程 在项目启动时,向其部署组织的标准过程集;并且在每个项目的整个 生命期中,适当向其部署变更。 重要的是,新项目使用已证明并且有效的过程执行关键的早期活动(例如 项目计划、收到需求、获得资源)。 项目也应该定期更新其已定义的过程,以在将会从中受益时纳入对组织的 标准过程集所作的最新变更。这种定期更新有助于确保所有项目活动从其 它项目已经学到的东西中获得完整的收益。 参阅“组织级过程定义”过程域以进一步了解如何建立标准过程并建立裁 剪准则与指南。 工作产品实例 1. 组织的项目列表以及对每个项目(即现有的与计划的项目)的过程部 署状态 2. 在新项目上部署组织标准过程集的指南 3. 裁剪并实施组织的标准过程集的记录 子实践 1. 识别组织中正在启动的项目。 2. 识别可能会从实施组织的当前标准过程集受益的活动项目。 174 组织级过程关注(OPF) CMMI 开发模型,版本 1.3 SP 3.3 SP 3.4 3. 建立计划以在所识别的项目上实施组织的当前标准过程集。 4. 协助项目裁剪组织的标准过程集以满足其需要。 参阅“集成项目管理”过程域以进一步了解如何建立项目已定义的过程。 5. 维护在所识别的项目上裁剪并实施过程的记录。 6. 确保过程裁剪产生的已定义过程被纳入过程符合性审计计划。 过程符合性审计是参照项目已定义的过程对项目活动的客观评价。 7. 随着组织的标准过程集更新,识别哪些项目应该实施变更。 监督实施 监督所有项目中组织标准过程集的实施与过程资产的使用。 通过监督实施,组织确保组织的标准过程集与其它的过程资产适当地部署 到所有的项目。监督实施也帮助组织理解正在使用的组织级过程资产以及 它们在组织的哪些地方得到使用。监督也有助于为解释并使用从项目获得 的过程与产品度量项、经验教训以及改进信息等建立更广泛的背景情况。 工作产品实例 1. 对项目上的过程实施进行监督的结果 2. 过程符合性审计的状态与结果 3. 作为过程裁剪与实施的一部分,对所选的已创建过程产物进行评审的 结果 子实践 1. 监督项目中组织级过程资产及其变更的使用。 2. 评审所选的在每个项目生命期中创建的过程产物。 对所选的在项目生命期中创建的过程产物进行的评审确保所有的项目正 在适当使用组织的标准过程集。 3. 对过程符合性审计的结果进行评审以确定组织的标准过程集已经部 署到怎样的程度。 参阅“过程与产品质量保证”过程域以进一步了解如何客观评价过程。 4. 识别与组织的标准过程集的实施相关的问题,将其文档化并跟踪直到 关闭。 将经验纳入到组织级过程资产中 将源于过程的计划与执行的、与过程相关的经验纳入组织级过程资产。 工作产品实例 1. 过程改进提议 2. 过程经验教训 3. 组织级过程资产的度量 4. 对组织级过程资产的改进建议 5. 组织的过程改进活动记录 6. 有关组织级过程资产及其改进的信息 组织级过程关注(OPF) 175 CMMI 开发模型,版本 1.3 子实践 1. 比对源自于组织业务目标的过程需要与目标,对组织标准过程集与相 关组织过程资产的有效性与适合性进行定期的评审。 2. 获得与组织级过程资产的使用有关的反馈。 3. 从组织级过程资产的定义、试点、实施及部署中获得经验教训。 4. 使经验教训能被组织中的人适当使用。 确保经验教训得到适当使用的行动可能是必要的。 对经验教训不适当使用的实例有: • 评价人的绩效 • 判断过程性能或结果 用于预防对经验教训不适当使用的方法实例有: • 控制对经验教训的访问权限 • 对人员进行适当使用经验教训有关的教育 5. 分析从组织的公共度量项集合的使用中获得的度量数据。 参阅“度量与分析”过程域以进一步了解如何分析度量数据。 参阅“组织级过程定义”过程域以进一步了解如何建立组织的度量库。 6. 评估在组织中使用的过程、方法与工具并制订改进组织级过程资产的 建议。 这种评估通常包括: • 确定哪些过程、方法及工具对组织的其它部分具有潜在的用途 • 评估组织级过程资产的质量与有效性 • 识别对组织级过程资产的候选改进 • 确定对组织的标准过程集与裁剪指南的符合性 7. 适当地充分利用组织中的人员可以获得的组织过程、方法与工具。 8. 管理过程改进提议。 过程改进提议可能对过程与技术改进都涉及。 管理过程改进提议的活动通常有: • 征求过程改进提议 • 收集过程改进提议 • 评审过程改进提议 • 选择待实施的过程改进提议 • 对过程改进提议的实施进行跟踪 过程改进提议被适当文档化为过程变更请求或者问题报告。 有些过程改进提议可以纳入组织的过程行动计划。 9. 建立并维护组织的过程改进活动记录。 176 组织级过程关注(OPF) CMMI 开发模型,版本 1.3 组织级绩效管理(OPM) 成熟度 5 级过程管理类过程域 目的 组织级绩效管理(Organizational Performance Management,OPM)的 目的在于主动地管理组织的绩效以满足其业务目标。 简介 “组织级绩效管理”过程域使组织能够通过反复分析聚合的项目数据,参 照业务目标识别绩效差距,并选择、部署改进以填补差距的方式管理组织 级绩效。 在本过程域,术语“改进”包括所有增量型与革新型的过程与技术改进, 包括那些对项目工作环境所做的改进。“改进”指所有将要改变组织的过 程、技术与绩效,以更好地满足组织的业务目标以及相关质量与过程性能 目标的想法。 本过程域可能应对的业务目标有: • 得到改进的产品质量(例如,功能、质量属性) • 得到提高的生产率 • 得到提高的过程效率与有效性 • 得到提高的在满足预算与进度方面一致性 • 得到降低的周期时间 • 更高的客户与最终用户满意度 • 更短的开发或生产时间用以改变功能、添加新特性或适应新技术 • 得到改进的包括多个供方的供应链绩效 • 得到改进的整个组织的资源使用 组织分析从项目得来的产品与过程性能数据,以决定其是否有能力满足质 量与过程性能目标。作为分析的一部分,“组织级过程性能”过程开发的 过程性能基线与过程性能模型得到使用。“原因分析与解决”过程也可以 用于识别潜在改进领域或特定改进提议。 组织识别并主动从组织内部,也从外部来源,例如学术界、竞争情报以及 已在其它地方成功实施的改进,征求增量型与革新型改进。 改进及其对质量与过程性能目标所产生效果的实现依赖于能够有效地识 别、评价、实施改进,并将其部署到组织的过程与技术。 改进以及有益效果的实现也依赖于使员工参与识别与评价可能的改进,并 维护对于包括识别革新在内的长期计划的关注。 改进提议的有效性在目标环境中得到评价与确认。基于这个评价,改进被 划分优先级并得到选择,以部署到新的与正在进行的项目。部署按照部署 计划得到管理,并且绩效数据得到使用统计与其它量化技术的分析,以确 定改进对质量与过程性能目标产生的效果。 基于质量与过程性能目标,这个改进环持续优化组织级过程。业务目标得 到定期评审以确保是最新的,并且质量与过程性能目标适当得到更新。 组织级绩效管理(OPM) 177 CMMI 开发模型,版本 1.3 相关过程域 “组织级过程关注”过程域没有假定在识别改进或者其预期结果时需要具 备量化基础。通过关注以量化理解为基础的过程改进,本过程域对“组织 级过程关注”的实践进行了扩展,此处的量化理解是对组织标准过程与技 术的集合及其期望的质量和过程性能的量化理解。 本过程域的特定实践适用于其项目得到量化管理的组织。虽然在其它情况 下使用本过程域的特定实践可以增加价值,但是结果可能无法对组织的质 量与过程性能目标产生相同程度的影响。 参阅“原因分析与解决”过程域以进一步了解如何识别所选结果的原因并 采取行动,以改进过程性能。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 参阅“组织级过程关注”过程域以进一步了解如何基于对组织过程与过程 资产当前的强项与弱项的透彻理解,计划、实施并部署组织级过程改进。 参阅“组织级过程性能”过程域以进一步了解如何建立质量与过程性能目 标并建立过程性能基线与模型。 参阅“组织级培训”过程域以进一步了解如何提供培训。 178 组织级绩效管理(OPM) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 管理业务绩效 SP 1.1 维护业务目标 SP 1.2 分析过程性能数据 SP 1.3 识别潜在改进领域 SG 2 选择改进 SP 2.1 挖掘所建议的改进 SP 2.2 分析所建议的改进 SP 2.3 确认改进 SP 2.4 选择并实施将要部署的改进 SG 3 部署改进 SP 3.1 计划部署 SP 3.2 管理部署 SP 3.3 评价改进效果 按目标排列的特定实践 SG 1 管理业务绩效 使用统计与其它量化技术,组织的业务绩效得到管理,以理解过程性能的不足并识 别过程改进领域。 管理业务绩效要求如下: • 维护组织的业务目标 • 理解组织满足业务目标的能力 • 对达成业务目标相关的过程进行持续改进 组织使用已定义的过程性能基线来确定是否正在满足当前的与规划将来 的组织级业务目标。过程性能的不足得到识别并分析,以确定潜在过程改 进领域。 参阅“组织级过程性能”过程域以进一步了解如何建立过程性能基线与模 型。 随着组织改进其过程性能或者随着业务战略发生变更,新业务目标得到识 别,并且相关质量与过程性能目标得到派生。 特定目标 2 旨在挖掘并分析改进建议,这些改进建议对达成质量与过程性 能目标方面的不足进行处理。 SP 1.1 维护业务目标 基于对业务战略与实际绩效结果的理解,维护业务目标。 以过程性能基线为特征的组织级绩效数据用于评价业务目标是否现实并 与业务战略协调一致。当业务目标已经修订并且由高层管理人员划分了优 先级之后,可能需要创建或维护质量与过程性能目标并就其再次沟通。 工作产品实例 1. 修订了的业务目标 2. 修订了的质量与过程性能目标 3. 高层管理人员对修订了的业务目标以及质量与过程性能目标的批准 4. 所有修订了的目标的沟通 5. 更新了的过程性能度量项 组织级绩效管理(OPM) 179 CMMI 开发模型,版本 1.3 SP 1.2 子实践 1. 定期评价业务目标,以确保其与业务战略协调一致。 高层管理人员负责了解市场、建立业务战略、以及建立业务目标。 因为业务战略与组织级绩效会演化,所以业务目标应该定期评审,以确 定其是否应该更新。例如,过程性能数据表明某业务目标随着时间推移 总是持续得到满足的时候,或者相关业务战略已经改变的时候,该业务 目标可能应该舍弃。 2. 将业务目标与实际过程性能结果相比较,以确保其现实性。 业务目标可能设得太高以致不能激励实际的改进。使用过程性能基线有 助于平衡愿望与现实。 如果过程性能基线不可用,那么可以在短时间内使用采样技术开发一个 用于比较的量化基础。 3. 基于文档化的准则,例如赢得新业务、留住现有客户或者完成其它关 键业务战略的能力,为业务目标划分优先级。 4. 维护质量与过程性能目标,以处理业务目标的变更。 业务目标以及质量与过程性能目标通常会随时间演化。随着现有目标达 成,其将受到监督以确保继续得到满足,同时新业务目标以及相关质量 与过程性能目标得到识别并管理。 参阅“组织级过程性能”过程域以进一步了解如何建立质量与过程性能 目标。 5. 修订过程性能度量项,以便和质量与过程性能目标协调一致。 参阅“组织级过程性能”过程域以进一步了解如何建立过程性能度量项。 分析过程性能数据 分析过程性能数据,以确定组织满足所识别业务目标的能力。 “组织级过程性能”过程定义过程性能度量项,应用这些度量项产生数据, 分析这些数据以创建有助于理解组织当前能力的过程性能基线。将过程性 能基线和质量与过程性能目标相比较有助于组织确定其满足业务目标的 能力。这些数据通常从项目级过程性能数据收集,以使组织级分析成为可 能。 工作产品实例 1. 当前能力与业务目标之间的对比分析 2. 过程性能的不足 3. 与满足业务目标相关的风险 子实践 1. 定期将质量与过程性能目标和当前过程性能基线相比较,以评价组织 满足其业务目标的能力。 例如,如果周期时间是关键的业务需要,那么组织可能收集许多不同的 周期时间度量项。整体的周期时间绩效数据应该与业务目标相比较,以 理解期望绩效是否将满足业务目标。 2. 识别不足——实际过程性能不满足业务目标之处。 3. 识别并分析与不满足业务目标相关的风险。 4. 将过程性能与风险分析的结果报告给组织级领导。 180 组织级绩效管理(OPM) SG 2 CMMI 开发模型,版本 1.3 SP 1.3 识别潜在改进领域 识别可能有助于满足业务目标的潜在改进领域。 潜在改进领域通过主动式的分析得以识别,从而确定哪些领域可以应对过 程性能的不足。“原因分析与解决”过程可用于诊断并解决根本原因。 这个活动的输出用于评价潜在改进并为其划分优先级,并且如特定目标 2 所述,可以产生增量型或者革新型改进。 工作产品实例 1. 潜在改进领域 子实践 1. 基于对过程性能不足的分析,识别潜在改进领域。 性能不足包括无法满足生产率、周期时间或者客户满意度目标。待考虑 的改进领域实例包括产品技术、过程技术、员工配置与发展、团队结构、 供方选择与管理以及其它组织级基础设施。 2. 将潜在改进领域的依据文档化,包括对适用的业务目标与过程性能数 据的引用。 3. 将与处理潜在改进领域相关的预期成本与收益文档化。 4. 为了进一步的评价、划分优先级与使用,就潜在改进领域的集合进行 沟通。 选择改进 改进得到主动的识别以及使用统计与其它量化技术的评价,并且基于其对满足质量 与过程性能目标的贡献,得到选择以进行部署。 从那些在目标部署环境中已经评价过其有效性的改进建议中,选择将要在 整个组织部署的改进。这些改进建议是为了处理特定目标 1 识别的改进领 域而在整个组织内挖掘并提交的。 改进建议的评价基于: • 对组织当前的质量与过程性能的量化理解 • 对组织的质量与过程性能目标的满意度 • 估算的开发并部署改进的成本与影响、资源、以及可用于部署的资金 • 部署改进对质量与过程性能产生的估算收益 SP 2.1 挖掘所建议的改进 挖掘并分类所建议的改进。 这个实践关注对改进建议的挖掘,也包括把改进建议归类为增量型或革新 型。 增量型改进通常来自那些做工作的人(即过程或技术的使用者)。增量型 改进在实施与部署上可能简单且成本低廉。增量型改进建议虽然得到分析, 但是如果被选中,可能不需要严格的确认或试点。革新型改进,例如新的 或重新设计的过程,与增量型改进相比是更大的转型。 革新型改进常常出自对解决方案所做的系统化搜索,这些解决方案是针对 特定绩效问题或绩效改进机会的。识别革新型改进的人,他们或者经过训 练并且具有特定技术的纯熟经验,或者其工作就是跟踪或直接为提高绩效 做出贡献。 组织级绩效管理(OPM) 181 CMMI 开发模型,版本 1.3 通过积极监督其它组织使用的或记录在研究文献中的革新,革新可以在外 部发现。革新也可以通过内部观察(例如,通过检查项目经验教训)发现。 革新的启发来自于达成质量与过程性能目标的需要、改进性能基线的需要, 或者来自外部业务环境。 增量型改进实例有: • 在同级评审检查单中添加条目。 • 将供应商的技术评审与管理评审合并成一个单独的评审。 • 引入事件权变措施。 • 取代新组件。 • 对工具做些较小的更新。 革新型改进实例通常包括对如下条目添加附加部分或进行重大的更新: • 计算机及相关硬件产品 • 转型支持工具 • 新的或重新设计的工作流 • 过程或生命周期模型 • 接口标准 • 可复用组件 • 管理技术与方法论 • 质量改进技术与方法论 • 开发技术与方法论 一些建议的改进可能以提议的形式收到(例如出自原因分析与解决活动的 组织级改进提议)。在输入“组织级绩效管理”过程前,这些建议的改进 应该已经得到分析并文档化。在所建议的改进作为提议收到时,评审提议 的完整性,并且作为选择过程的一部分,评价该提议是否会被选择实施。 改进的搜索可以包括观察组织外部、使用“原因分析与解决”过程从项目 得到革新、使用业务竞争情报、或者分析目前的组织级绩效。 工作产品实例 1. 所建议的增量型改进 2. 所建议的革新型改进 子实践 1. 挖掘所建议的改进。 这些建议将针对过程与技术的潜在改进文档化。组织的管理人员与员工 和客户、最终用户以及供方一样可以提交建议。为得到所建议的改进, 组织还可以搜索学术与技术社区。在提交给组织前,有些建议的改进可 能已经在项目级得到实施。 182 组织级绩效管理(OPM) CMMI 开发模型,版本 1.3 改进来源的实例有: • 来自过程评估的发现与建议 • 组织的质量与过程性能目标 • 对客户与最终用户的问题以及满意度有关的数据分析 • 过程与产品基准比较工作的结果 • 已度量的过程活动有效性 • 已度量的项目工作环境有效性 • 其它地方成功采用的改进实例 • 对以前改进的反馈 • 管理人员与员工自发的想法 • 从已实施且已证明有效性的行动产生的,来自“原因分析与解决”过 程的改进提议 • 对技术性能度量项的分析 • 对缺陷原因数据的分析 • 项目与组织级绩效相对于质量与生产率目标的比较分析 SP 2.2 参阅“组织级过程关注”过程域以进一步了解如何部署组织级过程资产 并纳入经验。 2. 将所建议的改进识别为增量型或是革新型。 3. 对可能改进组织过程与技术的革新型改进进行调查。 调查革新型改进通常包括: • 保持对领先的相关技术工作与技术趋势的认知 • 搜索已被商业化的革新型改进 • 收集来自项目与组织的革新型改进提议 • 评审外部使用的过程与技术,并将其与组织中使用的过程与技术相比 较 • 识别已经成功使用革新型改进的领域,并评审这些改进使用经验的数 据与文档 • 识别将新技术集成到产品与项目工作环境的改进 分析所建议的改进 分析所建议的改进对达成组织质量与过程性能目标可能产生的影响。 所建议的改进是那些得到分析并可能被选择进行确认、实施并在整个组织 部署的增量型与革新型改进。 工作产品实例 1. 所建议的改进提议 2. 所选择的待确认的改进 子实践 1. 分析所建议改进的成本与收益。 组织级绩效管理(OPM) 183 CMMI 开发模型,版本 1.3 过程性能模型提供对过程变更所产生的过程能力与性能效果的深入了解。 参阅“组织级过程性能”过程域以进一步了解如何建立过程性能模型。 成本收益比例较大或者对组织的过程不会带来改进的改进建议可能会被 拒绝。 评价成本与收益的准则有: • 对满足组织的质量与过程性能目标的贡献 • 对缓解已识别的项目与组织级风险产生的效果 • 对项目需求、市场情况以及业务环境变化的快速反应能力 • 对有关过程及相关资产所产生的效果 • 数据的定义与收集成本,这些数据为过程与技术改进的度量与分析提 供支持 • 预期的改进生命期 2. 对部署每个建议的改进面临的潜在障碍与风险进行识别。 部署改进所面临障碍的实例有: • 区域保护与狭隘视角 • 业务依据薄弱或不清晰 • 缺乏短期收益与可见成功 • 不清楚对每个人的期望 • 在同一时间变更太多 • 缺乏相关干系人的参与和支持 影响改进部署的风险因素的实例有: • 改进与现有过程、价值观以及潜在最终用户技能之间的兼容性 • 改进的复杂度 • 改进的实施困难度 • 在广泛部署之前证明改进价值的能力 • 在诸如工具与培训此类的领域进行大规模前期投资的理由 • 在当前技术被大量的成熟用户安装且成功使用的情况下,不能克服 “技术阻力” 3. 为实施、验证并部署每个建议的改进,估算必需的成本、工作量与进 度。 4. 为了确认以及可能的实施与部署,基于评价选择所建议的改进。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的 决策。 5. 将每个所选改进建议的评价结果文档化在改进提议中。 184 组织级绩效管理(OPM) CMMI 开发模型,版本 1.3 提议应包括问题的描述、实施改进的计划(包括成本与进度、风险处理、 评价目标环境中有效性的方法)、以及用于评价部署实际结果的量化成 功准则。 6. 确定实施改进所需的详细变更,并将其文档化在改进提议中。 7. 确定将于大规模部署变更之前使用的确认方法,并将其文档化在改进 提议中。 确定确认方法包括定义量化成功准则,该准则将用于评价确认结果。 因为根据定义,革新表示具有高度影响的重大变更,所以大多数革新型 改进将进行试点。其它确认方法,包括建模与模拟,可以适当得到使用。 8. 将选择过程的结果文档化。 选择过程的结果通常有: • 对每个建议的改进的处置 • 对每个建议的改进的处置依据 SP 2.3 确认改进 确认所选改进。 所选改进按照其改进提议得到确认。 确认方法的实例有: • 与干系人讨论,或许在正式评审的场合 • 原型展示 • 所建议改进的试点 • 建模与模拟 在其广泛部署之前,可以进行试点以评价那些包含未经实验的、高风险或 革新型改进的重大变更。并非所有改进都需要试点这样严格的方式。用于 选择改进以进行试点的准则得到定义并使用。诸如风险、变更的转型性质 或者受影响功能领域的数量等因素将决定变更是否需要试点。 可以制作红线标注的或者草拟的过程文档以备在试点中使用。 工作产品实例 1. 确认计划 2. 确认评价报告 3. 从确认得到的文档化的经验教训 子实践 1. 为确认制订计划。 当为确认制订计划时,在改进提议中记录的量化成功准则可能有用。 所选待试点改进的确认计划应包括目标项目、项目特征、报告结果的进 度以及度量活动。 2. 评审确认计划并就其与相关干系人达成一致。 3. 与执行确认的人协商并提供协助。 4. 按照确认计划,为所选待试点改进创建试验性实施。 组织级绩效管理(OPM) 185 CMMI 开发模型,版本 1.3 5. 在与大规模部署所呈现环境类似的环境中执行每个确认。 6. 对照确认计划对确认进行跟踪。 7. 评审确认结果并将其文档化。 使用在改进提议中定义的量化准则,确认结果得到评价。 评审试点结果并将其文档化通常包括如下活动: • 与干系人评审试点结果 • 对是否终止试点、对改进的实施进行返工、重新计划并继续试点、或 者继续部署做出决定 • 对试点相关改进提议的处置进行更新 • 适当识别新改进提议并将其文档化 • 识别试点过程中得到的经验教训以及遇到的问题,包括对改进团队的 反馈以及对改进的变更,并将其文档化 SP 2.4 选择并实施将要部署的改进 基于对成本、收益与其它因素的评价,选择并实施将要在整个组织部 署的改进。 对将要部署的所建议改进的选择基于质量与过程性能目标相关的成本收 益比、可用资源、以及对改进提议的评价与确认活动结果等。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 工作产品实例 1. 所选择的待部署的改进 2. 更新了的过程文档与培训 子实践 1. 为待部署的改进划分优先级。 改进的优先级基于对估算的成本收益比进行的评价,成本收益比关系到 和性能基线相比较的质量与过程性能目标。投资回报可以用作比较的基 础。 2. 选择待部署的改进。 待部署改进的选择基于其优先级、可用资源以及对改进提议的评价与确 认活动结果等。 3. 确定如何部署每个改进。 可能部署改进的地方的实例有: • 项目特定的或者通用的工作环境 • 产品家族 • 组织的项目 • 组织级的组 4. 将选择过程的结果文档化。 186 组织级绩效管理(OPM) CMMI 开发模型,版本 1.3 SG 3 选择过程的结果通常有: • 所建议改进的选择准则 • 目标项目的特征 • 对每个改进提议的处置 • 对每个改进提议的处置依据 5. 对实施改进所需要的任何变更进行评审。 部署改进所需变更的实例有: • 过程描述、标准与规程 • 工作环境 • 教育与培训 • 技能 • 现有承诺 • 现有活动 • 对最终用户的持续支持 • 组织级文化与特征 6. 更新组织级过程资产。 更新组织级过程资产通常包括对其进行评审、获得对其的批准,以及就 其进行沟通。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 部署改进 对组织过程与技术的可度量改进得到部署,并得到了使用统计与其它量化技术的评 价。 将要部署的改进一旦得到选择,就要创建并执行部署计划。改进的部署得 到管理,并且改进的效果得到度量和评价,以判断其多大程度上为满足质 量与过程性能目标作出贡献。 SP 3.1 计划部署 建立并维护部署所选改进的计划。 部署所选改进的计划可以包含在组织级绩效管理计划中,也可以包含在改 进提议或者单独的部署文档中。 这个特定实践补充“组织级过程关注”过程域的“部署组织级过程资产” 特定实践,并且增加对量化数据的使用以指导部署及确定改进的价值。 参阅“组织级过程关注”过程域以进一步了解如何部署组织级过程资产并 纳入经验。 工作产品实例 1. 所选改进的部署计划 组织级绩效管理(OPM) 187 CMMI 开发模型,版本 1.3 子实践 1. 确定每个改进应该如何为部署进行调整。 在受限的环境(例如,针对单个改进提议)中识别的改进,可能需要为 组织的所选部分而进行修改。 2. 识别策略,以应对在部署改进提议中定义的每个改进时可能遇到的障 碍。 3. 识别改进将要部署的目标项目群体。 并非所有项目对所有改进都是合适的候选。例如,改进可能把目标指向 只有软件的项目、COTS 集成项目或者运营与支持项目等。 4. 建立度量项与目标以确定每个改进对组织的质量与过程性能目标的 价值。 度量项可以基于文档化在改进提议中的量化成功准则或者源于组织级目 标。 确定改进价值的度量项实例有: • 项目或者组织过程性能已度量的改进 • 回收改进成本所需的时间 • 通过过程或技术改进得到缓解的项目与组织级风险的数量与类型 • 对项目需求、市场情况与业务环境变更等进行响应所需的平均时间 SP 3.2 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一 致并提供度量结果。 5. 将部署所选改进的计划文档化。 部署计划应包括相关干系人、风险策略、目标项目、成功度量项以及进 度等。 6. 与相关干系人评审部署所选改进的计划并就其达成一致。 相关干系人包括改进倡导者、目标项目、支持组织等等。 7. 必要时,对部署所选改进的计划进行修订。 管理部署 管理所选改进的部署。 这个特定实践可以与“原因分析与解决”过程域的“实施行动提议”特定 实践部分地重叠(例如,在组织级或者多个项目使用原因分析与解决的时 候)。 工作产品实例 1. 更新了的培训材料(以反映部署的改进) 2. 文档化了的改进部署活动结果 3. 修订了的改进度量项、目标、优先级以及部署计划等 子实践 1. 使用部署计划监督对改进的部署。 2. 协调整个组织的改进部署。 188 组织级绩效管理(OPM) CMMI 开发模型,版本 1.3 协调部署包括如下活动: • 每个改进的对项目、支持组、以及组织级的组的协调活动 • 对部署相关改进的协调活动 3. 以受控的并且规范化的方式部署改进。 部署改进的方法的实例有: • 增量地部署改进而不是一次性部署 • 为改进的早期采用者提供全面的咨询,以替代修订后的正式培训方式 4. 对改进在项目已定义的过程中的部署适当进行协调。 参阅“组织级过程关注”过程域以进一步了解如何部署组织级过程资产 并纳入经验。 5. 适当提供咨询以支持对改进的部署。 6. 提供更新了的培训材料或者开发沟通包以反映对组织级过程资产的 改进。 参阅“组织级培训”过程域以进一步了解如何提供培训。 7. 确保按照部署计划完成对所有改进的部署。 8. 将改进部署的结果文档化并对其进行评审。 将结果文档化并对其进行评审包括: • 识别经验教训并将其文档化 • 对改进的度量项、目标、优先级、以及部署计划等进行修订 SP 3.3 评价改进效果 评价已部署的改进对质量与过程性能产生的效果。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 这个特定实践可以与“原因分析与解决”过程域的“评价已实施行动的效 果”特定实践部分地重叠(例如,在组织级或者多个项目使用原因分析与 解决的时候) 工作产品实例 1. 将已部署改进所产生效果文档化了的度量项 子实践 1. 使用部署计划中定义的度量项,随着每个改进在目标项目中的实施, 度量其结果。 2. 使用统计与其它量化技术,度量并分析在达成组织的质量与过程性能 目标方面的进展,并且在必要时采取纠正措施。 参阅“组织级过程性能”过程域以进一步了解如何建立质量与过程性 能目标并建立过程性能基线与模型。 组织级绩效管理(OPM) 189 CMMI 开发模型,版本 1.3 190 组织级绩效管理(OPM) CMMI 开发模型,版本 1.3 组织级过程性能(OPP) 成熟度 4 级过程管理类过程域 目的 简介 组织级过程性能(Organizational Process Performance,OPP)的目的在 于建立并维护对组织标准过程集中所选定过程性能的量化理解,以支持 达成质量与过程性能目标,并提供过程性能数据、基线与模型,以量化 管理组织的项目。 “组织级过程性能”过程域涉及以下活动: • 基于业务目标建立组织级量化的质量与过程性能目标(见术语表中“质 量与过程性能目标”的定义。) • 选择需要进行过程性能分析的过程或子过程 • 建立用于过程性能分析的度量项定义(见术语表中“过程性能”的定 义。) • 建立过程性能基线与过程性能模型(见术语表中“过程性能基线”与 “过程性能模型”的定义。) 基于项目与组织的需要,可以适当在组织的不同级别,包括个别项目或相 关项目的组合,进行数据的收集与分析并进行过程性能基线与模型的创建。 组织的公共度量项包括过程与产品度量项,可用于描述组织个体项目过程 的实际性能特征。通过分析所产生的度量,可以建立结果的分布或范围, 当用于个体项目时,这个分布或范围描述期望的过程性能特征。 度量质量与过程性能可以包括将现有的度量项与附加的衍生度量项相结 合以提供对项目或组织级别总体效率与效果的更深入了解。在组织级的分 析可用于研究生产率、提高效率、以及增加组织中各项目的生产能力。 期望的过程性能可用于建立项目的质量与过程性能目标,并且可用作与实 际项目绩效比较的基线。此信息用来量化地管理项目。反过来,每一个量 化管理的项目所提供的实际绩效结果,也将成为对所有项目可用的组织级 过程资产的一部分。 过程性能模型用来表示过去和当前的过程性能,并且用来预测过程将来的 结果。例如,已交付产品的潜在缺陷可以通过使用诸如复杂度之类的工作 产品属性与诸如同级评审准备时间之类的过程属性的度量进行预测。 当组织对关键过程、产品及服务特性有足够的度量项、数据以及分析技术 时,能够做到: • 确定过程是否具有一致的行为或具有稳定的趋势(即,是可预测的) • 识别性能处于自然边界内的过程,在各项目间保持一致并且有可能得 到聚合 • 识别显示出不寻常行为的过程(例如偶尔发生的,不可预见的) • 在组织标的准过程集中识别可以改进的过程方面 • 识别那些表现最佳的过程实施 本过程域与其它高度成熟过程域有交互关系,并支持它们的实现。作为实 现这一过程域所建立并维护的资产的一部分(例如,用来描述子过程行为 组织级过程性能(OPP) 191 CMMI 开发模型,版本 1.3 相关过程域 的度量项、过程性能基线、过程性能模型)是量化项目管理、原因分析与 解决以及组织级绩效管理过程的输入,支持在这些过程域中描述的分析。 量化项目管理过程提供了维护本过程域中描述的资产所需的质量与过程 性能数据。 参阅“度量与分析”过程域以进一步了解如何明确说明度量项、获得度量 数据、以及分析度量数据。 参阅“组织级绩效管理”过程域以进一步了解如何主动地管理组织的绩效 以满足其业务目标。 参阅“量化项目管理”过程域以进一步了解如何量化地管理项目,以达成 项目已建立的质量与过程性能目标。 192 组织级过程性能(OPP) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 建立性能基线与模型 SP 1.1 建立质量与过程性能目标 SP 1.2 选择过程 SP 1.3 建立过程性能度量项 SP 1.4 分析过程性能并建立过程性能基线 SP 1.5 建立过程性能模型 按目标排列的特定实践 SG 1 建立性能基线与模型 描述组织标准过程集所期望过程性能特征的基线与模型得到建立与维护。 在建立过程性能基线与模型之前,有必要确定那些过程的质量与过程性能 目标(“建立质量与过程性能目标”特定实践),哪些过程适合度量(“选 择过程”特定实践),以及哪些度量有助于决定过程性能(“建立过程性 能度量项”特定实践)。 本目标的前三个实践是相互联系的,通常需要同时并且迭代地执行以选择 质量与过程性能目标、过程、以及度量项。在选择了某一质量与过程性能 目标、与其相关的过程和度量后,往往会约束其他的选择。例如,选择一 个与交付给客户的缺陷有关的质量与过程性能目标几乎肯定需要选择验 证过程以及与缺陷相关的度量项。 本目标的意图是为项目提供需要执行量化项目管理的过程性能基线与模 型。这些基线与模型由组织多次收集或者创建,但是在一些情况下,项目 可能需要为其自身创建基线与模型。这些情况包括组织的基线与模型没能 覆盖到的那些项目。对于这样的情况,项目遵照本目标的实践以创建它自 己的基线与模型。 SP 1.1 建立质量与过程性能目标 建立并维护组织的质量与过程性能量化目标,这些目标可追溯到业务 目标。 在组织架构的不同级别建立组织的质量与过程性能目标(例如,业务领域、 产品线、职能、项目),在过程的不同层次也是如此。在建立质量与过程 性能目标时,考虑以下方面: • 与组织的业务目标的可追溯性 • 在一定环境中(例如,在项目级)所选过程或子过程的过往性能 • 过程性能的多种属性(例如,产品质量、生产率、周期、响应时间) • 所选过程或子过程的固有偏差性或自然边界 组织的质量与过程性能目标提供了过程性能分析与量化项目管理活动的 关注点和指导。然而,应该说明一点,当达成质量与过程性能目标,与现 有过程能力存在重大差距时,需要使用在“原因分析与解决”和“组织级 绩效管理”过程域中所获得的技术。 工作产品实例 1. 组织的质量与过程性能目标 子实践 1. 对质量与过程性能相关的组织业务目标进行评审。 组织级过程性能(OPP) 193 CMMI 开发模型,版本 1.3 业务目标的实例有: • 在预算内并且按时交付产品 • 在规定的时间内产品质量提高规定的百分比 • 在规定的时间内生产率提高规定的百分比 • 保持客户满意度 • 在规定的时间内新产品或服务发布的上市时间提高规定的百分比 • 在规定的时间内延迟产品功能减少规定的百分比 • 在规定的时间内产品的召回率减少规定的百分比 • 在规定的时间内客户总拥有成本减少规定的百分比 • 在规定的时间内维护遗留产品的成本减少规定的百分比 2. 定义质量与过程性能的组织的量化目标。 对于过程或子过程度量(例如:工作量、周期、缺陷排除有效性),产 品的度量(例如,可靠性、缺陷密度),以及服务度量(例如,容量、 响应时间)适当的建立质量与过程性能目标。 质量与过程性能目标的实例有: • 达成规定的缺陷逃逸率、生产率、周期、容量或成本目标 • 在规定的时间内改进缺陷逃逸率、生产率、周期、容量或成本性能在 过程性能基线规定的百分比 • 在规定时间内改进服务级别协议绩效在过程性能基线规定的百分比 SP 1.2 3. 对于质量与过程性能,定义组织目标的优先级。 4. 与相关干系人对组织的质量与过程性能目标以及其优先级进行评审、 协商并获得承诺。 5. 必要时修改组织的质量与过程性能的量化目标。 何时需要修订组织的质量与过程性能量化目标的实例有: • 当组织的业务目标改变时 • 当组织的标准过程集改变时 • 当实际质量与过程性能和目标有显著差异时 选择过程 在组织标准过程集中选择将要纳入组织过程性能分析的过程或子过程, 并维护与业务目标的可追溯性。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 组织的标准过程集是由一系列的标准过程组成,而这些过程是由子过程组 成。 通常,将统计管理技术应用到组织标准过程集的所有过程或子过程是不可 能的、无用的或不够经济合理的。根据质量与过程性能目标选择过程或子 过程。而质量与过程性能目标源于业务目标,正如在前面特定实践所描述。 194 组织级过程性能(OPP) CMMI 开发模型,版本 1.3 工作产品实例 1. 为过程性能分析所识别的过程或子过程列表,以及它们的选择理由, 包括对业务目标的可追溯性 子实践 1. 建立选择子过程时使用的准则。 可用于组织过程性能分析的过程或子过程选择准则的实例有: • 过程或子过程与关键业务目标是强相关的。 • 过程或子过程在过去已证明是稳定的。 • 与过程或子过程相关的有效历史数据是当前可使用的。 • 过程或子过程将具有足够频度产生数据以便统计管理。 • 过程或子过程是质量与过程性能的重要贡献者。 • 过程或子过程是质量与过程性能的重要预测器。 • 过程或子过程对了解达成质量与过程性能目标的关联的风险是重要 的因素。 • 与过程或子过程关联的度量与度量项的质量(例如,度量系统错误) 是足够好的。 • 描述过程或子过程行为特征的多个可度量属性是可用的。 2. 选择子过程并文档化选择的理由。 作为选择的一部分,识别与评价子过程备选方案方法的实例有: • 因果分析 • 敏感性分析 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的 决策。 3. 建立并维护所选择子过程、质量与过程性能目标以及业务目标之间的 可追溯性。 能够表达可追溯性方法的实例有: • 子过程相对质量与过程性能目标的映射 • 子过程相对业务目标的映射 • 目标下行展开(例如,目标分解到关键过程(Big Y to Vital X),方 针规划) • 平衡计分卡 • 质量功能展开(Quality Function Deployment,QFD) • 目标-问题-度量项法(Goal Question Metric) • 过程性能模型的文档 组织级过程性能(OPP) 195 CMMI 开发模型,版本 1.3 SP 1.3 4. 必要时修订该选择。 在以下情况中修订选择可能是必要的: • 过程性能模型的预测偏差太大,以至于模型无用。 • 质量与过程性能目标变更。 • 组织的标准过程集变更。 • 内在质量与过程性能变更。 建立过程性能度量项 建立并维护纳入组织过程性能分析中的度量项定义。 参阅“度量与分析”过程域以进一步了解如何明确说明度量项。 工作产品实例 1. 所选的过程性能度量项的定义及选择理由,包括对所选过程或子过程 的追溯性 子实践 1. 选择反映所选过程或子过程合适属性的度量项,以提供对组织的质量 与过程性能的深入了解。 为一个过程或者子过程定义多个度量项,对于理解过程变化的影响及避 免局部优化常常是有帮助的。另外,为所选的过程与子过程的产品与过 程属性,及其输入、输出以及消耗的资源(包括人与他们具有的技能) 建立度量项常常也是有帮助的。 目标问题度量项范式是一种可用于选择度量项的方法,它提供对组织的 质量与过程性能目标的深入了解。根据所选度量项提供的对过程性能的 理解,分析怎样才能够达到质量与过程性能目标常常是有帮助的。 用于选择度量项准则的实例有: • 度量项与组织的质量与过程性能目标间的关系 • 度量项提供整个产品或服务生命期的覆盖度 • 度量项提供对过程性能的可见性 • 度量项的可用性 • 可以收集到度量项观察值的频率 • 过程或子过程的变化对度量项的影响程度 • 度量项代表最终用户的有效过程性能观点的程度 2. 建立所选度量项的可操作定义。 参阅“度量与分析”过程域以进一步了解如何明确说明度量项。 3. 将所选的度量项纳入组织的公共度量项集。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 4. 必要时修订度量项集。 定期地对度量项进行评价,以保持它们持久的有用性与预示过程有效性 的能力。 196 组织级过程性能(OPP) CMMI 开发模型,版本 1.3 SP 1.4 分析过程性能并建立过程性能基线 分析所选定过程的性能,以及建立并维护过程性能基线。 分析所选的度量项,以描述在项目上达成的所选过程或子过程的性能特征。 此特征描述用来建立并维护过程性能基线。(见术语表中“过程性能基线” 的定义。)在给定的一系列情况下,当这些基线用于一个项目时,它们用 来确定过程或子过程期望的结果。 将过程性能基线与组织的质量与过程性能目标进行比较,以确定质量与过 程性能目标是否正在达成。 过程性能基线是组织标准过程集各细节层次的性能度量。过程性能基线可 以应对的过程如下: • 具有联系的过程序列 • 覆盖项目整个生命期的过程 • 开发个别工作产品的过程 可以有多个过程性能基线以描述组织的子组性能特征。 用于分类子组的准则实例有: • 产品线 • 业务线 • 应用领域 • 复杂度 • 团队规模 • 工作产品规模 • 来自组织的标准过程集的过程元素 对组织标准过程集进行裁剪可以很大程度上影响纳入过程性能基线的数 据可比性。应当在建立基线时考虑裁剪的影响。可以针对每种裁剪分别建 立性能基线,这取决于所容许的裁剪。 参阅“量化项目管理”过程域以进一步了解如何量化地管理项目,以达成项目 已建立的质量与过程性能目标。 工作产品实例 1. 过程性能数据的分析 2. 组织过程性能的基线数据 子实践 1. 对于所选的过程与子过程,收集所选的度量。 当采用度量时,记录使用中的过程或者子过程以使其以后能够使用。 参阅“度量与分析”过程域以进一步了解如何明确说明度量数据收集与 存储规程。 2. 分析已收集的度量项以建立结果的分布或范围,其描述了当用于项目 时所选的过程与子过程期望的性能特征。 此分析应该包括相关的过程或子过程的稳定性,以及相关因素与环境的 影响。相关因素包括过程的输入以及可以影响所得结果的其它属性。而 环境包括业务情形(例如,领域)与组织标准过程集的重大裁剪。 组织级过程性能(OPP) 197 CMMI 开发模型,版本 1.3 在可能的时候,应该使用项目稳定的子过程度量;其它数据可能是不可 靠的。 3. 从收集的度量与分析中建立并维护过程性能基线。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一 致并提供度量结果。 过程性能基线源于对所收集的度量项的分析,以建立结果的分布或范围。 这个结果描述所选过程或子过程用于组织的项目时所期望的性能特征。 4. 与相关干系人对过程性能基线进行评审并达成一致。 5. 使得度量库中的过程性能信息在整个组织中可用。 项目使用组织的过程性能基线以估算过程性能的自然边界。 6. 将过程性能基线与相关的质量与过程性能目标进行比较以决定那些 质量与过程性能目标是否正在达成。 这些比较应该使用统计技术,而不仅仅是平均值的简单比较,以测量质 量与过程性能目标达成程度。如果质量与过程性能目标没能达成,则应 当考虑纠正措施。 参阅“原因分析与解决”过程域以进一步了解如何确定所选结果的原因。 参阅“组织级过程关注”过程域以进一步了解如何计划并实施过程行动。 参阅“组织级绩效管理”过程域以进一步了解如何分析过程性能数据并 识别潜在改进领域。 7. 必要时修改过程性能基线。 何时需要修订组织的过程性能基线的实例有: • 当过程改变时 • 当组织的结果改变时 • 当组织的需要改变时 • 当供方的过程改变时 • 当供方改变时 SP 1.5 建立过程性能模型 为组织的标准过程集建立并维护过程性能模型。 高成熟度组织通常会建立并维护一套在各细节层次的过程性能模型,覆盖 组织内共有活动的某个范围,并应对组织的质量与过程性能目标。(见术 语表中“过程性能模型”的定义。)在一些情况下,项目可能需要创建他 们自己的过程性能模型。 过程性能模型用于从其它过程、产品与服务度量的值估算或预测一个过程 性能度量项的值。通常,这些过程性能模型使用从自贯穿项目的生命期中 收集的过程和产品度量以估算那些只能在项目生命期后期才能度量的质 量与过程性能目标达成的进展。 过程性能模型用于: • 组织使用过程性能模型来估算、分析并预测与组织标准过程集中过程 以及变更相关的过程性能。 • 组织使用过程性能模型评估过程改进活动(潜在的)投资回报。 198 组织级过程性能(OPP) CMMI 开发模型,版本 1.3 • 项目使用过程性能模型来估算、分析并预测他们已定义过程的过程性 能。 • 项目使用过程性能模型来选择将要使用的过程或子过程。 • 项目使用过程性能模型来估计达成项目质量与过程性能目标的进展。 定义度量项与模型,对关系到组织的质量与过程性能目标的关键过程与产 品特性提供深入了解及预测能力。 过程性能模型的实例有: • 系统动态模型 • 回归模型 • 复杂度模型 • 离散事件仿真模型 • 蒙特卡罗仿真模型 参阅“量化项目管理”过程域以进一步了解如何量化地管理项目,以达成 项目已建立的质量与过程性能目标。 工作产品实例 1. 过程性能模型 子实践 1. 基于组织的标准过程集与过程性能基线建立过程性能模型。 2. 基于过去的结果与当前的需要校准过程性能模型。 3. 与相关干系人评审过程性能模型并达成一致。 4. 支持项目使用过程性能模型。 5. 必要时修订过程性能模型。 何时需要修订过程性能模型的实例有: • 当过程改变时 • 当组织的结果改变时 • 当组织的质量与过程性能目标改变时 组织级过程性能(OPP) 199 CMMI 开发模型,版本 1.3 200 组织级过程性能(OPP) CMMI 开发模型,版本 1.3 组织级培训(OT) 成熟度 3 级过程管理类过程域 目的 简介 组织级培训(Organizational Training,OT)的目的在于发展人员的技能 与知识,使其能够有效且高效地执行他们的角色。 “组织级培训”涉及用于支持组织战略业务目标的培训,并满足跨项目、 跨支持组的通用战术培训需要。由个别项目与支持组识别的、用以满足其 特定需要的培训在项目与支持组层面进行处理,处于“组织级培训”过程 域的范围之外。 参阅“项目计划”过程域以进一步了解如何计划必需的知识与技能。 组织级培训项目包括以下活动: • 识别组织所需要的培训 • 获得并提供培训,以解决已识别的培训需要 • 建立并维护培训能力 • 建立并维护培训记录 • 评估培训有效性 有效的培训要求对培训需求进行评估、计划、教学设计与准备合适的培训 媒体(例如:练习册、计算机软件),并要有培训过程数据的存储库。作 为组织级的过程,培训的主要组件包括得到管理的培训开发项目、得到文 档化的计划、适当精通学科知识与其它知识领域的人员,以及度量培训项 目有效性的机制。 对过程培训需要的识别主要以执行组织的标准过程集所需的技能为基础。 参阅“组织级过程定义”过程域以进一步了解如何建立标准过程。 某些技能可以通过有别于课堂培训经历的其它方式(例如:非正式的辅导) 有效并高效地进行传授。其它的技能则需更正式的培训方式,诸如课堂教 学、基于网络的培训、有指导的自学或者通过正式的在岗培训项目等。各 情况下采用正式的或非正式的培训方式应当取决于对培训需要的评估,以 及要解决的绩效差距。贯穿本过程域使用的术语“培训”,其使用广泛包 括了所有这些学习方式。 当执行企业的新活动或持续进行的活动时,是否具备获取所需知识与技能 的机会是衡量培训成功的指标。 技能与知识可以是技术方面的、组织方面的或环境方面的。与技术方面的 技能有关的是使用项目或过程所要求的设备、工具、材料、数据与工艺的 能力。与组织方面的技能有关的是员工在组织结构、角色与职责、以及共 同操作原则与方法方面的、并在这些范围之内、据此而有的行为表现。与 环境方面的技能有关的是在项目与支持组的组织与社会环境中成功进行 工作所需要的自我管理、沟通与人际交往的能力。 组织级培训(OT) 201 CMMI 开发模型,版本 1.3 相关过程域 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 参阅“项目计划”过程域以进一步了解如何计划必需的知识与技能。 202 组织级培训(OT) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 建立组织级培训能力 SP 1.1 建立战略培训需要 SP 1.2 确定哪些培训需要属于组织的职责 SP 1.3 建立组织级培训的战术计划 SP 1.4 建立培训能力 SG 2 提供培训 SP 2.1 交付培训 SP 2.2 建立培训记录 SP 2.3 评估培训的有效性 按目标排列的特定实践 SG 1 建立组织级培训能力 支持组织内各角色的培训能力得到建立与维护。 组织识别必需的培训,以提升执行企业活动所必需的技能与知识。一旦识 别出这样的需要,应对那些需要的培训项目应得到设立。 SP 1.1 建立战略培训需要 建立并维护组织的战略培训需要。 战略培训需要应对的是长期目标,通过填补重大知识差距、引入新技术或 者实现重要的行为变化,以进行某项能力的建设。战略规划通常展望未来 二至五年的时间。 战略培训需要的来源的实例有: • 组织的标准过程 • 组织的战略业务规划 • 组织的过程改进计划 • 企业层面的举措 • 技能评估 • 风险分析 • 采购与供方管理 工作产品实例 1. 培训需要 2. 评估分析 子实践 1. 分析组织的战略业务目标与过程改进计划,以识别潜在的培训需要。 2. 将组织的战略培训需要文档化。 组织级培训(OT) 203 CMMI 开发模型,版本 1.3 培训需要的类别实例有: • 过程分析与文档工作 • 工程(例如:需求分析、设计、测试、配置管理、质量保证) • 供方的选择与管理 • 团队建设 • 管理(例如:估算、追踪、风险管理) • 领导力 • 灾难恢复与运营持续性 • 沟通与协商技巧 SP 1.2 3. 确定执行组织标准过程集所需要的角色与技能。 4. 将履行组织标准过程集中的角色所必需的培训文档化。 5. 将维护安全、保密与业务的持续运营所必需的培训文档化。 6. 必要时,修订组织的战略需要与必需的培训。 确定哪些培训需要属于组织的职责 确定哪些培训需要属于组织的职责,哪些留给个别项目或支持组来完 成。 参阅“项目计划”过程域以进一步了解如何计划必需的知识与技能。 除了战略培训需要,组织级的培训还应对跨项目与支持组的共同培训需求。 项目与支持组对其培训需要的识别与应对负有主要责任。组织的培训人员 只负责应对跨项目与支持组的共同培训需要(例如:多个项目共同工作环 境的培训)。然而当某些时候,在培训资源具备、并且组织的培训优先级 允许的情况下,通过与其协商,组织的培训人员可以应对项目与支持组额 外的培训需要。 工作产品实例 1. 项目与支持组共同的培训需要 2. 培训承诺 子实践 1. 对项目与支持组识别的培训需要进行分析。 对项目与支持组的需要的分析,其本意是识别能在组织范围内最有效解 决的共同培训需要。这些需要的分析活动可用于预测会首先出现在项目 与支持组层面的未来培训需要。 2. 与项目和支持组协商如何满足其培训需要。 由组织的培训人员提供的支持依赖于可用的培训资源与组织的培训优先 级。 204 组织级培训(OT) CMMI 开发模型,版本 1.3 适合由项目或支持组执行的培训的实例有: • 在项目的应用领域或服务领域内的培训 • 由项目或支持组使用的独有的工具与方法的培训 • 在安全性、保密性与人员因素方面的培训 SP 1.3 3. 文档化为项目与支持组提供培训支持而做出的承诺。 建立组织级培训的战术计划 建立并维护组织级培训的战术计划。 组织级培训的战术计划所计划的是由组织负责的、并且是个体有效履行其 角色所必要的培训。这份计划对近期将进行的培训做出安排,并且根据变 更(例如:需要方面的、资源方面的)与有效性评价定期地加以调整。 工作产品实例 1. 组织级培训的战术计划 子实践 1. 建立计划的内容。 组织级培训的战术计划通常包含: • 培训需要 • 培训主题 • 基于培训活动与其依赖关系的进度 • 培训所用的方法 • 对培训材料的需求与质量标准 • 培训任务、角色与责任 • 必需的资源,包括工具、设施、环境、人员、技能与知识 SP 1.4 2. 建立对计划的承诺。 由那些负责实施与支持该计划的人员做出的文档化的承诺,是计划具有 有效性的必要条件。 3. 必要时,修订计划与承诺。 建立培训能力 建立并维护培训能力,以解决组织级培训需要。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 依据所建立的准则,分析可能的决策,评价所识别的备选方案。 工作产品实例 1. 培训资料与支持性产物 子实践 1. 选择适当的方法以满足组织级的培训需要。 组织级培训(OT) 205 CMMI 开发模型,版本 1.3 有许多因素可能影响培训方法的选择,包括受众特定的知识、成本、日 程与工作环境。选择方法时,需要考虑在给定的约束下提供技能与知识 的最有效的方法。 培训方法的实例有: • 课堂培训 • 计算机辅助教学 • 有指导的自学 • 正式的师徒制与辅导项目 • 视频教学 • 注入式教学 • 便当午餐研讨会 • 结构化的在岗培训 2. 确定培训资料是内部开发还是外部采购。 确定内部培训开发与采购外部培训的成本与收益。 可用于确定知识或技能最有效的获得方式,其准则的实例有: • 对工作或过程性能目标的适用性 • 所具备的对项目执行进行准备的时间 • 对业务目标的适用性 • 内部专家的可用性 • 来源于外部的培训的可用性 来源于外部的培训的实例有: • 客户提供的培训 • 可购买到的培训课程 • 学术项目 • 专业会议 • 研讨会 3. 开发或获得培训材料。 培训可以由项目、支持组、本组织或外部组织提供。不管培训的来源如 何,培训的采购与交付由组织的培训人员进行协调。 培训材料的实例有: • 课程 • 计算机辅助教学 • 视频 4. 培养或获得合格的讲师、教学设计者或辅导员。 206 组织级培训(OT) CMMI 开发模型,版本 1.3 为保证那些开发并交付内部培训的人员具备必需的知识与培训技能,可 以定义准则,以识别、培养并使其合格。培训开发,包括自学与在线培 训,都应当使那些有教学设计经验的人参与进来。在外部培训的情况下, 组织的培训人员可以调查该培训提供者是如何确定交付培训的讲师的。 也可以是选择或继续使用某一培训提供者的因素。 5. 描述组织的培训课程表中的培训。 在各课程的培训描述中所提供的信息实例有: • 培训中所覆盖的主题 • 预期的受众 • 参加的前提条件与准备 • 培训目标 • 培训时长 • 教案 • 课程的完成准则 • 准许免修的准则 6. 必要时,修订培训资料与支持性产物。 培训资料与支持性产物可能需要修订的场合,其实例有: • 培训需要的变更(例如:与培训主题相关联的新技术已具备) • 从培训的评价识别出变更需要(例如:对培训有效性问卷调查的评价、 培训项目绩效评估、讲师评价表) SG 2 提供培训 使个人能够有效执行其角色的培训得到提供。 选择待培训的人员时,应考虑以下因素: • 培训参加者的目标群体的背景 • 接受培训的前提背景条件 • 人员执行其角色所需要的技能与能力 • 包括项目管理在内、对所有学科进行跨学科培训的需要 • 对管理人员进行适当的组织过程培训的需要 • 对质量管理、配置管理与其它相关支持职能的支持人员就所有适当学 科或服务的基本原则进行培训的需要 • 对关键的职能领域提供胜任能力开发的需要 • 对维护人员操作并维护多个项目通用的工作环境方面的胜任能力与资 质的要求 组织级培训(OT) 207 CMMI 开发模型,版本 1.3 SP 2.1 交付培训 按照组织级培训的战术计划,交付培训。 工作产品实例 1. 已交付的培训课程 子实践 1. 选择那些将接受必需的培训以有效执行其角色的人员。 培训意在将知识与技能传授给在组织中执行各种角色的人员。某些人员 已具备良好执行其指定角色所必需的知识与技能。这些人员的培训可以 得到豁免,但是应当小心不能滥用培训豁免。 2. 排定培训日程,必要时,包括资源(例如:设施、讲师等)。 应当计划培训并排定日程。所提供的培训应对工作绩效的期望有直接影 响。因此,最佳的培训应该及时出现在对工作绩效有迫切期待之时。 对绩效的期望通常包括: • 培训专用工具的使用 • 培训执行人员所不熟悉的规程 SP 2.2 3. 交付培训。 如果培训由个人交付,则应当由适当的培训专家(例如:有经验的讲师、 辅导员)来交付培训。培训的提供应尽可能以类似于实际工作环境的布 置方式进行,并且包括模拟实际工作情况的活动。这一方法包括将与胜 任能力开发相关的工具、方法与规程进行集成。培训与工作责任紧密关 联,因而在培训交付后的合理时间内,在岗活动或其它外部经验将进一 步强化该培训。 4. 对照计划追踪培训的交付。 建立培训记录 建立并维护组织级培训的记录。 本实践适用于在组织级层面上执行的培训。对于由项目或支持组发起并资 助的培训,建立并维护培训记录是各项目或支持组各自的职责。 工作产品实例 1. 培训记录 2. 对组织级存储库中培训内容的更新 子实践 1. 保存所有成功完成以及未成功完成各培训课程或其它批准的培训活 动的学员的记录。 2. 保存豁免了培训的所有人员的记录。 应当将准许豁免的依据文档化,并且豁免应得到负责培训的管理人员的 批准与被豁免人的管理人员的批准。 3. 保存成功完成所要求培训的所有学员的记录。 4. 使培训记录对合适的人员可用,用以考虑工作的分配。 培训记录可包含在由培训组织制订的技能矩阵之中,以提供人员的经验 与教育的汇总,以及由组织发起并资助的培训。 208 组织级培训(OT) CMMI 开发模型,版本 1.3 SP 2.3 评估培训的有效性 评估组织培训项目的有效性。 应当具备用以确定培训的有效性(即培训多大程度能够满足组织的需要) 的过程。 用于评估培训有效性的方法,其实例有: • 培训场合中的测验 • 培训参加者的培训后问卷调查 • 培训后效果的管理人员满意度问卷调查 • 课件中内含的评估机制 可以采集度量数据,以对照项目的与组织的目标评估培训的收益。应当特 别留意对各种不同培训方法的需要,比如将培训团队作为工作单位整体的 一部分。使用该方法时,工作绩效或过程性能的目标应当是明确的、可观 察的、可验证的,并且能够与课程参加者进行分享。如同在“建立培训能 力”特定实践中所描述的那样,应当将培训有效性评估的结果用于修订培 训材料。 工作产品实例 1. 培训有效性问卷调查 2. 培训项目绩效评估 3. 讲师评价表 4. 培训测验 子实践 1. 评估进行中的或已完成的项目,以确定人员的知识是否足以执行项目 的任务。 2. 提供各培训课程相对于所建立的组织级、项目级或个人的学习(或绩 效)目标的有效性评估机制。 3. 就培训活动在多大程度上能够符合学员的需要,获得学员的评价。 组织级培训(OT) 209 CMMI 开发模型,版本 1.3 210 组织级培训(OT) CMMI 开发模型,版本 1.3 产品集成(PI) 成熟度 3 级工程类过程域 目的 简介 产品集成(Product Integration,PI)的目的在于将产品组件装配成产品, 确保产品作为一个整体正确地运行(即具有所要求的功能与质量属性), 并交付产品。 本过程域涉及如何将产品组件集成为更复杂的产品组件或者完整的产品。 本过程域的范围是按照已定义的集成策略与规程,在一个阶段或者增量式 的多个阶段中进行产品组件的渐进装配,以实现完整的产品集成。本过程 域中使用的术语“产品”与“产品组件”,其含义也包括服务、服务系统 及其组件。 产品集成的一个重要方面是管理产品与产品组件的内部与外部接口,以确 保接口间的兼容性。这些接口并不局限于用户界面,也适用于产品组件之 间的接口,包括内部与外部的数据源、中间件以及其它组件——它们可能 受或不受开发组织的控制,但是产品却依赖于它们。在项目过程中应始终 关注接口管理。 产品集成远远不只是在设计与制造完结时将产品组件一次性地装配起来。 产品集成可以采用装配产品组件、对其进行评价、然后装配更多产品组件 的重复过程增量式地进行,也能采用对经过完整单元测试的产品的高度自 动化的构建与持续集成来进行。本过程可以始于分析与模拟(例如多线程、 快速原型、虚拟原型、实体原型),逐步获得更多现实的增量而稳步进展, 直至完成最终的产品。在每一次连续的构建中,原型(虚拟的、快速的或 者实体的)得到构筑、评价、改进以及基于评价过程中所获知识的重构。 所需要的原型的虚拟化或者实体化程度取决于设计工具的功能、产品的复 杂性及其相关的风险。以这种方式集成的产品更有可能通过对产品的验证 与确认。对于某些产品与服务来说,最后的集成阶段发生于它们被部署在 预期的运行场所时。 对于产品线来说,产品是按照产品线的生产计划来装配的。产品线的生产 计划明确说明了装配过程,包括使用哪些核心资产,以及如何在这些核心 资产范围内解决产品线所需的适应性变化。 在敏捷环境中,产品集成是频繁的活动,常常每天进行。例如,对于软件来说, 在一个被称为“持续集成”的过程中,持续地向代码库添加可工作的代码。除 了持续集成以外,产品集成策略还说明如何并入供方提供的组件、如何构建功 能(分层或者“纵向切片”)、以及何时进行“重构”。应该在项目初期建立 该策略,并且及时修订以反映逐步演进和出现的组件接口、外部输入、数据交 换和应用程序接口。(见第一部分中的“使用敏捷方法时对 CMMI 的解读”) 产品集成(PI) 211 CMMI 开发模型,版本 1.3 相关过程域 参阅“需求开发”过程域以进一步了解如何识别接口需求。 参阅“技术解决方案”过程域以进一步了解如何使用准则设计接口。 参阅“确认”过程域以进一步了解如何执行确认。 参阅“验证”过程域以进一步了解如何执行验证。 参阅“配置管理”过程域以进一步了解如何跟踪并控制变更。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“风险管理”过程域以进一步了解如何识别并缓解风险。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和服 务的活动。 212 产品集成(PI) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 准备产品集成 SP 1.1 建立集成策略 SP 1.2 建立产品集成环境 SP 1.3 建立产品集成规程与准则 SG 2 确保接口兼容性 SP 2.1 评审接口描述的完整性 SP 2.2 管理接口 SG 3 装配产品组件并交付产品 SP 3.1 确定需集成的产品组件准备就绪 SP 3.2 装配产品组件 SP 3.3 评价装配后的产品组件 SP 3.4 打包并交付产品或产品组件 按目标排列的特定实践 SG 1 准备产品集成 产品集成的准备工作得以进行。 产品组件集成的准备工作包括建立集成策略、建立执行集成的环境以及建 立集成的规程与准则。集成的准备工作始于项目初期。 SP 1.1 建立集成策略 建立并维护产品集成策略。 产品集成策略描述了接收、装配与评价构成产品的产品组件的方法。 产品集成策略说明了以下事项: • 使产品组件达到可供集成的状态(例如以何种顺序) • 采用一次性构建或者连续的增量式构建来进行装配与评价 • 采用迭代开发时,每一迭代包含并测试的特性 • 管理接口 • 采用模型、原型和模拟来辅助评价某一次装配,包括其接口 • 建立产品集成环境 • 定义规程与准则 • 使适当的测试工具与环境可用 • 管理产品的层次、架构与复杂度 • 记录评价结果 • 处理异常事项 集成策略还应当与“项目计划”过程域中描述的技术方法相匹配,并与“技 术解决方案”过程域中做出的产品与产品组件的解决方案选择、得到的产 品与产品组件设计相协调。 参阅“技术解决方案”过程域以进一步了解如何选择产品组件解决方案以 及如何实现设计。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“项目计划”过程域以进一步了解如何建立并维护定义项目活动的计 划。 产品集成(PI) 213 CMMI 开发模型,版本 1.3 SP 1.2 参阅“风险管理”过程域以进一步了解如何识别并缓解风险。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和服 务的活动。 制订产品集成策略的结果通常被文档化为产品集成计划,并得到干系人的 评审以促进承诺与理解。本过程域的其它特定实践和通用实践中还会给出 产品集成策略中说明的某些事项的更多细节(例如环境、规程与准则、培 训、角色与职责、相关干系人的参与)。 工作产品实例 1. 产品集成策略 2. 选择或拒绝备选的产品集成策略的依据 子实践 1. 识别需集成的产品组件。 2. 识别产品组件集成期间需执行的验证活动。 应包括对接口验证活动的识别。 3. 识别备选的产品组件集成策略。 制订集成策略时可以详细说明并评价多种备选的集成策略或者顺序。 4. 选择最佳的集成策略。 以下各项的可用性需要与集成策略相匹配或者相协调:产品组件、集成 环境、测试工具与设备、规程与准则、相关干系人,以及具备适当技能 的人员。 5. 定期评审产品集成策略,必要时进行修订。 评价产品集成策略,以确保生产与交付的进度偏差不会对集成顺序产生 负面影响,或者危害到早期决策时依赖的各要素。 6. 记录作出决策与推迟决策的依据。 建立产品集成环境 建立并维护支持产品组件集成所需的环境。 产品集成的环境既可以是外购的也可以是开发的。为建立环境,需要为购 买或开发设备、软件或其它资源进行需求开发。这些需求在实施与“需求 开发”过程域相关的过程时得到收集。产品集成环境可以包含对现有的组 织级资源的重复利用。关于外购或开发产品集成环境的决策在与“技术解 决方案”过程域相关的过程中得到处理。 参阅“技术解决方案”过程域以进一步了解如何执行自制、购买或复用分 析。 产品集成过程中的每一步所需要的环境可以包括测试设备、模拟器(替代 尚不可用的产品组件)、真实设备部件以及记录设备。 工作产品实例 1. 经过验证的产品集成环境 2. 产品集成环境的支持文档 子实践 1. 识别对产品集成环境的需求。 2. 确定产品集成环境的验证规程与准则。 214 产品集成(PI) CMMI 开发模型,版本 1.3 SP 1.3 3. 决定制造或购买所需的产品集成环境。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和 服务的活动。 4. 如果无法采购适用的环境,则开发集成环境。 对于前所未有的、复杂的项目来说,产品集成环境可以是重大的开发任 务。这也同样地需要包含项目计划、需求开发、技术解决方案、验证、 确认以及风险管理。 5. 维护产品集成环境直至项目结束。 6. 对环境中不再有用的部分进行废弃处置。 建立产品集成规程与准则 建立并维护产品组件集成的规程与准则。 产品组件集成的规程可以包括将要执行的增量式迭代的次数以及每一阶 段将要完成的测试与其它评价的细节等内容。 准则可以表明产品组件是否已经达到适于集成的状态,或者其可接受性。 产品集成的规程与准则阐述的内容有: • 构建组件时需要的测试等级 • 接口的验证 • 性能偏差的阈值 • 装配件及其外部接口的衍生需求 • 允许的组件替代物 • 测试环境参数 • 测试成本的限制 • 集成操作中的质量/成本权衡 • 功能正常的概率 • 交付率及其变差 • 从下订单到交付的提前时间 • 员工的可用性 • 集成设施/生产线/环境的可用性 可以为如何验证产品组件定义准则,也可以为它们应有的表现(功能与质 量属性)定义准则,还可以为如何确认并交付装配后的产品组件与最终集 成后的产品定义准则。 准则也可以约束产品组件通过测试时所允许的模拟程度,或者约束集成测 试所用的环境。 应当将装配进度与准则中的相关部分共享给工作产品的供方,以减少延误 与组件故障。 参阅“供方协议管理”过程域以进一步了解如何履行供方协议。 工作产品实例 1. 产品集成规程 2. 产品集成准则 产品集成(PI) 215 CMMI 开发模型,版本 1.3 SG 2 子实践 1. 建立并维护产品组件的产品集成规程。 2. 建立并维护产品组件集成与评价的准则。 3. 建立并维护确认与交付集成后产品的准则。 确保接口兼容性 产品组件的内部与外部接口都是兼容的。 许多产品集成问题起因于内部与外部接口的不为人知或不受控制的方面。 对产品组件的接口需求、规格说明与设计的有效管理有助于确保将来实现 的接口是完整的和兼容的。 SP 2.1 评审接口描述的完整性 评审接口描述的覆盖度与完整性。 除了产品组件接口以外,还应包括所有与产品集成环境之间的接口。 工作产品实例 1. 接口的类别 2. 每类接口的清单 3. 接口与产品组件和产品集成环境的对应关系 子实践 1. 评审接口数据的完整性并确保完全覆盖了所有接口。 考虑所有的产品组件并准备一个关系表。通常可以将接口分成三种主要 类型:环境的、物理的、功能的。这些类型中的典型类别有:机械的、 流体的、声学的、电气的、气候的、电磁的、热的、消息的以及人机接 口。 能归入上述三类的接口的实例(例如机械或电子组件的)有: • 机械接口(例如重量与体积、重心、运转时的部件间隙、维修时所需 的空间、固定连接、机动连接、承载结构传来的冲击与振动) • 噪声接口(例如结构件传来的噪声、空气中传来的噪声、声学效果) • 气候接口(例如温度、湿度、气压、盐度) • 热接口(例如热耗散、向承载结构的热传导、空调特性) • 流体接口(例如海军或沿海地区的产品的淡水出入口和海水出入口、 空调、压缩空气、氮气、燃料、润滑油、排气口) • 电气接口(例如瞬变与峰值电压时电网的供电量、供电与通信的非敏 感控制信号、敏感信号[如模拟链路]、干扰信号[如微波]、符合 暴风标准[TEMPEST standard]的接地信号) • 电磁接口(例如磁场、无线电与雷达链路、光波段连接波导管、同轴 电缆与光纤) • 人机接口(例如音频或语音合成、音频或语音识别、显示[模拟拨号、 液晶显示、发光二极管指示灯]、手动控制[脚踏板、游戏杆、轨迹 球、键盘、按键、触摸屏]) • 消息接口(例如源点、终点、刺激、协议、数据特性) 216 产品集成(PI) CMMI 开发模型,版本 1.3 SP 2.2 2. 确保产品组件与接口得到了标记,以确保简便并正确地连接相接的产 品组件。 3. 定期评审接口描述的完备性。 接口描述一经建立,就应该定期得到评审,以确保在现有的描述与正在 开发、加工、制造或购买的产品之间没有偏差。 应该与相关干系人一起评审产品组件的接口描述,以避免误解,减少延 误,并防止开发出不能正常工作的接口。 管理接口 管理产品与产品组件的内部与外部接口的定义、设计与变更。 接口需求驱动了集成产品组件所需要的接口的开发。对产品与产品组件接 口的管理始于产品开发初期。接口的定义与设计不仅影响产品组件与外部 系统,还影响验证与确认的环境。 参阅“需求开发”过程域以进一步了解如何识别接口需求。 参阅“技术解决方案”过程域以进一步了解如何使用准则设计接口。 参阅“配置管理”过程域以进一步了解如何使用配置识别、配置控制、配 置状态记录与报告以及配置审计来建立并维护工作产品的完整性。 参阅“需求管理”过程域中的“管理需求变更”特定实践以进一步了解如 何管理接口需求的变更 对接口的管理包括维护产品生命期中接口的一致性、符合架构决策和约束、 以及解决冲突、不兼容和变更等问题。管理好外购产品与其它产品或产品 组件之间的接口对于项目的成功至关重要。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和服 务的活动。 除了产品组件接口以外,还应包括所有与环境和验证、确认、操作和支持 等其它环境之间的接口。 接口变更得到文档化、维护并易于获取。 工作产品实例 1. 产品组件与外部环境的关系列表(例如主电源、紧固产品、计算机总 线系统) 2. 不同产品组件之间的关系列表 3. 适用时,列出经过约定的为每对产品组件定义的接口清单 4. 接口控制工作组会议的报告 5. 更新接口的行动事项 6. 应用程序接口(application program interface,API) 7. 更新的接口描述或协议 产品集成(PI) 217 CMMI 开发模型,版本 1.3 SG 3 子实践 1. 确保接口在产品生命期中的兼容性。 2. 解决冲突、不兼容与变更问题。 3. 维护接口数据存储库使之可供项目成员访问。 可共同访问的接口数据存储库提供了一种机制,以确保每个人都知道当 前的接口数据在何处并能够在需要使用时得到它们。 装配产品组件并交付产品 经过验证的产品组件得到装配,经过集成、验证与确认的产品得到交付。 产品组件的集成按照产品集成策略与规程进行。集成之前,应确定每一产 品组件都符合其接口需求。产品组件被装配为更大、更复杂的产品组件。 这些装配后的产品组件得到检查,以保证正确的互操作。持续这一过程直 至产品集成完毕。如果在这一过程中发现问题,应将问题记录下来并触发 纠正措施过程。 所需产品组件的及时接收与合适人员的参与,有助于将构成产品的产品组 件成功地集成起来。 SP 3.1 确定需集成的产品组件准备就绪 在装配之前,确定装配产品所需的每一产品组件都得到了正确的识别, 能按照其描述运行,并且产品组件的接口符合其接口描述。 参阅“验证”过程域以进一步了解如何执行验证。 本特定实践的目的是确保经过正确识别、能满足其描述的产品组件,能按 照产品集成策略与规程得到实际装配。要检查产品组件的数量、明显的损 伤以及产品组件与接口描述的一致性。 执行产品集成的人员要从根本上为检查负责,以确保在装配之前,对产品 组件来说所有条件都是适合的。 工作产品实例 1. 接收的产品组件的验收文档 2. 交付收据 3. 经检查的装箱单 4. 异常事件报告 5. 豁免声明书 子实践 1. 在产品组件可供集成之后,尽快跟踪所有产品组件的状态。 2. 确保产品组件按照产品集成策略与规程交付到产品集成环境。 3. 确定收到了各项正确识别的产品组件。 4. 确保各项接收到的产品组件满足其描述。 5. 按照期望的配置检查配置状态。 6. 在将产品组件连接起来之前,对所有的物理接口执行预检查(例如目 视检查、使用基本的测量手段)。 218 产品集成(PI) CMMI 开发模型,版本 1.3 SP 3.2 SP 3.3 装配产品组件 按照产品集成策略与规程装配产品组件。 本特定实践的装配活动与下一项特定实践的评价活动是迭代进行的,从最 初的产品组件开始,经过产品组件的中间装配件,直至产品成为一个整体。 工作产品实例 1. 装配后的产品或产品组件 子实践 1. 确保产品集成环境就绪。 2. 按照产品集成策略、规程与准则进行集成。 记录所有适当的信息(例如配置状态、产品组件的序列号、类型、计量 器具的校准日期)。 3. 在适当的情况下,修订产品集成策略、规程与准则。 评价装配后的产品组件 评价装配后的产品组件的接口兼容性。 参阅“确认”过程域以进一步了解如何执行确认。 参阅“验证”过程域以进一步了解如何执行验证。 评价包括采用产品集成规程与准则检查并测试装配后产品组件的性能、适 用性或者完成度。这些评价按照产品集成策略与规程中的规定,在产品组 件装配的不同阶段酌情进行。产品集成策略与规程可以定义更加精细的集 成与评价顺序,而不只是有人可能想象的只是检查产品的层级或架构。例 如,如果某个产品组件装配件由四个较简单的产品组件构成,集成策略不 必要求将这四个元件视为一体同时进行集成和评价。相反,这四个较简单 的元件可以是逐步集成的,一次一个,在实现满足产品架构中的规格说明 的更复杂产品组件之前的每一次装配操作之后,都进行评价。产品集成策 略与规程也可以决定只需要进行最后的评价。 工作产品实例 1. 异常事件报告 2. 接口评价报告 3. 产品集成总结报告 子实践 1. 按照产品集成策略、规程与准则对装配后的产品组件进行评价。 2. 记录评价结果。 结果的实例有: • 需要对集成规程或准则进行的任何适应性调整 • 对产品配置(备件、新发布)的任何变更 • 评价规程或准则的偏差 产品集成(PI) 219 CMMI 开发模型,版本 1.3 SP 3.4 打包并交付产品或产品组件 打包已装配的产品或产品组件并将其交付给客户。 参阅“确认”过程域以进一步了解如何执行确认。 参阅“验证”过程域以进一步了解如何执行验证。 可以在规格说明与验证准则中说明某些产品的打包需求。当客户存储和运 输物品时,这些需求的处理尤为重要。在这类情况下,可以针对包装规定 一系列的环境与应力条件。在其它情况下,下列因素可能变得重要: • 运输的经济性与简便性(例如集装箱化) • 应承担的责任(例如收缩包装) • 方便而安全地解包(例如锋利的边缘、捆绑方式的强度、对儿童无害、 包装材料的环保性、重量) 在工厂里将产品组件装配起来所需要的调整可能不同于在操作现场安装 时所需要的调整。这时,应使用向客户提供的产品日志来记录这类特殊参 数。 工作产品实例 1. 包装好的产品或产品组件 2. 交付文档 子实践 1. 评审需求、设计、生产、验证结果以及文档,以确保影响产品的打包 与交付的问题都已经得到了识别与解决。 2. 采用有效的方法打包并交付装配后的产品。 软件打包与交付的方法实例有: • 磁带 • 磁盘 • 硬拷贝文档 • 光盘 • 其它电子分发方式如因特网 3. 满足打包与交付产品时适用的需求与标准。 需求与标准的实例包括安全性、环保、安防性、可运输性以及废弃处置 等方面。 关于打包与交付软件的需求与标准实例有: • 存储与交付介质的类型 • 主拷贝与备份拷贝的保管人 • 需要的文档 • 版权 • 授权条款 • 软件的保密性 220 产品集成(PI) CMMI 开发模型,版本 1.3 4. 为产品安装准备操作现场。 操作现场的准备可以是客户或者最终用户的责任。 5. 交付产品及相关文档并确定获得收据。 6. 在操作现场安装产品并确定产品能正确操作。 安装产品可以由客户或最终用户负责。某些情况下,只需要简单的几步 就能证实产品能正确操作。其它情况下,需要在操作现场进行对完整产 品的最终验证。 产品集成(PI) 221 CMMI 开发模型,版本 1.3 222 产品集成(PI) CMMI 开发模型,版本 1.3 项目监督与控制(PMC) 成熟度 2 级项目管理类过程域 目的 简介 相关过程域 项目监督与控制(Project Monitoring and Control,PMC)的目的在于提 供对项目进展的了解,以便在项目绩效显著偏离计划时可采取适当的纠正 措施。 文档化的项目计划是监督活动、沟通状态以及采取纠正措施的基础。主要 通过在项目进度表或 WBS 中预定的里程碑处或者控制级别上,将实际的 工作产品与任务属性、工作量、成本以及进度与计划进行对比来确定进展 情况。对进展的适当可视性使得绩效与计划发生显著偏差时能够及时采取 纠正措施。显著偏差是指如果不解决就会妨碍项目达成其目标的偏差。 在本过程域中,用术语“项目计划”表示用于控制项目的总体计划。 当实际状态与预期情况显著偏离时,就要酌情采取纠正措施。这些措施可 能需要重新计划,包括修订原来的计划,建立新的协议,或者在当前计划 中增加额外的缓解活动。 参阅“度量与分析”过程域以进一步了解如何提供度量结果。 参阅“项目计划”过程域以进一步了解如何建立并维护定义项目活动的计 划。 项目监督与控制(PMC) 223 CMMI 开发模型,版本 1.3 SG 1 对照计划监督项目 SP 1.1 监督项目计划参数 SP 1.2 监督承诺 SP 1.3 监督项目风险 SP 1.4 SP 1.5 SP 1.6 SP 1.7 监督数据管理 监督干系人的参与 进行进展评审 进行里程碑评审 SG 2 管理纠正措施直至关闭 SP 2.1 分析问题 SP 2.2 采取纠正措施 SP 2.3 管理纠正措施 按目标排列的特定实践 特定目标与特定实践摘要 SG 1 对照计划监督项目 对照项目计划,项目的实际进展与绩效得到监督。 SP 1.1 监督项目计划参数 对照项目计划,监督项目计划参数的实际值。 项目计划参数构成了通常的项目进展与绩效指标,并且包括了工作产品与 任务的属性、成本、工作量和进度。工作产品与任务的属性包括规模、复 杂度、服务水平、可用性、重量、形状、匹配以及功能。应该考虑监督参 数的频率。 监督通常涉及度量项目计划参数的实际值,将实际值与计划中的估算值相 比较,并且识别重大偏差。对项目计划参数实际值的记录包括对相关情境 信息的记录,以帮助理解度量结果。在本过程域的特定目标 2 及其特定实 践中将描述如何分析重大偏差的影响,以确定需要采取何种纠正措施。 工作产品实例 1. 项目绩效记录 2. 重大偏差记录 3. 成本绩效报告 子实践 1. 对照进度监督进展。 进展监督通常包括: • 定期度量各活动和里程碑的实际完成情况 • 将活动和里程碑的实际完成情况与项目计划中的进度相比较 • 识别与项目计划中的进度估算值的重大偏差 2. 监督项目成本与投入的工作量。 224 项目监督与控制(PMC) CMMI 开发模型,版本 1.3 工作量与成本监督通常包括: • 定期度量花费的实际工作量与成本,以及指派的人员 • 将实际的工作量、成本、人员以及培训与项目计划中的预算和估算值 相比较 • 识别与项目计划中的预算和估算的显著偏差 3. 监督工作产品与任务的属性。 参阅“度量与分析”过程域以进一步了解如何开发并保持用于支持管理 信息需要的度量能力。 参阅“项目计划”过程域以进一步了解如何建立并维护工作产品与任务 属性的估算。 监督工作产品与任务的属性通常包括: • 定期度量工作产品与任务的规模、复杂度或服务水平等实际属性(以 及这些属性的变化) • 将实际的工作产品与任务属性(以及这些属性的变化)与项目计划中 的估算值相比较 • 识别与项目计划中的估算值的重大偏差 4. 监督资源的提供与使用。 参阅“项目计划”过程域以进一步了解如何计划项目资源。 资源的实例有: • 物理设施 • 计算机、外围设备以及软件 • 网络 • 保密环境 • 项目人员 • 过程 5. 监督项目人员的知识与技能。 参阅“项目计划”过程域以进一步了解如何计划所需的知识与技能。 监督项目人员的知识与技能通常包括: • 定期度量项目人员获得的知识与技能 • 比较实际接受的培训与项目计划中的培训 • 识别与项目计划中的估算值的重大偏差 6. 将项目计划参数的重大偏差文档化。 项目监督与控制(PMC) 225 CMMI 开发模型,版本 1.3 SP 1.2 SP 1.3 监督承诺 对照项目计划,监督所识别的承诺。 工作产品实例 1. 对承诺进行评审的记录 子实践 1. 定期地评审承诺(外部的和内部的)。 2. 识别尚未满足的承诺,或者存在无法满足的重大风险的承诺。 3. 记录对承诺进行评审的结果。 监督项目风险 对照项目计划,监督所识别的风险。 参阅“项目计划”过程域以进一步了解如何识别项目风险。 参阅“风险管理”过程域以进一步了解如何在项目潜在的问题发生前对其 进行识别,以便在整个产品或项目生命期中,计划并在必要时启动风险的 处理行动,从而降低这些潜在问题对达成目标产生的不利影响。 工作产品实例 1. 项目风险监督的记录 子实践 1. 结合项目当前的状态与环境,定期评审风险文档。 2. 在得到新增信息时,修订风险文档。 随着项目的进展(特别是长期或持续运行的项目),会出现新的风险。 识别并分析新的风险很重要。例如,软件、设备以及使用的工具可能变 得过时;或在对项目与组织极具长期重要性的领域,关键人员的技能逐 步退化。 3. 向相关干系人通报风险的状态。 风险状态的实例有: • 风险发生概率的变化 • 风险优先级的变化 SP 1.4 监督数据管理 对照项目计划,监督项目数据的管理。 参阅“项目计划”过程域中的“计划数据管理”特定实践以进一步了解如 何识别应管理数据的类型以及如何计划这些管理活动。 为确保数据管理要求得到满足,应监督数据管理活动。根据监督结果以及 项目需求、情况或状态的变更,可能需要重新计划项目的数据管理活动。 工作产品实例 1. 数据管理的记录 226 项目监督与控制(PMC) CMMI 开发模型,版本 1.3 子实践 1. 对照项目计划中的有关描述,定期评审数据管理活动。 2. 识别重大问题及其影响,将其文档化。 重大问题的一个实例是干系人无法访问其作为相关干系人履行角色时所 需的项目数据。 SP 1.5 3. 将数据管理活动的评审结果文档化。 监督干系人的参与 对照项目计划,监督干系人的参与。 参阅“项目计划”过程域中的“计划干系人的参与”特定实践以进一步了 解如何识别相关干系人并计划他们适当的参与。 为确保适当的交互,应监督干系人的参与。根据监督结果以及项目需求、 情况或状态的变更,可能需要重新计划干系人的参与活动。 在敏捷环境下,客户与潜在的最终用户持续参与项目的产品开发活动对项目成 功至关重要;因此客户与最终用户在项目中的参与活动也应该受到监督。(见 第一部分中的“使用敏捷方法时对 CMMI 的解读”。) SP 1.6 工作产品实例 1. 干系人参与的记录 子实践 1. 定期评审干系人参与的状态。 2. 识别重大问题及其影响,并将它们文档化。 3. 将干系人参与状态的评审结果文档化。 进行进展评审 定期评审项目的进展、绩效与问题。 “项目的进展”是在某个特定时间点的项目状态,与相关干系人(特别是 项目代表及项目管理层)评审到此时间点为止项目活动的执行情况、结果 与影响,以决定是否存在重大问题或需要处理的绩效不足。 进展评审是为了保持相关干系人对项目情况的了解而进行的评审。这些项 目评审可以是非正式的,也可能并未在项目计划中明确规定。 工作产品实例 1. 文档化的项目评审结果 子实践 1. 定期与相关干系人沟通已分派的活动与工作产品的状态。 酌情组织管理人员、员工、客户、最终用户、供方以及其他相关干系人 参与评审。 2. 评审用于控制项目的度量项的收集与分析结果。 被评审的度量可以包括客户满意度度量项。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一 致并提供度量结果。 项目监督与控制(PMC) 227 CMMI 开发模型,版本 1.3 SG 2 SP 1.7 3. 识别重大问题和与计划的偏差,并将其文档化。 4. 将工作产品与过程中识别出来的变更请求及问题文档化。 参阅“配置管理”过程域以进一步了解如何跟踪并控制变更。 5. 将评审结果文档化。 6. 跟踪变更请求与问题报告直至关闭。 进行里程碑评审 在选定的项目里程碑处,评审项目的已完成情况与结果。 参阅“项目计划”过程域中的“建立预算与进度”特定实践以进一步了解 如何识别主要的里程碑。 里程碑是预先计划的事件或指定时间点,用来执行对项目状态的全面评审, 以便了解干系人需求的符合程度。(如果项目包含一个演进性的里程碑, 那么应执行评审以确保与该里程碑相关的假设及需求都已得到满足。)里 程碑可以与整体项目或一个特定的服务类型或服务实例相关。因此里程碑 可以基于事件或日期。 在项目计划期间就要计划里程碑评审,并且通常是正式的评审。 进展评审与里程碑评审并不需要分别进行。一次评审可处理两种评审的内 容。例如,一次预先计划的评审可以对照计划中的期望值,评价某个计划 中的时间段(或里程碑)内的进展、问题与绩效。 根据项目的不同,“项目启动”与“项目结束”可能是里程碑评审包括的 阶段。 工作产品实例 1. 文档化的里程碑评审结果 子实践 1. 在项目进度中有重要意义的时刻,例如选定的阶段完成时,与相关干 系人一起进行里程碑评审。 酌情组织管理人员、员工、客户、最终用户、供方以及其他相关干系人 参与里程碑评审。 2. 评审项目的承诺、计划、状态以及风险。 3. 识别重大问题及其影响并将它们文档化。 4. 将评审的结果、行动项以及决策文档化。 5. 跟踪行动项直至关闭。 管理纠正措施直至关闭 当项目绩效或结果显著偏离计划时,纠正措施得到管理,直至关闭。 SP 2.1 分析问题 收集并分析问题,确定处理问题所需的纠正措施。 工作产品实例 1. 需要采取纠正措施的问题的清单 子实践 1. 收集问题以供分析。 228 项目监督与控制(PMC) CMMI 开发模型,版本 1.3 从评审和其它过程的执行中收集问题。 需要收集的问题的实例有: • 执行技术评审、验证与确认活动时发现的问题 • 项目计划参数与项目计划中的估算值的显著偏差 • 尚未满足的承诺(内部的和外部的) • 风险状态的重大变化 • 数据访问、收集、私有性或保密性等问题 • 干系人代表或参与方面的问题 • 产品、工具或环境交接的假设(或其他客户或供方承诺)未能达成 SP 2.2 2. 分析问题以决定是否需要纠正措施。 参阅“项目计划”过程域中的“建立预算与进度”特定实践以进一步 了解纠正措施准则。 如果问题不解决会妨碍项目达成其目标的话,就需要采取纠正措施。 采取纠正措施 对已识别的问题采取纠正措施。 工作产品实例 1. 纠正措施计划 子实践 1. 确定所需的适当措施并将其文档化,以处理已识别的问题。 参阅“项目计划”过程域以进一步了解如何制订项目计划。 可能的措施的实例有: • 修改工作说明书 • 修改需求 • 修订估算与计划 • 重新协商承诺 • 增加资源 • 修改过程 • 修订项目风险 2. 与相关干系人一同评审将要采取的措施并达成一致。 3. 协商内部与外部承诺的变更。 项目监督与控制(PMC) 229 CMMI 开发模型,版本 1.3 SP 2.3 管理纠正措施 管理纠正措施直至关闭。 工作产品实例 1. 纠正措施的结果 子实践 1. 监督纠正措施是否完成。 2. 分析纠正措施的结果以确定纠正措施的有效性。 3. 当纠正措施的实际结果与计划结果出现偏差时,确定适当的后继纠正 措施并将其文档化。 作为采取纠正措施的结果,相关的经验教训可被用作计划与风险管理过 程的输入。 230 项目监督与控制(PMC) CMMI 开发模型,版本 1.3 项目计划(PP) 成熟度 2 级项目管理类过程域 目的 简介 项目计划(Project Planning,PP)的目的在于建立并维护定义项目活动 的计划。 项目计划是有效管理项目的关键之一。项目计划过程域包含以下活动: • 制订项目计划 • 适当地与相关干系人配合 • 获得对计划的承诺 • 维护计划 计划工作包括估算工作产品与任务的属性,确定需要的资源,协商承诺, 安排进度以及识别并分析项目风险。为了建立项目计划,可能需要反复进 行这些活动。项目计划提供了执行并控制项目活动的基础,这些活动实现 了对项目客户的承诺。(见术语表中“项目”的定义。) 项目计划通常需要随着项目的进展而修订,以应对需求与承诺的变化、不 准确估算、纠正措施以及过程变更。本过程域同时包含了描述制订计划及 重新计划的特定实践。 本过程域中使用术语“项目计划”来表示用于控制项目的总体计划。项目 计划可以是单独的文档或分布在多份文档中。无论哪种情况,都应包括人 员工作分配的连贯视图。同样地,监督与控制也可以是集中或分散式的, 只要在项目层面上能维护着项目状态的连贯视图。 对于产品线,本过程域中的实践可以为多组工作活动提供帮助。这些工作 活动包括创建并维护核心资产、使用这些核心资产开发待构建的产品以及 周密地安排整个产品线的工作量来支持与协调内部关联的各工作组及其 活动的运作。 在敏捷环境下,执行增量式开发包括了比传统开发环境中更加频繁的计划、监 督、控制及重新计划。通常在建立了整个项目或者工作的高层计划后,团队一 次只对一个增量或迭代的工作进行估算、计划和执行。除了预先考虑风险、重 大事件、大范围的影响及限制外,团队一般不会对超出项目或者后续迭代的范 围进行预测。估算结果反映的是影响本迭代和团队特定的因素,包括完成本迭 代的时间、工作量、资源及风险。每一迭代期间,团队需要尽量及时地(例如 每天)进行计划、监督及调整计划活动。迭代计划过程中任务得到了分配与接 受,用户故事(user story)得到了详细说明或估算,从受到维护的工作清单 (backlog of work)中选出了每个迭代的任务——这一切证实了对计划的承诺。 (见第一部分中的“使用敏捷方法时对 CMMI 的解读”。) 项目计划(PP) 231 CMMI 开发模型,版本 1.3 相关过程域 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“技术解决方案”过程域以进一步了解如何选择、设计并实现对需求 的解决方案。 参阅“度量与分析”过程域以进一步了解如何明确说明度量项。 参阅“需求管理”过程域以进一步了解如何管理需求。 参阅“风险管理”过程域以进一步了解如何识别、分析并缓解风险。 232 项目计划(PP) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 建立估算 SP 1.1 估算项目范围 SP 1.2 建立对工作产品与任务属性的估算 SP 1.3 定义项目生命周期阶段 SP 1.4 估算工作量与成本 SG 2 制订项目计划 SP 2.1 建立预算与进度 SP 2.2 识别项目风险 SP 2.3 计划数据管理 SP 2.4 计划项目资源 SP 2.5 计划所需的知识与技能 SP 2.6 计划干系人的参与 SP 2.7 建立项目计划 SG 3 获得对计划的承诺 SP 3.1 评审影响项目的各项计划 SP 3.2 协调工作与资源水平 SP 3.3 获得对计划的承诺 按目标排列的特定实践 SG 1 建立估算 项目计划参数的估算得到建立与维护。 项目计划参数包括项目执行必要的计划、组织、人员配备、指导、协调、 报告以及预算等工作所需要的所有信息。 对计划参数的估算应该具备合理可靠的基础,使人们相信基于这些估算得 出的计划足以支持项目目标的达成。 估算这些参数时要考虑的因素包括项目需求——包含产品需求、组织提出 的需求、客户提出的需求等,以及影响项目的其它需求。 为了干系人的评审、对计划的承诺以及项目进展过程中对计划的维护,需 要将估算依据和支持数据文档化。 SP 1.1 估算项目范围 建立顶层的工作分解结构(work breakdown structure,WBS)以估 算项目范围。 WBS 与项目一同演进。顶层的 WBS 可以用来构建初始估算。通过 WBS 的开发,整个项目被划分为一组相互关联且可管理的组成部分。 WBS 通常以面向产品、工作产品或任务的方式为结构,提供一个原理框 架,从而识别并组织将要管理的工作逻辑单元,该工作逻辑单元被称为“工 作包(work package)”。WBS 为分配工作、进度与职责提供了参考和 组织机制,并被用作计划、组织与控制项目工作的基础框架。 有些项目会使用术语“合同 WBS”来表示被置入合同中的 WBS 部分(也 可能是整个 WBS)。并非所有的项目都会有合同 WBS(如公司内部出资 的开发项目)。 项目计划(PP) 233 CMMI 开发模型,版本 1.3 SP 1.2 工作产品实例 1. 任务描述 2. 工作包描述 3. WBS 子实践 1. 制订 WBS。 WBS 提供了项目工作的组织方案。WBS 应该有助于识别以下各项: • 风险及其缓解任务 • 产生交付物和支持活动的任务 • 获取技能与知识的任务 • 制订所需支持计划(例如配置管理计划、质量保证计划以及验证计划) 的任务 • 集成与管理非开发项的任务 2. 定义工作包,使其详细到能够明确说明对项目任务、职责和进度的估 算。 顶层 WBS 的目的是有助于针对任务和组织级角色与职责来估计项目的 工作量。该层次 WBS 的详细程度有助于制订更加切实可行的进度,从而 使管理储备减小到最低限度。 3. 识别将要从外部采购的产品及产品组件。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品 和服务的活动。 4. 识别将要复用的工作产品。 建立对工作产品与任务属性的估算 建立并维护工作产品与任务属性的估算。 规模是很多用于估算工作量、成本和进度的模型的首要输入。这些模型还 可能基于服务水平、连接性、复杂度、可用性以及结构等其它属性。 234 项目计划(PP) 项目计划(PP) CMMI 开发模型,版本 1.3 需估算的属性的实例有: • 需求的数量与复杂度 • 接口的数量与复杂度 • 数据量 • 功能数 • 功能点数 • 源代码行数 • 类与对象的数量 • 数据库表数量 • 数据表的字段数量 • 架构元素数量 • 项目参加者经验 • 复用与新建的代码量 • 团队开发速率(velocity)与复杂度 • 页数 • 输入与输出数量 • 技术风险数量 • 集成电路逻辑门数量 • 零件数量(例如印制电路板、组件与机械零件) • 物理限制(例如重量与容量) • 项目成员的地理分布 • 客户、最终用户和供方的合作关系 • 与客户相处的难易程度 • 现有代码库质量和“洁净”程度 估算应与项目需求一致,以确定项目的工作量、成本以及进度。对每个规 模属性,均应赋予一个相对的难度或者复杂度等级。 工作产品实例 1. 任务与工作产品的规模及复杂度 2. 估算模型 3. 属性估算值 4. 技术方法 子实践 1. 确定项目的技术方法。 技术方法定义了产品开发的顶层策略。它包括架构特性的决策:例如分 布式或客户端/服务器架构;采用最先进还是较成熟的技术,例如机器 人技术、复合材料或者人工智能;以及对最终产品的功能及质量属性的 期望,例如安全性、保密性以及人体工程学等。 2. 用适当的方法来确定将用于估算资源需求的工作产品与任务的属性。 确定规模与复杂度的方法,应以经过确认的模型或历史数据为基础。 对产品特性与属性的关系了解得越多,决定属性的方法也将随之逐渐增 多。 235 CMMI 开发模型,版本 1.3 3. 估算工作产品与任务的属性。 需要进行规模估算的工作产品的实例有: • 交付物与非交付的工作产品 • 文档与文件 • 操作与支持硬件、固件及软件 SP 1.3 SP 1.4 定义项目生命周期阶段 定义项目的生命周期阶段,以界定计划工作的范围。 项目生命周期阶段的确定,为计划的阶段评价与决策做准备。通常定义这 些阶段是为了支持逻辑上的决策点,在这些决策点决定对项目计划与策略 的持续信赖是否合适,并作出关于资源的重要承诺。这些决策点提供了事 先计划的事件,用以修正项目进程并确定后续的范围与成本。 理解项目生命周期,对于确定计划工作的范围、开始计划的时机以及重新 计划的时机与准则(关键里程碑)都是至关重要的。 项目生命周期阶段的定义,依赖于需求范围、对项目资源的估算以及项目 的性质。较大的项目可能包含多个阶段,诸如概念探索、开发、生产、运 行以及废弃。在这些阶段中,还可能需要子阶段。开发阶段可包含需求分 析、设计、制造、集成以及验证等子阶段。项目阶段的确定,通常包括对 一个或多个开发模型的选择及细化,以处理阶段内各活动间的相互关系及 适当的顺序。 根据开发策略,可能还有一些中间阶段用于原型创建、能力增量或者螺旋 模型周期等。此外还可以包含明确的“项目启动”及“项目结束”阶段。 工作产品实例 1. 项目生命周期阶段 估算工作量与成本 基于估算依据,估算工作产品与任务所需的项目工作量与成本。 对工作量与成本的估算,通常基于使用模型或历史数据对规模、活动以及 其它计划参数进行分析的结果。估算的置信度基于选定模型的依据及数据 的特性。有时会出现历史数据不适用的情况,例如工作没有先例可循或者 任务的类型与可用模型不适合。例如,如果组织没有这种产品或任务的经 验,该项工作就是没有先例可循的。 没有先例可循的工作通常风险更高,需要多做一些研究以建立合理的估算 基础,并需要更多的管理储备。使用这些模型时,项目的独特性应该得到 文档化,以保证在初始计划阶段所作出的任何假设都能得到共识。 工作产品实例 1. 估算依据 2. 项目工作量估算值 3. 项目成本估算值 子实践 1. 收集模型或历史数据,以用于将工作产品及任务的属性转换为工时及 成本的估算值。 236 项目计划(PP) CMMI 开发模型,版本 1.3 目前已有许多用于估算成本及进度的参数化模型。并不建议使用这些模 型作为估算的单一来源,因为他们所依据的历史项目数据,可能并不适 用于当前项目。可以使用多种模型与方法来确保更高的估算置信度。 历史数据应该包括以往执行的项目的成本、工作量及进度数据,以及考 虑规模及复杂度不同而进行适当调整后的数据。 2. 在估算工作量与成本时,应包含对支持性基础设施的需要。 支持性基础设施包括产品从开发到维持所需的全部资源。 在估算工作量与成本时,应考虑开发环境、测试环境、生产环境、操作 环境或上述环境的任何适当组合所需的基础设施资源。 基础设施资源的实例有: • 关键计算机资源(例如,内存、磁盘及网络容量、外设、通信信道, 这些资源的容量) • 工程环境及工具(例如, 原型、 测试、集成、编译、计算机辅助设 计[computer-aided design,CAD]、模拟等活动相关的工具) • 设施、机械及设备(例如,测试平台、记录装置) 3. 在估算工作量与成本时,使用模型、历史数据或者二者的组合。 项目计划(PP) 237 CMMI 开发模型,版本 1.3 通常工作量与成本估算的输入的实例有: • 专家或专家组提供的估算值(例如,德尔菲法[Delphi method]、 极限编程的计划游戏[Planning Game]) • 风险,包括该工作在多大程度上没有先例可循 • 执行工作所需的核心能力及关键角色 • 差旅 • WBS • 所选的项目生命周期模型及过程 • 生命周期成本估算 • 执行工作的管理人员及员工技能水平 • 所需的知识、技能及培训 • 直接人力及间接成本 • 呼叫中心及产品保修的服务协议 • 任务、工作产品、硬件、软件、人员及工作环境的安保水平 • 所需设施(例如办公室、会议室及工作站) • 产品及产品组件需求 • 工作产品、任务及预期变更的规模估算值 • 从外部采购产品的成本 • 制造过程的能力 • 所需的工程设施 • 工程环境下的工具能力 • 技术方法 SG 2 制订项目计划 项目计划得到建立与维护,以此作为管理项目的基础。 项目计划是用于管理和控制项目执行的经过批准的正式文件。它以项目需 求和已建立的估算为基础。 项目计划应考虑项目生命周期中的所有阶段。制订项目计划时应确保所有 影响项目的计划与整体项目计划一致。 SP 2.1 建立预算与进度 建立并维护项目的预算与进度。 项目的预算与进度以编制好的估算为基础,并确保预算分配、任务复杂度 以及任务依赖关系都得到适当的处理。 以事件为驱动、以资源为限制条件的进度已经被证明能够有效应对项目风 险。明确某个事件开始之前需要展示的成果,能够提供该事件在时间上的 灵活性、对预期成果的共识、更清晰的项目状态展望以及对项目任务更准 确的状态了解。 238 项目计划(PP) CMMI 开发模型,版本 1.3 工作产品实例 1. 项目进度 2. 进度依赖 3. 项目预算 子实践 1. 识别主要的里程碑。 里程碑是预先计划的事件或指定时间点,用来执行对项目状态的全面评 审,以便了解干系人需求的符合程度。(如果项目包含一个演进性的里 程碑,那么应执行评审以确保与该里程碑相关的假设及需求都已得到满 足。)里程碑可以与整体项目或一个特定的服务类型或实际服务相关。 里程碑可以基于事件或日期。如果基于日期,一旦就里程碑日期达成一 致,常常很难更改。 2. 识别进度的假设。 当开始编制进度表时,通常要对特定活动的工期作出假设。这些假设经 常针对估算数据较少甚至没有的事项做出。识别这些假设提供了对整个 进度的置信度(即:不确定性)的深刻理解。 3. 识别约束。 需要尽早识别出影响管理者选择的灵活性的限制因素。对工作产品和任 务属性的检查,常常可以揭示这些问题。这些属性可能包括任务工期、 资源、输入及输出。 4. 识别任务的依赖关系。 项目或服务的任务常常能够以某种工期最短的排序完成。这需要识别任 务之间的先后次序,并确定最优排序。 能够帮助确定任务活动的最佳排序的工具与输入的实例有: • 关键路径法(Critical Path Method,CPM) • 项目评价与评审技术(Program Evaluation and Review Technique,PERT) • 资源受限的进度编制 • 客户优先级 • 可市场化的特性 • 最终用户的价值 5. 建立并维护预算与进度。 项目计划(PP) 239 CMMI 开发模型,版本 1.3 建立并维护项目的预算与进度通常包括: • 定义资源及设施的已承诺或已预期的可用时段 • 确定活动的时间阶段 • 确定附属进度的分解 • 定义活动之间的依赖关系(前导或者后继关系) • 确定支持项目监督与控制的进度活动及里程碑 • 确定交付客户产品的里程碑、发布版本或增量 • 定义工期适当的活动 • 定义时间间隔适当的里程碑 • 根据满足进度与预算的信心程度,定义管理预留 • 利用适当的历史数据来验证进度 • 定义增量式的经费需求 • 记录项目的假设和依据 SP 2.2 6. 建立纠正措施准则。 建立确定何为明显偏离项目计划的准则。为了确定何时应该采取纠正措 施,需要建立估量各种问题和事项的基础。纠正措施可能要求重新计划 ——包括修订原计划和建立新协议,或者在当前计划中包含缓解措施。项 目计划定义何时(例如:何种情况下、以何种频率)由何人来应用这些 准则。 识别项目风险 识别并分析项目风险。 参阅“项目监督与控制”过程域中的“监督项目风险”特定实践以进一步 了解风险监督活动。 参阅“风险管理”过程域以进一步了解如何在项目潜在的问题发生前对其 进行识别,以便在整个产品或项目生命期中,计划并在必要时启动风险的 处理行动,从而降低这些潜在问题对达成目标产生的不利影响。 识别或者发现风险并且加以分析,以支持项目计划活动。本特定实践应该 扩展到所有影响项目的计划,以确保所有相关干系人在已识别的风险上适 当地协作。 项目计划工作中的风险识别与分析通常包括: • 识别风险 • 分析风险以确定其影响、发生的可能性以及可能发生问题的时间范围 • 划分风险优先级 工作产品实例 1. 已识别的风险 2. 风险影响及发生概率 3. 风险的优先级 240 项目计划(PP) CMMI 开发模型,版本 1.3 子实践 1. 识别风险。 风险的识别包括识别可能对工作和计划带来负面影响的潜在问题、危险、 威胁、弱点等。在对风险进行分析与适当的管理之前,应该识别并以易 于理解的方式描述风险。识别风险时,最好能采用定义风险的标准方法。 可以使用风险识别与分析工具,来帮助识别可能的问题。 风险识别与分析工具的实例有: • 风险分类法 • 风险评估 • 检查单 • 结构化访谈 • 头脑风暴 • 过程、项目及产品性能或绩效模型 • 成本模型 • 网络分析 • 质量因素分析 2. 将风险文档化。 3. 与相关干系人一起评审已文档化的风险,就其完整性与正确性达成一 致。 4. 适当地修订风险。 何时需要修订已识别风险的实例有: • 识别出新风险时 • 风险变成问题时 • 风险已经消失时 • 项目环境发生重大变化时 SP 2.3 计划数据管理 为项目数据的管理制订计划。 数据是在所有方面(例如管理、工程、配置管理、财务、后勤、质量、安 全、制造以及采购)支持项目所需要的文档形式。数据可能采用任何形式 (例如报告、手册、笔记、图表、图纸、规格说明、文件或者往来信函)。 数据可能存在于任何介质(例如不同材质的打印件或绘制件、照片、电子 存储或者多媒体)。 数据可能是交付物(例如项目的合同数据需求中标识出来的条目),也可 能是不需交付的(例如非正式的数据、权衡分析、分析资料、内部会议纪 要、内部设计评审文档、经验教训以及行动项)。数据的分发形式可以是 多种多样的,包括电子传递。 项目的数据要求,应当根据通用或标准的数据要求,从要创建的数据项及 其内容和格式两方面来建立。统一的数据项内容和格式要求,使数据内容 更容易理解,并有助于对数据来源进行一致的管理。 项目计划(PP) 241 CMMI 开发模型,版本 1.3 SP 2.4 收集每份文档的理由都应该很明确。这项任务包括分析与验证项目的交付 物及非交付物、数据要求以及客户提供的数据。数据往往是在其用途尚不 清楚的情况下就开始收集。收集数据的成本很高,应该只在需要时才去收 集。 工作产品实例 1. 数据管理计划 2. 受管理的数据总表 3. 数据内容及格式描述 4. 采购方与供方的数据需求清单 5. 私有性需求 6. 保密性需求 7. 保密性规程 8. 数据检索、复制和分发机制 9. 项目数据的收集进度 10. 需收集的项目数据清单 子实践 1. 建立保证数据的私有性和保密性的要求与规程。 并非每个人都有访问项目数据的需要或者权限。必须建立有关规程,以 确定何人能在何时访问何种数据。 2. 建立数据归档以及访问已归档数据的机制。 被访问的信息应该是易于理解的形式(例如来自数据库的电子或计算机 输出)或者以其初始产生时的形式表达。 3. 确定待识别、收集和分发的项目数据。 4. 确定对相关干系人进行访问授权或者数据分发的需求。 对项目计划中其他要素的评审,有助于确定何人需要访问或接受项目数 据以及需要哪些数据。 5. 确定对哪些项目数据及计划需要版本控制或其他级别的配置控制,并 且建立机制以确保项目数据受控。 计划项目资源 为执行项目所需的资源制订计划。 根据初始的估算结果,定义执行项目活动所需的项目资源和数量(例如人 工、设备、材料以及方法),并提供额外信息,以展开用于管理项目的 WBS。 早期作为估算机制所制订的顶层 WBS 常常会被展开为若干个代表单一工 作单元的工作包,工作包能够分别被分配、执行和跟踪。这种划分能够分 配管理职责,并提供更好的管理控制。 WBS 中的每个工作包都应该被赋予唯一的标识符(例如编号)以便跟踪。 WBS 可能基于需求、活动、工作产品、服务或者它们的组合。WBS 应附 有一份描述该工作分解结构中每项工作的字典。 242 项目计划(PP) CMMI 开发模型,版本 1.3 工作产品实例 1. 工作包 2. WBS 任务字典 3. 基于项目规模和范围的人员配备需求 4. 关键设施与设备清单 5. 过程及工作流的定义及图表 6. 项目行政管理需求清单 7. 状态报告 子实践 1. 确定过程需求。 必须会同所有相关干系人一起识别、定义和协商用于管理项目的过程, 以保证项目执行期间这些过程的有效运作。 2. 确定沟通需求。 这些需求说明了与客户、最终用户、项目成员以及其他相关干系人沟通 所使用的机制。 3. 确定人员配备需求。 项目的人员配备情况取决于为了实现项目需求将其分解成的任务、角 色和职责,分解方式与 WBS 中的工作包结构一致。 人员配备需求应该考虑到每个已识别的职位所需的知识与技能,正如 “计划所需的知识与技能”特定实践中定义的那样。 4. 确定设施、设备及组件需求。 大部分项目具备某些方面的独特性,并需要某些独特的资产来完成项目 目标。及时确定并获取这些资产对项目的成功至关重要。 最佳做法是尽早识别需要备货周期的事项,以决定应对方式。即使需要 的资产不是独特的,也应该编制一份所有设施、设备以及零件(例如项 目中人员使用的计算机数量、应用软件、办公空间等)的清单,从而深 入了解工作范围内某些经常被忽视的方面。 5. 确定其他持续性的资源需求。 除确定过程、报告模板、用人情况、设施以及设备之外,还有关于其它 类型资源的持续需要,以有效地实施项目的活动,包括: • 易耗品(例如:电力、办公用品) • 知识产权的使用权 • 运输设备的使用权(对人员及设备) 对于此类资源的需求从以下各项衍生而来:从(现有及未来的)协议(例 如:客户协议、服务协议、供方协议)中发现的需求、项目的战略手段 以及在一定时期内管理并维持项目运作的需要。 项目计划(PP) 243 CMMI 开发模型,版本 1.3 SP 2.5 计划所需的知识与技能 为执行项目所需的知识与技能制订计划。 参阅“组织级培训”过程域以进一步了解如何发展人员的技能与知识,使 其能够有效并高效地执行他们的角色。 对项目的知识传递包括对项目人员的培训以及从外部来源获取知识。 人员配备需求取决于当前可用于支持项目执行的知识与技能。 工作产品实例 1. 技能需要清单 2. 人员配备与雇佣计划 3. 数据库(例如技能与培训) 4. 培训计划 子实践 1. 识别执行项目所需的知识与技能。 2. 评估可用的知识与技能。 3. 选择提供所需知识与技能的机制。 机制的实例有: • 内部培训(组织级的和项目级的) • 外部培训 • 人员配备及雇佣 • 获取外部技能 SP 2.6 根据培训专家的可用性、项目进度以及业务目标来决定选择内部培训还 是外包培训获取所需的知识与技能。 4. 将选定的机制纳入项目计划。 计划干系人的参与 计划所识别干系人的参与。 通过识别项目中需要的人员类型和职能,并描述他们与特定的项目活动的 相关性和作用的程度,来确定项目生命周期中所有阶段的干系人。使用二 维矩阵对照表是完成识别工作的简便方法,两个维度的坐标轴分别表示干 系人和项目活动。在特定的项目阶段干系人与活动的相关关系以及预期的 参与程度,应该在项目阶段活动轴与干系人轴的交叉位置上标明。 为了使干系人的参与发挥作用,必须慎重地选择相关干系人。对于每项主 要活动,识别受到该活动影响的干系人及他们执行该活动所需的专业技能。 相关干系人列表应随着项目所处的生命周期阶段而变化。然而重要的是, 应保证生命周期后续阶段的相关干系人,能提前参与对他们有影响的需求 和设计决策。 244 项目计划(PP) CMMI 开发模型,版本 1.3 应该包含在干系人交互计划中的内容实例有: • 所有相关干系人的列表 • 干系人参与的依据 • 干系人之间的关系 • 保证干系人的交互所需的资源(例如培训、材料、时间、资金) • 干系人分阶段交互的时间安排 • 项目生命周期阶段中,相关干系人的角色与职责 • 项目生命周期阶段中,该干系人对项目成功的相对重要性 SP 2.7 本特定实践的实施依赖于前一项“计划所需的知识与技能”特定实践的共 享或交换信息。 工作产品实例 1. 干系人参与计划 建立项目计划 建立并维护整体项目计划。 描述了所有相关计划事项的文档化的计划,对实现执行或支持计划的个人、 小组以及组织之间的共同理解与承诺是必要的。 项目计划定义了项目工作的各个方面,以符合逻辑的方式说明以下各项: • 项目生命周期的考量 • 项目任务 • 预算及进度 • 里程碑 • 数据管理 • 风险识别 • 资源及技能需求 • 干系人的识别及交互 • 基础设施的考量 基础设施的考量应包括项目成员、管理人员和支持组织的职责与权限。 生命周期的考量应包括产品或服务后续阶段的覆盖(可能已经超出项目的 生命期),特别是移交至其他阶段或团体(例如:转移到制造、培训、运 营、服务提供商)。 软件的计划文档通常被称为下列之一: • 软件开发计划 • 软件项目计划 • 软件计划 对于硬件,计划文档通常被称为硬件开发计划。生产准备中的开发活动可以包 含在硬件开发计划里,也可以在独立的生产计划中定义。 项目计划(PP) 245 CMMI 开发模型,版本 1.3 SG 3 美国国防部相关团体使用的计划的实例有: • 集成的总体计划——事件驱动的计划,描述了项目的重要成果及其业务和 技术方面的通过/失败准则,并且将每项成果与关键的项目事件联系起 来。 • 集成的总体进度——集成化、网络化的多层次项目任务进度表,这些任务 是完成相关的“集成的总体计划”中描述的工作所需要的。 • 系统工程管理计划——详细描述项目中集成的技术工作的计划。 • 系统工程总体进度——事件驱动的进度安排,汇总了所有关键的技术成果, 每一项成果都要有可度量准则、要能成功的实现,以通过所识别的事件。 • 系统工程详细进度——详细的、基于时间、任务导向的进度安排,将特定 的日期和里程碑与“系统工程总体进度”联系起来。 工作产品实例 1. 总体的项目计划 获得对计划的承诺 对项目计划的承诺得到建立与维护。 计划需要得到负责实施和支持的人员的承诺才能生效。 SP 3.1 评审影响项目的各项计划 评审影响项目的所有计划,以理解项目的承诺。 其它过程域中制订的计划通常包含了与总体项目计划中需要的类似信息。 这些计划可以提供额外的详细指导,并且应该配合并支持总体项目计划, 以指明谁拥有权限、职责、义务以及控制。所有影响项目的计划都应该得 到评审,以确保它们对项目成功所需要的范围、目标、角色以及关系的共 同理解。这些计划中,很多是在“计划过程”通用实践中描述的。 工作产品实例 1. 对影响项目的各项计划的评审记录 SP 3.2 协调工作与资源水平 调整项目计划以协调可用的资源与估算的资源。 为了建立可行的项目,应获得相关干系人的承诺,并协调估算的和可用的 资源之间的差距。协调的方式通常包括:修订或推迟需求、协商以争取更 多的资源、发现提高生产率的方法、外包、调整人员的技能组合或者修订 所有影响项目的计划或进度。 工作产品实例 1. 修订的方法和对应的估算参数(例如更好的工具、现货组件的使用) 2. 重新协商后的预算 3. 修订后的进度 4. 修订后的需求列表 5. 重新协商后的干系人协议 246 项目计划(PP) CMMI 开发模型,版本 1.3 SP 3.3 获得对计划的承诺 从负责执行与支持计划实施的相关干系人处获得承诺。 获得承诺需要项目内外所有相关干系人的交互。作出承诺的个人或小组应 该有信心在成本、进度和绩效约束内完成工作。一个临时的承诺往往就足 以启动工作,并允许进行研究,从而将信心提升至适于获得全部承诺的程 度。 工作产品实例 1. 文档化的承诺请求 2. 文档化的承诺 子实践 1. 与相关干系人一起识别需要的支持并就承诺进行协商。 WBS 可以用作检查单,以确保为所有任务获得承诺。 对干系人交互的计划应该识别出需要作出承诺的所有当事人。 2. 将所有组织级的承诺(完整的以及临时的)文档化,并确保由适当级 别的人员签署。 承诺应该是文档化的,以确保相互间的一致理解以及项目的跟踪与维护。 临时的承诺应该附有与临时承诺关系相关的风险描述。 3. 适当时与高层管理人员一同评审内部承诺。 4. 适当时与高层管理人员一同评审外部承诺。 管理层应具备必要的洞察力和职权来降低与外部承诺相关的风险。 5. 识别关于项目元素与其它项目及组织级单位间接口的承诺,以便对其 进行监督。 明确的接口规格说明构成了承诺的基础。 项目计划(PP) 247 CMMI 开发模型,版本 1.3 248 项目计划(PP) CMMI 开发模型,版本 1.3 过程与产品质量保证(PPQA) 成熟度 2 级支持类过程域 目的 简介 过程与产品质量保证(Process and Product Quality Assurance,PPQA)的目的 在于向员工与管理层提供对过程及其相关工作产品的客观洞察。 “过程与产品质量保证”过程域涉及以下活动: • 对照适用的过程描述、标准与规程,客观评价已执行的过程与工作产 品 • 识别并记录不符合问题 • 向项目员工与管理人员提供对质量保证活动结果的反馈 • 确保不符合问题得到处理 过程与产品质量保证过程域在项目整个生命期,向项目员工与各层次的管 理人员提供对过程与相关工作产品适当的可视性及反馈,由此支持高质量 产品的交付。 过程与产品质量保证过程域的实践确保已计划的过程得到实施,而验证过 程域的实践则确保规定的需求得到满足。这两个过程域可能有时会从不同 的视角来处理同一个工作产品。项目应利用这种重叠,以在注意保持各自 视角的同时使重复工作降到最少。 过程与产品质量保证评价的客观性,是项目成功的关键(有关“客观评价” 的定义,详见术语)。客观性通过独立性与准则的使用两方面来达到。经 常使用的是一种组合方法,由不生产该工作产品的人对照准则提供评价。 较为不正式的方法可以覆盖广泛的日常活动。更正式的方法可以定期使用 以保证客观性。 执行客观评价方法的实例有: • 由组织级独立的质量保证组织进行的正式审计 • 可按照不同正式程度执行的同级评审 • 在工作地点的深入评审(即,桌面审计) • 工作产品的分布式评审与评论 • 嵌入过程中的过程检查,例如当过程执行不正确时的自动防故障装置(如, 防错法[Poka-Yoke]) 通常,客观性以独立于项目的质量保证组提供。但在某些组织中,实施过 程与产品质量保证角色以不具有这种独立性的方式进行,而这样的方式仍 可能是合适的。 例如,在具有开放、质量导向文化的组织中,过程与产品质量保证角色可以部 分或全部由同级担任,并且质量保证职能可以嵌入到过程中。对于小型组织, 这种嵌入式方法可能是最可行的方法。 过程与产品质量保证(PPQA) 249 CMMI 开发模型,版本 1.3 如果质量保证嵌入于过程中,应该处理几个问题以确保客观性。每个执行 质量保证活动的人应得到质量保证方面的培训。执行工作产品质量保证活 动的人应与直接参与开发或维护该工作产品的人分开。应该具有向组织级 管理层的适当级别独立报告的渠道,以便可以在必要时将不符合问题上报。 例如:当实施同级评审作为客观评价的方法时,应该处理以下问题: • 参加同级评审的人员得到培训并被分派了角色。 • 分派一个同级评审成员执行质量保证角色,他不是生产该工作产品的人。 • 具有基于过程描述、标准与规程的检查单,以支持质量保证活动。 • 作为同级评审报告的一部份,不符合问题得到记录,并且得到跟踪,必要 时上报到项目之外。 质量保证应开始于项目的早期阶段,以制定使项目增值并满足项目需求与 组织级方针的计划、过程、标准与规程。执行质量保证的人参与制定计划、 过程、标准与规程,以确保它们适合项目需要,并能用于执行质量保证评 价。另外,指定在项目期间将要评价的过程与相关工作产品。这种指定可 以基于与组织级方针、项目需求及项目需要相一致的采样或客观准则。 当识别出不符合问题时,首先尽可能在项目内处理并解决。不能在项目内 解决的不符合问题,上报到管理层的适当级别解决。 本过程域适用于项目活动与工作产品的评价,也适用于组织级(如,过程 组、组织级培训)活动与工作产品的评价。对于组织级活动与工作产品, 术语“项目”应加以适当解释。 在敏捷环境中,团队倾向于关注迭代的直接需要,而不是更长期与更广泛的组 织级需要。为确保认识客观评价的价值与效率,在早期讨论以下几点:(1) 客观评价将如何进行,(2)将评价哪些过程与工作产品,(3)评价结果将 如何集成到团队的节奏(例如,作为每日会议的一部分、检查单、同级评审、 工具、持续集成、回顾)。(见第一部分中的“使用敏捷方法时对 CMMI 的 解读”。) 相关过程域 参阅“验证”过程域以进一步了解如何确保选定的工作产品满足其规定的 需求。 250 过程与产品质量保证(PPQA) CMMI 开发模型,版本 1.3 SG 1 客观评价过程与工作产品 SP 1.1 客观评价过程 SP 1.2 客观评价工作产品 SG 2 提供客观洞察 SP 2.1 沟通并解决不符合问题 SP 2.2 建立记录 特定目标与特定实践摘要 按目标排列的特定实践 SG 1 客观评价过程与工作产品 所执行的过程及其相关的工作产品,对适用的过程描述、标准与规程的遵守程度, 得到客观评价。 SP 1.1 客观评价过程 对照适用的过程描述、标准与规程,客观评价所选择的已执行过程。 质量保证评价中的客观性是项目成功的关键。应当对质量保证报告链及其 如何确保客观性的描述给出定义。 工作产品实例 1. 评价报告 2. 不符合问题报告 3. 纠正措施 子实践 1. 提倡鼓励员工参与识别并报告质量问题的环境(作为项目管理的一部 分而创建的)。 2. 建立并维护描述清晰的评价准则。 本子实践的意图是基于业务需要提供准则,例如: • 将要评价什么 • 过程在什么时机或以何种频度得到评价 • 如何进行评价 • 谁必须参与评价 3. 使用所述准则,评价所选择的已执行的过程对过程描述、标准及规程 的遵守程度。 4. 识别在评价期间发现的每一个不符合问题。 5. 识别可能改进过程的经验教训。 过程与产品质量保证(PPQA) 251 CMMI 开发模型,版本 1.3 SG 2 SP 1.2 客观评价工作产品 对照适用的过程描述、标准与规程,客观评价所选择的工作产品。 工作产品实例 1. 评价报告 2. 不符合问题报告 3. 纠正措施 子实践 1. 若使用采样,则基于文档化的采样准则,选择要评价的工作产品。 工作产品可以包括由过程产生的服务,服务的接受者可以是项目或组织 的内部或外部。 2. 建立并维护描述清晰的对所选择的工作产品评价的准则。 本子实践的意图是基于业务需要提供准则,例如: • 在工作产品评价期间,将要评价什么 • 工作产品在什么时机或以何种频度得到评价 • 如何进行评价 • 谁必须参与评价 3. 在评价所选择的工作产品期间,使用所述准则。 4. 在选定的时机评价所选择的工作产品。 对照过程描述、标准或规程,评价工作产品时机的实例有: • 在交付给客户前 • 在向客户交付期间 • 在适当的时候采用增量式地评价 • 单元测试期间 • 集成期间 • 当演示一个增量时 5. 识别在评价期间发现的每一个不符合案例。 6. 识别可能改进过程的经验教训。 提供客观洞察 不符合问题得到客观的跟踪与沟通,并确保得到解决。 SP 2.1 沟通并解决不符合问题 与员工和管理人员沟通质量问题,并确保不符合问题的解决。 不符合问题是在评价中所识别的问题,它们反映对适用的标准、过程说明 或规程的遵守程度不足。不符合问题的状态提供质量趋势的指示。质量问 题包括不符合问题与趋势分析结果。 当不符合问题在项目内不能解决时,使用已建立的上报机制,以确保适当 级别的管理层能解决该问题。跟踪不符合问题直到解决。 252 过程与产品质量保证(PPQA) CMMI 开发模型,版本 1.3 工作产品实例 1. 纠正措施报告 2. 评价报告 3. 质量趋势 子实践 1. 如果可能,与合适的员工一起解决每个不符合问题。 2. 当不符合问题在项目内不能解决时,将其文档化。 项目内解决不符合问题的方法的实例有: • 修正不符合问题 • 变更所违反的过程描述、标准或规程 • 获得豁免以放行不符合问题 SP 2.2 3. 将不能在项目内解决的不符合问题,上报到适当级别的、被指定接收 不符合问题并就其采取行动的管理层。 4. 分析不符合问题,看是否有可被识别并处理的质量趋势。 5. 确保相关干系人及时知道评价结果与质量趋势。 6. 与指定接收不符合问题并就其采取行动的管理人员一起,定期评审尚 待解决的不符合问题与趋势。 7. 跟踪不符合问题直到解决。 建立记录 建立并维护质量保证活动的记录。 工作产品实例 1. 评价日志 2. 质量保证报告 3. 纠正措施的状态报告 4. 质量趋势报告 子实践 1. 足够详细地记录过程与产品质量保证活动,以了解状态与结果。 2. 必要时,修订质量保证活动的状态与历史记录。 过程与产品质量保证(PPQA) 253 CMMI 开发模型,版本 1.3 254 过程与产品质量保证(PPQA) CMMI 开发模型,版本 1.3 量化项目管理(QPM) 成熟度 4 级项目管理类过程域 目的 简介 量化项目管理(Quantitative Project Management,QPM)的目的在于量 化地管理项目,以达成项目已建立的质量与过程性能目标。 “量化项目管理”过程域涉及以下活动: • 建立并维护项目的质量与过程性能目标 • 组成项目已定义的过程以帮助达成项目的质量与过程性能目标 • 选择对理解性能起关键作用并有助于达成项目质量与过程性能目标的 子过程与属性 • 选择将用于量化管理的度量项与分析技术 • 使用统计与其它量化技术来监督所选子过程的性能 • 使用统计与其它量化技术管理项目,以确定项目的质量与过程性能目 标是否正在得到满足 • 对所选定的问题执行根本原因分析,以解决在达成项目质量与过程性 能目标上的不足 通过使用组织级过程性能过程,建立用于实现高成熟度的组织级过程资产, 包括质量与过程性能目标、所选过程、度量项、基线以及模型,并用于量 化项目管理过程。在必要时,项目可以使用组织级过程性能的过程来定义 附加的目标、度量项、基线及模型,以有效地分析并管理性能。将量化项 目管理过程所产生的度量项、度量及其它数据纳入组织级过程资产。通过 这种方式,组织与项目通过使用改进后的资产而从中受益。 项目已定义的过程是一个相互关联的子过程集合,其构成项目的一个集成 而且一致的过程。“集成项目管理”实践描述了通过从组织的标准过程集 中选择与裁剪过程,来建立项目已定义的过程。(见术语表中“已定义的 过程”的定义。) 与“集成项目管理”实践不同,“量化项目管理”实践有助于形成对于过 程或者子过程所期望性能的量化理解。通过为项目评价备选过程或子过程, 并选择那些最可能达成质量与性能目标的过程或子过程,这种量化理解被 用作建立项目已定义过程的基础。 与供方建立有效的关系对于成功地实施本过程域也至关重要。建立有效的 关系包括为供方建立质量与过程性能目标,确定用于深入了解供方的进展 及绩效的度量项与分析技术,并监督达成那些目标的进展。 量化管理的一个基本要素是对预测有信心(即,能够准确地预测项目在多 大程度上满足其质量与过程性能目标的能力)。基于对可预测过程性能的 需要,选择将使用统计与其它量化技术管理的子过程。 另一个量化管理的基本要素是理解在过程性能中遇到的偏差本质和程度, 并且察觉项目的实际绩效何时可能不足以达成项目的质量与过程性能目 标。 量化项目管理(QPM) 255 CMMI 开发模型,版本 1.3 因此,量化管理包括统计思维方式与各种统计技术的正确使用。(见术语 表中“量化管理”的定义。) 统计与其它量化管理技术用于开发对过程的实际性能的理解,或者预测过 程的性能。这些技术可用于多个层面,从对单个子过程的关注到对跨生命 周期阶段、项目以及支持职能的分析。非统计技术提供了不够严格但依然 有用的方法集,它与统计技术一起帮助项目理解是否质量与过程性能目标 正在得到满足,并识别任何需要的纠正措施。 本过程域适用于管理项目。应用这些概念来管理其他组与职能有助于将组 织绩效的不同方面关联起来,从而提供一个基础,来平衡并协调存在竞争 的优先级关系,以应对更广泛的业务目标集合。 从本过程域的使用中可能获得收益的其他组与职能的实例有: • 质量保证或者质量控制职能 • 过程定义与改进 • 内部研究与开发职能 • 风险识别与管理职能 • 技术探索职能 • 市场研究 • 客户满意度评估 • 问题跟踪与报告 相关的过程域 参阅“原因分析与解决”过程域以进一步了解如何识别所选结果的原因并 采取行动,以改进过程性能。 参阅“集成项目管理”过程域以进一步了解如何建立项目已定义的过程。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 参阅“组织级绩效管理”过程域以进一步了解如何主动地管理组织的绩效 以满足其业务目标。 参阅“组织级过程性能”过程域以进一步了解如何建立并维护对组织标准 过程集中所选定过程性能的量化理解,以支持达成质量与过程性能目标, 并提供过程性能数据、基线与模型,以量化管理组织的项目。 参阅“项目监督与控制”过程域以进一步了解如何提供对项目进展的了解, 以在项目绩效显著偏离计划时采取适当的纠正措施。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和服 务的活动。 256 量化项目管理(QPM) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 准备量化管理 SP 1.1 建立项目的目标 SP 1.2 组成已定义的过程 SP 1.3 选择子过程与属性 SP 1.4 选择度量项与分析技术 SG 2 量化地管理项目 SP 2.1 监督所选定子过程的性能 SP 2.2 管理项目绩效 SP 2.3 执行根本原因分析 按目标排列的特定实践 SG 1 准备量化管理 量化管理的准备工作得以进行。 准备活动包括建立项目的量化目标,组成有助于达成那些目标的项目已定 义过程,选择对理解性能及达成目标起关键作用的子过程与属性,并选择 支持量化管理的度量项与分析技术。 当需要与优先级发生变更时,当对过程性能有更好的理解时,或作为风险 缓解或纠正措施的一部分时,这些活动可能需要重复进行。 SP 1.1 建立项目的目标 建立并维护项目的质量与过程性能目标。 当建立项目质量与过程性能目标时,要考虑项目已定义过程中会包括的过 程,并考虑历史数据对这些过程的性能具有何种意义。这些考虑连同技术 能力等其它方面一起,可以有助于项目建立现实的目标。 在适当的细节层次建立并协商项目的质量与过程性能目标(例如,单个产 品组件、子过程、项目团队等),以允许在项目级对目标与风险的整体评 价。随着项目进展,当对项目的实际绩效获得了解、并且更加可预测时, 就可以更新项目目标,以反映相关干系人变化的需要与优先级。 工作产品实例 1. 项目的质量与过程性能目标 2. 对不能达成项目目标的风险所进行的评估 子实践 1. 评审组织的质量与过程性能目标。 该评审确保项目成员理解项目运行的更广范业务环境。项目的质量与过 程性能目标是在这些总体组织级目标的环境中制订出来的。 参阅“组织级过程性能”过程域以进一步了解如何建立质量与过程性能 目标。 2. 识别客户、供方、最终用户及其他相关干系人的质量与过程性能需要 及优先级。 典型情况下,对相关干系人需要的识别会在早期就已开始(例如,在工 作说明书的开发期间)。在需求开发期间,进一步挖掘、分析、提炼、 划分优先级以及平衡这些需要。 量化项目管理(QPM) 257 CMMI 开发模型,版本 1.3 可能要为其识别需要与优先级的质量与过程性能属性的实例有: • 周期 • 可预测性 • 可靠性 • 可维护性 • 可使用性 • 及时性 • 功能 • 准确性 3. 定义并文档化项目可度量的质量与过程性能目标。 定义并文档化项目的目标涉及以下方面: • 纳入合适的组织级质量与过程性能目标 • 编写反映质量与过程性能需要的目标,以及客户、最终用户及其他相 关干系人的优先级 • 确定将如何达成每个目标 • 评审这些目标以确保它们是足够明确的、可度量的、可达到的、相关 的以及有时限性的 可度量的质量属性的实例有: • 平均故障间隔时间 • 在已发布产品中的缺陷的数量及严重程度 • 关键资源使用率 • 对已提供服务的客户投诉数量及严重程度 可度量的过程性能属性的实例有: • 周期时间 • 返工时间的百分比 • 产品验证活动中已移除缺陷的百分比(可能按照验证的类型进行区 分,例如同级评审与测试) • 缺陷逃逸率 • 在产品交付(或者服务开始)后第一年内发现的缺陷(或者已报告的 事件)数量及严重程度 258 量化项目管理(QPM) CMMI 开发模型,版本 1.3 项目质量与过程性能目标的实例有: • 保持变更请求工作清单规模在一个目标值之下。 • 在目标日期以前,在敏捷环境下将速度提升到一个目标值。 • 在目标日期以前,将空闲时间降低一定的百分比。 • 将进度延误保持在一个规定的百分比以下。 • 在目标日期以前,将总生命周期成本减少规定的百分比。 • 在不影响成本情况下,将交付给客户的产品中缺陷减少 10%。 4. 衍生中期目标,以监督达成项目目标的进展。 可以针对所选生命周期阶段、里程碑、工作产品以及子过程的属性建立 中期目标。 由于过程性能模型描述了产品与过程属性之间的关系特征,因此这些模 型可以用来帮助衍生出指导项目达成其目标的中期目标。 5. 确定不能达成项目的质量与过程性能目标的风险。 风险是已建立的目标、产品架构、项目已定义的过程、所需的知识与技 能的可用性等因素的函数。过程性能基线与模型可以用来评价达成一系 列目标的可能性,以及提供协商目标与承诺的指导。这些风险的评估可 以包括各种项目干系人,并且可以作为下一子实践中所描述的冲突解决 部分来执行。 6. 解决项目的质量与过程性能目标间的冲突(例如,如果不在一个目标 上妥协,另一个目标就不能达成)。 过程性能模型可以帮助识别冲突,并有助于确保在不引入新的冲突或者 风险的情况下解决冲突。 解决冲突包括以下活动: • 为目标设置相对优先级 • 根据长期的业务策略以及短期需要,考虑备选目标 • 让客户、最终用户、高层管理人员、项目管理人员及其他相关干系人 参与权衡决策 • 必要时修订目标以反映冲突解决的结果 7. 建立项目的质量与过程性能目标与其来源的可追溯性。 目标来源的实例有: • 需求 • 组织的质量与过程性能目标 • 客户的质量与过程性能目标 • 业务目标 • 与客户及潜在客户的讨论 • 市场调查 • 产品架构 量化项目管理(QPM) 259 CMMI 开发模型,版本 1.3 识别并追溯这些需要与优先级方法的一个实例是质量功能展开(Quality Function Deployment,QFD)。 SP 1.2 8. 定义并协商供方的质量与过程性能目标。 9. 必要时修订项目的质量与过程性能目标。 组成已定义的过程 使用统计与其它量化技术,组成使项目能够达成其质量与过程性能目 标的已定义过程。 参阅“集成项目管理”过程域以进一步了解如何建立项目已定义的过程。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 参阅“组织级过程性能”过程域以进一步了解如何建立过程性能基线与模 型。 组成项目已定义过程超出了在“集成项目管理”过程域中描述的过程选择 与裁剪。它包括识别一个或多个过程或子过程的备选过程,执行性能的量 化分析以及选择最能帮助项目达成其质量与过程性能目标的备选方案。 工作产品实例 1. 用于评价项目备选方案的准则 2. 备选子过程 3. 将包括在项目已定义过程中的子过程 4. 对不能达成项目目标的风险评估 子实践 1. 建立用于评价项目备选过程的准则。 准则可以基于以下内容: • 质量与过程性能目标 • 过程性能数据的可用性以及评价备选过程的数据的相关性 • 对不能达成项目目标的风险进行评估 • 存在可用于评价备选过程的过程性能模型 • 产品线标准 • 项目生命周期模型 • 干系人需求 • 法律与法规 2. 识别项目的备选过程与子过程。 识别备选过程可以包括如下一个或多个活动: • 分析组织级的过程性能基线以识别有助于达成项目的质量与过程性 能目标的候选子过程 • 从组织的标准过程集以及在过程资产库已裁剪的过程中识别有助于 达成目标的子过程 • 从外部来源中识别过程(例如,其他组织、专业会议、学术研究等) 260 量化项目管理(QPM) CMMI 开发模型,版本 1.3 SP 1.3 • 调整所应用的子过程级别或者强度(进一步详细的描述见接下来的子 实践) 调整所应用的子过程级别或者强度包括如下选择: • 将要进行同级评审的数量、类型与时间 • 用于特定任务的工作量或日历时间 • 参与人的数量与选择 • 执行特定任务的技能水平需求 • 专业化构造或验证技术的选择性应用 • 复用决策与相关风险缓解策略 • 将被度量的产品与过程属性 • 管理数据的采样率 参阅“集成项目管理”过程域以进一步了解如何使用组织级过程资产来 计划项目活动。 3. 分析备选子过程的相互作用以理解子过程之间的关系,包括它们的属 性。 分析这种相互作用可以深入理解特定备选方案的强项与弱项。可通过具 有过程性能数据的组织级过程性能模型的校准来支持此分析(例如,在 过程性能基线中描述的特征)。 如果现有的过程性能模型不能处理在考虑之中的备选子过程之间的重要 关系,并存在不能达成目标的高风险,则需要追加建模。 4. 对照准则评价备选子过程。 在适当的时候,使用历史数据、过程性能基线以及过程性能模型,以帮 助对照准则评价备选子过程。特别是在高风险情况下,这些评价可能包 括使用敏感性分析。 参阅“决策分析与解决”过程域以进一步了解如何评价备选方案。 5. 选择最能满足准则的备选子过程。 在对已经识别出最可用的备选方案获得信心之前,可能有必要反复执行 几次前面的子实践所描述的活动。 6. 评价不能达成项目的质量与过程性能目标的风险。 对于选定的备选已定义过程的相关风险的分析可能导致识别出需要被评 价的新备选方案,以及需要更多管理人员关注的领域。 参阅“风险管理”过程域以进一步了解如何识别并分析风险。 选择子过程与属性 选择对评价性能起关键作用,并有助于达成项目质量与过程性能目标 的子过程与属性。 一些子过程之所以关键是因为它们的性能显著地影响或有助于项目目标 的达成。正如在第二个特定目标的第一个特定实践所描述,这些子过程可 能是使用统计与其它量化技术进行监督并控制合适的候选。 同样,这些子过程的一些属性可以充当下游子过程期望的过程性能的先导 指示器,也可以用来评估不能达成项目目标的风险(例如,通过使用过程 性能模型)。 量化项目管理(QPM) 261 CMMI 开发模型,版本 1.3 扮演如此关键角色的子过程与属性可能作为上一个特定实践所描述的分 析的一部分已经被识别出来。 对于小项目,以及项目可能无法足够频繁地生成子过程数据来支持充分灵 敏的统计推断的场合,通过在多个相似的迭代、团队或项目间对性能的考 查,仍然有可能形成对性能的理解。 工作产品实例 1. 用于选择达成项目目标的关键子过程的准则 2. 所选择的子过程 3. 有助于预测未来项目绩效的所选子过程的属性 子实践 1. 分析子过程、其属性、其它因素以及项目绩效结果之间的相互关系。 根本原因分析、敏感性分析或过程性能模型可以帮助识别子过程及其属 性,这些子过程及其属性对特定性能结果的达成(以及性能结果的偏差) 贡献最大,或者对将来达成性能结果来说是有用的指示器。 参阅“原因分析与解决”过程域以进一步了解如何确定所选结果的原因。 2. 识别用于选择对达成项目质量与过程性能目标有关键贡献的子过程 的准则。 用于选择子过程的准则的实例有: • 与应对项目目标的绩效结果具有强相关性。 • 子过程的性能稳定具备重要性。 • 子过程性能不良与项目的重大风险相关联。 • 一个或多个子过程的属性充当项目所用过程性能模型的关键输入。 • 子过程将以足够高的频率执行,为分析提供充分的数据。 3. 使用已识别的准则选择子过程。 历史数据、过程性能模型与过程性能基线有助于对照选择准则评价候选 子过程。 参阅“决策分析与解决”过程域以进一步了解如何评价备选方案。 4. 识别将被监控的产品与过程属性。 这些属性可能作为执行前面的子实践的一部分已经得到识别。 不论关联子过程在项目中是否已受控,对当前或未来子过程提供深入理 解的属性都可以成为监督的候选。同时,一些相同的属性可能起到其它 作用,(例如,在“项目监督与控制[PMC]”中所描述的有助于监督 项目进展与绩效的属性)。 262 量化项目管理(QPM) CMMI 开发模型,版本 1.3 产品与过程属性的实例有: • 执行子过程所花费的工作量 • 子过程执行的速度 • 组成子过程的过程元素的周期时间 • 作为子过程的输入的、所消耗的资源或材料 • 执行子过程的员工的技能等级 • 用于执行子过程的工作环境的质量 • 子过程输出量(例如,中间工作产品) • 子过程输出的质量属性(例如,可靠性,可测试性) SP 1.4 选择度量项与分析技术 选择将用于量化管理的度量项与分析技术。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 工作产品实例 1. 在量化管理中使用的度量项与分析技术的定义 2. 度量项与项目的质量与过程性能目标的可追溯性 3. 所选子过程与其属性的质量与过程性能目标 4. 由项目所使用的过程性能基线与模型 子实践 1. 从支持量化管理的组织级过程资产中识别公共度量项。 参阅“组织级过程定义”过程域以进一步了解如何建立组织级过程资产。 参阅“组织级过程性能”过程域以进一步了解如何建立性能基线与模型。 产品线或其它分层准则可以将公共度量项加以分类。 2. 识别可能需要的附加度量项,以覆盖所选子过程的关键产品与过程属 性。 在某些情况中,度量项可能仅供研究使用。应该对这样的度量项进行明 确的标识。 3. 识别用于管理子过程的度量项。 当选择度量项的时候,要记住如下考虑: • 从多个来源(例如,不同的过程、输入源、环境)或随时间(例如, 在某个阶段层面)将数据聚合在一起的度量项,可能掩盖潜在的问题, 使问题识别与解决变得困难。 • 对于短期的项目,在继续使用非聚合的数据支持单个项目的同时,可 能有必要从一个过程的多个相似实例中聚合数据使其过程性能分析 成为可能。 • 选择不应该仅限于进展或性能度量项。“分析度量项”(例如,审查 准备率、员工技术水平、测试中的路径覆盖度)可能对过程性能提供 更深入的了解。 量化项目管理(QPM) 263 CMMI 开发模型,版本 1.3 4. 明确说明度量项的操作定义、在子过程中的采集点以及怎样确定度量 项的完整性。 5. 分析所识别度量项相对于项目质量与过程性能目标的关系,并衍生出 子过程的质量与过程性能目标,这些目标说明了各选定子过程中各度 量属性的既定指标(例如,阈值、范围)。 衍生的子过程质量与过程性能目标的实例有: • 保持代码评审速率在每小时 75 至 100 行代码 • 保持需求收集会议在三小时以内 • 将测试速率保持在每天执行的测试用例大于一个规定的数量 • 保持返工水平在规定的百分比以下 • 保持每天生成用例的生产率 • 保持设计复杂度(扇出率)在规定的阈值以下 6. 识别将要在量化管理过程中使用的统计与其它量化技术。 在量化管理中,使用统计与其它量化技术对所选子过程的过程性能进行 分析,这些技术有助于描述子过程偏差的特征、识别统计上非预期行为 表现的发生时间、识别何时偏差过度,并调查原因。用于过程性能分析 的统计技术的实例包括统计过程控制图、回归分析、方差分析以及时间 序列分析。 对未被选定的那些子过程的性能在项目绩效方面的影响进行分析,可能 会使项目受益。同样可以识别统计与其它量化技术来处理这些子过程。 有时统计与其它量化技术涉及图形显示的使用,这有助于将数据与分析 结果之间的联系可视化。这些图形显示可以有助于将一段时间的过程性 能与偏差(即,趋势)可视化,识别问题或机会,并评价特定因素的影 响。 图形显示的实例有: • 散点图 • 直方图 • 箱线图 • 运行图 • 石川图 其它用来分析过程性能的技术实例有: • 计数单 • 分类法(例如,正交缺陷分类法) 7. 确定需要哪些过程性能基线与模型以支持所识别的分析。 在某些情况下,按照“组织级过程性能”过程域中描述的方式所提供的 基线与模型的集合,可能并不能充分支持量化项目管理。在项目的目标、 过程、干系人、技能水平或环境与当初建立基线与模型时所针对的其他 项目不同的时候,这样的情况可能发生。 264 量化项目管理(QPM) CMMI 开发模型,版本 1.3 SG 2 随着项目的进展,来自该项目的数据可以充当更具代表性的数据集,以 建立缺少的或项目特定的过程性能基线与模型集。 用假设检验的方法将项目数据与以前的历史数据相比较可以确认是否需 要额外建立项目特定的基线与模型。 8. 搭建组织级或者项目支持环境以支持度量项的收集、衍生与分析。 这样的环境搭建在以下的基础上进行: • 组织的标准过程集的描述 • 项目已定义过程的描述 • 组织级或项目支持环境的能力 9. 必要时修订度量项与统计分析技术。 量化地管理项目 项目得到量化管理。 量化管理项目涉及使用统计与其它量化技术执行以下活动: • 使用统计与其它的量化技术监督所选子过程 • 确定项目的质量与过程性能目标是否正在得到满足 • 对所选问题执行根本原因分析以解决不足 SP 2.1 监督所选定子过程的性能 使用统计与其它量化技术来监督所选定子过程的性能。 本特定实践的意图是使用统计与其它量化技术以分析子过程性能中的偏 差,并确定对于达成各子过程的质量与过程性能目标所必要的措施。 工作产品实例 1. 各所选子过程属性的过程性能的自然边界 2. 解决各所选子过程的过程稳定性或者能力中的不足所需的措施 子实践 1. 依照所选度量项定义,随着子过程的执行收集数据。 2. 监督所选子过程的偏差与稳定性并解决不足。 此项分析包括对度量数据进行评价,评价时对比为各选定度量项计算的 自然边界,此分析还包括识别异常或者其它潜在非随机行为的信号,确 定它们的原因,以及防止或者缓解它们再发生的影响(例如,处理偏差 的特殊原因)。 在进行这样的分析时,要敏锐洞察数据是否充足,并敏锐洞察会影响到 过程稳定性的达成与保持的过程性能偏移。 识别异常或者信号的分析技术包括统计过程控制图、预测区间及方差分 析,其中一些技术涉及图形显示。 其它可考虑在过程性能方面存在不足的情况有:当偏差过大,以至于不 能确信子过程是否稳定时;或者当偏差过于巨大,以至于不能评估其能 力(下一子实践),以达成为各选定子过程所建立的目标时。 3. 监督所选子过程的能力与性能,并解决不足。 量化项目管理(QPM) 265 CMMI 开发模型,版本 1.3 本子实践的意图是识别将要采取什么行动以有助于子过程达成其质量与 过程性能目标。在对其能力与其质量与过程性能目标进行比较之前,要 确保子过程性能相对所选度量项是稳定的(上一子实践)。 当所选子过程的性能不能满足其目标时可能采取行动的实例有: • 改进现有子过程的实施以减少其偏差或者改进其性能(例如,解决偏 差的共同原因) • 通过识别与采用可能更有助于与目标协调一致的新过程元素、子过程 以及技术,识别与实施备选子过程 • 为子过程中的每个不足识别风险与风险缓解策略 • 为子过程各选定属性重新协商或者重新衍生目标,以便子过程能够满 足这些目标 SP 2.2 一些行动可能包括根本原因分析的使用,在 SP 2.3 中有这方面进一步的 描述。 参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施直至关 闭。 管理项目绩效 使用统计与其它量化技术管理项目,以确定项目的质量与过程性能目 标是否会得到满足。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 参阅“组织级绩效管理”过程域以进一步了解如何管理业务绩效。 本特定实践关注于项目,并且使用多个输入以预测是否项目的质量与过程 性能目标将会得到满足。基于此预测,识别并管理未满足项目的质量与过 程性能目标的相关风险,以及适当定义解决不足的行动。 该分析的关键输入包括来源于上一个特定实践的单个子过程的稳定性与 能力数据,以及来自于监督其它子过程、风险与供方进展的性能数据。 工作产品实例 1. 对与项目的质量与过程性能目标相关的、将要达成结果的预测 2. 支持量化管理的其它子过程的图形显示与数据表格 3. 不能达成项目的质量与过程性能目标的风险评估 4. 解决在达成项目目标方面的不足的所需行动 子实践 1. 定期评审子过程的性能。 由 SP 2.1 所描述的监督所选子过程,在其执行中得到的稳定性与能力数 据,对理解项目满足质量与过程性能目标的整体能力来说是一个关键输 入。 另外,因其对项目的影响程度而未被选择的子过程依然可能给项目造成 问题或风险。因此,也同样期望在一定程度上对这些子过程进行监督。 使用图形显示的分析技术对理解子过程性能来说也可能证明是有用的。 2. 监督与分析供方在达成其质量与过程性能目标方面的进展。 3. 对照已建立的中期目标,定期地评审与分析已达成的实际结果。 266 量化项目管理(QPM) CMMI 开发模型,版本 1.3 4. 使用以项目数据校准过的过程性能模型,评估达成项目质量与过程性 能目标方面的进展。 过程性能模型用于评估达成目标的进展,这些目标直到项目生命周期的 未来阶段才可度量。目标可以是中期目标或者总体目标。 一个过程性能模型使用的实例是预测在未来阶段的工作产品中或者已发 布产品中的潜在缺陷。 过程性能模型的校准是基于之前的子实践与特定实践中所描述活动的执 行结果。 5. 识别并管理与达成项目的质量与过程性能目标相关联的风险。 参阅“风险管理”过程域以进一步了解如何识别与分析风险,并缓解风 险。 风险来源的实例有: • 子过程的性能或能力不足 • 供方没有实现其质量与过程性能目标 • 缺乏对供方能力的可视度 • 用于预测性能的过程性能模型不准确 • 所预测的过程性能存在不足(估算的进展) • 与所识别的不足相关联的其它已识别的风险 6. 确定并实施必要措施以解决在达成项目质量与过程性能目标中存在 的不足。 本子实践的意图是识别并实施一套正确的行动、资源以及进度表,以使 得项目回归到通往达成其目标的轨道上。 在达成项目目标中,为解决不足可能采取的行动实例有: • 变更质量与过程性能目标以使其落在项目已定义的过程所期望的范 围之内 • 改进项目已定义过程的实施 • 采用有可能满足目标并管理关联风险的新子过程与技术 • 识别因为不足带来的风险以及风险缓解策略 • 终止项目 一些行动可能涉及使用根本原因分析,这将在下一特定实践中讨论。 参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施直至关 闭。 当纠正措施引起过程性能模型中可调因子的相关属性或者度量项变化时, 该模型就可以用来预测此措施的效果。当在高风险情况中采取关键的纠 正措施时,可以建立过程性能模型以预测此变化产生的影响。 量化项目管理(QPM) 267 CMMI 开发模型,版本 1.3 SP 2.3 执行根本原因分析 对所选定的问题执行根本原因分析,以解决在达成项目质量与过程性 能目标上的不足。 待解决的问题包括在子过程稳定性与能力方面的不足,以及项目绩效与其 目标相比存在的不足。 对所选问题的根本原因分析最好在问题的初次识别后立即进行,此时该事 件刚刚发生,能够进行仔细的调查。 根本原因分析的正式程度与所需的工作量可能有很大不同,并且取决于一 些因素,如参与的相关干系人;呈现出的风险与机会;情况的复杂度;情 况可能再度发生的频度;可用于分析的数据、基线以及模型的可用性;引 发稳定性与能力不足的事件发生后已经过去了多少时间等。 如果子过程呈现出太多偏差,几乎很少得到执行,并且涉及到不同干系人, 根本原因的识别就可能需要几周或几个月的时间。 同样,在确定、计划及执行将要采取的行动时,所需工作量与时间可能变 化很大。 除非对不足进行初始分析,否则很难知道需要多长时间。 参阅“原因分析与解决”过程域以进一步了解如何识别所选结果的原因并 采取行动,以改进过程性能。 参阅“度量与分析”过程域以进一步了解如何使度量与分析活动协调一致 并提供度量结果。 工作产品实例 1. 记录在组织的度量库中的子过程和项目绩效方面的度量与分析(包括 统计分析) 2. 用于理解子过程性能与项目绩效及性能或绩效趋势的数据图形显示 3. 已识别的根本原因与要采取的潜在行动 子实践 1. 在适当时候,执行根本原因分析,以诊断过程性能的不足。 在适当时候,过程性能基线与模型用于诊断不足;识别可能的解决方案; 预测未来项目与过程性能;以及评价可能的行动。 在预测未来项目与过程性能时,对过程性能模型的使用在上一个特定实 践的子实践中进行了描述。 2. 识别并分析潜在的行动。 3. 实施所选行动。 4. 评估行动对子过程性能产生的影响。 对影响进行的评估可能包括对已采取的过程性能改进行动所产生影响进 行统计显著性的评价。 268 量化项目管理(QPM) CMMI 开发模型,版本 1.3 需求开发(RD) 成熟度 3 级工程类过程域 目的 简介 需求开发(Requirements Development,RD)的目的在于挖掘、分析并 建立客户需求、产品需求与产品组件需求。 本过程域描述 3 类需求:客户需求、产品需求与产品组件需求。综合起来, 这些需求涉及相关干系人的需要,包括与不同的产品生命周期阶段(例如: 验收测试准则)和产品属性(例如:响应性、安全性、可靠性、可维护性 等)相关的需要。需求还涉及源于设计解决方案(例如:商用现货产品的 集成、特定架构模式的使用等)的选择所带来的约束。 所有的开发项目都有需求。需求是设计的基础。需求的开发包括下列活动: • 客户需要、期望与约束的挖掘、分析、确认与沟通,以获得区分了优 先级的客户需求,形成对什么样的需求将能使干系人得到满足的理解 • 干系人需要的收集与协调 • 产品的生命周期需求的开发 • 客户功能性需求与质量属性需求的建立 • 与客户需求一致的产品及产品组件初始需求的建立 本过程域涉及所有的客户需求而不仅仅是产品级需求,原因在于客户也可 能提供具体的设计需求。 客户需求要进一步提炼为产品需求与产品组件需求。除客户需求之外,产 品需求与产品组件需求产生自选定的设计解决方案。过程域内凡是用到术 语“产品”与“产品组件”的地方,其预期的含义还包含服务、服务系统 与其组件。 需求的识别与提炼贯穿于产品生命周期的所有阶段。在产品生命周期的每 个阶段,都需要分析设计决策、后续纠正措施与反馈等对衍生需求与已分 配需求造成的影响。 “需求开发”过程域包含 3 个特定目标。“开发客户需求”特定目标所应 对的是定义用于开发产品需求的客户需求集合。“开发产品需求”特定目 标所应对的是定义用于设计产品与产品组件的产品需求或产品组件需求。 “分析并确认需求”特定目标所应对的是分析客户需求、产品需求与产品 组件需求,以对需求进行定义、衍生并理解。第三个特定目标中的特定实 践意图在于辅助前两个特定目标中的特定实践。与“需求开发”过程域相 关联的过程以及与“技术解决方案”过程域相关联的过程可以递归地相互 作用。 分析工作用于理解、定义并从相互冲突的备选方案中选择所有级别的需求。 这些分析包含下列活动: • 对产品生命周期的每一阶段的需要及需求的分析,包含相关干系人的 需要、操作环境以及反映客户与最终用户的总体期望与满意度的因素, 诸如安全性、安保性以及可承担性 • 操作概念的开发 需求开发(RD) 269 CMMI 开发模型,版本 1.3 • 必需的功能与质量属性的定义 必需的功能与质量属性的定义描述了产品要做什么。(见术语表中“必需 的功能与质量属性的定义”。)该定义可以包含产品的描述、产品的分解 与产品的功能划分(或面向对象的分析所称的“服务”或“方法”)。 另外,该定义详细说明了产品必需的功能将如何实现的设计依据或约束条 件。质量属性应对的是诸如产品可用性、可维护性、易修改性、及时性、 吞吐量以及响应性、可靠性、安全性与可缩放性。一些质量属性将显现出 在架构方面的重要性,并因此驱动产品架构的开发。 这样的分析在产品架构不断细化的层次递进开展,直到具备足够的细节, 使得产品的详细设计、采购和测试能够进行。对需求与操作概念(包括功 能、支持、维护与废弃)进行分析后,制造或生产的概念将因此产生更多 的衍生需求,所考虑的因素有: • 不同类型的约束 • 技术限制 • 成本及成本驱动因素 • 时间约束及进度驱动因素 • 风险 • 对客户或最终用户隐含的但未明确说明的问题的考虑 • 由开发者独特的业务考虑、规章与法律等方面所引入的因素 随着操作概念的反复演进,逻辑实体的层次结构(例如:功能与子功能、 对象类与子类;过程;其它架构实体)得以建立。需求得以提炼、派生并 分配到这些逻辑实体。需求与逻辑实体被分配到产品、产品组件、人员或 相关联的过程中。在迭代或增量式开发的情况下,需求也将被分配到迭代 或增量中。 相关干系人参与到需求开发与分析之中,可以使需求的演化对他们具有可 视性。该活动使相关干系人不断确信需求得到妥当地定义。 对于产品线,工程过程(包括需求开发)可在组织中至少两个层级进行应 用。在组织级或产品线级,进行“通用性和差异性分析”来帮助挖掘、分 析并建立由产品线内各项目使用的核心资产。而在项目级,作为项目工程 活动的一部分,项目则根据产品线生产计划使用这些核心资产。 在敏捷环境中,客户需要与想法是以迭代的方式进行挖掘、细化说明、分析并 确认的。需求的文档化是以诸如用户故事、场景、用例、产品工作清单以及迭 代的结果(在软件中指可运行的代码)等形式进行的。在一次指定迭代中要处 理哪些需求是由风险评估驱动的,并由与产品工作清单中的遗留事项相关联的 优先顺序驱动。需求(以及其它产物)的哪些细节需要文档化是由(团队成员 之间、团队之间以及后续迭代之间)的协调需要驱动的,并由丢失哪些已有知 识的风险来驱动。当客户在团队中时,仍可能需要区分客户文档与产品文档, 以便于对多种解决方案进行探索。随着解决方案的显现,对衍生需求的职责被 分配给适当的团队。(见第一部分中的“使用敏捷方法时对 CMMI 的解读”。) 270 需求开发(RD) 相关过程域 CMMI 开发模型,版本 1.3 参阅“产品集成”过程域以进一步了解如何确保接口的兼容性。 参阅“技术解决方案”过程域以进一步了解如何选择产品组件解决方案并 进行设计的开发。 参阅“确认”过程域以进一步了解如何对产品或产品组件进行确认。 参阅“验证”过程域以进一步了解如何验证选定的工作产品。 参阅“配置管理”过程域以进一步了解如何跟踪并控制变更。 参阅“需求管理”过程域以进一步了解如何管理需求。 参阅“风险管理”过程域以进一步了解如何识别并分析风险。 需求开发(RD) 271 CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 开发客户需求 SP 1.1 挖掘需要 SP 1.2 将干系人的需要转换为客户需求 SG 2 开发产品需求 SP 2.1 建立产品与产品组件需求 SP 2.2 分配产品组件需求 SP 2.3 识别接口需求 SG 3 分析并确认需求 SP 3.1 建立操作概念与场景 SP 3.2 建立必需的功能与质量属性的定义 SP 3.3 分析需求 SP 3.4 分析需求以达到平衡 SP 3.5 确认需求 按目标排列的特定实践 SG 1 开发客户需求 干系人的需要、期望、约束与接口得到收集并转化为客户需求。 干系人(例如:客户、最终用户、供方、建造方、测试方、制造方、后勤 支持人员)的需要是确定客户需求的基础。干系人需要、期望、约束、接 口、操作概念与产品概念得到分析、协调、提炼并细化,以转换为客户需 求集合。 干系人的需要、期望、约束与接口常常识别不充分或相互冲突。由于干系 人需要、期望、约束与限制应当得到清晰识别并理解,为达成这一目的, 在项目的生命期中使用了迭代式的过程。为促进必要的互动,最终用户或 客户的代理人经常地参与进来代表其需要,来帮助冲突的解决。组织的客 户关系部分或市场部分与来自人因工程学科或支持学科的开发团队成员 一样,都可作为代理人。当建立并解决客户需求的集合时,环境、法律以 及其他约束也应当得到考虑。 SP 1.1 挖掘需要 挖掘干系人对产品生命周期所有阶段的需要、期望、约束与接口。 挖掘活动不仅仅是对需求进行收集,而是通过主动地识别附加的、未由客 户明确提供的需求。附加的需求应当解决产品生命周期的各种活动以及其 对产品的影响。 272 需求开发(RD) CMMI 开发模型,版本 1.3 挖掘需要的技术实例有: • 技术演示 • 接口控制工作组 • 技术控制工作组 • 项目中期评审 • 从最终用户取得的问卷调查表、访谈以及(操作的、支持的与开发的)场 景 • 操作的、支持的与开发的走查,以及最终用户任务的分析 • 有干系人参加的质量属性挖掘研讨会 • 原型与模型 • 头脑风暴 • 质量功能展开 • 市场调查 • Beta 测试 • 来源于诸如文档、标准或规格说明的信息提取 • 对现有产品、环境与工作流模式的观察 • 用例 • 用户故事 • 产品功能的小规模增量式“垂直片段”交付 • 业务案例分析 • (对遗留产品的)逆向工程 • 客户满意度调查 客户或许未能识别出的需求,其需求来源的实例有: • 业务方针 • 标准 • 先前的架构设计决策与原则 • 业务环境需求(例如:实验室、测试与其它设施、信息技术基础设施等) • 技术 • 遗留产品或产品组件(复用产品组件) • 法规条文 工作产品实例 1. 需求挖掘活动的结果 子实践 1. 使用方法引导相关干系人,以挖掘需要、期望、约束与外部接口。 需求开发(RD) 273 CMMI 开发模型,版本 1.3 SG 2 SP 1.2 将干系人的需要转换为客户需求 将干系人的需要、期望、约束与接口转换为划分了优先级的客户需求。 随着客户需求的开发与及优先级的区分,应当合并来自于相关干系人的各 种输入,获取缺失的信息并解决矛盾之处。客户需求可以包含与验证和确 认相关的需要、期望和约束。 在某些情形下,客户向项目提供需求集合,或需求作为以前项目的活动输 出而存在。在这些情形下,客户需求可能与相关干系人的需要、期望、约 束与接口相矛盾,在矛盾得到妥善解决后,需要将其转换为经认可的客户 需求集合。 代表项目的生命周期所有阶段的相关干系人应当包括业务职能与技术职 能。这样,所有与产品相关的生命周期过程的概念就同产品的概念一并得 到考虑。客户需求不仅得自于这些需求在技术效果方面的知情决策,而且 得自于其在业务方面的知情决策。 工作产品实例 1. 区分了优先级的客户需求 2. 有关执行验证的客户约束 3. 有关执行确认的客户约束 子实践 1. 将干系人需要、期望、约束及接口转换为文档化的客户需求。 2. 建立并维护客户功能需求与质量属性需求的优先顺序。 区分了优先顺序的客户需求有助于确定项目、迭代或增量的范围。这一 优先顺序可确保对客户与其他相关干系人来说那些关键的功能需求与质 量属性需求得到迅速处理。 3. 定义验证与确认的约束。 开发产品需求 客户需求得到提炼与细化,以开发产品与产品组件需求。 结合操作概念的开发,客户需求得到分析,以衍生出更详细且精确的需求 集合,称为“产品与产品组件需求”。产品与产品组件需求解决与产品生 命周期各阶段相关联的需要。衍生需求产生自约束;对隐含在客户需求基 线中而未明确说明的问题的考虑;由选定的架构、产品生命周期与设计引 入的因素;以及开发方独特的业务考虑。伴随每一后续的、低一级的需求 集合与架构,需求得到再次检验,并且首选的产品概念得到提炼。 需求得以分配至产品功能与产品组件,包括对象、人员与过程。在迭代式 或增量式开发的情况下,需求也会根据客户的优先顺序、技术问题与项目 目标分配至那些迭代或增量。需求到功能、对象、测试、问题或其它实体 的可追溯性得到文档化。已分配的需求及功能(或其它逻辑实体)是合成 技术解决方案的基础;然而,随着架构得到定义或显现,架构成为指导将 需求分配至解决方案的最终基础。随着内部组件得到开发,附加的接口得 到了提炼,并且接口需求得到了建立。 参阅“需求管理”过程域以进一步了解如何维护需求的双向可追溯性。 274 需求开发(RD) CMMI 开发模型,版本 1.3 SP 2.1 建立产品与产品组件需求 依据客户需求,建立并维护产品与产品组件需求。 客户功能需求与质量属性需求可以用客户的术语表达,并且可以是非技术 性描述。产品需求则是以技术术语表达的这些需求,并能用于设计决策。 这一转换的实例可以在“质量功能展开屋(House of Quality Function Deployment)”的第一步中找到,这一步骤将客户希望映射为技术参数。 例如,“实心音效门”可以映射为尺寸、重量、安装匹配、减震与共振频 率。 产品与产品组件需求处理的是客户的满意度、业务、以及项目目标与关联 属性,如有效性与可承担性。 衍生需求同时处理其它生命周期阶段(例如:生产、运行、废弃等)与业 务目标一致的需要。 由已得到批准的需求变更引起需求的修改由本特定实践的“维护”部分覆 盖;而需求变更的管理则由“需求管理”过程域覆盖。 参阅“需求管理”过程域以进一步了解如何管理需求。 工作产品实例 1. 衍生需求 2. 产品需求 3. 产品组件需求 4. 说明或约束了产品组件之间关系的架构需求 子实践 1. 使用技术术语开发需求,这些技术术语对产品与产品组件的设计来说 是必要的。 2. 对需求进行由设计决策引起的衍生推断。 参阅“技术解决方案”过程域以进一步了解如何选择产品组件解决方案 并进行设计的开发。 技术的选择带来附加的需求。例如,电子器件的使用需要额外的技术上 的特定需求,例如电磁干扰限制。 诸如架构模式的选择那样的架构决策为产品组件引入额外的衍生需求。 例如,分层模式将约束某些产品组件之间的依赖关系。 3. 开发架构需求,这些架构需求捕获了关键的质量属性与为建立产品架 构与设计而必要的质量属性度量项。 质量属性度量项的实例有: • 响应时间小于 1 秒 • 系统的可用时间达到 99% • 实现一项变更的工作量不超过 1 个人周 4. 建立并维护需求间的关系,以便在变更管理与需求分配时进行考虑。 参阅“需求管理”过程域以进一步了解如何维护需求的双向可追溯性。 需求之间的关系有助于评价变更的影响。 需求开发(RD) 275 CMMI 开发模型,版本 1.3 SP 2.2 SP 2.3 分配产品组件需求 为各产品组件分配需求。 参阅“技术解决方案”过程域以进一步了解如何选择产品组件的解决方案。 将产品需求分配到产品组件中,产品架构是其基础。对于已定义的解决方 案,其产品组件的需求包括产品性能的分配、设计约束、以及为满足需求 并便于生产的安装匹配、外形与功能。由上一级需求所规定的某项质量属 性可以由多于一个的产品组件所承担,在此情况下,该质量属性有时能作 为衍生需求被单独分解到每一产品组件中去,然而有时这一共享的需求却 应当直接分配至架构。例如,共享需求至架构的分配将描述性能需求(例 如:响应时间)如何在各组件进行划分,以便以端对端的方式解决需求的 实现。这一共享需求的概念可以扩展到其它在架构方面具有重要性的质量 属性(例如:安全性、可靠性等)。 工作产品实例 1. 需求分配单 2. 临时的需求分配 3. 设计约束 4. 衍生需求 5. 衍生需求之间的关系 子实践 1. 将需求分配至功能。 2. 将需求分配至产品组件与架构。 3. 将设计约束分配至产品组件及架构。 4. 将需求分配至交付增量。 5. 将已分配需求之间的关系文档化。 这样的关系包括某一需求内的变更可能影响其它需求的依赖关系。 识别接口需求 识别接口需求。 功能之间(或者是对象或其它逻辑实体之间)的接口进行了识别。接口可 以驱动在“技术解决方案”过程域中描述的备选解决方案的开发。 参阅“产品集成”过程域以进一步了解如何确保接口的兼容性。 在产品架构中识别的产品之间或产品组件之间的接口需求进行了定义。它 们作为产品集成与产品组件集成的一部分受到控制,并且是架构定义的必 不可少的一部分。 工作产品实例 1. 接口需求 子实践 1. 识别产品的外部接口以及产品的内部接口(例如:功能划分之间或对 象之间)。 随着设计的进展,技术解决方案过程会改变产品架构,从而创建产品组 件与产品外部组件之间的新接口。 与产品相关的生命周期过程的接口也应当进行识别。 276 需求开发(RD) CMMI 开发模型,版本 1.3 SG 3 这些接口的实例有测试设备的接口、传输系统的接口、支持系统的接口 与制造设施的接口。 2. 开发已识别接口的需求。 参阅“技术解决方案”过程域以进一步了解如何使用准则设计接口。 接口需求的定义中所使用的术语有起源、目标、刺激源、软件的数据特 性、以及硬件的电气与机械特性等。 分析并确认需求 需求得到分析与确认。 “分析并确认需求”特定目标中的特定实践既支持“开发客户需求”特定 目标中的需求开发,也支持“开发产品需求”特定目标中的需求开发。与 本特定目标相关联的特定实践涵盖需求的分析与确认,并与最终用户的预 期环境相关。 分析得到执行,以确定预期的操作环境将会对满足干系人的需要、期望、 约束与接口的能力产生什么影响。取决于产品所处的环境,诸如可行性、 使命需要、成本约束、潜在的市场规模与采购策略等因素,都应当加以考 虑。基于使命与业务驱动因素,在架构方面具有重要性的质量属性得到了 识别。必需的功能与质量属性定义也得到了建立。所有规定的产品使用方 式得到了考虑。 分析的目的是为了确定那些满足干系人需要、期望与约束的产品概念的候 选需求,然后将这些概念转换为需求。与此同时,基于客户的输入与初步 的产品概念,用于评价产品有效性的参数得到了确定。 需求得到确认,以增加最终产品的表现在使用环境中合乎预期设想的可能 性。 SP 3.1 建立操作概念与场景 建立并维护操作概念与相关场景。 典型情况下,场景是可能发生在产品的开发、使用或支持时的事件序列, 用于明确干系人在某些功能或质量属性方面的需要。与此相对,产品的操 作概念通常既依赖于设计解决方案,也依赖于场景。例如,基于卫星的通 信产品的操作概念与基于陆上通信线的通信产品的操作概念就有非常大 的不同。由于在准备初步的操作概念时备选解决方案往往还没有得到定义, 这时通过开发概念性的解决方案供分析需求时使用。在制定解决方案决策 时操作概念被进一步提炼,并且更低层次的详细需求得到了开发。 正如产品的设计决策能成为产品组件的需求,操作概念也能成为产品组件 的场景(需求)。对操作概念与场景进行演化以便于产品组件解决方案的 选择,当实现这样的解决方案后,它将能够满足产品的预期用途,或便于 其开发与维持。不管是怎样的工程学科,操作概念与场景都记录了产品组 件与环境、最终用户和其它产品组件之间的交互。这些交互的文档记录应 体现操作、产品开发、部署、交付、支持(包括维护与维持)、培训与废 弃在内的所有模式和状态。 可以开发场景以应对操作、维持、开发或其它事件序列。 需求开发(RD) 277 CMMI 开发模型,版本 1.3 SP 3.2 工作产品实例 1. 操作概念 2. 产品或产品组件的开发、安装、操作、维护与支持概念 3. 废弃概念 4. 用例 5. 时间线场景 6. 新需求 子实践 1. 适当地开发包括操作、安装、开发、维护、支持与废弃的操作概念与 场景。 识别并开发场景,其详细程度与干系人的需要、期望与约束相一致,所 提议的产品或产品组件在此场景下进行预期的操作。 扩充场景,扩充时考虑场景中描述的功能(或其它逻辑实体)的质量属 性因素。 2. 定义产品或产品组件将要操作的环境,包括边界与约束。 3. 评审操作概念与场景,以提炼并发现需求。 操作概念与场景的开发是迭代式的过程。应当定期进行评审以确保它们 与需求一致。评审可以用走查的形式进行。 4. 随着对产品与产品组件进行选择,开发详细的操作概念,该操作概念 定义了产品、最终用户与环境的交互,且满足操作、维护、支持与废 弃的需要。 建立必需的功能与质量属性的定义 建立并维护必需的功能与质量属性的定义。 一种定义必需的功能与质量属性的方法是使用某些称为“功能分析”的方 法,去分析场景以描述产品打算要做什么。这一功能描述可以包括行动、 顺序、输入、输出或其它沟通产品使用方式的信息。得出的功能、功能的 逻辑分组以及其与需求的关联关系的描述被称为功能架构。(见术语表中 “功能分析”与“功能架构”的定义。) 近年来这些方法已经通过架构描述语言、方法与工具的引入等不断演进发 展,以更充分地处理并描述质量属性的特征,在已定义的功能将如何在产 品中进行实现方面,这样的演进发展使得对约束更丰富的(例如:多维度) 规格说明成为可能,并便于对需求与技术解决方案进行进一步的分析。某 些质量属性将显现出在架构方面的重要性,进而驱动产品架构的开发。这 些质量属性所涉及的通常是横向交叉的影响,而可能无法分配至解决方案 中更低层次的元素。对质量属性及其基于使命或业务需要的重要性的清晰 理解,是设计过程的必不可少的输入。 工作产品实例 1. 必需的功能与质量属性定义 2. 功能架构 3. 活动图与用例 4. 识别了服务或方法的面向对象分析 5. 具有架构重要性的质量属性需求 278 需求开发(RD) CMMI 开发模型,版本 1.3 SP 3.3 子实践 1. 确定关键使命与业务驱动因素。 2. 识别可取的功能与质量属性。 如同上一特定实践所描述的那样,通过与相关干系人一起进行各种场景 的分析,可以对功能与质量属性进行识别与定义。 3. 基于关键使命与业务驱动因素,确定具有架构重要性的质量属性。 4. 分析最终用户所要求的功能,并确定其数量。 这样的分析可涉及考虑时间关键性功能的时序。 5. 分析需求以识别逻辑或功能划分(例如:子功能)。 6. 依据已建立的准则(例如:相似的功能、相似的质量属性需求、耦合 等),将需求分组,以利于需求的分析与专注。 7. 将客户需求分配至功能划分、对象、人员或支持元素,以支持解决方 案的整合。 8. 将需求分配至功能与子功能(或其它逻辑实体)。 分析需求 分析需求以确保其必要性与充分性。 以操作概念与场景为出发点,分析产品在某个层次的需求,以确定它们在 满足产品上一层次的目标方面是否必要与充分。分析后的需求进而为产品 下一层次的更详细、更精确的需求建立了基础。 定义了需求之后,就应当能够理解需求与上一级需求、需求与上一级必需 的功能与质量属性定义之间的关系。用于跟踪进度的关键需求也可以进行 确定。例如,在开发期间,产品的重量或软件产品的规模可以依据其风险 或其对客户的关键程度进行监督。 参阅“验证”过程域以进一步了解如何建立验证规程与准则。 工作产品实例 1. 需求缺陷报告 2. 为解决缺陷而提议的需求变更 3. 关键需求 4. 技术性能度量项 子实践 1. 分析干系人需要、期望、约束与外部接口,以将其按照相关的主题组 织在一起,并排除冲突。 2. 分析需求以确定其是否满足上一层次需求的目标。 3. 分析需求以确保其是完整的、可行的、可实现的并且是可验证的。 虽然确定某个特定解决方案可行性的是设计,但是本子实践可用于理解 哪些需求影响了可行性。 4. 识别对成本、进度、性能或风险有重大影响的关键需求。 需求开发(RD) 279 CMMI 开发模型,版本 1.3 SP 3.4 SP 3.5 5. 识别将在开发期间进行跟踪的技术性能度量项。 参阅“度量与分析”过程域以进一步了解如何开发并保持用于支持管理 信息需要的度量能力。 6. 分析操作概念与场景,以提炼客户需要、约束与接口,并发现新需求。 这一分析可能得出更详细的操作概念与场景,并支持新需求的派生。 分析需求以达到平衡 分析需求以平衡干系人的需要与约束。 干系人的需要与约束能处理诸如成本、进度、产品性能或项目绩效、功能、 优先顺序、可复用组件、可维护性或风险等事项。 工作产品实例 1. 与需求相关的风险评估 子实践 1. 使用已证明的模型、模拟与原型对如何平衡干系人的需要与约束进行 分析。 分析的结果可用于降低产品的成本与产品开发的风险。 2. 对需求及必需的功能与质量属性定义进行风险评估。 参阅“风险管理”过程域以进一步了解如何识别并分析风险。 3. 检验产品生命周期概念以评价需求对风险的影响。 4. 评估具有架构重要性的质量属性需求给产品与产品开发成本及风险 带来的影响。 当需求给成本与风险的带来的影响似乎超出了预计收益时,应当咨询相 关干系人,以确定需要进行哪些变更。 举例来说,非常严格的响应时间需求或高可用性需求可能被证明实现起 来成本高昂。一旦理解了这样的影响(例如对成本),或许可以放宽这 一需求。 确认需求 确认需求,以确保所做出的产品在最终用户的环境中能如预期执行。 在开发活动的早期就要与最终用户共同进行需求的确认,以获得信心,使 得需求能够指导开发,并实现最后的成功确认。这一活动应当与风险管理 活动集成在一起。成熟的组织进行需求确认时,通常以更复杂的方式,使 用多种技术,并且扩大确认的基础,去包含干系人的其它需要与期望。 用于需求确认的技术的实例有: • 分析 • 模拟 • 原型 • 演示 工作产品实例 1. 分析方法与结果的文档记录 280 需求开发(RD) CMMI 开发模型,版本 1.3 子实践 1. 分析需求以确定所获得产品将不能在其预期的使用环境中正确运行 的风险。 2. 开发产品表示法(例如:原型、模拟、模型、场景、故事板等),获 得相关干系人对此的反馈,以此方式探索需求的充分性与完整性。 参阅“确认”过程域以进一步了解如何进行确认的准备,并对产品或产 品组件进行确认。 3. 随着设计的成熟,在需求确认环境的背景下对其进行评估,以识别确 认的问题,并揭示未陈述的需要与客户需求。 需求开发(RD) 281 CMMI 开发模型,版本 1.3 282 需求开发(RD) CMMI 开发模型,版本 1.3 需求管理(REQM) 成熟度 2 级项目管理类过程域 目的 简介 需求管理(Requirements Management,REQM)的目的在于管理项目的 产品与产品组件需求,并确保那些需求与项目计划和工作产品间的协调一 致。 “需求管理”过程管理所有由项目收到或产生的需求,包括技术与非技术 需求,以及由组织赋予项目的需求。 特别要指出的是,如果实施了“需求开发”过程域,由该过程域中的各过 程产生的产品与产品组件需求也将由需求管理过程来进行管理。 在各个过程域中使用到的术语“产品”与“产品组件”,其含义也包含了 服务、服务系统以及它们的组件。 当“需求管理”、“需求开发”与“技术解决方案”过程域都得到实施时, 其相关的过程能够紧密结合并同时执行。 项目应采取适当的步骤来确保已批准的需求集得到管理,以支持项目计划 与执行的需要。当项目从已批准的需求提供方处接收了需求,应在将这些 需求纳入项目计划之前,与需求提供方一起评审这些需求,以解决问题并 避免误解。一旦需求提供方与需求接收方达成一致,应从项目参加者处获 得对需求的承诺。随着需求的演变,项目对需求的变更进行管理,并识别 在计划、工作产品与需求间的不一致。 需求管理活动还包括将需求变更及其依据文档化,并维护源需求、所有产 品与产品组件需求,以及其它规定的工作产品之间的双向可追溯性。(见 术语表中“双向可追溯性”的定义。) 所有项目都有需求。在维护活动中,变更是对已有的需求、设计或实现的 变更。在增量式交付产品能力的项目中,其变更可能是由于客户需要的演 变、技术上的成熟或过时以及标准的演变而产生的。在上述两种情况下, 需求变更(如果有的话)可能记录在客户或最终用户提出的变更请求中, 也可能是从需求开发过程中接收的新需求的形式。不管是何种来源或形式, 由需求变更所驱动的活动都应得到相应的管理。 在敏捷环境中,需求通过如产品工作清单(product backlog)、故事卡(story card)与屏幕模型(screen mock-up)等机制得以沟通与跟踪。对于需求的承 诺由团队集体作出或由授权的团队领导者作出。基于已取得的进展、对需求理 解的加深以及解决方案的逐步显现,定期地(如每天、每周)进行工作分配的 调整。需求与工作产品的可追溯性与一致性也可通过上述机制以及在迭代开始 或迭代结束活动(如“回顾会”或“演示日”等)中得到处理。(见第一部分 中的“使用敏捷方法时对 CMMI 的解读”。) 需求管理(REQM) 283 CMMI 开发模型,版本 1.3 相关过程域 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“技术解决方案”过程域以进一步了解如何选择、设计并实现对需求 的解决方案。 参阅“配置管理”过程域以进一步了解如何建立基线并跟踪与控制变更。 参阅“项目监督与控制”过程域以进一步了解如何对照计划监督项目,并 管理纠正措施直至关闭。 参阅“项目计划”过程域以进一步了解如何建立并维护定义项目活动的计 划。 参阅“风险管理”过程域以进一步了解如何识别并分析风险。 284 需求管理(REQM) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 管理需求 SP 1.1 理解需求 SP 1.2 获得对需求的承诺 SP 1.3 管理需求变更 SP 1.4 维护需求的双向可追溯性 SP 1.5 确保项目工作与需求间的协调一致 按目标排列的特定实践 SG 1 管理需求 需求得到管理,与项目计划和工作产品间的不一致得到识别。 项目通过以下活动来在整个项目期间维护当前已批准的需求集: • 管理所有需求变更 • 维护需求、项目计划与工作产品之间的关联关系 • 确保需求、项目计划与工作产品之间的协调一致 • 采取纠正措施 参阅“需求开发”过程域以进一步了解如何分析并确认需求。 参阅“技术解决方案”过程域中的“开发备选解决方案和选择准则”特定 实践以进一步了解如何确定需求的可行性。 参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施直至关闭。 SP 1.1 理解需求 与需求提供方一起达成对需求含义的理解。 随着项目的逐步成熟和需求的产生,所有的项目活动或专业领域将接收需 求。为避免需求蔓延,应建立准则来指定接收需求的适当渠道或官方来源。 需求接收方与提供方一起对需求进行分析,以确保对于需求的含义达成一 个相容的、共同的理解。这些分析和对话的结果是已批准的需求集。 工作产品实例 1. 区分适当的需求提供方的准则列表 2. 评价与验收需求的准则 3. 基于准则的分析结果 4. 已批准的的需求集 子实践 1. 建立区分适当的需求提供方的准则。 2. 建立评价与验收需求的客观准则。 缺少评价与验收需求的准则通常会导致不充分的验证、代价高昂的返工 或客户的拒绝。 需求管理(REQM) 285 CMMI 开发模型,版本 1.3 评价与验收准则的实例有: • 描述清晰而适当 • 完整 • 彼此一致 • 可唯一识别 • 与架构方法与质量属性的优先级划分相一致 • 适于实现 • 可验证(即可测试) • 可追溯 • 可实现 • 与业务价值结合紧密 • 被认定为客户的一个高优先级需求 SP 1.2 3. 分析需求以确保建立的准则得到了满足。 4. 与需求提供方达成对需求的理解,从而使项目参与者能够对其作出承 诺。 获得对需求的承诺 获得项目参与者对需求的承诺。 参阅“项目监督与控制”过程域以进一步了解如何监督承诺。 前一条特定实践处理的是与需求提供方达成对需求的理解。本特定实践处 理的是在执行必要的需求实现活动的人员之间达成一致与承诺。需求在项 目期间会逐渐演变。本特定实践确保项目参与者随着需求的演变,对当前 的、已批准的需求及其导致的项目计划、活动与工作产品的变更作出承诺。 工作产品实例 1. 需求影响评估 2. 对需求与需求变更的文档化的承诺 子实践 1. 评估需求对已有承诺的影响。 当需求变更或新需求产生时,应评价其对项目参与者的影响。 2. 协商并记录承诺。 在项目参与者对新需求或需求变更作出承诺前,应先协商对既有承诺的 变更。 286 需求管理(REQM) CMMI 开发模型,版本 1.3 SP 1.3 SP 1.4 管理需求变更 随着项目进行中需求的演变,对需求变更进行管理。 参阅“配置管理”过程域以进一步了解如何跟踪并控制变更。 需求变更有各种原因。随着要求的变化与工作的进展,可能必须对已有需 求进行变更。有必要高效而有效地管理这些新增需求与变更。为有效地分 析变更的影响,有必要了解每个需求的来源,并将变更的依据文档化。项 目可能要对需求易变性的适当的度量项进行跟踪,以判断是否有必要采用 新的变更控制方法或修订已有的变更控制方法。 工作产品实例 1. 需求变更请求 2. 需求变更影响报告 3. 需求状态 4. 需求数据库 子实践 1. 将对项目提出的或由项目产生的所有需求与需求变更文档化。 2. 维护需求变更历史信息,包括变更的依据。 维护变更历史信息有助于跟踪需求易变性。 3. 从相关干系人的立场评价需求变更的影响。 影响产品架构的需求变更可能会对很多干系人产生影响。 4. 确保需求与变更的数据对项目可用。 维护需求的双向可追溯性 维护需求与工作产品之间的双向可追溯性。 本特定实践旨在维护需求的双向可追溯性(见术语表中“双向可追溯性” 的定义。)当需求得到有效管理时,我们能够建立起从源需求到其较低层 次需求以及从较低层次需求回溯到源需求的可追溯性。这种双向可追溯性 有助于确定是否所有的源需求都得到了完全的处理以及是否所有较低层 次需求都可以追溯到一个有效的来源。 需求可追溯性也包括与其它实体如中间的与最终的工作产品、设计文档的 变更以及测试计划等的关联。可追溯性既包括垂直关联,也包括水平关联, 如接口两端。在评估需求变更对项目活动与工作产品的影响时,可追溯性 尤为重要。 可追溯性要考虑的方面,实例有: • 可追溯性的范围:可追溯性所需的边界 • 可追溯性的定义:需要建立逻辑关联的元素 • 可追溯性的类别:何时需要建立水平与垂直可追溯性 此类双向可追溯性并不总是自动化的。可以用电子表格、数据库及其它通 用工具来手工实现。 工作产品实例 1. 需求可追溯性矩阵 2. 需求跟踪系统 需求管理(REQM) 287 CMMI 开发模型,版本 1.3 SP 1.5 子实践 1. 维护需求可追溯性,以确保将低等级(即衍生的)需求的来源文档化。 2. 维护从需求到其衍生需求及其在工作产品中的分配的需求可追溯性。 可能需要维护其可追溯性的工作产品包括:架构、产品组件、开发迭代 (或增量)、功能、接口、对象、人员、过程及其它工作产品。 3. 创建需求可追溯性矩阵。 确保项目工作与需求间的协调一致 确保项目计划和工作产品与需求之间保持协调一致。 本特定实践识别需求与项目计划、工作产品之间的不一致,并采取纠正措 施来纠正这些问题。 工作产品实例 1. 需求与项目计划、工作产品之间不一致的记录文档,包括来源与条件 2. 纠正措施 子实践 1. 评审项目计划、活动以及工作产品与需求及其变更的一致性。 2. 识别不一致的来源(如果有的话)。 3. 识别由需求基线的变更引起的,应对计划与工作产品进行的变更。 4. 启动必要的纠正措施。 288 需求管理(REQM) CMMI 开发模型,版本 1.3 风险管理(RSKM) 成熟度 3 级项目管理类过程域 目的 简介 风险管理(Risk Management,RSKM)的目的在于在项目潜在的问题发 生前对其进行识别,以便在整个产品或项目生命期中,计划并在需要时启 动风险的处理行动,从而降低这些潜在问题对达成目标产生的不利影响。 “风险管理”是一个持续的、前瞻性的过程,也是项目管理的重要组成部 分。风险管理应能应对可能威胁关键目标达成的问题。持续的风险管理方 法能有效地预测并缓解可能对项目产生重大影响的风险。 有效的风险管理包括通过与相关干系人的协作与参与(在“项目计划”过 程域中提及的干系人参与计划中描述),及早、积极地识别风险。为建立 一个自由、开放地揭示并讨论风险的环境,需要具备对相关干系人的强有 力的领导能力。 风险管理应考虑到内部与外部、技术与非技术、成本来源、进度、性能以 及其它方面的风险。尽早、积极地发现风险是很重要的,因为在项目早期 阶段采取变更与纠正措施,相对于在项目后期才采取措施,往往更加容易 和经济,破坏性也更小。 例如,与产品架构相关的决定,往往在充分理解相关的影响前,就已经做 出了,因此必须要审慎考虑此类选择所蕴含的风险。 行业标准有助于确定如何预防或缓解在某一特定行业中经常出现的特定 风险。通过对这些行业最佳实践与经验教训的回顾,可以主动地管理与缓 解某些特定的风险。 风险管理可以分为以下几部分: • 定义风险管理策略 • 识别并分析风险 • 处理已经识别的风险,包括在必要时执行风险缓解计划 正如在“项目计划”和“项目监督与控制”过程域中已经介绍过的,组织 最初可能会专注于识别风险,以在风险发生时及时察觉并作出反应。“风 险管理”过程域描述了这些特定实践的演进,从而系统地计划、预测与缓 解风险,以主动减小其对项目的影响。 虽然“风险管理”过程域主要强调的是项目风险管理,但这些概念同样适 用于管理组织级的风险。 在敏捷环境中,所使用的敏捷方法本身就已经包含了某些风险管理活动,例如, 某些技术风险可以通过鼓励实验(早期“试错”[early“failure”])或在常 规迭代之外的“穿刺检查(spike)”来处理。然而,“风险管理”过程域鼓 励在技术与非技术领域都采用更为系统化的方法来管理风险。这样的方法可以 集成到敏捷方法典型的迭代与会议节奏中,尤其是在迭代计划、任务估算与任 务验收期间。(见第一部分中的“使用敏捷方法时对 CMMI 的解读”。) 风险管理(RSKM) 289 CMMI 开发模型,版本 1.3 相关过程域 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“项目监督与控制”过程域以进一步了解如何监督项目风险。 参阅“项目计划”过程域以进一步了解如何识别项目风险并计划干系人的 参与。 290 风险管理(RSKM) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 准备风险管理 SP 1.1 确定风险来源与类别 SP 1.2 定义风险参数 SP 1.3 建立风险管理策略 SG 2 识别并分析风险 SP 2.1 识别风险 SP 2.2 评价、分类风险并划分风险优先级 SG 3 缓解风险 SP 3.1 制订风险缓解计划 SP 3.2 实施风险缓解计划 按目标排列的特定实践 SG 1 准备风险管理 风险管理的准备工作得以进行。 建立并维护风险识别、分析与缓解的策略,以进行风险管理的准备。该策 略通常会在风险管理计划中得到文档化。风险管理策略说明了应用与控制 风险管理计划的具体措施与管理方法。该策略通常会包含风险来源的识别、 风险分类的方案以及用以有效处理风险的风险评价、界定与控制的参数。 SP 1.1 确定风险来源与类别 确定风险来源与类别。 风险来源的识别奠定了基础,以系统地检查随时间变化的形势,从而揭示 影响项目目标达成能力的情况。风险既来源于项目内部,也来源于项目外 部。随着项目的进展,可以识别出风险的其它来源。建立风险的类别提供 了一种机制,以收集与整理风险,对于那些会严重影响项目目标达成的风 险,确保给予适当的监察与管理层关注。 工作产品实例 1. 风险来源清单(外部与内部的) 2. 风险类别清单 子实践 1. 确定风险来源。 风险来源是项目与组织中导致风险的基本因素。项目有很多内部与外部 的风险来源。风险来源识别了风险可能的起源。 风险管理(RSKM) 291 CMMI 开发模型,版本 1.3 典型的内部与外部风险来源有: • 不确定的需求 • 无先例可循的工作(即无可用的估算) • 不可行的设计 • 会影响方案选择与设计的、相互冲突的质量属性需求 • 不具备的技术 • 不切实际的进度估算或安排 • 不充足的人员和技能 • 成本或预算问题 • 不确定或不充分的分包商能力 • 不确定或不充分的供方能力 • 与实际或潜在的客户或其代表间不充分的沟通 • 运行连续性的中断 • 管理的约束(如保密、安全、环境) 这些风险来源中有许多种在未经充分计划之前就被接受了。对内部与外 部风险来源的早期识别,有助于及早识别风险。从而,风险缓解计划也 能够在项目中及早实施,以预防风险的发生或者减轻其发生时所造成的 后果。 2. 确定风险类别。 风险类别提供了一个用于收集与组织风险的“储物柜”。识别风险类别 有助于未来对风险缓解计划中的各项活动进行整合。 在确定风险类别时,可考虑以下因素: • 项目生命周期模型的阶段(如需求、设计、制造、测试与评价、交付、 废弃处置) • 所使用的过程类型 • 所使用的产品类型 • 项目管理风险(如合同风险、预算风险、进度风险、资源风险) • 技术性能风险(如与质量属性相关的风险、可支持性风险) SP 1.2 风险分类可用于为风险来源与类别的确定提供一个框架。 定义风险参数 定义用于对风险进行分析、分类以及用于控制风险管理工作的参数。 用于风险评价、分类与优先级划分的参数有: • 风险的可能性(即风险发生的概率) • 风险的后果(即风险发生时产生的影响及其严重性) • 触发管理活动的阈值 292 风险管理(RSKM) CMMI 开发模型,版本 1.3 风险参数用于提供公共的、一致的评价准则,以比较需要管理的各项风险。 如果没有这些参数,就很难衡量风险导致的负面变化的严重性,也难以为 风险缓解计划中的各项措施排定优先级。 项目的形势会随时间发生变化,因此项目应记录这些用于风险分析与分类 的参数,使其在整个项目生命期内都能提供参考作用。在变更发生时当情 况发生变化时,可以方便地利用这些参数对风险进行重新分类与分析。 项目可以使用诸如失效模式与影响分析(failure mode and effects analysis, FMEA)等技术,来考察产品或选定的产品开发过程中的潜在失效风险。 此类技术有助于规范风险参数的使用。 工作产品实例 1. 风险评价、分类与优先级划分准则 2. 风险管理要求(如控制与审批级别、重新评估的时间间隔) 子实践 1. 定义一致的准则,以评价与量化风险的可能性、严重性水平。 一致使用的准则(如可能性与严重程度的界定),使得对于不同的风险 的影响,能够达成共同的理解,并得到适当级别的监察以及有保障的管 理层关注。在管理不同的风险时(如人身安全风险与环境污染风险), 保证最终结果的一致性是很重要的。(例如,严重的环境污染与严重的 人身安全风险同样重要)。为比较不同风险提供公共基础的方法之一, 就是赋予这些风险相应的经济价值(例如通过一个风险货币化的过程)。 2. 定义每个风险类别的阈值。 可以对每个风险类别定义阈值,以决定该风险是否可以接受、风险的优 先级或者启动管理措施的触发条件。 阈值的实例有: • 项目阈值可以设置为:当产品成本超出目标成本 10%或者成本绩效 指数(cost performance index,CPI)低于 0.95 时,需要高层管理 人员的参与。 • 进度阈值可以设置为:当进度绩效指数(schedule performance index,SPI)低于 0.95 时,需要高层管理人员的参与。 • 性能阈值可以设置为:当规定的关键指标(如处理器利用率、平均响 应时间)超过预期设计值的 125%时,需要高层管理人员的参与。 3. 定义阈值在某风险类别内外的适用范围。 对于哪些风险能采用定性分析,哪些能采用定量分析并无多少限制。范 围边界值的界定(或者边界条件)有助于确定风险管理工作的范围和避 免资源的过度浪费。设定范围边界值时,可以将某类风险来源排除在外, 也可以将发生频率低于一定程度的情况排除在外。 风险管理(RSKM) 293 CMMI 开发模型,版本 1.3 SG 2 SP 1.3 建立风险管理策略 建立并维护用于风险管理的策略。 一个全面的风险管理策略应说明以下内容: • 风险管理工作的范围 • 用于风险识别、风险分析、风险缓解、风险监督与沟通的方法与工具 • 项目特定的风险来源 • 如何组织、分类、比较与整合风险 • 用于对所识别的风险采取措施的参数,包括可能性、后果及阈值 • 所使用的风险缓解手段,如原型法、试用、模拟、备选方案设计或渐 进式开发 • 用于监督风险状态的风险度量项定义 • 风险监督或重评估的时间间隔 风险管理策略应遵循共同成功愿景的指导,该愿景通过交付的产品、成本 以及任务的适用性,描述了预期的未来项目结果。风险管理策略通常会在 组织或项目的风险管理计划中得到文档化。应与相关干系人共同评审该策 略,以增进对该策略的承诺与理解。 应在项目初期就制订风险管理策略,从而主动地识别和管理相关风险。对 于关键风险的尽早识别与评估,能使项目规划风险的应对方法,并基于关 键的风险调整项目资源的定义与分配。 工作产品实例 1. 项目风险管理策略 识别并分析风险 风险得到识别与分析,以决定其相对重要性。 风险等级会影响到为应对该风险所投入的资源,以及提请管理者适当关注 该风险的时机。 风险分析,需要从已定义的内、外部风险来源中识别出风险,并对每个已 识别的风险进行评价以确定其可能性与后果。基于按照风险管理策略建立 的风险类别与准则进行的评价,风险分类能够提供应对风险所需的信息。 对相关的风险进行分组,能够实现风险应对的高效和风险管理资源的有效 利用。 SP 2.1 识别风险 识别风险并将其文档化。 项目中潜在的问题、危险、威胁及漏洞会对项目成果或计划产生负面影响, 对它们的识别是充分、成功地管理风险的基础。在适当地分析和管理风险 前,应以易于理解的方式来识别与描述风险。并简单明了地将风险文档化, 包括风险发生的背景、条件以及风险导致的后果。 风险识别应该是一个有组织的、全面的方法,以找出目标达成过程中可能 发生的或现实存在的风险。为有效起见,风险识别不应试图去说明所有可 能的事件。利用在风险管理策略中制订的类别、参数以及识别的风险来源, 可以使风险识别更加规范和高效。已识别的风险构成了启动风险管理活动 的基线。应定期评审风险,以重新检视可能的风险来源和状态的变更,从 而发现在风险管理策略最近一次更新时尚不存在的或者被忽略的来源和 风险。 294 风险管理(RSKM) CMMI 开发模型,版本 1.3 风险识别应关注于风险识别本身,而不是对风险的追责。管理层决不能将 风险识别的结果用于个人绩效的评价。 风险识别有很多方法。典型的有: • 检查项目工作分解结构的各个子项。 • 基于风险分类进行风险评估。 • 访谈该专题领域的专家。 • 回顾相似产品的风险管理工作。 • 检查经验教训文档与资料库。 • 检查设计文档与协议需求。 工作产品实例 1. 已识别的风险列表,包括背景、条件和风险发生的后果 子实践 1. 识别与成本、进度和性能相关的风险。 应检查与成本、进度、性能以及其它业务目标相关的风险,以了解其对 项目目标的影响。也可能发现那些在项目范围之外但却对客户利益至关 重要的可能的风险。例如存在于开发成本、产品采购成本、产品备件成 本(或更换成本)以及产品的处置(或废弃)成本等中的风险。 客户可能并未充分考虑到产品现场支持或者使用某一服务的全部成本。 客户应当被告知这些风险的存在,但未必需要主动地去管理它们。在项 目和组织层面应检查其决策机制,如果觉得合适,就应将其落实到位, 尤其是当风险会影响到对产品进行验证和确认的能力时,更应如此。 除了上述的成本风险以外,可能还有与拨款级别、拨款估算以及预算分 配相关的其它成本风险。 进度风险包含了与已经计划的活动、关键事件与里程碑等相关的风险。 性能风险可能与以下内容相关: • 需求 • 分析与设计 • 新技术的使用 • 物理尺寸 • 形状 • 重量 • 生产制造 • 与功能或质量属性相关的产品表现与操作 • 验证 • 确认 • 性能维护属性 性能维护属性是指那些能令使用中的产品或服务提供其所需性能的特性, 如维护安全性和保密性水平。 风险管理(RSKM) 295 CMMI 开发模型,版本 1.3 有些风险不属于成本、进度或性能类风险,而是与组织运营的其它方面 相关。 例如,其它类风险可能包括与如下因素相关的风险: • 罢工 • 供应来源的减少 • 技术周期 • 竞争 SP 2.2 2. 评审可能影响项目的环境因素。 项目经常会忽略那些被认为不在项目范围内的风险(即项目不能控制该 风险的发生,但能够降低其影响),这些风险包括天气或自然灾害、政 局变化以及通讯中断。 3. 评审工作分解结构的所有子项,将其作为风险识别的一部分,以确保 这些工作内容得到了全方位的考量。 4. 评审项目计划的所有子项,将其作为风险识别的一部分,以确保项目 得到了全方位的考量。 参阅“项目计划”过程域以进一步了解如何识别项目风险。 5. 将每个风险的背景、条件与潜在的后果文档化。 风险描述通常以标准的格式记录,包括风险背景、条件与产生的后果。 对于那些引发关注、疑虑或不确定性的风险,风险背景提供了风险的额 外信息,例如风险的相关时间范围、风险所处的形势与条件。 6. 识别与各个风险相关的相关干系人。 评价、分类风险并划分风险优先级 用已定义的风险类别与参数,对识别出的每个风险进行评价与分类, 并确定其相对优先级。 需要进行风险评价,以指定各已识别风险的相对重要性,并决定何时需给 予其适当的管理层关注。依据风险的相互关系将风险聚集起来,并在一定 的聚集层级上开发方案,往往会起到一定作用。当一个风险是由较低层级 的风险向上聚集而成时,必须小心谨慎以确保未忽视重要的低层级风险。 风险评价、分类及优先级划分活动有时也被统称为“风险评估”或“风险 分析”。 工作产品实例 1. 风险及其优先级的清单 子实践 1. 用定义的风险参数评价已识别的风险。 依据已定义的风险参数评价每个风险并赋予其特定的参数值,这些参数 可包含可能性、后果(即严重性、影响)以及阈值。可对这些赋予的风 险参数值进行整合,以产生额外的度量项,如风险暴露值(即可能性与 后果的结合)等,可用于确定处理风险的优先顺序。 通常会用一个有 3 到 5 个数值的标尺来评价可能性与后果。 296 风险管理(RSKM) CMMI 开发模型,版本 1.3 SG 3 例如,可能性可以分为微乎其微、不太可能、可能、非常可能、近乎确 定。 后果的类别实例有: •低 •中 •高 • 可忽略的 • 轻微的 • 重大的 • 关键的 • 灾难性的 经常采用概率值来对可能性进行量化。后果通常与成本、进度、环境影 响或人员的度量项相关(如损失的工时、人身伤害的严重程度)。 风险评价往往是一项困难和耗时的工作,可能需要特定的专业知识或分 组技术来评估风险和达成比较可信的优先级划分。另外,随着时间的变 化,可能需要重新评价优先级。可以将风险的后果货币化,以提供一个 对已识别风险变成现实后的影响进行比较的基础。 2. 依照已定义的风险类别,将风险分类并分组。 将风险按定义的风险类别分类,提供了一个按照风险的来源、类别或项 目组件来评审风险的方法。可将相关或等效的风险归为一组,以便提高 处理效率。应将相关风险间的因果关系文档化。 3. 划分风险的缓解优先级。 根据每项风险被赋予的风险参数,确定风险的相对优先级。应使用清晰 的准则来确定风险优先级。风险优先级有助于确定将风险缓解的资源投 入哪个领域最为有效,能够最大化对项目的正面影响。 缓解风险 风险得到适当的处理与缓解,以降低其对目标达成产生的不利影响。 处理风险的步骤包含制订风险处理方案、监督风险、当超过已定义的阈值 时执行风险处理活动。对选定的风险制订并实施风险缓解计划,以主动降 低风险发生的潜在影响。风险缓解计划还可包含应急计划,以应对当缓解 措施未能阻止该风险的发生时所造成的影响。风险管理策略定义了用于触 发风险处理措施的风险参数。 SP 3.1 制订风险缓解计划 依照风险管理策略,制订风险缓解计划。 风险缓解计划的一个关键环节就是制订备选行动方案、临时应对措施、回 退点以及为每个关键风险制订推荐的行动方案。对每个给定风险的风险缓 解计划包含一系列技术与方法,用于避免、减轻与控制风险发生可能性, 或者风险发生时导致的损害范围(有时被称为“应急计划”),或者兼顾 两者。监督风险,当其超出设定的阈值时,执行风险缓解计划,以使受影 响的部分回归到可接受的风险水平。如果风险不能被缓解,可以执行应急 风险管理(RSKM) 297 CMMI 开发模型,版本 1.3 计划。通常只针对后果为严重或不可接受的风险制订风险缓解与应急计划, 对于其它风险可能是接受并仅仅监督即可。 处理风险的备选方案通常有: • 风险规避:改变或降低需求,但仍符合最终用户的需要 • 风险控制:采取积极措施使风险最小化 • 风险转移:重新分配需求以降低风险 • 风险监督:关注风险并定期重新评价其在指定参数上的变化 • 风险接受:承认风险但不采取措施 通常,尤其是针对高影响度的风险,应制订多种风险处理方法。 例如,在破坏运行连续性的事件中,风险管理方法应包括建立: • 资源预留以响应操作中断事件 • 可用的备用设备清单 • 关键员工的后备人员 • 应急响应系统测试计划 • 公告的应急步骤 • 公布的应急关键联络人与信息资源的清单 风险在很多情况下会被接受或关注。当判定风险很低而不必做正式地缓解 时,或者似乎没有可行措施来降低风险时,该风险通常会被接受。接受风 险时,应将做出该决策的理由文档化。当风险存在一个客观定义的、可验 证的已文档化阈值(如对成本、进度、性能、风险暴露值),并且该阈值 会触发缓解计划或者应急计划时,该风险才会被关注。 参阅“决策分析与解决”过程域以进一步了解如何评价并选择备选方案。 作为风险缓解计划活动的一部分,应尽早充分考虑技术展示、模型、模拟、 试用与原型。 工作产品实例 1. 每个已识别风险的文档化的处理方案 2. 风险缓解计划 3. 应急计划 4. 负责跟踪与应对每个风险的人员列表 子实践 1. 确定级别与阈值,以定义何时风险是不可接受的,以及执行风险缓解 计划或应急计划的触发条件。 风险级别(通过风险模型导出)是一个结合了达成目标的不确定性与没 有达成目标的后果的度量项。 风险级别与阈值设定了已计划的或可接受的成本、进度或性能的边界值, 应清晰地理解并定义风险级别以提供一个了解风险的方法为了确保基于 严重性的风险优先级划分与来自相关管理层的响应,风险的适当分类是 非常必要的。可设定多重阈值,以启动不同等级的管理者响应。通常, 触发风险缓解计划的阈值会设定在触发应急计划的阈值之前。 2. 识别负责应对每个风险的人员或团体。 3. 确定执行每个风险的风险缓解计划的成本与收益。 298 风险管理(RSKM) CMMI 开发模型,版本 1.3 SP 3.2 应检查风险缓解活动所提供的收益及其会消耗的资源。正如其它任何设 计活动一样,可能需要制订备选计划,并评估每个备选计划的成本与收 益。选择实施最适当的计划。 4. 为项目制订总体的风险缓解计划,以协调单个风险缓解与应急计划的 实施。 整套风险缓解计划的集合可能是超出负担范围的。应执行权衡分析以排 定执行风险缓解计划的优先级。 5. 针对选取的关键风险,制订当其影响变为现实时的应急计划。 必要时应制订并执行风险缓解计划,以主动地在风险变为问题前降低其 风险。尽管做出了很大的努力,某些风险可能仍然无法避免,并成为影 响项目的问题。对于关键风险可以制订应急计划,以描述当风险的影响 发生时项目可以采取的措施。其意图是定义一个主动的计划以处理风险。 风险或者被减轻(缓解)或者被处理(应急)。这两种情况下,风险都 得到了管理。 有些风险管理文献可能把应急计划作为风险缓解计划的同义词或是一部 分。这些计划也可能作为风险应对计划或者风险行动计划一起描述。 实施风险缓解计划 定期监督每个风险的状态,并适当地实施风险缓解计划。 为在工作期间有效地控制与管理风险,须遵守事先安排的计划,定期监督 风险以及风险处理措施的状态与结果。风险管理策略定义了检视风险状态 的时间间隔。该行动可能导致发现新的风险,或者可能需要重新计划或评 估风险处理方案。在上述任何一种情况下,应比较与风险相关的可接受性 阈值与风险的状态,以决定是否需要执行风险缓解计划。 工作产品实例 1. 更新的风险状态清单 2. 更新的风险可能性、后果与阈值评估 3. 更新的风险处理方案清单 4. 更新的已采取的风险处理措施的清单 5. 风险处理方案的风险缓解计划 子实践 1. 监督风险状态。 在风险缓解计划启动后,仍然要监督风险。评估阈值以检查是否要执行 应急计划。 应使用某种监督机制。 2. 提供方法,以跟踪未完成的风险处理措施直至关闭。 参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施直至关 闭。 3. 当监督的风险超过预定阈值时,启动选定风险的处理方案。 通常,仅对被判定为高或中的风险执行风险处理。对于给定风险的风险 处理策略可以包括规避、减轻与控制风险可能性的技术与方法,或者规 避、减轻与控制风险发生时产生的破坏程度的技术与方法,或者二者兼 而有之。在这种情况下,风险处理既包含了风险缓解计划,也包含了应 急计划。 风险管理(RSKM) 299 CMMI 开发模型,版本 1.3 开发风险处理技术以规避、减轻与控制对项目目标的负面影响,并根据 可能的影响产出可接受的结果。为处理风险而制定的行动措施需要在计 划与进度基线中安排适当的资源。重新计划需要密切考虑其对于相邻的 或有依赖关系的工作或活动的影响。 4. 针对每个风险处理行动,建立其执行的进度或时间段,包括起始日期 与预期的完成日期。 5. 对每个计划提供持续的资源承诺,以使风险处理行动能够顺利实施。 6. 收集风险处理行动的绩效度量。 300 风险管理(RSKM) CMMI 开发模型,版本 1.3 供方协议管理(SAM) 成熟度 2 级项目管理类过程域 目的 简介 供方协议管理(Supplier Agreement Management,SAM)的目的在于管 理从供方采购产品与服务的活动。 本过程域的范围涉及如何采购可以交付给项目客户或包含在一个产品或 服务系统中的产品、服务以及产品、服务组件。本过程域的实践也可以用 于其它使项目获益的目的(例如,购买消费品)。 本过程域并不能涵盖商用现货(commercial off-the-shelf,COTS)采购的 所有场景,但却能应用于需要对项目有显著价值或意味着项目重要风险的 COTS 组件、政府现货组件或免费软件进行修改的情况。 在各个过程域中使用到的术语“产品”与“产品组件”,其含义也包含了 服务、服务系统以及它们的组件。 “供方协议管理”过程域包括以下活动: • 确定采购类型 • 选择供方 • 建立并维护与供方的协议 • 执行供方协议 • 接受所采购产品的交付 • 确保成功地移交所采购的产品 本过程域主要说明交付给项目客户的产品及产品组件的采购。 可由项目采购的产品及产品组件的实例有: • 子系统(例如,机载导航系统) • 软件 • 硬件 • 文档(例如,安装、操作及用户手册) • 零件与材料(例如,测量仪器、开关、轮子、钢材、原材料) 为使项目风险最小,本过程域也可用于采购那些并不交付给项目客户,而 是用于开发与维护产品或服务的重要产品及产品组件(如开发工具和测试 环境)。 通常,在计划与开发的早期阶段就要确定将由项目采购的产品。 技术解决方案过程域提供了确定可以向供方采购的产品及产品组件的实 践。 本过程域并不直接关注将供方集成到项目团队的安排,在这样的安排中供 方使用与项目团队成员一样的过程,报告给相同的管理层(例如集成化的 团队)。通常,这些情况由其他过程或职能(例如,项目管理过程、项目 供方协议管理(SAM) 301 CMMI 开发模型,版本 1.3 相关过程域 之外的过程或职能)来处理(解决),尽管本过程域的部分特定实践可用 于管理这类的供方协议。 典型情况下,本过程域并不用于处理项目客户也是供方的情况。这种情况 通常是通过与客户的非正式协议或与项目客户的整体协议中加入客户提 供的细节条款来处理。对于后者,本过程域的部分特定实践可用于管理协 议,而其它则可能不行,这是因为与客户的关系和与平常供方的关系有着 本质上的不同。可参阅 CMMI-ACQ 模型以进一步了解其它协议类型的有 关信息。 根据业务需要的不同,供方可能采取多种形式,包括内部(in-house)供 方(即在同一组织内但是在项目之外的供方)、制造部门、复用库的供方 以及商业供方。(见术语表中“供方”的定义。) 建立供方协议来管理组织与供方之间的关系。供方协议是在组织(代表项 目)与供方之间任何形式的书面协议。该协议可以是合同、许可证、服务 水平协议或协议备忘录。采购的产品由供方依据供方协议交付给项目。(见 术语表中“供方协议”的定义。) 参阅“技术解决方案”过程域以进一步了解如何执行自制、购买或复用分 析。 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“项目监督与控制”过程域以进一步了解如何对照计划监督项目,并 管理纠正措施直至关闭。 参阅“需求管理”过程域以进一步了解如何维护需求的双向可追溯性。 302 供方协议管理(SAM) CMMI 开发模型,版本 1.3 SG 1 建立供方协议 SP 1.1 确定采购类型 SP 1.2 选择供方 SP 1.3 建立供方协议 SG 2 履行供方协议 SP 2.1 执行供方协议 SP 2.2 接受采购的产品 SP 2.3 确保产品移交 按目标排列的特定实践 特定目标与特定实践摘要 SG 1 建立供方协议 与供方的协议得到建立与维护。 SP 1.1 确定采购类型 为要采购的每一个产品或产品组件确定采购类型。 参阅“技术解决方案”过程域以进一步了解如何执行自制、购买或复用分 析。 对于项目所用产品与产品组件的采购,有多种不同的采购类型可供选择。 采购类型的实例有: • 购买对于项目具有显著价值的、修改后的 COTS 产品 • 通过供方协议获得产品 • 从内部供方获得产品 • 从客户获得产品 • 从首选的供方获得产品 • 上述某些类型的组合(例如,合同采购某个 COTS 产品的修改,同时由企 业的另一部分与外部供方合作开发产品) SP 1.2 如果采购对于项目具有显著价值的或意味着重大项目风险的、修改后的 COTS 产品,就要注意评估和选择这些产品和供方,这对项目来说是关键 所在。在选择决策时要考虑专利权问题和产品的可获得性等方面。 工作产品实例 1. 待采购产品与产品组件将采用的采购类型清单 选择供方 评价供方满足规定需求与已建立准则的能力,并以此为基础选择供方。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“需求管理”过程域以进一步了解如何获得对需求的承诺。 应当建立准则来阐明对项目重要的各项因素。 供方协议管理(SAM) 303 CMMI 开发模型,版本 1.3 对项目重要的因素,实例有: • 供方的地理位置 • 供方在类似工作上的绩效记录 • 工程能力 • 可用于执行工作的人员和设施 • 以往在类似情形中的经验 • 客户对供方交付的类似产品的满意程度 工作产品实例 1. 市场研究 2. 候选供方列表 3. 首选供方列表 4. 评价准则的权衡分析或其他记录、候选供方的优劣势以及供方选择的 依据 5. 招标材料与需求 子实践 1. 建立评价潜在供方的准则并将其文档化。 2. 识别潜在的供方并向其分发招标资料与需求。 实施本活动的主动方式是进行市场研究,以识别要采购的候选产品的潜 在来源,包括定制产品的候选供方和 COTS 产品的供方。 3. 按照评价准则评价建议书。 4. 评价与每个被提议的供方相关的风险。 参阅“风险管理”过程域以进一步了解如何识别并分析风险。 5. 评价被提议的供方执行工作的能力。 用于评价被提议供方执行工作能力的方法,实例有: • 评价以往在类似应用上的经验 • 评价以往在所提供类似产品上的客户满意度 • 评价以往类似工作的绩效 • 评价管理能力 • 能力评价 • 评价可用于执行该工作的人员 • 评价可用的设施与资源 • 评价项目与被提议的供方共同工作的能力 • 评价候选 COTS 产品对项目计划与承诺的影响 304 供方协议管理(SAM) CMMI 开发模型,版本 1.3 当评价修改的 COTS 产品时,考虑如下因素: • 修改的 COTS 产品成本 • 将修改的 COTS 产品纳入项目的成本与工作量 • 安全性需求 • 产品未来发布可能带来的收益与影响 SP 1.3 修改的 COTS 产品的未来发布可以提供额外的功能,用以支持项目已计 划或预期的增强特性,但是可能导致供方不再支持其当前的发布。 6. 选择供方。 建立供方协议 建立并维护供方协议。 供方协议是组织(代表项目)和供方之间任何形式的书面协议。该协议可 以是合同、许可证、服务水平协议或协议备忘录。 供方协议的内容应当明确说明如下安排:选择要监督、分析及评价的供方 的过程和工作产品,以上安排对于本次采购或采购的产品要适当。供方协 议还应当明确说明要实施的评审、监督、评价和验收测试。 应当监督对于项目成功至关重要(例如,因其复杂性、重要性)的供方过 程。 通常,独立法人实体之间的供方协议要经过法律或合同顾问的评审之后才 能获得批准。 工作产品实例 1. 工作说明书 2. 合同 3. 协议备忘录 4. 许可协议 子实践 1. 必要时修订将由供方满足的需求(例如,产品需求、服务水平需求), 以反映与供方协商的结果。 参阅“需求开发”过程域以进一步了解如何开发产品需求。 参阅“需求管理”过程域以进一步了解如何管理项目的产品与产品组件 需求,并确保那些需求与项目计划和工作产品间的协调一致。 2. 将项目需要提供给供方的内容文档化。 包括以下内容: • 项目提供的设施 • 文档 • 服务 3. 将供方协议文档化。 供方协议应包括工作说明书、规格说明、条款与条件、交付物清单、进 度、预算以及已定义的验收过程。 供方协议管理(SAM) 305 CMMI 开发模型,版本 1.3 本子实践通常包括以下任务: • 识别项目对供应商监察的类型与深度,识别用于监督供应商绩效的规 程和标准,包括对要监督的过程和要评价的产品的选择 • 建立工作说明书、规格说明、条款与条件、交付物清单、进度、预算 及验收过程 • 识别项目与供方中负责并有权对供方协议进行变更的人员 • 识别如何确定、沟通并处理需求变更和供方协议变更 • 识别将要遵循的标准与规程 • 识别项目与供方之间的关键依赖 • 识别与供方一同进行的评审类型 • 识别供方对所采购产品进行后继维护和支持的职责 • 识别所采购产品的保修、所有权以及使用权 • 识别验收准则 在某些情况下,选择修改的 COTS 产品可能不仅需要产品许可证中的协 议,还需要供方协议。在与 COTS 供方的协议中可能涵盖的内容实例有: • 大量购买的折扣 • 许可协议之下涵盖的相关干系人,包括项目供方、团队成员和项目客 户 • 未来功能增强的计划 • 现场支持,例如对询问和问题报告的响应 • 其它未包含在产品中的能力 • 维护支持,包括产品退出通用可获得性状态时的支持 4. 定期评审供方协议以确保其准确反映项目与供方的关系和当前风险 以及市场状况。 5. 在实施协议或任何变更之前,确保供方协议的各方均理解和同意所有 需求。 6. 必要时修订供方协议以反映供方过程或工作产品的变更。 7. 修订项目计划和承诺,包括必要时变更项目过程或工作产品以反映供 方协议。 参阅“项目监督与控制”过程域以进一步了解如何监督承诺。 306 供方协议管理(SAM) CMMI 开发模型,版本 1.3 SG 2 履行供方协议 与供方的协议得到项目与供方双方的履行。 SP 2.1 执行供方协议 与供方共同执行供方协议中规定的活动。 参阅“项目监督与控制”过程域以进一步了解如何提供对项目进展的了解, 以在项目绩效显著偏离计划时采取适当的纠正措施。 工作产品实例 1. 供方的进展报告与绩效度量 2. 供方评审材料与报告 3. 跟踪至关闭的行动项 4. 产品与文档交付物 子实践 1. 按照供方协议中的规定,监督供方的进展与绩效(例如,进度、工作 量、成本以及技术性能)。 2. 按照供方协议中的规定,选择、监督并分析供方所使用的过程。 应监督对项目成功至关重要(例如,因其复杂性、重要性)的供方过程。 选择要监督的过程应考虑该选择对供方的影响。 3. 按照供方协议中的规定,选择并评价供方提供的工作产品。 被选中接受评价的产品应当包括关键的产品、产品组件和工作产品,以 便尽可能早地洞察质量问题。在低风险的情况下,可能没有必要选择什 么工作产品进行评价。 4. 按照供方协议中的规定,与供方一同进行评审。 参阅“项目监督与控制”过程域以进一步了解如何进行里程碑评审,以 及如何进行进展评审。 评审包含正式和非正式评审,并包括以下步骤: • 准备评审 • 确保相关干系人的参与 • 进行评审 • 确定、记录并跟踪所有行动项直至关闭 • 准备评审总结报告并将其分发给相关干系人 5. 按照供方协议的规定,与供方一同进行技术评审。 技术评审通常包括: • 适当地使供方了解项目客户与最终用户的需要与期望 • 评审供方的技术活动并验证供方对需求的理解和实施与项目组相一 致 • 确保技术承诺得到了满足,并及时沟通和解决技术问题 • 获得有关供方产品的技术信息 • 向供方提供适当的技术信息与支持 供方协议管理(SAM) 307 CMMI 开发模型,版本 1.3 6. 按照供方协议的规定,与供方一同进行管理评审。 管理评审通常包括: • 评审关键依赖 • 评审涉及供方的项目风险 • 评审进度与预算 • 评审供方对法律法规要求的符合性 SP 2.2 技术与管理评审可以结合在一起协调举行。 7. 使用评审结果来改进供方的绩效,并建立和培育与首选供方的长期关 系。 8. 监督涉及供方的风险并在必要时采取纠正措施。 参阅“项目监督与控制”过程域以进一步了解如何监督项目风险。 接受采购的产品 在接受所采购的产品前,确保供方协议得到履行。 在接受供方协议中规定的产品之前,应完成验收评审、测试以及配置审计。 工作产品实例 1. 验收规程 2. 验收评审或测试结果 3. 偏差报告或纠正措施计划 子实践 1. 定义验收规程。 2. 在验收评审或测试之前,与相关干系人一同评审验收规程并获得一致 认可。 3. 验证所采购的产品满足其需求。 参阅“验证”过程域以进一步了解如何验证选定的工作产品。 4. 确定与采购工作产品相关的非技术承诺已经得到满足。 这种确定活动可以包括确定适当的许可证、保修、所有权、使用和支持 或维护协议已就绪,并且收到所有支持资料。 5. 将验收评审或测试的结果文档化。 6. 对任何未通过验收评审或测试的所采购工作产品,建立行动计划并获 得供方的认同以采取措施加以纠正。 7. 识别、文档化并跟踪行动项直至关闭。 参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施直至关 闭。 308 供方协议管理(SAM) CMMI 开发模型,版本 1.3 SP 2.3 确保产品移交 确保采购自供方的产品的移交。 在将所采购的产品移交给项目、客户或最终用户之前,应进行适当的准备 与评价,以确保平滑的移交。 参阅“产品集成”过程域以进一步了解如何装配产品组件。 工作产品实例 1. 移交计划 2. 培训报告 3. 支持与维护报告 子实践 1. 确保存在适当的设施以接收、存储、集成和维护所采购的产品。 2. 确保向参与接收、存储、集成和维护所采购产品的人员提供了适当的 培训。 3. 确保所采购产品的存储、分发和集成符合供方协议或者许可证中规定 的条款与条件。 供方协议管理(SAM) 309 CMMI 开发模型,版本 1.3 310 供方协议管理(SAM) CMMI 开发模型,版本 1.3 技术解决方案(TS) 成熟度 3 级工程类过程域 目的 简介 技术解决方案(Technical Solution,TS)的目的在于选择、设计并实现对 需求的解决方案。解决方案、设计与实现包括单独的或以适当形式组合的 产品、产品组件以及与产品相关的生命周期过程。 “技术解决方案”过程域适用于产品架构的任一层级和每一个产品、产品 组件以及与产品相关的生命周期过程。在本过程域内,用到术语“产品” 与“产品组件”的地方,其预期的含义也包含服务、服务系统及其组件。 本过程域所关注的有: • 评价并选择解决方案(有时亦指“设计方法”、“设计概念”或“初 步设计”),这些解决方案可能满足所分配的功能性需求与质量属性 需求的适当集合 • 开发所选解决方案的详细设计(所谓详细指的是包含所有制造、编码 或其它将设计实现为产品或产品组件的必要信息) • 将设计实现为产品或产品组件 典型情况下,这些活动相互作用、相互支持。有些层级的设计,有时可能 需要相当详细,以用于选择解决方案。原型或试点可以作为一种手段,以 获得充分的知识,来开发技术资料包或完整的需求集合。可使用质量属性 模型、模拟、原型或试点来获得有关潜在设计解决方案方面的额外信息, 以帮助解决方案的选择。对于开发多系统构成的系统(systems-of-systems) 的项目,模拟可能尤其有效。 “技术解决方案”的特定实践不但适用于产品与产品组件,而且适用于与 产品相关的生命周期过程。与产品相关的生命周期过程的开发配合产品或 产品组件进行。这类开发活动可以包括选择并修改供使用的现有过程(包 括标准过程)与开发新的过程。 与“技术解决方案”过程域相关联的过程从需求管理过程得到产品或产品 组件需求。需求管理过程将来源于需求开发过程的需求置于适当的配置管 理之下,并维护其到前期需求的可追溯性。 对于维护类或支持类项目,在维护行为或重设计活动中所需要的需求可能 由用户的需要、技术的成熟与陈旧、或者产品组件中的遗留缺陷驱动。操 作环境中的变化可能引发新的需求。这样的需求可能在产品的验证期间被 发现,此时其实际的性能可以与其规定的性能相比较,并可能识别出不可 接受的性能下降。应当将与“技术解决方案”过程域相关联的过程用于执 行维护类或支持类的设计工作。 对于产品线,这些实践既适用于核心资产的开发(即为复用进行构建), 也适用于产品的开发(即使用复用进行构建)。核心资产的开发还需要进 行产品线可变管理(产品线可变机制的选择与实现)以及产品线生产计划 (过程的制订与其它工作产品的开发,以定义如何构建产品以充分利用用 核心资产)。 技术解决方案(TS) 311 CMMI 开发模型,版本 1.3 在敏捷环境中,关注点是及早进行解决方案的探索。通过更明确地进行选择并 进行决策的权衡,“技术解决方案”过程域有助于提高决策的质量,无论其是 单独的还是长期的。解决方案可以用功能、特性集、发布或其它任何有助于产 品开发的成分进行定义。当团队之外的人员未来会从事产品方面的工作时,所 安装的产品中通常包括了发布信息、维护日志与其他数据。为了支持产品未来 的更新,要记录下(权衡、接口与所购买的部件的)依据,以便更好地理解为 什么会有该产品。如果所选的解决方案风险很低,就大大降低了将决策进行正 式记录的需要。(见第一部分中的“使用敏捷方法时对 CMMI 的解读”。) 相关过程域 参阅“需求开发”过程域以进一步了解如何分配产品组件需求、建立操作 概念与场景并识别接口需求。 参阅“验证”过程域以进一步了解如何执行同级评审并验证选定的工作产 品。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 参阅“组织级绩效管理”过程域以进一步了解如何选择改进并部署改进。 参阅“需求管理”过程域以进一步了解如何管理项目的产品与产品组件需 求,并确保那些需求与项目计划和工作产品间的协调一致。 312 技术解决方案(TS) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 选择产品组件解决方案 SP 1.1 开发备选解决方案与选择准则 SP 1.2 选择产品组件解决方案 SG 2 开发设计 SP 2.1 设计产品或产品组件 SP 2.2 建立技术数据包 SP 2.3 使用准则设计接口 SP 2.4 执行自制、购买或复用分析 SG 3 实现产品设计 SP 3.1 实现设计 SP 3.2 开发产品支持文档 按目标排列的特定实践 SG 1 选择产品组件解决方案 产品或产品组件解决方案得以从备选解决方案中选出。 在选择解决方案之前,备选解决方案与其相对长处得到了考虑。关键需求、 设计问题与约束得到了建立,用于备选解决方案的分析。支持达成质量属 性需求的架构选择与模式得到了考虑。同样地,商用现货(commercial off-the-shelf,COTS)产品组件的使用在比较了成本、进度、性能与风险 的情况下得到了考虑。COTS 的备选方案既可在修改后也可不加修改地予 以使用。有时这些 COTS 项需要在诸如接口或某些特性的定制方面加以修 改,以纠正与功能性需求或质量属性需求之间的不匹配,或与架构设计的 不匹配。 好的设计过程的一个标志是,设计是在对备选解决方案进行比较并评价之 后选择得到。架构决策、定制开发或是使用现货的决策、以及产品组件模 块化的决策是所应对的有代表性的设计选择。某些这样的决策可能要求使 用正式的评价过程。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 有时候,解决方案的搜索仅检查相同需求的备选实例,而无需对低一级产 品组件进行分配。这种情况出现在产品架构的底部。也有些情况,一个或 多个解决方案是已固定的(例如:已指定了具体的解决方案,或已调查了 如 COTS 等已具备的产品组件的使用)。 一般情况下,解决方案定义为一个集合。也就是说,当定义下一层次的产 品组件时,同时建立集合中的每一个产品组件的解决方案。备选解决方案 不仅是解决相同需求的不同方式,而且也体现了构成解决方案集合的产品 组件之间不同的需求分配。目标是将集合的整体进行优化,而不是单个组 件。与“需求开发”过程域的关联过程会有大量的相互作用,以支持至产 品组件的暂定的分配方案,直到选定解决方案集合并且建立最终分配。 从备选解决方案选择产品组件解决方案中包含有与产品相关的生命周期 过程。这些与产品相关的生命周期过程的实例有制造、交付与支持过程。 技术解决方案(TS) 313 CMMI 开发模型,版本 1.3 SP 1.1 开发备选解决方案与选择准则 开发备选解决方案与选择准则。 参阅“需求开发”过程域中的“分配产品组件需求”特定实践以进一步了 解如何取得至产品组件备选解决方案的需求的分配。 参阅“决策分析与解决”过程域以进一步了解如何建立评价准则。 应当进行备选解决方案的识别与分析,以能够选出在整个产品生命期中成 本、进度、性能与风险等方面取得平衡的解决方案。这些解决方案基于所 提议的产品架构,这样一些产品架构解决了关键的产品质量属性需求,并 且遍及可行解决方案的设计空间。与“开发设计”特定目标相关联的特定 实践提供进一步的信息,说明如何开发潜在的产品架构,并结合到产品的 备选解决方案之中。 备选解决方案经常包含至不同产品组件的备选需求分配方案。这些备选解 决方案可以包括在产品架构中使用 COTS 解决方案。之后,再使用与“需 求开发”过程域相关联的过程,来提供更完整且更健壮的、至备选解决方 案的暂定需求分配方案。 备选解决方案遍及成本、进度与性能的可接受范围。产品组件需求被接收, 并与设计事项、约束和准则一起用于开发备选解决方案。进行选择的准则 通常应对了成本(例如:时间、人员、金钱)、收益(例如:产品性能、 能力、有效性)以及风险(例如:技术、成本、进度)。在备选解决方案 方面的考虑点与选择准则有: • 开发、制造、采购、维护与支持的成本 • 关键质量属性需求的达成,诸如产品及时性、安全性、可靠性与可维 护性 • 产品组件的复杂度以及与产品相关的生命周期过程 • 产品操作与使用条件的健壮程度、操作模式、环境、以及与产品相关 的生命周期过程的变动情况 • 产品扩展与增长 • 技术限制 • 对建造方法与材料的敏感度 • 风险 • 需求与技术的演化 • 废弃 • 最终用户与操作人员的能力与局限 • COTS 产品的特性 列在这里的考虑点是是一个基本集合;组织应当制订与其业务目标相一致 的过滤准则,以缩小备选解决方案清单的范围。尽管产品生命周期成本是 一项值得尽可能缩减的参数,但该参数可能并不在开发组织的控制范围内。 客户可能不愿意为短期内导致成本更高,但在产品生命期内最终会降低成 本的特性付费。在这种情况下,至少应当告知客户降低生命周期成本的潜 在可能。用于选择最终解决方案的准则应当是平衡了成本、收益与风险的 方法。 工作产品实例 1. 备选解决方案的过滤准则 2. 新技术的评价报告 3. 备选解决方案 314 技术解决方案(TS) CMMI 开发模型,版本 1.3 SP 1.2 4. 最终选择结果的选择准则 5. COTS 产品的评价报告 子实践 1. 识别过滤准则,以选择可供考虑的备选解决方案集合。 2. 识别当前所使用的技术与获得竞争优势的新产品技术。 参阅“组织级绩效管理”过程域以进一步了解如何选择改进并部署改进。 项目应当识别适用于当前产品及过程的技术,并且监督当前所用技术在 项目生命期内的发展。项目应当识别、选择、评价并投资于新技术,以 取得竞争优势。备选解决方案可以包含新技术,但也可包含将成熟的技 术进行不同的应用,或者维持当前的方法。 3. 识别满足需求的候选 COTS 产品。 参阅“供方协议管理”过程域以进一步了解如何选择供方。 COTS 产品的供方所需要满足的需求有: • 产品功能与质量属性 • 产品质保的条款与条件 • 有助于在产品的持续维护与支持方面减轻供方责任的期望(例如:评 审活动方面的)、约束或检查点 4. 识别可复用解决方案组件或适用的架构模式。 对于产品线,组织的核心资产可作为解决方案的基础。 5. 形成备选解决方案。 6. 获得各备选方案的完整的需求分配方案。 7. 制订用于选择最佳备选解决方案的准则。 应当包含解决产品生命期中设计问题的准则,如更方便地导入新技术、 或更有能力地利用商用产品的条款。实例包括与所评价的备选方案的开 放式设计或开放式架构概念相关的准则。 选择产品组件解决方案 基于选择准则,选择产品组件解决方案。 参阅“需求开发”过程域中的“分配产品组件需求”与“识别接口需求” 特定实践以进一步了解如何建立产品组件的已分配的需求与产品组件之 间的接口需求。 选择最佳满足准则的产品组件,就建立了对产品组件的需求分配方案。选 定的备选方案又形成了低一级的需求,并被用于开发产品组件设计。产品 组件之间的接口被描述。在至产品外部的产品接口与活动接口的文档中应 包含物理接口的描述。 要将解决方案的描述与选择的依据进行文档化。开发过程中解决方案与详 细设计被开发出来,并实现了这些设计,贯穿在这样的开发过程中,解决 方案文档也要不断演进。维护选择依据的记录对于下游的决策意义重大。 这类记录防止了下游干系人的重复劳动,并随着技术在所适用场合中的具 备而能够提供对应用该技术的洞察力。 工作产品实例 1. 选择产品组件的决策与依据 技术解决方案(TS) 315 CMMI 开发模型,版本 1.3 SG 2 2. 需求与产品组件之间文档化了的关系 3. 文档化的解决方案、评价与依据 子实践 1. 对照以操作概念与场景为背景而建立的选择准则,评价各备选解决方 案或解决方案的集合。 为各备选解决方案开发产品操作与用户交互的时间轴场景。 2. 依据备选方案的评价,评估选择准则的充分性,并在必要时更新准则。 3. 识别并解决备选解决方案与需求方面的问题。 4. 选择能满足已建立的选择准则的备选解决方案最佳集合。 5. 建立与选定的备选方案集合相关联的功能性需求与质量属性需求,作 为至那些产品组件的已分配需求的集合。 6. 识别将复用或采购的产品组件解决方案。 参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和 服务的活动。 7. 建立并维护解决方案、评价与依据的文档。 开发设计 产品或产品组件设计得到开发。 产品或产品组件设计不但应当为实现提供合适的内容,而且应为诸如修改、 重新采购、维护、支持与安装等产品生命周期其它阶段提供合适的内容。 设计文档为支持相关干系人对设计的相互理解提供了参考,并且支持未来 在开发期间以及产品生命周期后续阶段对设计的变更。完整的设计描述得 以文档化在技术数据包中,技术数据包含有特性与参数的完整范围,包括 外形、安装匹配、功能、接口、制造工艺特性以及其它参数。已建立的组 织级或项目级的设计标准(例如:检查单、模板、对象框架)形成基础, 以达成设计文档的高规格定义与设计文档的完整性。 SP 2.1 设计产品或产品组件 开发产品或产品组件的设计。 产品设计大致由两个执行时可重叠的阶段组成:初步设计与详细设计。初 步设计建立产品能力与产品架构,包括架构风格与模式、产品分块、产品 组件标识、系统状态与模式、主要的组件间接口,以及产品外部接口。详 细设计则完全地定义了产品组件的结构与能力。 参阅“需求开发”过程域中的“建立必需的功能与质量属性的定义”特定 实践以进一步了解如何开发架构需求。 架构定义由在需求开发过程期间所开发的架构需求集合所驱动。这些需求 识别了对产品的成功有重要作用的质量属性。随着产品设计细节的建立, 架构定义了结构上的元素与协调机制,这些元素与机制要么直接满足需求, 要么支持需求的达成。架构可以包含支配产品组件与其接口开发的标准与 设计规则,以及辅助产品开发人员的指南。“选择产品组件解决方案”特 定目标中的特定实践包含如何使用产品架构作为备选解决方案基础的进 一步说明。 架构师提出设想并开发产品的模型,做出判断,将功能性需求与质量属性 需求分配给包括硬件与软件的产品组件。可以开发并分析支持备选解决方 案的多个架构以确定在架构需求方面的优势与劣势。 316 技术解决方案(TS) CMMI 开发模型,版本 1.3 操作概念以及操作的、支持的与开发的场景被用于形成用例以及与质量属 性相关的场景,用于对架构进行细化。在产品设计中定期执行的架构评价 过程中,它们也作为手段用以评价架构对其预期目的的适合程度。 参阅“需求开发”过程域中的“建立操作概念与场景”特定实践以进一步 了解如何开发操作概念与场景用于架构评价。 架构定义任务的实例有: • 建立分块的结构关系,以及有关分块内的元素之间接口的规则,以及有关 分块之间接口的规则 • 选择支持功能性需求与质量属性需求的架构模式,并将那些模式实例化, 或组成那些模式,以建立产品架构 • 识别主要的内部接口与所有的外部接口 • 识别产品组件,以及产品组件之间的接口 • 使用架构描述语言,正式定义组件行为与交互作用 • 定义协调机制(例如:对软件的、硬件的) • 建立基础能力与服务 • 开发产品组件模板,或者类与框架 • 建立设计规则与进行决策的职权 • 定义过程/线程模型 • 定义将软件向硬件的物理分配 • 识别主要的复用途径与来源 在详细设计期间,产品架构细节被最终确定,产品组件被完整定义,并且 接口的特征被完全描述。可以针对特定质量属性优化产品组件设计。设计 者可以对遗留产品或 COTS 产品用作产品组件的决策进行评价。随着设计 的成熟,要追踪分配给低一级产品组件的需求,以确保可以满足那些需求。 参阅“需求管理”过程域以进一步了解如何确保项目工作与需求之间的协 调一致。 对于软件工程,详细设计关注于软件产品组件的开发。通过定义产品组件 的内部结构,形成数据模式,开发算法,建立探试法等,以为产品组件提 供满足已分配需求的能力。 对于硬件工程,详细设计关注于电子的、机械的、电光的以及其它硬件产 品及其组件的产品开发。电气原理图与连接图被开发,机械与光学装配模 型被生成,生产与装配工艺被制订。 工作产品实例 1. 产品架构 2. 产品组件的设计 子实践 1. 建立并维护准则,据此可以对设计进行评价。 技术解决方案(TS) 317 CMMI 开发模型,版本 1.3 除了期望的产品性能,可用于建立设计准则的质量属性实例有: • 模块化 • 清晰 • 简洁 • 可维护 • 可验证 • 便携 • 可靠 • 准确 • 安全 • 可扩充 • 易用 2. 识别、开发或采购适用于产品的设计方法。 有效的设计方法可以包含活动、工具及描述性技术等广阔范围。某种方 法是否有效依赖于具体情况。两家公司可能各自拥有其所专长的有效的 产品设计方法,但这些方法可能在合营企业并不有效。高度成熟的方法 在那些未得到方法使用方面的培训的设计者手里,也未必一定有效。 方法是否有效也依赖于其给设计者提供了多大的帮助,以及该帮助的成 本有效性。例如,多年的原型投入可能不适用于简单的产品组件,但对 于前所未有的、昂贵的且复杂的产品开发则也许是正确的事情。然而, 快速原型技术可以非常有效地用于许多产品组件。有些方法使用工具来 确保设计将包含实现产品组件设计所必需的所有必要属性,这些方法也 可以是有效的。例如,“了解”制造工艺能力的设计工具可以在设计容 限中容许制造工艺的偏差。 可促进有效设计的技术与方法的实例有: • 原型法 • 结构模型 • 面向对象的设计 • 实质的系统分析 • 实体关系模型 • 设计的复用 • 设计模式 3. 确保设计遵循所适用的设计标准与准则。 318 技术解决方案(TS) CMMI 开发模型,版本 1.3 设计标准的实例有(这些标准的一部分或全部可以是设计准则,特别是 在标准尚未建立的场合): • 操作员接口标准 • 测试场景 • 安全标准 • 设计约束(例如:电磁兼容、信号集成、环境) • 生产约束 • 设计容限 • 部件标准(例如:生产废料、浪费) SP 2.2 4. 确保设计遵循已分配的需求。 应当考虑已识别的 COTS 产品组件。例如,若要将已有的产品组件放到 产品架构中,也许就修改了需求与需求分配方案。 5. 将设计文档化。 建立技术数据包 建立并维护技术数据包。 技术数据包为开发者提供所开发产品或产品组件的全面描述。这样的数据 包也为诸如绩效保证式合约(performance based contracting)或设计蓝 本式制造(build-to-print)等各种情况提供了采购方面的灵活性。(见术 语表中“技术数据包”的定义。) 在创建初步设计、进行架构定义的文档化的过程中,设计被记录在技术数 据包中。在产品的整个生命期中,要维护该技术数据包,记录下产品设计 的重要细节。技术数据包提供了产品或产品组件(包括未作为单独的产品 组件处理的与产品相关的生命周期过程)的描述,支持了采购策略、或产 品生命周期的实现、生产、工程与物流支持阶段。这样的描述包括必需的 设计配置与规程的定义,以确保产品或产品组件性能方面的充分性。它包 括所有适用的技术数据,诸如绘图、相关联的清单、规格说明、设计描述、 设计数据库、标准、质量属性需求、质量保证条款与打包细节。技术数据 包中含有挑选进行实现的所选定备选解决方案的描述。 由于设计描述可能包含大量数据,且又对成功的产品组件开发起关键作用, 所以建立组织数据与选择数据内容的准则是可取的。特别有效的是以产品 架构为手段,来组织这些数据,并抽象出清晰的且与某问题点或所关心的 特性相关的视图。这些视图有: • 客户 • 需求 • 环境 • 功能 • 逻辑 • 安全 • 数据 • 状态/模式 • 建造 • 管理 技术解决方案(TS) 319 CMMI 开发模型,版本 1.3 SP 2.3 这些视图文档化在技术数据包中。 工作产品实例 1. 技术数据包 子实践 1. 确定设计层次的数量,以及每一设计层次适当的文档水平。 确定需要进行文档化、并要求需求可追溯的产品组件层次的数量(例如: 子系统、硬件配置项、电路板、计算机软件配置项[computer software configuration item,CSCI]、计算机软件产品组件、计算机软件单元等) 对于管理文档的成本并支持集成计划与验证计划来说是重要的。 2. 确定用于进行架构文档化的视图。 视图被选择用以记录产品的内在结构并应对特定干系人的关注点。 3. 将设计的详细描述建立在已分配的产品组件需求、架构与上一级设计 的基础之上。 4. 将设计文档化在技术数据包中。 5. 文档化所做出的或所定义的关键(即:对成本、进度或技术性能产生 显著影响的)决策,并包括其依据。 6. 必要时修订技术数据包。 使用准则设计接口 使用所建立的准则设计产品组件的接口。 接口的设计有: • 起源 • 目标 • 软件的刺激源(stimulus)与数据特征,包括次序方面的约束或协议 • 处理特定刺激源所耗费的资源 • 对错误的或超出规定限度之外的刺激源的例外处理或出错处理行为 • 硬件的电气的、机械的与功能的特征 • 通信的服务线路 接口的准则通常体现了应当得到定义、或至少得到调查的关键参数,以确 保其适用性。这些参数通常是给定的产品类型(例如:软件、机械、电气、 服务)所特有的,并通常与安全性、安保性、耐久性以及任务关键性特性 相关联。 参阅“需求开发”过程域中的“识别接口需求”特定实践以进一步了解如 何识别产品与产品组件的接口需求。 工作产品实例 1. 接口设计规格说明 2. 接口控制文档 3. 接口规格说明准则 4. 所选接口设计的依据 子实践 1. 定义接口准则。 320 技术解决方案(TS) CMMI 开发模型,版本 1.3 SP 2.4 这些准则可以是组织级过程资产的一部分。 参阅“组织级过程定义”过程域以进一步了解如何建立并维护一套可用 的组织级过程资产与工作环境标准。 2. 识别与其它产品组件相关联的接口。 3. 识别与外部项相关联的接口。 4. 识别产品组件和与产品相关的生命周期过程之间的接口。 举例来说,这类接口可能包括那些在待制作产品组件与制造过程中用于 使制作成为可能的钻模与固定装置之间的接口。 5. 将准则用于接口设计备选方案。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的 决策。 6. 将选定的接口设计与选择的依据文档化。 执行自制、购买或复用分析 依据所建立的准则,评价产品组件是应当自行开发、还是购买或者复 用。 通常将确定采购哪些产品或产品组件的过程称之为“自制或购买分析”。 这基于对项目需要的分析。自制或购买分析开始于项目早期的第一次设计 迭代期间;在设计过程中继续进行;完成于对产品的开发、采购或复用的 决策。 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“需求管理”过程域以进一步了解如何管理需求。 影响自制或购买决策的因素有: • 产品将提供的功能,以及如何将这些功能融入到项目中 • 可用的项目资源与技能 • 采购成本与内部开发成本的对比 • 关键的交付与集成日期 • 战略上的业务联盟,包括高层次的业务需求 • 已具备产品的市场研究,包括 COTS 产品 • 已具备产品的功能与质量 • 潜在供方的技能与能力 • 对核心竞争力的影响 • 与待采购产品相关联的许可、质保、责任与限制 • 产品的具备程度 • 专有事项 • 风险的降低 • 在需要与产品线核心资产之间的匹配度 可以采用正式评价方法来进行自制或购买决策。 参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程, 遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决 策。 技术解决方案(TS) 321 CMMI 开发模型,版本 1.3 技术在演化,产品组件的开发或购买的选择依据也会随之演化。尽管复杂 的开发工作可能更支持采购现货产品组件,但在生产率及工具方面的进步 可能会给出相反的依据。现货产品的文档可能不完整或不准确,并且将来 是否能够得到支持也是未知数。 一旦做出采购现货产品组件的决策,如何实施该决策则依赖于待采购项的 类型。有时候“现货”所指的既有产品并不能拿来就用,因为必须先进行 定制以满足采购方规定的特殊的性能需求与所采购的其它产品特性(例如 飞机发动机)。为了管理这类采购,需建立包含这些需求与应满足的验收 准则的供方协议。在其它情况下,现货产品是真正的现货(例如字处理软 件),不存在需要管理的与供方的协议。 参阅“供方协议管理”过程域中的“建立供方协议”特定目标以进一步了 解如何处理供方协议,以修改 COTS 产品。 工作产品实例 1. 设计与产品组件复用的准则 2. 自制或购买分析 3. 选择 COTS 产品组件的指南 子实践 1. 制订复用产品组件设计的准则。 2. 分析设计,以确定产品组件应该开发、复用还是采购。 3. 对已购买项或非开发项(例如:COTS、政府现货、复用)进行考虑 时,分析维护的含义。 维护的含义实例有: • 与未来所发布的 COTS 产品的兼容性 • 供方变更的配置管理 • 非开发项与其解决方案中的缺陷 • 计划外的淘汰 SG 3 实现产品设计 产品组件与相关支持文档,按照设计得以实现。 产品组件的实现按照“开发设计”特定目标中的特定实践所建立的设计进 行。实现通常包括在送交产品集成之前对产品组件所进行的单元测试,以 及最终用户文档的开发。 SP 3.1 实现设计 实现产品组件的设计。 完成设计后,即将其实现成为产品组件。实现的特性依赖于产品组件的类 型。 在产品层次结构顶层的设计实现,涉及对产品层次结构下一个层次的各产 品组件进行规格说明。这一活动包括各产品组件的分配、细化与验证。它 还涉及产品组件的各种开发工作之间的协调。 参阅“产品集成”过程域以进一步了解如何管理接口并装配产品组件。 322 技术解决方案(TS) CMMI 开发模型,版本 1.3 参阅“需求开发”过程域以进一步了解如何分配产品组件需求,并分析需 求。 这样的实现,其特征的实例有: • 软件得到编码。 • 数据得到文档化。 • 服务得到文档化。 • 电气的与机械的部件得到制作。 • 独特的产品生产工艺得到投入使用。 • 工艺得到文档化。 • 设施得到建造。 • 材料得到生产(例如:独特的产品材料可以是石油、机油、润滑剂、新型 合金等)。 工作产品实例 1. 已实现的设计 子实践 1. 使用有效的方法进行产品组件的实现。 软件编码方法的实例有: • 结构化编程 • 面向对象编程 • 面向方面的编程 • 自动化代码生成 • 软件代码复用 • 使用合适的设计模式 硬件实现方法的实例有: • 门电路水平的合成 • 电路板版图设计(位置与布线) • 计算机辅助设计绘图 • 版图设计后的模拟 • 制造方法 2. 遵循适用的标准与准则。 技术解决方案(TS) 323 CMMI 开发模型,版本 1.3 实现标准的实例有: • 语言标准(例如:软件编程语言标准、硬件描述语言标准) • 绘图需求 • 标准件清单 • 生产件 • 软件产品组件的结构与层次 • 工艺与质量标准 准则的实例有: • 模块化 • 清晰性 • 简洁性 • 可靠性 • 安全性 • 可维护性 3. 对选定的产品组件执行同级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 4. 适当地执行产品组件的单元测试。 注意,单元测试不局限于软件。单元测试涉及在集成之前的单个硬件或 软件单元的测试,或一组相关项的测试。 参阅“验证”过程域以进一步了解如何验证选定的工作产品。 单元测试方法(手工的或自动的)的实例有: • 语句覆盖测试 • 分支覆盖测试 • 断言覆盖测试 • 路径覆盖测试 • 边界值测试 • 特殊值测试 单元测试方法的实例有: • 功能测试 • 辐射检查测试 • 环境测试 5. 必要时,修正产品组件。 产品组件何时可能需要修正,一个实例是在实现时发现了在设计期间不 能预见的问题。 324 技术解决方案(TS) CMMI 开发模型,版本 1.3 SP 3.2 开发产品支持文档 开发并维护最终使用文档。 本特定实践开发并维护将用于产品的安装、操作与维护的文档。 工作产品实例 1. 最终用户培训资料 2. 用户手册 3. 操作手册 4. 维护手册 5. 在线帮助 子实践 1. 对需求、设计、产品与测试结果进行评审,以确保影响安装、操作与 维护文档的问题得到识别与解决。 2. 使用有效的方法以开发安装、操作与维护文档。 3. 遵循所适用的文档标准。 文档标准的实例有: • 与指定的文字处理器兼容 • 可接受的字体 • 章、节、页编号规则 • 与指定的风格手册一致 • 缩写的使用 • 机密分类标识 • 国际化需求 4. 在项目生命周期的早期阶段,进行安装、操作与维护文档初步版本的 开发,以供相关干系人评审。 5. 进行安装、操作与维护文档的同级评审。 参阅“验证”过程域以进一步了解如何执行同级评审。 6. 必要时,修订安装、操作与维护文档。 文档何时可能需要修订,其实例包括下列所发生的事件: • 已进行需求的变更 • 已进行设计的变更 • 已进行产品的变更 • 已识别文档的错误 • 已识别修正的变通方案 技术解决方案(TS) 325 CMMI 开发模型,版本 1.3 326 技术解决方案(TS) CMMI 开发模型,版本 1.3 确认(VAL) 成熟度 3 级工程类过程域 目的 简介 确认(Validation,VAL)的目的在于证明产品或产品组件被置于预期环境 中时满足其预期用途。 “确认”活动可以应用于产品的各方面,并可用于任何预期的产品环境, 诸如运行、培训、制造、维护以及支持服务。完成确认所用的方法既能用 于工作产品,也能用于产品和产品组件(在各个过程域中使用到的术语“产 品”与“产品组件”,其含义也包含了服务、服务系统以及它们的组件)。 应该选择最能够预示产品与产品组件对最终用户需要的满足程度的工作 产品(如需求、设计、原型),因而在早期(概念/探索阶段)就应该执 行确认,并在整个产品生命周期(包括移交到运行和维持)中增量式地执 行。 确认环境应该代表产品与产品组件的预期环境,同时代表适于工作产品确 认活动的预期环境。 “确认”证明产品在提供时能满足其预期的用途,而“验证”处理的是工 作产品是否适当地体现了规定的需求。换言之,验证是确保“正确地做了 事”,而确认是确保“做了正确的事”。确认活动采用与验证类似的方法 (如测试、分析、审查、演示、模拟)。最终用户和其他相关干系人常常 参与确认活动。确认与验证活动常常同时进行并可以采用同一环境的组成 部分。 参阅“验证”过程域以进一步了解如何确保选定的工作产品满足其规定的 需求。 只要有可能,确认就应该通过在其预期环境中运行产品或工作产品来完成。 可以采用整个环境也可以只用一部分。然而不论如何,都可以在项目生命 早期通过与相关干系人一起使用工作产品来发现确认问题。针对服务的确 认活动可以应用于诸如方案建议书、服务目录、工作说明书和服务记录等 工作产品。 确认问题一经识别,就会由与“需求开发”、“技术解决方案”、“项目 监督与控制”等过程域相关联的过程加以解决。 本过程域中的特定实践之间的相互依赖关系如下: • “选择需要确认的产品”特定实践使得需要确认的产品或工作产品、 执行确认时需要采用的方法都得到识别。 • “建立确认环境”特定实践使得执行确认所用的环境得到确定。 • “建立确认规程与准则”特定实践使得确认规程与准则得到制订,并 且与选定的产品、客户对确认的约束、方法和确认环境的特性相一致。 • “执行确认”特定实践使得确认按照方法、规程与准则得到执行。 确认(VAL) 327 CMMI 开发模型,版本 1.3 相关过程域 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“技术解决方案”过程域以进一步了解如何选择、设计并实现对需求 的解决方案。 参阅“验证”过程域以进一步了解如何确保选定的工作产品满足其规定的 需求。 328 确认(VAL) CMMI 开发模型,版本 1.3 SG 1 准备确认 SP 1.1 选择需要确认的产品 SP 1.2 建立确认环境 SP 1.3 建立确认规程与准则 SG 2 确认产品或产品组件 SP 2.1 执行确认 SP 2.2 分析确认结果 按目标排列的特定实践 特定目标与特定实践摘要 SG 1 准备确认 确认的准备工作得以进行。 准备活动包括选择需要确认的产品与产品组件,以及建立并维护确认的环 境、规程与准则。选定的确认对象可以只包括产品,也可以包括被用于构 建产品的适当层级的产品组件。可以对任何产品或产品组件进行确认,例 如更换、维护和培训产品。 要准备好确认产品或产品组件所需的环境。环境可以是买来的,也可以是 通过规格制定、设计和构建来得到的。可以统筹考虑用于产品集成和验证 的环境与确认环境,从而降低成本并提高效率或生产力。 SP 1.1 选择需要确认的产品 选择待确认的产品与产品组件以及将采用的确认方法。 根据其与最终用户需要的关系来选择需要确认的产品与产品组件。应该确 定每一产品组件的确认范围(如操作行为、维护、培训、用户接口)。 可以确认的产品与产品组件的实例有: • 产品与产品组件的需求与设计 • 产品与产品组件(如系统、硬件单元、软件、服务文档) • 用户接口 • 用户手册 • 培训材料 • 过程文档 • 访问协议 • 数据交换报告格式 收集对执行确认的要求和约束,然后选择确认方法,选择的依据是它们是 否有能力证实最终用户的需要得到了满足。确认方法不仅定义了产品确认 的方法,也驱动了对设施、装备与环境的需要。确认方法和需要可以导致 产生更低层次的产品组件需求,这些需求由需求开发过程进行处理。也可 能产生诸如对测试装置和测试设备的接口需求等衍生需求。这些需求也被 传递到需求开发过程,以确保产品或产品组件能够在支持选定方法的环境 中得到确认。 在项目初期就应选定确认方法,从而使得相关干系人能够清晰地了解并认 可这些方法。 确认方法适当地处理产品或产品组件的开发、维护、支持与培训等。 确认(VAL) 329 CMMI 开发模型,版本 1.3 确认方法的实例有: • 与最终用户讨论,可能采用正式评审方式 • 原型演示 • 功能演示(如系统、硬件单元、软件、服务文档、用户接口) • 培训材料的试用 • 由最终用户与其他相关干系人执行的产品与产品组件测试 • 增量式交付能工作并可能被接受的产品 • 对产品与产品组件的分析(如模拟、建模、用户分析) 硬件的确认活动包括对电子或机械产品组件进行以下活动:建模以确认外形、 配合和机械设计的功能;热建模;可维护性与可靠性分析;时间线演示;以及 电路设计模拟。 工作产品实例: 1. 选定的需要确认的产品与产品组件清单 2. 每一产品或产品组件的确认方法 3. 对每一产品或产品组件执行确认的需求 4. 确认每一产品或产品组件时的约束 子实践 1. 识别在整个项目生命期内确认产品或产品组件的关键原则、特性与阶 段。 2. 确定需要确认哪些类别的最终用户需要(操作、维护、培训或支持)。 产品或产品组件应该能在其预期运行环境中得到维护与支持。本特定实 践也适用于可以随产品交付的实际的维护、培训与支持服务。 在运行环境中评价维护概念的一个实例是证明维护工具适用于真实的产 品。 SP 1.2 3. 选择需要确认的产品与产品组件。 4. 选择产品或产品组件确认的评价方法。 5. 与相关干系人一起评审确认的选择、约束与方法。 建立确认环境 建立并维护支持确认所需的环境。 选定的产品或产品组件、工作产品的类型(如设计、原型、最终版本)、 以及确认的方法共同驱动了对确认环境的需求。这些选择可以导致关于购 买或者开发设备、软件或其它资源的需求。这些需求被提交给需求开发过 程以供开发。确认环境可以包括对现有资源的重复利用。在这种情形下, 应当对这些资源的利用作出安排。 330 确认(VAL) CMMI 开发模型,版本 1.3 确认环境中各类元素的实例有: • 与被确认产品有接口的测试工具(如观测仪器、电子设备、探测仪) • 临时嵌入的测试软件 • 用于数据转储或者后继分析与重放的记录工具 • 模拟的子系统或组件(如软件、电子设备、机械设备) • 模拟的接口系统(如测试舰载雷达用的仿真战舰) • 真实的接口系统(如测试具有轨迹跟踪设施的雷达时所用的飞机) • 其它设施与客户提供的产品 • 操作或使用上列元素的熟练人员 • 特定的计算或网络测试环境(如为真实的集成与确认试验而建设的可以虚 拟操作的电信网络测试设施,其中有实际的干线、交换机和其它系统) SP 1.3 为确保确认环境能够在需要时可供使用,应该提早选定需要确认的产品或 产品组件、确认中将用到的工作产品以及确认的方法。 应该仔细地控制确认环境,从而为复制、结果分析以及问题部分的再次确 认做好准备。 工作产品实例 1. 确认环境 子实践 1. 识别确认环境的需求。 2. 识别客户提供的产品。 3. 识别测试设备与工具。 4. 识别可供重复利用与改造的确认资源。 5. 详细计划各项资源的可用性。 建立确认规程与准则 建立并维护确认规程与准则。 为确保产品或产品组件被置于预期环境中时满足其预期用途,要定义确认 规程与准则。验收测试的测试用例与规程可以被用作确认规程。 确认规程与准则包括对维护、培训和支持服务的测试与评价。 确认准则的来源实例有: • 产品与产品组件需求 • 标准 • 客户的验收准则 • 环境性能 • 性能偏差的阈值 工作产品实例 1. 确认规程 2. 确认准则 3. 对维护、培训和支持服务的测试与评价规程 确认(VAL) 331 CMMI 开发模型,版本 1.3 SG 2 子实践 1. 评审产品需求,以确保影响产品或产品组件确认的问题得到识别与解 决。 2. 将确认选定产品或产品组件的环境、操作场景、规程、输入、输出以 及准则文档化。 3. 随着设计在确认环境中的成熟而进行设计评估,以识别确认问题。 确认产品或产品组件 产品或产品组件得到确认,以确保它们适用于预期的运行环境。 在适当的确认环境中,采用确认方法、规程与准则来确认选定的产品与产 品组件,以及任何相关的维护、培训与支持服务。确认活动的执行贯穿整 个产品生命周期。 SP 2.1 执行确认 对选定的产品与产品组件执行确认。 产品或产品组件在其预期的运行环境中的表现应该符合预期,从而使干系 人能够接受。 按照已建立的方法、规程与准则执行确认活动并收集结果数据。 应当将实际执行的(as-run)确认规程文档化,并适当地记录执行中产生 的偏差。 工作产品实例 1. 确认报告 2. 确认结果 3. 确认的交叉引用矩阵 4. 规程实际执行中(as-run)产生的日志 5. 操作性的演示 SP 2.2 分析确认结果 分析确认活动的结果。 对照预定的确认准则分析在确认测试、审查、演示或评价中得出的数据。 分析报告表明需要是否得到了满足。在有不足的情形下,这些报告记录了 成功或者失败的程度,并将可能的失败原因进行分类。将收集到的测试、 审查或评审结果与已建立的评价准则进行比较,以确定是继续前进,还是 先在需求开发或技术解决方案过程中处理需求或设计问题。 分析报告或者实际执行的(as-run)确认文档也可能表明测试结果不良的 原因是确认规程问题还是确认环境问题。 工作产品实例 1. 确认不足报告 2. 确认问题 3. 规程变更请求 子实践 1. 对比实际结果与期望的结果。 332 确认(VAL) CMMI 开发模型,版本 1.3 2. 基于已建立的确认准则,识别在其预期的运作环境中表现不当的产品 与产品组件,或者识别方法、准则或环境中的问题。 3. 分析确认数据以寻找缺陷。 4. 记录分析结果并识别问题。 5. 利用确认结果,将实际度量和性能与预期的使用或操作需要相比较。 6. 提供关于如何解决缺陷的信息(包括确认方法、准则与确认环境)并 启动纠正措施。 参阅“项目监督与控制”过程域以进一步了解如何管理纠正措施。 确认(VAL) 333 CMMI 开发模型,版本 1.3 334 确认(VAL) CMMI 开发模型,版本 1.3 验证(VER) 成熟度 3 级工程类过程域 目的 简介 验证(Verification,VER)的目的在于确保选定的工作产品满足其规定的 需求。 “验证”过程域涉及验证的准备、验证的执行以及纠正措施的识别。 “验证”包括按照所有选定的需求对产品和中间工作产品进行的验证,这 里的需求包括客户需求、产品需求和产品组件需求。对于产品线来说,还 应该验证核心资产及其相关的产品线适应性变化机制。在各个过程域中使 用到的术语“产品”与“产品组件”,其含义也包含了服务、服务系统以 及它们的组件。 验证本身是一个增量式的过程,因为它贯穿产品与工作产品开发的整个过 程,始于对需求的验证,随着对逐步演进的工作产品的验证而进展,结束 于对完整产品的验证。 本过程域中的特定实践之间的相互依赖关系如下: • “选择需要验证的工作产品”特定实践使得需要验证的工作产品、执 行验证时需要采用的方法以及每一选定的工作产品应满足的需求都得 到识别。 • “建立验证环境”特定实践使得执行验证所用的环境得到确定。 • “建立验证规程与准则”特定实践使得验证规程与准则得到制订,并 且与选定的工作产品、需求、方法和验证环境的特性相一致。 • “执行验证”特定实践按照可用的方法、规程与准则进行验证。 对工作产品的验证充分地提升了产品满足客户需求、产品需求和产品组件 需求的可能性。 “验证”与“确认”两个过程域是类似的,不过处理的是不同的问题。“确 认”证实产品在被提供时(或者在其将被提供时)能满足其预期的用途, 而“验证”处理的是工作产品是否适当地体现了规定的需求。换言之,验 证是确保“正确地做了事”,而确认是确保“做了正确的事”。 同级评审是验证的重要部分,也是经过证明的消除缺陷的有效机制。一个 重要的作用是更好地理解工作产品以及产生这些工作产品的过程,从而预 防缺陷并识别过程改进的机会。 同级评审引入了制作者的同级人员对工作产品的系统检查,以识别缺陷和 需要的其它变更。 同级评审方法的实例有: • 审查 • 结构化走查 • 审慎地重构 • 结对编程 验证(VER) 335 CMMI 开发模型,版本 1.3 在敏捷环境中,由于客户的介入和频繁的发布,验证与确认是相互支持的。例 如,一个缺陷可能导致对原型或早期发布的确认提早失败。相反,早期并持续 的确认有助于确保对正确的产品实施验证。“验证”与“确认”过程域有助于 确保采用系统化的方法来选择将要评审和测试的工作产品、将要采用的方法与 环境以及将要管理的接口,这些都有助于确保尽早识别并处理缺陷。产品越复 杂,就需要系统化程度越高的方法来确保需求与解决方案之间的相容性,以及 与产品未来用途的一致性。(见第一部分中的“使用敏捷方法时对 CMMI 的 解读”。) 相关过程域 参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、 产品需求与产品组件需求。 参阅“确认”过程域以进一步了解如何证明产品或产品组件被置于预期环 境中时满足其预期用途。 参阅“需求管理”过程域以进一步了解如何确保项目工作与需求之间的协 调一致。 336 验证(VER) CMMI 开发模型,版本 1.3 特定目标与特定实践摘要 SG 1 准备验证 SP 1.1 选择需要验证的工作产品 SP 1.2 建立验证环境 SP 1.3 建立验证规程与准则 SG 2 执行同级评审 SP 2.1 准备同级评审 SP 2.2 进行同级评审 SP 2.3 分析同级评审数据 SG 3 验证选定的工作产品 SP 3.1 执行验证 SP 3.2 分析验证结果 按目标排列的特定实践 SG 1 准备验证 验证的准备工作得以进行。 为确保产品与产品组件的需求、设计、开发计划与进度安排中包含了验证 方面的内容,有必要进行预先准备。验证包括对工作产品的选择、审查、 测试、分析以及演示。 验证方法包括但不限于审查、同级评审、审计、走查、分析、架构评估、 模拟、测试以及演示。同级评审被视为一种特定的验证方法,在特定目标 2 中包含了与其相关的实践。 准备工作中也必须对支持工具、测试设备与软件、模拟、原型与其它设施 进行定义。 SP 1.1 选择需要验证的工作产品 选择待验证的工作产品以及将采用的验证方法。 依据工作产品对满足项目目标与需求以及应对项目风险所起的作用,对工 作产品进行选择。 需要验证的工作产品可以包括与维护、培训以及支持服务相关的部分。在 验证方法中包含了对工作产品的验证要求。验证方法说明了工作产品的验 证方式,以及将用于验证某些特定的工作产品是否满足其需求的特定方法。 验证方法的实例有: • 软件架构评价与实现一致性评价 • 路径覆盖测试 • 负载、压力和性能测试 • 基于决策表的测试 • 基于功能分解的测试 • 测试用例复用 • 验收测试 • 持续集成(即尽早发现集成问题的敏捷方法) 系统工程中的验证通常包括为验证系统设计(以及分配)的充分性而进行的原 型、建模以及模拟。 验证(VER) 337 CMMI 开发模型,版本 1.3 硬件工程中的验证通常要求一种参数化的方法,要考虑多方面的环境条件(例 如压力、温度、振动、湿度)、各种输入范围(例如对于计划的标称输入电压 28V,应该额定为 20~32V),部件与部件之间的容限问题引入的偏差,以及 许多其它变量。硬件的验证一般要分别测试大部分变量,除非已经怀疑存在多 变量交互方面的问题。 SP 1.2 验证方法的选择通常始于对产品与产品组件需求的定义,以确保需求是可 验证的。验证方法还应该考虑到重复验证,以确保对工作产品的返工不会 导致意外的缺陷。供方应该参与选择验证方法,以确保项目选择的方法适 合供方的环境。 工作产品实例 1. 选定的需要验证的工作产品清单 2. 每一选定的工作产品的验证方法 子实践 1. 识别需要验证的工作产品。 2. 识别每一选定工作产品应满足的需求。 参阅“需求管理”过程域中的“维护需求的双向可追溯性”特定实践以 进一步了解如何将需求追溯到工作产品。 3. 识别可用的验证方法。 4. 定义将每一选定工作产品所用的验证方法。 5. 提交待验证工作产品、需满足需求和将采用方法的识别结果,以便与 项目计划进行集成。 参阅“项目计划”过程域以进一步了解如何制订项目计划。 建立验证环境 建立并维护支持验证所需的环境。 应建立环境来使验证能得以实行。验证环境可以通过采购、开发、复用、 修改或者通过前述方式的某种组合来得到,这取决于项目的需要。 所需环境的类型取决于选定的需验证工作产品和将采用的验证方法。同级 评审基本上只需要一些材料、评审员和一间屋子,而产品测试则可能需要 模拟器、仿真器、场景生成仪、数据还原工具、环境控制器以及与其它系 统的接口。 工作产品实例 1. 验证环境 子实践 1. 识别对验证环境的需求。 2. 识别可供复用或者修改的验证资源。 3. 识别验证设备与工具。 4. 获取验证支持设备和整套环境(如测试设备、软件)。 338 验证(VER) SG 2 CMMI 开发模型,版本 1.3 SP 1.3 建立验证规程与准则 建立并维护用于选定工作产品的验证规程与准则。 定义验证准则以确保工作产品满足其需求。 验证准则的来源实例有: • 产品与产品组件需求 • 标准 • 组织级方针 • 测试类型 • 测试参数 • 在质量与测试成本之间进行权衡的参数 • 工作产品类型 • 供方 • 方案建议书与协议 • 客户与开发人员一同对工作产品进行的评审 工作产品实例 1. 验证规程 2. 验证准则 子实践 1. 必要时制订一组全面的、集成化的工作产品与商用现货产品的验证规 程。 2. 必要时制订并细化验证准则。 3. 识别满足需求的预期结果、允许的容限和其它准则。 4. 识别支持验证所需要的设备与环境组件。 执行同级评审 对选定工作产品的同级评审得到执行。 同级评审引入了制作者的同级人员对工作产品的系统检查,以识别需消除 的缺陷并提出需要的其它修改建议。 同级评审是一种重要而有效的验证方法,通过审查、结构化走查或者其它 一些合议式的评审方法来实施。 同级评审主要被用于项目开发的工作产品,但也能被用于通常由支持团队 开发的其它工作产品,诸如文档与培训方面的工作产品等。 SP 2.1 准备同级评审 为选定工作产品的同级评审做准备。 同级评审的准备活动通常包括:识别应邀请来参加每一工作产品同级评审 的人员;识别应参加同级评审的关键评审员;准备并更新同级评审期间使 用的材料,诸如检查单和评审准则;以及安排同级评审进度。 工作产品实例 1. 同级评审的进度安排 验证(VER) 339 CMMI 开发模型,版本 1.3 2. 同级评审检查单 3. 工作产品的入口与出口准则 4. 要求再次同级评审的准则 5. 同级评审的培训材料 6. 待评审的选定工作产品 子实践 1. 确定将进行的同级评审的类型。 同级评审类型的实例有: • 审查 • 结构化走查 • 主动评审 • 架构实现一致性评价 2. 定义同级评审期间收集数据的要求。 参阅“度量与分析”过程域以进一步了解如何获得度量数据。 3. 建立并维护同级评审的入口与出口准则。 4. 建立并维护要求再次同级评审的准则。 5. 建立并维护检查单以确保工作产品得到一致的评审。 检查单涉及的事项的实例有: • 构建的规则 • 设计指南 • 完整性 • 正确性 • 可维护性 • 通用的缺陷类型 必要时修订检查单以适用于特定类型的工作产品和同级评审。检查单开 发者的同级人员和潜在的最终用户要评审这些检查单。 6. 编制详细的同级评审进度安排,包括同级评审培训日期和同级评审材 料准备就绪的日期。 7. 确保工作产品在分发前满足同级评审入口准则。 8. 将待评审工作产品和相关材料提前分发给参加人员,提前量要足够, 从而使同级评审参加者能进行充足的准备。 9. 适当地分配同级评审的角色。 340 验证(VER) CMMI 开发模型,版本 1.3 角色的实例有: • 领导者 • 读者 • 记录员 • 作者 10. 在进行同级评审之前先行评审工作产品,从而为同级评审做准备。 SP 2.2 SP 2.3 进行同级评审 对选定工作产品进行同级评审,并识别这些评审中发现的问题。 同级评审的目的之一是及早发现并消除缺陷。同级评审随着工作产品的开 发而增量式地执行。这些评审是结构化的,并且不是管理层评审。 可以对规格说明、设计、测试与实现等活动的关键工作产品,以及特定的 计划工作产品实施同级评审。 同级评审应该聚焦于被评审的工作产品,而非其制作者。 应该将同级评审期间发现的问题告知工作产品的主要开发人员以便进行 更正。 参阅“项目监督与控制”过程域以进一步了解如何对照计划监督项目。 同级评审应当体现以下指导原则:应当进行充分的准备,实施进程应该受 到管理与控制,应该记录一致并充分的数据(例如进行正式审查),并且 应该记录行动项。 工作产品实例 1. 同级评审结果 2. 同级评审发现的问题 3. 同级评审数据 子实践 1. 在同级评审中承担已分配的角色。 2. 识别工作产品中的缺陷和其它问题并将它们文档化。 3. 记录同级评审的结果,包括行动项。 4. 收集同级评审数据。 参阅“度量与分析”过程域以进一步了解如何获得度量数据。 5. 识别行动项,并将问题通知相关干系人。 6. 必要时,进行一次附加的同级评审。 7. 确保同级评审的出口准则得到满足。 分析同级评审数据 分析与同级评审的准备、实施与结果相关的数据。 参阅“度量与分析”过程域以进一步了解如何获得度量数据并分析度量数 据。 工作产品实例 1. 同级评审数据 验证(VER) 341 CMMI 开发模型,版本 1.3 2. 同级评审行动项 子实践 1. 记录与同级评审的准备、执行和结果相关的数据。 典型的数据有产品名称、产品规模、同级评审团队的组成、同级评审的 类型、每位评审员的准备时间、评审会议的时长、发现的缺陷数量、缺 陷的类型与来源等。也可以收集被评审的工作产品的其它信息,诸如规 模、开发阶段、被检查的操作模式、被评价的需求等。 2. 存储数据以供将来参考和分析。 3. 保护数据以避免同级评审数据遭到不恰当的使用。 不当使用同级评审数据的实例包括使用数据来评价人员的绩效以及将数 据用于归因判断。 4. 分析同级评审数据。 可以分析的同级评审数据的实例有: • 引入缺陷的阶段 • 对比准备时间或速度与预期时间或速度 • 对比缺陷数量与预期数量 • 发现的缺陷的类型 • 缺陷的成因 • 缺陷解决的影响 • 与某个缺陷相关的用户故事或案例研究 • 与缺陷相关的最终用户和客户 SG 3 验证选定的工作产品 对照其规定的需求,选定的工作产品得到验证。 使用适当的验证环境,采用验证方法、规程与准则来验证选定的工作产品 及相关的维护、培训与支持服务。验证活动应该在整个产品生命周期中进 行。同级评审作为一种特定的验证方法,在特定目标 2 中包含了与其相关 的实践。 SP 3.1 执行验证 对选定的工作产品执行验证。 对产品与工作产品的增量式验证促进了问题的及早发现,并能产生及早消 除缺陷的结果。验证的结果节省了与发现并解决问题相关的可观的故障隔 离与返工成本。 工作产品实例 1. 验证结果 2. 验证报告 3. 演示 4. 规程实际执行中(as-run)产生的日志 342 验证(VER) CMMI 开发模型,版本 1.3 SP 3.2 子实践 1. 对照其需求执行对选定工作产品的验证。 2. 记录验证活动的结果。 3. 识别从对工作产品的验证中得出的行动项。 4. 记录“实际执行(as-run)”的验证方法,及其执行中发现的与可用 方法和规程的差异。 分析验证结果 分析所有验证活动的结果。 应该将实际结果与已建立的验证准则进行对比,以确定可接受度。 将分析结果作为已经进行验证的证据记录下来。 对于每一工作产品,增量式地分析所有可用的验证结果,以确保需求已经 得到了满足。由于同级评审也是若干种验证方法之一,前述分析活动中也 应该包含同级评审的数据,以确保对验证结果进行了充分的分析。 分析报告或者“实际执行(as-run)”方法的文档也可能表明验证结果不 良的原因是方法问题、准则问题还是验证环境问题。 工作产品实例 1. 分析报告(如:性能统计、不合格品的原因分析、真实产品与模型的 行为比较、趋势) 2. 疑难问题报告 3. 关于验证方法、准则与环境的变更请求 子实践 1. 对比实际结果与期望的结果。 2. 基于已建立的验证准则,识别不满足其需求的产品,或者识别方法、 规程、准则与验证环境中的问题。 3. 分析缺陷数据。 4. 在报告中记录分析的全部结果。 5. 采用验证结果来将实际度量和性能与技术性能参数相比较。 6. 提供关于如何解决缺陷的信息(包括验证方法、准则与验证环境)并 启动纠正措施。 参阅“项目监督与控制”过程域以进一步了解如何采取纠正措施。 验证(VER) 343 CMMI 开发模型,版本 1.3 344 验证(VER) CMMI 开发模型,版本 1.3 第三部分 附录 345 CMMI 开发模型,版本 1.3 346 附录 A:参考资料 CMMI 开发模型,版本 1.3 Ahern 2005 Ahern 2008 Beck 2001 Chrissis 2011 Crosby 1979 Curtis 2009 Deming 1986 DoD 1996 Dymond 2005 EIA 2002a EIA 2002b 参考资料 Ahern, Dennis M.; Armstrong, Jim; Clouse, Aaron; Ferguson, Jack R.; Hayes, Will; & Nidiffer, Kenneth E. CMMI SCAMPI Distilled: Appraisals for Process Improvement. Boston, MA: Addison-Wesley, 2005. Ahern, Dennis M.; Clouse, Aaron; & Turner, Richard. CMMI Distilled: A Practical Introduction to Integrated Process Improvement, 3rd Edition. Boston: Addison-Wesley, 2008. Beck, Kent et. al. Manifesto for Agile Software Development. 2001. http://agilemanifesto.org/. Chrissis, Mary Beth; Konrad, Mike; & Shrum, Sandy. CMMI: Guidelines for Process Integration and Product Improvement, 3rd Edition. Boston: Addison-Wesley, 2011. Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain. New York: McGraw-Hill, 1979. Curtis, Bill; Hefley, William E.; & Miller, Sally A. The People CMM: A Framework for Human Capital Management, 2nd Edition. Boston, MA: Addison-Wesley, 2009. Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering, 1986. Department of Defense. DoD Guide to Integrated Product and Process Development (Version 1.0). Washington, DC: Office of the Under Secretary of Defense (Acquisition and Technology), February 5, 1996. https://www.acquisition.gov/sevensteps/library/dod-guide-to-int egrated.pdf. Dymond, Kenneth M. A Guide to the CMMI: Interpreting the Capability Maturity Model Integration, 2nd Edition. Annapolis, MD: Process Transition International Inc., 2005. Electronic Industries Alliance. Systems Engineering Capability Model (EIA/IS-731.1). Washington, DC, 2002. Government Electronics and Information Technology Alliance. Earned Value Management Systems (ANSI/EIA-748). New York, NY, 2002. http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FEIA748-B. 347 CMMI 开发模型,版本 1.3 EIA 2003 Forrester 2011 Gallagher 2011 GEIA 2004 Gibson 2006 Glazer 2008 Humphrey 1989 IEEE 1991 ISO 2005a ISO 2005b Electronic Industries Alliance. EIA Interim Standard: Systems Engineering (EIA/IS-632). Washington, DC, 2003. Forrester, Eileen; Buteau, Brandon; & Shrum, Sandy. CMMI for Services: Guidelines for Superior Service, 2nd Edition. Boston: Addison-Wesley, 2011. Gallagher, Brian; Phillips, Mike; Richter, Karen; & Shrum, Sandy. CMMI-ACQ: Guidelines for Improving the Acquisition of Products and Services, 2nd Edition. Boston: Addison-Wesley, 2011. Government Electronic Industries Alliance. Data Management (GEIA-859). Washington, DC, 2004. http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FGEI A+859-2009. 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. http://www.sei.cmu.edu/library/abstracts/reports/06tr004.cfm. Glazer, Hillel; Dalton, Jeff; Anderson, David; Konrad, Mike; & Shrum, Sandy. CMMI or Agile: Why Not Embrace Both! (CMU/SEI-2008-TN-003). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, November 2008. http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm. Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE, 1991. International Organization for Standardization. ISO 9000: International Standard. 2005. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_d etail.htm?csnumber=42180. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 20000-1 Information Technology – Service Management, Part 1: Specification; ISO/IEC 20000-2 Information Technology – Service Management, Part 2: Code of Practice, 2005. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=45086. 348 参考资料 CMMI 开发模型,版本 1.3 ISO 2006a ISO 2006b ISO 2007 ISO 2008a ISO 2008b ISO 2008c IT Governance 2005 Juran 1988 International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15504 Information Technology—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. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=45086. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 14764 Software Engineering – Software Life Cycle Processes – Maintenance, 2006. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=45086. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15939 Systems and Software Engineering—Measurement Process, 2007. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=45086. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 12207 Systems and Software Engineering—Software Life Cycle Processes, 2008. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=45086. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15288 Systems and Software Engineering—System Life Cycle Processes, 2008. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=45086. International Organization for Standardization. ISO 9001, Quality Management Systems—Requirements, 2008. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc _browse.htm?commid=53896. IT Governance Institute. CobiT 4.0. Rolling Meadows, IL: IT Governance Institute, 2005. http://www.isaca.org/Content/NavigationMenu/Members_and_ Leaders/COBIT6/Obtain_COBIT/Obtain_COBIT.htm. Juran, Joseph M. Juran on Planning for Quality. New York: Macmillan, 1988. 参考资料 349 CMMI 开发模型,版本 1.3 McFeeley 1996 McGarry 2001 Office of Government Commerce 2007a Office of Government Commerce 2007b Office of Government Commerce 2007c Office of Government Commerce 2007d Office of Government Commerce 2007e SEI 1995 SEI 2002 SEI 2006 SEI 2010a McFeeley, Robert. IDEAL: A User’s Guide for Software Process Improvement (CMU/SEI-96-HB-001, ADA305472). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, February 1996. http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm. 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, 2001. Office of Government Commerce. ITIL: Continual Service Improvement. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Design. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Operation. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Strategy. London, UK: Office of Government Commerce, 2007. Office of Government Commerce. ITIL: Service Transition. London, UK: Office of Government Commerce, 2007. Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995. Software Engineering Institute. Software Acquisition Capability Maturity Model (SA-CMM) Version 1.03 (CMU/SEI-2002-TR-010, ESC-TR-2002-010). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, March 2002. http://www.sei.cmu.edu/publications/documents/02.reports/02tr 010.html. CMMI Product Team. CMMI for Development, Version 1.2 (CMU/SEI-2006-TR-008, ADA455858). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, August 2006. http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm. CMMI Product Team. CMMI for Services, Version 1.3 (CMU/SEI-2010-TR-034). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, November 2010. http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm. 350 参考资料 CMMI 开发模型,版本 1.3 SEI 2010b SEI 2010c SEI 2011a SEI 2011b Shewhart 1931 CMMI Product Team. CMMI for Acquisition, Version 1.3 (CMU/SEI-2010-TR-032). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, November 2010. http://www.sei.cmu.edu/library/abstracts/reports/10tr032.cfm. Caralli, Richard; Allen, Julia; Curtis, Pamela; White, David; and Young, Lisa. CERT® Resilience Management Model, Version 1.0 (CMU/SEI-2010-TR-012). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, May 2010. http://www.sei.cmu.edu/library/abstracts/reports/10tr012.cfm. SCAMPI Upgrade Team. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1.3: Method Definition Document (CMU/SEI-2011-HB-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, expected January 2011. http://www.sei.cmu.edu/library/abstracts/reports/11hb001.cfm. SCAMPI Upgrade Team. Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.3) (CMU/SEI-2011-TR-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, expected January 2011. http://www.sei.cmu.edu/library/abstracts/reports/11tr001.cfm. Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: Van Nostrand, 1931. 信息保证/信息安全相关的原始资料 DHS 2009 DoD and DHS 2008 ISO/IEC 2005 NDIA 2008 Department of Homeland Security. Assurance Focus for CMMI (Summary of Assurance for CMMI Efforts), 2009. https://buildsecurityin.us-cert.gov/swa/proself_assm.html. Department of Defense and Department of Homeland Security. Software Assurance in Acquisition: Mitigating Risks to the Enterprise, 2008. https://buildsecurityin.us-cert.gov/swa/downloads/SwA_in_A cquisition_102208.pdf. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27001 Information Technology – Security Techniques – Information Security Management Systems – Requirements, 2005. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue _detail.htm?csnumber= 42103. NDIA System Assurance Committee. Engineering for System Assurance. Arlington, VA: NDIA, 2008. http://www.ndia.org/Divisions/Divisions/SystemsEngineering /Documents/Studies/SA-Guidebook-v1-Oct2008-REV.pdf. 参考资料 351 CMMI 开发模型,版本 1.3 352 参考资料 附录 B:缩略语 CMMI 开发模型,版本 1.3 ANSI API ARC CAD CAR CCB CL CM CMU CMF CMM CMMI CMMI-ACQ American National Standards Institute 美国国家标准学会 application program interface 应用程序接口 Appraisal Requirements for CMMI CMMI 评估需求 computer-aided design 计算机辅助设计 Causal Analysis and Resolution (process area) 原因分析与解决(过程域) configuration control board 配置控制委员会 capability level 能力等级 Configuration Management (process area) 配置管理(过程域) Carnegie Mellon University 卡内基梅隆大学 CMMI Model Foundation CMMI 模型基础 Capability Maturity Model 能力成熟度模型 Capability Maturity Model Integration 能力成熟度模型集成 CMMI for Acquisition CMMI 采购模型 缩略语 353 CMMI 开发模型,版本 1.3 CMMI-DEV CMMI-SVC CobiT COTS CPI CPM CSCI DAR DHS DoD EIA EIA/IS FCA FMEA GG CMMI for Development CMMI 开发模型 CMMI for Services CMMI 服务模型 Control Objectives for Information and related Technology 信息与相关技术的控制目标 commercial off-the-shelf 商用现货 cost performance index 成本绩效指数 critical path method 关键路径法 computer software configuration item 计算机软件配置项 Decision Analysis and Resolution (process area) 决策分析与解决(过程域) Department of Homeland Security 国土安全部 Department of Defense 国防部 Electronic Industries Alliance 电子工业协会 Electronic Industries Alliance/Interim Standard 电子工业协会/暂定标准 functional configuration audit 功能配置审计 failure mode and effects analysis 失效模式与影响分析 generic goal 通用目标 354 缩略语 GP IBM IDEAL IEEE INCOSE IPD-CMM IPM ISO ISO/IEC ITIL MA MDD ML NDIA OID 缩略语 CMMI 开发模型,版本 1.3 generic practice 通用实践 International Business Machines 国际商用机器公司 Initiating, Diagnosing, Establishing, Acting, Learning 初始,诊断,建立,行动,学习 Institute of Electrical and Electronics Engineers 电气与电子工程师学会 International Council on Systems Engineering 国际系统工程委员会 Integrated Product Development Capability Maturity Model 集成产品开发能力成熟度模型 Integrated Project Management (process area) 集成项目管理(过程域) International Organization for Standardization 国际标准化组织 International Organization for Standardization and International Electrotechnical Commission 国际标准化组织与国际电工委员会 Information Technology Infrastructure Library 信息技术基础架构库 Measurement and Analysis (process area) 度量与分析(过程域) Method Definition Document 方法定义文档 maturity level 成熟度级别 National Defense Industrial Association 国防工业协会 Organizational Innovation and Deployment (former process area) 组织级创新与部署(旧过程域) 355 CMMI 开发模型,版本 1.3 OPD OPF OPM OPP OT P-CMM PCA PERT PI PMC PP PPQA QFD QPM RD Organizational Process Definition (process area) 组织级过程定义(过程域) Organizational Process Focus (process area) 组织级过程关注(过程域) Organizational Performance Management (process area) 组织级绩效管理(过程域) Organizational Process Performance (process area) 组织级过程性能(过程域) Organizational Training (process area) 组织级培训(过程域) People Capability Maturity Model 人员能力成熟度模型 physical configuration audit 物理配置审计 Program Evaluation and Review Technique 项目评价与评审技术 Product Integration (process area) 产品集成(过程域) Project Monitoring and Control (process area) 项目监督与控制(过程域) Project Planning (process area) 项目计划(过程域) Process and Product Quality Assurance (process area) 过程与产品质量保证(过程域) Quality Function Deployment 质量功能展开 Quantitative Project Management (process area) 量化项目管理(过程域) Requirements Development (process area) 需求开发(过程域) 356 缩略语 REQM RSKM SA-CMM SAM SCAMPI SECAM SECM SEI SG SP SPI SSD SSE-CMM SW-CMM TS 缩略语 CMMI 开发模型,版本 1.3 Requirements Management (process area) 需求管理(过程域) Risk Management (process area) 风险管理(过程域) Software Acquisition Capability Maturity Model 软件采购能力成熟度模型 Supplier Agreement Management (process area) 供方协议管理(过程域) Standard CMMI Appraisal Method for Process Improvement 过程改进标准 CMMI 评估方法 Systems Engineering Capability Assessment Model 系统工程能力评估模型 Systems Engineering Capability Model 系统工程能力模型 Software Engineering Institute 软件工程研究所 specific goal 特定目标 specific practice 特定实践 schedule performance index 进度绩效指数 Service System Development (process area in CMMI-SVC) 服务系统开发(CMMI-SVC 过程域) Systems Security Engineering Capability Maturity Model 系统安全工程能力成熟度模型 Capability Maturity Model for Software or Software Capability Maturity Model 软件能力成熟度模型 Technical Solution (process area) 技术解决方案(过程域) 357 CMMI 开发模型,版本 1.3 VAL VER WBS Validation (process area) 确认(过程域) Verification (process area) 验证(过程域) work breakdown structure 工作分解结构 358 缩略语 CMMI 开发模型,版本 1.3 附录 C:CMMI 版本 1.3 项目参加人员 许多杰出人士作为产品团队的一员开发了 CMMI 版本 1.3 的几个模型。以 下列出的人员在 CMMI 版本 1.3 的开发中,参加了下面的一个或多个团队。 成员姓名后列出的是其当时成为团队成员时所代表的组织。 参与开发此模型的主要小组有: • CMMI 指导小组 • CMMI 服务模型顾问小组 • CMMI1.3 版协调团队 • CMMI1.3 版配置控制委员会 • CMMI1.3 版核心模型团队 • CMMI1.3 版翻译团队 • CMMI1.3 版高成熟度团队 • CMMI1.3 版采购模型小团队 • CMMI1.3 版服务模型小团队 • CMMI1.3 版 SCAMPI 升级团队 • CMMI1.3 版培训团队 • CMMI1.3 版质量团队 CMMI 指导小组 CMMI 指导小组指导并批准产品团队的计划,为重大的 CMMI 产品问题提 供咨询建议,确保各个利害关系方的参与,并批准模型的最终发布。 指导小组成员 • Alan Bemish, US Air Force • Anita Carleton, Software Engineering Institute • Clyde Chittister, Software Engineering Institute • James Gill, Boeing Integrated Defense Systems • John C. Kelly, NASA • Kathryn Lundeen, Defense Contract Management Agency • Larry McCarthy, Motorola, Inc. • Lawrence Osiecki, US Army • Robert Rassa, Raytheon Space and Airborne Systems (lead) • Karen Richter, Institute for Defense Analyses • Joan Weszka, Lockheed Martin Corporation • Harold Wilson, Northrop Grumman • Brenda Zettervall, US Navy CMMI 版本 1.3 项目参加人员 359 CMMI 开发模型,版本 1.3 指导小组的当然成员 • Mike Konrad, Software Engineering Institute • Susan LaFortune, National Security Agency • David (Mike) Phillips, Software Engineering Institute 指导小组的支持人员 • Mary Beth Chrissis, Software Engineering Institute (CCB) • Eric Hayes, Software Engineering Institute (secretary) • Rawdon Young, Software Engineering Institute (Appraisal program) CMMI 服务模型顾问小组 CMMI 服务模型顾问小组为产品开发小组提供服务业方面的建议。 • Brandon Buteau, Northrop Grumman Corporation • Christian Carmody, University of Pittsburgh Medical Center • Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM SED • Annie Combelles, DNV IT Global Services • Jeff Dutton, Jacobs Technology, Inc. • Eileen Forrester, Software Engineering Institute • Craig Hollenbach, Northrop Grumman Corporation (lead) • Bradley Nelson, Department of Defense • Lawrence Osiecki, US Army ARDEC • David (Mike) Phillips, Software Engineering Institute • Timothy Salerno, Lockheed Martin Corporation • Sandy Shrum, Software Engineering Institute • Nidhi Srivastava, Tata Consultancy Services • Elizabeth Sumpter, NSA • David Swidorsky, Bank of America CMMI 1.3 版协调团队 协调团队汇集了其他产品开发团队的成员,确保项目之间的协调性。 • Rhonda Brown, Software Engineering Institute • Mary Beth Chrissis, Software Engineering Institute • Eileen Forrester, Software Engineering Institute • Will Hayes, Software Engineering Institute • Mike Konrad, Software Engineering Institute • So Norimatsu, Norimatsu Process Engineering Lab, Inc. • Mary Lynn Penn, Lockheed Martin Corporation • David (Mike) Phillips, Software Engineering Institute (lead) • Sandy Shrum, Software Engineering Institute • Kathy Smith, Hewlett Packard • Barbara Tyson, Software Engineering Institute 360 CMMI 版本 1.3 项目参加人员 CMMI 开发模型,版本 1.3 • Rawdon Young, Software Engineering Institute • Mary Lynn Russo, Software Engineering Institute (non-voting member) CMMI 1.3 版配置控制委员会 配置控制委员会批准所有对 CMMI 资料的变更,包括模型、SCAMPI MDD 以及模型导论培训。 • Rhonda Brown, Software Engineering Institute • Michael Campo, Raytheon • Mary Beth Chrissis, Software Engineering Institute (lead) • Kirsten Dauplaise, NAVAIR • Mike Evanoo, Systems and Software Consortium, Inc. • Rich Frost, General Motors • Brian Gallagher, Northrop Grumman • Sally Godfrey, NASA • Stephen Gristock, JP Morgan Chase and Co. • Eric Hayes, Software Engineering Institute (non-voting member) • Nils Jacobsen, Motorola • Steve Kapurch, NASA • Mike Konrad, Software Engineering Institute • Chris Moore, US Air Force • Wendell Mullison, General Dynamics Land Systems • David (Mike) Phillips, Software Engineering Institute • Robert Rassa, Raytheon Space and Airborne Systems • Karen Richter, Institute for Defense Analyses • Mary Lou Russo, Software Engineering Institute (non-voting member) • Warren Schwomeyer, Lockheed Martin Corporation • John Scibilia, US Army • Dave Swidorsky, Bank of America • Barbara Tyson, Software Engineering Institute • Mary Van Tyne, Software Engineering Institute (non-voting member) • Rawdon Young, Software Engineering Institute CMMI 1.3 版核心模型团队 核心模型团队开发所有三个群集的模型资料。 • Jim Armstrong, Stevens Institute of Technology • Rhonda Brown, Software Engineering Institute (co-lead) • Brandon Buteau, Northrop Grumman • Michael Campo, Raytheon • Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM SED CMMI 版本 1.3 项目参加人员 361 CMMI 开发模型,版本 1.3 • Mary Beth Chrissis, Software Engineering Institute • Mike D’Ambrosa, Process Performance Professionals • Eileen Forrester, Software Engineering Institute • Will Hayes, Software Engineering Institute • Mike Konrad, Software Engineering Institute (co-lead) • So Norimatsu, Norimatsu Process Engineering Lab, Inc. • Mary Lynn Penn, Lockheed Martin Corporation • David (Mike) Phillips, Software Engineering Institute • Karen Richter, Institute for Defense Analyses • Mary Lynn Russo, Software Engineering Institute (non-voting member) • John Scibilia, US Army • Sandy Shrum, Software Engineering Institute (co-lead) • Kathy Smith, Hewlett Packard • Katie Smith-McGarty, US Navy CMMI 1.3 版翻译团队 翻译团队协调 CMMI 资料的翻译工作。 • Richard Basque, Alcyonix • Jose Antonio Calvo-Manzano, Universidad Politecnica de Madrid • Carlos Caram, Integrated Systems Diagnostics Brazil • Gonzalo Cuevas, Universidad Politecnica de Madrid • Mike Konrad, Software Engineering Institute • Antoine Nardeze, Alcyonix • So Norimatsu, Norimatsu Process Engineering Lab, Inc. (lead) • Steven Ou, Institute for Information Industry • Ricardo Panero Lamothe, Accenture • Mary Lynn Russo, Software Engineering Institute (non-voting member) • Winfried Russwurm, Siemens AG • Tomas San Feliu, Universidad Politecnica de Madrid CMMI 1.3 版高成熟度团队 高成熟度团队开发高成熟度模型资料。 • Dan Bennett, US Air Force • Will Hayes, Software Engineering Institute • Rick Hefner, Northrop Grumman • Jim Kubeck, Lockheed Martin Corporation • Alice Parry, Raytheon • Mary Lynn Penn, Lockheed Martin Corporation (lead) • Kathy Smith, Hewlett Packard • Rawdon Young, Software Engineering Institute 362 CMMI 版本 1.3 项目参加人员 CMMI 开发模型,版本 1.3 CMMI 1.3 版采购模型小团队 采购小团队为模型开发工作提供采购方面的专业知识。 • Rich Frost, General Motors • Tom Keuten, Keuten and Associates • David (Mike) Phillips, Software Engineering Institute (lead) • Karen Richter, Institute for Defense Analyses • John Scibilia, US Army CMMI 1.3 版服务模型小团队 服务小团队为模型开发工作提供服务方面的专业知识。 • Drew Allison, Systems and Software Consortium, Inc. • Brandon Buteau, Northrop Grumman • Eileen Forrester, Software Engineering Institute (lead) • Christian Hertneck, Anywhere.24 GmbH • Pam Schoppert, Science Applications International Corporation CMMI 1.3 版 SCAMPI 升级团队 SCAMPI 升级团队开发 CMMI 评估需求(Appraisal Requirements for CMMI,ARC)与 SCAMPI 方法定义文档(Method Definition Document, MDD)。 • Mary Busby, Lockheed Martin Corporation • Palma Buttles-Valdez, Software Engineering Institute • Paul Byrnes, Integrated System Diagnostics • Will Hayes, Software Engineering Institute (leader) • Ravi Khetan, Northrop Grumman • Denise Kirkham, The Boeing Company • Lisa Ming, BAE Systems • Charlie Ryan, Software Engineering Institute • Kevin Schaaff, Software Engineering Institute • Alexander Stall, Software Engineering Institute • Agapi Svolou, Software Engineering Institute • Ron Ulrich, Northrop Grumman CMMI 1.3 版培训团队 两 个 培 训 团 队 ( 一 个 负 责 CMMI-DEV 与 CMMI-ACQ , 另 一 个 负 责 CMMI-SVC)开发了模型培训资料。 ACQ 与 DEV 培训团队 • Barbara Baldwin, Software Engineering Institute • Bonnie Bollinger, Process Focus Management • Cat Brandt-Zaccardi, Software Engineering Institute CMMI 版本 1.3 项目参加人员 363 CMMI 开发模型,版本 1.3 • Rhonda Brown, Software Engineering Institute • Michael Campo, Raytheon • Mary Beth Chrissis, Software Engineering Institute (lead) • Stacey Cope, Software Engineering Institute • Erik Dorsett, Jeppesen • Dan Foster, PF Williamson • Eric Hayes, Software Engineering Institute • Kurt Hess, Software Engineering Institute • Mike Konrad, Software Engineering Institute • Steve Masters, Software Engineering Institute • Robert McFeeley, Software Engineering Institute • Diane Mizukami-Williams, Northrop Grumman • Daniel Pipitone, Software Engineering Institute • Mary Lou Russo, Software Engineering Institute (non-voting member) • Sandy Shrum, Software Engineering Institute • Katie Smith-McGarty, US Navy • Barbara Tyson, Software Engineering Institute SVC 培训团队 • Drew Allison, Systems and Software Consortium, Inc. • Mike Bridges, University of Pittsburgh Medical Center • Paul Byrnes, Integrated System Diagnostics • Sandra Cepeda, Cepeda Systems & Software Analysis/RDECOM SED • Eileen Clark, Tidewaters Consulting • Kieran Doyle, Excellence in Measurement • Eileen Forrester, Software Engineering Institute (lead of SVC training) • Suzanne Miller, Software Engineering Institute • Hillel Glazer, Entinex • Christian Hertneck, Anywhere.24 GmbH • Pat Kirwan, Software Engineering Institute • Judah Mogilensky, PEP • Heather Oppenheimer, Oppenheimer Partners • Pat O’Toole, PACT • Agapi Svolou, Alexanna • Jeff Welch, Software Engineering Institute 364 CMMI 版本 1.3 项目参加人员 CMMI 开发模型,版本 1.3 CMMI 1.3 版质量团队 质量团队对模型资料进行各种质量保证检查,确保其准确性、易读性与一 致性。 • Rhonda Brown, Software Engineering Institute (co-lead) • Erin Harper, Software Engineering Institute • Mike Konrad, Software Engineering Institute • Mary Lou Russo, Software Engineering Institute • Mary Lynn Russo, Software Engineering Institute • Sandy Shrum, Software Engineering Institute (co-lead) CMMI 版本 1.3 项目参加人员 365 CMMI 开发模型,版本 1.3 366 CMMI 版本 1.3 项目参加人员 附录 D:术语表 CMMI 开发模型,版本 1.3 术语表定义了 CMMI 模型中使用的基本术语。术语表中的条目通常是由一 个名词与一个或多个限制性修饰词组成的多词术语。(该规则存在一些例 外,术语表中也有一些单词术语。) 由术语组成的 CMMI 术语表并非 CMMI 模型的必需的组件、期望的组件或 说明性的组件。要将术语表中的术语在其出现的模型组件背景下进行解读。 为能够制订 CMMI 的合适定义,我们查阅了多个原始资料。我们首先查阅 了韦氏在线字典(http://www.merriam-webster.com/)。必要时我们还查 阅了其它标准,包括: • ISO 9000[ISO 2005a] • ISO/IEC 12207[ISO 2008a] • ISO/IEC 15504[ISO 2006a] • ISO/IEC 15288[ISO 2008b] • ISO/IEC 15939[ISO 2007] • ISO 20000-1[ISO 2005b] • IEEE[IEEE 1991] • CMM for Software(SW-CMM)v1.1 • EIA 632[EIA 2003] • SA-CMM[SEI 2002] • People CMM(P-CMM)[Curtis 2009] • CobiT v. 4.0 [IT Governance 2005] • ITIL v3(Service Improvement, Service Design, Service Operation, Service Strategy, and Service Transition)[Office of Government Commerce 2007] 我们认识到使用所有模型使用者都能够理解的用辞的重要性而制订了术 语表。我们还认识到文字与术语在不同的上下文与背景下会有不同的含义。 CMMI 模型中术语表的设计,是将在 CMMI 产品用户中得到最广泛使用并 理解的词语与术语进行文档化。 尽管术语“产品”包含产品的同时也包含服务,术语“服务”也被定义为 一种类型的产品,术语表中的很多术语同时含有词语“产品”与“服务”, 以强调 CMMI 同时适用于产品与服务。 术语表中每个词条都有两到三个组件。术语与定义总是存在。有时也提供 额外的注释。 被定义的术语位于页面左边。术语的定义首先以与被列出的术语相近的字 体大小出现。在定义的下面,术语表注释以小一些的字体出现。 术语表 367 CMMI 开发模型,版本 1.3 验收准则 (acceptance criteria) 验收测试 (acceptance testing) 达成情况概览图 (achievement profile) 采购方 (acquirer) 采购 (acquisition) 采购策略 (acquisition strategy) 附加部分 (addition) 已分配需求 (allocated requirement) 评估 (appraisal) 评估发现 (appraisal findings) 评估参与人员 (appraisal participants) 评估评定 (appraisal rating) 评估参考模型 (appraisal reference model) 为使交付物被用户、客户或其他授权实体接受而必须满足的准 则。(另见“交付物”。) 为使用户、客户或其他授权实体确定是否接受交付物而进行的 正式测试。(另见“单元测试”。) 表现了组织在提升能力等级时各过程域进展情况的过程域及 其对应能力等级的列表。(另见“能力等级概览图”,“目标 概览图”与“目标阶段”。) 从供方采购或取得产品或服务的干系人。(另见“干系人”。) 通过供方协议获得产品或服务的过程。(另见“供方协议”。) 以对供货源、采购方法、需求规格说明类型、协议类型及相关 采购风险等方面的考虑为基础的,采购产品与服务的具体方 法。 含有特定用户所关心的信息的、得到明确标记的模型组件 在 CMMI 模型中,具有相同名称的附加部分的全部可选择作为一 个整体进行使用。在 CMMI 服务模型中,服务系统开发(Service System Development,SSD)过程域为一个附加部分。 从较高级别需求的全部或部分指派给较低级别的架构元素或 设计组件所得到的需求。 一般来说,以怎样使产品或服务能最好地达成需求为依据,需求 可被分配至其它逻辑或物理组件,包括人员、消耗品、交付增量 或整体架构。 最低限度是为确定强项与弱项,使用评估参考模型作为基础, 由经过培训的专业团队对一个或多个过程所进行的检查。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。 在评估范围内,以过程改进为目的,识别出的最为重要的问题、 欠缺或机会的评估结果。 评估发现来自于确证了的客观证据的推断。 在评估时,组织级单位内参与提供信息的成员。 由评估团队为下列中的任一项所给出的评分:(a)CMMI 目 标或过程域,(b)过程域的能力等级,或(c)组织级单位的 成熟度级别。 该术语在如 SCAMPI MDD 的 CMMI 评估资料中使用。评定结果 通过执行所用评估方法中定义的评定过程而得出。 评估团队用以对所实施的过程活动进行关联的 CMMI 模型。 该术语在如 SCAMPI MDD 的 CMMI 评估资料中使用。 368 术语表 CMMI 开发模型,版本 1.3 评估范围 (appraisal scope) 架构 (architecture) 审计 (audit) 基线 (baseline) 基本度量项 (base measure) 双向可追溯性 (bidirectional traceability) 业务目标 (business objectives) 能力等级 (capability level) 能力等级概览图 (capability level profile) 能力成熟度模型 (capability maturity model) 有能力的过程 (capable process) 原因分析 (causal analysis) 评估的界限定义,包含组织级界限与 CMMI 模型界限,待审查 的过程在此界限内施行。 该术语在如 SCAMPI MDD 的 CMMI 评估资料中使用。 对产品进行推理分析所需结构的集合。这些结构由元素、元素 间关系及两者的属性构成。 在服务的应用背景下,架构常常适用于服务系统。 要注意的是,功能只是产品的一个方面。质量属性,如响应速度、 可靠性及安全性等,对推理分析来说也很重要。结构提供了突出 架构不同部分的手段。(另见“功能架构”。) 对照具体的准则(如需求),对工作产品或工作产品的集合进 行的客观检查。(另见“客观评价”。) 该术语以多种方式在 CMMI 中使用,包括配置审计与过程符合度 审计。 经过正式评审并取得共识的规格说明与工作产品的集合,该集 合成为之后进一步开发的基础,并且只能通过变更控制规程才 能进行变更。(另见“配置基线”与“产品基线”。) 由属性与量化属性的方法所定义的度量项。(另见“衍生度量 项”。) 基本度量项在功能上独立于其他度量项。 两个或更多逻辑实体间可从任一方向(即至某一实体或自某一 实体)认识的关联。(另见“需求可追溯性”与“可追溯性”。) (见“组织的业务目标”。) 在单个过程域内取得的过程改进成果。(另见“通用目标”, “特定目标”,“成熟度级别”与“过程域”。) 能力等级由过程域中合适的特定与通用目标所定义。 过程域及其对应的能力等级的列表。(另见“达成情况概览图”, “目标概览图”与“目标阶段”。) 当能力等级概览图表现了组织在提升能力等级过程中每个过程域 的进展时,即成为“达成情况概览图”。或者,当它表现了过程 改进的目标时,即成为“目标概览图”。 含有一个或多个有关领域内有效过程的实质性元素,并描述了 从随意、不成熟的过程到改进了质量与有效性的、有秩序、成 熟的过程的演进道路的模型。 能够满足规定的产品质量、服务质量以及过程性能目标的过 程。(另见“稳定的过程”与“标准过程”。) 为确定原因而对结果进行的分析。 术语表 369 CMMI 开发模型,版本 1.3 变更管理 (change management) CMMI 框架 (CMMI Framework) CMMI 模型 (CMMI model) CMMI 模型组件 (CMMI model component) CMMI 产品套件 (CMMI Product Suite) 商用现货 (commercial off-the-shelf) 偏差的共同原因 (common cause of variation) 配置审计 (configuration audit) 配置基线 (configuration baseline) 配置控制 (configuration control) 配置控制委员会 (configuration control board) 配置识别 (configuration identification) 配置项 (configuration item) 使得对产品或服务的变更、或对其提议的变更生效而审慎使用 的手段。(另见“配置管理”。) 将包括现有 CMMI 模型元素以及模型创建的规则与方法、评估 方法(包括相关产物)与培训材料等在内的 CMMI 组件进行组 织的基本结构。(另见“CMMI 模型”与“CMMI 产品套件”。) 框架能使新的有关领域可添加进 CMMI,并与现有领域进行整合。 从 CMMI 框架中创建的模型。(另见“CMMI 框架”与“CMMI 产品套件”。) 任何组成 CMMI 模型的主要架构元素。 CMMI 模型的主要元素中包括特定实践、通用实践、特定目标、 通用目标、过程域、能力等级与成熟度级别等。 围绕 CMMI 概念所开发产品的完整集合。(另见“CMMI 框架” 与“CMMI 模型”。) 这些产品包括框架本身、模型、评估方法、评估资料与培训资料 等。 能够从商业供方处购买到的物品。 由于过程组件之间正常的、期望中的相互作用而存在的过程的 偏差。(另见“偏差的特殊原因”。) 为验证构成基线的一个或一组配置项是否符合规定的标准或 需求而进行的审计。(另见“审计”与“配置项”。) 在产品或产品组件生命期的特定时间点上,正式标识的配置信 息。(另见“产品生命周期”。) 配置基线及已批准的对这些基线的变更,构成了当前的配置信息。 配置管理的要素之一,包括在对配置项的配置识别正式建立之 后,对配置项的变更进行评价、协调,批准或否决,以及变更 的实施等活动。(另见“配置识别”,“配置项”与“配置管 理”。) 负责对提议的配置项变更进行评价、批准或否决,并确保所批 准变更得以实施的一组人员。(另见“配置项”。) 配置控制委员会也被称为“变更控制委员会”。 配置管理的要素之一,包括选择产品的配置项,为其赋予唯一 标识,并在技术文档中记录其功能及物理特性。(另见“配置 项”,“配置管理”与“产品”。) 为接受配置管理而得到标识的工作产品的集合体,在配置管理 过程中被视为单个实体。(另见“配置管理”。) 370 术语表 CMMI 开发模型,版本 1.3 配置管理 (configuration management) 配置状态记录与报告 (configuration status accounting) 群集 (constellation) 连续式表示法 (continuous representation) 承包方 (contractor) 合同需求 (contractual requirements) 纠正措施 (corrective action) 客户 (customer) 客户需求 (customer requirement) 数据 (data) 技术和管理方面的学科,用来指导和监督:(1)识别并文档 化配置项的功能与物理特性,(2)控制这些特性的变更,(3) 记录并报告变更处理和实施状态,以及(4)验证与规定需求 的符合性。(另见“配置审计”,“配置控制”,“配置识别” 与“配置状态记录与报告”。) 配置管理要素之一,包括记录和报告有效管理配置所需的信 息。(另见“配置识别”与“配置管理”。) 该信息包括已批准配置的列表、提议的配置变更的状态以及已批 准变更的实施状态。 CMMI 组件的集合,用于构建所关心领域(如,开发、采购、 服务等)的模型、培训资料以及评估相关的文档。 能力成熟度模型的一种结构,其中的能力等级为每一特定过程 域中的过程改进路径提供了建议顺序。(另见“能力等级”, “过程域”与“阶段式表示法”。) (见“供方”。) 由客户需求分析并细化而来,适于纳入一个或多个招标文件包 或者供方协议的一组需求。(另见“采购方”,“客户需求”, “供方协议”与“招标文件包”。) 合同需求包括产品或服务采购所必需的技术和非技术需求。 补救某种状况或消除某种错误的行动或行为。 负责验收产品或授权支付的当事人。 客户是独立于项目或工作组之外的(除某些特定的项目结构,使 得客户可能有效融入项目团队或工作组),但不一定是组织外部 的。客户可以是一个更高层级的项目或工作组。客户是干系人的 子集。(另见“干系人”。) 在使用本术语的大多数情况下,上述定义都是适用的。但在某些 情况下,术语“客户”的含义中也会包含其他的相关干系人。(另 见“客户需求”。) 在当事人直接获得产品或服务的价值,但不负责协议的安排、支 付或谈判时,可以将最终用户与客户区分开来。在客户和最终用 户本质上是同一当事人的情形下,术语“客户”应该包含这两者。 (另见“最终用户”。) 以客户可接受的方式对产品相关干系人的需要、期望、约束与 接口进行挖掘、整合并消除分歧的结果。(另见“客户”。) 已记录的信息。 已记录的信息包括能够用于沟通、存储和处理的技术数据、计算 机软件文档、财务信息、管理信息、事实的陈述、数字、或任何 性质的资料。 术语表 371 CMMI 开发模型,版本 1.3 数据管理 (data management) 缺陷密度 (defect density) 已定义的过程 (defined process) 必需的功能与质量属性定 义 (definition of required functionality and quality attributes) 交付物 (deliverable) 交付环境 (delivery environment) 衍生度量项 (derived measure) 衍生需求 (derived requirements) 设计评审 (design review) 开发 (development) 在整个数据生命周期中,用于计划和获取业务与技术数据并对 其进行管理,以使其符合数据需求的规范的过程与体系。 每单位产品规模的缺陷数量。 如每千行代码中问题报告的数量。 按照组织的裁剪指南,从组织的标准过程集中裁剪得到的已管 理的过程;它具有受维护的过程描述;并且将过程相关经验贡 献给组织级过程资产。(另见“已管理的过程”。) 一组必需的功能和质量属性的特性描述,该特性描述通过对需 求(功能的和非功能的)“分块”、组织、注释、结构化或正 式化得到,以便进一步细化和理解需求及(可能的、初始的) 解决方案的探索、定义和评价。(另见“架构”,“功能架构” 与“质量属性”。) 随着技术解决方案过程的进展,该特性描述可以进一步演变成架 构描述,而不只是帮助确定开发范围和指导后续开发,这取决于 所使用的工程过程、需求规格说明及结构化语言、开发产品或服 务系统所使用的工具及环境。 在协议中规定的提供给采购方或其他指定接收人的项。(另见 “采购方”。) 此类项可以是文档、硬件、软件、服务或任何类型的工作产品。 使服务按照服务协议交付的环境与条件的完整集合。(另见“服 务”与“服务协议”。) 交付环境包括对交付服务具有或能够产生显著影响的所有事物, 包括但不限于服务系统的运作、自然现象以及所有当事人的行为, 不管它们是否有意产生这样一个影响。例如,交通运输服务需要 考虑天气或交通模式的影响。(另见“服务系统”。) 交付环境与其它环境(例如,模拟环境、测试环境)有明确的区 别。交付环境是服务实际被交付并被认定为满足服务协议的环境。 定义为两个或多个基本度量项值的函数的度量项。(另见“基 本度量项”。) 在客户需求中未明确说明但从下列内容推导出来的需求:(1) 情境需求(如适用的标准、法律、政策、惯例、管理决策)或 (2)明确说明产品或服务组件的需求。 在分析和设计产品或服务组件的过程中也可以产生衍生需求。(另 见“产品需求”。) 为了确定设计是否满足适用的需求、识别问题和提出解决方 案,对设计所做的正式的、文档化的、全面的和系统化的检查。 通过审慎的工作来创造产品或者服务系统。 在有些情形下,开发可以包括对所开发产品的维护。 372 术语表 CMMI 开发模型,版本 1.3 文档 (document) 最终用户 (end user) 企业 (enterprise) 入口准则 (entry criteria) 等价阶段式定级 (equivalent staging) 建立并维护 (establish and maintain) 工作产品实例 (example work product) 高层主管 (executive) 出口准则 (exit criteria) 不论记录在哪种介质上,通常具有持久性并且可被人或者机器 读取的数据集合。 文档既包括纸质文档也包括电子文档。 最终使用所交付产品或者从所交付服务得到收益的一方。(另 见“客户”。) 最终用户可能是也可能不是客户(即能建立并接受协议或者授权 支付的人)。 在一些情况下,一个单独的服务协议涵盖多个服务交付,这时, 发起服务请求的任何一方都可以被理解为最终用户。(另见“服 务协议”与“服务请求”。) 一个公司的完整构成。(另见“组织”。) 一个公司可以包括许多位于多个位置、具有不同客户的组织。 工作能够成功开始之前必须呈现的状态。 是一种目标阶段,这一目标阶段的创建是基于已定义的连续式 表示法,从而使得其使用结果可与阶段式表示法中的成熟度级 别相比较。(另见“能力等级概览图”,“成熟度级别”,“目 标概览图”与“目标阶段”。) 这样的定级允许组织、企业、项目和工作组之间,不管其使用哪 种 CMMI 表示法,都可以对进展进行基准比较。组织可以实施等 价阶段式定级所报告组件之外的 CMMI 模型组件。等价阶段式定 级关系到组织之间如何就成熟度级别互相比较。 创建、文档化、使用、并且在必要时修订工作产品以确保它们 保持有用的状态。 短语“建立并维护”在传递一个更深层次的 CMMI 原则时,发挥 特殊的作用。该原则是:应该关注在工作组、项目和组织级绩效 中起主要或者关键作用的工作产品,以确保这些工作产品发挥相 应的作用并保持使用价值。 这一短语在 CMMI 中有特别重要的意义,原因是该短语经常出现 在目标和实践描述中(尽管在前者其表述形式为“得到建立与维 护”),并且不论这一短语指向什么工作产品,都意味着上述原 则对其适用。 提供特定实践输出例子的说明性模型组件。 (见“高层管理人员”。) 在工作可以成功结束之前必须呈现的状态。 术语表 373 CMMI 开发模型,版本 1.3 期望的 CMMI 组件 (expected CMMI components) 发现 (findings) 正式评价过程 (formal evaluation process) 框架 (framework) 功能分析 (functional analysis) 功能架构 (functional architecture) 通用目标 (generic goal) 通用实践 (generic practice) 通用实践详细说明 (generic practice elaboration) 硬件工程 (hardware engineering) 上级管理层 (higher level management) 不完整的过程 (incomplete process) 描述活动的 CMMI 组件,这些活动在必需的 CMMI 组件的达成 中起重要作用。 模型用户可以明确地实施期望的组件,也可以实施这些组件的等 价实践。特定实践与通用实践是期望的模型组件。 (见“评估发现”。) 为了确定处理问题的推荐解决方案,而对照已建立的准则评价 备选解决方案的结构化方法。 (见“CMMI 框架”。) 为识别完成功能必需的全部子功能而对已定义功能的考察;对 功能联系和接口(内部的与外部的)的识别,以及在功能架构 中对这些联系和接口的捕捉;较高层需求向下的流转以及把这 些需求对较低层子功能的分配。(另见“功能架构”。) 对功能、其内外部(聚合本身之外的)功能接口与外部物理接 口、其各自需求、及其设计约束的层次性安排。(另见“架构”, “功能分析”与“必需的功能与质量属性定义”。) 必需的模型组件,描述了把某一过程域相关过程制度化所必须 呈现的特征。(另见“制度化”。) 期望的模型组件,它在达成相关联的通用目标中被认为起重要 作用。 与通用目标相关联的通用实践描述了一些活动,这些活动有望带 来通用目标的达成,并且有助于过程域所关联过程的制度化。 说明性的模型组件,它出现在通用实践之后,为该通用实践在 某一过程域的特定应用提供指导。(该模型组件并非在所有 CMMI 模型中都出现。) 系统化、规范并可计量的方法在转换需求集的过程中的应用 ——运用文档化的技术与工艺来设计、实现并维护有形的产 品,该需求集代表了干系人的需要、期望和约束的集合。(另 见“软件工程”与“系统工程”。) 在 CMMI 中,硬件工程代表了把需求和想法转换成有形产品的全 部技术领域(例如,电子的、机械的)。 为过程提供方针和总体指导,但是不直接提供日常的过程监督 和控制的一个或者多个人。(另见“高层管理人员”。) 这类人所属的组织管理层级别高于负责过程的直接管理级别,并 且可以是高层管理人员(但不是必须)。 没有得到执行或者只是部分得到执行的过程;过程域的一个或 者多个特定目标没有得到满足。 不完整的过程也被认为是能力等级 0 级。 374 术语表 说明性的 CMMI 组件 (informative CMMI components) 制度化 (institutionalization) 接口控制 (interface control) 生命周期模型 (lifecycle model) 已管理的过程 (managed process) 管理人员 (manager) 成熟度级别 (maturity level) 度量项(名词) (measure [noun]) 度量 (measurement) 度量结果 (measurement result) 协议备忘录 (memorandum of agreement) 自然边界 (natural bounds) 术语表 CMMI 开发模型,版本 1.3 CMMI 组件,它帮助模型使用者理解模型中必需的组件与期望 的组件。 这些组件可以是实例、详细解释或者其它有帮助的信息。子实践、 注解、参考、目标标题、实践标题、来源、工作产品实例与通用 实践详细说明是说明性的模型组件。 组织常规遵循的根深蒂固的业务方式,它是组织文化的一部 分。 配置管理中,这一过程(1)识别由一个或者多个组织所提供 的两个或者多个配置项接口连接相关的全部功能和物理特征, 以及(2)确保对这些特征提出的变更在实施前得到评价与批 准。(另见“配置项”与“配置管理”。) 对产品、服务、项目、工作组或者工作活动集生命期的阶段划 分。 一种已执行的过程,这种过程按照方针得到计划和执行;雇用 有技能的人,具备充分的资源以产生受控的输出;使相关干系 人参与其中;得到监督、控制与评审;并且对其过程描述的遵 守程度得到评价。(另见“已执行的过程”。) 对那些在该管理人员所负责的领域内执行任务或活动的人员 发布技术和管理方面的指令,并进行控制的人。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。管理人员的传统职能包括计划、组织、指示并控制某个责任 领域内的工作。 在一组预先定义的过程域集合范围内取得的过程改进的程度, 该过程域集合内的所有目标都得到达成。(另见“能力等级” 与“过程域”。) 赋值的变量,该值为度量的结果。(另见“基本度量项”,“衍 生度量项”与“度量”。) 该术语在 CMMI 中的定义与在 ISO 15939 中的定义一致。 确定度量项的值的操作集合。(另见“度量项”。) 该术语在 CMMI 中的定义与在 ISO 15939 中的定义一致。 通过执行度量而确定的值。(另见“度量”。) 两方或多方之间有约束力的谅解文档或协议文档。 协议备忘录又称“谅解备忘录”。 由过程性能度量项确定的过程内偏差的固有范围。 自然边界有时被称作“过程的声音”。 诸如控制图、置信区间和预测区间等技术用于确定偏差是源于共 同原因(即过程可预测或稳定)还是源于某些能够且应该被识别 并移除的特殊原因。(另见“度量项”与“过程性能”。) 375 CMMI 开发模型,版本 1.3 非开发项 (nondevelopmental item) 非技术需求 (nontechnical requirements) 客观评价 (objectively evaluate) 操作概念 (operational concept) 操作场景 (operational scenario) 组织 (organization) 组织级成熟度 (organizational maturity) 组织级方针 (organizational policy) 组织级过程资产 (organizational process assets) 组织的业务目标 (organization’s business objectives) 在采购或开发过程中,于当前用途之前已完成开发的项。 此类项可能只需要小规模的修改即可满足其当前预期用途的需 求。 影响产品与服务的采购或开发的、并非产品或服务的属性的需 求。 实例包括要交付的产品或服务的数量、交付的 COTS 与非开发项 的数据权利、交付日期以及具有出口准则的里程碑等。其它非技 术需求包括与培训、现场规定及部属进度等相关联的工作约束。 对照尽可能减少评审者的主观性和倾向性的准则,对活动与工 作产品进行评审。(另见“审计”。) 一个客观评价的实例是由一个独立的质量保证职能对照需求、标 准或规程所进行的审计。 对实体的使用方式或操作方式所做的一般性描述。 操作概念又称“操作的概念”。 对所设想的事件序列的描述,事件序列包括产品或服务与其环 境和用户的交互,以及产品组件之间或服务组件之间的交互。 操作场景用于评价系统的需求与设计,并用于对系统进行验证与 确认。 一个行政管理结构,在此结构内部,其人员作为一个整体共同 管理一个或多个项目或工作组,由同一位高层管理人员负责, 并且在相同方针下运作。 不过,在 CMMI 模型各处所使用的“组织”一词,也可适用于小 型组织中执行某项职能的个人,而该职能在大型组织中,可能要 由一组人员来执行。(另见“企业”。) 组织将那些已文档化、已管理、已度量、已控制并持续改进的 过程进行明确并一致部署的程度。 组织级成熟度能够通过评估得到度量。 组织采纳用于影响并确定决策的、通常由高层管理人员建立的 指导原则。 与对过程进行描述、执行并改进相关联的产物。 这些产物的实例有方针、度量描述、过程描述、支持过程实现的 工具。 术语“过程资产”用于表明这些产物的开发或获取是为了满足组 织的业务目标,这些产物体现了组织的投入,以期待为当前及未 来的业务带来价值。(另见“过程资产库”。) 由高层管理人员制订的目标,用以确保组织的持续存在,并强 化其盈利能力、市场份额以及其它影响组织成功的因素。(另 见“质量与过程性能目标”与“量化目标”。) 376 术语表 CMMI 开发模型,版本 1.3 组织的度量库 (organization’s measurement repository) 组织的过程资产库 (organization’s process asset library) 组织的标准过程集 (organization’s set of standard processes) 外包 (outsourcing) 同级评审 (peer review) 性能参数 (performance parameters) 已执行的过程 (performed process) 已计划的过程 (planned process) 方针 (policy) 用于收集有关过程与工作产品的度量结果,并使其可用的存储 库,尤指这些度量结果与组织的标准过程集相关的场合。 这个存储库包含或引用实际的度量结果以及理解并分析度量结果 所需的相关信息。 用于存储并使过程资产可用的信息库。其过程资产对于那些在 组织中定义、实施并管理过程的人员具有使用价值。 该库所含的过程资产包括与过程相关的文档,例如方针、已定义 的过程、检查表、经验教训文档、模板、标准、规程、计划与培 训材料等。 指导组织内活动的过程定义合集。 这些过程描述涵盖基本的过程元素(以及过程元素间如顺序与接 口等相互关系),这些过程元素应当纳入到那些在组织的各项目、 各工作组以及各类工作中得到实施的已定义过程内。标准过程使 得开发与维护活动在整个组织内能够具有一致性,对其长期的稳 定与改进来说亦必不可少。(另见“已定义的过程”与“过程元 素”。) (见“采购”。) 在工作产品开发期间由同级人员执行的工作产品评审,来识别 缺陷以便移除。(另见“工作产品”。) 在 CMMI 产品套件中,使用术语“同级评审”来代替术语“工作 产品审查”。 用于指导并控制渐进式开发的有效性度量项与其它关键度量 项。 完成所需工作而产生工作产品的过程;过程域中的特定目标得 到满足。 由一份描述说明和一份计划而文档化的过程。 描述说明与计划应当协调一致,且计划应当包括标准、需求、目 标、资源与任务分配等。 (见“组织级方针”。) 术语表 377 CMMI 开发模型,版本 1.3 过程 (process) 过程行动计划 (process action plan) 过程行动小组 (process action team) 过程与技术改进 (process and technology improvements) 过程架构 (process architecture) 过程域 (process area) 过程资产 (process asset) 过程资产库 (process asset library) 过程属性 (process attribute) 过程能力 (process capability) 过程定义 (process definition) 过程描述 (process description) 相互关联的活动的集合,这些活动将输入转换为输出以达成特 定的目的。(另见“过程域”,“子过程”与“过程元素”。) 在通用目标与通用实践的陈述与描述中,“过程”一词有特殊的 用法。第二部分使用到的“过程”指的是实施了某过程域的一个 或多个过程。 术语“过程”、“子过程”与“过程元素”形成一个层次结构, “过程”是最高级、最通用的术语,“子过程”在其之下,“过 程元素”则最为具体。如果一个特定的过程是另一个更大的过程 的一部分,则可称其为一个子过程。如果过程不能被分解至子过 程,则也可将其称为一个过程元素。 过程的这个定义与过程在 ISO 9000、ISO 12207、ISO 15504 以 及 EIA 731 中的定义一致。 通常根据评估结果制定的计划文件,说明将要如何实施针对评 估发现的弱项进行的特定改进。 负责根据过程行动计划开发并实施某组织的过程改进活动的 小组。 对过程本身和对过程、产品或服务技术的渐进与创新的改进。 (1)标准过程中过程元素之间的排序、接口、内部依赖关系 以及其它关系,或(2)过程元素与外部过程之间的接口、内 部依赖关系以及其它关系。 某一领域内的一组相关实践,当它们共同得到实施时,能满足 一组对于在本领域作出改进较为重要的目标。 组织认为有助于实现过程域目标的一切事物。(另见“组织级 过程资产”。) 可被一个组织、项目或者工作组使用的过程资产的集合。(另 见“组织的过程资产库”。) 对任何过程均适用的关于过程能力的可度量特性。 遵循某过程可能达到的预期结果的范围。 定义并描述某过程的行动。 过程定义的结果是过程描述。(另见“过程描述”。) 为实现某一给定目标而执行的一组活动的文档化表述。 过程描述提供了过程主要组件的操作性定义。该描述以完整、精 确和可验证的方式明确说明了过程的需求、设计、行为或者其它 特性。它还可以包括确定这些条款是否得到满足的规程。过程描 述可以定位于活动、项目、工作组或者组织级层面。 378 术语表 CMMI 开发模型,版本 1.3 过程元素 (process element) 过程组 (process group) 过程改进 (process improvement) 过程改进目标 (process improvement objectives) 过程改进计划 (process improvement plan) 过程度量 (process measurement) 过程负责人 (process owner) 过程性能 (process performance) 过程性能基线 (process performance baseline) 过程的基本单元。 过程可以用子过程或过程元素来定义。当子过程不能被进一步分 解为子过程或者过程元素时,子过程即为过程元素。(另见“过 程”与“子过程”。) 每一过程元素涵盖了密切相关的一组活动(例如估算元素、同级 评审元素)。过程元素可以用需完成的模板、需细化的摘要、或 者需要修订或采用的描述来加以描绘。一个过程元素可以是一项 活动或者任务。 术语“过程”、“子过程”与“过程元素”形成一个层次结构, “过程”是最高级、最通用的术语,“子过程”在其之下,“过 程元素”则最为具体。 帮助定义、维护和改进组织所用过程的专家队伍。 用于改进过程性能与组织的过程成熟度的活动所组成的项目, 以及这类项目的结果。 为了以明确和可度量方式指导对现有过程的改进而建立的一 组目标特性,其表现形式可能是结果性的产品或服务特性(例 如质量、产品性能、与标准的符合性),也可能是过程执行的 方式(例如消除冗余的过程步骤、合并某些过程步骤、改进周 期时间)。(另见“组织的业务目标”与“量化目标”。) 基于对组织的过程与过程资产现有的强项与弱项的充分理解, 为实现组织级过程改进目标而制订的计划。 用于确定某过程及其结果性产品或服务的度量项取值而进行 的一组操作,其目的在于描述并理解该过程的特征。(另见“度 量”。) 负责定义与维护某过程的个人(或团队)。 在组织级层面,过程负责人是负责描述标准过程的个人(或团队); 在项目或工作组层面,过程负责人是负责描述已定义的过程的个 人(或团队)。因此同一过程可能有负责不同层面的多个负责人。 (另见“已定义的过程”与“标准过程”。) 遵循某过程而达成的结果的度量项。(另见“度量项”。) 过程性能的表述方式既包括过程度量项(例如工作量、周期时间、 缺陷消除效率)也包括产品或服务度量项(例如可靠性、缺陷密 度、响应时间)。 过程性能的文档化表述,可以包括中心趋势与偏差。(另见“过 程性能”。) 过程性能基线可被用作比较实际过程性能与期望过程性能的基 准。 术语表 379 CMMI 开发模型,版本 1.3 过程性能模型 (process performance model) 过程裁剪 (process tailoring) 产品 (product) 产品基线 (product baseline) 产品组件 (product component) 产品组件需求 (product component requirements) 产品生命周期 (product lifecycle) 一项或多项过程或工作产品的可度量属性的相互关系的描述, 它根据过程性能的历史数据开发而来,并被用于预测未来的性 能。(另见“度量项”。) 一项或多项可度量属性代表了某一子过程的可控的输入,从而使 对计划、动态的重新计划以及问题解决等活动性能的假设分析成 为可能。过程性能模型包含了统计的、概率的以及基于模拟的模 型,这些模型联接了过去的性能表现与未来的输出,从而预测中 间结果或者最终结果。它们对各项因素的偏差进行建模,并提供 了对预测结果的期望范围与偏差的洞察。过程性能模型可以是(组 合在一起时)满足过程性能模型准则的若干模型的集合。 为取得特定结果而对过程描述进行制订、修改或做适应性调 整。 例如,项目或工作组从组织的标准过程集裁剪出自己的已定义的 过程,以满足该项目或工作组的目标、约束与环境。(另见“已 定义的过程”,“组织的标准过程集”与“过程描述”。) 意在交付给客户或最终用户的工作产品。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。产品的形态可能在不同的语境中发生变化。(另见“客户”, “产品组件”,“服务”与“工作产品”。) 在生命周期的生产、操作、维护和后勤支持过程中,定义一个 配置项的最初经批准的技术数据包。(另见“配置项”,“配 置管理”与“技术数据包”。) 本术语与配置管理相关。 一种工作产品,是产品的更低层次的组件。(另见“产品”与 “工作产品”。) 产品组件得到集成以生产产品。可能有多个层次的产品组件。 在各个过程域中使用到的术语“产品”与“产品组件”,其含义 也包含了服务、服务系统以及它们的组件。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。 产品或服务组件的完整的规格说明,包括适配、形状、功能、 性能以及其它任何需求。 从产品或服务的构想开始,到产品或服务不可再使用为止,由 这期间的多个阶段组成的时间区间。 因为一个组织可以同时为多个客户生产多项产品或者服务,仅有 一种产品生命周期的描述可能是不够的。因此,组织可以定义一 组经过批准的产品生命周期模型。这些模型通常可以在公开发表 的文献中找到,并且可能需要进行裁剪,以便在组织中使用。 产品生命周期可能由如下阶段组成:(1)概念和愿景、(2)可 行性研究、(3)设计/开发、(4)生产和(5)逐步废弃。 380 术语表 CMMI 开发模型,版本 1.3 产品线 (product line) 与产品相关的生命周期过 程 (product related lifecycle processes) 产品需求 (product requirements) 产品套件 (product suite) 项目 (project) 项目计划 (project plan) 项目进展与绩效 (project progress and performance) 项目启动 (project startup) 共享一个受管理的公共特性集的一组产品。该组产品按照预先 规定的方式、从公共的核心资产集中开发出来,并且可以满足 某一市场或使命的特定需要。(另见“服务线”)。 产品线内各产品的开发或采购基于对于这组产品共性的利用和差 异性的限定(即限制非必要的产品差异性)。受管理的核心资产 集(如:需求、架构、组件、工具、测试成果、操作规程、软件 等)中也包括了在产品开发中如何使用它们的规范性指南。产品 线的运营包括了核心资产开发、产品开发和管理等广泛活动的联 动执行。 很多人使用“产品线”,只是用来表示由一个特定的业务单位生 产的一组产品,而不论它们是否是用共享资产开发的。我们将这 样的一组产品称为“产品组合(portfolio)”,而保留“产品线” 一词,用于表示前面所提及的技术含义。 与贯穿产品或服务生命期的一个或多个阶段(如从概念到废弃 阶段)相关的过程,例如制造与支持过程。 产品需求是将客户需求细化为开发者的语言,将隐性的需求转 化为明确的衍生需求。(另见“衍生需求”和“产品组件需求”。) 开发者用产品需求来指导产品或服务的设计与构建。 (见“CMMI 产品套件”。) 一组受管理的相互关联的活动和资源(包括人员),以交付一 项或多项产品或服务给客户或最终用户。 每个项目都有预期的开始点(如项目启动)和结束点,并通常按 照一份计划进行运作。该计划文档会频繁地修订,明确说明要交 付或实施的内容、要使用的资源和资金、需完成的工作以及执行 该工作的进度。一个项目可以由多个项目组成。(另见“项目启 动”。) 在某些情况下,英语术语“program”也用于表示项目。 计划为执行和控制项目活动提供基础,以此处理对项目客户的 承诺。 项目计划活动包括了估算工作产品与任务的属性、确定所需资源、 协商各类承诺、制订进度计划以及识别并分析项目风险。可能有 必要反复进行上述的活动以建立项目计划。 项目在项目计划执行方面的达成情况,包括工作量、成本、进 度以及技术性能。(另见“技术性能”。) 为某一个项目所提供的一组相关资源,被指定去为某一客户或 最终用户开发或交付一项或多项产品或服务的时刻。(另见“项 目”。) 术语表 381 CMMI 开发模型,版本 1.3 原型 (prototype) 质量 (quality) 质量与过程性能目标 (quality and process performance objectives) 质量保证 (quality assurance) 质量属性 (quality attribute) 质量控制 (quality control) 量化管理 (quantitative management) 量化目标 (quantitative objective) 已量化管理的 (quantitatively managed) 一项产品、服务、产品组件或者服务组件的初始类型、模式或 实例,用以作为该产品或服务的后继阶段版本或最终完整版本 的模型。 该产品或服务的模型(如物理的、电子的、数码的、分析的)可 用于以下(及其它)目的: • 评估某项新的或不熟悉的技术的可行性 • 评估或缓解技术风险 • 确认需求 • 展示关键特性 • 验证产品或服务是否合格 • 验证过程是否合格 • 描述产品或服务的性能或特性 • 阐明物理原理 一组固有特性满足需求的程度。 产品质量、服务质量与过程性能的量化目标和需求。 量化的过程性能目标包括了质量,然而,为强调质量在 CMMI 产 品套件中的重要性,在 CMMI 中使用“质量与过程性能目标”一 词。“过程性能目标”在成熟度 3 级中提及,而术语“质量与过 程性能目标”意味着使用量化数据,仅在成熟度 4 级和 5 级中使 用。 一种有计划的、系统化的方法,以使管理者确信已定义的标准、 实践、规程和过程方法得到了实施。 产品或服务的一种属性,相关干系人可以由此判断产品或服务 的质量。质量属性的特征可以通过一些适当的度量项得到描 述。 质量属性是非功能性的,如及时性、吞吐量、响应能力、安全性、 可修改性、可靠性以及易用性。它们对于架构有显著影响。 用于满足质量需求的操作性的技术和活动。(另见“质量保 证”。) 使用统计与其它量化技术来管理项目或工作组,以对照项目或 工作组的质量与过程性能目标,建立对过程的性能或预计性能 的理解,并识别可能需要采取的纠正措施。(另见“统计技术”。) 在量化管理中所使用的统计技术包括:分析、创建或使用过程性 能模型;分析、创建或使用过程性能基线;控制图的使用;偏差 分析、回归分析;置信区间或预测区间的使用;敏感度分析;模 拟以及假设检验等。 用定量的度量项来表示的期望目标值。(另见“度量项”,“过 程改进目标”与“质量与过程性能目标”。) (见“量化管理”。) 382 术语表 CMMI 开发模型,版本 1.3 参考模型 (reference model) 相关干系人 (relevant stakeholder) 表示法 (representation) 必需的 CMMI 组件 (required CMMI components) 需求 (requirement) 需求分析 (requirements analysis) 需求挖掘 (requirements elicitation) 需求管理 (requirements management) 需求可追溯性 (requirements traceability) 投资回报 (return on investment) 风险分析 (risk analysis) 风险识别 (risk identification) 一个作为基准来度量某一属性的模型。 被识别需要参与规定的活动并被纳入计划的干系人。(另见“干 系人”。) CMM 组件的组织、使用和展现方式。 总体而言,有两种表示最佳实践的明确方法:阶段式表示法与连 续式表示法。 在某一给定的过程域中,为达成过程改进所必不可少的 CMMI 组件。 特定目标和通用目标为必需的模型组件。在评估中,目标的达成 作为确定一个过程域是否得到满足的基础。 (1)用户解决问题或达成某一目标所需的条件或能力;(2) 为满足供方协议、标准、规格说明或其它正式提出的文件,产 品、服务、产品组件或服务组件必须满足或拥有的条件或能力; (3)(1)或(2)中提到的条件或能力的文档化表述。(另 见“供方协议”。) 基于分析,对产品或服务的具体功能与质量属性特征的确定。 分析的对象包括客户需要、期望及制约;操作概念;人员、产 品、服务与过程的预计使用环境;以及有效性度量等。(另见 “操作概念”。) 使用诸如原型与结构化调查等系统化技术,以主动识别并文档 化客户与最终用户的需要。 对项目或工作组收到或生成的所有需求进行的管理,需求包括 技术与非技术需求,以及组织指派给项目或工作组的需求。(另 见“非技术需求”。) 需求与相关需求、实现以及验证之间可辨别的关联性。(另见 “双向可追溯性”与“可追溯性”。) 从输出物(产品或服务)得到的收入与生产成本的比率。这一 比率决定了组织能否通过执行一项行动来生产某物而获得利 益。 对风险进行的评价、分类以及优先级设定。 一种有序而深入的方法,用以找出目标达成中可能的或现实的 风险。 术语表 383 CMMI 开发模型,版本 1.3 风险管理 (risk management) 高层管理人员 (senior manager) 服务 (service) 服务协议 (service agreement) 一个有序的、分析型的过程,用于识别什么可能造成伤害或损 失(识别风险);评估并量化已识别的风险;制订并在必要时 实施一个适当的方案,来防止或处理可能造成重大伤害或损失 的风险原因。 风险管理往往围绕开发或交付产品或服务的项目、工作组、组织 或其他组织级单元的活动来开展。 组织中处于足够高级别的管理者角色。担任该角色的人员的首 要关注点在于组织的长期生命力而非短期考虑与压力。(另见 “上级管理层”。) 高层管理人员有权指示资源的分配或再分配,以支持组织级过程 改进的有效性。 任何满足上述条件的管理人员都可以是高层管理人员,包括组织 的负责人。高层管理人员的同义词有“执行官”与“最高管理层”。 然而,为了保证一致性与易用性,这些同义词在 CMMI 模型中并 未使用。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。 一种无形且不可储存的产品。(另见“产品”,“客户”与“工 作产品”。) 通过使用为满足服务需求而设计的服务系统来交付服务。(另见 “服务系统”。) 许多服务提供方既提供服务也提供货物。单个服务系统能够同时 交付这两类产品。例如,一家培训机构可以在交付培训服务的同 时交付培训材料。 服务可通过人工与自动化过程的结合进行交付。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。 服务提供方与客户之间一份对价值交换进行承诺的有约束力 的书面记录。(另见“客户”。) 服务协议可以是完全可协商、部分可协商或不可协商的,可以视 情况由服务提供方起草,或由客户起草,或由双方共同起草。 “承诺的价值交换”是指双方为满足协议而对各自需要提供给对 方的内容的共同认可与接受。客户往往支付钱款作为对已交付服 务的报酬,但也有可能是其它安排。 “书面”记录并不需要集中体现在一份文档或其它产物中。另外, 在某些类型的服务中该记录可能极其简单(例如一份只标识了某 项服务与其价格和抬头的票据)。 384 术语表 CMMI 开发模型,版本 1.3 服务目录 (service catalog) 服务事件 (service incident) 服务水平 (service level) 服务水平协议 (service level agreement) 服务水平度量项 (service level measure) 服务线 (service line) 服务请求 (service request) 一份标准化的服务定义列表或库。 服务目录可以包括可提供的服务水平、质量、价格、可协商/可 裁剪的项目、条款与条件等不同程度的细节。 服务目录不需要包含在单份文档或其它产物中,它可以是提供同 等信息(例如链接到数据库的网页)的多个条目组合。另外,在 某些服务中,一份有效的目录也可以是一张简单印有可提供的服 务及其价格的菜单。 服务目录信息可以被划分成不同的子集,以支持不同类型的干系 人(如客户、最终用户、提供方员工、供方)。 服务中实际的或潜在的干扰迹象。 服务事件可能在任何服务领域发生。因为客户与最终用户的投诉 都是某些类型的事件,而即便是最简单的服务也会产生投诉。 当上下文内容意义清晰时,可用“事件”代替“服务事件”以示 简洁。 已定义的服务交付绩效的尺度、程度或质量。(另见“服务” 与“服务水平度量项”。) 明确说明了下列事项的服务协议:所交付的服务;服务度量项; 可接受与不可接受的服务水平;以及在一些预期的场景中提供 方与客户双方期望的职责、责任与行动。(另见“度量项”, “服务”与“服务协议”。) 服务水平协议是将此定义中的细节文档化的服务协议。 在使用“服务协议”这一术语时,“服务水平协议”总是作为子 类含在其中,前者可替代后者使用以示简洁。然而,为了强调存 在不同层次的可接受服务,或服务水平协议的其它细节可能对讨 论有重要影响时,“服务水平协议”是首选术语。 与服务水平相关联的服务交付绩效的度量项。(另见“度量项” 与“服务水平”。) 满足所选市场或任务区域特定需要的一套已整合的标准化服 务与服务水平。(另见“产品线”与“服务水平”。) 来自客户或最终用户的,需要一个或多个特定服务交付实例的 沟通。(另见“服务协议”。) 这些请求在服务协议背景下做出。 在需要持续或定期交付服务的情况下,一些服务请求可能会在服 务协议本身中得到明确识别。 在其它情况下,属于先前建立的服务协议范围内的服务请求随时 间推移由客户或最终用户根据其需要的发展而提出。 术语表 385 CMMI 开发模型,版本 1.3 服务需求 (service requirements) 服务系统 (service system) 服务系统组件 (service system component) 服务系统消耗品 (service system consumable) 共同愿景 (shared vision) 软件工程 (software engineering) 招标 (solicitation) 影响服务交付与服务系统开发的需求的完整集合。(另见“服 务系统”。) 服务需求包括技术与非技术需求。技术需求指的是所交付服务的 属性与使交付成为可能而所需要的服务系统的属性。非技术需求 可能包括附加条件、规定、承诺、协议规定的条款、法规以及源 于业务目标的所需能力与条件。 满足服务需求的、由组件资源构成的集成化的、相互依存的组 合体。(另见“服务系统组件”与“服务需求”。) 服务系统包含服务交付必需的一切,包括工作产品、过程、设施、 工具、消耗品以及人力资源。 需要注意的是一个服务系统还包括了执行服务系统过程的必要人 员。在最终用户为完成服务交付而执行某些过程的情况下,那些 最终用户也是服务系统的一部分(至少在那些互动期间内)。 一个复杂的服务系统可以被分割成多次不同的交付与多个支持系 统或子系统。这些分割与不同之处可能对服务提供方的组织来说 有其重要性,而对其他干系人来说可能并不那么有意义。 为了成功交付服务所需要的资源。 在服务交付开始前及服务交付结束后,客户、最终用户、或第三 方可以继续拥有一些组件。(另见“客户”与“最终用户”。) 一些组件可以是短暂资源,它们在一段有限的时间内属于服务系 统(例如,在维修车间处于维修中的物品)。 组件可以包括过程与人。 在含义明确的上下文内容中,为了简洁,“组件”这个词可以用 来替代“服务系统组件”。 “基础设施”这个词可以统一表示有形的和本质上永久性的服务 系统组件。根据服务的场合与类型,基础设施还可以包括人力资 源。 在服务交付期间,变得不再可用或者由于使用而发生永久性改 变的服务系统组件。 燃料、办公用品与一次性容器是常用消耗品的几个例子,特定类 型的服务可以有自己的专用消耗品。(例如:一个卫生保健服务 可能需要药物或者血液供应)。 人不是消耗品,但是他们的劳动时间是消耗品。 对于指导原则的共同理解,包括任务、目标、预期行为、价值 与最终的结果,这些是由一个项目或者工作组开发并使用的。 (1)系统化、规范化并可量化的方法在软件开发、运行及维 护中的应用。(2)对于(1)中的方法的研究(另见“硬件工 程”与“系统工程”。) 准备用于选择供方的文件包的过程。(另见“招标文件包”。) 386 术语表 CMMI 开发模型,版本 1.3 招标文件包 (solicitation package) 偏差的特殊原因 (special cause of variation) 特定目标 (specific goal) 特定实践 (specific practice) 稳定的过程 (stable process) 阶段式表示法 (staged representation) 干系人 (stakeholder) 标准(名词) (standard [noun]) 标准过程 (standard process) 工作说明书 (statement of work) 一个正式的文档集合,包括对于期望的潜在供方响应形式的描 述,供方相关工作说明书,以及在供方协议中所需的条款。 某些暂时情况下特有的缺陷原因,它不是过程的固有组成部 分。(另见“偏差的共同原因”。) 必需的模型组件,它描述了为满足过程域而必须呈现出的独特 特征。(另见“能力等级”,“通用目标”,“组织的业务目 标”与“过程域”。) 期望的模型组件,它在达成相关的特定目标中被认为起着重要 作用。(另见“过程域”与“特定目标”。) 特定实践描述活动,这些活动预期导致过程域中特定目标的达成。 处于特殊原因已经得到排除并且已预防再发生的状态,从而仅 留下过程偏差的共同原因。(另见“有能力的过程”,“偏差 的共同原因”,“偏差的特殊原因”与“标准过程”。) 一种模型结构,在这种结构中,通过达到一组过程域目标来建 立一个成熟度级别;每一个级别都为其后续级别建立了基础。 (另见“成熟度级别”与“过程域”。) 受到某项工作结果的影响,或对某项工作结果以某种方式负有 责任的组或个人。(另见“客户”与“相关干系人”。) 干系人可能包括项目或者工作组成员、供方、客户、最终用户及 其他。 该术语除了通常的字面含义,在 CMMI 产品套件中还具有特殊含 义。 已开发并用于规定一致方法的正式需求,这些方法用于采购、 开发或服务。 标准的实例有 ISO/IEC 标准,IEEE 标准与组织级标准等。 基本过程的可操作定义,它指导组织内公共过程的建立。 标准过程描述了过程的基本元素,这些元素将会纳入任何已定义 的过程中。它也描述了这些过程元素间的关系(例如顺序、接口)。 (另见“已定义的过程”。) 对将要执行工作的描述。 术语表 387 CMMI 开发模型,版本 1.3 统计与其它量化技术 (statistical and other quantitative techniques) 统计过程控制 (statistical process control) 统计技术 (statistical techniques) 子实践 (subpractice) 子过程 (subprocess) 供方 (supplier) 供方协议 (supplier agreement) 维持 (sustainment) 多系统构成的系统 (system of systems) 通过量化任务的参数使一项活动能够完成的分析技术。(例如: 输入、规模、工作量与性能)。(另见“统计技术”与“量化 管理”。) 这一术语在高成熟度过程域中使用,这些过程域描述了通过使用 统计与其它量化技术来改进对项目、工作及组织级过程的理解。 非统计类的量化技术实例包括趋势分析、运行图、帕累托分析、 柱状图、雷达图以及数据平均法。 在 CMMI 中使用“统计与其它量化技术”这一复合术语是为了告 知读者,尽管统计技术期望得到应用,其它量化技术也同样可以 进行有效使用。 基于统计的过程与过程性能度量项分析,识别过程性能偏差的 共同原因与特殊原因,并把过程性能维护在界限内。(另见“偏 差的共同原因”、“偏差的特殊原因”与“统计技术”。) 源于数理统计领域的技术,用于诸如描述过程性能特征、理解 过程偏差并预测结果之类的活动。 统计技术的例子包括采样技术、方差分析、卡方检验及过程控制 图。 说明性模型组件,它为解释和实施特定实践或通用实践提供指 导。 子实践的措辞可能会让人感觉是规定的作法,不过它们实际仅旨 在为过程改进提供可能有用的思路。 一个过程,它是更大过程的一部分。(另见“过程”,“过程 描述”与“过程元素”。) 过程可以进一步分解为更小粒度的子过程或过程元素,或不可以 分解。术语“过程”、“子过程”与“过程元素”形成一个层次 结构,“过程”是最高级、最通用的术语,“子过程”在其之下, “过程元素”则最为具体。如果子过程不被进一步分解成子过程, 那它就可以称为过程元素。 (1)交付产品或者执行所采购的服务的实体。(2)个人、合 作伙伴、公司、企业、协会或者其它实体,它们与采购方拥有 设计、开发、制造、维护、修改的协议,或根据协议条款供应 物品。 采购方与供方之间的文档化的协议。(另见“供方”。) 供方协议也称为合同、许可证与协议备忘录。 用于确保产品或者服务能够保持运行的过程。 当独立且有用的系统集成为一个具有独特能力的大系统时,所 形成的系统集合或者系统排列。 388 术语表 系统工程 (systems engineering) 裁剪 (tailoring) 裁剪指南 (tailoring guidelines) 目标概览图 (target profile) 目标阶段 (target staging) 团队 (team) CMMI 开发模型,版本 1.3 为了把客户的需要、期望与约束转换成解决方案并在它的整个 生命期内支持该解决方案,而对所需要的全部技术与管理工作 进行支配的跨学科的方法。(另见“硬件工程”与“软件工程”。) 该方法包括对技术性能度量项的定义,为建立架构而对多个工程 专业的集成,以及对用于平衡成本、进度与性能目标的辅助性生 命周期过程的定义。 为达到特别的目的而对某事物进行制订、修改或调整的行为。 例如,项目或工作组通过裁剪组织的标准过程集来建立其已定义 的过程,以满足其目标、约束与环境。同样,服务供应商为特定 的服务协议裁剪标准服务。 组织级指南,它使得项目、工作组与组织级职能部门能够适当 地调整标准过程为他们所用。 组织的标准过程集描述得比较概要,可能无法直接用于执行某一 过程。 裁剪指南帮助人员为项目或工作组建立已定义的过程。裁剪指南 包括:(1)选择标准过程;(2)选择经批准的生命周期模型; (3)裁剪所选的标准过程与生命周期模型以适合项目或工作组的 需要。裁剪指南描述可修改与不可修改之处,并标识出可供修改 的候选过程组件。 代表过程改进目标的过程域及过程域对应能力等级的列表。 (另见“达成情况概览图”与“能力等级概览图”。) 目标概览图只在使用连续式表示法时可用。 目标概览图的序列,它描述组织将要遵循的过程改进路径。(另 见“达成情况概览图”,“能力等级概览图”与“目标概览图”。) 目标阶段只在使用连续式表示法时可用。 具有互补的技能与专业知识的一组人,他们共同工作以完成规 定的目标。 团队建立并维护一个过程,该过程识别了角色、职责与接口;该 过程足够明确,使得团队能够度量、管理并改进他们的工作绩效; 使团队能够做出并捍卫他们的承诺。 团队成员共同为他们工作的各方面(例如,为工作产品生命期的 不同阶段)提供适合的技能与支持,并且负责完成规定的目标。 并非所有项目或工作组成员都必须属于一个团队(例如,主要以 独立方式完成任务的人)。因此,大项目或工作组可以由许多团 队组成,也可以包括不属于任何团队的项目成员。更小型项目或 工作组可以只包括一个团队(或者一个单独的个人)。 术语表 389 CMMI 开发模型,版本 1.3 技术数据包 (technical data package) 技术性能 (technical performance) 技术性能度量项 (technical performance measure) 技术需求 (technical requirements) 可追溯性 (traceability) 权衡分析 (trade study) 培训 (training) 单元测试 (unit testing) 一些项的集合,如果下列信息适用于产品与产品组件的类型 (例如,原料与制造需求可能不适用于软件服务或过程相关的 产品组件),该集合可以包括下列各项: • 产品架构描述 • 已分配需求 • 产品组件描述 • 与产品相关的生命周期过程描述,如果不作为独立的产品 组件进行描述 • 关键产品特性 • 必需的物理特性与约束 • 接口需求 • 材料需求(材料清单与材料特性) • 加工与制造需求(既有对原始设备制造商的,也有对现场 支持的) • 用于确保需求已经得到满足的验证准则 • 贯穿产品整个生命期的使用条件(环境)、运行/使用场 景、运行模式与状态、支持、培训、制造、废弃与验证 • 决策与特性(例如,需求、需求分配与设计选择)的依据 过程、产品或服务的特性,一般由功能或技术需求来定义。 技术性能类型的例子包括估算的准确性、最终用户功能、安全性 功能、响应时间、组件准确性、最大重量、最小吞吐量、允许范 围。 需求、能力或需求与能力的某种组合的精确定义的技术度量 项。(另见“度量项”。) 待采购或开发的产品或服务的性质(即属性)。 两个或多个逻辑实体,例如需求、系统元素、验证或任务,之 间的一种可辨别的关联。(另见“双向可追溯性”与“需求可 追溯性”。) 一种对备选方案的评价,该评价基于准则与系统化分析,选择 最佳备选方案以达到既定目标。 正式的与非正式的学习选项。 这些学习选项可以包括:课堂培训、非正式的辅导、基于网络的 培训、有指导的自学、以及正式的在岗培训项目。 各种情况的学习选项的选择基于对培训需要以及要处理的绩效差 距的评估。 对单个硬件或软件单元或相关单元组合的测试。(另见“验收 测试”。) 390 术语表 CMMI 开发模型,版本 1.3 确认 (validation) 验证 (verification) 版本控制 (version control) 工作分解结构(WBS) (work breakdown structure [WBS]) 工作组 (work group) 工作计划 (work plan) 工作产品 (work product) 工作产品与任务属性 (work product and task attributes) 工作启动 (work startup) 确定提供的(或将要提供的)产品或服务将满足其预期的用途。 换句话说,确认确保“做了正确的事”。(另见“验证”。) 确定工作产品适当地反映了其规定的需求。 换句话说,验证确保“正确地做了事”。(另见“确认”。) 基线的建立与维护及基线变更的识别,这使恢复到以前的基线 成为可能。 某些场合中,一个独立的工作产品可能具有自己的基线,并且低 于正式配置控制的控制水平可能就足够。 工作元素、其彼此关系以及工作元素与最终产品或服务间关系 的一种安排。 人员与其它已分配资源组成的一个已管理的集合,其将一个或 多个产品或服务交付给客户或最终用户。(另见“项目”。) 工作组可以是具有已定义目标的任意组织级实体,不论该实体是 否在组织结构图中。工作组可以出现在组织的任何级别,也可以 包含其它的工作组,并且可以跨越组织级边界。 如果有意限定了生命期,那么可以认为工作组连同其工作与项目 是相同的。 工作组的活动及相关资源分配的计划。 工作计划包括估算工作产品与任务属性、确定所需的资源、协商 承诺、安排进度、以及识别并分析风险。建立工作计划时可能有 必要重复执行这些活动。 过程的有用结果。 此结果可以包括文件、文档、产品、产品部件、服务、过程描述、 规格说明与发货单。工作产品与产品组件间的一个关键区别是: 工作产品不必是最终产品的组成部分。(另见“产品”与“产品 组件”。) 在 CMMI 模型中,虽然工作产品的定义包含服务,但是,有时使 用短语“工作产品与服务”来强调讨论中包含服务。 产品、服务与任务的特性,用来帮助对工作进行估算。这些特 性包含规模、复杂度、重量、形状、适配方式与功能。它们通 常被用作导出其它资源(例如,工作量、成本与进度)估算的 输入。 为工作组指定了一组相关的资源给客户或最终用户,以开发或 交付一个或多个产品或服务的时候。(另见“工作组”。) 术语表 391 CMMI 开发模型,版本 1.3 392 CMMI 开发模型,版本 1.3 REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 1. AGENCY USE ONLY 2. REPORT DATE 3. REPORT TYPE AND DATES (Leave Blank) November 2010 COVERED Final 4. TITLE AND SUBTITLE 5. FUNDING NUMBERS CMMI® for Development, Version 1.3 FA8721-05-C-0003 6. AUTHOR(S) CMMI Product Development Team 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 8. PERFORMING ORGANIZATION REPORT NUMBER CMU/SEI-2010-TR-033 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) HQ ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2116 10. SPONSORING/MONITORING AGENCY REPORT NUMBER ESC-TR-2010-033 11. SUPPLEMENTARY NOTES 12A DISTRIBUTION/AVAILABILITY STATEMENT 12B DISTRIBUTION CODE Unclassified/Unlimited, DTIC, NTIS 13. ABSTRACT (MAXIMUM 200 WORDS) CMMI® (Capability Maturity Model® Integration) models are collections of best practices that help organizations to improve their processes. These models are developed by product teams with members from industry, government, and the Carnegie Mellon® Software Engineering Institute (SEI). This model, called CMMI for Development (CMMI-DEV), provides a comprehensive integrated set of guidelines for developing products and services. 14. SUBJECT TERMS CMMI, Development, CMMI for Development, Version 1.3, software process improvement, reference model, product development model, development model, CMM 16. PRICE CODE 15. NUMBER OF PAGES 468 17. SECURITY CLASSIFICATION OF REPORT Unclassified NSN 7540-01-280-5500 18. SECURITY CLASSIFICATION OF THIS PAGE Unclassified 19. SECURITY CLASSIFICATION 20. LIMITATION OF OF ABSTRACT ABSTRACT Unclassified UL Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102 393 CMMI 开发模型,版本 1.3 394
更多简介内容

评论

下载专区


TI最新应用解决方案

工业电子 汽车电子 个人消费电子

$(function(){ var appid = $(".select li a").data("channel"); $(".select li a").click(function(){ var appid = $(this).data("channel"); $('.select dt').html($(this).html()); $('#channel').val(appid); }) })