[body]1. Introduction

Companies of software through the processes improvement, seek to reduce costs, increase productivity and enhance the quality of the products resulting from the execution of processes, therefore, identify it as a mechanism to promote competitiveness and efficiency in the software industry (Pino et al., 2006).

This industry is mostly made up of small and medium-sized companies of software (Pymes_ DS), according to Fayad et al. (2000), Richardson & von Wangenheim (2007) and Garcia & Pacheco (2010) approximately 94% of companies who develop software are of this type. One factor that can help to make successful SPI initiatives in Pymes_DS, is to provide technological support through software tools, which support the implementation, monitoring and control of SPI initiatives throughout all its stages, however, currently not has been done enough research in this kind of tools (Garcia & Pacheco, 2010; Muñoz et al., 2012).

It is one of the main drawbacks have various tools which do not interoperate, which mainly hinder the sequence and automatic reuse of information of SPI initiatives and consequently the automation of workflows. The previous disadvantage becomes an aspect of concern because the Pymes_DS required to conduct automated evaluations and improvements in the software process to effectively manage their development processes (Von Wangenheim et al., 2006a). The problem is these tools are designed and developed without governed by an architecture that allows reuse and the communication of the data handled among them, following a logical sequence of Exchange and use of information needs.

To propose a solution to this problem must take into account that interoperability is treated from different levels for its development, the most common and representative in the context of information technology and telecommunications are: (i) technical, (ii) syntactic, semantic (iii) and (iv) organizational (Castrillon, 2013). Technical interoperability refers to elements that allow physically interoperability, the organizational to models and business processes, the syntactic to format data and communication protocols, and semantics to the ability to interpret the information exchanged automatically. Within these levels should be considered that at present many studies on interoperability give great preponderance to the semantic level, within which define first what information exchange between systems, that comply with a basic level of standardization on its data, codes, structures, relationships and constraints, as a principle to keep the meaning of the information exchanged and achieve a common understanding.

From the above, this article presents an architectural model from the information view to support the interoperability of software tools that support the stages of the diagnosing the process and formulating improvements from the PmCompetisoft process (Pino et al., 2009). The model seeks to support the interoperability of such tools to describe in detail the type of information that can be exchanged, as well as the structure of the data to send or receive, their possible values, its semantics, and the restrictions imposed on the use and interpretation of such information, so it is a model that supports the design of the architecture of the software tools.

The model was made from the information managed in the PmCompetisoft process, which is part of the COMPETISOFT project (Oktaba et al., 2007), this way sets a domain on which the model represent information. PmCompetisoft set 5 stages: initiating the cycle, diagnosing the process, formulating improvements, executing improvements and revising the cycle, which are aimed at driving the software process improvement focused on Pymes_DS through the definition of a guide to implement step by step the improvement (Oktaba et al., 2008).

The proposed model arises from the information view since it addresses only the levels of syntactic and semantic interoperability, moreover, because it is independent of the technical elements for the exchange of information between software tools. The model follows the guidelines set by the standard ISO/IEC/IEEE 42010 (systems and software engineering - description of architecture) (ISO et al., 2011), which aims to standardize the practice of the architectural descriptions through the definition of a framework for its development and definition.

In this article, in addition to this introduction, section 2 presents works that address the interoperability of software tools that support SPI initiatives aimed at Pymes_DS. Section 3 shows the concepts involved in the architectural model from the information view. Section 4 describes the research strategy used to develop the architectural model. Section 5 presents an overview of the schemas that make up the model, and a detailed description of the schema corresponding to the Process Evaluation Model. Section 6 describes the evaluation of the model. Finally, section 7 shows the conclusions and future work.

2. Related work

In this Section reviews works that address interoperability from: (i) software tools aimed at Pymes_DS that support the life cycle of SPI and (ii) software in areas such as health and Government. The following describes these two approaches and, finally, the contribution of this work.

2.1 Interoperability in the context of software tools for SPI

There is not enough research in software tools that support comprehensive SPI initiatives for Pymes_DS, from diagnosis and implementation of the improvement, to monitoring or direction of the same (Garcia & Pacheco, 2010; Muñoz et al., 2012). They were initially analyzed tools that support improvement initiatives for Pymes_Ds which comply with some of the following criteria: design to establish interoperability with other applications of the same type or those which allow to automate the generation of the information between the diagnosing the process and development of plans for improvement activities. Below are described at a general level the tools found:

