1. University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC USC-CSE Executive Workshop March 15, 2006 Processes for Human Systems Integration

2. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE2 Outline: Essential HSI Process Features Concurrent: in defining product and process; needs and solutions; development and solution; human, hardware, and software elements –Counterexample: 1-second response time requirement Risk-driven: in determining which tasks to do next and how much of each task to do –Example: COTS products’ HCI incompatibility Anchor point milestones: in bounding complexity and in synchronizing and stabilizing development Balanced with respect to plan-driven and situation- driven process Mapped onto acquisition commitment milestones Strawman workshop HSI gap analysis

3. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE3 Human-System Integration Levels of Activity - EIEIO model for relatively complex systems IRR: Inception Readiness Review; LCO: Life Cycle Objectives; LCA: Life Cycle Architecture; OC: Operational Capability. LCA N+1 is being rebaselined while OC N is being implemented and OC N-1 is being operated.

4. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE4 LCO (MS A) and LCA (MS B) Pass/Fail Criteria A system built to the given architecture will –Support the operational concept –Satisfy the requirements –Be faithful to the prototype(s) –Be buildable within the budgets and schedules in the plan –Show a viable business case –Establish key stakeholders’ commitment to proceed LCO: True for at least one architecture LCA: True for the specific life cycle architecture; All major risks resolved or covered by a risk management plan

5. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE5 $100M $50M Required Architecture: Custom; many cache processors Original Architecture: Modified Client-Server 12 3 4 5 Response Time (sec) Original Spec After Prototyping Original Cost The Cost of Unvalidated KPP’s: 15-Month Architecture Rework Delay

6. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE6 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

7. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE7 Example of Spiral HSI Risk Addressal A and B are our strongest COTS choices –But there is some chance that they have incompatible HCI’s –Probability of loss P(L) If we commit to using A and B –And we find out that users can’t live with their HCI differences –We’ll add more cost and delay delivery by at least 3 months –Size of loss S(L) We have a risk exposure of RE = P(L) * S(L)

8. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE8 How Can Risk Management Help You Deal With Risks? Buying information Risk avoidance Risk transfer Risk reduction Risk acceptance

9. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE9 Risk Management Strategies: - Buying Information Let’s spend $30K and 2 weeks prototyping the integration of A and B’s HCI’s This will buy information on the magnitude of P(L) and S(L) If RE = P(L) * S(L) is small, we’ll accept and monitor the risk If RE is large, we’ll use one/some of the other strategies

10. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE10 Other Risk Management Strategies Risk Avoidance –COTS product C is almost as good as B, and its HCI is compatible with A –Delivering on time is worth more to the customer than the small performance loss Risk Transfer –If the customer insists on using A and B, have them establish a risk reserve. –To be used to the extent that A and B have incompatible HCI’s to reconcile Risk Reduction –If we build the wrapper right now, we add cost but minimize the schedule delay Risk Acceptance –If we can solve the A and B HCI compatibility problem, we’ll have a big competitive edge on the future procurements –Let’s do this on our own money, and patent the solution

11. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE11 Each Risk Strategy is Valid in Some Situations - Determined by stakeholder value propositions - No one-size-fits-all process Risk Avoidance: COTS C Adequate Risk Transfer: COTS C not Adequate Risk Reduction: customer $, IP Risk Acceptance: developer $, IP

12. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE12 Risk-Driven Scalable Spiral Model: Increment View

13. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE13 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

14. University of Southern California Center for Software Engineering C S E USC 3/15/06©USC-CSE14

15. Strawman HSD* Gap Analysis Future HSD* NeedsCurrent HSD CapabilitiesGaps Human Systems-of-Systems Design: organization, RAAR**, scalable design and analysis methods and tools Emerging systems-level macro- ergonomics methods and tools Macro-ergonomics methods and tools maturity and scalability to systems of systems (SoS) HSD for multi-mission systems: what to make common, variable HSD for single-mission systemsPrinciples, methods, tools, training for HSD design and analysis of multi-mission systems (and SoS) HSD for rapidly-evolving, adversary-driven systems: evolvable, rapidly tailorable HSI, rapid retraining Mature methods for relatively stable HSD for single-mission systems. Emerging methods for adversary threat and vulnerability analysis, associated HSD Principles, methods, tools for designing and analyzing evolvable, rapidly tailorable HSI, rapid retraining (and for HSoSI) HSD for potential new HSI modalities: virtual collaboration, flattened organizations, human intellect augmentation, powerful data analysis HSD for current modalities. Exploratory HSD for early new modalities. Principles, methods, tools and exploratory exercise capabilities for emerging new modalities for HSI and HSoSI *HSD: Human-Systems Design **RAAR: Responsibility, authority, accountability, resources