1219
社区成员
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
noooon 2001-10-25
CMM是对软件企业的要求，那么对开发人员有没有相应的行业标准呢？
w102272 2001-07-20
摘录的文章片断：
CMM 是一个很好的管理标准，它是西方成功软件企业从不成熟到成熟整个演绎过程(4 个阶段)经验的总结，因而对软件企业过程改进的可指导性极强。和其它管理标准相比，它对组织结构的规定、形象地体现朱兰三部曲的5 个级别的模型图(软件过程的可视性(内部活动)—成熟度等级所指示的过程能力(活动结果))、从2 级---5 级各级关键域按输入—输出方式，PDCA 模式的描述，都是其它的管理标准无可比拟的。
我国的软件企业确实是非常需要这种管理模式的帮助，但如果仅从字面上理解CMM ，是能做到符合性---CMM二级，要达到三级以上很难---根本上不去，因为，达到三、四级的符合并不等于有效，无效果的符合等于不符合，这一点与ISO9000 不同(ISO9000 审核人员大多数是只查符合，不查效果，所以对企业的帮助不大)，而CMM 推行的目的是使企业在提高软件质量的同时，降低成本，提高工作效率。二级是给企业做规矩，符合就可以，而三级以上才是标志着企业的过程改进达到此效果。因此，CMM 三级以上，才是我们追和其它管理标准一样，CMM 告诉了人们在各级别关键域要做些什么，但是为什么要这样做和如何做没为什么要这样做？-------要深刻理解CMM 就要知道为什么要这样做，“第四代管理”(美国)可帮助我们理解CMM 的内涵，它用简单的日常生活/工作中案例说明了难以理解的朱兰三步曲的原理以及在我们日常工作中常遇到的难以解决的问题。的本公司的CMM 培训课程就是用第四代管理作为辅助教材，帮助学员理解CMM ，取得较好的效果，但要让学员在几天的时间里就完全转变观念和思维方式，一下就全盘接受，是不太可能的，它似一杯浓醇的香茶，有一个品味过程，在理解的思路教给了学员后，我们相信在日后的工作实践中他们是能够品出其真正的内涵—--CMM 就是第四代管理思想和方法在软件行业的具体体现
CMM 是一个很好的管理标准，它是西方成功软件企业从不成熟到成熟整个演绎过程(4 个阶段)经验的总结，因而对软件企业过程改进的可指导性极强。和其它管理标准相比，它对组织结构的规定、形象地体现朱兰三部曲的5 个级别的模型图(软件过程的可视性(内部活动)—成熟度等级所指示的过程能力(活动结果))、从2 级---5 级各级关键域按输入—输出方式，PDCA 模式的描述，都是其它的管理标准无可比拟的。
我国的软件企业确实是非常需要这种管理模式的帮助，但如果仅从字面上理解CMM ，是能做到符合性---CMM二级，要达到三级以上很难---根本上不去，因为，达到三、四级的符合并不等于有效，无效果的符合等于不符合，这一点与ISO9000 不同(ISO9000 审核人员大多数是只查符合，不查效果，所以对企业的帮助不大)，而CMM 推行的目的是使企业在提高软件质量的同时，降低成本，提高工作效率。二级是给企业做规矩，符合就可以，而三级以上才是标志着企业的过程改进达到此效果。因此，CMM 三级以上，才是我们追和其它管理标准一样，CMM 告诉了人们在各级别关键域要做些什么，但是为什么要这样做和如何做没为什么要这样做？-------要深刻理解CMM 就要知道为什么要这样做，“第四代管理”(美国)可帮助我们理解CMM 的内涵，它用简单的日常生活/工作中案例说明了难以理解的朱兰三步曲的原理以及在我们日常工作中常遇到的难以解决的问题。的本公司的CMM 培训课程就是用第四代管理作为辅助教材，帮助学员理解CMM ，取得较好的效果，但要让学员在几天的时间里就完全转变观念和思维方式，一下就全盘接受，是不太可能的，它似一杯浓醇的香茶，有一个品味过程，在理解的思路教给了学员后，我们相信在日后的工作实践中他们是能够品出其真正的内涵—--CMM 就是第四代管理思想和方法在软件行业的具体体现
zxyii 2001-07-19
方针陈述
（Policy statement ）
当采用方针陈述时，它们一般指的是项目遵循书面的、用于那个
关键过程区域的实践的组织上的方针。这是为了强调在组织上的约定
和实际正进行工作的项目之间的连结。
方针陈述的子实践通常概述以后将被包括在关键过程区域中并
特别适合于通过书面方针加以规范化的活动。
在某些关键过程区域（例如组织过程焦点）中，关键过程区域的
活动的焦点是组织，而不是项目。这种情况下方针陈述要改写，并且
指的是组织遵循书面方针。
领导
（leadership ）
在某些关键过程区域，执行约定包含一个阐述任命一个领导角色
（例如项目软件经理）的语句，或者一个描述特别资助活动的语句，
这些是成功地规范化该关键过程区域所必须的。
资源和投资
（Resources and funding ）
大多数关键过程区域包含一个反映关键过程区域的活动对适当
的资源和投资要求的关键实践。由子实践描述的资源及投资一般分成
三类；能利用的特别的技能、足够的投资和能利用的工具。作为例子，
列出在执行关键过程区域活动中可能利用的工具。
采用“投资（funding ）”这个词而不用“预算（budget ）”这个词
是为了强调，对于实际过程而言，已交付的和已使用的东西要比许诺
的东西更有实际价值。
培训
（training ）
对于术语培训，CMM 中所指的范围比通常使用此术语时所考虑
的要宽。提供培训是为了使得个人精通专门的细则和实践。该培训可
以包括正式的和非正式的在组织中将技能和知识传授给个人的办法。
虽然课堂培训是许多组织所采用的培育雇员技能的办法，但CMM 还
提供其它的手段，例如方便的录相教学、计算机辅助指导、或者正规
的师徒计划。培训大钢这个关键过程区域描述与这些培训办法有关的
具体实践。在CMM 的所有地方一般能发现描述培训的两个样板短
语。在等级2 使用短语“接受培训”，在等级3 以上使用短语‘’接
受所要求的培训”。使用这些不同样板短语的意图是，区别出等级2
上的培训多半尚未在全组织范围内规范化。在等级3 和更高等级，预
料培训大纲这个关键过程区域的关键实践能控制组织的培训活动。在
所有的关键过程区域，潜在可能的培训专题用例子块表示，承认不同
的组织情况多半有不同的具体培训需要。
定向培训
（orientation ）
在某些关键过程区域，能找到描述定向培训的关键实践。广泛使用术
语定向培训去指明所传授的技能和知识的深度要比由培训传授的浅。
定向培训是对一个专题所作的概述或介绍，其对象是那些对在该专题
范围内负责进行工作的个人加以监督和打交道的人。
先决条款
（Prerequisite Items ）
某些关键过程区域包括描述要求先决条款的关键实践；例如，软
件开发计划是软件项目跟踪和监督的先决条款。在某些情况下，这些
先决条款可能为另一个关键过程区域活动的输出。在另一些情况下，
它们是预期能从软件项目范围之外获得的条款（例如，分配给软件的
系统需求是需求管理的先决条款）。
与CMM 突出“关键”实践的哲理相一致，对每个关键过程区域
并不列出全部先决条款。在CMM 中仅仅引用那些已被发现对关键过
程区域的实施起特别关键作用的先决条款。
计划的类型
（Types Of plans ）
在关键实践中所描述的两个主要的计划类型是：正式计划（例如：
软件开发计划、软件质量保证计划和软件配置管理计划）及非正式计
划（例如同行评审计划、风险管理计划和技术管理计划）。
非正式计划一般编写为正式计划的一部分（例如，同行评审计划
可以作为软件开发计划的一部分）或者作为正式计划的附件（例如，
同行评审进度表可以是软件开发计划中的一节）。正式计划要求有管理
者的高度支持，无论从制定这些计划的立场上看还是从保证它们得到
遵循的立场上看均是如此。在签约环境中这些计划一股交付给作为合
同甲方的顾客。
正式计划
（Formal Plans ）
在提到正式计划时，通常有两个关键实践专门描述策划活动：一
个关键实践要求按照已文档化的规程制定和修改计划，另一个要求关
键过程区域的活动基于计划。涉及已文档化的规程的子实践的内容包
括；计划的输入所必须有的内容和为了获得计划所要求的约定和支持
预计需采取的步骤。这些干实践标识出该计划的典型评审者，还突出
说明预期的批准等级。
有些计划是活动的基础，与这些计划有关的实践描述这些计划
所预计有的内容。在描述计划内容方面可以提供不同层次的细节，它
取决于计划的类型和在包括哪些一般的计划专题方面有关组织灵活性
的要求。
非正式计划
（litormal plans ）
通常非正式计划由单个关键实践描述。其子实践包括有关计划内
容的信息和用于制定或修定计划的规程。
按照文档化的现程
（According to a
documented
procedure ）
一般需要一个文档化的规程，这样，负责一个作业或活动的个人
能以重复的方式执行它，而且其它具有该领域一般知识的人员也能学
会并以同样的方式执行该作业和活动。这是使过程规范化的一个方面。
文档化规程的形式和细节层次可能变化很大，从手写的个人的桌面规
程到正式的组织的标准操作规程。形式和细节层次依赖于谁将执行该
作业或活动（例如，个人或群组），执行频率，结果的重要性和所预计
的用途，以及结果的预计接收者。
分配给软件的系统
需求(System
requirements
allocated to
Software)
在CMM 中分配给软件的系统需求通常称为“分配需求”，它是系
统需求中将用系统的软件成分实现的子集。分配需求是软件开发计划
的主要输入。软件需求分析详细阐述和精炼分配需求，结果产生文档
化的软件需求。
顾客需求涉及整个的系统，不只是软件。CMM 中，对顾客需求的
讨论集中于那些将用软件实现的顾客需求。将系统需求分配给硬件、
软件等等是整个系统设计的一部分，一般由系统工程组完成。分配给
软件项目的系统需求在CMM 中一般称作“分配需求”，既包括技术需
求（功能性、性能等等），也包括非技术需求（交付日期、成本等等）
顾客一供应商关系
(Customer supplier
relationship)
顾客可以是组织内部的，也可以是组织外部的。内部顾客的一个例子
是营销小组；外部顾客的～个例子是国防部。用户也可能不同于顾客，
国防部签约环境中情况正是如此。CMM 是用外部顾客加以表述的，他
们是采购带有关键软件成分的系的人员或组织在需要处必须恰当地解
释（正如在CMM 中所述的）组间的边界，例如，在仅仅采购软件的情
况下，顾客和软件工程组之间可以没有系统工程组。此时，顾客需求、
系统需求和分配需求可能是同义语，系统工程组的职责将由顾客及软
件工程组分担。
按管理要求进行跟
踪和采取纠正措施
(Tracking and Taking correctiveaction
versus managing)
等级2 在软件项目跟踪和监督关键过程区域中的许多关键实践采用短
语“跟踪…，必要时采取纠正措施。”在等级3 的集成软件管理中的许
多类似的关键实践采用短语“进行管理”。这个用字上的差异反映出等
级2 上的项目缺乏一个完全定义的软件过程。管理措施很可能是对实
际问题的反应。在等级3 上项目有一个完全定义的软件过程，不同软
件工作产品、作业和活动之间的关系也是妥善定义的。管理者更能预
见会出现的问题并能预先采取措施防止它们发生。在要求进行干预时，
干预对整个软件过程的效果是清楚的，因而能更有效地定义和运用这
些干预。
经过评审和经过同
行评审的比较
(Reviewed versus
under goes peer
reviews)
在评审中，将一个软件工作产品或一组工作产品提交给经理、顾客、
最终用户、或其它有兴趣的个人，以得到他们的评论或批准。评审一
般出现在作业结束时。在同行评审中，将一个软件工作产品或一组工
作产品提交给生产者的同事们以识别出缺陷。经理、顾客或终端用户
一般不出席同行评审。同行评审是作业过程中不可缺少的部分。进行
同行评审使得缺陷能及早排除，导致较高的生产率和高质量的产品。
某些软件工作产品将经过评审；某些将经过同行评审；还有一些将既
经受评审又经受同行评审。
置于配置管理之下
与之进行管理和控
制相比较
(Placed under
configuration
management versus
managed and
Controlled)
某些软件工作产品，例如软件设计和代码，应在预先确定的点上
建立基线。这些基线经过正式评审和认同，作为进一步开发工作的基
础。对已基线化的配置项施加严格的更改控制过程。在与顾客打交道
时，这些基线提供控制和稳定性。有时称此为基线配置管理。短语“置
于配置管理之下”用于此类软件工作产品。当配置控制由开发者实施
时，通常称之为开发配置管理。在预先确定的开发中的某些点上，开
发配置管理下的某些项可置于基线配置管理之下。虽然对短语“置于
配置管理之下”的解释可扩展至开发配置管理，但是正确的基本解释
是仅要求实施基线配制管理。
某些软件工作产品，例如估计或软件开发计划，可以不必置于配
置管理之下，但仍然需要“进行管理和控制”。这些软件工作产品不是
基线的一部分，因此不用置于配置管理之下，但它们必须受控以使得
项目按一种有纪律的方式进行工作，短语“进行管理和控制”用于对
标识和定义这种软件工作产品的过程进行特征描述。“进行管理和控
制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知
的（即版本控制），并且更改以一种受控的方式引入（即更改控制）。
高级管理者作定期评审的主要目的是在合适的抽象层次上和
以及时的方式了解和洞察软件过程活动。评审间隔应满足组织的需
要，只要已存在有报告例外情况的合适机制，间隔可以长。
为了强调项目在不同的阶段和依赖于项目的不同特征而需要
不同类型的评审，在这些关键实践的描述中采用样板短语“既定期
地也事件驱动地”。项目管理者应保持对软件工作状态的不断了解，
并在软件项目出现重大事件时收到报告。例子包括项目管理者参加
诸如关键设计评审那样的正式评审，和围绕过程问题的评审--例
如．有关过程改进规划的状态和过程不符合问题的解决等的评审。
预计在项目层上，项目管理者的监督要比高级管理者的监督详细，
反映出项目管理者更为积极地卷入项目的运行方面。
软件质量保证活动
（Software quality
assurance activities ）
用一个关键实践描述那些据信适宜于软件质量保证（SQA ）组
作评审和（或）审计的特定活动。但存在一些特殊情况，在那里
SQA 验证活动未被描述，例如在培训大纲和组间协调关键过程区域
中。这些是处在软件项目和组织间的边界上的关键过程区域，预计
在这里SQA 组不会有权威。
（Policy statement ）
当采用方针陈述时，它们一般指的是项目遵循书面的、用于那个
关键过程区域的实践的组织上的方针。这是为了强调在组织上的约定
和实际正进行工作的项目之间的连结。
方针陈述的子实践通常概述以后将被包括在关键过程区域中并
特别适合于通过书面方针加以规范化的活动。
在某些关键过程区域（例如组织过程焦点）中，关键过程区域的
活动的焦点是组织，而不是项目。这种情况下方针陈述要改写，并且
指的是组织遵循书面方针。
领导
（leadership ）
在某些关键过程区域，执行约定包含一个阐述任命一个领导角色
（例如项目软件经理）的语句，或者一个描述特别资助活动的语句，
这些是成功地规范化该关键过程区域所必须的。
资源和投资
（Resources and funding ）
大多数关键过程区域包含一个反映关键过程区域的活动对适当
的资源和投资要求的关键实践。由子实践描述的资源及投资一般分成
三类；能利用的特别的技能、足够的投资和能利用的工具。作为例子，
列出在执行关键过程区域活动中可能利用的工具。
采用“投资（funding ）”这个词而不用“预算（budget ）”这个词
是为了强调，对于实际过程而言，已交付的和已使用的东西要比许诺
的东西更有实际价值。
培训
（training ）
对于术语培训，CMM 中所指的范围比通常使用此术语时所考虑
的要宽。提供培训是为了使得个人精通专门的细则和实践。该培训可
以包括正式的和非正式的在组织中将技能和知识传授给个人的办法。
虽然课堂培训是许多组织所采用的培育雇员技能的办法，但CMM 还
提供其它的手段，例如方便的录相教学、计算机辅助指导、或者正规
的师徒计划。培训大钢这个关键过程区域描述与这些培训办法有关的
具体实践。在CMM 的所有地方一般能发现描述培训的两个样板短
语。在等级2 使用短语“接受培训”，在等级3 以上使用短语‘’接
受所要求的培训”。使用这些不同样板短语的意图是，区别出等级2
上的培训多半尚未在全组织范围内规范化。在等级3 和更高等级，预
料培训大纲这个关键过程区域的关键实践能控制组织的培训活动。在
所有的关键过程区域，潜在可能的培训专题用例子块表示，承认不同
的组织情况多半有不同的具体培训需要。
定向培训
（orientation ）
在某些关键过程区域，能找到描述定向培训的关键实践。广泛使用术
语定向培训去指明所传授的技能和知识的深度要比由培训传授的浅。
定向培训是对一个专题所作的概述或介绍，其对象是那些对在该专题
范围内负责进行工作的个人加以监督和打交道的人。
先决条款
（Prerequisite Items ）
某些关键过程区域包括描述要求先决条款的关键实践；例如，软
件开发计划是软件项目跟踪和监督的先决条款。在某些情况下，这些
先决条款可能为另一个关键过程区域活动的输出。在另一些情况下，
它们是预期能从软件项目范围之外获得的条款（例如，分配给软件的
系统需求是需求管理的先决条款）。
与CMM 突出“关键”实践的哲理相一致，对每个关键过程区域
并不列出全部先决条款。在CMM 中仅仅引用那些已被发现对关键过
程区域的实施起特别关键作用的先决条款。
计划的类型
（Types Of plans ）
在关键实践中所描述的两个主要的计划类型是：正式计划（例如：
软件开发计划、软件质量保证计划和软件配置管理计划）及非正式计
划（例如同行评审计划、风险管理计划和技术管理计划）。
非正式计划一般编写为正式计划的一部分（例如，同行评审计划
可以作为软件开发计划的一部分）或者作为正式计划的附件（例如，
同行评审进度表可以是软件开发计划中的一节）。正式计划要求有管理
者的高度支持，无论从制定这些计划的立场上看还是从保证它们得到
遵循的立场上看均是如此。在签约环境中这些计划一股交付给作为合
同甲方的顾客。
正式计划
（Formal Plans ）
在提到正式计划时，通常有两个关键实践专门描述策划活动：一
个关键实践要求按照已文档化的规程制定和修改计划，另一个要求关
键过程区域的活动基于计划。涉及已文档化的规程的子实践的内容包
括；计划的输入所必须有的内容和为了获得计划所要求的约定和支持
预计需采取的步骤。这些干实践标识出该计划的典型评审者，还突出
说明预期的批准等级。
有些计划是活动的基础，与这些计划有关的实践描述这些计划
所预计有的内容。在描述计划内容方面可以提供不同层次的细节，它
取决于计划的类型和在包括哪些一般的计划专题方面有关组织灵活性
的要求。
非正式计划
（litormal plans ）
通常非正式计划由单个关键实践描述。其子实践包括有关计划内
容的信息和用于制定或修定计划的规程。
按照文档化的现程
（According to a
documented
procedure ）
一般需要一个文档化的规程，这样，负责一个作业或活动的个人
能以重复的方式执行它，而且其它具有该领域一般知识的人员也能学
会并以同样的方式执行该作业和活动。这是使过程规范化的一个方面。
文档化规程的形式和细节层次可能变化很大，从手写的个人的桌面规
程到正式的组织的标准操作规程。形式和细节层次依赖于谁将执行该
作业或活动（例如，个人或群组），执行频率，结果的重要性和所预计
的用途，以及结果的预计接收者。
分配给软件的系统
需求(System
requirements
allocated to
Software)
在CMM 中分配给软件的系统需求通常称为“分配需求”，它是系
统需求中将用系统的软件成分实现的子集。分配需求是软件开发计划
的主要输入。软件需求分析详细阐述和精炼分配需求，结果产生文档
化的软件需求。
顾客需求涉及整个的系统，不只是软件。CMM 中，对顾客需求的
讨论集中于那些将用软件实现的顾客需求。将系统需求分配给硬件、
软件等等是整个系统设计的一部分，一般由系统工程组完成。分配给
软件项目的系统需求在CMM 中一般称作“分配需求”，既包括技术需
求（功能性、性能等等），也包括非技术需求（交付日期、成本等等）
顾客一供应商关系
(Customer supplier
relationship)
顾客可以是组织内部的，也可以是组织外部的。内部顾客的一个例子
是营销小组；外部顾客的～个例子是国防部。用户也可能不同于顾客，
国防部签约环境中情况正是如此。CMM 是用外部顾客加以表述的，他
们是采购带有关键软件成分的系的人员或组织在需要处必须恰当地解
释（正如在CMM 中所述的）组间的边界，例如，在仅仅采购软件的情
况下，顾客和软件工程组之间可以没有系统工程组。此时，顾客需求、
系统需求和分配需求可能是同义语，系统工程组的职责将由顾客及软
件工程组分担。
按管理要求进行跟
踪和采取纠正措施
(Tracking and Taking correctiveaction
versus managing)
等级2 在软件项目跟踪和监督关键过程区域中的许多关键实践采用短
语“跟踪…，必要时采取纠正措施。”在等级3 的集成软件管理中的许
多类似的关键实践采用短语“进行管理”。这个用字上的差异反映出等
级2 上的项目缺乏一个完全定义的软件过程。管理措施很可能是对实
际问题的反应。在等级3 上项目有一个完全定义的软件过程，不同软
件工作产品、作业和活动之间的关系也是妥善定义的。管理者更能预
见会出现的问题并能预先采取措施防止它们发生。在要求进行干预时，
干预对整个软件过程的效果是清楚的，因而能更有效地定义和运用这
些干预。
经过评审和经过同
行评审的比较
(Reviewed versus
under goes peer
reviews)
在评审中，将一个软件工作产品或一组工作产品提交给经理、顾客、
最终用户、或其它有兴趣的个人，以得到他们的评论或批准。评审一
般出现在作业结束时。在同行评审中，将一个软件工作产品或一组工
作产品提交给生产者的同事们以识别出缺陷。经理、顾客或终端用户
一般不出席同行评审。同行评审是作业过程中不可缺少的部分。进行
同行评审使得缺陷能及早排除，导致较高的生产率和高质量的产品。
某些软件工作产品将经过评审；某些将经过同行评审；还有一些将既
经受评审又经受同行评审。
置于配置管理之下
与之进行管理和控
制相比较
(Placed under
configuration
management versus
managed and
Controlled)
某些软件工作产品，例如软件设计和代码，应在预先确定的点上
建立基线。这些基线经过正式评审和认同，作为进一步开发工作的基
础。对已基线化的配置项施加严格的更改控制过程。在与顾客打交道
时，这些基线提供控制和稳定性。有时称此为基线配置管理。短语“置
于配置管理之下”用于此类软件工作产品。当配置控制由开发者实施
时，通常称之为开发配置管理。在预先确定的开发中的某些点上，开
发配置管理下的某些项可置于基线配置管理之下。虽然对短语“置于
配置管理之下”的解释可扩展至开发配置管理，但是正确的基本解释
是仅要求实施基线配制管理。
某些软件工作产品，例如估计或软件开发计划，可以不必置于配
置管理之下，但仍然需要“进行管理和控制”。这些软件工作产品不是
基线的一部分，因此不用置于配置管理之下，但它们必须受控以使得
项目按一种有纪律的方式进行工作，短语“进行管理和控制”用于对
标识和定义这种软件工作产品的过程进行特征描述。“进行管理和控
制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知
的（即版本控制），并且更改以一种受控的方式引入（即更改控制）。
高级管理者作定期评审的主要目的是在合适的抽象层次上和
以及时的方式了解和洞察软件过程活动。评审间隔应满足组织的需
要，只要已存在有报告例外情况的合适机制，间隔可以长。
为了强调项目在不同的阶段和依赖于项目的不同特征而需要
不同类型的评审，在这些关键实践的描述中采用样板短语“既定期
地也事件驱动地”。项目管理者应保持对软件工作状态的不断了解，
并在软件项目出现重大事件时收到报告。例子包括项目管理者参加
诸如关键设计评审那样的正式评审，和围绕过程问题的评审--例
如．有关过程改进规划的状态和过程不符合问题的解决等的评审。
预计在项目层上，项目管理者的监督要比高级管理者的监督详细，
反映出项目管理者更为积极地卷入项目的运行方面。
软件质量保证活动
（Software quality
assurance activities ）
用一个关键实践描述那些据信适宜于软件质量保证（SQA ）组
作评审和（或）审计的特定活动。但存在一些特殊情况，在那里
SQA 验证活动未被描述，例如在培训大纲和组间协调关键过程区域
中。这些是处在软件项目和组织间的边界上的关键过程区域，预计
在这里SQA 组不会有权威。
bland 2001-07-18
现在有点体会：有相当多的中国公司的管理层 小农思想太浓厚了
而CMM的实现需要现代化的管理思路
而CMM的实现需要现代化的管理思路
w102272 2001-07-11
ＣＭＭ方法需要在中国的现实环境下予以改造，以便适应中国中小企业，以及不规范的现状．希望依靠一个认证来规范企业软件开发过程，是一种本末倒置的行为．
CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程
但是，应该说，前四个都是手段，只有最后一个才是目的．但是在达到目标５之前，多数公司会出现开销过大，僵化，以及不适应公司整体发展水平和人文环境的问题．为了实施ＣＭＭ，首先需要对组织体系和企业文化进行必要的改变．ＣＭＭ也可以看做是从技术体系上描述的管理思想．
ＣＭＭ描述了一种规范可评估的软件开发过程原则．但是并无法也不能确定按照此种原则必然会达到的效果，因此不是万灵丹，而是评价标准和参考规范．
如同各种系统设计方法不同，但是良好的适用最终可以达到相同的产品效果一样，为了达到过程管理的目标，可以实施各种手段和思想体系．ＣＭＭ是其中一种比较流行和规范的方法，但并不是唯一方法．
软件开发过程，在某种程度上，也类似一个生命．绝对的规范并不是合适的，静态规范在某种意义上也意味着僵化和死亡．为了适应需求变化和环境变化，软件过程也应该作具体的变化，改进和环境适应．如同生命一样，它应该是一种＂螺旋式进化的生命过程＂，是处于秩序的混沌状态．因此，只有ＣＭＭ５，才开始触及软件开发过程的核心．
个人看法：
基于知识重用的开发过程，
基于螺旋演化的开发过程，
在任何方面能够实现持续化改进（过程改进／产品改进／技术能力改进等等）的方法是ＣＭＭ的核心思想．
个人看法：
为了减小开销，以及适用中国的国情，简单套用ＣＭＭ方法会遇到障碍．
在ＣＭＭ的框架下实施ＰＳＰ／ＴＳＰ／ＸＰ这样的方法，会更加符合中小企业的国情和管理现状．也不至于因为适应性问题，导致ＣＭＭ变形和压制创新．另外，ＣＭＭ方法对如何具体实现从ＣＭＭ２-> CMM5的过渡描述不足，手段也不足．也需要加以注意．
个人的一些不成熟观点，请高手指点，谢谢！
CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程
但是，应该说，前四个都是手段，只有最后一个才是目的．但是在达到目标５之前，多数公司会出现开销过大，僵化，以及不适应公司整体发展水平和人文环境的问题．为了实施ＣＭＭ，首先需要对组织体系和企业文化进行必要的改变．ＣＭＭ也可以看做是从技术体系上描述的管理思想．
ＣＭＭ描述了一种规范可评估的软件开发过程原则．但是并无法也不能确定按照此种原则必然会达到的效果，因此不是万灵丹，而是评价标准和参考规范．
如同各种系统设计方法不同，但是良好的适用最终可以达到相同的产品效果一样，为了达到过程管理的目标，可以实施各种手段和思想体系．ＣＭＭ是其中一种比较流行和规范的方法，但并不是唯一方法．
软件开发过程，在某种程度上，也类似一个生命．绝对的规范并不是合适的，静态规范在某种意义上也意味着僵化和死亡．为了适应需求变化和环境变化，软件过程也应该作具体的变化，改进和环境适应．如同生命一样，它应该是一种＂螺旋式进化的生命过程＂，是处于秩序的混沌状态．因此，只有ＣＭＭ５，才开始触及软件开发过程的核心．
个人看法：
基于知识重用的开发过程，
基于螺旋演化的开发过程，
在任何方面能够实现持续化改进（过程改进／产品改进／技术能力改进等等）的方法是ＣＭＭ的核心思想．
个人看法：
为了减小开销，以及适用中国的国情，简单套用ＣＭＭ方法会遇到障碍．
在ＣＭＭ的框架下实施ＰＳＰ／ＴＳＰ／ＸＰ这样的方法，会更加符合中小企业的国情和管理现状．也不至于因为适应性问题，导致ＣＭＭ变形和压制创新．另外，ＣＭＭ方法对如何具体实现从ＣＭＭ２-> CMM5的过渡描述不足，手段也不足．也需要加以注意．
个人的一些不成熟观点，请高手指点，谢谢！
freebase 2001-07-09
to zxyii 从全球工业来讲,70年代80年代已经进入了全面质量管理的时代,CMM是在这个基础之上针对软件工程开发提出来的,理解了这个背景,我想是有帮助的.
freebase 2001-07-06
to zxyii ,我想你也在搞CMM,说的挺专业.呵呵
zxyii 2001-07-06
前者的目的主要是在于暴露问题的邦助改进他们的组织
后者的目的是审核,并形成文件
后者的目的是审核,并形成文件
zxyii 2001-07-06
评定一个组织执行的软件过程的成熟度有两种方法
1.软件过程评估,
2.软件能力评价,
1.软件过程评估,
2.软件能力评价,
zxyii 2001-07-06
等级2的可重复级就已经没有多少公司能达到了
何况是能自我完善的等级5
何况是能自我完善的等级5
good_girl 2001-07-06
记笔记
zxyii 2001-07-06
http://moon.nju.edu.cn/CMMChinese/index.html
上面有关于CMM的详细介绍
上面有关于CMM的详细介绍
zxyii 2001-07-06
自从1987年卡奈基.梅隆大学的软件工程研究所提出CMM（能力成熟度模型）以来，到1999年的六月份为止，共进行1330次评测，其中包括841次CBA IPI（基于CMM的机构内部过程改进评测）和489次SPA（软件过程评测），共有1036家机构和270家公司参加，更有244家机构进行了多次评测，总计参加评测的项目有5452项 。值得一提的是，参加评测的机构是逐年攀升，自95至99年，就有734家机构和217家公司的3390个项目参加评测，其中有27.2%是海外项目。
曾经参加过评测的国家：
包括美国、英国、日本、德国和中国在内的34个国家。
曾经参加过评测的国家：
包括美国、英国、日本、德国和中国在内的34个国家。
zxyii 2001-07-06
CMM提供了一种有条不紊且一致的方法改进软件产品的管理和开发的概念性结构.
但是它并不能保证软件产品将成功地制造出来,它只是标识出有效软件过程的特征
to Freebase
我不过边学边卖
但是它并不能保证软件产品将成功地制造出来,它只是标识出有效软件过程的特征
to Freebase
我不过边学边卖
bland 2001-07-05
to zxyii(编程疯狗):
你的想法我也赞同,不过每个人的看问题的角度不同 有时间就CMM多讨论讨论 :)
你的想法我也赞同,不过每个人的看问题的角度不同 有时间就CMM多讨论讨论 :)
wwwunix 2001-07-05
学习
GRIEG 2001-07-05
CMM给了很好的过程控制，着重于管理和技术的结合。
如果能达到CMM3的13个key area就不错了。
项目的成功毕竟还是需要人来操作，人的因数还是最重要的，我认为。
如果能达到CMM3的13个key area就不错了。
项目的成功毕竟还是需要人来操作，人的因数还是最重要的，我认为。
wolfboy 2001-07-03
这个也要看国情的来的，也不能看着别人都采用CMM，我们也跟着招搬
yuminggang 2001-07-03
这和用什么语言的关系不大,而且CMM已经是一个成熟的模型啦,他只是一种管理思路和方法,难道我们连学习方法还要说和语言有关系么?
还有?我们为什么讨论这个问题?是因为我们自己落后,而且没有创造性,只是一味的跟着走,没有自己的东西,我们是落后,这没什么好狡辩的,但我们的聪明也没有用对地方,我们什么时候有自己的方式方法,放弃照搬呢?真是可悲,总是拿着别人的标准来衡量自己,每个人都津津乐道,以为触摸到一个前沿的东西,为什么我们就没有批判和分辨呢?
眼看着数以百万的人们,傻呵呵的追随着,忘记了我们曾经的四大发明和令人惊异的创造天赋,现在不是达到几级的问题,也不是CMM的问题,而是一个民族是否还可以有自己独特的思维方式和创造性的问题.
还有?我们为什么讨论这个问题?是因为我们自己落后,而且没有创造性,只是一味的跟着走,没有自己的东西,我们是落后,这没什么好狡辩的,但我们的聪明也没有用对地方,我们什么时候有自己的方式方法,放弃照搬呢?真是可悲,总是拿着别人的标准来衡量自己,每个人都津津乐道,以为触摸到一个前沿的东西,为什么我们就没有批判和分辨呢?
眼看着数以百万的人们,傻呵呵的追随着,忘记了我们曾经的四大发明和令人惊异的创造天赋,现在不是达到几级的问题,也不是CMM的问题,而是一个民族是否还可以有自己独特的思维方式和创造性的问题.
freebase 2001-07-02
非常同意qingrun的说法，许多人老是想着拿那个证，梦想着一天就到2级，说这是一个管理上的循序渐进的过程，还打死也不听。
加载更多回复
软件企业如何实施CMM 本文讨论软件企业实施CMM或通过CMM评估所必须经历的步骤，希望能起到一个抛砖引玉的作用，软件企业实际实施CMM时，可以根据自身的实际情况和具体要求加以应用。1、提高思想认识 近年来，随着国民经济持续增长，作为...
软件测试面试题汇总 26、简述一下缺陷的生命周期？ .................................................................................................................... 9 27、软件的安全性应从哪几个方面去测试？ .............
CMM与CMMI的关系 文章目录一：简介二：CMM等级三：CMM的基本思想四：引进CMM的主要意义1.对软件公司2.对软件项目发包单位和软件用户CMMI一：简介二：CMMI背景介绍三：CMMI的基本思想四：CMMI模型的表示法1.阶段式表示法2.连续式表示...
软件企业如何实施CMM？ CMM(软件过程能力成熟模型)的主要思想很清楚，标准的条例也很明确，但如何达到这种标准的可...本文讨论软件企业实施CMM或通过CMM评估所必须经历的步骤，希望能起到一个抛砖引玉的作用，软件企业实际实施CMM时，可以根据
关于CMM的一场讨论 http://forum.iteye.com/viewtopic.php?t=9459 这是Javaeye的一场...关于CMM讨论已经极为深入，甚至可以算得上深刻了。 最近又来了两个CMM的支持者，一个是askycn，一个是青海渔风。我问了他们一个问题：你认为推进...
CMM 转自： http://www.itisedu.com/phrase/200603051508215.htmlCMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。...CMM的核心是把软件开发视为一
CMM评审（十） 我们的客户对项目的质量和进度都有要求，希望我们快速交付出高质量的产品 2.组织面临的最需要优先解决的问题是什么？(what problem need to prior to tackle?) 目前提高团队的有效生产率是最主要考虑的问题，我们.....
软件企业如何实施CMM (转) 软件企业如何实施CMM 国内的绝大部分软件企业目前处于CMM的初级阶段，没有基础和经验。虽然CMM的主要思想很清楚，标准的条例也很明确，但如何达到这种标准的可操作性比较差。所以许多企业在实施CMM的过程中，往往...
软件企业如何实施CMM（转） 软件企业如何实施CMM国内的绝大部分软件企业目前处于CMM的初级阶段，没有基础和经验。虽然CMM的主要思想很清楚，标准的条例也很明确，但如何达到这种标准的可操作性比较差。所以许多企业在实施CMM的过程中，往往感到...
什么是CMM CMM综述 CMM(Capability Maturity Model能力成熟度模型)的本质是软件管理工程的一个部分。它是对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。他通过5个不断进化的层次来评定...
CMM简介 CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心...
