did-you-know? rent-now

Amazon no longer offers textbook rentals. We do!

did-you-know? rent-now

Amazon no longer offers textbook rentals. We do!

We're the #1 textbook rental company. Let us show you why.

9780201694383

Software Product-Line Engineering A Family-Based Software Development Process

by ;
  • ISBN13:

    9780201694383

  • ISBN10:

    0201694387

  • Edition: 1st
  • Format: Paperback
  • Copyright: 1999-08-12
  • Publisher: Addison-Wesley Professional
  • Purchase Benefits
  • Free Shipping Icon Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • eCampus.com Logo Get Rewarded for Ordering Your Textbooks! Enroll Now
List Price: $49.95

Summary

Industries and marketplaces often suffer radical changes in seemingly brief periods of time. The software development industry, in all its forms, has the opportunity to undergo such a change now. The hallmark will be a conversion from software development processes that are characterized by develop-ing an individual system and then creating variations of it, to software development processes that create product lines and families of systems. Creating variations on individual systems takes continual investment in understanding new requirements, and in redesign, recoding, and retesting. Creating product lines and families, on the other hand, invests in support for understanding new requirements and rapidly cre-ating new family members with little or no redesign and recoding and with reduced retesting. Changing from the first strategy to the second means changing the software development techniques that you use and changing your organization. Fortunately, you can make both changes incrementally if you know what you are trying to achieve.

We wrote this book to show you what we think your target in improving your software development process should be: a software development process focused on building families. The process we describe is based on our experience with creating soft-ware families, experience that extends back to the middle 1970s. Most recently we have seen improvements from applying family-based processes at Lucent Technologies, showing decreases in development time and costs for family members of 60%n70%. Our comparison is based on measuring the time and effort to create variations on a product before a family-based process is introduced and again after it is used.

Our intent is to identify the key ideas whose combination can radically alter the way software developers do their jobs, with attendant major gains in their productiv-ity and in the quality of their products. By focusing software developers on building software families, these ideas can be woven into a process for software development that is much more effective than the processes in common use today. The result is a paradigm shift in software development that involves creating two new types of organizations: one devoted to defining families of programs and creating facilities needed for rapidly producing family members and a second one devoted to rapidly producing family members by using those facilities. Creation of members of a family is akin to a production process and is enabled by an investment in tools and pro-cesses for the entire family. The result is to make it possible to create high-quality software applications much faster than with current processes.

Most of the ideas we useosuch as abstraction, separation of concerns, information hiding, formal specification, and model buildingohave permeated the research lit-erature in software engineering for many years but have not been widely applied in engineering practice. A process that incorporates these ideas into a practical, family-oriented software production process was introduced at AT&T in 1992 by David Weiss; its roots can easily be traced back through 30 years of research in software engineering conducted by a variety of people. Called the Family-Oriented Abstraction, Specification, and Translation (FAST) process, it is now in use at Lucent Technologies, where its evolution is continuing. Because of its focus on producing family members, we often refer to FAST as a software production process rather than a software development process.

This book introduces the ideas that software development organizations need to know to evolve into software production organizations. Such an evolution is easiest if an organization can create for itself a software production process. Accordingly, the FAST process is really a pattern for doing so, and we think of any process that conforms to that pattern as a FAST process. Put another way, FAST processes form a family. Within Lucent we have created several members of the FAST family of processes, using variations on the basic pattern as people and circumstances demand. With the help of this book we hope that you can begin to create your own FAST processes.

Planning and structuring for change is a central theme of FAST processes. It has also been a key theme in software engineering for many years. Characteristic of this theme is a continuing search for better abstractions. Finding and applying appropri-ate abstractions in software design and in programming languages has been a major tool for software engineers. FAST processes further develop the theme of abstraction by asking software engineers to find, for each family, abstractions that are useful in defining the family and describing its members. For each family we incorporate such abstractions into a language for specifying and modeling family members. The description of a family member in the language can be analyzed for completeness, consistency, and other properties, and, with a sufficient investment, engineers can build tools that generate the software for the family member from its description. The ability to perform each of these steps represents a further step in an organiza-tionis evolution from a software development organization to a software production organization. The ability to do all of them represents a step in the evolution of the software engineering community to use abstractions to better advantage.

