The U.S. Air Force's Software Technology Support Center is excited to provide an updated and condensed version of the Guidelines for Successful Acquisition and Management of Software Intensive Systems (GSAM).

We are pleased that prior editions have been so well received and that many individuals and programs have worked hard to implement the principles contained therein. These users also repeatedly requested a more streamlined version of the content. Our goal for this project has been to provide a usable desk reference that would give a brief but effective overview of important software acquisition and development topics, provide checklists for rapid selfinspection, and provide pointers to additional information on the topics covered.

We are excited to provide version 3.0 of these Guidelines for Successful Acquisition and Management of Software Intensive Systems. We are pleased that prior editions have been so well received and that many individuals and programs have worked to implement the principles contained herein. Since this project began, the software community has experienced rapid changes. During the last few years in particular, software acquisition reform has introduced several changes and alterations of many long-held approaches. In the first few chapters we have tried to address these changes and accompanying issues. Likewise, we have updated information related to systems and software. We have left intact discussions dealing with software engineering principles since these tried-and-true principles do not change much often, its putting them into consistent practice that is forgotten.

The turnover in the Department of Defense (DoD) acquisition and management work force has suggested additional reasons for these Guidelines. The entire work force has not been fully acclimated to the new approaches embodied in the acquisition reform policies. Also, we have witnessed many situations where individuals have repeated inappropriate or unsuccessful practices. Our hope is that the lessons learned by the past generation of acquisition managers and systems developers will put the new kids on the block on a success-oriented path. Hence, we have included information and emphasized concepts that may seem old-hat to those of you with experience but are completely new for others.

A central theme of these Guidelines is how to turn an adverse situation into a success - how to turn a challenge into a victory. The most important ingredient in achieving these goals, the most crucial resource in producing a quality product, is the people selected to do the job. The skills, talent, experience, creative abilities, or lack thereof, of the team are the determinants of success of failure in the software world. These Guidelines cover the gamut of software life cycle management activities, from pre-acquisition strategic planning to post-deployment software support. They condense and assimilate into one document the range of guidance now being used for the acquisition and management of software intensive systems DoD-wide. PART 1 - Introduction, provides a basic overview of why major software acquisitions fail or succeed, the unique DoD software environment, and soft-intensive system life cycles and methodologies. PART II - Engineering, focuses on risk management. Ada, software development maturity, measurement and metrics, reuse, and software tools and support. PART III - Management, covers the software development process, software quality assurance, contract management techniques, and continuous process improvement. These Guidelines should be read by all levels of managers involved in the development and acquisition of major software-intensive systems. Program Executive Officers (PEO's), Designated Acquisition Commanders (DAC's), program managers, software maintainers, engineers, action officers, and technical personnel will all benefit from the guidance provided herein.

In its role as an agent for improving software technology use within the U.S. Air Force, the Software Technology Support Center (STSC) is supporting metrics technology improvement activities for its customers. These activities include: disseminating information regarding the U.S. Air Force Policy on software metrics [AP93M-017], providing metrics information to the public through CrossTalk, conducting customer workshops in software metrics, guiding metrics technology adoption programs at customer locations, researching new and evolving metrics methodologies, etc.

This guide covers the following:

• It defines a metric capability evaluation method that deals specifically with defining a customer's metrics capability.
• It presents metrics capability questionnaires that help gather metrics capability data.
• It outlines a metrics capability evaluation report that provides the basis for developing a metrics customer project plan.
• It provides a metrics customer profile form used to determine the initial information required to prepare for a metrics capability evaluation.
• It provides a customer organization form that helps guide the STSC in gathering cultural information about the organization that will help with developing and implementing the metrics customer project plan.

Software Quality Assurance (SQA) is a group of related activities employed throughout the software life cycle to positively influence and quantify the quality of the delivered software.

This report provides an overview of SQA, outlining process and product assurance and the methods and technologies typically employed to accomplish them. These methods include audits, assessment activities (e.g., ISO 9000), analysis functions such as reliability prediction, and embedded defect detection methods such as formal inspection. The overview is intended to help the reader identify specific SQA activities for more in-depth study.

This report also describes several representative publications on the subject of software quality assurance, assessment standards, and inspection to help the reader find a reliable source for further research. It concludes with an annotated bibliography of public-domain papers on the subject of SQA.

