Search

Some systems have some but not all properties of systems of systems (SoS). We refer to these as SoS-like systems. This report reviews the fundamental process and project-management problems of large-scale SoS-like programs and outlines steps to address these problems. The report has eight sections. Section 1 summarizes current thinking on the nature of future complex systems, and Section 2 discusses the systems-design problems of the future, particularly the partitioning of massive systems into system-of-systems structures. Section 3 points out how large-scale systems development efforts have typically failed because of project-management and not technical problems, and that the solutions to these problems are known and highly effective, but not widely practiced. It explains why, if the project-management problems of the past are not promptly and effectively addressed, large-scale systems development programs will likely be unmanageable. Section 4 discusses the requirements for a scalable process, and Section 5 both reviews and explains the quality-management principles upon which any scalable process must rest. Section 6 reviews the nature of the project-management problems currently faced by large-scale software-intensive system development efforts and explains why attempts to scale up current methods to very large-scale systems work will almost certainly fail. Section 7 describes process strategies for supporting development of a network-like system of systems and it outlines the process and project-management topics needing further research and development. Finally, Section 8 reviews the process considerations for supporting the very large-scale integrated development programs of the future. The report concludes that, unless steps like those outlined in this report are taken in conjunction with continuing technical research and development, the large-scale systems development efforts of the future will almost certainly fail, and often catastrophically.

Because the Team Software Process (TSP) has proven effective for developing high-quality software applications, a brief review of the safety-critical systems field has been conducted to determine whether the TSP could be usefully extended into this area. This technical note provides a brief overview of recent work in software safety, discusses the problems and implications of using the TSP for developing safety-critical systems, and presents some conclusions. This information is relevant to software developers and acquirers of safety-critical software-intensive systems.

This report characterizes the software processes currently used by software managers and practitioners in the U.S., Japan. The U.S. data for this comparative study of the state of software practice in the U.S., Japan is drawn from extensive SEI assessments conducted from 1987 through 1989. The Japanese maturity data was gathered during a three-week trip to Japan by the authors. This includes data on 168 U.S. projects and 196 Japanese software projects. This data is not a statistically valid sample of the software capabilities of either the U.S. or Japanese software industries. However, the data does indicate that the Japanese software industry is, in some respects, both weaker and stronger than that in the U.S. There are also significant differences in the maturity findings between the U.S., Japanese organizations, and these have important implications for software organizations in both countries.

Automating a software process magnifies its strengths and accentuates its weaknesses. Automation can make an effective process more effective, but it can also make a chaotic process even worse—and at considerable expense. Anyone who buys expensive tools to solve an ill-defined problem is likely to be disappointed. Unless such tools are obtained as part of a thoughtful software process improvement plan, the purchase could be an expensive mistake. This article discusses software process maturity and its relationship to planning and installing computer-aided software engineering (CASE) systems. Although process is not a magic answer (there isn’t one), the key issues are discussed from a process perspective, and guidelines are given for avoiding the most common pitfalls. Because CASE systems can involve significant investment, an economic justification may be necessary. The relevant financial considerations are therefore discussed, and some basic steps for producing such justifications are outlined. Finally, some key considerations for introducing and using CASE systems are discussed.

This report describes software process assessment as it is performed in organizations with the assistance of the Software Engineering Institute. A software process assessment is an appraisal or review of an organization's software process (e.g., software development process). The main objectives of such an assessment are to understand the state of practice in an organization, to identify key areas for improvement, and to initiate the actions that facilitate those improvements. This report is specifically addressed to the organizations and assessment team members that may be involved in an SEI-assisted software process assessment.

This document provides guidelines and procedures for assessing the ability of potential DoD contractors to develop software in accordance with modern software engineering methods. It includes specific questions and a method for evaluating the results.