软件开发规范(1)

Q/SY

中国石油天然气股份有限公司企业标准

Q/SY XJ 0269—2014

软件开发规范

Specification for software development

     

报批稿

201X - XX - XX发布

     - XX - XX实施

中国石油天然气股份有限公司油田分公司  发布

目  次

前  言

本标准依据GB/T 1.1-2009给出的规则起草。

本标准附录A、附录B、附录C、附录D、附录F、附录G、附录H、附录I、附录K为规范性附录，附录E、附录J、附录L为资料性附录。

本标准由油田分公司数据公司提出。

本标准由油田分公司信息专业标准技术委员会归口。

本标准起草单位：油田分公司数据公司。

本标准主要起草人：石峰、刘燕俐、冯斌、姜力、华磊、马骥、贾鹿、郑光慧。

软件开发规范

1　范围

本标准给出了软件开发活动中的过程管理、质量管理、变更管理以及文档管理要求。

本标准适用于油田公司软件开发管理。

2　规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

Q/SY XJ 0204-2009  勘探开发数据库数据表编码规范

Q/SY XJ 0205-2009  数据库逻辑结构管理规范

Q/SY XJ 0243-2010  应用系统运行维护管理规范

3　组织机构及成员

3.1　组织机构

软件开发实行项目制管理。项目组织机构由信息化工作管理部门、项目建设单位、项目承担单位组成。

3.2　组织成员

由项目建设单位负责指派用户总监、信息化工作管理部门负责指派项目监督、项目承担单位负责指派项目经理。由项目经理负责组建项目组。

用户总监

项目的总体负责人，负责组织应用需求、系统测试和应用推广协调。

项目经理

负责组建项目组、制定项目计划、组织项目实施。

项目监督

负责技术审查、计划进度监管并协调项目各方开展实施工作。

项目组成员

项目组成员除项目经理、用户总监、项目监督外，还包括程序开发人员、测试项目负责人、测试人员。其职责分别为：

a)程序开发人员负责程序编码工作；

b)测试项目负责人负责组织软件测试，管理监督测试项目，提供技术指导，负责技术协调，负责项目的安全保密和质量管理；

c)测试人员负责建立测试环境、执行测试、记录测试结果、分析测试结果。

4　总体描述

软件开发是一个循序渐进的过程，需要经过若干次的迭代开发才能日趋完善。对每一次软件开发均按软件开发生命周期理论分阶段进行；对启动、需求、设计、编码、测试、上线等所有阶段，均需进行全面项目管理和质量控制。具体要求按第5章的规定执行。软件开发过程总体流程如图1所示。

图1 软件开发过程总体流程图

5　过程管理

5.1　启动阶段

工作流程

项目启动后，项目经理依据立项内容和要求，确定完成软件开发的各项任务范围，制定各项任务的时间表，明确开发组成员及其工作责任以及相应的职权。工作流程如图2所示。

图2 启动工作流程图

流程描述

d)信息化工作管理部门下达立项通知，确定项目监督；

e)项目监督依据油田公司相关规定组织项目启动工作，与用户总监共同完成项目承担单位的选定；  

f)项目承担单位负责指派项目经理，项目经理依据立项内容和要求开始需求调研，与用户沟通确定项目目标、范围与基本需求，并完成计划文档的编制；

g)用户总监和项目监督负责审查计划文档。审查通过后，在《软件开发项目计划要点表》上签字确认，格式见表A.1；

h)计划文档在评审通过后5个工作日内，由项目监督提交并归档。

质量要求

i)完整性：能严格遵循下达立项中所列工作内容，阶段清晰，里程碑明确；

j)可操作：有一个可执行、可控制的工作进度安排；

k)可管理：能及时发布和维护并能依据项目管理的有关规定实施管理；

l)可变更：能依据项目管理的有关规定实施变更；

m)可规避风险：能预先建立规避措施，并据其调整不能如期实施的计划。

提交文档

a)《软件开发项目实施计划》，格式为. proj文件；

b)《软件开发项目计划要点表》；

c)《软件开发项目风险清单》，格式见表A.2。

5.2　需求分析阶段

工作流程

在需求分析阶段，项目经理理解用户需求，就软件功能与用户达成一致，评估软件风险。工作流程如图3所示。

图3 需求阶段工作流程图

流程描述

n)用户总监负责组织需求调研，界定系统的目标和范围，确定需求的详细内容；

o)项目经理负责进行需求分析，形成《软件需求说明书》，格式见B.1，并填写《软件开发项目需求－设计－测试链接关系表》,格式见表B.1

p)用户总监负责组织专家对需求文档进行评审；

q)评审结束后，评委在《软件开发项目需求评审表》上签字确认，格式见表B.2；

r)项目监督负责在评审结束后1个工作日内向项目经理及有关方通报评审结果；

s)如未通过需求评审，项目经理负责组织需求分析人员在5个工作日内完成整改；

t)需求评审通过后5个工作日内，项目经理负责将需求文档提交至项目监督归档。

质量要求

u)可行性：在已知的能力、有限的系统及其环境中，每个需求应是可实现的；

v)正确性：需求应能准确地表达用户的意图和需要；

w)完整性：需求应完整地描述用户的需要，不应遗漏重要需求和必需的信息；

x)一致性：需求应遵守不同层次间的一致性关系，保证业务需求和功能需求一致；

y)优先级：每个需求应明确地标注其实现的优先级；

zz)明确性：需求应采用简洁、直观、用户熟知的语言进行描述，并使预期读者能够从中得到唯一的解释说明；

aa)可修改：需求可依据管理要求实施变更、跟踪和管理。

提交文档

bb)《软件需求说明书》；

cc)《软件开发项目需求－设计－测试链接关系表》；

dd)《软件开发项目需求评审表》。

5.3　设计阶段

工作流程

在设计阶段，项目经理根据需求阶段的需求定义，设计出解决方案，详细说明系统的设计。工作流程如图4所示。

图4 设计阶段工作流程图

流程描述

ee)项目经理依据《软件需求说明书》编制完成《系统设计说明书》，格式见C.1；

ff)项目经理按Q/SY XJ 0205-2009的规定进行数据库逻辑结构设计，生成《数据库设计说明书》，格式见C.2，数据表按Q/SY XJ 0204-2009的规定进行规范命名设计；

gg)根据《系统设计说明书》中对组件的功能需求生成《组件设计说明书》，格式见C.3；

hh)测试项目负责人依据《系统设计说明书》完成《测试设计说明书》，格式见C.4，并填写《软件开发项目需求－设计－测试链接关系表》；

ii)项目监督负责组织专家对设计文档进行评审；

jj)设计评审通过后，评委在《软件开发项目系统设计评审表》上签字确认，格式见表C.1；

kk)项目监督在评审结束后1个工作日内对评审结果进行通报；

ll)如未通过设计评审，项目经理负责组织系统设计人员在5个工作日内完成整改；

mm)项目经理在评审通过后5个工作日内将设计文档提交至项目监督归档。

质量要求

a)正确性：设计应准确地表达《软件需求说明书》所确认的系统目标；

b)完整性：设计应覆盖软件需求分析目标所涉及的全部范围；

c)可测性：设计应能定量表示，可通过数学计算、平台测试、经验统计等方法得到具体数据，为软件测试提供支持。

提交文档

nn)《系统设计说明书》；

oo)《数据库设计说明书》；

pp)《组件设计说明书》； 

qq)《测试设计说明书》；

rr)《软件开发项目系统设计评审表》；

ss)《软件开发项目需求－设计－测试链接关系表》。

设计要求

a)对实施集中部署、统一运维的软件系统应满足以下要求，包括：支持统一认证，支持集群方式部署，采用服务名访问数据库集群，使用的配置文件，用户及密码采用统一算法进行加密，在系统主界面提供在线咨询论坛的访问链接，按油田公司统一要求提供系统日志；

b)满足数据库统一管理的要求，包括：物理数据库与《数据库设计说明书》保持一致，数据库逻辑结构设计符合关系数据库设计的第一范式和第二范式。

5.4　编码阶段

编码流程

在编码阶段，将系统分成几个模块（或构件）和程序。为每个程序（或构件）进行逻辑设计，产生可执行程序以及应用数据库，同时为每个程序（或构件）进行单元测试。工作流程如图5所示。

图5 编码阶段工作流程图

流程描述

tt)项目经理负责根据设计文档对系统框架、应用功能进行程序开发，对数据库进行物理建模及开发，编制《源程序说明书》，其格式见附录D，并生成可执行程序；

uu)编码阶段完成后，由项目经理将可执行程序及《源程序说明书》提交至项目监督归档。

质量要求

a)规范性：每个软件编码过程的程序风格、命名规则、注释规范等参见附录E；

b)正确性：每个软件编码过程中，软件单位源代码（每千行无注解源代码为一个单位）所隐藏的缺陷数量应控制在一定范围。具体规定为开发阶段小于10个，交付使用后小于2个。

提交文档

vv)《源程序说明书》；

ww)可执行程序。

5.5　测试阶段

测试流程

在测试阶段，测试验证已开发完成的系统是否满足软件开发合同、系统设计说明书和软件产品说明等规定的软件质量要求，发现软件缺陷，为软件产品的质量测量和评价提供依据。工作流程如图6所示。

图6 测试阶段工作流程图

流程描述

xx)测试项目负责人负责依据《测试设计说明书》搭建测试环境；

yy)测试项目负责人依据《软件需求说明书》、《系统设计说明书》及《测试设计说明书》的要求，组织单元测试、集成测试、系统测试，填写《缺陷记录和跟踪表》，格式见表F.1，并负责跟踪整改；

zzz)系统测试通过后，项目经理负责完成《用户手册》的编制，格式见F.2，并向用户总监提出用户测试申请；

