Chapter 1

Software Engineering Life Cycle Processes

1. Introduction to IEEE/EIA Standard 12207.0-1996

IEEE/EIA Standard 12207.0-1996 establishes a common framework for software life cycleprocesses. This standard contains processes, activities, and tasks that are to be applied during theacquisition of a system that contains software, a stand-alone software product, and softwareservice during the supply, development, operation, and maintenance phases of software products.

The International Organization for Standardization (ISO) and the International ElectrotechnicalCommission (EEC) published ISO/IEC 12207, Information Technology -- Software Life CycleProcesses, in August 1995. IEEE/EIA Standard 12207.0 is an American version of theinternational standard. IEEE/EIA Standard 12207.0 consists of the clarifications, additions, andchanges accepted by the Institute of Electrical and Electronics Engineers (IEEE) and theElectronic Industries Association (EIA) during a joint project by the two organizations.IEEE/EIA Standard 12207.0 contains concepts and guidelines to foster better understanding andapplication of the standard. Thus, this standard provides industry a basis for software practicesthat is usable for both national and international businesses.

IEEE/EIA Standard 12207.0 may be used to:

• Acquire, supply, develop, operate, and maintain software.

• Support the above functions in the form of quality assurance, configuration management,joint reviews, audits, verification, validation, problem resolution, and documentation.

• Manage and improve the organization's processes and personnel.

• Establish software management and engineering environments based upon the life cycleprocesses as adapted and tailored to serve business needs.

• Foster improved understanding between customers and vendors and among the partiesinvolved in the life cycle of a software product.

• Facilitate world trade in software.

IEEE/EIA Standard 12207-1996 is partitioned into three parts:

• IEEE/EIA Standard 12207.0-1996, Standard for Information Technology - Software LifeCycle Processes: Contains ISO/EEC 12207 in its original form and six additional annexes(E through J): Basic concepts; Compliance; Life cycle process objectives; Life cycle dataobjectives; Relationships; and Errata. A unique IEEE/EIA foreword is included.

• IEEE/EIA Standard 12207.1~ 1997, Guide for ISO/IEC 12207, Standard for InformationTechnology — Software Lifecycle Processes -- Life Cycle Data: Provides additionalguidance on recording life cycle data.

• IEEE/EIA P12207.2-1997, Guide for ISO/IEC 12207-1997, Standard for InformationTechnology — Software Life Cycle Processes — Implementation Considerations: Providesadditions, alternatives, and clarifications to ISO/EEC 12207's life cycle processes asderived from U.S. practices.

2. Application of IEEE/EIA Standard 12207-1996

This section lists the software life cycle processes that can be employed to acquire, supply,develop, operate, and maintain software products. IEEE/EIA Standard 12207 groups theactivities that may be performed during the life cycle of software into five primary processes,eight supporting processes and four organizational processes. One of the primary processes,development, is emphasized in this tutorial set.

2.1 Development process

The development process contains the activities and tasks of the developer. The process containsthe activities for requirements analysis, design, coding, integration, testing, and installation andacceptance related to software products. It may contain system related activities if stipulated inthe contract. The developer performs or supports the activities in this process in accordance withthe contract. The developer manages the development process at the project level following themanagement process, which is instantiated in this process. The developer also establishes aninfrastructure under the process following the infrastructure process, tailors the process for theproject, and manages the process at the organizational level following the improvement processand the training process.

This process consists of the following 12 activities:

1. Process implementation

2. System requirements analysis

3. System architectural design

4. Software requirements analysis

5. Software architectural design

6. Software detailed design

7. Software coding and testing

8. Software integration

9. Software qualification testing

10. System integration

11. System qualification testing

12. Software installation

13. Software acceptance support.

This tutorial only covers seven of the above activities: system requirements analysis and design,software requirements, software architecture and detailed design, implementation (coding),testing and the maintenance process.8 are listed below

1. System requirements analysis. Describes the functions and capabilities of the system;business, organizational and user requirements; safety, security, human-factorsengineering (ergonomics), interface, operations, and maintenance requirements; alsoincludes design constraints and system measurements.

2. System architectural design. Identifies items of hardware, software, and manual-operations. It shall be ensured that all system requirements are allocated among the items.Hardware configuration items, software configuration items, and manual operations aresubsequently identified from these items.

3. Software requirements analysis. Establishes and documents software requirementsincluding functional, performance, external interfaces, design constraints, and qualitycharacteristics.

4. Software architectural design. Transforms the requirements for the software item into anarchitecture that describes its top-level structure and identifies the software components.All requirements for the software item are to be allocated to their software componentsand further refined to facilitate detailed design.

5. Software detailed design. Develops a detailed design for each software component of thesoftware item. The software components are refined into lower levels containing softwareunits that can be coded, compiled, and tested. All software requirements are allocatedfrom the software components to software units.

6. Software coding and unit testing. Coding and unit testing of each software configurationitem.

7. Software integration and testing. Integration of software units and software componentsinto the software system. Perform qualification testing to ensure that the final systemmeets the software requirements.

8. Software maintenance. Modification of a software product to correct faults, to improveperformance or other attributes, or to adapt the product to a changing environment.

2.2 Supporting life cycle processes

The supporting life cycle processes consist of eight processes. A supporting process supportsanother process as an integral part with a distinct purpose and contributes to the success andquality of the software project. A supporting process is employed and executed as needed, byanother process. The supporting processes are:

1. Documentation process. Defines the activities for recording the information produced bya life cycle process.

2. Configuration management process. Defines the configuration management activities.

3. Quality assurance process. Defines the activities for objectively assuring that thesoftware products and processes are in conformance with their specified requirementsand adhere to their established plans. Joint reviews, audits, verification, and validationmay be used as techniques of quality assurance.

4. Verification process. Defines the activities (for the acquirer, the supplier, or anindependent party) for verifying the software products and services in varying depth,depending on the software project.

5. Validation process. Defines the activities (for the acquirer, the supplier, or anindependent party) for validating the software products of the software project.

6. Joint review process. Defines the activities for evaluating the status and products of anactivity. This process may be employed by any two parties, where one party (reviewingparty) reviews another party (reviewed party) in a joint forum.

7. Audit process. Defines the activities for determining compliance with the requirements,plans, and contract. This process may be employed by any two parties, where one party(auditing party) audits the software products or activities of another party (audited party).

8. Problem resolution process. Defines a process for analyzing and removing the problems(including non-conformances), regardless of nature or source, that are discovered duringthe execution of development, operation, maintenance, or other processes.

2.3 Organizational life cycle processes

The organizational life cycle processes consist of four processes. They are employed by anorganization to establish and implement an underlying structure made up of associated life cycleprocesses and personnel, and continuously improve the structure and processes. They aretypically employed outside the realm of specific projects and contracts; however, lessons fromsuch projects and contracts contribute to the improvement of the organization. The organizationalprocesses are:

1. Management process. Defines the basic activities of the management, including projectmanagement related to the execution of a life cycle process.

2. Infrastructure process. Defines the basic activities for establishing the underlyingstructure of a life cycle process.

3. Improvement process. Defines the basic activities that an organization (that is, acquirer,supplier, developer, operator, maintainer, or the manager of another process) performs forestablishing, measuring, controlling, and improving its life cycle process.

4. Training process. Defines the activities for providing adequately trained personnel.

3. Introduction to Tutorial

This tutorial (Volume 1 of the set) has been partitioned into chapters to support the IEEECertificate for Software Development Professionals (CSDP) examination and as a softwareengineering textbook and reference guide. Chapter 1 provides an overview of the history andcurrent state of software engineering. Chapter 2 to covers several subject areas from the CSDPexam specifications, including professionalism and software law. Chapters 3 through 5 andChapters 7 through 8 discuss the major development processes. Chapter 6 surveys softwaredevelopment strategies and methods. Chapter 9 discusses maintenance (again in support of theCSDP exam).

Each chapter begins with an introduction to the subject and the supporting papers and standards.Each introduction incorporates the appropriate clauses from EEEE/EIA Standard 12207-1997.The appropriate IEEE Software Engineering Standards are contained within every chapter. Twoadditional Computer Society Press Tutorials contain appropriate standards.

• The standards for the management process can be found in a separate Computer SocietyPress tutorial, Software Engineering Project Management, 2nd edition. Be sure to obtainthe latest printing from 2001. The three standards included in the Project Managementtutorial are:

> IEEE Standard 1058-1998, IEEE Standard for Software Project Management Plans(draft)

> IEEE Standard 1062-1998, IEEE Recommended Practice for Software Acquisition

> IEEE Standard 1540-2001, IEEE Standard for Software Life Cycle Processes —Risk Management

• The requirements standards are included in a separate Computer Society Press tutorial,Software Requirements Engineering, 2nd edition. The three standards included in theRequirements tutorial are:

> IEEE wStandard 830-1998, Recommended Practice for Software RequirementSpecifications

> IEEE Standard 1233-1998, Guide to Preparing System Requirements Specifications

> IEEE Standard 1362-1998, Standard for Information Technology - SystemDefinition - Concept of Operations

4. Articles

The first paper (letter) credits Professor Friedrich L. Bauer with coining the phrase "softwareengineering." In 1967, the NATO Science Committee organized a conference to discuss theproblems of building large-scale software systems. The conference was to be held in Garmisch,Germany, in 1968. At a pre-conference meeting, Professor Bauer of Munich TechnicalUniversity, proposed that the conference be called "Software Engineering" as a means ofattracting attention to the conference. This short paper (letter), written by Professor Bauer ofMunich and edited by Professor Andrew D. McGettrick of University of Strathclyde, Glasgow,Scotland, was the foreword from an earlier IEEE Tutorial, Software Engineering — A EuropeanPerspective [1], explaining the history behind the term. It is therefore included in this tutorial togive full credit to Professor Bauer.

