1Lecture #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.

2Lecture #3

The WinWin Spiral Model

2. Identify Stakeholders’win conditions

1. Identify next-levelStakeholders

Reconcile win conditions. Establishnext level objectives,constraints, alternatives

3.

Evaluate product and process alternatives.Resolve Risks

4.

Define next level of product andprocess - including partitions

5.

Validate productand processdefinitions

6.

Review, commitment7.

Win-Win Extensions

OriginalSpiral

3Lecture #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

4Lecture #3

Elements of Critical Front End Milestones(Risk-driven level of detail for each element)

Milestone Element Life Cycle Objectives (LCO) Life Cycle Architecture (LCA)

Definition of OperationalConcept

• 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 TBD’s( (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 TBD’s 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 SystemRequirements

Definition of Systemand SoftwareArchitecture

Definition of Life-Cycle Plan

FeasibilityRationale

*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

5Lecture #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

6Lecture #3

Resolving Problems with LCO, LCA MilestonesProblem

Premature decisions

Inflexible pointsolutions

Gold plating

High-risk sleepers

Cost/schedule/qualityoversights

Capabilities too farfrom user needs

LCO Resolution LCA Resolution

Risk-driven detail of specifications

Rqts. growth vectorsidentified

Rqts. growth vectorsspecified, accommodated

Business case analysisStakeholder concurrence

Feasibility analysisand 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

7Lecture #3

Flowcharts

Preliminarydesign

Briefings and documents

Design language

Detaileddesign

Briefing and documents

HOL source code

Code andunit test

Code and documents

Configurationbaselines

Integrationtest, selloff

Test plansand reports

The Conventional Software Engineering Model

Format

Activity

Product

Integration Translation Translation

Conventional vs. Iterative Process Models

Configurationbaselines

Testing,documentation,

selloff

Compliant products

Configuration baselines

Architectureintegration

Architecturedemonstration

Compilable,executable

Architectureanalyses and

design

Prototypes anddemonstrations

Incrementalapplications

development, integration

Usefulincrements

Configurationbaselines

A Comparable Iterative Development Model

Format

Activity

Product

Refinement Refinement Refinement

8Lecture #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

9Lecture #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

10Lecture #3

Conventional Software Process

Time (months)

Progress(% coded)

100

90

80

70

60

50

40

30

20

10

Conventional Late designbreakage

Integration begins

Problem: Late Tangible Design AssessmentStandard sequence of events: Early and successful design review milestones Late and severe integration trauma Schedule slippage

Design Reviews

/

11Lecture #3

Top 10 Software Metric Relationships1. 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

12Lecture #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.

13Lecture #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

Softwarecost

Software costs = E * (Size)P

14Lecture #3

Current Software Technology Thrusts

Software Costs = E * (Size)P

EEnvironment technologiesand tools

Integrated tools (compiler-editor-debugger-CM)Open systemsHardware platform performanceAutomation of documentation, testing, quality

analyses

Size(Human generated code)Component baseddevelopment technologies

Reuse, commercial-off-the-shelf (COTS) productsObject-oriented (analysis, design, programming)Higher level languages (Ada95, C++, VB, Java, etc.)CASE tools (automatic code generation)Distributed middleware

PProcess technologies andteamwork

Iterative developmentProcess maturity modelsArchitecture-first developmentAcquisition reformTraining and personnel skill development

15Lecture #3

Software Technology Language Level Support Software

Microprogramming Bits: 100, 010 Machine languages F12, A07, 124, AAF

Low- level language Instructions: LDR, ADDX, Assemblersprogramming CLA, JMPS Linkers

High- level language Lines: If A then B Compilersprogramming 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 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; Middleware

CASE tools

Component Based Development

16Lecture #3

Middleware: Distributed Megaprogramming

Applications and architecture

Operating systems, networkingprotocols, 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 complexityof distributed programming.

Pre-integrated reuse libraries

17Lecture #3

Technology State-of-the-Art Evolution

Custom

100% custom

Ad hoc

Separate butoff-the-shelf

30% megaprogrammed70% custom

Repeatable

Off-the-shelfand integrated

Managed andmeasured

Environment/tools

Size

Process/team

Conventional Software Engineering Target

Project performance over budget,over scheduleAlways

Predictable:on budget,on schedule

Unpredictable:Infrequently

Predictable:Competitive budget and schedule performance

70% megaprogrammed30% custom

18Lecture #3

Moving Toward Software ProductionApplications

ArchitecturalinfrastructureMiddleware

Single operatingsystem

Single H/W platform

Applications

ArchitecturalinfrastructureMiddleware

Single operatingsystem

H/W platform family

Conventionalrisk

Software engineering risk

Megaprogrammingrisk

Buy 10%Build 90%

Buy 70%Build 30%

Buy 30%Build 70%

High Moderate Low

Mostly R&D Mostly production

Customapplications

ReusableapplicationsArchitecturalinfrastructureMiddleware

Interchangeableoperating systems

Interchangeablehardware platforms

19Lecture #3

1960s 1970s

Functional

Waterfall

Proprietary and centralized

FORTRAN and COBOL

Functionality

Software Cost EvolutionSoftware engineering Modern best practices

ProjectCost

Conventionaldiseconomy 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

20Lecture #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)