aaa)用户总监负责组织用户测试，填写《缺陷记录和跟踪表》，项目经理负责用户测试中缺陷的整改；

bbb)项目经理根据测试情况，完成《项目测试总结报告》编制，格式见F.3；

ccc)用户总监负责组织测试评审。评审通过后，用户总监在《测试结果确认表》上签字确认，格式见表F.2；

ddd)项目经理在测试评审通过后5个工作日内将《用户手册》、《缺陷记录和跟踪表》、《项目测试总结报告》提交项目监督归档。

质量要求

a)全面性：测试用例设计应能体现测试的全面程度，将遗漏缺陷数（即软件系统发布后用户报告的缺陷数）尽可能控制在较小范围；

b)有效性：测试应能正确理解软件系统并发现有效的问题，保证递交缺陷的有效率；

c)性：每个测试应保证软件测试参与人员开展工作。

提交文档

a)《缺陷记录和跟踪表》；

b)《用户手册》；

c)《项目测试总结报告》；

d)《测试结果确认表》。

5.6　上线阶段

上线包括验收投产和上线运行，按照Q/SY XJ 0243-2010第2章规定执行。通过上线审核后5个工作日内，项目经理完成《项目开发总结报告》的编制，格式见附录G，并提交用户总监和项目监督审核，审核通过后提交项目监督归档。

通过上线审核后10个工作日内，项目监督依据项目执行过程、管理过程及成果质量情况完成《项目评估报告》的编制并提交归档，格式见附录H。

6　质量管理

6.1　质量控制 

文挡控制

最终文档组成

软件开发过程中所产生的技术资料、产品均作为软件开发文档进行管理。各类技术文档应严格依据规范的模板与方法进行编写。在一项软件开发过程中，至少应提交以下7种技术文档：

eee)《软件需求说明书》（附：软件开发项目计划要点表、软件开发项目需求评审表）；

fff)《系统设计说明书》（附：软件开发项目系统设计评审表、组件设计说明书）；

ggg)《数据库设计说明书》；

hhh)《测试设计说明书》；

iii)《用户手册》；

jjj)《项目测试总结报告》（附：缺陷记录和跟踪表、测试结果确认表）；

kkk)《项目开发总结报告》。

文档管理

软件开发文档应以电子或纸质形式存在，并按照正式文件名+V+版本号命名。文档管理应满足以下要求：

lll)电子文档存放在约定文件服务器的文件夹或存储介质中；

mmm)软件开发文档有版本控制措施，保留各修订版本；

nnn)在软件开发过程中，由项目经理或其指派专人负责软件开发文档的保管。项目验收后，由项目建设单位或信息化工作管理部门负责项目文档的归档。

评审控制

软件开发过程中应满足以下的评审要求：

ooo)软件开发的每个阶段在其实施结束后，通过技术评审或专家确认才能组织进行软件开发下一个阶段的实施工作；

ppp)数据库逻辑结构设计经信息标准专家评审通过，才能组织实施。

沟通管理

项目监督负责对项目计划的实施进行管理。每周检查项目内容是否与要求发生偏差，进度是否滞后，尤其对里程碑严格检查和控制。检查结果不符合要求时，应及时进行通报。管理过程应符合以下基本管理要求：

qqq)项目经理每周五向用户总监、项目监督提交《软件开发项目工作周报》，格式见I.1，每月24日前向用户总监、项目监督提交《软件开发项目工作月报》，格式见I.2；

rrr)项目监督每月至少组织一次项目例会，项目经理在项目出现问题时应及时向项目监督反馈，项目监督应及时沟通或组织会议协调解决；

sss)项目开发过程中的所有会议，均应在会议结束的1个工作日内，以《会议纪要》形式加以记录与通报，格式见I.3。

6.2　质量评价 

软件质量特性

功能性

由以下4个子特性组成:

ttt)适合性：与所提供的功能和用户需求适合程度有关的软件属性；

uuu)准确性：与能否得到正确或相符的结果或效果有关的软件属性；

vvv)互操作性：与同其他指定系统进行交互的能力有关的软件属性； 

www)安全性：与防止程序及数据非法访问的能力有关的软件属性。

可靠性

由以下3个子特性组成:

xxx)成熟性：与由软件故障引起失效的频度有关的软件属性；

yyy)容错性：与在软件故障情况下，维持规定的性能水平的能力有关的软件属性；

zzzz)易恢复性：与在失效发生后，重建性能以及恢复数据的能力有关的软件属性。

易用性

由以下2个子特性组成:

aaaa)易学性：与用户为学习软件应用所花的努力有关的软件属性；

bbbb)易操作性：与用户为操作和运行软件所花努力有关的软件属性。

效率

这里特指时间特性，即与软件运行时响应和处理时间有关的软件属性。

稳定性

与软件进行长时间连续运行能力有关的软件属性。

软件质量评价

度量

本标准采用语言描述的度量方法对质量特性进行测量，具体要求参见表J.1。

等级

通过将测量结果映射到尺度，来分割各个不同的评定等级，具体要求参见表J.2。

评估准则

对于不同类型的软件，各质量特性的重要性不同。应根据业务需求，对各度量项实施必要的裁剪，以完成对软件成果质量的最后评价。

7　变更管理 

7.1　变更

变更流程

变更管理作为贯穿于软件开发应用生命周期各个阶段的关键要素，旨在准确地记录软件产品的演化过程，帮助开发人员在各个阶段得到不同版本的产品配置。本标准的变更管理以项目开发内容变更为主，贯穿需求分析、系统设计和系统测试等主要开发流程。变更流程如图7所示。

图7 变更流程图

流程描述

过程变更的工作流程描述：

cccc)项目经理根据项目的需要，向用户总监提出项目开发计划变更、需求变更、技术方案变更或项目关键人员变更，提交《软件开发项目变更申请表》，格式见表K.1；

dddd)用户总监审批通过后,项目经理根据《软件开发项目变更申请书》调整项目开发内容和项目开发组成员，变更项目开发计划,计划管理遵循5.1；

eeee)变更过程中,项目经理对照《软件需求说明书》,确定是否调整系统需求，如需调整，遵循5.2的规定；

ffff)变更过程中,如需对开发内容进行变更，项目经理对照《系统设计说明书》,重新进行系统设计, 遵循5.3的规定；

gggg)变更过程中,项目经理对照《测试设计说明书》,对变更的开发内容重新进行系统测试设计, 遵循5.5的规定。

提交文档

变更完成后应提交以下文档：

hhhh)《软件开发项目变更申请表》；

iiii)依据变更范围所需修订的相关文档。

7.2　计划变更

软件开发过程中，出现进度安排需要调整的情况，项目经理应填写《软件开发项目变更申请表》，经用户总监审核确认后，同时提交更新后的《软件开发项目计划要点表》至信息化工作管理部门，方可变更。

7.3　需求变更

软件开发过程中，出现用户要求调整需求的情况，项目经理应填写《软件开发项目变更申请表》，经用户总监审核确认后，同时提交更新后的《软件需求说明书》至信息化工作管理部门，方可变更。

7.4　技术方案变更

软件开发过程中出现技术方案需要调整的情况，项目经理应填写《软件开发项目变更申请表》，经用户总监确认后，提交《系统设计说明书》、《数据库设计说明说》至信息化工作管理部门审核批准，方可变更。

7.5　人员变更

软件开发过程中出现主要参与人员需要调整变动的情况，项目经理应填写《软件开发项目变更申请表》，经用户总监审核确认后，提交至信息化工作管理部门，方可变更。

8　文档管理

8.1　文档分类

软件开发过程涉及文档分类表参见表L.1。

8.2　文档阶段分布

文档阶段分布表参见表L.2。

附　录　A

（规范性附录）

软件开发过程启动阶段文档模板汇总

A.1　软件开发项目计划要点表模板

表A.1　软件开发项目计划要点表

                                                                                                                                  填表日期

序号

任务名称

计划 开始时间

计划 完成时间

任务负责人

提交成果

实际 完成时间

备注

项目承担单位 审核意见

签名:                  年   月   日

项目监督 审核意见

签名:                  年   月   日

用户总监 审核意见

签名：                               年   月   日

填表说明：实际完成时间由项目监督根据项目实际进度填写。

A.2　软件开发项目风险清单模板

表A.2　软件开发项目风险清单

                                                    填表日期

项目名称
承担单位				项目经理
项目风险识别
序号	风险类型		风险内容		风险概率		风险级别	规避风险措施
1	需求风险
2	计划编制风险
3	组织和管理风险
4	人员风险
5	开发环境风险
6	客户风险
7	产品风险
8	技术风险
9	过程风险
项目风险评估
项目监督评估意见		评估时间：     年    月    日                           签  名：

附　录　B

（规范性附录）

软件开发过程需求分析阶段文档模板汇总

B.1　软件需求说明书模板

软件需求说明书

项目名称： 

委托单位： 

承担单位： 

编写：                    年  月  日

校对：                    年  月  日

审核：                    年  月  日

《软件需求说明书》的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。《软件需求说明书》编制指导如下。

1  引言

1.1 编写目的

说明编写这份《软件需求说明书》的目的，指出预期的读者。

1.2 项目背景

说明待开发的软件系统的名称、版本号说明、本项目的任务提出者、开发者、用户。

简述项目的来源和背景情况，说明已进行的前期工作及决策过程以及该软件系统同其它系统的关系。

说明本项目在油田公司信息规划中的定位和作用。

1.3 修订审批记录

说明编写这份《软件需求说明书》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
审批方式	审批日期	版本	审批意见	提交者	审批者

1.4 术语和缩写词

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.5 参考资料

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。

2 任务概述

2.1 项目目标

说明项目建设的总体目标和具体目标。项目目标应尽量细化、量化，如可以分为业务目标、功能目标，便于对目标进行考核和验收。

