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

2. 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 Session 1 10 May 2009 DMW

3. 3 Engineer Application Process Artifact Key: Validation & Acceptance Customer(s) Delivered Product Requirements Decisions Components+ Tools+ Processes Code & Documentation

4. 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. Session 1 10 May 2009 DMW

5. 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. 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. Session 1 10 May 2009 DMW

7. 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. Session 1 10 May 2009 DMW8 Importance of Commonality USAir will reduce costs by using one aircraft type Airbus is reducing its production costs by reusing one aircraft type

9. Session 1 10 May 2009 DMW9 Examples of Families Airbus airplanes IBM 360 computers Internet browsers Versions of 5ESS TM Switch Maintenance Software –Software that enables changes in switch configuration while the switch is operating

10. Session 1 10 May 2009 DMW10 Economics Of Families Current Practice Number of Family Members Cumulative Cost Product Line Engineering { Initial Investment

11. Session 1 10 May 2009 DMW11 Economics Of Families Current Practice Number of Family Members Cumulative Cost Product Line Engineering { Initial Investment 1234 56

12. Session 1 10 May 2009 DMW12 123 Number of Family Members 4 Cumulative Savings -I S = N*(C T - C F ) - I P ayback Point S F - I 2*S F - I 3*S F - I 4*S F - I 5*S F - I S = Cumulative savings C T = Cost per family member with current practice C F = Cost per family member with domain engineering N = Number of family members I = Investment in domain engineering for the family

13. Session 1 10 May 2009 DMW13 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. Session 1 10 May 2009 DMW14 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. Session 1 10 May 2009 DMW15 Product Engineering Environment A FAST Process Domain Engineering Product Engineering Products Feedback Investment Payback

16. Session 1 10 May 2009 DMW16 Engineer Application Process Artifact Key: Validation & Acceptance Customer(s) Delivered System Requirements Decisions Components+ Tools+ Processes Code & Documentation Product Engineering Environment Products

17. Session 1 10 May 2009 DMW17 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. Session 1 10 May 2009 DMW18 Interval Reduction A B C D 0 20 40 60 80 100 Percent Previous Interval Reduced Interval

19. Session 1 10 May 2009 DMW19 FAST Applied To Switch Maintenance: Product Engineering For SM Configuration Control

20. Session 1 10 May 2009 DMW20 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. Session 1 10 May 2009 DMW21 5ESS™ Switch Configuration

22. Session 1 10 May 2009 DMW22 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. Session 1 10 May 2009 DMW23 Packet Service Unit Relationships

24. Session 1 10 May 2009 DMW24 Packet Service Unit Relationships With Attributes

25. Relationship Architecture Design (RAD)

26. Session 1 10 May 2009 DMW26 Domain Engineering Product Engineering Environment Domain Analysis Domain Model Domain Implementation Analysis Document, Application Modeling Language Tools, Process

27. Session 1 10 May 2009 DMW27 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. Session 1 10 May 2009 DMW28 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. Session 1 10 May 2009 DMW29 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. Session 1 10 May 2009 DMW30 Product Engineering Environment For Configuration Control

31. Session 1 10 May 2009 DMW31 FAST ARTIFACTS

32. Session 1 10 May 2009 DMW32 FAST ACTIVITIES

33. Session 1 10 May 2009 DMW33 FAST ROLES

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

35. Session 1 10 May 2009 DMW35 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 Session 1 10 May 2009 DMW36

37. Exercise 1: Scoping A Family Part 1 Identify and name a family and describe 3 members of your family Family: Members: 1. 2. 3. Session 2 20 May 2009 DMW37

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): Session 2 20 May 2009 DMW38

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

40. Teams RoleResponsibilityPerson Systems EngineerCommonality/variability analysis, decision model ArchitectModule, uses, process structures, interface specifications DeveloperModule implementation Tester & Integrator Module tests, System generation and verification Project ManagerEconomic model, project plan Session 2 20 May 2009 DMW40

41. Session 1 10 May 2009 DMW41 “If I have seen farther than others it is because I have stood on the shoulders of giants.” -- Isaac Newton

42. Session 1 10 May 2009 DMW42 “Everything should be as simple as possible, but no simpler.” -- Albert Einstein

43. Backups Session 1 10 May 2009 DMW43

44. Session 1 10 May 2009 DMW44

45. Session 1 10 May 2009 DMW45 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. Session 1 10 May 2009 DMW46 Application Model Analyses Requirements Application Engineer Requirements/NeedsCode/Documentation Application Engineering

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. Session 1 10 May 2009 DMW48 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. Session 1 10 May 2009 DMW49 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. Session 1 10 May 2009 DMW50 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.

51. Session 1 10 May 2009 DMW51 Variabilities V5. Some unit names have inhibit states. V7. The units to which a unit is related vary from unit to unit. V9. A child unit has one or more parent units. The parent units may be of different names. V10. The number of units of each parent unit name that must be working or ready...

52. Session 1 10 May 2009 DMW52 Parameters of Variation P5: inhibit state -- whether a unit name can have an inhibit state -- Boolean P6: restore parallelism -- whether units of this name may be restored in parallel P22: parent name information -- by unit name P25: parent units

53. Session 1 10 May 2009 DMW53 Reusable Assets Validations -- generic algorithms for every unit type Realizations -- generic algorithms for every unit type Relationships –data that is used to drive the generic algorithms –design information shared across development

54. Session 1 10 May 2009 DMW54 Defining The Family: The Commonality Analysis Dictionary of terms –Technical terms that define a vocabulary for the domain Primary Condition: The availability of a unit: working: ready, unready, or unusable Commonalities: Assumptions that hold for every member of the family –Every unit must be in one of the four primary conditions. Variabilities: Assumptions that define the range of variation for the family –Some unit names have inhibit states. Parameters of Variation: Quantification of the variabilities –Whether or not a unit name can have an inhibit state: Boolean

55. Session 1 10 May 2009 DMW55 Maintenance Domain Structure Human Machine Interface Diagnostics Hardware Software Interface Maintenance Administrator Fault Detection and Analysis Routine Maintenance Initialization Control Configuration Control 4

56. Session 1 10 May 2009 DMW56 SMALL-D Creating Configuration Controllers SMALL-V SMALL-R Domain Engineering Application Engineering VFSM C Data Application RAD 4

57. 57 Advantages of FAST Quick start-up –Social process and documentation method are easy to learn –Other methods require special languages and tools Immediate benefits –Knowledge discovery and documentation has immediate impact –Other methods require investment in new process or tools before any benefits Inclusive, not exclusive –All domain experts are welcome, they become owners –Other methods use specialists to record knowledge that is taken from domain experts Incremental benefits for incremental investment