MBASE Retrospective

1
MBASE Retrospective

• Software engineering with MBASE
• Use of models
• MBASE Model Integration Framework

2
Ingredients of a project
Product Const. Delivery Maint.
3
MBASE Artifact Collections
OCD
SSRD
SSAD
FRD/CTS
LCP
CTS
4
MBASE Artifacts
Proj. Reqs. Capability Reqs. Level of Service
Reqs. Evolution Reqs. SSRD
OCD Org. Background Org. Goals Entity Model Org.
Activities System Shortfalls System
Capabilities Levels of Service Op.
Stakeholders Op. Impacts
Iterations Release Description Test Plan Test
Results Inspection Report Users Manual
CTS
SSAD Component Model Behavior Model Enterprise
Model Architectural Views Object Model Class
Model Operations Model
FRD/CTS Business Case Reqs. Satisfaction Process
Rationale Risk Assessment Iteration Plan Quality
Plan
LCP Milestones and Products Responsibilities Appro
ach, Resources
Not exhaustive
5
MBASE Retrospective

• Software engineering with MBASE
• Use of models
• MBASE Model Integration Framework

6
People-Technology Gap

• Technology
• Specific

7
People-Technology Gap
Characteristics of Computers
Characteristics of People
1.
Non-linear
1.
Linear
2.
Abstract
2.
Concrete
3.
Continuous
3.
Discrete
4.
Context sensitive
4.
Context free
5.
Active
5.
Passive
6.
Creative
6.
Logical
7.
Inconsistent
7.
Consistent
8.
Need doughnuts
8.
Need batteries
9.
Semantic
9.
Syntactic
10.
Highly parallel (small task)
10.
Sequential
11.
Approximate (PAC, PACE)
11.
Exact
12.
Learn
12.
Represent
13.
Do as they want
13.
Do as theyre told
14.
Make choices
14.
Compute
15.
Flexible (usually)
15.
Rigid
16.
Desires power
16.
Needs power
17.
Informal
17.
Formal
Software people tend to focus more on the
technologies context rather than the customer. -
E.Port
8
But

• The software development landscape is not so
  idyllic.

9
Traditional and Current SW Development

• Traditional Development
• Standalone systems
• Stable requirements
• Rqts. determine capabilities
• Control over evolution
• Enough time to keep stable
• Repeatability-oriented process, maturity models

• Current SW Development
• Everything connected--maybe
• Rapid requirements change
• COTS capabilities determine rqts.
• No control over COTS evolution
• Ever-decreasing cycle times
• Adaptive process models
• Overly constrained resources (budget, schedule,
  staff, etc.)
• Unrealistic expectations

10
Models Are Tools Used to Visualize and Manage
Complex Software Facets

• Win-Win Business Case Analysis
  Results Chains
• Risk Software Warranties Correctness
• RAD Six Sigma Stories
• Award Fees Agility
• JAD QFD
• Golden Rule

• Waterfall
• Spiral RUP XP
• SAIV CAIV SCQAIV
• Risk Management
• Business Process Reengineering
• CMMs Peopleware
• IPTs Agile Development
• Groupware Easy WinWin
• Experience Factory GQM

• UML XML
• CORBA COM
• Architectures
• Product Lines
• OO Analysis Design
• Requirements
• Operational Concepts
• Domain Ontologies
• COTS GOTS

• Value Models
• COCOMO II
• COCOTS CORADMO
• Cost-Benefit Models
• Performance Reliability COQUALMO
• System Dynamics Simulation Analytic
  Models

Red items USC research
11
But

• Even with many powerful and useful tools...

12
Software Engineering Is Not Well-Practiced
Today-Standish Group CHAOS Report 1995
On-time On-budget
Discontinued
Seriously Overrun

• Averages
• 189 of original budget
• 221 of original schedule
• 61 of original functionality

