<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Return on Experience of the Implementation of a Business-IT Alignment Approach: Theory and Practice</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Islem Gmati</string-name>
          <email>Islem.Gmati@malix.univ-paris1.fr</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Irina Rychkova</string-name>
          <email>Irina.Rychkova@univ-paris1.fr</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Judith Barrios</string-name>
          <email>ijudith@ula.ve</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Selmin Nurcan</string-name>
          <email>Selmin.Nurcan@univ-paris1.fr</email>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Universidad de Los Andes, Facultad de Ingeniería, Escuela de Ingeniería de Sistemas, Departamento de Computación</institution>
          ,
          <addr-line>Mérida, 5101</addr-line>
          ,
          <country country="VE">Venezuela</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University Paris 1 - Panthéon - Sorbonne Centre de Recherche en Informatique 90</institution>
          ,
          <addr-line>rue de Tolbiac 75634 Paris Cedex 13</addr-line>
          <country>France Fax :</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>University Paris 1 - Panthéon - Sorbonne IAE de Paris (Business Administration Institute) 21</institution>
          ,
          <addr-line>rue Broca 75005 Paris Fax:</addr-line>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2010</year>
      </pub-date>
      <fpage>76</fpage>
      <lpage>90</lpage>
      <abstract>
        <p>Approaches for business-IT alignment assessment developed in the research community represent an increasing interest for practitioners as they offer an in-depth analysis of the business and IT systems in the organisations. In order to be used by practitioners as a regular tool, these approaches have to be validated. Our experience shows that the perception of validity in academia - "in vitro" - and in the industrial environment "in vivo" - may differ substantially. In this paper, we discuss the theoretical and empirical (or practical) validity of alignment assessment approaches based on metrics. We propose an empirical validation of a fitness measurement approach for business-IT alignment. First we identify a set of practical validity criteria for this approach and then we generalise our example proposing a set of practical guidelines for operationalisation of approaches based on alignment measurements. Our study reveals a significant gap between our understanding of validity and the perception of our industrial partners about this validity. The contribution of this work is a set of empirical criteria of validity and a set of practical guidelines that can significantly improve the usability - by organisations - of research approaches for business-IT alignment assessment.</p>
      </abstract>
      <kwd-group>
        <kwd>business-IT alignment</kwd>
        <kwd>criteria of validity</kwd>
        <kwd>measurements</kwd>
        <kwd>validation</kwd>
        <kwd>empirical validation</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>theoretical</p>
    </sec>
    <sec id="sec-2">
      <title>1. Introduction</title>
      <p>
        Assessment of business-IT alignment is a subject of continuous interest in research
