小型软件企业实施CMMI过程改进研究和分析
来源：csdn Thomas专栏
1．引言
在过去十年中，高质量软件生产变得越加复杂和难以管理，其中部分原因是生产软件的技术和方法快速变革，要开发的应用程序愈加复杂。这两个因素是密切相关：技术的快速发展促使新产品、服务和活动不断产生，不断替换旧产品，而此也对技术产生新的需求。其次，软件过程是面向人的，人之间，以及人与工具之间具有高度可变性和不可预测性。这个事实进一步增加软件过程的复杂性，对管理提出更高要求。最后，软件过程也许持续很长一段时间，在其生命周内也许会出现很多新需求，经历许多变更，这类变更涉及到开发技术改变、开发策略和规程更新。软件过程改进的其他重要原因包括动态调整软件过程以适应项目参与人的需求和偏好，或者处理不可以预测的情况。
现在业界最成熟的过程评估和改进方法是美国卡内基-梅隆大学的软件工程研究所（SEI）提出的过程能力成熟度模型。这些模型描述了有效的过程单元的框架，为组织描述了从混乱的、不成熟的过程向成熟的、有纪律的过程改进的一条途径。自从1991年SEI发布SW-CMM（V1.0）以来，SEI逐渐开发了多种CMM模型，其中最有影响的包括：系统工程（SE-CMM）、软件工程(SW-CMM)、软件采办(SA-CMM)、人力资源管理(P-CMM)，以及集成的化产品和过程开发(IPPD-CMM)等。虽然这些模型对许多组织是有用的，有助于改善组织过程，以构造更好的产品，提高质量，降低成本。但是多种模型的共存逐渐显露出弊端。
于是出现了能力成熟度模型集成（Capability Maturity Model Integration ，CMMI）。集成的目的是通过以下手段降低基于多学科模型的过程改进成本：消除不一致性；减少重复；增加透明度和可理解性；提供公共术语；提供一致的风格；建立统一的构造规则；维护公共构件；确保与ISO 15504保存一致；实现尽量好的可继承性。SEI计划逐步用CMMI取代现行的包括SW-CMM和SA-CMM在内的多个现行的成熟度模型 。
1．1 小型企业实施过程改进遇到的困难
实施CMM和ISO 9001的经验表明：在人员只有15人，甚至更少的小型软件企业中，应用这些模型时会遇到很多困难。即使对于大型软件企业来言，其中的小部门和小项目在单独应用这些模型时也会遇到这种问题，需要对这些模型进行调整，以适应小型企业、小部门和小项目（SB/SO/SP）的资源、结构和实践。SB/SO/SP环境下遇到的问题可以分成三大类：
（1）与软件企业组织结构相关的问题
小型软件组织的组织结构是实施过程改进的最大困难，通常这种企业没有正式定义角色、职责和过程。做法经常是每日都变化，没有长期计划，这种结构使得软件企业很难生成高质量大规模软件，或者及时满足不断变化的用户需求。总结如下：
[*]缺乏负责质量的专门人员。在小型企业中，通常没有人具备软件过程改进的经验和相关培训，即使知道基本概念和技术，但是对底层原理缺乏正确认识，无法解释本组织的质量模型需求。
[*] 人员有限。在小型软件企业中，难以形成专职的过程改进团队。
[*] 资金有限。小型软件企业通常资金有限，很容易受到市场的影响。
[*] 当前过程的状态。小型软件企业通常只处于CMM等级1的水平。经验表明等级1的公司需要花费4或者6年的水平才能达到CMM 3级的水平。对于大多数小型企业而言，这么长时间难以忍受。
[*] 非软件过程的问题。在小型软件企业中，对于那些与软件开发不直接相关的组织过程，通常缺乏所必需的成熟度。这个问题进一步加剧解决软件开发相关问题的难度。
[*] 黑客文化。小型软件企业通常具有黑客文化，严重依赖于少数高水平的程序员。
[*] 缺乏定量数据。小型软件企业通常没有收集数据以度量过程和执行情况，这与它们缺乏定义明确的过程和固有开发模式紧密相关。
（2）与软件过程改进模型相关的问题
诸如CMM和ISO 9001之类被广泛应用的软件过程改进模型有很多不适合小型软件企业的固有问题，总结如下：
[*] 缺乏指导。质量模型，尤其是ISO 9001，解释了应该具备的质量系统基本元素，但是没有提供何处启动和如何启动这些属性的指南。CMM稍强一点，定义了关键过程域，然而对于小型企业而言，没有那么多资源来实现这么多关键过程域，而且没有关于如何实施的详细指南。如果操作顺序不符合规范，则所有努力有可能付之东流。
[*] 缺乏行动知识。缺乏软件过程改进专门知识的小型软件企业需要如何在企业内部应用质量模型需求的详细步骤说明。
[*] 没有从小型企业角度考虑。已有的软件过程改进模型没有考虑到小型软件企业的特点，那就是灵活、快速反应和沟通能力。
[*] 假设具备多种领域的专门知识。当前过程改进模型隐含地假设软件组织具备形成能够在不同过程域中并行实施的资源，而小型企业没有那么多人力资源来组建这么多成员组。
（3）与小型企业所面对市场相关的问题
小型软件企业面对的市场有很多影响改进活动的特性。通常而言，小型软件企业与其顾客关系紧密沟通，容易受到市场经济的影响。与市场相关的问题总结如下：
[*] 应变能力假设。小型软件企业的软件的用户群较小（相对于庞大的软件企业），与客户关系很密切。这种密切关系有助于企业更加快捷了解用户需求，同时这也是一个问题。正如Brooks所说的那样，当用户的需求发生变化时，它们首先想到修改软件，而且认为软件修改起来更加容易。
[*] 低投资回报率。小型软件企业通常的市场用户比较少，如果组织不能显著的扩展其市场份额，则投资回报率也许会使公司上层丧失信心。
2．案例
由于多种CMM模型引起的混乱，以及在CMMI推出之后，SEI宣称在不久将来不再进行支持CMM，我们决定使用CMMI作为研究课题，研究如何在小型软件企业中剪裁CMMI，克服“小”带来的问题，以适应小型软件企业的改进需求。
本文研究对象是一家小型软件组织A1，有员工12人，其中10人从事软件开发，2人从事管理、市场和销售等其他事务。A1细分为两个部门：生产部门和研发部门。这个组织属于典型的CMM级别1的组织，没有明显的过程支持，靠的是精英，没有质量控制和度量数据。
我们从2002年10月开展对这家企业的过程改进，按照CMMI模型提出一套简单可行的实施过程和模型，给出简单可行的操作步骤，大大减轻了企业的过程改进压力，充分利用兼职和全职资源，并同时提供“小型软件企业过程改进支持环境（SSE-PISE）”过程改进支持软件来支持其过程改进。
3．相关研究
关于小型企业如何实施过程改进问题，已经引起美国和欧洲等国家等重视，并就此开展多项研究和试验。
中提出一个基于CMM、ISO 9001和ISO 9000-3的综合模型，该模型改造ISO 9001和CMM的需求以满足小型企业的需求，本模型包含三个阶段，分别是：准备阶段、控制阶段和稳定阶段。提出改造IDEAL模型的各个阶段和步骤，给出比较仔细的行动计划。尝试在小型软件企业中创建ISO 9001兼容的质量系统。介绍了European Commission支持的项目SPIRE( Software Process Improvement in Region of European)的进展情况，”SPIRE Handbook——Better ,Faster, Cheaper, Software Development in Small Organization” 使用SPICE自评估指南的结果，提供在小型软件企业中实施过程改进的详细指南。改进方法分为6个步骤，分别是：（1）细化与软件相关的商业目标；（2）评估当前软件实践；（3）评价员工态度；（4）开发过程改进的焦点计划；（5）基于既定改进目标来实施计划；（6）评价改进过程和结果。本改进方法的一个特点是专门对员工态度进行特殊评价。分析小型软件企业实施过程化改进时应该包含的8种SPI特性，分别是：与企业商业目标相关；集中于最重要的软件过程；充分利用资金；进行能够在尽可能短时间内提供尽可能大收效的改进；提供快速的投资回报；面向过程；与其他软件模型相关；足够灵活和易于使用。简单介绍LOGOS Tailored CMM的基本思想，以及简单实施指南，并给出剪裁过程，宣称本方法适合于所有规模的组织和项目，不是CMM的简单重写和改进。
4．剪裁过程和原则
CMMI剪裁过程的目的不是重新编写CMMI，而是根据小型软件企业的特点对其文档、实践、评审、资源、培训和管理等进行改造，同时保持CMMI的精粹和结构。由于各个软件企业的具体改进方向不同，采用的改进策略不同，使用的模型不同（连续式或者阶段式），本文不逐个解释如何剪裁KPA，这样做不容易抓住主题，而且容易陷入细节中，我们讨论剪裁文档、管理、评审、资源、培训等的普遍做法和原则。
4．1 文档剪裁
CMMI过程模型包含大量文档，包括策略、计划、规程、标准和报告等，如果严格按照CMMI实践来做，小型软件企业的有限资源会被文档所淹没，而丧失对改进本质的掌握。我们采用的策略是合并或者扩充文档，减少生成文档的负担，并借助于“小型软件企业过程改进支持环境（SSE-PISE）”来实现文档的快速生成、分发、合并和管理。主要剪裁策略包括：
[*] 文档合并。 文档合并是符合CMMI主旨的，CMMI也定义非形式化计划作为形式化计划的一部分。我们可以扩展之，项目级文档可以是其他项目级文档的一部分，组织级文档可以是其他组织级文档的一部分，前提是保证文档的可识别性。
可以充分利用信息系统的访问控制机制，实现文档的更大程度合并，比如每个项目的项目级文档只有一个，比如项目计划，对于不同角色，只能看到相应的信息段，进行自己权限范围内的输入、修改、阅读、转发等操作。
对于相关性较强的文档，尤其是某文档是其他文档的简化版本，则完全取消前一个文档，或者借助于信息化系统来实现自动生成。
[*] 文档消除。 对于没有涉及到的文档，则完全删除，不必提供，但是要在项目级文档中解释所采取的措施。对于信息冗余的文档，则完全删除；对于有价值信息量很少的文档，则删除本文档，然后把有价值信息量合并到相关度最强的文档中。
[*] 数据项抽取。 对于不同文档中的公共信息，利用信息系统从公共数据源抽取，保证数据的正确性、一致性，同时减少重新输入的工作量。
在本文讨论的案例中，我们充分利用Lotus R5的多媒体文档有关机制，组织级文档只保留一个；每个项目只保留一个项目级文档。对于配置管理（SCM）等KPA，基本上也限制在每个项目一个配置计划文档。当然，这个系统提供有关机制，能够保证可以从同一个文档衍生、打印输出多个子文档，分作不同场合使用。
4．2 管理剪裁
CMMI中任务分工非常细，涉及到的角色也非常多，但是对于小型软件企业来说，根本没有那么多人力资源来分工承担这么多管理任务。比如CMMI中的高级经理在小型软件企业中很可能就是公司总经理或者CEO，但是很多细节性任务他又不可能，也没有时间自己来做。而且，在小型组织和小型项目中，很多角色实际上是重复的，比如在小型项目中，任务领导、软件经理、项目软件经理，以及项目经理的角色时重复的，没有必要单独设置。鉴于CMMI的管理结构与小型软件企业存在较大差距，有必要对管理活动和管理角色进行剪裁。主要剪裁原则如下：
[*] 剖析KPA和管理任务，把相关的，不必要保证独立性的KPA综合起来，把相关管理职责分配给单个经理进行管理。
[*] 除非在绝对需要高级经理承诺的情况下，一般不设置高级经理这个管理职位。
[*] 合并管理任务，没有必要重复设置经理职位，可以把相关职责交给有关技术人员或者管理人员来实施。
在本文讨论的案例中，我们把KPA进行分类，保证“过程和产品质量管理”过程域的独立性，其他KPA进行实施时都实施一人承担多个职责，并把权利和职责合并和下放，每个项目只设立一个项目经理和一个SQA经理，项目经理负责项目的计划、实施、部署和维护。KPA经理负责对项目实施进行监控，安排评审、获取度量和分析数据，以及提出改进建议。
4．3评审剪裁
CMMI实践中涉及很多类型的评审活动——管理评审、同行评审、SQA审计/验证/评审、正式评审，以及技术评审，几乎对所有项目相关的关键决策和关键文档和活动都需要进行相应的评审，以建立公共基线。对于小型项目和企业而言，如果按照CMMI模型所有评审活动都实施的话，评审所花费的时间会严重影响开发时间，因此很有必要对评审活动进行剪裁。主要剪裁原则如下：
[*]适当合并评审实践。按照CMMI模型，高级管理层需要参与的评审太多，但是经理和具体实施者经常是在一个办公室工作，沟通非常方便，很多评审活动可以简化和合并，甚至取消。
实践证明，评审频率与项目是否关键，以及项目持续时间，关系非常密切。比如在非关键的和短期项目中，评审频率应该不影响项目生命周期，相应的管理评审、软件风险评审，以及SQA活动评审的频率应该降低。
[*]把评审实践非正式化。充分利用其他会议或者碰头机会解决评审需求。
[*] SQA评价、审计和评审没有必要对所以产品都及时进行，应该只进行抽查。SQA评审被证明会严重增加小型项目的工作量。应该在SQA计划中明确SQA抽查活动和工作产品。举例说明可以抽查进行评审的活动或者工作产品：
（1）对KPA中活动和工作产品的SQA评审和审计；
（2）关于软件基线的SCM审计；
（3）子承包商的SQA计划和活动的评审；
（4）子承包商执行情况的评价。
大型项目和小型项目的一个主要区别是在状态报告方面经理和员工之间工作关系不同。在小型项目中经理通常把主要精力放在技术层面上，因此在小型项目中实施大规模的状态报告机制是不必要和不合适的。为了解决这个问题，需要剪裁和合并很多CMMI评审实践，尤其与高层项目管理层和SQA联合进行的项目跟踪评审。在本文讨论的案例中，我们只对关键工作产品和里程碑进行正式评审，其余评审进行合并，或者进行抽查评审，或者非正式化，降低评审工作量，充分利用小型项目的沟通便利、合作紧密的优势。
4．4资源剪裁
CMMI模型规定很多执行管理和工程任务的角色，但是在小型组织和小型项目中根本没有那么多人能够全职执行CMMI要求的角色。实际情况是，工程师和管理人员可能同时执行多个角色，甚至跨越多个项目。比如，项目经理也许管理多个项目，也许同时从事管理和技术工作。SQA人员也许来自于其他项目，或者来自于其他组织和公司，SQA和SCM人员也许同时负责多个项目，并且个人也许参与到多个工程科目。同时，对于小项目而言，实现诸如SQA、SCM、培训和SEPG的人员全职化也是不现实的。通常是，这样的团队经常包括多个兼职人员，以及一个全职人员。
在小型项目中，人员不是唯一受限的资源，每个KPA中“执行能力”部分提到的工具资源通常指的是自动化工具。在小型项目或者小型组织中，很多自动化工具不仅昂贵，而且不适合。对于不成熟的软件过程，通常不能有效地使用大型CASE自动化工具。为了解决小型软件组织和小型项目中有限资源问题，我们需要对CMMI进行剪裁，主要剪裁策略如下：
[*]个人可以执行项目或者组织中的多个角色；承认兼职角色和职责；可以利用组织之外的资源。
[*] 扩展组（group）的概念，，使之可以包含兼职人员。
[*] 根据项目和过程成熟度需要选择合适的自动化工具。在小型项目中，应该综合使用基本的自动化工具和人力。
在本文讨论的案例中，要求对资源进行分类，不仅按照人力资源、自动化工具等进行分类，而且进行进一步细化，比如人力资源根据专业方向、领导才能、沟通能力等进行分类，提出一个简单的分类和评估方法；对CMMI的资源和组概念扩展，不再局限于部门的概念，使之能够容纳各种全职和兼职人员，而且没有规模和其中职位的限制。基于不同成熟度的项目或者组织，对不同KPA提出不同的建议工具，尤其是“小型软件企业过程改进支持环境（SSE-PISE）”能够对这些工具提供接口，促进自动化工具的使用效率。
4．5培训剪裁
CMMI模型KPA的“执行能力”公共特性包含很多不同类型的培训需求，包括管理和技术方面的。由于培训是非常耗费资源和资金的事情，小型组织通常雇用已经被培训或者具备相关知识的人才。CMMI的培训程序KPA允许放弃培训，但是大多数企业没有认识到这个问题，仍旧坚持认为对所有员工进行培训是必不可少的。必须对CMMI进行剪裁以澄清这种误解。主要剪裁原则如下：
[*] 已经具备相应实践经验或者类似领域培训历史的员工可以免除培训。
[*] 培训可以当作以前培训的扩展，并且可以合并相关活动的培训。
[*] 可以扩展培训实践，消除不必要的内部培训，接收来自于外部资源或者方法的培训。
在我们讨论的案例中，我们对相关培训记录和人力资源培训技能和培训历史非常重视，并基于此来决定是否使用培训免除机制。如果使用这种机制，必须保证有当事人的签名。我们剪裁多个培训实践以合并或者扩充培训需求。比如，同行评审领导者培训可以与同行评审者培训合并。有些高等级成熟度KPA的活动是低等级成熟度活动的扩展，因此支持高等级成熟度活动的培训是支持低等级成熟度活动的培训的扩展，比如集成化软件管理KPA的项目管理培训。
4．6剪裁无关实践
CMMI是面向于大型软件企业的，其中很多实践是与小型企业不相关的，尤其很多过程实践不适合于小型项目，小型项目实施这些过程实践会花费比项目本身更多成本，并且由于部分项目的短时效性使得重新计划或者调整活动变得没有实际意义。
在组织过程焦点、组织过程定义、集成化软件管理，以及定量过程管理等KPA中，很多过程实践涉及到创建和维护项目已定义过程。但是在只有一个项目的组织中，项目过程和组织过程是完全相同的。如果组织的项目具备类似的特性（比如领域知识、规模和开发循环等），则所有小项目可能使用一个过程。并且这个过程是小型项目的组织标准过程。无论何种情况，那些剪裁组织标准软件过程作为项目已定义过程，以及集成项目已定义过程的变更到组织标准过程的实践都不适合。同时，对于那些开发时间很短的项目，则根本没有时间来实施项目重新计划、风险计划，以及过程调整等活动，那么这些实践对于这种项目来说也是没有用处的。
5．总结
中国的软件企业80%都是小型企业，人员规模在15人以下，而CMMI是面向于大型软件企业的过程改进模型，怎样使得小型企业和项目能够充分利用CMMI模型的过程改进优势，并获得相关CMMI认证呢？作者参与一个只有12名员工的小型企业软件过程改进项目，本文正是基于该项目总结而得的。
本文首先从企业组织结构、软件过程改进模型、小型组织面对的市场需求等三个方面剖析小型软件企业的过程改进面临与大型企业不同的需求。然后分析为什么CMMI的有关内容不适合于小型企业和项目的实际情况，并概括介绍如何在文档、管理、评审、资源和培训等方面进行剪裁和改进，使之适合于小型企业和项目的实际情况。
苏州思特瑞信息技术有限公司 专业CMMI ISO27001 ISO20000服务提供商
联系人：叶莉
电话：13584882490 0512-62653189
邮箱：lily@szstr.com
地址：苏州工业园区仁爱路258号C207
支持下楼主 这个广告做得不错啊 wxsunhao 发表于 2012-2-28 07:37 static/image/common/back.gif
支持下楼主
O(∩_∩)O谢谢啦大大的好人 jimlaw 发表于 2012-2-28 08:08 static/image/common/back.gif
这个广告做得不错啊
没办法 工作压力大啊！多多理解 O(∩_∩)O谢谢 wxsunhao 发表于 2012-2-28 07:37 static/image/common/back.gif
支持下楼主
O(∩_∩)O谢谢啦大大的好人:) 1、很好的文章。但有以下拙见，仅供供参考。
2、按照GB/T16680-1996《信息技术软件文档管理指南》的说法：“软件生存期的所有阶段都要求编制文档。因此，文档编制和维护是必需的并且从软件的概念阶段连续作用到它废止文档编制开始于软件项目的初始阶段并贯穿于软件的设计开发、测试、安装、使用、修改和增强。仅当软件走到它的生命终点时才认为文档编制过程结束。文档编制是任何软件开发项目成功的基础。”GB/T 8567-2006《 计算机软件文档编制指南》有说：“这些文件连同计算机程序及数据一起，构成为计算机软件。”显然，计算机软件文档的合并和删减应有个底线，就是“必须适应计算机软件整个生存周期的需要”，删减后的所有文档是否能表现出被删减文档的软件产品的所有技术特性（功能、性能）。如这个底线都不能保证，无论是小型企业还是大型企业，合并和删减的结果都是不可以放行的。
3、针对产品的评审活动可能有交叉，有重叠，可以适当“合并”。但针对软件的“功能、分配、产品”基线的评审和每次因评审、（单元、组装、集成和系统）测试、试运行后和产品释放后用户反馈信息引发的软件的重大设计变更的风险评审，还是不要“裁剪”的好！这些评审是确保软件开发“生命活动周期”满足要求的重要控制方法。且保持每次评审结果和引发措施的记录以利于后来跟踪验证也是非常必要的。文章中并未谈及。
4、无关实践是可以“剪裁”的。但相关的实践活动是必须保持的。规模再小的软件开发前期到客户现场与客户沟通等“实践活动”以作出充分的软件《需求分析》都是不可“删减”的。否则您的软件开发成果将难以满足客户需求和需求的变化。已没有时间来实施项目而“剪裁”掉软件《设计开发计划》、《风险分析评估计划》不应该是一个充分的理由。一个无计划的开发项目和对风险未作基本评估并提出规避的项目，规模再小也是有风险的。只有按计划开发的过程才具有可“调整”的空间。
5、关于“培训剪裁”。同意“已经具备相应实践经验或者类似领域培训历史的员工可以免除培训”。但据我的经验。中国软件行业中的软件开发的高手们，大多未经过CMM软件成熟等级、质量管理意识和ISO9000管理体系理论和应用的培训。他们可能是程序员、高级程序员；系统分析员或高级系统分析员。但对规范化的，先进有效的管理方法和管理模式确极不熟悉！有很多优秀的开发者还停留在个人或作坊式开发模式，不具有团队开发理念，不注重软件开发风险分析与评估，开发的阶段控制方法和对软件缺陷处置带有随意性。导致所开发软件的成熟度低、稳定性不够，生命周期过短，缺乏竞争力。这些正是小型软件企业发展的瓶颈和致命伤！如果强调开发人员资源不足，时间不够而放弃对他们的培训，产品的质量是无法确保的！我审核过无数个小型软件企业。员工的参与意思最欠缺的就是开发软件人员，管理意思最差的也是开发人员。不管是推行CMM或ISO9000,最不给力，最不配合的也是开发人员。他们往往苦瓜着脸，十二万分的不乐意参加这样的活动。理由就是“忙”，“没时间”！但这是一种恶性循环！
6、结论：不管是推行CMM还是ISO9000，裁剪要适当。按ISO9000标准的说法：裁剪后不能影响组织满足顾客和法规要求的能力和责任！否则，不能声称已符合要求！搞不好可能误导小型软件企业引入ISO9000. CMM12人企业也就够2级吧？能做3级吗？ 目前，连cmm
都有全包干的咨询机构了。啥不敢做。
yuanye318 发表于 2012-4-22 23:10 static/image/common/back.gif
目前，连cmm
都有全包干的咨询机构了。啥不敢做。
我们公司是好好做的哦，专业咨询老师全程辅导印度评估师评估 eicbj 发表于 2012-4-20 20:16 static/image/common/back.gif
CMM12人企业也就够2级吧？能做3级吗？
2个人的企业不好做的不建议做CMMI CMM2没有必要做呀，没有用！
L3是底线了。
印度评估师评估用中文还是英文？
国内好像也有几十个主任评估师。
留个联系方式，我们可能有机会合作。
【yuanye老师的评论很给力】
1、很好的文章。但有以下拙见，仅供供参考。
' w- G& N4 wt4 w; _1 p2、按照GB/T16680-1996《信息技术软件文档管理指南》的说法：“软件生存期的所有阶段都要求编制文档。因此，文档编制和维护是必需的并且从软件的概念阶段连续作用到它废止文档编制开始于软件项目的初始阶段并贯穿于软件的设计开发、测试、安装、使用、修改和增强。仅当软件走到它的生命终点时才认为文档编制过程结束。文档编制是任何软件开发项目成功的基础。”GB/T 8567-2006《 计算机软件文档编制指南》有说：“这些文件连同计算机程序及数据一起，构成为计算机软件。”显然，计算机软件文档的合并和删减应有个底线，就是“必须适应计算机软件整个生存周期的需要”，删减后的所有文档是否能表现出被删减文档的软件产品的所有技术特性（功能、性能）。如这个底线都不能保证，无论是小型企业还是大型企业，合并和删减的结果都是不可以放行的。9 l! D" h4 I- `: E! ]- y
3、针对产品的评审活动可能有交叉，有重叠，可以适当“合并”。但针对软件的“功能、分配、产品”基线的评审和每次因评审、（单元、组装、集成和系统）测试、试运行后和产品释放后用户反馈信息引发的软件的重大设计变更的风险评审，还是不要“裁剪”的好！这些评审是确保软件开发“生命活动周期”满足要求的重要控制方法。且保持每次评审结果和引发措施的记录以利于后来跟踪验证也是非常必要的。文章中并未谈及。5 M% a( U# N6 x
4、无关实践是可以“剪裁”的。但相关的实践活动是必须保持的。规模再小的软件开发前期到客户现场与客户沟通等“实践活动”以作出充分的软件《需求分析》都是不可“删减”的。否则您的软件开发成果将难以满足客户需求和需求的变化。已没有时间来实施项目而“剪裁”掉软件《设计开发计划》、《风险分析评估计划》不应该是一个充分的理由。一个无计划的开发项目和对风险未作基本评估并提出规避的项目，规模再小也是有风险的。只有按计划开发的过程才具有可“调整”的空间。
$ z8 K! l0 C9 ?0 ~$ N5、关于“培训剪裁”。同意“已经具备相应实践经验或者类似领域培训历史的员工可以免除培训”。但据我的经验。中国软件行业中的软件开发的高手们，大多未经过CMM软件成熟等级、质量管理意识和ISO9000管理体系理论和应用的培训。他们可能是程序员、高级程序员；系统分析员或高级系统分析员。但对规范化的，先进有效的管理方法和管理模式确极不熟悉！有很多优秀的开发者还停留在个人或作坊式开发模式，不具有团队开发理念，不注重软件开发风险分析与评估，开发的阶段控制方法和对软件缺陷处置带有随意性。导致所开发软件的成熟度低、稳定性不够，生命周期过短，缺乏竞争力。这些正是小型软件企业发展的瓶颈和致命伤！如果强调开发人员资源不足，时间不够而放弃对他们的培训，产品的质量是无法确保的！我审核过无数个小型软件企业。员工的参与意思最欠缺的就是开发软件人员，管理意思最差的也是开发人员。不管是推行CMM或ISO9000,最不给力，最不配合的也是开发人员。他们往往苦瓜着脸，十二万分的不乐意参加这样的活动。理由就是“忙”，“没时间”！但这是一种恶性循环！
# b4 m, B) T$ _+ L' c& u9 l) W6 A6、结论：不管是推行CMM还是ISO9000，裁剪要适当。按ISO9000标准的说法：裁剪后不能影响组织满足顾客和法规要求的能力和责任！否则，不能声称已符合要求！搞不好可能误导小型软件企业引入ISO9000. eicbj 发表于 2012-4-27 09:28 static/image/common/back.gif
CMM2没有必要做呀，没有用！
L3是底线了。
印度评估师评估用中文还是英文？
对呀 现在一般都从三级开始做起的 印度评估师全程英文但是我们有专业的翻译人员
苏州思特瑞信息技术有限公司
姓名：叶小姐
电话：0512-62653189
手机：13584882490
Q Q：997407315
邮箱：lily@szstr.com
页:
[1]