CMM-CMMI认证前的准备工作.doc

CMM-CMMI认证前的准备工作.doc

《CMM-CMMI认证前的准备工作.doc》由会员分享，可在线阅读，更多相关《CMM-CMMI认证前的准备工作.doc（12页珍藏版）》请在冰豆网上搜索。

CMMI评估

    CMMI评估不是第三方的认证工作（如ISO9001认证等）。

CMMI评估是组织自己评价自己在实施内部过程改进后的绩效（PERFORMANCE）。

聘请SEI授权的评估师作为评估小组的组长只是为了确保评估的结果更加专业、更加准确以及更具权威性。

   SEI明确规定了CMMI评估方法，全称是：

StandardCMMIAppraisalMethodforProcessImprovement，简称SCAMPI。

   主要CMMI评估流程如右图所示。

   CMMI评估工作是企业迈向自我改进和自我完善的起点，也是获取客户及公众信任的展示。

因此必须以科学、公正和规范的方式开展，坚决克服一些短期行为，尽量消除各种负面因素的影响。

   如需我公司提供CMM/CMMI评估服务，请下载相关信息表认真填写，然后传真或E_Mail到我公司。

我公司将指定项目经理进一步与您联系和沟通，并提供相关服务。

               表格下载

分析评估的要求

 （AnalyzeRequirements） 

编制评估计划

 （DevelopAppraisalPlan） 

选择和组成评估小组

（SelectandPrepareTeam）

获取和分析初始客观证据

（ObtainandAnalyzeInitialObjectiveEvidence）

筹备客观证据的收集

  （PrepareforCollectionofObjectiveEvidence）

检验客观证据

（ExamineObjectiveEvidence）

 验证和确认客观证据

 （VerifyandValidateObjectEvidence）

记录客观证据

（DocumentObjectiveEvidence） 

产生评估结论

 （GenerateAppraisalResults）

 宣布评估结论

（DeliverAppraisalResults） 

整理和存档于评估库

     （PackageandArchiveAppraisalAssets）

CMM/CMMI认证前的准备工作：

    1．什么是CMM/CMMI？

    2．目前在我们软件开发工作中的哪些典型问题可以通过推行CMM/CMMI2的工作加以解决？

    3．如何看待推行CMM/CMMI对我们目前工作带来的冲击？

    4．推行CMM/CMMI到底在哪些方面能够给我们带来好处？

    5．综合描述国内企业在推行CMM/CMMI出现的典型问题及不良结果？

    6．我们企业需要推行CMM/CMMI吗？

    7．向谁申请CMM/CMMI评估？

    8．申请CMM/CMMI的认证费用有多大？

    9．如何确定合理的CMM/CMMI咨询费用？

    10．我们企业对CMM/CMMI咨询机构都可以提出哪些工作要求？

    11．我们企业在推行CMM/CMMI时是否一定要100%按CMM/CMMI条款执行？

    12．什么是推行CMM/CMMI工作中的平衡观念？

    13．我们企业可否跨越CMM/CMMI2级直接应用CMM/CMMI3级？

    14．推行CMM/CMMI工作中文化建设内容有哪些？

    15．如果我们要开展咨询工作一定要请国外机构吗？

    16．我们从什么地方可以查到SEI授权的主评员？

CMM/CMMI认证前的准备工作：

1．什么是CMM/CMMI？

　软件能力成熟度模型（CapabilityMaturityModelForSoftware,简称SW-CMM/CMMI）,是由美国卡内基梅隆大学软件工程研究所（CMUSEI）研究出的一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。

其所依据的想法是：

只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。

CMM/CMMI是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了国际软件产业界的认可，成为当今（企业）从事规模软件生产不可缺少的一项内容。

     CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：

（1）初始级（initial）。

工作无序，项目进行过程中常放弃当初的计划。

管理无章法，缺乏健全的管理制度。

开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

（2）可重复级（Repeatable）。

管理制度化，建立了基本的管理制度和规程，管理工作有章可循。

初步实现标准化，开发工作比较好地按标准实施。

变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。

   （3）已定义级（Defined）。

开发过程，包括技术工作和管理工作，均已实现标准化、文档化。

建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解。

   （4）已管理级（Managed）。

产品和过程已建立了定量的质量目标。

开发活动中的生产率和质量是可量度的。

已建立过程数据库。

已实现项目产品和过程的控制。

可预测过程和产品质量趋势，如预测偏差，实现及时纠正。

   （5）优化级（Optimizing）。

可集中精力改进过程，采用新技术、新方法。

拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。

可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。

 2．目前在我们软件开发工作中的哪些典型问题可以通过推行CMM/CMMI2的工作加以解决？

目前我们软件开发工作中许多典型问题都可以通过推行CMM/CMMI2级工作加以解决。

下面我们就列举出一些典型问题，您可以看一看在您的企业中是否存在类似的情况。

注意每个问题后面括号中的名称就是CMM/CMMI中解决该问题的关键过程域名称（KPA）。

 Ø        项目开发计划是凭“经验”制定，缺少必要的科学依据。

