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.
1 3 Engineering Practice The phrase "software engineering" was coined in 1968 as an expression of aspiration.] It remains today more an aspiration than a description.2 The field of software engineering lacks the strengths and structure of other engineering disciplines, which have a more highly developed theory and firmer methodological foundations, as well as widely shared tools and techniques. Engineering disciplines are rooted in craftsmanship and evolve through a commercial stage (with emphasis on production and management) before becoming engineering as we generally know it (see Table 3.1~. What is needed is a way to define and discuss the "parts" of software engineering, the specifications for each, and a conceptual framework within which to place them. Organizing known techniques and information to identify and describe the parts of the software enterprise and how they fit together would go a long way toward enabling cleaner, more flexible design and development processes (Biggerstaff and Perlis, 1989~. SHORT-TERM ACTIONS Codify Software Engineering Knowledge for Dissemination and Reuse Codifying existing software engineering knowledge and disseminating it through handbooks would help achieve several desirable ends: increasing the amount of software that can be created routinely, contributing to knowledge reuse, and ultimately, it is hoped, helping to reduce the size of programs, the time required to develop them, the risk of unacceptable errors, and the tendency to reinvent solutions to the same problems. For software engineering to progress as a discipline, far more "routine" software development must be produced routinely. At a time when our needs for software are beginning to outstrip our ability to produce it, efforts to reduce the number of tasks requiring human effort are one obvious way to improve the situation. Practice in traditional engineering disciplines includes opportunities for both innovative design (creating things that have not been done before) and routine design (creating yet another example of a class of things that is well understood). Current software practice tends to treat most designs as innovative, even when knowledge exists that should render them routine. There is a need to make the reuse of knowledge routine, something many observers lament is far from happening: 15
16 TABLE 3.1 Engineering Evolution Craftsmanship Commercial Practice Professional E. . nglneermg Practitioners Virtuosos and Skilled craftsmen Educated amateurs professionals Practice Intuition and Established Analysis and theory brute force procedure ! Progress Haphazard and Pragmatic refinement Scientific repetitive Transmission Casual and Training in Education of unreliable mechanics professionals SOURCE: "Maybe Your Next Programming Language Shouldn't Be a ProsJr~mmino lo-~' _~:~:^ statement by Mary Shaw, Appendix B. ~{~^ _^A^~^-A& ~6j ~6 ~v~tlUi} Indeed, if builders built buildings the way many programmers wrote programs, then most of us would still be homeless, because builders, like too many programmed, would be busy reinventing their technology every time they built something new. Continually having to rediscover carpentry, metallurgy, and project management, as well as having to writhe A h~lil,1in~ ^ADo ,..1A ~_1.. be enormous disincentives to productivity.... (Booch, 1987) ~&~ = we-a. ~ ~ ~ ~ ~ ~ ~ ~ v Codifying knowledge and making it more accessible could be an important step in moving toward a situation in which machines can do some of the routine tasks, leaving those more complex and creative tasks to humans.3 This is one potent way to improve software development productivity. Award this end, academic researchem clan half nr~rtitir~n~re hv ~lP=Plnnin ~ ~ '~^ 1 r~ 1 a__ _ ~ ~ . _v~E~ ~ ~1~1 11=lll~WolK liar soIIware elements, routine designs, and standard components, much as chemical engineers have developed a framework for the reuse of design elements at a large scale Sperry et al., 1984~. Reuse of code, a less flexible concept than is reuse of knowledge, is the avenue for minimizing programming effort that has been most widely discussed in the software research and development community (Biggerstaff and Perlis, 1989~. Although theoreti- cally attractive, there are many barriers-both technical and sociological to significantly improving the amount of reuse actually achieved. Achieving reuse involves more than building libraries of programs, and it requires research on what kinds of resuse are fea- sible, how to index, how to represent reusable elements, and how to deal with variations in the language in which a piece of reusable code is stated or even in the wording of the specification. But so-called code libraries serve as precursors to the broader concept of handbooks discussed below; current work in that area provides a useful starting point. Develop Software Engineering Handbooks Software engineering should follow the lead of other engineering fields, which codify basic knowledge and use handbooks as carriers of common knowledge, thereby reducing the tendency for dispersed practitioners to independently develop solutions to common problems, duplicating effort while diluting progress. Handbooks for such disciplines as mechanical and chemical engineering allow a broad sharing of general and specific technical knowledge, which provides a base for further progress. Software engineering needs such products; references during the CSTB workshop to heavily used copies of Don Knuth's multivolume work, The Art of Computer Programming (Knuth, 1973), illustrate that a demand exists but remains unmet except in selected, narrow instances. The structure and contents for software engineering handbooks cannot be determined without progress in accomplishing the codification discussed above. What is clear,
however, is that there is a need for substantive as well as process knowledge to be conveyed in these handbooks, and it is that substantive component that distinguishes these handbooks from the manuals that individual organizations use to standardize the software development procedures followed by their employees. Thus handbooks should contain a compendium of algorithms (see, for example, Cody and Waite, 1980), test methods, and items pertaining to design and programming style. Also, to help practitioners work within the practical constraints that they face, handbooks must vary for different domains; the languages, knowledge, and processes associated with, say, transaction processing systems differ from those used for large-scale scientific processing or other types of systems. Given the dynamic nature of the field, a software engineering handbook should be one that can use computer technology to deliver its contents an electronic handbook. The goal is to have a repository of information that creates a uniform organization for current knowledge, presents the information accessibly, and provides a means for updating its contents easily. LONG-TERM ACTIONS Automate Handbook Knowledge 1b maximize the effectiveness of an electronic handbook, advances in several areas that will make such products easy and attractive to use will be necessary. A research initiative aimed at the development of an electronically accessible, interactive software handbook should be inaugurated to develop the following: · concepts and notations for describing designs and components; · techniques for organizing and cataloging designs and components; · techniques and representations for storing, searching, and retrieving designs and components; · codification of routine designs and components for a large variety of types of software and applications; · techniques for evaluating designs and components in terms of engineering trade- offs; · techniques for modeling and simulating systems based on routine designs and components; · criteria for evaluating and accepting or rejecting handbook entries; and · technology to make the handbook easily usable and easily accessible. If the technology and the electronic handbooks can be developed, it will be important to educate software engineers about appropriate methodologies and techniques for using the information they contain. The handbooks themselves will facilitate the teaching of routine design as part of software engineering itself an important step toward increased productivity. Finally, the handbooks should not only be electronically "recorded," but they should also be built into the standard tools of software engineers, making for a truly activist incarnation. Nurture Collaboration Among System Developers and Between Developers and Users Complex software systems are created by the efforts of many people-sometimes as many as a few thousand organized into multiple teams and frequently no one person has a thorough understanding of the interaction of the entire system. Further, the software
18 developers must communicate with end-users and others to understand the application, the issues, and the requirements. System development is an exercise in collaboration, and it is necessary to maximize the effectiveness of that collaboration. Although the team management problem has captured much attention and concern much current software engineering consists of ad hoc measures or what could be called "crowd control"-today's measures do not go far enough (MCC, 1986; ACM, 1988; and Bernstein and Yuhas, 1987~. Methodologies for iterative design are necessary. Specifications will always be idealized and simplified, and neither users nor designers are able to envision the full functionality of the resulting system during the traditional design stages. Consequently, system requirements are not so much analytically specified (contrary to appearances) as they are collaboratively evolved through an iterative process of consultation between end-users and software developers. lbo many projects or designs have been completed that do not accomplish the desired end because substantive information was not well conveyed or understood in the design or implementation process (Curtis et al., 19~). Better linkage of knowledge about application areas or domains with software engineering expertise is essential; it is an important direction for exploration. Another involves developing and sustaining a common world view of systems under development. And a third is gaining understanding about how skilled designers make architectural trade-offs in the designs of systems (R. Guindon, 1988; Shaw, 1989~. Better tools to support and enhance cooperative work are necessary in order to provide productivity enhancements; the more time that programmers can spend designing and programming pieces of systems that uniquely require their attention, as opposed to investing their time to overcome communications difficulties, the more likely it is that systems can be built in less time. Various forms of "groupware," tools for computer- supported cooperative work, may prove well suited to the collaborative process of system development. Also, the development of high-speed, ubiquitous computer networks, coupled with sophisticated and easy-to-use resources available through network access, may provide software engineers with valuable research and development tools (CSTB, 1988~. For example, the growth of the information services business has illustrated the market potential of data base searching, and handbook implementation will depend critically on network access to data base facilities. The call for improved collaboration is not new, nor are discussions about computer support for collaboration. But it may be particularly timely, since the motivation in this area is high and new tools are appearing and becoming more economical to use. NOTES 1. The classic reference is to the software engineering workshop sponsored by the NATO Science Committee in Garmisch, West Germany, October 7-11, 1968. In gross terms, software engineering is concerned with the practical aspects of developing software, such as design under various constraints and economic delivery of software products. It overlaps all of the various specialties of software research, including programming languages, operating systems, algorithms, data structures, data bases, and file systems, and it also addresses such cross-cutting qualities as reliability, security, and efficiency. 3. Thus it could provide a foundation for exploration of user-programmable application generators, which may be appropriate for smaller systems. ~ _v_ _~ ~,$~5
