INGENIAS-SCRUM Development Process for Multi ... - Semantic Scholar

INGENIAS-SCRUM Development Process for Multi-Agent Development Iván Garc´ıa-Magari˜ no1 , Alma Gómez-Rodr´ıguez2 , Jorge Gómez-Sanz1 , and Juan C. González-Moreno2 1 2

Universidad Complutense de Madrid ivan gmg,[email protected] Universidade de Vigo alma,[email protected]

Summary. One of the key issues in development of Multi-agent System(MAS) is to follow the more suitable development process for a particular problem. This means that development process models must be defined. Definition leads to better process understanding, facilitates process measurement and improvement, and constitutes the basis for automating the process itself. The main goal of this paper is the definition of a process for agent-based development. This definition is based on the Software Process Engineering Metamodel(SPEM) and applied in the definition of the software engineering process of INGENIAS MAS methodology following a SCRUM approach.

1 INTRODUCTION Some authors [3, 4], indicate that the modeling of processes for agent-based development is an increasing demand due to many reasons. Some of the Agentoriented Software Engineering(AOSE) methodologies [15, 5, 2, 14] may be followed using different process models depending on the system to be constructed. In these cases, the anticipated definition of the process, by means of its modeling, is very useful. Besides, the process models can be shared among Multi-agent System (MAS) designers, facilitating to inexperienced designers the process models defined by experienced ones. Moreover, defining the process models provide the basis for automating the process itself, in the same way as it is done in other engineering fields, and opens the possibility of adapting CASE tools for a particular process within a methodology. This paper focuses on the definition of a process model for agent-based development. When addressing this issue several perspectives can be followed: some methodologies define a unique process of development, while others may follow different processes depending on the system, the team, etc. This paper incorporates this latest approach, applying a particular process to a well defined methodology. In fact, the main aim of this work is to define a process of development for Multiagent Systems following a particular methodology

2

I. Garc´ıa-Magari˜ no, A. G´ omez-Rguez, J. G´ omez-Sanz, J.C. Glez-Moreno

(INGENIAS) and approaching the process within the SCRUM philosophy of management in mind. The definition of processes is made easier using an editor which allows designers to create the suitable diagrams and definitions in an automated manner. In the last two years, an important number of tools have been proposed to model and specify Software Development Process [1, 6, 4, 8], most of them based on the SPEM standard. The structure of the remaining of the paper follows. Next two sections introduce briefly the SCRUM process of management and INGENIAS methodology of development. Section 4 provides a detailed definition of INGENIASSCRUM process, introducing several subsection where details about the lifecycle, the disciplines, etc. are explained. Finally, Section 5 presents the conclusions and future work.

2 SCRUM A SCRUM is a mechanism in the sport of rugby for getting an out-of-play ball back into play. The term was adopted in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi to describe hyper-productive development. Ken Schwaber formalized the process in the first published paper on SCRUM at OOPSLA 1995 [18]. As pointed in [17], SCRUM is an empirical Agile project management framework which is used to iteratively deliver to the customer software increments of high value. It is a simple framework used to organize teams and get work done more productively with higher quality. SCRUM relies on self organizing, empowered teams to deliver the product increments. It also relies on a customer, the Product Owner, which provides the development team with a list of desired features using business value as the mechanism for prioritization. From the previous paragraphs it must be clear that SCRUM is a model for management of the process of software development. It is not a methodology, but a framework which can fit with several methodologies. The SCRUM process is particularly suitable for Knowledge Engineering Developments based on the use of Multi-Agent Systems, because of the agile development and the user implication.

3 INGENIAS METHODOLOGY INGENIAS methodology covers analysis and design of MAS, and it is intended for general use, with no restrictions on application domain [16, 11, 12]. It is based on UML diagrams and process (RUP), trying in this way to facilitate its use and apprenticeship. New models are added and the UML ones are enriched to introduced agent and organizational concepts. At the moment the metamodels proposed cover the whole life cycle and capture different views of

