软件产品项目全流程模板-流程检查表

软件项目-产品检查单-模板

项目管 23 是否包含目标达成措施和未达成措施？
理计划 24 是否包含预测信息及分析?
》 25 有否明确定义了进度计划？
26 是否包含目标和子过程控制表？
产品得分="是"的项数/(总项数-"不适用"的项数)×100
备注
5 WBS是否包含了项目的所有工作？
6 有否明确定义完整的生命周期模型？
7 有否明确定义的进度计划？
8
进度计划是否留有缓冲来减少项目过程中的不确定性？
9 进度计划中任务是否已排序？
10 进度计划中任务是明确定义里程碑计划？
计划》 12 有否明确定义质量控制计划？
项目策划检查表
项目名称项目类别检查开始时间检查工作量统 2H
定制化项目/新开发项目
项目经理检查人检查结束时
分类序号
检查项
是否 NA
《项目 1 是否明确了项目类型？
过程定 2 是否明确定义了各个阶段的活动？
义》 3 是否是按剪裁指南要求进行的剪裁？
4 《项目进度计划》里有否包含了WBS？
13 有否明确定义培训计划？
14 有否明确定义资源计划？
15 有否明确定义费用计划？
16 有否明确定义本项目的干系人？
17 有否明确定义沟通计划？
18 有否明确定义质量保证计划？
19 有否明确定义配置管理计划？
20 有否明确定义度量计划？
21 是否包含项目目标及子过程目标？
《量化 22 是否包含度量计划？

APQP程序文件及完整表格

5.0程序技术部主管根据新产品开发设计Input信息确定新产品开发来源。

技术部主管组织进行成本核算及报价，填写《成本核算及报价表》。

InputProcessOutput Owner项目组长负责编制《新产品APQP开发计划》，并组织项目组实施。

由项目小组组长召集小组有关成员根据项目的要求结合公司实际情况确定设计目标、可靠性目标和质量指标。

A）顾客需要和期望可以是无安全问题和可维修性；B）可靠性基准是竞争者产品的可靠性、消费者的报告或在一设定时间内修理的频率；总的可靠性目标可用概率和置信度表示；C）质量目标应是基于持续改进的目标，如： PPM、缺陷水平或废品降低率； D）设计目标中应包括过程能力、生产率、成本方面的目标。

项目小组对设计输入材料进行评审，评审通过后填写《设计开发任务书》安排设计任务工作，设计输入评审应进行记录，具体填写在《新产品开发输入评审记录》上。

Activity技术部主管组织进行新产品制造可行性分析，并将分析结果填入《新产品制造可行性分析报告》中。

技术部主管根据制造可行性分析结果及成本核算结果，填写《新产品开发申请/立项报告》，并连同《新产品制造可行性分析报告》及《成本核算及报价表》提交总经理审批。

总经理审批后，新产品开发项目即成立，总经理负责授权项目组长，由项目组长组成项目小组。

确定的新产品开发设计目标、可靠性及质量目标由项目组长审批。

确定新产品开发来源●市场调研报告●维修记录和质量信息●小组经验●业务计划/营销策略●产品/过程标杆数据●产品/过程设想新产品开发制造成本核算/报价新产品开发申请成立跨功能小组编制APQP 计划审批停产品开发小组成员表新产品APQP 开发计划成本核算及报价表新产品开发申请/立项报告技术部主管总经理新产品开发项目组长新产品制造可行性分设计输入新产品开发输入评审记录项目小组设计开发任务书安排设计任务●顾客要求输入●与产品有关的法规要求●任何其他要求确定设计目标确定可靠性和新产品开发设计目标、可靠性及质量目标表审批确定初始材料清单初始材料清单(BOM)产品设计人员负责进行DFMEA分析。

软件开发计划检查表模板

