1

2
Assessment/ Examination Scheme:

Theory L/T (%) Lab/Practical/Studio (%) Total

80% 20% 100%

3
 Theory Assessment (L&T):
Continuous Assessment/Internal End Term
Assessment Examination
Components Mid Term HA Viv Attendanc
(Drop down) Exam a e

Weightage (%) 10 8 7 5 70

4
 Lab/ Practical/ Studio Assessment:
Continuous End Term
Assessment/Internal Examination
Assessment
30
Components Lab Lab Viv Attendan
Performance File a ce
5
Weightage (%) 10 10 5 5 70
 Text Reading:

1. K. K. Aggarwal & Yogesh Singh, “Software Engineering”, 2nd Ed, New Age
International, 2005.
2. R. S. Pressman, “Software Engineering – A practitioner’s approach”, 5th Ed.,
McGraw Hill Int. Ed., 2001.
3. Rajib Mall, Fundamentals of Software Engineering, Prentice Hall India.
4. Ian Summerville, Software Engineering, Addison-Wesley.
References:

5. R. Fairley, “Software Engineering Concepts”, Tata McGraw Hill, 1997. 6

6. P. Jalote, “An Integrated approach to Software Engineering”, Narosa, 1991.
Module I Introduction

S. NO Topic
1 Software life cycle models: Waterfall
2 Software life cycle models: Prototype

3 Software life cycle models: Evolutionary and Spiral

models

4 Agile Methodology

5 Overview of Quality Standards like ISO 9001,

SEI-CMM

7
8
 What is software?

• Computer programs and

associated documentation

9
What is software?

10
 What is software?

Programs

Documentation Operating
Procedures

Software=Program+Documentation+Operating
Procedures Components of software

11
What is software

12
What is Engineering

13
Software Engineering

14
IEEE Defination

15
What is software

16
Types of software

17
Types of software

18
Types of software

19
Types of software

20
Types of software

21
Difference between H/W and S/W

22
 Difference between H/W and S/W

Software is set of Programs, which we can not touch

23
Difference between H/W and S/W

24
Difference between H/W and S/W

25
Characteristics of software

26
Characteristics of software

27
Characteristics of software

28
Principles of S/W Engineering

29
Principles of S/W Engineering

30
Principles of S/W Engineering

31
Principles of S/W Engineering

32
Principles of S/W Engineering

33
Principles of S/W Engineering

34
Principles of S/W Engineering

35
 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 sold to a range of different
be customers
–Bespoke (custom) - developed for a single customer
according to their specification

36
 Software Product
Software product is a product designated for
delivery to the user
Source code Documents

Reports

Manual
Object Code
plans
plans

Data

Test Suit Test Results prototypes

prototypes

37
 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

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

Productivity

Do not quit here!

Learning curve

Time

39
 Software
Characteristics:
✓Software does not wear
out.
Burn-in
phase Wear out
phase
Failure Intensity

Useful life
phase

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

41
 Software Characteristics:
Comparison of constructing a bridge vis-à-vis writing a
program. Constructing a bridge
Sr Writing a program
.
N
o
1. The problem is well understood Only some parts the problem are
of
understood, others are
not
2. There are many existing bridges Every program is different and designed
for special applications.
3. The requirement for a bridge typically Requirements typically change
do not change much during construction
during all phases of
development.
4. The strength and stability of a bridge can Not possible to calculate correctness of a
be calculated with reasonable precision
program with existing methods.
5. When a bridge collapses, is a When a program fails, the reasons are
there detailed often unavailable or even deliberately
investigation and report concealed.
6. Engineers have been constructing Developers have been writing
bridges for thousands of years programs for 50 years or so. 42

7. Materials (wood, stone,iron, steel) and Hardware and software changes rapidly.
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

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

44
 Software Myths
