Software

Engineering

1
 Chapter 1

Software
Engineering
INTRODUCTION

2
Organization of this Chapter :

 What is Software Engineering?

 Programs vs. Software Products.
 Evolution of Software Engineering.
 Notable Changes In Software.
Development Practices.
 Introduction to Life Cycle Models.
 Summary.

3
Introduction

For developing a building

structure,
Civil Engineering principles
are used !!

4
 Introduction...
For developing a bicycle,
Mechanical Engineering
principles are used !

For developing an engine,

Mechanical Engineering is
applied !!

5
 Introduction...

For developing a fan/ bulb,

transformer
Electrical Engineering is applied !

For developing a radio, TV, Phone...

Electronics Engineering is used !!

6
Introduction...

Similarly,

For developing a SOFTWARE,

Software Engineering
principles
are used !!

7
 Introduction...

 Engineering approach to
develop software.
 Building Construction Analogy.
 Systematic collection of past
experience:
 techniques,
 methodologies,
 guidelines.
 Counting number of persons in a room
v/s the Census (i.e. population of a
country ) 8
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 the size of software increases.

10 lines.... 100 lines..... 500 lines.... 1000

lines.... 10000 lines.... 20,000 lines.... And
more..... 9
Why Study Software Engineering? (2)

 Ability to solve complex

programming problems:
 How to break/divide large projects
into smaller and manageable parts?
 Learn techniques of:
 specification, design, interface
development, testing, project
management, etc.
10
Why Study Software Engineering? (3)

 To acquire skills to be a better

“software engineer” (i.e.
analyst/ designer/ developer/
tester…) instead of a
programmer:
 To achieve Higher Productivity
 Produce Better Quality Programs...

11
Software Crisis
 In early days, Software products:

 fail to meet user requirements.

 frequently crash.
 expensive.
 difficult to alter, debug, and enhance.
 often delivered late.
 use resources non-optimally, like
Money, Man-power(HR), Machine, Months...

12
Software Crisis…

 Software projects:

 Over budgets.
 Over Schedules.
 Large number of Cancellation.
 Uncontrolled and unmanaged.

13
 Software Crisis…
 Research from Standish Group Data on 9236 development projects completed in 2004.

14
Software Crisis (cont.)

Hw cost
Sw cost

1960 Year
1999…
Relative Cost of Hardware and Software

15
Factors Contributing to the
Software Crisis

 Larger and complex

problems,
 Lack of adequate training in
software engineering,
 Shortage of skilled people,
 Low productivity and quality
improvements.
16
 How was Software usually Constructed
…

The requirements The developers This is how the This is how the
specification was understood it in problem was programmers
defined like this that way designed coded it
before.

That is the program This is how the program is This, in fact, is what the
17
after debugging described by marketing dept. customer wanted … :-)
Important Root Causes of
Project Failures
 Ad hoc requirement management,
 Ambiguous and imprecise communication at
different level,
 Overwhelming complexity,
 Undetected inconsistencies in requirement,
design, and implementation.
 weak software architectures(cohesion &
coupling),
 Insufficient testing,
 Incorrect or subjective assessment of project
status,
 Uncontrolled change propagation.
 Insufficient automation.
 Software in the 21st Century…
 More safety critical, real-time software…
 Embedded software is everywhere … check your pockets,
 Smart devices… Intelligent systems….IoT…..AI and
Machine Learning…
 Enterprise applications means bigger programs, more
users, (e.g. ERP systems)
 Security is now all about software quality,
 Secure software is reliable software.
 The web offers a new deployment platform,
 Very competitive and highly available to large number
of users,
 Web apps must be highly reliable.

19
19
The Changing Nature of Software

System Real
Software Time
Software
Engineering Embedded
and Scientific Software
Software

Web based Business

Software
Software
Artificial
Intelligence Personal
Software Computer
Software

20
 What are the important
attributes of good software?
 The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and acceptable.
 Maintainability:
 Software must evolve to meet changing needs;
 Software must be reliable;
 Efficiency
 Software should not make wasteful use of system
resources;
 Acceptability
 Software must be accepted by the users for which it was
