Home > Store

Software Product Lines: Practices and Patterns

Register your product to gain access to bonus material or receive a coupon.

Software Product Lines: Practices and Patterns

Book

  • Sorry, this book is no longer in print.
Not for Sale

About

Features

Description

  • Copyright 2002
  • Dimensions: 6-1/4" x 9-1/4"
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-70332-7
  • ISBN-13: 978-0-201-70332-0

Long a standard practice in traditional manufacturing, the concept of product lines is relatively new to the software industry. A software product line is a family of systems that share a common set of core technical assets, with preplanned extensions and variations to address the needs of specific customers or market segments. Software organizations of all types and sizes are discovering that when skillfully implemented, a product line strategy can yield enormous gains in productivity, quality, and time-to-market.

Software Product Lines is the culmination of an intensive investigation, undertaken by the Software Engineering Institute (SEI) at Carnegie Mellon, into how leading-edge software development organizations have "retooled" for product lines. With explanations of fundamental concepts further illuminated by real-world experience, this book spells out the technical issues involved in adopting a product line strategy, as well as the organizational and management issues that are so critical for success. In providing a comprehensive set of practices and patterns, this book defines and explores the key activities for software product line development and explains specific practice areas in engineering, technical management, and organizational management.

Highlights include:

  • The benefits of a software product line approach, including actual improvement data from industrial success stories
  • Methods to develop a reusable base of core assets and to develop products that utilize that core
  • Common problems paired with concrete solutions in the form of reusable software product pine patterns
  • Twenty-nine practice areas for successful implementation, including architecture definition,component development, configuration management, market analysis, and training
  • The product line technical probe for identifying technical and organizational weaknesses that could impede success

Three detailed case studies from the industry lead you step by step through the process of developing and managing software product lines, illustrating potential pitfalls, creative solutions, and the ultimate rewards. Discussion questions, sidebars, and real-world anecdotes from the trenches reveal the collective wisdom of those on the front line of software product line ventures.



0201703327B09102001

Downloads

Supplements

Reader's Guide

This book is a work in three parts.

Part I is called "Software Product Line Fundamentals," and its three chapters lay out the conceptual groundwork for software product lines. Chapter 1 covers the background and basic ideas. Chapter 2 describes the benefits of a software product line approach from a variety of points of view throughout an organization. Chapter 3 lays out the three essential activities for product lines: development of a reusable base of core assets, development of products that utilize those core assets, and management to orchestrate the entire affair.

Part II is called "Software Product Line Practice Areas." It defines 29 skill areas in which an organization needs to be adept in order to achieve a software product line capability. All of these practice areas will be familiar to every reader experienced in software development; they are pockets of expertise that must be present in any software development organization. They include architecture definition, component development, testing, configuration management, market analysis, training, and the like. However, each one takes on a new dimension and needs to be applied in different ways in a software product line context. The practice areas are organized into three groups: software engineering practice areas (Chapter 4), technical management practice areas (Chapter 5), and organizational management practice areas (Chapter 6).

Part III is called "Putting the Practice Areas into Action." Its goal is to provide the reader with the tools necessary to apply the practice areas in a way most beneficial to a specific organizational context. Chapter 7 shows how the practice areas can be applied in software product line practice patterns, a powerful mechanism by which organizations can bring the practice areas into play according to their own situations and goals. Chapter 8 introduces the Product Line Technical Probe, a diagnostic instrument that lets an organization discover where it is lacking necessary practice area skills. Chapters 9 through 11 present three case studies of organizations that adopted the software product line approach, and they take the reader along for the ride as they explain how these organizations worked to skirt the pitfalls, solve the problems, and eventually reap the benefits of software product line practice.

Different readers may wish to use this book in different ways.

If you're seeking to persuade upper management of the viability of the software product line approach, you should point them to Chapters 1, 2, and 3, with special emphasis on Chapter 2. You should also show them the case study chapters (Chapters 9-11); odds are that something in those success stories will resonate.

If you're a new product line manager, you should read Part I (Chapters 1-3) carefully and make sure to grasp the fundamentals given there. Read Part II to comprehend the scope of the product line activities that will be required. The extent to which you need to master the practice areas depends on the extent to which you will delegate responsibility for them to others. The patterns in Chapter 7 in Part III will provide key guidance for helping with the delegation, and you should study those patterns carefully. Patterns will also help you launch the product line effort, as will the Product Line Technical Probe in Chapter 8, and the case studies in Chapters 9-11 can increase your confidence and help you remember the end game. You might also encourage (or require) others in your organization to read the case studies, for the same two reasons: to show that success is possible and to reinforce the reasons for adopting the approach.

If you've been given responsibility for part of a software product line, you should read Part I (Chapters 1-3) to grasp the big picture, and in Part II (Chapters 4-6) concentrate on those practice areas that fall within your purview. Pay attention to Chapter 7 to see how your practice areas interact with others in patterns, and examine the case studies (Chapters 9-11) to see how those organizations put your practice areas into play; they may give you ideas for doing the same.

If you work for a small organization interested in software product line concepts, start by reading the basics in Part I and strive to gain a passing familiarity with the practice areas in Part II, but then pay special attention to Part III. Chapter 7, which discusses the software product line practice patterns, will help you apply the practice areas in a way tailored to a small organization, and the Market Maker case study in Chapter 11 shows how a small organization can enjoy unparalleled success with software product line ideas.

Discussion questions designed to stimulate thought about the material appear throughout the book. These questions can be assigned as essay questions for homework in a university class, but they can also guide the discussion if this book is used as the basis for a brown-bag seminar or reading group in a company setting.

A glossary of vocabulary terms appears at the end of the book.

Sample Content

Online Sample Chapter

Software Product Lines: Basic Terms and Ideas

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
clementsch1.pdf

Table of Contents



Foreword.


Preface.


Acknowledgements.


Dedication.


Reader's Guide.

I. SOFTWARE PRODUCT LINE FUNDAMENTALS.

1. Basic Ideas and Terms.

What Is a Software Product Line?

What Software Product Lines Are Not.

Fortuitous Small-Grained Reuse.

Single-System Development with Reuse.

Just Component-Based Development.

Just a Reconfigurable Architecture.

Releases and Versions of Single Products.

Just a Set of Technical Standards.

A Note on Terminology.

For Further Reading.

Discussion Questions.

2. Benefits.

Organizational Benefits.

Individual Benefits.

Benefits versus Costs.

For Further Reading.

Discussion Questions.

3. The Three Essential Activities.

What Are the Essential Activities?

Core Asset Development.

Product Development.

Management.

All Three Together.

For Further Reading.

Discussion Questions.

II. SOFTWARE PRODUCT LINE PRACTICE AREAS.

Describing the Practice Areas.

Starting versus Running a Product Line.

Organizing the Practice Areas.

4. Software Engineering Practice Areas.

Architecture Definition.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Architecture Evaluation.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Component Development.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

COTS Utilization.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Mining Existing Assets.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Requirements Engineering.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Software System Integration.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Testing.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Understanding Relevant Domains.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

5. Technical Management Practice Areas.

Configuration Management.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Data Collection, Metrics, and Tracking.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Make/Buy/Mine/Commission Analysis.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Process Definition.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Scoping.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Technical Planning.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Technical Risk Management.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Tool Support.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

6. Organizational Management Practice Areas.

Building a Business Case.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Customer Interface Management.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Developing an Acquisition Strategy.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Funding.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Launching and Institutionalizing.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Market Analysis.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Operations.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Organizational Planning.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Organizational Risk Management.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Structuring the Organization.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

Discussion Questions.

Technology Forecasting.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

Training.

Aspects Peculiar to Product Lines.

Application to Core Asset Development.

Application to Product Development.

Specific Practices.

Practice Risks.

For Further Reading.

Discussion Questions.

III. PUTTING THE PRACTICE AREAS INTO ACTION.

7. Software Product Line Practice Patterns.

The Value of Patterns.

Software Product Line Practice Pattern Descriptions.

The Curriculum Pattern.

The Essentials Coverage Pattern.

Each Asset Pattern.

What to Build Pattern.

Product Parts Pattern.

Assembly Line Pattern.

Monitor Pattern.

Product Builder Pattern.

Cold Start Pattern.

In Motion Pattern.

Process Pattern.

Factory Pattern.

Other Patterns.

Practice Area Coverage.

Discussion Questions.

8. Product Line Technical Probe.

What Is the Product Line Technical Probe?

Probe Interview Questions.

Probe Participants.

Probe Process.

Using the Probe Results.

Conducting a Mini Self-Probe.

Discussion Questions.

9. Cummins Engine Company: Embracing the Future.

Prologue.

Company History.

A Product Line of Engine Software.

Getting off the Ground.

An Organization Structured for Cooperation.

Running the Product Line.

Results.

Lessons Learned.

Epilogue.

Practice Area Compendium.

For Further Reading.

Discussion Questions.

10. Control Channel Toolkit: A Software Product Line that Controls Satellites.

Contextual Background.

Organizational Profiles.

Project History.

Control Channels.

Launching CCT.

Developing a Business Case for CCT.

Developing the Acquisition Strategy and Funding CCT.

Structuring the CCT Organization.

Organizational and Technical Planning.

Operations.

Engineering the CCT Core Assets.

Domain Analysis.

Architecture.

Component Engineering.

Testing: Application and Test Engineering.

Sustainment Engineering: Product Line Evolution.

Documentation.

Managing the CCT Effort.

Early Benefits from CCT.

First CCT Product.

Benefits beyond CCT Products.

Lessons and Issues.

Tool Support Is Inadequate.

Domain Analysis Documentation Is Important.

An Early Architecture Focus Is Best.

Product Builders Need More Support.

CCT Users Need Reuse Metrics.

It Pays to Be Flexible, and Cross-Unit Teams Work.

A Real Product Is a Benefit.

Summary.

For Further Reading.

Discussion Questions.

