Pittsburgh, PA 15213-3890
Evolutionary
Process for
Integrating
COTS-based systems
Lisa Brownsword
Ceci Albert
Sponsored by the U.S. Department of Defense
© 2003 by Carnegie Mellon University
page 1
Why EPIC?
Many projects are not getting the benefits they want from
using COTS products
Marketplace imperatives drive new and modified activities,
new skill sets, additional players, and changed roles and
responsibilities
Organizations need an example to facilitate required
culture changes
© 2003 by Carnegie Mellon University
page 2
Outline
Challenges of Building Systems using COTS Products
Evolutionary Process for Integrating COTS-Based
Systems (EPIC)
© 2003 by Carnegie Mellon University
page 3
Popular COTS Fantasies
COTS products are “plug ‘n play”
We’ll just modify the COTS to fit our business
COTS is “market tested”
COTS will save money
I’ll just use “best of breed”
© 2003 by Carnegie Mellon University
page 4
What is COTS?
A COTS product is one that is …
• Sold, leased, or licensed to the general public
• Offered by a vendor trying to profit from it
• Is supported and evolved by the vendor, who retains
intellectual property rights
• Available in multiple, identical copies
• Used without modification of its internals
© 2003 by Carnegie Mellon University
page 5
What Makes COTS Challenging?
COTS Vendors
Mismatch is likely
• End user and product
processes
• Architectural assumptions
• Enterprise and product
architectures
• Different products
• Versions of products
© 2003 by Carnegie Mellon University
Marketplace is volatile
• Market drivers
• Product features
• Vendor viability
???
COTS
Products
COTS-Based
System
Product visibility is limited
• Technical behavior
• Business implications
page 6
What Makes COTS-Based Systems Challenging?
COTS-based systems come in many forms
• One substantial product (suite) tailored to provide functionality
• Multiple products from multiple suppliers integrated with other
components (legacy, NDI, custom) to collectively provide
functionality
A solution based on COTS products includes
• COTS-based system (composed of tailored COTS products,
other components, integration code)
• end-user business processes
• associated requirements, architecture, cost/schedule/risks
Different COTS products may lead to different solutions
Stability -- and potential obsolescence -- of the solution
must be balanced with marketplace volatility
© 2003 by Carnegie Mellon University
page 7
COTS Spheres of Influence
Use cases
Quality attributes
Business model
Stakeholder Needs
/ Business
Processes
Architecture/
Design
Marketplace
Vendors
Market segments
Available COTS Products
Emerging technology
© 2003 by Carnegie Mellon University
Patterns
Interfaces
Infrastructure
COSTS
Programmatics/
Risk
Risk management
Project management
Change management
License negotiation
page 8
Marketplace Changes the Approach
Traditional Engineering
Approach
Required COTS Approach
Stakeholder Needs/
Business Processes
Requirements
Architecture &
Design
Simultaneous
Marketplace
Definition
Architecture
Design
and Tradeoffs
Implementation
Programmatics/
Risk
Requirements-driven
© 2003 by Carnegie Mellon University
Negotiation-driven
page 9
Key Aspects of COTS Approach
Simultaneous definition and tradeoffs among four spheres
– from project initiation until system retired
• Business process engineering is fully integrated
• Requirements are fluid and formed through discovery
• Flexible system architecture is developed early and maintained
• Marketplace is monitored continuously
• Cost, schedule, and risk for implementing the system and any
required business process changes is integral to all trades
Continuous negotiation among stakeholders
Disciplined spiral or iterative practices with frequent executable
representations of the evolving system
© 2003 by Carnegie Mellon University
page 10
Outline
Challenges of Building Systems using COTS Products
Evolutionary Process for Integrating COTS-Based
Systems (EPIC)
© 2003 by Carnegie Mellon University
page 11
What is EPIC?
A disciplined, negotiation-driven spiral approach
• Addresses the aspects of defining, building, fielding, and
supporting COTS-based solutions
• Describes objectives, activities, and artifacts with sufficient
detail to facilitate needed culture change
Operationalizes COTS lessons learned and software
engineering best practice
• Concurrent definition of artifacts
• Frequent executable representations
• Risk drives project planning and engineering activities
© 2003 by Carnegie Mellon University
page 12
EPIC Conceptual Framework
Stakeholder Needs/
Business Processes
Marketplace
Simultaneous Architecture/
Definition
Design
and Tradeoffs
Programmatics/
Risk
Trade Space
•
•
•
•
Decisions
Converge
Trade Space
Time
Trades are negotiation-driven with knowledge of marketplace
Requirements formed based on knowledge of market/architecture
Continuous awareness of end-user business processes changes
Project business and contractual approaches support trades
© 2003 by Carnegie Mellon University
page 13
Knowledge Grows Incrementally
Time
Executable
• Risk-based spiral development
focuses and integrates diverse information
-
Prioritized stakeholder needs, end-user processes
Organization and system architecture, design constraints
Identified risks, programmatic constraints
Marketplace offerings, product characteristics, other buyer
usage
• Frequent, evolving executable representations demonstrate
current understanding
© 2003 by Carnegie Mellon University
page 14
Continuous Stakeholder Negotiation
• Stakeholder needs mature with increased understanding of
marketplace implications
• Business processes change to leverage available products
• End users committed to system solution
• Quick resolution to discovered mismatches
-
Business process owners and end users
System engineers and developers
Vendors and suppliers
Project managers
Change agents
Stakeholder Buy-in Increases
Time
© 2003 by Carnegie Mellon University
page 15
Spiral Development – at a Glance
Continuous discovery, invention, and implementation
approach for an increment of capability
• Many iterations are executed to deliver an increment
• Each iteration forces the development team to drive the
increment’s artifacts to closure in a predictable and
repeatable way
• High-priority risks drive objectives for each iteration
Successive increments replace or build upon previously
delivered increments
© 2003 by Carnegie Mellon University
page 16
Iterations Redefined for COTS*
Gather
information
Simultaneous
Definition
and Tradeoffs
Plan iteration
(1 to 8 weeks
per outer cycle)
by identifying and
analyzing
mismatches and
negotiating among
stakeholders
Refine into
harmonized set
Assess iteration
Assemble executable
representation
Executable
*adapted from A/APCS; SEI CBS Initiative
© 2003 by Carnegie Mellon University
page 17
Phases Bounded by Anchor Points
Inception
Elaboration
Construction
Gather and define
project scope
Refine, experiment
& select solution
Implement selected
solution
Field and support
solution
Survey/try COTS
Try/select COTS
Apply/track COTS
Track/update COTS
Agree to business
process changes
Prototype business
process changes
Prepare to change
business process
Change business
process
Gatherinformation
Stakeholder needs/
BusinessProcesses
Marketplace
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Programmatics/
Risk
Planiteration
Refineinto
harmonizedset
Assembleexecutable
…
Planiteration
Gatherinformation
Stakeholder needs/
BusinessProcesses
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Marketplace
Programmatics/
Risk
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Programmatics/
Risk
Refineinto
harmonizedset
Assembleexecutable
Executable
Assessiteration
Gatherinformation
Stakeholder needs/
BusinessProcesses
Marketplace
Planiteration
Refineinto
harmonizedset
Assembleexecutable
Executable
Assessiteration
…
Gatherinformation
Stakeholder needs/
BusinessProcesses
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Marketplace
Programmatics/
Risk
Planiteration
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Programmatics/
Risk
Refineinto
harmonizedset
Assembleexecutable
Executable
Assessiteration
Gatherinformation
Stakeholder needs/
BusinessProcesses
Marketplace
Planiteration
Refineinto
harmonizedset
Assembleexecutable
Executable
Assessiteration
…
Transition
Gatherinformation
Gatherinformation
Stakeholder needs/
BusinessProcesses
Marketplace
Stakeholder needs/
BusinessProcesses
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Programmatics/
Risk
Planiteration
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Programmatics/
Risk
Refineinto
harmonizedset
Assembleexecutable
Executable
Assessiteration
Marketplace
Planiteration
Refineinto
harmonizedset
Assembleexecutable
Executable
Assessiteration
…
Gatherinformation
Stakeholder needs/
BusinessProcesses
Marketplace
Planiteration
© 2003 by Carnegie Mellon University
LifeCycle
Architecture
Refineinto
harmonizedset
Assembleexecutable
Executable
Executable
Assessiteration
Assessiteration
6 to 18 months
LifeCycle
Objectives
Simultaneous
itecture/•
Definition Arch
Design
andTradeoffs
Programmatics/
Risk
Initial Operational
Capability
page 18
EPIC: A Negotiation-Driven Approach
Accumulate knowledge
through risk-based spirals
Solution Alternatives
Stakeholder needs
Business processes
Simultaneous
Marketplace
Definition
and Tradeoffs
Drive strategic
vision to
Architecture
Design
sustainable
solution
Programmatics
Risk
Increase stakeholder buy-in and
reconcile business processes with
COTS-based system
Time
Coordinates operational change, system and software
engineering, and program management activities
© 2003 by Carnegie Mellon University
page 19
Change Happens …
Most software systems change before they are fully
implemented
•
•
•
•
•
•
Enterprise priorities shift
Business or operational needs change
New technologies introduce new opportunities
COTS products add and delete key features
Participants rotate
Etc.
Each increment should be small enough to minimize the
impact of change (6-18months)
Each increment must be defined in the context of an agreed
upon system vision
• Going after low hanging fruit in the absence of an overarching
architecture and coherent plan results in incompatible and stove
piped solutions
© 2003 by Carnegie Mellon University
page 20
Managing Successive Increments
System level
Scope
Design
• Business
model
• Scope
• Constraints
• Market study
Scope
• Critical use cases at
system level (what)
• Architecture (how)
• Available and
projected technology
LCO
…
Design
• Business
model
• Scope
• Constraints
• Market study
• Critical use cases at
system level (what)
• Architecture (how)
• Available and
projected technology
LCO
LCA
LCA
Increment #1
Scope
Design
LCO
Build
LCA
Field
IOC
6-18 months
© 2003 by Carnegie Mellon University
page 21
The Bottom Line
Challenges of Building Systems using COTS Products
• Vendors control product evolution
• Forces of the marketplace drive COTS product tempo and
content
Implications for Development and Maintenance Processes
• “Doing COTS” is different from custom development
• Traditional requirements-driven processes don’t work
Evolutionary Process for Integrating COTS-Based Systems
(EPIC)
• A negotiation-driven process that helps identify and manage the
differences between what users want and what COTS products
can deliver
• Commercial and government EPIC pilots underway
© 2003 by Carnegie Mellon University
page 22
References
EPIC
• Overview: CMU/SEI-2002-TR-009 (July 2002)
• Detailed: CMU/SEI-2002-TR-005 (November 2002)
COTS issues
• Office of the Secretary of Defense, Commercial Item Acquisition:
Considerations and Lessons Learned.
http://www.acq.osd.mil/ar/doc/cotsreport.PDF (26 June 2000)
• Boehm, B. & Abts, C. “COTS Integration: Plug and Pray?” IEEE Computer,
32, 1 (January 1999)
• Brownsword, L.; Carney, D.; & Oberndorf, P. “The Opportunities and
Complexities of Applying COTS Components.” Crosstalk, 11, 4 (April 1998)
http://www.stsc.hill.af.mil/crosstalk/1998/apr/applying.asp
• Carney, D.; Hissam, S.; & Plakosh, D. “Complex COTS-based Software
Systems: Practical Steps for their Maintenance.” Journal of Software
Maintenance: Research and Practice, 12, 6 (2000)
Spiral development
• Boehm, B. “Anchoring the Software Process.” IEEE Software, (July 1996)
• Kruchten, Phillippe. The Rational Unified Process: An Introduction, 2nd ed.
New York, NY: Addison-Wesley Object Technology Series, March 2000
© 2003 by Carnegie Mellon University
page 23
Additional Information
www.sei.cmu.edu/cbs
www.sei.cmu.edu/cbs/epicprod.htm
Lisa Brownsword
[email protected]
© 2003 by Carnegie Mellon University
Ceci Albert
[email protected]
page 24