北京大学工程硕士软件工程教材第七章软件过程与改善

《北京大学工程硕士软件工程教材第七章软件过程与改善》由会员分享，可在线阅读，更多相关《北京大学工程硕士软件工程教材第七章软件过程与改善（109页珍藏版）》请在装配图网上搜索。

1、,第七章、软件过程与改善 1、软件过程 软件过程：活动的一个集合； 活动：任务的一个集合； 任务：将一个输入转换为一个输出的操作。 基本过程类 按性质可分为三类过程： 支持过程类 组织过程类,1基本过程类 是指那些与软件生产直接相关的过程。 包括5个过程：获取过程、供应过程、开发过程、 运行过程、维护过程 例如1：开发过程 是软件开发者所从事的一系列活动。 包括13个活动： 过程的实施准备 系统需求分析 系统结构设计 软件需求分析 软件体系结构设计 软件详细设计 软件编码和测试 软件集成 软件合格测试 系统集成 系统合格测试 软件安装 软件验收支持,其中的活动：过程的实施准备 目的：为开发过程

2、准备基本的约定。 -建立过程模型 主要任务： 依据合同和软件或系统的特点，选择开发过程中活 动，这些活动可重复和关联，亦可循环； 制定本过程计划，其中至少包括：所需的标准，方 法，工具，行为，责任以及所使用的程序设计语言； 指定各种文档的编制方式，安排其他支持过程的实 施方法。,其中的活动：软件需求分析 目的：确定软件需求及质量特性需求。 主要任务： 编制软件需求规格说明书 检查软件需求： 是否能够跟踪系统需求、结构； 从外部上，是否与系统需求保持一致； 需求内部的一致性； 是否具有可测性； 测试覆盖是否可达到要求； 操作（设计和实现），维护的可行性等,其内容包含： 功能和性能需求； 外界与软

3、件的接口 合格需求； 安全需求； 保密需求； 人机界面需求； 数据定义和数据库需求； 用户文档； 用户操作和运行需求； 用户维护需求,2支持过程类 是有关各方按其目标所从事的一系列的支持活动。 包括8个过程：文档过程、配置管理过程、质量保证、 验证过程、确认过程、联合评审、审计过程、问题解决等。 例如2：文档过程 是一个记录由某一过程或活动所产生信息的过程 包括4个活动：过程的实施准备 设计与开发 制作与发行 维护 其中的活动：过程的实施准备 主要任务：制定文档编制计划。确定： 需产生的所有文档；文档框架；以及 预期的使用 者；制作过程；参加人员及其责任；计划进度等,其中的活动：设计与开发 主

4、要任务： 根据适用的文档标准，设计每一文档的格式、内 容说明、图表设置以及包装等。 应保证个文档输入数据的来源和适用性； 应对所编制的文档格式、技术内容以及表达方式 进行审查。在分发前需经主管人员批准。,3组织过程类 是指那些与软件生产组织有关的过程。 包括4个过程：管理过程、基础设施过程、培训过程、 改进过程 例如3：管理过程 是软件生存周期过程中管理者所从事的一系列活动。 一般可包括5个活动： 过程的实施准备 管理计划的制定 计划的实施与控制 计划完成程度的评审 管理过程完成的文档编制,其中的活动：管理计划的制定 主要任务： 规定进度 分配资源 决定项目的有关组织 承担人员（地位，作用，职

5、责，制度等） （根据规模和工作量估计）进行任务分配 定量风险分析 制定质量管理指标 编制预算和成本 准备环境和基础设施等 其中的活动：计划的实施与控制 主要任务：监督过程的实施 提供过程进度报告 按合同向获取方提供外部报告 调查、分析和解决执行过程中发现的问题 计划调整和修改等,例如4：改进过程 是建立、评估、度量、控制和改进软件生存周期过程 的过程。 主要活动： 制定一套组织计划 评估相关过程 分析、改进过程 例如4：基础设施过程 （基础设施包括：硬件、软件、工具； 技术、标准以及开发所需的其他设施） 是建立、维护任何其他过程所需的基础设施的过程。 主要活动： 定义并建立各过程所需的基础设施

6、 维护其他过程所建立的基础设施,4）剪裁过程： 目的：针对特定领域的软件工程，为了有效地实施软件过程，提供一种选定过程模型和标准的机制，以便形成该工程的各个软件过程和活动。 剪裁过程作为一类软件过程，是对软件过程和活动实施剪裁的过程。 主要活动： 指明工程环境 收集信息 选取过程、活动和任务 编制文档 如：指明工程环境 指明影响剪裁的工程环境特征，例如使用的过程模型和方法，系统和软件需求，机构的政策和策略，参与工程的人员素质、数量等。,5软件过程之间的关系,获取过程,获取过程,供应过程,管理过程,运行过程,开发过程,维护过程,获取者 供应者,管理者,运行者 用 户,开发者 维护者,开发者 维护

7、者,组织过程：管理、改进.,支持过程：文档、质量保证、 配置管理 .,合 同,使 用,合同观点,管理观点,运行观点,开发观点,支持观点,2、ISO 9000-3简介 1）目的与背景 ISO 9000系列标准，旨在指导：高质量产品的生产、评价、认证。 ISO 9000系列标准包括： ISO 9000 质量管理和质量保证标准-选择与使用导则 ISO 9001 质量体系-设计/开发、生产、安装和服务中的质量保证模式 ISO 9002 质量体系-生产和安装中的质量保证模式 ISO 9003 质量体系-最终检验和测试中的质量保证模式 ISO 9004 质量管理和质量体系要素-导则,其中： ISO 900

8、1、ISO 9002、ISO 9003，是“需方对供方 要求质量保证”的标准。 它们之间的主要区别是工序范围不同，即： ISO 9001范围最广，从设计一直到售后服务， ISO 9002是ISO 9001的一个子集 ISO 9003又是ISO 9002的一个子集 ISO 9004是用于“供方建立质量保证体系的标准”,ISO 9000系列标准的其主导思想是： 产品质量形成于产品生产的全过程。于是： 应使影响产品质量的全部因素，在生产全过程中始终 处于受控状态；并且 质量管理应遵循PDCA循环（即计划Plan实施Do检 查Check措施Action），坚持进行质量改进。,ISO 9000-3标准产