11. Successful Software product Line Development in Small Organization.

Introduction.

The Early Years.

The MERGER Software Product Line.

Market Maker Software Product Line Practices.

Architecture Definition.

Component Development.

Structuring (and Staffing) the Organization.

Testing.

Data Collection and Metrics.

Launching and Institutionalizing the Product Line.

Understanding the Market.

Technology Forecasting.

A Few Observations.

Effects of Company Culture.

Cost Issues.

The Customer Paradox.

Tool Support.

Lessons Learned.

Drawbacks.

Conclusions: Software Product Lines in Small Organizations.

For Further Reading.

Discussion Questions.

12. Conclusions: Practices, Patterns and Payoffs.

The Practices.

The Patterns.

The Success Factors.

The Payoff.

Finale.

Glossary.
Bibliography.
Index.

Preface

From subroutines in the 1960s through modules in the 1970s, objects in the 1980s, and components in the 1990s, software engineering has been the story of a continuously ascending spiral of increasing capability and economy battled by increasing complexity. Now, at the dawn of the new millennium, comes the next great turn of the cycle. Software product lines promise to revolutionize the way that organizations, large and small, conceptualize and carry out their software development activities. Software product lines enable companies to field entire families of systems--perhaps containing dozens or even hundreds of members--for little more than the cost of building two or three the old way. This relatively straightforward concept is bringing about breathtaking improvements in productivity, time to market, cost, and quality; and it can be applied to software in every application area and deployed on every kind of platform, regardless of size.

For us, the story began in 1995, when two fortuitous events aligned at exactly the right juncture. First, we quite accidentally stumbled onto a software product line that would forever fuel our thinking; and second, our organization funded an effort dedicated to improving the practice of software product lines.

As researchers at the Software Engineering Institute (SEI), we were scouring our sources looking for case studies in software architecture, a topic just blossoming into the software engineering community's consciousness. We wanted to show that architectural drivers (for example, the need for high performance, security, or modifiability) could be consistently described across different applications and that the same architectural solutions to these drivers would probably surface again and again. This kind of thinking is what motivates the design pattern and architectural style communities. So we wanted to start a "butterfly collection" of architectures, categorized by the problems they solved. Off we went with our nets. One of our colleagues, Lisa Brownsword, mentioned that she knew of an architecture constructed to achieve a quality not in our list. In fact, this quality was not to be found in any of the usual lists of "ilities" that often describe the goals for a software architecture. And yet, Lisa told us, this quality was so important that a company had gambled its whole existence on it.

We were intrigued.

That company was CelsiusTech Systems AB, a Swedish defense contractor supplying shipboard command and control systems to navies around the world. In 1985, CelsiusTech faced a monumental crisis: they were compelled to build two systems much larger than anything the company had ever attempted, and although they had an excellent reputation in their market, CelsiusTech had had trouble meeting schedules and budgets before. Their only hope was to build one solution that would satisfy the (very different) requirements of both customers and--and this was their key insight--would also satisfy customers that they hoped would come after these two. The overriding quality that drove the CelsiusTech architecture was its applicability across a wide (but planned) range of products--that is, its suitability to serve as the architecture for a software product line.

So Lisa and one of the authors (PCC) flew off to Sweden, butterfly nets in hand. As we listened to the CelsiusTech story, it became clear that we were onto something much bigger than just an interesting architecture. Yes, the software architecture was the critical foundation for the product line, but it was only one part of a broader story. In some ways, the architecture had been the easy part compared to changing the way the company did business. Adopting the product line strategy required reorganization (more than once), copious training, and an adjustment in the very way that people thought about carrying out their jobs. Architecture and reuse were the technical keys--but by no means the only keys--to adopting a software product line strategy.

And what had this strategy wrought? Not only did it allow the company to deliver both pilot systems, but on subsequent projects (more than 50 of them, in fact), it took years off delivery schedules, allowed a smaller staff to produce more systems, and sent their software reuse levels into the 90 percent range. As an example of their productivity gains, the integration testing of one of these enormous (1.5 million lines of Ada) real-time, safety-critical, highly distributed systems can be routinely handled by one or two people at most. Porting one of these systems to a whole new computing environment and operating system takes less than a month.

When we returned home and reported our findings, we described the architecture. It was, after all, what we had gone to investigate. It was layered and multiprocess, with a blackboard to mediate between data consumers and data producers--it was, in short, just what one would expect. One of our colleagues remarked how uninteresting it was and, I'm sure, didn't think it justified a trip to Sweden--but he didn't grasp the big picture. What we learned was that even a vanilla architecture, if embellished with judiciously planned extension and variation points and created in the context of an overall shift in the way a company does business, can save an organization from oblivion if the organization is willing to reshape itself.

What a discovery and how fortunate for us that it occurred right at the time the SEI's interest in flexible systems was coming into focus with the creation of the Product Line Systems Program, under the direction of one of the authors (LMN). This new program, like the other three technical programs at the SEI, was launched to carry out the mission of the SEI: to provide leadership in advancing the state of the practice of software engineering to improve the quality of systems that depend on software. But this program had a unique charter: to build on earlier SEI work as well as both commercial and government software product line efforts to enable the widespread efficacy of software product lines. We agreed on two strategies to fulfill our mission: (1) we would codify and establish best practices for organizations wishing to undertake that reshaping to become skilled at producing software product lines; and (2) we would build and equip a community of people interested in working on software product line issues. We set out with enthusiasm to effect those strategies.

In that process, we've worked to gather information and identify key people in the field. We've held nearly a dozen workshops attended by experienced product line practitioners from all over the world. They've told us how they've solved problems in all areas of product line production, and they've let us know about areas where they've stumbled and made the wrong choices as well. We've participated in many other conferences and workshops with software product lines in the agenda (sometimes as a result of our prodding or initiation). We sponsored and held the First Software Product Line Conference in August 2000. (We expect that there will be many more such conferences.) There, almost 200 people gathered to discuss and learn about software product lines. Finally, we work with organizations directly to help them adopt the product line paradigm as a way of doing business. This puts us in the trenches with the people who must undergo the changes precipitated by the shift. Our customer collaborations have two effects. First, they give us the best seat in the house from which to judge and record what works and what doesn't. Second, they put everything we think and counsel about product lines through a trial by fire. If these things are not right--or if they are right but unimportant--our customers/collaborators will let us know in a hurry.

What we've learned is that software product lines represent a powerful paradigm for software that can and does achieve remarkable improvements in time, cost, and quality. Systems turned out in days instead of years. Order-of-magnitude productivity gains. Smaller staffs producing more projects that are larger and of higher quality. Mass customization wherein 20 software builds are parlayed into a family of over a thousand specifically tailored systems. These and other stories are what we've discovered.

This book is the distillation of all that we've learned about software product lines. We describe the essential activities, which are (1) the development of a set of core assets from which all of the products will be built, (2) the development of products using those core assets, and (3) strong technical and organizational management to launch and coordinate both core asset development and product development. We delve beneath the surfaces of these three broad essential activities. To be more prescriptive about what an organization must do, we describe 29 practice areas that must be mastered. The practice areas are divided into the categories of software engineering, technical management, and organizational management according to what types of skills are required to carry them out. For example, defining the architecture is a software engineering practice area; configuration control is a technical management practice area; and training is an organizational management practice area.

The essential activities and the practice areas have constituted the pivotal output of the SEI's product line practice work and are continually updated in a Web-based document. Parts I and II of this book are derived from that document, which is called A Framework for Software Product Line Practice Clements 00b. This work has been used by organizations, large and small, to help them plan their adoption of the product line approach as well as to help them gauge how they're doing and in what areas they're falling short. We use it to guide our collaborations with customers. We have also used it as the basis for conducting product line technical probes, which are formal diagnostics of an organization's product line fitness. It represents our best picture of sound product line practice as described to us by its many reviewers and users--practitioners all.

In addition to the practice areas and essential activities, which offer "what to do" guidance, this book provides software product line practice patterns as "how to" guidance. These patterns give common product line problem/solution pairs in which the problems are product line work to be done and the solutions are the groups of practice areas to apply in concert to accomplish the work. We also chronicle three detailed case studies (and short takes of several others) that show how different organizations have overcome product line hurdles in their own unique ways. Cummins Inc., the U.S. Government's National Reconnaissance Office, and Germany's Market Maker AG all made deliberate decisions to go down the product line path, and each has a compelling story to tell about its experiences. (The CelsiusTech story is chronicled elsewhere Bass 98a.)

The book includes discussion questions throughout, so that a study group (maybe a brown-bag lunch discussion group or a university class) can explore the subtleties of the issues together. We have also added numerous sidebars that tell stories, relate the experiences or viewpoints of others, or simply underscore significant points. Anecdotes in the sidebars are all true and come from first-hand knowledge, although confidentiality occasionally prevents us from naming sources. Many of the sidebars form a series we call "Other Voices." In them we have borrowed (with permission) from product line practitioners' experiences that have appeared in the open literature. They provide a set of first-person war stories that we hope will resonate with readers.

Software Product Lines: Practices and Patterns is the culmination of our efforts to grow and nurture a community of people interested in software product lines. As a reader of this book, you are also a member of this growing community. Welcome.

PCC, Austin, Texas

LMN, Pittsburgh, Pennsylvania



0201703327P07312001

Index

Note: Page numbers followed by the letters f and t indicate figures and tables respectively

A

