Software Engineering

Chapter 1

Software Engineering
Fundamentals

1
 Contents
What is software?
Types of software,
Nature of software.
What is software engineering?
Why Software Engineering?
Software crises
Some examples of software failures
Reason for software failure
Silver bullet ?
Software quality
Software Engineering and the Engineering
Profession
2
Ethics in Software Engineering
 What is software?
Software is
 set of instruction or programs that direct the
computer hardware or that help user to perform
users task.
 collection of computer programs, procedures, rules,
and associated documentations and data (IEEE).
Software have variety of application or touch
all aspect of human life.
Some of them are:
business domain
 engineering domain(software used for drawing,
drafting, modelling, etc)
Education domain (e-learning, ...)
3
etc
 Types of software
There are different types of software based on
different criteria
One way to classify software is as
 System Software and Application Software
In another way software can be classified as
Custom (Bespoke) : For a specific customer
Example: web sites, air traffic system, etc
Generic: Often called COTS (Commercial Off
The Shelf) or Shrink-wrapped.
Sold on open market
Example: word processors, spread sheets,
compilers, etc
Embedded: Built into hardware
4
Hard to change
 Types of software…
Software can also be classified as
Real time software: Must react immediately
Safety is often a concern
e.g. control and monitoring systems
Almost all embedded systems have hard real-time
constraint.
Data processing software: Used to run businesses
Accuracy and security of data are key concerns
Functions: recording sales, managing accounts,
printing bills
Some software has both aspects
e.g.. Telephone system (managing phone calls and
billing for those calls)
Can you think other ways to categorize software?
5
 The Nature of Software
Software is intangible: Hard to understand development
effort
Software is easy to reproduce: Cost is in its
development
in other engineering products, manufacturing is the costly
stage
The industry is labor-intensive: Hard to automate
Untrained people can hack something together
Quality problems are hard to notice
Software is easy to modify
People make changes without fully understanding it.
Software does not ‘wear out’: It deteriorates by
having its design changed:
 Changes often tend to introduce new defects
6
 What is Software Engineering?
The process of solving customers’ problems by the
systematic development and evolution of large,
high-quality software systems within cost, time and
other constraints

Other definitions:
IEEE: (1) the application of a systematic, disciplined,
quantifiable approach to the development, operation,
maintenance of software; that is, the application of
engineering to software. (2) The study of approaches
as in (1).
The Canadian Standards Association: The systematic
activities involved in the design, implementation and
testing of software to optimize its production and
7
support.
 What is Software Engineering?...
 Solving customers’ problems: is the goal of every
software engineering
Sometimes the solution is to buy, not build
 Systematic development and evolution: An
engineering process involves applying well understood
techniques in a organized and disciplined way
Many well-accepted practices have been formally
standardized e.g. by the IEEE or ISO
Large, high quality software systems: Software
engineering techniques are needed because large systems
cannot be completely understood by one person.
 Teamwork and co-ordination are required
Cost, time and other constraints: Finite resources
o Inaccurate estimates of cost and time have caused many
8
project failures
 Why software Engineering?
Just like mechanical engineers design
mechanical systems and electrical engineers
design electrical systems software engineers
design software systems.
 Software appears, by its nature, to be difficult to
engineer on a large scale
 Because software differs in important ways from the
artifacts produced by other engineering discipline.
 We continue to be dogged by large numbers of
project failures, on small and large projects.
Many of these are due to mistakes in project
management.
 Nevertheless, there is an insatiable demand for
9 sizeable, well-engineered software.
 Why software Engineering?...
 As per the IBM report, “31%of the project get cancelled
before they are completed, 53% overrun their cost
estimates by an average of 189% and for every 100
projects, there are 94 restarts”.
Software industry is in Crisis
 The causes of the software crisis were linked to the
overall complexity of hardware and the software
development process.
 The crisis manifested itself in several ways:
