functional paleontology: the evolution of user...

Functional Paleontology:The Evolution of User-Visible System Services

Annie I. Anton, Member, IEEE, and Colin Potts, Member, IEEE

Abstract—It has long been accepted that requirements analysis should precede architectural design and implementation, but in

software evolution and reverse engineering this concern with black-box analysis of function has necessarily been de-emphasized in

favor of code-based analysis and designer-oriented interpretation. In this paper, we redress this balance by describing “functional

paleontology,” an approach to analyzing the evolution of user-visible features or services independent of architecture and design

intent. We classify the benefits and burdens of interpersonal communication services into core and peripheral categories and

investigate the telephony services available to domestic subscribers over a 50-year period. We report that services were introduced in

discrete bursts, each of which emphasized different benefits and burdens. We discuss the general patterns of functional evolution that

this “fossil record” illustrates and conclude by discussing their implications for forward engineering of software products.

Index Terms—Measurement, metrics, empirical methods, reverse engineering, requirements engineering, software evolution.

æ

1 PALEONTOLOGY OF SOFTWARE FUNCTION

SERVICES are generally collections of functions that arerelated to a delineated purpose or mode of use.

Examples include call forwarding in telephone switchingand spell checking in word processing. Functional evolu-tion is the phenomenon by which a system’s serviceschange over time. However, we are unaware of any detailedstudies of the functional evolution of software. Historians ofengineering have investigated the evolution of structureand function in physical artifacts as diverse as the paperclip[24], jet engine [4], and buildings [6]. Lehman and Belady[20] studied the evolution of OS 360 over many releases,addressing the evolution of its structure (size and numberof modules and the concomitant development effort), andthey distinguish between various kinds of enhancement.However, they do not report in detail on the kinds ofservices introduced over time.

The systems that Lehman calls E-type systems co-evolvefunctionally in conjunction with their environments [20],[21]. Requirements volatility (customer-desired, short-termfunctional change) has been identified as a principalobstacle to software development [8]. Given how muchmore pervasive and important change processes are insoftware development than in other engineering fields, itwould be valuable to know what kinds of functionalchanges occur as systems evolve. Only when these havebeen identified or predicted can architectural principlessuch as information hiding, component-based design [1],and design patterns [11] be applied to the implementationarchitecture to make it more adaptable.

Investigations of service evolution are sorely needed.

Software development practice is moving toward a pro-

duct-line perspective [10], in which software systems are

configurations of desired services or features. To exercise

better control over service evolution and prioritization of

important services as contrasted with gold plating, software

engineers and product managers could benefit from an

understanding how the services of large systems tend to

evolve and what structural limits and patterns may

constrain such changes. Such investigations, while driven

ultimately by practical concerns about controlling and

shaping the repertoire of services that constitute a packaged

system, have many of the hallmarks of science or natural

history, rather than engineering research (see Table 1).We believe it is worth investigating whether systems

evolve functionally in nonrandom and partly predictable

ways. Such investigations require the development of a

conceptual base, or theory of function and evolution, and an

empirical base or fossil record (a chronology of service

evolution for a single system). The work we describe in this

paper is an initial investigation into the definition of system

function and value by analyzing the growth and evolution

of services. Our aim is to provide a vocabulary for

delineating, classifying, and comparing the value of services

as they evolve to more rationally anticipate and plan for

future system evolution. Previous studies of software

evolution have encompassed all aspects of the software

concerned, such as its development process and its

implemented form, as well as its functionality. By restrict-

ing the study to just the functionality delivered, the

approach is both more tractable and more likely to yield

conclusions that apply to other systems.We can put the current research in perspective by

referring to Shaw’s classification scheme for software

engineering research [28]. She identifies five kinds of

research:

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003 151

. A.I. Anton is with the Computer Science Department, North CarolinaState University, Raleigh, NC 27695-8207.E-mail: [email protected].

. C. Potts is with the College of Computing, Georgia Institute of Technology,Atlanta, GA 30332-0280. E-mail: [email protected].

Manuscript received Feb. 2002; revised July 2002; accepted Sept. 2002.Recommended for acceptance by M.J. Harrold.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number 117522.

0098-5589/03/$17.00 ß 2003 IEEE Published by the IEEE Computer Society

. Feasibility. (Is there an X, and what is it? Is itpossible to accomplish X at all?)

. Characterization. (What are the important charac-teristics of X?... What are the varieties of X, and howare they related?)

. Method/Means. (How can we accomplish X? Howcan I automate doing X?)

. Generalization. (Is X always true of Y? Given X,what will Y be?)

. Selection. (How do I decide between X and Y?)

Although there is not a necessary progression through

this list, research questions tend to require answers to or

assumptions about the questions earlier in the list. For

example, there is no need to question the feasibility of

functional evolution of software since we see software

evolving and growing in functionality all the time.

However, before we can reasonably develop theories ofevolution-promoting development practices, generalizeabout evolution predictions in given cases, or selectbetween alternative development processes, it is clearlybeneficial to characterize evolution according to its basicmodes and drivers. Accordingly, in the research describedin this paper, we set out to characterize the dynamics offunctional evolution in software-intensive systems. Our aimis not to develop an explanatory theory of evolutionarysuccess factors or fitness criteria or to promote technologyor principles that help practitioners predict and guide theprocess of evolution. Such theoretical and practical under-standing must wait until we can characterize evolutionmore effectively.

According to Shaw, characterization research can beconstrued on three levels (see Table 2). The generic level

152 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003

TABLE 1Contrasts between Traditional and Emerging Contexts of Software Evolution

TABLE 2Characterization Research Questions, After Shaw (2001)

provides template questions (experienced researchers donot need these templates to generate questions as much asto reflect on the category of research into which theirresearch questions fall when viewed as instances oftemplates). At the research level, the research questionsare framed in terms of basic categories of interest in thefield. In the case of this research, the categories are featuresor services, software evolution, etc. However, these ques-tions are typically not answerable except by speculation ofdubious value unless they are approached through equiva-lent questions at the case-study level. Thus, to approach thenature of services and evolution, we must investigateexamples, not because the examples are themselves inter-esting (although they may be) but because they areexamples of something more general. The remainder ofthis paper deals exclusively with service evolution indomestic telephony. Of necessity, we provide details aboutthe evolution of telephone features and their relationships.We do so, however, not to elucidate, critique, or recom-mend improvements in telephone systems, but becausedomestic telephony is the best example of service evolutionthat we know of that admits the kind of longitudinal studynecessary.

Section 2 outlines our conceptual base. In the first part,we develop a taxonomy of service benefits and burdens thatderive from an analysis of knowledge and communicationtypes. The profile or “shape” of benefits and burdens at agiven point in a system’s evolution is its functionalmorphology at that time. Section 2.2 addresses the evolutionof functional morphology, introducing the concepts ofepochs, expansions, and cohorts, and discusses to whatextent these concepts are dependent on or autonomous ofimplementation and environmental driving forces. Section 3describes a functional fossil record, the evolving functionalmorphology of domestic subscriber telephone services in aUnited States major metropolitan city over a 50 year period.We present a summary of the major changes and then digdeeper, applying the functional morphology to reveal theunderlying pattern. Finally, in Section 4, we discuss to whatextent the introductory conceptual base and limited fossilrecord can be used to predict patterns of functionalevolution or future requirements volatility in communica-tions-support software specifically, and software engineer-ing more generally. We close by relating our analysis ofservices to abstractions such as use cases and functionpoints, and other ongoing and planned investigations intofunctional morphology and evolution.