2.2 组织范围

列出本项目的组织范围（负责单位、建设单位、用户单位等）。

2.3 业务需求

条目化地叙述本软件最终用户的原始业务需求，包括：业务指标、技术指标、总体功能需求、目标用户功能需求等，为需求分析提供支持。

2.3.1 业务指标

从业务的角度进行需求分析，分析与本项目相关的业务领域、机构与部门在业务运作、流程、管理、操作等方面对本项目的需求。根据不同的业务类型和部门，逐个进行梳理和分析，提出业务指标。

2.3.2 技术指标

列出本项目的主要技术指标。应用系统主要技术指标包括且不限于（系统响应时间、系统总体可用率、系统最大用户数、平均并发用户数、数据在线保存时间等）。

2.3.3 总体功能需求

对照项目目标和业务需求，分析本项目应实现的总体功能和各项具体功能要求。

2.4 假设和约束

列出进行本软件开发工作的假定和约束，例如经费、开发期限等。

3需求分析

3.1 目标用户分析

列出本软件的目标用户的职责和分工，划分目标用户角色和层次关系，充分说明各角色在本系统范围内的职责和技术要求，以及本软件的预期使用频度。

3.2 业务流程

说明待开发软件系统的业务流程。此流程可用图表即业务流程图的形式表示，并加以叙述。

3.3 数据流程

说明待开发软件系统的数据流程。此流程可用图表即数据流图的形式表示，并加以叙述。

3.4 数据需求

3.4.1 数据建设需求

根据项目所涉及业务数据种类和分布情况，分析数据源现状，提出相应数据源建设需求。

3.4.2 数据量测算

分析对于数据采集、数据存储、数据处理与应用的需求，分析数据处理量、存储量、传输流量，测算数据量的现值和未来3～5 年的预测值。

3.4.3 标准化需求

分析本项目对于数据编码和信息标准化的需求。

3.5 功能需求

描述系统功能需求，绘制系统功能框架图。

3.5.1 XX功能需求

从以下四个部分，详细叙述功能要求，说明功能需求具体分析过程。

（1）功能描述

该功能要达到的目标、所采用的方法和技术。还应清楚说明该功能意图的由来和背景。

（2）业务流程

说明该功能需求所涉及的业务内容和业务流程。此流程可用图表即流程图的形式表示，并加以叙述。

（3）数据流程

描述该功能的数据流图及分模块的数据流图，包含数据类型、数据项、数据来源及流向、频度等指标，绘制数据流图。

（4）界面原型

描述用户对于界面的操作需求，绘制出基本的界面原型图。

3.5.2 XX功能需求

……。

3.5.n XX功能需求

……。

3.6 性能需求

对于应用系统，分析系统对处理能力、存储能力和传输能力等性能指标要求，包括容量、最大用户数、平均并发用户、响应时间、平均无故障时间等。分析系统对硬件设备的性能要求，如对设备可靠性（集群、双机热备份）的需求。

对于网络系统、数据中心，根据项目性质和特点，分析其性能需求，提出具体的指标。

3.7 安全保密需求

分析系统可用性、保密性需求，如系统安全等级、信息保密等级、身份认证、防病毒等。

3.8 备份与灾备

根据系统的安全保密需求和业务连续性需求，分析对数据备份、系统备份的要求，包括恢复点目标（RPO）、恢复时间目标（RTO）、灾备等级以及对备份方式、周期、介质存储时间要求等。分析系统对于同城备份及异地灾备系统的需求。

3.9 接口需求

从业务角度描述本项目与在用及规划拟建应用系统的关系，分析本系统与其它系统接口需求。

3.10 其它需求

分析建设单位对本项目的其它需求，如用户培训、系统维护等。

B.2　软件开发项目需求－设计－测试链接关系表模板

B

表B.1 软件开发项目需求－设计－测试链接关系表

                                                                                                         填表日期

项目名称							项目经理
需求说明书版本号				设计说明书版本号			测试方案版本号
序号	业务需求			需求分析				功能设计		测试用例
	章节编号	摘要		章节编号	摘要			章节编号		用例编号
填表说明： 1.本表定义了需求、设计与测试之间的对应关系。表中业务需求从《软件需求说明书》中2.3章节摘录，需求分析从需求说明书中第3章节摘录，功能设计从《系统设计说明书》中第4章节摘录，测试用例从《测试设计说明书》中第4章节摘录。 2.本表应随着需求、设计、测试文档的编制和修订同时更新，在需求、设计、变更申请时一同提交审核。

B.3　软件开发项目需求评审表模板

表B.2 软件开发项目需求评审表

项目名称：                                                                                             填表日期

序号	角色	姓名	工作单位	职称/职务	个人意见	本人签名
评审组长审核意见：                                    签名：
填表说明：该评审表最终提交项目监督，并把复印件装订在《软件需求说明书》的扉页。

附　录　C

（规范性附录）

软件开发过程设计阶段文档模板汇总

C.1　系统设计说明书模板

系统设计说明书

项目名称： 

委托单位： 

承担单位：  

编写：                    年  月  日

校对：                    年  月  日

审核：                    年  月  日

批准：                    年  月  日

《系统设计说明书》的编制，是为了说明对程序系统的设计考虑。《系统设计说明书》编制指导如下。 

1 引言

1.1 编写目的

说明编写这份《系统设计说明书》的目的，指出预期的读者。

1.2背景

说明待开发的软件系统的名称、版本号说明、本项目的任务提出者、开发者、用户以及该软件系统同其他系统的关系。

1.3 术语和定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。

1.5 修订审批记录

说明编写这份《系统设计说明书》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
审批方式	审批日期	版本	审批意见	提交者	审批者

2 设计概述

2.1 设计思想

说明本系统在设计过程中所使用的设计思想，例如面向对象或过程、自顶向下等。

2.2 软件实现技术及特点

简要列出开发本软件系统的所使用的技术及特点。

2.3需求概述

简要概述所开发软件系统的基本需求，并指出详细的业务需求可参见《软件需求说明书》。

2.4运行环境

2.4.1软件环境

罗列出系统运行所需要的软件环境，例如操作系统、Web服务器软件、数据库等。

2.4.2硬件环境

简述系统运行所需要的硬件环境，包括应用服务器、数据库服务器等。

2.5开发环境

简述系统开发所使用的语言、工具等。

3 总体设计

3.1 功能架构设计

软件的功能架构规定了软件系统由哪些功能模块组成、以及这些功能模块之间的关系。可采用功能结构图和文字的方式描述系统的主要功能以及各功能模块之间的关系。

3.2 技术架构设计

用技术架构图和文字的方式描述系统所采用的技术路线以及系统的分层结构关系。

3.3 物理部署设计

物理架构图用以描述一个软件部署到现实环境的布置情况，以及如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的平台集成等要求。

4  功能设计

4.1 模块1

4.1.1 模块描述

以条目的方式详细说明该功能。给出对该模块的基本描述，主要说明设计本模块对应的主要需求，建设目的意义、建设的主要内容、模块的特点等

4.1.2 流程描述

以图示（流程图，时序图，活动图）方式描述功能的实现原理。用图表辅以必要的说明来表示本模块的逻辑流程，可以用Visio绘制流程图、或者用活动图等图形形式来描述，也可以使用UML工具构建。

4.1.3 相关算法

对于使用到特殊或者复杂算法，应具体的说明算法的计算公式及计算步骤，以及实现的方式等。

4.1.4 界面设计

绘制该功能的各个实现界面及界面之间的关系。

4.1.5 数据表

列出该功能所引用的数据表及数据项名称，并说明该功能对数据项的具体操作。

4.1.6 出错处理设计

描述该功能的出错情况和容错机制。

4.2模块2

用类似本文4.1节的方式给出第2项及其后各项功能设计描述。

．．．．．．。

4.n 模块n

．．．．．．。

5 接口设计

说明本系统同外界接口的安排（包括软件与硬件之间的接口）、本系统与各支持软件之间的接口关系。以及关于用户接口、内部接口的相关说明。

6 出错处理总体设计

6.1 出错处理设计

描述故障出现后，系统所提供的报错信息方式，以及为了系统查错维护的方便而在系统设计中所做出的设计（如错误日志等）。

6.2 出错处理一览表

用一览表的方式说明每一种可能出错的情况出现时，系统的输出信息、含义及处理的方法。

7 安全保密设计

关于系统安全保密的相关安排和处理。

8 标识符设计

说明准备在本程序中安排的标识符。库设计说明书。

C.2　数据库设计说明书模板

数据库设计说明书

项目名称： 

委托单位： 

承担单位：  

编写：                    年  月  日

校对：                    年  月  日

审核：                    年  月  日

批准：                    年  月  日

《数据库设计说明书》的编制，是对于设计中的数据库的所有标识、逻辑结构和物理结构做出具体的设计规定。《数据库设计说明书》编制指导如下。 

1引言 

1.1 编写说明 

说明编写这份《数据库设计说明书》的目的，指出预期的读者。

1.2 背景 

说明待开发数据库的名称、版本号说明、使用范围并列出本项目的任务提出者和开发者。 

1.3 修订审批记录

说明编写这份《数据库设计说明书》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
审批方式	审批日期	版本	审批意见	提交者	审批者

1.4 术语和缩写词

列出本文件中用到的专门术语的定义、外文首字母组词的原词组。

1.5 参考资料 

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。

2 外部设计 

2.1 标识符和状态 

列出用于标识该数据库的编码、名称、标识符或标号，并给出附加的描述性信息。如果该数据库是在实验中的或者暂时性的，则要说明这一特点和有效期。

2.2 使用该数据库的程序

列出将要使用或访问此数据库的所有应用程序，给出其名称和版本号。

2.3 约定 