Projects running over-budget and over-time.
Software was very inefficient and of low quality
Software often did not meet requirements.
Projects were unmanageable and code difficult to maintain.
Software was never delivered.
Property damage and loss of life
10
 Some software failures
Ariane 5
It took the European Space
Agency 10 years and $7 billion
to produce Ariane 5,
Ariane 5 is a giant rocket capable
of hurling a pair of three-ton
satellites into orbit
The rocket was destroyed after
39 seconds of its launch, at an
altitude of two and a half .
Reason: Overflow error when
converting data from 64-bit format to
16-bit format
11
 Some software failures…
The Patriot Missile
First time used in Gulf war
Used as a defense from Iraqi Scud
missiles
Failed several times including one
that killed 28 US soldiers wounded
100 in Dhahran, Saudi Arabia
Reasons:
 A small timing error in the system’s
clock accumulated to the point that
after 14 hours, the tracking system
was no longer accurate.
 In the Dhahran attack, the system had
been operating for more than 100
hours.
12
 Some software failures…
 Y2k (the Year 2000 Problem)
was a problem for both digital (computer-
related) and non-digital documentation
and data storage situations which resulted
from the practice of abbreviating a four-
digit year to two digits.
Businesses spent billions on programmers
to fix a glitch in legacy software. While no
significant computer failures occurred,
preparation for the Y2K bug had a
significant cost and time impact on all
industries that use computer technology.
•Reason: To save computer storage space, legacy
software often stored the year for dates as two digit
numbers, such as “99″ for 1999. The software also
interpreted “00″ to mean 1900 rather than 2000, so
when the year 2000 came along, bugs would result.
13
 Some software failures…
Therac 25 incident
The Therac-25 was a radiation
therapy machine produced by Atomic
Energy of Canada Limited(AECL).
It was involved with at least six
accidents between 1985 and 1987, in
which patients were given massive
overdoses of radiation,
approximately 100 times the
intended dose.
Three of the six patients died as a
direct consequence.
Reason: bad software design and
development practices

14
 Some software failures…
Windows XP
o Microsoft released Windows
XP on October 25, 2001.
o On the same day company
posted 18 MB of compatibility
patches on the website for
bug fixes, compatibility
updates, and enhancements.
o Two patches were intended to
fix important security holes.
(one of them did : The other
patch didn’t work)

15
 Reason for software failure
Why?
we can’t find all errors before release
It takes so long to get the program finished
It cost so high?
There a difficulty in measuring progress of software
development….

Software engineering appears to be among the

few options available to tackle the present
software crisis.
Demand for software is high and rising
Much software has poor design and is getting worse
We are in a perpetual ‘software crisis’
We have to learn to ‘engineer’ software


16
But is there sliver bullet to tackle the problem?
 No Silver Bullet
The hardware cost continues to decline
drastically.
However, there are desperate cries for a silver
bullet something to make software costs drop
as rapidly as computer hardware costs do.
But as we look to the horizon of a decade, we
see no silver bullet.
There is no single development, either in
technology or in management technique, that
by itself promises even one order of magnitude
improvement in productivity, in reliability and in
simplicity.
However, though there is no royal road, there is
a path forward.
17
 Looking for silver bullets
Tools
Structured programming, object-oriented programming, CASE
tools, Ada, Java, documentation, standards, and Unified
Modelling Language were touted as silver bullets
Discipline
The software crisis was due to the lack of discipline of
programmers
Formal methods
Apply formal engineering methodologies to software
development, to make production of software as predictable as
other branches of engineering, proving all programs correct
Process
Processes and methodologies like the Capability Maturity Model
Professionalism
This led to work on a code of ethics, licenses, and
professionalism
18
 Software Quality
Is the degree to which a system, component or
process meets customer or user needs or
expectations. Some examples of SQ
Usability: Users can learn it and fast and get their job
done easily
Efficiency: It doesn’t waste resources such as CPU
time and memory
Reliability: It does what it is required to do without
failing
Maintainability: It can be easily changed
Reusability: Its parts can be used in other projects,
so reprogramming is not needed
 Software quality can be
