1. University of Southern California Center for Systems and Software Engineering Barry Boehm, USC CSSE Annual Research Review February 12, 2007 Collaborative Design Workshop Overview

2. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE2 Outline Future trends in software-intensive systems Proposed NSF Science of Design projects –Medvidovic/Golubchik/Gupta HW-SW Design –Boehm/Majchrzak/More Collaborative Design Interdisciplinary Collaborative Design –Process context: Incremental Commitment Model –Role of behavioral science concepts Boundary objects, transactive memory, guided discovery, experiential learning –Boundary objects in value-based design Lunch discussions –Your best examples of boundary objects and usage –What you’d most like to be able to do with boundary objects

3. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE3 Future Trends in Software-Intensive Systems Human-intensive, emergent –Evolutionary, concurrent requirements and design process Rapid change; partly foreseeable –Service-oriented framework for foreseeable aspects –Encapsulated services for unforeseeable aspects Rapidly-formed, evolving global coalitions –Friedman: The World is Flat –SEI: Ultra Large Scale Systems –Need rapid and effective teambuilding

4. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE4 Proposed NSF Science of Design Projects Medvidovic/Golubchik/Gupta: Hardware- Software Design –Details tbd Boehm/Majchrzak/More: Interdisciplinary Collaborative Design –Integrating value-based design with behavioral science concepts Boundary objects, transactive memory, guided discovery, reciprocal learning –Apply to experimental, observational testbeds IT Services Lab, industrial design, systems of systems

5. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE5 The Incremental Commitment Model Principles Phases and activity levels Details later

6. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE6 Incremental Commitment Model Principles 1.Success-critical stakeholder satisficing 2.Incremental growth of system definition and stakeholder commitment 3,4.Concurrent, iterative system definition and development cycles Cycles can be viewed as sequential concurrently-performed phases or spiral growth of system definition 5.Risk-based activity levels and anchor point commitment milestones

7. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE7 Human-System Integration Levels of Activity: Incremental Commitment Model (Part 1 of 2)

8. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE8 Human-System Integration Levels of Activity: Incremental Commitment Model (Part 2 of 2)

9. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE9 Primary Focus of HSI Activity Categories - I – HSI activities often span multiple categories

10. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE10 Primary Focus of HSI Activity Categories - II – HSI activities often span multiple categories

11. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE11 Primary Focus of HSI Activity Categories - III – HSI activities often span multiple categories

12. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE12 Outline Future trends in software-intensive systems Proposed NSF Science of Design projects –Medvidovic/Golubchik/Gupta HW-SW Design –Boehm/Majchrzak/More Collaborative Design Interdisciplinary Collaborative Design –Process context: Incremental Commitment Model –Role of behavioral science concepts Boundary objects, transactive memory, guided discovery, experiential learning –Boundary objects in value-based design Lunch discussions –Your best examples of boundary objects and usage –What you’d most like to be able to do with boundary objects

13. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE13 Boundary Objects: Ann and Phil (TBD) Nature of boundary objects –Star, Carlile, … Employment of boundary objects –Guided discovery, … Examples of usage –TBD Research approach –TBD

14. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE14 Value-Based Boundary Objects Context: Incremental Commitment Model –Value-based reinterpretation of spiral model Some value-based boundary objects –Spiderweb diagram –EasyWinWin tool –Simplifiers and complicators –Benefits Chain Experimental research example –WikiWinWin tool

15. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE15 Incremental Commitment in Gambling Total Commitment: Roulette –Put your chips on a number –Wait and see if you win or lose Incremental Commitment: Poker, Blackjack –Put some chips in –See your cards, some of others’ cards –Decide whether, how much to commit to proceed

16. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE16 Incremental Commitment Common System/Software stakeholder commitment points –Defined in concert with Government, industry organizations –Initially coordinated with Rational’s Unified Software Development Process Exploration Commitment Review (ECR) –Stakeholders’ commitment to support initial system scoping –Like dating Validation Commitment Review (VCR) –Stakeholders’ commitment to support system concept definition and investment analysis –Like going steady Architecting Commitment Review (ACR) –Stakeholders’ commitment to support system architecting –Like getting engaged Development Commitment Review (DCR) –Stakeholders’ commitment to support system development –Like getting married Incremental Operational Capabilities (OCs) –Stakeholders’ commitment to support operations –Like having children In Life: Anchor Point Milestones

17. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE17 The Incremental Commitment Life Cycle Process: Overview

18. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE18 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 Serves as basis for stakeholders’ commitment to proceed

19. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE19 Different Risks Create Different Processes

20. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE20 The Incremental Commitment Life Cycle Process

21. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE21 Risk-Driven Scalable Spiral Model: Increment View

22. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE22 Risk-Driven Scalable Spiral Model: Increment View

23. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE23 Value-Based Boundary Objects Context: Incremental Commitment Model –Value-based reinterpretation of spiral model Some value-based boundary objects –Spiderweb diagram –EasyWinWin tool –Simplifiers and complicators –Benefits Chain Experimental research example –WikiWinWin tool

24. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE24 The Model-Clash Spider Web: Master Net - Stakeholder value propositions (win conditions)

25. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE25 EasyWinWin OnLine Negotiation Steps

26. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE26 Red cells indicate lack of consensus. Oral discussion of cell graph reveals unshared information, unnoticed assumptions, hidden issues, constraints, etc.

27. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE27 S&C Subdomain (General) 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20, 31, 32, 35, 36, 37, 39 Type of Application Simple Block Diagram Examples (project nos.) Deveoper Simplifiers Developer Complicators Multimedia Archive  Use standard query languages  Use standard or COTS search engine  Uniform media formats  Natural language processing  Automated cataloging or indexing  Digitizing large archives  Digitizing complex or fragile artifacts  Automated annotation/descrip tion/ or meanings to digital assets  Integration of legacy systems MM asset info Catalog MM Archive query MM asset update query update notification  Rapid access to large Archives  Access to heterogeneous media collections

28. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE28 DMR/BRA* Results Chain INITIATIVE OUTCOME Implement a new order entry system ASSUMPTION Contribution Order to delivery time is an important buying criterion Reduce time to process order Reduced order processing cycle (intermediate outcome) Increased sales Reduce time to deliver product *DMR Consulting Group’s Benefits Realization Approach

29. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE29 Expanded Order Processing System Benefits Chain

30. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE30 Outline Future trends in software-intensive systems Proposed NSF Science of Design projects –Medvidovic/Golubchik/Gupta HW-SW Design –Boehm/Majchrzak/More Collaborative Design Interdisciplinary Collaborative Design –Process context: Incremental Commitment Model –Role of behavioral science concepts Boundary objects, transactive memory, guided discovery, experiential learning –Boundary objects in value-based design Lunch discussions –Your best examples of boundary objects and usage –What you’d most like to be able to do with boundary objects

31. University of Southern California Center for Systems and Software Engineering Backup Charts

32. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE32 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

33. University of Southern California Center for Systems and Software Engineering 02/12/07©Rational33 Waterfall Model Risk Profile RiskRisk Time Specifications & models Design Specifications & models Code and unit test Tested code Subsystem integration Executable subsystem Requirements analysis System integration Executable system The most critical risks are architectural: Performance (size, time, accuracy) Interface integrity System qualities (adaptability, portability, etc.)

34. University of Southern California Center for Systems and Software Engineering 02/12/07©Rational34 Conventional Software Process Time (months) Progress (% coded) 100 90 80 70 60 50 40 30 20 10 Conventional Late design breakage Integration begins Problem: Late Tangible Design Assessment Standard sequence of events:  Early and successful design review milestones  Late and severe integration trauma  Schedule slippage Design Reviews /

35. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE35 Sequential Engineering Neglects Risk $100M $50M Arch. A: Custom many cache processors Arch. B: Modified Client-Server 12 3 4 5 Response Time (sec) Original Spec After Prototyping

36. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE Spiral Model of Software Process 7

37. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE37 KPP Validation with Spiral Model Attempt to validate 1-second KPP –Architecture analysis: needs expensive custom solution –Prototype: 4-seconds OK 90% of the time Negotiate KPP ranges –2 seconds desirable –4 seconds acceptable with some 2-second special cases Benchmark client-server to validate feasibility Present solution and feasibility rationale at anchor point milestone review –Result: Acceptable solution with minimal delay

38. University of Southern California Center for Systems and Software Engineering 02/12/07©Rational38 Spiral/MBASE/Rational Life-Cycle Model RiskRisk Time Iteration 3... Construction Inception Architectural prototype Draft specifications & models Elaboration Initial executable system Refined specifications & models Final system Intermediate system Transition

39. University of Southern California Center for Systems and Software Engineering 02/12/07©Rational39 Project Results Time (months) Progress (% coded) 100 90 80 70 60 50 40 30 20 10 Conventional Late Design Breakage Demo Iterative Development Demo Final Qual Test Integration Begins Continuous Integration

40. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE40 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 Spiral Model No common life cycle milestones –Anchor Points

41. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE41 The WinWin Spiral Model 2. Identify Stakeholders’ win conditions 1. Identify next-level Stakeholders Reconcile win conditions. Establish next level objectives, constraints, alternatives 3. Evaluate product and process alternatives. Resolve Risks 4. Define next level of product and process - including partitions 5. Validate product and process definitions 6. Review, commitment7. Win-Win Extensions Original Spiral

42. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE42 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

43. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE43 (Risk-driven level of detail for each element) *WWWWWHH: Why, What, When, Who, Where, How, How Much Milestone ElementLife 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 Assurance of consistency among elements above - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Definition of System Requirements Definition of System 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 WinWin Spiral Anchor Point Milestone Content

44. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE44 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 Serves as basis for stakeholders’ commitment to proceed

45. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE45 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

46. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE46 Anchor Points and Rational USDP Phases Engineering Stage Manufacturing Stage Inception ElaborationConstructionTransition Feasibility Iterations Architecture Iterations Usable Iterations Product Releases Management REQREQ DESDES IMPIMP DEPDEP REQREQ DESDES IMPIMP DEPDEP REQREQ DESDES IMPIMP DEPDEP REQREQ DESDES IMPIMP DEPDEP LCOLCAIOC RATIONAL S o f t w a r e C o r p o r a t i o n

47. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE47 Spiral Anchor Points Enable Concurrent Engineering

48. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE48 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

49. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE49 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

50. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE50 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

51. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE51 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

52. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE52 “Spiral Model” – Example Misinterpretation From a government briefing “explaining” the spiral model Incremental, but no risk, concurrency, stakeholder satisficing Requirements Design Implement Test

53. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE53 The Incremental Commitment Life Cycle Process: Overview

54. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE54 Different Risks Create Different Processes

55. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE55 The Incremental Commitment Life Cycle Process

56. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE56 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

57. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE57 Spiral Growth of System Understanding, Definition, and Commitment With concurrent mini-spirals and backtracking ACR Progress Through Steps Assess and mitigate risks Develop Feasibility Rationale Cumulative Level of Understanding, Cost, Time, Product and Process Detail (Risk-Driven) Elaborate product and process Evaluate alternatives, identify risks DCR 3 DCR 2 OCR 1 OCR 3 DCR 1 Identify objectives, constraints, alternatives Identify, reconcile success-critical stakeholders’ win conditions Anchor point commitment milestones ACR

58. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE58 Risk-Driven Scalable Spiral Model: Increment View

59. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE59 Risk-Driven Scalable Spiral Model: Increment View

60. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE60 Risk-Driven Scalable Spiral Model: Life Cycle View System Inception System Elaboration Agile DI 2 (OO&D) Rebaselining Plan-Driven DI 1 Construction (A) DI 1 V&V Plan-Driven DI 2 Construction (A) DI 2 V&V System LCASystem, DI 1 LCADI 2 B/L LCA DI 2 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

61. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE61 Risk-Driven Scalable Spiral Model: Life Cycle View System Inception System Elaboration Agile DI 2 (OO&D) Rebaselining Plan-Driven DI 1 Construction (A) DI 1 V&V Agile DI 3 (OO&D) Rebaselining Plan-Driven DI 2 Construction (A) DI 2 V&V Agile DI 4 (OO&D) Rebaselining Plan-Driven DI 3 Construction (A) DI 3 V&V DI 1 Trans’n DI 1 Usage DI 2 Trans’n DI 2 Usage DI 3 Trans’n DI 3 Usage System LCA DI 3 LCA System, DI 1 LCADI 2 B/L LCADI 3 B/L LCADI 4 B/L LCA Update DI 2 LCA Changes DI 4 LCA... DI 1 IOC DI 3 IOC DI 2 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

62. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE62 Acquisition C4ISR Via Spiral OODA Loops Life Cycle Architecture Milestone for Cycle Decide on next-cycle capabilities, architecture upgrades, plans Stable specifications, COTS upgrades Development, integration, V&V, risk management plans Feasibility rationale Act on plans, specifications Keep development stabilized Change impact analysis, preparation for next cycle (mini- OODA loop) Orient with respect to stakeholders priorities, feasibility, risks Risk/Opportunity analysis Business case/mission analysis Prototypes, models, simulations Observe new/updated objectives, constraints, alternatives Usage monitoring Competition, technology, marketplace ISR Operate as current system Accept new system

63. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE63 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 Increment-N changes Discuss, resolve deferrals to future increments Propose Changes Discuss, revise, defer, or drop Rebaseline future-increment LCA packages Prepare for rebaselined future-increment 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

64. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE64 Initial VBSE Theory: 4+1 Process – With a great deal of concurrency and backtracking

65. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE65 Frequent Protagonist Classes Sierra Moutainbikes: Susan Swanson, new CEO – Bicycle champion, MBA, 15 years’ experience – Leads with goals, open agenda

66. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE66 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/crosstalkhttp://www.stsc.hill.af.mil/crosstalk –20 projects to date: 2002 – 2005

67. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE67 Top-5 Use of Key Spiral Principles Year Concurrent Engineering Risk-Driven Evolutionary Growth 2002433 2003432 2004222 2005445 Total (of 20)1412

68. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE68 Spiral Aspects of CrossTalk 2002 Top-5 Software Projects Spiral Degree Concurrent Requirements/ Solution Development Risk – Driven Activities Evolutionary Increment Delivery STARS Air Traffic Control *YesHCI, Safety For multiple sites Minuteman III Messaging (HAC/RMPE) *YesSafety Yes; block upgrades FA-18 Upgrades*Not describedYes Yes; block upgrades Census Digital Imaging (DCS2000) **Yes No; fixed delivery date FBCB2 Army Tactical C3I **Yes

69. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE69 Spiral Aspects of CrossTalk 2003 Top-5 Software Projects Spiral Degree Concurrent Requirements/ Solution Development Risk – Driven Activities Evolutionary Increment Delivery Defense Civilian Pay (DCPS) No; waterfallYes For multiple organization s Tactical Data Radio (EPLRS) **Yes Joint Helmet- Mounted Cueing (JHMCS) *Yes; IPT-based Not described For multiple aircraft Kwajalein Radar (KMAR) *Yes; IPT-based Not described For multiple radars One SAF Simulation Testbed (OTB) **Yes

70. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE70 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) Initially waterfall Not described Yes; block upgrades F-18 HOL (H1E SCS) Legacy requirements- driven COTS, display No One SAF Objectives System (OOS) **Yes Patriot Excalibur (PEX) **Yes; agile Not described Yes

71. University of Southern California Center for Systems and Software Engineering 02/12/07©USC-CSE71 Spiral Aspects of CrossTalk 2005 Top-5 Software Projects Spiral Degre e 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 basedYes Smart Cam Virtual Cockpit (SC3DF) **Yes WARSIM Army Training **Yes