Genesis (Hernández & Flores, 2009): is an assistant that guides the implementation of improvements step by step following PmCompetisoft. This tool allows to import a Process reference model chosen by the Organization through an XML file generated by EPFComposer. Similarly, this tool in its design allows to import information from the evaluation of processes of a file in XML format generated by the EVALTOOL tool (Martinez et al., 2008), this file is raised so it can be used by the application in the automatic identification of the improvement opportunities.

Evaltool: is an environment that allows to evaluate the capacity of organization's processes, using different evaluation models and multiple process reference models. It offers the possibility to define and add new reference processes and new evaluation models. Its design allows to export information in a file in XML of evaluated processes, so that specialized tools in obtaining and managing improvement opportunities to use it.

SysProVal (Garcia & Pacheco, 2010): allows to compare current practices of an organization with the CMMI-DEV practices adapted to Pymes_ DS through a set of questionnaires, in addition, automatically generates a detailed improvement plan which is composed of specific actions, milestones, deliverables, decision points, resources, responsibilities, measures, monitoring mechanisms and strategies for the management and mitigation of risks. It is also oriented in support the automatic communication of improvement information and support learning for project managers.

Tool for evaluation of processes using MoProSoft (Cruz, 2010): allows automatically create improvement plans based on the strengths and weaknesses of the Pymes_DS. The process evaluation is carried out in two ways: first through a questionnaire based on the practices proposed by the MoProSoft reference model (NYCE, 2005), and the second from the automatic mapping between the current software development process of the Pymes_DS and the ideal process posed the MoProSoft model.

The tools presented in the section dealt with research on this type of application, since they mainly seek: (i) fully support the SPI cycle, (ii) automatically generate improvement plans based on the Process reference model and the current state of the organization's processes, and (iii) to reuse the information generated with expert tools to support the stages of improvement projects, specifically the stage of diagnosing the process. On the other hand they present different flaws, in the case of Genesis and Evaltool tools arises the interoperability with other applications in its architectural design but is a part that have not implemented, in addition, the fact that exchange information only between the two tools, does not make them interoperable but compatible. Other flaws seen in SysProVal and the evaluation tool for MoProSoft is that they have modules specialized in evaluation and generation of improvements, but do not allow interoperability with tools expert in other stages, for example in evaluation with other process reference models or evaluation models.

The short existence of software tools that support the SPI initiatives for Pymes_DS and the little or almost no research on interoperability among this type of software, is notorious. To investigate other related word oriented architectures to support the design of software tools that support SPI initiatives, there was no projects that had this approach, which also corresponds with the deficiency in research in such tools (Pino et al, 2006; Martinez et al., 2008; Pavón, 2008; Hernández & Flores, 2009; Garcia & Pacheco, 2010; Muñoz et al., 2012).

2.2 Software interoperability in areas as health and government

There are, however, areas such as health and Government pioneer in research on interoperability between software. These areas considered important syntactic and semantic level to keep the meaning of the information exchanged and achieve a common understanding among systems, this is one of the reasons that the proposal presented in this article was developed in a home at the conceptual level.

These areas were analyzed proposals to formally represent the information that can be exchanged between software tools. Generally proposals for achieving a syntactic and semantic interoperability essentially established the following: identify the information that can be exchanged; they represent such information at the conceptual level using a formal modeling; they pose a set of models and common use data structures to support the exchange of information between software systems; describes the possible values that can take information and restrictions on their use and interpretation; and establish a repository to access models, so they are related or standards. Some of the work in these areas, pioneers around the world are then displayed:

Benson (2012) and Russler et al. (1999) described the references information model (RIM) proposed by Health Level Seven International (HL7), as a static object model that provides a representation explicit semantics and connections lexical that may exist in the information incorporated in clinical messages that are exchanged between the health systems of different domains.

Serrano et al. (2009) described the dual model of development, which defines a reference model for the representation of clinical information, as well as a knowledge model based on archetypes responsible represent clinical concepts of higher semantic level.

Walmsley (2010), Minhap (2014) and MinTIC (2014) presented proposals developed by governments for the exchange of information between state software. They pose to build repositories of models and data structures in common use among the agencies of the State, repositories of models and data structures in common use among the agencies of the State, capable of exchange between software systems. These structures are composed of a series of elements that define the information exchange, which are reusable for applications which did not intervene in its creation and which are continually added to the repositories to represent new information.

