HOMOGENIZATION OF MODELS TO SUPPORT

MULTI-MODEL PROCESSES IN

IMPROVEMENT ENVIRONMENTS

César Pardo, Francisco J. Pino

IDIS Research Group, Electronic and Telecommunications Engineering Faculty, University of Cauca

Street 5 # 4–70, Popayán, Colombia

Félix García, Mario Piattini

Alarcos Research Group – Institute of Information Technologies & Systems, University of Castilla-La Mancha

Paseo de la Universidad 4, 13071 Ciudad Real, Spain

Keywords: Harmonization of Models for Process Improvement, Software Process Improvement (SPI), ISO 9001,

CMMI, ISO/IEC 12207, COBIT, PMBOK, COMPETISOFT.

Abstract: Since almost two decades ago, process improvement has been evolving considerably. Proof of this is the

increase in the amount of models (models and fact standards) that have been able to be referenced and taken

as a basis on which to carry out process improvement. The heterogeneity of available models, together with

the need to solve problems from many dimensions and organizational hierarchies, lead to organizations

facing problems in improvement process projects which have to deal with different models at the same time.

To balance these models, this paper sets out a homogenized structure as a support mechanism for the

harmonization and integration of their different characteristics.

1 INTRODUCTION

It is increasingly important and necessary for

organizations to take up work that allows them to

broach process improvement in a multi-model

environment. This is due to the fact that often the

“addiction” to new or better practices in this kind of

environments exists without any attention being

given to the coordination and considerations needed

to make the harmonization, integration and

interaction of the models (Jalote, 1999) easier.

Similarly, multi-model environments in software

process improvement are present when an

organization decides or needs to integrate into its

processes different practices or characteristics that

are present not in one, but in several models (Siviy

et al., 2008a).

A difficulty in tackling process improvement in

multi-model environments is the heterogeneity of

how different models describe the process elements.

This heterogeneity of those models is one reason

why many organizations get overwhelmed and

confused when making a decision about the choice

and application of the model which is most pertinent

to their needs. Such heterogeneity also comes about

because these models describe elements of different

knowledge areas and organizational requirements. In

some cases similar practices may even exist. In

general, each model specializes in a set of specific

practices and in a different level of abstraction and

detail. However, organizations can benefit from this

heterogeneity and variety if they suitably select and

complement the software processes from these

models which fit well to their contexts.

Of the analysis carried out in (Pardo et al., 2009)

and their upgrading with a systematic review, the

most important works with related this proposal are

(Biffl et al., 2006), (Ferchichi et al., 2008), (Siviy et

al., 2008a), (Siviy et al., 2008b), (Siviy et al., 2008c)

and (SPICE., 2008).

Related to the literature, this paper presents a

common structure that allows us to carry out the

homogenization of the process elements of two or

more models as one of the aspects that is important

in supporting the harmonization and integration of

models. The proposed structure allows us to analyze

151

Pardo C., Pino F., García F. and Piattini M. (2009).

HOMOGENIZATION OF MODELS TO SUPPORT MULTI-MODEL PROCESSES IN IMPROVEMENT ENVIRONMENTS.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 151-156

DOI: 10.5220/0002245801510156

 SciTePress

the process elements described by different models

under a common schema, to make harmonization

easier. The structure is also a tool that supports the

identification of differences and similarities, thereby

making it more possible to understand the different

models involved in the efforts in process

improvement made by a given organization.

Apart from the present introduction, the paper

presents: in section 2 the description of the structure

for homogenization and an example of its

application. Section 3 sets out the application of the

structure and homogenization of some process

entities of ISO 9001:2000. A set of lessons learned

is summed up in Section 4. Section 5 features

conclusions and future work.

2 STRUCTURE FOR

HOMOGENIZATION

To define the structure for homogenization, it was

first necessary to identify the process elements that it

would be made up of and that were also common to

any process model. Based on the analysis of the

studies about the commonly-identified process

elements presented in (Cugola et al., 1998),

(Derniame et al., 1999) and (Fuggetta, 2000) and the

most modeled process elements presented in (Benali

et al., 1992), (Finkelstein et al., 1994), (McChesney,

1995), (Fuggetta et al., 1996) and (Huff, 1996), it

was possible to establish a set of basic and common

elements for any process model.

Likewise, when making a comparison to analyze

the degree of correspondence with standard SPEM

