六、GJB5000A各成熟度等级所含过程域

★GJB5000A认证知识★---★GJB5000A软件成熟基本概念★

第一节 GJB-5000A 能力成熟度基本概念

1.1  软件过程的基本概念

一个大型软件项目要成功，很大程度上依赖于正确而且合适的软件过程，首先的问题是什么 是软件过程呢？

1，软件过程的定义与概念
1）过程的定义 系统从一个状态（始态）变成另一个状态（终态），我们就说：发生了一个过程（Process）。
过程是一种手段，通过该手段可以把人、方法与规程、技术与工具进行集成，以产生一种所期望 的结果。
换句话说，过程就是人们使用相应的方法、规程、技术、工具等将原始材料（输入）转化成 用户需要的产品（输出）。过程与产品存在因果关系。即好的过程才能得到好的产品，而差的过程只会得到差的产品。

2）过程的特征 任何过程都应该具备 8 个特征：
 任何一个过程都有输入和输出；
 输入是实施过程的基础、前提和条件；
 输出是完成过程的结果；
 输出可能是有形产品，也可能是无形产品，如软件或服务；
 过程本身是增值转换，不增值的过程没有意思；
 完成过程必须投入适当的资源和活动，是换取过程增值或结果有效的代价
 过程存在可测量点；
 所有的工作和活动都是通过过程来完成的。若干目的上相互关联的过程系统,我们称之为过程域，广义的软件过程包括管理过程和生产
过程。主要的软件过程域如下：
 工程类的主要过程域：需求开发、系统设计、软件实现、软件测试、软件维护等等；
 管理类的主要过程域：项目规划、项目监控、需求管理、质量管理、配置管理等等。上述过程域中的任何活动都会影响产品的质量、生产率和成本。
3）软件过程能力 软件过程能力描述通过遵循软件过程能够实现预期结果的程度。一个组织的软件过程能力提
供一种预测该组织承担下一个软件项目时最可能的预期结果的方法。软件过程性能表示遵循软件 过程所得到的实际结果。所以，软件过程性能关注已得到的结果，而软件过程能力则关注预期结果。由于一个特定项目的属性和执行该项目的环境所限，该项目的实际性能可能并不充分反映组织的整个过程能力，即项目的能力受限于它的环境。

2，为什么要加强管理与过程能力呢？ 一个组织的成熟首先是从要强管理开始的。很多人尽管在口头上不得不承认，但内心里还是
认为只要我有了好的技术，照样能把产品做出来，但这不一样。 过去一谈创新往往想到的就是技术创新，但仅仅有技术创新是不够的，我们还必须关注管理
创新和应用创新，没有这个层面的创新思想，就没有办法把技术手段转化为真正有用的东西，更 没有办法创造影响人类社会进程的伟大产品。
如果我们仅仅是做一个纸飞机，那我们就没有必要写下详细计划（花 20 分钟写计划再花 20 秒把飞机折出来，无疑是个愚蠢行为），你可以快速的修改，即使返工也是经济和高效的。但是， 如果你是制造一家大型客机，那么用纸飞机的方法来实现同样也是愚蠢的，如果没有详细的前期设计，没有严密的管理，那整个飞机制造过程就是一个漫长、混乱和昂贵的过程。它将产生大量应该避免的返工，甚至永远不可能完成，如下图所示。
为了加强管理与过程能力，现代软件工程学提供了一系列方法，包括： 1）基于工程规范的大型软件系统开发由于大型项目的组件未必是同一个机构生产的，所以需要建立一些系统工程原则，来协调需
要精确协同工作的组件的开发。
2）引入标准和过程规范 为了解决这个问题，美国国防部开发了一系列的指导文档，为软件开发提供符合系统工程的
标准方法，这些规范和标准有如下特征：
Ÿ 重视定义良好的工作产品、验证和确认：软件系统工程认为，从需求到代码的过程中，计划驱动的方法非常精确的依赖于明确的步骤，其中每个步骤中文档的完备性非常重要，这种完备性可以保证每个步骤可验证，文档是可跟踪性的重要保证。
Ÿ 产品规范与过程定义和改进具有同等的联系：软件作为一种产品，其可塑性使过程需要经过多次改进，正因为如此，过程需要进行定义、标准化并需要逐步改进以提供对项目的有效控制。
Ÿ 过程提供可预见性、可重复性和基础设施的支持来缓解人员流动问题：标准化所带来的可比较和可重复性，使组织中的人都知道在哪里找信息，以及如何评估日常工作。这种过程的一致性可以使管理人员在项目之间调动人员而不必要重新培训，也意味着关键 人员的的流失不再是项目的厄运。
3）项目越复杂，规范的意义就越重要 项目越复杂，规范的意义就愈重要。在一些非常大的项目中，很多人试图避开这个过程，结
果大多数都失败了。大量实践表明，规范方法尽管在管理上的成本提高了，但远远比不遵从这些 方法（游击队似的疯狂开发）更经济有效，因为它减少了意外和返工的工作量。更重要的是，它可以保证每个人都知道自己该干什么事情，确保组织运转成为可能。严格的基线和工作产品的静态测试，帮助人们提高了整体质量，并有助于人们尽早发现更多的缺陷。

