a data model for multimodel process improvement

7/29/2019 A Data Model for Multimodel Process Improvement

1/12

1

A Data Model for

Multimodel Process Improvement

Zador Daniel Kelemen1, Rob Kusters2, Jos Trienekens2, Katalin Balla3, 41ThyssenKrupp Presta Hungary

[email protected],2Eindhoven University of Technology

[email protected],[email protected] ,3Budapest University of Technology and Economics

[email protected],4SQI Hungarian Software Quality Consulting Institute

[email protected]

Abstract Systematic software process improvement based on multiple softwareprocess improvement approaches is getting more and more emphasised. Despite

a systematic improvement requires mapping of quality approaches to

organizational processes and data shall be stored in a well-designed manner,

storing multimodel results is not yet addressed in detail in the current literature.

In this report we present a data model for multimodel software process

improvement which allows storing multimodel results in a maintainable way.

Keywords: quality approach, data model, mapping, harmonization, unification,model, standard, improvement framework, software quality, maintainability,

adaptability, expandability, traceability, appraisal support

1 IntroductionMultimodel process improvement is becoming more and more emphasized by the

appearance of new (and new versions of prior) quality approaches[1] [5]: see e.g.

the review of 52 Software Process Capability/Maturity Models in [6] or a review

of developing maturity models in [7].

The problem of multimodel process improvement is even more striking when

differences in content, structure, granularity and auditing are needed to be taken

into the consideration when harmonizing multiple approaches[8], [9].

The objective of this technical report is to present a data model for

multimodel software process improvement. The data model allows storing most

important elements of multimodel software process improvement. Having a well-

designed data model is crucial for assuring the maintainability[10] of the results

of the multimodel software process improvement [11], [12] and can provide a

basis for multimodel solutions and tools[13]. Before going into details of the data

model we clarify basic terms used.
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/12

2

Terms usedIn on-going research in the area of software process improvement, different

terms are used for software quality approaches. Examples are: quality standard,quality assurance method, improvement framework [14], software process

improvement (SPI) framework [15], quality model, improvement technology [16]

and process improvement model [17] among others. In order to emphasize that

each standard (e.g. ISO 9001 or ISO 12207), method and (improvement)

technology framework (e.g. CMMI, SPICE) is a specific approach to software

quality; we call each of them an approach.

An approach which is connected to quality is called quality approach.

We call quality approach element(class) an element of a quality approach

(e.g. activity, artifact, role, chapter or requirement) and quality approach

element instancethe instance of a quality approach element. E.g. prepare for

review

can be an instance of

activity

element or a

project plan

can bean instance of the artifact element. We use the terms quality approach

element and quality approach element class as synonyms.

Multimodel process improvement (abbreviated as MSPI) mean process

improvement based on multiple software quality approaches.

In this research we call the multimodel problem the problem of the

simultaneous usage of multiple quality approaches. We call multimodel initiative

all the initiatives which are aimed at solving the multimodel problem. An

initiative which solves the multimodel problem is called a (multimodel) solution.

The output (or result) of a multimodel initiative is called a multimodel result.

In [10] criteria were proposed that represent a multimodel solution of

sufficient quality. These are called MSPI (Multimodel Software ProcessImprovement) criteria.

We use the term maintainabilityto cover the following set of MSPI criteria:

adaptability, expandability, traceability and appraisal support.

This data model is not an ultimate solution for the maintainability, it is

rather a general discussion on how such a database can be built with the purpose

of enhancing maintainability.

2 ApproachIn developing a data model we distinguished the following two steps:

1. identifying requirements of a data model based on MSPI criteria (whatshould be done),

2. developing an entity-relationship diagram based on requirements (howshould be done).

In section 3 we present the requirements for a data model, while in chapter

4 the data model itself is presented.


3/12

3

3 Identifying requirements for a data modelIn this section we identify requirements for a data model. Requirements are

identified based on the maintainability issues of the multimodel results.Traceability: Traceability of multimodel results is crucial to prove the

validity of the multimodel solution. For example in the process based unification

(PBU) process[11], [12] both processes and quality approaches are decomposed,

and clear relationships (mapping) among process element instances and quality

approach element instances is identified. These relationships describe

traceability.

In order to ensure adaptability and expandability of multimodel results, a

data model should provide a solution for including new (versions of) quality

approaches into the multimodel results.

Adaptability: In order to ensure adaptability, changes in the new versions ofquality approaches will be discovered and reflected in quality approach elementmappings. In case of a new version of a quality approach 3 things can happen

regarding quality approach elements: deletion, modificationand appearance of

newquality approach elements. A multimodel solution can be supported by a

database structure to store the quality approach element process element

