上个月有幸参加了公司为期一个月的CMMI的模拟项目试点.               

      首先高兴有这个机会参加公司这次CMMI的情景模拟实验，在这几个星期期间感谢EPG组的各位专家组成员孜孜不倦的给我们培训和指导。 

      
这次的情景模拟实验之前，很多一些概念是比较模糊或者是还只是听说而已，而没有真正的理解。同时这次培训，让我了解到CMMI的核心思想是过程和管理的持
续改进，使企业按正确的流程去做正确的事。CMMI告诉我们软件开发过程中有哪些内容，需要做些什么、出些什么文档。而至于具体怎么做、文档里面怎么写则
不会有明确的规定。               

   
 个人感觉上，实施CMMI主要还是观念上的转变，就是平心而论，我觉得CMMI在公司实施还是有一定阻力的。最常见的估计肯定就是文档太多了流程复杂
了，需要记录的信息更多了。肯定会延长开发时间，那么公司会不会延长开发时间，延长多少呢，个人觉得会比较适合大的项目，在一些小的项目中，经常是一人身
兼多职，一个人充当多个角色，会给这些文档压得透不过气来，如果在大的项目中，各自做好自己的角色，那么完成的工作，写出的文档质量也就比较高了。像我们
开始前2个星期做情景模拟实验的时候，心情很激动。大家积极性比较高，不知道CMMI原来是个猛兽，2个星期下来，参加了好几个角色的培训，要写一大堆文
档，本来开发人员可能就是不喜欢写文档。2个星期后就比较疲惫了，下次如果准备这种情景模拟，分2个不同的组来实施可能效果会更好。        

        
还有一个就是通过这次情景模拟，对需求管理和需求变更的概念有一些了解，比如明确了变更的概念，以及指明了变更控制的方向。以前在开发的时候，我们开发人
员有时候经常和业务人员抱怨，这到底是不是客户的真实需求啊。有时候业务人员也不明白这个需求是从哪里来的。还有一个就是市场人员和开发设计部的矛盾，市
场人与需要拿单，拿到的单，开发设计部能不能做出来。前段时间我们财保在做第一阶段的一个功能的时候，分支机构的市场人员要求我们一个星期完成某个功能，
急着要给客户演示，但是当时是很多东西未准备好，这样我们开发人员就加班加点的赶出来了，赶出来后，分支机构那边确过了一个星期才给客户演示，演示后发现
与客户实际需要的有些差异，如果不是我们催要反馈结果，可能还会再推一段时间。所以觉得市场人与也应该参与CMMI的流程会不会更好些呢，尤其是需求管理
的流程。              

       再就是希望能有一些专业工具能辅助CMMI的工作，最后发现很多软件管理知识自己很薄弱.       

CMMI(Capability Maturity Model Integration)即能力成熟度集成模型，主要包括过程管理、项目管理、软件工程、过程支持等几个大的过程。

参加公司为期2周的模拟培训 ，时间：2008-05-23 星期五

担任角色：Project Manager

此次共有的角色有: 项目经理、业务人员、设计人员、测试人员

CMMI说明了软件开发中都包括了那些活动，需要做什么，出什么文档。至于具体怎么做、文档的具体内容是什么则没有明确的规定。各公司和项目组根据实际需求来进行裁剪过程。可以说CMMI是一个比较灵活的体系。而公司此次实施CMMI的目的是为了提高软件的质量，并不是为了过级而实施CMMI，所制定的模板要充分考虑公司的实际情况。既要过级也要提高软件质量

此次模拟实验

以最近做的项目“山西财产保险”为例子做模拟实验

以下是此次培训和模拟实验的一些心得,只做备忘供以后工作需要.

先解释一些名词：

项目

项目是一系列的活动，具有特定的目标，在该目标达成之后项目结束，每一个项目都是独立的。

项目的要素：

–  目标、应用、技术、规模、历时

–  客户、项目组

PM工作的重点

         立项 -- 填写《***项目立项通知书.doc》

         工作分解 --《***项目项目过程定义.doc》

         做项目估算 --《***项目估算.xls》

         项目计划 --《***项目计划书.doc》

         进度计划 --《***项目进度计划.mpp》

立项

         主要填写项目名称、项目背景、项目目标、外部干系人、交互用户产品、术语

         项目范围、特性、成员、风险、相关文档

外部干系人：

         像我公司设计是由设计部来做的，那么设计部的那个设计人员就是我们外部干系人。

能制约、改变项目的过程。

工作分解

         分为工程类、管理类、和支持类，这边主要的工作就是根据项目的实际情况。做一些过程裁剪。每个过程都会分解成几个步骤来完成。对于裁剪的步骤需要说明裁剪理由。

         工程类

                   测试过程

                   测试设计规程

                   缺陷处理规程

                   需求开发

                   需求管理

                   架构设计过程

                   概要设计过程

                   编码实现过程

                   详细设计过程

                   产品集成过程

管理类

         项目立项过程

         项目计划过程

         项目估算过程

         项目监测与控制

         分析管理

支持类

         配置管理过程

         通用类产品发布过程

         基线发布规程

         变更控制规程

项目估算

         主要是规模估算、功能点估算、工作量与工期估算、成本、关键计算机资源估计。

项目计划

         项目概述、术语、角色、生命周期模型、项目阶段、里程碑、关键资源估计、项目风险、配额管理、知识技能需求、培训计划、质量保证计划、测试计划、相关文档、参考资料

进度计划

         进度计划主要是用Microsoft Project来做，主要根据项目过程中定义的过程和项目计划来制定进度计划。进度计划中需要填写任务名称、工时、工期、实际公工时、前置任务、开始时间、结束时间

         在项目实行过程中不断填充内容（比如实际工时）。每月的周报可以从进度计划中获取数据。比如挣值图(图略) 

总工作量偏差图(图略)

测试人员

需要填写《测试报告》、《测试计划》、《测试用例》

需求人员

需要填写《产品需求规格说明书.》《功能设计文档》、《客户需求说明书》、《需求调研报告》、《需求变更模板》

设计人员

需要填写《案情导入类图.oom》、《案情导入序列图.oom》、《财保系统数据库er图》、《山西财保系统数据库设计说明书》、《山西财保详细设计文档》

项目周报

         项目周报最好做成PPT的方式、数据从各个文档里面取得数据来做。优点是很直观的了解项目的本周进展。缺点是比较花费时间。

QA

         质量管理、质量管理人员是独立于项目组的。质量管理人员直接上司是质量管理部经理。

质量管理人员需要做好质量跟踪。把每月的跟踪数据给项目经理。项目经理可以利用此数据放在项目周报中。