产品研发流程程序文件
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第1页
1
目的及适用范围
1.1 为规范产品研发过程，提高产品研发的效率、质量，降低研发成本，特制定本程序; 1.2 本程序文件适用于侏罗纪公司产品研发;
1.3 本程序文件由侏罗纪公司 制定，其解释权及修改权属于 ;
1.4 本程序文件从2003年 月 日起执行;
2 职责
2.1 产品部负责产品研发;
2.2 质量控制部负责对产品开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成
果放入资源中心存档;
2.3 技术支持部和市场部负责宣传材料和用户手册的制作，以及和产品销售流程的衔接环节和动作; 3 产品研发流程
3.1 CEO从公司战略规划决案中形成产品规划，下发给产品中心;
3.2 产品中心(副)总监依据产品规划安排产品经理进行产品研发立项;
3.3 执委会对产品立项进行评审，若评审未通过，相关文档放入资源管理部备案; 3.4 若立项评审通过，质量控制部对立项进行质量检验，若质检未通过，产品经理修改立项报告; 3.5 若质检通过，产品经理开始制订项目
计划
项目进度计划表范例计划下载计划下载计划下载课程教学计划下载
，同时质量控制部将立项相关文档放入资源管理部归档; 3.6 产品经理将项目计划提交给产品(副)总监评审，若未通过，产品经理修改项目计划; 3.7 若评审通过，质量控制部对项目计划进行评审，若质检评审未通过，产品经理修改项目计划，若质检
评审通过，产品总监安排研发项目资源;
3.8 产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术委员会进行内容评审; 3.9 若内容评审未通过，产品经理修改需求分析;若内容评审通过，质量控制部对《需求分析说明》进行
质量检验;
3.10 若质检未通过，产品经理修改《需求分析说明》，若质检通过，相关成果和文档放入资源管理部归档，
同时产品经理带领研发相关人员进行总体设计;
3.11 产品经理和研发人员完成总体设计后将相关成果交技术委员会进行内容评审;
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第2页
3.12 若内容评审未通过，产品经理修改《总体设计说明》;若内容评审通过，质量控制部对《总体设计说
明》进行质量检验;
3.13 若质检未通过，产品经理修改《总体设计说明》，若质检通过，相关成果和文档放入资源管理部归档，
同时产品经理和研发人员进行程序设计/测试;
3.14 完成程序设计/测试后，产品经理将相关成果交质量控制部进行功能测试，若测试未通过，产品经理修
改相关成果，若测试通过，质量控制部对相关成果和文档进行质量检验;
3.15 若质检未通过，产品经理修改相关成果和文档;若质检通过，质量控制部将相关成果和文档放入资源
管理部门归档;
3.16 同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内
部培训，市场部申请并取得著作权;
3.17 市场部在取得著作权后制作用户/技术手册;
3.18 产品研发组完成软件制作后，质量控制部对制作的软件进行质量检验，若未通过质检，产品研发组重
新制作软件;若通过质检，相关成果和文档放入资源管理部归档，同时产品经理进行产品研发总结; 3.19 质量控制部将产品研发总结等相关成果和文档放入资源管理部，同时市场部进行软件产品包装，销售
部进行产品销售;
4 相关文件
4.1 《产品规划说明书》
4.2 《立项报告》
4.3 《综合评审记录》
4.4 《质量控制立项报告和可行性分析报告说明书》
4.5 《项目计划书》
4.6 《质量控制项目计划评审记录》
4.7 《资源调度单》
4.8 《需求分析说明书》
4.9 《质量控制需求分析说明书评审报告》
4.10 《资源中心验收单》
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第3页
4.11 《评审规程》
4.12 《总体设计说明书》
4.13 《概要设计说明书》
4.14 《详细设计说明书》
4.15 《质量控制系统设计报告评审记录》
4.16 著作权相关文档(略)
4.17 《软件质量保证单》
4.18 《软件缺陷报告》
4.19 《项目总结》
产品规划说明书
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第4页
公司三年产品规划
1.
2.
3.
公司年度产品计划
1.
2.
签发人:
时间
合评审记录(公司)
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第5页
评审对象(项目名称及编号)
评审项类(如合同、投标
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
等)
评审人
时间
业务板块(产品中心、项目中心、服务中心、营销中心)评审意见
财务部评审意见
质量控制部评审意见
技术委员会评审意见
专家委员会评审意见
最终意见:
通过
修改
修改内容
时间
立项报告评审记录
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第6页
记录编号, - 时间, 年 月 日 立项建议报告名称, 编制人, 参加人员,
评审内容(审议通过的内容在“?”中划“?”,否则划“×”),
1)项目启动的背景; ?
2)项目的目的(合同意向或内部领导的要求); ?
3)项目的范围(项目所涉及的主要活动); ?
4)项目的可行性(如，人力、技术资源的可利用性); ?
5)项目存在风险与控制; ?
6)项目的重要里程碑和主要提交产品; ?
7)项目的规模(估计所需的工作量和资源种类); ?
8)项目启动的预算(项目启动所需的资源); ?
9)项目市场前景及效益的简要分析。 ?
评审意见,
评审结论:
填表 审批
1, 本页不足记述评审意见时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第7页
风险评估与控制(立项建议报告评审附页)
评估人/日期,立项建议报告名称,评审部门,序风险发生风险描述风险级别风险现值风险控制措施号可能性
目标不明确,如产品定位、市场前景描1述不清晰，
时间紧,包括开发、测试、产品包装、2产品销售等，
3源码、文档资料的控制
市场调研不充分,缺乏对市场上已经有4的具有相似功能产品的了解
5预算不合理
6存在技术难点、采用新技术
缺乏对本公司的产品形态、技术路线、7战略方针、发展趋势的全面了解
8缺乏足够资源
9分工不明确、缺乏计划性
1.评估中风险不限于表中已列出的,应依据评审的具体情况增加风险项。并将各项填写完整。10多部门配合2.风险描述,描述当前过程中可能发生的风险。风险发生可能性,风险发生的概率,以百分数表示,为0到1,增量为0.05。风险级别,风险发生造成损失的严重程度,以0~10级
表示,其中10级 为最高级。风险现值,风险发生可能性与风险级别的乘积。风险控制措施,预防风险发生的措施。
11第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第8页
可行性分析报告评审记录
记录编号, - 时间, 年 月 日 可行性分析报告编号, 可行性分析报告名称,
编制部门, 编制人,
参加人员:
评审内容:(评审中审议通过的内容在“?”中划“?”否则划“×”),
1) 软件产品功能要点及产品化程度书 ?
2) 量化的市场前景、效益分析和竞争对手分析 ?
3) 开发优势 ?
4) 技术路线 ?
5) 成本估算 ?
6) 进度估算 ?
7) 可用的现行技术、重用软件和开发平台 ?
评审意见:
评审结论,
填表 审批
1, 本页不足记述评审意见时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第9页
风险评估与控制(可行性分析报告评审附页)
评估人/日期,立项建议报告名称,评审部门,序风险发生风险描述风险级别风险现值风险控制措施号可能性
1市场调研不充分
市场预测不准确(如目标市场、产品定2位等)
编写人员缺乏足够的行业知识和专业知3识
4时间紧
5多部门配合
技术可行性(如技术平台采用、接口的6描述等)
7缺乏足够的资源
8投资预算不合理
9缺乏对技术复用的分析
1.评估中风险不限于表中已列出的,应依据评审的具体情况增加风险项。并将各项填写完整。缺乏对本公司的产品形态、技术路线、2.风险描述,描述当前过程中可能发生的风险。风险发生可能性,风险发生的概率,以百分数表示,为0到1,增量为0.05。风险级别,风险发生造成损失的严重程度,以0~10级10战略方针、发展趋势的全面了解表示,其中10级 为最高级。风险现值,风险发生可能性与风险级别的乘积。风险控制措施,预防风险发生的措施。
第 页/共 页11缺乏对市场环境、竞争对手的了解
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第10页
项目计划书
项目名称 项目编号
项目经理
项目任务描述
项目总时间及关键里程碑设置
项目资源(人力、技术、设备)
项目费用预计
审批人意见:
总监: 副总监: 执委会:
备注:抄送财务部、人力资源部
时间
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第11页
项目启动计划评审记录 记录编号, 时间, 年 月 日 项目编号, 项目名称, 项目启动计划编号, 开发部门, PM, 评审地点, 参加评审人员:
评审内容(评审中审议通过的内容在“?”中划“?”否则划“×”),
1) 项目的目的是否明确, ?
2) 对项目的规模是否进行估算, ?
3) 是否进行项目启动的预算, ?
4) 阶段输出结果是否明确, ?
5) 其它方面
评审意见,
评审结论,
填表, 审批,
1. 项目启动计划评审由项目管理部门组织评审。
2. 评审完成后由开发体系决策层SMG批准。
3. 本页不足记述结果时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第12页
开发计划评审记录
记录编号, 时间, 年 月 日 项目编号, 项目名称, 项目计划编号, 开发部门, PSM, 评审地点, 参加评审人员:
评审内容,
评审意见,
评审结论,
填表, 审批,
1. 开发计划评审由项目管理部门组织评审。
2. 评审完成后由开发体系决策层SMG批准。
3. 本页不足记述结果时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第13页
开发计划检查表(开发计划评审附页)
项目名称, 项目编号,检查项目检查内容检查结果得分一、质量目标1、是否符合质量体系的要求,
2、如果不符合质量体系的要求,是否按要求编
制《质量计划》,
二、阶段划分1、是否明确划分各阶段,
2、各阶段的输入、输出
标准
excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载
是否明确,
3、是否明确各阶段提交物,
4、是否明确各阶段质量目标,
5、是否明确提出各阶段检查点,
1、是否明确提交给客户的产品清单,产品名称
、提交时间、客户接受方式、责任人、验收标
准，,三、产品清单
2、是否明确提交给项目监控部门的产品清单
,产品名称、提交时间、提交方式、责任人，,四、技术管理1、是否明确开发环境,软件、硬件环境，,
2、是否明确开发工具,
3、是否明确开发方法,
4、是否采用新技术,
5、是否考虑软件复用,
1、是否确定项目小组成员,并将其划分成多个
Team,五、组织结构
2、是否明确各个小组成员的职责,
六、风险管理1、是否预测了与项目有关的主要风险,
2、是否采取跟踪、监测措施以减小风险或避免
风险的产生,
七、相关性1、是否考虑了项目的外部相关活动,
2、是否考虑了项目的内部相关活动,八、资源预算1、是否画了有关资源的直方图,
2、是否预算了项目的工作量并划分给小组成
员,
九、配置管理1、是否制定了配置管理计划表,
检查人/日期, 批准人/日期,
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第14页
风险评估与控制(开发计划评审附页)开发计划名称,计划编号,评审部门,序风险发生风险描述风险级别风险现值风险控制措施号可能性
客户需求不明确1
客户需求变化2
开发人员缺乏足够的行业知识和专业知识3
源码、文档的控制4
工作阶段划分不明确、人员分工不合理5
多部门配合6
开发队伍不稳定或缺乏人力资源7
预算超支8
缺乏对技术复用的考虑9
时间紧10
存在技术难点、采用新技术11
12检查点设立不合理
13缺乏对突发事件的考虑1.评估中风险不限于表中已列出的,应依据评审的具体情况增加风险项。并将各项填写完整。
2.风险描述,描述当前过程中可能发生的风险。风险发生可能性,风险发生的概率,以百分数表示,为0到1,增量为0.05。风险级别,风险发生造成损失的严重程度,以0~10级表
示,其中10级 为最高级。风险现值,风险发生可能性与风险级别的乘积。风险控制措施,预防风险发生的措施。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第15页
软件问
题
快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题
报告
记录编号, - 时间, 年 月 日 项目编号, 项目名称,
软件项编号, 软件项名称, 版本号, 问题描述,
报告人签字/日期:
修改描述,主要是修改后与修改前的对比,如所用资源的变化、提交时间的变化、功能的变化等，,
修改人签字/日期,
填写, 审批,
1. 问题描述栏中可以填写问题现象及其产生原因,如果有用户的书面说明,则可以直接引用。 2. 修改描述一栏描述问题的确切原因、修改办法以及修改后的效果。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第16页
3. 本页不足记述时,可以有附页,格式自定。总页数包括本页与所有附页。
项目资源调度单(借鉴产品中心任务书)
项目名称 项目编号 项目经理 项目的跨中心(部门)资源调度缘由及
申请人
审批人
正式调用时间:
起:
止:
备注:抄送财务、人力资源部
时间
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第17页
软件需求分析说明书 1. 引言
1.1 目的
说明编写软件需求说明书的目的，指出预期的读者。
1.2 背景
(1) 待开发的软件系统的名称;
(2) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; (3) 该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3 参考资料
列出所用的参考资料，如:
(1) 本项目的经核准的计划任务书或合同、上级机关的批文;
(2) 属于本项目的其他已发表的文件;
(3) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
(4) 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 1.4 术语
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
2. 项目概述
本部分描述影响产品和其需求的一般因素。此处并不说明具体的需求，其描述的内容仅仅是为了更容易理解、深化需求规格，其用意是为从多方面、多角度考虑需求以提供思维参考点。 2.1 一般描述
本节描述软件开发项目的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料，解释待开发产品和其相关的其他产品或项目的关系。
, 如果本产品是独立的，而且自含全部内容，应在此说明。
, 如果所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容:
, 要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口;
, 指出本产品主要的外部接口(不需要详细描述，详细描述放在其他章节中);
, 描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。 【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
【提醒注意】本节所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约束条件提供了一个可以解释的理由。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第18页
2.2 功能简述
对待的软件产品功能提供一个摘要。
【技巧】
, 编制功能的一种方法是制作功能表，以便客户或第一次读这个文件的人很容易理解;
, 用方框图来表达不同的功能和它们的关系有益于理解。
【提醒注意】
, 方框图不是产品的设计，而只是一种有效的解释方式。
, 本节不是具体需求的陈述，只是对具体需求部分中为什么要对一些需求做出描述的铺垫。 2.3 用户特点
本节描述产品最终用户(包括操作员、维护员和系统工作人员等)具有的受教育水平、工作经验及技术专长等一般特点。
如果系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
2.4 假定和约束
给出影响软件需求说明书中陈述的需求的每一个因素。这些因素不是软件的设计约束，但是它们的改变可能影响到需求说明书中的需求。
这些假定和约束条件可能包括:管理方针;运行环境，包括硬件设备和支持软件的限制;与其他应用间的接口;并行操作;实时功能;审查功能;控制功能;所需的高级语言;通信协议;应用的临界点;安全保密方面的考虑等。
【提醒注意】
, 本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。
, 本节的内容不能用来陈述具体需求或强加若干特殊的设计约束，而应对具体需求部分中的某些具体需求或设计约束的描
述提供理由。
3. 具体需求
本章应包括软件开发者在建立设计时需要的全部细节。
本章的编写应该遵循如下基本原则:
, 遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述;
, 在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引
用的背景;
, 按符合逻辑的和可读的方式组织;
, 详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。 【提醒注意】每一项需求的描述都应包括至少5个方面的内容:功能需求;性能需求;属性需求;外部接口需求;设计约束。 3.1 功能需求
用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成:
3.1.1 引言
(1) 描述该功能要达到的目标、所采用的方法和技术;
(2) 清楚说明功能意图的由来和背景。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第19页
3.1.2 输入
(1) 详细描述该功能的所有输入数据，如:输入源、数量、度量单位、时间设定、有效输入范围(包
括精度和公差)。
(2) 操作员具体的操作控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。
例如:当打印检查时，要求操作员进行格式调整。
(3) 指明引用的输入接口资料。
3.1.3 处理
描述为获得预期输出结果，对输入数据及中间参数进行的全部操作。它包括如下的说明: (1) 输入数据的有效性检查手段;
(2) 操作的顺序和处理过程，包括事件的时间设定;
(3) 异常情况的响应，例如:溢出、通信故障、错误处理等;
(4) 受操作影响的参数;
(5) 降级运行的要求;
(6) 用于把系统输入变换成相应输出的任何方法(方程式、数学算法、逻辑操作等)。 (7) 输出数据的有效性检查手段。
3.1.4 输出
(1) 详细描述该功能所有输出数据，例如:输出目的地、数量、度量单位、时间关系、有效输出的范
围(包括精度和公差)、非法值的处理、出错信息;
(2) 指明引用的输出接口资料。
【技巧】可以用列表的方式(例如IPO表即输入、处理、输出表的形式)，逐项定量和定性地叙述对软件所提出的功能要求。 【提醒注意】对着重于输入输出行为的系统来说，需求说明书应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态做出响应。这种情况犹如有限状态机。 3.2 性能需求
从整体来说，本节应具体说明软件、或人与软件交互的静态或动态数值需求。
静态数值需求可能包括:支持的终端数，支持并行操作的用户数，处理的文卷和记录数， 表和文卷的大小等。
动态数值需求可能包括:欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量等。
所有这些需求都必须用可以度量的术语来叙述。例如:95%的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。
, 精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
, 时间特性要求
说明对于该软件的时间特性要求，如对响应时间、更新处理时间、数据的转换和传送时间、解题时间
等的要求。
, 灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如:操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、计划的变化或改进等。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第20页
3.3 软件属性需求
在软件的需求之中有若干个属性，下面列举一部分。
【提醒注意】下列属性决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。
3.3.1 正确性
3.3.2 健壮性
3.3.3 安全保密性
这里指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括:利用可靠的密码技术，掌握特定的记录或历史数据集，给不同的模块分配不同的功能，限定一个程序中某些区域的通信，计算临界值的检查等。
3.3.4 易使用性
3.3.5 可理解性
3.3.6 可维护性
这里规定若干需求以确保软件是可维护的。例如:软件模块所需要的特殊的耦合矩阵，为微型装置指定特殊的数据/程序分割要求等。
3.3.7 可测试性
3.3.8 可移植性
这里规定把软件从一种环境移植到另一种环境所要求的用户程序、用户接口兼容方面的约束等。 3.4 外部接口需求
3.4.1 用户接口
(1) 提供用户使用软件产品时的界面需求。例如，如果系统的用户通过显示终端进行操作，就必须指
定如下要求:对屏幕格式的要求，报表或菜单的页面显示格式和内容，用户命令的格式，输入输
出的相对时间，程序功能键的可用性。
(2) 列出输出错误信息的格式。
3.4.2 硬件接口
(1) 指出软件产品与系统硬部件之间每一个接口的逻辑特点。
(2) 指出硬件接口支持的设备。
(3) 描述软件与硬件接口之间以及硬件接口与支持设备之间的约定。
3.4.3 软件接口
描述项目待开发软件产品与其它有关软件的接口关系，并指出这些软件的以下内容:名字、助记符、规格说明号、版本号、来源。
【提醒注意】对于每一个接口，应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，这里不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
3.4.4 通讯接口
说明各种通信接口及协议，例如局部网络的协议等。
3.5 设计约束
3.5.1 其它标准的约束
描述由现有的标准或规则派生的要求。例如:报表格式、数据命名、财务处理、审计追踪等等。
3.5.2 硬件设备的约束
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第21页
描述在各种硬件约束下运行而产生的软件要求，可能的约束有硬件配置的特点(接口数、指令系统等)，
内存储器和辅助存储器的容量等。
3.6 数据需求
【提醒注意】
, 此部分内容一般在数据要求说明书中进行描述，如果项目软件产品规模较小，系统复杂程度较低，数据需求较简
单，也可在此章中描述。
, 此部分内容也可能在功能需求中予以说明。
3.6.1 数据描述
(1) 列出作为控制和引用而使用的静态数据元素
(2) 列出动态输入数据元素
(3) 列出动态输出数据元素
(4) 列出软件内部生成的数据元素
3.6.2 数据获取
(1) 列出提供输入数据的机构
(2) 列出数据输入介质和设备
(3) 列出数据输出介质和设备
3.7 其它专门需求
根据软件和用户组织的特性等，某些需求在这里描述，下面列举一部分。 【提醒注意】下列需求项决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。
3.6.1 数据库
本项对作为项目产品的一部分进行开发的数据库规定一些需求，它们可能包括: (1) 在功能需求中标识的信息类别;
(2) 使用的频率
(3) 存取能力;
(4) 数据元素和文卷描述符;
(5) 数据元素、记录和文卷的关系;
(6) 静态和动态的组织;
(7) 数据保存要求。
【提醒注意】如果使用一个现有的数据库包，这个数据库包应在“软件接口”中命名，并在那里详细说明。
3.6.2 数据管理能力
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。
3.6.3 操作
这里说明用户组织之中各种方式的操作。例如:
(1) 用户初操作;
(2) 交互作用操作的周期和无人操作周期;
(3) 数据处理支持功能;
(4) 后援和恢复操作。
【提醒注意】这里的内容有时是“用户接口”的一部分。
3.6.4 故障处理
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第22页
4. 运行环境规定
4.1 设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括: (1) 处理器型号及内存容量;
(2) 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量; (3) 输入及输出设备的型号和数量，联机或脱机;
(4) 数据通信设备的型号和数量;
(5) 功能键及其他专用硬件。
4.2 支持软件
列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。 4.3 接口
说明该软件同其它软硬件之间的接口、数据通信协议等。
4.4 控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。 【提醒注意】本章中的内容有时在前面的章节中已说明。
5. 支持信息
支持信息指目录表、索引和附录。
, 目录表和索引很重要，而且应按照可以接受的文件规则来编写。 , 对一个实际的需求说明书来说，如有必要应该编写附录。附录中可能包括:
(1) 输入输出格式样本，成本分析研究的描述或用户调查结果;
(2) 有助于理解需求说明书的背景信息;
(3) 软件所解决问题的描述;
(4) 用户历史、背景、经历和操作特点;
(5) 交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善;
(6) 特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。
当包括附录时，需求说明书必须明确地说明附录是不是需求要考虑的部分。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第23页
分析说明书评审记录
记录编号, - 时间, 年 月 日 项目编号, 项目名称,
项目软件经理PSM, 需求分析报告编制人,
参加评审人员,
评审内容,(评审中审议通过的内容在“?”中划“?”,否则划“×”)
1. 无岐义性 ?
2. 完整性 ?
3. 可验证性 ?
4. 一致性 ?
5. 可使用性 ?
6. 符合《需求分析报告编写规范》的要求 ? 评审意见,
风险评估总结,
评审结论,(评审中审议通过的内容在“?”中划“?”,否则划“×”)
1. 通过评审,可以进入下一阶段 ?
2. 未通过评审,修改后重新评审 ?
填表, 审批,
1. 本页不足记录结果时,可以有附页,附页格式自定。总页数包括本页与所有附页。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第24页
风险评估与控制(需求分析报告评审附页)
系统设计报告名称,报告编号,评审部门,
序风险发生风险描述风险级别风险现值风险控制措施号可能性
1客户需求变化
开发人员缺乏足够的行业知识和专业知2识
3需求未被顾客完全认可
4需求不明确
5时间紧
6存在技术问题、采用新技术
7多部门配合
8没有顾客系统接口原型
9缺乏顾客自然情况的了解
10顾客配合程度不够1.评估中风险不限于表中已列出的,应依据评审的具体情况增加风险项。并将各项填写完整。2.风险描述,描述当前过程中可能发生的风险。风险发生可能性,风险发生的概率,以百分数表示,为0到1,增量为0.05。风险级别,风险发生造成损失的严重程度,以0~10级表示,其中10级 为最高级。风险现值,风险发生可能性与风险级别的乘积。风险控制措施,预防风险发生的措施。11 第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第25页
评审规程
状态: 草稿 标识号:
评审 当前版本: 1.0
初始版 前一版本:
修订版 发布日期:
摘要
本文详细描述了软件工作产品的评审规程。将要执行评审的所有项目的软件工作产品
都必须遵循该评审规程。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第26页
修改历史
日期 版本 作者 修改内容 评审号 更改请求号
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第27页
目录
1 目的和范围 28
2 评审角色 28
2.1 作者 ................................................................... 28 2.2 评审组长 ............................................................... 28 2.3 记录员 ................................................................. 28 2.4 其他参与人员 ........................................................... 29
3 评审过程 29
3.1 计划阶段 ............................................................... 29 3.1.1 进入条件 ........................................................... 29 3.1.2 目的............................................................... 29 3.1.3 活动............................................................... 29 3.2 准备阶段 ............................................................... 29 3.2.1 进入条件 ........................................................... 30 3.2.2 目的............................................................... 30 3.2.3 活动............................................................... 30 3.3 执行阶段 ............................................................... 30 3.3.1 进入条件 ........................................................... 30 3.3.2 目的............................................................... 30 3.3.3 活动............................................................... 30 3.4 整理阶段 ............................................................... 31 3.4.1 进入条件 ........................................................... 31 3.4.2 目的............................................................... 31 3.4.3 活动............................................................... 31
4 附录A 评审活动检查表 32
5 附录B 评审记录表 33
6 附录C 评审通知 35
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第28页
1 目的和范围
本文档主要描述了软件工作产品的评审过程，目的是能够及早和有效地发现并排除软件工作产品的缺陷。 2 评审角色
在评审时有四种角色:作者、评审组长、记录员及其他人员。这些角色在评审会上要承担不同的职责。角色的划分必
须遵循下面的原则:
作者和评审组长是必须的角色，且不能为同一人
记录员可以是任何人员，也可由作者或评审组长兼任
其他人员在数量上没有限制，可以来自与项目相关的其它组织或部门
所有人员都必须具备相关的技术背景知识，对评审的软件工作产品有足够的了解，熟悉评审规程。
2.1 作者
作者是指被评审的软件工作产品的作者，其主要职责如下:
准备相关的评审资料
完成评审后的修改工作
2.2 评审组长
评审组长必须为该软件工作产品所属领域的高级技术人员，其主要职责如下: 指导作者组织并实施评审活动，对评审材料进行初审，确定参加评审的人员
按照评审规程主持评审会议
在评审会议上控制评审进度，提醒参加者不要在某一问题上花费过多时间
对评审中发现的问题进行分析判断，确定处理办法，建议为两类:
1. 问题项:当场确定为问题，需要解决
2. 调查项:无法确定是否为主要问题，需要进一步调查确认
决定评审结果(通过和再评审)
2.3 记录员
记录员在评审会议中记录发现的问题及相关的数据，其主要职责如下:
填写评审记录表
作为评审员参与评审
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第29页
2.4 其他参与人员
其他人员评审软件工作产品，回答问题、参与讨论同时帮助解决问题。所有的参与人员都必须严格遵循评审规程。 3 评审过程
评审过程分为四个阶段，每一阶段都包含一定的任务描述，可以参考《评审活动检查表》执行评审。 《评审活动检查表》是帮助评审人员正确执行评审的工具，它与本章所描述的各阶段的具体活动是一致的。 评审过程的四个阶段为:计划、准备、执行和整理。 每一阶段必须顺序地执行，才能保证评审成功。 下面将详细描述这四个步骤。
3.1 计划阶段
这是评审的第一阶段，其每一步都有详细说明，只有计划阶段的任务完成后才能进入准备阶段。
3.1.1 进入条件
软件工作产品满足规范要求
软件工作产品经过拼写检查
3.1.2 目的
确保作者提供正确的评审材料
确保软件工作产品满足评审要求
确定评审员并明确其职责
3.1.3 活动
作者准备评审所需的材料，包含被评审的软件工作产品、支持材料及评审表格等
技术委员会指定评审组长
评审组长检查进入标准是否满足
技术委员会确定参评人员。也可由技术委员会委托评审组长确定需要参加评审的人员 评审组长确认作者准备好所需要的材料
评审组长与作者共同确定评审会议日程
3.2 准备阶段
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第30页
3.2.1 进入条件
评审材料已准备好
参加者对被评审的软件工作产品具备必要的背景知识 评审组长确认评审材料符合要求
3.2.2 目的
评审员明确自己的职责
所有评审员在评审之前得到评审材料
确保评审员在评审之前阅读评审材料，找出问题
3.2.3 活动
作者发评审会议通知给所有评审员
作者将评审材料分发给所有评审员
评审组长标识软件工作产品的范围，强调重点，提取问题 评审组长熟悉议程，确保评审进度
评审员仔细阅读评审材料，在评审材料上做评注，找出问题 所有评审员记录自己准备所花费的时间
3.3 执行阶段
执行评审必须召开评审会议，所有评审员进行面对面地讨论是必要的。
3.3.1 进入条件
所有评审员得到评审材料
所有评审员根据自己的角色要求准备并且评审软件工作产品 所有评审员记录自己的准备时间。本次评审的准备时间是所有评审员的准备时间之和
会议室和其它资源已经准备就绪
作者准备就绪，重要参加人员能够出席评审会议
3.3.2 目的
找出、记录和分析所有问题
3.3.3 活动
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第31页
评审组长检查所有评审员是否已经做好评审的准备工作
记录员记录评审员的准备时间，开始评审
作者为软件工作产品逐项进行概要介绍
记录员在评审会议上记录发现的问题
所有评审员把重点放在讨论和提出问题上
评审员使用自己注释的评审材料对有问题的地方提出讨论
作者和评审员协助评审组长描述和分析问题，
发现一个问题后，评审组长确保该问题被正确记录
所有评审员提出对评审会议的改进建议，记录员在评审表上记录要点
评审组长确保评审完成
评审组长在评审组的协助下决定评审结果。如果没有问题或发现的问题类型和数量容易改正和处理，其结果为“通过”，
否则为“再评审”
如果需要“再评审”，可以只评审需要评审的部分。评审组长记录需要再被评审的部分
3.4 整理阶段
3.4.1 进入条件
问题已被记录在评审表中
3.4.2 目的
修正评审中发现的所有问题
确保所有需要进行调查的项目已经被分析，并且被排除
评审数据被记录
3.4.3 活动
评审组长估计并跟踪修改问题所需时间
对于问题项，作者确保有问题记录
对于调查项，经研究后，如果是问题项，作者负责解决并记录在评审表中
作者修正所有问题项
评审组长协调所有评审员检查作者已修改过的内容。如果没有问题，则评审结果定为“通过”，否则，评审组长应提
出解决方案
所有评审员确认后，在评审表上签字
如果使用评审工具代替评审记录表，则作者在评审工具中生成一个新的评审记录表，填入相应内容并提交
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第32页
4 附录A 评审活动检查表
阶段 作者 评审组长 其他评审员
, 接受评审组长角色并确, 定评审目标
, 检查评审进入条件是否 , 准备评审材料 满足 计划
, 同评审组长一起选择评, 确定需要参加评审的人, 接受评审员角色 审员 员
, 与评审组长共同
, 确保评审材料准备好 , 核实进入条件 , 理解自己的职责
, 给所有评审员发评审会, 学习并且评注软件工作, 学习并且评注软件工作
议通知 产品 产品 准备 , 将被评审材料分发给所, 熟悉评审议程 , 记录个人的准备时间 有评审员
, 确保会议室和其它资源 , 记录个人的准备时间 准备就绪
, 按时出席，提供准备时, 介绍评审会议日程 , 控制评审进度 间
, 逐项概要介绍软件工作, 记录员记录所有评审员, 分析问题 产品 姓名及准备时间
执行 , 决定评审结果 , 参加讨论并提出问题
, 记录员记录问题
, 所有评审员提出对评审
会议的改进建议，记录
员在评审表上记录要点
, 估计并跟踪需要修改问 , 改正评审所发现的问题 题所需时间
, 如果有评审工具，则生
整理 成一个新的评审记录, 阅读并确认评审记录表, 检查修改内容的正确性 表，填入相应内容并提内容的正确性
交
, 提交文档 , 签字 , 签字
注:首先由技术委员会指定评审组长。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第33页
5 附录B 评审记录表
评审会日期:_________________ 开始时间:_________________ 结束时间:_________________
评审会地点:___________________________________________________________第_____次评审
评审主题:__________________________________________________________________________
__________________________________________________________________________ 软件工作产品名称:________________________________软件工作产品大小:_________SLOC/页
软件工作产品标识号:____________________________版本号:_______ 作者:_______________
评审员及准备时间:
角色 姓名 准备时间(小时)
评审组长
作者
记录员
评审员
总和
问题记录:
序号 位置 描述 类型 状态
问题项 未解决 调查项 已解决
问题项 未解决 调查项 已解决
修改软件工作产品工作量(小时):___________________
评审结果: ? 通过 ? 再评审
改进建议:__________________________________________________________________________
__________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第34页
签字:
角色 姓名 签字
评审组长
评审员
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第35页
6 附录C 评审通知
主题:
第 次评审
期望准备时间:
评审会日期: 开始时间: 持续时间: 评审会地点:
软件工作产品名称:
软件工作产品标识号: 版本号: 作者: 评审组长: 记录员:
其他评审员:
议程:
起止时间 主题
软件工作产品信息:
软件工作产品标识号:
版本:
软件工作产品大小(SLOC/页):
其它支持材料:
遵循标准:
其它:
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第36页
概要设计说明书 1. 引言
1.5 目的
说明编写概要设计说明书的目的，指出预期的读者。
1.6 背景
(4) 待开发的软件系统的名称;
(5) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; (6) 该软件系统同其他系统或其他机构的基本的相互来往关系。
1.7 参考资料
列出所用的参考资料，如:
(5) 本项目的经核准的计划任务书或合同、上级机关的批文;
(6) 属于本项目的其他已发表的文件;
(7) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 (8) 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.8 术语
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
2. 总体设计
2.2 需求规定
简要说明对本系统的主要的输入输出项目、处理的功能与性能等的要求。 2.3 运行环境
简要地说明对本系统的运行环境(包括硬件环境和支持环境)的规定。 2.4 基本设计概念和处理流程
说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
2.5 结构
用一览表及框图的形式说明本系统的系统元素(各层模块、子程序、公用程序等)的划分，扼要说明每个系
统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。 2.6 功能需求与程序的关系
用如下的矩阵图说明各项功能需求的实现同各块程序的分配关系:
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第37页
程序1 程序2 „„ 程序m
功能需求1 ?
功能需求2 ?
: :
功能需求n ? ? 2.7 人工处理过程
说明在本软件系统的工作过程中不得不包含的人工处理过程。
2.8 尚未解决的问题
说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。
3. 接口设计
3.1 用户接口
说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。
3.2 外部接口
说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。 3.3 内部接口
说明本系统之内的各个系统元素之间的接口的安排。
4. 运行设计
4.1 运行模块组合
说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每时每种运行所历经的内部模块和支持软件。
4.2 运行控制
说明每一种外界的运行控制的方式方法和操作步骤。
4.3 运行时间
说明每种运行模块组合将占用各种资源的时间。
5. 系统数据结构设计
5.1 逻辑结构设计要点
给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
5.2 物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系(索
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第38页
引、设备、存储区域)、设计考虑和保密条件。
5.3 数据结构与程序的关系
说明各个数据结构与访问这些数据结构的各个程序之间的对应关系，可采用如下的矩阵图的形式:
程序1 程序2 „„ 程序m
数据结构1 ?
数据结构2 ?
: :
数据结构n ? ?
6. 系统出错处理设计
6.1 出错信息
用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。 6.2 补救措施
说明故障出现后可能采取的变通措施，包括:
(1) 后备技术革新:说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技
术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术; (2) 降效技术:说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，
例如一个自动系统的降效技术可以是手工操作和数据的人工记录;
(3) 恢复及再启动技术:说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新
运行的方法。
6.3 系统维护设计
说明为了系统维护的方便而在程序内部设计中做出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第39页
详细设计说明书
1. 引言
1.1 目的
说明编写详细设计说明书的目的，指出预期的读者。
1.2 背景
(7) 待开发的软件系统的名称;
(8) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; (9) 该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3 参考资料
列出所用的参考资料，如:
(9) 本项目的经核准的计划任务书或合同、上级机关的批文;
(10) 属于本项目的其他已发表的文件;
(11) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
(12) 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 1.4 术语
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
2. 软件系统的结构
用一系列图表列出本软件系统内的每个程序(包括每个模块和子程序)的名称、标识符和它们之间层次结构关系。
3. 模块n设计说明(n是模块序号)
从本章开始，将概要设计产生的功能模块进行细化，形成若干个可编程的程序单元，逐个地给出各个层次中的每个程序的设计考虑。
以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。 3.1程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且还要说明本程序的特点(如是常驻内存还是非常驻内存;是否子程序;是可重入的还是不可重入的;有无覆盖要求;是顺序处理还是并发处理;„„)。 3.2功能
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第40页
说明该程序单元应具有的功能，可采用IPO图(即输入——输出图)的形式。 3.3性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4结构
用图表的形式给出程序单元的结构。
3.5程序逻辑
用框图或过程性描述语言的形式表示各程序单元的控制流程。
3.6输入项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式、数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3.7输出项
给出对每时每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围、输出的形式、数量和频度、输出媒体、对输出图形及符号的说明、安全保密条件等等。
3.8算法
详细说明本程序单元所选用的算法，具体的计算公式和计算步骤。
3.9接口
用图表的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式。
3.10 数据结构
说明与本程序相直接关联的数据结构(数据库、数据文卷)，用图表描述数据结构与模块的关系。 3.11 存储分配和数组分配
确定每个模块的存储量及数组定义。
3.12 单元说明
说明程序单元标识、调用方式、参数说明。
3.13 注释设计
说明准备在本程序中安排的注释，如:
(1) 加在模块首部的注释;
(2) 加在各分枝点处的注释;
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第41页
(3) 对各变量的功能、范围、缺省条件等所加的注释;
(4) 对使用的逻辑所加的注释等等。
3.14 限制条件
说明本程序运行中所受到的限制条件。
3.15 尚未解决的问题
说明在程序单元的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
系统设计报告评审记录
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第42页
记录编号, 时间, 年 月 日 项目编号, 项目名称,
项目软件经理PSM, 系统设计报告编制人,
评审人员,
评审内容,(评审中审议通过的内容在“?”中划“?”,否则划“×”)
1. 设计是否满足功能和性能要求, ?
2. 设计是否满足设计规范的要求, ?
3. 设计是否满足下一阶段的输入要求, ?
4. 错误或缺陷是否消除,或已识别了错误的风险, ?
评审意见,
评审结论,(评审中审议通过的内容在“?”中划“?”否则划“×”)
1. 通过评审,可以进入下一阶段 ?
2. 未通过评审,修改后重新评审 ?
填表, 审批,
1. 此表不足记录结果时,可以有附页,附页格式自定,总页数包括所有附页。
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第43页
风险评估与控制(系统设计报告评审附页)系统设计报告名称,报告编号,评审部门,序风险发生风险描述风险级别风险现值风险控制措施号可能性设计缺乏对后期开发工作的指导和规范
1(如缺乏对界面、编码、源码管理、接
口等方面的规范)
2设计不能做为测试设计的输入
3设计的语言描述不清晰、简洁、准确
4设计不能完全覆盖客户的需求
5设计缺乏灵活性
6设计结构描述不清晰
7技术分工不清晰
技术可行性(如存在技术难度、采用新
8技术、工具选用不合理、开发平台选用
不合理等)
9设计人员缺乏必要的素质
10需求不明确
11时间紧1.评估中风险不限于表中已列出的,应依据评审的具体情况增加风险项。并将各项填写完整。2.风险描述,描述当前过程中可能发生的风险。风险发生可能性,风险发生的概率,以百分数表示,为0到1,增量为0.05。风险级别,风险发生造成损失的严重程度,以0~10级 表示,其中10级 为最高级。风险现值,风险发生可能性与风险级别的乘积。风险控制措施,预防风险发生的措施。12缺乏技术复用的考虑
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第44页
软件质量保证文档
(项目名称)SQA计划
计划编号: SQAL: 日期:
版 本: SQAM: 日期:
分 册: PM/SM: 日期:
1质量目标
质量目标，尽可能用测试的条款表达。
2. SQA组织
2.1 SQA组的组成
SQA的成员及资格说明(经验与培训)
2.2 SQA职责和权力
2.3 SQA组的资源需求
3. SQA任务
3.1 规程与标准
明确项目标准和规程，作为SQA评审和审计的基础。
3.2 明确质量活动的责任
如检查、审计和测试，配置管理和变更控制，测量和报告，缺陷控制和纠正措施。
3.3 阶段划分与任务列表
为每个开发阶段定义入口和出口条件，划分SQA的工作阶段，确定评审与审计的类型，明确SQA作业，
可依据项目特点对作业列表进行裁剪与增添。
3.4 测试与评估
确定测试的类型，对于产品规范、计划要求、测试规范及采用的开发方法和工具的确认和验证活动;通
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第45页
过详细的测试和验证活动计划，对包括资源、进度和审批等方面进行评估。
3.5 全程的偏差跟踪
根据任务列表进行全程偏差跟踪。
4. SQA报告
4.1 文档化SQA组的活动结果
软件产品
评价
LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载
报告
软件工具评价报告
项目设备评价报告
过程审核报告
测量报告
4.2 提供给软件工程组和其他相关组SQA活动反馈的方法和频率
周报、月报与重要报告等提交的方式与日程(可在计划表中体现)。 5. 计划进度表与预算表
序完成时间 任务 提交结果 备注 号
1
2
3
4
5
预算:
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第46页
SQA作业列表(发布日期)
SQA方向任务作业项审核与检验
质量目标质量策划质量目标，尽可能用测试的条款表达
质量标准与规程的确立
评估工具和设
工具和设备备的管理软件工具
设备
配套的产品与设备
评估软件产品评审的标准，依据程序文件的要求或在《质
软件过程评审过程量计划》与SDP中明确
评估项目计划
和监督过程项目计划的建立与监控执行
评估系统需求保证通过需求定义和配置过程来确定用户的分析过程所有的需求
保证需求被评审，以确定它是切实可行的，
描述清楚的和一致的
保证分配需求，工作产品和活动的变化都被
确定，评审，跟踪到结束
项目参与者受到必要的培训
保证分配需求的约定是同被影响的组协商有
同意的
验证约定文档化，被传达，被评审和被接受
保证潜在需求受到评审，被文档化，并在分
配需求中作出必要的变化
验证定义，文档化和分配需求的过程被执行
和文档化
确认CM过程受控和管理基准
验证需求文档化，被管理，受控，和被跟踪
验证同意的需求在SDP中给予记录评估系统设计保证生存周期文档和可跟踪距阵准备好并是过程最新的和一致的
验证相关的生存周期文档是更新的并基于批
准的需求变化
识别缺陷，保证已发现的缺陷被解决，和变
更控制完整性
选择性的评审和审计系统设计文档
确定不符合标准的项，并确定矫正措施
决定需求，设计和工具符合标准和是否放弃
进一步的软件开发
评审实例原型满足需求和标准
保证实例符合标准和规程
评审设计的里程碑状态
评估软件需求保证需求定义和分析过程及相关的需求评审分析过程符合标准和规程
保证需求分析引起的行动条款符合标准和规
程 评估软件设计保证软件设计过程和相关的设计评审符合标
过程准和规程
保证设计评审引起的行动条款符合标准和规
程 评估跟踪和文档化软件单元开发的方法作为
评估软件单元开发进程的利用率
保证作为跟踪和文档化软件单元开发的方
法，如SDF，UDF，得到实施且是最新的评估编码和单保证编码过程，相关的代码评审，软件单元元测试过程测试符合标准和规程
保证代码评审引起的行动条款符合标准和规
程
保证SDF/UDF得到实施和保持最新
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第47页
保证矫正措施有效地使差异得到解决
保证软件性能测试结果将允许确定软件的性
能参数
保证测试和报告结果的职责分配给明确的组
织元素
保证监控测试的规程已经建立
评审软件测试计划和软件测试规程
保证软件被测试过
评估最终-项目
交付过程
评估矫正行动定期评审矫正过程和其结果，评估矫正行动过程过程的有效性
实施所有报告问题的分析，确定出可能揭露
一般问题区域的趋势
媒体验证
不交付的软件
验证
评估存取和操
作过程
评估子合同控
制
评估偏离和放
弃过程
评估配置管理保证配置确定的文档，代码，和计算机数据过程已经建立标准
变化的基准管理确定，评审，实施和与建立
规程合为一体
保证基准文档和软件变化的配置控制符合
CM需求
保证配置状态报告准备好，且符合所建立的
规程，并报告了同有关软件产品和文档的配
置管理有很重要关联的的重要条款的状态
保证个人遵守SCMP参与配置审计
保证文档控制，只有被批准的，最新的文档
才能被引用，文档分配过程导致收到正确的
文档
保证所有软件的基准版本只放在规划支持库
里面，并有软件名称和独一无二的标识评估软件开发
库控制过程保证SDL的建立和规程能管理它的操作
保证文档和计算机材料得到批准并在库的控
制下
保证CM批准的文档和软件版本的正式释放
的规程建立
保证库的控制不受未经受权的更改和保证所 有批准变更的合并
评估不直接开 发的软件过程
实施配置审计
验证需求管理
KPA的实施情
况
验证软件项目
策划KPA的实
施情况
验证软件项目
跟踪和监督
KPA的实施情
况。
验证软件子合
同管理KPA的
实施情况
验证软件配置
管理KPA实施
情况
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第48页
软件产品/工具和设备/项目技术评价报告摸板
报告编号: SQAL: 日期:
SQAM: 日期: 1. 软件产品/工具和设备/项目技术评估:
2. 评估方法或标准:
3. 评估结果:
4. 建议纠正措施:
5. 实施纠正措施:
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第49页
过程审计报告摸板 报告编号:
主要审计人: 报告日期:
项目名称: 项目编号:
审计项:
审计日期:
审计过程/程序:
审计检查表(附件)
审计结果:
过程/程序 可接受
过程/程序 有条件的接受
条件说明:
过程/程序 不可接受
条件说明:
措施项:
A1# 标题 责任人 预计日期 完成日期
纠正措施:
审批: 批准 取消 推迟 PM: 日期: 验证关闭:
SQAL: 日期:
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第50页
SQA测量报告摸板
报告编号: SQAL: 日期:
SQAM: 日期: 软件产品/软件工具/项目设备评估测量
软件产品 规模/形态 评估工作时 报告工作时
Of Page 20 3 1 软件需求说明
过程/程序审计测量
软件开发过程 审计准备工作时 审计工作时 报告工作时
2 2 1 纠正措施过程
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第51页
文档编号:Test005
版本编号:V1.00
密 级:中
北京侏罗纪软件开发有限公司
质量控制部文档
XX系统 之
xx系统
缺陷报告
文档编号:Test005 版本号 :V1.0
文 件 名:缺陷报告.doc
编 写:质量控制部 年 月 日
校 对: 年 月 日
审 核: 年 月 日
批 准: 年 月 日
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第52页
XXX系统之
XX系统
缺陷报告
版本 1.0
修订历史记录
日期 版说明 作者
本
1.0 首次的缺陷报告 质量控制部
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第53页
缺陷报告
一.简介
1.1目的
本文档作为《XXX系统》之< XX系统>的“缺陷报告”，有助于实现以下目标: A、 列出测试活动的主要内容。
B、 列出测试活动的测试统计结果。
C、 列出系统的主要缺陷。
D、 对于缺陷提出的修改建议。
E、 由于本系统的某些需求尚未最后确定，目前只能对系统进行部分的功能测试及完全的用户界面测试。 F、 本报告为针对测试活动的首次缺陷报告，以后的测试活动还会提交迭代的缺陷报告。 G、 本文档提交给项目组的管理者及开发人员审阅。
二.测试内容
下面的列表列出了本次测试活动的主要测试内容。
2.1数据库测试
核实系统是否能访问数据库。
2.2功能测试
核实..
2.3用户界面测试
浏览所有的用例，核实是否每个 UI 面板都易于理解。
核实界面操作是否简单易行，图形显示是否清晰。
三.测试统计结果及缺陷总结
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第54页
3.1数据库测试
3.1.1核实系统是否能访问数据库。
3.2功能测试
3.2.1核实是否能够浏览数据库中保存的电子化文档;
3.2.2核实是否能够查找和检索资料;
3.2.3核实是否能够实现资料文件的管理;
3.2.4核实是否能够实现资料文件图片的导入;
3.2.5核实是否能够实现资料文件图片的导出;
3.2.6核实是否能够实现资料的打印输出;
3.2.7核实是否具有灵活的显示模式，如放大、缩小等。 3.3用户界面测试
3.3.1窗口
3.3.2下拉式菜单和鼠标操作
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第55页
3.3.3数据项
四.针对缺陷提出的建议
4.1功能方面 4.2用户界面方面
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第56页
项目总结
项目编号:
项目类项:产品研发/项目/数据服务/组件开发/等
部门名称:
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第57页
目录
1. 引言
2. 项目开发结果 2.1软件产品或软件项目
2.2主要功能和性能
2.3项目规模总结
2.4项目人员总结
2.5进度及工作量总结
3. 项目评价 3.1生产效率评价
3.2技术方法评价
3.3产品质量评价
3.4出错原因分析
4. 经验和教训
1. 引言
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第58页
说明实际参加人员、时间及工作划分:说明参加本项目的负责人、参加人员、起止时间及实际工作量。按项目开发的阶段划分，细划每位开发人员在各开发阶段所用开发时间及实际工作量。 负责人: 起止时间: 计划工作量:
项目情况
阶段 参加人员 工作内容 起止时间 实际工作量
A、B 需求分析
等等
系统设计
编码
测试
其它
合计
2. 项目开发结果
2.1 软件产品或软件项目
2.1.1 软件产品或软件项目名称:给出该软件项目或软件产品在项目任务书或开发计划评审等
文件中确定的正式的项目名称和项目编号;并给出该软件项目或软件产品正式批准发布
的版本标识。
2.1.2 程序量:按模块进行划分，给出该软件项目或软件产品的源程序的存贮容量。源代码用代
码行来表示，可执行程序及其他程序可用字节来表示，文档可用页或字节来表示。(源代
码一定要按模块来统计)
模块名称 代码行(千行) 字节数(KB)
模块1
源码
模块2
执行程序
等等
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第59页
注:源码不填写“字节数”，执行程序只填写“字节数”。
2.1.3 存储介质:给出该软件项目或软件产品正式发布版本的存储介质及所需存储介质及
其数量。
2.2 主要功能和性能
1)描述该软件项目或软件产品所实现的功能，根据需要说明该软件项目或软件产
品的有关性能指标。
2)与最初的需求相比较，给出功能和/或性能上的差异并说明原因。 2.3 项目规模总结
根据软件开发的各阶段，总结该软件项目或软件产品完成的功能模块数量与计划的对比，
给出对比图表，并对比较结果进行分析。
阶段 计划模块数 完成模块数
需求分析
系统设计
编码
测试
合计
2.4 项目人员总结
总结该软件项目或软件产品开发各阶段人员的变化情况与计划的对比，并对比较结果进
行分析。
阶段 计划人数 实际人数 增加人数 减少人数 变动人数
需求分析
系统设计
编码
测试
总计
注:变动人数为人员更换数。
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第60页
7
6
5
计划人数4
实际人数
3变动人数
2
1
0
需求分析系统设计编码测试
2.5 进度及工作量总结
总结该软件项目或软件产品实际完成所用的时间及工作量与原计划的对比。用图表来表
示。
2.5.1 从开发人员的角度进行总结:将每位开发人员开发该软件项目或软件产品起止时间和工作
量与计划进行比较，给出对比图表，并对比较结果进行分析。 开发人员 计划时间 实际时间 是否按时 计划M 实际M A B C D 等等 35
30
25
20计划M
实际M15
10
5
0
ABCD
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第61页
2.5.2 从模块的角度进行总结:将每一模块完成的起止时间和工作量与计划进行比较，给出对比
图表，并对比较结果进行分析。
程序文件 产品研发流程 2003年 月 日起生效 文件号
编制 审核 批准 版 次 1.0
日期 日期 日期 共68页 第62页
模块名称 计划时间 实际时间 是否按时 计划M 实际M
模块1
模块2 模块3 模块4
总计
35
30
25
20计划M
实际M15
10
5
0
模块1模块2模块3模块4
2.5.3 从开发阶段的角度进行总结:将每一阶段完成的起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。
阶段 计划时间 实际时间 是否按时 计划M 实际M
需求分析
系统设计 编码 测试
总计
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第63页
35
30
25
20计划M
实际M15
10
5
0
需求分析系统设计编码测试
2.5.4 从工作量的角度进行总结:将开发该软件项目或软件产品所用工作量与计划进行比较，给
出由于软件问题报告所增加的工作量，给出对比图表，并对比较结果进行分析。
批复工作量 实际工作量
计划 增加 小计
2.5.5 从完成情况进行总结:将项目的总体进度和阶段进度与计划进行比较，说明此项目是正常
完成、正常但增加工作量、延期但不增加工作量、即延期又增加工作量，并对比较结果进
行分析。
计划时间 实际时间 批复工作量 实际工作量 结论
注:以最后一版的开发计划中的开发进度为准，批复工作量包括由于软件问题报告增加的
工作量。
3. 项目评价
3.1 生产率评价
评价生产率可以有两种方法:代码行数与人月数比较，或修改BUG数与所用人月数的比
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第64页
较。我们可以采用任何一种。如果采用第一种方法，应以模块为单位进行比较;如果采用
第二种方法，应以各测试版本的BUG数、修改的BUG数、修改BUG所用的工作量及修
改单位BUG所用的工作量进行比较，总结评价项目的开发效率及相应的原因分析。
模块名称 代码行(千行) 工作量 代码行/工作量
模块1
模块2
等等
3.2 技术方法评价
总结该软件项目或软件产品开发时所采用的各项技术。
3.3 产品质量评价
可参考以下几个方面进行产品质量的评价。
1) 历次测试发现的BUG数;
2) 同种原因产生的BUG数;
3) 同种类型的BUG数;
4) 各等级的BUG数;
5) 同一BUG出现的次数。
3.4 出错原因分析
分别对以上几种情况绘制图表，进行原因的分析。
BUG数 BUG数 BUG数 BUG数 次数 原因 类型 等级 BUG名 次数
4. 经验和教训
可以从以下几方面总结开发中获得的经验及纠正错误或缺陷等问题的教训。
1) 管理人员的管理水平;
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第65页
2) 开发人员的合理分工;
3) 项目软件经理PSM及开发人员的技术水平;
4) 开发人员的更换;
5) 开发人员的配合及协作;
6) 用户的密切配合;
7) 需求及设计的更改;
8) 开发过程中计划的合理调整等等。
程序文件 产品研发流程 2003年 月 日起生效 文件号
编制 审核 批准 版 次 1.0
日期 日期 日期 共68页 第66页
资源中心验收单,式样，一式三份
序编号 成果题名 完成日期 提交日期 页数 密级 保管期限 备注 号
1 NAVIKEN Ver2.1 1998-8-21 72 长期 MO盘 2 1998-12-30 42 多媒体办公自动化系统MOAS 长期 磁盘
填表人, 成果管理员, 成果提交人,
程序文件 产品研发流程 2003年 月 日起生效 文件号
1.0 编制 审核 批准 版 次
日期 日期 日期 共68页 第67页
卷内成果目录,式样，一式三份
序号 文件编号 责任者 题 名 日期 页次 备注 1 AT97004DP01 FAX 1997-3-31 1 李峰
2 NA504100A 1997-4-3 4 王琛 乐器练习软件功能说明书
3 AT97004SD01 1997-4-3 64 李峰 乐器练习软件概要书
4 NR506100A 1997-4-25 102 王琛 AMOR RT Ver 1.0开发计划
第 页/共 页
程序文件 产品研发流程 2003年 月 日起生效 文件号
编制 审核 批准 版 次 1.0
日期 日期 日期 共68页 第68页
浙公网安备 33021202002483