Don’t forget to sign

in for the lecture!

COA111: Software Engineering

Russell Lock

“A common mistake that people make when trying to design

something completely fool proof is to underestimate the
ingenuity of complete fools.” – Douglas Adams, Mostly Harmless.
 Objectives for this topic

▪ Administrative arrangements

▪ Introduction to SE
▪ Trends
▪ Stakeholders

▪ Case Studies
 Administrative minutiae

▪ Lecturer Dr Russell Lock

▪ Labs, weeks 5,6,7,8,9

▪ 10% Lab Exercises
▪ 90% Exam (2 hour)

▪ Module Textbook
▪ Software Engineering 10th Edition, Prof Ian
Sommerville, Pearson Education, ISBN-10:
0133943038
▪ 28 Paper copies + Electronic Access
 Lab Exercises

▪ 5 weeks of 2 hour labs

▪ 2 duplicate sessions (correct one will show on your
timetable)

▪ Week 5 – UML Use Case Diagrams (1 exercise)

▪ Week 6 – UML Class & Object Diagrams (2 exercises)
▪ Week 7 – UML Sequence Diagrams (1 exercise)
▪ Week 8 – UML State & Activity Diagrams (2 exercises)
▪ Week 9 – Consolidation (No new exercises)

▪ 2.5% of module mark per week of exercises signed off

 Module topic overview

▪ Software processes & models

▪ Requirement Engineering
▪ Agile development
▪ Modelling using UML
▪ Design & Implementation
▪ Testing
▪ Ethics
▪ Law
▪ Project Management
 Background Reading for this Topic

▪ Chapter 1 of the course textbook

 What is Software Engineering?

▪ Software engineering is concerned with

theories, methods and tools for professional
software development.
▪ Good software engineering involves cost-
effective software development.
▪ The software cost often exceeds that of the
hardware
▪ Maintenance costs for complex systems likely
to be higher than original development
 Putting the pace of software
advancement into perspective
 Image of LEO Mk1 –
Lyons tea room
50s supercomputer

The 50s: The language barrier

Computers make the leap from government into business

But they were huge, unreliable, and difficult to program, leading to:

FORTRAN
Higher Level General Purpose Programming
Languages
 Image of PDP-1

The
The 60s: Defining the lifecycle

‘Timesharing’ allows computers to be used far more

widely
But we kept mishandling implementations due to the lack of
defined software development processes. This was termed:

The Software
Crisis
‘Software Engineering’ was born
The
The 70s: Reliability

We could now fit powerful computers into smaller spaces

But the hardware/software still wasn’t very reliable

Leading to techniques such as:

Triple N version
Modular programming
Redundancy
The
The 80s: HCI

Usable Consumer computers Ubiquity

Software is now everywhere, but the interfaces are apalling….

The
The990s: Complexity

Complexity reaches dizzying levels, leading to:

Object Open
Agile
Orientation Source
The
The 00s: Social & Disposable
The cost benefits of outsourcing are
realised through better collaborative
support technologies
• Social networking, project
management software, bug tracking
software, video conferencing, wikis,
forums etc

Apps lead to disposable, fast to

market software

Rapid uptake of new technology causes

scaling issues, leading to ‘cloud’
The
The 10s: Big Data

We finally have the computing

power we need

Two key frontiers include:

• How much work can be
shifted into software?
• How do we make sense of
the data around us?
 Software Engineering Today

▪ The economies of ALL developed nations are

dependent on software.
▪ Practically all systems are software controlled
▪ IT expenditure worldwide: £3.7 Trillion (2018 -
Gartner)
▪ Enterprise Software Expenditure: Approx £400
Billion

▪ On average 15.7% of project budgets are spent

on RE (Hofman 01)
▪ Approx 60% of all errors originate in the
requirements process (McConnell 04)
 An example...

▪ 74 sensors
▪ 70 onboard
computers
▪ Generates more
than 25 gigabytes
of data per hour

This image is licensed under the Creative Commons Attribution-Share Alike 3.0 Germany, M93
Reasons for software development
failure

▪ Incomplete requirements 13.1 %

▪ Lack of user involvement 12.4%
▪ Lack of resources 10.6%
▪ Unrealistic expectations 9.9%
▪ Lack of executive support 9.3%
▪ Changing reqs/specs 8.7%
▪ Lack of planning 8.1%
▪ Didn't need it any longer 7.5%

(Pfleeger)
 Why is software different?

Software is a surprisingly recent achievement

It has changed the rules…..

Images sourced from FreeDigitalPhotos.net

Trends....
 Outsourcing

▪ Theory:
▪ If it is expensive to do in-house, outsource it
▪ If you are bad at something, outsource it

▪ Practice:
▪ It can save significant money
▪ Outsourcing inevitably complicates
management
▪ If you were bad at it, and you outsource it, do
you understand what you have outsourced?
 Outsourcing: The waterfall model