The centerpiece of this chapter is an original paper from an earlier Software Engineering tutorial[2], written by the well-known author and consultant, Roger Pressman. As indicated in thePreface, one of the problems of software engineering is the shortage of basic papers. Oncesomething is described, practitioners and academics apparently move onto research or to the finerpoints of argument, abandoning the need to occasionally update the fundamentals. Dr. Pressmanundertook the task of updating the basic papers on software engineering to the current state ofpractice. Pressman discusses technical and management aspects of software engineering. Hesurveys existing high-level models of the software development process (linear sequential,

prototyping, incremental, evolutionary and formal) and discusses management of people, thesoftware project, and the software process. He discusses quality assurance and configurationmanagement as being equally as important as technical and management issues. He reviewssome of the principles and methods that form the foundation of the current practice of softwareengineering, and concludes with a prediction that three issues — reuse, re-engineering, and a newgeneration of tools — will dominate software engineering for the next ten years.

Pressman's latest book is Software Engineering: A Practitioner's Approach, 5th edition(McGraw-Hill, 2000).

The last paper in this chapter was written by Buxton, entitled "Software Engineering — 20 YearsOn and 20 Years Back." This paper provides another historical perspective of the origin and useof the term "software engineering." Professor Buxton is in a unique position to define the pasthistory of software engineering, as he was one of the main reporters and documenters of thesecond NATO software engineering conference in Rome in 1969.

1. Thayer, R. H., and A. D. McGettrick, (eds.), Software Engineering — A EuropeanPerspective, IEEE Computer Society Press, Los Alamitos, CA, 1993.

2. Dorfman, ML, and R.H. Thayer (eds.), Software Engineering, IEEE Computer Society Press,Los Alamitos, CA, 1997.

The Origin of Software Engineering

Dear Dr. Richard Thayer:

In reply to your question about the origin of the term "Software Engineering/1 Isubmit the following story.

In the mid-1960s, there was increasing concern in scientific quarters of theWestern world that the tempestuous development of computer hardware was notmatched by appropriate progress in software. The software situation lookedmore to be turbulent. Operating systems had just been the latest rage, but theyshowed unexpected weaknesses. The uneasiness had been lined out in theNATO Science Committee by its US representative, Dr. I.I. Rabi, the Nobellaureate and famous, as well as influential, physicist. In 1967, the ScienceCommittee set up the Study Group on Computer Science, with members fromseveral countries, to analyze the situation. The German authorities nominatedme for this team. The study group was given the task of "assessing the entirefield of computer science," with particular elaboration on the ScienceCommittee's consideration of "organizing a conference and, perhaps, at a laterdate,... setting up ... an International Institute of Computer Science."

The study group, concentrating its deliberations on actions that would merit aninternational rather than a national effort, discussed all sorts of promising scien-tific projects. However, it was rather inconclusive on the relation of these themesto the critical observations mentioned above, which had guided the ScienceCommittee. Perhaps not all members of the study group had been properlyinformed about the rationale of its existence. In a sudden mood of anger, I madethe remark, "The whole trouble comes from the fact that there is so muchtinkering with software. It is not made in a clean fabrication process," and when Ifound out that this remark was shocking to some of my scientific colleagues, Ielaborated the idea with the provocative saying, "What we need is softwareengineering."

This remark had the effect that the expression "software engineering," whichseemed to some to be a contradiction in terms, stuck in the minds of themembers of the group. In the end, the study group recommended in late 1967the holding of a Working Conference on Software Engineering, and I was madechairman. I had not only the task of organizing the meeting (which was held fromOctober 7 to October 10, 1968, in Garmisch, Germany), but I had to set up ascientific program for a subject that was suddenly defined by my provocativeremark. I enjoyed the help of my cochairmen, L. Bolliet from France, and HJ.Helms from Denmark, and in particular the invaluable support of the programcommittee members, AJ. Perlis and B. Randall in the section on design, P. Naurand J.N. Buxton in the section on production, and K. Samuelson, B. Galler, andD. Gries in the section on service. Among the 50 or so participants, E.W. Dijkstrawas dominant. He actually made not only cynical remarks like "the disseminationof error-loaded software is frightening" and "it is not clear that the people who

manufacture software are to be blamed. I think manufacturers deserve better,more understanding users." He also said already at this early date, "Whetherthe, correctness of a piece of software can be guaranteed or not depends greatlyon the structure of the thing made," and he had very fittingly named his paper"Complexity Controlled by Hierarchical Ordering of Function and Variability,11

introducing a theme that followed his life the next 20 years. Some of his wordshave become proverbs in computing, like "testing is a vory inefficient way ofconvincing oneself of the correctness of a program."

With the wide distribution of the reports on the Garmisch conference and on afollow-up conference in Rome, from October 27 to 31,1969, it emerged that notonly the phrase software engineering, but also the idea behind this, becamefashionable. Chairs were created, institutes were established (although the onewhich the NATO Science Committee had proposed did not come about becauseof reluctance on the part of Great Britain to have it organized1 on the Europeancontinent), and a great number of conferences were held. The present volumeshows clearly how much progress has been made in the intervening years.

The editors deserve particular thanks for paying so much attention to a tutorial.In choosing the material, they have tried to highlight a number of software engi-neering initiatives whose origin is European. In particular, the more formalapproach to software engineering is evident, and they leave included somematerial that is not readily available, elsewhere. The tutorial nature of the papersis intended to offer readers an easy introduction to the topics and indeed to theattempts that have been made in recent years to provide them with the tools,both in a handcraft and intellectual sense, that allow them now to call themselveshonestly software engineers.

O. Prof. Dr. Friedrich L. Bauer,Professor EmeritusInstitut fur Informatik der Technischen Universitat Munchen,Postfach 20 24 20,D-8000 Munchen 2, Germany

Software Engineering

Roger S. Pressman, Ph.D.

As software engineering approaches its fourthdecade, it suffers from many of the strengths and someof the frailties that are experienced by humans of thesame age. The innocence and enthusiasm of its earlyyears have been replaced by more reasonable expec-tations (and even a healthy cynicism) fostered byyears of experience. Software engineering approachesits mid-life with many accomplishments alreadyachieved, but with significant work yet to do.

The intent of this paper is to provide a survey ofthe current state of software engineering and to sug-gest the likely course of the aging process. Key soft-ware engineering activities are identified, issues arepresented, and future directions are considered. Therewill be no attempt to present an in-depth discussion ofspecific software engineering topics. That is the job ofother papers presented in this book

1.0 Software Engineering—LayeredTechnology1

Although hundreds of authors have developed per-sonal definitions of software engineering, a definitionproposed by Fritz Bauer [1] at the seminal conferenceon the subject still serves as a basis for discussion:

[Software engineering is] the establishmentand use of sound engineering principles in or-der to obtain economically software that is re-liable and works efficiently on real machines.

Almost every reader will be tempted to add to thisdefinition. It says little about the technical aspects ofsoftware quality; it does not directly address the needfor customer satisfaction or timely product delivery; itomits mention of the importance of measurement andmetrics; it does not state the importance of a matureprocess. And yet, Bauer's definition provides us witha baseline. What are the "sound engineering princi-ples" that can be applied to computer software devel-opment? How to "economically" build software sothat it is "reliable"? What is required to create com-

1 Portions of this paper have been adapted from A Manager'sGuide to Software Engineering [19] and Software Engineering: APractitioner's Approach (McGraw-Hill, fourth edition, 1997) andare used with permission.

puter programs that work "efficiently" on not one butmany different "real machines"? These are the ques-tions that continue to challenge software engineers.

Software engineering is a layered technology.Referring to Figure 1, any engineering approach(including software engineering) must resic on anorganizational commitment to quality. Total qualitymanagement and similar philosophies foster a con-tinuous process improvement culture, and it is thisculture that ultimately leads to the development ofincreasingly more mature approaches to softwareengineering. The bedrock that supports software engi-neering is a quality focus.

The foundation for software engineering is theprocess layer. Software engineering process is theglue that holds the technology layers together andenables rational and timely development of computersoftware. Process defines a framework for a set of keyprocess areas [2] that must be established for effec-tive delivery of software engineering technology. Thekey process areas form the basis for managementcontrol of software projects, and establish the contextin which technical methods are applied, deliiverables(models, documents, data reports, forms, and so on)are produced, milestones are established, quality isensured, and change is properly managed.

Software engineering methods provide the techni-cal "how to's" for building software. Methods encom-pass a broad array of tasks that include: requirementsanalysis, design, program construction, testing, andmaintenance. Software engineering methods rely on aset of basic principles that govern each area of thetechnology and include modeling activities, and otherdescriptive techniques.

Software engineering tools provide automated orsemiautomated support for the process and the meth-ods. When tools are integrated so that informationcreated by one tool can be used by another, a systemfor the support of software development, called com-puter-aided software engineering (CASE), is estab-lished. CASE combines software, hardware, and asoftware engineering database (a repository contain-ing important information about analysis, design, pro-gram construction, and testing) to create a softwareengineering environment that is analogous toCAD/CAE (computer-aided design/engineering) forhardware.

Figure 1. Software engineering layers

2.0 Software Engineering Process Models

Software engineering incorporates a developmentstrategy that encompasses the process, methods, andtools layers described above. This strategy is oftenreferred to as a process model or a software engi-neering paradigm. A process model for softwareengineering is chosen based on the nature of the proj-ect and application, the methods and tools to be used,and the controls and deliverables that are required.Four classes of process models have been widely dis-cussed (and debated). A brief overview of each is pre-sented in the sections that follow.

2.1 Linear, Sequential Models

Figure 2 illustrates the linear sequential model forsoftware engineering. Sometimes called the "classiclife cycle" or the "waterfall model," the linear sequen-tial model demands a systematic, sequential approachto software development that begins at the systemlevel and progresses through analysis, design, coding,testing, and maintenance. The linear sequential model

is the oldest and the most widely used paradigm forsoftware engineering. However, criticism of the para-digm has caused even active supporters to question itsefficacy. Among the problems that are sometimes en-countered when the linear sequential model is appliedare:

