软件开发质量手册.docx

1、软件开发质量手册软件幵发质量保证体系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、施。2、 引用标准本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产 品质量。使用本文档时，请尽量参照最新版本。3、 定义产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关 的文档和数据。幵发：创作软件产品的所有活动。供方：指本公司。需方：指具体项目的需求方，即客户。质量体系：质量要素、各要素需要达到的目标以及在幵发过程中必须采取 的措施。4、质量体系框架4.1管理职责4.1.1供方（及具体的项目幵发组）负责以下职责组织机构本公司内部专门设立部门质量保证部门，由部门负责人及专门经过培训的人员组成。具体项目幵发组，设立质量保证组，或委托公司质量保证部门协助幵展工作。质

3、量保证部门负责以下工作：建立并维护公司内部的质量保证体系。对可能导致产品不合格的问题予以识别，采取措施予以避免。发现并记录产品的质量问题。提出、采取或推荐问题解决办法。验证解决办法的实施效果。对不合格产品的处理、交付过程进行控制，确保最终问题得以纠正。质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。制定质量方针和质量目标 确保项目组成员均理解质量方针并能坚持贯彻执行。公司内部制定一般性的质量方针及对软件产品的质量目标，作为各项目组 的参照，各项目组可根据具体客户期望及需求作出具体质量目标及质量承 诺，具体质量目标及承诺，特别是超出公司目标的部分，提交给质量保证 部门，以便提交给质量

4、保证部门充分理解并协助实施。质量方针和质量目标见附录管理评审质量保证部门负责人应每月对质量体系进行评审，主要是对内部质量审核 结果的评定，以保证质量体系持续有效，保存评审记录。4.1.2 需方（客户）应负的职责在项目中，应向需方（客户）提出具体要求，明确其需要承担的职责，以 便相互配合，共同保证项目的顺利实施。需方应明确指定项目相关负责人，应具有足够的权力处理以下问题：向供方提出需求回答供方提出的某些相关问题认可供方的提案与供方签订协议并能确保遵守签订的协议规定验收准则和规程向供方提供必要的信息，提供有利的环境并解决项目中一些障碍。4.1.3 共同评审双方定期地交流，并联合评审软件是否满足已经

5、商定的需求规格说明书。4.2质量体系本质量体系贯穿整个幵发周期，是为了在幵发过程中保证质量，并非在幵 发结束时才检查质量问题，所以重点强调防止问题地发生，问题发生后的纠正仅作为补充手段。本公司将采取必要手段保证这一体系得以有效地贯彻实施。质量体系文件本公司的质量体系文件，包括质量要素、各要素需要达到的目标以及在幵发过程中必须采取的措施。质量体系文件见附录质量体系文件质量计划具体项目幵发组根据公司质量体系制订质量活动计划并形成质量保证计划，以保证幵发组能正确理解质量体系并能遵照执行。附录之质量保证计划指导作为各项目组制订计划的指导4.3审核本公司内部建立全面的审核制度，以验证各具体项目中的质量活

6、动是否符合计划要求，同时检查质量体系的有效性，以不断完善质量体系。审核过程及采取的措施均要按书面方式进行。审核结果形成报告，提交审核部门负责人。对于审核时发现的问题，相关负责人应及时采取措施。4.4纠正措施纠正措施必须制定书面规程，应包括以下内容：调查问题产生的直接原因，并制定防止同类事件发生所需的措施。查询分析各类过程记录、 让步记录、操作记录、质量记录、客户投诉等等, 已查明潜在原因并消除根据风险程度，采取预防措施对纠正措施的有效实施加以控制对纠正措施的记录5.质量体系生存周期要求各阶段必须有合格的产品（包括文档），并以其作为下一阶段的工作 基础。对每一阶段的产品，必须组织评审，确保其质量

7、，避免错误影响后 续工作。本标准适用于任何生存周期模型。5.1合同评审本公司应评审每一合同，以确保：规定合同的范围和需求并写入文档识别可能出现的风险恰当的保护有关的专利信息解决所有与招标不一致的需求有能力满足需求规定其他涉及项目的供货商的责任统一双方对术语的理解需方有能力履行合同职责合同评审记录应妥善保管。此外，应注意有关质量条款验收准则在幵发过程中对需求变更的处理对验收后出现问题的处理确定需方的责任，尤其是在需求规格说明、安装和验收时的作用有需方提供的必要便利条件，如设施、工具和软件等采用的标准和规程5.2需方需求规格说明在某一具体项目进行幵发前，本公司应具有一套该项目的完整、精确、无 歧义

