While the simulated development effort was the third time PosoMAS was applied, it was the first time that only software engineers with very good knowledge of the domain and the application of software processes worked together in a brief period of time and looked at all aspects of the process. This concentrated approach resulted in some changes to the method content and some interesting insights into the application of PosoMAS, both of which are described in the following.
The MAS Adequacy Confirmation practice was refined, by clearing up the criteria by which MAS adequacy is checked on the local level and by giving more detailed instructions on the creation of the work product.
The artefact Agent Organisation Structure is more clearly defined now and an accompanying guideline as well as a template have been created.
The task Apply Architectural Style from the practice Pattern-driven MAS Design was originally defined as separate from the activity Develop System Architecture and has now been included in that activity to make it clear that it applies to the system architecture.
The main reason why the initial two iterations took longer than anticipated was the sheer number of tasks that had to be accomplished in the early design stages. Since the simulated development effort was very much focused on providing a high-level architecture that is at the same time viable and supports the requirements, many design decisions had to be made in a very short period of time. In an actual development effort, where the individual phases require weeks instead of hours, this would have been less of an issue. However, these circumstances show that it was a wise decision to select a system that the development team was already familiar with for the simulated effort. This way, the team could focus on the process and go through the individual steps in detail without being to caught up in understanding the vision, requirements, and environment.
The time to bring the artefacts into a state in which they could be published here was not part of the planned and actual work hours for the different iterations. Instead, the diagrams and texts that were captured during the time the team worked on the product were revised later on. Especially the Architecture Notebook that contains a number of diagrams and their descriptions on the actual design was created offline. This additional effort is, however, again negligible in a greater development effort in which an iteration takes weeks.
While both PosoMAS and the OpenUP often call for fine-grained work products and artefacts, it is often much more convenient to merge different work products into one document. Examples for this are the Architecture Notebook and the Deployment Plan. The former captures all kinds of design models, including the Agent Interaction Model, the Individual Agent Architecture, and the Multi-Agent System Architecture. The latter comprises much information about the deployment, including Release Controls and Infrastructure. Note that the scope of these documents is within the discretion of the Project Manager and the Development Team and that other instantiations of the process can therefore choose a different division of artefacts.
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
Contributors
Contact: Jan-Philipp Steghöfer