Software Engineering. Natallia Kokash N. Kokash, Software Engineering

Natallia Kokash

Introduction

 _{Course overview}  Logistics  Literature  Practical assignment  Evaluation

 _{What is Software Engineering?}

 _{What does Software Engineer do?}  _{Software Engineering Processes}

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

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

Course overview

Theme 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

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

 _{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)

 Convert a picture of a UML class diagram (.bmp, .jpg) to a UML class diagram in

XMI format

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

Final evaluation

 50% written exam

But > 5.5

 50% practical assignment

25% Requirement specification

25% Software architecture and design

25% Implementation

Software Crises

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

“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 goto

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

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

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 Multidata Systems (2000) (8 dead, 20 critically injured)

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

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

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/

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

 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%

Famous Engineering Disasters

 Tacoma Narrows bridge (1940) (1 dog

dead)

 Hyatt Regency Hotel Walkway Collapse

Famous Engineering Disasters

 Chernobyl Nuclear Power Plant (1986) (at

least 5000 dead, 336000 relocated)

 Air crashes:

DC10-S (1979) (271 dead)

Relative distribution of

software/ hardware costs

Hardware Development Software Maintenance 100 60 20 P e rc e nt of t ot a l c os t

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

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

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

Simple life cycle model

requirements engineering design implementation testing 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}

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

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

What does Software Engineer do?

programming, documenting, planning, presenting, reviewing, reporting individually listening, explaining, proving feedback, selling interacting with clients in a team

Specializing in different roles

designing, programming, testing,

Microsoft 1978

brainstorming discussing

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.

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

program information planning boundary conditions people documentation software input 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

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}

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

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

Managing people

 Managing expectations

 Building a team

Managing quality

 Quality has to be designed in

 Quality is not an afterthought

 Quality requirements often

conflict with each other

 Requires frequent interaction

Managing cost

 Which factors influence cost?

 What influences productivity?

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

Waterfall model

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

Requirements engineering Detailed design Global design Coding Unit testing Integration testing Acceptance testing

Evolutionary model

Waterfall Model (Mid 70ies) Test Specification Design Implementation Requ. Eng. &

Architecting Tim e Evolutionary Models (80ies) Increments (Spiral cycles) Iteration

Win-Win Spiral Model

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

7. Verify & commit

6. Implement product & process definitions

5. Define next-increment of product & process, inclusive partitions

4. Evaluate product and process alternatives Resolve risks 1. Identify next-increment stakeholders Emphasizes continuous stakeholder alignment (Boehm, 1998) 2. Identify stakeholders objectives 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

Incremental development

increment 1 increment 2 increment 3 delivered system

first incremental delivery

design build install evaluate

second incremental delivery

design build install evaluate

third incremental delivery

design build install evaluate

Each component delivered must give some benefit to the stakeholders

Velocity tracking

 Measure team productivity

 Unit of work – hours, days, story points,

ideal days

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

Prototyping as a tool for SE

Requirements engineering design design implementation implementation testing testing maintenance

Prototyping approaches

 Throwaway prototyping: the n-th prototype is followed by a waterfall-like process

 Evolutionary prototyping: the n-th prototype is delivered

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

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

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

Recent developments

 _{Rise of agile methods}

 _{Shift from producing software to using software}  _{Software development becomes more}

heterogeneous

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)

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

 _{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

 Fundamental idea: fix time and resources

(timebox), adjust functionality accordingly

 One needs to be a member of the DSDM

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}

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

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.

13 practices of XP

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

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

Heterogeneity

 _{Old days:}

 Software development department had everything under control

 _Nowadays:

 Teams scattered around the globe

 Components acquired from others

 Includes open source parts

Producing software means

using software!

 Builders build pieces, integrators integrate

them

 Component-Based Development (CBSD)

 Software Product Lines (SPL)

 Commercial Off-The-Shelves (COTS)

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}

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

Software Engineering (3

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