|
Items in cart [0] |
Questions? Call 888-624-8373 |
PAPERBACK PDF BOOK Free Resources |
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
| ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
| Copyright © 2009. National Academy of Sciences. All rights reserved. Terms of Use and Privacy Statement |
Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 7
Perspective
The software research community has not kept up with the development of complex
software systems in industry and government, while in tile field, managers concerned
with procuring software systems often evince idealized and unrealistic views of how
software is developed. A critical reality in the field that is insufficiently appreciated by
academic researchers and systems purchasers is the extent to which existing systems tie
up resources. So-called system maintenance, discussed below, may constitute up to 75
percent of a system's cost over its lifetime. The high cost of maintenance diminishes
the amount of money available to replace existing systems, and it lengthens the payback
period for investment in new system development. It makes designing for a system's
entire life cycle imperative, but such design is rarely if ever achieved. CSTB workshop
participants agreed that to progress in system development, it is time to portray systems
realistically by (1) viewing software systems as systems which has implications for optimal
system design, (2) recognizing that change is intrinsic in large systems, and (3) striving
for a better and more timely blending of software engineering and applications expertise
(see discussions headed "Build a Unifying Model," p. 10, and "Nurture Collaboration,"
p. 17. They also agreed that a more rigorous use of mathematical techniques can help
researchers to manage and diminish complexity.
SHORT-TERM ACTIONS
Portray Systems Realistically
Mew Systems as Systems, not as Collections of Parts
While the computer field has helped to popularize the word "systems" and the
concept of systems, it is ironic that information systems developers have not developed
formal mechanisms to understand systems and the interrelationships among system
components. Software engineering researchers have been unable to provide effective
guidance to practitioners regarding the process of system definition and the concomitant
implementation of functional elements. Progress in developing software systems requires
a fundamental appreciation that those systems are more than just a collection of parts
and that software is embedded in larger systems with a variety of physical components;
7
OCR for page 8
8
design of such systems must deal with both of these issues. Design of software systems
must also take into account the fact that the whole system includes people as well as
hardware, software, and a wide variety of material elements.
Recognize Change as Inoinsic in Large Systems
Software projects are increasingly likely to be built on top of an existing, installed
base of code rather than built anew. As that installed base of software grows over
time, software systems that might or might not have been designed to endure have
been patched, modified, and "maintained," transforming them greatly from their original
designs and functions (Belady and Lehman, 1985~. To factors are at work here: The
first is that systems are often not well-enough designed to begin with, and the second
is that user needs change over time new requirements arise, and existing systems must
be adapted to accommodate them. But commonly used conceptualizations, such as the
"waterfall model" or even the "spiral model," assume a more sure-footed progression
from requirement specification to design to coding to testing and to delivery of software
than is realistic (Royce, 1970; Boehm, 1988~. Given that 40 to 60 percent or more of
the effort in the development of complex software systems goes into maintaining i.e.,
changing-such systems (Boehm, 1981), the design and development processes could be
made more efficient if the reality of change were accepted explicitly.
Sustaining the usefulness of software systems differs from the care of other assets
because it entails two distinct activities: (1) corrective and preventive maintenance,
which includes the repair of latent defects and technological wear and tear, and (2)
enhancement, which normally introduces major transformations not only in the form but
also in the functions and objectives of the software. Enhancement activities have been
observed to constitute perhaps 75 percent of the total maintenance effort.2
The degree and impact of change is analogous to the evolution of an urban neighbor-
hood: Over time, old and obsolete buildings are torn down, the supply of utilities changes
in both quality and delivery aspects, and transportation routes and media change. As new
needs, wants, and capabilities emerge, the structure and function of the neighborhood
evolve; the neighborhood is not thrown out wholesale and replaced because doing so
would be far too costly. As with changes in neighborhoods, changes in software are not
always improvements; software systems suffer from the tension between providing for
functional flexibility and assuring structural integrity of the system.
Software developers in industry and government are increasingly aware that change
occurs from the earliest design stages as initial expressions of customer requirements
are refined. Managing this change involves managing a mix of old code (typically with
inadequate documentation of original specifications as well as modifications made over
time), new programmers, and new technology. The process is ad hoc, and the problem
grows over time; the larger the installed base of code, the more formidable the problem.
The problem is aggravated where management decisions, including Contrnctina rlP.ri~i~
keep developers and maintainers separate.
Ideallyj system designers leave hooks for the changes they can anticipate, but
problems arise from major changes that result from changed circumstances or goals.
Also, schedule and process pressures often militate against providing for functional
flexibility and future changes. Further, the current generation of computer-aided tools
for software engineers concentrates on development activities and generally neglects
maintenance. As a result, supporting information for new code and the tools to exploit
it are not carried forward from development to maintenance. More seriously, these tools
do not accommodate large bodies of code developed without using the tools, although
~^^, ~_ _ _^v ^~ ~ ~
OCR for page 9
9
some progress is being made in the necessary restructuring of programs to accommodate
computer-aided tools.
Just as change, per se, should be accepted as a basic factor In most large, complex
systems, designing for change should become a fundamental body of knowledge and skill.
The very notion of maintenance as an activity separate from the creation process seems
to legitimize high costs, poor support, and poorly managed redesign. Eliminating this
notion via a move toward designing and building systems in anticipation of change would
help to increase the engineering control over post-release modification. Since software
reflects both system specifications and design decisions, changing either element will
indirectly produce changes in the code. One possibility is to strive for designing systems
that are more modular or easier to replace as needs change.
Note that the issue of determining what the software shall do (the `'requirements
definition") is much broader than software engineering practices today would suggest;
this perceptual difference contributes to the maintenance problem. What is needed is a
thorough investigation, analysis, and synthesis of what the combined functions will, or
should, be of the automated and non-automated (human, business, or physical) elements
of the system, including all "think flows," work flows, information flows, and other
functionalities. A total systems approach, as discussed above, would be involved, with a
heavy emphasis on the conceptualization of the functional role of both the automated
parts and the fully combined systems, allowing for reengineering to accommodate or
exploit the changes that are made possible by introduction of the automated system.
Understanding the reasons for change and the costs, impacts, and methods of change
could lead to more control of a major part of software development costs. Creating
mechanisms that allow for change and that make systems robust while undergoing
change will help to reduce opportunity costs in system development and deployment.
Part of what is needed is a change in attitude. But for the long term, a theory of software
systems is needed that will build on empirical study of software system applications.
Study and Preserve Software Artifacts:
Learn From Real Systems Past and Present
Although systems developers work with an evolving set of goals and technologies,
they can still learn valuable lessons from existing systems, lessons about what led to success
or failure and what triggered incremental or major advances. The history of computing
is replete with instances in which identifying the intellectual origins of key developments
is difficult or impossible because most advances, in their time, were not thought of as
intellectual issues but instead were treated as particular solutions to the problems of
the day. Most software specialists would be hard put to name "seven wonders of the
software systems world" or to state why those wonders are noteworthy.3 Meanwhile, the
artifacts of such systems are disappearing every day as older equipment and systems are
replaced with newer ones, as projects end, and as new applications emerge. Because
almost all large software systems have been built in corporate or government settings
where obsolete systems are eventually replaced, and because those systems have received
little academic attention, useful information may be vanishing.
A concerted effort is needed to study (and in some cases preserve) systems and to
develop a process for the systematic examination of contemporary and new systems as
they arise. Immediate archival of major software artifacts, together with the software
tools needed to examine them, or even to experiment with them, would enable both
contemporary and future study. Systematic study of those systems would facilitate
understanding of the ontology of architecture and system components, provide a basis
OCR for page 10
10
for measuring what goes on in software development, and support the construction of
better program generators.
Studies of contemporary systems would provide an understanding of the character-
istics of software developed under present techniques. Such an effort would examine
software entities such as requirements documentation, design representation, and testing
and support tools, in addition to the actual source code itself, which has traditionally
been the focus of measurement. Better mechanisms that provide quantifiable measures
of requirements, design, and testing aspects must be developed in order to understand
the quality baseline that exists today. Existing mechanisms for measuring source code
must be put to more widespread use to better assess their utility and to refine them
(Bowen et al., 1985; McCabe, 1976~. In addition, variations in quality need to be traced
to their sources to understand how to control and improve the process. Thus this effort
should encompass less successful as well as exemplary artifacts, if only to show how poor
design affects maintainability. The examination of artifacts should be combined with
directed interviews of the practitioners (and system users) and observation of the process
to correlate development practices with resulting product quality.
Having quantifiable measurements would enable new, innovative development meth-
ods and practices to be evaluated for their impact on product quality. However, as the
software industry evolves, so too must the measurement techniques. For example, if new
means of representing requirements and design are put into practice, the measurement
techniques must be updated to accommodate these new representations. In addition,
efforts to automate measurement can be improved if researchers consider measurability
as an objective when developing new development methods and design representations.
Such measurement and research cannot take place in the laboratory due to the
size of the actual systems being developed (the costs of experiments at this scale are
prohibitive), and it is unlikely that small experiments can be extrapolated to apply to
large-scale projects. A cooperative effort between government, industry, and academia
could provide necessary funding, access to real-world artifacts and practitioners, and
the academic research talent required for such an effort. Such a combined effort also
would provide an excellent platform for greater collaboration in software engineering
research between members of these communities. Designation and funding of one or
more responsible entities are needed, and candidates include federal agencies (e.g., the
National Science Foundation and the National Institute of Standards and Technology),
federally funded research and development centers, or private institutions.
Finally, active discussion of artifacts should be encouraged. A vehicle like the on-line
RISKS forum sponsored by the Association for Computing Machinery, which provides
a periodic digest and exchange of views among researchers and practitioners on risks
associated with computer-based technology, should be established. Also, completed case
studies would provide excellent teaching matenals.
LONG-TERM ACTIONS
Build a Unifying Model for Software System Development
Shortcomings in software systems often reflect an imperfect fit to the needs of
particular users, and in this situation lie the seeds for useful research. The imperfect fit
results from the nature of the design and development process: Developers of complex
software systems seek to translate the needs of end-users, conveyed in everyday language,
into instructions for computer systems. They accomplish this translation by designing
systems that can be described at different conceptual levels, ranging from language
comprehensible to the intended user (e.g., "plain English" or formal models of the
OCR for page 11
11
LEVELS
User lVodel
Requirement
Architecture
Code
DOMAINS
1
1
Me . ~1 j ,
~--~
1 ' 1 ' II
I ~ Mj j L
1
l
1 ~,
1 - 1
Machine Language I I ~Mn,~ On, 1-
FIGURE 2.1 Illustration of a unifying model for software system design.
application domain) to machine language, which actually drives the computer. Different
spheres of activity are referred to by the profession as end-user domains; these include
the following:
scientific computation,
· · -
eng~neenng c es~gn,
modeling and visualization,
transaction processing, and
embedded command and control systems.
These domains tend to have different types of abstraction and different language re-
quirements arising from differences in the representations of application information and
associated computations. As a result, software developers work with a variety of domain-
specific models. During the design process in any domain, key pieces of information or
insights tend to be lost or misinterpreted.
How can the process of moving from a domain-specific model to a working piece of
software be improved? One approach would be to develop a unifying view of the software
design process and the process of abstraction, a view that would define a framework for
the task of the complex software system developer. CSTB workshop participants did not
reach a consensus on this complicated issue, but to illustrate the point, they began to
sketch out the parameters for such a framework (Figure 2.1~. For example, a system
design can be thought of as a sequence of models, one (Mid) at each level. Different
sorts of details and design decisions are dealt with at each level. The model at each level
is expressed in a language (Icy). Languages are not necessarily textual or symbolic; they
may use graphics or even gestures. Also, languages are not always formally defined.4
Just as the domains of discourse at each level are different, so are the languages.
Finally, the unifying view would distinguish domain-specific models, a multilevel set of
appropriate languages (although it is possible that languages may be shared-or largely
shared across domains), abstractions, and interlevel conversion mechanisms.
OCR for page 12
12
Useful Outcomes
The concept of a uniting model and the associated issues are emblematic of the
larger problem of achieving more complementarily between software engineering research
and practice. A unifying model would not necessarily be of immediate use to a system
builder. But it would be a tool for academic analysis that could, in turn, yield structures
and tools useful to a practitioner. In particular, it could help a researcher to analyze
the software development process and forge imnr`1vemPnI~ Chat might metro that Bran
more efficient in Drnrti~P.
- 0 - - --r ~~ ~,^^ ~ ^~-~ · ~ In
_ _ ~ _ _ ~.__.
For example, a unifying view could help the software engineering researcher to see
the relation among existing mechanisms, to see what mechanisms are missing, and to
devise ways to facilitate transitions from one major conceptual level to another (since it
is necessary to be able to convert a system description at one level to a system description
at an adjacent level).5 By showing how parts are related, unification may facilitate the
collapse of domain-specific models to include fewer levels than at present.6 Eventually,
it may be possible to move automatically from a description of requirements to a
working product, bypassing intermediate levels. The modeling process can facilitate this
progress much as the modeling of production processes in manufacturing has facilitated
the reduction of the number of tasks in manufacturing processes and the application of
manufacturing automation. Also useful, as noted above, is better coordination technology
which would support both the modeling and the development processes.
Research Implications
-~d,
While the theory and nature of program transformation functions, drawing on a
body of knowledge about language that crosses levels (sometimes called wide-spectrum
language), have already been developed (Balzer, 1985; Partsch and Steinbruggen, 1983;
and Smith et al., 1985), the proposed kind of unifying view would also motivate new
styles of research independent from those noted above. Relevant current research ad-
dresses traditional programming language (although some of this research is in eclipse),
computer-supported cooperative work (beyond the mere mechanical aspects see dis-
cussion headed "Nurture Collaboration," p. 17), and efforts to raise the level at which
automation can be applied. Also needed are the following:
· Research that would support the development of domain-specific models and cor-
responding program generators it is critical to recognize the legitimacy of specialization
to the domain at the expense of expressive generality.
· Research to identify domains, levels, and commonalitie.s neuron Hamming cinch
languages are needed for each level and domain.
~.
v ~_4 V-·J ~V111~111 ~111~;
· Research into the architectural level, which cuts across individual domain models.
This level deals with the gross function of modules and the ways they are put together (for
procedure call, data flow, messages, data sharing, and code mingling). The aggregates
defined at this level include "state machine," "object-oriented system," and "pipe/filter
system." Contrast this with the programming level, where the issues are algorithms and
data structures and the defined entities are procedures and types.
· Research into whether it is possible to implement a concept found in the mechan-
ical engineering environment, the quarter-scale model, and if so, how. A quarter-scale
model, which would provide a more precise and detailed correspondence to the desired
system than does a conventional prototype, would help to convey the complexity and
various design attributes of a software system. It would allow practitioners to better
comprehend how well a design works, and it would allow managers to control risk by
helping them to understand where problems exist and to better estimate the resources
OCR for page 13
13
required to solve those problems. In essence, it would make a seemingly intangible
product, software, more real.
· Investigation of the mechanisms for making the transition between and among
the various levels of abstraction. This research would involve exploration of automation
aspects (e.g., compilers and generators) and computer-aided and manually directed steps.
It would also involve exploration of the order of development of the models of a system:
Whereas the conventional waterfall life cycle calls for completing each model before
translating to the next, other approaches such as rapid prototyping or the spiral model
allow for simultaneous development of several models.
· Reformulation of expressions of rigor and technical precision (sometimes referred
to as "correctness"), performance given resources, traceability, cost, reliability, and
integrity.
Strengthen the Mathematical and Scientific Foundations
of Software Engineering
In the absence of a stronger scientific and engineering foundation, complex software
systems are often produced by brute force, with managers assigning more and more
people to the development effort and taking more and more time. As software engineers
begin to envision systems that require many thousands of person-years, current pragmatic
or heuristic approaches begin to appear less adequate to meet application needs. In this
environment, software engineering leaders are beginning to call for more systematic
approaches: More mathematics, science, and engineering are needed (Mills, 1989~.
Workshop participants focused on application of such approaches to software anal-
ysis; they also affirmed the value of mathematical foundations for better modeling and
translation of real-world problems to the abstractions of software systems. Software
analysis, which seeks to assure that software works as specified and as designed, is both
a significant and a critical part of the implementation of large software systems. Unfor-
tunately, analysis activities have received too little focused attention, and what attention
they have received has been largely limited to today's main analytical approach testing.
Sting techniques, moreover, are constantly being discovered and rediscovered.
A more rigorous and comprehensive approach to analysis is needed, one that
renders techniques explicit, teaches about them, and develops its own literature and
authority. In addition to testing, such techniques as proving, modeling, and simulation
should be further developed and targeted to more properties (e.g., safeW and functional
correctness). Work is needed in performing measurements, establishing metrics, and
finding a way to validate them. The understanding of what constitutes a defect and how
to verify that designs or code are defect-free is today very limited.
Note that the ability to find defects earlier in the life cycle of a product or to
prevent them from being introduced reduces test cost and reduces the number of defects
in products delivered to end-users. This ability involves qualifier assessment and qualifier
assurance. Research questions center on how to specify and measure the attributes
(functional, behavioral, and performance) a system must possess in a manner that permits
correct generation or proof. What aspects of a product can be assured satisfactorily only
by testing as opposed to experimentation? What are the economic trade-offs between
developing mathematical proofs and conducting testing? How to design for testability
and verifiability is also an issue here.
Promising directions include the application of formal methods (which involve math-
ematical proofs), exploration of the mechanical and civil engineering concept of a
quarter-scale model for previewing a design, application of the "cleanroom concept"
(featuring waLk-throughs of software with proofs of claims about features rather than
OCR for page 14
14
checklists of flaws; Mills, 1989), and statistical quality control analogous to that used in
manufacturing. A handbook of testing and/or quality assessment is desirable and will be
possible with further development of the field of analysis.
NOTES
1. These conclusions are consonant with those of the Defense Science Board Ask
Force (1987), which focused on management aspects because attitudes, policies, and
practices were a major factor in defense software system acquisition.
2. The National Bureau of Standards (now the National Institute of Standards and
Technology) drew on several studies to decompose maintenance into corrective
maintenance (20 percent), including diagnosis and fixing design, logic, or coding
errors; adaptive maintenance (25 percent), which provides for responses to changes
in the external environment; perfective maintenance (50 percent or more), which
incorporates enhancements; and preventive maintenance (5 percent), which improves
future maintainability and reliability (Martin and Osborne, 1983; Swanson and Lientz,
1980~. Similarly, experience with U.S. Air Force weapons systems suggests that while
15 to 35 percent of software maintenance corrects design errors, 25 to 50 percent
adds new capability, 20 to 40 percent responds to changes in the threat, 10 to 25
percent provides new system interfaces, 10 to 20 percent improves efficiency, 5 to
15 percent improves human factors and ~ tat 1n n'3rrPnt AM .. ~ --are- -
(Mosemann, 1989).
3. An informal query addressed to a community of several hundred software engineering
specialists suggested the following candidates: the SAGE missile defense system, the
Sabre interactive system for airline reservations, the Yacc compiler tool for UNIX,
ARPANET communications software. and the Vi.sir~ ~nr~q~h^~' ~q^~q~~ ^~^-^
others.
4. ~ serve this model-definition role, a language must provide five essential capabili-
ties: (1) component suitability module-level elements, not necessarily compilation
units, with function shared by many applications; (2) operators for combining de-
sign elements; (3) abstraction ability to give names to elements for further use;
(4) closure-named element can be used like primitives; and (5) specification-
more properties than computational functionality, with specifications of composites
derivable from specifications of elements.
This process of transition is sometimes accomplished manually and sometimes me-
chanically. Mechanical transitions (e.g., using program generators or compilers) can
enhance productivity, but they depend on more precision and understanding than
are often available.
6. Overall, the number of levels has grown and shrunk with technology over time. For
example, today few people actually code in machine language, and relatively few
program in assembly code.
--I ~r~~ ~1~ Ullll~UcU ~paolllgr
_, ~,~._~,-~l~c~all~ pa~a,84;, among
Representative terms from entire chapter:
complex software
