Software Quality in the SDLC

Society has currently become increasingly dependant on technology, therefore, software applications must work. It is unsurprising that many software characteristics continue to grow in importance, including reliability, availability, security, safety and quality.

Software quality is a process, not a product. According to McGraw (2003), there is no substitute for instilling software quality as deeply into the software development process as possible, taking advantage of the engineering lessons software practitioners have learned over the years. He stresses that the particular software process followed is not as important as the act of thinking about reliability, security and performance throughout the software development process.

McGraw (2003) refers to three technical trends that are aggravating the software quality problem and making the impacts on business both more common and more serious than previous. He summarises these three key trends as follows:

· All modern software is exposed to the Internet;

· Extensible systems (for example, Java and .Net) are dangerous; · System complexity is rising.

Quality is a key issue within the software industry. Software is expected to perform at high levels of reliability and security. The failure of such software can result in severe business consequences including (McGraw, 2003):

· Revenue loss when software fails or key data is stolen or compromised;

· Brand/reputation damage can destroy the market impact when software does not work as advertised, or security vulnerabilities impact consumer trust;

· Liability costs when consumers cannot complete online transactions, or when software embedded in airplanes, automobiles, pacemakers or nuclear reactors causes injury or death;

· Productivity loss when software malfunctions or ceases to function altogether. Defective software costs the American economy an estimated $59.5 billion each year, according to a report issued in June 2002 by the NIST institute. Software users incurred 64% of the total and software developers 36%. The NIST institute suggests that improvements in testing could reduce this cost by about a third, but that testing

McGraw (2003) suggests that the early identification of software risks is beneficial. The two primary reasons in support of this argument are:

· Most software defects are introduced early in the software life cycle;

· The earlier in the software life cycle a defect is uncovered and fixed, the less it costs to repair.

These reasons are illustrated in Figure 4.3 and 4.4 respectively.

Percentage of Defects Introduced at Each Stage of Software Development 0 10 20 30 40 50 60

Stages of Software Development

% of Defects Requirements Design Coding Testing Maintenance

Figure 4.3: Percentage of Defects Introduced at Each Stage of Software Development (McGraw, 2003)

Figure 4.4 illustrates that it is evident that errors revealed in the initial stages of the software development process are less costly to fix than those revealed in the later stages. The likelihood of errors occurring in the later stages tends to diminish in proportion to the effort devoted to the initial stages. Figure 4.4 illustrates that it is evident that the cost of repairing errors is significantly lower during the requirements and design stages then in the later stages, or during the coding, testing and maintenance phases.

Cost of Fixing Defects at Each Stage of Software Development $0 $3,000 $6,000 $9,000 $12,000 $15,000

Stages of Software Development

Cost per Defect

Requirements Design Coding Testing Maintenance

Figure 4.4: Cost of Fixing Defects at Each Stage of Software Development (McGraw, 2003)

One of the areas of software where errors can least be tolerated is that of security safeguards. One of the techniques employed to improve the reliability of software is Software Quality Assurance (SQA). The SQA process attempts to improve the quality of computer software products via the software development process. SQA involves the use of various reviews and the establishment of baselines throughout the SDLC. Tompkins and Rice, as early as 1985, argued that it is not sufficient to simply incorporate security safeguards in application systems. Safeguards should possess many of the software quality factors. Security concerns should be integrated into the SQA process in the same manner that security concerns should be incorporated into the SDLC process. The quality of security safeguards must be built- in, like software quality, and cannot be tested-in (Tompkins and Rice, 1985).

Businesses that value quality, according to Bessin (2004), become more effective at innovation, increase their competitive differentiation and greatly reduce their total cost of development and ownership. Quality, however, is not only the responsibility of each individual on the development team, but is the responsibility of the team as a whole. Teams must do everything they can to integrate workflows, establish traceability and simplify communication. A breakdown in the chain linking team members leads to data

loss, rework, lack of clarity and inefficiency and ultimately lowers software quality (Bessin, 2004). Gong, Yen and Chou (1998) suggest that software developers should select an appropriate development methodology and use suitable tools to maintain a high quality and low-cost software design and development environment.

Gong et al (1998) refer to the growing trend of adopting the Total Quality Management (TQM) philosophy to software development. They suggest that applying TQM to the software development process will help control software quality and productivity, lower costs and decrease cycle times. They provide through their research a way of integrating TQM into the software development process, and in so doing have focussed on the common phases of the SDLC (requirements analysis, design, development, testing and maintenance). Some of the major characteristics of TQM they focus on include:

· Understandability – a software project should be well-structured, concise, complete and consistent and thereby be understood by analysers, designers, programmers and users;

· Reliability – quality software is reliable and dependable. A reliable system performs correctly, completely and consistently;

· Testability – quality software should be testable, simple and easy to execute and maintain;

· Modifiability – this implies that quality software is general and flexible. A system of generic modules or routines should be re- used or tailored for other applications;

· Portability – quality software should be hardware independent. It should demonstrate a consistent performance on different computers with minimal modifications;

· Efficiency – a system with short turnaround time, faster response time and better throughput is recognised as the one with better quality;

· Usability – simplicity or conciseness is one of the fundamental perceptions about good quality.

Table 4.1 identifies the relationship of software quality factors to the life cycle phases in terms of where qua lity factors should be measured, and where the impact of poor quality is realised. Tompkins and Rice (1985) have not explicitly stated security as a

software quality factor, but this is implied through the correctness, reliability and integrity factors. They further suggest that software quality factors should be included in the functional requirements document and ultimately viewed as performance criteria (Tompkins and Rice, 1985).

SDLC

Design Code and Debug System Test Operation Maintenance Correctness (*) # # # X X X Reliability (*) # # # X X X Efficiency # # X Integrity (*) # # # X Usability # # X X X Maintainability # # X Testability # # X Flexibility # # X X Portability # # Reusability # # Interoperability # X LEGEND

# Where software quality factors should be measured; X Where impact of poor quality is realised

* Security-related factors

Table 4.1: Relationship of Software Quality Factors to Life Cycle Phases (Tompkins and Rice, 1985).

The business benefits of including quality-oriented activities in all phases of the software development cycle are both broad and deep. These measures facilitate innovation and lower costs by increasing predictability, reducing risk and eliminating rework. They can help differentiate a business from its competitors. Most important, continuously ensuring quality will always cost less tha n ignoring quality considerations. It is actually suggested that raising product quality costs virtually nothing if done correctly (Bessin, 2004).