9、生背景 ISO 9000系列标准原本是为制造业而制定的标准，通过在软件开发中的应用，发现效果并不是十分理想。 其主要原因是：传统制造业的产品生产与软件开发具有很大 的差异。 在过程方面：制造业的产品需要经历“设计”、“生产”、“储存”、“发布”、“销售”、“运输”、“服务”等过程，而软件产品/系统基本上不需要“储存”、“运输”等过程； 在固有本质方面：与传统制造业产品生产相比，软件开发还具有自己的一些特点，例如： “设计”是核心，且“设计”到“生产”过渡的时间间隔“很小”； 软件质量检验技术与工具尚不完善；,由于软件是知识的固化，因此不但产品的复杂度比传统制造业的产品要高，而且随着知识的快速发

10、展，软件产品/系统更新和演化更快； 开发环境需要有助于开发人员创造性的发挥；特别是，软件开发又是团队协同的工作，需要将软件开发的个人性与群体性有机结合起来； 于是，国际标准化组织以ISO 9000系列标准为基础，以“追 加”形式，制定了ISO 9000-3标准，成为“使ISO 9001适用 于软件开发、供应及维护”的“指南”。,ISO 9000-3与相关标准之间关系,ISO 9001：质量体系设计、开发、生产、安装和服务的质量保证模式,ISO/IEC 12207 ：信息技术软件生存周期过程,ISO 9000-3：质量管理和质量保证标准第3部分：ISO9001：1994在计算机软件开发、供应、安

11、装和维护中的使用指南,解释和实施指南,参照,2） ISO 90003要点 ISO 9000-3主要是给出了软件开发中的质量体系框架。 其中包括：供需双方的责任，供需双方所进行的一些有组 织的质量活动，以及与之相关的规范化（文档化）。而没 有规定质量管理以及每一活动所采用的方法和程序。 因此可以说，ISO 9000-3是质量体系这一概念在注重质量的软件开发中之应用；目的是：为软件企业实施ISO 9001提供了一个指南。 （1） 质量体系费根堡姆： “在制造及传递某种合乎特定质量标准的产品时， 必须配合适当的管理及技术作业程序，这些程序 所组成的结构，称之为质量体系”。,（2）软件质量的定义 AN

12、SI/IEEE Std 729-1983 ：软件质量为“与软件产品满足 规定的和隐含的需求能力有关的特征或特性的全体”。 软件质量反映了以下三方面的问题： 软件需求是度量软件质量的基础，不满足需求的软件就 不具备质量； 不遵循各种标准中定义的开发规则，软件质量就得不到 保证； 只满足明确定义的需求，而没有满足应有的隐含需求， 软件质量也得不到保证。,软件质量模型-McCall,正 确 性,可 靠 性,效 率,完 整 性,可 用 性,可 维 护 性,灵 活 性,复 用 性,可 测 试 性,可 移 植 性,互 连 性,可测试性 完 备 性 一 致 性 安 全 性 容 错 性 准 确 性 简 单 性

13、 执行效率 存储效率 存贮控制 存取检查 操 作 性 ,质量因 素,评测 准则,质量因素： 正确性：在预定的环境下，满足设计规格说明及用户预期 目标的程度。它要求软件没有错误。 可靠性：软件按着设计要求，在规定时间和条件下，持续 运行的程度。 效 率：为了完成预定功能，软件所需计算机资源多少。 完整性：为了某一目的而保护数据，避免受到偶然的，或 有意的破坏、改动或遗失的能力。 可用性：对于一个软件系统，用户学习、使用以及为程序 准备输入和解释输出所需工作量的大小。 可维护性：为满足用户新的要求，或环境发生了变化，或 发生了新的错误，进行相应诊断和修改所需工作 量的大小。,可测试性：测试软件以确

14、保能够执行预定功能所需工作量 的大小。 灵 活 性：修改或改进已运行的软件所需工作量的大小。 可移植性：将一个软件系统从一个计算机系统或环境移植 到另一计算机系统或环境中所需工作量的大小。 复 用 性：一个软件能够再次用于其它应用的程度。 互 连 性：将一个软件连接到其他系统所需工作量的大小 （连接：意指联网，通信，控制等） 该质量因素也称为互操作性。,各评测准则的含义： 可跟踪性：在特定的软件开发和运行的环境下，追溯设 计表示的能力或实际程序部件追溯原始需求的能力。 完 备 性：软件需求得以实现的程度。 一 致 性：在软件设计和实现的整个过程中，技术和表示 的一致程度。 安 全 性：防止软件

15、受到有意或无意存取、使用、修改、 毁坏以及泄密的程度。 容 错 性：当系统出现错误，例如机器故障，输入不合理 的数据等，能以某种预定方式进行适当处理，使系统 继续执行以及恢复系统的能力。也称为健壮性。,准 确 性：软件系统实现计算或控制精度的程度。 简 单 性：在可理解的简单方式下，定义并实现软件功能的 程度。 执行效率：为实现某种功能，提供使用最少处理时间的程度。 存贮效率：为实现某种功能，提供使用最少存贮空间的程度 存取控制：对用户存取权限实施控制的程度。 存取检查：对用户存取进行审查的程度。 操 作 性：操作软件的难易程度。通常，操作性取决于软件 提供的操作规程以及输入/输出方法。,易训

16、练性：软件辅助新的用户使用系统的能力。通常，易 训练性取决于软件提供帮助用户使用系统的方法和方式 简 明 性：软件（程序和文档）易读的程度。有时，也称为 可理解性。 模块独立性：软件模块（部件）实现“高内聚低耦合”的程度 自描述性：软件自身对其功能描述的程度。 结 构 性：软件结构“良好”的程度。 文档完备性：软件文档齐全、描述清楚、满足规范或标准 的程度。 通 用 性：软件功能覆盖可用范围的程度。,可扩展性；软件体系结构、数据设计和过程设计的可扩展 程度。 可修改性：软件容易修改且不会产生副作用的程度。 自 检 性：监控自身操作效果和发现自身错误的能力。 机器独立性：不依赖于特定计算机和特定

