40
Software Engineering HT06 Annabella Loconsole [email protected] http://www.cs.umu.se/~bella http://www.cs.umu.se/kurser/TDBB12/HT06/

Software Engineering HT06 Annabella Loconsole [email protected] bella

Embed Size (px)

Citation preview

Page 1: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

Software Engineering HT06

Annabella [email protected]

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

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

Page 2: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 2

Course Organisation

Lecture part o Traditional lectureso 1 guest lectureo 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

Page 3: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 3

ContentsL1: Introduction L2: Requirements engineering L3: Project management L4: Software design L5: Detailed design and coding L6: Verification and Validation L7: Maintenance Guest Lecture: Product line engineering (?)

Page 4: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 4

Introduction

What is software engineeringSoftware development processesSoftware qualityApproaches to improve quality

Page 5: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 5

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

Page 6: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 6

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

Page 7: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 7

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

Page 8: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 8

Software processes

A structured set of activities required to develop a software systemo Specification;o Design;o Validation;o Evolution.

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Page 9: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 9

The Waterfall Model

AnalysisDesign

Testing

Coding

Operation and

Maintenance

Installation

Require-ments

Requirements

Specification

Planning

Page 10: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 10

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

start

Plan next phase

Simulations, models

Page 11: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 11

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

Page 12: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 12

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

Page 13: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 13

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

Page 14: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 14

RupO

rgan

i sat i

on

al o

ng

con

t ext

Page 15: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 15

Agile processes

Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods:o Focus on the code rather than the design;o Are based on an iterative approach to software

development;o Are intended to deliver working software quickly

and evolve this quickly to meet changing requirements.

Agile methods are probably best suited to small/medium-sized business systems or PC products.

Page 16: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 16

eXtreme Programming project

Page 17: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 18

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

Page 18: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 19

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.

Page 19: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 20

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

Page 20: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 21

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

Page 21: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 22

Fault vs Failure

?!human error fault failure

can lead to can lead to

Page 22: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 23

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

Page 23: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 24

Introduction

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

Page 24: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 25

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

Page 25: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 26

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

Page 26: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 27

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

Page 27: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 28

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

Page 28: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 29

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

Page 29: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 30

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

Page 30: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 31

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

Page 31: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 32

Approaches to Improve Quality

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

Page 32: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 33

The CMMI model

Developed by SEI for the DoD (Cmm in 1986, Cmmi in 2001) An integrated capability model that includes software and systems engineering capability assessment.The model has two instantiationso Staged where the model is expressed in terms

of capability levels;o Continuous where a capability rating is

computed.

Page 33: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 34

The staged CMMI model

Level 3Defined

Level 2Managed

Level 1Initial

Level 4Quantitatively

managed

Level 5Optimizing

Page 34: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 35

The continuous CMMI model

This is a finer-grain model that considers individual or groups of practices and assesses their use.The maturity assessment is not a single value but is a set of values showing the organisations maturity in each area.The CMMI rates each process area from levels 1 to 5.The advantage of a continuous approach is that organisations can pick and choose process areas to improve according to their local needs.

Page 35: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 36

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

Page 36: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 37Source: http://www.sei.cmu.edu/sema/profile.html

CMM Process Maturity Profileof Software Organizations

Page 37: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 38

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

Page 38: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 39

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,...)

Page 39: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 40

Goal Goal Goal

QuestionQuestion Question

Metric Metric Metric

Goal: Evaluate the reliability of the final software product

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

in the context of company XYZ

Question: What is the defects distribution by phase of entry? How many faults and failures are there in the final product? Metric: Number of Requirements faults, Number of Design faults, MTTF,...

GQM Example

Page 40: Software Engineering HT06 Annabella Loconsole bella@cs.umu.se bella

PVK--Ht06 41

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