软件开发质量保证体系样本.doc

软件开发质量保证体系

最后更新日期：.6.12    
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 供方(及详细项目开发组)负责如下职责
o 组织机构
我司内部专门设立部门质量保证部门，由部门负责人及专门通过培训人员构成。详细项目开发组，设立质量保证组，或委托公司质量保证部门协助开展工作。
质量保证部门负责如下工作：
o 建立并维护公司内部质量保证体系。
o 对也许导致产品不合格问题予以辨认，采用办法予以避免。
o 发现并记录产品质量问题。
o 提出、采用或推荐问题解决办法。
o 验证解决办法实行效果。
o 对不合格产品解决、交付过程进行控制，保证最后问题得以纠正。
质量保证部门评审活动应由与被评审工作无直接负责人员构成。
o 制定质量方针和质量目的
保证项目构成员均理解质量方针并能坚持贯彻执行。
公司内部制定普通性质量方针及对软件产品质量目的，作为各项目组参照，各项目组可依照详细客户盼望及需求作出详细质量目的及质量承诺，详细质量目的及承诺，特别是超过公司目的某些，提交给质量保证部门，以便提交给质量保证部门充分理解并协助实行。
《质量方针和质量目的》见附录
o 管理评审
质量保证部门负责人应每月对质量体系进行评审，重要是对内部质量审核成果评估，以保证质量体系持续有效，保存评审记录。
     4.1.2 需方（客户）应负职责
在项目中，应向需方（客户）提出详细规定，明确其需要承担职责，以便互相配合，共同保证项目顺利实行。
o 需方应明确指定项目有关负责人，应具备足够权力解决如下问题：
o 向供方提出需求
o 回答供方提出某些有关问题
o 承认供方提案
o 与供方订立合同并能保证遵守订立合同
o 规定验收准则和规程
o 向供方提供必要信息,提供有利环境并解决项目中某些障碍。
     4.1.3 共同评审
双方定期地交流，并联合评审软件与否满足已经商定需求规格阐明书。
4.2 质量体系
    本质量体系贯穿整个开发周期，是为了在开发过程中保证质量，并非在开发结束时才检查质量问题，因此重点强调防止问题地发生，问题发生后纠正仅作为补充手段。
    我司将采用必要手段保证这一体系得以有效地贯彻实行。
A. 质量体系文献
我司质量体系文献,涉及质量要素、各要素需要达到目的以及在开发过程中必要采用办法。
质量体系文献见附录《质量体系文献》
B. 质量筹划
详细项目开发组依照公司质量体系制定质量活动筹划并形成《质量保证筹划》，以保证开发组能对的理解质量体系并能遵循执行。
附录之《质量保证筹划指引》作为各项目组制定筹划指引。
4.3 审核
我司内部建立全面审核制度，以验证各详细项目中质量活动与否符共筹划规定，同步检查质量体系有效性，以不断完善质量体系。
审核过程及采用办法均要按书面方式进行。
审核成果形成报告，提交审核部门负责人。对于审核时发现问题，有关负责人应及时采用办法。
4.4 纠正办法

纠正办法必要制定书面规程，应涉及如下内容：
· 调查问题产生直接因素，并制定防止同类事件发生所需办法。
· 查询分析各类过程记录、让步记录、操作记录、质量记录、客户投诉等等，已查明潜在因素并消除
· 依照风险限度，采用防止办法
· 对纠正办法有效实行加以控制
· 对纠正办法记录

5. 质量体系生存周期
    规定各阶段必要有合格产品（涉及文档），并以其作为下一阶段工作基本。对每一阶段产品，必要组织评审，保证其质量，避免错误影响后续工作。
    本原则合用于任何生存周期模型。
5.1 合同评审
    我司应评审每一合同，以保证：
· 规定合同范畴和需求并写入文档
· 辨认也许浮现风险
· 恰当保护关于专利信息
· 解决所有与招标不一致需求
· 有能力满足需求
· 规定其她涉及项目供货商责任
· 统一双方对术语理解
· 需方有能力履行合同职责
合同评审记录应妥善保管。
此外，应注意关于质量条款
· 验收准则
· 在开发过程中对需求变更解决
· 对验收后浮现问题解决
· 拟定需方责任，特别是在需求规格阐明、安装和验收时作用
· 有需方提供必要便利条件，如设施、工具和软件等
· 采用原则和规程

5.2 需方需求规格阐明
    在某一详细项目进行开发前，我司应具备一套该项目完整、精准、无歧义功能需求，这些需求应涉及需方所有规定。
    由于我司在业务领域具备丰富经验，可以大力配合客户辨认并拟定需求，需求在开发前得到需方确认。
    该需求应足以成为产品验收确认时根据。
    在制定需求规格阐明时应注意：
