Tailoring PosoMAS for the Case Study

Adapting a process to the specific needs of a project and development team is an important step in making a process "fit" a certain development situation. This need is acknowledged by the OpenUP and by PosoMAS by including the practice Project Process Tailoring early in the inception phase. More generally, situational method engineering (SME, Henderson-Sellers & Ralyté, 2010) is that part of process engineering that focuses on the composition of new, ad-hoc methodologies for specific projects or development environments. We use situational method engineering (SME) to create a customised software engineering methodology from reusable assets, in this case from the practices available in PosoMAS and additional method content provided by other methodologies.

Since process tailoring shows the power of SME and the advantages of dividing a process into separate method fragments, chunks, or practices, the following will illustrate in detail how PosoMAS has been adapted for the example run. This includes extension of the process with method content from other processes, assignment of roles to concrete members of the development team, and the decision to alter the lifecycle and method content used.

Inclusion of Foreign Method Content

"MAS Adequacy Confirmation" is a method fragment originally developed as part of ADELFE (Cossentina & Seidita, 2005) and adapted to fit the modelling style of the PosoMAS practices. It provides support to check whether a system under development is actually suited for a multi-agent system approach. The method content of the practice can be found here.

Assignment of Roles to Members of the Development Team

The development team in the simulated development effort consisted of three people, each with experience in multi-agent systems and software engineering. One of the three was also a domain expert on power systems. In the following, we denote the three participants as "Person H", "Person B", and "Person J". Table 1 indicates who filled which role during the project. Please note that two of the participants acted as "developers", even though no actual implementation was done. This is due to the fact that the developers are often secondary performers on many design tasks. The tester, however, is not a developer since it is advantageous that testing is performed from a different perspective than the implementation. A number of roles have not been filled (e.g., Trainer, Deployment Manager, Course Developer) since these are not in the scope of the simulated effort.
Table 1: Assignment of Roles to Members of the Development Team
Role Team Member
Analyst Person B
Architect Person H
Product Owner Person J
Project Manager Person H
Process Engineer Person J
Tester Person B
Developer Person H, Person J
Stakeholder Person J
Deployment Engineer Person B

Changes to the Process Lifecycle and Method Content

The inclusion of method content from ADELFE required a change in the lifecycle during the inception phase where "MAS Adequacy Confirmation" was additionally scheduled as a task and an according work item was planned. Other than that, the simulation effort mostly ignored the implementation and test activities and focused on project management and design tasks. This is reflected in the Work Item Lists in which only the considered tasks received point estimation and man hours. Work products for relevant scheduled tasks were created and are linked at the appropriate points in the description of the process.

A number of work products were folded into the Architecture Notebook to keep all relevant information about the different architectural ares in one document. This includes the Agent Interaction Model and the Architectural Style Notebook. The consequence is that the Architecture Notebook contains a lot of information and becomes a large document. In development efforts that include many developers that might work on the design documents concurrently, it is advised to keep separate documents for the different architectural areas as suggested by the process to avoid editing conflicts and keep the documentation more structured.



This material is made available under the Creative Commons—Attribution-ShareAlike License v3.0.

© Copyright 2013, 2014 by Institute for Software & Systems Engineering, University of Augsburg
Contact: Jan-Philipp Steghöfer