Introduction to

Software
Engineering
Lecture 2
1
What is
Software Engineering?
• Definition
• Software Engineering is an engineering discipline
• Concerns with the development of software by
applying Engineering Principles
• Goal is the cost-effective development of software
systems
• Origin
• 1968: The notion of ‘software engineering’ was first
proposed at a conference held to discuss what was
called the “software crisis”.
2
 Knowledge Spectrum
TheThe
Application of engineering study that focuses
creation of artifacts and
science knowledge to improve
on materials,
systems toprocesses
meet people's
the quality of life. We are
andnow
material
needs actions
– construction,
being creative with our manufacturing
knowledge

Solutions
Theory

Engineering Engineering Engineering Production

Science Installation
Science Design Technology

3
 A Computing Spectrum
•Development Environment
•Implementation Standards
•Algorithms
•Information theory
•Computability theory

Solutions
Theory

Engineering Engineering Engineering Production

Science
Science Design Technology Installation

•System Software •Analysis &

•System
•Computer Architecture Design Methods Administration
•Information storage •Design Process •End-user Support
•Measurements
4
 Computing Professions
•Creates new applications
applying engineering principles
and CS best practices

Software Engineer

Solutions
Theory

Engineering Engineering Engineering Production

Science Installation
Science Design Technology

Computer Scientist Information Technologist

•Creates New Infrastructure •Provides end-user solutions

5
“Software Engineering”
• Definition
– Based on Webster definition of “engineering”
• The application of science and mathematics by which the
properties of software are made useful to people
• Includes computer science and the sciences of making things
useful to people
– Behavioral sciences, economics, management sciences

6
Software Engineering
• Software Engineering [IEEE-93]:
1.The application of a systematic, disciplined,
quantifiable approach to the development, operation,
and maintenance of software; that is, the application
of engineering to software.
2.The study of approaches as in 1

IEEE-93: IEEE Standard Glossary & Software Engineering Terminology

7
SE and Other Engineering
Disciplines
• Two major components in engineering systems
• Design
• Manufacture

• Engineering is applied to both design

and manufacture
• Significant part of an engineering discipline is the manufacturing
process
• Have mathematics, for example, for optimization of processes
• Engineer manufacturing and fabrication equipment

8
• SE: engineering is applied to both as well, BUT
• Manufacture is
• Trivial (by comparison – sometimes complex and time-consuming)
• Mundane
• Automated
• Much larger emphasis on engineering applied to DESIGN
• Building a software product is a DESIGN process
• General design approaches/principles applied to diverse domains

9
Reading Assignment
• Brooks, Jr., F.P., "No Silver Bullet—Essence and Accidents of
Software Engineering (IEEE Computer Magazine; April 1987)
Mythical Man-Month, 20th Anniversary Edition, Addison-
Wesley, 1995

10
 No Silver Bullets
Essence and Accidents of
Software Engineering
11

FREDERICK P. BROOKS, JR., 1987

Based on presentations by
F.P Brooks
Devon Simmonds Computer Science Department University of North arolina Wilmington

Software Engineering Spring 2009

 The Software Werewolf
12

Software is like a werewolf—it looks normal until the

moon comes out and it turns into a monster
 Missed deadlines
 Blown budgets
 Buggy software
We want the silver bullet to kill the
monster
 something to make software costs drop as
rapidly as computer hardware costs do.

Software Engineering Spring 2009

 !There Is No Silver Bullet
13

“As we look to the horizon of a decade hence, we see no silver

bullet.
There is no single development, in either
essence, technology or in management technique,
that by itself promises even one order-of-magnitude
improvement in productivity, in reliability, in
simplicity”

Goal: ”In this article, I shall try to show why, by

examining both the nature of the software problem
and the properties of the bullets proposed.”

Software Engineering Spring 2009

 Essential vs. Accidental Difficulties
14

Essential: a characteristic of software

 Difficulties inherent in the nature of software
 Data sets, relationships among them, algorithms, and function
invocation
 Inherent properties of the essence of modern software
system:
Complexity, Conformity, Changeability, Invisibility

Accidental: a problem in today’s production methods

 Difficulties related to the actual production process.
 Note: This doesn’t mean “by chance”!

Software Engineering Spring 2009

 Complexity
15

No two parts are alike

Huge number of states
Complexity grows nonlinearly with size
Can’t know the whole domain, process, or system
Unlike other disciplines, we can’t abstract away the
complexity because it is essential
Math, physics: complexities ignored in the models were not


the essential properties of the phenomena.

Introduces technical and managerial

Complexity 
problems leading to unreliability
Software Size 

Software Engineering Spring 2009

 Software has order of magnitude more states than“
"computers
16

?How many paths

loop < 20 X
There are about

1014 (~520)
possible paths!
If we execute one test per
millisecond, it would
take 3,170 years to test
this program!!

Software Engineering Spring 2009

 Consequences of Complexity
17

Communication overhead: cost overruns, schedule

delays
Large number of states: unreliability
 overview is hard
 hard to find and control all the loose ends.
 creates a tremendous learning and understanding burden
Complex function: poor usability
Complex structure: poor maintainability

Software Engineering Spring 2009

 Conformity
18

Software development lacks unifying rules and

theories.
 man made not God made.
Software must conform to arbitrary limitations
 imposed by humans (e.g. business rules) institutions and
