What is Software

Engineering?
Engineering approach to
develop software.

Building Construction Analogy.

Systematic collection of past

experience:
techniques,
methodologies,
guidelines.

Engineering Practice
Heavy use of past experience:
Past experience is systematically
arranged.

Theoretical basis and quantitative

techniques provided.
Tradeoff between alternatives
Pragmatic approach to costeffectiveness
2

Why To Study Software

Engineering? (1)

To acquire skills to develop large

programs.
Exponential growth in complexity and
difficulty level with size.
The ad hoc approach breaks down
when
size of software increases: --One
thorn of experience is worth a whole wilderness of
warning.
3

Why To Study Software

Engineering? (2)

Ability to solve complex

programming problems:
How to break large projects into
smaller and manageable parts?

Learn techniques of:

specification, design, interface
development, testing, project
management, etc.
4

Why Study Software Engineering?

(3)

To acquire skills to be a
better programmer:
Higher Productivity
Better Quality Programs

Software Crisis
Software products:

fail to meet user

requirements.
frequently crash.
expensive.
difficult to alter, debug, and
enhance.
often delivered late.
use resources non-optimally.
6

Factors contributing to the

software crisis

Larger problems,
Lack of adequate training in
software engineering,
Increasing skill shortage,
Low productivity
improvements.
7

Programs versus Software

Products
Usually small in size
Author himself is
sole user
Single developer
Lacks proper user
interface
Lacks proper
documentation
Ad hoc
development.

Large
Large number of
users
Team of developers
Well-designed
interface
Well documented &
user-manual
prepared
Systematic
development

Computer Systems
Engineering
Computer systems engineering:
encompasses software
engineering.

Many products require

development of software as well
as specific hardware to run it:
a coffee vending machine,
a mobile communication
product, etc.
9

Computer Systems
Engineering

The high-level problem:

deciding which tasks are to be
solved by software
which ones by hardware.

10

Computer Systems
Engineering
Often, hardware and software
are developed together:
(CONT.)

Hardware simulator is used during

software development.

Integration of hardware and

software.
Final system testing
11

Computer Systems
Engineering
(CONT.)

Feasibility
Study

Requirements
Analysisand
Specification
Hardware
Software
Partitioning

Hardware
Development
Software
Development

Integration
andTesting

ProjectManagement

12

Emergence of Software
Engineering

Early Computer Programming

(1950s):
Programs were being written in
assembly language.
Programs were limited to
about a few hundreds of lines
of assembly code.
13

Early Computer
Programming (50s)
Every programmer
developed his own style of
writing programs:
according to his intuition
(exploratory programming).

14

High-Level Language
Programming (Early 60s)

High-level languages such

as FORTRAN, ALGOL, and
COBOL were introduced:
This reduced software
development efforts greatly.

15

High-Level Language
Programming (Early 60s)

Software development
style was still exploratory.
Typical program sizes were
limited to a few thousands
of lines of source code.

16

Control Flow-Based Design

(late 60s)

Size and complexity of

programs increased further:
exploratory programming style
proved to be insufficient.

Programmers found:
very difficult to write costeffective and correct programs.
17

Control Flow-Based Design

(late 60s)

Programmers found:
programs written by others very
difficult to understand and maintain.

To cope up with this problem,

experienced programmers
advised: Pay particular attention to the
design of the program's control structure.

18

Control Flow-Based Design

(late 60s)

A program's control structure

indicates:
the sequence in which the program's
instructions are executed.

To help design programs having

good control structure:
flow charting technique was
developed.
19

Control Flow-Based Design

(Late 60s)

A program having a
messy flow chart
representation:
difficult to understand
and debug.
111

20

Control Flow-Based Design

(Late

60s)

It was found:

GO TO statements makes control

structure of a program messy
GO TO statements alter the flow
of control arbitrarily.
The need to restrict use of GO TO
statements was recognized.

21

Control Flow-Based Design

