Software Engineering · Software Engineering Natallia Kokash, researcher at LIACS Research experience Postdoc at Centrum Wiskunde & Informatica (CWI), Amsterdam Ph.D. from University

1

Software Engineering

Natallia Kokash

email: [email protected]

N. Kokash, Software Engineering


Introduction Course overview

Logistics

Literature

Practical assignment

Evaluation

What is Software Engineering?

What does Software Engineer do?

Software Engineering Processes

2



Natallia Kokash, researcher at LIACS

Research experience Postdoc at Centrum Wiskunde & Informatica

(CWI), Amsterdam

Ph.D. from University of Trento, Italy (2008)

Research in Software Engineering Semantics of Modeling Languages

Software Design and Verification

Service-Oriented Computing

3N. Kokash, Software Engineering

Industrial ExperienceCollaboration with large international companies

Thales-France, Telcordia-Poland, PWC.

Two years of experience as Software Engineer Development of banking systems




What will you learn?

Engineering = skill + knowledge

This course 70% knowledge and 30% skills

Basic concepts & vocabulary of SE

Main activities in SE projects

Main methods and techniques

excluding: programming

Guest lectures by professionals



Literature 70% - H. van Vliet, Software

Engineering: Principles and Practice, 3rd ed., 2008.

A. Shalloway and J.R. Trott, “Design Patterns Explained” (2004)

WWW

Check my course web pagehttp://homepages.cwi.nl/~kokash/courses.html

6


These slides are based on the slides

by Prof. Dr. Hans van Vliet

http://homepages.cwi.nl/~kokash/courses.html


Course overviewTheme Chapter

Course Overview, Introduction to Software Engineering (SE) &

Software Development (SD) Lifecycle

1, 2, 3.1-3.2

Requirements Engineering & Configuration Management 4, 9

Software Modeling 3.3-3.9,10

Software Design & Architectural Styles 11, 12

Software Quality Assurance & Metrics 6

Team Organization & Global SD 5, 20

Software Reuse, Component-based & Service-oriented Computing 17, 18,19

Design Patterns & Refactoring tbd

Software Testing 13

Software Maintenance 14

Cost Estimation, Planning & Control 7, 8

Empirical Research in SE tbd

7



Logistics Lecturer (B.Sc. Informatica &

Economie, Den Haag) Dr. Natallia Kokash

Lecturer (B.Sc. Informatica, Leiden) Drs. Werner Heijstek

Werkgroepdocent, Leiden Christoph Johann Stettina, M.Sc

Course Manager Dr. Michel R.V. Chaudron

You may take hoorcolleges (but not werkcolleges) at either location

The schedule for Leiden can be found at www.liacs.nl


Check slides by Drs. W. Heijstek http://www.liacs.nl/~heijstek/se11-slides/

http://www.liacs.nl/

http://www.liacs.nl/~heijstek/se11-slides/




Team of 3-4 people

Focus on a proper development process

Results: requirements specification, software

design, implementation, documentation and

testing report

Any tools or programming languages (pointers

to useful tools & libraries will be given)

9



Convert a picture of a UML class diagram

(.bmp, .jpg) to a UML class diagram in

XMI format

10


Problem


Details

Retrieve images of UML class diagrams from Google images

Recognize basic shapes (rectangles, arrows)

Use optical character recognition (OCR) tools to recognize names of classes, attributes, annotations, etc.

Create a graph-based representation of a recognized class diagram

Write an XMI file

11



Final evaluation

50% written exam

But > 5.5

50% practical assignment

25% Requirement specification

25% Software architecture and design

25% Implementation

25% Quality evaluation

12



Software Crises

Edsger Dijkstra, The Humble Programmer, Communications of the ACM (1972)

13


“The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.”


Who is Edsger Dijkstra? Born in Rotterdam in 1930.

Studied theoretical physics at the University of Leiden where he became interested in “programming”

Received numerous awards including Turing Award in 1972

1.300+ publications

Helped the emancipation of computer science as a science

Best known for his "shortest path algorithm” and his hate to the gotooperator.