13
No scene from prehistory is quite so vivid as
that of the mortal struggles of great beasts in
the tar pits.
Large system programming has over the past decade
been such a tar pit, and many great and powerful
beasts have thrashed violently in it. Fred
Brooks, 1975
14
Everyone seems to have been surprised by the
stickiness of the problem, and it is hard to
discern the nature of it.
But we must try to understand it if we are to
solve it. Fred Brooks, 1975
15
Understanding the Tar Pit Model Clashes

• Model Clash An incompatibility among the
  underlying assumptions of a set of models
• Process, product, property, and success models
• Often unrecognized
• Produces conflicts, confusion, mistrust,
  frustration, rework, throwaway systems

16
Where do Models (and Clashes) Come From?

• Childhood training
• - Golden Rule, easiest - first
• Past experience
• - Waterfall, Add people to speed up
• Exaggerating for effect
• - Quality is free, COTS marketing
• Government/Corporate policy
• - Use waterfall, use COTS, use Ada, use 4GLs,
  Cost as Independent Variable
• Built-in conflicts among stakeholder success
  models

17
Models and Modeling
Software System

• Model (Webster)
• A description or analogy used to help
  visualize or analyze something a pattern of
  something to be made
• For us is representation of an aspect of
  software development based on a set of
  assumptions
• Models may use other models as part of their
  assumptions (e.g.., COCOMO uses multiplicative
  regression, WinWin uses Theory W)

18
Assumptions and Models
Assumption A statement that is taken for
granted as true Example COCOMO cost drivers
are multiplicative Model a consistent set of
assumptions and their logical derivations that
represent a viewpoint Example COCOMO
represents the effort viewpoint of a project.
It has another assumption that states effort is
proportional to (SIZE)E. Hence the logical AND
implies that effort is proportional to the cost
drivers AND (SIZE)E Note these assumptions are
only taken to be true with respect to the COCOMO
model itself
19

• Issues involved in Using Models (summary)
• Typically multiple models are used within a
  project.
• Based on assumptions of the projects
  stakeholders or inherited policies, cultures,
  COTS products.
• Assumptions of models are not always explicitly
  known
• or communicated.
• Compatibility of assumptions within and between
  models
• are often not assessed.
• It is difficult to explicitly determine all
  assumptions for a given model.
• Typically people take it for granted that a
  collection of models will not clash.

20
Model-Clash An incompatibility among the
assumptions of a set of models Note It is
possible that the combined set of assumptions
from two models cannot be represented itself as a
model. In particular if two assumptions are
inconsistent. Basic fact When models clash
there is always risk
21
Example IKIWISI success model assumes
requirements are generated after something is
implemented (prototype) Waterfall process model
assumes nothing is implemented until requirements
are specified. There is no model in which both of
above statements are consistent Can you see the
risk if one attempts to use both these models?

• You have already experienced many examples of
  model clashes within your project and will see
  more in 577B

22
Inter and Intra Model clash examples
Property Model
Success Model
Product Model
Process Model





Product Model








Structure clash

COTS
-
driven
Interdependent
4GL
-
based



product vs.
multiprocessor
product vs. low
Traceability
Waterfall
product vs. linear
development cost
clash

(requirements
-
performance
e
and performance

driven) process

scalability model

scalability









Multi
-
increment
Evolutionary
Waterfall proce
ss

development
development
model vs. "I'll
Process Model
process vs. single
-
process vs.
know it when I see
increment
Rayleigh
-
curve
it" (IKIWISI)
support tools

cost model

prototyping
success model







Minimize cost
Fixed
-
price
Property Model
and schedule vs.
contract vs. easy
-
maximize quality
to
-
change, volatile
(Quality is free)

requirements






Golden Rule v
s.
Success Model

stakeholder win
-
win



23
Taxonomy of Model-Clash Causes
Model-Clash Cause
Description
Examples  
Inconsistency    
An assumption in one model is inconsistent with
an assumption in another model      
   An organization goal that does not map to a
