CMMI软件生命周期模型选用指南(共9页)

1、精选优质文档-倾情为你奉上编码：生命周期模型选择指南专心-专注-专业修订历史序号版本号更改时间更改内容描述填写人目 录1 目的描述适合公司现状、可供项目选择的组织级生命周期模型。2 适用范围公司所有软件项目。3 模型介绍3.1 瀑布模型3.1.1 模型说明图1 瀑布模型对于需求比较明确的项目，可以使用瀑布模型进行项目开发，每个阶段的输入都是依靠上一个阶段的输出，每个阶段内都需要完成与最终产品相关的所有工作。3.1.2 模型分析优点：1. 可以明确划分项目的各个阶段，便于管理；2. 项目成员只需要在被安排的阶段开展项目工作，不需要全程参与；3. 阶段工作内容清晰，降低了开发难度。缺点：1. 对项

2、目的启动条件要求较高；2. 如果出现需求不明确或设计开发技术瓶颈，将会影响后续阶段的工作启动；3. 最终产品提交给用户确认的时间比较晚，存在一定的风险。3.2 迭代模型3.2.1 模型说明图2 迭代模型通常有许多项目不能在需求开发阶段提供准确的需求，对于这样的项目，可以选择迭代开发模型，将能够确定的需求分析确定下来。之后便可以对这部分确定的需求进行系统设计、编码和测试。整个项目可以进行多次迭代的过程，一般情况下迭代的起点从需求开发开始，然后进行设计、编码和测试，但是有时候也可能出现从设计或编码阶段安排新的迭代过程。3.2.2 模型分析优点：1. 项目的启动条件比较灵活、只要用户有基本的立项意向

3、和需求范围就可以开始计划工作；2. 可以在项目早期识别和管理风险；3. 可以较快的展示项目开发的成果，有益于增强客户授信度和满意度。缺点：1. 迭代过程和范围划分比较复杂，项目的过程管理难度较大；2. 产品的设计开发是迭代过程完成的，容易出现产品构件兼容性问题，如果处理不当会出大量返工的工作。3.3 精简模型3.3.1 模型说明图4 精简模型1图5 精简模型2对于一些规划较小、版本升级、或者是有大量可复用构件的项目，这些项目需求相对比较明确、产品架构比较成熟和稳定，因此可以选择精简生命周期模型。根据项目的不同情况：可以将设计阶段和编码阶段精简为一个工程阶段（如图4）；也可将需求开发阶段和设计阶

4、段精简为一个阶段、将编码阶段和测试阶段精简为一个阶段（如图5）。3.3.2 模型分析优点：1. 缩短开发周期、降低各阶段工作的衔接工作；2. 可以一定程度降低项目的成本。缺点：1. 如果精简方式选择不合理，可能会造成产品质量降低。4 模型选择4.1 模型选择原则1. 不会降低项目开发过程和工作产品的质量；2. 不会降低工程师的开发效率；3. 项目资金是否可以控制在目标成本范围内。4.2 项目分类项目类别金额（万元）项目周期(月）总工时（人月）需求明确程度需要应对的主要风险项目管理的重点管理级别A100125070任意主要是需求不明确和进度风险，人员的项目工时安排受到限制，容易在项目关键点出现生

5、产力和关键资源缺失的现象。按期按质实现项目目标，锻炼队伍、固化管理，协调资源，解决风险问题，积累客户需求，提供确定类型客户需求解决方案管理级别B50100683050任意主要是需求变更风险和进度风险按期按质实现项目目标，锻炼队伍、固化管理，协调资源，解决风险问题，积累客户需求，提供确定类型客户需求解决方案。管理级别C3050461530任意主要是需求变更风险和进度风险实现客户需求，维护客户满意度。进行前瞻性技术研究，完成科研成果向应用的转换。锻炼队伍，发现新的项目目标和机会。管理级别D103023515任意主要是需求变更风险和进度风险实现客户需求，维护客户满意度，锻炼队伍，发现新的项目目标和机

6、会。管理级别E1015任意主要是需求变更风险和进度风险锻炼队伍，维护客户关系，发现新的项目目标和机会4.3 模型选择指南目前公司大多数项目是由JZERP2.2延伸出来的项目，这类项目采用JZERP2.2这一比较成熟的架构，客户的需求相对比较明确，因此建议在以上项目分类中：管理级别B和管理级别C可以采用“精简模型1”；管理级别D和管理级别E可以采用“精简模型2”；而管理级别A的项目建议采用“迭代模型”对非JZERP2.2延伸的项目，可复用的产品构件较少，产品架构不够成熟，客户的需求也不够明确，因此建议：管理级别A和管理级别B采用采用“迭代模型”；管理级别C和管理级别D采用采用“快速原型模型”；管理级别E可以采用“精简模型1”。如果出现项目管理级别在C、D、E中，而且项目需求在项目启动阶段已经很明确，可以选择“瀑布模型”。对于规模小，需求简单，功能单一的项目，建议采用瀑布模型。 对于规模比较大,