2.3 Contribution

Analyzing the works shown in the first part of this section, be can prove that there is little research on interoperability between software tools that support SPI in Pymes_DS and models that identify the information managed in projects of SPI, which structure information to exchange between software tools, to achieve a common syntactic and semantic level understanding. Later works displayed in the second part of this section allowed the main alternatives used to formally represent to conceptual level, the information exchange between software.

From the above, the proposal presented in this article is intended to support the interoperability of software tools that support the SPI initiatives for Pymes_DS through the following contributions: (i) the identification of integral form of the information involved in SPI initiatives based on the stages of process diagnosing and formulating improvements from PmCompetisoft, (ii) an architectural model that allows to represent and structure in detail the information that can be exchanged by software tools which support the stages of process diagnosing and formulating improvements, in order to be a way for these tools share a common understanding to syntactic and semantic level of information that can be exchanged, and (iii) the formal representation at the conceptual level of information exchange using a modeling language.

The proposed model is based on PmCompetisoft, mainly because it takes into account factors considered of success to implement SPI in Pymes_ DS, and because it has been developed from multiple proposals to lead SPI initiatives (Pino et al., 2009), in addition, the model focuses exclusively on the stages of process diagnosing and formulating improvements because they are the most critical to the success SPI initiatives in Pymes_DS, because for these organizations is not easy to incorporate into their processes the improvement opportunities that are unveiled at the stage of process diagnosing (Muñoz et al., 2012).

3. Concepts involved in the architectural model from the information view

To define and structure the information that can be exchanged by software tools that support SPI, was selected the standard ISO/IEC/IEEE 42010. According to this standard, an architectural description is organized into a set of Architecture views (or simply views), each view models a part of the system and meets one or more of the interests of the people involved. A view expressed the architecture of a system according to a Viewpoint, which establishes conventions for the construction, interpretation and analysis of the view. Finally a view consists of one or more architectural models, each model allows to represent the architecture view set.

The viewpoint used for the construction of the architectural model was the Information Viewpoint, proposed by the norm ISO/IEC 10746 (Open distributed processing - Reference model: Architecture -RM-ODP) (ISO et al., 1998), norm that defines essential concepts to describe the architecture of a system exclusively in terms of the semantics of the information, which use the object-based modelling. As the Information Viewpoint does not establish a notation to represent the architecture of a system, was used the notation proposed by the standard ISO/IEC 19793 (UML4ODP) (ISO et al., 2007), which defines a UML profile for the Information Viewpoint. Below are described the main conceptual elements defined the proposed model:

Information object (OI): is defined as a structure or template that allows to represent the information corresponding to the real-world entities. Each OI consists of its attributes and relationships with other OI. Attributes represent one aspect of an entity at a level more granular and relations with other OI represent a set of restrictions on its use.

Instance of an information object: occurs when an OI represents a specific entity of the universe of discourse, taking specific values in its attributes and certain relations with other OI.

Schema: allows to represent a set of particular information. It is composed of several information objects, its possible relationships between them and the restrictions on their relationships and values. The specification of each schema involves: (i) modeling of the OI comprising it, relations between them and the constraints on these relationships and some values that can take certain attributes of each OI, (ii) the description of the information that generally allows to represent, (iii) the description of the leading OI and attributes are not explicit in its meaning, and (iv) the description of the restrictions concerning information allowing to represent certain OI.

The OI that compose each schema are not raised in isolation but that can exist different relationships between OI belonging to different schemas, in addition, an OI specification level is determined according to the atomicity of the entity to which it is related, from one level of abstraction defined.

4. Methodology to develop the architectural model

To address the development of the model was established a research strategy consisting of 4 stages. The implementation of each of the stages was overseen by an expert in process improvement, which in turn formed part of the COMPETISOFT project.

First stage, identification of the general information about the data that may be shared: During this stage was identified the information managed by the PmCompetisoft process during the stages of the diagnosing the process and formulating improvements, as also its restrictions and more important considerations. To identify information was used the technique of documentary review on official documentation from PmCompetisoft, and various components of the improvement model from COMPETISOFT as the PvalCompetisoft process (Pino et al., 2008), PfemCompetisoft process (Pino et al., 2010), templates for work products defined in PmCompetisoft (Trujillo, 2010) and a compilation of case studies about SPI of the COMPETISOFT project founds in Oktaba et al. (2008).

