1. University of Southern California Center for Systems and Software Engineering Barry Boehm, Jo Ann Lane Incremental Commitment Spiral Model: Phases and Stages Common Cases

2. University of Southern California Center for Systems and Software Engineering Part II Outline ICSM Stages and Phases ICSM Common Cases Medical First Responder System (MedFRS) example Copyright © USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Process: Phased View Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process 3Copyright © USC-CSSE

4. University of Southern California Center for Systems and Software Engineering ICSM Stages and Phases Stage I: System definition –Exploration Phase Concurrently identifies and clarifies –System capability needs –System constraints –Candidate solution options for providing the capabilities –Valuation Phase Analyzes alternative solutions and identifies preferred alternative –Foundations Phase Develops management and technical foundations for the selected alternative Stage II: Incremental development –Development Phase Procurement, iterative detailed design and development, integration, and test of current-increment components –Production and Operations Phase System “units” produced/integrated and put into operations Copyright © USC-CSSE4

5. University of Southern California Center for Systems and Software Engineering What the ICSM Book Has to Say About Each Phase What it is Questions to guide phase activities Potential pitfalls during phase Major risks to watch for How phase scales from small to large/complex Role of principles in phase MedFRS example activities and decisions Copyright © USC-CSSE5

6. University of Southern California Center for Systems and Software Engineering Questions To Guide Phase Activities Engineering technical activities “ility” trades Aspects of potential pitfalls and risks Feasibility evidence Potential cost/schedule issues Stakeholders Copyright © USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering Questions To Guide Phase Activities: Examples Exploration –What is the real need? –Who wants it and why? Valuation –Will less extreme performance/capability suffice? –If so, what are the various levels of acceptability? Foundations –What is the status of desired innovations or new technologies? –Have they been sufficiently matured, or should alternatives be considered? Copyright © USC-CSSE7

8. University of Southern California Center for Systems and Software Engineering Questions To Guide Phase Activities: Examples (continued) Development: –Hardware: What are the size, weight, power, etc. constraints for hardware components? Who is responsible for embedded FPGA code? –Software: What are contingency plans for reusable software that is found not to be as reusable as initially planned? –Integration: If recent COTS software upgrades have not yet been incorporated, should they be incorporated or is there risk of destabilizing the system? Production and operations: –What manufacturing is required for the new release? –When will spares be produced? –What user training is required? –What Help Desk training is required? Copyright © USC-CSSE8

9. University of Southern California Center for Systems and Software Engineering ICSM as Risk-Driven Process Generator Stage I of the ICSM has 3 decision nodes with 4 options/node –Culminating with incremental development in Stage II –Some options involve go-backs –Results in many possible process paths Can use ICSM risk patterns to generate frequently- used processes –With confidence that they fit the situation Can generally determine this in the Exploration phase –Develop as proposed plan with risk-based evidence at VCR milestone –Adjustable in later phases 9Copyright © USC-CSSE

10. University of Southern California Center for Systems and Software Engineering Proposal/white paper explaining need and context for need Inputs Clarify and assess need/potential benefits Conduct gap analysis against existing capabilities Develop initial concept description Identify potentially feasible alternatives for further analysis Capture risks and develop mitigation plans Activities Initial concept description Business case for need List of feasible alternatives for further analysis Key risks and mitigation plans Guidelines/needed budget for further analysis Outputs Entry Criteria Identified need Proponent(s) for need Budget for exploration activities Exit Criteria Decision to provide resources to conduct further evaluation of potential alternatives or decision to discontinue Exploration Copyright © USC-CSSE10

11. University of Southern California Center for Systems and Software Engineering Guidelines identified in Exploration phase Initial concept description Business case for need List of potentially feasible alternatives for further analysis Risk list and mitigation plans Inputs Refine and implement valuation plan developed in Exploration phase Monitor changes in needs/opportunities/ risks Adapt plans to address identified changes Evaluate results of valuation activities Develop foundations strategy and plans Update risks and risk mitigation plans Activities Analysis of any prototypes Updated risks and mitigation plans Approved Foundations strategy plan Key stakeholder commitments/ MOAs Outputs Entry Criteria Decision to conduct further evaluation of potential alternatives Budget for Valuation activities Exit Criteria Decision to provide resources to proceed to Foundations Phase or decision to discontinue Valuation Copyright © USC-CSSE11