This technical report has been developed by the United States Air Force (USAF) Software Technology Support Center (STSC) under the direction of the Embedded Computer Resources Support Improvement Program (ESIP) program office. The report can be used to identify training sources or develop training material for the purpose of software process improvement. It can also be used to identify technology, commercial, and professional solutions for analysis and insertion in a software development or maintenance organization.

This report is divided into eight sections. Following is a brief description of each section. Section 1, contains an introduction to and summary of the report. Section 2, provides an overview of project management standards, theory, and terminology. Section 3, provides case studies illustrating the implementation of various software project management approaches. Sections 4, 5, and 6, provide reference information including information about software tools, commercial services, professional societies and symposia, and recommended readings on the topic of project management. Sections 7 and 8 provide a glossary and index of terms used in this report.

The field of Software Engineering has studied many techniques that build software engineering skills. However, there has been little attention paid to the impacts of individual discipline in software development. This report studies technologies that support the disciplined development of software. Software developed in this manner has extremely high quality and software projects that use disciplined methods are completed on or ahead of schedule.

Disciplined software development has two components: individual discipline and team discipline. This report first defines disciplined development. It then reviews what practices are implied by individual discipline and reviews a technology, Personal Software Process (PSP) that supports individual discipline. The report then discusses the issues involved in forming and maintaining development teams and the potential of teams made up of disciplined individuals. The Team Software Process (TSP), a technology that supports teams of PSP trained engineers, is then reviewed.

PSP is a technology focusing on process improvement of the individual software developer. Individual discipline is required to practice PSP. This report describes PSP and the effect of PSP on key performance issues of software engineers. Using PSP, engineers develop software using disciplined, structured methods enabling them to deliver high quality software in a timely manner. TSP extends PSP by realizing the potential of software teams composed entirely of disciplined individuals. TSP shows PSP trained engineers how to develop an effective team to consistently produce high quality software products on schedule and within budget. Watts Humphrey of the Software Engineering Institute (SEI) developed these two technologies as an extension to his earlier Capability Maturity Model (CMM)® work. PSP is described in his book A Discipline for Software Engineering.

This report is intended to be an unbiased summary of published information on PSP and TSP. The intended audience is a PSP neophyte, an individual who knows very little about PSP and TSP, but who wants to understand more. Because, this report summarizes all known information it can also be viewed as a resource for the PSP/TSP community. The body of the report includes a high level PSP and TSP tutorial, shorter than a textbook, yet longer than currently available reports and papers. Six appendixes are included. They contain background (acronyms, glossary, and bibliography) and other support information (PSP vendors, WWW resources, and STSC services). The support information is subject to change.

Software development is often thought of as a series of discrete activities: First, you analyze the problem and write down the requirements; then, you design the code; next, you write the code; and finally, you debug your creation. Unfortunately, this view of software production is extremely outdated. Today, software creation needs to be viewed as a series of discrete steps, plus many continuous processes that guide the software creation process and inject quality into the creation effort. The purpose of this report is to explain the relationships between the discrete and the continuous activities and also to give a brief overview of both discrete and continuous activities.

The definition of a software process is embodied in how a software organization does business, that is, how management and engineering practices are implemented to support software development and/or maintenance. This view of software process assumes that an organization has a set of building blocks that defines the general way it does business and that some subset of those building blocks is implemented for each software project.

This report has been developed to address the most obvious issues that arise when tailoring a set of building blocks to the unique aspects of a software project. The report discusses the concept of software processes at the organization and project levels and how these processes are implemented through software development plans. An example is used to show how an organization's standard software process can be tailored and implemented as a project's defined software process. The report presents information on automated tool support for documenting a project's defined software process and providing inputs to a project plan based on the chosen software process.

Software Configuration Management (SCM) is the backbone of the software development process. When it is implemented correctly it helps ensure software quality and process improvement.

The purpose of this report is to provide current information on basic SCM principles, methods, and technologies, and identify their value in improving software quality. It should be used as a first step in transferring effective SCM processes and products into practical use.

This report also provides an overview of SCM concepts, what it is and how to implement an SCM process as well as SCM standards, current trends and future directions for SCM, measurements and metrics, case studies, and lessons learned.

Emphasis is placed on the need for organizations to develop a long-term SCM solution by developing a detailed SCM plan and defining the SCM process before implementing an automated system.

