1,268
社区成员
发帖
与我相关
我的任务
分享CMM在中国将会如何?
CMM的知识体系在中国的最早引入是国防系统以及部分大学和研究所，而在中国最早实施CMM的公司是Motorola中国公司，他们在1993年就开始实施CMM，并于1996年就达到CMM3，但是并没有广为宣传，也没有对整个软件业界产生大的影响。真正对软件业界产生较大的冲击力的是1997年7月鼎新公司通过CMM2，从此，有关规模化的CMM“知识导入期”开始，这个时期的特点主要是从国外（主要是从美国）引入大量有关CMM的资料（有关CMM本身的和有关运用CMM的）。另外，2001年，中国联想公司通过软件事业部的CMM2，这标志着CMM知识体系在中国进入了“研究实施期”。
到目前为止，国内有关CMM的研究和实施已经取得了很大的进展，同时，我国政府也大力支持软件产业的发展，为了响应国务院18号文件的精神，很多地方政府制定了适合于自身软件产业发展的鼓励政策，今年我国十大软件园区挂牌成立就是一个很有力的说明。为了进一步规范市场和正确引导我国软件产业的发展，信息产业部在2001年4月发布了《软件能力成熟度模型》的行业标准。
目前国内有的工具主要是CASE工具，在这个方面早就被国外的CASE开发商抢占先机，普遍为国人接受的是Rational 的ClearClass系列工具，另外CA公司也不是等闲之辈。唯一能让国人感到自豪的就是北大青鸟的JBCM-Web和JBCM。而针对CMM的评估工具，国内是一片空白。
目前国内有关CMM评估还是企业行为，并没有通过国家的统一管理和指导。同时，评估时对评估过程中数据的处理也是根据自己对《软件能力成熟度模型》的理解来进行的，没有使用针对《软件能力成熟度模型》的评估工具，在科学性，公平性以及公正性方面缺乏说服力，这对实施和推广CMM是极其危险的。
到目前为止，国内有关CMM的研究和实施仍然停留在面上，没有实质性的进展，这主要是和我国软件产业整个产业发展的水平相关，国人对此也无奈，因为对CMM来说，如果要达到它的要求，并非一朝一夕之功，需要结合自身的情况，严格按照CMM的框架结构，才有可能达到预期效果。
目前国内有的工具主要是CASE工具，在这个方面早就被国外的CASE开发商抢占先机，普遍为国人接受的是Rational 的ClearClass系列工具，另外CA公司也不是等闲之辈。唯一能让国人说上一两句的就是北大青鸟的JBCM-Web和JBCM。而针对CMM的评估工具，国内真是一片空白，有人想做，但是没有办法，因为不了解，这不能简单地说只是一个技术问题，它与整个行业发展的水平是密切相关的。对CMM的理解和认识是需要很深的文化背景和行业背景的。
CMM对企业来说，是软件企业过程改进和管理水平得到提高行之有效的方法，而不是企业应该造就的牌子，但目前国内却有很大的“牌子”误区，这与CMM的初衷是背道而驰的。如果要承认和使用CMM，就要遵循这样的规则：严格按照CMM对组织的软件过程改进的要求执行，否则你就别瞎搀乎。既然要把CMM作为医治软件企业过程 改进和管理上存在的弊病的良方，就得遵循适当原则，因为CMM这种药不能轻易吃，即不能多吃，否则会要命；也不能少吃，因为会让你对你的软件企业失去信心；更不能停药之后走回头路，除了耗费大量的人力、物力、财力以及时间以外，浑身上下不舒服的是你自己软件公司。
除此之外，我想还有一个我们都担心的问题是我们的政府会如何对待CMM在中国的发展，我们的政府会采用什么样的方式来扶持CMM在中国的发展，我们作为业界的从业人员，都担心这样的问题，因为ISO 9000兵败中国就是一个最好证明。国务院已经颁发了18号文件，以鼓励和支持中国软件产业的发展，一些地方政府也制定了相应的鼓励政策，今年全国十大软件园区的挂牌成立就是一个最好的例子，这真是上下齐心协力的好榜样，不过国人都好面子，都讲牌子，你通过CMM2，不行，对我的发展造成了很大的威胁，我要通过CMM3，至少也要通过CMM2，不管企业自身的水平是否达到了CMM的要求，都会来个短兵突击，对CMM的内容照抄照搬，所谓“上有政策，下有对策”，把CMM的评估要求再研究一翻，做好准备，把专家找来，而不管企业本身的运行如何，是通过了，但是只是拿到牌子，并没有对企业本身的软件过程改进起到作用，企业以前是如何运行的现在还是老样子。国外的统计数字表明：CMM每跨一级，至少需要两年的时间来改进，这告诫国人，不要一蹴而就，欲速则不达，害了的是自己。
所以，我们要小心，CMM是企业本身的事情，是对整个企业本身软件过程改进的指导，是软件企业练内功的功法，决不是质量保证体系，不能用来贴在商品上的，是不能作为商标用的。
另外，说到ISO 9000兵败中国，我们不能把这样的命运来对待CMM，我想我们的软件企业管理人员（无论是高级经理，还是项目经理），都对自己的企业充满信心，都对CMM抱很大的希望，在实施过程中都是小心的，都充分考虑了CMM的每一个级别的KPA(关键惯例)。还有，我们在实施ISO 9000的过程中，都是结合自己的国情，多数情况下都缺乏思考，这是因为掌握ISO 9000在中国的命运的人们，对ISO 9000的内涵了解不够透彻，是因为他们只做“政策”不做技术，不知道技术的内涵是什么，有些时候喜欢把它作为一种文字游戏来对待，但是技术不是文字游戏。除此之外，ISO 9000也有它的缺陷，综合起来主要是下述两个方面的原因造成的：
1、从ISO 9000自身角度来看，它包括了20个企业活动种类要素，虽然强调了质量持续改进的观点，但没有明确如何循序渐进地在企业建立与落实这些活动要素。
2、从企业自身来看，建立ISO 9000质量体系的动机不纯，很多都是把它作为一种通向市场的手段，质量规范走过场，上上下下一致对外，是保护了自己，但同时又害了自己。
CMM较之ISO 9000来说，进步主要表现在：
1、指出了进步管理的四个台阶；
2、指出在每个台阶上必须要完成哪些必要工作才能进行管理版本升级。
中国企业在骨子里就是反规范的，在实施CMM这样的过程改进手段时，会叶公好龙，哪一个细节上除了一点问题，就会群起而攻之，结果很多都是由于无法承受这样的压力而半途而废，真是可悲。
另外，我们都应该注意到，现在CMM在中国掉入了前面所述的陷阱中，国内有关CMM培训、咨询和管理的公司可谓是如雨后春笋般出现在北京、西安、广州和上海等地，大家都好像异口同声地说，我们都很有实力，都对自己冠以国内唯一这样的字样，其实明白人眼里是揉不进沙子的，CMM在中国经历了什么，除了一两张认证资格证书以外，并没有什么，大家都在鼓吹自己，其实都是心虚的表现，国内现在有关CMM咨询、培训的工程师，就单凭CMM中对CMM评估人员的背景要求，可以毫不客气地说，部分公司是没有评估人员的，而更多时候好像是一些江湖郎中，这对我们的软件企业真的会达到治病救人吗？
当然，出现这样的问题，是绝对不能将责任归咎于谁，只是想大家多应该冷静，把更多的时间和精力放在思考我们的软件企业的文化背景，以及由此而出现的软件企业文化。我们什么东西好像都喜欢说是中国特色，其实， CMM在中国实施的这个问题上，我们同样可以大胆地把CMM中国化，不过这样的大前提是必须了解我们的软件企业需要什么。
前面我们已经提到CMM和ISO 9000的区别，这个问题现在都认识到了，CMM更多地是企业行为，并不是用来规范市场的（不过现在信息产业部已经说明以后软件产品的出口必须通过CMM认证，这个时候更多地是政府行为），这就要求企业本身要把CMM对软件企业管理、开发等过程方面的要求落实到自己的企业管理和软件开发过程中。
我们在开发SPI评估工具的过程当中，综合考虑到了上述情况，将工具的功能限定在一定的范围之内，而不是只是单纯地将它的功能限定在评估职能上，下面，我们将会详细介绍SPI的功能：
1、 功能特点：
SPI评估工具是以《软件能力成熟度模型》，即以SJ/T 11234为核心，以《成熟度评估框架要求》为指导，参考《CMMI评估要求》，根据国内评估人员提出的需求，借鉴和学习国内外评估工具的优点，适合国内CMM评估的需要。
2、完全符合标准要求的评估流程:图1是工具的评估流程和《成熟度评估框架要求》的评估流程。从这个图中我们可以看到，评估工具的评估流程是完全符合《成熟度评估框架要求》中的评估要求和流程的，部分细节上的调整是更具评估的需要所做的改动。
3、 除了评估企业的CMM能力以外，工具本身的另外一个功能就是将《软件能力成熟度
模型》的内容简化，但是对《软件能力成熟度模型》的核心和灵魂部分是丝毫无损，企业管理人员、软件开发人员完全可以使用本工具来学习和研究CMM。
4、 便于培训和学习
l 有助于评估组长培训评估小组成员
l 在培训过程中，有助于评估人员掌握评估必要的知识和技能
l 有助于评估人员学习《软件能力成熟度模型》的内容
l 提供《软件能力成熟度模型》内容的参考
l 可以为软件企业的管理者以及CMM的实施者了解和掌握SPI的评估内容以及流程，同时便于实施CMM对软件开发过程进行改进。
图1 CMM评估流程图
(由于此论坛不能显示图片,只好作罢)
上述评估流程图是使用工具的评估流程图，下面将介绍《成熟度评估框架要求》中的评估流程图。
从这两个流程图的比较可以看出，使用“工具”的流程图和《成熟度评估框架 要求》中的流程图在逻辑上是一致的，除了部分细节内容不同以外，其它的都完全相同，因此，评估人员对于使用本“工具”进行评估，掌握它的评估流程是非常简单的事情。
对于这个评估工具，作者本人并不想作过多的介绍，我不想改变自己的初衷，因为我不是想借此机会鼓吹这个工具的好处，我只是说一些想说的话，同时，我相信我想说的是有依据的，并非是我自己一时兴起，对目前国内对于软件质量体系建设的不满，抱怨归抱怨，我们最关心的问题还是CMM在中国如何实施，达到改进我国软件企业中软件开发管理的种种弊病。因此，我是相信对CMM感兴趣，特别是关心CMM在中国发展命运的同僚们会接受我的说法的，希望我能开一个好头。
到目前为止，国内有关CMM的研究和实施已经取得了很大的进展，同时，我国政府也大力支持软件产业的发展，为了响应国务院18号文件的精神，很多地方政府制定了适合于自身软件产业发展的鼓励政策，今年我国十大软件园区挂牌成立就是一个很有力的说明。为了进一步规范市场和正确引导我国软件产业的发展，信息产业部在2001年4月发布了《软件能力成熟度模型》的行业标准。
目前国内有的工具主要是CASE工具，在这个方面早就被国外的CASE开发商抢占先机，普遍为国人接受的是Rational 的ClearClass系列工具，另外CA公司也不是等闲之辈。唯一能让国人感到自豪的就是北大青鸟的JBCM-Web和JBCM。而针对CMM的评估工具，国内是一片空白。
目前国内有关CMM评估还是企业行为，并没有通过国家的统一管理和指导。同时，评估时对评估过程中数据的处理也是根据自己对《软件能力成熟度模型》的理解来进行的，没有使用针对《软件能力成熟度模型》的评估工具，在科学性，公平性以及公正性方面缺乏说服力，这对实施和推广CMM是极其危险的。
到目前为止，国内有关CMM的研究和实施仍然停留在面上，没有实质性的进展，这主要是和我国软件产业整个产业发展的水平相关，国人对此也无奈，因为对CMM来说，如果要达到它的要求，并非一朝一夕之功，需要结合自身的情况，严格按照CMM的框架结构，才有可能达到预期效果。
目前国内有的工具主要是CASE工具，在这个方面早就被国外的CASE开发商抢占先机，普遍为国人接受的是Rational 的ClearClass系列工具，另外CA公司也不是等闲之辈。唯一能让国人说上一两句的就是北大青鸟的JBCM-Web和JBCM。而针对CMM的评估工具，国内真是一片空白，有人想做，但是没有办法，因为不了解，这不能简单地说只是一个技术问题，它与整个行业发展的水平是密切相关的。对CMM的理解和认识是需要很深的文化背景和行业背景的。
CMM对企业来说，是软件企业过程改进和管理水平得到提高行之有效的方法，而不是企业应该造就的牌子，但目前国内却有很大的“牌子”误区，这与CMM的初衷是背道而驰的。如果要承认和使用CMM，就要遵循这样的规则：严格按照CMM对组织的软件过程改进的要求执行，否则你就别瞎搀乎。既然要把CMM作为医治软件企业过程 改进和管理上存在的弊病的良方，就得遵循适当原则，因为CMM这种药不能轻易吃，即不能多吃，否则会要命；也不能少吃，因为会让你对你的软件企业失去信心；更不能停药之后走回头路，除了耗费大量的人力、物力、财力以及时间以外，浑身上下不舒服的是你自己软件公司。
除此之外，我想还有一个我们都担心的问题是我们的政府会如何对待CMM在中国的发展，我们的政府会采用什么样的方式来扶持CMM在中国的发展，我们作为业界的从业人员，都担心这样的问题，因为ISO 9000兵败中国就是一个最好证明。国务院已经颁发了18号文件，以鼓励和支持中国软件产业的发展，一些地方政府也制定了相应的鼓励政策，今年全国十大软件园区的挂牌成立就是一个最好的例子，这真是上下齐心协力的好榜样，不过国人都好面子，都讲牌子，你通过CMM2，不行，对我的发展造成了很大的威胁，我要通过CMM3，至少也要通过CMM2，不管企业自身的水平是否达到了CMM的要求，都会来个短兵突击，对CMM的内容照抄照搬，所谓“上有政策，下有对策”，把CMM的评估要求再研究一翻，做好准备，把专家找来，而不管企业本身的运行如何，是通过了，但是只是拿到牌子，并没有对企业本身的软件过程改进起到作用，企业以前是如何运行的现在还是老样子。国外的统计数字表明：CMM每跨一级，至少需要两年的时间来改进，这告诫国人，不要一蹴而就，欲速则不达，害了的是自己。
所以，我们要小心，CMM是企业本身的事情，是对整个企业本身软件过程改进的指导，是软件企业练内功的功法，决不是质量保证体系，不能用来贴在商品上的，是不能作为商标用的。
另外，说到ISO 9000兵败中国，我们不能把这样的命运来对待CMM，我想我们的软件企业管理人员（无论是高级经理，还是项目经理），都对自己的企业充满信心，都对CMM抱很大的希望，在实施过程中都是小心的，都充分考虑了CMM的每一个级别的KPA(关键惯例)。还有，我们在实施ISO 9000的过程中，都是结合自己的国情，多数情况下都缺乏思考，这是因为掌握ISO 9000在中国的命运的人们，对ISO 9000的内涵了解不够透彻，是因为他们只做“政策”不做技术，不知道技术的内涵是什么，有些时候喜欢把它作为一种文字游戏来对待，但是技术不是文字游戏。除此之外，ISO 9000也有它的缺陷，综合起来主要是下述两个方面的原因造成的：
1、从ISO 9000自身角度来看，它包括了20个企业活动种类要素，虽然强调了质量持续改进的观点，但没有明确如何循序渐进地在企业建立与落实这些活动要素。
2、从企业自身来看，建立ISO 9000质量体系的动机不纯，很多都是把它作为一种通向市场的手段，质量规范走过场，上上下下一致对外，是保护了自己，但同时又害了自己。
CMM较之ISO 9000来说，进步主要表现在：
1、指出了进步管理的四个台阶；
2、指出在每个台阶上必须要完成哪些必要工作才能进行管理版本升级。
中国企业在骨子里就是反规范的，在实施CMM这样的过程改进手段时，会叶公好龙，哪一个细节上除了一点问题，就会群起而攻之，结果很多都是由于无法承受这样的压力而半途而废，真是可悲。
另外，我们都应该注意到，现在CMM在中国掉入了前面所述的陷阱中，国内有关CMM培训、咨询和管理的公司可谓是如雨后春笋般出现在北京、西安、广州和上海等地，大家都好像异口同声地说，我们都很有实力，都对自己冠以国内唯一这样的字样，其实明白人眼里是揉不进沙子的，CMM在中国经历了什么，除了一两张认证资格证书以外，并没有什么，大家都在鼓吹自己，其实都是心虚的表现，国内现在有关CMM咨询、培训的工程师，就单凭CMM中对CMM评估人员的背景要求，可以毫不客气地说，部分公司是没有评估人员的，而更多时候好像是一些江湖郎中，这对我们的软件企业真的会达到治病救人吗？
当然，出现这样的问题，是绝对不能将责任归咎于谁，只是想大家多应该冷静，把更多的时间和精力放在思考我们的软件企业的文化背景，以及由此而出现的软件企业文化。我们什么东西好像都喜欢说是中国特色，其实， CMM在中国实施的这个问题上，我们同样可以大胆地把CMM中国化，不过这样的大前提是必须了解我们的软件企业需要什么。
前面我们已经提到CMM和ISO 9000的区别，这个问题现在都认识到了，CMM更多地是企业行为，并不是用来规范市场的（不过现在信息产业部已经说明以后软件产品的出口必须通过CMM认证，这个时候更多地是政府行为），这就要求企业本身要把CMM对软件企业管理、开发等过程方面的要求落实到自己的企业管理和软件开发过程中。
我们在开发SPI评估工具的过程当中，综合考虑到了上述情况，将工具的功能限定在一定的范围之内，而不是只是单纯地将它的功能限定在评估职能上，下面，我们将会详细介绍SPI的功能：
1、 功能特点：
SPI评估工具是以《软件能力成熟度模型》，即以SJ/T 11234为核心，以《成熟度评估框架要求》为指导，参考《CMMI评估要求》，根据国内评估人员提出的需求，借鉴和学习国内外评估工具的优点，适合国内CMM评估的需要。
2、完全符合标准要求的评估流程:图1是工具的评估流程和《成熟度评估框架要求》的评估流程。从这个图中我们可以看到，评估工具的评估流程是完全符合《成熟度评估框架要求》中的评估要求和流程的，部分细节上的调整是更具评估的需要所做的改动。
3、 除了评估企业的CMM能力以外，工具本身的另外一个功能就是将《软件能力成熟度
模型》的内容简化，但是对《软件能力成熟度模型》的核心和灵魂部分是丝毫无损，企业管理人员、软件开发人员完全可以使用本工具来学习和研究CMM。
4、 便于培训和学习
l 有助于评估组长培训评估小组成员
l 在培训过程中，有助于评估人员掌握评估必要的知识和技能
l 有助于评估人员学习《软件能力成熟度模型》的内容
l 提供《软件能力成熟度模型》内容的参考
l 可以为软件企业的管理者以及CMM的实施者了解和掌握SPI的评估内容以及流程，同时便于实施CMM对软件开发过程进行改进。
图1 CMM评估流程图
(由于此论坛不能显示图片,只好作罢)
上述评估流程图是使用工具的评估流程图，下面将介绍《成熟度评估框架要求》中的评估流程图。
从这两个流程图的比较可以看出，使用“工具”的流程图和《成熟度评估框架 要求》中的流程图在逻辑上是一致的，除了部分细节内容不同以外，其它的都完全相同，因此，评估人员对于使用本“工具”进行评估，掌握它的评估流程是非常简单的事情。
对于这个评估工具，作者本人并不想作过多的介绍，我不想改变自己的初衷，因为我不是想借此机会鼓吹这个工具的好处，我只是说一些想说的话，同时，我相信我想说的是有依据的，并非是我自己一时兴起，对目前国内对于软件质量体系建设的不满，抱怨归抱怨，我们最关心的问题还是CMM在中国如何实施，达到改进我国软件企业中软件开发管理的种种弊病。因此，我是相信对CMM感兴趣，特别是关心CMM在中国发展命运的同僚们会接受我的说法的，希望我能开一个好头。
...全文
请发表友善的回复…
发表回复
