关于嵌入式系统软件的全过程质量保证(精)

关于嵌入式系统软件的全过程质量保证质量是产品的生命当今随着软、硬件技术的发展，嵌入式系统广泛应用于航空航天、国防军事、电子通信等行业，其中软件也越来越复杂。

而这些领域应用特点，决定了嵌入式系统往往是高安全、任务关键的系统，软件的微小瑕疵就可能严重威胁到生命和国家的安全、天文数字的巨额财产损失。

这就使得保证嵌入式软件的质量和可靠性，变得至关重要。

而在这些领域，对产品质量从来就保持着高度的重视，有将“质量视为产品的生命”的传统。

这样，相关行业的高层管理人员和开发人员对于软件的质量也逐渐提高了重视程度。

近年来，在组织上，建立了完善的软件测试体系；在开发和测试方法上，建立了中国的软件过程成熟度的评价体系GJB5000；在自动化工具方面，投入了大量的经费和人员在测试设备的开发、购置和建设方面。

应该说，软件作为嵌入式产品主要的组成部分之一，对其质量的重视是目前相关行业的一个共识。

IBM Rational多年来在软件工程和质量保证方面积累了丰富的方法和经验。

本文依据部分嵌入式开发机构对软件质量保证工作的一些理解，分析相应开发机构工作中可能的问题，并提出以RUP为核心的全过程质量管理的思想和具体的实现方式，提出不同单位的过程改进方法，以一种渐进的方式，从简单的工作开始，逐渐深入地改进组织的软件质量管理水平。

定义质量对于任何一个组织，定义共同的对质量的理解是重要的第一步。

软件开发组织经常按照一种不精确的、概括的质量观念来运转。

在IBM Rational统一过程中，质量定义如下：满足或超出认定的一组需求；使用经过认可的评测方法和标准来评估；使用认定的流程来生产。

在这个定义中，我们首先看需求，IBM Rational的软件质量在用户需求方面的定义分为五个方面：易用性、可靠性、性能、可支持和功能。

质量保证，归根结底就是为客户提供更高品质的产品，更好地满足客户的需求。

另一方面，这个质量定义中明确指出，质量更体现在软件开发的整个过程和一个标准的评价方式上。

软件开发过程质量就是指为了生成工件而对可接受流程的实施和遵守程度，体现在三个层次：产品本身和用来生产、组装软件产品的零部件质量；在软件开发过程的标准化、流程化、自动化程度和团队基本协作平台的效率，各个过程对质量的承诺；软件产品验收的评测手段应该是被业界广泛认可和接受的方法，所构筑的质量评价标准。

一个软件生产企业的过程质量一般可以用它的软件过程成熟度等级来评估。

RUP全过程质量保证Rational Unified Process（RUP）是一个可以通过Web来使用的软件工程过程。

作为软件工业事实上的标准，它回答了我们以下问题：在整个软件开发的各个过程中，谁（角色）应该在什么时候（详细工作流程）做什么（任务）和产生什么样的开发结果（工件），以完成整个项目的开发目标。

建立有效的工作过程，可以提高团队的生产效率，控制开发过程中的风险，保证软件开发进度并且提高软件产品质量。

同时通过为所有重要的开发活动提供全面的指南、模板和示例，使整个软件开发团队能够有效共享成功经验，提高团队效率，最终保证软件开发质量。

全过程质量保证思想RUP把整个软件开发过程分解成：业务建模、需求管理、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境等九个核心工作流程。

每个核心工作规程由多个详细工作流程组成。

RUP使用角色、任务和作为输入/输出的工件来组织每个详细工作流程，实现软件开发组织内部人、资源和流程的融合。

RUP通过建立完整的软件开发过程，使得产品的质量由项目团队的每个成员所代表的角色共同负责，具体体现在：每个工作流程设定相应的工作指南和工作检查点，每个角色承担相应的质量任务。

在RUP中，整个软件开发过程如图1所示，它以指定的工件为输入，通过软件开发角色和标准化的软件开发活动，生产出满足质量要求的输出工件。

用正确的过程和平台实现质量IBM提供一个完整的方案以帮助开发团队构建更高质量的软件。

这个开放和标准的平台包括IBM软件的许多工具，包括IBM Rational统一过程。

在开发的每个阶段和每个流程都强调关注质量，帮助团队来识别开发生命周期中的早期问题。

以下部分描述了RUP和IBM软件开发平台中的工具如何支持每个工作流程中的质量实践的。

为减少重复描述，先将相关工具的功能统一简要描述。

下面的所有工具都可以以插件的形式集成到开放的Eclipse平台上，为开发者提供集成环境：IBM Rational System Developer 用于系统建模和开发的集成环境；IBM Rational TestManager 用于计划、管理和报告任何测试工作要求；IBM Rational Manual Tester 用以提高手工测试工作的效率；IBM Rational Test RealTime用于嵌入式系统的静态度量、代码规则检查、单元测试、覆盖率分析、内存分析、性能分析、代码跟踪、线程分析、基于消息的分布式系统测试的跨平台解决方案。