1、是否画了有关资源的直方图？
2、是否预算了项目的工作量并划分给小组成员？
九、配置管理
1、是否制定了配置管理计划表？
检查人/日期：批准人/日期：
5、是否考虑软件复用？
五、组织结构
1、是否确定项目小组成员，并将其划分成多个Team?
2、是否明确各个小组成员的职责？
六、风险管理
1、是否预测了与项目有关的主要风险？
2、是否采取跟踪、监测措施以减小风险或避免风险的产生？
七、相关性
1、是否考虑了项目的外部相关活动？
2、是否考虑了项目的内部相关活动？
八、资源预算
三、产品清单
1、是否明确提交给客户的产品清单（产品名称、提交时间、客户接受方式、责任人、验收标准）？
2、是否明确提交给项目监按钮部门的产品清单（产品名称、提交时间、提交方式、责任人）？
四、技术管理
1、是否明确开发环境（软件、硬件环境）？
2、是否明确开发工具？
3、是否明确开发方法？
4、是否采用新技术？
软件
项目名称：项目编号：
检查项目
检查内容
检查结果
得分
一、质量目标
1、是否符合质量体系的要求？
2、如果不符合技量体系的要求，是否按要求编制《质量计划》？
二、阶段划分
1、是否Байду номын сангаас确划分各阶段？
2、各阶段的输入、输出标准是否明确？
3、是否明确各阶段提交物？
4、是否明确各阶段质量目标？
5、是否明确提出各阶段检查点？

IPD产品开发流程图

制定概念阶段项目计划（WBS1/2/3/4级）
MNFPDT-10
开始监控客户服务活动
MNFPDT-20
制定客户服务策略 NT
参与制定业务计划和端到端项目计划（WBS1/2)
MNFPDT-40
PDT制造代表（MNFPDT）
制定概念阶段项目计划（WBS1/2/3/4级）
PROPDT-10
开始监控制造活动
LPDT-180
优化信息安全计划做出提前采购决定
LPDT-170 LPDT-190
制定项目计划优化业务计划开发合同
LPDT-210
IPMT-50
计划决策评审
LPDT-230 NO YES LPDT-240 LPDT-240
制定对外合作计划
LPDT-200
PDT经理（LPDT）
结束
团队培训
项目开工会
MKTPDT-130
MKTPDT-140
监控配置管理及更改 SE-390
SE-340
优化市场计划
SE-300
制定发布计划
技术评审4
SE-370
技术评审4A
SE-380
SE-400
技术评审5
SE-410
准备早期销售决策评审材料
系统工程师（SE）
开始参与执行项目监控
PQA-60
企业标准、企业内控标准起草
MKTPDT-50
参与制定业务计划和端到端项目计划（WBS1/2)
MKTPDT-60
PDT市场代表（MKTPDT）
制定概念阶段项目计划（WBS1/2/3/4级）
概念阶段 WBS3/4级计划模板
开始监控市场活动
SE-10

软件设计评审检查表

该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线?
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
是否将需求分别陈述,因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y：是 TBD:不确定 N：不是 NA：不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
测试计划进程表开发阶段测试阶开发组集成测试承测试组系统测试业主联合测试软件需求分析完成确认测试计划完成系统测试计划软件概要完成软件集开始设计确开始设计软件设计评审检查表设计成测试计划认测试用例编写确认测试说明系统测试用例编写系统测试说明软件详细设计完成软件单元测试计划开始设计集成测试用例编写集成测试说明软件编码编写软件单元测试说明执行软件单元测试编写软件单元测试报告软件测试完成集成测试说明执行集成测试进行测试分析编写软件集成测试报告完成软件确认测试说明执行软件确认测试进行测试分析编写确认测试报告完成系统测试说明执行系统测试进行测试分析编写系统测试报告

软件项目过程文档评审检查表

过程模板模板是否符合iso表单模板要求表格的表头是否使用统一的淡蓝色表格中的字体是否统一模板中文字描述是否合理。
评审耗时（小时）
是否通过 N/A,Y,N
缺陷个数
缺陷描述
版本号：2 修订号：0
第1页共1评审人
评审日期
评审规模（页）
序号
1 1.1 1.2 1.3
1.4
1.5
1.6
2 2.1 2.2 2.3 2.4
检查项
过程规范是否符合过程文件模板要求规范中的角色是否已经定义清楚活动中对应的角色是否正确活动的描述是否使用了多余的形容词和副词规范中的模板是否用蓝色标注出来规范中提到的模板是否和定义的模板一致

软件项目检查表

软件项目检查表
项目概述
该软件项目检查表旨在帮助团队对软件项目进行全面的检查和
评估，以确保项目的顺利进行和高质量的交付。

本检查表包括多个
方面，包括项目计划、需求分析、设计、开发、测试和部署等环节。

