5 0 I E E E S O F T W A R E J u l y / A u g u s t 2 0 0 2 0 7 4 0 - 7 4 5 9 / 0 2 / $ 1 7 . 0 0 © 2 0 0 2 I E E E

Experience shows that a company candrastically improve its competitive advan-tage if it optimizes how it develops theseproduct lines.1,2 Using product line engineer-ing, some organizations have reduced thenumber of defects in their products and re-duced costs and time to market by a factorof 10 or more.1,3 However, many companiesdon’t use a product line engineering ap-proach when developing their product lines.More often than not, they either start from asingle system, branching off new variants asthe need arises and ending up with com-pletely independent code bases, or they startwith the different variants as independentprojects from the beginning.

Product line engineering focuses on de-veloping multiple variants of systemsjointly, thus exploiting the commonalityamong systems in the form of reuse.1 Thekey to successful product line engineering

approaches, such as Pulse4 (a component-based product line development approachdeveloped at the Fraunhofer Institute forExperimental Software Engineering), is toidentify early on a reference architecturethat provides a blueprint for producing dif-ferent variants. The structural similarityamong the variants, resulting from the com-mon architecture, enables developers toreuse components across a range of differ-ent products in the product line. However,when implementing product line engineer-ing, a wealth of options exists, so compa-nies must make wise decisions to optimizetheir economic benefit. To exemplify this,we discuss Market Maker Software AG’s3

Merger product line.

Product line adoption schemesIn theory, the optimal product line devel-

opment adoption scheme is to set up a com-

focusThe Economic Impact ofProduct Line Adoption andEvolution

Klaus Schmid, Fraunhofer Institute for Experimental Software Engineering

Martin Verlage, Market Maker Software AG

When transitioningto product linedevelopment, anorganization mustconsider theadoption context andshould use productline scopingtechniques tooptimize theeconomic benefits.

Software is increasingly turning into a commodity; thus, people in-creasingly expect systems that are customized to their needs. Thissituation is forcing nearly every software development organiza-tion to develop multiple variants of their systems to serve the spe-

cific needs of different customers or market segments. Thus, many, if notmost, software development organizations are finding that they need tobuild families of systems or product lines.

initiating software product lines

pletely new product line by developing a reuseinfrastructure for the whole range of productsright from the start. We often call this the bigbang approach. You can use this infrastruc-ture to develop new products, which coulddrastically cut costs compared to traditionalstovepipe development. Of course, when firstplanning a product line, predicting the spe-cific investments and benefits is hard, so eco-nomic results will contain some uncertainty.

Unfortunately, this ideal approach ishardly ever adequate in practice. In principle,strong upfront planning should let you de-velop assets that support the full range offunctionality the product line requires, butorganizations often use a more incrementalapproach. With an incremental approach,you develop assets to support the next fewupcoming products, deliberately excludinghighly uncertain potential products. Overtime, you need to extend and adapt assets toaddress further products. Usually, constraintson available resources force this more incre-mental approach, but it’s generally usefuleven with unlimited resources because of theintrinsic uncertainty of future products andtheir requirements. Figure 1a shows the idealbig bang pattern, and Figure 1b compares itwith the corresponding patterns for the in-cremental approach.

Regardless of which approach you use, itis best to first distinguish several basic situa-tions from which product line adoption canstart. You can then link each situation to cor-responding strategies (or adoption schemes)and connect a different pattern of investmentand resulting benefits to each one.

We can distinguish four main types of situ-ations for adopting product line engineering:

� Independent. The company starts a newproduct line without any predecessorproducts.

� Project-integrating. Existing systems arealready under development to address anew market. As part of product line de-velopment, the software engineers inte-grate the systems so that they can derivethem from the same reuse infrastructure.

� Reengineering-driven. Legacy systemsalready exist, but the engineers can’t usethem for product line development—rather, they need to perform a nontrivialreengineering effort.

� Leveraged. The company sets up a newproduct line (to address a new market)based on a product line that is alreadyin place.

In practice, these situations often overlap.Consider Market Maker’s Merger product

line. Market Maker started in 1990 as a one-person company with a single product: aDOS-based system for tracking stock infor-mation. It has since grown to 60 employees,but to optimize its limited resources, MarketMaker has always used a product line ap-proach. Even in the DOS version, variousmodules were available to address specificdata-processing needs, and customers couldindependently bring in other modules. (How-ever, the implementation level only had a sin-gle variant and certain menu entries enabled,based on the given license key.)

