Presentation is loading. Please wait.

Presentation is loading. Please wait.

MBASE Integration Framework

Similar presentations

Presentation on theme: "MBASE Integration Framework"— Presentation transcript:

1 MBASE Integration Framework
Copyright 2000 by USC and the Center for Software Engineering, all rights reserved. MBASE Integration Framework

2 MBASE Conceptual Framework

3 MBASE WinWin Spiral

4 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 MBASE Invariants and Variants

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 project’s direct authority and responsibility may not cover the entire system’s life cycle, but it needs to involve those with authority and responsibility over the rest of the system’s life cycle as critical system stakeholders.

7 MBASE Invariants 2. Building as-you-go integrity relationships within and among the project’s 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 MBASE Invariants 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.

9 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 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 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 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 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 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 MBASE Guidelines MBASE Model Guide MBASE Process 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 Process Guide “The Trinity” Model Guide Active Templates

16 MBASE Model Guidelines

17 MBASE Process Guidelines

18 MBASE Active Templates

19 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 “TBD”s, 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 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 Integration of MBASE System Definition Elements
Domain Description System Analysis System Requirements System Definition Statement of Purpose Organization Background Project Goals Project Requirements Organization Goals Levels of Service Levels of Service Requirements Organization Activities System Capabilities Capability Requirements System Design Organization Entities Component Model Object Model Activity Model Behavior Model Operations Model Interaction Model Enterprise model Class Model Operational Concept Description (OCD) System and Software Requirements Definition (SSRD) System and Software Architecture Description (SSAD)

22 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 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 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 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 OCD Audience and Participants
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 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

Download ppt "MBASE Integration Framework"

Similar presentations

Ads by Google