4 Software Project Reviews

Software Quality Assurance

 

Software Quality Assurance is an umbrella activity applied which is throughout the software engineering process and is used for enhancing the software quality. This encompasses a quality management approach and hence it is an effective software engineering technology. It consists of many steps including formal technical reviews, a multi-tiered testing strategy and control of software documentation. It also takes care of modifications in the documents and changes to it are performed through a standard procedure to assure compliance with software development standards. The main objectives of software quality management are to reduce the “variation between samples” in the developed software product and to improve the quality attributes of the software in terms of reliability, usability, portability, consistency and maintainability.

The software quality assurance is the consideration of many factors including the quality control, quality assurance and the cost of quality. The quality control is achieved through conducting a series of inspections, reviews and tests. The quality assurance is enhanced through the analysis, auditing and reporting activities. The cost of quality is maintained well through the consideration of the appraisal costs, failure costs and external failure costs.

 

Software quality can be defined in many ways. However, all the definitions ensure that software quality must be based onexplicitly specified functional and performance requirements, explicitly documented development standards and implicit characteristics that are expected of all professionally developed software. Moreover, software requirements are the foundation from which quality is measured. Therefore, requirements must be collected properly. In addition, the specified standards define a set of development criteria that guide the manner in which software is engineered. Finally, there is a set of implicit requirements that often goes unmentioned; if software conforms to its explicit requirements, but fails to meet implicit requirements, software quality is suspect.

 

Software Quality Assurance can be provided by applying proper techniques in the five components namely analysis and reporting, Process Definition and standards, formal technical reviews, measurement and test planning and review. System analysis is performed by collecting the requirements from the user, formalizing them and preparing the software requirements specification documents. Moreover, analysis can be modeled using data flow diagrams and use case diagrams. Analysis reports must be prepared for each project stating the functional requirements and non-functional requirements clearly.

Software engineering provides a number of process models such as waterfall model, prototyping model, rapid application development model, fourth generation techniques and agile models. Depending upon the type of application to be developed, a standard model must be chosen. Moreover, standards including capability maturity model, Indian Standards Organization model and IEEE model must be followed so that a good design can be arrived. After this formal technical reviews must be conducted.

 

SQA plan consists of various sections such as management section, documentation section, standards, practices, and conversions section, reviews and audits section, test section, Problem reporting and corrective action section and other tools, SQA methods, change control, record keeping, training, and risk management. The management section describes the place of SQA in the structure of the organization. The documentation section describes each work product produced as part of the software process. The standards, practices, and conventions section lists all applicable standards/practices applied during the software process and any metrics to be collected as part of the software engineering work. The reviews and audits section provides an overview of the approach used in the reviews and audits to be conducted during the project. Test section references the test plan and procedure document and defines test record keeping requirements. Problem reporting and corrective action section defines procedures for reporting, tracking, and resolving errors or defects, identifies organizational responsibilities for these activities.

 

Quality Assurance Elements are standards, reviews and audits, testing. Error/defect collection and analysis, changes management, education, vendor management, security management, safety and risk management. The standards ensure that it is adopted and followed. Reviews and audits performed by SQA personnel to ensure that the quality guidelines are followed for all software engineering work. The testing process is ensured that testing id properly planned and conducted.

 

Error/defect collection and analysis collects and analyses error and defect data to better understand how errors are introduced and can be eliminated. Changes management ensures that adequate change management practices have been instituted. Education takes lead in software process improvement and educational program. Vendor management suggests specific quality practices vendor should follow and incorporates quality mandates in vendor contracts. Security management always ensures use of appropriate process and technology to achieve desired security level. Safety is responsible for assessing impact of software failure and initiating steps to reduce risk. Risk management ensures risk management activities are properly conducted and that contingency plans have been established.

 

SQA Tasks are to prepare the SQA plan for the project, participate in the development of the project’s software process description, review software engineering activities to verify compliance with the defined software process, audit designated software work products to verify compliance with those defined as part of the software process. Ensure that any deviations in software or work products are documented and handled according to a documented procedure and record any evidence of noncompliance and reports them to management.

 