12. University of Southern California Center for Systems and Software Engineering Analysis/results of any Valuation prototypes Key risks and mitigation plans Approved Foundations strategy plan Key stakeholder commitments/ MOAs Inputs Ensure technology readiness for needed capabilities Monitor changes in needs/opportunities/ risks Prototype and evaluate various alternatives Select acquisition/ development strategies Prioritize features/ requirements for development Develop plan for development based upon prioritization Update risks and risk mitigation plans Activities List of approved features/requirements allocated to components or configuration items Approved Development plan Feature allocation to increments Updated risks and mitigation plans Updated stakeholder commitments/ MOAs Requests for proposals for outsourced development Outputs Entry Criteria Decision to develop necessary foundations Budget for Foundations activities Exit Criteria Decision to provide resources to proceed to Development Phase or decision to discontinue Foundations Copyright © USC-CSSE12

13. University of Southern California Center for Systems and Software Engineering List of approved features/requirements Problems reported against currently deployed system Approved changes Approved Development plan Feature allocation to increments Updated risks and mitigation plans Updated stakeholder commitments/ MOAs Proposals for outsourced development Inputs Initial increment: Set up development environments Develop detailed design Select hardware, COTS products, and outsource vendors Update Foundations as needed based on selections All increments (in accordance with plan) Update detailed design Procure/develop/integrate hardware components Develop/procure/integrate software features/requirements according to development plan Monitor changes in needs/opportunities/ risks Update Foundations as needed Conduct continuous V&V Update approved features, risks, and mitigations at end of each increment Activities System ready for production/deploym ent Outputs Entry Criteria Decision to develop increment Budget for increment Development activities Exit Criteria Decision to either proceed with production/operations or discontinue Development Copyright © USC-CSSE13

14. University of Southern California Center for Systems and Software Engineering Approved production plans Inputs Acquire/establish production or manufacturing facilities and resources Produce system units in accordance with approved production plans/orders Develop maintenance strategies and plans for system Produce user information / training materials Produce help desk support materials Activities System units ready for operations User information/training materials Help desk materials and training Maintenance and logistics plans Outputs Entry Criteria Production budget Exit Criteria Production for current system version complete Production Copyright © USC-CSSE14

15. University of Southern California Center for Systems and Software Engineering Approved operations and support plans System updates Help desk updates Inputs Distribute and support system units and components in accordance with approved plans Distribute and support approved system changes in accordance with approved plans Operate system help desk and provide user assistance as requested Triage user problem reports and change requests and forward to Development as needed Activities Support: Problem reports to be resolved Change requests for implementation consideration End of life: Authorization to replace, retire or dispose of system Outputs Entry Criteria Operations and support budget Exit Criteria End of life: decision to replace, retire, dispose of system, or no longer support system (or system version) Operations and Support Copyright © USC-CSSE15

16. University of Southern California Center for Systems and Software Engineering Copyright © USC-CSSE 16 Different Risk Patterns Yield Different Processes 16Copyright © USC-CSSE

17. University of Southern California Center for Systems and Software Engineering ICSM Patterns: How Phases Can Be Combined Copyright © USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering Agile Rebaselining for Future Increments Short, Stabilized Development of Increment N Verification and Validation (V&V) of Increment N Deferrals ArtifactsConcerns Rapid Change High Assurance Future Increment Baselines Increment N Transition/ Operations and Maintenance Future V&V Resources Increment N Baseline Current V&V Resources Unforeseeable Change (Adapt) Short Development Increments Foreseeable Change (Plan) Stable Development Increments Continuous V&V Short, Stabilized Development of Increment N Short, Stabilized Developments for Increment N Iterative and Incremental Development Copyright © USC-CSSE18

19. University of Southern California Center for Systems and Software Engineering Reality for Large/Complex Development Copyright © USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering ICSM COMMON CASES Copyright © USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering ICSM Common Cases Software application or system Software-intensive device Hardware platform Family of systems or product line System of systems (SoS) or enterprise- wide system Brownfield modernization Copyright © USC-CSSE21

