软件质量保证计划(共17页).doc

《软件质量保证计划(共17页).doc》由会员分享，可在线阅读，更多相关《软件质量保证计划(共17页).doc（18页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、精选优质文档-倾情为你奉上案卷号日期项目名称软件质量保证计划 作 者： 完成日期： 签 收 人： 签收日期： 修改情况记录：版本号修改批准人修改人安装日期签收人 目录 1 引言11.1 目的11.2 定义和缩写词11.3 参考资料12 管理12.1 机构12.2 任务22.3 职责23 文档23.1 基本文档23.1.1 软件需求规格说明书23.1.2 软件设计说明书23.1.3 软件验证与确认计划33.1.4 软件验证与确认报告33.1.5 用户文档33.2 其他文档34 标准、条例和约定45 评审和检查45.1 软件需求评审45.2 概要设计评审45.3 详细设计评审45.4 软件验证与确

2、认评审45.5 功能检查45.6 物理检查55.7 综合检查55.8 管理评审56 软件配置管理57 工具、技术和方法58 媒体控制69 对供货单位的控制610 记录的收集、维护和保存611 附录611.1 附录A：项目进展报表611.2 附录B：项目阶段评审表11专心-专注-专业1 引言1.1 目的 本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目（及其所属的各个子项目）的名称和用途。1.2 定义和缩写词应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义，必要时，还要给出这些定义的英文单词及其缩写词。1.3 参考资料列出要用到的参考资料，

3、如：a 本项目的经核准的计划任务书或合同、上级机关的批文；b 属于本项目的其他已发表的文件；c 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2 管理必须描述负责软件质量保证的机构、任务及其有关的职责。2.1 机构必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的相互关系。2.2 任务描述计划所涉及的软件生存周期中有关阶段的任务，特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。2.3 职责指明软件质

4、量保证计划中规定的每一个任务的负责单位或成员的责任。3 文档3.1 基本文档为了确保软件的实现满足需求，至少需要下列基本文档。3.1.1 软件需求规格说明书软件需求规格说明书必须清楚、准确地描述软件的每一个基本需求（功能、性能、设计约束和属性）和外部界面。必须把每一个需求规定成能够通过预先定义的方法（例如检查、分析、演示或测试等）被客观地验证与确认的形式。软件需求规格说明书的详细格式按GB 8567。3.1.2 软件设计说明书软件设计说明书应该包括软件概要设计说明和软件详细设计说明两部分。其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口

5、性和时还必须对主要部件的每一个子部件进行描述。其详细设计部分必须给出每一个基本部件的功能、算法和过程描述。软件设计说明书的详细格式按GB 8567。3.1.3 软件验证与确认计划软件验证与确认计划必须描述所采用的软件验证和确认方法（例如评审、检查、分析、演示或测试等），以用来验证软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现；软件设计说明书表达的设计是否已由编码实现。软件验证与确认计划还可用来确认编码的执行是否与软件需求规格说明书中所规定的需求相一致。软件验证与确认计划的详细格式按GB 8567中的测试计划的格式。3.1.4 软件验证与确认报告软件验证与确认报告必须描述软件验证

6、与确认计划的执行结果。这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果。软件验证与确认报告的详细格式按GB 8567中的测试报告的格式。3.1.5 用户文档用户文档（例如手册、掼等）必须指明成功运行该软件所需要的数据、控制命令以及运行条件等；必须指明所有的出错信息、含义及其修改方法；还必须描述将用户发现的错误或问题通知项目承办单位（或软件开发单位）或项目委托单位的方法。用户文档的详细格式按GB 8567。3.2 其他文档除基本文档外，还应包括下列文档：a 项目实施计划（其中可包括软件配置管理计划，但在必要时也可单独制订该计划），其详细格式按GB 8567。b 项目进展报表：其详细

7、格式可参考本计划附录A中有关项目进展报表的各项规定。c 项目开发各阶段的评审报表：其详细格式可参考本计划附录B中有关项目阶段评审表的各项规定。d 项目开发总结：其详细格式按GB 8567。4 标准、条例和约定必须列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施。5 评审和检查必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程以及通过与否的技术准则。至少要进行下列各项评审和检查工作：5.1 软件需求评审在软件需求分析阶段结束后必须进行软件需求评审，以确保在软件需求规格说明书中所规定的各项需求的合适性。5.2 概要设计评审在软件概要设计阶段结

8、束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体机构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。5.3 详细设计评审在软件详细设计阶段结束后必须进行详细设计评审，以确定软件设计说明书中所描述的详细设计在功能、算法和过程描述等方面的合适性。5.4 软件验证与确认评审在制订软件验证与确认计划之后要对它进行评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。5.5 功能检查在软件释放前，要对软件进行检查，以确认已经满足在软件需求规格说明书中规定的所有需求。5.6 物理检查在验收软件前，要对软件进行物理 检查，以验证程

9、序和文档已经一致并已做好了交付的准备。5.7 综合检查在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。5.8 管理评审要对计划的执行情况定期（或按阶段）进行管理评审；这些评审必须由獐独立于被评审单位的机构或授权的第三方主持进行。6 软件配置管理必须编制有关软件配置管理的条款，或引用按照GB/T 12505单独制订的。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四