1. Real projects rarely follow the sequentialflow that the model proposes. Although thelinear model can accommodate iteration, itdoes so indirectly. As a result, changes cancause confusion as the project team proceeds.

2. It is often difficult for the customer to stateall requirements explicitly. The linear se-quential model requires this and has difficultyaccommodating the natural uncertainty thatexists at the beginning of many projects.

3. The customer must have patience. A workingversion of the program(s) will not be avail-able until late in the project time span. Amajor blunder, if undetected until the work-ing program is reviewed, can be disastrous.

Figure 2. The linear, sequential paradigm

10

2.2 Prototyping

Often, a customer defines a set of general objec-tives for software, but does not identify detailed input,processing, or output requirements. In other cases, thedeveloper may be unsure of the efficiency of an algo-rithm, the adaptability of an operating system, or theform that human-machine interaction should take. Inthese, and many other situations, a prototyping para-digm may offer the best approach.

The prototyping paradigm (Figure 3) begins withrequirements gathering. Developer and customer meetand define the overall objectives for the software,identify whatever requirements are known, and outlineareas where further definition is mandatory. A "quickdesign" then occurs. The quick design focuses on arepresentation of those aspects of the software that willbe visible to the customer/user (for example, inputapproaches and output formats). The quick designleads to the construction of a prototype. The prototypeis evaluated by the customer/user and is used to refinerequirements for the software to be developed. Iterationoccurs as the prototype is tuned to satisfy the needs ofthe customer, while at the same time enabling the devel-oper to better understand what needs to be done.

Ideally, the prototype serves as a mechanism foridentifying software requirements. If a working proto-type is built, the developer attempts to make use ofexisting program fragments or applies tools (reportgenerators, and window managers, for instance) thatenable working programs to be generated quickly.

listento

customer

Both customers and developers like the prototyp-ing paradigm. Users get a feel for the actual systemand developers get to build something immediately.Yet, prototyping can also be problematic for the fol-lowing reasons:

1. The customer sees what appears to be aworking version of the software, unawarethat the prototype is held together "withchewing gum and baling wire" or that in therush to get it working we haven't consideredoverall software quality or long-term main-tainability. When informed that the productmust be rebuilt, the customer cries foul anddemands that "a few fixes" be applied to makethe prototype a working product. Too often,software development management relents.

2. The developer often makes implementationcompromises in order to get a prototypeworking quickly. An inappropriate operatingsystem or programming language may beused simply because it is available andknown; an inefficient algorithm may be im-plemented simply to demonstrate capability.After a time, the developer may become fa-miliar with these choices and forget all thereasons why they were inappropriate. Theless-than-ideal choice has now become anintegral part of the system.

buildmock-up

customertest-drivesmock-up

Figure 3. The prototyping paradigm

11

2.3 Incremental Model

Although problems can occur, prototyping is an ef-fective paradigm for software engineering. The key isto define the rules of the game at the beginning; that is,the customer and developer must both agree that theprototype is built to serve as a mechanism for definingrequirements. It is then discarded (at least in part) andthe actual software is engineered with an eye towardquality and maintainability.

When an incremental model is used, the firstincrement is often a core product. That is, basicrequirements are addressed, but many supplementaryfeatures (some known, others unknown) remain unde-livered. The core product is used by the customer (orundergoes detailed review). As a result of use and/orevaluation, a plan is developed for the next increment.The plan addresses the modification of the core prod-uct to better meet the needs of the customer and thedelivery of additional features and functionality. Thisprocess is repeated following the delivery of eachincrement, until the complete product is produced.

The incremental process model, like prototyping(Section 2.2) and evolutionary approaches (Section2.4), is iterative in nature. However, the incrementalmodel focuses on the delivery of an operational prod-uct with each increment. Early increments are"stripped down" versions of the final product, but theydo provide capability that serves the user and alsoprovide a platform for evaluation by the user.

Incremental development is particularly usefulwhen staffing is unavailable for a complete imple-mentation by the business deadline that has beenestablished for the project. Early increments can beimplemented with fewer people. If the core product iswell received, then additional staff (if required) can beadded to implement the next increment. In addition,increments can be planned to manage technical risks.For example, a major system might require the avail-ability of new hardware that is under development andwhose delivery date is uncertain. It might be possibleto plan early increments in a way that avoids the use ofthis hardware, thereby enabling partial functionality tobe delivered to end users without inordinate delay.

2.4 Evolutionary Models

The evolutionary paradigm, also called the spiralmodel [3] couples the iterative nature of prototypingwith the controlled and systematic aspects of the linearmodel. Using the evolutionary paradigm, software isdeveloped in a series of incremental releases. Duringearly iterations, the incremental release might be a pro-totype. During later iterations, increasingly more com-plete versions of the engineered system are produced.

Figure 4 depicts a typical evolutionary model.

Each pass around the spiral moves through six taskregions:

• customer communication—tasks required toestablish effective communication betweendeveloper and customer

• planning—tasks required to define re-sources, time lines and other project-relatedinformation

• risk assessment—tasks required to assessboth technical and management risks

• engineering—tasks required to build one ormore representations of the application

• construction and release—tasks required toconstruct, test, install, and provide user support(for example, documentation and training)

• customer evaluation—tasks required toobtain customer feedback based on evalua-tion of the software representations createdduring the engineering stage and imple-mented during the installation stage.

Each region is populated by a series of tasksadapted to the characteristics of the project to beundertaken.

The spiral model is a realistic approach to thedevelopment of large scale systems and software. Ituses an "evolutionary" approach [4] to software engi-neering, enabling the developer and customer tounderstand and react to risks at each evolutionarylevel. It uses prototyping as a risk reduction mecha-nism, but more importantly, it enables the developer toapply the prototyping approach at any stage in theevolution of the product. It maintains the systematicstepwise approach suggested by the classic life cyclebut incorporates it into an iterative framework thatmore realistically reflects the real world. The spiralmodel demands a direct consideration of technicalrisks at all stages of the project, and if properlyapplied, should reduce risks before they becomeproblematic.

But like other paradigms, the spiral model is not apanacea. It may be difficult to convince customers(particularly in contract situations) that the evolution-ary approach is controllable. It demands considerablerisk assessment expertise, and relies on this expertisefor success. If a major risk is not discovered, problemswill undoubtedly occur. Finally, the model itself is rela-tively new and has not been used as widely as the linearsequential or prototyping paradigms. It will take a num-ber of years before efficacy of this important newparadigm can be determined with absolute certainty.

12

Planning Risk Assessment

go-no-go axis

CustomerCommunication

project entry point Engineering

CustomerEvaluation Construction and Release

Figure 4. The evolutionary model

2.5 The Formal Methods Model

The formal methods paradigm encompasses a setof activities that leads to formal mathematical specifi-cation of computer software. Formal methods enable asoftware engineer to specify, develop, and verify acomputer-based system by applying a rigorous,mathematical notation. A variation on this approach,called cleanroom software engineering [5, 6], is cur-rently applied by a limited number of companies.

When formal methods are used during develop-ment, they provide a mechanism for eliminating manyof the problems that are difficult to overcome usingother software engineering paradigms. Ambiguity,incompleteness, and inconsistency can be discoveredand corrected more easily—not through ad hoc review,but through the application of mathematical analysis.When formal methods are used during design, theyserve as a basis for program verification and there-fore enable the software engineer to discover andcorrect errors that might otherwise go undetected.

Although not yet a mainstream approach, the for-mal methods model offers the promise of defect-freesoftware. Yet, concern about its applicability in abusiness environment has been voiced:

1. The development of formal models is cur-rently quite time-consuming and expensive.

2. Because few software developers have thenecessary background to apply formal meth-ods, extensive training is required.

3. It is difficult to use the models as a communi-cation mechanism for technically unsophisti-cated customers.

These concerns notwithstanding, it is likely that theformal methods approach will gain adherents amongsoftware developers who must build safety-criticalsoftware (such as aircraft avionics and medical de-vices) and among developers that would suffer severeeconomic hardship should software errors occur.

3.0 The Management Spectrum

Effective software project management focuses onthe three P's: people, problem, and process. The orderis not arbitrary. The manager who forgets that softwareengineering work is an intensely human endeavor willnever have success in project management. A manager

13

who fails to encourage comprehensive customer com-munication early in the evolution of a project risksbuilding an elegant solution for the wrong problem.Finally, the manager who pays little attention to theprocess runs the risk of inserting competent technicalmethods and tools into a vacuum.

3.1 People

The cultivation of motivated, highly skilled soft-ware people has been discussed since the 1960s [see 7,8, 9]. The Software Engineering Institute has spon-sored a people-management maturity model "toenhance the readiness of software organizations toundertake increasingly complex applications by help-ing to attract, grow, motivate, deploy, and retain thetalent needed to improve their software developmentcapability." [10]

The people-management maturity model definesthe following key practice areas for software people:recruiting, selection, performance management, train-ing, compensation, career development, organization,and team and culture development. Organizations thatachieve high levels of maturity in the people-management area have a higher likelihood of imple-menting effective software engineering practices.

3.2 The Problem

Before a project can be planned, objectives andscope should be established, alternative solutionsshould be considered, and technical and managementconstraints should be identified. Without this informa-tion, it is impossible to develop reasonable cost esti-mates, a realistic breakdown of project tasks, or amanageable project schedule that is a meaningful indi-cator of progress.

The software developer and customer must meet todefine project objectives and scope. In many cases,this activity occurs as part of structured customercommunication process such as joint applicationdesign [11, 12]. Joint application design (IAD) is anactivity that occurs in five phases: project definition,research, preparation, the JAD meeting, and documentpreparation. The intent of each phase is to developinformation that helps better define the problem to besolved or the product to be built.

3.3 The Process

A software process (see discussion of processmodels in Section 2.0) can be characterized as shownin Figure 5. A few framework activities apply to allsoftware projects, regardless of their size or complex-ity. A number of task sets—tasks, milestones, deliver-

