Incremental Commitment Spiral Model (ICSM) Supannika Koolmanojwong, USC CS 577a Lecture Fall 2011 August 24, 2011

Outline Software Engineering Process Models ICSM Success Critical Criteria for each milestone ICSM in CSCI577 Feasibility Evidence Aug. 24, 2011 © USC-CSSE

Software Development Process Or Software Development Life Cycle The actual set of activities performed within an organization Popular Models: Waterfall model Spiral model Iterative and Incremental model Agile model Aug. 24, 2011 © USC-CSSE

Examples of Process Model Waterfall Model Spiral Model Aug. 24, 2011 © USC-CSSE

Examples of Process Model Iterative and Incremental Model Agile Model Aug. 24, 2011 © USC-CSSE

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. Aug. 24, 2011 © USC-CSSE

The Incremental Commitment Spiral Model (ICSM) 4 Key Principles Stakeholder value-based system definition and evolution Incremental commitment and accountability Concurrent system and software definition and development If you spread out the spiral, you will this picture. Originally, the ICSM or the ICM has 6 key principles and these 6 key principles are rearranged into 4 key principles. The first key principle remind you to include all success-critical stakeholders and engage them in the development process. They second key principle focuses gaining commitment and accountability from the stakeholders . Otherwise, it could lead to useless project The third key principle, instead of doing sequential development, the team should follow concurrent project development and perform synchronization and stabilization at each milestone. The last one, as I mentioned earlier that it plays major roles in determining the project’s course of action. Moreover, we will see later how the risks and opportunities of the project define what process pattern that the team should follow. Stakeholder value-based system definition and evolution. If a project fails to include success-critical stakeholders such as end-users, maintainers, or suppliers, these stakeholders will frequently feel little commitment to the project and either underperform or refuse to use the results. Incremental commitment and accountability. If success-critical stakeholders are not accountable for their commitments, they are likely to be drawn away to other pursuits when they are most needed. Concurrent system and software definition and development. If definition and development of requirements and solutions; hardware, software, and human factors; or product and process definition are done sequentially, the project is likely both to go more slowly, and to make early, hard-to-undo commitments that cut off the best options for project success. Evidence and risk-based decision making. If key decisions are made based on assertions, vendor literature, or meeting an arbitrary schedule without access to evidence of feasibility, the project is building up risks. And in the words of Tom Gilb, “If you do not actively attack the risks, the risks will actively attack you.” Evidence and risk-based decision making Aug. 24, 2011 © USC-CSSE

The Incremental Commitment Spiral Model (ICSM) 4 Key Principles: Stakeholder value-based system definition and evolution Incremental commitment and accountability Concurrent system and software definition and development Evidence and risk-based decision making Aug. 24, 2011 © USC-CSSE

Different Risks/Opportunities Yield Different Processes Architected Agile E.g. Business data processing Although the patterns look similar, NDI and services have different risks Use Single NDI E.g. Accounting System With addressable risk(s), the project moves on the next phase Different opportunities and different risks that each project has, could indicate the activities in the next, in turn determine which process you should follow. In general, in the exploration phase, the team explores alternative, if there is no opportunities in using any NDI or NCS tow, then the team continue to negotiate for the requirements then building the architecture and other foundations. Then move on to the development phase with agile-driven approach. Next opportunity case is, in the exploration phase, the team found a perfect NDI that satisfy all the win conditions, so the team could spend very little time on the Valuation phase and Foundation phase since most of the functionalities are provided by the NDI. The team could move on the development phase where the team start migrating data and move to deployment For NDI-Intensive, in exploration phase or valuation phase, the development might find an NDI or combination of NDIs. In the Valuation phase, the effort goes to selecting and assessing the NDIs and assessing the interoperability between the selected NDIs. Then in Foundations phase, since NDI comes with their own architecture, then the team could spend less time in foundation phase. Similarly, the team could spend less effort in development due to the functionalities provided by NDI. For services-intensive, the risk and opportunity pattern is very similar to NDI, but since there are many aspects in their differrences, hence it needs different process to follow. NDI-Intensive E.g. Supply Chain Management With provided architecture and functionalities from NDI, the team could spend close to no effort in Valuation and Foundations phase Services-Intensive E.g. Community Services The team spends more effort in assessing NDI(s) and their interoperability, enter Operation phase sooner 10/21/2010

