系统软件质量保证计划设计文件

1、名称xxx系统软件质量保证计划代号版本.历史记录版本号说 明日 期作 者目 次1简介31.1目的31.2范围31.3参考31.4定义与缩写42组织结构与职责42.1组织结构42.2职责53软件质量保证的过程53.1阶段评审73.2日常检查73.3安装维护检查74文档74.1基本文档74.2文档质量的度量准则85标准、条例和约定96评审和检查97软件配置管理108工具、技术和方法108.1开发工具及编程语言108.2测试工具108.3配置管理工具108.4故障报告工具109媒体控制1010供应商控制1111记录收集、维护和保存111 简介1.1 目的本计划定义了xxx控制单元软件质量保证（sof

2、tware quality assurance，以下简称sqa）组织、任务及职责；提供sqa的参考文献及行动指南；提供执行sqa的标准、过程及相关的约定；并为执行sqa活动和sqa报告提供了工具、技术和方法。通过执行sqa计划，以保证xxx控制单元软件达到安全完整度为4的要求。1.2 范围本计划适用于执行xxx控制单元生命周期内的所有sqa活动。本计划参考iec 62279、遵循xxx公司（以下简称xxx）质量管理体系文件进行编制，并作为xxxsqa对质量管理体系文件的补充。本计划中，sqa小组仅对项目负责人负责，独立于项目的软件开发组（包括软件设计开发组、软件测试组、软件验证组及与软件相关的

3、其它项目组）。sqa计划的目标是验证交付的软件和文件已满足所有的技术要求。本sqa计划中规定了审查所有交付的软件和文件所应遵循的技术和执行方面的要求。本计划将根据xxx控制单元软件项目进展情况，在项目的每个阶段开始前进行讨论，根据需要进行修订，修订工作由软件质量保证组完成。修订后更新版本号，以新版本替换上一版本。本计划经过修订发布后，修订前的软件质量保证计划同时废止，但可作为参考使用。1.3 参考1.3.1 应用文件a） xxx公司股份有限公司质量管理体系文件, b） xxx系统控制单元软件开发计划c） xxx系统控制单元软件配置管理计划d） xxx系统控制单元软件维护计划e） 软件编码规范f

4、） 软件修改流程g） 相关的国家/ 部委规定的行车安全管理办法h） 相关的供应商选择办法1.3.2 参考文件a） iso 9001:2000，质量管理体系 要求b） ieee-std-730-1998, ieee standard for software quality assurance plans, june 1998.c） ieee-std-730.1-1995, ieee guide for software quality assurance planning, december 1995.d） ieee std 610.121990（r2002），ieee standard gl

5、ossary of software engineering terminology, september 2002.e） iec 62279, railway applications communications, signaling and processing systems software for railway control and protection systems, september 2002.f） gb/t 16260-2006/iso/iec 9126:2001，软件工程 产品质量.g） iso/iec 90003, software engineering- gu

6、idelines for the application of iso 9001:2000 to computer software, february 2004.1.4 定义与缩写 definitions and abbreviations1.4.1 定义质量保证quality assurance (qa)： (1) a planned and systematic pattern of all actions necessary to provide adequateconfidence that an item or product conforms to established tec

7、hnical requirements.(2) a set of activities designed to evaluate the process by which products are developed or manufactured. contrastwith: quality control (1).评审 review：a process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, cus

8、tomers, or other interested parties for comment or approval. types include code review, design review, formal qualification review, requirements review, test readiness review.1.4.2 缩写软件质量保证（sqa） software quality assurance安全完整度等级（sil） safety integrity level2 组织结构与职责2.1 组织结构图1 软件质量保证组组织结构图在xxx控制单元软件开发

9、期间，必须成立软件质量保证小组负责质量保证工作。软件质量保证组属软件开发组组长领导，由项目的软件开发组代表、项目的专职质量保证人员、软件验证组代表等方面的人员组成，由项目的质量保证组代表任组长。软件质量保证组和软件质量保证人员必须检查和督促本计划的实施，软件质量保证人员有权直接向软件质量保证组报告软件质量状况。2.2 职责项目的软件质量保证小组中，其各方面人员的职责如下：a） 组长全面负责有关软件质量保证的各项工作； b） 项目的软件开发组代表负责有关阶段评审及项目进展工作中的质量保证工作，负责有关软件配置变动、软件媒体控制以及对供货单位的控制等三方面的质量保证活动； c） 软件验证组代表的主

10、要工作是在控制单元软件开发的各阶段进行相关软件验证工作，以确保在每个阶段呈现的软件被较好地设计，被合理构造，没有不可接受的差错或缺陷，符合所有指定的要求和规程，具有可接受的质量，并协助检查软件质量保证计划的执行情况；d） 项目的专职质量保证人员协助组长开展各项软件质量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责汇总、维护和保存有关软件质量保证活动的各项记录。e） 软件质量保证组负责向软件确认组提供软件开发各阶段质量保证活动资料。3 软件质量保证的过程软件质量保证工作涉及软件生命周期各阶段的活动，应该贯彻到软件生命周期各阶段活动中，而且应该特别注意软件开发活动的早期评审工作。软件生

