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

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

3. University of Southern California Center for Systems and Software Engineering Software Development Process Or Software Development Life Cycle The actual set of activities performed within an organization Popular Models: (c) 2007-2013 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-2013 USC-CSSE Waterfall Model Spiral Model Examples of Process Model 4

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

6. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model The Four ICSM Principles –Stakeholder value-based system definition and evolution. –Incremental commitment and accountability. –Concurrent hardware-peopleware-software system definition and development. –Evidence and risk-based decision-making. (c) 2007-2013 USC-CSSE6

7. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model (ICSM) (c) 2007-2013 USC-CSSE Stakeholder value- based system definition and evolution Incremental commitment and accountability Concurrent system and software definition and development Evidence and risk- based decision making 4 Key Principles 7

8. University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model (ICSM) (c) 2007-2013 USC-CSSE Stakeholder value-based system definition and evolution Incremental commitment and accountability Concurrent system and software definition and development Evidence and risk-based decision making 4 Key Principles: 8

9. University of Southern California Center for Systems and Software Engineering Different Risks/Opportunities Yield Different Processes Architected Agile E.g. Business data processing Use Single NDI E.g. Accounting System NDI-Intensive E.g. Supply Chain Management Services-Intensive E.g. Community Services With addressable risk(s), the project moves on the next phase With provided architecture and functionalities from NDI, the team could spend close to no effort in Valuation and Foundations phase With provided architecture and functionalities from NDI, the team could spend close to no effort in Valuation and Foundations phase The team spends more effort in assessing NDI(s) and their interoperability, enter Operation phase sooner Although the patterns look similar, NDI and services have different risks Although the patterns look similar, NDI and services have different risks (c) 2007-2013 USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering Why the Incremental Commitment Spiral Model (ICSM)? A new process model framework that is developed to build on the strengths of current process models (c) 2007-2013 USC-CSSE = Early verification and validation + Explicit emphasis on concurrent engineering + evolutionary development = Risk-driven activity prioritization + Explicit definition of risk-based decision points and criteria = Concurrent engineering = stabilizes at anchor point milestones + Integrated hardware-software-human factors = Adaptability to unexpected change + Addresses scalability, high assurance RUP V-Model Agile Spiral 10

11. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 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. 10, 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 : Monday Sept. 9, After Class, E-Quad 11

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 –Implementer –Tester –Trainer 12

13. University of Southern California Center for Systems and Software Engineering ICSM HSI Levels of Activity for Complex Systems 13

14. University of Southern California Center for Systems and Software Engineering 8/22/2014 (c) 2007-2014 USC-CSSE14 Timelines: Fall 2014 Wed. Sept. 10: Teams formed; projects selected; Fri. Sept 12: 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 15-17: Site visit During the semester: Sept. 17 – Dec. 12 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. 13 – 15: FCR ARB meetings Dec 1,2, 5: DCR ARB meetings Dec. 12: 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 8/22/2014 (c) 2007-2014 USC-CSSE15 Dec. 12, 2012…Jan. 12 to Feb.6: 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 7 to April 24: Scheduled Weekly Meetings with Teams to: –Discuss status and plans –Provide access to key transition people for strategy and readiness discussions Mar 16 to 20: Core Capability Drivethrough (Clients exercise systems) Apr 13 - Apr 17: Project Transition Readiness Reviews Apr 20: Installation and Transition –Install Product –Execute Transition Plan May 1: Operational Commitment Review for Initial Operational Capability May 5: Client Evaluations Timelines: Spring 2015

16. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC-CSSE Primary CS577 Risk Items Personnel: commitment; compatibility; ease of communication; skills (management, Web/Java, Perl, CGI, 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 ©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 ©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 ©USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering Top 11 - Risk distribution in CSCI577 ©USC-CSSE20

21. University of Southern California Center for Systems and Software Engineering Comparing between risks in Fall and Spring ©USC-CSSE21

22. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 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-2014 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 Monday: Labor Day – No Class Next Wednesday 09/03 –PC-1 : Incremental Commitment Spiral Model Submit thru DEN; http://courses.uscden.nethttp://courses.uscden.net if no DEN account, submit printout before class at SAL 329 before 12pm http://greenbay.usc.edu/csci577/fall2014/assignments Next Friday 09/05 –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/fall2014/assignments 23

24. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 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., Software Cost Estimation With COCOMOII Contribute to team project –Lead on one artifact; on other, co-lead –Part of Honoring commitment grade (70 points) Individual Critique –100 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-2013 USC-CSSE ICSM HSI Levels of Activity for Complex Systems 25

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

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

28. University of Southern California Center for Systems and Software Engineering Success Critical Criteria for each milestone (c) 2007-2013 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 ICSM-Sw & P 3 S Invariants and Variants (c) 2007-2013 USC-CSSE 1. Use of particular success, process, product, or property models. 2. Choice of process or product representation. 3. Degree of detail of process, product, property, or success modeling. 4. Number of risk-driven cycles or builds between anchor points. 5. Mapping of activities onto Exploration, Valuation, Foundations, Construction, Transition phases. 6. Mapping of staff levels onto activities. 1. Defining and sustaining a stakeholder win-win relationship through the system's life-cycle. 2. Using the ICSM-Sw & P3S Model Integration Framework. 3. Using the ICSM-Sw & P3S Process Integration Framework. 4. Using the ECR, VCR, FCR, DCR, IOC and OCR Anchor Point milestones. 5. Ensuring that the contents of ICSM- Sw & P3S artifacts and activities are risk-driven. VariantsInvariants 29

30. 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-2013 USC-CSSE30

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

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

33. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC-CSSE33

34. University of Southern California Center for Systems and Software Engineering (c) 2007-2013 USC-CSSE34 Project name 1History Writer 2Web Redesign – Women at Work 3Visual Paradigm plug-in 4Pleo Robots 5iRobots 6Flower Seeker 7Stoked Skateboard – Web enhancement 8SnApp Dev 9BLTG – Bible iOS game 10African mellinium foundation - EduBank 11Aptitude Test 12TipSure 13Girls on the Run of Los Angeles County (GOTRLA) 14Fantasy Call out 15Yanomamo 16Jrefer 17Drighv 18Black Professionals 19Soccer Data Web crawler 20ShareTheTraining.com 21CashDoctor 22We Are Trojans 23EdAdmin 24Mobil Application for Mobile-Controlled Lighting_Android 25Mobil Application for Mobile-Controlled Lighting_iOS