1. University of Southern California Center for Systems and Software Engineering Incremental Commitment Spiral Model (ICSM) for CS 577 Barry Boehm, Supannika Koolmanojwong, USC CS 577a Lecture Fall 2015

2. University of Southern California Center for Systems and Software Engineering Outline Software Engineering Process Models ICSM Success Critical Criteria for each milestone ICSM in CSCI577 (c) 2007-2015 USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering Software Development Process Answers two primary questions –What should we do next? –How long should we do it for? Popular Models: (c) 2007-2015 USC-CSSE Waterfall model Spiral model Iterative and Incremental model Agile model 3

4. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE Waterfall Model Spiral Model Examples of Process Models 4

5. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE Iterative and Incremental Model Agile Model Examples of Process Models 5

6. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model Principles Trump Diagrams –Too easy to interpret diagrams as one-size-fits-all 1.Stakeholder value-based guidance 2.Incremental commitment and accountability. 3.Concurrent multidiscipline engineering. 4.Evidence and risk-based decisions (c) 2007-2015 USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model (ICSM) (c) 2007-2015 USC-CSSE Stakeholder value- based guidance Incremental commitment and accountability Concurrent multidiscipline engineering Evidence and risk- based decisions 4 Key Principles 7

8. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model (ICSM) (c) 2007-2015 USC-CSSE Stakeholder value-based guidance Incremental commitment and accountability Concurrent multidiscipline engineering Evidence and risk-based decisions 4 Key Principles: 8

9. University of Southern California Center for Systems and Software Engineering ICSM HSI Levels of Activity for Complex Systems 9(c) 2007-2015 USC-CSSE

10. University of Southern California Center for Systems and Software Engineering Decision Point Feasibility Evidence Descriptions 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 budgets and schedules in the plan –Generate a viable return on investment –Generate satisfactory 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 Synchronizes and stabilizes concurrent activities (c) 2007-2015 USC-CSSE Can be used to strengthen current schedule- or event-based reviews 10

11. University of Southern California Center for Systems and Software Engineering Why the Incremental Commitment Spiral Model (ICSM)? Builds on the strengths of current process models But avoids their shortfalls (c) 2007-2015 USC-CSSE = Emphasizes verification and validation + But leaves V&V until too late + evolutionary development = Risk-driven activity prioritization + Looks like one-size=fits-all process = Concurrent engineering = Stabilizes at anchor point milestones + Strong focus on software = Adaptability to unexpected change + Weak on scalability, high assurance RUP V-Model Agile Spiral 11

12. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE Team Structure Six-person, on-campus teams (augmented by DEN students) –Each artifact should have a lead producer and a co-producer –DEN students do IIV&V, Issue/Bug tracking, etc. Project Manager generally the lead for Feasibility Rationale 1. Ensures consistency among the team members’ artifacts (and documents this in the Rationale). 2. Leads the team’s development of plans for achieving the project results, and ensures that project performance tracks the plans. Teams formed and project selected by Wednesday, Sept. 9, 4:00pm –Web questionnaires should help in team formation (EF-3) Start forming teams now! –What are your skills? What roles would you prefer? –What skills does your team need? Who does them? –What projects does your team prefer? Note: Team Mixer Activity : Friday Sept. 4, After Class, E-Quad 12

13. University of Southern California Center for Systems and Software Engineering 577 Project Roles Roles – 577a –Project Manager –Operational Concept Engineer –Requirements Engineer –Prototyper –Software Architect –Life Cycle Plan –Feasibility Analyst –IIV&V –Quality Focal Point Roles – 577b –Or 577a for 1- semester projects –Implementer –Tester –Trainer 13(c) 2007-2015 USC-CSSE

14. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE14 Timelines: Fall 2015 Wed. Sept. 9: Teams formed; projects selected; Fri. Sept 11: 1:00 - 2:00 pm Win-Win negotiation Training for Clients (SAL322) 2:00 - 3:20 pm CS 577a class Session with clients (OHE122) Sept 14-16: Site visit During the semester: Sept. 16 – Dec. 11 Intermediate consultation, prototype reviews, WinWin negotiation, scheduled weekly meetings with team, prototype evaluations, on-campus win-win negotiation participation & off campus follow up, Identify other success-critical stakeholders Oct. 16 – 18: FCR ARB meetings Nov. 30, Dec 1,4: DCR ARB meetings Dec. 11: Submit Client evaluation form DCR: Development Commitment Review; FCR: Foundations Commitment Review; VCR: Valuation Commitment Review

15. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE15 Dec. 11, 2015…Jan. 11 to Feb.5: Work with [parts of] teams: –Rebaseline prototype, prioritize requirements –Plan for CS 577b specifics, including transition strategy, key risk items –Participate in ARB review Feb 6 to April 22: Scheduled Weekly Meetings with Teams to: –Discuss status and plans –Provide access to key transition people for strategy and readiness discussions Mar 14 to 18: Core Capability Drivethrough (Clients exercise systems) Apr 11 - Apr 15: Project Transition Readiness Reviews Apr 18: Installation and Transition –Install Product –Execute Transition Plan Apr 29: Operational Commitment Review for Initial Operational Capability May 3: Client Evaluations Timelines: Spring 2016

16. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE Primary CS577 Risk Items Personnel: commitment; compatibility; ease of communication; skills (management, Web/Java, Salesforce, NoSQL, data compression, …) Schedule: project scope; IOC content; critical- path items (COTS, platforms, reviews, …) COTS: see next chart; multi-COTS Rqts, UI: mismatch to end-user needs Performance: #bits; #bits/sec; overhead sources External tasks: Client/Operator preparation, commitment for transition 16

17. University of Southern California Center for Systems and Software Engineering Validation Results on Process Adoption Incidents of Process Selection and Direction Changes (c) 2007-2015 USC-CSSE17 #of teamsResults on Project Process Selection 8/14Selected the right process pattern from the beginning 3/14Unclear project scope ; re-select right at the end of the Exploration phase 1/14Minor changes on project scope ; right at the end of the Valuation phase 1/14Major change in Foundations phase 1/14Infeasible project scope

18. University of Southern California Center for Systems and Software Engineering Top 10 Risk Categories: 1995 and 2010 19952010 1. Personnel shortfalls 1. Customer-developer-user team cohesion 2. Schedules, budgets, process2. Personnel shortfalls 3. COTS, external components 3. Architecture complexity; quality tradeoffs 4. Requirements mismatch4. Budget and schedule constraints 5. User interface mismatch 5. COTS and other independently evolving systems 6. Architecture, performance, quality6. Lack of domain knowledge 7. Requirements changes7. Process Quality Assurance 8. Legacy software8. Requirements volatility; rapid change 9. Externally-performed tasks9. User interface mismatch 10. Straining computer science10. Requirements mismatch (c) 2007-2015 USC-CSSE18

19. University of Southern California Center for Systems and Software Engineering Primary CS577 Risk Categories (all on 1995 list) and Examples Personnel shortfalls: commitment (This is team member’s last course; only needs C to graduate); compatibility; communication problems; skill deficiencies (management, Web design, Java, Perl, CGI, data compression, …) Schedule: project scope too large for 24 weeks; IOC content; critical-path items (COTS, platforms, reviews, …) COTS: see next slide re multi-COTS Rqts, UI: mismatch to user needs (recall overdue book notices) Performance: #bits; #bits/sec; overhead sources Externally-performed tasks: Client/Operator preparation; commitment for transition effort (c) 2007-2015 USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering Top 11 - Risk distribution in CSCI577 (c) 2007-2015 USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering Comparing between risks in Fall and Spring (c) 2007-2015 USC-CSSE21

22. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE COTS and External Component Risks COTS risks: immaturity; inexperience; COTS incompatibility with application, platform, other COTS; controllability Non-commercial off-the shelf components: Open source, reuse libraries, government, universities, etc. –Qualification testing; benchmarking; inspections; reference checking; compatibility analysis 22

23. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE23 Early Assignments 1st Class (Done in class; DEN students – email or fax to DEN office [if you miss 1 st class(es), get from Class Website]: –EF-1: Basic Questionnaire : Commitment Form (5 points) submit signed version ASAP to TAs –EF-2: Academic Integrity and Copyright Agreement (5 points) submit signed version ASAP to TAs Next Wednesday 09/02 –HW-1 : Incremental Commitment Spiral Model Submit thru DEN; http://courses.uscden.nethttp://courses.uscden.net http://greenbay.usc.edu/csci577/fall2015/assignments Next Friday 09/04 –EF-3: Online "Questionnaire for CSCI 577a: Software Engineering I--Fall 2013" [on line ONLY] (5 points) Submit thru class website http://greenbay.usc.edu/csci577/fall2015/assignments 23

24. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE Individual Responsibilities Homework assignments Selected pre-class and in-class exercises –Drop lowest 1 in-class quiz Acquire Book: USC bookstore, Amazon, B&N,... –Boehm et al., ICSM Contribute to team project –Lead on one artifact; on other, co-lead –Part of Honoring commitment grade (70 points) Individual Critique –90 points, due after Development Commitment package submitted Effort reports; Review other peoples artifacts Presentation at two project reviews (ARB’s) Academic integrity! 24

25. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE ICSM HSI Levels of Activity for Complex Systems 25

26. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE26

27. University of Southern California Center for Systems and Software Engineering RUP & ICSM Anchor Points Enable Concurrent Engineering (c) 2007-2015 USC-CSSE27

28. University of Southern California Center for Systems and Software Engineering Success Critical Criteria for each milestone (c) 2007-2015 USC-CSSE Foundations Commitment Review Development Commitment Review Transition Readiness Review For at least one architecture, a system built to 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 viable business case Most major risks identified and resolved or covered by risk management plan Key stakeholders committed to support Foundations Phase For the selected architecture, a system built to the arch. will: Support the Ops Concept Satisfy the Requirements Be faithful to the Prototype(s) Be buildable within the budgets and schedules in the Plan All major risks resolved or covered by risk management plan Key stakeholders committed to support full life cycle Show value Product works as expected (or with addressable exceptions) Product will help users do job Show quality development As-Built Documentation V&V results Show sustainability Support requirements/plans Transition plan & status: training, installation, usage test Show confidence that product is/will be ready to be used 28

29. University of Southern California Center for Systems and Software Engineering Outline Software Engineering Process Models ICSM Success Critical Criteria for each milestone ICSM in CSCI577 (c) 2007-2015 USC-CSSE29

30. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE30

31. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE31

32. University of Southern California Center for Systems and Software Engineering (c) 2007-2015 USC-CSSE32