${taskforce.name} Avatar
  1. OMG Task Force

SPEM FTF — Closed Issues

  • Key: SPEM
  • Issues Count: 53
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SPEM-53 SPEM issue: URL to issues reporting form is '404' SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-52 Duplication of 'range' in XMI SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-51 Standardization SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-50 Transformation to a UML-profile (section 11) SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-49 Activity and step (p. 7-4) SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-48 Precedes dependencies (p. 6-3) SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-47 SPEM FTF: Figure 3-2 (p. 3-2) SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-46 SPEM FTF: Figure 3.2 (p. 3-2) and figure 7-1 (p. 7-2) SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-4 Section 10.4 Precondition and Goal/Example SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-3 Section 8.3, page 33 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-8 Need more UML graphical examples SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-7 Figure 13-3, page 60 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-14 Figure 8.1, page 31 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-13 Section 7.1/Precedes, page 29 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-2 Section 8.1, page 31 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-1 Figure 3.8, page 21 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-11 Figure 3.2, page 18 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-10 Section 2.1/ Basic Concepts, page 13 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-15 Section 8.3, page 33 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-6 Figure 12-2 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-5 Section 12, page 46 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-9 Section 1.5/Proof of Concept, page 11 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-12 Figure 6.1, page 25 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-17 Section 9.2 /Example SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-16 Section 8.4, page 34 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-30 SPEM issue: acknowledgments SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-29 SPEM issue: Simplify Preface SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-24 trademark notification on page 2. SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-23 Typos in the current SPEM document SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-27 SPEM issue - InformationElement SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-26 Translation table, Annex 1 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-19 Figure 12.2, page 50 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-18 Section 12.1 SPEM to UML Correspondence Table SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-22 Section 12.6 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-21 Section 12.8, page 79 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-28 SPEM issue: URL to issues reporting form is '404' SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-25 .Section 1.2 Modeling Approach on page 7 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-20 Section 12.5, figure 12-3 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-39 Pre-defined UML stereotypes to be used in UML use case diagrams. SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-38 Capturing distinct kinds of WorkProducts in the metamodel. SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-42 Issue about goals and preconditions SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-41 Icon definition is missing in fig 12-1 SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-35 Use explicit references for MOF SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-34 Inconsistent use of name 'ProcessComponent' with EDOC SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-45 SPEM FTF: Data types (p 2-3) SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-44 Figure 11-3 Decomposition of WorkDefinition SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-37 Milestone as a metaclass SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-36 a Category should not inherit from ProcessComponent. SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-32 Make profile icons available SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-31 Remove DTD from the document SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-33 Combine classes for Goal and Precondition SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-40 Restriction on the model elements that can be annotated with Guidances SPEM 1.0b1 SPEM 1.0 Resolved closed
SPEM-43 4668 makes no sense unless StructuralFeature and Attribute are included SPEM 1.0b1 SPEM 1.0 Resolved closed

Issues Descriptions

SPEM issue: URL to issues reporting form is '404'

  • Key: SPEM-53
  • Legacy Issue Number: 4787
  • Status: closed  
  • Source: University of British Columbia ( Philippe Kruchten)
  • Summary:

    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.

  • Reported: SPEM 1.0b1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Link has been fixed.

  • Updated: Sun, 8 Mar 2015 18:39 GMT