2 CONCEPTUAL BASE: FUNCTIONAL MORPHOLOGY

AND EVOLUTION

Before discussing our functional fossil record, we mustintroduce two sets of concepts. These describe 1) the fossilsor functional morphology of systems at any given time and2) patterns of change in morphology over time or functionalevolution. Although this section is a necessary preamble tothe discussion of the actual fossil record in question, toprovide a more convincing motivation and to avoid thediscussion being too dry or appearing too gratuitously toadopt biological metaphors, we anticipate the discussion of

the telephony fossil record by introducing illustrations fromit. The reader should realize, however, that these are merelyillustrative at this stage and do not carry the weight of ourargument.

2.1 Functional Morphology

By functional morphology, we mean the overall profile orshape of benefits and burdens exhibited by a system at apoint during its evolution, where by benefits we mean typesof system-use outcomes that meet a beneficiary’s interestsor goals, and by burdens we mean outcomes that under-mine these benefits. Benefits and burdens are discussed inmore detail below in Sections 2 and 3, respectively. Benefitsand burdens are determined by the services that the systemprovides.

We expect a system’s repertoire of services to grow as thesystem evolves, although it is conceivable that a systembecomes functionally simpler over time. Thus, the overallcount or magnitude of benefits and burdens that a system’sservices manifest is an interesting property of that system atany point of its evolution. But a service is more than a set ofuniform benefits and burdens ripe for counting.

In addition to magnitude, a system has a functional formor morphology. Not only the size of the system measured inservices or benefits can be expected to change, but also itsprofile of benefits and burdens is likely to change as thesystem becomes more complex and entrenched in its ownhistory. For example, at one time, the telephone systemprovided services that primarily aided users in commu-nication. Subsequent developments have not changed theprimary purpose of the telephone system as a means ofcommunication, but more recently introduced services domore than merely augment the communication benefitsafforded by basic telephony services. As we shall describein detail later, some services, for example, let subscribersreduce their availability or even prevent unwanted com-munication in some circumstances.

In a sense, therefore, the benefits of later services mayaccrue in part from impeding or reducing the very benefitthat the system was intended to achieve. Viewed as a resultof a rational goal-refinement process, the requirements for asystem that contains both communication-enhancing bene-fits and communication-impeding benefits are paradoxical.Viewed, however, as a quasi-natural phenomenon evolvingunder its own steam, so to speak, a system should beexpected to develop such internal “arms races” of mutuallyantagonistic services as it becomes more complex anddiverse. Such behavioral complexities abound in biologicalsystems, for example, in the context of internal defense.

2.1.1 Services

Services, broadly speaking, are the features of a system thatenable users to do useful things. Being more precise aboutservices involves answering two questions:

. What delineates or individuates services? Forexample, is call-forwarding a telephone service? Oris it a cluster of many services that happen to bebundled together for certain marketing and billingpurposes? Given that there are variants of call-forwarding (e.g., forwarding a call when the line is

ANT �OON AND POTTS: FUNCTIONAL PALEONTOLOGY: THE EVOLUTION OF USER-VISIBLE SYSTEM SERVICES 153

busy as distinct from call forwarding when therecipient does not answer after a predefined inter-val), are these variants of a service or are theydifferent services? Is wireless telephony a service? Isbeing able to stay in touch with one’s friends aservice? What about dialing a telephone number andhaving a connection made: Is that a service?

. In what does a service’s usefulness consist? Inparticular, are we forced into admitting as a serviceanything for which a customer is willing to pay? Orare services, like some uses of the related termfeatures, optional additions to a system’s functions?If optional, this suggests that what may start out as aservice early in a system’s lifecycle may cease to be aservice after several releases once it is no longer anoption. Spell checking is an example of a once-optional word-processing service that now comesbundled automatically (at least for most commercialword processors), but it seems inappropriate toregard it as no longer a service just because it is nolonger optional. Or are the services of a systemindicative of its performance in different needs of itsusers? That is, are services such items as the abilityto help the writer polish a document, or the ability tostay in touch with your friends and relatives? Such acharacterization of services would rely on actualdata obtained from specific user groups using thesystem in their performance of specific activities. Wecould not characterize services independently of thepopulations of users making use of the services andsituations in which they were used. While a fulldescription of how services actually fulfill theiruser’s needs must take such contextual factors intoaccount, it seems circular to appeal to them whendefining what it is that makes the service useful.

In answer to the first question, our definition of a servicedelineates functionally useful and self-contained interactionpatterns between a system and its environment (here users).“Self-contained” here may imply ease of concise descrip-tion, logical delineation as an option or billable entity, butdoes not require that the service exist as a separate unit ofthe implementation architecture. Given that the services areintended to be beneficial, it is the assumed beneficiary (herefor the user or telephone subscriber, not the developer ortelephone company) whose viewpoint is crucial in deter-mining self-containedness. Thus, call-forwarding is indeeda service, and its several variants are distinct servicesthemselves. Wireless telephony, however, is not a servicebecause it is a set of loosely connected characteristicsassociated with equipment, mobility, and billing servicesthat, in many cases, mimic nonwireless services. We suspectthat the temptation to regard wireless telephony as a featurereflects the implementer’s viewpoint. The ability to stay intouch with friends is only a service in the informal sense.For our purposes, we characterize it as a potential benefit ofseveral services, and one that could only be supported bypointing to specific scenarios of use involving those services(for example, using speed dialing to store the numbers offrequently called friends). Connecting to a recipient of acall, however, is a service, one so basic to telephony and

absent from explicit mention in many telephone user guidesthat it is easy to overlook.

Our answer to the second question is that services endowcustomers with the potential to achieve goals that customerscould not achieve or could achieve less adequately in theservices’ absence. For example, Caller ID lets telephonesubscribers identify callers without answering. A service isappropriate if it supports a stakeholder’s goals. Servicesthat fail to support goals or that support minor goals at acost that is too great to justify are often criticized aspointless, decorative, or gold plating (that is, including afeature “just in case” even though it may not be needed).

Previous research in requirements engineering hasdeveloped a rich theory of goals and their refinement intosystem constraints and operations [2], [3], [19], the obstaclesthat may block goals in the deployed system’s environment,and the secondary defensive and mitigation goals that ariseto make the system more robust in the presence of suchobstacles [19], [25]. We adopt this perspective in thefollowing analysis of service evolution without furtherelaboration.

An important difference between the use of goals to

support requirements engineering, the investigation of

goals as the rationale for services, and their evolution in

deployed systems is that, in requirements engineering, the

benefits of a service can be assumed to be delivered by the

intended system to the expected user in an expected use

situation. In a deployed system, however, we must

distinguish the potential to satisfy goals from their actual

satisfaction. A service provides a customer with the

potential to achieve goals. How much benefit customers

realize when using a deployed system depends on many

factors that are not under the control of the writer of a

requirements specification. The major impediments to

benefiting from service potential are the burdens that the

service imposes on its users either as an intrinsic side effect

or as a result of implementation decisions. For example, a

service may be feasible only if its users possess certain

capabilities that are not needed otherwise. For example,

Caller ID is meaningless in the context of a subscriber

telephone that is not Caller ID-enabled. A subscriber may

subscribe to the service but simply be unable to reap any

benefit at all. At the very least, the telephone should have a