(Late

60s)

Many programmers had

extensively used assembly
languages.
JUMP instructions are frequently
used for program branching in
assembly languages,
programmers considered use of GO
TO statements inevitable.
22

Control-flow Based Design

(Late

60s)

At that time, Dijkstra

published his article:
Goto Statement Considered
Harmful Comm. of ACM, 1969.

Many programmers were

unhappy to read his article.
23

Control Flow-Based Design

(Late

60s)

They published several

counter articles:
highlighting the
advantages and
inevitability of GO TO
statements.
24

Control Flow-Based Design

(Late

60s)

But, soon it was conclusively proved:

only three programming constructs are
sufficient to express any programming
logic:
sequence (e.g. a=0;b=5;)
selection (e.g.if(c=true) k=5 else
m=5;)
iteration (e.g. while(k>0) k=j-k;)

25

Control-flow Based Design

(Late 60s)

Everyone accepted:

it is possible to solve any

programming problem without
using GO TO statements.
This formed the basis of
Structured Programming
methodology.
26

Structured Programming

A program is called structured

when it uses only the
following types of constructs:
sequence,
selection,
iteration

27

Structured programs

Unstructured control
flows are avoided.
Consist of a neat set of
modules.
Use single-entry, single-exit
program constructs.
28

Structured programs

However, violations to
this feature are permitted:
due to practical
considerations such as:
premature loop exit to
support exception handling.
29

Structured programs

Structured programs are:

Easier to read and
understand,
easier to maintain,
require less effort and time
for development.
30

Structured Programming
Research experience shows:
programmers commit less
number of errors

while using structured if-then-else

and do-while statements
compared to test-and-branch
constructs.

31

Data Structure-Oriented
Design (Early 70s)

Soon it was discovered:

it is important to pay more
attention to the design of
data structures of a program
than to the design of its
control structure.

32

Data Structure Oriented

Design (Early 70s)

Example of data structureoriented design technique:

Jackson's Structured
Programming(JSP)
methodology (Jackson in 1970s)
Warnier-Orr Technique

33

Data Flow-Oriented Design

(Late

70s)

Data flow-oriented
techniques advocate:

the data items input to a

system must first be identified,
processing required on the data
items to produce the required
outputs should be determined.
34

Data Flow-Oriented Design (Late

70s)

Data flow technique

identifies:
different processing stations
(functions) in a system
the items (data) that flow
between processing stations.
35

Data Flow-Oriented Design

70s)

