某某工程设计审查实施要领指南.doc

作业标准S-10000总页数44正文22附件22文件控制部门:项目管理部设计审查实施要领指南沈阳东东系统集成有限公司目录1.全体DR的通用事项1)DR中的课题、残留问题以及未完成事项6/222)DR中使用的文档6/223)证据的确认、成果的确认6/224)DR-G，H的可选性6/222.DR-Q合同内容的审查（在签订合同前召开）1)订货经过6/222)系统概要7/223) 需求规范7/224) 交纳期限7/225) 验收条件7/226) 有无客户方验收7/227) 目前的日程7/228) 总结7/223.DR-A接受订货内容和开发计划的审查1)系统概要7/222)系统规范8/223)开发环境8/224)大日程（事件）8/225)体制、联络途径8/226)向客户缴纳物品-通过订货规范书来确认8/227)接收文档、数据8/228)电子媒体的保管、维护8/229)风险管理8/2210)总结8/224.-按功能规范（需求定义）检查开发计划（需求定义结束后进行）。1)系统概要8/222)需求规范的更改管理8/223)中遗留事项的确认8/224)系统开发计划的确认8/225)性能预测(目标性能)-对性能管理表进行确认9/226)硬件配置与规模9/227) 可靠性9/228) 确认功能规范书的内容9/229)测试方针10/2210)知识产权10/2211)接收文档、数据10/2212)电子媒体的保管与维护10/2213)配置管理10/2214)设计验证10/2215)准确性的确认10/2216)总结10/225.系统设计方针的审查（在系统设计结束后召开）。1)系统概要-基于系统设计书进行说明11/222)需求规范的更改管理11/223)到上一为止的遗留事项11/224)日程-对系统开发计划书中的日程表进行确认。11/225)系统设计内容-对实际成果（文档）进行确认11/226)性能预测-对性能管理表进行确认。11/227)测试方针11/228)接收文档与数据11/229)电子媒体的保管与维护11/2210)配置管理11/2211)风险管理-筛选与推测的风险项目12/2212)设计验证12/2213)准确性的确认12/2214)总结12/226.程序设计内容与编码、调试方针的审查（在程序制作前进行）1)系统概要-基于系统设计书进行说明12/222)需求规范的更改管理12/223)到上一为止的遗留事项12/224)日程-对系统开发计划书中的日程表进行确认。12/225)文档的完成情况-对实际成果进行确认12/226)程序制作标准12/227)测试规范-依照单体测试规范书12/228)单体测试准备情况13/229)接收文档与数据13/2210)电子媒体的保管与维护13/2211)配置管理13/2212)风险管理-筛选与推测的风险项目13/2213)设计验证13/2214)准确性的确认13/2215)总结13/227. 1程序完成情况与单体测试结果、组合测试体制的审查（单体测试后召开）1)系统概要-基于系统设计书说明13/222)需求规范的更改管理13/223)到上一为止的遗留事项13/224)日程-对系统开发计划书中的日程表进行确认。14/225)文档的完成情况14/226)编程内容与完成情况-根据程序清单、审查记录来确认14/227)单体测试结果14/228)组合测试准备情况14/229)性能评价的确认14/2210)接收文档与数据14/2211)电子媒体的保管与维护14/2212)配置管理14/2213)风险管理-筛选与推测的风险项目14/2214)设计验证15/2215)准确性的确认15/2216)总结15/228.2组合测试结果内容的审查（综合测试前召开）1)系统概要-基于系统设计书说明15/222)需求规范的更改管理15/223)到上一为止的遗留事项15/224)日程-对系统开发计划书中的日程表进行确认。15/225)组合测试结果15/226)对性能评价的确认15/227)文档的完成情况15/228)综合测试准备情况15/229)公司内部与用户方的验收方针16/2210)接收文档与数据16/2211)电子媒体的保管与维护16/2212)配置管理16/2213)风险管理-筛选与推测的风险项目16/2214)设计验证16/2215)准确性的确认16/2216)总结16/229.综合测试结果检查（结束综合测试后召开）1)系统概要-在系统设计书中说明16/222)需求规范的更改管理17/223)到上一为止的遗留事项17/224)日程-在系统开发计划书中的主工程表中确认。17/225)组合测试结果-依据出厂认可申请书与综合测试规范书成绩书。17/226)对性能评价的确认-以综合试验规范书与成绩书及性能管理为依据。17/227)客户方的验收准备状况17/228)知识产权17/229)文档的完成情况17/2210)提交物品17/2211)验收条件17/2212)公司验收会17/2213)产品完成程度的评价18/2214)现场调试作业方针与准备情况18/2215)接收文档与数据18/2216)电子媒体的保管与维护18/2217)出厂软件的保管18/2218)配置管理18/2219)风险管理-筛选与推测的风险项目18/2220)准确性的确认18/2221)维护体制18/2222)总结18/2210. 审查会（只对标准产品）19/2211.DR-G(可选项)现场调试作业的验收1)系统概要-基于系统设计书进行说明19/222)到上一为止的遗留事项19/223)日程-对系统开发计划书中的日程表进行确认。19/224)验收指出事项-在用户端实施验收时，用验收检查备忘录进行确认。19/225)现场情况19/226)现场调试准备情况19/227)验收条件19/228)接收文档与数据19/229)电子媒体的保管与维护19/2210)配置管理19/2211)风险管理-筛选与推测的风险项目19/2212)出厂软件的保管19/2213)准确性的确认20/2214)总结21/2212.DRH(可选项)现场调试作业的结果及综合验收1)系统概要-基于系统设计书进行说明21/222)到上一为止的遗留事项21/223)日程-在现场作业要领书中确认。21/224)现场调试结果的确认21/225)维护服务体制21/226)文档的修改与保管情况21/227)性能评价-按现场性能测定的数据来评价21/228)接收文档与数据21/229)电子媒体的保管与维护21/2210)出厂软件的保管21/2211)配置管理21/2212)风险管理-筛选与推测的风险项目21/2213)准确性的确认21/2214) 总结22/22附DR 检查表·DR-Q 检查表1/22(附)·DR-A 检查表2/22(附)·DR-B 检查表5/22(附)·DR-C 检查表8/22(附)·DR-D 检查表10/22(附)·DR-E1 检查表12/22(附)·DR-E2 检查表14/22(附)·DR-F 检查表16/22(附)·DR-G 检查表19/22(附)·DR-H 检查表21/22(附)1.全体DR的通用事项1)DR中的课题、残留问题以及未完成事项实施DR后，审查的课题、剩余问题以及由于进度延迟而未完成的事项，要全部无遗漏地记录在“DR记录（研讨事项和跟踪）”中，并进行跟踪。2)证据的确认、成果的确认在各个DR中，一定要对各个DR中的作业结束证据（WalkThrough记录、DR记录等）和成果进行确认。2. DR-Q合同内容的审查（在签订合同前召开） （软件包软件没有DR-Q）本DR是与客户洽谈的部门将成交内容向开发承担部门说明后，洽谈部门与开发承担部门一起对合同内容进行审查和确认。在有基本合同的情况下，进行的项目洽谈，可以以审查批准的签字形式进行DR-Q。1)交易对象的情报洽谈部门负责说明下述事项，确认本公司与客户的关系，及重要事项。·何时，以什么方式成交的？·成交当中的重要事件·与其它公司的竞争状况·客户关键人物等综合以上各点，对以下的基本事项进行明确：（1） 客户名（2） 客户地址（3）客户的特点（4）谈判期限2)系统需求的概述可用图示说明有关硬件的构成、软件构成。（1）硬件构成（2）软件构成（3）是否为新开发系统3)需求规范对需求规范进行详细的说明（包括是否使用客户提供品或者从其它公司购入的物品等）。（1）有无用户提供物品（2）从其它公司购入物品（3）需求事项是否明确（4）与需求有关的技能的确认（5）与需求有关的资源的确认 ·人员负荷 ·开发场所 ·购入品、提供物品、其它（6）进口（输入）管理 ·进口管理的实施项目 ·是否需要进口管理4)是否与其他公司存在竞争5)预算 ·客户的预算6)交纳日期对客户要求的交纳期、以及是一次交纳还是分期交纳等进行说明。（1）提交用户日期（2）用户开始使用日期7)估价方法8)接受委托的风险 ·有无系统集成的要求、有无新的软硬件、工期、开发体制、委托规模范围不明、要求性能 、 客户规模、客户窗口9 )当前的日程计划·DR-A预定日期的确认10)总结11)确认是否再次实施DR 3.DR-A交接文档和开发计划的审查1)接受委托经过·委托重点（本系统的销售重点）（1）客户名（正式名）·窗口部门、最终提交部门（2）提交方（正式名）·窗口、 最终提交场所（3）系统名称（4）委托金额 （5）交付期（6）关联公司（7）合同（委托）条件·知识产权·机密保护·维护内容/条件/体制·保证内容/保证期限·责任范围·用户指定产品的使用·适用法规类·保证项目 ·运行率/故障率要求 ·性能要求 ·处理容量要求 ·精度要求 ·其它2)DRQ遗留事项 发行DR记录（根据商讨项目与跟踪的件数来确认）3)系统概要 ·开发方针的确认·系统功能概要·硬件，软件构成· 系统运行条件 休息日、夜间运行的确认· 工作范围 委托范围现场调试4)系统规范（1）系统规范的确认 ·故障、 恢复规范的确认 ·2000年对应问题（作为系统）（2）（本公司）要求事项（3）交接文档的确认 （根据规范交接书中确认）5)验收条件（包含性能） 6)新开发产品（新技术开发项目）（1）硬件关系 购入硬件（2）软件产品 公司内部开发、购入软件7)合同内容的确认（1）估价内容（根据）的确认 (2)估价要反映出全部要求事项（3）有无满足要求事项的技能（4）和资源（人员负荷）（5）要求事项与估价的差异（6）有无发行编号（7）投入管理妥当与否确认8)开发环境（1）设置场所 具体场所（2）设置日程（3）费用负担形式（4）设备管理9)用户验收会检查有无（1）期限（2）内容10)大日程（事件）（1）规范、用户批准预定日（2）用户提供物品、数据预定 交付日期（3）出厂预定日（4）现场硬件设置预定日（5）现场作业时间（6）试运行开始预定日（7）正式运行开始预定日（8）DRB预定日的确认（9）到下次DR前的WT计划11)体制、联络表（1）用户方体制、负责窗口（2）本公司体制、负责、分担12)向用户交纳物品（1）提出程序 （种别/媒体/数量 其它）（2）提出文档的名称以及时间与数量（3）其它13)接受文档/数据（1）接受文档/数据管理14)电子媒体的保管/维护（1）文档/数据的备份15)风险管理 筛选/推测的风险项目 预定之外发生的作业16)总结17)确认是否再实施DR 4.-按功能规范（需求定义）检查开发计划（需求定义结束后进行）。 以明确开发计划为目的，这儿将以怎样执行计划为目的。1)系统概要· 硬件构成· 软件构成和功能规范2)需求规范的更改管理需求规范的内容有了更改时，应迅速修改规范，并接受审批。而且要确认有没有实际实施更改处理。3)到上一为止的遗留问题4)系统开发计划的确认（1）开发方针商讨 (2)软件功能规范的确认 (3)软件开发任务分配 用户/其它公司/购入 本公司内部门/合作公司 (4)开发体制图（作用、人员） (5)风险管理 ·筛选/推测的风险项目 ·预定之外发生的作业（6）提供物品的管理 (7)日程计划（开发过程） ·用户在内的事件计划 ·与其它部门的交接计划 ·综合化计划 ·DR计划 ·进度状况 （大，中，小日程表） ·主要作业项目的计划 （8）软件的留用（继承） (9)开发工具 ·使用语言 ·CASE工具 ·测试工具 ·其它（库等）(10)要制作的文档的种类/承担者/期限/是否提交(11)开发环境 机器、空间(12)验收计划的确认 ·检查范围/场所/机器 (13)提交计划·提交成果物/验收条件/维护 (14)设计规则：人机界面规测标准/术语集 ·规范书制作/编码/测试检查 （15）项目运行规则（16）购入软硬件的评价计划5)性能预测(目标性能)-对性能管理表进行确认即使客户要求没有确定下来也要设定目标值。明确目标值设定、预测中的性能、内存或硬盘等的硬件条件（型号，容量）和操作系统、基本库的版本等软件条件是非常重要的。如果不精确的话，将无法进行性能分析。6)硬件配置与规模从目标性能、处理容量、可靠性等的检查结果来确认此硬件配置与规模有无问题。对于开发方来说，硬件的条件越宽越好。对于要求严格的用户（营业）来说，成本越低越好。这时应根据双方最大限度的让步来决定，但不能破坏与客户的协定。7)可靠性错误恢复、备份，调试或开始使用后发生不合格等时，讨论对障碍的处理对策。对调试或开始使用后发生的不合格的处理应注意不要影响产品性能。8)估价确认 第二阶段估价9)功能规范书内容确认应确认如下内容：·人机接口系列(界面·报表等) ·错误处理 ·故障对策 ·通信规范/网络规范 ·数据结构（文件、记录等） ·程序结构 ·系统接口 ·2000年对应（作为系统） ·WalkThrough记录 10)测试方针明确本系统的主要功能、危险点等重要点后，制订测试的方针。·测试目的·测试范围、内容（单体、组合、综合）·测试环境 特别是应提前对测试用工具（含模拟器）是否合适进行评价。·质量目标(检查覆盖率、错误密度、错误命中率)（注）对于做为质量目标可以设定的项目，应设定目标值后再使用。 ·WalkThrough记录 11)知识产权 (1) 知识产权审查12)接收文档、数据从外部接收文档、数据时，应在记录的同时进行必要的管理。13)电子媒体的保管与维护为了在磁盘出现故障时能得到迅速恢复，而将其备份到能进行恢复的外部媒体中进行保管。14)配置管理设计文档、程序、环境、接收文件和数据的配置管理是必须的，确认相应的计划与实施情况。15)技术成果目标 软件认证/注册16)设计验证 (1) QCP的成果是否全通过设计验证(2) 实施WT是否全被记录且作为设计的验证的证据(3)WT的实施情况 ·前回DR后WT结果 ·下次DR前的计划17)总结结束时，归纳整理出遗留事件与问题点，并据实记录到记录的研讨事项与跟踪表中。19)确认是否再进行DR 5.系统设计方针的审查（在系统设计结束后召开）。确认系统设计结束时无设计方面的问题。1)系统概要-基于系统设计书进行说明在确认有无更改的同时，面向第三者进行说明。·硬件构成·软件构成与功能确认2)需求规范的更改管理需求规范的内容发生更改时，应迅速修改规范，并接受审批。而且要确认有没有实际实施更改处理。3)到上一为止的遗留事项4)日程-对系统开发计划书中的日程表进行确认。(1)大日程与事件D、E1、E2、验收、出厂、现场调试、提交；(2)中日程(3)小日程5)系统设计内容-对实际成果（文档）进行确认·人机接口规范（界面、报表等）·错误处理·故障对策·通信规范网络规范·数据结构（文件、记录等）·程序结构与子系统划分·与其它系统（机器）的接口、子系统之间的接口(系统I/F)·内部处理流程·Walk through记录6)性能预测-对性能管理表进行确认。7)测试方针1)测试的目的2)测试范围/内容3)测试环境环境条件、工具、方法、判定条件、测试等级（单体、组合、综合）特别是应提前对测试工具（含模拟器）进行评价。4)质量目标·检查覆盖率、·错误密度·错误命中率5)WT记录8)接收文档与数据从外部接收文档与数据时，记录的同时进行必要的管理9)电子媒体的保管与维护为了在磁盘出现故障时能得到迅速恢复，而将其备份到能进行恢复的外部媒体中进行保管。10)配置管理设计文档、程序、环境、接收文档数据的配置管理是必须的，确认计划与实施情况。11)风险管理-筛选与推测的风险项目找出开发过程、开发规范、进展、技术方面或客户方体制等中的风险项目。然后检查有无计划外的作业发生，确认对过程有无影响。如果推测有风险存在时也要包含在内。 12)软硬件准备情况的确认13)设计验证 (1) 确认QCP的成果是否全部经过正确的设计验证 (2) 实施Walk-through全部被记录，且作为设计验证的证据 (3)WT实施情况 ·前DR后的WT结果 ·下DR前的WT计划14)总结结束时，归纳整理出遗留事项与问题点，并据实记录到记录的研讨事项与跟踪表中。15.确认是否再实施DR 6.程序设计内容与编码、调试方针的审查（在程序制作前进行）确认程序设计中不存在问题。1)系统概要-基于系统设计书说明在确认有无更改的同时，面向第三者进行说明。·硬件构成·软件构成与功能确认2)需求规范的更改管理需求规范的内容发生更改时，应迅速修改规范，并接受审批。而且要确认是否已实施更改处理。3)到前一为止的遗留事项4)日程-对系统开发计划书中的日程表进行确认。(1)大日程与事件1、2、验收、出厂、现场调试、提交；(2)中日程(3)小日程5)文档的完成程度-对实际成果进行确认(1)程序一览(2)程序设计书(3)操作/使用说明书(4)安装说明书(5)Walk through记录 6)程序制作标准(1)制作责任者与完成期限(2)源程序管理··········源码更改履历、更改许可、备份(3)编码规则的确认········著作权的表示、修改履历（版本管理）(4)开发设备管理·········机器日程表(5)确认用品的筹备情况···软盘、打印用纸等7)测试规范-依照单体测试规范书(1) 测试目的/基本准准/环境测试工具（含仿真）的评价计划与实际评价结果(2) 内容 功能测试负荷、性能、容量、精度、兼容性、边界值、破坏性测试、其他） (3)WT记录8)单体测试准备状况(1)责任者/完成期限(2)测试环境(3)测试数据的制作(4)不合格表管理 (5)质量分析的准备 (6)其它 9)性能预测的确认(1)目标性能(2)性能预测结果10)接收文挡与数据从外部接收文档与数据时，在记录的同时按需要进行管理。11)电子媒体的保管与维护为了在磁盘出现故障时能得到迅速恢复，而将其备份到能进行恢复的外部媒体中进行保管。12)配置管理(1) 配置管理的计划与实施(2) 更改管理表13)风险管理 (1)筛选与推测的风险项目 找出开发过程、开发规范、进展、技术或客户方体制等方面中的风险项目。(2)有无计划外的作业发生，确认对过程有无影响。如果推测有风险存在时也要包含在内。14)设计验证(1)QCP的成果全部经过正确的设计验证(2)Walk-through的实施全部被记录且作为设计验证的证据(3)WT的实施情况 ·前一次DR后的WT的结果 ·到下一次DR为止的WT计划15)总结结束时，归纳整理出遗留事项与问题点，并据实记录到记录的研讨事项与跟踪表中。16)确认是否要再次实施DR 7.1程序完成情况与单体测试结果、组合测试体制的审查（单体测试后召开）确认在程序制作、单体测试结束阶段没有问题存在。 1)系统概要-基于系统设计书中说明在确认有无更改的同时，面向第三者进行说明。(1)硬件构成(2)软件构成与功能确认2)需求规范的更改管理需求规范的内容发生更改时，应迅速修改规范，并接受审批。而且要确认有没有实际实施更改处理。3)到前一的遗留事项4)日程-对系统开发计划书中的日程表的内容进行确认。(1)大日程与事件2·、验收、出厂、现场调试、提交；(2)中日程(3)小日程5)文档的完成程度(1)操作说明书(2)系统设计书(3)程序设计书(4)其它(5)WT记录6)编程内容与完成程度-根据程序清单、审查记录来确认(1) 编程规则/著作权表示/修改履历 2000年对应（作为系统的）(2)Walk through记录7)单体测试结果未达成目标值时，重要的是分析其原因后拿出对策。(1) 测试未实施的项目(2)不合格的遗留项目(3)不合格的发生、解决情况(4)检查覆盖率(5)错误命中率(6)错误密度(7)2000年对应（作为系统的）(8)其它8)组合测试准备情况·测试内容·体制 ·日程表（责任者、完成期限）·测试环境（硬件、软件、测试数据、测试工具、调试工具）·不合格表的管理·Walk through记录9)性能评价（单体测试）的确认在性能管理表中进行单体测试阶段性能测定值的确认。·目标性能·评价方法·测试结果10)接收文档与数据从外部接收文档与数据时，在记录的同时进行必要的管理。11) 电子媒体的保管与维护 为了在磁盘出现故障时能得到迅速恢复，而将其备份到能进行恢复的外部媒体中进行保管。 ·文档/数据的备份 ·软件（源程序）的备份 ·开发环境的备份12)配置管理(1)设计文档、程序、环境、接收文档和数据的配置管理是必须的，确认计划与实施情况。(2)更改管理表13)风险管理 (1)筛选与推测的风险项目 找出开发过程、开发规范、进展、技术或客户方体制等方面中的风险项目。 (2)有无计划外的作业发生，确认对过程有无影响。如果有推测的风险存在时也要包含在内。14)设计验证(1)QCP的成果全部经过正确的设计验证(2)Walk-through的实施全部被记录且作为设计验证的证据(3)WT的实施情况 ·前一次DR后的WT的结果 ·到下一次DR为止的WT计划15)总结结束时，归纳整理出遗留事项与问题点，并据实记录到记录的研讨事项与跟踪表中。 16)确认是否要再次实施DR8.2组合测试结果的审查（综合测试前召开）1)系统概要-基于系统设计书进行说明在确认更改有无的同时，面向第三者进行说明。(1) 硬件构成(2) 软件构成与功能确认2)需求规范的更改管理需求规范的内容发生更改时，应迅速修改规范，并接受审批。而且要确认有没有实际实施更改处理。3)到上一为止的遗留事项4)日程-对系统开发计划书中的日程表进行确认。(1) 大日程与事件、验收、出厂、现场调试、提交；(2) 中日程(3) 小日程5)组合测试结果(1) 测试未实施的项目(2) 不合格的遗留问题(3) 不合格的发生、解决情况(4) 检查覆盖率(5) 错误命中率(6) 错误密度(7) Bug曲线(8) 2000年对应（作为系统的）(9) 其它目标值未完成时，主要应分析其结果后再寻找对策。6)性能评价的确认对目标性能评价的方法和测试结果进行确认7)文档的完成程度·系统设计书·程序设计书·操作说明书·其它·WT记录8)综合测试准备状况·测试内容·体制·日程（责任者、完成期限）·测试环境（硬件、软件测试数据、测试/调试工具）·不合格表管理·决定质量评价、分析用的数据·Walk through记录9)公司内部和用户验收会的方针应考虑下述事项实施验收。·日程确认·用户方与公司内部参加成员 在确认用户方参加人员职务的基础上，安排公司内部对应者·验收会检查内容/范围·验收会验收条件10)接收文档与数据从外部接收文档与数据时，在记录的同时进行必要的管理。11) 电子媒体的保管与维护 为了在磁盘出现故障时能得到迅速恢复，而将其备份到能进行恢复的外部媒体中进行保管。12)配置管理(1)配置管理的计划与实施(2)更改管理表13)风险管理 (1)筛选与推测的风险项目 找出开发过程、开发规范、进展、技术或客户方体制等方面中的风险项目。(2)有无计划外的作业发生，确认对过程有无影响。如果推测有风险存在时也要包含在内。14)设计验证(1)QCP的成果全部经过正确的设计验证(2)Walk-through的实施全部被记录且作为设计验证的证据(3)WT的实施情况 ·前一次DR后的WT的结果 ·到下一次DR为止的WT计划15)总结结束时，归纳整理出遗留事项与问题点，并据实记录到记录的研讨事项与跟踪表中。16)确认是否要再次实施DR 9.综合测试结果的检查（结束综合测试后召开）这里的重点是，按计划全面完成DR-E的测试后，作为产品准备出厂时确保没有质量上的问题，进行出厂可否判定。 为了今后与客户的对应，希望市场部门也出席。1)系统概要-基于系统设计书进行说明在确认有无更改的同时，面向第三者进行说明。(1) 硬件构成(2) 软件构成与功能确认2)需求规范的更改管理需求规范的内容发生更改时，应迅速修改规范，并接受审批。而且还要确认有没有实际实施更改处理。3)到上一为止的遗留事项4)日程-对系统开发计划书中的日程表进行确认。(1) 大日程与事件验收、出厂、现场调试、提交；(2) 中日程(3) 小日程5)综合测试结果-依据出厂批准申请书与综合测试规范书成绩书。(1)测试未实施的项目(2)不合格的遗留问题(3)不合格的发生、解决情况(4)检查覆盖率(5)错误命中率(6)错误密度(7)测试规范书/成绩书的确认(8)Bug曲线(9)2000年对应（作为系统的）检查重点为重要的功能、性能、精度、兼容性、负荷，边界测试、破坏性测试与虚拟运行测试。6)性能评价、综合测试的确认-以综合测试规范书与成绩书及性能管理表为依据。 ·目标性能 ·评价结果 ·测试结果7)客户验收会准备状况(1) 确认参加人员(2) 体制/责任者/功能分割(3) 详细日程(4) 检查内容(5) 场所(6) 其它8)文档的完成程度(1) 系统设计书(2) 程序设计书(3) 操作/使用说明书(4) Walk through记录9)向用户提交的物品(1) 交付物品一览表(2) 文档(3) 程序、装载模块 ·出厂媒体 对标签、物品样式等外观进行确认 ·病毒检查的实施10)验收条件11)公司内验收会DR-QDR-F是对文档资料等进行的桌面审查，公司验收会是对迄今为止由公司自行设计、制作的产品，使用实际设备，根据订货规范书、系统设计书与性能管理表等，接受有关人员对性能、可靠性、质量等方面的确认。12)现场调试工作方针与准备状况 (1) 体制和日程 (作业分担和期限) (2)作业内容与范围 (3)现场调试结束的验收条件 (4)现场状况机器安装等 (5)用户内事件 (6)DRG的再确认 （7）DRH的再确认 13)接收文档/数据 (1)接收文档/数据的管理 14)电子媒体的保管、维护 (1)文档/数据的备份 (2)软件的备份 15)已出厂软件的保存 (1)出厂或完成软件原本及复制品的保存16)配置管理 (1)配置管理的计划和实施 (2)更改管理表 17)风险管理 ·筛选出推测的风险项目对策 ·预定之外发生的作业 18)设计验证 (1)QCP的成果全部经过正确的设计验证 (2)Walk-through的实施被记录且作为设计验证的证据（3）WT的实施状况 ·前一次DR后的WT结果 ·到下一次为止的WT计划19)维护体制 ·维护窗口 ·有无一次性维护的委托20)产品承认/产品出厂承认文书的确认产品承认/产品出厂承认的共同事项·BUG发生/修正推移表·产品评价表·质量未确认/遗留项目列表·知识产权审查报告·生产许可证审查报告·系统开发计划书·公司验收会记录产品承认项目·产品承认申请书·开发、改进要点和维护·系统利润管理表·其它出厂承认项目·出厂承认申请书·其它21)出厂判定22)总结结束时，归纳整理出遗留事项与问题点，并据实记录到记录的研讨事项与跟踪表中。23)确认是否需要再次实施DR 10.审查会（只对标准产品） 在开发即将完成时，开发部门便将产品计划书总结后提交主管领导，等待他的认可。 审查会确认是否进行了充分的测试与检查。11.DR-G(可选项)现场调试作业的审查（在现场调试之前召开现场调试进行过程中有必要时也可召开）确认出厂后的现场调试作业无问题。1)系统概要-基于系统设计书进行说明2)到上一为止的遗留事项3)日程-对系统开发计划书中的日程表进行确认。(1) 大日程与事件用户培训、开始运行、提交、验收 等(2) 中日程(3) 小日程4)验收会指出的事项-在用户端实施验收时，用验收检查备忘录进行确认。5)现场的壮况对硬件安装日程及情况的确认6)现场调试准备情况(1)作业体制（用户方与本公司）(2) 日程表（分担确认）·现场调试时间，期限·用户事件(3) 现场测试规范书·测试的目标·测试的环境与条件(4)备份体制(5)现场作业项目规则不合格表的应用管理规范确认书的应用管理等(6)现场作业结束报告等的准备(7)其它7)验收条件从现场调试结束的条件是什么?用用户订货规范书及系统提案书来确认。8)接收文档与数据从外部接收文档与数据时，在记录的同时必须进行管理。9) 电子媒体的保管与维护(1)文件/数据的备份(2)软件的备份 10)出厂/完成软件的保管 (1)出厂或完成软件原本/及其复制品的保管11)配置管理 (1)配置管理的计划和实施