我对使用CMM的看法(初稿)

Terry的Blog — Sun, 09 Apr 2006 07:35:00 GMT

1. 先看看大家是怎么说的：
http://forum.javaeye.com/viewtopic.php?t=9459&postdays=0&postorder=asc&start=0&sid=2871e6a1b3468ccdd441b29776e74b41

      其中lucifer说:"最近我们部门在努力通过CMM3中，经过一段时间的培训和实做。发现了一些比较令人困惑的地方，记录下来可以探讨一下。 CMM的目标是提高组织的成熟度，利用软件开发过程通过固化甚至严格量化的过程来提高整个组织的成熟度进而达到较高的项目成功率和客户满意度。嗯，通过最初的培训，经历了以前开发过程比较混乱，存在各种问题的我觉得茅塞顿开，原来做软件可以这样。这样的开发才可以叫做工程。可是，真正开始项目的时候情况又如何呢？感觉上就是铺天盖地的要求极其详细的文档，无休无止的大大小小的会议。真正涉及开发的内容少之又少，以至于项目进行到了现在，大规模的编码还没有开始。这种情况直接导致了整个团队的士气下降，每个人没有自己的明确目标。个人的工作效率越来越低。整天的工作就是忙于规范各个流程，忙于修正各种NC。PM和主要参与人员忙的要死，而开发人员空闲时间很多。为什么会出现这种状况？是我们在导入CMM的时候矫枉过正，还是CMM比较不适合我们的团队乃至于整个部门，要么是我们在实施过程中忽略了一些其它的什么因素？"

2. 简要的说说CMM是什么：
      能力成熟度模型（Capability Maturity Model 简称CMM）是美国软件工程研究所（Software Engineering Institute, 缩写为SEI）首先提出的。SEI是美国国防部设立，SEI的任务是提供一系列技术管理方法来提高软件工程水平，保证美国防部能够通过成本、进度和质量的预估和改进获得并且支持其精准的软件系统。
    任务包含四个目标：
    1、通过对实践和技术（或为未充分应用的技术和实践）的定义、评估和成熟预测，以加快导入和推广高成效的软件工程的实践和技术。
    2、在软件工程和技术转型方面维护一个长期有效的资格认证工作
    3、使工业和政府组织通过自己的直接努力实现软件工程的有规划的改进
    4、促进软件工程持续不断的应用所采纳的优秀标准      CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
      初始级(initial)：软件开发过程中偶尔会出现混乱的现象,只有很少的工作过程是经过严格定义的,开发成功往往依靠的是某个人的智慧和努力。
     可重复级(repeatable)：建立了基本的项目管理过程。按部就班地设计功能、跟踪费用, 根据项目进度表进行开发。对于相似的项目,可以重用以前已经开发成功的部分。
      已定义级(defined.)：软件开发的工程活动和管理活动都是文档化、标准化的,它被集成为一个组织的标准的开发过程。所有项目的开发和维护都在这个标准基础上进行定制。
      已管理级(managed.)：对于软件开发过程和产品质量的测试细节都有很好的归纳, 产品和开发过程都可以定量地分解和控制。
      优化级(optimizing)：通过建立开发过程的定量反馈机制,不断产生新的思想, 采用新的技术来优化开发过程。
3. 我对CMM的看法：
      CMM强调的是规范的过程.它目标是求稳不求快。开发速度，开发效率不是首要追求的东西。它强调的是软件开发流程的成熟程度，可控制可预测的程度。而且引进CMM是一个渐进的过程，在初期一定会明显增加开发的工作量，如此同时改善的效果却很不明显。

4. 另外希望大家能够交流一下在实际开发中的心得
      包括：正面的："我们最近项目开发比以前顺利了许多，因为我们新引进了......方法"
                负面的："整天加班但是进展还是非常缓慢，感觉做了很多无用功......"

Terry的Blog 2006-04-09 15:35 发表评论

软件开发的评价标准（转载）

Terry的Blog — Wed, 16 Nov 2005 08:40:00 GMT

三、注释与文档

首先讨论一个计算工作量的数学模型。

1.没有注释的情况下：
第一次开发工作量＝代码行数×单位代码工作量
维护工作量＝理解代码工作量＋决定方案工作量＋修改代码行数×单位代码工作量

2、有注释的情况下：
第一次开发工作量＝代码行数×单位代码工作量＋代码行数×注释率×单位注释工作量
维护工作量＝基于注释理解代码工作量＋决定方案工作量＋修改代码行数×单位代码工作量＋修改代码行数×注释率×单位注释工作量

增加注释之后，增机了注释的工作量，这些增加需要通过节约理解代码的工作量赚回来。

3、理解代码的工作量讨论
在没有注释的情况下：
理解代码工作量＝代码总量×理解代码的效率
在有注释的情况下：
理解代码工作量＝注释总量×理解注释的效率
又因为
注释总量＝代码总量×注释率

因此，要想通过注释减少维护工作量，就要切实降低注释率，并且提高注释的效率。

4、这些数据的含义

注释率：软件的注释行数/软件的程序行数

有人像这样写代码

java代码:

//给i赋初始值 
int i=10; 
//开始循环 
for(int j=0;j){ 
//输出j的值 
System.out.println(j); 
}//循环结束 

这样的一比一注释，注释率就是1。一般来说，注释率大于1的程序，肯定是垃圾。因为写这个程序的人，根本不知道该注释哪些地方。

但是，并不是说注释率越低越好，因为注释少了之后，可能会影响理解注释的效率。

面对一次维护需求时：
理解注释的效率：需要阅读的注释行数/注释总数

如果一个维护者，在阅读了所有的注释之后，还没有理解程序，更不要说找到解决方案，那么他就必须去阅读代码。理解代码的工作量，就是没有注释时的工作量再加上被垃圾注释浪费掉的工作量。

这时的理解注释的效率，就是大于1的。写出这样的注释的人，不配做程序员。

切实提高理解注释的效率，是提高维护效率的根本。可以有以下手段：
1、结构化文档
2、HTML格式的合理的超链接
3、关键字索引（方便对于注释全文检索）
4、逻辑清晰的概要介绍

上面的这些公式都有一条：决定方案工作量。
这个工作量其实是可以合并的。以往的理解是，必须理解了现有的程序，才能决定维护的方案。但是我们可以假设，如果通过查询注释和文档，就能找到如何维护的答案，那么这样的维护就是最轻松的。

我们不假设所有的维护都能通过查询注释和文档，直接得到答案，但是如果有一个预先的合理的考虑，而写下了系统维护指南这样的文档，那么这样的文档，将是最有价值的。

另外一个手段，就是在每次维护之后，写下一个维护记录，大致格式是：
我的维护需求，我查询了哪些注释和文档，最后我在哪里找到了答案

这样的记录，将会为后来者提供极大的方便。

下面说一点题外话，因为在软件工程中，还存在这样的文档：
《功能需求描述》《概要设计》《详细设计》《.......》
我不理解为什么需要这样的文档，也不理解谁会来阅读这样的文档。为了模仿建筑工程，软件工程已经大大的扭曲了自己的本性。

注释与文档的本质，是为了便于软件的开发和维护，而不是在一道一道的工序之间作为“交接班”的说明。

如果一份文档，无法回答这两个问题，那么这份文档就是浪费了：

谁愿意写这样的文档？

Terry的Blog 2005-11-16 16:40 发表评论

BlogJava-Terry的Blog-随笔分类-软件工程

我对使用CMM的看法(初稿)

软件开发的评价标准（转载）