Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Lecture #3 WinWin Stakeholder Roles Developer: The Architecture and Prototype team members will represent developer concerns, such as use of familiar.

Similar presentations

Presentation on theme: "1 Lecture #3 WinWin Stakeholder Roles Developer: The Architecture and Prototype team members will represent developer concerns, such as use of familiar."— Presentation transcript:

1 1 Lecture #3 WinWin Stakeholder Roles 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. Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.

2 2 Lecture #3 The WinWin Spiral Model 2. Identify Stakeholders win conditions 1. Identify next-level Stakeholders Reconcile win conditions. Establish next level objectives, constraints, alternatives 3. Evaluate product and process alternatives. Resolve Risks 4. Define next level of product and process - including partitions 5. Validate product and process definitions 6. Review, commitment7. Win-Win Extensions Original Spiral

3 3 Lecture #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 4 Lecture #3 Elements of Critical Front End Milestones (Risk-driven level of detail for each element) Milestone ElementLife Cycle Objectives (LCO)Life Cycle Architecture (LCA) Definition of Operational Concept 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 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 TBDs( (to-be-determined items) Stakeholders concurrence on their priority concerns 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 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 Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBDs for later increments Assurance of consistency among elements above All major risks resolved or covered by risk management plan 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 Assurance of consistency among elements above - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Definition of System Requirements Definition of System and Software Architecture Definition of Life- Cycle Plan Feasibility Rationale *WWWWWHH: Why, What, When, Who, Where, How, How Much System Prototype(s) Exercise key usage scenarios Resolve critical risks Exercise range of usage scenarios Resolve major outstanding risks

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

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

8 8 Lecture #3 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 9 Lecture #3 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 10 Lecture #3 Conventional Software Process Time (months) Progress (% coded) Conventional Late design breakage Integration begins Problem: Late Tangible Design Assessment Standard sequence of events: Early and successful design review milestones Late and severe integration trauma Schedule slippage Design Reviews /

11 11 Lecture #3 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 % of the contribution comes from 20% of the contributors. Source: Boehm, September 1987

12 12 Lecture #3 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 13 Lecture #3 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 Complex software costs Diseconomy of scale What Makes Systems Complex? size/scale Software cost Software costs = E * (Size) P

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

15 15 Lecture #3 Software TechnologyLanguage LevelSupport Software MicroprogrammingBits: 100, 010 Machine languages F12, A07, 124, AAF Low- level languageInstructions:LDR, ADDX, Assemblers programming CLA, JMPS Linkers High- level languageLines: If A then B Compilers programmingloop Operating systems I = I + 1 Object-based and object-Objects and packages: Compilers oriented programmingType color is (red, yellow, green); Operating systems package traffic_light Runtime libraries when green go; Component based developmentComponents and services: Compilers Operating systems - ReuseOverlay map with grid; Runtime libraries - Automatic codingWhen failure switchover; Networks - COTS componentsShutdown all test processes; Middleware CASE tools Component Based Development

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

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

18 18 Lecture #3 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 Conventional risk Software engineering risk Megaprogramming risk Buy 10% Build 90% Buy 70% Build 30% Buy 30% Build 70% High ModerateLow Mostly R&D Mostly production Custom applications Reusable applications Architectural infrastructure Middleware Interchangeable operating systems Interchangeable hardware platforms

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

20 20 Lecture #3 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 –Tool support for this process Note: Our focus is on component-based development (supported by MBASE)

Download ppt "1 Lecture #3 WinWin Stakeholder Roles Developer: The Architecture and Prototype team members will represent developer concerns, such as use of familiar."

Similar presentations

Ads by Google