project goal or a level of service goal
Necessary assumption(s) about the product
has/have been omitted from the model
Necessary information about interfacing with
other systems are missing
Omission
An assumption whose conclusion cannot be
established with certainty as true
System performance increases linearly with number
of processors
Un-soundness
Over-specification
Assumptions with no relevant elements to satisfy
them
Specifying requirements that can not be
implemented within specified budget and
schedule  
24
MBASE Retrospective

• Software engineering with MBASE
• Use of models
• MBASE Model Integration Framework

25
Basic problem

• Identifying and managing (avoiding, mitigating,
  etc.) model clashes is a complex and overwhelming
  task!

26
Success Model-Clashes profile MasterNet
Acquirers
Users
PD
SS
Many features
Mission cost/effectiveness
PD
Changeable Requirements
PP
Limited budget, schedule
PD
Applications Compatibility
SS
Government standards Compliance
PP
High levels of Service
SS
Political correctness
PC
PC
Voice in acquisition
Development visibility control
PC
PC
Flexible Contract
Rigorous contract
PP
Early Availability
PD
PC
Flexible contract
Ease of of Transition
PD
PP
Ease of Maintenance
Ease of meeting budget schedule
PD
PD
Applications Compatibility
Stable requirements
PC
PC
Voice in acquisition
Freedom of choice Process
PC
Freedom of choice Team
PD
Freedom of choice COTS/reuse
Maintainers
Developers
27
Issues with model clash identification

• What are the models?
• What are the assumptions for the models?
• Did you find all (critical) model clashes?
• What about hyper model clashes?
• What do you do once you identify a model clash?
• How does mitigation of one clash affect the other
  models? More clashes?

28
One View Model Integration
Success Models

• Win-Win Business Case Analysis
  Results Chains
• Risk Software Warranties Correctness
• RAD Six Sigma Stories
• Award Fees Agility
• JAD QFD
• Golden Rule

Product Models

• Waterfall
• Spiral RUP XP
• SAIV CAIV SCQAIV
• Risk Management
• Business Process Reengineering
• CMMs Peopleware
• IPTs Agile Development
• Groupware Easy WinWin
• Experience Factory GQM

• UML XML
• CORBA COM
• Architectures
• Product Lines
• OO Analysis Design
• Requirements
• Operational Concepts
• Domain Ontologies
• COTS GOTS

MBASE, CeBASE

• Value Models
• COCOMO II
• COCOTS CORADMO
• Cost-Benefit Models
• Performance Reliability COQUALMO
• System Dynamics Simulation Analytic
  Models

Process Models
Red items USC research
Property Models
29
Serve and satisfy
Stakeholders
Negotiate
mutually
satisfactory
entry and
context in
exit
conditions
Domain
models
Success
models
Set
Constrain
context
Provide
for
measures
Provide
for
parameters
Product
for
models
Property
models
Guide
development
Provide
of
parameters
for
Process
Constrain
models
Success
Models
Product
Process
evaluation
entry/exit
criteria
criteria
Process
Planning and control
Product
Models
Models
Ad-hoc integration
Milestone content
Evaluation and
analysis
Property

• Multi Hyper-graph problem is O(2n)
  relationships are not just binary

Models
MBASE Framework

• Is approximately O(n3)
• Model clusters (semi-orthogonal)
• separation of element and behavior integrations
  and well-defined relations
• Claims
• Enables focus on high risk areas
• forms a basis for model integration

complete lt 12
Effort(capabilities)
Capabilities (C1, C2, C3)
30
MBASE Integration Framework Reduces Risk
Ad hoc
MBASE Framework
Risk
Risk
Acceptable risk level
number of models integrated
number of models integrated

• Too many relationships to check (can be as bad as
  O(2n))
• Risk profile for uniform selection (no
  preference) of models is approximately linear

• Fewer more well-defined integrations
• Risk profile is better than linear due to focus
  on high risk areas first

