SOFTWARE ENGINEERING
devastating effects.
Importance of Software Engineering
Complex systems need a disciplined approach
for designing, developing and managing them.
TIME
COST QUALITY
TIME – kailangan iconsider yung time sa
paggagawa ng software, para malaman kung
kalian yung deadline or yung time kung
hanggang kalian magagagawa yung software
COST – yung cost ng software, or paggawa ng
software
QUALITY – kailangan quality, hindi bad quality
SOFTWARE DEVELOPMENT CRISES
Projects were:
• Late – di natapos on time
• Over budget – hindi sakto sa budget yung
total nung software
• Unreliable – pag mali yung mga nalagay sa
software like yung sources
• Difficult to maintain – di na mamaintain yung
software, di nauupdate on time
• Performed poorly - di nagana ng maayos,
kulang sa test?
Software errors….the cost
Errors in computer software can have
SOFTWARE CRISIS
Example 1: 2009,Computer glitch delays flights
Saturday 3rd October 2009-London, England
(CNN)
• Dozens of flights from the UK were delayed
Saturday after a glitch in an air traffic control
system in Scotland, but the problem was fixed a
few hours later.
• The agency said it reverted to backup
equipment as engineering worked on the
system.
• The problem did not create a safety issue but
could cause delays in flights.
Example 2: Ariane 5 Explosion
• European Space Agency spent 10 years and $7
billion to produce Ariane 5.
• Crash after 36.7 seconds.
• Caused by an overflow error. Trying to store a
64-bit number into a 16-bit space.
Example 3: 1992, London Ambulance Service
• Considered the largest ambulance service in
the world.
• Overloaded problem.
• It was unable to keep track of the ambulances
and their statuses. Sending multiple units to
some locations and no units to other locations.
• Generates many exceptions messages.
• 46 deaths.

Therefore…
A well-disciplined approach to software
development and management is necessary.
This is called engineering.
 the term software engineering first appeared
in the 1968 NATO
Software Engineering Conference and was
meant to provoke thought regarding what was
then called the “software crisis”
 “.. An engineering discipline that is concerned
with all aspects of software production from the
early stages of system specification to
maintaining the system after it has gone into
use.” Sommerville,
pg.7
TYPES OF SOFTWARE
GENERIC PRODUCTS
- Stand-alone systems, marketed and
sold to customers
- Ex. PC Software such as graphic
programs
- Specification is owned by the software
developer and decisions on software
change are made by the developer
CUSTOMIZED OR BBESPOKE PRODUCTS
- Commissioned by a specific customer to
meet their own needs
- Embedded control systems
- Specification of what the software
should do is owned by the customer for
the software and they make decisions
on software changes that are required
SOFTWARE ENGINEERING vs COMPUTER
SCIENCE
Computer Science is no more about computers
than astronomy is about telescopes - edger
dijkstra
Computer Science
- Theory
- Fundamentals
Software Engineering
- Practicalities of software design,
development and delivery
SOFTWARE ENGINEERING vs SYSTEMS
ENGINEERING
Systems Engineering
- Interdisciplinary engineering field
(computer, software, and process eng)
- Focuses on how complex engineering
projects should be designed and
managed
- All aspects of computer-based systems
development: HW + SW + Process
- Older than SWE
Software Engineering
- Deals with design, development and
delivery of SW
- Part of Systems Engineering

QUESTIONS
What is software?
- Computer programs and associated
documentation. Software products may
be developed for a particular customer
or may be developed for a general
market.
What are the attributes of good software?
- Good software should deliver the
required functionality and performance
to the user and should be maintainable,
dependable and usable.
What is software engineering?
- Software engineering is an engineering
discipline that is concerned with all
aspects of software production.
What are the fundamental software
engineering activities?
- Software specification, software
development, software validation and
software evolution.
What is the difference between software
engineering and computer science?
- Computer science focuses on theory
and fundamentals; software
engineering is concerned with the
practicalities of developing and
delivering useful software.
What is the difference between software
engineering and system engineering?
- System engineering is concerned with
all aspects of computer-based systems
development including hardware,
software and process engineering.
Software engineering is part of this
more general process.
What are the key challenges facing software
engineering?
- Coping with increasing diversity,
demands for reduced delivery times
and developing trustworthy software.
What are the costs of software engineering?
- Roughly 60% of software costs are
development costs, 40% are testing
costs. For custom software, evolution
costs often exceed development costs.
What are the best software engineering
techniques and methods?
- While all software projects have to be
professionally managed and developed,
different techniques are appropriate for
different types of system. For example,
games should always be developed
using a series of prototypes whereas
safety critical control systems require a
complete and analyzable specification
to be developed. You can’t, therefore,
say that one method is better than
another.
What differences has the web made to software
engineering?
- The web has led to the availability of
software services and the possibility of
developing highly distributed service-
based systems. Web-based systems
development has led to important
advances in programming languages
and software reuse.
SOFTWARE PROCESS
Process Activity
SPECIFICATION – what does the customer COST OOF SOFTWARE ENGINEERING
needs? ; What are the constraints?
 Depends on:
