1. Incremental Commitment Model (ICM)* for Software
A Winsor Brown and Barry Boehm, USC
CS 577a Lecture
Fall 2009
* NOTE: Check the handouts page for this lecture, and 8/24/09 and 8/26/09 lectures for “notes”.

2. The Incremental Commitment Model Life Cycle Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point Milestones
The Incremental Commitment Life Cycle Process: Overview
This slide shows how the ICM spans the life cycle process from concept exploration to operations. Each phase culminates with an anchor point milestone review. At each anchor point, there are 4 options, based on the assessed risk of the proposed system. Some options involve go-backs. These options result in many possible process paths.
The life cycle is divided into two stages: Stage I of the ICM (Definition) has 3 decision nodes with 4 options/node, culminating with incremental development in Stage II (Development and Operations). Stage II has an additional 2 decision nodes, again with 4 options/node.
One can use ICM risk patterns to generate frequently-used processes with confidence that they fit the situation. Initial risk patterns can generally be determined in the Exploration phase. One then proceeds with development as a proposed plan with risk-based evidence at the VCR milestone, adjusting in later phases as necessary. For complex systems, a result of the Exploration phase would be the Prototyping and Competition Plan discussed above.
Risks associated with the system drive the life cycle process. Information about the risk(s) (feasibility assessments) supports the decision to proceed, adjust scope or priorities, or cancel the program.
A more detailed description of the activities going on in each phase is provided in chart 78.
Synchronize, stabilize concurrency via FEDs
Risk patterns determine life cycle process
Aug. 28, 2009
© USC-CSE 3

3. "Real Projects for Real Clients"
Title from Dr. David Klappholz
We are one of the few graduate level courses doing it
If you go on to become a CS/SE educator, we are happy to help you and your institution
WIIFM (actually YOU):
Dr. Klappholz says his students "blow [HR] interviewers away" because they can talk about the not just CS side:
Pre & Post Design, Code and [maybe] Test
Aug. 28, 2009
© USC-CSE

4. ICM HSI Levels of Activity for Complex Systems
As mentioned earlier, with the ICM, 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. 28, 2009
© USC-CSE 5

5. RUP & ICM Anchor Points Enable Concurrent Engineering
Aug. 28, 2009
© USC-CSE

6. What's different about IICM-Sw [from other SDLCs]
____ Life Cycle
Documents …
Aug. 28, 2009
© USC-CSE

7. ICM 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. 28, 2009
© USC-CSE

8. ICM-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 ICM-Sw & P3S Model Integration Framework.
3. Using the ICM-Sw & P3S Process Integration Framework.
4. Using the ECR, VCR, FCR, DCR, IOC and OCR Anchor Point milestones.
5. Ensuring that the contents of ICM-Sw & P3S artifacts and activities are risk-driven.
Variants
Invariants
Aug. 28, 2009
© USC-CSE

9. ICM-Sw & P3S Model Integration Process
Aug. 28, 2009
© USC-CSE

10. Instructional Incremental Commitment Model – Software Engineering
Aug. 28, 2009
© USC-CSE 11

11. IICM-Sw Project Artifacts
Aug. 28, 2009
© USC-CSE

12. IICM-Sw Prj. Artifacts 1 Sem.
Aug. 28, 2009
08/25/08
©USC-CSSE
© USC-CSE 13

13. 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 ICM 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. 28, 2009
© USC-CSE 14

14. Parsing “FED” Definition => 1 of 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. 28, 2009
© USC-CSE

15. Parsing “FED” Definition => 2 of 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. 28, 2009
© USC-CSE

16. Parsing “FED” Definition => 3 of 8
“Support the operational concept”
Need “Operational Concept Description”
Complex projects may need models of environment and system
Structure
Behavior
Aug. 28, 2009
© USC-CSE

17. Parsing “FED” Definition => 4 of 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. 28, 2009
© USC-CSE

18. Parsing “FED” Definition => 5 of 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. 28, 2009
© USC-CSE

19. Parsing “FED” Definition => 6 of 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. 28, 2009
© USC-CSE

20. Parsing “FED” Definition => 7 of 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. 28, 2009
© USC-CSE

21. Parsing “FED” Definition => 8 of 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. 28, 2009
© USC-CSE

22. 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)
FED
???
Aug. 28, 2009
© USC-CSE

23. Guidelines or Standards
Do they exist?
Do they cover the necessary material? (if not, update to FED needs)
Examples
IBM/Rational “Rational Unified Process”(es)
Open UP (for [simple] Agile LC processes)
Commercial (purchased)
Organization tailored based on OpenUP or Commercial
USC-CSSE “Instructional ICM - Sw” (ICM EPG)
nee “MBASE Guidelines” of various “flavors”
Generated through RMC (Rational Method Composer)
Aug. 28, 2009
© USC-CSE

24. How to Decide What to Use?
P3S Model View of ICM [AKA MBASE “Frameworks”]
Model Integration Framework
Model Integration Process Framework
Aug. 28, 2009
© USC-CSE

25. ICM 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. 28, 2009
© USC-CSE

26. ICM-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 ICM-Sw & P3S Model Integration Framework.
3. Using the ICM-Sw & P3S Process Integration Framework.
4. Using the ECR, VCR, FCR, DCR, IOC and OCR Anchor Point milestones.
5. Ensuring that the contents of ICM-Sw & P3S artifacts and activities are risk-driven.
Variants
Invariants
Aug. 28, 2009
© USC-CSE

27. ICM-Sw & P3S Model Integration Process
Aug. 28, 2009
© USC-CSE

28. 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
Reality for MEDIUM+ SIZED and/or CRITICAL projects
Help you become the leaders in 2015(?)-2040 …
What ELSE do enhancers/maintainers need?
C ode
W orking system for trial(s) and tests
Aug. 28, 2009
© USC-CSE

29. Grading One of your Win Conditions?
Making a sustainable winner of your client
Don't cut corners (without prior, confirmed consent)
Provide the code and a copy of working system and/or executable architectural prototype …
Consequences:
Make sure variations coordinated with TAs (grading) and me (I am the "Director of Development" concerned with responsibilities to clients)
After-the-fact grade changes when we find out and verify critical shortfalls!
Aug. 28, 2009
© USC-CSE

30. Academic Integrity Acknowledgement AGAIN+
Single most-serious offense: Plagiarism
Using other people’s work without crediting them
INCLUDING previous projects and/or guidelines
Proper crediting shown in DEN AI Tutorial
Homework, exams, class exercises, individual assignments
Minor first offense: Written up for submission AND You lose one grade level
E.g., B+ instead of A-
Write-up's are SJA&CS required! Recommended sanction usually accepted
Second offense OR MAJOR first offense: F for the course
Aug. 28, 2009
© USC-CSE 31

31. SCAMPUS: University Governance
11.00 Behavior Violating University Standards and Appropriate Sanctions
General principles of academic integrity include and incorporate the concept of respect for the intellectual property of others, the expectation that individual work will be submitted unless otherwise allowed by an instructor, and the obligations both to protect one’s own academic work from misuse by others as well as to avoid using another’s work as one’s own. All students are expected to understand and abide by these principles. Faculty members may include additional classroom and assignment policies, as articulated on their syllabus.
The following are examples of violations of these and other university standards.
11.11
A. The submission of material authored by another person but represented as the student’s own work, whether that material is paraphrased or copied in verbatim or near-verbatim form.
B. The submission of material subjected to editorial revision by another person that results in substantive changes in content or major alteration of writing style.
C. Improper acknowledgment of sources in essays or papers. …
Aug. 28, 2009
© USC-CSE