(Management
Management mayPerspectives
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 !

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

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

47
 Software Myths (Management
Perspectives)
Software is easy to change

The reality is totally different.

48
 Software Myths (Management
Perspectives)

Computers provide greater reliability

than the devices they replace

This is not always true.

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

50
 Software Myths (Customer
Perspectives)
Software with more features is
better software

Software can work right the first time

Both are only myths!

51
 Software Myths (Developer
Perspectives)
Once the software is demonstrated, the job is done.

Usually, the problems just begin!

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

53
 Software Myths (Developer
Perspectives)
The only deliverable for a
software development project is the tested
code.

Tested code is only one of the deliverable!

54
 Software Myths (Developer
Perspectives)
Aim is to develop working programs

Those days are over. Now objective is to

develop good quality maintainable
programs!

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

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

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

58
 Some Terminologies
➢ Software Process and Product Metrics

Process metrics quantify the attributes of software

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

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

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

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

62
 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.
63
Role of Management in Software
Development
Factors

People
Project

Product Process

64
Role of Management in Software
Development People

Project 4 Dependency Product

2
Order

Process

65
SDLC

66
SDLC

67
SDLC

68
 Software Life Cycle M o d e l s

“The period of time that starts when a software product is conceived

and ends when the product is no longer available for use. The
software life cycle typically includes a requirement phase, design
phase, implementation phase, test phase, installation and check out
phase, operation and maintenance phase, and sometimes retirement
phase”.

3
 Build & Fix Model

❖ Product is constructed without

specifications or any attempt at
design
Build
❖ Adhoc approach and not
Code
well defined

❖ Simple two phase model Fix

4
 Build & Fix Model

❖ Suitable for small programming exercises of 100 or 200

lines

❖ Unsatisfactory for software for any reasonable size

❖ Code soon becomes unfixable & unenhanceable

❖ No room for structured design

❖ Maintenance is practically not possible

5
Water fall model

72
Water Fall Model

73
Water fall model

74
 Waterfall Model

Requirement This model is named

Analysis & Specification
model” because its
“waterfall
representation resembles a cascade
diagrammatic
Design waterfalls.
of

Implementatio
n and unit
testing
Integr ation
and system
testing

Operation
and
maintenance

6
Water fall model

76
Water fall model

77
Water fall model

78
Water fall model

79
Waterfall Model

80
Waterfall Model

81
Waterfall Model

82
Water fall Model

83
Water fall Model

84
Water Fall Model

85
Water Fall model

86
Waterfall model

87
Logical Design

88
Water Fall Model

89
Water Fall Model

90
Water Fall Model

91
Waterfall model

92
Advantage of water fall model

93
 Waterfall Model

Problems of waterfall model

i. It is difficult to define all requirements at the beginning of
a project
ii. This model is not suitable for accommodating any change
iii. A working version of the system is not seen until late
in the project’s life

iv. It does not scale up well to large projects.

v. Real projects are rarely sequential.

8
 Incremental Process M o d e l s

They are effective in the situations where requirements are

defined precisely and there is no confusion about the
functionality of the final product.

After every cycle a useable product is given to the customer.

Popular particularly when we have to quickly deliver a limited

functionality system.

9
 Iterative Enhancement Model

This model has the same phases as the waterfall model, but with
fewer restrictions. Generally the phases occur in the same order
as in the waterfall model, but they may be conducted in several
cycles. Useable product is released at the end of the each cycle,
with each release providing additional functionality.

✓ Customers and developers specify as many requirements as

possible and prepare a SRS document.
✓ Developers and customers then prioritize these requirements
✓ Developers implement the specified requirements in one or
more cycles of design, implementation and test based on the
defined priorities.

10
Iterative Enhancement Model

97
Iterative Enhancement Model

98
Iterative Enhancement Model

99
Iterative Enhancement Model

100
Iterative Enhancement Model

101
Evolutionary development

102
Evolutionary development

103
Prototype Model

104
Prototype Model

105
Prototype Model

106
Prototype Model

107
 Prototyping Model

➢ The prototype may be a usable program but is not suitable as

the final software product.

➢ The code for the prototype is thrown away. However

experience gathered helps in developing the actual system.

➢ The development of a prototype might involve extra cost, but

overall cost might turnout to be lower than that of an
equivalent system developed using the waterfall model.

17
Prototype Model

109
The Rapid Application Development (RAD)
Model

110
 The Rapid Application Development (RAD)
Model

o Build a rapid prototype

o Give it to user for evaluation & obtain
feedback
o Prototype is refined

With active participation of users

Requirements User Construction Cut over

Planning Description

13
The Rapid Application Development
(RAD) Model

112
The Rapid Application Development
(RAD) Model

113
The Rapid Application Development
(RAD) Model

114
The Rapid Application Development
(RAD) Model

115
The Rapid Application Development
(RAD) Model

116
The Rapid Application Development
(RAD) Model

117
The Rapid Application Development
(RAD) Model

118
The Rapid Application Development
(RAD) Model

119
The Rapid Application Development
(RAD) Model

120
The Rapid Application Development
(RAD) Model

121
The 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.

14
 Spiral Model

Models do not deal with uncertainly which is inherent to software

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

The result is the spiral model, which was presented in 1986.

19
Risk Involved in project

124
Spiral Model

125
Spiral Model

20
 Spiral Model
▪ An important feature of the spiral model is that each phase is
completed with a review by the people concerned with the
project (designers and programmers)
▪ The advantage of this model is the wide range of options to
accommodate the good features of other life cycle models.
▪ It becomes equivalent to another life cycle
appropriate
model in situations.
The spiral model has some difficulties that need to be resolved
before it can be a universally applied life cycle model. These
difficulties include lack of explicit process guidance in
determiningconstraints, alternatives; relying on risk assessment
objectives,
expertise; and provides more flexibility than required for many
applications.
22
Spiral Model

128
 Different phases of spiral model

Phase 1:Objectives determination and identify alternative

solutions

129
 Different phases of spiral model

Phase 2: Identify and resolve Risks

130
 Different types of risk involved.

1. Schedule Risk
2. Budget Risk
3. Operational Risks
4. Technical Risks
5. Programmatic
Risks

131
 Different phases of spiral model

Phase 3: Develop next version of the Product

132
 Different phases of spiral model

Phase 4: Review and plan for the next Phase

133
 Advantage of spiral model

1.Software is produced early in the software life cycle.

2.Risk handling is one of important advantages of the Spiral
model, it is best development model to follow due to the risk
analysis and risk handling at every phase.
3.Flexibility in requirements. In this model, we can easily change
requirements at later phases and can be incorporated accurately.
Also, additional Functionality can be added at a later date.
4.It is good for large and complex projects.
5.It is good for customer satisfaction. We can involve customers in
the development of products at early phase of the software
development. Also, software is produced early in the software life
cycle.
6.Strong approval and documentation control.
7.It is suitable for high risk projects, where business needs may be
unstable. A highly customized product can be developed using 134
 Disadvantage of spiral model

1.It is not suitable for small projects as it is expensive.

2.It is much more complex than other SDLC models.
Process is complex.
3.Too much dependable on Risk Analysis and requires
highly specific expertise.
4.Difficulty in time management. As the number of phases is
unknown at the start of the project, so time estimation is
very difficult.
5.Spiral may go on indefinitely.
6.End of the project may not be known early.
7.It is not suitable for low risk projects.
8.May be hard to define objective, verifiable milestones.
Large numbers of intermediate stages require excessive
documentation.
135
Agile Methodology

136
Agile Methodology

137
Agile Methodology

138
Agile Methodology

Process is complete if they deliver

good quality product to the
customer and the customer is
happy.

139
Agile Methodology

140
Agile Methodology

141
Agile Methodology

142
Agile Methodology

143
Agile Methodology

144
Agile Methodology

145
 Agile Methodology

Role and responsibilities are

Role and responsibilities are not
clear in Scrum methodology
clear in Kanban methodology

146
Agile Methodology

Product is delivered
as per customer
needs 147
 Agile Methodology
Both KanBan and Scrum uses the pull technique to
allocate new tasks but used in two different ways

148
Agile Methodology

149
Agile VS. Waterfall

150
Agile VS. Waterfall

151
Agile VS. Waterfall

152
Agile VS. Waterfall

153
Agile VS. Waterfall

154
Agile VS. Waterfall

Changes can not be

incorporated.

155
Agile VS. Waterfall

156
Agile VS. Waterfall

After each iteration customer

157
feedback is involved.
Agile VS. Waterfall

158
Agile VS. Waterfall

159
Agile VS. Waterfall

160
Agile VS. Waterfall

There could be one of the case that customer is

happy with this version and we need not to extend it
to the newer version

161
Agile VS. Waterfall

162
Selection of a Life Cycle Model

Can lead to successful

product

Can lead to un successful

product

163
Selection of a Life Cycle Model

164
 Selection of a Life Cycle Model

Selection of a model is based on:

a) Requirements