systems
Software arrives late in system design
Software viewed as most changeable
It’s hard to plan for arbitrary changes that will
occur late in development
Software Engineering Spring 2009
 Changeability
19

Software is easier to change than hardware or cars

Changes during development
Changes after deployment
New features
Software lives longer than hardware
Conform to new vehicles of opportunity (computers,
displays etc..)

People underestimate difficulties of change

Software Engineering Spring 2009

 Invisibility
20

The code is invisible and unvisualizable

Software reality not embedded in space: no ready geometric
representation.
Structure is terribly complex
Structure is hidden
There’s only the external input/output view

silicon chips have diagram Buildings have plans UML class

Software Engineering Spring 2009

 Accidental Difficulties Already Solved
21

High level languages

 Powerful stroke for software productivity, reliability, &
simplicity
 Removed the low level complexities
 Benefits of further improvement is limited
Time sharing
 Increased turnaround time and productivity of programmer
 Improvement is not as much as that of high-level language
 System response time is no longer an issue
Integrated programming environments
 Use of libraries, unified file formats, pipes, filters etc

Software Engineering Spring 2009

 !Is There Any Hope? Yes
22

“A disciplined, consistent effort to develop,

propagate, and exploit these innovations
should indeed yield an order-of-magnitude
improvement. There is no royal road, but
there is a road.”

Technical developments that are most often advanced as

potential silver bullets
 Ada & High Level Languages Advances.
 OOP
 AI
 Expert Systems
 Etc.

Software Engineering Spring 2009

 Things To Try
23

Reuse: “buy, don’t build”

Requirements improvement and rapid prototyping
Incremental development: (“grow don’t build”)
Better SE training : grow “great designers”
“My first proposal is that each software organization must
determine and proclaim that great designers are as important to its
success as great managers are, and that they can be expected to be
Future Software Engineers
similarly nurtured and rewarded. Not only salary, but the
perquisites of recognition-office size, furnishings, personal technical
equipment, travel funds, staff support-must be fully equivalent.”
Multiple coordinated techniques

Software Engineering Spring 2009

 Summary
24

No one advance will give a 10x improvement

 All the accidental difficulties have been solved
 No one advance will address essential difficulties
But perhaps we can learn to better exploit what
we’ve learned

Software Engineering Spring 2009

 The Inevitable Pain of Software
Development:
Why There Is No Silver Bullet
25

DANIEL M. BERRY, 2004

Software Engineering Spring 2009

 About the paper
26

This paper tries to get to the root of why any given

new programming technique has
not improved productivity very much.

 This paper is…an attempt “to analyze why some

ideas were or were not successful” with the choice of
“were not”.

Software Engineering Spring 2009

Programming Then and Now (~40 years perspective)
27

 I remember doing requirements analysis at the same time as I was doing

the programming in the typical
seat-of-the-pants build-it-and-fix-it-until-it-works
method of those days: ,Basically
 discover some requirements, programming felt like
skiing down a narrow
 code a little,
downhill valley with an
 discover more requirements,
avalanche following me
 code a little more, down the hill and gaining
 etc, until the coding was done; .on me
 test the whole thing,
 discover bugs or new requirements,
 code some more, etc.
 Nowadays, we follow more systematic methods. However, the basic
feelings have not changed.

Software Engineering Spring 2009

 The Problem by Berry
28

The real problem of software engineering is dealing

with ever-changing requirements.
No model, method, artifact, or tool offered to date
has succeeded to overcome this problem.

Software Engineering Spring 2009

 The Search for a Silver Bullet
29

Brooks:
The essence is what the software does and the
accidents are the technology by which the software
does the essence or by which the software is
developed.
 That is, the requirements are the essence, while the language,
tools, and methods used are the accidents.
what is so difficult about understanding
requirements?
 it should be possible to sit down with the customer and users,
ask a few questions, understand the answers, and then
synthesize a complete requirements specification.

Software Engineering Spring 2009

 Requirements Change
30

Two things are known about requirements:

1. They will change.
 Software will always have to be modified, to capture the
changed requirements.
 There ain’t no way to stop change of requirements .
2. They will be misunderstood.
 Software will always have to be modified, to capture the
changes imposed by better understanding, as the
misunderstandings are discovered.

Software Engineering Spring 2009

 Maintenance of application software
(Bennett Lientz and Burton Swanson ‘78)
31

Software Engineering Spring 2009

Expected number of errors in a program as a function of time
(Laszlo Belady and Meir Lehman ‘75,’86)
32
Belady-Lehman
,(B-L) upswing
it is very
difficult to
change anything
without
adding more
errors than have
been fixed by
the change

the software at its

most bug-free
Release change

Software Engineering Spring 2009

 Purpose of Methods
33

Example: Information Hiding attempts to structure

a system into modules such that-
each implementation change results in changing only
the code, and not the interface, of only one module.

? ?

Software Engineering Spring 2009

 Development Models and Global Methods
34

Example development models and general

programming methods to identify their painful parts.
 Example Models
 Waterfall
 Requirements Engineering.
 Example general methods
 Structured Programming
 Extreme Programming,
 Program Generation
 Rapid Prototyping
 Formal Methods

Software Engineering Spring 2009

 Bottom line (by Berry)
35

I no longer get excited over any new language,

development model, method, tool, or environment
that is supposed to improve programming…

…The most important work is addressing

requirements, changes, and the psychology and
sociology of programming

Software Engineering Spring 2009