University of Southern California Center for Systems and Software Engineering Barry Boehm CS 510, Fall 2014 ICSM Stage I: Phases and Project Example

University of Southern California Center for Systems and Software Engineering Outline Overview of ICSM Stages I and II Stage I Detailed Descriptions –Exploration, Valuation, Foundations –Inputs, Activities, Outputs –Entry and Exit Criteria Example Project Usage –Medical First Responder System (MedFRS) Fall 2014Copyright © USC-CSSE2

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

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, constraints, and candidate solution options –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 Fall 2014Copyright © USC-CSSE4

University of Southern California Center for Systems and Software Engineering ICSM Phase Detailed Descriptions Fall 2014Copyright © USC-CSSE5

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 Fall 2014Copyright © USC-CSSE6

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 Fall 2014Copyright © USC-CSSE7

University of Southern California Center for Systems and Software Engineering Example Questions To Guide Phase Activities Exploration –What is the real need? Who wants it and why? –Who is/are the key proponent(s)? Opponent(s)? –How strong is the business case? What is the expected market share? Valuation –Will less extreme performance/capability suffice? –If so, what are the various levels of acceptability? –If innovation or new technologies required, what is current status? Foundations –What is the status of desired innovations or new technologies? –Have they been sufficiently matured, or should alternatives be considered? Fall 2014Copyright © USC-CSSE8

University of Southern California Center for Systems and Software Engineering Example Questions To Guide Phase Activities (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? Fall 2014Copyright © USC-CSSE9

University of Southern California Center for Systems and Software Engineering Outline Overview of ICSM Stages I and II Stage I Detailed Descriptions –Exploration, Valuation, Foundations –Inputs, Activities, Outputs –Entry and Exit Criteria Example Project Usage –Medical First Responder System (MedFRS) Fall 2014Copyright © USC-CSSE10

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 Fall 2014Copyright © USC-CSSE11

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 Fall 2014Copyright © USC-CSSE12

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 Fall 2014Copyright © USC-CSSE13

University of Southern California Center for Systems and Software Engineering Outline Overview of ICSM Stages I and II Stage I Detailed Descriptions –Exploration, Valuation, Foundations –Inputs, Activities, Outputs –Entry and Exit Criteria Example Project Usage –Medical First Responder System (MedFRS) Fall 2014Copyright © USC-CSSE14

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 Fall 2014Copyright © USC-CSSE15

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 Fall 2014Copyright © USC-CSSE16

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 Fall 2014Copyright © USC-CSSE17

University of Southern California Center for Systems and Software Engineering Exploration: Assess Related Systems The Tucson effort began in 2006 and was deployed in late 2007 with the help of $3.8 million in federal grants. It used a WiFi network specifically for mobile teletrauma care and was available only within the city. Due to somewhat unreliable WiFi connections and a lack of additional funding after the grant funds were used, the telemedicine capability was discontinued. However, the Tucson first responders continue to transmit electronic patient care reports over the network and communicate with the trauma centers using their other communications systems. East Baton Rouge Parish began its effort to include telemedicine capabilities on first responder vehicles in Its approach was to implement the capabilities in three phases, starting with a prototype on a single first responder platform using 3G cellular technology. Phase 2 provided the capability to share information between all area emergency rooms and prehospital providers, leaving the implementation of the telemedicine capability using 4G cellular technology to Phase 3. Phase 3 is currently in the early stages. Fall 2014Copyright © USC-CSSE18

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 Fall 2014Copyright © USC-CSSE19

University of Southern California Center for Systems and Software Engineering Valuation: Cost-Benefit Analysis During further discussions with the physicians in the hospital trauma centers that would be using the telemedicine systems, it was learned that the most valuable information from a telemedicine system is the patient-monitoring data and videos of the patient. If patient-monitoring data could be sent directly from the ambulance laptop to the trauma center and a wireless camera added to the laptop that could stream videos to the trauma centers, the more expensive telemedicine system would not be needed. Further investigations of wireless laptop cameras indicated that they could be purchased for $100 to $400 each, depending on the quality of images desired. As a result of the initial Valuation-phase studies and evaluations, the estimated life- cycle costs for MedFRS were updated, along with the development of a schedule showing the rollout of MedFRS capabilities over time. If all of the initially desired capabilities were to be provided as part of this upgrade effort, it would cost $3.5 million to $5 million. Therefore, plans were adjusted to defer migration to a standard EHR system and to replace the telemedicine system with a wireless video camera that could be used to communicate with physicians at the trauma center. This change was expected to keep initial costs well under the $2 million constraint while retaining a budget to incorporate a standard EHR in the future. Fall 2014Copyright © USC-CSSE20

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 Fall 2014Copyright © USC-CSSE21

University of Southern California Center for Systems and Software Engineering Foundations: Development Decisions and Plans With the Foundations Commitment Review decision to proceed, trade studies to evaluate the integrated cardiac monitors (which included a defibrillator, blood pressure monitor, and pulse oximeter) and IV infusion pump monitors were initiated using the COTS evaluation criteria listed in the Foundations questions earlier. As a result, a single vendor was selected and purchase orders approved to purchase a single version of the cardiac monitor and IV infusion pump monitor. A ruggedized laptop that was compatible with the chosen devices was also selected to host the integrated prototype on the first responder platform. Next, plans were developed for the installation of the systems and the training of the personnel who would be using the systems. The plan was that the single vehicle would be taken out of service for one week; while the new systems were being installed and tested, the first responders would attend training at the vendor site on the configuration options, use, and troubleshooting processes. In the prototype version, there was to be minimal integration with the first responder laptop and the users would need to manually create messages to send information to the trauma centers. Once the systems were received, the installation and training plans were implemented. Fall 2014Copyright © USC-CSSE22

University of Southern California Center for Systems and Software Engineering Fall 2014Copyright © USC-CSSE List of Acronyms B/LBaselined CDConcept Development CDRCritical Design Review COTSCommercial Off-the-Shelf DCRDevelopment Commitment Review DIDevelopment Increment ECRExploration Commitment Review EVMSEarned Value Management System FCRFoundations Commitment Review FEDFeasibility Evidence Description FMEAFailure Modes and Effects Analysis FRPFull-Rate Production GUIGraphical User Interface HMIHuman-Machine Interface HSIHuman-System Interface HWHardware ICSMIncremental Commitment Model IOCInitial Operational Capability IRRInception Readiness Review IS&SEIntegrating Systems and Software Engineering 23Copyright © USC-CSSE

University of Southern California Center for Systems and Software Engineering Fall 2014Copyright © USC-CSSE List of Acronyms (continued) LCOLife Cycle Objectives NDINon-Developmental Item NRCNational Research Council OCOperational Capability OCROperations Commitment Review O&MOperations and Maintenance 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 VCRValidation Commitment Review V&VVerification and Validation WBSWork Breakdown Structure 24Copyright © USC-CSSE