1. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE1 Software Acquisition and Life Cycle Management CS577b, Spring 2006 Barry Boehm, USC

2. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE2 Outline Context: “The world is flat” Outsourcing principles and practices Deciding to develop or acquire –Importance of life cycle considerations Example: Leading-edge systems of systems acquisition Conclusions

3. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE3 Context: “The World is Flat” -Friedman, 2005 Information processing functions can be performed almost anywhere in the world –Low-cost global fiber-optic communications –Overnight global delivery services Significant advantages in outsourcing to low-cost suppliers –But significant risks also Competitive success involves pro-actively pursuing advantages –While keeping risks manageable

4. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE4 Example Success Patterns - e.g. Walmart, Dell Identify corporate focus and strategy –Focus on core competitive discriminators Develop value chain linking inputs to outputs and values –Eliminate non-value-adding activities –Identify which can be outsourced Select, engage outsourcing partners Monitor progress vs. plans –Adapt to changes in marketplace, technology, environment

5. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE5 Preparing for Outsourcing (I) -Gartner, 2004 Self-Awareness –Strengths, weaknesses, opportunities, threats (SWOT) Resource Management –Future vs. current allocation of resources, accountability Competences –Competitive core competencies; outsourceable competencies Organization –Multimodal: skills, operations, cross-cutting improvements

6. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE6 Preparing for Outsourcing (II) -Gartner, 2004 Roles –Less on skills; more on business processes and objectives Change Readiness –Not just more adaptive, but more pro-active Communication –Less hierarchical, open

7. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE7 Core Competencies Include Outsourcing Sourcing strategy and framework –Business strategy and Op Con, technical architecture, parts outsourced Source selection –Request for proposals; evaluation criteria, evaluation processes, selection processes Contact negotiation –Statement of work, deliverables, award fees, change adaptiveness, principled negotiation Outsourcing management –Teambuilding, expectations management, change management, progress monitoring, corrective action Success-critical stakeholder win-win

8. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE8 Outline Context: “The world is flat” Outsourcing principles and practices Deciding to develop or acquire –Importance of life cycle considerations Example: Leading-edge systems of systems acquisition Conclusions

9. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE9 Deciding to Develop or Acquire: Options CriteriaDevelopOutsourceOTS Development cost, speed** Life cycle cost* - ** Scarce staff** Non- core competency function *** Core competency function** Unique needs*** Control of evolution***

10. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE10 Life Cycle Evolution Risks: - Outsourcing or OTS Divergence of objectives –Accommodation of special needs Erosion of core competencies Continuing-change costs –COTS products: new release every 8-10 months; unsupported after 3 releases –Renegotiating supplier agreements Lack of technology scalability, evolvability

11. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE11 21 st Century Acquisition Challenges Transformational net-centric systems of systems (NCSOS) –With broad and deep supplier chains Increasingly rapid change, need for agility –Technology, competition, environment changes –Requirements emergent rather than pre-specifiable Increasing need for discipline and high assurance –Security, safety, performance, interoperability, … Increasing dependence on COTS, reused, and legacy components

12. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE12 What does a NCSOS look like?

13. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE13 Complexity of NCSOS Solution Spaces Size: 10-100M lines of software code Number of external interfaces: 30-300 Number of “Coopetitive” suppliers: 20-200 –Even more separate work locations Depth of supplier hierarchy: 6-12 levels Number of coordination groups: 20-200 –Reviews, changes, risks, requirements, architecture, standards, procedures, technologies, -ilities, integration, test, deployment, personnel, infrastructure, COTS,… –Key personnel spend 60 hours/week in meetings Unprecedentedness Emergence Rapid change

14. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE14 Rapid Change Trends Global connectivity and competition accelerate change –More ripple effects of technology, marketplace changes Increased need for agility, continuous learning –Need to balance agility and plan-driven dependability –Decline of THWADI (That’s how we’ve always done it) –Avoid technical agility, administrative THWADI Hybrid agile/plan-driven processes needed for larger systems Need for incremental processes, methods, tools, skills Need for pro-active technology, marketplace monitoring Education: Need to learn how to learn

15. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE15 Failure Mode I: Build-to-Spec Deliverables - Purchasing agent metaphor Rapid change: heavy spec change traffic, slow contract changes Plus deep supplier chain: slowdowns multiply, changes interact Plus emergent rqts: many initial specs wrong; more changes Plus build-to-spec award fee: supplier inertia Bottom line: late rework, overruns, mission shortfalls

16. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE16 Why Software Projects Fail - Overruns: 189% cost; 222% schedule; 61% of product

17. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE17 18-24 Month Development Increments Need More Concurrency

18. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE18 Failure Mode II: Sequential Document-Driven Milestones - Waterfall, V-model, MIL-STD-1521B Rqts. Emergence, COTS: freeze rqts. too early Plus document-completion progress metrics: hasty point solutions, undiscovered risks Plus rapid change: problems with Failure Mode I Bottom line: more late rework, overruns, mission shortfalls

19. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE19 $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 Hasty Specifications 15-Month Architecture Rework Delay

20. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE20 Failure Mode III: Hasty Best-of-Breed Source Selection - Overambitious startup schedule Complexity, emergence: incomplete, unvalidated system architecture, solicitation SOWs Deep, wide supplier chains: incompatible legacy solutions, COTS; critical-path modeling & simulation needs Rapid change: rapid COTS evaluation, version obsolescence –GSAW: 8-11 months/release; 3 supported releases Bottom line: serious integration problems, overruns, mission shortfalls

21. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE21 How much Architecting is Enough? - A COCOMOII Analysis Percent of Project Schedule Devoted to Initial Architecture and Risk Resolution Added Schedule Devoted to Rework (COCOMO II RESL factor) Total % Added Schedule 10000 KSLOC 100 KSLOC 10 KSLOC Sweet Spot Sweet Spot Drivers: Rapid Change: leftward High Assurance: rightward

22. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE22 Failure Mode IV: Incremental Document-Driven Development - Risk-insensitive “spirals”; ambitious increment schedules High assurance of –ilities: deferral to later increments Complex NCSOS: early-increment architecture inadequate for later-increment –ilities. Rapid change: destabilization of ambitious increment schedules; increment completion delays; next increment destabilized Bottom line: serious security, safety, scalability problems; destabilized development; more rework, overruns, shortfalls

23. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE23 Conclusions So Far 20 th century contracting practices have many failure modes for 21 st century NCSOS –High likelihood of serious overruns, mission shortfalls –Still good for 20 th century type acquisitions Purchasing agent metaphors a poor match to NCSOS acquisition –A better metaphor is C4ISR –Acquirers need to operate in OODA loops Observe, Orient, Decide, Act New acquisition policies, processes, and practices needed –Empower acquisition corps to deal with NCSOS challenges –Being worked out in various programs –Example provided next

24. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE24 Emerging Scalable Spiral Process - For 21 st century systems engineering and acquisition The C4ISR Metaphor for NCSOS Acquisition –Role of OODA loops –Example: Internet Spiral –Example: FCS Win Win Spiral Model Risk-Driven Scalable Spiral Model –Increment view –Life-cycle view –Role of anchor point milestones Acquisition management implications People management implications

25. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE25 Acquisition C4ISR Via Spiral OODA Loops – Example: ARPANet/Internet Spiral 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

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

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

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

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

30. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE30 Acquisition Management Implications - I 20 th century build-to-spec contracting practices usable in part –Good fit for stabilized-increments team –But not for rebaselining, V&V teams Time & materials or equivalent Award fee based on cost/effectiveness These apply all the way down the supplier chain Need top-level award fee for cost-effective team balancing –No stable distribution of effort

31. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE31 Acquisition Management Implications - II Don’t skimp on system definition phases –But avoid analysis-paralysis –Use Feasibility evidence generation as progress metric Use more evidence-based source-selection processes –Competitive exercise as proof of capability –Preceded by multistage downselect Use Schedule/Cost as Independent Variable processes –Prioritized features as dependent variable Top priority: transformational empowerment of acquisition corps –Education, mentoring, tools, techniques

32. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE32 Conclusions 20 th century acquisition practices inadequate to address 21 st century system acquisition challenges –Net-centric systems of systems, emergent requirements, rapid change, high assurance Risk-driven Scalable Spiral Process provides framework for coping with 21 st century challenges –Stabilized increments using 20 th century practices –New practices for agile rebaselining, thorough V&V Transformational empowerment of acquisition corps a top priority –Education, mentoring, tools, techniques

33. University of Southern California Center for Software Engineering C S E USC 3/8/06©USC-CSE33 B. Boehm, R. Turner, Balancing Agility and Discipline, Addison Wesley, 2004. B. Boehm, W. Hansen, “The Spiral Model as a Tool for Evolutionary Acquisition,” Cross Talk, May 2001. B. Boehm, D. Port, “Balancing Discipline and Flexibility with the Spiral Model and MBASE,” CrossTalk, December 2001, pp. 23-28. B. Boehm, D. Port, L. Huang, and W. Brown, “Using the Spiral Model and MBASE to Generate New Acquisition Process Models: SAIV/ CAIV, and SCQAIV,” CrossTalk, January 2002, pp. 20-25. D. Reifer and B. Boehm, “A Model Contract/Subcontract Award Fee Plan for Large, Change-Intensive Software Acquisitions,” USC-CSE Technical Report, April 2003. B. Boehm, A.W. Brown, V. Basili, and R. Turner, “Spiral Acquisition of Software- Intensive Systems of Systems,” Cross Talk, May 2004, pp. 4-9. B. Boehm, “The Future of Software and Systems Engineering Processes,” Tech Report USC-CSE-TR-507, June 2005. USC-CSE web site : sunset.usc.edu Agile workshops web site : www.cse.usc.edu/events/2004/arr CrossTalk articles: www.stsc.hill.af.mil/crosstalk References