Download AN OVERVIEW OF SOFTWARE ENGINEERING and more Summaries Software Engineering in PDF only on Docsity!
BRUCE I. BLUM and THOMAS P. SLEIGHT
AN OVERVIEW OF SOFTWARE ENGINEERING
Computer software has become an important component of our defense systems and our everyday
lives, but software development is both difficult and costly. This article examines the similarities and
differences between software and hardware development, the essence of software, modern practices used
to support the software process, and the application of government methods. We also consider the role
of standards and technology centers, and conclude with a view into the future.
INTRODUCTION
Software is a part of everyday life at work and at home. Many things we take for granted are software de- pendent: watches, telephone switches, air-conditioning/ heating thermostats, airline reservations, systems that de- fend our country, financial spreadsheets. The discipline of managing the development and lifetime evolution of this software is called software engineering. Software costs in the United States totaled about $ billion in 1985, of which $11 billion was spent by the Department of Defense. 1 Worldwide, spending was about twice that amount-$l40 billion. At a growth rate of 12070 per year, the United States will spend almost $0.5 trillion annually on software by the turn of the cen- tury. Studies in the early 1970s projected that software would rapidly become the dominant component in com- puter systems costs (Fig. 1). The cost of computing hard- ware over the last few years has fallen dramatically on a per-unit performance basis. That decrease resulted pri- marily from the mass production of denser integrated circuits. Software remains labor intensive, and no com- parable breakthrough has occurred. Thus, the small in- creases in software productivity have not overcome the increased cost of human resources. There is broad agreement on what is to be avoided but a diversity of opinions regarding the best way to de- velop and maintain software. We will examine here why software development is so difficult, what methods are currently available to guide the process, how government methods have responded to those difficulties, and what roads to improvement are being explored. This article, oriented to a technical audience with minimal back- ground in software development, presents a survey of many different methods and tools, for that is the na- ture of the state of the art in software engineering.
THE ESSENCE OF SOFTWARE
DEVELOPMENT
The software process, sometimes called the software life cycle, includes all activities related to the life of a software product, from the time of initial concept until final retirement. Because the software product is gener- ally part of some larger system that includes hardware,
U5 0 u ' E <lJ (^2) <lJ a...
100~---------------r---------------'
Hardware 80 development/maintenance
60
40
20
0 1955 1970 Year
Software maintenance
Figure 1-Hardware-software cost trends.
1985
people, and operating procedures, the software process is a subset of system engineering. There are two dimensions to the software process. The first concerns the activities required to produce a product that reliably meets intended needs. The major consider- ations are what the software product is to do and how it should be implemented. The second dimension ad- dresses the management issues of schedule status, cost, and the quality of the software deliverables. In a large system development effort, we commonly find the same management tools for both the hardware and software components. These typically are organized as a sequence of steps and are displayed in a "waterfall" diagram. Each step must be complete and verified or validated before the next step can begin; feedback loops to earlier steps are included. A typical sequence is shown in Fig. 2 for software development. The steps are de- rived from the hardware development model. In fact, only two labels have been changed to reflect the differ- ences in the product under development: software cod- ing and debugging is similar to hardware fabrication, and software module testing is similar to hardware com- ponent testing.
fohns Hopkins APL Technical Digest, Volume 9, Number 3 (1988)
Analysis 1 -
Analysis of _ '- functions
Detailed design
Code and I-
'-- Module test 1 -
Integration 1 _
" if Operations
Figure 2- Typical software development steps.
This structural similarity in the flow facilitates the coordination and management of hardware and software activities. There are, however, major differences between hardware and software:
- Hardware engineering has a long history, with physical models that provide a foundation for de- cision making and handbooks that offer guidance. But software engineering is new; as its name im- plies, it relies on "soft" models of reality.
- Hardware normally deals with mUltiple copies. Thus, the effort to control design decisions and as- sociated documentation can be prorated over the many copies produced. In fact, it is common to reengineer a prototype to include design corrections and reduce manufacturing (i.e., replication) costs. Conversely, software entails negligible reproduction cost; what is delivered is the final evolution of the prototype.
- Production hardware is expensive to modify. There is, consequently, a major incentive to prove the de- sign before production begins. But software is sim- ply text; it is very easy to change the physical me- dia. (Naturally, the verification of a change is a
fohn s Hopkin s APL Technical Digest, Volume 9, Number 3 (1988)
complex process. Its cost is directly proportional to the number of design decisions already made.)
- Hardware reliability is a measure of how the parts wear out. Software does not wear out; its reliability provides an estimate of the number of undetected errors.
These differences suggest that, even with a strong par- allel between hardware and software, overcommitment to a hardware model may prove detrimental to the soft- ware process. Some common errors are:
- Premature formalization of the specification. Be- cause the design activities cannot begin until the analysis is performed and the specification is com- plete, there often is a tendency to produce a com- plete specification before the product needs are un- derstood fully. This frequently results in an invalid system. Unlike hardware, software can be incre- mentally developed very effectively. When a prod- uct is broken down (decomposed) into many small components, with deliveries every few months, the designer can build upon earlier experience, and the final product has fewer errors. Another develop- ment approach is to use prototypes as one uses breadboard models to test concepts and build un- derstanding. Of course, only the essence of the pro- totype is preserved in the specification; its code is discarded.
- Excessive documentation or control. Software de- velopment is a problem-solving activity, and docu- mentation serves many purposes. It establishes a formal mechanism for structuring a solution, com- municates the current design decisions, and pro- vides an audit trail for the maintenance process. But documentation demands often go beyond pragmatic needs. The result is a transfer of activity from problem-solving to compliance with external standards, which is counterproductive.
- The alteration of software requirements to accom- modate hardware limitations. Since software is relatively easy to change, there is the perception that deficiencies in hardware can be compensated for by changes to the software. From a systems engineering perspective, this strategy obviously is inappropriate. Although it may be the only reason- able alternative, it clearly represents an undesirable design approach.
- Emphasis on physical products such as program code. Because code frequently is viewed as a prod- uct, there is a tendency to place considerable store in it. The most difficult part of software design, however, is the determination of what the code is to implement. In fact, production of the code and its debugging typically take one-half the time of its design. Also, most errors are errors in design and not in writing code. Therefore, managers should not be too concerned with the amount of code produced if the design team has a firm un- derstanding of how they intend to solve the prob- lem. And programmers should not be encouraged
Although the parameters affecting costs, scheduling, and quality vary from project to project, there are some gener- ally accepted trends. Boehm recently identified the follow- ing ten most important industrial software measures or met- rics: 3
- Finding and fixing a software problem after delivery can be up to 100 times more expensive than finding and fixing it during the phases when the requirements and early design are determined.
- You can compress a software development schedule up to 25070 of nominal, but no more.
- For every dollar you spend on software development, you will spend two dollars on software maintenance. (Other studies have shown that the costs associated with perfecting the product represent the largest main- tenance category, and costs associated with making corrections represent the smallest category. The re- maining resources are used to adapt the software to altered requirements. Figure 4 illustrates a typical al- location of costs among maintenance categories.)
- Software development and maintenance costs are primarily a function of the number of source instruc- tions in the product.
- Variations between people account for the biggest differences in software productivity.
- The overall ratio of computer software costs to hard- ware costs has gone from 15:85 in 1955 to 85:15 in 1985, and this trend is still growing.
- Only about 15% of a software product development effort is devoted to programming.
- Software systems and software products each typically cost three times as much per instruction to develop fully as does an individual software program. Software system products cost nine times as much.
- Walk-throughs can catch 60% of the errors.
- Many software phenomena follow a Pareto distribu- tion: 80% of the contribution comes from 20% of the contributors.
A common method of analysis is called "structured analysis." The operational environment is first modeled as a network of input-output transformations and docu- mented in the form of "data flow diagrams" (DFDs). The nodes in the DFDs represent the transformations, and the arcs represent the data flowing to and from the transformations. Each node is given a title suggesting the activity the transformation represents, and each arc is given the title of the data in the flow. To convey mean- ing, abstraction is used to reduce the level of detail. For increased information content, each node can be expand- ed as a DFD; the only restriction is that all data flows to and from that node are retained as inputs to and out- puts from the lower-level DFD. With this approach, one typically models the physical environment and then draws a boundary separating the automated system from the nonautomated system. Data flows crossing that boundary represent the application interfaces. Next, the functions within the boundary are
f o hn s Hopkins A PL Techni ca l Digest, Volume 9, N umber 3 (1988)
Corrective (20%)
Adaptive (25%)
Perfective (55%)
User enhancements (42%) Documentation Efficiency Other
Figure 4- Allocation of system and programming resources to three maintenance categories (reprinted by permission, "Soft· ware Engineering: Problems and Perspectives," IEEE Computer, © 1984, IEEE).
reorganized to provide a more effective implementation of what previously was a nonautomated process. All flows (arcs) and actions (nodes) are labeled, and the nodes are further decomposed into DFDs until each node is well understood. Because the arcs represent abstrac- tions of the data in the flow, " data dictionaries" are created that detail the data organization and content. There are several variations of structured analysis. In the method developed by DeMarco and Yourdon, the low- est-level nodes are described in process- or minispecs that use "structured English" to detail the processing that the transformation must conduct. A sample DFD, dic- tionary, and minispec are shown in the boxed insert. Most structured analysis techniques are designed for information processing applications. The initial goal of this method was to provide a manual technique that would allow the analyst to detail his thoughts systematic- ally and communicate the results to the sponsors and users. Recently, automated tools have been developed to assist in drawing the DFD and maintain dictionaries of the transformations and flows. (Such tools are known as CASE: computer-assisted software engineering.) Var- iations of the DFD also have been adopted for use with real-time systems by adding symbols to model queues and messages transmitted among nodes. The requirements analysis is conducted in a top-down mode. This decomposition approach imposes some de- sign decisions on the product; for example, the DFD es- sentially establishes the module structure for the im- plementation. Some suggest that this is a weakness of such methods: the analyst must make critical design decisions when he least understands the problem being solved. The alternative is a "composition" approach in which one models portions of the system that are well understood and builds the system from those components.
STRUCTURED ANALYSIS DESCRIPTION
The figure below contains a si mple example of the rep- resentation used during structured analysis. For this data flo w diagram (DFD), we assume that there is a parent DFD, with at least five bubbles or acti vi tie s. This diagram is an expansion of the bubble, 5.0, Determine Schedule, of the pa rent activity. Typically a DFD contains fiv e to nine bubbles, although only three are shown. Each bubble is labeled with the ac- ti vity it represents; t he data flows to and from each bubble are labeled; and t he data stores (i.e., the f ile containing the work-breakdow n- structure [WBS] data) and external ele- ments (i.e., the printer) are identified with their special sym- bol s.
5.0 DETERMINE SCHEDULE Schedule Request
Schedule
Examples of composition techniques include the Jack- son System Design and object-oriented design ("design" implying that the process steps have considerable over- lap). In the Jackson System Design, the target system is represented as a discrete simulation, and the implemen- tation is considered a set of communicating sequential processes; that is, the method allows for the modeling of the real-world environment as a computer simulation, which then is transformed into a set of sequential pro- grams that can operate asynchronously. Conversely, ob- ject-oriented design first identifies the real-world objects that the desired system must interact with and then con- siders how those objects interact with each other. There are several versions of object-oriented design, but exper- ience with its use is limited.
Programming in the Large-Design
The design process begins after there is a specification establishing what functions the software is to provide. From the discussion of analysis, we see that there is no precise division between analysis (the decision of what is to be done) and design (the determination of how to realize it). There sometimes is a contractual need to es-
Because the processing for this DFD is clear, there is no need to expand it to another DFD level. Bubble 5.2, Define Schedule, is described in a minispec, which conveys the pro- cessing while avoiding t he detail required of a programming language. For example, " get and list WBS# and WBS TITLE" is several instructions, and the reenter statement after printing the error message implies a GOTO (not shown). Finally, the data dictionary defines the major elements in the data flow. Here, WBS is a table wi th five columns, and Task Group is a set of WBS#s. More detailed defini- tions of the element formats and index schemes may be delayed until additional information is compiled.
PROCESS (MINI) SPECIFICATION
5.2 Define Schedule Process for each TASK in TASK GROUP get and list WBS# and WBS TITLE enter START date enter STOP date if START < STOP then print error and reenter end
DATA DICTIONARY
WBS = WBS# + Title + Start + Stop + Re- sources Task Group = {WBS#}
tablish what the procured software is to provide, so the specification becomes part of the contract that defines the deliverable. In the essential model of the software process, however, there is continuity between analysis and design activities, and the methods often support both activities. The basic process is one of modeling the software sys- tem and adding details until there is sufficient informa- tion to convert the design into a realization (i.e., pro- gram). Design always begins with a specification, which is a product of the analysis step. At times, the specifica- tion is a formal document establishing a set of require- ments. Here, it is important to maintain traceability to ensure that all design decisions are derived from a re- quirement and that all requirements are satisfied in the design (i.e., there are neither extra features nor omis- sions). At other times (e.g. , in the internal development of a product), the specification is less formal, and addi- tional subjectivity is needed to determine that the design decisions are valid. For any set of requirements, there are many equally correct designs. The task of the design team is to select among the alternatives those system decisions yielding
John s Hopkin s APL Technical Digest, Volume 9, Number 3 (1988)
tools have been developed for a specific class of appli- cation (information processing) that facilitate the devel- opment of programs at a very high level. For example, one can produce a report simply by describing the con- tent and format of the desired output; one does not have to describe procedurally how it should be implemented. (Thus, 4GLs generally are described as being nonproce- dural or declarative.)
Validation and Verification
In the traditional descriptive flow for software devel- opment, the activity that precedes operations and main- tenance is called "test." Testing is the process of detect- ing errors. A good test discovers a previously undetected error. Thus, testing is related to defect removal; it can begin only when some part of the product is completed and there are defects to be removed. The validation and verification activity includes the process of testing. But it begins well before there is a product to be tested and involves more than the identi- fication of defects. Validation comes from the Latin vali- dus, meaning strength or worth. It is a process of predict- ing how well the software product will correspond to the needs of the environment (i.e., will it be the right
system?). Verification comes from the Latin verus,
meaning truth. It determines the correctness of a product with respect to its specification (i.e., is the system right?). Validation is performed at two levels. During the anal- ysis step, validation supplies the feedback to review de- cisions about the potential system. Recall that analysis requires domain understanding and subjective decisions. The domain knowledge is used to eliminate improper decisions and to suggest feasible alternatives. The rank- ing of those alternatives relies on the analysts' experience and judgment. The review of these decisions is a cogni- tive (rather than a logically formal) activity. There is no concept of formal correctness; in fact, the software's va- lidity can be established only after it is in place. (Proto- types and the spiral model both are designed to deal with the analyst's inability to define a valid specification.) The second level of validation involves decisions made within the context of the specification produced by the analysis activity. This specification describes what func- tions should be supported by the software product (i.e., its behavior). The specification also establishes nonfunc- tional requirements, such as processing time constraints and storage limitations. The product's behavior can be described formally; in fact, the program code is the most complete expression of that formal statement. Nonfunc- tional requirements, however, can be demonstrated only when the product is complete. Validation and verification are independent concepts. A product may be correct with respect to the contractu- al specification, but it may not be perceived as a useful product. Conversely, a product may correspond to the environment's needs even though it deviates from its specified behavior. Also, validation always relies on judgment, but verification can be formalized. Finally, both validation and verification can be practiced before there is code to be tested; failure to exercise quality con- trol early in the development process will result in the
mUltiplication of early errors and a relatively high cost of correction per defect. Before a formal specification exists (one that can be subjected to logical analysis), the primary method for both verification and validation is the review. In the soft- ware domain, this is sometimes called a walk-through or inspection, which frequently includes the review of both design documents and preliminary code. The review process is intended to identify errors and misunderstand- ings. There also are management reviews that establish decision points before continuing with the next devel- opment step. The two types of reviews have different functions, and they should not be confused or combined. Management reviews should occur after walk -throughs have been completed and technical issues resolved. Most software tests are designed to detect errors, which sometimes can be identified by examining the pro- gram text. The tools that review the text are called "static analyzers." Some errors they can detect (such as iden- tifying blocks of code that cannot be reached) can be recognized by compilers. Other forms of analysis rely on specialized, stand-alone software tools. "Dynamic analysis" tests, concerned with how the program oper- ates, are divided into two categories. "White box" tests are designed to exercise the program as implemented. The assumption is that the errors are random; each path of the program, therefore, should be exercised at least once to uncover problems such as the use of the wrong variable or predicate. "Black box" tests evaluate only the function of the program, independent of its im- plementation. As with equipment testing, software testing is organ- ized into levels. Each program is debugged and tested by the individual programmer. This is called unit test- ing. Individual programs next are integrated and tested as larger components, which are then function tested to certify that they provide the necessary features. Finally, the full system is tested in an operational setting, and a decision is made to deploy (or use) the product. Natu- rally, if the software is part of an embedded system, then, at some level, the software tests are integrated with the hardware tests.
Management
We have so far emphasized the essential features of software development; that is, what makes the devel- opment process unique for this category of product. Some characteristics of the process make it difficult: the software can be very complex, which introduces the potential for many errors; the process is difficult to mod- el in terms of physical reality; there is always a strong temptation to accommodate change by modifying the programs; and, finally, the product is always subject to change. (In fact, the lifetime cost for adaptation and en- hancement of a software product usually exceeds its de- velopment cost.) The management of a software project is similar to the management of any other technical project. Man- agers must identify the areas of highest risk and the strategies for reducing that risk; they must plan the se- quence of project activities and recognize when devia-
Johns Hopkins APL Technical Digest, Volume 9, Number 3 (1988)
tions are imminent; they must budget time, personnel, and dollar resources and adjust these factors through- out the process; they must maintain control over the completed products; and they must establish procedures to ensure a high level of product quality. As with any project management assignment, the manager must understand something about both the do- main of application and the technology to be applied. In well-understood problem areas, this knowledge is less critical because design is reduced to the detailing of some existing design concept. But in new domains there are uncertainties, and management must be sensitive to the early resolution of high-risk problems. (This is one area in which prototyping can be most effective; another is the examination of the human interface.) Although software engineering is a relatively new dis- cipline, there are many tools available to help support its management. Cost-projection tools have been pro- duced that allow a manager to build upon previous ex- perience to estimate cost and schedule. Commercial "configuration control" systems manage the software versions and supply mechanisms to insulate programs from unauthorized or uncertified changes. Many modem program-support environments also contain tools that give management easy access to schedule and status in- formation.
GOVERNMENT METHODS
APPLIED AT APL
The approaches to software engineering taken by APL's sponsoring organizations must be considered both when an operational system is delivered and when a pro- totype is developed that will evolve into government specifications and procurements. For many experiments (e.g., at-sea or space-based), the whole effort is oriented toward quick deployment of existing or slightly modified sensors and support for recording, telemetry, and anal- ysis. There are no sponsor-specified approaches, and development responsiveness often is the critical compo- nent. The software becomes a crucial integrating element. Since existing software must be modified, software en- gineering techniques are applied less formally. In its work on Navy tactical systems, however, APL relies more on the use of standards. The development and acquisition of mission-critical defense-systems soft- ware is governed by DOD-STD-2167A,6 a standard specifying a number of documents that should be gener- ated during software development. This document-driven approach has been criticized for the lack of proper docu- ment selection and tailoring by the government and for ignoring several modern software processes or develop- ment strategies as described above. Although this stan- dard has some drawbacks, it has provided a sound and consistent basis for software development over many years. Recently, it was modified (Revision A) to reflect better the methods available via the Ada language. This standards approach is not new; the DOD standard origi- nated in earlier internal Navy standards. 7 ,8 The other main component in the Navy's approach is the use of specific programming languages. The Navy has attempt-
fohns Hopkins APL Technical Digest, Volume 9, Number 3 (1988)
ed for many years to standardize languages, beginning with CS-I in the 1960s, through the CMS-2 and the in- troduction of Ada. The Navy also has standardized computer hardware, in particular, the AN/UYK-20, and more recently the AN/UYK-44 and AN/ AYK-14, which are the 16-bit common instruction set standards. The AN/UYK-7 is upward-compatible with the newer 32-bit AN/UYK- standard computer. For the Navy to support those com- puters with the new Ada language, the Ada Language System/Navy project is tasked to develop production- quality Ada translators (first released in June 1988) for the AN/UYK-44, AN/A YK-14, and AN/UYK-43. Con- siderable emphasis has been placed on the support of fast interrupts, a requirement of many Navy embedded systems. Within a common command language frame- work, there are tools for version and database main- tenance, software-problem-report tracking, documen- tation updating, and report generation. The Ada language has matured, and the translators are rapidly becoming viable production tools. Some re- cent benchmark programs executing on the MC 68020 processor indicate that the Ada code is almost as fast as code generated by popular C-Ianguage translators. Ada is now a workable language for military use, and the benefits of the object-oriented approach can be ob- tained from specification through operational code and, most important, during evolution and maintenance. APL has explored Ada applications for several tactical systems. Whenever a mature Ada translator and target run-time system have been available, the projects have been successful. One example is the redesign and reimple- mentation of a simplified version of the Aegis Command and Decision System. 9 This project, while successful, also identified several problems with the 1985 Ada tech- nology. Many of those problems have disappeared with more mature Ada products. In follow-on projects, the reuse of both internally developed and externally avail- able Ada modules has been successful. Also, Ada mod- ule integration has been faster, and fewer errors were detected than with other languages. Most software development at APL involves the sup- port of experimental or "one of a kind" systems. Al- though these systems frequently require the proper use of software engineering techniques, they typically are not controlled by the sponsor as is a mission-critical Navy system (i.e., DOD-STD-2167A). This offers an oppor- tunity to try new techniques. For example, in some sat- ellite altimeter work for NASA, the DeMarco and Your- don methodology, with Ward/Mellor real-time exten- sions,1O is being successfully applied using new CASE tools. The recent APL projects requiring Ada have used the Bahr object-oriented design approach, II which (with some modification) has been particularly useful when the target language is known to be Ada. Some pro- jects derived their approach from a combination and tail- oring of DOD-STD-2167A and emerging IEEE software standards. This approach provides guidelines and tem- plates, and helps to alleviate problems arising from staff reassignment and short corporate memory.
for building requirement and design specifications and related code, synthesizing prototypes, performing dy- namic assessments, and managing software development projects. At a recent meeting of companies developing and marketing CASE tools, SPC launched an initiative to establish an industrywide consensus on effective tool- to-tool interface standards. Those standards will repre- sent the fIrst steps in building an integrated environment. MCC was established by 21 shareholder companies in 1983. The consortium has several research programs, ranging from semiconductor packaging to software tech- nology. Each program is sponsored by a subset of par- ticipating shareholder companies. The software technology program focuses on the front end, upstream in the software cycle, where little research has been performed. This program has created a com- puter-aided software design environment call Leonardo. The environment is to concentrate on requirements cap- ture, exploration, and early design. Academic research has focused on downstream activities, where formalism and automation are more obvious. MCC's research em- phasis is on defining and decomposing a large problem into smaller problems and on selecting algorithms, and is geared to teams of professional software engineers working on large, complex systems. Researchers are working on Leonardo architecture, and three compo- nents: complex design processes, a design information base, and design visualization. The corporation does not consider its research com- plete until it is put to use by the sponsoring companies. Also, MCC believes it is easier to transfer and establish tools and make them consistent than to transfer method- ologies and methods.
A VIEW TO THE FUTURE
We began this article with a review of how software differed from hardware and noted that-once the tech- nical manager understands the software process-the management of software is much like that of hardware. We then described the software process, characterized more by variety than by clarity and consistency. Despite our signifIcant accomplishments with software, there re- main conflicting methods, limited formal models, and many unsubstantiated biases. But we present below some significant trends in the field.
Formalization
Some new paradigms extend the formalism of the programming language into an executable specification. A specification defines the behavior for all implementa- tions. An executable specifIcation does not exhibit the intended behavior effIciently, but a program is an imple- mentation of that behavior, optimized for a specifIc com- puter. We see this because there are systems that we know how to specify exactly, but we do not know how to implement them efficiently. For example, one can specify what a chess-playing program should do without being able to describe an efficient implementation. The hope is that the executable specification will supply a prototype for experimentation that ultimately can be transformed into an effIcient program. But the concept
Johns Hopkins APL Technical Digest, Volume 9, Number 3 (1988)
has not been demonstrated outside the laboratory, and it is not clear how this process model can be managed.
Automatic Verification
In the discussion of validation and verification, we noted that proofs (verification) could be objective only when the parent specification was clear (formal). There is, therefore, considerable interest in working with mathematically formal specifications at an early stage in the design process, since it then would be possible to prove that each detailing step was correct with respect to this high-level source. A theorem prover could be used to automate the process. Testing then would not be necessary, because no errors would exist. Naturally, vali- dation still would be required.
Automated Tools and Environments
There is considerable interest in the use of CASE tools and in program support environments. Unlike the for- malisms addressed above, most tools and environments are commercial products that implement techniques de- veloped in the mid-1970s. Thus, these tools and environ- ments respond to a marketplace demand and provide a means for making the application of current practice more efficient. Their primary benefit is one of reducing the manual effort and thereby the number of errors in- troduced. As new paradigms are introduced, this focus may limit their use or force changes in the approaches taken.
Artificial Intelligence and Knowledge
Representation
Although there are many definitions of artificial in- telligence and debates about what it accomplishes, it has had an impact on our perceptions of what computers can do and how to approach problems. The software process is one of representing knowledge about a prob- lem in a way that facilitates its transformation (detail- ing) into an implementable solution. Thus, there are many software engineering methods and tools that owe their origins to artifIcial intelligence. Some projects, such as the development of object-oriented programming, have been successful and are available to developers; many others still are in the research stage. One can ex- pect that a knowledge orientation to the problem of soft- ware design will have considerable impact.
New High-Order Languages
The major advances of the 1960s can be attributed to the use of high-order languages, but it is doubtful that current language improvements will have much impact on productivity. Many proven modern programming concepts have been incorporated into Ada, and the com- mitment to this language clearly will familiarize de-. velopers with those concepts and thereby improve both product quality and productivity. At another extreme, 4GLs offer tools to end users and designers that, for a narrow application domain, yield a tenfold improvement in productivity at a price in performance. Still, neither high-order languages nor 4GLs can match the improve- ments we are witnessing in hardware cost performance.
Software Reuse
The concept of software reuse was first perceived in the context of a program library. As new tools have been developed, the goal of reusable components has expand- ed. For example, Ada packages that encapsulate ab- stracted code fragments can be shared and reused. The artificial-intelligence-based knowledge perspective also suggests ways to reuse conceptual units having a gran- ularity finer than code fragments and program libraries. Finally, the extension of 4GL techniques provides a mechanism for reusing application-class conventions with a natural human interface.
Training and Domain Specialization
All software development requires some domain knowledge. In the early days of computing, the program- mer's knowledge of the new technology was the key, and the domain specialist explained what was needed. To- day, almost every recent college graduate knows more about computer science than did those early program- mers. Thus, there is an emphasis on building applica- tions. As more tools become available, one can expect software developers to divide into two classes. The soft- ware engineer will, as the name implies, practice en- gineering discipline in the development of complex soft- ware products, such as embedded applications and com- puter tools for end users. The domain specialists will use those tools together with the domain knowledge to build applications that solve problems in their special environ- ment. We can see this trend in the difference between Ada and the 4GLs. Ada incorporates powerful features that are not intuitively obvious; the features are built on a knowledge of computer science and must be learned. The 4GLs, however, offer an implementation perspec- tive that is conceptually close to the end user's view. The software engineer builds the language; the domain spe- cialist uses it.
WHAT OTHERS SAY
What do the experts in software engineering say about the future of this discipline and the hope for significant improvements in productivity? In explaining why the Strategic Defense Initiative is beyond the ability of cur- rent (and near-term) software practice, Parnas 15 offered a negative critique of most research paths. He said that the problem involves complex real-time communication demands, adding that there is limited experience in designing programs of this architecture and magnitude and that there is no way to test the system thoroughly. No ongoing approach, he concluded, could overcome these difficulties.
Boehm, I in an article on improving productivity, was more positive. Speaking of state-of-the-art software ap- plications, he offered this advice: write less code, reduce rework, and reuse software-especially commercially available products, where possible. Brooks 16 discusses the possibility of improving soft- ware productivity. He has catalogued research directions in some detail and concluded that the biggest payoff would come from buying rather than building, learning by prototyping, building systems incrementally, and- most important to him-training and rewarding great designers. Of those four recommendations, the first reflects the spinning off of tools that can be used by do- main specialists, and the next two relate to the need to build up knowledge about an application before it can be implemented. The last of Brooks's positive approach- es recognizes that software design (like every other crea- tive activity) depends on, and is limited by, the individu- al's ability, experience, understanding, and discipline.
REFERENCES and NOTES l B. W. Boelun , " Improving Software Productivity," IEEE Computer 20 , 43 - 57 (1987). 2B. W. Boelun, "A Spiral Model of Software De velopment and Enhancement, " IEEE Computer 21 , 61-72 (1 988). 3B. W. Boehm , " Industrial Software Metrics Top 10 L is t ," IEEE S oftware, 84-54 (Sep 19 87). 4T wo books that are hig hl y recommended are R. Fairley, Softw are Engineer- ing Concepts, McGraw- Hill , New York (1985) and R. Pressman, S oft ware Eng in eerin g: A Pra ctitioner's Approach, 2n d ed ., McGraw-Hill , N ew York (1 987). 5Ada is a regis tered trademark of the U.S. Government, Ada Joint Project Office. 6DO D-STD -2 16 7A, "Military Standard Defense System Software Dev elop- ment," (2 9 Feb 19 88). 7MI L-S TD -1 679 (Navy), "Military Standard Weapon Software Deve lopment ," (I Dec 1978). 8SEC AV INST 35 60.1, "Tactical Digital Systems Documentation Standard s," (8 Aug 1 97 4 ).
- F. Sterne, M. E. Schmid, M. J. Gralia, T. A. Grobicki, and R. A. R. Pearce, "Use of Ada for Shipboard Embedded App li cation s," Annual Wash- ington Ada Symp., Washington, D.C. (24-26 Mar 19 85). lOS. J. Me ll or and P. T. Ward, Structured De velopment fo r Real-Time Systems, Prent ice -H al l, En gl ewood Cliffs, N.J. (1986). II R. J. A. Bahr, System Design With Ada, Prentice-H al l, Englewood Cliffs, N.J. (1984). 12G. Tice, "Looki ng at Standards from the World View," I EEE Soft wa re 5, 82 (1988). l3V. G. Sigi llito, B. I. Bl um, and P. H. Loy, "Software Engineering in The Johns Hopkins University Continuing Professional Programs," 2nd SEI Con f. on Software En gi neering Education, Fairfax, Va. (28 - 29 Apr 19 88). 14 J. Foreman and J. Goodenough, Ada Adoption Hand book: A Program Manager's Guide, CMO / SEI-87- TR -9, Software En gi neering Institute (M ay 19 87). 15 D. L. Parnas, "Aspects of St rategic Defen se Sys tem s," Commun. A CM 12 , 13 26 - 1335 (1 985). 16F. P. Brooks, "No Silver Bu llet," I EEE Computer 20 , 1 0- 19 (1 987).
ACKNOWLEDGMENTS-Th e authors gratefully acknowledge the very helpf ul suggestions of J. E. Coolahan , M. J. Gralia, R. S. Gro ss man, and J. G. Palmer.
f o hn s Hopkin s A PL Techni ca l Digest, Vo lume 9, N umb er 3 (1 988)
