INTRODUCTION TO

SOFTWARE ENGINEERING
ORGANIZATION OF THIS LECTURE
What is Software Engineering?
Programs vs. Software Products
Evolution of Software Engineering
Notable Changes In Software Development
Practices
Introduction to Life Cycle Models
Summary
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.
Many are just thumb rules.
Tradeoff between alternatives.
Pragmatic approach to cost-effectiveness.
TECHNOLOGY DEVELOPMENT
PATTERN
Engineering
Esoteric Past
Experience
Technology

Craft Systematic Use of Past

Experience and Scientific Basis

Unorganized Use of
Art Past Experience

Time
 EVOLUTION OF AN ART INTO AN
ENGINEERING DISCIPLINE
The early programmers used an exploratory (also
called build and fix) style.
In the build and fix (exploratory) style, normally a
`dirty' program is quickly developed.
The different imperfections that are subsequently
noticed are fixed.
WHAT IS WRONG WITH THE
EXPLORATORY STYLE?
Can successfully be used for very small programs only.
Software
Exploratory Engineering
time, cost
Effort,

Machine

Program Size
 WHAT IS WRONG WITH THE
EXPLORATORY STYLE? CONT…
Besides the exponential growth of effort, cost, and
time with problem size:
Exploratory style usually results in unmaintainable code.
It becomes very difficult to use the exploratory style in
a team development environment.
WHAT IS WRONG WITH THE
EXPLORATORY STYLE? CONT…

Why does the effort required to

develop a product grow exponentially
with product size?
Why does the approach completely
breaks down when the product size
becomes large?
 AN INTERPRETATION BASED ON HUMAN
COGNITION MECHANISM
Human memory can be thought to be made up of two distinct
parts [Miller 56]:
Short term memory and
Long term memory.
If you are asked the question: ``If it is 10AM now, how many
hours are remaining today?"
First, 10AM would be stored in the short-term memory.
Next, a day is 24 hours long would be fetched from the long term
memory into short term memory.
Finally, the mental manipulation unit would compute the difference
(24-10).
HUMAN COGNITION
MECHANISM
Short Term Memory

Processing Center

Long Term Memory

Brain
 SHORT TERM MEMORY
An item stored in the short term memory can get lost:
Either due to decay with time or
Displacement by newer information.
This restricts the time for which an item is stored in short term memory to few tens of
seconds.
However, an item can be retained longer in the short term memory by recycling.
 WHAT IS AN ITEM?
An item is any set of related information.
A character such as `a' or a digit such as `5' can be items.
A word, a sentence, a story, or even a picture can each be a single item.
Each item normally occupies one place in memory.
When you are able to relate several different items together
(chunking):
The information that should normally occupy several places can be stored
using only one place in the memory.
 CHUNKING
If you are given the binary number
110010101001
It may prove very hard for you to understand and
remember.
But, the octal form of 6251 (i.e. (110)(010)(101)(001))
would be easier.
You have managed to create chunks of three items
each.
 EVIDENCE OF SHORT TERM
MEMORY
Short term memory is evident:
In many of our day-to-day experiences.
Suppose, you look up a number from the telephone directory
and start dialling it.
If you find the number to be busy, you can dial the number again after a
few seconds almost effortlessly without having to look up the directory.
But, after several days:
You may not remember the number at all, and would need to consult the
directory again.
 THE MAGICAL NUMBER 7
If a person deals with seven or less number items:
These would be easily be accommodated in the short
term memory.
So, he can easily understand it.
As the number of new information increases
beyond seven,
It becomes exceedingly difficult to understand it.
 IMPLICATION IN PROGRAM
DEVELOPMENT
A small program having just a few variables:
Is within the easy grasp of an individual.
As the number of independent variables in the
program increases:
It quickly exceeds the grasping power of an individual:
Requires an unduly large effort to master the problem.
 IMPLICATION IN PROGRAM
DEVELOPMENT
Instead of a human, if a machine could be writing (generating) a program,
The slope of the curve would be linear.

