software engineering: the future of a profession

8
Software Engineering: The Future of a Profession John D. Musa, AT&T Bell Laboratories Increasing and diverse pressures, manpower shortages, and technology transfer problems all plague the growing software engineering profession. Industry, government, education, and the professional society together must help. T he environment in which soft- ware is being developed is chang- ing at an unprecedented rate in com- parison to that of other professions. Although this dynamic situation is a sign of a certain health in the pro- fession of software engineering, it also signals a present danger. The field is having enough trouble solving its many existing problems without also having to tackle new ones brought by change! To compound this, many of the old mechanisms for creating and disseminating technology appear to be obsolete. At this critical moment in the evolution of our profession, it is im- perative that we examine the environ- ment and problems we now face and, more importantly, expect to face in the future as a result of current trends. Such a view is critical if we are to -shape and direct change intelligently rather than merely respond to it. We must discuss the roles of some of our major institutions in dealing with our prob- lems and suggest how professional societies can guide these institutions to meet them. The environment Since its inception, the data process- ing industry has doubled in size ap- proximately every five years in the United States. As Figure 1 shows, this has made it an increasingly significant factor in the domestic economy, ' and it has had similar impact in many other countries as well. Figure 2 depicts the growth of the US data processing in- dustry in terms of computers and com- puter programmers. The expanding market for data processing is no doubt related to the fact that the cost-effec- tiveness of hardware has been growing by about three orders of magnitude per decade. Such an increase multiplies enormously the number of applica- tions for which computing becomes a feasible and economical solution, and in turn it places great demands on the software industry. While (due to reuse, duplication, and other causes) the total amount of software required has not increased by a factor of 1000 every 10 years, a conservative estimate indicates a tenfold increase in the demand for software each decade, or a hundred- fold increase between 1965 and 1985. Demand exceeding development. While the growth in demand for soft- ware has been rapid, actual software development has been increasing much more slowly. Productivity ad- vances between 1965 and 1975 were on the order of three percent per year, as shown in Figure 3. 1 If this rate is pro- jected through 1985, then productivi- ty between 1965 and 1985 will have in- creased by a factor of only 1.8. Multi- plying this by the estimated increase in the US computer programming population between 1965 and 1985 (from Figure 2), we calculate an effec- tive increase in output by a factor of about 18. This rate, when contrasted with the estimated increase in demand by a fac- tor of 100, represents a serious defi- ciency in software production capabil- ity. Nor does the problem end here. The "software shortage" may well in- hibit technological and economic de- velopment in other areas. A shortage of qualified software professionals exists and will probably 0740-7459/85/0001/0055$01.00 © 1985 IEEE 55 January 1985

Upload: jd

Post on 04-Mar-2017

219 views

Category:

Documents


3 download

TRANSCRIPT

Software Engineering:

The Future of a

Profession

John D. Musa, AT&T Bell Laboratories

Increasing and diversepressures, manpower

shortages, and technologytransfer problems all plague

the growing softwareengineering profession.Industry, government,education, and theprofessional societytogether must help.

T he environment in which soft-ware is being developed is chang-

ing at an unprecedented rate in com-parison to that of other professions.Although this dynamic situation is asign of a certain health in the pro-fession of software engineering, it alsosignals a present danger. The field ishaving enough trouble solving itsmany existing problems without alsohaving to tackle new ones brought bychange! To compound this, many ofthe old mechanisms for creating anddisseminating technology appear to beobsolete.At this critical moment in the

evolution of our profession, it is im-perative that we examine the environ-ment and problems we now face and,more importantly, expect to face in thefuture as a result of current trends.Such a view is critical ifwe are to-shapeand direct change intelligently ratherthan merely respond to it. We mustdiscuss the roles of some of our majorinstitutions in dealing with our prob-lems and suggest how professionalsocieties can guide these institutions tomeet them.

The environmentSince its inception, the data process-

ing industry has doubled in size ap-proximately every five years in theUnited States. As Figure 1 shows, thishas made it an increasingly significantfactor in the domestic economy, ' andit has had similar impact in many othercountries as well. Figure 2 depicts thegrowth of the US data processing in-dustry in terms ofcomputers and com-puter programmers. The expandingmarket for data processing is no doubt

