PAN African eNetwork Project

Post Graduate Diploma (IT)

Software Engineering
Semester - I

Mr. O.P.Sangwan
Copyright Amity University
1

Faculty Profile

MSc (Computer Science)

CCNA (Cisco certified Network Associate)
CCNA (Cisco certified )
Ph D (CSE) (Thesis Submitted)

Publications
International/ National Journal = 8 (including ACM, ISJKE)
International/ National Conference = 9 (including Springer)

Conference/ Workshop Attended

Bangkok
Vietnam

Copyright Amity University

Patents filed provisionally

ANN model
Area of specialization
Software Engineering
Artificial Intelligence
Experience
5 + teaching
1 research
Member
Cisco (Academic Council, USA)
Cisco (Learning Institute, USA)

Copyright Amity University

Why We Need Software

Engineering?
Change in nature & complexity of software
Concept of one guru is over
We all want improvement

Copyright Amity University

Why Software Engineering?

Software development is hard !
Important to distinguish easy systems (one
developer, one user, experimental use only) from hard
systems (multiple developers, multiple users, products)
Experience with easy systems is misleading
One person techniques do not scale up
Analogy with bridge building:
Over a stream = easy, one person job
Over River Severn ?
(the techniques

Copyright Amity University

do not scale)

Software Crisis!

Software Crises
As per the IBM report, 31%of the
project get cancelled before they are
completed, 53% over-run their cost
estimates by an average of 189% and
for every 100 projects, there are 94
restarts.

Copyright Amity University

Factors Contributing Software Crises

Larger problems,
Lack of adequate training in software
engineering
Increasing skill shortage,
Low productivity improvements

Copyright Amity University

Some Software failures

Ariane 5
It took the European Space Agency 10 years
and $7 billion to produce Ariane 5, a giant
rocket capable of hurling a pair of three-ton
satellites into orbit with each launch and
intended to give Europe overwhelming
supremacy in the commercial space business.

The rocket was destroyed after 39 seconds of

its launch, at an altitude of two and a half
miles along with its payload of four expensive
and uninsured scientific satellites.

Some Software failures

When the guidance systems own
computer tried to convert one piece
of data the sideways velocity of the
rocket from a 64 bit format to a 16
bit format; the number was too big,
and an overflow error resulted after
36.7 seconds. When the guidance
system shutdown, it passed control
to an identical, redundant unit, which
was there to provide backup in case
of just such a failure. Unfortunately,
the second unit, which had failed in
the
identical
manner
a
few
milliseconds before.

10

Some Software
failures
Y2K problem:
It was simply the ignorance about the
adequacy or otherwise of using only
last two digits of the year.

The 4-digit date format, like 1964, was

shortened to 2-digit format, like 64.

11

Some Software failures

The Patriot Missile
o First time used in Gulf war
o Used as a defense from Iraqi Scud
missiles
o Failed several times including one that
killed 28 US soldiers in Dhahran, Saudi
Arabia
Reasons:
A small timing error in the systems 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

The Space Shuttle
Part of an abort scenario
for the Shuttle requires
fuel dumps to lighten the
spacecraft. It was during
the second of these
dumps that a (software)
crash occurred.
...the fuel management
module,
which
had
performed one dump
and successfully exited,
restarted when recalled
for the second fuel

13

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 fixed important security holes.

14

What is software?
It is defined as Computer programs
and associated documentation

15
Copyright Amity University

What is software?
Programs

Documenta
tion

Operating
Procedures

Software=Program+Documentation+Operating Procedures
Components of software
16

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

Documentation consists of different types of

Formal
manuals are
Specification
Analysis
/
Specificatio
n
Design
Documentat
ion
Manuals
Implementati
on
Testing

ContextDiagram
Data Flow
Diagrams
Flow Charts
EntityRelationship
Diagram
Source Code
Listings
CrossReference
Listing
Test Data
Test Results

List of documentation manuals

18

Documentation consists of different types

System
of manuals are
Overview
User
Manuals

Beginners
Guide Tutorial

Reference
Guide
Operatin
g
Procedu
res
Operation
al
Manuals

Installation
Guide

