软件质量保证计划Word下载.docx

上传人:b****4 文档编号:16824787 上传时间:2022-11-26 格式:DOCX 页数:14 大小:61.62KB
下载 相关 举报
软件质量保证计划Word下载.docx_第1页
第1页 / 共14页
软件质量保证计划Word下载.docx_第2页
第2页 / 共14页
软件质量保证计划Word下载.docx_第3页
第3页 / 共14页
软件质量保证计划Word下载.docx_第4页
第4页 / 共14页
软件质量保证计划Word下载.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

软件质量保证计划Word下载.docx

《软件质量保证计划Word下载.docx》由会员分享,可在线阅读,更多相关《软件质量保证计划Word下载.docx(14页珍藏版)》请在冰豆网上搜索。

软件质量保证计划Word下载.docx

5.2概要设计评审4

5.3详细设计评审4

5.4软件验证与确认评审4

5.5功能检查4

5.6物理检查5

5.7综合检查5

5.8管理评审5

6软件配置管理5

7工具、技术和方法5

8媒体控制5

9对供货单位的控制6

10记录的收集、维护和保存6

11附录6

11.1附录A:

工程进展报表6

11.2附录B:

工程阶段评审表11

1引言

1.1目的

本条必须指出特定的软件质量保证方案的具体目的。

还必须指出该方案所针对的软件工程〔及其所属的各个子工程〕的名称和用途。

1.2定义和缩写词

应该列出方案正文中需要解释的而在GB/T11457中尚未包含的术语的定义,必要时,还要给出这些定义的英文单词及其缩写词。

1.3参考资料

列出要用到的参考资料,如:

a.本工程的经核准的方案任务书或合同、上级机关的批文;

b.属于本工程的其他已发表的文件;

c.本文件中各处引用的文件、资料,包括所要用到的软件开发标准。

列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

2管理

必须描述负责软件质量保证的机构、任务及其有关的职责。

2.1机构

必须描述与软件质量保证有关的机构的组成。

还必须清楚地描述来自工程委托单位、程承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的相互关系。

2.2任务

描述方案所涉及的软件生存周期中有关阶段的任务,特别要把重点放在描述这些阶段所应进展的软件质量保证活动上。

2.3职责

指明软件质量保证方案中规定的每一个任务的负责单位或成员的责任。

3文档

3.1根本文档

为了确保软件的实现满足需求,至少需要以下根本文档。

3.1.1软件需求规格说明书

软件需求规格说明书必须清楚、准确地描述软件的每一个根本需求〔功能、性能、设计约束和属性〕和外部界面。

必须把每一个需求规定成能够通过预先定义的方法〔例如检查、分析、演示或测试等〕被客观地验证与确认的形式。

软件需求规格说明书的详细格式按GB8567。

3.1.2软件设计说明书

软件设计说明书应该包括软件概要设计说明和软件详细设计说明两局部。

其概要设计局部必须描述所设计软件的总体构造、外部接口、各个主要部件的功能与数据构造以及各主要部件之间的接口性和时还必须对主要部件的每一个子部件进展描述。

其详细设计局部必须给出每一个根本部件的功能、算法和过程描述。

软件设计说明书的详细格式按GB8567。

3.1.3软件验证与确认方案

软件验证与确认方案必须描述所采用的软件验证和确认方法〔例如评审、检查、分析、演示或测试等〕,以用来验证软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现;

软件设计说明书表达的设计是否已由编码实现。

软件验证与确认方案还可用来确认编码的执行是否与软件需求规格说明书中所规定的需求相一致。

软件验证与确认方案的详细格式按GB8567中的测试方案的格式。

3.1.4软件验证与确认报告

软件验证与确认报告必须描述软件验证与确认方案的执行结果。

这里必须包括软件质量保证方案所需要的所有评审、检查和测试的结果。

软件验证与确认报告的详细格式按GB8567中的测试报告的格式。

3.1.5用户文档

用户文档〔例如手册、掼等〕必须指明成功运行该软件所需要的数据、控制命令以及运行条件等;