31
So at last
32
MBASE DefinedVariance and Invariance
MBASE systems engineering is intentionally very
broad in order to encompass a broad spectrum of
projects large and small. Invariant universal
for all MBASE projects. Variant can be adjusted
according to particular project parameters (team
size, application scope, etc.).
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-Construct
ion-Transition phases. 6. Mapping of staff
levels onto activities.
33
Invariants 1, 2, 3, 5 MBASE Model Integration
Framework

• MBASE Spiral
• Handles invariants 1, 5 (stakeholders, win-win,
  risk)
• Drives stakeholders activities (what to do, how
  long, to what extent)
• MBASE Behavioral Integration (Invariant 2)
• Defines the behavioral integration between models
  invariant
• Shared activities or operations between models
• Relationships of activities and operations
  between models
• MBASE Element Integration (Invariant 3)
• Defines the element integration between models
  invariant
• Shared elements or operational elements
• Inputs and outputs of models

34
MBASE Model Integration Framework
2. Identify stakeholders
win conditions
3. Reconcile
Serve and satisfy
1
. Identify
win
Stakeholders
next level
conditions,
stakeholders
establish
Describe
enterprise
objectives,
context in
constraints,
and
alternatives
Domain
7
. Review,
models
commit
Success
models
Set
Constrain
context
6. Validate
for
Provide
4. Evaluate
product
parameters
Product
product
and process
for
models
and process
definitions
Property
alternatives
models
Guide
development
Provide
5. Define next level of
of
parameters
product and process
for
Process
Constrain
LCO
MBASE Spiral
models
LCA
Behavioral Integration
IOC
Success
Models
Product
Process
evaluation
entry/exit
criteria
criteria
Planning and control
Product
Process
Models
Models
Milestone content
Evaluation and
analysis
Element Integration
Property
Models
35
Invariant 4 Life Cycle Anchor Points

• Common System/Software stakeholder commitment
  points
• Defined in concert with Government, industry
  affiliates
• Coordinated with Rationals Unified Software
  Development Process
• Life Cycle Objectives (LCO)
• Stakeholders commitment to support system
  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 your first child

