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

Community, Artifacts, and Versions André van der Hoek Institute for Software Research University of California, Irvine andre@ics.uci.edu

Christopher Van der Westhuizen and Andre van der Hoek Presented by Jaime Acosta

Jantina van der Hoek CV 0317jantinavanderhoek.com/wp-content/uploads/2017/02/Jantina-van-der … · - Developing account plan and fine-tuning with senior colleagues, account team

Ian Hoek Spaans

© 2009 University of California, Irvine – André van der Hoek1February 8, 2009 – 21:49:30 Informatics 122 Software Design II Lecture 9 André van der Hoek

Introduction to Software Engineering Lecture 4 André van der Hoek

El criterio de rotura de Hoek-Brown – Edición 2002 Hoek-Brown

(c) 2010 University of California, Irvine – André van der Hoek1June 29, 2015 – 08:55:05 Informatics 122 Software Design II Lecture 8 André van der Hoek

Introduction to Software Engineering Lecture 7 André van der Hoek

HOEK CLASSIC DESIGN

Fish Hoek Primary

© 2010 University of California, Irvine – André van der Hoek1June 25, 2015 – 08:15:24 Informatics 121 Software Design I Lecture 3 André van der Hoek &

© 2010 University of California, Irvine – André van der Hoek1July 13, 2015 – 06:42:38 Informatics 121 Software Design I Lecture 4 André van der Hoek &

© 2010 University of California, Irvine – André van der Hoek1October 23, 2015 – 10:21:58 Informatics 122 Software Design II Lecture 1 André van der Hoek

xxxxx Der Dativ im Deutschen – Eine Verständnishilfe für ... · xxxxx Der Dativ im Deutschen – Eine Verständnishilfe für das Phänomen der gespaltenen Ergativität 1 André

Hoek Brown(2007)

Introduction to Software Engineering Lecture 5 André van der Hoek

EDWIN VAN DER HOEK Supply Chain and Buying Options 091208

Composition Environments for Deployable Software Componentsandre/papers/T7.pdf · Composition Environments for Deployable Software Components Chris Lüer and André van der Hoek Department

Report Hoek Sema