related to the fact that the cost-effec-tiveness of hardware has been growingby about three orders of magnitudeper decade. Such an increase multipliesenormously the number of applica-tions for which computing becomes afeasible and economical solution, andin turn it places great demands on thesoftware industry. While (due to reuse,duplication, and other causes) the totalamount of software required has notincreased by a factor of 1000 every 10years, a conservative estimate indicatesa tenfold increase in the demand forsoftware each decade, or a hundred-fold increase between 1965 and 1985.

Demand exceeding development.While the growth in demand for soft-ware has been rapid, actual softwaredevelopment has been increasingmuch more slowly. Productivity ad-vances between 1965 and 1975 were onthe order of three percent per year, asshown in Figure 3. 1 If this rate is pro-jected through 1985, then productivi-ty between 1965 and 1985 will have in-creased by a factor of only 1.8. Multi-plying this by the estimated increasein the US computer programmingpopulation between 1965 and 1985(from Figure 2), we calculate an effec-tive increase in output by a factor ofabout 18.

This rate, when contrasted with theestimated increase in demand by a fac-tor of 100, represents a serious defi-ciency in software production capabil-ity. Nor does the problem end here.The "software shortage" may well in-hibit technological and economic de-velopment in other areas.A shortage of qualified software

professionals exists and will probably

0740-7459/85/0001/0055$01.00 © 1985 IEEE 55January 1985

Figure 1. Data processing in the UnitedStates as a percentage of gross nationalproduct.

continue for the foreseeable future.The spread of firmware and silicon en-gineering will compound the situationfurther, since the design techniques arelike those used in the software engi-neering profession.

It is therefore clear that softwareproductivity must be enhanced to thegreatest extent possible. However, anumber of forces will unfortunatelymake software engineering more diffi-cult in the near future. The complexityof systems is increasing dramatically.Computer networks require distrib-uted operating systems and distributeddatabases. Increasing emphasis on se-curity, privacy, and control of trans-

Figure 2. Computers and Programmers in US. (Data sources: M. Phister, DataProcessing Technology and Economics, 2nd edition, 1979; The 1983 ComputerData Book; Statistical Abstract of the United States 1984, US Department ofCommerce; "The Too-Mighty Dollar," New York Times 9/23/84.)

Figure 3. Relative programmer productivity.

border data flow necessitates secureoperating and database managementsystems. New computer architectures(e.g., data flow) may become com-mon. Thus, to increase software pro-ductivity will be a most difficultchallenge.

Public involvement. One source ofpressure on the software engineeringcommunity is more commercial and so-cial than technical. The advent of thepersonal computer has made comput-ing available to the general public. Thecomputer, with its associated software,is becoming a commonly used itemmuch like the automobile. Videotextand other services that make largequantities of data available on-line arespreading rapidly. Some educationalinstitutions are requiring each studentto purchase a personal computer. Thework place has been changing complex-ion with the rapid spread of word pro-cessing equipment, on-line files, andcomputing networks with electronicmail facilities.

Where is this involvement heading inthe future? Computers will be extreme-ly widespread, both as multipurposemachines in homes and offices and asdedicated (embedded) machines for ap-plications such as household environ-ment control. Most of the users of thesemachines will be naive. Certainly themajority of them will not be program-mers. This means that the quality of theinterface to humans must and probablywill improve. Two likely areas of im-provement are high-resolution interac-tive graphics and voice interaction. Fur-thermore, most software will providepackaged services that require little, ifany, programming. The packages willbe tailored to individual needs, in astandardized way, much as one nowselects options when purchasing a car.

We will come to think of computersprimarily as tools for accessing infor-mation, rather than primarily ascalculating machines. Networks willprovide a medium for making avail-able numerous public databases, bothpassive (catalogs, library facilities,newspapers) and active (newsletters,individualized entertainment). Distrib-

IEEE SOFTWARE

iol / / I' l1955 1960 1965 1970 1975 1980 1985

4

,i 32o0-*> 2

c,

1

1955 1960 1965 1970 1975 1980 1985I

56

uted applications such as electronicfunds transfer will become common.Electronic mail will reach a substantialfraction of the population.

Distributed systems and networkswill facilitate a distributed workplace,but it is doubtful that the norm for of-fice workers will be to work at homeinstead of in an office-computers willnot replace human interaction fordecision-making. However, softwaredevelopment's potential as a cottageindustry will increase. Electronic workstations will change the nature of workthat now depends on paper flow, androbotics will substantially changemanufacturing.

Finally, in education, the computerwill become as important a tool as thebook is today.The foregoing views raise a number