Second stage, identify the possible needs of interoperability: Based on the information identified in the first stage were determined a series of possible needs for interoperability, depending on what information share or import, which can be filed by software tools that support the improvement initiatives based on PmCompetisoft. To meet the needs of interoperability were raised a series of schemas through which it is possible to represent the information associated with every need. For all information concerning to assessment of processes was considered only focus on the evaluation model of standard ISO/IEC 155042 Performing an Assessment (ISO et al., 2003), because according to (Von Wangenheim et al., 2006b) is suitable for carrying out evaluations in Pymes_DS and, in addition, is the COMPETISOFT proposes to use.

Third stage, determination of the information on which specify the schemas: During this stage, new sources of information, were investigated in order to specify in more detail the information identified in the first stage. Some of the main sources of information used were software tools as: GENESIS, Appraisal Assistant (Software Quality Institute, 2014) and Spice 1-2-1 to the ISO/IEC 15504 (HM & S IT - Consulting GmbH., 2014), were also analyzed the official documents of the standard ISO/IEC 15504-2 (ISO et al., 2003), ISO/IEC 15504-5 (ISO et al., 2012), and the chapter about the management of the time on the projects of the Guide to Project Management Body of Knowledge (PMBOK guide)(PMI, 2009).

Fourth stage, specification of the schemas that constitute the architectural model proposed: During this stage specified schemas that constitute the model using the procedure shown in Figure 1. The specification is to create for each of the proposed schemas the information objects, from the infor-mation that generally allows to represent the mation collected in the previous stages. At the schema and a description of the leading OI and end of the procedure is described each schema, attributes that are not explicit in its meaning. this activity consists of the description of the information that generally allows to represent the schema and a description of the leading OI and attributes that are not explicit in its meaning.

Figure 1. Diagram showing the generic procedure for the creation of information objects and specification of a schema.

5. Presentation of proposed architectural model

The model is comprised of 9 schemas, each one allows to represent a set of particular information and all allow to meet interoperability requirements identified in the second phase of the research strategy. These information schemas are as follows: (i) Initiation of improvement cycle, (ii) Management of the personnel involved, (iii) Management of resources, (iv) Planning of activities, (v) Planning of assessment, (vi) Description and modeling of processes, (vii) Evaluation model, (viii) Result of the evaluation of processes and (ix) Planning and formulation of improvements. Figure 2 shows the schemas that make up the proposed model and which relate directly to the stages of initiating the cycle, diagnosing the process and formulating improvements, and the figure 3 shows the relationship between schemas, based on the use of OI among these.

Figure 2. Relationship between the schemas that constitute the model and the stages of Initiating the cycle, Diagnosing the process and Formulating improvements, based on the information that the schemas allow to represent each stage.

Figure 3. Relationship of dependency between the schemas, based on the use of information objects.

The model's schemas can be used in the design of new software tools to establish a common understanding, to syntactic and semantic level, of the information to exchange. Designers of software via the model identify the required information to share, then select the OI that allow represent and structure it, finally the attributes corresponding to each selected OI, data types, constraints, and relationships among OI can be converted into elements which belong to the level of technical interoperability. Similarly, the model can be used to enable interoperability between existing software tools, in this case the model can be used as a reference to establish a canonical data model, which describes a form of common representation of the information produced and consumed by applications, therefore the software tools that send messages must use a translator that allows to convert messages to form canonical which are subsequently sent to the receiving application of information, where are translated and interpreted.

5.1 General description of schemas

Each of the schemas that constitute the proposed model present the following elements: the modeling of the OI that integrates it, used the notation of UML4ODP standard, the description of the information that to general level allows to represent, the description of the leading OI and attributes that are not explicit in its meaning and description of the restrictions concerning the information allowing to represent certain OI. Is then carried out a brief description of the information general that allows to represent each schema:

Management of personnel involved: allows to represent the corresponding information to the staff involved in the implementation of improvement initiatives and the Organization in which the improvement initiative is implemented.

