Software

Engineering
INTRODUCTION

UU-COM 4001 ENGINEERING OF SOFTWARE

 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 What is Software
Engineering?
• Engineering approach to develop
software.
– Building Construction Analogy.
• Systematic collection of past
experience:
– techniques,
– methodologies,
– guidelines.
3
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 Technology Development
Pattern
Engineering

Technology

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

5
UU-COM 4001 ENGINEERING OF SOFTWARE
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: --- “One
thorn
of experience is worth a whole wilderness of
warning.” 6
UU-COM 4001 ENGINEERING OF SOFTWARE
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,
UU-COM 4001 E S
etc.
NGINEERING OF OFTWARE
7
Why Study Software Engineering?
(3)

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

8
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
Software Crisis (cont.)

Hw cost
Sw cost

1960 Year
1999
Relative Cost of Hardware and Software

10
UU-COM 4001 ENGINEERING OF SOFTWARE
 Factors contributing to the
software crisis

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

11
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 Computer Systems
Engineering

• The high-level problem:

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

14
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 Computer Systems
Engineering (CONT.)

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

Project Management

16
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 Early Computer
Programming (50s)
• Every programmer developed his
own style of writing programs:
– according to his intuition
(exploratory programming).

18
UU-COM 4001 ENGINEERING OF SOFTWARE
 High-Level Language
Programming (Early 60s)

• High-level languages such as FORTRAN,

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

19
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 ENGINEERING OF SOFTWARE
 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
UU-COM 4001 E
structure.'’
S
NGINEERING OF OFTWARE
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
UU-COM 4001 ENGINEERING OF SOFTWARE
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
UU-COM 4001 E S
execution sequence.
NGINEERING OF OFTWARE
24
 Control Flow-Based Design
(Late 60s)

• A program having a messy

flow chart representation:
–difficult to understand and
debug.

25
UU-COM 4001 ENGINEERING OF SOFTWARE
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
UU-COM 4001 ENGINEERING OF SOFTWARE
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
UU-COM 4001 E
TO statements
S
NGINEERING OF OFTWARE
inevitable.
27
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.

28
UU-COM 4001 ENGINEERING OF SOFTWARE
Control Flow-Based Design (Late
60s)

• They published several

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

29
UU-COM 4001 ENGINEERING OF SOFTWARE
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 ([Link](c=true) k=5 else
m=5;)
• iteration
UU-COM 4001 E S
(e.g. while(k>0) k=j-k;)
NGINEERING OF OFTWARE
30
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.
31
UU-COM 4001 ENGINEERING OF SOFTWARE
 Structured Programming

• A program is called structured

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

32
UU-COM 4001 ENGINEERING OF SOFTWARE
 Structured programs

• Unstructured control flows

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

33
UU-COM 4001 ENGINEERING OF SOFTWARE
 Structured programs

• However, violations to this

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

34
UU-COM 4001 ENGINEERING OF SOFTWARE
 Structured programs

• Structured programs are:

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

35
UU-COM 4001 ENGINEERING OF SOFTWARE
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.
UU-COM 4001 E S
NGINEERING OF OFTWARE
36