Presentation on theme: "WinWin Stakeholder Roles"— Presentation transcript:
1 WinWin Stakeholder Roles Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.Developer: The Architecture and Prototype team members will represent developer concerns, such as use of familiar packages, stability of requirements, availability of support tools, and technically challenging approaches.Customers: The Rationale team member will represent customer concerns, such as the need to develop an IOC in one semester, limited budgets for support tools, and low-risk technical approaches.User: The Operational Concept and Requirements team members will work with their designated user-community representative to represent user concerns, such as particular multimedia access features, fast response time, friendly user interfaces, high reliability, and flexibility of requirements.
2 The WinWin Spiral Model 2. Identify Stakeholders’ Extensions2. Identify Stakeholders’win conditions3.Reconcile winconditions. Establishnext level objectives,constraints, alternatives1. Identify next-levelStakeholders7.Review, commitment4.Evaluate product andprocess alternatives.Resolve Risks6.Validate productand processdefinitions5.Define next level of product andprocess - including partitionsOriginalSpiral
3 Life Cycle Anchor Points Life Cycle Objectives (LCO)Like getting engagedLife Cycle Architecture (LCA)Like getting marriedInitial Operational Capability (IOC)Like having your first child
4 Elements of Critical Front End Milestones (Risk-driven level of detail for each element)Milestone ElementLife Cycle Objectives (LCO)Life Cycle Architecture (LCA)Top-level system objectives and scope- System boundary- Environment parameters and assumptions- Evolution parametersOperational concept- Operations and maintenance scenarios and parameters- Organizational life-cycle responsibilities (stakeholders)Elaboration of system objectives and scope of incrementElaboration of operational concept by incrementDefinition ofOperationalConceptSystem Prototype(s)Exercise key usage scenariosResolve critical risksExercise range of usage scenariosResolve major outstanding risksDefinition of SystemRequirementsTop-level functions, interfaces, quality attribute levels,including:- Growth vectors and priorities- PrototypesStakeholders’ concurrence on essentialsElaboration of functions, interfaces, quality attributes,and prototypes by increment- Identification of TBD’s( (to-be-determined items)Stakeholders’ concurrence on their priority concernsChoice of architecture and elaboration by increment- Physical and logical components, connectors,configurations, constraints- COTS, reuse choices- Domain-architecture and architectural style choicesArchitecture evolution parametersTop-level definition of at least one feasible architecture- Physical and logical elements and relationships- Choices of COTS and reusable software elementsIdentification of infeasible architecture optionsDefinition of Systemand SoftwareArchitectureIdentification of life-cycle stakeholders- Users, customers, developers, maintainers, interoperators,general public, othersIdentification of life-cycle process model- Top-level stages, incrementsTop-level WWWWWHH* by stageElaboration of WWWWWHH* for Initial OperationalCapability (IOC)- Partial elaboration, identification of key TBD’s for laterincrementsDefinition of Life-Cycle PlanFeasibilityRationaleAssurance of consistency among elements above- via analysis, measurement, prototyping, simulation, etc.- Business case analysis for requirements, feasible architecturesAssurance of consistency among elements aboveAll major risks resolved or covered by risk managementplan*WWWWWHH: Why, What, When, Who, Where, How, How Much
5 Initial Operational Capability (IOC) Software preparationOperational and support softwareData preparation, COTS licensesOperational readiness testingSite preparationFacilities, equipment, supplies, vendor supportUser, operator, and maintainer preparationSelection, teambuilding, training
6 Resolving Problems with LCO, LCA Milestones LCO ResolutionLCA ResolutionPremature decisionsRisk-driven detail of specificationsInflexible pointsolutionsRqts. growth vectorsidentifiedRqts. growth vectorsspecified, accommodatedGold platingBusiness case analysisStakeholder concurrenceFeasibility rationale:risk resolution criterionFeasibility analysisand rationaleHigh-risk sleepersCost/schedule/qualityoversightsLife cycle plan, Stakeholder concurrence,Feasibility rationaleCapabilities too farfrom user needsStakeholder concurrence, Risk resolutionSW VS. SystemFocusSystem objectives & scope, Ops. concept
7 Conventional vs. Iterative Process Models FlowchartsPreliminarydesignBriefings anddocumentsDesign languageDetailedBriefing andHOL source codeCode andunit testConfigurationbaselinesIntegrationtest, selloffTest plansand reportsThe Conventional Software Engineering ModelFormatActivityProductTranslationA Comparable Iterative Development ModelIncrementalapplicationsdevelopment,integrationUsefulincrementsConfigurationbaselinesFormatCompilable,executableArchitectureanalyses anddesignPrototypes anddemonstrationsConfigurationbaselinesArchitectureintegrationdemonstrationConfigurationbaselinesTesting,documentation,selloffCompliantproductsActivityRefinementRefinementRefinementProduct
8 Software Industry Maturity 1/3 of all large-scale software developments are canceled.The average software development project overruns its schedule by 50%, larger projects usually by more.3/4 of all large-scale systems are operational failures: They do not function as intended or do not function at all.Software is still hand-crafted by artisans using techniques they cannot measure nor repeat consistently.Source: Scientific American, September 1994
9 The Software Crisis (Commercial Version) 1995 Standish Group studyU.S. companies will spend $81 billion for canceled software projects.31% will be canceled before they are completed.Over 50% will cost more than twice the original estimate.Only 9% will be delivered on time and within budget.Recommended practicesExecutive management supportClear requirementsProper planningUser involvement
10 Conventional Software Process Problem: Late Tangible Design AssessmentStandard sequence of events:Early and successful design review milestonesLate and severe integration traumaSchedule slippageProgress(% coded)/10090Integration begins807060Late designbreakageConventional5040302010DesignReviewsTime (months)
11 Top 10 Software Metric Relationships 1. Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases.2. You can compress software development schedules 25% of nominal, but no more.3. For every $1 you spend on development, you will spend $2 on maintenance.4. Software development and maintenance costs are primarily a function of No. of SLOC.5. Variations among people account for the biggest differences in software productivity.6. The overall ratio of software/hardware costs is still growing. 1955: 15/85; 1985: 85/15.7. Only about 15% of software development effort is devoted to programming.8. Software systems and products typically cost 3 times as much per SLOC as individual software programs. Software-system products (i.e., system of systems) cost 9 times as much.9. Walkthroughs catch 60% of the errors.10. 80% of the contribution comes from 20% of the contributors.Source: Boehm, September 1987
12 The 80/20 Rule80% of the engineering is consumed by 20% of the requirements.80% of the development cost is consumed by 20% of the components.80% of the errors are caused by 20% of the components.80% of development phase scrap and rework is caused by 20% of the errors.80% of the resource consumption (execution time, disk space, memory) is consumed by 20% of the components.80% of the engineering gets accomplished by 20% of the tools.80% of the progress is made by 20% of the people.
13 What Makes Systems Complex? Performance constraintsTime-to-market pressuresCertification requirementsDistributed, real-time requirementsSize and geographic distribution of the engineering teamReliability and fault-tolerance requirementsRate of requirements and technology changeThe interplay of these factorsSoftwarecostComplex software costsDiseconomy of scalesize/scaleSoftware costs = E * (Size)P
14 Current Software Technology Thrusts Software Costs = E * (Size)P
15 Component Based Development Software Technology Language Level Support SoftwareMicroprogramming Bits: 100, Machine languagesF12, A07, 124, AAFLow- level language Instructions: LDR, ADDX, Assemblersprogramming CLA, JMPS LinkersHigh- level language Lines: If A then B Compilersprogramming loop Operating systemsI = I + 1Object-based and object- Objects and packages: Compilersoriented programming Type color is (red, yellow, green); Operating systems package traffic_light Runtime librarieswhen green go;Component based development Components and services: Compilers Operating systems- Reuse Overlay map with grid; Runtime libraries- Automatic coding When failure switchover; Networks- COTS components Shutdown all test processes; MiddlewareCASE tools
16 Middleware: Distributed Megaprogramming Developed and reused componentsApplications and architecturePre-integrated reuse librariesMiddlewareLanguage runtime librariesOperating systems, networkingprotocols, and data representationsOpen systems standardsExecution platformsPhysical hardware resourcesMiddleware software insulates applications from the complexityof distributed programming.
19 Software Cost Evolution Conventionaldiseconomy of scaleSoftware engineeringModern best practicesEconomy of scaleProjectCostSoftware ROIFunctionality, scale, and complexityEraDesign methodProcessArchitectureLanguagesRisk focus1960s sFunctionalWaterfallProprietary and centralizedFORTRAN and COBOLFunctionality1980s sDeclarativeDOD-STD-2167AProprietary and distributedC and Ada 83Performance1990sObject-orientedIterative developmentOpen distributedAda 95 and C++Adaptability
20 Prerequisites to Component-Based Development Resilient, reusable application architecturesModeling language for architecture specificationProcess for architecture design, implementation, and testingTool support for this processStandard architectures for key problem domainsArchitecturally compliant componentsScalable, commercially successful infrastructureModeling language for component specificationProgramming language support for component implementationProcess for component design, implementation, and testingNote: Our focus is on component-based development (supported by MBASE)
Your consent to our cookies if you continue to use this website.