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.

• 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.

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.

• Updated semantics definition for Extends in Section 14.11 and updated Appendix B.4

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.

• 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.

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.

• 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

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.

• 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

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.

• 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

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.

• 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.

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.

• Merged Profiles package from UML2 Infrastructure library in SPEM Complete compliance level.

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.

• 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.

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.

• 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.

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”.

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