diffusing software-engineering methods - semantic … · the main elements of the framework are...

Diffusing Software-Engineering

Methods

SIWUW A. Raghvan and Donald R. Chmd, Bentley College

T~nolo~transfesl has become a m@or concern in software

engfneering But without a frarmework

iiwdiffbsing technology annmg pmctitionetq the transferpfohiem

cannot be solved.

July 1989

T ethnology transfer has become an important area of concern in software engineering. Yet we do not

have good frameworks for systematically studying the nature of software-technology transfer, nor for developing sound and prescriptive strategies for facilitating successful diffusion.

Softwareengineering technology, as Peter Freeman has defined it,’ consists of any concepts, tools, techniques, methods, and generalized technical structures that software engineers use to create software- intensive systems that meet stated technical, economic, and social objectives. Examples of this technology include mod- ularization techniques, design methodologies, review techniques, programming environments, estimation techniques, and metrics.

Diffusion is the process of transferring technology from those who develop it to those who apply it. Although diffusion is important in all disciplines, it assumes crit-

0740-7459/8910700/00811$01.000 19891EEE

ical importance in applied disciplines such as software engineering where the primary mission is advancing the state of the practice. Therefore, the success of software engineering as a discipline will depend not only our ability as a community to come up with creative and innova- tive methods to address the problems of software development but also on how successfully we diffuse these methods into practice.

From this perspective, the track record of the software-engineering discipline is far from reassuring. Although softwareengineering technology has advanced rapidly, it hasnot significantly affected the state of the practice of software develop ment. It is thus not surprising that technology transfer is increasingly becoming an area of concern in the softwareengineering community.

This increased concern can be seen in IEEE workshops on software-technology transfer, the US Defense Dept.‘s 1984 es

81

tablishment of the Software Engineering Institute, and the establishment of special private consortia like the Microelectron- ics and Computer Technology Corp. and the Software Productivity Consortium with explicit responsibility for transferring software technology to their member institutions and operating units.

Despite the increasing interest and the growing literature on the topic, software- technology transfer remains a poorly un- derstood area of software engineering. There is a tendency on the part of software-engineering innovators to oversim- plify the problems of technology transfer. They often attribute these problems to management pressures that interfere with the USC of software-engineering practices or to general apathy and resistance to change on the part of potential users.

Although these views may be true in specific instances, they usually represent only a small part of the overall problem. A good understanding of the underlying processes and problems is needed to effectively tackle the technology-transfer problem.

How can we as software engineers understand these problems? First, we need to identify a conceptual framework that can provide a systematic understanding of diffusion processes. Second, we need to identify priority areas through which the software-engineering community can affect the successful diffusion of its innovations.

Existing literature. The existing literature on software-technology uansfer fails to address these needs adequately. Much of this literature has a pragmatic orienta- tion in the sense that it outlines strategies to ease the technology-transfer problem, but it provides little help in advancing a systematic framework for studying and understanding the diffusion processes.

For example, Freeman’ has suggested several strategies for software-engineering technology transfer hased on his experience in conducting professional develop ment seminars and establishing softwareengineering guidelines in industrial organizations. He advocates that you

l view technology transfer as a system, l separate the distinct functions of tech-

nology transfer,

82

l differentiate the types of technology and the intended recipients,

l make sure that there are effective feed- hack paths,

l match the technology to the actual needs,

l obtain broad support for the technol-

%Y~ l treat each technology transfer as a

project, l build on existing technology l deal with organizational change ex-

plicitly, l exploit familiarity to overcome fear of

change, and l continually study the process and de-

velop new strategies. But while Freeman’s work provides use-

ful guidelines, it does not offer insight into the underlying diffusion processes.

We as soibvare

engineers need to identify a conceptual

framework for understanding

technolo& diftbion.

Reports by Louis Tornatzky and col- leagues2 and by Walt Scacchi andJames Babcock’ have dealt better with these underlying processes. They review a body of literature relevant to the study of the diffusion of innovations. However, their focus is too broad for software-technology transfer.

Tornatzky and colleagues focused on the larger issues of managing organizational innovations, so the diffusion pre cess received only limited attention and is buried in a mays of other material. It was also not oriented toward software technology.

The Scacchi and Babcock report, on the other hand, was more focused on software-technology transfer. It developed a conceptual framework, called the Soft- ware Innovation Life Cycle, for systematically organizing the available empirical

studies on the design, development, adoption, and implementation of information systems in organizations. How- ever, this framework provided only a limited understanding of the diffusion processes because diffusion is only one of the steps in the life cycle and is not cov- ered in detail. Furthermore, the understanding the paper developed is based solely on the few available studies on user acquisition of information-system products rather than on the adoption of software technology by software developers.