17、设备而能工作的 程度。 软件独立性：不依赖非标准程序设计语言特性、操作系统 特性，或其他环境约束，而靠自身能实现其功能的程度 通 信 性：提供有效I/O方式的程度。 通信共享性：使用标准通信协议、接口和带宽的标准化程度 数据共享性；使用标准数据结构和数据类型的程度。,（2） ISO9000-3质量体系要素,软件企业实施ISO9000质量标准，应选择ISO9001质量保证模式，需贯彻执行其20个质量体系要素。 ISO9000-3针对上述20个要素在软件企业中实施做出了解释：“建议”或“最好（should）”。 ISO9000-3与ISO9001标准的文本描述是完全对应的。 下面对每个要素给出具体

18、的解释。,1、管理职责：负责人工作职责 组织制定机构的质量方针、质量目标和质量承诺；保证机构内各级人员理解质量方针，并能贯彻执行。 对所有与质量相关的管理人员、执行人员和验证人员规定职责、权限和相互关系；为相关活动提供充分的资源支持；委派专人负责按标准建立、实施和保持质量体系。 负责定期组织机构内的管理评审，审查质量体系是否满足标准及企业需要，是否持续有效,2、质量体系 建立质量体系，形成文件并加以维护。 编制质量手册，明确质量方针、目标、组织结构等各个方面，以及质量体系文件概要 确定质量手册的管理（制定、修改、批准和控制） 编制有关质量体系要素、需求和预防措施的文件。 质量策划与对质量计划的

19、要求 质量策划：确定质量以及采用质量体系要素的目标和要求的活动。（构思和安排） 质量计划：针对特定产品、项目或合同，规定专门的质量措施、资源和活动顺序的文件。（具体实施） 对新产品、新项目或新合同应制定质量计划。,3、合同评审 在合同签订之前，应对合同、标书或订单进行全面评审，以保证其中的条款能够接受，也有能力满足。 对上述工作程序建立文件定义，并贯彻执行。 评审参与组织及其职责、活动。 评审结论及其管理 合同修订及其管理 4、设计控制 在产品设计方面进行质量控制，并保持稳定、制度化，包括： 设计和开发的策划 组织上的接口和技术上的接口 设计输入，确定对设计输入的要求 设计输出，确定对设计输出

20、的要求 设计评审，设计验证， 设计确认， 设计更改,设计和开发的策划 开发策划包括：确定需求分析、设计、编码、集成、 测试、安装和支持软件产品验收等各项活动，并按 开发计划的方式形成文件。 开发策划宜涉及下列事项： 项目定义、项目输入与输出、项目资源的组织、 组织接口和技术接口、进度安排、使用工具、技术、 配置管理等方面。 制定开发计划，并标明相关计划（质量计划、配置 管理计划、集成计划、测试计划、移交计划、培训计划、 维护计划、重用计划） 开发计划主要包括：确定项目如何管理、要求的进度 评审，并考虑合同的要求，规定提交管理者、顾客和 其他有关各方的报告类型和频次。 开发计划和有关计划可以是一

21、份独立文件，或是另 一文件的部分或由若干文件组成。,组织和技术接口 规定软件产品各部分的职责范围和在各部门之间传递 技术信息的方式；可以要求分承包方提交开发计划， 以供评审。 确定接口时，要仔细考虑在顾客和供方之外需参与设 计、安装、维护和培训活动的各方，以保证得到适当的 能力和培训，达到承诺的服务水平。 明确按合同规定顾客可能有某些职责，并解决有关的 事项。 进行供方和顾客同时参与的联合评审，定期安排或在 发生重大项目事件时进行。联合评审要覆盖下述方面： 供方软件开发的进展；顾客同意承担活动的进展； 开发的产品是否符合需求规格说明；开发中涉及系 统最终用户的活动的进展； 验证结果； 验收测试

22、 结果等。,设计输入（需求规格说明书） 需求规格说明最好由顾客提供，也可以由供方提供。 需建立制定规格说明的形成文件的程序，包括商定需 求和授权更改的方法、对原型或演示的评价方法、记 录和审查双方讨论的结果、明确定义术语、解释需求 背景等。要取得顾客对需求规格说明的认可。 可以采用交谈、调查、研究、提供原型、演示和分析 等方法制定需求规格说明。 需求规格说明在接受和同时可以不完全明确，在项目 进行期间可以继续制定，也可以修订合同，对其更改 最好加以控制。 需求包括用户要求的所有方面，包括但不限于ISO/IEC 9126中的各个特性。 需求最好用产品验收时能确认的形式来表达。,设计输出 要求的设

23、计输出最好按照选定的方法予以确定，并形成 文件。这种文件应是正确、完整和符合需求的。 设计输出可以包括：体系结构设计规格说明； 详细设计规格说明；源代码；用户指南 设计评审 供方应对所项目的评审过程做出计划，并加以实施。 评审活动的正式程度和严格程度，应与产品复杂性及软 件产品规定用途关联的风险程度相适应。 应形成处理这些活动期间发现的过程缺陷和产品缺陷、 或不合格事项的程序文件。 设计评审中最好考虑设计活动的内在因素，如可行性、 安全性、编程规划和可测试性。 评审结果以及为确保规定要求所需的进一步活动，最好 予以记录，并检查。,设计评审（续） 建议只有当所有已知缺陷都得到满意的解决，或继续

24、进行的风险已知时，才继续进行下一步设计活动。 设计验证 建议在开发过程中，适当地进行设计验证，可以包含 设计输出评审，也可以针对其它开发活动的输出进行。 按照质量计划或程序文件制定验证活动计划，实施设 计验证。 对验证结果和为满足规定要求所需的进一步活动，最 好予以记录，并检查。 建议对任何发现的问题都要予以充分论述并解决。 只有经验证的设计输出才能提交验收和后续使用。,设计确认 在产品提交顾客验收之前，供方最好按规定的预期用途 确认该产品，可以进行多次确认。 对确认的结果和需要进一步采取的措施，建议予以记录， 并且在措施完成时检查。 设计更改 供方应建立和维持用于控制实施任何设计更改的程序，