As the company created new softwareplatforms, it found it had to develop moresophisticated approaches to address increas-ingly complex variability needs. In 1995, itstarted developing a new software systemaimed at supplanting the original DOS-based product and transferring its potentialto the Windows-based age. Like the originalproduct, the new system supported the mod-ule concept. However, over time, the com-pany created additional implementation-level variants (for special applications) and

J u l y / A u g u s t 2 0 0 2 I E E E S O F T W A R E 5 1

Risk

Break even Number of products Number of products

Initialinvestment

Big bangproduct linedevelopment

Traditionaldevelopment

Product linedevelopment

Incrementalproduct linedevelopment

(a) (b)

Effo

rt

Effo

rt

Figure 1. Product line investment curves: (a) the big bang approach, including risks; (b) the big bangversus incremental approach.

entry-level mass-market variants. These vari-ants constituted the Market Maker productline—the company produced them from asingle, common code base.

In 1999, the company decided to enterthe market of Internet-based stock-marketinformation systems. It thus created theMerger product line, which was based on acompletely new infrastructure developed inJava (Martin Verlage managed the Mergerproduct line’s setup and evolution). Cur-rently, this product line includes about 15variants addressing three different marketsegments (see Figure 2a). When developingMerger, the company decided not to repli-cate functionality that already existed in theMarket Maker product line—such as theMM98 and MM live variants that addressthe historical data feed and the real-timedata feed, respectively. So, it created specificvariants of the Market Maker product lineand used them as data servers in the Mergerinstallations (see “MM98” in Figure 2b).

When adopting and evolving its productline approach for these two product lines,Market Maker applied the schemes we dis-cuss here with huge success.

Product line entry and exploitationpotential

Depending on the specific situation inwhich you start product line development,you usually find different patterns of how thecompany incrementally develops the productline and, similarly, different patterns of in-vestment and return on investment. In partic-ular, you need to determine whether the in-

crement originates by successively extendingand adapting the reuse infrastructure for ad-ditional products, or whether the companyextends it by successively adding assets cov-ering additional functionality.

Independent adoption The independent product line adoption

scenario is the prototypical product line situ-ation (see Figure 1a). Because no products ex-ist yet, the company can plan in detail andoptimize its product portfolio. Compared tothe product line’s overall setup time, the plan-ning time would be rather low, so it wouldn’tsignificantly increase the time to market.

However, starting a completely newproduct line means venturing into the com-pletely unknown. Thus, technical feasibilitystudies and detailed market analyses arenecessary to control the overall uncertainty.Furthermore, even if you use these meas-ures, you usually still have significant un-certainty, because, for example, some prod-ucts could become more or less important asproduct development progresses.

In the context of the Merger product line,the company made a detailed analysis of po-tential portfolios, identifying major marketsegments, key requirements, and so forth.Additionally, it performed technical feasibil-ity studies and competitor surveys. Al-though these analyses were rather thorough,plans still required adjustment. For exam-ple, the company addressed some marketsegments later than anticipated or not at all,because more products than expected couldbe delivered to the customer in the initial

5 2 I E E E S O F T W A R E J u l y / A u g u s t 2 0 0 2

Qtr. 1 Qtr. 2 Qtr. 32000

(b)(a)

Qtr. 4

5

4

3

2

1

0

RMIRMI

Application layer

RMI

Servlets

Data access layer

JDBC/ODBC

HTTPHTTP

Java wrapper

COM interfaceCOM interface COM interface

Java wrapper Java wrapper

MM live! MM live!MM98

WAP

Banksintranet External

applications

Chartdata

Basicdata

Market segment 1Market segment 2Market segment 3

Figure 2. The Merger product line: (a) systems delivered over time and (b) the product line architecture.

market segments. Despite these deviations,it is clear in retrospect that the initial effortswere not wasted. Rather, they played a keyrole in focusing the reuse infrastructure’s de-velopment, so now Market Maker can effi-ciently develop new variants.

Project-integrating adoptionFrom our experience in industrial prac-

tice, we’ve found that the independent situa-tion is rather uncommon. Usually, severalproducts exist in a company that have somecommonalities but were more or less inde-pendently developed. There is continuouspressure to bring to market new products, soit is impossible to put product developmenton hold to focus on developing an integratedproduct line infrastructure. Rather, an incre-mental approach is required, where keycomponents are successively generalized intocommon, reusable components.

