All processes have their characteristics and specific requirements that make them more or less suitable for the development of a certain product. The comparisons in the tables in Qualitative Comparison of AOSE processes can provide indications of the strength and weaknesses of the different processes. They are, however, not always easy to interpret, especially since Tran et al. (2005) have not necessarily defined their criteria unambiguously. Nevertheless, the list of features and concepts covered by the process, as well as the comparison of the life-cycle, process-related criteria, and supportive-feature criteria can at least give an indication of suitability.
Most processes impose a certain way of thinking about the system under construction on the development team. Prometheus enforces the use of BDI-agents, O-MaSE puts the focus on organisations and away from individual agents, and ASPECS forces the developers to think in terms of ontologies and holarchies. PosoMAS has been designed to be independent of most of these factors but still contains elements that favour certain solutions, e.g., using the Observer/Controller architectural pattern as the basis for adaptation processes in the system. When choosing a process, the development team has to make sure that the perspective taken by the process is compatible with the product. Unfortunately, this is not always clear when the project is initiated. This fact constitutes a classical chicken-and-egg problem: while rather detailed information about the product to develop is necessary to select the most suitable process, this information is only revealed while a process is already selected and under way. Ideally, the definition of the vision and the initial requirements should thus be done before the process is selected and the first iteration is begun.
Personal taste of the development team, e.g., with regard to the agility of the process, plays an important role as well. While some development teams thrive in an agile environment with very little focus on documentation, others are more productive if the documents are prescribed and development steps follow a clear sequential order. AOSE processes tend to be rather heavyweight, possibly due to the fact that their standardisation is far from the level of "traditional" software engineering processes and since agents and their specifics have not yet arrived in mainstream rely on very detailed and extensive documentation to achieve design standards comparable to traditional methodologies. However, it is possible to embed practices for MAS in agile methodologies and couple the best of both worlds.
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