But, why does the effort-size curve become almost linear when software
engineering principles are deployed?
Software engineering principles extensively use techniques specifically to overcome the human cognitive
limitations.
PRINCIPLES DEPLOYED BY SOFTWARE
ENGINEERING TO OVERCOME HUMAN
COGNITIVE LIMITATIONS
Mainly two important principles are
deployed:
Abstraction
Decomposition
 ABSTRACTION
Simplify a problem by omitting unnecessary details.
Focus attention on only one aspect of the problem and ignore irrelevant
details.
Suppose you are asked to develop an overall understanding of
some country.
No one in his right mind would meet all the citizens of the country, visit
every house, and examine every tree of the country, etc.
You would possibly refer to various types of maps for that country.
A map, in fact, is an abstract representation of a country.
 DECOMPOSITION
Decompose a problem into many small
independent parts.
The small parts are then taken up one by one and
solved separately.
The idea is that each small part would be easy to
grasp and can be easily solved.
The full problem is solved when all the parts are
solved.
 DECOMPOSITION
A popular way to demonstrate the decomposition
principle:
Try to break a bunch of sticks tied together versus
breaking them individually.
Example use of decomposition principle:
You understand a book better when the contents are
organized into independent chapters
Compared to when everything is mixed up.
WHY 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.
WHY STUDY SOFTWARE
ENGINEERING? (2)
Ability to solve complex programming
problems:
How to break large projects into smaller and
manageable parts?
How to use abstraction?
Also learn techniques of:
Specification, design, user interface
development, testing, project management, etc.
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.
SOFTWARE CRISIS (CONT.)

Hw cost
Sw cost

1960 Year
2008

Relative Cost of Hardware and Software

FACTORS CONTRIBUTING TO THE
SOFTWARE CRISIS
Larger problems,
Lack of adequate training in software
engineering,
Increasing skill shortage,
Low productivity improvements.
PROGRAMS VERSUS SOFTWARE
PRODUCTS
Usually small in size Large
Author himself is sole user Large number of users
Single developer Team of developers
Lacks proper user interface Well-designed interface
Well documented &
Lacks proper documentation
user-manual prepared
Ad hoc development. Systematic development
 TYPES OF SOFTWARE
PROJECTS
Software products
Outsourced projects
Indian companies have focused on
outsourced projects.
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.
COMPUTER SYSTEMS
ENGINEERING

The high-level problem:

Deciding which tasks are to be solved by
software.
Which ones by hardware.
COMPUTER SYSTEMS ENGINEERING
(CONT.)

Often, hardware and software are

developed together:
Hardware simulator is used during software
development.
Integration of hardware and software.
Final system testing
COMPUTER SYSTEMS ENGINEERING
(CONT.)

Feasibility
Study

Requirements
Analysis and
Specification
Hardware
Development
Hardware
Software
Partitioning Software
Development Integration
and Testing

Project Management
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.
EARLY COMPUTER
PROGRAMMING (50S)
Every programmer developed his
own style of writing programs:
According to his intuition (exploratory
programming).
 HIGH-LEVEL LANGUAGE
PROGRAMMING (EARLY 60S)
● High-level languages such as FORTRAN,
ALGOL, and COBOL were introduced:
– This reduced software
development efforts greatly.
 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.
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 cost-effective and
correct programs.
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.'’
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.
CONTROL FLOW-BASED DESIGN (LATE 60S)
Using flow charting technique:
One can represent and design a program's
control structure.
Usually one understands a program:
By mentally simulating the program's
execution sequence.
CONTROL FLOW-BASED DESIGN
(LATE 60S)

A program having a messy flow

chart representation:
Difficult to understand and debug.
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.
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.
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.
CONTROL FLOW-BASED DESIGN (LATE 60S)

They published several counter

articles:
Highlighting the advantages and
inevitability of GO TO statements.
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;)
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.
STRUCTURED PROGRAMMING
A program is called structured
When it uses only the following types
of constructs:
sequence,
selection,
iteration
STRUCTURED PROGRAMS
Unstructured control flows are avoided.
Consist of a neat set of modules.
Use single-entry, single-exit program
constructs.
 STRUCTURED PROGRAMS
● However, violations to this feature are
permitted:
– Dueto practical considerations
such as:
●Premature loop exit to support
exception handling.
STRUCTURED PROGRAMS
Structured programs are:
Easier to read and understand,
Easier to maintain,
Require less effort and time for
development.
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.
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.
DATA STRUCTURE-ORIENTED DESIGN
(EARLY 70S)