11、命周期模型见图2。图2 软件生命周期模型在软件项目进展过程中，软件质量保证小组应根据软件项目的进展开展软件项目评审工作。一般来说，每阶段的评审工作应在阶段开发工作完成后的两周内完成。因此，对新开发的或正在开发的各子系统，要按照本计划的各项规定进行评审工作。软件开发过程中，如需复用已有的软件模块，应对复用的软件模块进行评审，复用软件模块的评审与新开发的软件子系统评审要求相同。软件质量保证组要派成员参加所有的评审与检查活动，评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量，质量评审活动根据xxx公司产品/软件设计评审办法执行。在xxx控制单元项目

12、软件开发过程中，要进行如下几类评审与检查工作： 3.1 阶段评审在软件开发过程中，要定期地或阶段性地对软件进行评审。一般应该进行以下三次评审：第一次评审软件需求、软件结构设计；第二次评审软件模块设计、编码设计、软件测试，并对第一次评审结果复核；第三次评审软件测试、软/硬件集成测试的结果。关于这些评审工作的详细内容见第6部分。 阶段评审工作要组织专门的评审小组，原则上由项目组成员或特邀专家担任评审组长，评审小组成员应该包括软件验证组代表、质量保证人员和软件设计开发组人员，其他参加人员视评审内容而定。 每一次评审工作都应填写设计评审申请表、设计评审意见汇总表、设计评审意见追踪处理记录表格，阶段评审

13、报表的具体格式应与规定相一致。 3.2 日常检查在项目软件的开发过程中，软件开发组应该定期填写项目及子系统进展报表，即软件项目进展报表。软件质量保证组以通过项目进展报表发现有关软件质量保证过程控制的问题。项目进展报表的具体格式见表1。3.3 安装维护检查xxx控制单元软件交付给用户的是可执行的二进制文件，交付的软件应是通过测试、验证，并确认满足软件需求说明书要求的软件。软件交付前，xxx项目组应填写业务联系书，说明交付安装的软件的版本号、使用范围，并将交付的软件以只读的方式作为业务联系书的附件一同发布。业务联系书应按流程签审，软件安装应符合铁路机车行车安全装备管理规则要求。在软件维护阶段，软件

14、的质量保证按xxx控制单元软件维护计划、xxx软件修改流程执行。软件安装维护阶段的质量保证通过对安装维护阶段的过程文件检查发现有关软件质量控制的问题，发现的问题通过填写不符合项报告单跟踪处理。4 文档4.1 基本文档 为了确保软件的实现满足系统需求说明书各项需求，软件开发小组应该编写以下文档，各文档应符合iec 62279的有关要求： a） 软件需求规范 software requirements specification（srs）b） 软件需求测试规范 software requirements test specification (srts)c） 软/硬件集成测试计划 software

15、/hardware integration test plan (sw/hwitp)d） 软件结构说明书 software architecture specification (sas)e） 软件集成测试计划 software integration test plan (sitp)f） 软件设计说明书 software design specification (sds)g） 软件模块设计说明书 software module design specification (smds)h） 软件模块测试说明书 software module test specification (smts)i

16、） 软件源代码 software source code (ssc)j） 软件模块测试报告 software module test report (smtr)k） 软件集成测试报告 software integration test report (sitr)l） 软/硬件集成测试报告 software/hardware integration test report (sw/hwitr)m） 软件确认报告 software validation report (svar)4.2 文档质量的度量准则 文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。参考iso/iec 9126

17、，每个文档（文档清单见表2、表3所述文档清单）的度量准则可分别以内部质量、外部质量及使用质量来度量。xxx控制单元软件为嵌入式软件，只能在指定的应用环境（xxx）下使用，不考虑软件的可移植性。由于xxx处于研发阶段，暂不考虑使用质量中的有效性、生产率、满意度三个子特性。因此，评审文档内部质量、外部质量和使用质量的度量准则有以下六项： a） 功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。b） 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。 c） 易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。d） 效率：在规定条件下，相对于

18、所用资源的数量，软件产品可提供适当性能的能力。 e） 维护性：软件产品可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规格说明变化的适应。f） 安全性：软件产品在指定使用环境下，达到对人类、业务、软件、财产或环境造成损害的可接受的风险级别的能力。各文档根据所处的阶段不同，存在不同的质量需求。每个文档所具备的特性及子特性见表2及表3。根据定义的文档特性，每个文档应该根据文档具备的特性确定度量表（见表4），并质量测量表（见表5）。为了满足系统安全完整度等级为4的要求，根据iec 62279的有关要求，在进行特性及子特性度量时选用适当的度量级别。只有在经过测量的实际结果满足度量要求时，

