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