Duplication of 'range' in XMI

  • Key: SPEM-52
  • Legacy Issue Number: 4827
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    1. Duplication of 'range' in XMI
    In the XMI and Rose metamodel the 'Multiplicity' has an explicit 'range'
    attribute in addition to the 'range' association end which causes a
    conflict. Proposed resolution: delete the attribute

  • Reported: SPEM 1.0b1 — Sun, 12 Feb 2012 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Duplicate, resolved by issue # 4833

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Standardization

  • Key: SPEM-51
  • Legacy Issue Number: 5221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Standardization

    SPEM is a MOF-based metamodel (p 1-2) which is defined as an extension of a
    subset of UML (SPEM foundation; p 1-3). However, SPEM cannot be considered
    as a conservative extension of the UML metamodel since the SPEM foundation
    does not keep the semantics of the UML meta-model (i.e., some elements of
    the SPEM foundation have not the same structure, associations, an-cestors
    and, hence, semantics as their counterparts in the UML metamodel).
    This lack of conformance with UML compromises standardization. In
    particular, the SPEM foundation elements cannot rely on the semantics of the
    UML metamodel. As a result, the semantics of the SPEM UML-profile are not
    well-defined and the portability of SPEM models is impaired.

    • Example 1: A UML metamodel Association, as a GeneralizableElement,
      inherits several at-tributes (e.g., isRoot, isLeaf). A SPEM Association does
      not inherit them (since it is not a Gen-eralizableElement). A UML tool may
      require a value for those attributes in Association in-stances.
    • Example 2: The UML metamodel defines several constraints on Package
      regarding the asso-ciation importedElement. Since this association is not
      defined in SPEM, those constraints make no sense.

    Proposed resolution:
    1. Keep UML metamodel ancestors for all the SPEM foundation elements.
    2. Keep UML metamodel associations involving SPEM foundation elements (this
    includes asso-ciations with elements not belonging to SPEM foundation)
    3. Incorporate constraints restricting the semantics of the UML metaelements
    in a SPEM model (e.g., Add to Package, the constraint:
    self.importedElement->size=0)

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    reject, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transformation to a UML-profile (section 11)

  • Key: SPEM-50
  • Legacy Issue Number: 5220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Transformation to a UML-profile (section 11)

    A model built using the SPEM UML-profile does not conform necessarely with
    the SPEM metamodel (for instance, since the UML ModelManagement package is
    retained in the SPEM UML-profile definition, a model can define instances of
    the Package::importedElement association, which are not part of the SPEM
    metamodel).
    Proposed resolution: Incorporate constraints to restrict the use of the UML
    elements within the SPEM UML-profile.

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject. The SPEM was designed this way.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity and step (p. 7-4)

  • Key: SPEM-49
  • Legacy Issue Number: 5219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Activity and step (p. 7-4)
    The specification document states: "Although it is not explicitly
    prohibited, an Activity does not normally use the subWork structure
    inherited from WorkDefinition; instead decomposition within Activity is done
    using Steps". Steps are atomic elements. In practice, this constraints
    activity de-composition to two levels. We believe that this is not enough to
    model detailed and fine-grained processes.
    Proposed resolution: Remove Step from the metamodel and use the association
    parentwork-subwork to model Activity decomposition too.

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject. The presence of Step does not constrain activity decomposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Precedes dependencies (p. 6-3)

  • Key: SPEM-48
  • Legacy Issue Number: 5218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Although the precedes dependency may be enough for the family of software
    development proc-esses whose modelling is the main interest of SPEM, it
    should be noted that finish-start and finish-finish precedence relationships
    are clearly insufficient when detailed software processes are to be
    modelled.
    Proposed resolution: Incorporate other precedence relationships to the SPEM
    definition. See, for instance:

    Schlenoff, C., Gruninger M., Tissot, F., Valois, J., Lubell, J., Lee, J.,
    The Process Specification Language (PSL): Overview and Version 1.0
    Specification, NISTIR 6459, National Institute of Standards and Technology,
    Gaithersburg, MD (2000).

    Ribó J.M; Franch X.: Building Expressive and Flexible Process Models using
    an UML-based approach. LNCS, Vol. 2077. Springer-Verlag (2001).

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM FTF: Figure 3-2 (p. 3-2)

  • Key: SPEM-47
  • Legacy Issue Number: 5217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 3-2 (p. 3-2)
    We believe that it is better to consider that an activity may be performed
    by a collaboration of more than one role. In this case, two different
    associations should be provided in order to distinguish between
    "responsible" and "participant".

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Resolved by 4681 – duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM FTF: Figure 3.2 (p. 3-2) and figure 7-1 (p. 7-2)

  • Key: SPEM-46
  • Legacy Issue Number: 5216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 3.2 (p. 3-2) and figure 7-1 (p. 7-2)

    In our opinion, WorkProduct should have a role as responsible. Although
    figure 3-2 considers a "responsibility" association between Role and
    WorkProduct, this association is not retained in the metamodel definition.
    Specifically, the process structure package representation (figure 7.1, p.
    7-2) does not depict any association meaning "responsibility" between
    WorkProduct and ProcessPerformer or ProcessRole.
    Proposed resolution: Incorporate "responsibility" associations between
    ProcessPerformer and WorkProduct in figure 7-1.

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Duplicate Resolved by 4682

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.4 Precondition and Goal/Example

  • Key: SPEM-4
  • Legacy Issue Number: 4670
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The possible states of work products are referenced in pre-conditions and
    goal but there is no declaration of such potential states in the SPEM
    metamodel.
    Solution: add a "validStates" attribute in the "WorkProduct" class.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept. Introduce a subset of the UML 1.4 model of states into the SPEM

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3, page 33

  • Key: SPEM-3
  • Legacy Issue Number: 4669
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    "An Activity is owned by a ProcessRole that is the performer (or owner)"
    Mixing "performer" and "ownership" is very confusing. In the metamodel
    these two concepts should be clearly distinguished.
    The "performer" association should not "derive" from the feature/owner
    association. It's more natural to say that activities are owned by the
    process (a Package).
    Features (such as attributes) in roles could be used for another purpose:
    adding specific information on roles
    NOTE that this suggested modification need not to impact the UML profile.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need more UML graphical examples

  • Key: SPEM-8
  • Legacy Issue Number: 4674
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Need more UML graphical examples (accompanied with its SPEM translation,
    using for instance a HUTN notation)

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 13-3, page 60

  • Key: SPEM-7
  • Legacy Issue Number: 4673
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    This very basic example CANNOT be expressed in the terms of the SPEM
    metamodel because there is no way to represent fork/joins. I don't see any
    valid justification for such limitation.
    A simple solution would be to add a "PseudoActivity" class, inheriting from
    Activity and having a "kind"attribute (choice, join, fork,...etc.).

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept. Introduce a subset of the UML1.4 model of Activities into the SPEM

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 8.1, page 31

  • Key: SPEM-14
  • Legacy Issue Number: 4680
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Role name "steps" should be renamed "step" (this is the usual convention)

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1/Precedes, page 29

  • Key: SPEM-13
  • Legacy Issue Number: 4679
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A short explanation of what is the meaning of finish-start and
    finish-finish is needed.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.1, page 31

  • Key: SPEM-2
  • Legacy Issue Number: 4668
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    I don't see any justification for prohibiting the WorkProducts to have
    features.
    Attributes in WorkProducts may be useful to add extra information
    (such as the version number, creation date, etc). Each SPEM compliant
    family may define its own set of relevant attributes.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 3.8, page 21

  • Key: SPEM-1
  • Legacy Issue Number: 4667
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:
    • Figure 3.8, page 21
      A package cannot import a model element individually (an "Import"
      dependency (inherited from UML) cannot be used since the client
      and the supplier need to be Packages (see UML 1.4 and section 7.2)
      The UML association Package/importedElement/ModelElement need
      to be included in the SPEM_Foundation package.
  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 3.2, page 18

  • Key: SPEM-11
  • Legacy Issue Number: 4677
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Prefixes "ak_" and "pdk_" should be removed.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.1/ Basic Concepts, page 13

  • Key: SPEM-10
  • Legacy Issue Number: 4676
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    "Techniques are modeled by Guidance or Activity(see section 8.3)"
    In section 8.3 there is no statement regarding how to model Techniques
    with activities

    • Figure 3.2, page 18
      Prefixes "ak_" and "pdk_" should be removed.
  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject. Issue refers to wrong document

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3, page 33

  • Key: SPEM-15
  • Legacy Issue Number: 4681
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    "It may refer addtional...assistants...as additional input parameters..."
    Too complex. Why not an explicit "assist" relationship in the metamodel
    between
    a ProcessRole and an Activity? This will ease implementation of the SPEM
    metamodel.
    NOTA: No changes in the UML profile is implied with this change,

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 12-2

  • Key: SPEM-6
  • Legacy Issue Number: 4672
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the figure An Actor has attributes. Is this valid in UML 1.4?
    In the UML 1.4 specification it is only said that an actor may have
    interfaces.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12, page 46

  • Key: SPEM-5
  • Legacy Issue Number: 4671
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    "The SPEM profile... to give more detail to the work decomposition..."
    This is not true. Work composition in the SPEM metamodel is recursive
    (subWork/parentWork), so any detail of decomposition is expressible with
    the MM.
    This sentence should be removed.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 1.5/Proof of Concept, page 11

  • Key: SPEM-9
  • Legacy Issue Number: 4675
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Mention an available implementation of the SPEM metamodel using the the
    France Telecom
    Univers@lis repository tool.
    Add a reference in Section 16: http: /universalis.elibel.tm.fr/site/

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 6.1, page 25

  • Key: SPEM-12
  • Legacy Issue Number: 4678
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A guidance may apply to more than one model element (see the "Java
    Programming
    Guideline" in page 27)
    Multiplicity of the association should be 1..*

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.2 /Example

  • Key: SPEM-17
  • Legacy Issue Number: 4683
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Inputs and Outputs for processes are undefined (in contrast with inputs
    and output for
    activities which are defined in 8.2)

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.4, page 34

  • Key: SPEM-16
  • Legacy Issue Number: 4682
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    "A ProcessRole is responsisble for..."
    Too complex and unclear. Why not an explicit "responsibleFor" relationship
    in the MM?
    This will minimize the size of XMI files generated from SPEM.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM issue: acknowledgments

  • Key: SPEM-30
  • Legacy Issue Number: 4789
  • Status: closed  
  • Source: University of British Columbia ( Philippe Kruchten)
  • Summary:

    Ref: http://www.omg.org/cgi-bin/doc?ptc/2001-12-06

    page 14-15 ( numbered viii and ix)
    It is curious to find that the names of the people who actively contributed have disappeared, but the
    secondary participants, last minute reviewers or critics have remained.

    Either we leave just the company names and cut the people page 15, or (in IEEE style),
    we do list the active contributors page 14,...

    Steve Cook has spent one or two order of magnitude more time and 3 orders of magnitude more money
    on this than Mr. BHS...

  • Reported: SPEM 1.0b1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM issue: Simplify Preface

  • Key: SPEM-29
  • Legacy Issue Number: 4788
  • Status: closed  
  • Source: University of British Columbia ( Philippe Kruchten)
  • Summary:

    Ref: http://www.omg.org/cgi-bin/doc?ptc/2001-12-06

    Suppress the Corba text that is of little relevance to this specification:
    -page 11, what is CORBA

    • and page 12-13: Corba spec..

    Replace by nothing. Or if we need something, have a section

    What is UML

    and

    UML 1.4 specification

    instead (which seems more relevant that what is CORBA).

    Note: refer to email correspondence with mr. Watson.

  • Reported: SPEM 1.0b1 — Mon, 17 Dec 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

trademark notification on page 2.

  • Key: SPEM-24
  • Legacy Issue Number: 4695
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    1. trademark notification on page 2.
    Could you add a following sentence?
    "SDEM is a registered trademark of Fujitsu in Japan."

  • Reported: SPEM 1.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in the current SPEM document

  • Key: SPEM-23
  • Legacy Issue Number: 4689
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    TYPO issues

    • Section 1.5/UML page 8
      "Software Process Engineering Model" should be replaced by
      "Software Process Engineering Metamodel"
    • Section 1.5/Workflow, page 10
      "None of the these areas overlaps the SPE submission" should be
      replaced by
      "None of these areas overlaps the SPEM submission"
    • Section 3.1, page 17
      "The SPEM_Foundation:;Data_Types" should be replaced by
      "The SPEM_Foundation::Data_Types"
    • Section 3.4, page 22
      Well-formedness rules need to be re-numbered.
    • End of page 27
      A dot is expected at the end of the sentence.
    • Section 7.1/Categorizes
      "Discpline" ==> "Discipline"
    • Section 8.2, page 33
      "ProcessRoke" ==>ProcessRole
  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM issue - InformationElement

  • Key: SPEM-27
  • Legacy Issue Number: 4751
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    InformationElement in the SPEM specification section 7.1 seems to do
    nothing that cannot be done by WorkProduct. I believe it is redundant and
    should be deleted from the model.

  • Reported: SPEM 1.0b1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Translation table, Annex 1

  • Key: SPEM-26
  • Legacy Issue Number: 4697
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    3. Translation table, Annex 1
    Regarding SLCP(ISO/IEC 12207) column,
    "Lifecycle model" has not been defined in a body of its
    specification except annex example.
    "Lifecycle model" of SLCP should not be described
    in the translation table, should it?
    And, I think that the SLCP has provided "Iteration".
    It better describe an "Iteration" on the SLCP Iteration column.

  • Reported: SPEM 1.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject (withdrawn).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 12.2, page 50

  • Key: SPEM-19
  • Legacy Issue Number: 4685
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Use <<baseClass>> instead of <<stereotype>> in dependencies.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    No, SPEM follows UML 1.4 specification. Reject

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.1 SPEM to UML Correspondence Table

  • Key: SPEM-18
  • Legacy Issue Number: 4684
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    For clarity alternative representations should appear in the table. For
    instance UseCases
    to represent work definitions.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.6

  • Key: SPEM-22
  • Legacy Issue Number: 4688
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Clarify the meaning of "includes" dependencies in the SPEM UML profile

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.8, page 79

  • Key: SPEM-21
  • Legacy Issue Number: 4687
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The Model stereotype conflicts with the UML Model metaclass.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM issue: URL to issues reporting form is '404'

  • Key: SPEM-28
  • Legacy Issue Number: 4786
  • Status: closed  
  • Source: University of British Columbia ( Philippe Kruchten)
  • Summary:

    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.

  • Reported: SPEM 1.0b1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

.Section 1.2 Modeling Approach on page 7

  • Key: SPEM-25
  • Legacy Issue Number: 4696
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    2.Section 1.2 Modeling Approach on page 7
    Could you add "SDEM" as an example of M1 level.

  • Reported: SPEM 1.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.5, figure 12-3

  • Key: SPEM-20
  • Legacy Issue Number: 4686
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The relationship between a CallAction and the "behavior" of an operation
    needs to
    be clarified.

  • Reported: SPEM 1.0b1 — Wed, 7 Nov 2001 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Resolved by 4673

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pre-defined UML stereotypes to be used in UML use case diagrams.

  • Key: SPEM-39
  • Legacy Issue Number: 4889
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    5. Pre-defined UML stereotypes to be used in UML use case diagrams.
    When using a use case diagram to show the relationships between
    ProcessRoles and WorkDefinitions we may want to distinguish
    between assist and perform. The <<assist>> and <<perform>>
    stereotypes could be defined for this purpose in the SPEM spec.
    When no stereotype is used, the specification should indicate what is
    the default interpretation that applies (according to figure 12-2 the
    default meaning is assistance).
    In addition, to render in a more user-friendly way the semantics of an
    association between a ProcessRole and a WorkProduct, we could add
    a <<responsible>> stereotype.

  • Reported: SPEM 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Capturing distinct kinds of WorkProducts in the metamodel.

  • Key: SPEM-38
  • Legacy Issue Number: 4887
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    3. Capturing distinct kinds of WorkProducts in the metamodel.
    In the metamodel there is no way to capture both the name and
    the kind of a workproduct. In contrast, in the UML profile, the
    kind of a work product can be provided using pre-defined stereotypes
    (such as <<document>> and <<UMLmodel>>).
    In order to solve this and also allow more flexibility to refer to distinct
    kinds of work products (such as Text Documents, UML model,
    SDL models, SQL Tables, executables, code librairies, and so on) a
    WorkProductKind could be added in the metamodel (in the similar
    manner as the GuidanceKind metaclass).
    In addition a 'subKind' association between WorkProductKinds could
    be useful to allow the structuring of allowable product kinds.
    NOTA: No additional pre-defined UML stereotypes need to be
    defined since these may depend on the process family being used.

  • Reported: SPEM 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue about goals and preconditions

  • Key: SPEM-42
  • Legacy Issue Number: 4980
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the SPEM, goals and preconditions are shown as constraints which are
    shown as owned by WorkDefinitions. This is inconsistent with the UML 1.4 in
    which constraints are owned by Namespaces. This makes the profile mapping
    invalid. To make the profile valid it is necessary to state that the
    constraint must be owned by a namespace: the associated ProcessPerformer
    would do ok, and also to clarify that the associations between
    WorkDefinition and Goal/Precondition are actually specialisations of the
    general constraint/constrainedElement association.

  • Reported: SPEM 1.0b1 — Tue, 12 Mar 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Icon definition is missing in fig 12-1

  • Key: SPEM-41
  • Legacy Issue Number: 4891
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    7. Icon definition is missing in fig 12-1
    The icon used for denoting the User Models in figure 12-1 is not defined
    in 11.5 section.

  • Reported: SPEM 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use explicit references for MOF

  • Key: SPEM-35
  • Legacy Issue Number: 4833
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SPEM should use explicit references rather than leaving MOF to generate
    them, driven by non-navigable association ends. This is because
    non-navigability has a stronger effect in MOF than just not generating the
    references, which compromises the ability to perform 'where used'
    navigations. Adopting this approach will be consistent with UML and CWM
    metamodels.

  • Reported: SPEM 1.0b1 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of name 'ProcessComponent' with EDOC

  • Key: SPEM-34
  • Legacy Issue Number: 4831
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    EDOC uses the name for something completely different: a (higher-level)
    (software) component that can enact a business process. There are cases
    where both metamodels need to be combined in the same repository and this
    causes needless scope for confusion.

    Proposed resolution: rename 'ProcessComponent' to 'ProcessModule' since it
    is not a Component in the conventional usage of software having well defined
    interfaces.

  • Reported: SPEM 1.0b1 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Withdrawn by Pete: reject

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SPEM FTF: Data types (p 2-3)

  • Key: SPEM-45
  • Legacy Issue Number: 5215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Data types (p 2-3)

    Figure 2-2 (p. 2-3). We think that the stereotype <<datatype>> applied to
    Boolean should be sub-stituted for <<enumeration>>.

  • Reported: SPEM 1.0b1 — Fri, 12 Apr 2002 04:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject. SPEM follows UML 1.4 on this point

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 11-3 Decomposition of WorkDefinition

  • Key: SPEM-44
  • Legacy Issue Number: 5087
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I'm trying to map the assocations in Figure 11-3 "Decomposition of
    WorkDefinition" to those in Figure 7-1 "Process Structure Package" and I
    have 3 questions:

    1. WorkDefinition has a direct association to itself in Figure 7-1 and
    Operation (to which WorkDefinition is mapped) in Figure 11-3 does not
    seem to have such direct corresponding association. Does this
    association map to
    Operation->ActivityGraph->CompositeState->ActionState->CallAction->Operation
    in Figure 11-3 ?

    2. If the answer to the above question is yes then this question is: the
    self-assocation of Operation in Figure 11-3 passes through ActionState
    (to which Step from Figure 7-1 is mapped to) but the self assocation of
    WorkDefinition in Figure 7-1 does not seem to pass through Step, why ?

    3. Step in Figure 7-1 is mapped to ActionState in Figure 11-3 and Step
    doesn't seem to have any sub-component. In Figure 11-3 ActionState has a
    composition assocation with Action (+entry), what does this represent ?

  • Reported: SPEM 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Milestone as a metaclass

  • Key: SPEM-37
  • Legacy Issue Number: 4886
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Milestone as a metaclass
    In 9.1 and 9.2 milestones are defined as special kinds of goals.
    Because a Milestone is an major concept it could make
    sense to add a Milestone metaclass inheriting from the more
    generic metaclass used for Goal.
    Additionally, a <<milestone>> stereotype could be added in the
    UML profile.

  • Reported: SPEM 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

a Category should not inherit from ProcessComponent.

  • Key: SPEM-36
  • Legacy Issue Number: 4885
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    An explicit metaclass to denote packages used for categorization.
    To better reflect the semantics of packages that are used to
    define a category of process elements, it could be useful to add
    an explicit "Category" metaclass inheriting from Package.
    Additionnally, a well-formedness rule saying "A Category can
    only contain Categorizes dependencies" will help to formalize
    the usage of this.
    A Discipline Package obviously inherits from Category.
    However a Category should not inherit from ProcessComponent.
    In addition, a <<category>> stereotype could be added in
    the UML profile.

  • Reported: SPEM 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept a minor change of wording, no extra metaclass.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make profile icons available

  • Key: SPEM-32
  • Legacy Issue Number: 4829
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    3. Make profile icons available
    It would be useful to have bitmaps and Rose definitions for the standard
    icons as a non-normative 'supporting measure' to ease adoption and encourage
    consistency.

  • Reported: SPEM 1.0b1 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove DTD from the document

  • Key: SPEM-31
  • Legacy Issue Number: 4828
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2. Remove DTD from the document
    It's not human-readable and so should not be in the document but a separate
    file.

    Proposed resolution: delete Chapter 13 and refer to the separate file (which
    will remain normative).

  • Reported: SPEM 1.0b1 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Combine classes for Goal and Precondition

  • Key: SPEM-33
  • Legacy Issue Number: 4830
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Goal and Precondition do not need to be separate classes. Could not the same
    object 'Design Model in state Ready' be used for both the Goal of one
    Activity and the Precondition of the following activity? By using exactly
    the same object one can more easily follow state-driven transitions.

    Proposed resolution: make use of ClassifierInState (added as part of the
    Activity metamodel extensions)

  • Reported: SPEM 1.0b1 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Withdrawn by Pete: reject.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restriction on the model elements that can be annotated with Guidances

  • Key: SPEM-40
  • Legacy Issue Number: 4890
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    6. Restriction on the model elements that can be annotated with Guidances.
    In 5.2 it is said that a Guidance can be attached to any model element.
    This is probably to permissive. Maybe we should add a well-formedness
    rule that restricts this to WorkDefinitions and WorkProducts.

  • Reported: SPEM 1.0b1 — Fri, 22 Feb 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4668 makes no sense unless StructuralFeature and Attribute are included

  • Key: SPEM-43
  • Legacy Issue Number: 5086
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Issue 4668 suggested that WorkProducts can have attributes. However, SPEM
    does not include StructuralFeatures or Attributes. Issue 4668 therefore
    makes no sense unless StructuralFeature and Attribute are included.

  • Reported: SPEM 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Disposition: Resolved — SPEM 1.0
  • Disposition Summary:

    Reject. StructuralFeature and Attribute will not be included

  • Updated: Fri, 6 Mar 2015 20:58 GMT