4 MBASE Process: WinWin Spiral Three 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.
6 MBASE Invariants 1. Defining and sustaining a stakeholder win-win relationship throughout a system's life-cyclea. A project organized to achieve the stakeholder win-winobjectives is the focus of MBASE activity.b. A system characterized by a system boundary scopes theproject's authority and responsibility.c. A project’s direct authority and responsibility may notcover the entire system’s life cycle, but it needs to involvethose with authority and responsibility over the rest of thesystem’s life cycle as critical system stakeholders.
7 MBASE Invariants2. Building as-you-go integrity relationships within andamong the project’s process, product, property, andsuccess models. [static relationships and constraintsacross the various MBASE models being integrated]· Retrofiting integrity relationships (late fixes of modelclashes) causes- much larger amounts of rework and- deflated expectations.· MBASE Model Integration Framework addresses theamong-models integrity relationships.· Within-models relationships involve things like the productmodel OCD/SSRD/SSAD traceability relationships
8 MBASE Invariants 3. Achieving model integrity relationships via the WinWin Spiral Process and MBASE Process IntegrationFramework. [dynamic relationships and constraintsacross the various MBASE models being integrated]· This is a Project Responsibility: model clashes will occur ifrelationships and constraints are not satisfied4. Managing stakeholder life cycle commitments via theLCO, LCA, and IOC Anchor Point milestones.Implicitly identifies the constituent elements andassociated reviews and pass/fail conditions of theAnchor Point milestones as invariants.
9 MBASE Invariants 4. Continued: constituent elements and associated reviews and pass/fail conditions· for LCO and LCA, includes the essential content of- Operational Concept Definition,- Requirements Definition,- Architecture Definition,- Life Cycle Plan, Key Prototypes, and- Feasibility Rationale- LCO and LCA Architecture Review Board reviews andtheir Feasibility Rationale-based pass-fail criteria.
10 MBASE Invariants 4. Continued: constituent elements and associated reviews and pass/fail conditions· For IOC, the essential content of the IOC deliverables for- Preparation of software, personnel, and facility- Transition Readiness Review + associated pass-fail criteria- Release Readiness Review + associated pass-fail criteria· Do not have to be separate events or definition documents.- For a 4GL application, the project has committed to the 4GL infrastructure's architecture, and the project canmerge its LCO and LCA packages and reviews.- For simple systems or upgrades, the project may choose to integrate its OCD, SSRD, and SSAD.
11 MBASE Invariants 5. Ensuring that the content of MBASE artifacts and activities is risk-driven Otherwise, the project will either· fail to achieve critical success conditions· waste effort performing unneeded or dysfunctional activitiesRisk criterion is the best way for a project to determine"how much is enough”· modeling · reusing · reviewing· specifying · testing · etc.· prototyping · documentinge.g. a simple application to automate some pre-specifiedtax tables may have no need to prototype at all
12 MBASE Variants(1) Use of particular success, process, product, or property models.(2) Choice of process or product representation.· UML may be appropriate for many applications, but not fora small upgrade to a well-documented legacy system usingstructured analysis and design, for example.· The choice may vary by legacy constraints, nature ofapplication (pure dataflow vs. pure event-based), stafffamiliarity, or tool support.(3) Degree of detail of process, product, property, or success modeling. Given Invariant 5, the degree of detail will vary based on risk considerations.
13 MBASE Variants(6) Mapping of activities onto Inception-Elaboration Construction-Transition phases.· Most of the activity elements will be spread across multiplephases.· Their relative activity levels by phase may vary a lot.- stakeholders may require a lot of negotiation of top-levelrequirements in Inception and little negotiation of detailedrequirements in Elaboration- vice versa.(7) Mapping of staff levels onto activities.
14 MBASE Variants for CS3156/4156Product Model: Baseline – OO/UML(RUP's) based modelsProcess Model: RAD; Schedule as Independent variable; 12 week construction – minimize risk of not finishingProperty Models:· COCOMO II + CORADMO Cost & Schedule· Quality:- Fagan's Inspection's defect data- Problem reports· IKIWISI: user friendlinessProcess representation: EPG; MBASE guidelinesProduct representation & method: RUP's use of UML plus …Number of spiral cycles: one in inception, 1.5 in elaboration,two (recommended) in construction.
15 MBASE 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
19 General 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
20 General 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”
21 Integration 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)
22 Modeling versus Documenting MBASE describes models, how to build them, and ways to communicate them.Documentation is a necessary consequence of modelingwhy?Also, the act of writing something down helps you solidify a modelCommunication is an essential part of the collaborative development approachAvoid documenting for documentation sake!Everything you document should be the result of modelingeverything you document should have value and meaning to stakeholders (think about risk here)The documentation are the models!!!The Models are the documentation!!!
23 Purpose 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.
24 OCD 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
25 OCD 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
26 OCD 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
27 OCD High-Level Dependencies WinWin Negotiations GiveSystem ResponsibilitiesChanges Considered But Not IncludedDomain Description TermsProject Goals, Quality GoalsOCD YieldsProject, System and Quality Reqs for SSRDDomain Description and Initial Analysis for SSADStakeholder and Organizational ResponsibilitiesBusiness Case Analysis parameters for FR