System
Administration
Guide
List of operating procedure manuals.
19

What is a software
process?
A set of activities whose goal is the
development or evolution of software
Generic activities in all software
processes are:
Specification - what the system should
do and its development constraints
Development - production of the
software system
Validation - checking that the software
is what the customer wants
Evolution - changing the software in
response to changing demands

What is a software process model?

A simplified representation of a software
process,
presented from a specific perspective
Examples of process perspectives:
Workflow perspective represents inputs, outputs and
dependencies
Data-flow perspective represents data transformation
activities
Role/action perspective represents the roles/activities of the
people involved in software
process

Generic process models

Waterfall
Evolutionary development
Formal transformation
Integration from reusable components

Software Product
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

22

What is software engineering?

Software engineering is an engineering discipline which is
concerned with all aspects of software production
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
use the resources available
23
Copyright Amity University

What is software
engineering?

At the first conference on software engineering in 1968, Fritz Bauer

defined software engineering as The establishment and use of sound
engineering principles in order to obtain economically developed
software that is reliable and works efficiently on real machines.
Stephen Schach defined the same as A discipline whose aim is the
production of quality software, software that is delivered on time, within
budget, and that satisfies its requirements.
Both the definitions are popular and acceptable to majority. However,
due to increase in cost of maintaining software, objective is now shifting
to produce quality software that is maintainable, delivered on time,
within budget, and also satisfies its requirements.
24

Software Process
The software process is the way in which we
produce software.
Why is it difficult to improve software
process ?
Not enough time
Lack of knowledge
25

Software Process
Wrong motivations
Insufficient commitment
Initial
state
state

Process
improvement
begins

Improved future
state

Productivity

Do not quit here!

Learning curve

Time
26

Software Characteristics:
Software does not wear out.

Failure Intensity

Burn-in
phase
Useful life
phase

Wear out
phase

Time
27

Software Characteristics:

Software is not manufactured

Reusability of components

Software is flexible

28

Software Characteristics:
Comparison of constructing a bridge vis--vis writing a program.
Sr.
No
1.
2.
3.
4.
5.
6.
7.

Constructing a bridge
The problem is well understood
There are many existing
bridges
The requirement for a bridge
typically do not change much
during
construction
The
strength
and stability of a
bridge can be calculated with
reasonable
precision
When a bridge
collapses, there is
a detailed investigation and
report
Engineers have been constructing
bridges for thousands of years
Materials (wood, stone,iron, steel)
and techniques (making joints in
wood, carving stone, casting iron)
change slowly.

Writing a program
Only some parts of the problem are
understood, others are not
Every program is different and
designed for special applications.
Requirements
typically
change
during all phases of development.
Not possible to calculate correctness
of a program with existing methods.
When a program fails, the reasons
are often unavailable or even
deliberately
Developers concealed.
have been writing
programs for 50 years or so.
Hardware and software changes
rapidly.
29

Software Applications
System
Softwa
re

Real
Time
Softwa
re

Engineeri
Embedd
ng and
ed
Scientific
Software
Software
Web
Busine
based
ss
Software
Softwa
Artificial
re
Person
Intelligen
al
ce
Software Comput
er
Softwar
e

30

The Changing Nature of

Software
Trend has emerged
to provide source code
to the customer and organizations.
Software where source codes are available
are known as open source software.
Examples
Open source software: LINUX, MySQL, PHP, Open office, Apache
webserver etc.

31

Software Myths (Management

Perspectives
Management may
be confident about) good
standards and clear procedures of the company.

But the taste of any food item

is in the eating;
not in the Recipe !

32
Copyright Amity University

Software Myths (Management

Company has
latest computers
Perspectives
) and stateof-the-art software tools, so we shouldnt
worry about the quality of the product.

The infrastructure is
only one of the several factors
that determine the quality
of the product!

33
Copyright Amity University

Software Myths (Management

Perspectives
) those with
Addition of more
software specialists,
higher skills and longer experience may bring the
schedule back on the track!

Unfortunately,
that may further delay the schedule!

34
Copyright Amity University

Software Myths
(Management Perspectives)