Internal or external
19
Short term or long term
 Software Quality…
External quality of software: quality of software on the
eye of users
Examples: Usability, efficiency, accuracy, …
Internal quality: refers to Characterize aspects of the
design and source code of the software
Have an effect on the external quality attributes
E.g. The amount of commenting of the code, The complexity of
the code
Short term quality:
Does the software meet the customer’s immediate needs?
Is it sufficiently efficient for the volume of data we have today?
Long term quality:
Maintainability
Customer’s future needs
Scalability: Can the software handle larger volumes of data?

20
 Software Quality…
All kinds of software qualities are important .
However, the relative importance of each will vary
from stakeholder to stakeholder and from system to
system
Different qualities can conflict each other
Increasing efficiency can reduce maintainability or
reusability
Increasing usability can reduce efficiency
Solutions
Setting objectives for quality is a key engineering activity
You then design to meet the objectives
Avoids ‘over-engineering’ which wastes money
Optimizing is also sometimes necessary
E.g. obtain the highest possible reliability using a fixed
budget
21
 Software Engineering and the Engineering Profession
The term Software Engineering was coined in
1968
People began to realize that the principles of
engineering should be applied to software
development
Engineering is a licensed profession
In order to protect the public
Engineers design artifacts following well accepted
practices which involve the application of science,
mathematics and economics
Ethical practice is also a key tenet of the profession
In many countries, much software engineering does
not require an engineering license, but is still
engineering
22
 Ethics in Software Engineering
Software engineers shall
Act consistently with public interest
Act in the best interests of their clients
Develop and maintain with the highest
standards possible
Maintain integrity and independence
Promote an ethical approach in management
Advance the integrity and reputation of the
profession
Be fair and supportive to colleagues
Participate in lifelong learning

23
 Software Engineering

Chapter 1

Software Engineering
Fundamentals
(cont’d)
24
 Contents
Software Processes
Software Life Cycle and Process Models
 Code-and-fix
Water fall model
Spiral model
Incremental development model
Evolutionary development model
Formal systems development
Reus-oriented development
Automated process support (CASE)

25
 Software Process
Process is particular course of action intended
to achieve a result.
Software Process [ software development life
cycle (SDLC)] is structured set of activities
required to develop a software system.
Requirement Specification - what the system should
do and its development constraints
Development (design and implementation (Coding))
- production of the software system
Testing (Validation) - checking that the software is
what the customer wants
Maintenance (Evolution) - changing the software in
response to changing demands
26
 Software life cycle
The time from the initial idea for a product until it
is delivered is the development life cycle.
When the product is delivered, its real life begins.
The product is in use or deployed until it is
disposed of.
The time from the initial idea for a product until it
is disposed of is called the product life cycle, or
software life cycle, if we focus on software
products.
Everything we do in software life seems to follow a
few common steps, namely:
Requirements engineering, designing, coding,
testing, evolution.
27
 Software process models
Software development projects are large and complex
A phased approach to control it is necessary
Software process model is an abstract description of
the sequence of activities carried out in a software
engineering project, and the relative order of these
activities.
One of the goals of software engineering is to provide
models and processes that lead to the production of
well-documented maintainable software in a manner
that is predictable.
There are hundreds of different process models
They are usually grouped according to one of the
following concepts: Sequential, Iterative and
Incremental models.
28
 Software process models...
Examples of software process models
Code-and-Fix process model
The waterfall process model
Spiral process Model
Incremental development process model
Evolutionary development process model
Formal Transformation process model
Reuse-based development process model
Rational Unified Process model(RUP)
Time Boxing (Reading Assignment)
Rapid Application Development(RAD)
Extreme programming (Reading Assignment)
V-Model, W-Model etc