INGENIAS-SCRUM Development Process for Multi-Agent Development

3

the system. In the latest years, INGENIAS Metamodels have demonstrated their capability and maturity, as supporting specification for the development of Multiagent Systems [16, 15]. Recently the INGENIAS Agent Framework (IAF) has been proposed taking into account the experience in application of INGENIAS methodology during several years enabling a full model driven development. This means that, following the guidelines of the IAF, an experienced developer can focus most of its effort in specifying the system, converting a great deal of the implementation in a matter of transforming automatically the specification into code. A MAS, in IAF, is constructed over the JADE platform. It can be distributed along one or several containers in one or many computers. To enable this feature, the IAF has means of declaring different deployment configurations.

4 SCRUM FOR INGENIAS METHODOLOGY In [3] the need of process models for agent-based development has been established. After this work, many others have modeled different kinds of processes within a well known methodology. In this paper processes and methodologies are thought to be in two orthogonal dimensions that can be merged or interchanged during the life cycle of a MAS development process. This could be done if development resources and deliverables are previously defined and modeled into a well known process or if, a new process is created to match the necessity of the development team for fulfilling the user requirements. In this section, the guidelines used in [8] to specify and define a process model are followed for adapting the SCRUM Development Process within the INGENIAS Methodology. Moreover, SCRUM-INGENIAS process has proved his utility, because it has been used for developing a MAS system, based on delphi process for document relevance evaluation [7]. In the latest years an important number of tools for modeling and specifying Software Development Processes have been proposed. Most of them are based on the SPEM standard, for instance Eclipse Process Framework (EPF) [6]. As part of the EPF documentation, two possible development processes are described: OpenUp and SCRUM. Moreover, in the EPF Composer Overview, authors propose as an example of the EPF capabilities, the model of a new process obtained by reusing several activities defined for OpenUp into a SCRUM process skeleton. On the other hand, in [3, 13] the approach is to find a set of common activities for different Agent Oriented Software Engineering Methodologies (AOSEM). The objective, in this case, is to reuse those activities across real Multi-Agent Software Development Life Cycle Processes. In this paper, process activities can not be shared across different development processes in AOSEM because the intended meaning may be different and those activities may use different resources (human, software and hardware). Nevertheless, different processes for the same methodology which use

4


the same resources can be used. This section addresses this goal; that is, to show how an agile project management technique, such as SCRUM, can be used within a methodology like INGENIAS, whose development process nature is basically those of the Rational original Unified Process Development (UPD) and which has been recently mapped to the OpenUP process (see [9]). When trying to map a well established methodology/process into a new process, it is necessary to define the steps to be done for obtaining the desired result. In [9]several steps that must be followed in the definition of a new development process models for AOSEM are defined, adopting SPEM as model specification. These steps are: 1. Identify the process model with an existent process model if possible, if not define from zero the new one taking as basis the next steps. 2. Define the lifecycle view. Identify the phases, iterations and sequence of application. This step is essentially a temporal step in which other resources different from time are not considered. 3. Define the disciplines. Disciplines in SPEM determine process packages which take part in the process activities, related with a common subject. That is, disciplines represent a specialization of selected subactivities, where these new subactivities can not appear in other packages or disciplines. In this step, resources are the subject of the activities defined. 4. Define the guidance and suggestion view. The Guidances provide information about certain model elements. Each Guidance is associated to a Guidance Kind. This step is focused in exemplifying and documenting the activities previously defined. After applying the previous steps to IAF and SCRUM, the results can be synthesized in the following points: 1. Process Model: There are several Multi-Agents Systems that could be quickly constructed with INGENIAS by reusing previous developments. Recently, the INGENIAS Agent Framework (IAF) for JADE has been proposed and documented as a successful approach in this context. 2. Lifecycle: In SCRUM, each release is produced within a number of brief iterations called Sprints (see Fig. 1). All the work is done in two basic phases: the Preparation Phase (before the first sprint) and the Sprint Phases(successive sprints leading to the release). 3. Disciplines: The team defines required tasks for developing the Sprint: Daily Scrum, Initiate Product Backlog, Manage problems, Plan Release, Sprint Planning, Sprint Retrospective, Sprint Review and Update product backlog. 4. Guidance and suggestion view: The guidance for implementing the process with INGENIAS could be found in the IAF documentation [10]. All the aforementioned technique steps are further explained in the following subsections.


