1. University of Southern California Center for Systems and Software Engineering CS 510 Software Management and Economics Fall 2015 Barry Boehm, USC ICSM Principle 2: Incremental Commitment and Accountability

2. University of Southern California Center for Systems and Software Engineering Outline Nature of incremental commitment Failure story: Bank of America Master Net Success story: TRW Software Productivity System Alternative incremental commitment processes 8/26/2015Copyright © USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering Nature of Incremental Commitment Successful system development projects are built on a bedrock of trust Trust is built through effective commitments –Nature of commitments Premature commitments are risky –The Cones of Uncertainty –Best to commit incrementally The ICSM commitment stages –Incremental definition and development 8/26/2015Copyright © USC-CSSE3

4. University of Southern California Center for Systems and Software Engineering Nature of Commitments Watts Humphrey, 1989 The person making the commitment does so willingly. The commitment is not made lightly; that is, the work involved, the resources, and the schedule are carefully considered. There is agreement between the parties as to what is to be done, by whom, and when. The commitment is openly and publicly stated. The person responsible tries to meet the commitment, even if help is needed. Prior to the committed date, if something changes that impacts either party relative to the commitment, advance notice is given and a new commitment is negotiated. 8/26/2015Copyright © USC-CSSE4

5. University of Southern California Center for Systems and Software Engineering The Cones of Uncertainty – Need incremental definition and development Uncertainties in competition, technology, organizations, mission priorities 8/26/2015Copyright © USC-CSSE5

6. University of Southern California Center for Systems and Software Engineering ICSM Stages and Phases Stage I: Incremental system definition –Exploration Phase: Concurrently identifies and clarifies system capability needs, constraints, and candidate solution options –Valuation Phase: Analyzes alternative solutions and identifies preferred alternative –Foundations Phase: Develops management and technical foundations for the selected alternative Stage II: Incremental system development –Development Phase: Procurement, iterative detailed design and development, integration, and test of current- increment components –Production and Operations Phase: System “units” produced, integrated, and put into operations 8/26/2015Copyright © USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering 8/26/2015 The Incremental Commitment Spiral Process: Phased View Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process 7Copyright © USC-CSSE

8. University of Southern California Center for Systems and Software Engineering Outline Nature of incremental commitment Failure story: Bank of America Master Net Success story: TRW Software Productivity System Alternative incremental commitment processes 8/26/2015Copyright © USC-CSSE8

9. University of Southern California Center for Systems and Software Engineering Failure Story: Bank of America Master Net B of A Trust Management System (TMS) B of A an early leader in banking automation –Electronic check processing, 1950s-1960s Lost automation leadership by late 1970s –CEO agenda to “leapfrog into 1990s” Tried $6M in-house next-generation TMS development –Extensive next-generation public relations push –Results: missing capabilities; lack of scalability –Embarrassing with respect to public relations push CEO appointed new TMS department head –Modernize or discontinue TMS business 8/26/2015Copyright © USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering B of A TMS Second Try: Master Net Develop full-capability requirements –Union of customer wish lists: 3.5 million lines of code –$22 million budget; 9 month full operational capability Look for best external TMS developer –Premier Systems: several successful small-bank TMSs –Lack of B of A system engineers to analyze proposals Contracted with Premier Systems March 1984 –$22 million; full commitment to deliver by December 1984 December 1984: 100 programmers on-board –Far from complete, even for demonstrations –Many key stakeholder win condition conflicts 8/26/2015Copyright © USC-CSSE10

11. University of Southern California Center for Systems and Software Engineering 8/26/2015 Copyright © USC- CSSE 11 ICSM Principles Counterexample: Bank of America Master Net

12. University of Southern California Center for Systems and Software Engineering B of A/Premier TMS Development, 1985-88 Serious corporate image problem if discontinued –Added budget, developed 1985-86 schedule Organized major 1986 demonstration of working capabilities –Could not demonstrate performance scalability –Still far from complete; many performance problems by end 1986 1987: Full-commitment TMS cutover to Master Net –Serious performance, reliability problems, system crashes –Premier Prime computer vs. BofA IBM interoperability problems –Clients dropping off: 800->700 accounts; $38B->$34B assets May 1988: Transfer of TMS business to other banks –Final 50-monthproject schedule, $80 million cost 8/26/2015Copyright © USC-CSSE12

