Software Engineering

1
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
2
Introduction

For developing an engine,

Mechanical Engineering principles are used !!

3
Introduction

For developing a building structure,

Civil Engineering principles
are used !!

4
 What is Software
Engineering?
 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 )
5
Introduction

Similarly,
For developing a SOFTWARE,
Software Engineering principles
are used !!

6
What do we want in a system?
(What are the important attributes of
good software?)
 Reliability
 Efficiency
 Maintainable/ Adaptable
 Accessible / Usable (good interface design)
 Cost Effectiveness
 Safety
 Robustness
 Recoverability
 Portability
 Understandability

7
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, auto pilot
system.

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

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

10
 Fault tolerance is the capability of the
software product to maintain a specified
level of performance, or to recover from
faults in cases of any software faults.

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

13
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.
14
Why Study Software Engineering?
(3)

 To acquire skills to be a
better software engineer
(analyst/designer/developer/
tester…) instead of a
programmer:
 To achieve Higher Productivity
 Produce Better Quality Programs...

15
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.
16
Software Crisis…

 Software projects:
 Over budgets.
 Over Schedules.
 Large number of Cancellation.
 Uncontrolled and unmanaged.

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

18
Software Crisis (cont.)

Hw cost
Sw cost

1960 Year
1999…
Relative Cost of Hardware and Software

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

20
 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
21
after debugging described by marketing dept. customer wanted … :-)
 Software in the 21st Century…

 More safety critical, real-time software..

 Embedded software is everywhere … check your pockets,
 Smart devices… Intelligent systems…
 Enterprise applications means bigger programs, more users
 Security is now all about software faults,
 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.

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

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

24
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

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

26
 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.
28
Software Characteristics

 Developed or Engineered – not

“manufactured”
 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

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

30
 software..
Software products may be:
 GENERIC
 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

31
 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;
 Dependability
 Software must be reliable;
 Efficiency
 Software should not make wasteful use of system resources;
 Acceptability
 Software must accepted by the users for which it was designed.
This means it must be understandable, usable and compatible with
other systems.
32
Software Characteristics

 Many Types..
 System software, Real Time systems, Business
software, Scientific software, Embedded
software, PC based software, Web based
software, AI software etc.
 Products
 Generic or Packaged (COTS)
 Custom Built
 Sources
 Open (shareware) easily shared,
 Closed (Proprietary), have to be purchased
33 CISH-6050 - Software Engineering Management
33
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 is
only one of the several factors
that determine the quality
of the end software 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
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
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.
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
 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.

46
Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Nominal software development

schedules can be compressed
2 up to 25% (by adding people,
money, etc.) but no more.
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!
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 maintenance

4 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 can

5 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
Software
80

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

Coding 20 30

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 ??
57
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 individual
8 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
 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.
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

67
Programs versus Software
Products
 Usually small in size  Large
 Author himself is sole  Large number of
user users
 Single developer  Team of developers
 Lacks proper user  Well-designed
interface interface
 Lacks proper  Well documented &
documentation user-manual prepared
 Ad hoc development.  Systematic development

69
Programs versus Software
Products

 What is the difference between a student’s

program and industrial strength software
for the given problem?

70
 Programs versus Software
Products

Student Program Industrial Strength

 Developer is the user  Others are the users
 bugs are tolerable,  bugs not tolerated,
 UI not so important,  UI very imp. Issue,
 No documentation,  Tested carefully,
 No thorough testing.  Documents needed for
the user as well as for
the organization and
the project.

71
 Programs versus Software
Products
Student Program Industrial Strength
 SW not in critical use,  Supports important
 Reliability, robustness functions / business,
not so important,  Reliability , robustness
 Not much investment, are very important,
 Don’t care about  Heavy investment,
portability.  Portability, scalability is
a key issue here,

72
Computer Systems
Engineering
 Computer systems engineering:
 encompasses software engineering.

 Many products require development

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

73
Computer Systems
Engineering

 The high-level problem:

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

74
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

75
Computer Systems
Engineering (CONT.)

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

Project Management