Despite these drawbacks, the two sur- veys do provide a good frame of reference for considering how to diffuse softwareengineering technology. This article builds on their work but takes a narrower focus - the diffusion process-and h-ies to relate it directly to the context of software technology.

Looking at other fields. Although technology transfer and diffusion are rela- tively new areas of study in software engineering, they are not new to other disciplines. Sociologists and management scientists have studied them extensively for several years. Everett Rogers’s frame- work4 for diffusion of innovations domi- nates this literature.

His framework is widely accepted because of its success in predicting and ex- plaining the diffusion process for a wide variety of innovations. These include edu- cational innovations like programmed in- struction and new mathematics that are similar to softwareengineering innovations in that they involve transfer of knowledge and changes in how people think.

We strongly believe that studying and adapting Rogers’s framework to the software-engineering context could signifi- cantlyenhance our overall understanding of the diffusion process and help us develop effective strategies to successfully diffuse software-engineering innovations.

The Ro@mframeworic Rogers’s framework for diffusion of in-

nowtions was originally based on exten- sive study of agricultural innovations. It was later enriched and validated through many empirical studies in other settings. It is a comprehensive framework that can be used descriptively or prescriptively.

IEEE Software

The main elements of the framework are innovation, the communication process, the adoption process, and the social system

Innovation. In the context of diffusion, innovation is an idea, practice, or object that is perceived to be new by the people who are targets for its adoption. Rogers identified five key characteristics of inn@ vations that directly affect an innovation’s rate of diffusion: relative advantage, compatibility, complexity, ability to try it out (called “trialability” in the management literature), and visibility.

Relative advantage measures how much better an innovation is perceived to be compared to the product or the idea it supersedes. If an innovation is perceived to have a high level of relative advantage by the people who will be instrumental in adopting it, the innovation tends to be diffused very rapidly. The degree of relative advantage may be measured in economic terms, but social factors like prestige, con- venience, and satisfaction are often important components.

Compatibility measures how consistent an innovation is perceived to be with the existing values, past experiences, and the needs of the potential adopters. If a new product requires you to significantly change behavior, attitudes, or beliefs, it loses compatibility. Adopting an incompatible innovation may require the adop tion of a new value system.

Complexity measures how difficult an innovation is perceived to be to learn and use. New ideas that are easy to understand will be adopted more rapidly than innovations that require new knowledge and skills.

The ability to try out an innovation measures how well you can learn, understand, and apply an innovation incrementally by working from small problems to large one. If potential adopters can try out an innovation, they will be less uncertain about its usefulness and about its potential for quick adoption.

Visibility measures how visible the results of an innovation are to others. The easier it is for people to see the results of an innovation, the more likely they are to adopt the innovation.

Thus an innovation that fulfills these

July1989

five criteria - one that enjoys relative advantage, that is compatible with the current environment and past experiences, that is easily comprehensible, that may be tried out on small applications, and whose performance is easy to observe and evaluate - has greater potential for rapid and widespread adoption than an innovation that lacks one or more of these properties.

However, the characteristics of an inncl vation are not determined by innovation alone. They also depend on the nature of the potential adopters and their environment. Tornatzky and K. Klein have pre vided a more detailed analysis” of the sub jectivity of innovation characteristics.

Communication process. Diffusion requires a communication process that results in the transmission of information

tfan innovation is perceived to have a hi@

relative advantage 6y the peopie who will be

instrumental in adopting it, the innovation tends to be diffzmed rapidly.

about innovations. Rogers recognized two kinds of transmitted information: hard and soft. Hard information describes the details of the innovation like the concepts it represents, how it works, and how it should be used. Soft information refers to other information about innovation like its costs, ratings of evaluation factors of interest, and analysis of its potential effects and implications. Soft information deals with those aspects that are necessary to make adoption decisions.

The communication process involves innovators, diffusers, potential adopters, and the communication channels that connect them.

There are two types of channels: mass media and interpersonal. Mass-media channels let one person or a few people reach an audience of many. They include media like radio, newspapers, and trade

publications. Interpersonal channels are direct communications between two or more people through face-to-face meet- ings and interactive media like phone calls and electronic conferencing.

Mass-media channels are rapid and eff- cient in creating awareness of innovations, while interpersonal channels are more effective in persuading people to adopt new ideas. Successful diffusion requires a proper balance between the use of mass-media and interpersonal channels. The proper balance depends on the characteristics of the innovation and the social and cultural aspects of the potential adopters.

Another important factor that affects communication is the nature of fit (homophilous or heterophilous) between the participants. Homophily is how similar pairs of people who interact are in certain attributes like beliefs, education, and social status. Heterophily is the lack of such similarity. Communication is usually more effective when the participants are homophilous.

