软件开发质量保证体系

1. 使用范围

2. 引用标准

3. 定义

4. 质量体系框架

4.1 管理职责

4.2 质量体系

4.3 评审

4.4 纠正措施

5. 质量体系生存周期

5.1 合同评审

5.2 需方需求规格说明

5.3 开发计划

5.4 质量计划

5.5 设计和实现

5.6 测试和确认

5.7 验收

5.8 复制、交付和安装

5.9 维护

公司内部标准

本标准参照ISO9000-3 《质量管理和质量保证标准 第三部分：在软件开发、供应和维护中的使用指南》。

1、 使用范围

本标准作为本公司在软件项目开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。

以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。

2、 引用标准

本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。

使用本文档时，请尽量参照最新版本。

3、 定义

产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。

开发：创作软件产品的所有活动。

供方：指本公司。

需方：指具体项目的需求方，即客户。

质量体系：质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。

4、 质量体系框架

4.1管理职责

4.1.1 供方(及具体的项目开发组)负责以下职责

组织机构

本公司内部专门设立部门质量保证部门，由部门负责人及专门经过培训的人员组成。具体项目开发组，设立质量保证组，或委托公司质量保证部门协助开展工作。

质量保证部门负责以下工作：

建立并维护公司内部的质量保证体系。

对可能导致产品不合格的问题予以识别，采取措施予以避免。 发现并记录产品的质量问题。

提出、采取或推荐问题解决办法。

验证解决办法的实施效果。

对不合格产品的处理、交付过程进行控制，确保最终问题得以纠正。 质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。

制定质量方针和质量目标

确保项目组成员均理解质量方针并能坚持贯彻执行。

公司内部制定一般性的质量方针及对软件产品的质量目标，作为各项目组的参照，各项目组可根据具体客户期望及需求作出具体质量目标及质量承诺，具体质量目标及承诺，特别是超出公司目标的部分，提交给质量保证部门，以便提交给质量保证部门充分理解并协助实施。

《质量方针和质量目标》见附录

管理评审

质量保证部门负责人应每月对质量体系进行评审，主要是对内部质量审核结果的评定，以保证质量体系持续有效，保存评审记录。

4.1.2 需方（客户）应负的职责

在项目中，应向需方（客户）提出具体要求，明确其需要承担的职责，以便相互配合，共同保证项目的顺利实施。

需方应明确指定项目相关负责人，应具有足够的权力处理以下问题： 向供方提出需求

回答供方提出的某些相关问题

认可供方的提案

与供方签订协议并能确保遵守签订的协议

规定验收准则和规程

向供方提供必要的信息,提供有利的环境并解决项目中一些障碍。

4.1.3 共同评审

双方定期地交流，并联合评审软件是否满足已经商定的需求规格说明书。

4.2 质量体系

本质量体系贯穿整个开发周期，是为了在开发过程中保证质量，并非在开发结束时才检查质量问题，所以重点强调防止问题地发生，问题发生后的纠正仅作为补充手段。

本公司将采取必要手段保证这一体系得以有效地贯彻实施。

质量体系文件

本公司的质量体系文件,包括质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。

质量体系文件见附录《质量体系文件》

质量计划

具体项目开发组根据公司质量体系制订质量活动计划并形成《质量保证计划》，以保证开发组能正确理解质量体系并能遵照执行。

附录之《质量保证计划指导》作为各项目组制订计划的指导。

4.3 审核

本公司内部建立全面的审核制度，以验证各具体项目中的质量活动是否符合计划要求，同时检查质量体系的有效性，以不断完善质量体系。

审核过程及采取的措施均要按书面方式进行。

审核结果形成报告，提交审核部门负责人。对于审核时发现的问题，相关负责人应及时采取措施。

4.4 纠正措施

纠正措施必须制定书面规程，应包括以下内容：

调查问题产生的直接原因，并制定防止同类事件发生所需的措施。

查询分析各类过程记录、让步记录、操作记录、质量记录、客户投诉等等，已查明潜在原因并消除

