CMMI5在小型项目中的成本过高，根据自己对CMMI5的实施体会与在实际项目中的应用，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中既可以确保流程规范与质量信赖又可以节约项目成本。以下跟大家分享一下CMMI5在项目中的精简应用：

一、需求与规范的管理

1、 由测试负责人（或专门的需求分析负责人）统一接收来自移动总的行业网关相关规范和新需求，测试负责人浏览规范获知大意后回复邮件，将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；

2、 测试负责人（或专门的需求分析负责人）、项目经理仔细阅读规范与需求后，对规范和新需求进行研究，并就难点和疑点进行讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；

3、 开发经理、项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定需求的具体含义以及最终实现的需求和功能点；

4、 项目经理根据规范、需求和开会讨论结果编写《需求规格说明书》与《功能列表》，测试负责人（或专门的需求分析负责人）对文档进行检查并修改完善，然后commit到CVS；

5、 测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。

二、项目计划与测试计划

1、 由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；

2、项目经理根据估算工作量和工程需求编写项目计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的项目计划；

3、测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；

4、项目计划与测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读项目计划、测试计划后将建议和意见以邮件的形式反馈给项目经理与测试负责人，项目经理与测试负责人收集大家的邮件分别对项目计划与测试计划进行修改完善，同时回复邮件说明项目计划与测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的项目计划、测试计划commit到CVS；

5、测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。

三、开发设计与评审

1、 项目经理构思系统设计，项目组开发成员一起讨论系统的设计，对设计形成较为清晰的思路；

2、 项目经理负责编写概要设计文档，与开发经理、开发团队成员与测试负责人一起讨论概要设计；

3、 概要设计完成后，项目经理编写详细设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计；

4、 设计文档编写完成后，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；

5、 开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；

6、 模块负责人收集邮件中的修改建议并对设计文档进行修改，同时回复邮件说明详细设计修改情况，修改后的详细设计commit到CVS；

7、 如果对设计存在争议或出现明显不合理的设计，召开一个小型会议对异议进行讨论，有效解决设计所出现的分歧

8、 测试负责人（或专门的PPQA）对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。

注：在大型的项目中，必须先完成概要设计后再完成详细设计，在小项目或需求中可做适当剪裁概要设计与详细设计合在一起完成。

四、测试方案与评审

1、在项目的设计阶段，测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案；

2、测试方案编写完成后，发邮件通知开发经理、项目经理、相关开发人员和测试人员；

3、开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查，开发经理和项目经理对测试方案进行总体性的审查，而各模块负责人则负责相关模块或功能的测试方案的审查，将建议和意见以邮件的形式反馈给测试负责人；

4、测试负责人收集邮件中的修改建议并对测试方案进行修改，同时回复邮件说明测试方案修改情况，修改后的测试方案commit到CVS；

5、测试负责人（或专门的PPQA）对最终修改的测试方案进行检查，并确认所有文档都已经commit到CVS。

五、编码实现与单元测试

1、在产品详细设计完成后，开发工程师依据设计进行编码工作；

2、编码完成后，开发工程师编写单元测试案例并进行单元测试，单元测试完成后提交单元测试报告；

3、项目经理根据项目实际情况对开发工程师编写的代码组织Code Review，记录相关问题；

4、产品模块单元测试完成后，开发之间进行产品联调测试，并修改所发现问题以及提交联调测试报告；

5、产品初步完成后，在提交测试前进行一次产品演示，参加人员包括开发经理、项目经理、测试负责人、开发工程师、测试工程师、售前工程师与售后工程师，在演示的过程中对产品提出改进建议；

6、各模块负责人对Code Review以及产品展示所发现的问题进行修改，相关的代码与文档commit到CVS；

7、项目经理对编码完成后的系统进行确认，确保提交测试的系统是可运行的，测试负责人（或专门的PPQA）确认所有文档和代码都已经commit到CVS。

六、测试设计与评审

1、 在项目编码阶段，测试方案编写完成后，测试负责人或相关测试人员根据测试方案、规范文档、功能列表和详细设计进行测试用例设计；

2、 测试案例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试案例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；

3、 在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；

4、 测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；

5、 开发经理、项目经理、相关开发人员和测试人员对所提交的测试案例进行审查，开发经理与项目经理对测试案例进行总体性的检查，各模块负责人则负责检查自己所负责的测试案例，将建议和意见以邮件的形式反馈给测试负责人；

6、 测试负责人收集大家的邮件对测试案例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试案例commit到CVS；

7、 测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试案例必须配套修改更新；在测试过程中发现设计测试案例时考虑不周，需要对测试案例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试案例存在漏洞造成，也需要对测试案例进行完善；

8、 测试负责人（或专门的PPQA）对最终修改测试案例进行检查，并确认所有文档都已经commit到CVS。

七、测试实施

1、代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；

2、测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；

3、测试人员按照预定的测试计划和测试方案逐项对测试案例进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；

4、每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试测试计划与可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；

5、开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；

6、开发对bug进行修改；

7、开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；

8、产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；

9、确认测试，在软件发布前，对产品进行确认测试；

10、当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。

八、产品发布

当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，在发布前对照功能列表进行一次全面的确认测试，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：（1） 产品安装操作手册;（2） 产品白皮书;（3） 产品管理维护手册;（4） 用户操作手册;（5） 总体测试报告（6）性能测试报告。

九、版本控制

在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。

十、自动测试

产品稳定后，进行自动测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。

十一、小结：应用推广思路与体会

整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。

这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。 在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座沟通的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。不过这种测试与开发的模式，对测试负责人的要求很高，不但要求测试负责人具有很强的责任心与沟通协调能力，而且还需要具有很高的业务分析能力和CMMI5实施经验。