The crisis manifest

Projects running over-budget

Projects running over-time

Software was very inefficient

Software was of low quality

Software often did not meet requirements

Projects were unmanageable and code

difficult to maintain

Software was never delivered

15



The beginning of Software

Engineering

1968/69 NATO conferences: introduction of the term Software Engineering

Idea: software development is not an art, or a bag of tricks

Build software like we build bridges



Definition

Software Engineering is

the application of a

systematic, disciplined,

quantifiable approach to the

development, operation, and

maintenance of software;

that is, the application of

engineering to software



Famous software failures Military

Mariner 1 rocket (1962) Cost: $18.5 million

Soviet anti-missile warning system (1983)

Patriot missile system (1991) 28 soldiers dead, 100 injured

Medicine Therac-25 (1985) (3 dead, 3 critically

injured)

Radiation therapy software by MultidataSystems (2000) (8 dead, 20 critically injured)

18



Famous software failures Finance

Wall Street Crash (1987) caused by the NYSE computer system

EDS Drops Child Support (2004) Cost: £540 million

Airspace and flight control

ARIANE 5, Flight 501 crash (1996) Cost: $500 million

Mars Climate Orbiter crash (1998) Cost: $125 million

19



ARIANE Flight 501 Disintegration after 39 sec

Caused by wrong data being sent to On Board Computer

Large correction for attitude deviation

Software exception in Inertial Reference System after 36 sec.

Overflow in conversion of a variable from 64-bit floating point to 16-bit signed integer

Of 7 risky conversions, 4 were protected Reasoning: physically limited, or large

margin of safety In case of exception: report failure and

shut down



Explanations Inadequate testing

Specification does not contain trajectory data

In tests, components that measure altitude and movements of the launcher were simulated by software modules

Wrong type of reuse If a component works perfectly well in one environment, it doesn’t

necessarily do so in another

Ariane 5 is much faster than Ariane 4, and horizontal velocity builds up more rapidly excessive values for parameter in question

This software doesn’t have any purpose for the Ariane 5, but was still kept

Wrong design philosophy “If something breaks down, it is caused by a random hardware

failure”

Action: shut down that part

There is no provision for design errors!



Further information Ariane 5:

IEEE Computer, January 1997, p. 129-130

http://www.cs.vu.nl/~hans/ariane5report.html

20 Famous Software Disasters http://www.devtopics.com/20-famous-software-

disasters/


http://www.cs.vu.nl/~hans/ariane5report.html

http://www.devtopics.com/20-famous-software-disasters/








Is SE = Engineering?

Software is logical, rather than physical

Progress is hard to see (speed progress)

Software is not continuous

Further reading:Henry Petroski, Design Paradigms: Case

Histories of Error and Judgement in Engineering

A. Spector & D. Gifford, A Computer Science Perspective of Bridge Design, Communication of the ACM 29, 4 (1986) p 267-283



Quo Vadis?

It takes at least 15-20 years for

a technology to become mature

Software engineering has made

tremendous progress

There is no silver bullet



http://www.projectsmart.co.uk/docs/chaos-report.pdf


1994 1996 1998 2000 2002 2004 2006 2009

Successful 16% 27% 26% 28% 34% 29% 35% 32%

Challenged 53% 33% 46% 49% 51% 53% 46% 44%

Failed 31% 40% 28% 23% 15% 18% 19% 24%

The CHAOS report





Famous Engineering Disasters

Tacoma Narrows bridge (1940) (1 dog

dead)

Hyatt Regency Hotel Walkway Collapse

(1981) 114 dead, >200 injured

26



Famous Engineering Disasters

Chernobyl Nuclear Power Plant (1986) (at

least 5000 dead, 336000 relocated)

Air crashes:

DC10-S (1979) (271 dead)

Aloha Airlines Flight 243 (1988) (1 dead)

27



Relative distribution of

software/ hardware costs

28

HardwareDevelopment

Software

Maintenance

1955 1970 1985Year

100

60

20

Perc

en

t o

f to

tal

co

st



