软件需求工程 高校教学平台 质量保证计划

点击查看 软件需求工程 高校教学平台 卷首语

简介

目的

本计划定义了高校教学平台软件质量保证（Software Quality Assurance，以下简称SQA）组织、任务及职责；提供SQA的参考文献及行动指南；提供执行SQA的标准、过程及相关的约定；并为执行SQA活动和SQA报告提供了工具、技术和方法。通过执行SQA计划，以保证高校教学平台软件达到安全完整度为4的要求。

范围

本计划适用于执行高校教学平台生命周期内的所有SQA活动。

本计划参考IEC 62279，SQA小组仅对项目负责人负责，独立于项目的软件开发组（包括软件设计开发组、软件测试组、软件验证组及与软件相关的其它项目组）。

SQA计划的目标是验证交付的软件和文件已满足所有的技术要求。本SQA计划中规定了审查所有交付的软件和文件所应遵循的技术和执行方面的要求。

本计划将根据高校教学平台软件项目进展情况，在项目的每个阶段开始前进行讨论，根据需要进行修订，修订工作由软件质量保证组完成。修订后更新版本号，以新版本替换上一版本。本计划经过修订发布后，修订前的软件质量保证计划同时废止，但可作为参考使用。

参考

应用文件

• 高校教学系统软件开发计划

• 高校教学系统软件管理计划

• 软件编码规范

• 软件修改流程

• 相关的国家/部委规定的行车安全管理办法

• 相关的供应商选择办法

参考文件

• ISO 9001:2000，质量管理体系要求

• IEEE-Std-730-1998, IEEE Standard for Software Quality Assurance Plans, June
  1998.

• IEEE-Std-730.1-1995, IEEE Guide for Software Quality Assurance Planning,
  December 1995.

• IEEE Std 610.12－1990（R2002），IEEE Standard Glossary of Software
  Engineering Terminology, September 2002.

• GB/T 16260-2006/ISO/IEC 9126:2001，软件工程 产品质量.

• ISO/IEC 90003, Software engineering- Guidelines for the application of ISO
  9001:2000 to computer software, February 2004.

定义与缩写

定义

• 质量保证quality assurance (QA)：(1) A planned and systematic pattern of
  all actions necessary to provide adequate confidence that an item or product
  conforms to established technical requirements. (2) A set of activities
  designed to evaluate the process by which products are developed or
  manufactured. Contrast with quality control

• 评审 review：A process or meeting during which a work product, or set of
  work products, is presented to project personnel, managers, users,
  customers, or other interested parties for comment or approval. Types
  include code review, design review, formal qualification review,
  requirements review, test readiness review.

缩写

• 软件质量保证（SQA） Software Quality Assurance

• 安全完整度等级（SIL） Safety Integrity Level

组织结构与职责

组织结构

在高校教学系统软件开发期间，必须成立软件质量保证小组负责质量保证工作。

软件质量保证组属软件开发组组长领导，由项目的软件开发组代表、项目的专职质量保证人员、软件验证组代表等方面的人员组成，由项目的质量保证组代表任组长。
软件质量保证组和软件质量保证人员必须检查和督促本计划的实施，软件质量保证人员有权直接向软件质量保证组报告软件质量状况。

职责

项目的软件质量保证小组中，其各方面人员的职责如下：

• 组长全面负责有关软件质量保证的各项工作

• 项目的软件开发组代表负责有关阶段评审及项目进展工作中的质量保证工作，负责有关软件配置变动、软件媒体控制以及对供货单位的控制等三方面的质量保证活动

• 软件验证组代表的主要工作是在控制单元软件开发的各阶段进行相关软件验证工作，以确保在每个阶段呈现的软件被较好地设计，被合理构造，没有不可接受的差错或缺陷，符合所有指定的要求和规程，具有可接受的质量，并协助检查软件质量保证计划的执行情况

• 项目的专职质量保证人员协助组长开展各项软件质量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责汇总、维护和保存有关软件质量保证活动的各项记录

• 软件质量保证组负责向软件确认组提供软件开发各阶段质量保证活动资料

软件质量保证的过程

阶段评审

在整个软件系统开发过程中，要定期地或阶段性地对软件进行评审。一般应该进行以下三次评审：第一次评审软件需求、软件结构设计；第二次评审软件模块设计、编码设计和软件测试，并对第一次评审结果复核；第三次评审软件测试、软/硬件集成测试的结果。

阶段评审工作要组织专门的评审小组，邀请质量保证小组组长担任评审组长，评审小组成员包括项目所有成员、模块质量保证人员以及项目委托单位。

