如何确保嵌入式实时控制软件的质量?对这类软件的生产过程如何进行有效的质量控制?这是一个重要的研究课题。为解决软件危机而产生和发展起来的软件工程成功地解决了软件开发中存在的许多问题。它不仅对软件开发、设计和生产有直接影响，而且对提高软件质量有显著成效。实践表明，使用软件工程方法，可达到一般的质量要求。但当软件质量要求更高时，则必须在实施软件工程的同时，采取一些专门的可靠性工程技术和方法，以保证需求的可靠性。

软件工程是指按照工程的规律来组织软件的生产与开发。软件工程化要求以软件质量控制为核心，紧紧抓住软件生产方法、需求分析、软件设计、软件生产工具、测试、验证与确认、评审和管理等8个主要环节(图1)。

软件生产方法

软件是产品。从产品的意义上说，所谓软件开发应为软件生产。软件应采用工程化、结构化和规范化方法进行生产。软件工程化是指使用软件工程的理论、技术、要求和管理等来规范软件开发过程中的全部活动。硬件生产已有一套成熟的工程化方法，软件要向硬件学习，使软件硬化，把软件看作是软件工厂中的产品。

软件规范化是指在软件生存周期中，软件的生产活动必须严格遵循各项软件规范和标准。经验证明，没有规范就没有产品，也就没有软件。执行规范必须动真格。执行规范工作量是大些(工作量主要在文档、审查、验证、评审和管理上)，但受益却是明显的。由于软件开发过程规范提高了软件质量，这样不仅减轻了损失，而且还促进了软件的生产进度，提高了软件的生产率。

软件结构化是指软件生产过程中采用了结构化分析和结构化设计方法。

软件需求分析

软件需求分析的目的是使软件设计人员和用户之间进行全面和深入的沟通，以明确用户所需的究竟是一种什么样的软件。需沟通的主要内容有：将要开发的软件所涉及的概念、定义、目标、指标、功能、控制逻辑、算法、环境、时序、执行过程和特点等。通过需求分析产生的软件规格说明书是此后软件设计、调试和测试工作的基础，是软件评审、鉴定和验收的依据之一。因此，需求分析是软件生产中的一个首要步骤。一份软件规格说明书的质量优劣，一方面取决于需要分析深入的程度，另一方面取决于系统分析员刻画软件需求的正确性、完整性、合理性和一致性达到的程度。

众所周知，软件怕修改，更怕需求变更。原因在于：

·软件修改的工作量大，关键软件的任何修改，必须经历一个调试、测试、验证与确认的步骤。

·花费的代价高，经试验考核过的软件，又要更改软件需求，即使是只改了一个参数，也需要对更改的软件作重复考核。有的实时控制系统一次试验的代价是相当大的。

·软件修改的牵涉面广，往往有牵一发而动全身的问题。尤其是由多个分系统组成的系统 (例如军事指挥的C3I系统)，任何·一项修改均要考虑是否会影响其他的分系统。

软件可靠性需求分析要求全面、细致和深入。

不难看出，软件需求分析的过程，也是软件设计方案的酝酿过程。通过分析应得出用户需求的正确性、合理性和完整性的结论；同时，也应得出软件付诸实现的可行性、可靠性和安全性的结论。软件需求分析的衔接关系见图2.

软件设计

软件也和硬件一样，它的质量是设计出来的，生产出来的。其中，设计对软件质量具有关键性的影响。设计的重要性可从图3看出，其中(a)为经历了设计步骤后的效果，在软件使用和维修阶段，软件的问题少；反之，(b)为跳过设计步骤，到了使用和维修阶段，软件问题成堆，到了不可收拾的地步。基于这种情况，应强调：软件设计未完成，不得转入软件编码阶段。

良好的软件设计与所采用的软件设计方法、设计工具和设计准则有关。软件设计方法主要有面向数据流的设计、面向对象的设计和面向数据的设计方法等。这些方法均有其优缺点和不同的应用领域。目前，大多数嵌入式的实时控制软件使用的是面向数据流的设计方法。该方法的目标是以一种全局的软件观点和体系结构设计的角度派生出程序结构。

面向数据流的设计又称为结构化设计。它强调模块化、层次化和自顶向下等设计思想。这些思想的根本目的是对复杂问题的解决采用一个简化过程以获得满意的答案。通过这种简化，纵有千头万绪也能理得清清楚楚。一个设计准则是要将复杂的问题简化，切忌将简单的问题复杂化。好的程序设计语言，无疑对设计高质量的软件是有益的。例如，Ada语言，与一般语言比较，它所特有的一些语言成分旨在突出软件可靠性和安全性，便于软件维护，便于实行程序的层次式管理和提高程序的易读性、高效性等。

软件可靠性设计主要将软件的检错、避错、容错和异常处理技术灌输到软件设计中去，设计时应处处关心：

·控制逻辑的完整性；

·软件与硬件、软件与软件界面之间的协调性；

·人机交互的有效性；