Software is easy to change

The reality is totally different.

35

Software Myths
(Management Perspectives)
Computers
provide
greater
reliability than the devices they
replace
This is not always true.

36

Software Myths (Customer

A general statement
of objectives is )
sufficient to get
Perspectives
started with the development of software. Missing/vague
requirements can easily be incorporated/detailed out as
they get concretized.

If we do so, we are heading

towards a disaster.

37
Copyright Amity University

Software Myths (Customer

Perspectives
Software with
more features ) is
better software

Software can work right the first time

Both are only myths!

38

Software Myths (Developer

Perspectives)
Once the software is demonstrated, the job is
done.

Usually, the problems just begin!

39
Copyright Amity University

Software Myths (Developer

Software quality
can not be assessed
Perspectives
) before
testing.

owever, quality assessment techniques

should be used through out the
software development life cycle.

40
Copyright Amity University

Software Myths (Developer

The only Perspectives
deliverable for )a software
development project is the tested code.

sted code is only one of the deliverable!

41
Copyright Amity University

Software Myths (Developer

Perspectives
)
Aim is to develop
working programs

Those days are over. Now objective is to

develop good quality maintainable
programs!

42

Some Terminologies

Deliverables and Milestones

Different deliverables are generated during software development. The

examples are source code, user manuals, operating procedure manuals
etc.
The milestones are the events that are used to ascertain the status of the
project. Finalization of specification is a milestone. Completion of design
documentation is another milestone. The milestones are essential for
project planning and management.

43

Some Terminologies

Product and Process

Product: What is delivered to the customer, is called a product. It may

include source code, specification document, manuals, documentation
etc. Basically, it is nothing but a set of deliverables only.

Process: Process is the way in which we produce software. It is the

collection of activities that leads to (a part of) a product. An efficient
process is required to produce good quality products.
If the process is weak, the end product will undoubtedly suffer, but an
obsessive over reliance on process is also dangerous.
44

Some Terminologies

Measures, Metrics and Measurement

A measure provides a quantitative indication of the extent, dimension,

size, capacity, efficiency, productivity or reliability of some attributes of
a product or process.

Measurement is the act of evaluating a measure.

A metric is a quantitative measure of the degree to which a system,
component or process possesses a given attribute.

45

Some Terminologies

Software Process and Product Metrics

Process metrics quantify the attributes of software development process

and environment;
whereas product metrics are measures for the software product.
Examples
Process metrics: Productivity, Quality, Efficiency etc.
Product metrics: Size, Reliability, Complexity etc.

46

Some Terminologies

Productivity and Effort

Productivity is defined as the rate of output, or production per unit of

effort, i.e. the output achieved with regard to the time taken but
irrespective of the cost incurred.

Hence most appropriate unit of effort is Person Months (PMs), meaning

thereby number of persons involved for specified months. So, productivity
may be measured as LOC/PM (lines of code produced/person month)

47

Some Terminologies

Module and Software Components

There are many definitions of the term module. They range from a
module is a FORTRAN subroutine to a module is an Ada Package, to
Procedures and functions of PASCAL and C, to C++ Java classes to
Java packages to a module is a work assignment for an individual
developer. All these definition are correct. The term subprogram is also
used sometimes in place of module.

48

Some Terminologies
An independently deliverable piece of functionality providing access to
its services through interfaces.

A component represents a modular, deployable, and replaceable part

of a system that encapsulates implementation and exposes a set of
interfaces.

49

Some Terminologies

Generic and Customized Software Products

Generic products are developed for anonymous customers. The target is

generally the entire world and many copies are expected to be sold.
Infrastructure software like operating system, compilers, analyzers, word
processors, CASE tools etc. are covered in this category.

The customized products are developed for particular customers. The

specific product is designed and developed as per customer
requirements. Most of the development projects (say about 80%)come
under this category.

50

Role of Management in Software

Development Factors

People

Project
Product

Process

51

Role of Management in Software

People
Development
1

Project

Depende
ncy

Product

Order

3
Process
52

Software Development Life Cycle

Requirement Analysis &
Specification
Design
Coding
Testing
Maintenance & Operations