of issues in which software plays arole. The use of computer software bylarge numbers of nontechnical peopleraises concerns about consumer rightsand expectations and the responsibilityof vendors toward their products.These include problems associatedwith product and professional liabili-ty, warrantees, standards and com-patibility, and product safety. Howdoes the naive user select intelligentlyamong the many software packagesavailable? Do we need a ConsumersUnion or an Underwriters Laborator-ies for software and data? Is the ven-dor of data legally responsible for theconsequences to a consumer who actson any inaccurate information that issupplied? Since the viability of societyis increasingly dependent on software,program and database failures mustbe held to acceptable limits. Softwareengineering must be responsive to theproblems that do occur in a real-timesense. Many legal concerns exist aboutthe impact of computers and theirsoftware on society: security, privacy,licensing, copyrights, and transborderdata flow are just a few. Althoughresolution of many of these issues willoccur in the courts, few legal prece-dents now exist.

Convergence of software and hard-ware know-how. Another pressurethat complicates software engineering

is the increasingly blurred distinctionbetween hardware and software incomputing. The design, test, andmaintenance processes are becomingvery much alike, whether they refer tosoftware, firmware, or silicon.

Decisions on whether a software ora hardware (chip) component is thebest solution to a particular problemare made at many stages of the designprocess. Clearly, in this milieu, ex-

Since the viability of societyis increasingly dependent on

software, program anddatabase failures must beheld to acceptable limits.

pertise in a single field is too limitingfor a system designer. Note also thatwhen a hybrid system fails in opera-tion, the failure usually cannot be im-mediately attributed to either a soft-ware or hardware component. Thus,reliability and fault-tolerance becomeinterdisciplinary issues.

Hardware and software develop-ment phases appear to be reasonablysimilar, except during the quite dif-ferent manufacturing phase of hard-ware. Both engineering technologiesuse multiple levels of abstraction indesign. Exception handling and errorrecovery play predominant roles incode and logic. The largest cost compo-nent in both technologies is fixed; theincremental cost of reproduction is rel-atively low compared to developmentcosts. Both fields operate at the upperlimits of manageable complexity.

Nevertheless, differences are equal-ly strong. The hardware life cycle in-cludes the final physical layout as wellas the costly and technologically de-manding manufacturing phase; in thecase of software, it merely involves thesimple reproduction of program codeat negligible cost. Further, even alogically correct piece of hardwaremay have to be completely redesignedto increase yield in the manufacturingprocess-a consideration totally ab-sent in software production.

In general, the penalty for design er-rors committed early and discovered

later in operation is more serious inhardware, since corrective action in-volves not only update of stored infor-mation and documentation, but re-manufacture as well. Furthermore,hardware logic usually has much moreconcurrency than does software; hencetiming considerations must be strictlyfollowed during the entire life cycle.And while software modules can atleast in theory be made to an arbitrarysize, there is a predetermined absolutelimit to the capacity of a chip. Thesetime and space barriers make more it-erations necessary in the VLSI designcycle. But the physical limitations ofinterchip connections may have a dis-ciplining effect as well, with the sidebenefit of enforcing simple interfaces.This stands opposed to the often un-constrained intermodule communica-tion found in software.

Finally, in hardware, designers investin simulation to reduce the need for ex-pensive changes late in the developmentcycle. Also, investment in experimenta-tion, prototyping, and tools, whileoften absent in software, is taken forgranted in a hardware shop. For in-stance, design automation systems areconsidered indispensable, and the com-plexity of these systems exceeds eventhat of large operating systems.

The convergence of technologiesdiscussed above suggests that an exam-ination of some of the common prob-lems of both fields may be profitable.The following is a partial list of suchproblems.

(1) Functional decomposition musttake place relatively early in the designof software and VLSI. The conse-quences of various design alternativesare far reaching, yet decomposition to-day is done by rather slow manualmeans. More computer aid or at leastpartial automation is needed to guidethe decomposition and the selection ofinterfaces between the major compo-nents, so that we arrive at interfacesthat are simple yet reasonably stableunder maintenance.

(2) Current efforts in integratingtools around a workstation are carriedout by separate groups for software andVLSI. It is felt that the development of

January 1985 57

common standard workstations is fea-sible and could be economicallyattractive.

(3) There is vast experience in devel-opment of compilers for software. Inturn, VLSI engineers are putting addi-tional intelligence into compilersaimed at hardware design to cope withphysical, timing, and other constraintsnot present in software. Cross-fertili-zation between camps already takesplace, but more cooperation is needed.For instance, software engineering isprobably ahead in code optimization,while VLSI engineering may be moreadvanced in detecting potential con-currency.

