ICSM Stages and Phases CS 510, Fall 2017

ICSM Stages and Phases CS 510, Fall 2017
Copyright © USC-CSSE

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 2017 Copyright © USC-CSSE

The Incremental Commitment Spiral Process: Phased View
Anchor Point Milestones Synchronize, stabilize concurrency via FEDs The Incremental Commitment Life Cycle Process: Overview This slide shows how the ICSM spans the life cycle process from concept exploration to operations. Each phase culminates with an anchor point milestone review. At each anchor point, there are 4 options, based on the assessed risk of the proposed system. Some options involve go-backs. These options result in many possible process paths. The life cycle is divided into two stages: Stage I of the ICSM (Definition) has 3 decision nodes with 4 options/node, culminating with incremental development in Stage II (Development and Operations). Stage II has an additional 2 decision nodes, again with 4 options/node. One can use ICSM risk patterns to generate frequently-used processes with confidence that they fit the situation. Initial risk patterns can generally be determined in the Exploration phase. One then proceeds with development as a proposed plan with risk-based evidence at the VCR milestone, adjusting in later phases as necessary. For complex systems, a result of the Exploration phase would be the Prototyping and Competition Plan discussed above. Risks associated with the system drive the life cycle process. Information about the risk(s) (feasibility assessments) supports the decision to proceed, adjust scope or priorities, or cancel the program. Risk patterns determine life cycle process Fall 2017 Copyright © USC-CSSE 3

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 2017 Copyright © USC-CSSE

Questions To Guide Phase Activities
Engineering technical activities “ility” trades Aspects of potential pitfalls and risks Feasibility evidence Potential cost/schedule issues Stakeholders Fall 2017 Copyright © USC-CSSE

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 2017 Copyright © USC-CSSE

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 2017 Copyright © USC-CSSE

Exploration Activities Inputs Outputs Entry Criteria Exit Criteria
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 2017 Copyright © USC-CSSE

Valuation Activities Inputs Outputs Entry Criteria Exit Criteria
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 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 Analysis of any prototypes Updated risks and mitigation plans Approved Foundations strategy plan Key stakeholder commitments/ MOAs Inputs Outputs Delete extra space after the slashes in the Activities and Outputs labels (e.g., “commitments/MOAs”) 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 Fall 2017 Copyright © USC-CSSE

Activities Foundations Inputs Outputs Entry Criteria Exit Criteria
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 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 Analysis/results of any Valuation prototypes Key risks and mitigation plans Approved Foundations strategy plan Key stakeholder commitments/ MOAs Inputs Outputs Delete the extra space after the slashes in the Activities (3 times) and Outputs (1 time) labels 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 Fall 2017 Copyright © USC-CSSE

The Incremental Commitment Spiral Process: Phased View
Anchor Point Milestones Concurrently engr. Incr.N (ops), N+1 (devel), N+2 (arch) Concurrently engr. OpCon, rqts, arch, plans, prototypes The Incremental Commitment Life Cycle Process: More on the Overview Stage II of the Incremental Commitment Life Cycle provides a framework for concurrent engineering and development of multiple increments. More on this concurrency follows on the next slides. Note: The term “concurrent engineering” fell into disfavor when behind-schedule developers applied it to the practice of proceeding into development while the designers worked on finishing the design. Not surprisingly, the developers encountered a high rework penalty for going into development with weak architecture and risk resolution. “Concurrent engineering” as applied in the ICSM is much different. It is focused on doing a cost-effective job of architecture and risk resolution in Stage I; and on performing stabilized development, verification, and validation of the current system increment while concurrently handling the systems change traffic and preparing a feasibility-validated architecture and set of plans for the next increment in Stage II. Fall 2017 Copyright © USC-CSSE 11

Iterative and Incremental Development
Unforeseeable Change (Adapt) Rapid Change Agile Rebaselining for Future Increments Future Increment Baselines Short Development Increments Deferrals Foreseeable Change (Plan) Short, Stabilized Development of Increment N Short, Stabilized Development of Increment N Increment N Transition/ Operations and Maintenance Short, Stabilized Developments for Increment N Increment N Baseline Stable Development Increments High Assurance Artifacts Concerns Future V&V Resources Current V&V Resources Verification and Validation (V&V) of Increment N Continuous V&V Fall 2017 Copyright © USC-CSSE

Reality for Large/Complex Development
Fall 2017 Copyright © USC-CSSE