13. University of Southern California Center for Systems and Software Engineering 8/26/2015 Principles Trump Diagrams: Master Net 1.Stakeholder value-based guidance –Overconcern with Voice of Customer: 3.5 MSLOC of rqts. –No concern with maintainers, interoperators: Prime vs. IBM 2.Incremental commitment and accountability –Total commitment to infeasible budget and schedule –No contract award fees or penalties for under/overruns 3.Concurrent multidiscipline engineering –No prioritization of features for incremental development –No prototyping of operational scenarios and usage 4.Evidence and risk-driven decisions –No evaluation of Premier Systems scalability, performance –No evidence of ability to satisfy budgets and schedules 13Copyright © USC-CSSE

14. University of Southern California Center for Systems and Software Engineering Outline Nature of incremental commitment Failure story: Bank of America Master Net Success story: TRW Software Productivity System Alternative incremental commitment processes 8/26/2015Copyright © USC-CSSE14

15. University of Southern California Center for Systems and Software Engineering Success story: TRW-SPS, 1980-82 Software Productivity System Major 1980 TRW corporate productivity initiative –Need business case and plan COCOMO-based business case led to spiral plan –Use of productivity opportunity tree –Combination of technical, management, personnel initiatives First actual implementation of spiral model 1980-82 –Summaries of Exploration, Valuation, Foundations phases Results consistently improved productivity by factor of 2 –1982 International Conference on Software Engineering Best Paper 8/26/2015Copyright © USC-CSSE15

16. University of Southern California Center for Systems and Software Engineering TRW - SPS, Exploration Phase 8/26/2015Copyright © USC-CSSE16

17. University of Southern California Center for Systems and Software Engineering 8/26/201517 Legacy System Repurposing Eliminate Tasks Eliminate Scrap, Rework Staffing, Incentivizing, Teambuilding Kaizen (continuous improvement) Work and Oversight Streamlining Collaboration Technology Early Risk and Defect Elimination Modularity Around Sources of Change Incremental, Evolutionary Development Risk-Based Prototyping Satisficing vs. Optimizing Performance Value-Based Capability Prioritization Composable Components,Services, COTS Productivity Improvements and Tradeoffs Get the Best from People Make Tasks More Efficient Simplify Products (KISS) Reuse Components Facilities, Support Services Tools and Automation Lean and Agile Methods Evidence-Based Decision Gates Domain Engineering and Architecture Task Automation Model-Based Product Generation Value-Based, Agile Process Maturity Productivity Improvement Framework Reduce Operations, Support Costs Streamline Supply Chain Design for Maintainability, Evolvability Automate Operations Elements Anticipate, Prepare for Change Value- and Architecture-Based Tradeoffs and Balancing Copyright © USC-CSSE

18. University of Southern California Center for Systems and Software Engineering 18 Costing Insights: COCOMO II Productivity Ranges Productivity Range 11.21.41.61.822.22.4 Product Complexity (CPLX) Analyst Capability (ACAP) Programmer Capability (PCAP) Time Constraint (TIME) Personnel Continuity (PCON) Required Software Reliability (RELY) Documentation Match to Life Cycle Needs (DOCU) Multi-Site Development (SITE) Applications Experience (AEXP) Platform Volatility (PVOL) Use of Software Tools (TOOL) Storage Constraint (STOR) Process Maturity (PMAT) Language and Tools Experience (LTEX) Required Development Schedule (SCED) Data Base Size (DATA) Platform Experience (PEXP) Architecture and Risk Resolution (RESL) Precedentedness (PREC) Develop for Reuse (RUSE) Team Cohesion (TEAM) Development Flexibility (FLEX) Scale Factor Ranges: 10, 100, 1000 KSLOC 8/26/2015Copyright © USC-CSSE Staffing Teambuilding Continuous Improvement

19. University of Southern California Center for Systems and Software Engineering TRW-SPS, Validation Phase 8/26/2015Copyright © USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering TRW-SPS, Foundations Phase 8/26/2015Copyright © USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering Outline Nature of incremental commitment Failure story: Bank of America Master Net Success story: TRW Software Productivity System Alternative incremental commitment processes 8/26/2015Copyright © USC-CSSE21

22. University of Southern California Center for Systems and Software Engineering Incremental and Evolutionary Acquisition Models 228/26/2015 TypeExamplesProsCons Prespecified Sequential Platform base plus Pre-Planned Product Improvements Prespecifiable full- capability requirements, scalability when stable Emergent requirements or rapid change, architecture breakers Evolutionary Sequential Small: Agile Larger: Rapid fielding Adaptability to change, need for usage feedback Easiest-first; late, costly fixes; SysE time gaps Slow for large systems Evolutionary Overlapped (DoDI 5000.02) Stable development; Maturing technology Mature technology upgrades Emergent requirements or rapid change; SysE time gaps Evolutionary Concurrent (ICSM) Rapid, emergent development Systems of systems Emergent requirements or rapid change, SysE continuity Overkill on small or highly stable systems Time phasing terms: Scoping; Architecting; Developing; Producing; Operating (SADPO) Prespecified Sequential: SA; DPO1; DPO2; DPO3; … Evolutionary Sequential: SADPO1; SADPO2; SADPO3; … Evolutionary Overlapped: SADPO1; SADPO2; SADPO3; … Evolutionary Concurrent: SA; D1 ; PO1… SA2; D2 ; PO2… SA3; D3; PO3 … Copyright © USC-CSSE

