Leiden University. The university to discover. Leiden University. The university to discover. Leiden University. The university to discover. Software Engineering.

Leiden University. The university to discover. Leiden University. The university to discover.

Software Engineering

Leiden Institute of Advanced Computer Science

Lecture Series for BSc. “Computer Science” year 2

(Fall semester 2013)

Leiden University. The university to discover.

“Software Engineering” (B.Sc. Computer Science / Fall 2012)

2 | 81Outline

Introduction / Course logistics Introductory lecture Software Engineering

What is Software Engineering? What does a Software Engineer do? What does a Software Engineering

Process look like?

These slides are based on slides by Drs. Werner Heijstek, Dr. Natallia Kokash, Dr. Michel Chaudron and Professor Dr. Hans van Vliet

Leiden University. The university to discover. Leiden University. The university to discover.


“Course Logistics”






4 | 81Who am I?

Tim Cocxhttp://www.timcocx.nlRoom 124 (Thursdays), 071-5275777, [email protected]

• Teach this course for the second time• Also: statistics• Main job: Haagse Hogeschool• I hold M.Sc. (2004) & Ph.D. (2009) degrees from Leiden

University• My current main focus points are programming and

software design• Married with two cats

http://fmt.isti.cnr.it/~mtbeek/



5 | 81What you will learn in this course?

Engineering = skill + knowledge—This course 30% knowledge and 70% skills

Basic concepts, vocabulary of Software Engineering

Main activities in Software Engineering projects Main methods and techniques

—excluding: programming

(Maybe) Guest Lectures by professionals Software Engineering as an academic research

area



6 | 81The Only Really Important Info

http://www.liacs.nl/~tcocx/SE2013



7 | 81Lectures Schedule

• There is a iCal file on the website for phone / tablet usage

• Week 1• Morning: Course & Subject Introduction• Afternoon: Nothing / Free / Self-Study

• Week 2• All day: Reverse Engineering• Week 3

• All day: Modelling• Week 4-14:

• Morning: Class• Afternoon: Lab

• Week 15 Monday & Tursday:• All Day Assessments

• 20-12-2013 10.00 Exam

• NB: 3rd October: Only party• NB: 24th October: No class, exam in afternoon



8 | 81Grading

Week 2: Reverse Engineering Assignment (20%)

Deadline Week 4 Week 8: Modelling Exam (20%) Week 15: Assessments (40%) Week 16: Theoretical Exam (20%)

All grades must be sufficient (>=5.5)



9 | 81Lab

You will do a Software Engineering Project In teams of 6-10 people Focus on a proper development process Results: Documentation, process “Log’s”,

Software Programming skills are required.

Assignment: You’ll see when the lab starts (surprise!)



10 | 81


“An Introduction”






11 | 81The Software Crisis

“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 DijkstraThe Humble Programmer, Communications of the ACM (1972)



12 | 81Division Computer costs

HardwareDevelopment

Software

Maintenance

1955 1970 1985

Year

100

60

20

Per

cen

t of

tot

al c

ost



13 | 81The 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



14 | 81The Birth of Software Engineering

The term Software Engineering was introduced at 1968/69 NATO conferences Idea: software development is not an art, or a

bag of tricks We should build software like we build bridges



15 | 81What is Software Engineering?

The process of solving customers’ needs by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints

Solving customers’ problems This is the goal of software engineering Sometimes the solution is to buy, not build Adding unnecessary features does not help solve

the problem Software engineers must communicate

effectively to identify and understand the problem



16 | 81Definition (IEEE)

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



17 | 81Is Software Engineering, Engineering? Software is logical, rather than physical Progress is hard to see 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



18 | 81Types 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



19 | 81Types 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 keySome software has both aspects!



20 | 81The Nature of Software

Software is intangible Hard to understand development effort

Software is easy to reproduce Cost is in its development

in other engineering products, manufacturing is the costly stage

The industry is labor-intensive Hard to automate



21 | 81The Nature of Software