76
Emergence of Software
Engineering

 Early Computer Programming

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

77
Early Computer
Programming (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

78
High-Level Language
Programming (Early 60s)

 Later, High-level languages

such as FORTRAN, BASIC, and
COBOL were introduced:
This reduced software
development efforts greatly.

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

80
 …. 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.
81
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.'’

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

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

84
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)

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

87
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.
88
Control Flow-Based Design (Late
60s)

 They published several

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

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

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

91
Structured Programming

 A program is called structured

when it uses the following
types of constructs:
sequencing,
selection,
Iteration.

92
Structured programs…

 Unstructured control flows

are avoided.
 Consist of a neat set of modules.
 Use single-entry, single-exit
program constructs.

93
Structured programs …

 Structured programs are:

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

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

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

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

103
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.
104
Data Flow-Oriented Design (Late
70s)

 Data flow technique is a general

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.
105
Object-Oriented Design (mid
80s)

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

 Relationships among objects:

such as composition, aggregation
and inheritance are determined.
 Each object essentially acts as
a data hiding (or data abstraction)
entity.
Polymorphism

108
Object-Oriented Design (80s)

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

109
Evolution of Design
Techniques
Object-Oriented

Data flow-based

Data structure-
based

Control flow-
based

Ad hoc

110
Evolution of Other Software
Engineering Techniques

 life cycle models,

 specification techniques,
 Design and modelling tools,
 project management techniques,
 testing techniques,
 debugging techniques,
 quality assurance techniques,
 software measurement techniques,
 CASE tools, etc. 112
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.
113
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.

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

 In exploratory style,
errors are detected only during
testing,
 Now,
 focus is on detecting as many
errors as possible in each phase
of development.
115
Differences Between the Exploratory Style and
Modern Software Development Practices..

 In exploratory style,
coding is synonymous with
program development.
 Now,
coding is considered only a small
part of overall software
development effort.
116
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.

117
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.
118
Differences between the exploratory style
and modern software development practices…

 Projects are being thoroughly

planned:
 Estimation of various resources,
 Scheduling of different activities,
 monitoring mechanisms.
 Use of CASE tools.

121
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. 122
 Common Symptoms of Failed
Software Development Projects

 1. Inaccurate understanding of end-user-needs

 2. Inability to deal with changing requirements
 3. improper designs of Modules
 4. Software that is too hard to maintain or extend
 5. Late discovery of serious flaws
 6. Poor software quality
 7. Unacceptable software performance

123
Some Root Causes for Failure

 1. Ad hoc requirements management

 2. Ambiguous and imprecise communication between
customer and developer
 3. Poor software architectures
 4. Overwhelming complexity
 5. Undetected inconsistencies in requirements,
design and implementations
 6. Insufficient testing
 7. Irregular project status assessment
 8. Uncontrolled change propagation
 9. Insufficient use of automation tools

124
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 prioritised ordering (sequence)
among the different activities,
 Divides life cycle into phases.
126
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
 Higher level design and lower level
design activity.
127
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 selecting a process model for
specific projects (according to application
domain).

128
Life Cycle Model (CONT.)

 The development team must

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

130
Life Cycle Model (CONT.)

 When a program is developed

by a single programmer ---
He/she has the freedom to decide
his/her exact steps (when and what
is to be done).

131
Life Cycle Model (CONT.)

 When a software product is being

developed by a team:
 there must be a precise understanding
among team members about when
and what is to be done.
 otherwise it would lead to chaos and
project failure.

132
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 quality plan for his
portion first.
133
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.

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

135
Life Cycle Model (CONT.)

 It becomes easier for software

project managers:
to monitor the progress of
individual phase and overall
progress of the entire project.

136
Life Cycle Model (CONT.)

 When a life cycle model is adhered to,

 the project manager can at any time
accurately tell,
 at which stage (e.g., design, code, test,
etc. ) 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.
137
Life Cycle Model (CONT.)

 This usually leads to a problem:

known as the 99% complete
syndrome.

138
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,
 Agile, and
 spiral model
139