5.3 Design Guidelines for Software Quality
5.3.1 Guidelines for Software Defect Prevention
Defects can be introduced in different ways and at different points along the life cycle phases of software. The following are some causes for defects:
1. During the concept and definition phase
• misunderstandings in the problem definition, (the final user itself my have an incomplete vision of what is truly desired),
Modules (Software Element) Design, Coding, and Testing Software System
Specification
Basic Software Structure
Modules Validation
Modules Integration Software Validation
and Installation
Software Modules Specifications
Figure 5.2 Procedure for software development(top-down design and bottom-up integration with vertical and horizontal control loops)
• constraints on C P U performance, memory size, computing time, I/O facilities or others,
• inaccurate interface specifications,
• too little attention to user needs and/or skills.
2. During the design, coding, and testing phase
• inaccuracies in detailed specifications,
• misinterpretation of detailed specifications,
• inconsistencies in procedures or algorithms,
• timing problems,
• data conversion errors,
• complexsoftwarestructuringorlargedependencebetweensoftware modules.
3. During the integration, validation, and installation phase
• too large interaction between software modules,
• errors during software corrections or modifications,
• unclear or incomplete documentation,
• changes in the hardware or software environment,
• exceeding important resources (dynamic memory, disk, etc.).
Defects are thus generally caused by human errors (software developer or user).
Their detection and removal become more expensive as the software life cycle progresses (often by a factor of 10 between each of the four main phases of Table 5.3, as in Fig. 8.2 for hardware). Considering that many defects can remain undiscovered for a long time after the software installation (since detected only by particular combinations of data and system states), the necessity for defect prevention through an appropriate software quality assurance becomes mandatory.
Following design guidelines can be useful:
1. Fix written procedures/rules and follow them during software development, such rules specify quality attributes, with project specific priority, and corresponding qualityassurance procedures.
2. Formulate detailed specifications and interfaces as carefully as possible, such specifications/interfaces should exist before coding begins.
3. Give priority to object oriented programming.
4. Use well-behaved high-level programming languages, assembler only when a problem cannot be solved in other way; use established CASE tools for program development and testing (see e.g. IEEE Std 14102-2010 [5.61]).
5. Partition software into independent software modules (modules should be individually testable, developed top-down, and integrated bottom-up (Fig.5.2)).
6. Take into account all constraints given by I/O facilities.
7. Develop software able to protect itself and its data; plan for automatic testing and validation of data.
8. Consider aspects of testing / testability as early as possible in the development phase; increase testability through the use of definition languages (Vienna, RTRL, PSL, IORL).
9. Improve understandability and readability of software by introducing appropri- ate comments.
10 Document software carefully and carry out sufficient configuration management, in particular with respect to design reviews (Table 5.5).
Software for on-line systems (embedded software) should further be conceived to be, as far as possible, tolerant on hardware failures and to allow a system re- configuration, particularly in the context of a fail-safe concept (hardware and software involved in fail-safe procedures should be periodically checked during the operation phase). For this purpose, redundancy considerations are necessary,
• in the time domain (protocol with retransmission, cyclic redundancy check, assertions, exception handling, etc.),
•in the space domain (error correcting codes, NVP, NVS, NSCP (N-self config- uring programming) or parallel processing, used in a majority redundancy, etc.), or in a combination of them. Moreover,if the interaction between hardware andsoftwareintherealizationof therequiredfunctionatthesystemlevel islarge,
Table 5.5 Software design reviews (IEEE Std 1028-1988 [A2.8])
Type Objective
Management Review
Provide recommendations for the following
• activities progress, based on an evaluation of product development status
• changing project direction or identifying the need for alternate planning
• adequate allocation of resources through global control of the project
Evaluation
Technical Review
Evaluate a specific software element and provide management with evidence that
• the software element conforms to its specifications
• the design (or maintenance) of the software element is being done according to plans, Standards, and guidelines applicable for the project
• changes to the software element are properly implemented and affect only those system areas identified by change specifications
Software Inspection
Detect and identify software element defects, in particular
• verify that every software element satisfies its specifications
• verify that every software element conforms to applicable Standards
• identify deviations from standards and specifications
• evaluate software engineering data (e.g. defect and effort data)
Verification
Walk- through
Find defects, omissions, and contradictions in the software elements and consider alternative implementations (long associated with code examination, this process is also applicable to other aspects, e.g. architectural design, detailed design, test plans/procedures, and change control procedures)
software element is used here also for software module; see also Tab. A3.3 for system oriented design reviews;
gate review is often used instead of design review
redundancy considerations should be extended to cover hardware defects& failures, i.e., to make the system fault tolerant (Sections 2.3.7, 6.8). In this context, effort should be devoted to the investigation of causes-to-effects aspects (criticality) of hardware & software faults from a system level point of view, including hardware, software, human factors, logistic support(Sections2.6,4.2,6.10,[1.7,2.87,2.88,5.75]).