(Untrained) people can hack something together Quality problems are hard to notice

Software is easy to modify People make changes without fully understanding

it

Software does not ‘wear out’ It deteriorates by having its design changed:

erroneously, or in ways that were not anticipated, thus making

it complex



22 | 81The 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%

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%

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

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



23 | 81Central Themes in Software Engineering Software Engineering is

concerned with large programs These programs are complex Software evolves Development must be efficient You’re doing it together Software must effectively support users Involves different disciplines Software Engineering is a balancing act



24 | 81What does a Software Engineer do?

programming

presenting

reporting

documenting

individually

listening

interactingwith clients

in a team

explainingfeedbackplanning

reviewing

Specializing in different roles- designing, programming,

testing … brainstormingdiscussingplanning

selling

Microsoft 1978



25 | 81Simple “Life Cycle” Model

problem

reqs specification

requirements engineering

design

design

implementation

system

testing

working system

maintenance

15%

20%

20%

45%

Typical distribution of effort(excluding maintenance)



26 | 81Requirements Engineering

Includes—Domain analysis—Defining the problem—Requirements gathering

- Obtaining input from as many (relevant) sources as possible

—Requirements analysis- Organizing the information

—Requirements specification- Writing detailed instructions

about how the software should behave

Results in a description of the DESIRED system:

which functions

possible extensions

required documentation

performance requirements

Includes a feasibility study

Resulting artifact:

requirements specification



27 | 81Design

Includes Deciding how the requirements

should be transferred to software, using the available technology

• Includes:—Systems engineering: Deciding

what should be in hardware and what in software

—Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact

—Detailed design of the internals of a subsystem

—User interface design—Design of databases

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

specification



28 | 81Implementation

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



29 | 81Testing

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



30 | 81Maintenance

Correcting errors found after the software has been delivered

Adapting the software to changing requirements, changing environments, ...



31 | 81Effort Distribution

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



32 | 81Actual Effort Distribution



33 | 81Software Engineering in a Nutshell



34 | 81Codex Hamurabi

“If a builder build a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death.”

Article 229 of the Code of Hammurabi (1780 BC)

http://www.wsu.edu/~dee/MESO/CODE.HTM



35 | 81Software 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



36 | 81Difficulties and Risks in Software Engineering

Complexity and large numbers of details Uncertainty about technology Uncertainty about requirements Uncertainty about software engineering skills Constant change Deterioration of software design Political risks



37 | 81Software Development Methods

Software 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



38 | 81Software Development Process Models

Waterfall Iterative




Tim

e

Waterfall Model (Mid 70ies)

Test

Specification

Design

Implementation

Requ. Eng. &Architecting

No iterations Big bang scenario

First-time right

milestone 1

milestone 2

milestone 3

milestone 4

milestone 5



40 | 81

40

Feasibility study

The waterfall model

User Requirements

System Design

Coding

Operation

Testing

Analysis

Program Design

Decomission



41 | 81

41

Pro's and Cons of the Waterfall Model

Pro's: Imposes structure on

complex projects Every stage needs to

be checked and signed off:

Elimination of midstream changes

Good when quality requirements dominate cost and schedule requirements

Cons:Limited scope for

flexibility / iterationsFull requirements

specification at the beginning:

User specificationsNo tangible product

until the end



42 | 81Problems of the Waterfall Process (2)

Business Modeling

Requirements & Architecting

Specification & Design

Implementation

Testing

Consultants

Architect(s)

IT-Specialists

IT-Engineers

IT-Engineers

Communication becomes highly critical

Different phases are handled by different people




WaterfallModel

(Mid 70ies)

Test

Specification

Design

Implementation

Requ. Eng. &Architecting

Scope

Tim

e

EvolutionaryModels(80ies)

Increments(Spiral cycles)

Iteration



44 | 81Rational Unified Process (RUP)

Phases

Iterations

Disciplines



45 | 81Problems of Evolutionary Models

Inflexible point solutions The initial release is optimized for demonstration, consequently the architecture is difficult to