Agile Change Processing and Rebaselining
Assess Changes, Propose Handling Stabilized Increment-N Development Team Change Proposers Future Increment Managers Agile Future- Increment Rebaselining Team Negotiate change disposition Formulate, analyze options in context of other changes Handle Accepted changes Discuss, resolve deferrals to future increments Propose Changes Discuss, revise, defer, or drop Rebaseline future-increment Foundations packages Prepare for rebaselined development Defer some Increment-N capabilities Recommend handling in current increment Accept changes Handle in current rebaseline Proposed changes Recommend no action, provide rationale Recommend deferrals to future increments To handle unpredictable, asynchronous change traffic, it is not possible to do a sequential observe, then orient, then decide process. Instead, it requires handling unforeseen change requests involving new technology or COTS opportunities; changing requirements and priorities; changing external interfaces; low-priority current increment features being deferred to a later increment; and user requests based on experience with currently-fielded increments (including defect fixes). In the context of the agile rebaselining team in Chart 10, this chart shows how the agile team interacts with the change proposers, current-increment development team, and managers of future increments to evaluate proposed changes and their interactions with each other, and to negotiate rebaselined Milestone B packages for the next increment. Again, there is no precise way to forecast the budget and schedule of this team’s workload. Within an available budget and schedule, the agile team will perform a continuing “handle now; incorporate in next increment rebaseline; defer-or-drop” triage in the top “Assess Changes, Propose Handling” box. Surges in demand would have to be met by surges in needed expertise and funding support. Fall 2017 Copyright © USC-CSSE

Activities Development Outputs Inputs Entry Criteria Exit Criteria
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 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 System ready for production/deployment Outputs Inputs Inputs: Close up spaces around slash and change capitalization in next to last bullet: “commitments/MoA” Activities: Close up space around slash “needs/opportunities/risks” Entry Criteria Decision to develop increment Budget for increment Development activities Exit Criteria Decision to either proceed with production/operations or discontinue Fall 2017 Copyright © USC-CSSE

Activities Production Inputs Outputs Entry Criteria Exit Criteria
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 System units ready for operations User information/training materials Help desk materials and training Maintenance and logistics plans Approved production plans Inputs Outputs Under Activities, delete extra space around slash: “…information/training materials” Under Activities and Outputs, change capitalization: “Help Desk” (2 times) Entry Criteria Production budget Exit Criteria Production for current system version complete Fall 2017 Copyright © USC-CSSE

Operations and Support
Activities Operations and Support 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 Support: Problem reports to be resolved Change requests for implementation consideration End of life: Authorization to replace, retire or dispose of system Approved operations and support plans System updates Help desk updates Inputs Outputs Under Operations and Support, change capitalization: “Help Desk updates” Under Activities, change capitalization: “Operate system Help Desk and…” Under Outputs, add series comma: Authorization to replace, retire, or dispose…” 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) Fall 2017 Copyright © USC-CSSE

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 2017 Copyright © USC-CSSE

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 2017 Copyright © USC-CSSE

MedFRS Exploration Initial Vision 1st 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: Upgraded comms New devices such as smart stents Retina authentication to systems Learning capability Fall 2017 Copyright © USC-CSSE

MedFRS Valuation 1st Increment at End of Exploration
1st 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 Telemedicine capability to replace camera Standard EHR Fall 2017 Copyright © USC-CSSE

MedFRS Foundation 1st Increment at End of Valuation
1st 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 Fall 2017 Copyright © USC-CSSE

MedFRS Development 1st Increment at End of Foundations
1st 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 2nd increment Fall 2017 Copyright © USC-CSSE

MedFRS Production and Operations
1st Increment at End of Development 1st 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 2nd 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 2nd increment implemented Still to come: Fall 2017 Copyright © USC-CSSE

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 Fall 2017 Copyright © USC-CSSE

Different Risk Patterns Yield Different Processes
As illustrated in the four example paths through the Incremental Commitment Model in this slide, the ICSM is not a single monolithic one-size-fits-all process model. As with the spiral model, it is a risk-driven process model generator, but the ICSM makes it easier to visualize how different risks create different processes. In Example A, a simple business application based on an appropriately-selected Enterprise Resource Planning (ERP) package, there is no need for a Valuation or Foundations activity if there is no risk that the ERP package and its architecture will not cost-effectively support the application. Thus, one could go directly into the Development phase, using an agile method such as a Scrum/Extreme Programming combination would be a good fit. There is no need for Big Design Up Front (BDUF) activities or artifacts because an appropriate architecture is already present in the ERP package. Nor is there a need for heavyweight waterfall or V-model specifications and document reviews. The fact that the risk at the end of the Exploration phase is negligible implies that sufficient risk resolution of the ERP package’s human interface has been done. Example B involves the upgrade of several incompatible legacy applications into a service-oriented web-based system. Here, one could use a sequential waterfall or V-model if the upgrade requirements were stable, and its risks were low. However, if for example the legacy applications’ user interfaces were incompatible with each other and with web-based operations, a concurrent risk-driven spiral, waterfall, or V-model that develops and exercise extensive user interface prototypes and generates a Feasibility Evidence Description (described on chart 12) would be preferable. In Example C, the stakeholders may have found during the Valuation phase that their original assumptions about the stakeholders having a clear, shared vision and compatible goals with respect the proposed new system’s concept of operation and its operational roles and responsibilities were optimistic. In such a case, it is better to go back and assure stakeholder value proposition compatibility and feasibility before proceeding, as indicated by the arrow back into the valuation phase. In Example D, it is discovered before entering the Development phase that a superior product has already entered the marketplace, leaving the current product with an infeasible business case. Here, unless a viable business case can be made by adjusting the project’s scope, it is best to discontinue it. It is worth pointing out that it is not necessary to proceed to the next major milestone before terminating a clearly non-viable project, although stakeholder concurrence in termination is essential. Fall 2017 Copyright © USC-CSSE Copyright © USC-CSSE 27 27