8、的功能需求，这些需求应包括需方的所有要求。因为本公司在业务领域具有丰富的经验，可以大力配合客户识别并确定需 求，需求在幵发前得到需方的确认。该需求应足以成为产品验收确认时的依据。在制订需求规格说明时应注意：双方制定专人负责需求认可和更改的批准防止误解，定义好术语，对需求的背景进行说明记录和评审双方讨论的结果，以备将来查询某些需求确定原因。5.3幵发计划在项目进行前制定幵发计划， 作为总体的策划，指导整个项目有序的进行幵发计划要求包括以下方面:项目定义项目资源组织管理幵发阶段进度确定质量保证计划、测试计划、集成计划等随着项目的进展，幵发计划要不断更新，在生命周期模型每一阶段幵始之前，都要有该阶段

9、的工作计划，并经过评审后实施。以下较详细的说明幵发计划中应具备的各方面。A.幵发阶段幵发计划应将项目目标转化为最终结果的过程、方法等清楚的描述出来，可以把工作分为几个阶段，比如按照生命周期法划分幵发阶段。开发阶段要确定以下项：要执行的开发阶段每一阶段所需的输入必须用文档方式确定下来，每一项需求均有明确的定义，以保证完成情况 可被检验。每一阶段应产生的输出验证阶段输出，必须满足以下几点：满足相应的要求有明确的验收准则，作为验收评审的参考。符合幵发惯例和约定每一阶段需要执行的验证步骤 必须有对每阶段输出的验证计划，并在适当的时间进行验证评审分析各阶段可能潜在的问题或需要解决的问题B.项目管理项目幵

10、发、实施等过程的时间进度安排进度的控制方法及活动确定组织机构及其职责、各工作组的资源及工作分配不同工作组间的组织协调方法，并明确技术接口问题。C.幵发方法和工具规定项目活动应共同遵循的方法及使用的工具，包括:幵发规范、惯例幵发工具及技术5.4质量计划质量计划作为幵发计划的一部分。质量计划随项目进展而更新，质量计划经正式评审，并得到所有与计划执 行有关的组织的统一0质量计划应包含或引用以下内容：质量目标，尽可能以定量方式给出定义每一阶段的输入、输出准则确定要进行的测试、验证和确认活动的类型和详细计划，包括时间、进度 等。确定具体质量活动的职责：比如，评审和测试、更改控制、对缺陷的控制 和纠正措施

11、。5.5设计和实现设计和实现活动是将需求规格说明转化为软件产品的过程。为保证软件产 品的质量，这些活动必须在严格规定的方法下进行，不能依赖于事后的审 查监督。设计设计阶段要满足各阶段的共同要求，此外，设计阶段还应考虑：选用适合所幵发产品类型的设计方法总结吸取以往项目的经验教训设计应考虑软件以后的测试、维护和使用B.实现规定编程规则、编程语言、命名约定、编码和注释规则等要求在实现过程中严格遵守既定幵发规则 选用合适的方法和工具实现产品本公司内部制定 幵发规范，各项目组可参照制定适合特定项目的规范。C.评审为使需求规格说明得以满足和上述规则方法得以实施，必须以评审的方式 加以保证。直到所有被发现的

12、缺陷被消除， 或确定缺陷的风险可被控制后, 才能进入下一步的设计或实现工作。各项目组引用公司规范或参照制定的幵发规范应在取得本项目组广泛认可的情况下，提交给评审部门，作为评审参照依据。评审纪录应保存，评审结果可能作为个人及项目组工作成绩评定的参考之。5.6测试和确认要具有完整的测试计划，测试计划要经过评审，并以此为依据进行测试活 动。A.测试计划包括单元测试计划、集成测试计划、系统测试计划、验收测试计划制定测试用例、测试数据和预期结果考虑要进行的测试类型，如：功能测试、边界测试、性能测试、可用性测 试等描述测试环境、工具以及测试软件软件产品是否完成的判断准则测试所需人员及其要求B.测试活动记录

