Software Engineering
Natallia Kokash
email: nkokash@liacs.nl
1
N. Kokash, Software Engineering
Software Engineering
Introduction

Course overview
 Logistics
 Literature
 Practical
assignment
 Evaluation



What is Software Engineering?
What does Software Engineer do?
Software Engineering Processes
2
N. Kokash, Software Engineering
Software Engineering

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
Industrial Experience
 Collaboration

Thales-France, Telcordia-Poland, PWC.
 Two

with large international companies
years of experience as Software Engineer
Development of banking systems
N. Kokash, Software Engineering
3
Software Engineering
N. Kokash, Software Engineering
4
Software Engineering
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
N. Kokash, Software Engineering
5
Software Engineering
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 page
http://homepages.cwi.nl/~kokash/courses.html
These slides are based on the slides
by Prof. Dr. Hans van Vliet
6
N. Kokash, Software Engineering
Software Engineering
Course overview
Theme
Course Overview, Introduction to Software Engineering (SE) &
Software Development (SD) Lifecycle
Requirements Engineering & Configuration Management
Software Modeling
Chapter
1, 2, 3.1-3.2
4, 9
3.3-3.9,10
Software Design & Architectural Styles
11, 12
Software Quality Assurance & Metrics
6
Team Organization & Global SD
Software Reuse, Component-based & Service-oriented Computing
5, 20
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
N. Kokash, Software Engineering
Software Engineering
Logistics

Lecturer (B.Sc. Informatica &
Economie, Den Haag)


Lecturer (B.Sc. Informatica, Leiden)



Christoph Johann Stettina, M.Sc
Course Manager


Drs. Werner Heijstek
Werkgroepdocent, Leiden


Dr. Natallia Kokash
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/
N. Kokash, Software Engineering
8
Software Engineering




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
N. Kokash, Software Engineering
Software Engineering
Problem

Convert a picture of a UML class diagram
(.bmp, .jpg) to a UML class diagram in
XMI format
10
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
Software Crises
“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.”
Edsger Dijkstra, The Humble Programmer,
Communications of the ACM (1972)
13
N. Kokash, Software Engineering
Software Engineering
Who is Edsger Dijkstra?






N. Kokash, Software Engineering
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 goto
operator.
14
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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

N. Kokash, Software Engineering
16
Software Engineering
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
N. Kokash, Software Engineering
17
Software Engineering
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 Multidata
Systems (2000) (8 dead, 20 critically
injured)
18
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
20
Software Engineering
Explanations

Inadequate testing



Wrong type of reuse




Specification does not contain trajectory data
In tests, components that measure altitude and movements of the
launcher were simulated by software modules
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!
N. Kokash, Software Engineering
21
Software Engineering
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/
N. Kokash, Software Engineering
22
Software Engineering
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
N. Kokash, Software Engineering
23
Software Engineering
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

N. Kokash, Software Engineering
24
Software Engineering
The CHAOS report
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%

http://www.projectsmart.co.uk/docs/chaos-report.pdf
N. Kokash, Software Engineering
25
Software Engineering
Famous Engineering Disasters
Tacoma Narrows bridge (1940) (1 dog
dead)
 Hyatt Regency Hotel Walkway Collapse
(1981) 114 dead, >200 injured

26
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
Relative distribution of
software/ hardware costs
100
Percent of total cost
Hardware
Development
60
Software
20
1955
N. Kokash, Software Engineering
Maintenance
1970
Year
1985
28
Software Engineering
Types of Software

Custom
 For

a specific customer
Generic
 Sold
on open market
 Often called



COTS (Commercial Off The Shelf)
Shrink-wrapped
Embedded
 Built
into hardware
 Hard to change
N. Kokash, Software Engineering
29
Software Engineering
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
N. Kokash, Software Engineering
30
Software Engineering
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
N. Kokash, Software Engineering
31
Software Engineering
Simple life cycle model
Problem
requirements engineering
Requirements
specification
design
Design
implementation
System
testing
Working system
maintenance
N. Kokash, Software Engineering
32
Software Engineering
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
N. Kokash, Software Engineering
33
Software Engineering
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
N. Kokash, Software Engineering
34
Software Engineering
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
N. Kokash, Software Engineering
35
Software Engineering
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

N. Kokash, Software Engineering
36
Software Engineering
Maintenance
Correcting errors found after the
software has been delivered
 Adapting the software to
changing requirements,
changing environments, ...

N. Kokash, Software Engineering
37
Software Engineering
Global distribution of effort
design 15%
coding 20%
requirements
engineering 10%
specification 10%
testing 45%



Rule of thumb: 40-20-40 distribution of effort
Trend: enlarge requirements
specification/design slots; reduce test slot
Beware: maintenance alone consumes 5075% of total effort
N. Kokash, Software Engineering
38
Software Engineering
Distribution of maintenance
activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%




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
N. Kokash, Software Engineering
39
Software Engineering
SE in a nutshell
N. Kokash, Software Engineering
40
Software Engineering
What does Software Engineer do?
individually
interacting
with clients
in a team
Microsoft 1978
programming,
documenting,
planning,
presenting,
reviewing,
reporting
N. Kokash, Software Engineering
listening,
Specializing in different roles
explaining,
designing, programming, testing,
proving feedback,
brainstorming
selling
discussing
planning
41
Software Engineering
Hammurabi’s Code
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.
N. Kokash, Software Engineering
42
Software Engineering
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
N. Kokash, Software Engineering




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
43
Software Engineering
A broader view on SD
information planning
boundary conditions
documentation
people
input
program
software
output
program
procedures
44
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
Managing information