5

Fig. 1. SCRUM lifecycle

4.1 Lifecycle Although, SCRUM does not describe engineering activities required for product development, INGENIAS-SCRUM process must do it in order to adjust to IAF recommendations. IAF allows combining the classic approach of coding applications with modern techniques of automatic code generation. In this latest case, the generated MAS works over the JADE platform and additional tools available for this framework can be applied as well. This requires a correct IAF specification, that is, determine the following aspects in a sound way: • • • • • • •

Interactions. Interactions describe how agents do coordinate. Coordination is defined in terms of information transfer units. Tasks. Tasks are the basic units of agent’s behavior. They modify the agent mental state and perform actions over applications. Agents. Agents are the main building blocks of the system. An agent is defined completely when its perception (main tasks) and its coordination means are described. Deployment. Deployment expresses how agents are instantiated and initialized in the final system. Tests. Tests describe the testing units the MAS should pass. Goal. The agents pursue certain goals. Goals guide agent’s behavior. Mental state. The tasks performed by agents depend on their mental state and their pursued goals.

IAF requires the use of the INGENIAS Development Kit (IDK). IDK contains a graphical editor for working with the specification model. Accord-

6


ingly to IDK, the SCRUM definition for the Preparation Phase (see Fig. 2) comprises the tasks: Initiate Product Backlog, Plan Release and Preparation Tasks.

Fig. 2. Preparation Phase workflow

The INGENIAS Product Backlog contains the product requirements established with the IDK. This process can be done by adapting a known model from a previous project (i.e. IDK-IAF distribution comes with a complete cinema project which can be used for other distributed e-commerce developments) or defining a completely new product backlog with the editor. After this initial model is completed, in the Preparation Tasks, the SCRUM Master and the Product Owner establish the Plan Release in which the needed Sprints are defined. From the SCRUM perspective and taking into account that IAF bases on the automatic generation of code approach, the project team must be completely involved in getting the release within the planned sprints. So, the INGENIAS specification must be established with the IDK as the core of the development. From this core, the different scripts and sources will be automatically produced. Nevertheless, at the first stage, the generated code for the tasks may be incomplete and the programmer should add, if necessary, code in the tasks. This code must be incorporated in the specification by means of the IDK or the CodeUploader 3 application. In this way, the next code generation does not overwrite the added code. Furthermore, for some MAS, external components may be necessary, and the IDK provides a mechanism to integrate these components into the MAS. In addition, a developer may find necessary to modify code already generated. In order to do that, in each sprint (see Fig. 3 and Fig. 4) the following tasks must be performed: Plan Sprint, 3

http://grasia.fdi.ucm.es/


7

Update Product Backlog, Daily Works, Manage Problems, Conduct SCRUM Daily Meeting, Review Sprint, and Conduct Retrospective.

Fig. 3. Sprint Phase workflow

