Software Quality Is A Measure Of Desirable

Published Date: 02 Nov 2017

Introduction

Software quality is a measure of desirable attributes and it is accessed by two main variables known as external and internal quality criteria. It is also defined as a property built into a system using certain rules and procedures (Dennings, 1992).

User experiences when running the software in its operational mode is attributed to external quality whilst the invisible, that are code-dependent are ascribed to internal quality. While external quality is critical to the user as it provides some form of satisfaction and integrity in that the client receive what they expect, internal quality is meaningful to the developer only as it ensures that there are no consequences of using the developed system.

Fitzpatrick (1996), notes that there are various aspects of software quality named functional, Structural and Process quality. However, these aspects along do not suffice for quality as there are other factors such as people, tools or activities such as group code reviews and effective management also have a role to play. Poor quality can result in companies losing their business, excessive costs decreased productivity, increased risk, uncertainity and possibly death in safety-critical systems.

This assignment focuses on software that was used on the therac-25, a radiation machine used to treat cancer and due to some quality issues, it had drastic effects that even resulted in deaths.

Acronyms

ADP Automated Defect Prevention ADP

AECL Atomic Energy of Canada Limited

CMC Canadian Medical Corporation

CMM Capability Maturity Model Integrated

RMP Risk Management Plan

SCMP Software Configuration Management Plan

SDD Software Design Description

SDLC Software Development Life Cycle

SPMP Software Project Management Plan

SRR Software Requirement Review

SRS Software Requirements Specification

SVVP Software Verification and Validation Plan

SQA Software Quality Assurance

ISO Software Quality Assurance Plan

UD User Documentation

QA Quality Assurance

Assumptions

Will be reused enough to recoup extra costs

Can easily and cheaply integrate components into a new environment (interoperability).

Frequency of reuse increases with degree of comprehensibility.

CMC had no rating in the CMMI levels and can be classified as level Zero (0).

CMC had no departments responsible for testing and no quality assurance team.

CMC did not use any software design principles or software engineering principles during the development of the therac-25 machine software.

CMC reused software codes to recoup extra development costs

CMC developed the software application under commercial pressures.

CMC did not have an independent test group

AECL had no Quality Control Mechanism in place.

Part A: Software Quality Matrix

According to IEEE (1993), Software metrics are meant for obtaining objective reproducible measurements in the SDLC. These measurement can be used for finding defects or predicting defective code to ascertain quality assurance in terms of performance, debugging, management, and estimating project costs. They can also help in predicting project risks and success, size, complexity of development involved and quality of software as in whether the software quality requirements are met. However, the use of metrics does not eliminate the need for human decision in software evaluations and expected to have positive effects by making software quality more visible (Schulmeyer, 2008).

Various types of software matrices are;

Process Metrics

Process metrics, which is used to evaluate and track aspects of the process of software design process. It is normally used by management to check the budget and office procedures for efficiency. Basically, it is used to improve software development and maintenance. Its main focus is outlined in figure1 below

Figure : Process metrics aspects

Disadvantages

Minimal focus on quality

2. Cyclomatic Complexity

Cyclomatic complexity is a sub component of "Product metrics" which focuses on the following outlined factors in the figure below.

Cyclomatic Complexity (CC) metric has been chosen for testing the quality of the software discussed below. It is basically used to measure the control flow complexity within a function, modules, methods or a program. The number of recommended design test cases to execute each of the paths for software can also be determined as the minimum number of test cases is equal to the cyclomatic complexity. It can be used in all phases of the software lifecycle in order to keep software reliable, testable, and manageable.  It is very easy to compute and it provides a good indicator of how easy it is to maintain the codes since complex codes can be found during formal review (Shepperd, 1988).

The usage of the CC is as illustrated below.

M = E − N + 2P

where

E = the number of edges of the graph

N = the number of nodes of the graph

P = the number of connected components (exit nodes)

Below is the flowchart upon which the CC calculations are based. (N.B Actual smart draw exe file on cd)

Figure : Flow chart

M = E − N + 2P

E = 54

N = 50

P = 1

Therefore,

M= 54 – 50 + 2(1)

4 + 2

M = 6

According to Shepperd (1988), as depicted below in the figure, it can therefore be deduced that the program has 6 independent path executions and it is a simple program without much risk.

