软件组织成熟度

　　不成熟的组织最大的特征就是“救火”，只顾、也只能忙于解决眼前的问题，而眼前的问题又往往一个接一个。

　　成熟的组织要有序得多，力图预防问题，而非应付问题，虽然也可能出现意外情况，但对此是早有防范的，是有准备的。

　　成熟与否导致的最终结果就是客户对其能否胜任软件项目的信心有所不同不同。

　　软件流程成熟度 software process maturity

　　一个特定的流程在多大程度上被明白无误的定义、管理、衡量和控制，以及有多有效。

　　软件组织的软件流程成熟度预示着它的软件流程能力有多大的发展潜力，这不仅指它的软件流程有多丰富，多完备，而且指这些软件流程在最大程度上是一致的，在整个组织范围内，在任何一个项目中，都是被很好的了解和贯彻。

　　CMM 是一个阶梯式的模型它根据软件组织的流程成熟度高低分成了5 个级别（level），从第一级的初始级一直到第五级的优化级

　　指导软件组织逐步成熟的框架

　　任何一个软件组织，在某个时刻，都可以依据一定的标准来被划定处于哪个级别。这个组织就可以知道，它下一步要争取的级别是哪一级。

　　CMM可以说是一个指导软件组织如何一步一步的走向成熟的框架。每一个低的级别都是向更高级别迈进的基础。

　　KPA（Key Process Area)—划定组织流程成熟度级别的依据

　　除了初始级外，每个级别都包括若干个KPA，每个KPA 又设定了2 至4 个目标。当某个KPA 的所有目标达到时，就可以说该KPA 被满足了；

　　当某个级别的所有KPA（除了极个别KPA 不是必须的）都被满足时，我们就可以说，已经达到该级别了。

　　KPA 归类

　　CMM KPA应用

　　既要利用KPA 有重点、有次序的指导流程改进，也不要眼里只有KPA，忘记了现实的状况。

　　有关键流程区，当然还有非关键流程区；所以，千万不要以为，处于某个级别的组织，所要面对的流程只是那几个KPA；要做的流程，其实远远不止这些。

　　可重复级只有6 个KPA，没有涉及基本的软件工程活动（如系统设计、软件测试），也没有涉及项目资源（如必须的软硬件和其他设备）采购、客户交流等等，而这些对于做好项目（更不要说要可重复了）也是非常重要的。

　　CMM 没有涉及这些流程，是因为它把这些流程归结为“非关键”的，但“非关键”并不等同于可忽略的。

　　CMM 内部结构

　　关键过程区表明关键过程的实施和制度化

　　共有特性（common feature）与关键实践（key practice）:

　　每个KPA 都包含了相关的一系列KP，这些KP 提供了达到KPA 目标的一个指导。是指导，而非必须。正所谓“条条大路通罗马”，我们完全可以采取其他的做法（Practice）来满足目标，甚至可以是CMM 没有提到的Practice。

　　每个KPA 的所有KP 都按照共有特性（common feature）归类

　　将KPA 的KP 按照共有特性组织起来，完全是为了方便。

　　KP 共有特性（common feature）：

　　实施承诺（commitment to perform），实施承诺通常包括是否建立了相关的制度，管理层是否支持等等。

　　实施能力（ability to perform），包括诸如是否有足够的人力资源、培训等等

　　实施活动（activities performed ）

　　度量和分析（ measurement and analysis ）

　　实施验证（ verifying implementation）

　　CMM 强调

　　KPA 达成目标的一贯性和有效性，而不是今天能达到，明天就很难说。