29
 Code-and-Fix process model
This model starts with an informal general
product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order. Disadvantage
Advantage

• No administrative • No visibility/control
overhead • No resource
• Signs of progress (code) planning
early. • No deadlines
• Low expertise, anyone • Mistakes hard to
can use it! detect/correct
• Useful for small
projects.

30
•Impossible for large projects: communication
 Waterfall model
Linear sequence of phases/stages
Requirements – design-Code – Test – Deploy
The following phase should not start until
the previous phase has finished: no/little
feedback
 But in practice, phases overlap and may
return to a previous phase.
The phases partition the project, each
addressing a separate concern
This model is only appropriate when the
requirements are well-understood
31
 Waterfall model...

32
 Drawbacks (of waterfall model) advantages(of waterfall model)

1. Requires that 1. Easy to understand

requirements and implement.
are well- 2. Widely used and
specified and known (in theory!)
unchanging. 3. Fits other
2. Assumes a engineering
sequential flow, process models:
which real civil, mechanical
projects rarely etc.
follow 4. Reinforces good
3. Working version habits: define-
becomes before- design,
available very design-before-code
The of late
the (after 5. Identifies
waterfall model:
coding) deliverables and
4. Developers may milestones
33
have to wait 6. Works well on
 Spiral process Model
Extends waterfall model by adding iteration to
explore/manage risk.
Important software projects have failed because
project risks were neglected & nobody was
prepared when something unforeseen happened.
Barry Boehm recognized this and tired to incorporate
the “project risk” factor into a life cycle model.
A spiral model is divided into a number of
framework activities, also called task regions.
Typically, there are between 3-6 task regions.
Delivers the software in a series of incremental
releases
When risks are high and need to be resolved, it is
reasonable to use this approach
34
 Spiral process Model…

35
 Spiral process Model…

36
 Advantages (of Spiral Model) Disadvantages(of Spiral
Model)
• Realism: the model • Needs technical
accurately reflects the expertise in risk
iterative nature of analysis and risk
software development on management to
projects with unclear work well.
requirements. • Model is poorly
• Flexible: incorporates the understood by
advantages of the non technical
waterfall and management,
evolutionary methods. hence not so
• Comprehensive model to widely used.
decreases risk. • Complicated
• Good project visibility. model, needs
• On each iteration, plans, competent
costs, risks and professional
37 schedules updated and management.
project manager get • High
 Incremental development model
Rather than deliver the system as a single
delivery, the development and delivery is broken
down into increments with each increment
delivering part of the required functionality.
User requirements are prioritised and the highest
priority requirements are included in early
increments.
Once the development of an increment is started,
theoutline
Define requirements are frozen
Assign requirements though
Design system requirements
for later increments
requirements to increments can continue
architecture to evolve.

Develop system Valida te Integrate Valida te

increment increment increment system
Final
system
38
System incomplete
 Incremental development model...
Advantages Disadvantages
• Customer value can be • Increment
delivered with each s may be
increment so system difficult to
functionality is available define
earlier.
• Client does not have to • Software
pay for entire software may be
together. difficult to
• Early increments act as a maintain
prototype to help elicit
requirements for later
increments
When• the
Lower risk product
“core” of overall
is well understood and
project
increments canfailure.
be easily defined, it is reasonable to
use•this
The highest priority
approach.
39 system services tend to
 Evolutionary development model
Evolutionary development is based on the idea of
developing an initially implementation,
exposing this to user comment and
refining this through many versions until an
adequate system is developed.
When requirements are not well understood, it
may be reasonableConcurr
to use
ent
activities
this approach.
Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

40
 Evolutionary development model
There are two types of evolutionary development
Exploratory development
- Objective is to work with customers and to evolve a final
system from an initial outline specification.
- Should start with relatively well-understood requirements.
- The system evolves by adding new features as they are
proposed by customer.
Throw-away prototyping
Objective is to understand the system requirements.
Should start with poorly understood requirements, Develop
“quick and dirty” system quickly, Expose to user comment
and refine until adequate system is developed.
Particularly suitable where detailed requirements not
possible.

