SOFTWARE

ENGINEERING - I
Lecture 1

SLIIT

Session outcomes

Introduction to Module

SE- Introduction
SE Process - Introduction

SLIIT

MODULE
INTRODUCTION

SLIIT

Module contents
Course web
General
Module outline
Notices
Marks
Weekly updates
Lecture
Lab
Tutorial
Additional Reading

SLIIT

Learning outcomes
Understand what software engineering is and relate it to other disciplines.

Understand the lifecycle of software development past and present.

Compare the lifecycle models and be able to choose the best model for a given

scenario.
Describe the requirement engineering process and to write a formal requirements
document for a software project.
Use UML such as Use Case Diagrams and Use Case Scenarios to capture
requirements of a System.
Demonstrate how requirements gathering can be carried out accurately and
consistently making use of structured analysis using data flow diagrams.
Design an appropriate set of modules from a structured analysis, and communicate
them in the form of a structure chart.
Use a dictionary-based CASE tool (e.g. WinA&D).
Describe and compare different testing strategies used in software development.
Develop an understanding of project management and to apply the project
management concepts in software development.
Compare and contrast different modern software development methodologies.

SLIIT

Assessment Criteria
Mid-term (1 hour duration)
Assignment
Final Examination
(3 hours duration)

- 20%
- 10%
- 70%

To pass this module, students need to obtain

a pass mark continuous assessments and
a pass mark in their end semester
examination and
achieve an overall mark that would qualify
for a C grade or above.

SLIIT

Assignment
Pair wise assessment
Randomly chosen case study

Two submissions
Before Mid term
Based on requirements engineering and use

case diagrams
After Mid term
Based on DFD and Structure charts

SLIIT

Lab Schedule
Time

Lessons

Labs

Week 1

Introduction & Life Cycle Modelling

PS

Week 2

Life Cycle Modelling

PS

Week 3

Requirements Engineering Decision Trees, Tables

PS

Week 4

Requirements Engineering Use Case

SE lab 1 (Decision
tables)

Week 5

Requirements Engineering Use Case

SE lab 2 (Use case)

Week 6

Structured Analysis and Design

SE lab 3 (Use case,DFD)

Week 7

Mid-Term Examination

Week 8

Structured Analysis and Design

PS

Week 9

Structured Analysis and Design

PS

Week10

Implementation and Testing

PS

Week 11

Project Management

SE lab 3 (DFD)

Week 12

Modern Software Development Methodologies

SE lab 4 (Struc. Charts)

Week 13

Revision

SE lab 5 ( PM )

Final Exam

SLIIT

SE- INTRODUCTION

SLIIT

Organization of the Lecture

What is Software Engineering?
Background to this Unit
How Software Engineering started?

Why is Software Engineering Important?

Software Development Life Cycles

10

SLIIT

11

What is Software?
S/W is not just the programs, but also associated

documentation and configuration data (to operate

the program) needed to make the programs
operate correctly.
A S/W system consists of
Number of separate programs
Configuration files used to setup the programs
System documentation describes the structure of the
system
User documentation explains how to use the system

SLIIT

12

Software Products may be

Generic
Developed to be sold to a range of different customers
E.g.
Operating Systems(Microsoft Windows)
Database Management Systems(Oracle)
Banking Software
Bespoke
Developed for a single customer according to their specification

SLIIT

13

Programs Vs Software Products

Program
Small
Single developer

Small in size
Limited Functionality
Single user (author)
Simple user interface

Sparse documentation
No user manual
Ad hoc development

Software Product

Large
Team of developers
Multiple users
(customer)
Complex user interfaces
Detailed documentation
User manual
Systematic development

SLIIT

14

What is Software Engineering?

Software engineering is an engineering discipline,

concerned with all aspects of software production

from early stages of system specification through
maintaining the system.
engineering discipline make things work by applying

theories, methods and tools where appropriate and also

try to find solutions to problems when theres no
suitable theories/methods.
all aspects of software production not just technical,

but project management and development of tools,

methods and theories to support S/W production.

SLIIT

15

What is Software Engineering? contd.

Software engineers should adopt a systematic

and organized approach to their work and use

appropriate tools and techniques depending on
the problem to be solved, the development
constraints and the resources available.

