CS 551 – Software Life Cycle

Key Question

What’s the problem?

“…[I]n software there has always been a great willingness to make changes in the specifications, and this makes the job tenuous; hardware peoplehave a habit of freezing a design and not letting a large number of new things be incorporated into it.When you allow changes you risk errors, delays and cost overruns.”

R.W. Hamming, preeminent softwarephilosopher

Journal of Systems Integration, Vol. 6, Number 1/2, March 1996, Kluwer AcademicPublishers Boston ISSN: 0925-4676, p. 6

Software Requirements Process

Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype Requirements Management

Five Great Processes

Solo Virtuoso

Code Ownership

Engage QA

Divide and Conquer Prototype

Reference: Technical Memorandum by J. O. Coplien Document No. BL0112650-940906-50TM

Product Size Reduction

TRADITIONAL PROCESS PROTOTYPING

40% REDUCTION

20%

80%

40%

30%

45%

25%

SystemsEngineering

Design,Develop,

Test,Install

FinalDevelopment,Deployment

SystemsEngineering &

Prototype

FinalDevelopment

Deployment

‘Code then fix’

Test

Fix

Code

Run

This approach leads to unstructured, unstable software that sometimes meets users’ needs. Problems are hard to find and harder to fix.

Analysis

Design

Coding

Testing

Integration

• Document Focused

• Phases in lockstep

• Encourages point solutions

• Mistakes found late

• Leads to tightly coupled systems

The Waterfall Model

•Risk Focused

•Incremental and iterative

•Evolutionary Feature Discovery

•Prototyping with quick feedback

•Continuous integration

Analysis Design

Testing Coding

The Spiral Model

Extreme Programming (XP)

Test before Coding Pair Programming On-Site Customers Ad hoc functionality Evolutionary Development Continuous Integration Short Cycles with Feedback Incremental Development

Vision

People Process Product Project (control, risk, schedule, trustworthiness) Technology and Platforms (rules, tools, assets) People work days, computers work nights Work, not people, needs to be mobile Productivity must continue to double with no loss of

reliability or performance

CHAOS

Customer Interests

I N S T A L L A T I O N

Before

• Features• Price• Schedule

After

• Reliability• Response Time• Throughput

• Customer buys off-the-shelf

• System works with 40-60% flow- through

• Developers complies with enhancements

BUT

• Customer refuses critical Billing Module

• Customer demands 33 enhancements and tinkers with database

• Unintended system consequences

Why bad things happen to good systems

Lessons Learned

One common process is not the goal Commonly managed processes are possible Scalability is essential

CMM LEVEL FOCUS KEY PROCESS AREAS

5 Optimizing

Continual Process Improvement

Defect prevention, Technology change management,Process change management

4 Managed Product and process quality

Quantitative process management,Software quality management

3 Defined Engineering processes and organizational support

Organization process focus, Organization process definition, Training program, Integrated software management, Software product engineering, Intergroup coordination, Peer reviews

2 Repeatable

Project management processed

Requirements management, Software project planning, software project tracking and oversight, Software subcontract management, Software QA, Software configuration management

1 Initial Competencies And heroics and small teams

Brooks: System Production

Program Programming System

Programming Product Programming System Product

x3

x3

x9

Techniques for Project Planning

Some sort of work breakdown structure, tasks into subtasks with constraints

Beware of over and under analysis Beware of diffuse responsibility Gantt chart - Microsoft project (do not represent

dependencies between activities) Identify critical path activities (should know w/o

automation) Sensitivity analysis - “what if” questions Also informal methods -- milestones

Mindset

Move from a culture of minimal change to one of maximal change.

Move to "make it work, make it work right, make it work better" philosophy through prototyping and delaying code optimization.

Give the test teams the "right of refusal" for any code that was not reasonably tested by the developers.

Productivity

Productivity =

F {people,

system nature,

customer relations,

capital investment}

As of 8/31/06

People 20:1

20:1 difference between people but ‘20:1ers’ are 1% of population

Code ownership with one developer making module changes; apprentice permitted

Source module size = 20-40 new function points; smaller modules carry too much overhead; larger modules become too big for people to understand

Production module size - constrained only by the execution environment

