1

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

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

3
4
 What is software?

• Computer programs and

associated documentation

5
What is software?

6
 What is software?

Programs

Documentation Operating
Procedures

Software=Program+Documentation+Operating
Procedures Components of software

7
What is software

8
What is Engineering

9
Software Engineering

10
IEEE Defination

11
What is software

12
Types of software

13
Types of software

14
Types of software

15
Types of software

16
Types of software

17
Difference between H/W and S/W

18
 Difference between H/W and S/W

Software is set of Programs, which we can not touch

19
Difference between H/W and S/W

20
Difference between H/W and S/W

21
Characteristics of software

22
Characteristics of software

23
Characteristics of software

24
Principles of S/W Engineering

25
Principles of S/W Engineering

26
Principles of S/W Engineering

27
Principles of S/W Engineering

28
Principles of S/W Engineering

29
Principles of S/W Engineering

30
Principles of S/W Engineering

31
 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

32
 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

33
 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

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

Productivity

Do not quit here!

Learning curve

Time

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

Useful life
phase

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

37
 Software Characteristics:
Comparison of constructing a bridge vis-à-vis writing a
Sr.
program. Constructing a bridge Writing a program

No
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 do Requirements typically change during
not change much during construction
all 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, is a When a program fails, the reasons are often
there 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.
38
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

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

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

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

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

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

The reality is totally different.

44
 Software Myths (Management
Perspectives)

Computers provide greater reliability

than the devices they replace

This is not always true.

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

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

Software can work right the first time

Both are only myths!

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

Usually, the problems just begin!

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

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

Tested code is only one of the deliverable!

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

Those days are over. Now objective is to

develop good quality maintainable
programs!

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

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

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

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

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

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

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

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

People
Project

Product Process

60
Role of Management in Software
Development People

Project 4 Dependency Product

2
Order

Process

61
SDLC

62
SDLC

63
SDLC

64
 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

68
Water fall model

69
 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

71
Water fall model

72
Water fall model

73
Waterfall Model

74
Waterfall Model

75
Waterfall Model

76
Water fall Model

77
Water fall Model

78
Water Fall Model

79
Water Fall model

80
Waterfall model

81
Water Fall Model

82
Waterfall model

83
Advantage of water fall model

84
 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. 88
 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 89
Difference

90
Iterative Enhancement Model

91
Iterative Enhancement Model

92
Iterative Enhancement Model

93
Iterative Enhancement Model

94
Iterative Enhancement Model

95
Difference between iterative
and Incremental

96
Evolutionary development

97
Evolutionary development

98
Prototype Model

99
Prototype Model

100
Prototype Model

101
Prototype Model

102
 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

104
The Rapid Application Development
(RAD) Model

105
 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

107
 The Rapid Application
Development (RAD) Model

108
 The Rapid Application
Development (RAD) Model

109
 The Rapid Application
Development (RAD) Model

110
 The Rapid Application
Development (RAD) Model

111
 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

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

119
Spiral Model

120
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

123
 Different phases of spiral model

Phase 1:Objectives determination and identify alternative

solutions

124
 Different phases of spiral model

Phase 2: Identify and resolve Risks

125
 Different types of risk involved.

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

126
 Different phases of spiral model

Phase 3: Develop next version of the Product

127
 Different phases of spiral model

Phase 4: Review and plan for the next Phase

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

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

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

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

132
 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 this.

133
 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.
134
 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.
135
 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.
136
 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
137
 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.
138
Principles of Agile
Methodology

139
 The Agile Software
Development Process

140
 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.
141
 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.
142
 Agile Software
Development Life cycle

143
 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. 144
 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

145
 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 core basic features.

146
Agile Methodology

147
Agile Methodology

148
Agile Methodology

Process is complete if they deliver

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

149
Agile Methodology

150
Agile Methodology

151
Agile Methodology

152
Agile Methodology

153
Agile Methodology

154
Agile Methodology

155
 Agile Methodology

Role and responsibilities are

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

156
Agile Methodology

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

158
Agile Methodology

159
Agile VS. Waterfall

160
Agile VS. Waterfall

161
Agile VS. Waterfall

162
Agile VS. Waterfall

163
Agile VS. Waterfall

164
Agile VS. Waterfall

Changes can not be

incorporated.

165
Agile VS. Waterfall

166
Agile VS. Waterfall

After each iteration customer

167
feedback is involved.
Agile VS. Waterfall

168
Agile VS. Waterfall

169
Agile VS. Waterfall

170
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

171
Agile VS. Waterfall

172
Selection of a Life Cycle Model

Can lead to successful

product

Can lead to un successful

product

173
Selection of a Life Cycle Model

174
 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

180
ISO

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

182
ISO 9001

183
ISO 9001

184
ISO family

185
ISO family

186
ISO 9001

187
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

188
 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

189
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 190
 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
191
 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
192
 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
department.

193
 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). 194
CMM

195
Key Process Areas (KPA)
of a software
organization

196
Module 1

197