Software verification

Guidances recommend an integration of software life-cycle management and risk management activities. Software validation and verification activities must be conducted throughout the software life cycle [12,14]. Software verification and validation are terms frequently confused. Software verification is defined as the process that provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase... 

Software verification consists of tasks performed to evaluate if the software is performing desired tasks and providing desirable results. Software verification is part of software validation. Software testing is one of the many verification activities intended to confirm that software development output meets its input requirements. Other verification activities include various static and dynamic analyses, code and document inspections, walkthroughs, and other techniques [14]. 

The correct functioning of software loaded on a computer system should be checked in the user s laboratory under typical operating conditions and under high load conditions. During the equipment hardware test, as described in the previous section, many software functions are also executed, such as instrument control, data acquisition, peak integration, quantitation, file storage and retrieval, and printing. Therefore, after successful completion of hardware tests, it can also be assumed that the software operates as intended. There are two situations where software verification independent of the equipment hardware may be necessary ... 

ANSI (1987), IEEE Standard for Software Verification and Validation Plans, ANSI/IEEE Std. No. 1012-1987, The Institute of Eilectrical and Electronic Engineers, New York. 

Wilburn, N.P. Guidelines-software verification. HEDL-TC-2425, Westinghouse Hanford Company, Richland, Washington, 1983. 

An overview of procedural software verification is covered by Mili (20a). Quirk (20b) covers V V of real time software and DeMille, et al (20c) covers the general subject of software testing and evaluation. 

Because of cost and time constraints, we have not had the opportunity to actually work with and evaluate many of the tools mentioned. Consequently our conclusions are based in large measure on the comments received from those working in the fields of AI/Expert Systems and Software Verification and Validation. Also, my conclusions are those of a potential user rather than of a specialist in the field. 

The manipulation of data by computer is a particularly difficult operation to monitor, since in a busy laboratory it is only too easy to accept the software as correct in all circumstances. Obviously the accuracy of the quoted results depends not only on the accuracy of the original measurements but also on the validity of the data handling. Some standard bodies are now developing specifications giving rules and guidance on software verification. 

Methodology of NPP I C System Algorithms and Software Verification Expert Analysis... 

At the first stage preliminary analysis (inspection) of documentation (system and A SW specification, algorithms and software verification and validation plans and reports, etc.) was carried out. 

The requirements and criteria of algorithm and software verification may be imiform. For assessment algorithm V V the some requirements and criteria must be modified. 

In order to reveal and remove faults that already exist in the software, verification is recommended throughout the development lifecycle. Typical approaches are described in 12.7.2.3. 

Partitioning is a technique for providing isolation between functionally independent software components to contain and/ or isolate faults and potentially reduce the effort of the software verification process. If protection by partitioning is provided, the software level for each partitioned component may be determined using the most severe failure condition category associated with that component [ABDOIOO.1.3 Issue E para 2.1.5]. 

An argument used to justify this approach is that comprehensive software Verification and Validation (V V) program is capable to uncover all systematic software faults. Any system failure caused by software is thus hypothetical and can be thus omitted as negligible. This approach is basically correct in the control systems with limited amounts of variable (measured parameters) combination from the point of final probabilistic result (expressed either by system/function unavailability or by critical sys-tem/fimction failure rate). Nevertheless, some anxiety is still relevant because of the high common cause potential of software faults. 

The continuing increase in analytical capabilities has allowed the use of highly sophisticated non-linear constitutive laws to model materials in conjunction with very finely detailed numerical models. This has enabled validating results to be derived from alternative software, thus enhancing confidence in the appropriateness and correctness of the results. However, as all analytical techniques have limits of applicability, an appropriate validation phase of methods and software verification should be carried out by means of either an independent analysis or a test. 

NOTE 2 Examples of some verification activities include design reviews, use of tools and techniques including software verification tools and CAD tools. 

Application software design, and development. Support tools and programming languages To identify a suitable set of configuration, library, management, and simulation and test tools, over the whole safety life cycle of the software (utility software) 12.4.4 SIS application software safety requirements specification Description of the architecture design Manuals of the SIS List of procedures for use of utility software Verification information... 

Static Code Analysis (SCA) has a proven track record as a powerful software verification technique providing the necessary rigour for safety-related software. A number of mature tools supporting SCA are available. However, static analysis also has a reputation as being costly and labour-intensive. This paper looks at recent advances in identifying objectives and processes for SCA and assesses the potential for such analyses to provide, in conjunction with new software safety standards such as the CAA s SWOl and Ministry of Defence s DEF STAN 00-56 Issue 3, a cost-effective and focussed method of gathering evidence that software performs safely. 

The final stage is then expanded on. Software verification is comprised of the following stages ... 

Hi-Lite will create a set of workflows for critical software verification based on existing tools already used in indusfry, some of which were mentioned earlier. These workflows will focus on separate verification through the use of annotations like the precondition shown above, which could be as beneficial to critical software development as separate compilation was beneficial to software development in general. The goal is to reduce the entry cost of formal verification sufficiently so that non-experts will be able to apply separate verification early in the development of systems in common languages like Ada and C. This is in contrast with... 

Software verification toois. These were tools used to detect errors. They therefore cannot introduce errors, but can fail to detect them. Examples include test tools and static code analysers. 

DO-178B required tools to be qualified only when they were used to automate a software development or verification activity without its output being verified. Software development tools were qualified by satisfying the same DO-178B objectives as for airborne software. Software verification tools were qualified by demonstrating that the tool complied with its requirements under normal operating conditions. A tool could be qualified only for use on a specific system, and needed further qualification to be reused on other systems. ... 

On the other hand, qualifying a software verification tool is relatively straightforward. A number of commercially available products have been qualified as DO-178B software verification tools. 

DO-178C has replaced the existing two tool categories (software development tools and software verification tools) with five tool qualification levels (TQLs),... 

---