A special case of the project-integratingsituation exists when two product line in-frastructures must merge. Such a situation iscurrently occurring at Market Maker—thecompany is integrating the original MarketMaker and Merger product lines into a sin-gle product line architecture. Althoughcompanies can usually avoid project-inte-gration by replicating functionality amongthe two product lines, at times profounddifferences in the nonfunctional require-ments make it necessary. In this situation,the company integrates the reuse infrastruc-tures, focusing on integrating the replicatedcomponents. Because the company mustcontinually derive new products and re-leases from the product lines, it can onlyperform an incremental, component-wiseintegration of the reuse infrastructures—similar to the incremental pattern Figure 1bshows. However, if compared to the initialsituation, the entrance barrier (the effort re-quired before you can derive the first prod-ucts from the resulting infrastructure) isusually lower, whereas the number of steps(effort to extend the product line infrastruc-ture) will be higher. Also, the company gen-erally must expect more problems with thedegradation of the reference architecture.

This is the general adoption pattern forproject-integrating product line develop-ment—create a common infrastructure byintegrating technical areas in a component-wise manner. This leads to an incremental

approach, similar to the one in Figure 1b.However, compared to the initial situation,the entrance barrier (effort required untilthe first products can be derived from theresulting infrastructure) will usually belower, while the steps (effort to extend theproduct line infrastructure) will usually behigher. Also, more problems generally occurwith the degradation of the reference archi-tecture over time.

Reengineering-driven adoptionA company usually undertakes reengi-

neering-driven adoption if it finds that itssoftware development is bound to hit a wall.This can manifest itself in many ways—forexample, if the cost of product developmentgrows too high or if it becomes impossible toderive new, envisioned products based on theavailable systems. Companies typically willtolerate a certain level of pain before makingthe investments associated with performing amajor reengineering effort. However, whenthey do undergo such reengineering, it’s thenfairly easy to introduce the additional effortrequired to plan a product portfolio. Reengi-neering can either focus on packaging the ex-isting legacy system as a whole or it can aimat a component-wise approach.

This situation is similar to independentadoption and its economic patterns. If thecompany packages the legacy as a whole, itincurs rather large investments in the begin-ning but significantly reduced costs for devel-oping future systems (see Figure 1a). If thecompany performs component-wise packag-ing, an incremental pattern (see Figure 2b)will result, but reengineering generally re-quires a large initial investment compared totypical project-integrating situations.

A good example of the component-wiseapproach to reengineering-driven adoptionis the Ramsis kernel redesign project thatFraunhofer IESE performed with a smallcompany. This project focused on a reengi-neering-driven product line design for alarge legacy system of ergonomy simula-tions.5 It started with a significant reengi-neering effort for identifying components inthe existing system and packaging them toturn the system into an appropriate basisfor further product line development.

Developing the Merger product line alsomirrors this situation, because, as discussedearlier, the company reused Market Maker

J u l y / A u g u s t 2 0 0 2 I E E E S O F T W A R E 5 3

There iscontinuouspressure to bring to

market newproducts, so itis impossible to

put productdevelopment

on hold to focuson developingan integratedproduct line

infrastructure.

functionality as servers, and prior to that, ithad to add specific interfaces to theseservers. However, for Merger, packagingonly required augmenting the existing sys-tems with appropriate interfaces usingCOM. Also, the Merger product line wasbuilt on top of the existing one, which iswhy it’s more appropriately characterized asleveraged product line adoption.

Leveraged adoptionLeveraged product line development is

perhaps the most sophisticated approach toproduct line adoption. As opposed to theother patterns, it requires an existing productline and is characterized by a shift to a newmarket (system type). Examples of such ashift are Cummins Engines, which expandedits original product line for car and truckdiesel engines to arbitrary industrial dieselengines, and CelsiusTech, which leveraged itsproduct line of battle ship control systems byentering the market of civil air-control sys-tems.6 In these cases, the existing product lineinfrastructures provided leverage for enteringthe new market, giving the company a com-petitive advantage right from the start.

The Merger product line is clearly a caseof a leveraged product line. The existingMarket Maker product line offers leverageby providing data gathering, data manage-ment, and aggregation services, while theMerger infrastructure mainly focuses ondata transformation and online presenta-tion tasks. Market Maker packaged its orig-inal product line’s functionality into Mergerin the form of servers. This partitioning ofthe reuse infrastructure also benefits Mergerproducts through ongoing development onthe Market Maker product line.

