I would like to start the discussion about the process documentation template. coque iphone 7 plus I here propose an approach that I found useful. Please feel free to comment and to contribute different points of view.
It is based on SPEM 2.0 and it partially extends that (as reported in paper [1]). coque iphone 5 By now I am just considering the document structure, later I will go into further details (notation, metamodel, and so on).
The documentation is based on a few assumptions:
A) that the process workflow can be decomposed in 3 successive levels of details:
- phase. For instance: System Requirements Analysis is a phase.
- Activity. coque iphone 4 For instance Architecture Design is an activity
- Step (it is an atomic element of the process). For instance Identify Actors is a step.
Please note that in my point of view phases and activities always deliver main work products (like diagrams, text docs and so on) while steps contribute to define these work products. This will help in next process of our activity, process fragmentation.
B) Work product notation (for instance UML) is not necessarily part of the process specification. coque samsung a70 Frequently existing notations are adopted and therefore it is not necesssary to detail them. When a customised or totally new notation is used, it can be presented in the document or pointer to a complete documentation provided.
In my point of view the focus is not on modeling notation but rather on what is modeled (i.e. the instances of the MAS metamodel).
In the process template I suggest below, Phase and activities have a precise position in the template outline thus stressing the workflow representation of the process.
This is the outline I adopted:
1.Introduction
1.1.The (processname) Process lifecycle
1.2.The (processname) Metamodel
1.2.1Definition of MAS metamodel elements
2.Phases of the (processname) Process
2.1.(First) Phase
2.1.1.Process roles
2.1.2.Activity Details
2.1.3.Work Products
3.(Second) Phase
4. (further phases)
5.Work Product Dependencies
**An example of this outline is reported in this document**
References
[1] V. Seidita, M. Cossentino, S. Gaglio. Coques personnalisées iphone Using and Extending the SPEM Specifications to Represent Agent Oriented Methodologies. In Agent-Oriented Software Engineering 2008. Lecture Notes in Computer Science, volume 5386-0086. Springer-Verlag GmbH. 2009.
Hi all,
my first impressions :
- first are the three levels (Phase, Activity, Step) mandatory/sufficient ? They come from the SPEM concepts ? The real question in fact is do any methodology can be represented with them ? What could you say Massimo (you have a big experience with these questions).
- about the activities i would like to add two sections: goal and guidelines. Goal in order to define the state of affair to achieve as a result and guidelines in order to help use the activity.
Comment by vincent — 23/06/2009 @ 12:07
Hi,
1) about the three levels: IMHO they will be sufficient for most processes but I guess we should leave the possibility of enlarging the number. Probably an approach could be: phase remains the higher in granularity. It is composed of activities that in turn can be composed of activities or steps. Steps are atomic and therefore cannot be decomposed in more refined elements.
In this way we can have more levels and maintain a clear distinction among the the elements. In fact, I think it is good to classify elements in a way like this: a phase delivers a composite document assembling several DIFFERENT contributions coming from lower level elements. For instance a phase may collect several different structural and behavioral documents. An activity delivers a major work product (one or more instances of the same type). This means an activity may deliver a structural or behavioral diagram (sometimes complemented by text description thus creating a composite document).
Finally, a step contributes to the definition of an activity’s WP.
2) about activities: I think you are opening a very important issue. In my point of view, the major benefits of a standardized specification are: a) it is simpler to read, comprehend and share a process (at least difficulty of understanding the documentation structure is overcome); b) it is easier to extract coherent fragments and to store them in the same repository.
According to item b, we could have a great advantage from the introduction of a more refined outline for activities (that will likely be a major part of future fragments). I will work on that and propose something in the next few days.
Comment by Cossentino — 26/06/2009 @ 09:39
Dear all,
I just had a meeting with Alma M. Gómez about Figure 2 (pag.6) of the “PASSI with SPEM 2.0 ver0.2.5″ document that I posted in the website as an example of process documentation (avalaible at http://www.pa.icar.cnr.it/cossentino/fipa-dpdf-wg/docs/PASSI_with_SPEM_2.0_ver_0.2.5.pdf).
The diagram reported in Figure 2 should be a quick representation of the process lifecycle in order to smoothly move towards the description of its lower level elements (activities and tasks)
By now the diagram is a SPEM 2.0 component diagram. This choice comes from the idea of showing the main phases of the process as ‘components’ (thus addressing a possible fragmentation way).
After the discussion with Alma it seems to me this can be misleading. The diagram should be a process representation addressing the lifecycle structure at the highest level (phase).
For this reason phases and not components should be reported there. Here is a new version of the diagram reporting SPEM 2.0-style phases instead of process components.
I look forward to hear your opinions.
Comment by Cossentino — 02/09/2009 @ 17:15
I prepared an updated version of the documentation template example including the new phase-level diagram.
You can download it from here.
Comment by Cossentino — 04/09/2009 @ 16:32