2023年12月22日发(作者：泉英奕)
过程管理类
生命周期模型
编写
审批
文档版本
编写时间
审批时间
V 1.0
XXX有限公司 版权所有
文档中的全部内容属量子通信所有，
未经允许，不可全部或部分发表、复制、使用于任何目的。
OPD-GUID-2-生命周期模型
文档修订摘要
日期
修订号
描述
著者
审阅者
日期
XXX有限公司 版权所有
文档中的全部内容属量子通信所有，
未经允许，不可全部或部分发表、复制、使用于任何目的。
OPD-GUID-2-生命周期模型
目 录
1
导言 ............................................................... 3
1.1
1.2
1.3
2
3
4
目的 .......................................................... 3
范围 .......................................................... 3
术语和缩略语 .................................................. 3
过程综述 ........................................................... 3
主要角色及职责 ..................................................... 4
主要阶段描述 ....................................................... 4
4.1
瀑布模型（waterfall model） ................................... 4
4.1.1
立项阶段 ................................................. 5
4.1.2
需求分析和项目策划阶段 ................................... 5
4.1.3
设计阶段 ................................................. 7
4.1.4
编码和单元测试阶段 ....................................... 9
4.1.5
集成测试和系统测试阶段 .................................. 10
4.1.6
验收和实施阶段 .......................................... 11
4.1.7
售后维护 ................................................ 13
4.1.8
裁剪指南 ................................................ 13
4.2
迭代模型（iterative model） .................................. 15
4.2.1
典型生命周期描述 ........................................ 15
4.2.2
裁剪指南： .............................................. 16
4.2.3
生命周期各个阶段描述 .................................... 16
4.2.4
里程碑和基线 ............................................ 20
4.2.5
项目生命周期模型的选择 .................................. 20
4.2.6
选择迭代模型 ............................................ 20
4.2.7
软件生命周期模型的应用 .................................. 21
4.2.8
输出 .................................................... 21
4.3
敏捷模型（Agile model） ...................................... 21
4.3.1
典型生命周期描述 ........................................ 21
4.3.2
生命周期各个阶段描述 .................................... 22
XXX有限公司 第 1 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.3.3
里程碑与基线 ............................................ 25
4.3.4
项目生命周期模型的选择 .................................. 25
4.3.5
选择敏捷模型 ............................................ 26
4.3.6
裁剪指南 ................................................ 26
4.3.7
软件生命周期模型的应用 .................................. 26
4.3.8
敏捷实践 ................................................ 26
4.4
原型模型（prototyping model） ................................ 35
4.4.1
咨询立项 ................................................ 35
4.4.2
需求分析、项目策划、快速设计和原型评审 .................. 36
4.4.3
最终系统设计-概要设计与详细设计 ......................... 38
4.4.4
最终系统实现-编码和单元测试 ............................. 40
4.4.5
集成测试和系统测试 ...................................... 41
4.4.6
验收和实施 .............................................. 42
4.4.7
售后维护 ................................................ 43
4.4.8
裁剪指南 ................................................ 44
XXX有限公司 第 2 页 / 共 46 页
OPD-GUID-2-生命周期模型
1 导言
1.1 目的
该文档为公司的项目确定合适的生命周期提供指导，说明公司项目对应的软件生命周期的描述。
1.2 范围
本文档适用于XXX有限公司。
1.3 术语和缩略语
EPG ： Engineering Process Group 工程过程组。
2 过程综述
该过程阐述了公司最具代表性的项目类型特性，以及他们所对应的软件生命周期描述。这三种项目类型分别为：开发类项目，维护类项目，升级类项目。同时又着重对开发类项目中的瀑布模型和迭代模型进行了详细描述。
开发类项目是指公司新承接的，由客户方提出的，有明确需求的项目，或由公司自主立项的新项目。该类项目一般有比较完整的软件生命周期，也可能根据项目的具体情况将其中几个阶段合并或拆分。
维护类项目是指对公司原有开发完毕的已发布的项目进行维护，维护的需求可能来自客户提交的问题报告单，也可能来自公司内部测试人员提交的在发布时没有解决的问题报告单。
升级类项目是指公司对原有开发完毕项目进行的后期开发项目，后期开发的主要内容可能包括前期项目的缺陷修复、功能增强、新功能等等。
XXX有限公司 第 3 页 / 共 46 页
OPD-GUID-2-生命周期模型
3 主要角色及职责
角色
高层经理
EPG组长
EPG成员
职责
批准裁剪后的软件生命周期
评审并批准裁剪原因和裁剪结果
参与评审批准裁剪原因和裁剪结果
确定项目特性数据，根据项目特性数据选择合适项目经理 的软件生命周期，并确定具体的过程及过程之间的关系
协助项目经理选择合适的软件生命周期，并帮助项目组关键成员
确定其中具体过程及过程之间的关系
备注
4 主要阶段描述
根据软件工程和公司项目的实际情况，主要对项目的瀑布模型、迭代模型、敏捷模型分别描述。
各个项目可以根据项目的需求特点，开发周期，团队规模，团队技术水平以及应用的重要程度等项目的特性数据来选择适合自己项目的软件生命周期。
4.1 瀑布模型（waterfall model）
瀑布模型，从上一项活动接收该活动的工作对象做为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，做为输出传给下一项活动，对该项活动实施的工作进行评审，若其工作得到确认，则基线下一项活动，否则返回前项，甚至更前项的活动进行返工。
瀑布模型的优点是，通过设置里程碑明确每阶段的任务与目标，通过阶段评审，将开发过程纳入正确轨道，严格的计划性保证软件产品的按时交付。缺点是瀑布模型缺乏灵活性，不适合需求模糊的项目；返回上一级的开发需要十分高昂的代价。
选择瀑布模型的项目一般是需求比较稳定，项目周期比较长，团队技术水平比较高的项目。
根据公司项目情况，我们利用瀑布模型将整个软件项目生命周期过程划分为：咨询立项、需求分析和项目策划、概要设计与详细设计、编码和单元测试、集成测试和系统测试、验收和实施、售后维护7个主阶段。
XXX有限公司 第 4 页 / 共 46 页
OPD-GUID-2-生命周期模型
咨询
立项
需求分析项目策划
概要设计
详细设计
编码和单元测试
集成测试系统测试
验收
实施
阶售后
维护
4.1.1 立项阶段
参见《立项管理过程定义》中的内容。
4.1.2 需求分析和项目策划阶段
需求分析和项目策划阶段的目标可分两方面来描述：
通过对系统功能、性能指标、可靠性等多方面分析陈述、结合客户实际业务需求，生成一个能够正确说明客户所有需求的标准化需求文档。在需求分析方面主要工作是需求提炼与分析、需求归档、需求评审等。
根据已评审通过的需求文档，同时根据经验数据（组织过程能力基线及项目数据），XXX有限公司 第 5 页 / 共 46 页
OPD-GUID-2-生命周期模型
估算软件开发进度、软件开发经费及其他相关因素，制定相关项目管理计划。
需求分析时间占开发时间的20%－35%左右；
采用的成熟软件技术必须占80%以上；
4.1.2.1 角色职责
角 色
高层经理
职责
根据情况参与需求规格说明书评审
负责审批项目开发计划
负责组织需求规格说明书评审
负责编制项目计划
负责组织编制配置管理计划、质量保证计划、测试计划、度量与分析计划等
负责组织项目所有管理计划的评审工作
负责组织编制需求规格说明书
相关人员参与评审需求规格说明书
参与项目计划的编制，对各自任务做出承诺
按要求完成编制需求规格说明书
负责编制配置管理计划
参与项目计划的编制，对自己任务做出承诺
按计划建立配置环境，建立基线目录
做本阶段配置审计、配置统计报告
参与需求规格说明书评审
负责编制质量保证计划
参与项目计划的编制，对自己任务做出承诺
审计本阶段过程、工作产品，形成QA报告及相关文档
参与需求规格说明书的评审
开始着手测试用例的编写
负责编制软件测试计划
参与项目计划的编制，对自己任务做出承诺
参与需求规格说明书的评审
按要求开始测试用例编写工作
参与软件测试计划的编制，对各自任务做出承诺
配合项目经理完成需求规格说明书，并确认
项目经理
项目组成员
配置管理员
PPQA
测试经理
测试人员
客户经理/代表（销售经理）
4.1.2.2 输入
《立项建议书》
《项目任务书》
项目人员和资金
4.1.2.3 输入准则
《立项建议书》通过审批；
XXX有限公司 第 6 页 / 共 46 页
OPD-GUID-2-生命周期模型
《项目任务书》下发；
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能；
项目资金到位。
4.1.2.4 活动和任务
根据组织级《项目已定义过程裁剪指南》裁剪或重新定义为《项目已定义过程》；
《项目已定义过程》由项目经理申请，经过EPG审批；
根据需求开发的计划与客户联系进行需求获取；
根据获取的客户原始需求，形成《用户需求说明书》；
根据《用户需求说明书》，结合现有软件产品系统，形成《需求规格说明书》，必要时建立系统原型；
项目经理组织相关人员评审《需求规格说明书》，跟踪评审问题直到修改完成；
在《需求规格说明书》开始编写并完成评审过程中，测试负责人组织人员考虑测试用例的编写工作；
根据《项目任务书》、《立项建议书》、《用户需求说明书》拟订项目计划；
根据评审通过的《需求规格说明书》细化并制定估算记录、WBS、项目计划及相关计划，如：《配置管理计划》、《质量保证计划》、《度量与分析计划》、《测试计划》等；
项目经理组织评审项目计划及相关计划。
4.1.2.5 输出准则
以上所有文档或计划通过评审或审批
4.1.2.6 输出
《用户需求说明书》(可裁剪)
《需求规格说明书》
《需求跟踪矩阵》
《项目计划》（附《估计记录》、《WBS分解》）
《质量保证计划》
《配置管理计划》
《度量与分析计划》
4.1.3 设计阶段
概要设计阶段是从实现的角度开发针对客户需求的解决方案，完成软件的架构设计和XXX有限公司 第 7 页 / 共 46 页
OPD-GUID-2-生命周期模型
数据库设计，详细设计是从架构设计和数据库设计入手，完成模块的详细设计或界面设计。
软件需求分析和软件设计的时间占研制周期的15－20％左右；其中软件设计时间约占7％－10％。；
4.1.3.1 角色职责
角 色
高层经理
职责
根据情况参与架构设计说明书、数据库设计说明书评审
根据情况参与模块详细设计或界面设计
负责组织设计说明书评审
负责组织编制架构设计、数据库设计说明书
负责协调项目内、外工作
负责审核本阶段QA、CM活动
相关人员参与评审设计说明书
按分配工作做设计说明书
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
组织编制测试用例
按要求开始测试用例编写工作
项目经理
项目组成员
配置管理员
PPQA
测试人员
4.1.3.2 输入
《立项建议书》
《项目任务书》
《用户需求说明书》
《需求规格说明书》
《项目计划》
4.1.3.3 输入准则
以上文档通过评审或审批
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能
项目资金到位
4.1.3.4 活动和任务
项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》，按照AD过程描述，进行概要设计，编制《概要设计说明书》。
项目经理组织人员评审《概要设计说明书》。
开发接口设计。
项目经理或项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》、《概要设计说明书》，编制《数据库设计说明书》。
XXX有限公司 第 8 页 / 共 46 页
OPD-GUID-2-生命周期模型
项目经理组织人员评审《数据库设计说明书》。
根据评审通过的《概要设计说明书》和《数据库设计说明书》，项目经理组织人员，针对每个模块完成相应的《详细设计说明书》。
项目经理组织人员评审《详细设计说明书》。
4.1.3.5 输出准则
以上文档通过评审
4.1.3.6 输出
《概要设计说明书》
《接口设计说明书》（根据项目需要可合并到设计文件中）
《数据库设计说明书》（没有数据库需要的项目可裁剪该产品及过程）
《详细设计说明书》
4.1.4 编码和单元测试阶段
根据软件详细设计，完成软件编码、单元测试和集成；
本阶段进度占总生命周期的15－35%左右
采用的成熟技术必须占80%以上
4.1.4.1 角色职责
角 色
高层经理
职责
根据情况参与代码走查
负责组织代码走查
负责协调项目内、外工作
负责审核本阶段QA、CM活动
负责分配编码工作
负责分配单元测试工作
协调代码走查
组织需求变更管理
完成分配的编码工作
完成分配的单元测试任务
参与代码走查
编写部署说明
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
按要求对所负责的模块做单元测试接收工作
项目经理
项目组成员
配置管理员
PPQA
测试人员
4.1.4.2 输入
《需求规格说明书》
《概要设计说明书》
XXX有限公司 第 9 页 / 共 46 页
OPD-GUID-2-生命周期模型
《详细设计说明书》
4.1.4.3 输入准则
软件设计说明书通过评审和批准；
相关人员到位，并接受过相关技能的培训或达到技能要求。
4.1.4.4 活动和任务
项目经理组织相关人员，根据《需求规格说明书》和《概要设计说明书》或《详细设计说明书》，分配相关程序员完成所有软件单元的编码工作；
完成编码后，项目经理组织项目成员之间进行编码的单元测试工作；
项目经理组织相关人员，对编码进行走查，覆盖范围必须大于等于60%；
项目经理组织相关人员编写《产品集成策略》。
4.1.4.5 输出准则
完成所有模块的编码工作
完成所有模块的单元测试报告
4.1.4.6 输出
软件代码
单元测试报告
4.1.5 集成测试和系统测试阶段
验证客户需求是否都已经实现
本阶段进度占总研发生命周期的10％－20％。
4.1.5.1 角色职责
角色 职责
负责制定和维护测试计划
负责设计测试过程
对执行测试负责
负责协调资源，评审测试用例，验证测试环境
搭建测试环境，执行单元测试， 集成测试和系统测试，记录测试结果，填写测试问题报告单， 编写测试驱动程序。
参与测试计划及用例的评审，协调处理测试问题报告单，评审测试总结报告。
负责问题和缺陷修复工作
参与测试过程中产生的关键工作产品的评审。
测试负责人
测试人员
项目经理
软件工程师
评审人员(项目经理, 质量保证员, 系统分析员等)
XXX有限公司 第 10 页 / 共 46 页
OPD-GUID-2-生命周期模型
软件验收小组(咨询顾问, 项目经理, 质量保证员, 测试负责人等)
4.1.5.2 输入
《测试计划》
《集成测试用例》
《系统测试用例》
发布程序
《单元测试报告》
《产品集成策略》
4.1.5.3 输入准则
测试用例通过评审
代码完成并通过单元测试
4.1.5.4 活动和任务
制定验收测试计划书, 实施验收测试, 编写验收测试报告。
按照《测试计划》和《产品集成策略》，搭建集成测试环境；
执行集成和系统测试；
记录测试结果，填写测试问题报告单提交给项目组人员修改；
对修改过的版本进行回归测试；
总结测试结果并编写测试报告。
4.1.5.5 输出准则
通过集成测试和系统测试，并完成回归测试。
4.1.5.6 输出
缺陷记录
测试报告
4.1.6 验收和实施阶段
在验收阶段，系统安装在目标环境中，并在这个环境中进行测试，以确保它满足系统要求，客户满意验收。
进度周期占研发生命周期的10%－20%
4.1.6.1 角色职责
角色 职责
XXX有限公司 第 11 页 / 共 46 页
OPD-GUID-2-生命周期模型
项目经理
现场实施人员
技术支持人员
测试人员
配置管理员
4.1.6.2 输入
产品里程碑报告
基线发布报告
测试总结报告
制订实施计划。
负责组织编写用户手册或操作手册
组织和协调用户参与项目实施过程
对用户的反馈意见和新需求分类整理，并与用户协商，提出修改意见
填写验收报告
参与编写用户手册或操作手册。
参与初始化基础数据，和必要的业务数据。
培训用户使用应用系统，包括帮助用户理解使用系统，讲解业务操作步骤，解答用户问题。
协助用户验收测试。
收集用户的反馈意见，记录用户新需求。
安装和调试软硬件，部署应用系统。
监测应用系统运行状况。
及时修改程序，解决现场实施中的问题。
配合数据初始化工作。
参与编写用户手册或操作手册。
根据实施计划和用户现场情况，部分或全程参与培训用户工作。
提供正确版本的文档和产品，确保文档、产品之间的完整性和一致性。
配置审计通过的软件产品和程序包
4.1.6.3 输入准则
软件产品的开发已经完成；
通过集成测试和系统测试；
完成测试总结和配置审计。
4.1.6.4 活动和任务
进行实施准备，制定实施计划，编写用户手册或操作手册、培训手册等；
安装系统环境，进行数据初始化；
按照客户要求配合客户进行验收测试或试运行；
验收测试通过，客户接收系统，签订用户验收报告。
4.1.6.5 输出准则
客户接受系统，验收通过
XXX有限公司 第 12 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.1.6.6 输出
《用户手册》（可裁剪）
《验收报告》
4.1.7 售后维护
本阶段可以裁剪。
在维护期间，对于客户提出的系统交付使用后出现的问题进行修改和维护。
维护时间一般为1年左右。
4.1.7.1 角色职责
角 色
高层经理
客户经理
项目经理
项目维护人员
4.1.7.2 输入
用户验收报告
4.1.7.3 输入准则
系统已经通过客户验收
4.1.7.4 活动和任务
按合同签订的维护服务期和任务进行系统维护；
维护期满项目过程中的所有配置项应纳入资产库。
4.1.7.5 输出准则
到达合同签订的维护时间，完成维护任务
客户提出的问题已经得到解决或和客户达成一致协定。
4.1.7.6 输出
《维护记录》
职责
负责项目人力、物力等资源的保障和管理；
负责项目经费使用的审批；
于客户沟通，协助用户方的维护工作
负责维护的管理工作
负责具体的维护工作
4.1.8 裁剪指南
在实际的使用过程中，根据软件项目的特点可以对瀑布模型进行裁剪。
设计阶段中，根据项目实际情况需要，可以选择概要设计和详细设计只做一种，如果概要设计完成了，可以选取其中需要的部分做详细设计；
XXX有限公司 第 13 页 / 共 46 页
OPD-GUID-2-生命周期模型
集成测试、系统测试阶段合并成一个阶段，称为测试阶段。活动和工作产品也作相应合并；
如非有必要，售后维护阶段可以整个裁剪；
根据项目的人员配置情况，在有替代的活动来验证相应工作产品的可测试性时，测试计划和测试用例的编制时间可以适当的后延。不过，必须确保测试计划和测试用例经过有效的评审以后，才可以开始实际的测试活动。
根据项目需要，在经EPG审核并获得高层经理的批准下，也可对瀑布模型做出其他方式的裁剪，裁剪内容主要包括：对生命周期各阶段、输入/输出出及相关活动的增加、删除或修改合并，但在裁剪过程中必须遵循以下原则：
1) 阶段衔接原则：
所裁剪的生命周期各阶段间应是相互衔接的。一个阶段的里程碑工作是下一阶段的输入。切忌从需求阶段跳过分析设计阶段直接进入编码实现阶段。
2) 合理性原则：
每个生命周期阶段中所列的各个活动、工作和质量控制点，视项目大小可以合理的增加或合拼。如某些大项目，可增加一些对子项目、子工作产品或子活动的质量控制点；小项目或增补少量功能点的项目可将一些质量控制点加以适当合拼，但在计划中必须对合拼的理由做出说明。
3) 可视化原则：
生命周期各阶段中必须明确列出任务、活动、工作产品与质量控制点。
XXX有限公司 第 14 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.2 迭代模型（iterative model）
4.2.1 典型生命周期描述
迭代模型迭代过程项目策划项目策划迭代过程项目策划需求分析需求分析需求分析系统设计系统设计系统设计编码和单元测试软件集成和集成测试系统测试编码和单元测试软件集成和集成测试系统测试编码和单元测试软件集成和集成测试验收和安装
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。实际上，这个模型可看作是重复执行的多个“瀑布模型”。
要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以两周到四周为适当的长度。
主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
优点：
XXX有限公司 第 15 页 / 共 46 页
OPD-GUID-2-生命周期模型
当需求更好的被理解时，开始开发下一个迭代
测试贯穿与整个产品生命周期
缺点：
过程复杂性增加
有可能使产品开发周期增长
不连贯的需求分析
缺乏自然的设计评审点
风险：
取消本来已经完成的
4.2.2 裁剪指南：
对于一些特殊的软件项目，可以根据实际需要，增加或者减少迭代次数。
4.2.3 生命周期各个阶段描述
基于迭代模型的各阶段描述。
一个项目可以有多个迭代组成，每个跌代根据所处项目阶段不同，它的重点和目标是不同的，所以将软件生命周期根据时间顺序划分为三个阶段：立项阶段、迭代阶段、交付阶段，每一个阶段可以有一到多个迭代组成。
立项阶段
立项阶段
1、 确定项目的软件范围和边界条件
目标
2、 识别出系统的关键用例
3、 估计整个项目需要的费用和时间安排，给出第一个迭代的详细计划
4、 评估项目风险
1、建立系统的业务模型
2、 捕获系统的基本需求
3、 确定系统的边界
主要活动 4、 识别关键任务
5、 确定系统验收标准
6、 进行项目风险评估
7、 进行项目资源的估计与效益分析
XXX有限公司 第 16 页 / 共 46 页
OPD-GUID-2-生命周期模型
8、 制定项目开发计划与重要里程碑。
重点
里程碑
确定项目目标。如果需要构造原型系统，则需做一些设计与实现。
生命期目标
1、项目目标文档：系统的核心需求、关键特性与主要约束的总体蓝图
2、 初始的项目术语表
制品 3、 初始的风险评估
4、 一个可以显示阶段和迭代的项目计划
5、 一个或多个原型
1、风险承担者是否赞成项目的范围定义、成本以及进度估计。
2、 是否通过主要用例证实对需求的理解。
评价标准
3、 成本与进度预测的评估以及优先级、风险和开发过程的可信度。
4、 所开发软件原型的深度和广度。
5、 实际开支与计划开支的比较。
如果无法达到这些标准，可能取消项目或重新对项目进行仔细的考虑。
迭代阶段
迭代阶段
目标 1、分析用户需求和系统需求
2、 建立系统架构
3、 编制项目计划
4、 淘汰项目中最高风险的元素
5、 通过优化资源和避免不必要的返工达到开发成本的最小化
6、 根据实际需要达到适当的质量目标
7、 对所有必须的功能完成分析设计开发和测试工作
8、 采用循环渐进的方式开发出一个与硬件部门的接口一致的产品
9、 达成一定程度上的并行开发机制
主要活动 1、分析用户需求，确定对关键需求的理解
2、 分析系统需求，捕获并细化关键的功能需求
3、 定义非功能需求
XXX有限公司 第 17 页 / 共 46 页
OPD-GUID-2-生命周期模型
4、 建立坚实的架构
5、 细化架构并建立可执行的软件
6、 根据已定义的评价准则进行软件测试
7、 与硬件部门进行功能和接口联调
8、 精化风险评估
9、 制定过程迭代计划和迭代的评价标准
10、
重点
资源管理资源控制和过程优化
1、需求分析——精化系统范围和需求，揭示任何遗漏的需求
2、 设计——创建稳定的架构
3、 实现——细化架构，构造可以执行的软件
4、 测试——测试架构，测试软件功能
5、 联调——测试软硬接口，测试产品功能。
里程碑 该阶段可以划分为多个迭代实现，在每个交付点建立里程碑，相邻的交付点之间是一个迭代。如果交付点的间隔时间较长（8周以上）则需要将本次交付阶段划分为多个迭代来实现。
制品 1、用户需求说明书
2、 系统需求说明书
3、 概要设计
4、 详细设计
5、 可运行的软件系统
6、 测试用例
7、 用户手册
8、 发布描述
评价标准 1、需求是否与用户达成一致？
2、 系统分析是否全面彻底？
3、 架构是否稳定？
4、 风险要素是否已被处理并可靠地解决了？
5、 每个迭代的计划是否足够详细和精确？
6、 如果在当前架构上下文中执行计划并开发出整个系统，是否所有的风险承担人都同意系统达到了当前的需求？
XXX有限公司 第 18 页 / 共 46 页
OPD-GUID-2-生命周期模型
7、 实际的费用支出与计划支出是否可以接受？如果无法达到这些标准，可能取消项目或对项目进行重新考虑。软件是否足够稳定和成熟，从而可以发布给用户？
8、 是否所有的风险承担人都准备好了向用户交付软件产品？
9、 实际费用与计划费用的对比是否仍可被接受？
10、
交付阶段
交付阶段
目标 将开发完成的系统提交给客户，具体为
1、进行验收测试以期达到最终用户的需要
2、 对最终用户和产品支持人员的培训
3、 和具体部署相关的工程活动
4、 协调Bug，修订改进性能和可用性等工作
5、 基于完整的Vision和产品验收标准对最终部署做出评估
6、 达到用户要求的满意度
7、 达成各风险承担人对产品部署基线已经完成的共识
8、 达成各风险承担人对产品部署符合Vision中标准的共识
主要活动 1、将软件系统部署到用户环境
2、 修复软件的缺陷
3、 编制用户手册和其它文档
4、 培训用户和维护人员
5、 提供用户咨询
重点 主要关注系统的测试和配置工作流。每个工作流关注如下各项。
1、设计——如果验收测试中出现问题，修改设计。
2、 实现——为用户场地裁减软件，修复在验收测试中发现的问题。
3、 测试——在用户现场验收测试。
4、 配置——将软件系统部署到环境中，并配置相应参数。
里程碑
制品
产品发布
1、可运行的软件产品
2、 用户手册
XXX有限公司 第 19 页 / 共 46 页
如果项目无法达到这些要求，必须推迟进入交付阶段。
OPD-GUID-2-生命周期模型
评价标准 1、用户是否认可系统已经成功部署？
2、 用户是否积极使用该软件产品？
3、 用户是否认可产品支持策略？
4、 如果项目无法达到这些要求，必须推迟交付。
4.2.4 里程碑和基线
在各个生命周期阶段结束时对相应的阶段目标建立里程碑。在需求分析和构建阶段的每个交付点建立里程碑，每个迭代启动前确定本次迭代的交付物，在交付物完成或评审通过（如果需要评审交付物）时对该交付物建立基线。
4.2.5 项目生命周期模型的选择
根据生命周期模型的特点，结合项目的具体情况，进行生命周期的选择。
选出项目符合《生命周期选择表》中的哪些类型：需求类型、项目类型、项目风险、用户类型和团队类型（可选一或选多）
参考《生命周期选择表》确定生命周期模型
4.2.6 选择迭代模型
对稳定并且水平较高的团队来说，迭代开发的代价最小。
迭代最主要的还是解决了风险的问题，不稳定的团队风险更多，应该实施迭代。迭代比实施瀑布代价低。可以通过迭代的方法促进团队成长，这是因为迭代给了大家更多的检查自己工作的机会，也给了更多的改进的机会。迭代开发具有普遍意义。
区别是迭代周期的长短、每个迭代中的工作安排、文档正式化程度、使用的主要的沟通手段等等。
每一次迭代都必须有明确的交付和出口准则。
适宜采用迭代模型的软件项目：
1. 最适合于需求没有完全确定和定义的情况；
2. 迭代模型将创建一个早期的版本可让人感受，以后的迭代将基于以前的迭代；
3. 不稳定团队，迭代最主要的还是解决了风险的问题，不稳定的团队风险更多，应该实施迭代，迭代给了大家更多的检查自己工作的机会，也给了更多的改进的机会；
4. 团队成员经验比较少的话，应该尽可能采用较短的迭代周期，以便于较快得到反馈，不断发现开发工作中的问题，以做出改进。
XXX有限公司 第 20 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.2.7 软件生命周期模型的应用
根据项目的具体情况，在描述的软件生命周期模型中选择软件生命周期。
在明确了软件生命周期模型之后，根据《组织级生命周期模型描述》中说明的各个阶段，进行项目的开发和确定。
4.2.8 输出
参考瀑布模型。
4.3 敏捷模型（Agile model）
4.3.1 典型生命周期描述
产品负责人和开发团队对产品业务目标形成共识；
产品负责人建立和维护产品需求列表Backlog（需求会不断新增和改变），并进行优先级排序；
产品负责人每轮迭代前Review需求列表，并筛选高优先级需求进入本轮迭代开发；
开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成；
开发团队每日站立会议、结对编程、持续集成，使开发进度真正透明；
XXX有限公司 第 21 页 / 共 46 页
OPD-GUID-2-生命周期模型
产品负责人对每轮迭代（2-4周）交付的可工作软件进行现场验收和反馈；
回到第2步，开始下一轮迭代；
优点：
快速地响应变化。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时，都能交付用户一个可用的、可部署的系统，用户使用并体验该系统并反馈意见，在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时地处理需求变化和用户反馈。
精确。敏捷方法则采用小步快跑，每走完一步再调整并为下一步确定方向，直到真正的终点。
质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等，甚至使用测试驱动开发。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。
速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。
丰厚的投资回报率。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。
高效的自我管理团队。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
缺点：
敏捷开发以人为本，对项目经理的要求比较高。如果控制不好，整个项目的风险会比较大。
敏捷对团队人员的素质要求比较高，要求团队能够进行自我管理。
采用敏捷开发的模式，团队成员须在思想上转变，比如结对编程、测试驱动开发等。
4.3.2 生命周期各个阶段描述
敏捷的周期划分为立项阶段和多个迭代阶段。迭代阶段分为初始阶段、计划阶段、冲刺阶段与发布阶段。立项阶段主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划；初始阶段的活动主要包括编写产品Backlog；计划阶段包括了迭代的两次计划会议；冲刺阶段即一个完整的Sprint迭代，周期通常不超过六个星期；发布阶段包括评审会议与回顾会议，此阶段结束后，将发布一个达到迭代目标的增量版本。至于产品的维护，则属于产品Backlog的一部分，列入每次迭代的范围。
XXX有限公司 第 22 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.3.2.1 立项阶段
详见瀑布生命周期模型项目策划阶段说明。
4.3.2.2 迭代阶段
4.3.2.2.1初始阶段
目标
适用标准和规范
相关工具
主要输入
入口准则
参与人员和相关人员
建立和维护产品需求列表，并进行优先级排序
[根据组织的实际情况描述]
[根据组织的实际情况描述]
项目任务书、建议书或工作说明书（SOW）
客户需求/需要
客户需求/需要已被批准
项目任务书、建议书或SOW已被批准
项目经理
产品负责人
客户代表
领域专家
需求分析师
PPQA工程师
1、 获取部分需求
2、 编写产品Backlog
3、 产品Backlog评估会议
产品Backlog
需求已根据优先级排序
需求分析所花的工作量和资金，评审工作量
制定迭代计划
[根据组织的实际情况描述]
活动
主要输出
出口准则
度量
目标
适用标准和规范
相关工具
主要输入
入口准则
4.3.2.2.2计划阶段
任务板、卡片
产品Backlog
存在产品Backlog
Backlog条目已划分优先级
参与人员项目经理
和相关人敏捷教练
员 客户代表
需求分析师
PPQA工程师
CM工程师
开发工程师
测试工程师
XXX有限公司 第 23 页 / 共 46 页
OPD-GUID-2-生命周期模型
活动 1、 迭代计划会议
2、 确定迭代目标、迭代演示日期、每日例会时间地点、团队成员名单、障碍Backlog
3、 拆分迭代 Backlog为任务并进行分配
4、 进行工作量估算并建立燃尽图
5、 创建任务板
主要输出 迭代计划会议纪要
迭代Backlog（包括迭代目标和团队成员名单）
障碍Backlog
燃尽图
任务板
出口准则 迭代计划得到产品经理、客户代表、项目经理及敏捷团队成员的认可。
度量 迭代计划的工作量。
4.3.2.2.3冲刺阶段
目标
适用标准和规范
相关工具
主要输入
实现迭代目标
[根据组织的实际情况描述]
[根据组织的实际情况描述]
迭代Backlog
障碍backlog
燃尽图
任务板
团队成员充分理解需求
团队成员接受过相关技能的培训
项目经理
敏捷教练
客户代表
PPQA工程师
CM工程师
开发工程师
测试工程师
1、 需求澄清
2、 敏捷建模，创建架构模型、类结构模型和测试用例模型
3、 测试驱动开发
4、 结对编程
5、 每日站立会议
6、 持续集成
7、 更新迭代Backlog
8、 更新燃尽模型
UserStory
敏捷模型
测试代码
功能代码
增量产品
入口准则
参与人员和相关人员
活动
主要输出
XXX有限公司 第 24 页 / 共 46 页
OPD-GUID-2-生命周期模型
出口准则 增量产品实现了迭代目标
度量 编码和单元测试的工作量、代码评审缺陷、独立的单元测试缺陷以及评审和返工工作量；
测试的工作量、测试中发现的缺陷。
4.3.2.2.4发布阶段
目标
适用标准和规范
相关工具
主要输入
入口准则
参与人员和相关人员
确保增量软件产品正常使用
[根据组织的实际情况描述]
[根据组织的实际情况描述]
增量产品（可执行文件）
增量产品实现了迭代目标并经过充分测试
项目经理
敏捷教练
产品负责人
客户代表
需求分析师
PPQA工程师
CM工程师
开发工程师
测试工程师
活动
1、 评审会议，
2、 进行迭代演示
3、 回顾会议
4、 编写用户手册和培训手册
主要输出 评审会议纪要
回顾会议纪要
增量产品
用户手册
培训手册
出口准则 迭代演示通过，客户知道如何使用
度量 迭代演示、验收和安装的工作量、验收中发现的缺陷。
4.3.3 里程碑与基线
根据项目情况，敏捷模型的整个项目生命周期根据Sprint迭代次数划分阶段，每个迭代阶段都包括初始、计划、冲刺和发布四个阶段。
里程碑点：每次迭代完成时；
基线点：
产品基线，每次迭代完成产品交付时建立。
4.3.4 项目生命周期模型的选择
根据生命周期模型的特点，结合项目的具体情况，进行生命周期的选择。
XXX有限公司 第 25 页 / 共 46 页
OPD-GUID-2-生命周期模型
选出项目符合《生命周期选择表》中的哪些类型：需求类型、项目类型、项目风险、用户类型和团队类型（可选一或选多）
参考《生命周期模型选择表》确定生命周期模型
4.3.5 选择敏捷模型
适宜采用敏捷模型的软件项目：
持续产生价值，需求有一定不确定性。
规模适中，没有特别约束。
有测试和集成工具支持。
便于和客户交流。
4.3.6 裁剪指南
在实际的使用过程中，根据软件项目的特点可以对敏捷模型进行裁剪。一般而言，以下几种裁剪是经常存在的，只要PPQA工程师同意即可：
产品Backlog中优先级一项可以裁减，按照先后排列顺序作为优先级的高低。
结对编程实践可以裁减，改为传统个人编程方式。
障碍Backlog可以裁减
根据项目需要，在经EPG审核并获得部门总监的批准下，也可对敏捷模型做出其他方式的裁剪。
4.3.7 软件生命周期模型的应用
根据项目的具体情况，在描述的软件生命周期模型中选择软件生命周期。
在明确了软件生命周期模型之后，根据《组织级生命周期模型描述》中说明的各个阶段，进行项目的开发和确定。
4.3.8 敏捷实践
4.3.8.1 管理实践
4.3.8.1.1产品Backlog评估会议
该实践对应瀑布模型需求确认过程，活动如下：
介绍会议的目标；
产品负责人介绍其需要评估的产品Backlog中的部分；
对产品Backlog中的各项问题：
➢ 由产品负责人解释Backlog中该问题背后的详细用例；
XXX有限公司 第 26 页 / 共 46 页
OPD-GUID-2-生命周期模型
➢ 团队各成员选出其手上的一张计划卡片，以投票决定他所认为的该问题的工作量大小；
➢ 所有团队成员同时亮出他们的卡片；
➢ 如果评估结果又分歧，让意见分歧最大的成员进行辩论，然后再次投票，知道所有人意见一致；
➢ 评估结果被添加到Backlog项；
通过简单的总结来结束评估会议。
4.3.8.1.2迭代计划会议
该实践对应瀑布模型需求确认过程，活动如下：
产品负责人对迭代目标进行总体介绍，概括产品Backlog；
定下演示的时间地点；
团队估算时间，在必要的情况下拆分Backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”；
团队选择要放入迭代中的故事。计算生产率，用作核查工作安排的基础；
为每日站立会议安排固定的时间地点；
把故事进一步拆分成任务。
需求澄清
4.3.8.1.3每日站立会议
该实践对应瀑布模型项目监督和控制过程，活动如下：
每日工作前，团队成员的例行沟通机制，由项目经理组织，项目组成员全体站立参加
聚焦在下面的三个主题：
➢ 昨天做了什么？
➢ 计划今天做什么？
➢ 遇到什么困难需要什么帮助以更高效的工作？
每日站立会议需要注意：
准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯；
高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）；
问题跟踪：敏捷教练应该记录下所有的问题并跟踪解决；
XXX有限公司 第 27 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.3.8.1.4迭代验收会议
该实践对应瀑布模型确认过程，活动如下：
每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求；
由敏捷教练组织， 产品负责人和用户代表（外部或内部利益相关人）负责验收、项目组负责演示可工作软件。
展示“真实”的产品：项目组应在真实环境中展示可运行的软件，判断是否达到“完成”标准；
收集反馈：产品负责人 根据验收情况及客户反馈意见，及时调整产品Backlog
4.3.8.1.5迭代回顾会议
该实践对应瀑布模型过程，活动如下：
在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；
围绕如下三个问题：
➢ 本次迭代有哪些做得好
➢ 本次迭代我们在哪些方面还能做得更好
➢ 我们在下次迭代准备在哪些方面改进？
会议气氛：项目组全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；
关注重点：项目组共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；
会议结论要跟踪闭环：可以放入迭代Backlog中。
XXX有限公司 第 28 页 / 共 46 页
OPD-GUID-2-生命周期模型
迭代回顾会议
4.3.8.1.6可视化管理
该实践对应瀑布模型项目监督和控制、风险管理过程，活动如下：
将项目状态 (进度、质量等)通过物理实体（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息。
物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到（存在电脑中的文件不是可视化的）；
内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨；
实时刷新：延迟的信息拖延问题暴露，降低运作效率。
可视化管理
4.3.8.1.7头脑风暴
该实践活动如下：
确定头脑风暴的主题、时间、地点并提前通知相关人员；
头脑风暴负责人讲述初步方案；
讨论方案；
确定方案，头脑风暴结束。
需要进行头脑风暴的活动如下：
需求澄清；
敏捷建模，如：架构设计、数据库设计、接口设计等；
Backlogs设计评审；
4.3.8.2 技术实践
4.3.8.2.1用户故事
该实践对应瀑布模型需求开发过程，活动如下：
用户故事是站在用户角度描述需求的一种方式；
每个用户故事须有对应的验收测试用例；
XXX有限公司 第 29 页 / 共 46 页
OPD-GUID-2-生命周期模型
用户故事是分层分级的，在使用过程中逐步分解细化；
典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。
I – Independent，可独立交付给客户
N – Negotiable，便于与客户交流
V - Valuable ，对客户有价值
E - Estimable ，能估计出工作量
S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成
T - Testable，可测试
用户故事
4.3.8.2.2需求澄清
该实践对应瀑布模型《需求规格说明书》评审过程，在迭代计划会议中进行，活动如下
需求分析师给开发人员讲解需求点；
开发人员评论需求点是否合理，完善；
开发人员大致描述实现该需求点的难点
所有人员对该需求估计工作量，如果估计不统一，则要估计多的人和估计少的人讲解原因，讲解完成后再进行一次估计，选择大多数的估计作为该需求的工作量；
4.3.8.2.3敏捷建模
该实践对应瀑布概要设计和详细设计过程。
敏捷开发把传统软件过程前期的架构设计，分散到了整个敏捷开发过程中，即演进式敏捷建模。需要进行敏捷建模的方面如下：
软件的架构层次，层次化是软件产品架构中很重要的一部分；
XXX有限公司 第 30 页 / 共 46 页
OPD-GUID-2-生命周期模型
产品和技术选型；
各个组件的结构及接口；
重要模块和重要类的说明。
4.3.8.2.4结对编程
该实践对应瀑布模型同行评审过程，活动如下：
两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；
操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；
领航员检视的同时还必须负责考虑下一步的工作方向 ，比如可能出现的问题以及改进等。
程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象；
开始一个新Story开发的时候即可变换搭档，以增进知识传播；
培养团队成员积极、主动、开放、协作的心态能够增进结对编程效果；
实施初期需要精心辅导，帮助团队成员克服个性冲突和习惯差异。
4.3.8.2.5测试驱动开发
该实践对应瀑布模型验证过程，活动如下：
TDD以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化；
TDD要求测试可以完全自动化运行。
测试代码和源代码一样都需要简洁，可读性好；
测试用例的设计要保证完备，覆盖被测单元的所有功能；
每个测试用例尽量保持独立，减少依赖，提高用例的可维护性；
当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用 TDD 实现。
XXX有限公司 第 31 页 / 共 46 页
OPD-GUID-2-生命周期模型
测试驱动开发
4.3.8.2.6持续集成
该实践对应瀑布模型产品集成过程，活动如下：
持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息；
自动化测试用例的完备性和有效性是持续集成质量保障；
修复失败的构建是团队最高优先级的任务；
开发人员须先在本地构建成功，才可提交代码到配置库 ；
持续集成的状态必须实时可视化显示给所有人；
大系统持续集成需分层分级，建立各层次统一的测试策略。
XXX有限公司 第 32 页 / 共 46 页
OPD-GUID-2-生命周期模型
持续集成
4.3.8.3 支持实践
4.3.8.3.1配置管理
详见配置管理过程域文件。
4.3.8.4 度量与分析
详见度量与分析过程域文件。
4.3.8.5 过程和产品质量保证
详见过程和产品质量保证过程域文件。
4.3.8.6 相关的文件
类别
项需求管理 管理需求 产品Backlog
过程域 特定目标 敏捷实践
XXX有限公司 第 33 页 / 共 46 页
OPD-GUID-2-生命周期模型
目管理类
项目策划 建立估计
开发项目计划
获得对计划的承诺
立项阶段
项目监督和控制 对照计划监督项目
管理纠正行动直至关闭
每日站立会议
可视化管理
供方协定管理
集成项目管理
使用项目已定义过程
与相关人员协调和合作
风险管理 准备风险管理
识别和分析风险
缓解风险
障碍Backlog
每日站立会议
可视化管理
用户故事
产品Backlog评估会议
迭代计划会议（需求澄清）
敏捷建模
工程类
需求开发 开发顾客需求
开发产品需求
分析和确认需求
技术解决方案 选择产品构建解决方案
开发设计
实现产品设计
产品集成 准备产品集成
确保接口兼容性
组装产品构建和交付产品
持续集成
验证 准备验证
进行同行评审
验证选择的工作产品
持续集成
测试驱动开发
结对编程
迭代验收会议 确认 准备确认
确认产品或产品构件
支持类
度量和分析 度量和分析
过程和产品质量保证 过程和产品质量保
证
配置管理 配置管理
XXX有限公司 第 34 页 / 共 46 页
OPD-GUID-2-生命周期模型
决策分析和解决
过程管理类
组织过程定义
组织培训
组织过程焦点
确定过程改进的机会
策划和实施过程改进
部署组织过程资产和汇总经验教训
建立组织过程资产
建立组织级的培训能力
提供必要的培训
迭代回顾会议
敏捷生命周期 && CMMI过程域
4.4 原型模型（prototyping model）
4.4.1 咨询立项
参见《立项管理过程定义》中的内容。
XXX有限公司 第 35 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.2 需求分析、项目策划、快速设计和原型评审
本阶段的主要目标是了解客户的主要需求，进行初步策划，完成原型设计，组织客户参与的原型评审，通过几轮上述过程，确定最终客户需求，并通过实际验证所需技术可行。根据需求，同时根据经验数据（组织过程能力基线及项目数据），估算软件开发进度、软件开发经费及其他相关因素，制定相关项目管理计划。完成本阶段需产生的文档。
需求分析时间占开发时间的20%－35%左右；采用的成熟软件技术占80%以上。
4.4.2.1 角色职责
角 色
高层经理
职责
根据情况参与需求规格说明书评审
负责审批项目开发计划
负责组织需求规格说明书评审
负责编制项目计划
负责组织编制配置管理计划、质量保证计划、测试计划、度量与分析计划等
负责组织项目所有管理计划的评审工作
负责组织编制需求规格说明书
相关人员参与评审需求规格说明书
参与项目计划的编制，对各自任务做出承诺
按要求完成编制需求规格说明书
负责编制配置管理计划
参与项目计划的编制，对自己任务做出承诺
按计划建立配置环境，建立基线目录
做本阶段配置审计、配置统计报告
参与需求规格说明书评审
负责编制质量保证计划
参与项目计划的编制，对自己任务做出承诺
审计本阶段过程、工作产品，形成QA报告及相关文档
参与需求规格说明书的评审
开始着手测试用例的编写
负责编制软件测试计划
参与项目计划的编制，对自己任务做出承诺
参与需求规格说明书的评审
按要求开始测试用例编写工作
参与软件测试计划的编制，对各自任务做出承诺
配合项目经理完成需求规格说明书，并确认
参与原型评审
项目经理
项目组成员
配置管理员
PPQA
测试经理
测试人员
客户经理/代表（销售经理）
领域专家
4.4.2.2 4.4.2.2 输入
《项目任务书》
XXX有限公司 第 36 页 / 共 46 页
OPD-GUID-2-生命周期模型
《合同》
4.4.2.3 输入准则
《项目任务书》通过审批
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能
项目资金到位
4.4.2.4 活动和任务
1. 根据组织级项目过程定义裁剪或重新定义为《项目已定义过程》。
2. 《项目已定义过程》由项目经理申请，经过EPG审批。
3. 根据需求开发计划与客户联系进行需求获取。
4. 根据获取的客户原始需求，编写《用户需求说明书》的关键章节。
5. 根据《用户需求说明书》，结合现有软件产品系统，编写《需求规格说明书》的关键章节，建立系统原型。
6. 项目经理组织相关人员对《需求规格说明书》进行走查，走查问题需及时跟踪解决。
7. 在需求规格说明书开始编写并完成走查过程中，测试负责人组织人员考虑系统主要测试用例的编写工作。
8. 根据《项目任务书》和《用户需求说明书》拟订项目计划。
9. 根据走查通过的《需求规格说明书》细化并制定估算记录、WBS、项目计划及相关计划，如：配置管理计划、质量保证计划、测试计划等。
10. 项目经理组织走查项目计划及相关计划。
11. 项目经理组织人员，依据走查通过的《项目计划》时间任务安排，根据《需求规格说明书》，按照TS过程描述，进行概要设计，编制《概要设计说明书》的关键章节。
12. 项目经理组织人员走查《概要设计说明书》。
13. 开发接口设计。
14. 项目经理或项目经理组织人员，依据走查通过的《项目计划》时间任务安排，根据《需求规格说明书》、《概要设计说明书》，编制《数据库设计说明书》的关键章节。
15. 项目经理组织人员走查《数据库设计说明书》。
16. 根据走查通过的《概要设计说明书》和《数据库设计说明书》，项目经理组织人员，针对每个模块完成相应的《详细设计说明书》的关键章节。
17. 项目经理组织人员走查《详细设计说明书》。
18. 项目经理组织相关人员，根据《需求规格说明书》和《概要设计说明书》或《详细设计说明书》，分配相关程序员完成所有软件单元的编码工作；
XXX有限公司 第 37 页 / 共 46 页
OPD-GUID-2-生命周期模型
19. 完成编码后，项目经理组织项目成员对系统主要部分进行编码的单元测试，系统主要部分包括系统主要功能和采用新技术实现的模块等。
20. 组织客户、领域专家对原型模型进行评审，包括需求是否完备、设计方法是否可行，评审通过后确定最终的《用户需求说明书》、《需求规格说明书》、项目计划及附属计划等，并将该阶段所有文档的全部章节补充完整，并通过正式评审。如果评审未通过，则返回第4条，进行新一轮迭代。
21. 快速设计产生的原型需提交配置受控库。
4.4.2.5 输出准则
以上所有文档或计划通过评审或审批
4.4.2.6 输出
《用户需求说明书》(可裁剪)
《需求规格说明书》
《需求跟踪矩阵》
《项目计划》（附《估算记录》、《WBS》）
《质量保证计划》
《配置管理计划》
《测试计划》
《度量与分析计划》
4.4.3 最终系统设计-概要设计与详细设计
概要设计阶段是从实现的角度开发针对客户需求的解决方案，完成软件的架构设计和数据库设计，详细设计是从架构设计和数据库设计入手，完成模块的详细设计或界面设计。
软件需求分析和软件设计的时间占开发周期的15－20％左右；其中软件设计时间约占7％－10％。
4.4.3.1 角色职责
角 色
高层经理
职责
根据情况参与架构设计说明书、数据库设计说明书评审
根据情况参与模块详细设计或界面设计
负责组织设计说明书评审
负责组织编制架构设计、数据库设计说明书
负责协调项目内、外工作中国
负责审核本阶段QA、CM活动
相关人员参与评审设计说明书
按分配工作做设计说明书
项目经理
项目组成员
XXX有限公司 第 38 页 / 共 46 页
OPD-GUID-2-生命周期模型
角 色
配置管理员
PPQA
测试人员
4.4.3.2 输入
《项目任务书》
职责
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
组织编制测试用例
按要求开始测试用例编写工作
《用户需求说明书》
《需求规格说明书》
《项目计划》
4.4.3.3 输入准则
以上文档通过评审或审批
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能
项目资金到位
4.4.3.4 活动和任务
1. 项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》，按照TS过程描述，重新进行概要设计，编制完整的《概要设计说明书》。
2. 项目经理组织人员评审《概要设计说明书》。
3. 开发接口设计。
4. 项目经理或项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》、《概要设计说明书》，编制完整的《数据库设计说明书》。
5. 项目经理组织人员评审《数据库设计说明书》。
6. 根据评审通过的《概要设计说明书》和《数据库设计说明书》，项目经理组织人员，针对每个模块细化相应的《详细设计说明书》。
7. 项目经理组织人员评审《详细设计说明书》。
4.4.3.5 输出准则
以上文档通过评审
4.4.3.6 输出
《概要设计说明书》
《接口设计说明书》
《数据库设计说明书》
《详细设计说明书》
XXX有限公司 第 39 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.4 最终系统实现-编码和单元测试
根据软件详细设计，完成软件编码、测试和集成。
本阶段进度占总生命周期的15－35%左右；采用的成熟技术占80%以上。
4.4.4.1 角色职责
角 色
高层经理
职责
根据情况参与代码走查
负责组织代码走查
负责协调项目内、外工作
负责审核本阶段QA、CM活动
负责分配编码工作
负责分配单元测试工作
协调代码走查
组织需求变更管理
完成分配的编码工作
完成分配的单元测试任务
参与代码走查
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
按要求对所负责的模块做单元测试接收工作
项目经理
项目组成员
配置管理员
PPQA
测试人员
4.4.4.2 输入
《需求规格说明书》
《概要设计说明书》
《详细设计说明书》
4.4.4.3 输入准则
软件设计说明书通过评审和批准；
相关人员到位，并接受过相关技能的培训或达到技能要求
4.4.4.4 活动和任务
1. 项目经理组织相关人员，根据《需求规格说明书》和《概要设计说明书》或《详细设计说明书》，分配相关程序员完成所有软件单元的编码工作；
2. 完成编码后，项目经理组织项目成员之间进行编码的单元测试工作，单元测试的覆盖范围为100%；
3. 项目经理组织相关人员，对编码进行走查，覆盖范围应当大于等于60%。
4.4.4.5 输出准则
完成所有模块的编码工作
完成所有模块的单元测试报告
XXX有限公司 第 40 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.4.6 输出
软件代码
《单元测试报告》
4.4.5 集成测试和系统测试
验证客户需求是否都已经实现。
本阶段进度占总研发生命周期的10％－20％。
4.4.5.1 角色职责
角色 职责
负责制定和维护测试计划
负责设计测试过程
对执行测试负责
负责协调资源，评审测试用例，验证测试环境
搭建测试环境，执行单元测试， 集成测试和系统测试，记录测试结果，填写测试问题报告单， 编写测试驱动程序。
参与测试计划及用例的评审，协调处理测试问题报告单，评审测试总结报告。
负责问题和缺陷修复工作
测试负责人
测试人员
项目经理
软件工程师
评审人员(项目经理,
质量保证员, 系统分参与测试过程中产生的关键工作产品的评审。
析员等)
软件验收小组(咨询顾问, 项目经理, 质量制定验收测试计划书, 实施验收测试, 编写验收测试报保证员, 测试负责人告。
等)
4.4.5.2 输入
《测试计划》
《测试用例》
源代码
《单元测试报告》
4.4.5.3 输入准则
测试用例通过评审
代码完成并通过单元测试
4.4.5.4 活动和任务
1. 按照测试计划，搭建集成测试环境；
XXX有限公司 第 41 页 / 共 46 页
OPD-GUID-2-生命周期模型
2. 执行集成和系统测试；
3. 记录测试结果，填写测试问题报告单提交给项目组人员修改；
4. 对修改过的版本进行回归测试；
5. 总结测试结果并编写测试总结报告。
4.4.5.5 输出准则
通过集成测试和系统测试，并完成回归测试
4.4.5.6 输出
《缺陷纪录》
《测试报告》
4.4.6 验收和实施
在验收阶段，系统安装在目标环境中，并在这个环境中进行测试，以确保它满足系统要求，客户满意验收。
进度周期占研发生命周期的10%－20%。
4.4.6.1 角色职责
角色 职责
制订实施计划。
负责组织编写用户手册
项目经理 组织和协调用户参与项目实施过程
分类整理用户的反馈意见和新需求，协商用户提出修改意见
填写验收报告
参与编写用户手册。
参与初始化基础数据，和必要的业务数据。
培训用户使用应用系统，包括帮助用户理解使用系统，讲解业现场实施人员
务操作步骤，解答用户问题。
协助用户验收测试。
收集用户的反馈意见，记录用户新需求。
安装和调试软硬件，部署应用系统。
监测应用系统运行状况。
技术支持人员
及时修改程序，解决现场实施中的问题。
配合数据初始化工作。
参与编写用户手册。
测试人员
根据实施计划和用户现场情况，部分或全程参与培训用户工作。
提供正确版本的文档和产品，确保文档、产品之间的完整性和配置管理员
一致性。
4.4.6.2 输入
《质量总结报告》
《测试总结报告》
XXX有限公司 第 42 页 / 共 46 页
OPD-GUID-2-生命周期模型
配置审计通过的软件产品，和程序包
4.4.6.3 输入准则
软件产品的开发已经完成，并且通过集成测试和系统测试，完成测试总结和配置审计
4.4.6.4 活动和任务
1. 进行实施准备，制定实施计划，编写用户手册、系统安装手册、培训手册等；
2. 安装系统环境，进行数据初始化；
3. 按照客户要求配合客户进行验收测试或试运行；
4. 验收测试通过，客户接收系统，签字确认；
5. 召开项目总结会议，向组织及财富库自交项目资料。
4.4.6.5 输出准则
客户接受系统，验收通过
4.4.6.6 输出
《用户手册》
《验收报告》
《项目总结报告》
《提交给过程资产库的资料清单》
4.4.7 售后维护
在维护期间，对于客户提出的系统交付使用后出现的问题进行修改和维护。
维护时间一般为1年左右。
4.4.7.1 角色职责
角 色
高层经理
客户经理
项目经理
项目维护人员
4.4.7.2 输入
《验收报告》
4.4.7.3 输入准则
系统已经通过客户验收
职责
负责项目人力、物力等资源的保障和管理；
负责项目经费使用的审批；
于客户沟通，协助用户方的维护工作
负责维护的管理工作
负责具体的维护工作
XXX有限公司 第 43 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.7.4 活动和任务
1. 按合同签订的维护服务期和任务进行系统维护；
2. 维护期满项目过程中的所有配置项应纳入资产库。
4.4.7.5 输出准则
到达合同签订的维护时间，完成维护任务
客户提出的问题已经得到解决或和客户达成一致协定。
4.4.7.6 输出
《维护记录》
4.4.8 裁剪指南
在实际的使用过程中，根据软件项目的特点可以对原型法进行裁剪。一般而言，以下几种裁剪是经常存在的，只要EPG同意即可：
采用原型法时需求分析、项目策划、快速设计、原型评审阶段内部产生的文档可以只完成文档的关键章节，进行基本走查，等到原型DEMO通过用户认可后再重新界定项目范围和内容，细化该阶段文档的全部内容，并进行正式评审；
最终设计阶段根据项目的实际情况和规模可以细化概要设计阶段和详细设计阶段，细化后的活动和出入口准则可以参考瀑布模型的相关阶段；
如果采用增长式原型，则系统的最终设计和最终实现可以省略。系统的开发过程变成了一边开发，一边试用，然后修正，如此反复，直到用户满意。
根据项目需要，在高层经理的批准下，也可对原型模型做出其他方式的裁剪。
XXX有限公司 第 44 页 / 共 46 页
2023年12月22日发(作者：泉英奕)
过程管理类
生命周期模型
编写
审批
文档版本
编写时间
审批时间
V 1.0
XXX有限公司 版权所有
文档中的全部内容属量子通信所有，
未经允许，不可全部或部分发表、复制、使用于任何目的。
OPD-GUID-2-生命周期模型
文档修订摘要
日期
修订号
描述
著者
审阅者
日期
XXX有限公司 版权所有
文档中的全部内容属量子通信所有，
未经允许，不可全部或部分发表、复制、使用于任何目的。
OPD-GUID-2-生命周期模型
目 录
1
导言 ............................................................... 3
1.1
1.2
1.3
2
3
4
目的 .......................................................... 3
范围 .......................................................... 3
术语和缩略语 .................................................. 3
过程综述 ........................................................... 3
主要角色及职责 ..................................................... 4
主要阶段描述 ....................................................... 4
4.1
瀑布模型（waterfall model） ................................... 4
4.1.1
立项阶段 ................................................. 5
4.1.2
需求分析和项目策划阶段 ................................... 5
4.1.3
设计阶段 ................................................. 7
4.1.4
编码和单元测试阶段 ....................................... 9
4.1.5
集成测试和系统测试阶段 .................................. 10
4.1.6
验收和实施阶段 .......................................... 11
4.1.7
售后维护 ................................................ 13
4.1.8
裁剪指南 ................................................ 13
4.2
迭代模型（iterative model） .................................. 15
4.2.1
典型生命周期描述 ........................................ 15
4.2.2
裁剪指南： .............................................. 16
4.2.3
生命周期各个阶段描述 .................................... 16
4.2.4
里程碑和基线 ............................................ 20
4.2.5
项目生命周期模型的选择 .................................. 20
4.2.6
选择迭代模型 ............................................ 20
4.2.7
软件生命周期模型的应用 .................................. 21
4.2.8
输出 .................................................... 21
4.3
敏捷模型（Agile model） ...................................... 21
4.3.1
典型生命周期描述 ........................................ 21
4.3.2
生命周期各个阶段描述 .................................... 22
XXX有限公司 第 1 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.3.3
里程碑与基线 ............................................ 25
4.3.4
项目生命周期模型的选择 .................................. 25
4.3.5
选择敏捷模型 ............................................ 26
4.3.6
裁剪指南 ................................................ 26
4.3.7
软件生命周期模型的应用 .................................. 26
4.3.8
敏捷实践 ................................................ 26
4.4
原型模型（prototyping model） ................................ 35
4.4.1
咨询立项 ................................................ 35
4.4.2
需求分析、项目策划、快速设计和原型评审 .................. 36
4.4.3
最终系统设计-概要设计与详细设计 ......................... 38
4.4.4
最终系统实现-编码和单元测试 ............................. 40
4.4.5
集成测试和系统测试 ...................................... 41
4.4.6
验收和实施 .............................................. 42
4.4.7
售后维护 ................................................ 43
4.4.8
裁剪指南 ................................................ 44
XXX有限公司 第 2 页 / 共 46 页
OPD-GUID-2-生命周期模型
1 导言
1.1 目的
该文档为公司的项目确定合适的生命周期提供指导，说明公司项目对应的软件生命周期的描述。
1.2 范围
本文档适用于XXX有限公司。
1.3 术语和缩略语
EPG ： Engineering Process Group 工程过程组。
2 过程综述
该过程阐述了公司最具代表性的项目类型特性，以及他们所对应的软件生命周期描述。这三种项目类型分别为：开发类项目，维护类项目，升级类项目。同时又着重对开发类项目中的瀑布模型和迭代模型进行了详细描述。
开发类项目是指公司新承接的，由客户方提出的，有明确需求的项目，或由公司自主立项的新项目。该类项目一般有比较完整的软件生命周期，也可能根据项目的具体情况将其中几个阶段合并或拆分。
维护类项目是指对公司原有开发完毕的已发布的项目进行维护，维护的需求可能来自客户提交的问题报告单，也可能来自公司内部测试人员提交的在发布时没有解决的问题报告单。
升级类项目是指公司对原有开发完毕项目进行的后期开发项目，后期开发的主要内容可能包括前期项目的缺陷修复、功能增强、新功能等等。
XXX有限公司 第 3 页 / 共 46 页
OPD-GUID-2-生命周期模型
3 主要角色及职责
角色
高层经理
EPG组长
EPG成员
职责
批准裁剪后的软件生命周期
评审并批准裁剪原因和裁剪结果
参与评审批准裁剪原因和裁剪结果
确定项目特性数据，根据项目特性数据选择合适项目经理 的软件生命周期，并确定具体的过程及过程之间的关系
协助项目经理选择合适的软件生命周期，并帮助项目组关键成员
确定其中具体过程及过程之间的关系
备注
4 主要阶段描述
根据软件工程和公司项目的实际情况，主要对项目的瀑布模型、迭代模型、敏捷模型分别描述。
各个项目可以根据项目的需求特点，开发周期，团队规模，团队技术水平以及应用的重要程度等项目的特性数据来选择适合自己项目的软件生命周期。
4.1 瀑布模型（waterfall model）
瀑布模型，从上一项活动接收该活动的工作对象做为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，做为输出传给下一项活动，对该项活动实施的工作进行评审，若其工作得到确认，则基线下一项活动，否则返回前项，甚至更前项的活动进行返工。
瀑布模型的优点是，通过设置里程碑明确每阶段的任务与目标，通过阶段评审，将开发过程纳入正确轨道，严格的计划性保证软件产品的按时交付。缺点是瀑布模型缺乏灵活性，不适合需求模糊的项目；返回上一级的开发需要十分高昂的代价。
选择瀑布模型的项目一般是需求比较稳定，项目周期比较长，团队技术水平比较高的项目。
根据公司项目情况，我们利用瀑布模型将整个软件项目生命周期过程划分为：咨询立项、需求分析和项目策划、概要设计与详细设计、编码和单元测试、集成测试和系统测试、验收和实施、售后维护7个主阶段。
XXX有限公司 第 4 页 / 共 46 页
OPD-GUID-2-生命周期模型
咨询
立项
需求分析项目策划
概要设计
详细设计
编码和单元测试
集成测试系统测试
验收
实施
阶售后
维护
4.1.1 立项阶段
参见《立项管理过程定义》中的内容。
4.1.2 需求分析和项目策划阶段
需求分析和项目策划阶段的目标可分两方面来描述：
通过对系统功能、性能指标、可靠性等多方面分析陈述、结合客户实际业务需求，生成一个能够正确说明客户所有需求的标准化需求文档。在需求分析方面主要工作是需求提炼与分析、需求归档、需求评审等。
根据已评审通过的需求文档，同时根据经验数据（组织过程能力基线及项目数据），XXX有限公司 第 5 页 / 共 46 页
OPD-GUID-2-生命周期模型
估算软件开发进度、软件开发经费及其他相关因素，制定相关项目管理计划。
需求分析时间占开发时间的20%－35%左右；
采用的成熟软件技术必须占80%以上；
4.1.2.1 角色职责
角 色
高层经理
职责
根据情况参与需求规格说明书评审
负责审批项目开发计划
负责组织需求规格说明书评审
负责编制项目计划
负责组织编制配置管理计划、质量保证计划、测试计划、度量与分析计划等
负责组织项目所有管理计划的评审工作
负责组织编制需求规格说明书
相关人员参与评审需求规格说明书
参与项目计划的编制，对各自任务做出承诺
按要求完成编制需求规格说明书
负责编制配置管理计划
参与项目计划的编制，对自己任务做出承诺
按计划建立配置环境，建立基线目录
做本阶段配置审计、配置统计报告
参与需求规格说明书评审
负责编制质量保证计划
参与项目计划的编制，对自己任务做出承诺
审计本阶段过程、工作产品，形成QA报告及相关文档
参与需求规格说明书的评审
开始着手测试用例的编写
负责编制软件测试计划
参与项目计划的编制，对自己任务做出承诺
参与需求规格说明书的评审
按要求开始测试用例编写工作
参与软件测试计划的编制，对各自任务做出承诺
配合项目经理完成需求规格说明书，并确认
项目经理
项目组成员
配置管理员
PPQA
测试经理
测试人员
客户经理/代表（销售经理）
4.1.2.2 输入
《立项建议书》
《项目任务书》
项目人员和资金
4.1.2.3 输入准则
《立项建议书》通过审批；
XXX有限公司 第 6 页 / 共 46 页
OPD-GUID-2-生命周期模型
《项目任务书》下发；
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能；
项目资金到位。
4.1.2.4 活动和任务
根据组织级《项目已定义过程裁剪指南》裁剪或重新定义为《项目已定义过程》；
《项目已定义过程》由项目经理申请，经过EPG审批；
根据需求开发的计划与客户联系进行需求获取；
根据获取的客户原始需求，形成《用户需求说明书》；
根据《用户需求说明书》，结合现有软件产品系统，形成《需求规格说明书》，必要时建立系统原型；
项目经理组织相关人员评审《需求规格说明书》，跟踪评审问题直到修改完成；
在《需求规格说明书》开始编写并完成评审过程中，测试负责人组织人员考虑测试用例的编写工作；
根据《项目任务书》、《立项建议书》、《用户需求说明书》拟订项目计划；
根据评审通过的《需求规格说明书》细化并制定估算记录、WBS、项目计划及相关计划，如：《配置管理计划》、《质量保证计划》、《度量与分析计划》、《测试计划》等；
项目经理组织评审项目计划及相关计划。
4.1.2.5 输出准则
以上所有文档或计划通过评审或审批
4.1.2.6 输出
《用户需求说明书》(可裁剪)
《需求规格说明书》
《需求跟踪矩阵》
《项目计划》（附《估计记录》、《WBS分解》）
《质量保证计划》
《配置管理计划》
《度量与分析计划》
4.1.3 设计阶段
概要设计阶段是从实现的角度开发针对客户需求的解决方案，完成软件的架构设计和XXX有限公司 第 7 页 / 共 46 页
OPD-GUID-2-生命周期模型
数据库设计，详细设计是从架构设计和数据库设计入手，完成模块的详细设计或界面设计。
软件需求分析和软件设计的时间占研制周期的15－20％左右；其中软件设计时间约占7％－10％。；
4.1.3.1 角色职责
角 色
高层经理
职责
根据情况参与架构设计说明书、数据库设计说明书评审
根据情况参与模块详细设计或界面设计
负责组织设计说明书评审
负责组织编制架构设计、数据库设计说明书
负责协调项目内、外工作
负责审核本阶段QA、CM活动
相关人员参与评审设计说明书
按分配工作做设计说明书
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
组织编制测试用例
按要求开始测试用例编写工作
项目经理
项目组成员
配置管理员
PPQA
测试人员
4.1.3.2 输入
《立项建议书》
《项目任务书》
《用户需求说明书》
《需求规格说明书》
《项目计划》
4.1.3.3 输入准则
以上文档通过评审或审批
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能
项目资金到位
4.1.3.4 活动和任务
项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》，按照AD过程描述，进行概要设计，编制《概要设计说明书》。
项目经理组织人员评审《概要设计说明书》。
开发接口设计。
项目经理或项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》、《概要设计说明书》，编制《数据库设计说明书》。
XXX有限公司 第 8 页 / 共 46 页
OPD-GUID-2-生命周期模型
项目经理组织人员评审《数据库设计说明书》。
根据评审通过的《概要设计说明书》和《数据库设计说明书》，项目经理组织人员，针对每个模块完成相应的《详细设计说明书》。
项目经理组织人员评审《详细设计说明书》。
4.1.3.5 输出准则
以上文档通过评审
4.1.3.6 输出
《概要设计说明书》
《接口设计说明书》（根据项目需要可合并到设计文件中）
《数据库设计说明书》（没有数据库需要的项目可裁剪该产品及过程）
《详细设计说明书》
4.1.4 编码和单元测试阶段
根据软件详细设计，完成软件编码、单元测试和集成；
本阶段进度占总生命周期的15－35%左右
采用的成熟技术必须占80%以上
4.1.4.1 角色职责
角 色
高层经理
职责
根据情况参与代码走查
负责组织代码走查
负责协调项目内、外工作
负责审核本阶段QA、CM活动
负责分配编码工作
负责分配单元测试工作
协调代码走查
组织需求变更管理
完成分配的编码工作
完成分配的单元测试任务
参与代码走查
编写部署说明
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
按要求对所负责的模块做单元测试接收工作
项目经理
项目组成员
配置管理员
PPQA
测试人员
4.1.4.2 输入
《需求规格说明书》
《概要设计说明书》
XXX有限公司 第 9 页 / 共 46 页
OPD-GUID-2-生命周期模型
《详细设计说明书》
4.1.4.3 输入准则
软件设计说明书通过评审和批准；
相关人员到位，并接受过相关技能的培训或达到技能要求。
4.1.4.4 活动和任务
项目经理组织相关人员，根据《需求规格说明书》和《概要设计说明书》或《详细设计说明书》，分配相关程序员完成所有软件单元的编码工作；
完成编码后，项目经理组织项目成员之间进行编码的单元测试工作；
项目经理组织相关人员，对编码进行走查，覆盖范围必须大于等于60%；
项目经理组织相关人员编写《产品集成策略》。
4.1.4.5 输出准则
完成所有模块的编码工作
完成所有模块的单元测试报告
4.1.4.6 输出
软件代码
单元测试报告
4.1.5 集成测试和系统测试阶段
验证客户需求是否都已经实现
本阶段进度占总研发生命周期的10％－20％。
4.1.5.1 角色职责
角色 职责
负责制定和维护测试计划
负责设计测试过程
对执行测试负责
负责协调资源，评审测试用例，验证测试环境
搭建测试环境，执行单元测试， 集成测试和系统测试，记录测试结果，填写测试问题报告单， 编写测试驱动程序。
参与测试计划及用例的评审，协调处理测试问题报告单，评审测试总结报告。
负责问题和缺陷修复工作
参与测试过程中产生的关键工作产品的评审。
测试负责人
测试人员
项目经理
软件工程师
评审人员(项目经理, 质量保证员, 系统分析员等)
XXX有限公司 第 10 页 / 共 46 页
OPD-GUID-2-生命周期模型
软件验收小组(咨询顾问, 项目经理, 质量保证员, 测试负责人等)
4.1.5.2 输入
《测试计划》
《集成测试用例》
《系统测试用例》
发布程序
《单元测试报告》
《产品集成策略》
4.1.5.3 输入准则
测试用例通过评审
代码完成并通过单元测试
4.1.5.4 活动和任务
制定验收测试计划书, 实施验收测试, 编写验收测试报告。
按照《测试计划》和《产品集成策略》，搭建集成测试环境；
执行集成和系统测试；
记录测试结果，填写测试问题报告单提交给项目组人员修改；
对修改过的版本进行回归测试；
总结测试结果并编写测试报告。
4.1.5.5 输出准则
通过集成测试和系统测试，并完成回归测试。
4.1.5.6 输出
缺陷记录
测试报告
4.1.6 验收和实施阶段
在验收阶段，系统安装在目标环境中，并在这个环境中进行测试，以确保它满足系统要求，客户满意验收。
进度周期占研发生命周期的10%－20%
4.1.6.1 角色职责
角色 职责
XXX有限公司 第 11 页 / 共 46 页
OPD-GUID-2-生命周期模型
项目经理
现场实施人员
技术支持人员
测试人员
配置管理员
4.1.6.2 输入
产品里程碑报告
基线发布报告
测试总结报告
制订实施计划。
负责组织编写用户手册或操作手册
组织和协调用户参与项目实施过程
对用户的反馈意见和新需求分类整理，并与用户协商，提出修改意见
填写验收报告
参与编写用户手册或操作手册。
参与初始化基础数据，和必要的业务数据。
培训用户使用应用系统，包括帮助用户理解使用系统，讲解业务操作步骤，解答用户问题。
协助用户验收测试。
收集用户的反馈意见，记录用户新需求。
安装和调试软硬件，部署应用系统。
监测应用系统运行状况。
及时修改程序，解决现场实施中的问题。
配合数据初始化工作。
参与编写用户手册或操作手册。
根据实施计划和用户现场情况，部分或全程参与培训用户工作。
提供正确版本的文档和产品，确保文档、产品之间的完整性和一致性。
配置审计通过的软件产品和程序包
4.1.6.3 输入准则
软件产品的开发已经完成；
通过集成测试和系统测试；
完成测试总结和配置审计。
4.1.6.4 活动和任务
进行实施准备，制定实施计划，编写用户手册或操作手册、培训手册等；
安装系统环境，进行数据初始化；
按照客户要求配合客户进行验收测试或试运行；
验收测试通过，客户接收系统，签订用户验收报告。
4.1.6.5 输出准则
客户接受系统，验收通过
XXX有限公司 第 12 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.1.6.6 输出
《用户手册》（可裁剪）
《验收报告》
4.1.7 售后维护
本阶段可以裁剪。
在维护期间，对于客户提出的系统交付使用后出现的问题进行修改和维护。
维护时间一般为1年左右。
4.1.7.1 角色职责
角 色
高层经理
客户经理
项目经理
项目维护人员
4.1.7.2 输入
用户验收报告
4.1.7.3 输入准则
系统已经通过客户验收
4.1.7.4 活动和任务
按合同签订的维护服务期和任务进行系统维护；
维护期满项目过程中的所有配置项应纳入资产库。
4.1.7.5 输出准则
到达合同签订的维护时间，完成维护任务
客户提出的问题已经得到解决或和客户达成一致协定。
4.1.7.6 输出
《维护记录》
职责
负责项目人力、物力等资源的保障和管理；
负责项目经费使用的审批；
于客户沟通，协助用户方的维护工作
负责维护的管理工作
负责具体的维护工作
4.1.8 裁剪指南
在实际的使用过程中，根据软件项目的特点可以对瀑布模型进行裁剪。
设计阶段中，根据项目实际情况需要，可以选择概要设计和详细设计只做一种，如果概要设计完成了，可以选取其中需要的部分做详细设计；
XXX有限公司 第 13 页 / 共 46 页
OPD-GUID-2-生命周期模型
集成测试、系统测试阶段合并成一个阶段，称为测试阶段。活动和工作产品也作相应合并；
如非有必要，售后维护阶段可以整个裁剪；
根据项目的人员配置情况，在有替代的活动来验证相应工作产品的可测试性时，测试计划和测试用例的编制时间可以适当的后延。不过，必须确保测试计划和测试用例经过有效的评审以后，才可以开始实际的测试活动。
根据项目需要，在经EPG审核并获得高层经理的批准下，也可对瀑布模型做出其他方式的裁剪，裁剪内容主要包括：对生命周期各阶段、输入/输出出及相关活动的增加、删除或修改合并，但在裁剪过程中必须遵循以下原则：
1) 阶段衔接原则：
所裁剪的生命周期各阶段间应是相互衔接的。一个阶段的里程碑工作是下一阶段的输入。切忌从需求阶段跳过分析设计阶段直接进入编码实现阶段。
2) 合理性原则：
每个生命周期阶段中所列的各个活动、工作和质量控制点，视项目大小可以合理的增加或合拼。如某些大项目，可增加一些对子项目、子工作产品或子活动的质量控制点；小项目或增补少量功能点的项目可将一些质量控制点加以适当合拼，但在计划中必须对合拼的理由做出说明。
3) 可视化原则：
生命周期各阶段中必须明确列出任务、活动、工作产品与质量控制点。
XXX有限公司 第 14 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.2 迭代模型（iterative model）
4.2.1 典型生命周期描述
迭代模型迭代过程项目策划项目策划迭代过程项目策划需求分析需求分析需求分析系统设计系统设计系统设计编码和单元测试软件集成和集成测试系统测试编码和单元测试软件集成和集成测试系统测试编码和单元测试软件集成和集成测试验收和安装
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。实际上，这个模型可看作是重复执行的多个“瀑布模型”。
要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以两周到四周为适当的长度。
主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
优点：
XXX有限公司 第 15 页 / 共 46 页
OPD-GUID-2-生命周期模型
当需求更好的被理解时，开始开发下一个迭代
测试贯穿与整个产品生命周期
缺点：
过程复杂性增加
有可能使产品开发周期增长
不连贯的需求分析
缺乏自然的设计评审点
风险：
取消本来已经完成的
4.2.2 裁剪指南：
对于一些特殊的软件项目，可以根据实际需要，增加或者减少迭代次数。
4.2.3 生命周期各个阶段描述
基于迭代模型的各阶段描述。
一个项目可以有多个迭代组成，每个跌代根据所处项目阶段不同，它的重点和目标是不同的，所以将软件生命周期根据时间顺序划分为三个阶段：立项阶段、迭代阶段、交付阶段，每一个阶段可以有一到多个迭代组成。
立项阶段
立项阶段
1、 确定项目的软件范围和边界条件
目标
2、 识别出系统的关键用例
3、 估计整个项目需要的费用和时间安排，给出第一个迭代的详细计划
4、 评估项目风险
1、建立系统的业务模型
2、 捕获系统的基本需求
3、 确定系统的边界
主要活动 4、 识别关键任务
5、 确定系统验收标准
6、 进行项目风险评估
7、 进行项目资源的估计与效益分析
XXX有限公司 第 16 页 / 共 46 页
OPD-GUID-2-生命周期模型
8、 制定项目开发计划与重要里程碑。
重点
里程碑
确定项目目标。如果需要构造原型系统，则需做一些设计与实现。
生命期目标
1、项目目标文档：系统的核心需求、关键特性与主要约束的总体蓝图
2、 初始的项目术语表
制品 3、 初始的风险评估
4、 一个可以显示阶段和迭代的项目计划
5、 一个或多个原型
1、风险承担者是否赞成项目的范围定义、成本以及进度估计。
2、 是否通过主要用例证实对需求的理解。
评价标准
3、 成本与进度预测的评估以及优先级、风险和开发过程的可信度。
4、 所开发软件原型的深度和广度。
5、 实际开支与计划开支的比较。
如果无法达到这些标准，可能取消项目或重新对项目进行仔细的考虑。
迭代阶段
迭代阶段
目标 1、分析用户需求和系统需求
2、 建立系统架构
3、 编制项目计划
4、 淘汰项目中最高风险的元素
5、 通过优化资源和避免不必要的返工达到开发成本的最小化
6、 根据实际需要达到适当的质量目标
7、 对所有必须的功能完成分析设计开发和测试工作
8、 采用循环渐进的方式开发出一个与硬件部门的接口一致的产品
9、 达成一定程度上的并行开发机制
主要活动 1、分析用户需求，确定对关键需求的理解
2、 分析系统需求，捕获并细化关键的功能需求
3、 定义非功能需求
XXX有限公司 第 17 页 / 共 46 页
OPD-GUID-2-生命周期模型
4、 建立坚实的架构
5、 细化架构并建立可执行的软件
6、 根据已定义的评价准则进行软件测试
7、 与硬件部门进行功能和接口联调
8、 精化风险评估
9、 制定过程迭代计划和迭代的评价标准
10、
重点
资源管理资源控制和过程优化
1、需求分析——精化系统范围和需求，揭示任何遗漏的需求
2、 设计——创建稳定的架构
3、 实现——细化架构，构造可以执行的软件
4、 测试——测试架构，测试软件功能
5、 联调——测试软硬接口，测试产品功能。
里程碑 该阶段可以划分为多个迭代实现，在每个交付点建立里程碑，相邻的交付点之间是一个迭代。如果交付点的间隔时间较长（8周以上）则需要将本次交付阶段划分为多个迭代来实现。
制品 1、用户需求说明书
2、 系统需求说明书
3、 概要设计
4、 详细设计
5、 可运行的软件系统
6、 测试用例
7、 用户手册
8、 发布描述
评价标准 1、需求是否与用户达成一致？
2、 系统分析是否全面彻底？
3、 架构是否稳定？
4、 风险要素是否已被处理并可靠地解决了？
5、 每个迭代的计划是否足够详细和精确？
6、 如果在当前架构上下文中执行计划并开发出整个系统，是否所有的风险承担人都同意系统达到了当前的需求？
XXX有限公司 第 18 页 / 共 46 页
OPD-GUID-2-生命周期模型
7、 实际的费用支出与计划支出是否可以接受？如果无法达到这些标准，可能取消项目或对项目进行重新考虑。软件是否足够稳定和成熟，从而可以发布给用户？
8、 是否所有的风险承担人都准备好了向用户交付软件产品？
9、 实际费用与计划费用的对比是否仍可被接受？
10、
交付阶段
交付阶段
目标 将开发完成的系统提交给客户，具体为
1、进行验收测试以期达到最终用户的需要
2、 对最终用户和产品支持人员的培训
3、 和具体部署相关的工程活动
4、 协调Bug，修订改进性能和可用性等工作
5、 基于完整的Vision和产品验收标准对最终部署做出评估
6、 达到用户要求的满意度
7、 达成各风险承担人对产品部署基线已经完成的共识
8、 达成各风险承担人对产品部署符合Vision中标准的共识
主要活动 1、将软件系统部署到用户环境
2、 修复软件的缺陷
3、 编制用户手册和其它文档
4、 培训用户和维护人员
5、 提供用户咨询
重点 主要关注系统的测试和配置工作流。每个工作流关注如下各项。
1、设计——如果验收测试中出现问题，修改设计。
2、 实现——为用户场地裁减软件，修复在验收测试中发现的问题。
3、 测试——在用户现场验收测试。
4、 配置——将软件系统部署到环境中，并配置相应参数。
里程碑
制品
产品发布
1、可运行的软件产品
2、 用户手册
XXX有限公司 第 19 页 / 共 46 页
如果项目无法达到这些要求，必须推迟进入交付阶段。
OPD-GUID-2-生命周期模型
评价标准 1、用户是否认可系统已经成功部署？
2、 用户是否积极使用该软件产品？
3、 用户是否认可产品支持策略？
4、 如果项目无法达到这些要求，必须推迟交付。
4.2.4 里程碑和基线
在各个生命周期阶段结束时对相应的阶段目标建立里程碑。在需求分析和构建阶段的每个交付点建立里程碑，每个迭代启动前确定本次迭代的交付物，在交付物完成或评审通过（如果需要评审交付物）时对该交付物建立基线。
4.2.5 项目生命周期模型的选择
根据生命周期模型的特点，结合项目的具体情况，进行生命周期的选择。
选出项目符合《生命周期选择表》中的哪些类型：需求类型、项目类型、项目风险、用户类型和团队类型（可选一或选多）
参考《生命周期选择表》确定生命周期模型
4.2.6 选择迭代模型
对稳定并且水平较高的团队来说，迭代开发的代价最小。
迭代最主要的还是解决了风险的问题，不稳定的团队风险更多，应该实施迭代。迭代比实施瀑布代价低。可以通过迭代的方法促进团队成长，这是因为迭代给了大家更多的检查自己工作的机会，也给了更多的改进的机会。迭代开发具有普遍意义。
区别是迭代周期的长短、每个迭代中的工作安排、文档正式化程度、使用的主要的沟通手段等等。
每一次迭代都必须有明确的交付和出口准则。
适宜采用迭代模型的软件项目：
1. 最适合于需求没有完全确定和定义的情况；
2. 迭代模型将创建一个早期的版本可让人感受，以后的迭代将基于以前的迭代；
3. 不稳定团队，迭代最主要的还是解决了风险的问题，不稳定的团队风险更多，应该实施迭代，迭代给了大家更多的检查自己工作的机会，也给了更多的改进的机会；
4. 团队成员经验比较少的话，应该尽可能采用较短的迭代周期，以便于较快得到反馈，不断发现开发工作中的问题，以做出改进。
XXX有限公司 第 20 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.2.7 软件生命周期模型的应用
根据项目的具体情况，在描述的软件生命周期模型中选择软件生命周期。
在明确了软件生命周期模型之后，根据《组织级生命周期模型描述》中说明的各个阶段，进行项目的开发和确定。
4.2.8 输出
参考瀑布模型。
4.3 敏捷模型（Agile model）
4.3.1 典型生命周期描述
产品负责人和开发团队对产品业务目标形成共识；
产品负责人建立和维护产品需求列表Backlog（需求会不断新增和改变），并进行优先级排序；
产品负责人每轮迭代前Review需求列表，并筛选高优先级需求进入本轮迭代开发；
开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成；
开发团队每日站立会议、结对编程、持续集成，使开发进度真正透明；
XXX有限公司 第 21 页 / 共 46 页
OPD-GUID-2-生命周期模型
产品负责人对每轮迭代（2-4周）交付的可工作软件进行现场验收和反馈；
回到第2步，开始下一轮迭代；
优点：
快速地响应变化。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时，都能交付用户一个可用的、可部署的系统，用户使用并体验该系统并反馈意见，在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时地处理需求变化和用户反馈。
精确。敏捷方法则采用小步快跑，每走完一步再调整并为下一步确定方向，直到真正的终点。
质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等，甚至使用测试驱动开发。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。
速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。
丰厚的投资回报率。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。
高效的自我管理团队。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
缺点：
敏捷开发以人为本，对项目经理的要求比较高。如果控制不好，整个项目的风险会比较大。
敏捷对团队人员的素质要求比较高，要求团队能够进行自我管理。
采用敏捷开发的模式，团队成员须在思想上转变，比如结对编程、测试驱动开发等。
4.3.2 生命周期各个阶段描述
敏捷的周期划分为立项阶段和多个迭代阶段。迭代阶段分为初始阶段、计划阶段、冲刺阶段与发布阶段。立项阶段主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划；初始阶段的活动主要包括编写产品Backlog；计划阶段包括了迭代的两次计划会议；冲刺阶段即一个完整的Sprint迭代，周期通常不超过六个星期；发布阶段包括评审会议与回顾会议，此阶段结束后，将发布一个达到迭代目标的增量版本。至于产品的维护，则属于产品Backlog的一部分，列入每次迭代的范围。
XXX有限公司 第 22 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.3.2.1 立项阶段
详见瀑布生命周期模型项目策划阶段说明。
4.3.2.2 迭代阶段
4.3.2.2.1初始阶段
目标
适用标准和规范
相关工具
主要输入
入口准则
参与人员和相关人员
建立和维护产品需求列表，并进行优先级排序
[根据组织的实际情况描述]
[根据组织的实际情况描述]
项目任务书、建议书或工作说明书（SOW）
客户需求/需要
客户需求/需要已被批准
项目任务书、建议书或SOW已被批准
项目经理
产品负责人
客户代表
领域专家
需求分析师
PPQA工程师
1、 获取部分需求
2、 编写产品Backlog
3、 产品Backlog评估会议
产品Backlog
需求已根据优先级排序
需求分析所花的工作量和资金，评审工作量
制定迭代计划
[根据组织的实际情况描述]
活动
主要输出
出口准则
度量
目标
适用标准和规范
相关工具
主要输入
入口准则
4.3.2.2.2计划阶段
任务板、卡片
产品Backlog
存在产品Backlog
Backlog条目已划分优先级
参与人员项目经理
和相关人敏捷教练
员 客户代表
需求分析师
PPQA工程师
CM工程师
开发工程师
测试工程师
XXX有限公司 第 23 页 / 共 46 页
OPD-GUID-2-生命周期模型
活动 1、 迭代计划会议
2、 确定迭代目标、迭代演示日期、每日例会时间地点、团队成员名单、障碍Backlog
3、 拆分迭代 Backlog为任务并进行分配
4、 进行工作量估算并建立燃尽图
5、 创建任务板
主要输出 迭代计划会议纪要
迭代Backlog（包括迭代目标和团队成员名单）
障碍Backlog
燃尽图
任务板
出口准则 迭代计划得到产品经理、客户代表、项目经理及敏捷团队成员的认可。
度量 迭代计划的工作量。
4.3.2.2.3冲刺阶段
目标
适用标准和规范
相关工具
主要输入
实现迭代目标
[根据组织的实际情况描述]
[根据组织的实际情况描述]
迭代Backlog
障碍backlog
燃尽图
任务板
团队成员充分理解需求
团队成员接受过相关技能的培训
项目经理
敏捷教练
客户代表
PPQA工程师
CM工程师
开发工程师
测试工程师
1、 需求澄清
2、 敏捷建模，创建架构模型、类结构模型和测试用例模型
3、 测试驱动开发
4、 结对编程
5、 每日站立会议
6、 持续集成
7、 更新迭代Backlog
8、 更新燃尽模型
UserStory
敏捷模型
测试代码
功能代码
增量产品
入口准则
参与人员和相关人员
活动
主要输出
XXX有限公司 第 24 页 / 共 46 页
OPD-GUID-2-生命周期模型
出口准则 增量产品实现了迭代目标
度量 编码和单元测试的工作量、代码评审缺陷、独立的单元测试缺陷以及评审和返工工作量；
测试的工作量、测试中发现的缺陷。
4.3.2.2.4发布阶段
目标
适用标准和规范
相关工具
主要输入
入口准则
参与人员和相关人员
确保增量软件产品正常使用
[根据组织的实际情况描述]
[根据组织的实际情况描述]
增量产品（可执行文件）
增量产品实现了迭代目标并经过充分测试
项目经理
敏捷教练
产品负责人
客户代表
需求分析师
PPQA工程师
CM工程师
开发工程师
测试工程师
活动
1、 评审会议，
2、 进行迭代演示
3、 回顾会议
4、 编写用户手册和培训手册
主要输出 评审会议纪要
回顾会议纪要
增量产品
用户手册
培训手册
出口准则 迭代演示通过，客户知道如何使用
度量 迭代演示、验收和安装的工作量、验收中发现的缺陷。
4.3.3 里程碑与基线
根据项目情况，敏捷模型的整个项目生命周期根据Sprint迭代次数划分阶段，每个迭代阶段都包括初始、计划、冲刺和发布四个阶段。
里程碑点：每次迭代完成时；
基线点：
产品基线，每次迭代完成产品交付时建立。
4.3.4 项目生命周期模型的选择
根据生命周期模型的特点，结合项目的具体情况，进行生命周期的选择。
XXX有限公司 第 25 页 / 共 46 页
OPD-GUID-2-生命周期模型
选出项目符合《生命周期选择表》中的哪些类型：需求类型、项目类型、项目风险、用户类型和团队类型（可选一或选多）
参考《生命周期模型选择表》确定生命周期模型
4.3.5 选择敏捷模型
适宜采用敏捷模型的软件项目：
持续产生价值，需求有一定不确定性。
规模适中，没有特别约束。
有测试和集成工具支持。
便于和客户交流。
4.3.6 裁剪指南
在实际的使用过程中，根据软件项目的特点可以对敏捷模型进行裁剪。一般而言，以下几种裁剪是经常存在的，只要PPQA工程师同意即可：
产品Backlog中优先级一项可以裁减，按照先后排列顺序作为优先级的高低。
结对编程实践可以裁减，改为传统个人编程方式。
障碍Backlog可以裁减
根据项目需要，在经EPG审核并获得部门总监的批准下，也可对敏捷模型做出其他方式的裁剪。
4.3.7 软件生命周期模型的应用
根据项目的具体情况，在描述的软件生命周期模型中选择软件生命周期。
在明确了软件生命周期模型之后，根据《组织级生命周期模型描述》中说明的各个阶段，进行项目的开发和确定。
4.3.8 敏捷实践
4.3.8.1 管理实践
4.3.8.1.1产品Backlog评估会议
该实践对应瀑布模型需求确认过程，活动如下：
介绍会议的目标；
产品负责人介绍其需要评估的产品Backlog中的部分；
对产品Backlog中的各项问题：
➢ 由产品负责人解释Backlog中该问题背后的详细用例；
XXX有限公司 第 26 页 / 共 46 页
OPD-GUID-2-生命周期模型
➢ 团队各成员选出其手上的一张计划卡片，以投票决定他所认为的该问题的工作量大小；
➢ 所有团队成员同时亮出他们的卡片；
➢ 如果评估结果又分歧，让意见分歧最大的成员进行辩论，然后再次投票，知道所有人意见一致；
➢ 评估结果被添加到Backlog项；
通过简单的总结来结束评估会议。
4.3.8.1.2迭代计划会议
该实践对应瀑布模型需求确认过程，活动如下：
产品负责人对迭代目标进行总体介绍，概括产品Backlog；
定下演示的时间地点；
团队估算时间，在必要的情况下拆分Backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”；
团队选择要放入迭代中的故事。计算生产率，用作核查工作安排的基础；
为每日站立会议安排固定的时间地点；
把故事进一步拆分成任务。
需求澄清
4.3.8.1.3每日站立会议
该实践对应瀑布模型项目监督和控制过程，活动如下：
每日工作前，团队成员的例行沟通机制，由项目经理组织，项目组成员全体站立参加
聚焦在下面的三个主题：
➢ 昨天做了什么？
➢ 计划今天做什么？
➢ 遇到什么困难需要什么帮助以更高效的工作？
每日站立会议需要注意：
准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯；
高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）；
问题跟踪：敏捷教练应该记录下所有的问题并跟踪解决；
XXX有限公司 第 27 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.3.8.1.4迭代验收会议
该实践对应瀑布模型确认过程，活动如下：
每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求；
由敏捷教练组织， 产品负责人和用户代表（外部或内部利益相关人）负责验收、项目组负责演示可工作软件。
展示“真实”的产品：项目组应在真实环境中展示可运行的软件，判断是否达到“完成”标准；
收集反馈：产品负责人 根据验收情况及客户反馈意见，及时调整产品Backlog
4.3.8.1.5迭代回顾会议
该实践对应瀑布模型过程，活动如下：
在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；
围绕如下三个问题：
➢ 本次迭代有哪些做得好
➢ 本次迭代我们在哪些方面还能做得更好
➢ 我们在下次迭代准备在哪些方面改进？
会议气氛：项目组全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；
关注重点：项目组共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；
会议结论要跟踪闭环：可以放入迭代Backlog中。
XXX有限公司 第 28 页 / 共 46 页
OPD-GUID-2-生命周期模型
迭代回顾会议
4.3.8.1.6可视化管理
该实践对应瀑布模型项目监督和控制、风险管理过程，活动如下：
将项目状态 (进度、质量等)通过物理实体（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息。
物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到（存在电脑中的文件不是可视化的）；
内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨；
实时刷新：延迟的信息拖延问题暴露，降低运作效率。
可视化管理
4.3.8.1.7头脑风暴
该实践活动如下：
确定头脑风暴的主题、时间、地点并提前通知相关人员；
头脑风暴负责人讲述初步方案；
讨论方案；
确定方案，头脑风暴结束。
需要进行头脑风暴的活动如下：
需求澄清；
敏捷建模，如：架构设计、数据库设计、接口设计等；
Backlogs设计评审；
4.3.8.2 技术实践
4.3.8.2.1用户故事
该实践对应瀑布模型需求开发过程，活动如下：
用户故事是站在用户角度描述需求的一种方式；
每个用户故事须有对应的验收测试用例；
XXX有限公司 第 29 页 / 共 46 页
OPD-GUID-2-生命周期模型
用户故事是分层分级的，在使用过程中逐步分解细化；
典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。
I – Independent，可独立交付给客户
N – Negotiable，便于与客户交流
V - Valuable ，对客户有价值
E - Estimable ，能估计出工作量
S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成
T - Testable，可测试
用户故事
4.3.8.2.2需求澄清
该实践对应瀑布模型《需求规格说明书》评审过程，在迭代计划会议中进行，活动如下
需求分析师给开发人员讲解需求点；
开发人员评论需求点是否合理，完善；
开发人员大致描述实现该需求点的难点
所有人员对该需求估计工作量，如果估计不统一，则要估计多的人和估计少的人讲解原因，讲解完成后再进行一次估计，选择大多数的估计作为该需求的工作量；
4.3.8.2.3敏捷建模
该实践对应瀑布概要设计和详细设计过程。
敏捷开发把传统软件过程前期的架构设计，分散到了整个敏捷开发过程中，即演进式敏捷建模。需要进行敏捷建模的方面如下：
软件的架构层次，层次化是软件产品架构中很重要的一部分；
XXX有限公司 第 30 页 / 共 46 页
OPD-GUID-2-生命周期模型
产品和技术选型；
各个组件的结构及接口；
重要模块和重要类的说明。
4.3.8.2.4结对编程
该实践对应瀑布模型同行评审过程，活动如下：
两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；
操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；
领航员检视的同时还必须负责考虑下一步的工作方向 ，比如可能出现的问题以及改进等。
程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象；
开始一个新Story开发的时候即可变换搭档，以增进知识传播；
培养团队成员积极、主动、开放、协作的心态能够增进结对编程效果；
实施初期需要精心辅导，帮助团队成员克服个性冲突和习惯差异。
4.3.8.2.5测试驱动开发
该实践对应瀑布模型验证过程，活动如下：
TDD以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化；
TDD要求测试可以完全自动化运行。
测试代码和源代码一样都需要简洁，可读性好；
测试用例的设计要保证完备，覆盖被测单元的所有功能；
每个测试用例尽量保持独立，减少依赖，提高用例的可维护性；
当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用 TDD 实现。
XXX有限公司 第 31 页 / 共 46 页
OPD-GUID-2-生命周期模型
测试驱动开发
4.3.8.2.6持续集成
该实践对应瀑布模型产品集成过程，活动如下：
持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息；
自动化测试用例的完备性和有效性是持续集成质量保障；
修复失败的构建是团队最高优先级的任务；
开发人员须先在本地构建成功，才可提交代码到配置库 ；
持续集成的状态必须实时可视化显示给所有人；
大系统持续集成需分层分级，建立各层次统一的测试策略。
XXX有限公司 第 32 页 / 共 46 页
OPD-GUID-2-生命周期模型
持续集成
4.3.8.3 支持实践
4.3.8.3.1配置管理
详见配置管理过程域文件。
4.3.8.4 度量与分析
详见度量与分析过程域文件。
4.3.8.5 过程和产品质量保证
详见过程和产品质量保证过程域文件。
4.3.8.6 相关的文件
类别
项需求管理 管理需求 产品Backlog
过程域 特定目标 敏捷实践
XXX有限公司 第 33 页 / 共 46 页
OPD-GUID-2-生命周期模型
目管理类
项目策划 建立估计
开发项目计划
获得对计划的承诺
立项阶段
项目监督和控制 对照计划监督项目
管理纠正行动直至关闭
每日站立会议
可视化管理
供方协定管理
集成项目管理
使用项目已定义过程
与相关人员协调和合作
风险管理 准备风险管理
识别和分析风险
缓解风险
障碍Backlog
每日站立会议
可视化管理
用户故事
产品Backlog评估会议
迭代计划会议（需求澄清）
敏捷建模
工程类
需求开发 开发顾客需求
开发产品需求
分析和确认需求
技术解决方案 选择产品构建解决方案
开发设计
实现产品设计
产品集成 准备产品集成
确保接口兼容性
组装产品构建和交付产品
持续集成
验证 准备验证
进行同行评审
验证选择的工作产品
持续集成
测试驱动开发
结对编程
迭代验收会议 确认 准备确认
确认产品或产品构件
支持类
度量和分析 度量和分析
过程和产品质量保证 过程和产品质量保
证
配置管理 配置管理
XXX有限公司 第 34 页 / 共 46 页
OPD-GUID-2-生命周期模型
决策分析和解决
过程管理类
组织过程定义
组织培训
组织过程焦点
确定过程改进的机会
策划和实施过程改进
部署组织过程资产和汇总经验教训
建立组织过程资产
建立组织级的培训能力
提供必要的培训
迭代回顾会议
敏捷生命周期 && CMMI过程域
4.4 原型模型（prototyping model）
4.4.1 咨询立项
参见《立项管理过程定义》中的内容。
XXX有限公司 第 35 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.2 需求分析、项目策划、快速设计和原型评审
本阶段的主要目标是了解客户的主要需求，进行初步策划，完成原型设计，组织客户参与的原型评审，通过几轮上述过程，确定最终客户需求，并通过实际验证所需技术可行。根据需求，同时根据经验数据（组织过程能力基线及项目数据），估算软件开发进度、软件开发经费及其他相关因素，制定相关项目管理计划。完成本阶段需产生的文档。
需求分析时间占开发时间的20%－35%左右；采用的成熟软件技术占80%以上。
4.4.2.1 角色职责
角 色
高层经理
职责
根据情况参与需求规格说明书评审
负责审批项目开发计划
负责组织需求规格说明书评审
负责编制项目计划
负责组织编制配置管理计划、质量保证计划、测试计划、度量与分析计划等
负责组织项目所有管理计划的评审工作
负责组织编制需求规格说明书
相关人员参与评审需求规格说明书
参与项目计划的编制，对各自任务做出承诺
按要求完成编制需求规格说明书
负责编制配置管理计划
参与项目计划的编制，对自己任务做出承诺
按计划建立配置环境，建立基线目录
做本阶段配置审计、配置统计报告
参与需求规格说明书评审
负责编制质量保证计划
参与项目计划的编制，对自己任务做出承诺
审计本阶段过程、工作产品，形成QA报告及相关文档
参与需求规格说明书的评审
开始着手测试用例的编写
负责编制软件测试计划
参与项目计划的编制，对自己任务做出承诺
参与需求规格说明书的评审
按要求开始测试用例编写工作
参与软件测试计划的编制，对各自任务做出承诺
配合项目经理完成需求规格说明书，并确认
参与原型评审
项目经理
项目组成员
配置管理员
PPQA
测试经理
测试人员
客户经理/代表（销售经理）
领域专家
4.4.2.2 4.4.2.2 输入
《项目任务书》
XXX有限公司 第 36 页 / 共 46 页
OPD-GUID-2-生命周期模型
《合同》
4.4.2.3 输入准则
《项目任务书》通过审批
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能
项目资金到位
4.4.2.4 活动和任务
1. 根据组织级项目过程定义裁剪或重新定义为《项目已定义过程》。
2. 《项目已定义过程》由项目经理申请，经过EPG审批。
3. 根据需求开发计划与客户联系进行需求获取。
4. 根据获取的客户原始需求，编写《用户需求说明书》的关键章节。
5. 根据《用户需求说明书》，结合现有软件产品系统，编写《需求规格说明书》的关键章节，建立系统原型。
6. 项目经理组织相关人员对《需求规格说明书》进行走查，走查问题需及时跟踪解决。
7. 在需求规格说明书开始编写并完成走查过程中，测试负责人组织人员考虑系统主要测试用例的编写工作。
8. 根据《项目任务书》和《用户需求说明书》拟订项目计划。
9. 根据走查通过的《需求规格说明书》细化并制定估算记录、WBS、项目计划及相关计划，如：配置管理计划、质量保证计划、测试计划等。
10. 项目经理组织走查项目计划及相关计划。
11. 项目经理组织人员，依据走查通过的《项目计划》时间任务安排，根据《需求规格说明书》，按照TS过程描述，进行概要设计，编制《概要设计说明书》的关键章节。
12. 项目经理组织人员走查《概要设计说明书》。
13. 开发接口设计。
14. 项目经理或项目经理组织人员，依据走查通过的《项目计划》时间任务安排，根据《需求规格说明书》、《概要设计说明书》，编制《数据库设计说明书》的关键章节。
15. 项目经理组织人员走查《数据库设计说明书》。
16. 根据走查通过的《概要设计说明书》和《数据库设计说明书》，项目经理组织人员，针对每个模块完成相应的《详细设计说明书》的关键章节。
17. 项目经理组织人员走查《详细设计说明书》。
18. 项目经理组织相关人员，根据《需求规格说明书》和《概要设计说明书》或《详细设计说明书》，分配相关程序员完成所有软件单元的编码工作；
XXX有限公司 第 37 页 / 共 46 页
OPD-GUID-2-生命周期模型
19. 完成编码后，项目经理组织项目成员对系统主要部分进行编码的单元测试，系统主要部分包括系统主要功能和采用新技术实现的模块等。
20. 组织客户、领域专家对原型模型进行评审，包括需求是否完备、设计方法是否可行，评审通过后确定最终的《用户需求说明书》、《需求规格说明书》、项目计划及附属计划等，并将该阶段所有文档的全部章节补充完整，并通过正式评审。如果评审未通过，则返回第4条，进行新一轮迭代。
21. 快速设计产生的原型需提交配置受控库。
4.4.2.5 输出准则
以上所有文档或计划通过评审或审批
4.4.2.6 输出
《用户需求说明书》(可裁剪)
《需求规格说明书》
《需求跟踪矩阵》
《项目计划》（附《估算记录》、《WBS》）
《质量保证计划》
《配置管理计划》
《测试计划》
《度量与分析计划》
4.4.3 最终系统设计-概要设计与详细设计
概要设计阶段是从实现的角度开发针对客户需求的解决方案，完成软件的架构设计和数据库设计，详细设计是从架构设计和数据库设计入手，完成模块的详细设计或界面设计。
软件需求分析和软件设计的时间占开发周期的15－20％左右；其中软件设计时间约占7％－10％。
4.4.3.1 角色职责
角 色
高层经理
职责
根据情况参与架构设计说明书、数据库设计说明书评审
根据情况参与模块详细设计或界面设计
负责组织设计说明书评审
负责组织编制架构设计、数据库设计说明书
负责协调项目内、外工作中国
负责审核本阶段QA、CM活动
相关人员参与评审设计说明书
按分配工作做设计说明书
项目经理
项目组成员
XXX有限公司 第 38 页 / 共 46 页
OPD-GUID-2-生命周期模型
角 色
配置管理员
PPQA
测试人员
4.4.3.2 输入
《项目任务书》
职责
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
组织编制测试用例
按要求开始测试用例编写工作
《用户需求说明书》
《需求规格说明书》
《项目计划》
4.4.3.3 输入准则
以上文档通过评审或审批
项目人员到位，具体所要求技能或可通过项目计划培训达到要求技能
项目资金到位
4.4.3.4 活动和任务
1. 项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》，按照TS过程描述，重新进行概要设计，编制完整的《概要设计说明书》。
2. 项目经理组织人员评审《概要设计说明书》。
3. 开发接口设计。
4. 项目经理或项目经理组织人员，依据评审通过的《项目计划》时间任务安排，根据《需求规格说明书》、《概要设计说明书》，编制完整的《数据库设计说明书》。
5. 项目经理组织人员评审《数据库设计说明书》。
6. 根据评审通过的《概要设计说明书》和《数据库设计说明书》，项目经理组织人员，针对每个模块细化相应的《详细设计说明书》。
7. 项目经理组织人员评审《详细设计说明书》。
4.4.3.5 输出准则
以上文档通过评审
4.4.3.6 输出
《概要设计说明书》
《接口设计说明书》
《数据库设计说明书》
《详细设计说明书》
XXX有限公司 第 39 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.4 最终系统实现-编码和单元测试
根据软件详细设计，完成软件编码、测试和集成。
本阶段进度占总生命周期的15－35%左右；采用的成熟技术占80%以上。
4.4.4.1 角色职责
角 色
高层经理
职责
根据情况参与代码走查
负责组织代码走查
负责协调项目内、外工作
负责审核本阶段QA、CM活动
负责分配编码工作
负责分配单元测试工作
协调代码走查
组织需求变更管理
完成分配的编码工作
完成分配的单元测试任务
参与代码走查
做本阶段配置统计报告
审计本阶段过程、工作产品，形成QA报告及相关文档
按要求对所负责的模块做单元测试接收工作
项目经理
项目组成员
配置管理员
PPQA
测试人员
4.4.4.2 输入
《需求规格说明书》
《概要设计说明书》
《详细设计说明书》
4.4.4.3 输入准则
软件设计说明书通过评审和批准；
相关人员到位，并接受过相关技能的培训或达到技能要求
4.4.4.4 活动和任务
1. 项目经理组织相关人员，根据《需求规格说明书》和《概要设计说明书》或《详细设计说明书》，分配相关程序员完成所有软件单元的编码工作；
2. 完成编码后，项目经理组织项目成员之间进行编码的单元测试工作，单元测试的覆盖范围为100%；
3. 项目经理组织相关人员，对编码进行走查，覆盖范围应当大于等于60%。
4.4.4.5 输出准则
完成所有模块的编码工作
完成所有模块的单元测试报告
XXX有限公司 第 40 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.4.6 输出
软件代码
《单元测试报告》
4.4.5 集成测试和系统测试
验证客户需求是否都已经实现。
本阶段进度占总研发生命周期的10％－20％。
4.4.5.1 角色职责
角色 职责
负责制定和维护测试计划
负责设计测试过程
对执行测试负责
负责协调资源，评审测试用例，验证测试环境
搭建测试环境，执行单元测试， 集成测试和系统测试，记录测试结果，填写测试问题报告单， 编写测试驱动程序。
参与测试计划及用例的评审，协调处理测试问题报告单，评审测试总结报告。
负责问题和缺陷修复工作
测试负责人
测试人员
项目经理
软件工程师
评审人员(项目经理,
质量保证员, 系统分参与测试过程中产生的关键工作产品的评审。
析员等)
软件验收小组(咨询顾问, 项目经理, 质量制定验收测试计划书, 实施验收测试, 编写验收测试报保证员, 测试负责人告。
等)
4.4.5.2 输入
《测试计划》
《测试用例》
源代码
《单元测试报告》
4.4.5.3 输入准则
测试用例通过评审
代码完成并通过单元测试
4.4.5.4 活动和任务
1. 按照测试计划，搭建集成测试环境；
XXX有限公司 第 41 页 / 共 46 页
OPD-GUID-2-生命周期模型
2. 执行集成和系统测试；
3. 记录测试结果，填写测试问题报告单提交给项目组人员修改；
4. 对修改过的版本进行回归测试；
5. 总结测试结果并编写测试总结报告。
4.4.5.5 输出准则
通过集成测试和系统测试，并完成回归测试
4.4.5.6 输出
《缺陷纪录》
《测试报告》
4.4.6 验收和实施
在验收阶段，系统安装在目标环境中，并在这个环境中进行测试，以确保它满足系统要求，客户满意验收。
进度周期占研发生命周期的10%－20%。
4.4.6.1 角色职责
角色 职责
制订实施计划。
负责组织编写用户手册
项目经理 组织和协调用户参与项目实施过程
分类整理用户的反馈意见和新需求，协商用户提出修改意见
填写验收报告
参与编写用户手册。
参与初始化基础数据，和必要的业务数据。
培训用户使用应用系统，包括帮助用户理解使用系统，讲解业现场实施人员
务操作步骤，解答用户问题。
协助用户验收测试。
收集用户的反馈意见，记录用户新需求。
安装和调试软硬件，部署应用系统。
监测应用系统运行状况。
技术支持人员
及时修改程序，解决现场实施中的问题。
配合数据初始化工作。
参与编写用户手册。
测试人员
根据实施计划和用户现场情况，部分或全程参与培训用户工作。
提供正确版本的文档和产品，确保文档、产品之间的完整性和配置管理员
一致性。
4.4.6.2 输入
《质量总结报告》
《测试总结报告》
XXX有限公司 第 42 页 / 共 46 页
OPD-GUID-2-生命周期模型
配置审计通过的软件产品，和程序包
4.4.6.3 输入准则
软件产品的开发已经完成，并且通过集成测试和系统测试，完成测试总结和配置审计
4.4.6.4 活动和任务
1. 进行实施准备，制定实施计划，编写用户手册、系统安装手册、培训手册等；
2. 安装系统环境，进行数据初始化；
3. 按照客户要求配合客户进行验收测试或试运行；
4. 验收测试通过，客户接收系统，签字确认；
5. 召开项目总结会议，向组织及财富库自交项目资料。
4.4.6.5 输出准则
客户接受系统，验收通过
4.4.6.6 输出
《用户手册》
《验收报告》
《项目总结报告》
《提交给过程资产库的资料清单》
4.4.7 售后维护
在维护期间，对于客户提出的系统交付使用后出现的问题进行修改和维护。
维护时间一般为1年左右。
4.4.7.1 角色职责
角 色
高层经理
客户经理
项目经理
项目维护人员
4.4.7.2 输入
《验收报告》
4.4.7.3 输入准则
系统已经通过客户验收
职责
负责项目人力、物力等资源的保障和管理；
负责项目经费使用的审批；
于客户沟通，协助用户方的维护工作
负责维护的管理工作
负责具体的维护工作
XXX有限公司 第 43 页 / 共 46 页
OPD-GUID-2-生命周期模型
4.4.7.4 活动和任务
1. 按合同签订的维护服务期和任务进行系统维护；
2. 维护期满项目过程中的所有配置项应纳入资产库。
4.4.7.5 输出准则
到达合同签订的维护时间，完成维护任务
客户提出的问题已经得到解决或和客户达成一致协定。
4.4.7.6 输出
《维护记录》
4.4.8 裁剪指南
在实际的使用过程中，根据软件项目的特点可以对原型法进行裁剪。一般而言，以下几种裁剪是经常存在的，只要EPG同意即可：
采用原型法时需求分析、项目策划、快速设计、原型评审阶段内部产生的文档可以只完成文档的关键章节，进行基本走查，等到原型DEMO通过用户认可后再重新界定项目范围和内容，细化该阶段文档的全部内容，并进行正式评审；
最终设计阶段根据项目的实际情况和规模可以细化概要设计阶段和详细设计阶段，细化后的活动和出入口准则可以参考瀑布模型的相关阶段；
如果采用增长式原型，则系统的最终设计和最终实现可以省略。系统的开发过程变成了一边开发，一边试用，然后修正，如此反复，直到用户满意。
根据项目需要，在高层经理的批准下，也可对原型模型做出其他方式的裁剪。
XXX有限公司 第 44 页 / 共 46 页