From an economic viewpoint, a leveragedproduct line adoption entails a revolution,because the company can address a com-pletely new market segment with low costsand few risks by building on an existingproduct line infrastructure. However, as inother situations—in particular, the independ-ent situation—the company must perform adetailed product portfolio analysis, technol-ogy studies, and risk analysis. Similarly,leveraged adoption usually requires an initialinvestment and then shows a steady growthin the number of systems (see Figure 1a). ForMerger, the leveraged approach proved to behighly successful. However, Figure 2a shows

a slightly different pattern of nearly expo-nential growth. The reason for this is that theMerger reuse infrastructure itself grew overtime. Thus, later systems could be built withmore reuse.

Product line evolutionThe main factor determining how a

product line evolves is how much deviationthe organization allows before reunifyingthe infrastructure. We can distinguish threebasic situations for product line evolution(not taking into account replacing the infra-structure’s parts over time).

In the first situation, infrastructure-basedevolution, new product requirements thatmight be reusable immediately lead to a gen-eralization of the product line infrastructure.Thus, the organization can avoid the prob-lem of multiple implementations of the samerequirement. However, this usually results inmany changes to the product line infrastruc-ture. A specific product (the first one in needof a new requirement) triggers each change,which is implemented in a way adapted tothe next few products (see Table 1). MarketMaker took this approach with its Mergerproduct line. If it hadn’t, the simultaneousdemands for many new variants would havecreated a strong dispersion into variants ofthe product line infrastructure. The advan-tage is that for the second product requiringthe functionality, it is already reusable. Thiscan lead to the superlinear increase that Fig-ure 2a shows.

The second situation, branch-and-unite, iscommon in industrial practice. Here, the or-ganization creates a new version branch for anew variant and then reunifies this branchwith the original infrastructure after releas-ing the product. In this case, the organizationtypically considers only a single product, al-though more experienced organizations alsoconsider requirements for future productswhen determining an adequate implementa-tion. Market Maker successfully pursued thisapproach with its first product line. Themain reason for applying this approach isthat new variants are rather infrequent andthus usually nonoverlapping. This wasn’t thecase with the Merger product line.

Some organizations end up in a bulk situ-ation, which allows larger branching of thereuse infrastructure. Then, at certain inter-vals, the organization reintegrates the prod-

From aneconomicviewpoint,

a leveragedproduct line

adoption entailsa revolution,because thecompany can

address acompletely newmarket segmentwith low costsand few risks.

5 4 I E E E S O F T W A R E J u l y / A u g u s t 2 0 0 2

uct line infrastructure. Larger organizationsusually apply this approach, but it’s best toavoid it as much as possible. It not only leadsto major reintegration efforts (mapping tobig jumps in the economic curve in Figure1b), but it also usually entails significant syn-chronization efforts and quality problems.

The different patterns of product lineevolution we’ve identified have different re-quirements in terms of look-ahead planningand the number of products simultaneouslyintegrated into the product line infrastruc-ture (see Table 1).

Product line planning techniquesHow an organization performs product

line adoption and evolution strongly influ-ences its product line’s overall economic re-sults. However, even if it selects a specificadoption approach, it still must decidewhich products to consider when develop-ing or extending the product line infrastruc-ture, which technical areas to integrate nextinto its product line infrastructure, andwhich requirements reusable assets will di-rectly support. Just as the basic adoption

and evolution steps determine the productline development’s basic economic pattern,answers to these questions help fine-tuneproduct line development and its economiccharacteristics. Restrictions for answeringthe questions depend on the specific adop-tion or evolution situation (see Table 2).

Based on the types of decisions that mustbe made, we can distinguish the followingthree levels of decision making—or scoping—in the context of product line engineering:7

� Product portfolio scoping: Which prod-ucts shall be part of the product line?

� Domain-based scoping: Which technicalareas (domains) provide good opportu-nities for product line reuse?

� Reuse infrastructure scoping: Whichfunctionalities should the reuse infra-structure support?

Affluency in these three scoping techniqueswill help you make the right decision whenadopting and evolving a product line.

Product portfolio scoping helps establisha detailed vision of the products and their

J u l y / A u g u s t 2 0 0 2 I E E E S O F T W A R E 5 5

Table 1Product line adoption and evolution patterns

Situation type Product line planning look-ahead Approach

Adoption Independent Broad portfolio of future systems Big bang Project-integrating Medium-size portfolio of future products Incremental, by functional area or componentReengineering-driven Broad portfolio of future products and Incremental, by functional area or component, or

