Introduction to SEN4002

Software Design & Development

Dr. BASMASSI Mohamed Amine
Agenda
Introduction to SEN4002
• Module structure / content / learning outcomes
• Key information & Assessments

Software Engineering
• What is software engineering?
• The problem of complexity
• Methodologies
• Stages of Software Development Life Cycle

the Unified Modeling language

• Getting setup for the module
SEN4002 – Module Overview
Module aims
This module introduces students to software development lifecycle:
• Analyse and evaluate modern software development lifecycles.
• Demonstrate understanding of the software development lifecycle.
• Analyse and evaluate the main principles of software development
lifecycle, with a special focus on the identification and prevention of
different categories of software vulnerabilities.
• Discuss, design, and implement strategies for web and mobile
development.
• Demonstrate working as a team through developing their personal,
social, academic, reflective, and professional skills, productivity, and
ability to deal with complexity.
Assessments
• PRES1 - mid term Presentation : (30%) – Week 12
• The presentation assessment is designed
to assess students ability to propose and defend
their project ideas in a clear and concise manner.
Presentation practise will improve students.
• PORT1 end of term Portfolio : (70%) – Week 12
• The portfolio assessment is designed to assess students ability to
understand and apply the knowledge gained in this module.
Students ability to analyse, design, implement, test, and modify
their software security project will be demonstrated through
portfolio assessment.
Reference texts
• Stevens, P. (2005), Using UML: Software Engineering with Objects and
Components. 2nd Edition.
• Addison Wesley.
• Lethbridge, T. & Laganiere, R. (2005), Object-Oriented Software
Engineering: Practical Software
• Development using UML and Java. 2nd edition. McGraw-Hill Higher
Education.
Software Engineering
Defining Software Engineering
• Engineering: developing technology to solve some problem
• Not all software products are “Software Engineering” products
“software engineering is the process of solving customers’ problems by the
systematic development and evolution of large, high-quality software
systems within cost, time and other constraints.” – Lethbridge
“the systematic application of scientific and technological knowledge,
methods, and experience to the design, implementation, testing, and
documentation of software“ - IEEE Systems and software engineering
“The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software” - IEEE Standard
Glossary of Software Engineering Terminology
Why do we need systematic
Application of a formal, systematic, design process
engineering processes?
Why do we need systematic methods?

• Many reasons, but mainly:

Large problems are difficult to understand

• Human working memory is limited to 7 ± 2 items
• Anything more complex cannot be handled in memory
at once
Complexity introduces vulnerabilities
• As the number of
components grows, the
number of interfaces
explodes. (N(N-1)) / 2

• Each interface is a
potential point of
failure. Need to be
controlled.

What are the consequences of

these difficulties? Source: Cory R. A. Hallam , MIT ESD.83
 Software Crisis Summary of 2009 Standish Group CHAOS report

[Link]
 Software Crisis – Consequences
Loss of Life
Loss of money

The New York Times (1986)

[Link]
[Link]
The Guardian (2013)
[Link]
records-system-10bn
What are the causes for the Software Crisis?

Difficult to determine Intangible product:

the problem and Hard to visualise
requirements (client Hard to estimate the
might not know) required effort
Require improved
software
engineering
methods
Difficulty Difficult to test all the
communicating possible states and
abstract concepts interactions
Software Engineering
• 1960s – Complexity and importance of software growing.
Need to formalise processes.
• 1968 – NATO Science Committee held a conference on
Software Engineering – birth of the field.
• Discussions included:
• Problem of achieving reliability in the data systems
• Difficulties of meeting schedules and specifications on
large software projects
• Education of software
Dealing with Complexity
How do we manage the problem of complexity?
Multiple ways – Three general approaches:
(1) Abstraction
• Identify & focus on the essential details
(2) Decomposition
• Break problem down into manageable parts
(3) Hierarchical organisation
• Identify commonalities & relationships between
parts
 Abstraction & Decomposition
• Abstract the high-level structure
• Iterative decompose
(“Divide & Conquer”)
• Adds logical hierarchical structure to
the approach
• Makes solution more understandable
(easier to maintain)
• Makes solution modular and reusable
• Allows parallelisation
(implementation and computation)
Decomposition of complex problem
Systematic decomposition not necessary on small problems.
For large project, decomposition is vital! → Software Engineering

Problem: Design a system to land on the moon

Not something you can do by just sitting down and starting to program.
Decomposition of complex problem
The larger the project, the more useful decomposition becomes.
Problem: Design a system to land on the moon

TOP LEVEL DESCRIPTION

Abstract the key features and focus on

what rather than how.
Decomposition of complex problem
The larger the project, the more useful decomposition becomes.
Problem: Design a system to land on the moon
Decomposition of complex problem
The larger the project, the more useful decomposition becomes.
Problem: Design a system to land on the moon
Decomposition of complex problem
The larger the project, the more useful decomposition becomes.
Problem: Design a system to land on the moon
Decomposition of complex problem
The larger the project, the more useful decomposition becomes.
Problem: Design a system to land on the moon
Decomposition of complex problem
The larger the project, the more useful decomposition becomes.
Problem: Design a system to land on the moon

What systematic
approaches exist for
decomposition?
Approaches to decomposition
Functional decomposition vs Object-oriented decomposition
Functional Decomposition Object-Oriented Decomposition
The system is decomposed into The system is decomposed into
modules of related functions classes of objects
Emphasises the operations to be Emphasises the agents that cause
performed the operations
Useful for requirements Useful to design a system around a
engineering, for a high-level set of functional requirements
description of the system function

