CMMI体系文件OPD标准软件过程裁剪指南.docx
《CMMI体系文件OPD标准软件过程裁剪指南.docx》由会员分享，可在线阅读，更多相关《CMMI体系文件OPD标准软件过程裁剪指南.docx（12页珍藏版）》请在冰点文库上搜索。
CMMI体系文件OPD标准软件过程裁剪指南
Preparedon21November2021
CMMI体系文件OPD标准软件过程裁剪指南
****信息系统有限公司
标准软件过程裁剪指南
文件编号：
版本号：
编制：
日期：
审核：
日期：
批准：
日期：
****信息系统有限公司
标准软件过程裁剪指南
文件编号：
版本号：
编制：
日期：
审核：
日期：
批准：
日期：
文件修订记录
时间
作者
主要修订内容
1目的
本文件的目的是提供公司标准软件过程的裁剪方法，指导项目经理和QA根据项目特征，对公司的标准软件过程进行裁剪，制定项目的开发过程。
2适用范围
本过程适用于公司的所有软件开发项目。
3资源和工具
引用模型和标准：
CapabilityMaturityModelIntegration（CMMISM）,Version
GB1526-89《信息处理数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定》
工具：
MicrosoftWord
MicrosoftExcel
MicrosoftVisio
MicrosoftVisualSourceSafe
4定义和缩写
表1定义和缩写表
术语/缩写词
定义
FP
独立功能（增、删、改操作的上一级）
5职责
表2角色职责表
角色
职责
质量管理部经理
审批《裁剪报告》。
项目经理
负责对项目进行标准软件过程的裁剪。
QA
指导和协助项目经理进行过程裁剪。
EPG
对项目裁剪方法给出意见或建议；维护裁剪指南。
6指南
6.1启动条件
《用户需求说明书》审批通过。
6.2输入
无
6.3活动
6.3.1确定项目特点
先根据项目规模、项目复杂度、项目关键性、项目组经验、需求明确性对项目进行分类。
要素编号
要素
高/大
中/中
低/小
A
项目规模
>=400FP
>=100FP，<400FP
<100FP
B
项目复杂度
复杂功能的比例>50%
复杂功能的比例>=30%但<50%
复杂功能的比例<30%
C
项目关键性
有发展前景
发展前景一般
无发展前景
D
项目组经验
丰富
一般
少
E
需求明确性
有非常明确的需求说明书
有较明确需求
说不清需求
6.3.2裁剪要求
下面给出了裁剪的具体要求，在项目进行裁剪时，必须首先认真阅读裁剪要求，之后才能进行裁剪报告的填写。
这里介绍一下豁免，豁免是指在组织允许的情况下，可以不执行组织级或项目级的必要任务，跳过整个过程或活动的一种特殊裁剪方式，对这种特殊裁剪称为豁免。
6.3.2.1裁剪对象
裁剪对象是组织标准软件过程中的工程过程以及部分管理过程，裁剪一般包括过程的裁剪和工作产品裁剪。
6.3.2.2裁剪原则
应根据项目特点进行过程裁剪；
裁剪不仅是减少过程，也可以根据质量或其它要求添加过程，以及对过程进行修改，使其更符合项目的特点；
项目经理和QA可以根据实际情况的需要，采用本指南中规定的裁剪方法之外的方法对项目过程进行裁剪，但所采用的裁剪方法必须经EPG同意。
6.3.2.3裁剪产物
项目经理和QA根据项目特点，对标准组织过程进行裁剪，其裁剪结果就是项目实施的过程，作为项目计划的一部分进行评审。
工作产品的裁剪请参照《工作产品汇总表》中的裁剪说明，过程内容裁剪参看下面说明。
6.3.3软件生命周期的裁剪指导
每种软件生命周期都有其优点、缺点和其适于的项目环境。
在裁剪中也应该考虑项目所选的软件生命周期模型的特点，进行合理裁剪。
当前只提供了一种软件生命周期供选择，即瀑布模型。
此模型包括5个阶段：
定义、设计、实现、测试、发布；包括7个里程碑：
需求定义、需求分析、概要设计、详细设计、系统集成、系统测试、项目确认。
软件生命周期
裁剪指导
瀑布型
原则上瀑布模型的各个阶段均不可裁剪。
其中，需求定义、详细设计是可裁剪的。
瀑布型项目各个阶段依次进行，因此后续开发对前期进行的需求开发的可靠性有很高的要求，在这样的过程中，用户需求说明书、软件需求规格说明书应至少分别进行过一次正式评审。
在技术解决过程中，概要设计应至少进行过一次正式评审。
6.3.4过程裁剪指导
6.3.4.1概要裁剪
过程名称
影响要素
是否有裁剪内容
需求开发与需求管理
A、E
是
技术解决和产品集成
A、B、C、D
是
验证
C、A
是
确认
否
项目计划
B、其他
是
项目监控
其他
是
风险管理
否
配置管理
A、B、其他
是
过程与产品质量保证
其他
是
度量与分析
A、其他
是
决策分析与决定
否
组织培训
其他
是
组织过程焦点
否
组织过程定义
否
6.3.4.2详细裁剪
对应各个开发阶段，对过程中的活动依照以下要求进行裁剪，如果有些情况未被提及，则原过程的活动不应该被裁剪。
6.3.4.2.1需求开发与需求管理
该过程对需求明确性最为敏感，其次是项目规模。
情况
裁剪
需求明确性低，项目规模大
应制定《需求调研计划》。
《用户需求说明书》评审时必须有用户或用户代表到场。
应考虑聘请该领域的专家参与进行《软件需求规格说明书》的同行评审。
需求明确性低，项目规模小
必须进行《用户需求说明书》的同行评审。
《用户需求说明书》评审时必须有用户或用户代表到场。
需求明确性高，项目规模大
评审时可以没有用户或用户代表到场。
需求明确性高，项目规模小
评审时可以没有用户或用户代表到场。
可以在一次评审中同时进行《用户需求说明书》和《软件需求规格说明书》的评审。
需求明确性高（用户提供了明确的需求说明）
制定《需求调研计划》和需求收集可以裁剪。
6.3.4.2.2技术解决过程
情况
裁剪
项目规模小
概要设计和详细设计可以合并在一起，最后出一份概要设计即可。
单元测试相关文档可以裁剪，只记录BUG。
复杂度为低的中、小型项目
备选方案选择可以裁剪。
项目关键性高
必须有资深系统分析员参与评审。
必须进行代码走查和代码评审。
项目关键性低
《用户手册》可以不进行评审。
项目组经验低
必须进行代码走查和代码评审。
6.3.4.2.3验证
6.3.4.2.3.1测试
情况
裁剪
项目关键性高
测试结果必须由资深测试工程师进行评审。
项目规模小
可以将集成测试与系统测试进行合并。
6.3.4.2.3.2评审
情况
裁剪
由评审组长根据评审内容决定是否要求评审人员提交预读记录
同行评审前评审人员提交《预读记录》可裁剪。
由评审组长决定本次评审是否需要产品检查表
使用产品检查表可裁剪。
6.3.4.2.4项目计划
情况
裁剪
项目复杂度低
确定项目的技术方法、项目工作分解活动的工作任务单、软硬件资源计划、决策计划、培训计划可以裁剪。
项目研发人数小于5人
人力资源计划可以裁剪。
项目周期在1月以内
项目进度计划、项目监控计划、验收计划可以裁剪。
6.3.4.2.5项目监控
情况
裁剪
项目研发成员小于等于3人
项目例会可以取消。
项目周期小于3个月
进度评审可以和里程碑评审重合。
6.3.4.2.6配置管理
情况
裁剪
项目规模小，或复杂度低，或者因为进度紧等其他原因
项目计划基线和详细设计基线可以裁剪。
其余基线不可裁剪。
6.3.4.2.7过程与产品质量保证
情况
裁剪
当事件驱动的质量检查和定期质量检查的时间间隔小于等于定期检查时间周期的50%
定期的质量检查可裁剪。
6.3.4.2.8度量与分析
情况
裁剪
项目经理根据项目的规模等具体情况
制定《数据收集与分析计划》时可以对标准度量项进行裁减。
6.3.4.2.9组织培训
情况
裁剪
培训时间小于半天且受训人数小于10人的培训
除《培训（教育）记录》外其他都可裁剪，但临时外训的《培训实施计划》不可裁剪。
培训时间小于等于1天的培训
除《培训（教育）记录》、《培训反馈表》（内训）/《培训心得》（外训）、《培训总结报告》外其他都可裁剪，但临时外训的《培训实施计划》不可裁剪。
培训时间小于半天且受训人数小于10人的内训方式的部门级别临时培训
《培训实施计划》的审批可裁剪。
6.3.5使用该裁剪范围以外的裁剪方法
若出现项目经理和QA必须使用该裁剪指南指定的裁剪方法以外的方法对项目过程进行裁剪，那项目经理和QA必须在裁剪时及时与EPG沟通，并获得EPG的同意，并在项目计划评审时进行评审。
该裁剪方法将在项目结束时进行评估，可以作为裁剪过程的补充，并由EPG决定是否将此裁剪方法记录进入本指南。
6.3.6填写裁剪报告
QA指导和协助项目经理进行过程裁剪。
项目经理根据《裁剪报告》模板，填写裁剪内容。
《裁剪报告》应由质量管理部经理审批。
6.3.7裁剪过程的收集和推广
《裁剪报告》应被纳入项目的配置库。
裁剪过程同时应被收集在组织过程财富库中。
项目应对裁剪内容进行跟踪，在项目结束时应分析本次裁剪是否对项目造成了影响，影响有哪些方面。
组织应对裁剪过程进行深入分析，检查是否应将裁剪内容加入标准软件过程。
6.4输出
《裁剪报告》
组织过程财富库
6.5关闭标准
《裁剪报告》通过审批。
7审核
《裁剪报告》应由质量管理部经理审批。
8度量
裁剪活动的工作量
9培训
对项目经理和QA进行关于标准软件过程裁剪的培训。
升级会员 