23. University of Southern California Center for Systems and Software Engineering Incremental Process Decision Table 8/26/2015Copyright © USC-CSSE23

24. University of Southern California Center for Systems and Software Engineering 8/26/2015 Risk-Driven Scalable Spiral Model: Increment View For each level of systems-of-interest Agile Rebaselining for Future Increments Short, Stabilized Development of Increment N Verification and Validation (V&V) of Increment N Deferrals ArtifactsConcerns Rapid Change High Assurance Future Increment Baselines Increment N Transition/ Operations and Maintenance Future V&V Resources Increment N Baseline Current V&V Resources Unforeseeable Change (Adapt) Short Development Increments Foreseeable Change (Plan) Stable Development Increments Continuous V&V 24Copyright © USC-CSSE

25. University of Southern California Center for Systems and Software Engineering Agile Change Processing and Rebaselining 25 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 Foundations 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 Copyright © USC-CSSE8/26/2015

26. University of Southern California Center for Systems and Software Engineering 8/26/2015 ICSM as Risk-Driven Process Generator Stage I of the ICSM has 3 decision nodes with 4 options/node –Culminating with incremental development in Stage II –Some options involve go-backs –Results in many possible process paths Can use ICSM risk patterns to generate frequently- used processes –With confidence that they fit the situation Can generally determine this in the Exploration phase –Develop as proposed plan with risk-based evidence at VCR milestone –Adjustable in later phases 26Copyright © USC-CSSE

27. University of Southern California Center for Systems and Software Engineering 8/26/2015Copyright © USC-CSSE 27 Different Risk Patterns Yield Different Processes 27Copyright © USC-CSSE

28. University of Southern California Center for Systems and Software Engineering 8/26/2015 The ICSM Process Decision Table: Key Decision Inputs Product and project size and complexity Requirements volatility Mission criticality Nature of Non-Developmental/COTS Item support –Commercial, open-source, reused components Organizational and Personnel Capability 28Copyright © USC-CSSE

29. University of Southern California Center for Systems and Software Engineering 8/26/2015 The ICSM Process Decision Table: Key Decision Outputs Key Stage I activities: incremental definition Key Stage II activities: incremental development and operations Suggested calendar time per build, per deliverable increment 29Copyright © USC-CSSE

30. University of Southern California Center for Systems and Software Engineering 8/26/2015 Common Risk-Driven Special Cases of the ICSM (Cases 1-4) Case 1: Use NDI Example: Small accounting system Size, Complexity: Size variable, complexity low Typical Change Rate/Month: Negligible Criticality: n/a NDI Support: Complete Organizational Personnel Capability: NDI-experienced (medium) Key Stage I Activities (Incremental Definition): Acquire NDI Key Stage II Activities (Incremental Development/Operations): Use NDI Time/Build: n/a Time/Increment: Vendor-driven Case 2: Agile Example: E-services Size, Complexity: Low Typical Change Rate/Month: 1-30% Criticality: Low to medium NDI Support: Good, in place Organizational Personnel Capability: Agile-ready, medium-high experience Key Stage I Activities (Incremental Definition): Skip Valuation and Architecting phases Key Stage II Activities (Incremental Development/Operations): Scrum plus agile methods of choice Time/Build: <= 1 day Time/Increment: 2-6 weeks Case 3: Architected Agile Example: Business data processing Size, Complexity: Medium Typical Change Rate/Month: 1-10 % Criticality: Medium to high NDI Support: Good, most in place Organizational Personnel Capability: Agile-ready, medium to high experience Key Stage I Activities (Incremental Definition): Combine Valuation, Architecting phases. Complete NDI preparation. Key Stage II Activities (Incremental Development/Operations): Architecture-based Scrum of Scrums Time/Build: 2-4 weeks Time/Increment: 2-6 months Case 4: Formal Methods Example: Security kernel; Safety-critical LSI chip Size, Complexity: Low Typical Change Rate/Month: 0.3% Criticality: Extra high NDI Support: None Organizational Personnel Capability: Strong formal methods experience Key Stage I Activities (Incremental Definition): Precise formal specification Key Stage II Activities (Incremental Development/Operations): Formally-based programming language; formal verification Time/Build: 1-5 days Time/Increment: 1-4 weeks 30Copyright © USC-CSSE