Figure : CC Risk evaluation

Part B: Quality Assurance Strategy

1.0 Case Review

The therac-25 was a radiation therapy machine produced by Atomic Energy of Canada Limited. There were previous version of the same machine that were initially produced but with intentions of extending computer control, substantial and vital components were overlooked and patients ended up being given massive overdoses of radiation. The therac-25 was completely software controlled as many hardware safety interlocks were removed. The resultant six (6) accidents recorded highlighted the risks of software control of safety-critical systems.

A review of the documented cases of the therac-25 revealed a number of contributing factors that led to overdoses of radiation and failure of the system as a whole. These factors are mainly due to poor software engineering practices. Failure was also due to the over-confidence in the software that brought about the assumption that software cannot fail. There was also a confusion where Reliability could not be treated as a separate entity from Safety. For AECL, long duration of using the software meant it was safe.

Another contributing factor to the software failures and accidents was that even after some safety issues started arising, the root causes could not be identified but rather, the engineers only tried to sort out the problem with unrealistic risk analysis methods where they just assumed the source of problems to be hardware related. Neither much investigation was done when an accident event transpired nor follow-up activities conducted which was the main cause of failing to trace the root cause of the failure. Moreover, no regression testing was performed to check against any changes that had been make as a means to improve the software.

Due to the early stages of using software, there was little experience and exposure to standard requirements to observe and therefore, little attention to was paid to standards and guidelines required to include in software (Leveson, 1995).

1.2 Failures

Basic Software Quality Measures and other failure contributing factors are as shown in the figure and table below respectively.

Table : Cause and Effects diagram

Component

Implemented/Done by CMC?

Comment

Software requirement specification

X

User Involvement

X

Not documented

Simple User-interface

X

Complex Command line

Formal Verification

X

Software Inspection

X

Hardware Inspection

Appropriate Feedback

X

Ambiguous

Integration testing

Maintenance/Support

X

Option between support/upgrade

Usability testing

X

Unit testing

X

Inadequate

Safety Mechanism

X

Removed & replaced by software

Follow-up activities

X

Documentation

X

Table 1: Failure factors

The failures of the therac25 can be categorized in to Soft-factors and Hard-factors where the soft are "People-related" or Non-Technical causes and the hard being "Technical Issues".

Soft-Factors/Non-technical causes

1.2.1.1 Lack of training

As noted by one of the operator named Susan, one of the biggest problems was lack of rigorous education for operators. She further notes that most clinics where money was tight, there was an option for administrators to choose between machine servicing, contracts, software upgrades and training. It can therefore be deduced that lack of training could have led to many human errors.

1.2.1.2 Poor communication among customers, developers, and users

Fault tolerance techniques usually embroil the observations of dynamic local failures and the tolerance of the related faults, however, there was no one from CMC to observe the faults that arose from the software. Furthermore, there were no follow up activities done, not even checking or getting feedback on issues encountered by AECL. Errors were also not reported and attended to immediately.

Un-attended to errors

Because of having too many errors and the fact that the program did not advise the operators the problem, they became insensitive to machine malfunctions. These un-attended to errors could have had an enormous effects in the long run.

Production or Operational pressures

Henrke (2001), notes that there was pressure to treat patients on certain days to avoid rescheduling which generated a push through effect. This made the operators override safety mechanism.

Hard-Factors/Technical related causes

1.2.2.1 No logging system

Hernke (2001), notes that the machine did not record and keep any logs. Therefore, it was not possible to determine if a machine generated more errors than acceptable. It is further noted that there were no regulations to govern the means of communication between the clinics and CMC

1.2.2.2 Documentation

The FDA memo (1986) noted that very little documentation was produced during the development. Software specifications and test plans were also not documented (Hernke, 2001 p59).

1.2.2.3 Ambiguous or Cryptic Error Messages

The error messages that were displayed if an error occurred provided no clear guideline for the user. Hernke (2001) notes of malfunction codes 1 to 64 with the keyword "malfunction" which were not even explained or addressed in the operator’s manual supplied with the machine. Therefore, operators could neither determine what had gone wrong nor tell the next step they could undertake. Such error malfunction messages were also very common and they were not taken seriously as they did not involve patient safety.

