A Winsor Brown CS 577b March 24, 2010 Incrementally Committed Acquisition (ICM nee Spiral) of Software-Intensive Systems of Systems A Winsor Brown CS 577b March 24, 2010 9/22/2018 © 2004-2010 USC-CSSE

Outline Definitions: Acquisition; SISOS Trends in Software-Intensive Systems of Systems Role of Incremental Commitment (nee Spiral) Development Concurrent engineering of requirements and architecture; systems and software Emphasis on risk management Example system-of-systems top-10 risk list Representative risks and mitigations Incremental Commitment Alternative Conclusions 9/22/2018 © 2004-2010 USC-CSSE

Acquisition (DoD) The acquisition process is structured by DoDI (DoD Instruction) 5000.02 into discrete phases separated by major decision points (called milestones or decision reviews) with a number of key activities to provide the basis for comprehensive management and informed decision making. Details available at https://akss.dau.mil/Documents/publications/ Final back-120408_singles.pdf Final%20Ver%205%203%202%20Front%20draft%2011%20Dec%202008.pdf 9/22/2018 © 2004-2010 USC-CSSE

Acquisition (DoD) (cont.) Life Cycle Management System Chart a pictorial roadmap of key activities in the systems acquisition processes illustrates the interaction of the three-key processes that must work in concert to deliver the capabilities required by the warfighters the requirements process (Joint Capabilities Integration & Development System [JCIDS]); the acquisition process (Defense Acquisition System); and program and budget development (Planning, Programming, Budgeting, and Execution [PPBE] process). 9/22/2018 © 2004-2010 USC-CSSE

Acquisition (DoD) (cont.) 9/22/2018 © 2004-2010 USC-CSSE

