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

1. Software Product-Line Engineering: A Family-Based Software Development Process:Introduction David Weiss weiss@sei.pku.edu.cn

2. Goals • Bring the customer into the production loop for validation • Separate the concerns of requirements determination and validation from design, coding, and testing • Respond rapidly to changes in requirements • Rapidly generate deliverable products • generate code and documentation • achieve high productivity (factor of 3-5 improvement) • achieve high quality (factor of 5 improvement) • Be efficient • capture and leverage expertise • reuse systems

3. Customer(s) Validation & Acceptance DeliveredProduct Decisions Code & Documentation Requirements Engineer Application Components+ Tools+ Processes K e y: Artif act Process

4. Underlying Assumptions • The Redevelopment Hypothesis: Most software development is mostly redevelopment. • The Oracle Hypothesis: It is possible to predict the changes that are likely to be needed to a system over its lifetime. • The Organizational Hypothesis: It is possible to organize both software and the organization that develops and maintains it in such a way as to take advantage of predicted changes.

5. Families “We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members.” David L. Parnas

6. Airbus Beats Boeing in Huge Jetliner Deal with USAir (11/6/96) • USAir, which had never bought a plane from Airbus, will purchase 120 Airbus A319s, A320s, and A321s... • USAir’s current fleet is a hodgepodge of nine types of aircraft • A simplified domestic fleet would allow USAir to lower costs.

7. Airbus: Unique Level of Commonality • Conceived as a single aircraft programme, the A340 and A330 are virtually identical. • They share the same fuselage, airframe, systems and cockpit technology as the original A300/A310. • This commonality concept extends to the whole family of Airbus.

8. Importance of Commonality • USAir will reduce costs by using one aircraft type • Airbus is reducing its production costs by reusing one aircraft type

9. Examples of Families • Airbus airplanes • IBM 360 computers • Internet browsers • Versions of 5ESSTM Switch Maintenance Software • Software that enables changes in switch configuration while the switch is operating

10. Economics Of Families CurrentPractice Cumulative Cost Product LineEngineering { Initial Investment Number of Family Members

11. Economics Of Families CurrentPractice Cumulative Cost Product LineEngineering { Initial Investment 5 6 1 2 3 4 Number of Family Members

12. Cumulati v e Sa vings 5*S - I F S = N*(C - C ) - I T F 4*S - I F 1 2 3 4 3*S - I F Number of F amily Members P ayback Point 2*S - I F S - I F -I S = Cumulative savings CT = Cost per family member with current practice CF = Cost per family member with domain engineering N = Number of family members I = Investment in domain engineering for the family

13. Product Line • A family of products designed to take advantage of its common aspects and predicted variabilities • A product line may be decomposed into sub-families • Each subfamily contributes a member to members of the product line • Sub-families may themselves be product-lines

14. FAST Process • A process for defining families and developing environments for generating family members • Find abstractions common to the family • Define a process for producing family members • Design a language for specifying family members • Generate software from specifications • Family-oriented Abstraction, Specification, Translation

15. Product Engineering A FAST Process Investment Domain Engineering Feedback Product Engineering Environment Payback Products

16. Product Engineering Customer(s) Products Validation & Acceptance Delivered System Decisions Code & Documentation Requirements Engineer Application Components+ Tools+ Processes Product Engineering Environment K e y: Artif act Process

17. Measuring The Effect In Legacy Systems That Have Been Reengineered • Environment: Large legacy systems with many domains • Goal: Measure effort and time per change before and after a domain is reengineered • Data Needed • Change history • Type, Time, Effort, Developers • Tags in the code that indicate reengineering • Lucent results • Effort (or time) improvement of about a factor of 3

18. Previous Interval Percent 100 80 60 40 20 0 Reduced Interval A B C D Interval Reduction

19. FAST Applied To Switch Maintenance:Product EngineeringFor SM Configuration Control

20. Switch Maintenance Configuration Control • Software That Enables Changes In Switch Configuration While The Switch Is Operating • Ensures that requested configurations are valid and safe • Reconfigures • Example: Remove a Protocol Handler (PH) from service and replace it with a spare • New Switching Technology Requires New Configuration Controllers • New unit types

21. 5ESS™ Switch Configuration

22. Product Engineering Environment For Configuration Control • Language for specifying relationships among units • Relationship Architecture Designer (RAD) • Translator for RAD • Generates C from RAD diagrams

23. Packet Service Unit Relationships

24. Packet Service Unit Relationships With Attributes

25. Relationship Architecture Design (RAD)

26. Domain Model Domain Implementation Domain Engineering Domain Analysis Analysis Document, Application Modeling Language Tools, Process Product Engineering Environment

27. The Domain Model • Conceptual Framework • Family Definition • Commonalities and Variabilities Among Family Members • Parameters of Variation • Common Terminology for the Family • Decision Model • Economic Analysis • Product Line Architecture • Optional: Application Modeling Language (AML): Language for stating requirements • Mechanism for generating products • Composer or Compiler (AML)

28. The Conceptual Framework (1) • Qualify The Domain • Is it economically viable? • Artifact: Economic Model • Define The Family • What do members of the family have in common and how do they vary? • Artifact: The Commonality/Variability Analysis • Define The Decision Model • What decisions must be made to identify a family member? • Artifact: The Decision Model Table

29. The Conceptual Framework (2) • Create The Architecture • What is a good modular structure and a good uses structure? • Artifacts: Module Guide, Interface Specifications, Uses Relation • Design The System Composition Mapping • What modules are needed for which decisions? • Artifacts: System Composition Mapping, Uses Relation • Design The Product Engineering Environment • What are good mechanisms for using the decision model to produce products or to generate products from the AML? • Artifacts: Decision Model GUI, Generator or Compiler (AML)

30. Product Engineering Environment For Configuration Control

31. FAST ARTIFACTS

32. FAST ACTIVITIES

33. FAST ROLES

34. Traditional Development Cumulative Effort Product Line Development Number of Products Time to Integrate Time to Market Number of Products Number of Products Time to Quality Time to close issues Number of Products Number of Products Quantifying Benefits: Who’s Your Audience? 4&5) Feature development cost and time decreases 1) New Product effort decreases Number of Features Cost and Time 2) Time to Market decreases 6) Time to integrate COTS decreases 3) Time for Customer Issues decreases 7) Time to Qualify Products decreases

