Heiko Kattenstroth
email: heiko.kattenstroth|david.heise@uni-duisburg-essen.de

David Heise

Towards a Method for IT Service Management

Keywords: IT service management, service life cycle, domain-specific modelling, enterprise modelling

To cope with the challenges in IT service management, methods are required that purposefully reduce the complexity inherent to enterprises -with regard to both business and IT -, facilitate communication among groups of stakeholders and support the management of IT services along their life cycle. In this paper we investigate the potentials of an enterprise modelling approach to IT service management and reflect upon design alternatives for corresponding modelling constructs. We present research in progress that is intended as foundation for discussion with and discursive evaluation by peers and domain experts.

Motivation

Today's IT organisations are confronted with remarkable challenges: First, they have to deal with the tremendous complexity of present day enterprises and their IT. A complexity that results from the multitude of IT platforms, networks, and information systems as well as their interrelations. At the same time they are expected to efficiently support the business and to drive innovations, which requires IT managers to account for the multifaceted dependencies between IT and the enterprise's goals, organisational structures, and business processes. Furthermore, aligning the IT to the business demands the participation of various stakeholders from business and IT, such as executives, end-users, and IT experts. Each of them has a different professional background, perspective on IT and business, and -even more important -technical language. As a result IT managers have to deal with language barriers, which hamper communication and collaboration between the stakeholders and consequently compromise the efficiency of the IT organisation.

In response to these challenges, the concept "IT service" emerged as an innovative approach to manage the relationship between business and IT. In current business practice, IT services are widely considered to be of outstanding relevance for IT management, as they, for example, represent the IT organisation's outcome that is used in the company's business processes and serve as a reference between IT and business stakeholders as well as between the different stakeholders inside the IT organisation. Unfortunately the introduction of this additional concept seems to have an ambivalent effect: While it is suited to reduce complexity on the one hand, it also adds to the complexity of IT management on the other. IT organisations are, thus, urged to enforce development, implementation, and maintenance of their IT services -the IT service management (ITSM) -in a structured and systematic manner.

To cope with these challenges, methods are required that purposefully reduce the complexity inherent to enterprises -with regard to both business and IT -, facilitate communication among groups of stakeholders, and support the management of IT services along their life cycle. In this respect, several authors highlight the prospects of supporting ITSM through conceptual models in general and enterprise models in particular (e.g., [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF][START_REF] Frank | ITML: A Domain-Specific Modeling Language for Supporting Business Driven IT Management[END_REF]). While current enterprise modelling approaches already provide preliminary conceptualisations for IT services (i.e., provide dedicated abstractions that, among others, reduce the complexity), their support for IT service management is still limited. Against this background we propose to extend a method for enterprise modelling to specifically addresses the requirements and challenges of IT service management. In this paper we present a part of this research in progress: First, we investigate the potentials of an enterprise model-based support for ITSM. In contrast to prior work, we deliberately analyse the potentials throughout the different phases of the service life cycle. And second, we propose corresponding modelling constructs in extension to existing approaches for enterprise modelling. Therefore, we synthesise and reflect upon promising enhancements and discuss design alternatives. The results of our analysis are intended as working drafts and foundation for discussion with and discursive evaluation by peers and domain experts.

In the next section we introduce the ITSM domain. In Section 3, we discuss approaches for enterprise modelling and how they can be used as a foundation for ITSM. The general prospects of such an approach are investigated in Section 4. In Section 5, we reflect on current work on domain-specific modelling constructs for ITSM and discuss design alternatives. Section 6 presents concluding remarks.

IT service management: Life Cycle and Requirements

IT service management seems to have evolved to an essential part of IT management that focuses on development, implementation, and maintenance of IT services. While in the last century many authors conceptualised (IT) services as "counterpart" to physical goods and products -applying the criteria of intangibility, heterogeneity, inseparability, and perishability -we follow Vargo and Lusch's [START_REF] Vargo | The 4 service marketing myths: Remnants of a goods-based, manufacturing model[END_REF] arguments in that a segregation between goods and services cannot be maintained. Rather we see "IT service" as a broad term that covers any IT-related outcome of the IT organisation that is used by internal (e.g., business departments) or external customers (e.g., companies at the market). In this diction, the service term incorporates both tangible and intangible aspects and corresponds to 'product'. Examples for IT services can be found at different levels of abstraction, ranging from fine-granular IT services like "Edit Customer Data" to broad ones like "Providing ERP Application". A method for ITSM should therefore provide a conceptualisation of IT service that covers the various, generic interpretations of service, their dependencies and other interrelations.

Moreover, IT service management can be understood as a paradigm that acknowledges the importance of aligning IT with the business ("IT/Business Alignment"). Thus, the key focus of IT management shifted from technology, i.e., hardware and software, to IT as an instrument that aims to support people in creating a business value and is strongly motivated by the demand for cost control and customer orientation. Thereby it seems accepted that IT does not provide a business value per se, but "must be part of a business value creating process with 'other' IS and organisational factors operating in a systematic manner" and that it includes "IT people and management, routines, and policies or the organisational system including non IT-people and management, business processes, knowledge assets, relationship assets, culture structure, and policies" [18, p. 26]. Accordingly, IT is not an end in itself. Instead, it is supposed to support an organisation's business processes, enterprise goals, and -in general -its competitiveness. Hence, adequate management of IT services requires a profound understanding of the organisational context and interdependencies between business and IT. At the same time, ITSM has to account for the technical context, too, since many IT services will be realised by hardware and software. Consequently, a method for IT service management has also to address the technical perspective and provide concepts representing the IT domain.

ITSM frameworks such as ITIL [21] aim at systematically managing the offerings of the IT organisation as services for the business by means of managing the service portfolio. Service portfolio management focuses, amongst others, on reuse of existing services and the strategic development of new offerings and capabilities to serve the customers, which recommends managing IT services during all phases of their life cycle. Moreover, if instruments do not support IT service management at all stages of the life cycle -i.e., different instruments have to be applied to cover the different phases -negative effects such as lack of integrity, loss of information, and frictions in communication are likely that finally will hamper the efficiency of IT service management in general. Based on the work from Jin and Ray [START_REF] Jin | Business-oriented development methodology for it service management[END_REF], Kohlborn et al. [START_REF] Kohlborn | Business and software service lifecycle management[END_REF], and Riedl et al. [START_REF] Riedl | Quality management in service ecosystems[END_REF], Figure 1 illustrates a synopsis of IT service life cycle phases along with exemplary activities. A method for ITSM thus has to provide support for all phases.

Table 1 summarises the requirements for a method that aims to support IT service management. Based on our experience with ITSM frameworks, methods, and tools, we conclude that there is currently no instrument or methodical sup- 1. Requirements for a method in support of IT service management port available that addresses all requirements. For instance, the ITIL framework provides high-level guidelines for IT service management processes and explicitly spans the service life cycle, but does neither address the business context nor provide concepts at detailed technical level; approaches like "Model Driven SOA" [START_REF] Zhang | SOMA-ME: A platform for the model-driven design of SOA solutions[END_REF] support the technical design and implementation of (web) services, but do hardly address the complexity of the ITSM domain, foster communication with business or account for organisational context. Our research is therefore based on the assumption that both demand and potentials exist for methods and tools that fulfill the described requirements and support IT service management.

Conceptual Background

