Dr. Goodman said he has seen much change in software but has never seen quality. Now software engineers have been talking about six sigma programs that have been successfully applied to hardware. It is not clear that there will be the same success with software. Which products in our lives have the poorest quality and affect us directly or indirectly through our interactions with it? How satisfied are you with software? Are you delighted or disgusted? It is time for new approaches.

Why don't more than 5% - 10% of software projects succeed totally without needing more "Phases"? All of our methodologies from "user needs" until now have not succeeded. We need significantly better quality management that includes not only software itself, but also user service and user support. Needed is significantly better project management that includes development, collaboration and management. We need significantly better client collaboration that includes replacing adversaries with partners and a change in the contracting process that now makes them adversaries. Clients pay our salary. Needed is significantly better external evaluation that includes going outside development methods and project management.

Quality software development has never been consummated. Quality programs at Arco in 1984 and at Los Angeles County in 1994 collapsed with many inputs resulting in few useful outputs. Companies are now using 6-sigma hardware methods on software. There is more hype, yet less visible understanding. This is like trying to present calculus without understanding algebra. Quality is more than buzz words and hand waving accompanied by our complex and trendy "methodology of the moment". Quality is more than evaluation inside processes and is also broader and deeper than "3.4 defects per million opportunities". Quality is not an add-on to development as usual, it is basic re-invention that goes to the core of both processes and people.

Good software quality management procedures can be developed from a synthesis of Deming principles and the Juran trilogy of quality principles. We must identify and understand the client and define his needs. We must do the homework required for high-quality software, service and support. We must specify the requirements and then design software. This includes developing specification features, generating specification processes and then establishing controls. Software should be developed to satisfy specifications. The process must do the vital things required by breaking through into new attitudes that mobilize teams to develop quality software. We must ensure that software is developed that serves the user and diagnose for, steer toward, and break through to service improvement. This requires supporting the user by overcoming resistance, perfecting performance and as a result transiting to new levels of quality software.

Good software management is a process requiring understanding, selection of approaches, management support, adhering to a real budget, properly defining problems and development of a robust architecture. Development should include communication and cooperation; and coordination and control. Coherent specifications must be developed and teams chartered to manage change and resolve conflicts. Teams must collaborate and participate to produce good performance and must be unwavering in producing well documented advances. Management must be deeply involved to conceive, charter, commit and care in order to attain successful software development programs. Management must be responsible and responsive with delineated roles.

Collaboration acts as the key to software quality. The client and the software development team must answer questions and aim for consistent and useful software. They must be in agreement on user needs for software, service and support. Client needs must be converted into specifications that aim for protective use. Quality must be designed into software and provisions for service and support should be defined at the beginning. Development must include aiming for quality and adaptable use of the software product. The quality of the software for the client and users must be a goal both before and after the product release. Quality must be built into many levels of service for clients and users. Quality is not an add-on to development as usual, it must be built into software support for both the client and the software users.

Collaboration commits to quality. The client and the development group should have blended goals that don't compete. You must be in agreement on definitions, verification of software, and service and support needs. There must be a team "conscience" about "dos" and "don'ts" to ensure specifications reflect needs for software, service, and support needs. You must play an essential role with prototypes and "what ifs". State your standards and assist the team in developing its standards. You must think and behave as a partner to prevent mistakes. Review software service for credibility, relevancy, reliability and rationality. You must speak during the entire process as a friend would. This will enhance the team's insights with professional and management capabilities.

Collaboration communicates for quality. You must communicate in the team context and aid self-education, Actively listen and summarize essential items to verify them. Respect and encourage all participants in the process. Convey user needs to developers and verify that they are in the specifications. Discuss the specifications for software support with the users to reassure them and give them security. Precisely relate the development process and quality to the specifications. Describe the validity and sensitivity to use patterns. Be caring and supportive. Describe the service to the users and provide their reactions to the developers and relate consistency and sensitivity of the software to use patterns. Recognize potential problems and advertise them to clients and users. Communicate with software novices as well as with experts. Explain support quality in the user's context. Amplify the effect of any concerns and their potential to the client and users.

Collaboration evaluates quality. Assess software, service and support needs and specifications. Do needs and specifications pass a "sniff test" or do they require significant improvement? Assess the software efficiency and effectiveness quality. Does software quality pass a "sanity test" or require real improvement? Assess service and support by surveys and monitoring. Does user service and support pass "error-analyses" or need improving? Computer technology enables efficient software but also encourages software that might not serve and support effectively. Evaluation can't be done just inside methodology, it must also be evaluated in its service environment by clients and users.

Software development should include evaluation to insure the protection of not only developers, but also clients and users. You have to become the customer and think like the users. Ask "Have we done what we said we were going to do?" before going on to the next stage. There are problems at the beginning in determining "What do we solve?" and at the end "Have we solved it?". Pretend you are the requirements of the clients and users, that you are the specification, and that you are the service they need. Currently the most evil thing is the contracting process where the parties become adversaries. It has built in animosity and competing agendas and everything that goes with it. Something has to be done to change this process.

You can reach Dr. Goodman at: agoodman@uci.edu

Dr. Goodman gave an excellent presentation that was interesting and informative. The write-up presented here provides much of the material presented in his slides, but does not include very many of his insightful remarks and illustrations that made his talk a real pleasure.

This was the fifth meeting of the LA Chapter year and was attended by 17 persons.
Mike Walsh, LA ACM Secretary