1. Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.
“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

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

3. Understanding the Tar Pit: Model Clashes
Model (Webster): A description or analogy used to help visualize or analyze something; a pattern of something to be made
Includes product models, process models, property models, success models
Model Clash: An incompatibility among the underlying assumptions of a set of models
Produces conflicts, confusion, mistrust, frustration, rework, throwaway systems
Model Integration: Choosing and/or reengineering models to reconcile their underlying assumptions.

4. Examples of Model Clashes
Product Model Clashes: structure clashes, traceability clashes, architectural style clashes
COTS-driven product and Waterfall process
Risk-based process and spec-based progress payments
Design-to-cost process and tightly-coupled architecture
Incremental process and Rayleigh-curve staffing model
Evolutionary development without life-cycle architecture
Golden Rule and stakeholder win-win
Spec-based process and IKIWISI success model
I’ll know it when I see it

5. Classic Model Clashes In Practice
Model Clashes and Tar Pits:
Bank of America Master Net Example
Master Net Stakeholders
Master Net Contract
Initial Progress
The Tar Pit
The Bottom Line
Contributing Model Clashes
R.Glass, Software Runaways, Prentice Hall, 1998, PP

6. Reconciling Model Clashes
Use stakeholders’ success models, domain models to drive choices of other models
MBASE conceptual framework
Example: Process model decision table
Reconcile underlying assumptions
Example model clash patterns
Pre-package domain-integrated models
Successful examples

7. Where’s It All Going? Win-Win • Business Case Analysis
Software Warranties • QFD
10X • Six Sigma
Award Fees
JAD • RAD
UML
CORBA • COM
Architectures
Product Lines
OO Analysis & Design
Domain Ontologies
COTS • GOTS
Spiral
Waterfall
Risk Management
Business Process Reengineering
CMM’s • Peopleware
IPT’s • Objectory
Groupware
COCOMO
COCOTS • Checkpoint
System Dynamics
Metrics • - ilities
Simulation and Modeling

8. One View: Models Needing Integration
Win-Win • Business Case Analysis
Software Warranties • QFD
10X • Six Sigma
Award Fees
JAD • RAD
Success Models
Product
Models
Spiral
Waterfall
Risk Management
Business Process Reengineering
CMM’s • Peopleware
IPT’s • Objectory
Groupware
UML
CORBA • COM
Architectures
Product Lines
OO Analysis & Design
Domain Ontologies
COTS • GOTS
MBASE
COCOMO
COCOTS • Checkpoint
System Dynamics
Metrics • - ilities
Simulation and Modeling
Process
Models
Property Models

9. MBASE Integration Framework

10. MBASE Conceptual Framework

11. MBASE Conceptual Framework

12. MBASE Model Integration: LCO Stage
Domain Model
determines
determines
identifies
identifies
WinWin
Taxonomy
Basic Concept
of Operation
Frequent
Risks
Stakeholders,
Primary win conditions
focus
use of
focus
use of
situates
exercise
exercise
determines
serves
as table of
contents
for
WinWin
Negotiation
Model i n t a l z e s
IKIWISI Model,
Prototypes,
Properties Models
Environment
Models
provides
inputs for
guides
determination of
validate
WinWin Agreements
update
update
initialize
adopt
identify
identify
Viable
Architecture
Options
Updated Concept
of Operation
Life Cycle Plan
elements
Outstanding
LCO risks
Requirements
Description
iterate to
achieve
feasibility,
consistency
determines exit
LCO Rationale
Anchor Point
Model
criteria for
validates readiness of
Life Cycle Objectives (LCO) Package
determines content of

13. Clashes Among MBASE Models

14. MBASE Model Clashes

15. Success Models Drive Other Model Choices
Demo agent-based E-commerce system at COMDEX in 9 months
Safe air traffic control system
Success Model
Key Stake-holders
Entrepreneurs, venture capitalists, customers
Controllers, Govt. agencies, developers
Key Property Models
Schedule estimation
Safety models
Initial spiral to risk-manage COTS, etc.; Final waterfall to verify safety provisions
Process Model
Design-to-schedule
Domain constrained by schedule; architected for ease in dropping features to meet schedule
Architected for fault tolerance, ease of safety verification
Product Model

16. MBASE Deliverables General Considerations
Operation Concept Description (OCD)
System and Software Requirements Definition (SSRD)
System and Software Architecture Description (SSAD)
Life Cycle Plan (LCP)
Feasibility Rationale Description (FRD)

17. Class Milestones September 20 All teams formed
October 4-8 WinWin Client Negotiation Results; Initial Prototype
October 14 LCO Drafts on Web Site
October LCO Package Architecture Review Boards
October 22 LCO Package Due
November 19 LCA Drafts on Web Site
November LCA Package Architecture Review Boards
November 29 LCA Package Due; Construction well underway; Testing and Debugging commence
December 10 IOC Drafts on Web Site
December 13 IOC Packages Due, Individual Critiques Due Finals Week
December Product Demos December

18. Life Cycle Anchor Points
Inception
Elaboration
Construction
Transition
Iteration 1
Iteration 2
Iteration 3
Iteration 4
Iteration 5
Iteration 6
Iteration 7
Major
Milestones
LCO
LCA
IOC
Full
Release
Life Cycle Objectives (LCO)
Like getting engaged
Life Cycle Architecture (LCA)
Like getting married
Initial Operational Capability (IOC)
Like having your first child

19. Continuous Integration Iterative Development
Project Results
Continuous Integration
Progress
(% coded)
IOC
Final Qual Test
Final Qual Test
100 90
Iterative Development
Integration Begins 80
LCA 70
Late Design
Breakage 60
LCO
Conventional 50 40 30 20 10
Time (months)

20. MBASE WinWin Spiral

21. Where Are We Now? Overview of MBASE
Operation Concept Description (OCD)
System and Software Requirements Definition (SSRD)
System and Software Architecture Description (SSAD)
Life Cycle Plan (LCP)
Feasibility Rationale Description (FRD)

22. MBASE Invariants and Variants

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

24. MBASE Model Guidelines

25. MBASE Process Guidelines

26. MBASE Active Templates

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

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

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

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