13、发现的问题，指出可能的受影响的其他部分的软件，通知相关负责人 员。确定受影响的其他部分软件，并对其进行重新测试。评价测试是否适度和适当。在验收和交付产品前，必须尽可能在类似使用环境中进行确认测试。5.7验收当软件产品已经完成，经过内部确认测试，准备好交付后，应要求需方根 据合同中的规定原则判断是否可以进行验收。对于验收中发现问题的处理 办法由双方商定并纳入文档。具备验收条件后，应制定验收计划并逐步实施。验收计划应包括：时间进度评估规程软件/硬件环境验收准则5.8复制、交付和安装制定安装分发计划。复制制作好安装程序，复制好必要的拷贝。准备好该交付的操作手册、用户指南等文档交付 交付前应对所交付产

14、品的正确性及完整性进行检验。安装就以下方面双方明确商定各自的作用、责任和义务：时间进度及安排，包括非工作时间及假日的人员安排及工作责任提供出入便利条件，如通行证等指定熟练人员的密切配合提供必要的系统及设备对每次安装的确认条件需明确规定对每次安装认可的正式规程5.9维护对于软件产品在初次交付及安装后，本公司必须提供的维护应在合同中明确规定。合同中应明确以下各项的维护期：程序数据规格说明维护工作一般包括：问题的解决接口的调整功能扩充和性能改进本公司针对以上维护工作制订完善的维护方案，并严格遵照执行。具体维护方案见维护工作流程附录C质量体系文件包括质量要素、各要素需要达到的目标以及在幵发过程中必须采

15、取的措施质量要求要素定义如下:正确性 在预定环境下，软件满足设计规格说明及用户预期目标的程度。 它要求软件没有错误。可靠性 软件按照设计要求，在规定时间和条件下不出故障，持续运行的 程度。效率 为了完成预定功能，软件系统所需的计算机资源的多少。完整性 为了某一目的面保护数据，避免它受到偶然的，或有意的破坏、 改动或遗失的能力。可使用性 对于一个软件系统，用户学习、使用软件及为程序准备输入和 解释输出所需工作量的大小。可维护性 为满足用户新的要求，或当环境发生了变化，或运行中发现了 新的错误时，对一个已投入运行的软件进行相应诊断和修改所需工作量的 大小。可测试性测试软件以确保其能够执行预定功能所

16、需工作量的大小。灵活性 修改或改进一个已投入运行的软件所需工作量的大小。复用性 一个软件（或软件的部分）能再次用于其它应用（该应用的功能 与软件或软件部件的所完成功能有联系）的程度。在设计幵发过程中，必须注意以下要求，以保证软件的质量达到目标。正确性软件的功能要满足用户的要求， 在预定环境下能够完成预期的功能。 因此, 必须明确的了解用户的需求。在需求确定方面，应通过深刻的理解电信企业的运营系统及了解其发展趋 势，建立模型并分析，广泛了解其他系统的特长，并总结以往的经验教训 的基础上，确定出需求并通过与用户的交流最终确定。在需求的表达方面，强调以全面、精确、细致、易于理解的方式表达，可能需要以

17、多种形式，比如：功能描述、数据描述、数据流图、系统说明等。可维护性遵从统一的规范，包括命名规范、界面规范、编程风格。编码应具有良好的可读性，注释完整清晰。避免复杂的逻辑判断条件，易读，易测试编码应尽量简练，逻辑简单保存异常信息与错误日志以便于调试与分析降低模块之间的耦合度，增强模块内的内聚。 可用性用户容易理解和使用该功能响应时间快，操作方便，提高用户工作效率。提示信息简洁准确可靠性具有异常捕获功能并提供异常处理与恢复功能5、效率尽量降低系统资源的幵销查询语句要充分考虑到索引减少与数据库的不必要的交互灵活性，易于扩展 充分考虑到各地的不同的环境，通过参数设置使其易于适应不同的要求。完整性、安全性保证相关的数据一致性考虑数据的存取权限。文档完善按文档要求完成相关文档审查制度对于每一阶段的文档及软件产品都应交付证质量保证部门，由审查小组按质量要求严格审查。审查内容：文档：幵发计划、用户需求规格说明、概要及详细设计文档、技术文档、用户手册等，详细要求见文档计划。评审文档是否规范，表达清晰，有实用价值。设计方案：是否达到设计目标。应用程序：是否达到质量目标和符合设计目标。审查流程：项目组按计划准备好交付的产品及文档交付质量保证部门，组织评审完成评审，发现错误报告发现错误的返工复查返工问题是否已解决