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

1Lecture #6

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

2Lecture #6

MBASE Conceptual Framework

3Lecture #6

MBASE WinWin Spiral

4Lecture #6

MBASEProcess: 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.

5Lecture #6

MBASE Invariants and VariantsInvariants Variants

1. Defining and sustaining a stakeholderwin-win relationship through thesystem's life-cycle.

2. Using the MBASE Model IntegrationFramework.

3. Using the MBASE Process IntegrationFramework.

4. Using the LCO and LCA Anchor Pointmilestones.

5. Ensuring that the content of MBASEartifacts and activities is risk-driven.

1. Use of particular success, process,product, or property models.

2. Choice of process or productrepresentation.

3. Degree of detail of process, product,property, or success modeling.

4. Number of spiral cycles or buildsbetween anchor points.

5. Mapping of activities onto Inception-Elaboration-Construction-Transitionphases.

6. Mapping of staff levels onto activities.

6Lecture #6

MBASE Invariants1. Defining and sustaining a stakeholder win-winrelationship throughout a system's life-cycle

a. A project organized to achieve the stakeholder win-winobjectives is the focus of MBASE activity.

b. A system characterized by a system boundary scopes theproject's authority and responsibility.

c. A project’s direct authority and responsibility may notcover the entire system’s life cycle, but it needs to involvethose with authority and responsibility over the rest of thesystem’s life cycle as critical system stakeholders.

7Lecture #6

MBASE Invariants2. Building as-you-go integrity relationships within andamong the project’s process, product, property, andsuccess models. [static relationships and constraintsacross the various MBASE models being integrated]

Retrofiting integrity relationships (late fixes of modelclashes) causes

-much larger amounts of rework and-deflated expectations.

MBASE Model Integration Framework addresses theamong-models integrity relationships.

Within-models relationships involve things like the productmodel OCD/SSRD/SSAD traceability relationships

8Lecture #6

3. Achieving model integrity relationships via theWinWin Spiral Process and MBASE Process IntegrationFramework. [dynamic relationships and constraintsacross the various MBASE models being integrated]

This is a Project Responsibility: model clashes will occur

ifrelationships and constraints are not satisfied

4. Managing stakeholder life cycle commitments via theLCO, LCA, and IOC Anchor Point milestones.Implicitly identifies the constituent elements andassociated reviews and pass/fail conditions of theAnchor Point milestones as invariants.

MBASE Invariants

9Lecture #6

MBASE Invariants4. Continued: constituent elements and associatedreviews 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.

10Lecture #6

MBASE Invariants4. Continued: constituent elements and associatedreviews 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 canmerge its LCO and LCA packages and reviews.

-For simple systems or upgrades, the project may choose to integrate its OCD, SSRD, and SSAD.

11Lecture #6

MBASE Invariants5. Ensuring that the content of MBASE artifacts andactivities 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 reviewingspecifying testing etc.prototyping documenting

e.g. a simple application to automate some pre-specifiedtax tables may have no need to prototype at all

12Lecture #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 fora small upgrade to a well-documented legacy system usingstructured analysis and design, for example.

The choice may vary by legacy constraints, nature ofapplication (pure dataflow vs. pure event-based), stafffamiliarity, 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.

13Lecture #6

MBASE Variants(6) Mapping of activities onto Inception-Elaboration Construction-Transition phases.

Most of the activity elements will be spread across multiplephases.

Their relative activity levels by phase may vary a lot.-stakeholders may require a lot of negotiation of top-levelrequirements in Inception and little negotiation of detailedrequirements in Elaboration-vice versa.

(7) Mapping of staff levels onto activities.

14Lecture #6

MBASE Variants for CS3156/4156Product 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 & ScheduleQuality:

-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.

15Lecture #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

ActiveTemplates

ProcessGuide

ModelGuide

“The Trinity”

16Lecture #6

MBASE Model Guidelines2. Domain DescriptionThe Domain Description (which focuses on the current system and organization) establishes the context forthe system to be developed and determine what is or is not relevant to the project. It consists of severalviews, which describe the domain of the project (i.e., the context in which the project will be developed anddeployed, including the organization, stakeholders, etc.) at various levels of generality from the customer'sand domain expert's perspective. It provides the distilled rationale for: Why the system is being built What overall organization goals and activities the proposed system will support and be responsible for

when deployed Where the project is starting from (i.e. "what" is there at present to build from, what is missing, and

needed, etc.)The goal is not to describe the entire organization, rather to faithfully sample enough information toprovide a working context for the System Analysis (“What” the proposed system is precisely). The workingcontext serves to avoid building a system that is too general by limiting its scope to what adds value for thecritical stakeholders. This provides a tangible means to measure what is or is not relevant to the project.All sections of the Domain Description should be written in a language understood by all the stakeholdersin the project (with particular customers and domain experts). This generally means describing concepts ata high, non-technical level.

Course Guidelines:Don't go too high in the organization for your project's organization background and goals. ColumbiaUniversity's overall goals may include improving Columbia University's rank in lists of the top U.S.universities, but it is too hard to relate the project goals for a multimedia archive to such organization goals.We recommend using Columbia University's Digital Library Initiatives (http://www.columbia.edu/dlc/) asan appropriate organizational context. Here is a working good statement for these initiatives:

"To make Columbia University’s reference materials more rapidly, reliably, easily and effectivelyaccessible to the Columbia University community, subject to appropriate information protection,fairness, and economic constraints."

At this level of organization goals, the mapping to project goals is more meaningful and straightforward.For your application, it is appropriate to elaborate these overall organizational goals to relate to your projectgoals (e.g., defining an aspect of "easily accessible" as bringing the reference materials to the user ratherthan vice versa), or to particular goals of your client's organization (e.g., Seaver Science Library, MarshallSchool of Business Library).

17Lecture #6

MBASE Process Guidelines

18Lecture #6

MBASE Active Templates

19Lecture #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 “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

20Lecture #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. 2.1.2, 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”

21Lecture #6

Operations Model

Object Model

Capability Requirements

System Definition

Class Model

Project Requirements

Statement of Purpose

Project Goals

Organization Goals

System Capabilities

Component ModelOrganization Entities

Behavior ModelActivity Model

Enterprise model

Domain Description System Analysis System 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

22Lecture #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!!!

23Lecture #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.

24Lecture #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

25Lecture #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

26Lecture #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

27Lecture #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