display capable of showing the caller’s number. In addition

to the need for extra resources, services may involve other

forms of burden, such as the effort required for extra setup

activities, cognitive burdens such as greater demands on

memory and attention, or physical or situational burdens

such as constraints on the customer’s mobility or location.This distinction between potential and realized benefits

is similar to the distinction drawn in formal linguisticsbetween language competence or langue, the underlyingdefinition of the grammar of a language that is assumed tobe known tacitly by a fluent speaker, and languageperformance or parole, which is affected by cognitive andarticulation limitations, social context, and many othersituational factors [7], [27]. As a result, many fluentspeakers speak ungrammatically but intelligibly, employexpressions and words in creative and nonsanctioned ways


according to the standard language documented in text-books. Correspondingly, the formal linguist interested inthe structure and grammar of a language investigates theboundaries of grammaticality using constructed examplesand fluent speakers’ intuitions about what utterances aregrammatical and what are not. In contrast, the sociolinguiststudies “talk,” the actual occurrence of speech in socialsituations. In the case of language, it is the human, thespeaker of language who has linguistic competence andwhose competence is modified in practice as actualperformance. In the case of system services, it is the system(or the constituent service) that exhibits a competence tosatisfy user goals (and not a competence of the human userto use the system “correctly”), and it is the system thatexhibits this competence in performance by satisfying user’sgoals to some extent in specific use situations (and, again,not the user’s performance in using the system).

We stress this distinction between competence andperformance views of services and its analogy withlinguistic usage because we see this research investigationprimarily as akin to formal linguistics. Just as linguisticsstudies language, not speech, so our object of study is theform of system services over time rather than which onesare the most used, which are the easiest to implement, thecheapest to acquire, or the most politically problematic in aregulatory environment. A full description of any system’shistory, assuming that such completeness is useful andinteresting, would have to take into account usage patternsand contextual factors outside the system itself, just as thesociolinguist looks beyond the potential for utterances thata grammar affords to actual utterances observed whenpeople communicate. But, such an investigation rests on anunderlying competence that had best be explicit and wellfounded. We can only ask which services are most used,most usable, etc., if we have some independent means ofdelineating them and characterizing them.

2.1.2 Benefits

Benefits are outcomes that meet a beneficiary’s interests orgoals. We can classify them on two levels, following Shaw’sanalysis [28], to which we referred in Section 1: the researchlevel and the case level. We defer case-level (i.e., telephony-specific) classification of benefits to the next section, inwhich we discuss the telephony fossil record in detail. Atthe research level, however, there are useful distinctions tomake between different forms of benefit that are indepen-dent of the domain of application in any case study. Weclassify services at this level on three dimensions: 1) abenefit may be a core benefit itself or may modulate aservice that provides a core benefit, 2) a benefit may beautonomous in origin or may have as the rationale for itsintroduction the reaction to other services whose burdensundermine its benefits, and 3) a benefit of a service may beabsolute, it may be an amplification of the benefits of someexisting service, or it may qualify in some way the benefitsof another service.

Core and Modulating Services. The most importantdistinction is between core services and second-order ormodulating services. Information systems and communica-tion-support services are designed primarily to create ortransmit knowledge. Thus, the core knowledge benefits ofservices are automated informing, notifying, or the enabling

of communication. Zuboff [32] introduced the term infomat-ing (in contrast to automating) to refer to those services thatbenefit users by creating or transmitting knowledge notabout the application domain but about the system itselfand its operations. Thus, knowing who is calling youwithout answering the telephone is a second-order benefitin which you as subscriber have more knowledge about andcontrol over the state of the system. However, this servicewould be of little use for most users who were unable tospeak to or hear the caller since it is communicationpotential that provides the subscriber with the telephone’score benefit, whereas the infomating benefits mainlyconcern state awareness (such as the identity of the calleror the presence of recorded calls).

Autonomous and Reactive Benefits. The benefits justconsidered are all autonomous in that they are intended asbenefits of the system without consideration of the burdensimposed by them or by other services. Some benefits,however, are reactive. They gain their value from thedisutility or burdens of other services. If a service makes asubscriber too accessible, services that enhance subscriberprivacy become required in reaction. When a serviceimposes action or cognitive burdens, new reactive servicesmay be required, services that let the user organize ormarshal information.

Amplified and Qualified Benefits. A service’s benefitmay be qualified or amplified by an enhancement of theservice or the addition of a new service. Information may becreated or transmitted faster, in richer media, moreaccurately or more broadly. Thus, being able to makeconference calls increases the communication potential ofthe subscriber because it is now possible to communicatewith more than one person simultaneously; the videotelephone lets the subscriber see as well as hear the caller.

2.1.3 Burdens

Services are not necessarily valuable because an intendedbeneficiary may incur burdens that impede or evenoutweigh the benefits. We divide burdens into two broadgroups: the withdrawal or diminishment of an existingbenefit, and burdens proper that have their own categoriesas follows:

Mechanism. Sometimes a service requires user-visiblemechanisms that are not necessary in the absence of theservice. Any service generally requires new or augmentedimplementation mechanisms, but by mechanism burdenswe mean only those visible to the user; for example,acquisition of special equipment.

Location. Some services require the beneficiary to belocated in a specific place, usually because of the sensorymodalities implied (e.g., you must be within earshot of analarm).

Role responsibility. Some services require the bene-ficiary to incur responsibilities in a new role. Having tolearn and remember codes and procedures are typicalexamples.

Setup. The set-up actions required to initiate a serviceare a special case of role-related responsibility. These mayinclude specifying information that modulates other ser-vices (e.g., customizing reports or shortcuts) or defining keydata (e.g., the addresses from which email messages may bediscarded).


2.2 Functional Evolution

Functional evolution refers to changes in functional morphol-ogy over time. Experience suggests that the dominant formof functional evolution is the addition of new functions to abaseline, but existing services may become refined orspecialized, and obsolete services may be displaced. Let usassume that each service can be individuated objectivelyand, therefore, a service baseline can always be measuredby simply counting the services (we revisit this simplisticassumption in the later section in which we discuss ourdata-gathering methodology). In that case, the evolution ofthe system would be indicated by a time-varying count ofservices.

Several kinds of patterns may occur as dynamic systemsevolve: gradual or punctuated evolution, steady-state,oscillation, or chaos. We can ignore the last two as likelypatterns for software evolution, as external control factors(e.g., project management, the economics of the businessarea, and social changes affecting user preferences) likelyaffect the growth or decline of a system. Treating steady-state as a special case of gradual evolution in which thetrend is neither growth nor decline leaves the first twoforms, which are the topic of great contention in discussionsof phylogenetic evolution in modern biology. A gradualtrend would be marked by relatively even growth ordecline in the number of services over time. The gradientneed not be constant, but, if increasing or decreasing(indicating positive feedback dynamics and damping,respectively), the trends should be fairly smooth. Punctu-ated evolution, in contrast, is indicated by regular changesbetween short intervals of rapid change interspersed withintervals (generally longer than the intervals of growth)during which the size of the system does not change.

Evolutionary biology has been marked by recent con-troversies concerning the degree to which speciation isgradual (as predicted by Darwin) or whether it ispunctuated, with comparatively sudden extinctions, expan-sions, and radiations of taxa1 [29]. Similarly, in the historyof science, Kuhn [17] made the distinction between epochsof normal science in which the growth of knowledge wassteady and conservative, and rare paradigm shifts in whichthe foundations of the science in question were rethoughtand reorganized. Within software engineering, Lehman andBelady [20] in their study of the evolution of large softwaresystems, distinguished between the normal and gradualmaintenance processes that occur between major softwarereleases and the occasional redesigns that punctuate thisgradual process.

