National Academies Press: OpenBook

Scaling Up: A Research Agenda for Software Engineering (1989)

Chapter: 4. Research Modes

« Previous: 3. Engineering Practice
Suggested Citation:"4. Research Modes." National Research Council. 1989. Scaling Up: A Research Agenda for Software Engineering. Washington, DC: The National Academies Press. doi: 10.17226/1467.
Page 19
Suggested Citation:"4. Research Modes." National Research Council. 1989. Scaling Up: A Research Agenda for Software Engineering. Washington, DC: The National Academies Press. doi: 10.17226/1467.
Page 20
Suggested Citation:"4. Research Modes." National Research Council. 1989. Scaling Up: A Research Agenda for Software Engineering. Washington, DC: The National Academies Press. doi: 10.17226/1467.
Page 21
Suggested Citation:"4. Research Modes." National Research Council. 1989. Scaling Up: A Research Agenda for Software Engineering. Washington, DC: The National Academies Press. doi: 10.17226/1467.
Page 22

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

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

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

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

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.

Next: 5. Conclusions »
Scaling Up: A Research Agenda for Software Engineering Get This Book
Buy Paperback | $45.00
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

Large and growing opportunity costs are resulting from the inability to produce sophisticated, reliable software in a timely manner. Software engineering presents stubborn problems, but in this book, a group of experts suggest several constructive directions for research. Together, they support the need for greater interaction between researchers and practitioners and more aggressive efforts to share and reuse software engineering knowledge.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook,'s online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!