SOFTWARE

ENGINEERING - I

Lecture 1

Session outcomes

Introduction to Module

SE- Introduction

SE Process - Introduction

SLIIT 2

MODULE

INTRODUCTION

SLIIT 3

Module contents

Course web

General

Module outline

Notices

Marks

Weekly updates

Lecture

Lab

Tutorial

Additional Reading

SLIIT 4

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 5

Assessment Criteria

Mid-term (1 hour duration) - 20%

Assignment - 10%

Final Examination

(3 hours duration) - 70%To pass this module, students need to obtain

a pass mark continuous assessments and

a pass mark in their end semesterexamination and

achieve an overall mark that would qualifyfor a C grade or above.

SLIIT 6

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 7

Lab Schedule

SLIIT 8

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

SE- INTRODUCTION

SLIIT 9

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

SLIIT 10

What is Software?

S/W is not just the programs, but also associateddocumentation and configuration data (to operatethe program) needed to make the programsoperate 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 11

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 12

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 13

What is Software Engineering?

Software engineering is an engineering discipline,concerned with all aspects of software productionfrom early stages of system specification throughmaintaining the system.

engineering discipline make things work by applyingtheories, methods and tools where appropriate and alsotry to find solutions to problems when theres nosuitable 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 14

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 15

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 16

What are things that you need to do

to develop Software?

SLIIT 17

Developing a Program

Analyze the problem

Develop a solution

Code the solution

Test and Debug

SLIIT 18

What about a Real Software?

There will be a real user (Customer) who would

need to use the software.

1. 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.

SLIIT 19

Characteristics of Software

EngineeringSoftware Engineering deals with team-basedproduction 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 20

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 21

Evolution of Technology with Time

SLIIT 22

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 23

Computer Systems Engineering

contd.

SLIIT 24

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 25

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 26

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.

SLIIT 27

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 28

Scale (When you move to larger

projects)

Complexity Increases

Work in Larger Teams

Quality of Software becomes more important

because of real users.

SLIIT 29

Relative cost of Hardware & Software

SLIIT 30

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 31

Evolution of Software Development

Techniques

SLIIT 32

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 33

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 34

Modern SE Techniques The Software Life CycleA 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 35

Modern SE Techniques The Software Life CycleEmphasis 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 36

SE PROCESS MODELS

INTRODUCTION

SLIIT 37

What is a Software Process?

A Software Process is a set of Activities and

Associated Results that produce a Software.

SLIIT 38

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 39

Biscuit Manufacturing Process

SLIIT 40

Fundamental Process Activities

Software Specification

Software Development

Software Validation

Software Evolution

SLIIT 41

Software Process Model

A Software Process Model is a simplified

description of a Software Process and represents

one view of that process.

SLIIT 42

General Software Process Models

Waterfall Model Classic

Waterfall Model Iterative

Prototyping

Evolutionary Model

Incremental

Spiral

SLIIT 43

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 44

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 45

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 46

Software Development

MethodologiesThe 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 47

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 48

WATERFALL LIFE

CYCLE MODELS

SLIIT 49

Classical Waterfall Model

A cascade of phases

SLIIT 50

Feasibility Study:

Aims :

To determine whether the project is financially

worthwhile and technically feasible.

1. Gain the basic understanding of the problem.

2. Formulate alternative solution strategies.

3. Evaluate solution strategies in terms of: Estimated technical difficulty

Estimated resources

Estimated development effort

Estimated development time & cost

SLIIT 51

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 52

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 53

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 54

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 55

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 56

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 57

Example Methodology -

Structured AnalysisStructured 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 58

Example Methodology -

Structured DesignStructured 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 59

The Implementation PhaseThis 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 60

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 61

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 62

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 63

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 64

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;

SLIIT 65

Next Lecture

Process Models Contd.

SLIIT 66