Acceptance testing, 129, 132, 134
Acquisition. See also Make/ buy/ mine/ commission analysis
definition of, 521
Acquisition plan, definition of, 248
Acquisition strategy, 247-255
for acquisition-based organizations, 247
for Control Channel Toolkit, 451-452
coordination with other practice areas, 249
in core asset development, 250
definition of, 247
developing, 247-248
developing, and Cold Start pattern, 381-384
developing, and Curriculum pattern, 354-356
developing, and Essential Coverage pattern, 357-360
developing, and In Motion pattern, 384-386
developing, and Product Parts pattern, 369-373
documenting, 248
make/buy/mine/commission analysis and, 168
practice risks of, 252-254
in product development, 250
in product lines, 248-249
specific practices for, 251-252
Active Design Reviews, 80
Active Reviews for Intermediate Designs (ARID), 80
Activities
integration of, 10
strategic management of, 10
three essential, 29-50, 30f
Ada language, 122
at CelsiusTech, 123
Adoption plans
definition of, 280
in launching and institutionalizing, 264-268, 270-271, 280
in organizational planning, 303, 304, 305
staging, 270-271
training and, 335
Analysis, reuse of, 19
Analysis pattern, 367-368
Application engineering. See Product development
Application program interface (API), 136
Architectural style(s)
in core asset development, 31, 35-36
definition of, 60-61
Architectural variation, planning for, 70-71
Architectural view(s), definition of, 66
Architecture(s)
in Barren Field pattern, 372
binding, 64-65
components wrapping to, 107
of Control Channel Toolkit, 460-468
as core assets, 32-33
COTS as, 93
at Cummins Engine Company, 425-426, 436-437
designing, 60-61
development of, 44
documentation for, 66
in Each Asset pattern, 360-364
in Evolve Each Asset pattern, 364
excellence in, 517
focus for Control Channel Toolkit, 477-478
in Green Field pattern, 372
importance of, 513-514
management support for, 72-73
in medical imaging, 58-60
OMA, 63
patterns, 35
portability of, 68
of product lines, 44
in Product Parts pattern, 369-373
reconfigurable, 12-13
reconstruction of, 100
recovery/reconstruction tools for, 106-107
reference, 12-13
requirements of, 57-58
reuse of, 19
scope and, 71
in software engineering practice areas, 56-57, 56f
software product lines and, 64-67
source of, 174
subsystems and, 35
support for variability, 69-70
Architecture definition, 56-75
architecture-based development and, 67
of Control Channel Toolkit, 460-466
coordination with acquisition strategy, 249
CORBA in, 63
core asset development and, 67
in Curriculum Pattern, 354-356
DCOM in, 63
definition of, 56-57
in Essentials Coverage pattern, 357-360
Java in, 63
JavaBeans in, 63
of MERGER product line, 496-498, 496f
practice risks of, 71-74
in Product Builder pattern, 378-381
product development and, 67
quality attributes and, 57-58
technical probe questions for, 400-402
Architecture evaluation, 76-83
Active Design Reviews, 80
in Analysis pattern, 367-368
ARID, 80
ATAM, 79-80
in Barren Field pattern, 372
of Control Channel Toolkit, 466-468
core asset development and, 78
at Cummins Inc., 431
in Curriculum patterns, 372
in Essentials Coverage pattern, 357-360
in Green Field pattern, 372
make/buy/mine/commission analysis and, 168
in Plowed Field pattern, 372
practice risks of, 81-82
in Product Builder pattern, 378-381
product development and, 78-79
product lines and, 77
in Product Parts pattern, 369-373
quality attribute goals and, 76
reevaluating, 82
requirements and, 76
reuse of artifacts, 78
SAAM, 80
second-order problems of, 82
SPE, 80
techniques for, 79-81
Architecture style(s), definition of, 67-68
Architecture Tradeoff Analysis Method (ATAM), 79-80
Architecture-based development, 67
Aspect, definition of, 68
Aspect-oriented programming (AOP), 89
definition of, 68
Assembly Line pattern, 374-376, 375f
in Factory pattern, 393-395
Asset(s). Also see Core asset(s)
preexisting, 31, 36
rehabilitation of, 101
value of, 234
Asset base
artifacts of, 11
reuse of, 19-20
Attached processes
for core assets, 33, 34f, 53
definition of, 521
documentation for, 66-67
in process definition, 176
in production plans, 176
Attribute/product matrix in scoping, 190, 190f

B

Barren Field pattern, 372
Baxter, Ira, 105
BigLever Software, Inc.
Krueger, Charles, 208, 211
Product Line Platform, 208-211, 210f, 211f
Brooks, Fred on requirements engineering, 109
Business case(s)
in Analysis pattern, 367-368
asset value prediction in, 234
benefit assessment, 231-232
business models in, 224
contents of, 222
for Control Channel Toolkit, 451, 474-475
in core asset development, 225
cost assessment, 231
cost basis for, 225-229, 229f
for Cummins Inc., 423-424
in Curriculum pattern, 354-356
definition of, 220-221
in Essentials Coverage pattern, 357-360
FAST method and, 230
funding in, 255-256
goal of, 221-222
market analysis in, 284
metrics examples in, 232
performance assessment, 232
practice risks of, 232-233
in product development, 230
product line goals in, 232, 233t
in product line launch, 225
in product lines, 222
relationship to market analysis, 221
reuse of, 225
risk assessment, 231
scope informed by, 225
simple, 230
use of, 220-221
in What to Build pattern, 365-369
Business Domain Object Task Force, 63
Business goals, training plans and, 335
Business model(s)
in business cases, 224
definition of, 521
Business unit(s), 14, 15f
Business units model for organizational structure, 316-317, 318f

C

