The Inception Phase

The inception phase of the tailored version of PosoMAS focuses on four distinct areas:

The preparation of the process and its environment.
The elicitation of the most important requirements for the system.
The confirmation that a MAS approach is adequate.
A first draft of the system design.

The work breakdown structure of the phase can be found here. It shows three of the four areas mentioned above, where the activities Initiate Project and Plan and Manage Iteration all contribute to the first area. In addition to what is shown there, the additional activity MAS Adequacy Confirmation is carried out to determine whether a multi-agent system is the ideal environment as described in Tailoring PosoMAS for the case study, yielding the activity diagram shown in Figure 1. The red frames indicate activities and tasks that were specifically introduced with PosoMAS. The following will describe the work performed in the different activities, the artefacts created, and describe the experiences of the development team while performing the activities. In contrast to the other phases, the inception does not end with a deliverable in the form of a system that has value to the customer. The Lifecycle Objectives Milestone, reached at the end of the iteration instead indicates that the development team has understood the objectives and the scope of the project.

A total of three hours had been scheduled for the only iteration of the Inception phase. In the end, three and a half hours were required to finish the work. This is reflected by the velocity and the actual effort in the Project Burndown Report.

Figure 1: The activity chart for the PosoMAS inception phase with the MAS Adequacy Confirmation practice added.

Advantages of PosoMAS

During the inception phase, the development team profits from the agent-specific extensions of PosoMAS, most notably the replacement of use cases with goal-driven requirements elicitation and the added activity to confirm that a MAS is suitable. It is very natural for designer experienced with agent systems to describe and refine goals since they are very similar to the way BDI agents are specificed and it is often easier to think of how goals of the system have to be broken down to achieve local behaviour instead of focusing on singular, very complex interactions. During the initial design, the guidelines provided by PosoMAS for the differentiation of architectural areas, modelling of agents with UML, and the tips included in the different roadmaps for the practices that discuss best practices and pitfalls, are very helpful.

Initiate Project

The first portion of the iteration was used to set up project management, the process used, and to define the scope of the project. A first Project Plan was agreed upon that comprises a total of five iterations: one iteration in the inception phase, two in the elaboration phase, and one each in the construction and transition phase. Each iteration was scheduled and an expected velocity was assigned. This information is also included in the Project Burndown Report that is updated continuously as the project progresses. Additional information about role assignments as well as the project practices and measurements have been taken from the prepared process tailoring.

The Risk List details many of the risks involved with a high-impact project such as autonomous power management. In particular, it lists the risks that are due to the reliance on other, parallel projects that must provide the supporting infrastructure, and due to the business and legal challenges involved. While the development team has very little chance to affect these risks, the project manager has chosen to work closely with the teams involved in other relevant projects to ensure that the risks are minimised and requirements arising on the system side are communicated early and clearly. Risks associated with standard project management issues, such as illness of a developer, problems with the hardware and software infrastructure, are subsumed in one item.

The Vision, the artefact used as the basis of the project plan and of the first iterations of requirements elicitation, was the case study description. It was accompanied by additional material on power management systems, including (Appelrath et al., 2012) and (Steghöfer et al., 2013). It was also used as the input for the initial input of the Glossary. A number of issues that would have to be tackled in a real design and implementation of an autonomous power management system were defined to be out of scope of the product. This includes accumulating accurate accounting data and detect fraud by the power plant operators that might want to cheat the system by claiming to have delivered more power than they actually did. Likewise, issues of communication security are assumed to be tackled by another team. Partially, these assumptions are reflected in the Project Plan.

Activities and Tasks	Work Products
Activity: Initiate Project Task: Develop Technical Vision Task: Plan Project Activity: Prepare Environment Task: Tailor the Process Task: Deploy the Process	Project Plan Project Burndown Report Risk List Glossary

Plan and Manage Iteration

Early on, even before work on artefacts such as the risk list and the vision began, the Iteration Plan was created. It contains the schedule of milestones of the iteration, its most important objectives copied from the project plan, a reference to the Work Items List and evaluation criteria that will let the development team measure their progress. In the inception, these criteria are not as tangible as in later iterations, where the iteration milestones usually include builds that demonstrate business value. Instead, the need to capture requirements and define the project scope and vision is reflected.

The Work Items List is especially in flux during the first iteration. Initially, it is filled with project and iteration planning items and as the development team progresses through requirements elicitation and architectural considerations, is expanded and detailed more finely. The work breakdown structure gives an indication for the initial drafts of the list, even for later iterations. Concrete requirements can be added as soon as they become available. The Work Items List linked above is from a stage in the iteration when the first requirements became clear and a first scheduling of the work was performed (a part of the ongoing Plan and Manage Iteration activity). The final list for the iteration can be found here and shows the finished work, the number of hours worked on the different items, and a clearer picture of the work in the next iterations.

Activities and Tasks	Work Products
Activity: Plan and Manage Iteration Task: Plan Iteration Task: Manage Iteration	Iteration Plan Work Items List