SISOS System of Systems (SOS) Software Intensive (SI) Planned/directed (relatively new) Directed: not many Acknowledged (lead by Sys of Sys Eng'g Group) Federated (not single point of admin.) Recognized Ad hoc Software Intensive (SI) See “EC25b=SISoS--FCSexampleV0.doc” 9/22/2018 © 2004-2010 USC-CSSE

Outline Definitions: Acquisition; SISOS Trends in Software-Intensive Systems of Systems Waterfall Legacies Role of Spiral Development Concurrent engineering of requirements and architecture; systems and software Emphasis on risk management Example system-of-systems top-10 risk list Representative risks and mitigations Incremental Commitment Alternative Conclusions 9/22/2018 © 2004-2010 USC-CSSE

Trends in Software-Intensive Systems Transformational, network-centric systems These are fundamentally software-intensive Emphasis on joint, interoperable, capability-based systems And increasingly, systems of systems Increasing requirements emergence, COTS-dependence, environmental change Traditional sequential acquisition practices increasingly inadequate Fixed-requirements, -cost, -schedule contracting Waterfall legacies: MIL-STD-1521B, parts of Software CMM 9/22/2018 © 2004-2010 USC-CSSE

Waterfall Legacies: SW CMM v.1.1 Requirements Management, Ability 1: “Analysis and allocation of the system requirements is not the responsibility of the software engineering group but is a prerequisite for their work.” Concurrent engineering emphasized in CMMI, DoDD 5000.1, DoDI 5000.2 9/22/2018 © 2004-2010 USC-CSSE

History and Trends The waterfall model and its problems Spiral model resolution of problems Problems with spiral model Initial resolution: win-win, anchor points Further problems Resolution with Incremental Commitment Model 9/22/2018 © 2004-2010 USC-CSSE

Waterfall Model Risk Profile Requirements analysis The most critical risks are architectural: Performance (size, time, accuracy) Interface integrity System qualities (adaptability, portability, etc.) Specifications & models Design R i s k Specifications & models Code and unit test Tested code Subsystem integration Executable subsystem System integration Executable system Time 9/22/2018 © 2004-2010 USC-CSSE

Conventional Software Process Problem: Late Tangible Design Assessment Standard sequence of events: Early and successful design review milestones Late and severe integration trauma Schedule slippage Progress (% coded) / 100 90 Integration begins 80 70 60 Late design breakage Conventional 50 40 30 20 10 Design Reviews Time (months) 9/22/2018 © 2004-2010 USC-CSSE

Sequential Engineering Neglects Risk $100M Arch. A: Custom many cache processors $50M Arch. B: Modified Client-Server Original Spec After Prototyping 1 2 3 4 5 Response Time (sec) 9/22/2018 © 2004-2010 USC-CSSE

Resulting Project Social Structure SOFTWARE MGMT. AERO. ELEC. G & C MFG. COMM PAYLOAD I wonder when they'll give us our requirements? 9/22/2018 © 2004-2010 USC-CSSE

History and Trends The waterfall model and its problems Spiral model resolution of problems Problems with spiral model Initial resolution: win-win, anchor points Further problems Resolution with Incremental Commitment Model 9/22/2018 © 2004-2010 USC-CSSE

DoDI 5000.2 “Spiral Development” Section 3.3.2.1 Desired capability is identified End-state requirements not initially known Requirements refined through demonstration and risk management Continuous user feedback Each increment provides user the best possible capability Requirements for future increments depend on feedback from users and technology maturation 9/22/2018 © 2004-2010 USC-CSSE

Spiral Model of Software Process 7 9/22/2018 © 2004-2010 USC-CSSE

Original Spiral and Misinterpretations Common Misinterpretations Hack some prototypes Fit spiral into waterfall Incremental waterfalls Suppress risk analysis No concurrency, feedback One-size-fits-all model 9/22/2018 © 2004-2010 USC-CSSE

What Is The Win Win Spiral Model? A stakeholder-driven and risk-driven process model generator There are no one-size-fits-all software process models Different stakeholders and different risks generate different process models A way to perform controlled concurrent engineering Of systems and software; of development and evolution; of product and process Controlled by anchor point milestones and Feasibility Rationales An upward-compatible extension of the Rational Unified Process Common risk and anchor-point orientation With stakeholder and value-based extensions Used successfully on a wide variety of applications A way to implement DoDD 5000.1 and DoDI 5000.2 9/22/2018 © 2004-2010 USC-CSSE

The FCS Win-Win Spiral Model Driven By: Success-critical stakeholders’ win conditions Progress Through Steps 2 1b. Stakeholders Identify System 2a. Evaluate Objectives, Constraints, Alternatives & Priorities (OC&Ps); with respect to Alternative Solution OC&Ps Elements Risk Management 1 3 1a. Identify 2b. Success-Critical Assess, Stakeholders Address Build 3 Build 2 Spiral anchor point milestones Bl1 Stakeholders’ Risks L CA L CO 4 8 Commitment 7 Stakeholders’ Review 6 3. Elaborate Product and Feasibility Rationale Process 4. Verify and Validate Definition Product and Process Definitions 5 9/22/2018 © 2004-2010 USC-CSSE

The WWSM Enables Concurrent Engineering 9/22/2018 © 2004-2010 USC-CSSE

Spiral/MBASE/Rational Life-Cycle Model Inception Architectural prototype Draft specifications & models Elaboration Initial executable system Refined specifications & models R i s k Construction Iteration 3... Intermediate system Transition Final system Time 9/22/2018 © 2004-2010 USC-CSSE

Continuous Integration Iterative Development Project Results Continuous Integration Progress (% coded) Final Qual Test Final Qual Test 100 Iterative Development Demo 90 Integration Begins 80 Demo 70 Late Design Breakage 60 Conventional 50 Demo 40 30 20 10 Time (months) 9/22/2018 © 2004-2010 USC-CSSE

Experience with the Spiral Model Good for getting risks resolved early Good for tailoring process to situation Good for accommodating COTS, reuse, prototyping Where do objectives, constraints, and alternatives come from? WinWin Negotiation and Maintenance of SCS WinWin (conditions) Common life cycle milestones Anchor Points 9/22/2018 © 2004-2010 USC-CSSE

Life Cycle Anchor Points Common System/Software stakeholder commitment points Defined in concert with Government, industry affiliates Coordinated with Rational’s Unified Software Development Process Life Cycle Objectives (LCO) Stakeholders’ commitment to support system architecting Like getting engaged Life Cycle Architecture (LCA) Stakeholders’ commitment to support full life cycle Like getting married Initial Operational Capability (IOC) Stakeholders’ commitment to support operations Like having your first child 9/22/2018 © 2004-2010 USC-CSSE

WinWin Spiral Anchor Point Milestone Content (Risk-driven level of detail for each element) *WWWWWHH: Why, What, When, Who, Where, How, How Much Milestone Element Life Cycle Objectives (LCO) Life Cycle Architecture (LCA) Definition of Operational Concept Top-level system objectives and scope - System boundary - Environment parameters and assumptions - Evolution parameters Operational concept - Operations and maintenance scenarios and parameters - Organizational life-cycle responsibilities (stakeholders) Elaboration of system objectives and scope of increment Elaboration of operational concept by increment Top-level functions, interfaces, quality attribute levels, including: - Growth vectors and priorities - Prototypes Stakeholders’ concurrence on essentials Elaboration of functions, interfaces, quality attributes, and prototypes by increment - Identification of TBD’s( (to-be-determined items) Stakeholders’ concurrence on their priority concerns Top-level definition of at least one feasible architecture - Physical and logical elements and relationships - Choices of COTS and reusable software elements Identification of infeasible architecture options Choice of architecture and elaboration by increment - Physical and logical components, connectors, configurations, constraints - COTS, reuse choices - Domain-architecture and architectural style choices Architecture evolution parameters Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBD’s for later increments Assurance of consistency among elements above All major risks resolved or covered by risk management plan Identification of life-cycle stakeholders - Users, customers, developers, maintainers, interoperators, general public, others Identification of life-cycle process model - Top-level stages, increments Top-level WWWWWHH* by stage - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Definition of System Requirements and Software Architecture Definition of Life- Cycle Plan Feasibility Rationale System Prototype(s) Exercise key usage scenarios Resolve critical risks Exercise range of usage scenarios Resolve major outstanding risks 9/22/2018 © 2004-2010 USC-CSSE

Pass/Fail Feasibility Rationales Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will Satisfy the requirements: capability, interfaces, level of service, AND evolution Support the operational concept Be buildable within the budges and schedules in the plan Generate a viable return on investment Generate satisfaction outcomes for all of the success-critical stakeholders All major risks resolved or covered by risk management plans [mitigations] Serves as basis for stakeholders’ commitment to proceed 9/22/2018 © 2004-2010 USC-CSSE

Initial Operational Capability (IOC) Software preparation Operational and support software Data preparation, COTS licenses Operational readiness testing Site preparation Facilities, equipment, supplies, vendor support User, operator, and maintainer preparation Selection, teambuilding, training 9/22/2018 © 2004-2010 USC-CSSE

Inception Elaboration Construction Transition Engineering Stage Anchor Points and Rational USDP Phases Engineering Stage Manufacturing Stage Inception Elaboration Construction Transition LCO LCA IOC Feasibility Iterations Architecture Iterations Usable Iterations Product Releases Management R E Q D S I M P R E Q D E S I M P D E P R E Q D E S I M P D E P R E Q D E S I M P D E P Management Management Management RATIONAL S o f t w a r e C o r p o r a t i o n 9/22/2018 © 2004-2010 USC-CSSE

Spiral Anchor Points Enable Concurrent Engineering 9/22/2018 © 2004-2010 USC-CSSE

History and Trends Outline The waterfall model and its problems Spiral model resolution of problems Problems with spiral model Initial resolution: win-win, anchor points Further problems Resolution with Incremental Commitment Model 9/22/2018 © 2004-2010 USC-CSSE

Effect of Waterfall SEMP and Spiral SDP Delays in starting critical software infrastructure OS, networking, DBMS, transaction processing, … Infeasible infrastructure Premature performance requirements (e.g., 1 second) Premature hardware selection overconstrains software Can also induce premature COTS commitments Waterfall-based progress payments undermine-spiral tasks Develop prototypes or get paid for specifications 9/22/2018 © 2004-2010 USC-CSSE

Further Problems with Spiral Model Too easy to misinterpret Propagated via vugraph vs. full paper Concurrent, asynchronous, mini-spirals Single, inexplicit role of risk When, how to backtrack When, how to skip cycles 9/22/2018 © 2004-2010 USC-CSSE

Original Spiral and Misinterpretations Common Misinterpretations Unroll spiral into V-model Hack some prototypes Incremental waterfalls Suppress risk analysis No concurrency, feedback One-size-fits-all model 9/22/2018 © 2004-2010 USC-CSSE

“Spiral Model” – Example Misinterpretation From a government briefing “explaining” the spiral model Incremental, but no risk, concurrency, stakeholder satisficing Requirements Design Implement Test 9/22/2018 © 2004-2010 USC-CSSE

Top-10 Risks: Software-Intensive Systems of Systems - CrossTalk, May 2004 Acquisition management and staffing Requirements/architecture feasibility Achievable software schedules Supplier integration Adaptation to rapid change Quality factor achievability and tradeoffs Product integration and electronic upgrade Software COTS and reuse feasibility External interoperability Technology readiness 9/22/2018 © 2004-2010 USC-CSSE

Effect of Software Underrepresentation Software risks discovered too late Slow, buggy change management Recent large project reorganization Software SW SW SW SW SW SW 9/22/2018 © 2004-2010 USC-CSSE

Need for CRACK Integrated Team Members - CrossTalk, December 2003 Not Collaborative: Discord, frustration, loss of morale Not Representative: Delivery of unacceptable systems, late rework Not Authorized: Authorization delays, unsupported systems Not Committed: Missing homework, discontinuities, delays Not Knowledgeable: Unacceptable systems, delays, late rework 9/22/2018 © 2004-2010 USC-CSSE

Supplier Integration: Rapid Adaptability to Change Risk #4/5. Inflexible subcontracting will be a major source of delays and shortfalls. Strategy #4/5. Develop subcontract provisions enabling flexibility in evolving deliverables. Develop an award fee structure based on objective criteria for: - Schedule Preservation - Cost Containment - Technical Performance - Architecture and COTS Compatibility - Continuous Integration Support - Program Management - Risk Management 9/22/2018 © 2004-2010 USC-CSSE

Top-10 Risks: Software-Intensive Systems of Systems - CrossTalk, May 2004 Acquisition management and staffing Requirements/architecture feasibility Achievable software schedules Supplier integration Adaptation to rapid change Quality factor achievability and tradeoffs Product integration and electronic upgrade Software COTS and reuse feasibility External interoperability Technology readiness 9/22/2018 © 2004-2010 USC-CSSE

Rapid, Synchronous Software Upgrades Risk #7. Out-of-synchronization software upgrades will be a major source of operational losses Software crashes, communication node outages, out-of-synch data, mistaken decisions Extremely difficult to synchronize multi-version, distributed, mobile-platform software upgrades Especially if continuous-operation upgrades needed Strategy #7a. Architect software to accommodate continuous-operation, synchronous upgrades E.g., parallel operation of old and new releases while validating synchronous upgrade Strategy #7b. Develop operational procedures for synchronous upgrades in software support plans Strategy #7c. Validate synchronous upgrade achievement in operational test & evaluation 9/22/2018 © 2004-2010 USC-CSSE

COTS: The Future is Here Escalate COTS priorities for research, staffing, education It’s not “all about programming” anymore New processes required 9/22/2018 © 2004-2010 USC-CSSE

COTS Upgrade Synchronization and Obsolescence Risk #8a: Many subcontractors means a proliferation of evolving COTS interfaces Risk #8b: Aggressively-bid subcontracts can lead to delivery of obsolete COTS New COTS released every 8-9 months (GSAW) COTS unsupported after 3 releases (GSAW) An actual delivery: 120 COTS; 46% unsupported Strategy #8a: Emphasize COTS interoperability in source selection process Strategy #8b: Contract provisions ensuring delivery of refreshed COTS products. 9/22/2018 © 2004-2010 USC-CSSE

History and Trends Outline The waterfall model and its problems Spiral model resolution of problems Problems with spiral model Initial resolution: win-win, anchor points Further problems Resolution with Incremental Commitment Model 9/22/2018 © 2004-2010 USC-CSSE

Problem Solutions: The Incremental Commitment Model Use spiral principles vs. diagram Relate to stakeholder commitments and values Use multiple connected views Make concurrency explicit Use risk to show go-backs and skips Provide view for handling mini-spirals 9/22/2018 © 2004-2010 USC-CSSE

The Incremental Commitment Life Cycle Process: Overview The Incremental Commitment Model (ICM) builds on concepts in the risk-driven spiral model [Boehm, 1988], the phases and anchor points in the Rational Unified Process (RUP) [Royce, 1998; Kruchten, 1999; Jacobson-Booch-Rumbaugh, 1999; Boehm, 1996], the Cooper stage-gate model [Cooper, 2001] and recent extensions of the spiral model to address systems of systems acquisition [Boehm, 2006]. In comparison to the software-intensive RUP, the ICM also addresses hardware and human factors integration. It extends the RUP phases to cover the full system life cycle: an Exploration phase precedes the RUP Inception phase, which is refocused on Valuation and investment analysis. The RUP Elaboration phase is refocused on Architecting; the RUP Construction and Transition phases are combined into Development; and an additional Operations phase combines operations, production, maintenance, and phase-out. In comparison to the Cooper model, the ICM includes the Cooper Discovery and Scoping phases in Exploration; calls its Business Case phase Valuation; includes an Architecting phase not in Cooper; includes the Cooper Development and Test & Validation phases in Development; and extends the Cooper Launch phase to cover Operations. In comparison to the V-model, the ICM explicitly emphasizes concurrent vs. sequential engineering of requirements and solutions, establishes explicit Feasibility Rationales as pass/fail milestone criteria, and provides explicit support for a stabilized current-increment development concurrently with a rebaselining activity to prepare for appropriate and stabilized development of the next increment. Other aspects of the ICM and comparisons with process models are provided in the next charts. 9/22/2018 © 2004-2010 USC-CSSE

Different Risks Create Different Processes As can be seen by the four example paths through the Incremental Commitment Model, it 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 ICM makes it easier to visualize how different risks create different processes. In Example A, there is no need for a Valuation or Architecting activity if there is no risk that the ERP package will not support the application. Thus, an agile method such as a Scrum/Extreme Programming combination would be a good fit. There is no need for a Big Design Up Front (BDUF) because it is already present in the ERP package. In Example B, one could use a sequential waterfall or V-model if its requirements were stable, the risks were low, and low cost were more important than a rapid development. Otherwise, a concurrent risk-driven waterfall or V-model that develops and reviews a Feasibility Rationale would be more appropriate. 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 were optimistic. In such a case, it is better to go back and assure compatibility before proceeding. In Example D, it is worth pointing out that it is not necessary to proceed to the next major milestone before terminating a clearly non-viable project. 9/22/2018 © 2004-2010 USC-CSSE

The Incremental Commitment Life Cycle Process The elaboration of the concurrent engineering and feasibility evaluation activities make it clearer just what is being concurrently engineered and evaluated in each phase. For example, at the Development Commitment Review, the stakeholders and specialty experts review the Life Cycle Architecture (LCA) package for the overall system and for each increment to assure themselves that it is worthwhile to commit their human, financial, or other resources to the system’s development. Charts 13 and 14 elaborate on the content of the LCA package and the Pass/Fail Feasibility Rationale used as a basis for acceptability. The next few charts provide complementary views of the Incremental Commitment Model that show further elaboration of its nature. 9/22/2018 © 2004-2010 USC-CSSE

Stakeholder Commitment Ranges vs. Phase Drivers System Size Length of Production Run System Criticality System Understanding Level Stakeholder Compatibility Personnel Capability Amount of New Modeling/Infrastructure The main point of this chart is to indicate that the relative resource commitment levels that stakeholders must furnish tend to increase with each successive phase, and that the commitments may be significant even in the early phases. The placement of the boxes is based on rough engineering judgment. They are intended to represent rough 25th and 75th percentile ranges with respect to total resource commitment (in the software area, small (<10 people) projects account for about 60% of the projects, but large (>50 people) projects account for about 60% of the resources committed [Boehm-Turner, 2004]). Factors causing resource commitment levels to be higher or lower include project size, length of production run, system criticality, system understanding level, stakeholder compatibility, personnel capability, and amount of new modeling and infrastructure capabilities needed. 9/22/2018 © 2004-2010 USC-CSSE

Spiral Growth of System Understanding, Definition, and Commitment Cumulative Level of Understanding, Cost, Time, Product and Process Detail (Risk-Driven) Progress Through Steps Evaluate alternatives, identify risks Identify objectives, constraints, alternatives Assess and mitigate risks Identify, reconcile success-critical stakeholders’ win conditions OCR3 OCR1 DCR1 ACR ACR DCR2 DCR3 Elaborate product and process The spiral model provides another view of the incremental commitment process that reflects the continuing growth of systems understanding, system definition, and resource commitment. It also emphasizes the iterative nature of the process, in that each spiral cycle involves stakeholder satisficing, risk management, concurrent problem and solution definition, and solution feasibility analysis and review at increasing levels of detail. Consistently with chart 5, the spiral view does not imply a sequential progression, but emphasizes risk-driven concurrent mini-spirals, backtracking, or skipping of spiral cycles. Chart 22 provides a more detailed view of how various concurrent change-, risk-, or opportunity-driven mini-spirals would operate. Anchor point commitment milestones Develop Feasibility Rationale With concurrent mini-spirals and backtracking 9/22/2018 © 2004-2010 USC-CSSE

Risk-Driven Scalable Spiral Model: Increment View 9/22/2018 © 2004-2010 USC-CSSE

Risk-Driven Scalable Spiral Model: Increment View 9/22/2018 © 2004-2010 USC-CSSE

Risk-Driven Scalable Spiral Model: Life Cycle View System Inception Elaboration Agile DI2 (OO&D) Rebaselining Plan-Driven DI1 Construction (A) DI1 V&V Plan-Driven DI2 Construction (A) DI2 V&V System LCA System, DI1 LCA DI2 B/L LCA DI2 LCA Changes LCA: Life Cycle Architecture IOC: Initial Operational Capability OO&D: Observe, Orient and Decide V&V: Verification and Validation DI: Development Increment B/L: Baselined 9/22/2018 © 2004-2010 USC-CSSE

Risk-Driven Scalable Spiral Model: Life Cycle View System Inception Elaboration Agile DI2 (OO&D) Rebaselining Plan-Driven DI1 Construction (A) DI1 V&V Agile DI3 (OO&D) Rebaselining Plan-Driven DI2 Construction (A) DI2 V&V Agile DI4 (OO&D) Rebaselining Plan-Driven DI3 Construction (A) DI3 V&V DI1 Trans’n DI1 Usage DI2 Trans’n DI2 Usage DI3 Trans’n DI3 Usage System LCA DI3 LCA System, DI1 LCA DI2 B/L LCA DI3 B/L LCA DI4 B/L LCA Update DI2 LCA Changes DI4 LCA . . . DI1 IOC DI3 IOC DI2 IOC LCA: Life Cycle Architecture IOC: Initial Operational Capability OO&D: Observe, Orient and Decide V&V: Verification and Validation DI: Development Increment B/L: Baselined 9/22/2018 © 2004-2010 USC-CSSE

Acquisition C4ISR Via Spiral OODA Loops Observe new/updated objectives, constraints, alternatives Usage monitoring Competition, technology, marketplace ISR Orient with respect to stakeholders priorities, feasibility, risks Risk/Opportunity analysis Business case/mission analysis Prototypes, models, simulations Operate as current system Accept new system Act on plans, specifications Keep development stabilized Change impact analysis, preparation for next cycle (mini-OODA loop) Decide on next-cycle capabilities, architecture upgrades, plans Stable specifications, COTS upgrades Development, integration, V&V, risk management plans Feasibility rationale Life Cycle Architecture Milestone for Cycle 9/22/2018 © 2004-2010 USC-CSSE

Agile Change Processing and Rebaselining Stabilized Increment-N Development Team Agile Future- Increment Rebaselining Team Future Increment Managers Change Proposers Defer some Increment-N capabilities Propose Changes Proposed changes Recommend handling in current increment Assess Changes, Propose Handling Recommend no action, provide rationale Discuss, revise, defer, or drop Negotiate change disposition Handle in current rebaseline Accept changes Formulate, analyze options in context of other changes Handle Accepted Increment-N changes Recommend deferrals to future increments Discuss, resolve deferrals to future increments Prepare for rebaselined future-increment development Rebaseline future-increment LCA packages 9/22/2018 © 2004-2010 USC-CSSE

Initial VBSE Theory: 4+1 Process – With a great deal of concurrency and backtracking 9/22/2018 © 2004-2010 USC-CSSE

Frequent Protagonist Classes Sierra Moutainbikes: Susan Swanson, new CEO Bicycle champion, MBA, 15 years’ experience Leads with goals, open agenda 9/22/2018 © 2004-2010 USC-CSSE

Annual CrossTalk Top-5 Projects Many candidate projects submitted annually Providing evidence of success, key practices Evaluated by leading software experts Top-5 published in CrossTalk DoD systems/software journal http://www.stsc.hill.af.mil/crosstalk 20 projects to date: 2002 – 2005 9/22/2018 © 2004-2010 USC-CSSE

Top-5 Use of Key Spiral Principles Year Concurrent Engineering Risk-Driven Evolutionary Growth 2002 4 3 2003 2 2004 2005 5 Total (of 20) 14 12 9/22/2018 © 2004-2010 USC-CSSE

Spiral Aspects of CrossTalk 2002 Top-5 Software Projects Degree Concurrent Requirements/ Solution Development Risk – Driven Activities Evolutionary Increment Delivery STARS Air Traffic Control * Yes HCI, Safety For multiple sites Minuteman III Messaging (HAC/RMPE) Safety Yes; block upgrades FA-18 Upgrades Not described Census Digital Imaging (DCS2000) ** No; fixed delivery date FBCB2 Army Tactical C3I 9/22/2018 © 2004-2010 USC-CSSE

Spiral Aspects of CrossTalk 2003 Top-5 Software Projects Degree Concurrent Requirements/ Solution Development Risk – Driven Activities Evolutionary Increment Delivery Defense Civilian Pay (DCPS) No; waterfall Yes For multiple organizations Tactical Data Radio (EPLRS) ** Joint Helmet- Mounted Cueing (JHMCS) * Yes; IPT-based Not described For multiple aircraft Kwajalein Radar (KMAR) For multiple radars One SAF Simulation Testbed (OTB) 9/22/2018 © 2004-2010 USC-CSSE

Spiral Aspects of CrossTalk 2004 Top-5 Software Projects Spiral Degree Concurrent Requirements/ Solution Development Risk – Driven Activities Evolutionary Increment Delivery Advanced Field Artillery (AFATDS) Initially waterfall Not described Yes; block upgrades Defense Medical Logistics (DMLSS) F-18 HOL (H1E SCS) Legacy requirements-driven COTS, display No One SAF Objectives System (OOS) ** Yes Patriot Excalibur (PEX) Yes; agile 9/22/2018 © 2004-2010 USC-CSSE

Spiral Aspects of CrossTalk 2005 Top-5 Software Projects Spiral Degree Concurrent Requirements/ Solution Development Risk – Driven Activities Evolutionary Increment Delivery Lightweight Handheld Fire Control ** Yes Marines Integrated Pay (MCTFS) Initially waterfall Not described Yes; block upgrades Near Imaging Field Towers (NIFTI) Yes; RUP based Smart Cam Virtual Cockpit (SC3DF) WARSIM Army Training 9/22/2018 © 2004-2010 USC-CSSE

Conclusions Defense and space systems undergoing transformation => Sw Intensive Systems of Systems (the transformer) Need emphasis on spiral systems engineering principles => Incremental Commitment Model (ICM) for Systems Need to integrate systems and software engineering => ICM for Sw Intensive Systems (SIS) & SIS of Systems ICM (Spiral) approach enables concurrent engineering And increased emphasis on risk (all kinds) management New systems of systems risks emerging And new mitigation approaches And applied earlier (rapid adaptation of lessons learned) CSSE is leading the field in addressing them 9/22/2018 © 2004-2010 USC-CSSE

References B. Boehm, W. Hansen, “The Spiral Model as a Tool for Evolutionary Acquisition,” Cross Talk, May 2001. B. Boehm, D. Port, “Balancing Discipline and Flexibility with the Spiral Model and MBASE,” CrossTalk, December 2001, pp. 23-28. B. Boehm et al., “Using the Win Win Spiral Model: A Case Study,” IEEE Computer, July 1998, pp. 33-44. B. Boehm, D. Port, L. Huang, and W. Brown, “Using the Spiral Model and MBASE to Generate New Acquisition Process Models: SAIV/ CAIV, and SCQAIV,” CrossTalk, January 2002, pp. 20-25. D. Reifer and B. Boehm, “A Model Contract/Subcontract Award Fee Plan for Large, Change-Intensive Software Acquisitions,” USC-CSE Technical Report, April 2003. B. Boehm, A.W. Brown, V. Basili, and R. Turner, “Spiral Acquisition of Software-Intensive Systems of Systems,” Cross Talk, May 2004, pp. 4-9. “Human-System Integration in the System Development Process: A New Look”, Report of the National Research Council of the National Acadamies, March 2007, National Academise Press (WWW.NAP.edu) MBASE web site : sunset.usc.edu/research/MBASE Spiral/EA workshops web site : www.sei.cmu.edu/cbs/spiral2000 CrossTalk articles: www.stsc.hill.af.mil/crosstalk 9/22/2018 © 2004-2010 USC-CSSE