ICSM HSI Levels of Activity for Complex Systems As mentioned earlier, with the ICSM, a number of system aspects are being concurrently engineered at an increasing level of understanding, definition, and development. The most significant of these aspects are shown in this slide, an extension of a similar view of concurrently engineered software projects developed as part of the RUP (shown in a backup slide). As with the RUP version, it should be emphasized that the magnitude and shape of the levels of effort will be risk-driven and likely to vary from project to project. In particular, they are likely to have mini risk/opportunity-driven peaks and valleys, rather than the smooth curves shown for simplicity in this slide. The main intent of this view is to emphasize the necessary concurrency of the primary success-critical activities shown as rows. Thus, in interpreting the Exploration column, although system scoping is the primary objective of the Exploration phase, doing it well involves a considerable amount of activity in understanding needs, envisioning opportunities, identifying and reconciling stakeholder goals and objectives, architecting solutions, life cycle planning, evaluation of alternatives, and negotiation of stakeholder commitments. Aug. 24, 2011 © USC-CSSE 10

10/21/2010

RUP & ICSM Anchor Points Enable Concurrent Engineering Aug. 24, 2011 © USC-CSSE

The ICSM Evolutionary View Aug. 24, 2011 © USC-CSSE

Outline Software Engineering Process Models ICSM Success Critical Criteria for each milestone ICSM in CSCI577 Feasibility Evidence Aug. 24, 2011 © USC-CSSE

Success Critical Criteria for each milestone 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 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 Aug. 24, 2011 © USC-CSSE

ICSM P3S Model Integration Framework Business case IKIWISI Stakeholder win-win Success models Product evaluation criteria Process entry/exit criteria Life cycle anchor points Risk management Key practices Planning and control Process models Product models Milestone content Domain model Requirements Evaluation and Architecture analysis Code Documentation Property models Cost Schedule Performance Reliability Aug. 24, 2011 © USC-CSSE

ICSM-Sw & P3S Invariants and Variants 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. Variants Invariants Aug. 24, 2011 © USC-CSSE

ICSM-Sw & P3S Model Integration Process Aug. 24, 2011 © USC-CSSE

Outline Software Engineering Process Models ICSM Success Critical Criteria for each milestone ICSM in CSCI577 Feasibility Evidence Aug. 24, 2011 © USC-CSSE

Incremental Commitment Spiral Model for CSCI577 Aug. 24, 2011 © USC-CSSE 20

IICSM-Sw Project Artifacts Aug. 24, 2011 © USC-CSSE

Why the Incremental Commitment Spiral Model (ICSM)? A new process model framework that is developed to build on the strengths of current process models RUP V-Model = Early verification and validation = Concurrent engineering = stabilizes at anchor point milestones + Explicit emphasis on concurrent engineering + evolutionary development + Integrated hardware-software-human factors We know that the ICM has great core concepts, now I would like to compare the ICM with state-of-the-art Process models The orange texts represent the similarities between the ICM and other process model The blue texts represent the advantage that the ICM over the other process model The first one, ICM and V-model, both of them apply early V&V but ICM has stronger points on concurrent Engineering and Evolutionary Development EVO: Risk-driven evolutionary development is better at coping with rapid change, but can have difficulties in optimizing around early increments with architectures that encounter later scalability problems. Comparing to RUP model, both of them emphasizes on concurrent engineering and stabilization at anchor point milestones but ICM also addresses hardware and human factors integration and has extra Inception phase. Comparing to Spiral Model, Both are risk-driven process, but ICM explicitly define the risk-based and evidence based decision milestones Lastly, the Agile Model, ICM is better in handling the scalability and higher assurance. Spiral Agile = Risk-driven activity prioritization = Adaptability to unexpected change + Explicit definition of risk-based decision points and criteria + Addresses scalability, high assurance Aug. 24, 2011 © USC-CSSE

Outline Software Engineering Process Models ICSM Success Critical Criteria for each milestone ICSM in CSCI577 Feasibility Evidence Aug. 24, 2011 © USC-CSSE

Anchor Point Feasibility Evidence Description (FED) 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 Anchor Point Feasibility Evidence Description To make ICSM concurrency work, the anchor point milestone reviews are the mechanism by which the many concurrent activities are synchronized, stabilized, and risk-assessed at the end of each phase. Each of these anchor point milestone reviews is focused on developer-produced evidence, documented in a Feasibility Evidence Description (FED), to help the key stakeholders determine the next level of commitment. At each program milestone/anchor point, feasibility assessments and the associated evidence are reviewed and serve as the basis for the stakeholders’ commitment to proceed. The FED is not just a document, a set of PowerPoint charts, or Unified Modeling Language (UML) diagrams. It is based on evidence from simulations, models, or experiments with planned technologies and detailed analysis of development approaches and projected productivity rates. The detailed analysis is often based on historical data showing reuse realizations, software size estimation accuracy, and actual developer productivity rates. It is often not possible to fully resolve all risks at a given point in the development cycle, but known, unresolved risks need to be identified and covered by risk management plans. Further details on the FED and anchor point milestones are provided in a counterpart presentation on the Workshop Materials web page. Aug. 24, 2011 © USC-CSSE 24

