University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE1 July 2008©USC-CSSE1 The Incremental Commitment.

Slides:



Advertisements
Similar presentations
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
Advertisements

Automated Software Testing: Test Execution and Review Amritha Muralidharan (axm16u)
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
University of Southern California Center for Systems and Software Engineering SoS Engineering and the ICM Workshop Overview Jo Ann Lane USC CSSE
Rational Unified Process
University of Southern California Center for Software Engineering CSE USC MBASE Essentials Planning and control Milestone content Process models Life cycle.
OO Development Process. UML and Process UML standardizes notation, not process –Increase likelihood of widespread acceptance There is significant variability.
Copyright © 2006 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
CS 501: Software Engineering
University of Southern California Center for Systems and Software Engineering ©USC-CSSE1 Ray Madachy, Barry Boehm USC Center for Systems and Software Engineering.
2/13/07(c) USC-CSSE1 An Empirical Study on MBASE and LeanMBASE Supannika Koolmanojwong Center for Systems and Software Engineering CSSE- Annual Research.
© USC-CSE1 Determine How Much Dependability is Enough: A Value-Based Approach LiGuo Huang, Barry Boehm University of Southern California.
SE 555 Software Requirements & Specification Requirements Validation.
© USC-CSE Feb Keun Lee ( & Sunita Chulani COQUALMO and Orthogonal Defect.
Copyright  Larry Dribin, Ph.D. SE470_EngFlows_v1.ppt SE470 EngFlows - 1 Excellence in Software Engineering Repeatable Level Defined Level Manage.
Page 1 R Risk-Driven and Iterative Development. Page 2 R Copyright © 1997 by Rational Software Corporation What the Iterative Life Cycle Is Not It is.
Software Quality Assurance For Software Engineering && Architecture and Design.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Unified Software Development Process (UP) Also known as software engineering process SEP describes how requirements are turned into software Defines who,
Software Engineering Chapter 15 Construction Leads to Initial Operational Capability Fall 2001.
RUP Fundamentals - Instructor Notes
Software Development *Life-Cycle Phases* Compiled by: Dharya Dharya Daisy Daisy
CLEANROOM SOFTWARE ENGINEERING.
Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16 Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book)
Relating Testing to Quality –Timeliness of Testing –Quality Attributes Gauge by Testing –Roles Defining Test Discipline Activities Elaborating the Test.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
2/5/20101 R-DCR ARB Preparation A Winsor Brown CS 577B Spring 2010.
Chapter – 9 Checkpoints of the process
University of Southern California Center for Systems and Software Engineering 7/19/2013(c) USC-CSSE11 USC e-Services Software Engineering Projects.
Eighth Hour Lecture 7:30 – 8:20 pm, Thursday, September 13 Workflows of the Process (from Chapter 8 of Royce’ book)
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
University of Southern California Center for Systems and Software Engineering Introduction to: System and Software Construction, Transition and Support.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
University of Southern California Center for Systems and Software Engineering 7/13/2012(c) USC-CSSE11 USC e-Services Software Engineering Projects.
Rational Unified Process Fundamentals Module 3: Disciplines I.
Lecture 2 –Approaches to Systems Development Method 10/9/15 1.
University of Southern California Center for Systems and Software Engineering 10/25/2010(C) USC CSSE1 CS 577a Overall FCR Feedback [Updated/More]
University of Southern California Center for Systems and Software Engineering 577 process CSCI 577a Software Engineering I Supannika Koolmanojwong Mobasser.
University of Southern California Center for Systems and Software Engineering 3/3/2010© USC-CSSE CSCI577B 2010 Light Weight Sw Engg for Off-the-Books.
Software Project Management (SEWPZG622) BITS-WIPRO Collaborative Programme: MS in Software Engineering SECOND SEMESTER /1/ "The content of this.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE Page 1 A Winsor Brown CS 577a Lecture Fall.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
University of Southern California Center for Systems and Software Engineering RDCR ARB CS 577b Software Engineering II Supannika Koolmanojwong.
Software Quality Assurance
CS 577b: Software Engineering II
USC e-Services Software Engineering Projects
Integrate Agile Testing into the Process
Client Introductions to CS577a
USC e-Services Software Engineering Projects
UNIFIED PROCESS.
Object Oriented Analysis and Design
Engineering Processes
CS577a Software Engineering I DCR ARB and Package Workshop
CSCI 577b Tasks and Activities
Software Quality Assurance
ICM-Sw Essentials for 577 Process models Success models Product models
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Quality Management, Peer Review, & Architecture Review Board
ARB Schedule Locations
CS 577b Software Engineering II -- Introduction
CS577a Software Engineering ARB #2 Workshop
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Appendix B Agile Methodologies
Presentation transcript:

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

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

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

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)

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

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 ©

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

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

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%

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.

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