Enterprise modelling (EM) approaches such as ARIS [START_REF] Scheer | Architecture of integrated information systems: Foundations of enterprise modelling[END_REF], MEMO [START_REF] Frank | Multi-Perspective Enterprise Modeling (MEMO): Conceptual Framework and Modeling Languages[END_REF] or Archi-Mate [START_REF] Lankhorst | Enterprise architecture at work: Modelling, communiation and analysis[END_REF][START_REF]ArchiMate 1.0 specification[END_REF] seem to provide a promising foundation for several reasons: (1) They serve to structure an enterprise by providing purposeful abstractions of IT and the surrounding action systems (Req. 1 ). (2) They, therefore, make use of domainspecific modelling languages (DSMLs), thereby offering a consistent, intuitive and semantically rich modelling [START_REF] Kelly | Domain-specific modeling: Enabling full code generation[END_REF]. (3) They usually build upon an elaborate meta model that already includes organisational and technical context, such as for goal, business process or organisational structure modelling on the one hand and for modelling the IT organisation on the other (Req. 4 & 5 ). ( 4) They provide stakeholders with specific and illustrative views on a company at various organisational levels, such as on value chains, business processes, or IT landscapes. Since the DSMLs are seamlessly integrated, they allow for comprehensive analyses fostering IS/Business Alignment and communication among business and IT stakeholders (Req. 2 ). Figure 2 illustrates an example of an enterprise model based on the MEMO family of modelling languages. The excerpt shows models at different levels of an organisational hierarchy, which is intended to address different stakeholders: A value chain and goal model at strategic level, a business landscape and business process model at organisational level, and models of the IT organisation at IT level.

In this regard, some approaches to enterprise modelling already provide preliminary meta types representing an "IT service", though their conceptualisations of the (IT) service term, the resulting meta types and the corresponding

Legend

Increase customer satisfaction through an attractive value proposition Fig. 2. Example of an Enterprise Model that integrates models of an IT landscape with models of associated business processes from various perspectives associations vary notably. Furthermore, these concepts have usually not been developed with dedicated ITSM support in mind. Moreover, to our best knowledge, approaches that propose an enterprise modelling-based approach as foundation for IT service management, such as Braun and Winter [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF] and Frank et al. [START_REF] Frank | ITML: A Domain-Specific Modeling Language for Supporting Business Driven IT Management[END_REF], do not illustrate how to support IT service management in detail, for instance, for service portfolio management.

At the same time, various authors outside the EM community propose specific DSMLs -at least in the broadest sense -for conceptual modelling of services. For instance, Quartel el al. [START_REF] Quartel | COSMO: A conceptual framework for service modelling and refinement[END_REF] introduce modelling concepts and a preliminary notation that allow to model services as sequences of user-provider interactions. Hence, they conceptualise services as counterpart to products and goods; technical or organisational context is not considered. An approach that specifically addresses IT service management is presented by Correira and Abreu [START_REF] Correia | Integrating IT Service Management within the Enterprise Architecture[END_REF][START_REF] Correia | Defining and Observing the Compliance of Service Level Agreements: A Model Driven Approach[END_REF] as work in progress. They suggest a DSML that aims to support the management of service level agreements over their life cycle; a meta model is not (yet) provided. A meta model for ITSM is, instead, provided by Uebernickel et al. and Ebert et al. respectively [START_REF] Ebert | A service model for the development of management systems for it-enabled services[END_REF][START_REF] Uebernickel | Is serviceengineering: A process model for the development of is services[END_REF]. Their metatype "IT Service" is embedded in organisational and technical context in that it is associated to meta types representing business processes and users as well as IT resources (e.g., "Information", or "Hardware"). It seems their meta model is not intended to be used for graphical modelling, since they do neither discuss a notation nor provide examples of how to apply the concepts. As attributes are missing from the meta model, the semantics of its concepts are mainly up to interpretation.

Against this background, the paper at hand extends prior work in two aspects: (1) We exemplarily illustrate how enterprise modelling can support ITSM during different phases of the life cycle; (2) we enhance current work by synthesising, reflecting, and enhancing current language specifications for IT service management as well as discussing corresponding design alternatives. Our research follows a design research process that is grounded on a research method configured for the epistemological particularity of research on modelling methods (for a detailed description, see [START_REF] Frank | Towards a Pluralistic Conception of Research Methods in Information Systems Research[END_REF] and [START_REF] Strecker | MetricM: A Modeling Method in support of the Reflective Design and Use of Performance Measurement Systems[END_REF]) and applies a method for designing domain-specific modelling languages [START_REF] Frank | Outline of a Method for Designing Modelling Languages[END_REF].

Outline of EM-based IT service management

This section illustrates the prospects of supporting life cycle spanning IT service management with a dedicated method, which is based on a domain specific modelling language and is integrated with an approach for enterprise modelling as described in Sec. 3. With respect to space restrictions, the example is limited to selected activities of the life cycle. The application scenario, as well as the specification of the design alternatives in Sec. 5, are based on the MEMO approach. Thus the present models are illustrated presuming modelling languages and notation of the MEMO language family, for instance, for strategic, organisational, and IT landscape modelling [START_REF] Frank | Multi-Perspective Enterprise Modeling (MEMO): Conceptual Framework and Modeling Languages[END_REF][START_REF] Frank | ITML: A Domain-Specific Modeling Language for Supporting Business Driven IT Management[END_REF] as well as specific extensions like for risk or indicator modelling [START_REF] Strecker | MetricM: A Modeling Method in support of the Reflective Design and Use of Performance Measurement Systems[END_REF][START_REF] Strecker | RiskM: A Multi-Perspective Modeling for IT Risk Assessment[END_REF]. It is, however, important to note that shown diagrams and meta models are not intended to predetermine a specific enterprise modelling approach; instead, they serve as an illustration of principle application and design decisions in context of enterprise model-based ITSM.

Figure 3 illustrates the application scenario: In the analysis phase the desired functionalities, constraints, and expectations of the business stakeholders have to be captured as requirements. With regard to Req. 4 it seems promising to use models of the organisational context (e.g., business processes, organisational structure, and business goals) since they provide an overview of the business processes the IT service will be used for and the business goals (and restrictions) it aims to support. These models are enriched with a description of the required functionalities (see 1 in Fig. 3). In contrast to common requirements engineering approaches such as [START_REF] Davis | Software requirements: Objects, functions, and states[END_REF][START_REF] Wieringa | Requirements engineering: Frameworks for understanding[END_REF] these requirements are integrated with the enterprise models in that they are associated to the concepts they affect. The required functionalities are then structured as potential IT services ("service candidates") based on their scope, purpose and similarities. To foster reuse, the resulting candidates are mapped against existing IT services, and the functionalities they offer, using the IT service model ( 2). The IT service model contains the services and their functionalities, dependencies (such as "uses" or "requires") as well as similarities ("similar to") and specialisation/generalisation relationships between IT services. In this regard, the objective of this service mapping is to identify services that can be reused, extended or adapted to fulfill the requirements. This allows for a comprehensive and sustainable management of the IT service portfolio. To support the negotiation between service provider and service customer, service level agreements act as contracts that specify responsibilities, additional IT services (e.g., a help desk) and, in general, their expected quality. For this purpose the IT service model is enriched with, for instance, (key performance) indicators and corresponding thresholds the service provider has to comply with ( 3 ). Enterprise models provide an overview of potential sources from which risks originate and thereby support risk identification. The identified risks and corresponding cause-and-effect relations can be added to the models ( 4). This allows for evaluation and prioritisation of risks related to IT services, e.g., to make decisions on their treatment and to implement appropriate measures. For the implementation of new IT services and functionalities, the IT service model -along with corresponding SLAs and architectural and implementation standards -is used for the conceptual and the technical design of the prospective service. Furthermore, the model can be enriched with implementation details, e.g., about hardware, software, or network resources as well as data models, interfaces, and GUI drafts ( 5 ). Again, models promise to foster the communication, in this case between different groups in the IT department and the "service owner", for example, to get feedback and to ensure the alignment between business requirements and service implementation. For higher productivity, models can also be used to generate (parts of) the service realisation such as interface descriptors, schema for databases, and program code [START_REF] Kelly | Domain-specific modeling: Enabling full code generation[END_REF]. Once deployed and running, the IT services need to be monitored, maintained and evaluated. In this context, Frank et al. [START_REF] Frank | Use of a domain specific modeling language for realizing versatile dashboards[END_REF] employ the idea of using models at run-time. Accordingly, the service model is used for operations in the run phase ( 6), for instance, to enforce quality and availability as guaranteed in the SLA. Whereas models in the plan and build phases remain on type level, the models in the run phases are enriched with data about the service execution (i.e., instance data). Thus the models are used as frontend to instance data ("dashboard"), which promotes a more proactive IT service management. Presuming an integration with corresponding operational information systems, these models could also be enhanced by their running costs, current availability and utilisation as well as other relevant information.

