Issues for Software Process Engineering Management revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 4787: SPEM issue: URL to issues reporting form is '404'
Issue 4832: Explicit relationship for WorkProduct composition
Issue 4888: Need for a minimal extensibility mechanism in the SPEM metamodel.
Issue 5331: Trace should not apply only on WorkDefinition but on every model element
Issue 5643: Constraint [C46] in section 8.5 contradicts definition of Discipline
Issue 6623: Figure 2.4 Foundation Core Package
Issue 9515: figure 12-4 page 85
Issue 14075: definition of what constitutes a development method

Issue 4787: SPEM issue: URL to issues reporting form is '404' (spem-rtf)

Ref:  http://www.omg.org/cgi-bin/doc?ptc/2001-12-06
 
on page 5 it says:

All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers

to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form at

http://www.omg.org/library/issuerpt.htm

 

This page does not exist.

In 7.1 (Associations): Using UML aggregation to represent WorkProduct
composition is painful in the metamodel since it requires Association,
AssociationEnd and Multiplicity objects etc. To link 2 WorkProducts will
thus take 7 objects (Association, 2 AssociationEnds, 2 Multiplicities, 2
Ranges) none of which carry any useful information. In contrast,
WorkDefinition has a direct subWork association.

Proposed resolution: introduce a new recursive association on WorkProduct
with ends subWork(0..*) and parentWork(0..*).

Discussed on 16/4/2002, no resolution

4. Need for a minimal extensibility mechanism in the SPEM metamodel. 
When using the SPEM UML profile one can use tagged values to 
annotate model elements. In order not to loose this information 
when expressing the SPEM model in terms of the metamodel, we need 
an equivalent mechanism in the metamodel counterpart. 
Suggestion: add a Property metaclass with a name and value attributes 
to be attached to any model element. 

This is addressed by UML 2.0, and is being handled under the SPEM 2.0 RFP.

The SPEM standard says :


"A Trace dependency acts between WorkDefinitions and is mainly
used to trace requirements and changes across models. It has the same
semantics as UML Trace."


Trace should not apply only on WorkDefinition but on every model element. We
could have for examples a requirement on process, and trace a specific
activity to the requirement, thus expressing that we have defined this
activity to fulfill the requirement. This is in line with the UML semantics.

Constraint [C46] in section 8.5 contradicts the definition of Discipline in the previous section. The standard says: 

"[C46] Disciplines only categorize Activities." 

However, in the previous section, Disciplines are defined as categorizing Activities, Guidances, and WorkProducts. We should consider getting rid of [C46]. 

The Figure 2.4 Foundation Core Package - Backbone will look "cleaner" if the element "Feature" will be moved to a position in between elements "Parameter" and "Constraint". This would allow to adjust the diagram so that the composition association between "Model Element" and "Namespaces" may stand alone, not crossing the inheritance association. 

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)

 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