Software & Systems Process Engineering Metamodel Avatar
  1. OMG Specification

Software & Systems Process Engineering Metamodel — Closed Issues

  • Acronym: SPEM
  • Issues Count: 11
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Appendix B is out of date

  • Key: SPEM2-16
  • Legacy Issue Number: 11302
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Appendix B is out of date. The diagrams need to be updated to use the correct stereotype names. It misses a section for the extends-replace variability kind.

  • Reported: SPEM 1.1 — Wed, 22 Aug 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Updated Appendix B with new images as the examples provided used the wrong stereotypes.
    • Added Appendix B.5 for Extends-Replace to complete the specification.
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Section: 14.11 and B.4

  • Key: SPEM2-15
  • Legacy Issue Number: 11284
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Inconsistent overrides for Extends: User of the SPEM 2.0 implementations EPF Composer and Rational Method Composer complained about an inconsistency in semantics define for the Extends relationship in Section 14.11 (p.136) and Appendix B.4 (p.179). The inconsistency relates to the fact that for to-one relationships and attribute values the extending element can override the inherited values whereas for to-many relationships values of the extending element would be appended to the list of inherited elements. The users preferred to have complete override semantics here as well. In other words, if the extending element would define its own to-many relationship instances the inherited relationships would be completely overridden. If the extending element needed relationships from its base element then users could add them back in manually, which is perceived as a more flexibility solution for using this relationship.

  • Reported: SPEM 1.1 — Fri, 17 Aug 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Updated semantics definition for Extends in Section 14.11 and updated Appendix B.4
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Page: 159ff

  • Key: SPEM2-14
  • Legacy Issue Number: 11266
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Section 18.4 defines Process Kinds, but Process is not a meta-model class anymore. These kinds need to be defined as Activity Kinds and need to be moved to Section 18.1.3.

  • Reported: SPEM 1.1 — Thu, 9 Aug 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Removed Process Kind stereotype and made all Process Kind specializations specialization of the Process stereotype.
    • Moved content of Section 18.4 to Section 18.1.4 to 18.1.6.
    • Removed outdated text that was left behind after revisions during the submission stage.
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Remove the word “Map” from various classes in the meta-model

  • Key: SPEM2-13
  • Legacy Issue Number: 11084
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Meta-Model: Remove the word “Map” from various classes in the meta-model The word “Map” is commonly used in software development to indicate a collection data structure that “maps keys to values”. The classes that use the word Map in SPEM 2 such as ResponsibilityAssignmentMap or TaskPerformerMap do not provide such a key to value mapping. Remove the word “map” from the class names. The names are clear without them, e.g. “ResponsibilityAssignment or TaskPerformer.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Updated the following classes by removing the word map from their name as well as all association's names they are connected to:
      o Work Definition Performer Map
      o Process Performer Map
      o Process Responsibility Assignment Map
      o Default Responsibility Assignment Map
      o Default Task Definition Performer Map
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Meta-Model: Missing association of Task Definition to Qualification

  • Key: SPEM2-12
  • Legacy Issue Number: 11083
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Meta-Model: Missing association of Task Definition to Qualification The SPEM 2 meta-model defines the concept of Qualification in Section 12.6, which is associated to Role Definitions. To fully utilize the concept it shall also be associated to Task Definition. This would allow to define Tasks purely based on the required qualifications and would allow a tool implementation of the meta-model to propose mappings of roles that would be a good fit to be listed a performers of the task based on the qualifications. This would allow to realize a so-called “late-role assignment” for roles to tasks for roles that all provide similar or common sub-sets of qualifications.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Added an association from Task Definition to Qualification and updated existing association name and role name from Role Definition to distinguish qualifications provided by roles from qualification required by tasks.
    • Renamed the role name for the association from Role use to Qualification to applied Qualification.
    • Added an association from Task Use to Qualification
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Responsibility Assignment Maps shall be specific for the Work Product State

  • Key: SPEM2-11
  • Legacy Issue Number: 11082
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Meta-Model: Responsibility Assignment Maps shall be specific for the Work Product State In the current SPEM 2.0 meta-model responsibility assignment of roles to work products is a class that associates a role use with a work product use as well as a role definition with a work product definition. However, in many processes these responsibilities might be actually different based on the state of the work product. For example, a “work item” work product to fix a bug might be assigned to a developer in the state “open” and assigned to a tester role instance in the state “resolved”. In the current SPEM 2 specification this can only be modeled by defining different work product use and role use instances with different maps within the context/namespace of an activity, but not independent of activities. Often processes or method content wants to define such relationships independent of a specific activity scope. We therefore propose to turn the assignment maps into such a ternary relationship (still represented as a class) amongst the concepts of role, work products, and state and to package merge in the Process Behavior package an association from the Responsibility Assignment Maps in Sections 9.8 and 12.1 to State_ext.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • See changes for Issue 11081
    • Added redefinitions of Default Responsibility Assignment and Process Responsibility Assignment (they have been renamed in Issue 11084 to not use the word Map anymore) that are associated to State_ext
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Meta-Model: Missing relationships in Process Behavior

  • Key: SPEM2-10
  • Legacy Issue Number: 11081
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Meta-Model: Missing relationships in Process Behavior Currently the Process Behavior package in Section 10 only provides associations of elements defined in Process Structure to behavioral models. If specification users implement the compliance levels “Complete” or “Method Content” they would also like to provide relationships of the additional elements introduced only in these compliance levels (e.g. work product definition) to behavior models. Provide either an Extended Process Behavior package that provide these missing relationships or package merge these relationships in the already existing packages. Currently there are issues with the following classes: - Work Product Definition needs to be associated to State_ext - Role Definition needs to be associated to Transition_ext - Task Definition or better the general Work Definition which also the generalization of the currently linked Activity needs to be associated to Transition_ext - Default_TaskDefinitionParameter or better its generalization WorkDefinitionParamter which is also the generalization of the currently linked ProcessParameter needs to be associated with State_Ext.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Added package merge relationship from Process Behavior to Method Content
    • Modeled association from Work Definition to Transition_ext replacing the existing association from Activity. Renamed association and role names for associations coming from Work Definition. Deleted Activity redefinition from Process Behavior package.
    • Added redefinitions for Work Product Definition and Role Definition and associated them to State_ext and Transition_ext respectively. Updated existing association and role names for consistency.
    • Replaced the Process Parameter override and relationships to State_Ext with the more generic Work Definition Parameter. Updated association name.
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Support UML 2 Profiles for SPEM 2.0 meta-model instances

  • Key: SPEM2-9
  • Legacy Issue Number: 11080
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    Meta-Model: Support UML 2 Profiles for SPEM 2.0 meta-model instances The SPEM 2.0 meta-model provides a light-weight extensibility mechanism via the Extensible Element and Kind classes that allow defining special kinds of meta-model elements such as “artifact” versus “deliverable” work product kinds. However, often when the kinds are defined meta-model users also want to define specific attributes or associations for the stereotyped instances such as in UML 2 Profiles. Provide as an additional alternative to the light-weight extensibility mechanism provided in the current specification also the ability to define and UML Profiles for SPEM 2 meta-model instances. As all classes in the SPEM 2 meta-model are derived from classifier the only model change to realize this capability needed would be to merge Infrastructure::Profiles into the SPEM 2 meta-model.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Merged Profiles package from UML2 Infrastructure library in SPEM Complete compliance level.
  • Updated: Sat, 7 Mar 2015 04:18 GMT

