<!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>A comparison of deontic matrices, maps and activity diagrams for the construction of situational methods</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Valeria Seidita</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Jolita Ralyté</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Brian Henderson-Sellers</string-name>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Massimo Cossentino</string-name>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Nicolas Arni-Bloch</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>CUI, University of Geneva</institution>
          ,
          <addr-line>Rue de Général Dufour, 24, CH-1211 Genève 4</addr-line>
          ,
          <country country="CH">Switzerland</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>DINFO, Università degli Studi di Palermo Viale delle Scienze</institution>
          ,
          <addr-line>90128 Palermo</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>SET - Université de Technologie Belfort-Montbéliard - 90010 Belfort cedex</institution>
          ,
          <country country="FR">France</country>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>University of Technology</institution>
          ,
          <addr-line>Sydney, PO Box 123, Broadway, NSW 2007</addr-line>
          ,
          <country country="AU">Australia</country>
        </aff>
      </contrib-group>
      <fpage>85</fpage>
      <lpage>88</lpage>
      <abstract>
        <p>Several approaches have been proposed to support situational method engineering (SME), each of them providing different techniques and using different basic concepts. In this work, we propose a framework for comparing SME approaches based on a generic SME process model. Three approaches are presented and compared by using this framework. Constructing Situational Methods - A Generic Process Model Starting from the assumption proposed by Gupta and Prakash [4] that a method engineering process is composed of three main phases, method requirements engineering, method design and method construction, we have described a high level (generic) process model for SME with the following phases: method requirements engineering, method fragments selection and method fragments assembly. The first phase of SME aims to specify requirements for a project-specific method and can be decomposed into three main activities: project situation assessment, method/process goals identification and process model definition; together with affiliated tasks. The second phase encompasses the selection of method fragments/chunks from the repository corresponding to the requirements defined during the first phase. We identify three main activities in this phase: preliminary</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>
        Situational method engineering (SME) involves, inter alia, a method construction
element. Although there are many publications on the topic [
        <xref ref-type="bibr" rid="ref11 ref5 ref7 ref8">5, 7, 8, 11</xref>
        ], each offers
its own individualistic approach. In this paper, we introduce an evaluative framework
based on a generic situational method engineering process model. After a description
of this process model in section 2, in the following section (3) we analyse, in turn, the
use of three techniques (a) deontic matrices, (b) maps and (c) activity diagrams for
their applicability to situational method engineering. In section 4, three approaches
using these techniques are compared by applying our evaluation framework.
fragments selection, method fragments analysis and final selection. The third phase
deals with selected method fragments/chunks assembly. It is refined into three
activities: assembly technique assessment, final identification of process, and
validation and evaluation.
      </p>
      <p>We found it necessary to extend this framework by specifying 1) the kind of
support provided by the application of each approach, 2) the presence of guidelines,
3) the possibility of using some kind of automation for each phase, 4) flexibility at
three levels: high (each method fragment can be easily added to or removed from the
process model), medium (every operation on fragments can be made under certain
constraints) and low (no flexibility is supported).
3</p>
    </sec>
    <sec id="sec-2">
      <title>Three Techniques for Method Construction</title>
      <p>
        A deontic matrix is a two dimensional matrix the values in which serve to link the
various process components. Deontic values for any specific pair of process
components depend on the context of the specific project, the development team
skills, etc. and are typical of the OPF approach (e.g. [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]). A process engineer has to
configure OPEN by creating instances of its metamodel (i.e. method fragments) that
are suitable for using on the specific project. In so doing, they have to use their own
experience and knowledge on new method requirements.
      </p>
      <p>
        A Map [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] is a navigational structure in the form of a graph where nodes are
