1

Why Software Engineering ?

❖ Change in nature & complexity of software

❖ Concept of one “guru” is over

❖ We all want improvement

Ready for change

2
 The Evolving Role of Software

❖ Software industry is in Crisis!

success
16%
failure
31%

over budget
53%

Source: The Standish Group International, Inc. (CHAOS research)

3
 The Evolving Role of Software

This is the Completed

Successful –
28%
SORRY state Late, over
budget, and/or
of Software with features
missing – 49%

Engineering
Cancelled –
Today! 23%

• Data on 28,000 projects

completed in 2000
4
 The Evolving Role of Software

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

5
 The Evolving Role of Software

Hw cost
Sw cost

1960 Year
1999
Relative Cost of Hardware and Software

6
 The Evolving Role of Software

• Unlike Hardware
– Moore’s law: processor speed/memory capacity doubles
every two years

7
 The Evolving Role of Software

Managers and Technical Persons are asked:

✓ Why does it take so long to get the program finished?

✓ Why are costs so high?

✓ Why can not we find all errors before release?

✓ Why do we have difficulty in measuring progress of software

development?

8
Factors Contributing to the Software Crisis

• Larger problems,

• Lack of adequate training in software engineering,

• Increasing skill shortage,

• Low productivity improvements.

9
 “No Silver Bullet”

The blame for software bugs belongs to:

• Software companies
• Software developers
• Legal system
• Universities

10
 What is software?

• Computer programs and associated

documentation

11
 What is software?

Programs

Operating
Documentation
Procedures

Software=Program+Documentation+Operating Procedures
Components of software

12
 Documentation consists of different types of manuals are
Formal Specification
Analysis Context-
/Specification Diagram
Data Flow
Diagrams
Flow Charts
Design
Entity-Relationship
Documentation Diagram
Manuals
Source Code Listings
Implementation Cross-Reference
Listing
Test Data
Testing
Test Results

List of documentation manuals

13
Documentation consists of different types of manuals are
System Overview
User Beginner’s Guide
Manuals Tutorial
Reference Guide

Operating
Procedures

Installation Guide
Operational
Manuals
System
Administration Guide

List of operating procedure manuals.

14
 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

15
 Software Product
Software product is a product designated for
delivery to the user
Source Documents
Codes Reports

Manuals
Objects Plans
plans
Codes
Data

Test Suites Test Results

Prototypes
prototypes

16
 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
17
 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.
18
 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

19
 Software Process

• Wrong motivations
• Insufficient commitment
Improved future state
Process improvement
begins
Initial state
state

Productivity

Do not quit here!

Learning curve

Time

20
 Software Characteristics:

✓Software does not wear

out.
Burn-in
phase Wear out
phase
Failure Intensity

Useful life
phase

Time
21
 Software Characteristics:
✓ Software is not manufactured
✓ Reusability of components
✓ Software is flexible

22
 Software Characteristics:
Comparison of constructing a bridge vis-à-vis writing a program.
Sr. Constructing a bridge Writing a program
No
1. The problem is well understood Only some parts of the problem are
understood, others are not
2. Every program is different and designed for
There are many existing bridges
special applications.
3. The requirement for a bridge typically do Requirements typically change during all
not change much during construction phases of development.
4. The strength and stability of a bridge can be Not possible to calculate correctness of a
calculated with reasonable precision program with existing methods.
5. When a bridge collapses, there is a When a program fails, the reasons are often
detailed investigation and report unavailable or even deliberately concealed.
6. Engineers have been constructing bridges Developers have been writing programs
for thousands of years for 50 years or so.
7. Materials (wood, stone,iron, steel) and Hardware and software changes rapidly.
techniques (making joints in wood, carving
stone, casting iron) change slowly.

23
The Changing Nature of Software

System Real
Software Time
Software

Engineering Embedded
and Scientific Software
Software

Web based Business

Software Software
Artificial
Intelligence Personal
Software Computer
Software

24
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 !

25
Software Myths (Management Perspectives)

Company has latest computers and state-of-

the-art software tools, so we shouldn’t worry
about the quality of the product.

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

26
Software Myths (Management Perspectives)

Addition of more software specialists, those

with higher skills and longer experience may
bring the schedule back on the track!

Unfortunately,
that may further delay the schedule!

27
Software Myths (Management Perspectives)

Software is easy to change

The reality is totally different.

28
 Software Myths (Management Perspectives)

Computers provide greater reliability than

the devices they replace

This is not always true.

29
Software Myths (Customer Perspectives)

A general statement of objectives is sufficient to get 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.

30
 Software Myths (Customer Perspectives)

Software with more features is better

software

Software can work right the first time

Both are only myths!

31
Software Myths (Developer Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!

32
 Software Myths (Developer Perspectives)

Software quality can not be assessed before

testing.

However, quality assessment techniques

should be used through out the
software development life cycle.

33
 Software Myths (Developer Perspectives)

The only deliverable for a software

development project is the tested code.

Tested code is only one of the deliverable!

34
 Software Myths (Developer Perspectives)

Aim is to develop working programs

Those days are over. Now objective is to

develop good quality maintainable
programs!

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

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

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

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

39
 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)

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

