think it is crucial that the definition of what constitutes a development method is added to this specification. Observe that many concepts within the document define aspects of a method (e.g. method plug-in, method content, method configuration, etc) but at no stage is the concept of a method defined. The reason I think this is important is that the concept of "enactment" (seen in section 16) should be applied to a method rather than a process. For example, when I enact a development method I create a code repository and processes for its use — I do not just enact the processes. To support this model Figure 6.1 could change the configuration statement to "Configure a cohesive method customized for my project needs". The reason I need this alteration is that I am using the TOGAF method plug-in with the Eclipse Practice Framework. Here, the enactment of the TOGAF method for an organisation requires the creation of an architecture repository (in direct analogy to a code repository above). The current SPEM conceptual model does not seem to adequately cover this scenario

The representation of "Example of Activity Diagram" is weird. It mixes data
flow and control flow.

Between two activities there should be a plain arrow if one comes after the
other, and not a dashed arrow going from the 1st activity to an artifact and
then another dashed arrow going from the artifact to the second activity. The
fact that one activity comes after another is a control flow, the fact that a
part from that one artifact is passing from one to the other is different.

Because of this confusion, the strangest thing happens: synchronization bars
are showed to synchronize activities with artifacts! This has no meaning.
Only plain arroaw should leave and arrive to synchronization bars. They would
go to or from activities, showing that two activities happen concurrently.
The flow of data between the activities (artifacts and dashed arrows are
something different)