ables, and quality assurance points—enable theframework activities to be adapted to the characteris-tics of the software project and the requirements of theproject team. Finally, umbrella activities—such assoftware quality assurance, software configurationmanagement, and measurement—overlay the processmodel. Umbrella activities are independent of any oneframework activity and occur throughout the process.

In recent years, there has been a significant empha-sis on process "maturity." [2] The Software Engineer-ing Institute (SEI) has developed a comprehensiveassessment model predicated on a set of software en-gineering capabilities that should be present as organi-zations reach different levels of process maturity. Todetermine an organization's current state of processmaturity, the SEI uses an assessment questionnaire anda five-point grading scheme. The grading scheme de-termines compliance with a capability maturity model[2] that defines key activities required at different lev-els of process maturity. The SEI approach provides ameasure of the global effectiveness of a company'ssoftware engineering practices and establishes fiveprocess maturity levels that are defined in the follow-ing manner:

Level 1: Initial—The software process is character-ized as ad hoc, and occasionally even chaotic.Few processes are defined, and success dependson individual effort.

Level 2: Repeatable—Basic project managementprocesses are established to track cost, schedule,and functionality. The necessary process disci-pline is in place to repeat earlier successes onprojects with similar applications.

Level 3: Defined—The software process for bothmanagement and engineering activities is docu-mented, standardized, and integrated into an or-ganization-wide software process. All projects usea documented and approved version of the or-ganization's process for developing and main-taining software. This level includes all charac-teristics defined for level 2.

Level 4: Managed—Detailed measures of the soft-ware process and product quality are collected.Both the software process and products are quan-titatively understood and controlled using detailedmeasures. This level includes all characteristicsdefined for level 3.

Level 5: Optimizing—Continuous process improve-ment is enabled by quantitative feedback from theprocess and from testing innovative ideas andtechnologies. This level includes all characteris-tics defined for level 4.

14

Figure 5. A common process framework

The five levels defined by the SEI are derived as aconsequence of evaluating responses to the SEIassessment questionnaire that is based on the CMM.The results of the questionnaire are distilled to a singlenumerical grade that helps indicate an organization'sprocess maturity.

The SEI has associated key process areas (KPAs)with each maturity level. The KPAs describe thosesoftware engineering functions (for example, softwareproject planning and requirements management) thatmust be present to satisfy good practice at a particularlevel. Each KPA is described by identifying the fol-lowing characteristics:

• goals—the overall objectives that the KPAmust achieve

• commitments—requirements (imposed on theorganization) that must be met to achieve thegoals, provide proof of intent to comply withthe goals

• abilities—those things that must be in place(organizationally and technically) that will en-able the organization to meet the commitments

• activities—the specific tasks that are requiredto achieve the KPA function

• methods for monitoring implementation—themanner in which the activities are monitoredas they are put into place

• methods for verifying implementation—themanner in which proper practice for the KPAcan be verified.

Eighteen KPAs (each defined using the structurenoted above) are defined across the maturity modeland are mapped into different levels of processmaturity.

Each KPA is defined by a set of key practices thatcontribute to satisfying its goals. The key practices arepolicies, procedures, and activities that must occurbefore a key process area has been fully instituted. TheSEI defines key indicators as "those key practices orcomponents of key practices that offer the greatestinsight into whether the goals of a key process areahave been achieved." Assessment questions aredesigned to probe for the existence (or lack thereof) ofa key indicator.

15

4.0 Software Project Management

Software project management encompasses thefollowing activities: measurement, project estimating,risk analysis, scheduling, tracking, and control. Acomprehensive discussion of these topics is beyondthe scope of this paper, but a brief overview of eachtopic will enable die reader to understand the breadthof management activities required for a mature soft-ware engineering organizations.

4.1 Measurement and Metrics

To be most effective, software metrics should becollected for both the process and the product. Proc-ess-oriented metrics [14, 15] can be collected duringthe process and after it has been completed. Processmetrics collected during the project focus on the effi-cacy of quality assurance activities, change manage-ment, and project management. Process metrics col-lected after a project has been completed examinequality and productivity. Process measures are nor-malized using either lines of code or function points[13], so that data collected from many different proj-ects can be compared and analyzed in a consistentmanner. Product metrics measure technical character-istics of the software that provide an indication ofsoftware quality [15, 16, 17, 18]. Measures can beapplied to models created during analysis and designactivities, the source code, and testing data. Themechanics of measurement and the specific measuresto be collected are beyond the scope of this paper.

4.2 Project Estimating

Scheduling and budgets are often dictated by busi-ness issues. The role of estimating within the softwareprocess often serves as a "sanity check" on the prede-fined deadlines and budgets that have been establishedby management. (Ideally, the software engineeringorganization should be intimately involved in estab-lishing deadlines and budgets, but this is not a perfector fair world.)

AH software project estimation techniques requirethat the project have a bounded scope, and all rely ona high level functional decomposition of the projectand an assessment of project difficulty and complex-ity. There are three broad classes of estimation tech-niques [19] for software projects:

• Effort estimation techniques. The projectmanager creates a matrix in which the left-hand column contains a list of major systemfunctions derived using functional decompo-sition applied to project scope. The top row

contains a list of major software engineeringtasks derived from the common processframework. The manager (with the assistanceof technical staff) estimates the effortrequired to accomplish each task for eachfunction.

• Size-Oriented Estimation. A list of majorsystem functions is derived using functionaldecomposition applied to project scope. The"size" of each function is estimated using ei-ther lines of code (LOG) or function points(FP). Average productivity data (for instance,function points per person month) for similarfunctions or projects are used to generate anestimate of effort required for each function.

• Empirical Models. Using the results of alarge population of past projects, an empiricalmodel that relates product size (in LOG orFP) to effort is developed using a statisticaltechnique such as regression analysis. Theproduct size for the work to be done is esti-mated and the empirical model is used togenerate projected effort (for example, [20]).

In addition to the above techniques, a softwareproject manager can develop estimates by analogy.This is done by examining similar past projects thenprojecting effort and duration recorded for these proj-ects to the current situation.

4.3 Risk Analysis

Almost five centuries have passed since Machiav-elli said: "I think it may be true that fortune is the rulerof half our actions, but that she allows the other half tobe governed by us... [fortune] is like an impetuousriver... but men can make provision against it bydykes and banks." Fortune (we call it risk) is in theback of every software project manager's mind, andthat is often where it stays. And as a result, risk isnever adequately addressed. When bad things happen,the manager and the project team are unprepared.

In order to "make provision against it," a softwareproject team must conduct risk analysis explicitly.Risk analysis [21, 22, 23] is actually a series of stepsthat enable the software team to perform risk identifi-cation, risk assessment, risk prioritization, and riskmanagement. The goals of these activities are: (1) toidentify those risks that have a high likelihood ofoccurrence, (2) to assess the consequence (impact) ofeach risk should it occur, and (3) to develop a plan formitigating the risks when possible, monitoring factorsthat may indicate their arrival, and developing a set ofcontingency plans should they occur.

16

4.4 Scheduling

The process definition and project managementactivities that have been discussed above feed thescheduling activity. The common process frameworkprovides a work breakdown structure for scheduling.Available human resources, coupled with effort esti-mates and risk analysis, provide the task interdepend-encies, parallelism, and time lines that are used in con-structing a project schedule.

4.5 Tracking and Control

Project tracking and control is most effective whenit becomes an integral part of software engineeringwork. A well-defined process framework should pro-vide a set of milestones that can be used for projecttracking. Control focuses on two major issues: qualityand change.

To control quality, a software project team mustestablish effective techniques for software quality as-surance, and to control change, the team should estab-lish a software configuration management framework.

S.O Software Quality Assurance

In his landmark book on quality, Philip Crosby[24] states:

The problem of quality management is notwhat people don't know about it. The problemis what they think they do know...

