软件开发质量手册.docx

软件开发质量手册.docx

《软件开发质量手册.docx》由会员分享，可在线阅读，更多相关《软件开发质量手册.docx（14页珍藏版）》请在冰豆网上搜索。

软件开发质量手册

软件幵发质量保证体系

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维护

公司内部标准

本标准参照IS09000-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质量计划

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

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

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

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

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

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

确定具体质量活动的职责：

比如，评审和测试、更改控制、对缺陷的控制和纠正措施。

5.5设计和实现

设计和实现活动是将需求规格说明转化为软件产品的过程。

为保证软件产品的质量，这些活动必须在严格规定的方法下进行，不能依赖于事后的审查监督。

设计

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

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

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

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

B.实现

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

要求在实现过程中严格遵守既定幵发规则选用合适的方法和工具实现产品

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

C.评审

为使需求规格说明得以满足和上述规则方法得以实施，必须以评审的方式加以保证。

直到所有被发现的缺陷被消除，或确定缺陷的风险可被控制后,才能进入下一步的设计或实现工作。

各项目组引用公司规范或参照制定的幵发规范应在取得本项目组广泛认

可的情况下，提交给评审部门，作为评审参照依据。

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

。

5.6测试和确认

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

A.测试计划

包括单元测试计划、集成测试计划、系统测试计划、验收测试计划

制定测试用例、测试数据和预期结果

考虑要进行的测试类型，如：

功能测试、边界测试、性能测试、可用性测试等

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

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

测试所需人员及其要求

B.测试活动

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

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

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

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

5.7验收

当软件产品已经完成，经过内部确认测试，准备好交付后，应要求需方根据合同中的规定原则判断是否可以进行验收。

对于验收中发现问题的处理办法由双方商定并纳入文档。

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

验收计划应包括：

时间进度

评估规程

软件/硬件环境

验收准则

5.8复制、交付和安装

制定安装分发计划。

复制

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

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

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

安装

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

时间进度及安排，包括非工作时间及假日的人员安排及工作责任

提供出入便利条件，如通行证等

指定熟练人员的密切配合

提供必要的系统及设备

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

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

5.9维护

对于软件产品在初次交付及安装后，本公司必须提供的维护应在合同中明

确规定。

合同中应明确以下各项的维护期：

程序

数据

规格说明

维护工作一般包括：

问题的解决

接口的调整

功能扩充和性能改进

本公司针对以上维护工作制订完善的维护方案，并严格遵照执行。

具体维

护方案见《维护工作流程》

附录C质量体系文件

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

质量要求要素定义如下:

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

它要求软件没有错误。

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

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

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

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

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

可测试性测试软件以确保其能够执行预定功能所需工作量的大小。

灵活性修改或改进一个已投入运行的软件所需工作量的大小。

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

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

正确性

软件的功能要满足用户的要求，在预定环境下能够完成预期的功能。

因此,必须明确的了解用户的需求。

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

在需求的表达方面，强调以全面、精确、细致、易于理解的方式表达，可

能需要以多种形式，比如：

功能描述、数据描述、数据流图、系统说明等。

可维护性

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

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

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

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

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

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

可用性

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

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

提示信息简洁准确

可靠性

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

5、效率

尽量降低系统资源的幵销

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

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

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

完整性、安全性

保证相关的数据一致性

考虑数据的存取权限。

文档完善

按文档要求完成相关文档

审查制度

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

质量要求严格审查。

审查内容：

文档：

幵发计划、用户需求规格说明、概要及详细设计文档、技术文档、

用户手册等，详细要求见文档计划。

评审文档是否规范，表达清晰，有实

用价值。

设计方案：

是否达到设计目标。

应用程序：

是否达到质量目标和符合设计目标。

审查流程：

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

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

完成评审，发现错误报告

发现错误的返工

复查返工问题是否已解决