如果没有计划和规范，那一定是混乱和不一致的。尽管某些局部可能成功，但整体上可能永 远也不会完成，所带来的管理成本可能更高。管理层所做的事情可能就是周而复始的协调、协调、再协调，这无疑是管理上的一场噩梦。
正确的规范化并不会抑止人们的创造力，相反它使得团队可以大规模地复用前人积累的智慧 和财富。这种方法非常适合于现代的工业化生产。 业界实践已经证明，走规范化之路是“成本最低、见效最快、能持续发展”的软件过程改进方法，

1.2  能力成熟度模型的基本概念

1，能力成熟度（CMM）的历史诱因
软件工程管理引起广泛注意源于 20 世纪 70 年代中期，当时人们就发现软件项目的成功率很低，一直到 20 世纪 90 年代中期，美国有$2,500 亿用于 IT 的 175,000 个软件项目，其中：
31%  在完成前被取消，其费用为$810 亿
53%  的费用是原估计费用的 190%
只有 10%的软件项目能够在预定的费用和进度下交付。 美国国防部（DoD）发现，在失败的项目中，70%是因为管理不善而引起。这就是 DoD 建
立 CMU/SEI（卡内基梅隆大学软件工程研究所）的诱因。
CMM 模型在理论上基于 20 世纪 30 年代施瓦特（Walter Shewart） 的统计质量控制原理， 已有 60 多年历史。德明（Edwards Deming）和朱兰（Joseph Juran）在 40 和 50 年代发展了这些 原理并在实践中得到了证明，特别是在日本，获得了极大的成功。
20 世纪 70 年代末期，菲利普.克罗斯比（Philip Crosby）把这些原理用于构造成熟度框架， 首次提出五个进化层次。20 世纪 80 年代中期，IBM 在汉弗莱（Watts S. Humphrey）的指导下， 莱德斯（Ron Radice）等人把这个成熟度框架首次用于软件过程。
1986 年，汉弗莱（Humphrey） 把这些成果带到 CMU/SEI，并由他主持研究软件过程成熟 度模型，对这些原理进行了进一步的完善，并于 1987 年 6 月公布了过程成熟度框架的第一份研 究报告。到 1993 年颁布了第一个成熟的版本 CMM 1.1。
CMM 模型正在向纵深发展，目前 CMM 家族包括：
 软件能力成熟度模型(SW-CMM)
 软件获取能力成熟度模型(SA-CMM)
 人员能力成熟度模型(People-CMM)
 系统工程能力成熟度模型(SE-CM)
 集成产品开发能力成熟度模型(IPD-CMM)
 个体软件过程(PSP)
 群组软件过程(TSP)等。
 最近正在试行和推广集成的能力成熟度模型(CMMI)。

2，过程改进的收益
1）过程改进的好处
从上个世纪 80 年代到今天，软件工程界广泛推行 CMM，获得了如下好处：
 减少软件开发费用。
 提高软件开发生产率。
 缩短软件开发周期。
 改进软件开发质量。
 能较好地控制费用和质量，有较好的可预测性。