Adoption process. Diffusion usually proceeds through a series of phases. The first stage is creating an innovation. This is followed by the communication stage, where the innovation is communicated to potential adopters. This triggers the adop tion process, which concludes with the adopters rejecting the innovation or accepting and committing to it.

As Figure I shows, you can divide the adoption process into five steps: knowledge, persuasion, decision, implementation, and confirmation. In the knowledge step, the potential adopter obtains information about what the innovation is and how it works. During the persuasion stage, the diffuser tries to influence the potential adopter to accept the innovation. In the decision phase, the adopter seeksvari- ous kinds of evaluation information to reduce his uncertainty about the consequences of adopting the innovation. The decision phase leads to an adoption or re- jection decision. If the adopter decides to accept the innovation, he then imple- ments and tests it in his environment. This leads to the confirmation phase, where the adopter either makes a commitment to the innovation or rejects it.

83

the innovatlon

Collect hard and soft information about

Try a pilot project

On-going review and evaluation t-l

Figure 1. Typical innovation-adoption decision process.

84

Studies4 ha\re shown that the adoption of innovation follows an S curve as shown in Figure 2. This occurs because people differ in their propensity to adopt innovations.

Rogers has grouped adopters into five categories: innovators, early adopters, early majority, late majority, and laggards. These categories also reflect the relative order in which these people will adopt innovations. Therefore, diffusion is necessarily drawn out over time. Furthermore, members of these categories display rec- ognizable social and personality profiles, so you usually can identify early adopters and the early majority in the target audience of adopters. During the early stages of diffusion, it is wise to focus only on these subsets of potential adopters. You can then exploit their adoption experiences to accelerate the rate of adoption by the rest of the target audience.

The number of early adopters is small, so the number of people in adoption start- up is small. In any diffusion process, the start-up is slow, but it then increases until it peaks, and then it diminishes as fewer nonadopters remain.

Marketing research studies’ have tried to identify the characteristics of people in the innovator and early adopter catege ries. The results vary, which suggests that the answer depends on the product group being studied, but the five traits have often emerged:

l Venturesomeness: the willingness and desire to be daring and try out new and different things.

l Social integration: how frequently and extensively you deal with other people at work, in your neighborhood, or in your social life.

l Cosmopolitanism: a point of view that extends beyond your immediate sur- roundings and shows an interest in world affairs, tmvel, and reading.

l Social mobility: your upward move- ment on the social scale.

l Privilege: generally defined as being better off financially than others in your group; this trait tends to reflect attitudes about the use of money as much as about the possession of money.

These five traits characterize the innovator, early adopter, and early user groups. But it is not possible to identify who in the

IEEE Software

innovator group will be the early users. Research has also shown that in the in-

dustrial setting early adopters tend to be the largest firms in the industry (although some studies have suggested the oppo site), early adopters are those firms that stand to make the greatest profit from the innovation, early adopters spend more on R&D, and early adopters have presidents who are younger and better educated.

Social system. The social system is the environment in which diffusion processes take place. Rogers has identified five as pects of the social system that affect the diffusion and adoption process: social structure, social norms, roles of opinion leaders and change agents, how adoption decisions are made, and the consequences of adopting innovations.

The social structure is the arrangement of how members of a social system com- municate. Two types of communication structures exist in any social system: formal and informal. A formal structure is designed to promote goal fulfillment, process control, and predictability. This structure gives regularity and stability to the system and tries to reduce the uncertainty of human behavior within the sys tern. Informal structures include mecha- nisms like friendships, leisure activities, and gossip that are not designed con- sciously or explicitly. They usually come into existence because of the members’ social needs.

The structure of asocial system can facilitate or impede the diffusion of innovations in the system. Furthermore, a person’s propensity to adopt innovations depends not only on his individual characteristics but also on the nature of his social system. For example, normally eager adopters may dampen their enthusiasm in conservative social systems and other- wise reticient adopters may display increased receptivity in liberal settings.

Social norms are established behavior patterns for the members of a social system. They define a range of tolerable behavior and serve as a guide or standard for the members. Rigid social norms can be a serious barrier to diffusion of innovations.

Opinion leaders and change agents are key people in any social system. Opinion leaders are usually technical leaders with

July 1989

16% laggards

34% late majority

34% early majority

/ 2.5% innovators

time

Rgure 2. The innovation-adoption curve.

proven track records who enjoy a very high level of credibility. They are thus often able to greatly influence the attitudes and behavior of other people. Change agents are people who are for- mally authorized and empowered to change parts of the social system. Unlike opinion leaders, they may not be technical leaders. They derive their strengths from their privileged formal positions in the social system rather than from their technical knowledge and past performance.

Opinion leaders and change agents play critical roles during diffusion. Their attitudes toward an innovation largely determine the outcome of the diffusion pro cess. If they favor the innovation, they may serve as effective catalysts for rapid diffusion and adoption. However, if they criti- cize the innovation, they can impede its diffusion.

