how to choose right agent oriented methodology

1. How to Choose the Right Methodology for Agent-
based Systems
Ehsan Alirezaei
Tehran, Iran
ehsan_alirezaii@ut.ac.ir
Ahamd Abdollahzadeh Barfourosh
Amirkabir University, AIS lab
Tehran, Iran
ahmad@aut.ac.ir
Abstract-Today many Agent Oriented Methodologies have been
introduced. Choosing the right methodology is a hard job to do.
For evaluate the effectiveness of introduced methodologies,
there is need to quantitatively assessment framework and
techniques. Assessment framework in this paper will show any
part of methodology with measurements. Based on proposed
framework, the guideline presented for choosing the right
methodology. In the new frame, benchmarks have six issues:
Definition (concept), Feasibility (pragmatic), Modeling
language, Process, Tool and Support criteria. In the benchmark
has been showed effect of the metrics and evaluation on
choosing the right methodology base on project characteristics.
For evaluation it is considered nine methodologies: ADELFE
and ASPECS as mature, ROADMAP, MASE and GAIA as
general-purpose, INGENIAS, PASSI, PROMETHEUS as
suitable for short time delivery projects and TROPOS with
strong Requirement Engineering basis. All measurements are by
checklists that created by study of software industry.
Keywords-Methodology
I. INTRODUCTION
Agent Oriented Software Engineering (AOSE)
methodologies as guidelines supported with tools are of
interest to developers and researchers in developing agent-
based systems. Each methodology has methods and processes,
which will determine its application in certain areas [1]. There
is a gap for agent-oriented methodologies in theory and
industrial use; there are many well-defined methodologies in
theory and examples but software companies do not using
them. Cause of this problem is: AO methodologies processes
due to being newer than Object-Oriented methodologies are
not complete as Capability Maturity Model (CMM) levels.
For filling the gap, it is helpful using guideline for choosing
right methodology. It seems that the use of a specific
methodology for solving problems affects on producing the
desired AO system. Some methodologies are appropriate for
special projects, so for each project characterization needs
appropriate methodology fragments for creating suitable
methodology for organization. Evaluating methodologies is
helpful for two main works: first for choosing the right
methodology by providing guidelines and second selecting
suitable method fragment to creating new project-specific
methodology.
Using disproportionate frameworks for methodology
evaluation, such as using object-oriented assumptions, can
lead to problems such as inability to express the agent-
oriented concepts, Therefore new framework must includes
agent concepts. Based on our new frame users can consider
which methodology is appropriate for the AO system
categories. Proposed methodologies in this paper have been
selected from those that have enough details in papers and
well known in the community of Software Engineering.
Proposed methodologies are: MASE [2], GAIA [3], TROPOS
[4], ADELFE [5], INGENIAS [6], PASSI [7],
PROMETHEUS [8], ROADMAP [9] and ASPECS [10].
In the second part, proposed methodologies and their
specifications, aspects of language, notations, and the process
have been introduced. In the third section, new framework and
result of evaluation base on frame are presented. In the fourth
part of paper, guideline for choosing the right methodology
base on evaluation is mentioned; finally in the fifth section,
conclusion and future works are presented.
II. METHODOLOGIES
In this section some of agent-oriented methodologies that
are presented based on four layers: A quality focus, Process,
Method and Tool [11]. Methodology quality focus comes
from functional and non-functional requirement management
aspects. All methodologies have processes for achieving the
quality focus, that these processes in practice must show their
strengths. In each process, methodologies are defined many
methods to achieving the quality goal with support of tool.
Definitions presented in these four layers for each
methodology. These nine methodologies have been selected
because they are well known and accepted in AOSE society
with introduced many examples and papers.
Agent oriented methodologies have differences in given
aspects such as process, process model, life cycle, supporting
tools and characteristics. Some latest methodologies
considered in this paper like (ASPECS from PASSI),
(ROADMAP from GAIA) have new processes or many
change, so they are categorized in separate methodology not
as extension.
Selected methodologies have differences in the quality
focus. MASE and TROPOS are using requirement
engineering and goals for achieving system quality. GAIA,
ASPECS and ROADMAP are using organizational aspects to
achieving quality. Some of methodologies need extension for
achieving quality in implementation.
Some of methodologies like GAIA, MASE,
PROMETHEUS and ROADMAP are using waterfall process
model with support of some phases of lifecycle. Other

