A Data Model for Multimodel Process Improvement

Zador Daniel Kelemen1, Rob Kusters2, Jos Trienekens2, Katalin Balla3, 4 1ThyssenKrupp Presta Hungary Daniel.Kelemen@thyssenkrupp.com, 2Eindhoven University of Technology R.J.Kusters@tue.nl, J.J.M.Trienekens@tue.nl, 3Budapest University of Technology and Economics KBalla@iit.bme.hu, 4SQI Hungarian Software Quality Consulting Institute Balla.Katalin@sqi.hu

Abstract Systematic software process improvement based on multiple software process 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

Introduction

Multimodel 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 welldesigned 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. 1

Terms used In 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 instance the instance of a quality approach element. E.g. prepare for review can be an instance of activity element or a project plan can be an 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 Process Improvement) criteria. We use the term maintainability to 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.

Approach

In developing a data model we distinguished the following two steps: 1. identifying requirements of a data model based on MSPI criteria (what should be done), 2. developing an entity-relationship diagram based on requirements (how should be done). In section 3 we present the requirements for a data model, while in chapter 4 the data model itself is presented.

Identifying requirements for a data model

In 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 of quality approaches will be discovered and reflected in quality approach element mappings. In case of a new version of a quality approach 3 things can happen regarding quality approach elements: deletion, modification and appearance of new quality 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 result can be ensured. The data model should support expandability of multimodel results. Appraisal support: Processes built/enhanced using a multimodel solution should 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 model Adaptability Required entities for storing: 1. Element instances of different versions of quality approaches, 2. Process instances, Expandability 3. Mapping of quality approach element instances to process element instances. Traceability 4. Required entities for storing the mapping of quality approach element instances to process element Appraisal instances (same as requirement 3) support

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 related entities 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 element instances. The five main entities identified above and their related entities are discussed in section 4.

A data model

In 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 shown in 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. in case of CMMI: goals, practices among others) of a quality approach, - the entity QualityApproachElementInstance stores the quality approach 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 the processes, - the entity ProcessElement stores the process element types and their textual and possible graphical representations this latter is needed when a process is also represented in a process modeling language. 4

As we have shown in a case study[11], mappings may be performed on instance level between QualityApproachElementInstance and ProcessElementInstance. Reasons of this: Granularity of processes is not generalized thus the same quality approach 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 be mapped to multiple process elements, e.g. to activities but also to rolesresponsibilities. 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 because it is not trivial which quality approach element instances should be mapped 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 5

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 can be 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 entities ProcessElementInstance, ProcessElementInstanceRelation and ProcessElementIntanceRelationType. The entity ProcessElementInstance 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.

Figure 3 The ProcessElementInstance and its related entities Figure 4 includes entities QualityapproachElement, QualityApproach, QualityApproachAttributeList, QualityApproachAttributeValue and QualityApproachAttirbute. 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 discussed initiatives 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 QualityApproachAttirbute. 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 QualityApproachAttributeList.

Figure 4 The QualityApproach and its related entities Figure 5 shows the QualityApproachElementInstance and its related entities QualityApproachElementInstanceRelation and QualityApproachElementInstanceRelationType. These three entities works similarly to those described in Figure 2.

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 related only to certain instances e.g. the level of requirement in IEEE and ISO standards shall, should may. These attributes are stored in entities QualityApproachElementInstanceAttribute, QualityApproachElementInstanceAttributeValue and QualityApproachElementInstanceAttributeList.

Limitations

The 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 the context.

Conclusion

As 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]. 8

Appendix A data model

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

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

10

References
[1] X. Larrucea, I. Santamaria, and P. Panaroni, A Harmonized Multimodel 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 Berlin Heidelberg, 2012, pp. 121132. M. Mirna and M. Jezreel, Establishing Multi-model Environments to Improve Organizational Software Processes, in Advances in Information Systems and Technologies, vol. 206, . Rocha, A. M. Correia, T. Wilson, and K. A. Stroetmann, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, pp. 445454. M. Kowalczyk and S. Steinbach, Managing Process Model Compliance in 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 Berlin Heidelberg, 2012, pp. 355360. 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: Springer Berlin Heidelberg, 2011, pp. 6173. S. Peldzius and S. Ragaisis, Usage of Multiple Process Assessment Models, in Software Process Improvement and Capability Determination, vol. 349, T. Woronowicz, T. Rout, R. V. OConnor, and A. Dorling, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, pp. 223234. C. G. von Wangenheim, J. C. R. Hauck, C. F. Salviano, and A. von Wangenheim, Systematic Literature Review of Software Process Capability/Maturity Models, in Proceedings of International

[2]

[3]

[4]

[5]

[6]

Conference on Software Process. Improvement And Capability dEtermination (SPICE), Pisa, Italy, 2010.
G. A. Garcia-Mireles, M. Angeles Moraga, and F. Garcia, Development of 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 Reference Models: A Harmonization Framework Applied In Two Case Studies, J. Syst. Softw., Sep. 2012. [9] J. Garzs, F. J. Pino, M. Piattini, and C. M. Fernndez, A maturity model 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 for multimodel software process improvement solutions - based on a review of 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 Software Process Improvement. Eindhoven: Technische Universiteit Eindhoven, 2013. [12] Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, A Process Based Unification of Process-Oriented Software Quality Approaches, [7]
11

[13]

[14] [15] [16] [17]

[18] [19] [20] [21]

in 2009 Fourth IEEE International Conference on Global Software Engineering, Limerick, Ireland, 2009, pp. 285288. Z. D. Kelemen, K. Balla, and G. Boka, Quality Organizer: a support tool in using multiple quality approaches, in Proceedings of 8th International Carpathian Control Conference (ICCC 2007), Strbske Pleso, Slovakia, 2007. M. C. Paulk, A Taxonomy for Improvement Frameworks, presented at the World Congress for Software Quality, 2008. C. P. Halvorsen and R. Conradi, A Taxonomy to Compare SPI Frameworks, Lect. Notes Comput. Sci., vol. 2077, pp. 217235, 2001. J. Siviy, P. Kirwan, L. Marino, and J. Morley, Improvement Technology Classification and Composition in Multimodel Environments. Carnegie Mellon University, Mar-2008. A. Ferreira and R. Machado, Software Process Improvement in Multimodel Environments, in 2009 Fourth International Conference on Software Engineering Advances, Porto, Portugal, 2009, pp. 512517. Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, Towards Applying Text Mining Techniques on Software Quality Standards and Models, Budapest, Technical Report TR201302, Sep. 2013. Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, A Data Model for Multimodel Process Improvement, Budapest, Technical Report TR201303, Sep. 2013. Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, Towards Complexity Analysis of Software Process Improvement Frameworks, Budapest, Technical Report TR201301, Sep. 2013. Z. D. Kelemen, R. Kusters, J. Trienekens, and K. Balla, Selecting a Process Modeling Language for Process Based Unification of Multiple Standards and Models, Budapest, Technical Report TR201304, Sep. 2013.

12