22. University of Southern California Center for Systems and Software Engineering Common Case Examples System (or Subsystem) Is…Use…Examples Software application/system that executes on one or more commercial hardware platforms. It can be a stand- alone software system or a constituent within one or more systems of systems (SoS). Software application or system Cellphone app, business application or system, military command-and-control software system, pharmacy systems, inventory management systems, computer operating system software, database management system An object, machine, or piece of equipment that is developed for a special purpose and has significant features provided by software. Software- intensive device Computer peripherals, weapons, entertainment devices, health care devices (including small robotics used in surgeries or to assist injured people), GPS navigation device, manufacturing tools Vehicle (land, sea, air, or space). Hardware platform Small unmanned ground or air vehicle, automobile, military jeep, tank, ship, airplane, space shuttle, space station, Mars rover Computer.Hardware platform Supercomputer, mainframe, server, laptop, tablet, cellphone Copyright © USC-CSSE22

23. University of Southern California Center for Systems and Software Engineering Common Case Examples (continued) System (or Subsystem) Is…Use…Examples Part of a set of systems that are either similar to each other or interoperate with each other. Family of systems or product line Car models that share many core components; interoperating back-office systems such as billing, accounting, customer care, pricing, and sales force automation systems that share a common underlying repository with standard data definitions/formats for the business domain and are provided by a single vendor A new capability that will be performed by more than one interoperating system System of system or enterprise- wide systems Multiple interoperating systems that are owned and managed by different organizations—for example, navigation systems that include airborne and land systems that also interoperate with GPS Refactoring or re- implementation of an older legacy system or set of systems Brownfield modernization Incremental replacement of old, fragile business systems with COTS products or technology refresh/upgrading of existing systems Copyright © USC-CSSE23

24. University of Southern California Center for Systems and Software Engineering Software Strategies Copyright © USC-CSSE24 NameDescription Architected agile Initial agile iteration focuses on software foundations and architecture issues, then transitions to a purely agile process for development of software capabilities AgileSoftware developed using purely agile methods with short- duration iterations, used after initial architected agile iteration or in cases where the environment for the new software application is well-defined  for example, a cellphone app with well defined interfaces Plan-drivenTraditional software development process guided by detailed plans and schedules, typically employing incremental or evolutionary methods Formal methods Critical software system or subsystem, often containing security- or safety-relevant software or critical/high-precision algorithms that must be rigorously developed, tested, and often certified COTS/servicesSoftware functionality provided through the integration of one or more commercial off-the-shelf software components or software services

25. University of Southern California Center for Systems and Software Engineering Software Strategy Selection Copyright © USC-CSSE25

26. University of Southern California Center for Systems and Software Engineering ICSM Software Strategy Examples Accounting Application Size/Complexity: Small/low Typical Change Rate/Month: Low Criticality: High NDI Support: NDI-driven architecture Organizational Personnel Capability: NDI- experienced, medium to high Software Strategy: COTS Simple Customer Business App Size/Complexity: Small/low Typical Change Rate/Month: Medium to high Criticality: Medium NDI Support: No COTS, development and target environment well-defined Organizational Personnel Capability: Agile- ready, domain experience high Software Strategy: Architected agile Cellphone Feature Size/Complexity: Medium/medium Typical Change Rate/Month: Medium to high Criticality: Low NDI Support: No COTS, development and target environment well-defined Organizational Personnel Capability: Agile- ready, domain experience high Software Strategy: Agile Security Kernel Size/Complexity: Small/low Typical Change Rate/Month: Low Criticality: Extra high NDI Support: No COTS, development and target environment well-defined Organizational Personnel Capability: Strong formal methods experience Software Strategy: Formal methods 26Copyright © USC-CSSE

27. University of Southern California Center for Systems and Software Engineering ICSM and Brownfield Development Many process models are Greenfield-oriented –Requirements→Design→Develop→Test→Operate Failed Greenfield project example –Corporate central financial system –To replace spaghetti-code collection of COBOL programs Alternative ICSM Brownfield approach –Concurrent new-system definition and legacy system re-engineering 27Copyright © USC-CSSE

28. University of Southern California Center for Systems and Software Engineering Example: Failed Greenfield Corporate Financial System Used waterfall approach –Gathered requirements –Chose best-fit ERP system –Provided remaining enhancements Needed to ensure continuity of service –Planned incremental phase-in of new services Failed due to inability to selectively phase out legacy services –Dropped after 2 failed tries at cost of $40M 28Copyright © USC-CSSE