根据风险程度，采取预防措施

对纠正措施的有效实施加以控制

对纠正措施的记录

5. 质量体系生存周期

要求各阶段必须有合格的产品（包括文档），并以其作为下一阶段的工作基础。对每一阶段的产品，必须组织评审，确保其质量，避免错误影响后续工作。

本标准适用于任何生存周期模型。

5.1 合同评审

本公司应评审每一合同，以确保：

规定合同的范围和需求并写入文档 识别可能出现的风险

恰当的保护有关的专利信息 解决所有与招标不一致的需求 有能力满足需求

规定其他涉及项目的供货商的责任 统一双方对术语的理解

需方有能力履行合同职责 合同评审记录应妥善保管。

此外，应注意有关质量条款

验收准则

在开发过程中对需求变更的处理

对验收后出现问题的处理

确定需方的责任，尤其是在需求规格说明、安装和验收时的作用 有需方提供的必要便利条件，如设施、工具和软件等

采用的标准和规程

5.2 需方需求规格说明

在某一具体项目进行开发前，本公司应具有一套该项目的完整、精确、无歧义的功能需求，这些需求应包括需方的所有要求。

因为本公司在业务领域具有丰富的经验，可以大力配合客户识别并确定需求，需求在开发前得到需方的确认。

该需求应足以成为产品验收确认时的依据。

在制订需求规格说明时应注意：

双方制定专人负责

需求认可和更改的批准

防止误解，定义好术语，对需求的背景进行说明

记录和评审双方讨论的结果，以备将来查询某些需求确定原因。

5.3开发计划

在项目进行前制定开发计划，作为总体的策划，指导整个项目有序的进行。

开发计划要求包括以下方面：

项目定义

项目资源组织管理

开发阶段

进度

确定质量保证计划、测试计划、集成计划等

随着项目的进展，开发计划要不断更新，在生命周期模型每一阶段开始之前，都要有该阶段的工作计划，并经过评审后实施。

以下较详细的说明开发计划中应具备的各方面。

A. 开发阶段

开发计划应将项目目标转化为最终结果的过程、方法等清楚的描述出来，可以把工作分为几个阶段，比如按照生命周期法划分开发阶段。

开发阶段要确定以下项：

要执行的开发阶段

每一阶段所需的输入

必须用文档方式确定下来，每一项需求均有明确的定义，以保证完成情况可被检验。

每一阶段应产生的输出

验证阶段输出，必须满足以下几点：

满足相应的要求

有明确的验收准则，作为验收评审的参考。

符合开发惯例和约定

每一阶段需要执行的验证步骤

必须有对每阶段输出的验证计划，并在适当的时间进行验证评审。

分析各阶段可能潜在的问题或需要解决的问题

B. 项目管理

项目开发、实施等过程的时间进度安排

进度的控制方法及活动

确定组织机构及其职责、各工作组的资源及工作分配 不同工作组间的组织协调方法，并明确技术接口问题。

C. 开发方法和工具

规定项目活动应共同遵循的方法及使用的工具，包括：

开发规范、惯例

开发工具及技术

5.4 质量计划

质量计划作为开发计划的一部分。

质量计划随项目进展而更新，质量计划经正式评审，并得到所有与计划执行有关的组织的统一。

质量计划应包含或引用以下内容：

质量目标，尽可能以定量方式给出

定义每一阶段的输入、输出准则

确定要进行的测试、验证和确认活动的类型和详细计划，包括时间、进度等。

确定具体质量活动的职责：比如，评审和测试、更改控制、对缺陷的控制和纠正措施。

5.5 设计和实现

设计和实现活动是将需求规格说明转化为软件产品的过程。为保证软件产品的质量，这些活动必须在严格规定的方法下进行，不能依赖于事后的审查监督。

设计

设计阶段要满足各阶段的共同要求，此外，设计阶段还应考虑：

选用适合所开发产品类型的设计方法

总结吸取以往项目的经验教训

设计应考虑软件以后的测试、维护和使用

B. 实现