1.2.2.4 Re-use of software

The therac-25 machine was built on software from older models. These old models had hardware interlocks that countered their software defects. However, because of not analyzing the problems with those old models, they adopted the limitations of the previous models into the therac-25. Having overlooked this, they further replaced hardware with software safeties which had no means of reporting a "trigger", therefore not indicating the presence of faulty software commands.

Leveson (1995) notes that a lesson to be drawn from the incident is to not assume that reused software is safe because of extensive prior usage. He further suggests that "A naive assumption is often made that reusing software or using commercial off-the-shelf software will increase safety because the software will have been exercised extensively. Reusing software modules does not guarantee safety in the new system to which they are transferred."

1.2.2.5 Badly defined system requirements

Requirements outline a guidelines of how the system should operate and fulfill the user or beneficiary needs. Since requirement analysis should be done by both the development and the Quality Assurance team, possible defects can be found and sorted out in the early stages or before release. However, with the therac-25, there was neither a team for development nor a team for quality assurance. Development was done by one person.

1.2.2.6 Unmanaged risks

Major components were overlooked and AECL did not consider the design of the software during its assessment. Condition under which the machine might produce the desired results and what failure modes existed were not checked and analyzed. The designers also overlooked the possibility of software failure and therefore, they did not setup any hardware interlocks to supplement safety that could prevent the electron-beam from operating in its high-energy mode without the target in place. The hardware furthermore provided no way for the software to verify that sensors were working correctly

1.2.2.7 Inability to handle the project’s complexity

The software was written by single programmer who used overly complex programs written in unreliable styles using assembly language which in-fact required more attention for testing and good design. Programming errors and poor standards such as unprotected memory, improper flag or initialization also contributed to the accidents

1.2.2.8 Sloppy Testing practices

Hernke (2001) notes that there was lack of documentation on software specifications and test plans. It was even argued by a Quality assurance manager that the therac-25 software was tested for 2700 hours whereas that was the time it was in use.

Regression testing which focuses on defects propagated to other modules by changes made to existing program was not done after CMC redesigned the switch to detect position and it accompanying software (Hernke, 2001:p23).

Unit testing on the software was overlooked and AECL only tested the Therac-25 after the assembly of software and hardware at the hospital. Even the re-used software from the previous therac-20 machines was not critically analysed before being used

Sloppy testing practices resulted in failure to realize that the equipment control task did not properly synchronize with the operator interface task. User testing could have shown the effect of certain event within a particular timing. Furthermore, as noted by Leveson (1995), data entry speed during editing was one of the causes of malfunction indicating that stress testing was not probably done at all or it was poorly done. He also states that AECL was requested by FDA is draw up installation test plans to ensure hardware and software performed in accordance to the design requirement.

This indicates that integration and functional testing were also poorly done or not done at all as the hardware provided no way for the software to verify that sensors were working correctly. Due to poor testing (probable unit and functional), the developer could not discover that the software was setting a flag that caused the software to bypass safety checks.

Furthermore, the Fault-Tree-Analysis did not analyse the software due to assumptions and Pre-market Equivalency was used to commercialize the machine which did not subject the machine to testing and inspection. Failures and problems were therefore left to be faced by users.

1.2.2.9 Design flaws

There was an incrementing flag which caused an occasional arithmetic overflow occurred. The Poor unfriendly User-Interface was also another factor. Leveson, as noted by Hernke (2001), suggest that the console was no user friendly and it made no distinct differences between life-threatening and minor errors. All these resulted in an override of safety checks.

2.0 Software Development life-cycle Quality Assurance Recommendations

Quality Assurance, as defined by Kevitt (2008) is guarantying that the totality of features and characteristics of the software being delivered satisfies the given needs based on agreed specifications, standards and functionality required without defects and possible problems. Alsultanny and Wohaishi (2009) note that software quality assurance ensures that the process of cooperating quality in the software is done properly, and that the resulting software product meets the quality requirements. Reviews of specification documents, checking models, or by static analysis of source code determine internal quality whereas properties of software interacting with its environment define external quality (Zeiss etal, 2007). However, rather than testing which demonstrates the degree of conformance in terms of functional requirements, various measures that lead to quality, such as those listed below should be taken into account.