designed. This means it must be understandable, usable and
compatible with other systems.
21
What do we want in a system?
(What are the important attributes of
good software?)
 Reliability
 Efficiency
 Maintainable/ Adaptable
 Accessible / Usable (good interface design)
 Robustness
 Portability
 Understandable
 Scalability
 ....

22
Reliability describes the ability of a
system to keep functioning correctly
under specific use over a given
period.
(System should not fail in adverse
circumstances) e.g. health care
system, patient monitoring system,
nuclear reactor system, auto pilot
system.
23
 The test for efficiency measures the
required time and consumption of
resources for the fulfillment of tasks.
Resources may include other software
products, the software and hardware
configuration of the system etc. e.g.
ATM.
 It doesn’t waste resources such as CPU
time and memory.

24
 Usability is very important for
interactive software systems. Users
will not accept a system which is
hard to use. So the system should be
easy to use.

 Users should learn it quickly and get their

jobs done easily

25
Essential attributes of good
software
Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to meet
the changing needs of future. This is a critical attribute because software
change is an inevitable requirement of a changing business
environment.

Dependability and security Software dependability includes a range of characteristics including

reliability, security, safety etc. Dependable software should not cause
physical or economic damage in the event of system failure. Malicious
users should not be able to access or damage the system.

Efficiency Software should not make wasteful use of system resources such as
memory and processor cycles. Efficiency therefore includes
responsiveness, processing time etc.

Acceptability Software must be acceptable to the type of users for which it is

designed. This means that it must be understandable, usable and
compatible with other systems that they use.

26
Quality Software...
Customer: User:
solves problems at easy to learn;
an acceptable cost in efficient to use;
terms of money paid and helps get work done
resources used

QUALITY
SOFTWARE

Developer: Development manager:

sells more and
easy to design;
easy to develop & maintain; satisfies customers
easy to reuse its parts while costing less
to develop and maintain

27
What is Software Engineering?

IEEE : Software Engineering:

(1) The study and use of a
systematic, disciplined, quantifiable
approach to the development,
operation, and maintenance of
software; that is, the application of
engineering to software.

28
Software Engineering…

 Software engineering is a discipline

whose aim is the production of
fault-free software, delivered on
time and within the given
budget, that satisfies all the
user’s requirements.

29
 Software Engineering…
 The process of solving customers’ problems by the
systematic and phase vise development and
evolution of large, high-quality software systems
within cost, time and other constraints.

Software engineering techniques are needed

because large systems can not be completely
understood/ explained/ developed by one
person,
Teamwork and co-ordination are required,
Dividing up the work and ensuring that the parts
of the system work properly together,
The end-product must be of good quality. 30
Software Engineering…

 Broad definition:
 The methods, processes, technologies and tools
by which software systems are developed and
maintained.
 Encompasses many areas:
– Planning and managing software projects
– Requirements Analysis and Specification
– System Modeling and Design
– System Implementation
– Testing and quality assurance
– Maintenance
31
 Decomposition

 The important approach to tackle the complexity

of given problem is decomposition. In this
technique, a complex problem is divided into
several smaller problems and then the smaller
problems are solved one by one.

32
 Abstraction

 The important principle of

abstraction implies that a problem
can be simplified by omitting
irrelevant details. In other words, the
main purpose of abstraction is to
consider only those aspects of the
problem that are relevant for certain
purpose and suppress other aspects
that are not relevant at this time and
for given purpose. 33
Software Characteristics

 Developed or Engineered – not

“manufactured”
Software is intangible,
 Software is logical system element,
 Software projects managed differently
than manufacturing projects
 Software doesn’t physically wear out
like hardware might
 Most software are custom built
34 34
Software…

 Computer programs and associated

documentation such as requirements,
design models and user manuals.
 Software products may be developed for a
particular customer or may be developed
for a general market.
 New software can be created by
developing new programs, configuring
generic software systems or reusing
existing software.
35
 Software...
Software products may be:
 Generic (COTS)
 developed to be sold to a range of different
