Quality of the process

Quality of the process

Software certification
Quality of the process

INTRODUCTION TO THE SUBJECT

Anyone with basic knowledge about programming can develop an application, and this
implies that you can find all kinds of solutions in the market.
The problem is that not everyone applies quality controls when developing software.
Imagine
that we want to manufacture a new type of car, copying designs from other cars, and
without
establishing some minimum controls of security. Probably we can sell many units,
but when
any disaster occurs, the problems will begin.
Therefore, it is important to define a model of quality, from the point of view of
software
engineering, in order to establish some controls that ensure the quality of the
software.
So, basically we will see quality models that focus on the quality of the software
process,
also on the product quality, and also on the service quality.
Quality of the process

GLOSARY
- AENOR: Is a certification body with various headquarters in the world, including
Latino America.
- Audit: Is an external review of the system.
- Benchmark: Bank of tests that generally is used to test software.
- BSI: British Standard Institution, is an international entity that publishes
standards, and
also gives certification services.
- Capacity: Ability of a process to meet some requirements.
- CMMI: Software model for the evaluation of the quality.
- Developers: People that develops software.
- Environment: Can be the place where an application is executed, for example an
internal
network, or a production environment.
- ISO: International organization that develops and publishes ISO standards.
- IT service: Service that is related to the Information Technologies.
- Knowledge base: Database with specific information about some topics.
- Maturity: Ability of an organization to offer quality in the software.
- Outcomes: Results of processes.
- PDCA: Model of continual improvement, composed by the following steps: Plan, Do,
Check, Act.
- Process: A set of activities that have several inputs and give several outputs.
- Software life cycle: The development of software is composed by different steps,
generally: Requirements analysis, Design the software, Implementation,
Documentation
and testing, and Operate and maintain the system.
Quality of the process

- Software product: Is the result of the development of the software, and the
product that
can be sold to the customers.
- Source code: Lines of code which the software is composed. This source code can
be
written in Java, C++, PHP, or any other programming language.
- SQuaRE: Software Quality Requirements and evaluation, is a model composed by
various standard for the evaluation of the software product.
Quality of the process
MODULE N° 1: Quality of the process
2. SPECIFIC INFORMATION ABOUT THE MODULE

TABLE OF CONTENT
1. Quality of the process.
1.1 Introduction to the maturity model.
1.2 Approach about SPICE
1.3 Structure of ISO/IEC 15504
1.4 Software life cycle processes – ISO 12207
1.5 SPICE certification
INTRODUCTION TO THE MODULE 1
In this module we will see the software quality from the point of view of the
processes,
so we will see the SPICE model, which is composed mainly by the standards ISO/IEC
15504 (evaluation) and ISO/IEC 12207 (processes).

CONTENT OF THE MODULE N° 1

1. Thematic unit 1: Quality of the process
1.1. Introduction
From the point of view of the quality, you cannot improve a product or a service
if you do not improve the processes involved.
There are many processes specifics for the software, which we can use to
improve the product, or the service, so we will see different models and their
processes.
1.2. Conceptual framework
1.2.1. Introduction to the maturity model
The maturity model allows to know the maturity of an organization, based on its
processes, in relation to the software quality. However, there is also the model
Quality of the process
of capacity, which measure the capacity of each of the software processes of the
organization.
1.2.2. Approach about SPICE
The SPICE model allows to evaluate the maturity and capacity of an organization,
being similar to CMMI, but with the big difference that SPICE is based in a ISO
standard, and has a certification scheme. For the evaluations, SPICE defines
mainly 6 levels.

1.2.3. Structure of ISO/IEC 15504

ISO/IEC 15504 is composed by 10 different part, which can be used to
understand better the standard, and to know how to implement it.
1.2.4. Software life cycle processes – ISO/IEC 12207
ISO/IEC 12207 defines a group of software processes, which can be used to
improve the quality. SPICE can be based on these processes to perform the
evaluation.
1.2.5. SPICE certification
If you have implemented SPICE, the logic next step is certificate it, and depending
the processes implemented, you will have a level, according to the SPICE model.
1.3. Examples (not to exceed 2 pages)
AENOR model:
http://www.aenor.es/AENOR/certificacion/calidad/calidad_software_15504.asp#.W
CWsltxhrAo
1.4. Exercises (not to exceed 2 pages)
1.- There are many companies developing software, but all companies have the
same model for the quality?
2.- If 2 companies use the same model, these companies have the same level for
the quality?
Quality of the process
3.- How can we prove that we have a standard –related to software
qualityimplemented in the organization?
1.5. Conclusions (not to exceed 1 page)
Improving the software processes, we can also improve the quality of the
software, so our customer will be more satisfied with our service.
1.6. Resources for the study
Topics
covere
d
SPICE
Maturit
y model