The major goals of SQA are requirements quality, design quality, code quality and quality control effectiveness. The requirement qualities are Ambiguity, Completeness, Volatility, Traceability and Model clarity. Design qualities are Architectural integrity, Component completeness, Interface complexity and Patterns. The code qualities are Complexity, Maintainability, Understandability, Reusability and Documentation. The effectiveness of quality controls such as Resource allocation, Completion rate, Review effectiveness and Testing effectiveness. Statistical Quality Assurance is the collected and categorized information about software defects. Each defect is traced back to its cause using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the “vital few” defect causes and move to correct the problems that caused the defects in the “vital few”. The next step in quality assurance is reviews.

Reviews are nothing but a meeting conducted by technical people for technical people. Moreover, it is a technical assessment of a work product created during the software engineering process. It can also be considered as a software quality assurance mechanism and a training ground for the project members. However, reviews are not for providing project budget summary, scheduling assessment, overall progress report and a mechanism for reprisal or political intrigue.

It is possible to ensure the quality through reviews. Figure 2 shows the participants and methods used in a software project review.

 

 

Reviews can be effective if it is conducted in a formal method. In such a scenario, the review presenter will make a power point presentation to the review committee members. In addition, the review presenter will submit a report on the work completed by him. Reviews can be substituted through other means such as casual conversation, informal presentation, walk through and inspection.

 

Review participants are review leader, standards bearer, producer, reviewer, user representative, recorder and maintenance oracle. The review process will be conducted typically with three to

five people on the review team. Advance preparation is required but should not take more than 2 hours per person and the duration of meeting should be two hours or less. The guidelines for review are to be prepared. The reviewer must review the product but not the producer. Moreover, the reviewers must keep their tone mild and ask questions instead of making accusations. They must set an agenda and maintain it throughout the review process and limit the debate and rebuttal and record issues for further discussion off-line. Moreover, they must enunciate problem areas, but they should not attempt to solve every problem noted. They must take written notes and the recorder should collect the critical concerns so that wording and prioritization can be assessed by other reviewers as information is recorded. In addition, they must limit the number of participants and insist upon advance preparation and develop a checklist for each type of work product that is likely to be reviewed. Moreover, it is necessary to allocate resources and time schedule for formal technical reviews and conduct meaningful training for all reviewers. The reviewers must review their early reviews and avoid discussions of style. They have to stick to technical correctness and it is necessary that reviews must be scheduled as project tasks and record and report all review results.

Reviewer’s preparation must be such that the participants understand the context. First, they can skim all product materials to understand location and format of the information. Next, they can read the product material and annotate hardcopy. The reviewers must pose their written comments as questions and avoid issues of style. The member must inform the review leader if they cannot prepare.

 

Metrics are used for measuring the software quality. The important metrics from reviews are inspection time per page of documentation, inspection time per KLOC or FP, inspection effort per KLOC or FP, Errors uncovered per reviewer hour, Errors uncovered per preparation hour, Errors uncovered per SE task (e.g., design), Number of minor errors (e.g., typos), Number of major errors (e.g., nonconformance to requirement) and Number of errors found during preparation.

The statistical quality assurance is the information about software defects is collected and categorized. In this process, an attempt is made to trace each defect to its underlying cause and using the principle that 80% of the defects can be traced to 20% of all possible causes and find  the 20%. Once these vital few causes have been identified, they can move to correct the problems that have caused the defects.

 

The computation of Reliability and Availability is as follows:

  • MTBF = mean time between failure
    •  End users are concerned with failures, not with the total defect count
    • MTBF = MTTF and MTTR
    • MTTF = mean time to failure
    • MTTR = mean time to repair
  • Availability = MTTF/(MTTF + MTTR) x 100%.
  • In this way, it is possible to compute the reliability and availability of software systems. In this model, it is not possible to provide 100% reliability. However, it is possible to maintain quality up to 99.999%, here the 5 nines used in this model was applied to the failure analysis on telephone lines and found that the availability was nearly 99.999%. This corresponds to ~5.3 minutes per year out of service. Therefore, nothing can be 100% pure or 100% perfect. Even an Ivory Soap will be only 99.44% pure which is the maximum limit for quality of soaps. Similarly, if software’s are developed with 99% availability and 99.9% availability, then it is a good software

Summary

 

In this topic, the use of reviews for software quality management is discussed. There are many important points which are to be noted from this discussion. First, software quality must be ensured at all phases of software development lifecycle. Second, quality can be enhanced using inspections and also by conducting periodical reviews for monitoring the project activities. Third, reviews help to assess the quality of completed work. Finally, metrics must be applied suitably to measure quality.