25、 其目的是为了： 对更改形成文件并证明更改是正确的 评价更改的后果 批准或不批准更改 实施并验收更改,5、文件和资料的控制 应建立并保持形成文件的程序，包括下述两方面文件： 对于本标准相关的所有文件和资料， 外来的原始文件等，如： 标准、参考材料、顾客提供的样本等 文件和资料的批准与发布管理（审批适用性）程序，防止使用失效或作废的文件 文件和资料更改（审批更改）程序，保证文件和资料适用、系统、协调和完整,6、采购 确保采购的产品符合规定要求，包括以下领域： 对分承包方的评价 对采购文件的要求：包括的详细信息要求及审批 对采购产品的检验 7、顾客提供产品的控制 对顾客提供的产品建立并保持储存和维

26、护的控制程序，并形成文件。 产品包括：顾客提供的供应品或有关活动。 若出现损坏、不适用等情况，应予以记录并通告顾客。,8、产品标识和可追溯性 在接受和生产、交付及安装的各阶段对产品以适当的方式进行标识。 这种标识应有唯一性和可追溯性。 对成品与半成品均需管理。 防止产品在加工过程中出现混乱。 9、过程控制 对直接影响产品质量的生产、安装和服务过程进行有效控制，制定程序并形成文件（制度化），控制对象可以是过程本身，也可以是与过程相关的方法、设备、材料、环境以至人员等。 对影响过程质量的所有因素，包括工艺参数、人员、设备、材料、加工和测试方法、环境等加以控制。 具体规定操作方法、使用设备、工具和技

27、术等要求。,10、检验和试验 为了使产品满足规定的要求，应建立并保持进行检验和试验活动的程序，并形成文件，包括： 进货的检验和试验 过程的检验和试验 最终检验和试验 对检验和试验记录的要求 11、检验、测量和试验设备的控制 对用于证实产品符合要求的检验、测量和试验设备建立并保持控制、校准和维修的程序，并形成文件 确认测量任务及所要求的精度，选择合适的设备。 应规定检验、测量和试验设备的采购、验收、定期校验、故障维修等控制程序。 对上述校验、维修等记录需进行管理,12、检验和试验状态 对产品的不同状态，如未检、已检合格、已检不合格等，应严格区分，防止不合格的材料、半成品、部件混入或误用，应明确标

28、识。 13、不合格品的控制 建立和保持对不合格品的控制程序，并形成文件，包括对不合格品的标识、记录、评审、隔离和处置等。,14、纠正和预防措施 为消除实际已出现的不合格品，及其产生根源，应建立并保持相应控制程序，并形成文件。 纠正措施： 有效处理顾客意见和产品不合格报告。 调查与产品、过程和质量体系有关的不合格产生原因，并记录调查结果。 确定消除不合格根源所需的纠正措施，并保证起执行与有效性。 预防措施： 利用适当信息源，已发现、分析并消除不合格的潜在因素。 确保所采取措施的信息提交管理评审。,15、搬运、储存、包装、防护和交付 应建立搬运、储存、包装、防护和交付的控制程序，并形成文件。 提供

29、防止产品损坏或变质的搬运方法。 使用指定的储存场地，规定接收和发放的管理方法。 对装箱、包装和标志过程（包括材料）等进行必要的控制。采取适当的隔离和防护措施。 上述保护在合同要求下，应可以延续到交付的目的地。 16、质量记录控制 应建立并保持对质量记录的标识、收集、编目、查阅、归档、储存、保管和处理的程序，并形成文件。,17、内部质量审核 为验证质量活动和有关结果是否符合计划安排，并确定质量体系的有效性，应对内部质量审核工作建立和保持程序，并形成文件。 18、培训 对所有与质量相关的人员进行培训，明确培训要求并建立程序。 在确定培训需求时，要考虑： 软件产品开发和管理工具、技术、方法； 特定领

30、域知识和技能,19、服务 在规定由服务要求的情况下，应建立并保持有关服务的 实施、验证和报告的程序，并形成文件。 一般的顾客支持在ISO9000-2中描述。 软件产品维护通常分为以下几类：问题解决、接口修 改、功能扩展或性能改进。 如果顾客要求在初始较符合安装之后，对软件产品进 行维护，建议在合同中加以规定。 建议供方建立并维护形成文件的程序实施维护活动， 并且验证这些活动符合规定维护要求。 维护活动也可以是对开发环境、工具和文档的维护。,19、服务（续） 应在合同中说明需维护的软件和维护期限。 所有维护活动应按照供方和顾客事先确定并协商一致 的维护计划或规程实施和管理。 对维护活动应加以记录

31、并保存，供方和顾客协商建立 维护报告提交规则。 20、统计技术 建立并保持为分析过程能力和产品特性所采用的若干 统计技术的实施程序，并形成文件。,3 能力成熟度模型（CMM）简介 1）问题的提出 计算机软件的开发一直是广泛应用计算机的瓶颈。 解决这一问题，初期着重于研究一些新的开发方法和技术， -对提高计算机软件的生产率和质量起到了很大的 作用，但问题并没得到很好解决。 在80年代中期，美国工业界和政府部门开始认识到：在软件开发中，关键的问题在于软件开发组织不能很好地定义和控制其软件过程。 -从而使一些好的开发方法和技术都起不到所期望的作用。 在无纪律的、混乱的软件项目开发状态中，开发组织不可

