Advanced Software Engineering

Dr. Serdar Taran

Ko University Department of Computer Engineering

http://theorem.ku.edu.tr

Software Engineering Overview

Outline of todays lecture

What is software engineering?
The issues The constraints Key ideas underlying software engineering methodologies

The software life cycle

Issue 1: Fault-Free Software

What are Faults?
software behavior unaccounted for in its design

Examples?
Therac-25 medical linear accelerator incident Intl Atomic Energy Agency declared radiological emergency in 2001 in Panama.
28 patients overexposed, 8 died. Data entry software was in error

Ariane-5 (ESA rocket)

Rocket lost due to (unneeded) code throwing exception

Patriot missile timing error NASA Climate Orbiter failure London Ambulance Dispatch system
Dropped, duplicated calls

(Prof. Tom Henzingerden alnt) 5

(Prof. Tom Henzingerden alnt) 6

(Courtesy of Prof. Tom Henzinger)

(Courtesy of Prof. Tom Henzinger), EPFL

Development failures
IBM survey,1994
55% of systems cost more than expected 68% overran schedules 88% had to be substantially redesigned

Advanced Automation System (FAA, 1982-1994)

industry average was $100/line, expected to pay $500/line ended up paying $700-900/line $6B worth of work discarded

Bureau of Labor Statistics (1997)

for every 6 new systems put into operation, 2 cancelled probability of cancellation is about 50% for biggest systems average project overshoots schedule by 50% 3/4 systems are regarded as operating failures

Issue 1: Working, quality software

Buggy software is a huge problem Defects in software are commonplace
Much more common than in other engineering disciplines

How can we lessen our chances of faults?

Use a well-defined process that includes rigorous design, testing, and programming techniques

Role of design and designers

thinking in advance always helps (and its cheap!) cant add quality at the end:
contrast with reliance on testing; more effective, much cheaper

makes delegation and teamwork possible

10

Specification
But how do we know behavior is a bug?

Because we have some separate specification of what the program must do

Separate from the code

Thus, knowing whether the code works requires us first to define what works means
A specification
Formal, or semi-formal

11

Teams and Specifications

Principle #1: Communication is hard. In any conversation, the participants will have (slightly) differing interpretations of what was said.

12

Teams and Specifications (Cont.)

Principle #1 is devastating for software development

People will
Discuss what to do Divide up the work Implement incompatible components Be surprised when it doesnt all just work together

13

What Can We Do?

Write specifications
Write down what it is supposed to do Make sure everyone understands it Keep the specification up to date

This does not solve the problem

There are always ambiguities, contradictions These lead to bugs But the problem is reduced to manageable size

14

Summary of Issue 1
A specification allows us to:
Check whether software works Build software in teams at all

Checking that the software works is hard

Code reviews Static analysis tools Testing and more testing Formal verification

15

Issue 2: Time & Budget Constraints

What happens if we are late?
miss the market window (competition wins) costs rise, less profit

What happens if we are over budget?

loss of profit cancellation of project

Case study: California DMV software (87-93)

attempt to merge driver & vehicle registration systems spent 7 years and $50 million before pulling the plug
costs 6.5x initial estimate & expected delivery slipped to 1998!

16

Time
Time is the enemy of all software projects

Taking a long time is inherently risky

Time pressure is (seemingly) at conflict with sound development.

17

Why?
The world changes, sometimes quickly

Technologies become obsolete

Many products obsolete before they first ship!

Other people produce competitive software Software usually depends on many 3rd-party pieces
Compilers, networking libraries, operating systems, etc. All of these are in constant motion Moving slowly means spending lots of energy keeping up with these changes

18

Issue 2: How Do We Code Efficiently?

Assume we want to minimize time
Usually the case Time-to-market exerts great pressure in software

How can we code faster?

Obvious answer: Hire more programmers!

19

Parallel Development
How many programmers can we keep busy?
As many as there are independent tasks

People can work on different modules

Thus we get parallelism And save time

What are the pitfalls?

20

Pitfalls of Parallel Development

The problems are the same as in parallel computing

More people = more communication

Which is hard

Individual tasks must not be too fine-grain

Increases communication overhead further

Inherent sequential constraints

e.g., pipeline architecture

21

Interfaces
The chunks of work must be independent
But work together in the final system

We need interfaces between the components

To isolate them from one another To ensure the final system works

The interfaces must not change (much)!

Otherwise, development is not parallel

22

Defining Interfaces
What are interfaces?

They are just specifications!

But of a special kind
Interfaces are the boundaries between components
And people

23

Defining Interfaces
Specifying interfaces is most important
Interfaces should not change a lot Effort must be spent ensuring everyone understands the interfaces Both things require preplanning and time

But often we can stop at specifying interfaces

Let individual programmers handle the internals themselves

24

Software Architecture
To define interfaces, we must decompose a system into separate pieces with boundaries The decomposition of a system is driven by:
What it does How we build it Who builds it

25

How We Build It
Buildings need scaffolding during construction So does software! Two areas in particular:
Lots of extra code that is not really part of the final product Influence of third-party subsystems

Test harnesses, stubs, ways of building and running partial systems

26

Who Builds It
Software architecture reflects the structure of the organization that builds it Often, 5 developers = 5 components

27

Summary of Issue 2
Efficient development requires
Decomposing system into pieces Good interfaces between pieces

The pieces should be large

Dont try to break up into too many pieces

Interfaces are specifications of boundaries

Must be well thought-out and well communicated

28

Issue 3: Satisfies the Users Needs

Functionality & Usability
does what the users tasks require easy to learn efficient to use & error rates kept to a minimum leads to high user satisfaction

Bad (even if correct) user interfaces cost

money (5% satisfaction -> up to 85% profits) lives (Therac)

How to attack this issue?

Capture users needs in the form of a requirements document Iterate on this document, update throughout lifecycle of project

29

Conclusions
Software engineering boils down to two issues:
Know what you want to do Develop an efficient plan for doing it

Both require specifications

To even define what you want to do To ensure everyone understands the plan

30

Outline of todays lecture

How important is software? Why?
An overview of the software industry

What is software engineering?

The issues The constraints Key ideas underlying software engineering methodologies

The software life cycle

31

Phases
Gather Requirements Specification Design Implementation Integration Product 32

Cost of Finding Flaws Late

33