1 Lecture #7 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. Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.
Transcript
1Lecture #7
MBASEProcess: 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.
Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.
2Lecture #7
MBASE Invariants and VariantsInvariants Variants
1. Defining and sustaining a stakeholderwin-win relationship through thesystem's life-cycle.
2. Using the MBASE Model IntegrationFramework.
3. Using the MBASE Process IntegrationFramework.
4. Using the LCO and LCA Anchor Pointmilestones.
5. Ensuring that the content of MBASEartifacts and activities is risk-driven.
1. Use of particular success, process,product, or property models.
2. Choice of process or productrepresentation.
3. Degree of detail of process, product,property, or success modeling.
4. Number of spiral cycles or buildsbetween anchor points.
5. Mapping of activities onto Inception-Elaboration-Construction-Transitionphases.
6. Mapping of staff levels onto activities.
3Lecture #7
MBASE Guidelines
• MBASE Model 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
ActiveTemplates
ProcessGuide
ModelGuide
“The Trinity”
4Lecture #7
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
5Lecture #7
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”
6Lecture #7
Operations Model
Object Model
Capability Requirements
System Definition
Class Model
Project Requirements
Statement of Purpose
Project Goals
Organization Goals
System Capabilities
Component ModelOrganization Entities
Behavior ModelActivity Model
Enterprise model
Domain Description System Analysis System Requirements
Operational Concept Description (OCD)
System and Software Requirements Definition (SSRD)
System and Software Architecture Description (SSAD)
Organization Background
Organization Activities
Interaction Model
Levels of Service Levels of Service Requirements
Integration of MBASE System Definition Elements
System Design
7Lecture #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.
8Lecture #7
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
9Lecture #7
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
10Lecture #7
OCD Audience and Participants
Audience• 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
11Lecture #7
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
12Lecture #7
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.
13Lecture #7
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
• Requirements Satisfiable by at least one system/software architecture
15Lecture #7
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
16Lecture #7
SSRD Audience and Participants
Audience• Domain Expert and Customer (decision makers)
• Implementers and Architects
Participants• Same stakeholders as WinWin negotiation
17Lecture #7
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
18Lecture #7
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
19Lecture #7
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
20Lecture #7
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
21Lecture #7
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
22Lecture #7
SSAD Audience and Participants
Audience• 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)
23Lecture #7
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
24Lecture #7
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.
25Lecture #7
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
26Lecture #7
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
27Lecture #7
LCP Audience and Participants
Audience• 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
28Lecture #7
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.
29Lecture #7
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
30Lecture #7
FRD Completion Criteria (LCO)
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
31Lecture #7
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.
32Lecture #7
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
33Lecture #7
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)
34Lecture #7
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
35Lecture #7
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
36Lecture #7
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
37Lecture #7
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.)
