软件项目过程定义表模版.docx
《软件项目过程定义表模版.docx》由会员分享，可在线阅读，更多相关《软件项目过程定义表模版.docx（44页珍藏版）》请在冰豆网上搜索。
软件项目过程定义表模版
项目过程定义表
文档编号：
项目编号:
受控状态：
受控
版本号：
V1。
0
2014年1０月15日
修订记录
类别:
A–增加M – 修改D–删除
版本
日期
制定
类别
批准
描述（注明修改的条款或页）
1.0
2014-１0—09
胡秋苹
Ａ
1．项目生命周期选择ﻩ1
2。
ﻩ项目已定义过程1
2。
1通用过程裁剪1
2．2 项目开发过程裁剪矩阵３
２.2。
１瀑布型3
2。
2.2迭代型1０
2。
3项目支持过程裁剪矩阵ﻩ18
3．ﻩ偏差说明19
4。
ﻩ审核过程２0
项目过程定义表
项目名称
项目编号
项目开始日期
项目计划完成日期
1.项目生命周期选择
提示：
请在选择栏划√,并在“选择理由”栏说明理由．
可选生命周期模型
选择理由
瀑布型
迭代型
螺旋型
增量型
2.项目已定义过程
2.1通用过程裁剪
通用过程：
适用于所有生命周期模型
适用的生命周期模型:
√瀑布型√增量型√迭代型√螺旋型
阶段
过程
过程元素
裁剪
属性
裁剪选项
输出
裁剪准则
生命周期全阶段
项目监控
活动
项目计划监控
频率
□每周一次
□每两周一次
项目计划监控一览表
项目周期较长（6个月以上）的项目,可以选择每两周一次
周期性项目进展
评估与汇报
频率
□每周一次
□每两周一次
项目周报
项目周期较长（6个月以上）的项目，可以选择每二周一次
项目里程碑评估
方式
□正式
□非正式
项目里程碑报告
当里程碑节点是阶段结束点时，采用正式评估,其它里程碑评估方式由项目经理根据对项目控制的重要程度决定
问题与偏差管理
／
/
项目计划监控一览表—差异与问题管理
/
风险管理
活动
制定风险管理计划
方式
□专题计划
□含在项目计划中
风险管理计划
中小项目风险管理计划可含在项目计划中
风险管理计划技术评审
可选
□需要
□不需要
专题计划需要单独的技术评审
方式
□ 非正式评审
检查表
评审报告
风险识别与应对
/
／
风险列表
/
风险监控
／
/
项目风险列表（包含于“项目计划监控表”中）
／
项目风险管理总结
方式
□单独总结报告
□含在项目总结报告中
风险管理总结报告
/
供应商管理
过程
可选
□ 需要
□ 不需要
不需要:
如果项目不涉及采购和外包，可裁剪该过程
活动
制定采购计划
方式
□专题计划
□在项目计划中
采购计划
/
采购计划技术评审
可选
□需要
□不需要
专题计划需要单独的技术评审
方式
□非正式评审
技术评审检查表
技术评审报告
选择供应商
方式
□自主采购
□招标
供应商评价表
原则上采购单价大于5０万元的设备、软件和外包或同类设备总额大于10０万元时，采用招标方式
签定合同
可选
□需要
□不需要
合同与合同审批表
不需要:
供应商为公司内部时
/
/
采购产品交付计划
/
监控合同执行情况
可选
□需要
□ 不需要
合同执行状态报告
不需要：
非合同方式
可选
□需要
□不需要
外包过程监控报告
需要：
外包方式
到货验收
／
／
采购产品验收报告
/
产品交付
/
/
/
2.2项目开发过程裁剪矩阵
项目经理在EPG组与和项目团队的协助下，在所选生命周期模型的指导下，对项目开发裁剪矩阵进行裁剪，定义项目的项目开发过程需要的活动和输出。
注:
不同的生命周期模型具有不用的开发过程,本表支持二种类型的生命周期模型,瀑布型、迭代型,在定义的过程中,可以依据项目特点定义。
不需要的生命周期模型，请删除。
2.2.1瀑布型
适用的生命周期模型：
√瀑布型ﻩ□迭代型□螺旋型
阶段
过程
过程元素（活动）
裁剪属性
裁剪选项
输出
裁剪准则
*3立
项
项目计划
召开项目启动会议
方式
□Eｍail
□ 正式会议
会议纪要
Eｍail：
项目组成员少于5人
制定初步项目计划
／
／
项目计划
/
获取对项目计划的承诺
方式
□ 口头
□Emａil回复
□ 签字
根据承诺对于项目的重要性，项目经理自己确定
需求
分析
阶段
需求开发
、
技术评审
需求调研
可选
□需要
□ 不需要
需求调研计划
需求调研报告
不需要:
用户提出明确纸质需求时；维护型项目
／
／
需求讨论会议记录
/
需求分析、需求定义
/
/
需求讨论记录表或
会议记录
/
可选
□需要
□不需要
客户需求说明书
不需要：
用户提供纸质需求文档时;维护型项目;软件产品研发;
/
/
产品需求说明书
/
/
/
需求双向追踪表
/
客户需求评审
可选
□ 需要
□ 不需要
不需要:
用户提供完整用户需求说明书时（用户提供纸质需求文档时;维护型项目）
方式
□非正式评审
□正式评审
评审检查表
技术评审报告
产品需求说明书评审
方式
□ 正式评审
评审计划
评审检查表
技术评审报告
客户需求确认
方式
□会议
□会签
客户需求说明书
根据客户要求确定
项目计划阶段
项目计划
、
验收（计划）
、
系统测试（计划）
、
技术评审
项目过程定义
/
/
项目过程定义表
/
项目估算
／
/
项目估算报告
／
制定项目计划
/
/
项目计划
／
项目计划评审
方式
□正式评审
□Email回复
□签字
评审计划
评审检查表
管理评审报告
根据承诺对于项目的重要性，项目经理自己确定
制定验收计划
/
/
验收计划
／
制定系统测试计划
/
／
系统测试计划
/
系统测试计划同行评审
方式
□正式评审
□ Eｍail回复
□签字
评审计划
评审检查表
管理评审报告
/
概要设计阶段
概要设计
、
系统
测试（
设计）
、
技术评审
制定备选方案并评选
可选
□ 需要
□不需要
备选方案评估准则及评估方法
备选方案评估分析表
备选方案
需要:
技术、需求上具有创新性或者大型项目
不需要:
1。
在需求、技术等方面与以前项目高度类似的项目
２.采用相同技术方案的维护型项目
新技术评价
可选
□需要
□ 不需要
新技术评价表
需要：
需制定备选方案且备选方案中含有新技术
不需要:
1.不需制定备选方案2。
备选方案中不含新技术
概要设计
/
／
概要设计说明书
接口一览表
／
概要设计评审
方式
□正式评审
□Eｍail回复
技术评审计划
技术评审检查表
技术评审报告
／
设计系统测试用例
/
/
系统测试用例
/
系统测试用例评审
方式
□一般评审
□ Ｅmaｉｌ回复
技术评审检查表
技术评审报告
/
详详细设计阶段
产品集成（计划）
、
详细设计
、
集成测试（计划和
设计）
、
技术评审
制定集成计划
/
／
集成计划
／
集成计划技术评审
方式
□正式评审
□其他
技术评审表
技术评审报告
制定集成测试计划
/
/
集成测试计划
/
集成测试计划技术评审
方式
□会签
□Emａiｌ答复
□正式评审
技术评审表
技术评审报告
详细设计
可选
□需要
□ 不需要
当满足如下情况时，可将详细设计合并至《概要设计说明书》:
１.小项目，系统复杂程度低,开发人员能力足以根据概要设计进行开发
2.中小项目,为以前项目的后继或派生，开发人员了解程序结构和需求
3．中小项目，采用以前成熟项目的系统结构和设计思想,开发人员了解程序结构
４.使用成熟的构架进行设计、且概要设计已包括详细设计信息
5．不变更技术方案的维护型项目，且开发人员了解结构和需求
方法
□面向对象
□面向过程
详细设计说明书（面向对象）
详细设计说明书（面向过程）
详细设计说明书技术评审
方式
□一般评审
技术评审表
技术评审报告
／
设计集成测试用例
/
／
集成测试用例
/
集成测试用例技术评审
方式
□一般评审
技术评审表
技术评审报告
/
编码
与单元测试阶段
单元测试（计划和设计）
、
编码实现
、
技术评审
、
单元测试
制定单元测试计划
方式
□按照《测试计划模板》制定
□ 含在《项目计划》的附件《项目进度计划》中
单元测试计划
项目进度计划
自主研发大项目
中、小项目或者合同项目
单元测试计划技术评审
方式
□一般评审
技术评审表
技术评审报告
支持文档编写
文档种类
培训材料
用户手册
安装手册
操作手册
可根据项目的具体要求,编制上述文档中的一至多份
支持文档技术评审
方式
□一般评审
□Ｅmａiｌ回复
技术评审检查表
技术评审报告
／
设计单元测试用例
方式
□按照《测试用例模板》制定
□开发人员自己编写,格式不做限制
单元测试用例
＊2关键软件代码组件
非关键软件代码组件
单元测试用例技术评审
方式
□一般评审
□ 可不专门做评审,可在测试时采用交叉测试执行方式验证
技术评审表
技术评审报告
＊２关键软件代码组件
非关键软件代码组件
编码实现
/
／
源代码
/
代码技术评审
方式
□代码走查
□ 正式评审
代码走查报告
技术评审计划
技术评审表
技术评审报告
项目经理自定
*2关键软件代码组件
执行单元测试
/
/
测试用例的执行历史
缺陷管理
频率
□事件驱动（有缺陷时）
测试记录单
根据测试情况而定
编写单元测试报告
方式
□ 合并到工作周报
个人工作周报
项目周报
/
集成与集成测试阶段
产品集成
、
集成测试
集成测试发布
/
□ Eｍail
Emａｉl
/
建立集成环境
/
／
集成环境检查单
/
确保接口兼容性
/
/
会议纪要
/
确认产品构件准备就绪
/
/
／
产品集成
／
/
集成后的产品
集成日志
/
执行集成测试
/
/
测试用例的执行历史
/
缺陷管理
频率
□事件驱动（有缺陷时）
测试记录单或Bｕg管理系统
根据测试情况而定
编写集成测试报告
/
/
个人工作报告及项目周报
／
产品打包
/
/
产品包
/
系统测试阶段
系统测试
系统测试发布
/
□Ｅmail
／
集成测试通过，方可申请系统测试
执行系统测试
/
/
测试用例的执行历史
/
缺陷管理
频率
□事件驱动（有缺陷时）
测试记录单或Bug管理系统
根据测试情况而定
编写系统测试报告
/
／
系统测试报告
/
验收阶段
验收过程
验收测试申请
/
□Email
□正式申请
验收测试申请
/
＊3对软件产品的验收测试
方式
□用户验收测试
□用系统测试替代或部分替代
验收测试报告
用系统测试报告替代或部分替代
根据合同、任务书的要求和项目本身的情况选择一种或多种方式。
当系统测试环境符合或可模拟产品预期使用环境时,系统测试可作为软件产品内部验收测试
验收和产品交付
/
/
发布清单
/
问题处理
频率
事件驱动
根据验收测试和验收情况而定
编写验收报告
／
/
验收报告
/
产品发布（最终版本发布）
/
／
/
全生命周期
需求管理
需求变更
频率
事件驱动
变更申请表
当需求发生变更时
更新维护《需求双向追踪表》
频率
事件驱动
需求双向追踪表
事件驱动：
根据项目情况而定
注：
＊1:
立项的度量数据应包含在项目管理类中，不单独按阶段统计。
注:
＊2:
关键软件代码组件.对关键组件（或组件的部分）的选择需要考虑如下的风险条件：
Ø使用了新的技术、方法、工具,缺少经验的组件,比如新领域的软件开发；
Ø关键的架构性的组件；
Ø必须准确和优化的复杂逻辑或算法;
Ø具有多个异常条件或失败模式的组件；
Ø不易测试的异常处理代码；
Ø打算复用的组件；
Ø将作为其他组件的模型或模板的组件;
Ø影响产品多个部分的组件；
Ø复杂的用户界面;
Ø由缺乏经验的开发者创建的组件；
Ø以往具有很多缺陷或变更的模块。
符合这些条件中任何一种或几种被认为是高风险的，我们都视为关键组件.
注：
*3：
对软件产品的验收测试,关键是要在软件产品的预定使用环境中来确认其满足预期用途。
项目的合同、任ﻩ务书或项目本身的项目计划的制定要考虑这个关键因素。
在项目中可能是采用一种或多种方式来确认的。
2.2.2迭代型
适用的生命周期模型：
□瀑布型√迭代型□螺旋型
阶段
过程
过程元素（活动）
裁剪属性
裁剪选项
输出
裁剪准则
初始计划阶段
项目计划
召开项目启动会议
方式
□ Ｅｍail
■正式会议
会议纪要
Email:
项目组成员少于5人
制定初步项目计划
/
/
项目计划
／
获取对项目计划的承诺
方式
□口头
■Ｅmaｉl回复
□签字
根据承诺对于项目的重要性，项目经理自己确定
需求阶段（第1次迭代）
需求管理和需求开发
需求调研
可选
□需要
■ 不需要
需求调研计划
需求调研报告
不需要:
用户提出明确纸质需求时（如国税总局直接下达明确任务书）；虽然没有明确的纸质需求,但需求非常明确,（如采用新技术的产品升级项目等）
需求分析、需求定义
／
/
需求讨论会议记录
／
可选
■需要
□不需要
用户需求说明书
不需要：
用户提供纸质需求文档时；产品升级时
/
/
产品需求说明书
/
需求跟踪
/
/
需求双向追踪表或需求管理系统
/
需求确认
方式
□会议
■会签
客户需求确认表
根据客户要求确定
需求变更
/
／
变更申请表
/
项目计划阶段（第1次迭代）
项目计划
项目过程定义
／
／
项目过程定义表
／
项目估算
/
/
项目估算报告
/
制定项目计划
/
/
项目计划
/
获取对项目计划的承诺
方式
□ 口头
■Email回复
■签字
根据承诺对于项目的重要性，项目经理自己确定
设计和编码实现阶段（第1次迭代）
技术方案
制定备选方案并评审
可选
■需要
□不需要
备选方案评估准则表
备选方案
中小项目备选方案评估分析报告
需要：
技术、需求上具有创新性或者大型项目
不需要：
在需求、技术等方面与以前项目高度类似的项目
新技术评价
可选
■需要
□不需要
新技术评价表
需要：
需制定备选方案且备选方案中含有新技术
不需要：
1。
不需制定备选方案2.备选方案中不含新技术
确定设计准则
方式
□ 单独形成表格
■含在产品需求说明书中
设计准则及接口准则表
已在《产品需求说明书》中明确表达时不需此表
概要设计
/
/
概要设计说明书
详细设计
可选
■需要
□不需要
当满足如下情况时,可将详细设计合并至《概要设计说明书》:
1.小项目，系统复杂程度低,开发人员能力足以根据概要设计进行开发
2.中小项目,为以前项目的后继或派生,开发人员了解程序结构和需求
3.中小项目,采用以前成熟项目的系统结构和设计思想，开发人员了解程序结构
4.使用成熟的构架进行设计、且概要设计已包括详细设计信息
方法
■面向对象
□ 面向过程
详细设计说明书（面向对象）
详细设计说明书（面向过程）
需求双向追踪
/
/
需求双向追踪表或需求管理系统
根据项目情况而定
编码实现
/
/
源代码
／
支持文档编写
文档种类
培训材料
用户手册
操作手册
安装手册
维护手册
可根据项目的具体要求,编制上述文档中的一至多份
验收阶段（第1次迭代）
产品集成
制定集成计划
/
／
集成计划
/
建立集成环境
/
/
集成环境检查单
/
确保接口兼容性
／
/
/
确认产品构件准备就绪
/
/
/
产品集成
/
/
集成后的产品
集成日志
/
产品打包
/
／
产品包
／
测试（单元测试）
制定单元测试计划
方式
□按照《测试计划模板》制定
■ 含在《项目计划》的附件《项目进度计划》中
单元测试计划
项目计划
自主研发大项目
中、小项目或者合同项目
编写单元测试用例
可选
■需要
□不需要
单元测试用例
需求双向追踪
/
／
需求双向追踪表或需求管理系统
根据项目情况而定
执行单元测试
/
/
测试记录单
／
缺陷管理
频率
□ 事件驱动
测试记录单
根据测试情况而定
编写单元测试报告
方式
□单独形成报告
□包含在其他报告
单元测试报告
人个工作报告、项目周报中
自主研发大项目
中、小项目或者合同项目
测试（集成测试）
制定集成测试计划
/
/
集成测试计划
/
编写集成测试用例
／
/
集成测试用例
／
需求双向追踪
/
/
需求双向追踪表或需求管理系统
根据项目情况而定
执行集成测试
/
/
测试记录单
/
缺陷管理
频率
□事件驱动
测试记录单
根据测试情况而定
编写集成测试报告
／
/
集成测试报告
/
测试（系统测试）
制定系统测试计划
/
/
系统测试计划
/
编写系统测试用例
/
/
系统测试用例
／
需求双向追踪
／
／
需求双向追踪表或需求管理系统
根据项目情况而定
执行系统测试
/
/
测试记录表
／
缺陷管理
频率
□事件驱动
测试记录表
根据测试情况而定
编写系统测试报告
/
/
系统测试报告
／
验收
申请验收
/
／
验收申请
/
验收
/
／
/
问题处理
频率
事件驱动
问题管理系统
根据验收情况而定
编写《验收报告》
/
/
验收报告
／
需求阶段（第Ｎ次迭代）
需求管理和需求开发
是否重新开发需求
□ 需要
□不需要
不需要：
如果在第一次迭代的阶段就已经做好了N次迭代的需要开发。
否则每次迭代开始前必须重新做需求开发。
需求调研
可选
□需要
■不需要
需求调研计划
需求调研报告
不需要:
用户提出明确纸质需求时（如国税总局直接下达明确任务书）；虽然没有明确的纸质需求，但需求非常明确,（如采用新技术的产品升级项目等）
需求分析、需求定义
/
/
需求讨论会议记录
/
可选
■需要
□不需要
用户需求说明书
不需要：
用户提供纸质需求文档时；产品升级时
/
/
产品需求说明书
／
需求跟踪
/
/
需求双向追踪表
/
需求确认
方式
□会议
■会签
客户需求确认表
根据客户要求确定
需求变更
/
/
变更申请表
/
项目计划阶段（第N次迭代）
项目计划
修改项目计划
可选
■需要
□不需要
项目计划
需要:
若项目计划没有对该次迭代的内容进行计划
获取对项目计划的承诺
可选
■需要
□不需要
不需要:
该次迭代没有引入新的项目干系人
方式
□口头
■Emaiｌ回复
■签字
根据承诺对于项目的重要性,项目经理自己确定
注:
如果该次迭代没有引入新的项目干系人则无需选择该项
设计和编码实现阶段（第N次迭代）
技术方案
制定备选方案并评审
可选
□需要
■ 不需要
备选方案评估准则表
备选方案
中小项目备选方案评估分析报告
需要：
技术、需求上具有创新性或者大型项目
不需要:
在需求、技术等方面与以前项目高度类似的项目
新技术评价
可选
□需要
■不需要
新技术评价表
需要：
需制定备选方案且备选方案中含有新技术
不需要：
１。
不需制定备选方案2.备选方案中不含新技术
确定设计准则
方式
□ 单独形成表格
■ 含在产品需求说明书中
设计准则及接口准则表
已在《产品需求说明书》中明确表达时不需此表
概要设计
方式
■ 修改概要设计
□重新进行概要设计
概要设计说明书
修改概要设计：
如果系统框架没有发生大变动,否则需要重新进行概要设计
详细设计
可选
■ 需要
□不需要
当满足如下情况时，可将详细设计合并至《概要设计说明书》:
１．小项目，系统复杂程度低,开发人员能力足以根据概要设计进行开发
2.中小项目,为以前项目的后继或派生,开发人员了解程序结构和需求
3.中小项目,采用以前成熟项目的系统结构和设计思想,开发人员了解程序结构
4。
使用成熟的构架进行设计、且概要设计已包括详细设计信息
方式
■修改详细设计□重新设计
方法
■面向对象
□ 面向过程
详细设计说明书（面向对象）
详细设计说明书（面向过程）
编码实现
/
/
源代码
/
支持文档编写
文档种类
培训材料
用户手册
操作手册
安装手册
维护手册
可根据项目的具体要求，编制上述文档中的一至多份
需求双向追踪
/
/
需求双向追踪表或需求管理系统
根据项目情况而定
验收阶段（第N次迭代）
产品集成
制定集成计划
／
／
集成计划
/
建立集成环境
/
/
集成环境检查单
/
确保接口兼容性
/
/
/
确认产品构件准备就绪
/
/
/
产品集成
/
/
集成日志
集成后的产品
/
产品打包
/
/
产品包
/
测试（单元测试）
制定单元测试计划
方式
□按照《测试计划模板》制定
■含在《项目计划》的附件《项目进度计划》中
单元测试计划
项目计划
自主研发大项目
中、小项目或者合同项目
编写单元测试用例
/
/
单元测试用例
/
需求双向追踪
/
/
需求双向追踪表或需求管理系统
根据项目情况而定
执行单元测试
/
/
测试记录单
/
缺陷管理
频率
□事件驱动
测试记录单
根据测试情况而定
编写单元测试报告
/
/
升级会员 