Software Engineering

Introduction to Software Engineering

Software Engineering:
Author: Pressman R.S
A Practitioner's Approach, 7/e, Mc Graw Hill

1
Course Objective
1. To introduce Software Engineering and the need for
Engineering approach to software development.
2. Enable participants to appreciate their role and contribution
to, the SDLC.
3. To Introduce the participant to quality concepts and quality
system procedures in industry.
4. To introduce the participant to commonly used analysis and
design methods.
5. To introduce structured programming concepts and
principles of coding.
6. Introduce the participant to software testing. Appreciate
importance of software testing.
2
Chapter Overview

1 Introduction
1.1 A Brief History of Software

1.1.1 The Early Years

1.1.2 The Software Crisis

1.2 The Engineering Approach to Software

Development
1.3 Software Engineering

1.4 Summary

3
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.

Software products may be

Generic - developed to be sold to a range of different
customers
Bespoke (custom) - developed for a single customer
according to their specification 4
The Importance of Software
Software has become part of the national infrastructure
i,e computers are put to use more than ever these days in every
aspect of life, be it Transport, telecom, finance, manufacturing,
service..

Software is the differentiating factor

1. Hardware is general-purpose, software is application-specific
2. Hardware is becoming a commodity
Software is often costlier than the hardware it runs on because of
customization

Software engineering is about managing this complexity. Eg:

UNIX contains 4 million lines of code
Windows 2000 contains 108 lines of code 5
Softwares Dual Role
Software is a product
Delivers computing potential
Produces, manages, acquires, modifies, displays, or

transmits information

Software is a vehicle for delivering a product

Supports or directly provides system functionality
Controls other programs (e.g., an operating system)

Effects communications (e.g., networking software)

Helps build other software (e.g., software tools)

6
Characteristics of Software..
software is developed / engineered, not manufactured
software doesnt wear out
software is complex
Most software is custom built, although the industry is moving toward
component-based construction
A software product should
perform the required function
be reliable
be maintainable
be efficient
have an appropriate user interface
have an appropriate lifetime

7
 Failure curve for Hardware - Bath tub curve
Failure Rate Ware out

Infant mortality

Time
Infant mortality: design or manufacturing defects during initial
stages
Ware out: as h/w components suffer from cumulative affects of
dust vibrations, temperature extremes and other environmental
remedies

8
 Wearout vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

9
The Software Crisis
Early software development was personalized
programs were small
No standard and structured approach
Believed that only a gifted few were able to write programs
Much emphasis was on H/w than S/w
No Documentation
Computation, design were performed in ones head.
Debugging and fixing a bug was difficult

As sophistication/complexity of applications grew,

No tools/ methods for managing the increasing complexity.
Maintenance became difficult .
The no. of errors raised exponentially

All the above factors resulted in Software crisis like

1. Software projects were taking longer time than originally estimated.

2. Software development costing a lot more than initially estimated.
3. More failures reported by costumer.
4. Errors found were extremely difficult to trace and fix.
10
Some statistics
One in four systems miscarry
Major corporations have a backlog of up to a 30
months
Large systems take 3 to 5 years to develop
Corporations are spending up to 20% of revenue
on Information Technology
Y2K problem took up to 50% of resources in at
least one bank in Australia.

11
Need For Engineering Approach
Absence of a structured and methodical approach caused
problems like:
Errors made in one phase of development carried over

to subsequent phases causing rework and therefore

delay.
Difficulty in estimating effort, and measuring progress

caused schedule slippage and budget overruns.

Quality of delivered software in terms of defects was

not estimated.
No guarantee that all promised changes are
incorporated.

12
Need For Engineering Approach contd..
Demands of Todays Business
Hardware sophistication has outpaced our ability to build software that
completely taps its potential;

With increasing competitiveness in todays business market-timing has

become utmost important, demanding tight and aggressive software
delivery schedules.

Technological advances in the software space couples with competition

is demanding new software, our ability to build software cannot keep
pace with this demand;

Frequently changing business needs demand frequent updates to

existing software, our ability to maintain existing programs is
undermined by poor design and haphazard development practices.
13
Need For Engineering Approach contd.

In response to these problems and demands, it is clear

that a discipline for software development must exist.
There is a need to introduce a rigor and structure into
the process.
Ideas about systematic development were borrowed
from a sister discipline, namely Engineering, giving
rise to a new discipline
Software Engineering

14
 What is Software Engineering?
Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation and maintenance
of software;

i.e., the application of engineering to software OR use of Methods

/Techniques , Tools & Standards for designing and building a product

Software engineers should

Adopt a systematic and organised approach to their work
use appropriate tools and techniques depending on
the problem to be solved,
the development constraints and
the resources available
to build good, reliable software
15
Software Engineering contd.
Software Engineering provides a set of
Methods(what&how), Tools & Procedures (when)

Methods(What&How) provide the rules and steps for

carrying out software engineering tasks,
such as
Project planning

Requirements analysis

Design

Coding

Testing and maintenance.

16
Software Engineering contd.
Tools provide automated or semi-automated support for
methods
Tools that automates a range of software engineering methods,
called Computer-Aided Software Engineering (CASE)

17
Software Engineering contd.
Procedures (when) bind the methods and tools into a
framework
Defining the sequence in which methods will be applied

Specify deliverables

Controls quality and coordinate change

Set milestones to assess progress

18
SE History
SE introduced first in 1968 conference about software
crisis

Early approaches based on informal methodologies leading to

Delays in software delivery

Higher costs than initially estimated

Unreliable, difficult to maintain software

Need for new methods and techniques to manage the production of

complex software.