规定编程规则、编程语言、命名约定、编码和注释规则等

要求在实现过程中严格遵守既定开发规则

选用合适的方法和工具实现产品

本公司内部制定《开发规范》，各项目组可参照制定适合特定项目的规范。

C. 评审

为使需求规格说明得以满足和上述规则方法得以实施，必须以评审的方式加以保证。直到所有被发现的缺陷被消除，或确定缺陷的风险可被控制后，才能进入下一步的设计或实现工作。

各项目组引用公司规范或参照制定的开发规范应在取得本项目组广泛认可的情况下，提交给评审部门，作为评审参照依据。

评审纪录应保存，评审结果可能作为个人及项目组工作成绩评定的参考之一。

5.6 测试和确认

要具有完整的测试计划，测试计划要经过评审，并以此为依据进行测试活动。

A.测试计划

包括单元测试计划、集成测试计划、系统测试计划、验收测试计划 制定测试用例、测试数据和预期结果

考虑要进行的测试类型，如：功能测试、边界测试、性能测试、可用性测试等

描述测试环境、工具以及测试软件

软件产品是否完成的判断准则

测试所需人员及其要求

B.测试活动

记录发现的问题，指出可能的受影响的其他部分的软件，通知相关负责人员。

确定受影响的其他部分软件，并对其进行重新测试。

评价测试是否适度和适当。

在验收和交付产品前，必须尽可能在类似使用环境中进行确认测试。

5.7 验收

当软件产品已经完成，经过内部确认测试，准备好交付后，应要求需方根据合同中的规定原则判断是否可以进行验收。对于验收中发现问题的处理办法由双方商定并纳入文档。

具备验收条件后，应制定验收计划并逐步实施。

验收计划应包括：

时间进度

评估规程

软件/硬件环境

验收准则

5.8 复制、交付和安装

制定安装分发计划。

复制

制作好安装程序，复制好必要的拷贝。

准备好该交付的操作手册、用户指南等文档。

交付

交付前应对所交付产品的正确性及完整性进行检验。

安装

就以下方面双方明确商定各自的作用、责任和义务：

时间进度及安排，包括非工作时间及假日的人员安排及工作责任 提供出入便利条件，如通行证等

指定熟练人员的密切配合

提供必要的系统及设备

对每次安装的确认条件需明确规定

对每次安装认可的正式规程

5.9 维护

对于软件产品在初次交付及安装后，本公司必须提供的维护应在合同中明确规定。合同中应明确以下各项的维护期：

程序

数据

规格说明

维护工作一般包括：

问题的解决

接口的调整

功能扩充和性能改进

本公司针对以上维护工作制订完善的维护方案，并严格遵照执行。具体维护方案见《维护工作流程》

附录C 质量体系文件

包括质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施

质量要求要素定义如下：

正确性 在预定环境下，软件满足设计规格说明及用户预期目标的程度。它要求软件没有错误。

可靠性 软件按照设计要求，在规定时间和条件下不出故障，持续运行的程度。

效率 为了完成预定功能，软件系统所需的计算机资源的多少。

完整性 为了某一目的面保护数据，避免它受到偶然的，或有意的破坏、改动或遗失的能力。

可使用性 对于一个软件系统，用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。

可维护性 为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，对一个已投入运行的软件进行相应诊断和修改所需工作量的大小。

可测试性 测试软件以确保其能够执行预定功能所需工作量的大小。 灵活性 修改或改进一个已投入运行的软件所需工作量的大小。

复用性 一个软件（或软件的部分）能再次用于其它应用（该应用的功能与软件或软件部件的所完成功能有联系）的程度。

在设计开发过程中，必须注意以下要求，以保证软件的质量达到目标。

正确性

软件的功能要满足用户的要求，在预定环境下能够完成预期的功能。因此，必须明确的了解用户的需求。

在需求确定方面，应通过深刻的理解电信企业的运营系统及了解其发展趋势，建立模型并分析，广泛了解其他系统的特长，并总结以往的经验教训的基础上，确定出需求并通过与用户的交流最终确定。