项目计划
- 项目是否有明确的目标和可行的计划？
- 是否有详细的项目计划及时间表？
- 是否有项目经理负责监督和管理项目进度？
需求分析
- 是否完整、准确地收集和记录了项目的需求？
- 是否对需求进行了合理的分类和优先级排序？
- 是否与相关利益相关者沟通确认了需求？
设计
- 是否进行了系统的架构设计和模块设计？
- 是否充分考虑了扩展性和可维护性等因素？
- 是否进行了界面设计和交互设计？
开发
- 是否按照设计文档进行开发工作？
- 是否按照编码规范完成代码编写？
- 是否进行了代码评审和单元测试？
测试
- 是否制定了详细的测试计划和测试用例？
- 是否进行了功能测试、性能测试和安全测试等多个方面的测试？
- 是否及时修复了测试中发现的缺陷和问题？
部署
- 是否制定了可靠的部署计划？
- 是否进行了部署前的完整测试和验证？
- 是否提供了必要的文档和培训？
运维支持
- 是否确保了系统的可靠性和稳定性？
- 是否建立了监控和报警机制？
- 是否保障了系统的安全性和数据的完整性？
以上是软件项目检查表的主要内容，通过对每个方面的检查和评估，能够有效提升软件项目的质量和成功交付的概率。

请针对具体项目的不同需求和情况，适当调整和完善该检查表。

软件产品项目全流程模板-评审意见表

评审文件列表：
文件电子版存档路径：
文档电子版访问授权人员名单：
评审时间：2006年01月16日
项目评审人（签字）
部门总经理：_________________________
产品经理：___________________________
设计负责人：_________________________
测试人员：___________________________
评审意见表
项目名称及项目编号：游戏BBS迁移需求规格说明书
（项目编号：IBD_PN_06003）
评审阶段
产品规划书评审
需求说明书评审
概略测试计划评审
概要设计评审
精确测试计划评审
开发流程类型选择（□完整□简化）
概略日程表评审
整体日程表评审
项目计划评审
其他评审：______________________
运营总监：___________________________
项目经理：___________________________
开发人员：___________________________
其他支持人员：_______________________
评审意பைடு நூலகம்：
____________________（签字）

项目管理检查表

项目管理检查表——项目计划编制1、已经撰写了项目的问题报告。

2、项目使命已经通知到了所有参与者。

3、已经识别风险，并在可能的情况下编制了应急措施。

4、核实P、C、T、S可行性的项目战略。

5、满意的力场分析。

6、已对后果进行了分析并且是可接受的。

7、所有项目人员都理解了项目的最终目标。

8、至少对变量P、C、T、S其中之一进行了估算，而不是指定所有四个变量。

9、有项目绩效需求的明确定义。

10、有评估绩效目标的合适标准。

11、编制出的项目分解结构的级数足以使成本、时间和资源需求的估算达到满意的准确度。

12、WBS已接受如下审查：客户、贡献者、高级管理层。

13、按照计划进行审查的进度里程碑已经确立。

14、遵照WBS，已经完成了网络形式的任务级进度计划。

15、已经识别出关键路径。

16、关键路径可以满足要求的结束时间。

17、为确定关键路径是否现实，对其进行了检查。

18、作为工作工具，编制了甘特图。

19、为确保资源没有过载，检查了资源分配。

20、不要以高于80%的生产率进行资源分配。

21、消除和解决了与其他项目的资源冲突。

22、已经设计出控制系统。

23、已经建立了项目评估方法。

24、执行项目计划的人员应参与计划编制。

25、计划应在合适的级别（既不能太大，也不能太小）。

26、如果可能，估算应基于类似项目的记录。

27、估算扩充已公开完成。

28、对于管理层来说，扩充应可接受。

29、项目计划已经在最终确认会上审查通过。

30、项目笔记已由项目干系人签署。

31、最终确认会上提出的所关心的问题已得到令每个人都满意的解决。

32、计划包括以下内容：问题说明、使命说明、项目战略、项目目标、QFD分析或识别客户需求的其他方法、SWOT分析、项目范围说明、可交付成果清单或其他合同要求、需达到的成品规范、工作分解结构、里程碑和任务级进度计划、资源需求、控制系统（包括变更控制程序）、以线性责任图形式表示的主要贡献者、风险分析和应急措施、要求的工作说明。

软件项目过程文档评审检查表模板