SLIIT

16

Software Engineering
IEEE Definition of Software Engineering:

The application of a systematic, disciplined, quantifiable

approach to the development, operation, and
maintenance of software;
that is, the application of engineering to software.

IEEE Standard 610.12-1990, 1993.

SLIIT

17

What are things that you need to do

to develop Software?

SLIIT

Developing a Program
Analyze the problem
Develop a solution
Code the solution

Test and Debug

18

SLIIT

19

What about a Real Software?

There will be a real user (Customer) who would

need to use the software.

You have to find out what the customer wants
(Requirements Gathering)
2. Analyze the problem
3. Develop a solution (Design)
4. Code the solution
5. Test and Debug
6. Maintenance
Note : In addition in the beginning there can be a
Feasibility Study.
1.

SLIIT

20

Characteristics of Software
Engineering
Software Engineering deals with team-based

production of large software systems:

no single person has complete knowledge of all the

details of a software engineering project.

Software Engineering borrows from:
Computer Science & Information Technology
Electrical & Computer Engineering
Mathematics & Physics
Business & Management
Psychology & Sociology

SLIIT

21

Characteristics of Software Engineering

contd.
Modern engineering is based on the systematic

collection of past experience:

methodologies; techniques; guidelines.

It involves tradeoffs between alternatives:

a pragmatic approach to cost-effectiveness;
a rigorous approach to quality and safety!
It uses a variety of quantitative techniques
with a sound theoretical basis:
yet many SE techniques are just rules of thumb

SLIIT

22

Evolution of Technology with Time

SLIIT

23

Computer Systems Engineering

Computer systems engineering is concerned with

developing both hardware and software:

hence it encompasses software engineering.

Many products require simultaneous development

of hardware and software:

IBM System/360 see Brooks (1995)
vending machines

mobile phones
games consoles

SLIIT

Computer Systems Engineering

contd.

24

SLIIT

25

Software Engineering why bother?

To solve LARGE and/or COMPLEX problems

using modern computer technology:

there is an exponential growth in complexity, and hence

difficulty, with software size;

the ad hoc approach breaks down VERY quickly as
software size increases.
Software engineers break large projects into

smaller, more manageable parts

which can be delivered within a short time.

SLIIT

26

Software Engineering why bother?

Contd.
To acquire the skills necessary to be a better

software developer:
higher productivity;
lower cost;
better quality.

Knowledge of SE is essential when using

languages like C++ or Java to solve real

problems:
first year programming exercises are trivial

SLIIT

The Software crisis

Typically, software products:
are expensive to develop, e.g. Win2000;
are difficult to debug, e.g. WinNT3;
are usually delivered late, e.g. Win2000;
fail to meet user requirements, e.g. MS Word;
crash frequently, e.g. Win95, Win98, WinNT4;
are difficult to maintain, e.g. WinNT4 SP6;
use resources non-optimally, etc, etc, etc.

27

SLIIT

28

Quality of Software
Depending on the type of software project the

qualities of software would be different.

e.g. Most systems should be reliable, functional

Some systems should be more reliable

e.g. Software running on the Space Shuttle

SLIIT

29

Scale (When you move to larger

projects)
Complexity Increases

Work in Larger Teams

Quality of Software becomes more important

because of real users.

SLIIT

30

Relative cost of Hardware & Software

SLIIT

31

Software Engineering History

1950s: Early Programming
Early 1960s: High Level languages and Control flow design
Late 1960s: The demise of GOTO and Structured

programming
Early 1970s: Data Structure Design
Late 1970s: Structured Analysis

1980s:Object Oriented Design

SLIIT

Evolution of Software Development

Techniques

32

SLIIT

33

Modern SE Techniques
In addition to software design, many other SE

techniques have evolved:

analysis & specification techniques;
debugging & testing techniques;
software metrics (used to measure SE);
software project management;
software quality assurance;

CASE tools (used to automate SE).

Most of the above are examined in this unit.

SLIIT

34

Modern SE Techniques contd.

Modern software is developed in well-defined

phases
There is a lot of emphasis on requirements

analysis and specification.

There is a distinct design phase.

Coding is only a small part of modern