4.2 Disciplines Disciplines in SPEM determine process packages which take part in the process activities, related with a common subject. That is, disciplines represent a specialization of selected subactivities, where these new subactivities can not appear in other packages or disciplines. As previously pointed, in the INGENIAS-SCRUM approach the disciplines are the tasks required in each sprint, so the intended meaning of each task, according to IAF, must be explained. But first, the roles and products involved in the development must be introduced [9]. The roles, in this case, are:Product Owner, this role must be play by an active customer as in eXtreme Programming(XP); SCRUM Master, the coach and main of the development team; SCRUM Team, this is a collective role that must be played by any of the team members; Stakeholder, anyone that does not directly participate on the project but can influence the product being developed, that is, an interested party. The products or artifacts involved in a SCRUM development process are: Product backlog, Sprint backlog and Product increment. The product backlog contains the product requirements and has the purpose of listing all the functionalities to implement from a customer perspective. The sprint backlog is the list of things to do from the development team point of view. It could be understood as a fine-grained planning on detailed tasks. At last, the product increment is a partial product obtained at the end of each sprint, which can be deployed in the production environment or simply made available to users. From the INGENIAS-SCRUM perspective those artifacts are referred to the INGENIAS model and JADE code produced in each release. An INGENIAS model documented with the IDK can accomplish a low o high level of detail. Also, in the description of each model the SCRUM Master can fix the work to be done in the next release, where release can be identified with the package entity of the INGENIAS model.

8


Fig. 4. Sprint Iteration

The tasks that must be performed during the development lifecycle are: • • • • • • • • • •

Initiate Product Backlog.- Explained in the previous subsection. Preparation tasks.- Explained in the previous subsection. Plan Release.- Explained in the previous subsection. Sprint Planning.- It involves the following steps: Define the sprint’s goal, Select the items, Identify tasks from items, Estimate tasks, Assigning tasks, Getting team commitment. Update product backlog.- The update should take sprint scope changes into account for planning the next sprints. It must be performed in three steps: Collecting changes, Reprioritizing items and Reestimating items. Daily SCRUM.- The team performs backlog tasks to reach sprint goal in a free way, each SCRUM team selects the tasks to be performed or modified. Sprint Retrospective.- It allows the feedback and adaptation of the process. Sprint Review.- It shows what has been done and works. Manage problems.- This means to take into consideration the events that happen at every moment in a project and try to solve them. It is relevant with respect to last steps of the guideline presented in the next section Release work.- This latest Sprint prepares product release.

All these tasks could be matched with different guidelines appearing in IAF documentation [10].


9

4.3 Guidances Developing a system with code generation facilities requires some guidance. In IAF documentation [10] several guidelines for development are proposed. In multi-agent systems, we recommend specially the use of two kinds of guidance: Technique and Guideline. The technique provides an algorithm to create a work product. The guideline is a set of rules and recommendations about a work product organization. As examples, the most relevant INGENIAS Guidances are described below. Reader can have a more detailed view in [8].

5 CONCLUSIONS AND FUTURE WORK The definition of the software process engineering model of a MAS methodology makes it easier to learn and use the methodology. This paper provides a technique to define process models for agent-based development, using SPEM techniques. In particular, the technique is used for the redefinition of the SCRUM development process for the INGENIAS methodology. Furthermore, this work can guide a MAS team of developers through the steps of definition of a development process for MAS construction using an agent framework (the IAF) and the SCRUM process management. The description of the steps to follow provided in the paper, can simplify the definition of processes for non expert engineers. In addition, the description of how SCRUM can be used for managing a project within the INGENIAS methodology provides an example, of how a methodology can incorporate several processes. That is, INGENIAS may follow a RUP process of development or can use other specific processes, such as SCRUM. In the future, other methodologies and processes can be mixed in a particular process definition using the available tools for modeling. The models constructed in this way can assist the MAS designer in selecting the appropriate methodology and process model for a specific MAS, team of development or other circumstances. Moreover, the SCRUM process for the INGENIAS methodology can be compared with other MAS processes by means of certain metrics.

6 Acknowledgments This work has been supported by the following projects: Methods and tools for agent-based modeling supported by Spanish Council for Science and Technology with grants TIN2005-08501-C03-01 and TIN2005-08501-C03-03 cofinanced with FEDER funds and Grant for Research Group 910494 by the Region of Madrid (Comunidad de Madrid) and the Universidad Complutense Madrid.

