项目监控过程域的研究与应用

王瑞民，李 娜

0 引言

软件成熟度模型集成(Capability Maturity ModelⓇIntegration：CMMIⓇ)是由美国国防部委托卡内基梅隆大学软件工程学院开发的，用于评估和改善软件组织开发过程和能力的一套模型［1－6］.该套模型可以协助软件组织持续改进软件过程的成熟度并提高软件的质量，提升软件组织开发产品的能力和管理的能力，最终达到缩短开发进度，降低开发成本，确保软件质量的目标.

项目监督与控制活动贯穿项目的整个生命周期.CMMI V1.3十分重视项目监控活动，并在CMMI管理级中，强化了项目监控(Project Monitoring and Control：PMC)过程域.对项目实施有效监控，既可保证合理的项目计划得到顺利实施，又可避免“执迷不悟”地按照不合理的计划行事.另外，将项目监控过程产生的数据保存起来，还可以为软件组织持续地过程改进提供有价值的数据.项目监控的关键是跟踪项目的实际进展和性能［7］.

但是，CMMI模型只是过程改进的指导性框架，只告诉了软件组织需要“做什么”.对于如何做，才能满足过程目标，却缺乏可操作性［8－9］.基于一些软件组织实施CMMI等级评估的结果，总结了项目监控过程的典型弱项.通过分析项目监控过程域各特定实践的相互关系，给出了产生典型弱项的原因.结合笔者实施软件过程改进的实践经验，针对项目监督与控制活动的典型弱项，给出了详实的改进方案.

1 项目监督与控制过程域

项目监督与控制过程域的目的是：通过周期性地或里程碑式地跟踪项目计划的各种参数，如进度、工作量、费用、资源、工作成果，不断地了解项目的实际进展情况;以便当项目的实际进展状况显著偏离于原有计划时，能够及时地采取纠正措施.CMMI模型为项目监控过程域设立了两个特定目标.为了满足项目监督与控制活动的两个特定目标，需要通过执行一些特定实践来分别实现.

SG1依据项目计划，监督项目的实际性能和进展情况.该特定目标的实质是发现项目的问题.共包括7个特定实践.

SP1.1监督项目计划各参数的实际值.项目的计划参数，主要包括项目的范围、规模、工作量和成本等.在项目进展过程中，需要密切关注这些参数的实际情况与计划估计的结果是否一致.当计划参数的实际值与估计结果存在严重偏离时，需要标识出来.

SP1.2按照项目计划中标识的承诺关系，监督承诺.所监督的承诺，既包括对外部客户的承诺，也包括内部上游客户对下游客户的承诺.监督的依据是在项目计划中定义的依赖承诺表.对于尚未满足的承诺，特别是不满足就会造成严重风险的承诺要进行重点监控.

SP1.3按照项目计划中标识的风险，监督风险.监督项目的风险，一方面是监督风险的概率和影响程度等重要的风险参数是否有变化，发生变化时，需要对风险的优先级进行重新评估;另一方面是监督预设的风险缓解措施的执行情况.

SP1.4按照项目计划，监督项目数据的管理情况.项目计划中，需要确定哪些数据需要管理，并划分需要管理的数据类型.针对不同的数据类型，确定相应的管理方式.一旦制定了项目的数据管理计划，数据管理就应该得到监督，确保数据管理计划得以完成.

SP1.5按照项目计划，监督相关干系人的参与情况.项目计划中，需要确定哪些人或组属于项目的干系人，并确定与其沟通的方式.监督干系人的目的是平衡各方干系人的利益，及时发现项目执行情况和干系人期望之间的偏差.

SP1.6定期评审项目的进展、性能和问题.所谓定期评审，并非指按一定的周期，而是要求有计划的开展检查.因此，定期评审可以是正式评审，也可以是非正式评审.评审时，需要采集和分析度量的结果，这些度量用于控制项目.对严重问题及偏离于计划、变更请求等问题，要标识并如实记录，并对评审结果进行文档化.

SP1.7在选定的里程碑点，评审项目的成就和结果.里程碑评审属于项目策划期间所计划的评审，目的是对项目各里程碑点的项目状态和性能进行监督，一般属于正式评审.

如图1所示，特定实践 SP1.1～SP1.5的设立，是为了了解项目的实际执行情况，评价项目的状态，从而为项目负责人及各级管理者，提供项目当前真实情况的可视性，用以判断项目是否沿着项目计划所期望的轨道，健康地取得了进展.SP1.6和SP1.7是了解项目性能和进展的方式，一般包括定期的周例会制度和事件驱动的里程碑会议.

