1. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 1 A Winsor Brown CS 577a Lecture Fall 2010 Anchor Point Feasibility Evidence Incremental Commitment Spiral Model (ICSM)* for Software (as used in CS 577a)

2. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 2 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

3. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 3 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]

4. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 4 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

5. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 5 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

6. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 6 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

7. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 7 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!

8. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 8 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!

9. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 9 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

10. University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE 2007-2010Page 10 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”