more on software architecture and product...
TRANSCRIPT
More on Software Architectureand Product Lines
SEI Update
More on Software ArchitectureMore on Software Architectureand Product Linesand Product Lines
SEI UpdateSEI Update
GSAW 2000
Linda M. NorthropDirector, Product Line Systems Program
Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213
This work is sponsored by the U.S. Department of Defense.
GSAW 2000
Linda M. NorthropDirector, Product Line Systems Program
Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213
This work is sponsored by the U.S. Department of Defense.
© 2000 by Carnegie Mellon University 2
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Today’s Talk
© 2000 by Carnegie Mellon University 3
What Is a Product Line?A product line is a group of products sharinga common, managed set of features that satisfy specificneeds of a selected market.
Market strategy/ Application domain
pertain to
Products
© 2000 by Carnegie Mellon University 7
Software Product Lines
Market strategy/ Application domain
Architecture
Components
pertain to
share an
are built from
is satisfied by
used to structureProductsCORE
ASSETS
Product lines• take economic advantage of commonality• bound variability
Product lines• take economic advantage of commonality• bound variability
© 2000 by Carnegie Mellon University 8
How Do Product Lines Help?
Product lines amortize the investment in theseand other core assets:• requirements and requirements analysis•domain model•software architecture and design•performance engineering•documentation• test plans, test cases, and data•people: their knowledge and skills•processes, methods, and tools•budgets, schedules, and work plans•components
product lines = strategic reuse
earlier life-cyclereuse
more benefit
© 2000 by Carnegie Mellon University 9
The Key Concepts
Use of acommonasset base
inproduction
of a relatedset ofproducts
© 2000 by Carnegie Mellon University 10
The Key ConceptsUse of acommonasset base
inproduction
of a relatedset ofproducts
ArchitectureArchitectureProduction PlanProduction Plan
Scope DefinitionBusiness Case
Scope DefinitionBusiness Case
© 2000 by Carnegie Mellon University 11
Customers/CollaboratorsCaterpillar
Robert Bosch Co.Hewlett Packard
LLNLEPAFAA
USCGNRO/CCT
JNTFDMSO
US Army SOA: TAPOUS Army CECOM
US Navy TENAUS Airforce: F-22
NASA
CaterpillarCaterpillarRobert Bosch Co.Robert Bosch Co.
Hewlett PackardHewlett PackardLLNLLLNLEPAEPAFAAFAA
USCGUSCGNRO/CCTNRO/CCT
JNTFJNTFDMSODMSO
US Army SOA: TAPOUS Army SOA: TAPOUS Army CECOMUS Army CECOM
US Navy TENAUS Navy TENAUS Airforce: F-22US Airforce: F-22
NASANASA
LucentAT&TThomson-CSFEricssonRaytheonSiemensSchlumbergerCummins Engine Co.NokiaTelesoft S.p.ABoeingCelsiusTechBuzzeoALLTELMotorolaGeneral Motors
LucentLucentAT&TAT&TThomson-CSFThomson-CSFEricssonEricssonRaytheonRaytheonSiemensSiemensSchlumbergerSchlumbergerCummins Engine Co.Cummins Engine Co.NokiaNokiaTelesoft S.p.ATelesoft S.p.ABoeingBoeingCelsiusTechCelsiusTechBuzzeoBuzzeoALLTELALLTELMotorolaMotorolaGeneral MotorsGeneral Motors
© 2000 by Carnegie Mellon University 12
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Today’s Talk
© 2000 by Carnegie Mellon University 13
Necessary Changes
OrganizationalOrganizationalstructure andstructure and
personnelpersonnel
ManagementManagement
BusinessBusinessapproachapproach
ArchitectureArchitecture
DevelopmentDevelopmentapproachapproach
The architecture is the foundation of everything.
© 2000 by Carnegie Mellon University 14
Risks and Mitigation Strategies
Poor quality architecture is among the top ten risksassociated with software product lines.
To mitigate the risk, care must be taken duringarchitecture definition and evaluation.
Our architecture work has therefore focused on:• Architecture-Based Design• Architecture Analysis: Architecture Tradeoff Analysis MethodSM (ATAM)• Analyzable Designs: Attribute-based Architectural Styles (ABAS)
Poor quality architecture is among the top ten risksassociated with software product lines.
To mitigate the risk, care must be taken duringarchitecture definition and evaluation.
Our architecture work has therefore focused on:• Architecture-Based Design• Architecture Analysis: Architecture Tradeoff Analysis MethodSM (ATAM)• Analyzable Designs: Attribute-based Architectural Styles (ABAS)
© 2000 by Carnegie Mellon University 15
Architecture-Based Design
A refinement method designed to organize the earliestdesign decisions
© 2000 by Carnegie Mellon University 16
Architecture DesignConsiderationsVariabilities and Commonalities• use cases with variation points and
quality scenarios
Software Templates• categorize design elements into types
Architectural Drivers• combination of functional and quality
requirements that drive the design
Variabilities and Commonalities• use cases with variation points and
quality scenarios
Software Templates• categorize design elements into types
Architectural Drivers• combination of functional and quality
requirements that drive the design
© 2000 by Carnegie Mellon University 17
ABD Method Within the LifeCycle
ABD MethodABD Method
Requirements AnalysisRequirements AnalysisBusiness Case
Architect’s Experience
Legacy Systems
Functional Requirements - abstract - use casesQuality Requirements - abstract
- quality scenarios- architecture options
Constraints
ConcreteConcreteComponentComponent
DesignDesign
Abstract ComponentsSoftware TemplatesConstraintsRequirements
© 2000 by Carnegie Mellon University 18
Engineering Quality Attributes
We need to identify and analyze risks at the stage ofarchitecture design.
To do this we need suitable architecture analysistechniques.
And we need analyzable designs.
How do we get these?
© 2000 by Carnegie Mellon University 19
SEI’s Architecture TradeoffAnalysis MethodSM (ATAMSM)ATAM is an architecture evaluation method that• focuses on multiple quality attributes
• illuminates points in the architecture where qualityattribute tradeoffs occur
• generates a context for ongoing quantitativeanalysis
• utilizes an architecture’s vested stakeholders asauthorities on the quality attribute goals
© 2000 by Carnegie Mellon University 20
The ATAM
We have been developing the Architecture TradeoffAnalysis Method (ATAM) for over two years.
The purpose of ATAM is: to assess the consequences ofarchitectural decision alternatives in light of qualityattribute requirements.
We have been developing the Architecture TradeoffAnalysis Method (ATAM) for over two years.
The purpose of ATAM is: to assess the consequences ofarchitectural decision alternatives in light of qualityattribute requirements.
© 2000 by Carnegie Mellon University 21
ATAM Steps1. Present ATAM2. Present business drivers3. Present architecture4. Identify architectural styles5. Generate quality attribute utility tree6. Elicit and analyze architectural styles7. Generate seed scenarios8. Brainstorm and prioritize scenarios9. Map scenarios onto styles10. Present out-brief and/or write report
ATAM Steps
© 2000 by Carnegie Mellon University 22
ATAM Techniques
• Utility Tree Generation
• Style-Based Elicitation/Analysis
• Scenario Brainstorming/Mapping
© 2000 by Carnegie Mellon University 23
Building Upon Styles andDesign Patterns: ABASs
Architectural styles and design patterns are awonderful (and necessary) idea.
They describe the essence of a recurring designproblem and its solution.
Attribute-based architectural styles (ABASs) addexplicit quality attribute analysis models to reasonabout the costs/benefits of a pattern or style.
Architectural styles and design patterns are awonderful (and necessary) idea.
They describe the essence of a recurring designproblem and its solution.
Attribute-based architectural styles (ABASs) addexplicit quality attribute analysis models to reasonabout the costs/benefits of a pattern or style.
© 2000 by Carnegie Mellon University 24
ABAS Motivation
Why add a quality attribute-basedmodeling framework to anarchitectural style?• to make architectural design more routine
and predictable• to have a standard set of important
attribute-based analysis questionsassociated with the style
• to tighten the link between design andanalysis
© 2000 by Carnegie Mellon University 25
Analysis Models
For each attribute, the characterization describes:• the stimuli of interest• the architectural style (and its parameters)• the responses
To aid in structuring an ABAS and in understandingeach attribute, we are using attribute characterizations.
StimuliStimuli Architectural StyleArchitectural Style ResponsesResponses
© 2000 by Carnegie Mellon University 26
Parts of an ABAS
1. Problem Description and Criteria: characteristics ofthe problem solved.
2. Stimuli/Responses: the ABAS’s quality attributespecific stimuli and the measures of the responses.
3. Architectural Style: components, connectors,parameters, topology, constraints.
4. Analysis: formally relating quality attribute models tothe style; heuristics for reasoning about the style.
© 2000 by Carnegie Mellon University 27
ABAS Support
We are building a handbook with a collection of ABASs
AnalysisAnalysis DesignDesign
© 2000 by Carnegie Mellon University 28
Example Handbook Contents
Performance:• Concurrent Pipelines• Multiple Messages• Synchronization• Cache• Client/Server
Modifiability:• Abstract Data Repository• Layers• Publish/Subscribe• Data Indirection
Availability:• Analytic Redundancy• Simplex• Trimodular Redundancy
Security:• Firewall• Virtual Private Network• Encryption/Decryption
Usability:• Undo• Cancel• Visualization
© 2000 by Carnegie Mellon University 29
ConnectionsConnections
ABAS Quality Attribute Workshop
ATAM
ABD
Architecture
SoftwareProduct
Lines
Component quality (CBE)
Component Assembly Plan(CBE)
productionplan
© 2000 by Carnegie Mellon University 30
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Today’s Talk
© 2000 by Carnegie Mellon University 31
Trends Supporting Product LinesProliferation within major organizations of self-sustainingarchitecture centers.
Growing acceptance of the importance of architecture.
Standardization of commercial middleware.
Growing popularity of the notion of "rapid development."
Community acceptance of well-defined processes forsoftware development.
Growing acceptance in the software engineeringcommunity of the importance of product line practicesand the rising recognition of the amazingcost/performance savings that are possible.
© 2000 by Carnegie Mellon University 32
Benefits
Improved productivity by as much as 10x
Decreased time to market (to field, to launch...) by as much as an order of magnitude
Decreased cost by as much as 60%
Increased quality as measured by customer satisfaction
© 2000 by Carnegie Mellon University 33
PervasivenessFirst Software Product Line ConferencePaper Submissions
North America 25Europe 25Asia 7So America/So Africa 2
Academic 27Industry 32 * of these, 10 from DoD community
Research 19Experience 18Either/both 12
© 2000 by Carnegie Mellon University 34
Some DoD Options
Scope the product line and develop thearchitecture
Acquire a product line architecture
Acquire the core asset base
Acquire a product built using product line technology
Acquire a product and some set of reusable assets
Acquire products built from a government asset base
Acquire an entire product line
Acquire products built from a non-government asset base
Scope the product line and develop thearchitecture
Acquire a product line architecture
Acquire the core asset base
Acquire a product built using product line technology
Acquire a product and some set of reusable assets
Acquire products built from a government asset base
Acquire an entire product line
Acquire products built from a non-government asset base
© 2000 by Carnegie Mellon University 35
DoD Strategy
Domain Understanding
DoD Options
Product Line Goals
Scope DefinitionScope Definition
Business CaseBusiness Case
© 2000 by Carnegie Mellon University 36
DoD Response
30 from the DoD community participated in SEISecond DoD Product Line Practice Workshop(March 1999).• They talked about how they were doing or going to do
product lines, not how it would be impossible in theDoD.
The current Defense Science Board Task Forceis recommending product lines.
© 2000 by Carnegie Mellon University 37
Impact - NRO CCT
CCTCCT
DCCSDCCS
MALTAMALTA
ECLIPSEECLIPSE
SOTGSOTG
??
© 2000 by Carnegie Mellon University 38
Impact - Robert Bosch
Bosch is a majorparticipant inESAPS
Glass DashboardR&DEffort
Glass DashboardR&DEffort
New BoschResearch Centerin Pittsburgh
Two dashboardprototypes
New dashboardbusiness unit
Corporate DomainEngineering Team
Product Lines are oneof three goals of
new Bosch Initiative inSoftware Systems (BISS)
© 2000 by Carnegie Mellon University 39
SEI Product Line Practice Framework
Web-based, evolving document
Describes product line essentialactivities
Describes essential and proven productline practices in the areas of• software engineering• technical management• organizational management
Addresses development and acquisition contexts
© 2000 by Carnegie Mellon University 40
Current Status of FrameworkVersion 2.0 is now on our Web Site
http://www.sei.cmu.edu/plp/framework.html
Version 2.0 differs from Version 1.04modified list of practice areas4added nine additional practice area descriptions4improved acquisition context coverage4improved the six practice area descriptions in
V1.04included an FAQ section
Currently known to be used by 20 organizations intheir product line efforts
© 2000 by Carnegie Mellon University 41
Product Line Essential Activities
Domain Engineering Application Engineering
ManagementManagementManagement
ProductDevelopment/ Acquisition
ProductProductDevelopmentDevelopment/ Acquisition/ Acquisition
Core AssetDevelopment /
Acquisition
Core AssetCore AssetDevelopment /Development /
AcquisitionAcquisition
Product Line Development / Acquisition ProcessProduct Line Development / Acquisition ProcessProduct Line Development / Acquisition Process
© 2000 by Carnegie Mellon University 42
Practice Area Categories
SOFTWARE ENGINEERING
TECHNICAL MANAGEMENT
ORGANIZATIONAL MANAGEMENT
SOFTWARE ENGINEERING
TECHNICAL MANAGEMENT
ORGANIZATIONAL MANAGEMENT
© 2000 by Carnegie Mellon University 43
Software EngineeringPractice Areas
Understanding Relevant Domains
Mining Existing Assets
Architecture Definition
Architecture Evaluation
Component Development
Testing
Requirements Engineering
COTS Utilization
Software System Integration
0
00
f in Version 1.0
0 in Version 2.0
f f
f
0
© 2000 by Carnegie Mellon University 44
Technical ManagementPractice Areasf Data Collection, Metrics and Trackingf Product Line Scoping
Configuration ManagementProcess ModelingPlanningMake/Buy/Mine/Outsource AnalysisTechnical Risk ManagementTool Support
f in Version 1.0
0 in Version 2.0
0
0
© 2000 by Carnegie Mellon University 45
Organizational ManagementPractice Areas
Achieving the Right Organizational Structure Building and Communicating a Business Case
Funding
Market Analysis
Developing and Implementing an Acquisition Strategy
Operations
Training Customer Interface Management
Technology Forecasting
Launching and Institutionalizing a Product Line
Organizational Risk Management
f
f in Version 1.0
0 in Version 2.0
00
0
0
© 2000 by Carnegie Mellon University 46
Key Themes Among SuccessfulProduct Lines
Long and deep domain experience
A legacy base from which to build
Architectural excellence
Management commitment
© 2000 by Carnegie Mellon University 47
Remarks
The SEI framework for software product linepractice is intended to be a living document.
Version 2.0 is the second iteration.
Future versions will incorporate• Additional practice area descriptions• Usage scenarios• Practice area dependency descriptions
The SEI conducts product line technical probesbased upon the framework to examine whether anorganization is “fit for product lines.”
© 2000 by Carnegie Mellon University 48
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Context (again!)
Software Architecture• ABD• ATAMSM
• ABAS
Product Lines• Supporting Trends• Benefits• Pervasiveness• DoD Response• Impact• SEI Product Line Practice Framework
Conclusion
Today’s Talk
© 2000 by Carnegie Mellon University 49
Conclusion
There has been much technological and experientialprogress in the last year both in software architecture andsoftware product lines.
The time is right to make software product lines a DoDreality.
Join us at:• Third DoD Product Line Practice Workshop (March 13-14, 2000)• SPLC1 (August 28-31, 2000)
to push the frontier further.
© 2000 by Carnegie Mellon University 50
For Additional Information Telephone 412 / 268-7638
FAX 412 / 268-5758
Email [email protected]
World Wide Web http://www.sei.cmu.edu/plp http://www.sei.cmu.edu/ata
U.S. mail Linda M. NorthropSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890