Considerations on Method Design: Reflections on Service Modelling

Development of a method for IT service management requires reconstructing the key concepts of the domain as modelling concepts and providing a process model that guides the application of these concepts. The key domain-specific concepts seem obvious: The method has to provide concepts that represent IT services (Req. 3 ), the business context the IT services are used in (Req. 4 ) as well as concepts that represent the underlying IT infrastructure (Req. 5 ). The conceptualisation in detail, however, depends on design decisions between alternative specifications. In this section we therefore discuss considerations on the language specification and design alternatives (Sec. 5.1), which are based on existing conceptualisations, and outline open issues for a method for IT service management (Sec. 5.2). The specifications are presented as metamodel excerpts in notation of the MEMO Meta Modelling Language [START_REF] Frank | The MEMO Meta Modelling Language (MML) and Language Architecture[END_REF]. The meta models are intended as working drafts and foundation for discussion with and discursive evaluation by peers and domain experts. The reuse of modelling concepts from existing modelling languages in the MEMO language family is visualised by a colored rectangle attached to the meta type header (as suggested in [START_REF] Frank | The MEMO Meta Modelling Language (MML) and Language Architecture[END_REF]).

Outline of a Metamodel: Design Alternatives

IT service concept. Pertinent literature, ITSM approaches and ITSM standards such as [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF][START_REF] Brocke | Managing the current customization of process related it-services[END_REF]21,[START_REF] Rands | Information technology as a service operation[END_REF] apply a generic definition wherein an IT service is used as an abstraction over any (IT-related) outcome of the IT organisation that is used by a customer. This is mainly for one reason: A vague definition of "IT service" enables stakeholders from different hierarchical levels (e.g., management vs. operations), organisations, and domains (e.g., business vs. IT) to communicate without clarifying their (maybe different) conceptualisations in detail. Current modelling languages like [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF][START_REF] Frank | ITML: A Domain-Specific Modeling Language for Supporting Business Driven IT Management[END_REF] seem to acknowledge this practice and offer a generic service concept as illustrated in Fig. 4: A meta type IT service serves to describe a service at least by means of a name, a description and its status in the life cycle (such as "planned", "in implementation", "operated" or "inactive"). However, despite the advantages of such a broad service concept it also comes with various deficiencies: Though stakeholders might be able to communicate for a start, it bears the risk of (maybe unrecognised) misunderstandings, especially if stakeholders apply a different conceptualisation of IT service in detail; and since it does not provide much semantic, it does not allow for a specific support throughout the different life cycle phases as illustrated in Sec. 4. Thus it seems reasonable to provide a more specific conceptualisation that accounts for different connotations of "IT service". We reason that the IT-related service term is used on at least three different levels of abstraction (for a similar conclusion, see [START_REF] Quartel | COSMO: A conceptual framework for service modelling and refinement[END_REF]). On the one hand an IT service is used as an abstraction over processes performed by the IT organisation. Examples for such IT services are "Help Desk" or "PC installation" (e.g., [START_REF] Trienekens | Specification of service level agreements: Problems, principles and practices[END_REF]). On the other hand, it refers to a more technical conception with a focus on features that are provided from information systems, like "Invoice Printing" or "Manage Customers" offered by an ERP system. Finally, the IT service term is used to describe functions (i.e., operations) of software; prominent examples are services in context of SOA as in [START_REF] Erl | Service-oriented architecture: Concepts, technology, and design[END_REF] (e.g., "Retrieve Customer" or "Add Customer").

Against this background, we recommend providing a differentiated conception of IT service in the modelling language as well. One solution would be to offer a meta type for IT service categories that allows organisations to define categories of IT services, such as "IS-based services" or "software-based services" (cf. fig. 5a). Though this solution supports stakeholders in interpreting the semantic of IT service conceptualisations, is does still not provide service-specific semantic and thus no support for tool-based analyses or code generation. 5b illustrates a design alternative that reconstructs the different types of IT services as meta types (a similar conceptualisation has been chosen in ArchiMate [START_REF]ArchiMate 1.0 specification[END_REF]).

In contrast to the service categorisation this alternative offers semantically rich concepts, since it allows to (1) specify IT service type-specific attributes and to (2) associate the meta types to other meta types that further describe them, e.g., associate IS-based services to a meta type that represents information systems etc. This promotes a more precise modelling, enables tool-supported analyses and supports code generation, e.g., for software services.

IT service relations. Analysing and managing IT services recommends to account for the various relations between IT services. For instance, Braun and Winter [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF] suggest an isPartOf relation between services; Brocke et al. [START_REF] Brocke | Managing the current customization of process related it-services[END_REF] differentiate the service meta type into core services and associate services, that customise the core services; while Weigand et al. [START_REF] Weigand | Value-Based Service Modeling and Design: Toward a Unified View of Services[END_REF] classify services into, e.g., core, enhancing, complementary and support services. Since this distinction might be a matter of perspective -while one customer regards a service as complement, others might consider it core -we refrain from such separation in the language specification; instead we regard them as context specific roles. However, it might be promising to introduce an association potentiallyAdditiveTo between IT services. Following the proposal from Ebert et al. [START_REF] Ebert | A service model for the development of management systems for it-enabled services[END_REF], we also suggest to differentiate the isPartOf relation: On the one hand an IT service might be an abstraction over other IT services, without providing own functionality (aggregates). On the other hand an IT service might, in turn of its execution, optionally or mandatory revert to other IT services (uses). In extension to current work, two further relations seem promising: In support of the withdrawal of IT services an IT service can be dedicated to replace other IT services; and an IT service can be similarTo other IT services, which might be feasible especially for larger corporations with several local IT organisations. Figure 6a illustrates the design alternative. With respect to ongoing research in product modelling (see, e.g., [START_REF] Sinnema | Covamof: A framework for modeling variability in software product families[END_REF]), one design alternative seems worthwhile that builds upon the idea of generalisation/specialisation. IT services that are similar to a large extent are generalised to an IT service that describes their common features; additionally, features that vary among the specialised IT services are explicitly modelled as "variation points" (fig. 6b). This alternative contributes to transparency and fosters communication with business stakeholders, as it supports abstracting over all the different variations. Moreover, it specificially promotes a systematic and elaborate portfolio management of IT services. However, although fig. 6 indicates corresponding language specifications (and, for instance, ArchiMate already offers service specialisation), the semantic of service specialisation, service variation points and similar-to relations has not been clarified yet and is subject to further research. As for similar-to relations, we assume that this issue mightat least partly -be addressed by particularising IT services into functionalities.