As an organization evolves from software development to software production, so will its FAST processes evolve. We have started this evolution within Lucent Technologies.To understand and track our progress, we need a way of precisely describing the pro-cesses we are using and have used. Our mechanism for doing so is the Process and Artifact State Transition Abstraction (PASTA) process description method.

PASTA allows us to describe the artifacts that we use in our process, the activities that are performed during the process, the operations that we use to manipulate the artifacts, and the roles played by people during the process. It allows us to describe activities that may proceed concurrently and activities that must be performed sequentially as well as situations when backtracking may occur. A PASTA model of a process is also a good basis for developing automated support for the process.

This book contains a PASTA reference model for FAST processes. Having such models gives us a record of the evolution of FAST. The nature of PASTA and its sup-porting tools help us to understand the possible effects of a change to FAST and make it easier for us to make changes to the model. PASTA thereby facilitates changes to the FAST process. We have left certain aspects of the model incomplete because they vary considerably from one organization to another. For example, the configu-ration management process is usually highly specialized for an organization.1 We have done no more than sketch how change reporting might be handled for a family. We hope that you will use the model in this book as a starting point for creating your own reference model for your own FAST process.

We live in a time when business enterprises of all sorts appear to be undergoing continuous change. Such change usually relies on altering the processes that the enterprise uses. In manufacturing industries, the idea of redesigning product lines and processes so that a product is easy to produce using its production process is known as concurrent engineering. Both product and process are designed together. FAST and PASTA together can be viewed as concurrent engineering for software: FAST processes help software engineers to design both a family whose members are based on predicted changes and a process for producing those members based on the predictions. PASTA helps a software development organization to deploy and enact FAST as a production process, providing a

Author Biography

David M. Weiss is head of the Software Production Research Department, part of the Systems and Software Research Center, at Lucent Technologies Bell Laboratories. His technical work has evolved into the invention of processes that incorporate ideas from families, design for change, measurement, precise specification, and technology transfer. The result has been a software production process based on family-oriented abstraction, specification, and translation, known as FAST. Chi Tau Robert Lai is founder of the International Software Process Constellation, Inc., which is an industry leader in process engineering and software automation.

Table of Contents

