Software Engineering HT05

Annabella Loconsolebella@cs.umu.se

http://www.cs.umu.se/~bella

http://www.cs.umu.se/kurser/TDBB12/HT05/

PVK--Ht05 2

Course OrganisationLecture part o Traditional lectureso 3 Group exerciseso 2 Assignments o Written examination

Project parto Teamwork

• Prototype developmento Team meetingso Oral presentation of

resultso Written reports

Examination: Assignments + Exam+ Project

PVK--Ht05 3

Contents

L1: Introduction L2: Requirements engineeringL3: Project managementL4: Software designL5: Detailed design and codingL6: Quality assuranceL7: Maintenance

PVK--Ht05 4

Introduction

What is software engineeringSoftware development processesSoftware qualityApproaches to improve quality

PVK--Ht05 5

Software Problems

Software becomes more and more complexSoftware permeates our daily lifeSoftware failures may harm our livesSoftware does not meet expectationsSoftware projects exceed budgets and schedules...

PVK--Ht05 6

Ariane 5 Failure (in ’96 and ’02)

Inertial Reference computer (SRI-1) tried to convert 64-bit float value to 16-bit signed integer. Value too large, raised exception. SRI-1 computer shut down. Redundant SRI-2 computer performed same conversion, produced same exception. SRI-2 sent bad data to flight control computer, which then put the launcher into an unstable flight trajectory. Result: Self-destruct mechanism was activated. Failure Cause: improperly constrained computation. http://news.bbc.co.uk/2/hi/science/nature/2565387.stmhttp://www.esa.int/export/esaCP/ESACVS7708D_index_0.html

PVK--Ht05 7

The Software Crisis is not Over

29%

26%

21%

19%

3% 2%

Undeliverable software

Incorrect software

Unsound software

Major redesign needed

Usable after change

OK as delivered

Study from Study from Medvits C et al “SAIC common approach guidance for CMMI”, GAO report on software results

PVK--Ht05 8

What is Software Engineering?“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” Definition proposed by Fritz Bauer

at the NATO conference ‘68 in Garmisch [NRB 76]

COMPUTERSCIENCE

SOFTWAREENGINEERING

CUSTOMER

Theories

Tools andTechniques toSolve Problem

ProblemComputerFunctions

ENGINEERINGPRINCIPLES

ProvenTechniques

PVK--Ht05 9

But ...

“ ... we all tell each other and ourselves that software engineering techniques should be improved considerably, because there is a crisis. But there are a few boundary conditions which apparently have to be satisfied. I will list them for you:1. We may not change our thinking habits.2. We may not change our programming tools.3. We may not change our hardware.4. We may not change our tasks.5. We may not change our organizational set-up in which the work has to be done.Now under these five immutable boundary conditions, we have to try to improve matters. This is utterly ridiculous. ...”Comment by Edsger Dijkstra at

the NATO conference ‘69 in Garmisch [BuRa 70]

PVK--Ht05 10

Elements of Software Engineering

Languages

Technical “how tos” to support software development tasks

Notations to support methods

(Semi-) automated support for (the usage of) methods and languages

Coordination and management of software development tasks supported by methods, languages, and tools

Tools

Processes

Methods

Economically produce quality software

PVK--Ht05 11

Does this scale up?

Software Development Processes

Build firstversion

Modify until clientis satisfied

Operation

Require-ments

maintenancedevelopment

PVK--Ht05 12

The Waterfall Model (‘70)

AnalysisDesign

Testing

Coding

Operation and

Maintenance

Installation

Require-ments

Requirements

Specification

Planning

PVK--Ht05 13

The V model (‘92)

Requirements Analysis

System Design

Unit & Integra-tion Testing

Coding

Operation andMaintenance

Program Design

System Testing

Acceptance Testing

Verify design

Validate requirements

PVK--Ht05 14

PLAN DEVELOP AND TEST

DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS

EVALUATE ALTERNATIVES

AND RISKS

Requirements,life-cycle plan

Budget1

Alternatives1

Constraints1

Riskanalysis1

Risk analysis2

Risk analysis3

Risk analysis4

Constraints2

Constraints3

Constraints4

Budget2Budget3Budget4

Altern

ativ

es2

Altern

ative

s 3

Altern

ative

s 4

Prototype1

Proto-type2

Proto-type3

Proto-type4

Conceptof operation

Softwar

e

requ

irem

en

tsValidated

requirements

DevelopmentplanIntegrationand test plan

Softwar

e

design

Validated,

verified design

Detaileddesign

Code

Unit test

SystemtestAcceptance

test

The Spiral Model (‘88)

start

Plan next phase

Simulations, models

PVK--Ht05 15

Waterfall vs. Spiral Model