29. University of Southern California Center for Systems and Software Engineering Budgeting Legacy Systems Patched, Highly Coupled Financial and Non-Financial Services Legacy Business Services Contract Services Project Services Deliverables Management Billing Staffing Work Breakdown Structure Subcontracting Scheduling Progress Tracking Change Tracking Reqs, Configuration Management Earned Value Management 29Copyright © USC-CSSE

30. University of Southern California Center for Systems and Software Engineering Legacy Business Services Contract ServicesProject Services Result of Legacy Re-engineering Contract Financial Services Billing Subcontract payments... Contract Non- Financial Services Deliverables mgmt. Terms compliance... General Financial Services Accounting Budgeting Earned value Payroll... General Non- Financial Services Progress tracking Change tracking... Project Financial Services WBS Expenditure categories... Project Non- Financial Services Scheduling Staffing Reqs CM... 30Copyright © USC-CSSE

31. University of Southern California Center for Systems and Software Engineering ICSM Approach to Brownfield Engineering Understanding needs –Analysis of legacy system difficulties Envisioning opportunities –Concurrently decouple legacy financial and non-financial services, explore new system phase-in and architecture options System scoping and architecting –Extract legacy financial, non-financial services –Prioritize, plan for incremental financial services phase-in/out Feasibility evidence development –Successful examples of representative service extractions –Evidence of cost, schedule, performance feasibility Works well when re-engineering/refactoring can be easily achieved and parts can be incrementally replaced 31Copyright © USC-CSSE

32. University of Southern California Center for Systems and Software Engineering Medical First Responder System Example

33. University of Southern California Center for Systems and Software Engineering MedFRS Scenario Ensayo (small urban, semi-rural area) needs –Improve trauma patient outcomes –Simplify/consolidate multitude of first responder systems on ambulances –Provide flexibility to provide first responder systems on other platforms Initial vision –Upgrade communications between ambulances and trauma centers –Incorporate telemedicine capabilities on ambulances –Migrate to a common electronic health record (EHR) system across platforms and sites –Provide high level of patient privacy and safety –Integrate new technologies once approved for general use Copyright © USC-CSSE33

34. University of Southern California Center for Systems and Software Engineering MedFRS Stage/Phase Discussions ICSM principles as applied to the phase Activities, including feasibility analysis Summary of phase –Objectives and business case –Constraints –Alternatives –Risks –Risk mitigation –Risk resolution results –Plan for next phase –Commitment Copyright © USC-CSSE34

35. University of Southern California Center for Systems and Software Engineering MedFRS Exploration Initial Vision1 st Increment at End of Exploration Upgrade/expansion of comms systems capabilities Upgrade and integration of medical devices on ambulances Standard electronic health records across all ambulances, trauma centers, and hospitals Telemedicine capability Improved patient safety and privacy Learning capability for improved patient care Incorporation of new devices (e.g., smart stents) once approved Integrated first responder medical systems, connecting a variety of medical devices and telemetry systems, to initially include cardiac monitors, blood pressure monitors, defibrillators, pulse oximeters, and intravenous (IV) infusion pump monitors using standard interfaces Transmit patient information to the trauma center using current communications systems and transition to standard EHR as soon as possible Improved patient privacy and safety Future: Telemedicine capability Upgraded comms New devices such as smart stents Retina authentication to systems Learning capability Copyright © USC-CSSE35

36. University of Southern California Center for Systems and Software Engineering MedFRS Valuation 1 st Increment at End of Exploration1 st Increment at End of Valuation Integrated first responder medical systems, connecting a variety of medical devices and telemetry systems, to initially include cardiac monitors, blood pressure monitors, defibrillators, pulse oximeters, and intravenous (IV) infusion pump monitors using standard interfaces Transmit patient information to the trauma center using current comms system and transition to standard EHR as soon as possible Improved patient privacy and safety Future: Telemedicine capability Upgraded comms New devices such as smart stents Retina authentication to systems Learning capability Integrated first responder medical systems to be provided by single cardiac monitor, blood pressure monitor, defibrillator, pulse oximeter system and an IV infusion pump system Camera to provide patient images to trauma center Transmit patient information and images to the trauma center using upgraded comms system Improved patient privacy and safety Future: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Copyright © USC-CSSE36