UML 2 Profile: Missing Profile meta-model diagrams

  • Key: SPEM2-8
  • Legacy Issue Number: 11079
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    UML 2 Profile: Missing Profile meta-model diagrams The specification does not present a UML model of the UML 2 Profile. Provide a class diagram for the profile.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Added stereotype diagrams to every section that defines a meta-model package. Text for each Figure caption: "The SPEM 2.0 UML 2 Profile stereotypes defined in the <name> package".
    • Added stereotype diagrams for the Base Plug-in Profile sections.
    • Fixed Figure 11.2 in Section 11.1 which was showing the wrong stereotypes.
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Fix stereotype extensions for components and update examples in spec

  • Key: SPEM2-7
  • Legacy Issue Number: 11078
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    UML 2 Profile: Fix stereotype extensions for components and update examples in specification (Thanks to FTF member Chris Armstrong, APG for helping identifying and discussing this issue.) The UML 2 Profile contains errors that prevent specification consumers from remodeling the examples presented in Section 14.7 using UML 2 Components and the supplied stereotypes. The Process Component stereotype extends Package, but UML 2 Components are Classes. Extend the stereotype from UML 2 Class and Package. The latter is necessary, because in SPEM 2 as well as SPEM 1.1 Process Components are derived from UML Package in the meta-model. A profile user shall be able to choose to apply the stereotype to UML Packages or Components. The stereotype definition currently misses a graphical icon that is shown in the examples. Add an icon to the stereotype. The Work Product Port stereotype extends Classifier, but UML 2 Ports are Properties, not Classifiers. Extend the stereotype from UML Port and not Classifier. The examples presented use different graphical icon than defined for the profile’s stereotypes. Redraw the diagrams to be consistent with the profile.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:
    • Changed Process Component stereotype to extend Class and Package in model and specification.
    • Changed Work Product Port to extend Port.
    • Fixed model by assigning the same icon to the Process Component stereotype as listed in the specification.
    • Replaced all figures with new diagrams coming from the same UML modeling tool that was used for all other figures in the specification using the fixed profile.
    • The old figures used the same names for component, port type, and work product definition name, which was very confusing. We adjusted the names.
  • Updated: Sat, 7 Mar 2015 04:18 GMT

Wrong Specification Name

  • Key: SPEM2-6
  • Legacy Issue Number: 11077
  • Status: closed  
  • Source: International Business Machines ( Dr. Peter Haumer)
  • Summary:

    The submission team of the specification had decided to change the name of the specification to “Software & Systems Process Engineering Meta-Model” but keeping the acronym “SPEM” as it is well-know in the industry. Currently the specification is still named as “Software Process Engineering Meta-Model”.

  • Reported: SPEM 1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — SPEM 2.0b1
  • Disposition Summary:

    We updated specification title, footer, and references to the full name in text to reflect the name change.

  • Updated: Sat, 7 Mar 2015 04:18 GMT