41
Role of Management in Software Development

Factors

People Project

Product Process

42
Role of Management in Software Development

People

Project Dependency 2 Product

4
Order

Process

43
44
 Case Study – 1

Browser - 1 Browser - 2
• Good Functionality. • Good Functionality.
• Need Good Internet Speed (min. 1 • Need At least Good Internet Speed
Mbps). (min. 1 Mbps).
• Also, Perform on < 1 Mbps with • Not Perform on < 1 Mbps with
Limited Functionality. Limited Functionality.
• Compromised with Services. • Not Compromised with Services.
45
Which Browser has Reliability?
 Case Study – 2

Online Video Player - 1 Online Video Player - 2

46
Which Online Video Player has Reliability?
 SoftwareReliability

Basic Concepts
There are three phases in the life of any hardware
component i.e., burn-in, useful life & wear-out.
In burn-in phase, failure rate is quite high initially, and it starts
decreasing gradually as the time progresses.

During useful life period, failure rate is approximately constant.

Failure rate increase in wear-out phase due to wearing

out/aging of components. The best period is useful life period. The
shape of this curve is like a “bath tub” and that is why it is
known as bath tub curve. The “bath tub curve” is given in Figure 1.

47
 SoftwareReliability

Figure.1: Bath tub curve of hardware reliability.

48
 SoftwareReliability
We do not have wear out phase in software. The expected curve for
software is given in Figure 2.

Figure. 2: Software reliability curve (failure rate versus time)

49
 SoftwareReliability
Software may be retired only if it becomes obsolete. Some of
contributing factors are given below:
✓ change in environment
✓ change in infrastructure/technology
✓ major change in requirements
✓ increase in complexity
✓ extremely difficult to maintain
✓ deterioration in structure of the code
✓ slow execution speed
✓ poor graphical user interfaces
50
 SoftwareReliability

What is Software Reliability?

“Software reliability means operational reliability. Who cares how

many bugs are in the program?

As per IEEE standard: “Software reliability is defined as the ability of

a system or component to perform its required functions under
stated conditions for a specified period of time”.

51
 SoftwareReliability

Software reliability is also defined as the probability that a software

system fulfills its assigned task in a given environment for a
predefined number of input cases, assuming that the hardware and
the inputs are free of error.

“It is the probability of a failure free operation of a program for a

specified time in a specified environment”.

52
 SoftwareReliability
▪ Failures and Faults

A fault is the defect in the program that, when executed under

particular conditions, causes a failure.

53
 SoftwareReliability

There are four general ways of characterising failure occurrences in

time:

1. time of failure,

2. time interval between failures,

3. cumulative failure experienced up to a given time,

4. failures experienced in a time interval.

54
 SoftwareReliability

Software Quality

Different people understand different meanings of quality like:

❖ conformance to requirements

❖ fitness for the purpose

❖ level of satisfaction

55
SoftwareReliability

Figure 3: Software quality attributes (cont.) 56

SoftwareReliability

Figure 3: Software quality attributes.

57
 SoftwareReliability
1 Reliability The extent to which a software performs its intended
functions without failure.
2 Correctness The extent to which a software meets its
specifications.
3 Consistency & The extent to which a software is consistent and give
precision results with precision.
4 Robustness The extent to which a software tolerates the
unexpected problems.
5 Simplicity The extent to which a software is simple in its
operations.
6 Traceability The extent to which an error is traceable in order to
fix it.
7 Usability The extent of effort required to learn, operate and
understand the functions of the software

58
 SoftwareReliability
8 Accuracy Meeting specifications with precision.
9 Clarity & The extent to which documents are clearly & accurately
Accuracy of written.
documentation
10 Conformity of The extent to which a software is in conformity of
operational operational environment.
environment
11 Completeness The extent to which a software has specified functions.
12 Efficiency The amount of computing resources and code required
by software to perform a function.
13 Testability The effort required to test a software to ensure that it
performs its intended functions.
14 Maintainability The effort required to locate and fix an error during
maintenance phase.

59
 SoftwareReliability
15 Modularity It is the extent of ease to implement, test, debug and
maintain the software.
16 Readability The extent to which a software is readable in order to
understand.
17 Adaptability The extent to which a software is adaptable to new
platforms & technologies.
18 Modifiability The effort required to modify a software
during maintenance phase.
19 Expandability The extent to which a software is expandable without
undesirable side effects.
20 Portability The effort required to transfer a program from one
platform to another platform.

Table1: Software quality attributes

60
 SoftwareReliability
▪ McCall Software Quality Model

Figure 4: Software quality factors. 61

 SoftwareReliability
i. Product Operation
Factors which are related to the operation of a product are
combined. The factors are:
▪ Correctness
▪ Efficiency
▪ Integrity
▪ Reliability
▪ Usability
These five factors are related to operational performance,
convenience, ease of usage and its correctness. These factors play
a very significant role in building customer’s satisfaction.
62
 SoftwareReliability
ii. Product Revision
The factors which are required for testing & maintenance are
combined and are given below:

▪ Maintainability
▪ Flexibility
▪ Testability