Similarly, the functional evolution of a system or productline could be gradual or punctuated. It is an empiricalquestion that depends on the interpretation of a functionalfossil record (see Section 3). We cannot prejudge theempirical question by declaring that software evolutionmust be of one type or another. We should not evenpresume that the number of services necessarily increasesover time. (Even decline and ultimate extinction is a form ofevolution.) However, if service evolution shows signs ofpunctuated evolution, we need a vocabulary to describe itsfeatures. In punctuated evolution, the magnitude of the

phenomenon being studied (the number of services orbenefits, in the case of this research) increases in bursts orexpansions that separate comparatively stable epochs. A setof new elements usually appearing during an epoch, butnot necessarily during the expansion phase at its beginning,form a cohort. Thus, a service cohort would be a set ofservices introduced during an epoch of functional evolutionif such an evolution shows a pattern of punctuatedequilibrium. The elements present at the end of theprevious epoch (i.e., the set of services that the cohortenhances) form the service baseline. Any services removedbefore the next epoch would form a displacement cohort.

Armed with this vocabulary of evolutionary types andpatterns, we can now investigate the evolution of an actualsystem and describe which types and patterns occurred.

3 A FOSSIL RECORD: THE EVOLUTION OF

TELEPHONY SERVICES

The previous section introduced a generic set of conceptsfor discussing functional evolution. In this section, weexamine the evolution of a specific set of services over anunusually long period: the provision of subscriber-visibleservices in domestic telephony over the past 50 years. Wenow describe our paleontological method and findings.

3.1 Methodology

We used only publicly available information about tele-phone services. Specifically, we tabulated the namedservices contained in the call guide (the introductorysection) of the Atlanta telephone directories for the years1950-1999. In many cases, these are familiar services and forsome years the call guides included instructions for use.

The number of services available in a given year istherefore a coarse measure of the functional size of thesystem at that time. Intuitively, some services seem morecentral or significant than others, but to assign differentweights to features based on an a priori classificationscheme rather than obtaining a raw count would beg thevery questions we seek to answer. Thus, we take account ofcentrality by classifying some services as yielding core asopposed to modulating benefits. For the time being, we willtreat all services and the benefits that they yield ascontributing equally to the functional morphology of thesystem.

3.1.1 Telephony-Specific Benefits and Burdens

The functional morphology described in Section 2 is given atShaw’s [28] research level and needs to be instantiated for aspecific application domain or product line before it can beused at the case-study level. Thus, we need to characterizethe telephony-specific benefits that appear to be corebenefits, those that appear to modulate the core benefits,and so on. In the absence of a formal theory of telephonythat is compatible with the research-level morphologydescribed in Section 2, there is room for subjectiveinterpretation and question-begging classification decisions.To minimize the risk of this, we have carefully adopted theresearch-level functional morphology categories whenpositing specific categories for the case of domestic


1. A taxonomic category or group, such a family, genus, or species.

subscriber telephony. The resulting case-study-level analy-sis is described below and summarized in Table 3.

In the case of telephony, the core knowledge orinformation transfer made possible by the system istransparent to the system’s services. Thus, the core knowl-edge benefits are simply the communication of any speechby the subscriber (the principal stakeholder with whoserequirements we are concerned) and the receptivity of thestakeholder to communications initiated by others. Beyondsimple calling and receiving of calls, telephony servicesprovide additional communication and accessibility bene-fits too. These involve the broadening of media (e.g., video)as well as the timeliness of communication and accessibility(e.g., recording, forwarding). We characterize all these typesof service as providing communication or accessibilitypotential.

In addition, more advanced services modulate thesebenefits by making the subscriber or caller aware ofinformation about the state of ongoing or previous calls.Thus, the modulating benefits are simply activities thatinform the subscriber via some cue, such as a call waitingbeep.

There are two main types of reactive benefit: thoserelating to privacy (which include nondisclosure of personalinformation and freedom from interruption) and thoserelating to organization of information (e.g., lists of specialnumbers).

Analogously, we identify five types of telephony-specificservice burdens (see Table 4). In the case of telephony,subscribers incur specific burdens, imposed by the serviceprovider or the individual services themselves.

Many services require subscribers to purchase additionalhardware or special apparatus; for example, when thephone company stopped blocking subscriber identifiable

information from callees, subscribers rushed to purchase

new Caller ID boxes or Caller ID enabled phone units. We

refer to such burdens as equipment burdens; other

examples include TTY (text telephone) and video enabled

phones. Collocation burden is also prominent in subscriber

telephony since many services such as Caller ID and, more

recently, the Message Waiting Indicator, require subscribers

to be physically located close enough to the phone unit to

either read the LED display or glance at the light indicator.

Telephony services that impose equipment and/or colloca-

tion burden force certain additional responsibilities upon

their subscribers. Certain services require subscribers to

perform a set of structured and infrequent actions, for

example to initialize and tailor a service’s options (such as

with Ring Master, which requires subscribers to assign

certain ring patterns to specific caller phone numbers) or

more repetitive and routine actions (such as when sub-

scribers interact with their voice mail service on a daily

basis). Subscribers may also incur a cognitive or memory

burden. In the case of services that require decision making,

such as with Caller ID enabled Call Waiting, the subscriber

may need to decide whether the incoming call is more

important than the current call already in progress. The

RingMaster service requires a subscriber to be able to

discern the difference between specific ring tones.

3.1.2 Attributing Benefits and Burdens to Services

The preceding explanations and examples of benefit and

burden types are general and intuitively plausible. Never-

theless, to attribute benefits and burdens more reliably to

services, a more objective method is needed. We used the

following method in the current study:


TABLE 3Benefit Categories for Telephony Services

. Characterize potential benefits and burdens for a

given service. These benefits and burdens must be

additional to those that apply to the basic services of

making and receiving calls. It is possible for a service

to deliver more than one potential benefit of a given

category or incur several burdens of the same type.

The resulting number of benefits or burdens of a

particular type is the benefit (burden) count for that

category for that service.. Aggregate the benefit and burden counts for each

category of benefit and burden over all the services

available in a given year to obtain a set of benefit and

burden counts.. Chart the variation over time of the separate benefit

and burden counts.

3.1.3 Epochs and Cohorts

Fig. 1 charts the growth in services over time. Of the two

feasible forms of evolution identified above, the gradual

and punctuated, the graph clearly shows the latter trend.

Years of expansion are marked. Note that the number of

services sometimes declines soon after an expansion.

3.1.4 Changes in Benefit/Burden Profile

More important than the number of services over time,however, are the types introduced. Table 5 provides moredetail by identifying the service and displacement cohortsfor each of the between-expansion epochs. Fig. 2 combinesthese two presentations by showing the net benefit countover time for each benefit type. The same stepwise growthcan be seen in Fig. 2 as in Fig. 1, but with the expansionsaffecting the benefit types differently.

For example, touch-tone service was introduced in 1980,

and it spurred a major expansion during which the services

Speed Calling, Three Way Calling, Call Forwarding, and

Call Waiting were introduced. These services greatly

benefited communication potential (a core knowledge

benefit) by providing more effective ways for subscribers

to get in touch with others. The growth in communication