The decision to adopt an innovation may take place at the individual, group, or authority levels. The social system itself may or may not influence the level at which the adoption decisions are made.

Individual-level adoption decisions are

called optional-adoption decisions. Here, a person adopts or rejects an innovation independently of the decisions of the so cial system’s other members. However, the person’s decision may be influenced by the social norms or by the members of his interpersonal network.

Collective-adoption decisions are choices that are made by consensus among the system’s members. These are very efficient from the viewpoint of diffusion because the majority of the social system has agreed to adopt the innovation voluntarily.

Authority-adoption decisions are usually made by a few key people who possess power, status, or technical knowledge. Once they make the decision, it becomes binding on the rest of the system’s members.

The level at which adoption decisions are made has many implications for the diffusion process. The collective-adop tion processes may take longer than the individual-adoption process to make the initial adoption decision, but once the decision has been made the innovation dif- fuses rapidly because the decision is based

85

on a conscnsux. Authority-level decisions mayor may not difhsc rapidl\; dependi~~g

on the attitude ofthc members towardau- thorit\. If the members submit to author- it); the rate of adoption is accelerated, hut if they resist authority, they may under- mine the innovation’s adoption.

Because an innovation is necessarily a new idea, practice, or object, its adoption

implies some changes to current methods and practices. Therefore, adopting an innovation amounts to accepting some changes. These changes can interact with the social system in complex ways and pr* duct various kinds of consequences. You can classify these consequences under one or more of the following categories:

l desirable or tmdesirahle, l direct or indirect, and l anticipated or urnanticipated. Social systems will generally accept and

commit to innovations that produce direct, desired, and anticipated consequences. If an innovation has many unde- sired consequences, it will be rejected by the social system even if it is accepted ini- tially. However, the consequences of adopting an innovation are not the Same for the social system’s various constituen- cies. N%at may be a desired innovation to some members may not be desired by the other members, leading to ronflicrs. In such cases, the final outcome will depend on how the conflicts. get resolved-a complex sociological process in itself.

Key issues. Rogers’s framework has nine key points

l Diffusion is a process by which an innovation is communicated through certain channels, over time, and among the members of a social system.

l The perceived attributes of an innovation have strong implications for the success or failure of its diffusion.

l Diffusion is accompanied by change, so effectively managing change is critical for successful diffusion.

l Diffusion occurs in a social context, so factors like social structure, culture, and norms can facilitate or impede diffusion.

l Diffusion requires effective communication, so the selection of communication channels and the match between the participants are important factors in promot- ing diffusion.

l Inno\ation-adoptiorl decisions are ill- flucnced by both rational and irrational I-dctors.

l People differ in their propensity to adopt innovations. Based on this propen- sit); you can group people into categories like early miljorit); late majority, and Iag- gards. These categoriesalso reflect the relative order in which these people will adopt innovations.

l Difftlsion is necessarily drawn out over time.

l Innovation-adoption decision processes may he carried out individually, col- lectively, or by authorities. The level at which the adoption decisions are made have significant implications for diffn- sion

l Change agents and opinion leaders

nle consequences of adopting an innovation are not the same for all constituencjes. What

may be a desired innovation to some may not be desired by others.

act as catalysts during diffusion. Their attitudes toward the innovation can largely determine the success or failure of the diffusion.

Softwareengineering diffusion

There are two ways that you can use Rogers’s framework in the context of software-engineering diffusion: as a descrip tive model or as a prescriptive model.

Descriptive model. Because Rogers’s framework is a model that is well tested on a wide variety of innovations, you can use it as a theoretical foundation for conducting empirical studies to enhance the understanding of softwareengineering diffusion. Some studies have already used aspects of Rogers’s framework to study the diffusion of software products in public

agencies’ and of office-automation products in large corporations.x Because many

empirical studies have been done using Rogers’s framework in other fields, new studies in the softwareengineering arena can draw on their methodologies and analysis techniques.

Conducting these empirical studies can provide answers to some important questions: Are software-engineering innovations diffusing as f’dst as they can? If not, what are the key problems that are slowing their diffusion? How do we evaluate the importance of. these factors in the software-engineering context?

Prescriptive model. Rogers’s framework readily provides the following general guidelines for facilitating diffusion of innovations:

l Ensure that innovations rate well on five key characteristics: relative advantage, complexity, compatibility, ability to he tried out, and visibility.

l Generate adequate hard and soft information about the innovation.

l Develop strategies for overcoming the problems of incompatibility and smooth- ing the transition.

l Select an appropriate communications strategy.

l Develop diffusers. l Pay attention to communication as-

pects. l Recognize the differences in propen-

sityfor adopting innovations and develop a plan of attack that takes into account the S-curve phenomenon.

