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
Models

“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
Models
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
Incremental and Iterative Model
• Iterative
Involves a series of cycles or iterations, where each cycle
produces a working version of the software. The team can then
test and refine the software based on feedback. This approach is
good when the vision isn't well defined and the team wants to get
feedback while refining it.
• Incremental
Involves breaking the development process into small,
manageable parts called increments. Each increment builds on
the previous one, and the final product is only available when all
the increments are combined. This approach is good when the
vision is clear and the team knows what needs to be done.

97
 Observations

• An Iterative approach works well

when you have a rough idea of the
outcome but intend to refine it over
time.
• An incremental-only approach is best
when you have a very clear vision of
what you are creating.
• A combined incremental and iterative
development approach brings 98
Difference

99
Iterative Enhancement Model

100
Iterative Enhancement Model

101
Iterative Enhancement Model

102
Iterative Enhancement Model

103
Iterative Enhancement Model

104
Difference between iterative and
Incremental

105
Evolutionary development

106
Evolutionary development

107
Prototype Model

108
Prototype Model

109
Prototype Model

110
Prototype Model

111
 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

113
The Rapid Application Development
(RAD) Model

114
 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

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

122
 The Rapid Application
Development (RAD) Model

123
 The Rapid Application
Development (RAD) Model

124
 The Rapid Application
Development (RAD) Model

125
 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

128
Spiral Model

129
Spiral
Model

20
 Spiral
▪ An important feature ofModel
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

132
 Different phases of spiral model

Phase 1:Objectives determination and identify alternative

solutions

133
 Different phases of spiral model

Phase 2: Identify and resolve Risks

134
 Different types of risk involved.

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

135
 Different phases of spiral model

Phase 3: Develop next version of the Product

136
 Different phases of spiral model

Phase 4: Review and plan for the next Phase

137
 Example-Developing an E-
Commerce Website
First Spiral – Planning and Requirements: The
initial phase involves gathering basic requirements
for the e-commerce website, like product listing,
shopping cart, and payment options. The team
analyzes any risks, such as security or scalability,
and creates a small prototype.

Example: The team builds a simple homepage

with a basic product catalog to see how users
interact with it and identify any design flaws.

138
 Example-Developing an E-
Commerce Website
Second Spiral – Risk Analysis and Refining the Design:
After gathering feedback from the prototype, the next spiral
focuses on adding more features and fixing early issues.
The team addresses security risks, such as secure
payment processing, and tests how well the site handles
increasing user traffic.
Example: A basic shopping cart and user registration
system are added. The payment system is also tested with
dummy transactions to ensure security.

139
 Example-Developing an E-
Commerce Website
Third Spiral – Detailed Implementation: With
more feedback, the team further refines the design,
adding advanced features like order tracking,
customer reviews, and search functionality. Risks
like scalability (handling many users) are re-
evaluated, and more testing is conducted.

Example: The website now supports user

profiles, product reviews, and real-time inventory
updates. The team tests how the system handles
large volumes of orders during peak times.

140
 Example-Developing an E-
Commerce Website
• Final Spiral – Full Deployment: The final phase
involves full implementation, thorough testing, and
launching the e-commerce website to the public.
Ongoing risks like system crashes or user feedback
are monitored and addressed as needed.

• Example: The website goes live with all features,

including secure payments, product listings, and
order tracking, ready for users to shop online.

141
 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 142
 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.
143
 Agile Methodology
• Agile Software Development is an iterative
and incremental approach to software
development that emphasizes the
importance of delivering a working product
quickly and frequently. It involves close
collaboration between the development
team and the customer to ensure that the
product meets their needs and
expectations.
144
 Why Agile?
• Creating Tangible Value: Agile places a
high priority on creating tangible value
(gaining a deeper understanding of their
customers' needs, challenges, and
goals)as soon as possible in a project
• Concentrate on Value-Added Work:
Agile methodology promotes teams to
concentrate on producing functional and
value-added product increments, hence
reducing the amount of time and energy
allocated to non-essential tasks.
145
 Why Agile?