2.0, it is possible to note that the process elements

identified are present in the standard. This helps to

prove the generality of the homogenization of our

purpose. The process element “resource” isn’t

defined in SPEM, however, this is just a

generalization of roles and tools that may be found

in a process model and that are defined in the

standard.

Other possible elements can manage to shape the

set of basic elements, like directly associated

elements or decomposed elements from other

elements, for example, steps and tasks of activities,

in-out appliances, human resources, time and so on.

Decomposition of elements allows us to detail and

match the information of models with more

granularity and/or detail. Thus, it will be possible to

evaluate the granularity of each model throughout

the structure. The generic structure is based on the

following works (Fuggetta, 2000), (Cugola et al.,

1998), (OMG, 2008), (Derniame et al., 1999) and

(Acuña et al., 2001).

2.1 Modeling of the Structure

Figure 1 presents the conceptual modeling of the

structure that uses the elements of a previously

defined process model, covering the object model,

attributes and its respective data types. As shown in

this figure, in general each model grouped together

all processes in different categories or processes

groups, in the same way each process is formed by a

set of elements or characteristics such as: activities,

tasks, roles, products or appliances, measurements,

and so on. This first version doesn’t aim to deal with

characteristics of all existing models. It does set out

to take account of the more common ones, as well as

the ones defined in the models analyzed, making its

future adaptation possible.

2.2 Structure Description

Common structure for the homogenization of

different models is divided into four sections, which

are described next:

Figure 1: UML modeling of the structure for

homogenization.

 Section 1: Description. Includes the process

description, process group, process, activities

and related tasks;

 Section 2: Roles and Resources. Includes the

tools, resources, roles and work disciplines

defined to carry out the process development,

activities or tasks;

 Section 3: Control. Relates the work products

or appliances, deliverables, results, goals and

measurements that serve as verification

milestones in the execution of an activity or

task;

 Section 4: Additional information. Involves

related processes and methods needed to obtain

a purpose.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

152

Table 1: Comparison of models at a high level.

Section Stereotypes and elements

12207 CMMI COMPETISOFT COBIT PMBOK

Section S1D: Description SD1.1 Process group

x x x x x

SD1.2 Processes

x x x x x

SD1.3 Activities

x x x x

SD1.4 Tasks

x x

Section S2RR: Roles and resources. S2RR1 Roles

x x

S2RR.2 Tools

Section S3C: Control. S3C.1 Artefacts

x x x x

S3C.2 Goals

x x

S3C.3 Metrics

x x

Section S4IA: Additional information S4AI.1 Related processes

x x x

S4AI.2 Methods

In table 1 an example of the structure application

is set out, comparing several models at a high level

of abstraction. This comparison allows us to know if

a model defines or not the process elements in

comparison to other models, taking as a basis the

process elements established in the structure.

If we analyze one of the homogenized models in

the table 1, for example CMMI, we can notice that

according to the process elements of section 1 or

SD1, the match will be equal to: process groups

(Category), processes (purpose, introduction notes,

and specific or generic objectives), activities

(specific and/or generic practices) and tasks

(subtasks).

2.3 Steps for Homogenization of

Models using the Structure

To describe the process elements making use of the

proposed structure, we suggest three steps:

P1. Structure Analysis and Terminology. The

analysis of the structure of a model can turn out to

be one of the initial implicit steps in carrying out the

implementation or improvement project.

Homogenization supports an exhaustive analysis of

terminology, syntaxes and identification of specific

words for the models. Although it won’t be

necessary to perform a rigorous analysis on all

models, it is important to bear in mind that the

analysis will serve as a way to identify criteria that

allow us to establish an objective matching of

information and model process elements in relation

to each one of the structure elements.

P2. Identification of Requirements. Once the

analysis has been done, it is possible to carry out the

identification of requirements of software process to

be homogenized. That allows us to identify which

information of the model will be matched and

organized in the structure elements. The effort

involved in the first two steps depends on the

granularity level and the detail of the model.

P3. Correspondence. Element Correspondence is

the last of the steps to perform in a model

homogenization. Such correspondence shows the

models reorganized in the four sections of process

element described by the proposed structure. The

object of homogenization is to prepare the models

for harmonization in multi-model environments.

3 IMPLEMENTATION OF THE

STRUCTURE

In this paragraph we describe the steps carried out

for the homogenization of models and requirements