41
 Advantages (of evolutionary Disadvantages(of evolutionary
model) model)
• The resulting system • Lack of process
is easier to use visibility
• User needs are • Systems are often
better poorly structured
accommodated • Special skills (e.g.
• Problems are in languages for
detected earlier rapid prototyping)
• The design is of may be required
higher quality
• The development
incurs less effort
Applicability,
• Use prototyping when the requirements are
unclear.
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
42 interface)
• For short-lifetime systems
 Formal systems development
Based on the transformation of a
mathematical specification through
different representations to an executable
program.
Transformations are ‘correctness-
preserving’ so it is straightforward to show
that the program conforms to its
specification.
Integration and
Requirements
Embodied
definition
Formal
inspecification
the ‘Clean room’Formal
approach
transformation to
system testing
software development

43
 Formal systems development...
Problems
Need for specialised skills and training to
apply the technique
Difficult to formally specify some aspects of
the system such as the user interface.
Advantage
The resulting software will have high quality
Applicability
Critical systems especially those where a
safety or security case must be made before
the system is put into operation

44
 Reuse-oriented development
Based on systematic reuse where systems
are integrated from existing components or
COTS systems
Process stages
Component analysis
Requirements modification
System design with reuse
Development and integration
System Validation
This approach is becoming more important
but still there is limited experience with it

45
 Process Models & Process visibility
Software systems are intangible so
managers need documents to assess
progress.
Process model Process visibility
Waterfall model Good visibility, each activity produces some
deliverable
Evolutionary Poor visibility, uneconomic to produce
development documents during rapid iteration
Formal Good visibility, documents must be produced
transformations from each phase for the process to continue
Reuse-oriented Moderate visibility, it may be artificial to
development produce documents describing reuse and
reusable components.
Spiral model Good visibility, each segment and each ring
of the spiral should produce some document.

46
 Automated process support (CASE)
 Computer-aided software engineering (CASE) is software
to support software development and evolution processes
 CASE examples: Graphical editors for system model
development, Data dictionary to manage design entities, GUI builder
for user interface construction, Debuggers to support program fault
finding, Automated translators to generate new versions of a
program
 Case technology has led to significant improvements in
the software process though not the order of magnitude
improvements that were once predicted.
Software engineering requires creative thought - this is not
readily automatable
Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support these

47
 CASE classification
Classification helps us understand the different
types of CASE tools and their support for process
activities
Functional perspective:
 Tools are classified according to their specific function
Process perspective
 Tools are classified according to process activities that are
supported
Integration perspective
 Tools are classified according to their organisation into integrated
units
CASE Tools can also be classified into two
Upper-CASE: Tools to support the early process
activities of requirements and design
Lower-CASE: Tools to support later activities such as
programming, debugging and testing
48
 Functional tool classification

Tool type Examples

Planning tools PERT tools, estimation tools,
spreadsheets
Editing tools Text editors, diagram editors, word
processors
Change management tools Requirements traceability tools, change
control systems
Configuration management tools Version management systems, system
building tools
Prototyping tools Very high-level languages,
user interface generators
Method-support tools Design editors, data dictionaries, code
generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static
analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-
structuring systems

49
 Process Activity-based classification
Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processing
tools

Method support tools

Prototyping tools

Configuration
management tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verification

and
Validation

50
 CASE integration
Tools
Support individual process tasks such as design
consistency checking, text editing, etc.
Workbenches
Support a process phase such as specification or
design
Environments
Support all or a substantial part of an entire
software process.
Normally include several integrated
workbenches

51
 Tools, workbenches, environments
CASE
technology

Tools Workbenches Environments

File Integrated Process-centred

Editors Compilers
comparators environments environments

Analysis and
Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches

52