l Understand the social structure and norms of the potential adopters.

l Understand and develop strategies to deal with the potential interactions of the innovation with the social system.

9 Develop change agents. l Manage change. l Work through opinion leaders. l Seek collective acceptance of the

adoption decision. l Ensure commitment to the use of in-

novation. l Develop methods to establish the con-

sequences of adopting innovations. By refining these guidelines in the con-

text of software engineering, you can develop more concrete action agendas. Doing this requires understanding and

IEEE Software

sensitivity to four issues: l Translating the constructs provided by

Rogers’s framework into software-en@ neering terms.

l The skills and expertise of the software-engineering community.

l Knowledge and level of understanding about the diffusion of software-engineering innovations.

l Pragmatic issues like what can be con- trolled and what factors can provide lever- age in diffusion.

As Rogers’s framework points out, successful diffusion requires that you estab lish successful interaction between the four main elements of diffusion: innovation, communication, adoption, and the social system. The key question is what kinds of skills, knowledge, and expertise are needed to affect the various aspects of the complex interaction underlying diffusion.

Troublesome areas. Proper packaging of an innovation is critical for its adoption. (“Packaging” usually refers to things like training materials, computer-based sup port tools, and empirical evidence for the performance of an innovation in realistic applications.) Because of their critical importance, the creation of such support materials is an integral part of the innovation process. Therefore, it becomes an added responsibility for innovators. In the software-engineering context, this responsibility must be borne by software engineers.

Because software-engineering innovations - especially methodologies and techniques -are abstract, they are prone to misunderstanding and misapplication. Thus an innovation that is accepted ini- tially may be rejected later because of its apparent failure to produce results. You can avoid these problems only by precisely articulating what these innovations represent, what their intended objectives are, and how to apply them effectively. You must also ensure that potential adopters have correct expectations about the innovations. These issues underscore the importance of communication processes in the softwareengineering context and the need for active involvement of innomtors and researchers in the communication.

The area that is potentially most trou-

July1989

blesome for the software-engineering community is dealing with the social syg tern. Social systems tend to be complex and difficult to control and change. The body of knowledge needed to manage these lies in management studies and must be adapted to the software-engineering context. This knowledge is essentially nonexistent in the softwareengineering literature.

To add to the problem, softwareengineering professionals as a rule receive very little training in management, so the profession must rely on practicing software engineers who have accumulated managerial skills through years of practi- cal experience.

Because the adoption process is greatly influenced by the social system, affecting it becomes difficult. However, you can partially compensate for this by providing

SotWare eiqgfm3ecs as a rule recehe very little

managemenf trainin& so the profbsion must rely

onthosewhohave accumulated managerial skills tilrollgll jY#actica/

expeffence.

adequate hard and soft information about innovation. Adequate hard information is usually available for software innovations, but not soft information like cost-benefit analysis, hidden-costs analysis, effect analysis, risk analysis, scaling-up problems, and available strategies. Get- ting this information should have a high priority in the softwareengineering community.

It is quite possible that managing the sc+ cial system will turn out to be the major determinant of successful diffusion. How- ever, it can become significant only if the innovations are basically sound and if they are objectively and effectively communicated to the potential adopters.

What must be done. We have developed

the following action items that the software-engineering community should un- dertake immediately to address the needs of software-technology diffusion:

l The diffusion literature, which exists in the management discipline, must be studied and adapted to software engineering.

l The softwareengineering community should become more involved in objectively communicating its innovations to practitioners. Software engineers should play active roles as diffusers and opinion leaders and widen the scope of their research and publication activities.

l Software-engineering students can play an effective role as diffusers. They should learn how to manage change, become effective communicators, and learn to deal with incorrect perceptions. They should be taught measurement techniques with which they can evaluate the performance of tools they diffuse into their parent organizations. They should be provided comprehensive information about available empirical results.

l Software-engineering education should address techniques for justifying and diffusing softwareengineering technology, not just teach tools, techniques, and methodologies.

casestudy Programdesign methodologies have

been an active area of research in software engineering for 15 years. Many methodologies have been developed to facilitate the development of quality programs. The same period has seen rapid growth in a satellite industry that offers professional- development seminars, in-house training programs, consulting services, and sup port-tool development for these methodologies.

Despite the elaborate efforts of the satellite industry and the strong commitment and enthusiasm of the softwareengineering community, the adoption of the well- known methodologies - structured pre gramming a la Edsger Dijkstra and Niklaus Wirth, Terry Baker and Harlan Mills’s integrated top-down design method, stepwise refinement using ab stract data types based on Barbara Liskov’s ideas, Jeane Warnier’s approach to logical program construction, Michael Jackson’s

87

l They prov ide a systemat ic a n d un i fo rm way of

