University of Southern California Center for Software Engineering CSE USC MBASE Essentials Planning and control Milestone content Process models Life cycle.

Slides:



Advertisements
Similar presentations
MBASE Integration Framework
Advertisements

1 Lecture #8 Purpose of SSRD Describe Capability Requirements: system subject matter measured by concrete means Describe Project, Level of Service, and.
MBASE Process: WinWin Spiral
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
University of Southern California Center for Software Engineering CSE USC 1 Digital Library Projects’ MBASE Experience Dan Port USC-CSE Annual Research.
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Copyright 2000 by USC and the Center for Software Engineering, all rights reserved. “No scene from prehistory is quite so vivid as that of the mortal struggles.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
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)
SYSC System Analysis and Design
University of Southern California Center for Software Engineering C S E USC 02/16/05©USC-CSE1 LiGuo Huang Computer Science Department.
Rational Unified Process
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
University of Southern California Center for Software Engineering CSE USC 477 Class Project – HazMat (Hazardous materials) Spring 2003 Feb. 4.
Development Processes UML just is a modeling technique, yet for using it we need to know: »what do we model in an analysis model? »what do we model in.
Requirements - Why What and How? Sriram Mohan. Outline Why ? What ? How ?
2/13/07(c) USC-CSSE1 An Empirical Study on MBASE and LeanMBASE Supannika Koolmanojwong Center for Systems and Software Engineering CSSE- Annual Research.
Iterative development and The Unified process
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural 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.
RUP Fundamentals - Instructor Notes
Software Development *Life-Cycle Phases* Compiled by: Dharya Dharya Daisy Daisy
Chapter 2 The process Process, Methods, and Tools
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Rational Unified Process Fundamentals Module 4: Disciplines II.
2/5/20101 R-DCR ARB Preparation A Winsor Brown CS 577B Spring 2010.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
University of Southern California Center for Software Engineering CSE USC 2/9/00 ©USC-CSE 1 Spiral Development: Experience, Principles, and Refinements.
Chapter – 9 Checkpoints of the process
University of Southern California Center for Systems and Software Engineering Simplifiers & Complicators and IICM-Sw Barry Boehm & A Winsor Brown CS 577a.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Lecture 7: Requirements Engineering
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
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)
REQUIREMENTS - WHY WHAT AND HOW? Steve Chenoweth & Chandan Rupakheti CSSE 371 Chapters Requirements Text. Question 6.
University of Southern California Center for Systems and Software Engineering (c) USC-CSSE Incremental Commitment Spiral Model for CSCI577 1.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
University of Southern California Center for Software Engineering CSE USC A Case for Anchor Point Milestones and Feasibility Rationales April 2005 Barry.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
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.
An organizational structure is a mostly hierarchical concept of subordination of entities that collaborate and contribute to serve one common aim... Organizational.
Rational Unified Process (RUP)
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
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.
Unified Software Practices v 5.0-D Copyright  1998 Rational Software, all rights reserved 1 /26 Rational Unified Process – Part 2 Original slides modified.
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.
Review of Definitions Software life cycle: –Set of activities and their relationships to each other to support the development of a software system Software.
Process 4 Hours.
Client Introductions to CS577a
Requirements and the Software Lifecycle
Introduction to Software Engineering
ICM_Sw Essentials for CS510
USC e-Services Software Engineering Projects
ICM-Sw Essentials for 577 Process models Success models Product models
USC e-Services Software Engineering Projects
Comparison between each special case
CS577a Software Engineering ARB #2 Workshop
Incremental Commitment Model (ICM)* for Software
Presentation transcript:

University of Southern California Center for Software Engineering CSE USC MBASE Essentials Planning and control Milestone content Process models Life cycle Anchor Points; Risk management Key practices Success models Business case IKIWISI Stakeholder win-win Product models Evaluation and analysis Process entry/exit criteria Product Evaluation criteria Domain models; Requirements; Architecture; Code; Documentation Property models Cost Schedule Performance Reliability …

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE2 Waterfall Misconceptions

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE3 Outline Spiral Model Life Cycle Anchor Points MBASE/RUP Activity/Process ModelMBASE/RUP Activity/Process Model COCOTS: Development ModelCOCOTS: Development Model MBASE Integration Framework & ProcessMBASE Integration Framework & Process MBASE ModelsMBASE Models a lecture on the philosophy behind MBASE, the types of things MBASE does and why, and an overview of OCD and SSRD

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE4 Spiral Model Original spiral and common misinterpretations Six spiral essentials –Examples and counterexamples –Relation to CMMI Hazardous spiral lookalikes to avoid

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE5 Original Spiral and Misinterpretations? Common Misinterpretations –Hack some prototypes –Fit spiral into waterfall –Incremental waterfalls –Suppress risk analysis –No concurrency, feedback –One-size-fits-all model

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE6 “Spiral Development” Definition A risk-driven process model generator Used to guide concurrent engineering Two distinguishing features: –Cyclic approach for growing system definition –Anchor point stakeholder-commitment milestones

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE7 Six Spiral Model Essentials 1. Concurrent determination of artifacts in each cycle 2. Each cycle addresses objectives, constraints, alternatives, risks, artifact elaboration, stakeholders’ commitment 3. Risk-driven activity level of effort 4. Risk-driven artifact degree of detail 5. Managing stakeholder commitments via anchor-point milestones 6. Emphasis on system and life-cycle issues - vs. software and development issues

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE8 Life Cycle Anchor Points Common System/Software stakeholder commitment points –Defined in concert with Government, industry affiliates –Coordinated with the Rational Unified Process Life Cycle Objectives (LCO) –Stakeholders’ commitment to support architecting –Like getting engaged Life Cycle Architecture (LCA) –Stakeholders’ commitment to support full life cycle –Like getting married Initial Operational Capability (IOC) –Stakeholders’ commitment to support operations –Like having first child

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE9 MBASE/RUP Activity/Process Model

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE10 2. COTS Tailoring 1. COTS Assessment 3. Glue Code Development 4. System Effort due to COTS Volatility New System Development Not Involving COTS Components Time Staffing LCO (Requirements Review) LCA (PDR) IOC (SAR) LCO – Lifecycle Objectives LCA – Lifecycle Architecture IOC – Initial Operational Capability COCOMO II Effort Estimate COCOTS Effort Estimate Elaboration (RR) Construction COCOTS: Development Model

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE11 (Risk-driven level of detail for each element) *WWWWWHH: Why, What, When, Who, Where, How, How Much Milestone ElementLife Cycle Objectives (LCO)Life Cycle Architecture (LCA) Definition of Operational Concept Top-level system objectives and scope - System boundary - Environment parameters and assumptions - Evolution parameters Operational concept - Operations and maintenance scenarios and parameters - Organizational life-cycle responsibilities (stakeholders) Elaboration of system objectives and scope of increment Elaboration of operational concept by increment Top-level functions, interfaces, quality attribute levels, including: - Growth vectors and priorities - Prototypes Stakeholders’ concurrence on essentials Elaboration of functions, interfaces, quality attributes, and prototypes by increment - Identification of TBD’s( (to-be-determined items) Stakeholders’ concurrence on their priority concerns Top-level definition of at least one feasible architecture - Physical and logical elements and relationships - Choices of COTS and reusable software elements Identification of infeasible architecture options Choice of architecture and elaboration by increment - Physical and logical components, connectors, configurations, constraints - COTS, reuse choices - Domain-architecture and architectural style choices Architecture evolution parameters Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBD’s for later increments Assurance of consistency among elements above All major risks resolved or covered by risk management plan Identification of life-cycle stakeholders - Users, customers, developers, maintainers, interoperators, general public, others Identification of life-cycle process model - Top-level stages, increments Top-level WWWWWHH* by stage Assurance of consistency among elements above - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Definition of System Requirements Definition of System and Software Architecture Definition of Life- Cycle Plan Feasibility Rationale System Prototype(s) Exercise key usage scenarios Resolve critical risks Exercise range of usage scenarios Resolve major outstanding risks Win Win Spiral Anchor Points

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE12 Where do objectives, constraints, alternatives come from? –Win Win extensions Lack of intermediate milestones –Anchor Points: LCO, LCA, IOC –Concurrent-engineering spirals between anchor points Need to avoid model clashes, provide more specific guidance –MBASE Spiral Model Refinements

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE13 MBASE Model Integration Framework Process models Life cycle anchor points Risk management Key practices Success models Business case IKIWISI Stakeholder win-win Property models Cost Schedule Performance Reliability Product models Domain model Requirements Architecture Code Documentation Planning and control Milestone content Evaluation and analysis Process entry/exit criteria Product evaluation criteria

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE14 MBASE 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 spiral cycles or builds between anchor points. 5. Mapping of activities onto Inception-Elaboration-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 MBASE Model Integration Framework. 3. Using the MBASE Process Integration Framework. 4. Using the LCO, LCA, and IOC Anchor Point milestones. 5. Ensuring that the content of MBASE artifacts and activities is risk- driven. VariantsInvariants

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE15 MBASE Model Integration Process

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE16 MBASE Process Framework

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE17 MBASE Model Integration: LCO Stage Domain Model WinWin Taxonomy Basic Concept of Operation Frequent Risks Stakeholders, Primary win conditions WinWin Negotiation Model IKIWISI Model, Prototypes, Properties Models Environment Models WinWin Agreements, Shared Vision Viable Architecture Options Updated Concept of Operation Life Cycle Plan elements Outstanding LCO risks Requirements Description LCO Rationale Life Cycle Objectives (LCO) Package Anchor Point Model determines identifies determines situatesexercise focus use of focus use of determines guides determination of validate inputs for provides initializeadoptidentify update achieveiterate to feasibility, consistency determines exit criteria for validates readiness of initializesinitializes

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE18 MBASE Models* Iterations Release Description Test Plan Test Results Peer Review Report Users Manual CTS OCD Shared Vision System Capabilities Key Stakeholders System Boundary & Environment Top-Level Business Case Domain & Organization Description Proposed System Prototyping Proj. Reqts. Capability Reqts. System Interface Level of Service Reqts. Evolution Reqts. SSRD SSAD System Analysis Architecture Design & Analysis Implementation Design LCP Milestones and Products Responsibilities Approach, Resources FRD/CTS Business Case Reqts. Satisfaction Process Rationale Risk Assessment Iteration Plan Quality Plan * Not exhaustive

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE19 Operations Model` Object Model Capability Requirements System Definition Class Model Project Requirements Statement of Purpose Project Goals Organization Goals System Capabilities Component Model Organization Entities Behavior Model Enterprise model Domain DescriptionSystem AnalysisSystem Design Operational Concept Description (OCD) System and Software Requirements Definition (SSRD) System and Software Architecture Description (SSAD) Organization Background Organization Activities Interaction Model Levels of Service Goals LOS Requirements Coverage/Traceability of MBASE Product Models* * Does not include all MBASE models Release Description Reqts. Satisfaction Capability Tests Data Structures Methods/functions LOS Tests Implementation Construction,Transition,Support (CTS) External to MBASE

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE Project Activities

University of Southern California Center for Software Engineering CSE USC 4/30/01©USC-CSE21 CS577 MBASE Documents