· 双方制定专人负责
· 需求承认和更改批准
· 防止误解，定义好术语，对需求背景进行阐明
· 记录和评审双方讨论成果，以备将来查询某些需求拟定因素。
5.3开发筹划
在项目进行前制定开发筹划，作为总体策划，指引整个项目有序进行。
开发筹划规定涉及如下方面：
· 项目定义
· 项目资源组织管理
· 开发阶段
· 进度
· 拟定质量保证筹划、测试筹划、集成筹划等
随着项目进展，开发筹划要不断更新，在生命周期模型每一阶段开始之前，都要有该阶段工作筹划，并通过评审后实行。
如下较详细阐明开发筹划中应具备各方面。
    A. 开发阶段
开发筹划应将项目目的转化为最后成果过程、办法等清晰描述出来，可以把工作分为几种阶段，例如按照生命周期法划分开发阶段。
开发阶段要拟定如下项：
o 要执行开发阶段
o 每一阶段所需输入
必要用文档方式拟定下来，每一项需求均有明拟定义，以保证完毕状况可被检查。
o 每一阶段应产生输出
验证阶段输出，必要满足如下几点：
1. 满足相应规定
2. 有明确验收准则，作为验收评审参照。
3. 符合开发惯例和商定
o 每一阶段需要执行验证环节
必要有对每阶段输出验证筹划，并在恰当时间进行验证评审。
o 分析各阶段也许潜在问题或需要解决问题

    B. 项目管理
o 项目开发、实行等过程时间进度安排
o 进度控制办法及活动
o 拟定组织机构及其职责、各工作组资源及工作分派
o 不同工作组间组织协调办法，并明确技术接口问题。
    C. 开发办法和工具
规定项目活动应共同遵循办法及使用工具，涉及：
o 开发规范、惯例
o 开发工具及技术
5.4 质量筹划
质量筹划作为开发筹划一某些。
质量筹划随项目进展而更新，质量筹划经正式评审，并得到所有与筹划执行关于组织统一。
质量筹划应包括或引用如下内容：
o 质量目的，尽量以定量方式给出
o 定义每一阶段输入、输出准则
o 拟定要进行测试、验证和确认活动类型和详细筹划，涉及时间、进度等。
o 拟定详细质量活动职责：例如，评审和测试、更改控制、对缺陷控制和纠正办法。
5.5 设计和实现
设计和实现活动是将需求规格阐明转化为软件产品过程。为保证软件产品质量，这些活动必要在严格规定办法下进行，不能依赖于事后审查监督。
A. 设计
设计阶段要满足各阶段共同规定，此外，设计阶段还应考虑：
· 选用适合所开发产品类型设计办法
· 总结吸取以往项目经验教训
· 设计应考虑软件后来测试、维护和使用
  B. 实现
· 规定编程规则、编程语言、命名商定、编码和注释规则等
· 规定在实现过程中严格遵守既定开发规则
· 选用适当办法和工具实现产品
我司内部制定《开发规范》，各项目组可参照制定适合特定项目规范。
  C. 评审
    为使需求规格阐明得以满足和上述规则办法得以实行，必要以评审方式加以保证。直到所有被发现缺陷被消除，或拟定缺陷风险可被控制后，才干进入下一步设计或实现工作。
    各项目组引用公司规范或参照制定开发规范应在获得本项目组广泛承认状况下，提交给评审部门，作为评审参照根据。
    评审纪录应保存，评审成果也许作为个人及项目组工作成绩评估参照之一。
5.6 测试和确认
         要具备完整测试筹划，测试筹划要通过评审，并以此为根据进行测试活动。
        A.测试筹划
o 涉及单元测试筹划、集成测试筹划、系统测试筹划、验收测试筹划
o 制定测试用例、测试数据和预期成果
o 考虑要进行测试类型，如：功能测试、边界测试、性能测试、可用性测试等
o 描述测试环境、工具以及测试软件
o 软件产品与否完毕判断准则
o 测试所需人员及其规定
        B.测试活动
o 记录发现问题，指出也许受影响其她某些软件，告知有关负责人员。
o 拟定受影响其她某些软件，并对其进行重新测试。
o 评价测试与否适度和恰当。
o 在验收和交付产品前，必要尽量在类似使用环境中进行确认测试。