legacy products big bang, by packaging existing legacy as a wholeLeveraged Broad portfolio of future products Big bang

Evolution Infrastructure-based A small number of products Incremental, by product

Branch-and-unite Single product Incremental, by productBulk A small number of products Incremental, by product group

(perhaps a market segment)

Table 2 Scoping techniques and their relation to product line adoption

Mode of product line Portfolio definition Domain-potential analysis Reuse infrastructure scopingextension

Partial big bang and Very important Recommended, but Recommended to supportevolution by product group mainly for risk analysis architecture definition

By (single) product Not necessary Only needed if the extension Only needed if the extension requires restructuring requires restructuring

By component or Should be performed Key for identifying the next Should be applied to supportfunctional area component for product line architecture definition

extension

requirements. First, you identify the generalmarket potential based on market analyses,taking into account the market structure,potential customers, end-user needs, and thepositioning of competitors. Then, you iden-tify the market segments that fit the com-pany background. This usually happens in aworkshop representing the most relevantstakeholder groups. While coming up withan integrated definition of the product port-folio, it is important to address questionssuch as, “Will the products compete witheach other on the market?” and “Howmuch will it cost to develop these prod-ucts?” It helps even if you just informallyask these questions.

While setting up the Merger product line,Market Maker performed a detailed productportfolio scoping. It analyzed markets andcompetitors, developing a first vision of po-tential market segments and products. Thisprovided the necessary input for technicalfeasibility studies. At the same time, it re-fined the initial vision of the portfolio in sev-eral iterations. This actually led to rather se-vere changes, such as introducing additionalmarket segments in the product line vision.You only need to perform this full-size ap-proach if you develop a new product portfo-lio. Otherwise, just identify changes to theproduct portfolio—technical feasibility andmarket studies are usually not so important.

Based on a product portfolio definition,you can perform domain-based scoping.With this approach, you identify the maintechnical domains relevant to the productline and analyze their reuse potential. Differ-ent technical domains, even within the sameproduct line, can vary considerably in termsof their potential benefit and inherent risksfor product line engineering. Market Maker

applied this approach to domain-potentialanalysis, which is part of the Pulse-Ecomethod,8 for the Merger product line. In thiscase, Market Maker observed variationsfrom “extremely well suited for product linereuse” to “not suited at all.” In particular,domain-based scoping identifies areas wherea reuse investment is particularly meaning-ful, which is especially important if the prod-uct line infrastructure is built in an incre-mental manner (for example, in aproject-integrating adoption situation). Fur-thermore, it can help you decide what func-tionality to integrate next into the productline. In a situation such as the one with theMerger product line, where the organizationbasically built a full product line infrastruc-ture with the first product, this approach istypically used only to inform the develop-ment of potential reuse risks (see Table 2).

Once you identify the key areas for prod-uct line reuse, the important question iswhich functionalities should be madereusable in the context of the specific prod-uct line, which involves reuse infrastructurescoping. The Pulse-Eco approach supportsthis activity in a quantitative manner. Withreuse infrastructure scoping, you developquantitative models to capture the desiredproduct line benefits. You then use thesemodels to identify functionalities that willprovide the highest economic benefit if madereusable. This provides economic input forthe architecture definition. Because of thisfocus on guiding the product line’s imple-mentation, this form of scoping is particu-larly useful when large parts of the productline infrastructure are built for the first time.This is the case if whole product groups ornew functional areas must be integrated intothe product line infrastructure. MarketMaker applied this approach when extend-ing certain functional areas for its MarketMaker product line. In this case, the ap-proach provided valuable input for makingthe most appropriate functionality reusable.7

P roduct line development is about tochange how we perceive and per-form software development. This

transition is similar to the one made fromcraftsmanship to industrial production. Al-though this transition is strongly based onthe increased understanding of software ar-

5 6 I E E E S O F T W A R E J u l y / A u g u s t 2 0 0 2

About the Authors

Klaus Schmid is competence manager for value-based product line development atFraunhofer IESE, where he has been involved in several projects that have transferred productline engineering concepts to industrial environments. He was also a member of the Pulse de-velopment team. His main research interests are the economic aspects of product line develop-ment and approaches for introducing and institutionalizing product line development in indus-try. He received an MS in computer science from the University of Kaiserslautern. Contact himat Fraunhofer Inst. for Experimental Software Eng., Sauerwiesen 6, D-67661 Kaiserslautern,Germany; klaus.schmid@iese.fhg.de.

