COMP5590 – Week 13
Integrated Development
Environments
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Outline
•Using an Integrated Development Environment
•Introduction to Eclipse
Some of the materials are inspired by previous years' lectures
2
Why not use BlueJ?
•BlueJ enables the user to directly create objects
of any class and interact with their methods
•BlueJ visualizes class structure
•BlueJ is easy to use
3
Problems with BlueJ
•Not for Professional Software Development
•Hard to keep overview for large number of classes
and packages
•BlueJ intentionally has a limited number of features
• no continuous checking for errors
• no refactoring
• only for Java
• limited integration with teamwork tools
4
Eclipse
• Most widely used Integrated Development Environment
for Java
(there are others, e.g. Netbeans, IntelliJ)
• Flexible plugin-architecture encouraged numerous
extensions
• Open source and free to use
• But huge and complex
5
Installing Eclipse
•You may need to have JRE or JDK installed
•Download from http://www.eclipse.org
•Available as zip or tar file for various operating
systems
•Just unzip/untar and put whole folder wherever
you store executable programs
6
Documentation
http://www.eclipse.org/users/
•Getting Started with the Eclipse Workbench
•Getting Started with Java development
•Lots of further online documentation
7
Selecting a Workspace
• A workspace is just a directory
• Inside a workspace all source code + compiled
code + preference are stored
• You can have several workspaces
• Choose a directory and click OK
8
Welcome Screen
Gives access to overview,
news, sample code and
tutorials
Select arrow
on right to
get to the
actual IDE
9
Standard Window (Java Perspective)
Projects and
files are
listed here.
Editor: Here you edit your
source code.
Hierarchical
view of source
files.
Various: Compiler errors, console, …
10
Eclipse User Interface
• The Eclipse Window is divided into numerous Views and
Editors (all called Parts).
• Views and Editors can be closed, opened and rearranged like
windows / panes.
• Such an arrangement is called a Perspective.
• Open a Perspective with menu Window -> Open
Perspective…
• Normally use Java or Debug Perspective
• Window -> Reset Perspective to get default
11
Creating a New Project
12
Creating a New Project
Enter a name for the project,
then click Finish.
13
Creating a New Project
Newly
created
project
appears
in
Package
Explorer
14
The src folder
A folder
to store
your
source
code was
created
too.
15
Creating a Class
16
Creating a Class
Class Wizard
• Fill in details:
• Package name
• Class name
• Superclass
• Whether to include main
• Click Finish
17
The Created Class
New
package
and Java
source file
Source file in editor pane
Also here
18
Compilation Error
Hovering
over
light
bulb
displays
error
message
Error underlined with
red line
Red line
marks error
position. Click
to jump to
error line.
19
Compilation Error
20
Run Program
21
Run Program
Eclipse asks which modified files to
save before compiling
22
Run Program
23
Run Program
Output in Console Tab
24
Re-Run Program
25
Run Configuration
26
Run Configuration
27
Getter/Setter Generation
28
Getter/Setter Generation
Choose members for which
to generate getters and
setters
29
Getter/Setter Generation
New
Code
30
Javadoc Comment Generation
31
Generate Javadoc for Classes
32
Generate JavaDoc for Classes
• At first time have to
give path for Javadoc
command
• Select classes for which
to generate
• Give path for
destination of
generated Javadoc
33
View Javadoc
1. Open JavaDoc
view
2. Right-click to
select open
attached
JavaDoc
Or
Navigate ->
Open Attached
Javadoc
34
Debugging
Set
breakpoints
by double
clicking in
margin
35
Start Running in Debugger
36
Debugging
• When starting debugging, Eclipse asks to switch to a
perspective suited for debugging; select Yes
• A perspective is an arrangement of views and panes in
the Eclipse window
37
Debugging
Location of
current
breakpoint
Current line
in program
Buttons for stepping through program
Click Java
for Java
perspective
Variables in
scope; right
click to
modify
Output
console
38
Debugging
39
Debugging
40
COMP5590 – Week 13
Module Overview
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Outline
•Module overview
• Lectures and Classes
• Group project
•Introduction to software development
Some of the materials are inspired by previous years' lectures and Sommerville’s book
2
Assessment Structure
•50% Coursework
• A1: 10%
• A2: 30%
• A3: 10%
•50% Exam
3
Group Project
•A1: Group Presentation (User Stories) – 10%
•A2: Group Project – 30%
•A3: Individual Project Reports – 10%
4
Working in a Group
•Being dependent on others can be challenging
•But, working with others is the norm in realworld software development settings
•Build on your experiences from last year
•Good practice for final year projects
5
Group Formation
•Form your own groups
• Four or five people
• Among people assigned to the same class
• Arrange your group during W15 class (KV W27) and let
your class supervisor know
• If you can’t attend, let your class supervisor know so
they can put you in a group
6
A1
•Describe user stories
•Every group member chooses different stories
•Act as user and developer
•Presentations to take place during classes
7
A2
•Three stages
• Corresponding to three Sprints
• Each sprint takes two weeks
• Implement user stories for Sprints 1-3
•Submit deliverables after each Sprint
• Code
• Tests
• Documentation
8
A3
•Individual contributions
•Reflections on group work and project
management practices
•Reflections on individual performance
•Description of future improvements
9
Software Development
•Goal
• What is the aim of the software?
• What the system should do
•Design and implement
•Test: check that the system does the desired
10
Software vs Traditional Engineering
Getty Images
11
Plan-driven vs Agile Processes
•Plan-driven processes
• process activities are planned in advance
• progress is measured against this plan
•Agile processes
• planning is incremental
• easier to change the process to reflect changing
customer requirements
12
Software Process Models
• The Waterfall model
• Separate and distinct phases of specification and development
• Plan-driven model
• Incremental development
• Specification, development and validation are inter-leaved
• May be plan-driven or agile
• Reuse-oriented software engineering
• The system is assembled from existing components
• May be plan-driven or agile
13
Coping with Change
•Change is inevitable in all large software projects
• Business changes lead to new and changed system
requirements
• New technologies open up new possibilities for
improving implementations
• Changing platforms require application changes
14
Software Prototyping
•A prototype is an initial, partially working version of
a system used to demonstrate concepts and try out
design options
•A prototype can be used in:
• The requirements engineering process to help with
requirements elicitation and validation
• In design processes to explore options and develop a UI
design
15
Why Agile Methods?
•Rapid delivery and deployment
•Requirements change quickly in changing
business environment
•Plan-driven processes have substantial
overheads, e.g. documentation
16
Collecting Requirements
•Requirements expressed as user stories, written on
story cards
•Development team breaks these down into tasks
•Customer prioritises stories
•A few stories for next release chosen
•Later stories may change or be discarded
17
Extreme Programming (XP)
• Perhaps the best-known and most influential agile
method
• Extreme Programming (XP) takes an “extreme” approach
to incremental development
• New versions may be built several times per day
• Increments are delivered to customers every 2 weeks
• All tests must be run for every build and the build is only accepted
if tests run successfully
• Focus on technical/programming practices
18
Pair Programming
• In XP, programmers work in pairs
• Sitting together to develop code
• Pairings change over time
• This helps develop common ownership of code and spreads knowledge across the team
• The team has collective responsibility for resolving problems
• Reduces risks when team members leave
• Serves as an informal review process as each line of code is looked at by more than
one person
• Encourages refactoring
• Measurements suggest that development productivity with pair programming is similar
to that of two people working independently
19
Refactoring
•Re-organisation of a class hierarchy to remove
duplicate code
•Tidying up and renaming attributes and methods to
make them easier to understand
•The replacement of inline code with calls to
methods that have been included in a program
library
20
Additional Material
• Software Engineering by Ian Sommerville:
http://iansommerville.com/software-engineering-book/
• Agile Manifesto: https://agilemanifesto.org/
• Extreme Programming: http://www.extremeprogramming.org
• Refactoring: http://refactoring.com
• Agile Resources:
• https://www.agilealliance.org/
• https://www.scrumalliance.org/
• https://www.pmi.org/certifications/agile-acp
• https://www.mountaingoatsoftware.com/agile
21
COMP5590 – Week 15
Version Control & Git
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Outline
•Version Control
•Branches and Merging
Some of the materials are inspired by previous years' lectures
2
School’s GitLab
https://git.cs.kent.ac.uk/
3
Version Control
Did this ever happen to you?
• Had code that worked, made some changes which broke the code and now just want the
last working version back
• Accidentally deleted a file
• Somehow messed up the structure of the files
Want an “Undo” button
• Familiar from word processors, spreadsheets
• But want it to work over days, months, not just one IDE run
• Need coarser granularity than undoing single characters
4
Version Control
•Individual Use
• Keep a history of changes (change log)
• Mainly for source code, but virtually for any file (even
binaries)
•Manual (or Local) Solution
• Version by filename: file, file2, file.old, file-1Feb21
• Version by folder: file, old/file, 2Feb18/file
• Version by increments and initials: file-v1-ROK, file-v2-XYZ
5
Group Collaboration
•Large number of developers
•Who did what, when, and why?
•Merge various changes on the same file
•Revert (undo) if something goes wrong
6
Centralised Version Control Systems
•CVS, SVN
•Single (central) server with all the versioned files
•Clients check out files from the server
•Has been the standard for version control for
many years
7
Git Basics
•Distributed: clients don’t just check out
snapshots, they clone the whole repository
•Free and open source
•Server-side interfaces
•Integrated in other software
•Good documentation: Books, tutorials
8
Git States
https://git-scm.com/book/en/v2
9
User Interfaces for Git
• Has a command line user interface
• For Windows GUI TortoiseGit
• integrates into windows explorer, with icon overlays
• context menu (right click) provides all git commands
• freely available
• IDEs such as Eclipse, Netbeans, IntelliJ have a direct interface to Git
• Web-based GUIs for central servers may provide more than just Git, e.g. GitLab, GitHub
10
First Use of Git
Tell git who you are:
$ git config --global user.name "John Doe"
$ git config --global user.email jd@kent.ac.uk
With TortoiseGit, select TortoiseGit->Settings
In the Settings dialogue, choose Git and enter name and email
Git records for every version who made it
11
Create Local Repository
• Start a project with a directory of all project files (working tree, possibly empty)
• Create a local repository for your working tree:
$ git init
• A subdirectory .git will be created as local repository
• At this point the repository will describe an empty project
12
Tracked and Untracked Files
• Usually a project directory contains some files that you do not want to be tracked by the
version control system, e.g. track .java files, but not .class files
• By default Git may not track any files, you may have to tell it which files to track:
$ git add *.java
13
Which Files to Track?
• source code
• configuration files
• build files and utility scripts
• documentation (requirements, specification, …)
• test specifications, programs and data
• webpages
• icons, images
• any file that is part of a project!
Not specific to source code, but best for plain text files
14
Which Files not to Track
Any file automatically generated from other files
e.g.
• MyProg.java belongs under version control
• MyProg.class does not!
Ignoring this rule wastes space
15
Committing a Version
Commit a new version to your repository:
$ git commit -a
a text editor will ask you to enter a message; alternatively:
$ git commit –a –m “Descriptive message”
Git will confirm success with some information about the new version.
16
Which Files Are Committed?
• By default all tracked files that have changed
• In TortoiseGit a file selector box allows you to (de)select
• The command line interface can use a staging area
$ git add filename
$ git status
$ git commit –m “Descriptive message”
17
History & Undo
• The Git log shows all commits of local repository in reverse
chronological order
• “checkout” can get any old version from local repository into
the working tree
log
local repository
checkout version
working tree
18
Branches
• variants may be developed in different ways
• main branch with bug-fixes
• a branch for each feature under development
• get own name
• can be merged again
Every repository already has one branch called master
19
Branches
• Create a new branch
$git branch branchname
• Switch to a branch
$git checkout branchname
• Can commit to different branches
• By default a commit is to the current branch
20
Merging Branches
• A new feature in a branch may be finished. Want to add it to the master branch
• Merging another branch with the current branch:
$git merge otherbranchname
• If merging successful, then git commits a merged version automatically
• Otherwise you have to resolve the conflict
21
Automatic Merging
• If the file from one branch is an old version of the file from the other branch, then newer
version is chosen
• Independent changes of two version of a text file can be merged automatically
22
Merge Conflict & Resolution
Git generates a merged file with a conflict:
Tomato
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Edit yourself, removing special lines, and then tell git that conflict resolved:
$ git commit -a –m “What I did”
23
Merge Conflict Resolution for Binaries
• If a binary file has two conflicting versions, you have to choose one:
$ git checkout --ours -- fullPathOfFile
$ git checkout --theirs -- fullPathOfFile
• After resolution commit as usual
24
Merging is Fundamental
Automatic merging
• works well on text files (differences in different lines)
• but moving large text parts around causes problems
• (generally) does not work for binary files
Can always manually resolve merge conflict
In practice developers work mostly on separate files, but some overlap exists
25
Distributed Repositories in Git
• Every working tree comes with a local repository
• As many additional repositories as you like
server
central repository
machine A
machine B
machine C
local repository A
local repository B
local repository C
working tree A
working tree B
working tree C
26
Different Repository Locations
• On a server on the internet
• accessible for all team members
• running 24/7
• more likely to be backed up
• On your own computer
• always accessible for you, even without network access
• high speed access
27
Setting up Git
• Central repository usually created with web-based system such as GitLab
• Local repositories cloned from central repository
• Checkout gets selected version into working tree
central repository
clone repository
local repository
checkout
working tree
28
Basic Workflow
Clone from central repository and checkout
or
Pull recent versions from central repository
Cycle
• Local Cycle
clone
push
pull
– Make changes to working tree
– Commit working tree as new version to local
repository
• Pull latest versions from central repository
(including merge with working tree)
• Push versions of local repository to central
repository
central repository
local repository
commit
checkout
working tree
29
Starting a Project
• One member may connect their local repository to a server and push all contents to the
empty central repository
$ git remote add origin
https://gitlab.../project.git
• Everybody else clones the central repository from the server
• Branches: most git commands can take a branch as parameter
30
Additional Material
•Git: https://git-scm.com/book/en/v2/GettingStarted-About-Version-Control
•Tortoise Git: https://tortoisegit.org/
•Git for Eclipse:
http://wiki.eclipse.org/EGit/Git_For_Eclipse_Us
ers
31
COMP5590 – Week 17
Continuous Integration
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Learning Outcomes
•After this lecture, you will be able to
• Describe the advantages of continuous integration over
tradition software development practices
• Explain the stages of continuous integration, delivery, and
deployment
• Understand tool support for the automation of continuous
deployment
• Review software development features supported by GitLab
2
Problem
3
Developing in a Team: File Sharing
4
Lock-Modify-Unlock Solution
5
Copy-Modify-Merge Solution I
6
Copy-Modify-Merge Solution II
7
Modern Software
•Requirements change
•Develop as you go
•Automate the process of testing and
deployment
8
Modern Software Development
•Do multiple releases per day
•Avoid major failures
• Test major components
• Make sure you don’t break core “business logic”
•Small issues can be corrected in minutes
9
What can Go Wrong?
•Modern software systems are built from
components and libraries
•You don’t have control over all the code in your
software
•Major incidents where library developers break
major programs
10
Continuous Integration
• “List of practices for
integrating code
changes from
multiple developers
in a software team
into the main
development branch
as early and frequent
as possible”
https://docs.gitlab.com/ee/ci/introduction/
11
Continuous Delivery/Deployment
•Continuous Delivery: keep the codebase
deployable at any point
•Continuous Deployment: automatically release
to the production environment
12
The Joel Test
• Do you use source control?
• Can you make a build in one
step?
• Do you make daily builds?
• Do you have a bug database?
• Do you fix bugs before
writing new code?
• Do you have an up-to-date
schedule?
• Do you have a spec?
• Do programmers have quiet
working conditions?
• Do you use the best tools
money can buy?
• Do you have testers?
• Do new candidates write
code during their interview?
• Do you do hallway usability
testing?
13
Ensuring Good Project State
•Make sure "master" branch always works
•Everything builds on a clean machine
•All tests run automatically and pass
•Use tool support
14
Modern Project Structure
• Code and tests:
• Writing quality code
• Writing tests
• Running tests
• Dependency management:
• Getting versions right
• Making use of package managers
• Build configuration: build and run with one command
• Continuous integration: tool configuration
15
How to Use CI
•Automatic reproducible build
•Package management and tests
•Service to run builds
16
Tool Support: GitHub
•Runs build and tests every time you “git push”
•Runs build and tests for every pull request
•Shows warning when build fails
17
Software Development
with GitLab
•GitLab Web User Interface
•Bug Tracking
•Issue Tracking
•Wiki
18
Bug Tracking
• User informs developer about a problem
• Developer has to reproduce problem, isolate
circumstances, locate and fix and finally deliver
fix to user
• How to organise the debugging process?
• which problems exist that need to be fixed?
• which problems have which priority?
• did similar problems occur in the past?
• user may want to know the state of their problem
• For a tiny project a simple problem list
document may do
19
Issue Tracking
An issue is a small piece of text,
describing e.g. a feature request,
task, bug report, support problem
An issue
• created by one user
• assigned to one user
• reassigned many times
• anybody can add comments
• can refer to a version of code
• finally closed
https://docs.gitlab.com/ee/user/project/issue_board.html
20
Wiki
• Your own project Wikipedia
• Create and edit pages on a topic
• Create links between Wiki pages and
commit messages and issues
• Wiki pages have their own version
control and thus history
21
Tool Support: GitLab
•GitLab CI/CD
• https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/
• https://docs.gitlab.com/ee/ci/
22
Additional Material
• Best practices and guides:
• The Joel Test: 12 Steps to Better Code:
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12steps-to-better-code/
• https://www.martinfowler.com/articles/continuousIntegration.ht
ml
• https://www.atlassian.com/continuous-delivery/continuousintegration
• https://about.gitlab.com/stages-devops-lifecycle/continuousintegration/
23
COMP5590 – Week 17
Project Management
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Learning Outcomes
•After this lecture, you will be able to
• Describe common problems with software projects
• Review what each planning phase contributes to the
project
• Understand the importance of building a project team
2
Basics
•Goal: Deliver what the customer wants
• Understand what the customer wants (requirements
elicitation)
• Plan and estimate the work that needs to be done
• Verify the quality of the resulting product
3
Design
4
Implementation
5
Delivery
6
Common Problems
•Over budget
•Delivered late
•Does not deliver what the customer really wants
• Poor requirements elicitation
• Poor communication with the stakeholders
7
Software Engineering: Uniqueness
•Numerous types of software:
• Safety-critical systems (power plants)
• Healthcare (hospitals, GPs)
• Mobile games
• Online banking
• Physical interaction (robots)
8
Methodologies
•A set of guiding principles and processes for
managing a project
•Describes how teams work and communicate
•Typically, the project manager chooses a
methodology
•Involves tools to accompany the selected
methodology
9
How to Choose? Project Factors
•Project properties
• Requirements
• End product
• Budget
• Timeline
• Size (complexity, lines of code)
• Domain (type and industry)
10
How to Choose? Team Factors
•Team capabilities
• How familiar is the team with the candidate project
management methodologies?
• How experienced is the team?
• Where is the team located?
11
How to Choose? Other Factors
•Organisational
•Stakeholders
•Tools
12
Planning Phases
1.
2.
3.
4.
5.
6.
7.
8.
9.
Project goals and critical success factors
Scope and assumptions
Tasks and targets
Roles and responsibilities
Quality plan
Documentation
Project control and reporting
Stakeholder analysis
Risk analysis
13
Phase 1: Goals
•What is the overall aim or purpose of the
project?
•What goals or objectives do we need to support
that aim?
•What features and functionality do we need to
have to meet those objectives?
14
Phase 2: Scope
•What is included in the project?
•What is not included in the project?
•What assumptions are you making?
• Staffing
• Third-party suppliers
• Technical issues
• Implicit features
15
Phase 3: Tasks
Project
Goal
Deliverable-2
Deliverable-1
Task-D1.1
Task-D1.2
Task-D2.1
TaskD2.1.1
TaskD2.1.2
TaskD2.1.3
16
Targets and Milestones
• Should follow trivially from project goals and critical
success factors
• Each critical success factor is usually a milestone
• But not limited to
• Milestones:
• Must be dated
• Dependencies must be clearly documented: What they depend on
and what depends on them
• Are they internal or external to the project?
17
Gantt
Chart
18
Phase 4: Roles
•Project team
• Team development and training
• Understand different people will play different roles
• Make this a strength, not a weakness
19
Responsibilities: Project Manager
•Develop project plan
•Recruit and manage project team
•Choose project management methodology
•Manage deliverables
•Assign tasks to team
•Provide updates to customer
20
Responsibilities: Lead Developer
•Manage specific project plan activities and
contributes to project plan development (with
project manager)
•Coordinate documentation, testing, and training
efforts related to project plan
•Act as ScrumMaster (if Agile adopted)
21
Responsibilities: Analyst
•Assist in defining the project
•Gather and document requirements
•Verify that project deliverables meet the
requirements
•Participate in testing
22
Phase 5: Quality
•How will you assure the quality of your project?
•A little effort in the planning phase could save a
lot of effort later
•Setting up quality requirements and defining
measures of success
23
Phase 6: Documentation
• During the project
• Customer correspondence (letters, written and verbal)
• Internal communication
• Agreed specification for the work (including all past versions)
• Issue log
• Activity log
• Finishing the project
• Technical documentation
• User documentation
24
Phase 7: Reporting
•The project plan should provide information on
how the project will be monitored including
• Regular progress reports to the customer
• Procedures for internal monitoring: Time spent, costs
incurred, issues and problems
25
Phase 8: Stakeholders
•Stakeholder: An individual or group who can have
an impact on or who will be affected by the project
•For each stakeholder, record:
• Who they are
• Their potential impact on the project
• What is expected from them: Their responsibility
• Perceived attitudes and risks
•A management strategy involving all stakeholders
26
Phase 9: Risk
• Condition (What?)
• Cause (How?)
• Consequence
• Likelihood (Low/High)
• Impact (Small/Large) - cost, time, quality
• Timescale (Quick/long term)
• Who is responsible for monitoring? (Early warning signs)
• What can be done to reduce risk occurrence?
• What can be done when it does happen?
27
Estimating Time
•Units of time must be relative to the task
•Underestimation: large tasks take lots of small
time units
vs
•Overestimation: small tasks do not always take a
large unit of time
28
Estimating Cost
• Hardware: Powerful and relatively cheap for most
applications
• Travel:
• Usually small fraction of costs
• Reduced by e-mail, telephone, videoconferencing, etc
• Training: Depends on how much is needed
• Software:
• Developer intensive
• High cost if longer project
29
Additional Material
•Planning Poker:
https://www.mountaingoatsoftware.com/agile/
planning-poker
•State of Agile: https://stateofagile.com/#ufh-i615706098-14th-annual-state-of-agilereport/7027494
30
COMP5590 – Week 22
Risk Management
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Outline
•Managing risk
• Critically assess risk for software products
• Compute and rank risk factors
•Case studies
Some of the materials are inspired by previous years' lectures
2
Risk
•Risk: Possibility of loss
•Loss:
• Not meeting a specified requirement
• Low quality of the end product
• Increased costs
• Delayed completion
• Failure to deliver
3
Managing Risk
•Dealing with risks
•Anticipate potential risks
•Evaluate/rank risks
•Incorporate risk mitigation into processes
4
Risk vs Opportunity
•Risk is not always bad (if controlled)
•Balance trade-offs: possible negative
consequences of risk against the potential
benefits of its associated opportunity
•Failure is often a key part of learning
5
Types of Risk
•Objective risk:
• Derived by science and statistics
• Depends on the accuracy of the models employed
•Subjective risk: as perceived by the general
public
6
Risk Attributes
•Description
•Probability of occurrence
•Severity (impact, consequences)
•Mitigation plan: <Actor, Action>
•Priority
7
Reasons for Failure
8
Sources of Risk: Design
•Erroneous, incomplete, or inconsistent
requirements
•Fundamental misconception or flaws in the design
or specification of either the hardware or software
•Analysis based on false assumptions about the
physical world, the operating environment, or
human behaviour
•Hidden dependencies
9
Sources of Risk: Development
• Errors in chip fabrication
• Program bugs
• Accidental or intentional use of malicious code
• Poor programming languages, faulty compilers and
debuggers, misleading development tools
• Incomplete testing, erroneous verification, mistakes in
debugging
• Introduction of new flaws in attempt to fix old flaws
10
Sources of Risk: Deployment
• Environmental factors
• Infrastructure factors: Loss of electrical power or air
conditioning
• Faulty maintenance after installation
• Software misbehaviour
• Human limitations in system use
• Unintentional misuse (errors)
• Intentional misuses (breaches, attacks)
11
Software Risk
12
Software Project Risk
•Defines operational, organisational, and contractual
software development parameters
•Primarily a management responsibility
•Includes constraints on resources, external
interfaces, supplier relationships, contract
restrictions
•Funding is the most significant project risk reported
13
Software Process Risk
•Includes both management and technical work
procedures
•Management procedures: Planning, staffing,
tracking, quality assurance and configuration
management
•Technical procedures: Development process requirements analysis, design, code and test
14
Software Product Risk
•Involves both intermediate and final work product
•Primarily a technical responsibility
•Requirements stability, design performance, code
complexity, and test specifications (acceptance)
•Requirements is the most significant product risk
15
Classification
•Any risk may fall in more than one category
•Categories help focus on where problems might
arise
•The cause may be in one category while the
impact is in several categories
16
Top Risks
•Personnel shortfalls
•Unrealistic schedules and budgets
•Developing wrong functions or user interfaces
•Continuing stream of requirements changes
•Shortfalls in external components and tasks
Barry W. Boehm
17
How to Compute Risk?
•An instance of risk is obtained by specifying values
for the risk attributes:
• Impact is the effect of an unsatisfactory outcome
• Likelihood is the probability that a consequence will occur
•Risk = Likelihood x Impact
or
•RE = P(UO) x L(UO)
18
Unsatisfactory Outcomes
•For customer and developers: Budget overruns
and schedule slips
•For users: Products with the wrong functionality,
user-interface shortfalls, performance shortfalls
or reliability shortfalls
•For maintainers: Poor-quality software
19
Risk Likelihood
20
Risk Impact
21
Risk Exposure
R3 > R2 > R1 > R4
22
Risk Analysis
•Risk assessment
• Identification
• Analysis
• Prioritisation
•Risk control
• Planning
• Resolution
• Monitoring
Software Risk Management: Principles and Practices. Barry W. Boehm - IEEE software, 1991
23
Risk Identification
•Identify risk and sources of risk
• Concerns
• Doubts
• Issues
• Uncertainties
24
Risk Analysis
•Analyse risk based on established criteria
•Estimate the probability
•Estimate the consequences of a risk
•Evaluate the risk with respect to other risks
25
Risk Prioritisation
•Produce a ranked ordering of the risk factors
that have been identified and analysed
•Team review for ranked risks
26
Risk Planning
•Plan the next task to resolve a risk
•Develop alternative strategies for risk resolution,
and define a risk action plan for the selected
approach
•Establish thresholds that help to determine
when to execute a risk action plan
27
Risk Resolution
•Respond to notification of triggering events
•Execute the risk action plan
•Report results of risk resolution efforts until the
level of risk is acceptable
28
Risk Monitoring
•Monitor planned thresholds and risk status
•Compare thresholds to status and determine
variances
•Use triggers to provide early warnings to
implement the risk action plan
29
Decision Trees
•Fundamental technique for risk analysis
•Provides individual solutions to risk
management situations
•Provides a framework for analysing the
sensitivity of the preferred solutions to the risk
exposure parameters
30
Example Scenario
•Satellite experiment program
• Strength: Team understands the experiment well
• Weakness: They are inexperienced and somewhat casual
about software development
•Platform manager estimates that the software will
have a critical error with P(UO) of 0.4
•Error will wipe out the entire experiment and cause
L(UO) of $20M investment
31
Potential Solutions
• Alternative 1: Convincing and helping the experiment
team to apply better software development methods
• No additional cost
• Reduce P(UO) to 0.1
• Alternative 2: Hiring an independent contractor to verify
and validate the software
• Additional cost: $500K
• Reduce P(UO) to 0.04
32
Decision
Tree
Software Risk Management: Principles
and Practices. Barry W. Boehm
IEEE Software, 1991
33
Controlling Risk
•Risk acceptance
•Risk prevention
•Risk mitigation
•Risk research
•Risk reserves
•Risk transfer
34
Risk Acceptance
•In an oil refinery the failure of a component is likely
to result in an explosion that could kill 100 people. It
is estimated that this component will fail once in
every 10000 years. What is the risk associated with
this component?
•Risk = Impact x Likelihood
= 100 x 0.0001
= 0.01 deaths per year
35
Severity for Military System
36
How to Decide?
• The level of risk might not be acceptable:
• E.g. hazard with catastrophic consequences that occur frequently
• The level of risk might be acceptable:
• E.g. hazard with negligible consequences that occurs frequently
• E.g. hazard with potentially critical or catastrophic consequences
is improbable
• The acceptability of a given risk is determined by
• The benefits associated with that risk
• The amount of effort that would be required to reduce it
37
Concorde: Was it an Acceptable Risk?
https://en.wikipedia.org/wiki/Concorde
38
Risk Assessment: Case Study I
•Taxi sharing app
https://bits.blogs.nytimes.com/2013/07/21/disruptions-upstarts-challenge-the-taxi-industry/
•Online banking
https://www.bbc.co.uk/news/business-35422587
39
Medical Software: Problems
•Risk of software failure might have serious
consequences in clinical environments
•Benefits to patient of using medical devices should
outweigh the risk of failure
•Important difference between safety and quality:
• Improved quality does not necessarily lead to improved safety
• Software may be correct, but not safe
• Software may be incorrect and unreliable, but still safe
40
Medical Software: Solutions
•Absolute safety is unattainable
•Tolerable risk
•Redundancy
• Sensors
• Software
•Training
41
Additional Material
•“Software Risk Management: Principles and
Practices” Barry W. Boehm - IEEE software, 1991
•“Project Risk Management: Processes, Techniques
and Insights” Chris Chapman, Stephen Ward – 2003
•Protection Poker: The New Software Security
“Game”
https://ieeexplore.ieee.org/document/5432145
42
COMP5590 – Week 23
Professional Issues
Dr Özgür Kafalı
Lecturer
R.O.Kafali@kent.ac.uk
Outline
•Computer Misuse Act
•Organisations
•Patents
•Ethical Software Development
•Data Protection Act
Some of the materials are inspired by previous years' lectures
2
What do Software Engineers Ignore?
•Software engineers focus on development
•Not so much on
• Security (unless it is a security-critical application)
• Data privacy
• Ethics
3
The Need for Law
•Accountability for actions
•Previous cases as precedence
4
Computer Misuse Act (CMA)
•In 1984, Gold and Schifreen successfully hacked into
BT, gaining unauthorised access to email accounts –
most importantly the Duke of Edinburgh's
•Initially convicted under the Forgery and
Counterfeiting Act 1981, but appealed successfully
•House of Lords decision in 1988: “The language of
the Act was not intended to apply to the situation
which was shown to exist in this case”
5
Implications
• Technical aspects of computing can have complex effects that
previous laws don’t take into account
• No hacking offense
• Security aspects of the system may be relevant
• The user name was 22222222
• The password was 1234
• Mixed aspects of hacking
• Good fun
• Serious disruption
• Malice
6
CMA Summary
•Three new criminal offences:
• Unauthorised access to computer material
• Unauthorised access to computer material with intent to
commit or facilitate commission of further offences
• Unauthorised acts with intent to impair operation of
computer
7
CMA - New Offences: Section 1
•Unauthorised access to computer material
• Described by the Act’s sponsor as “simple hacking” using a computer without permission. This carries a
penalty of up to two years in prison or a fine
• Involves causing a computer to perform some function.
But could be as little as guessing and using a password
8
CMA - New Offences: Section 2
•Unauthorised access to computer material with
intent to commit or facilitate commission of
further offences
•Covers actions such as attempting to use the
contents of an email message for blackmail. This
is a more serious offence, and the penalty is up
to five years imprisonment and an unlimited fine
9
CMA - New Offences: Section 3
•Unauthorised modification of computer material
• Covers distributing a computer virus, or malicious deletion of
files, & direct actions e.g. altering an account to obtain
fraudulent credit
• From 2006 Police & Justice Act, rephrased as: Unauthorised
acts with intent to impair operation of computer … as it was
up to then unclear whether denial-of-service was CMA
• The Act also includes the offences of conspiracy to commit
and incitement to commit the three main offences
10
CMA - New Offences: Section 3A
•Making, supplying or obtaining articles for the
three offences
• Computer viruses, worms, trojans, malware, malicious
scripts etc
• Carries maximum 2 years of prison and a fine
11
Sample Case
•Director of Public Prosecutions v Bignell (1997)
•Two police officers from the Metropolitan Police
• accessed the Police National Computer at an authorised level
• but, for an unauthorised purpose (details of the registration
and ownership of two motor cars)
• were not guilty of securing unauthorised access
• “Section 1 of the Computer Misuse Act 1990”
12
Updates
•Updated in relation to the Serious Crime Act
2015
•More serious punishments, e.g. life
imprisonment
13
Software Misuse and Cyber Crime
•Intellectual property
•Fraud: tampering with data integrity
•Criminal liability
•Deception
•Online harassment: cyber bullying
•Cyberterrorism: propaganda
•Illegal online markets
14
NCA
http://www.nationalcrimeagency.gov.uk/crime-threats/cyber-crime
15
Professional Organisations
•A governmental or government authorised
organisation
•Commonly driven by: Health and safety, societal &
business critical concerns
•In ICT, primarily associated with specific roles:
Consultants, public sector software engineers, those
working in “safety critical” work areas
16
British Computer Society (BCS)
•Aim: to maximise the benefits from IT
• Standards for IT professionals (accreditation, codes)
• Debate on IT strategic issues (government, industry,
academia)
• Advising the UK government
• Debate on IT topical issues
• Individuals for career development
• Networking
17
Certification
•Requirements:
• Minimally: Tests passed that guarantee a knowledge and skill
level
•Role-specific: Databases, computer forensics,
networking, information security, VoIP & telephony,
healthcare IT, cloud IT, mobile applications
•Platform-specific: Linux, Java, Microsoft, Apple
18
Patents
•“A patent may be understood as a monopoly
right over the commercial exploitation of an
invention, granted for a limited time (usually 20
years)”
T. Aplin & J. Davies – Intellectual Property Law (2013)
19
Rationale
•Rewarding the inventor
•Incentive function
• Promote industrial and technical progress: Important for
society as a whole
•Public benefits rationale
• Disclosure of invention helps dissemination of innovation
20
Patentability
•Patents Act 1977 – Patentable inventions
• The invention is new (novelty);
• It involves an inventive step;
• It is capable of industrial application.
21
Software Patent
•European Patent Office
•A computer-implemented invention is one
which involved the use of a computer, computer
network or other programmable apparatus,
where one or more features are realised wholly
or partly by means of a computer program
22
Patent Examples:
Amazon
•US5960411A
•Method and system
for placing a
purchase order via
a communications
network
23
Patent Examples:
Dropbox
•US8825597B1
•Network folder
synchronization
24
Patent Examples:
Google
•US6285999B1
•Method for
node ranking
in a linked
database
25
Ethics: Definitions
•Ethics:
http://rickhendershot.com/?p=1767
• Derived from the Greek word Ethos
• Branch of philosophy that involves systematizing, defending,
and recommending concepts of right and wrong conduct
•Morality:
• Derived from the Latin word Mores
• A system of rules for guiding human conduct, and principles
for evaluating those rules
26
Computer Ethics
•How does it all connect to computing?
•We use computers to help with our choices
•Computers make choices too
• Increasingly on their own due to new advances in
machine learning
• We do not necessarily know how they make those
choices
27
Software Engineering Code of Ethics
•IEEE-CS/ACM joint task force
•Software engineers shall commit themselves to
making the analysis, specification, design,
development, testing and maintenance of software
a beneficial and respected profession
•Commitment to the health, safety and welfare of
the public
https://www.computer.org/web/education/code-of-ethics
28
IEEE/ACM Principles
Public
Client and
Employer
Self
Colleagues
Code of
Ethics
Profession
Product
Judgment
Management
29
Principles - Public
• Approve software only if they have a well-founded belief that it
is safe, meets specifications, passes appropriate tests, and
does not diminish quality of life, diminish privacy or harm the
environment
• Disclose to appropriate persons or authorities any actual or
potential danger to the user, the public, or the environment
• Be fair and avoid deception in all statements, particularly
public ones, concerning software or related documents,
methods and tools
30
Principles – Client and Employer
•Not knowingly use software that is obtained or
retained either illegally or unethically
•Use the property of a client or employer only in
ways properly authorised, and with the client’s
or employer’s knowledge and consent
31
Principles - Management
•Attract potential software engineers only by full
and accurate description of the conditions of
employment
•Not ask a software engineer to do anything
inconsistent with the ethical code
32
Principles - Self
•Improve their ability to create safe, reliable, and
useful quality software at reasonable cost and
within a reasonable time
•Improve their ability to produce accurate,
informative, and well-written documentation
33
Software Engineering for Sustainability
https://www.gemalto.com/iot/inspired/smart-cities
The WEEE Man - http://www.weeeman.org
34
Volkswagen Emissions Scandal
https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal
35
Data Privacy
Laws: EU
• New General Data Protection Regulation (GDPR - May
2018) replaces EU Data Protection Directive 95/46/EC
(1998)
• Objective:
• Not only protect EU citizens’ sensitive data
• But also enable them to manage their data in a more controlled
way
https://eugdpr.org/
36
Data Privacy Laws: US
•Different approach
•No single regulation, but rather sector based
• Health Insurance Portability and Accountability Act (HIPAA)
• National Institute of Standards and Technology (NIST)
• Federal Trade Commission (FTC)
• Financial institutions (Gramm-Leach-Bliley Act)
• Federal agencies
https://www.hhs.gov/hipaa/index.html
37
Differences: US vs EU
•Breach notification
•Right to be forgotten
•Freedom of information request
•Protection of children’s data
38
Data Protection Act - 1998
•Regulates the “processing” of personal data
•Protects the rights of individuals whom the data
is about (data subjects), mainly by placing duties
on those who decide how and why such data is
processed (data controllers)
39
Terminology
• Data
• Personal data
• Sensitive personal data
• Processing
• Data subject
• Data controller
• Data processor
• Third party
https://ico.org.uk/for-organisations/data-protection-fee/legal-definitions-fees/
40
Data
•Information that is
• being processed by means of equipment operating
automatically in response to instructions given for that
purpose;
• recorded with the intention that it should be processed by
means of such equipment;
• recorded as part of a relevant filing system or with the
intention that it should form part of a relevant filing system.
41
Personal Data
•Data that relate to an individual who can be
identified
• from those data; or
• from those data and other information which is in the
possession of, or is likely to come into the possession of, the
data controller, and includes any expression of opinion about
the individual and any indication of the intentions of the data
controller or any other person in respect of the individual.
42
Sensitive Personal Data
• Consists of information (not limited to):
• racial or ethnic origin of the data subject;
• political opinions;
• religious beliefs or other beliefs of a similar nature;
• membership to a trade union within the meaning of the Trade Union and Labour
Relations (Consolidation) Act 1992;
• physical or mental health or condition;
• sexual life;
• commission or alleged commission of any offence; or
• any proceedings for any offence committed or alleged to have been committed,
the disposal of such proceedings or the sentence of any court in such
proceedings.
43
Processing
•Broadly means collecting, using, disclosing,
retaining or disposing of personal data
•Or, formally
•Obtaining, recording or holding the information
or data or carrying out any operation or set of
operations on the information or data
44
Actors
• Data subject means an individual who is the subject of personal data
• Data controller means a person who (either alone or jointly or in common
with other persons) determines the purposes for which and the manner in
which any personal data are, or are to be, processed
• Data processor, in relation to personal data, means any person (other than
an employee of the data controller) who processes the data on behalf of the
data controller
• Third party, in relation to personal data, means any person other than
• the data subject;
• the data controller; or
• any data processor or other person authorised to process data for the data controller or
processor.
45
Individual Rights
• Access to a copy of the information comprised
in their personal data
• Object to processing that is likely to cause or is
causing damage or distress
• Prevent processing for direct marketing
• Object to decisions being taken by automated
means
• In certain circumstances, have inaccurate
personal data rectified, blocked, erased or
destroyed
• Claim compensation for damages caused by a
breach of the Act
https://ico.org.uk/your-data-matters/
46
General Data Protection Regulation
•GDPR
• Agreed in 2016
• In effect from May 2018
•UK General Data Protection Regulation (UK
GDPR)
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/
47
GDPR Overview
•Every individual located within the EU must be
guaranteed the same rights and freedoms
•More focus on individual rights than the interests of
businesses
•Not only apply to organisations based within the EU,
but to any organisation that processes EU citizens’
data
48
GDPR Main Changes
•Increased territorial scope
•Penalties: Fined up to 4% of annual global turnover
or €20 Million
•Consent: Given in an intelligible and easily
accessible form, with the purpose for data
processing attached to that consent
•Data subject rights
https://eugdpr.org/the-regulation/
49
Case Study: Ticketmaster
• June 23 2018
• 40,000 customers hacked
• Their money stolen
• Their details turned up for sale
• Third-party supplier involved
• “Ticketmaster was only as secure as its weakest link”
• https://www.bbc.co.uk/news/technology-54931873
• https://www.ncsc.gov.uk/guidance/ncsc-advice-ticketmaster-customers
• https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2020/11/ico-finesticketmaster-uk-limited-125million-for-failing-to-protect-customers-payment-details/
50
Case Studies: British Airways
• 6 September 2018
• 380,000 booking transactions stolen (including credit card information)
• Impact: BA’s reputation, company shares, GDPR fines
• Mitigation: Banks issued replacements or warnings to their customers
• https://www.bbc.co.uk/news/technology-54568784
• https://www.britishairways.com/en-gb/information/incident/latest-information
• https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2020/10/ico-finesbritish-airways-20m-for-data-breach-affecting-more-than-400-000-customers/
• https://www.ncsc.gov.uk/news/ncsc-statement-reported-british-airways-data-breach
51
Additional Material
• CMA: https://www.cps.gov.uk/legal-guidance/computer-misuse
• IEEE/ACM Software Engineering Code of Ethics:
https://www.computer.org/web/education/code-of-ethics
• GDPR:
• https://eugdpr.org/
• https://www.nytimes.com/interactive/2016/01/29/technology/data-privacy-policy-useurope.html
• TED talks:
• https://www.ted.com/talks/tim_berners_lee_a_magna_carta_for_the_web#t-24904
• https://www.ted.com/talks/caleb_barlow_where_is_cybercrime_really_coming_from
52