CMM说明与关键过程域

1、CMM介绍及关键过程域的分析一、cmm介绍CMM它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实 践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这 一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使 企业能够更好地实现商业目标。CMM是一种用于评价软件承包能力并帮助其改 善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估OCMM 分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管 理级，五级为优化级。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到 了众多国家以及国际软件产业界的认可，成为

2、当今企业从事规模软件生产不可缺 少的一项内容。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的 过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之 苦。软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括 了软件生产的技术方面和管理方面。CMM明确地定义了 5个不同的“成熟度”等 级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。成熟度等级1：初始级(I nitial)。处于这个最低级的组织，基本上没有健全的 软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由 一个有能力的管理员和一个优秀的软件开发组来做，则这个工程可能是成

3、功的。 然而通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。 结果，大多数的行动只是应付危机，而非事先计划好的任务。处于成熟度等级1 的组织，由于软件过程完全取决于当前的人员配备，所以具有不可预测性，人员 变化了，过程也跟着变化。结果，要精确地预测产品的开发时间和费用之类重要 的项目，是不可能的。成熟度等级2：可重复级(Repeatable)。在这一级，有些基本的软件项目的管 理行为、设计和管理技术是基于相似产品中的经验，故称为可重复”。在这一级 采取了一定措施，这些措施是实现一个完备过程所必不可缺少的第一步。典型的 措施包括仔细地跟踪费用和进度。不像在第一级那样，在危机状

4、态下方行动，管 理人员在问题出现时便可发现，并立即采取修正行动，以防它们变成危机。关键 的一点是，如没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在 一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。成熟度等级3：已定义级(Defined)。在第3级，已为软件生产的过程编制了 完整的文档。软件过程的管理方面和技术方面都明确地做了定义，并按需要不断 地改进过程，而且采用评审的办法来保证软件的质量。在这一级，可引用CASE 环境来进一步提高质量和产生率。而在第一级过程中，“高技术”只会使这一危机 驱动的过程更混乱。成熟度等级4：已管理级(Managed)。一个处于第4级的

5、公司对每个项目都 设定质量和生产目标。这两个量将被不断地测量，当偏离目标太多时，就采取行 动来修正。利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量 或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。 相应的目标就是随时间推移减少这个量)。成熟度等级5：优化级(Optimizing)。一个第5级组织的目标是连续地改进软 件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得 的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率 和质量得到稳步的改进。 整个企业将会把重点放在对过程进行不断的优化， 采取主动的措施去找出过程的弱点与

6、长处，以达到预防缺陷的目标。同时，分析 各有关过程的有效性资料，作出对新技术的成本与效益的分析，并提出对过程进 行修改的建议。达到该级的公司可自发的不断改进，防止同类缺陷二次出现。二、CMM关键过程域介绍Cmm2的关键过程是：需求管理、软件项目计划、软件项目跟踪和监控、 软件转包合同、软件质量保证、软件配置管理。这六个关键过程域主要涉及建立 基本项目管理和控制方面的内容。需求管理:在顾客和顾客要求的软件项目之间建立一种一致的、共同的理解， 控制系统对软件的需求，为软件工程和管理建立基线，保持软件计划、产品和活 动与分配需求的一致性。共同理解是计划和管理软件项目的基础，所以需求管理 要求需求文档

7、化，并对需求进行评审。在整个软件生命周期中，当用户需求改变 时，记录全部改变，并进行评审。软件项目计划：为实施软件工程和管理软件项目制订合理计划。估计软件产 品的规模和所需资源，制定开发进度计划，确定并评估风险，协商有关约定。软件项目跟踪与监控：对软件项目的执行进行跟踪、监督与控制，以便随时 掌握软件项目的实际开发过程。当项目的执行活动与软件项目计划偏离时，项目 经理能够采取有效的措施进行处理。软件转包合同：选择高质量的软件子项目承包者，并对子合同的执行进行有 效的管理，并对其进行过程监督。软件质量保证：对软件项目和产品质量进行监督和控制，为管理者监控软件 项目的过程和产品质量提供适度的可视性