Foreword xiii(4)
Preface xvii
1 Introduction: The Need for Families
1(10)
The Dilemma of Careful Engineering and Rapid Production 1(2)
1.1 Problems FAST Addresses
3(2)
1.2 Applications of FAST
5(1)
1.3 Benefits of FAST
5(1)
1.4 What Can Readers Expect?
6(2)
1.5 Summary
8(1)
1.6 Nomenclature Introduced
9(1)
1.7 Readings for Chapter 1
9(2)
2 Family-Oriented Software Production
11(14)
Basic Assumptions 11(2)
2.1 FAST Strategies
13(3)
2.2 Foundations for Engineering Families
16(4)
2.2.1 The Role of Abstractions in Identifying and Designing Families
17(1)
2.2.2 The Role of Information Hiding and Separation of Concerns
18(1)
2.2.3 Predicting Change
19(1)
2.3 Organizational Considerations
20(2)
2.4 Summary
22(1)
2.5 Nomenclature Introduced
22(1)
2.6 Readings for Chapter 2
23(2)
3 AN EXAMPLE: FAST Applied to Commands and Reports
25(18)
The Commands and Reports Family 25(4)
3.1 Defining the C&R Family
29(4)
3.2 Using the C&R Application Engineering Environment
33(1)
3.3 The SPEC Language and Its Translators
33(4)
3.4 Designing the Translators
37(3)
3.5 Summary
40(1)
3.6 Nomenclature Introduced
41(1)
3.7 Reading for Chapter 3
42(1)
4 An Overview of FAST
43(24)
The Structure of FAST 43(2)
4.1 The Economics of FAST
45(4)
4.1.1 Case 1: No Domain Engineering
46(1)
4.1.2 Case 2: Domain Engineering
46(1)
4.1.3 The Fundamental Law of Family Production
47(1)
4.1.4 Risk Versus Automation
48(1)
4.2 Application Engineering
49(4)
4.2.1 Application Engineering Artifacts
52(1)
4.2.2 Application Production Activities
53(1)
4.3 Domain Engineering
53(4)
4.3.1 Domain Engineering Artifacts
55(1)
4.3.2 Domain Engineering Activities
56(1)
4.4 Organizational Roles
57(5)
4.5 Variability in the FAST Process
62(1)
4.6 Summary: The FAST Family of Processes
63(2)
4.7 Nomenclature Introduced
65(1)
4.8 Reading for Chapter 4
66(1)
5 AN EXAMPLE: The Floating Weather Station Family
67(76)
The Floating Weather Station Family 67(3)
5.1 Qualify the FWS Domain
70(3)
5.2 Engineer the FWS Domain
73(34)
5.2.1 Analyze the FWS Domain
73(14)
5.2.2 Implement the FWS Domain
87(20)
5.3 Summary
107(2)
5.4 Nomenclature Introduced
109(1)
5.5 Readings for Chapter 5
110(3)
Addendum A: The Floating Weather Station Commonality Analysis
113(8)
A.1 Introduction
113(1)
A.2 Overview
113(2)
A.3 Dictionary of Terms
115(1)
A.4 Commonalities
115(1)
A.5 Variabilities
115(1)
A.6 Parameters of Variation
116(1)
A.7 Issues
116(2)
A.8 Message Formats
118(1)
A.9 Sensor Driver Identifiers
119(2)
Addendum B: The Floating Weather Station Module Guide
121(6)
B.1 Behavior-Hiding Modules
123(1)
B.2 Device Interface Modules
124(1)
B.3 Software-Design-Hiding Modules
124(1)
B.4 Issues
125(2)
Addendum C: The Floating Weather Station Application Generation Environment
127(8)
C.1 Family Member Generator
127(8)
Addendum D: A Generated Floating Weather Station Family Member
135(4)
Addendum E: The Floating Weather Station Environment Simulator
139(4)
6 Process Modeling
143(24)
Motivations for Process Modeling 143(2)
6.1 A PASTA Model as a Communications Medium
145(1)
6.2 Elements of a PASTA Model
146(3)
6.3 Process Activities as State Machines
149(2)
6.4 Artifacts as State Machines
151(2)
6.5 Prescribing the Order of Events
153(1)
6.6 Prescribing a Methodology
153(1)
6.7 The Role of Process Modeling in FAST
154(1)
6.8 PASTA Abstractions
155(1)
6.9 Creating PASTA Process Models
155(6)
6.9.1 The Process User's Concerns
158(2)
6.9.2 PASTA Models as Used by Process Environment Developers
160(1)
6.10 Process Measurement Using PASTA
161(1)
6.10.1 Measuring a Process Model
161(1)
6.10.2 Measuring Process Performance
161(1)
6.11 Summary
162(2)
6.12 Nomenclature Introduced
164(1)
6.13 Readings for Chapter 6
165(2)
7 Representing a PASTA Model
167(22)
7.1 Representations of PASTA Elements
167(2)
7.2 PASTA Forms
169(18)
7.2.1 Notational Considerations
170(1)
7.2.2 Artifact Definition Form
170(4)
7.2.3 A-State Machine Diagrams
174(1)
7.2.4 Process State Definition Form
174(5)
7.2.5 P-State Machines
179(1)
7.2.6 Relation Definition Form
180(1)
7.2.7 Role Definition Form
181(1)
7.2.8 Operation Definition Form
182(3)
7.2.9 Analysis Definition Form
185(2)
7.3 Summary
187(1)
7.4 Nomenclature Introduced
188(1)
7.5 Readings for Chapter 7
188(1)
8 An Overview of the FAST PASTA Model
189(18)
8.1 FAST Model Hierarchies
189(1)
8.2 FAST Artifacts
190(4)
8.2.1 Environment Artifacts
191(2)
8.2.2 Application Artifacts
193(1)
8.2.3 Change_Report
194(1)
8.3 FAST Activities
194(5)
8.3.1 Qualify_Domain
194(1)
8.3.2 Engineer_Domain
194(3)
8.3.3 Implement_Domain
197(1)
8.3.4 Engineer_Application
197(1)
8.3.5 Manage_Project
198(1)
8.3.6 Change_Family
198(1)
8.4 FAST Roles
199(1)
8.4.1 FAST Manager
199(1)
8.5 Gluing the Elements Together: The State Transition Diagrams
200(1)
8.6 Typical Questions Answered by the Model
201(2)
8.7 First Steps in Applying the Model
203(2)
8.7.1 Identifying Starting Activities and Roles
203(1)
8.7.2 Other Scenarios
204(1)
8.8 Readings for Chapter 8
205(2)
9 Artifact Definitions
207(48)
9.0 Family_Artifact
209(2)
9.1 Environment
211(33)
9.1.1 Domain_Model
213(21)
9.1.2 Domain_Implementation
234(10)
9.2 Application
244(8)
9.2.1 Application_Model
246(2)
9.2.2 Application_Documentation
248(2)
9.2.3 Application_Code
250(2)
9.3 Change_Report
252(3)
10 Activity Definitions
255(72)
FAST 257(3)
10.1 Qualify_Domain
260(7)
10.1.1 Gather_Data
262(1)
10.1.2 Analyze_Data
263(2)
10.1.3 Reject
265(1)
10.1.4 Accept
266(1)
10.2 Engineer_Domain
267(42)
10.2.1 Analyze_Domain
269(24)
10.2.2 Implement_Domain
293(16)
10.3 Engineer_Application
309(7)
10.3.1 Model Application
312(1)
10.3.2 Produce_Application
313(1)
10.3.3 Delivery_And_Operation_Support
314(2)
10.4 Manage_Project
316(1)
10.5 Change_Family
317(5)
10.5.1 Request_Family_Change
319(1)
10.5.2 Evaluate_Implementation_Change
320(1)
10.5.3 Evaluate_Domain_Change
321(1)
10.6 Library_Activities
322(4)
10.6.1 Review_Internally
323(1)
10.6.2 Review
323(2)
10.6.3 Iterate_Or_Refine
325(1)
10.7 Reading for Chapter 10
326(1)
11 Role Definitions
327(26)
11.1 Project_Manager
328(25)
11.1.1 Domain_Manager
329(18)
11.1.2 Application_Manager
347(6)
12 FAST Analyses
353(30)
12.1 Application_Engineering_Process_To_Decision_Trace_Analysis
355(1)
12.2 Application_Engineering_Process_To_Tool_Trace_Analysis
356(1)
12.3 Application_Engineering_Support_Analysis
357(1)
12.4 Application_Modeling_Language_Editor_Assurance_Analysis
358(1)
12.5 Application_Modeling_Language_Parser_Assurance_Analysis
359(1)
12.6 Application_Modeling_Language_To_Family_Design_Trace_Analysis
360(1)
12.7 Artifact_Implementation_Assurance_Analysis
361(1)
12.8 Commonality_To_Module_Trace_Analysis
362(1)
12.9 Composition_Mapping_To_Family_Design
363(1)
12.10 Composition_Mapping_To_Language_Construct_Mapping_Analysis
364(1)
12.11 Composition_Mapping_To_Module_Trace_Analysis
365(1)
12.12 Customer_Satisfaction
366(1)
12.13 Decision_To_Tool_Trace_Analysis
366(1)
12.14 Defect_Analysis
367(1)
12.15 Final_Product_Documentation_Assurance_Analysis
368(1)
12.16 Final_Product_Validation_Analysis
369(1)
12.17 Module_Documentation_Assurance_Analysis
370(1)
12.18 Module_Implementation_Assurance_Analysis
371(1)
12.19 Parameter_Of_Variation_To_Decision_Trace_Analysis
372(1)
12.20 Parameter_Of_Variation_To_Language_Trace_Analysis
373(1)
12.21 Parameter_Of_Variation_To_Module_Trace_Analysis
374(1)
12.22 Progress_Analysis
375(1)
12.23 Resource_Analysis
376(1)
12.24 Risk_Analysis
377(1)
12.25 Terminology_Analysis
378(1)
12.26 Tool_Documentation_Assurance_Analysis
379(1)
12.27 Tool_Implementation_Assurance_Analysis
380(1)
12.28 Variability_To_Variation_Parameter_Trace_Analysis
381(1)
12.29 Variation_Parameter_To_Variability_Trace_Analysis
382(1)
13 FAST Relations
383(8)
13.1 Application_Model_Module
384(1)
13.2 Commonality_Module
385(1)
13.3 Composition_Mapping_AML
385(1)
13.4 Decision_Process
386(1)
13.5 Decision_Tool
386(1)
13.6 Module_Document
387(1)
13.7 Module_Implement
387(1)
13.8 Parameter_Decision
388(1)
13.9 Parameter_Module
388(1)
13.10 Product_Document
389(1)
13.11 Tool_Document
389(1)
13.12 Tool_Implement
390(1)
13.13 Variability_Parameter
390(1)
14 Summary
391(14)
14.1 Patterns of Thought and Work
391(2)
14.2 FAST and Reuse
393(1)
14.3 FAST as a Multiparadigm Process
394(1)
14.4 FAST and Object Orientation
394(1)
14.5 Applicability of FAST
395(4)
14.5.1 Finding Domains Where FAST Is Worth Applying
396(1)
14.5.2 The Single-Customer, Single-Product-Family Situation
397(1)
14.5.3 The Many-Customers, Single-Product-Family Situation
397(1)
14.5.4 The Many-Customers, Many-Product-Families Situation
398(1)
14.6 Applying FAST Incrementally
399(2)
14.7 Patterns of a FAST Organization
401(1)
14.8 Applying PASTA
401(1)
14.9 Transitioning to a FAST Process
402(1)
14.10 Readings for Chapter 14
403(2)
Glossary 405(4)
Bibliography 409(4)
Index 413

