We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byMagnus Grant
Modified about 1 year ago
Sponsored by the U.S. Department of Defense © 2003 by Carnegie Mellon University page 1 Pittsburgh, PA 15213-3890 Evolutionary Process for Integrating COTS-based systems Lisa Brownsword Ceci Albert
© 2003 by Carnegie Mellon University page 2 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 3 Outline Challenges of Building Systems using COTS Products Evolutionary Process for Integrating COTS-Based Systems (EPIC)
© 2003 by Carnegie Mellon University page 4 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 5 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 6 What Makes COTS Challenging? Marketplace is volatile Market drivers Product features Vendor viability Mismatch is likely End user and product processes Architectural assumptions Enterprise and product architectures Different products Versions of products COTS Products COTS-Based System ??? COTS Vendors Product visibility is limited Technical behavior Business implications
© 2003 by Carnegie Mellon University page 7 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 8 COTS Spheres of Influence Vendors Market segments Available COTS Products Emerging technology Use cases Quality attributes Business model Patterns Interfaces Infrastructure Risk management Project management Change management License negotiation
© 2003 by Carnegie Mellon University page 9 Marketplace Changes the Approach Traditional Engineering Approach Requirements Architecture & Design Implementation Requirements-driven Required COTS Approach Negotiation-driven Simultaneous Definition and Tradeoffs Marketplace Stakeholder Needs/ Business Processes Architecture Design Programmatics/ Risk
© 2003 by Carnegie Mellon University page 10 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 11 Outline Challenges of Building Systems using COTS Products Evolutionary Process for Integrating COTS-Based Systems (EPIC)
© 2003 by Carnegie Mellon University page 12 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 13 EPIC Conceptual Framework Time Trade Space Simultaneous Definition and Tradeoffs Marketplace Stakeholder Needs/ Business Processes Architecture/ Design Programmatics/ Risk 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 Trade Space Decisions Converge
© 2003 by Carnegie Mellon University page 14 Knowledge Grows Incrementally 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 Executable Time
© 2003 by Carnegie Mellon University page 15 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 Time Stakeholder Buy-in Increases
© 2003 by Carnegie Mellon University page 16 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 17 Iterations Redefined for COTS* Assess iteration Gather information Simultaneous Definition and Tradeoffs *adapted from A/APCS; SEI CBS Initiative (1 to 8 weeks per outer cycle) Plan iteration Assemble executable representation Executable Refine into harmonized set by identifying and analyzing mismatches and negotiating among stakeholders
© 2003 by Carnegie Mellon University page 18 Phases Bounded by Anchor Points LifeCycle Architecture Initial Operational Capability ElaborationConstructionTransition Refine, experiment & select solution Try/select COTS Prototype business process changes Implement selected solution Apply/track COTS Prepare to change business process Field and support solution Track/update COTS Change business process ……… LifeCycle Objectives Inception Gather and define project scope Survey/try COTS Agree to business process changes … 6 to 18 months
© 2003 by Carnegie Mellon University page 19 EPIC: A Negotiation-Driven Approach Drive strategic vision to sustainable solution Increase stakeholder buy-in and reconcile business processes with COTS-based system Accumulate knowledge through risk-based spirals Coordinates operational change, system and software engineering, and program management activities
© 2003 by Carnegie Mellon University page 20 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 21 Managing Successive Increments System level ScopeDesign Business model Scope Constraints Market study Critical use cases at system level (what) Architecture (how) Available and projected technology LCO LCA ScopeDesign Business model Scope Constraints Market study Critical use cases at system level (what) Architecture (how) Available and projected technology LCO LCA … ScopeDesign BuildField Increment #1 LCOLCAIOC 6-18 months
© 2003 by Carnegie Mellon University page 22 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 23 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) http://www.acq.osd.mil/ar/doc/cotsreport.PDF 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 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, 2 nd ed. New York, NY: Addison-Wesley Object Technology Series, March 2000
© 2003 by Carnegie Mellon University page 24 Additional Information Ceci Albert firstname.lastname@example.org Lisa Brownsword email@example.com www.sei.cmu.edu/cbs www.sei.cmu.edu/cbs/epicprod.htm
© 2003 by Carnegie Mellon University page 1 Processes for COTS-Based Systems LA SPIN 3 September 2003 Software Engineering Institute Carnegie Mellon University.
© 2003 by Carnegie Mellon University page 1 Process Principles for COTS-Based Systems 5 September 2003 Software Engineering Institute Carnegie Mellon University.
Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 2001 by Carnegie Mellon.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome Introductions What is your experience with RUP What is.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
Software Acquisition Management SAM-450 EXEC SAM (1) COTS-Based Systems* SAM Executive Seminar George Prosnik DAU CDSC E&T Center * Derived from the SEI’s.
Systems Engineering in a System of Systems Context
CSE 470 : Software Engineering The Software Process.
Software Engineering Management Lecture 1 The Software Process.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
1 Project Management Introduction. 2 Chap 1 What is the impact? 1994: 16% of IT projects completed “On-Time” 2004 : 29% of IT projects “On- Time” 53%
Chapter 2 The process Process, Methods, and Tools
Iterative development and The Unified process
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Software Project Management
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
CS 360 Lecture 3. The software process is a structured set of activities required to develop a software system. Fundamental Assumption: Good software.
Using IBM Rational Unified Process for software maintenance
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Lecture # 2 : Process Models
Object-oriented Analysis and Design
CMMI Course Summary CMMI course Module 9..
Certified Business Process Professional (CBPP®) Exam Overview
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
CPSC 871 John D. McGregor Module 6 Session 3 System of Systems.
MODEL-BASED SOFTWARE ARCHITECTURES. Models of software are used in an increasing number of projects to handle the complexity of application domains.
Rational Unified Process Fundamentals Module 5: Implementing RUP.
Cost and Management Challenges of Systems of Systems True Program Success TM Cost and Management Challenges of System of Systems Arlene Minkiewicz, Chief.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 2 : The Project Management and Information Technology Context Information Technology Project Management, Fourth Edition.
2004 by SEC Chapter 2 Software Development Process Models.
Systems Architectures System Integration & Architecture.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Rational Unified Process Fundamentals Module 3: Disciplines I.
THE PROTOTYPING MODEL The prototyping model begins with requirements gathering. Developer and customer meet and define the overall objectives for the software.
PRJ270: Essentials of Rational Unified Process
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Unified Software Practices v 5.0-D Copyright 1998 Rational Software, all rights reserved 1 /26 Rational Unified Process – Part 2 Original slides modified.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Prescriptive Process models
© 2017 SlidePlayer.com Inc. All rights reserved.