Upload
xanthe
View
25
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Software Product-Line Engineering: A Family-Based Software Development Process: Introduction. David Weiss [email protected]. Goals. Bring the customer into the production loop for validation Separate the concerns of requirements determination and validation from design, coding, and testing - PowerPoint PPT Presentation
Citation preview
Software Product-Line Engineering: A Family-
Based Software Development Process:
IntroductionDavid Weiss
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
Session 1 10 May 2009 DMW 3
Engineer Application
Process Artifact
Key:
Validation & Acceptance
Customer(s)
Delivered Product
Requirements
Decisions
Components+Tools+Processes
Code & Documentation
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
Session 1 10 May 2009 DMW 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.
Session 1 10 May 2009 DMW
Session 1 10 May 2009 DMW 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.
Session 1 10 May 2009 DMW 8
Importance of Commonality
• USAir will reduce costs by using one aircraft type• Airbus is reducing its production costs by reusing one
aircraft type
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 10
Economics Of Families
CurrentPractice
Number of Family Members
Cumulative Cost
Product LineEngineering
{Initial Investment
Session 1 10 May 2009 DMW 11
Economics Of Families
CurrentPractice
Number of Family Members
Cumulative Cost
Product LineEngineering
{Initial Investment
1 2 3 4 5 6
Session 1 10 May 2009 DMW 12
1 2 3
Number of Family Members
4
Cumulative Savings
-I
S = N*(CT - CF) - I
Payback Point
SF - I
2*SF - I
3*SF - I
4*SF - I
5*SF - 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
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 15
Product Engineering Environment
A FAST Process
Domain Engineering
Product Engineering
Products
Feedback
Investment
Payback
Session 1 10 May 2009 DMW 16
Engineer Application
Process Artifact
Key:
Validation & Acceptance
Customer(s)
Delivered System
Requirements
Decisions
Components+Tools+Processes
Code & Documentation
Product Engineering
Product EngineeringEnvironment
Products
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 18
Interval Reduction
AB
CD
0
20
40
60
80
100
Percent PreviousInterval
ReducedInterval
Session 1 10 May 2009 DMW 19
FAST Applied To Switch Maintenance:
Product EngineeringFor SM Configuration Control
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 21
5ESS™ Switch Configuration
Lucent Technologies 5ESS
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 23
Packet Service Unit Relationships
Session 1 10 May 2009 DMW 24
Packet Service Unit Relationships With Attributes
Relationship Architecture Design (RAD)
Session 1 10 May 2009 DMW 26
Domain Engineering
Product Engineering Environment
Domain Analysis
Domain Model
Domain Implementation
Analysis Document,Application Modeling
Language
Tools, Process
Session 1 10 May 2009 DMW 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)
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 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)
Session 1 10 May 2009 DMW 30
Product Engineering Environment For Configuration Control
ControlCode
ApplicationEnvironment
RAD Diagram
Translator
DataStructures
Configuration Controller
Functions
Rules And Operations
Translator
Session 1 10 May 2009 DMW 31
Family Artifact
Environment
Economic Model
Commonality Analysis
Decision Model
Family Design
Composition Mapping
Application Modeling Language
Application Engineering Process
Domain Model
Domain Implementation
Library
Generation Tools
Analysis Tools
Documentation
Application
Application Model
Application Documentation
Application Code
Tool Set Design
FAST ARTIFACTS
Session 1 10 May 2009 DMW 32
FAST
Qualify Domain
Engineer Domain
Engineer Application
Model Application
Produce Application
Delivery and Operation Support
Manage Project
Change Family
Analyze Domain
Implement Domain
Define Decision Model
Analyze Commonality
Design Domain
Design Application Modeling Language
Create Standard Application Engineering Process
Design Application Engineering Environment
Implement Application Engineering Environment
Document Application Engineering Environment
FAST ACTIVITIES
Session 1 10 May 2009 DMW 33
Project Manager
Domain Manager
Environment Engineer
Domain Engineer
Application Manager
Application Producer
Application Engineer
System Maintainer/Supporter
FAST ROLES
Quantifying Benefits: Who’s Your Audience?
1) New Product effort decreases
Number of ProductsCum
ulat
ive
Effo
r t
Product LineDevelopment
TraditionalDevelopment
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 ProductsTim
e to
Mar
k et
Number of ProductsTim
e to
clo
se is
s ues
Cost and TimeNum
ber
o f F
e atu
res
Number of ProductsTim
e to
Inte
g rat
e
Number of Products
Tim
e to
Qua
l ity
Session 1 10 May 2009 DMW 34
Session 1 10 May 2009 DMW 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
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 DMW 36
Exercise 1: Scoping A FamilyPart 1
• Identify and name a family and describe 3 members of your family
Family:
Members:
1.
2.
3.
Session 2 20 May 2009 DMW 37
Exercise 1: Scoping A Family Part 2
Postulate an economic model for your family and define its key parametersAssumptions (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 DMW 38
Exercise 1: Scoping A Family Part 2 (cont.)
Form of the model (equations, graph)
Session 2 20 May 2009 DMW 39
Teams
Role Responsibility Person
Systems Engineer Commonality/variability analysis, decision model
Architect Module, uses, process structures, interface specifications
Developer Module implementation
Tester & Integrator Module tests, System generation and verification
Project Manager Economic model, project plan
Session 2 20 May 2009 DMW 40
Session 1 10 May 2009 DMW 41
“If I have seen farther than others it is because I have stood on the shoulders of giants.”
-- Isaac Newton
Session 1 10 May 2009 DMW 42
“Everything should be as simple as possible, but no simpler.”
-- Albert Einstein
Backups
Session 1 10 May 2009 DMW 43
Session 1 10 May 2009 DMW 44
Family MembersNeeded by Customer 1
Family MembersNeeded by Customer 2
Family MembersNeeded by Customer 3
Initial FamilyMember For
Initial FamilyMember ForCustomer 1
Customer 3
Key
Family Member
Customer 1
Customer 2
Customer 3
1.2.1
1.2.2
1.2.1.1
3.1.1.1
3.1.1.2
3.2.1.1
3.1.1.1.1
Initial FamilyMember ForCustomers 2
Common domain
1.1
2.1
3.1
1.2
2.1.1
2.1.2
3.1.1
3.2.1 3.2.1.1.1
2.0
3.0
1.0
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 46
ApplicationModel
Analyses
RequirementsApplicationEngineer
Requirements/Needs Code/Documentation
Application Engineering
“... 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
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 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
Session 1 10 May 2009 DMW 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.
Session 1 10 May 2009 DMW 51
Variabilities
V5. Some unit names have inhibit states.
V7. The units to which a unit is related vary fromunit to unit.
V9. A child unit has one or more parent units. Theparent units may be of different names.
V10. The number of units of each parent unit name thatmust be working or ready...
Session 1 10 May 2009 DMW 52
Parameters of Variation
P5: inhibit state -- whether a unit name can have aninhibit state -- Boolean
P6: restore parallelism -- whether units of this namemay be restored in parallel
P22: parent name information -- by unit name
P25: parent units
Session 1 10 May 2009 DMW 53
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
Session 1 10 May 2009 DMW 54
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
Session 1 10 May 2009 DMW 55
Maintenance Domain Structure
Human MachineInterface
Diagnostics
Hardware SoftwareInterface
MaintenanceAdministrator
Fault Detectionand Analysis
RoutineMaintenance
InitializationControl
ConfigurationControl
4
Session 1 10 May 2009 DMW 56
SMALL-D
Creating Configuration Controllers
SMALL-V SMALL-R
Domain Engineering
Application Engineering
VFSMC Data
Application
RAD
4
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