在需求的表达方面，强调以全面、精确、细致、易于理解的方式表达，可能需要以多种形式，比如：功能描述、数据描述、数据流图、系统说明等。

可维护性

遵从统一的规范，包括命名规范、界面规范、编程风格。

编码应具有良好的可读性，注释完整清晰。

避免复杂的逻辑判断条件，易读，易测试

编码应尽量简练，逻辑简单

保存异常信息与错误日志以便于调试与分析

降低模块之间的耦合度，增强模块内的内聚。

可用性

用户容易理解和使用该功能

响应时间快，操作方便，提高用户工作效率。

提示信息简洁准确

可靠性

具有异常捕获功能并提供异常处理与恢复功能

5、效率

尽量降低系统资源的开销

查询语句要充分考虑到索引

减少与数据库的不必要的交互

灵活性，易于扩展

充分考虑到各地的不同的环境，通过参数设置使其易于适应不同的要求。

完整性、安全性

保证相关的数据一致性

考虑数据的存取权限。

文档完善

按文档要求完成相关文档。

审查制度

对于每一阶段的文档及软件产品都应交付证质量保证部门，由审查小组按质量要求严格审查。

审查内容：

文档：开发计划、用户需求规格说明、概要及详细设计文档、技术文档、用户手册等，详细要求见文档计划。评审文档是否规范，表达清晰，有实用价值。

设计方案：是否达到设计目标。

应用程序：是否达到质量目标和符合设计目标。

审查流程：

项目组按计划准备好交付的产品及文档

交付质量保证部门，组织评审

完成评审，发现错误报告

发现错误的返工

复查返工问题是否已解决

第二篇：软件开发文档范例-程序维护手册

程序维护手册

1. 引言

? 编写目的

软件维护是软件生命周期的最后一个阶段，它处于系统投入生产性运行以后的时期中,因此不属于系统开发过程。

软件维护需要的工作量非常大，虽然在不同应用领域维护成本差别很大，但是，平均说来，大型软件的维护成本高达开发成本的四倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。

软件维护就是在软件已经交付使用之后，为了改正错误或者满足新的需要而修改软件 的过程。它有如下几种性质的维护：

? 改正性维护

因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以在使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。我们把诊断和改正错误的过程称为改正性维护。

? 适应性维护

计算机科学技术领域的各方面都在迅速进步，需要经常地修改版本。为了和变化了的环境适当地配合而进行的修改软件的活动称为适应性维护。

? 完善性维护

在软件编写完成之后，投入实践，在使用软件的过程中，用户往往提出增加新功能或修改已有的功能的建议，这就需要进行完善性维护。

? 预防性维护

为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，就需要进行预防性维护。

维护的过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。

鉴于以上各点，编写维护软件的文档十分重要。它给软件维护人员提供了一份完整，清晰的说明文档，便于其快速有效地进行维护工作。

? 开发单位

项目的提出者：浙江航空公司

开发者：〈〉软件开发工作室

用户：浙江航空公司

使用场所：浙江航空公司各售票厅

? 定义和缩写

a. 数据流图描绘系统的逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系 统中流动和处理的情况，它表示了数据和处理过程的关系。数据流图有四种基本符号： ? 正方形（或立方体）表示数据的源点或终点。

? 圆角矩形（或圆形）代表变换数据的处理。

处理不一定是一个程序。一个处理框可以代表一系列程序，单个程序或者程序的 一个模块；它甚至可以代表一种人工处理过程。

? 开口矩形（或两条平行横线）代表数据存储。

数据存储可以表示一个文件，文件的一部分，数据库的元素或纪录的一部分等等。 数据存储是处于静止状态的数据。

? 箭头代表数据流，即特定数据的流动方向。

数据流是处于运动中的数据。

还有几种附加符号：

? 星号表示数据流之间是“与”关系

? 加号表示“或”关系

? 异或符号表示只能从中选一个

