1. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE1 July 2008©USC-CSSE1 The Incremental Commitment Life Cycle Process: Overview Stage I: DefinitionStage II: Development and Operations Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process

2. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE2 MBASE/RUP/ICM Activity/SwDLC Model

3. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE3 Adjust Scope, priorities, or discontinue Too High, unaddressable Too High, unaddressable Exploration Valuation Foundations Development ECRECR ECRECR VCRVCR VCRVCR FCRFCR FCRFCR DCRDCR DCRDCR Team formed, project assigned Start of Fall Semester Negligible Acceptable Risk? High, but addressable Negligible Acceptable Risk? High, but addressable Risk? Semester Break RDCRRDCR RDCRRDCR Risk? Team reformed, project assigned CCDCCD CCDCCD TRR1TRR1 TRR1TRR1 Risk? Client Evaluation Client Evaluation, Close Out Report End of Spring Semester Project Release Incremental Commitment Model (Instructional ICM-Sw) (2 Semester Projects) OCROCR OCROCR CCD-Core Capability Drivethrough; DCR- Development Commitment Review; ECR-Evaluation Commitment Review; FCR-Foundations Commitment Review; OCR- Operational Commitment Review; RDCR-Rebaselined Development Commitment Review; TRR-Transition Readiness Review; VCR-Valuation Commitment Review Operation Construction Transition Risk? TRR2TRR2 TRR2TRR2

4. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE4 Incremental Commitment Model (Instructional ICM-Sw) (1 Semester Projects)

5. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE5 CS577 Projects' Paths and Options Full two semester –Completed software for a "system" –Inception, Elaboration, Construction, mini-Transition Single Semester –System "Feasibility" demonstration –COTS assessment and recommendation –Inception and Elaboration (for later "implementation” Second Semester (possibly delayed) –Completed software for a "system" –Re-baselined Elaboration, Construction, mini-Transition Third Semester continuation –Enhancement (more functionality) IECT –Full Transition "Off the books" continuation of projects too risky to be in 577b –Needs at least 1 DR/UI from current project to lead, preferrably two –Development using 2+ DR/UI (2 units) –OCD, SSRD, SSAD, LCP and FED updated to As Built

6. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE6 577b Projects Often total team >=5 <=6 (objective) –At least 3 students taking CS577b Can be technical or non-technical leads Can be developers –DR/V or UI used for developers (usually, can be documenters) Must be putting in 10 hours per week Must have taken 577a to be "documenters" Preferred: have taken 577a OK: 2+ units (or UI) and good technical fit: Should attend some/most of the 577b lectures –DR/V or UI for leads IFF were on same project in 577a ©

7. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE7 States for 577b Projects

8. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE8 Completion progress of project artifacts in each phase

9. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE9 Completion progress of project artifacts in each phase Artifacts Exploration Valuation Foundations Rebaselined Foundations Development Operation Operational Concept Description (OCD)20%60%15%4%1%0% System and Software Requirements Description (SSRD)5%75%7%12%1%0% System and Software Architecture Description (SSAD)0%30%60%6%4%0% UML Models0%30%60%6%4%0% Life Cycle Plan (LCP)5%74%10% 1%0% Feasibility Evidence Description (FED)5%70%15%8%2%0% Supporting Information Document (SID)0%70%10% 0% Quality Management Plan (QMP)0%40% 19%1%0% Iteration Plan (IP)0% 80%20%0% Iteration Assessment Report (IAR)0% 100%0% Transition (Preparation) Plan0% 40%60%0% Test Plan and Cases (TPC)0% 50% 0% Test Procedures and Result (TPR)0% 100%0% Peer Review Plan (PRP)0% 100%0% Peer Review Report (PRR)0% 100%0% User Manual (UM)0% 100%0% Support Plan (SP)0% 100%0% Training Materials0% 100%0% Regression Test Package (RTP)0% 100%0% Packaged Tools and Procedure (PTP)0% 100%0%

10. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE10 RatingAutomated AnalysisPeer ReviewsExecution Testing and Tools Very Low - Simple complier syntax checking. - No peer review. - No testing. Low - Basic compiler capabilities for static module-level code analysis, syntax, type-checking. - Ad-hoc informal walk-throughs - Minimal preparation, no follow-up - Ad-hoc testing and debugging. - Basic text-based debugger. Nominal - Some compilers extensions for static module and inter-module level code analysis, syntax, type-checking. - Basic requirements and design consistency, traceability checking. - Well-defined sequence of preparation, review, minimal follow-up. - Informal review roles and procedures. - Basic unit test, integration test, system test process. - Basic test data management, problem tracking support. - Test criteria based on checklists. High - Intermediate-level module and inter- module code syntax and semantic analysis. - Simple requirements/ design view consistency checking. - Formal review roles with all participants well- trained and procedures applied to all products using basic checklist, follow up. - Well-defined test sequence tailored to organization (acceptance/ alpha/ beta/ flight/ etc.) test. - Basic test coverage tools, test support system. - Basic test process management. Very High - More elaborate requirements/ design view consistency checking. - Basic distributed-processing and temporal analysis, model checking, symbolic execution - Formal review roles with all participants well- trained and procedures applied to all product artifacts and changes (formal change control boards). - Basic review checklists, root cause analysis. - Formal follow-up. - Use of historical data on inspection rate, preparation rate, fault density. - More advanced test tools, test data preparation, basic test oracles support, distributed monitoring and analysis, assertion checking. - Metrics-based test process management. Extra High - Formalized* specification and verification. - Advanced distributed processing and temporal analysis, model checking. Symbolic execution. - Consistency-checkable pre-condition and post-conditions, but not mathematical theorems - Formal review roles and procedures for fixes, change control. - Extensive review checklists, root cause analysis. - Continuous review process improvement. - User/Customer involvement, Statistical Process Control - Highly advanced tools for test oracles, distributed monitoring and analysis, assertion checking - Integration of automated analysis and test tools. - Model-based test process management.

11. University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE11 Automated AnalysisReviewingTesting - Completeness checking - Consistency checking - Views, interface, behavior, pre/post conditions - Traceability checking - Compliance checking- Models, assertions, standards. - Peer review, inspections - Architecture Review board - Pair programming - Requirements and design - Structure - Operational profile - Usage (Alpha/ Beta) - Regression - Value/ risk – based - Test automation