36
MBASE Milestone Elements
37
MBASE Milestone Elements (2)
38
Anchor Points and Rational USDP Phases
Engineering Stage
Manufacturing Stage
Inception
Elaboration
Construction
Transition
LCO
LCA
IOC
Feasibility Iterations
Architecture Iterations
Usable Iterations
Product Releases
R E Q
D E S
I M P
D E P
R E Q
D E S
I M P
D E P
R E Q
D E S
I M P
D E P
Management
Management
Management
39
Example MBASE Variation (Schedule)
All teams formed
LCO ARB
LCA ARB
LCA Due
Initial WinWin draft prototype
LCO Due
IOC Due
CU S99
IOC Demos
week
2.5
6
10
12
13
14
15
16
All teams formed
LCO ARB
LCA ARB
Initial WinWin draft prototype
LCA Due
LCO Due
IOC Due
CU F99
IOC Demos
week
2
4.5
7
8
12.5
11.5
14
15
577B
All teams formed
LCA ARB
LCO ARB
Re-team
Transition Readiness Review
LCA Due
Draft prototype
LCA Re-baseline ARB
Initial WinWin
IOC Delivery
LCO Due
USC
week
2
6.5
5.5
9.5
10.5
14
15
17
21
28
40
Example MBASE integration
41
Problem Statement 4 Medieval Manuscripts
Ruth Wallach, Reference Center, Doheny Memorial
Library
I am interested in the problem of scanning
medieval manuscripts in such a way that a
researcher would be able to both read the
content, but also study the scribes hand,
special markings, etc. A related issue is that
of transmitting such images over the network.
42
(No Transcript)
43
Domain Model Block Diagram
44
Example MBASE Model Integration
Software Product Production Function for success,
property, and product models
Natural speech input
Animated graphics
Tertiary Application Functions
Secondary application functions
Humanized I/O
Value of software product to organization
Main application functions
Basic application functions
Operating
system
Data management
Availability of
delivery by time T
Investment
High
-
payoff
Diminishing returns
50
90
Likelihood of completion in 12 mo.
45
Organization management Developers Project
manager Domain experts .
Project Manger Domain Experts
1
. Identify
next level
stakeholders
Multimedia Info. Sys.
LCO
LCA
IOC
46
Secondary application functionsHumanized
I/O Main application functions Basic application
functions Data management
Project Manger Domain Experts
1
. Identify
next level
stakeholders
Multimedia Info. Sys.
Describe Multimedia System
LCO
LCA
IOC
Basic Capabilities Main Capabilities
47
Project Manger Domain Experts
1
. Identify
Negotiate ? 12 months high-pay off range
next level
stakeholders
Multimedia Info. Sys.
Describe Multimedia System
LCO
LCA
IOC
Basic Capabilities Main Capabilities
capabilities in high payoff range
Schedule ? 12 months
Basic Capabilities Main Capabilities
Design to schedule
48
Project Manger Domain Experts
1
. Identify
Negotiate ? 12 months high-pay off range
next level
stakeholders
Implement enough caps to be in the high pay-off
region ? 12 months
Multimedia Info. Sys.
Describe Multimedia System
LCO
Schedule ? 12 months
LCA
COCOMO II
IOC
Basic Capabilities Main Capabilities
Estimate FPs
Check for 12 month schedule. adjust cost drivers
capabilities in high payoff range
Schedule ? 12 months
Design to schedule
Basic Capabilities Main Capabilities
Design to schedule
FPs and product cost drivers
12 months schedule, cost drivers
COCOMO II
49
Project Manger Domain Experts
1
. Identify
Negotiate ? 12 months high-pay off range
next level
stakeholders
Implement enough caps to be in the high pay-off
region ? 12 months
Multimedia Info. Sys.
Describe Multimedia System
LCO
5. Define next level of
product and process
Schedule ? 12 months
LCA
COCOMO II
IOC
Basic Capabilities Main Capabilities
Capability FPs
Check for 12 month schedule. adjust cost drivers
Design as many basic and main capabilities FPs
for 12 month schedule
capabilities in high payoff range
Schedule ? 12 months
Basic capability design plan
Design to schedule
Basic Capabilities Main Capabilities
Design to schedule
Basic capabilities design
FPs and product cost drivers
12 months schedule, cost drivers
COCOMO II
50
Project Manger Domain Experts
1
. Identify
Negotiate ? 12 months high-pay off range
next level
stakeholders
Implement enough caps to be in the high pay-off
region ? 12 months
6. Validate
Is schedule ? 12 months?
product
Multimedia Info. Sys.
and process
definitions
Describe Multimedia System
LCO
5. Define next level of
product and process
Schedule ? 12 months
LCA
COCOMO II
IOC
Basic Capabilities Main Capabilities
Capability FPs
Check for 12 month schedule. adjust cost drivers
Design as many basic and main capabilities FPs
for 12 month schedule
capabilities in high payoff range
Schedule ? 12 months
Basic capability design plan
Design to schedule
Basic Capabilities Main Capabilities
Design to schedule
Basic capabilities design
FPs and product cost drivers
12 months schedule, cost drivers
COCOMO II
51
Does basic capabilities design satisfy needs?
Project Manger Domain Experts
1
. Identify
Negotiate ? 12 months high-pay off range
next level
stakeholders
7
. Review,
commit
Implement enough caps to be in the high pay-off
region ? 12 months
6. Validate
Is schedule ? 12 months?
product
Multimedia Info. Sys.
and process
definitions
Describe Multimedia System
LCO
5. Define next level of
product and process
Schedule ? 12 months
LCA
COCOMO II
IOC
Basic Capabilities Main Capabilities
Capability FPs
Check for 12 month schedule. adjust cost drivers
Design as many basic and main capabilities FPs
for 12 month schedule
capabilities in high payoff range
Schedule ? 12 months
Basic capability design plan
Design to schedule
Basic Capabilities Main Capabilities
Design to schedule
Basic capabilities design
FPs and product cost drivers
12 months schedule, cost drivers
COCOMO II
52
Another basic problem