8、。通过评审和审核软件产品和活动，验 证是其否与应用的标准和规程一致。出现的问题尽可能在软件项目组内部解决。 内部不能解决的问题，由质量保证组进行适当的解决。3级CMM在2级的基础上增加了七个KPA组织过程焦点:软件组织建立负责软件过程活动的责任和机制，为改进软件 组织的整体软件过程能力提供组织上的保证。组织过程定义:由负责软件过程活动的组开发和维护一组能提高项目软件过 程整体效能的软件过程资源的集合，并为在定量过程管理中确定有意义的数据提 供基础。培训大纲:为提高个人的技能和知识进行培训，使其更有效地完成任务。集成软件管理:协调软件工程活动和软件管理活动，将二者集成为密切相关、 定义完整的软件

9、过程。软件产品工程:协调一致地执行经过定义并综合了所有软件工程活动的工程 过程，以便高效地生产出稳定的软件产品。任务：分析分配给软件的系统需求、 制定软件需求、开发软件体系结构、设计软件、编码、测试、集成等，检验其是 否满足分配需求。组间协调：开发软件项目的各小组积极合作，以便使项目更好、更有效地满 足用户需求。同行评审：由同一级别的其他人员对该软件项目产品系统地检测，以便能较 早地和有效地发现软件产品中存在的错误，并改正它们。4级CMM在3级的基础上增加了两个KPA，关注焦点是建立起对软件过程和产生的软件产品的定量理解。定量过程管理：在软件项目过程中的各个阶段进行定量控制。目的是定量地 控制

10、软件项目的过程性能，在一个可测量的稳定的过程范围内鉴别出变化的特殊 原因，并且适时改正促使变化出现的环境。为组织过程定义、集成软件管理、组 间协调和同行评审的实践增加一个内容丰富的测量计划。软件质量管理：定量地评价软件产品的质量，实现具体的质量目标。包括 确定软件产品的质量目标，制定实现这些目标的计划，监控及调整软件计划、软 件工作产品、活动和质量目标，以满足客户和最终用户对高质量产品的需要和期 望。5级CMM在4级的基础上增加了 3个KPA,关注的焦点是为了实施连续 不断的和可测量的软件过程改进，组织和项目所必须解决的问题。缺陷防范：在软件过程中能识别出产品产生缺陷的原因，并采取防范措施，

11、防止它们再次发生。为了能识别缺陷，一方面要分析以前所遇到的问题和隐患， 另一方面要对各种可能出现缺陷的情况加以分析和跟踪，从中找出可能出现缺陷 和复发缺陷的类型，并对缺陷产生的根本原因进行确认，同时对未来的活动预测 可能产生的错误趋势。技术改革管理：确定新技术（包括工具、方法和过程），将其有序地引入到 组织的各种软件过程中去。同时，对由此引起的各种标准变化进行处理，使之适 应新的需要。过程变更管理：不断改进组织的软件过程，提高生产率和软件质量，缩短软 件产品开发周期。目的是改进软件质量、提高生产率和缩短产品开发周期 只有 持续不断地改进组织中所采用的软件过程才能实现这一目标。既采用缺陷预防的

12、增量式改进，又采用技术改革管理的创新式改进，并使得整个组织可以共享这 些改进的成果。活动包括定义过程改进目标、不断地改进和完善组织的标准软件 过程和项目定义软件过程，制定培训和激励的计划，促使组织中的每个人都能自 觉地参与过程改进活动。对cmm2到cmm5的关键过程域的分析，需求管理、软件项目计划、软件项 目跟踪和监控、软件转包合同、软件质量保证、软件配置管理是cmm的基础。三、需求管理分析本人认为这六项里面，需求管理是最为关键，也是一个项目是否能实施、完 成的重要基础。对需求管理与需求工程进行如下分析：需求开发和需求管理是需 求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出

13、现重 复性的工作。导致需求开发欠佳的主要原因有以下几点：1、缺乏良好的需求规格说明编写模板分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐 方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客 观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改 进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契” 而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种 默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。 改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反 向追踪需求规

14、格说明更改的程度，并持续改进需求规格说明编写模板。2、较严重地忽略了非功能性需求目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐 成熟，软件客户对软件的非功能性需求也会越来越高，这就对软件开发商提出了 更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工 作的包围之中。如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中 期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理 难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规 格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在 的不足。3、缺

15、乏对需求文档的配置管理采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看， 一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加 专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理 的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者 到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能 严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规 则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基 本名词和动词集合，并规定语句书写规则。4、需求规格说明缺乏可测试在需求说明应具备

16、的几个特性里，为什么单单挑出可测性呢？在需求说 明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可 测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多 需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试 组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面 之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软 件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重 要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且 有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件 企业应该进一步重视的