5.7 验收
    当软件产品已经完毕，通过内部确认测试，准备好交付后，应规定需方依照合同中规定原则判断与否可以进行验收。对于验收中发现问题解决办法由双方商定并纳入文档。
    具备验收条件后，应制定验收筹划并逐渐实行。
    验收筹划应涉及：
· 时间进度
· 评估规程
· 软件/硬件环境
· 验收准则
5.8 复制、交付和安装
    制定安装分发筹划。
A. 复制
制作好安装程序，复制好必要拷贝。
准备好该交付操作手册、顾客指南等文档。
B. 交付
交付前应对所交付产品对的性及完整性进行检查。
C. 安装
    就如下方面双方明确商定各自作用、责任和义务：
· 时间进度及安排，涉及非工作时间及假日人员安排及工作责任
· 提供出入便利条件，如通行证等
· 指定纯熟人员密切配合
· 提供必要系统及设备
· 对每次安装确认条件需明确规定
· 对每次安装承认正式规程
5.9 维护
    对于软件产品在初次交付及安装后，我司必要提供维护应在合同中明确规定。合同中应明确如下各项维护期：
· 程序
· 数据
· 规格阐明
    维护工作普通涉及：
· 问题解决
· 接口调节
· 功能扩充和性能改进
  我司针对以上维护工作制定完善维护方案，并严格遵循执行。详细维护方案见《维护工作流程》

附录C 质量体系文献
涉及质量要素、各要素需要达到目的以及在开发过程中必要采用办法
质量规定要素定义如下：
· 对的性 在预定环境下，软件满足设计规格阐明及顾客预期目的限度。它规定软件没有错误。
· 可靠性 软件按照设计规定，在规定期间和条件下不出故障，持续运营限度。
· 效率 为了完毕预定功能，软件系统所需计算机资源多少。
· 完整性 为了某一目面保护数据，避免它受到偶尔，或故意破坏、改动或遗失能力。
· 可使用性 对于一种软件系统，顾客学习、使用软件及为程序准备输入和解释输出所需工作量大小。
· 可维护性 为满足顾客新规定，或当环境发生了变化，或运营中发现了新错误时，对一种已投入运营软件进行相应诊断和修改所需工作量大小。
· 可测试性 测试软件以保证其可以执行预定功能所需工作量大小。
· 灵活性 修改或改进一种已投入运营软件所需工作量大小。
· 复用性 一种软件（或软件某些）能再次用于其他应用（该应用功能与软件或软件部件所完毕功能有联系）限度。
在设计开发过程中，必要注意如下规定，以保证软件质量达到目的。
1. 对的性
软件功能要满足顾客规定，在预定环境下可以完毕预期功能。因而，必要明确理解顾客需求。
在需求拟定方面，应通过深刻理解电信公司运营系统及理解其发展趋势，建立模型并分析，广泛理解其她系统特长，并总结以往经验教训基本上，拟定出需求并通过与顾客交流最后拟定。
在需求表达方面，强调以全面、精准、细致、易于理解方式表达，也许需要以各种形式，例如：功能描述、数据描述、数据流图、系统阐明等。
2. 可维护性
遵从统一规范，涉及命名规范、界面规范、编程风格。
编码应具备良好可读性，注释完整清晰。
避免复杂逻辑判断条件，易读，易测试
编码应尽量简洁，逻辑简朴
保存异常信息与错误日记以便于调试与分析
减少模块之间耦合度，增强模块内内聚。
3. 可用性
顾客容易理解和使用该功能
响应时间快，操作以便，提高顾客工作效率。
提示信息简洁精确
4. 可靠性
具备异常捕获功能并提供异常解决与恢复功能
   5、效率
尽量减少系统资源开销
查询语句要充分考虑到索引
减少与数据库不必要交互
6. 灵活性，易于扩展
充分考虑到各地不同环境，通过参数设立使其易于适应不同规定。
7. 完整性、安全性
保证有关数据一致性
考虑数据存取权限。
8. 文档完善
按文档规定完毕有关文档。

审查制度
   对于每一阶段文档及软件产品都应交付证质量保证部门，由审查小组按质量规定严格审查。
   审查内容：
· 文档：开发筹划、顾客需求规格阐明、概要及详细设计文档、技术文档、顾客手册等，详细规定见文档筹划。评审文档与否规范，表达清晰，有实用价值。
· 设计方案：与否达到设计目的。
· 应用程序：与否达到质量目的和符合设计目的。
审查流程：
1. 项目组按筹划准备好交付产品及文档
2. 交付质量保证部门，组织评审
3. 完毕评审，发现错误报告
4. 发现错误返工
5. 复查返工问题与否已解决