customers e.g. PC software such as Excel or Word.
 referred to as commercial off-the-shelf (COTS)
software or clickware supplied by a vendor

Personalized (custom made ) - developed for a

single customer according to their specification.
Product specification controlled by the product
developer

36
 Software…
 Many Types...
 System software, Real Time systems, Business
software, Scientific software, Embedded software,
PC based software, computer viruses, Web based
software, AI and machine learning software etc.
 Products
 Generic or Packaged (COTS)
 Custom Built
 Sources
 Open (shareware) easily shared,
 Closed (Proprietary), have to be purchased

37 CISH-6050 - Software Engineering Management

37
Important Root Causes of
Project Failures
 Ad hoc requirement management,
 Ambiguous and imprecise communication at
different level,
 Overwhelming complexity,
 Undetected inconsistencies in requirement,
design, and implementation.
 weak software architectures(cohesion &
coupling),
 Insufficient testing,
 Incorrect or subjective assessment of project
status,
 Uncontrolled change propagation.
 Insufficient automation.
Software Myths

39
Software
Software Myths
Myths
(Management
(Management Perspectives)
Perspectives)
As long as there are good standards and clear
procedures in my company, I shouldn’t be too
concerned.

But the proof of the pudding

is in the eating;
not in the Recipe !
 Software
Software Myths
Myths
(Management
(Management Perspectives)
Perspectives)
As long as my software engineers, have
access to the fastest and the most
sophisticated computer environments and
state-of-the-art software tools, I shouldn’t be
too concerned.

The environment/ infrastructure is

only one of the several factors
that determine the quality
of the end product!
Software
Software Myths
Myths
(Management
(Management Perspectives)
Perspectives)
When my schedule slips, what I have to do
is to start a fire-fighting operation: add more
software specialists, those with higher skills
and longer experience - they will bring the
schedule back on the rails!
Unfortunately,
software business does not
entertain schedule compaction
beyond a limit!
 Software
Software Myths
Myths
(Customer
(Customer Perspectives)
Perspectives)
 A general statement of objectives is
sufficient to get started with the
development of software.
Missing/vague requirements can
easily be incorporated even lately in
the development process.
Software Myths
(Customer Perspectives)
A general statement of objectives is sufficient to get
started with the development of software.
Missing/vague requirements can easily be
incorporated/detailed out as they get concretized.

If we do so, we are heading towards

a disaster.

44
 Software
Software Myths
Myths
(Developer
(Developer Perspectives)
Perspectives)
Once the software is demonstrated, the job
is done.

Usually, the problems just begin!

 Software
Software Myths
Myths
(Developer
(Developer Perspectives)
Perspectives)
Until the software is coded and is available for
testing, there is no way for assessing its quality.

Usually, there are too many

tiny bugs inserted at every stage
that grow in size and complexity
as they progress thru further stages!
 Software
Software Myths
Myths
(Developer
(Developer Perspectives)
Perspectives)

The only deliverable for a software

development project is the tested code.

The code is only

the externally visible component
of the entire software!
 Software
Software Product
Product
is a product designated for delivery to
the user (complete software suite)
source
source documents
documents
codes
codes reports
reports

manuals
manuals
object
object plans
plans
codes
codes
data
data

test test
testresults
results
testsuites
suites prototypes
prototypes
Boehm’s
Boehm’s
Top
Top Ten
Ten
Industrial
Industrial Software
Software
Metrics
Metrics
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Finding and fixing a software

problem after delivery of the
product is 100 times more
1 expensive than defect
removal during requirements
and early design phases.
Relative
Relative Effort
Effort to
to Repair
Repair Software
Software
(when
(when defects
defects are
are detected
detected at
at
different
different stages)
stages)

20 20
relative effort to repair

15

10

5 5

1 2
0.5
0 0.15

Maintenance
Unit test

Acc. Test
Reqmts

Coding
Design
 Bug/Error…
 An error/bug is a mistake, misconception, or
misunderstanding on the part of a software
developer.
 In the category of developer we include software
engineers, like: business analysts, system analysts,
designers, programmers, testers etc.

 For example, an analysts may misunderstand a