Dependency on
appropriate requirements

Dependency on
appropriate Design

Potential loss of operating data

22
 Outsourcing is not the easy option….

This image is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported licence
 Bespoke vs COTS

▪ Bespoke development
▪ Develop from scratch, could be embedded
▪ Deciding what requirements are necessary
▪ Ensuring you get them!
▪ Could be tricky to maintain, and risky to develop within a set
timeframe and cost
▪ COTS (Commercial Off The Shelf)
▪ Relies on standard products
▪ Deciding what requirements are necessary
▪ More focus on where to compromise needs or extend
existing systems
▪ Has its own drawbacks......
▪ In reality practically every system is becoming a hybrid to some
extent
▪ Independence has become a concern in many systems
 Working with COTS products

“With a standard package there is no such thing as a

‘minor’ code change. It is like trying to add an
appendage to a human being. Imperfect as we are,
we are tried and tested and are unlikely to work
better with two hearts, or run faster with three legs. If
you want to keep the project really simple, buy a
package but don’t modify it.

Tony Collins, author of CRASH

 Software process activities

▪ Software specification, where customers and engineers

define the software that is to be produced and the
constraints on its operation.

▪ Software development, where the software is designed

and programmed.

▪ Software validation, where the software is checked to

ensure that it is what the customer requires.

▪ Software evolution, where the software is modified to

reflect changing customer and market requirements.
 Software engineering fundamentals

▪ Some fundamental principles apply to all types of software

system, irrespective of the development techniques used:
▪ Systems should be developed using a appropriate,
managed and understood development process.
▪ Dependability and performance are important for all
types of system.
▪ Understanding and managing the software
specification and requirements (what the software
should do) are important.
▪ Where appropriate, you should reuse software that has
already been developed rather than write new
software.
Stakeholders
 Stakeholders

▪ Customers
▪ Users
Balancing the needs
▪ Managers
of these groups is a
▪ System owners
tough job
▪ Maintainers (IT support etc)
▪ Developers
▪ Analysts
▪ Designers
▪ Programmers, etc.
 Changing times, changing levels of
user involvement

Batch Processing Distributed systems Cloud Computing

Timeshare Fuzzy Logic Tablet PCs
Custom software The home computer Social Networking

Databases OO Paradigm Robotic

Real-time systems Grid Technology attack
monkeys?
Multi-user Web 2.0

1940 1950 1960 1970 1980 1990 2000 2010 2020

Academic Researchers
Government
Industry
Home Users
SE and the jelly mould effect

Image not subject to copyright

 Removing the Jelly Mould

Thou shalt not computerise until the existing

paper-based or semi-computerised
processes have been simplified, simplified
again and further simplified long before
computerisation; in any efficiency drive,
computerisation is the last thing to do

Tony Collins, Author of CRASH

 DVLA (Old System)

DVLA DVLA
Website Database Police
National
MID Computer
Database System
 DVLA (Old System)

DVLA DVLA
Website Database Police
National
MID Computer
Database System
 DVLA (step 1)

DVLA DVLA
Website Database Police
National
MID Computer
Database System
 DVLA (step 2)

DVLA DVLA
Website Database Police
National
MID Computer
Database System
 DVLA (step 2)

DVLA DVLA
Website Database Police
National
MID Computer
Database System
 DVLA (step 3)

DVLA DVLA
Website Database Police
National
MID Computer
Database System
 The jelly mould in action

Out with the old In with the new

1. Student prints coursework

2. Student hands in coursework at office
3. Office stamp coursework with
submission time/date What would you do?
4. Office hands report to academic
5. Academic checks for plagiarism
6. Academic marks coursework
7. Mark handed to office
8. Mark sheet printed
9. Mark sheet pinned to notice board
10. Student checks marks
 Requirements engineering involves
U.S. Troops Conduct Live Fire Exercise evolution & compromises
Near Iraqi Border © Getty Images

But this can be taken too far......

 A couple of real world issues....

New Passenger Train © Getty Images Missile Launcher © Getty Images

 Summary

▪ Software Development is context specific

▪ When we get things wrong it can be very
expensive

▪ In the next lecture:

▪ Software Processes
 AG Overview

▪ Designed to support your education

▪ Requested by students two years ago
▪ Mandatory completion of tasks
▪ AG tutor meetings:
▪ Week 3: Individual (arranged by your AG tutor)
▪ Week 6/7: Group (This will appear on your timetable)
▪ Themed weekly tasks:
▪ Week 2 – Health and Safety (Quiz)
▪ Week 3 – The Library (Quiz)
▪ Week 4 – Plagiarism (Quiz & Essay)
▪ Week 5 – Handbook (Quiz)
▪ All accessed via LEARN “18COA001 - School of
Science Academic Guidance”