benefits that year may be attributed to the introduction of

these services. A sharp increase in privacy benefits is

evident later, such as the introduction in 1989 of services

such as Call Block, Call Selector, and Call Tracing. These are

reactive services that arose in response to the amplified

communication and accessibility potential for the earlier

expansion in core services and reflect a growing concern for

privacy.

3.1.5 Attributing Benefits and Burdens to Services

Fig. 3 charts the five kinds of service burden per year.

Equipment burden is clearly not significant. Action burden

is fairly linear and monotonically increasing, whereas

cognitive burden is bursty. There were two peaks in

collocation burden, one in 1980 and the other in 1990.

Recall that Call Forwarding was introduced in 1980 and this

was the first time that customers were able to remain in

communication and accessible while away from their home

phone number. Of course, with this potential comes a

collocation burden. For a subscriber to fully appreciate the

potential of Call Forwarding, the subscriber must be

physically present at the number to which their calls have

been forwarded. Another service burden, setup, also

experienced peaks.


TABLE 4Burden Categories for Telephony Services


TABLE 5Service Epochs and Expansions

Fig. 1. Growth in services over 50 years (1950-1999).

3.2 Evidence for Punctuated Evolution

In Section 2, we distinguished between normal evolutionary

growth and expansions. The evolution of the telephony

services unambiguously shows the primacy of punctuated

evolution over gradual enhancement. In Fig. 2, each of the

curves for the benefit types show clear step-like features,

with the highest gradients being synchronized in all cases

around the years indicated as the year of the expansion in

question. The only benefit type that has a more gradual

profile is privacy. Because privacy benefits are the most

recent to have been introduced, there have been fewer

expansions and lower frequencies of services with privacy

benefits to show such a trend, and so it is unsurprising that

the one type of benefit not to show clear evidence of

punctuated equilibrium should be this one.

While punctuated equilibrium may not be typical of

functional evolution in all software applications, it is

remarkable that it occurred in the case of an infrastructure

that undergoes continual releases, with the services avail-

able to subscribers being documented annually. On a priori

grounds, we might have expected the evolution of tele-

phony services to be more gradual than that of applications

that undergo major releases every year or two. Whatever

the cause, telephony professionals with whom we have

discussed this are not short of technology-based and

economic explanations for specific expansions. We draw

attention to the more general lesson that some factors in the

system’s technical and cultural environment are likely to

promote punctuated evolution. In the case of one system at

one point in time, these could include the deregulation of

the United States telephone industry; in another case, they

may include the growth of Internet-based commerce and

changing concepts of privacy in society.

What this means in practice is that product development

at any time is predominantly conducted in either normal,

incremental mode or expansionist, punctuated mode. The

distinction between major and minor releases or upgrades

is enshrined in the informal numbering policies that many

organizations use when releasing software, but largely as an

administrative or configuration-control device. Given that

external pressures are likely to drive the need for more and

different kinds of benefits in discrete expansions, we

suggest that the technical and management processes an

organization uses during development should reflect this

distinction explicitly.

3.3 Periodic Retrenchment

Expansions are usually followed by a small decline in the

number of services and the benefit count. Referring back to

Fig. 2, it can be seen that most of the expansions (the high


Fig. 2. Benefit profile over 50 years (1950-1999).

gradient portions of each curve) are followed by a short-

duration, small magnitude drop in benefits. Thus, it seems

that rapid introduction of services is generally followed by a

small rebound. A diffusion explanation of this rebound

effect is that technological opportunities make some

services possible, which are subsequently consolidated

when it turns out that some services are not used by

customers or are resisted culturally (e.g., being contested on

regulatory grounds, in the case of telephony services). An

evolutionary explanation is that some previous services are

now seen to be redundant and the new ones displace them,

as in the displacement of Caller ID by Caller ID Deluxe in

which the caller’s name is given rather than a telephone

number.

3.4 Functional Decentralization

Not only was the evolution of telephony services punctu-ated, the expansions were different from each other in asystematic and generalizable fashion. The initial normalgrowth and expansions in services mainly emphasized

those providing core benefits. While these always retainedtheir role as core benefits (i.e., the telephone system is stillall about communicating with others and being accessibleto them), the later expansions included services that gain

much of their imputed benefits from the inadequacy of,interactions among, or inventive abuse of earlier services.

The precise sequence of expansions is surely unique to a

given system and is affected strongly by implementation

concerns and the social and organizational climate in which

the system is used. However, the evolution of telephony

services suggests two general trends:

1. Benefits for the actor beneficiary precede benefits forothers. Communicating with others dominated thefirst epochs in telephony; being accessible to otherswho wish to communicate with you, while signifi-cant from the start, only dominated later. It is clearfrom Fig. 2 that the earliest increases in benefit (thatis, the gradual growth prior to 1970, and the first twomajor expansions) are in the communication curve.Thus, it is not the core benefits in general that are theearliest to take off, but specifically those core benefitsthat are benefits for the caller, not the recipient ofcalls. This, we surmise, is not an accident, and pointsto an important dynamic principle in the evolutionof services that differentially benefit stakeholders.Writers in HCI and social computing [12] haveemphasized that the features of an initially diffusingtechnology should benefit the people who actuallyperform tasks with it rather than those for whomthey are acting as agents or with whom theycollaborate indirectly. In a very different domain,the production of electronic presentations, one can


Fig. 3. Burden profile over 50 years (1950-1999).

see in products such as Powerpoint, featuresintended for the author/presenter taking priorityin early versions over features intended for the liveor archival audience.

This suggests a somewhat Machiavellian require-ments guideline that projects should be morecareful in prioritizing and clarifying the require-ments obtained from actor stakeholders, especiallywhen system use is discretionary, than thoseobtained from other stakeholders, such as theostensible owners or clients for the system. In thecase of the telephone system, it is making (andpaying for) calls, not receiving them, that places thesubscriber in the most active role, and it is featuresfor callers, not recipients, that therefore received theearliest emphasis.

2. Object-level benefits precede metalevel benefits. Wherebenefits refer to the creation and transfer ofinformation (object-level benefit), such services takepriority over services that add value to thatinformation by creating or transferring informationabout it or about how the system is manipulating it(metalevel benefit). Compare the curves in Fig. 2 forcommunication and accessibility on the one handand awareness and organization on the other.Communication and accessibility benefits are at theobject level. They are benefits for the subscriber inhis or her role as communicator. Awareness andorganization benefits, on the other hand, aremetalevel benefits. They are benefits for thesubscriber in his or her role as user of communica-tions technology. Services providing awareness andorganization benefits arise in reaction to the addedcomplexity of the earlier communication- andaccessibility-enhancing services (A user needscaller-id only if he or she must constantly decidewhether to answer the phone.) Thus, awareness andorganization benefits did not figure prominently inthe early evolution of telephony services, but theytake off during more recent development of services.As telephony services continue to converge withother communication services, such as e-mail, wepredict a much greater emphasis on services yield-ing metalevel benefits.

These observations suggest that customization featuresmay be relatively unimportant in most systems. Once thecore services are largely in place, design options formetalevel services such as user customizations may besignificantly limited by the legacy of core design decisions.Customization devaluing in this way is somewhat surpris-ing and goes against the grain of much recent communica-tion technology development. Rather than taking a standabout the efficacy of customization for the ideal user, wesimply observe that metalevel services are likely to beunimportant during the early development of most systemssimply because the core services that customization featureswill customize have yet to be laid down in sufficient detail.But the mass of early decisions that lead to the core benefit-yielding services may constrain the ways in which the nowfirmly entrenched functionality can be customized.

