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

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 Or Software Development Life Cycle The actual set of activities performed within an organization 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 Model 4

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

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

University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model (ICSM) (c) 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

University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model (ICSM) (c) 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

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

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

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

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

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

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

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

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

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

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

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

University of Southern California Center for Systems and Software Engineering Comparing between risks in Fall and Spring ©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 Monday: Labor Day – No Class Next Wednesday 09/03 –PC-1 : Incremental Commitment Spiral Model Submit thru DEN; if no DEN account, submit printout before class at SAL 329 before 12pm 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 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., 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

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 ICSM-Sw & P 3 S Invariants and Variants (c) 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

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

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

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