mappings and handle adaptability issues related to these three kinds of changes.Expandability: The expandability of the multimodel results will be ensured

by an iterative process, so that in each iteration, a new quality approach can be

added to the multimodel result. When a new quality approach is included into

the unification process then a new iteration should be performed. If such an

iterative process can be defined, then the expandability of the multimodel resultcan be ensured. The data model should support expandability of multimodel

results.

Appraisal support: Processes built/enhanced using a multimodel solutionshould be conformant to multiple source quality approaches, and there should

be a possibility to appraise this conformity. Using a well-documented mapping,

the relations between the multimodel results (process model(s) resulting from

the application of a multimodel solution) and source quality approaches is needed

to be ensured.

Table 1 Requirements of a data model

MSPI criteria Implementation requirements for a data modelAdaptability Required entities for storing:

1. Element instances of different versions of qualityapproaches,

2. Process instances,3. Mapping of quality approach element instances to

process element instances.

Expandability

Traceability 4. Required entities for storing the mapping of qualityapproach element instances to process element

instances (same as requirement 3)

Appraisal

support


4/12

4

Table 1 contains the MSPI criteria and requirements against the data model

which were formulated by us based on discussion above and our data modeling

experience. According to Table 1 the following main entities and their relatedentities should be represented in the data model.

For requirement 1 identified in Table 1:

1. quality approach elements (type level),2. quality approach element instance (instance level).

For requirement 2 identified in Table 1:

3. textual and graphical process model elements (type level),4. textual and graphical process model element instances (instance

level).

For requirements 3 and 4 identified in Table 1:

5. mapping quality approach element instances to process elementinstances.The five main entities identified above and their related entities are discussed

in section 4.

4 A data modelIn this section we present elements of a data model which were developed to

reflect requirements identified in the previous section. The entity-relationship

diagram was developed by using the free ER modeler tool MySQL Workbench.

We used MySQL data types, but these can easily be substituted in case of using

other databases. The emphasis is more on entities and relations than on data

types and attributes. However some example attributes and data types are shownin figures to illustrate the purpose of entities.

Figure 6 and Figure 7 in the appendix show an overview of the five major

parts (quality approach element, quality approach element instance, mapping,

process instance and process language) of the ER model.

Figure 1 shows an overview of main entities and their relations:

- the entity QualityApproachElement stores the element types (e.g. incase of CMMI: goals, practices among others) of a quality approach,

- the entity QualityApproachElementInstance stores the qualityapproach element instances (e.g. in case of CMMI instances of goals,

practices among others),- the entity QualityApproach_Process_Mapping stores the relation among

quality approach element instances and process element instances, this

is the main entity which provides traceability and appraisal support

through mapping,

- the entity ProcessElementInstance stores the element instances of theprocesses,

- the entity ProcessElement stores the process element types and theirtextual and possible graphical representations this latter is needed

when a process is also represented in a process modeling language.


5/12

5

As we have shown in a case study[11], mappings may be performed on

instance level between QualityApproachElementInstance and ProcessEle-

mentInstance. Reasons of this:

- Granularity of processes is not generalized thus the same qualityapproach element instance can be mapped to process, subprocess or

activity depending on granularity level of the process (description).

- Weakly structured textual information (e.g. shall statements) could bemapped to multiple process elements, e.g. to activities but also to roles-

responsibilities. One such statement could be: The inspection leader shall

invite inspection participants. In this case the statement can be mapped

to at least one role as a responsibility and to an activity.

- A mapping should always be performed on instance level. This is becauseit is not trivial which quality approach element instances should bemapped to which process element instances. (This could be supported by

automatic recognition of similarities between the text of quality approach

element instances and process element instances, but this still cannot

provide the type level mapping, because automatic mapping of texts

should also be confirmed by users.)

If mapping could be performed on type level, an M:N relation and entity

between the entities QualityApproachElement and ProcessElement could be

included.

Figure 1 Main entities of a data model

Figure 2 shows a view of the ProcessElement entity and its related entities.

The ProcessElement entity describes how textual and graphical attributes of a

process element can be stored. For simplicity reasons, attributes related to the

graphical representation were not included into the table such as size or position.

The ProcessElement entity stores the possible process elements of a process

modeling language such as activity, role, inputs-outputs, etc. The description of

the process modeling language is included into the ProcessModelingLanguage

entity. It can happen that different process modeling languages can have the


6/12

6