contained in ISO 9001:2000 (ISO, 2000).

To perform a first homogenization we decided to

take ISO 9001, for two reasons: (i) because it is one

of the standards which is useful and widespread at

the present time and (ii) because it is one of the most

subjective standards about what to do and how to do

it.

3.1 Homogenization of ISO 9001:2000

We will now give a brief summary of the application

of the steps described, implementing the common

structure in homogenization of the ISO 9001:2000

standard. The analysis of the standard was carried

out in the same way as other authors (Paulk, 1993),

(Paulk, 1994), (Paulk, 1995), (Mutafelija et al.,

2003a), (Mutafelija et al., 2003b) and (Mutafelija et

HOMOGENIZATION OF MODELS TO SUPPORT MULTI-MODEL PROCESSES IN IMPROVEMENT

ENVIRONMENTS

153

al., 2003c), where the requirements are identified by

analyzing the “Shall” and “Should” statements. A

syntax that allowed us to better identify the practices

required by the standard was established , thereby

decreasing a large part of the ambiguity and

subjectivity that is an integral part of trying to

understand it; see table 2.

An example of the result of the homogenization

is shown in Annex 1. On the Annex, clause 4 is

organized and structured according to the quality

management system. In this table we can see that not

all the elements of the four sections of the general

structure found any correspondence, this is because

the standard “doesn´t define” or set out detailed

information for that correspondence.

ISO 9001 neither defines nor documents clearly

many of the requirements that it suggests should be

put into operation (for example activities, tasks and

appliances). Correspondence and formalization of

the information presented in it with regard to process

elements of structure, had made it more possible to

understand the requirements associated with it. An

example is the identification and correspondence of

activities and appliances.

Due to the limitations on space, the information

presented in Annex 1 have been summarized. For

greater detail about the models analyzed, we suggest

the corresponding reference be consulted.

Table 2: Syntax to identify the requirements in ISO 9001.

Syntax Description

1. Shall [verb]

2. Shall [verb] …

and [verb]

This statement indicates the actions,

activities, tasks or procedures that the

organization that will develop it will

have. It is probable that this statement

will be used to describe one or several

actions or to derive processes.

3. Begins for [shall]

or shall [verb] that

Identifies a list of derived requirements of

processes, procedures, activities or tasks.

3. Shall be [verb]

Indicates the characteristics associated

with a process, or possible roles or work

products.

4. Shall [include] Indicates the details that the organization

must include in a process or work product

5. Shall be [verb] +

[by], [to] or [on]

This syntax helps to identify the detail of

some procedures or processes.

The proposed structure has been also applied to

ISO/IEC 12207, CMMI-ACQ V1.2, COMPETISOFT,

COBIT 4.0 and PMBOK.

4 LESSONS LEARNED

Having put this proposal into practice, we have

learned a series of lessons:

 Correspondence of process elements is carried

out according to the investigator’s criterion. A

set of basic criteria for supporting the analysis

and identification of requirements in the

models needs to be found and recorded, along

with the steps suggested for homogenization.

 ISO 9001 neither defines nor sets out clearly

many requirements that it recommends

implementing (for example activities, tasks and

appliances). Correspondence and formalization

of the information shown on it according to the

process elements of the structure, has made it

easier to understand the requirements

associated with it.

 Granularity and flexibility in the incorporation

of process elements allow us to address the

description of new elements that are only

present in specific models. An example is the

correspondence of subpractices of CMMI.

 Analyzing the models from only the

identification of the amount of declarations

and/or requirements, either indicates only their

correspondence (strong, medium or weak) in

relation to other quality models. It might not be

the best option in mapping or comparison of

models, because in this kind of mappings it is

only possible to identify the matches at a high

level of abstraction. This leaves to one side

other characteristics that could turn out to be

important.

 Differences in words and structures used in the

different models, makes the comparison with a

simple mapping at a high abstraction level

improbable. Dealing with that problem by the

translation of a model into the terms of words

and structures of other model, is even more

difficult and less flexible. An option in solving

this problem is to define a guide or process that

guides and provides the tools needed for the

harmonization and integration of different

models.

 Process elements are components of great

importance in the homogenization of models.

Besides this, they make it possible to perform

more objective mappings and or fine grain

comparisons. They allow us to identify at a low

level of abstraction how a model can be

complemented with another in terms of its