必须指明所有的出错信息、含义及其修改方法;

还必须描述将用户发现的错误或问题通知工程承办单位〔或软件开发单位〕或工程委托单位的方法。

用户文档的详细格式按GB8567。

3.2其他文档

除根本文档外,还应包括以下文档:

a.工程实施方案〔其中可包括软件配置管理方案,但在必要时也可单独制订该方案〕,其详细格式按GB8567。

b.工程进展报表:

其详细格式可参考本方案附录A中有关?

工程进展报表?

的各项规

定。

c.工程开发各阶段的评审报表:

其详细格式可参考本方案附录B中有关?

工程阶段评

审表?

的各项规定。

d.工程开发总结:

其详细格式按GB8567。

4标准、条例和约定

必须列出软件开发过程中要用到的标准、条例和约定,并列出监视和保证执行的措施。

5评审和检查

必须规定所要进展的技术和管理两方面的评审和检查工作,并编制或引用有关的评审和

检查规程以及通过与否的技术准那么。

至少要进展以下各项评审和检查工作:

5.1软件需求评审

在软件需求分析阶段完毕后必须进展软件需求评审,以确保在软件需求规格说明书中所规定的各项需求的适宜性。

5.2概要设计评审

在软件概要设计阶段完毕后必须进展概要设计评审,以评价软件设计说明书中所描述的软件概要设计在总体机构、外部接口、主要部件功能分配、全局数据构造以及各主要部件之间的接口等方面的适宜性。

5.3详细设计评审

在软件详细设计阶段完毕后必须进展详细设计评审,以确定软件设计说明书中所描述的详细设计在功能、算法和过程描述等方面的适宜性。

5.4软件验证与确认评审

在制订软件验证与确认方案之后要对它进展评审,以评价软件验证与确认方案中所规定的验证与确认方法的适宜性与完整性。

5.5功能检查

在软件释放前,要对软件进展检查,以确认已经满足在软件需求规格说明书中规定的所有需求。

5.6物理检查

在验收软件前,要对软件进展物理检查,以验证程序和文档已经一致并已做好了交付的准备。

5.7综合检查

在软件验收时,要允许用户或用户所委托的专家对所要验收的软件进展设计抽样的综合检查,以验证代码和设计文档的一致性、接口规格说明之间的一致性〔硬件和软件〕、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

5.8管理评审

要对方案的执行情况定期〔或按阶段〕进展管理评审;

这些评审必须由獐独立于被评审单位的机构或授权的第三方主持进展。

6软件配置管理

必须编制有关软件配置管理的条款,或引用按照GB/T12505单独制订的。

在这些条款或文档中,必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。

还必须规定用以维护和存储软件受控版本的方法和设施;

必须规定对所发现的软件问题进展报告、追踪和解决的步骤,并指出实现报告、追踪和解决软件问题的机构及其职责。

7工具、技术和方法

必须指明用以支持特定软件工程质量保证工作的工具、技术和方法,指出它们的目的,描述它们的用途。

8

媒体控制

9对供货单位的控制

供货单位包括工程承办单位、软件销售单位、软件开发单位或软件子开发单位。

必须规定对这些供货单位进展控制的规程,从而保证工程承办单位从软件销售单位购置的、其他开发单位〔或子开发单位〕开发的或从开发〔或子开发〕单位现存软件库中选用的软件能满足规定的需求。

10记录的收集、维护和保存

必须指明需要保存的软件质量保证活动的记录,并指出用于汇总、保护和维护这些记录的方法和设施,并指明要保存的期限。

11附录

工程进展报表

工程进展报表〔月报表或季报表〕由一个工程进展报表表头〔表A1〕和另外三个表格

〔表A2、表A3、表A4丨组成。

在表A2“软件阶段进度表'

’中,要填写各个阶段的开工日期与完毕日期。

其中方案进度是指在工程实施方案中确定的方案进度,因此可以由管理事先填好,而不必由开发人员填写。

实际进度是指该工程实际的开工日期与完毕日期,它将随着该工程的不断进度来填写。