software development.
There is a distinct, systematic testing phase.

SLIIT

35

Modern SE Techniques
The Software Life Cycle
A series of phases through which a software

product passes during its lifetime, such as:

Feasibility Study;
Requirements Analysis & Specification;

Design;
Implementation (coding);
Testing;
Maintenance.

Many different activities may be carried out in

each phase.

SLIIT

36

Modern SE Techniques
The Software Life Cycle
Emphasis has shifted from error correction to

error prevention:
exploratory methods focused on detecting errors only

during testing;
modern methods focus on detecting errors in each
phase of development.
Phase containment: detect errors as close as

possible to their point of introduction Reduces the amount of work that must be re-done.

Software are developed using a well defined

Process.

SLIIT

37

SE PROCESS MODELS
INTRODUCTION

SLIIT

38

What is a Software Process?

A Software Process is a set of Activities and

Associated Results that produce a Software.

SLIIT

39

Software Processes
Different types of projects would require different

types of Software Processes.

A real time system in a plane would need to be fully specified.
In an E-Commerce system the specification and the program are

developed together.

SLIIT

Biscuit Manufacturing Process

40

SLIIT

Fundamental Process Activities

Software Specification
Software Development
Software Validation

Software Evolution

41

SLIIT

42

Software Process Model

A Software Process Model is a simplified

description of a Software Process and represents

one view of that process.

SLIIT

43

General Software Process Models

Waterfall Model Classic
Waterfall Model Iterative
Prototyping
Evolutionary Model
Incremental
Spiral

SLIIT

44

Life Cycle (Process) Model

A life cycle is a series of phases (steps) that

software passes through during its lifetime.

A life cycle (process) model defines entry and exit

criteria for every phase:

a phase only begins when all of its entry criteria are met;
a phase only ends when all of its exit criteria are met;
the entry and exit criteria make it easier to monitor the

progress of a project through the different phases.

Example exit criteria for the coding phase:
each module has been tested and documented.

SLIIT

45

Life Cycle (Process) Models Contd.

A program is developed by a single programmer

who is free to make decisions.

A software product is developed by a team of
software engineers:
there must be agreement between team members

about what to do when;

communication is essential breakdown will quickly
lead to chaos and project failure.
A software development team must identify a

suitable life cycle model and stick to it!

SLIIT

46

Life Cycle (Process) Models Contd.

A software life cycle (process) model:
is a descriptive and diagrammatic model of the life cycle
of a software product;
identifies all the activities and phases necessary for
software development;
establishes a precedence ordering among the different
activities.
Life cycle models encourage systematic and

disciplined software development.

SLIIT

47

Software Development
Methodologies
The processes, standards and guidelines used by

an organization form a Software Development

Methodology:
organizations expect their software engineers to master the in-

house methodology;
this means YOU!

In modern software engineering, the software

process is just as important as the product!

if you get the development process right, the software product

should take care of itself!

SLIIT

48

Classical Waterfall Model

The classical waterfall model divides the software

life cycle into six phases:

Feasibility Study
Requirements Analysis & Specification

Design
Implementation (Coding) & Unit Testing
Integration & System Testing
Maintenance

Also called the Linear Sequential Model...

SLIIT

49

WATERFALL LIFE
CYCLE MODELS

SLIIT

Classical Waterfall Model

A cascade of phases

50

SLIIT

51

Feasibility Study:
Aims :
To determine whether the project is financially

worthwhile and technically feasible.

1.
2.
3.

Gain the basic understanding of the problem.

Formulate alternative solution strategies.
Evaluate solution strategies in terms of:

Estimated technical difficulty

Estimated resources
Estimated development effort
Estimated development time & cost

SLIIT

52

Feasibility Study
A Cost/Benefit Analysis can be used to decide

which solutions are feasible:

i.e. does the benefit outweigh the cost? Should reveal

which solution is the best;

However, it may be that none of the solutions is

feasible due to
Resource Limitations
Technical Difficulty
High Cost
Long Development Time (e.g. for a Y2K fix)

SLIIT

53

The Requirements Phase

Aim: to document the customer requirements:
i.e. the PROBLEM!
A customer may be a single person, a group, a

department, or an entire organization:

often with many employees (potential users).