Bibliographi
c reference
(APA)
What is
SPICE? wibas.
Capability
Maturity
Model
Integration

Location (the link web or the database)

https://www.wibas.com/en/turningvisions/publications/articles/spice/what-spice/
https://es.wikipedia.org/wiki/Capability_Maturity_Model_Integrati
on
Quality of the process
2. Thematic unit 2 – Quality of the process
2.1.- Introduction to the maturity model.
In the industry of the engineering of the software, errors are typical. Probably
more than
once your computer, or an application you usually use to surf the internet, it has
shown you
an error message, not allowing you to work with her.
These errors were much more common in the past, given that is cared less for the
quality of
the product, or are not cared for properly.
Really, in systems that were developed in the past, quality focused on detecting
errors in a
test phase, once developed the software.
Currently, this has improved, and now not only is important the detection of
errors, also is
important the definition of process, and use them for the development of the
software, for of
this way improve the quality of the product developed.
Therefore, it is important to test the product once it has developed, but it is
also very
important to establish a series of processes, to be used for the development of the
product,
to thus ensure the quality of the software .

Software
process

Error
detection

Software

Software quality
Figure 1 – Software quality
Quality of the process
The concept of process software, includes to all them activities that is carried to
out,
and the methods that are defined, and practices that can be used for the
development and maintenance of the software.
You can define a process basically as a black box, where is carried out a series of
activities, taking as basis a series of entries, and providing as output a series
of
results.

Inputs

Activities

Outputs

Figure 2 - Process

Therefore, the activities will provide results, on the basis of some parameters.
These
activities may consist of the following actions:
•
•
•

Establishment of a methodology and a systematic common work.

Establishment of roles (developers, analysts, head of project, etc.)
Assignment of responsibilities (for example, developers for the programming,
analysts for the review of the source code, the project manager for the
coordination of the implementation of the project, etc.)
Definition of the technologies to be used (for example: C++ and Java for the
logic of business, PHP for the web layer, etc.)

The main objective of these processes, is the development of a quality final

product,
which is obviously much better in order to the satisfaction of current customers,
or
to be able to attract the attention of future clients.
You can also see this process approach as an opportunity for the positioning on the
market: not all organizations that develop software worry really the quality of the
product to develop, and with the approach of processes we can give greater
guarantees of quality.
On the other hand, to ensure that the processes improve the quality of the product,
they have to meet certain requirements:
•

They have to return the results that were expected, or that were established.
Quality of the process
•
•

Must be based on a proper definition of the process

They have to be improved constantly, depending on the objectives of the
organization

In addition to gaining a competitive advantage, the approach to processes can

provide cost savings, because may allow an organization to establish an order when
it comes to work, which will involve a significant optimization of the tasks that
are
carried out in the organization, which means that they will reduce times, and this
has
a clear effect to the costs (is not the same run a project in 12 months, that in 6
months).
An organization that does not define processes, or does not define them properly,
but does not measure them, or does not control them, or does not improve them, is
considered as an immature organization. And, obviously, if you meet all these
points,
is considered a mature organization.
Therefore, the best way of ensuring the quality of a software product is to define
process, establish a method to measure them, control them, and improve them.

Define the
process

Improve the
process

Measure
the process

Control the
process

Figure 3 – Steps of the process software

In this way, an organization which is mature, with software-defined, measured,
controlled, and improved process, will develop software according to the required
specifications, will comply with the time limits set forth in the project plan,
achieve
Quality of the process
customer satisfaction, will get that staff of the project team is integrated,
coordinated
and function all in one line.
Another advantage of organizations that are mature, is that the knowledge is
usually
kept in the organization (through defined processes), while immature organizations
are made up by people who possibly change their company, and therefore bring their
knowledge elsewhere, and may leave a disclosure of knowledge of the organization
(a company not may depend on one or more persons, the organization must have
its own methods of work, etc.).
Another of the advantages provided by this model, is that different levels of
maturity
can be established to know the degree of maturity of an organization in relation to
its processes.
On the other hand, you can also measure the capacity of each process, i.e., the
degree of capacity which has each process individually.
So, we can find mainly 2 models of evaluation:
•
•