These factors pertain to the testing & maintainability of software.

They give us idea about ease of maintenance, flexibility and testing
effort. Hence, they are combined under the umbrella of product
revision.

63
 SoftwareReliability
iii. Product Transition
We may have to transfer a product from one platform to an other
platform or from one technology to another technology. The factors
related to such a transfer are combined and given below:

▪ Portability
▪ Reusability
▪ Interoperability

64
 SoftwareReliability
1 Operability The ease of operation of the software.
2 Training The ease with which new users can use the
system.
3 Communicativeness The ease with which inputs and outputs can be
assimilated.
4 I/O volume It is related to the I/O volume.
5 I/O rate It is the indication of I/O rate.
6 Access control The provisions for control and protection of the
software and data.
7 Access audit The ease with which software and data can be
checked for compliance with standards or other
requirements.
8 Storage efficiency The run time storage requirements of the software.
9 Execution efficiency The run-time efficiency of the software.

65
 SoftwareReliability
10 Traceability The ability to link software components to
requirements.
11 Completeness The degree to which a full implementation of the
required functionality has been achieved.
12 Accuracy The precision of computations and output.
13 Error tolerance The degree to which continuity of operation is ensured
under adverse conditions.
14 Consistency The use of uniform design and implementation
techniques and notations throughout a project.
15 Simplicity The ease with which the software can be understood.
16 Conciseness The compactness of the source code, in terms of lines
of code.
17 Instrumentation The degree to which the software provides for
measurements of its use or identification of errors.

66
 SoftwareReliability
18 Expandability The degree to which storage requirements or
software functions can be expanded.
19 Generability The breadth of the potential application of software
components.
20 Self- The degree to which the documents are self
descriptiveness explanatory.
21 Modularity The provision of highly independent modules.
22 Machine The degree to which software is dependent on its
independence associated hardware.
23 Software system The degree to which software is independent of its
independence environment.
24 Communication The degree to which standard protocols and
commonality interfaces are used.
25 Data commonality The use of standard data representations.

Table: Software quality criteria

67
 SoftwareReliability
▪ Boehm Software Quality Model

Figure: The Boehm software quality model. 68

 SoftwareReliability
Characteristic/ Short Description of the Characteristics and the
Attribute concerns Addressed by Attributes
Functionality Characteristics relating to achievement of the basic
purpose for which the software is being engineered
• Suitability The presence and appropriateness of a set of functions for
specified tasks
• Accuracy The provision of right or agreed results or effects
• Interoperability Software’s ability to interact with specified systems
• Security Ability to prevent unauthorized access, whether accidental
or deliberate, to program and data.
Reliability Characteristics relating to capability of software to
maintain its level of performance under stated conditions
for a stated period of time
• Maturity Attributes of software that bear on the frequency of failure
by faults in the software

69
 SoftwareReliability
• Fault tolerance Ability to maintain a specified level of performance in cases
of software faults or unexpected inputs
• Recoverability Capability and effort needed to reestablish level of
performance and recover affected data after possible
failure.
Usability Characteristics relating to the effort needed for use, and on
the individual assessment of such use, by a stated implied
set of users.
• Understandability The effort required for a user to recognize the logical
concept and its applicability.
• Learnability The effort required for a user to learn its application,
operation, input and output.
• Operability The ease of operation and control by users.
Efficiency Characteristic related to the relationship between the level
of performance of the software and the amount of
resources used, under stated conditions.

70
 SoftwareReliability
• Time behavior The speed of response and processing times and
throughout rates in performing its function.
• Resource The amount of resources used and the duration of such
behavior use in performing its function.
Maintainability Characteristics related to the effort needed to make
modifications, including corrections, improvements or
adaptation of software to changes in environment,
requirements and functions specifications.
• Analyzability The effort needed for diagnosis of deficiencies or causes
of failures, or for identification of parts to be modified.
• Changeability The effort needed for modification, fault removal or for
environmental change.
• Stability The risk of unexpected effect of modifications.

• Testability The effort needed for validating the modified software.

71
 SoftwareReliability

Portability Characteristics related to the ability to transfer the

software from one organization or hardware or software
environment to another.
• Adaptability The opportunity for its adaptation to different specified
environments.
• Installability The effort needed to install the software in a specified
environment.
• Conformance The extent to which it adheres to standards
or conventions relating to portability.
• Replaceability The opportunity and effort of using it in the place of other
software in a particular environment.

Table: Software quality characteristics and attributes.

72
 SoftwareReliability
▪ Capability Maturity Model
It is a strategy for improving the software process, irrespective of the
actual life cycle model used.

Figure: Maturity levels of CMM

73
 SoftwareReliability

Maturity Levels:

✓ Initial (Maturity Level 1)

✓ Repeatable (Maturity Level 2)

✓ Defined (Maturity Level 3)

✓ Managed (Maturity Level 4)

✓ Optimizing (Maturity Level 5)

74
 SoftwareReliability

Maturity Level Characterization

Initial Adhoc Process

Repeatable Basic Project Management

Defined Process Definition

Managed Process Measurement

Optimizing Process Control

Figure: The five levels of CMM

75
Thanks

76