Innovators’ a n d di f fusers’ v iew of

at tacking p r o g r a m m i n g prob lems. *They p rov ide f rameworks for check ing the

methodo log ies

in ternal consis tenc ies of p r o g r a m designs. *They p romote s tandard izat ion of both the

p r o g r a m deve lopment p rocesses a n d p r o g r a m products.

l They facil i tate a luc id a n d prec ise documenta t ion of the thought p rocesses under ly ing a p r o g r a m des ign.

l They prov ide a c o m m o n f ramework that p romotes effective commun ica t ions a m o n g the m e m b e r s of a p r o g r a m m i n g team.

l They he lp deve lop correct a n d re l iab le p rograms.

*They he lp deve lop unders tandab le p rograms. *They he lp deve lop modi f iab le p rograms. *They ex tend the reper to i re of p r o g r a m m i n g

techniques. *They he lp inc rease overa l l p r o g r a m m e r

product ivi ty. *They he lp identi fy au tomat ion oppor tuni t ies

for p r o g r a m deve lopment .

(a)

l Methodo log ies a re comple te in the sense that

H o w methodo log ies a re commun ica ted to

fo l lowing the prescr ibed steps wi l l p roduce a g o o d p r o g r a m des ign.

l Methodo log ies a re genera l in the sense that

pract i t ioners

they a re app l icab le to b road c lasses of p rob lems.

l Methodo log ies a re i l lustrated th rough smal l p rob lems.

l Log ica l a rguments a re used to establ ish a n d justify the soundness of these methodo log ies .

l Log ica l reason ing is used to establ ish the mer i ts of these methodo log ies .

l Methodo log ies m a y not b e usefu l w h e n app l ied to sma l l p rob lems because of their overheads, but they wi l l def ini tely pay off for la rge prob lems. Log ic a n d rhetor ic is used to commun ica te this message .

l Methodo log ies can b e easi ly l ea rned a n d used by any p rog rammer .

l Methodo log ies increase p rog ram-deve lopmen t product ivi ty.

l Methodo log ies enhance the visibi l i ty of p rog ram-deve lopmen t activit ies.

*The constraints imposed bythe methodo log ies p roduce va luab le benefi ts.

W

H o w methodo log ies a re perce ived by pract i t ioners l Methodo log ies a re not complete . They n e e d

creat ive adaptat ions wh i le app ly ing them. *They have la rge overheads, wh ich tend to

inc rease rap id ly as p r o g r a m s ize increases. *They cannot b e easi ly app l ied to la rge

prob lems. *They requ i re m u c h per iphera l work that m a y

or m a y not b e usefu l in the long run. *They genera l l y s low d o w n the p rog rammers . *They a re not robust a n d can b e easi ly

misapp l ied . l It is very diff icult to de te rmine their

appl icabi l i ty to a g iven p rob lem. l They a re too genera l a n d d o not p rov ide c lear

gu idancefor the i r p roper appl icat ion. l N o in format ion is ava i lab le about the r isks

invo lved in adopt ing these methodo log ies . *They constra in the p rog rammer to app ly

s o m e form of top-down des ign approach. *They d o not ind icate h o w the methodo logy

can b e comb ined with o ther methods. *They must b e app l ied in their ent irety to

der ive benefi ts. l They take away the cha l lenge a n d en joyment

of p r o g r a m des ign. l There is a lack of exper imenta l resul ts that

conc lus ive ly p rove that these methodo log ies work in pract ice.

*The learn ing acqu i red by app ly ing these methodo log ies o n smal l p rob lems does not p repa re a p r o g r a m m e r to attack la rge p rob lems with these methodo log ies .

l It is diff icult to establ ish that the success of a des ign is d u e to the methodo logy a n d not to the ingenui ty of the des igner .

(c)

F igure 3. (a) H o w p rog ramdes ign methodo log ies a re perce ived by the the pract i t ioners, and(c ) h o w they a re perce ived by the pract i t ioners.

innovators a n d dif fusers, W h o w they a re commun ica ted to

des ign method, a n d structured des ign methodo logy 5 la Lar ry Constant ine a n d E d Y o u r d o n - is s low a n d far be low the des i red levels. Th is can b e part ia l ly ex- p la ined us ing Rogers’s f ramework.

(The quest ion ofwhat const i tutes asat is factory di f fusion rate for sof tware-engi - neer ing techno logy is a controvers ia l issue. S a m Redw ine a n d Wi l l i am R idd le9 have conc luded that it takes 1 5 to 2 0 years for a techno logy to matu re to whe re it can b e popu la r i zed a n d d issemina ted to the technical commun i t y at large. They b & d their conc lus ion o n a n analys is of severa l sof tware- technology case studies. Bu t this

cannot b e used to justify the current soft- wareeng ineer ing diff icult ies because it is a c i rcu lar a rgument : It takes 1 5 to 2 0 years because it has taken 1 5 to 2 0 years. A n - o ther study by R.R. Wi l l is’o conc luded that techno logy transfer takes f rom four to e ight years in most cases.)

