Product Line Engineering CS 415, Software Engineering II Mark Ardis, Rose-Hulman Institute March 11, 2003.

Slides:



Advertisements
Similar presentations
CESG, Fall 2011, 5 th November 2011 Stuart Fowell, SciSys Device Virtualisation and Electronic Data Sheets.
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Chapter 22 Product Line Engineering Week 1 CIS 673.
Alternate Software Development Methodologies
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
1 Product Lines 1: Commonality Analysis CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute November 1, 2004.
Software Engineering COMP 201
Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
Software Reuse Building software from reusable components Objectives
SE curriculum in CC2001 made by IEEE and ACM: Overview and Ideas for Our Work Katerina Zdravkova Institute of Informatics
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
1 SWE Introduction to Software Engineering Lecture 5.
Formal Methods: Industrial Use CS 415, Software Engineering II Mark Ardis, Rose-Hulman Institute March 21, 2003.
Managing Reuse Presented by: Aisha Al-Hammadi. Outline Introduction History. The technical and managerial advantages of Reusing Solutions. The main challenges.
1 Product Lines 2: Escaping from the Oral Culture CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute November 2, 2004.
L ECTURE 2 S OFTWARE P ROCESSES 1. O BJECTIVES To describe outline process models for requirements engineering, software development, testing and evolution.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Introduction to Software Testing
CSC230 Software Design (Engineering)
Software Product Line Architectures (SPLA) Nipun Shah
Page - 1 Rocketdyne Propulsion & Power Role of EASY5 in Integrated Product Development Frank Gombos Boeing Canoga Park, CA.
Chapter 3 Software Processes.
Chapter 9 – Software Evolution and Maintenance
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Software Project Management
Chapter 2 The process Process, Methods, and Tools
What is Enterprise Architecture?
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Software Processes (Chapter 3)
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2: Software Process Omar Meqdadi SE 2730 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Lecture 3 Software Engineering Models (Cont.)
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
MERCURY BUSINESS PROCESS TESTING. AGENDA  Objective  What is Business Process Testing  Business Components  Defining Requirements  Creation of Business.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Confederations and the Maintenance of Global Software Systems Jaroslav Král, Michal Žemlička Charles University, Prague
HRL © 2009 IBM Corporation Model-Driven Product-Lines for Embedded Software and for Supply-Chain Companies Tali Yatzkar-Haham Julia Rubin,
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
OOPSLA workshop on Domain-Specific Visual Languages 1 Framework for Domain-Specific Visual Languages Juha-Pekka.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Software Product-Line Engineering: A Family- Based Software Development Process: Introduction David Weiss
OOPSLA workshop on Domain-Specific Visual Languages 1 Juha-Pekka Tolvanen, Steven Kelly, Jeff Gray, Kalle Lyytinen.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
Software Engineering Introduction.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
March 2004 At A Glance The AutoFDS provides a web- based interface to acquire, generate, and distribute products, using the GMSEC Reference Architecture.
CASE Tools and their Effect on Software Quality
1 SYS366 Week 2 - Lecture Visual Modeling and Process.
1 Process activities. 2 Software specification Software design and implementation Software validation Software evolution.
A Method for Improving Code Reuse System Prasanthi.S.
Software Life Cycle “What happens in the ‘life’ of software”
Software Processes.
Model-Driven Analysis Frameworks for Embedded Systems
Tools of Software Development
Introduction to Software Testing
Automated Analysis and Code Generation for Domain-Specific Models
Agenda The current Windows XP and Windows XP Desktop situation
Presentation transcript:

Product Line Engineering CS 415, Software Engineering II Mark Ardis, Rose-Hulman Institute March 11, 2003

2 Acknowledgements David Weiss Lloyd Nakatani Janel Green Bob Olsen Paul Pontrelli

3 Outline 1.What is product line engineering? 2.How did we use product line engineering at Lucent? 3.Why did product line engineering work (at Lucent)?

4 Airbus Beats Boeing in Huge Jetliner Deal with USAir ( 11/6/96 NY Times ) 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. Importance of Commonality –USAir will reduce costs by using one aircraft type –Airbus is reducing its production costs by reusing one aircraft type

5 Airbus Wins $4 Billion Order From Iberia, Beating Boeing ( 2/4/98 NY Times ) Iberia ordered 76 planes: – 9 A319’s, each with capacity for 124 passengers –36 A320’s, each with capacity for 150 passengers –31 A321’s, each with capacity for 185 passengers

6 Airbus Wins $4 Billion Order... “Iberia president said single-aisle Airbus models... though differing in passenger capacity, had identical cockpits and mechanical specifications that offered savings in crew training and maintenance.”

7 Product Line Approach Reorganize the software development process –Evolve a family rather than build single systems –Invest in family infrastructure: Capitalize Develop systematic approach to building flexible application generators

8 Application Environment FAST: Family-oriented Abstraction, Specification, Translation Domain Engineering Application Engineering Applications Feedback

9 Domain Engineering Application Environment Domain Analysis Domain Model Domain Implementation Analysis Document, Application Modeling Language Tools, Process

10 Application Engineering ApplicationApplication Environment Application Requirements

11 Economics of Families Current Practice Number of Family Members Cumulative Cost Domain Engineering