Assessment of capacity model: Focused on each individual process

Evaluation of maturity model: Focused on all the processes of the
organization

The evaluation of the maturity model is generally more common, since it gives a
global picture of the organization,
However, these models are not incompatible, i.e., are often used in a way parallel,
thus can know the level of maturity of the organization, and also the level of
capacity
for each of their processes.

Capacity
evaluation

• Individual processes

Maturity
evaluation

• All processes

Figure 4 – Capacity and maturity models

Therefore, we can finally say that the quality of a product, will be determined by
the
quality of the processes used for its development and maintenance.
2.2.- Approach about SPICE
Quality of the process
From now, it is clear that the process model is necessary in the software
engineering
industry if we want to offer quality products, and if we want to have a powerful
tool
to be able to be competitive in the market.
But how can an organization prove that has processes, and uses them to develop
quality software? The answer is, with a certification.
The certification CMMI-DEV offers further insight about the maturity of the
organization, i.e., uses a model of evaluation of maturity to determine the
maturity of
processes, and is well known in the software engineering industry.
However, this certification is also known to be especially costly, and in many
cases
also be considered complex, especially for small organizations (small organizations
are that most abound in this sector).
So it can be interesting to consider other options, like for example SPICE
(Software
Process Improvement and Capability dEtermination), which is very similar to
CMMIDEV.
SPICE is really based on the standard ISO/IEC 15504, and it is used to certify the
maturity of processes of software development, which is basically the same thing
that makes CMMI-DEV.
The difference is that the SPICE certification tends to be cheaper, and also easier
to
evaluate. In addition, being based on an ISO standard, it can be easily integrated
with other ISO standards, as for example ISO 27001 (information security), ISO
22301 (business continuity), ISO 20000 (IT services), ISO 9001 (quality), etc.
Another important difference is the scheme of certification of CMMI-DEV, and
SPICE. In the case of CMMI-DEV, assessments (known as "appraisal"), are made
via the SCAMPI method (Standard CMMI Appraisal Method for Process
Improvement), which identifies strengths and weaknesses in the processes, and can
reveal risks of development.
SPICE follows the scheme of certification of management systems, ISO standards,
so that annual audits are performed (there is an initial audit, consisting of a
stage 1
and a stage 2, and in the following years are performed surveillance audits each
year, and every 3 years a recertification audit is performed).
Therefore, since SPICE it is easy to understand, easy to implement, and more
economical, we will give more information about this standard during this module.
The different levels that establishes the SPICE model (you already know that it is
based on ISO/IEC 15504) for levels of capacity are as follows:
Quality of the process

Level 5: Optimized • The process is improved continuously

Level 4:
Predictable

• The process is managed using

quantitative techniques

Level 3:
Established

• An adapted process is used, based on a

standard process

Level 2: Realizado • The process is managed

Level 1:
Performed

• The process is performed and there are

evidences

Level 0:
Incomplete

• The process is not complete

Figure 5 – Capacity levels

On the other hand, the levels of maturity that defines ISO / IEC 15504 are the
following:
Quality of the process

Level 5: Optimized • The processes are improved continuously

Level 4:
Predictable

• The processes are managed using

quantitative techniques

Level 3:
Established

• The organization uses processes adapted,

based on standards

Level 2: Managed
Level 1: Basic

Level 0: Immature

• The processes are managed

• The organization implements the
processes and achieves the objectives

• The organization does not have

implemented the processes

Figure 6 – Maturity levels

The majority of organizations certified in the SPICE model, are level 2 and 3,
being
the level 2 the first certifiable level. So, levels 0 and 1 are not certifiable
(especially
the level 0, which indicates that the processes are not implemented).
On the other hand, the ISO/IEC 15504 also relies on another standard, the ISO/IEC
12207, which defines a common framework for software life cycle processes. We'll
talk more in detail about this standard later.
Therefore, an organization of software development based on the SPICE model, can
implement the processes of ISO/IEC 12207.
There is a specific model of SPICE focused in the industry of the automotive, which
is known as Automotive SPICE, and is composed by specific processes of this
industry.
CMMI-DEV defines the following levels of maturity:
Quality of the process

Level 5:
Optimized

• The processes are improved continuously

Level 4:
Managed

• The processes are measured and controlled

