University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC CSSE Annual Research Review February 12, 2007 Collaborative Design Workshop Overview

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE2 Outline Participant introductions 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

University of Southern California Center for Software Engineering C S E USC 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE4 Proposed NSF Science of Design Projects Medvidovic/Golubchik/Gupta: Architecture- Based Multilevel Modeling –Speed, power, reliability, …; gates  missions 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE5 The Incremental Commitment Model Provides context for what people from different disciplines need to do –To understand their options and their feasibility wrt. other stakeholders’ value propositions –To negotiate successful win-win agreements –To determine when and how deeply to commit resources Principles Phases and activity levels Details later

University of Southern California Center for Software Engineering C S E USC 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

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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE8 Primary Focus of HSI Activity Categories - I – HSI activities often span multiple categories

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE9 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 (ICM) –Role of behavioral science concepts Boundary objects, transactive memory, guided discovery, experiential learning –Value-based boundary objects in ICM Lunch discussions –Your best examples of boundary objects and usage –What you’d most like to be able to do with boundary objects

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE10 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 (ICM) –Role of behavioral science concepts Boundary objects, transactive memory, guided discovery, experiential learning –Value-based boundary objects in ICM Lunch discussions –Your best examples of boundary objects and usage –What you’d most like to be able to do with boundary objects

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE11 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE12 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE13 The Incremental Commitment Life Cycle Process: Overview

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE14 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE15 Different Risks Create Different Processes

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE16 Value-Based Boundary Objects Context: Incremental Commitment Model –Model and boundary objects evolved over 10 years of annual e- services projects, systems of systems support activities Some value-based boundary objects –Getting started: Spiderweb diagram –Shared vision: scenarios, stories, prototypes –Identifying added initiatives, stakeholders: Benefits Chain –Avoiding overkill: Simplifiers and complicators; cost models –Negotiating requirements: EasyWinWin tool –Understanding solutions: workflows, designs, plans Experimental research example –WikiWinWin tool

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE17 The Model-Clash Spider Web: Master Net - Stakeholder value propositions (win conditions)

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE18 The Information Paradox (Thorp) No correlation between companies’ IT investments and their market performance Field of Dreams –Build the (field; software) –and the great (players; profits) will come Need to integrate software and systems initiatives

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE19 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE20 Expanded Order Processing System Benefits Chain

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE21 Hard things for software people “If you can do queries with all those ands, ors, synonyms, data ranges, etc., it should be easy to do natural language queries.” “If you can scan the document and digitize the text, it should be easy to digitize the figures too.” Hard things for clients “It was nice that you could add this access feature, but it overly (centralizes, decentralizes) control of our intellectual property rights.” “It was nice that you could extend the system to serve the medical people, but they haven’t agreed to live with our usage guidelines.” Conflicts in Win Conditions and Expectations

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE22 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE23 EasyWinWin OnLine Negotiation Steps

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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE25 t Year 1 Year 2 Year 3 1. Empirical Analysis of Industry Use of Boundary Objects (BOs) – More, Majchrzak Analysis of current use, critical success factors, propositions, moderators. Define, prepare for pilots. Run pilots, analyze results, suggest TPPT improvements. Prepare, train for Interventions. Run Interventions, analyze results. Suggest TPPT improvements. 2. Development, Refinement of BO Usage Theory, Principles, Practices, and Tools (TPPTs) – Majchrzak, More, Boehm Use propositions, moderators, analyses to develop and refine BO TPPTs. Integrate results of pilots with respect to BO TPPTs. Develop BO TPPT improvements. Integrate results of Interventions with respect to BO TPPTs. Develop BO TPPT improvements. 3.Integrated VB/BO TPPTs - All Integrate, evaluate, refine VB/BO theory, principles, practices, and tools Broaden dissemination of results. 4. Integration of BOs into Value- Based (VB) TPPTs -Boehm, Majchrzak, More, RA’s Use propositions, moderators, analyses to create BO extension to VB TPPTs. Integrate results of pilots with respect to VB TPPTs. Develop VB TPPT improvements. Integrate results of Interventions with respect to VB TPPTs. Develop VB TPPT improvements. 5. Empirical Analysis of IT Services Use of BO’s -Boehm, Majchrzak, Koolmanojwong,Wu Analysis of current use, critical success factors, propositions, moderators. Define, prepare for pilots. Run pilots, analyze results, suggest TPPT improvements. Prepare, train for Interventions. Run Interventions, analyze results. Suggest TPPT improvements. 6. Empirical Analysis of Systems of Systems Use of BOs -Boehm, Lane, Ingold Analysis of current use, critical success factors, propositions, moderators. Define, prepare for pilots. Run pilots, analyze results, suggest TPPT improvements. Prepare, train for Interventions. Run Interventions, analyze results. Suggest TPPT improvements. NSF Science of Design Research Plan

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE26 WikiWinWin: Majchrzak Research Wikis can strongly facilitate collaboration –Low entry barrier, flexible usage “Shapers” a critical success factor –Focus on reorganizing vs. adding group knowledge –Example of a shaper: Howard 75-person software engineering group at a multi-billion dollar tech company “I spend up to two hours a day working on the wiki. Much of this time I reorganize other people’s materials, rename pages, create new links on the home page, or restructure the home page. Benefits aren’t to mean personally, but they help the group collaborate more effectively. They can find things easier”

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE27 EasyWinWin Strengths and Difficulties Strengths –Group-oriented brainstorming, prioritization –Clear progression toward win-win equilibrium Difficulties –Overly sequential progression toward win-win equilibrium –Timeconsuming group shaping Resolving duplicates, overlaps; categorizing –Outdated, unsupported infrastructure Primary tool expert graduating

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE28 WikiWinWin Approach to Team Projects Explain approach to clients Select 1-2 team members as overall shapers –Anyone can contribute to shaping Provide class lecture, developer-client tutorial Establish preconditions for use –Majchrzak teamforming session; client site visit, early shared vision interactions, concurrent prototyping plans At least initial collocated, facilitated sesssion Prestructured but modifiable areas provided –Negotiation topics, issue identification and resolution, feature prioritization, definition of terms, … –Evaluate prestructuring, flexibility effects

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE29 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

University of Southern California Center for Software Engineering C S E USC Backup Charts

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE31 Spiral Anchor Points Enable Concurrent Engineering

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE32 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE33 The Incremental Commitment Life Cycle Process

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE34 Risk-Driven Scalable Spiral Model: Increment View

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE35 Risk-Driven Scalable Spiral Model: Increment View

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE36 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE37 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE38 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE39 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE40 Initial VBSE Theory: 4+1 Process – With a great deal of concurrency and backtracking

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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE42 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 – –20 projects to date: 2002 – 2005

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE43 Top-5 Use of Key Spiral Principles Year Concurrent Engineering Risk-Driven Evolutionary Growth Total (of 20)1412

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE44 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE45 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE46 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

University of Southern California Center for Software Engineering C S E USC 02/12/07©USC-CSE47 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