叙述使用该数据库所必须了解的建立标号、标识的有关约定。例如，用于标识库内各个文卷、记录、数据项的命名约定等。

2.4 支持软件 

叙述与此数据库有关的支持软件，如数据库管理系统、存储定位程序等。概要说明这些支持软件的名称、功能及为使用这些支持软件所需的操作命令。列出这些支持软件的有关资料。

2.5 专门说明

向准备从事此数据库的生成、测试、维护人员所提供的专门说明。

3 结构设计 

在概念结构设计和逻辑结构设计部分仅需描述与新增表、修订表有关的内容，可以引用未做修改的表，但不进行详细描述，系统完整的数据库逻辑结构做为附件附在该文档之后。数据库逻辑结构字典格式参见附件1。

3.1 概念结构设计 

详细说明本数据库的用户视图，即反映现实世界中的实体、属性和它们之间关系的原始数据形式。包括各数据项、记录、数据表的标识符、定义、类型、计量单位和值域；描述数据模型的设计考虑，并绘制E_R图。

3.2 逻辑结构设计 

详细说明本数据库的数据库管理员视图，即把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和数据表结构、所建立的各个数据表之间的相互关系，并按照油田公司《勘探开发数据库数据表编码规范（Q/SY XJ 0204-2009）》以及《数据库逻辑结构管理规范（Q/SY XJ 0205-2009）》等相关标准设计《数据库逻辑结构》。并绘制E_R图，要求达到第二范式。

3.3 物理结构设计 

详细说明本数据库的系统程序员视图，即数据在内存中的安排，包括对索引区、缓冲区的设计；所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分以及访问数据的方式方法。

4 应用设计

详细说明数据库应用开发所产生的存储过程、包、视图、函数、触发器等设计，并做为附件附在该文档之后。具体格式参见附件2。

5 其它设计

5.1 完整性设计

说明为保持数据库中数据的完整性所作的设计考虑，如数据库的后援频率、数据共享、数据冗余等。

5.2 安全保密设计

说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象等而获得数据库安全保密的设计考虑。以及将要采用的保证数据安全保密的措施和机制，如数据库安全破坏标识、资源保护方式、存取控制方式等。

5.3 其它设计

说明其它设计考虑。

附件1  数据库逻辑结构字典格式

表名称

表代码

序

号

数据项名称

拼音代码

数据 类型

宽 度

小数 位数

计量单位

主 键

外 键

参照表

非空 值

值约束

规范值

维护 级别

数据项描述

数据来源

附件2  数据库对象设计说明模板

对于本数据库中用户创建的存贮过程、包、视图及函数按下列模板进行详细说明，并做为数据库设计说明书的附件提交。

一、存贮过程说明模板

数据库名			表空间名
过程编号		过程名称		过程版本号
开发者		完成日期		审核人

1.用途描述

详细描述此存贮过程的用途。

2.输入输出说明

说明此存贮过程的输入要求及最终输出结果。

3.算法说明

说明此存贮过程的关键算法及处理流程。

4.其它说明

说明此存贮过程需要说明的其它内容．比如引用了哪些表、调用了哪些函数或过程、内部参数或变量说明等。

5.脚本

此存贮过程的实现代码（需符合源代码写书规范）。

二、包说明模板

数据库名			表空间名
包编号		包名称		包版本号
开发者		完成日期		审核人

1.用途描述

详细描述此包的用途。

2.包头说明

详细说明此包在包头部分定义的各元素的用途。

3.算法说明

详细说明此包中的关键算法及处理流程。

4.其它说明

说明此包包体部分需要说明的其它内容．比如引用了哪些表、调用了其它哪些包、内部参数或变量说明等。

5．脚本

此包的包头及包体的实现代码（需符合源代码写书规范）。

三、视图说明模板

数据库名			表空间名
视图名称		视图编号		视图版本号
开发者		完成日期		审核人

1.功能描述

详细描述此视图的用途。

2.关联方式及引用表

说明此视图所用到的表及关联方式。

3.算法说明

说明此视图的关键算法。

4.其它说明

说明此视图需要说明的其它内容。

5.脚本

此视图的实现代码（需符合源代码写书规范）。

四、函数说明模板

数据库名			表空间名
函数名称		函数编号		函数版本号
开发者		完成日期		审核人

1.功能描述

详细描述此函数的用途。

2.输入输出说明

说明此函数的输入要求及最终输出结果。

3.算法说明

说明此函数的关键算法及处理流程。

4.其它说明

说明此函数需要说明的其它内容．比如引用了哪些表、调用了哪些函数或过程、内部参数或变量说明等。

5.脚本

此函数的实现代码（需符合源代码写书规范）。

五、触发器说明模板

数据库名			表空间名
触发器名称		触发器编号		触发器版本号
开发者		完成日期		审核人

1.功能描述

详细描述此触发器的用途。 

2.算法说明

详细说明此触发器中的关键算法。

3.其它说明

说明此触发器需要说明的其它内容。

4.脚本

此触发器的实现代码（需符合源代码写书规范）。

六、索引说明模板

数据库名			表空间名
索引名称	数据集名称	包含数据项		索引类型	创建者

七、规则说明模板

数据库名		表空间名
规则名称	规则内容	数据集名称	关联数据项	创建者

C.3　组件设计说明书模板

组件设计说明书

组件名称：

组件编号：

编写：                          年  月  日

校对：                          年  月  日

审核：                          年  月  日

批准：                          年  月  日

1.概述

简要描述本组件的目的、意义和特点。

2.文档修订记录

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

3.功能描述

详细描述此组件要完成的功能

4.接口设计说明

4.1 类图

用类图描述组件所涉及的类、接口之间的关系

4.2 接口说明

详细描述该组件的方法、事件及参数说明。 可用接口文件代码。（方法及函数的命名参见编码规范）

    XML格式参数用附件。

5.处理过程说明

详细说明组件内部的处理过程及与其它组件或系统的交互（可用活动图描述）、采用的算法、出错处理。

6.界面设计说明

有界面的组件必须进行界面设计，详细说明主界面、子界面，以及相互之间的关系。

7.条件说明

说明本组件运行中受到的条件或特殊要求。 

8.参考文档

说明本组件所参考的文档资料或引用的标准。

C.4　测试设计说明书模板

测试设计说明书

项目名称： 

委托单位： 

承担单位：  

编写：                    年  月  日

校对：                    年  月  日

审核：                    年  月  日

批准：                    年  月  日

1引言

1.1 编写目的

说明编写这份《测试设计说明书》的目的，指出预期的读者。

1.2 背景

说明待测试软件系统的名称、版本号说明、列出本项目的任务提出者、开发者和用户。对项目目标和目的进行简要说明。

1.3 术语和缩写词

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4 参考资料

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。 

1.5 修订审批记录

说明编写这份《测试设计说明书》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
审批方式	审批日期	版本	审批意见	提交者	审批者

2 测试计划

2.1 测试范围

描述测试的各个阶段，例如单元测试、集成测试、系统测试、用户测试等，并说明本计划所针对的测试类型，例如功能测试、性能测试、界面测试、接口测试、压力测试、兼容性测试、安全性与访问控制测试、安装与卸载测试等。

2.2测试进度

说明各阶段测试活动的开始时间、结束时间、资源情况等。如果测试活动是里程碑事件在表3“是否里程碑”一栏中填写“√”，不是无需填写。

表3  测试进度计划表

测试活动	开始时间	结束时间	资源	是否里程碑
制定测试计划
制定测试方案
单元测试
用户手册编写
集成测试
系统测试
用户测试
测试设计说明书编写

2.3测试资源

2.3.1人力资源

角色	参与人员	职责

2.3.2测试环境

（1）软件环境

终端类别	操作系统	相关应用软件

（2）硬件环境

终端类别	机器名	设备编号	配置说明

（3）网络环境

网络类型	带宽	设备	数量

2.3.3测试工具

说明：列出项目测试所使用的工具。 

用途	工具	生产厂商/自产	版本

2.4风险和约束

说明：列出测试过程中可能存在的一些风险和制约因素，并给出规避方案。

2.5质量目标

说明：可以是产品的质量达到什么样的目标。

编号	测试质量目标	确认人以及特殊说明
1	测试已实现的产品是否达到设计的要求，包括：各个功能点是否已实现，业务流程是否正确
2	所有的测试用例已经执行过
3	所有的自动测试脚本已经执行通过
4	不允许存缺陷严重程度为A类、B类和C类的功能缺陷

测试缺陷严重程度分为A类、B类、C类、D类、E类五类。

A类-致命错误：指不能执行正常工作，是系统崩溃或资源严重不足。

B类-严重错误：指严重地影响系统要求或基本功能的实现，且没有办法更新（重启安装或重新启动不属于更正办法）。

C类-一般性错误：指严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重启安装或重新启动不属于更正办法）。

D类-轻微错误：指使操作者不方便或遇到麻烦，但它不影响执行工作或功能实现。

E类-测试建议（非缺陷）。

3测试方案

3.1测试数据

说明被测对象的数据库类型，以及测试所需要的数据来源。

3.2测试类型

说明：选择本项目是否采用该测试类型，如果表格中没有对应的测试类型自己增加。

表4 测试类型方案表

测试类型	测试阶段
	单元测试	集成测试	系统测试	用户测试
功能测试			X
用户界面测试	X	(X)
接口测试	X		(X)	(X)
性能测试	(X)		(X)
安全性测试	X	X		(X)
压力测试	X	X
兼容性测试	X	X
安装与卸载测试	X	X	(X)
回归测试	当被测试的软件或其环境改变时，在合适的测试阶段进行回归测试

 ：必选；X：不选；(X)：可选； 测试类型可根据实际软件开发条件增删。

3.3测试技术

说明：选择本项目是否采用该测试技术，在表格是否采用如果采用填写“√”，不采用无需填写，如果表格中没有对应的测试技术自己增加。