Martin Verlage is director of the Online Products business area at Market Maker Soft-ware AG. His main software development interests are in the area of component-based soft-ware engineering, especially architecting and testing. He received an MS and PhD in computerscience from the University of Kaiserslautern. He is a member of the Gesellschaft für Infor-matik e.V. Contact him at Market Maker Software GmbH, Karl-Marxstr. 13, D-67655 Kaiser-slautern, Germany; m.verlage@market-maker.de.

chitectures, it is also changing how organiza-tions go about their software business. Duringthe industrial revolution, becoming a moderncompany involved more than just adding anassembly line to the factory floor. Likewise, itwill not be sufficient for organizations toswitch to product line development in an ar-bitrary way. Rather, a company must ade-quately adopt such an approach, and the ap-proach must evolve from the perspective ofpotential economic benefits. To successfullyreap these benefits, companies will have todevelop an in-depth understanding of productline development’s economic implications andhow these implications relate to the possibleproduct line adoption and evolution mecha-nisms.

AcknowledgmentsThe Eureka 2023 Programme, ITEA (Information

Technology for European Advancement) projectsip00004 and 99005, Café (from concepts to applicationin system-family engineering), and ESAPS (EngineeringSoftware Architectures, Processes, and Platforms forSystems-Families) partially supported the work pre-sented in this article.

References1. P. Toft, D. Coleman, and J. Ohta, “A Cooperative Model

for Cross-Divisional Product Development for a SoftwareProduct Line,” Proc. 1st Software Product Line Conf.(SPLC1), Kluwer, Dordrecht, Netherlands, 2000, pp.111–132.

2. J.C. Dager, “Cummin’s Experience in Developing a SoftwareProduct Line Architecture for Real-Time Embedded DieselEngine Controls,” Proc. 1st Software Product Line Conf.(SPLC1), Kluwer, Dordrecht, Netherlands, 2000, pp. 23–46.

3. L. Northrop and P. Clements, Software Product Lines,Addison-Wesley, Reading, Mass., 2001.

4. J. Bayer et al., “PuLSE: A Methodology to Develop Soft-ware Product Lines,” Proc. 5th Symp. Software Reusability(SSR’99), ACM Press, New York, 1999, pp.122–131.

5. J. Bayer et al., “Transitioning Legacy Assets to a ProductLine Architecture,” Proc. 7th European Software Eng.Conf. (ESEC’99), Springer Verlag, New York, 1999, pp.446–463.

6. P. Clements, “On the Importance of Product Line Scop-ing,” Proc. 4th Workshop Product Family Eng. (PFE’4),Springer Verlag, New York, 2001, pp. 70–78.

7. K. Schmid, “Scoping Software Product Lines: An Analysisof an Emerging Technology,” Proc. 1st Software ProductLine Conf. (SPLC1), Kluwer, Dordrecht, Netherlands,2000, pp. 513–532.

8. K. Schmid, “A Comprehensive Product Line Scoping Ap-proach and Its Validation,” Proc. 24th Int’l Conf. Soft-ware Eng. (ICSE’02), ACM Press, New York, 2002, pp.593–603.

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

J u l y / A u g u s t 2 0 0 2 I E E E S O F T W A R E 5 7

The exploding popularity of mobile Internet access, third-generation wirelesscommunication, and wearable and handheld devices have made pervasivecomputing a reality. New mobile computing architectures, algorithms,environments, support services, hardware, and applications are coming onlinefaster than ever. To help you keep pace, the IEEE Computer Society and IEEECommunications Society are proud to announce IEEE Pervasive Computing.

This new quarterly magazine aims to advance mobile and ubiquitouscomputing by bringing together its various disciplines, including peer-reviewedarticles on

• Hardware technologies• Software infrastructure• Real-world sensing and interaction• Human–computer interaction• Security, scalability, and privacy

SUBSCRIBE NOW!

http://computer.org/pervasive

NEW FOR 2002

M. SatyanarayananCarnegie Mellon Univ. and Intel Research Pittsburgh

Associate EICs

the IEEE Computer & Communications Societies present

IEEE PERVASIVE COMPUTING

Editor in Chief

Roy Want, Intel Research; Tim Kindberg, HP Labs; Deborah Estrin, UCLA; Gregory Abowd, Georgia Tech.;

Nigel Davies, Lancaster University and Arizona University