Model ComplexitySimple, linearsequence of phases

Complex, iterative model;many integrated tasks

Management Document driven Risk driven

Quality Control Natural milestoneafter each phase

Continuous evaluation,integrated into the model

Customerinteraction No Prototypes are built and

evaluated by customers in every iteration

Risk High (late feedback) Low (risk analysis isintegrated in the model)

Usability Small and/or lowrisk projects

Large projects

Waterfall Model Spiral Model

PVK--Ht05 16

Incremental and Iterative Processes

ProjectManagement

QualityAssurance

Reuse Documentation

Maintenance Version- and Confi-guration Control

RequirementsEngineering

Design

Implemen-tation

RequirementsEngineering

Design

Implemen-tation

RequirementsEngineering

Design

Implemen-tation

Iterations

PVK--Ht05 17

Rational Unified Process

RUP is a method of managing OO Software DevelopmentIt can be viewed as a Software Development Framework which is extensible and features:o Iterative Developmento Requirements Managemento Component-Based Architectural Visiono Visual Modelling of Systemso Quality Managemento Change Control Management

PVK--Ht05 18

RupO

rgan

i sat i

on

al o

ng

con

t ext

PVK--Ht05 19

eXtreme Programming project

PVK--Ht05 21

Rules and Practices of Extreme Programming

The Customer is Always Available

Coding Standards

Code the Unit Test First

Pair Programming

Sequential Integration

Integrate Often

Collective Code Ownership

Optimise Last

No Overtime

Unit Tests

Acceptance Tests

User Stories

Release Plan

Make frequent small releases

Iterative Development

iteration Planning

Move People Around

Daily Stand Up Meeting

Simplicity is the Key

CRC Cards

Create a Spike Solution

Never Add Functionality Early

PVK--Ht05 22

Component-based software engineering

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.Process stageso Component analysis;o Requirements modification;o System design with reuse;o Development and integration.

This approach is becoming increasingly used as component standards have emerged.

PVK--Ht05 23

Relative Costs of Development Phases1%

6%

5%

7%

8%

4%

67%

2%Requirements

Specification

Planning

Design

Coding

Testing

Integration

MaintenanceCompiled data from 1976-1981, see [Schach 97].

PVK--Ht05 24

Relative Costs of an Error

1 2 3 4 1030

200

1 2 3 4 10

52

368

0

50

100

150

200

250

300

350

400

Requ

iremen

ts

Analys

Plan

ning

Design

Implem

enta

tion

Inte

grat

ion

Maint

enan

ce

Studies from 1974-1980

IBM AS/400 [94]

See [Schach 97].

PVK--Ht05 25

Fault vs Failure

?!human error fault failure

can lead to can lead to

PVK--Ht05 26

Causes of Errors12%8%

6%

14%

34%

4%22%

Incorrect or misunderstoodrequirementsIncorrect or misunderstoodspecificationsDesign faultinvolvingseveral componentsDesign- or code fault in onecomponentSpelling mistake or similar

Fault correction

Other reasons

Study from 1978, see [GoRu 95].

PVK--Ht05 27

Introduction

What is Software Engineering Software Development Processes Software QualityApproaches to Improve Quality

PVK--Ht05 28

Quality is ...

… I know it when I see it… it suits the client/user … it conforms to the specification… it has some inherent quality… it depends on the price

PVK--Ht05 29

And Quality is …

Efficiency

Reliability

Easy to learn

Functionality

Flexibility

Increased productivity

Low costs

Easy to use

Readable codeGood design

Good documentation

Few errors

SponsorUser

Maintainer/modifier

Short time of delivery Easy to remember

PVK--Ht05 30

Quality Factors

(ISO 9126)

Functionality

Replaceability

Suitability

Accuracy

InteroperabilitySecurity

Maturity

Fault toleranceRecoverabilityUnderstandabilityLearnability

Operability

Time behaviorResource behaviorAnalyzability

ChangeabilityStability

Testability

Adaptability

Installability

Conformance

Reliability

Efficiency

Usability

Maintainability

Portability

PVK--Ht05 31

How Companies Pursue Software Quality

4%24%

20%

9%

42%

1%

None

Slogans

Improved testing

Focus on prevention

Process improvement

Other

A survey from the CASE Research Corporation (1990), see [Yourdon 92].

PVK--Ht05 32

How To Measure Quality?Quality Factor

Property/Criteria

Property/Criteria

Property/Criteria

Metric MetricMetric

depends on

Efficiency

SpeedSize

Response timeLOC...

determined by

Metrics are (objective) measurements to determine (subjective) quality factors

PVK--Ht05 33

Some Example MetricsTo measure efficiencyo Time behaviour

• Transactions per second

