Software Engineering HT04 Annabella Loconsole [email protected] bella

Software Engineering HT04

Annabella [email protected]

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

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

PVK--Ht04 [email protected] 2

Course OrganisationLecture part o Traditional lectureso 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


ContentsL1: Introduction L2: Requirements engineeringL3: Project managementL4: Guest Lecture - System engineeringL5: Software designL6: Detailed design and codingL7: Quality assuranceL8: Maintenance


Introduction

What is software engineeringSoftware development processesSoftware qualityApproaches to improve quality


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


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

http://news.bbc.co.uk/2/hi/science/nature/2565387.stm






http://www.esa.int/export/esaCP/ESACVS7708D_index_0.html








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


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


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]


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


Does this scale up?

Software Development Processes

Build firstversion

Modify until clientis satisfied

Operation

Require-ments

maintenancedevelopment


The Waterfall Model (‘70)

AnalysisDesign

Testing

Coding

Operation and

Maintenance

Installation

Require-ments

Requirements

Specification

Planning


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


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


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


Incremental and Iterative Processes

ProjectManagement

QualityAssurance

Reuse Documentation

Maintenance Version- and Confi-guration Control

RequirementsEngineering

Design

Implemen-tation


Design

Implemen-tation


Design

Implemen-tation

Iterations


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


RupO

rgan

i sat i

on

al o

ng

con

t ext


eXtreme Programming project


Rules and Practices of Extreme Programming

The Customer is Always AvailableCoding 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


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


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


Fault vs Failure

?!human error fault failure

can lead to can lead to


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


Introduction

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


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


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


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


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


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


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


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


Approaches to Improve Quality

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


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


CMM: Levels


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:


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


Source: http://www.sei.cmu.edu/sema/profile.html

CMM Process Maturity Profileof Software Organizations

Maturity Level 1987-91 1997 1999 2001 December 2002

1- Initial 80% 61% 48% 38% 32%

2- Repeatable 12% 23% 30% 34% 37%

3- Defined 7% 14% 16% 20% 21%

4- Managed 0% 2% 4% 5% 5%

5- Optimizing 1% 1% 2% 4% 5%

Organizations reporting to SEI

130 795 1179 1641 1998

http://www.sei.cmu.edu/sema/profile.html


Personal Software Process -PSP

A process for individual developerso Well-defined process steps (scripts)o Formso Instruction for filling in the formso Standards

Framework for analysisTool for individual process improvements Developers find more errors Developers improve their estimations Developers improve productivity

Improvements at “no” costs


Plan

Result

PSP Overview

Planning

Design

Coding

Compile

Testing

Post Mortem

Requirements

Product

Scripts

guid

e LogsLogs

logg

ing (

tim

e /

defe

cts

Plan&

Summary

Project and Process DataSummary Report


PSP Levels

PSP0Current processTime recording

Defect recordingDefect type standard

PSP1Size estimating

Test report

PSP2Code reviews

Design reviews

PSP3Cyclic development

PSP2.1Design templates

PSP1.1Task planning

Schedule planning

PSP0.1Coding standard

Size measurementProcess improvement

proposal (PIP)


CMM and PSP

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

Initial

1:1:

2:2:

3:3:

4:4:

5:5:

PSP key process areas


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

Software Engineering HT04 Annabella Loconsole [email protected] bella

Documents

Transcript of Software Engineering HT04 Annabella Loconsole [email protected] bella