CS 551 – Software Life Cycle

Think like an engineer

What is Engineering?

Engineering is the quantitative & systematic application of knowledge to create and build cost-effective solutions to practical problems.

Making trade-offs.

What is systems engineering?

The systematic synthesis and analysis of solutions to problems with a focus on

1. Understanding the problem domain

2. Defining the clients needs creating a set of feature definitions that satisfy the need

3. Mapping the features to components that perform defined functions

4. Specifying the components and their interfaces

5. Studying the economic viability of the solution

Viewpoints

Systems engineers determine whatshould be.

Software engineers determine whatcan be.

Be able to answer these Four Questions

l Is this proposed software centric system feasible?l If it is, how much will it cost?l If we are willing to pay, how long will it take to

build and to deploy?l What is the development plan, especially the

detailed schedule?

“…[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

l Requirements Elicitation l Requirements Analysisl Use Casesl Requirements Specificationl Prototypel 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

‘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.

HACKING

PROBLEM

Reqts Spec

Tech Spec

Code

SystemReqts Eng

Design

Implem

ent

Tes

t Maintain

Simplified Model

Analysis

Design

Coding

Testing

Integration

• Document Focused

• Phases in lockstep

• Encourages point solutions

• Mistakes found late

• Leads to tightly coupled systems

The Waterfall Model

Waterfall Model with feedback

Reqts Eng

Design

Implementation

TestV&V

Maintenance

Waterfall: document-driven milestones

l Baselined Requirements Specificationl Baselined Test Planl Baselined Design Specificationl Baselined Codel Test Results report

Why is Waterfall still used?

l Easy to understand l Familiar to customers, steps make intuitive sensel ‘Natural’ Structure for new staff or teamsl Tight control by project managementl Requirements are stablel Forces documentation

Prototyping by Barry Boehm

Listen to customer Build/revise mockup

Customer test drives mockup

When finished: Design, Implement, Test, Maintain

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

•Risk Focused

•Incremental and iterative

•Evolutionary Feature Discovery

•Prototyping with quick feedback

•Continuous integration

Analysis Design

Testing Coding

The Spiral Model

Extreme Programming (XP)

l Test before Codingl Pair Programmingl On-Site Customers l Ad hoc functionalityl Evolutionary Developmentl Continuous Integrationl Short Cycles with Feedbackl Incremental Development

Vision

l Peoplel Processl Productl Project (control, risk, schedule, trustworthiness)l Technology and Platforms (rules, tools, assets)l People work days, computers work nightsl Work, not people, needs to be mobilel Productivity must continue to double with no loss of

reliability or performance

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

l One common process is not the goall Commonly managed processes are possiblel 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

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

l Beware of over and under analysisl Beware of diffuse responsibilityl Gantt chart - Microsoft project (do not represent

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

automation)l Sensitivity analysis - “what if” questionsl 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

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

l Code ownership with one developer making module changes; apprentice permitted

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

l Production module size - constrained only by the execution environment

System Nature 10:5:1

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

which impacts productivity

Customer Relations 2:1

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

l Prototypes build customer relations and increase productivity by 40%.

Capital Investment

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

l OOT coming with 3:1 potentiall 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

l Estimation l Value-based approachesl Agilityl 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

l 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

l 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

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

l 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

l By 2025, there will be a “9/11” – magnitude software failurethat 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

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