Printer Friendly

Planning for quality software.

Software Vigilance Pays Off

Whether we find it fascinating or frightening, software is everywhere. It touches almost every aspect of our lives, from international business to personal banking.

Evelyn Richards, reporting in The Washington Post, recently noted, "In a generation's time, software has emerged as the ubiquitous control system of an automated society ... an essential underpinning of America's economic and political standing in the world."|1~

In a series of four articles, Richards pointed out that software is no longer created solely by independent technical specialists. Systems frequently require millions of lines of code, a major task for a team of programmers or even several coordinated teams. Software development should no longer be a mysterious process controlled by a group of specialists behind closed doors.

What are the Risks?

Software and systems are part of the very fabric of day-to-day operations. Twenty years ago, this was not true. A system that failed to function properly was more like an out-of-order copying machine -- inconvenient but not critical to doing business. Not so today. With software supporting every facet of business and government, the system going down is more like the lights going out and the phones not working. Everything can grind to a halt.

Even when the ramifications are not so dramatic -- say you just have a "bug" in the system which interferes with normal operations -- the ultimate price may be higher than you anticipate. Software errors cost you and your organization money. The longer the time before the error is found, the more difficult and expensive it usually is to remedy. Why? Because systems are no longer in the back office. They are in most offices, in the board room, and on the telephone lines linking you and your clients. The more interconnected the computers, the more interconnected and expensive the errors.

Changing of the Guard

As a result of the expanding role of computers and software, the responsibility for keeping things running smoothly is moving higher up the ladder. There are reliable methods for ensuring software quality, methods that involve many parts of the organization. With ever-expanding use of computers and increased reliance on systems, it is not possible to depend only on a systems group. Software quality assurance must be a coordinated effort.

Upper management must take the lead in setting the objectives, planning for quality control, and testing. Since software development involves different departments within most organizations, a plan is needed that ties users, developers, and managers together. Each level of the organization has a role to play.

The user must be taken into account to make sure requirements accurately provide for the tasks to which the software will be put. Managers must be involved in planning for resources and configuration of the system. Upper management is called on to establish quality criteria and assess the overall effectiveness of the software to be developed.

While affecting various parts of the organization, the responsibility for engineering quality into software development rightly begins at the top. Without the involvement of top management, software quality is not likely to make the transition from a specialized "talent" to an institutionalized operating procedure. Quality assurance in software becomes more and more synonymous with ensuring the flow of critical information and business transactions -- a high priority for management.

Hardware is not the Hard Part

Computer hardware is usually not the source of system failures. Hardware is straightforward to test, inspect, and upgrade, can be covered under specific warranties, and is normally maintained on a periodic basis. Software, however, is subject to a complex and sometimes frustrating array of problems.

Software is often a custom-developed product that may have been created under inconsistent standards without a clear understanding of intended use. Software can also "evolve." If uncontrolled changes are made, the system ultimately may not satisfy the original purpose.

Your organization's software requirements may also change over time. If a system is not designed to be easily adaptable to needs that were unanticipated in earlier years, the entire system may become unwieldy, requiring significant expense and time to work around the problem areas.

Why Care About Quality?

Today's global demand for quality products and services has moved quality assurance to the forefront. Just as quality is a requirement in the modern marketplace, quality systems will be a requirement for the competitive survival of corporations and organizations in the future. To have quality systems, companies need to develop specific plans for designing software, operating it and maintaining it.

The Challenge of Comprehending Quality

It can be difficult to understand what "quality software development" means, because software products are intangible. Software components work together, making them hard to inspect and evaluate individually.

There are three basic aspects of software quality: meeting specified requirements; user perception of fitness for use; and value added per unit of development cost. These must be applied to the definition of software which includes not only computer programs, but data and documentation as well.|7~

The most important step in making the connection between these quality aspects and planning for quality software is to develop a working definition of quality that is appropriate for the system producer, user, and client.

Develop Four Plans

Software development has evolved from an art form to a management science. Many large system development projects share some common features, although they may have vastly differing requirements. A standardized system development methodology will have uniform characteristics and planning steps.

The move toward standardization and consistency in systems development means that managers and planners must follow an accepted system development methodology and have a uniform approach to the preparation of system development and quality plans. A plan is needed for each of the following: quality assurance; development; quality control/testing; and configuration.

Software Development Concepts

Basic quality-related system development concepts that are important to understand include the following:

1. Software is durable; it does not change with frequent use and does not decay. Therefore, just as good developers can make a lasting positive contribution to an organization with a quality software product, poor developers can unleash an unending curse with bad software.

2. The system development life cycle covers requirements, design, programming, testing, installation, and maintenance. Using a recognized development methodology allows employees to assimilate into the organization and contribute quickly. Software quality assurance is a full life-cycle activity, because each phase is dependent on the products that are delivered from the previous phase.