37. University of Southern California Center for Systems and Software Engineering MedFRS Foundation 1 st Increment at End of Valuation1 st Increment at End of Foundations Integrated first responder medical systems to be provided by single cardiac monitor, blood pressure monitor, defibrillator, pulse oximeter system and an IV infusion pump system Camera to provide patient images to trauma center Transmit patient information and images to the trauma center using upgraded comms system Improved patient privacy and safety Future: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Vendors selected for compatible ruggedized laptop, single cardiac monitor, blood pressure monitor, defibrillator, pulse oximeter system, IV infusion pump system, and camera Comms updated in single ambulance and systems checked out on board to determine desired ambulance configuration, tuning, user training, and impacts to patient outcomes configuration, tuning, and user training Software design developed to fully integrate systems Future: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Copyright © USC-CSSE37

38. University of Southern California Center for Systems and Software Engineering MedFRS Development 1 st Increment at End of Foundations1 st Increment at End of Development Vendors selected for compatible ruggedized laptop, single cardiac monitor, blood pressure monitor, defibrillator, pulse oximeter system, IV infusion pump system, and camera Comms updated in single ambulance and systems checked out on board to determine desired ambulance configuration, tuning, user training, and impacts to patient outcomes Software design developed to fully integrate systems and patient information Future: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Hardware configuration/installation plans complete Integration and user interface software developed and tested Improved patient privacy and safety confirmed through prototype on first ambulance Transition plans/schedules to upgrade ambulances and train users (ambulances and trauma centers) User help desk plans established Plans for 2 nd increment Future: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Copyright © USC-CSSE38

39. University of Southern California Center for Systems and Software Engineering MedFRS Production and Operations 1 st Increment at End of Development1 st Increment at End of Productions and Operations Hardware configuration/installation plans complete Integration and user interface software developed and tested Improved patient privacy and safety confirmed through prototype on first ambulance Transition plans/schedules to upgrade ambulances and train users (ambulances and trauma centers) User help desk plans established Plans for 2 nd increment Future: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Hardware procured including spares All ambulances and trauma centers upgraded with new systems (hardware and software) Users trained “just in time” using “spares” as each platform upgraded Help desk established Plans for 2 nd increment implemented Still to come: Telemedicine capability to replace camera Standard EHR New devices such as smart stents Retina authentication to systems Learning capability Copyright © USC-CSSE39

40. University of Southern California Center for Systems and Software Engineering Copyright © USC-CSSE40

41. University of Southern California Center for Systems and Software Engineering Copyright © USC-CSSE List of Acronyms B/LBaselined C4ISRCommand, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance CDConcept Development CDRCritical Design Review COTSCommercial Off-the-Shelf DCRDevelopment Commitment Review DIDevelopment Increment DoDDepartment of Defense ECRExploration Commitment Review EVMSEarned Value Management System FCRFoundations Commitment Review FEDFeasibility Evidence Description FMEAFailure Modes and Effects Analysis FRPFull-Rate Production GAOGovernment Accountability Office GUIGraphical User Interface 41Copyright © USC-CSSE

42. University of Southern California Center for Systems and Software Engineering Copyright © USC-CSSE List of Acronyms (continued) HMIHuman-Machine Interface HSIHuman-System Interface HWHardware ICSMIncremental Commitment Model IOCInitial Operational Capability IRRInception Readiness Review IS&SEIntegrating Systems and Software Engineering LCOLife Cycle Objectives LRIPLow-Rate Initial Production MBASEModel-Based Architecting and Software Engineering NDINon-Developmental Item NRCNational Research Council OCOperational Capability OCROperations Commitment Review OO&DObserve, Orient and Decide OODAObserve, Orient, Decide, Act O&MOperations and Maintenance 42Copyright © USC-CSSE

43. University of Southern California Center for Systems and Software Engineering Copyright © USC-CSSE List of Acronyms (continued) PDRPreliminary Design Review PMProgram Manager PRPublic Relations PRRProduct Release Review RUPRational Unified Process SoSSystem of Systems SoSESystem of Systems Engineering SSESystems and Software Engineering SWSoftware SwESoftware Engineering SysESystems Engineering Sys EngrSystems Engineer S&SESystems and Software Engineering USD (AT&L)Under Secretary of Defense for Acquisition, Technology, and Logistics VCRValidation Commitment Review V&VVerification and Validation WBSWork Breakdown Structure WMIWarfighter-Machine Interface 43Copyright © USC-CSSE