（SPP）

 Ø        企业高层领导无法真实地了解和控制项目开发进程。

（SPP）

 Ø        无人知道一个项目的真实成本。

（SPP）

 Ø        对项目可能出现的风险一无所知。

（SPP）

 Ø        对开发人员的考核无科学依据。

（SPP）

 Ø        无人知道项目能否最终实现既定的目标。

（SPTO）

 Ø        软件开发中形成大量有价值的数据无人过问和收集。

（SPTO）

 Ø        在项目（产品）质量（缺陷水平）、成本、工期和技术等要求之间平衡问题上，缺乏有效地平衡机制。

         （SPTO）

 Ø        不知道如何随着项目的进展，合理安排、配置和调整各种资源。

（SPTO）

 Ø        无人真正地知道客户需求变更次数及原因。

（SRM）

 Ø        无人真正地知道是否客户的需求已经全部转化到项目产品之中。

（SRM）

 Ø        无人清楚地知道每次客户的需求变化对开发工作带来哪些负面影响潜在风险？

（SRM）

 Ø        无人清楚地知道被开发活动中的重大变更的次数及原因。

（SCM）

 Ø        无人清楚地能够知道每次变更所带的潜在风险。

（SCM）

 Ø        无人清楚地知道被开发项目的每个单元状态（是否通过测试）。

（SCM）

 Ø        变更是随意的。

（SCM）

 Ø        无法完全地说清楚被开发代码与设计文档间的关系。

（SCM）

 Ø            无法有效地控制外包项目？

（SSM）

 Ø         无人对出现的各种技术或管理问题进行深入地分析，类似的问题不断发生。

（SQA）

 Ø         无人监督软件开发活动是否处于稳定状态，只有出现缺陷或质量事故时才想起控制。

（SQA）

 Ø         出现重大缺陷时，无正规的通报渠道。

（SQA）

 Ø         无人关心软件开发过程的适宜性、有效性和充分性。

（SQA）

3．如何看待推行CMM/CMMI对我们目前工作带来的冲击？

许多软件企业都面临着两难的选择，一方面，对目前软件开发工作的混乱局面感到头痛，希望采取措施，立即加以解决。

另一方面，又担心推行CMM/CMMI对目前的开发工作带来冲击。

特别是在开发任务紧，人力资源不足，资金紧张的状况下，更难下定决心。

   那么如何看待推行CMM/CMMI对开发工作带来冲击呢？

这就取决于企业高层管理人员的认识了，一句话：

这种“冲击”是值得的。

   这种冲击首先表现在“额外”增加许多工作量，示意图如下：

   未推行CMM/CMMI

                 a                     b

               软件开发周期             软件维护周期 

推行CMM/CMMI

                       a′                   b′

                    软件开发周期              软件维护周期

表面上看推行CMM/CMMI之后开发周期有所增加，即a′＞a，但维护时间缩短了许多，b′＜b，综合两者，a+b＞a′+b′。

即表面上虽然开发周期变长，但整体时间缩短，成本大大降低，而且产品质量显著提高，因此是值得的。

   其次有些冲击是必要的。

例如，文化上的冲击。

以往我们的软件产品开发是靠“个人英雄主义”，而当今软件产品开发是靠“兵团作战”。

推行CMM/CMMI就是这种“兵团作战”的基础。

因此，这种在文化上的冲击也是必要的。

其它冲击还有很多，在这里就不一一赘述。

   目前许多软件企业管理人员有一种类似如何处理龋齿心态，因为怕痛不去医院治疗，推行CMM/CMMI一定会带来文化上的激烈冲击，这样下去后果大家自然会想到。

因此一定要正确看待推行CMM/CMMI所带来的冲击。

4．推行CMM/CMMI到底在哪些方面能够给我们带来好处？

一个软件项目能够成功的最基本特征就是整个软件项目是在一个合理的计划指导下，有序地完成各项规定的任务。

这包括十个最基本的因素。

这些因素都可通过建立CMM/CMMI模型所获得的。

它们是：

   ①建立一个清楚的视野。

包括明确整个和各阶段要实现的目标，以及可能存在的各种风险等。

这些可通过科学地评估和周密的策划所得到。

   ②获得一个相对稳定和完整的书面需求。

需求的变更是导致软件产品质量下降和开发工作混乱的主要原因之一。

通过需求管理可以最大限度地降低这项风险。

   ③建立一个有效的与客户之间沟通的渠道和方法。

与客户沟通的有效性，直接影响着客户对产品的满意以及对尽可能降低开发成本和风险，缩短开发周期。

   ④实施有效项目开发过程管理和控制。

严格执行项目开发计划，并及时解决出现各种技术和管理问题。

在此过程中还要不断收集产品、过程和体系产生的各种数据。

为今后有效开展改进工作奠定基础。

   ⑤准确和快速识别开发工作中所出现的各种问题。

采取纠正和预防措施，防止问题再次产生。

   ⑥持续改进。

软件产品开发活动本身带有许