b. 数据字典(Data Dictionary，简称DD)是对系统中各类数据描述的集合，是各类数据属性清单，是进行详细的数据收集和数据分析所获得的主要结果。它通常包括以下五个部分：

? 数据项，是数据的最小的单位。

? 数据结构，是若干数据项有意义的集合。

? 数据流，可以是数据项，也可以是数据结构，表示某一处理过程的输入或输出。 ? 数据存储，处理过程中存取的数据。常常是手工凭证，手工文档，计算机文件。 ? 处理过程。

它们的描述内容如下：

1．数据项描述={数据项名，数据项含义说明，别名，类型，长度，取值范围，与其他数据项的逻辑关系}

取值范围，与其他数据项的逻辑关系定义了数据的完整性约束条件，是设计数据检验功能的依据。

2．数据结构描述={数据结构名，含义说明，组成：{数据结构或数据项}}

3．数据流={数据流名，说明，流出过程，流入过程，组成：{数据结构或数据项}} ? 流出过程，说明该数据流由什么过程来。

? 流入过程，说明该数据流到什么过程去。

4．数据存储={数据存储名，说明，输入数据流 ，输出数据流，组成：{数据结构或数据项}，数据量，存取方式}

? 数据量，说明每次存取多少数据，每天（或每小时，或每周）存取几次的信息。 ? 存取方法，指的是批处理，还是联机处理；是检索还是更新；是顺序检索还是

随机检索；尽可能详细收集并加以说明。

5．处理过程={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}

简要说明中主要说明该处理过程的功能，即“做什么”（不是怎么做）；处理频度要 求，如每小时（或每分钟）处理多少事务，多少数据量；响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。

d. 主键：数据库表中的关键域。值互不相同。

e. 外部主键：数据库表中与其他表主键关联的域。

f. 系统：若未特别指出，统指本机票预定系统。

g. SQL: Structured Query Language（结构化查询语言），一种用于访问查询数据库的语言 h. SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。

i. ATM: Asynchronous Transfer Mode (异步传输模式)。

j. ROLLBACK: 数据库的错误恢复机制。

? 参考资料

书籍：

《软件工程导论》第三版 张海藩 清华大学出版社

《实用软件工程》第二版 郑人杰 殷人昆 陶永雷 清华大学出版社

文档：

需求规格说明书，概要设计说明书，详细设计说明书，用户操作手册。

2. 系统说明

? 系统用途

输入：预定机票的旅客信息，包括姓名，性别，工作单位，身份证号码，旅行时间，旅

行目的地。

输出：取票通知和帐单。

功能：查询航班和旅客信息，增加预定机票的旅客信息，删除要求退票的旅客信息。

? 安全保密

系统提供一定的方式让用户表示自己的身份，系统进行核实，通过鉴定后才提供 机器使用权。常用的方法有：

1．用一个用户名或用户标识号来标识用户身份。

2．口令。

3．系统提供一个随机数，用户根据预先约定好的某一过程或者函数进行计算，系

统根据用户计算结果是否正确进一步鉴定用户身份。

系统管理员还可对获得上机权的用户进行权限控制，是不同的用户对于不同的数据对象

有不同的操作权限。

? 总体说明

系统的总体功能：系统接收输入的预定机票的旅客信息，为旅客安排航班，印出取票通

知和帐单，旅客在飞机起飞的前一天凭取票通知和帐单交款取票，系统校对无误即印出机票

给旅客。

系统的具体功能：

1． 接受：旅客信息及取票通知和帐单；

2． 打印：取票通知和帐单及机票；

3． 网络输出和加密，输入和解密；

4． 分辨信息的种类并采取相应的处理步骤；

5． 判断信息的正误并采取相应的处理步骤；

6． 进行数据库的查询、修改工作；

7． 接受并判断错误，输出相应的出错消息；

? 程序说明

1. PersInfoExam 过程：

对在旅客信息界面中输入的各项信息进行初步检验。若发现错误，令 ErrorAppear=T,判断错误类型，并将相应的 错误类型ErrorType或ErrorRank作为参数，转

