1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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)

8. 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

9. 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

10. 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

11. 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

12. 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

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

14. 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

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

16. 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

17. 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)

18. 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

19. 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

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

21. 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

22. 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

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

24. 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.

25. 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

26. 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”

27. 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

28. 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

29. 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

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

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

32. 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

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

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

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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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 –http://www.stsc.hill.af.mil/crosstalkhttp://www.stsc.hill.af.mil/crosstalk –20 projects to date: 2002 – 2005

43. 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 2002433 2003432 2004222 2005445 Total (of 20)1412

44. 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

45. 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

46. 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

47. 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