2. methodologies like ASPECS, ADELFE, INGENIAS and
PASSI are using iterative process model. TROPOS has
proposed evolutionary process model. In lifecycle phases each
methodology had guideline for achieving artifacts (method).
Each method affect on final quality and some of them are
supporting by tools. Some of Methodologies for achieving the
system quality proposed tools and modeling language. E.g.
INGENIAS are using INGENIAS Development Kit (IDK)[6]
for modeling and JADE [12] for implementing systems.
Methodologies have differences based on the time they are
introduced, changes in their definitions and characteristics.
Today agent specifications are complete and there are
methodologies that cover some aspects of lifecycle and agents
concepts, but it is a long way to introduce mature
methodology. In the first step to find what to do there is need
to new frame for founding effectiveness of methodologies
quantitatively.
III. ASSESSMENT FRAMEWORK AND METHODOLOGIES
EVALUATION
All aspects of quantitative evaluation and adoption for
methodologies assessment are presented in this section. In the
second subsection new assessment framework is presented
and there is a study about it. In the last subsection evaluation
results are presented with nine methodologies based on new
frame and quantitative approach.
A. Quantitative assessment
Researchers presented many standard frameworks for
evaluating different methodologies, e.g. DESMET [13].
DESMET method introduced quantitative approach, so in our
new frame we adopted its ranking table for evaluating
methodologies. New method uses values from 0 to 5 for
mapping quality assessment to quantitative evaluation as is
shown below:
• The feature is not supported nor referred in
methodology document is equal to Zero (No
support).
• Indirectly support of some features is equal to One
(Low support).
• Properties listed in the document supported and
mentioned with tools but does not support some
aspects is equal to Two (Support some aspects).
• All aspects mentioned are supported with tools
but experience of user is important is equal to
Three (Strong support).
• All aspects are fully supported with tools is equal
to Four (Very strong support).
• In addition to full support with tools there is aided
scenarios is equal to Five (Full support).
For creating mature framework for AOSE methodologies
and identifying characteristics of framework we used the
context of methodologies and other evaluation frameworks by
researchers [14,15,16]. The aim of this assessment framework
is to creating quantitative measurement for methodologies.
Prior frameworks had qualitative assessment to methodologies
or some of them had some of features that specify in this
framework, so this frame is complement to other and
quantitative. In some cases in new frame answering questions
is only possible with Yes/No, because of the nature of a
features that is not quantifiable.
B. Assessment framework
Presented framework in this paper is based on agent
oriented methodologies specifications and it is an evolution of
introduced frameworks in other papers [14-19]. A problem
that we try to cover in new frame is that researchers
assessment frameworks are limited to some aspects of
qualification evaluation. Another problem that has been tried
to cover is supporting evaluation with guideline to choose
right methodology. Presented assessment framework in Fig. 1
includes the concept, modeling language, process, pragmatic,
support aspects and development tools. In addition to the
above issues, each part has a subsection, which all questions
related to topic is categorized based on their specification.
Each part of the framework has some aspects, in concepts
we checked properties like autonomy, re-activeness, social
ability, pro-activeness and other features. Furthermore there
must be some test on methodology for factors such as belief,
desire, intention, message, norm, organizations, protocol, role,
service, community, and etc. For each subsection of existing
aspects in framework there are questions that must be
answered to have the right evaluation. Each aspect with its
questions is available in a checklist with references to three
parts: developers of methodology, other research assessment,
and our assessment. Presented final evaluation is based on
reviews on this three assessment in checklists.
Comparison of agent oriented concepts based on Fig.1,
needs to propose questions about features like: architecture
independency, consistency, autonomy, reactivity, pro-activity,
interaction language, and intention. In comparison modeling
language needs to propose questions about features like
representation type, Meta model, relation among models and
their dependency, notation evaluation, environment support,
concurrency, transparency, modularity, and methodology
extendibility.
Figure 1. Assessment Framework
In the process section some features are considered like
process model, covering the lifecycle, development methods
and context, application domain, the basic element of models,