process elements and not only according to its

purpose.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

154

5 CONCLUSIONS AND FUTURE

WORK

It is important to emphasize that the models from

different representations are not incompatible and

that there is the possibility of mapping

characteristics to harmonize complementation in the

improvement projects. In this sense, this paper

proposes a common structure as one of the aspects to

support the homogenization of different models that

are used to carry out the process improvement of the

organization. The goal of this work, besides

allowing the organization of the different elements

that are belong to each one of the models in a

common structure for homogenization, is to make

better comprehension and identification of the

relationships or differences between different

models more likely. It will thus be easier to carry out

the identification and analysis of the level of detail

(depth or granularity), overlap, complementarity,

synergy and all the other concepts that may be

present in the harmonization of multi-model

environments.

This work will be the starting point from which a

line of work will be developed. This is related

initially to two aspects mentioned previously: the

depth and overlap levels of different models. Depth

and granularity would be characterized by the level

of detail and the description of each one of the

elements present and defined in a model. The

overlap would be represented by the level of

similarity, coincidence or differentiation between

processes that each one of the models is made up of.

This comparison would be carried out to allow the

organizations to choose the most appropriate process

for providing better practices that help give solutions

to their needs. Additionally, practical reports will be

carried out and written up on and here is where the

benefits of the homogenization and harmonization of

models can be seen easily.

ACKNOWLEDGEMENTS

This work has been funded by the projects:

ESFINGE (TIN2006-15175-C05-05, MEC of

Spain), MECENAS (PBI06-0024, JCCM of Spain),

Collaborative Environment to Support Process

Improvement for the Colombian software industry

(3531-403-20708, Colciencias of Colombia) and

ARMONIAS (PII2I09-0223-7948, JCCM of Spain).

REFERENCES

Acuña, S. T., Antonio, A. D., Ferré, X., López, M. and

Maté, L., 2001. The Software Process: Modelling,

Evaluation and Improvement. Handbook of Software

Engineering and Knowledge Engineering. I. S. K.

Chang. New Yersey (EE.UU), World Scientific. 1

Fundamentals: 193-237.

Benali, K. and Derniame, J. C., 1992. "Software process

modeling: What, who and when." Software Process

Technology, Lecture Notes in Computer Science.

Biffl, S., Winkler, D., Höhn, R. and Herbert Wetzel, 2006.

"Software process improvement in Europe: potential

of the new V-modell XT and research issues."

Software Process: Improvement and Practice 11(3):

229-238.

Cugola, G. and Ghezzi, C., 1998. "Software Processes: a

Retrospective and a Path to the Future." Software

Process: Improvement and Practice 4(3): 101-123.

Derniame, J.-C., Kaba, A. B. and Warboys, B., 1999. The

Software Process: Modelling and Technology.

Software process: principles, methodology, and

Technology. C. Montenegro. Germany, Springer: 1-

12.

Ferchichi, A., Bigand, M. and Lefebvre, H., 2008. An

Ontology for Quality Standards Integration in

Software Collaborative Projects. In First International

Workshop on Model Driven Interoperability for