ICSM Patterns: How Phases Can Be Combined

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 Fall 2017 Copyright © USC-CSSE

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. Supercomputer, mainframe, server, laptop, tablet, cellphone Fall 2017 Copyright © USC-CSSE

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 Fall 2017 Copyright © USC-CSSE

Software Strategies Name Description Architected agile
Initial agile iteration focuses on software foundations and architecture issues, then transitions to a purely agile process for development of software capabilities Agile Software 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-driven Traditional 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/services Software functionality provided through the integration of one or more commercial off-the-shelf software components or software services Fall 2017 Copyright © USC-CSSE

Software Strategy Selection

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 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 Criticality: Low Software Strategy: Agile Security Kernel Criticality: Extra high Organizational Personnel Capability: Strong formal methods experience Software Strategy: Formal methods Fall 2017 Copyright © USC-CSSE

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 Fall 2017 Copyright © USC-CSSE

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 Fall 2017 Copyright © USC-CSSE

Legacy Business Services
Legacy Systems Patched, Highly Coupled Financial and Non-Financial Services Legacy Business Services Contract Services Project Services Budgeting Staffing Deliverables Management Billing Earned Value Management Subcontracting Change Tracking Progress Tracking Work Breakdown Structure Scheduling Reqs, Configuration Management Fall 2017 Copyright © USC-CSSE

Result of Legacy Re-engineering
Legacy Business Services Contract Services Project Services 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 ... Fall 2017 Copyright © USC-CSSE

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 If not relatively easy, better to focus on capturing/restructuring system data and migrating to replacement system Fall 2017 Copyright © USC-CSSE

List of Acronyms B/L Baselined
C4ISR Command, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance CD Concept Development CDR Critical Design Review COTS Commercial Off-the-Shelf DCR Development Commitment Review DI Development Increment DoD Department of Defense ECR Exploration Commitment Review EVMS Earned Value Management System FCR Foundations Commitment Review FED Feasibility Evidence Description FMEA Failure Modes and Effects Analysis FRP Full-Rate Production GAO Government Accountability Office GUI Graphical User Interface Several further acronyms are TBD Fall 2017 Copyright © USC-CSSE Copyright © USC-CSSE 42

List of Acronyms (continued)
HMI Human-Machine Interface HSI Human-System Interface HW Hardware ICSM Incremental Commitment Model IOC Initial Operational Capability IRR Inception Readiness Review IS&SE Integrating Systems and Software Engineering LCO Life Cycle Objectives LRIP Low-Rate Initial Production MBASE Model-Based Architecting and Software Engineering NDI Non-Developmental Item NRC National Research Council OC Operational Capability OCR Operations Commitment Review OO&D Observe, Orient and Decide OODA Observe, Orient, Decide, Act O&M Operations and Maintenance Fall 2017 Copyright © USC-CSSE Copyright © USC-CSSE 43

List of Acronyms (continued)
PDR Preliminary Design Review PM Program Manager PR Public Relations PRR Product Release Review RUP Rational Unified Process SoS System of Systems SoSE System of Systems Engineering SSE Systems and Software Engineering SW Software SwE Software Engineering SysE Systems Engineering Sys Engr Systems Engineer S&SE Systems and Software Engineering USD (AT&L) Under Secretary of Defense for Acquisition, Technology, and Logistics VCR Validation Commitment Review V&V Verification and Validation WBS Work Breakdown Structure WMI Warfighter-Machine Interface Fall 2017 Copyright © USC-CSSE Copyright © USC-CSSE 44

ICSM Stages and Phases CS 510, Fall 2017

Similar presentations

Presentation on theme: "ICSM Stages and Phases CS 510, Fall 2017"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

ICSM Stages and Phases CS 510, Fall 2017

Similar presentations

Presentation on theme: "ICSM Stages and Phases CS 510, Fall 2017"— Presentation transcript:

Similar presentations

About project

Feedback