·信息交换的正确性；

·设备控制的安全性；

·时序控制的合理性；

·数学运算中变量定义域的合法性。

软件生产工具

软件生产的主要工具是软件试验台(Software Testbed) 或软件开发平台。在软件需求分析的同时，就要考虑到这类软件开发环境的创造。它应满足下列要求：

(1)它的组成、结构、性能、功能和工作的方式与状态，力求与实际系统一致。优点是：

·它与实际系统出现的故障现象是一样的，便于故障隔离。

·软件试验台与实际系统的软件可彼此互相复制，便于软件开发过程交替上升。

·具有互补性，试验台有局限性的问题可在实际系统解决；实际系统上有困难的，代价太大的检测活动可在试验台上进行。

(2)配上多媒体工作站，提供软件测试过程中综合信息的显示和生产真实工作环境中的音响效果。

(3)配备实时数据采集器。

(4)能支持实时与非实时两种运行方式的调试活动。

软件试验台是辅助软件调试、测试、试验和验证的重要工具。在某种程度上可以得出这样的结论：没有软件试验台就不能顺利地开发出实时控制系统软件。原因在于：

(1)这类复杂的软件在实际系统上开发是不可能的，其代价太大，效率太低，效果太差。

(2)软件开发是个做细致研究、分析和不断探索的过程，软件试验台能适应这种工作方式。

(3)它是软件编程、调试、测试、集成和试验的综合环境。

(4)它是支持软件原型化开发方法的重要手段。

一般来说，实时控制系统软件的第一个原型是在软件试验台上开发出来的。有了软件原型，就有了与用户深入讨论、分析和确认软件需求的基础。实践证明，经过软件试验台测试通过的软件，基本上能用于实际实时控制系统的系统联调、测试、试验和系统验收。

软件测试

从软件生存周期看，软件测试是卡住软件质量，尤其是卡住软件可靠性的最后一道关口。但软件测试并不仅仅局限于这个阶段，而应贯穿于软件开发的全过程(见图4)。应解决这样一个认识问题——用于实时控制系统一类的复杂软件，自认为没有错误的想法是不切合实际的。因此，测试的主要目的是：

1) 对软件的质量或可接受性作出判断；

2) 发现问题。

从图4看出，会产生错误的阶段是在需求说明、设计和编程过程中。这些错误若不排除，均会遗传到测试阶段，甚至会遗传到使用阶段。利用测试用例测出问题进行故障分类、故障隔离和故障消除等步骤，直到获得满意的测试结果为止。

测试用例的编写格式和内容如图5所示。测试的设计。难就难在试图利用这组测试用例能找出软件的全部问题。格式中含有测试管理信息——测试用例标识和执行史。测试用例标识是按一定规律统一为每个测试例赋予的代号，便于需求追踪。执行史中有测试日期、测试结果(给出结论：通过/失败)、版本号和主管的测试者签字，这些都是有保存价值的资料。测试用例是需要精心设计、编写、评审、使用、管理和保存的。

软件测试要求在测试过程中，采集软件可靠性数据，并利用软件可靠性模型进行可靠性评估。分析其是否达到了预期的可靠性要求。并据此作出该软件能否放行的决断。若不满足要求，需继续进行测试，直到满足要求为止。可见这是一项十分花精力的活动。

软件验证与确认

软件验证(Verification)和确认(Validation)，简称为V＆V 或V2。验证和确认的区别在于：验证关心的是确保软件模块或功能内在的正确性；确认则表明要与规定的需求进行比较是否满足要求，它所关心的是该软件产品的价值。

软件验证与确认是贯穿于软件开发过程中十分细致的软件检验活动。每个开发阶段的结果可认为是下一开发阶段的一个规格文件，但要进入下一阶段之前必须对该结果作出确认。验证和确认的主要方法有：代码走查、审查、测试和正确性证明等。代码走查就是对软件文档进行书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。

审查是软件验证和确认中的一个主要方法，可弥补其他方法的一些不足之处。它是一种用形式的、有效的和经济的方法查找设计和编程中的错误。审查的主要目的是1)找出软件中的缺陷；2)核实是否符合需求；3)早期生产评价；4)过程评价等。由第三方进行软件评测工作是十分重要的，其评测工具软件对软件进行静态的和动态的评测，能发现软件设计的缺陷、瓶颈和多余物等。值得指出的是，用于软件测试的各种方法、技术、工具和措施等，对提高软件的可靠性都是必要的，但不是充分的。这就表明，其中任何一个手段，均不能绝对保障软件的可靠性，但只要能发现软件中任何一个微小的错误，就起到了它的作用。

软件评审

从某种意义上说，软件中的多数错误是人为的。软件评审是软件生产过程中过滤软件错误的一个“滤波器”。软件评审涉及评审的组织机构、管理、准则、类别、内容、文件和要求等。

一般要求在软件研制阶段的里程碑点进行软件评审。评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。

评审的原则：

·某阶段未通过阶段评审不得进入下一个软件研制阶段；