requirement, a designer may misunderstand a
design notation, or a programmer might type a
variable name incorrectly.
Bug…Error---fault…defect---
Failure

 Small bug in the initial phase

(requirements),
 Becomes an error in later phases,
 May become serious fault in testing
phase,
 And can be the major cause of system
failure after implementation.

53
Bug/defect (Cost-Time Relation)
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Nominal software
development schedules
2 can be compressed up to
25% (by adding people,
money, etc.) but no more.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Maintenance costs twice

3 what the development
costs.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Development and

4 maintenance costs are

primarily a function of the
size.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Variations in humans (people

5
can be transferred or can
change the company) account
for the greatest variations in
overall productivity.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

The ratio of software to

hardware costs has gone
6 from 15:85 in 1985 and
continues to grow in favor
of software as the leading
cost.
Hardware
Hardware Vs
Vs Software
Software
Costs
Costs

100 Hardware

80 Software

60

40

20

0
1960 1970 1980 1990
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Only about 15% of the

7 development effort is in
coding.
 Distribution
Distribution of
of Effort
Effort
Across
Across Phases
Phases

10
25 5
45
Testing 15 40

20 30
Coding
15
Design 45
30
20
Analysis
Traditional Structured CASE environment
environment techniques

Analysis Design Coding Testing

What is CASE?
 Computer-Aided Software Engineering
 Software systems that are intended to provide
automated support for software process activities.
Upper-CASE
 Tools to support the early process activities of
requirements and design;
 Lower-CASE
 Tools to support later activities such as
programming, debugging and testing.

Reverse Engineering ??
63
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Application software
products cost three times as
much per instruction as
8 individual programs; system
software products cost nine
times as much.
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Walkthroughs/reviews catch
9 around 65% of the errors.
Distribution
Distribution of
of Activities
Activities
in
in Defect
Defect Removal
Removal

walkthru
unit test
evaluation
10 5 10 integration
other
10

65
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics
Many software processes
10 obey a Pareto distribution.

20% 80%
modules cost
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10 Many software processes

obey a Pareto distribution.

20% 80%
modules errors
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10 Many software processes

obey a Pareto distribution.

20% 80%
modules cost
to fix the
errors
Symptom of Software Crisis
 about US$250 billion spent per year in
the US on application development
 of this, about US$140 billion wasted
due to the projects getting discarded
or reworked; this in turn because of
not following best practices and
standards in the development
process i.e. S.E.
Ref: Standish Group, 1996
70
Programs versus Software
Products

 What is the difference between a

student’s program and industrial
strength software for the given
problem?

71
 Programs versus Software
Products

Student Program Industrial Strength

 Developer is the  Others are the users,
user, and large number of
 bugs are tolerable, users
 UI not so important,  bugs not tolerated,
 No documentation,  UI very imp. Issue,
 No thorough  Tested carefully,
testing.  Documents needed for
the user as well as for
the project and for the
whole organization.
72
 Programs versus Software
Products
Student Program Industrial
 SW not in critical Strength
use,  Supports important
 Reliability, functions / business,
robustness not so  Reliability,
important, robustness are very
 Not much important,
investment,  Heavy investment,
 Don’t care about  Portability,
portability. scalability, Security
73
are key issues here,
Programs versus Software Products

 Student  Industrial
Program Strength
 Usually small in size  Large in size
 Author himself is  Large number of
sole user users
 Single developer  Team of developers
  Well-designed
Lacks proper user
interface interface
  Well documented &
Lacks proper user-manual
documentation prepared
 Ad hoc  Systematic
development. development
74
 Emergence of Software
Engineering
 Early Computer Programming
(early 1950s):
 Programs were being written in
m/c language initially and then in
assembly language.
 Programs were limited to about a
few hundreds of lines of assembly
code.

75
 Early Computer Programming
( late 50s)
 Every programmer developed
his/her own style of writing
programs:
 according to his/her convenience
(called exploratory
programming/ adhoc
programming) which leads to
Adhoc development.
development

76
 High-Level Language
Programming (Early 60s)
 Later, High-level