软件
编号：___________________
项目名称
项目编号
评审人
评审日期
评审规模
评审耗时
序号
检查项
是否通过N/A,Y,N
缺陷个数
缺陷描述
1
过程规范
1.1
是否符合过程文件模板要求
1.2
规范中的角色是否已经定义清楚ቤተ መጻሕፍቲ ባይዱ
1.3
活动中对应的角色是否正确
1.4
活动的描述是否使用了多余的形容词和副词
1.5
规范中的模板是否用蓝色标注出来
1.6
规范中提到的模板是否和定义的模板一致
2
过程模板
2.1
模板是否符合iso表单模板要求
2.2
表格的表头是否使用统一的淡蓝色
2.3
表格中的字体是否统一
2.4
模板中文字描述是否合理。

IT行业软件项目开发流程及文档汇总

软件项目开发流程规范版本管理目录1.0目的 (4)2.0范围 (4)3.0责任 (4)4.0流程文件列表 (4)5.0开发工作流程图 (5)6.0实施步骤与干系人关系 (8)6.1产品意向提出 (9)6.2市场调研及产品规划书起草 (9)6.3产品规划书评审 (9)6.4流程类型选择 (10)6.5需求说明书起草与日程表拟定 (10)6.6需求说明书与日程表评审 (11)6.7测试用例与测试计划起草 (11)6.8测试计划评审 (12)6.9概要设计与概要设计书起草 (12)6.10概要设计书评审 (12)6.11项目计划与项目分解 (13)6.12项目计划评审 (13)6.13项目软件开发及例会与汇报制度管理 (13)6.14软件测试和测试报告 (14)6.15项目总结与产品发布 (14)7.0风险管理 (15)IBD软件项目开发流程规范1.0目的建立并文件化一种软件产品的规划、评审、设计、计划、开发、控制与测试的流程，以确保软件产品能够在规定的时间内达到所有指定的需求。

本规范特别强调在项目进行过程中持续进行的高效能的团队沟通以及及时总结，良好的流程依赖于执行者忠实地贯彻才能够发挥最大的作用。

2.0范围本流程适用于国际业务部（IBD）所有新产品的开发，包括从初始的产品概念提出一直到进入产品发布，其包括了完整软件开发流程和简化软件开发流程两类开发流程。

其项目阶段包括：产品意向提出、市场调研及产品规划书起草、产品规划书评审、流程类型选择、项目需求说明书起草与日程表拟定、需求说明书与日程表评审、测试计划起草、测试计划评审、概要设计与概要设计书起草、概要设计书评审、项目计划与项目分解、项目计划评审、项目软件开发及例会与汇报制度管理、软件测试和测试报告、项目总结与产品发布等阶段。

3.0责任IBD负责管理本流程，并负责维护和保障本流程的实际运行。

项目干系人包括：部门总经理、运营总监、产品经理、项目经理、设计负责人、开发人员、测试人员及技术总监等其他支持人员。

2-VDA6.3检查表P1-P7

示例
⁻决定自制还是外购 -供方选择标准 -供方开发计划 -项目供方名单 -批准的供方清单 -与指定供方的风险评估 -零件分类 -服务供方，如开发、实验室、维护保养等
⁻时间计划 -过程描述 -变更管理 -变更表格 -产品和过程变更历史 -变更评审 -变更批准
⁻根据具体的风险，约定事态升级的时间范围 -在事态升级程序中规定了联系人/ 决策者 -规定了事态升级标准以及沟通路径 -包括措施在内里的里程碑评价记录
⁻包含里程碑的项目计划 -有关技术和/或产品组的顾客特殊要求 -顾客的项目计划 -顾客的时间期限 -顾客的里程碑 -顾客的目标要求（里程碑的衡量） -里程碑评价（评审） -质量计划（例如，来自于VDA MLA 或APQP） -具体国家或地区的特殊认证要求（ECE、SAE、DOT、CCC…) -关键系统的的法律法规批准流程（电镀、喷漆…)
⁻资源规划的证据（兼顾其他项目） -设备的资源规划（例如，开发用测试平台）
在资源规划中，应特别关注关键路径。
针对人员和设备需要的项目预算，进行
了策划并批准。
项目组织机构内发生变更时（与顾客的
接口），需进行报告。
审核发现
评分
P2-P7 * 2.3 2.4
VDA6.3过程审核-2016版P部分
P1
运输&零部件处置
范围（内部和外部供方）。
定期监控计划的符合性和目标的达成情
况。
审核发现
评分
VDA6.3过程审核-2016版P部分
P2-P7 2.5 2.6 2.7
* P1 *x *x x
运输&零部件处置
过程要素
项目是否已经落实与采购相关的活动，并监督了落实情况？