Documentation
 Technical
documentation
 Current state of projects
 Changes agree upon
…

Agile projects: less attention to explicit
documentation, more on tacit knowledge
held by people
48
N. Kokash, Software Engineering
Software Engineering
Managing people
Managing expectations
 Building a team
 Coordination of work

N. Kokash, Software Engineering
49
Software Engineering
Managing quality
Quality has to be designed in
 Quality is not an afterthought
 Quality requirements often
conflict with each other
 Requires frequent interaction
with stakeholders

50
N. Kokash, Software Engineering
Software Engineering
Managing cost
Which factors influence cost?
 What influences productivity?
 Relation between cost and schedule

N. Kokash, Software Engineering
51
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
Waterfall model



Iteration
Feedback
Validation
Requirements eng.
V&V
we building the
right system?
Design
V&V
 Are

Verification
 Are
we building the
system right?

Requirements are
fixed as early as
possible
Implementation
V&V
Testing
V&V
Maintenance
V&V
53
N. Kokash, Software Engineering
Software Engineering
V-model
Requirements
engineering
Acceptance
testing
Integration
testing
Global design
Detailed
design

Problems


Unit testing
Coding
Too rigid
Developers cannot move between various abstraction levels
54
N. Kokash, Software Engineering
Software Engineering
Evolutionary model
Waterfall
Model
(Mid 70ies)
Evolutionary
Models
(80ies)
Time
Requ. Eng. &
Architecting
Specification
Design
Implementation
Test
Increments
(Spiral cycles)
Iteration
Scope
N. Kokash, Software Engineering
55
Software Engineering
Win-Win Spiral Model
2. Identify stakeholders
objectives and win
conditions / values
1. Identify
next-increment
stakeholders
(Boehm, 1998)
Emphasizes continuous
stakeholder alignment
3. Reconcile win conditions
Establish next-increment
objectives, constraints &
alternatives
4. Evaluate product and
process alternatives
Resolve risks
7. Verify &
commit
6. Implement product
& process definitions
N. Kokash, Software Engineering
5. Define next-increment
of product & process,
inclusive partitions
56
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
Incremental development
design
build
install
increment
1
evaluate
first incremental delivery
design
delivered
system
build
install
evaluate
increment
2
second incremental delivery
design
build
install
evaluate
third incremental delivery
increment
3
Each component delivered must give some
benefit to the stakeholders
N. Kokash, Software Engineering
58
Software Engineering
Velocity tracking
Measure team productivity
 Unit of work – hours, days, story points,
ideal days
 Interval – week, month

N. Kokash, Software Engineering
59
Software Engineering
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 process
 use
rapid prototyping languages and tools
 not all functionality needs to be implemented
 production quality is not required
60
N. Kokash, Software Engineering
Software Engineering
Prototyping as a tool for SE
Requirements
engineering
design
design
implementation
implementation
testing
testing
maintenance
61
N. Kokash, Software Engineering
Software Engineering
Prototyping approaches
Throwaway prototyping: the n-th prototype is
followed by a waterfall-like process
 Evolutionary prototyping: the n-th prototype
is delivered

62
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
The plan
N. Kokash, Software Engineering
66
Software Engineering
Reality
N. Kokash, Software Engineering
67
Software Engineering
Recent developments




Rise of agile methods
Shift from producing software to using software
Software development becomes more
heterogeneous
Success of open source software
N. Kokash, Software Engineering
68
Software Engineering
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.”
.
N. Kokash, Software Engineering
69
Software Engineering
12 principles of Agile SE:
Customer satisfaction by rapid delivery
of useful software
Face-to-face conversation is the best
form of communication (co-location)
Welcome changing requirements, even
late in development
Projects are built around motivated
individuals, who should be trusted
Working software is delivered
frequently (weeks rather than months)
Continuous attention to technical
excellence and good design
Working software is the principal
measure of progress
Simplicity
Sustainable development, able to
maintain a constant pace
Self-organizing teams
Close, daily co-operation between
business people and developers
Regular adaptation to changing
circumstances
N. Kokash, Software Engineering
70
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
RAD





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;
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
N. Kokash, Software Engineering
Software Engineering
DSDM

Dynamic Systems
Development Method, #1
RAD framework in UK
Fundamental idea: fix time and resources
(timebox), adjust functionality accordingly
 One needs to be a member of the DSDM
consortium

73
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
DSDM practices
Active user involvement is
imperative
 Empowered teams
 Frequent delivery of products
 Acceptance determined by
fitness for business purpose
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






75
N. Kokash, Software Engineering
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
13 practices of XP
Whole team: client part of the team
Metaphor: common analogy for the
system
The planning game, based on user
stories
Test-driven development: tests
developed first
Design improvement (refactoring)
Collective code ownership
Simple design
Small releases (e.g. 2 weeks)
Customer tests
Pair programming
Continuous integration: system always
runs
Sustainable pace: no overtime
Coding standards
77
N. Kokash, Software Engineering
Software Engineering
Differences
Lightweight (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
N. Kokash, Software Engineering
78
Software Engineering
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
N. Kokash, Software Engineering
79
Software Engineering
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)

N. Kokash, Software Engineering
80
Software Engineering






N. Kokash, Software Engineering
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
81
Software Engineering
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
N. Kokash, Software Engineering
Software Engineering
Software Engineering (3rd Ed.)


















N. Kokash, Software Engineering
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
83