|
Items in cart [1] |
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 19
4
Research Modes
~ complement existing directions in software engineering research and to better
address the problem of developing software for large systems, CSTB workshop partic-
ipants identified a need for cross-fertilization between academic software engineering
researchers and practitioners as well as between software engineers and specialists in the
behavioral and managerial sciences. CSTB workshop participants also urged universities
to encourage additional topics and styles of software engineering research and to seek
commensurate funding.
SHORT-TERM ACTION:
FOSTER PRACTITIONER AND RESEARCHER INTERACTIONS
There is little academic investigation of the practices, techniques, or problems out
in the field today. To rectify this situation, greater interaction among researchers and
practitioners is needed as a first step. Such interaction has proved a boon in, for
example, manufacturing engineering. Industry and university collaboration in that field
has provided researchers and students access to real-world problems and constraints,
while providing practitioners with access to creative problem-solving talent and new
techniques.
The interaction of academia, industry, and government in software engineering has
been inhibited by culture and tradition (Besemer et al., 1986~. Although much is known
about how complex software systems are built, there are few connections among the
various repositories of practical knowledge. Much of the expertise in complex software
systems resides in corporations, government research centers, and other nonacademic
institutions. It is largely inaccessible to the academic community because of considerations
of product delivery, proprietary knowledge, and cultural differences between the corporate
and academic communities involved in software research.
That academic computer scientists do not often study large software systems and
the process of developing them is one reason that practitioners often feel that the issues
studied by academia do not adequately address the problems and challenges faced by
builders of large systems-despite an apparently large body of systems analysis, systems
design, and other university courses that do address systems issues. This is particularly
so, for example, for complex systems involving software embedded in other products or
19
OCR for page 20
20
systems (ranging from spacecraft to medical technology) and those systems that involve
distributed processes in multiple nonhomogeneous computing and storage elements.
There are a number of reasons that information generated in our universities flows
only slowb into the commercial sector: Academics do not study large systems because
they do not have them or have access to them, and commercial and academic software
specialists tend to read and have their work published in different journals. On the
other hand, many topflight corporate researchers and developers, to the extent that
they publish at all, do not publish in archival computer science journals because their
topics-problems of practice-are not deemed scholarly.
The disparity in perspective and exposure existing between the academic software
engineering research community and the practitioners of the corporate world hinders U.S.
progress in developing complex software systems. Reducing that disparity is imperative,
and it will require a greater degree of interaction between the two groups. Special
meetings like the CSTB workshop are but a beginning to this process; implementing
an initiative to preserve and study major artifacts, as discussed above, and legitimizing
academic exploration of large software systems, discussed below, are other vehicles for
interaction.
LONG-TERM ACTIONS
Legitimize Academic E - loration of Large Software Systems
Academic investigation of research topics based on problems encountered in the
"real world" by software developers could help industrial and other practitioners in both
the short and long terms. For this to happen, new attitudes and incentives must be
adopted.
As currently structured, most academic departments are not conducive to large-
system research. The tendency of universities to encourage and reward narrow spe-
cializations compounds the problem of a lack of opportunity or funding for access to
large, complex systems by academic software researchers. Another side of this prob-
lem is the focus of the academic world on individual actions, whereas the corporate
world is more team oriented. The realities of academic life-funding, tenure tracks,
and other career concerns militate against an individual academic researcher making a
strong commitment to large Vim r~.~P~rrh unthn,~t rnnciA^ratir~n Fr^~ the ~..~..~;~
environment.
__~_ __ ^ , ~. ,, _~1V&t lIVI11 L11 ~OUllQUllU1118
Furthers whereas industry tends to focus on a problem as it appears in production,
researchers (whether corporate or academic) need to find the underlying conceptual
problems that are amenable to the development of knowledge that transcends a partic-
ular system manifesting a problem. Identification of good research problems based on
production problems is a nontrivial problem that itself requires focused efforts. And
to pursue that research requires analytical advances, as discussed above, inasmuch as
abstract formal models are lacking, language design issues are in eclipse. and testing an`1
measurement have not been formalized.
~. . .
--Of or-- v~^,8~
Funding Is a major consideration. Funding of some considerable magnitude is needed
if large systems are to be built-which is necessary to determine feasibility and studied
in academic settings, because the artifacts being studied are large. Also, while some
universities have state-of-the-art hardware resources (although many do not), universities
seldom invest in software tools and tend to lag behind industry in that area. This is a
problem because there must be a fit between hardware and software across academic
and industrial environments if large artifacts are to be experimented with other than
as text (code). Thus it is difficult to study large systems cost effectively. Solving this
OCR for page 21
21
problem requires innovations in funding, the details of which were beyond the scope of
the workshop but which would clearly involve actions by government research funders,
universities, and companies (including product development as well as research entities).
Another direction for improvement and relief may come from enhanced networking,
such as through the proposed national research network, which would allow dispersed
researchers to share access to artifacts, other researchers, and practitioners (CSTB, 1988~.
If software systems are to be studied in corporate settings, a number of other
difficulties will need to be overcome on the industry side. Resolving these difficulties Drill
take much thought and concerted action; the CSTB workshop identified key directions
for change. The insights and enhancements that software engineering managers and
practitioners seek will come at a price: Industry must be willing to provide support-
finan~ial and human resources, and computer resources for experimentation as well
as access to the records of the proprietary system. Mechanisms would be needed to
compensate industry for its efforts to produce data in a form useful to researchers or for
bearing the risk of experimenting with novel development activities.
Perhaps the biggest concern is protecting the proprietary interests of corporations,
for whom large systems are often a source of competitive advantage. Although the
academic culture is devoted to openness and information exchange, universities are
actively grappling with the problems of protecting corporate proprietary information
that are presented by increasing corporate interest in research on practical problems.
Business schools appear to have solved this problem some time ago. It should be possible
to extend such efforts to apply to academic research into corporate software systems.
Finally, one way to get around some of the difficulties of studying large systems
in corporate settings would be to facilitate the study of large systems in government
settings. The federal government has been the impetus for the development of large-
scale integrated systems, interaction with academic researchers is a long-time tradition
for many government organizations, and government entities are more obligated to
respond to government programs or mandates. However, inasmuch as federal systems are
developed and/or managed by private organizations, limitations on access to design and
development processes and personnel may have to be overcome, as in purely corporate
settings. Also, some peculiarities of federal systems development are not generalizable
to commercial systems. For example, the federal procurement process is associated with
specifications that are much more detailed than those typically generated by commercial
buyers. Study of federal systems may therefore be an option that is second best.
Glean Insights from Behavioral and Managerial Sciences
There is a need to better understand how groups of people collaborate in large
projects involving a variety of participants sharing a rich but uneven distribution of
knowledge and imagination among them. Software engineering research would be en-
hanced by greater interaction with behavioral, managerial, and other scientists that could
lead to increasingly effective contributions to software engineering practice, in part by
accelerating the transfer of technology into and through the software engineering com-
munity. The field has benefited in the past from technology transfer; for example,
configuration management practices and change-control techniques developed in the
aircraft industry were adopted in the l950s and 1960s.
There may be particular value in augmenting the insights of computer science and
electrical engineering with the insights of behavioral and managerial sciences. Since
large software systems will continue to be produced by teams for the foreseeable future,
insights gained in other team contexts may be useful for software engineering. 1b
get those insights it may be necessary for software engineers to actually team up with
OCR for page 22
22
specialists from other disciplines; the benefits of such cross-disciplinary teams have been
demonstrated, for example, in the area of ergonomics, where cognitive and management
science specialists have been brought in to determine how best to complement human
skills with automation. Even within computer science, some areas other than software
engineering have aging software platforms that need to be reimplemented to make them
less brittle and more easily changed or to improve the user interface to take advantage
of workstation technology advances. In such areas software engineers could collaborate
with other types of computer scientists and engineers in new developments that both
produce new tools and serge as the objects of study. The CSTB workshop pointed to a
need for software engineers to glean insight from people with complementary expertise
but did not develop the concept. ~
Develop Additional Directions and Paradigms
for Software Engineering Research
Software engineering research today follows a variety of patterns, including the
following:
building systems with certain properties to show their feasibility;
measuring properties of one or several systems;
· improving the performance of systems along particular dimensions;
· developing abstract formal models for certain domains;
showing how to describe phenomena by designing languages; and
malting incremental improvements on prior work
All of these activities are relevant to complex software systems. But given the nature of
those systems and the problems we face today, some new approaches to research may
also be productive.
Computer Science and Technology Board workshop participants recommended that
the academic research community expand its notion of good research to accept review or
synthesis studies, case studies, comparative analyses, and development of unifying models
for individual or multiple domains. In particular, review or synthesis studies, which are
common in a number of other fields, would support a greater and ongoing codification of
software engineering knowledge and help to minimize the reinvention of techniques and
processes. Finally, if effective handbooks are to be developed, as recommended above,
research that supports such handbooks must be encouraged and rewarded.
Representative terms from entire chapter:
cstb workshop