每一次评审工作都应该填写设计评审申请表、设计评审意见汇总表、设计评审意见追踪处理记录表格，阶段评审报表的具体格式应与规定相一致。

日常检查

在项目软件开发过程中，软件开发组应该定期填写项目及子系统进展报表，即软件项目进展报表。软件质量保证小组通过项目进展报表检查有关软件质量保证过程控制的问题和模块的开发情况。

安装维护检查

本软件系统交付给用户的是可使用的系统，交付的软件是通过测试、验证，并确认满足软件需求说明书要求的软件。软件交付前，项目组应填写业务联系书，说明交付安装的软件的使用范围和方法。

软件安装维护阶段的质量保证通过对安装维护阶段的过程文件检查发现软件质量控制的问题，并针对问题进行相应处理。

文档

本部分中，列举出了在软件开发、测试、验证与确认以及使用与后期维护等阶段，需要编写并最终定稿的文档工作，同时列举出评判文档质量的度量标准。

基本文档

为保障软件的实现能够满足需求规格说明书中既定的各项需求，本软件开发项目组应当至少编写以下文档：

• 《软件需求规格说明书》

• 《软件设计说明书》（包括《概要设计说明书》和《详细设计说明书》）

• 《软件验证与确认计划》

• 《软件验证与确认报告》

• 《用户手册》

• 《源程序清单》

在此之外，还将根据实际需求，补充以下文档：

• 《项目实施计划》

• 《软件配置管理计划》

• 《项目进展报表》

• 《阶段评审报表》

• 《项目开发总结》

文档质量的度量准则

文档是软件开发流程中的重要组成部分，描述了软件生存周期中不同阶段的产品特性和开发进展。验证和确认在这当中发挥了检查各阶段文档合适性的作用，其中，根据《GB/T
12504-90 计算机软件质量保证计划规范》中的规定，评审文档质量的度量准则有以下六条：

1. 完备性：所有承担软件开发任务的项目，都必须按照GB 8567
   的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的。

2. 正确性：在软件开发各个阶段所编写的文档的内容，必须真实地反映该阶段的工作且与该阶段的需求相一致。

3. 简明性：在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练，适合各种文档的特定读者。

4. 可追踪性：在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性与横向可追踪性两个方面。前者是指在不同文档的相关内容之间相互检索的难易程度；后者是指确定同一文档某一内容在本文档中的涉及范围的难易程度。

5. 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。

6. 规范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。

标准、条例和约定

在工程化软件系统的开发过程中，还必须遵守以下相关标准、条例和约定：《软件配置管理计划》。

评审和检查

本章是本计划3.1部分的详细说明，具体规定了应该进行的阶段评审、阶段评审的内容要求。对新开发的或正在开发的各个子系统，都要根据GB 8566标准和《“高校教学平台”软件设计评审办法》进行各项评审工作，评审的时间安排应根据项目的进展情况而定。就整个教学平台的开发过程而言，至少要进行软件需求评审、软件结构设计评审、详细设计（包括架构设计、模块设计和编码三个阶段）评审、软件测试及软硬件集成等五个方面的评审和检查工作。在每次评审前，应确定阶段文档度量已满足设定的度量值要求，否则不得申请评审。

每项评审应由评审申请人填写《设计评审申请表》，明确评审输入及项目负责人对评审的要求与建议，所有的评审和检查过程依照《“高校教学平台”软件设计评审办法》执行。如本计划3.1条所述，在每次评审之后要填写《设计评审意见汇总表》，对评审结果做出明确的管理决策，并填写《设计评审意见追踪处理记录》对评审问题的处理进行跟踪验证。综合考量各方面的因素，本计划将评审分为以下三个阶段：

1. 第一次评审

   第一次评审主要包括软件需求评审、概要设计评审以及软件验证和确认评审。

• 软件需求评审

  应评价软件需求满足系统需求规格说明书中规定的各项需求及IEC 62279中8.4要求，确保各项需求的合理性。

• 概要设计评审

  应评价软件设计说明书中的软件概要设计的技术合适性，同时评价软件是否满足IEC 62279中9.4要求。

• 软件验证和确认评审

  应评价软件验证计划中确定的验证方法的合适性与完整性，评价验证及测试是否满足IEC 62279中11.4要求。

2. 第二次评审

   第二次评审包括详细设计评审、功能测试与演示评审，并对第一次评审结果进行复核。如果再软件开发过程中发现需要修改的第一次评审结果，则应按照《软件配置管理计划》的规定处理。

• 详细设计评审

  应确定软件设计说明书中的详细设计在满足软件需求规格说明书中所描述的详细设计在功能、算法和过程描述等方面的合适性。

