3.2.3 软件项目跟踪与监督（Software Project Tracking and Oversight）
软件项目跟踪和监督的目的，是建立对实际进展的适当的可视性，为了及时发现开发过程与项目计划之间的误差，使项目经理或高层管理者能够及时了解软件开发过程的状态，能在软件项目明显偏离软件计划时采取有效措施。
CMM重复级软件项目跟踪与监控的基本流程可如图7所示。该流程描述了软件项目组根据文档化的估计、承诺和计划，以跟踪和审查软件成果，并根据实际情况来调整计划。文档化的软件项目计划被用作跟踪软件活动、了解状态和修正计划的基础。项目经理根据项目开发计划跟踪项目的执行情况，定期形成项目进度报告，并与项目开发计划进行对比，发现问题，并及时修正。
图7：软件项目跟踪和计划基本流程图
根据图7所示流程，在进行实际项目计划跟踪与监控时，可以采取如下方式：
1. 项目经理每周根据项目的实际执行情况，拟定项目的进度报告。然后召集项 目小组成员，对进度报告进行确认和修正。
2. 项目经理对照计划与实际执行情况，发现差距并将其纪录成问题报告，其中包括：费用、进度、风险、人员、资源状况等。
3. 由高层管理者复审进度报告及问题报告，并敦促项目经理修正其计划及解决项目存在的问题和风险。
4. 实际项目中应用的文档有：项目跟踪与监控流程定义、项目进度报告、项目进度指标收集指南。
联想软件事业部关于软件项目计划有如下流程:
1．制定项目跟踪计划。其目的是对项目的跟踪和管理活动做成安排，由项目经理负责，其依据是度量计划和项目计划。该计划首先应规定项目要采集的数据项、采集人和采集时间。所采集的数据项应包括软件的规模、成本、进度、关键计算机资源和风险跟踪等内容。另外，项目经理应在跟踪与监控计划中对项目例会关注的问题做出安排。最后，项目经理在《跟踪与监控计划》中决定《项目状态报告》的频率，建议定期和事件驱动相结合。跟踪计划需要得到所有涉及到的负责人的认同，被批准的项目跟踪计划应纳入配置管理。
2．数据采集。其目的是收集规模、成本、进度、关键计算机资源和风险等数据，以用于分析项目的状态。实施的人员包括：数据采集员，项目经理和项目组成员。其采集流程如图8所示
项目组所有成员每日记录自己的工作量，填写《工作量周报》
《工作量周报》
项目经理和SQA人员抽查，验证数据的及时性和有效性
数据采集员定期采集数据，填写《项目数据汇总表》
《数据项目汇总表》
项目经理审核《项目数据汇总表》
将审核过的《项目数据汇总表》提交数据分析员
图8：数据采集流程图
3．数据分析。其目的是根据获得的实际数据，对照计划，分析状态，解决问题。其主要活动是，项目经理对比项目数据汇总表中的实际数据和项目计划中的计划数据和阈值，管理项目的工作产品规模、工作量、成本、关键计算机资源、进度和风险。分析的结果优先目经理记录在《项目状态报告》中，说明项目在这一阶段的管理活动和软件工程状态，指出问题，提出解决方案。
4．项目例会。其目的是定期交流项目状态。由全体项目组成员参加。例会的首要议程是检查上次例会所提出的问题是否解决，然后对项目当前及将来可能的状态进行分析。
5．正式评审。其目的是在里程碑处，组织相关小组和用户对项目的整体情况做出评审。正式评审的主要活动是召开评审会议。项目经理向评审小组介绍项目的进展情况，评审小组对项目做出整体评价，并提出建议。会议书记填写《评审报告》。
6．修改项目开发计划。其目的是使项目计划更符合实际情况。由项目经理负责，其主要流程如图9所示
项目经理提出变更申请，并接受评审
项目经理修改项目计划
提交上级经理批准
通报受影响的组
将修改过的项目计划纳入配置管理
通过
不通过
通过
图8：修改项目开发计划的流程图
3.2.4 软件质量保证（Software Quality Assurance）
软件质量保证的目的,是为管理人员提供软件项目所用流程和正在构建的产品的可见度。软件质量保证涉及审查和核实软件产品及其活动，以便验证它们与项目采用的过程与标准的一致性。软件质量保证的基本流程可如图9所示。该流程描述了软件质量保证计划的形成与复审，SQA人员根据质量保证计划开展质量保证活动，发现问题，跟踪解决问题，并最终向高层领导汇报执行情况。质量保证计划一般包含项目过程采用的标准和软件工作产品的标准。
图9： 软件质量保证流程图
根据上图所示流程，结合实际情况，可确定如下的软件质量保证过程：
1．项目质量保证人员拟定项目质量保证计划文档和项目质量保证活动的进度表。
2． 由质量保证经理或高层管理者指定项目的质量保证人员。项目的质量保证人员在项目开发计划复审通过之后，拟定项目的质量保证计划，并提交给项目经理和质量保证经理或高层管理者复审。
3．质量保证人员根据计划对项目执行的活动进行定期审计，记录与项目流程定义不一致的问题，并形成报告。
4．质量保证人员组织人员对产出的工作产品进行复审，以验证其是否与项目采用的标准一致，并形成报告。
5．将审计和复审发现的问题记录到项目的问题跟踪进度表中，跟踪并协调问题的解决情况，并定期向高层管理者汇报。
6．项目经理或高层管理者定期检查质量保证人员的活动。
7．实际项目中应用的文档有： 项目质量保证流程定义、质量保证计划、流程审计报告、软件工作产品复审报告、质量保证计划进度表、SQA问题跟踪解决进度表。
联想集团软件部的具体做法有以下流程：
1．制定SQA计划。该活动需要《立项报告》作为输入，还要参考《项目计划》中的数据。其中包括以下几个要点：SQA的职责与权力，资源要求，SQA活动进度，由SQA进行的评审，用作SQA评审基础的项目标准与规程，对发现不符合的项的处理规程，SQA计划的评审。
2．执行SQA计划。其主要活动包括：检查是否满足进入准则，剪除输入的工作产品是否正确，确认执行活动的人员具备执行活动的能力，验证开展的工作与计划的符合性，检查活动是否满足活动准则，审计输出的产品与前阶段输出的工作产品的一致性。在评审过程中，如果发现不符合项，则记录在《不符合项报告》中，并按照图10的流程做出处理。
不符合项报告
将不符合项提交有关责任人
责任人解决问题并反馈给SQA
SQA与项目组沟通，跟踪不符合项，对反馈进行审查
关闭不符合项
提交高程经理帮助解决
注销不符合项
通过审查
得到解决
未通过审查
不能解决
图10：SQA组发现不符合项后的处理工作流程
3．SQA工作总结。在项目结束后，SQA要在两方面做出总结。一是对SQA的工作度量，总结工作中的经验和教训，提高SQA组的工作能力；二是对产品进行评价。最后生成《SQA总结报告》。
3.2.5 软件配置管理(Software Configuration Management)
软件配置管理的目的，是在整个软件生命周期中建立和维护软件项目中的产品的完整性。它包括标识在给定时间点上软件的配置，系统地控制对配置的更改，并维护在整个软件生命周期内配置的完整性和可跟踪性。因此，软件配置管理可以分为两方面的内容，一是配置项的识别和管理，另一方面是变更管理。其基本的工作流程如图11和图12所示：
图11：配置相的识别和管理
图12：变更管理
根据图11和图12所示流程，可以总结出软件配置管理的一般方法：
1．项目设定配置管理人员，根据项目计划拟定项目的配置管理计划文档，拟定项目配置活动的进度表。
2．项目的配置管理计划包含以下内容：配置管理工具、目录结构、识别配置项的方法、配置项命名、创建配置管理库、基线管理、配置审计、配置状态报告、变更管理等。
3．由配置管理人员负责在适当的时机（如：里程碑处或迭代结束）创建基线，晋升基线，下降基线，并由其负责备份和恢复基线。
4．根据配置管理计划对项目的配置项和基线定期（或里程碑处）进行审计，以验证其是否与项目配置计划或项目开发计划一致。
5．所有的变更请求首先向配置管理人员提出，由配置管理人员对变更请求进行分析确定其影响，组织变更评审小组。
6．一旦同意变更，由配置管理人员标记出需变更的配置项，然后对配置项进行变更，变更完成后再由配置管理人员放回到配置管理库中。
7．由SQA人员定期审计配置管理的活动。
8．实际项目中应用的文档有：项目配置管理计划制定流程定义、项目配置管理活动流程定义、项目配置管理计划、配置状态报告、基线审计报告、配置项变更申请表、项目配置管理活动进度表、配置管理工具操作指南。
联想集团软件部的具体做法是：
1．SCM准备工作。SCM组与项目经理一起制定SCM计划。然后经其他受到影响的组和个人进行评审，得到被批准的SCM计划。其内容包括：项目中江要进行的SCM活动，文档标识的参考规范，时间安排，相关资源，职责分配，将要设计的每个软件配置项（SCI）的定义，SCI变更是的影响范围。此外，事业部SCM主管需要为新启动的项目建立开发库、受控库和产品库，为项目组成员分配相应的用户权限。
2．SCI的标识。该活动发生在SCM计划被批准之后。SCI撰写人根据SCM计划中制定的文档规范进行标识。
3．SCI入受控库。软件开发过程中，项目组成员将产品提交到开发库中，经批准后，再转移到受控库中。同时通知所有的受到影响的组和个人。
4．SCI变更。SCI的变更分为基线变更和版本变更。基线变更的流程如图13所示。在基线变更的过程中，要注意对正在变更的SCI进行加锁。
提出变更的人员估计工作量和日程进度，填写变更请求说明
提交项目经理进行审批
变更请求书提交SCCB，并保存在受控库中
SCCB评审
基线变更，确立新版本
形成“变更请求审评会议纪要”，并将此文档保存在受控库中
审批通过
图13：基线变更工作流程
如果所申请的变更是版本变更，则根据所影响的范围，项目经理填写变更请求说明书，然后由SCCB召开变更评审会议。
5．基线审计。其目的是维护软件配置项的状态，使其满足一致性、完备性和可跟踪性。其内容包括：验证当前基线所有SCI对迁移基线相应项的可追踪性，确认当前SCI正确反映了软件需求，审计三库中的项目工作产品，填写报告。
6．配置状态记录与汇报。其目的是维管理人员和开发人员提供有关项目进展的全面信息。以定期或事件驱动的方式，提供项目配置的当前状态及修改情况。
7．SCI的备份。指对开发库、受控库和产品库中所有的SCI进行备份，以保证三库信息的安全。
3.3 正确认识CMM评估
CMM是指导软件企业进行软件过程改进的指南，它指导软件企业如何进行改进，是一个逐渐提高的过程。我国软件企业应该把目标放在有计划的过程改进上，而不是应付CMM等级评估。CMM给企业带来的利益，是通过有效的过程改进实现的，而不是CMM等级的认证。单纯的追求认证级别，或者“先认证，后改进”的做法，只会给企业单来经济负担，而没有实际效果。
CMM的过程改进是一个长期的过程，需要企业有整体的计划和投入，不能只把目标放在有限的级别上，应该坚持不断改进的思想，切实把过程改进落实到实处。
CMM从一级过渡到二级，大概需要两年左右的时间，而目前社会上存在一些评估组织，宣传用极短的时间帮助公司通过CMM重复级认证。对于这种情况，公司应该继续执行自己的计划，切实提高水平，等达到或者很接近CMM重复级要求的时候，在开始着手认证工作。单纯的认证对公司是没有意义的。
3.4 结论
CMM描绘了软件过程改进的一个“常识工程化”路径。它的成熟度等级、关键过程区域、目标及关键实践经受了软件社团内部的广泛讨论和评审。同时CMM既非完美无缺也不是包容一切，它只是表达了软件社团的一种广泛一致的意见，并且成为指导改进工作的一个有用工具，它也有助于小型软件组织改进它们的过程。
本文通过实例分析，详细介绍了CMM规范和实现CMM第二级的方法。CMM是一条没有终点的路，企业在实施CMM第二级后，应该继续朝着第三级和更高的级别前进，不断的改进和提高过程能力，促进自身乃至整个软件行业的发展。
参考文献：
1 美国卡内基·梅隆大学著．能力成熟度模型（CMM）：软件过程改进指南：英文版.北京：人民邮电出版社.2002年10月
2 雷剑文，陈振冲，李明树.CMM：软件过程的管理与改进.北京：清华大学出版社.2002年9月
3 观点工作室.CMM实践之路.北京：机械工业出版社.2003年3月
4 杨一平等著.现代软件工程技术与CMM的融合.北京：人民邮电出版社.2002年11月
5 单银根，王安，黎连业.软件能力成熟度模型（CMM）与软件开发技术.北京：北京航天航空大学出版社.2003年5月
6 Jalote，P.著.CMM实践应用----Infosys公司的软件项目执行过程.胡春哲等译.北京：电子工业出版社.2002年8月
7 Mark C. Paulk. Using the Software CMM in Small Organizations. http://www.tongtech.com/jsqy/yqxwview.asp?id=247
8 刘文威 宁传成,CMM Level 2 实战, http://www.51cmm.com/PubCMM/No104.htm