Types of Software CustomFor a specific customer

GenericSold on open market

Often called COTS (Commercial Off The Shelf)

Shrink-wrapped

EmbeddedBuilt into hardware

Hard to change



Types of software

Real time software

E.g. control and monitoring systems

Must react immediately

Safety often a concern

Business Information Systems

Data processing

Used to run businesses

Accuracy and security of data are key



Central themes

LARGE programs

COMPLEX programs

Software EVOLVES

Software COSTS

Software is developed by TOGETHER by many

people

Software must EFFECTIVELY support users

SE depends on knowledge transfer from

DIFFERENT disciplines

SE is about finding a BALANCE



Simple life cycle model

32

requirements engineering

design

implementation

testing

maintenance

Working system

System

Design

Requirements

specification

Problem



Requirements Engineering

Yields a description of the DESIRED system:

which functions

possible extensions

required documentation

performance requirements

Includes a feasibility study

Resulting document: requirements specification



Design

Earliest design decisions captured in software architecture

Decomposition into parts/components; what are the functions of, and interfaces between, those components?

Emphasis on what rather than how

Resulting document: specification



Implementation

Focus on individual components

Goal: a working, flexible, robust, … piece of software

Not a bag of tricks

Present-day languages have a module and/or class concept



Testing

Does the software do what it is

supposed to do?

Are we building the right

system? (validation)

Are we building the system

right? (verification)

Start testing activities in phase 1,

on day 1



Maintenance

Correcting errors found after the

software has been delivered

Adapting the software to

changing requirements,

changing environments, ...



Global distribution of effort

38

testing 45%

coding 20%design 15%

requirements

engineering 10%

specification 10%


Rule of thumb: 40-20-40 distribution of effort

Trend: enlarge requirements specification/design slots; reduce test slot

Beware: maintenance alone consumes 50-75% of total effort


Distribution of maintenance

activities

Corrective maintenance: correcting discovered errors

Preventive maintenance: correcting latent errors

Adaptive maintenance: adapting to changes in the environment

Perfective maintenance: adapting to changing user requirements


corrective 21%

adaptive 25%

preventive 4%

perfective 50%


SE in a nutshell



What does Software Engineer do?


programming,documenting,planning,presenting,reviewing,reporting

individually

listening,explaining,proving feedback,selling

interactingwith clients

in a team

Specializing in different rolesdesigning, programming, testing,

Microsoft 1978

brainstormingdiscussingplanning


Hammurabi’s Code

42

64: If a builder builds a house for a man and does not make its construction firm, and the house which he has built collapses and causes the death of the owner of the house, that builder shall be put to death.…73: If it cause the death of a son of the owner of the house, they shall put to death a son of that builder.



Software Engineering Ethics

Act consistently with the

public interest

Act in a manner that is in

the best interest of the

client and employer

Ensure that products meet

the highest professional

standards possible

Maintain integrity in

professional judgment

Managers shall promote

an ethical approach

Advance the integrity and

reputation of the

profession

Be fair to and supportive

of colleagues

Participate in lifelong

learning and promote an

ethical approach



A broader view on SD

44

program

information planning

boundary conditions

people

documentation

softwareinput output

procedures

program



Contents of project plan

Introduction

Process model

Organization of project

Standards, guidelines,

procedures

Management activities

Risks

Staffing

Methods and techniques

Work packages

Resources

Quality assurance

Budget and schedule

Changes

Delivery

45



Project control Time, both the number of man-months and the

schedule

Information, mostly the documentation

Organization, people and team aspects

Quality, not an add-on feature; it has to be built in

Money, largely personnel

46



Managing time

Measuring progress is hard (“we spent half

the money, so we must be halfway”)

Development models serve to manage time

More people less time?

Brooks’ law: adding people to a late project

makes it later

47



Managing information

48

Documentation

Technical documentation

Current state of projects

Changes agree upon

…

Agile projects: less attention to explicit

documentation, more on tacit knowledge

held by people



Managing people

Managing expectations

Building a team

Coordination of work



Managing quality

