The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
heterogeneous software, including Open Systems, Internet, and Common Object Request Broker Architecture standards.
Reflecting these fundamental changes, a consistent theme emerged throughout the committee's deliberations and in presentations from industry and DOD experts: programming language is important, but not as important as a thorough understanding of application requirements, a mature software development process, and a good software architecture. While understanding of requirements is certainly an important factor in project success, it represents a largely language-independent aspect of software engineering and thus is not emphasized in the following discussion. Process maturity and architecture quality, on the other hand, represent aspects of software engineering that are influenced and supported by programming languages and the environments in which they are developed. Furthermore, one very important aspect of "good" processes and architectures is their ability to accommodate changes in requirements.1
While there is much debate over what constitutes an architecture,2 the following observations are made to summarize architecture's importance and its close linkage with modern software development processes:3
Achieving a stable software architecture represents a significant project milestone at which the critical decisions to make, buy, or reuse software should have been resolved. This milestone in a project's life-cycle represents a transition from the exploratory stage (characterized by discovery and resolution of numerous unknowns and sources of risk) of a project to the development phase (characterized by management according to a particular development plan).4
Architecture representations provide a basis for balancing the trade-offs between the problem space (i.e., requirements and constraints) and the solution space (i.e., the product design, implementation, and quality).
The software architecture and process provide the framework for most of the important (i.e., high-payoff or high-risk) human communications among the analysis, design, implementation, and test activities.
Poor architectures and immature processes often underlie many project failures. A mature process, an understanding of the primary requirements, and a demonstrable architecture are important prerequisites for predictable outcomes.
Architecture development and process definition are the intellectual steps that map a problem to its solution without violating existing constraints; these tasks require human innovation and cannot be automated.
DOD's formulation of an improved policy regarding its use of the Ada programming language should take into consideration the fundamental need for improved software architectures, more effective and mature development processes, and increased process automation. Because DOD's requirements for quality—generally high reliability, state-of-the-art performance, and maintainability by DOD personnel—usually cannot be compromised, DOD software development projects often require increased funds and/or extended schedules. The four subsections below describe process and architecture as elements fundamental to needed improvements in software economics—it is this significance of architecture and process that motivates the committee's belief that DOD should expand its software policy to encompass more than just a programming language policy. The discussion below focuses on improving the cost-effectiveness of DOD software and achieving a better return on investment (ROI); it is assumed that quality is held fixed at the levels necessary for DOD systems.