Capability Maturity Model (CMM), 389
Capability Maturity Model Integrated (CMMI)
maturity levels for, 389-390
process areas in, 389-392
Capability Maturity Model Integrated (continued)
process areas vs. practice areas, 390-392, 390t-391t
in process improvement, 280-281, 389-392
representations for, 389
steps for configuration management, 158
CASE (computer-aided software engineering) tools, 207-208
CBMS. See Code-Base Management System
CCT. See Control Channel Toolkit
CCT Program Office, 453
CelsiusTech Systems AB
Ada in continuous integration at, 123
business case, simplicity of, 230
customer interface management at, 242-243
integration reuse and, 118-120
leadership of, 47
organizational culture at, 39
organizational structure at, 320-326, 321f, 322f, 325f
product line background, vii-viii
product line launch, 1-3
results from software product line, 26-27
scoping and, 184-185
training curriculum at, 339-341, 341f
training plans at, 336-339
CEO. See Chief Executive Officer
Change-case modeling in requirements engineering, 115
Charan, Ram on leadership, 47
Chief Executive Officer (CEO), benefits of software product lines to, 20
Chief Operating Officer (COO), benefits of software production lines to, 20-21
China, architecture and product lines, 7
“Clone and own,” 12, 176
Clone detection in mining assets, 103-105
CloneDR, 104-105, 104f
CM. See Configuration management
CMM (Capability Maturity Model), 389
CMMI. See Capability Maturity Model Integrated
Code-Base Management System (CBMS) in architecture recovery/ reconstructions, 106
Cold Start pattern, 381-384, 383f
in Factory pattern, 393-395
variants of, 384
COM (Component Object Model), 63
Command and control system(s), 443
contact for, 449
Control Channel Toolkit (See Control Channel Toolkit)
DCCS, 447-448
description of, 448-450
execution for, 449
planning for, 449
requirements for, 458-459
scenarios for, 467-468
Spacecraft C2 System, 448
SSCS, 447-448
use of, 449-450
Commercial off-the-shelf components. See COTS
Commissioning assets. See also Make/ buy/ mine/commission analysis
definition of, 521
Common Object Request Broker Architecture (CORBA)
in architecture definition, 63
in Control Channel Toolkit, 461
in software system integration, 123
Commonality analysis
definition of, 141
at Lucent Technologies, 141-143, 279
Communication protocols, 63
Component(s)
adapting, 86
architecture, wrapping to, 107
in Barren Field pattern, 372
connecting, 62-64
contracts and, 61-62
as core assets, 32-33
COTS as, 91-93
definition of, 41, 83
developing new, 86
documenting performance of, 62
documenting reliability of, 62-63
in Each Asset pattern, 360-364
in Evolve Each Asset pattern, 364
in Green Field pattern, 372
history of, 83-84
IDD, 121
in Product Parts pattern, 369-373
interfaces of, 61-62
interfaces of and integration, 117-118
modification of, 86
nature of vs. source of, 84n1
ORB, 63
patterns and, 35-36
as products, 41-44
promoting to core assets, 86
reuse of, 19
in software engineering practice areas, 56-57, 56f
sources for, 58
variability mechanisms for, 87-89, 88t
Component development, 83-90
for Control Channel Toolkit, 461-466, 468-469
core asset development and, 85
in Curriculum pattern, 354-356
definition of, 83
in Essentials Coverage pattern, 357-360
focus of, 84
for MERGER product line, 498-499
practice risks of, 89-90
in Product Builder pattern, 378-381
product development and, 85-86
product lines and, 85
Component Object Model (COM), 63
Component-based development, 12
Computer-aided software engineering (CASE) tools, 207-208
“Concept alignment,” 430
Concept of operations (CONOPS), 292-299
developing, 293-295, 299-300
purpose of, 293
Configuration management (CM), 152-160
in Assembly Line pattern, 374-368
capabilities of, 154-156
CMMI steps for, 158
core asset development and, 156-157
at Cummins Inc., 430, 435
in Curriculum pattern, 354-356
in Each Asset pattern, 360-364
in Essentials Coverage pattern, 357-360
in Evolve Each Asset pattern, 364
at Hewlett Packard, 157-158
IEEE/ANSI standard for, 157
impact analysis from, 156
in organizational planning, 303, 304, 305
practice risks of, 159
in process definition, 176
in Process pattern, 386-393
in Process Improvement pattern, 388
product development and, 157
Product Line Platform for, 208-211, 210f, 211f
product lines and, 153-156, 153f
purpose of, 152-153
Conformance testing, 129
CONOPS. See Concept of operations
Context diagram in scoping, 190-191, 190f
Continuous Risk Management (CRM), 202-203, 203f
Contract(s), components and, 61-62
Control Channel Toolkit (CCT), 444
acquisition strategy for, 451-452
architecture definition of, 460-466
architecture evaluation of, 466-468
architecture focus for, 477-478
architecture of, 460-468
asset development for, 455
asset sustainment for, 455
benefits from, 474-476, 476t
business case for, 451, 474-475
CCT Program Office, 453
component categories for, 461-466
CORBA in, 461
DCCS, 447-448
description of, 444-445
documentation for, 472-473
domain analysis for, 458-459, 477
domain definition for, 459-460
Control Channel Toolkit (continued)
domain partitioning and, 459
essential activities and, 445, 445f
funding for, 445, 451-452
growth of, 482f
IDL in, 461
intellectual rights to, 452
launching, 450-457
management of, 473-474
Ohlinger, John, 473-474
operational concept for, 455-457, 482
operations of, 454-457
ORB in, 461
organizational management of, 454
organizational planning of, 454
organizational structure of, 452-453, 453t, 480-481
practice area coverage, 450-457
process refinement for, 455
product builder support in, 460-461, 473, 478-479
product line champion for, 474
product line improvement for, 455
product line sustainment for, 455
project history for, 447-448
requirements analysis for, 458-459
reuse metrics for, 479-480
SAAM in, 466-467
scoping for, 458-460
Shaw, Jeff, 474
Spacecraft C2 System in, 481
stakeholders in, 452
subscribers to, 455-457
subsystems in, 461-466, 462f, 464f
sustainment engineering for, 471-472
technical planning of, 454
testing for, 469-471
tool support for, 477
use of, 444-445
variability of, 465-466, 466t
COO. See Chief Operating Officer
CORBA. See Common Object Request Broker Architecture
CORBA models, 42
Core asset(s)
architecture as, 32-33
attached processes for, 33, 53
business case as, 225
business use case as, 33
components, promoting to, 86
in core asset development, 32-33
COTS as, 33
definition of, 14, 15f
design documentation as, 33
development of (See Core asset development)
funding, 303, 304
identified risks as, 33
market analysis as, 286
metrics for management of, 164-165
people as, 313
performance models as, 33
plans as, 198-199
preintegrating, 118
in product development, 37, 40-41
requirements as, 111
scope definition as, 185
software components as, 32-33
software product lines and, 176
statement of scope as, 33
technical management process definitions as, 33
test cases as, 33
test plans as, 33
from testing, 132
testing of, 133-134
training as, 33
training plans as, 336
updating, 33, 38
Core asset development, 29-37, 30f, 32f
acquisition strategy in, 250
architectural style in, 31, 35-36
architecture definition and, 67
architecture evaluation and, 78
business cases in, 225
component development and, 85
configuration management and, 156-157
for Control Channel Toolkit (CCT), 455
cooperative, 409-411
core assets in, 32-33
COTS and, 94-95
at Cummins Inc., 424-426
customer interface management in, 241
data collection and, 160-161
domains and, 141-143
frameworks in, 35-36
funding in, 256-257
goal of, 31
inputs to, 35-37
institutionalizing and, 264-268
launching and, 264-268
legacy assets in, 31
make/buy/mine/commission analysis and, 169-170
market analysis in, 286
metrics and, 163
mining assets and, 102
in operations, 295-299
operations in, 291-292
organizational culture and, 264-268
organizational planning in, 304-305
organizational risk management in, 309
organizational structure in, 314-316
patterns in, 31, 35
plans for, 195
preexisting assets in, 31, 36
process definition and, 177
product constraints in, 35
production constraints in, 31, 36
production plans in, 34-35
production strategy in, 36
requirements engineering and, 112-113
scope in, 31-32
scoping and, 185
software system integration and, 122
staffing and, 428
styles in, 31, 35
technical planning in, 197-198
technical risk management in, 203
technology forecasting for, 329-330
testing and, 132-134
tool support for, 213-214
training for, 335-336
Core asset management
metrics for, 164-165
technical planning in, 195-197
Core competence, 438
COTS. See also COTS utilization
as architecture, 93
certification criteria for, 96-97
as components, 91-93
core asset development and, 94-95
as core assets, 33
as framework, 93
integrating, 92
maintaining, 93
middleware as, 91
operating systems as, 90
product development and, 95
testing, 92-93
variability of, 93-94
COTS utilization, 90-98. See also COTS
in Barren Field pattern, 372
criteria for, 90-93
in Curriculum pattern, 354-356
in Essentials Coverage pattern, 357-360
in Green Field pattern, 372
make/buy/mine/commission analysis and, 168
in Plowed Field pattern, 372
practice risks of, 97-98
product lines and, 93-94
in Product Parts pattern, 369-373
COTS-based systems practices, 95-96
CRM (Continuous Risk Management), 202-203, 203f
Culture. See Organizational culture
Cummins, Clessie, 418
Cummins Inc.
architecture at, 425-426, 436-437
architecture evaluation at, 431
business case for, 423-424
case study, 417-442
“concept alignment,” 430
configuration management at, 430, 435
Controls Software workflow process, 423
core asset development at, 424-426
core competence at, 438
Cummins, Clessie, 418
data collection at, 436
diesel engines, 419
Diesel, Rudolf, 419
Cummins Inc. (continued)
domain analysis at, 145-146, 424-425, 436, 437
engine software product line inception, 422-423
history, 418-421
integration strategy at, 425
Irwin, William Glanton “W.G.”, 418
launching and institutionalizing at, 426
leadership of, 47
make/buy/mine/commission analysis at, 424
market analysis at, 425
mining assets at, 435
morale and, 428
new business areas at, 432-433
organizational culture at, 427
organizational culture of, 39
organizational structure at, 426-430
pilot project for, 423
practice areas coverage, 440-441, 441t
process improvement at, 434
product builder’s guide at, 435-436
product development priorities at, 429
product line approach benefits, 431-434
product line champion at, 423, 434
release management at, 436
requirements definition at, 424
requirements engineering at, 436
risk management at, 431
scope at, 432, 433t
stakeholders at, 439
technology forecasting at, 330-331
Temple, Ronald H., 421
testing at, 430
two-part organizational structure at, 427-430
values-based business and, 433-440
variability at, 432-434, 433t
variability mechanisms at, 425
Curriculum pattern, 354-356
dynamic structure of, 355, 356f
variants of, 356
Customer interface management, 235-247
at CelsiusTech, 242-243
change in interface and, 238
in Cold Start pattern, 381-384
components of, 236
in core asset development, 241
in Curriculum pattern, 354-356
customer representatives in, 237, 244t
customer requirements in, 237, 241
in Essentials Coverage pattern, 357-360
establishing interface and, 238-240
in In Motion pattern, 384-386
in Monitor pattern, 376-360
practice risks of, 245-246
in product development, 241-243
in product lines, 236-241
requirements of, 236
Customer representatives, 244t
definition of, 237
Customer value analysis, 287-288
Cusumano, Michael, 10, 49, 99
on reuse of people, 313
on training, 334

D

DADP (Domain analysis and design process), 145
Dali workbench in architecture recovery/ reconstructions, 106-107
DATA, 173
Data collection
core asset development and, 162
at Cummins Inc., 436
inherent value of, 162
management and, 161-162
for MERGER product line, 501
practice risks of, 165-166
product development and, 161-162
techniques for, 164-166
Data collection, metrics and tracking, 160-167
in Curriculum pattern, 354-356
in Each Asset pattern, 360-364
in Essentials Coverage pattern, 357-360
in Evolve Each Asset pattern, 364
in Monitor pattern, 376-378
in Process pattern, 386-393
in Process Improvement pattern, 388
DATA Interactive, 173
DCCS. See Distributed Command and Control System
DCOM. See Distributed Object Component Model
DECC project. See Domain Engineered Configuration Control project
Decision analysis
definition of, 168
in make/buy/mine/commission analysis, 168-170
Defense Information Systems Agency (DISA), 145
Delphi language, variability mechanism properties in, 88
Deployment testing, 129
Design documentation as core assets, 33
Design patterns
adapter, 86
as variability mechanisms, 89
Development. See also Make/buy/ mine/ commission analysis
architecture-based, 67
definition of, 14
Development department model for organizational structure, 316, 317f
Diesel engines, 419
Diesel, Rudolf, 419
Directed testing, 127
DISA (Defense Information Systems Agency), 145
DISCOVER in architecture recovery/reconstructions, 106
Distributed Command and Control System (DCCS), 447-448
requirements of, 458-459
Distributed Object Component Model (DCOM)
in architecture definition, 63
in software system integration, 123
Distributed Object Technology (DOT), 123
Domain(s)
commonality analysis of, 142
core asset development and, 141-143
core competence maintenance and, 438
defining for Control Channel Toolkit, 459-460
definition of, 14, 138
eliciting information for, 138
experience in, 517
modeling, 138-139, 140
partitioning, 459
practice risks of understanding, 147-148
product development and, 143-144
product lines and, 139-141
reuse and, 141
in software engineering practice areas, 56-57, 55f
software libraries for, 42
Domain analysis
for Control Channel Toolkit, 458-459, 477
at Cummins Inc., 145-146, 424-425, 436, 437
definition of, 521
for elevator control systems, 144-145
extent of, 138-139
techniques for, 114
Domain analysis and design process (DADP), 145
Domain Engineered Configuration Control (DECC) project, 141
commonality analysis at, 279
commonality analysis of, 141-143
launching and institutionalizing, 279-280
Domain engineering. See Core asset development
Domain engineering unit model for organizational structure, 317, 318f
DOT (Distributed Object Technology), 123
Dynamic link libraries, 89

E

Each asset apprentice pattern, 363-364, 372
Each Asset pattern, 360-364, 362f
in Factory pattern, 393-395
variants of, 363-364
Economies of production for software product lines, 5-6
Economies of resources, economic conditions and, 18-19
Economies of scale, definition of, 521
Economies of scope. See Scope, economies of
Elevator control systems, domain analysis for, 144-145
Engines
diesel, 419
software for, 421-423
Enterprise JavaBeans, 42
Essentials Coverage pattern, 357-360, 358f, 359f-360f
Evolve Each Asset pattern, 364

