Register your product to gain access to bonus material or receive a coupon.
Software Product Lines: Practices and Patterns
- By Paul Clements, Linda Northrop
- Published Aug 20, 2001 by Addison-Wesley Professional. Part of the SEI Series in Software Engineering series.
Book
- Sorry, this book is no longer in print.
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
- 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
- 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
- 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
- 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
- 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
- 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
- General Electric (GE), leadership of, 46
- Gleick, James, 6
- Goal-Question-Metric method, 164
- Green Field pattern, 372
- Griss, Martin, 9
- Guided inspection, 135
- 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
- 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
- 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
- Krueger, Charles, 208, 211
- 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
- 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
- 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
- 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
- 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
- Quality attribute(s), architecture definition and, 57-58
- 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
- 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
- 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
- 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
- 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
- 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
0201703327P07312001
Index
Note: Page numbers followed by the letters f and t indicate figures and tables respectively
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
More Information
Other Things You Might Like
- Book $35.99
- eBook $34.39