CMM与项目管理解读.ppt

CMM与项目管理 -CMM与项目管理研讨会心得交流 第二事业部 寇东 概要 CMM简介 项目管理简介 软件项目管理 软件工程 需求工程 软件测试 问题 主管在项目在进行过程中询问项目的进展情况，你挠挠头皮：设计做的差不多了，一部分已经开始编码了。 主管不满意了：什么时候能交活？你有些底气不足：至少还得一个多月的时间。主管着急了：就剩两周的时间了，你要花一个月，上一周你还答应可以在三周内完成。 六周过去了，你的项目组还在测试，还在修改代码。两个月过去了，项目终于完成了。尽管客户有不少抱怨，但总算做了验收。 下一个项目会怎样？ SEI 的解决方案 SEI 的解决方案 软件项目管理的重要原则： —重视软件质量 —始终如一地强调有纪律的工程工作 理性管理的四要素 CMM/CMMI/PSP（Personal Software Process）/TSP（Team Software Process） 软件流程 A software process can be defined as a set of activities，methods，practices，and transformations that people use to develop and maintain software and the associated products（e.g.， project plans，design documents，codes，test cases，and user manuals）。 如何工作（软件开发和维护） 软件流程能力software process capability 遵循这样的软件流程，有多大可能可以达到预计的结果。 软件流程能力提供了一种有效的手段，可以预计软件组织承担某个项目最有可能的结果是什么样的。 软件流程性能software process performance 代表了遵循这样的软件流程，真正达到的结果是怎样的。 软件流程能力表述的是期望的结果，而软件流程性能表述的是实际的结果。 软件组织成熟度 不成熟的组织最大的特征就是“救火”，只顾、也只能忙于解决眼前的问题，而眼前的问题又往往一个接一个。 成熟的组织要有序得多，力图预防问题，而非应付问题，虽然也可能出现意外情况，但对此是早有防范的，是有准备的。 成熟与否导致的最终结果就是客户对其能否胜任软件项目的信心有所不同不同。 软件流程成熟度software process maturity 一个特定的流程在多大程度上被明白无误的定义、管理、衡量和控制，以及有多有效。 软件组织的软件流程成熟度预示着它的软件流程能力有多大的发展潜力，这不仅指它的软件流程有多丰富，多完备，而且指这些软件流程在最大程度上是一致的，在整个组织范围内，在任何一个项目中，都是被很好的了解和贯彻。 CMM概貌 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 提供了