Functionality. An IT service is used as abstraction over IT processes, information systems and software. At the same time an IT service is used to describe and bundle functionalities that address customers' requirements. Two design alternatives are feasible to represent a service's functionality. First, the concept of functionality is considered being part of the IT service, esp. the description attribute (fig. 7a); this alternative conforms to most current state of the art in EM approaches, e.g., [START_REF] Frank | ITML: A Domain-Specific Modeling Language for Supporting Business Driven IT Management[END_REF][START_REF]ArchiMate 1.0 specification[END_REF]. Second, a dedicated meta type represents the functionalities of an IT service (fig. 7b), as suggested by Brocke et al. [START_REF] Brocke | Managing the current customization of process related it-services[END_REF]. The first alternative requires organisations to formulate their services in a specific, functionality-oriented manner and, thus, restricts to describing one functionality. As a result, an IT service that offers several functionalities has to be modelled by using the above mentioned aggregation mechanism, i.e., the IT service has to comprise several other IT services that each provide one of the required functionalities. The second alternative, in contrast, supports to (1) assign several functionalities to one IT service and (2) allows to separate a general, maybe more business-intuitive description of the IT service and the description of the functionality. Furthermore, a separate modelling of functionalities might be a prerequisite to using service-specialisation and variation points -though this depends on the semantic of these concepts.

Business context. To account for the organisational context IT services are used in, we propose the integration with existing modelling languages, e.g. for business process and goal modelling. Besides "traditional" concepts such as business processes, goals, and organisational structures, we further propose to integrate concepts for risks and indicators as these aspects play a crucial role for today's IT management (fig. 8): Against this background, we suggest integrating the IT service concept with concepts representing risks [START_REF] Strecker | RiskM: A Multi-Perspective Modeling for IT Risk Assessment[END_REF] and indicators [START_REF] Strecker | MetricM: A Modeling Method in support of the Reflective Design and Use of Performance Measurement Systems[END_REF]. Service level agreement. The relations between a service provider, the IT services it provides and the customers of these IT services are often contractually agreed in service level agreements (SLAs). At least two alternatives seem feasible: First, SLAs are considered to govern IT services in that IT services have to be provided with the agreed quality (fig. 9). Similar conceptualisations have been proposed in [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF][START_REF] Debusmann | Unifying service level management using an MDA-based approach[END_REF]. Since a SLA might be specific for the relation between service provider and service customer, a second design alternative is to refine the association between IT service and business process, which acts as a surrogate for the service customer (fig. 9). Whereas Moser and Bayer [START_REF] Moser | IT Architecture Management : A Framework for IT Services[END_REF] propose to associate SLA with an IT service and a business unit, we use the concept for business processes as this more precisely describes the point of use of the service.

In both alternatives a SLA is constituted, amongst others, by a set of indicators, responsible organisational roles, and goals. Usually these aspects will a be subset of indicators, roles, and goals of the IT service the SLA refers to, which recommends corresponding constraints to assure consistency in the model. Additionally a SLA can contain billing details for the IT service (e.g., costs). Although the second solution promotes a more precise definition of the relation between IT service and business process and thereby of a SLA, this alternative might be counterintuitive for users that are accustomed to assign IT services directly to a business process.

Open Issues & Research Agenda

The presented reflections on IT service modelling already indicate challenging questions that need to be investigated. Although we presented alternative design decisions and, as far as reasonable, decision criteria and rationales, we highlighted just a selection of open questions. Development of an enterprise modelling method for IT service management requires considering further design issues.

Among others, open research questions are:

-Some authors introduced a differentiation of IT services and IT products (e.g., [START_REF] Ebert | A service model for the development of management systems for it-enabled services[END_REF]). While this separation seems reasonable -a product bundles services to be sold, thus applying a marketing perspective -it entails a problem if the specialisation/variation point concepts (cf. fig. 7b) are applied: Assuming that these concepts make sense for product modelling, too, the relation between product, specialised products, IT services and specialised IT services has to be investigated. -In fig. 5 we assumed a meta type representing IT processes. However, yet there seems no consensus -nor analysis -whether there is need for a specific meta type or if existing modelling concepts and languages for business processes can be reused to also model IT processes. -With regard to the requirements analysis it needs to be investigated [START_REF] Braun | Integration of IT service management into enterprise architecture[END_REF] to what extent requirements can be derived from process models and (2) how additional details such as capacity requirements and anticipated changes can be added to process models and used in later life cycle phases. -Similar and reusable services (and functionalities) can only be identified if they are described consistently and at the same level of abstraction -at best using (semi-)formal concepts that support tool-based comparison. In context of enterprise modelling such concepts and corresponding heuristics are, to our knowledge, subject to future research. -Finally, modelling SLAs, as indicated in fig. 9, recommends accounting for juridical aspects, too. However, we are not aware of work that addresses the formalisation juridical aspects, yet. Beside issues pertaining the language specification, the application of the presented modelling concepts needs to be embedded in a process model that envisions the use of the concepts; in addition, heuristics and guidelines are recommended. These aspects were not in focus of this paper.

Conclusions

This paper investigates the potentials of an enterprise modelling based method in support of IT service management. In this regard, our contribution in this paper is twofold: First, we illustrate consistent support for ITSM over the entire life cycle of IT services. Second, we prepare for further research on such a method by reflecting key considerations and decisions pertaining to IT service modelling. Therefore, we focus on language specification and discuss design alternatives as enhancements to existing approaches as research in progress. However, developing a method requires further considerations, for instance, guidelines, an accompanying process model, and support of a modelling tool. Since corporate culture and the distribution of power in an organisation have an impact on IT management [START_REF] Rands | Information technology as a service operation[END_REF][START_REF] Trienekens | Specification of service level agreements: Problems, principles and practices[END_REF] it should also be investigated, whether these aspects, which apparently resist against formalisation, could be somehow accounted for in the method, too.

Fig. 1 .

 1 Fig. 1. Idealised life cycle with exemplary activities

Fig. 3 .

 3 Fig. 3. Example for a model based ITSM

Fig. 4 .Fig. 5 .

 45 Fig. 4. Basic Conceptualisation of IT service

Fig. 6 .

 6 Fig. 6. Design alternatives for service relations (cardinalities & constraints ommitted)

Fig. 7 .

 7 Fig. 7. Design alternatives for service functionalities

Fig. 8 .

 8 Fig. 8. Business context for IT services

Fig. 9 .

 9 Fig. 9. Design alternatives for service level agreements


Alexandre M L De Vasconcelos

Giovanni Giachetti
email: ggiachetti@pros.upv.es

Beatriz Marín
email: bmarin@pros.upv.es

Oscar Pastor
email: opastor@pros.upv.es

Towards a CMMI-compliant Goal-Oriented Software Process through Model-Driven Development

Keywords: Goal-Oriented Requirements Engineering, i* framework, Model-Driven Development, Software Process Quality, CMMI