• Response time• Screen refresh time

o Resource behaviour• KBytes of executables• LOC• Number of processors

To measure usabilityo Training timeo Number of help frames

To measure reliabilityo MTTF (Mean Time To

Failure)o Availability

To measure robustnesso Time to restart after a

failureo Probability of data

corruption on failureTo measure portabilityo Number of target systemso Percentage of target

dependent statements

Measurement is necessary

PVK--Ht05 34

Purpose of MeasurementAnalysis: Determine current quality Prediction: Predict future quality

Not only code can be measured, but also

o Products• Documentation• Design

oProcesses•Analysis phase•Test phase

oResources•Personnel•Budget

PVK--Ht05 35

Approaches to Improve Quality

Capability Maturity Model (CMM)Personal Software Process (PSP)InspectionsStandards (ISO9000, ...)Cleanroom engineeringStatistical quality controlGoal Question Metrics (GQM)…..

PVK--Ht05 36

CMMCapability Maturity ModelDeveloped by SEI 1986 (for the DoD)Five maturity levelso Initial (ad-hoc process)o Repeatable (repeatable process)o Defined (well-defined, documented process)o Managed (predictable process)o Optimised (continuous process improvements)

The DoD requires level 3 from all contractors

PVK--Ht05 37

CMM: Levels

PVK--Ht05 38

CMM Key

Process Areas

Repeatable:Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking and oversightSoftware project planningRequirements management

Defined:Peer reviewsIntergroup coordinationSoftware product engineeringIntegrated software managementTraining programOrganization process definitionOrganization process focus

Managed:Quality managementProcess measurement and analysis

Optimized:Process change managementTechnology innovationDefect prevention

Initial1:1:

2:2:

3:3:

4:4:

5:5:

PVK--Ht05 43

CMM Results

Model predictions for the development of a 200.000 LOC data processing product (1993), see [Schach 97].

CMMlevel

1

2

3

4

5

Developmenttime

29,8

18,5

15,2

12,5

9,0

Personmonths

593,5

143,0

79,5

42,8

16,0

Faults detectedduring dev.

1.348

328

182

97

37

Faults delivered

and installed

61

12

7

5

1

Total dev. costsin US$

5.440.000

1.311.000

728.000

392.000

146.000

PVK--Ht05 44Source: http://www.sei.cmu.edu/sema/profile.html

CMM Process Maturity Profileof Software Organizations

PVK--Ht05 45

Goal Question Metric

The paradigm helps an organisation to focus on its goals. It consists of three steps:

Specify a set of goals Generate a set of quantifiable questions Define a set of metrics

PVK--Ht05 46

GQM TemplatePurpose: Analyse some (objects: processes, products, other

experience models) for the purpose of (why: characterisation, evaluation,

prediction, motivation, improvement) Perspective: with respect to (focus: cost, correctness, defect removal,

changes, reliability, user friendliness,...) from the point of view of (who: user, customer, manager,

developer, corporation,...) Environment: in the following context (problem factors, people factors,

resource factors, process factors,...)

PVK--Ht05 47

Goal Goal Goal

QuestionQuestion Question

Metric Metric Metric

Goal: Analyze the final product for the purpose of characterisation with respect to the various defect classes from the point of view of the

organization

Question: What is the error distribution by phase of entry

Metric: Number of Requirements Errors, Number of Design Errors, ...

GQM Example

PVK--Ht05 48

CMM and GQM

CMM

Level 2

Level 3

Level 4

Level 5

KPA

KPA

KPA

Goal

Goal

Goal

Question

Question

Question

Metric

Metric

Metric

KPA

Question

Metric

Metric

Metric

PVK--Ht05 49

References

[Somm 96]I. Sommerville: Software Engineering, Addison-Wesley, 1996.

[Yourdon 92]E. Yourdon, Decline and Fall of the American Programmer, Prentice Hall, 1992. Critical Software Engineering textbook.

[Boehm 81] B.W. Boehm, Software Engineering Economics, Prentice Hall, 1981. “Classical.”

[Pfleeger 98]S.L. Pfleeger, Software Engineering, Theory and Practice, Prentice Hall, 1998.

[Schach 97] S.R. Schach, Software Engineering with Java, Irwin, 1997.

[BuRa 70] J.N. Buxton, B. Randell, Proceedings of the 1969 NATO Conference on Software Engineering, NATO Science Committee, 1970. “Historical.”

[GoRu 95] A. Goldberg, K.S. Rubin, Succeeding with Objects, Addison-Wesley, 1995. Object-Oriented Software Engineering.

[Hump 95] W.S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995. Main PSP textbook.

[Myers 79] G.J. Myers, The Art of Software Testing, Wiley, 1979. “Classical.”