Presentation on theme: "MBASE Process: WinWin Spiral"— Presentation transcript:
1MBASE Process: WinWin Spiral Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.MBASEProcess: WinWin SpiralThree principals to visualizing application development1. Integrating four system model, each one capturingspecific attributes2. All four models have specific interdependencies3. An iterative spiral that is anchored with managementmilestones. At each anchor point, key stakeholdersdecide whether and how to proceed.Philosophy: Eliminate or mitigate model clashes byconcurrently evolving· Requirements· Other key choices: e.g. architecture, operational concepts, etc.
3MBASE Guidelines MBASE Model Guide MBASE Process Guide describes modelsdescribes suggested model creation approach (variant)MBASE Process GuideDescribes activities and dynamic model integrationlarge, so provided in EPGredundant with model guide (at present)MBASE Active TemplatesProcessGuide“The Trinity”ModelGuideActiveTemplates
4General MBASE Considerations Made up of OCD, SSRD, SSAD, LCP, and FRD and various IOC plansCollaboration Essential, Elements Strongly Integratedthis reduces risk overallKeep deliverables in sync, strong interdependenciesConceptual integrity critical! Be consistent, traceable,…LCO: less structure, detail, more “vision” - major issuesLCA: no “TBD”s, formal, no unresolved issuesIOC: only detail what was actually builtGenerally no set number of pagesbe concise, but cover, “lean and mean”be willing to “throw away”meet completion or “exit” criteria
5General MBASE Considerations Cont. Avoid repetition, instead reference the information. Avoid “broken” or “blind” or “vague” referencesDo not include text from guidelines, without relating to your projectFollow formatting guidelines (grader win-condition!)Describe what things are for your project, not the guidelinesOutline 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 relevantrisk driven documentationIOC guidelines separated from LCO/LCAthere are places that they integrate and mixlook out for “construction phase”
6Integration of MBASE System Definition Elements Domain DescriptionSystem AnalysisSystem RequirementsSystem DefinitionStatement of PurposeOrganization BackgroundProject GoalsProject RequirementsOrganization GoalsLevels of ServiceLevels of Service RequirementsOrganization ActivitiesSystem CapabilitiesCapability RequirementsSystem DesignOrganization EntitiesComponent ModelObject ModelActivity ModelBehavior ModelOperations ModelInteraction ModelEnterprise modelClass ModelOperational Concept Description (OCD)System and Software Requirements Definition (SSRD)System and Software Architecture Description (SSAD)
7Purpose of OCDDescribe 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.
8OCD Completion Criteria (LCO) Top-level system objectives: Organizational Context, System Boundary, System Environment, Evolution ConsiderationsOperational Concept: ID stakeholders, Determine Responsibilities, Coordinate Operational Scenarios, System ConceptShared Vision and Context for Stakeholders: Common system visions, goals, language and understanding, Rationalize capabilities
9OCD Completion Criteria (LCA) Elaboration of system objectives and scope by system incrementElaboration of operational concept by system incrementAll scenarios (stakeholder-critical nominal and off-nominal) coordinated with clientsSSAD satisfies operational conceptTracing between Project Goals and Organization Goals and ActivitiesTracing between System Responsibilities and Project Goals and Organization Activities
10OCD Audience and Participants Customer for Domain Description DomainDomain Expert for System AnalysisUse language and define CDL appropriately for intended audienceParticipantsSame stakeholders as WinWin negotiationEstablish concept of operation agreed on by all stakeholders
11OCD High-Level Dependencies WinWin Negotiations GiveSystem CapabilitiesDomain Description Terms (CDL)Project Goals and ConstraintsOCD YieldsProject, System and Level of Service Reqs for SSRDDomain Description and Initial Analysis for SSADStakeholder and Organizational ResponsibilitiesBusiness Case Analysis parameters for FR
12Purpose of SSRDDescribe Capability Requirements: system subject matter measured by concrete meansDescribe 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.
13Requirements in General Describe a contract between the developers and the customercustomer: if the developers build these requirements, then I agree that the system is builtdeveloper: if I build these requirements, then I have built a satisfactory system for the customerthis is very misleading and full of strong assumptions!Important: all requirements must be implementable and testableGotha’s:vague requirementsvolatile requirements“hidden” or implied requirements
14SSRD Completion Criteria (LCO) Top-level capabilities, interfaces, quality attribute levels: Growth vectors (evolution reqs), PrioritiesStakeholders’ Concurrence on EssentialsRequirements Satisfiable by at least one system/software architecture
15SSRD Completion Criteria (LCA) Elaboration of capabilities, interfaces, quality attributes by iteration. Resolution of TBDs, Elaboration of evolution reqsStakeholders’ concurrence on priority concerns (prioritization)Traces SSRD (and indirectly to FRD, LCP)Requirements satisfiable by the architecture in the SSAD
16SSRD Audience and Participants Domain Expert and Customer (decision makers)Implementers and ArchitectsParticipantsSame stakeholders as WinWin negotiation
17SSRD High-Level Dependencies (Page 1) SSRD Depends on WinWin TaxonomyOutline of SSRD evolves from taxonomyNo one-size-fits-all taxonomy or requirements descriptionImportance of adapting taxonomy to domainSSRD Depends on OCD for:Statement of PurposeProject GoalsSystem Capabilities
18SSRD High-Level Dependencies (Page 2) SSRD Depends on Prototype for:User Interface RequirementsAdditional documents depend on SSRD:SSAD to obtain System and Project RequirementsLCP to relate requirement priorities to system increments or to requirements to be dropped in a design-to-cost/schedule development planFRD to check for satisfaction of: Capability, Interface, Quality, and Evolution Requirements
19Purpose of SSADDocuments the Architectural Analysis and the System Design, “blueprint”Serves As A Bridge between Engineering (Inception and Elaboration) and Construction PhaseThe SSAD is refined during the Construction Phase into a Software Detailed Design SpecificationThe SSAD should not repeat information from other documents: reference other information. Vital to project integration and cohesion. Conciseness is paramount
20SSAD Completion Criteria (LCO) Top-level definition of at least one feasible architecture: Physical/Logical elements, choices of COTS and reusable elements, detailed analysisFeasibility 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 PlanIdentify infeasible architecture options
21SSAD Completion Criteria (LCA) Choice of architecture and elaboration by iteration: physical/logical components, COTS, Architectural style, deployment considerations, critical algorithms, analysis issues resolved in designArchitecture evolution parametersComplete design for each component of the systemTracing to and from OCD/SSRDAssurance of Satisfaction of Feasibility Criterion
22SSAD Audience and Participants Domain Expert for System AnalysisImplementers for System DesignParticipantsSystem ArchitectDomain Experts (to validate analysis models)Implementers (to validate design models)Project Managers (to test feasibility)
23SSAD High-Level Dependencies SSAD depends on OCD for:Statement of PurposeProject Goals and ConstraintsSystem ResponsibilitiesSSAD depends on SSRD for:System Definition and RequirementsLevel of Service RequirementsProject RequirementsFRD depends on SSAD to ensure that:Project, Capability, Interface, and Evolution Requirements are achievable
24Purpose of LCPBasis for monitoring and controlling the project’s progressBasis for controlling the project's progress in achieving the software product objectivesHelps make the best use of people and resources throughout the life cycleProvides evidence that the developers have thought through the major life cycle issues in advanceOrganized to answer the most common questions about a project or activity: why, what, when, who, where, how, how much, and whereasMaintaining the conceptual integrity between the tasks and the things they create/solve is a prime quality criterion.
25LCP Completion Criteria (LCO) ID life-cycle stakeholders: users, customers, developers, maintainers, interfacers, general public, othersTop-level stages, increments: Top-level WWWWWHH (Why, What, When, Who, Where, How, How Much) by stageMajor risks IdentifiedAchieve deliverables, budgets, and schedules: by at least one system/software architecture
26LCP Completion Criteria (LCA) Elaboration of WWWWWHH for Initial Operational Capability (IOC). Partial elaboration, identification of key TBDs for later incrementsAll major risks resolved or covered by risk management planAchieve deliverables, budgets and schedules by the architecture in the SSAD
27LCP Audience and Participants Primarily for the performer teams in each stageImportant for customersUseful for other stakeholders.ParticipantsProject 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
28LCP 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.
29Purpose of FRDEnsure feasibility and consistency of other package components (OCD, SSRD, SSAD, LCP, Prototype)Demonstrate viable business case for the systemIdentify shortfalls in ensuring feasibility, consistency, and business case as project risk items for LCPDemonstrate 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 docsRationalize life cycle decisions in a way the prime audience (the customer and users) and other stakeholders can understandEnable the customers to participate in the decision process and to express their satisfaction with the product
30FRD 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 architecturesLCAAssurance of consistency among elements above for the architecture specified in the SSADAll major risks resolved or covered by risk management plan
31FRD AudienceThe primary audiences are the LCO and LCA Architecture Review Board membersKey system stakeholdersExperienced peersTechnical Specialists in critical areasThe 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.
32FRD Participants Project manager responsible for content OCD author should prepare business caseAll stakeholders responsible for consistency and feasibility via Win-Win negotiationsAgreements can be contingent on demonstration of feasibility
33FRD 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)
34IOC Plans To be discussed later Preview by looking at the MBASE IOC guidelinesCompletion criteria is generally editing the models to “as-built” status so that they reflect the IOC of the system
35Starting Your Project Meet with your team communication basic approachalternativesfail-safe, “crunch” times, etc.designate basic responsibilities“leads” not “do-all”be flexiblerisks, constraints, problemsexpectations for projectstick with positive only
36Starting Your Project Meet with your TA communication how your TA can help betweenyour team and the customeryour team and the classdiscuss class expectations and possible problemsscheduling of reviewsgrading concernsresource issuesproject concerns
37Starting Your Project Meet with your customer communication basic approachalternativesfail-safe, “crunch” times, etc.Domain interview (see recitation!)CDL (OCD 4.)Start building DD (OCD 2.)Scope project (simps/comps)manage expectationsdiscuss top risks and their severityDiscuss next stepsWinWin negotiations