Software Engineering

(LECT 1)

Dr. Raghunath Dey

School of Computer Engineering
KIIT Deemed to be University

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
What is Software Engineering?

• Engineering approach to
develop software.
–Building Construction Analogy.
• Systematic collection of past
experience:
–techniques,
–methodologies,
–guidelines.
3
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 4
Technology Development Pattern

Engineering

Technology

Esoteric
Craft Systematic Use of Past
Past Experience and Scientific
Experience Basis
Unorganized Use
of
Art Past Experience
Time

Estoric: understood by only few people with a special knowledge

5
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:

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

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

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

9
Software Crisis (cont.)

Hw cost
Sw cost

1960 Year
1999
Relative Cost of Hardware and
Software
10
Factors contributing to the software
crisis

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

11
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

12
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.
13
Computer Systems Engineering
• The high-level problem:
–deciding which tasks are to be
solved by software
–which ones by hardware.

14
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

15
Computer Systems Engineering (CONT.)

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

Project
Management

16
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.
17
Early Computer Programming (50s)

• Every programmer developed

his own style of writing
programs:
–according to his intuition
(exploratory programming).

18
High-Level Language Programming
(Early 60s)

• High-level languages such as

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

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

20
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.
21
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.'’ 22
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.

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

• A program having a messy

flow chart representation:
–difficult to understand and
debug.

25
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.
26
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. 27
Structured Programming

• A program is called structured

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

28
Structured programs

• Unstructured control flows

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

29
Structured programs

• However, violations to this

feature are permitted:
–due to practical considerations
such as:
• premature loop exit to support
exception handling.

30
Structured programs

• Structured programs are:

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

31
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. 32
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.

33
Data Structure-Oriented Design (Early 70s)

• Techniques which
emphasize designing the
data structure:
–derive program structure from
it:
• are called

34
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.
35
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.
36
Data Flow Model of a Car Assembly
Unit
Engine Door
Store Store

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

Chassis Wheel
Store Store

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
Object-Oriented

Data flow-
based
Data structure-
based

Control flow-
based

Ad hoc

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

42
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.
43
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.
44
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.
45
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.
46
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. 47
Differences between the exploratory style and
modern software development practices (CONT.)

• Projects are being thoroughly

planned:
– estimation,
– scheduling,
– monitoring mechanisms.
• Use of CASE tools.

48
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 49

• 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.
50
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.

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

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

53
Life Cycle Model (CONT.)

• When a program is developed

by a single programmer ---
–he has the freedom to decide his
exact steps.

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

55
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.
56
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.

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

58
Life Cycle Model (CONT.)

• It becomes easier for software

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

59
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
60
members.
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, etc.
61
Summary

• Software engineering is:

–systematic collection of decades
of programming experience
–together with the innovations
made by researchers.

62
Summary

• A fundamental necessity while

developing any large software
product:
–adoption of a life cycle model.

63
Reference
• R. Mall, “Fundamentals of Software
Engineering,” Prentice-Hall of India, 1999,
CHAPTER 1.

64