The i* framework is a Goal-Oriented Requirement Engineering (GORE) approach that is widely applied at academic level. However, its application to industrial scenarios is limited. For the application of i* in concrete software development process, an alternative is to transform the defined requirements models into initial input models to be used by Model-Driven Development (MDD) approaches. However, this does not assure that the resultant development process will be sound enough to motivate real development companies to adopt this GORE solution. To tackle this issue, we propose the alignment of GORE and MDD solutions with software process maturity models, which are strongly adopted and applied by industry. In particular, we have considered an approach that integrates the i* framework into an industrially-applied MDD solution to obtain a development process (that goes from requirements to the final software code), which is compliant with the CMMI-DEV maturity model.

Introduction

Requirement modeling plays a relevant role in software development, since the quality of the requirements has a direct impact on the success of software development projects [START_REF] Kamata | How Does Requirements Quality Relate to Project Success or Failure?[END_REF]. Among several approaches for defining requirements, the Goal-Oriented Requirement Engineering (GORE) [START_REF] Shuichiro | Goal Oriented Requirements Engineering: Trends and Issues[END_REF][31] [START_REF] Van Lamsweerde | Goal-Oriented Requirements Engineering: a Roundtrip from Research to Practice[END_REF] is one that has a wide application spectrum. In general terms, GORE focuses on obtaining the "why" of the intended systems through the analysis of organizational scenarios. It is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements.

However, as stated in [START_REF] De La Vara | System Modeling from Extended Task Descriptions[END_REF], a Requirements Engineering (RE) approach is not useful per se, it must be appropriate for the software process into which it is integrated. Thus, a GORE approach must be properly integrated into a full software process (from requirements to the final code). An alternative to achieve this integration is to automatically transform the requirements models into an initial model [START_REF] Alencar | From i* Requirements Models to Conceptual Models of a Model-Driven Development Process[END_REF] [START_REF] Giachetti | Beyond Requirements: An Approach to Integrate i* and Model-Driven Development[END_REF] to be used as input in the context of a Model-Driven Development (MDD) approach [26] [START_REF] Völter | Model-Driven Software Development: Technology[END_REF]. Then, this initial model can be refined to automatically generate code through a model compilation (transformation) process. An additional advantage of integrating GORE with MDD is that, through the automatic generation of code from models, MDD allows lower development costs, higher productivity, portability, interoperability, ease of software evolution, and software quality improvement [START_REF] Mohagheghi | Where is the Proof? -A Review of Experiences from Applying MDE in Industry[END_REF].

Among the existing GORE approaches, the i* framework [START_REF] Yu | Modelling Strategic Relationships for Process Reengineering[END_REF] is one of the most widespread and used at research level [START_REF] Yu | Social Modeling for Requirements Engineering[END_REF]. However, there is a gap between the vast application of i* in academy in relation to its application to real (industrial) development scenarios [START_REF] Xavier | Fostering the Adoption of i* by Practitioners: Some Challenges and Research Directions[END_REF]. An alternative to obtain a suitable support for the application of the i* framework into real scenarios is to align i*-based development processes with a software process maturity model [START_REF] Pino | Software process improvement in small and medium software enterprises: a systematic review[END_REF] [START_REF] Unterkalmsteiner | Evaluation and Measurement of Software Process Improvement -A Systematic Literature Review[END_REF], such as the CMMI-DEV (Capability Maturity Model Integration for Development) [26]. In this way, this kind of GORE solutions become more attractive for the companies that are using those maturity models as the basis to improve their development processes in order to become more competitive in terms of quality and maturity of their processes.

As GORE, MDD, and process maturity models are focused on achieving/increasing the quality of the software product, we believe they are rather complementary. In this context, the following research question is proposed: How can be designed a GORE-based MDD process to fulfill the requirements of a software process maturity model? Since this challenge has not been properly addressed by any software process yet, research into this area is relevant and necessary.

Towards answering the research question, in this paper we propose a Goal-Oriented software process (hereafter called GO-MDD) based on the i* framework and on OO-Method (an industrially applied MDD approach) [START_REF] Pastor | Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling[END_REF], which is compliant with the requirements development (RD) process area (PA1 ) of CMMI 2 . We have focused on the compliance with RD because, similarly to i*, the main objectives of this process area are the elicitation and/or specification of system requirements.

The contribution of this paper is twofold. First, practitioners that follow or plan to follow a maturity model and at the same time want to combine GORE and MDD can adapt this proposal instantiating it to their specific needs. Second, the paper can be useful in academia as reference for further research on combining different instances of GORE, MDD, and software process maturity models.

The rest of this paper is organized as follows: Section 2 presents relevant background. Section 3 describes the GO-MDD process. Section 4 presents the analysis of GO-MDD in regard to the RD process area. Section 5 discusses relevant related works. Finally, Section 6 shows the conclusions and proposes future work.

Background

The reasons for choosing i*, OO-Method, and CMMI as the basis for the GO-MDD proposal are the following: i* is currently one of the most widespread GORE modeling and reasoning frameworks [START_REF] Shuichiro | Goal Oriented Requirements Engineering: Trends and Issues[END_REF] [START_REF] Van Lamsweerde | Goal-Oriented Requirements Engineering: a Roundtrip from Research to Practice[END_REF]; OO-Method is a MDD approach that has been successfully applied in the software industry [START_REF] Pastor | Automated Production of Fully Functional Applications with OlivaNova Model Execution[END_REF] and; finally, CMMI is the most frequently adopted software process maturity model [22][30]. This section provides a brief explanation of these software development approaches.

The i* Goal-Oriented Requirements Framework

The i* framework [START_REF] Yu | Modelling Strategic Relationships for Process Reengineering[END_REF] emphasizes the analysis of strategic relationships among organizational actors to capture intentional requirements. An actor generically refers to any unit for which intentional dependencies can be ascribed. Actors are intentional in the sense that they do not simply carry out activities and produce entities, but also have desires and needs. The framework offers two types of models: the Strategic Dependency (SD) model and the Strategic Rationale (SR) model.

The SD model focuses on external relationships among actors. It includes a set of nodes and connecting links, where nodes represent actors (depender and dependee) and each link indicates a dependency (dependum) between two actors. There are four possible dependum elements: goal, resource, task, and softgoal. A goal is a condition or state of concerns that an actor would like to obtain. A resource is a physical or informational entity that must be available for an actor. A task specifies a particular way of doing something and can be decomposed into small sub-tasks. Finally, a softgoal is associated to non-functional requirements.

The SR model is a detailed view of the SD model that shows the internal actor relationships. In addition to the dependencies that are present in the SD model, the SR model incorporates three new types of relationships: (i) task-decomposition links, which describe what should be done to perform a certain task; (ii) means-end links, which suggest that a task is a means to achieve a goal; (iii) contribution links, which suggest how a model element can contribute to satisfy a softgoal.

The OO-Method MDD Approach

OO-Method [START_REF] Pastor | Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling[END_REF] is an object-oriented method that allows the automatic generation of the final application code from a conceptual model. It is supported by the industrial tool OlivaNova [START_REF] Pastor | Automated Production of Fully Functional Applications with OlivaNova Model Execution[END_REF] and provides a precise UML-like notation, which is used to specify a Conceptual Schema that describes a system at the problem space level. The development process suggested by OO-Method has two phases (Fig. 1): Development of a Conceptual Schema and Generation of a Software Product.

The first phase consists of eliciting and representing the essential properties of the information system under study, thereby creating the corresponding conceptual schema. In the second phase, a precise execution model, conformed by a set of compilation patterns, indicates the correspondences between the conceptual schema and pieces of code in a target implementation platform. Thus, the application code is automatically generated for an input conceptual schema.

CMMI-DEV

