Click for next page ( 2


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © 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 1
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 1
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 1
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 1
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 1
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.