from the editor Editor in Chief: Steve McConnell
■
Construx Software
■
[email protected] The Business of Software Improvement
T
he return on investment in improved software practices is well documented. In 1994, James Herbsleb reported that the average “business value” (roughly the same as ROI) for 13 organizations that took on CMM-SW-based improvement programs was about 5 to 1, with the best organizations realizing returns of 9 to 1.1 In 1995, Neil C. Olsen reported similar returns for organizations that made significant investments in staffing, training, and work environments.2 In 2000, Capers Jones reported that the ROI from process improvement could easily go into double digits (meaning returns greater than 10 to 1).3 A recent analysis by Watts Humphrey found that the ROI for improved software practices could be in the neighborhood of 4 to 1.4 Indirect benefits are even more significant The ROI figures in the published literature are based on operational savings—that is, on reducing development cost per line of code written or per function point delivered. Although these savings are impressive, the greater business benefit might arise from the significant indirect returns that arise from improved software practices. Better software practices improve predictability of costs and schedules, reduce risk of cost and schedule overruns, provide early warning of problems, and support better management. Many organizations that have focused on improving their software practices have reCopyright © 2002 Steven C. McConnell. All Rights Reserved.
ported improvements in predictability similar to the results in Figure 1.5 For a software products company, what is the business value of improving schedule estimation accuracy from plus or minus 100 percent to plus or minus 10 percent? What is the value of being able to make a commitment to customers six to 12 months in advance of a scheduled completion date, with high confidence of delivering on that commitment? For a company that develops custom software, what is the business value of being able to provide a fixed price bid with high confidence that the project will not significantly overrun the bid? For a retail sales organization, what is the value of being able to plan cutover to a new system with pinpoint accuracy? What is the value of knowing with confidence that cutover will occur 1 October, as planned, with little risk of overrunning to 15 November or 1 December? Unlike the operational benefits that most of the industry literature has focused on, these indirect benefits open the door to additional revenue opportunities. These benefits are based not on reducing costs, but on increasing access to additional business. For top decision makers in organizations, these indirect benefits are often more compelling than the direct, operational benefits. Organizational challenge Considering the strong—even compelling—case for improving software practices, it might seem surprising that some organizations have not made a commitment to use best practices. I have recently been thinkJuly/August 2002
IEEE SOFTWARE
5
FROM THE EDITOR
600%
Bookshelf: Warren Keuffel,
[email protected] Construction: Andy Hunt and Dave Thomas, Pragmatic Programmers, {Andy, Dave}@pragmaticprogrammer.com Country Report: Deependra Moitra, Lucent Technologies
[email protected] Design: Martin Fowler, ThoughtWorks,
[email protected] Loyal Opposition: Robert Glass, Computing Trends,
[email protected] Manager: Don Reifer, Reifer Consultants,
[email protected] Quality Time: Jeffrey Voas, Cigital,
[email protected] Actual results as a percentage of estimated results
D E PA R T M E N T E D I T O R S
500% 400% 300%
Predictability before improvement
Predictability after improvement
200% 100% 0% 1
2 SW-CMM level
3
STAFF
Senior Lead Editor Dale C. Strok
[email protected] Group Managing Editor Crystal Chweh Associate Editors Jenny Ferrero, Shani Murray, and Dennis Taylor Staff Editors Scott L. Andresen and Kathy Clark-Fisher Editorial Assistants Rebecca Deuel and Ty Manuel Magazine Assistants Dawn Craig,
[email protected] Pauline Hosillos Art Director Toni Van Buskirk Cover Illustration Dirk Hagner Technical Illustrator Alex Torres Production Assistant Monette Velasco Production Artists Carmen Flores-Garvey and Larry Bauer Executive Director David Hennage Publisher Angela Burgess Assistant Publisher Dick Price Membership/Circulation Marketing Manager Georgann Carter Advertising Assistant Debbie Sims CONTRIBUTING EDITORS
Greg Goth, Keri Schreiner, Joan Taylor, and Margaret Weatherford
Editorial: All submissions are subject to editing for clarity, style, and space. Unless otherwise stated, bylined articles and departments, as well as product and service descriptions, reflect the author’s or firm’s opinion. Inclusion in IEEE Software does not necessarily constitute endorsement by the IEEE or the IEEE Computer Society. To Submit: Send 2 electronic versions (1 word-processed and 1 postscript or PDF) of articles to Magazine Assistant, IEEE Software, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314;
[email protected]. Articles must be original and not exceed 5,400 words including figures and tables, which count for 200 words each.
6
IEEE SOFTWARE
July/August 2002
ing a lot about why best practices aren’t used. Several factors seem to be in play. First, there is a basic technology transfer issue. Many software development best practices have been available for decades, but only a few companies use them, and undergraduate programs have not generally taught these best practices. The scarcity of experienced users of these practices limits the rate at which current users can train new users. Although a person might reasonably assume that the average software organization’s capability is halfway between the worst organization’s capability and the best’s, in reality, the average software organization’s practices are much closer to the worst organization’s practices than the best’s. The result is that software developers who work in average organizations—which includes most developers—have never seen a really wellrun software project, much less a really well-run software organization. The software industry faces the problem of bootstrapping best practices into common usage because of limited current usage of them. A second factor is that recent economic circumstances have prevented software organizations from feeling any strong imperative to switch to better practices.6 Throughout the 1990s, software-related companies rode a technology wave that rewarded companies just for being in the software in-
Figure 1. Project performance compared to estimated performance.5 This example demonstrates different projects in the US Air Force.
dustry. Companies didn’t need to focus on operational improvements because that would have shifted too much focus away from generating revenue. For a time, improved software practices seemed to be more of a distraction than a help. A final factor is that many organizations push responsibility for software development improvement down to the project level. In reviewing the “effort multiplier” factors in the Cocomo II estimation model,7 I was struck by how few of the factors are under the control of an individual project manager. Of the 22 factors Cocomo II uses to fine-tune a project’s base effort estimate, in my judgment only three are typically under the individual project manager’s control: documentation, architecture and risk resolution, and development for reuse. Numerous factors are dictated by the nature of the company’s business—product complexity, required reliability, platform volatility, unprecedentedness of the software, and so on. A company cannot easily change these factors without changing businesses. The remaining factors—staff capability, multisite devel-
FROM THE EDITOR
opment, personnel continuity, process maturity, and so on—can be influenced by the organization but not by individual projects. What can you do? We could hope that upper management, sales, and marketing staff would read every issue of IEEE Software cover to cover or educate themselves about the finer nuances of software development some other way. But this isn’t likely to happen, so leading software practitioners have an ongoing responsibility: the education of nontechnical software project stakeholders. Software practitioners sometimes perceive upper management and other nontechnical staff to be blocking the use of better practices. We complain that they fail to support better practices or even undermine them. I’ve generally found, however, that upper management, sales, marketing, product support, and other personnel are receptive to improved software practices when I take the time to explain those practices to them. Indeed, they are acutely aware of the problems caused by current practices and are eager to
hear how they can help improve software projects. What have you done to educate executives about better software practices? What has worked well for you? I’d love to hear your comments at
[email protected].
References 1. J. Herbsleb et al., Benefits of CMM Based Software Process Improvement: Initial Results, tech. report CMU/SEI-94-TR-13, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 1994. 2. N.C. Olsen, “Survival of the Fastest: Improving Service Velocity,” IEEE Software, vol. 12, no. 5, Sept./Oct. 1995, pp. 28–38. 3. C. Jones, Software Assessments, Benchmarks, and Best Practices, Addison Wesley, Reading, Mass., 2000. 4. W. Humphrey, Winning with Software: An Executive Strategy, Addison Wesley, Reading, Mass., 2001. 5. P.K. Lawlis, R.M. Flowe, and J.B. Thordahl, “A Correlational Study of the CMM and Software Development Performance,” Crosstalk, Sept. 1995. 6. S. McConnell, After the Gold Rush, Microsoft Press, Redmond, Wash., 1999. 7. B. Boehm et al., Software Cost Estimation with Cocomo II, Addison Wesley, Reading, Mass., 2000.
Call for Articles: Industry Experience Reports Experience reports with lessons learned in industry are one way to share successes or failures with others who likely face similar situations. We invite you to report on a technology or process you introduced in your company, analyze its impact, and explore what you would do differently the next time. Articles should be 2,000 to 2,400 words with each illustration counting as 200 words. We also encourage you to submit up to 10 short bullet points on lessons learned and references to related Web sites. Submissions are reviewed by members of our Industry Advisory Board and are subject to editing for style, clarity, and space. For detailed author guidelines, see computer.org/software/genres. htm#IndustryExperienceReport or contact
[email protected]. Submissions are accepted at any time.
EDITOR IN CHIEF: Steve McConnell 10662 Los Vaqueros Circle Los Alamitos, CA 90720-1314
[email protected] EDITOR IN CHIEF EMERITUS: Alan M. Davis, Univ. of Colorado at Colorado Springs A S S O C I AT E E D I T O R S I N C H I E F
Design: Maarten Boasson, Quaerendo Invenietis
[email protected] Construction: Terry Bollinger, Mitre Corp.
[email protected] Requirements: Christof Ebert, Alcatel Telecom
[email protected] Management: Ann Miller, University of Missouri, Rolla
[email protected] Quality: Jeffrey Voas, Cigital
[email protected] Experience Reports: Wolfgang Strigel, Software Productivity Center;
[email protected] EDITORIAL BOARD
Don Bagert, Texas Tech University Richard Fairley, Oregon Graduate Institute Martin Fowler, ThoughtWorks Robert Glass, Computing Trends Andy Hunt, Pragmatic Programmers Warren Keuffel, independent consultant Brian Lawrence, Coyote Valley Software Karen Mackey, Cisco Systems Deependra Moitra, Lucent Technologies, India Don Reifer, Reifer Consultants Suzanne Robertson, Atlantic Systems Guild Dave Thomas, Pragmatic Programmers INDUSTRY ADVISORY BOARD
Robert Cochran, Catalyst Software (chair) Annie Kuntzmann-Combelles, Q-Labs Enrique Draier, PSINet Eric Horvitz, Microsoft Research David Hsiao, Cisco Systems Takaya Ishida, Mitsubishi Electric Corp. Dehua Ju, ASTI Shanghai Donna Kasperson, Science Applications International Pavle Knaflic, Hermes SoftLab Wojtek Kozaczynski, Rational Software Corp. Tomoo Matsubara, Matsubara Consulting Masao Matsumoto, Univ. of Tsukuba Dorothy McKinney, Lockheed Martin Space Systems Nancy Mead, Software Engineering Institute Stephen Mellor, Project Technology Susan Mickel, AgileTV Dave Moore, Vulcan Northwest Melissa Murphy, Sandia National Laboratories Kiyoh Nakamura, Fujitsu Grant Rule, Software Measurement Services Girish Seshagiri, Advanced Information Services Chandra Shekaran, Microsoft Martyn Thomas, Praxis Rob Thomsett, The Thomsett Company John Vu, The Boeing Company Simon Wright, Integrated Chipware Tsuneo Yamaura, Hitachi Software Engineering M A G A Z I N E O P E R AT I O N S C O M M I T T E E
George Cybenko (chair), James H. Aylor, Thomas J. Bergin, Frank Ferrante, Forouzan Golshani, Rajesh Gupta, Steve McConnell, Ken Sakamura, M. Satyanarayanan, Nigel Shadbolt, Munindar P. Singh, Francis Sullivan, James J. Thomas P U B L I C AT I O N S B O A R D
Associate Editor: Wolfgang B. Strigel, Software Productivity Center,
[email protected].
Rangachar Kasturi (chair), Jean Bacon, Mark Christensen, George Cybenko, Gabriella Sannitti di Baja, Lee Giles, Thomas Keefe, Dick Kemmerer, Anand Tripathi
July/August 2002
IEEE SOFTWARE
7
in the news Features Editor: Scott L. Andresen
■
s a n d r e s e n @ c o m p u t e r. o r g
Will the Cyber-UL Concept Take Hold? Greg Goth,
[email protected] O
ne of the most talked-about concepts in network security—the idea of an Underwriters’ Laboratories-type seal of approval for hardware and software— is about to take full flight. Beginning 1 July, new products deemed to be part of systems with US national security implications must be certified under one of several information assurance schemes and tested by independent laboratories working in concert with colleagues from the federal government. However, whether the new standards will usher in an era of consistency and assurance for systems developers and customers is uncertain. While many vendors and security experts applaud the effort as an important—and workable—step in the quest for a more secure Internet, others think the concept is paradoxically simplistic and confusing. “I think the idea of a UL-type approval is very noble, but I think it will be very difficult to implement at this point,” says Marty Lindner, team leader of incident handling at the Software Engineering Institute’s CERT Coordination Center. “Even if you did the UL stuff at the design phase, you’re only certifying that a perfect implementation of the code is believed to be secure. If you take what has been built and test that, you’re testing it based on what we know current vulnerabilities or vectors are. For example, buffer overflow would be a vector. That isn’t to say somebody comes up with a clever way of doing something six months from now that we
Whether the new standards will usher in a new era of consistency is uncertain.
12
IEEE SOFTWARE
July/August 2002
don’t know about. Would this null and void the UL? That’s the more challenging part.” Yet many vendors and the public sector people in charge of the new effort believe it to be a critical step in providing incentive to design and build better products. “In reality, there is no such thing as a secure system,” says Ron Ross, director of the National Information Assurance Partnership, which oversees the new certification program. The NIAP is administered jointly by the National Institute for Standards and Technology (NIST) and the National Security Agency. “What we’re talking about is putting in as much security and getting as much assurance about the system as we can possibly afford, given our respective missions. Everybody’s mission is different, everybody’s perception of how much risk they can handle is different. It’s the product evaluation that gives you more information and confidence about what goes into the system, and that’s a good starting point.” Common Criteria for the common good The linchpin of the new security and assurance effort is product certification under one of two standards: the Common Criteria, a graduated set of assurance levels recognized by 14 nations, or the Federal Information Processing Standard (FIPS)-140. Under the guidelines of a federal policy known as NSTISSP 11, federal purchasers of network components that have national security implications must ensure these products have received certification under either of these standards. Vendors say the 0740-7459/02/$17.00 © 2002 IEEE
IN THE NEWS
Common Criteria’s international scope will strengthen the market. “The Common Criteria is the big one for a couple of reasons,” says Mary Ann Davidson, chief security officer at Oracle. “First of all, it’s an ISO standard, so that carries some weight. Second of all, we used to do country-specific evaluations, which were really expensive. We did ITSEC [the old Western European standard], the Orange Book [the US Defense Department standard], and the Russian criteria. “Through the mutual recognition provision of the Common Criteria, if you get evaluation up to a certain level, everyone says ‘That’s good enough for me,’ as opposed to something developed by a US-specific body, which may have other agendas. This is a true international standard.” Davidson testified before a US House of Representatives Armed Services Committee subcommittee that the mandated security evaluations will provide three main benefits: ■ ■
■
A more secure product, through the steps of the evaluation A secure development process, through the evaluators’ review of product security architecture, functional, design, and test specifications, which ensures a secure development process is repeatable A culture of security, through the completion of multiple evaluations, that makes security part of the corporate “DNA” over the long term
“I like that the Common Criteria forces a secure development process,” Davidson says. “It’s not so much slapping it on at the end as bells and whistles. Jumping through this hoop at the end of your development process just isn’t good enough. “It doesn’t mean you don’t have security vulnerabilities, but you at least have to develop a process where people have to think about security. Another plus is that if the evaluators find a big honking security hole, they won’t give you the seal of approval until you fix it. If you found one of those five years
down the pike, it would be a multiplatform, multirelease problem. That pays for the cost of the evaluation.” An IBM product—a cryptographic security chip—was the first to receive Common Criteria approval in November 2001. Ernie Ovies, product manager for the chip, says the effort will give customers assurance the product does what it says. “When we put this chip on the motherboard, we wanted to make sure our customers knew it had been verified independently. I don’t think it’s lip service. I think it’s going to be with us for a long time.” Ovies estimated the process, from conceiving the chip’s design to receiving certification, took about 18 months. During the design and evaluation phases, IBM and the chip’s manufacturer, Atmel, worked closely with the approved testing lab, CygnaCom. This collaboration might have saved the designers much time and effort. “We developed a security target, defining what part of it had the security function in it,” Ovies says. “This
defines the scope of certification. We thought about including some of the APIs that belong to Microsoft, for example, which the lab said would take years.” Meeting Common Criteria specifications could offer an opportunity for vendors of specialized components entree into larger systems if they cannot afford to develop and evaluate them. “Hardware, particularly for cryptographic mechanisms, is rightly perceived as more secure, so it has a higher assurance level,” Davidson says. “The other nice thing about it is that if you have a card or chip with a cryptographic mechanism, it doesn’t mean the software vendor is off the hook. It means you can plug something into your system that does some of the cryptographic mechanism and get a level of assurance from that.” The Common Criteria’s graduated levels of testing are called Evaluation Assurance Levels. Those deemed most workable for commercial products are Levels One through Four, July/August 2002
IEEE SOFTWARE
13
IN THE NEWS
with the following requirements for reaching each level as stated in Common Criteria documentation: ■ ■
■
■
14
EAL1 (functionally tested) is applicable where some confidence in correct operation is required but the threats to security are not considered to be serious. Its value comes when independent assurance is required to verify due that care was exercised with respect to the protection of personal or similar information. This level provides an evaluation of the Target of Evaluation (TOE) as made available to the consumer, including independent testing against a specification and an examination of the guidance documentation provided. EAL2 (structurally tested) requires the developer’s cooperation in terms of design information and test result delivery but should not demand more effort on the developer’s part than is consistent with good commercial practice. As such, it should not require a substantially increased investment of cost or time. EAL2 is applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of the complete development record. Such a situation can arise when securing legacy systems or where access to the developer is limited. EAL3 (methodically tested and checked) permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices. It is applicable in those circumstances where developers or users require a moderate level of independently assured security and a thorough investigation of the TOE and its development without incurring substantial reengineering costs. An EAL3 evaluation provides an analysis supported by “gray box” testing, selective confirmation of the developer test results, and evidence of a developer search for obvious vulnerIEEE SOFTWARE
July/August 2002
abilities. Development environmental controls and TOE configuration management are also required. EAL4 (methodically designed, tested, and reviewed) permits a developer to maximize assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills, or other resources. EAL4 is the highest level at which it is economically feasible to retrofit an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOE, and are prepared to incur additional securityspecific engineering costs. An EAL4 evaluation provides an analysis supported by the low-level design of the TOE’s modules, and a subset of the implementation. Testing is supported by an independent search for vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.
“It takes about a year to become accredited from the time the lab first submits a letter stating its interest to the NIAP to the time it actually gets its certification.”
NIAP Director Ross says the graduated Common Criteria standards are a significant advance over the previous Orange Book standards. “The Orange Book was fairly rigid in structure and was primarily developed to define requirements for general-purpose operating systems and the development of those systems. The Common Criteria gives us great flexibility to define requirements for security in key technologies like operating systems, databases, firewalls, biometrics, and smart cards.” Currently, there are seven accredited testing labs in the US, three in Canada and Germany, four in the United Kingdom and France, and two in Australia. Ross doesn’t foresee a land rush in labs asking to be certified. “I don’t know how many labs we can sustain. I know NSTISSP 11 is driving a lot of companies to get their product evaluated, so there may be a large ramp-up because of that, but at some point we’ll reach a steady state in supply and demand in terms of the evaluation process,” he says. “Some labs may get in the business and find there’s not enough work. Others may be overwhelmed. A lot of labs, though, could use their NIAP approval as an entree to do some consulting. That’s allowed as long as they don’t evaluate anything they’ve worked on. There are strict guidelines to protect against conflict of interest.” Testing the testers Laboratories must submit to a three-step process to become accredited. Those steps include ■
■ ■
Developing a quality manual that will become the testing bible for the lab, pursuant to ISO standards Completing a proficiency test administered by NIAP assessors An onsite assessment of the lab by examiners working for the National Voluntary Laboratory Accreditation Program, the NIST office responsible for the process
“It takes about a year to become accredited from the time the lab first
IN THE NEWS
submits a letter stating its interest to the NIAP to the time it actually gets its certification,” Ross says. “It takes a long time to get a quality manual together if you don’t have one. The proficiency tests are fairly extensive. And the labs have ongoing business, so a lot of the accreditation process takes time away from normal business.” Ken Kolstad is director of operations for InfoGard Laboratories, in San Luis Obispo, California. InfoGard, which was founded in 1993, was the first lab in the US to become FIPS certified but is still awaiting its Common Criteria accreditation. Kolstad says an early survey of its customers met with lukewarm enthusiasm for Common Criteria evaluations, so InfoGard put its application on hold. A combination of events in the autumn of 2001, however, led those customers to reconsider, and InfoGard is once again in the accreditation process. “Business has been swamped since 9/11,” Kolstad says, explaining the surge in security matters. “Our customer base is suddenly seeing a demand overseas for Common Criteriacertified products. There’s also a big demand for FIPS overseas, so that business has increased substantially.” Booz Allen Hamilton received its laboratory accreditation in March. Steve Rome, recently named lab director, says customer interest in receiving Common Criteria certification is steadily increasing. Joe Mahaffee, who oversees the lab’s NIAP program, says interest is not confined to companies within the US, but it is going to market its niche closer to home, focusing on products under consideration for use by the federal government. Rome believes the future of certification will be centered not on individual products but on systems. “I think the 1 July deadline shows the government is serious about making sure its acquisitions are products we know something about,” he says. “It’s not going to change the world. The attitude of the NSA has always been incremental steps toward adding security, and this is a good first one.
Useful URLs Common Criteria: www.commoncriteria.org CERT Coordination Center: www.cert.org/nav/index_main.html NIST’s Common Criteria: http://csrc.nist.gov/cc NIST’s NVLAP: http://ts.nist.gov/ts/htdocs/210/214/214.htm
When they get into systems certification, it will be another big step.” Ball of confusion? The likelihood that complex systems will eventually require some sort of evaluation and certification might be the biggest area of uncertainty in the entire concept. For example, if a defense contractor clerk sends a federal agency counterpart a spreadsheet breakdown of costs for a vehicle part, will the spreadsheet and email applications on their desktops need certification? If so, under which program? Common Criteria? Or, perhaps, benchmarks released by the nonprofit Center for Internet Security, or an evaluation done under CERT’s Survivable Systems Analysis method? “This will all be incredibly confus-
“Our customer base is suddenly seeing a demand overseas for Common Criteriacertified products. There’s also a big demand for FIPS overseas, so that business has increased substantially.”
ing,” says cryptography expert Bruce Schneier, cofounder of Counterpane Internet Security. “And even worse, the Common Criteria doesn’t even mandate anything. It’s just a framework. I can define a protection scheme of ‘Don’t bother with any security’ and then accurately claim that my system conforms to the Common Criteria.” The NIAP’s Ross concedes there will be confusion and overlap. “The danger is that the average person doesn’t understand the difference between the Common Criteria, the CIS, and CERT,” he says. “These programs do different things. The Common Criteria is a much more technical evaluation. It looks at the internals of these products, the way they’re designed and developed, and the sophistication of the software development techniques that were used to build them. The CIS benchmarks look at what these products do once they’re configured—when they come out of the box. “You can spend a lot of time and effort on a Common Criteria evaluation and if that product is configured improperly or used by people who don’t understand it, you may just as well never have done it. So, I look at these programs as being kind of complementary,” Ross says. “We all know what each of us does, and I think we need to do a better job of telling people. When I go out and talk about the Common Criteria, I should also talk about these other programs and how they relate to ours. Some people might say it gives the other guys a competitive advantage. I say it doesn’t. We’re trying to position ourselves in the marketplace. We all have a niche, and that niche must be made very clear.” July/August 2002
IEEE SOFTWARE
15
manager Editor: Donald J. Reifer
■
Reifer Consultants
■
[email protected] How Good Are Agile Methods?
T
he software industry seems to be embracing yet another change to the way it does business. Because of their emphasis on agility and time-to-market, many programming shops are moving to agile methods. Unlike more traditional approaches, these methods focus on generating early releases of working products using mostly collaborative techniques such as pair programming, refactoring, and having customers work on site as team members. Programmers use these releases— which are working products, not prototypes—to demonstrate features and functions to stakeholders involved in their use, marketing, and support. This article surveys the experience software engineers in a wide range of industries have had in deploying agile methods. The survey Fads come and go, in software engineering as in everything else. Practitioners want to know if agile methods are real or just more hype. To answer that question, I surveyed 10 industry segments using the approach illustrated in Figure 1. I designed the survey to ■ ■ ■
16
IEEE SOFTWARE
Determine what practices early adopters of agile methods are using Assess the scope and conditions governing their use Evaluate the costs and benefits associated with their use
July/August 2002
Table 1 summarizes the demographics of the 32 organizations, representing 28 firms, that responded (several large firms had more than one organization trying to use agile techniques). To transfer a technology, these firms use it on a pilot to prove to themselves that it works, use it on a pathfinder to determine how to integrate the technology with their processes, and then move it onto production projects. As expected, five of the 14 firms that responded are involved in ecommerce and e-business applications. The information these early adopters supplied gives us insight into how to tap the power of these emerging practices. The 14 firms using agile methods cited a laundry list of practices as agile: collective ownership, concurrent development, continuous integration, customer collaboration, daily standup meetings, product demos instead of documents, Extreme Programming (XP), frequent product releases, full stakeholder participation, individuals and interactions, just-in-time requirements, metaphors instead of architectures, nightly product builds, pair programming, rapid application development, refactoring, retrospectives, stories for requirements, team programming, and test-driven development. The database’s 31 projects showed that those firms pursuing agile methods were motivated because they had a poor record of delivering acceptable products to market on time and within budget. Most projects were relatively small (typically fewer than 10 participants) and were pursued as pilots or pathfinders. All projects were in-house de0740-7459/02/$17.00 © 2002 IEEE
MANAGER
velopments (as opposed to contracted out), lasting one year or less and involving low-risk methods. Furthermore, the firms characterized their projects as having stable requirements, established architectures, and a high degree of development flexibility. Products under development were mostly quick-to-market applications (generally Web-based and clientserver oriented). Teams were cohesive and staffed with motivated, experienced performers, most of whom were relatively young and thus perhaps more open to new ideas. Although there was some skepticism, most practitioners involved with agile methods were enthusiastic about the prospects. Although software engineers in the various industries differed on what constituted best agile practices, invariably they agreed that a project’s process must be cyclical and involve builds and increments done in parallel. Furthermore, they said, these projects must involve collaborative organizations that include participation by all stakeholders during development. These projects always included full-time participation by customers or users while the work was being done, rather than relying on reviews, and resulted in working product demos, not documents or prototypes that are often thrown away. Differences arose in the actual form of the process used, such as spiral,
IEEE Software/XP Agile Universe
Interest
Literature search 1
Firm up survey goals Goals 2
Findings
Develop survey instrument Questionnaire
Mailing lists
Projects 1 3 2 15 1 0 4 5 31
Develop findings Information from questionnaires and interviews Interviews
Figure 1. Survey approach showing steps taken to access industry response to XP methods.
incremental, or similar methods, as well as on how informal or flexible the process should be. The engineers in different industries disagreed on who the stakeholders were and how deep their involvement should be. Opinions differed as well on what practices fell under the category of agile methods—Extreme Programming, rapid application development, team programming, and so on. The biggest surprise was that most responding organizations were at Level 2 or greater under the Software Capability Maturity Model (see Table 2). For the most part, these advanced organizations were willing to try something new because they were having problems meeting delivery expecta-
Year first tried 2001 2000 2000 2000 2000 2001 2000 2000
tions even though their pro-cesses were mature. Also, most of the organizations trying agile methods were modifying their processes to incorporate those that worked into their way of doing business. The results so far In summarizing the results either measured or observed by these early adopter organizations, seven of the 14 organizations that used agile methods captured hard cost, productivity, and quality data. Five of these had benchmarks that they could use for comparisons. Hard data included ■
■
Characteristics of responding firms Industry Aerospace Computer Consultants E-business Researchers Scientific Software Telecom Total
4
3 Canvas broad spectrum of industry
Table 1 Firms using agile methods 1 2 1 5 1 0 2 2 14
5 Publish results and conclusions
State of progress Pathfinder Pilot Pilot Production Pilot Pilot Production Production Average
Average size (KESLOC)* 23 32 25 33 12 N/A 25 42 31.8
*KESLOC = thousand equivalent source lines of code computed using formulas that normalize reused and modified code in terms of new lines of code (see Barry Boehm’s discussion of the mathematical approach involved).1
■
■
Productivity improvement: 15 to 23 percent average gain based on published industry benchmarks.2 Cost reduction: 5 to 7 percent on average based on published industry benchmarks.2 Time-to-market compression: 25 to 50 percent less time compared to previous projects in participating firms. Quality improvement: Five firms had data showing that their defect rates were on par with their other projects when products or applications were released.
These numbers normalize contributions of all participating firms independent of their CMM levels. In addition, the seven organizations that didn’t capture hard data used soft data to justify their move to July/August 2002
IEEE SOFTWARE
17
MANAGER
they must be considered separately. For example, as we all well know, decreasing cost by accepting reduced quality can accelerate schedule but result in lost market share. And increasing productivity could increase a company’s cost as software staff is busily producing the wrong product. In such cases, rework increases as does schedule.1
Survey Summary and Recommendations Questions asked and responses What do users think agile methods are? ■ Devised list of variants and invariants based on user perceptions, not on a search. Who’s using agile methods? ■ Small, in-house teams developing software for quick-to-market applications. Do they provide added value? ■ Although reports from the field were positive, the sample was too small to make any broad conclusions. What are the issues plaguing users? ■ Most issues revolve around classical problems in managing technology change.
I
n the “Survey summary and recommendations” sidebar, I’ve organized my findings by the questions the survey sought to answer. Recommendations are aimed at addressing key issues identified by early adopters. I hope this initial report from the field on agile methods prompts others to put their experiences in the public domain. I am currently preparing a paper detailing this survey’s findings for presentation at XP Agile Universe. If you’re interested in this topic but cannot attend, contact me for a copy of that paper.
Recommendations ■ Clearly define what “agile methods” means. ■ Build a business case for agile methods using “hard” data to justify the move. ■ When adopting agile methods, recognize that you are changing the way
your organization does business. ■ Provide those moving to agile methods with support for making the transition.
Support should include startup guidelines, “how to” checklists, and measurement wizards; a knowledge base of past experience accessible by all; and education and training, including distance education and self-study courses.
agile methods. Most used some form of survey to capture stakeholder opinions, and all used recruitment, morale, and other intangibles to build a case for trying and retaining agile methods. All argued passionately for continued use of agile methods based on qualitative factors, and all pressed for help in resolving the issues that revolved around technology transfer. In any case, the jury is still out because the sample size (14 organizations and 31 projects) is just too small to derive any firm conclusions. In ad-
dition, the “hard” data gathered might be tainted by the Hawthorne effect common in efforts of this type, which relates to the small sample size. (These were small, low-risk projects staffed by select teams under controlled situations, so the results might neither scale to larger projects nor reflect higher-risk situations.) We will just have to see if agile methods can scale to address larger efforts. The percentages I’ve cited can be deceptive. Although cost, schedule, productivity, and quality are related,
References 1. D.J. Reifer, Making the Software Business Care: Improvements by the Numbers, Addison-Wesley, Reading, Mass., 2002. 2. D.J. Reifer, “Let the Numbers Do the Talking,” Crosstalk, Mar. 2002, pp. 4–8.
Donald J. Reifer is president of Reifer Consultants and a visiting associate at the Center for Software Engineering at the University of Southern California. Contact him at
[email protected]. He’d like to hear from you.
Table 2 Software CMM ratings of responding firms Industry Aerospace Computer Consultants E-business Researchers Scientific Software Telecom Totals
18
Number of agile projects 1 3 2 15 1 0 4 5 31
IEEE SOFTWARE
July/August 2002
Level 1
Level 2
Level 3
Level 4 1
1 1
1
Level 5
No Rating
3 6 1 2 12
2 2 6
8
2 4
1 1
8
requirements Editor: Suzanne Robertson
■
The Atlantic Systems Guild
■
[email protected] Eureka! Why Analysts Should Invent Requirements James Robertson
We often hear the complaint “The customer didn’t tell us the project requirements.” Here, James Robertson takes the opposite view and encourages requirements analysts to create more valuable and competitive products by inventing requirements rather than expecting customers to ask for them.—Suzanne Robertson
T
he traditional job of the requirements analyst is to talk to users, find out how they work, ask them what they want, specify what is required, and have a system built. But something’s missing: this activity doesn’t improve anything. We need a step in the requirements activity called “invent something better.” This column is about how to go about doing that.
Reinventing your role Software designer Dewys Lasdon puts it simply: “Our job is to give the client, on time and on cost, not what he wants, but what he never dreamed he wanted; and when he gets it, he recognizes it as something he wanted all the time.” (Read more about Lasdon in Tom Peters’, The Circle of Innovation: You Can’t Shrink from Greatness, Knopf, 1997.) This applies to you, even if you’re working on yet another inventory control system or the 18th incarnation of your management information system. To be successful in today’s software world, you must add the title “inventor” to your portfolio. Let me explain why, and suggest how you might become an inventor. The user interface you look at whenever you use your personal computer is an invention, but when the team at Xerox PARC was inventing it, nobody was asking for it. What 20
IEEE SOFTWARE
July/August 2002
about your mobile telephone? Before it was invented, people didn’t go around saying, “I really wish I had a telephone that I could carry in my pocket.” What about the cool personal digital assistant you bought recently? Before you knew it existed, did you think to ask for one? But now that you have it, and a mobile telephone, could you get along without them? Paradoxically, we must avoid becoming victims of our customers. Our task is not to provide every button and pull-down menu enhancement that they ask for, but to invent a completely new way of working—one that will thrill and amaze them. Once users see it, they will wonder how they got along before. If you confine yourself to making marginal improvements, someone else will make the inspirational leap and take your customer along for the ride. A new list of requirements In the IT world, there are guides about what we should invent and how to go about inventing something better for the client. Consider the following partial list as potential requirements. At least one of them represents an area where you can invent something to make a difference to your organization. Service is a requirement In today’s commoditized world, quality of service separates one business from an0740-7459/02/$17.00 © 2002 IEEE
REQUIREMENTS
other. If all banks charge the same fee, you will give your business to the one that provides the best service. Federal Express started asking people to pay US $21 for what formerly cost 21 cents. Enough people valued guaranteed next-day service to make FedEx the second largest airline (in number of airplanes) in the US. Service means understanding what your customers will value if you give it to them. In the UK, unlike continental Europe, we drive on the righthand side of the road. To overcome this obstacle for continental vacations, Hertz offers “Le Swap.” You rent a car in England, drive it to Folkestone, and put it on Le Shuttle train to France (the price of Le Shuttle ticket is included in the rental cost). On the French side of the tunnel at Calais, you drive to the Hertz depot, and they give you a French car with left-hand drive. On the way back, you reverse the process. Hertz realized that this is a service people would value. Someone at Hertz invented a better way of renting a car. What service could your organization provide that your customers would value? For example, can you do something for them that they currently do for themselves? Can you provide a service that will make your customer value you over your competitors? Some products are ideas Post-it notes are an idea. The inventor had the idea that bits of paper with removable adhesive would be useful. When they saw Post-its, everybody in the 3M offices wanted them. The rest is history. eBay is an idea. Meg Whitman had the simple idea of putting auctions on the Internet. eBay registered 10 million users in its first five years—not bad for an idea that in retrospect is pretty simple. Napster took less than one year to get to one million users, and estimates of music downloads from it today run into the tens of billions. I know that the product was free, but look at the idea: peer-to-peer networking by strangers. Abstract a little. Can you come up with something else from these ideas or better
still, make one of your own? How does your organization handle its ideas? Does it have a way of hearing them? How could you listen harder and avoid missing the next eBay idea? Information is a requirement Put another way, it is a requirement to provide information. Today’s consumers and customers are far better informed than they were a generation ago. If an organization refuses to provide information, it can look forward to a departing customer. Your customers already have lots of information, and they expect more of it, which means that you must invent a way to give them access to your company’s information. Do you provide all your rates and prices? Do you also provide your competitors’ rates? Do you provide all the information your customer needs to make a buying decision? What is it that your organization knows, or could know, that your customers would also like to know? In other words, invent some way of getting more information to the outside world. Customers want choices Your customers want more choices to suit their own particular requirements. Charles Schwab (www.schwab. com) lets customers make choices online or via telephone that were formerly made only by brokers and certified financial advisors. Dell and Gateway encourage cus-
Your customers already have lots of information, and they expect more of it, which means that you must invent a way to give them access to your company’s information.
tomers to configure their own computers (and place their own orders). There is a competitive advantage to providing better choices than the other guy. Do you provide your customers with all the information you have so that they can make their own choice? Do you show them all their choices? The National Association of Realtors (www.realtor.com) offers the choice of over 1.5 million properties on its Web site and gets 30 million hits per month. People also want to do more of the work themselves. FedEx, DHL, and UPS spent millions on systems that let customers participate in the delivery process. Visit FedEx’s online tracking sytem (www.fedex.com/us/tracking), and look at the options it provides. People are happy to do more of the work themselves, and if they’re doing the work themselves, they are far less likely to complain about the service. People do not want to sit back and be told how they should deal with your company. They want to decide for themselves. Do your customers participate in your business? If not, invent some way to make your customers part of it. The real origin of the use case is outside your organization If you want to invent a better product, start by thinking outside the box. I find it dismaying when I talk to analysts who only draw use case models in which the actor is someone who works inside the organization. This approach prevents the analyst from understanding the real business problem. Imagine that we’re dealing with a business use case. That is, it starts outside your organization. Now, what happened before the internal actor became involved? Who was doing what to trigger this business use case? Progressive Insurance (www. progressive.com) has a fleet of Immediate Response Vehicles. If you have an accident (and you are insured with Progressive), an IRV comes to the accident scene. The driver is a trained insurance assessor who can immediately assess the damage to July/August 2002
IEEE SOFTWARE
21
REQUIREMENTS
Recommended Reading C. Christensen, The Innovator’s Dilemma, Harvard Business School Press, Cambridge, Mass., 1997. N. Gershenfeld, When Things Start to Think, Henry Holt & Co., New York, 1999. T. Kelley, The Art of Innovation: Lessons in Creativity from IDEO, America’s Leading Design Firm, Doubleday, New York, 2000. T. Peters, The Circle of Innovation, Alfred A. Knopf, New York, 1997. J. Robertson and S. Robertson, Mastering the Requirements Process, Addison-Wesley, Reading Mass., 1999. M. Schrage, Serious Play, Harvard Business School Press, Cambridge, Mass., 2000.
your car and (if you choose) pay your claim and give you a check on the spot. In other words, Progressive has
realized that the real origin of the business use case is the accident, not the filling out of the claim, and decidedly not the actor in the insurance company who starts to enter the claim into a computer system. For any use case, consider the following: what was the person (there is usually a person involved, and it could well be your customer) doing when the business use case started? A use case does not start when the bank customer reaches the ATM and inserts a card. What was the customer doing before that? Why did he or she come to the ATM? If it was for money, what was that money for? Could you (the bank) invent something that would help the customer avoid having to go to the ATM at all? And if he or she does reach the ATM, what else can you do? Add more time to a prepaid cell phone? Make a transfer to pay for an eBay purchase? Offer to send details of your special mortgage rates or new savings accounts? You could even put up an ATM screen that says, “If you
would you like us to (e)mail you information on our new brokerage service, touch here.” Amazon.com has links all over the Web on other peoples’ sites. It recognizes that the origin of the book-buying business use case is when a reader decides that he or she wants a book. Amazon’s Associates program provides an incentive for sites to add a “Buy it from Amazon.com” link. This captures the real actor at the real point of origin. I don’t know how much revenue Amazon’s Associates links generate, but I imagine it is a healthy chunk of their earnings. What can you do? Look at any use case. Now, back away from the computer system, back past the employee who operates the computer, back past the incoming paper or telephone call to the employee, and go back to the outside world where real people (probably your customers) live. What are those people doing at the time of initiating the business use case? Can you do it for them? Can you invent something that will make it easier for them to use your organization’s resources? If you know what they are doing, then you can do it for them. When you invent something that gets to the use case’s true origin, you capture—and keep—a loyal customer.
W
hat sets you apart from your competitors? The difference is invention. That spark, that idea, that moment of human thought that makes the difference between a great product or service and one that is merely adequate. We might not need any more software, but we will certainly buy it if it is appealing and innovative—that is, if it promises to add some compelling new value to the way we work, live, travel, and go about our lives. In other words, we will buy inventions.
James Robertson is a founder and principal of the Atlantic Systems Guild. He provides organizations with training and consulting on how they can leverage their requirements process to build better, more innovative software products. Contact him at
[email protected].
22
IEEE SOFTWARE
July/August 2002
focus
guest editors’ introduction
Initiating Software Product Lines John D. McGregor, Clemson University and Luminary Software Linda M. Northrop, Software Engineering Institute Salah Jarrad, Panasonic Wireless Design Center Klaus Pohl, University of Essen
li Whitney revolutionized the manufacturing of rifles using interchangeable parts. Henry Ford did the same for automobiles, integrating the idea of interchangeable parts and an assembly line. A growing number of software development organizations are adopting approaches that emphasize proactive reuse, interchangeable components, and multiproduct planning cycles to construct high-quality products faster and cheaper. Standard methods, referred to as software product line or software family practices, have developed around these approaches. This special issue focuses on the technical, managerial, and organizational activities related to introducing these practices.
E
24
IEEE SOFTWARE
July/August 2002
0740-7459/02/$17.00 © 2002 IEEE
Cumulative costs of products (US dollars)
Introducing product line practices into an organization typically involves many levels of the enterprise. Organizations have employed two main types of strategies when introducing software product lines: heavyweight and lightweight. With heavyweight strategies, a product line’s initial product costs significantly more than an initial product in single-system development (see Figure 1). However, after approximately three products, the product line has lower cumulative costs. In contrast, lightweight strategies require minimal upfront investment. The initial cost falls somewhere between the single-product cost and heavyweight cost (see Figure 1). The tradeoff for lower upfront costs is that it takes longer to reduce cumulative costs. Early adopters of these two approaches have been rewarded with significant improvement in productivity, time to market, and product costs. Companies such as Cummins, which took a heavyweight approach, and Nokia, with its lightweight approach, have reported successful experiences.1
600,000
Figure 1. A comparison of heavyweight and lightweight strategies and single-system development.
Single product Heavyweight Lightweight
500,000 400,000 300,000 200,000 100,000 o 1
2 3 4 Number of products
5
The keys to success Three ideas are common to most successful product line efforts: exploring commonality among products to proactively reuse software artifacts, encouraging architecturecentric development, and having a twotiered organizational structure. Exploring commonalities and variabilities Software developers have been interested in building multiple systems with similar requirements for years. In 1976, David Parnas stated, “We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members.”2 This definition focuses on a set of programs’ common properties, regardless of how you implement the programs. More recently, the Software Engineering Institute’s Product Line Practices initiative has defined a software product line as “a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.”3 This definition focuses on the common properties of products and the common technologies used to implement programs. A product line’s scope is specified such that the products have a high degree of commonality. A product line organization realizes economically significant reuse, which so many earlier reuse approaches failed to deliver, by exploiting this commonality to achieve economies of scope. Product lines use proactive approaches that plan the use of assets in multiple products rather than ad hoc approaches that reuse assets only if they happen to be suitable. July/August 2002
IEEE SOFTWARE
25
Besides the commonalities, products in a product line also vary in their features. To allow for controlled variation, analysts and software architects introduce so-called variation points on each level of abstraction (for example, on the level of the requirements, architecture, and runtime system). As experienced in the major European product line initiatives, Esaps (www.esi.es/esaps) and Café (www.esi.es/café), product line variability has two major dimensions: a time dimension, which deals with the evolution of software artifacts over time, and a space dimension, which deals with software’s different behaviors (for example, a software artifact used in multiple products might need to exhibit different behaviors).4 The degree to which an organization must create a comprehensive, robust set of assets before delivering its first product varies from one initiation method to another. In heavyweight initiation schemes, the organization creates or acquires assets to satisfy the specifications in the product line architecture before creating the products. In lightweight initiation schemes, the organization mines assets from existing products and products currently in production. Architecture-centric development The software architecture is key to a software product line’s success. An architecture that specifies all of the products identifies and communicates the regions of commonality and points of variation. A product team creates the product-specific architectures by specializing the product line architecture to achieve specific functional and quality requirements. The software architecture creation process includes techniques that let architects make design choices that enhance certain qualities of the system and degrade others. The architects design the product line architecture to support the range of values for each quality attribute necessary to represent all products. Developers then construct each product by selecting reusable assets that result in the appropriate quality values. The degree to which an organization must formally define an inclusive, complete software architecture before delivering its first product varies from one approach to another. For example, reference architectures in specific domains can provide both a 26
IEEE SOFTWARE
July/August 2002
starting point for the product line architecture and support for early decisions about the first product if the product line architecture is not sufficiently complete. Two-tiered organization An organization using product line practices is structured to facilitate two fundamental roles: development of reusable assets and development of products that use those assets. The first role includes all products while the second focuses on a single product. Organizations accomplish this division of responsibility in a variety of ways—some have teams dedicated to each role and others use the same people for both. Product line practices affect many parts of an organization. Roles such as product planning or marketing will change from a singleproduct focus to working with a set of related products and can take advantage of the product line approach. Planning a set of products at one time as opposed to individually over time produces economies of scale. The degree to which organizational changes must occur before delivering the first product varies. In heavyweight approaches, the organization assigns specific teams to produce assets such as the architecture and components. In lightweight approaches, the organization might create the first few products as usual and then use mining efforts to extract product line assets after the fact. Issue overview In the Point/Counterpoint department, Paul Clements of the Software Engineering Institute argues the advantages of thorough planning and design before constructing products. Charles Kreuger of BigLever Software counters this view by supporting an approach that develops reusable assets while products are being constructed. The first two articles survey the major initiatives in developing product line practices. In “SEI’s Software Product Line Tenets,” Linda M. Northrop describes a comprehensive set of practices that have evolved from the experience of initiating product lines in a variety of industrial domains and government agencies. In “Software Product Families in Europe: The Esaps & Café Projects,” Frank van der Linden summarizes the challenges faced and lessons learned when introducing software product lines in European companies.
About the Authors The next two articles address general issues related to introducing a product line. “The Economic Impact of Product Line Adoption and Evolution,” by Klaus Schmid and Martin Verlage, describes decisions that must be made when initiating a product line and presents economic arguments that help guide the decision-making process. “Feature-Oriented Product Line Engineering,” by Kyo C. Kang, Jaejoon Lee, and Patrick Donohoe, describes the central role that product features can play in product line development. Using feature-oriented domain analysis and the feature-oriented reuse method, the authors illustrate how to use features as the guiding principle behind product development. The final two articles report on industrial experiences gained when introducing a software product line. “Modeling and Using Product Line Variability in Automotive Systems,” by Steffen Thiel and Andreas Hein, describes the pervasiveness of variability when operating a product line. The article presents a study of the systematic planning and variability management that occurs in a product line to achieve strategic reuse. “Developing Mobile Browsers in a Product Line,” by Ari Jaaksi, provides a look inside an organization as it evolves to meet the demands for faster, cheaper development. The article provides a valuable set of lessons that the team learned during the evolution of the organization.
John D. McGregor is an associate professor of computer science at Clemson University and a partner in Luminary Software, a software engineering consulting firm. His research interests are software product lines and component-based software engineering. He received his PhD from Vanderbilt University. Contact him at the Dept. of Computer Science, Clemson University, Clemson, SC 29634;
[email protected].
Linda M. Northrop is director of the Product Line Systems Program at the Software
Engineering Institute. Her research interests include software architecture, software product lines, and the predictable assembly of certifiable components. She received her undergraduate degree from LeMoyne College and her graduate degrees from the State University of New York and the University of Rochester. Contact her at the Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, PA 15213-3890;
[email protected]. Salah Jarrad is vice president of Software and Systems at MMCD, Panasonic Wireless De-
sign Center. Contact him at MMCD, Panasonic Wireless Design Center, 1226 NorthBrook Pkwy, Suwanee, GA 30024;
[email protected].
Klaus Pohl is full professor for software systems engineering and the director of the Institute for Computer Science at the University of Essen. His research interests include scenariocentered requirements management and requirements-driven software product line development. He received a degree in computer science from FH Karlsruhe, Germany, a degree in information systems from the Univ. Konstanz, Germany, and a PhD in computer science from the Technical University of Aachen, Germany. Contact him at Software Systems Eng., Univ. of Essen, Altendorferstr. 97-101,45117, Essen, Germany;
[email protected].
References 1. P. Donohoe, Software Product Lines: Experience and Research Directions, Kluwer, Dordrecht, Netherlands, 2000. 2. D.L. Parnas, “On the Design and Development of Program Families,” IEEE Trans. Software Eng., vol. SE2, no. 1, Mar. 1976, pp. 1–9. 3. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, Boston, 2001. 4. J. Bosch et al., “Variability Issues in Software Product Lines,” Proc. 4th Int’l Workshop Product Family Eng. (PFE-4), Lecture Notes in Computer Science, Springer Verlag, Berlin, 2001, pp. 13–21.
Check it out A Free CD-ROM with Your CG&A Subscription This supplemental CD will contain peer-reviewed multimedia content such as 2D and 3D simulations and animations, standalone interactive tutorials, and demonstrations of application examples. The CD will not duplicate any current electronic or print content. Subscribe today! http://computer.org/cga IEE E AN D
A PPLIC AT IO N S
point Being Proactive Pays Off Paul Clements
One of the most exciting aspects of software product lines is how they put technical and enterprise issues on the same page.
28
IEEE SOFTWARE
July/August 2002
oftware product lines represent a paradigm on the rise in software engineering that comes with true order-ofmagnitude improvements in cost, schedule, and quality. As the field grows and matures, case studies are becoming more plentiful and beneficial. Books, papers, conferences, workshops, and special issues of magazines such as this one provide ideas that can inspire us. For me, one of the most exciting aspects of software product lines is how they put technical and enterprise issues on the same page. This is best demonstrated when a software product line capability helps a savvy organization quickly enter and thrive in a whole new market area. CelsiusTech Systems, a Swedish seller of shipboard commandand-control systems, recognized that a new market lay nearby in ground-based air defense systems—guns mounted on moving platforms. On the first day CelsiusTech decided to enter that market, 40 percent of its entry system was complete because of its roots in a ship system product line.1 Cummins, an American manu-
S
facturer of diesel engines, recognized that a vast untapped market in industrial diesel engines lay right next to its product line of (software-intensive) automotive and truck diesel engines. The industrial diesel domain encompasses an extraordinary range of applications, from ski lifts to rock crushers, but no single application is a high-volume proposition. Without the capability to field a product variant quickly and easily, the market is not attractive. But with that capability—that is, with a product line capability—an organization can score a coup, which is precisely what Cummins did.2 The key to this enterprise-level strategic positioning is understanding the scope of the product line. A product line’s scope states what systems an organization would be willing to build as part of its product line and what systems it would not. In other words, it defines what’s in and what’s out. Defining a product line’s scope is like drawing a doughnut in the space of all possible systems. The doughnut’s center represents the set of systems that the organization Continued on page 30 0740-7459/02/$17.00 © 2002 IEEE
point
continued from page 28
could build, and would be willing to build, under the auspices of its product line capability. Systems outside the doughnut represent those that are out of scope, that the product line is not equipped to handle well. Systems on the doughnut itself could be handled with some effort, but require case-by-case disposition as they arise. In a product line of office automation systems, a product with a conference room scheduler would be in, but one with a flight simulator would be out. One with a specialized intranet search engine might be in if it could be produced in a reasonable time and if there were strategic reasons for doing so (such as the likelihood that future customers would want a similar product). Explicitly scoping the product line lets us examine regions in the neighborhood that are underrepresented by actual products in the marketplace, make small extensions to the product
line, and move quickly to fill the gap. In short, a consciously preplanned, proactive product line scope helps organizations take charge of their own fate. The scope feeds other product line artifacts; the requirements, architecture, and components all take their cues for the variabilities they need to provide from the scope statement.
to make them apply to product line engineering. The growing body of literature and case studies also provides invaluable guidance for practitioners who want to adopt the approach. Together, we are taking product lines into the realm where organizations can be proactive about the systems they are prepared to build.
P
References
utting an organization on the same strategic page requires vision, strong management, technical competence, process discipline, and no small amount of dedicated leadership. But the payoffs can be spectacular, as companies large and small in all domains are discovering. Help is available. The Software Engineering Institute’s product line practice framework (www.sei.cmu.edu/plp) describes how to extend software engineering and managerial practices from one-system-at-a-time product building
continued from page 29
engineering and software product line engineering. They let organizations reuse their existing software, tools, people, organization charts, and processes. The variety of adoption models lets organizations select one or more strategies that best meet their business objectives, engineering realities, and management styles. The three prominent adoption models are proactive, reactive, and extractive. The proactive approach to software product lines is like the waterfall approach to conventional software. You analyze, architect, design, and implement all product variations on the foreseeable horizon up front. This 30
IEEE SOFTWARE
July/August 2002
1. L. Brownsword and P. Clements, A Case Study in Successful Product Line Development, tech. report SEI/CMU 96-TR-016, Carnegie Mellon Univ., Software Eng. Inst., Pittsburgh, 1996. 2. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, AddisonWesley Longman, Reading, Mass., 2001.
Paul Clements is a senior member of the technical staff at the Software Engineering Institute, Carnegie Mellon University. His technical interests include product line systems, software architecture, software design, and product line practice. He received his PhD in computer sciences from the University of Texas at Austin. Contact him at SEI, 4500 Fifth Ave., Pittsburgh, PA 15213;
[email protected].
counterpoint
approach might suit organizations that can predict their product line requirements well into the future and that have the time and resources for a long waterfall development cycle. The reactive approach is like the spiral or extreme programming approach to conventional software. You analyze, architect, design, and implement one or several product variations on each development spiral. This approach works in situations where you cannot predict the requirements for product variations well in advance or where organizations must maintain aggressive production schedules with few additional resources during the
transition to a product line approach. The extractive approach reuses one or more existing software products for the product line’s initial baseline. To be an effective choice, the extractive approach requires lightweight software product line technology and techniques that can reuse existing software without much reengineering. This approach is very effective for an organization that wants to quickly transition from conventional to software product line engineering. The combination of lightweight technologies and techniques along with the variety of adoption models offers a dramatic reduction in the adoption
counterpoint Eliminating the Adoption Barrier Charles Krueger
tories of successful software product line deployments often read like epic adventures. In the end, there is triumph of inspirational proportions, but along the journey there is risk, hardship, sacrifice, heroes, antagonists, love lost, love found, and fortuitous events of both happy and tragic consequences. For example, for Cummins to achieve its impressive software product line successes, it stopped all product deployments for six months while it rearchitected its engine control software, support technology, organizational charts, and processes. Imagine the consequences if, after an extended production shutdown, unanticipated events had led to project failure. Although these epics make for great, inspiring reading, many software organizations need to operate on a more predictable and less dramatic story line. They can’t afford to slow or stop production for six months to reinvent themselves, even if the potential payoff is huge. For most organizations, the risks, timetables, efforts, and costs experienced by the pioneers represent an adoption barrier to software product line practice.
S
0740-7459/02/$17.00 © 2002 IEEE
For software product lines to become part of mainstream software engineering culture, organizations need software product line strategies with low adoption barriers. They need low-risk strategies that afford small upfront effort, incremental transition from current practices, and rapid return on investment. Several organizations have recognized this need and are successfully creating technology and techniques that lower the adoption barrier to software product lines (see www.biglever.com, www.esi.es/Projects/Reuse/projects.htm, and www.iese.fhg.de/Business_Areas/ Product_Line_Development). These new approaches offer two things not found in the epic proactive software product line approaches. The first is lightweight technologies and techniques that specifically support software product line engineering. The second is a variety of adoption models for establishing and operating a software product line practice. Lightweight software product line technologies and techniques minimize the paradigm shift between conventional software
Although these epics make for great, inspiring reading, many software organizations need to operate on a more predictable and less dramatic story line.
Continued on page 30 July/August 2002
IEEE SOFTWARE
29
point
continued from page 28
could build, and would be willing to build, under the auspices of its product line capability. Systems outside the doughnut represent those that are out of scope, that the product line is not equipped to handle well. Systems on the doughnut itself could be handled with some effort, but require case-by-case disposition as they arise. In a product line of office automation systems, a product with a conference room scheduler would be in, but one with a flight simulator would be out. One with a specialized intranet search engine might be in if it could be produced in a reasonable time and if there were strategic reasons for doing so (such as the likelihood that future customers would want a similar product). Explicitly scoping the product line lets us examine regions in the neighborhood that are underrepresented by actual products in the marketplace, make small extensions to the product
line, and move quickly to fill the gap. In short, a consciously preplanned, proactive product line scope helps organizations take charge of their own fate. The scope feeds other product line artifacts; the requirements, architecture, and components all take their cues for the variabilities they need to provide from the scope statement.
to make them apply to product line engineering. The growing body of literature and case studies also provides invaluable guidance for practitioners who want to adopt the approach. Together, we are taking product lines into the realm where organizations can be proactive about the systems they are prepared to build.
P
References
utting an organization on the same strategic page requires vision, strong management, technical competence, process discipline, and no small amount of dedicated leadership. But the payoffs can be spectacular, as companies large and small in all domains are discovering. Help is available. The Software Engineering Institute’s product line practice framework (www.sei.cmu.edu/plp) describes how to extend software engineering and managerial practices from one-system-at-a-time product building
continued from page 29
engineering and software product line engineering. They let organizations reuse their existing software, tools, people, organization charts, and processes. The variety of adoption models lets organizations select one or more strategies that best meet their business objectives, engineering realities, and management styles. The three prominent adoption models are proactive, reactive, and extractive. The proactive approach to software product lines is like the waterfall approach to conventional software. You analyze, architect, design, and implement all product variations on the foreseeable horizon up front. This 30
IEEE SOFTWARE
July/August 2002
1. L. Brownsword and P. Clements, A Case Study in Successful Product Line Development, tech. report SEI/CMU 96-TR-016, Carnegie Mellon Univ., Software Eng. Inst., Pittsburgh, 1996. 2. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, AddisonWesley Longman, Reading, Mass., 2001.
Paul Clements is a senior member of the technical staff at the Software Engineering Institute, Carnegie Mellon University. His technical interests include product line systems, software architecture, software design, and product line practice. He received his PhD in computer sciences from the University of Texas at Austin. Contact him at SEI, 4500 Fifth Ave., Pittsburgh, PA 15213;
[email protected].
counterpoint
approach might suit organizations that can predict their product line requirements well into the future and that have the time and resources for a long waterfall development cycle. The reactive approach is like the spiral or extreme programming approach to conventional software. You analyze, architect, design, and implement one or several product variations on each development spiral. This approach works in situations where you cannot predict the requirements for product variations well in advance or where organizations must maintain aggressive production schedules with few additional resources during the
transition to a product line approach. The extractive approach reuses one or more existing software products for the product line’s initial baseline. To be an effective choice, the extractive approach requires lightweight software product line technology and techniques that can reuse existing software without much reengineering. This approach is very effective for an organization that wants to quickly transition from conventional to software product line engineering. The combination of lightweight technologies and techniques along with the variety of adoption models offers a dramatic reduction in the adoption
barrier. For example, Salion, an enterprise software producer, needed to transition from conventional one-of-a-kind software engineering to software product line engineering.1 Based on time and cost constraints, an epic proactive transition was out of the question. So, it adopted lightweight software product line technology from BigLever Software,2 an extractive approach to reuse existing conventional product as the baseline for the product line and a reactive approach to implement unanticipated requirements from new customers. While maintaining its aggressive production schedule, Salion transitioned to a live software product line in about four person-months of total effort, which was less than 5 percent of the time required to build the conventional product used as the product line’s baseline.
I
t has been said that “the right point of view is worth 20 points of IQ.” That is certainly the approach we need to take in moving software product line practice from
the realm of epic adventures to mainstream software practice. New advances in technology and methodology show that, by taking the right viewpoint, the adoption barrier disappears.
References 1. P. Clements and L. Northrop, Salion, Inc.: A Case Study in Successful Product Line Practice, tech. report, Carnegie Mellon Univ., Software Eng. Inst. to appear in 2002. 2. C. Krueger, “Easing the Transition to Software Mass Customization,” Proc. 4th Int’l Workshop Software Product Family Eng., Springer Verlag, New York, 2001, pp. 282–293.
Charles Krueger is the founder and CEO of BigLever Software. His technical interests are in technologies and techniques that bring software product lines into mainstream software engineering practice. He received his PhD in computer science from Carnegie Mellon University. Contact him at BigLever Software, 10500 Laurel Hill Cove, Austin, TX 78730;
[email protected].
Paul Responds
Charles Responds
Krueger’s identification of adoption models—proactive, reactive, extractive—is a first-rate contribution to this field, as is his missionary work for low-cost adoption methods. But with the zeal of some missionaries, I think he’s a little quick to spot the devil lurking about—in this case, hiding in the proactive approach. First, the proactive approach does not require a halt in production. At Cummins, the new product line manager called a halt because the projects that were under way were running in different directions and would clearly not be able to deliver the many products to which the company had already committed. Turning the whole organization to the product line approach was its salvation, because it was on the road to major failure anyway. Here, the risk was in not taking decisive action. Second, proactive adoption does not mean unanimous simultaneous adoption. In our book Software Product Lines: Practices and Patterns (Addison-Wesley, 2001), Linda Northrop and I write extensively about how an organization can launch pilot projects to introduce the concepts, demonstrate measurable benefit, iron out process and organizational details, and let other projects climb aboard when ready. Finally, we read that in the proactive world “all product variations on the foreseeable horizon are analyzed, architected, designed, and implemented up front.” Well, when would you not take the foreseeable horizon into account? Granted, in some environments, your foreseeable horizon might not be very broad. But shouldn’t you still plan for the variations you know are coming? If you don’t, your architecture (among other things) might simply not be up to the task. If your next customer wants a version of your basic product that runs 10 times as fast and supports 100 times the users, good luck achieving that by just iterating on your current inventory. Being proactive simply means actively gathering what you know about your customers and your application area and using that knowledge as much as you can to plan for the future and, in some cases, to manage that future to your advantage.
One of the insightful segments in the Clements and Northrop book on software product lines is a sidebar entitled E Pluribus Unum (Latin for “out of many, one”). There, Clements skillfully articulates how organizations who have mastered software product line engineering think of themselves as building a singular software “system”—the product line—rather than as building multiple software products. What this suggests to me is that all the issues that the software industry has explored for engineering singular one-ofa-kind software systems will be explored again for engineering singular software product lines. The argument for or against proactive approaches to software product line engineering resembles the arguments for or against waterfall approaches to one-of-a-kind software engineering. Rather than be dogmatic about any particular approach, I prefer to keep a collection of approaches available in my toolbox. After exploring business conditions, knowledge of the domain, clarity and stability of the customer requirements, architectural complexity, likelihood of building the “wrong” system, available time and resources, and so forth, I can go to the toolbox to select the tool that best solves the problem. The issue here, I believe, is whether proactive should be the only tool in my toolbox rather than whether it’s a good approach. For Cummins, proactive was likely the most effective approach. For Salion, a combination of extractive and reactive approaches fit their business conditions perfectly. For the mainstream software engineering community to embrace software product lines, the adoption barrier must be much lower than that experienced by the early pioneers. Providing lightweight technology and techniques plus a variety of adoption models will go a long way toward enabling the entire software industry to capitalize on the order-of-magnitude improvements offered by software product lines.
July/August 2002
IEEE SOFTWARE
31
focus
initiating software product lines
SEI’s Software Product Line Tenets Linda M. Northrop, Software Engineering Institute
ompanies, such as Hewlett-Packard, Nokia, and Motorola, are finding that using a product line approach for software can yield remarkable quantitative improvements in productivity, time to market, product quality, and customer satisfaction. This practice of building sets of related systems from common assets can also efficiently satisfy the current demand for mass customization of software. Product lines are, of course, not new in manufacturing. Boeing, Ford, Dell, and even
C Software product lines are rapidly emerging as a viable and important software development paradigm. The Software Engineering Institute defines basic concepts and the activities and practices that ensure success. The author shares how-to’s, success stories, and lessons learned while defining and applying this approach. 32
IEEE SOFTWARE
McDonald’s develop product lines. But software product lines are a relatively new concept. They are rapidly emerging as a practical and important software development paradigm. A product line succeeds because companies can exploit their software products’ commonalities to achieve economies of production. The Software Engineering Institute’s (SEI) work has confirmed the benefits of pursuing this approach; it also found that doing so is both a technical and business decision. To succeed with software product lines, an organization must alter its technical practices, management practices, organizational structure and personnel, and business approach. Software product lines A software product line is a set of software-intensive systems that share a com-
July/August 2002
mon, managed feature set satisfying a particular market segment’s specific needs or mission and that are developed from a common set of core assets in a prescribed way. Core assets form the basis for the software product line. Core assets often include, but are not limited to, the architecture, reusable software components, domain models, requirements statements, documentation and specifications, performance models, schedules, budgets, test plans, test cases, work plans, and process descriptions. The architecture is key among the collection of core assets. Each system in the product line is a product in its own right. However, it is created by taking applicable components from a common asset base, tailoring them through preplanned variation mechanisms, adding new components as necessary, and assembling the collection according to the rules of a common, product-line-wide architecture. 0740-7459/02/$17.00 © 2002 IEEE
Every software product line has a predefined guide or plan that specifies the exact product-building approach. Development is a generic term used to describe how core assets (and products) come to fruition. Software enters an organization in one of three ways: the organization builds it (from scratch or by mining legacy software), purchases it (largely unchanged, off the shelf), or commissions it (contracts with someone else to develop it especially for them). So, the term development might actually involve building, acquiring, purchasing, retrofitting earlier work, or any combination of these options. Some practitioners use a different set of terms to convey essentially the same meaning. They might refer to a product line as a product family,1 to the core asset set as a platform,2 or to the products of the software product line as customizations instead of products. Others use the terms domain and product line interchangeably. We distinguish between the two. A domain is a specialized body of knowledge, an area of expertise, or a collection of related functionality. Core asset development is often referred to as domain engineering, and product development as application engineering. Regardless of terminology, software product line practice involves strategic, largegrained reuse, which means that software product lines are as much about business practices as they are about technical practices. Using a common set of assets to build products requires planning, investment, and strategic thinking that looks beyond a single product. Reuse, as a software strategy for decreasing development costs and improving quality, is not a new idea. However, past reuse agendas, which focused on reusing relatively small pieces of code or opportunistically cloning code designed for one system for use in another, have not been profitable. In a software product line approach, reuse is planned, enabled, and enforced. The reusable asset base includes artifacts in software development that are costly to develop from scratch. Essential activities Numerous organizations in various industries have reaped significant benefits using a software product line approach for their systems. Despite this diversity, we at the SEI believe we have distilled universal and essential
Product line development
Core asset development
Product development
Management
Figure 1. Essential software product line activities and practices. product line At the highest level of generality are three es- activities.
sential and highly iterative activities that blend technology and business practices. Fielding a product line involves core asset development and product development using the core assets under the aegis of technical and organizational management. Figure 1 illustrates this triad of essential activities. The rotating arrows in Figure 1 indicate not only that companies use core assets to develop products but also that revisions of existing core assets or even new core assets might (and most often do) evolve out of product development. In some contexts, organizations mine existing products for generic assets—perhaps a requirements specification, an architecture, or software components—that they then migrate into the product line’s asset base. In other cases, the core assets might be developed or procured for later use in product production. There is a strong feedback loop between the core assets and the products. Core assets are refreshed as organizations develop new products. They then track asset use, and the results are fed back to the asset development activity. Technical and organizational managers manage this process carefully at all levels. Core asset development The core asset development activity’s goal is to establish a production capability July/August 2002
IEEE SOFTWARE
33
■
Core assessment development
Production line scope Core assets Production plan
Product constraints Styles, patterns, frameworks Production constraints Production strategy Inventory of pre-existing assets
■
Core asset development ■
Management
■
Figure 2. Core asset development.
for products. Figure 2 illustrates this activity, its outputs, and necessary inputs. This activity, like its counterparts, is iterative. Its inputs and outputs affect each other. For example, slightly expanding the product line scope (an output) might admit new classes of systems to examine as possible sources of legacy assets (an input). Inputs to core asset development include ■
Figure 3. Product development.
Product constraints: Commonalities and variations among the products that will constitute the product line, including their behavioral features.
Product development
Requirements Product line scope Core assets Product development
Production plan + +
Products Management
34
IEEE SOFTWARE
July/August 2002
Styles, patterns, and frameworks: Relevant architectural building blocks that architects can apply during architecture definition toward meeting the product and production constraints. Production constraints: Commercial, military, or company-specific standards and requirements that apply to the products in the product line. Production strategy: The overall approach for realizing the core assets. This can be top down (starting with a set of core assets and spinning products off of them), bottom up (starting with a set of products and generalizing their components to produce the product line assets), or some of both. Inventory of preexisting assets: Software and organizational assets available at the outset of the product line effort that can be included in the asset base.
Besides core assets, the outputs of core asset development include a product line scope, which describes the products that will constitute the product line or that the product line is capable of including, and a production plan, which describes how products are produced from the core assets. All three outputs must be present to ensure the production capability of a software product line. Product development In addition to the three outputs, product development activity depends on the requirements for individual products. Figure 3 illustrates these relationships; the rotating arrows indicate iteration. For example, the existence and availability of a particular product might affect a subsequent product’s requirements. Creating products can have a strong feedback effect on the product line scope, core assets, production plan, and even the requirements for specific products. Product development can vary greatly depending on the assets, production plan, and organizational context. Management Management at the technical (or project) and organizational (or enterprise) levels must be strongly committed to the software product line effort for the product line’s success. Technical management oversees the core asset development and the product develop-
ment activities, ensuring that the groups building core assets and those building products engage in the required activities, follow the processes defined for the product line, and collect data sufficient to track progress. Organizational management must set in place the proper organizational structure that makes sense for the enterprise and ensure that organizational units receive the right resources (for example, well-trained personnel) in sufficient amounts. Organizational management determines a funding model that ensures core asset evolution and then provides the funds accordingly. It also orchestrates the technical activities in and iterations between core asset development and product development. Management should ensure that these operations and the product line effort’s communication paths are documented in an operational concept. Management mitigates risks at the organizational level that threaten a product line’s success. Product lines tend to engender different relationships with an organization’s customers and suppliers, and these new relationships must be introduced, nurtured, and strengthened. Management must create an adoption plan that describes the organization’s desired state (that is, routinely producing products in the product lines) and a strategy for achieving that state. Finally, someone should be designated as the product line manager and either act as or find and empower a product line champion. This champion must be a strong, visionary leader who can keep the organization squarely pointed toward the product line goals, especially when the going gets rough in the early stages. Software product line practice areas Beneath the surface of the three essential activities are 29 practice areas that our experience shows must be mastered for a successful product line. A practice area is a body of work or a collection of activities. They help make the three essential activities more achievable by defining activities that are smaller and more tractable than a broad imperative such as “Develop core assets.” Most practice areas describe activities that are essential for any successful software development, not just software product lines. However, in a product line context, each
takes on particular significance or must be carried out in a unique way. For example, configuration management, an identified practice area, is important for any software development effort. However, configuration management for product lines is more complex than for single systems, those developed one at a time versus using a product line approach. The core assets constitute a configuration that needs to be managed; each product in the product line constitutes a configuration that must be managed, and managing all of these configurations must be coordinated under a single process. We have created a conceptual framework for software product line practice that provides a comprehensive description of each practice area as it relates specifically to software product line operations and the common risks associated with each.3,4 We categorize each practice area as software engineering, technical management, or organizational management, according to the skills required to carry it out.
Software engineering practice areas are those that are necessary for applying the appropriate technology to create and evolve core assets and products.
Software engineering practice areas Software engineering practice areas are those that are necessary for applying the appropriate technology to create and evolve core assets and products. They are ■ ■ ■ ■ ■ ■ ■ ■ ■
Architecture Definition Architecture Evaluation Component Development COTS Utilization Mining Existing Assets Requirements Engineering Software System Integration Testing Understanding Relevant Domains
Figure 4 provides a sketch of how they relate to each other. Domain understanding feeds requirements, which drive an architecture, which specifies components. Components can be made in-house, bought on the open market, mined from legacy assets, or commissioned under contract. This choice depends on the availability of in-house talent and resources, open-market components, an exploitable legacy base, and able contractors. Their existence (or nonexistence) can affect the product line’s requirements and architecture. Once available, the components must July/August 2002
IEEE SOFTWARE
35
Figure 4. Relationship among software engineering practice areas.
Domain understanding
Understanding Relevant Domains
feeds Requirements drives Architecture Definition Architecture Evaluation
Architecture
specifies components Make/Buy/Mine/Commission analysis
Make
Buy
Mine
Commission
Component Development
COTS Utilization
Mining Existing Assets
(Developing an acquisition strategy)
Existing talent
Organizational policy Market availability
Software System Integration
Legacy base Components
be integrated and, along with the system, be tested. This description is a quick trip through an iterative growth cycle. It greatly oversimplifies reality but shows a good approximation of how software engineering practice areas come into play. Technical management practice areas Technical management practices are those that are necessary for engineering the creation and evolution of core assets and products. Technical management’s practice areas are ■ ■ ■ ■ ■ ■ ■ ■
Configuration Management Data Collection, Metrics, and Tracking Make/Buy/Mine/Commission Analysis Process Definition Scoping Technical Planning Technical Risk Management Tool Support
These practices directly support and pave the way for software development activities. Scoping and Technical Planning delineate what should be built and how. Data Collection, Metrics, and Tracking and Technical Risk Management establish “health” measures for the software development efforts 36
IEEE SOFTWARE
July/August 2002
Testing
and help assess their current conditions. Make/Buy/Mine/Commission Analysis, Tool Support, Configuration Management, and Process Definition all contribute to a smooth development effort. Organizational management practice areas Organizational management practices are those that are necessary for orchestrating the entire product line effort. Practice areas in organizational management are ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Building a Business Case Customer Interface Management Developing an Acquisition Strategy Funding Launching and Institutionalizing Market Analysis Operations Organizational Planning Organizational Risk Management Structuring the Organization Technology Forecasting Training
Some practices, such as Building a Business Case and Funding, are required to initiate a product line approach and emphasize the business investment and planning required. Others, such as Operations and Or-
ganizational Risk Management, apply to ongoing product line efforts. Launching and Institutionalizing is about an organization’s systematic growth from a given state to a higher state of product line sophistication. It is actually a context-sensitive threading of other organizational management practice areas. The sheer number of organizational management practice areas gives testament to the significant business dimension of software product lines. Product line practice patterns Although laying out all essential activities and practice areas has proven very helpful, an organization must still determine how to put the practice areas into play. One approach is to follow a divide-and-conquer strategy. Fortunately, although no two situations are alike, we have found that similar situations repeatedly occur. It is because of these similarities that product line practice patterns have emerged.3 Patterns are a way of expressing common contexts and problem and solution pairs. They have been used effectively in many disciplines including architecture, economics, social science, and software design. For software product line practice patterns, the context is the organizational situation. The problem is part of the software product line effort that must be accomplished. The solution is the grouping of practice areas and their relations to address the problem for that context. Following the lead of the design patterns community, we created a pattern template and have used it to define the 22 patterns (including variants) listed in Table 1. These patterns, some of which have relationships between them, span various ranges of abstraction, scale, and purpose. For example, Factory is a composite pattern that consists of eight other patterns, so it describes the entire product line organization. Lessons learned defining the approach The SEI’s understanding of what is involved in a software product line approach has evolved considerably. Our ideas have matured, and no doubt will continue to mature, owing to our direct involvement in software product line efforts, our discussions with others involved in product line work, and our own (sometimes heated) internal debates.
Table 1 Product line practice patterns Pattern
Assembly Line Cold Start Curriculum Each Asset Essentials Coverage Factory In Motion Monitor Process Product Builder Product Parts
What to Build
Variants
Warm Start Each Asset Apprentice Evolve Each Asset
Process Improvement Product Generation Green Field Barren Field Plowed Field Analysis Forced March
Formulating the basic concepts Our original thoughts were based on a domain engineering, followed by an application engineering mind-set, which had an unrealistic waterfall life-cycle mentality. We rarely encountered an organization that had the luxury of developing assets from scratch and then building products from those assets. In almost all situations, some products or assets already existed, and the asset base grew out of those. In any case, each asset continues to evolve over time. Core asset development and product development activities are highly iterative, and that iteration must be carefully managed. This latter insight led us to include management as the third essential activity. In our original definition of software product lines, we did not prescribe how products were constructed. After much debate, we concluded that our definition was insufficiently discriminating. We added the clause “that are developed from a common set of core assets in a prescribed way.” Expanding the definition proved to be an epiphany that led to other refinements. We agree with others5 that the product line architecture plays a special role among the core assets by providing the structural prescription for products in the product lines. However, we discovered that the product line architecture alone does not provide enough July/August 2002
IEEE SOFTWARE
37
Product Line Success Stories There is a great benefit in learning how others approached their move to product lines. We have documented four complete product line case studies.1 Our earliest report was a study of CelsiusTech Systems, a Swedish defense contractor supplying international navies with shipboard command and control systems.2 Using a product line approach, they have delivered more than 50 systems from essentially the same asset base. In doing so, they have shortened delivery schedules by years, allowed a smaller staff to produce more systems, and achieved software reuse levels into the 90 percent range. Cummins, the world’s largest manufacturer of commercial diesel engines with more than 50 horsepower, made a bold move to a software product line approach for its engine control software. The results are most compelling. It previously took Cummins a year or more to bring new engine software to the test lab, but now it takes less than a week. Moreover, the product line approach lets the company augment its command of the automotive diesel engine market. It has expanded vigorously into the industrial diesel market, where just 20 software builds provide the basis for more than a thousand separate engine products; it now offers a mix of feature and platform flexibility that otherwise would require almost four times their current staff. The US National Reconnaissance Office took advantage of commonality and built a product line asset base for its groundbased spacecraft command and control software. They commissioned Raytheon to build their asset base, the Control Channel Toolkit. The new product line’s first system has seen, among other benefits, a 50-percent decrease in overall cost and schedule, and nearly tenfold reduction in development personnel and defects. Successful product lines are also possible in small organizations, such as in Market Maker Software of Kaiserslautern, Germany, producer of Europe’s most popular stock market software. Market Maker adopted a product line approach to
produce an Internet version of its software. This version, which they market to other companies, must integrate with other databases and content-producing software (which run on a variety of computing platforms and servers); satisfy human-user performance requirements; and be tailored to show the exact kind of data, in exactly the kind of charts, in exactly the kind of form each customer’s Web site requires. Using their software product line, it takes Market Maker as few as three days to install a tailored system for individual customers. Others have also reported success stories: Alcatel,3 Hewlett Packard,4 Philips,5 the Boeing Company,6 and Robert Bosch GmBh7 presented their experiences at the 2000 Software Product Line Conference (SPLC1 00).
References 1. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, Boston, 2001. 2. L. Brownsword and P. Clements, A Case Study in Successful Product Line Development, tech. report CMU/SEI-96-TR-016, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 1996; www.sei.cmu.edu/publications/ documents/96.reports/96.tr.016.html. 3. M. Coriat et al., “The SPLIT Method,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 147–166. 4. P. Toft et al., “A Cooperative Model for Cross-Divisional Product Development for a Software Product Line,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 111–132. 5. P. America et al., “CoPAM: A Component-Oriented Platform Architecting Method Family for Product Family Engineering,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 167–180. 6. D. Sharp, “Component-Based Product Line Development of Avionics Software,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 353–369. 7. S. Thiel and F. Peruzzi, “Starting a Product Line Approach for an Envisioned Market,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 495–512.
prescription. Each core asset should have an associated attached process that specifies how to use it in product development. These attached processes get folded into what becomes the product production plan. Another debate in the product line community was whether releases and versions of single products constituted a product line. Although others still disagree, we decided that they did not. We agree with Jan Bosch that a product line evolves over time and space.5 Settling on the practice area set Being true to our technical backgrounds, we began with a greater proportion of prac38
IEEE SOFTWARE
July/August 2002
tice areas in software engineering than in management. However, we quickly recognized the need for more management practices, and the set of technical and organizational management practices grew. For some time, we maintained that Domain Analysis was a practice area, meaning that a formal domain analysis was required. However, CelsiusTech and other organizations with successful product lines did not conduct a domain analysis. However, they did have solid knowledge of their domains, which helped them make good product decisions. What was essential was understanding relevant domains, so that became a practice area.
Also, early on we considered understanding relevant domains, requirements engineering, and scoping as one practice area. However, we gradually found that although there were dependencies among the three, they involved different activities and players. Determining the practice areas’ contents Experts draft individual practice area descriptions for the framework, so overlap continues to require monitoring. In reality, there are no clear boundaries between the practice areas; we could slice the effort in many different ways, but a balance, however arbitrary in some cases, is important to assert. Some of our early ideas about software product lines were simply naïve. For example, we originally believed that the organizational structure must have two units: one to build the core assets and one to build products. Colleagues from Nokia and Hewlett-Packard, among others, pointed out that all product line development can be concentrated in a single unit, where each member is expected to be a jack-of-alltrades in the product line, doing domain engineering tasks or application engineering tasks when appropriate. Later, Bosch described four separate organizational models.5 Beyond practice areas The practice area framework was (and is) an encyclopedia of software product lines,4 but we fell short in offering concrete guidance on using that encyclopedia. There were many fits and starts about how and what to provide. We settled on product line practice patterns and have been encouraged by early positive feedback. We have also been encouraged to connect the product line practice framework with software development standards, most especially with the Capability Maturity Model framework. We have compared the framework with the Capability Maturity Model Integration for Systems Engineering/Software Engineering V1.1.4. Although process discipline is essential for product line success, there is not one-to-one mapping between these standards. The process areas in the CMMI framework do not address 12 product line practice areas, and even for those that do cover similar subjects, the em-
phasis is different. More fundamentally, the product line practice framework is not a maturity model. Lessons learned applying the approach Besides the explicit changes in our approach, we learned these lessons: ■
■
■
■
■
■
■
Organizations can benefit tremendously through product lines.
Product line business practices cannot be affected without explicit management commitment and involvement. We have seen too many product line efforts fail for lack of sponsorship and commitment from someone above the technical ranks. Organization size doesn’t matter. Our original experiences were all with large organizations. Many small organizations, such as Market Maker (see the “Product Line Success Stories” sidebar), have demonstrated that they can succeed with product lines. Reuse has a bad reputation in many organizations owing to the failure of earlier small-grained reuse initiatives. It takes highly proactive advocacy and marketing to introduce software product lines into such cultures. Organizations often want an evaluation of their product line efforts. (This led us to develop the Product Line Technical Probe, a diagnostic method for examining an organization’s readiness to adopt, or ability to succeed with, a software product line approach, described elsewhere.)3 The lack of either an architecture focus or architecture talent can kill an otherwise promising product line effort. Process discipline is critical. Processes can be according to the CMM framework, Extreme Programming, or some Agile method, but they must be defined and followed. On one of our collaborations, we mistakenly introduced process improvement and software product lines simultaneously. The product line effort languished. The community needs more quantitative data to support software product line adoption. Moving to product lines is an investment, and decision makers want hard numbers in their business cases. July/August 2002
IEEE SOFTWARE
39
How to Reach Us Writers For detailed information on submitting articles, write for our Editorial Guidelines (software@ computer.org) or access http://computer.org/ software/author.htm. Letters to the Editor Send letters to Editor, IEEE Software 10662 Los Vaqueros Circle Los Alamitos, CA 90720
[email protected] Please provide an email address or daytime phone number with your letter.
S
oftware product lines epitomize the concept of strategic, planned reuse, and differ from the opportunistic reuse of the past that has been largely discredited. Organizations can benefit tremendously through product lines. A number of global software trends make product lines more doable today than in the past, such as rapidly maturing and increasingly sophisticated software development technologies, mature object technology, vendor-available components with tremendous functional capability, increased realization of the importance of architecture, universal recognition of the need for process discipline, product line case studies, workshops, and education programs. Nevertheless, there are needs in many areas. For example, better product line tool support and more supportive business models and data are imperative. However, the industry trend toward software product lines seems indisputable. The SEI believes that software product lines are here to stay.
Acknowledgments
Subscribe Visit http://computer.org/subscribe.
Many people have contributed to the SEI’s product line work, both inside and outside the SEI. Although Paul Clements and I have led the charge, the entire SEI Product Line Practice Initiative team has contributed to the basic concept evolution, to the focusing of the key ideas, and to the work’s conceptual integrity. Much of the information that the SEI has assimilated has come from software community members who have built software product lines, sometimes with our help. They have graciously participated in our conference and software product line workshops and shared with us their knowledge and experience.
Subscription Change of Address Send change-of-address requests for magazine subscriptions to
[email protected]. Be sure to specify IEEE Software.
References
On the Web Access http://computer.org/software for information about IEEE Software.
Membership Change of Address Send change-of-address requests for IEEE and Computer Society membership to
[email protected]. Missing or Damaged Copies If you are missing an issue or you received a damaged copy, contact
[email protected]. Reprints of Articles For price information or to order reprints, send email to
[email protected] or fax +1 714 821 4010. Reprint Permission To obtain permission to reprint an article, contact William Hagen, IEEE Copyrights and Trademarks Manager, at
[email protected].
1. P. America et al., “CoPAM: A Component-Oriented Platform Architecting Method Family for Product Family Engineering,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 167–180. 2. P. Toft et al., “A Cooperative Model for Cross-Divisional Product Development for a Software Product Line,” Proc. 1st Software Product Line Conf. (SPLC1 00), Kluwer Academic Publishers, Boston, 2000, pp. 111–132. 3. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, Boston, 2001. 4. P. Clements and L. Northrop, “A Framework for Software Product Line Practice,” 2000; www.sei.cmu.edu/plp/framework.html. 5. J. Bosch, Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, Addison-Wesley, Boston, 2000.
Linda M. Northrop’s biography appears on page 27.
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
40
IEEE SOFTWARE
July/August 2002
focus
initiating software product lines
Software Product Families in Europe: The Esaps & Café Projects Frank van der Linden, Philips Medical Systems
he main drive for Europe’s industrial-cooperation projects on product family development is business need. The participating companies have realized that only through significant reuse could they increase software productivity, and for reuse to happen, it had to be planned and organized.
T European companies have been cooperating for seven years on product family development. The size and scale of the projects have increased dramatically, and funding now comes through the ITEA framework from local governments. Here is an overview of these projects, their results, and how they differ from other product line efforts. 0740-7459/02/$17.00 © 2002 IEEE
In 1995, the small Esprit project ARES (Architectural Reasoning for Embedded Systems)1 began with a focus on architecture support for developing product families. Near the end of ARES, another Esprit consortium started investigating family development processes in the Praise project. When ARES finished, both ARES and Praise forces began to cooperate on a larger scale within the Information Technology for European Advancement framework (www. itea-office.org). Established in mid-1999, ITEA is an industrydriven, multinational strategic research and development program designed to promote the development of embedded and distributed software and related software engineering technologies. Because ITEA projects last for at most two years, there has been a sequence of such efforts. The first, Esaps (Engineering Software Architectures, Processes, and Platforms for System Families), recently finished, and the second, Café (Concepts to Application in System-Family Engineering), has just begun. The research in Café will extend the
Esaps results by providing methods and processes that support independent life cycles of products and of systems using these products. In short, Café will tie the separate concepts of Esaps into a unified whole covering a product family’s entire life cycle. A follow-up project is already being planned. Companies in the ITEA projects (see Figure 1) are working on a variety of embedded systems, including medical imaging, mobile phones, flight control, utility control, supervision and management, financial services, and car electronics. Because they are still introducing product family practices in their organizations, not all conclusions are definite. The five major partners—Philips, Nokia, Siemens, Thales, and Telvent—introduced product family development in software organizations of more than 100 people. Several other companies and research institutions are involved in parts of the program: they introduce family development on smaller scales, focus on special topics, or act as consultants for other companies. July/August 2002
IEEE SOFTWARE
41
Norway Asea Brown Boveri, A Information on Communication Tech. Norway, C
The Netherlands
Sweden
Philips, AEC Software Engineering Research Centre, E Environmental and Energy Study Inst., E Univ. of Groningen, EC
. Ericsson, E Combitech, E Blekinge Inst. of Tech., E
United Kingdom
Finland
Imperial College, A
Nokia, AEC Helsinki Univ. of Technology, E Univ. of Helsinki, C
France Thales, PEC Alcatel, E French Nat'l Inst. for Research in Computer Science and Control, EC Ivorium, EC Softeam, C
Germany Siemens, EC Bosch, PEC Market Maker, EC Fraunhofer Inst. for Experimental Software Eng., EC Univ. of Essen, EC
Spain Telvent, EC Unión Fenosa, E Polytechnic Univ. of Madrid, AEC European Software Inst., PEC
Italy
Austria
Omega Generation, C Inst. of Information Research, C
Vienna Univ. of Technology, AC Johannes Kepler Univ. of Linz, C
A: P: E: C:
ARES Praise Esaps Café
Figure 1. The companies and countries involved in ITEA projects. Each partner’s name is followed by a code denoting its involvement in the projects.
Product line, product family, product population You might notice that we use the term product family or system family where others use product line. This is because the US and European communities in this field worked independently until a first meeting in Las Navas, Spain, in November 1996. By that time, two sets of terminology were already established. Moreover, certain European companies use product line to indicate something different—a set of related, commercial products that appear similar to users but often are built with different technologies. For example, product lines in consumer electronics include televisions, VCRs, DVD players, audio receivers, CD players, audio amplifiers, and so on. These products have similar housings and user interfaces (for instance, buttons, dials, and LEDs), but their internal technical details might differ a lot. We use product family to describe a collection of products 42
IEEE SOFTWARE
July/August 2002
that are based on the same technology—for instance, a collection of TVs based on the same software architecture. Often products in the same product line are in different product families, and vice versa. Because good communication between the architects and the marketing department is important in product family development, using product family or system family is easier. Rob van Ommering introduced the technical term product population.2 This term denotes a collection of related systems based on a similar technology but with many differences. For instance, the complete set of consumer electronics products mentioned earlier can form a product population. Family development concerns Setting up product family development means taking several concerns into account. The acronym BAPO, introduced by Henk Obbink of Phillips Research, covers the main issues. BAPO stands for
Selection and construction
■ ■ ■ ■
Business: the way the resulting products make a profit Architecture: the technology needed to build the system Process: responsibilities and dependencies during software development Organization: the organization in which the software is developed
Single systems
Reuse level multiple system families
Decisions made for one of these concerns affect them all. Thus, such decisions must be made carefully. System family development started with the implicit idea that a good family architecture might benefit business. In other words, by dealing with diversity in a managed way, we might serve a larger, more predictable market segment. If we are going to initiate an architecture design and implementation, we need a process to determine all the actions needed. We also need an organization to implement the whole. Then we can address the business consequences in light of the results obtained. The two main technical goals of the sequence of projects are to improve in both development paradigms and reuse level. In the case of our projects, the main architectural improvements that will influence the designs are developments in the computing platforms, distribution and communication, the development environments, and the soft-
Component base Platform
Family: varying products
Figure 2. Component-based platform as the basis for a family. Reusable assets might include interfaces, designs, patterns, requirements, supporting infrastructure, and test cases.
ware development paradigms. In practice, this means that we move toward component-based development—that is, varying products based on a single component-based platform (see Figure 2). The platform is the basis of the product family. Developers design, build, and test from a selection of the platform’s assets. If they cannot obtain the assets they need from the platform itself, they must develop them. Later, the developer might integrate these new, single-product assets into the platform. The idea is simple but the practice is hard, and this relates to all BAPO concerns. The graph in Figure 3 shows the reuse-level terms introduced by Ivar Jacobson, Martin Griss, and Patrik Jonsson.3 To move from bottom to top along the y axis means that an increasing number
Domainpervasive reuse Architected reuse Managed reuse Planned reuse Informal code reuse No reuse Structured programming
Object-oriented development
Component-based development
Development paradigms
Agent-based development ??
Figure 3. Moving from single systems to multiple system families. July/August 2002
IEEE SOFTWARE
43
Table 1 Project topics Business
ARES
Praise
Architecture
Process
Dealing with variation Architecture description Resource management qualities Domain-specific architectures Family architecture Development tools
Recovery from legacy systems
Esaps
Scoping
Domain analysis Aspect analysis Family requirements Architecture glossary Commonality and variability Reference architecture Platform and components
Café
Business and market analysis Scoping Family development transition and adoption
Requirements engineering Heterogeneous platforms COTS use Design for quality Development tool support Test modeling Validation
Family development practices Variability and commonality Traceability between assets Architectural decisions Architecture assessment Architecture recovery Domain analysis Aspect analysis Family development process frameworks Requirements modeling and traceability Change management Evolution support Variant configuration and derivation Asset management Traceability Change management and impact analysis Family transition and adoption Configuration and version management Product derivation Family evolution Test strategy and methodology Validation
of assets other than software—for example, designs, patterns, requirements, test specifications, and test results—become reusable. In addition, planning and design of reuse become necessary. The product family approach deals with architected reuse. Our sequence of projects addressed various software development issues. The ARES project considered mainly architecture concerns for system families, and the Praise project considered mainly process issues. Praise introduced a reference process model that we use in Esaps and Café. The Esaps project concentrated on creating and managing family assets but also did some work on the architecture and the organization. Café also has a strong process focus, but it spends more effort than the previous projects on organization and business issues. Café takes into account issues at the very early and later stages of development related to requirements engineering and testing. The companies working in the different projects agreed to use a particular set of best practices. Table 1 groups these practices according to the development issues discussed later. 44
IEEE SOFTWARE
July/August 2002
Organization
Platform and component development
Asset management Validation and testing Product-line transition and adoption Change management Configuration and version management Product derivation
Business We began the sequence of projects with an intuition that family development was good for business, but we didn’t address the first business concern, scoping, until Esaps. Now, business concerns are an important topic in Café. The scope determines the product family’s range, and scoping decisions have important business impact. If the scope is too wide, development becomes too costly; if it is too narrow, the product family cannot serve the market demand. We must choose project objectives and a domain focus that are appropriately scoped and aligned with the broader strategic needs of the market and the stakeholder organization. Scoping is not an initial activity, but it must be performed over the course of the family’s lifetime, because new market demands might give rise to new scoping solutions. Esaps participants distinguished three kinds of scoping: ■ ■
Product family scoping: define the product portfolio Domain scoping: identify the boundaries to relevant domains
■
Asset scoping: identify reusable elements
Esaps activities dealt only with the latter two. Domain scoping is related to domain modeling activities; asset scoping is related to feature analysis, which determines a product’s commercial features. We used an initial tool prototype to help us make scoping decisions. The Café project must answer these important questions:
Architecturally significant requirements • Functional • Quality
Structure • Layers • Components • Interfaces ...
Texture • Patterns • Coding standards ...
Concepts • Client-server • Resource manager ...
Figure 4. The ARES model of software architecture. ■ ■ ■
From a market point of view, when is defining a product line worthwhile? When and how should we introduce a product family approach? How do we integrate existing processes with the new ones derived from the product family paradigm?
To evaluate these questions, we need an economical analysis model. To make scoping more effective, we want to relate it to the business model. Finally, Café will deal with the problems of introducing a family development process into an organization. Emphasis will be on which organizations are suitable for product family development, and how traditional organizations can move toward product family processes. The project will cover both lightweight and heavyweight transitions. Architecture The ARES project focused on architecture, as Figure 4 shows. One of the most important results was a clear definition of these architecture issues: ■
■
■ ■
Significant architecture requirements: The architecture should make explicit which requirements are significant for the product family’s architecture. Moreover, it should be explicit whether a requirement is functional or nonfunctional (related to quality). The architecture should relate all these requirements to the design decisions made. Concepts: The architecture determines concepts, which clarifies the system’s organization. Structure: The architecture determines the internal organization of the products. Texture: The architecture determines the standard solutions for implementa-
tion problems. Developers can address quality issues by using such standards. ARES spent much effort on the architecture description. Having the right description mechanisms eases the modeling of variability. This modeling continued in Esaps. As a result, we recognize that variability should be modeled through variation points,3 which denote places at which the family’s assets might vary. Esaps distinguished between variability in time and in space. This distinction strongly influences how the variability will eventually be implemented. Esaps investigated the subject of variability. Designing system families requires finding a way of architecting both commonality and variability to exploit them during the tailoring process. The product family architecture, or reference architecture, defines the components (mandatory, optional, and alternative), component interrelationships, constraints, and guidelines for use and evolution in building systems in the product family. Consequently, the reference architecture must support common capabilities identified in the specification, the commonality, and the potential variability within the product family. We then use the reference architecture to create an instance of a particular architecture for a new variant. Product line architecture modeling in Esaps resulted in separating the concepts variability in the large and variability in the long term. This is a useful separation, because it relates to the type of equipment and to the market. Moreover, the variation patterns used differ for these categories. The Esaps project recognized the most important reusable assets: July/August 2002
IEEE SOFTWARE
45
■
In a product family context, each component must carry much more information than traditional software packages.
■
■
■ ■
■ ■
■ ■
Requirements, with variation points: stating stable and variable (planned) product properties for all family members Domain model: describing all the entities that are important for all systems in the family Architectures: determining how to configure different software assets to build systems that satisfy the quality requirements Patterns: used in solving quality and variability issues during product development Design decision model: used in determining how to derive a product based on specific requirements Software components: implementing the functionality Interfaces between components: providing more stability than using the components directly; often enabling different implementations of the same functionality Test cases, with variation points: used in testing products in the family Product documentation: used by the system’s end users
To build systems right, we must develop our platforms and components carefully. In many cases, we build the platform itself from components. In the Esaps project, we addressed component management, including identifying and retrieving assets and designing, implementing, and delivering components. We also investigated component configuration support; we found that in a product family context, each component must carry much more information than traditional software packages. The Café project continued this work, emphasizing the independence of the underlying commercially bought platform and the use of commercial off-the-shelf (COTS) software in the families. In ARES, Esaps, and Café, attention to designing for quality was an important issue. In a product family context, designing for quality has specific challenges, because the developers must make quality predictions for all the products in the family. In ARES, we addressed traditional qualities, mainly those dealing with resource issues. In Esaps, we gave specific attention to aspect analysis to deal with special system views for various quality concerns. Aspect analysis is inspired by the Building Blocks 46
IEEE SOFTWARE
July/August 2002
practices4 in Philips Kommunikations Industrie in the 1980s and early 1990s. PKI had to survive in a niche market and therefore needed to be very flexible. This architecture was the basis for one of the first product families in Philips. The developers considered three design dimensions independently—structure, aspects, and behavior— and then assigned each piece of functionality a place in each dimension. The structure dimension determines the component and layer where the functionality resides. The behavior dimension determines the threads in which the functionality is executed. The aspect dimension does a highlevel functional decomposition of the system. Each piece of functionality was assigned to a single aspect—for example, operational behavior, logging, initialization and termination, test management, process management, and resource management. Each component, called Building Block by PKI, implemented all aspects. Sometimes with the support of automatic code generation, we created a global design for each aspect. Esaps developers took up this idea to see whether it would apply to more general situations. Some investigated how this relates to aspect-oriented programming. In Café, attention is on using architectural styles and patterns to address quality issues at the architecture level. Esaps developers did a lot of work on requirements modeling for product families. Within product families, requirements come in several sorts. Some requirements hold for the complete family, but others hold for only one or a few systems. Requirements might have variation points for different family members. To be able to deal efficiently with the requirements, it should be clear what kinds of requirements are necessary and useful in the family. Traceability is related to this. Requirements must be traced to family assets. In this way, we can determine which assets are necessary for which set of product requirements. Praise and Esaps did a lot of work on traceability modeling. Esaps came with a distinction between pre- and post-traceability, determining whether traceability is related to assets in an earlier or a later stage than requirements modeling. In addition, the developers distinguished between horizontal and vertical traceability and whether
Figure 5. The Praise reference process. Legacy code Domain expertise Domain engineering
Feedback / adaptations / reverse architecting Domain design
Domain analysis
Domain implementation
Reference architecture
Domain terminology
Reusable components
Reference requirements ...
Requirements Traceability Application engineering
New requirements
Application requirements
traceability remains at the same abstraction level. This work continues in Café. We studied ways (methods and tools) to support the process of determining which variants should be selected at each variation point; this is an important step in deriving the products. Esaps determined a framework for the technology and the concepts related to variability. The framework helps the developers recognize where and when variability is needed and led to patterns often related to variability. A crucial factor here is the right choice of variable-point representation. Process The typical software development process involves separate development for each product; instead, we wanted to introduce a development process incorporating all of a family’s products. Moreover, the process had to take into account asset reuse. The advantage of this setup is that the total development cost decreases after several systems are built. The Praise project delivered an abstract reference family development process (see Figure 5) that we carried over into all activities in Esaps and Café. There is a simple application development process for developing single systems involving ■ ■ ■
Application requirements: determining what the product should be Application design: selecting components to make the product Application coding: combining components using the infrastructure and possibly additional product-specific code
Traceability Components
Application design
Family asset repository
Application coding
The domain development process produces family assets that the product development process will reuse. This process involves ■ ■ ■
Domain analysis: determining what the family is about Domain design: deciding which platform components are needed Domain implementation: building and buying components and supporting infrastructure
Two important product family issues dealt with at this point are traceability and change management, which enable developers to plan and produce systems efficiently. Traceability is connected to configuration and version management. At any moment, many system configurations are available in the field. For maintenance reasons, we need to know which versions of which assets are used in which systems. The feedback loop is essential for getting a manageable process. The Esaps companies have implemented this process in many different forms. The development process distinguishes family asset development (domain engineering) from product development (application engineering). The asset base is the repository of family assets produced by domain engineering and used by application engineering. We can map Jacobson, Griss, and Jonsson’s process classification3 to this model as well. Their AFE (application family engineering) is related to the activities in the top-left hand block of Figure 5, CSE (component system engineering) is related to the other blocks in the top row, and ASE (apJuly/August 2002
IEEE SOFTWARE
47
All Esaps partners already had a collection of systems in the field that should belong to the family and that need to be maintained for several more years.
48
IEEE SOFTWARE
plication system engineering) comprises the bottom row. Esaps presented all the process frameworks used in the participating companies in the same template, so we could compare the different frameworks. We found room for improvement in all the frameworks. Esaps determined a clear set of necessary activities and work products. In all cases, domain engineering and application engineering had separate processes. Because no existing framework exhibited all the important activities, we concluded that none were sufficient for product family development. All Esaps partners already had a collection of systems in the field that should belong to the family and that need to be maintained for several more years. Moreover, these systems contained assets that could be transformed into family assets, to be reusable in future family members. We began to define a process and tool support for incorporating the already existing (legacy) systems into the family domain, and we began to treat them as family members henceforward. Café continues on this track and has introduced the incorporation of thirdparty software and COTS into the family. The Café project is based on the same Praise reference process, with a focus on the very early and late subprocesses and the major activities shown in Figure 5. The Café project’s results have the form of structural rules for assets, methods, procedures, and organizational structures. We will use these results to build new applications in the families and to provide requirements for tool vendors. Change management lets us predict the properties of variants and new family assets before building them. The Esaps project did some initial investigation of change management, and these efforts are continuing in Café. Changes in one asset of a family might affect many products in several ways, so we must be careful with changes. Guidelines and automated support are essential for identifying and supporting required changes caused by the modification of a given software artifact. These guidelines might be accomplished by specifying specific tradeoffs or constraints on specific products or product parts. Moreover, it is necessary to be able to select the requirements for a single member of the family and then to quickly select the assets needed to build that mem-
July/August 2002
ber. Esaps proposed a decision model, based on a requirement hierarchy, for deriving family members. Depending on the specific functional or quality requirements, the architect selects the product variants to be delivered and then builds the executable system based on that selection. Esaps investigated how to manage family assets so that developers can find what they need. The project built metamodels to improve asset classification and introduced methods for effectively selecting components and interfaces in an asset base. ARES started the first investigation of architecture assessment, the process of measuring system properties based on an architecture description. The project performed a small assessment related to timing behavior and proposed tool support for analyzing the timing behavior. A more complete assessment case study within Esaps resulted in some additions to traditional architecture assessment. However, we did not find much difference from traditional architecture assessment. Domain analysis is one of the basic activities in product family development. All systems in the family belong to the same domain or a small set of domains, and the result of the domain analysis, the domain model, is usable for all these systems. The domain model is crucial for the family architecture, because the complete family architecture is based on the domain. Only when the developer knows the domain’s boundaries can he or she efficiently determine the domain model. ARES experimented with and had some success in recovering architecturally useful information from existing assets, informal documentation, and interviews. Esaps continued this work in the automatic verification of conformance to architectural rules during development, and the work continues in Café. Tool support is crucial. Product family development needs tool support to manage the assets, model the domain, support traceability, and help the architects and developers easily do the right things. In addition, the (semi)automatic derivation of products from specific product requirements would be very helpful. No good tool support exists for this. In ARES’ focus on techniques for product family architecture, it found that a simple language works best. However, most
commercial tools support complex languages that divert the attention of architects to issues that are important only in later stages of development. Esaps produced a collection of tool requirements. Café will get a more complete picture of requirements for tool support. Organization The projects have not done much work on organization yet, but Café will investigate this aspect. During Esaps, we investigated only briefly the organizational consequences of a product family development approach. We concluded that separate development groups should work on family engineering and product engineering. In fact, division into three development organizations might be a good idea.3 However, we found that good experiences also occur when we combine all responsibilities and split the departments orthogonally to the process categories. So, we concluded that it is still not clear when and why a development organization should be separated into family and product development departments.
W
hile the European movement toward product family engineering took place, researches in the US founded the SEI Product Line Initiative.5 This initiative had the same objectives: improving and introducing product families (product lines) into industrial organizations. Apart from this, we know of no other large-scale product family engineering efforts. In contrast to the SEI initiative, the companies involved initiated the European projects. This was based on their own experiences and their own economic need for product families. The European movements joined forces to learn from each other. The founding companies selected research institutes according to their added value for the initiative. The SEI initiative gives general guidelines on best practices for many areas. It puts a lot of work into the management process, which the European projects only partially address. In the European projects, we found many cultural differences among organizations, which led to different emphases on different management issues. Moreover, we
are acting in a bottom-up way. We try to learn from each other and adopt each other’s best practices. We do not want to force the participants to take over practices that do not fit their culture. This means that the European projects came up with a large variety of solutions to the same problem, in contrast to the SEI initiative, which promotes a single framework. To bring the rest of the world into the discussion, we have been running a sequence of workshops on product family engineering.6–8 During the first workshop, we came in contact with the SEI Initiative participants; now, we meet each other several times a year at conferences and workshops and exchange ideas for improvement. We feel we benefit from this contact, so we will continue to present our workshops.
References 1. M. Jazayeri, A. Ran, and F. van der Linden, Software Architecture for Product Families, Addison-Wesley, Reading, Mass., 2001. 2. R. van Ommering, “Beyond Product Families: Building a Product Population?” Proc. Software Architectures for Product Families, Lecture Notes in Computer Science 1951, Springer-Verlag, Berlin, 2000, pp. 187–198. 3. I. Jacobson, M. Griss, and P. Jonsson, Software Reuse, Addison-Wesley, Reading, Mass., 1997, p. 21. 4. F.J. van der Linden and J.K. Müller, “Creating Architectures with Building Blocks,” IEEE Software, vol. 12, no. 6, Nov. 1995, pp. 51–60. 5. P. Clements and L. Northrop, Software Product Lines, Addison-Wesley, Reading, Mass., 2001. 6. Proc. Development and Evolution of Software Architectures for Product Families, F. van der Linden, ed., Lecture Notes in Computer Science no. 1429, Springer-Verlag, New York, 1998. 7. Proc. Product Family Engineering, F. van der Linden, ed., Lecture Notes in Computer Science no. 2290, Springer-Verlag, New York, 2002. 8. Proc. Software Architectures for Product Families, Lecture Notes in Computer Science 1951, Springer-Verlag, Berlin, 2000.
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
About the Author Frank van der Linden is an international project leader at Philips Medical Systems,
where he coordinates international-cooperation projects in software engineering for product families. He is also project manager for the ITEA projects Esaps and Café and was Philips’ project leader of ARES (Architectural Reasoning for Embedded Systems). His main interests are in software engineering and architecture, with an emphasis on process and organization, and quality issues. He received a PhD in pure mathematics from the University of Amsterdam. He is a member of the Dutch Mathematical Society and of the Dutch Association for Theoretical Computer Science. Contact him at Philips Medical Systems, Veenpluis 4-6 5684 PC Best, Netherlands;
[email protected].
July/August 2002
IEEE SOFTWARE
49
focus
initiating software product lines
The Economic Impact of Product Line Adoption and Evolution Klaus Schmid, Fraunhofer Institute for Experimental Software Engineering Martin Verlage, Market Maker Software AG
oftware is increasingly turning into a commodity; thus, people increasingly expect systems that are customized to their needs. This situation is forcing nearly every software development organization to develop multiple variants of their systems to serve the specific needs of different customers or market segments. Thus, many, if not most, software development organizations are finding that they need to build families of systems or product lines.
S When transitioning to product line development, an organization must consider the adoption context and should use product line scoping techniques to optimize the economic benefits. 50
IEEE SOFTWARE
Experience shows that a company can drastically improve its competitive advantage if it optimizes how it develops these product lines.1,2 Using product line engineering, some organizations have reduced the number of defects in their products and reduced costs and time to market by a factor of 10 or more.1,3 However, many companies don’t use a product line engineering approach when developing their product lines. More often than not, they either start from a single system, branching off new variants as the need arises and ending up with completely independent code bases, or they start with the different variants as independent projects from the beginning. Product line engineering focuses on developing multiple variants of systems jointly, thus exploiting the commonality among systems in the form of reuse.1 The key to successful product line engineering
July/August 2002
approaches, such as Pulse4 (a componentbased product line development approach developed at the Fraunhofer Institute for Experimental Software Engineering), is to identify early on a reference architecture that provides a blueprint for producing different variants. The structural similarity among the variants, resulting from the common architecture, enables developers to reuse components across a range of different products in the product line. However, when implementing product line engineering, a wealth of options exists, so companies must make wise decisions to optimize their economic benefit. To exemplify this, we discuss Market Maker Software AG’s3 Merger product line. Product line adoption schemes In theory, the optimal product line development adoption scheme is to set up a com0740-7459/02/$17.00 © 2002 IEEE
Effort
Effort
Traditional development
Incremental product line development
Product line Initial development investment
Big bang product line development
Risk
(a)
Break even
Number of products
Number of products
(b)
Figure 1. Product line investment curves: (a) the big bang approach, including risks; (b) the big bang versus incremental approach.
pletely new product line by developing a reuse infrastructure for the whole range of products right from the start. We often call this the big bang approach. You can use this infrastructure to develop new products, which could drastically cut costs compared to traditional stovepipe development. Of course, when first planning a product line, predicting the specific investments and benefits is hard, so economic results will contain some uncertainty. Unfortunately, this ideal approach is hardly ever adequate in practice. In principle, strong upfront planning should let you develop assets that support the full range of functionality the product line requires, but organizations often use a more incremental approach. With an incremental approach, you develop assets to support the next few upcoming products, deliberately excluding highly uncertain potential products. Over time, you need to extend and adapt assets to address further products. Usually, constraints on available resources force this more incremental approach, but it’s generally useful even with unlimited resources because of the intrinsic uncertainty of future products and their requirements. Figure 1a shows the ideal big bang pattern, and Figure 1b compares it with the corresponding patterns for the incremental approach. Regardless of which approach you use, it is best to first distinguish several basic situations from which product line adoption can start. You can then link each situation to corresponding strategies (or adoption schemes) and connect a different pattern of investment and resulting benefits to each one. We can distinguish four main types of situations for adopting product line engineering: ■
Independent. The company starts a new product line without any predecessor products.
■
■
■
Project-integrating. Existing systems are already under development to address a new market. As part of product line development, the software engineers integrate the systems so that they can derive them from the same reuse infrastructure. Reengineering-driven. Legacy systems already exist, but the engineers can’t use them for product line development— rather, they need to perform a nontrivial reengineering effort. Leveraged. The company sets up a new product line (to address a new market) based on a product line that is already in place.
In practice, these situations often overlap. Consider Market Maker’s Merger product line. Market Maker started in 1990 as a oneperson company with a single product: a DOS-based system for tracking stock information. It has since grown to 60 employees, but to optimize its limited resources, Market Maker has always used a product line approach. Even in the DOS version, various modules were available to address specific data-processing needs, and customers could independently bring in other modules. (However, the implementation level only had a single variant and certain menu entries enabled, based on the given license key.) As the company created new software platforms, it found it had to develop more sophisticated approaches to address increasingly complex variability needs. In 1995, it started developing a new software system aimed at supplanting the original DOSbased product and transferring its potential to the Windows-based age. Like the original product, the new system supported the module concept. However, over time, the company created additional implementationlevel variants (for special applications) and July/August 2002
IEEE SOFTWARE
51
5
4
Market segment 1 Market segment 2 Market segment 3
MM live!
MM live! MM98
COM interface
COM interface
Java wrapper
Java wrapper
3
COM interface
Basic data
Java wrapper
Chart data
JDBC/ODBC
RMI
RMI
2
Data access layer
Banks intranet
Application layer
1
WAP
External applications
RMI 0
Qtr. 1
Qtr. 2
Qtr. 3
Servlets
Qtr. 4
2000
HTTP
(a)
HTTP
(b)
Figure 2. The Merger product line: (a) systems delivered over time and (b) the product line architecture.
entry-level mass-market variants. These variants constituted the Market Maker product line—the company produced them from a single, common code base. In 1999, the company decided to enter the market of Internet-based stock-market information systems. It thus created the Merger product line, which was based on a completely new infrastructure developed in Java (Martin Verlage managed the Merger product line’s setup and evolution). Currently, this product line includes about 15 variants addressing three different market segments (see Figure 2a). When developing Merger, the company decided not to replicate functionality that already existed in the Market Maker product line—such as the MM98 and MM live variants that address the historical data feed and the real-time data feed, respectively. So, it created specific variants of the Market Maker product line and used them as data servers in the Merger installations (see “MM98” in Figure 2b). When adopting and evolving its product line approach for these two product lines, Market Maker applied the schemes we discuss here with huge success. Product line entry and exploitation potential Depending on the specific situation in which you start product line development, you usually find different patterns of how the company incrementally develops the product line and, similarly, different patterns of investment and return on investment. In particular, you need to determine whether the in52
IEEE SOFTWARE
July/August 2002
crement originates by successively extending and adapting the reuse infrastructure for additional products, or whether the company extends it by successively adding assets covering additional functionality. Independent adoption The independent product line adoption scenario is the prototypical product line situation (see Figure 1a). Because no products exist yet, the company can plan in detail and optimize its product portfolio. Compared to the product line’s overall setup time, the planning time would be rather low, so it wouldn’t significantly increase the time to market. However, starting a completely new product line means venturing into the completely unknown. Thus, technical feasibility studies and detailed market analyses are necessary to control the overall uncertainty. Furthermore, even if you use these measures, you usually still have significant uncertainty, because, for example, some products could become more or less important as product development progresses. In the context of the Merger product line, the company made a detailed analysis of potential portfolios, identifying major market segments, key requirements, and so forth. Additionally, it performed technical feasibility studies and competitor surveys. Although these analyses were rather thorough, plans still required adjustment. For example, the company addressed some market segments later than anticipated or not at all, because more products than expected could be delivered to the customer in the initial
market segments. Despite these deviations, it is clear in retrospect that the initial efforts were not wasted. Rather, they played a key role in focusing the reuse infrastructure’s development, so now Market Maker can efficiently develop new variants. Project-integrating adoption From our experience in industrial practice, we’ve found that the independent situation is rather uncommon. Usually, several products exist in a company that have some commonalities but were more or less independently developed. There is continuous pressure to bring to market new products, so it is impossible to put product development on hold to focus on developing an integrated product line infrastructure. Rather, an incremental approach is required, where key components are successively generalized into common, reusable components. A special case of the project-integrating situation exists when two product line infrastructures must merge. Such a situation is currently occurring at Market Maker—the company is integrating the original Market Maker and Merger product lines into a single product line architecture. Although companies can usually avoid project-integration by replicating functionality among the two product lines, at times profound differences in the nonfunctional requirements make it necessary. In this situation, the company integrates the reuse infrastructures, focusing on integrating the replicated components. Because the company must continually derive new products and releases from the product lines, it can only perform an incremental, component-wise integration of the reuse infrastructures— similar to the incremental pattern Figure 1b shows. However, if compared to the initial situation, the entrance barrier (the effort required before you can derive the first products from the resulting infrastructure) is usually lower, whereas the number of steps (effort to extend the product line infrastructure) will be higher. Also, the company generally must expect more problems with the degradation of the reference architecture. This is the general adoption pattern for project-integrating product line development—create a common infrastructure by integrating technical areas in a componentwise 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 until the first products can be derived from the resulting infrastructure) will usually be lower, while the steps (effort to extend the product line infrastructure) will usually be higher. Also, more problems generally occur with the degradation of the reference architecture over time. Reengineering-driven adoption A company usually undertakes reengineering-driven adoption if it finds that its software development is bound to hit a wall. This can manifest itself in many ways—for example, if the cost of product development grows too high or if it becomes impossible to derive new, envisioned products based on the available systems. Companies typically will tolerate a certain level of pain before making the investments associated with performing a major reengineering effort. However, when they do undergo such reengineering, it’s then fairly easy to introduce the additional effort required to plan a product portfolio. Reengineering can either focus on packaging the existing legacy system as a whole or it can aim at a component-wise approach. This situation is similar to independent adoption and its economic patterns. If the company packages the legacy as a whole, it incurs rather large investments in the beginning but significantly reduced costs for developing future systems (see Figure 1a). If the company performs component-wise packaging, an incremental pattern (see Figure 2b) will result, but reengineering generally requires a large initial investment compared to typical project-integrating situations. A good example of the component-wise approach to reengineering-driven adoption is the Ramsis kernel redesign project that Fraunhofer IESE performed with a small company. This project focused on a reengineering-driven product line design for a large legacy system of ergonomy simulations.5 It started with a significant reengineering effort for identifying components in the existing system and packaging them to turn the system into an appropriate basis for further product line development. Developing the Merger product line also mirrors this situation, because, as discussed earlier, the company reused Market Maker
There is continuous pressure to bring to market new products, so it is impossible to put product development on hold to focus on developing an integrated product line infrastructure.
July/August 2002
IEEE SOFTWARE
53
From an economic viewpoint, a leveraged product line adoption entails a revolution, because the company can address a completely new market segment with low costs and few risks.
54
IEEE SOFTWARE
functionality as servers, and prior to that, it had to add specific interfaces to these servers. However, for Merger, packaging only required augmenting the existing systems with appropriate interfaces using COM. Also, the Merger product line was built on top of the existing one, which is why it’s more appropriately characterized as leveraged product line adoption. Leveraged adoption Leveraged product line development is perhaps the most sophisticated approach to product line adoption. As opposed to the other patterns, it requires an existing product line and is characterized by a shift to a new market (system type). Examples of such a shift are Cummins Engines, which expanded its original product line for car and truck diesel engines to arbitrary industrial diesel engines, and CelsiusTech, which leveraged its product line of battle ship control systems by entering the market of civil air-control systems.6 In these cases, the existing product line infrastructures provided leverage for entering the new market, giving the company a competitive advantage right from the start. The Merger product line is clearly a case of a leveraged product line. The existing Market Maker product line offers leverage by providing data gathering, data management, and aggregation services, while the Merger infrastructure mainly focuses on data transformation and online presentation tasks. Market Maker packaged its original product line’s functionality into Merger in the form of servers. This partitioning of the reuse infrastructure also benefits Merger products through ongoing development on the Market Maker product line. From an economic viewpoint, a leveraged product line adoption entails a revolution, because the company can address a completely new market segment with low costs and few risks by building on an existing product line infrastructure. However, as in other situations—in particular, the independent situation—the company must perform a detailed product portfolio analysis, technology studies, and risk analysis. Similarly, leveraged adoption usually requires an initial investment and then shows a steady growth in the number of systems (see Figure 1a). For Merger, the leveraged approach proved to be highly successful. However, Figure 2a shows
July/August 2002
a slightly different pattern of nearly exponential growth. The reason for this is that the Merger reuse infrastructure itself grew over time. Thus, later systems could be built with more reuse. Product line evolution The main factor determining how a product line evolves is how much deviation the organization allows before reunifying the infrastructure. We can distinguish three basic situations for product line evolution (not taking into account replacing the infrastructure’s parts over time). In the first situation, infrastructure-based evolution, new product requirements that might be reusable immediately lead to a generalization of the product line infrastructure. Thus, the organization can avoid the problem of multiple implementations of the same requirement. However, this usually results in many changes to the product line infrastructure. A specific product (the first one in need of a new requirement) triggers each change, which is implemented in a way adapted to the next few products (see Table 1). Market Maker took this approach with its Merger product line. If it hadn’t, the simultaneous demands for many new variants would have created a strong dispersion into variants of the product line infrastructure. The advantage is that for the second product requiring the functionality, it is already reusable. This can lead to the superlinear increase that Figure 2a shows. The second situation, branch-and-unite, is common in industrial practice. Here, the organization creates a new version branch for a new variant and then reunifies this branch with the original infrastructure after releasing the product. In this case, the organization typically considers only a single product, although more experienced organizations also consider requirements for future products when determining an adequate implementation. Market Maker successfully pursued this approach with its first product line. The main reason for applying this approach is that new variants are rather infrequent and thus usually nonoverlapping. This wasn’t the case with the Merger product line. Some organizations end up in a bulk situation, which allows larger branching of the reuse infrastructure. Then, at certain intervals, the organization reintegrates the prod-
Table 1 Product line adoption and evolution patterns Adoption
Evolution
Situation type
Product line planning look-ahead
Approach
Independent Project-integrating Reengineering-driven Leveraged
Broad portfolio of future systems Medium-size portfolio of future products Broad portfolio of future products and legacy products Broad portfolio of future products
Big bang Incremental, by functional area or component Incremental, by functional area or component, or big bang, by packaging existing legacy as a whole Big bang
Infrastructure-based
A small number of products
Incremental, by product
Branch-and-unite Bulk
Single product A small number of products (perhaps a market segment)
Incremental, by product Incremental, by product group
Table 2 Scoping techniques and their relation to product line adoption Mode of product line extension
Portfolio definition
Domain-potential analysis
Reuse infrastructure scoping
Partial big bang and evolution by product group By (single) product
Very important
By component or functional area
Should be performed
Recommended, but mainly for risk analysis Only needed if the extension requires restructuring Key for identifying the next component for product line extension
Recommended to support architecture definition Only needed if the extension requires restructuring Should be applied to support architecture definition
Not necessary
uct line infrastructure. Larger organizations usually apply this approach, but it’s best to avoid it as much as possible. It not only leads to major reintegration efforts (mapping to big jumps in the economic curve in Figure 1b), but it also usually entails significant synchronization efforts and quality problems. The different patterns of product line evolution we’ve identified have different requirements in terms of look-ahead planning and the number of products simultaneously integrated into the product line infrastructure (see Table 1).
and evolution steps determine the product line development’s basic economic pattern, answers to these questions help fine-tune product line development and its economic characteristics. Restrictions for answering the questions depend on the specific adoption or evolution situation (see Table 2). Based on the types of decisions that must be made, we can distinguish the following three levels of decision making—or scoping— in the context of product line engineering:7
Product line planning techniques How an organization performs product line adoption and evolution strongly influences its product line’s overall economic results. However, even if it selects a specific adoption approach, it still must decide which products to consider when developing or extending the product line infrastructure, which technical areas to integrate next into its product line infrastructure, and which requirements reusable assets will directly support. Just as the basic adoption
■
■
■
Product portfolio scoping: Which products shall be part of the product line? Domain-based scoping: Which technical areas (domains) provide good opportunities for product line reuse? Reuse infrastructure scoping: Which functionalities should the reuse infrastructure support?
Affluency in these three scoping techniques will help you make the right decision when adopting and evolving a product line. Product portfolio scoping helps establish a detailed vision of the products and their July/August 2002
IEEE SOFTWARE
55
About the Authors Klaus Schmid is competence manager for value-based product line development at
Fraunhofer IESE, where he has been involved in several projects that have transferred product line engineering concepts to industrial environments. He was also a member of the Pulse development team. His main research interests are the economic aspects of product line development and approaches for introducing and institutionalizing product line development in industry. He received an MS in computer science from the University of Kaiserslautern. Contact him at Fraunhofer Inst. for Experimental Software Eng., Sauerwiesen 6, D-67661 Kaiserslautern, Germany;
[email protected]. Martin Verlage is director of the Online Products business area at Market Maker Software AG. His main software development interests are in the area of component-based software engineering, especially architecting and testing. He received an MS and PhD in computer science from the University of Kaiserslautern. He is a member of the Gesellschaft für Informatik e.V. Contact him at Market Maker Software GmbH, Karl-Marxstr. 13, D-67655 Kaiserslautern, Germany;
[email protected].
requirements. First, you identify the general market potential based on market analyses, taking into account the market structure, potential customers, end-user needs, and the positioning of competitors. Then, you identify the market segments that fit the company background. This usually happens in a workshop representing the most relevant stakeholder groups. While coming up with an integrated definition of the product portfolio, it is important to address questions such as, “Will the products compete with each other on the market?” and “How much will it cost to develop these products?” It helps even if you just informally ask these questions. While setting up the Merger product line, Market Maker performed a detailed product portfolio scoping. It analyzed markets and competitors, developing a first vision of potential market segments and products. This provided the necessary input for technical feasibility studies. At the same time, it refined the initial vision of the portfolio in several iterations. This actually led to rather severe changes, such as introducing additional market segments in the product line vision. You only need to perform this full-size approach if you develop a new product portfolio. Otherwise, just identify changes to the product portfolio—technical feasibility and market studies are usually not so important. Based on a product portfolio definition, you can perform domain-based scoping. With this approach, you identify the main technical domains relevant to the product line and analyze their reuse potential. Different technical domains, even within the same product line, can vary considerably in terms of their potential benefit and inherent risks for product line engineering. Market Maker 56
IEEE SOFTWARE
July/August 2002
applied this approach to domain-potential analysis, which is part of the Pulse-Eco method,8 for the Merger product line. In this case, Market Maker observed variations from “extremely well suited for product line reuse” to “not suited at all.” In particular, domain-based scoping identifies areas where a reuse investment is particularly meaningful, which is especially important if the product line infrastructure is built in an incremental manner (for example, in a project-integrating adoption situation). Furthermore, it can help you decide what functionality to integrate next into the product line. In a situation such as the one with the Merger product line, where the organization basically built a full product line infrastructure with the first product, this approach is typically used only to inform the development of potential reuse risks (see Table 2). Once you identify the key areas for product line reuse, the important question is which functionalities should be made reusable in the context of the specific product line, which involves reuse infrastructure scoping. The Pulse-Eco approach supports this activity in a quantitative manner. With reuse infrastructure scoping, you develop quantitative models to capture the desired product line benefits. You then use these models to identify functionalities that will provide the highest economic benefit if made reusable. This provides economic input for the architecture definition. Because of this focus on guiding the product line’s implementation, this form of scoping is particularly useful when large parts of the product line infrastructure are built for the first time. This is the case if whole product groups or new functional areas must be integrated into the product line infrastructure. Market Maker applied this approach when extending certain functional areas for its Market Maker product line. In this case, the approach provided valuable input for making the most appropriate functionality reusable.7
P
roduct line development is about to change how we perceive and perform software development. This transition is similar to the one made from craftsmanship to industrial production. Although this transition is strongly based on the increased understanding of software ar-
chitectures, it is also changing how organizations go about their software business. During the industrial revolution, becoming a modern company involved more than just adding an assembly line to the factory floor. Likewise, it will not be sufficient for organizations to switch to product line development in an arbitrary way. Rather, a company must adequately adopt such an approach, and the approach must evolve from the perspective of potential economic benefits. To successfully reap these benefits, companies will have to develop an in-depth understanding of product line development’s economic implications and how these implications relate to the possible product line adoption and evolution mechanisms.
References 1. P. Toft, D. Coleman, and J. Ohta, “A Cooperative Model for Cross-Divisional Product Development for a Software Product 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 Software Product Line Architecture for Real-Time Embedded Diesel Engine 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 Software 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 Product Line 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 Scoping,” Proc. 4th Workshop Product Family Eng. (PFE’4), Springer Verlag, New York, 2001, pp. 70–78. 7. K. Schmid, “Scoping Software Product Lines: An Analysis of an Emerging Technology,” Proc. 1st Software Product Line Conf. (SPLC1), Kluwer, Dordrecht, Netherlands, 2000, pp. 513–532. 8. K. Schmid, “A Comprehensive Product Line Scoping Approach and Its Validation,” Proc. 24th Int’l Conf. Software Eng. (ICSE’02), ACM Press, New York, 2002, pp. 593–603.
Acknowledgments The Eureka 2023 Programme, ITEA (Information Technology for European Advancement) projects ip00004 and 99005, Café (from concepts to application in system-family engineering), and ESAPS (Engineering Software Architectures, Processes, and Platforms for Systems-Families) partially supported the work presented in this article.
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
NEW FOR 2002 the IEEE Computer & Communications Societies present
IEEE PERVASIVE COMPUTING The exploding popularity of mobile Internet access, third-generation wireless communication, and wearable and handheld devices have made pervasive computing a reality. New mobile computing architectures, algorithms, environments, support services, hardware, and applications are coming online faster than ever. To help you keep pace, the IEEE Computer Society and IEEE Communications Society are proud to announce IEEE Pervasive Computing. This new quarterly magazine aims to advance mobile and ubiquitous computing by bringing together its various disciplines, including peer-reviewed articles on
• • • • •
Hardware technologies Software infrastructure Real-world sensing and interaction Human–computer interaction Security, scalability, and privacy
Editor in Chief M. Satyanarayanan Carnegie Mellon Univ. and Intel Research Pittsburgh Associate EICs Roy Want, Intel Research; Tim Kindberg, HP Labs; Deborah Estrin, UCLA; Gregory Abowd, Georgia Tech.; Nigel Davies, Lancaster University and Arizona University
SUBSCRIBE NOW! http://computer.org/pervasive July/August 2002
IEEE SOFTWARE
57
focus
initiating software product lines
Feature-Oriented Product Line Engineering Kyo C. Kang and Jaejoon Lee, Pohang University of Science and Technology Patrick Donohoe, Software Engineering Institute, Carnegie Mellon University
roduct line software engineering is an emerging paradigm that helps organizations develop their wares from reusable core assets rather than from scratch.1–3 However, to develop these assets, such software engineering must exploit commonality and manage variability. Many researchers in industry and academia started using a feature-oriented approach to commonality and variability analysis4 after the Software Engineering Institute introduced Feature-Oriented Domain Analysis in 1990.5
P The Feature-Oriented Reuse Method concentrates on analyzing and modeling a product line’s commonalities and differences in terms of features and uses this analysis to develop architectures and components. The FORM explores analysis and design issues from a marketing perspective. 58
IEEE SOFTWARE
FODA appeals to many product line developers because features are essential abstractions that both customers and developers understand. Customers and engineers usually speak of product characteristics in terms of the features the product has or delivers, so it’s natural and intuitive to express any commonality or variability in terms of features. A feature-based model thus provides a basis for developing, parameterizing, and configuring reusable assets. Although requirements are essential inputs for core asset development, they are not sufficient on their own; a marketing and product plan (MPP) can help propel asset development. We extended FODA into the FeatureOriented Reuse Method (FORM) not only to support architecture design and object-oriented component development but also to incorporate a marketing perspective and explore analysis and design issues from that perspective.6 With an MPP, reuse is not opportunistic; it is carefully planned for a specific product line. Our customers have applied this method
July/August 2002
to several industrial application domains to create software engineering environments and software assets for a specific product line.4 Here, we’ll use a home integration system example to show how the FORM brings efficiency to product line development. FORM FORM product line engineering consists of two major processes: asset development and product development. (See Figure 1 for activities and their relationships.) Asset development consists of analyzing a product line (such as marketing and product plan development and refinement, feature modeling, and requirements analysis) and developing architectures and reusable components based on analysis results. Product development includes analyzing requirements, selecting features, selecting and adopting an architecture, and adapting components and generating code for the product. The MPP identifies the information to gather during the marketing and business 0740-7459/02/$17.00 © 2002 IEEE
Product line asset development process
MPP development
MPP
Feature model
MPP MPP refinement
Feature model PL req.
Conceptual architecture design
Feature modeling Feature model
PL req.
PL req.
Product line requirements analysis
COTS, patterns
Conceptual architecture
Architecture refinement Conceptual architecture Design object model
Process Deployment architecture architecture
Design object modeling
Component design
Refined MPP Product line assets Data flow Product requirement analysis and feature selection
Architecture selection and adaptation
Component adaptation and code generation
Name
Activity
MPP PL Req.
Marketing and product plan Product line Requirements
Product development process
analyses. It includes a market analysis, a marketing strategy, product features, and product feature delivery methods. To start the asset development process, developers organize functional and nonfunctional product features from the MPP into an initial feature model, which they then extend with design features—operating environments, the domain technology available, and the implementation techniques to be used. In parallel, a product line requirements analysis elicits and organizes requirements in terms of a use case model and an object model.7 A use case model defines interactions between the user and the system; an object model defines system responsibilities. The developers then refine the original MPP with the help of both the feature and requirements models. The next step is conceptual architecture design, which allocates features to abstract architectural components and specifies the data and control dependencies between them. The result is a conceptual architecture. A design object model must be developed based on the conceptual architecture, the feature model, product line requirements, and other information such as any commercial off-the-shelf components or design patterns8 relevant to the product line. Designers then refine this conceptual architecture into process and deployment architectures by allocating components to concurrent processes and network nodes, considering whether to replicate each process, and defining interaction methods between processes.
(The process architecture represents concurrency structure in terms of concurrent processes or tasks to which functional elements are allocated; the deployment architecture shows an allocation of processes to hardware resources.) The component design activity then further refines the process and deployment architectures into concrete components by using the design object model. The MPP provides quality attributes for architecture design and refinement. For example, user profile information in the MPP can help determine the quality attributes required for the architectural design of the products targeted for each market segment. Also, the MPP can help the developer explore design alternatives for feature delivery methods, the resolution of feature interaction problems, and so on. FORM product line engineering processes are iterative, incremental, and repeat until a design has enough details for implementation.
Figure 1. The Feature-Oriented Reuse Method product line engineering process. The arrows show dataflow (each activity’s use of work products).
Initiating asset development Developing an MPP for a product line initiates asset development; the MPP sets a specific context for analyzing the product line and exploring reuse. Products developed without considering how to market them or what the users’ needs and capabilities are cannot be sold. Functionality alone does not sell. Products must be configurable to meet user needs and capabilities. How the MPP helps The first part of an MPP is a marketing July/August 2002
IEEE SOFTWARE
59
Marketing and product plan
Marketing plan (business concerns)
Product plan (engineering concerns)
Market analysis
Product features
Market segment • Needs assessment • User profile • Cultural and legal constraints Business opportunities • Time to market • Price range Marketing strategy Product delivery methods Other business considerations
Figure 2. The elements of a marketing and product plan.
60
IEEE SOFTWARE
Product functional features • Feature lists • Feature description Quality attributes • Usability, scalability, and so on Product feature delivery methods Feature coverage Feature binding time Feature binding techniques
plan, which includes a market analysis and a strategy for realizing business opportunities in that market (see Figure 2). For each market segment, the analysis includes an assessment of needs, potential users, cultural and legal constraints, time to market, and price range. The marketing strategy initially includes an outline of product delivery methods and other business considerations. Once we define the marketing plan, we should identify the characteristics of products in the line in terms of features and develop a plan to incorporate those features. A product plan includes product features and product feature delivery methods (see the right half of Figure 2). Product features are largely classified into functional and nonfunctional features. Functional features include services, which are often considered marketable units or units of increment in a product line, and operations, which are internal product functions that are needed to provide services. For example, in home integration systems, fire, intrusion, and flood detection and control features are functional features. Nonfunctional features include end-user-visible application characteristics that cannot be identified in terms of services or operations, such as presentation, capacity, usage, cost, and other quality attributes. Safety, reliability, and scalability are important quality attributes for a home integration system product line. A product feature delivery method defines how product features are sold or delivered to customers and users and how they July/August 2002
are installed and maintained. We can prepackage some features in products as standard items; others can be selected at negotiation time. Other features could be specific to a customer and built into a custommade product. Marketing and product planning: An example Let’s say that a home integration system company intends to become a major player with two initial products: a low-end product (LE-HIS) and a high-end product (HE-HIS). This company’s key marketing strategy is to allow budget-conscious customers to start with a “small” system with a few features and then grow to a bigger one by adding new features instead of buying new products. Therefore, the product’s scalability is the most difficult challenge for the engineers. Table 1 is an example of an MPP for such a home integration system product line. The market analysis identifies two user categories (office building and home users) and two market segments (high-end and lowend) along with their current needs and user profiles. The user/maintainer profiles for each market segment are ■
■
Low-end market (household uses): No computer skill is assumed for the potential users, and home integration system software should run on the PCs they already have. High-end market (office building uses): Dedicated engineers with computer science background are available for maintenance. The computing environment is distributed over a network, and maintainers can access the system remotely.
The MPP must also identify each country’s laws and cultural traits. Emergency codes for each type of incident (such as fire, flood, or intrusion) could vary from country to country, as could safety and reliability requirements. Because the HE-HIS has many customerspecific requirements, the designers would choose the feature selection method (see Table 1) to adapt and integrate features at product delivery time. For the LE-HIS, they would use the prepackaged method (see Table 1) combined with a user-friendly interface for users who do not have any computer knowledge. The designers must refine product delivery
Table 1 A marketing and product plan example for a home integration system product line User/maintainer profile Feature delivery method Legal constraints
Office building (high-end product)
Household (low-end product)
Dedicated engineers with computer science backgrounds Feature selection from a predefined set of features (feature selection method) Emergency control services must conform to each country’s codes
No computer knowledge is assumed Prepackaged method Emergency control services must conform to each country’s codes Fire, intrusion, flood Safety, reliability, scalability, usability Product build time
Product features Fire, intrusion, flood, security, and other customer-specific features Quality attributes Safety, reliability, scalability Product feature binding time Product delivery time
Feature identification and organization Feature model Business concerns
Engineering concerns
Feature interaction policy
Marketing and product plan Market information
Market analysis
Marketing strategy
Product functional and nonfunctional features Product feature delivery methods
Fire Detection
Behavior specification (Statechart)
Fire Detection
Fire Detection
Key driver
Quality attributes
Architecture design and evaluation
Feature delivery methods
Collaboration through MPP
Component design for feature binding time variation
User profile
User interface and installer design
Product line assets
methods into product feature delivery methods—what features are allowed (feature coverage), when they are incorporated (product build time, product delivery or installation time, or runtime), and how that incorporation is made (framework, template, load table, plug-ins, and so on).5,9,10 For example, the LE-HIS has a closed set of features, so feature binding occurs at the product build time. For the HE-HIS, however, customers can select any feature from a predefined list, so feature binding occurs at product delivery time, perhaps by using a load table that contains parameter values for instantiation. FORM with MPP The FORM includes the MPP to bring efficiency into product line asset development. (Figure 3 shows an overview of the concept.) Feature modeling and requirements analysis Because a product line’s MPP sets a spe-
cific context for a product line analysis, the analyst can perform that analysis effectively and efficiently. As we mentioned earlier, product features identified in the MPP are organized into an initial feature model, which is then refined by incorporating operating environment, domain-specific technology, and implementation technique features. When incorporating these features, analysts must investigate potential environmental and technological changes (see Figure 4).11 Product line requirements analysis captures the necessary functionalities in a set of models such as a use case model, an object model, and so on.7 Depending on the product line’s domain, other models may be included. Based on this information, the product line component design provides realizations of common functions that an organization can use across products. (The complete set of models of the HIS example is not presented in this article because of space limitations.)
Figure 3. Product line asset development using a marketing and product plan as a key driver.
July/August 2002
IEEE SOFTWARE
61
Capability layer
HIS Services
Administration
Quality Monitor/control attributes
... Security Intrusion
Fire
Flood
...
Direct
HMI
Usability Scheduled
Operating environment layer
Safety Scalability
Standard Advanced ... Detection Action Detection Action Detection Action Door operation Message Gas Pumping ... ... Alarm Water Water Data Voice main Smoke Moisture Motion
Periodic
Communication
Detection devices
...
One-time Eventbased
Reliability
Action devices ... Sprinkler Sump pump
Telephone Internet Motion Smoke Moisture sensor sensor sensor Domain technology layer
Responding strategy
Monitoring and detecting
Discrete Continuous value value Implementation technique layer
Sequential Connection
TCP Composition rules Water requires Sprinkler. Flood requires Moisture sensor. Pumping requires Sump pump. Message requires Communication.
Figure 4. A feature model of the home integration system product line.
62
IEEE SOFTWARE
Redundancy control
Active
UDP Optional feature Alternative feature
Feature interaction problems significantly affect the way components are designed and integrated. They can also affect how products are sold and delivered to customers. Suppose a product line has a large set of features from which customers can select. In this case, analyzing feature interactions for all possible feature combinations and having the components ready for them is probably too difficult. Analyzing feature interactions for each customer selection and handling the problem on a per-customer basis might be more cost-effective. The organization should use this information in designing components, and the MPP marketing strategy should reflect it. Suppose, for example, a flood control feature, which shuts off the water main to the home during a flood, is added to the HIS along with the fire control feature, which turns sprinklers on during a fire. One possible scenario could see sprinklers turning on during a fire and flooding the basement before the fire is under control. This would trigger the flood control feature to shut off the home’s water main, rendering the sprinklers useless. Thus, when features are added
July/August 2002
Priority
Standby
Composed-of relationship Generalization relationship Implemented-by relationship
or integrated, the designer must analyze all possible interactions during product line requirements analysis and design the system so that no undesirable interactions occur. Figure 5 describes policies for handling LE-HIS feature interactions using the Statechart technique. The nested structure of states represents the priority among events, the deepest state having the lowest priority. Notice that the event-monitoring features are independently additive, and the associated activities perform concurrently. Event handling is not independently additive, so the designer should analyze interactions among features and devise and enforce an interaction resolution policy. Once the analyst refines the feature model and develops the product line requirement models, he or she can use this information to refine the MPP, as Figure 1 describes. Because the initial MPP contains delivery methods only for functional and nonfunctional features, the designer should develop product feature delivery methods for design features, such as operational environment and implementation technique features, during refinement.
Smoke level > ?upper smoke level/fire Fire/turn sprinklers on, set off alarm, send message to owner and fire station, unlock doors, open water main
Fire Detection detection No event Door Smoke level < ?lower smoke level/extinguished event handled Motion/intrusion
Intrusion detection
No motion/intrusion resolved Scheduled time/door event
Door event Door event handling
Fire event handling
Intrusion/set off alarm, send message to owner and police, lock doors
Extinguished/shut off sprinklers, turn alarm off, timed event (back to normal, ?time)
Intrusion resolved/ turn alarm off Intrusion event handling
Figure 5. Global control behavior of the low-end home integration system. The left side of the diagram shows event-monitoring activities being executed concurrently, and the right shows event-handling activities and priorities among them.
Restoration from fire event
Scheduled event Fire Detection detection No flood event Flood under control/ open water main Moisture/flood
Flood/ shut off water main
Back to normal
Flood event handling Flood Fire Detection detection
No moisture/flood under control
Conceptual architecture design and architecture refinement In the FORM, architecture design starts with identifying high-level conceptual components and specifying data and control dependencies among them. The MPP is a key design driver. For example, the conceptual architecture for LE-HIS (see the conceptual architecture in Figure 6) consists of three major components (HIS Control, Standby HIS Control, and External Interface components); the Standby HIS Control component is added to meet the legal constraints on reliability by increasing the mean time between failures. Standby HIS Control is activated when HIS Control fails to send the Heartbeat data, thus making the system fault-tolerant. The External Interface component is for external device scalability. It encapsulates the information on external devices and provides a common interface to HIS Control and Standby HIS Control. The next step is to refine the conceptual architecture into process and deployment architectures. The upper portion of Figure 6 shows the process and deployment architecture for
the conceptual architecture’s HIS Control component. (The processes are allocated to one network node.) During refinement, we use the quality attributes from the MPP for architectural style selection and evaluation.12 For example, we select the Independent Component architectural style12 and design the human–machine interface (HMI) process to configure the HIS Configuration and Status information-hiding module so that we can add new external devices easily. Component design Next, we refine the architectural components into concrete components. The product component design consists of specifications of components and relationships among them. Figure 7 shows a UML representation of the component specification of the EventDNMDriver component and relationships with other components. For component design, designers should take the product feature delivery methods in the MPP into consideration. For example, the FORM’s macro language ($IF(;$Flood) [...]) in the component specification of the July/August 2002
IEEE SOFTWARE
63
Figure 6. Architecture design and refinement for the low-end home integration system.
Process and deployment architecture Action request Action Event and action definition Responding definition
Event and action data
HMI command
Heart beat HMI
Architecture refinement
HMI request
Event definition Event detection and monitoring
External device status HIS configuration and status HIS configuration HIS configuration and status and status HIS configuration and status Process
Conceptual architecture HMI command
HMI request
Information hiding module
Message without reply
Loosely coupled message queue
Data access
Communication data
External device status
Sprinkler control
HIS control Heartbeat Standby HIS control HMI command
External device command
Door control
External interface
Sump pump control Water main control
External HMI device request status
Figure 7. Component specification for the EventDNMDriver.
External device command
Event report
Moisture Motion sensor sensor input input
Smoke sensor input
Conceptual component
Data flow
Control flow
FORM component specification for macro processing Component EventDNMDriverGetMoisture( eventGeneration->GenerateEvent(F1. ... ] … }
EventDNMDriver Detection DetectNMonitoring() Detection():Boolean
FireEventDetection
FireEventDetection::FireDetection() pre: smokeSensor.opFlag = true post: if smokeSensor->GetSmoke() >= getEventDefinition->GetDefinition(Fire) then self.isFire = true else self.isFire = false endif
64
IEEE SOFTWARE
July/August 2002
1
Fire: Event isFire: Boolean
EventGeneration 1 GenerateEvent(e:Event)
FireDetection():Boolean 1
UML/OCL specification
calls
1 GetEventDefinition
uses
calls 1 1..*
SmokeSensor Smoke : Integer opFlag : Boolean GetSmoke(): Integer isOperate(): Boolean
EventDefinition: Event ChangeDefinition(e:Event, v:Integer) GetDefinition(e:Event):Integer
About the Authors Kyo C. Kang is a professor at the Pohang University of Science and Technology. His re-
EventDNMDriver in Figure 7 supports the prepackaged LE-HIS feature delivery method. When we select the Flood feature (in Figure 4) as a prepackaged feature, code segments related to it are incorporated into the product at build time. As another example, we refine the HMI process in Figure 6 into a framework, which defines a generic structure for implementing an Advanced HMI feature for HEHIS and a Standard HMI feature for LE-HIS. At product build time, product-specific components for the Advanced HMI and Standard HMI features (in Figure 4) are instantiated from the framework. Depending on the nature of extensions required for product-specific features, we can use techniques such as code generation, encapsulation, parameterization, frameworks, templates, and so on. For example, we could specify the Event Generation component in Figure 7 that encapsulates a policy for handling feature interactions by using a formal specification technique (for example, the Statechart specification in Figure 5). Whenever we add new features, we modify and test the feature interaction specification for correctness, and users can generate new updated program code for the component.
T
he FORM’s connection to the MPP forces organizations to make marketing more “product aware” and to think about how to package, deliver, and maintain features, who will perform these activities, and what the pricing implications are with various alternative approaches. The customer profile and other useful information go directly into product design. This marketing-oriented perspective can uncover critical quality attributes required for product line architecture and component design. By tightly coupling marketing with asset development, we can develop product line assets that will support business goals and satisfy customer needs. We are planning to apply our method to several product lines, including process computer systems for steel manufacturing factories and embedded systems for electrical appliances. Also, we are formalizing our method and extending our tool to support a marketing and product plan.
search interests include software reuse, real-time embedded systems, and automatic code generation. He received a PhD in industrial engineering from the University of Michigan. Contact him at the Dept. of Computer Science and Eng., Pohang Univ. of Science and Technology, San 31 Hyoja-Dong, Pohang, 790-784, Korea;
[email protected].
Jaejoon Lee is a PhD candidate at the Pohang University of Science and Technology,
where he received an MS in computer and communications engineering. He received a BS in mathematics from Sogang University. Contact him at the Dept. of Computer Science and Eng., Pohang Univ. of Science and Technology, San 31 Hyoja-Dong, Pohang, 790-784, Korea;
[email protected].
Patrick Donohoe is a senior member of the technical staff at the Software Engineering Institute of Carnegie Mellon University. His research interests are software product lines and analysis modeling. He received a BA in mathematics and an MS in computer science from Trinity College, Dublin, Ireland. Contact him at the Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, PA 15213;
[email protected].
References 1. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison Wesley Longman, Reading, Mass., 2001. 2. D.M. Weiss and C.T.R. Lai, Software Product-Line Engineering: A Family-Based Software Development Process, Addison Wesley Longman, Reading, Mass., 1999. 3. J. Bosch, Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, Addison Wesley Longman, Reading, Mass., 2000. 4. K.C. Kang et al., “Feature Oriented Product Line Software Engineering: Principles and Guidelines,” to be published in Domain Oriented Systems Development: Practices and Perspectives, Taylor and Francis, London, 2002. 5. K. Kang et al., Feature-Oriented Domain Analysis (FODA) Feasibility Study, tech. report CMU/SEI-90TR-21, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 1990. 6. K. Kang et al., “Using a Marketing and Product Plan as a Key Design Driver for Product Line Asset Development,” G. Chastek, ed., Proc. 2nd Software Product Line Conf., Springer Lecture Notes in Computer Science, vol. 2379, Heidelberg, Germany, 2002. 7. G. Chastek et al., Product Line Analysis: A Practical Introduction, tech. report CMU/SEI-2001-TR-001, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 2001. 8. E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley Longman, Reading, Mass., 1995. 9. K. Czarnecki and U. Eisenecker, Generative Programming: Methods, Tools, and Applications, Addison Wesley Longman, Reading, Mass., 2000. 10. M. Simos et al., Software Technology for Adaptable Reliable Systems (STARS) Organization Domain Modeling (ODM) Guidebook Version 2.0, STARS-VCA025/001/00, Lockheed Martin Tactical Defense Systems, Manassas, Va., 1996. 11. K. Lee, K. Kang, and J. Lee, “Concepts and Guidelines of Feature Modeling for Product Line Software Engineering,” C. Gacek, ed., Proc. 7th Int’l Conf. Software Reuse, Springer Lecture Notes in Computer Science, vol. 2319, Heidelberg, Germany, 2002. 12. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison Wesley Longman, Reading, Mass., 1998.
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
July/August 2002
IEEE SOFTWARE
65
focus
initiating software product lines
Modeling and Using Product Line Variability in Automotive Systems Steffen Thiel and Andreas Hein, Robert Bosch Corporation
utomotive systems provide a broad spectrum of services that fundamentally improve passenger comfort, safety, economy, and security. Parking assistance or adaptive cruise control systems make it easier to operate a car in various driving situations, thus reducing drivers’ workload and increasing their comfort. Safety-related systems, such as automatic stability or airbag control, help drivers avoid or reduce the impact of accidents. Fuel economy systems lower emissions and increase fuel
A Product lines offer a promising approach to automotive system development because they permit strategic reuse of core assets. However, to gain significant economies of scope, variability must be systematically considered throughout the development process. 66
IEEE SOFTWARE
efficiency, while security systems protect the car from unauthorized manipulation. An automotive system typically consists of dedicated processors, software, and interfaces that let the system measure, manipulate, and otherwise interact with its external environment. Designers optimize such systems to reflect specific application characteristics. Apart from a system’s desired functionality, automotive system designers must consider many possibly conflicting qualities and constraints. Developing an automotive system can thus involve hundreds or thousands of variants, adding to the existing engineering complexity. Whereas variability has typically been addressed on a case-by-case basis in late development phases, designers now need a managed, systematic approach to the ever-increasing number of variants. Product lines provide this systematic approach, along with a special focus on vari-
July/August 2002
ability among related products. As we discuss here, systematic planning and continuous variability management is a prerequisite for effective product lines. We’ve developed an approach to modeling and utilizing variability to support the efficient creation of product variants. Our approach is based on experiences with several industrial case studies at Bosch. Before describing them, we explain how product line development meets the major design challenges in the automotive system domain. Product line development Automotive systems typically have thousands of requirements, but some are especially important. Many automotive systems are real-time systems with strict temporal requirements that result from the internal control loops. Thus, a computation’s correctness depends, in part, on its timeliness. 0740-7459/02/$17.00 © 2002 IEEE
Furthermore, designers must guarantee the safety and reliability of the automotive system software and embedded computer, even under harsh conditions including excessive heat or cold, vibration, shock, power supply fluctuations, water, and corrosion. Another essential quality of automotive systems is their availability, or readiness for use. Maintainability might also be important. Legacy software, for example, might have to run on replacement hardware. Finally, security is critical: Developers must be able to guarantee that the system software cannot be easily manipulated. Although many of these challenges involve comprehensive research and analysis, most have been solved by technical means. However, providing such solutions in a way that is both cost-effective and allows a short time-to-market remains challenging for both traditional and platform-based development. Traditional development Today’s automobiles use many automotive systems. Luxury cars, for example, can include more than 80 electronic control units that operate as single, partly networked systems. In these systems, the software portion is often highly adapted to the underlying hardware and implements fixed, very specific functions (such as adjusting seats or lifting windows). Although companies might have considered the development of unifunctional entities cost-effective in the past, it is hardly so when we consider the total functionality of the car’s automotive systems. The disproportionate hardware costs, along with excessive software development and maintenance costs for the various automotive systems, make the conventional “one at a time” approach singularly unattractive. Moreover, the restricted reusability that results from binding software functionality to dedicated hardware—as well as the additional packaging, power consumption, and electromagnetic interference—now make it difficult to profitably engineer automotive systems in the traditional way. Platform-based development To overcome these problems, the industry recently began integrating automotive functions on powerful multipurpose platforms that replace mechanical and electronic components with intelligent software solutions.
For example, companies now use a common platform for infotainment systems (including, for example, a radio, CD player, and navigation system1) and safety systems (including parking assistance and precrash detection2). Although adopting a platform-oriented development permits additional services, more flexibility, and shared hardware use, cost-effectiveness and time-tomarket have still not been addressed. Consequently, the effort required to develop more complex platform software is not fully compensated by the hardware cost savings. The product line approach Despite their high volume, automotive systems nonetheless have numerous variations due to differences among customers, price, and technology. Therefore, a strategic reuse approach that guarantees economies of scope is indispensable. We can achieve this strategic reuse by adopting a product line approach to platform-based development. A software product line is a set of softwareintensive products that share a common, managed feature set that satisfies the specific needs of a particular market segment. Product line development proceeds from a common set of core assets in a prescribed way.3 Economies of scope imply a mass-customization ability,4 which in turn requires a systematic consideration of variability throughout product line development. Paradoxically, the latter is often dismissed as secondary. Nonetheless, as we now describe, this variability is crucial to achieving effective product lines.
Developing product line products differs from developing single products in that variability is an inherent part of the modeling.
Modeling product line variability Developing product line products differs from developing single products in that variability is an inherent part of the modeling. This does not mean that common software engineering practices are obsolete. Rather, we must both extend these practices and develop new ones.5 Variability affects all product line artifacts, from requirements to code. Clearly, we need specific solutions to support the specific customer needs that motivated the variation. However, in current practice, designers often give variability incidental treatment. They typically introduce it during late design or implementation and express it, for example, through myriad compiler switches. Moreover, July/August 2002
IEEE SOFTWARE
67
Core asset development Product line design & implementation
produces Product line feature model
used_for
Product line architecting used_for
Product line analysis
produces
maps_to
Product line architecture
produces Components and source code
maps_to
Figure 1. Managing variability throughout core asset development. The figure shows a representative set of processes (light green boxes) and artifacts (dark green boxes).
designers often introduce a variation point based on heuristics or expert knowledge. The documentation of variable requirements addressed by a variation point is often implicit, making the variation’s rationale hard to identify. With such an approach, product customization—and especially the integration of new features—is complex and error-prone. Therefore, handling variability late in development eliminates the company’s ability to achieve significant economies of scope. Our approach addresses these problems by systematically and continuously incorporating variability throughout product line engineering. We must introduce and refine variability
during core asset development and reflect variability in the production artifacts.6 Figure 1 shows a representative set of processes and artifacts; a more comprehensive overview is available in the literature.3 Feature model The feature model is an essential result of product line requirements analysis.7–10 It captures product line members’ functional and nonfunctional capabilities, as well as their commonalities and variabilities. It also provides various stakeholders with a valuable view of the product line. For example, customers can use the feature model to gain an understanding of the product line’s functionality, while system architects and product engineers use it to drive the development of product variants. Figure 2 shows a simplified example of a feature model for a car periphery supervision product line. CPS systems provide passenger comfort and safety functions based on sensors that detect objects in the vehicle environment. The feature model structures CPS product line capabilities into a tree that shows designers which variants to create and a constraint network that coordinates their combination. For clarity, we’ve omitted the constraints network in Figure 2, which shows only the tree structure:
Car periphery supervision systems
F1 Application
F3 Parking support
F7 Distance indication
F13 Front
F2 Sensor equipment
F4 Precrash detection
F8 Steering assistance
F5 Front
F9 Low-end
F10 High-end
F6 Rear
F11 Low-end
F12 High-end
F14 Rear
Figure 2. A feature model for a product line that provides car periphery supervision, which uses sensors to detect objects in the vehicle’s environment. “F” indicates a feature. Filled arches indicate or-features and empty arches indicate alternative features; filled circles indicate mandatory features and empty circles indicate optional features.10 68
IEEE SOFTWARE
July/August 2002
Precrash detection
Situation evaluation
Steering assistance
Situation evaluation
Distance indication
F1
F7
Sensor mode
VP1 Application
VP3
(a)
Smart Sensor (rear left)
Smart Sensor (rear right)
F2
F5 F6
VP2
VP5
VP6
Indication range
Supervision range
Sensor type
Priority management
Sensor control
Smart Sensor (mid front)
Component groups Interaction Dependency
VP4
Measurement coordination
(b)
Figure 3. Variability in the (a) logical architecture and the (b) physical architecture. The variation points satisfy the variability among the requirements in Figure 2. “F” indicates a feature and “VP” a variation point. ■ ■
The application branch is concerned with the intended CPS system functionality. The sensor equipment branch shows the hardware variants required to realize the sensor platform on which the functionality is based.
As Figure 2 illustrates, a CPS system includes at least one of two applications: parking support and precrash detection. Parking support basically consists of reardistance indication; we can enhance it with front-distance indication and steering assistance. We can define sensor equipment for the car’s front or rear, applying either a lowor high-end variant for each. Product line architecture Architecture is the first design artifact that places requirements into the solution space. Designers typically organize the architecture description into multiple architectural views. Each view represents the target system from a particular perspective while addressing one or more stakeholder concerns. With a product line, the architecture must also capture design element variability.3,6,11 Architectural variability represents alternative design options that could not be bound during architectural modeling. Designers often express this variability as a set of architectural variation points that show (part of) the architectural solution to variable features.
A feature model does not, however, imply a specific design; rather, it hints about where designers must pay special attention to structuring an architecture—for example, with respect to configurability.11 Nevertheless, configurability is unlikely to be the only attribute a designer must consider during architecture design. In the automotive context, performance, safety, and reliability also play important roles, as mentioned earlier. The final architecture must consider all functional and nonfunctional requirements, including qualities and design constraints. Figure 3a and b shows the variability in the logical and the physical views of the CPS product line architecture. At the architectural level, we introduce variation points to satisfy the variability among the requirements in Figure 2. We characterize each variation point by specifying how and when a variation point applies. As the solid lines between them show, variation points might depend on each other to define consistent component configurations. The logical view contains four variation points. As the arrows indicate, variation point 1 affects a logical component, steering assistance, and two component groups. Variation points 2, 3, and 4 affect only individual logical components (distance indication, sensor control, and measurement coordination, respectively). Additionally, there are dependencies between variation points 1 and 3, 1 and July/August 2002
IEEE SOFTWARE
69
Product development Product line feature model
Product line architecture maps_to
used_for Feature configuration
used_for Architecture configuration
produces
produces Derived architecture
Product features
used_for
used_for
Architecture adaptation produces
map_to
Figure 4. Interaction between the feature and architecture models to utilize variability. Light green boxes represent processes; dark green boxes represent artifacts.
Product architecture
4, and 2 and 5. Variation point 2 parameterizes the indication range software, whereas variation points 5 (supervision range) and 6 (sensor type) map the corresponding elements to the hardware platform. Thus, variation points 5 and 6 are part of the CPS’s physical view, describing the sensor equipment that the specified functionality requires. Variability also affects other architectural views, including the process and deployment views, which we discuss elsewhere.11 Other work products The feature model and architecture documentation represent only a portion of the work products required for product line development. The feature model represents product line members’ particular capabilities, while the product line architecture offers the overall structure for realizing these capabilities. To create product line members, designers must consistently refine design solutions for realizing both the common and variable features during detailed design and implementation. Not all variable features will inevitably affect the architecture’s overall organization. Rather, designers encapsulate some variability from the architectural viewpoint, and it first appears at a more detailed level. In automotive systems in particular, there are
70
IEEE SOFTWARE
July/August 2002
problems (and variations among them) that designers can adequately address through component design or code constructs. Examples include algorithmic conversions of feedback control activities, software code encryption to prevent unauthorized tuning, or runtime data and instruction compression for optimizing memory efficiency. As designers refine the architecture during design and implementation, the number of variation points usually increases because the mechanisms must ultimately be realized through constructs at a lower abstraction level. Nevertheless, the concrete solutions we use to implement a variation point must conform to the conventions defined in the architecture. To control this process, establishing adequate traceability links—which reveal the rationale behind a code-level variation—is vital. Using product line variability As we mentioned earlier, work products created during product line development do not exist in isolation. Rather, they relate to each other as designers refine and realize requirements stepwise from analysis to code. Stepwise refinement includes the variability identified first in the feature model, then implemented in architectural variation points. Designers should explicitly map features to the corresponding architectural variation points. In principle, this mapping shows how the architecture’s variability mechanisms contribute to the realization of the feature model’s variability. In Figure 3, we denote this mapping using feature identifiers attached to the architectural variation points. For example, the options associated with the application feature (F1) affect the architectural variation point 1. This point is associated with the corresponding logical components in the product line architecture. Variation points 3 and 4 are only indirectly affected by feature variants (through their relationship to variation point 1). Variation point 6 depends on both the feature specification of the front (F5) and rear (F6) sensor equipment. This example raises two major points: ■
The correspondence between features and architectural variation points is rarely 1:1 (F5 and F6 both map to variation point 6, for example).
F1 Application F3 Parking support F7 Distance indication
Situation evaluation
F2 Sensor equipment F6 Rear
VP1
Distance indication
Smart sensor (rear left)
Smart sensor (rear right)
Application
F11 Low-end Sensor VP3 mode
Priority VP4 management
F14 Rear Sensor control
(a)
(b) Component groups
■
Measurement coordination
The architectural variation points do not introduce new variability; rather, they realize the feature model’s variability. Variation points 3 and 4 do not contradict this statement; they simply support variation point 1 and F1, respectively.
The traces between the features and the architecture not only help stakeholders understand how designers have realized product line variability, but also can be effectively used for product derivation. We therefore propose an extension to the concept of feature modeling to support the development of product line members, starting from their feature specifications.8,12 The basic idea is to choose among the different feature options and resolve the variability according to customer needs. For example, we might specify a low-end parking support that displays distances to rear obstacles by selecting the features F3 and F11 (see Figure 2). Such selections must be consistent with the relationships among features. Following feature selection, a product developer can use a configuration tool to propagate the selections to the architecture. Figure 4 shows how the feature and architecture models work together. The product line’s feature model serves as a starting point for deriving a product. In the feature configuration process, we use the feature model to specify products in terms of features. Then, in the architecture configuration process, we use the specified product features to bind the corresponding
(c) Interaction
Dependency
variation points in the product line architecture by using the traceability between the product line feature model and architecture. The result is a derived architecture that conforms to the product features. The architecture also serves as the basis for potential customizations in the architecture-adaptation process, which yields the actual product architecture. To support product architecture maintenance, product developers should preserve the traces between the derived architecture and the corresponding product features. The reason for this is that product developers eventually must adapt an architecture to add features specific to only a few products. The decision about what is built “inside” and “outside” a product line is based on business considerations that shape the product line’s scope. In practice, new features that are not directly supported by the current product line architecture still must be included to satisfy all customer requirements. However, slight adaptations are acceptable as long as those features require only small, local changes to the architecture and don’t negatively affect the overall architectural quality. Generally, management must make an explicit decision about whether to include such “extra features” at the product or product line level. Figure 5 shows the product features, the corresponding variation points in the logical view, and the derived physical architecture. Because we selected F3 and F11, we must select other features as well. F7 and F14, for
Figure 5. CPS parking support variant, including (a) product features, (b) the related variation points in a portion of the logical view, and (c) a portion of the derived physical view, which contains no variability and can thus be input directly into the product architecture.
July/August 2002
IEEE SOFTWARE
71
Work products created during product line development do not exist in isolation.
example, are mandatory parts in every parking-support application (see Figure 2, for example). The derived logical view consistently excludes steering assistance and precrash detection but still contains variation points that must be resolved as part of the product architecture design. The derived physical view contains no variability after resolving variation points 5 and 6 according to the feature selections, so we can use it as direct input to the product architecture.
W
e are currently working on concepts and techniques to extend and improve variability modeling and management for industrial applications. Our research areas include representation issues and modeling and traceability guidelines for different development phases, as well as tools that exploit variation points to support efficient product creation. In addition to these topics, we are working to refine our system-engineering processes to make product line development more effective.
References 1. P. Motz et al., “Mobile Media Open Computing Platform,” Proc. In-Vehicle Software 2001 (SP-1587), SAE 2001 World Congress, Soc. of Automotive Engineers, Warrendale, Pa., 2001, pp. 135–153. 2. S. Thiel et al., “A Case Study in Applying a Product Line Approach for Car Periphery Supervision Systems,” Proc. In-Vehicle Software 2001 (SP-1587), SAE 2001 World Congress, Soc. of Automotive Engineers, Warrendale, Pa., 2001, pp. 43–55. 3. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, Boston, 2001. 4. C.W. Krueger, “Easing the Transition to Software Mass Customization,” Software Product Family Engineering, F. van der Linden, ed., Lecture Notes in Computer Science no. 2290, Springer-Verlag, Berlin, 2002, pp. 282–293. 5. S. Thiel, “On the Definition of a Framework for an Architecting Process Supporting Product Family Development,” Software Product Family Engineering, F. van der Linden, ed., Lecture Notes in Computer Science no. 2290, Springer-Verlag, Berlin, 2002, pp. 125–142. 6. F. Bachmann and L. Bass, “Managing Variability in Software Architectures,” Proc. Symp. Software Reusability: Putting Software Reuse in Context, ACM Press, New York, 2001, pp. 126–132. 7. G. Chastek et al., Product Line Analysis: A Practical Introduction, tech. report CMU/SEI-2001-TR-001, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 2001. 8. A. Hein, J. MacGregor, and S. Thiel, Configuring Software Product Line Features, tech. report 2001-14, Dept. of Computer Science, Univ. of Karlsruhe, Karlsruhe, Germany, 2001, pp. 67–69. 9. K.C. Kang et al., Feature-Oriented Domain Analysis (FODA) Feasibility Study, tech. report CMU/SEI-90TR-21, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 1990. 10. K. Czarnecki and U.W. Eisenecker, Generative Programming: Methods, Tools, and Applications, AddisonWesley, Boston, 2000. 11. S. Thiel and A. Hein, “Systematic Integration of Variability into Product Line Architecture Design,” to be published in Proc. 2nd Software Product Line Conf. (SPLC2), Springer-Verlag, Berlin, 2002. 12. A. Hein, M. Schlick, and R. Vinga-Martins, “Applying Feature Models in Industrial Settings,” Software Product Lines: Experience and Research Directions, P. Donohoe, ed., Kluwer Academic Publishers, Boston, 2000, pp. 47–70.
About the Authors Steffen Thiel is project leader for product line improvements in the Software Technology De-
partment of Robert Bosch Corporate Research and Development in Frankfurt, Germany. At Bosch, he was responsible for the European product line research project ESAPS and is now leading Bosch activities for its successor, CAFÉ. Prior to his product line activities, he developed intelligent vehicle information systems at Bosch. His research interests include requirements and feature analysis, quality-driven architectural design, product derivation, and evolution. He received a diploma in computer science from the Technical University of Darmstadt. He is a member of the IEEE Computer Society. Contact him at Robert Bosch Corp., Corporate Research and Development, Software Technology, P.O. Box 94 03 50, D-60461, Frankfurt, Germany;
[email protected]. Andreas Hein is a member of the scientific staff at the Corporate R&D Department for
Software Technology at Robert Bosch Corporate Research and Development in Frankfurt, Germany. He has worked on several European software product line projects, including PRAISE, ESAPS, and CAFÉ. In addition to product lines, his research interests are in software engineering practices and configuration systems. He received a diploma in computer science from the Technical University of Darmstadt. Contact him at Robert Bosch Corp., Corporate Research and Development, Software Technology, P.O. Box 94 03 50, D-60461, Frankfurt, Germany;
[email protected].
72
IEEE SOFTWARE
July/August 2002
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
focus
initiating software product lines
Developing Mobile Browsers in a Product Line Ari Jaaksi, Nokia
software product line is a set of systems sharing a common, managed suite of features that satisfy a particular market or mission’s needs and that are developed in a prescribed way.1,2 A software product line basically consists of a family of interrelated software products—applications that use a pool of core assets, such as software components, documents, processes, and tools. The organization developing a product line is inseparable from the systems
A Developers at Nokia recently initiated and used a product line to create and deliver mobile browser products. They learned that, to succeed, a software product line must be product and application driven, rather than reuse or platform driven.
0740-7459/02/$17.00 © 2002 IEEE
themselves: Satisfying a particular market segment’s specific needs and operating in a prescribed way require solid requirements and operational management. A product line organization must therefore be a complete product creation and delivery entity that collects and analyzes requirements, creates the products, delivers them to customers or distributors, and supports them after delivery. It functions under a management that has full responsibility for maintaining the core assets and creating and delivering software products. At Nokia, we used a product line to develop mobile browser products that let mobile phone or personal digital assistant users access services over wireless telecommunications networks. We developed the technology first for our own handsets and later distributed it as a software product. We had two reasons to initiate the product line. First, we needed to serve an increasingly
heterogeneous customer base. Second, we wanted to benefit from large-scale reuse. Neither of these reasons alone would have justified initiating a new product line. However, the product line approach provided us with tools to achieve both of these goals and was therefore well justified. Our experience at Nokia can serve as a case study for other organizations debating a similar transition. Mobile browsers and tools In 1999, we launched the Nokia Browsers and Tools product line. The technology was initially based on the Wireless Application Protocol specification, which specifies, among other things, mark-up and scripting languages and a communication protocol.3 We started by developing a WAP browser and toolkit (see Figure 1). We then extended our product family to include three browser products and a multimode toolkit product. We named the generic version of the browser July/August 2002
IEEE SOFTWARE
73
Figure 1. (a) The Nokia Mobile Internet Toolkit and (b) an early browser phone.
(a)
Nokia Mobile Browser. We offered it as a software product to external customers seeking a portable mobile browser, and we delivered it as a source code product with a reference implementation on Windows. The Nokia operating system version of the browser included Nokia-platform-specific adaptations and interfaces. We delivered it internally and ran it on Nokia’s proprietary phone platforms. We tailored the Symbian OS version of the browser for the Symbian operating system with C++ wrappers and Symbian extensions. We also delivered it as a source code product. The Nokia Mobile Internet Toolkit was a phone simulator coupled with a development environment running on Windows platforms. We distributed it over the www.nokia.com Web site for content developers. By the end of 2001, we had several customers for all the embedded browsers, and the toolkit had approximately 500,000 registered users. We had many common requirements for all the products. These included requirements for implementing the Extensible Hypertext Markup Language (XHTML) with Cascading Style Sheets and the Wireless Markup Language 1.x browser, supporting both languages natively.3,4 All products required connectivity through the specified protocol, and we tested all of them for interoperability with wireless gateways. Several requirements varied from one product to the next. A small phone, such as 74
IEEE SOFTWARE
July/August 2002
(b)
the Nokia 6210, requires a compact C implementation with small memory consumption. A more advanced device, such as the Nokia 7650, requires C++ interfaces, integration with various personal information management applications, and other more advanced features. Our external customers, such as AOL, Samsung, and Symbian, needed a compact implementation with no dependencies on Nokia’s proprietary phone platforms. The toolkit required accurate duplication of phone behavior on the Windows platform, a separate content development environment, and hooks to plug in to various third-party components. In spite of their differences, all the products used a common product line core, which included elements such as protocol stacks, markup and scripting handling components, and layout managers. We implemented the core in C, and it consisted of approximately 300,000 lines of code. Developing the product line A product line must benefit customers by helping the software organization build better products. Therefore, we first concentrated on the specification and speedy delivery of individual products. We built the product line only after our first product releases, which helped us get the first products out quickly. As an example, we needed to get phone simulators and authoring tools out to con-
tent developers before browser phones were available. We implemented a browser simulator from scratch, using Java for speedy development instead of the existing C-based browser components. In a later release, we replaced the Java-based simulators with Cbased simulators that originated from the product line.
Browser Layout manager User agent
Browser utilities
Loader Protocol stack Session
The origin of Nokia’s product line assets In 1998, the US Nokia team started to develop mobile browser modules such as a script engine and WML markup handling routines for the Nokia 7110, the first WAP browser phone. There were no requirements to make code available on any other platform or to document or packetize it as a software product. The group simply developed software components to a specific hardware device. We also started to develop the Nokia WAP Toolkit—a WAP simulation and content development environment—which we released on 17 December 1998, only four months after the project’s initiation. The product included full WML and WMLScript development facilities with a WAP phone simulation. Simultaneously, another team developed WAP gateway products, creating a client-side protocol stack to test gateway protocols. The development happened at Nokia Hungary, with several components coming from other Nokia groups. The protocol stack was not tailored for small devices nor designed for use as part of a software product. A team in Denmark implemented and adapted browser technology to specific Nokia phone models. The team had another implementation of the WAP protocol stack running in a phone that was small but designed to work only on Nokia’s own platform. Thus, we had many components available for the product line: several core browser components, the WAP Toolkit developed as an authoring tool and simulator, a WAP protocol implementation built as a WAP test suite, and a Nokia platform-dependent protocol stack developed to run only in Nokia phones. We developed and maintained all these components separately. Clearly, it was time for a product line. Incorporating existing components In April 1999, we decided to integrate
Figure 2. The Nokia product line architecture.
Portability layer
Transaction Security
Protocol utilities
APIs to cache, persistent stotage, memory, strings, math, messaging, settings, logging, time, and so on
Datagram
available browser components, put the browser on different Nokia phones, and offer it to external customers such as device manufacturers and telecom operators. This was the first time Nokia licensed out its own phone software—we had already distributed the WAP Toolkit. Now that we needed to develop two different products with a lot of overlapping functionality, we decided to organize the common parts into a product line. Thus began the Nokia Browsers and Tools product line. We selected the core browser components and the test protocol stack to form the initial product line. We first enhanced these components to meet our key product requirements of full WAP implementation, portability, and product quality. To meet the implementation requirement, we set up a project to build missing functionality. We also set up an interoperability test suite to verify that we had implemented the standard as specified. To meet the portability requirement, we removed all dependencies to Nokia phone platforms and used only ANSI C and a limited set of standard libraries. We modified all components, especially the protocol stack, to be suitable for small portable devices. Finally, we isolated platform-dependent code and APIs into a portability layer (see Figure 2). At this time, we kept the toolkit separate and didn’t use common software components in it. However, the toolkit benefited from the product line’s requirements, testing facilities, documentation, and software development processes. We analyzed the two available stack implementations: the generic test suite implementation and the Nokia platform-specific July/August 2002
IEEE SOFTWARE
75
We cleaned, tested, verified, and documented the acquired components to achieve product quality.
compact protocol stack. We chose the generic one. The effort of making platform specific code generic and portable seemed to exceed the work needed to tailor an existing generic stack to meet a small device’s requirements. We cleaned, tested, verified, and documented the acquired components to achieve product quality. We concluded that inconsistent error handling, memory management, and coding standards were our most critical problems. We set up a separate maintenance project to clean the memory management, which was all we had time for. To achieve product quality, we needed first to assess existing quality. We needed the information to focus our development efforts and to set customer expectations right. We constructed test suites, trained personnel, contacted other vendors for interoperability testing, and set up rules and procedures for testing the product line. We also created customer documentation, which was a major effort: none of the original product line components except the toolkit had any customer documentation. To give an idea of the task’s difficulty, the porting guide for the Nokia Mobile Browser consists of almost 500 pages, and the toolkit documentation exceeds 300 pages. After eight months of cleanup, implementation, testing, and documentation, we released the 1.0 version of the generic browser product from the product line. We now had a pool of core assets on which to build our future products. The fact that most of our core assets were already being used in existing products demonstrated that our technology worked. Organization and processes As I mentioned earlier, the technical product line architecture and the developing organization’s structure must resemble each other. We had five separate functional entities in our product line organization: ■
■
76
IEEE SOFTWARE
Product management collected, analyzed, and prioritized product requirements; created requirements specifications and roadmaps; and oversaw the functionality of all products. Product development owned the architecture and implementation resources and ran the development projects.
July/August 2002
■ ■ ■
System testing tested and released the final products. Customer support assisted customers in using our products. Advanced development ran the standardization work and provided architectural studies, prototypes, and demonstrations of new technologies and features.
Development took place in the US, but we developed parts of the product line in Finland and Hungary. By the end of 2001, the product line organization employed over 100 people. We released approximately six major product releases each year. Requirements analysis in product management During the analysis phase, a product manager responsible for a specific version of a product would create a requirement specification document that analyzed and prioritized requirements for the product release in question. However, this document didn’t specify requirements for the whole product line. During the first two product projects, we tried to allocate product requirements directly to the product line components, which we soon discovered to be difficult. Our customers wanted to discuss features and products, not components. Also, our product management didn’t have the technical expertise to allocate product requirements to technical components. Thus, we started to map requirements directly to product releases. Further allocation to separate components happened later in the design phase. Product managers maintained roadmaps that outlined the characteristics of individual products for the next few years. The product board—composed of participants from all functions of the product line and from major customers—reviewed all the roadmaps together. Such review meetings synchronized different product features: if a feature appeared first in one product’s roadmap and then later in others, synchronizing our products provided a means of domain analysis over all the products we developed. Software creation in product development Our product development organization
had four teams—namely, the core team, the platforms team, the toolkit team, and the testing team. The teams were competency centers with a certain technical focus, and they allocated their resources to various product development projects. The core team was further divided into the browser and protocol teams. These teams maintained the core product line— the reusable assets that all the products used. The platforms team specialized in porting the core product to the various hardware and software platforms. The toolkit team developed the toolkit product. The testing team maintained the tools and expertise to test the various products developed from the product line. Product managers defined a product release’s requirements in a requirement specification. The engineering teams analyzed this specification and extracted generic functionality into the product line core, with the goal being to make the core as big as possible. Then, the core team members within the projects handled the common core parts while platform and toolkit teams handled platform- and customer-specific parts within development projects. The core team had an architect responsible for the product line’s architecture. She used the requirements specifications, her expertise, and the platforms and toolkit expertise of the other teams to create a functional specification document. This document was an engineering view of the requirements and specified how to develop products and reusable components. Thus, the core team maintained the product line architecture. We had only a few projects in which to develop product line components independently from any product release. Typically, we allocated product line maintenance work inside individual product projects, prioritizing component development efforts and embedding them into our tightly scheduled product development projects.5 This ensured strong product focus but made caring for the product line architecture a challenge. Our design and implementation phases of the development projects included several cycles that resembled other software projects at Nokia.5,6 First, each new product release built on the previous one. Second, we built individual product releases incrementally. Our internal customer often wanted
intermediate releases during the development project. Finally, we used daily builds,7 which ensured that one project modifying the product line would not harm another concurrent project using the same components. Daily builds also let us detect problems early. Developing products from a product line calls for solid configuration management. We stored all the phase products such as documents, test cases, and code in a centralized configuration management system. We shared the system with our internal customers who needed early access to the configuration items. A test lead developed the initial test plan based on the functional specification. We conducted system and interoperability testing as part of the product projects—different products shared test suites and cases. We also invested a lot in the implementation of reusable test suites. They formed an important part of the product line’s core assets and let us reuse test cases, tools, and expertise. We originally planned to test software components independently and then assemble product releases from these tested components, but we soon realized that this was not enough. Every product needed full testing on different operating systems, with different applications and memory constraints. We never trusted that a component tested in the context of one product would automatically work in the context of another. Instead, we tested all components separately for each delivered product version, using a regression testing approach. A project board run by the product line management oversaw all the development projects. It reviewed all projects on a regular basis to ensure timely and synchronized project execution, solve resource conflicts between projects, and assign resources to work on common tasks outside the product projects. The board was a key means of maintaining a coherent product line view within individual development projects.
Developing products from a product line calls for solid configuration management.
Innovation and standardization in advanced development Developing products for emerging markets calls for innovation and standardization. We had a dedicated advanced development team that demonstrated new technologies and provided information and ideas to the July/August 2002
IEEE SOFTWARE
77
Our XHTML browsing feature is a good example of successful innovation and standardization.
other teams. The team also provided requirements and expertise on emerging standards to the rest of the organization and worked within standardization bodies, such as the WAP forum, to drive standards. Our XHTML browsing feature is a good example of successful innovation and standardization. To the best of our knowledge, our product line was the first to provide a mobile XHTML browser with Cascading Style Sheet and full WAP 1.x support. Our advanced development team created the basic architecture and demonstrated an XHTML browser for a phone at the end of 2000. The demo provided us with early customer feedback and verified that the implementation was possible within the given memory and computing restrictions. The team also worked closely with the product development that ramped up the XHTML browser’s development and released the Nokia Mobile Browser 3.0 in summer 2001. Finally, the team got the core of our XHTML approach approved as the new WML 2.0 standard.8 Benefits versus cost A product line increases quality, shortens time to market, and helps specify the “right” product features. Strong process structures help manage complexity and conflicts between the requirements of individual products and projects. Skilled architects and architectural guidelines can mitigate challenges in architectural development. Benefits We experienced increased efficiency through reuse as well as accelerated product implementation, lowered cost, and increased quality. We could not have developed four different products and six annual releases with our given resources without a product line. We analyzed requirements originating from one product in the context of all other products and used this accumulated domain understanding to benefit the whole product line. Such a process helped us identify new requirements early and let one product benefit from the requirements of others. This also helped us detail feature sets and build competitive products. Understanding the domain helped us specify new products accurately. The product line provided a clear focus
78
IEEE SOFTWARE
July/August 2002
and set the management, processes, tools, and other support elements, which attracted and motivated high-quality personnel. Our product line was highly rated in our annual “Nokia Listening to You” questionnaires in which employees rate their working conditions. We also managed to retain our employees. In 1999 and 2000, when various startup companies offered potentially larger benefits than we did, we lost less than 3 percent of our workforce. That we retained our key experts and team leaders further increased productivity and motivation. The product line also increased our credibility and demonstrated our long-term commitments. Showing different products developed from the same product line running on different platforms provided a convincing demonstration of our technology. Within Nokia, we became not only the source of browsers and tools but also a center of expertise on XML, XHTML, scripting, and other related technologies. Costs and risks Compared to developing a single product, the product line required extra resources in process and tools development, core development, and product management. To minimize costs, we avoided developing core assets that we would not reuse. For example, we considered a potentially reusable library with no need for reuse as a waste. It becomes an inventory that does not benefit the product line and constrains the organization’s throughput.9 We occasionally witnessed cases where the creation of core assets significantly delayed the shipment of the first products to customers. We considered this to be one of the biggest risks and prioritized getting products out quickly—even if such a move delayed core asset creation. Therefore, we first built product releases and then extracted components from them. Only when a clear case for reuse became apparent did we incorporate the asset into the core. We had challenges in developing a coherent product line architecture. Such architecture cannot be optimized for a single product but must support the conflicting requirements of many products. Our architecture managed to accommodate different product needs and integrate components originally developed for different architectures. These
sources provided us with a head start but compromised the overall architecture by introducing several different designs and coding styles within the product line. This was visible in the context of our generic browser, which we distributed as a source code product. Our customers had to learn different styles depending on the component they were integrating or modifying. Our product line supported four different products by providing them with reusable core assets, so modifying these assets could potentially affect all products. We managed such dependencies through controlled requirements management, project synchronization, configuration management, and architecture development. We expected all teams to follow the documented software development life cycle, which implemented several milestones with approval points. Our project board synchronized projects, and our product board synchronized product roadmaps and features. Our architect was a gatekeeper, approving all design and API changes. We also used strict software configuration management processes and tools. Changing plans, components, or APIs required approvals to be acquired and communicated appropriately. All these practices aimed at good quality in predictable product projects at the expense of increased bureaucracy. We also experienced some conflicts between project teams. Our employees received incentives based on releasing their products on time, yet their work depended on the product line. We had cases in which a project team felt that it didn’t get adequate support from the product line, which made blaming others for missed delivery dates easy. We first handled these conflicts through our project board; later, we added product line maintenance into our bonus schemes. However, we never quite managed to solve conflicts between teams relying on each other’s work. It seems such conflicts are built into product lines. A product line can also cause conflicts between customers. They do not always welcome the idea of our developing a product line instead of just their product. As an example, a major customer approved a requirements specification for the next release of its browser product. Later, we showed the client a functional specification and
project plans that allocated work to product line components. The client questioned our approach, because it wanted us to concentrate on its product only. Explaining a product line’s benefits to a customer of a single product was sometimes difficult. Moreover, testing a product line is more complex than testing a single software product. We must test the product line in its various configurations, which easily multiplies the number of test cases. To manage this complexity, we system tested individual product releases instead of testing the whole product line. This kept testing simple and guaranteed the quality of product releases. However, we did not build a pool of tested core assets ready for integration, which probably increased the need to test each product release. We had approximately 25 percent of the product line personnel working on testing teams, so the testing phase took approximately 30 percent of the entire time of developing a software product release.
Testing a product line is more complex than testing a single software product.
F
or Nokia, the product line approach’s benefits clearly outnumbered its costs. We reused our core assets extensively, and we succeeded in serving a diverse customer base, from content developers to device manufacturers and software companies. Such experiences are motivating us to launch new product lines and convert existing activities to use the product line approach. An important future challenge—not just for Nokia—is to learn to reengineer existing product lines to accommodate new business, technical, and customer requirements. The product line increased costs in various support functions, architectural work, and management. We therefore suggest that an organization consider initiating a product line only when it both aims at systematic reuse and serves a heterogeneous customer base with a common domain. Based on our experiences, you can achieve fairly high levels of reuse without developing and maintaining an entire product line—for example, by using independent code components.5 You might better serve a homogeneous customer base by adapting a single product for different purposes. Moreover, without a common domain, the pool of core assets July/August 2002
IEEE SOFTWARE
79
About the Author Ari Jaaksi heads the Nokia Mobile Phones software and protocols research organization in
Finland. His research interests include development methodologies, architectures, and software development organizations. He received his PhD in software engineering from Tampere University of Technology. Contact him at Nokia Mobile Phones, PO Box 1000, 33721 Tampere, Finland;
[email protected].
might not grow big enough to be beneficial. We believe that a software development organization should resemble the development view to the software architecture.6,10 The processes and organizational structures must support the product line architecture. Components must have owners, deliverables must be allocated to teams and projects to develop them, and the interaction between teams must resemble the interaction of the software components in a product line. Thus, coupling the product line and the organization is important. They need to develop hand in hand.
Building a product line is a long-term effort in which the benefits come through reuse, which can only come after several product releases. We believe that building a few products first is the right way to initiate a product line. Early products provide customer feedback and prevent the construction of useless assets. A product line needs a long-term management commitment together with skills to build it step by step. It is an investment that can be made if business conditions call for a long-term commitment to deliver several products sharing a common domain.
Acknowledgments I thank my colleagues Raouf Bortcosh, Greg Carpenter, and Konstantinos Kalabokis at Nokia for building and managing the product line with me and helping me write this article. I also thank Ilkka Haikala and Kai Koskimies at Tampere University of Technology for their valuable feedback.
References 1. L. Bass et al., Product Line Practice Workshop Report, CMU/SEI-97-TR-003, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 1997; www.sei.cmu.edu/ publications/documents/97.reports/97tr003/97tr003abstract. html. 2. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, Reading, Mass., 2002. 3. Wireless Application Forum, Official Wireless Application Protocol: The Complete Standard, John Wiley & Sons, New York, 1999. 4. World Wide Web Consortium, XHTML 1.0: The Extensible HyperText Markup Language, 2000; www.w3. org/TR/xhtml1. 5. M. Laitkorpi and A. Jaaksi, “Extending the Object-Oriented Software Process with Component-Oriented Design,” J. Object-Oriented Programming, vol. 12, no. 1, Mar./Apr. 1999, pp. 41–50. 6. A. Jaaksi et al., “Tried & True Object Development,” Industry-Proven Approaches with UML, Cambridge Univ. Press, Cambridge, UK, 1999. 7. S. McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond, Wash., 1996. 8. WAP Forum, Wireless Application Protocol, WAP 2.0: Technical White Paper, Jan. 2002; www.wapforum. org/what/WAPWhite_Paper1.pdf. 9. E. Goldratt, The Goal—A Process of Ongoing Improvement, North River Press, Great Barrington, Mass., 1992. 10. P.B. Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, vol. 12, no. 6, Nov./Dec. 1995, pp. 42–50.
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
80
IEEE SOFTWARE
July/August 2002
software construction Editors: Andy Hunt and Dave Thomas ■ The Pragmatic Programmers a n d y @ p r a g m a t i c p r o g r a m m e r. c o m ■ d a v e @ p r a g m a t i c p r o g r a m m e r. c o m
Naked Objects Richard Pawson
O
n a recent visit to Norway, I was served the customary lunch of openfaced sandwiches. I don’t understand the logic of the open-faced sandwich—all the work of preparing a sandwich, but you still have to eat it with a knife and fork. Perhaps the Norwegian that brought the idea of the sandwich from overseas (our British tradition holds that the Earl of Sandwich invented it) simply lost the key instruction: place another slice of bread on top so that you can pick it up! Some Norwegians might feel the same way about what the rest of the world did to one of their great ideas: object-orientation. Looking at most so-called objectoriented software, you’d think the designers had never heard about the key idea: An object should model some aspect of the business domain— not just its attributes and associations—but all behaviors that might be required of it. This behavioral completeness yields a big benefit, in that changes to the business domain map simply to changes in the software. Actually, many designers intend to create behaviorally complete objects, but just as milk degrades into curds and whey and salad dressing into oil and vinegar, their software seems almost inevitably to separate into process and data. Separating process and data Several years ago I determined to find out what caused this. My research identified several common practices that encourage the separation of process and data in object0740-7459/02/$17.00 © 2002 IEEE
oriented designs. The problem is that none of those practices is a bad habit; each was deliberately designed to overcome some existing problem with software engineering. Let’s look at an example. The argument for the Model-View-Controller pattern and its close-relation, the Entity-Boundary-Controller pattern is that a given business object must be viewed on different platforms, in different contexts, and with different visual representations. Embedding knowledge of how to create these different views in business objects would result in bloated objects with heavy duplication of functionality. Using MVC or EBC, the core business objects (that is, the Model or Entity objects, respectively) have no knowledge of these different presentations. Dedicated presentation objects (that is, the View or Boundary objects) specify what will appear in each view, and know how to create the visual display and accept inputs from the user. Controller objects provide the glue between the two—populating the views with attributes from the business objects and invoking methods on those objects in response to user-initiated events. However, there is a marked tendency for Controller objects to become an explicit representation of business tasks, managing the optimized sequence of activities and enforcing appropriate business rules. In doing so, they usurp the business objects’ natural responsibilities. The presentation objects, meanwhile, often mix attributes from multiple business objects. Before long, the Entity or Model objects become the data representation, and the Controller objects become the process representation. July/August 2002
IEEE SOFTWARE
81
SOFTWARE DEPT CONSTRUCTION TITLE
Figure 1. A prototype for a new government benefits administration system built using Naked Objects. All user actions consist of nounverb style operations on core business objects.
Naked Objects Robert Matthews and I designed Naked Objects, an open-source Javabased framework, to discourage process and data separation and to encourage business system creation from behaviorally complete objects. Naked Objects’ key idea is to directly expose the core business objects (such as Customer, Product, and Order) to the user. All user actions consist of invoking a behavior directly on a business object, either by selecting an icon from a pop-up menu or dragging an object and dropping it on another. There are no top-level menus, or any forms or scripts sitting on the objects. The framework is so radical that it does not even permit the creation of dialog boxes. Applying the principles of Naked Objects One of the first organizations to apply the design principles embodied in Naked Objects is the Irish government’s Department of Social, Community, and Family Affairs. Figure 1 shows a screenshot from a prototype 82
IEEE SOFTWARE
July/August 2002
for a new system, created using Naked Objects, to replace their existing Child Benefit Administration system. That system is now in full-scale development and is near deployment. Although the user interface differs slightly from that shown here, the prototype’s principles have been faithfully preserved. The new architecture, which mimics that of the Naked Objects framework but is tailored to the DSCFA’s own technical environment, will eventually replace all of their existing core business systems. Figure 1 shows several classes of business objects including Customers (the mother and children involved in a claim), Officers, Cases, Payments, Communications, and Schemes (the various legislative schemes that the DSCFA administers—only Child Benefit is included in this prototype), which are represented as icons. Users can double click on any instance to show an expanded view, or they can drag it to the desktop to create a separate viewer. Right clicking on any instance, in any context, produces a popup menu of actions, some of which are
generic and some of which are object specific. These actions all correspond to methods on the business object. For a Customer object, specific actions include Authenticate, Communicate, and RegisterNewChild. Some actions perform simple operations on that object; others initiate more complex transactions. Users can also initiate behaviors by dragging and dropping objects on other objects, or into specific fields within objects. Dragging a Customer instance on the Child Benefit class would cause the system to check if that customer was already claiming child benefit. If not, the system initiates a new claim by creating an instance of the Child Benefit Scheme, inserting a reference to the Customer object inside it, and creating a new instance of Case to track the progress of this claim. The Case owner is the object representing the Officer logged into the system. (The user could also perform each action individually and in a different order). The system also portrays the business object classes directly. A window on the left lists the six primary business object classes that constitute the system. Each class icon has a pop-up menu of class methods. These are mostly generic methods, and include ■ ■ ■ ■
Create a new instance of this class Retrieve an existing instance from storage List instances of this class that match a set of criteria Show any subclasses that are available to the user
Because there is no other mechanism with which users can initiate a business action, the programmers developing an application are forced to encapsulate all required behavior with the core business objects. However, because there is a 1:1 correspondence between the underlying object model and the user interface, Naked Objects can auto-generate the latter from the former. Programmers do not need to write any user interface code to develop a fully working
SOFTWARE DEPT CONSTRUCTION TITLE
application using Naked Objects. Instead, at runtime the framework’s generic viewing mechanism uses Java’s reflection to identify objects’ behaviors and makes these available to the user. Programmers need only follow a few simple conventions when writing business objects in Java. The Naked Objects framework effectively provides the View and Controller roles in generic form— the programmer writes only the Model objects. Most early attempts at auto-generating a user interface from an underlying model, such as some application generators in the 1980s, produced spectacularly poor user interfaces. Naked Objects does rather better. I would not suggest that our user interfaces are in any sense optimal, but they are remarkably expressive and give users a strong sense of control— what Edwin Hutchins, James Hollan, and Donald Norman call “direct engagement”1 and Brenda Laurel calls a “first-person experience.”2 We would even suggest that much of the efforts of the human-computer interface community, which is concerned with optimizing a user interface design for a given set of tasks, is actually counterproductive. Who has not experienced the frustration of being managed by an optimized script when dealing with a customer agent at a call center, for example? I don’t mean to suggest that the user is free to do anything with a Naked Object system—some constraints are genuinely needed. But these constraints are built into the business objects, not into the scripted tasks that usually sit on top of them. The net effect is similar to using a drawing program or a CAD system, but for business transactions. When developing an application using Naked Objects, the 1:1 correspondence between the screen representation and the underlying model means that the business objects now provide a common language for the user and programmer. The auto-generation of one from the other shortens the development cycle to the point where we can now create prototypes
in real time. Most approaches to rapid prototyping develop only the users’ view of the system. Using Naked Objects we are prototyping the object model simultaneously. With Naked Objects, the conventional notion of the user interface simply disappears— programmers don’t even consider a user-interface because they don’t have to develop one and users talk only about the objects with which they deal. New generation of business systems A handful of commercial organizations have already started to use Naked Objects to conceive a new generation of business systems. In each of these projects, the organization has stated that they have never seen such positive communication between developers and users during development. Developers have praised Naked Objects for its “flexibility”—quite an interesting comment given that the framework doesn’t let them do many things they are accustomed to doing, such as customizing the user interface or writing dialog boxes. (The latter is a massive constraint and somewhat difficult to adjust to, but we have found that it forces you to do a better object modeling job.) Programmers frequently comment, “This feels like what I had in my mind when I first en-
“In anything at all, perfection is finally achieved not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness.”
countered OO, and I’ve just realized how far it is from what we’ve actually been doing.” Naked Objects is still in its infancy, but it is developing rapidly. We have much that we still want to do with the framework. We are starting to get offers of help from others who are catching the vision. What pleases us most is that the framework gets simpler with every iteration. You can read more about the design principles behind Naked Objects and download the Java framework from www.nakedobjects.org. Antoine de Saint Exupery wrote that “In anything at all, perfection is finally achieved not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness.” This principle has been one of the inspirations for Naked Objects. I remain to be convinced about the merit of naked sandwiches, though.
References 1. E. Hutchins, J. Hollan, and D. Norman, “Direct Manipulation Interfaces,” User Centered System Design: New Perspectives on HumanComputer Interaction, D. Norman and S. Draper, eds., Lawrence Erlbaum, Hillsdale, N.J., 1986, p. 94. 2. B. Laurel, Computers as Theatre, AddisonWesley, Reading, Mass., 1991, pp. 116–119.
Richard Pawson is a research fellow with Computer Sciences Corporation. He has a BSc in engineering science and is currently earning a PhD in computer science at Trinity College, Dublin. He is coauthor of Naked Objects with Robert Matthews, which will be published by Wiley in November 2002. Contact him at CSC Research Services, 70 Wilson St., London EC2A 2DB, UK;
[email protected]. July/August 2002
IEEE SOFTWARE
83
quality time E d i t o r : J e f f r e y Vo a s
■
Cigital
■
[email protected] Software Safety Alan C. Tribble
I
recently attended a workshop where I found myself sitting between people from Disney and the Nuclear Regulatory Commission. What do these unlikely companions have in common? They’re both concerned about the safety of the software they produce. Given that people can suffer when software fails, this multi-industry concern makes sense. We can argue that we must be doing a good job because we don’t find many software casualties. Accidents are the sixth leading cause of death in the United States. However, if you scan the statistics, you’ll be hard pressed to find anyone blaming software. With the possible exceptions of the Therac25 radiation therapy machine overdoses in the mid-1980s or the Osprey crash in 2000, it’s hard to make a case for many people being injured, let alone killed, by software. Part of this, I think, is a matter of perception. Hurdles I’ve identified four issues that prevent software safety from sometimes getting the attention it deserves. 1. Safety is often confused with security and reliability. Safety is freedom from the conditions that cause accidents. This is a separate idea from security, a system’s ability to resist attempts to influence its operation, or reliability, a system’s ability to continue to provide functionality. The confusion arises because safe sys84
IEEE SOFTWARE
July/August 2002
tems are usually secure and reliable. Safety means worrying about what the system should, might, and shouldn’t do. In my days as a software applications manager, I observed that our users could abuse our products in ways that the developers never imagined. Safety requires you to think about every conceivable way a system might cause harm. 2. Safety is viewed as a system-level problem. We regulate medical devices, not the software itself. Similarly, we certify aircraft, not the software that they carry. If a robot goes out of control and injures someone, we blame the robot first and not its programming. Consequently, we direct most safety analysis at the system level and the hardware that comprises the system. This can overlook faulty software that might have commanded an unsafe action. 3. Software failures are subtle. Hardware failures are easy to spot— cracked structural elements or burned-out electronics are dead giveaways that something’s gone wrong. Software doesn’t fail like hardware, and software failures are usually not so obvious. A software routine will generate the same output, given the same input, consistently. However, software can fail to perform its intended function if it contains requirements, design, or logic errors. You can easily spot logic errors, such as if you code a program to believe that 1 + 1 = 3 instead of 2, but requirements or design errors are harder to find. Frequently, we don’t spot the most fundamental errors until well into the test phase, when the cost of repair is high. 0740-7459/02/$17.00 © 2002 IEEE
QUALITY TIME
4. Safety can’t be proven. Festus, the lovable, illiterate deputy from the old TV show Gunsmoke, often justified his illiteracy by asking, “How do you know the fellow that wrote the writin’, wrote the writin’ right?” Your customers probably ask you, “How do you know the fellow that coded the coding, coded the coding correctly?” Exhaustive testing is usually infeasible, so you can’t always demonstrate compliance for every possible situation. What you can do is show that the code functions properly—and doesn’t exhibit anomalous behavior—for the situations you’ve tested. Similarly, you can’t prove safety. You can only show that you haven’t found the software exhibiting any behavior that would compromise safety. Predictions In spite of these limitations, software safety has a good track record, and as software developers, we want to make sure it stays that way. Unfortunately, change is inevitable. The earliest systems were inherently simple, independent, and understandable. However, customers want additional functionality, so systems will continue to become more complex. As system complexity grows, so will software complexity. This leads to my software safety predictions. 1. Software will grow in importance. As software assumes greater responsibility in more and more systems, safety analysis will have to examine not only the hardware but also the software. This will mean including software in standard safety analysis techniques, such as failure mode and effects analysis or fault tree analysis. 2. Software designers will spend more time worrying about failure modes. Safety analysis starts with hazard analysis—identifying what can go wrong and how bad it will be. Analyzing failure requires a different mind-set. If you focus on success, you only think of ways to build something. When you start considering the possi-
bility of failure, you have to wonder how it could come apart. Software designers will need to consider not only what code should do but also what it could and shouldn’t do. 3. The search for errors will move upstream. As requirements and design errors become more costly, software safety analysis will start moving upstream. Testing finished code functionality won’t stop, but we’ll start testing its design and requirements. Designers will start modeling requirements and seek to prove their completeness and correctness before writing a line of code. This will require a shift to model-based development. Analysis of all forms, including formal methods, will become routine. 4. Showing process compliance won’t be enough. You can’t build in safety after the fact. You need to address it from day one. If you’re going to put a flight control system on a new aircraft, the US Federal Aviation Administration must approve the software. Today, the FAA’s regulating document, DO178B, doesn’t control the final product as much as the process to create the product. The more safety-critical the software, the more rigorously controlled the process. DO-178B mandates 66 compliance objectives for the most critical (Level A) software. You can’t throw together a pile of spaghetti code and go back after the fact and expect to show compliance. To have a chance of success, you’d have to start over, showing control over the process from day one. But process-based compliance, although necessary, will not suffice. We’ll need to show not only that we exhibited good software engineering design practices, but that the product satisfies its safety requirements.
Alan C. Tribble is a principal systems engineer at Rockwell Collins. Contact him at 400 Collins Road, NE (108-206), Cedar Rapids, IA 52498;
[email protected]; www. atribble.com. July/August 2002
IEEE SOFTWARE
85
