Presentation is loading. Please wait.

Presentation is loading. Please wait.

WinWin Stakeholder Roles

Similar presentations

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’
Extensions 2. Identify Stakeholders’ win conditions 3. Reconcile win conditions. Establish next level objectives, constraints, alternatives 1. Identify next-level Stakeholders 7. Review, commitment 4. Evaluate product and process alternatives. Resolve Risks 6. Validate product and process definitions 5. Define next level of product and process - including partitions Original Spiral

3 Life Cycle Anchor Points
Life Cycle Objectives (LCO) Like getting engaged Life Cycle Architecture (LCA) Like getting married Initial Operational Capability (IOC) Like having your first child

4 Elements of Critical Front End Milestones
(Risk-driven level of detail for each element) Milestone Element Life Cycle Objectives (LCO) Life Cycle Architecture (LCA) Top-level system objectives and scope - System boundary - Environment parameters and assumptions - Evolution parameters Operational concept - Operations and maintenance scenarios and parameters - Organizational life-cycle responsibilities (stakeholders) Elaboration of system objectives and scope of increment Elaboration of operational concept by increment Definition of Operational Concept System Prototype(s) Exercise key usage scenarios Resolve critical risks Exercise range of usage scenarios Resolve major outstanding risks Definition of System Requirements Top-level functions, interfaces, quality attribute levels, including: - Growth vectors and priorities - Prototypes Stakeholders’ concurrence on essentials Elaboration of functions, interfaces, quality attributes, and prototypes by increment - Identification of TBD’s( (to-be-determined items) Stakeholders’ concurrence on their priority concerns Choice of architecture and elaboration by increment - Physical and logical components, connectors, configurations, constraints - COTS, reuse choices - Domain-architecture and architectural style choices Architecture evolution parameters Top-level definition of at least one feasible architecture - Physical and logical elements and relationships - Choices of COTS and reusable software elements Identification of infeasible architecture options Definition of System and Software Architecture Identification of life-cycle stakeholders - Users, customers, developers, maintainers, interoperators, general public, others Identification of life-cycle process model - Top-level stages, increments Top-level WWWWWHH* by stage Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBD’s for later increments Definition of Life- Cycle Plan Feasibility Rationale Assurance of consistency among elements above - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Assurance of consistency among elements above All major risks resolved or covered by risk management plan *WWWWWHH: Why, What, When, Who, Where, How, How Much

5 Initial Operational Capability (IOC)
Software preparation Operational and support software Data preparation, COTS licenses Operational readiness testing Site preparation Facilities, equipment, supplies, vendor support User, operator, and maintainer preparation Selection, teambuilding, training

6 Resolving Problems with LCO, LCA Milestones
LCO Resolution LCA Resolution Premature decisions Risk-driven detail of specifications Inflexible point solutions Rqts. growth vectors identified Rqts. growth vectors specified, accommodated Gold plating Business case analysis Stakeholder concurrence Feasibility rationale: risk resolution criterion Feasibility analysis and rationale High-risk sleepers Cost/schedule/quality oversights Life cycle plan, Stakeholder concurrence, Feasibility rationale Capabilities too far from user needs Stakeholder concurrence, Risk resolution SW VS. System Focus System objectives & scope, Ops. concept

7 Conventional vs. Iterative Process Models
Flowcharts Preliminary design Briefings and documents Design language Detailed Briefing and HOL source code Code and unit test Configuration baselines Integration test, selloff Test plans and reports The Conventional Software Engineering Model Format Activity Product Translation A Comparable Iterative Development Model Incremental applications development, integration Useful increments Configuration baselines Format Compilable, executable Architecture analyses and design Prototypes and demonstrations Configuration baselines Architecture integration demonstration Configuration baselines Testing, documentation, selloff Compliant products Activity Refinement Refinement Refinement Product

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 study U.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 practices Executive management support Clear requirements Proper planning User involvement

10 Conventional Software Process
Problem: Late Tangible Design Assessment Standard sequence of events: Early and successful design review milestones Late and severe integration trauma Schedule slippage Progress (% coded) / 100 90 Integration begins 80 70 60 Late design breakage Conventional 50 40 30 20 10 Design Reviews Time (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 Rule 80% 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 constraints Time-to-market pressures Certification requirements Distributed, real-time requirements Size and geographic distribution of the engineering team Reliability and fault-tolerance requirements Rate of requirements and technology change The interplay of these factors Software cost Complex software costs Diseconomy of scale size/scale Software costs = E * (Size)P

14 Current Software Technology Thrusts
Software Costs = E * (Size)P

15 Component Based Development
Software Technology Language Level Support Software Microprogramming Bits: 100, Machine languages F12, A07, 124, AAF Low- level language Instructions: LDR, ADDX, Assemblers programming CLA, JMPS Linkers High- level language Lines: If A then B Compilers programming loop Operating systems I = I + 1 Object-based and object- Objects and packages: Compilers oriented programming Type color is (red, yellow, green); Operating systems package traffic_light Runtime libraries when 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; Middleware CASE tools

16 Middleware: Distributed Megaprogramming
Developed and reused components Applications and architecture Pre-integrated reuse libraries Middleware Language runtime libraries Operating systems, networking protocols, and data representations Open systems standards Execution platforms Physical hardware resources Middleware software insulates applications from the complexity of distributed programming.

17 Technology State-of-the-Art Evolution
Conventional Software Engineering Target Separate but off-the-shelf Off-the-shelf and integrated Environment/tools Custom 30% megaprogrammed 70% custom 70% megaprogrammed 30% custom Size 100% custom Process/team Ad hoc Repeatable Managed and measured Predictable: Unpredictable: Infrequently Project performance Predictable: Competitive budget and schedule performance Always over budget, over schedule on budget, on schedule

18 Moving Toward Software Production
Applications Architectural infrastructure Middleware Single operating system Single H/W platform Applications Architectural infrastructure Middleware Single operating system H/W platform family Custom applications Reusable Architectural infrastructure Middleware Interchangeable operating systems hardware platforms Conventional risk Software engineering risk Megaprogramming risk Buy 10% Build 90% Buy 30% Build 70% Buy 70% Build 30% High Moderate Low Mostly R&D Mostly production

19 Software Cost Evolution
Conventional diseconomy of scale Software engineering Modern best practices Economy of scale Project Cost Software ROI Functionality, scale, and complexity Era Design method Process Architecture Languages Risk focus 1960s s Functional Waterfall Proprietary and centralized FORTRAN and COBOL Functionality 1980s s Declarative DOD-STD-2167A Proprietary and distributed C and Ada 83 Performance 1990s Object-oriented Iterative development Open distributed Ada 95 and C++ Adaptability

20 Prerequisites to Component-Based Development
Resilient, reusable application architectures Modeling language for architecture specification Process for architecture design, implementation, and testing Tool support for this process Standard architectures for key problem domains Architecturally compliant components Scalable, commercially successful infrastructure Modeling language for component specification Programming language support for component implementation Process for component design, implementation, and testing Note: Our focus is on component-based development (supported by MBASE)

Download ppt "WinWin Stakeholder Roles"

Similar presentations

Ads by Google