3. development approach (Object Oriented, Knowledge
Engineering, Requirement Engineering), and guidelines. For
assessment of lifecycle we categorized it into seven phases as
requirement elicitation, requirements analysis, architecture
design, detail design, implementation, verification and test,
and deployment. The cause of this classification is the support
volume and guidance that is provided by a methodology in
each part difference and should be carefully investigated.
In comparison to pragmatism, methodologies should have
features like no ambiguity, accuracy, consistency, notation
simplicity, model refinement ability, documentation,
suitability architecture language, samples, applicative in
domain, and models expressively. The other section presents:
supported aspects, features like support of open systems,
security, support of ontology, organization, dynamic
organization, knowledge modeling, and scalability. Some
assumptions like knowledge modeling are not part of agent-
oriented methodologies, but support of them can show
strength of the target methodology.
Development tools for methodologies are categorized in
modeling tools and implementation tools. Having tool is
strength for methodology; also it is important to the designer
and developer. Some aspects in tools are important like code
generation from design, testing ability, platform
independency, and support agent concepts.
C. Comparison of methodologies
The cause for selecting these nine methodologies for
comparison is that they have features such as supporting tools,
many different researches, or available standard language for
them. We tried choosing methodologies from the different
time intervals that targeted methodologies had many citations.
In comparing the methodologies also we look at previous
evaluation that have been performed in this field [14-19]. All
evaluations are provided with comparison tables for the
proposed framework. In contrast of this paper, some of tables
are presented in these sub sections.
1) Process aspect evaluation
The process and life cycle comparison are presented in
[20]. According to this comparison, we can say methodologies
like MASE and GAIA are using waterfall process model and
there are other methodologies that make use of iterative and
evolutionary process model that it affects their uses on
projects and organizations. In requirement elicitation phase,
TROPOS and ADELFE are better in comparison feature with
the other methodologies and it is due to the use of I*
framework. In requirements analysis and architecture design
phases there are good guidelines and supports with tools for
all methodologies but GAIA, INGENIAS, and PASSI just
support some aspects of requirement analysis. In the detail
design GAIA and ROADMAP only support some aspects and
are weaker than others, although there is extension of GAIA
(ex-GAIA) that it is trying to cover this weakness [21]. These
two methodologies finish their works in detail design. In
implementation phase there are tools for supporting the
methodology guidelines except for ADELFE, in this phase
experience of developers is important for using methodologies
guidelines. ROADMAP and ASPECS are the two
methodologies that strongly support verification and
validation phase, but MASE only supports requirements
validation. Support of deployment is another feature in table
and considered phases that provided by three methodologies
in some aspects. All mentioned methodologies have Object-
Oriented (OO) base and Requirement Engineering (RE)
affects some of them. ROADMAP and GAIA does not have
any guidance for the reusability, while ADELFE and ASPECS
have strong reusability criteria based on their metamodel.
2) Agent concepts coverage evaluation
As shown in [20], in contrast to the concepts associated
with the implementation of Multi-Agent Systems, we can say
that all the methodologies in this field have documentations
and guidelines. In autonomy all methodologies have enough
attention to support of tools. GAIA has low support of mental
aspects while TROPOS supports this aspect very strongly.
ADELFE and MASE have very strong supporting for the
concurrency. For adaptive systems ADELFE has the best
solutions and the aim of its development is to support the
adaptive agent-based systems. GAIA and ROADMAP don’t
have any guidelines for communication language and
communicability. In order to face with transient conditions
and dealing with failures, ADELFE is operating accurately. In
comparing the methodology Intentions (purposes), those
methodologies that have lower ranks, like MASE, they can be
used for broad categories of projects and other that have
higher ranks are suitable for special-purposes; like ADELFE
that is suitable for adaptive systems, but methodology
projects-independency (suitability for broad category of
projects/organizations) does not mean that they are general
purpose. Reactivity is the aspect that has been mentioned in
all methodologies but ASPECS has scenarios for it so it is has
strong support for it. Pro-activity shows the importance of
goals in methodology, as you can see in methodologies like
PASSI, in which the goals are not as important as the goals in
TROPOS. Other aspects can be considered in [20].
3) Methodologies pragmatism evaluation
As shown in Table I, Methodologies that are older than
others have better situation in pragmatism. The reason is that,
these methodologies are equipped with more documentation
and examples. GAIA and ROADMAP are so weak for
covering pragmatism aspects. All methodologies have been
good in terms of not being ambiguous. PASSI and ASPECS
are very strong in this term. In refining aspect, TROPOS,
ADELFE, and INGENIAS have very strong support. There is
much documentation for older methodologies, because of
those new methodologies such as ASPECS, which have low
rating. In number of examples, most methodologies do not
provide a lot of work, or those have examples are not
accessible. All in all, in comparing pragmatism we can say
MASE, TROPOS, INGENIAS and ADELFE have good
support of aspects provided in table I.