其中调整进度是指工程组长发现实现进度与方案进度不符时提出的进度修改建议;

但经工程管理人员研究后,可能对此修改建议作某些更改。

此外,在相继的假设干次报表中,工程组长提出的建议修改日期也可能是不一样的。

在此我们规定,最终的调整进度由工程经理来确定。

在表A3“软件阶段产品完成情况表"

中,要填写各个文档的开场编写日期与完成日期。

其中关于对方案进度、调整进度与实际进度的含义的解释与上一样。

表A4是关于统计软件开发费用的表格。

工程名:

年月

子系统名称

模块名

填表人

填表日期

年月日

工程组长

开发单位

表A2软件阶段进度表

子系统名:

模块名:

统计日期:

年月日

阶段名称

方案进度

调整进度

实际进度

开工日期

完毕日期

SA&

SD

RA

PD

DD

CD&

UT

IT&

ST

IS&

AC

TSSD

注:

SA&

SD(systemanalysis&

softwaredefinitionphase):

系统分析与软件定义阶段。

RA(requirementsanalysisphase):

需求分析阶段。

PD(preliminarydesignphase):

概要设计阶段。

DD(detaileddesignphase):

详细设计阶段。

CD&

UT(coding&

unittestingphase):

编码与单元测试阶段。

IT&

ST(integrating&

systemtestingphase):

组装与系统测试阶段。

IS&

AC(installation&

acceptaneephase):

安装与验收阶段。

TSSD(totalsoftwaresystemdevelopmentphase):

整个软件系统的开发阶段。

表A3软件阶段产品完成情况表

子系统名:

文档名称

页数

备注

开场日期

完成日期

1工程实施方案

2需求规格说明书

3概要设计说明书

4详细设计说明书

5测试方案

6测试报告

7用户手册

8工程开发总结

9源代码清单

10质量保证方案

11配置管理方案

表A4软件开发费用统计表

统计区间:

日至

人工费用〔人月〕

机时〔小时〕

其他〔元〕

工程管理

系统分析

软件设计

编码调试

数据录入

其它人工

终端小时

主机小时

外存空间

其它费用

出差资料

其他费用

工程阶段评审表

在软件开发过程中的适当阶段对软件阶段产品进展评审,是确保软件产品最终质量的重要方法。

阶段评审可以对某个开发阶段的阶段产品进展评审,也可以对某几个开发阶段的阶段产品进展综合评审。

在每次阶段评审中,必须履行正式手续,填写必要的评审表格,以利于工程管理工作,利于产品验收时的质量检查工作。

工程阶段评审表由四张子表组成。

表B1是对评审中发现的问题的记录RPL(reviewproblemlog〕;

表B2是评审总结报表RSR(reviewsummaryreport);

表B3是对其中主要问题的详细描述SPR(softwareproblemreport);

表B4是评审小组成员登记与签字表。

下面给出这四张表的格式。

表B1评审问题记录〔RPL〕

RPL

评审问题记录

登记号

评审日期

评审性质

评审口复审口

工程名

子工程名

代号

编号

冋题摘要

问题类型

是否解决

1

2

3

4

5

6

7

9

10

表B2评审总结报告〔RSR〕

RSR

评审总结报告

阶段名

软件

定义

需求

分析

概要

设计

详细

编码

测试

组装

安装

验收

运行

维护

姓名

地址

评审任务

评审材料

评审结论

通过

不需修改

稍作修改

不通过

作重要修改

要重新评审

备注

表B3软件问题报告单〔SPR〕

子例行程序/子系统:

修改版本号:

媒体:

数据库:

文档:

测试实例:

硬件:

数据库口

例行程序口

程序口

文档口

改良口

问题:

问题描述/影响:

附注及修改建议:

表B4评审成员签字登记表〔RMT〕

评审小组成员

职务姓名职称

单位

签字

组长

副组长

成员

可以不设副组长;

此外,工程开发组长或其代表可以作为评审组的成员,但不能担任评审组的组长或副组长。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 成人教育 > 成考

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1