This phase involves two distinct activities:

Requirements Gathering and Analysis
Requirements Specification

SLIIT

54

Requirements Gathering and Analysis

Gather Information via meetings, interviews and

discussions:
this information is typically inadequate at first each

user has only a partial view of the system.

Identify and eliminate errors
Inconsistency (Contradictions)
Vagueness (Ambiguities)
Incompleteness (Omissions)
Clarification involves further gathering and

analysis of information.

SLIIT

55

Requirements Gathering and Analysis

Aim:
To understand exactly what the customer needs..

which may not be what they ask for:

data to be input to the system;

processing to be performed on these data;
data to be output from the system;
characteristics of the system as a whole;
constraints on the system/project.

WHAT, not HOW!

SLIIT

56

Requirements Specification
Requirements are documented in a Software

Requirements Specification (SRS).

The SRS document forms the basis of a legal

contract with the customer:

Customer approval of the SRS document typically

marks the end of the requirements phase.

Software Engineers who specialize in

requirements gathering, analysis, and

specification are called (Systems) Analysts.

SLIIT

57

The Design Phase

Aim:
To transform the specification into a form suitable

for implementation in a programming language

Design is a creative activity so its hard!
The software design is derived from the SRS

document using one of two approaches:

Function Oriented Methods (SE I) - e.g. Structured

Analysis & Design (SA/SD)

Object Oriented Methods (SE II)

SLIIT

58

Example Methodology Structured Analysis

Structured Analysis is carried out using Data Flow

Diagrams (DFDs)
1.

Identify the major tasks (processes) to be performed

by the system

2.

Identify all data flows into or out of these tasks

3.

Recursively decompose each task into sub-tasks and

identify all data flows between the sub-tasks

4.

Stop at the algorithm level i.e. when each task can

be represented by 1/2 page of pseudo-code

SLIIT

59

Example Methodology Structured Design

Structured design follows on from structured

analysis; it is done at two complexity levels...

Architectural (or High-Level) Design:

Decompose the system into modules

Identify relationships between the modules
Detailed (or Low-Level) Design:

Design data structures and algorithms for each

module (i.e. produce mini-specs).

SLIIT

60

The Implementation Phase

This is the coding and unit testing phase.
Each module is implemented independently, as a

stand alone unit:

Translation into source code and
documentation
Unit Testing and Debugging
Unit Testing ensures that each module works

correctly in isolation.
The end product of this phase is a set of

independently tested software modules....

SLIIT

61

The Testing Phase-Integration Testing

Aim:
To integrate modules in a series of carefully

planned steps.
Integrating modules one at a time makes error
location and correction much easier:
it would be foolish to integrate several different modules

at the same time

big bang!
At the end of each step the incomplete system is

re-tested using ALL of the test data.

SLIIT

62

The Testing Phase - System Testing

Aim:
To ensure that the system meets the

requirements in the SRS document.

System testing takes place after all the modules

have been integrated:

Alpha & Beta Testing
Stress & Acceptance Testing

The system is delivered to the customer at the

end of this phase:

you get paid, and maintenance begins.

SLIIT

63

Maintenance -Three broad Categories

Corrective Maintenance
To eliminate errors that were not discovered during
system development
Perfective Maintenance
To improve the existing system e.g. by optimizing the
implementation or enhancing the functionality
Adaptive Maintenance
To modify the system for a new or changing
environment e.g. a new hardware device, operating
system, or tax law.

SLIIT

64

Problem of Classical Waterfall Model

The classical waterfall model is idealistic:
It assumes that no defects are introduced during any of
the development phases.
In practice, defects are introduced during every

phase of the software life cycle:

Hence feedback paths must be added to the classical

waterfall model.
The resulting Iterative Waterfall Model is one of

the most widely used process models.

SLIIT

References
Essential Reading:
Fundamentals of Software Engineering
by Rajib Mall - Chapter 1 & 2
Software Engineering

by Sommerville Chapter 1 & 4

SLIIT Text Book Chapter 2
Background Reading:
Software Engineering, a practitioners approach

by Roger S Pressman Chapter 1 and 2

Pfleeger Chapter 1;

65

SLIIT

Next Lecture

Process Models Contd.

66