<!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>Towards a Quality-Aware Web Engineering Process</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Cristina Cachero</string-name>
          <email>ccachero@dlsi.ua.es</email>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Geert Poels</string-name>
          <email>geert.poels@ugent.be</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Coral Calero</string-name>
          <email>Coral.Calero@uclm.es</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>ALARCOS Research Group. University of Castilla-La Mancha.</institution>
          <country country="ES">Spain</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Faculty of Economics and Business Administration, Ghent University.</institution>
          <country country="BE">Belgium</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>University of Alicante.</institution>
          <country country="ES">Spain</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Evidence-Based Web Engineering (WE) is necessary in order to (1) help industry practitioners in making rational decisions about technology adoption and (2) increase the acceptability of WE methodologies. Particularly, empirical data should be provided to support traditional WE claims such as increased productivity or better quality of the applications deployed using a WE methodology. Unfortunately the WE community is not yet familiar with either systematic quality evaluation issues or empirical research, and therefore tools and guidelines to ease this shift are necessary. In this paper we extend the traditional WE Development Process with quality evaluation and assurance activities that are compliant with the ISO/IEC 14598 set of standards and guarantee that Web applications developed with WE approaches fulfill certain quality criteria. This extension follows the MDA paradigm in order to ensure that the development productivity is not hampered by the additional focus on quality aspects.</p>
      </abstract>
      <kwd-group>
        <kwd>Web Engineering methodologies</kwd>
        <kwd>Web Engineering process</kwd>
        <kwd>quality evaluation</kwd>
        <kwd>quality assurance</kwd>
        <kwd>model-driven development</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>
        It is an avowed fact that WE practices lack an impact on industry [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. This situation
is at least partly caused by a WE field that does not guarantee any kind of
improvement over ad-hoc approaches towards assuring the quality in use of the
deployed applications, where by ‘quality in use’ we mean the efficiency, productivity,
security and satisfaction with which users use the application to satisfy specific goals
under specific conditions [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. In fact, WE methodologies and their associated
development processes do not usually include specific support for the specification
and implementation of quality requirements. This fact contrasts with the definition of
WE as “the application of systematic, disciplined and quantifiable approaches to the
cost-effective development and evolution of high-quality applications in the World
Wide Web” [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. One possible reason for this situation is that, being the final objective
of any quality evaluation process the quality in use (meeting user needs) [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], and
given the fact that assessing quality in use means tracking the use that real users make
of the application under real exploitation conditions, the WE field has traditionally
considered such concerns out of its scope. However, this consideration disregards an
important relationship between quality in use and other quality perspectives. Namely,
according to ISO/IEC 9126, there is a relationship between quality as ‘meeting user
needs’ (that is, quality in use) and quality as a ‘conformance to specifications’ [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ].
Otherwise stated, it is possible to predict the degree of quality in use of the final Web
application by examining which quality specifications are met by the intermediate
products (Web artifacts) of a certain application. The advantages of such change of
perspective translate into cost and quality gains [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>
        The scene regarding quality evaluation in the context of the traditional ad-hoc
approaches towards Web site/application development is just slightly better. Here, the
concern for Web quality is showed on the wide range of Web design guidelines and
automated measures that can be gathered in literature [
        <xref ref-type="bibr" rid="ref12 ref18">12, 18</xref>
        ]. Additionally, and due
to the high expense associated with monitoring the use of the application under real
conditions of use, most of these guidelines and measures (the notable exception being
those based on log analysis techniques) reflect a ‘conformance to specification
perspective’. In these approaches, the relationship between specifications and user
needs is usually implicitly assumed, without providing empirical evidence. Also as a
drawback, the lack of intermediate models supporting those ad-hoc approaches causes
measures to still be centered on the lower (mostly code) levels of abstraction. Given
these facts, it seems clear that an increase of the level of abstraction at which Web
guidelines/measures are applied would be desirable, and such change can only be
achieved if WE practices are adopted and if the WE process includes a quality
evaluation and assurance perspective, from the early development stages till
deployment.
      </p>
      <p>
        In this paper we present a quality-aware WE process that fulfills these conditions
and systematically integrates quality evaluation and assurance issues at every stage of
the WE process without hampering the cost and/or time to market of the delivered
application. Our proposal explicitly recognizes the relationship between the ’meeting
user needs’ and ‘conformance to specifications’ perspectives, and provides a working
basis to empirically prove such relationships. In order to perform such inclusion of
quality concerns in existing WE methodologies in a sensible, consistent and practical
way, our research aims at the development of three elements: (1) a quality-aware WE
process, (2) a set of general-purpose WE quality models specific for each stakeholder
and/or WE artifact and, (3) a WE-Software Measurement Metamodel (WE-SMM)
that permits the developer to operationalize and, if needed, also tailor, those quality
models according to a particular domain and/or application. In this paper we are
centering on the first element (the process). Readers interested in the quality
instruments (Quality Models and the WE-SMM) that support such processes are
referred to [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. To justify the necessity for our proposal, in Section 2 we present a
brief overview of the state of the art in quality instruments and WE quality evaluation
processes. In Section 3 the generic WE process is presented, together with an analysis
of how each artifact and/or activity may influence the quality in use of the deployed
application. Section 4 then explains our proposal of a quality-aware generic WE
process and how it was developed based on the ISO 14598 set of standards [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. Last,
conclusions and future work are presented in Section 5.
      </p>
    </sec>
    <sec id="sec-2">
      <title>2 Related Work</title>
      <p>
        In order to evaluate quality it is necessary to count on instruments that are based on
clear definitions. One of these instruments is a quality model. A quality model is
defined in ISO as the set of characteristics and the relationships between them which
provide the basis for specifying quality requirements and evaluating quality. Quality
models for software products are far from scarce. Well known pioneer models include
the McCall, Boehm and Dromey models. Because of the widespread use of the ISO
family of quality-related standards (including the ISO/IEC 9126 software quality
standard), many proposals have aimed at tailoring/refining/improving these standards.
For example, the Quint2 quality model regards the ISO/IEC 9126 standard as a valid
but incomplete quality model, and therefore tries to complete it with additional
features. If we now focus on WE, there are various proposals of specific WE quality
models, most of them tackling the specificities of the ‘meet the user needs’ quality
perspective on Web applications [
        <xref ref-type="bibr" rid="ref1 ref17 ref19 ref6 ref7">1, 6, 7, 17, 19</xref>
        ]. From these proposals, only [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] and
[
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] consider the quality of other artifacts than code that are constructed during the WE
development cycle, and none of them provides independent quality models for the
different levels of abstraction in the WE process. These approaches can however be
refined and complemented by research on model quality (e.g. Lindland et a.
framework [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], Krogstie et al. framework [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] and Moody and Shanks framework
[
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]), which provides further insight into how the quality concept can be dealt with at
higher levels of abstraction than the actual software code.
      </p>
      <p>
        Another instrument is a quality evaluation process that prescribes how and when
quality evaluation must be performed. An example here is the ISO/IEC 14598 series
of standards that gives an overview of software product evaluation processes and
provides guidance and requirements for evaluation of general software products. In
the WE field, some quality evaluation processes are WebQUEM [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] and WebTango
[
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. Similar to the proposed WE quality models, the main drawback of most of these
processes is that they assume that the quality evaluation is performed on the deployed
application. In fact, only [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] and [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] recognize the necessity to conciliate the WE
quality evaluation process with the general WE development process. The general
structure of such WE development process is presented next.
      </p>
    </sec>
    <sec id="sec-3">
      <title>3 The WE Process</title>
      <p>The relative immatureness of the WE field causes a lack of agreement on a
common Web development process. However, most methodologies share a set of
artifacts and activities that are presented in Figure 1 and that may be regarded as a
simplified WE process where, for the sake of readability, the iterative and incremental
nature of this process has been hidden. This process, based on the Model Driven
Engineering paradigm, departs from a general business model and includes (1) a
(manually performed) functional requirements workflow, whose outgoing artifact is a
use case model, (2) an analysis workflow, whose output is a domain model (usually
an ER diagram or a UML class diagram), (3) a conceptual design workflow, whose
outputs are a navigation and a presentation model (expressed by means of UML
profiles or proprietary), (4) a detailed design workflow that introduces platform and
technology specific features (typically J2EE and .NET) and (5) an implementation
workflow, which results in a Web application that is ready to be deployed. Variants of
this process model exist, usually to include additional Platform Independent Models
(PIM’s) and/or Platform Specific Models (PSM’s) (architectural models, business
process models, different languages and/or platforms, etc.) that further enrich the
application specification. Additionally, WE methodologies promote the use of
automatic and/or (semi-)automatic transformations among most of these artifacts
(depicted as circles that represent stereotyped activities in Figure 1) that, based on the
underlying meta-models, streamline the process and guarantee traceability among and
between concepts.</p>
      <p>WORKFLOWS
Requirements
Analysis</p>
      <p>MDA
CIM</p>
      <p>PIM
Conceptual Design</p>
      <p>The use of a WE process with (semi-) automatic transformations prevents some
development problems such as inconsistencies among models, lack of traceability,
lack of technical soundness, etc. However, this (semi-)automatic nature of the WE
process also may cause the propagation of quality flaws through levels of abstraction.
Hence, quality problems that nowadays are just detected at deployment time may
have been introduced at any previous stage of development. As an example, the
omision of certain domain relationships (which are present in the end-user’s mind) in
the domain model may lead to an improper navigation structure that hampers the
application usability.</p>
      <p>The six levels of refinement presented in Figure 1 imply in fact six different WE
products, each one involving a different purpose of evaluation. From them, the first
five can be regarded as ‘internal products’ in the sense that they refer to models of the
product, and not the product itself, while the deployable Web application is an
external product (the product that actually reaches first the testing environment and
then the market). A graphical representation of the products, together with their
hypothetical quality inter-relationships, is presented in Figure 2. Such relationships
(still to be empirically proven by the WE community) are based on (1) the
aforementioned ISO/IEC assumption that quality at one level of abstraction may be
used to predict quality at lower levels of abstraction and (2) the already mentioned
underlying traceability of concepts among the different WE models (see Figure 1).</p>
      <p>Internal
Measures
(on models)
Fig. 2. Quality in the WE lifecycle (adapted from ISO/IEC 9126)</p>
      <p>Namely, in Figure 2 we can graphically observe how the internal quality
dimensions may affect an external quality dimension, that is, the quality of the final
application (code) as perceived under testing conditions. Finally, such external quality
may influence the actual quality of the application in real contexts of use. Next, we
are presenting how we have enriched the WE process of Figure 1 to introduce quality
concerns during the development of each one of the WE products.</p>
    </sec>
    <sec id="sec-4">
      <title>4 Towards a Quality-Aware WE Process</title>
      <p>Even if it is true that the ISO set of standards accompanies the definition of quality
models (defined in the ISO/IEC 9126) with a software evaluation process (defined in
the ISO/IEC 14598), it is a well known fact that both standards are not sufficient to
direct the practitioner in the quality evaluation process. One reason for this fact may
be that ISO/IEC 14598 was finished before the last version of the ISO/IEC 9126, and,
while it provides generic linkages between the high-level concepts of the ISO/IEC
9126 quality models (characteristics, subcharacteristics and measures), the evaluation
Deployed Application
Deployed application in test in real environment</p>
      <p>Legend:</p>
      <p>Quality
in Use
influences
depends on</p>
      <p>Contexts
of use
External Measures</p>
      <p>
        Measures of Actual Usage
(in testing environment) (under real conditions of use)
process is not yet specified in the format of specific prescriptive quality engineering
practices. Otherwise stated, there is a mapping gap between standards and existing
development process. Figure 3 presents how we propose to fill in this gap. Our
proposal includes the encapsulation of each pair purpose of evaluation-product type in
an independent WE quality model (dotted elements, see Figure 3) that gathers
measurement concepts, attributes and measures relevant for the purpose of evaluation
at such level of abstraction. Additionally, in order to preserve the semi-automatic
nature of the WE process, our proposal includes the operationalization of quality
models by means of a WE measurement meta-model instantiation (shadowed
elements, see Figure 3). The WE measurement meta-model and the transformations
that permit to calculate measurement results and, if necessary, evolve the WE models
are out of the scope of this paper. Interested readers are referred to [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] for a whole
description of such operationalization. The result of evolving each WE model based
on a specific quality measurement model is then used at the next stage of
development.
      </p>
      <p>CIM Business Requirements</p>
      <p>PIM Analysis</p>
      <p>Conceptual Design
:RF
Measurement Model
:Representational Faithfulness</p>
      <p>Quality Model</p>
      <p>As the reader may already have inferred, the main advantages of a process such as
the one included in Figure 3 are:
:Business</p>
      <p>Model
:Requirements</p>
      <p>Model
:Domain
Model
:Navigation</p>
      <p>Model
TMraondsefol2rmMaotdioenl T1</p>
      <p>Model2Model
Transformation T2
Model2Model</p>
      <p>Transformation T3</p>
      <p>It integrates quality evaluation practices in current WE practices so that
each problem is detected and solved as soon as possible in the
development lifecycle, what, as we have already outlined, diminishes
costs and time to market of high-quality web applications.</p>
      <p>
        It is based on different WE-quality models, each one providing the most
suitable basis on which to fulfill a given quality evaluation purpose. This
specificity of model and evaluation purpose helps to make such models
more concise. We agree with [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ] in that the construction of concise
quality models that are integrated in a quality management process are of
prime importance to focus the quality evaluation task and carry out a
comprehensive quality analysis in a very limited timeframe.
      </p>
      <p>It explicitly recognizes the relationship that, according to ISO, exists
among quality of intermediate artifacts. Such relationships justify the
necessity to assure that the outgoing artifact of each workflow has the
required level of quality before going on to the next step of development.</p>
      <p>As a further advantage, and in order to facilitate its adoption by industry, our
proposal conforms to ISO/IEC 14598. This means that it (1) makes use of quality
models and (2) it covers all the process steps defined in clause 6 of the standard. Next
we are further explaining this last assertion.
4.1 Conformance to ISO 14598 set of standards</p>
      <p>Although, in order to keep faithful to the WE philosophy, our approach is
presented as an enrichment of a general WE process, it is possible to superpose the
workflow defined by the ISO/IEC 14598 (much better known in industry) over the
quality-aware WE process presented so far. For such superposing, the ISO/IEC
14598-3 (development) is of special interest. ISO/IEC 14598 poses two main
requirements for compliance. On one hand, the quality evaluation must be based on a
quality model. This end is fulfilled by our approach, as we already saw in Section 3.
On the other hand, ISO/IEC 14598 demands that the evaluation process follows the
following steps: (1) Establish Evaluation Requirements (purpose of evaluation, types
of product to be evaluated and quality models), (2) Specify the Evaluation (select
measures, establish decision criteria and establish indicators for assessment, (3)
Design Evaluation (produce evaluation plan) and (4) Execute Evaluation (take
measures, compare with decision criteria and assess results). Next we are presenting
how we are covering each of these activities.</p>
      <p>
        Establish Evaluation Requirements. The overall purpose of evaluation of our
proposed quality-aware WE process is (using the GQM template [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]) “analyze the
different WE artifacts for the purpose of assessing their conformance with respect to
certain quality specifications from the viewpoint of the end-user of the application in
the context of testing environments”. This purpose is fulfilled by evaluating the main
six WE models (types of product): requirements, domain, navigation, presentation,
implementation and code. For each one of these products we need to specify a
different quality model.
      </p>
      <p>
        Specify the Evaluation. Particular applications may have specific requirements that
may make necessary a tailoring of the characteristics (measurable concepts),
measures, decision criteria and/or indicators included in a given quality model.
Aware of this fact, our proposal (see Figure 3) provides both general quality models
defined at each level of abstraction and particular measurement models, which
represent an operationalized version of the quality model. During this
operationalization the designer (1) makes sure that all the relevant concepts are
defined (e.g. that all measures have associated decision criteria, general or particular
to the actual application being quality-evaluated) and (2) expresses the quality model
in a machine-readable way (by instantiation of a well-defined WE Software
Measurement Meta-model (WE-SMM)). Hence, this operationalization acknowledges
the fact that certain quality elements may diverge depending on particular application
domains or even particular application’s quality needs. Nonetheless, the need to fulfill
the restrictions imposed by such meta-model contributes to guaranteeing the
correctness and completeness of the resulting instantiation. Interested readers in how
such operationalization is performed are referred to [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>Design the evaluation. In our proposal, each evaluation activity must be performed
as soon as the incoming WE artifact is produced and before stepping into the next WE
process activity (which makes up the evaluation schedule). The evaluation method
consists on the automatic application of the WE measurement meta-model
instantiation to the particular WE model we are dealing with.</p>
      <p>
        Execute the evaluation. Finally, we propose to execute the evaluation in an
automatic way, by means of transformation rules that interact with the WE-SMM and
with the particular WE artifact meta-model to (1) get measures results, (2) calculate
indicators, (3) compare indicators with decision criteria and (4) if feasible, evolve the
models to improve the indicator value. Interested readers in how such execution is
performed are referred to [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
    </sec>
    <sec id="sec-5">
      <title>5 Conclusions and Further Work</title>
      <p>
        In this paper we have proposed a WE process that integrates quality evaluation and
assurance activities at every abstraction level in the development of the Web
application. Building up a high-quality Web application from the end-user perspective
all along the WE process implies a shift from the traditional WE quality assessment
perspective to a WE Total Quality Management (TQM) approach. Briefly speaking,
adopting a Total Quality Management perspective means setting the focus on
preventing rather than detecting errors, with the ultimate aim of reducing the reliance
on code inspections as a way of achieving quality [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. Our assumption is that
providing practitioners with WE methodologies that offer automated support for
assuring quality will not only back some of the WE traditional claims of high
productivity, short time-to-market and high quality, but also increase the acceptance
rate of WE methodologies in industry. This in turn would provide the WE community
with more data on which to refine their knowledge about when and how to use a
given WE methodology.
      </p>
      <p>This work is just a first step towards the inclusion of quality issues in the WE field. In
order to increase the reusability of our framework, it would be necessary for the
definition of generic WE-quality models to reach a consensus and identify a set of
common attributes that characterize any of the WE artifacts (i.e. models) proposed by
the best known WE methodologies, and center the quality evaluation on such
common concepts. We do claim that such common set of concepts exist at each level
of abstraction, as the recent MDWEnet initiative1 backs. Only such attributes, together
with a general definition of measures, independent from particular notations, should
be included in WE-quality models in order to make them reusable among WE
methodologies. Also, general tailoring rules of these quality models for certain
application families should be provided in order to ease the operationalization of the
quality models. Transformations should be implemented to support each of the
measures included as part of those quality models, and empirical research should take
place to demonstrate how the measurement results taken at early stages of
development influence the quality in use of the final application. Even if we are
conscious that we may never reach such a rigorous, evidence-based quality
assessment, we believe that even the automatic assessment of a few empirically
validated measures at each level of abstraction could already significantly increase the
satisfaction of WE users.</p>
    </sec>
    <sec id="sec-6">
      <title>Acknowledgments</title>
      <p>This paper has been supported by the Spanish Ministry of Science and Technology (Grant
PR2006-0374 for University Teaching Staff Stages at foreign Universities and projects
CALIPSO (TIN20005-24055-E), MEC-FEDER (TIN2004-03145), ESFINGE
(TIN200615175-C05-05), METASIGN (TIN2004-00779) and DSDM (TIN2005-25866-E)). Also, this
research is part of the DADASMECA project (GV05/220), financed by the Valencia
Government and the DADS (PBC-05-012-2) and the DIMENSIONS (PBC-05-012-1) projects,
financed by the Regional Science and Technology Ministry of Castilla-La Mancha (Spain).
Also, we would like to thank Dr. Mario Piattini for his continuous support.
1 Interested readers can follow the lines of work and the state of evolution of this project by
contacting the MDWEnet project members
(http://www.pst.informatik.unimuenchen.de/~zhangg/cgi-bin/mdwenet/wiki.cg)</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Abrahao</surname>
            ,
            <given-names>S</given-names>
          </string-name>
          , Insfran,
          <string-name>
            <surname>E.</surname>
          </string-name>
          (
          <year>2006</year>
          )
          <article-title>Early usability evaluation in Model-Driven Architecture Environments</article-title>
          .
          <source>In Proceedings of the Sixth IEEE International Conference on Quality Software</source>
          , IEEE Press, Wiley, Chichester.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Basili</surname>
            ,
            <given-names>V.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Galdiera</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Rombach</surname>
            ,
            <given-names>H.D.</given-names>
          </string-name>
          (
          <year>1994</year>
          )
          <article-title>Goal Question Metric paradigm</article-title>
          , in: J. J.
          <string-name>
            <surname>Marciniack</surname>
          </string-name>
          (Ed.),
          <source>Enciclopaedia of Software Engineering</source>
          , Vol
          <volume>1</volume>
          , John Wiley and Sons.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Briand</surname>
            <given-names>LL</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Morasca</surname>
            <given-names>S.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Basili</surname>
            <given-names>V</given-names>
          </string-name>
          (
          <year>1999</year>
          )
          <article-title>Defining and Validating Measures for Objectbased High-level Design</article-title>
          .
          <source>IEEE Transactions on Software Engineering</source>
          <volume>25</volume>
          (
          <issue>5</issue>
          ),
          <fpage>722</fpage>
          -
          <lpage>743</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Cachero</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ;
          <string-name>
            <surname>Meliá</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ;
          <string-name>
            <surname>Genero</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Poels</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Calero</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          (
          <year>2006</year>
          ).
          <article-title>Towards improving the navigability of Web applications: a Model Driven Approach</article-title>
          . Working Paper D/
          <year>2006</year>
          /7012/64. Available On-line at: www.feb.ugent.be/Fac/Research/WP/Papers/ wp_06_
          <fpage>419</fpage>
          .pdf
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Cachero</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Poels</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Calero</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          (
          <year>2007</year>
          )
          <article-title>Towards a Quality-Aware Engineering Process for the development of Web Applications</article-title>
          . Working paper. Available On-line at http://www.dlsi.ua.es/~ccachero/pPublicaciones.htm
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Calero</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruiz</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Piatinni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          (
          <year>2005</year>
          )
          <article-title>Classifying web metrics using the web quality model</article-title>
          .
          <source>In Online Information Review Journal, OIR - 29</source>
          ,
          <issue>3</issue>
          ,
          <string-name>
            <given-names>Emerald</given-names>
            <surname>Literari</surname>
          </string-name>
          , United Kingdom.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Comai</surname>
            <given-names>S.</given-names>
          </string-name>
          ; Matera,
          <string-name>
            <given-names>M.</given-names>
            ;
            <surname>Maurino</surname>
          </string-name>
          ,
          <string-name>
            <surname>A.</surname>
          </string-name>
          (
          <year>2003</year>
          )
          <article-title>A Model and an XSL Framework for Analyzing the Quality of WebML Conceptual Schemas</article-title>
          .
          <source>In Proceedings of the International Workshop on Conceptual Modeling Quality</source>
          , p
          <fpage>339</fpage>
          -
          <lpage>350</lpage>
          . Springer-Verlag, Heidenberg, LNCS 2784
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Garvin</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          (
          <year>1984</year>
          )
          <article-title>What Does “Product Quality” Really Mean?</article-title>
          , Sloan Management Review,
          <year>Fall 1984</year>
          , pp.
          <fpage>25</fpage>
          -
          <lpage>45</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Heuser</surname>
            ,
            <given-names>L</given-names>
          </string-name>
          (
          <year>2004</year>
          )
          <article-title>The real world or Web Engineering?</article-title>
          <source>In Proceedings of the Fourth International Conference on Web Engineering</source>
          , p
          <fpage>1</fpage>
          -
          <lpage>5</lpage>
          , Springer-Verlag, Heidelberg, LNCS 3140.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10. ISO/IEC 9126 (
          <year>2001</year>
          )
          <article-title>Software engineering - Product quality - Part 1: Quality model</article-title>
          . International Organization for Standardization, Geneva.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11. ISO/IEC 14598 (
          <year>1999</year>
          ).
          <source>Information technology - Software Product Evaluation</source>
          . International Organization for Standardization. Geneva.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Ivory</surname>
            <given-names>MY</given-names>
          </string-name>
          (
          <year>2004</year>
          <source>) Automated Web Site Evaluation</source>
          . Kluwer Academic Publishers, Norwell.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Krogstie</surname>
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lindland</surname>
            <given-names>O.I.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Sindre</surname>
            <given-names>G.</given-names>
          </string-name>
          (
          <year>1995</year>
          )
          <article-title>Defining quality aspects for conceptual models</article-title>
          .
          <source>ISCO</source>
          <year>1995</year>
          :
          <fpage>216</fpage>
          -
          <lpage>231</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Lang</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ;
          <string-name>
            <surname>Fitzgerald</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          (
          <year>2005</year>
          )
          <article-title>Hypermedia Systems Development Practices: A Survey</article-title>
          .
          <source>IEEE Software 22(2)</source>
          ,
          <fpage>68</fpage>
          -
          <lpage>75</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Lindland</surname>
            <given-names>O.I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sindre</surname>
            <given-names>G.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Solvberg</surname>
            <given-names>A.</given-names>
          </string-name>
          (
          <year>1994</year>
          )
          <article-title>Understanding Quality in Conceptual Modeling</article-title>
          .
          <source>IEEE Software</source>
          Vol
          <volume>11</volume>
          (
          <issue>2</issue>
          ) pp
          <fpage>42</fpage>
          -
          <lpage>49</lpage>
          . IEEE Computer Society Press. Los Alamitos, CA, USA
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16. Moody D.L. and
          <string-name>
            <surname>Shanks</surname>
            <given-names>G.G.</given-names>
          </string-name>
          (
          <year>2003</year>
          ).
          <article-title>Improving the quality of data models: empirical validation of a quality management framework</article-title>
          .
          <source>Information Systems</source>
          <volume>28</volume>
          :
          <fpage>619</fpage>
          -
          <lpage>650</lpage>
          . Elsevier Science Ltd.
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Moraga</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calero</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Piattini</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          (
          <year>2006</year>
          )
          <article-title>Ontology Driven Definition of a Usability Model for Second Generation Portals</article-title>
          .
          <source>In Proceedings of the 1st International Workshop on Methods</source>
          ,
          <article-title>Architectures &amp; Technologies for e-Service Engineering</article-title>
          (MATeS
          <year>2006</year>
          ) ACM Press. Vol.
          <volume>155</volume>
          . ISBN:
          <fpage>1</fpage>
          -
          <lpage>59593</lpage>
          -435-9
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Nielsen</surname>
            <given-names>J</given-names>
          </string-name>
          (
          <year>2000</year>
          ).
          <source>Designing Web Usability: The Practice of Simplicity. New Riders</source>
          , Berkeley.
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Olsina</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rossi</surname>
            ,
            <given-names>G</given-names>
          </string-name>
          , (
          <year>2002</year>
          )
          <article-title>Measuring Web Application Quality with WebQEM</article-title>
          ,
          <source>In IEEE Multimedia Magazine</source>
          , Vol.
          <volume>9</volume>
          ,
          <string-name>
            <surname>Nº</surname>
            <given-names>4</given-names>
          </string-name>
          , pp.
          <fpage>20</fpage>
          -
          <lpage>29</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>