The purpose of this report is to increase awareness and understanding of software testing technologies in particular, test preparation, test execution, test evaluation, and source code static analysis tools. Use of this report should be the first step in transferring effective software test processes, methods and tools into practical use. This report was written for organizations responsible for the development and maintenance of computer software. This report explains how the features of current testing technologies can improve software development and maintenance. It includes information about specific products in the marketplace. This information is aimed at those who must make decisions about acquiring advanced technology and prepare their organizations to use it effectively.

The purpose of this report is to increase awareness and understanding of documentation technology. Use of this report should be the first step in transferring effective documentation principles, methods, and products into practical use. The target audience of this report consists of those managers and technical people responsible for the development and maintenance of software in their organizations. This report defines the concepts of the Documentation Domain and identifies their value in improving software quality and productivity. It explains how the capabilities of current documentation products can improve management of software development and maintenance projects. It includes information about specific products in the marketplace. Also included are case studies of organizations that are using documentation domain technology. The information is aimed at those who must make decisions about acquiring advanced technology and who must prepare their organizations to use it effectively. Finally, this report attempts to identify the future direction of the field to help in planning long-range strategies.

This report examines the software challenges facing today's Air Force and the role of SEE technology in meeting these challenges. The concepts of SEE technology are introduced and explained. The report examines current SEE technology and provides information about specific products in the marketplace. Finally, the report addresses future directions in SEE technology as an aid in planning long-range strategies.

This document, is a synopsis of the progress of the Software Technology Support Center (STSC) in evaluating requirements analysis and preliminary design computer-aided software engineering products. Throughout this report we will refer to these requirements analysis and preliminary design computer-aided software engineering products as Upper CASE products. The targets of this report are organizations responsible for the development and maintenance of computer software. This report defines the Upper CASE products and identifies their value in improving software quality. It explains how the features of current Upper CASE products can improve software development and maintenance. It includes information about specific products in the marketplace. The information is aimed at those who must make the decisions about acquiring advanced technology and prepare their organizations for its effective use. Finally, this report attempts to identify the future directions of the field to help plan long-range strategies.

Volume I is a synopsis of the progress of the Software Technology Support Center (STSC) in evaluating process technologies. A software process is a set of activities, methods, practices, and transformations that people use to develop and maintain software and associated products. Process technologies are defined as those technologies that can be applied to support an organization's software process.

The purpose of this report is to increase contact, awareness, and understanding of software reengineering tools. Use of this report should be the first step in transferring effective software reengineering processes, methods, and tools into practical use. The targets of this report are organizations responsible for the development and maintenance of computer software. This report defines the ideas of software reengineering and identifies their value in improving software quality for embedded, MCCR, and MIS applications. It explains how the features of current reengineering tools can improve software development and maintenance. It includes information about specific products in the marketplace. The information is aimed at those who must make the decisions about acquiring advanced technology and prepare their organizations to use it effectively. Also, this report attempts to identify the future directions of the field to help in planning long-range strategies. Volume II contains detailed information on reengineering products lists, and product sheets.

The Project Management Technology Domain is a classification of methodologies, tools, theory and practice as it pertains to the field of project management. The purpose of this report is to increase awareness and understanding of project management technology. Use of this report should be the first step in transferring effective project management principles, methods, and products into practical use. The target audience of this report consists of those managers and technical personnel who are responsible for the development and maintenance of software in their organizations.

This report defines the basic concepts of the Project Management Technology Domain and identifies their value in improving software quality and productivity. It explains how the capabilities of current project management products can improve management of software projects. It provides information about specific products in the marketplace. The information is aimed at those who must make decisions about acquiring project management technology and who must prepare their organizations to use it effectively. Finally, this report proposes an identification of future directions of the domain to help in planning long-range strategies and development of an organizational road map toward improved software development.

The definition of a software process is embodied in how a software organization does business, that is, how management and engineering practices are implemented to support software development and or maintenance. This view of software process assumes that an organization has a set of building blocks that defines the general way it does business and that some subset of those building blocks is implemented for each software project.

This report has been developed to address the most obvious issues that arise when tailoring a set of building blocks to the unique aspects of a software project. The report discusses the concept of software processes at the organization and project levels and how these processes are implemented through software development plans. An example is used to show how an organization's standard software process can be tailored and implemented as a project's defined software process. The report presents information on automated tool support for documenting a project's defined software process and providing inputs to a project plan based on the chosen software process.