However, this should not be taken as a recommendationnot to consider or anticipate the need for specific metalevelservices in advance on the grounds that it is impossible totell exactly what will be needed later. On the contrary,where the core services greatly amplify access to aparticular kind of knowledge or communication resource,it seems very likely that metalevel services will be called forlater to help users modulate access to these resources. In thecase of telephony services, these easy-to-anticipate servicespresumably should have included lists of user-specificinstances (e.g., friends’ phone numbers, a personal dic-tionary), categories (e.g., types of message), or events (e.g.,importance of calls). Without knowing the details ofmetalevel services, therefore, it should be possible in thecase of any system to anticipate from an analysis of the corebenefits the major types of metalevel benefit to be requiredof future services.

3.5 Benefit/Burden Dialectic

Once a service has been designed and deployed, it ceases tobe an artificial creation and becomes part of the user’snatural experience. Thus, irrespective of the designers’intentions, the service takes on a life of its own. Its potentialbenefits may fail to be realized; it may be reinvented byusers who adopt it in creative and unintended ways (e.g.,the answering machine being used as a call-screening ratherthan recording device); it may give rise to new modes ofactivity, including countermeasures to its perceived abuse.The literature on technology diffusion is littered withexamples of unforeseen reinventions by users [26], andDahlbom and Mathiassen [9] make this dialectic betweenhopeful deployment (thesis), nonoptimal use (antithesis),and reinvention in the field (synthesis) a major thrust oftheir design approach. More colorfully, Tenner [31] talks oftechnology biting back, when an acute benefit (e.g.,agricultural pest control) gives rise to chronic burdens(e.g., rapid evolution of pests that resist the controls), thuscreating the need for further reactive innovations.

In the evolution of telephony services, we see thisdialectic, or competition between types of benefit or burden,in the tensions between accessibility and privacy and in thegeneral amplification of core benefits on the one hand andthe concomitant need for awareness-enhancing and orga-nizational services on the other. In both cases, the reactiveservices lagged the introduction of the services and theinitial epoch of their use. Specifically, Fig. 2 shows that thecurve for privacy benefits significantly lagged the curve foraccessibility benefits. Furthermore, the curves for awarenessand organization benefits lagged the curves for both coreservices (communication and accessibility). These differ-ences did not necessarily have to be observed. While it mayseem absurd to talk of reactive or modulating benefitspreceding the autonomous benefits that they react againstor the core benefits that they modulate, it is quiteconceivable that, given a few autonomous or core services,the reactive and modulating services would then take offdramatically. However, this did not happen. The secondaryservices are only introduced after the basic services havealready been in use for some time.

Benefits are always tarnished in some way and, there-fore, we recommend that new services always be analyzed


in terms of benefits and burdens. Even though a trade-offanalysis may clearly indicate the net benefit of a servicenow (and, therefore, that it should be given high priority),recognizing its downstream burdens gives the designersome confidence about what reactive services may berequired subsequently and, therefore, should be plannedfor in the design of architectural structure. While the precisedetails will be specific, general patterns can be detected thatdo not require specialized domain or sociological knowl-edge. For example, amplified knowledge-creation andtransmission benefits generally increase the likelihood thatmetalevel services will be needed later to marshal and makesense of the object-level information that the earlier servicesmake available. Thus, the need for improved filtering; user-interface and visualization features can be predicted in theexpansion following the introduction of any powerfulknowledge-creation service.

Finally, one stakeholder’s benefit often becomes an-other’s burden. We addressed this in passing earlier whenemphasizing the core actors. We are currently investigatingthe benefit/burden profiles for different stakeholders incommunications applications, which turn out to be subtleand difficult to anticipate. Most readers will be familiar,however, with the “arms races” between e-commerceservices that provide convenience at the cost of disclosureand those that protect consumer privacy at the cost of denialof service.

4 DISCUSSION

This paper advocates study of the evolution of the functionsoffered by a system over its lifetime as a basis forunderstanding/predicting future characteristics of thesystem itself or comparable systems; the approach istherefore relevant to the management of long-life softwaresystems. It also contributes a new methodology forconsidering how systems have evolved to their currentstate from an end-user service perspective. When taking aproduct forward, it helps to understand where it has beenand what kinds of technical decisions have been made. Suchan analysis helps one consider how future services might beadded on, beginning with object services and then extend-ing to metalevel services.

4.1 Validity and Generality of “Paleontological”Data

The fossil record presented in Section 3 is based on a sampleof service data for one region of the United States. Wirelesstelephony, data communications, and business telephonyservices are among the services that we did not considerbecause of our data-gathering method. It is possibletherefore that our data harbors systematic bias; for example,perhaps business-oriented services would have revealedmore gradual enhancement of core communication benefits.But, there seems no good reason to posit such bias otherthan the concern that the data is unavoidably incomplete.

What is more, our concrete data applies to just one formof telephony services. While there seems to be no goodargument for supposing that the principal trends identifiedin this study are restricted to subscriber telephony, never-theless the failure to include small and large-business

telephony, the distinction between local and long-distanceswitching and billing, and the recent introduction ofwireless services and hybrid voice, media, and datacommunications services mean the results and interpreta-tions given in Section 3 may apply only narrowly. We areconfident, however, that the findings will prove to begeneral across communication and coordination applica-tions such as group-based productivity and CSCW applica-tions and infrastructures. Communication, accessibility,privacy, awareness, and organization benefits are generalto all such communication and coordination applications.

Indeed, with minor modifications and a differentinstantiation of the general benefits identified in Section 2,the general conclusions from the previous section shouldapply to most systems that are dominated by what Jackson[15] calls the dynamic information systems problem frame,which includes all requirements for dynamically updating amodel of the world and communicating the state of themodel to a user, as well as some variants of the controlproblem frame, in which the system is responsible forcontrolling some autonomous real-world process. In therestricted set of control problem frames to which weenvisage our results applying, the phenomenon being“controlled” by the system is more likely to be theinfluencing and coordination of human communication.The human or organization being influenced by the systemis referred to by Jackson as a biddable domain because it iscalled on to do the control system’s bidding, but is in nosense causally determined by it.

But, although our work should translate into othersystem contexts that govern communication and coordina-tion, many other important computer-based applicationsthat do not fall into these categories or problem frames arelikely to evolve according to the patterns we havediscussed. We do not think that the benefit/burdentypology introduced in Section 2 or the results andinterpretations discussed in Section 3 are likely to general-ize to Jackson’s transformational applications (which includecompilers or pattern recognizers), physical control systems,such as manufacturing or avionics control systems (asopposed to the human or organizational biddable controlsystems described in the previous paragraph), staticinformation systems, such as search engines, and workpiecesoftware products, such as word-processors or spread-sheets. Each deserves separate treatment.

While communication and coordination applicationslend themselves to a goal-oriented analysis that yields upbenefits and burdens as topics of discourse, control, orworkpiece applications, for example, probably requiredifferent treatment, and their evolution should be explainedin terms of that treatment. For example, workpieceapplications such as word processing are dominated bythe idea of creating and editing content. Thus, informationstructure and semantics becomes more critical than in thecase of telephony and suggest the need for an object-oriented analysis in place of a goal-based analysis. Anexample of a more object-oriented conceptual basis suitedto workpiece applications is the investigation by Hsi andPotts [13] of the successive releases of a commercial officeproductivity suite.