4. Table I. Methodologies pragmatism Evaluation
Feature
Methodology
Unambiguity
Precisely
Expressiveness
Consistency
Notationsimplicity
Refinement
Documentation
Examples
MASE 2 2 2 3 3 1 4 4
GAIA 2 2 1 1 1 0 4 0
TROPOS 2 2 2 3 2 4 4 2
ADELFE 1 3 3 5 2 4 3 1
INGENIAS 3 1 2 2 4 4 2 1
PASSI 4 2 3 2 3 2 2 1
PROMETHEUS 2 3 3 2 2 2 3 3
ROADMAP 3 2 2 1 2 0 2 0
ASPECS 4 3 3 1 2 1 1 0
4) Modeling language evaluation
Cause the nature of questions for aspects in Modeling
Language; questions could answers by Yes/No. Features like
modularity and type of representations are supported by all
methodologies. Designing models in languages in different
phases are independent for four methodologies as you can
consider in table. GAIA has no support for transparency.
MASE methodology does not support concurrency in
modeling language, also it does not have Meta model.
Considering environment aspects and interaction with that is
another comparison feature, and it has not been supported in
MASE and PASSI and another four methodologies as
presented in table are supporting work and interact in dynamic
environments. MASE in modeling language has weaker
support in comparison with other methodologies and ASPECS
due to its features like: independency between models,
multiple abstraction layers for enterprise hierarchy, and agent
decomposition ability has good modeling language coverage.
5) Tools evaluation
In this section we only presented development tools
assessment table. For modeling tools, methodologies have
dealt with one or more tools. According to documentation of
ASPECS, it is using UML language and it doesn't have
specific tool yet. There is a new tool for GAIA, called
GAIA4E [22], that its representation is formal and still does
not have any guidelines for some features. There is a strong
tool for supporting ADELFE with all features, named
OpenTool. In Table II, development tools are presented for
methodologies. Methodologies with star above them have
guidelines for specific Tool and there are not developed
specifically for that those methodologies. The Tool that is
called BOGOR doesn't have IDE for programming; instead, it
provides an environment for concurrent processes. In
comparing programming tools, there is JACK [23] and JADE
tools, which are java base and are common with using
intelligent agents. Downloading and using of JADE is free but
for using JACK must be paid. JANUS is a new tool that is
specifically for ASPECS methodology. There is no
implementation tool for ADELFE.
6) Comparison of support Aspects
According to Table III, for support aspects, ASPECS
methodology provides full support with initial features in its
workflow and lowest support belongs to PROMETHEUS
methodology. These three methodologies, MASE, PASSI, and
ASPECS, have support for ontology from the base and with
ontology it is possible to model domains. Only ASPECS has
support for organization dynamics and change of organization
in different situations. All methodologies are scalable and
security support in definition is available for MASE,
TROPOS, ADELFE, and ASPECS.
Table III. Comparison of support aspects
Support aspects
Methodology
Open
systems
Security
Scalability
Ontology
Organization
Dynamic
Organization
Knowledge
Model
MASE No Yes Yes Yes Yes No Yes
GAIA Yes No Yes No No No Yes
TROPOS No Yes Yes No No No No
ADELFE Yes Yes Yes No No No No
INGENIAS No No Yes No No No Yes
PASSI No No Yes Yes Yes No Yes
PROMETHEUS No No Yes No No No No
ROADMAP Yes No Yes No Yes No Yes
ASPECS Yes Yes Yes Yes Yes Yes Yes
Table II. Implementaion Tools Assessment
Tool
name
Methodology Tool specification
BOGOR MASE Environment model, controlling
JACK TROPOS,
PROMETHUS*
Platform independency,
Environment model, controlling,
debugging, special systems
JADE MASE*, GAIA*,
INGENIAS,
PASSI*,
ROADMAP*
Platform independency,
Environment model, controlling,
debugging, special systems, free
JANUS ASPECS Platform independency,
Environment model, controlling,
debugging