b) Development team
c) Users
d) Project type and associated
risk

36
 Based On Characteristics Of Requirements

Requirements Waterfall Prototype Iterative Evolutionar Spiral RAD

enhancemen y
t developmen
t
Are requirements
easily Yes No No No No Yes
understandable and
defined?
Do we change
requirements No Yes No No Yes No
quite often?

Can we define
requirements Yes No Yes Yes No Yes
early in the
cycle?

Requirements are
indicating a No Yes Yes Yes Yes No
complex system to
be built
37
 Based on Development Team

Developme Waterfall Prototype Iterative Evolutionar Spiral RAD

enhancemen y
nt t developmen
team t

Less experience
on similar No Yes No No Yes No
projects?

Less domain
knowledge (new Yes No Yes Yes Yes No
to the
technology)
Less experience
on tools to be Yes No No No Yes No
used

Availability of
No No Yes Yes No Yes
training if
required

38
 Based On User’s Participation

Involvement Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement development
of Users

User involvement
in all phases No Yes No No No Yes

Limited user
participation Yes No Yes Yes Yes No

User have no
previous experience No Yes Yes Yes Yes No
of participation in
similar projects

Users are experts of

problem domain No Yes Yes Yes No Yes

39
 Based On Type Of Project With Associated Risk

Project type Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement development
and risk