System Nature 10:5:1

If Report Generation Software =1, then On-line Software =5, and Communications or Real-time =10 1:5:10 is the degree of difficulty or complexity

which impacts productivity

Customer Relations 2:1

Projects that team with customers are twice as productive as those that have contracts

Prototypes build customer relations and increase productivity by 40%.

Capital Investment

100:1 improvement every 20 years measured by the expansion factor

OOT coming with 3:1 potential Objects in the large, and 80% reuse by turn of the

century

Function Point MetricFunction Point MetricF

un

ctio

n P

oin

ts/S

taff

Mo

nth

Technology

0

2

4

6

8

10

12

14

16

18

20

IDMS IMS MVS Oracle UNIX VM Composite

80 Projects 98 Projects

Benefits of Objects:

1. Manages complexity

2. Speeds development

3. Encourages module reuse

4. Enables scaling

Prerequisites for Supporting Object-Oriented Design:

1. Software technologies and techniques

2. Tools and infrastructure

3. Management process and culture

4. Know-how

Objects

3

15

3037.5

47

75

113142

475

638

81

1

10

100

1000

1960 1965 1970 1975 1980 1985 1990 1995 2000

ExpansionFactor

TechnologyChange:

RegressionTesting

4GL Small ScaleReuse

MachineInstructions

High LevelLanguages

MacroAssemblers

DatabaseManagers

On-LineDev

Prototyping SubsecTimeSharing

ObjectOrientedProgramming

Large ScaleReuse

Order of MagnitudeEvery Twenty Years

Each date is an estimate of widespread use of a software technology

The ratio ofSource line of code to a machine level line of code

Trends in Software Productivity

Barry Boehm

USC Center for Systems and Software Engineering

Keynote Address, EQUITY 2007

March 19, 2007

Revisiting Software Engineering Economics

Implications for the future

Estimation Value-based approaches Agility Systems-of-Systems

Software Estimation: 1980’s Expectations

Unprece-dented

Prece-dented

EstimationError

Domain Understanding

Software Estimation: The Receding Horizon

Unprece-dented

Prece-dented

Component-based

RADOpen Source

Systems of Systems

A B C D

RelativeProductivity

EstimationError

Domain Understanding

RAD: Rapid Application Development

The Future of Systems and Software

Eight surprise-free trends1. Increasing integration of SysE and SwE2. User/Value focus3. Software Criticality and Dependability4. Rapid, Accelerating Change5. Distribution, Mobility, Interoperability, Globalization6. Complex Systems of Systems7. COTS, Open Source, Reuse, Legacy Integration8. Computational Plenty

Three surprises9. Autonomy and Adaptable Software10. Combinations of Biology and Computing11. Multi-threading returns

Why Software Projects Fail

Pareto 80-20 distribution of test case value [Bullock, 2000]

Actual business value

% of Valuefor

CorrectCustomer

Billing

Customer Type

100

80

60

40

20

5 10 15

Automated test generation tool

- all tests have equal value

% of Valuefor

CorrectCustomer

Billing

Customer Type

100

80

60

40

20

5 10 15

Automated test generation tool

- all tests have equal value

Business Case for Value-Based Testing

-1

-0.5

0

0.5

1

1.5

2

0 20 40 60 80 100

% Tests Run

Ret

urn

on

Inve

stm

ent

(RO

I)

Pareto testing ATG testing

Defect Removal Estimates- Nominal Defect Introduction Rates

60

28.5

14.37.5

3.5 1.60

10

20

30

40

50

60

70

VL Low Nom High VH XH

Delivered Defects/ KSLOC

Composite Defect Removal Rating

Trustworthy Trends

Software increasingly success-critical to product and services• Provides competitive differentiation, adaptability to change

Dependability is generally not vendors’ top-priority• “The IT industry spends the bulk of its resources… on rapidly bringing

products to market.” – US PITAC Report By 2025, there will be a “9/11” – magnitude software failure

that will raise trustworthiness to priority 1• Major loss of life or collapse of world financial system• Market demand; stronger warranties and accountability• Value-based trustworthy processes and tools

But other trends will make trustworthy solutions harder• System complexity, globalization, rapid change