·评审时对事不对人，评审的是产品，而不是评审生产者；

·评审就要挑刺，找问题、缺陷和隐患；

·评审组的人员面越广越好；

·评审组不作无休止的争论和辩驳，将争论点记录下来，供以后甄别；

·评审只是提出问题，没有解决问题的任务；

·使用“评审检查单”以提高评审的效果；

评审的作用：

·技术把关，避免软件人员的想当然；

·概念沟通，吸收用户和总体人员参加，审查软件人员理解的正确性；

·集思广益，吸收有关的分系统人员参加，从不同侧面确认软件的协调性；

·总结汇报，使实时控制系统总指挥、总设计师了解软件生产的进度、问题和要求，作出新的部署。

评审很容易走过场、走形式。评审效果的好坏，与当事人(软件人员)密切相关。基于有问题才需要评审，不能轻信自己的软件，导致对评审产生对立情绪。对评审出的问题进行整理、分类和汇总，不忽视任何一个细小的疑点。

软件管理

科学的管理能够出可靠性、出效果、出效益。软件的管理工作不完善、不严格，是引起意外事故的原因之一。软件管理主要包括软件项目管理、软件配置管理、软件可靠性管理和软件质量管理等方面。

软件项目管理的内容包括软件开发过程管理、软件可靠性度量、风险管理(包括风险分析和估计)、确定项目任务、建立可操作的工程计划等。软件项目管理是软件管理工作的第一层。需要强调的是，它不是一个阶段，也不仅仅是个步骤，而是贯穿于整个软件开发工程中的一个层次。从其管理内容来看，这是一种十分重要的管理工作。其管理的好坏，直接影响产品的质量。这项管理尚处于起步状态，是个薄弱环节。软件配置管理是软件人员和管理人员确定、组织和开展软件修改的手段，目的是在软件修改过程中设法少犯差错来最大限度地提高软件产品的生产率。软件配置管理涉及软件配置项和基线的确定。

软件配置项可理解为在软件生产的某个阶段应具备的软件文档和保存软件的介质等。软件基线(基准)又称里程碑。软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一个基准。下一个阶段只能在这个基准上进行开发活动。

软件配置管理要求：

·软件修改必须遵循软件更改规范；

·未经批准的更改，任何人无权修改；

·更改后必须测试、验证和确认；

·软件验收，必须对相应的软件进行评审。

具备评审的条件包括：相对该基线的软件配置项齐全、有测试结果和测试分析报告及软件优化报告。

文档管理是一项十分艰巨而又琐碎的工作，要求：文档编写必须规范、文实相符、文文相符、描述具有一致性、确切性和简明性、签署完整、职责明确。软件可靠性管理作了一些初步的尝试。在软件生产过程中，设计了软件可靠性数据采集表格。对软件中的需求、模型、设计、编码和定义域等方面的错误均要填表。填写产生该错误的时间(计算机执行的累计时间)、错误性质、出错原因和排除错误的结果等。

主要问题与解决方法

对实时控制系统软件工程化的重要性的认识尚处于起步阶段，重视程度也不平衡。主要问题：

(1)部分系统的软件开发由硬件人员承担。硬件、软件、模型设计均由一个组完成，仍是典型的“自编、自导、自演”小作坊的工作方式。

(2) 还不太习惯于软件工程化、规范化、结构化和模块化的软件生产方法。往往跳过了软件设计阶段，而是先有编码，为了软件检查才补设计。

(3)缺少配套的软件测试工具。试图利用实时控制系统进行软件的调试、测试、验证、确认和试验工作，这样的软件测试必然是不完整的，也是有局限性的，更是不科学的。

(4)实时控制系统软件可靠性工程的研究是自发的，未纳入实时控制系统研制计划，影响这项工作的深入开(5)需要解决实时控制系统软件工程化方面的若干模糊认识：

·软件就是编程；

·没有测试工具照样可以开发出软件；

·舍不得在软件可靠性上化成本；

·出了问题，才发现软件似乎比硬件更重要。

(6)实时控制系统软件可靠性指标不好定。原因是软件可靠性的评估涉及模型、方法、工具和条件等问题。当前，要求软件的可靠性为100％，对软件是不公正的，也是过于苛刻的。

建议

(1) 软件可靠性工程也是一项涉及面很广的系统工程，应加强这项技术的研究力度。尤其要结合具体实时控制系统设置研究课题，使实时控制系统软件的生产过程同时也是软件可靠性工程的实施过程。使自发的可靠性工作成为有计划、有组织和有目标的研究工作。

(2) 适用于嵌入式计算机的实时软件，例如实时操作系统、Ada语言等，应像美国国防部那样，要强制推行。

(3)计算机技术发展很快，软件技术及软件可靠性工程技术也发展很快，应对重点实时控制系统的软件人员定期组织培训。

(4)为了解决软件生产的小作坊问题，可否考虑逐步推行实时控制系统软件人员考核制，作出资格认证。