W e conduc ted a n in formal case study based o n h o w p rog ram-des ign methodo l - og ies a re perce ived by the innovators, h o w they a re commun ica ted to the pract i t ioners, a n d h o w they a re perce ived by the pract i t ioners. F igure 3 l ists these pe rcep t ions. The descr ip t ions a re based o n ou r extens ive persona l invo lvement with p ro-

g ram-des ign methodo log ies a n d o n the case studies a n d user exper iences de - scr ibed in the l i terature. A l though the data m a y b e informal , it does represent reali ty.

Pract i t ioners’ prob lems. The data shows that pract i t ioners perce ive severa l p rob lems with the p rog ramdes ign methodo log ies . These p rob lems can b e systemat ical ly g rouped by the f ive key innovat ion character ist ics: re lat ive advantage, complexity, compat ibi l i ty, abi l i ty to b e tr ied out, a n d visibil i ty.

Pract i t ioners d o not s e e m to perce ive

8 8 IE E E Sof tware

clear advantages in adopting the methodologies because the methodologies require a lot of peripheral work that may or may not pay off in the long run. This peripheral work creates large overheads and slows down programming activities. Fur- thermore, the overheads increase rapidly as problem size increase.

These methodologies are too general and do not provide clear guidance for their proper application, making their use complex. Because they are incomplete and need creative adaptation during their application, they can be easily misapplied. It is also very difficult to determine these methodologies’ applicability to a given problem.

Practitioners also perceive problems with compatibility. Because methodole gies require a different and systematic way of thinking about design problems, they usually constrain programmers to apply some form of top-down design approach; they are generally incompatible with the informal design processes that are already in use. Furthermore, the methodologies do not provide much guidance about eas- ing the transition problems or about how they may be combined with other methods during transition periods. Last, but not least, there is also a strong perception that these methodologies take away the creative challenge associated with pre gram design.

These methodologies also Seem to be difficult to try out because you must apply them in their entirety to derive any benefits. The learning you acquire by applying these methodologies on small problems does not prepare you to attack large prob lems. They do not scale up well.

Last, the methodologies are also perceived to have poor visibility because it is very difficult to observe or ensure that a chosen methodology is being followed properly. It is usually not clear whether the success of a design is due to the metb- odology or to the designer’s ingenuity. It is also difficult to establish the benefits ac- crued by using the methodologies, which is further aggravated by the general lack of empirical results that establish their value.

Communication problems. In addition to the problems with the design methodologies’ characteristics, there are

July1989

several problems with the communication of these methodologies. The data in Fig- ure 3b shows the wide gap between the perceptions of innovators and those of practitioners. It means that the methodologies are oversold or poorly communicated -or both.

It is also clear that empirical evidence for the strengths of the methodologies are seldom communicated. Information about the risks associated with the methodologies, as well as other evaluation details that are needed for innovation-adop tion decisions, are either not available or not communicated.

Recommendations. These problems suggest that programdesign methodole gies will be difficult to diffuse and will diffuse very slowly. This conclusion is consistent with the general belief that program-

The widog23pbotwoon theperceptionsof

innovatm and pt!actition~moansthat

oversoldorpoor& communicated-orboth.

design methodologies have not diffused well in practice.

Based on our analysis of programdesign methodologies, we suggest the following actions for the softwareengineering community to take to facilitate these methodologies’ diffusion:

l Improve the methodologies so their advantages clearly outweigh their drawbacks. One approach is to develop computer-based support so developers are free of the mundane overhead activities that slow down the use of these methodologies. CASE tools are now addressing this weakness.

l Extend the methodologies with de main-specific knowledge. This is being ex- plored in knowledge-based CASE tools.

l Develop methods for measuring the

effectiveness of these methodologies. This is a central issue in software productivity.

l Develop techniques by which you can incrementally introduce these methodologies and by which you can seamlessly bridge the incompatibilities among the past, current, and future development practices. These ideas are part of CASE re- verse engineering.

l Characterize the benefits, drawbacks, and risks of using programdesign metb- odologies. For example, it is being recognized that CASE has both serendipitous advantages and unpredictable side effects and risks. Systematic studies are needed to develop a better understanding of the benefit/risk trade+&.

I

dentifying and illustrating Rogers’s framework as an appropriate model of software-technology diffusion is just

the first step in studying the diffusion of softwareengineering technology. Further work is needed to put Rogers’s framework into practice for the diffusion of softwareengineering innovations.