35. Summary • Product lines take advantage of commonalities to make software development more efficient • Reorganizing software production to take advantage of the family viewpoint is the key to improvement • Generation of code and documentation from a model is the goal

36. Terminology • Family • Product Line • Conceptual Model • Domain Engineering • Domain Model • Product Engineering (aka Application Engineering) • Product Engineering Environment • Decision Model • Commonality/Variability Analysis • System Composition Mapping • Application Modeling Language

37. Exercise 1: Scoping A FamilyPart 1 • Identify and name a family and describe 3 members of your family Family: Members: 1. 2. 3.

38. Exercise 1: Scoping A Family Part 2 Postulate an economic model for your family and define its key parameters Assumptions (For example, size of market, most valuable variabilities) Parameters (For example, no.of family members, cost to produce a family member, time to break-even, profit as a function of members sold):

39. Exercise 1: Scoping A Family Part 2 (cont.) Form of the model (equations, graph)

40. Teams

41. “If I have seen farther than others it is because I have stood on the shoulders of giants.” -- Isaac Newton

42. “Everything should be as simple as possible, but no simpler.” -- Albert Einstein

43. Backups

45. Selecting Your Targets • Active domains • Frequent changes • Significant resources required • Revenue-producing domains • Independent domains • Little dependency on others • Often, near to the hardware

46. Application Engineering Requirements/Needs Code/Documentation Analyses Application Model Requirements Application Engineer

47. “... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.” Edsger W. Dijkstra On Program Families

48. Commonality Analysis of Configuration Control • Approximately 20 staff -weeks • Spread over 6 months • 6-12 experts • Produced a Commonality Analysis • Definitions • Commonalities • Variabilities • Parameters of Variation • Reviewed by entire organization

49. Definitions • Configuration: A set of units, the relationships between those units, and the status of the units. • Primary condition: The availability of a unit: working, ready, unready, or unusable • Realization: A sequence of steps from an initial configuration to a final configuration

50. Commonalities C8. Every unit has a status. C9. Every unit has a name and number, e.g., QLPS-0-1. Units with the same name provide the same functionality. C10. All units of the same name have the same set of conditions.