intentions and edges are strategies. It is possible to follow different strategies for each
couple of target/source intentions, thus dynamically determining different solution
paths between start and end. The Map formalism is used by Ralyté et al. [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] during
the construction process of a new method by following three main steps: methods
requirements specification, method chunks selection and method chunks assembly. A
map is also used to represent the method chunk itself, thus enabling the designer to
apply similarity measures between the requirement map and the method chunk
representation to assess if a method chunk matches a specific requirement [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
      <p>
        Three SME papers [
        <xref ref-type="bibr" rid="ref1 ref10 ref11">1, 10, 11</xref>
        ] use a version of UML activity diagrams, offering an
approach for the development of a new method using typical steps of: (i) identifying
the needs for the new method by analysing the application context; (ii) selecting, from
existing methods, those meeting some required aspect; (iii) analysing selected
methods and storing them in a method base; (iv) assembling method fragments into a
new method to obtain situational methods.
      </p>
      <p>
        Both [
        <xref ref-type="bibr" rid="ref10 ref11">10, 11</xref>
        ] claim to use a meta-modelling technique to model a complete
process or part of it; however, the technique is in fact made up of two diagrams, a
UML Activity diagram and a Class diagram, respectively used to model the process
and its related concepts, resulting in a novel hybrid diagram named process-data
diagram. The method engineer selects a set of existing methods that could fit the
application context on the basis of personal knowledge and expertise, argued to be
quite straightforward. The approach in [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] is more strictly based on SPEM’s Activity
Diagram [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. While van de Weerd et al.’s approach [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] results in a joint diagram
(activity plus class) to model process and data, SPEM presents these two views in a
single diagram. Here, the process of creating a new method consists of analysing the
new process and selecting and assembling the fragments. In this approach, SPEM
activity diagrams are used only to model process and artefacts; the representation of
data is not detailed and another diagram, where each artefact is related to the data it
represents (according to a general meta-model of the system) [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], is used.
4
      </p>
    </sec>
    <sec id="sec-3">
      <title>Comparison of the SME Approaches</title>
      <p>Using the framework described in Section 2 we can evaluate the potentiality of
each approach to support the construction of an SME process. For each approach we
ask the following question: Does it provide help for the activity carried out in each
generic process phase? In this sense we have to examine if, for each approach, the
specific phase/activity/task is performed and how this is done. Table 1 presents the</p>
      <sec id="sec-3-1">
        <title>Level of flexibility</title>
        <p>Values: (1) S/NS supported/not supported; (2) I/SF/F informal/semi-formal/formal; (3) G/NG
guidelines/no guidelines; (4) T/P/NT tool/prototype/no tool support; fs from scratch; br by reuse; Proc
Process-driven, Prod Product-driven; Ass Association; Int Integration
comparison results using our evaluative framework. We can conclude that for the
Requirements Engineering phase the three approaches do not present substantial</p>
        <p>Generic SME Process</p>
        <p>Activity Task/Attribute
Phase
t
n
e
rem ing
iu r
hodeqR igeennE
t
e
M</p>
      </sec>
      <sec id="sec-3-2">
        <title>Project Situation Assessment</title>
      </sec>
      <sec id="sec-3-3">
        <title>Method/process</title>
        <p>goals
identification
Process model
definition</p>
      </sec>
      <sec id="sec-3-4">
        <title>Characterisation of the project environment Identification of the project features</title>
        <p>Method situation
evaluation</p>
      </sec>
      <sec id="sec-3-5">
        <title>Way of identification</title>
      </sec>
      <sec id="sec-3-6">
        <title>Source</title>
        <p>Technique
ts Preliminary
en fragments
ragm itcno selection Way of selection
F le Method fragments analysis
hod eS
te Final selection
M
s
t
n
ragehodFm lssybeAm
t
e
M</p>
      </sec>
      <sec id="sec-3-7">
        <title>Assembly Positioning selected</title>
        <p>technique method fragments
assessment Assembly technique
Final identification of process model</p>
      </sec>
      <sec id="sec-3-8">
        <title>Validation and evaluation Map [8] S, SF, G,</title>
        <p>
          differences; some have guidelines and/or specific tools and all of them result in a set
of requirements that is the basis for the fragments selection phase. Both deontic
matrices and maps provide more formal support in the Fragment Selection phase,
reflected in the potential to use an automated tool for the selection. In contrast, the
first approach based on activity diagrams is informal being based principally on the
designer’s knowledge of the repository or existing design processes. Only the last
phase (final selection) prescribes the use of a semi formal diagram (activity diagrams)
as a reference point for the final selection. In the Fragment Assembly phase, only the
Map-based approach [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ] formally supports the assessment of assembly techniques
while all the others bring to a kind of assembly on the fly where fragments are
selected principally based on designers’ knowledge, data they deal with or on the
results of applying deontic matrices, so it is almost obvious that they can be
assembled by merely putting them together. The activity of validation and evaluation
of the obtained method is supported in Ralyté’s and van de Weerd et al. approaches,
which provide specific quality validation rules.
        </p>
        <p>In our future work we also aim to use this framework for evaluating other SME
approaches and to investigate the possibility to combine different SME approaches.</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Cossentino</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gaglio</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Garro</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Seidita</surname>
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Method Fragments for agent design methodologies: from standardization to research</article-title>
          .
          <source>International Journal on Agent-Oriented Software Engineering</source>
          .
          <volume>1</volume>
          (
          <issue>1</issue>
          ),
          <year>2007</year>
          . (in press)
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Cossentino</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sabatucci</surname>
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Seidita</surname>
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>SPEM Description of the PASSI Process</article-title>
          . http://www.pa.icar.cnr.it/cossentino/FIPAmeth/metamodel.htm,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Firesmith</surname>
            <given-names>D.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Henderson-Sellers</surname>
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>The OPEN Process Framework</article-title>
          . An Introduction, Addison-Wesley, pp.
          <fpage>330</fpage>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Gupta</surname>
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Prakash</surname>
            <given-names>N.</given-names>
          </string-name>
          :
          <article-title>Engineering Methods from Method Requirements Specifications</article-title>
          .
          <source>Requirements Engineering Journal</source>
          .
          <volume>6</volume>
          (
          <issue>3</issue>
          ), pp.
          <fpage>135</fpage>
          -
          <lpage>160</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Henderson-Sellers</surname>
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Process Metamodelling and Process Construction: Examples Using the OPEN Process Framework (OPF)</article-title>
          .
          <source>Annals Software Engin</source>
          .
          <volume>14</volume>
          , pp.
          <fpage>341</fpage>
          -
          <lpage>362</lpage>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6. OMG: Software Process Engineering Metamodel Specification, version
          <volume>1</volume>
          .1. formal/05-01-
          <fpage>06</fpage>
          . Object Management Group,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Ralyté</surname>
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rolland</surname>
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>An Assembly Process Model for Method Engineering</article-title>
          . CAISE'
          <volume>01</volume>
          ,
          <string-name>
            <surname>Proceedings</surname>
          </string-name>
          ,
          <source>LNCS 2068</source>
          , Springer-Verlag, pp.
          <fpage>267</fpage>
          -
          <lpage>283</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Ralyté</surname>
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Deneckère</surname>
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rolland</surname>
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Towards a Generic Method for Situational Method Engineering</article-title>
          . CAiSE'
          <volume>03</volume>
          ,
          <string-name>
            <surname>Proc</surname>
            <given-names>.</given-names>
          </string-name>
          , Springer, LNCS
          <volume>2681</volume>
          , pp.
          <fpage>95</fpage>
          -
          <lpage>110</lpage>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <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 Modelling</article-title>
          , Requirements Engineering J.
          <volume>4</volume>
          (
          <issue>4</issue>
          ), pp.
          <fpage>169</fpage>
          -
          <lpage>187</lpage>
          ,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Saeki</surname>
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique</article-title>
          .
          <source>CAiSE'03, Proceedings, LNCS 2681</source>
          , Springer, pp.
          <fpage>374</fpage>
          -
          <lpage>389</lpage>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>van de Weerd</surname>
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brinkkemper</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Souer</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Versendaal</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>A Situational Implementation Method for Web-based Content Management System-applications: Method Engineering and Validation in Practice</article-title>
          .
          <source>Software Process: Improvement and Practice</source>
          <volume>11</volume>
          (
          <issue>5</issue>
          ),
          <fpage>521</fpage>
          -
          <lpage>538</lpage>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>