CMMI-DEV [26] is a guide to implement a continuous process improvement for developing products and services. For accomplishing this task, it provides two representations: Staged, which assesses the maturity level of a whole development process from an organization; and Continuous, which assesses the capability level of individual process areas (PAs), selected based on the organization's business goals. The process framework described in this paper (see Section 3) is related to the continuous representation, since it is focused on only one process area (PA): requirements development (RD). It complies with the capability level 1 of RD, which is considered, according to CMMI, the basis for improvement initiatives in a specific PA. A meta-model for the continuous representation is presented in Fig. 2. In the continuous representation, the achievement of a capability level depends on goals and practices (decomposition of goals) of two types: 1) specific goals (SGs) and specific practices (SPs), which are applied only to a particular PA; and 2) generic goals (GGs) and generic practices (GPs), which are applied equally to all PAs that achieve a specific capability level. From the assessment of practices and goals, which is performed on a bottom-up way (from the practices up to the goals), it is possible to classify the capability level of a PA on a scale from 0 to 3 (for details see [26]).

The Proposed Process Framework: GO-MDD

The process framework, GO-MDD, extends the works published in [START_REF] Alencar | From i* Requirements Models to Conceptual Models of a Model-Driven Development Process[END_REF]

[2][8][9][21].
It is composed of six stages that are performed through an iterative and incremental development cycle (Fig. 3). Thus, after performing all the stages, the cycle can re-start for a new iteration if the product being developed is not finished yet.

Fig. 3. Stages and artifacts of GO-MDD.

We call GO-MDD a process framework and not simply a process because it has a character most descriptive rather than prescriptive, meaning that it focuses on the "what" rather than on the "how" (a detailed discussion on the differences between descriptive and prescriptive processes is presented in [START_REF] Ruhe | Learning Software Organizations[END_REF]). Hence, GO-MDD can be instantiated for each organization prior to its use (e.g., the way of doing the requirements elicitation or their validation).

In particular we apply the CMMI perspective to create a process framework that automatically integrates the i* framework into a concrete MDD processes (OO-Method). This process framework presents specific transformation guidelines, i* extensions, and verification mechanisms to assure the correct generation of initial MDD models from i* models. Then, by means of refinement of this MDD model, a fully executable application that is aligned with the stakeholder requirements is generated. Since the proposed integration of i* and MDD is based on the class model generation, the results presented in this paper can be used as reference for other object-oriented MDD processes, such as UML-based proposals.

An example, related to the management of work requests in a Photography agency, extracted from the experiment presented in [START_REF] Giachetti | Automatic Verification of Requirement Models for Their Interoperability in Model-Driven Development Processes[END_REF], is used to explain the process framework GO-MDD. The Photography agency is dedicated to the management of photo reports and their distribution to publishing houses. This agency operates with freelance photographers, which must present a work request to its production department. Due to space constraints, only those aspects that are not part of i* and are more relevant to the paper's objectives are illustrated.

First stage: Develop Custom Requirements. Requirements from various stakeholders are consolidated, prioritized (according to stakeholder needs and constraints) and detailed to be implemented in the current iteration. These requirements can be elicited in the current iteration or come from a backlog (i.e., a list) of previously approved requirements (see the description of the Second Stage). The requirements backlog and the iterative development cycle were inspired from Scrum [START_REF] Schwaber | SEI: CMMI for Development, Version 1.3[END_REF]. As the result of this stage, an SD model is produced and the traceability (i.e., a mapping) from requirements to the SD model is created/updated. Second stage: Requirements Management. This stage is responsible for monitoring the requirement requests from several stakeholders and performing initial requirements elicitation and analysis (of adequacy and impact) in order to decide whether the requests will be approved (or not) to be developed in some iteration. It is executed in parallel with the first stage, until the product is satisfactorily produced. As the result of this stage, a backlog of approved requirements is created/updated. Third stage: Develop Product Requirements. In this stage, detailed in [START_REF] Alencar | Aligning Goal-Oriented Requirements Engineering and Model-Driven Development[END_REF] [START_REF] Pastor | Linking Goal-Oriented Requirements and Model-Driven Development[END_REF], an initial SR model is produced from the refinement of the SD model. The goals defined in the SR model are analyzed to decide the intentional elements that must be considered as requirements of the system to be. These elements are highlighted by means of specific stereotypes, which introduce information to automatically perform the corresponding MDD model generation. Thus, an enriched SR model is produced.

Fig. 4 shows an example of an i* SR model, related to the Photography agency, extended with the stereotypes defined for the integration with OO-Method. This SR model shows that the production department depends on the reception of work requests (i.e., job applications), which are produced by photographers that want a work opportunity. The work requests are comprised by the photographer's personal data. The production department is responsible for refusing or accepting the received work requests by indicating the final work request status. For the accepted requests, a photographer level is assigned according to the information provided by the Commercial Department. The stereotypes that extend the i* SR model introducing specific information to generate the corresponding MDD (class) model according to the OO-Method approach, and their main application to the transformation process are briefly described as follows (further information can be found in [START_REF] Alencar | Aligning Goal-Oriented Requirements Engineering and Model-Driven Development[END_REF]):

• SActor: Indicates that an i* actor must be maintained by the corresponding system. This actor will be represented by means of a class in the generated MDD model. • SPhysicalR: Indicates that an i* resource is considered as a physical resource that must be maintained in the system as a class in the generated MDD model. • SInfoR: Indicates that an i* resource is considered as an informational resource that must be maintained in the system as class attribute in the generated MDD model. • STask: Indicates that an i* task must be considered for the system behavior. This will be represented as a class service in the generated MDD model. Fourth stage: Verification, Analysis, and Validation: The models defined in the previous stages are used as input for this stage. An analysis is performed to guarantee that the requirements defined in the SR model are necessary and sufficient to meet the organizational goals and to balance stakeholder's needs and constraints. Then, the requirements are validated with the stakeholders to guarantee their correctness and completeness and, if any problem is detected in the analysis or in validation, it must be fixed. Later, the resultant SR model is verified by means of a set of measures (detailed in [START_REF] Giachetti | Automatic Verification of Requirement Models for Their Interoperability in Model-Driven Development Processes[END_REF]), which evaluate the elements extended. These verification measures are formally specified by means of OCL rules [START_REF]OMG: Object Constraint Language 2.2 Specification[END_REF] and guarantee the completeness of the MDD model generation in relation to the requirements indicated in the i* model. This has been demonstrated by means of the controlled experiment presented in [START_REF] Giachetti | Automatic Verification of Requirement Models for Their Interoperability in Model-Driven Development Processes[END_REF]. The measures not only identify the modeling issues, but also provide fixing guidelines to improve the SR model and the MDD model generation. Hence, if some problem is detected during the model verification, it must be fixed before getting to the next stage. For instance, the measure Wrong Attribute Generation (Table 1) specifies that an i* resource stereotyped as an informational resource (SInfoR) must be related to a system actor (SActor) or to a physical resource (SPhysicalR), which are transformed into a class. Otherwise, the informational resource cannot be transformed into a class attribute due to the lack of a class that contains it.

Measurement procedure

The attributes to be measured must be counted to obtain the number of informational resources that cannot be transformed into attributes. [START_REF] Alencar | Aligning Goal-Oriented Requirements Engineering and Model-Driven Development[END_REF] and [START_REF] Pastor | Linking Goal-Oriented Requirements and Model-Driven Development[END_REF]). We refer to an initial MDD model and not a complete one because there are aspects related to specific system functionality that cannot be obtained from requirements models.