F

Factory pattern, 393-395
dynamic structure of, 394, 394f
variants of, 394
Family-Oriented Abstraction, Specification, and Translation (FAST), 124, 230
Feature modeling
definition of, 114
in FODA, 114
in FORM, 114
Feature-oriented domain analysis (FODA), 114, 145
Feature-oriented reuse method (FORM), 114
Forced March pattern, 368
Framework(s)
in core asset development, 35-36
COTS as, 93
definition of, 70, 93
object-oriented, 12-13
service component, 70
A Framework for Software Product Line Practice, 49
Fraunhofer Institute for Experimental Software Engineering (IESE), 490
Fujitsu, 10
Functional testing, 127, 133-134
Funding, 255-262
in business cases, 255-256
consequences of, 256
for Control Channel Toolkit, 445, 451-452
in Cold Start pattern, 381-384
coordination with acquisition strategy, 249
in core asset development, 256-257
in Curriculum pattern, 354-356
direct, 259
discretionary, 259
in Essentials Coverage pattern, 357-360
from fee-based asset usage, 260
from first product project, 260
goals of, 256
in In Motion pattern, 384-386
from multiple projects, 260
in organizational planning, 303, 304
organizational structure and, 428
practice risks of, 261-262
in product development, 257-258
for product lines, 255-256
product-specific, 258
from prorated cost recovery, 260
sources of, 255, 258-260, 259t
strategies for, 258-260, 259t
from taxes, 260
for training, 333
in Warm Start pattern, 384

G

General Electric (GE), leadership of, 46
Gleick, James, 6
Goal-Question-Metric method, 164
Green Field pattern, 372
Griss, Martin, 9
Guided inspection, 135

H

Hank, Christian, 487, 493
HCI (Human-computer interface), 171
Hewlett Packard
configuration management at, 157-158
organizational culture at, 409-411
Owen Firmware Cooperative, 409-411
Hierarchical domain engineering unit model for organizational structure, 317-319, 320f
Hitachi, 10
HTML, 43
HTTP, 43
Hughes Electronics Corporation, background of, 446-447
Human-computer interface (HCI), 171
HyperText Markup Language (HTML), 43
HyperText Transfer Protocol (HTTP), 43

I

IBM, System/360, 6-7
IBM Consulting Group
launching as project at, 263-264
on pilot projects, 276-277
IDD (Interface Description Document), 121
IDEAL model
acting phase of, 274
definition of, 272-273, 273f
diagnosing phase of, 274
establishing phase of, 274
initiating phase of, 273
for institutionalizing, 274
for launching, 272-276
for launching and institutionalizing, 273f
learning phase of, 274
for product lines, 273-275, 273f
sample scenario for, 275-276
IDL. See Interface Description Language
IEEE/ANSI standard for configuration management, 157
IESE (Fraunhofer Institute for Experimental Software Engineering), 490
Improvement plan(s), 199-200
In Motion pattern, 384-386, 385f
in Factory pattern, 393-395
Incremental model, 117
Institutionalizing. See Launching and institutionalizing
Integration. See Software system integration
Intellectual rights, commissioned product lines and, 452
Interaction tests, 134
Interface(s)
Ada language for, 122
of components, 61-62
definition of, 61
IDL language for, 122
languages for, 122-124
Interface Description Document (IDD), 121
Interface Description Language (IDL)
for component interfaces, 122
in Control Channel Toolkit, 461
Irwin, William Glanton “W.G.,” 418

J

Japan’s Software Factories, 10, 49, 99
on reuse of people, 313
on training, 334
Java
in architecture definition, 63
dynamic class loading in, 88
javadoc tool in, 87
RMI, 63, 496
in software system integration, 123
JavaBeans, 42
in architecture definition, 63-64

K

Krueger, Charles, 208, 211

L

Launching and institutionalizing, 262-284
adoption plans in, 264-268, 270-271, 280
approaches to, 268-272, 278
CMMI in, 280-281
in Cold Start pattern, 381-384
Control Channel Toolkit, 450-457
core asset development and, 264-268
Launching and institutionalizing (continued)
at Cummins Inc., 426
in Curriculum pattern, 354-356
DECC project and, 279-280
In Essentials Coverage pattern, 357-360
at IBM Consulting Group, 263-264
IBM Consulting Group on, 276-277
IDEAL model for, 272-276, 273f
Lucent Technologies and, 279-280
of MERGER product line, 501-502
organizational culture and, 264-268
as patterns, 272
pilot projects in, 276-278
practice risks of, 281-283
process improvement and, 280-281
in Process Improvement pattern, 388
product development and, 268
Product Line Technical Probe for, 278
of product lines, 263-264
as project, 263-264
as technology change project, 262-263
Leadership, 45-48
management vs., 47
qualities of, 47
Legacy assets in core asset development, 31
Libraries
dynamic link, 89
static, 89
Load testing, 128
Lucent Technologies
commonality analysis at, 141-143, 279
DECC project at, 141, 279-280
SCV approach, 145

M

Maintenance work plans, 195
Make/buy/mine/commission analysis, 167-174. See also Acquisition; Commissioning assets; Development; Mining assets
acquisition strategy and, 169
in Analysis pattern, 367-368
architecture evaluation and, 168-169
in Barren Field pattern, 372
coordination with acquisition strategy, 249
core asset development and, 170
COTS utilization and, 169-170
criteria for, 170
at Cummins Inc., 424
in Curriculum pattern, 354-356
decision analysis in, 168-169
in Essentials Coverage pattern, 357-360
in Green Field pattern, 372
intellectual rights and, 452
in Plowed Field pattern, 372
practice risks of, 173-174
product development and, 170-171
in Product Parts pattern, 369-373
questions for, 172-173
tool support for, 173
Management, 29-31, 30f, 45-48
commitment of, 516
of Control Channel Toolkit, 473-474
data collection and, 161-162
leadership vs., 47
organizational, 45
support for architecture, 72-73
support for training, 334
technical, 45
Market, definition of, 284
Market analysis, 284-290
in Analysis pattern, 367-368
in business cases, 284
competitors in, 289
conducting, 287-289
contributors to, 285-286
as core asset, 286
in core asset development, 286
at Cummins Inc., 425
in Curriculum pattern, 354-356
customer segments for, 288
customer value analysis in, 287-288
definition of, 284
information for, 288
for MERGER product line, 502-503
as mission analysis, 284
practice risks of, 289
in product development, 286-287
in product lines, 285-286
purpose of, 284
relationship to business case, 221
scope and, 286
scope definition influence on, 185
in What to Build pattern, 365-369
Market Maker Software AG
advantages of size, 509-510
background, 486-493
case study, 485-512
cost issues with, 505-506
customer service focus of, 504-505
disadvantages of size, 510-511
Hank, Christian, 487, 493
IESE cooperation with, 490
Market Maker 98, 488-490, 489f
MERGER product line (See MERGER product line)
MMLive!, 490, 492f
modularity of products, 490, 491f
new businesses for, 508-509
organizational culture at, 504-505
organizational structure in, 499-500
Sellemerten, Axel, 487
“Software Variantenbildung” project and, 490
Verlage, Martin, 493
WISO-Börse, 490
Measurement
initiation phase of, 161-162
performance phase of, 161
purpose of, 160-161
Medical imaging, architecture in, 58-60
MERGER product line, 493-495
architecture definition of, 496-498, 496f
business drivers for, 495, 495f
champion for, 509
component development for, 498-499
customer influence on, 506
data collection for, 501
disadvantages of product line approach to, 507-508
launching and institutionalizing of, 501-502
market analysis for, 502-503
metrics for, 501
requirements for, 497-498
technology forecasting for, 503-504
testing of, 500-501
tool support for, 506-507
Metric(s)
business cases using examples of, 232
choosing, 164
conventional, 163
core asset development and, 162-163
for core asset management, 163
efficiency goals for, 163
Goal-Question-Metric method for, 164
for MERGER product line, 501
for practice areas, 53
practice risks of, 165-166
product development and, 163
product line indicators and measures for, 163-164, 165f
for product line management, 164-165
for reuse, 479-480
reuse of, 164-165
Microsoft Corporation, COM, 63
Middleware
CORBA, 63, 123
as COTS, 91
DCOM, 63, 123
definition of, 63
Mining assets, 99-108. See also Make/ buy/mine/commission analysis; Reuse
analysis for, 103-106
architecture recovery/reconstructions tools for, 106-107
candidates for, 101
clone detection in, 104-105
CloneDR, 104-105, 105f
core asset development and, 102
at Cummins Inc., 435
in Curriculum pattern, 354-356
definition of, 99
in Essential Coverage pattern, 357-360
OAR, 103-106
in Plowed Field pattern, 372
practice risks of, 107-108
product development and, 103
product lines and, 101-102
in Product Parts pattern, 369-373
tool support for, 101
Mitigation plan(s) for risk management, 204-206
MMLive!, 490, 492f
Model(s)
of domains, 138-139, 140
for organizational structure, 316-320
for reliability, 129-130
reuse of, 19
Monitor pattern, 376-378, 377f
in Factory pattern, 393-395
in Process Improvement pattern, 388

N

Naming services, 62
National Product Line Asset Center, COTS certification criteria from, 96-97
National Reconnaissance Office (NRO), 444
background of, 445-446
NEC, 10
Nokia, architectural variation and, 70-71
NRO. See National Reconnaissance Office

O