32、能从软件工程的研究成果中获益。尽管仍有一些软件开发组织能够开发出个别优秀软件，但其成功往往归功于软件开发组的一些杰出个人或小组的努力。,历史的经验表明：一个软件开发组织，只有通过： 建立全组织的有效的软件过程； 采用严格的软件工程方法和管理； 坚持不懈地付诸实践； -才能取得全组织的软件过程能力的不断改进 针对这一问题： 1986年11月，美国卡内基-梅隆大学软件工程研究所（SEI）开始开发过程成熟度框架。 1987年9月，SEI发布了过程成熟度框架的简要描述和成熟度调查表。 1991年，SEI将过程成熟度框架演化为CMM 1.0版：CMU/SEI-91-TR-24、CMU/SEI-91-TR

33、-25。 1993年，SEI根据反馈，提出CMM 1.1版：CMU/SEI-93-TR-25。目前，已经提出CMM 2.0版。,2、过程成熟度的基本概念 软件过程能力：描述(开发组织或项目组)通过遵循其软件过 程能够实现预期结果的程度。 用途：一个组织的软件过程能力，提供了一种预测该组织 承担下一个软件项目可能结果的方法。 软件过程性能：表示(开发组织或项目组)遵循其软件过程所 得到的实际结果。 注意：软件过程能力与软件过程性能之间的关系： 一个是能够实现预期结果的程度，一个是得到的实际结果 一个项目的实际过程性能，可能并不充分反映其所在组织 的整个过程能力。 （由于该项目的具体属性和执行该项

34、目的环境所限）,软件过程成熟度： 一个特定软件过程被明确和有效地定义、管理、测量和 控制的程度。 指明： 一个软件开发组织软件过程能力的增长潜力； -能力提高的基础性 表明一个开发组织软件过程的丰富多样性， -能力提高的可能性 在各开发项目中运用软件过程的一致性。 -能力提高的持续性 这意味着：由于开发组织通过运用软件过程，使各项目 执行软件过程的纪律性一致地增强，导致软件生产率和质量 可以得到不断地的改进。,作用：随着一个软件开发组织的软件过程成熟度的提高， 并通过该组织的方针、标准和组织机构等将其软件过程 规范化和具体化，从而使得开发组织对有关管理和工程 的方法、实践和规程等有明确定义。

35、软件能力成熟度等级： 软件开发组织在走向成熟的过程中，几个具有明确定 义的、可以表征其软件过程能力成熟程度的“平台”。 该平台（每一等级）包含一组过程目标。当一个软件开发 组织达到其中一个目标时，则表明软件过程的一个(或几个)重 要成分得到了实现，从而导致该组织软件过程能力的增长。 作用：每一个成熟度等级为达到下一个等级提供了一 个基础。,关键过程域： 过程域：互相关联的若干个软件实践活动和有关基础设施的集合，即软件实践活动，基础设施。 关键过程域：对某一成熟度等级将起到至关重要的过程域即它们的实施将对达到该成熟度等级的目标起保证作用，这些过程域被称为关键过程域。 每一软件过程成熟度等级均包含

36、一组特定的关键过程域。 关键实践：对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关的基础设施的建立。 “关键实践”的表述，一般只给出“做什么”。 作用：通过实施一个关键过程域中所包含的关键实践（“小”的进化），才可以达到该关键过程域中的目标。,3、CMM的软件过程成熟度框架 通过成熟度级别，定义了在使软件过程成熟的过程 中的 演化状态。,初始级 (1),可重复级 (2),已定义级 (3),已管理级 (4),持续优化级 (5),严格的 过程,标准的一致的 过程,可预言的 过程,持续改善的 过程,CMM将这些演化步骤组织为5个成熟度等级的框架，为持续的过程改进提供了基础。,可见，过程成

37、熟度框架： 描述什么：一条从无序的、混乱的过程达到成熟的、有纪律 的软件过程的进化途径。 怎么描述：集软件过程、软件过程能力、软件过程性能和 软件过程成熟度等概念为一体。 用途：以软件过程成熟度框架，可以导出过程改进策略， 为软件过程的不断改进的历程提供了一份导引图。 -指导软件开发组织不断识别出其软件过程的缺陷 -引导开发组织在各个平台上“做什么”改进（但它 并不提供“如仍做”的具体措施。 基础：软件过程成熟度框架的基础是软件能力成熟度模型。,4、软件能力成熟度模型 -涉及组织，项目，过程能力等要素 回顾：软件过程能力：描述(开发组织或项目组)通过遵 循其软件过程能够实现预期结果的程度。 软

38、件能力成熟度等级：软件开发组织在走向成熟 的过程中，几个具有明确定义的、可以表征 其软件过程能力成熟程度的“平台”。该平 台（每一等级）包含一组过程目标。当一个 软件开发组织达到其中一个目标时，则表明 软件过程的一个(或几个)重要成分得到了实 现，从而导致该组织软件过程能力的增长。,模型作用： 指导软件开发组织 通过确定当前过程的成熟度，并识别出执行软件过程 的薄弱环节，通过解决对软件质量和过程改进至关重 要的若个问题 形成对其过程的改进策略 通过关注并认真实施一组有限的关键实践活动 稳步地改善其全组织的软件过程 使全组织的软件过程能力持续增长,软件能力成熟度等级 初始级 主要特征： 组织：组

39、织通常没有提供开发和维护软件的稳定的环境。 项目：当发生危机时，项目通常放弃计划的过程，回复到编码和测试。 过程能力：不可预测。(unpredictable) 由于： 软件开发无规范； 软件过程不确定、无计划、无秩序； 过程执行不“透明”； 需求和进度失控。 结果：项目的成败完全取决于个人的能力和努力； 软件性能随个人具有的技能、知识和动机的不同而变化， 并只能通过个人的能力进行预测。,可重复级 实现了关键过程域： 软件配置管理、软件质量保证、软件子合同管理、 软件项目跟踪和监督、软件项目规划、需求管理。 主要特征： 组织：将软件项目的有效管理过程制度化，这使得组织 能够重复以前项目中的成功实