50

Quality has to be designed in

Quality is not an afterthought

Quality requirements often

conflict with each other

Requires frequent interaction

with stakeholders



Managing cost

Which factors influence cost?

What influences productivity?

Relation between cost and schedule



Software Development Methods Projects are large and complex

A phased approach to control it is necessary

Traditional models are document-driven: there is a new pile of paper after each phase is completed

Evolutionary models recognize that much of what is called maintenance is inevitable

52



Waterfall model

53

V&V

Requirements eng.

V&V

Design

V&V

Implementation

V&V

Testing

V&V

Maintenance


Iteration

Feedback

Validation Are we building the

right system?

Verification Are we building the

system right?

Requirements are fixed as early as possible


Problems Too rigid

Developers cannot move between various abstraction levels

V-model

54

Requirements

engineering

Detailed

design

Global design

Coding

Unit testing

Integration

testing

Acceptance

testing



Evolutionary model


WaterfallModel

(Mid 70ies)

Test

Specification

Design

Implementation

Requ. Eng. &Architecting

Scope

Tim

e

EvolutionaryModels(80ies)

Increments(Spiral cycles)

Iteration



Win-Win Spiral Model

3. Reconcile win conditionsEstablish next-increment objectives, constraints & alternatives

7. Verify & commit

6. Implement product& process definitions

5. Define next-incrementof product & process,inclusive partitions

4. Evaluate product andprocess alternativesResolve risks

1. Identifynext-incrementstakeholders

Emphasizes continuous stakeholder alignment

(Boehm, 1998)2. Identify stakeholdersobjectives and win conditions / values


Incremental development A software system is delivered

in small increments

The waterfall model is employed in each phase

The user is closely involved in directing the next steps

Incremental development prevents over-functionality

57



Incremental development


increment1

increment2

increment3

deliveredsystem

first incremental delivery

design build install evaluate

second incremental delivery


third incremental delivery


Each component delivered must give somebenefit to the stakeholders


Velocity tracking

Measure team productivity

Unit of work – hours, days, story points,

ideal days

Interval – week, month



Prototyping

Requirements elicitation is difficult software is developed because the present

situation is unsatisfactory

however, the desirable new situation is as yet unknown

Used to obtain the requirements of some aspects of the system

Should be a relatively cheap processuse rapid prototyping languages and tools

not all functionality needs to be implemented

production quality is not required

60



Prototyping as a tool for SE

61

Requirements

engineering

designdesign

implementationimplementation

testingtesting

maintenance



Prototyping approaches

Throwaway prototyping: the n-th prototype is

followed by a waterfall-like process

Evolutionary prototyping: the n-th prototype

is delivered

62



Prototyping, advantages

The resulting system is easier to use

User needs are better accommodated

The resulting system has fewer features

Problems are detected earlier

The design is of higher quality

The resulting system is easier to maintain

The development incurs less effort

63



Prototyping, disadvantages

The resulting system has more features

The performance of the resulting system

is worse

The design is of less quality

The resulting system is harder to maintain

The prototyping approach requires more

experienced team members

64



Recommendations for

prototyping

The users and the designers must be well

aware of the issues and the pitfalls

Use prototyping when the requirements

are unclear

Prototyping needs to be planned and

controlled as well

65



The plan



Reality



Recent developments

Rise of agile methods

Shift from producing software to using software

Software development becomes more

heterogeneous

Success of open source software



The Agile Manifesto (2001)


“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”.


12 principles of Agile SE:

Customer satisfaction by rapid delivery of useful software

Welcome changing requirements, even late in development

Working software is delivered frequently (weeks rather than months)

Working software is the principal measure of progress

Sustainable development, able to maintain a constant pace

Close, daily co-operation between business people and developers


Face-to-face conversation is the best form of communication (co-location)

Projects are built around motivated individuals, who should be trusted

Continuous attention to technical excellence and good design

Simplicity

Self-organizing teams

Regular adaptation to changing circumstances


Popular agile methods Rapid Application Development (RAD) &

Dynamic System Development Method (DSDM)