In this regard, quality has much in commonwith sex. Everybody is for it. (Under certainconditions, of course.) Everyone feels they un-derstand it. (Even though they wouldn't want toexplain it.) Everyone thinks execution is only amatter of following natural inclinations. (Afterall, we do get along somehow.) And, of course,most people feel that problems in these areasare caused by other people. (If only they wouldtake the time to do things right.)

There have been many definitions of softwarequality proposed in the literature. For our purposes,software quality is defined as: Conformance to explic-itly stated functional and performance requirements,explicitly documented development standards, andimplicit characteristics that are expected of all profes-sionally developed software.

There is little question that the above definitioncould be modified or extended. In fact, the precisedefinition of software quality could be debated end-lessly. But the definition stated above does serve toemphasize three important points:

L Software requirements are the foundationfrom which quality is assessed. Lack of con-formance to requirements is lack of quality.

2. A mature software process model defines aset of development criteria that guide themanner in which software is engineered. Ifthe criteria are not followed, lack of qualitywill almost surely result.

3. There is a set of implicit requirements thatoften go unmentioned (for example, the de-sire for good maintainability). If softwareconforms to its explicit requirements but failsto meet implicit requirements, software qual-ity is suspect.

Almost two decades ago, McCall and Cavano [25,26] defined a set of quality factors that were a firststep toward the development of metrics for softwarequality. These factors assessed software from threedistinct points of view: (1) product operation (usingit); (2) product revision (changing it), and (3) producttransition (modifying it to work in a different envi-ronment, that is., "porting" it). These factors include:

• Correctness. The extent to which a programsatisfies its specification and fulfills the cus-tomer's mission objectives.

• Reliability. The extent to which a programcan be expected to perform its intended func-tion with required precision.

• Efficiency. The amount of computing re-sources and code required by a program toperform its function.

• Integrity. Extent to which access to softwareor data by unauthorized persons can be con-trolled.

• Usability. Effort require to learn, operate,prepare input, and interpret output of a pro-gram.

• Maintainability. Effort require to locate andfix an error in a program. [Might be bettertermed "correctability"].

• Flexibility. Effort required to modify an op-erational program.

• Testability. Effort required to test a program toinsure that it performs its intended function.

• Portability. Effort required to transfer theprogram from one hardware and/or softwaresystem environment to another.

• Reusability. Extent to which a program [orparts of a program] can be reused in other

17

applications—related to the packaging andscope of the functions that the program per-forms,

• Interoperability. Effort required to coupleone system to another.

The intriguing thing about these factors is how lit-tle they have changed in almost 20 years. Computingtechnology and program architectures have undergonea sea change, but the characteristics that define high-quality software appear to be invariant. The implica-tion: An organization that adopts factors such as thosedescribed above will build software today that willexhibit high quality well into the first few decades ofthe twenty-first century. More importantly, this willoccur regardless of the massive changes in computingtechnologies that are sure to come over that period oftime.

Software quality is designed into a product or sys-tem. It is not imposed after the fact. For this reason,software quality assurance (SQA) actually begins withthe set of technical methods and tools that help theanalyst to achieve a high-quality specification and thedesigner to develop a high-quality design.

Once a specification (or prototype) and designhave been created, each must be assessed for quality.The central activity that accomplishes quality assess-ment is the formal technical review. The formal tech-nical review (FTR)—conducted as a walk-through oran inspection [27]—is a stylized meeting conducted bytechnical staff with the sole purpose of uncoveringquality problems. In many situations, formal technicalreviews have been found to be as effective as testing inuncovering defects in software [28].

Software testing combines a multistep strategywith a series of test case design methods that helpensure effective error detection. Many software devel-opers use software testing as a quality assurance"safety net.'* That is, developers assume that thoroughtesting will uncover most errors, thereby mitigating theneed for other SQA activities. Unfortunately, testing,even when performed well, is not as effective as wemight like for all classes of errors. A much betterstrategy is to find and correct errors (using FTRs)before getting to testing.

The degree to which formal standards and proce-dures are applied to the software engineering processvaries from company to company. In many cases,standards are dictated by customers or regulatorymandate. In other situations standards are self-imposed. An assessment of compliance to standardsmay be conducted by software developers as part of aformal technical review, or in situations where inde-pendent verification of compliance is required, theSQA group may conduct its own audit.

A major threat to software quality comes from aseemingly benign source: changes. Every change tosoftware has the potential for introducing error or cre-ating side effects that propagate errors. The changecontrol process contributes directly to software qualityby formalizing requests for change, evaluating thenature of change, and controlling the impact ofchange. Change control is applied during softwaredevelopment and later, during the software mainte-nance phase.

Measurement is an activity that is integral to anyengineering discipline. An important objective of SQAis to track software quality and assess the impact ofmethodological and procedural changes on improvedsoftware quality. To accomplish this, software metricsmust be collected.

Record keeping and recording for software qualityassurance provide procedures for the collection anddissemination of SQA information. The results ofreviews, audits, change control, testing, and otherSQA activities must become part of the historical rec-ord for a project and should be disseminated to devel-opment staff on a need-to-know basis. For example,the results of each formal technical review for a pro-cedural design are recorded and can be placed in a"folder" that contains all technical and SQA informa-tion about a module.

6.0 Software Configuration Management

Change is inevitable when computer software isbuilt. And change increases the level of confusionamong software engineers who are working on a proj-ect. Confusion arises when changes are not analyzedbefore they are made, recorded before they areimplemented, reported to those who should be awarethat they have occurred, or controlled in a manner thatwill improve quality and reduce error. Babich [29]discusses this when he states:

The art of coordinating software developmentto minimize... confusion is called config-uration management. Configuration manage-ment is the art of identifying, organizing, andcontrolling modifications to the software beingbuilt by a programming team. The goal is tomaximize productivity by minimizing mistakes.

Software configuration management (SCM) is anumbrella activity that is applied throughout the soft-ware engineering process. Because change can occurat any time, SCM activities are developed to (1) iden-tify change, (2) control change, (3) ensure that changeis being properly implemented and (4) report changeto others who may have an interest.

18

A primary goal of software engineering is toimprove the ease with which changes can be accom-modated and reduce the amount of effort expendedwhen changes must be made.

7.0 The Technical Spectrum

There was a time—some people still call it "thegood old days"—when a skilled programmer created aprogram like an artist creates a painting: she just satdown and started. Pressman and Herron [30] drawother parallels when they write:

At one time or another, almost everyone la-ments the passing of the good old days. Wemiss the simplicity, the personal touch, the em-phasis on quality that were the trademarks of acraft. Carpenters reminisce about the dayswhen houses were built with mahogany andoak, and beams were set without nails. Engi-neers still talk about an earlier era when oneperson did all the design (and did it right) andthen went down to the shop floor and built thething. In those days, people did good work andstood behind it.

How far back do we have to travel to reach thegood old days? Both carpentry and engineeringhave a history that is well over 2,000 years old.The disciplined way in which work is con-ducted, the standards that guide each task, thestep by step approach that is applied, have allevolved through centuries of experience. Soft-ware engineering has a much shorter history.

During its short history, the creation of computerprograms has evolved from an art form, to a craft, toan engineering discipline. As the evolution took place,the free-form style of the artist was replaced by thedisciplined methods of an engineer. To be honest, welose something when a transition like this is made.There's a certain freedom in art that can't be repli-cated in engineering. But we gain much, much morethan we lose.

As the journey from art to engineering occurred,basic principles that guided our approach to softwareproblem analysis, design and testing slowly evolved.And at the same time, methods were developed thatembodied these principles and made software engi-neering tasks more systematic. Some of these "hot,new" methods flashed to the surface for a few years,only to disappear into oblivion, but others have stoodthe test of time to become part of the technology ofsoftware development.

In this section we discuss the basic principles thatsupport the software engineering methods and providean overview of some of the methods that have already"stood the test of time" and others that are likely to doso.

7.1 Software Engineering Methods-—Hie Landscape

All engineering disciplines encompass four majoractivities: (1) the definition of the problem to besolved, (2) the design of a solution that will meet thecustomer's needs; (2) the construction of the solution,and (4) the testing of the implemented solution touncover latent errors and provide an indication thatcustomer requirements have been achieved. Softwareengineering offers a variety of different methods toachieve these activities. In fact, the methods landscapecan be partitioned into three different regions:

• conventional software engineering methods

• object-oriented approaches

• formal methods

Each of these regions is populated by a variety ofmethods that have spawned their own culture, not tomention a sometimes confusing array of notation andheuristics. Luckily, all of the regions are unified by aset of overriding principles that lead to a single objec-tive: to create high quality computer software.

Conventional software engineering methods viewsoftware as an information transform and approacheach problem using an input-process-output viewpoint.Object-oriented approaches consider each problem asa set of classes and work to create a solution byimplementing a set of communicating objects that areinstantiated from these classes. Formal methodsdescribe the problem in mathematical terms, enablingrigorous evaluation of completeness, consistency, andcorrectness.

Like competing geographical regions on the worldmap, the regions of the software engineering methodsmap do not always exist peacefully. Some inhabitantsof a particular region cannot resist religious warfare.Like most religious warriors, they become consumedby dogma and often do more harm that good. Theregions of the software engineering methods landscapecan and should coexist peacefully, and tedious debatesover which method is best seem to miss the point. Anymethod, if properly applied within the context of asolid set of software engineering principles, will leadto higher quality software than an undisciplinedapproach.

19

7.2 Problem Definition

A problem cannot be fully defined and boundeduntil it is communicated. For this reason, the first stepin any software engineering project is customer com-munication. Techniques for customer communication[11, 12] were discussed earlier in this paper. Inessence, the developer and the customer must developan effective mechanism for defining and negotiatingthe basic requirements for the software project. Oncethis has been accomplished, requirements analysisbegins. Two options are available at this stage: (1) thecreation of a prototype that will assist the developerand the customer in better understanding the system tobe build, and/or (2) the creation of a detailed set ofanalysis models that describe the data, function, andbehavior for the system.

7.2.1 Analysis PrinciplesToday, analysis modeling can be accomplished by

applying one of several different methods that popu-late the three regions of the software engineeringmethods landscape. All methods, however, conform toa set of analysis principles [31]:

1. The data domain of the problem must bemodeled. To accomplish this, the analystmust define the data objects (entities) that arevisible to the user of the software and therelationships that exist between the dataobjects. The content of each data object (theobject's attributes) must also be defined.

2. The functional domain of the problemmust be modeled. Software functions trans-form the data objects of the system and canbe modeled as a hierarchy (conventionalmethods), as services to classes within a sys-tem (the object-oriented view), or as a suc-cinct set of mathematical expressions (theformal view).

3. The behavior of the system must be repre-sented. All computer-based systems respondto external events and change their state ofoperation as a consequence. Behavioral mod-eling indicates the externally observablestates of operation of a system and how tran-sition occurs between these states.

4. Models of data, function, and behaviormust be partitioned. All engineering prob-lem-solving is a process of elaboration. Theproblem (and the models described above)are first represented at a high level ofabstraction. As problem definition pro-gresses, detail is refined and the level of ab-

straction is reduced. This activity is calledpartitioning.

5. The overriding trend in analysis is fromessence toward implementation. As theprocess of elaboration progresses, the state-ment of the problem moves from a represen-tation of the essence of the solution towardimplementation-specific detail. This progres-sion leads us from analysis toward design.

7.2.2 Analysis MethodsA discussion of the notation and heuristics of even

the most popular analysis methods is beyond the scopeof this paper. The problem is further compounded bythe three different regions of the methods landscapeand the local issues specific to each. Therefore, all thatwe can hope to accomplish in this section is to notesimilarities among the different methods and regions:

• All analysis methods provide a notation fordescribing data objects and the relationshipsthat exist between them.

• All analysis methods couple function anddata and provide a way for understandinghow function operates on data.

• Ail analysis methods enable an analyst to rep-resent behavior at a system level, and in somecases, at a more localized level.

• All analysis methods support a partitioningapproach that leads to increasingly more de-tailed (and implementation-specific models).

• All analysis methods establish a foundationfrom which design begins, and some providerepresentations that can be directly mappedinto design.

For further information on analysis methods ineach of the three regions noted above, the readershould review work by Yourdon [32], Booch [33], andSpivey [34].

7.3 Design

M.A. Jackson [35] once said: 'The beginning ofwisdom for a computer programmer [software engi-neer] is to recognize the difference between getting aprogram to work, and getting it right" Softwaredesign is a set of basic principles and a pyramid ofmodeling methods that provide the necessary frame-work for "getting it right."

73.1 Design PrinciplesLike analysis modeling, software design has

20

spawned a collection of methods that populate theconventional, object-oriented, and formal regions thatwere discussed earlier. Each method espouses its ownnotation and heuristics for accomplishing design, butall rely on a set of fundamental principles [31] that areoutlined in the paragraphs that follow:

1. Data and the algorithms that manipulatedata should be created as a set of interre-lated abstractions. By creating data and pro-cedural abstractions, the designer modelssoftware components that have characteristicsleading to high quality. An abstraction is self-contained; it generally implements one well-constrained data structure or algorithm; it canbe accessed using a simple interface; the de-tails of its internal operation need not beknown for it to be used effectively; it is in-herently reusable.

2. The internal design detail of data struc-tures and algorithms should he hiddenfrom other software components thatmake use of the data structures and algo-rithms. Information hiding [36] suggests thatmodules be "characterized by design deci-sions that (each) hides from all others." Hid-ing implies that effective modularity can beachieved by defining a set of independentmodules that communicate with one anotheronly that information that is necessary toachieve software function. The use of infor-mation hiding as a design criterion formodular systems provides greatest benefitswhen modifications are required during test-ing and later, during software maintenance.Because most data and procedures are hiddenfrom other parts of the software, inadvertenterrors (and resultant side effects) introducedduring modification are less likely to propa-gate to other locations within the software.

3. Modules should exhibit independence. Thatis, they should be loosely coupled to eachother and to the external environment andshould exhibit functional cohesion. Softwarewith effective modularity, that is, independentmodules, is easier to develop because func-tion may be compartmentalized and interfacesare simplified (consider ramifications whendevelopment is conducted by a team). Inde-pendent modules are easier to maintain(and test) because secondary effects causedby design/code modification are limited; error

propagation is reduced; and reusable modulesare possible.

4. Algorithms should be designed using aconstrained set of logical constructs. Thisdesign approach, widely know as structuredprogramming [37], was proposed to limit theprocedural design of software to a smallnumber of predictable operations. The use ofthe structured programming constructs(sequence, conditional, and loops) reducesprogram complexity and thereby enhancesreadability, testability, and maintainability.The use of a limited number of logical con-structs also contributes to a human under-standing process that psychologists callchunking. To understand this process, con-sider the way in which you are reading thispage. You do not read individual letters; butrather, recognize patterns or chunks of lettersthat form words or phrases. The structuredconstructs are logical chunks that allow areader to recognize procedural elements of amodule, rather than reading the design orcode line by line. Understanding is enhancedwhen readily recognizable logical forms areencountered.

7.3.2 The Design PyramidLike analysis, a discussion of even the most popu-

lar design methods is beyond the scope of this paper.Our discussion here will focus on a set of designactivities that should occur regardless of the methodthat is used.

Software design should be accomplished by fol-lowing a set of design activities as illustrated in Figure6. Data design translates the data model created dur-ing analysis into data structures that meet the needs ofthe problem. Architectural design differs in intentdepending upon the designer's viewpoint. Conven-tional design creates hierarchical software architec-tures, while object-oriented design views architectureas the message network that enables object;; to com-municate. Interface design creates implementationmodels for the human-computer interface, the externalsystem interfaces that enable different applications tointeroperate, and the internal interfaces that enableprogram data to be communicated among softwarecomponents. Finally, procedural design is conductedas algorithms are created to implement the processingrequirements of program components.

Like the pyramid depicted in Figure 6, designshould be a stable object. Yet, many software devel-opers do design by taking the pyramid and standing it

21

on its point. That is, design begins with the creation ofprocedural detail, and as a result, interface, architec-tural, and data design just happen. This approach,common among people who insist upon coding theprogram with no explicit design activity, invariablyleads to low-quality software that is difficult to test,challenging to extend, and frustrating to maintain. Fora stable, high-quality product, the design approachmust also be stable. The design pyramid provides thedegree of stability necessary for good design.

7.4 Program Construction

The glory years of third-generation programminglanguages are rapidly coming to a close. Fourth-generation techniques, graphical programming meth-ods, component-based software construction, and avariety of other approaches have already captured asignificant percentage of all software constructionactivities, and there is little debate that their penetra-tion will grow.

And yet, some members of the software engineer-ing community continue to debate "the best program-

ming language." Although entertaining, such debatesare a waste of time. The problems that we continue toencounter in the creation of high-quality computer-based systems have relatively little to do with themeans of construction. Rather, the challenges that faceus can only be solved through better or innovativeapproaches to analysis and design, more comprehen-sive SQA techniques, and more effective and efficienttesting. It is for this reason that construction is notemphasized in this paper.

7.5 Software Testing

Glen Myers [38] states three rules that can servewell as testing objectives:

1. Testing is a process of executing a programwith the intent of finding an error.

2. A good test case is one that has a high prob-ability of finding an as-yet-undiscoverederror.

3. A successful test is one that uncovers anas-yet-undiscovered error.

Figure 6. The design pyramid

22

These objectives imply a dramatic change in view-point. They move counter to the commonly held viewthat a successful test is one in which no errors arefound. Our objective is to design tests that systemati-cally uncover different classes of errors and to do sowith a minimum of time and effort.

If testing is conducted successfully (according tothe objective stated above), it will uncover errors inthe software. As a secondary benefit, testing demon-strates that software functions appear to be workingaccording to specification, that performance require-ments appear to have been met. In addition, data col-lected as testing is conducted provides a good indica-tion of software reliability and some indication ofsoftware quality as a whole. But there is one thing thattesting cannot do: testing cannot show the absence ofdefects, it can only show that software defects are pre-sent. It is important to keep this (rather gloomy) state-ment in mind as testing is being conducted.

7.5.1 StrategyA strategy for software testing integrates software

test-case design techniques into a well-planned seriesof steps that result in the successful construction ofsoftware. It defines a template for software testing—aset of steps into which we can place specific test-casedesign techniques and testing methods.

A number of software testing strategies have beenproposed in the literature. All provide the softwaredeveloper with a template for testing, and all have thefollowing generic characteristics:

• Testing begins at the module level and worksincrementally "outward" toward the integra-tion of the entire computer-based system.

• Different testing techniques are appropriate atdifferent points in time.

• Testing is conducted by the developer of thesoftware and (for large projects) an inde-pendent test group.

• Testing and debugging are different activities,but debugging must be accommodated in anytesting strategy.

A strategy for software testing must accommodatelow-level tests that are necessary to verify that a smallsource code segment has been correctly implemented,intermediate-level tests designed to uncover errors inthe interfaces between modules, and high-level teststhat validate major system functions against customerrequirements. A strategy must provide guidance forthe practitioner and a set of milestones for the man-ager. Because the steps of the test strategy occur at atime when deadline pressure begins to rise, progress

must be measurable and problems must surface asearly as possible.

7.5.2 TacticsThe design of tests for software and other engi-

neered products can be as challenging as the initialdesign of the product itself. Recalling the objectives oftesting, we must design tests that have the highestlikelihood of finding the most errors with a minimumof time and effort.

Over the past two decades a rich variety of test-case design methods have evolved for software. Thesemethods provide the developer with a systematicapproach to testing. More importantly, methods pro-vide a mechanism that can help to ensure the com-pleteness of tests and provide the highest likelihoodfor uncovering errors in software.

Any engineered product (and most other things)can be tested in one of two ways: (1) knowing thespecified function that a product has been designed toperform, tests can be conducted that demonstrate eachfunction is fully operational; (2) knowing the internalworkings of the product, tests can be conducted toensure that "all gears mesh"; that is, internal operationperforms according to specification and all internalcomponents have been adequately exercised. The firsttest approach is called black-box testing and the sec-ond, white-box testing [38].

When computer software is considered, black-boxtesting alludes to tests that are conducted at the soft-ware interface. Although they are designed to uncovererrors, black-box tests are also used to demonstratethat software functions are operational; that input isproperly accepted, and output is correctly produced;that the integrity of external information (such as datafiles) is maintained. A black-box test examines someaspect of a system with little regard for the internallogical structure of the software.

White-box testing of software is predicated onclose examination of procedural detail. Logical pathsthrough the software are tested by providing test casesthat exercise specific sets of conditions and/or loops.The status of the program may be examined at variouspoints to determine if the expected or asserted statuscorresponds to the actual status.

8.0 The Road Ahead & The Three R's

Software is a child of the latter half of the twenti-eth century—a baby boomer. And like its humancounterpart, software has accomplished much while atthe same time leaving much to be accomplished. Itappears that the economic and business environmentof the next ten years will be dramatically different thananything that baby boomers have yet experienced.

23

Staff downsizing, the threat of outsourcing, and thedemands of customers who won't take "slow" for ananswer require significant changes in our approach tosoftware engineering and a major revaluation of ourstrategies for handling hundreds of thousands ofexisting systems [39].

Although many existing technologies will matureover the next decade, and new technologies willemerge, it's likely that three existing software engi-neering issues—I call them the three R's—will domi-nate the software engineering scene.

8.1 Reuse

We must build computer software faster. This sim-ple statement is a manifestation of a business environ-ment in which competition is vicious, product lifecycles are shrinking, and time to market often definesthe success of a business. The challenge of fasterdevelopment is compounded by shrinking humanresources and an increasing demand for improvedsoftware quality.

To meet this challenge, software must be con-structed from reusable components. The concept ofsoftware reuse is not new, nor is a delineation of itsmajor technical and management challenges [40]. Yetwithout reuse, there is little hope of building softwarein time frames that shrink from years to months.

It is likely that two regions of the methods land-scape may merge as greater emphasis is placed onreuse. Object-oriented development can lead to thedesign and implementation of inherently reusable pro-gram components, but to meet the challenge, thesecomponents must be demonstrably defect free. It maybe that formal methods will play a role in the devel-opment of components that are proven correct prior totheir entry in a component library. Like integratedcircuits in hardware design, these "formally" devel-oped components can be used with a fair degree ofassurance by other software designers.

If technology problems associated with reuse areovercome (and this is likely), management and culturalchallenges remain. Who will have responsibility forcreating reusable components? Who will manage themonce they are created? Who will bear the additionalcosts of developing reusable components? What in-centives will be provided for software engineers to usethem? How will revenues be generated from reuse?What are the risks associated with creating a reuseculture? How will developers of reusable componentsbe compensated? How will legal issues such as liabil-ity and copyright protection be addressed? These andmany other questions remain to be answered. And yet,component reuse is our best hope for meeting the

software challenges of the early part of the twenty-firstcentury.

8.2 Reenguneering

Almost every business relies on the day-to-dayoperation of an aging software plant. Major companiesspend as much as 70 percent or more of their softwarebudget on the care and feeding of legacy systems.Many of these systems were poorly designed morethan decade ago and have been patched and pushed totheir limits. The result is a software plant with aging,even decrepit systems that absorb increasingly largeamounts of resource with little hope of abatement. Thesoftware plant must be rebuilt, and that demands areengineering strategy.

Reengineering takes time; it costs significantamounts of money, and it absorbs resources that mightbe otherwise occupied on immediate concerns. For allof these reasons, reengineering is not accomplished ina few months or even a few years. Reengineering ofinformation systems is an activity that will absorbsoftware resources for many years.

A paradigm for reengineering includes the follow-ing steps:

• inventory analysis—creating a prioritized listof programs that are candidates for reengi-neering

• document restructuring—upgrading docu-mentation to reflect the current workings of aprogram

• code restructuring—recoding selected por-tions of a program to reduce complexity,ready the code for future change, and im-prove understandability

• data restructuring—redesigning data struc-tures to better accommodate current needs;redesign the algorithms that manipulate thesedata structures

• reverse engineering—examine software in-ternals to determine how the system has beenconstructed

• forward engineering—using information ob-tained from reverse engineering, rebuild theapplication using modern software engineer-ing practices and principles.

8.3 Retooling

To achieve the first two R's, we need a third R—anew generation of software tools. In retooling thesoftware engineering process, we must remember the

24

mistakes of the 1980s and early 1990s. At that time,CASE tools were inserted into a process vacuum, andfailed to meet expectations. Tools for the next tenyears will address all aspects of the methods land-scape. But they should emphasize reuse and reengi-ncering.

9.0 Summary

As each of us in the software business looks to thefuture, a small set of questions is asked and re-asked.Will we continue to struggle to produce software thatmeets the needs of a new breed of customers? Willgeneration X software professionals repeat the mis-takes of the generation that preceded them? Will soft-ware remain a bottleneck in the development of newgenerations of computer-based products and systems?The degree to which the industry embraces softwareengineering and works to instantiate it into the cultureof software development will have a strong bearing onthe final answers to these questions. And the answersto these questions will have a strong bearing onwhether we should look to the future with anticipationor trepidation.

References

[1] Naur, P. and B. Randall (eds.), Software Engineering:A Report on a Conference Sponsored by the NATOScience Committee, NATO, 1969.

[2] Paulk, M. et al., Capability Maturity Model for Soft-ware, Software Engineering Institute, Carnegie MellonUniversity, Pittsburgh, PA, 1993.

[3] Boehm, B., "A Spiral Model for Software Developmentand Enhancement," Computer, Vol. 21, No. 5, May1988, pp. 61-72.

[4] Gilb, T., Principles of Software Engineering Manage-ment, Addison-Wesley, Reading, Mass., 1988.

[5] Mills, RD., M. Dyer, and R. Linger, XleanroomSoftware Engineering," IEEE Software, Sept. 1987,pp. 19-25.

[6] Dyer, M., The Cleanroom Approach to Quality Soft-ware Development, Wiley, New York, N.Y., 1992.

[7] Cougar, J. and R. Zawacki, Managing and MotivatingComputer Personnel, Wiley, New York, N.Y., 1980.

[8] DeMarco, T. and T. Lister, Peopleware, Dorset House,1987.

[9] Weinberg, G., Understanding the Professional Pro-grammer, Dorset House, 1988.

[10] Curtis, B., "People Management Maturity Model,"Proc, Int'l Conf Software Eng., IEEE CS Press, LosAlamitos, Calif., 1989, pp. 398-399.

[11] August, J.R, Joint Application Design, Prentice-Hall,Englewood Cliffs, N.J., 1991.

[12] Wood, J. and D. Silver, Joint Application Design,Wiley, New York, N.Y., 1989.

[13] Dreger, J.B., Function Point Analysis, Prentice-Hall,Englewood Cliffs, N.J., 1989.

[14] Hetzel, B., Making Software Measurement Work, QEDPublishing, 1993.

[15] Jones, C, Applied Software Measurement, McGraw-Hill, New York, N.Y., 1991.

[16] Fenton, N.E., Software Metrics, Chapman & Hall,1991.

[17] Zuse, H., Software Complexity, W. deGruyer & Co.,Berlin, 1990.

[18]Lorenz, M. and J. Kidd, Object-Oriented SoftwareMetrics, Prentice-Hall, Englewood Cliffs, N.J., 1994.

[19] Pressman, R.S., A Manager's Guide to Software Engi-neering, McGraw-Hill, New York, N.Y., 1993.

[20] Boehm, B., Software Engineering Economics, Prentice-Hall, Englewood Cliffs, N.J., 1981.

[21] Charette, R., Application Strategies for Risk Analysis,McGraw-Hill, New York, N.Y., 1990.

[22] Jones, C, Assessment and Control of Software Risks,Yourdon Press, 1993.

[24] Crosby, P., Quality is Free, McGraw-Hill, New York,N.Y., 1979.

[25] McCall, J., P. Richards, and G. Walters, "Factors inSoftware Quality," three volumes, NTIS AD-A049-014,015,055, Nov. 1977.

[26] Cavano, J.P. and J.A. McCall, "A Framework for theMeasurement of Software Quality," Proc. ACM Soft-ware Quality Assurance Workshop, ACM Press, NewYork, N.Y., 1978, pp. 133-139.

[27] Freedman, D and G. Weinberg, The Handbook ofWalkthroughs, Inspections and Technical Reviews,Dorset House, 1990.

[28] Gilb, T. and D. Graham, Software Inspection, Addison-Wesley, Reading, Mass., 1993.

[29] Babich, W., Software Configuration Management,Addison-Wesley, Reading, Mass., 1986.

[30] Pressman, R. and S. Herron, Software Shock, DorsetHouse, 1991.

[31] Pressman, R., Software Engineering: A Practitioner'sApproach, 3rd ed., McGraw-Hill, New York. N.Y.,1992.

[32] Yourdon, E., Modern Structured Analysis, YourdonPress, 1989.

[33] Booch, G., Object-Oriented Analysis & Design, Ben-jamin-Cummings, 1994.

25

[34] Spivey, M., The Z Notation, Prentice-Hall, Englewood [38] Myers, G., The Art of Software Testing, Wiley, NewCliffs, N.J., 1992. York, N.Y., 1979.

[35] Jackson, M., Principles of Program Design, Academic [38] Beizer, B., Software Testing Techniques, 2nd ed.,Press, New York, N.Y., 1975. VanNostrand Reinhold, 1990.

[36] Pamas, D.L., "On Criteria to be used in Decomposing r^M ^ « „„ , *Systems into Modules," Comm. ACM, Vol. 14, No. 1, ™ P

uressn™; ^l™*™ T

A ° T ± ! g * n!C°n° Ma"Apr 1972 pp 221-227 chiavelh," IEEE Software, Jan. 1995, pp. 101-102.

[37] Linger, R., H. Mills, and B. Witt, Structured Pro- [40] Tracz, W., Software Reuse: Emerging Technology,gramming, Addison-Wesley, Reading, Mass., 1979. IEEE CS Press, Los Alamitos, Calif., 1988.

26

Software Engineering—20 Years On and 20 YearsBack*

J. N. BuxtonDepartment of Computing, Kings College, London

This paper gives a personal view of the developmentof software engineering, starting from the NATO con-ferences some 20 years ago, looking at the currentsituation and at possible lines of future development.Software engineering is not presented as separate fromcomputer science but as the engineering face of thesame subject. It is proposed in the paper that significantfuture developments will come from new localizedcomputing paradigms in specific application domains.

2 0 YEARS BACK

The start of the development of software engineering asa subject in its own right, or perhaps more correctly asa new point of view on computing, is particularlyassociated with the NATO conferences in 1968 and1969. The motivations behind the first of these meet-ings was the dawning realization that major softwaresystems were being fuilt by groups consisting essen-tially of gifted amateurs. The endemic problems of the"software crisis"—software was late, over budget, andunreliable—already affected small and medium systemsfor well-coordinated applications and would clearlyhave even more serious consequences for the really bigsystems which were being planned.

People in the profession typically had scientific back-grounds in mathematics, the sciences, or electronics. In1968 we had already achieved the first big break-through in the subject—the development of high-levelprogramming languages—and the second was awaited.The time was ripe for the proposition which was floatedby the NATO Science Committee, and by ProfessorFritz Bauer of Munich, among others, that we shouldconsider the subject as a branch of engineering; other

Address correspondence to Professor J. N. Bwcton. Depart-ment of Computing. Kings College London, Strand. LondonWC2R2LS, England.

•The paper is a written version of the keynote address at theInternational Conference on Software Engineering, Pittsburgh. May,1989.

professions built big systems of great complexity andby and large they called themselves "engineers," andperhaps we should consider whether we should do thesame. Our big systems problems seemed primarily tobe on the software side and the proposition was that itmight well help to look at software development fromthe standpoint of the general principles and methods ofengineering. And so, the first NATO Conference onSoftware Engineering was convened in GarmischParten-Kirchen in Bavaria.

It was an inspiring occasion. Some 50 people wereinvited from among the leaders in the field and from thefirst evening of the meeting it was clear that we shareddeep concerns about the quality of software being builtat the time. It was not just late and over budget; evenmore seriously we could see, and on that occasion wewere able to share our anxieties about, the safetyaspects of future systems.

The first meeting went some way to describing theproblems—the next meeting was scheduled to followafter a year which was to be devoted to study of thetechniques needed for its solution. We expected, ofcourse, that a year spent in studying the application ofengineering principles to software development wouldshow us how to solve the problem. It turned out thatafter a year we had not solved it and the secondmeeting in Rome was rather an anticlimax. However,the software engineering idea was now launched: it hassteadily gathered momentum over some 20 years. Somewould no doubt say that it has become one of the greatbandwagons of our time; however, much has beenachieved and many central ideas have been developed:the need for management as well as technology, thesoftware lifecycle, the use of toolsets, the application ofquality assurance techniques, and so on.

So during some 20 years, while the business hasexpanded by many orders of magnitude, we have beenable to keep our heads above water. We have putcomputers to use in most fields of human endeavor, we

Reprinted from / Systems and Software, Vol. 13, JLN. Buxton, "Software Engineering—20 Years On and 20 Years Back," pp. 153-155,1990, with kind permission from Elsevier Science-NL, Sara Burgerhartstraat 25; 1055 KV Amsterdam, The Netherlands.

27

have demonstrated that systems of millions of lines ofcode taking hundreds of man-years can be built toacceptable standards, and our safety record, while notperfect, has so far apparently not been catastrophic.The early concepts of 20 years ago have been muchdeveloped: the lifecycle idea has undergone much re-finement, the toolset approach has been transformed bycombining unified toolsets with large project data bases,and quality control and assurance is now applied as inother engineering disciplines. We now appreciate moreclearly that what we do in software development canwell be seen as engineering, which must be under-pinned by scientific and mathematical developmentswhich produce laws of behavior for the materials fromwhich we build: in other words, for computer pro-grams.

THE PRESENT

So, where is software engineering today? In my viewthere is indeed a new subject of "computing" whichwe have to consider. It is separate from other disci-plines and has features that are unique to the subject.The artifacts we build have the unique property ofinvisibility and furthermore, to quote David Parnas, thestate space of their behavior is both large and irregular.In other words, we cannot "see" an executing programactually running; we can only observe its conse-quences. These frequently surprise us and in this branchof engineering we lack the existence of simple physicallimits on the extent of erroneous behavior. If you builda bridge or an airplane you can see it and you canrecognize the physical limitations on its behavior—thisis not the case if you write a computer program.

The subject of computing has strong links and rela-tionships to other disciplines. It is underpinned bydiscrete mathematics and formal logic in a way stronglyanalogous to the underpinning of more traditionalbranches of engineering by physics and continuousmathematics. We expect increasing help from relevantmathematics in determining laws of behavior for oursystems and of course we rely on electronics for theprovision of our hardware components. A computer isan electronic artifact and is treated as such when it isbeing built or when it fails; at other times we treat it asa black box and assume it runs our program perfectly.

At the heart of the subject, however, we have thestudy of software. We build complex tnultilayered pro-grams which eventually implement applications forpeople—who in turn treat the software as a black boxand assume it will service their application perfectly.

So, where and what is software engineering? I do notregard it as a spearate subject. Building software isperhaps the central technology in computing and muchof what we call software engineering is, in my view,

the face of computing which is turned toward applica-tions. The subject of computing has three main aspects:computer science is the face turned to mathematics,from which we seek laws of behavior for programs;computer architecture is the face turned to the electron-ics, from which we build our computers; and softwareengineering is the face turned toward the users, whoseapplications we implement. I think the time has come toreturn to a unified view of our subject—software engi-neering is not something different from computer sci-ence or hardware design—it is a different aspect orspecialty within the same general subject of computing.

20 YEARS ON

To attempt to answer the question, Where should we gonext and what of the next 20 years? opens interestingareas of speculation. As software engineers, our con-cerns are particularly with the needs of the users andour aims are to satisfy these needs. Our techniquesinvolve the preparation of computer programs and Ipropose to embark on some speculation based on astudy of the levels of language inwhich these programsare written.

The traditional picture of the process of implement-ing an application is, in general, as follows. The userpresents a problem, expressed in his own technicalterminology or language, which could be that of com-merce, nuclear physics, medicine or whatever, tosomebody else who speaks a different language in theprofessional sense. This is the language of algorithmsand this person devises an algorithmic solution to thespecific user problem, i.e., a solution expressed incomputational steps, sequences, iterations, choices.This person we call the "systems analyst19 and indeed,in the historical model much used in the data processingfield, this person passes the algorithms on to a "realprogrammer" who thinks and speaks in the codeof thebasic computer hardware.

The first major advance in computing was the gen-eral introduction of higher level languages such asFORTRAN and COBOL—as in effect this eliminatedfrom all but some specialized areas the need for thelower level of language, i.e., achine or assembly codeprogramming. The separate roles of systems analystand programmer have become blurred into the conceptof the software engineer who indeed thinks in algo-rithms but expresses these directly himself in one of thefashionable languages of the day. This indeed is abreakthrough and has given us an order of magnitudeadvance, whether we measure it in terms of productiv-ity, size of application we can tackle, or quality ofresult.

Of course we have made other detailed advances—wehave refined our software engineering techniques, wehave devised alternatives to algorithmic programming

28

in functional and rule-based systems, and we have donemuch else. But in general terms we have not succeededin making another general advance across the board inthe subject.

In some few areas, however, there have been realsuccesses which have brought computing to orders ofmagnitude more people with applications. These havebeen in very specific application areas, two of whichspring to mind—spreadsheets and word processors. Inmy view, study of these successes gives us most valu-able clues as to the say ahead for computing applica-tions.

The spreadsheet provides a good example for study.The generic problem of accountancy is the presentationof a set of figures which are perhaps very complexlyrelated but which must be coherent and consistent. Thepurpose is to reveal a picture of the formal state ofaffairs of an enterprise (so far, of course, as the accountatn thinks it wise or necessary to reveal it). Thetraditional working language of the accountatn is ex-pressed in rows and columns of figures on paper to-gether with their relationships. Now, the computer-based spreadsheet system automates the piece of paperand gives it magical extra properties which maintainconsistency of the figure under the relationships be-tween them as specified by the accountant, while headjusts the figures. In effect, the computer programautomates the generic problem rather than any specificset of accounts and so enables the accountant to expresshis problem of the moment and to seek solutions in hisown professional language. He need know nothing, forexample, of algorithms, high-level languages, or vonNeuman machines, and the intermediary stages of thesystems analyst and programmer have both disappearedfrom his view.

The same general remarks can be applied to wordprocessing. Here what the typist sees is in effect acombination of magic correcting typewriter and filingcabinet—and again the typist need know nothing ofalgorithms. In both these examples there has beenconspicuous success in introduction. And there areothers emerging, e.g., hypertext. And historically thereis much in the thesis that relates to the so-called 4GLsand, even earlier, to simulation languages in the 1960s.

Let me return to the consideration of levels of lan-guage, and summarize the argument so far. I postulateda traditional model for complete applications in which aspecific user problem, expressed in the language of thedomain of application, underwent a two-stage transla-tion: first into algorithms (or some language of similarlevel such as functional applications or Horn logicclauses) and second down into machine code. Our firstbreakthrough was to automate the lower of these stagesby the introduction of high-level languages, primarilyalgorithmic. I now postulate that the second break-

through will come in areas where we can automate theupper stage. Examples can already be found: veryclearly in specific closed domains such as spreadsheetsand word processors but also in more diffuse areasaddressed by very high-level languages such as 4GLsand simulation generators.

Perhaps I should add a word here about object~ori-entedness, as this is the best known buzz word oftoday. I regard an object-oriented approach as a halfwayhouse to the concept I am proposing. Objects indeedmodel those features of the real world readily mode-lable as classes of entities—that is why we invented theconcept in the simulation languages of the early 1960s.However, the rules of behavior of the object are stillexpressed algorithmically and so an object-oriented sys-tem still embodies a general purpose language.

It is central to the argument to realize that spread-sheets and such can be used by people who do notreadily think in terms of algorithms. The teaching ofprogramming has demonstrated over many years thatthinking in algorithms is a specific skill and mostpeople have little ability in transposing problems fromtheir own domains into algorithmic solutions. Attemptsto bring the use of computers to all by teaching themprogramming do not work; providing a service toworkers in specific domains directly in the language ofthat domain, however, does work and spectacularly so.

CONCLUSIONS

I come to the conclusion, therefore, that the mostpromising activity for the next 20 years is the searchfor more domains of applications in which the languageused to express problems in the domain is closed,consistent, and logically based. Then we can put for-ward generic computer-based systems which enableusers in the domain to express their problems in thelanguage of the application and to be given solutions intheir own terms. To use another buzz word of the day,I look for non-specific but localized paradigms forcomputing applications.

Of course this is not all that we might expect to do inthe next 20 years. We can do much more in developingthe underpinning technology in the intermediate levelsbetween the user and the machine. Most of our workwill still be devoted to the implementing of systems todeliver solutions to specific problems. But while weproceed with the day-to-day activities of software engi-neering or of the other faces of computing with whichwe may be concerned, wemight be wise to look out foropportunities to exploit new application domains wherewe can see ways to raise the '* level of programminglanguage'* until it becomes the same as the professionallanguage of that domain. Then, we will achieve anotherbreakthrough.

29