Management of resources: allows to represent the information corresponding to the resources will be planned, assigned and/or managed during the stages and activities of the improvement cycle. Resources are classified in human, financial and technical or physical.

Planning of activities: allows to represent the information corresponding to the planning of the activities and tasks that are made to support the objectives throughout the cycle of improvement, the estimate of time and resources that will lead to its realization and the result of monitoring that involves effort measured and presented problems.

Initiation of improvement cycle: allows to represent the information generated in the activity of initiating the cycle defined in the process of improving PmCompetisoft. This information that guides the Organization through the following phases of the improvement cycle.

Planning of assessment: allows to represent the information corresponding to the assessment planning. This information is that guide the activity corresponding to the assessment of organizational processes.

Description and modeling of processes: allows to represent the information corresponding to a processes reference model that comply with the essential requirements for process reference models, and the fundamental elements that describe a process, raised by the standard ISO/ IEC 15504-2.

Evaluation model: allows to represent the information corresponding to a model of evaluation of processes in accordance with the defined requirements to constitute a model of evaluation according to the standard ISO/IEC 15504-2. The selected requirements were the focused on the elements with which to establish a profile of valued processes.

Result of the evaluation of processes: allows to represent the information corresponding to the current state of the processes of the organization, result of the execution of the diagnosing the processes based on a planning and a process reference and evaluation model. The OI that represent the State of valued processes follow the recommendations framed in the ISO/IEC 15504-2 standard.

Planning and formulation of improvements: allows to represent the information correspon ding to the improvement opportunities associa ted to each valued processes, planning iterations of improvement, the identified risks and process improvement skills training.

Due to space restrictions, then is presented detailing the schema corresponding to the Evaluation model, the same characteristics constitute the rest of schemas, which can be seen in detail in Delgado & Paz (2015).

5.2 Schema corresponding the evaluation model

This schema allows to represent the information corresponding to a process evaluation model according to requirements defined for constitute an evaluation model according the standard ISO/ IEC 15504-2, the modeling of the OI that make up the schema is presented in Figure 4. Below are described the main OI and its restrictions.

Figure 4. Modeling of the information objects constituting the evaluation model schema.

Evaluation model:It allows to represent the priority information that identifies an evaluation model in accordance with the defined requirements to constitute an evaluation model of according to the standard ISO/IEC 15504-2. This OI in its selected capacity level attribute indicates the continuous subset of selected levels of the Measurement framework for process capability of the 15504-2 standard, starting at level 1.

Capacity level: It allows to represent the characterization of the capability of a process implemented on the process evaluation model. This OI is related to a number of Process Attributes by which the achievement of a Capacity level is shown.

Process attribute: It allows to represent the information corresponding to an attribute process, which describes a particular aspect of the process capability. This OI contains a series of achievements, results of the full realization of the process attribute through which is proven their attainment.

Achievement: It allows to represent the information corresponding to a result of the completion of the attribute corresponding to.

Assessment indicator: It allows to represent the information corresponding to the description of an assessment indicator. The indicators may relate to significant activities, practices, resources, results, etc., associated with the achievement of the purpose of a process or the process attributes.

Kind of assessment indicator: It allows to represent the class to which it belongs an assessment indicator. If we take as an example the indicators defined in the evaluation model specified by the standard ISO/IEC 15504-5, a kind of assessment indicator could correspond to one Base Practice, Generic Practice, and Generic Work Product among others.

Measurement element: Allows to represent the information corresponding to a range of values that denote the degree of achievement of the fulfillment of a process attribute, achievement or an assessment indicator.

Restrictions on the OI

The OI evaluation model in its attribute, selected capacity level, single can take numeric values between 1 and 5.

The OI capacity level in its attribute, number of capacity level, single can take numeric values between 0 and 5, and its value must be unique within an OI evaluation model.

In an instance of the OI process attribute, the value of the attribute identifier of the attribute must be unique within an instance of an OI evaluation model.

In an instance of the OI achievement, the value of the attribute identifier of the achievement must be unique within an instance of an OI process attribute.

In an instance of the OI Assessment indicator, the value of the attribute identifier of the indicator must be unique within an instance of the OI process attribute.

In the OI Measurement element the attributes lower percentage and higher percentage single can take numeric values between 0 and 100.