DEVELOPMENT – Design and programming
 The process used, and
VALIDATION – Checking whether it meets
 The type of software being
requirements
developed.
EVOLUTION – Modifications (customer/market)
 Each generic approach has a different profile
of cost distribution.

SOFTWARE PROCESS MODEL  Roughly 60% of costs are development costs,

40% are testing costs.
Description of the software process that
represents one view, such as the activities, data  For custom software, evolution costs often
or roles of people involved. exceed development costs.

WORKFLOW – activities = human actions; what

CASE
is input, output, and dependencies
Computer Aided Software Engineering
DATAFLOW – activities = transformations of
information; how the input is transformed into Programs that support:
output
 Requirements analysis.
ROLE/ACTION – what is the role of people
involved in each step of the process?  System modeling.

 Debugging.

MODELS  Testing.

Waterfall Approach

Iterative Development ATTRIBUTES OF A GOOD SOFTWARE

Component-Based Software Engineering – Functional attributes (performance; what the

CBSE; assembled from existing components system does).

Non-functional attributes (quality; how the

system does it).

MAINTAINABILITY – evolution qualities such as

testability, extensibility

DEPENDABILITY – reliability, security, safety

EFFICIENCY – response time, processing time,

memory utilization
USABILITY - Easy to learn how to use the system
by target users. Efficient to use the system by
users to accomplish a task. Satisfying to use by
intended users.
CHALLENGES FACING SOFTWARE ENGINEERING
Heterogeneity – different computers, different
platforms, different support systems; software
needs to cope with this variability
DELIVERY - Businesses are more responsive
(supporting software needs to evolve as
rapidly); software needs to be delivered in
shorter time without compromising quality.
TRUST - Software is a part of many aspects of
our lives (work, study, leisure); Software needs
to demonstrate that it can be trusted by users.
SOFTWARE LIFECYCLE
A software engineering lifecycle model
describes how one might put structure on the
software engineering activities
The classic lifecycle model is the waterfall
model (roughly due to Royce in 1956), which is
structured by a set of activities and is inherently
document-driven
Limited feedback increases risk
“You start at the top and it’s all downhill from
there.” [uncertain origin]
The cost of fixing errors at later lifecycle phases
is much higher than at earlier stages
- Boehm’s 1976 data still hold — the
differences are often an order of
magnitude
- Must increase feedback in the lifecycle
to reduce these costs (and other risks)
MODELS OF SOFTWARE ENGINEERING
Why have a model
The goals of a model
Look at a few models
What was NT’s model
WHY HAVE A MODEL
Software has become vital in our everyday life
Software programs are large complicated beasts
- NT started out small. Today not one
single person can grasp all of NT.
A model recognize that Software Engineering is
more than just programming
Recognize product life cycles
- Various requirements specification
phases
- Design phases
- Coding and testing phases
- Maintenance phase (bug fixes and
revisions)
A model helps recognize and define the division
of labor
- Individual responsibilities (program
managers, software design engineers,
UI designers, testers, product support,
internationalization, marketing, etc.)
- How big should a team be (look at
MMM)
- Parallel work efforts
- Does a one person team need a model
Provide a common means of communication
between all involved parties
Documentation is vital
- Comments in the code is not sufficient
documentation
 - Dave Cutler’s NT design workbook is
now part of the Smithsonian
WATERFALL MODEL

WHY NOT HAVE A MODEL

Avoids bureaucracy

Cost of an inadequate or improperly applied

model

- Build the wrong product

- Build something that doesn’t work
- Build something that cannot be tested
- Build something that cannot be What it is
maintained What it tried to accomplish
- Not take into account personnel
changes, and requirement changes - Account for more than programming
- Feedback between phases
GOALS OF A GOOD MODEL
Benefits
The obvious “Provide a framework for building
a solidly engineered product” Limitations

A paradigm that adds discipline and order to - Limited feedback increases risk
software development - A requirement change can have a major
cost downstream
Provides a formal mechanism to clarify, track,
and modify the product requirements
throughout the product life cycle BOEHM’S SPIRAL MODEL
Provide a guideline for engineers to use in the
product life cycle

Provide feedback into the development cycle

Compel engineers to want to use it

- Doesn’t get in the way

- Convinces them that they will build a
better product
- Be easy to understand and use

Keep everyone organized

Many more “common sense” reasons What it is

What it tried to accomplish

FIRST A SIMPLE MODEL (WATERFALL) - Recognize that Software Engineering is
a process of iterative refinement
 - Allow for alternate designs and