OAR (Options Analysis for Reengineering), 103-106
Object Management Architecture (OMA), 63
Object Management Group (OMG), 63
Business Domain Object Task Force, 63
Object persistence, 63
Object Request Broker (ORB), 63
in Control Channel Toolkit, 461
ODM (Organizational domain modeling), 146
Ohlinger, John, 473-474
OMA (Object Management Architecture), 63
OMG (Object Management Group), 63
Operational concept(s). See also Operations
for Control Channel Toolkit, 455-457, 482
creating a CONOPS for, 292-299
definition of, 290
practice risks with, 295-299
for product lines, 176
Operations, 290-302. See also Operational concept(s)
in Assembly Line pattern, 374-376
in Cold Start pattern, 381-384
of Control Channel Toolkit, 454-457
in core asset development, 291-292
core asset development in, 295-299
in Curriculum pattern, 354-356
definition of, 290
documenting, 290
in Essentials Coverage pattern, 357-360
in In Motion pattern, 384-386
incentives in, 293
in Process pattern, 386-393
in Process Improvement pattern, 388
in product development, 292
product line architect in, 295-299
in product lines, 291
production plans and, 291
in Warm Start pattern, 384
Options Analysis for Reengineering (OAR), 103-106
ORB. See Object Request Broker
Organizational culture
at CelsiusTech, 39
core asset development and, 264-268
at Cummins Inc., 39, 427
at Hewlett Packard, 409-411
launching and institutionalizing and, 264-268
at Market Maker Software AG, 504-505
software product lines and, 38-40
Organizational domain modeling (ODM), 146
Organizational management
of Control Channel Toolkit, 454
core assets, contribution to, 45
definition of, 45
risk management integrated with, 203-204
Organizational management practice area(s), 219-343
acquisition strategy development (See Acquisition strategy)
business cases (See Business cases)
customer interface management (See Customer interface management)
definition of, 54, 219, 220f
funding (See Funding)
market analysis (See Market analysis)
operations (See Operations)
organizational planning (See Organizational planning)
organizational risk management (See Organizational risk management)
organizational structure (See Organizational structure)
relationships among, 219, 220f
technology forecasting (See Technology forecasting)
training (See Training)
Organizational plan(s). See also Organizational planning
for artifact evolution and sustainment, 53
dependencies among, 303, 304
examples of, 303
Organizational planning, 302-305. See also Organizational plan(s)
adoption plans in, 303, 304, 305
in Assembly Line pattern, 374-376
in Cold Start pattern, 354-356
configuration management in, 303, 304, 305
of Control Channel Toolkit, 454
in core asset development, 304-305
in Curriculum pattern, 354-356
in Essential Coverage pattern, 357-360
funding in, 303, 304
in Monitor pattern, 376-378
organizational structure in, 304, 313-314
participants in, 303
practice risks of, 305
in Process pattern, 386-393
in Process Improvement pattern, 388
in product development, 305
in product lines, 303-304
risk management in, 304, 305
scope of, 302, 303
tool support in, 303-304
training in, 304
in Warm Start pattern, 384
Organizational risk management, 306-312. See also Risk management; Technical risk management
in core asset development, 309
in Curriculum pattern, 354-356
in Essentials Coverage pattern, 357-360
in In Motion pattern, 384-386
practice risks of, 311
in product development, 310
in product lines, 308-309
TRM in, 310-311, 311f
Organizational structure, 312-327
at CelsiusTech, 320-326, 321f, 322f, 325f
in Cold Start pattern, 381-384
change management of, 327
“concept alignment,” 430
of Control Channel Toolkit, 452-453, 453t, 480-481
in core asset development, 314-316
criteria for, 314
at Cummins Inc., 426-430
in Curriculum pattern, 354-456
definition of, 312
in Essentials Coverage pattern, 357-360
evolving, 315, 320-326, 321f, 322f, 325f
funding and, 428
implementation approach and, 499
in In Motion pattern, 384-386
in MERGER product line, 499-500
models for, 316-320, 317f, 318f, 320f
morale and, 428
in organizational planning, 304, 313-314
Organizational structure (continued)
at Owen Firmware Cooperative, 410-411
practice risks in, 326-327
in product development, 316
in product lines, 313-314
for reuse businesses, 319
two-part, 427-430
Owen Firmware Cooperative, 409-411
organizational structure at, 410-411

P

Parameters of variation, definition of, 142
Pattern(s)
architecture, 35
components and, 35-36
in core asset development, 31, 35-36
definition of, 350
launching as, 272
value of, 349-351
People, reuse of, 20
Performance model(s) as core assets, 33
Performance testing, 128
Philips
architectural binding and, 65
multiple vs. single product lines, 189-190
product line testing at, 130
Philips Medical Systems
architectural requirements and, 58-60
Pronk, Ben, 58
Philips Research Laboratories, service component frameworks and, 70
Pilot project(s), 276-278
criteria for, 277
for Cummins Inc., 423
in launching and institutionalizing, 276-278
scoping, 277
PLA (Product Line Analysis), 114
Plan(s)
acquisition, 248
as core assets, 198-199
improvement, 199-200
mitigation, 204-206
organizational (See Organizational plan[s])
production (See Production plan[s])
reuse of, 199
for risk management, 205-206
test, 33
training (See Training plan[s])
Platform. See Core asset(s)
Plowed Field Pattern, 372, 373f
Practice area(s), 51-54
approach to, 346-348
CMMI process areas vs., 390-392, 390t-391t
Control Channel Toolkit coverage of, 450-457
Cummins Inc., coverage of, 440-441, 441t
definition of, 51
divide-and-conquer strategy for, 347, 350
dynamics of, 353
expertise and, 390
metrics for, 53
necessity of coverage for, 396
organizational management (See Organizational management practice area[s])
Product Line Technical Probe of, 348
relationship among categories of, 349, 350f
software engineering (See Software engineering practice area[s])
specific practices for, 52
technical management (See Technical management practice area[s])
work plan for, 53
Practice pattern(s), 349-397, 395t
Analysis pattern, 367-368
Assembly Line pattern, 374-376
Barren Field pattern, 372
Cold Start pattern, 381-384
Curriculum pattern, 354-356
definition of, 350
describing, 352-354
Each Asset Apprentice patterns, 363-364
Each Asset pattern, 360-364
Essentials Coverage pattern, 357-360
Evolve Each Asset pattern, 364
Factory pattern, 393-395
Forced March pattern, 368
Green Field pattern, 372
In Motion Pattern, 384-386
Monitor pattern, 376-378
other types, 395-396
Plowed Field pattern, 372
Process Improvement pattern, 388
Process pattern, 386-393
Product Builder pattern, 378-381
Product Gen pattern, 381
Product Parts pattern, 369-373
schema for, 352, 352f
template for, 353
uses of, 351
Warm Start pattern, 384
What to Build pattern, 365-369
Preexisting asset(s) in core asset development, 31, 36
Preintegration. See Software system integration, preintegration
Procedure call, 62
remote, 62-63
Process(es)
attached (See Attached processes)
CMMI process areas and, 390
discipline in, 514, 517
implementing, 390
of planning, 193-195
reuse of, 20
Process definition, 175-179
in Assembly Line pattern, 374-376
attached processes in, 177
configuration management in, 176
core asset development and, 177
in Curriculum pattern, 354-356
in Each Asset pattern, 360-364
goals of, 175
practice risks of, 178-179
product development and, 177
in Monitor pattern, 376-378
in Process pattern, 386-393
in Process Improvement pattern, 388
in production plans, 176
role of, 175
software process modeling, 175
software product lines and, 176
specific practices for, 177-178
Process improvement, 280-281
CMMI in, 280-281
at Cummins Inc., 434
launching and institutionalizing and, 280-281
with product line focus, 392
product lines and, 388-392
Process Improvement pattern, 388
Process pattern, 386-393
dynamic structure of, 387-388, 387f
variants of, 388
Product Builder pattern, 378-381, 380f
in Factory pattern, 393-395
variants of, 380-381
Product builder’s guide, 68-69
at Cummins Inc., 435-436
Product constraints in core asset development, 35
Product development
acquisition strategy in, 250
architecture definition and, 67
architecture evaluation and, 78-79
business cases in, 230
component development and, 85-86
configuration management and, 157
core assets in, 37
COTS and, 95
customer interface management in, 241-243
data collection and, 161
domains and, 143-144
funding in, 257-258
inputs for, 40-41
launching and institutionalizing and, 268
make/buy/mine/commission analysis and, 170-171
market analysis in, 286-287
metrics and, 164
mining assets and, 103
operations in, 292
organizational planning in, 305
organizational risk management in, 310
organizational structure in, 316
Product development (continued)
priorities for, 429
process definition and, 177
production plan for, 198-199
production plan in, 37, 40-41
requirements engineering and, 113-114
requirements in, 37, 40-41
scope definition and, 183-184
scope in, 37, 40-41
software system integration and, 122
technical planning and, 198-199
technical risk management in, 202-203
technology forecasting for, 330
testing and, 127
tool support for, 213-214
training for, 336
Product family. See Software product line(s)
Product Gen pattern, 381
Product Line Analysis (PLA), 114
Product Line practice patterns. See Practice pattern(s)
Product line champion (leader), 45
for Control Channel Toolkit, 474
for MERGER product line, 509
in successful product lines, 516
Temple, Ronald H. as, 423, 434
Product line manager, 45
Product Line Planning Workshop, 413-414
Product Line Platform, 208-211, 210f, 211f
Product line scenario(s)
for command and control system, 467-468
in scoping, 191-192
Product line scoping. See Scoping
Product Line Technical Probe, 399-416
benefits of, 400-401
definition of, 278, 348, 399
follow-on phase, 413-414
participants in, 404
of practice areas, 348
preliminary phase of, 405-411
process for, 405-414
Product Line Planning Workshop, 413-414
questions for, 400-403, 405-408
results of, 399-400, 414
schedule for, 412-413
self-probe, 414-415
structure of, 411-412
technical probe phase, 411-413
Product lines (business units). See Business unit(s)
Product lines (general)
CelsiusTech, 1-3
Chinese architecture and, 7
definition of, 2
single products vs., 13
single-system development with reuse vs., 12
small-grained reuse vs., 11
standard component-based development vs., 12
technical standards vs., 13
ubiquity of, 6-8
Product lines (software). See Software product line(s)
Product Parts pattern, 369-373, 371f
In Factory pattern, 393-395
variants of, 372-373, 373f
Product plans, 195
Production constraints in core asset development, 31, 36
Production, economies of, for software product lines, 5-6
Production plan(s), 198-200
attached processes in, 177
constructing, 199
in core asset development, 34-35
developing, 35
integration plans in, 199
operations and, 291
process definition in, 177
in product development, 37, 40-41
reuse of, 20
Production strategy in core asset development, 36
Project, definition of, 193-194
Project management, risk management and, 203, 307, 307f
Pronk, Ben, 58
Protocol(s)
communication, 63
for customer requirements, 237
definition of, 62, 128
in testing, 128
PuLSE-ECO method in scoping, 191

