《企业组织设计小型组织推行CMM》由会员分享，可在线阅读，更多相关《企业组织设计小型组织推行CMM（10页珍藏版）》请在金锄头文库上搜索。
1、如何在小型组织中推行CMMCMM SM是适用于小工程项目和小规模组织的经剪裁的CMM版本。而CMM V1.1是用适宜于那些和政府签约的大型组织的标准实践来表达的，这些实践必须剪裁才能适合不同于这个样板的组织的需要。摘要 有关在小工程或小组织中应用CMM的一些常见问题包括： 什幺样的才算做“小”？标准是根据人？时间？项目大小？还是产品的艰难复杂程度？ 什幺是CMM的“需求”？是否有不该被应用到小项目/小组织中去的关键过程区域或目标？有好的过程“ 不变量”吗？ 造成CMM被滥用的驱动力和动机是什幺？这篇论文以小型组织为例讨论了怎样在各种商业环境中正确而有效地使用CMM。作者简介 Mark是美国软件
2、工程学会（SEI）的一名技术人员。他1987年加入SEI ,最初参与的是软件能力评价项目的工作。Mark从一开始就工作在软件能力成熟度模型方面，并且是开发CMM1.1版本时的项目领导人。他也一直活跃在制定有关软件工程的标准上, 这些标准包括： ISO 15504 ( 也称为SPICE-软件过程改进和能力决断),一整套软件过程评估的国际标准 ISO 12207 , 软件生存周期过程 ISO 15288 , 系统生存周期过程在加入SEI之前，Mark是系统开发公司（System Development Corporation，即优利国防系统公司Unisys Defense Systems的前身）的
3、位于亚拉巴马州Huntsville的弹道导弹防护高级研究中心（Ballistic Missile Defense Advanced Research Center）的一名高级系统分析员。Mark在范德比尔特大学获得了他的计算机科学硕士学位。在Huntsville的亚拉巴马州立大学获得了他的数学和计算机科学学士学位。专业资格及证明 电子学会高级研究员及电子工程师 (IEEE，美国电气及电子工程师学会） 美国质量协会高级研究员 (ASQ，美国质量协会) 美国质量协会（ASQ）认证软件质量工程师 提供了路标。CMM定义了怎样使开发组织的软件过程走向成熟的5个等级的框架结构。这些等级描述了从特别紊乱的
4、混沌过程到成熟的、有纪律的软件过程的进化路径。CMM在称心如意地实施管理及工程实践方面，都提供了良好的建议，它强调以人为核心的管理、沟通和协调以及能体现软件开发和维护特性的强化设计的过程。无论如何，把它看成灵活的指南而非生硬的指令吧，还有对于软件工程和管理，以及应用领域和组织的商业环境等方面，CMM用户必须能够在这些方面应用其基于知识和经验的专业判断。因为CMM聚焦于软件，所以TQM的一些重要方面不能直接照搬到模型里，比如系统工程里的“人的问题（people issues）”和“较宽泛的审视（broader perspective）”，这些在商业上可能是至关重要的。CMM应该被看成使用在软件过
5、程改进系统步骤里的一种上下文工具，比如SEI的IDEAL模型，如图2所示McFeeley96。/ / TQC abbr. 全面质量管理 (total quality control)在对软件过程改进的讨论中，开始的问题总应该是这样的：为什幺软件组织会对使用CMM感兴趣？如其愿望是以直接依从商业目标以及心甘情愿投身改革而来改进过程，那幺CMM确实是效用非凡、功能强大的工具；如果CMM只被当成单纯的短期时髦，那可真是把一剂糟糕的药方拿到了手。如果驱动力是客户利益，理想情况下客户利益将导致客户和供应商之间协作的改进。有时供应商的利益集中在软件能力评价(Software Capability Eval
6、uations，SCEs)上, 如此则可在那些来源选择及签约监督方面是由政府获取代理的项目上有所表现。国防部在执行软件能力评价(SCEs)标准的政策上是排斥绝大多数小组织和小项目的Barbour96，但也存在它们可以有所作为的机遇。很多CMM的滥用都对“其它人”可以做什幺的担心置于不顾。如若一个开发组织能在用CMM来导引胜过被需求来牵引上达成共识，那幺在模型中要解决问题的很大一部分就化解掉了。有很多这样的案例。尽管如此，那些对于好的工程和管理实践的无知仍将成为问题。对于那些只有很少的管理方面的经验和训练而只是因技术优秀就被提拔到管理层职位的人来讲，问题是显而易见的。由DOD（美国国防部）特种部
7、队确认并提出的问题是DOD87： “少数区域在最佳当前实践和平均当前实践之间有着如此巨大的缺口。” “大问题不在技术方面现今军事软件开发的主要问题不再是技术问题，而是管理问题。”2. 小组织和小项目 本篇论文的焦点对准了在小组织正确而有效地使用CMM，因为经常有人问我，“CMM是否能被用在小项目(或小组织)？”然而有关“小”的定义却是模糊难解的，如表1所示。 在某段时间里我们致力于为小项目和小组织而开发出剪裁适当的CMM，1995年CMM剪裁工作室的结论是我们甚至不能对什幺才算“小”的真正含义达成一致意见！这个结果得出了一篇更注重于“如何剪裁CMM”而不是“已为小组织而裁好的CMM”的报告Gi
8、nsberg95。1998年SEPG会议关注于CMM及小组织上，“小”被定义成“5个或更少的人为期3至4个月的开发”。Brodman和Johnson则定义“小组织”为少于50个软件开发人员并且“小项目”为少于20个开发人员Johnson98。表1. 定义一个小项目小的变体 人数 总的时间小 3-5 6个月 很小 2-3 4个月微小 1-2 2个月个人 1 1星期荒唐！ 1 1小时注意从小到微小的项目是在被Humphrey称为小组软件过程（Team Software Process，TSP）的范围里，而个人的开发努力则在个人软件过程（Personal Software Process，PSP）的
9、范围里Humphrey95。TSP和PSP阐明了CMM的概念是如何应用到小项目中的。“荒唐”变体则描述了一个解释性的问题。在两种场合里，变体都会被论述，问题是“项目”的定义。两种情况下它都是个维护环境，而且组织的“项目”将被描述为CMM的任务；更多关于CMM“项目”的精确解释是一个基线的升级或者维护的发行但术语的冲突会将其搞乱。对于那些使用CMM的小组织来说，首要的挑战就是其主要商业目标要能存活下来！甚至在决定之后，现状是不能令人满意的而且过程改进也将有助于发现资源并为过程改进分派职责,接下来通过制定与部署过程所要做的是一项艰难的商务决定。小组织往往相信： 我们全都是胜任的人们是被雇佣来做工作
10、的，我们可不想负担那些要在雇佣期间进行培训所花的任何时间或金钱。 我们全都彼此沟通因我们是如此紧密地在“渗透式”工作。 我们全都是英雄好汉我们无论做任何需要做的事情，规则都不适用于我们（这些恰恰达成了将工作完成的方式），我们承受住了短周期及高压力。然而对于小组织，也正象大组织一样，有着非文档化的需求所带来的麻烦，以及无经验的经理人员、资源分配、培训、同行评审和产品文档等方面带来的问题。尽管有着这些挑战，小组织仍能非同寻常地进行创新和提高生产率。尽管有一大把需要人们去解决的大块问题，通常小组织比大组织更具生产效率，他们能更敏锐地成形生产要素并且远远更少见有沟通方面的问题。无论如何，遗留下来的问题
11、是，小组织也需要过程纪律吗？回答这些CMM咒语,我们需要考虑到纪律包括了什幺? 而那将引入这篇有关CMM指导性课题论文的核心。即便如此，评估小组织时运用最新式的评估过程是明智可取的。为期两周的CMM内部过程改进基础评估(CMM IPI)的形式也许是多余的Strigel95, Paquin98, Williams98，甚至会由于缺乏监控而导致某些遗漏，而关键是有效地确认重大问题。我建议将注意力集中在建立在企业文化上的制度化实践方面：如规划、培训等等，并确切地将过程改进落实到商业需要上。3. 解释CMM CMM都适用在什幺地方呢？CMM是按照在任何环境中为任何项目都能提供良好的软件工程和管理实践来
12、塑造的。模型是被分层次描述的：成熟度等级 (5)-关键过程区域 (18)-目标 （52）-关键实践 （316）-子实践和例子 (许多)根据我最近十年来在软件过程工作方面的经验，阐述的环境以及CMM的剪裁需要包括： 非常大的程序 虚拟项目或组织 地点上分布式的项目 快速原型法的项目 研究及开发组织 软件服务组织 小项目和小组织对于小项目和小组织的解释性指导也同样适用于大项目和大组织。在正确有效地使用CMM的过程中，智能和常识是必要的Paulk96。所有（软件）项目都有所不同，但所有（软件）项目也都有所相同这可全都是真的。我们必须平衡现实：相似与唯一，秩序与混乱。那些成功所缔造出的持久组织Coll
13、ins94是真正有能力的学习型组织Senge90；此外在其它地方也必须得益于其成功。CMM的标准构件是成熟度等级、关键过程区域和目标。CMM的所有实践都是有益处的。既然那些详细的实践都首先支持大型签约的软件组织，也就没必要正好写成是直接适用于小项目和小组织然而它们同样提供了如何达到目标和可重复地实现已定义的、规范的、不断改进的软件过程。这样就会避免了过程评估方式上的简单武断诸如“去问老张吧”。我最通常的指导性建议是开发出一套适用于组织的置于CMM术语和语言间的映像。特别地,组织结构的期限行为、角色、关系以及过程的形式都需要映像到其组织的相应部分，以防止出现无法理喻的事情，诸如“荒诞的一小时项目
14、”。组织结构的例子包括诸如质量保证、测试及配置管理等“独立小组”。应该用术语明确地指定适当的组织角色，诸如项目经理及项目软件经理等。人们可以担当多重角色，例如，一个人可以同时做项目经理、项目软件经理、软件配置管理（SCM）经理等等。明确规划好这些，将生发出对CMM更生动简洁也更协调一致的阐明。一旦术语问题被理解了，我们就得考虑什幺是守纪律过程的“不变量”|here|（invariant，一个必须永远为真的约束）以及哪些实践依赖于上下文关系。除了软件转包合同管理（即若无转包合同的话就可能成为“不可用的”），一般来说我们总是假定关键过程区域及目标关联到任何环境。我想象不出同行评审被等级3的组织适当
15、剪裁掉的情形。尽管所选择出的实践（诸如正式方法）可以替代同行评审，但这还是一个需要足够专业性判断的问题。拥有专业性的判断和训练、经验丰富的评估人员是至关重要的，甚至对小组织也一样！Abbott97我从没见过下列哪个环节是不必要的(尽管实现方式不同)： 将客户(系统)的需求记录成文档 与客户(并且最终用户)沟通 同意承诺并签约 计划 文档化过程 工作细化结构当然，一些实践都被处理成了“大项目的实现”。小的项目未必需要软件配置管理组或者变更控制部门，然而配置管理及变更控制总还是要有的。一个独立的软件质量保证(SQA)组也许不是必要的，但目标的认可始终是需求要被满足。一个独立的测试组也许没必要设立，但测试总是必要的。即使小组织和大组织之间的实现有着根本的不同，但我们看到对于上下文相关的实践，其意旨是建设性的。如果有人读到CMM所定义的“组”，它是被陈述为“一个组可以是被分派兼职的单独个人、从不同部门分派了几个兼职的个人，也可以是全职的几个个人”，这里就有意迎合了环境的变化。除了这些, 一些特殊的问题再三地出现, 尤其是对于小组织，涉及有： 管理资助 度量 软件工程过程组(SEPGs，Software