入ErrorHandle过程。若未发现错误，转入PersInfoInput过程。其中的错误种类有：

1.数据类型不匹配,ErrorType =T;

姓名 string 旅行目的地 string

性别 string 旅行时间 date

工作单位 string (年/月/日 yy/mm/dd)

身份证号码 long int

2、数据超出规定范围ErrorRank =T;等等

性别只能是‘男’或‘女’；身份证号码按规定必须是13位；旅行时间必须在 定票的当天过一天以后等等

2、PersInfoInput 过程：

经检验无误后，将输入界面表单中的数据输入到Class PersInfo

Class PersInfo{ /* 伪码 */

String name= 姓名 ；

String sex= 性别；

String company= 工作单位；

Long int idcode= 身份证号码；

Date stime= 旅行时间；

（syear/smonth/stime=年/月/日）

String denist= 目的地

}

2．操作环境

? 设备

共享一个数据库的若干台电脑，台式打印机若干。

? 支持软件

支持常用的数据库应用软件：

VISUAL FOXPRO 5.0 , DELPHI 4.0, POWER BUILDER 6.0

? 数据库

标识符：姓名，性别，工作单位，身份证号码，旅行时间，旅行目的地。

静态数据：存储在硬盘上的数据。

动态数据：正处于处理过程中的数据。

数据库的存储媒体：硬盘。

3. 维护过程

? 规则

1．设计原则

1． 密切结合结构（数据）设计和行为（处理）设计。

2．有机结合硬件，软件，技术和管理的界面。

3．具体程序实现过程中，对记录，字段的引用参照PersInfo 类。

4．存储区的标识符也参照PersInfo 类。

5．在设计过程中参照瀑布模型，ER模型，层次图，Jackson 程序设计方法。

2．设计程序变更的准则

1．检查可供选择的设计方案，寻找一种与程序的原始设计原理相容的变更设计。

2．努力使设计简化。

3．能满足可变性要求的设计。

4．不降低程序质量。

5．用可测试的并具备测试方法的术语描述设计。

6．考虑处理时间，存储量和操作过程方面的变化。

7．考虑标更对用户服务的干扰以及实施变更的代价与时间。

3．修改程序代码的准则

1．必须要先熟悉整个程序的控制流程。

2．不要做不必要的修改。

3．不影响原始程序的风格和相容性。

4．记录所作过的修改。

5．审查软件质量是否符合标准。

6．更新程序文档以反映修改并保留修改前的程序代码版本。

4．重新验证程序的准则

1．首先测试程序故障，然后测试程序的未改动部分，最后测试程序的修改部分。

2．不允许做修改的维护程序员成为唯一的重新验证程序的人。

3．鼓励终端用户参与到重新测试进程中来。

4．在重新验证进程中，记录出错的次数与类型，并把结果同所提供的测试功能进行比较，以便估量出程序是否退化。

? 验证过程

每当软件被修改后，都要校验其正确性。维护员应该有选择地作些重新测试工作，不仅要证实新的逻辑的正确性，而且要校验实程序的为修改部分是否无损害，并且整个程序运行正确。若发现错误，则要马上进行修正。

? 出错及纠正方法

经查询还有余票，但输入旅客信息后却发现已没有余票。发生这种情况的原因是：有多台计算机同时输入订购同一次航班的旅客信息，在查询余票时，其他输入信息并未写入磁盘，票数并未修改。此时，应该等待数秒后重新查询余票。

? 专门维护过程

系统运行一段时间后，由于记录的不断增加，删除和修改，会使数据库的物理存储变坏。例如，逻辑上属于同一记录型或同一关系的数据被分散到了不同的文件或文件的多个碎片上。这样就会降低数据库存储空间的利用率和数据的访存效率，使数据库的性能下降。这是就要进行数据库的重组织。在重组过程中，按原设计要求重新安排记录的存储位置，调整数据区和溢出区，回收“垃圾”，减少指针链等。

? 程序清单及流程图

详见概要设计和详细设计文档。