图1 项目监控场景Fig.1 Project monitoring and control context

SG2当项目表现或者项目的度量分析结果，与原计划相比，存在显著偏差时，给出纠正措施，并管理纠正活动，直至问题得到解决.该特定目标包括3个特定实践.

SP2.1收集和分析问题，并确定必要的纠正措施来解决问题.偏离计划的情况大多是进度推迟、预算超支等.

SP2.2采取与已标识的问题有关的纠正行动.当出现严重偏离时，项目管理者不应该轻易的改变计划，以使计划与实际情况一致，而应该努力改善现有情况.否则项目计划就没有了执行力.但如果确实属于“不可能完成”的计划，变更项目计划也是必须的.

SP2.3管理纠正行动，直至问题得到解决.组织应该制定严格的变更控制制度，对涉及预算变更、里程碑点推迟等关键变化，组织的高层应该参与这些关键变更的评审，以保证项目计划的严肃性.

当项目状态显著地偏离了所期望的轨道，如工作量或进度的偏离，超过了预定的阈值，则应该采取纠正措施，改进过程的性能，使得项目的规模、工作量、进度、成本、缺陷及风险得到有效的控制.必要时，也可以修正项目计划.对制定的纠正措施，需要进行管理，确保项目能够调整到项目计划所期望的轨道上.

2 项目监督与控制过程域的典型弱项

在参与某软件组织进行软件过程改进的过程中，对该软件组织的5个试点项目和参加预评估的3个项目，进行了调查研究.分析后发现，这些项目在监督与控制过程中，存在一些典型弱项，主要体现在：

·没有建立在度量基础上的数量化监视，定性的监视精确度偏低.项目进展发生偏差是常见行为.控制阈值偏低，会导致纠正活动过于频繁，或项目计划不可行;但如果控制阈值过高，会导致问题倾向严重时，仍不能采取纠正措施.合理的控制阈值，应依据组织级的度量库和项目的实际特点而定.

·未形成项目例会制度.定期和不定期的会议，是发现问题，跟踪项目进展和性能的主要方式.个别项目为了赶工期，不开项目例会，或例会中不能提出有效问题，是项目失控的主要原因.

·项目成员和项目组无定期工作报告.举行项目例会和里程碑会议，目的是发现问题，确认问题.建立高效、畅通的沟通机制，是项目监控成败的关键因素.因此，项目各组员，需要及时总结，主动地将个人的工作进展呈报给项目负责人.项目负责人，进一步将项目的状态和问题，及时呈报给高层管理者.

·里程碑无严格的状态评审.主要体现在个别项目不划分里程碑点，或者划分了里程碑点，但高层管理者对项目的性能和状态，未能进行严格的审查，对出现的风险未采取应有的缓解措施.

·出现问题时，未能分析产生问题的原因，而是随意的修订项目计划.导致项目计划没有执行力.

·未记录采取的纠正活动.个别项目出现问题时，给出了纠正措施.但纠正活动并未落实到人.缺少必要的问题跟踪.

3 改进方案

项目监督与控制，属于CMMI成熟度管理级过程域.因此，为了达到CMMI成熟度管理级及以上各个级别的要求，各评估项目需要证明项目监督与控制的各个特定目标的所有实践，都被描述为“全部执行(FI：Fully Implemented)”或“大多数执行(LI：Largely Implemented)”.

在软件改进过程中，针对试点项目和预评估项目的典型弱项，可以将项目监控的活动分为3个阶段，分别进行改进.

第一、跟踪项目计划，并文档化监控结果.项目负责人，按照项目计划所识别的计划参数，通过周期性地(比如周例会)和不定期地(比如里程碑评审会议)跟踪工作任务，包括工作任务的进度和投入的工作量(表1)，所使用的成本(表2)，资源及产出的工作成果，及时地了解项目的实际进展情况，并为持续地过程改进提供有价值的数据.在跟踪的过程中，项目的各成员，应协助项目负责人收集有关的度量数据.

表1 任务跟踪表Tab.1 Task tracking table

表2 成本跟踪表Tab.2 Cost tracking table

本活动的入口准则是项目计划已经制定.出口准则为任务跟踪、费用跟踪、资源跟踪、工作成果跟踪所产生的数据已经文档化.

