第12章软件成熟度模型与软件过程分解.ppt

12.1 能力成熟度模型 12.2 能力成熟度模型集成 12.3 个人软件过程 12.4 团队软件过程 12.5 能力成熟度模型与软件过程之间的关系 12.6 本章小结 CMM的诞生 软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。 20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。 软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。 在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。 软件管理工程和其它工程管理相比有其特殊性： 软件是知识产品，进度和质量都难以度量，生产效率也难以保证。 软件系统复杂程度也是超乎想象的。 因为软件复杂和难以度量，软件管理工程的发展还很不成熟。 软件管理工程的发展，在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代； 90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代； 而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，可以实现真正的软件工业化生产。软件生产转向以改善软件过程为中心。 CMM的发展 CMM框架用5个进化的层次来评定软件生产的历史与现状： 初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。 任何单位所实施的过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。而在某个层次内部，也有成熟程度的区别。在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。 因此，一个软件开发单位首先需要了解自己正处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题。任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还必须得到保持与发扬。 实施CMM的必要性 实施CMM是改进软件质量的有效方法 科学地评价软件开发单位的软件能力成熟等级； 帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发能效率。 CMM在中国的现状 总体上讲，国内对软件过程理论的讨论与实践正在展开，目标是使软件的质量管理和控制达到国际先进水平，中国的软件产业获得可持续发展的能力。 我们应该看到目前国内对软件管理工程存在的最大问题是认识不足。管理实际上是一把手工程，需要高层管理人员的足够重视。而且软件过程的重大修改也必须由高层管理部门启动，这是软件过程改善能否进行到底的关键。此外，软件过程的改善还有待于全体有关人员的积极参与。 除了要认识到过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。 CMMI的背景 按照SEI原来的计划，CMM的改进版本2.0应该在1997年12月完成，然后在取得版本2.0的实践反馈意见之后，在1999年完成准CMM2.0版本。但是，美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI，原因是在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆，CMMI就是为了解决怎么保持这些模式之间的协调。 与原有的能力成熟度模型类似，CMMI也包括了在不同领域建立有效过程的必要元素，反映了业界普遍认可的“最佳”实践；专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。 CMMI内容 CMMI内容分为“Required”（必需的)、“Expected”（期望的）、“Informative”（提供信息的）三个级别，来衡量模型包括的质量重要性和作用。最重要的是“要求”级别，是模型和过程改进的基础。第二级别“期望”在过程改进中起到主要作用，但是某些情况不是必须的可能不会出现在成功的组织模型中。 “提供的信息”构成了模型的主要部分，为过程改进提供有用的