为了推动团队沟通、协作和合作，IBM Rational还提供多种额外的解决方案选项。

分析根据统计得知，引起客户不满意问题的80%可以追溯到对需求的糟糕理解上。

对于任何嵌入式开发项目，不论是新的系统开发，或遗留系统更新集成，质量开始于分析业务，以确保系统需求清晰且准确地反映了业务和客户需求。

我们可以将被测系统置于其将运行的环境中，采用建模的方式，将最优确认的需求，用条目化的方式管理需求文档，实现从需求、到分析、到设计、到实现、到测试的双向跟踪，以实现测试中发现缺陷到各层次的跟踪，和影响范围的分析。

设计在设计中，主要的质量集中在构架上，这是软件的“灵魂”。

低质量的构架会引起大范围的质量问题，包括（软件）脆弱、缺乏升级、以及发现缺陷也难以修改。

这些问题随着应用软件项目不断发展，变得越来越难以解决；并且随着应用软件从设计到开发、测试和部署，纠正缺陷的成本以指数在增长。

如果软件开发人员可以有效地发现、隔离和解决设计和开发期间的结构上的不足，这项工作会在整个项目期间获得受益。

开发平均起来，开发人员在他们写的每千行代码中会产生100到150个错误。

当然，这个数量随着开发人员和项目的不同而不同。

即使只有一小段代码，产生10%的错误也是很严重的。

RUP倡导开发人员主动地测试和分析。

尽管单元测试和运行分析已经变得更为主流，但是许多管理人员仍然有这样的误解，即这些过程使时间表中增加了不必要的时间。

事实上，如果不采用这些措施，开发时间表通常会一样或更加延长，这是由于在质量保证或客户发现问题后，开发人员在生命周期中调试代码要花费更多的时间。

测试管理系统级功能和性能测试是持续保证质量的一个主要部分。

一个开发组织既不应当过分强调，也不应当减少系统测试的重要性。

如前所述，保证质量不只是测试团队的职责，测试也不只是质量保证的唯一领域。

某些测试可以并且应当由开发人员来运行，在某些情况下，可以由构架师来运行。

大量的质量保证工作，在RUP的原则下是由其他开发角色构造的。

支持保证质量的团队职责质量是开发团队中的每个人的职责，但是它也是团队作为一个整体的职责。

在一个迭代的过程中，每个迭代确保了每个工件质量的持续的重新评估，这样，在迭代的方式下，经常可以保证提交质量更高的产品。

有效的软件配置管理和变更管理是保证质量的一个基本工具；它帮助组织确保软件在每次构建时是可重复的和可靠的，并且保证缺陷和变更请求得到正确的管理。

质量过程改进的步骤当我们考虑需要什么来构建任务关键和高安全性的系统软件，并涉及过程质量改进时，大家往往想到的是一个复杂的过程。

其实，软件过程质量改进，如软件开发，可以是一个迭代的过程。

你不需要一步就完成所有的事情。

即使是小的变化，包括调整你的组织中对质量的看法，也会产生一个切实的改进。

我们指出两条参考的改进的线路图，递进式的（或者本质的）和演进式的（反应式的）。

递进式的更多考虑工作流程间的依赖性，做到先改善基础流程，再基于已有的改善基础，做进一步改进。

而演进式的多来自于工作中感知到的问题和瓶颈，依据问题的表面做反应式的改进。

基于改进后再发现新的问题，如此反复。

当然，我们也在努力发现一种可以兼顾工作流程间依赖性，有可以快速显示改进效果的改进方式。

我们可以把质量保证工作改善划分为以下几个方面：配置管理和变更管理、静态分析和单元测试、集成测试和系统测试、迭代开发和连续测试、全过程质量、组织级质量体系、架构分析、需求管理、项目管理。

获得软件高质量的高收益全过程的质量保证体系总是比忽略质量问题的成本要低。

事实上，如果你正确地运用，提高产品质量基本上没有成本。

在国际上，随着软件质量保证理论及应用研究工作的不断深入，针对软件质量保证工作的工作重点也经历了如下发展历程：1970年以前，采用特定（Ad-hoc）测试，与调试没有区分；1970年末到1980年中期，测试基础理论和实用技术形成，软件测试作为软件质量保证（SQA）的主要手段和职能；1980年代末到90年代中期，测试工具在质量和数量上不断增长，测试与SQA分离，注重于工具对测试效率的影响；1990年后期到目前，重新关注有效的过程管理对于软件测试的重要性，将软件工程视为软件测试的基础，或形成各种独立的测试模型、测试能力成熟度模型。

现在高品质软件，需要完整的软件开发过程和整合的软件开发平台来共同铸就。

IBM Rational软件开发平台，就是以各种国际标准和开放平台为基础，为嵌入式系统软件产品的开发和生产过程提供了良好的开发速度和质量保证。