40、践。 项目：配备了基本的软件管理控制。 过程能力： 可重复的：即对当前项目的需求分析后制定的，能重复以前的成功实践，尽管在具体过程中可能有所不同。 这是该级的个显著特征,基本可控的：即对软件项目的管理过程是制度化的。 对软件需求和为实现需求所开发的软件产品建立了基 线； 为管理、跟踪软件项目的成本、进度和功能提供了规范； 在项目的策划和服踪过程中规定并设置了监测点； 提供了当不满足约定时的识别方法和纠偏措施。 软件项目过程基本上是可视的 过程是有效的：即对项目可建立实用的、已文档化的、已实 施的、己培训的、已测量的和能改进的过程。 项目的过程基本是可特征化的 项目是稳定的：即对新项目的策划和管

41、理，有明确的管理方 针和确定的标准（包括对分承制方），可使项目的进展稳定。 新项目的策划和管理是基于成功项目经验的 是有纪律的：即对所建立和实施的方针、规程，对软件项目 过程而言，已进化为组织的行为。从而使软件开发组织能够保证准确地执行给定的软件过程。,已定义级 实现了可重复级（2级）的关键过程域： 软件配置管理、软件质量保证、软件子合同管理、 软件项目跟踪和监督、软件项目规划以及需求管理， 实现了关键过程域： 组织过程焦点、组织过程定义、培训大纲、集成软 件管理、软件产品工程、组间协调以及同行评审 主要特征： 组织：在组织范围内开发和维护软件的标准过程被文档化，其中包括软件工程过程和管理过程

42、，它们集成为一 个一致的整体。 项目：对组织的标准软件过程进行裁剪，来开发它们自己 的定义软件过程。 过程能力：标准的和一致的。(standard and consistent) 由于：,建立了“组织的标准软件过程”：即 关注的焦点转向组 织的体系和管理； 全组织建立了软件开发和维护的标准过程； 软件工程过程和软件管理过程，被综合为个有机的整 体，并且已经文档化。 建立了负责组织的软件过程活动的机构：即 在软件组织中存在负责软件过程活动的机构，并具体实 施全组织的过程制定、维护和改进。 其中包括全组织的人员培训，使之具备必须的技能和 知识，能高效地履行其职责。 项目定义的软件过程：即 项目能够

43、依据其环境和需求等，通过剪裁组织的标准 过程，使用组织的过程财富，自定义项目的软件过程。 其中，允许有一定的自由度，但任务间的不匹配情况， 应在过程策划阶段得到识别，进行组间协调和控制。,组织可视项目的进展：即 项目定义的软件过程将开发活动和管理活功综合为一 个协调的、妥善定义的软件过程； 明确规定了每一活动的输入、输出、标准、规程和验 证判据。 管理者或软件项目负责人能够洞察 所有项目的技术进展、费用和进度 组织的软件能力均衡、致：即 整个组织范围内的软件开发和维护过程已经标准化， 软件工程技术活动和软件管理活动都实现文档化的规 范管理， 组织和项目的软件过程都是稳定和可重复的。 这种过程能

44、力是建立在整个组织范围内对已定义过程 中的活动、作用和职责的共同理解基础之上。 在整个组织范围内软件能力是均衡、一致的,定量管理级 实现了关键过程域：定量过程管理和软件质量管理。 主要特征： 项目：项目减小过程性能的变化性，使其进入可接收的 量化边界，从而达到对产品和过程的控制。 组织：为软件产品和过程都设定了量化的质量目标。 过程能力：可预言的。(predictable) 由于： 设置了定量的质量目标：即 组织对软件产品和过程设置了定量的质量目标； 软件过程具有明确定义和一致的测量方法与手段； 可以定量地评价项目的软件过程和产品质量,项目产品质量和过程是受控和稳定的：即 可以将项目的过程性能

45、变化 限制在一个定量的、可接受的范围之内。 产品质量和过程是受控和稳定的 开发新领域软件的风险是可定量估计的：即 由于组织的软件过程能力是已知的，从而可以利用全组 织的软件过程数据库，分析并定量地估计出开发新领域 软件的风险。 组织的软件过程能力是可定量预测的：即 过程是经测量的并能在可预测的范围内运行，一旦发现 过程和产品质量偏离所限制的范围时，能够立即采取措 施予以纠正。,持续优化级 实现了关键过程域： 缺陷预防、技术变化管理、过程变化管理 主要特征： 组织：关注于持续的过程改进。 项目：软件过程被评价，以防止过失重复发生，从中 获得的教训散布给其它项目。 过程能力：持续的改善。(cont

46、inuously improving) (1)过程不断改进，即组织注重不断地进行过程改进。 组织有办法识别出过程的弱点，并及时地予以克服； 能够利用关于软件过程有效性的数据，识别最佳软件 工程实践的技术创新，并推广到整个组织。,(2)缺陷能有效预防：即 软件项目组能分析并确定缺陷的发生原因，认真评价 软件过程，以防止同类缺陷再现，并且能将经验告知其 他项目组。 (3)组织的过程能力不断提高：即 组织既能在现有过程的基础上以渐进的方式，又能 以技术创新等手段，不断努力地改善过程性能。 特别值得注意的是，在CMM定义的五个成熟度级别中，每一等级形成了一个必要的基础，从此基础出发才能达到下一个等级。

47、因此，软件能力成熟度等级的提高是一个循序渐进的过程，即使一个软件开发组织具有实施较高成熟度等级的能力，也不能表明该组织可以跳越成熟度等级。,关于五个级别的3点说明 从第1级提升到第2级可能需要几年的时间，在其它级别间提升通常依次需要2年的时间。 第1级组织的成功依赖于组织中人员的能力。对于所有成熟度级别的组织来说，选择、雇用、培养和保持有能力的人员都是重要的问题，但这超出了CMM的范围。 每个级别为以后的级别有效地和有效率地实现过程提供基础。跳过级别是达不到预期的目标的。 例如1：第1级的组织，如果在建立可重复的过程(第2级)之前，试图实现定义的过程(第3级)，通常是不会成功，因为项目管理者被