Source: Bruegge & Dutoit – Object-Oriented Software Engineering

Decomposing the
Software Development Processes
Systems Development Life Cycle (SDLC)

Waterfall Methodologies Iterative Methodologies

(e.g. Agile)
Source: Hoffer et al. (2014) Modern systems analysis and design
 Systems
Development
Life
Cycle (SDLC)

Waterfall Methodologies
Source: Shelly et al. (2003) Systems analysis and design
Process Stage Deliverable

Planning Preliminary
Investigation

Analysis Requirements

Design
Design Specification

Working System &

Implementation Maintenance Plan

Source: Dennis et al. (2001) Systems analysis and design

First stage: Planning
• Determine the business case: need, stakeholders, scope and constraints
• Analyse the feasibility
• Operational feasibility
Will the system be used effectively after it has been developed?
• Technical feasibility
Is it technically possible?
• Economic feasibility
What are the benefits vs. costs?
• Schedule feasibility
Can the project be completed in time?
• Perform a Risk Analysis
• Develop a work plan (economic costing and schedule)
Stakeholders in software engineering

Users Clients
• Software should enhance user • Paying for the software
experience • May or may not be users
• Should solve their problem

Stakeholders
in SE

Software developers Development managers

• Specialised roles within the • Managing software projects
team • Interact with the clients
Risk analysis in software engineering

Any software engineering project comes with risks

• Risks should be identified and managed

Risk registry
• Risk name, likelihood, impact and mitigation plans should be provided
• More effort should be allocated into tasks in the critical path

Risks should be regularly analysed during the project

• Risk owners should be assigned
• Regularly review risks and mitigation plans
Risk analysis in software engineering
Estimating cost & time
• Where most projects fail

Estimating the cost of the

system
• Study the scale of the problem
• Determine the effort required

Work planning

• Task allocation
• Setting up milestones and deliverables
Managing the process
Managing the process
Source: Shelly et al. (2003) Systems analysis and design
System Analysis

Domain analysis
• Understanding the background

Defining the problem

• Narrow down the scope of the system

Requirement gathering
• Collect ideas on what the system should do

Requirement analysis
• Come up with precise set of instructions on what the system should do
• How the software behaves, from the perspective of the user
• Separate ‘What’ from ‘How’
System Analysis: Requirements & specification
• Example listing of system requirements
System Analysis: Requirements & specification
• Example listing of system requirements
 Quality Requirements How easy it is for the users to
use the software?
User experience
Usability heuristics
Using components across
several different systems Usability Resource utilization,
Reduce long term costs energy/power consumption
(CPU time, memory usage, disk
usage)
Costs of running the software
Reusability Efficiency

Quality
attributes Fewer failures
Easily recoverable, easy to
Anticipate future changes, change
introduce flexibility Testing: Unit testing, integration,
Use of design patterns validation, stress testing; black
Maintain- box, white box testing
Reduces cost for developers and Reliability
ability
customers
Source: Shelly et al. (2003) Systems analysis and design
System Design
• Deciding how the requirements should be implemented

Hardware and software

• Deciding what requirements should be implemented on hardware, and what should be
implemented on software
Software architecture
• How the software is divided into sub-systems and how they interact
• Architectural design pattern

Design details
• Data structures, classes, algorithms procedures of each sub-system, data storage options

Look and feel

• User interface design
System Design: Modelling
• Creating a representation of the software

Structural modelling
• Represent classes, objects and entities in the software system

Behavioural modelling
• Represent states the system can be in, activities, interactions of the components

Visual representation
• Using diagrams

Mathematical representation
• Use of formal methods
Source: Shelly et al. (2003) Systems analysis and design
Implementation & Testing
• Translation of high-level designs to programming languages

Testing: Systematic execution of code to see if it behaves as

expected
• Verification: Making sure the requirements are met
• Validation: Determine whether the requirements identified will solve customer’s
problem
Deployment
• Distributing and installing the software
• Managing the transition from previous versions
Summary
Summary
• Software Engineering
• Definition: Use of systematic approaches to produce software
• Needed due to the Software Crisis
• Most software projects fail
• Increasing complexity of problems and systems
• Limit of human working memory 7 ± 2 items
• More parts brings increased interactions. Each is a point of failure
• Decomposition is a useful approach to dealing with complexity (Divide &
Conquer)
• Different approaches to decomposition:
• Functional decomposition
• Object-oriented decomposition
Summary
• Systems Development Life Cycle (SDLC)
• Decompose the systems development process
1. Planning Phase
• Business case
• Feasibility
• Risk
• Create a work plan & estimate
2. Systems Analysis Phase → Requirements
3. Systems Design Phase → Specification
4. Implementation Phase → Working system
Object concept ( Example JAVA)
Types of programming languages
Compiled languages:
Fast. Generate native machine code.
Disadvantage: Need to be optimised and compiled for each system.

Interpreted languages:
Slow. Interpreted at runtime. Instructions can be entered interactively without
compiling.

Source: Open University (2007) M257 Putting Java to work

Types of programming languages
Hybrid (i.e. Java):
• Compiled to an intermediate language (bytecode)
• Runs on the Java Virtual Machine (JVM)
• JVM compiled and optimised for different systems
• Highly portable – Write Once, Run / Debug Anywhere (WORA)

Source: Open University (2007) M257 Putting Java to work

Java: How it works

Source file Bytecode JVM

Compiler
• .java file • .class file • execution
Java example
• class
• Main method
• Variables
• Branches, loops