基于CMM的软件开发

　　

        软件开发流程存在风险不可控的问题，因此各种软件开发流程应运而生。这些规范的软件开发流程试图将软件开发用一个规范的流程控制起来，变成一个类似传统工业化生产流程的工业。

 

       CMM简介

    CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

　　CMM 三大理念

　　CMM主要理念之一就是加强过程控制，认为只要开发的过程按照规定动作执行，就可以很大程度上降低软件开发的质量、进度风险。而过程质量控制的主要手段就是检视。

(检视有项目组内检视，其他相关人检视等。能够发现文档写作，代码编程规范，接口，代码实现等多种问题。检视也有缺陷率指标。可以以会议上走读的形式现场检视，也可以发出代码，各自检视并反馈检视意见表单，开发人员对检视意见综合处理后开会澄清一下。代码或文档检视形式灵活多变。zyq)

　　CMM的理念之二是根据经验数据指导新的软件开发项目。CMM定义了监控软件开发过程是否规范的一系列指标，如软件生产率、检视缺陷密度、遗留缺陷密度(还有UT覆盖率，UT发现问题率等指标)等，并总结了同业的一些经验数据。当执行实际项目时，以这些经验数据指引开发过程，尽量使开发的关键质量指标落入经验数据区间。同时进行进一步分析总结，对质量目标进行修正，用以指导后续的新项目。通过在一个个的项目逐渐总结修正，最终得到一套适合自己的质量目标。

　　CMM的理念之三，也可以说是本质，是基于传统的瀑布软件开发模型的。

　　CMM全流程

　　CMM软件开发规范的流程。CMM规范基于瀑布软件开发模型，没有体现基于原型逐步求精的思想，这也是近年来在实施中为人所诟病的一个方面。下面结合IPD流程阐述一下CMM流程在公司实际的应用。

　　CDP-Charter

　　CDP即 Charter开发项目，主要的责任主体是Marketing团队和SE，目标是定义一个产品版本所要解决的主要目标和时间点，交付件是Charter。 Charter要通过BMT，即业务管理团队的批准。Charter需要回答这些问题：版本的Top N需求和主要竞争需求，主要目标客户，完整的包需求(OR: Orignal Requirement），版本的里程碑时间点，应用的时间窗口以及在版本火车中所处的位置。

　　Charter-TR1

　　TR1即产品概念完成里程碑，主要的责任主体是SE团队，同时Marketing配合完成需求的细化、澄清和修订。这个阶段的目标是输出设计需求（DR:Design Requirement）。相比包需求，设计需求粒度更细，能够清晰的描述每一个需求，包括每个需求的输入、输出参数，并输出低保真界面原型。

　　CDCP

　　CDCP即Concept Decision Check Point，近年来大部分项目都裁剪，具体作用不明。

　　TR1-TR2

　　TR2即产品设计完成里程碑，主要的责任主体是SE团队。这个阶段的输出是设计规格。相比设计需求，设计规格从系统架构的角度将每个设计需求分配到每个子系统，并定义每个子系统之间新增、修改的接口。接口必须详细定义到足以指导开发人员实现的程度，可能部分没有注意到的细节可以在后续开发过程中澄清，但总体的接口设计是不允许在后续随意更改的。同时TR2还要输出高保真界面原型。

　　PDCP

　　PDCP即Plan Decision Check Point，项目计划里程碑。虽然Charter决策时已经定出了版本代码规模、关键时间点和人力需求，但经过TR1和TR2的分析和细化，不可避免的会出现一些变更。TR2是项目从构想到实现，从混沌到清晰的一个关键时间点。相比TR2前比较不可控的的研讨、分析，TR2以后主要是执行的一个过程，因此在TR2前后有必要将版本代码规模、关键时间点和人力需求进一步明确固化下来，以便后续开发团队按照一个严格的计划来执行。除了以上提到的，PDCP时还要确定质量目标，由开发代表给各项目经理下发SOW（工作任务书）。SOW中明确了各个开发项目组在TR2-TR4之间应该完成的开发任务，是开发组完成开发任务的依据。

　　TR2-TR3

　　这个阶段开发组完成软件需求规格说明书（SRS）的写作，以及按照大瀑布模型，完成系统测试用例的写作（STC）。SRS基于软件设计需求（DS）分解细化，用描述性的语言阐述每个典型用户操作/业务流程的实现过程，包括每个子系统如何协作通讯。

      TR3-TR4

　　这个阶段开发组依次完成软件概要设计（HLD）和集成测试用例（ITC）、软件详细设计（LLD）和单元测试用例（UTC）、编码。HLD的交付标准是定义到函数接口级别，LLD的交付标准是写出伪码。但由于瀑布模型的固有缺陷，如果花了大量的时间在文档协作上，编码时间很短，重大的风险无法提前识别，只能到编码时菜暴露，对项目进度影响大。近年来大部分项目都将HLD和LLD合二为SD——软件设计说明书，而且弱化了伪码协作。

　　ITC根据项目的需求而定，如果项目本省不需要专门的集成测试，就可以裁减了。如果基于xUnit进行单元测试，则UTC文档可以裁减，或至少部分裁减。

　　TR4-TR4A

　　这个阶段开发组要完成UT/IT/ST/BBIT(这四种测试都是软件开发人员自己测试，没有转到测试组人员测试 zyq)，TR4A时开发组要向测试组交付版本进行测试。BBIT是指Building Block Integrated Test，一般是指跨团队的子系统间的集成测试。

　　TR4A-TR5

　　这个阶段测试部会完成2+1的测试，即完成两个版本的完整测试，外加1个版本的回归测试。根据CMM的经验，2+1的测试可以达到版本功能稳定的程度。TR5结束即意味着版本开发阶段的结束。对于直接交付给客户的产品，下一阶段就是实验局阶段。对于交付给下游的中间件，产品开发基本结束，准备过TDCP。

　　TDCP

　　TDCP即 Technology Decision Check Point。这个里程碑意味着产品主要开发活动的结束。开发代表需要邀请下游用户、测试等相关干系人员参与评审。评审的标准是产品的遗留缺陷。各域的代表会关心这些遗留缺陷是否确实影响用户的使用，有没有规避的方法。

　　TR5-TR6

　　对于直接交付给客户的产品，这个阶段就是实验局阶段。管理团队会挑选适当的客户来使用新版本，并根据暴露出来的问题进一步优化、改进。TR5-TR6之间的版本也会用于入网测试。很多新的特性本来就是应某些入网测试的需求开发的。

　　TR6-GA

　　这个阶段是维护阶段，对各种缺陷进行修改，发布新版本。这些缺陷可能是内部测试、外部测试、客户使用过程中暴露出来的。这个阶段只在控制范围内限量接收小的新需求，接收与否的依据是是否对架构影响大，是否确实紧急。

　　GA

　　GA意味着产品主要生命周期的结束。过了GA点以后，基本不会基于这个主版本在发布新版本，不接纳新需求。