CMMI基本流程

cmmi中的变更流程

1. 变更请求

- 任何相关人员(开发人员、测试人员、项目经理等)都可以提出变更请求

- 变更请求应包括变更原因、预期结果和潜在风险等详细信息

2. 变更评审

- 由变更控制委员会(CCB)对变更请求进行评审

- 评审过程中需要考虑变更的必要性、可行性、成本和风险等因素

3. 变更批准

- 如果变更请求获得批准,CCB将指定负责人员实施变更

4. 变更实施

- 按照既定的变更计划执行变更

- 需要进行适当的测试,以验证变更的正确性和完整性

5. 变更验证

- 在实施变更后,需要对变更进行验证,确保满足预期要求

6. 变更发布

- 如果验证通过,则可以将变更正式发布到生产环境中

7. 变更追踪

- 对变更的全过程进行记录和跟踪,以供将来审计和改进

8. 变更后评审

- 在变更完成后,对变更的效果和过程进行评审

- 根据评审结果提出改进建议,以优化后续的变更管理

以上是cmmi中规定的变更流程的一般步骤。在实际执行中,不同组织可能会根据自身情况对流程进行适当调整和完善。

专家谈CMMI认证

前不久，恰遇市计算机协会资深专家刘老师，交谈中说起CMMI认证的目的和过程，刘老师以自己的体会和理解作了较详细的介绍，现将部分内容摘要如下。

问：CMMI的目的是什么?

刘老师：CMMI的目的是提高研发（还可以拓展到其它业务的项目管理）的能力和成熟度。认证只是一个表达而已。如果一开始就只是考虑过级，长远来讲，往往会发现是非常浪费的，因为钱花了，证拿到了，但是效率没有提高。

首先要注意的是技术水平和过程成熟度的区别。一个技术很高的团队，未必就是过程成熟的。技术可以通过个人能力达到。过程的目标，是把员工的效率管理好，达到一个能够在不同情况下重复成功，并且不断地能够积累经验，提高效率，以达到能够在最短的时间，最低的成本开发出高质量的产品，来更好地满足市场和客户。

当然，这个需要一段时间。这是过程，不是流程。流程可以立刻使用，但不能保证生效。过程是一个制度，是管理理念、思维、习惯的改变，所以需要时间，但长远来说，生产力和质量的提高，是深远实际的，是远远比单依靠个人能力大得多。而且，没有有效的过程，个人能力的提高是有限的。贝尔实验室认证的时候，有过一句话，“I

can be as good as the superior allows me to be!”这就是说，不良的过程，也可以是进步的一个障碍。反过来说，有效合理的过程，可以通过有效管理技术，促进员工个人能力的提高。 问：什么是CMMI？

刘老师：CMMI(Capability Maturity Model Integration),是能力成熟度模型集成，本质是软件管理工程的一个部分。CMMI的版权，属于SEI（Carnegie Mellon University 属下的Software

Engineering Institute）。SEI有一批认可的传递伙伴（transition

partner），他们是一些在SEI登记的咨询公司。留意，不是每一个咨询公司都是SEI的传递伙伴。这些传递伙伴公司提名一些主任评估师，经过SEI的训练和观察，就可以按CMMI的要求，使用一个叫做SCAMPI的评审方法，判断企业的成熟级别。

软件开发流程

软件项目生命周期模型

需求分析

需求分析流程图

需求分析客户部门经理临时项目组输入/输出EPGQA测试负责人PM开始6、确定项目管理机制14、协调人员及资源项目日程表15、建立工作环境项目计划书17、编制项目日程表5、审批裁剪16、编制项目计划书4、申请裁剪1、组建临时项目组11、确定项目目标范围13、确定项目关键参数结束项目裁剪表2、制定需求阶段日程表12、项目估算规模估算表/项目估算表3、建立配置库18、评审项目计划书19、建立阶段基线20、阶段总结需求分析阶段总结报告需求分析阶基线7、编写需求清单列表需求清单列表10、确认需求规格书8、确定系统架构/编写需求规格书架构设计书/需求规格书9、评审架构设计书/需求规格书过程描述

1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。

3、PM指示配置管理员建立配置库。

4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。

5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。

6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。

7、项目组人员与客户进行沟通，编写需求清单列表。

8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。

➢ 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。

➢ 关于自行开发和采购复用的分析，

如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；

cmmi软件开发流程

软件开发流程

软件项目生命周期模型

质量目标

14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。

15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。

16、PM、测试负责人编制项目计划书。

17、PM、测试负责人编制项目日程表。

18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。

19、PM指示配置管理员建立配置基线。

20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

设计

设计流程图

PM项目组配置管理员输入/输出1、组织项目组成员学习需求调研报告结束开始2、组织人员明确设计约束3、系统功能设计6、组织人员评审设计文档8、建立阶段基线9、组织召开阶段会议5、系统外围设计C、设计说明书H、会议纪要A、需求规格书B、架构设计书过程描述

1) 项目经理组织项目组人员学习需求规格书；

2) 项目经理组织项目组中的开发人员确定设计约束，这些约束可能包括一下几个方面：

➢ 需求约束，需求规格书中约定的设计约束；

➢ 隐含约束，需求规格书中没有，但对系统的设计或者使用带来潜在影响的特殊约束。

3) 项目经理及开发人员根据需求规格书、架构设计书进行设计，编制《设计说明书》。

➢ 基于对业务和现有系统结构的理解，划分/调整系统模块。

➢ 描述各系统模块协作实现各业务场景的处理流程(可用序列图)。

➢ 必要时(通常要反复几轮)，修正系统模块划分和处理流程。

➢ 描述各处理流程中的各活动的输入、处理、输出和可能的异常。

➢ 系统模块构成及其相互关系。(可用类图、包图。)

➢ 系统模块内部设计。(功能、管理的数据、对外的服务、对内的服务,要求明确各模块的对外接口。)

4) 开发人员根据《需求规格书》、《架构设计书》进行设计、《设计说明书》进行用户界面和数据库以及接口等方面的详细设计，纳入《设计说明书》。