Extreme Programming (XP)

Feature Driven Development (FDD)

Unified Processes: Agile Unified Process (AUP)

Open Unified Process (OpenUP)/Basic

Essential Unified Process (EssUP)

Scrum

71



RAD

Other elements: Joint Requirements Planning (JRD) and Joint Application Design (JAD), workshops in which users participate;

Requirements prioritization through a triage;

Development in a SWAT team: Skilled Workers with Advanced Tools

72


Evolutionary development, with time boxes: fixed time frames within which activities are done;

Time frame is decided upon first, then one tries to realize as much as possible within that time frame;


DSDM

Dynamic Systems

Development Method, #1

RAD framework in UK

73


Fundamental idea: fix time and resources

(timebox), adjust functionality accordingly

One needs to be a member of the DSDM

consortium


DSDM phases

Feasibility: delivers feasibility report and outline plan, optionally fast prototype (few weeks)

Business study: analyze characteristics of business and technology (in workshops), delivers System Architecture Definition

Functional model iteration: time-boxed iterative, incremental phase, yields requirements

Design and build iteration

Implementation: transfer to production environment

74



DSDM practices Active user involvement is

imperative Empowered teams Frequent delivery of products Acceptance determined by

fitness for business purpose

75


Iterative, incremental development All changes are reversible Requirements baselined at high level Testing integrated in life cycle Collaborative, cooperative approach shared by

all stakeholders is essential


Extreme Programming (XP)

Everything is done in small steps

The system always compiles, always runs

Client as the center of development team

Developers have same responsibility w.r.t. software and methodology

76



13 practices of XP

77

Whole team: client part of the team

Metaphor: common analogy for the system

The planning game, based on user stories

Simple design

Small releases (e.g. 2 weeks)

Customer tests

Pair programming

Test-driven development: tests developed first

Design improvement (refactoring)

Collective code ownership

Continuous integration: system always runs

Sustainable pace: no overtime

Coding standards




DifferencesLightweight (Agile) Heavyweight

Developers Knowledgeable, collocated,

collaborative.

Plan-driven, adequate skills,

access to external knowledge.

Customers Dedicated, knowledgeable,

collocated, collaborative,

representative, empowered

Access to knowledgeable,

collaborative, representative,

empowered customers

Requirements Largely emergent, rapid

change

Knowable early, largely stable

Architecture Designed for current

requirements

Designed for current and

foreseeable requirements

Size Smaller teams and

products

Larger teams and products

Primary objective Rapid value High assurance


Heterogeneity

Old days: Software development department had

everything under control

Nowadays:Teams scattered around the globe

Components acquired from others

Includes open source parts

Services found on the Web



Producing software means

using software!

Builders build pieces, integrators integrate

them

Component-Based Development (CBSD)

Software Product Lines (SPL)

Commercial Off-The-Shelves (COTS)

Service Orientation (SOA)



Software engineering is a balancing act, where trade-offs are difficult

Solutions are not right or wrong; at most they are better or worse

Most of maintenance is (inevitable) evolution

SD project control concerns: time, information, organization, quality, money

There are many lifecycle models

Agile projects do less planning than document-driven projects



Homework Which SE model is the most suitable for the

assignment project and why?Write down your development plan

Use RUP Software Development Plan template

Read chapters 1,2 & 3.1-3.2

82



Software Engineering (3rd Ed.) 1. Introduction

2. Introduction to Software Engineering Management

3. The Software Life Cycle Revisited

4. Configuration Management

5. People Management and Team Organization

6. On Managing Software Quality

7. Cost Estimation

8. Project Planning and Control

9. Requirements Engineering

10. Modeling

11. Software Architecture

12. Software Design

13. Software Testing

14. Software Maintenance

17. Software Reusability

18. Component-Based Software Engineering

19. Service Orientation

20. Global Software Development


Documents

Software Engineering · Software Engineering Natallia Kokash, researcher at LIACS Research experience Postdoc at Centrum Wiskunde & Informatica (CWI), Amsterdam Ph.D. from University