编号	测试技术	说明	是否采用
1	测试用例设计	在产品需求评审通过后编写测试用例
2	白盒测试	单元测试是否开展代码测试
3	自动化测试	压力测试时是否要引入自动化测试
4	性能测试	是否是使用工具进行性能方面的测试

3.4测试策略

说明各种测试类型所采用的方法、工具等。

测试优先级说明：

H - 必须测试 。

M - 应该测试，只有在测试完所有 H 项后才进行测试。

L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测测试。

3.4.1功能测试

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.2性能测试

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.3用户界面测试（可根据测试策略裁减）

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.4接口测试（可根据测试策略裁减）

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.5压力测试（可根据测试策略裁减）

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.6兼容性测试（可根据测试策略裁减）

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.7 安全性与访问控制测试（可根据测试策略裁减）

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

3.4.8回归测试（可根据测试策略裁减）

测试范围
测试目标
技术
工具与方法
开始标准
完成标准
测试重点
测试优先级
需考虑的特殊事项

4 测试用例设计

单元测试及集成测试用例根据各自软件开发情况，可不在测试设计中设计测试用例。待需求及设计确定，开发之时设计各自的测试用例，测试用例设计完后补充到《测试设计说明书》测试用例章节中。

系统测试及用户测试用例设计通过测试用例进行描述。

测试用例格式参见附录6。

为便于测试用例的查询，编制测试用例目次表见附录5。每个测试用例可以通过“页码”在系统测试文档中迅速找到。

表5 测试用例目次表

测试阶段	用例编号	需求编号	需求/功能	用例类型	页码

测试阶段：DY-单元测试、JC-集成测试、XT-系统测试、YH-用户测试等。

用例编号：命名规则是项目编码_测试类型_序号。 

测试类型：GN-功能测试、XN-性能测试、JM-界面测试、JK-接口测试、YL-压力测试、JRX-兼容性测试、AF-安全性与访问控制测试、AZXZ安装与卸载测试等。

需求编号：《软件需求说明书》中对应的章节编号。

用例类型：基本事件、备选事件、异常事件等。

表6 测试用例

项目名称：                                 版本：                                测试批次：                     

测试阶段			用例编号		需求编号			执行类型
测试类型			用例类型		用例设计者			设计日期
测试环境		系统：                                               客户端：                                                 自动脚本路径：
用例摘要
前置条件
序号	执行步骤					预期输出			实际结果
1
2
3
4
5

注：

测试阶段：DY-单元测试、JC-集成测试、XT-系统测试、YH-用户测试等。

用例编号：命名规则是项目编码_测试类型_序号。 

需求编号：《软件需求说明书》中对应的章节编号。

测试类型：GN-功能测试、XN-性能测试、JM-界面测试、JK-接口测试、YL-压力测试、JRX-兼容性测试、AF-安全性与访问控制测试、AZXZ安装与卸载测试等。

用例类型：基本事件、备选事件、异常事件等。

执行类型：手动测试、自动测试。

自动脚本路径：自动执行脚本文件的路径，包含文件名。

C.5　软件开发项目系统设计评审表模板

C

表C.1 软件开发项目系统设计评审表

项目名称：                                                                                                            填表日期 

序号	角  色	姓  名	工作单位	职称/职务	个人意见		本人签名
评审组长审核意见： 签名：				主管领导审核意见： 签名：		用户总监审核意见： 签名：

附　录　D

（规范性附录）

源程序说明书模板

源程序说明书

项目名称： 

委托单位： 

承担单位： 

编写：                    年  月  日

校对：                    年  月  日

审核:                     年  月  日

批准:                     年  月  日

需求编号			功能模块编号				模块版本号
设计人		开发人				完成日期		审核人

1 功能描述

详细描述此模块要完成的功能。

2 输入/输出说明

说明此模块的输入要求及模块的最终输出结果。

3 类说明

描述该模块中的所有类（要求画出类关系图，分别详细说明每个类的属性、方法及关键算法）。

4 类对象交互关系说明

要求至少用时序图和活动图来详细说明各对象之间的交互关系。

5 程序文件说明

说明每个物理文件的存放路径、作用以及所包含的类等(用表格形式进行描述)。

附　录　E

（资料性附录）

源代码书写规范

1高级语言

1.1适用范围

主要针对C#、VC++和JAVA高级编程语言，其它高级语言可参照执行。

1.2程序风格

1.2.1代码缩进

程序块（包括函数、过程、结构的定义及循环、判断等语句）要严格采用缩进风格编写，对齐只使用空格键，不使用TAB键，所有的缩进为4个空格。

1.2.2变量申明

在函数内部申明变量时，必须在函数的开始位置。

1.2.3代码块长度

单个函数的程序行数不得超过200行。一个程序文件的长度不得超过5000行代码。

1.2.4代码换行

jjjj)较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。

kkkk)不允许把多个短语句写在一行中，即一行只允许写一条语句（如if 、for 、do 、while、case 、switch等语句自占一行）。

llll)程序块的分界符（如C/C++语言的大括号'{'和'}'）必须各自独占一行并且位于同一列，同时与引用它们的语句左对齐。

1.2.5空行及空格

mmmm)通过摘要注释分隔的两个代码块之间、局部变量和它后边的语句之间、函数之间留一个空行。

nnnn)在所有关键字和逗号之后要留一个空格，方法名之后不要留空格，紧跟左括号“（”，以与关键字区别。

oooo)如果“;”不是一行的结束符号，其后要留空格，如for (initialization; condition; update)。

pppp)赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”，“^”等二元操作符的前后要加空格。

qqqq)一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格。诸如“［］”、“.”、“->”这类操作符前后不加空格。

1.3命名

1.3.1变量命名

rrrr)变量的名字须使用“名词”或者“形容词＋名词”。 变量的命名要求符合匈牙利命名法则，即开头字母用变量的类型（第一个字母小写），其余部分用变量的英文意思或其英文意思的缩写（尽量避免用中文的拼音），中间单词的第一个字母要大写。即： 变量名=变量类型+变量的英文意思（或缩写）。

ssss)变量名称须准确、完整地描述变量的含义。循环计数变量的名称须有含义。如果循环语句的长度超过了两行或者存在着嵌套循环，避免使用i、j或k之类的变量，须使用有意义的变量，有利于程序的理解。（单字符的变量名一般只用于生命期非常短暂的变量）。

tttt)对于所有布尔型变量的命名，能够直接从名称上看出为真的条件。枚举类型的变量名称须包含基础类型，以方便分辨变量的类型。例如，用Color变量表示ColorRed和ColorGreen枚举类型的值。

uuuu)在所有全局变量前首字母必须使用‘v’， 接口指针必须使用“pi”，后跟接口名称缩写。在申明变量时要避免局部变量与公共变量同名、块内部变量与它外部变量同名。

1.3.2常量命名

常量的命名须代表抽象的实体，而非它们所代表的值，即对于涉及物理状态或者含有物理意义的常量，不允许直接使用不易理解的数字，必须用有意义的枚举或宏来代替。所有常量名均全部大写，由英文或其缩写，单词间以‘_’隔开，如int MAX_NUM。

1.3.3函数或方法命名

函数或方法的命名应该尽量用英文表达出函数或方法完成的功能。遵循动宾结构的命名法则，函数或方法名中动词在前，类的成员函数或方法须只使用“动词”， 第一个字母是小写，但是中间单词的第一个字母是大写。如果是返回一个成员变量的值，名称一般为get+成员变量名，如若返回的值是bool变量，一般以is作为前缀。如果是修改一个成员变量的值，名称一般为：set + 成员变量名。函数或方法名的长度不得少于8个字母。

1.3.4文件命名

文件的名字应该使用名词。每个单词第一个字母须大写。文件的命名应该尽量用英文表达出文件的内容。避免使用单词的缩写，除非它的缩写已经广为人知，如HTTP。文件的名字中应能反映出文件的类型（针对不同的编程语言，有不同类型的文件。如：VC++中有Application、Document、Main frame、View、Dialog Box等文件类型，则对应的文件名字就如TestApp、TestDoc、TestMainFrame、TestView、TestDlg）。要求文件名的长度不得少于5个字母。对于文件中类的命名，前缀用大写字母C，后跟类的功能，中间单词第一个字母要大写。

1.4注释

1.4.1代码注释

注释将增加代码的清晰度。注释需简洁、明了，含义准确，防止注释二义性，避免在注释中使用缩写，特别是非常用缩写。注释不允许包括其他的特殊字符。可以先写注释，后写代码，但对代码的注释不可放在代码下面，须放在代码上方或右方相邻位置。

1.4.2变量注释

vvvv)对于变量的注释必须紧跟在变量的后面说明变量的作用。对于所有有物理含义的变量、常量、数据结构声明(包括数组、结构、类、枚举等)，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。原则上对于每个变量都应该注释，但对于意义非常明显的变量，可以不注释。

wwww)对于全局变量必须有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等进行说明。

1.4.3函数注释

xxxx)对于函数，须在函数头部从函数的目的、功能、输入参数、输出参数、返回值、调用关系（函数、表）、“算法”、“日期”等方面进行注释。不允许在一行代码或表达式的中间插入注释。在定义函数原型时，须对每一个参数加以注释。

yyyy)对于函数体内的分支语句（条件分支、循环语句等）必须编写注释，对于前后顺序不能颠倒的情况，建议在注释中增加序号。对于从一个case子句进入后续的case子句，须用注释“ Fall through”明确标记。当代码段较长，特别是多重嵌套时，这样做可以使代码更清晰，更便于阅读。

zzzzz)如果部分代码不再使用，但还要保存，须使用#if UNUSED标识。如果部分代码目前不能使用，但最后肯定要用，须使用#if LATER标识。使用“TODO: comment”标记未完成代码，“ BUG: comment”标记错误代码。

