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

2. MBASE Invariants and Variants

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

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

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

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

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

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

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

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

11. OCD High-Level Dependencies
WinWin Negotiations Give
System Capabilities
Domain Description Terms (CDL)
Project Goals and Constraints
OCD Yields
Project, System and Level of Service Reqs for SSRD
Domain Description and Initial Analysis for SSAD
Stakeholder and Organizational Responsibilities
Business Case Analysis parameters for FR

12. Purpose of SSRD
Describe Capability Requirements: system subject matter measured by concrete means
Describe Project, Level of Service, and Evolutionary (non-functional) Requirements: Behavioral properties of functions (performance, usability, etc.)
Describe Global Constraints: constraints that apply to the entire system as a whole (including interface, environment and Data reqs)
Mandates (“must”, “shall”, “will”): how the system must be implemented with respect to general tech.

13. Requirements in General
Describe a contract between the developers and the customer
customer: if the developers build these requirements, then I agree that the system is built
developer: if I build these requirements, then I have built a satisfactory system for the customer
this is very misleading and full of strong assumptions!
Important: all requirements must be implementable and testable
Gotha’s:
vague requirements
volatile requirements
“hidden” or implied requirements

14. SSRD Completion Criteria (LCO)
Top-level capabilities, interfaces, quality attribute levels: Growth vectors (evolution reqs), Priorities
Stakeholders’ Concurrence on Essentials
Requirements Satisfiable by at least one system/software architecture

15. SSRD Completion Criteria (LCA)
Elaboration of capabilities, interfaces, quality attributes by iteration. Resolution of TBDs, Elaboration of evolution reqs
Stakeholders’ concurrence on priority concerns (prioritization)
Traces SSRD (and indirectly to FRD, LCP)
Requirements satisfiable by the architecture in the SSAD

16. SSRD Audience and Participants
Domain Expert and Customer (decision makers)
Implementers and Architects
Participants
Same stakeholders as WinWin negotiation

17. SSRD High-Level Dependencies (Page 1)
SSRD Depends on WinWin Taxonomy
Outline of SSRD evolves from taxonomy
No one-size-fits-all taxonomy or requirements description
Importance of adapting taxonomy to domain
SSRD Depends on OCD for:
Statement of Purpose
Project Goals
System Capabilities

18. SSRD High-Level Dependencies (Page 2)
SSRD Depends on Prototype for:
User Interface Requirements
Additional documents depend on SSRD:
SSAD to obtain System and Project Requirements
LCP to relate requirement priorities to system increments or to requirements to be dropped in a design-to-cost/schedule development plan
FRD to check for satisfaction of: Capability, Interface, Quality, and Evolution Requirements

19. Purpose of SSAD
Documents the Architectural Analysis and the System Design, “blueprint”
Serves As A Bridge between Engineering (Inception and Elaboration) and Construction Phase
The SSAD is refined during the Construction Phase into a Software Detailed Design Specification
The SSAD should not repeat information from other documents: reference other information. Vital to project integration and cohesion. Conciseness is paramount

20. SSAD Completion Criteria (LCO)
Top-level definition of at least one feasible architecture: Physical/Logical elements, choices of COTS and reusable elements, detailed analysis
Feasibility Criterion: a system built to the architecture would support the operational concept, satisfy the requirements, be faithful to the prototypes, and be buildable within the budgets and schedules in the Life Cycle Plan
Identify infeasible architecture options

21. SSAD Completion Criteria (LCA)
Choice of architecture and elaboration by iteration: physical/logical components, COTS, Architectural style, deployment considerations, critical algorithms, analysis issues resolved in design
Architecture evolution parameters
Complete design for each component of the system
Tracing to and from OCD/SSRD
Assurance of Satisfaction of Feasibility Criterion

22. SSAD Audience and Participants
Domain Expert for System Analysis
Implementers for System Design
Participants
System Architect
Domain Experts (to validate analysis models)
Implementers (to validate design models)
Project Managers (to test feasibility)

23. SSAD High-Level Dependencies
SSAD depends on OCD for:
Statement of Purpose
Project Goals and Constraints
System Responsibilities
SSAD depends on SSRD for:
System Definition and Requirements
Level of Service Requirements
Project Requirements
FRD depends on SSAD to ensure that:
Project, Capability, Interface, and Evolution Requirements are achievable