19
The changing nature of Software
System software: Collection of programs written to service other
programs. Eg: OS, Compilers, Editors, Linkers, Loaders,
Assemblers, Drivers, Networking softwares,.
The SS is characterized by interaction with the computer H/w

Application software: Consists of stand alone programs that solve

a specific business need. Used to control business function in real
time.
Eg: point of sales , real time mfg. process control.

Engineering/scientific software: range from astronomy to

volcanology, from automotive stress analysis to space shuttle
orbital dynamics and from molecular biology to automated
manufacturing, CAD,SS
They are characterized by number crunching algorithms.
20
The changing nature of Software...
Embedded software: reside within a product / system and is
used to implement control features and functions for the
end-user and for the system itself. Eg: keypad control for
microwave oven. Washing machines, dash board displays in
car,
Product-line software: designed to provide a specific
capability for use by many different customers. Eg: DBMS,
multimedia, graphics

WebApps (Web applications): e-commerce

AI software: makes use of non numerical algorithms to solve

complex problems. Eg : Robotics, Neural networks, ..
21
SoftwareNew Categories
Ubiquitous computing wireless networks
Netsourcingthe www Web as a computing engine
Open sourcefree source code open to the
computing community
Also
Data mining
Grid computing

Software for nanotechnologies

22
What is the difference between software engineering
and computer science?

Computer Science Software Engineering

is concerned with
theory the practicalities of developing
fundamentals delivering quality software

Algorithms, date structures, SE deals with practical problems in

complexity theory, numerical methods complex software products

Computer science theories are currently insufficient to act

as a complete underpinning for software engineering,
BUT it is a foundation for practical aspects of software
engineering
23
Legacy Software
Why must it change?
software must be adapted to meet the needs of
new computing environments or technology.
software must be enhanced to implement new
business requirements.
software must be extended to make it
interoperable with other more modern systems
or databases.
software must be re-architected to make it
viable within a network environment.
24
Software Evolution (Lehman theory)
The Law of Continuing Change (1974): E-type systems must be continually
adapted else they become progressively less satisfactory.
The Law of Increasing Complexity (1974): As an E-type system evolves its
complexity increases unless work is done to maintain or reduce it.
The Law of Self Regulation (1974): The E-type system evolution process is self-
regulating with distribution of product and process measures close to normal.
The Law of Conservation of Organizational Stability (1980): The average
effective global activity rate in an evolving E-type system is invariant over product
lifetime.
The Law of Conservation of Familiarity (1980): As an E-type system evolves all
associated with it, developers, sales personnel, users, for example, must maintain
mastery of its content and behavior to achieve satisfactory evolution.
The Law of Continuing Growth (1980): The functional content of E-type systems
must be continually increased to maintain user satisfaction over their lifetime.
The Law of Declining Quality (1996): The quality of E-type systems will appear to
be declining unless they are rigorously maintained and adapted to operational
environment changes.
The Feedback System Law (1996): E-type evolution processes constitute multi-
level, multi-loop, multi-agent feedback systems and must be treated as such to
achieve significant improvement over any reasonable base.
25
Software Myths**
Are believable because they often have elements of truth , but Invariably lead to bad decisions,
therefore
Insist on reality as you navigate your way through software engineering

Management myths
1. A book with full of standards and procedures for building software will provide the
programmers with everything they need to know.
Reality: The book of standards may very well exist, but is it used?
Does it reflect modern s/w engg. Practice?
Is it complete? Is it adaptable? Is it stream lined to improve time to delivery while
still maintaining a focus on quality?
2. if behind the schedule, Add more programmers and catch up

Customer myths
A general description of objectives is enough to start coding
Requirements may change as the software is flexible

Practitioner myths
Once we write a working program, our task is accomplished: Reality is only 20-40 % is done
Quality assessment can be done only when the program is running
Working program is the only deliverable work product for a successful project
SE will make us create voluminous & unnecessary documentation & will invariable slow us
down 26
Why bother with Software Engineering?
Many very successful projects dont use software engineering, eg.
ID Softwares Doom
Early Microsoft
Sausages Hotdog

BUT they are often not repeatable

Many more projects fail because they dont use software engineering.
Failures occur because:
of the size of the project
key personnel have left
of failure to understand requirements

the project delivers, but lacks the required quality

of the introduction of new technology

of many, many other reasons

27
However
Important progress:
Ability to produce more complex software has increased

New technologies have led to new SE approaches

A better understanding of the activities involved in

software development
Effective methods to specify, design and implement

software have been developed

New notations and tools have been produced

28
What are the costs of software engineering?

Roughly 60% of costs are development costs, 40%

are testing costs. For custom software, evolution costs
often exceed development costs

Costs vary depending on the type of system being

developed and the requirements of system attributes
such as performance and system reliability

Distribution of costs depends on the development

model that is used

29
What are the attributes of good software?**
The software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable

Maintainability
Software must evolve to meet changing needs
Dependability
Software must be trustworthy
Efficiency
Software should not make wasteful use of system resources
Usability
Software must be usable by the users for which it was designed

30
What are the key challenges facing Software engineering?

Software engineering in the 21st century faces three key

challenges:
Legacy systems
Old, valuable systems must be maintained and updated
Heterogeneity
Systems are distributed and include
a mix of hardware and software
Delivery
There is increasing pressure
for faster delivery of software
31
Summary
The growing importance of software in todays economic
scenario.
Early ad-hoc approaches to software development and how
their inadequacy in the face of increased sophistication led
to software-crisis.
The realization that more structured and organized way of
doing things was needed, leading to birth of software
engineering.
The justification of using software engineering techniques
for development of software.
Definition of software engineering.
Brief elaboration of software engineering methods, tools
and procedures.
32