![](bg4.png)
engineers having a low degree of expertise in the
scenario conceptualization. By using this simpler
map, the engineer has fewer variants to take into
account and the further guidance is easier.
Path Selection. There is a possibility to choose a
path, directly from the beginning of the process. For
instance, the Duration criteria will help to obtain a
specific method line which is the quickest to
perform. The time factor will help to choose the
following path as the chosen method line.
P
Start-Stop
=S1.S5.S14
Choosing this guidance, the engineer executes
the method line which corresponds to the lowest
duration. He does not have a possibility to change
the used method components during the execution.
Atomic Step Selection. This technique helps to
keep the intentional nature and all the powerfulness
of the map model. For instance, the navigation
through the Map leads the engineer to execute, at his
satisfaction, the section S2 (which helps him to elicit
a goal with a case-based strategy). Four possibilities
are offered to the engineer to go further in the
process. He may execute the section which has the
same target intention (S2) or go further in the Map
to the intention Write a Scenario (S3, S4), or even
go directly to Conceptualize a scenario (S5). As the
intention ‘Elicit a Goal’ is fully satisfied, the
indicator ‘Goal Achievement degree’ will guide him
to suppress the first possibility. He then chooses to
use three other criteria to customize his guidance,
namely Duration, Expertise degree and Formality
degree. These three indicators are quantitative and
have different measure scales. In order to obtain the
compatible scales for comparing them, the
normalization must be applied. The normalized values
are presented in the Table 2.
Table 2: Normalized Indicator Values.
Section Expertise Degree Duration Formality
degree
Aggregated
Value
S3 0,5 1 0,33 0,61
S4 1 0,66 1 0,89
S5 0,5 1 1 0,83
The aggregated value of the indicators guides
him to choose the section S3. That means that, the
selected section requires the lowest expertise and
formality degree and the lowest duration.
4 CONCLUSIONS AND FUTURE
WORKS
We introduce the notion of variability in method
family. Method families bring together a set of
different components having the same main usage to
facilitate their reuse and adaptation. We use the
MAP intentional formalism to represent method
families as a set of method component features and
use variability through four types of feature
relationships
. Once the method family has been
expressed with maps, the task of selecting the
adapted method line is done by deciding which
combinations of features are the most suited to the
situation at hand, following criteria and several
selection techniques.
Our future work consists of adapting the Map-
editor tool and combining it with the Map-executor
tool currently on development. This tool will support
navigation in a map to select dynamically the feature
most appropriate to the situation at hand.
REFERENCES
Deneckere, R. and Kornyshova, E., 2010. Process line
configuration: an indicator-based Guidance of the
Intentional Model MAP. EMMSAD’10, Hammamet,
Tunisia.
Maiden, N. A. M., 1998. CREWS-SAVRE: Scenarios for
Acquiring and Validating Requirements. Journal of
Automated Software Engineering.
Ralyte, J. and Rolland, C., 2001. An assembly process
model for method engineering. CAISE’01, Interlaken,
Switzerland.
Rolland, C., Souveyet, C. and Ben Achour, C., 1998.
Guiding Goal Modelling Using Scenarios. IEEE Tran-
sactions on Software Engineering, special issue on
Scenario Management, Vol.24, No.12, pp 1055-1071
Rolland, C., 2007. Capturing system intentionality with
maps. In the book Conceptual Modelling in
Information Systems Engineering, J. Krogstie, A. Op-
dahl, S, Brinkkemper (Eds.).
Rolland, C., 2010. Method engineering: trends and
challenges. RCIS’10, Invited Talk.
Roy, B., 1996. Multicriteria Methodology for Decision
Aiding. Dordrecht, Kluwer Academic Publishers
Santos, E., Pimentel, J., Castro, J., Sanchez, J., Pastor, O.,
2010. Configuring the Variability of Business Process
Models Using Non-Functional Requirements.
EMMSAD’10, Hammamet, Tunisia.
Svahnberg et al., 2001. On the notion of variability in
Software Product Lines. Proceedings of the Working
IEEE/IFIP Conference on Software architecture.
Taylor, C., 1964. The Explanation of Behaviour. London:
Routledge.
Van Gurp, J., 2000. Variability in Software Systems, the
key to Software Reuse. Licentiate Thesis, University
of Groningen, Sweden.
Van Slooten, K., and Hodes, B., 1996. Characterising IS
development projects. IFIP WG8.1 Conference on
Method Engineering.
METHOD FAMILY DESCRIPTION AND CONFIGURATION
387