4.2 Interactions among Function, Structure, andEnvironment

The treatment of functional evolution in this paper isunusual in our deliberate ignoring and downplaying ofwhat is known about the underlying switching technologyand business environmental factors during the period ofevolution that we studied. A more complete treatment oftelephony service evolution or the evolution of anyapplication services warrants the incorporation of knowl-edge from public policy, usability studies, cultural studies,and the details of the design architecture and enablingtechnologies in question. Such a broader analysis wouldreveal whether there is a correlated punctual evolution oftechnology and environment. However, our perspective isthat these issues, while of great practical importance, have aderivative role in explaining how functional evolutionoccurs. Before we can study how these factors affect theevolution of services, we need a better characterization ofwhat services are and what kinds and patterns of evolu-tionary change can reasonably be expected to occur insystem developments.

4.3 Related and Future Work

The paleontological approach to studying the evolution of

existing systems that we have developed and applied to the

case of subscriber telephony services is very different from

most software engineering research methodologies that

have been designed to answer questions that Shaw [28] calls

generalization, method/means or selection questions. In

particular, we have treated telephony services as a

phenomenon to study, akin to the objects of the life sciences

or the natural history that preceded the development of

biology as a hard science. Instead of studying developer

rationale, user performance, or organizational context, and

instead of developing and advocating process interventions

or technology, we have taken the stance that service

evolution is not entirely under the control of development

or user organizations and is best studied as an autonomous

phenomenon. However, the main reason for being inter-

ested in service evolution is the possibility that systems may

be made to fit better with their users’ requirements and can

be made to evolve in such a way that users’ benefits are

maximized without the introduction of egregious burdens

that undermine the efficacy of the services to the users. In

this final section, we shall compare our approach to more

development-oriented practices and research findings,

signaling points at which they differ and where there is

overlap and potential for an integrative understanding.

4.3.1 Benefits and Function-Based Measurement

By studying functional evolution as the change over time infunctional morphology and by studying functional mor-phology as a profile or portfolio of potential benefits thatthe system’s services can yield or burdens that it canimpose, we have essentially proposed another measure ofsystem size. Size metrics are most used in cost estimation,for which purpose they must be related either directly orindirectly to the software medium to be produced. Lines ofcode are obviously defined in implementation terms, but so

too are function points in a more disguised fashion.Function points are weighted combinations of input- andoutput-attributes of a planned system [22] and, thus, reflectthe interface complexity of a system. Function points are amore requirements-oriented basis for cost estimates thanlines of code because interface complexity captures a majorfactor in the cost of developing software, but they do notdirectly address the value or usefulness of differentservices. Thus, they take a developer-oriented perspective,rather than a user-oriented perspective. We concludetentatively that function points and benefit/burden countstogether will provide a more detailed estimate of thefunctional “size” of a system or collection of services, andone that could be used for a variety of developer-orientedand user-oriented design and evaluation tasks than eithercan on its own.

4.3.2 Services Compared to Use Cases

Services are also closely related to use cases [14], which aremodes of system use that external agents initiate with apurposeful input. Services could even be seen as justanother name for use cases. But there are importantdifferences. Unlike use cases, a service’s scenarios mayexhibit temporally disjointed episodes. For example, inCaller ID Deluxe, a subscription episode initiated by thesubscriber occurs just once on service inception. Then, afteran indeterminate interval, a caller initiates an identificationepisode, a type of episode that is repeated for everysubsequent incoming call (Note that the identification neednot be successful for the episode to occur.) A use-caseanalysis of Caller ID Deluxe, at least in Jacobson’s originalformulation, would differ markedly in making the sub-scription and calling episodes completely different usecases. Other services may involve more types of episode.For example, Voicemail involves subscription, calling andrecording a message, retrieving messages, and even,arguably, replying to them.

4.3.3 Services and the Context of Activity

Services are not the only ways for a customer to achieve hisor her goals. Workarounds are bundles of manual behaviorsand the inventive uses of other automated services toachieve the same purpose, albeit often imperfectly and lessconveniently. In the absence of Caller ID, a caller andrecipient might agree on a code that identifies the caller,such as ringing twice in quick succession. Workaroundsmay be useful in the presence of service unavailability,excessive cost, or temporary breakdown, but they typicallyresult in degraded outcomes and require additionalresponsibility, including, sometimes additional actions byagents other than the customer.

In Activity Theory [23], tools are an integral part of theactivity, shaping the way we conceive of and plan activitiesand learn skilled behaviors. What constitutes a “tool” inActivity Theory is more abstract than the everyday use ofthe term implies since it includes any part of the world orculture, such as language, whose affordances lend it tobeing recruited to some purpose. Because services affect thebehavior of agents and constrain their choices, services aretools in the Activity-Theoretic sense. As activities change inthe world (e.g., increased use by business of telemarketing)


so a service’s appropriateness (e.g., Caller ID) changes, theadoption of other tools and behaviors will follow as a resultof these changes. A service such as Caller ID may adapt thebehaviors of a caller, as over time callers learn tactics forpublicizing or hiding their identity.

4.3.4 Functional Morphology and Value Analysis

Numerous proposals have been made for assigningpriorities to features or requirements and managing trade-offs involving multiple requirements and design criteria [5],[16]. Sullivan’s [30] application of real options theory to thevaluation of product features is a more recent andeconomically more sophisticated contribution of the samekind. These approaches all have in common the provision ofa normative basis for decision making and prioritization, arequirement that demands pairwise prioritization of fea-tures or, alternatively, the reduction of benefit to a common“currency” of comparison—either in terms of abstractutility quantities or by translation of stakeholder prefer-ences into explicit monetary values.

In contrast, we argue for preserving the multidimen-sional and fundamentally incommensurable nature ofdifferent benefits and burdens if the aim is to understandthe likely future consequences of introducing features andservices. An additional advantage of doing so, which we areexploiting in continuing investigations of telephony ser-vices, is the ability to compare actual or proposed serviceswith already available work-arounds or the creative use ofexisting services to approximate the same benefits.

4.3.5 More Research Questions

We close by asking how our results might be applied toanswer other types of question about software evolution.Shaw’s [28] classification was summarized in Section 1, andwe adopt it again here. Most of these questions are merelyideas for future research.

. Feasibility Questions. Is it possible to relate thefunctional morphology of the system in question tothe software architecture? Is it possible to relate theevolutionary dynamics of user-visible services to theevolutionary dynamics of implementation architec-ture? Specifically, how do services relate to easilyindividuated architectural components? Are therepredictable architectural constructs that correspondto differences in the type of a service?

. Characterization Questions. What are the essentialcharacteristics of a service, a benefit, a burden? Is abenefit/burden-based ontology appropriate forother problem frames? If not, what are the bestalternatives (e.g., object-oriented analysis for work-piece applications)? If so, what are the appropriatecategories to use when going from the research levelto the case-study level?

. Method/Means Questions. How can we predict (orhelp expert stakeholders predict) the requirementsthat are the most likely to stay stable throughout thelifetime of the system? How can we identify therequirements for likely metalevel services when wehave only studied the object-level services of thesystem?

. Generalization Questions. Do the patterns observed inthis study (see Section 3) carry over to otherapplications that have been studied across multiplereleases? If not, what is the explanation for thedifferences?