12 Defining a Family: Commonality Analysis Dictionary: Technical vocabulary of the domain Commonalities: Assertions about every member of the family Variabilities: Assertions about variation across the family Consensus process –All domain experts invited to participate –Led by a trained moderator –Real-time editing of the document

13 Application Engineering Environment A language for specifying family members Translators from specification to code Libraries of common code Supporting tools –Simulator –Test case generator –Verifier

14 FAST Benefits Improved Understanding Shorter Intervals Lower Costs (Domain Dependent) Process Innovation Improved Technology

15 Cartoon of the Day

16 How Did We Use Product Line Engineering at Lucent?

17 Eli Whitney Born December 8, 1765 Raised on a farm in rural Massachusetts Attended Yale College What did Whitney do in 1793?

18 The Cotton Gin Whitney invented the cotton gin in 1793 Southern planters refused to pay royalties on patent –The gin was easy to manufacture –Southern legislatures conspired against Whitney

19 Eli Whitney Whitney’s company was out of business by 1797 What did Whitney do in 1798?

20 Flintlock Components

21 Whitney’s Gamble on Automation Whitney offered to make 10,000 muskets in 2 years No other manufacturer had ever made more than a few hundred muskets Automation was needed to improve the efficiency of the locksmiths Whitney invented milling machines to produce interchangeable parts Demonstrated for Congress in 1802

22 Putnam Machine Company, 1875

23 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 for new functionality of lower cost

24 Maintenance Domain Structure Human Machine Interface Diagnostics Hardware Software Interface Maintenance Administrator Fault Detection and Analysis Routine Maintenance Initialization Control Configuration Control

25 Commonality Analysis of Configuration Control 1 staff-year effort over 6 months by 6 experts Produced a Commonality Analysis –Definitions: rational vocabulary –Commonalities: reusable algorithms –Variabilities: relationships between devices –Parameters of Variation: enumerated types Reviewed by organization

26 Building Technology for Configuration Control 2 staff-years effort over 12 months by 3 experts Languages -- capture generic algorithms and parameters Translators -- translate to executable code Interface to legacy system Graphical editor

27 SMALL-D Configuration Control Architecture SMALL-V SMALL-R Domain Engineering Environment Application Engineering Environment VFSM C Data Application RAD

28 Configuration Control Development Environment Application Engineer Domain Engineer Application Specific Configuration Control Reusable Assets Application Data Application Environment Interface RAD C Code Knowledge Base

29 RAD Tool

30 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

31 Applications Project 1 (1994) –re-engineering project to demonstrate feasibility –replaced existing code and demonstrated in lab Project 2 (1996) –shadow project to demonstrate performance –duplicated work of another team and compared results Project 3 ( ) –first real application –reworked domain analysis as work progressed Project 4 (1999) –production use

32 Interval Reduction on 5ESS Projects

33 Measuring Benefits Siy and Mockus studied the effect of domain engineering on the AIM project: –Studied 22,804 MRs involved in 1351 distinct software features over a 7 year period –Found that domain engineered MRs took 1/4 of the time of other MRs –Total savings was $6M - $9M for 1999.

34 Where is Domain Engineering Being Used in Lucent? Switching –Naperville, IL –Boulder, CO –Hilversum, Netherlands –Malmesbury, England –Poland Wireless –Software development processes

35 Why Did Product Line Engineering Work (at Lucent)?

36 Diffusion of Innovations Classic work by Everett M. Rogers (ISBN ) Discovered keys to technology transfer: –Relative advantage How much better is it? –Compatibility Is it consistent with values, experiences, and needs? –Complexity How difficult is it to understand and use? –Trialability How easily may it be tried experimentally? –Observability How visible are the results of use?

37 Technology Transfer at Lucent Estimates are that we only use about 10% of the good ideas developed within Bell Labs Research What’s wrong with the other 90%? –Relative advantage? –Compatibility? –Complexity? –Trialability? –Observability?

38 Oral Culture of 5ESS

39 Problems of Oral Culture No History (Goody and Watt) –Story changes with each telling –Evolution breeds decay No abstraction (Luria) –Insistence on reasoning in terms of ground elements –Refusal to extend arguments to abstractions

40 From Orality to Literacy Write it down Identify abstractions Construct languages Create in the new languages

41 Power of Written Language Generic algorithms of Configuration Control –Translated to flowcharts and English for review –Executed in simulator for further review –Translated to VFSM for execution Commonality Analysis of Configuration Control –Starting point for DECC implementation –Starting point for 4 other designs

42 Diffusion of Domain Engineering Relative advantage: –Solution to the right problem Compatibility: –by the right people Complexity: –using the right tools and methods Trialability: – so that anyone can try it Observability: –and see the results

43 Conclusion Domain engineering reduces interval and cost of software development Resulting products are more consistent and easier to maintain Capturing domain knowledge in written form was the key

44 References Siy and Mockus, "Measuring domain engineering effects on software coding cost", 6th International Symposium on Software Metrics, , November 4-6, Ardis, Dudak, Dor, Leu, Nakatani, Olsen, Pontrelli, "Domain engineered configuration control", Software Product Line Conference, August 28-31, Ardis and Green, "Successful introduction of domain engineering into software development", Bell Labs Technical Journal 3(3), July-September 1998.