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

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) USC-CSSE2

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) USC-CSSE Waterfall model Spiral model Iterative and Incremental model Agile model 3

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

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

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) USC-CSSE6

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

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

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

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) USC-CSSE Can be used to strengthen current schedule- or event-based reviews 10

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

University of Southern California Center for Systems and Software Engineering (c) 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

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) USC-CSSE

University of Southern California Center for Systems and Software Engineering (c) 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

University of Southern California Center for Systems and Software Engineering (c) 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

University of Southern California Center for Systems and Software Engineering (c) 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

University of Southern California Center for Systems and Software Engineering Validation Results on Process Adoption Incidents of Process Selection and Direction Changes (c) 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

University of Southern California Center for Systems and Software Engineering Top 10 Risk Categories: 1995 and 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) USC-CSSE18

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) USC-CSSE19

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

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

University of Southern California Center for Systems and Software Engineering (c) 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

University of Southern California Center for Systems and Software Engineering (c) USC-CSSE23 Early Assignments 1st Class (Done in class; DEN students – 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; 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 23

University of Southern California Center for Systems and Software Engineering (c) 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

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

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

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

University of Southern California Center for Systems and Software Engineering Success Critical Criteria for each milestone (c) 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

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) USC-CSSE29

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

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

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