(Late

Data flow technique is a

generic technique:
can be used to model the working of
any system
not just software systems.

A major advantage of the data

flow technique is its simplicity.
36

Data Flow Model of a Car

Assembly Unit
EngineStore

Fit
Engine

DoorStore
Chassiswith
Engine

ChassisStore

Fit
Doors

Partly
Assembled
Car

Fit
Wheels

Assembled
Car

Paintand
Test

Car

WheelStore

37

Object-Oriented Design

(80s)

Object-oriented technique:
an intuitively appealing design
approach:
natural objects (such as
employees, pay-roll-register,
etc.) occurring in a problem
are first identified.
38

Object-Oriented Design

(80s)

Relationships among objects:

such as composition, reference,
and inheritance are determined.

Each object essentially acts as

a data hiding (or data abstraction)
entity.

39

Object-Oriented Design

(80s)

Object-Oriented Techniques
have gained wide
acceptance:

Simplicity
Reuse possibilities
Lower development time and
cost
More robust code
Easy maintenance
40

Evolution of Design
Techniques
ObjectOriented

Dataflowbased
Datastructure
based
Controlflow
based
Adhoc

41

Evolution of Other Software

Engineering Techniques
The improvements to the
software design methodologies
are indeed very conspicuous.

In additions to the software

design techniques:
several other techniques evolved.

42

exploratory style Vs. modern software

development practices
Exploratory

Modern Software Practice

No Specific methodology

Specific Cycle Models to be followed

Error Correction was important

whenever it was found

Emphasis has shifted from error

correction to error prevention

Errors are detected during testing

only

Detect as many errors as possible

during each phase of development

Coding is synonymous with

program development

Coding is considered only a small

part of the program development
Attention is now on requirements
specification and distinct design
phase
Testing and review are now
systematic

Poor visibility. Very little attention

was being given to producing good
quality and consistent documents.

Better visibility. visibility means

production of good quality,
consistent and standard documents
fault diagnosis and maintenance
software project management, 43

Evolution of Other Software

Engineering Techniques
life cycle models,
specification techniques,
project management techniques,
testing techniques,
debugging techniques,
quality assurance techniques,
software measurement techniques,
CASE tools, etc.

44

Software Life Cycle

Software life cycle (or software process):
series of identifiable stages that a
software product undergoes during its life
time:
Feasibility study
requirements analysis and specification,
design,
coding,
testing
maintenance.

45

Life Cycle Model

A software life cycle model (or
process model):
a descriptive and diagrammatic model
of software life cycle:
identifies all the activities required for
product development,
establishes a precedence ordering among
the different activities,
Divides life cycle into phases.

46

Life Cycle Model

(CONT.)

Several different activities may

be carried out in each life
cycle phase.
For example, the design stage might
consist of:
structured analysis activity followed by
structured design activity.

47

Why Model Life Cycle ?

A written description:
forms a common understanding of
activities among the software
developers.
helps in identifying inconsistencies,
redundancies, and omissions in the
development process.
Helps in tailoring a process model for
specific projects.

48

Why Model Life Cycle ?

Processes are tailored for
special projects.
A documented process
model
helps to identify where the
tailoring is to occur.
49

Life Cycle Model

(CONT.)

The development team must

identify a suitable life cycle
model:
and then adhere to it.
Primary advantage of adhering to a
life cycle model:
helps development of software in a
systematic and disciplined manner.
50

Life Cycle Model

(CONT.)

When a program is
developed by a single
programmer -- he has the freedom to decide
his exact steps.

51

Life Cycle Model

(CONT.)

When a software product is

being developed by a team:
there must be a precise
understanding among team
members as to when to do what,
otherwise it would lead to chaos
and project failure.
52

Life Cycle Model

(CONT.)

A software project will never

succeed if:

one engineer starts writing code,

another concentrates on writing the
test document first,
yet another engineer first defines the
file structure
another defines the I/O for his portion
first.
53

Life Cycle Model

(CONT.)

A life cycle model:

defines entry and exit criteria

for every phase.
A phase is considered to be
complete:

only when all its exit criteria are

satisfied.
54

Life Cycle Model

(CONT.)

The phase exit criteria for the software

requirements specification phase:
Software Requirements Specification (SRS)
document is complete, reviewed, and
approved by the customer.

A phase can start:

only if its phase-entry criteria have been
satisfied.

55

Life Cycle Model

(CONT.)

It becomes easier for

software project managers:
to monitor the progress of the
project.

56

Life Cycle Model

(CONT.)

When a life cycle model is adhered to,

the project manager can at any time fairly
accurately tell,
at which stage (e.g., design, code, test, etc. )
of the project is.

Otherwise, it becomes very difficult to

track the progress of the project
the project manager would have to depend
on the guesses of the team members.

57

Life Cycle Model

(CONT.)

This usually leads to a

problem:
known as the 99% complete
syndrome.

58

Life Cycle Model

(CONT.)

Many life cycle models have been

proposed.
We will confine our attention to a few
important and commonly used models.
classical waterfall model
iterative waterfall,
evolutionary,
prototyping, and
spiral model
59

Summary
Software engineering is:
systematic collection of
decades of programming
experience
together with the innovations
made by researchers.
60

Summary
A fundamental necessity
while developing any large
software product:
adoption of a life cycle
model.

61