Supplemental Materials

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Excerpts

Industries and marketplaces often suffer radical changes in seemingly brief periods of time. The software development industry, in all its forms, has the opportunity to undergo such a change now. The hallmark will be a conversion from software development processes that are characterized by develop-ing an individual system and then creating variations of it, to software development processes that create product lines and families of systems. Creating variations on individual systems takes continual investment in understanding new requirements, and in redesign, recoding, and retesting. Creating product lines and families, on the other hand, invests in support for understanding new requirements and rapidly cre-ating new family members with little or no redesign and recoding and with reduced retesting. Changing from the first strategy to the second means changing the software development techniques that you use and changing your organization. Fortunately, you can make both changes incrementally if you know what you are trying to achieve. We wrote this book to show you what we think your target in improving your software development process should be: a software development process focused on building families. The process we describe is based on our experience with creating soft-ware families, experience that extends back to the middle 1970s. Most recently we have seen improvements from applying family-based processes at Lucent Technologies, showing decreases in development time and costs for family members of 60%n70%. Our comparison is based on measuring the time and effort to create variations on a product before a family-based process is introduced and again after it is used. Our intent is to identify the key ideas whose combination can radically alter the way software developers do their jobs, with attendant major gains in their productiv-ity and in the quality of their products. By focusing software developers on building software families, these ideas can be woven into a process for software development that is much more effective than the processes in common use today. The result is a paradigm shift in software development that involves creating two new types of organizations: one devoted to defining families of programs and creating facilities needed for rapidly producing family members and a second one devoted to rapidly producing family members by using those facilities. Creation of members of a family is akin to a production process and is enabled by an investment in tools and pro-cesses for the entire family. The result is to make it possible to create high-quality software applications much faster than with current processes. Most of the ideas we useosuch as abstraction, separation of concerns, information hiding, formal specification, and model buildingohave permeated the research lit-erature in software engineering for many years but have not been widely applied in engineering practice. A process that incorporates these ideas into a practical, family-oriented software production process was introduced at AT&T in 1992 by David Weiss; its roots can easily be traced back through 30 years of research in software engineering conducted by a variety of people. Called the Family-Oriented Abstraction, Specification, and Translation (FAST) process, it is now in use at Lucent Technologies, where its evolution is continuing. Because of its focus on producing family members, we often refer to FAST as a software production process rather than a software development process. This book introduces the ideas that software development organizations need to know to evolve into software production organizations. Such an evolution is easiest if an organization can create for itself a software production process. Accordingly, the FAST process is really a pattern for doing so, and we think of any process that conforms to that pattern as a FAST process. Put another way, FAST processes form a family. Within Lucent we have created several members of the FAST family of processes, using variations on the basic pattern as people and circumstances demand. With the help of this book we hope that you can begin to create your own FAST processes. Planning and structuring for change is a central theme of FAST processes. It has also been a key theme in software engineering for many years. Characteristic of this theme is a continuing search for better abstractions. Finding and applying appropri-ate abstractions in software design and in programming languages has been a major tool for software engineers. FAST processes further develop the theme of abstraction by asking software engineers to find, for each family, abstractions that are useful in defining the family and describing its members. For each family we incorporate such abstractions into a language for specifying and modeling family members. The description of a family member in the language can be analyzed for completeness, consistency, and other properties, and, with a sufficient investment, engineers can build tools that generate the software for the family member from its description. The ability to perform each of these steps represents a further step in an organiza-tionis evolution from a software development organization to a software production organization. The ability to do all of them represents a step in the evolution of the software engineering community to use abstractions to better advantage. As an organization evolves from software development to software production, so will its FAST processes evolve. We have started this evolution within Lucent Technologies.To understand and track our progress, we need a way of precisely describing the pro-cesses we are using and have used. Our mechanism for doing so is the Process and Artifact State Transition Abstraction (PASTA) process description method. PASTA allows us to describe the artifacts that we use in our process, the activities that are performed during the process, the operations that we use to manipulate the artifacts, and the roles played by people during the process. It allows us to describe activities that may proceed concurrently and activities that must be performed sequentially as well as situations when backtracking may occur. A PASTA model of a process is also a good basis for developing automated support for the process. This book contains a PASTA reference model for FAST processes. Having such models gives us a record of the evolution of FAST. The nature of PASTA and its sup-porting tools help us to understand the possible effects of a change to FAST and make it easier for us to make changes to the model. PASTA thereby facilitates changes to the FAST process. We have left certain aspects of the model incomplete because they vary considerably from one organization to another. For example, the configu-ration management process is usually highly specialized for an organization.1 We have done no more than sketch how change reporting might be handled for a family. We hope that you will use the model in this book as a starting point for creating your own reference model for your own FAST process. We live in a time when business enterprises of all sorts appear to be undergoing continuous change. Such change usually relies on altering the processes that the enterprise uses. In manufacturing industries, the idea of redesigning product lines and processes so that a product is easy to produce using its production process is known as concurrent engineering. Both product and process are designed together. FAST and PASTA together can be viewed as concurrent engineering for software: FAST processes help software engineers to design both a family whose members are based on predicted changes and a process for producing those members based on the predictions. PASTA helps a software development organization to deploy and enact FAST as a production process, providing a way to create guidebooks and

Rewards Program