2.0.1 Planning

Quality can be managed at the planning stage through review of the project in its entirety and formal specification and then creating a quality assurance strategy and documenting the plans for easy review.

2.0.2 Analysis

2.0.2.1 Specification review and Abiding by the CMMI Model

Capability Maturity Model Integration (CMMI) is a process improvement approach where existing processes are understood and changes to these processes are made to increase product quality and, or reduce costs and development time. With the therac-25, a review of the therac-6/20 would have been ideal to understand the processes and make appropriate changes.

The risks should also be identified, evaluated, weighted and mitigation plans must be outlined (Kevitt, 2008).

2.0.3 Design

During the design phase, threat analysis should be conducted which is basically understanding threats to find issues before the code is committed and creating a defect removal and defect injection prevention measure.

2.0.4 Development and Testing

This stage is where test cases are developed for testing.

Testing

Executing testing activities help to validate secure implementation. Security testing would validate the robustness and security of the software. However, this phase should iterate throughout the development phase.

Figure : Testing Quality Assurance

Fuzz testing must also be done which, as defined by Simpson (2008), is reliability and security-testing that relies on building intentionally malformed data to see how the system responds

White-box and Black-box testing

White box testing is a method to test the software codes structure by seeing the program from the software engineer’s perspective and looking to the internal design and program code structure to uncover defects early.

While black box testing is a method of testing external software functionality and looking to the program from user perspective, the testers here know only what software should output without knowing how it operates. This test help to uncover functionality defects early before releasing the product to customers (Desikan and Ramesh, 2006).

Reliability Testing

This test is used by the Reliability Growth model to detect system failure causes and to evaluate the system ability to perform for long period of time without failure and the failures probability.

2.0.4.1 Conforming to ISO standards

ISO standards ensure that products and services are safe, reliable and of good quality, in this case, the software by providing guidance and tools. ISO9126 should be adopted which defines a generic quality model for internal quality or external quality by using different sets of metrics (Zeiss etal, 2007). The model characteristics are functionality, reliability, usability, efficiency, maintainability, and portability.

2.0.5 Maintenance

Maintainability is the ability of the software product to be revised. Modifications may include corrections, improvements, or adaptation of the software to changes in environment, and in requirements and functional specifications. However, it is vital to note that software complexity may have a direct impact upon maintenance costs as well as the costs incurred through the presences of software errors.

Maintenance can be made easier through Problem Reporting and Corrective Actions Measures. The purpose of this act is to describe the practices and procedures to be followed to report, track, and resolve problems in both software items and the software development and maintenance process. Problems identified during the project reviews must be recorded and submitted to the project leader and then reported to SQM to take necessary actions to correct and prevent those problems.

Figure : Maintenance Quality Assurance

Regression testing must also be conducted and the results well documented for reference purposes.

2.0.6 Documentation

Keeping a continuous record of all changes and problems (status accounting) to insure against disasters as well as to ensure the quality of the software development process is important. This can be achieved with the use of Software Configuration Management tools. During product development life cycle all reviews and modification must be documented, and archived after releasing the product for future use and avoid falling in the same mistakes, and the solutions used in each phase

Logging and tracing are essential for securing, monitoring and debugging purposes. This logging should not only cover failed events but normal and successful operations of the system too. They can help to pinpoint the bugs in the system. Usability implications of particular (mostly safety related) settings should be clearly defined and outlined in the documentation as well.

The Software Quality Assurance Plan (SQAP) Assessment Checklist must also be documented clearly stating problem reporting and corrective action procedures as well as the tools and techniques for support.

Deployment

2.0.6.2 User Manual Documentation

This document should clearly state how to install, operate, manage, and maintain software products, and describe the data control inputs, input sequences, options, program limitations, and all other essential information about the software product for users that interact directly with the system. Other measures are as shown in the diagram below.

Figure : Release Quality Assurance

2.0.7 Training

To ensure that the software development team can develop high quality products, SQM and project leader should ensure that the development team is trained in relevant software engineering design methods and processes, development environments, tools, test techniques, and quality assurance methods needed to stay current with the sufficient knowledge levels and whether best practices are used in the development process.

3.0 Quality Matrix Chosen