3. The cost of correcting an error increases with the span of time in the system development life cycle that the error goes undetected. The further along in the process an error is found, the more rework usually has to be done.

4. Distinctions should be made between the quality of the process used to create a product, the quality of the product itself, and the resources used in production and maintenance. Quality assurance is concerned with the quality of the process, and quality control is concerned with the quality of the product. Configuration management is concerned with conservation of resources.

Quality Assurance Plan

The foundation of quality assurance is process improvement. Every process experiences diminishing returns, even as incremental improvements are made. Eventually, the entire process needs to be re-evaluated, new technology or techniques need to be researched, and new economies of scale recognized. The magnitude of potential change can be so significant that only top management directive and commitment can make success a reality. Among the major concepts to be considered in developing the quality assurance plan are:

* Vision: Top management needs to be demanding and clear as to quality expectations, and define specific responsibilities to work toward establishing a continuous quality improvement cycle. The quality policy is best implemented when accompanied by quality objectives that state measurable, quantifiable goals for quality improvement. Remember, no one opposes quality, but everyone in the organization needs to agree on what it is.

* Cost of Quality: Expenses that do not directly add value to the product should ideally be reduced or eliminated. If a product is built "right-the-first-time," with no defects, rework, or customer dissatisfaction, then costs beyond the direct cost of production would not need to be incurred.|4~

* Professional QA Staff: An independent QA (quality assurance) group should be involved in all levels of reviewing and possibly designing the development process. This group can be authorized to conduct reviews, surveys, and evaluations and be responsible for finding solutions to quality problems.

* Resources: The quality assurance plan should include a list of available quality techniques, tools, and resources as well as a method for allocating resources to each project. Because the best tools and techniques are the ones that transcend levels, it is most productive for top management to identify and communicate available resources to the entire company through the QA plan.

* Measurement: The trend in information system development is to use quantitative methods to model system quality factors such as complexity, reliability, or correctness. A "metric" is a particular type of measurement or formula. These are measures that correlate well with observed error counts, system efficiency, or other characteristics that correspond to quality.|3~

* Conformity: The Quality Assurance Plan outlines goals, objectives, responsibilities, resources, and assignments. The other three plans should draw on this plan for the quality philosophy of the entire company.

Development Plan

A separate development plan can be written for each project. The bulk of this plan covers two components: project management and technical capabilities. The development plan also encompasses seven important concepts.

* Life Cycle: The appropriate system development life cycle (SDLC) phases need to be identified for each project. It is important to be specific about the events in each phase so that project status can be monitored. Note that transition areas are the most difficult SDLC areas to manage because they require skills encompassing both the phase you are leaving and the phase you are entering.

* Process Analysis: During the requirements phase, system users provide input. They need to focus on the process being automated and provide answers to the questions "What do you do?" and "Why do you do it?" The users' contributions to defining requirements should be centered on the information they need to have collected for them and its relevance to their jobs.

* Technology: Designers assess requirements and quality factors and select the appropriate technology to apply to the solution. Technology involves an implementation of science and theory, and designers should be viewed as innovative users of technology. Technological advances often provide the productivity gains that lead to competitive advantages.

* Requirements Focus: A requirements focus is more important than ever, primarily because of new automated code-building tools that can generate code directly from specifications. When such tools are employed, your software is only as good as the specifications on which it is based. In software development, genius is the art of reducing a complex problem into simple components.

* Quality Factors: During the requirements phase, the analysis staff needs to identify the quality factors that will characterize the system. These factors are expressed in such terms as "correctness." For example, if "performance" in response time or throughput is a priority, then stating this in quantifiable terms early in the development process will lead to an established set of criteria that will guide development.|4~

* Productivity: Productivity measurements should consider all resources required to correctly produce the product. If we accept that quality is a function of productivity, then improvement in the value added per unit of development cost for a product improves the quality of the product.

* Standards: Establish standards for structured programming, documentation, reporting, and task completion. With appropriate standards, you will not become a hostage to technology that is controlled by only a few technicians. Completion standards will ensure that components do not move between life-cycle stages prematurely. Information on commonly used standards is readily available from organizations such as the National Bureau of Standards, the Institute of Electronic and Electrical Engineers, and the Federal Government.

Quality Control/Test Plan

Quality Control determines fitness for use of all software products. Testing is done by the actual exercising of computer programs to judge how they meet specified requirements.

* Testing vs. Inspection: Testing cannot create a quality product; a concerted effort at all life-cycle stages is required to create a quality product. Testing should validate that the end results address the requirements and that the product is fit for use.

Code inspections verify conformity to programming standards, assessment of testability, modularity, and maintainability as well as conformity to design specifications.|2~