19、才可以确定所度量的文档符合要求。5 标准、条例和约定xxx系统控制单元软件的开发过程中，还必须遵守下列标准、条例和约定：软件编码规范6 评审和检查本章是本计划3.1部分的详细说明，具体规定了应该进行的阶段评审、阶段评审的内容要求。对新开发的或正在开发的各个子系统，都要根据xxx公司产品/软件设计评审办法进行各项评审工作，评审的时间安排应根据项目的进展情况而定。就整个软件开发过程而言，至少要进行软件需求评审、软件结构设计评审、详细设计（包括设计、模块设计和编码三个阶段）评审、软件测试及软/硬件集成等五个方面的评审和检查工作。在每次评审前，应确定阶段文档度量已满足设定的度量值要求，否则不得申请评审

20、。每项评审应由评审申请人填写设计评审申请表，明确评审输入及项目负责人对评审的要求与建议，所有的评审和检查过程依照xxx公司产品/软件设计评审办法执行。如本计划第3.1条所述，在xxx控制单元软件开发过程中，在每次评审之后，要填写设计评审意见汇总表，对评审结果作出明确的管理决策，并填写设计评审意见追踪处理记录对评审问题的处理进行跟踪验证。下面给出每项评审应该进行的主要工作：a） 软件需求评审：应评价软件需求满足系统需求规格说明书中规定的各项需求及iec 62279中8.4要求。b） 软件结构设计评审：应评价软件设计说明书中的软件结构设计的技术合适性，同时评价软件是否满足iec 62279中9.4

21、要求。c） 设计评审：应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性,评价所有编码采用规定的工作语言，能在规定的运行环境中运行，满足软件编码规范总则。同时评价是否满足iec 62279中10.4要求。 d） 软件验证及测试评审：应评价软件验证计划中确定的验证方法的合适性与完整性，评价验证及测试是否满足iec 62279中11.4要求。 e） 软/硬件集成评审：应评价软/硬件之间的相容性是否满足安全性系统的需求规格说明书和预期软件完善度等级要求，同时评价软/硬件间的相互作用是否能够正确达到预定的功能。评价是否满足iec 62279中12.4要求。7 软件配置管理对

22、xxx控制单元软件的各项配置进行及时、合理的管理，是确保软件质量的重要手段，也是确保该软件具有强大生命力的重要措施。有关xxx控制单元软件的配置管理工作，可参照控制单元软件配置管理计划software configuration management plan。在软件配置管理工作中，要特别注意规定对软件问题报告、追踪和解决的方法。8 工具、技术和方法在xxx控制单元的研制与开发过程中，都应该在各自的软件质量保证活动中合理地使用软件质量活动的支持工具、技术和方法。8.1 开发工具及编程语言请说明使用的硬件的主要控制芯片、开发环境以及开发工具。开发使用语言也需说明。8.2 测试工具xxx控制单元软

23、件生命周期内，主要采用xxx公司的xxx动态测试软件工具进行软件模块测试与软件集成测试。请描述一下该动态测试软件能够监测的项目。如：被测系统运行时的动态时序图、内存错误、代码覆盖率、系统调用图及性能信息。8.3 配置管理工具xxx控制单元软件生命周期内采用xxx作为配置管理工具，用于软件源代码以及文档的版本管理。8.4 故障报告工具故障报告是指软件质量保证计划中发现的不符合项，采用microsoft word/ microsoft excel作为故障报告管理工具。9 媒体控制为了保护计算机程序的物理媒体，以免非法存取、意外损坏或自然老化，xxx控制单元（包括支持软件）应设立软件配置管理人员，并

24、按照控制单元软件配置管理计划、文件控制程序妥善管理和存放各个子系统及其支持软件的媒体。软件生命周期内的文档及软件支持媒体应存放在合适的环境下，确保不受潮、霉变、破损和丢失，文件应分类存放，便于检索。对借用的文件应办理借用手续并保存借用记录。软件质量保证组通过对控制单元软件配置管理计划、文件控制程序的执行情况检查，保证软件媒体控制符合有关要求。10 供应商控制xxx控制单元软件开发组，如果需要从软件销售单位购买软件或软件部件时，则在选用前应向xxx项目组报告并提出需求说明，经xxx项目组批准，并按相关流程审批后报xxx公司信息管理部，按xxx公司it系统/设备供应商选择管理办法进行供应商评价、管

25、理。11 记录收集、维护和保存在xxx控制单元软件的开发期间，要进行各种软件质量保证活动，准确记录、及时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。在软件质量保证组中，由软件质量保证组质量保证人员负责收集、汇总与保存有关软件质量保证活动的记录。各种软件质量保证活动的质量记录应在每年xx月归档到事业部档案室保存，保存期限至少为五年。表1 项目进展报表子系统名： 模块名： 统计日期： 年 月 日阶段名称计划进度调整进度实际进度备注开工日期完工日期开工日期完工日期开工日期完工日期软件需求分析阶段软件结构与设计软件模块设计软件编码与单元测试软件集成软硬件集成测试软件确认软件使用的准备表2 各文档的质量需求（内部质量特性）内部质量特性（internal）功能性（functionality）可靠性（reliability）易用性（usability）效率（efficiency）维护性（mainta