第二、项目负责人，对比“项目实际进展”和“项目计划”，分析偏差.将项目的偏差分析结果，如实写入项目进展日志中.如果发现项目的实际进展显著偏离了既定计划，则应分析产生显著偏差的原因，以便及时采取纠正措施.产生偏差的常见原因有两类.一是项目估算不准确或工作任务分解力度等问题导致项目计划不符合实际.二是人员、知识技能、资源环境等因素发生了变化.

根据产生偏差的原因，采取必要的纠正措施.如图2所示.项目的第三阶段，进度偏差率超出了预定的上限，应该仔细分析产生显著偏差的原因.如果偏差是由于原有项目计划不合理导致的，则要变更项目计划.如果偏差主要是由于项目成员在执行时产生的，则应要求项目成员弥补偏差，避免原本合理的计划在实施时落空.

图2 进度偏差率Fig.2 Schedule variance percentage

对于给出的纠正措施，应落实问题的责任人，并跟踪纠正偏差的过程，直至所遇到的显著偏差被消除为止.

本活动的入口准则是周期性地跟踪了进度、工作量、费用、资源、工作成果等，及时地了解了项目的实际进展情况;出口准则是发现的显著偏差已经被消除.

第三、项目负责人周期性地(或在里程碑点)召开项目进展会议，讨论项目所遇到的问题，总结工作，让所有成员清楚地了解项目的实际进展情况.撰写《项目进展报告》，并通报给高层领导者和所有的项目成员.

本活动的入口准则是已经开展了“项目计划跟踪”和“偏差控制”;出口准则是《项目进展报告》已经通报给所有项目成员和高层领导，并且配置管理员对监控过程中的相关数据进行了配置管理.

4 结论

SEI提出的CMMI模型中，对项目监督与控制活动的特定目标和特定实践，作了框架性指导.但是，在软件组织实施软件过程改进时，由于可操作性不强，容易导致项目监督与控制活动执行不了或者执行不到位.

通过分析CMMI模型中有关项目监督与控制过程域的特定目标和特定实践的关系，结合软件组织实施软件过程改进的实践经验，总结了项目监督与控制过程域的有关典型弱项.针对这些典型弱项，给出了可行的解决方案.

按照这些实践方案，对各个预评估项目，进行了过程改进，并在正式评估项目和其它软件项目中，作为组织的制度进行推广使用.在正式评估过程中，参加评估的5个项目的监督与控制活动，没有出现弱项［10］，符合CMMI模型对项目监督与控制过程域的要求，从而为参加评估的软件组织顺利通过CMMI 3级的正式评估，提供了强有力的直接证据和间接证据.本实践方案还可供具有类似软件过程经历的软件组织单位参考.

［1］SUN Y，LIU Xiao-qing.Business-oriented software process improvement based on CMMI using QFD［J］.Information and software technology，2010，50(1)：79－91.

［2］EILEEN C F，BRANDON L B，SANDY S.CMMI for services：cuidelines for superior service(CMMI-SVC，Ver1.3)［M］.Canada：Addison-Wesley Professional，2009：1 －790.

［3］许东，刘宗田.CMMI V1.2 版本的新特征［J］.计算机科学，2007，34(11)：241－244.

［4］李娟，李明树，武占春，等.基于SPEM的CMM软件过程元模型［J］.软件学报，2005，16(8)：1366 －1377.

［5］武占春，王青，李明树.一种基于PDCA的软件过程控制与改进模型［J］.软件学报，2006，17(8)：241 －244.

［6］王青，李明树，刘霞.一种支持软件过程控制和改进的主动度量模型［J］.软件学报，2005，16(3)：407 －418.

［7］乔立红，郭广鑫，杨志兵.改进的挣值分析法在型号项目管理过程中的应用［J］.北京理工大学学报，2010，30(1)：33 －36.

［8］田立，曾光裕，于磊，等.支持CMMI的软件过程元模型的研究与实现［J］.计算机工程与设计，2010，31(18)：3983 －3988.

［9］LEE Chang-shing，WANG Mei-hui，CHEN Jui-Jen.Ontology-based intelligent decision support agent for CMMI project monitoring and control［J］.International Journal of Approximate Reasoning，2008，48(1)：62－76.

［10］SEI.Published Appraisal Results［OL］.http：//sas.sei.cmu.edu/pars/pars.aspx.