* Test Environment: The development of a comprehensive testing environment is as important as the development of a production environment. A testing environment provides for separate test data, internal files, and test programs that are not inserted into the production system. A test environment allows you to conduct tests that could potentially "crash" the system without affecting production operations.

* Test Strategy: The Quality Assurance plan specifies all tools and techniques available in the organization for improving system quality. The Test Plan indicates where to use them on a specific development project. Selecting the appropriate tools for testing is one of the most important parts of test planning, because there is no one universally correct approach to testing a system.

* Independent Test Team: Independence is important because it encourages an objective evaluation of products. Evaluation should encompass satisfaction of requirements and suitability for a specified purpose, not just technical merits. An independent team should have the flexibility and knowledge to operate in various hardware environments and be able to create test interconnectivity between programs and systems.

* Error Recording: The test team needs a reporting system to document where errors are found. Problems can be logged, to provide a track record for suggesting areas of future review in a particular program or subsystem.

* Risk Analysis: Risk analysis involves calculating the potential loss associated with a system failure against the probability of that failure occurring. When the cost of additional testing exceeds the potential cost associated with an error in a particular program, it is time to stop testing.

Configuration Plan

A configuration is a relative arrangement of parts, with each part identified and placed in proper sequence to create a product or system.|5~

* Identification: The Configuration Control Board (CCB) needs to be concerned about the environmental configuration, hardware configuration, operating system environment, and system utilities to ensure that the correct components are available and in place during development and production. This includes monitoring vendor upgrades to assure that software products can functionally migrate to the modified processing environment.

* Control: The CCB staff tracks changes, prioritizes proposed changes, and determines if these changes should be implemented. The CCB reviews change requests and recommended updates, improvements, and modifications. The CCB maintains a software release schedule to determine when versions of a product are ready to release.

* Status Accounting: The CCB is responsible for controlling the development of the system throughout the development life cycle. The configuration management staff needs to have a checklist for all components of a production-ready program, including documentation, development and test verification, sign-offs at all phases, and completed training.

* Audit: Auditing is an appraisal activity that involves evaluating the effectiveness of controls and compliance with the organization's policies and procedures. It determines if operations are efficient and effective, and ensures that business objectives are being properly fulfilled. The overall focus is the appropriate use of resources.

Rewards of a Coordinated Effort

Organizations involved in software development will be rewarded for their quality improvement efforts with reduced costs resulting from early detection of errors, and will improve overall quality and user satisfaction by reducing the number of flaws in finished systems.

Because of the time and money required to make endless corrections, companies can no longer risk carelessly planned or poorly monitored software development efforts.

The plans described here create separate areas of responsibility for the development process, deliverable system products and conservation of resources. Separate staff duties need to be created for each purpose in order to avoid conflicting perceptions of the role of the groups.

Effective software quality assurance is a challenge that requires strategic planning and a long-term commitment. Management can make well-coordinated software development pay off in terms of reduced costs, enhanced software life cycles, and higher productivity. The added value to your company will be systems that improve competitiveness and support your goals--now and in the future.


1. Richards, E. (1991). The Software Snarl, The Washington Post, Washington, DC, Dec. 9.

2. Beizer, B. (1984). Software Testing and Quality Assurance, New York: Van Nostrand Reinhold Company, Inc.

3. Perry, W. E., (1988). A Structured Approach to Systems Testing, Wellesley, Massachusetts: QED Information Sciences, Inc.

4. Perry, W. E., (1986). Hatching the Data Processing Quality Assurance Function, Orlando, Florida: quality Assurance Institute.

5. Schulmeyer, G. G. and McManus, J. I., (1987). Handbook of Software Quality Assurance, New York: Van Nostrand Reinhold Company, Inc.

6. Test Tools. (1990). D. Meredith, host. International Conference on Software Testing, Quality Assurance Institute, Orlando, Florida, November.

7. TQM Culture. (1991). L. E. Ellsworth, host. Conference on Total Quality Management in an Information Activity, Quality Assurance Institute, Orlando, Florida, May.
COPYRIGHT 1992 Society for the Advancement of Management
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1992 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Delgado, Rafael F.
Publication:SAM Advanced Management Journal
Date:Mar 22, 1992
Previous Article:Performance appraisal effectiveness: a matter of perspective.
Next Article:Resuscitating the comatose firm: changing management responsibilities under Chapter 11.

Related Articles
ERP Vendors Struggle in a Difficult Market.
DTR integrates quality management software.
Service level agreements as vehicles for managing acquisition of software-intensive systems.
Address standardisation and customer record linking within mySAP CRM.
Address standardisation and customer record linking within mySAP CRM.
Data quality dashboard.

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters