软件质量保证计划.docx

软件质量保证计划.docx

《软件质量保证计划.docx》由会员分享，可在线阅读，更多相关《软件质量保证计划.docx（7页珍藏版）》请在冰豆网上搜索。

软件质量保证计划

软件质量保证计划

版本记录

版本号

日期

修改章节

修改内容及说明

编制者

XXXXXXXX

编制者

审核者

项目负责人：

1.简介5

1.1.系统介绍5

1.2.文档目的5

1.3.范围5

1.4.与其它开发任务/文档的关系5

1.5.术语和缩写词6

2.参考文档7

3.软件SIL目标8

4.软件开发生命周期9

5.角色，职责和独立性10

5.1.组织结构、角色和职责10

5.2.独立性10

5.3.人员资质和培训10

6.软件质量管理11

6.1.软件配置管理11

6.2.文档质量11

6.3.可追溯性11

6.4.变更控制流程11

6.5.缺陷管理流程12

6.6.COTS管理流程12

6.7.软件验证和确认12

7.软件生命周期活动13

7.1.软件需求规范阶段13

7.2.软件结构设计阶段13

7.3.软件详细设计阶段13

7.4.软件编码阶段13

7.5.软件测试阶段13

7.6.软硬件集成阶段13

7.7.软件确认阶段14

1.简介

1.1.系统介绍

提示：

对系统进行简要介绍，包括系统的安全目标，安全评估的类型等。

1.2.文档目的

提示：

描述和介绍本计划的主要内容、目的及适用范围。

例如：

本软件质量保障计划是根据系统安全计划制定。

计划规定了本系统软件开发过程中所需要遵循的流程和采取的技术措施，目的是降低软件开发过程中人为错误的影响，提高软件的质量，确保软件达到要求的软件安全完整度等级。

软件开发者、测试者等相关人员在软件生命周期中，应贯彻执行本计划中的有关规定。

1.3.范围

本软件质量保障计划适用于xxxx系统的软件生命周期的全过程，包括软件需求、设计、测试、确认、维护。

1.4.与其它开发任务/文档的关系

提示：

如需求和设计文档的关系

1.5.术语和缩写词

提示：

列出项目文档的专用术语和缩写词。

以便阅读时，使读者明确，从而不产生歧义。

2.参考文档

提示：

列出本文档引用的所有标准、文档及其版本号例如：

项目安全计划

3.软件SIL目标

提示：

描述软件要达到的安全完整度等级

软件的安全完整度等级应不低于系统安全完整度，软件安全完整度等级也需要在软件需求规范中明确定义。

如果软件系统中存在不同安全完整度等级的模块，需要在软件结构设计中说明。

如果不能证明不同模块之间的独立性，那么所有模块都应按最高安全完整度对待。

4.软件开发生命周期

提示：

描述软件开发生命周期的阶段划分，简单介绍各阶段的工作

5.角色，职责和独立性

5.1.组织结构、角色和职责

提示：

描述软件相关的组织结构、角色和各自的职责。

在《项目安全计划》中已经确定项目的组织结构和职责，这里详细描述软件相关的，如开发、测试、确认、评估等。

应将不同人员角色所对应的具体人员姓名明确出来。

5.2.独立性

提示：

描述开发、测试、确认以及评估的独立性

5.3.人员资质和培训

提示：

分类描述软件相关人员的资质要求和培训计划。

6.软件质量管理

6.1.软件配置管理

提示：

在软件生命周期内应对各阶段的配置项进行标识、控制、审核及管理。

配置项包括技术文档和程序等。

6.2.文档质量

提示：

描述保障文档质量要遵循的原则。

例如：

所有文档都需要结构分明并具有良好的可读性。

应有一个变更历史清单。

每层文档必须传承上层文档的应用条件和需求，每级文档都不能与其上层文档相抵触。

每一个缩略语、专有名词在所有文档中应具有相同的含义。

不同的文档在引用相同概念或部件时应使用同样的字语。

根据本系统软件的复杂度在不牺牲内容细节的情况下可以决定软件文档的拆分与合并。

不同职责人员产生的文档不能合并。

6.3.可追溯性

提示：

描述如何实现需求的可追溯性，主要包括：

软件需求与系统需求的追踪性；软件需求和软件设计的追溯性；软件需求和软件测试案例的追溯性等。

6.4.变更控制流程

提示：

描述软件的变更控制流程。

引起变更的因素有两个：

一是来自外部的变更要求，如客户要求修改工作范围和需求等；二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改设计甚至需求。

实施变更的四个重要控制点：

授权（规定有权提出变更申请的人员和有权

受理变更的人员）、审核（决定是否需要修改、怎么修改和什么时候修改）、

评估（评估变更的代价和对项目的影响）和确认（由谁确认是否接受变更）；在实施过程要进行跟踪和验证，确保变更被正确执行。

6.5.缺陷管理流程

提示：

[应有一个具体的流程，包括以下内容：

确定问题报告和/或纠正行动所需要的文件，目的是为负责的管理层提供反馈；

确定对问题报告中所收集的信息的分析，以识别其原因；

确定要遵循的惯例，以报告、跟踪和分析开发阶段和软件维护阶段所识别的问题；

在一个水平上确定处理问题的预防性活动，该水平对应于所要求的软件安全完整性水平；

确定在开发和软件维护方面的特殊的组织责任；确定如何实施控制，以确保已采取了纠正性行动，并且这些行动是有效的；

确定所要采取的形式；

确定重新测试、重新确认、重新验证和重新评估的要求。

]

6.6.COTS管理流程

提示：

COTS的管理参考EN50128。

6.7.软件验证和确认

提示：

参见系统的验证计划、确认计划。

7.软件生命周期活动

7.1.软件需求规范阶段

提示：

描述软件需求阶段的活动，需要采用的技术措施，以及阶段输出

7.2.软件结构设计阶段

提示：

描述软件结构设计阶段的活动，需要采用的技术措施，以及阶段输

出，输出文档应描述清楚编写者是谁。

7.3.软件详细设计阶段

提示：

描述软件详细设计阶段的活动，需要采用的技术措施，以及阶段输

出，输出文档应描述清楚编写者是谁。

7.4.软件编码阶段

提示：

描述软件编码阶段的活动，需要采用的技术措施，以及阶段输出，

输出文档应描述清楚编写者是谁。

7.5.软件测试阶段

提示：

描述软件测试阶段的活动，需要采用的技术措施，以及阶段输出，

输出文档应描述清楚编写者是谁。

7.6.软硬件集成阶段

提示：

描述软硬件集成测试阶段的活动，需要采用的技术措施，以及阶段

输出，输出文档应描述清楚编写者是谁。

7.7.软件确认阶段

提示：

描述软件确认阶段的活动，需要采用的技术措施，以及阶段输出，输出文档应描述清楚编写者是谁。