• Manually applying MBASE integration is complex
  and gets worse proportionally to project size.
  Also, the MBASE framework only deals with some of
  the model clash issues.

53
Hence the MBASE guidelines
54
MBASE Model Areas
Success Models
OCD 3.2 Organization Goals OCD 3.7 Current System
Shortfalls OCD 4.4 Levels of Service FRD 2.2
Requirements Satisfaction
Product Models
OCD 3.5 Current Entity Model OCD 3.3 Current
Org. Activity Model OCD 4.2 Capabilities OCD 3.4
Description of Current Sys OCD 4.5 Proposed
System Description SSRD 3.2 System
Requirements SSRD 6. Evolution Requirements SSAD
2. Architectural Analysis SSAD 3. System Design
LCP 2. Milestones and Products LCP 3.
Responsibilities LCP 4. Approach LCP 5.1 Work
Breakdown Structure
MBASE
SSRD 2. Project Requirements SSRD 5. Level of
Service Requirements LCP 5.2 Budgets FRD 2.1
Business Case Analysis FRD 4. Project Risk
Assessment
Process Models
Property Models
Partial List

• Areas (OCD, SSRD, SSAD, LCP,FRD) provide
  placeholders for models
• Areas are integrated according to MBASE framework

55
Coverage/Traceability of MBASE Product Models
Domain Description
System Analysis
System Design
Implementation
System Definition
Statement of Purpose
Release Description
Organization Background
Project Requirements
Project Goals
Reqs. Satisfaction
Organization Goals
Levels of Service Goals
LOS Requirements
LOS Tests
Capability Requirements
System Capabilities
Capability Tests
Organization Activities
Operations Model
Behavior Model
Methods/functions
Object Model
Component Model
Organization Entities
Data Structures
Enterprise model
Interaction Model
Class Model
Operational Concept Description (OCD)
Construction,Transition,Support (CTS)
External to MBASE
System and Software Requirements Definition (SSRD)
Does not include all MBASE models
System and Software Architecture Description
(SSAD)
56
Example Trace Map
OCD 3.5
OCD 3.3
Manage lending of books to patrons
Implementation
Book
Book Checkout Table (Oracle)
The USC Leavy Library maintains research books
and periodicals for use by the USC community.
OCD 3.5
OCD 3.1
OCD 3.5
USC Patron
SSAD 3.2
Librarian
OCD 4.5.2
Checkout Input Panel
Library Card
SSAD 3.2
This system manages book checkout, check-in, and
overdue notifications for the Leavy Library.
Checkout Input Panel Controller
OCD 4.1
SSAD 2.1
OCD 4.3
Librarian checkout interface
Handle book lending for library card
Implementation
This system provides an automated interface for
Leavy Librarians for managing book lending for
walk-in patrons.
SSAD 2.2
Panel Controller class (Java)
SSRD 3.2
Checkout books
SSRD 3.1
Checkout book from patron with library card number
SSAD 3.3
SSAD 3.3
Verify library card
Store book in checkout table
57
More About MBASE

• MBASE is any framework that explicitly satisfies
  the MBASE Invariants as listed previously
• MBASE identifies and avoids model clashes in a
  win-win, risk driven manner through explicit
  model integration
• USC has several versions of MBASE (CS577,
  Columbia University 3156/4156, COTS Based, small
  systems, agile)
• Typically MBASE is instantiated through a set
  of guidelines that address the LCO/LCA/IOC
  milestone elements according to to the
  invariants.
• We have found MBASE an effective means of
  incorporating SWE concepts, in particular
  extensive economic modeling