Boughton (2012), notes that software metrics are meant for obtaining objective reproducible measurements that can be useful for quality assurance, performance, debugging, management, and estimating costs. However, different metrics look at different aspects of quality such as functionality, documents produced, the cost of the software project and size or complexity of the system (Michalis, 2006). It is therefore recommended to never use only one metric as Software is complex and multifaceted by Westfall (2005). Commonly used matrices are as described below.

Requirements metrics is used to measure the size of requirements, traceability, completeness and volatility of the software.

Product Metrics is used to assess the design as per requirements or design documents before the system has been implemented and Codes (lines of code) used in the software. It also embraces the testing criteria and the artifacts such as meetings (Jung & Kim, 2004).

Process Metrics assess the efficiency of processes of software development including Human resources, time, schedule and the methodology.

Therefore, an appropriate matrix to use for the therac-25 software would be all the above described Metrics because the limitations of one can be covered by the other since they all have different focus.

4.0 Testing Strategy and Tools

The core-purpose of testing is to ideally detect all errors that are present in a software even though a full test coverage of a program is impossible. The therac-25 was supposed to undergo various testing

Figure : Proposed testing strategies

Neither testing alone nor even simulation can thoroughly examine all possible instances and combinations of system execution. However, it is vital to ensure that it is done as it identifies errors that can then be removed or rectified. The following testing strategies could be carried out for quality assurance.

Unit testing: This testing would ensure that proper information flow on interfaces is regulated and that integrity is maintained by examining local data. Boundaries conditions as well as all error basic and handling paths would also be tested. Methods used to call a module (Drivers) that is being tested must be developed to test incomplete software. Finally, Regression testing which is basically adding test cases that focus on software functions likely to be affected by the changes and changed software components should be done.

Tools: Mockpp, is a platform-independent generic unit and integration testing framework for C++. Its objective is to expedite the development of unit and integration tests in the spirit of Mock Objects, EasyMock, and jMock.

For the therac-25, the methods used for execution were supposed to be verified to ensure that they could handle invalid data gracefully and did not fail for valid inputs

Integration testing: Individual modules should be tested as a group to ensure that the software can co-exist with others. Methods or tools that could be used are either be a bottom-up, top-down or modified top-down testing.

Bottom-up testing is where a driver (control program) is written to coordinate test case input and output and low level components are then combined in clusters that perform a specific software function which is then tested.

Top-down tests conducted as each component are integrated using the main program as a test driver and stubs as substitutes for components directly subordinate to it.