extend

High-risk downstream capabilities The initial release often defers quality attributes (dependability, scalability, etc.) in favor of early

functionality



46 | 81

increment 1

increment 2

increment 3

deliveredsystem

Incremental delivery

first incremental delivery

design build install evaluate

second incremental delivery


third incremental delivery


Each component delivered must give some benefit to the stakeholders



47 | 81The Plan



48 | 81Reality



49 | 81The Agile Manifesto

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



50 | 8112 Agile Principles

Satisfy the customer through early and continuous delivery

Welcome changing requirements, even late in development

Deliver working software frequently

Business people and developers work together daily

Build projects around motivated individuals

Convey information via face-to-face conversation

Working software is the primary measure of progress

Maintain a constant pace indefinitely

Give continuous attention to technical excellence

Simplify: maximize the amount of work not done

Teams self-organize

Teams retrospect and tune their behaviors



51 | 81Prototyping

Requirements elicitation is difficult software is developed because the present situation is

unsatisfactory however, the desirable new situation is as yet unknown

Prototyping is used to obtain the requirements of some aspects of the system

Prototyping should be a relatively cheap process use rapid prototyping languages and tools not all functionality needs to be implemented production quality is not required



52 | 81Prototyping Approaches

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

process Evolutionary prototyping

the n-th prototype is delivered



53 | 81Pro's and Cons of Prototyping

Pro's 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

Cons

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



54 | 81Popular Agile Methods

Rapid Application Development (RAD) & Dynamic System Development Method (DSDM)

Extreme Programming (XP) Feature Driven Development (FDD) Unified Processes:

Rational Unified Process Agile Unified Process (AUP) Open Unified Process (OpenUP)/Basic Essential Unified Process (EssUP)

Scrum



55 | 81(R)UP

(Rational) Unified Process.Philosophy:

Four phases in WaterfallInception: Determine the plan and starting REQElaboration: Elaborate on REQ and DesignConstruction: Building & TestingTransition: Delivery, Installation, Instruction

Within the phases iteration takes place until a predetermined ‘Milestone’ has been reached

Disciplines are part of the team for the project durationThere are, however, peaks in usage

Artifacts (documents): Change during the project.There are however peaks in work on them.



56 | 81Rapid Application Development (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



57 | 81Dynamic System Development Method Is a RAD framework Popular in the UK Fundamental idea: fix time and resources

(timebox), adjust functionality accordingly One needs to be a member of the DSDM

consortium



58 | 81Extreme 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 Pair Programming

Manifesto: If … is good then [fill in

extreme form]



59 | 81Agile versus Traditional Development

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



60 | 81Producing 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)



61 | 81Software Quality...

Usability• Users can learn it and fast and get their job done easily

Efficiency• It doesn’t waste resources such as CPU time and memory

Reliability• It does what it is required to do without failing

Maintainability• It can be easily changed

Reusability• Its parts can be used in other projects, so reprogramming is

not needed



62 | 81Software Quality...

QUALITY SOFTWARE

Developer: easy to design; easy to maintain; easy to reuse its parts

User: easy to learn; efficient to use; helps get work done

Customer:

solves problems at an acceptable cost in terms of money paid and resources used

Development manager: sells more and pleases customers while costing less to develop and maintain



63 | 81Software Quality

The different qualities can conflict• Increasing efficiency can reduce maintainability or reusability• Increasing usability can reduce efficiency

Setting objectives for quality is a key engineering activity• You then design to meet the objectives• Avoids ‘over-engineering’ which wastes money

Optimizing is also sometimes necessary• E.g. obtain the highest possible reliability using a fixed budget



64 | 81Homework

‘Teach yourselves’ UML diagrams This way you can start the assignment with a

head-start.

Leiden University. The university to discover. Leiden University. The university to discover. Leiden University. The university to discover. Software Engineering.

Documents

leiden university

software engineering

term software engineering

software development

software crisis

inefficient software

software design

birth of software