The Department of Defense (DoD) and its suppliers/developers have arrived at a software crisis. Far too many large-scale software development projects fail. They are unable to deliver needed quality, reliability, and capability within the planned cost and schedule. Their outputs are not predictable. Their processes are little more than chaotic and do not effectively use the kinds of disciplines necessary to achieve success. They have not yet taken advantage of the kinds of management and technical practices that have proven to be effective in other environments. This has got to change.

The software industry needs to produce products in a more consistent, managed, and controlled fashion such that cost, schedule, and product quality can be predicted. R.A. Radice and R. Phillips characterized the situation almost a decade ago.

"We are still at the beginnings of becoming a science. We call ourselves computer scientists or software engineers, but it is more out of anticipation of what these roles offer than from a fully earned position. We, as an industry, still do not keep, analyze, or make public the necessary data to substantially prove our theories or to enable others to repeat our successes. We still cannot do as good a job on a new project as we did on the last."
(Software Engineering: An Industrial Approach, Prentice Hall, 1988, 2-3.)

Software Acquisition Best Practices Initiative

In July 1994, the two officials responsible for virtually all DoD software development decided to meet this challenge head-on. They established the department-wide Software Acquisition Best Practices Initiative to "improve and restructure our software acquisition management process," and to "expand and support the efforts now underway by the Software Program Managers Network (SPMN) to identify and convey these practices." Noel Longuemare, then Acting Under Secretary of Defense for Acquisition and Technology, and Emmett Paige, Jr., Assistant Secretary of Defense for Command, Control, Communications, and Intelligence--themselves SPMN members--used the following words to describe the need for the initiative:

"Current DoD software acquisition practices have not proven to provide an effective framework for managing the acquisition of large-scale software development and maintenance programs that are an essential part of increasingly complex weapons systems."
(Memorandum for Secretaries of the Military Departments,July 8, 1994.)

 One of the most impressive aspects of this initiative is its "bottom-up" focus. It strives to identify practical techniques that program managers can directly apply to their organizations, shaping them to fit their particular program and environment.

Four primary purposes

The initiative had four primary purposes:

• To focus the DoD acquisition community on employing effective, high-leverage software-acquisition management practices
  
• To let program managers focus their software management efforts on producing quality software rather than on activities directed toward satisfying regulations that have grown excessively complex over time
  
• To let program managers exercise flexibility in implementing best practices within disparate corporate and program cultures
  
• To provide program managers and staff with the training and tools necessary to effectively use and achieve the benefits of these practices.

Three main components

Three main components comprised the initiative.

1. A "guru group," the Airlie Software Council, identified practices and their essential details that could improve cost, schedule, quality, user satisfaction, and predictability on large-project development and maintenance. From their work evolved a list of nine best practices.
   
2. Seven issue panels, staffed equally from industry and government by 180 software practitioners, addressed the areas of risk management, program planning and baselining, program visibility, program control, engineering practices and culture, process improvement, and contracting and solicitation. These panels reviewed 163 practices submitted by 56 companies. From these and their members' own experiences on large-scale programs, the panels identified 43 supporting best practices that not only support the nine principal best practices identified by the Airlie Software Council, but also provided insights into advanced management and development techniques.
   
3. The program managers panel, a group composed of highly experienced and successful industry program managers, provided a program manager's perspective and real-world anchor

In the interest of ensuring robust and meaningful results, the Airlie Software Council and issue panels checked and verified each other's outputs. The program managers panel performed a "sanity check" on the outputs of both the Council and the issue panels. All practices underwent an extensive review and comment process. After the initial thrust to create and validate the software best practices, the Airlie Software Council has remained active, maturing and evolving the best practices so they will continue to meet the needs of program managers.

16-Point Plan

Since the publication of the software best practices in 1995, it has become apparent that there are other factors that must be addressed if software projects are to be successful. During its September 1998 meeting, members of the Airlie Software Council reviewed and refined a working draft of a proposed "16 Critical Software Practices for Performance-Based Management," or the "16-Point Plan," for short. The working draft had previously been subjected to a structured peer review by a group of Airlie Software Council members held in July 1998.

Key issues identified during the September review included:

• Risk management should become an integral part of all projects, commencing prior to contract award and continuing through project completion.
  
• Project cost, effort, and schedule should be estimated for planning purposes and as a yardstick for measuring performance (tracking).
  
• Every project needs a project plan that has a detailed activity network defining the process the team will follow, organizes and coordinates the work, and allocates cost and schedule among tasks.
  
• Earned value metrics should be used to measure progress in terms of products produced.
  
• Quality targets should be established for subsystem software (depending on the nature of the system) and should be at the design, coding, integration, test, and operational levels.
  
• Management needs to ensure that all projects maintain a high degree of personnel satisfaction and team cohesion to achieve high levels of staff retention.
  
• Management needs to develop and then implement a configuration management plan to facilitate control of delivered and developmental baselines.
  
• The program should define complete and consistent system requirements and implement a requirements traceability process that traces these requirements through derived requirements and design to code units and individual test cases.
  
• System and software architectures need to be developed and maintained consistent with standards, structured methodologies, and external interfaces specified in the system and software development plans.
  
• Configuration management (CM) should document and control all internal and external interfaces.
  
• Management should ensure that reuse is implemented in a way that results in lower cost and higher quality than would be achieved by developing the reuse artifacts from scratch.
  
• Management should implement a formal, structured inspection/peer review process that will begin with the first system requirements products and continue through architecture, design, code, integration, and documentation products and plans.
  
• The testing process during development should be based on CM-controlled artifacts that will be delivered for use in maintenance to lower the cost of regression test.
  
• Management should use a process of frequent (one-week or less intervals) software compile-builds as a means to find software integration problems early.

These issues have become the foundation for the 16-Point Plan. The Airlie Software Council believes the 16 Critical Software Practices for Performance-Based Management are applicable to all large-scale, software-intensive projects (i.e., projects relying on the full-time efforts of twelve or more people). The practices that comprise it, however, are scaleable, all or in part, to smaller projects and to different software project environments. These 16 Critical Practices should be used as appropriate according to the particular circumstances and environment of a given project including where it is in its life cycle when practices are first adopted. All practices are generally applicable to both government and industry projects and to nearly all domains.

Norm Brown
Director, Software Program Managers Network

top

---