Level 3:
Defined

• The processes are characterized by the

organization, and acts proactively

Level 2:
Repeatable

• The proyects are characterized by the processes,

and often the organization acts reactively

Level 1: Initial

• The processes are unpredictable, poorly

controlled, and the organization acts reactively

Figure 7 – Capacity levels of CMMI-DEV

As you can observe, is very similar to the model of SPICE, therefore, is very
simple
mapping their levels.

Finally, as already mentioned in a previous section, the certification scheme of

SPICE is similar to the of other ISO management systems (ISO 27001, ISO 20000,
ISO 9001, ISO 14001, ISO 22301, etc). Therefore, a certification audit of SPICE, is
composed by the following types of audit:
Quality of the process
•

•
•

Initial audit: Composed by stage 1 (the audit is planned and the

documentation is reviewed), and stage 2 (the audit is performed to verify that
the organization has implemented the system, in this case the SPICE model).
Surveillance audit: Similar to stage 2 of the initial audit, i.e. is conducted the
audit to check in this case that the organization maintains the system.
Recertification audit: The certificate issued by a certification body usually
have a duration of 3 years, after which it is necessary to renew it, and again
repeat the certification process (but without stage 1 and stage 2, that is, there
will be surveillance audits each year, until a new recertification audit.

Initial audit

Surveillance
audit

Recertification
audit
Figure 8 – Main types of certification audits

After each audit, the lead auditor is responsible for issuing a final report with
the
results of the audit. This report may contain findings that the company needs to
treat,
developing a corrective actions plan.
Once the organization presents the corrective actions plan, if the lead auditor
valid
it, gives a decision for the certification to the certification body, and finally
if it is all
right, the certification body gives the certificate to the company (valid for 3
years).
The organization must ensure, during the time of validity of the certificate, to
keep
the system implemented and maintained, and may lose certification if during any
Quality of the process
surveillance audit, or a recertification audit, has not worked on findings
identified
during an audit.
There is another type of audit, unusual, which is called extraordinary audit, which
is
used in those cases in which a very important finding is detected and the
certification
body must verify in situ, after a normal audit, if the organization has treated and
solved the very important finding.
These audits are performed by auditors qualified by certification bodies, which
also
have to conduct audits according to another standard: the ISO/IEC 17021. In other
words, this standard defines requirements for certification bodies, for the
activities
carried out during the certification audit.
2.3.- Structure of ISO/IEC 15504
When we speak about ISO/IEC 15504, really consists of 10 parts.
a.- ISO/IEC 15504-1:2004 Information technology. Process assessment. Part 1:
Concepts and vocabulary
This first part of the standard provides information about basic concepts related
to
the evaluation of processes. On the other hand, it also provides information about
the terminology used in the standard for the evaluation of processes.
Therefore, this standard simply provides information about basic concepts, and
vocabulary that is used in all standards for the evaluation of the processes.

b.- ISO/IEC 15504-2:2003 Information technology. Process assessment. Part 2:

Performing an assessment
Sets some minimum requirements to carry out the evaluation of processes, so it
tends to be used by certification bodies to perform certification audits.
For the evaluation, this part of the standard is based on a model composed of 2
dimensions:
•

Dimension of the process: Relies on an external reference model (usually

ISO/IEC 12207, which we will see later), for the definition of a set of
processes.
Dimension of capacity: defines 6 levels of capacity (which we saw in a
previous point) to establish a framework for the measurement of processes.
Quality of the process
Therefore, this allows us to have a series of processes of an external model
(usually
the processes of ISO/IEC 12207, that are specific to software), and a mechanism for
measuring, composed by 6 levels of capacity.

Level 5
Level 4
Level 3
Level 2
Level 1
Level 0
Process A

Process B

Process C

Process D

Figure 9 – 2 dimensions model

On the other hand, to be able to measure the capacity of each process, it is
necessary to use what is known as process attributes.
These process attributes are grouped according to the different levels of capacity,
and each attribute measures a particular aspect of the ability of each process.
In this way, we can see the following:
Capacity level
Level 0
Incomplete process
Level 1
Performed process
Level 2
Managed process
Level 3
Established process
Level 4
Predictable process
Level 5
Optimizing

ID of the process
attribute
N/A

Process attribute

PA 1.1

Realization of the process

PA 2.1
PA 2.2
PA 3.1
PA 3.2
PA 4.1

Management of the realization

Work product management
Definition of the process
Deployment of the process
Measurement of the process
Control of the process

PA 4.2
PA 5.1
PA 5.2

Innovation of the process

Continual optimization

Table 1 – Capacity levels and process attributes

Quality of the process
It is also appropriate to highlight that for the dimension of the process, an
external
model can be used for the definition of processes, but this model has to meet the
following requirements:
•

Must contain documentation of the community interested in the development

of the model, and the actions performed to reach a consensus within the
community (this requirement is met by ISO/IEC 12207, given that has been
developed, and is maintained, by ISO.org).
The processes defined within the model must have a description and a unique
process ID. In addition, the descriptions of the processes must describe at a
high level the general objectives that are trying to achieve with the processes,
and describe the results that can be show that the achievement of the process
is achieved (it is also complied by ISO/IEC 12207).

c.- ISO/IEC 15504-3:2004 Information technology. Process assessment. Part 3:

Guidance on performing an assessment
It provides guidance for an evaluation using as reference the ISO/IEC 15504-2,
providing an overview of the evaluation of processes.
In addition, this part of the standard also offers a guide to establishing the
framework
for the process capability measurement, oriented in the selection and use of
assessment tools, helps to define competencies for evaluators, and also help in the
verification of the conformity of the assessment.
On the other hand, this part of the standard also provides an example of evaluation
according to the requirements of ISO/IEC 15504-2, i.e., the part 2 of the ISO/IEC
15504.
d.- ISO/IEC 15504-4:2004 Information technology. Process assessment. Part 4:
Guidance on use for process improvement and process capability
determination
This part of the standard also provides guidance, but in this case the guide helps
to
improve processes, and also helps to determine the capability of a process.
If we make an analysis of a process based on their results (this is also known as a
result of the process or outcomes), and crossed them with the business objectives
of a unit or organization area, we can identify the strengths, weaknesses and risks
that are associated with the processes (that can also help us to determine the
ability
of the processes).
Quality of the process
Therefore, this analysis can basically help to determine the ability of the
processes,
and if processes are effective in achieving the objectives of the business, which
can
be used to identify and make improvements on processes.

e.- ISO/IEC 15504-5:2012 Information technology. Process assessment. Part 5:

An exemplar software life cycle process assessment model
This part of the standard basically shows an example about how to perform an
assessment according to the requirements of part 2 of the ISO/IEC 15504, i.e. in
accordance with the ISO/IEC 15504-2.
For the evaluation also relies on the model of the ISO/IEC 12207 processes, and
establishes a series of indicators for process capability, which can afford to know
whether has achieved the established capacity.

f.- ISO/IEC 15504-6:2013 Information technology. Process assessment. Part 6:

An exemplar system life cycle process assessment model
This part of the standard is similar to part 5, so also this part also gives an
example
about how to perform an assessment according to the requirements of the ISO/IEC
15504-2, but in this case is used only as a process reference model the standard
ISO/IEC 15288.
The main difference between ISO/IEC 12207 and ISO/IEC 15288 is that the first is
focused on processes of software life cycle, while the second focuses on the system
life cycle processes.
Therefore, the main difference between ISO/IEC 15504-6 and ISO/IEC 15504-5, is
that the first is focused on a model of evaluation of the systems life cycle
processes,
while the ISO/IEC 15504-5 focuses on a model of evaluation of the software life
cycle
processes.
g.- ISO/IEC TR 15504-7:2008 Information technology. Process assessment.
Part 7: Assessment of organizational maturity
This part of the standard is one of the most important (together with parts 1 and
2),
and mainly establishes minimum requirements for an assessment of the maturity of
an organization. For this assessment of maturity, it relies mainly on the
evaluation of
the ability of the processes, so it has an important link with the ISO/IEC 15504-2.

In this way, you can use an array like the one shown below to determine the level
of maturity of an organization:
Quality of the process

Level 5
Level 4

Level 3

ML3

Level 2

ML4

ML5

ML2

Level 1
ML1
1A

1B

1C

2D

2E

2F

3D

3E

3F

4D

4E

4F

5D

5E

5F

Table 2 – Maturity levels

In the vertical line you can see different levels of capacity (level 1, level 2,
level 3,
level 4 and level 5), while in the horizontal line you can see different categories
of
the processes.
Representing each value as follows:
•
•
•
xA: minimum processes to the level of maturity n
xB: additional processes required for the level of maturity n
xC: optional processes for the maturity level of n

Where "n" indicates the level of corresponding maturity.

The crossing of the level of capacity with the corresponding process group,
determines the level of maturity of the organization.
In this way, for example, if the organization wants a level of maturity 3, the
organization should take all processes 1A, 1B, 1 c, 2D, 2E, 2F, 3D, 3E and 3F to
the
level of capacity 3.
On the other hand, as you can see in the table, to reach the level of maturity 4,
it is
not necessary that all processes reach a level of ability 4 (for example 1B, 3E,
the
4D and 4F).
Quality of the process
With respect to the level of maturity 5, also you can see in the table, that only
processes that have to reach a level of capacity 5 are the 1A, 2E, 3D and 4E,
although the latter is optional.
Therefore, the above matrix can be useful to determine the level of maturity of an
organization based on the levels of each process.

h.- ISO/IEC TS 15504-8:2012 Information technology. Process assessment.

Part 8: An exemplar process assessment model for IT service management
This part of the standard also provides an example of evaluation of processes, but
in this case focused on the processes of the ISO/IEC 20000 (this standard we will
see in the next module, but basically establishes requirements to define an IT
service
management system).
For the evaluation of the processes of ISO/IEC 20000, the standard is based on
ISO/IEC 15504-2.
i.- ISO/IEC TS 15504-9:2011 Information technology. Process assessment. Part
9: Target process profiles
This part of the standard essentially establishes a number of requirements in order
to be able to determine the ability to achieve the organization's specific needs,
using
process profiles.

j.- ISO/IEC TS 15504-10:2011 Information technology. Process assessment.

Part 10: Safety extension
This part of the standard basically adds a security component, as an extension to
the previous parts.
Quality of the process

ISO/IEC 15504-1

• Conceps and vocabulary

ISO/IEC 15504-2

• Performing an assessment

ISO/IEC 15504-3

• Guidance on performing an assessment

ISO/IEC 15504-4

• Guidance on use for process improvement

and process capability determination

ISO/IEC 15504-5

• An exemplar software life cycle process

assessment model

ISO/IEC 15504-6

• An exemplar system life cycle process

assessment model

ISO/IEC 15504-7

• Assessment of organizational maturity

ISO/IEC 15504-8

• An exemplar process assessment model

for IT service management

ISO/IEC 15504-9

• Target process profiles

ISO/IEC 15504-10 • SAfety extension

Figure 9 – Parts of ISO/IEC 15504
2.4.-Software life cycle processes – ISO 12207
So far we have spoken much of processes, but we need to know what processes
can be used together with ISO/IEC 15004 for the evaluation of processes.
As you know, in this context, the standard that provides a model of the software
life
cycle processes is the ISO/IEC 12207.
Quality of the process
This standard consists of the following groups of processes:
•
•
•
•
•
•
•

Agreement processes
Organizational project-enabling processes
Project processes
Technical processes
Software implementation processes
Software support processes
Software reuse processes

Each of these groups, defines specific processes, which are described below.

Agreement
processes

Acquisition
process
Supply
process

Figure 10 – Agreement processes

•

Acquisition process: Its main aim is to obtain the product or service in

accordance with the requirements established by the customer. Therefore,
the process essentially identifies the needs of the client, and also trafficking
in the acceptance of product or service that the customer needs.
Supply process: Its main purpose is to provide the customer a product or
service that is appropriate to their needs and requirements.
Quality of the process

Organizational
project-enabling
processes

Life cycle
model
management
process
Infrastructure
managemend
process
Project
portfolio
management
process
Human
resource
management
process
Quality
management
process

Figure 11 – Organizational project-enabling processes

•

Life cycle model management process: This process mainly provides a

series of procedures of the life cycle of software, processes and policies,
which are consistent with the objectives of the organization, and that are
defined, adapted, improved and maintained to support the individual needs of
a project, in the context of the organization.
Infrastructure management process: This process helps to define, provide
and maintain facilities of the organization, tools and resources of
communications and information technologies that are necessary for the
activities that plays the organization during the life cycle of the software.
Project portfolio management process: Has as main objective to define
and maintain a series of projects that may be necessary and sufficient for the
strategic objectives of the organization. Therefore, this process helps to make
a proper investment of resources.
Human resource management process: Its main aim is to provide the
human resources that are necessary for the organization. The process is also
the competence of human resources, which must be in accordance with the
needs of the business, which helps to have staff qualified, specialized and
Quality of the process

experienced in the software life cycle processes, which will help the
organization reach its goals.
Quality management process: The main objective of this process is to
ensure the quality of products and services, which have to fulfil the objectives
of the customer, and their needs.

Project
processes

Project
planning
process

Project
assessment and
control process

Decision
management
process

Risk
management
process
Configuration
management
process
Information
management
process

Measurement
process

Figure 12 – Project processes

•

Project planning process: The main objective of this process is to define

and communicate project plans. Therefore, the process describes the scope
of management and technical activities of the project, identifying also the
outputs of the project, processes tasks and deliverables, and also establishes
plans to perform the tasks in the project, including the scope, and the
resources needed to perform the tasks in the project.
Project assessment and control process: The aim of this process is to
monitor the status of the project, and ensure that it is performed according to
the established plans. During a review of the project, can be necessary to replan
the project.
Decision management process: This process is intended to determine the
decision more commensurate with the needs of the organization, when there
Quality of the process

•
•

are different alternatives. Therefore, intends to analyze different alternatives,

and the final decision is recorded along with their reasons, for possible future
decisions that are similar.
Risk management process: The main objective of this process is to manage
risks during the life cycle of a product, software, service, or system.
Configuration management process: This process has as main objective
to establish and maintain the integrity of the outputs of a process or a project,
and make these available to the interested parties.
Information management process: The main objective of this process is to
manage the information, for which it is necessary to provide relevant,
complete, valid, and confidential information in time, to the parties concerned
during the life cycle of the system (and where appropriate, also after the life
cycle). The information that can manage this process is that is related to the
project, technical information of the organization, agreements, and user
information.
Measurement process: This process aims to obtain, analyses and reports
data concerning products and processes implemented in the organization, to
support effective management of the processes, and objectively demonstrate
the quality of the products.
Quality of the process

Technical
processes

Stakeholder
requirements
definition process

System
requirements
analysis process

System
architectural
design process

Implementation
process

System
integration
process

System
qualification
testing process

Software
installation
process
Software
acceptance
support process

Software
opeation process

Software
maintenance
process

Software disposal
process

Figure 13 – Technical processes

Stakeholder requirements definition process: This process has as main
objective the definition of requirements for a system. The process also
transforms the needs of stakeholders in a set of requirements.
Quality of the process
•

•
•

•
•

System requirements analysis process: The aim of this process is to

transform the stakeholder requirements into a set of technical requirements
of the system.
System architectural design process: The main objective of this process is
to establish the system requirements that must be established for each
element of the system.
Implementation process: This process aims to implement, or implement, an
element of the system.
System integration process: The main objective of this process is to
integrate the different elements of the system, thus producing a complete
system which satisfies the design and requirements of the system, as well as
the needs of the client. On the other hand, the elements of the system can be
software, hardware, manuals, and if necessary, other systems.
System qualification testing process: The aim of this process is to ensure
that checks that each requirement of the system has been implemented, and
that it is ready to be delivered.
Software installation process: The main objective of this process is to install
the software according to the requirements.
Software acceptance support process: The aim of this process is to get
that customer reaches sufficient trust accept that the software complies with
the requirements.
Software operation process: The main objective of this process is to
operate the software product in the environment agreed, and also provide
help to customers on the operation of the software product that they have
acquired.
Software maintenance process: The aim of this process is to provide
maintenance of the software, to a cost-effective, for thus deliver the software
in appropriate conditions.
Software disposal process: The main objective of this process is to remove,
or delete, an element of a system. The removal must be responsibly, and in
accordance with applicable law, agreements, restrictions that may exist in the
organization, and the requirements of the stakeholders.
Quality of the process

Software
implementation
processes

Software
implementation
process

Software
requirements
analysis process

Software
architectural
design process

Software detailed
design process

Software
construction
process

Software
integration
process

Software
qualification
testing process

Figure 14 – Software implementation processes

•

•
•

Software implementation process: The main objective of this process is to

implement specific elements of the system, being the result of the process an
element software that meets the design requirements, and the requirements
of the stakeholders.
Software requirements analysis process: The main objective of this
process is to define the requirements of the elements.
Software architectural design process: The aim of this process is to
provide a design for the software, which will be implemented in accordance
with the established requirements, and which can be verified.
Software detailed design process: The main objective of this process is to
provide a design that implements the requirements. On the other hand, the
architecture of the software has to be sufficiently detailed to allow the software
codification, and the corresponding tests.
Software construction process: The aim of this process is to build software
units that adequately reflect the design of the software,
Quality of the process
•

Software integration process: The main objective of this process is to

integrate the units of software with the software components. This integration
has to demonstrate that meets the functional and non-functional
requirements.
Software qualification testing process: The aim of this process is to
confirm that the integrated software product meets the requirements.

Software
support
processes

Software
documentation
management
process
Software
configuration
management
process
Software quality
assurance
process

Software
verification
process

Software
validation
process

Software review
process

Software audit
process

Software
problem
resolution
process

Figure 15 – Software support processes

Software documentation management process: The main objective of this
process is to develop and maintain the records produced by a process.
Quality of the process
•

•
•

Software configuration management process: The main objective of this

process is to define and maintain the integrity of a process or project software
items, and keep them available to interested parties.
Software quality assurance process: The main objective of this process is
to ensure that products and processes comply with the defined plans.
Software verification process: The main objective of this process is to verify
and confirm that each product, or each service of process or project,
adequately complies with the requirements.
Software validation process: The main objective of this process is to
validate and confirm the requirements for the specific use of a software
product.
Software review process: The main objective of this process is to keep
stakeholders informed on the progress of the objectives established, and
what can be done to ensure that the product meets the needs of the
stakeholders. So the software revisions are made during the life of the project.
Software audit process: The aim of this process is to determine the
compliance of the requirements, plans and agreements. So, it is necessary to
perform audits.
Software problem resolution process: The main objective of this process
is to ensure that all of the problems detected, are identified, analyzed,
managed, controlled and resolved.
Quality of the process

Software
reuse
processes

Domain
engineering
process
Reuse asset
management
process
Reuse program
management
process

Figure 16 – Software reuse processes

•

•
•

Domain engineering process: The main objective of this process is

developing and maintaining models, architectures, and resources for the
domain.
Reuse asset management process: The aim of this process is to manage
the life of resources that are reusable.
Reuse program management process: The main objective of this process
is to plan, establish, manage, control, and review the reusable programs of
the organization.

2.5.- SPICE certification

For all that we have seen in previous sections, if we wish to certify an
organization
in SPICE, we need to work with the following standards:
•
•
•
•

ISO/IEC 15504-2: Defines the requirements for an evaluation of process

capability
ISO/IEC 15504-7: Defines the requirements for an assessment of the maturity
of an organization
ISO/IEC 12207: Defines a set of processes, structured by groups, for the
software life cycle.
ISO/IEC 17021: It defines requirements for a certification body that performs
certification audits. So, this is standard needs to be implemented only by the
certification body.
Quality of the process
Obviously, you can also use the other parts of the standard ISO/IEC 15504, which
we have seen in this module, as support to implement and certify SPICE, but the
essentials are these which we have summarized.

ISO 12207

ISO 155042 + ISO

15504-7

ISO 17021

SPICE certification
Figure 17 – Standards for the SPICE certification
We should also mention that you can meet different certification models of SPICE,
which can have a different selection of processes for each maturity level.
In other words, you know that to achieve each level of maturity, it is necessary to
implement certain processes of ISO/IEC 12207, with a certain level of ability. But
what processes?
In the case of the certification body AENOR, processes that must be implemented
for the maturity level of 1, 2 and 3 are as follows:
Quality of the process

Maturity
level 1
Supply process

Life cycle model

management
process

Software
configuration
management
process

Figure 18 – Processes of the AENOR model, maturity level 1

Quality of the process

Maturity
level 2
Stakeholder
requirements
definition process

System
requirements
analysis process

Project planning
process

Project
assessment and
control process

Configuration
management
process

Measurement
process

Software quality
assurance
process

Figure 19 – Processes of the AENOR model, maturity level 2

Quality of the process

Maturity
level 3
Software
requirements
analysis process

Software
architectural
design process

System
architectural
design process

Infrastructure
management
process

Human resource
management
process

Risk management
process

Decision
management
process

Software
integration
process

System
integration
process

Software
veritication
process

Software
validation process

Figure 20 – Processes of the AENOR model, maturity level 3

With this model, an organization can certify in SPICE from level 2 to 5, and to
obtain a level you must have the previous ones, i.e., to achieve level 3, it is
Quality of the process
necessary to implement all processes maturity level 3, in addition to those of
level
2, and level 1.