and industrial communities. For practitioners, validation of business-IT alignment is
an important part of the organisation government; for researchers, approachs
toccurate alignment measurement pave the way to new theories in the field [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. Many
approaches to business-IT alignment assessment are addressed in the literature. These
approaches can be divided into three groups: questionnaire-based approaches [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ],
[
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], framework-based approaches [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] and approaches based on alignment
measurements [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. For many organisations the metrics-based alignment
assessment is beneficial: it provides quantitative results that allow managers to
measure the business value of the existing IT, and to increase this value. Our work is
concentrated on the last type of business-IT alignment assessment approaches– the
metrics -based ones. Validation of business-IT alignment approaches based on metrics
is addressed in the research literature [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. We agree with the author in [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]
that in order to be valid these approaches should be grounded on a solid theory: “it is
questionable whether it is worth showing that a measure is measuring a particular
attribute if that attribute is not part of a theory”.
      </p>
      <p>
        Briand [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] argues that most of the proposed metrics and the way to measure them
have not undergone an empirical validation. Schneidewind [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] advocates an
empirical validation process in which a metric is associated with a measure of
interest. This process is specified for the software metrics but remains valid for
metrics in any other discipline - particularly in Enterprise Architecture. Our
experience shows that practical validation criteria of a metrics-based approach can
be quite different from the theoretical ones. We follow the author of [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ] who argues
that “a measure can be correct from a measurement theory perspective but be of no
practical relevance to the problem at hand. On the other hand, a measure can be not
entirely satisfactory from a theoretical perspective but can be a good enough
approximation and work fine in practice”.
      </p>
      <p>
        In this paper, we discuss the theoretical and empirical (or practical) validity of
metrics-based approaches to alignment assessment. We propose an empirical
validation of the fitness1 measurement approach for business-IT alignment developed
in [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. First, we identify a set of practical validity criteria for this approach and
illustrate these criteria on the example. Then we generalise our criteria and
propose the guidelines for operationalisation of approaches based on alignment
measurements.
      </p>
      <p>
        Research protocol: In the literature, five classes of empirical research are identified
[
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]: controlled experiments, case studies, survey research, ethnographies and action
research. In our work, we have selected “case studies” as a research method type. This
method offers a deep understanding of a given phenomenon and explains how and
why this phenomenon occurs.
      </p>
      <p>
        In this work, we use the ABC-Supermarket case for our study.We justify this case as
a critical case to test the fitness measurement approach [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. We proceed with the
case study as follows: first, we identify the criteria of theoretical validity for the
fitness measurement approach [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. To justify our criteria, we make an analysis of
related works and show that these criteria are considered important in many
approaches [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. Then we implement this approach in the
industrial project of Information Systems (IS) evolution in ABC-Supermarket.
While implementing, we (i) observe whether the theoretical criteria of validity are
met; (ii) check that the theoretical criteriaare recognised as “important” by
practitioners (iii) identify other validity criteria, which are important for practitioners
but are omitted in the identified theoretical criteria list (we call these criteria “empirical
vriteria of validity”).
1
1 The fitness relationship definition used in [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] is ‘‘the degree to which the needs,
demands, goals, objectives and/or structure of one component are consistent with the
needs, demands, goals, objectives and/or structure of another component’’.
Our study shows that some of the theoretical criteria are refuted and other factors
related to fitness metrics validity are elicited.
      </p>
      <p>This paper is organised as follows. In Section 2 we introduce the Fitness
Measurement Approach and define the theoretical and the empirical criteria of
validity for this approach. In section 3, we present the case study, by introducing the
industrial project and the scope of our research; we describe how the fitness
measurement approach was implemented, and we report the measurements’ results. In
section 4, we summarise the lessons learned and discuss the gap between our
understanding of the measurements validity and the perception of our industrial
partners about it. In Section 5, we present the conclusions and future work.</p>
    </sec>
    <sec id="sec-3">
      <title>2. Validation of Fitness Measurement Approach</title>
      <p>
        In this section we present the Fitness Measurement Approach developed in [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. We
define a list of theoretical criteria that should be respected by the valid fitness
metrics These criteria correspond to the perception of the Fitness Metrics Approach
validity from the researchers’ point of view.
      </p>
      <sec id="sec-3-1">
        <title>2.1. Introduction of Fitness Measurement Approach</title>
        <p>
          In [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ], authors propose an approach to evaluate the fitness relationship between the
business and the system supporting it. The fitness relationship is established between
components of business and system models. The approach proposes a fitness
measurement according to four points of view (called “factors”): intentional,
informational, functional and dynamic. This approach also identifies the ten fitness
criteria associated with these factors and defines a specific metric for each of them.
For example, the goal satisfaction criterion characterises the intentional alignment
factor. It describes how the business goals specified within an organisation are
supported by the IT systems existing in this organisation. The metric defined for this
criterion is a goal count. Goal count can be measured by calculating the ratio
between the business goals explicitly represented by the corresponding states of the
IT systems and the total amount of business goals (see [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ] for more details). The
measurement result 0 &lt; goal count ≤ 1 can be then analysed: if goal count = 1,
then all goals are taken into account. Please note that the approach does not address
the cost, human and social factors. It is rather concentrated on evaluating the
information which is supposed to be included in the IS.
        </p>
        <p>
          The Fitness Measurement Approach is based on a set of concepts important for the
alignment assessment. Business goal [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ] is a set of stable states of business objects
we seek to achieve. Business object (BO) is an object that represents the entities in
the business domain. Business state (or BO state) is a state of a BO at a time t,
defined by the values of all attributes of this BO. Business actor is defined as
someone or something that interacts with the business or IT system using an interface;
it participates in a business process and triggers external events that result in a state
transition of a BO. Business resource [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ] is a BO, which neither initiates actions nor
causes a state change. In our case, a product specification is an example of a business
resource. System class (or system object) is an object that represents the entities in the
IT system (by analogy with a business object). System event [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ] is associated with a
system state change. By analogy with business activities that are changing business
objects’ states, we consider system events changing states of system objects. System
goals describe purposes of the system [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ]. We say that a system goal maps a
business goal if the states of business objects associated with this business goal are
represented by the states of the corresponding system objects. System state (or system
object state) is a state of a system object (class instance) at a time t. It is defined by
the values of all attributes of this object. Paths are sequences of business (or system)
states. Business laws represent legal rules and principles adopted by business
organisations.
        </p>
        <p>
          The Fitness Measurement Approach addresses the problem of business-IT
alignment in the organisations and strongly relies on the detailed information about
the organisation processes, data models, etc. In case this information is not available,
one can build it up as it was discussed in [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ].
        </p>
      </sec>
      <sec id="sec-3-2">
        <title>2.2. The evaluation hypothesis</title>
        <p>In this section we define evaluation hypotheses of the Fitness Measurement
Approach. The hypotheses consist of a set of theoretical criteria of validity for the
fitness measurements. Based on our research experience and on the related literature
analysis we retain the following validity criteria:
1. The measurements should be based on verifiable observations (models,
specifications, interviews, etc).
2. The measurements’ results should be non-ambiguous – they should have only
one interpretation.
3. The measurements should be effective: they should correspond to the problem
complexity and help practitioners to decide on the course of improvement
actions.
4. The measurements’ results should be accurate: they should precisely localise
the misalignment in the organisation.</p>
        <p>Many works on metrics-based approaches validity confirm our validity criteria.</p>
        <p>
          Verifiable observations: research works [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ], [
          <xref ref-type="bibr" rid="ref22">22</xref>
          ] argue that a metric is valid if it
measures what it purports to measure. To do so, we need to clarify what attribute
we are measuring and how we proceed to measure it. The precision of the
underlined data to be measured is thus important to have a valid measurement.
        </p>
        <p>
          Non-ambiguity: in [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ], authors discuss the validity of a metric structure. In order
to be valid, the metric requires the validity of the attributes it measures, the unit it
uses, the instrument it underlies and the measurement protocol it defines. They argue
that the non-ambiguity of these elements guarantees the metric validity.
        </p>
        <p>
          Effectiveness: Fenton [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ] discusses the metric validity view based on the
identification of the usefulness of a metric for a stakeholder’s purpose. In [
          <xref ref-type="bibr" rid="ref21">21</xref>
          ], [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ],
[
          <xref ref-type="bibr" rid="ref7">7</xref>
          ] the authors argue that metrics constitute a crucial source of information for
decision-making. Indeed, they (metrics) should localise where malfunctions hold and
where resources are needed and give accurate information to managers in order to
help them make decisions.
        </p>
        <p>
          Accuracy: Bodhuin [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ] emphasises that the purpose of metrics is to check the
alignment and to detect misalignment between business processes and the information
system supporting them. He defines two metrics: “technological coverage” indicating
the percentage of activities supported by the system. If an activity i is supported by
the system, the second metric: “technological adequacy” brings more precise
information and measures how adequately is the support of a set of system
components for the activity i.
        </p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>3. The Practical Test of the Evaluation Hypotheses</title>
      <p>
        In order to be widely accepted, each research method or approach, , should prove its
usefulness in practice [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. In the previous section we defined the theoretical criteria
of validity for the fitness measurement approach. In the following, we test if these
criteria remain valid in practice. We argue that proving the empirical validity of a
research approach guarantees its entire validity.
      </p>
      <p>Practical validity addresses the ability of the research approach to meet the
practitioners’ needs: it tells the practitioners how they can benefit from this approach
and what will be the added value. To validate the Fitness Measurement Approach, we
should answer the question: « when do the results of this approach can be considered
by the users as satisfactory? ».</p>
      <p>
        To do so, we apply the Fitness Measurement Approach [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] in a real project. The
appreciation of the results by practitioners informs us about the “practical validity” of
this approach.
      </p>
      <sec id="sec-4-1">
        <title>3.1 The Case study: alignment validation in ABC-Supermarket</title>
        <p>ABC-Supermarket is a mass retail company - one of the leaders on the French market.
ABC-Supermarket groups approximately 3000 independent operators, and thousands
outlets in France and internationally. This company specialises in different sectors of
retail business and is well known in both food and non-food retail markets.</p>
        <p>The initial specialisation of the ABC-Supermarket is food and household products.
Seven years ago ABC-Supermarket integrated a new product category – textile – in its
portfolio and defined a new trade name - ABC-Fashion. To provide the IT support for
purchase (upstream) and retail (downstream) activities for textile products, the
company decided to use the existing information system – the one which is used to
support the business activities for food products.</p>
        <p>Initially, the reuse of the existing IS for ABC-Fashion seemed justified as retail
business defines similar processes for food and textile products. Master data for both
food and textile products also have a lot in common: all these products are
characterised by their type, price, etc. However, over the years, the textile trade name
turnover decreases and the survival of the trade name was threatened. The existing IS
showed its limits in managing the textile business. As a solution, numerous manual
fixes and workarounds have been developed over years. As a result, the existing IS
got overloaded with patches and became not efficient.</p>
        <p>The company decided to make evolve its information systems. The challenge
becomes the trade name survival. The main objective of this evolution is to precisely
define where the existing IS fails in supporting the textile business requirements, and
what improvement can be made to correct the misalignment.</p>
        <p>To answer these questions we apply the Fitness Measurement Approach. While
the fitness measurements results in a set of values, the process of acquiring these
values leads to a deep understanding of the gap between the existing IS and the textile
business requirements.</p>
      </sec>
      <sec id="sec-4-2">
        <title>3.2 Scope of the fitness approach application</title>
        <p>The upstream activities of ABC-Fashion include marketing, products referencing,
providers referencing, outlets billing, etc. These activities are supported by the
existing upstream information system (or UIS) of the company. The downstream
activities of ABC-Fashion address the product management in the outlet stores, e.g.
stock replenishment. These activities are supported by the existing downstream
information system (or DIS).</p>
        <p>The cited UIS and DIS were affected by the evolution requirements. Among listed
above, product referencing is one of the most critical tasks as it maintains the link
between the upstream and the downstream information systems: the outlets use DIS to
order products available in UIS (see fig.1). If a product is not referenced in UIS, it is
not available for ordering. That is why the IT support for the product referencing
represents the main concern for the ABC-Fashion management. Mismanaging the
product referencing activity affects the whole business process: the stock management
(in the upstream and at the outlet level), the ordering process, marketing campaigns...
For this reason, we concentrate in this study on the textile product referencing activity
and how the existing IS (the food one) supports it.</p>
      </sec>
      <sec id="sec-4-3">
        <title>3.3 Constraints of the research work</title>
        <p>Researcher: One researcher, working partial time, during 9 months in the
ABCSupermarket, applied the fitness measurement approach.</p>
        <p>Experimental objects availability: Less than 20% of business and system models are
available in the organisation. Indeed, over ten metrics, two were applied without
building the corresponding “input” models.</p>
        <p>The unavailable artefacts have to be built. Otherwise, fitness measurements cannot
be applied.</p>
      </sec>
      <sec id="sec-4-4">
        <title>3.4 Implementation of the Fitness Measurement Approach</title>
        <p>As cited above, Fitness Measurement Approach relies on business and IS models. As
the most of these models do not exist in the organisation, we built them up based on
the available information sources. As a result, we were able to implement nine fitness
metrics out of ten.</p>
      </sec>
      <sec id="sec-4-5">
        <title>a) Data collection</title>
        <p>To construct the missing business models, we collected data that describe the business
view of ABC-Fashion on the textile product referencing. We interviewed the
following business actors: (i) the head of department of the textile trade name: in
order to understand the textile business requirements, (ii) the responsible of the
product referencing department: in order to apprehend the product referencing
problem, (iii) IS users: in order to understand the IS functioning and how it is used.
The available business process landscape and process specifications were also
analysed.</p>
        <p>To construct the required IT artefacts, we collected data that describe the IT
support of textile product referencing provided by the existing information systems
(UIS and DIS). In order to apprehend the detail of the system architecture and
functioning, interviews have been conducted with the following IT actors: (i) the
referencing system administrator, (ii) the referencing system designers, (iii) the
referencing system developers.</p>
        <p>The following documentations were also analysed: (i) the user manuals of the
product referencing system, (ii) short descriptions of application functionalities
available on the Intranet, (iii) software applications’ data dictionaries, containing the
information about product master data, and (iv) screenshots.</p>
        <p>We also studied the product referencing system testing it on some “toy” examples.
After conducting interviews with the mentioned specialists and the examination of the
existing documentation, two problems have been highlighted: (i) compared to food
products, who’s assortment can be either permanent (always on the shelf) or
nonpermanent (a subject of a commercial operation), textile products are subdivided into
three planning categories: permanent products, collection products (e.g. summer/
winter), and short-cycle products (e.g. fashionable articles, brand promotions, etc); (ii)
apart from the master data, operations on textile products also require textile-specific
data (e.g. colour range and size range).</p>
        <p>Business and system artefacts reflecting these two problems should be built in
order to localise precisely the problem sources and identify accordingly potential
solutions.</p>
      </sec>
      <sec id="sec-4-6">
        <title>b) Consolidation of collected data</title>
        <p>
          We are interesting in highlighting how the existing IS has been adapted to support the
business requirements and to what extent it fits them. To conduct our study, we use:
• the MAP formalism [
          <xref ref-type="bibr" rid="ref23">23</xref>
          ] to build the business and IS goal models describing
respectively the referencing process as it is seen by ABC-Fashion and as it is
supported by the referencing application.
• UML modelling to build the business and the system class diagrams
specifying respectively the data model for the product referencing as it
is seen (or required) by ABC-Fashion and its implementation by the
existing information system.
        </p>
        <p>These artefacts (business goal models and business and IS data models) can
highlight enough the problems cited above. For lack of space, these models are not
presented in the paper.</p>
        <sec id="sec-4-6-1">
          <title>Problem detected by MAP modelling:</title>
          <p>A map is a process model in which a non-deterministic ordering of intentions and
strategies is defined. Intentions are the goals to achieve. Strategies represent the ways
to achieve these goals. A map diagram is a labelled directed graph with intentions as
nodes and strategies as edges between intentions. A section in a map is the triplet &lt;Ii,
Ij, Sij&gt; where Ii is the source intention, Ij is the target intention and Sij is the
strategy connecting the source and target intentions. A section can be, in turn,
refined by a map.</p>
          <p>The comparison between business and IS maps shows that there are some business
goals (at different level of abstraction) which do not correspond any IS goal. Some
business strategies are also not supported by the product referencing application. In fact,
as shown in Fig. 2, the business goal “Plan commercial operations” is not supported by
the Product Referencing application (shown by dashed and grey arrows in Fig. 2(b)). The
system implements only one strategy for achieving the goal Reference products. It does it
from scratch by entering data from the product sheet directly. This means that the system
does not distinguish Collection, Permanent, and Short cycle products and thus processes
all product types in the same way. This explains a partial satisfaction of the business goal
“Reference products”.</p>
          <p>(a) (b)
Fig. 2. (a) Business map for product referencing process (b) UIS map for product referencing
application</p>
          <p>Sections C3, C4 and C5 are refined in sub maps with sub goals and strategies (11
business goals in total). An important part of these sub goals are not supported by the
product referencing application. For lack of space, the sub maps are not presented in
the paper.</p>
        </sec>
        <sec id="sec-4-6-2">
          <title>Problem detected by the UML modeling:</title>
          <p>To reference food products, only the business object Logistic Unit is required. A
logistic unit for the product of a type T specifies a container, a pack, or a box with X
items of the given product inside. It represents a minimal amount of the product of
type T that can be ordered, delivered, or stored at the warehouse (e.g. a box of six
bottles of soda). As (speaking about food products) the products in the logistic unit
are identical – i.e. the same soda bottles - there is no need to reference each product
item within the logistic unit separately, it is the entire logistic unit with X items inside
that is referenced. At the IS level, the logistic unit is represented by the “Product file”
(or “Package” concept) which contains the package description, logistic and tariff
data. The same IS (conceived for food products) is used for textile product. But
applying the same simplified referencing method for textile product, the following has
to be considered: textile products have much more variations within the same type as
they can exist in multiple sizes and colours. Making (by analogy with soda bottles) a
logistic unit contain the same product variation (e.g. a box of 100 jeans {size = S,
colour = ‘Navy’}) is not practical. Therefore logistic units for textile products can
contain multiple variations of the same product type: a box of jeans: {{S,
‘Navy’}&gt;10; {S, ‘Black’}-&gt;10; {M, ‘Navy’}-&gt;20; {M, ‘Black’}-&gt;10; {L, ‘Navy’}-&gt;30;
{L,‘Black’}-&gt;20}.</p>
          <p>Textile business requires the sizes and colors referencing. As the existing system
does not support this need, several workarounds and manual fixes were added, for
instance, a “package content File” describing the content of the logistic unit was added
to inform points of sale about the quantity of products in terms of sizes and colors
contained in each logistic unit. This indicative information provided by the referencing
system can not be exploited by the points of sale to order a specifc product with specific
size and color. The business was constrained by the system limitations causing then the
emergence of gaps with the business requirements. These gaps explain several problems
mainly:
• Points of sales cannot order only one variation of the product to replenish their
stock – they have to order at least one complete logistic unit. This leads to
unsold stock, discounting, and regular company loss as a result.
• The marketing department cannot make forecasting based on the logistic units,
as it is not known which product was most demanded and brought to the company
the maximum profit and which was not sold and caused loss.</p>
        </sec>
      </sec>
      <sec id="sec-4-7">
        <title>3.5 Application of fitness measurements on the constructed data and result analysis</title>
        <p>In this section, we present fitness measurements’ results and propose guidelines that
can help ABC-Fashion to improve the fit between their business and the existing IS.
We note that some problems are detected during the business and IS models building.
Indeed this activity is knowledge intentsive and allowed us to have a first qualitative
aligment evaluation. The fitness measurements confirm and detail the qualitative
evaluation by capturing the malfunctions in more detail and in terms of models’
concepts and allow us to detect how we can act (add such concept if it is absent or
extend its states if it is present but mismanaged in the system...) to improve the
alignment.
{Number of activities represented by system events/Number
of activities}.
{Number of business goals represented by the system
goals/Number of business goals}
{Number of business actors represented by the system user
interfaces/Number of business actors}
{Number of business resources represented by system
classes interfaces/Number of business resources}
{Number of business objects represented by system
classes/Number of business objects}
Measures:
7/32 (21%)
1/11 (9%)
2/5 (40%)
0
6. Information</p>
        <p>accuracy
7. Activity</p>
        <p>completeness
8. Activity</p>
        <p>accuracy
9. System
reliability
{Number of business states represented by system
states/Number of business states}
{Number of business objects for a given activity represented
by system classes /Number of business objects for a given
activity}
{Number of business states for a given activity represented
by system states/Number of business states for a given
activity}
{Number of business laws (where each business state is
represented by a system state and the transitions
between business states are represented by the transitions
between</p>
        <p>Our study revealed the significant differences between the referencing activity
defined for the food and the textile products. This is the reason why referencing of
textile products using the existing information system was so problematic in the past.
The “misfit” between business and IT is confirmed by the measurements’ results
shown in Table 2.</p>
        <p>1&amp;2. Support ratio and Goal satisfaction: Only 20% of business activities are
supported by the system and less than 10% of business goals are satisfied by the
system. In fact, the significant part of upstream activities related to the planning of
commercial operations on textile products (collection and short cycle operations) is
not supported by the Product Referencing application.</p>
        <p>3. Actor presence: the product referencing activity involves five actors. Only two
actors interact with the system. The others (marketing, buyers and the head of the
point of sale) are involved during the planning phase, which is not supported by the
system.</p>
        <p>4. Resource presence: All business resources required for the product referencing
(e.g., specifications, product sheet containing information the product…) are created
using Microsoft Excel software and are not integrated in the referencing system.</p>
        <p>5. Information completeness: only the third of information is managed by the
system. Our analysis revealed the following reasons that justify the low value of
information completeness: (i) the need for referencing different textile product
categories: the referencing of each product category has its own referencing process.
These processes are manual or semi-automatic. Indeed, they are part of the planning
activity which is not supported by the system. (ii) The specific requirement for
referencing related to the textile products, taking into account their colour/size: on one
hand, the concept of “Product” is absent in the system. Indeed, what is present in the
system is the concept of “package” containing n products and not the product itself
(see section 3.4). On the other hand, the size/colour business concept is missing in the
system. It is for this reason that the product can not be referenced with the
corresponding size and color. This generated the problems cited above and explain
why the business goals are not satisfied by the system.</p>
        <p>6. Information accuracy: Although only third of business objects are represented
by system classes, 50% of business states are mapped by system states. This is
explained by the fact that system objects are not consistent with business objects (the
case of “Product” and “Package” concepts), they are forced to be treated in the same
manner.</p>
        <p>7. Activity completeness: More than half of business transitions are not
implemented in the system.
8. Activity accuracy: for some activities, even if a business object (BO) is represented
by a certain system object, the states of the latter might not represent the states of the
BO. In practice, this means that the system counterpart of the BO is not processed by
the IS as expected by business – it is not accurate. This explains why the completeness
of an activity is higher than its accuracy. For other activities, the accuracy is higher
than the completeness. In fact, some BOs are implicitly supported by the system: i.e.
there is no object in the system that represents a given BO, nevertheless the
system supports the behaviour of this BO. For example, the system object “Package”
does not map the Product BO in textile business (as explained in “information
completeness”); however, it substitutes this BO in certain operations – we can say that
the “Package” mimics the behaviour of the Product in the system.</p>
        <p>9. System reliability: More than half of business transitions are not implemented in
the system. This is explained by the fact that only a few activities are supported by the
system.</p>
        <p>We note that the fitness metrics organised around the four alignment factors are
inter-reliated and complement each others. Indeed, the source of a mismatch detected
at the goal level (intentional alignment) is explained in detail by metrics at more
operational levels (functional and informational alignment).</p>
        <p>As we can observe, there are huge differences in the gaps detected by the fitness
metrics. A part of them was covered by workaounds and manual fixes (several
treatments are done manually and several add-ons were made). These workarounds
were not detected by fitness metrics. Indeed, they (workarounds) correspond to
managing the information differently in the system and at the business levels.
Whereas, as presented in table 2, the metrics are based on a correspondance between
business and system concepts. This concern is beyond the scope of this paper. Metrics
are used to detect the gaps, to help us localising the main differences between the
business and the system domains and to propose a set of corrective actions which
would improve the business/IT alignment. Indeed, it was shown that (i) the existing IS
support demonstrates the serious lacks of flexibility: the stock replenishment for
POS is supported only on the logistic unit level. We recommended that the IS
of the ABC-Supermarket should support the textile product referencing on the
product level, rather than on the logistic unit level. (ii) The colour/size management
functionality is essential for textile products; we advised that it should be added to the
existing IS. (iii) Many business activities are not supported by the system.
Consequently, the corresponding actors do not interact with the system and the
handled objects and the required business resources are not present in the system. We
advocated that the organization should prioritize its business activities and revise the
existing IS in order to extend its functionalities to support the critical business
activities. The organisation should also verify whether the interaction of some actors
with the Product Referencing application would be beneficial for product-referencing
processes. If this is the case, new user interfaces should be developed and the business
process may be redesigned taking into account the new actors. Organisation should
also consider the IS support of identified business resources. Indeed, integration of
business resources can increase the interoperability and facilitate the information
exchanges between the business and the IS partners.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>4 Lessons learned</title>
      <p>In section 2.2, four theoretical criteria of validity have been defined. We will now
evaluate the results presented in section 3 against these criteria according to two
points of view: the researchers’ point of view and the practitioners’ point of view. The
first one allows us to establish if the measure values obtained for the fitness metrics
are hundred percent accurate, effective, verifiable and non ambiguous. The other
point of view allows us to evaluate if for the practitioners these set of criteria are
relevant or not.</p>
      <sec id="sec-5-1">
        <title>4.1 Measurements validity: point of view of the researchers</title>
        <p>•</p>
        <p>The measurements are based on verifiable observations: the models required for
the measurements application were built up and validated by specialists within
the organisation.
• The measurements’ results are non-ambiguous: the project stakeholders
understood the results in the same way.
• The measurements are effective: the results have been compared with the study
made by the project team, requested by the CEO of the textile trade name.</p>
        <p>These results were confirmed during discussions with the project stakeholders.
• The measurements’ results are accurate: the results helped us to localise the
misalignments and confirmed the causes of non-fits.</p>
        <p>From our point of view, the fitness measurements are valid; they fulfilled all
theoretical criteria of validity.</p>
      </sec>
      <sec id="sec-5-2">
        <title>4.2 Measurements validity: point of view of the practitioners</title>
        <p>Fitness Measurement Approach was applied by one researcher on a restricted
perimeter of the project as we showed in section 3. Practitioners confirm the
usefulness of the approach and the effectiveness of its corresponding results.
Nevertheless, concerning the reusability of the approach for other projects, the
following criteria related issues bring up:
• The measurements are based on verifiable observations: Building models
requires much time, new skills and further resources. Managers are aware of
their data weaknesses and argue that this is not the priority of the company to
build and to maintain such data.
• The measurement results are non-ambiguous: Managers are aware of their input
data weakness and argue that even with ambiguous results, they would be
satisfied.
• The measurements are effective: Concerning the effectiveness of the
measurements, managers are satisfied. They confirmed that we found problems
that indeed exist, and localised misalignments. Nevertheless, they deprecate the
fact that the results did not indicate the severity of the identified gaps. They
asserted that the prioritisation of gaps severity is very important for the
decisionmaking.
• The measurements’ results are accurate: The accuracy of the results is not
important for practitioners. They are interested in getting more results precision
only if it is done within a short period of time. Otherwise, it does not have much
value. For managers, detailed reports take more time to be done and to be
understood. Simpler results are preferred, at least in a first step. Sometimes,
intuition is enough.</p>
        <p>From the practical standpoint, fitness measurements are useful only if models
required for their application are available in the organisation. For the majority of
organisations, this is not the priority.</p>
        <p>The measurement validity perception of our industrial partners revealed that (i)
some of our criteria are not such important for them, and (ii) some criteria appeared to
be very important but we did not consider them in our work. Overall, practitioners do
not aim a perfect alignment, especially when it requires too much time and resources.
Most of the time, they are interested in some aspects of the problem, not all. What is
important for practitioners is to do things –approximately– right and fast. Besides the
effectiveness, for them, the efficiency criterion is crucial. Table 3 summarises the
importance of measurement validity criteria viewed from the theory and the practice
standpoints.
based
on
verifiable
++
++
++
++
--+
++
-+++</p>
      </sec>
      <sec id="sec-5-3">
        <title>4.3 Discussion of the obtained results</title>
        <p>
          Several factors may limit the generalisation of our results:
• The applicability of the Fitness Measurement Approach depends on the
enterprise models availability in the organisation: if models required for
metrics application exist in the organisation, the approach application is just a
technical task. Otherwise, required models need to be built [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ] and the
application of the approach may become a complex and resource demanding
task.
• The interpretation of the validity criteria by practitioners depends on the
organisation data maturity level. Indeed, the more the data maturity level is high
the more practitioners adhere to our validity criteria and confirm our evaluation
hypothesis.
• Fitness metrics results depend on the quality (and validity) of the built models. In
the big companies, knowledge is spread among many individuals and the
understanding of the same part of business by different individuals may vary and
may even be contradictory. Extensive cross-checking is thus mandatory.
        </p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>5 Conclusions and future work</title>
      <p>Our study revealed that researchers and practitioners do not have the same
understanding of the validity of metrics-based approaches. In fact, some of our
hypotheses have been refuted during the case study and new validity criteria emerged.
The main requirement of practitioners is that alignment measurements give effective
results – even approximately – with regard to the time and the budget constraints of
the project. Our experience allowed us to identify practical guidelines to help the
successful application of the metrics-based approaches and, more precisely, the
enhancement of their applicability in industrial projects. The definitions of these
guidelines are based on (i) the observation of the industrial context and (ii) the
practitioners’ requirements introduced during fitness measurements. We organise
them as practical guidelines in three directions:</p>
      <p>
        Guidance in building models: The maturity of organisations (SEI Capability
Maturity Model [
        <xref ref-type="bibr" rid="ref24">24</xref>
        ]) - has an impact on the metrics applicability. Indeed, metrics rely
on models and verified data, which constitute the inputs of the metrics-driven
approaches. The availability of such data depends on the maturity level of the
organisation. For many organisations required models are often not available, and to
build them is necessary to assess the business-IT alignment. Building such models is
not a trivial task; the project scope should be well defined to allow the collection of
the relevant data. Guidance is thus needed to assist engineers in building the business
and IT models required for performing measurements. In [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ], we proposed a
"buildup process" consisting in four phases: (i) identification of the input data required by
the fitness measurement approach and which should be constructed; (ii) initial data
collection; (iii) data consolidation; (iv) validation of the consolidated data (which will
be used as the input data of the fitness measurement approach).
      </p>
      <p>Customisation of the approach - Time To Market requirement: Business-IT
alignment assessment is a sort of internal audit performed by an organisation in order
to undertake the corrective actions and to enhance its performance. In an evolving
environment, it is very important to react rapidly to the change. If it takes long time to
produce and to communicate results, the measurements results become meaningless.
Constructing the required artefacts for applying metrics-based approaches takes a
long time (data collection and consolidation, and models validation). In order to
address this issue, we observed that it is important to find a way to get, interpret and
present results in a shorter time. For this reason, we argue that the measurement
approaches require more agility, i.e. the results should not be delivered at once and
intermediate results to lead the ways to measure are needed. Intermediate results are
discussed and a deeper analysis can be undertaken if needed. The measurement cycle
can thus be shortened.</p>
      <p>Customisation of the approach - Time Boxing/Design To Cost: The main
constraints of a project are the time, the cost and the quality of the resulting product.
The time boxing (or design to cost) is a strategy used in practice to indicate the
quantity of information, which can be delivered, under the constraint of a limited time
(x months) and a fixed budget (y K euros). We argue that the approach can gain in
usability if it is composed of fine-grained method chunks which can be applied
according to the convenience of the resources involved in the project, i.e. time,
budget and actors.</p>
      <p>In our future work, we will explore the three first directions in order to improve
the “usefulness” of our approach.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>E</given-names>
            <surname>Chan</surname>
          </string-name>
          ,
          <string-name>
            <surname>Y.</surname>
          </string-name>
          , Reich,
          <string-name>
            <surname>B.H.</surname>
          </string-name>
          :
          <article-title>IT alignment: what have we learned?</article-title>
          <source>Journal of Information Technology</source>
          .
          <volume>22</volume>
          ,
          <fpage>297</fpage>
          --
          <lpage>315</lpage>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Renner</surname>
            ,
            <given-names>R. A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Latimore</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Wong</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          (
          <year>2003</year>
          ).
          <article-title>Business and IT operational models in financial services:Beyond strategic alignment. IBM Institute for Business Value study</article-title>
          . Retrieved from http://www-935.ibm.com/services/in/igs/pdf/g510-3267
          <string-name>
            <surname>-</surname>
          </string-name>
          business-and
          <article-title>-itoperatonal-models-financial-services</article-title>
          .pdf
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Bergeron</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Raymond</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Rivard</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <source>Ideal Patterns of Strategic Alignment and Business Performance. Information and Management</source>
          ,
          <volume>41</volume>
          (
          <issue>8</issue>
          ), pp.
          <fpage>1003</fpage>
          --
          <lpage>1020</lpage>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Kearns</surname>
            ,
            <given-names>G.S.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Lederer</surname>
            ,
            <given-names>A.L.</given-names>
          </string-name>
          :
          <article-title>A Resource-Based View of Strategic IT Alignment: How knowledge sharing creates competitive advantage</article-title>
          .
          <source>Decision Sciences</source>
          ,
          <volume>34</volume>
          (
          <issue>1</issue>
          ), pp.
          <fpage>1</fpage>
          --
          <lpage>29</lpage>
          . (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Luftman</surname>
            ,
            <given-names>J.: Assessing</given-names>
          </string-name>
          <string-name>
            <surname>Business-IT Alignment</surname>
          </string-name>
          <article-title>Maturity</article-title>
          .
          <source>In: Communications of the Association for Information Systems</source>
          ,
          <volume>4</volume>
          (
          <issue>14</issue>
          ). (
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Luftman</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Brier</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>Achieving and Sustaining Business-IT Alignment</article-title>
          . In: California Management Reviw,
          <volume>42</volume>
          (
          <issue>1</issue>
          ), pp.
          <fpage>109</fpage>
          --
          <lpage>122</lpage>
          . (
          <year>1999</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Bodhuin</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Esposito</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pacelli</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Tortorella</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Impact Analysis for Supporting the Co-Evolution of Business Processes and Supporting Software Systems</article-title>
          .
          <source>In: Proceedings of Business Process Modelling</source>
          , Development, and
          <string-name>
            <surname>Support</surname>
          </string-name>
          (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Simonin</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Le Traon</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Jézéquel</surname>
            ,
            <given-names>J.M.:</given-names>
          </string-name>
          <article-title>An Enterprise Architecture Alignment Measure for Telecom Service Development</article-title>
          .
          <source>In: 11th IEEE International Enterprise Distributed Object Computing Conference</source>
          , pp.
          <volume>476</volume>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9. Kitchenham, b.,
          <string-name>
            <surname>Pfleeger</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fenton</surname>
          </string-name>
          , N.:
          <article-title>Towards a Framework for Software Measurement Validation</article-title>
          .
          <source>In: IEEE Transactions on Software Engineering</source>
          , pp.
          <fpage>929</fpage>
          --
          <lpage>944</lpage>
          (
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Schneidewind</surname>
          </string-name>
          , N.:
          <article-title>Methodology for Validating Software Metrics</article-title>
          ,
          <source>In: IEEE Trans. Software Eng.</source>
          , vol.
          <volume>18</volume>
          , no.
          <issue>5</issue>
          , pp.
          <fpage>410</fpage>
          --
          <lpage>422</lpage>
          (
          <year>1992</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Fenton</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kitchenham</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Validating Software Measures</article-title>
          .
          <source>Journal of Software Testing, Verification and Reliability</source>
          ,
          <fpage>27</fpage>
          --
          <lpage>42</lpage>
          (
          <year>1990</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Briand</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>El Emam</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Morasca</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Theoretical and Empirical Validation of Software Product Measures</article-title>
          ,
          <source>Technical Report</source>
          (
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Weyuker</surname>
          </string-name>
          , E.:
          <article-title>Evaluating software complexity measures</article-title>
          .
          <source>In: IEEE Transuctinns on So@ Engineering</source>
          , vol.
          <volume>14</volume>
          , no.
          <issue>9</issue>
          , pp.
          <fpage>357</fpage>
          --
          <lpage>365</lpage>
          (
          <year>1988</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Melton</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gustafson</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bieman</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baker</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>A mathematical perspective for software measures research</article-title>
          ,
          <source>J. of Sofmure Eng.</source>
          , vol.
          <volume>5</volume>
          , no.
          <issue>5</issue>
          ,
          <fpage>246</fpage>
          --
          <lpage>254</lpage>
          (
          <year>1990</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Fenton</surname>
          </string-name>
          , N.:
          <article-title>Software measurement: A necessary scientific basis</article-title>
          .
          <source>In: IEEE Trunsuctions on Sofiare Engineering</source>
          , vol.
          <volume>20</volume>
          , no.
          <issue>3</issue>
          , pp.
          <fpage>199</fpage>
          --
          <lpage>206</lpage>
          (
          <year>1994</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Basili</surname>
            ,
            <given-names>V. R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Briand</surname>
            ,
            <given-names>L. C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Melo</surname>
            ,
            <given-names>W. L.</given-names>
          </string-name>
          :
          <article-title>A validation of object oriented design metrics as quality indicators</article-title>
          .
          <source>In: IEEE Transactions on Software Engineering</source>
          , vol.
          <volume>22</volume>
          , no.
          <issue>10</issue>
          , pp.
          <fpage>751</fpage>
          - -
          <lpage>761</lpage>
          (
          <year>1996</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Etien</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rolland</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Measuring the fitness relationship</article-title>
          .
          <source>Requirements Engineering Journal</source>
          ,
          <volume>10</volume>
          (
          <issue>3</issue>
          ),
          <fpage>184</fpage>
          --
          <lpage>197</lpage>
          (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Easterbrook</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Singer</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Storey</surname>
            ,
            <given-names>M.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Damian</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          : Guide to Advanced Empirical Software Engineering. Springer London (
          <year>2007</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Soffer</surname>
            <given-names>P.</given-names>
          </string-name>
          &amp;
          <string-name>
            <surname>Wand</surname>
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>Goal-driven analysis of process model validity</article-title>
          .
          <source>In: Proceedings of Conference on Advanced Information System Engineering</source>
          , pp.
          <fpage>521</fpage>
          --
          <lpage>535</lpage>
          . Springer (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Gmati</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rychkova</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nurcan</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>On the Way from Research Innovations to Practical Utility in EA: The Build-Up Process</article-title>
          .
          <string-name>
            <surname>J. IJSMD.</surname>
          </string-name>
          (
          <year>2010</year>
          ) to be appeared.
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <surname>Harrison</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Software Measurement: A Decision-Process Approach</article-title>
          . In: Advances in Computers, vol.
          <volume>39</volume>
          , pp.
          <fpage>51</fpage>
          --
          <lpage>105</lpage>
          (
          <year>1994</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>El-Emam</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Benlarbi</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Goel</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rai</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>A Validation of Object Oriented Metrics</article-title>
          . In: National Research Council of Canada, NRC/ERB 1076, (
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <surname>Rolland</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Prakash</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Benjamen</surname>
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>A Multi-Model View of Process Modeling</article-title>
          ,
          <source>Requirements Engineering Journal</source>
          .
          <volume>4</volume>
          :
          <issue>4</issue>
          (
          <year>1999</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>24. Capability Maturity Model, http://www.sei.cmu.edu/cmmi/</mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>