The framework must be empirically validated for softwareengineering diffusion. It must be refined so it can predict softwareengineering diffusion. Taxonomies must be developed to characterize the state of diffusion and the dominant prob lems in diffusion. Last, contingency frameworks are needed to prescribe which actions the diffusing agents should take. 0%

Acknowledgments We are indebted to Roy Schweiker, our grad-

uate research student, who prepared an anno- tated bibliography on technology transfer, fel- low faculty members at the Wang Institute for their insightful comments on an earlier draft of this article, and to the anonymous referees for their suggestions.

ReferWlCW 1. P. Freeman, ‘Sofnvare Engineering: Strate-

gies for Technology Transfer,” Proc. Intl Gvnfmting Symp. ApPli&ias Sys!enu Devel- opment, ACM, Berichte, West Germany, 1983, pp. 333-35 I.

2. L.G.Tornatzkyetal., ‘TheProcessofTech- nological Innovation: Reviewing the Liter- ature,” tech. report, Nat’1 Science Foundation, Washington, D.C., 1983.

89

Software Engineers Ford Aerospace, Western Develop- ment Laboratories Division, located in the beautiful San Francisco Bay Area, is seeking Software Engineers. Join us in transferring our current Signet software program to a new hardware format. You will also work independently analyzing, synthesiz- ing, and communicating software system design and process solu- tions. Responsibilities will include coordinating the technical efforts of subcontractors in a large multi-site software development, integration, and test effort. Requires a BS in Engineering, Math, Physics, or Computer Sci- ence and a minimum of 6 years’ experience. You should also have experience with distributed PDP, VAX-based computers, hardware and software relational DBMS, and SUN/UNIX’” and C language technology. Must also have some expo- sure to mini and micro computer development, as well as firmware development. Knowledge of Army/ Air Force tactical communication systems a plus. TCAC experience desired. We offer an excellent benefits package including a relocation package and a stable work environment. For immediate consideration, please send your resume to: Betsy Smith, Ford Aerospace, Western Develop- ment Laboratories Division, Dept. BS-IEEESW, 220 Henry Ford II Drive, P.O. Box 49041, San Jose, CA 95161-9041. An equal opportu- nity employer. Principals only, please. Candidates must be able to work on all classes of govern- ment material. UNIX IS a registered trademark of AT&T.

Ford Aerospace

Command 8 Control Group

7. ,J, Prrry and K Krxmer, “Irmovation Attributes, Policy Intcrvcntion, and the Diftilsion of Compurcr Applications among L.ocal Govern- nwnt~,” I’dicy Stimm, April lY78, pp. 179.205.

8. T.K. 13ibon, “Understanding the Inrplcmcntation ofOfIicrTechnol- o~~,“Tech. Note N-2619.NSF, Rand Corp., Sanra Monira,Junr 1987.

9. ST. Redwine and W.E. Kiddlc, “Software Tcrhnolo~~ Matul-ation,” 13-w. 1:ighth Int ‘l (i)n[ &Jhuarr /<rug., (Zi Press, l,os Alamitos, (:alif., 19x5, pp. 189-2(X).

IO. R.R. U’illis, “Trchnolog?; Transfrr Takrs Six Plus One to Two Years,” I’m. Work\h@ So/twcmk;ng khnoiogy knslpr, (:S Press, Los Al- amitos, (Xf., 1983, J-'Jl 10X-l 17.

Donald R. Chand is the chairman of the (brnprttcr Infbrmation Systc-ms Dept. at Bentley College. Beforejoining Bentley in 1984, he taught for I5 years at Georgia State University and was chairman of the Information Systems Dept. His research and teaching interests include design methodologies, fou~th~e~~eratioll languages, and applic-ations-d~veloprnent tcthnologics.

Chand rcccived a PhL) in rrrathrnratics from Boston University. He is an A(:M Ircturrr, associate editor of the Journal o/In/mtion Kp.wurc~.~ Mnnqmmt S+rru, and memhcr of the,~our~l o~Mzrrocomp*tpr Systmm Mana~qnnmt editorial hoard. Hc is a member of IEEE.

Sridhar A. Raghavan is an assistant profrssor at the (Computer Informa- tion Systems Dept. at Bentley (bllege. Before,joining Bentley, he was an assistant professor of software engineering at the Wang Institute. His research interests include the use of artificial-intelligence and expert-systems technology for software engineering and decision making.

ktghavdn received a PhD in computer information systems from (;rorgia State University. He is on the editorial board of the,/ouncll of Infmation Hprrrurc~s Manapnmt Syslpmr. He is a member ofACM, IEEE, the American Association for Artificial Intelligence and the Institute of Management Science.

Address questions about this article to the authors at CIS Dept., Bent- ley College, Waltham, MA 02254.

IEEE Software

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

diffusing software-engineering methods - semantic … · the main elements of the framework are...

Documents