10


Some figures which facilitate de understanding of this paper have been obtained form EPF [6].

References 1. APES2: A Process Engineering Software. http://apes2.berlios.de/en/links.html. 2. C. Bernon, M. Cossentino, and J. Pav´ on. Agent-oriented software engineering. Knowl. Eng. Rev., 20(2):99–116, 2005. 3. L. Cernuzzi, M. Cossentino, and F. Zambonelli. Process models for agent-based development. Engineering Applications of Artificial Intelligence, 18(2):205–222, 2005. 4. M. Cossentino, L. Sabatucci, V. Seidita, and G. S. An Agent Oriented Tool for New Design Processes. Proceedings of the Fourth European Workshop on Multi-Agent Systems, 2006. 5. P. Cuesta, A. G´ omez, J. Gonz´ alez, and F. J. Rodr´ıguez. The MESMA methodology for agent-oriented software engineering. In Proceedings of First International Workshop on Practical Applications of Agents and Multiagent Systems (IWPAAMS’2002), pages 87–98, 2002. 6. Eclipse: Eclipse Process Framework (EPF). http://www.eclipse.org/epf/. 7. I. Garc´ıa-Magari˜ no, J. R. P. Agera, and J. J. G´ omez-Sanz. Reaching consensus in a multi-agent system. In International workshop on practical applications on agents and multi-agent systems, 2007. Salamanca, Spain. 8. I. Garc´ıa-Magari˜ no, A. G´ omez-Rodr´ıguez, and J. C. Gonz´ alez. Modeling INGENIAS development process using EMF (In Spanish). In 6th International Workshop on Practical Applications on Agents and Multi-agent Systems, IWPAAMS’07, pages 369–378, 2007. November 12/13, 2007, Salamanca Spain. 9. I. Garc´ıa-Magari˜ no, A. G´ omez-Rodr´ıguez, and J. C. Gonz´ alez. Definition of Process Models for Agent-based Development. In 9th International Workshop on AOSE, 2008. May 12/13, Lisbon, Portugal. 10. J. G´ omez-Sanz. Ingenias Agent Framework. Development Guide V. 1.0. Technical report, Universidad Complutense de Madrid. 11. J. J. G´ omez-Sanz. Modelado de Sistemas Multi-Agente. PhD thesis, Departamento de Sistemas Inform´ aticos y Programaci´ on, Universidad Complutense Madrid, 2002. 12. J. J. G´ omez-Sanz and R. Fuentes. Agent oriented software engineering with ingenias. In Fourth Iberoamerican Workshop on Multi-Agent Systems (Iberagents’2002), a workshop of IBERAMIA’2002, the VIII Iberoamerican Conference on Artificial Intelligence, pages –, 2002. 13. B. Henderson-Sellers and P. Giorgini. Agent-Oriented Methodologies. Idea Group Inc., 2005. 14. A. Mas. Agentes Software y Sistemas Multi-Agentes. Pearson Prentice Hall, 2004. 15. J. Pav´ on and J. G´ omez-Sanz. Agent Oriented Software Engineering with INGENIAS. Multi-Agent Systems and Applications III, 2691:394–403, 2003. 16. J. Pav´ on, J. G´ omez-Sanz, and R. Fuentes. Model Driven Development of Multi-Agent Systems. ECMDA-FA, Proceedings of Model Driven ArchitectureFoundations and Applications, Second European Conference, ECMDA-FA 2006, Bilbao, Spain, 4066:284–298, 2006.


11

17. K. Schwaber and M. Beedle. Agile Software Development with Scrum. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. 18. J. Sutherland. Business object design and implementation workshop. In OOPSLA ’95: Addendum to the proceedings of the 10th annual conference on Objectoriented programming systems, languages, and applications (Addendum), pages 170–175, New York, NY, USA, 1995. ACM.