After the work in the iteration is done, the team gets together for the final assessment that becomes part of the Iteration Plan. The first iteration of the process simulation did not finish on time. However, instead of stopping the work, the Project Manager decided to extend the iteration to be able to cover all required artefacts. This caused the progress to go to yellow, indicating that there is an issue with the process. Other issues were not detected in the iteration and the overall assessment was fine since all objectives and the defined criteria have been met. The Work Items List is updated as well, incorporating the actual work done, updating the status of the individual items, and checking the progress. It thus serves as the basis of the final assessment and gives the team an indication of the issues that have arisen.

Activities and Tasks	Work Products
Activity: Plan and Manage Iteration Task: Assess Results	Iteration Plan Work Items List

Identify System Goals and Requirements

A main focus of the initial iteration was the identification of high-impact requirements. For this purpose, the Vision and the Glossary were used as sources for requirements that were captured in a goal-driven fashion as described in the practice Goal-driven Requirements Elicitation. The main system goal that was identified is to maintain the stability of the power grid. This decomposes into three further requirements: to create and maintain schedules for the power plants, to use high-quality predictions for the creation of the schedules, and to stabilise the network frequency in case unplanned deviations occur.

These goals are further refined to sub-goals. High-quality predictions, e.g., rely on current weather forecasts in case of stochastic power plants such as solar and wind generators. Therefore, the power plants have to contact weather stations for up-to-date weather reports. Furthermore, the current status of the power plants should be taken into account. This can include solar panels that are shut off or maintenance intervals. These goals are then mapped to requirements which are assigned to individual agents. The distinction between controllable power plants that participate in the scheduling and stochastic power plants which are only dependent on the weather and their status is manifested in the introduction of corresponding agent types.

Requirements elicitation in this phase comes to an end after the Product Owner, the Analyst, and the Architect agree that those requirements with the greatest value and the highest impact have been captured. The team also identified a number of uncertainties, modelled as obstacles, and started thinking about possible mitigation strategies. The obstacle "Scheduling takes too long to compute", e.g., has already been dealt with by introducing a requirement for a suitable system structure, even though this requirement has not yet been fleshed out. System limitations and constraints have not yet been defined in this iteration. The final step is to validate the requirements by reviewing them and checking them against the vision.

The requirements engineering tool Objectiver was used to perform the goal-driven requirements elicitation. The resulting System Goals Document was exported as a browsable website. At the same time, a Conceptual Domain Model (incorporated into the Architecture Notebook) was created and the Glossary was updated.

Activities and Tasks	Work Products
Activity: Identify System Goals and Requirements Identify System Goals Refine System Goals to Requirements Mitigate Uncertainty Factors Validate Requirements	System Goals Model Conceptual Domain Model Glossary

MAS Adequacy Confirmation

This activity assumes that at least some of the requirements are already known. Depending on the style of requirements elicitation, acquiring the knowledge to make a substantiated decision can be quite difficult. Use cases, e.g., abstract so far from any kind of technical solution that it can be heard to answer the questions posed in the questionnaire. On the other hand, the goal-based requirements elicitation method used in PosoMAS allows the analyst to quickly ascertain the required information.

The work product of this activity, MAS Adequacy Synthesis, contains a paragraph for the confirmation that the global problem can be solved by a MAS and one paragraph for each of the local levels identified during requirements elicitation. Again, the fact that KAOS is used greatly simplifies the identification of these levels since they correspond to the agent types the requirements are assigned to. In our case, two relevant agent types were identified: AVPP and Power Plant. The latter can be quickly identified as a regular agent that does not in itself constitute a MAS. The former, however, shows characteristics of both types. As we will see in the elaboration phase, this fact will play a role in the decision for a suitable agent organisation. The global level is clearly suitable for multi-agent systems, even though not all answers have been clearly answered to indicate that.

Activities and Tasks	Work Products
Task: Confirm the Adequacy of a MAS Approach	MAS Adequacy Synthesis

Agree on Technical Approach

Based on the Vision, the preliminary System Goal Model, and the Conceptual Domain Model, the Development Team under the guidance of the Architect developed a first version of the architecture and a first draft of the Architecture Notebook. At this early stage, the architecture is still very high-level, with the main objectives to identify the different agent types and the elements of the environment, the system will have to interact with and which interfaces are required. Therefore, a high-level component diagram is created which shows controllable and stochastic power plants, a component for scheduling, the AVPP, the power grid and weather stations, as well as the interfaces provided and consumed by each.

Activities and Tasks	Work Products
Activity: Agree on Technical Approach Envision the Architecture	Architecture Notebook

Bibliography

Appelrath, H.J., H. Kagermann, and C. Mayer, editors. Future Energy Grid—Migration to the Internet of Energy. acatech STUDY. acatech – National Academy of Science and Engineering, Munich (2012).
Steghöfer, Jan-Philipp, Gerrit Anders, Florian Siefert, and Wolfgang Reif. ‘A System of Systems Approach to the Evolutionary Transformation of Power Management Systems’. In Proceedings of INFORMATIK 2013 – Workshop on &qout;Smart Grids", Lecture Notes in Informatics. Bonner Köllen Verlag (2013a).

Copyright

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