|
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 1
Introduction and Summary
. .
Business, government, and technical endeavors ranging from financial transactions to
space missions increasingly require complex software systems to function. The complexion
of the software arises from stringent requirements (e.g., for reliability in performance
and integrity of the data used), the need to support a range of interactions with the
environment in real time, and/or certain structural features (see Table 1.I). These at-
tributes make software difficult to produce and often require large-scale projects involving
the efforts of several hundred-even a few thousand programmers, software engineers,
applications experts, and others working for one year or more. The difficulty of de-
veloping complex software systems tends to force delays in the implementation of new
applications, compromises in what those applications can do, and uncertainties about
their reliability. (See Box for a more detailed characterization of the problem.) As a
result, there is a perception in the field, especially in industry, that opportunity costs are
large and growing.
How can this situation be improved? The problem has resisted the efforts of
many talented individuals over many years. Some degree of resistance to change is
inevitable, reflecting the inertia that comes from the large and cumulative investment
that companies have made in their software development processes, but CSTB workshop
participants expressed a widely shared frustration that options circulating within the
software engineering community fall short of what is needed (or fall on deaf ears).
Solutions suggested in the past have ranged from ways to improve tools used by software
developers to ways to improve the management of software development teams; they
have often been couched as options for improving productivity in software development,
itself a slippery and many-sided concept.
AGENDA FOR S OFT VVARE ENGINEERING RESEARCII
Directions for Change
Acknowledging those suggestions and accepting that there may be no "silver bullet"
in this area (Brooks, 1986), CSTB workshop participants reached the consensus that
progress will be made if the vast array of existing and emerging knowledge can be
codified, unified, distributed, and extended more systematically. Software requirements
1
OCR for page 2
2
TABLE 1.1 Observations on Complex Systems
.
What makes complex systems complex? Is complexity inherent when software is the focal point of the
system? How can we characterize the complexity of software systems? Can we identify avoidable and
unavoidable kinds of complexity? Looking at systems frown a broad perspective, we see several ways in
which they may be complex:
stl UCtUpe ~ It _~.~1__
~"U~yb`~mS, modules, macros, down to statements and expressions
Behavior Observable activity of a system
Function Transfonnations on components of the state
Process Flow of control
Reactivity Events to which the system must respond
Timing Constraints on response times
State Persistent and transient data with associated consistency and
Application Requirements from the context in which system will be used
Recovery of state and continuation of reactivity
Security of state from destruction or unwanted inspection
Safety from catastrophic external or internal events
Interfaces with users and other systems
Operations that maintain the state and continuity of the system
Development environment People and processes producing the code
Design and Implementation
Documentation and training
Verification, validation, and certification
correctness invariants
SOURCE: Adapted from "Comnlexitv Mllltinl. Pq..A; ~ A-
Gerhan, Appendix B.
---at ), ^~ .r^~ · ;, GAIL, J~nalySlS~ position statement by Susan L.
for large and complex systems have been outrunning understanding of their fundamental
principles, and software development practices have not filled that gap. Further, the
shared framework of existing knowledge has not grown commensurately with advances
made by individual practitioners. Codification of existing knowledge would help to make
the process of developing routine sofhvare Lehigh in ~x7hat mart ~ :^~
A. . . .
`~;r`;vy saving time and money. It is essential for progress in the reuse of knowledge. A
strategy for dissemination of codified knowlt-.aP Churls ha ~ LEA ~ ' --~-
engineering handbooks.
rat ~
_ -~ mulls Q11 ~1~ W{l~pl OI soI=are
Computer Science and Technolo~v Board worl~hr n n~rtirinan~c~ am. ^^A +~- ~-~
,A~ , ~ ~ r Rae -~ "~1 ~" allay But tware
~ll~lll~t;lul~ research can contribute to the improvement of practice if the research
community broadens its view of what constitutes good research (and amends its reward
structure accordingly. In particular, researchers need to look to practice to find good
research problems, validating results Mince the n^^Ao ^~ r -~ ;~" ~ I In
abstract standards. The problems experienced by practitioners are serious and pressing,
and they call for innovative solutions. The promise of fruitful interactions betw~.n
researchers and nr~titimnprc Oh^~'lA ~. to., ^~ ¢_ ~
-Cat ~ A&~O Vl Led, H.% Wf-.~! :4~ ~nalnor ~^
Rae ~ If ~t~t 1lavc; L[J lounger necks Of r~lt~lra1 Air
between the two groups.
The CRIB workshop underscored the need for both software engineering researchers
and practitioners to accept a more realistic view of the problem. Many of the problems
experienced today reflect implicit assumptions that the flow from software system concept
to implementation is smoother and more orderly than it is, as well as implicit assumptions
that a development process involving project teams is subject to the degree and kind of
control that might be found if a single individual were responsible for the software. A
~^ _~&~A ~11~1~
OCR for page 3
3
CHARACI~ERmNG THE PROBLEM: OBSERVATIONS FROM TtIE FIELD
There are few human endeavors that are as difficult to grasp as a complex program or set of programs. The
relations, processes, and purposes of the elements of a program are difficult to describe and thus difficult to
use as construction elements. Creating tools, methods, or magic to solve these difficulties is extremely hard.
The worst problem is not cost; it's not unreliability; it's not schedule slips. Rather, it's the fact that in the
near future we won't be able to produce requisite software a' all!
Both industry and government do not take management actions which recognize the industry's inability to
efficiently develop large software packages.
The typical system development life cycle is so long that only a few people will have the opportunity to Icam
. . . . . .
by repetition during a typlca career.
The state of practice in software development and maintenance is far behind the state of Ethel art.
Even when more 'modem' software development techniques and technologies are widespread, new and
unanticipated requirements for 'sties' (e.g., usability, installability, reliability, integrity, security, recoverability
reconfigurability, serviceability, etc.) which are not yet taught in software engineering, are not yet part of the
methodology being used, and are not yet 'parameters' to the code generator will necessitate rediscovery and
rework of our complex systems.
[My company's] most significant software problem is duplication of effort; we often write several times what
appears to be essentially the same software.
All problems pale against the issue of chasing the leading edge of technology.... For instance, our
state-of-the-practice can finally handle serial, monolithic systems quite well but our challenge is distributed
parallel, asynchronous applications for which we have little or no practical cnginecring principles.
~ ~ v v v 0~
Industry does not collaborate effectively with the research community in creating the next generation of
software capability and software production technology.
A key motivator for software tools and programmer education in the 1990s will be software evolved over
decades from several thousand line, sequential programming systems into multi-million line, multi-tasking
complex systems.
Without clear understanding of design, developing and teaching skills and developing better tools will continue
to be happenstance.
What we call the problem of requirements generation is actually a poverty of tools, tcchniqucs, and language
to assist business experts and computer scientists in collaborating on a process of transformation which
adequately exploits the knowledge of all.
The worst problem I must contend with is the inability of the software buyer, user, and builder to write
blueprint which quickly leads to a low-cost, correct product.
A m``ct c~r'^~'c nrr~lPm lo
in . . . cost and schcduJe increases due to changing user requircmcnts.
Too often funders, customers, and managers are willing to be 'Jow balled' on effort estimation. The lack of
appreciation for up-front capitalization in the software industry with consequential failures points to a serious
problem confronting us.
Non-programmers dominate modem computer use.... Computer users are interested in results, not in
programming; software must reflect this.
Users of software have reliability and economic (spccd, space, cost) constraints that are of little interest to the
computer scientist; the computer scientist has solutions which, when properly cnginccrcd, could greatly enhance
products.
Technology to enable satisfaction of capability requircmcnts, such as for high assurance, deadline guarantccs
and high adaptability is not being provided, despite need.
We need a true pragmatic test engineering discipline. Today it is a truism that we test until out of money and
time, not because we've achieved results.
Acre is a rigorous science, just waiting to be recognized and dcvcloped, which encompasses the whole of 'the
software problem,' as defined, including the hardware, software, languages, devices, logic, data, knowledge
users, uses, and effectiveness, etc. for end-users, providers, cnablcrs, commissioners, and sponsors, alike.
SOURCE: Quotations from position statements prepared before workshop (/\p~>cndix B).
. .
OCR for page 4
4
TABLE 1.2 Agenda for Software Engineenng Research
Recommended Actions
Short Tenn (1-5 years)
Long Terrn (5-10 years)
Perspective Portray systems realistically Research a unifying model
· View systems as systems for software
· Recognize change as development--for
intrinsic matching programming
languages to applications
Study and preserve domains and design
software artifacts phases .
Strengthen mathematical
and scientific foundations
Engineering practice Codify software Automate handbook
engineering knowledge knowledge, access, and
for dissemination and reuse--and make
reuse development of routine
Develop software software more routine
engineering handbooks Nurture collaboration
Research modes
Foster practitioner and
researcher interactions
among system developers
and between developers
and users
Legitimize academic
exploration of large
software systems in situ
Glean insights frown
behavioral and managerial
sciences
Develop additional research
directions and
paradigms--encourage
recognition of review
studies, contributions to
handbooks
clearer understanding of the realities of software development can lead to improvements
in any of several ways. For example, it may facilitate the identification of valuable tools
that do not now exist, or it may facilitate the identification of fundamental flaws in the
software development process itself. A more realistic view will also make clear the extent
to which problems are technical or are amenable to technical solutions.
Specific Short- and Long-Term Actions
Improving the development of complex software systems requires a series of long-
term (5 to 10 years or more) and short-term (1 to 5 years) measures. The CSTB
workshop reached consensus on several directions for change in software engineering
research, which fall into three interconnected areas: (1) perspective, (2) engineering
practice, and (3) modes of research (see Able 1.2~. These improvements are outlined
below and discussed in greater detail in the body of the report. Carried out together, they
will bring to software engineering strengths found in traditional engineering disciplines,
notably the effective reuse of shared knowledge and a working distinction between routine
and innovative design. Some of these directions have been advanced before; others are
more novel. CSTB workshop participants shared the hope that this new presentation and
the consensus it represents will help to catalyze much-needed changes.
OCR for page 5
s
Perspective
Portray the Software Development Process More Reals calf. Changes in attitude take time
to achieve, but the time is right to push for better models of the software development
process in research, teaching, and management. Idday's systems are conglomerate wholes,
not mere collections of parts, and change is intrinsic in such systems. A new approach
to software design that accounts for system evolution and that aggressively links software
development and application expertise could provide a basis for advances in practice. A
sampling of the software engineering leadership, CSTB workshop participants noted that
outmoded models lead to unrealistic expectations among developers or managers; such
models contribute to delay and diminish quality by engendering inappropriately tight
schedules and complicating the process of mid-course corrections. Further, new attitudes
are prerequisite to other steps being satisfactorily developed and implemented.
Study and Preserve Software Artifacts. A better understanding of the process of system
development would provide useful perspectives and insights for today's researchers and
practitioners. Because such an understanding must be built on the study of actual systems,
itself a dynamic process, an ongoing mechanism for studying innovative systems now in
existence should be established. Looking at snapshots of a system may be easy, but
it does not provide sufficient information to permit realistic portrayal of the software
development process. CSTB workshop participants urged efforts to preserve and study
software artifacts and their development processes in the hope that understanding their
structure and properties would contribute to the development of better experiments,
tools, and software development methods.
Develop Unifying Models and Strengthen Mathematical and Scientific Foundations. Long-
term efforts that will enhance research and education include developing unifying models
for system development and associated languages, which are the basic units of the
software development process. A comprehensive and uniting view of models and
languages would be a valuable analytical device that could help researchers develop
new tools and techniques to enhance the structure and development of large software
systems. Also, strengthening the mathematical and scientific foundations of software
development will help software engineers to improve the quality of software systems and
to produce them more systematically. For example, the degree of rigor in software design
and analysis (including testing and other verification and validation methods) should be
increased.
Engineenng Practice
Codify and Disseminate Software Engineering Knowledge. Codification of knowledge can
help move the practice of software engineering from a craft toward a science. Broad dis-
semination of software engineering insights and techniques that are known now will save
time by making much useful information broadly and conveniently available, thus reduc-
ing duplication of effort and enhancing software development productivity. In particular,
it will help make development of routine software more routine. This dissemination' can
be achieved through software engineering handbooks, providing for software engineers
the reference assistance other types of engineers have benefited from for decades. And
the handbooks need not be limited to conventional book form; they can be developed
and accessed in electronic formats. Over the long term, new technologies (e.g., advanced
networking and data base systems) will enhance the delivery and use of what should be
shared knowledge, but the codification and dissemination process should be launched
now.
OCR for page 6
6
Nurture Collaboration Among System Developers and Between Developers and Users. The
development of large software systems involve. mane n^^nl~ art;~~ ;~ ^~ + "~
· ~ J ' ~''~ 4~ REV J1~ Wilily 111 Al, I
Is especially needed to facilitate communication and ~ ooj~eration between software de
velopers and applications experts and other end-users; this is a long-term issue. Because
software engineers have an incomplete understanding of the process of collaboration,
tools to support software development are not optimal. Support for research into and
development and use of computer-supported tools for collaborative work would improve
the software development process.
Research Modes
Foster Practitioner and Researcher Interaction and Legitimize Academic Exploration of Large
Software Systems. Academic researchers lack access to large complex software systems,
which are developed and used primarily in commercial and defense-related industries. As
a result, these researchers have encountered difficulty in teaching large-system topics and
in identifying good basic research problems related to large-system development. New
ways should be explored to facilitate interaction between software engineers in academia
and industry, including expediting academic exploration of large systems, promoting
outlets for information that would reach both academic and corporate researchers, and
augmenting current teaching of large-system concepts. Legitimizing the study of large
systems (and their development) in situ would be a major step in the right direction.
Glean Insights from Behavioral aide Managerial Science. Collaboration by software engi-
neering researchers with other types of researchers, including those from the behavioral
and management sciences, may lead to insights into the people-driven process of software
system development. Although project management and administration are only a part
of the complex system problem, insights from other disciplines may enhance the planning,
management, and timeliness of system projects, which have resisted efforts from within
the software engineering field.
Develop New Research Paradigms. The filed would benefit from such new efforts as
review and synthesis studies, case studies, and comparative analyses, which have not
made the same mark on software engineering as on other fields, because such studies
would help to advance the codification and reuse of knowledge. Similarly, researchers
should get credit for contributions to the electronic handbooks discussed above.
ORGANIZATION AND CONTENT OF THIS REPORT
The remainder of this report of the CSTB Workshop on Complex Software Systems
examines each research agenda item in turn. Chapter 2 covers the area of perspective,
Chapter 3 discusses engineering practice, and Chapter 4 addresses research modes.
Chapter 5 presents brief conclusions and a call to action. A bibliography is given in a
final chapter. Appendix A lists workshop participants, and Appendix B contains position
statements prepared by individual participants in the workshop.
Determining the details of implementing the measures outlined below was beyond
the scope of the CSTB workshop. It is clear, however, that implementation of the
recommended measures will hinge on funding for corresponding research projects and
other incentives. Selected implementation issues will be addressed in follow-up work by
the CS113.
Representative terms from entire chapter:
software engineering