Thereafter, thread testing (testing set of actions associated with particular module functions should be done.

Validation testing: This testing phase would ensure that each function or performance characteristic conforms to its defined specification. Tools such as LabView or Reactis could be used to achieve this.

Performance testing: This phase tests the run-time performance of software and automated tools such as Qtest, simulator, monitors and analyzers could be used for this purpose. Other modes of analysis such as stress testing, where the entire program is checked to see how well it copes and deals with abnormal resource demands

Installation testing: This testing is aimed at verifying the successful installation and upgrade or uninstall the software. With a complex and sensitive system such as the therac-25, a full installation would be ideal

Acceptance testing: This testing would that the software works correctly for intended user in their normal work environment. The Cucumber tool can be used whilst conducting an Alpha test where the version of the complete software is tested by customer with the supervision of the developer at the developer’s site

The acceptance test could also comprise of timing, stress tests and user walkthroughs of meaningful scenarios to ensure that the software meets the performance requirements and behaves as defined.

5.0 Configuration Management

Chan and Sheung-lun (1997) define configuration management (CM) as a process for establishing and maintaining consistency of a product’s performance and functional and physical attributes with its requirements, design and operational information throughout its life. It is important because it gives precise visibility and therefore improved control over a complex system which establishes and maintains the integrity of the product. As noted by Greenough and Worth (2006), configuration identification and control could be done to ensure that all changes to the system are performed with the knowledge and consent of management of the institution using the therac-25. The costs and impact of changes, and deciding on how the changes should be implemented are also observed.

However, configuration status accounting must be done to keep a continuous record of all changes and problems to insure against disasters as well as to ensure the quality and also to determine if the system complies with its specifications of the software development process. Configuration audits which are simply proper authorization procedures must be in place to ensure the accuracy of the product as specified by the system requirement.

Since the therac-25 was a release from prevoius versions, version management was supposed to be carried out which is, as defined by Sachweh and Schafer (1995), is monitoring of the multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other. Release management was supposed to be used in preparing software for external release and keeping track of the system versions that have been released for customer use.

With the therac-25, configuration management could have been achieved

Breaking a system down into a number of known and manageable parts (configuration items)

By ensuring that change requests from members of the development team were vetted by a change control board (CCB) which either approves or disapproves the changes.

Identifying the various revisions of parts as it evolves throughout its development life cycle

Keeping track of the aggregates and instituting standards to give visibility of the completeness of a system at critical stages in its development lifecycle

Keeping detailed and accurate records of the above in a configuration item register to which this CI must comply which are the ISO standards

The table below outlines the tools that could be used for various activities.

TOOLS

PROCESS/ACTIVITY

Parallel Configuration Management System

(PCMS)

Documentation change control.

Version Manager

Version management and access control

The Source Code Control System (SCCS)

Status accounting

Change and Configuration Control Development and Maintenance CCC/DM

change request processing and emergency changes

Table : Configuration management tools

6.0 Defect Prevention Measures

Defect Prevention (DP) is a strategy that identifies root causes of defects and prevents them from recurring during the software development life cycle (Kumaresh and Baskaran, 2010). Implementation of defect preventive action helps to give a quality which not only increases customer satisfaction but the ability of software developers to learn from those errors and, more importantly, learn from the mistakes of others is enhanced. It also reduces development time and cost, reduces rework effort, thereby decreases cost and improves product quality. The various measures that can be undertaken to prevent defects are as outlined below.

6.0.1 Defining User/Customer Requirement

Formal specification: Setting up clearly outlined product specifications to clearly reflect design intentions to customer requirements. The requirements are reviewed and comments which may include corrections, suggestions and doubts on the artifact are noted until the team is satisfied as shown in the figure below.

Figure : User requirement phases

The process of preventing defects in a software or any system is an interactive process and is composed of various stages as shown in the table below.

Figure : Defect prevention processes

Defect Identification: preplanned activities intended to prevent defects at various stages of the SDLC must be outlined (Kumaresh and Baskaran, 2010).

Defect Classification: This is the stage were the different types of defects are categorized according to their attributes such as Requirements, Design, Logical (found by testing the code using functional/unit testing), and Documentation. This can also be achieved by using a tool named "Orthogonal Defect Classification" (ODC) which can identify and group defects in to types and at two different points in time which are Opener section – (first defect detected time) and Closer section – (Time when the defect got fixed)

Defect Analysis: this is the process of quantitatively analyzing defects data for continuous quality improvement. The feedback is used by developers to eventually improve the quality. Tools such are the "Cause and Effects" and "Pireto chart" can be used as well.

Root cause analysis: involves the process of finding the activity or process which causes the defects. It can be achieved by utilizing expertise who understand what went wrong. For instance, the therac-25, rather than focusing on reproducing the "malfunction" error, the cause of the error should have been the focus

For the therac-25, rather than the above measures, defect prevention could also have been achieved through Education and training of users to provide people based solutions for error source elimination (Tian, 2005). Managing the processes such as setup carried out by the users and effectively monitoring of operations, challenges and errors encountered would also have prevented defects. Other measures must have included "Formal Verification Techniques" by the software provider. This is a process of checking the conformance of software design or code against the formal specification outlined.

6.1 Process Improvement

The process improvement that could have been done to achieve quality software are as listed below.

PROCESS

ACTION

1

Measurement

Measure defects through defect density (Kilo Source Lines of Code/ per line of code) "These measurements provide the data input to subsequent analysis and modeling activities that provide feedback and useful information to manage software project and quality", (Tian, 2005 p59).

2

Analysis and modeling

Fitting the collected data in to analytical models that provide quantitative assessment of selected quality characteristics or classified defects into categories. Such may include "defect state tracing" or "density code review", "Questionnaires" or "Interviews" and focus on the correlation between one phenomenon and subjective cause to determine the root cause.

3

Providing feedback and identifying improvement potentials

Results from the analysis and modeling activities must be relayed to the quality engineering process to take appropriate remedial actions needed

4

Follow-up activities

Basically, this phase is for verifying that the rework needed was done. For example, if there were any suggestions to make some alterations to the therac-25 after some inspection, this phase would verify if changes had been done.

Table : Process Improvement measures

7.0 Inspection

Tian (2005), notes that independent reviews as a means of inspection are very important as it gives un-biasness. However, AECL did not have the software code independently reviewed. Various techniques such as the "Fegan-Inspection" could have been used to inspect the therac-25 software.

The activities include Planning preparations, Overview meeting to discuss related relevant matters, Preparation of necessities such as checklists of defects, conducting the Inspection and finally conducting Rework and Follow-up activities to verify that the necessary rework has been performed properly.

The objective of these inspections is to find all the defects at each phase and to proceed to the next phase with a completely correct basis which include errors in design, requirements documents, source code etc. With inspection, it can be determined if the coding style guidelines are followed, comments in the code are relevant and of appropriate length, naming conventions are clear and consistent, the code can be easily maintained (Parnas, 2003).

Inspection can be used to find faults in code standard and traceability (Sapsomboon, 1999). It can also help in debugging and finding what is wrong in a prescribed and systematic process. Whilst testing is executed by compilers, inspection is done by humans who can find errors outside the normal execution logic used by a compiler. Fegan (1986) notes that Product, Process, Management and Programmers should all be inspected to compliment testing and ensure quality.

Parnas and Lawford (2003) further notes that early inspection of a document that states system requirements can help insure that the correct system is built. Two techniques, "Usage-Based" and "Checklist-Based Reading" can be used for document inspection whilst integrated computer aided verification can be used for walk-through (informal) inspection of design and codes as well as logical and environmental factors (Tian, 2005).

8.0 Formal Verification

Formal verification is very important for safety-critical systems such as the therac-25 as it is a systematic process that uses mathematical logic to verify that the design specification is preserved in implementation. The software development process should be verified, validated through formal reviews and inspections performed on all source files and documents. The document determines whether developed software products conform to their requirements and satisfies functional, performance, and other requirements by providing a systematic coverage of all possible system execution sequences derived from both expected and unforeseen usage scenarios.

The verification plan should document the verification tasks and the validation plan should document the validation tasks, the verification plan and validation plan may be packaged together in a single document.

9.0 Fault Tolerance/Containment

Tian (2005), notes that failures are un-avoidable but minimize-able. He however states that fault containment measures must be taken in any system to prevent the propagation of faults from their origin at one point in a system to a point where they can have an effect on the service to the user in order to improve robustness. For the therac-25, containment could have been achieved through identification of the faults, isolating and restricting the faulty nodes and finally setting up some recovery options.

Isolating modules into independent functions

The software safety feature should have been backed up by a hardware component that blocks the channel of radiation in-case of any failure.

Exception handling

An electrical switch that trips off and turns down the machine in-case of failure

Having additional hardware modules that measure the dissipated rads from the therac-25 machine and displays the feedback on the console. If it detects an abnormal amount of radiation, it then automatically shuts the machine down.

10.0 Commercial Considerations

In order to commercialize the software, the following factors must be taken into consideration.

Usability testing

Acceptance Testing

Beta Testing

Functionality, features and innovativeness

Software support: How Maintenance and software enhancements can be carried out to cope with newly discovered problems or arising requirements.

Security

International Technology Standards ie ISO 9126

Retrieving feedback from customers through regular surveys or by using the company website to keep in touch with customers.

Conclusion

Software safety assurance fault tolerance, and formal verification techniques can be used to reduce the failure probability, or to reduce the accident probability or severity of resultant damage. Improving software quality requires development process improvements along the development timeline. However, fault containment measure must also be taken.

With the therac-25, improvements should have included the backing-up of the safety mechanisms from software-only to software and hardware. Identification of the root causes and following the Pireto principle of 80:20 rule (20 percent of the vital defects causing 80 percent of the problems). Therefore, resolving 20 percent of the root causes would have sorted out 80 percent of the problem. For instance, good documentation would have prevented "overlooking" of error by the therac-25 operators that ended in drastic effects.

Therefore, Quality measures must only start from the design and analysis and end after deployment but must continue throughout the usage of the software through maintenance and support.