If an instance of the OI assessment indicator in its attribute Dimension of the indicator, it takes the value of 'process capability', this OI can be used as an indicator for the levels of 1 to 5, and if it take the value of 'Compliance with the process', it can only be used as an indicator for the level of capacity 1.

Instances of the OI Achievement associated with an instance of an OI assessment indicator, must be contained in the instance of the OI process attribute with the corresponding the OI Assessment indicator.

6. Evaluation of the model

The model is evaluated using qualitative research Focus Group with modality presence. This evaluation method within the software engineering is a useful method to validate theoretical proposals from the expert opinion, those who experience promotes concepts of high value to accept them or reject them.

To formalize the planning and implementation of the Focus Group was used the proposed process in (Mendoza-Moreno et al., 2013), which aims to guide, organize, and facilitate the implementation and management of the method Focus Group through the definition of elements such as: phases, activities, tasks, roles, and work products.

6.1 Phases of the focus group

Below are described briefly each of the phases carried out:

Planning of the research phase: During this phase was defined the objective of research which was to evaluate the model based on the considerations made during the debate by a group of experts in software development, software architecture and familiar with SPI. Subsequently, materials were prepared for the contextualization of the participants, the questions that guided the session, points to the analysis in the context of the debate, logistics specifications, profile of potential participants, roles, and finally the procedures for the analysis and reporting of results.

Phase of definition of the discussion group: The Focus Group participants were 4 experts in enterprise software architectures, software development and who are familiar with process improvement in Pymes_DS, belong to different institutional affiliations and are recognized researchers and professional in the area of software. The execution of the discussion session was in charge of a rapporteur, and was coordinated by a supervisor and a moderator.

Phase of driving of the debate session: The participants were contextualized 2 weeks prior to the session of debate through a synthesized document of the proposed model and an example of how the model can be applied in a real environment, in addition, preliminarily to the session were presented to participants by means of an Executive exhibition the main conceptual elements that are involved in the model and the description of each of the schemas. Addressing the session, a set of research questions, whose objective was to obtain feedback with critical approach and encourage discussion of experts through their contributions based on the experience, knowledge, and best practices of its work in the field of study were used. At the end of the session, was filled out by each participant a format of general survey which aimed to capture opinions not shared during the Focus Group. As information capture techniques were used audio recording and registration of rapporteur by an actor outside the process.

Analysis of information and reporting of results phase: At this stage it was analyzed the information gathered during the session and established the contributions and observations for the refinement of the model. Procedurally were performed the following activities: (i) contrast between the annotations of report, survey of evaluation of General aspects and support audio files, (ii) establishment of the points of consensus and dissimilar, (iii) determination of the contributions by participants, and (iv) classification of the submissions on positive aspects of the proposed model, aspects to improve and observations. Subsequently, from the results generated from the analysis of the information were carried out the adjustments required to the proposal and conclusions both the architectural model and the implications of employee evaluation process.

6.2 Analysis and discussion of the results of focus group

From the analysis of the contributions made by experts during the execution of the Focus Group, the model, was preliminarily validated equally, were identified to improve, aspects and observations that should be considered during use.

Primarily was established that the proposed model is useful to support the interoperability of tools (new or developed) software from the perspective that information exchange and how it should be structured, this reason is mainly due to the experts consider that the proposed model: (i) defines the fundamental and common information to consider when there is a project to improve based on PmCompetisoft for the stages of the process diagnosing and formulating improvements using the evaluation model of the ISO/IEC 15504-2, (ii) sets (OI) structures that allow to represent the information that can be exchanged between software tools with which to achieve a common understanding of information to communicate, (iii) is easy to use if the software designers have knowledge about the part 2 and 5 of ISO/IEC 15504 Standard and processes improvement in PmCompetisoft (iv) modeling and description of the OI that comprise the schemas are clear and easy to understand to be used when designing the structure of the information exchange between software tools that support SPI for Pymes_ DS and (v) because the model is independent of technical or technological aspects for the exchange of information, it can be adapted to different technologies corresponding to the interoperability technical level.

Also, the experts made contributions focused on refining the model proposed, mainly oriented to describe in more detail how it can be used by software designers and define the concepts of object information, architectural view and architectural viewpoint, in which the model is supported. Another aspect considered by experts is that in principle the learning curve on the model management and information that allows to represent will be slow, fundamentally because of its large number of information objects, and because it is necessary to have knowledge about SPI, PmCompetisoft and part 2 and 5 of the ISO/ IEC 15504 Standard.