48、进度和开销压力所淹没。,例如2：组织在没有定义过程的基础时，如果试图实现 管理的过程(第4级)，通常是不会成功的。 因为没有定义过程，就没有解释度量的共同基础。 例如3：组织在没有管理过程(第4级)的基础时，如果试 图实现优化过程(第5级)，通常是会失败的。 因为对过程改变的影响缺乏理解。 注意： 和两点，说明了成熟度等级的演化特性。,5、成熟度等级的内部结构 CMM的每个等级是通过三个层次加以定义的： 关键过程域 关键实践类 关键实践,成熟度级别,关键过程区域 (KPA),共同特征,关键实践,过程能力,目标,实现或 制度化,基础设施 或活动,包含,指示,组织,达到,包含,解决,描述,每个等级

49、由几个关键过程域组成，它们共同形成定的 过程能力。 每个关键过程域都有一些特定的目标，为实现这些目标， 将实现目标的关键实践组织为四个关键实践类。 每个关键实践类规定了相应部门或有关责任者应实施的一 些关键实践。当关键过程域的这些关键实践都得 到实施时，就能够实现该关键过程域的目标。 关键实践按类组织，描述了为有效实施并规范化关键过程 域，应具备的基础设施和从事的活动。,目标概括了一个关键过程域的关键实践，表明该关键 过程域的范围、边界和意图。 可用来确定某组织或某项目是否已有效地 实施该关键过程域。 一个成熟度等级的关键过程域表示了这些关键过程域的 完全实现是达到该成熟度等级的必要条件； 一

50、个关键过程域的关键实践表示了实施这些关键实践 是实现该关键过程域目标的必要条件。,（1）各等级的关键过程域,初始级(1),软件配置管理 软件质量保证 软件子合同管理 软件项目跟踪和监督 软件项目规划 需求管理,可重复级(2),对等复审 组间协作 软件产品工程 集成的软件管理 培训计划 组织过程定义 组织过程焦点,定义级(3),软件质量管理 量化的过程管理,管理级(4),过程变化管理 技术变化管理 缺陷预防,优化级(5),例如：软件项目规划 所属等级：是2级的一个关键过程域。 目的：制定进行软件工程和管理软件项目的合理计划。这些计划是管理软件项目的必要基础，促进按选定的软件生存周期模型分阶段分工

51、地进行软件开发。按阶段组织检查，实施控制。 目标： (1) 软件生存周期已选定，并经评审确认； (2) 对计划中的软件规模、工作量、成本、风险等已经进 行估计; (3) 软件项日的活动和约定是有计划的； (4) 影响计划进度的关键路径是己标识的、且受控的； (5) 影响计划进度的关键资源需求是已标识的；,(6) 文档化的软件开发计划已经正式评审，并确认； (7) 在软件生存周期的里程碑处，对计划的执行有检查、 有记录，问题有报告; (8) 对于介入软件开发计划的软件负责人、软件工程师和 有关人员进行了软件估计和计划方面的培训。 实现目标的关键实践 例如：(9) 选定有可管理规模的、预定阶段的软

52、件生存 周期模型 如： 1)瀑布型; 2)增量型； 3)渐进型；4)螺旋型： 5)逆向工程型。 (10) 标识为控制软件项目所必需的软件工作产品。 注：其他关键过程域的简单描述，可见P217-P218。,由此可见： 每个关键过程域只与特定的成熟度等级直接相关； 每个关键过程域指明一组相关的活动，当全部完成时， 就能实现对增强过程能力至关重要的目标。 仅当一个关键过程域的全部目标均已达到时，该关键过 程域才能实现。 对于一个组织来说，仅当其所有项目均已达到一个关键 过程域的目标时，才可以说，该组织己使以该关键过程 域为特征的软件过程(软件能力)规范化了。,（2）关键实践类 关键实践类：指出各主要

53、负责人(或部门)对该关键过程 域的实施和规范化应起的作用和应负的责任。决定关 键过程域的实施和规范化是否有效、可重复、能持久。 每个关键过程域包含：四个关键实践类： 制定方针政策、确保必备条件、 实施软件过程、检查实施情况 制定方针政策 描述组织的高层管理者(决策者)应起的作用：一般说，应保证过程得以建立并持续有效。为此，应制定组织的方针或策略，规定高层管理者的支持或保障活动。 由组织的最高领导及其指定代理负责。,确保必备条件 描述项目负责人应起的作用：一般说，应保证解决实施软件过程所必需的先决条件。为此，应建立适当的资源和组织结构，组织必要的培训。 通常由项目负责人和计划、人事、等部门负责。

54、 实施软件过程 描述软件开发的具体实施者应起的作用：一般说，应制定实施计划和规程，进行实践，跟踪实施，必要时采取纠正措施。 通常由软件项目人员和计划、质量等部门负责。,检查实施情况 描述管理者和软件质量保证部门应起的作用：一般说，应保证各项活动按照已建立的过程进行，还应确定过程实施的状态和有效性。为此，应组织适当的测量和分析、评审和审计。 由质量部门负责人、软件课题负责人和主管领导负责 四个关键实践类之间的关系是： 实施软件过程这一关键实践类中的关键实践，描述了为建立过程能力，过程实施者必须作些什么； 其他关键实践类中的实践，作为一个整体使实施软件过程中的实践规范化。,（3）关键实践 每个关键

55、实践的描述由两部分组成： 前一部分：说明关键过程域的基本方针、规程和活动 -称为顶层关键实践 后一部分：通常是详细描述，可以包括例子 注意： -称为子实践 关键实践描述应该做“什么”，而不强制要求应该“如 何”实现目标。 其它替代的实践也可能实现该关键过程域的目标。 要合理地解释关键实践，以便判断关键过程域的目标 是否已被有效地实现。,例如：关键过程域“软件项目规划”中关键实践的描述 （按四个关键实践类：制定方针政策、确保必 备条件、实施软件过程、检查实施情况进行组织的） 了解： 关键实践如何描述； 关键过程域、关键实践类、关键实践三者之间的关系。,为了保证一致地实现软件项目规划 必须建立一个