Traceability from requirements to the MDD model is also produced in this stage. It is important to point out that the class model is the central model in the OO-Method approach. The rest of the models that are necessary to completely specify the OO-Method conceptual model (such as the presentation or the functional model) are derived from this central model. Thus, the traceability from requirements to the other OO-Method models can be obtained from the association of requirement elements to the corresponding class model elements. Fig. 5 shows the class model obtained from the extended i* model presented as example in Fig. 4. A specific OO-Method construct that differs from the traditional (UML-like) class model notation can be observed in the generated class model. This is the agent relationship, which indicates the visibility that a class has over attributes or services of other classes of the model. Agent relationships are defined between a class generated from an i* actor and the elements generated from i* elements that are inside the boundary of the actor transformed (e.g., the agent relationship that is defined from the class ProductionDept to the service toReceiveWorkRequest). These relationships provide relevant information for defining presentation models related to the specification of users' interactions with the final system.

Sixth stage: MDD Model Refinement and Code Generation. The initial MDD model generated is refined to introduce those design aspects that cannot be obtained from the transformation of the enriched i* SR model. Some of the refinements that must be performed are the specification of additional class services, association of cardinalities, or specific system constraints. The refined model is verified by means of a facility provided by the OO-Method modeling tool [START_REF] Pastor | Automated Production of Fully Functional Applications with OlivaNova Model Execution[END_REF], which guarantees the correct specification of the MDD model for the automatic code generation. The system source code is generated by applying the OO-Method model compilation technology. Finally, the generated source code must be compiled and executed in order to be validated against the corresponding requirements.

Research Method for the Design of GO-MDD

The design of GO-MDD was done according the following research method. First, based on previous works of our research group, regarding the integration of i* and OO-Method [START_REF] Alencar | From i* Requirements Models to Conceptual Models of a Model-Driven Development Process[END_REF][2][8][9] [START_REF] Pastor | Linking Goal-Oriented Requirements and Model-Driven Development[END_REF] (that propose the use of stereotypes, transformation guidelines and verification measures), an initial version of the process framework was specified. The compliance of this version was analyzed against the RD process area and, based on the gaps identified in the analysis, new characteristics, activities and artifacts were included into GO-MDD to make it fully compliant with this process area. Finally the compliance mapping, described in the next section, was produced. No exclusions were done from the original process, and the inclusions were mainly related to the consolidation, prioritization and traceability of requirements (First Stage); the whole Requirements Management (Second Stage); the analysis and validation of requirements (Fourth Stage); and the definition of an interactive/incremental cycle (performed along the whole process framework).

Compliance Mapping from the RD Process Area and GO-MDD

According to CMMI-DEV, the purpose of RD is to elicit, analyze and establish customer, product, and product component requirements. A compliance mapping between the capability level 1 of RD and the proposed process framework (GO-MDD) is presented in this section. For each SG, its purpose is described, and for all the corresponding SPs, a mapping relating stages, activities, and artifacts of GO-MDD to each SP is produced. To comply with the capability level 1, a process must satisfy the generic goal (GG) associated to this level (GG 1), which has only one generic practice (GP 1.1) that requests all the SGs associated to the PA to be satisfied (if at least one of the SGs is not satisfied, the PA is considered to have capability level 0). For evaluating capability levels higher than 1, a PA must satisfy the GG associated to the specific level, which imposes other requirements, and all the GGs associated to the lower levels. Fig. 6 instantiates the meta-model presented in Fig. 2 to represent the elements involved in the compliance mapping for level 1.

Fig. 6. The capability level 1 for the RD process area

Legend:

RD -Requir. Develop. GG -Generic Goal GP -Generic Practice SG -Specific Goal SP -Specific Practice SG 1 Develop Customer Requirements: This goal addresses the collection of stakeholder needs, expectations, constraints and interfaces, and their translation into customer requirements. SP 1.1 Elicit Needs: requirements should be elicited and a requirements specification (e.g., a textual document or a model) should be produced. The requirements specified (functional and non-functional) express stakeholder needs, expectations, constraints, and interfaces for all the phases of the product lifecycle. Compliance mapping: A preliminary requirements elicitation is performed in the Requirements Management stage and a list of approved requirements is produced. Then, in the Develop Custom Requirements stage, the requirements to be implemented in the current iteration are detailed, and an initial i* model (SD) is produced with the definition of different organizational actors (stakeholders) and their dependencies.

SP 1.2 Transform Stakeholder Needs into Customer

Requirements: requirements elicited from various stakeholders (including business and technical functions) should be consolidated, analyzed regarding missing information and presence of conflicts, and prioritized according to some criteria. Requirements specific to verification and validation (V&V) for the system to be can also be elicited.

Compliance mapping:

The SD model produced in the Develop Custom Requirements stage is a consolidated and prioritized specification of the needs from various stakeholders.

SG 2 Develop Product Requirements:

This goal addresses the refinement and elaboration of customer requirements in order to develop product and product component requirements. Some of the practices associated to this goal can be performed during or in conjunction with a design stage.

SP 2.1 Establish Product and Product Component

Requirements: product and product component requirements should be derived (identified) from customer requirements. Product requirements are functional and non-functional requirements expressed in technical terms that can be used for design decisions. Modifications on customer requirements due to approved requirements changes must be reflected in the derived requirements. Derived requirements also address the needs of other lifecycle phases (e.g., production, operations and disposal). Compliance mapping: The enriched SR model produced in the Develop Product Requirements stage is a refinement of the SD model and specifies which requirements (functional and non-functional) are allocated to the products and product components to be developed. Modifications on customer requirements are captured in the Requirements Management stage, and their impacts on the derived requirements are analyzed based on the traceability from requirements to the SD model (produced in the Develop Custom Requirements stage), on the refinement relationship between the SD and the SR models, and on the traceability from requirements to class model (produced in the Generate Initial MDD Model stage).

SP 2.2 Allocate Product Component

Requirements: the product components requirements (functional and non-functional) should be allocated to product components of the defined solution.

Compliance mapping: In the Generate Initial MDD Model stage, the initial class diagram generated is a first approximation for the allocation of requirements to product components. Later, this allocation can be updated when the class diagram is refined in the MDD Model Refinement and Code Generation stage.

SP 2.3 Identify Interface

Requirements: interface requirements between functions, objects or other logical entities should be identified.

Compliance mapping:

The initial class diagram, produced in the Generate Initial MDD Model stage, includes classes, methods, attributes, and associations. It defines the interfaces among entities that are identified from the requirements. Later, these interfaces can be updated when the class diagram is refined for code generation.

SG 3 Analyze and Validate Requirements:

This goal addresses requirements analysis and validation. Its specific practices support the development of the requirements in SG 1 and SG 2. Some of the practices associated to this goal can be performed during or in conjunction with a design stage. SP 3.1 Establish Operational Concepts and Scenarios: operational concepts and scenarios should be identified and maintained (i.e., updated when necessary). Operational concepts are general descriptions of the ways in which entities are used or operate. Scenarios are detailed sequences of events that make explicit some of the functional or quality attribute (non-functional) needs of the stakeholders. Compliance mapping: The SD and SR models illustrate the tasks and subtasks (i.e., the way of doing something) related to the satisfaction of goals that the actors would like to achieve. In particular, the enriched SR highlights the tasks and subtasks related to processes that will be automated.

SP 3.2 Establish a Definition of Required Functionality and Quality

Attributes: a definition of the required functionality and quality attributes should be established and maintained.