Techniques which emphasize

designing the data structure:
Derive program structure from it:
Are called data
structure-oriented design
techniques.
DATA STRUCTURE ORIENTED DESIGN
(EARLY 70S)

Example of data structure-oriented

design technique:
Jackson's Structured Programming(JSP)
methodology
Developed by Michael Jackson in 1970s.
DATA STRUCTURE ORIENTED DESIGN
(EARLY 70S)

● JSP technique:
– Program code structure should correspond to the data structure.
DATA STRUCTURE ORIENTED DESIGN
(EARLY 70S)

● In JSP methodology:
– A program's data structures are
first designed using notations for
●sequence, selection, and iteration.
– Then data structure design is
used :
●To derive the program structure.
DATA STRUCTURE ORIENTED DESIGN
(EARLY 70S)

● Several other data

structure-oriented Methodologies
also exist:
– e.g., Warnier-Orr
Methodology.
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.
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.
DATA FLOW-ORIENTED DESIGN (LATE 70S)
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.
DATA FLOW MODEL OF A CAR
ASSEMBLY UNIT

Engine Store Door Store

Partly
Chassis with Assembled
Engine Car
Fit Fit Fit Paint and Car
Engine Doors Wheels Assembled Test
Car

Chassis Store Wheel Store

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.
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.
OBJECT-ORIENTED DESIGN (80S)
Object-Oriented Techniques have
gained wide acceptance:
Simplicity
Reuse possibilities
Lower development time and cost
More robust code
Easy maintenance
EVOLUTION OF DESIGN
TECHNIQUES
Object-Oriented

Data flow-based

Data
structure-based

Control
flow-based

Ad hoc
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.
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.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES

Use of Life Cycle Models

Software is developed through several
well-defined stages:
requirements analysis and specification,
design,
coding,
testing, etc.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES

Emphasis has shifted

from error correction to error prevention.
Modern practices emphasize:
detection of errors as close to their point
of introduction as possible.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)

In exploratory style,
errors are detected only during
testing,
Now,
focus is on detecting as many errors
as possible in each phase of
development.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)

In exploratory style,
coding is synonymous with program
development.
Now,
coding is considered only a small part
of program development effort.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)
A lot of effort and attention is now being
paid to:
Requirements specification.
Also, now there is a distinct design phase:
Standard design techniques are being used.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)
During all stages of development process:
Periodic reviews are being carried out
Software testing has become systematic:
Standard testing techniques are available.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)
There is better visibility of design and code:
Visibility means production of good quality,
consistent and standard documents.
In the past, very little attention was being given to
producing good quality and consistent documents.
We will see later that increased visibility makes
software project management easier.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)
Because of good documentation:
fault diagnosis and maintenance are smoother
now.
Several metrics are being used:
help in software project management, quality
assurance, etc.
DIFFERENCES BETWEEN THE EXPLORATORY
STYLE AND MODERN SOFTWARE
DEVELOPMENT PRACTICES (CONT.)
Projects are being thoroughly planned:
estimation,
scheduling,
monitoring mechanisms.
Use of CASE tools.
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.
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.
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.
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.
WHY MODEL LIFE CYCLE ?

Processes are tailored for special

projects.
A documented process model
Helps to identify where the tailoring is
to occur.
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.
LIFE CYCLE MODEL (CONT.)

When a program is developed by a

single programmer ---
he has the freedom to decide his exact
steps.
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.
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.
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.
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.
LIFE CYCLE MODEL (CONT.)

It becomes easier for software project

managers:
to monitor the progress of the project.
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.
LIFE CYCLE MODEL (CONT.)

This usually leads to a problem:

known as the 99% complete syndrome.
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
SUMMARY

Software engineering is:

Systematic collection of decades of
programming experience
Together with the innovations made by
researchers.
SUMMARY

A fundamental necessity while

developing any large software product:
Adoption of a life cycle model.
SUMMARY
Adherence to a software life cycle model:
Helps to do various development activities in a
systematic and disciplined manner.
Also makes it easier to manage a software
development effort.