Another aspect to take into account is that the model defines the fundamental and common information within the scope of the stages of diagnosing the process and formulating improvements from PmCompetisoft, which sets a clear and initial scope to promote interoperability in the context of SPI research, but experts warn the need to analyses more information of other types of models for example: processes reference models, evaluation models , and models to guide improvement, with the aim of increasing the scope and generality. In addition, they agree that the proposed model should become reference for software tools designers wishing to interoperate, to establish a common understanding to follow the same structure of the information.

7. Conclusions and future work

This article has been presented an architectural model consisting of a set of schemas to represent the information that can be exchanged between software tools that support the stages of diagnosing the process and formulating improvements from PmCompetisoft. The proposed model establishes the necessary elements so that the designers of the software tools can: (i) identify what type of information can be exchanged with other tools, (ii) establish a software architecture which will determine what information exchange and how it should be structured, and (iii) constitute an understanding among tools from a semantic perspective of information.

The model defined and described in a comprehensive manner the information managed during the stages of diagnosis and formulation and the present in part 2 of the evaluation model which proposes the standard ISO/IEC 15504-2, therefore constitutes a contribution to the conceptual framework of SPI for Pymes_DS. This contribution is relevant if one takes into account that the majority of proposals that support SPI do not perform a thorough analysis of the information that can be managed for a SPI project and also because there is very little research on tools that support SPI Pymes_DS-oriented.

One aspect to be considered derived from the development of the model, is that process improvement should be seen as an integrated discipline, and not merely as an assessment of processes organizations and implementation of improvements, mainly because to analyze and identify the information managed during the stages of diagnosing and formulating from PmCompetisoft was established that various types of information are involved , as for example the corresponding: installation of the improvement cycle; the planning of the assessment of processes; the evaluation model ; the process reference model used during the execution of the assessment; the outcome of the assessment of processes; the planning and formulation of improvements; description and modeling of processes and finally cross-cutting information to the entire cycle of improvement related to the planning and management of activities, resources and allocation of staff involved in the improvement. As a result previously identified information becomes possible interoperability needs, which can be taken into account when designing a software tool that supports the management of the information of SPI initiatives.

As the domain of the model is the process improvement PmCompetisoft and for the evaluation of processes, the evaluation model described in part 2 of the ISO/IEC 15504 Standard, this domain allowed to analyze and identify with a high degree of detail in these two proposals, but countermeasure managed information scope and generality of the model is limited, in addition, that those who use the model require knowledge in the management of these proposals.

With regard to the evaluation of the model using the method Focus Group by means of the proposed process in (Mendoza-Moreno et al., 2013), it was noted that the process gave organization to the implementation of the method, without influencing the performance of experts participating in the session, it also allowed preliminarily validate the model by means of the contributions made by experts, since linked in its concept the experience, knowledge and best practices of their work in the field of study.

The evaluation determined initial validity of the schemas that constitute the model, since the Group of experts considered mainly that defined the fundamental and common information that should be considered when there is a project of improvement based on PmCompetisoft for the stages of diagnosing and formulating, and in addition, the schemas establishes the OI that represent the information that can be exchanged between software tools a clear and documented way, with which it would be possible to achieve a common understanding to syntactic and semantic level of information to communicate between software tools.

Several future research works are open, based on the shown proposal, the main include: Complete the schema named description and modeling of processes, adding information objects that represent information corresponding to the definition (modeling and description) of a process, from a specialized language in definition of processes.

Specify new schemas that represent the information corresponding to other evaluation models, for example EvalProSoft or SCAMPI, to achieve that the proposed model has a greater range of use in evaluation tools. Investigate and analyze new sources of information that allow to define new information objects and determine other possible needs for interoperability, to increase the scope and generality of the proposed model.

This work has been supported by the projects: (i) MERliNN Project (Marco de trabajo para la elicitación de requisitos no funcionales basada en la gestión del conocimiento, Universidad del Cauca, VRI-4354), and (ii) MCSS-TI Project (Modelo de Calidad de Servicios Soportados por TI, Universidad del Cauca, VRI-4358). Jose L. Arciniegas and Francisco J. Pino acknowledge the contribution of the University of Cauca, where they work as full professors.[/body]