56、文档化的规程：进行软件规模估计的方法。 该规程中应详细描述：使用以前的规模数据、对假定条 件提供文件说明、以及对估计进行评审等准则。这些准则可 用来指导对是否遵循合理的规模估计规程作出判断。 制订进行软件工程和管理软件项目的“软件开发计划”。 该计划提供完成和管理项目活动的必要基础，并按照项目的 资源、约束和能力，阐述对软件项目的用户所作的承诺。 制订软件项目开发计划的依据是软件需求规格说明和所 选定的软件生存周期模型。,软件计划管理的步骤是：估计软件工作产品规模和所需 的资源、确定待办的工作、界定软件项目的约束、陈述 由需求管理实践所建立的目标、规模和工作量估计、制 订进度表、鉴别并评估过程

57、风险以及协商相应的约定。 为了使软件开发计划能切实有效地指导项目软件工程 的各项活动，可能需要反复地执行这些步骤。亦即应根 据软件需求的更动和软件过程的各项活动的实际进展情 况经常、及时地修订计划。 于是，软件项目规划的目标为：,(1) 软件生存周期已选定，并经评审确认； (2) 对计划中的软件规模、工作量、成本、风险等已经进 行估计; (3) 软件项目的活动和约定是有计划的； (4) 影响计划进度的关键路径是己标识的、且受控的； (5) 影响计划进度的关键资源需求是已标识的； (6) 文档化的软件开发计划已经正式评审，并确认； (7) 在软件生存周期的里程碑处，对计划的执行有检查、 有记录，

58、问题有报告; (8) 对于介入软件开发计划的软件负责人、软件工程师和 有关人员进行了软件估计和计划方面的培训。,关键实践 制定方针政策 (1) 指定项目软件负责人，负责协商约定并制订项目的软件 开发计划。 (2) 项目遵循书面的、为软件项目制订计划用的方针。 该方针通常规定： 1)根据软件需求规格说明和所选定的软件生存周期模型制 订项目软件开发计划。 2)在项目软件项目其他软件的负责人之间协商对此项 目软件的约定。,3)与其它工程组(如，系统工程组、硬件工程组、系统测 试组)协商介入事宜。 4)受影响的组(如：软件工程组、系统工程组、系统测试 纽)评审项目的进度、工作量、规模估计、成本估计 和

59、其它约定。 5)高层管理者评审所有对组织外部的个人和组所作的软 件项目约定。 6)软件项目开发计划的管理和控制。,确保必备条件 (3) 软件项目有文档化的、且经批准的工作说明(SOW)。 1)工作说明包含： 工作的范围； 技术目标和对象； 用户、最终用户或其代表的标识； 要求遵循的标准和规范； 所赋予的职责; 成本和进度的约束及目标； 软件项目和其它组织(如，用户、分承制方、合作伙 伴)间的关系; 资源限制和目标； 对开发和维护的其它约束和目标。,2)下列人员评审工作说明： 项目负责人： 项目软件负责人； 其他软件负责人；影响的组。 3)管理和控制此工作说明。 (4) 赋予制订软件开发计划的职

60、责。 1)项目软件负责人直接或通过委托代表协调软件项目 开发计划； 2)以可追踪、可说明的方式把对软件工作产品和活动 的职责赋予项目软件负责人;,软件工作产品，如： 适当时，交付给外部顾客或最终用户的产品； 供其它工程组使用的产品； 供软件工程组内部使用的主要产品。 (5) 为软件项目开发计划的制订和实现提供必要的资源 和足够的经费。 1)必要时，可以雇用对该软件项目的应用领域有专业知 识的、有经验的人来制订软件开发计划； 2)使用合适的计划生成支持工具。例如： 电子表格程序； 计划生成软件。,(6)介入软件开发计划的软件负责人、软件工程师和有关 人员，均已受到软件估计和计划方面的培训。 实施

61、软件过程 (7) 软件工程组参与下述的项目建议和评审活动： 1)建议、说明的准备、讨论和提交； 2)对软件项目的约定有影响的那些变更的协商； 3)评审所建议的项目约定的内容。 项目约定，如： 项目的技术目标和对象； 系统和软件的技术解决办法； 软件预算、进度和资源； 软件标准和规程。,(8) 高层管理者按书面的规程评审对组织外部的个人和组 所作的软件项目约定。 (9) 选定有可管理规模的、预定阶段的软件生存周期模型 如： 1)瀑布型; 2)增量型； 3)渐进型； 4)螺旋型： 5)逆向工程型。 (10) 标识为控制软件项目所必需的软件工作产品。 (11) 按照一定的规程估计软件工作产品和活动的

62、规模。 该规程通常规定：,1)估计所有主要的软件工作产品和活动的规模。软件规 模的度量，如： 功能数； 特征数； 代码行数; 需求数； 文档页数。 应作规模估计的产品和活动，如： 运行软件和支持软件； 可交付的和不交付的产品； 软件和非软件工作产品;开发、验证和确认产品的活动 2)分解软件工作产品，达到估计所需的粒度； 3)可能时，使用历史数据； 4)规模估计及所作的假定；,(12) 按照书面的规程估计软件项目的工作量和成本。 该规程通常规定： 1)软件项目工作量和成本的估计与对软件工作产品规模 及其更动规模的估计有关： 2)将生产率数据(历史的、当前的)用于估计，并将其来 源和注释文档化；

63、可能时，生产率和成本数据尽量取自本组织的项目; 生产率和成本数据应考虑开发软件工作产品的工作量和 主要成本(如，直接劳务费、管理费、差旅费和计算机使 用成本)。,3)可能时，应利用过去在类似项目上的经验来估计工作 量、人员设置和成本；确定各种活动的时间段；确定 工作量、人员设置和成本在软件生存周期上的分布。 4)工作量和成本的估计及所作的假定。 (13) 按照书面的规程估计关键的计算机资源需求。 关键计算机资源可以是在宿主环境中的、在集成与测试 环境中的、在目标环境中的、或在以上这些环境的任何 组合中的。 该规程通常规定： 1)标识项目的关键计算机资源，如： 存储器容量; 处理机能力； 通信信道带宽。,2)关键计算机