Copyright Amity University

Software Life Cycle Model

Waterfall Model
Prototype Model
Iterative Enhancement Model
Evolutionary Development Model
Spiral Model
Rapid Application Development (RAD) Model

Copyright Amity University

Waterfall Model
Linear Sequential Model
Classical Life Cycle Model

Requirement

Design
Implementation
andunittesting
Integr ationand
systemtesting

Operation &
Maintenance

Copyright Amity University

Problems with the Waterfall Model

It is difficult to define all requirements at the beginning of
a project
This model is not suitable for accommodating any
change
A working version of the system is not seen until late in
the projects life
It does not scale up well to large projects
Real projects are rarely sequential

Copyright Amity University

Prototype Model
It is also known as throw away model.
It is developed as per the current available
requirement.
The code for the prototype model is
thrown away; however the experience
gathered from developing the prototype
helps in developing the actual system.

Copyright Amity University

Prototype Model

Linear model
Rapid

58
Copyright Amity University

Iterative Enhancement Model

Requirements
specification

Architectural
design

Detailed

design

Implementation
and unit testing

Integration
and testing

Operation and
Maintenance
59

Evolutionary Process Models

Evolutionary
process
model
resembles
iterative
enhancement model. The same phases as defined for the
waterfall model occur here in a cyclical fashion. This model
differs from iterative enhancement model in the sense that
this does not require a useable product at the end of each
cycle. In evolutionary development, requirements are
implemented by category rather than by priority.
This model is useful for projects using new technology that
is not well understood. This is also used for complex projects
where all functionality must be delivered at one time, but the
requirements are unstable or not well understood at the
beginning.
60

Evolutionary Development Model

Concurr ent
activities

Outline
description

Copyright Amity University

Specification

Initial
version

Development

Intermediate
versions

Validation

Final
version

Spiral Model
Phases of Spiral Model
Planning: Determination of objectives,
alternatives and constraints.
Risk Analysis: Analyze alternatives and
attempts to indentify and resolve the risks
involved
Development: Product development and
testing product.
Assessment: Customer evaluation
Copyright Amity University

Spiral Model

63

Rapid Application Development (RAD) Model

Build a rapid prototype

Give it to user for evaluation & obtain feedback

Prototype is refined
With active participation of users

Requirement
s
Planning

User
Description

Construction

Cut over

64

Rapid Application Development (RAD) Model

Not an appropriate model in the absence of user

participation.
Reusable components are required to reduce
development time.
Highly specialized & skilled developers are required
and such developers are not easily available.

65

Multiple Choice Questions

Note: Select most appropriate answer of the following questions:

1.1 Software is
(a) Superset of programs
(b) subset of
programs
(c) Set of programs
(d) none of the above
1.2 Which is NOT the part of operating procedure manuals?
(a) User manuals
(b) Operational manuals
(c) Documentation manuals
(d) Installation
manuals
1.3 Which is NOT a software characteristic?
(a) Software does not wear out
(b) Software is
flexible
(c) Software is not manufactured
(d) Software is
1.4 always
Productcorrect
is
(a) Deliverables
(b) User expectations
(c) Organization's effort in development
(d) none of
the above
1.5 To produce a good quality product, process should be
(a) Complex
(b) Efficient
(c) Rigorous
(d) none of the above
66

Multiple Choice Questions

Note: Select most appropriate answer of the following questions:

1.6 Which is not a product metric?

(a) Size
(c) Productivity

(b) Reliability
(d) Functionality

1.7 Which is NOT a process metric?

(a) Productivity
(b) Functionality
(c) Quality
(d) Efficiency
1.8 Effort is measured in terms of:
(a) Person-months
(c) Persons

(b) Rupees
(d) Months

1.9 UML stands for

(a) Uniform modeling language (b) Unified modeling
language
(c) Unit modeling language
(d) Universal
1.10modeling
An independently
language deliverable piece of functionality providing
access to
its services through interface is called
(a)
Software
measurement
(b)
Software
67
composition

Thank You
Please forward your query
To: sangwan_op@aiit.amity.edu
CC: manoj.amity@panafnet.com

68