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

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

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

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

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

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

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

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

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

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

11. 10/21/2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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