Sustainable Information Systems (MDISIS'08) held in

conjunction with the CAiSE'08 Conference,

Montpellier, France.

Finkelstein, A., Kramer, J. and Nuseibeh, B., 1994.

"Software process modelling and technology."

Advenced Software Development Series 3.

Fuggetta, A., 2000. Software process: A Roadmap. In

International Conference on Software Engineering

(ICSE), ACM Press.

Fuggetta, A. and Wolf, A. L., 1996. "Software process."

Trends in Software 4: 89-100.

Huff, K., 1996. "Software process modeling." Trends in

Software: Software Process.

ISO, 2000. ISO 9001:2000. Quality management systems -

Requirements. Ginebra, International Organization for

Standardization.

Jalote, P., 1999. CMM in Practice: Processes for

Executing Software Projects at Infosys.

McChesney, I., 1995. "Toward a classification scheme for

software process modelling approaches." Information

and Software Technology 37(7): 363-374.

Mutafelija, B. and Stromber, H., 2003a. Exploring CMMI-

ISO 9001:2000 Synergy when Developing a Process

Improvement Strategy. BearingPonit, Inc. & Hughes

Network Systems. In SEPG 2003, Boston, MA.

Mutafelija, B. and Stromber, H., 2003b. ISO 9001:2000 -

CMMI V1.1 Mappings, Software Engineering

Institute: 31.

Mutafelija, B. and Stromber, H., 2003c. Systematic

Process Improvement Using ISO 9001:2000 and

CMMI.

HOMOGENIZATION OF MODELS TO SUPPORT MULTI-MODEL PROCESSES IN IMPROVEMENT

ENVIRONMENTS

155

OMG, 2008. "Software & Systems Process Engineering

Meta-Model Specification. SPEM 2.0." from

http://www.omg.org/cgi-bin/doc?ptc/07-08-07

Siviy, J., Kirwan, P., Marino, L. and Morley, J., 2008a.

The Value of Harmonization Multiple Improvement

Technologies: A Process Improvement Profesional's

View, Software Ingineering Institute, Carnegie Mellon:

15.

Pardo, C., Pino, F., García, F. and Piattini, M., 2009.

Homogenización de marcos en ambientes de mejora

de procesos multimarco. In XII Conferencia

Iberoamericana de Ingeniería de Requisitos y

Ambientes de Software., Medellín, Colombia.

Siviy, J., Kirwan, P., Morley, J. and Marino, L., 2008b.

Maximizing your Process Improvement ROI through

Harmonization, Software Engineering Institute (SEI).

Carnegie Mellon University: 16. Paulk, M. C., 1993. "Comparing ISO 9001 and the

Capability Maturity Model for Software." Software

Quality Journal 2(4): 245-256.

Siviy, J., Kirwan, P., Renato, V., Peter, K. and Gerhard,

G., 2008c. SEPG Europe 2008. In Multimodel

Improvement in Practice. Paulk, M. C., 1994. A Comparison of ISO 9001 and the

capability maturity model for software, Software

Engineering Institute, CMU/SEI-94-TR-12.

SPICE., 2008. "Enterprise SPICE." An enterprise

integrated standards-base model from

http://www.enterprisespice.com/. Paulk, M. C., 1995. "How ISO 9001 compares with the

CMM." IEEE Software 12(1): 74-83.

Annex 1: Homogenization of Clause 4 of ISO 9001:2000 in the process elements of the common structure.

SD1.1 Processes group

4. System of Quality Management

SD1.2

Processes

ID Clause 4.

Name System of Quality Management

Purpose The organization shall establish, document, implement and maintain a system of quality management

and continually improve its effectiveness in accordance with the requirements of this international

standard.

Description General Requirements. The organization must: literally) identify the processes needed for the system of

quality management and its application across the organization.

Objectives Are defined implicitly.

SD1.3 Activities S3C.1 Artefacts

1. Clause 4.1 concerning the general requirements, referred to in subparagraphs a,

b, c, d, e and f, a set of responsibilities and processes that the organization must

take into account in the System of Quality Management, for example ensure the

availability of resources and information, tracking, measuring, and so on.

Note in this clause also refers to processes to include: management activities,

provision of resources, product creation and measurement

1. In clause 4.2.1, literal a, b, c, d and e, are

listed artifacts which the documentation system

of quality management should include. For

example, the statements of a documented quality

policy and quality objectives, quality manual,

documented procedures required by this

international standard, among others.

2. Clause 4.2.2, literal a), b) and c) lists what the

quality manual should contain. For example, the

scope of the system of quality management,

including details and justification of any

exclusion, the documented procedures

established for the system of quality

management, or reference to, and a description

of the interaction between the processes’ system

of quality management.

2. Note 1 of Clause 4.2.1 describes the term "documented procedure" as referring to

a procedure that must be supported by processes to establish, document it,

implement it and maintain it.

3. Clause 4.2.3 Control of documents relating to the list in the literal a, b, c, d, e, f,

g, a set of controls necessary to carry out this procedure (for example, approve,

review, update documents, and so on).

4. In clause 4.2.4 concerning the Control of records, records that are established,

maintained, remain legible, readily identifiable and retrievable. There should be a

documented procedure to define the controls needed for identification, storage,

protection, retrieval, retention time and disposition of records.

S4AI.1 Related

processes

The system of quality management ISO 9001 can relate clauses of its own or of others, for example in clause

4.2.1 General, subparagraph e), the clause 4.2.4. is related In clause 4.2.2 Quality Manual, literal a), clause 1.2.

is related and in clause 4.2.3. Control of documents clause 4.2.4. is related.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

156