5. IV. GUIDELINE FOR CHOOSING THE RIGHT METHODOLOGY
In the following lines, there is need to clarify how
evaluation result can be used to reach guideline. Agent
oriented approaches represent software engineering concepts
for solving industrial complicated problems. Considering this
fact, it is quite obvious that the role of agent-oriented
methodologies is important. In the last step by applying the
evaluation results, we try to have guidelines for choosing the
right methodology.
Software engineering projects also agent-oriented projects
are categorizing based on their size, cost, and type. Some
methodologies have better guidelines for specific category of
projects and organizations, there is needed to specify a matrix
for both projects and methodologies for selecting and ease of
use. Project size is measured in overall investment and agent
numbers estimation [24,25]. For increasing the size of the
projects, numbers of stakeholders grow up from 1 to n. The
system complexity is growing for agents and stakeholders
communication and interaction increment. In AOSE, the aim
of the methodologies is to dealing with medium to high
complexities, that there is different number of people involved
in the project and geographical or cultural distribution affects
on project communications. Choosing right methodology is
the responsibility of Project management office (PMO). In the
table IV, guideline is presented for choosing the methodology
that using agent-oriented approaches.
According to mentioned assessment and Table IV. MASE
methodology covers all life cycle stages. MASE is suitable for
enhancement to medium-scale closed systems, due to its
waterfall process model and specification of MASE that acts
in closed systems it is efficient for projects that have medium.
GAIA does not cover the entire life cycle, it moves
forward till the architecture design phase. This methodology is
suitable for developing enhancement to small projects in both
project types that have low risk in close environments. Ex-
GAIA is efficient in developing open systems till medium or
large scale.
TROPOS covers life cycle till implementation phase and
has strong support of requirement engineering phase this
methodology is effective in developing open and complex
systems.
ADELFE covers life cycle methodology till
implementation and has strong support of requirement
engineering. This methodology is for developing adaptive
systems that they deal with changing environment and agent
must cooperate to achieve new goals in this environment.
INGENIAS covers analysis, design and implementation
phases. It is applicative in all domains and can be used for
variety of projects sizes. But since there is no guideline in
requirement elicitation, it is suitable for projects low risk.
PASSI covers all life cycle phases except the requirement
phases. It is a methodology for closed and small systems and
Table IV. Guideline for uses of methodologies according categories of projects (Business-B, Information Technology-IT)
Methodology Project risk Project size and
system type
Description
MASE Low or medium Enhancement to medium
(B, IT)
Waterfall process model, applicable to closed systems, prototyping
can be used, change management maybe required
GAIA Low or medium Enhancement to medium
(IT, social)
Waterfall process model, applicable to closed and open systems,
prototyping can be used, short time delivery
TROPOS Medium to high Medium to very large
(B, IT)
Evolutionary process model, applicable to open systems, governance
important, focuses on business value
ADELFE High Large to very large
(Adaptive)
Iterative/incremental process model, applicable to open systems,
crucial systems, change management very important, customer
involvement is high
INGENIAS Low or medium Enhancement to large
(B, IT)
Iterative/incremental process model, applicable to closed systems,
artifacts are important, project time frame about 6 month
PASSI Low Enhancement to small
(IT)
Iterative process model, applicable to closed systems, also Agile
PASSI available, prototyping can be used, short time delivery
PROMETHEUS Medium or low Enhancement to small
(academic, B, IT)
Waterfall process model, applicable to closed systems, deliver in
short time, requirement not change
ROADMAP Medium or low Small to large (IT,
social)
Waterfall process model, applicable to open systems, requirement not
change, governance involvement
ASPECS Medium to high Large and very large (B,
IT)
Iterative process model, applicable to open systems, inter-team
communications, governance overhead, challenging and failing risks
available