24. Purpose of LCP
Basis for monitoring and controlling the project’s progress
Basis for controlling the project's progress in achieving the software product objectives
Helps make the best use of people and resources throughout the life cycle
Provides evidence that the developers have thought through the major life cycle issues in advance
Organized to answer the most common questions about a project or activity: why, what, when, who, where, how, how much, and whereas
Maintaining the conceptual integrity between the tasks and the things they create/solve is a prime quality criterion.

25. LCP Completion Criteria (LCO)
ID life-cycle stakeholders: users, customers, developers, maintainers, interfacers, general public, others
Top-level stages, increments: Top-level WWWWWHH (Why, What, When, Who, Where, How, How Much) by stage
Major risks Identified
Achieve deliverables, budgets, and schedules: by at least one system/software architecture

26. LCP Completion Criteria (LCA)
Elaboration of WWWWWHH for Initial Operational Capability (IOC). Partial elaboration, identification of key TBDs for later increments
All major risks resolved or covered by risk management plan
Achieve deliverables, budgets and schedules by the architecture in the SSAD

27. LCP Audience and Participants
Primarily for the performer teams in each stage
Important for customers
Useful for other stakeholders.
Participants
Project Manager: leads the baselining of the plan for that stage.
Plans for future stages: done by a designated team member during Engineering Stage.
Stakeholders should participate: if affected by plan

28. LCP High-Level Dependencies
Products specified by Requirements and Architecture must be buildable and supportable within the budgets and schedules in the Life Cycle Plan.
Plans for transition and support must be consistent with the Operational Concept Description.

29. Purpose of FRD
Ensure feasibility and consistency of other package components (OCD, SSRD, SSAD, LCP, Prototype)
Demonstrate viable business case for the system
Identify shortfalls in ensuring feasibility, consistency, and business case as project risk items for LCP
Demonstrate that a system built using the specified architecture (described in the SSAD) and life cycle process (described in the LCP) will fulfill prediction of other docs
Rationalize life cycle decisions in a way the prime audience (the customer and users) and other stakeholders can understand
Enable the customers to participate in the decision process and to express their satisfaction with the product

30. FRD Completion Criteria (LCO)
Assurance of consistency among elements above for at least one feasible architecture. Via analysis, measurement, prototyping, simulation, etc..
Business case analysis for reqs, feasible architectures
LCA
Assurance of consistency among elements above for the architecture specified in the SSAD
All major risks resolved or covered by risk management plan

31. FRD Audience
The primary audiences are the LCO and LCA Architecture Review Board members
Key system stakeholders
Experienced peers
Technical Specialists in critical areas
The parts dealing with client satisfaction must be understandable by the client representatives on the ARB.
The technical parts must be sufficiently detailed and well organized to enable the peers and technical experts to efficiently assess the adequacy of the technical rationale.
Valuable to developers and other stakeholders, provides a rationale for important decisions made by the project.

32. FRD Participants Project manager responsible for content
OCD author should prepare business case
All stakeholders responsible for consistency and feasibility via Win-Win negotiations
Agreements can be contingent on demonstration of feasibility

33. FRD High-Level Dependencies
The thoroughness of the Feasibility Rationale is dependent on the thoroughness of all the other LCO and LCA components.
Issues incompletely covered in the Feasibility Rationale are sources of risk, whose management should be covered in the Life Cycle Plan’s (LCP) Risk Management and Monitoring Procedures section (LCP 4.1)

34. IOC Plans To be discussed later
Preview by looking at the MBASE IOC guidelines
Completion criteria is generally editing the models to “as-built” status so that they reflect the IOC of the system

35. Starting Your Project Meet with your team communication
basic approach
alternatives
fail-safe, “crunch” times, etc.
designate basic responsibilities
“leads” not “do-all”
be flexible
risks, constraints, problems
expectations for project
stick with positive only

36. Starting Your Project Meet with your TA communication
how your TA can help between
your team and the customer
your team and the class
discuss class expectations and possible problems
scheduling of reviews
grading concerns
resource issues
project concerns

37. Starting Your Project Meet with your customer communication
basic approach
alternatives
fail-safe, “crunch” times, etc.
Domain interview (see recitation!)
CDL (OCD 4.)
Start building DD (OCD 2.)
Scope project (simps/comps)
manage expectations
discuss top risks and their severity
Discuss next steps
WinWin negotiations