The Incremental Commitment Life Cycle Process: OverviewMBASE/RUP/ICM Activity/SwDLC ModelSlide 3Incremental Commitment Model (Instructional ICM-Sw) (1 Semester Projects)CS577 Projects' Paths and Options577b ProjectsStates for 577b ProjectsCompletion progress of project artifacts in each phaseSlide 9Slide 10Slide 1110/30/2009 © 2009 USC CSSE 1University of Southern CaliforniaCenter for Systems and Software EngineeringJuly 2008 ©USC-CSSE 1©USC-CSSEThe Incremental Commitment Life Cycle Process: OverviewStage I: Definition Stage II: Development and OperationsAnchor Point MilestonesAnchor Point MilestonesSynchronize, stabilize concurrency via FEDsSynchronize, stabilize concurrency via FEDsRisk patterns determine life cycle processRisk patterns determine life cycle process10/30/2009 © 2009 USC CSSE 2University of Southern CaliforniaCenter for Systems and Software EngineeringMBASE/RUP/ICM Activity/SwDLC Model10/30/2009 © 2009 USC CSSE 3University of Southern CaliforniaCenter for Systems and Software EngineeringAdjust Scope, priorities, or discontinue Adjust Scope, priorities, or discontinue Too High, unaddressableToo High, unaddressableExplorationExplorationValuationValuationFoundationsFoundationsDevelopmentDevelopmentTeam formed, project assignedStart of Fall SemesterNegligibleAcceptableRisk?High, butaddressableNegligibleAcceptableRisk?High, butaddressableRisk? Risk?Semester BreakRisk?Team reformed, project assignedRisk? Risk?Client EvaluationClient Evaluation, Close Out ReportEnd of Spring SemesterProject ReleaseIncremental Commitment Model (Instructional ICM-Sw)(2 Semester Projects)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 ReviewOperationOperationConstructionConstructionTransitionTransitionRisk?10/30/2009 © 2009 USC CSSE 4University of Southern CaliforniaCenter for Systems and Software EngineeringIncremental Commitment Model (Instructional ICM-Sw)(1 Semester Projects)10/30/2009 © 2009 USC CSSE 5University of Southern CaliforniaCenter for Systems and Software EngineeringCS577 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 Built10/30/2009 © 2009 USC CSSE 6University of Southern CaliforniaCenter for Systems and Software Engineering577b 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 ©10/30/2009 © 2009 USC CSSE 7University of Southern CaliforniaCenter for Systems and Software EngineeringStates for 577b Projects10/30/2009 © 2009 USC CSSE 8University of Southern CaliforniaCenter for Systems and Software EngineeringCompletion progress of project artifacts in each phase10/30/2009 © 2009 USC CSSE 9University of Southern CaliforniaCenter for Systems and Software EngineeringCompletion progress of project artifacts in each phase10/30/2009 © 2009 USC CSSE 10University of Southern CaliforniaCenter for Systems and Software EngineeringRating Automated Analysis Peer Reviews Execution Testing and ToolsVery 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,
View Full Document
Unlocking...