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

“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

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.

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

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

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

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

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

MBASE Integration Framework

MBASE Conceptual Framework

MBASE Conceptual Framework

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

Clashes Among MBASE Models

MBASE Model Clashes

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

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)

Class Milestones September 20 All teams formed October 4-8 WinWin Client Negotiation Results; Initial Prototype October 14 LCO Drafts on Web Site October 14-17 LCO Package Architecture Review Boards October 22 LCO Package Due November 19 LCA Drafts on Web Site November 19-23 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 14-21 Product Demos December

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

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)

MBASE WinWin Spiral

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)

MBASE Invariants and Variants

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

MBASE Model Guidelines

MBASE Process Guidelines

MBASE Active Templates

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

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”

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)

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