(4) The advanced portability andreusability of standard parts in hard-ware has stimulated activities towardsimilar goals in software. Although theproblems are somewhat different inthe two areas, joint efforts could bebeneficial. In general, standardizationis often a stepchild, particularly insoftware engineering.

(5) On one hand, formal verifica-tion is more advanced in software andsome of the results could be used inhardware. On the other hand, the re-quirement for testability is traditional-ly a hardware concept, and this con-cept has not achieved the same state ofdevelopment in software.

(6) Quantitative measures of relia-bility, complexity, performance, etc.,have been separately pursued for soft-ware and hardware, although there isno reason for this isolation. Someproject cost estimation models couldalso be generalized to cover all com-puter system projects.

(7) Finally, it seems that the lack ofrigorous requirement technology andassociated documentation techniquesplagues both software maintenanceand the hardware engineering changeprocess. Languages and notations aretoo numerous and this suggests theneed for standardization. Attractivemodern graphic notations are particu-larly costly to store and machine-process, and so their standardization isessential to eliminating waste.

The technology lag. Software engi-neering technology may be defined asthe set of methods and tools that isused in the software development pro-cess. As previously noted, improve-ments in software engineering produc-tivity have come very slowly. Onereason for this is that the technologyof software engineering has also devel-oped slowly.

There are probably several reasonsfor this. First, there has been little at-

There has beeninsufficient connectionbetween research done inour academic communityand software practice.