31. University of Southern California Center for Systems and Software Engineering 8/26/2015 Common Risk-Driven Special Cases of the ICSM (Cases 5-8) Case 5: Hardware with Embedded Software Example: Multi-sensor control device Size, Complexity: Medium Typical Change Rate/Month: 0.3 - 1 % Criticality: Medium to very high NDI Support: Good, in place Organizational Personnel Capability: Experienced, medium-high Key Stage I Activities (Incremental Definition): Concurrent hardware/software engineering. CDR-level ICSM DCR Key Stage II Activities (Incremental Development/Operations): IOC development, LRIP, FRP. Concurrent version N+1 engineering Time/Build: Software 1-5 days Time/Increment: Market-driven Case 6: Indivisible IOC Example: Complete vehicle platform Size, Complexity: Medium to high Typical Change Rate/Month: 0.3 – 1% Criticality: High to very high NDI Support: Some in place Organizational Personnel Capability: Experienced, medium to high Key Stage I Activities (Incremental Definition): Determine minimum- IOC likely, conservative cost. Add deferrable software features as risk reserve Key Stage II Activities (Incremental Development/Operations): Drop deferrable features to meet conservative cost. Strong award free for features not dropped. Time/Build: Software: 2-6 weeks Time/Increment: Platform: 6-18 months Case 7: NDI-Intensive Example: Supply chain management Size, Complexity: Medium to high Typical Change Rate/Month: 0.3 – 3% Criticality: Medium to very high NDI Support: NDI-driven architecture Organizational Personnel Capability: NDI-experienced, medium to high Key Stage I Activities (Incremental Definition): Thorough NDI-suite life cycle cost-benefit analysis, selection, concurrent requirements/architecture definition Key Stage II Activities (Incremental Development/Operations): Pro- active NDI evolution influencing, NDI upgrade synchronization Time/Build: Software: 1-4 weeks Time/Increment: Systems: 6-18 months Case 8: Hybrid Agile/Plan-Driven System Example: C4ISR system Size, Complexity: Medium to very high Typical Change Rate/Month: Mixed parts; 1-10% Criticality: Mixed parts; Medium to very high NDI Support: Mixed parts Organizational Personnel Capability: Mixed parts Key Stage I Activities (Incremental Definition): Full ICSM, encapsulated agile in high change, low-medium criticality parts (Often HMI, external interfaces) Key Stage II Activities (Incremental Development/Operations): Full ICSM, three-team incremental development, concurrent V&V, next- increment rebaselining Time/Build: 1-2 months Time/Increment: 9-18 months 31Copyright © USC-CSSE

32. University of Southern California Center for Systems and Software Engineering 8/26/2015 Common Risk-Driven Special Cases of the ICSM (Cases 9-11) Case 9: Multi-Owner System of Systems Example: Net-centric military operations; Metro crisis management Size, Complexity: Very high Typical Change Rate/Month: Mixed parts; 1-10 % Criticality: Very high NDI Support: Many NDIs, some in place Organizational Personnel Capability: Related experience, medium to high Key Stage I Activities (Incremental Definition): Full ICSM; extensive multi-owner team building, negotiation Key Stage II Activities (Incremental Development/Operations): Full ICSM; large ongoing system/software engineering effort Time/Build: 2-4 months Time/Increment: 18-24 months Case 10: Family of Systems Example: Medical device product line Size, Complexity: Medium to very high Typical Change Rate/Month: 1-3% Criticality: Medium to very high NDI Support: Some in place Organizational Personnel Capability: Related experience, medium to high Key Stage I Activities (Incremental Definition): Skip Valuation and Architecting phases Key Stage II Activities (Incremental Development/Operations): Scrum plus agile methods of choice Time/Build: 1-2 months Time/Increment: 9-18 months Case 11: Brownfield Example: Incremental legacy phaseout Size, Complexity: High to very high Typical Change Rate/Month: 0.3-3% Criticality: Medium-high NDI Support: NDI as legacy replacement Organizational Personnel Capability: Legacy re-engineering Key Stage I Activities (Incremental Definition): Re-engineer/refactor legacy into services Key Stage II Activities (Incremental Development/Operations): Incremental legacy phaseout Time/Build: 2-6 weeks/refactor Time/Increment: 2-6 months 32Copyright © USC-CSSE