产品开发流程图

RDPL-c30 RDPL-c40
研发代表（RDPL）
主导样机制作
SE-c10 SE-c20
组织设计资料输出/BOM上网
参与TR3评审
参与早期销售决策材料
系统联调
SE-c30
样机制作检查表
系统测试
SE-c40
系统工程师（SE）
制定培训计划
培训计划模板 EE-c10
制作培训资料/技术监控
主导系统联调
组织编写业务计划书/概要进度计划
业务计划书计划到发布阶段概要计划
立项论证决策前沟通
立项决策评审要素表决策评审报告模板决策评审操作指导书
项目经验教训总结
项目经验教训总结报告 POP-a20
项目经验教训总结
POP-a30
POP
创建项目环境
项目环境检查清单
关闭项目数据库和环境
结束
更新项目数据库和环境
DFMEA
DFMEA模板 EE-b20
主导TR2评审
主导概要设计
EE-b30
硬件工程师 (EE)
参与制定产品规格书
ME-b10
参与DFMEA
电子概要设计
电子概要设计模板
ME-b20
ME-b30
ME-b40
ME-b50
结构工程师(ME)
参与制定产品规格书
SWE-b10
参与DFMEA
概要设计（ID问题反馈、解决）
主导制定计划阶段详细计划
计划阶段详细计划 PM-b10 模板 POP-b10
决定是否提前采购
提前采购检查清单
主导优化业务计划书/ 制定项目详细计划
业务计划书项目详细计划模板

新项目开发流程表

新项目开发流程表
在进行新项目开发时，一个清晰的流程表是非常重要的。

这个
流程表可以帮助团队成员了解项目的整体进展，明确各自的责任和
任务，并确保项目按时完成。

下面是一个典型的新项目开发流程表，供大家参考。

1. 项目立项阶段
- 确定项目目标和范围
- 制定项目计划和时间表
- 确定项目预算和资源需求
- 确定项目团队成员及其职责
2. 需求分析阶段
- 收集用户需求和期望
- 分析市场竞争情况
- 确定产品功能和特性
- 制定产品需求文档
3. 设计阶段
- 进行产品原型设计
- 确定产品界面和交互设计 - 制定技术架构和系统设计 - 编写详细的设计文档
4. 开发阶段
- 进行编码和编程工作
- 进行单元测试和集成测试
- 不断优化和调整产品功能 - 确保代码质量和安全性
5. 测试阶段
- 进行系统测试和验收测试 - 发现和修复产品缺陷和问题 - 确保产品性能和稳定性
- 编写测试报告和文档
6. 上线阶段
- 进行产品部署和发布
- 监控产品运行情况
- 处理上线后出现的问题
- 确保产品正常运行
7. 运营阶段
- 收集用户反馈和意见
- 不断优化和更新产品功能
- 进行市场推广和宣传
- 确保产品持续运营和发展
以上是一个典型的新项目开发流程表，每个阶段都有具体的任务和活动。

在实际项目开发中，团队成员可以根据实际情况对流程表进行调整和补充，以确保项目顺利完成。

同时，流程表也可以作为项目管理工具，帮助团队成员清晰地了解项目进展，提高工作效率。

软件正版化工作检查表

附件1
软件正版化工作检查表
单位名称：自查时间：序号检查项目检查内容
软件正版化工作机构和责任制度
年月
日检查结果
检查依据
文件、工作记录
是□
否□
1
责任落实情况
2016年软件正版化工作总结和2017年软件正文件、工作记录版化工作计划 2015-2017年软件正版化工作检查整改文件、工作记录
检查计算机台数判定安装盗版软件标准：安装的软件名称及版本与采购的软件名称及版本不一致（可免费使用的正版软件除外；采购某软件厂商高版本软件，实际使用该软件厂商低版本软件，并且有该软件厂商出具的降级使用授权书的除外）
台
安装盗版操作系统软件的计算机台数
台
4
现场检查计算机情况
安装盗版办公软件的计算机台数
是□
否□
是□
否□
规范计算机软硬件采购流程 2 源头监管情况
文件、工作记录
是□

