Introduction to

Software
Engineering

Lesson 1
Overview
This course introduces you to the field of Software Engineering which
is defined as the disciplined approach to developing software
Objectives
At the end of this course, you should be able to learn the following:
The product that is to be engineered
The process that provides the framework for engineering the product
Techniques for planning, organizing, monitoring, and controlling
software projects
Techniques for analysis, design, and testing of the end product,
including structured techniques
Issues related to the deployment and maintenance of the end product
Introduction
Product of Software Engineering: Software
Software vs. Hardware
Challenges of Developing Software
 Product of Software
Engineering:
Set of items or objects
that formSoftware
a “configuration”
that includes
• programs
• documents
• data ...
All created as part
Of Software
Engineering
 Software Poses Challenges
The Standish Group’s CHAOS studies show improvements in IT
projects in the past decade.*

Measure 1994 Data 2002 Data Result

Successful projects 16% 34% Doubled
Failed projects 31% 15% Halved
Money wasted on $140 B out $55 B out of More than
challenged and of $250 B $255 B halved
failed projects
*The Standish Group, “Latest Standish Group CHAOS Report Shows Project Success Rates
Have Improved by 50%” (March 25, 2003).
 Software Poses
Challenges
•Why does software not meet user or business needs?
•Why does it take so long to get software finished?
•Why are development costs high and projects over-budget?
•Why can’t we find all errors before we give software to customers?
•Why do we continue to have difficulty in measuring progress as software is
being developed ?
•Why is software hard to maintain?

ALL THIS AND MORE HAS LED TO THE USE OF SOFTWARE

ENGINEERING
What Makes Software
Different?
software costs are mostly in engineering vs.
manufacturing
software doesn’t wear out
 Hardware Failure Rate
Failure Rate

Hardware has relatively high

failure rates early due to design /
manufacturing defects
“Wear Out”
After defects corrected, failure rate
goes steady-state
As time passes, failure rate rises as
Infant mortality
hardware components suffer from
cumulative effects of dust,
vibration, abuse, temperature
extremes, and other environmental
factors.

Time

Source: Pressman
 Software Failure
Rate
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

Source: Pressman
 Challenges Caused by Myths

Management Myth 1:
My people have state-of-the art software development tools so I expect higher
productivity, after all, we buy them the newest computers.
Reality: it takes much more than latest model hardware
CASE (Computer aided software engineering) tools important for achieving good
quality and productivity, yet majority don’t use them effectively
Management Myth 2:
If we get behind schedule, can add more programmers and catch up.
Reality: As new people are added, current developers must spend time educating
newcomers
People can be added but only in planned manner

Source: Pressman
 Challenges Caused by Myths

Customer Myth 1 :
A general statement of objectives is sufficient to begin writing
programs – we can fill in details later.
Reality: Poor up-front definition is major cause of failed software
efforts
Customer Myth 2:
Project requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: Cost of change depends on time at which it is introduced.
The later, the more expensive it is !

Source: Pressman
 The Cost of
Change 60-100x

1.5-6x
1x

Definition Development After release

Source: Pressman
 Challenges Caused by Myths

Practitioner’s Myth 1:
Once we deliver software to customer, our job is done.
Reality. Between 60 – 80% of all effort expended on software is after
it is delivered to customer for first time
Practitioner’s Myth 2:
Until I get program “running” I have no way of assessing its quality
Reality: One of most effective software quality assurance
mechanisms, “formal technical review”, can be applied from the
beginning

Source: Pressman
 Challenges Caused by Myths

Practitioner’s Myth 3:
The only deliverable work product for successful project is working
software.
Reality: Documentation provides foundation for successful engineering
and guidance in maintenance phase
Practitioner’s Myth 4:
Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: SE is about creating documents to insure quality
Better quality leads to reduced rework

Source: Pressman
So, What is Software Engineering?

Framework for building software with higher quality.