1.4.4文件注释

aaaaa)每个源文件有效注释量必须占代码量的20％以上。必须在每个源文件的头部进行注释，注释须包含：版权说明、版本号、生成日期、作者、主要函数及其功能的简要说明、与其它文件的关系、修改日志（说明对文件的修改内容、修改原因以及修改日期）。

bbbbb)修改代码的同时必须修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。

1.5错误和异常处理

1.5.1系统在正常状态下以及无重载和硬件失效状态下，不应产生任何异常。发生异常或错误时，对于应用服务层不允许抛出异常中断服务程序的运行，须由系统自行处理保持程序正常运行，必须采用日志机制来报告异常，包括异常发生的时刻，错误说明，可能的原因、严重程度，发生异常或错误的位置等。

1.5.2不允许使用异常实现来控制程序的正常流程，异常实现只用于异常和错误发生时如何使程序回到正常流程。在捕获语句的抛出异常子句中，必须抛出原始异常，用以维护原始错误的堆栈分配。

1.6注意事项

1.6.1变量的使用

ccccc)公共变量是增大模块间耦合的重要原因之一，在开发过程中能不用公共变量尽量不要使用。

ddddd)临时或局部变量，使用时必须首先初始化，严禁使用未经初始化的变量作为右值。初始化类的实例时，除非十分必要，否则不要赋null值，在创建新对象时必须检查返回值，或者采用标准方法处理内存管理错误。

eeeee)尽量不要提供public 和 protected的成员变量，应使用属性来代替。

1.6.2代码实现

fffff)不要在程序中使用运算符的默认优先级，应使用括号明确表达式的操作顺序。

ggggg)对于要返回指针但可能出错的函数，应返回一个BOOL值和指向参数的指针。

hhhhh)每个接口不应该只有一个成员，最多也不应超过20个，尽量使每个接口中包含3－5个成员，并且接口成员中不要包含事件。

iiiii)如果只有成员函数或操作符，应该使用类，而不用结构。

jjjjj)定义类成员时，应明确定义其属性public、protected或private，并按照此顺序分组定义。在类中不要说明全局数据成员，可以使用内嵌访问函数，以提高性能。

kkkkk)不要使用虚函数，如多态，除非必须使用，因为虚函数的开销较大，如果使用多态，其基类的构造函数必须是虚函数。为了清楚其间，重载虚方法时，应明确说明为virtual。

lllll)在实现构造函数时，最好不要实现复杂费时的功能，但要确保初始化所有数据成员。同时要保证构造函数、析构函数不能失败，应在一个方法中实现内存分配，或潜在的错误处理。如果部分资源在析构函数执行之前释放，要确保全部域复位，如释放对象并将指针置为NULL，以避免多次释放出现异常。

mmmmm)每个类最好存放在单独的文件中，并且一个文件只能有一个命名空间，避免将多个命名空间放在同一个文件里面，每个命名空间对应一个目录。

2结构化查询语言

2.1程序风格

2.1.1SQL语句

nnnnn)语句中出现的所有表名、字段名全部小写，系统保留字、内置函数名、Sql保留字大写；

ooooo)在所有关键字之后要留一个空格，连接符OR、IN、AND、以及＝、<=、>=等前后要各加一个空格；

ppppp)一行有多列，超过80个字符时，要基于列对齐原则，采用下行缩进；

qqqqq)书写where子句时，每个条件要占一行，语句另起一行时，以保留字或者连接符开始，连接符右对齐。

2.1.2存贮过程

rrrrr)在存贮过程内部申明变量时，必须在存贮过程的开始位置；

sssss)通过摘要注释分隔的两个语句块之间、局部变量和它后边的语句之间留一个空行。

2.2命名

2.2.1存贮过程命名

用户存贮过程要按照：USP _ + 系统模块缩写+ 功能标识 +表名（不带前缀）或功能的英文单词或英文单词缩写的方式命名。 

2.2.2变量命名

存贮过程中变量名全部采用小写，局部变量名使用“v_”开头，输入参数以“i_开头，输出参数以“o_”开头，输入输出参数用io_开头。所有输入参数必须显示声明。当变量代表列时，应使用%TYPE属性对变量命名。

2.2.3游标命名

游标应统一用后缀 “_cur” 命名。

2.2.4常量命名

常量应统一用 cn_ 的前缀命名。

2.3注释

2.3.1代码注释

注释将增加代码的清晰度。注释需简洁、明了，含义准确，防止注释二义性，避免在注释中使用缩写，特别是非常用缩写。注释不允许包括其他的特殊字符。注释要单独成行，放在语句前面，可采用单行或多行注释。

2.3.2存贮过程注释

ttttt)每个存贮过程有效注释量必须占代码量的20％以上。必须在每个存贮过程的头部进行注释，注释须包含：功能描述、作者、生成日期、返回值、与其它存贮过程的关系（调用了哪些存贮过程和被哪些存贮过程调用），主要算法的简要说明、修改日志（注明修改内容、修改原因以及修改日期）。

uuuuu)修改代码的同时必须修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。

vvvvv)每条SQL语句和分支条件表达式原则上都应该注释，但对于意义非常明显的，可以不注释。

2.3.3常量及变量注释

对于常量及变量必须说明被保存值的含义及合法取值的范围。原则上对于每个常量及变量都应该注释，但对于意义非常明显的常量及变量，可以不注释。

2.4错误和和异常处理

2.4.1凡是涉及到表操作(insert,update,select,delete)的sql语句,都必须进行错误捕捉,不能将错误带到后面的语句。

2.4.2从表中取数的语句,应严格区分NO_DATA_FOUND（无数据返回，用户级错误）和 TOO_MANY_ROWS（数据异常导致，系统级错误）的错误,并将相应错误信息填入错误信息。

2.4.3所有存储过程(函数)在入口处统一先将返回错误代码(errCode)设置为42, 出口一律在存储过程的结束部分,不允许中间返回，功能处理成功结束后再将错误代码(errCode)设置为0(成功),避免程序过程中因错误未能正确捕获,导致功能未能完成,而程序却成功返回的情况出现，所有存储过程（函数）结束前应统一捕获系统异常，所有捕获异常处都要定义WHEN OTHER 子程序，以便捕获所有没有显示处理或其他类型的异常。

2.5注意事项

2.5.1查询的Where过滤原则，应使过滤记录数最多的条件放在最前面。

2.5.2 SELECT子句中应避免使用 ‘SELECT *’。

2.5.3多使用DECODE函数来避免重复扫描相同记录或重复连接相同的表。

2.5.4尽量多使用COMMIT，以提高系统性能。

2.5.5当SQL语句中要连接多个表时, 应使用表的别名并把别名前缀于每个列上以减少解析时间并2.5.6减少那些由列歧义引起的语法错误。

2.5.7尽量用EXISTS替代IN、用NOT EXISTS替代NOT IN以提高查询效率。

2.5.8避免在SELECT子句中使用DISTINCT. 一般可以考虑用EXISTS替换, EXISTS使查询更为迅速，如可能最好是用多表连接代替EXISTS子句。

2.5.9WHERE条件中尽量减少使用常量比较，改用主机变量。

附　录　F

（规范性附录）

软件开发过程测试阶段文档模板汇总

F.1　缺陷记录和跟踪表模版

D

E

F

表F.1　缺陷记录和跟踪表

序号

需求 编号

测试     用例编号

缺陷 描述

发现 阶段

缺陷 类型

修复   优先级

缺陷   严重程度

测试 日期

修改人

修改 日期

原因分析描述

缺陷 起源

缺陷 来源

状态

验证人

验证 日期

测试次数

填表说明： 1、需求编号：《软件需求说明书》中对应的章节编号。 2、测试用例编号：命名规则是项目编码_测试类型_序号。 3、发现阶段：XQ-需求、SJ-设计、DYCS-单元测试、JCCS-集成测试、XTCS-系统测试、YHCS-用户测试等。 4、缺陷类型：功能(F)、赋值(A)、接口(I)、容错(C)、打包(B)、文档(D)、算法/语法(G)、界面(U)、性能(P)、标准(N)、环境(E)、建议(S)。 5、修复优先级：5-Urgent、4-Very High、3-High、2-Medium、1-Low。 6、缺陷严重程度： A-致命错误、B-严重错误、C-一般性错误、D-较小错误、E-测试建议。 7、缺陷起源、缺陷来源：需求、架构、设计、编码、测试。 8、状态：New、Open、Reopen、Fixed、rejected、Closed。 9、“测试日期”栏之前的内容由测试人员完成。 10、修改人填写和“修改人”、“修改日期”、“原因分析描述”、“缺陷起源”、“缺陷来源”、“状态”。 11、由测试人、修改人和验证人按状态设置“缺陷状态”；“测试次数”一栏是回归测试的人员填写。

F.2　用户手册模板

用 户 手 册

项目名称： 

委托单位： 

承担单位：  

编写：                          年  月  日

校对：                          年  月  日

审核：                          年  月  日

批准：                          年  月  日

《用户手册》的编制是要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。《用户手册》编制指导如下。

1 引言

1.1 编写目的

说明编写这份《用户手册》的目的，指出预期的读者。

1.2 背景

说明待使用的软件系统名称、版本号说明、用户特点以及该软件系统同其他系统的关系。

1.3 修订审批记录

说明编写这份《用户手册》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
提交者	审批方式	审批日期	版本	审批意见	审批者

1.4 术语和缩写词

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.5 参考资料

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。

1.6  系统概述

介绍系统的基本情况、版本号说明、运行环境、系统特点、功能结构、数据的组织与结构及使用本系统应特别注意的事项等。

1.6.1 系统特点

列出系统存在的系统特点，主要是从系统方面来描述。