Project is the
enhancement of the No No Yes Yes No Yes
existing system
Funding is stable
for the project Yes Yes No No No Yes

High reliability
requirements No No Yes Yes Yes No

Tight project No Yes Yes Yes Yes Yes

schedule
Use of reusable
components No Yes No No Yes Yes
Are resources
(time, money, No Yes No No Yes No
people etc.) scare?

40
ISO 9001

170
ISO

171
 ISO 9001
• ISO 9001 is the internationally recognized
Quality Management System (QMS)
standard that can benefit any size
organization.

172
ISO 9001

173
ISO 9001

174
ISO family

175
ISO family

176
ISO 9001

177
How ISO 9001 helps

• It helps you to identify

present customer needs
and identify and assess
future requirement

• It helps you to
measure client
satisfaction

178
 How ISO 9001 helps

• Helps you ensure all

regulatory requirements
are met for your
products and services
• Requires you to
communicate
regulatory requirements
to your employees and
interested parties

179
How ISO 9001 helps
• It makes you assess
risks and identify
opportunities for your
business
• It makes you
continually examine
opportunities for
improvement
• You need to put in
place the operational
controls to effectively
manage and measure
your performance 180
 How ISO 9001 helps

• Demonstrates your
commitment to quality
products and services
• It is the most widely
recognized international
management system
standard
• Helps safeguard the
quality of your products
and services
181
 How ISO 9001 helps
• Requires you to identify al
internal and external
stakeholders relevant to your
Quality Management System
and their needs
• Requires you to communicate
the quality policy and ensure
that the workforce
understands how they
contribute to it
• You are expected to show
how you meet customer
requirements and regulatory
and statutory requirements
182
 What Are the Myths of ISO
9000?
• It guarantees customers.
• If you’re certified, your products must be
top quality.
• A consultant can prepare the certification
documentation for you.
• It’s a waste of money and time.
• The ISO 9000 requirements are
complicated.
• Certification is the job of the quality-control
183
department.
 SEI CMM(Software Engineering Institute
Capability Maturity Model)

• The Capability Maturity Model (CMM) is a

procedure used to develop and refine an
organization's software development process.
• The model defines a five-level evolutionary stage of
increasingly organized and consistently more mature
processes.
• CMM was developed and is promoted by the
Software Engineering Institute (SEI), a research and
development center promote by the U.S. Department
of Defense (DOD).
184
CMM

185
Key Process Areas (KPA) of a
software organization

186
Module 1

187