languages such as
FORTRAN, BASIC, and
COBOL were introduced:
 This reduced software
development efforts greatly.

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

78
 …. in 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.

79
Control Flow-Based Design
(late 60s)

 Programmers found:
 programs written by others were
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.'’

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

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

82
Control Flow-Based Design (Late 60s)

 After some time, It was found:

 GO TO statements makes control

structure of a program messy
 GO TO statements alter the flow of
control arbitrarily.
 Need to restrict the use of GO TO
statements was recognized.
83
Control Flow-Based Design (Late 60s)

 Many programmers, that time,

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

84
Control-flow Based Design (Late 60s)

 At that time, Dijkstra

published his article in a
research paper:
 “Goto Statement Considered
Harmful” Comm. of ACM, 1969.
 (a milestone in this journey)
 Many programmers were
unhappy to read his article.
85
Control Flow-Based Design (Late 60s)

 They published several

counter articles:
 highlighting the
advantages and
unavoidability of GO TO
statements.

86
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;)

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

88
Structured Programming

 A program is called
structured
 when it uses the following
types of constructs:
sequencing,
selection,
Iteration.

89
Structured programs …

 Structured programs are:

 Easier to read and
understand,
 easier to maintain,
 require less effort and time
for development.
90
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.

91
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,
 External entities of the system.

92
93
Data Flow-Oriented Design (Late 70s)

 Data flow technique is a

general technique:
 can be used to model the working
of any information system
A major advantage of the
data flow technique is its
simplicity.
95
Object-Oriented Design (mid 80s)

 Object-oriented technique:
 a naturally appealing design
approach:
 natural objects (such as
employees, pay-roll-register,
books etc.) occurring in a
problem are first identified.
96
Object-Oriented Design (80s)

 Relationships among objects:

 such as association, composition,
aggregation and inheritance are
determined.
 Each object essentially acts as
 a data hiding entity,
 data abstraction,
 Encapsulation,
 Polymorphism...
Unified Modeling Language
97
Object-Oriented Design (80s)

 Object-Oriented Techniques
have gained wide
acceptance:
 Simplicity
 Reuse possibilities
 Lower development time and
cost
 More robust code
 Easy maintenance

98
Evolution of Design Techniques

Object-Oriented

Data flow-based

Control flow-based

Ad hoc

99
Evolution of Design Techniques

Object-Oriented Paradigm

Structured Paradigm

Ad hoc

100
Evolution of Other Software
Engineering Techniques
 life cycle models,
 specification techniques,
 design and modelling
techniques,
 project management techniques,
 testing techniques,
 debugging techniques,
 software maintenance,
 automation tools...
101
Differences Between the Exploratory Style and
Modern Software Development Practices

 Use of Life Cycle Models

(Process Models)
 Software is developed through several
well-defined stages:
 requirements analysis and
specification,
 design,
 coding,
 testing, etc.

102
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 as possible,
to their point of introduction.
 The principle of detecting errors as close, to its
point of introduction, as possible:
is known as phase containment of
errors.

103
Differences Between the Exploratory Style and
Modern Software Development Practices..

 In exploratory style,
 errors are detected only
during testing phase,
 Now,
 focus is on detecting as
many errors as possible in
each phase of development.

104
Differences Between the Exploratory Style and
Modern Software Development Practices..

 In exploratory style,
 coding is synonymous with
software development.
 Now,
 coding is considered only a
small part/portion of overall
software development effort.
105
Differences Between the Exploratory Style and
Modern Software Development Practices..

 Lots 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.

106
Differences Between the Exploratory Style and
Modern Software Development Practices..

 During all stages of

development process:
 Periodic reviews are being
carried out
 Software testing has become
systematic:
 standard testing techniques
are available (e.g. WBT, BBT)
107
Differences between the exploratory style and
modern software development practices…

 Projects are being thoroughly planned:

 Estimation of various resources,
 Scheduling of different activities,
 Planning of various milestones,
 monitoring mechanisms,
 Better Documentation.
 Use of automation tools (like testing tools,
CASE tools) CPM and PERT.

108
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.
109