Presentation on theme: "1 Lecture #6 MBASE Integration Framework Copyright 2000 by USC and the Center for Software Engineering, all rights reserved."— Presentation transcript:
1 Lecture #6 MBASE Integration Framework Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.
2 Lecture #6 MBASE Conceptual Framework
3 Lecture #6 MBASE WinWin Spiral
4 Lecture #6 MBASE Process: WinWin Spiral Three principals to visualizing application development 1. Integrating four system model, each one capturing specific attributes 2. All four models have specific interdependencies 3. An iterative spiral that is anchored with management milestones. At each anchor point, key stakeholders decide whether and how to proceed. Philosophy: Eliminate or mitigate model clashes by concurrently evolving Requirements Other key choices: e.g. architecture, operational concepts, etc.
5 Lecture #6 MBASE Invariants and Variants
6 Lecture #6 MBASE Invariants 1. Defining and sustaining a stakeholder win-win relationship throughout a system's life-cycle a. A project organized to achieve the stakeholder win-win objectives is the focus of MBASE activity. b. A system characterized by a system boundary scopes the project's authority and responsibility. c. A projects direct authority and responsibility may not cover the entire systems life cycle, but it needs to involve those with authority and responsibility over the rest of the systems life cycle as critical system stakeholders.
7 Lecture #6 MBASE Invariants 2. Building as-you-go integrity relationships within and among the projects process, product, property, and success models. [static relationships and constraints across the various MBASE models being integrated] Retrofiting integrity relationships (late fixes of model clashes) causes - much larger amounts of rework and - deflated expectations. MBASE Model Integration Framework addresses the among-models integrity relationships. Within-models relationships involve things like the product model OCD/SSRD/SSAD traceability relationships
8 Lecture #6 3. Achieving model integrity relationships via the WinWin Spiral Process and MBASE Process Integration Framework. [dynamic relationships and constraints across the various MBASE models being integrated] This is a Project Responsibility: model clashes will occur if relationships and constraints are not satisfied 4. Managing stakeholder life cycle commitments via the LCO, LCA, and IOC Anchor Point milestones. Implicitly identifies the constituent elements and associated reviews and pass/fail conditions of the Anchor Point milestones as invariants. MBASE Invariants
9 Lecture #6 MBASE Invariants 4. Continued: constituent elements and associated reviews and pass/fail conditions for LCO and LCA, includes the essential content of - Operational Concept Definition, - Requirements Definition, - Architecture Definition, - Life Cycle Plan, Key Prototypes, and - Feasibility Rationale - LCO and LCA Architecture Review Board reviews and their Feasibility Rationale-based pass-fail criteria.
10 Lecture #6 MBASE Invariants 4. Continued: constituent elements and associated reviews and pass/fail conditions For IOC, the essential content of the IOC deliverables for - Preparation of software, personnel, and facility - Transition Readiness Review + associated pass-fail criteria - Release Readiness Review + associated pass-fail criteria Do not have to be separate events or definition documents. - For a 4GL application, the project has committed to the 4GL infrastructure's architecture, and the project can merge its LCO and LCA packages and reviews. - For simple systems or upgrades, the project may choose to integrate its OCD, SSRD, and SSAD.
11 Lecture #6 MBASE Invariants 5. Ensuring that the content of MBASE artifacts and activities is risk-driven Otherwise, the project will either fail to achieve critical success conditions waste effort performing unneeded or dysfunctional activities Risk criterion is the best way for a project to determine "how much is enough modeling reusing reviewing specifying testing etc. prototyping documenting e.g. a simple application to automate some pre-specified tax tables may have no need to prototype at all
12 Lecture #6 MBASE Variants (1) Use of particular success, process, product, or property models. (2) Choice of process or product representation. UML may be appropriate for many applications, but not for a small upgrade to a well-documented legacy system using structured analysis and design, for example. The choice may vary by legacy constraints, nature of application (pure dataflow vs. pure event-based), staff familiarity, or tool support. (3) Degree of detail of process, product, property, or success modeling. Given Invariant 5, the degree of detail will vary based on risk considerations.
13 Lecture #6 MBASE Variants (6) Mapping of activities onto Inception-Elaboration Construction-Transition phases. Most of the activity elements will be spread across multiple phases. Their relative activity levels by phase may vary a lot. - stakeholders may require a lot of negotiation of top-level requirements in Inception and little negotiation of detailed requirements in Elaboration - vice versa. (7) Mapping of staff levels onto activities.
14 Lecture #6 MBASE Variants for CS3156/4156 Product Model: Baseline – OO/UML(RUP's) based models Process Model: RAD; Schedule as Independent variable; 12 week construction – minimize risk of not finishing Property Models: COCOMO II + CORADMO Cost & Schedule Quality: - Fagan's Inspection's defect data - Problem reports IKIWISI: user friendliness Process representation: EPG; MBASE guidelines Product representation & method: RUP's use of UML plus … Number of spiral cycles: one in inception, 1.5 in elaboration, two (recommended) in construction.
15 Lecture #6 MBASE Guidelines MBASE Model Guide –describes models –describes suggested model creation approach (variant) MBASE Process Guide –Describes activities and dynamic model integration large, so provided in EPG redundant with model guide (at present) MBASE Active Templates Active Templates Process Guide Model Guide The Trinity
16 Lecture #6 MBASE Model Guidelines
17 Lecture #6 MBASE Process Guidelines
18 Lecture #6 MBASE Active Templates
19 Lecture #6 General MBASE Considerations Made up of OCD, SSRD, SSAD, LCP, and FRD and various IOC plans Collaboration Essential, Elements Strongly Integrated –this reduces risk overall Keep deliverables in sync, strong interdependencies Conceptual integrity critical! Be consistent, traceable,… LCO: less structure, detail, more vision - major issues LCA: no TBDs, formal, no unresolved issues IOC: only detail what was actually built Generally no set number of pages –be concise, but cover, lean and mean –be willing to throw away –meet completion or exit criteria
20 Lecture #6 General MBASE Considerations Cont. Avoid repetition, instead reference the information. Avoid broken or blind or vague references Do not include text from guidelines, without relating to your project Follow formatting guidelines (grader win-condition!) –Describe what things are for your project, not the guidelines –Outline and summarize, avoid the great system novel –Use a consistent referencing format (e.g , REQ-7) Not one size fits all - tailor to your project, use only what is relevant –risk driven documentation IOC guidelines separated from LCO/LCA –there are places that they integrate and mix –look out for construction phase
21 Lecture #6 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 Activity Model Enterprise model Domain DescriptionSystem AnalysisSystem Requirements 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 Levels of Service Requirements Integration of MBASE System Definition Elements System Design
22 Lecture #6 Modeling versus Documenting MBASE describes models, how to build them, and ways to communicate them. Documentation is a necessary consequence of modeling –why? –Also, the act of writing something down helps you solidify a model Communication is an essential part of the collaborative development approach Avoid documenting for documentation sake! –Everything you document should be the result of modeling –everything you document should have value and meaning to stakeholders (think about risk here) The documentation are the models!!! The Models are the documentation!!!
23 Lecture #6 Purpose of OCD Describe context of system. why build it? What do we have? Where are we starting? Describe stakeholders of the system: how the system will work when deployed. Allow evolution from current to new operational concept. Allow adaptation of concept. Clarify the value of new system.
24 Lecture #6 OCD Completion Criteria (LCO) Top-level system objectives: Organizational Context, System Boundary, System Environment, Evolution Considerations Operational Concept: ID stakeholders, Determine Responsibilities, Coordinate Operational Scenarios, System Concept Shared Vision and Context for Stakeholders: Common system visions, goals, language and understanding, Rationalize capabilities
25 Lecture #6 OCD Completion Criteria (LCA) Elaboration of system objectives and scope by system increment Elaboration of operational concept by system increment All scenarios (stakeholder-critical nominal and off-nominal) coordinated with clients SSAD satisfies operational concept Tracing between Project Goals and Organization Goals and Activities Tracing between System Responsibilities and Project Goals and Organization Activities
26 Lecture #6 OCD Audience and Participants Audience Customer for Domain Description Domain Domain Expert for System Analysis Use language and define CDL appropriately for intended audience Participants Same stakeholders as WinWin negotiation Establish concept of operation agreed on by all stakeholders
27 Lecture #6 OCD High-Level Dependencies WinWin Negotiations Give System Responsibilities Changes Considered But Not Included Domain Description Terms Project Goals, Quality Goals OCD Yields Project, System and Quality Reqs for SSRD Domain Description and Initial Analysis for SSAD Stakeholder and Organizational Responsibilities Business Case Analysis parameters for FR