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)