6. there is agile PASSI too. It is suitable for low risk systems that
have few changes in future.
PROMETHEUS attempted to cover life cycle but it does
not support deployment phase. It is suitable for those people
with no previous experience like student and academic users.
It is also applicable in small size industry.
ROADMAP covers life cycle till detailed design phase. It
supports knowledge modeling so that it is a good point. This
methodology is suitable in social open systems for variety of
sizes from small to large because mentioned specifications in
evaluation.
ASPECS covers life cycle phases completely. It is one of
strong methodologies that some of its remarkable points come
from other methodologies like PASSI. It is recommended for
complex open systems in large scales.
All methodologies that are applicable to open systems are
applicable to closed systems and environment too. FIPA made
efforts for methodologies standardization, for instance we can
mention some output of FIPA like Agent Communication
Language (ACL) and ASPECS methodology.
V. CONCLUSION
In this paper we have reviewed nine AOSE methodologies,
then we presented a quantitative evaluation framework that
can be used in other assessment researches for AOSE
methodologies. In thirds section, we evaluated methodologies
for illuminating their strengths and weaknesses. Based on the
evaluation result, we had a conclusion and proposal guideline
for choosing the right methodology on specific domain and
projects categorizes based on their sizes. it cannot be
recommend a specific methodology for specific project and
problem; hence there is need a methodology that complies
with the terms of that problem. So researches embark on
introducing unified methodology or using method
engineering. In methods engineering instead of selecting an
appropriate methodology, methodology is designed by
methods that developed and extracted from current
methodologies. In future works we are going to propose new
framework for engineering new methodology from current
methodologies based on current assessment, and proposal an
fast way to fragment extraction and choosing methodologies.
We are also working on decreasing the cost of method
engineering for global use with introducing unified method
engineering language.
REFERENCES
[1] C. Ghezzi, M. Jazayeri, D. Mandrioli, “Fundamentals of software
engineering”, Upper Saddle River, N.J: Prentice Hall, 2th
edition
2002.
[2] S. A. DeLoach,"Analysis and Design using MaSE and agentTool
", Midwest Artificial Intelligence and Cognitive Science
Conference, 2001.
[3] M. Wooldridge, N. R. Jennings, D. Kinny, "The Gaia
Methodology for Agent-Oriented Analysis and Design",
Autonomous Agents and Multi-agent Systems - AAMAS , vol. 3,
no. 3, pp. 285-312, 2000.
[4] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, J.
Mylopoulos,"Tropos: An Agent-Oriented Software Development
Methodology ",Autonomous Agents and Multi-agent Systems -
AAMAS , vol. 8, no. 3, pp. 203-236, 2004.
[5] C. Bernon, M. P. Gleizes, S. Peyruqueou, and G. Picard,
"ADELFE: A Methodology for Adaptive Multi-agent Systems
Engineering," Engineering Societies in the Agent World - ESAW,
2002.
[6] J. Pavón, J. J. Gómez-sanz,"Agent Oriented Software
Engineering with INGENIAS", International Workshop of
Central and Eastern Europe on Multi-Agent Systems - CEEMAS ,
pp. 394-403, 2003.
[7] M. Cossentino, and C. Potts. "PASSI: a Process for Specifying
and Implementing Multi-Agent Systems Using UML." 2002.
[8] L. Padgham, M. Winikoff, "Prometheus: a methodology for
developing intelligent agents ", Autonomous Agents &Multiagent
Systems/Agent Theories, Architectures, and Languages - ATAL ,
pp. 37-38, 2002.
[9] T. Juan, A. R. Pearce, L. Sterling,"ROADMAP: extending the
gaia methodology for complex open systems ", Autonomous
Agents &Multiagent Systems/Agent Theories, Architectures, and
Languages - ATAL , pp. 3-10, 2002.
[10] M. Cossentino, N. Gaud, V. Hilaire, S. Galland, and A. Koukam,
"ASPECS: an Agent-oriented Software Process for Engineering
Complex Systems," Autonomous Agents and Multi-agent
Systems, Vol. 20, No. 2, pp.260-304, 2010.
[11] R. S. Pressman, “Software engineering: A Practitioner’s
Approach” , Mc Graw Hill, 7th
edition, 2010.
[12] F. Bellifemine, A. Poggi, and G. Rimassa, “Developing Multi-
agent Systems with JADE “,springer 2000
[13] B. Kitchenham. DESMET: a method for evaluating software
engineering methodsand tools. Technical Report TR96-09,
University of Keele, U. K. , 1996.
[14] D. Isern, D. Sánchez, A. Moreno, Organizational structures
supported by agent-oriented methodologies, Journal of Systems
and Software 84(2):169-184 (2011)
[15] K. H. Dam, M. Winikoff: Evaluating an Agent-Oriented
Approach for Change Propagation. AOSE 2008: 159-172
[16] F. Bergenti, M.Gleizes, F. Zambonelli, METHODOLOGIES
AND SOFTWARE ENGINEERING FOR AGENT SYSTEMS
The Agent-Oriented Software Engineering Handbook,Springer,
Jun 30, 2004
[17] A. Sturm and O. Shehory, "A Framework for Evaluating Agent-
Oriented Methodologies,"Agent-Oriented Information Systems,
2003.
[18] Ingrid Nunes, Elder Cirilo, Carlos José Pereira de Lucena, Jan
Sudeikat, Christian Hahn, Jorge J. Gómez-Sanz: A Survey on the
Implementation of Agent Oriented Specifications. AOSE 2009:
169-179
[19] A. Susi, Anna Perini, John Mylopoulos, PaoloGiorgini: The
Tropos Metamodel and its Use. Informatica (Slovenia) 29(4):
401-408 (2005)
[20] E. Alirezaei and A. A. Barfroosh,” Evaluation of Agent Oriented
Methodologies”, 4th
IKT , 2012.
[21] P. Jain, D. Dahiya: Knowledge Management System Design
using Extended Gaia. CoRR abs/1102.2114: (2011)
[22] Luca Cernuzzi, Franco Zambonelli: Gaia4E: A Tool Supporting
the Design of MAS using Gaia. ICEIS (4) 2009: 82-88
[23] M. Winikoff: JACK™ Intelligent Agents: An Industrial Strength
Platform. Multi-Agent Programming 2005: 175-193
[24] Project classification for requirements, software education
requirement methodology pack, published by cutter consortium,
January 2008. Note in: www.softed.com
[25] S. Helber and K. Henken :Profit-oriented shift scheduling of

7. inbound contact centers with skills-based routing, impatient
customers, and retrials , 2007.