introduction to software engineering lecture 3 andré van der hoek

Introduction to Software Engineering

Lecture 3

André van der Hoek

Today’s Lecture

What makes software engineering difficult?

An introduction to software life cycle models

Visibility vs…

…Invisibility

Software as is cannot be viewed meaningfully Stack of paper Set of files

Software cannot be interpreted easily How to read source code? How to read a million lines of source code? How to read a part of source code?

Invisibility affects process How to measure progress?

Is a bigger stack of paper closer to the end-result than a smaller stack of paper?

Manageable Complexity vs…

…Unmanageable Complexity

Software cannot be easily abstracted Formulas

Only in very few domains Diagrams, graphs, and other representations

Typically non-hierarchical Far too many cross-references

Few concepts are available to use in an abstraction

Tension between high-level understanding and low-level detailed specification High-level understanding leaves out

important details Aggregation often does not work

Environment Can Be Changed vs…

…Environment Cannot Be Changed

Software has to adhere to the “world” in which it is placed Cannot change the hardware Cannot change the way people do business

The “world” is often not clearly specified How can you change something that you

cannot specify? Leads to many software changes

Perception is that software is easier to change

No Major Changes vs…

…Major Changes

Software is remarkably easy to change Change the source code, recompile, rerun “One line here, one line there”

Unfortunately, even small changes can have disastrous consequences A single wrong character can surreptitiously

change the behavior of the software The effects of most changes are only visible in

certain circumstances

Sometimes, the environment does change Software is used in different organizations Software is used for different purposes

Drastic Consequences

Deceased patients X-ray machine delivered very high doses

because of a timing problem in its control software

Crashed planes Software prevented pilots from performing

emergency maneuvers Software had similar codes for different

airports Decreased national security

NSA computers down for four days due to a “software problem”Peter Neumann’s Risks Digest:

http://catless.ncl.ac.uk/Risks

Analysis 2%Specification

5%Design

Module Coding5%

Module Testing7%

Integration8%

Maintenance67%

High Cost

[Schach]

Cost of Change Progressively Higher

Analysis Specification Design Implementation Integration Maintenance

[Schach]

Processes as a Remedy

Institute processes through which software is engineered Cover all steps from initial idea and

requirements to delivery, maintenance, and final retirement

Make sure we do the right things/things right

Make sure we do not forget to do anything Different processes for different kinds of

software Not a silver bullet [Brooks “No Silver

Bullet”] Software is still intrinsically difficult to deal

with Processes help, but cannot guarantee

anything

Remember: People + Processes + Tools Product

Processes

Elements Activities (“Phases”) Artifacts

Can include process specifications Resources

People (their time and their cost) Tools (their time and their cost)

Relationships between the elements Precedence, requires, provides, refines to, …

Constraints Time Cost Qualities (repeatable process?)

Software Life Cycle Models

Build-and-fix Waterfall Rapid prototyping Incremental Synchronize-and-stabilize Spiral

A software life cycle model is a high-level process

Build-and-Fix

Build first version

Modify untilclient is satisfied

Operations mode

RetirementDevelopmentMaintenance

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Build-and-Fix

Build first version

Operations mode

Waterfall

Operations mode

Retirement

RequirementsphaseVerify

SpecificationphaseVerify

DesignphaseVerify

ImplementationphaseTest

IntegrationphaseTest

Changedrequirements

Verify

DevelopmentMaintenance

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Waterfall

Operations mode

Retirement

DesignphaseVerify

Changedrequirements

Verify

Rapid Prototyping

Operations mode

Retirement

Build and discardsimple prototype

Verify

DesignphaseVerify

Changedrequirements

Verify

FOR EACH BUILDPerform detailed design, implementation, and integration. Test. Deliver to client.

Incremental

Operations mode

Retirement

ArchitecturaldesignVerify

Synchronize-and-Stabilize

Specifications Implementation,Integration

Deliver toclient (version 1)

Specifications Design Implementation,Integration

Deliver toclient (version n)

......

Specification team Design team Implementation/integration team

Design

......

Design

......

Design

Deliver toclient version 1

Deliver toclient version n

......

Design

......

Design

......

Design

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Spiral

Riskanalysis

prototype

Specification

Design

Implementation

VerifyVerify

Full spiral model is discussed in Sommerville

Boehm’s Top Ten Software Risks

1. Personnel shortfalls2. Unrealistic schedules and budgets3. Developing the wrong software functions4. Developing the wrong user interface5. “Gold plating”

6. Continuing stream of requirements changes7. Shortfalls in externally furnished components8. Shortfalls in externally performed tasks9. Real-time performance shortfalls10. Straining computer-science capabilities

A Comparison of Life Cycle Models

Model Strengths WeaknessesBuild-and-Fix Fine for small programs that do not

require much maintenanceTotally unsatisfactorily for nontrivial programs

Waterfall Disciplined approachDocument driven

Delivered product may not meet client’s needs

RapidPrototyping

Ensures that delivered product meets client’s needs

A need to build twiceCannot always be used

Incremental Maximizes early return on investmentPromotes maintainability

Requires open architectureMay degenerate into build-and-fix

Synchronize-and-stabilize

Future user’s needs are metEnsures components can be successfully integrated

Has not been widely used other than in Microsoft

Spiral Incorporates features of all the above models

Can be used only for large-scale productsDevelopers have to be competent at risk-analysis

Homework

1. Read Chapter 3 of van Vliet

introduction to software engineering lecture 3 andré van der hoek

Documents

invisibility software

control software

planes software

major changes software

different kinds of software

software changes perception

ukrisks slide

silver bullet software