|
老牛
|
查看文章
CMM的误解
2004-09-01 09:32:00
转自：《PMT评论》 推荐人：杜昌领
关于成熟度级别（maturitylevels） 的误解
1 . 第一级很差劲。
有人对“成熟度”抱有异议，因为“成熟”这个词更带有主观意味，而不象是对过程能力的客观评价。按照成熟度这个名词，第一级的组织当然就是“不成熟”的了；但事实上，现在大多数的软件组织都处于第一级，即初始级。而这些软件组织中的一部分，按照通常的衡量标准（比如利润率、市场占有率、客户满意程度等），还是相当成功的。当然，其他的第一级软件组织就陷入了预算超支、进度落后、质量低下的泥潭。
处于第一级并不意味着其中的成员就差强人意。的确，比起处于更高级别的组织来说，第一级的组织在项目上可能更缺乏可预见性，会发生更多的重做、进度跟不上和产品缺陷；但这只是针对整个组织的过程能力来说的，对于其中个人的能力和表现， CMM 不作任何的评价。
2 . 第二级主要涉及各种软件工程活动， 比如需求分析、设计、编程和测试。
实际上，第二级（即可重复级）描述的是有关基本的项目计划、管理和跟踪的做法。而分析、设计、编程、测试以及归档等“经典”的软件工程活动都被包括在第三级的一个大 KPA- 软件产品工程中。
软件组织要具备可重复的软件过程，必须首先建立起第二级 KPA 提供的有关项目管理的控制和纪律。如果没有项目管理这些“规矩”作为基础，哪怕再有效的的软件工程活动，也可能因为进度的压力和需求的多变而被弃而不用。
3 . 如果要达到某个级别，必须实施该级别的所有活动和做法（practice）。
仅仅第二级就有超过 120 个关键做法（ key practice ），但要达到第二级，并不是所有的关键做法都要实施。达成某个级别，不是看是否实施了相应的所有 KPA 中的关键做法，而是看是否达到了这些 KPA 设定的目标（ goal ）。完全可以采用其他的做法，不管是否包含在 CMM 中，来满足每个 KPA 设定的目标（事实上，有些 KPA 也有例外，比如“软件合同管理” KPA 就不是必须的）。 CMM 中的关键做法仅仅起到指导作用，不是强制的。
4 . 直到向第四级推进时才需要软件量度（softwaremeasurement）。
第四级，即受管理级，要建立起量化管理的软件过程，因此，有人就以为，在此之前不需要进行软件量度。而事实上，任何级别，任何 KPA 都需要进行软件量度。软件量度是 KPA 的一部分，包括在“量度和分析”这个共有特性（common feature）中。
5 . 软件组织的成熟度级别是 S E I 认证的。
事实上，并不存在“SEI认证”这码事。产生这一误解的原因可能是有人把基于 CMM 的过程评估看作了“审核”（audit），而某些审核的确会颁发一个证书样的东西。
关于做法 (practice) 的误解
1 . C M M 要求采用特定的软件开发方法、做法和工具。
CMM 并没有规定在管理和技术上要如何开发软件，或者要使用哪些工具。例如，软件项目计划（ software project planning ）这个 KPA 要求你遵循制定的书面步骤对项目的资源进行估计，而采用什么样的估计算法，是否要借助 CASE 工具，并没有限制。但是， CMM 的确要求将你采用的软件开发方法、做法和工具文档化，并严格遵循；从这个角度说， CMM 要求采用“你制定的”特定的软件开发方法、做法和工具。
2 . C M M 要求采用瀑布型生命周期。
CMM 的确要求采用软件生命周期，但没有规定要采用哪个或者哪些特定的软件生命周期；相反， CMM 明确指出：“ there is no intent either to encourage or preclude theuse of any particular software life cycle ”（即， CMM 无意鼓励或者排除使用任何一种特定的软件生命周期）。
但是， CMM 的确在每一个项目的生命周期模型的选型和应用上有所规定。这些有关生命周期模型的问题主要在已定义级谈及，要点是：对已被批准的软件生命周期的描述要文档化，并作为组织的软件流程标准的一部分；每个项目必须在这些生命周期中选取一种；根据项目需要，遵循指定的裁减指导，必要时可以对所选的生命周期进行修改。
3 . 软件质量保障（SoftwareQuality Assurance） KPA 主要关于测试。
这是个常见的误解，因为很多时候“ quality assurance ”（质量保障）这个词被用来表示查找缺陷的活动， 例如测试（ testing ）、审阅（ review ）。而事实上，测试这个词从未在 SQA KPA 中出现；测试在第三级的软件产品工程（ Software Product Engineering ） KPA 中被提及。
CMM 中讲到：“ the purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built. ”（即， SQA 的目的是向管理层提供适当的可见性，以了解软件项目或者产品所用的流程。）通过审核（ audit ）和审阅（ review ）可以了解所用的流程是否遵循规定的、文档化的流程标准。
SQA 可能被视为增加价值的有力支持，也可能被视为“间谍”、“警察”，这很大程度上取决于组织的文化。 SQA 是要帮助软件开发者采用最有效的方法以生产出高质量的软件产品，而不是充当一个监视者和打小报告者。
4 . 为达到第三级，C M M 要求实施“软件点检”（ Software Inspection ）。
受管理级有一个同级评审（ peer review ） KPA 。软件点检（ Software Inspection ）是一种有效的评审技术，但正如前面所讲的那样， CMM 并未限定采用哪种评审的技术，所以你完全可以采用其他的评审技术，或者和软件点检结合使用。
5 . “裁减”（ tailoring ） 流程意味着可以随心所欲。
受管理级要求制订整个组织范围的软件流程标准，同时也要求制订裁减的指导和准则。
这样，在为特定项目裁减标准的软件流程时，就必须按照裁减指导和准则从事，不能随心所欲。随心所欲的流程不可能是一个有纪律的流程，更不要说达到受管理级的要求了。
6 . 需求管理（ requirements management ）和需求工程（ requirements engi neering ） 是一回事。
需求管理是第二级的一个 KPA ，它的焦点是在客户和项目组之间建立，并维护有关软件需求的约定（ agreement ）。涉及的活动包括审阅客户需求，以需求为基准进行计划和活动，以受控的方式管理需求变更等。但是，这个 KPA 并未涉及诸如收集、记录、分析等需求工程活动。事实上，需求工程是在已定义级的软件产品工程 KPA 中被提及的。
关于应用（ Application ） 的误解
1 . 当你处于某个级别时， 不能改进再高一个级别的 K P A 。
尽管不能在能力成熟度级别上跳跃前进，但你的确可以选择任何一个级别，无论多高的级别上的任一个 KPA 作为改进的对象。例如，当你处在第一级时，完全可以实施同级评审 KPA ，尽管同级评审是第三级的 KPA 。事实上，无论你处于哪个级别，你可以改进任何一个流程，不管是否在 CMM 的 KPA 中，因为， CMM 并没有涉及项目如何成功的方方面面。
但是，在你改进再高一个级别的 KPA 时，你要清楚你这样做的现实意义如何，你是否具备实施的基础，既是实施了，你是否能长久的保持。由于 CMM 强调每一个级别都是更高级别的基础，所以这样的做法是不提倡的。
2 . C M M 会造成官僚主义和无意义的文档。
在应用 CMM 时，流程改进的热衷者们常常会忘记他们要面对的项目规模是大小不一的，因而流程的标准应该是可伸缩的（ scalable ）。 CMM 经常提到要遵循文档化的过程。但这并不是说每个项目，不管规模大小，都要同样多的文档。繁文缛节是官僚主义的温床。但这并不是 CMM 本身造成的，关键是看如何应用 CMM 。
3 . C M M 是一个短期问题的快速解决方案。
无论应用 CMM ，还是其他流程改进的方案，都不要期望可以一下子解决眼前的所有问题，或者可以大幅提高生产效率。 CMM 的确会带来效率和质量上的改观，但需要持之以恒。
关于成熟度级别（maturitylevels） 的误解
1 . 第一级很差劲。
有人对“成熟度”抱有异议，因为“成熟”这个词更带有主观意味，而不象是对过程能力的客观评价。按照成熟度这个名词，第一级的组织当然就是“不成熟”的了；但事实上，现在大多数的软件组织都处于第一级，即初始级。而这些软件组织中的一部分，按照通常的衡量标准（比如利润率、市场占有率、客户满意程度等），还是相当成功的。当然，其他的第一级软件组织就陷入了预算超支、进度落后、质量低下的泥潭。
处于第一级并不意味着其中的成员就差强人意。的确，比起处于更高级别的组织来说，第一级的组织在项目上可能更缺乏可预见性，会发生更多的重做、进度跟不上和产品缺陷；但这只是针对整个组织的过程能力来说的，对于其中个人的能力和表现， CMM 不作任何的评价。
2 . 第二级主要涉及各种软件工程活动， 比如需求分析、设计、编程和测试。
实际上，第二级（即可重复级）描述的是有关基本的项目计划、管理和跟踪的做法。而分析、设计、编程、测试以及归档等“经典”的软件工程活动都被包括在第三级的一个大 KPA- 软件产品工程中。
软件组织要具备可重复的软件过程，必须首先建立起第二级 KPA 提供的有关项目管理的控制和纪律。如果没有项目管理这些“规矩”作为基础，哪怕再有效的的软件工程活动，也可能因为进度的压力和需求的多变而被弃而不用。
3 . 如果要达到某个级别，必须实施该级别的所有活动和做法（practice）。
仅仅第二级就有超过 120 个关键做法（ key practice ），但要达到第二级，并不是所有的关键做法都要实施。达成某个级别，不是看是否实施了相应的所有 KPA 中的关键做法，而是看是否达到了这些 KPA 设定的目标（ goal ）。完全可以采用其他的做法，不管是否包含在 CMM 中，来满足每个 KPA 设定的目标（事实上，有些 KPA 也有例外，比如“软件合同管理” KPA 就不是必须的）。 CMM 中的关键做法仅仅起到指导作用，不是强制的。
4 . 直到向第四级推进时才需要软件量度（softwaremeasurement）。
第四级，即受管理级，要建立起量化管理的软件过程，因此，有人就以为，在此之前不需要进行软件量度。而事实上，任何级别，任何 KPA 都需要进行软件量度。软件量度是 KPA 的一部分，包括在“量度和分析”这个共有特性（common feature）中。
5 . 软件组织的成熟度级别是 S E I 认证的。
事实上，并不存在“SEI认证”这码事。产生这一误解的原因可能是有人把基于 CMM 的过程评估看作了“审核”（audit），而某些审核的确会颁发一个证书样的东西。
关于做法 (practice) 的误解
1 . C M M 要求采用特定的软件开发方法、做法和工具。
CMM 并没有规定在管理和技术上要如何开发软件，或者要使用哪些工具。例如，软件项目计划（ software project planning ）这个 KPA 要求你遵循制定的书面步骤对项目的资源进行估计，而采用什么样的估计算法，是否要借助 CASE 工具，并没有限制。但是， CMM 的确要求将你采用的软件开发方法、做法和工具文档化，并严格遵循；从这个角度说， CMM 要求采用“你制定的”特定的软件开发方法、做法和工具。
2 . C M M 要求采用瀑布型生命周期。
CMM 的确要求采用软件生命周期，但没有规定要采用哪个或者哪些特定的软件生命周期；相反， CMM 明确指出：“ there is no intent either to encourage or preclude theuse of any particular software life cycle ”（即， CMM 无意鼓励或者排除使用任何一种特定的软件生命周期）。
但是， CMM 的确在每一个项目的生命周期模型的选型和应用上有所规定。这些有关生命周期模型的问题主要在已定义级谈及，要点是：对已被批准的软件生命周期的描述要文档化，并作为组织的软件流程标准的一部分；每个项目必须在这些生命周期中选取一种；根据项目需要，遵循指定的裁减指导，必要时可以对所选的生命周期进行修改。
3 . 软件质量保障（SoftwareQuality Assurance） KPA 主要关于测试。
这是个常见的误解，因为很多时候“ quality assurance ”（质量保障）这个词被用来表示查找缺陷的活动， 例如测试（ testing ）、审阅（ review ）。而事实上，测试这个词从未在 SQA KPA 中出现；测试在第三级的软件产品工程（ Software Product Engineering ） KPA 中被提及。
CMM 中讲到：“ the purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built. ”（即， SQA 的目的是向管理层提供适当的可见性，以了解软件项目或者产品所用的流程。）通过审核（ audit ）和审阅（ review ）可以了解所用的流程是否遵循规定的、文档化的流程标准。
SQA 可能被视为增加价值的有力支持，也可能被视为“间谍”、“警察”，这很大程度上取决于组织的文化。 SQA 是要帮助软件开发者采用最有效的方法以生产出高质量的软件产品，而不是充当一个监视者和打小报告者。
4 . 为达到第三级，C M M 要求实施“软件点检”（ Software Inspection ）。
受管理级有一个同级评审（ peer review ） KPA 。软件点检（ Software Inspection ）是一种有效的评审技术，但正如前面所讲的那样， CMM 并未限定采用哪种评审的技术，所以你完全可以采用其他的评审技术，或者和软件点检结合使用。
5 . “裁减”（ tailoring ） 流程意味着可以随心所欲。
受管理级要求制订整个组织范围的软件流程标准，同时也要求制订裁减的指导和准则。
这样，在为特定项目裁减标准的软件流程时，就必须按照裁减指导和准则从事，不能随心所欲。随心所欲的流程不可能是一个有纪律的流程，更不要说达到受管理级的要求了。
6 . 需求管理（ requirements management ）和需求工程（ requirements engi neering ） 是一回事。
需求管理是第二级的一个 KPA ，它的焦点是在客户和项目组之间建立，并维护有关软件需求的约定（ agreement ）。涉及的活动包括审阅客户需求，以需求为基准进行计划和活动，以受控的方式管理需求变更等。但是，这个 KPA 并未涉及诸如收集、记录、分析等需求工程活动。事实上，需求工程是在已定义级的软件产品工程 KPA 中被提及的。
关于应用（ Application ） 的误解
1 . 当你处于某个级别时， 不能改进再高一个级别的 K P A 。
尽管不能在能力成熟度级别上跳跃前进，但你的确可以选择任何一个级别，无论多高的级别上的任一个 KPA 作为改进的对象。例如，当你处在第一级时，完全可以实施同级评审 KPA ，尽管同级评审是第三级的 KPA 。事实上，无论你处于哪个级别，你可以改进任何一个流程，不管是否在 CMM 的 KPA 中，因为， CMM 并没有涉及项目如何成功的方方面面。
但是，在你改进再高一个级别的 KPA 时，你要清楚你这样做的现实意义如何，你是否具备实施的基础，既是实施了，你是否能长久的保持。由于 CMM 强调每一个级别都是更高级别的基础，所以这样的做法是不提倡的。
2 . C M M 会造成官僚主义和无意义的文档。
在应用 CMM 时，流程改进的热衷者们常常会忘记他们要面对的项目规模是大小不一的，因而流程的标准应该是可伸缩的（ scalable ）。 CMM 经常提到要遵循文档化的过程。但这并不是说每个项目，不管规模大小，都要同样多的文档。繁文缛节是官僚主义的温床。但这并不是 CMM 本身造成的，关键是看如何应用 CMM 。
3 . C M M 是一个短期问题的快速解决方案。
无论应用 CMM ，还是其他流程改进的方案，都不要期望可以一下子解决眼前的所有问题，或者可以大幅提高生产效率。 CMM 的确会带来效率和质量上的改观，但需要持之以恒。
类别：默认分类 | 浏览(81)
最近读者
网友评论
发表评论
| 用户名： | 密码： 会员注册 |
| 内 容： | |
| 验证码： | 请输入下面图中的四位验证码，不区分大小写。 |