implementations
Benefits
Limitations
LESSONS FROM THE MODELS
Each trying to capture or dictate how a project
should be run
Even a good properly applied model cannot fix a
flawed design
Not any model offers the 100% solution
Often borrowing from one or more model is
necessary
Just as Software Engineering is full of
compromises so is using a Software Engineering
model
So take these models with a grain of salt and
use only those parts that apply to your situation
THE NT EXPERIENCE
Daily builds
- Incremental and clean builds
- Catch build errors
- Without daily builds entropy would rule
Dog food
- NT developers ran the latest build on
their own system.
- Performance and functional inadequate
features were usually taken care of in a
timely fashion
- Broken pieces had to get fixed
THE NT ALBATROSS
Maintenance cost including maintaining
compatibility between releases is huge
- With later versions of NT compatibility
is a huge burden.
Maintaining old API sets
Apps that improperly used the
API set in earlier releases
- Unforeseen interaction between pieces
also increases maintenance costs
Small changes break seemingly
unrelated things, for example the handle table
change in NT 5.0
Controlling kernel stack usage is
always hard
MP performance problems crop
up constantly when two pieces interact
SOFTWARE ENGINEERING REQUIREMENTS
Two words that bear repeating “Risks” and
“Constraints”
Specifying requirements
- What makes up a requirement
- What is not in a requirement
- Ways of specifying requirements
- One person’s requirement is usually
someone else’s design
Some Angles on Requirements
What vs. How
System requirements vs. Software requirements
Functional vs. non-functional
Requirements change
Keep it realistic
Expect unintended side affects (i.e., customers It is an iterative process, a good requirements
will use the system in ways you can never writer bridges the gap between customer and
imagine) implementer

Any method for dictating requirements is only

as good as the people are willing to use it
EXAMPLES

Successful projects that met their requirements

Who Writes the Requirements and Has Major
- Caller ID, Call forwarding, etc.
Input
- TCAS
Program Managers
Past failures or future failures (?)
Customers
- Therac-25 (An Investigation of the
Therac-25 Accidents, by Nancy Leveson Software Design Engineers
and Clark S. Turner, 1993)
Software Test Engineers
Computerized radiation therapy
Performance Engineers
machine
Realistic
Did not follow proper software
engineering practices KISS
- Internet security
- Tower of Babel
PROTOTYPING

Building the throw away model

WHAT SHOULD BE IN A REQUIREMENT
Building models that demonstrate properties of
Desired effects of the system the real product
Know your intended customers and speak their Building something faster and cheaper than the
language real product
Likewise know the implementers and speak WHY PROTOTYPE
their language
To reduce risk
Justify your requirements so that the next
person understands your reasoning To learn while you have the luxury

- How people will use and interact with

the product
HOW TO SPECIFY REQUIREMENTS - How to build the real product
Natural Language to To tweak the design before it is too late
Structured Natural Language to - Change requirements
- Change interface
Formal notation
- Change architecture
The goal is to convey enough information to MISSING
judge the design and the process necessary to
The code is missing
build the product
- Typically most of the error handling is
missing
EXAMPLES - May not be extensible, maintainable or
just well designed
The wooden Palm Pilot
- Typically not fully featured
Model cars
It maybe of limited size and
Storyboards scope

Mock-ups (space station, airplanes, kitchens, It maybe slow

etc.)
The documentation, testing, performance, and
A subset of an API set can be a prototype support considerations are missing

A non-fully featured app can be a prototype

(then it can act as a sales tool)
When do we do a prototype and when to start
There is really a wide spectrum from paper and stop prototyping
design notes to full featured prototypes (for
When potential payoff outweighs the cost of
example a building architects sketches to stick
doing a prototype
models)
Finish the prototype when you’ve learned what
Building construction sometimes erects a
you wanted to know
sample wall (to learn how to build the real
product and ensuring it meets its requirements) Also move on when other risks become more
pressing

- Slipping your schedule and spending

SOFTWARE PROTOTYPE
too much money on development
Isn’t the previous version a prototype
But resist jumping into the coding phase before
- It can often be used as a basis for you’re really ready
prototyping
- What to do in the absence of a previous
version Who builds, sees and uses the prototype

Screenshots and storyboards The program manager

Languages and tools for prototyping The customer to test usage scenarios

Not everything is easy to prototype The developer to see what to build

- UI’s are easier Testing, product support, et cetera

- API sets are hard
RISKS

Slows the process

- A longer time to market often translates

to decreased revenue
- Software Design Engineers don’t like to
wait for Program Management to say
what to build
- Software Design Engineers don’t listen
to Program Management

Program Management believes their prototype

should be the product

Program Management convinces upper

management that the product is possible
because the prototype works

- Sad but true, this occurs more often

than it should