tempt to develop a consensus on goalsfor computing technology in generaland software engineering technologyin particular (although this is startingto change with efforts such as Japan'sFifth Generation Program and the USDepartment of Defense STARS ef-fort). Second, R&D funding has beenwoefully inadequate. This may bepartly due to lack of industrial incen-tives to improve software technology,given the lack of satisfactory legal pro-tection for software. Third, noncom-petitive salaries and support levels foruniversity computing science depart-ments have resulted in a brain drain oflarge proportions and this has im-pacted basic research. Finally, therehas been insufficient connection be-tween research done in our academiccommunity and software practice. Thefeedback loop from industry back intoresearch programs needs to be strength-ened to ensure relevance.The creation of technology is gen-

erally unstructured, unguided, andslow. While these characteristics areinherent to the process, we can im-prove it by taking steps to (a) defineproblem areas needing solution, (b)encourage the development of a diver-sity of viewpoints, (c) foster the con-vergence of different streams of think-ing, and (d) test and comparativelyevaluate ideas and the techniques,methods, and tools that arise fromthem. There is some doubt as to the

degree to which these favorable factorshave been fostered in software engi-neering.Many software engineering ideas do

not lead to practical "products," butpure concepts can be very importantfor their effects in terms of new ideasor changes in the way software is pro-duced or supported.

Software engineering lacks, in gen-eral, mechanisms and procedures forsystematic, comparative evaluation; inparticular, experiments conducted todate in software engineering generallydo not set up and test hypotheses-that is, they do not adhere to the scien-tific method. Further, these are gener-ally not controlled experiments butrather relative measurements of thevalue of an idea. Most demonstrationsof effectiveness can be characterized asdemonstrations in-the-small: they donot provide the data needed to assessan idea with respect to large-scale soft-ware systems.

Technology transfer problems. Inessence, the concept of technologytransfer means advancing in an order-ly, coherent fashion the boundaryknown as "the state of the practice,"and linking it directly to improvementsin "the state of the art." In softwareengineering, the goal of technologytransfer is to improve the practice ofsoftware development to attain in-creased productivity and improvedproduct quality. We can simplify thisto the notion of recognizing and imple-menting good ideas. "Practice" re-quires institutionalization of the ideasin the fabric of the industry.There are several characteristics (in

effect, problems) which differentiatethe transfer of software technologyfrom the transfer of other technolo-gies. Any one may not be unique tosoftware engineering, but it is the com-bination and interaction of themwhich makes software engineeringtechnology difficult to transfer:(1) explosive growth in number of

practitioners;(2) diversity of practice;(3) insufficient quantitative objectives

for evaluation of software engi-neering technology;

IEEE SOFTWARE58

(4) lack of an adequate professionalsystem for selection, evaluation,and dissemination of ideas, meth-ods, and tools;

(5) the intellectual character of soft-ware development and the diffi-culty of conveying problem-solv-ing methodologies;

(6) insufficient formalization of con-cepts and lack of underlying baseof theory;

(7) lack of software literacy and soft-ware engineering background intop-level management; and

(8) proprietary attitudes toward soft-ware engineering technology.

Institutional rolesFortunately, there are some social

institutions, both in the US andabroad, that have the resources tomake an impact on the foregoingproblems. However, the actions ofthese institutions must be planned,coordinated, and directed in a cohe-sive fashion.

Educational institutions. The educa-tional system represents an excellentpotential force for influencing thepublic and raising its overall level ofconsciousness about software engi-neering. However, it is first necessaryto develop clear objectives that in-structors understand and support.

It is believed that the best point ofeducational leverage at the currenttime is the secondary school level.Here, the objectives are to increasecomputer literacy and introduce com-puter programming to those who willneed it in their careers.

In the primary schools, emphasisshould be on basic computer literacythrough introductory courses in spe-cial education programs and generaltreatment in basic science courses.At the college level there are two

needs. There should be continued em-phasis on the production of softwareengineers. There should also be in-creased emphasis on computer sciencein teacher-training curricula, to pro-vide the capability to meet the educa-tional objectives of the primary andsecondary school levels. Unfortunate-

ly, due to limited computer personnelresources and industry's desire to ex-pand into new markets, industry hasbeen draining university computer sci-ence talent.

Continuing education programsrepresent an excellent opportunity toraise the level of understanding of thelay public. They can also be used toprovide rapid education -for the ex-isting primary- and secondary-school-level teacher corps.

Government. The government, andin particular the Department of De-fense, is the largest user and producerof software in the US. The DoD spentapproximately $7 billion in 1980 onsoftware.2 This places the governmentin a key leadership position. The DoDdirects a large research and develop-ment program ($250 million per year)in computing technology and is aleading initiator of data processingstandards. Despite these facts, severalconcerns still exist about government'sposition and actions in the softwarearena. These concerns seem likely toexist in other countries as well.

(1) There appears to be insufficientunderstanding on the part of the gov-ernment of the impact computing hason the economy and the impact soft-ware engineering has on our ability toexploit the opportunities opened up bythe rapid advances in computer hard-ware.

(2) There is a lack of coordinationamong software engineering R&Dprograms. Software engineering R&Dproducts are not being properly dis-seminated to the public and industry atlarge.

(3) There is no clearly stated goalwith respect to computing (and hence,software engineering).Most of us believe that a national

program (perhaps ultimately leadingto an international program) needs tobe developed and articulated. Com-puting and software engineering goalsneed to be defined and focused. Possi-ble agents in the US to create this fo-cus are the DoD, the National ScienceFoundation, and the National Bureauof Standards. Under such leadership,

education, industrial and governmen-tal sectors could organize and imple-ment programs that are needed todeal with the situation we have beendiscussing.

Industry. The industrial sector'smotivation is primarily to develop andmarket goods and services for profit.In the data processing industry thestrategy is to build and market itemsthat can be mass-produced for repeatsales. Here a distinct difference existsbetween hardware and software. Soft-ware is so easy to copy that the de-veloper has little protection for theheavy development costs incurred.Therefore, for the most part, industrymotivation has been to retain a soft-ware engineering capability to supporthardware sales but not to producemarketable software. Hence, industrymotivation has primarily been directedtoward improving hardware technol-ogy. Software technology has im-proved at a relatively slow pace.

It is essential that both legal andtechnical means be developed to pro-tect software, and attention is begin-ning to be directed to the problem. Weneed stimulation equivalent to thatgiven hardware products by the patentsystem and by the expense of the pro-duction process. Otherwise, the fullpotential of industry cannot be un-locked for the creation of software.

The role of the professionalsociety

Professional societies generally relyon voluntary help and have limitedfinancial resources. They do provide ameans for close interaction between in-dividuals with a great diversity ofbackgrounds and views, however, par-ticularly among the leadership of theprofession. They have great flexibilityin the issues they choose to address,having no particular vested interest.Hence, they often have the greatestpotential for generating creative, in-sightful solutions to difficult prob-lems. Also, they generally are con-nected with communication media ofhigh prestige and great influence in theprofession. Consequently, they pro-vide an excellent conduit for ideas.

January 1985 59

Planning. With their limitationsand their potential, professional socie-ties clearly have an important role toplay in the dynamic yet fragmentedfield of software engineering. We havenoted that the field lacks clear goals,planning, and direction. The situationmight be contrasted with other fieldssuch as nuclear fusion power, cancer

research, etc. It is clear that profes-sional groups should take an activerole in setting these goals. An orga-

nized but flexible planning process isprobably vital if we are to deal effec-tively with the rapidly changing en-

vironment.

Public concerns. Computing has a

large and increasing impact on con-

sumers, but their interests with respectto software are not yet well understoodor protected. Professional societiescan and should take the lead in identi-fying issues of concern to consumers

and providing responsible technicaladvice to aid in their resolution. Thereare many ways to pursue this goal.Conferences and workshops involvingconsumer groups, lawyers, and publicofficials should be organized to iden-tify and explore the important con-

sumer issues and actions. Materialshould then be prepared to educate theconsumer on the technical aspects ofthese issues. Programs should be set upto provide speakers, both to the publicin general and to meetings of otherprofessional societies. Contacts be-

tween software engineering leadersand the general information mediamust be cultivated.

Technology creation. Most re-

searchers tend to focus in depth (andrightly so) on the problems they are

trying to solve. No single investigatorhas the time or the diversity of ex-

perience to understand and interpretthe effects of all the forces that are

rapidly changing software engineer-ing. Hence, that researcher may notrecognize a change in the situation thatrenders unimportant the problem be-ing solved; or he or she may miss op-

portunities for new insights and ap-

proaches.Societies should establish task

forces to assess the potential of currentresearch trends in software engineer-ing for producing significant changesin practice, identify new areas of re-

search that are needed and that do notnow have significant activity, and rec-

ommend priorities for applied soft-ware engineering research.

It is important to stimulate cross-

fertilization between software engi-neering and other fields that sharesimilar problems and approaches tosolutions: especially VLSI engineeringbut also database technology, personalcomputing, graphics, human factors,artificial intelligence, etc. Some pos-

sibilities include joint curriculum plan-ning, interdisciplinary workshops,cross-field tutorials (e.g., a VLSI tu-

torial for software engineers), cross-

field sessions at conferences, and jointstandards development. Journals andmagazines should stimulate and inviteinterdisciplinary papers.

One recommendation for enhanc-ing the process of technology creationis to commission a "Best Idea" mono-graph series. In each monograph, an

idea from two to four years ago, ad-judged a "best idea" by a panel of ex-

perts, could be explored from thestandpoint of how it was conceived,how it has matured over the years, andhow it has been applied. A key objec-tive here is to both stimulate furtherdevelopment and application of theidea and to encourage the creation ofnew ideas from the divergent views of

the subject.

Many of the people who could makeimportant contributions to softwareengineering are software managers

with a research bent. They have thepractical experience to understandwhat is needed and the capability topursue a solution. We need to findways to free them from their duties fora few years to do so. It is recom-

mended that foundations and corpor-

ations be approached as sponsors forhigh-level fellowships for this purpose.

The professional societies shouldpromote in government and industrythe establishment of experimental lab-oratories where common techniquesand tools are explored and systemat-ically evaluated.A software engineering institute is

recommended as a continuing focalpoint for software engineering re-

search. The institute would be a world-class organization, involving both per-

manent and visiting staff. It wouldjoin with the professional societies inundertaking the all-important plan-ning function noted above. It wouldhelp stimulate cross-fertilization ofdifferent fields. Finally, it would assistwith the assessment of various ideas,particularly by applying them in realis-tic environments. It should sponsor

some of the experimentation with largesoftware projects that is so desperatelyneeded. Professional societies shouldpublicize the need for such an institute,

IEEE SOFTWARE

Article contributorsThis article resulted from a three-day retreat of US leaders in the field

of software engineering held in Columbia, Maryland. Organized by theauthor with the assistance of seven discussion leaders, the retreatsought to assess the present state of the field and to explore ways inwhich professional societies could address the problems identified. Thefollowing individuals contributed to the analyses and recommendationscontained here.Discussion Leaders ParticipantsVictor R. Basili W. Richards Adrion Seymour JeffreyLes Belady Joseph C. Batz John ManleyJack Distaso Lorraine Duvall Don O'NeillJohn Marciniak Peter Freeman Robert PostonJohn Munson John Gannon Achilles SarrisWilliam E. Riddle Nico Habermann Anthony WassermanMary Shaw Herbert Hecht Marvin Zelkowitz

60

help define its charter and participatein its formation. (See sidebar below.)

Technology transfer. One of theproblems in the transfer of softwareengineering technology is that we donot know very well which ideas, tools,etc., are worthy of being transferred.More and better comparative tech-nology evaluation must be done. High-quality evaluation requires a contin-uing, long-term effort. Diversity mustbe encouraged to bring out a widerange of competing ideas and tools. Atthe same time, extensive interactionbetween the advocates of various ap-proaches is necessary to ensure that thepros and cons of each strategy are

thoroughly probed. Workshops pro-vide diversity and interaction, but donot provide sufficient time. The pro-cess used for standards developmentappears well suited for this sort of ac-

tivity if its goal is changed to theevaluation, organization, and clarifi-cation of the present knowledge of thefield in order to stimulate furtherdiscovery. It is particularly importantthat we encourage the design and per-formance 'of experiments, especiallyexperiments concerning large-scalesoftware systems.

Increased support should be givento the generation and dissemination ofstandards, especially in the selectionand synthesis of methods to supportthe software development process. It isalso important to support the use of astandard terminology so that ideas andresults can be more easily communi-cated. The timing of standardization isimportant. If done too early, it can in-hibit innovation and creativity andlimit advancement to evolutionaryrather than revolutionary steps.

Standardization of software engi-neering methods results in providingsoftware enginers with a model for thestate of the practice. It is recom-

mended that they be collected in a

single book. Standards may assist informing the basis for certifying prac-

ticing professionals with respect to theknowledge of methodology and tools.There is a need to make software

engineering a formalized discipline and

establish guidelines for a softwareengineering curriculum. In many sen-

ses, this curriculum would be similar tothat of a professional school cur-

riculum such as those of medicine, law,or branches of engineering. It might in-corporate the internship concept usedfor medical students. Currently, eacheducational institution develops its owncurriculum according to its own needs.In the long run, we expect softwareengineering curricula to be relativelystandardized across the country, withthe possibility of accreditation. Profes-sional societies can lead in this process.

Continuing education for managersand practitioners must also be ad-dressed to assure maintenance of thestate of the practice.The drain of university professors

into industry is a very serious impedi-ment to present and future technologycreation and transfer. Industry musthelp with this issue: it is part of theproblem, it has the resources to help,and its long-term interests dependheavily on the health of the univer-

sities. University professors are in ef-fect "external capital," even thoughthey do not show up on corporate bal-ance sheets. Professional societiesshould focus attention on this problemby discussing it in their conferencesand publications.

Because of the explosive growth ofthe literature and the time and ex-

pertise necessary to assimilate it, con-

ferences, workshops, and tutorials willcontinue to be an important means oftransferring technology. However, we

are faced with problems in these areas.It is difficult to simultaneously main-tain high quality and orginality and yetreach practitioners in various geo-graphical areas. It is recommendedthat "best paper" conferences beorganized at which several researchersrepeat, in cities where conferences are

rarely held, the presentation of papersgiven at other conferences. Finally,professional societies must help bringtechnology to the practitioner by ex-

panding the number of locations atwhich they sponsor tutorials.

January 1985 61

DOD establishes software engineering instituteIn November 1984, the US Department of Defense announced the

selection of Carnegie Mellon University, Pittsburgh, Pennsylvania, to im-plement and operate the DoD Software Engineering Institute as afederally funded, research and development center to support thedepartment in software engineering technology.

According to the DoD, the mission of the SEI is to accelerate the tran-sition of advanced software technology into practice in areas such as in-telligence, surveillance, command, control, and weapons systems.Government representatives say that the SEI is intended to be a credibleadvocate for new technology, a visible standard of excellence for DoDsoftware engineering practices, and a stimulus and guide to the entiredefense software community. Activities of the SEI will focus onmethods of technology transition and will exclude development of mis-sion software for defense systems. In this area, DoD will continue to relyheavily on the private sector to satisfy its needs.Computer software essential to a mission has been growing rapidly in

size, complexity and cost as defense systems become moresophisticated. A significant amount of new software technology exists,and continues to emerge at a rapid rate from the research and develop-ment community. Very little of this technology, however, is used in prac-tice. The SEI is intended to eliminate this problem, says the DoD.As a federally funded center, the SEI will be free of proprietary, com-

mercial, or profit interests and will have wide access to industry,academic, and government data concerning software technology.Following completion of negotiations with Carnegie Mellon, the SEI willbe established under a five-year contract. The institute plans to employ250 people, mostly scientific and technical personnel.

Clearly, periodicals are excellentmechanisms for transferring informa-tion about technology. We need to en-courage the publication of appliedtechnology (IEEE Software was es-tablished with this precise goal inmind). Recommended actions for ac-complishing this objective include thefollowing.

(1) Establish prizes and awards forthe best papers in applied technologyareas. Awards might also be given forpast contributions.

(2) Encourage management tomotivate people to publish appliedtechnology advances through a pub-licity campaign devoted to empha-sizing the value of publication inenhancing a company's image andstimulating sales.

(3) Provide some mechanism forpublication of papers that are verypractical, although not necessarilyoriginal. Possibilities include a specialperiodical or special issues or sectionsof existing periodicals.

(4) Supply technical editors to assistwith writing for those people who needit, or provide detailed guidelines sothat they will know how to writepapers.

Professionalism. It was previouslynoted that permanent improvement inthe state of the practice requires an in-stitutionalization of good practice inthe fabric of industry. Good practicetends to coexist with, and depend on, ahigh level of professionalism. Unfor-tunately, software engineering, and in-deed all segments of the computingcommunity, lacks the image of a trueprofession.

Although each of us may strive in-dividually for technical excellence, ob-jectivity in our technical judgments,and ethical conduct in dealing withothers, our field still seems to lacksome of the ingredients of a profes-sion, and our practitioners sometimesdo not exhibit sufficient professional-ism. There is no doubt that compe-tence and behavior are both extremelyimportant in every vocation. But with-out measures or standards for perfor-mance as well as standards of conduct,the image of that vocation as a profes-sion lacks credibility.

Technical societies facilitate the ex-change of technical information and,to an extent, promote technical growthamong their members. While they doadopt "standards" for interfaces andpractices they do not establish stan-dards of competence or standards ofbehavior. They are unable, as tax-exempt organizations, to develop andpromote public policy and/or legisla-tion beneficial to their members andthe public at large.

Doctors, lawyers, architects, engi-neers, accountants, and even real es-tate agents have professional associa-tions which perform the function ofpromoting professionalism in their re-spective fields. Although, to some ex-tent they exist to serve the interests oftheir membership, they also effectivelyserve the public. It is clear that profes-sionalism in these fields is enhanced bytheir existence.

Therefore, in the interest of pro-moting such professionalism in soft-ware engineering, a study should becommissioned to determine how ex-isting societies and organizationsmight be appropriately altered tofulfill such a role for practicing soft-ware engineers. This study shouldconsider adapting, reorganizing, com-bining and rechartering existing orga-nizations as well as establishing a newsociety or association.The important functions of such a

resulting organization will be to:

(1) establish and certify levels of com-petence,

(2) help establish standards for licens-ing (where appropriate),

(3) establish norms for accepted per-formance and good common prac-tices,

(4) promote integrity and ethical be-havior,

(5) help promote beneficial publicpolicy and legislation,

(6) promote technical excellence andprofessional growth among itsmembers, and

(7) serve as a visible public focal pointfor software engineering as a pro-fession and gainful endeavor.

A ttempting to improve a field thatA is as rapidly changing as soft-ware engineering is a formidable chal-lenge. The solution involves academia,industry, government, and the profes-sional societies. The professionalsociety is perhaps unique in its abilityto consider the problems and proposesolutions, relatively unhampered byspecial interests. Some actions havebeen recommended in this article. Wehope that you, the reader, will careful-ly consider the recommendations andinvolve yourself in some of those youfeel you can support. C1

References1. T. A. Dolotta et al, Data Processing in

1980-1985: A Study of PotentialLimitations to Progress, John Wiley &Sons, 1976, Appendix B, pp. 171-179.

2. "The Military Software Market in theUS," Frost & Sullivan, Inc., Volume1, June 1979, p. 3.

John D. Musa is supervisor of computermeasurements, capacity planning andsoftware reliability at AT&T BellLaboratories, Whippany, New Jersey. Hehas held a variety of assignments inprogram design and has managed a numberof different software projects and activities.He has also worked in the areas ofcomputer graphics, computer security,analysis, simulation, systems engineering,and human factors engineering. Hisresearch interests include softwarereliability, software engineering, andsoftware project management, and he haspublished over 35 papers in these and otherfields.Musa is vice-president for publications

and a member of the Governing Board ofthe IEEE Computer Society. He is a mem-ber of the editorial boards of IEEESpectrum, IEEE Proceedings, and IEEESoftware.

Questions about this article may be ad-dressed to the author atAT&T Bell Labora-tories, Whippany Road, Whippany, NJ07981.

IEEE SOFTWARE62