Q

Quality attribute(s), architecture definition and, 57-58

R

Rational Unified Process (RUP), 67, 180
Raytheon Company, 444. See also Control Channel Toolkit; Hughes Electronics Corporation
background of, 446-447
benefits from Control Channel Toolkit, 475
Shaw, Jeff, 474
Reference architecture, 12-13
Regression testing, 128-129, 132
Release management at Cummins Inc., 436
Relevant domains. See Domain(s)
Reliability models, testing and, 129-130
Remote Method Invocation (RMI), 63, 496
Remote procedure call, 62-63
Representative testing, 128
Requirement(s)
architectural, 58
architecture evaluation and, 76
in Barren Field pattern, 372
for command and control systems, 458-459
as core assets, 111
of customer, 241
of customers, 237
for DCCS, 458-459
definition of, 109
in Each Asset pattern, 360-364
in Evolve Each Asset pattern, 364
in Green Field pattern, 372
for MERGER product line, 497-498
Philips Medical Systems and, 58-60
in product development, 37, 40-41
in Product Parts pattern, 369-373
reuse of, 19
scope vs., 180-183
in software engineering practice areas, 56-57, 56f
for Spacecraft C2 System, 458-459
for SSCS, 458-459
traceability of, 115
Requirements analysis for Control Channel Toolkit, 458-459
Requirements definition
at Cummins Inc., 424
hierarchy, 70-71
Requirements engineering, 109-117
In Analysis pattern, 367-368
author role, 109-110
change management for, 110-111
change-case modeling in, 115
complexity of, 109-110
core asset development and, 112-113
at Cummins Inc., 436
in Curriculum pattern, 354-356
definition of, 109
developer role, 109-110
domain analysis techniques for, 114
in Essentials Coverage pattern, 357-360
practice risks of, 115-116
product development and, 113-114
in Product Gen pattern, 381
in Product Builder pattern, 378-381
product lines and, 111-112
requester role, 109-110
in scoping, 111
technical probe questions for, 402-403
use-case modeling in, 115
Requirements specifications as core assets, 33
Resources, economies of, economic conditions and, 18-19
Reuse
of analysis, 19
of architecture, 19
of architecture evaluation artifacts, 78
Reuse (continued)
of asset base, 19-20
background of, v-vi
of business cases, 225
“clone and own,” 12, 176
of components, 19
cost of, 100
domains and, 141
of metrics, 164-165
metrics for, 479-480
of models, 19
obstacles to, v-vi
of people, 20, 313
of plans, 199
of process, 20
of production plans, 20
of requirements, 19
single-system development with, 12
small-grained, 11, 100
software product line approach to, 11
of software system integration, 118-120
success factors in, v-vi
success of, 9
of technical planning, 20
of testing, 19-20
Reuse businesses, organizational structure for, 319
Reuse libraries, 11
Reuse plan(s), 195. See Production plan(s)
Reuse-driven software processes (RSP) approach, 146
Rigi in architecture recovery/ reconstructions, 106
Risk(s)
baseline for, 205
as core assets, 33
definition of, 201
identification of, 205-206
Risk management. See also Organizational risk management; Technical risk management
barriers to, 206-207, 207t
CRM and, 202, 203f
at Cummins Inc., 431
definition of, 201-202
implementing, 205-206
installation of, 204-205
mitigation plans for, 205-206
organizational management integrated with, 204
in organizational planning, 304, 305
plan for, 205
principles of, 306-308, 307f
project management and, 307, 307f
project management integrated with, 203-204
TBQ in, 205
Risk statement, 202-203, 203f
Risk Taxonomy-Based Questionnaire (TBQ), 205
Robert Bosch GmbH, scoping at, 192
RSP (Reuse-driven software processes) approach, 146
RUP (Rational Unified Process), 67, 180
Russia, Sputnik I, 443

S

SAAM. See Software Architecture Analysis Method
Satellites
command and control systems for (See Command and control system[s])
software product lines and, 443-483
Sputnik I, 443
uses of, 443
Scale, economies of, definition of, 521
Scenario(s). See Product line scenario(s)
Scope
architecture and, 71
business case and, 225
commonality, and variability (SCV) analysis, 145
in core asset development, 31-32
at Cummins Inc., 432, 433t
defining (See Scoping)
definition of, 31
economies of, definition, 522
Japanese software companies and economies of, 10
market analysis and, 286
of organizational planning, 302, 303
planned and economies of, 10
in product development, 37, 40-41
requirements vs., 180
software product lines and economies of, 9
statement of, as core assets, 33
technology forecasting and, 330
Scope definition
as core asset, 185
definition of, 180
driving factors of, 183-184
goal of, 183
market analysis influenced by, 185
product development and, 184-185
product lines and, 180-183
refining, 180
Scoping, 31-32, 179-193
in Analysis pattern, 367-368
attribute/product matrix in, 190-191, 190f
CelsiusTech and, 184-185
context diagram in, 190, 190f
for Control Channel Toolkit, 458-460
coordination with acquisition strategy, 249
core asset development and, 185
in Curriculum pattern, 354-356
definition of, 179-180
in Essentials Coverage pattern, 357-360
existing products in, 186-187
in Forced March pattern, 368
perspective of, 188
for pilot projects, 277
practice risks of, 191-192
proactive, 185
product line goals and products in, 188-189
product line scenarios in, 191
product lines and, 180-185
PuLSE-ECO method in, 191
requirements engineering in, 111
at Robert Bosch GmbH, 188-189
RUP on, 180
stakeholders in, 192
in What to Build pattern, 365-369
SCV (Scope, commonality, and variability) analysis, 145
Sellemerten, Axel, 487
Semantic Designs, Inc., 103-105
Baxter, Ira, 104-105
CloneDR, 104-105, 104f
Service component frameworks, 70
Shaw, Jeff, 474
Single products vs. software product lines, 13
Software Architecture Analysis Method (SAAM), 80
in Control Channel Toolkit, 466-467
Software Bookshelf in architecture recovery/reconstructions, 106
Software component(s). See Component(s)
Software development technologies, software product lines and, 513-514
Software engineering practice area(s)
architecture definition (See Architecture definition)
architecture evaluation (See Architecture evaluation)
architecture in, 56-57, 56f
component development (See Component development)
components in, 56-57, 56f
COTS utilization (See COTS utilization)
definition of, 56-57
domains in, 56-57, 56f
mining assets (See Mining assets)
relationships among, 56-57, 56f
relevant domains (See Domain[s])
requirements engineering (See Requirements engineering)
requirements in, 56-57, 56f
software system integration (See Software system integration)
testing (See Testing)
Software performance engineering (SPE), 80
Software process modeling, definition of, 175
Software product line(s). See also Product lines (general)
acquisition strategy in, 248-249
adoption plans for, 264-268, 270-271, 280
analysis approach for, 169-170
architecture evaluation and, 77
architecture of, 44
architectures and, 64-67
balanced portfolio of, 188
benefits of using, 17-28, 431-434
benefits vs. costs, 23-27, 24t-25t
business cases in, 222
business cases in launch of, 225, 225f
CASE tools for, 207-208
CelsiusTech, 26-27, vii-viii
component development and, 85
of components, 41-44
configuration management and, 152-160, 153f
Control Channel Toolkit (See Control Channel Toolkit)
core assets and, 176
cost savings of, 226-229, 227f
costs of approach, 225, 229f
COTS and, 93-94
at Cummins Inc., 421-423
customer interface management in, 236-241
definition of, 5, 13-14, 15f, 513
development as business decision, 223
development of, 30t
disadvantages of, 507-508
domain models and, 140
domains and, 139-141
economies of scope and, 9
for engines, 421-423
flexibility of, 2-3
funding for, 255-256
goal of, 37
goals development for, 278
goals in business cases, 232, 233t
goals in scoping, 188
IDEAL model for, 273-276
indicators and measures for, 164-165, 165f
intellectual rights to, 452
launching and institutionalizing of, 263-264
leaders and, 48
loyalty to, 517-518
market analysis in, 285-286
marketing, 238
MERGER (See MERGER product line)
metrics for management of, 164-165
mining assets and, 101-102
multiple vs. single, 185-186
new business areas and, 432-433
objectives development for, 278
operational concept for, 176
operations in, 291
organizational culture and, 38-40
in organizational planning, 303-304
organizational risk management in, 308-309
organizational structure and, 23, 26
organizational structure in, 313-314
patterns for (See Practice pattern[s])
at Philips, 185-186
practice of, 14
process definition and, 176-180
process improvement and, 388-392
process improvement with, 392
Product Line Technical Probe for, 278
production economies of, 5-6
promise of, vii
protocol for customer requirements, 237
qualities for organization, 438-440
quality enhancement and, 19-20
reconfigurable architecture vs., 12-13
requirements engineering and, 111-112
risks of approach, 225, 229f
running, 430-431
satellites and, 443-483
scoping and, 180-183
in small organizations, 485-512
software development technologies and, 513-514
software system integration and, 118-122
strategies development for, 278
success factors for, 516-518
technical planning and, 193-195
in technical risk management, 204
technology forecasting for, 329
testing and, 130-132
tool support for, 212-213, 214-215
tools for production of, 208-211
training for transition to, 339-341
training in, 333-335
trends influencing, 513-514
value maximization of, 187
viewpoints within, 308-309
Software product line practice pattern(s). See Practice pattern(s)
Software Reuse: Architecture, Process, and Organization for Business Success, 9, 49
Software system integration, 117-125
in Barren Field pattern, 372
component interfaces and, 117-118
continuous, 121
CORBA in, 123
core asset development and, 122
cost of, 121
of COTS, 92
at Cummins Inc., 425
in Curriculum pattern, 354-356
DCOM in, 123
definition of, 117
DOT, 123
effort involved in, 120
in Essentials Coverage pattern, 357-360
FAST in, 124
in Green Field pattern, 372
incremental model, 117
Java in, 123
middleware in, 123
in Plowed Field pattern, 372
practice risks of, 124
preintegration, 118, 120, 121-122
in Product Builder pattern, 378-381
product development and, 122
in Product Gen pattern, 381
product lines and, 118-122
in Product Parts pattern, 369-373
reuse of, 118-120
system functions in, 119
system generation and, 123
testing of, 128, 131-132
variation mechanisms and, 64-66
waterfall model, 117
wrapping in, 123
“Software Variantenbildung” project, Market Maker Software AG and, 490
Spacecraft C2 System, 448
benefits from Control Channel Toolkit, 475
in Control Channel Toolkit, 481
requirements of, 458-459
SPE (Software performance engineering), 80
Specific practices, definition of, 52
Sputnik I, 443
SSCS. See Standard Spacecraft Control Segment
Stakeholder(s)
in Control Channel Toolkit, 452
defining, 53
relationships with, 439
in scoping, 192
in technical probe, 404
Stakeholder-view modeling, 114
Standard Spacecraft Control Segment (SSCS), 447-448
requirements of, 458-459
Static libraries, 89
Stress testing, 128
Structural testing, 127, 133-134, 134f
Style(s). See Architectural style(s)
Subroutine(s), components and, 83-84
Subsystems
architecture and, 35
in Control Channel Toolkit, 461-466, 462f, 464f
Sun Microsystems, Inc.
Java (See Java)
JavaBeans, 42, 63-64
Synthesis process of the RSP approach, 146
System function(s)
definition of, 118
in integration, 119
System function(s) (continued)
preintegrated, 120
in testing, 119
System function group, definition of, 118
System generation, 123
System testing, 128