1.6.3 运行环境

列出客户端、服务端和数据库服务器环境的最低要求。

1.6.4 特别申明

列出系统注意事项。

2 系统管理员使用功能

2.1 安装

详细介绍本系统环境搭建和安装。

2.2 设置

详细介绍数据库连接及系统服务配置。

2.3 权限管理

介绍系统权限管理、用户管理、数据字典管理等操作。

3 普通用户使用功能

3.1 系统设置与登陆

介绍本系统的客户端系统设置和登陆要求。

3.1 功能1

详细介绍系统中各业务处理模块的使用步骤，并以实例的形式展开说明。

（1）功能说明及用途；

（2）说明中要有功能的详细操作步骤，在操作步骤中要有系统的操作界面；

（3）对使用过程中可能出现问题的地方，要有明确说明。

3.2 功能2

用类似本文3.1节的方式给出第2项功能描述。

．．．．．．。

3.n 功能n

．．．．．．。

4 FAQ （Frequently Asked Questions 问答集）

列出系统常见的问题与解答。

列出油田公司FAQ网站的发布地址，并提醒用户系统出现问题后，到FAQ网站查询问题解决方法。

F.3　项目测试总结报告模板

项目测试总结报告

项目名称： 

委托单位： 

承担单位： 

编写：                     年  月  日

校对：                     年  月  日

审核：                     年  月  日

批准：                     年  月  日

《项目测试总结报告》的编制，是为了把集成测试、系统测试和用户测试的结果、发现及分析写成文件加以记载。《项目测试总结报告》编制指导如下。

1 引言

1.1 编写目的

说明编写这份《项目测试总结报告》的目的，指出预期的读者。

1.2 背景

说明待测试软件系统的名称、版本号说明、列出本项目的任务提出者、开发者和用户。

1.3修订审批记录

说明编写这份《项目测试总结报告》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
审批方式	审批日期	版本	审批意见	提交者	审批者

1.4 术语和缩写词

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.5 参考资料

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。

2测试概要

概括性地描述测试规模、测试过程和测试结果等信息。

测试概要介绍，包括测试的一些申明、测试范围、测试目的等等，主要是测试情况介绍。

2.1测试组织

列出改项目在各测试阶段的参与测试的角色、姓名和具体职责 

表3 项目测试人员

角色	姓名	具体职责
测试项目负责人
主要测试人员
参与测试人员

2.2测试环境

列出执行该测试时所搭建的软、硬件环境、网络环境配置等，对于三层架构的网络设备和要求可以根据网络拓扑图列出相关配置。

测试名称/类型	配置
数据库服务器配置
CPU：
内存：
硬盘： 可用空间大小，可用转数等
操作系统：
应用软件：
机器网络名：
局域网地址：
应用服务器配置
客户端配置

2.3 测试进度

依据《测试设计说明书》中测试进度表列出实际测试活动的测试时间跨度和完成测试工作量情况。

表4 测试进度

测试活动	实际开始时间	实际结束时间	执行用例数	人力资源（人日）

 2.3 测试类型

列出实际测试类型，对于《测试设计说明书》中制定的各测试阶段测试类型未执行的，请说明原因。

表5 测试类型

测试类型	测试阶段
	单元测试	集成测试	系统测试	用户测试
功能测试
用户界面测试
接口测试
性能测试
安全性测试
压力测试
兼容性测试
安装与卸载测试
回归测试	当被测试的软件或其环境改变时，在合适的测试阶段进行回归测试

 ：选择；X：未选； 测试类型及所进行的测试根据实际填写。

3测试结果及缺陷分析

3.1测试用例执行结果

表6 测试用例执行结果表

用例编号	需求编号	需求/功能	用例状态	测试结果	备注

说明：在项目验收时，测试状态不能为new（新的）、open（已打开）、reopen（重新打开）。

对于fixed（已修改），需确认后，改为Close（已关闭）状态。

对于rejected（被拒绝）的、postpone（暂缓解决）的测试用例需在备注栏加以说明理由。

3.2覆盖分析

3.2.1需求覆盖

需求覆盖率指经过测试的需求/功能和软件需求说明书中所有需求/功能的比值，要求100％通过。

表7 功能测试结果记录表

需求编号	需求/功能	测试类型	是否通过 [Y][P][N][N/Y]	测试人	备注

根据测试结果，按编号给出每一测试需求的通过与否结论。Y表示通过，N表示未通过，P表示部分通过，N/A表示不可测试或者用例不适用。

需求覆盖率=被测试需求功能数/需求总数 ×100％ 

3.2.2 测试覆盖

描述测试用例的个数、测试覆盖率、执行通过率，以及因未测试的原因分析。

表8 测试用例记录表

需求编号	需求/功能	用例个数	执行总数	未执行	未执行测试分析和原因
总计

测试覆盖率=执行总数/用例总数 ×100％ 

3.3缺陷汇总

表9 缺陷统计表

缺陷严重程度	A（致命）	B（严重）	C（一般）	D(轻微)	E（建议）	缺陷总数
修复的缺陷数
残留的缺陷数
缺陷总计
所占百分比

3.4缺陷分析

本部分对上述缺陷和其他收集数据进行综合分析。

3.5残留缺陷与未解决问题

表10 残留缺陷统计表

序号	缺陷编号	缺陷严重程度	原因分析	预防和改进措施	预期影响

4综合评价

4.1 软件能力与缺陷

指出经过测试的软件所实现的功能或创新点功能。

简述本项目在功能测试、性能测试、界面测试、接口测试、压力测试、兼容性测试、安全性与访问控制测试、安装与卸载测试等方面的测试结果。

指出测试所揭露的软件缺陷和不足或可能给软件运行带来的影响。

4.2建议

指出可能存在的潜在缺陷和后续工作，提出对缺陷修改及项目改进方面的建议。

4.3 客户问题和建议

列出客户提出的问题或建议，以及解决方案等，必要时对这些问题进行分析。

 

F.4　测试结果确认表模板

表F.2　测试结果确认表

项目名称：                                                      填表日期

1.易学性	□优 □好 □中等 □差
2.易操作性	□优 □好 □中等 □差
3.流程操作清晰性	□优 □好 □中等 □差
4.界面布局合理性	□优 □好 □中等 □差
5.系统界面友好性	□优 □好 □中等 □差
6.业务需求满意度	□优 □好 □中等 □差
7.系统安全性	□优 □好 □中等 □差
8.系统响应效率	□优 □好 □中等 □差
9.系统稳定性	□优 □好 □中等 □差
10.系统运行准确性	□优 □好 □中等 □差
用户总监意见：                                                 签名： 年     月     日

 注：优-10分，好-8分，中等-5分，差-2分，满分为100分。

附　录　G

（规范性附录）

项目开发总结报告模板

项目开发总结报告

项目名称： 

委托单位： 

承担单位：  

编写：                      年  月  日

校对:                       年  月  日

审核：                      年  月  日

批准：                      年  月  日

编制《项目开发总结报告》，是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。《项目开发总结报告》的编制指导如下。

1 引言

1.1 编写目的

说明编写这份《项目开发总结报告》的目的，指出预期的读者。

1.2 背景

说明待开发的软件系统的名称、版本号说明、本项目的任务提出者、开发者、用户以及该软件系统同其他系统的关系。

1.3 修订审批记录

说明编写这份《项目开发总结报告》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。

表1 文档修订记录表

修订记录
章节	修订日期	版本	修订描述	修订者	审核者

表2 文档审批记录表

审批记录
审批方式	审批日期	版本	审批意见	提交者	审批者

1.4 术语和缩写词

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.5 参考资料

列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。

2  项目进度

2.1 计划安排

列出原定计划进度安排。

2.2 实际进度

列出实际进度并与原定计划进度对比，明确说明，实际进度是提前了、还是延迟了。若延迟了，分析其主要原因。

3 主要研究内容

对照《软件需求说明书》，列出项目实施的目标、主要研究内容，接续的项目需要描述前期工作情况。

4 完成情况

4.1  系统描述

 4.1.1  组织结构图

要有简要文字说明

 4.1.2  业务流程图

 4.1.3  数据流程图

 4.1.4  功能结构图

 4.1.5  系统部署图

4.2  功能完成情况

对照《软件需求说明书》的有关内容，列出系统完成的主要功能，并进行简要的描述。

序号	完成的主要功能	功能简述	是否达到开发目标	未达到开发目标原因分析	备注

4.3  建设历程

4.3.1 工作历程

   简述项目建设的阶段和历程。

4.3.2 项目大事记

   列出本项目中的里程碑事件。

4.4  变更情况

项目如有计划、内容、重要干系人等变更的需要说明其变更时间、理由、结果，并列出变更申请的批复文件。

4.5  遗留问题 

列出在项目开发计划的要求范围内，但尚未解决的问题。

5  主要成果

5.1  技术成果

分项描述项目所取得的主要技术性成果。

5.2  关键技术

列出本项目中所采用的关键性技术或前沿技术。

5.3  技术创新点

凝练出项目研究取得的技术创新点，包括新认识、新发现、新方法，并进行简要的说明。

6  应用情况

6.1  投产情况

简述系统投产审批、投产日期、系统部署架构等情况。

6.2  培训情况

简述项目实施过程中按合同要求的技术培训情况。

6.3  试运行情况

列举系统投产后的用户分布、访问数量、系统日志等。

7 评价分析

7.1 工作评价

给出对在开发中所使用的技术、方法、工具、手段以及其它的评价。

7.2 效益分析

阐述经济效益和社会效益分析。

8 经验与教训

8.1 经验教训

给出在项目管理方面及项目技术方面的经验和教训。 

8.2 工作建议 

根据本项目的经验和教训，对于今后项目开发工作提出改进的建议。

附　录　H

（规范性附录）