. Selection Questions. What system services should beelaborated and fixed first?

ACKNOWLEDGMENTS

The authors wish to thank the staff of BellSouth Advertising

and Publishing Company. The Atlanta History Center

provided the authors with historical records of telephone

service availability. Daniel Berry and anonymous reviewers

of a previous version of the paper made many helpful

comments. This research was supported inpart through

collaboration with BellSouth Telecommunications via the

North Carolina State University Center for Advanced

Communications and Computing.

REFERENCES

[1] R. Allen and D. Garlan, “A Formal Basis for ArchitecturalConnection,” ACM Trans. Software Eng. and Methodology, vol. 6,no. 3, pp. 213-249, July 1997.

[2] A.I. Anton, “Goal-Based Requirements Analysis,” Proc. Int’l Conf.Requirements Eng. (ICRE ‘96), pp. 136-144, Apr. 1996.

[3] A.I. Anton and C. Potts, “The Use of Goals to Surface Require-ments for Evolving Systems,” Proc. Int’l Conf. Software Eng.(ICSE ‘98), pp. 157-166, Apr. 1998.

[4] G. Basala, The Evolution of Technology. New York: Cambridge Univ.Press, 1988.

[5] B. Boehm, P. Bose, E. Horowitz, and M.J. Lee, “SoftwareRequirements Negotiation and Renegotiation Aids,” Proc. 17thInt’l Conf. Software Eng., pp. 243-253, Apr. 1995.

[6] S. Brand, How Buildings Learn: What Happens After They’re Built.New York: Viking, 1994.

[7] N. Chomsky, Aspects of the Theory of Syntax. Cambridge, Mass.:MIT Press, 1965.

[8] B. Curtis et al., “A Field Study of the Software Design Process forLarge Teams,” Comm. ACM, vol. 31, no. 11, pp. 1268-1287, 1988.

[9] B. Dahlbom and L. Mathiassen, Computers in Context: ThePhilosophy and Practice of Systems Design. Blackwell, Oxford, 1993.

[10] J.-M. DeBaud and K. Schmid, “A Systematic Approach to Derivethe Scope of Software Product Lines,” Proc. Int’l Conf. SoftwareEng., pp. 34-43, 1999.

[11] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:Elements of Reusable Object-Oriented Software. Reading, Mass.:Addison-Wesley, 1994.

[12] J. Grudin, “Computer-Supported Cooperative Work: History andFocus,” Computer, vol. 27, no. 5, pp. 19-26, May 1994.

[13] I. Hsi and C. Potts, “Studying the Evolution and Enhancement ofSoftware Features,” Proc. Int’l Conf. Software Maintenance, pp. 143-151, Oct. 2000.

[14] I. Jacobson et al., Object-Oriented Software Engineering: A Use CaseDriven Approach. Addison-Wesley, 1992.

[15] M. Jackson, Problem Frames: Analyzing and Structuring SoftwareDevelopment Problems. Addison-Wesley, 2001.

[16] J. Karlsson and K. Ryan, “A Cost-Value Approach for PrioritizingRequirements,” IEEE Software, vol. 14, no. 5, pp. 67-74, Sept.-Oct.1997.

[17] T.S. Kuhn, The Structure of Scientific Revolutions, third ed. Univ. ofChicago Press, 1996.

[18] A. van Lamsweerde, R. Darimont, and P. Massonet, “Goal-Directed Elaboration of Requirements for a Meeting Scheduler:Problems and Lessons Learnt,” Proc. Second Int’l Symp. Require-ments Eng. (RE ’95), pp. 194-203, Mar. 1995.

[19] A. van Lamsweerde, “Goal-Oriented Requirements Engineering:A Guided Tour,” Proc. IEEE Fifth Int’l Symp. Requirements Eng.(RE ’01), pp. 249-261, Aug. 2001.

[20] M.M. Lehman and L.A. Belady, Program Evolution—Processes ofSoftware Change. London: Academic Press, 1985.


[21] M.M. Lehman, “Programs, Life Cycles and the Laws of SoftwareEvolution,” Proc. IEEE, Special Issue on Software Evolution, vol. 68,no. 9, pp. 1060-1076, Sept. 1980.

[22] S.G. MacDonell, “Comparative Review of Functional ComplexityAssessment Methods for Effort Estimation,” Br. Computer Soc./Inst.Electrical Eng. J., vol. 9, no. 3, pp. 107-117, 1994.

[23] Context and Consciousness: Activity Theory and Human-ComputerInteraction. B.A. Nardi, ed., Cambridge, Mass.: MIT Press, 1996.

[24] H. Petroski, The Evolution of Useful Things. New York: VintageBooks, 1992.

[25] C. Potts, “A ScenIC: A Strategy for Inquiry-Driven RequirementsDetermination,” Proc. IEEE Fourth Int’l Symp. Requirements Eng.,June 1999.

[26] E.M. Rogers, Diffusion of Innovations. New York: Free Press, 1995.[27] F. de Saussure, Course in General Linguistics. translated by W.

Baskin. Reprint. New York: Philosophical Library, 1959.[28] M. Shaw, “The Coming-of-Age of Software Architecture Re-

search,” Proc. IEEE 23rd Int’l Conf. Software Eng., pp. 657-664a, May2001.

[29] E. Sober, The Nature of Selection: Evolutionary Theory in PhilosophicalFocus. Chicago, Ill.: Chicago Univ. Press, 1993.

[30] K.J. Sullivan, “Software Design: The Options Approach,” Proc.Second Int’l Software Architecture Workshop, Joint Proc. SIGSOFT ’96Workshops, pp. 15-18, Oct. 1996.

[31] E. Tenner, Why Things Bite Back: Technology and the Revenge ofUnintended Consequence. Knopf, 1996.

[32] S. Zuboff, In the Age of the Smart Machine: The Future of Work andPower. Basic Books, 1988.

Annie I. Anton (M’90) received the PhD degreein computer science from the Georgia Institute ofTechnology, Atlanta, in 1997, and joined thefaculty of North Carolina State University,Raleigh, in 1998. She is an assistant professorat the same university. Her research includes afocus on the specification of complete, correctbehavior of software systems that pose signifi-cant risks as a consequence of failures andmisuse. She is a cofounder and codirector of the

NCSU E-Commerce Studio as well as the founder and director ofThePrivacyPlace.org. Dr. Anton is the cognitive issues area editor of theRequirements Engineering Journal, and has served as both programchair and general chair of the Symposium on Requirements Engineeringfor Information Security (SREIS). She is an US National ScienceFoundation CAREER award winner, a CRA Digital Government Fellow,and member of both the IEEE and ACM.

Colin Potts received the PhD degree inpsychology from Sheffield University, UK, in1982. He is an associate professor in theCollege of Computing at Georgia Institute ofTechnology, Atlanta, and is affiliated with theGraphics, Visualization, and Usability (GVU)Center and the Georgia Tech InformationSecurity Center (GTISC). His research in re-quirements engineering, user-centered designprocesses, and feature evolution emphasizes

mechanisms for supporting, enforcing, and analysis of policies andnorms. He was previously a senior member of the technical staff at theMicroelectronics and Computer Technology Corporation (MCC) and amember of the faculty of Imperial College of Science, Technology andMedicine, London. He also is a member of the IEEE.

. For more information on this or any computing topic, please visitour Digital Library at http://computer.org/publications/dlib.


functional paleontology: the evolution of user...

Documents