• Agile as a Mindset: Agile represents a
shift in culture that values adaptability,
collaboration, and client happiness. It
gives team members more authority and
promotes a cooperative and upbeat work
atmosphere.
• Quick Response to Change: Agile
adopts a culture that allows teams to
respond swiftly to constantly shifting
priorities and requirements. This
adaptability is particularly useful in sectors
of the economy or technology that
146
 Why Agile?
• Regular Demonstrations: Agile techniques
place a strong emphasis on regular
demonstrations of project progress.
Stakeholders may clearly see the project’s
status, upcoming problems, and upcoming new
features due to this transparency.

• Cross-Functional Teams: Agile fosters self-

organizing, cross-functional teams that share
information effectively, communicate more
effectively and feel more like a unit. 147
Principles of Agile Methodology

148
 The Agile Software
Development Process

149
 Agile Software Development
• Agile Software Development is widely used by
software development teams and is considered
to be a flexible and adaptable approach to
software development that is well-suited to
changing requirements and the fast pace of
software development.
• Agile is a time-bound, iterative approach to
software delivery that builds software
incrementally from the start of the project,
instead of trying to deliver all at once.
150
 The Agile Software
Development Process
1. Requirements Gathering: The customer’s requirements for the
software are gathered and prioritized.

2. Planning: The development team creates a plan for delivering

the software, including the features that will be delivered in each
iteration.

3. Development: The development team works to build the

software, using frequent and rapid iterations.

4. Testing: The software is thoroughly tested to ensure that it meets

the customer’s requirements and is of high quality.

5. Deployment: The software is deployed and put into use.

6. Maintenance: The software is maintained to ensure that it

continues to meet the customer’s needs and expectations.
151
Agile Software Development
Life cycle

152
 Example
• A Software company named ABC wants to make a
new web browser for the latest release of its
operating system. The deadline for the task is 10
months. The company’s head assigned two teams
named Team A and Team B for this task. To
motivate the teams, the company head says that the
first team to develop the browser would be given a
salary hike and a one-week full-sponsored travel
plan. With the dreams of their wild travel fantasies,
the two teams set out on the journey of the web
browser. Team A decided to play by the book and
decided to choose the Waterfall model for the
development. Team B after a heavy discussion
decided to take a leap of faith and choose Agile as
their development model. 153
 example
The Development Plan of the Team A is as follows:
Requirement analysis and Gathering – 1.5 Months

Design of System – 2 Months

Coding phase – 4 Months

System Integration and Testing – 2 Months

User Acceptance Testing – 5 Weeks

154
 Example
The Development Plan for the Team B is as follows:
• Since this was an Agile, the project was broken up into
several iterations.
• The iterations are all of the same time duration.
• At the end of each iteration, a working product with a
new feature has to be delivered.
• Instead of Spending 1.5 months on requirements
gathering, they will decide the core features that are
required in the product and decide which of these
features can be developed in the first iteration.
• Any remaining features that cannot be delivered in the
first iteration will be delivered in the next subsequent
iteration, based on the priority. At the end of the first
iterations, the team will deliver working software with the 155
Agile Methodology

156
Agile Methodology

157
Agile Methodology

Process is complete if they deliver

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

158
Agile Methodology

159
Agile Methodology

160
Agile Methodology

161
Agile Methodology

162
Agile Methodology

163
Agile Methodology

164
 Agile Methodology

Role and responsibilities are

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

165
Agile Methodology

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

167
Agile Methodology

168
Agile VS. Waterfall

169
Agile VS. Waterfall

170
Agile VS. Waterfall

171
Agile VS. Waterfall

172
Agile VS. Waterfall

173
Agile VS. Waterfall

Changes can not be

incorporated.

174
Agile VS. Waterfall

175
Agile VS. Waterfall

After each iteration customer

176
feedback is involved.
Agile VS. Waterfall

177
Agile VS. Waterfall

178
Agile VS. Waterfall

179
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

180
Agile VS. Waterfall

181
Selection of a Life Cycle Model

Can lead to successful

product

Can lead to un successful

product

182
Selection of a Life Cycle Model

183
 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

189
ISO

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

191
ISO 9001

192
ISO 9001

193
ISO family

194
ISO family

195
ISO 9001

196
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

197
 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

198
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 199
 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
200
 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
201
 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
202
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). 203
CMM

204
Key Process Areas (KPA)
of a software
organization

205
Module 1

206