Parsing “FED” Definition (1/8) “validated by independent experts”: Independent experts planned for and engaged Funds set aside, resources “engaged” how ‘independent’ depends on situation Within corporation: provide charge numbers; incentivize External: NDA’s; incentive=$’s (contracted); more objective? how can FED be evaluated if ‘experts’ don’t know what they are looking at? Data Idem Definitions (DID) [for government programs] Internal document specifications/guidelines for commercial Pay “experts” to learn [review for accomplishing FED objectives] Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (2/8) “Satisfy the requirements: capability, interfaces, level of service, and evolution” Where? Software System Requirements Document Translation of terms Capability: “functionality” Level Of Service (LOS): “performance”, best tied to functionality Interfaces: Other systems; User; … Evolution: [NEW!] foreseeable and specifiable Capabilities LOS Interfaces Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (3/8) “Support the operational concept” Need “Operational Concept Description” Complex projects may need models of environment and system Structure Behavior Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (4/8) Be buildable within the budgets and schedules in the plan Implies “plan” is documented (and updated at Commitment Reviews) [577ab use “Life Cycle Plan (LCP)” document] Implies cost and schedule estimates performed “buildable” implies “bases of estimate” are provided to experts Experts understand estimation approach and models Budget and Schedule variations and expectable deviations understood and shared by experts Estimates documented in LCP Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (5/8) Generate a viable return on investment Implies a “business case” that is documented, checkable and justified What if “unprecedented” or “intangible” benefits Still need to specify “cost” ($ & ) SCS MUST weigh costs vs. benefits [Students in CSCI510 have learned techniques] Documented in FED! Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (6/8) Generate satisfactory outcomes for all of the success-critical stakeholders What is “satisfactory”? Do “models” exist? How balanced (“satisficed”)? [CS577ab use WinWin Negotiation with continuous balance checks AND re-balancing at Anchor Point Commitment Reviews] Documented in FED! Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (7/8) “Satisfy the requirements: capability, interfaces, level of service, and evolution” How: Software System Requirements Document entries traced to Capability: prototype, executable code, functioning system Level Of Service (LOS): simulation, measurements, test Interfaces: Existence and Completeness Evolution: usually requires “engineering argument” plus Architecture that can support (models and simulation) Prototype evolution and measure Demonstration or examples Documented in FED! All major risks resolved or covered by risk management plans A basis for stakeholders’ commitment to proceed Aug. 24, 2011 © USC-CSSE

Parsing “FED” Definition (8/8) Serves as basis for stakeholders’ commitment to proceed Stakeholders understand information provided or rely on experts Commitment Alternatives: Risk is assessed as High but adressable: repeat (primary actions of phase) Acceptable: proceed to next phase Negligible: proceed directly to next Anchor Point Review AFTER completing needed additional evidence “Too high or unadressable”: “Adjust scope, priorities [and restart an earlier phase] or discontinue” Aug. 24, 2011 © USC-CSSE

Documentation Summary Need documentation set with “guidelines” or standards for completion Need to cover [with appropriate updates per phase] Operation concept(s) Requirements Architecture Life Cycle Plan (NOT just Sw Development Life Cycle) Feasibility Evidence Description Aug. 24, 2011 © USC-CSSE

Guidelines or Standards Do they exist? Do they cover the necessary material? (if not, update to FED needs) Examples IBM/Rational “Rational Unified Process” Open UP (for [simple] Agile LC processes) Commercial (purchased) Organization tailored based on OpenUP or Commercial USC-CSSE “ICSM Guidelines” Generated through RCM (Rational Method Composer) Aug. 24, 2011 © USC-CSSE

More "Reality" about CS577ab Why "so much" documentation? Clients want not only to USE your software system, but also will need/want ENHANCEMENTS by "strangers" What do the "strangers" need? What do in-house "maintainers" need What ELSE do enhancers/maintainers need? C ode W orking system for trial(s) and tests Aug. 24, 2011 © USC-CSSE