Compliance mapping: The enriched SR in conjunction with the initial class diagram specify the quality attributes (softgoals) and required functionalities (tasks and class services) that are related to the requirements elicited. Later, when the class diagram is refined, these quality attributes and functionality can be updated.

SP 3.3 Analyze Requirements:

the requirements for one level of the product hierarchy should be analyzed to determine if they are necessary and sufficient to meet the objectives of higher levels (i.e., the practice analyses the consistence between requirements in different levels of hierarchy). Compliance mapping: satisfaction of this SP is discussed together with the next one.

SP 3.4 Analyze Requirements to Achieve

Balance: requirements should be analyzed to balance stakeholder's needs and constraints, such as cost, schedule, product or project performance, functionality, priorities, reusable components, maintainability, and risks. Compliance mapping: The SP 3.3 and SP 3.4 are satisfied in the following way. Preliminary requirements analysis is performed during the Requirements Management stage and also in the Develop Custom Requirements stage, when requirements are consolidated and prioritized according to stakeholder needs and constraints. In the Verification, Analysis, and Validation stage, the consistence among requirements from different levels of hierarchy is analyzed. Additionally, the defined measures automatically verify the i* models in the context of the MDD process to assure the transformation completeness of the necessary requirement elements. Thus, the MDD model generated provides a complete representation (at design time) of all the artifacts defined at requirements level.

SP 3.5 Validate

Requirements: requirements should be validated to ensure that the resulting product will perform as intended in the end-user environment. Compliance mapping: Prior to the generation of the initial class model, in the Verification, Analysis, and Validation stage, the requirements are validated with the stakeholders in order to guarantee their correctness and completeness. Also, the iterative and incremental refinement cycle that is present in our proposal allows automatically generated class models to be used to generate prototypes, which are validated by the stakeholders to assure the correct implementation of their needs. Hence, at each iteration, an initial MDD (class) model can be automatically generated from the requirements and later refined to obtain a complete and precise description of the generated MDD elements in order to perform the model compilation into an increment towards the final software product. Thus, necessary changes in the requirements are introduced in the defined i* models to generate a new version of the corresponding class models, and to perform a new model compilation and validation.

Related Work

In the literature, we have not found any work that proposes a software process based on the automatic integration of GORE with MDD and compliant with a maturity model. However, there are works which treat the pair-wise association of these software development approaches. Some of these works are described as follows.

The integration between GORE and MDD has been discussed in several works. However, most of these works (such as [START_REF] Liu | Designing Information Systems in Social Context: A Goal and Scenario Modeling Approach[END_REF][14] [START_REF] Santander | Deriving Use Cases from Organizational Modeling[END_REF]) are not based on standards or well-defined processes, nor do they introduce automation possibilities. Therefore, the application of these proposals must be manually performed [START_REF] Martínez | Conceptual Schemas Generation from Organizational Models in an Automatic Software Production Process[END_REF], which is not a suitable option since the manual translation of models is a time consuming and error prone task [START_REF] Maiden | Model-Driven Requirements Engineering: Synchronising Models in an Air Traffic Management Case Study[END_REF].

In relation to the integration of GORE with a software process maturity model, in [START_REF] Cerón | A Meta-Model for Requirements Engineering in System Family Context for Software Process Improvement using CMMI[END_REF] it is proposed an approach for requirements development and management in the context of system family engineering, which, according to the authors, complies with the RD and RM3 process areas of CMMI. In this approach, high abstraction level goals (related to functional aspects) and softgoals (related to quality aspects) are the first means used to elicit requirements. However, as opposed to our work, an explicit mapping identifying which are all the evidences to attest its compliance with CMMI is not presented; neither the approach is integrated into a complete software process from requirements to code.

Although there are some specific works related to the compliance of MDD approaches with CMMI or its ancestor (CMM) [START_REF]Crag Systems: The Model-Driven Development Process[END_REF][6][7] [START_REF] Steinhau | Guidelines for the Application of MDA and the Technologies covered by it[END_REF], they fail to deal with this issue properly. These works do not explain in detail how an approach complies with the maturity model, where the approach should be adjusted for compliance, and whether/where the approach conflicts with the maturity model requirements.

Hence, unlike those previous works, we proposed a complete software process framework, which integrates GORE and MDD through automatic transformation from requirements to initial design models and compliant with a software process maturity model. To demonstrate the adherence of the GO-MDD process framework with the maturity model, a detailed compliance mapping was presented.

Conclusions and Future Work

In this work, based on the research question How can be designed a GORE-based MDD process to fulfill the requirements of a software process maturity model?, we advocated that GORE and MDD can be put together to comply with the requirements of a software process maturity model, thus supporting the application of a GORE approach into real (industry) scenarios. In order to demonstrate the soundness of this idea, we have proposed a software process framework based on i* and OO-Method, and have described how it complies with the RD process area of CMMI-DEV. Even though the work has been based on specific instances of GORE, MDD, and a software process maturity model, we believe that this idea can be generalized to other instances, but further research need to be done in this direction.

This proposal is part of a wider work that is related to the use of GORE and MDD to define a full software process, compliant with a software process maturity model, covering the long path that goes from goal-oriented requirements modeling to a final high-quality software product. In this context, several future works can be developed: 1) Extending the proposed process framework to be compliant with other process areas and capability levels of CMMI is necessary. Despite the framework proposed already presents some characteristics that partially meet other PAs, such as "requirements management" and "project monitoring and control", additional characteristics must be considered to be compliant with these and further PAs; 2) We are aware that the evaluation of the proposal in real development scenarios is necessary. Hence, we consider as future work the development of empirical studies to validate the feasibility and the effectiveness of the proposed process framework, and to analyze the practical implications of its use in an industrial context; 3) The investigation of the research question in the scope of other software development approaches (i.e., different GORE, MDD and/or maturity models approaches) needs to be done; 4) Finally, a systematic literature review [START_REF] Kitchenham | Guidelines for Performing Systematic Literature Reviews in Software Engineering Version 2[END_REF] should be conducted to verify in deep the existence of other related works.

Fig. 1 .

 1 Fig. 1. Phases and artifacts of the OO-Method MDD approach.

Fig. 2 .

 2 Fig. 2. CMMI Continuous Meta-model, adapted from [17][26].

Fig. 4 .

 4 Fig. 4. Example of extended i* SR model.

Fifth stage:

  Generate Initial MDD Model: Once the i* SR model has been verified and improved according to the corresponding verification measures, it is transformed into an initial MDD model (class model) by means of a set of model-to-model transformations (detailed in

Fig. 5 .

 5 Fig. 5. Initial class model generated from the extended i* SR model.

Table 1 :

 1 Some characteristics of the measure Wrong Attribute Generation

	Characteristic	Definition
	Measurement Scale	Ratio scale
	Attribute to be measured	Informational resources not related to a physical resource or to an actor.
	Measurement principle	This kind of informational resource corresponds to a wrong attribute
		generation in the MDD model.

A cluster of related practices that, when implemented collectively, satisfies a set of goals for making improvements in an area.

In this paper, the terms CMMI and CMMI-DEV are used as synonyms.

The Requirements Management process area is responsible for tracking requirements changes, analyzing the impacts of the changes and maintaining the requirements traceability.

Acknowledgments. This work has been developed with the support of the Brazilian Research Agency CAPES, under the grant #BEX3229/10-6; and the Spanish Government, under the projects ORCA (PROMETEO/2009/15), PROS-REQ (TIN2010-19130-C02-02) and PTA2008-1443-P (co-financed by ERDF).