项目评估报告模板

项目评估报告

项目名称			项目承担单位
项目启止时间			项目负责单位
评估人			评估时间		年  月  日
总体评价		总分：
		评价：
一、项目管理控制(35分)
关键点	评估标准		数据来源	备注		评分
1、项目计划更新情况(10分)	1、评估项目计划更新情况，每迟到或少报扣减1分，最低0分。		1、项目管理系统。	无。
2、周、月报提交情况。(10分)	1、评估项目周、月报提交情况，每迟到或少报扣减1分，最低0分。		1、项目管理系统。	无。
3、计划偏离程度。(10分)	1、计算各月计划偏离度之和，每10%扣减1分，最低0分。		1、项目管理系统。	评估计划的偏离程度，并评分。
4、关键会议记录。(5分)	1、除评审会外，每记录一次关键事件得1分，最高5分。		1、项目管理系统。	无。
	2、若没有记录，按0分计
二、文档质量控制(40分)
关键点	评估标准		数据来源	备注		评分
1、招投标文件及合同(5分)	符合文件标准，能清晰描述项目范围及要求（5分）；基本符合文件标准，能描述项目范围及要求（4～3分）；文档质量差，不能对项目提供指导（2～0分）		1、招标文件	1、审核招投标文件及合同并评分。
			2、投标文件
			3、合同
2、计划文档审核(5分)	符合标准，资源配置合理，工作任务划分合理，里程碑明确（5分）；基本符合标准，资源、任务划分较为合理，里程碑清晰（4～3分）；计划质量差，不能对项目提供指导（2～0分）		1、项目计划。 2、软件开发项目计划要点表。	1、对项目计划的内容（人员、任务分解、里程碑）进行审核，并评分。
3、需求文档审核(10分)	符合标准模版要求，业务需求、功能需求描述清晰（10～8分）；基本符合标准模版要求，业务需求、功能需求描述清楚（7～5分）；文档质量差，不能对项目提供指导（2～0分）		1、需求分析说明书。 2、需求评审会议签表。 3、需求评审会议纪要。	1、召开需求审核会，对需求的内容（业务需求、功能需求）进行审核，并评分。
4、设计文档审核(10分)	符合标准模版要求，系统架构设计先进，功能设计描述清晰（10～8分）；基本符合标准模版要求，系统架构设计合理，功能设计描述清楚（7～5分）；文档质量差，不能对项目提供指导（4～0分）		1、系统设计分析说明书。 2、设计评审会议签表。 3、设计评审会议纪要。	1、召开设计审核会，对设计的内容（软件架构、功能设计）进行审核，并评分。

5、测试文档审核(5分)	符合标准模版要求，系统测试覆盖完全，无遗留问题（5分）；基本符合标准模版要求，功能测试完全，基本无遗留问题（4～3分）；文档质量差，不能对项目提供指导（2～0分）		1、测试设计。 2、测试设计说明书 3、测试总结报告	1、根据项目测试文件的规范性和合理性，给定评分。
6、验收文档审核(5分)	符合标准模版要求，项目过程总结到位，验收汇报清楚明白（5分）；基本符合标准模版要求，项目过程总结清楚，验收汇报基本清晰（4～3分）；文档质量差，不能对项目提供指导（2～0分）		1、项目总结报告。 2、验收汇报PPT。 3、验收会议纪要。	1、召开验收会，对验收的内容进行审核，并评分。
三、成果质量控制(25分)
关键点	评估标准		数据来源	备注		评分
1、功能性(5分)	依据软件质量度量与测评（附录J）进行评分（优秀5分，良好4，合格3，差2～0）		1、测试总结报告	依据系统测试情况对软件系统评分
			2、项目总结报告
			3、其它相关文档
2、可靠性(5分)	依据软件质量度量与测评（附录J）进行评分（优秀5分，良好4，合格3，差2～0）		1、测试总结报告	依据系统测试情况对软件系统评分
			2、项目总结报告
			3、其它相关文档
3、易用性(5分)	依据软件质量度量与测评（附录J）进行评分（优秀5分，良好4，合格3，差2～0）		1、测试总结报告	依据系统测试情况对软件系统评分
			2、项目总结报告
			3、其它相关文档
4、效率(5分)	依据软件质量度量与测评（附录J）进行评分（优秀5分，良好4，合格3，差2～0）		1、测试总结报告	依据系统测试情况对软件系统评分
			2、项目总结报告
			3、其它相关文档
5、稳定性(5分)	依据软件质量度量与测评（附录J）进行评分（优秀5分，良好4，合格3，差2～0）		1、测试总结报告	依据系统测试情况对软件系统评分
			2、项目总结报告
			3、其它相关文档

G

H

附　录　I

（规范性附录）

质量管理文档模版汇总

I.1　软件开发项目工作周报模板

软件开发项目工作周报

                                          填表日期    

项目名称
下一里程碑
项目经理		工作日期	月  日 — 月  日
总进度    %	本周进度     %	进度状态：[ ]超前  []正常  []滞后

一、本周工作成果

列出本周完成的主要工作及里程碑任务。

二、本周工作进展

1．完成计划任务

列出本周完成的计划内的任务。

2．未完成计划任务

列出本周未完成的计划中的任务，并说明原因及预计完成时间。

3．完成计划外任务

列出完成的本周计划之外的任务。

三、下周工作安排

    列出下周主要的工作安排。

四、需要协调的问题

列出项目中需要进行协调的问题。

I.2　软件开发项目工作月报模板

软件开发项目工作月报

填表日期 

项目名称
项目经理		日期	年    月
上月进度    %	本月进度     %	到达里程碑：

一、本月工作成果

列出本月完成的主要工作及里程碑任务。

二、本月工作进展

1．完成计划任务

列出本月完成的计划内的任务。

2．未完成计划任务

列出本月未完成的计划中的任务，并说明原因及预计完成时间。

3．完成计划外任务

列出完成的本月计划之外的任务。

三、下月工作安排

    下个月主要的工作安排。

四、需要协调的问题

    列出项目中需要进行协调的问题。

I.3　会议纪要模板

正文：会议时间、地点，议题等

参会人员：单位、姓名

                               编写人：XXX   审核人：XXX

                                     年   月   日

附　录　J

（资料性附录）

软件质量度量与测评文档模板汇总

J.1　软件质量度量表模板

I

J

表J.1　软件质量度量表

度量项	定性描述
功能性	能否提供《软件需求说明书》所确认的明确或隐含的系统功能；能否得到正确或相符的结果或效果；能否同其他系统交互；能否防止非法访问。
可靠性	软件故障引起失效的频度；故障下维持性能的能力；重建及恢复的能力。
易用性	能否使用户快速学习和操作软件。
效率	响应和处理时间。
稳定性	能否进行长时间连续运行。

J.2　软件质量测量与评定等级表模板

表J.2　软件质量测量与评定等级表

  测量结果     

 

度量项	等级|分值
	优秀	良好	合格	差
	[85，100]	[75，85）	[60，75)	[0，60）
功能性	能够提供所确认的全部功能并得到正确的结果；与其他系统交互好；可防止非法访问。	能够提供所确认的全部功能并得到较正确的结果。	实际完成的功能少于所确认的功能，但能够提供所确认的大多数功能。	不能提供所确认的大多数功能。
可靠性	软件故障频度低；故障下维持、重建及恢复性能的能力高。	软件故障频度较低；有维持、重建及恢复的能力。	有软件故障引起失效的现象，但可通过重建得到恢复。	因软件故障引起严重失效，并不可恢复。
易用性	用户容易学习、便于操作软件，用户界面友好。	用户可通过学习操作软件。	用户需要通过较长时间的培训操作软件。	用户无法操作软件。
效率	能迅速响应和处理。	响应和处理时间较短。	响应和处理时间能满足基本要求。	响应时间慢、处理时间长。
稳定性	能长时间连续运行。	能较长时间连续运行。	能连续运行。	不能连续运行。

附　录　K

（规范性附录）

软件开发项目变更申请表模板

K

表K.1　软件开发项目变更申请表

项目名称							变更申请人
变更原因：
变动情况：
风险评估			(项目经理填写，篇幅不够可另附说明)： 项目经理签名：              年    月    日
会 签 审 批
角 色		姓  名		单  位	职务/职称	意 见		签  名
审核结果：同意        □ 拒绝          评审组长签字：                     年    月    日

附　录　L

（资料性附录）

软件文档分类表汇总

L.1　文档分类表

L

表L.1　文档分类表

	类型	读者
	项目开发计划	研发人员、管理人员
设	软件需求说明书	用户、研发人员、管理人员
计	系统设计说明书	研发人员、维护人员
开	数据库设计说明书	研发人员、维护人员
发	测试设计说明书	研发人员、维护人员
类	用户手册	用户
	测试总结报告	研发人员、维护人员
	项目开发总结报告	研发人员、维护人员、管理人员
	变更申请表	管理人员
	需求评审表	管理人员
" 管	系统设计评审表	管理人员
	测试结果确认表	管理人员
理	项目工作周报	管理人员
类	项目工作月报	管理人员
	会议纪要	管理人员

L.2　文档阶段分布表

表L.2　文档阶段分布表

文件       阶段	项目    启动阶段	需求分析 阶段	设计 阶段	编码 阶段	测试 阶段	上线 阶段
项目开发计划	√
软件需求说明书		√
系统设计说明书		√	√
数据库设计说明书		√	√
测试设计说明书		√	√	√
用户手册			√	√
项目测试总结报告					√
项目开发总结报告					√
变更申请表	√	√	√	√	√	√
需求评审表		√
系统设计评审表			√
测试结果确认表					√
项目工作月报	√	√	√	√	√	√
项目工作周报	√	√	√	√	√	√
会议纪要	√	√	√	√	√	√

_________________________________