very same element (e.g. the role element is present in multiple languages,

therefore there is an additional entity called ProcessModelingLanguageElement

in which the association of process elements and process modeling languages canbe stored.

Process elements can be connected to each other, but not all kind of

connections are allowed in a process modeling language, therefore the table

AllowedProcessElementRelation stores the allowed relations among process

elements. The types of allowed relations between two process elements are stored

in the AllowedProcessElemenetRelationType entity.

Figure 2 The ProcessElement and its related entities

Figure 3 presents the entitiesProcessElementInstance

,ProcessElementIns-

tanceRelation and ProcessElementIntanceRelationType . The entity Process-

ElementInstance is an instance of a ProcessElement shown in Figure 2.

Examples of peer review process element instances in BPMN could be: instances

of subprocesses (e.g. prepare for peer review), roles (e.g. author or reviewer) or

instances of any other process elements. The relation between two process

element instances is stored in the ProcessElementInstanceRelation entity. Such

relations among many others can be for example:

- parent-children relation in case of process subprocess,- process flow relation (which subprocess follows the other subprocess),- activity role (which role is needed to perform a certain activity),- new version of, e.g. in case if a tool built on this database allows storing

multiple versions of processes, relations between versions can be stored

in the proposed data model.

- tailored from if an organization describes processes on multiple levels(e.g. on theoretical, organizational and project levels).

Since we do not know the full extent of the possible relation types, relation

types are stored in ProcessElementInstanceRelationType and this structure

allows the addition of new types over the time.


7/12

7

Figure 3 The ProcessElementInstance and its related entities

Figure 4 includes entities QualityapproachElement, QualityApproach,

QualityApproachAttributeList , QualityApproachAttributeValue and Quali-

tyApproachAttirbute.

The QualityApproach entity includes the attributes of a quality approach;

it can have elements which are stored in the entity QualityapproachElement.

A further requirement against such a data model could be an enhanced

support of the selection of quality approaches. In [11] and [18] we discussedinitiatives which help selecting from quality approaches based on their attributes.

Since these attributes are quite flexible and not ultimately set and probably will

be developed further in the future, we store these attributes using three entities:

QualityApproachAttributeList , QualityApproachAttributeValue and Quali-

tyApproachAttirbute. Possible quality approach attributes could be: origin,

popularity, assessment approach, goal, scope among many others. As these

attributes can have various types of values, values are stored in a separate entity,

QualityApproachAttributeValue. We also allow any number of attributes for

quality approaches, this is represented by the entity QualityApproachAttribu-

teList.

Figure 4 The QualityApproach and its related entities

Figure 5 shows the QualityApproachElementInstance and its related

entities QualityApproachElementInstanceRelation and QualityApproachEle-

mentInstanceRelationType. These three entities works similarly to those

described in Figure 2.


8/12

8

Similarly to process element instance relation types, possible quality

approach element instance relation types can be (but not restricted to): part of

/ contains, refers to, requires or version of.

Figure 5 The QualityApproachElementInstance and its related entities

Quality approach element instances can have attributes which are relatedonly to certain instances e.g. the level of requirement in IEEE and ISO standards

shall, should may. These attributes are stored in entities QualityApproachEle-

mentInstanceAttribute, QualityApproachElementInstanceAttributeValue

and QualityApproachElementInstanceAttributeList .

5 LimitationsThe main limitation of the data model presented in this report is that it is general

and covers only most important aspects of maintainability of multimodel results.

Therefore when building a software the data model should be tailored for thecontext.

6 ConclusionAs we introduced, multimodel software process improvement is getting more and

more emphasised. Despite a systematic improvement requires mapping of quality

approaches to organizational processes and data shall be stored in a well-designed

manner, storing multimodel results is not yet addressed in detail in the current

literature. In order to fill this gap, the goal of this report1 was to present a data

model for multimodel software process improvement.

In section 3 general requirements were identified for a data model for

supporting maintainability of multimodel results. The maintainability criterion

was decomposed to adaptability, expandability, traceability and appraisal

support and addressed accordingly. In section 4 main entities of a data model

which is aimed at supporting maintainability were discussed. The data model

itself does not give full maintainability support, however a basic discussion is

given on what data should such a tool handle.

1 This report has been published as a part of a PhD thesis [11] and it is part of

a series of technical reports which include: [18] [21].


9/12

9

Appendix A data model

Figure 6 An overview of the data model (part 1)


10/12

10

Figure 7 An overview of the data model (part 2)


11/12

11

References

[1] X. Larrucea, I. Santamaria, and P. Panaroni,A HarmonizedMultimodel Framework for Safety Environments, in Systems, Software

and Services Process Improvement, vol. 301, D. Winkler, R. V.OConnor, and R. Messnarz, Eds. Berlin, Heidelberg: Springer BerlinHeidelberg, 2012, pp. 121132.

[2] M. Mirna and M. Jezreel, Establishing Multi-model Environments toImprove Organizational Software Processes, in Advances inInformation Systems and Technologies, vol. 206, . Rocha, A. M.Correia, T. Wilson, and K. A. Stroetmann, Eds. Berlin, Heidelberg:Springer Berlin Heidelberg, 2013, pp. 445454.

[3] M. Kowalczyk and S. Steinbach, Managing Process Model Compliancein Multi-standard Scenarios Using a Tool-Supported Approach, in

Product-Focused Software Process Improvement, vol. 7343, O. Dieste,A. Jedlitschka, and N. Juristo, Eds. Berlin, Heidelberg: Springer BerlinHeidelberg, 2012, pp. 355360.

[4] C. Pardo, F. J. Pino, F. Garca, M. Piattini Velthius, and M. T.Baldassarre, Trends in Harmonization of Multiple Reference Models,in Evaluation of Novel Approaches to Software Engineering, vol. 230,L. A. Maciaszek and P. Loucopoulos, Eds. Berlin, Heidelberg: SpringerBerlin Heidelberg, 2011, pp. 6173.

[5] S. Peldzius and S. Ragaisis, Usage of Multiple Process AssessmentModels, in Software Process Improvement and CapabilityDetermination, vol. 349, T. Woronowicz, T. Rout, R. V. OConnor, andA. Dorling, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013,

pp. 223

234.[6] C. G. von Wangenheim, J. C. R. Hauck, C. F. Salviano, and A. vonWangenheim, Systematic Literature Review of Software ProcessCapability/Maturity Models, in Proceedings of InternationalConference on Software Process. Improvement And CapabilitydEtermination (SPICE), Pisa, Italy, 2010.

[7] G. A. Garcia-Mireles, M. Angeles Moraga, and F. Garcia, Developmentof maturity models: a systematic literature review, 2012, pp. 279283.

[8] C. Pardo, F. J. Pino, F. Garcia, M. T. Baldassarre, and M. Piattini,From Chaos To The Systematic Harmonization Of Multiple ReferenceModels: A Harmonization Framework Applied In Two Case Studies,J.Syst. Softw., Sep. 2012.

[9] J. Garz

s, F. J. Pino, M. Piattini, and C. M. Fern

ndez,

A maturitymodel for the Spanish software industry based on ISO standards,Comput. Stand. Interfaces, vol. 35, no. 6, pp. 616628, Nov. 2013.

[10] Z. D. Kelemen, R. Kusters, and J. Trienekens, Identifying criteria formultimodel software process improvement solutions - based on a reviewof current problems and initiatives,J. Softw. Evol. Process, vol. 24, no.8, pp. 895909, Dec. 2012.

[11] Z. D. Kelemen, Process Based Unification for Multi-Model SoftwareProcess Improvement. Eindhoven: Technische Universiteit Eindhoven,2013.

[12] Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, A ProcessBased Unification of Process-Oriented Software Quality Approaches,


12/12

12

in 2009 Fourth IEEE International Conference on Global SoftwareEngineering, Limerick, Ireland, 2009, pp. 285288.

[13] Z. D. Kelemen, K. Balla, and G. Boka, Quality Organizer: a supporttool in using multiple quality approaches, in Proceedings of 8thInternational Carpathian Control Conference (ICCC 2007), StrbskePleso, Slovakia, 2007.

[14] M. C. Paulk, A Taxonomy for Improvement Frameworks, presentedat the World Congress for Software Quality, 2008.

[15] C. P. Halvorsen and R. Conradi, A Taxonomy to Compare SPIFrameworks,Lect. Notes Comput. Sci., vol. 2077, pp. 217235, 2001.

[16] J. Siviy, P. Kirwan, L. Marino, and J. Morley, ImprovementTechnology Classification and Composition in MultimodelEnvironments. Carnegie Mellon University, Mar-2008.

[17] A. Ferreira and R. Machado, Software Process Improvement inMultimodel Environments, in 2009 Fourth International Conference onSoftware Engineering Advances, Porto, Portugal, 2009, pp. 512517.

[18] Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, TowardsApplying Text Mining Techniques on Software Quality Standards andModels, Budapest, Technical Report TR201302, Sep. 2013.

[19] Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, A Data Modelfor Multimodel Process Improvement, Budapest, Technical ReportTR201303, Sep. 2013.

[20] Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, TowardsComplexity Analysis of Software Process Improvement Frameworks,Budapest, Technical Report TR201301, Sep. 2013.

[21] Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, Selecting aProcess Modeling Language for Process Based Unification of MultipleStandards and Models, Budapest, Technical Report TR201304, Sep.2013.

a data model for multimodel process improvement

Documents