【IT168 技术文章】
CMM(软件能力成熟度模型：Software Capability Maturity Model)，是由美国卡内基梅隆大学(CMU)的软件工程研究所(SEI)制定的一种软件评估标准，主要用于软件开发过程和软件开发能力的评估和改进。此标准自1991年提出以来，已在美国、印度、日本、欧洲等地成功应用，并成为软件行业的工业标准。尽管CMM引起了软件行业充分的重视，但如何将CMM应用到企业或项目管理中 ，大多数企业仍然毫无头绪。而对于银行的科技部门，属于非软件行业的软件开发部门，是否可以通过应用CMM来优化项目开发过程，这是本文要探讨的问题。
软件能力描述了通过遵循软件过程能够实现预期结果的程度，就是软件企业在一个项目时其项目过程曲线的“波动带”，即项目围绕项目计划开发过程中的变化范围。随着成熟度级别的提高，在项目过程中关键点的目标结果与实际结果之间的差距越来越小、项目的可预见性将越来越高、项目过程中实际结果的变化范围将越来越小。
CMM在一个更高的层次抽象的关注组织上和管理上的问题，它只告诉我们要做什么，但却没有告诉我们要怎么做。它描述了一个软件企业的流程管理需要关注的属性和希望达到的目标，但它却没有在操作层面具体的描述要怎么实现这些目标。因为不同的软件企业，在规模和管理模式上不尽相同，CMM不是一济能医治百病的灵丹妙药，也不是一种“立竿见影”式的管理技术，它只是一种不断改进企业自身能力的方法，在具体的应用上，还要和企业的生产流程、管理模式、职能分布等因素结合起来，建立一套适合本企业生产发展的软件过程，才能使企业的软件项目在成本、进度、质量这个铁三角里找到非常好的的平衡点。
CMM的官方文档里面也有说到，当企业的员工少于50人时，需要对CMM的各个KPA做横向、纵向和深度的剪裁。我们是金融机构的科技部门，只有在编员工四十人，所以，CMM庞大的体系并不完全适用于我们，必需根据我们自身的实际需要和管理特征，对CMM体系做相应的剪裁。
银行的软件开发部门和一般的软件企业相比，有以下的不同点：
1、一般的软件企业有产品发布的市场风险和产品开发的自由度，而我们没有根据市场需求发布产品的需要，我们所做的项目也必须与企业的发展战略相适应，为企业的发展助力。
2、一般的软件企业在项目完成软件产品交付以后只需对软件做保修性质的维护，而我们需要对产品做长期的运行管理和升级维护，并且根据业务规模的扩大不断的修改软件的属性和增加软件的功能。
3、一般的软件企业是由项目堆砌起来的，项目盈利了企业才能盈利；而我们是属于银行内部的软件开发部门，承接的项目都是为企业服务的。
根据业务需求的范围，把需求分为两类：
项目级需求，新的子系统，主要通过合同外包或内部项目组开发完成。
交易级需求，在原有系统的基础上增加新的交易或对原有的交易进行修改，主要由内部项目组完成。
根据我们自身的一些实际情况，在CMM的剪裁上，我们可以在纵向上以CMM2级为核心，向CMM3级CMM4级延伸，横向保留CMM2级的大部分KPA，在此基础上增加CMM3级的组间协调、集成软件管理、培训大纲的KPA，以及CMM4级的软件质量管理KPA，在深度上做根据我们自身的需要，对各个KPA的具体活动做相应的裁减。
在这里，我们对CMM2级的相关KPA进行讨论。CMM2级的核心是实现项目的文档化管理，主要包含有六个KPA，分别是：需求管理(RM)；软件项目计划(SPP)；软件项目跟踪与监控(SPTO)；子合同管理(SSM)；软件质量保证(SQA)；软件配置管理(SCM)。
·需求管理(RM)
需求是整个项目的出发点和落脚点，是项目过程中其他各个环节依赖的基础。但是，在一个软件项目开发的过程中，随着用户对系统的了解和业务范围的扩大，需求会发生变更；另一方面，产品在开发过程中会经历分析、设计、编码等步骤，由于各个阶段的相关开发人员的知识水平与关注点不同，对需求的理解也会产生偏差。
需求管理的目的是在用户与实现用户需求的项目之间达成一种共识并维护这种共识，它针对对这两个问题提出了相应的目标。软件的需求可能是系统需求的一部分(系统工程的一部分)或是全部(单纯的软件工程)。无论是哪种情况，需求管理的第一个目标就是软件需求应能被控制，并可产生一个可用于软件工程过程和管理过程的基线。需求管理的第二个目标是确保软件项目计划、开发活动、产品与软件需求一致，保证最终的项目成果能够满足用户的需求。
·软件项目计划（SPP）是整个项目过程的骨架，它支撑起整个项目的过程。但大部分软件开发管理人员对它的重视程度还不够。软件项目计划前提是要有一个合理的、有效的计划，然后还必须有很强的能力去执行它。项目对于某些人来说，感觉就像是一个黑盒子，看不见摸不着，要对它做出一个合理有效的计划确实不是一件容易的事。我们的同事经常是一接到项目，掐指算算，然后就对领导拍胸脯保证一个月内完成任务，但是由于对项目过程中的资源调配和风险预期不足，导致项目进度一拖再拖。
要做出合理的项目计划，首先是估算，通过以往的项目经验拟订一个估算的标准，然后对项目的规模、资源要求和风险进行合理的估算。软件计划制定时要包括所有项目活动和所有参加方面的责任，这些活动和责任要文档化，以保证有效地将计划传达给项目各个参加方。在项目计划执行前，各个项目参加方要认同所承担的项目责任，并且项目计划的执行有行政职能的监督，这些认同和监督是项目计划有效性的基本保证。
·软件项目跟踪与监控（SPTO）
CMM里的软件项目跟踪与监控KPA涉及到三个关键词：可见性、检查点、修订计划。通过在项目过程中设置检查点来展现项目过程的可见性，发现不足，然后修订计划。
由于软件项目过程是一个逻辑活动过程的组合，因此，它不具备一个物理过程那样的可见性。软件项目跟踪与监控的目的就是为项目实际过程提供充分的可见性，以保证当项目执行偏离项目计划时能采取有效的解决手段。 项目跟踪是基于计划的，对一个项目要设定适当的检查点。在检查点上要将执行结果、执行状态和软件项目计划进行比较。若发现较大的差异，则采取适当的步骤进行调整。在必要的情况下，也需对计划本身进行修改和维护。若在修改计划时，改变了某些项目的责任，那么这些改变必须得到有关责任方的重新认同。
·子合同管理（SSM）
子合同管理对金融机构来将是比较重要的KPA，就像前面所说的，我们有一些较大的项目，比如一些外挂的子系统或者一些底层的平台开发项目，我们是外包给软件公司来做的。这样做的好处一方面可以节省我们单位日常必须维持的人力物力，另一方面，也可以让我们更好的专注于与金融业务相关的二次开发。这样，也带来了子合同管理的问题。子合同管理我们主要关注的有两点，如何选择软件承包商与如何对承包出去的项目进行监控管理。我们通过衡量软件企业的能力来选择软件承包商，当然还要考虑资金成本方面等因素，一般都是通过招标的方式来进行。对于承包出去的项目的监控管理，主要是还要靠交流，甲方和乙方通过不断的互动交流，让甲方对项目的进度有个整体的了解和把握。交流的方式有很多，有直接的咨询，有规范化的文档，有技术讨论会议，还有项目周报等。
软件质量保证是从项目流程管理上来保证软件的质量。由于用于开发软件系统或软件产品的过程是决定项目成功与否的关键因素，因此软件质量保证的工作是评审和审计软件活动和软件产品。评审和审计的依据是规定用于项目的步骤和相关标准。软件质量保证活动不能是随意的，必须经过充分的讨论和协商。相关的组织和个人要了解质量保证的活动和质量保证活动的结果。为了解决质量保证组织与开发组织对某些项目开发活动或开发出的产品的评价所发生的争议和分歧，企业要定义更高层次的管理组织，负责解决这些争议和分歧。
·软件配置管理（SCM）
软件从需求分析开始到最后提交产品要经历多个阶段，每个阶段的工作产品又会产生出不同的版本，如何在整个生存期内建立和维护产品的完整性是软件配置管理的目的。CMM软件配置管理关键过程域遵循了传统软件配置管理的概念，其基本工作内容是标识软件配置项，建立产品基线库，对配置项的修改加以系统的控制。
因为金融机构对软件项目的质量要求要比一般的软件项目高，在运行维护方面的要求也更规范更严格，所以，除了CMM2级的相关KPA，我们还需要增加CMM3级的组间协调、集成软件管理、培训大纲的KPA，以及CMM4级的软件质量管理等KPA来完善我们的软件过程。
在银行的软件开发部门应用CMM，能够不断的提高部门的开发效率，让项目进度控制更严格，品质更有保证，管理更有序，但前提是要使用得当。它没有一种固定的模式，也没有确定的应用框架，更没有明确指导我们要如何去实现，所以，我们科技部门需要结合自身的实际情况去裁剪，去探索出一套适用于银行的软件项目过程。
