Barry Boehm, "Software Design and Structuring," Practical Strategies for Developing Large Software Systems, edited by Ellis Horowitz, 1975, pp. 103-128 (pdf)
In 1974, the major leverage point in the software process is at the software design and structuring stage. This stage begins with a statement of software requirements. Properly done, the software design and structuring process can identify the weak spots and mismatches in the requirements statement which are the main sources of unresponsiveness of delivered software. Once these weak spots slip by the design phasel they will generally stay until during or after delivery, where only costly retrofits can make the software responsive to operational needs.
The software design and structuring phase ends with a detailed specification of the code that is to be produced, a plan for testing the code, and a draft set of users' manuals describing how the product is going to be used. Software costs and problems result from allowing coding to begin on a piece of software before its design aspects have been thoroughly worked out, verified, and validated.
This paper provides a classification of software design and structuring techniques into a few main categories which can currently be considered as software design alternatives. For each alternative, it presents a short description and a balance sheet indicating the advantages and difficulties in using the technique.
In an overall comparison of the alternative techniques, none of them provides positive assurance of satisfying all the criteria, but each criterion is satisfied by at least one of the techniques. This would lead one to believe that an appropriate synthesis of the techniques might prove successful.
The following major design and structuring alternatives will be described and evaluated: Bottom-up, Top-down stub, Top-down/Problem Statement, Structured Programming, and Model-driven Design.
Added June 6th, 2008
Barry Boehm, Robert K. McClean, D. B. Ufrig, "Some Experience with Automated Aids to the Design of Large-Scale Reliable Software," IEEE Transaction on Software Engineering, Volume 1, Number 1, March 1975, pp. 125-133 (pdf)
This paper summarizes some recent experience in analyzing and eliminating sources of error in the design phase of large software projects. It begins by pointing out some of the significant differences in software error incidence between large and small software projects. The most striking contrast, illustrated by project data, is the large preponderance of design errors over coding errors on largescale projects, not only with respect to numbers of errors, but also with respect to the relative time and effort required to detect them and correct them.
The paper next presents a taxonomy of software error causes, and some analyses of the design error data, performed to obtain a better understanding of the nature of large-scale software design errors and to evaluate alternative methods of preventing, detecting, and eliminating them.
Based on this analysis of observational data, a hypothesis was derived regarding the potential cost-effectiveness of an automated aid to detecting inconsistencies between assertions about the nature of inputs and outputs of the various elements (functions, modules, data bases, data sources, etc.) of the software design. This hypothesis was tested by developing a prototype version of such an aid, the Design Assertion Consistency Checker (DACC), using TRW's Generalized Information Management (GIM) system, and using it on a large-scale software project with 186 elements and 967 assertions about their inputs and outputs.
Of the 121,000 possible mismatches between input and output assertions, DACC found 818, at a cost in computer time of $30. Most of the mismatches resulted from shortfalls in the initial version of DACC or the initial data preparation, such as a lack of a synonym capability and a lack of explicit statements about external inputs and outputs. However, a number of serious mismatches were exposed at a time when they were easy to correct, and a most useful work-list generated of items needing resolution before allowing the design effort to proceed to further detail.
In general, the data confirmed the hypothesis about the general utility of a DACC capability for large software projects. However, a number of additional features should be considered to compensate for current deficiencies (in areas such as manuscript preparation) and to fully take advantage of having the software design in machine-readable form.
Added June 6th, 2008
Copyright 2008 The University
of Southern California
The written material, text,
graphics, and software available on this page and all related
pages may be copied, used, and distributed freely as long as the
University of Southern California as the source of the material,
text, graphics or software is always clearly indicated and such
acknowledgement always accompanies any reuse or redistribution
of the material, text, graphics or software; also permission to
use the material, text, graphics or software on these pages does
not include the right to repackage the material, text, graphics
or software in any form or manner and then claim exclusive proprietary
ownership of it as part of a commercial offering of services or
as part of a commercially offered product.