The Quality Movement demonstrated its capabilities in Japan after World War II. The Japanese economy was in shambles after the war and needed to be revived. Gen. Douglas MacArthur made a request for W. Edwards Deming, a management consultant, statistician, and professor emeritus, to help restore Japan. Deming introduced his concept of Quality Management to the struggling nation. Only a few years after Japanese manufacturers implemented Deming’s Quality Management techniques, they experienced increases in productivity and quality. Deming’s work in Quality Management was responsible for the miraculous rebuilding of the Japanese economy. His improvements to the manufacturing process turned post-war Japan into a leader in the manufacturing of products sold around the world.
Quality Management, as realized by Deming, is composed of two distinct groups: Quality Assurance (QA) and Quality Control (QC). The QA group is process oriented, focused on the processes used by the projects performed within the organization. The QA group does not take part in the manufacturing of the product; they are only there to monitor the process used. During this monitoring activity, QA confirms that standards and compliance issues are followed. The effects of the activities performed by QA are reduced waste, lower costs, better training, and institution of an organization-wide direction to improve quality. The QC group is product oriented, responsible for improving the quality of an individual project by performing inspections, testing, and the necessary corrective actions.
Software Quality Assurance
The software industry attempted to leverage Deming’s Quality model to varying degrees of success. Organizations customized Deming’s Quality model to fit their culture as well as tried to compensate for differences between the manufacturing of physical products and creation of intangible products, such as software. Recent events indicate that the software industry has not succeeded in creating the infrastructure necessary to consistently produce quality software. Recent national news has reported major software failures in the airline industry, with flights shutting down across the country and security breaches at major retailers where credit card information of millions of customers was stolen. In a government study by the National Institute of Standards and Technology (NIST), inadequate infrastructure for software testing is costing the U.S. economy $60 billion a year. Undoubtedly, there have been misconceptions and confusion on the proper way to implement Software Quality Assurance (SQA) to improve software quality. It is time for the software industry to take on the serious challenge of improving the software that is critical to every aspect of our lives. The following are just a few services that properly implemented SQA can provide to improve the quality of today’s software.
Standards must be enforced by SQA to create quality software and improve efficiency. Standards can be used to define the language of the software requirements and the format of the source code. It can define how well the software is documented and also define technical information, such as how software will exchange data with other systems. Another form of software standards is compliance issues. Software may be subject to a number of private and public compliance regulations. Credit card companies established the Payment Card Industry Data Security Standard (PCI DSS) for the proper handling of credit card information. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) protects the privacy and security of health information. Section 508 of the Rehabilitation Act of 1973 requires that all electronic information systems be accessible to people with disabilities. Other compliance standards that can easily affect the quality of software are the Federal Information Security Management Act (FISMA), Gramm-Leach-Bliley Act, Sarbanes-Oxley (SOX) Act, Control Objectives for Information and Related Technologies (COBIT), and ISO/IEC 17799:2000.
Reviews and Audits
SQA personnel perform audits to ensure quality guidelines are being followed on all software projects. Any non-compliance problems that cannot be quickly resolved within the software project should be reported to and addressed by senior management.
SQA personnel ensure that testing of the software is properly planned and conducted by QC. Project Test Plans are created and followed during software testing to confirm that the software requirements are properly written and test cases can be derived from them. SQA also ensures that QC properly executes the test cases and accurately documents the defects found.
Defect Collection and Analysis
Finding, reporting, and fixing software defects can be one of the most expensive and time-consuming parts of software development. By collecting information on the defects found during a project, the SQA department can perform techniques, such as Root Cause Analysis to determine the cause of software defects. Using this information, similar defects can be prevented from occurring again by improving the software development process or introducing new technologies. Eliminating future defects will increase productivity, lower costs, and improve quality.
It is easy to become overwhelmed and intimidated by the complex technical nature of software development. No one can keep up with the explosion of advances in all types of software. The SQA group must provide an education program for members of an organization so they can stay up to date, learn new concepts, and brush up on old technologies. When employees become more knowledgeable from these educational programs, they produce higher-quality work and lower project costs by reducing the number of defects and shortening development times.
SQA members perform risk management activities to identify potential problems so mitigation plans can be created. There are many types of risks to software projects. These include Schedule risks, which arise when there is a slip in completion of a task because resources are not properly determined or the scope of the project suddenly expands. There are Budget risks, which arise when cost overruns occur due to unplanned activities. Operational risks occur when there is a failure to follow the defined process due to lack of resources, communication, or training. Technical risks arise due to changing requirements, integration problems, or complication due to the software product being too complex to implement with the current state of technology. There are also unknown risks that are beyond the control of an organization, such as changing government rules, new compliance laws, changing markets changing, or changing customer priorities. Unmitigated risks have caused many software projects to end in failure or seriously compromise the quality of the software developed.
The goal of SQA is to guarantee the quality of sensitive data as it is processed, stored, or transmitted. This includes ensuring the software application can resist attacks from known threats. To achieve this, the SQA group must establish and update threat scenarios for the developers as well as the SQC team. By providing this information early in the project, everyone will have a better understanding of how to avoid introducing vulnerabilities and improve the quality of the software.
Safety Management is another risk-based activity. It involves looking at the software from the point of view of what happens if a module fails. This type of risk analysis is critical for developing control software that prevents putting people’s lives in jeopardy or causing major financial loss. If a certain module fails in the software of a jet aircraft in flight, does the software failure put the passengers in danger? If a module fails in an automated stock purchasing program, does it mistakenly purchase thousands of shares costing an investment firm millions of dollars? These safety risks must be mitigated to lower catastrophic loss from minor software defects.
Safety mitigation is about planning solutions to address anticipated problems. Safety risk assessment and mitigation can be addressed through a process known as Failure Mode and Effects Analysis (FMEA). FMEA meetings often include a wide variety of people to brainstorm ideas and plan the mitigation strategy. Team members may include database administrators, software developers, software testers, and system administrators. During the meeting, they provide different points of view on what will happen if a hardware component or a software module fails. Once the consequence is understood, the safety risks can be prioritized and risk mitigation plans created. The mitigation plans can vary from checking the validity of module inputs to a total rewrite of the software module to guarantee that a failure in a minor module does not take the entire system offline.
The responsibilities outlined above are a small sample of the capabilities a properly implemented SQA department can offer an organization. The SQA in many organizations are inappropriately filled with engineers focused only on creating and running test cases on the products of the software development effort. This is a typical misunderstanding of many organizations; engineers that are focused on project quality are performing Software Quality Control instead of Software Quality Assurance. What today’s organizations need are Software Quality Assurance departments capable of managing and monitoring the quality of the entire organization. Only then can they trigger Deming’s chain reaction of improving productivity, lowering cost, and continuously increasing quality.