10、方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。7 工具、技术和方法必须指明用以支持特定软件项目质量保证工作的工具、技术和方法，指出它们的目的，描述它们的用途。8 媒体控制必须指出保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化。9 对供货单位的控制供货单位包括项目承办单位、软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位（或子开发单位）开发的或从开发（或子开发）单位现存

11、软件库中选用的软件能满足规定的需求。10 记录的收集、维护和保存必须指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限。11 附录11.1 附录A：项目进展报表项目进展报表（月报表或季报表）由一个项目进展报表表头（表A1）和另外三个表格（表A2、表A3、表A4）组成。在表A2“软件阶段进度表”中，要填写各个阶段的开工日期与结束日期。其中计划进度是指在项目实施计划中确定的计划进度，因此可以由管理事先填好，而不必由开发人员填写。实际进度是指该项目实际的开工日期与结束日期，它将随着该项目的不断进度来填写。其中调整进度是指项目组长发现实现进度与计划

12、进度不符时提出的进度修改建议；但经项目管理人员研究后，可能对此修改建议作某些更改。此外，在相继的若干次报表中，项目组长提出的建议修改日期也可能是不相同的。在此我们规定，最终的调整进度由项目经理来确定。在表A3“软件阶段产品完成情况表”中，要填写各个文档的开始编写日期与完成日期。其中关于对计划进度、调整进度与实际进度的含义的解释与上相同。表A4是关于统计软件开发费用的表格。表A1 项目进展报表表头项目名： 年 月子系统名称模块名填表人填表日期 年 月 日项目组长开发单位表A2 软件阶段进度表子系统名： 模块名： 统计日期： 年 月 日阶段名称计划进度调整进度实际进度备 注开工日期结束日期开工日期

13、结束日期开工日期结束日期SASDRAPDDDCDUTITSTISACTSSD注：SA&SD(system analysis & software definition phase)：系统分析与软件定义阶段。 RA(requirements analysis phase)：需求分析阶段。 PD(preliminary design phase)：概要设计阶段。 DD(detailed design phase)：详细设计阶段。 CD&UT(coding & unit testing phase)：编码与单元测试阶段。 IT&ST(integrating & system testing phas

14、e)：组装与系统测试阶段。 IS&AC(installation & acceptance phase)：安装与验收阶段。 TSSD(total software system development phase)：整个软件系统的开发阶段。表A3 软件阶段产品完成情况表子系统名： 模块名： 统计日期： 年 月 日文档名称计划进度调整进度实际进度页数备 注开始日期完成日期开始日期完成日期开始日期完成日期1 项目实施计划2 需求规格说明书3 概要设计说明书4 详细设计说明书5 测试计划6 测试报告7 用户手册8 项目开发总结9 源代码清单10 质量保证计划11 配置管理计划表A4 软件开发费用统计

15、表子系统名： 模块名： 统计区间：从 年 月 日至 年 月 日阶段名称人工费用（人月）机时（小时）其他（元）项目管理系统分析软件设计编码调试数据录入其它人工终端小时主机小时外存空间其它费用出差资料其他费用SASDRAPDDDCDUTITSTISACTSSD11.2 附录B：项目阶段评审表在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。阶段评审可以对某个开发阶段的阶段产品进行评审，也可以对某几个开发阶段的阶段产品进行综合评审。在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。项目阶段评审表由四张子表组成。

16、表B1是对评审中发现的问题的记录RPL(review problem log）；表B2是评审总结报表RSR(review summary report)；表B3是对其中主要问题的详细描述SPR(software problem report)；表B4是评审小组成员登记与签字表。下面给出这四张表的格式。表B1 评审问题记录（RPL）RPL评 审 问 题 记 录登记号评审日期 年 月 日评审性质评审 复审项目名子项目名代号编号问题摘要问题类型是否解决12345678910表B2 评审总结报告（RSR）RSR评审总结报告登记号评审日期 年 月 日评审性质评审 复审项目名子项目名代号阶段名软件定义需求

17、分析概要设计详细设计编码测试组装测试安装验收运行维护项目组长姓名电话地址评审任务评审材料评审结论通过不需修改稍作修改不通过作重要修改要重新评审备注表B3 软件问题报告单（SPR）软件问题报告单登记号登记日期 年 月 日发现日期 年 月 日项目名子项目代号阶段名软件定义需求分析概要设计详细设计编码测试组装测试安装验收运行维护状态123报告人姓名电话地址问题： 例行程序 程序 数据库 文档 改进子例行程序/子系统：修改版本号：媒体：数据库：文档：测试实例：硬件： 问题描述/影响： 附注及修改建议：表B4 评审成员签字登记表（RMT）评审小组成员职务姓名 职称单位签字组长副组长成员成员成员成员成员成员成员成员成员成员成员成员成员注：可以不设副组长；此外，项目开发组长或其代表可以作为评审组的成员，但不能担任评审组的组长或副组长。