T

TBQ (Risk Taxonomy-Based Questionnaire), 205-206
TCP/IP, 43
Team Risk Management (TRM), 310-311, 311f
Technical management, 45
of Control Channel Toolkit, 473-474
core assets, contribution to, 45
definition of, 45
process definitions for, 33
Technical management practice area(s), 151-217, 151f
configuration management (See Configuration management [CM])
data collection, metrics, and tracking (See Data Collection; Metric[s])
definition of, 54
make/buy/mine/commission analysis (See Make/buy/mine/commission analysis)
process definition (See Process definition)
scoping (See Scoping)
technical planning (See Technical planning)
technical risk management (See Technical risk management)
tool support (See Tool support)
Technical planning, 193-201
In Assembly Line pattern, 374-376
contents of plans in, 194
of Control Channel Toolkit, 454
in core asset development, 197-198
of core asset development, 199
in core asset management, 195-197
in Curriculum pattern, 354-356
in Each Asset pattern, 360-364
in Essential Coverage pattern, 357-360
in Evolve Each Asset pattern, 364
improvement plans, 199-200
of maintenance work, 195
in Monitor pattern, 376-378
practice risks of, 200-201
process of, 193-195
in Process pattern, 386-393
in Process Improvement pattern, 388
product development and, 198-199
product lines and, 195
of production, 195
production plan construction, 199-200
relationships among plans in, 195
of reuse, 195
reuse of, 20
Technical risk management, 201-207. See also Organizational risk management; Risk management
in core asset development, 204
in Curriculum pattern, 354-356
in Essential Coverage pattern, 357-360
practice risks of, 206
in Process pattern, 386-393
in Process Improvement pattern, 388
in product development, 204
in product lines, 203
Technical standards vs. software product lines, 13
Technology change projects, definition of, 262-263
Technology forecasting, 328-333
in Analysis pattern, 367-368
as continuous improvement, 330
coordination with acquisition strategy, 249
for core asset development, 329-330
at Cummins Inc., 330-331
in Curriculum pattern, 354-356
for customer solutions, 328-329
in Essentials Coverage pattern, 357-360
in Forced March pattern, 368
importance of, 330-331
for internal development, 328
for MERGER product line, 503-504
practice risks of, 332
for product development, 330
for product lines, 329
purpose of, 328
scope and, 330
sources for, 331
steering group for, 331
validating, 331-332
in What to Build pattern, 365-369
Temple, Ronald H., 421
as leader, 47
on morale, 428
as product line champion, 434
Test cases as core assets, 33
Test plans as core assets, 33
Test software, 131
Testing, 125-130
acceptance, 129, 132, 134
on application program interface (API), 136
architectural support for, 131
in Barren Field pattern, 372
components of, 126
conformance, 129
for Control Channel Toolkit, 469-471, 470f
core asset development and, 132-134
of core assets, 133-134
core assets from, 132
of COTS, 92-93
criteria for, 126
at Cummins Inc., 430
in Curriculum pattern, 354-356
deployment, 129
in Each Asset pattern, 360-364
in Evolve Each Asset pattern, 364
in Green Field pattern, 372
guided inspection and, 135
guidelines for, 130-132
of MERGER product line, 500-501
of models, 126-127
of nonsoftware core assets, 133
in Plowed Field pattern, 372
practice risks of, 135-136
in Product Builder pattern, 378-381
in Product Gen pattern, 381
product development and, 127
product lines and, 130-132
in Product Parts pattern, 369-373
protocols in, 128
purposes of, 125
regression, 128-129, 132
reliability models and, 129-130
for reuse, 130-131
reuse of, 19-20
of subsystem integration, 128
of system integration, 128, 131-132
systems functions in, 119
types of, 127-128, 133-135, 134f
Tool support, 211-217
In Assembly Line pattern, 374-376
CASE tools, 207-208
for Control Channel Toolkit, 477
for core asset development, 214
in Curriculum pattern, 354-356
for development process, 207-208
in Each Asset pattern, 360-364
in Essentials Coverage pattern, 357-360
establishing, 212-213
in Evolve Each Asset pattern, 364
for make/buy/mine/commission analysis, 173
for MERGER product line, 506-507
for mining assets, 101
in organizational planning, 303-304
practice risks of, 216
for product development, 214
for product lines, 212-213, 214-215
Toshiba, 10
incentives in operations, 293
Training, 333-343
adoption plans and, 335
for core asset development, 335-336
as core assets, 33
curriculum at CelsiusTech, 339-341, 341f
funding for, 333
in Japanese software factories, 334
management support of, 334
in organizational planning, 304
practice risks of, 342
for product development, 336
for product line transition, 339-341
in product lines, 333-335
purpose of, 333
Training plan(s), 333
business goals and, 335
at CelsiusTech, 336-339
in Cold Start pattern, 381-384
as core assets, 336
in Curriculum pattern, 354-356
developing, 336
in Each Asset Apprentice pattern, 363-364
in Essentials Coverage pattern, 357-360
implementing, 341-342
in In Motion pattern, 384-386
Transfer Control Protocol/Internet Protocol (TCP/IP), 43
TreeAge Software
DATA, 173
DATA Interactive, 173
TRM (Team Risk Management), 310-311, 311f

U

Understanding relevant domains, 137-149
in Analysis pattern, 367-368
in Curriculum pattern, 354-356
in Essentials Coverage pattern, 357-360
in Forced March pattern, 368
in What to Build pattern, 365-369
Unit testing, 127, 133-134
for Control Channel Toolkit, 470
United States National Reconnaissance Office. See National Reconnaissance Office
Urmi, Jaak as leader, 47
Use-case modeling in requirements engineering, 115

V

Validation tests, 134
Value-based software engineering (VBSE), 223
Variability
architecture-based support for, 69-70
of Control Channel Toolkit, 465-466, 466t
at Cummins Inc., 432-434, 433t
Variability mechanism(s), 69-70, 87-88
aggregation/delegation, 87
aspect-oriented programming, 89
for components, 87-89, 88t
at Cummins Inc., 425
design patterns as, 89
dynamic class loading in Java, 88
dynamic link libraries, 89
frame technology, 89
inheritance, 87
integration and, 65-66
overloading, 88
parameterization, 88
properties in Delphi, 88
reflection, 89
static libraries, 89
Variation point(s), definition of, 115
VBSE (Value-based software engineering), 223
Verlage, Martin, 493
organizational structure and, 499-500
as product line champion, 509
Verlagsgruppe Handelsblatt GmbH, 494

W

WAE, 43
WAP, 43
Wappler, Thomas
on launching as project, 263-264
on pilot projects, 276-277
Warm Start Pattern, 384
Waterfall model, 117
WDP, 43
Welch, Jack as leader, 46, 48
What to Build Pattern, 365-369, 366f
in Barren Field pattern, 372
variants of 367-368
Whitney, Eli, 6
Wireless Application Environment (WAE), 43
Wireless Application Protocol (WAP), 43
Wireless Datagram Protocol (WDP), 43
Wireless Markup Language (WML), 43
Wireless Session Layer (WSL), 43
Wireless Transaction Protocol (WTP), 43
Wireless Transfer Layer Security (WTLS), 43
WISO-Börse, 490
WML, 43
Work plans for practice areas, 53
Wrapping
components to architecture, 107
in software system integration, 123
WSL, 43
WTLS, 43
WTP, 43

Updates

Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020