• 功能测试与演示评审

  应对所有的程序单元进行静态分析，检查其程序结构（即类之间的依赖关系以及模块和函数的调用关系和调用序列等）和变量使用是否正确。在通过静态分析后，再进行结构测试和功能测试。在结构测试中，所有程序单元结构测试的语句覆盖率C0必须等于100%，分支覆盖率C1必须大于或等于85%。要给出每个单元的输入和输出变量的变化范围，包括函数内部局部变量的变化范围等。各个子系统只进行功能测试，不单独进行结构测试，因而要登录程序单元之间接口的变量值，力图使满足单元测试的C1和C0准则的那些测试用例在子系统功能测试时得到再现。

• 测试工作评审

  应检查所进行的测试工作是否满足上述要求。特别在评审功能测试工作时，不仅要运行变量的等价值，而且要运行变量的边界值；不仅要运行开发组给出的测试用例，而且要允许运行其他相关人员（用户代言人、业界人士等）、评审人员选定的采样用例。

3. 第三次评审

   第三次评审要进行软硬件集成评审、功能检查、物理检查和综合检查。这些评审应在集成测试阶段结束后进行。

• 软硬件集成评审

  应评价软硬件之间的相容性是否满足安全系统的需求规格说明书和预期软件完善度等级要求，同时评价软硬件间的相互作用是否能够正确达到预定的功能。评价是否IEC
  62279中12.4的要求。

• 功能检查

  应确认所开发的软件已满足在软件需求规格说明书中规定的所有需求。

• 物理检查

  应验证程序和文档已经一致、并已做好了交付的准备。

• 综合检查

  应验证代码和设计文档的一致性、接口规格说明之间的一致性（软件和硬件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

软件配置管理

对高校教学平台的各项配置进行及时、合理的管理，是确保软件质量的重要手段。有关工程化软件的配置管理工作，可按软件项目组编写的《软件配置管理计划》。在软件配置管理工作中，要特别注意规定对软件问题报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

工具、技术和方法

开发工具及编程语言

在高校教学平台的开发过程中，应该在对应的软件质量保证活动中合理地使用软件质量保证活动中合理地使用软件质量支持工具、技术和方法。

开发工具我们采用PyCharm, WebStorm等IDE，编程语言我们使用Python, HTML,
JavaScript等。前端使用Vue.js框架，后端使用Django框架。

测试工具

模块的静态分析、结构测试与功能测试能用C语言编写，主要功能是协助测试人员判断程序结构与变量使用的情况是否出错；提出功能测试的有效情况协助最终交付给用户的有效测试用例。

配置管理工具

配置管理工具支持对用户源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户有不同文档相关内容之间进行相互检索并确定同一文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

故障报告工具

故障报告工具能够对故障进行报告和分析，并且将纠正措施反馈到设计、生产、试验过程中。同时，可以跟踪、评审故障分析以及纠正措施状况的制度，有关故障的文件记录的规定。

媒体控制

• 控制目的：保护计算机程序的物理媒体，避免非法存取、意外损坏或自然老化等问题

• 控制方法：设置软件配置管理人员管理媒体

在本项目中，我们为高校教学平台的各个子系统及其支持软件设立软件配置管理人员，并按照《软件配置管理计划》妥善管理和存放各个子系统及其专用支持软件的媒体。

供应商控制

高校教学平台的各个子系统开发组，在使用以下四个方式选用软部件时，应遵循一定的流程。

• 方式一：从软件销售单位购买

• 方式二：委托其他开发单位开发

• 方式三：从开发单位现存软件库中选用

• 方式四：从项目委托单位或用户的现有软件库中选用软部件

流程为：

图10-1 供应商控制流程图

如果只选用其中部分内容，则按待开发软件的处理过程办理。

记录收集、维护和保存

• 目的：在高校教学平台及其所属的各个子系统的研制与开发期间进行各种软件质量保证活动，需要保证软件质量

• 方法：准确记录、及时分析并妥善保存有关这些软件质量保证活动的记录；在软件质量保证小组中设置专人负责收集、汇总与保存有关软件质量保证活动的记录。

需要收集、汇总与保存的记录名称如下，其保存的期限均涉及了全部过程：

表11-1 收集、汇总与保存记录表

记录类别	记录名称	保存期限
阶段评审记录	阶段评审总结	整个软件开发周期
	阶段评审问题	整个软件开发周期
	阶段评审成员	整个软件开发周期
日常检查记录	软件阶段进度表	整个软件开发周期
	软件阶段产品完成情况	整个软件开发周期
	软件开发费用统计表	整个软件生存周期
修改记录	软件问题报告单	整个软件生存周期
	软件问题修改单	整个软件生存周期
组织记录	软件质量保证小组成员表	整个软件开发周期