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.

Bibliography

B. Henderson-Sellers and J. Ralyté, “Situational method engineering: State-of-the-art review,” Journal of Universal Computer Science, vol. 16, no. 3, pp. 424–478, Feb 2010.
M. Cossentino & V. Seidita (2005), SPEM Description of ADELFE Process, Technical Report, Consiglio Nazionale delle Ricerche - Istituto di Calcolo e Reti ad Alte Prestazioni (ICAR-CNR), Sede di Palermo Viale delle Scienze edificio 11 90128 Palermo. RT-ICAR-PA-05-07.

Copyright

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