否□
新采购计算机办公设备时，预装正版操作系统软件，对需要购置的办公软件和杀毒软件文件、工作记录一并作出购置计划正版软件管理制度文件、工作记录文件、软件台账、软件采购合同、软件授权协议
是□
否□
有□
无□
3
正版软件管理情况正版软件使用情况台账有□ 无□
台
安装盗版杀毒软件的计算机台数安装Windows8或Windows 10操作系统软件的计算机台数备注：如有需要说明的事项，可在此栏填写，也可另附页说明。
台
台

ck_检查表_软件工程.xls

8
技术代码中注释的数量是否合理？
9
技术调试信息是否被注释掉？
10
技术局部变量和全局变量的定义是否没有冲突？
11
技术是否有冗余或无用的变量？
12
技术变量和属性是否都正确的初始化？
13
技术变量使用结束后是否都赋了空值？
14
技术被赋值的变量，其变量类型是否一致或被正确转换？
15
技术代码能否通过本地的编译和调试？
21
技术每一个布尔测试，是否都检查过正确的条件？
符合
不符合不适用
备注
22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
确认信息
技术技术技术技术技术技术技术技术技术技术技术技术技术技术技术
循环结束的条件是否明显，并总能够达到？被除数是否做了零值测试？所有的边界值是否都作了考虑，并正确的进行了处理？如果一个循环有多个出口，是否每个出口都正确处理？ Switch声明是否都有default条件？循环和分支的嵌套是否过深？是否不合理？数组是否被合理定义范围？标记的不确定或错误的代码是否被改正？每个程序段是否只有一个入口和一个结束点？调用文件前是否被打开？文件使用后是否被关闭？所有的I/O异常是否被正确的处理？是否所有的代码都能有效被调用或执行？代码是否准确的实现了需求要求？代码是否准确的实现了设计要求？
过程
》配置管理员是否依据《发布申请审核单》，从产品库中提取产品组件
过程打包顺序是否在《发布申请审核单》中描述
符合
不符合不适用
备注
6 7 8 9
确认信息
过程过程过程过程

软件过程检查表格模板

精心整理
1.过程检查要素表
2.过程打分
2.1.过程打分原则：
1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。

2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了
使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。

3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。

4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容
和实施情况剪裁必须得到项目经理和受审计人员的认可。

5)软件过程检查打分的依据是“过程检查表”。

2.2.打分步骤：
1)依据标准过程定义项目过程，得出项目过程数N。

2)每个项目过程的得分M＝30/N。

3)采用“过程检查表”，对各个过程进行检查和打分。

4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的
5)/该
6)
7)
8)
9)
分计算。

2.3.
第一次
第二次
C=5.3＋5.6＋5.3＋5.7＋5.6＝27.5
3.过程检查表
3.1.计划过程检查表
3.5.系统设计过程检查表
3.6.需求和设计管理过程检查表
3.7.软件编码过程检查表
-来源网络。

项目策划过程检查表

对项目进行了成本估算，并符合要求的估算过程
对估算结果进行了评审，并符合要求
策划过程
参与项目策划过程人员是否接受估算和项目策划方面培训
以软件任务书和SRS作为策划基础
选择了合适的生命周期模型
对生命周期模型进行裁减，是否有合理的理由
项目产生的软件工作产品是否进行确认
策划过程与相关部门和人员充分协商，并取得了他们的承诺
审核签字
角色
姓目策划过程检查表
编号：
项目名称
项目编号
软件项目经理
此次检查时间
报告人
日期
内容
已经完成
部分完成
尚未完成
不适用
注释
项目估算
对项目进行了合理的分解，并区分复杂度
对项目进行了规模和工作量估算，并符合估算过程
对项目进行了进度估算，并符合要求的估算过程
对项目进行了风险估算，并符合要求的估算过程
对项目进行了资源估算，并符合要求的估算过程
同时考虑了项目管理、集成、测试、SCM、SQA等工作
已经剔除了停工、假期等影响工作时间的因素
策划形成的软件开发计划与用户要求、合同等不相矛盾
计划评审
软件项目开发计划形成文档
计划评审过程符合公司规定、标准要求
项目相关部门和人员同意，并签字认可
公司的对外承诺是否得到高级管理者的认可
项目开发计划经过SCCB批准