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.

Link has been fixed.

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.

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

Duplicate, resolved by issue # 4833

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)

reject, see above

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.

Reject. The SPEM was designed this way.

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.

Reject. The presence of Step does not constrain activity decomposition

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

Accept.

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

Resolved by 4681 – duplicate

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.

Duplicate Resolved by 4682

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

see below

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.

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

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

see above

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

Accept

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

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

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

Accept

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

accept

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.

see above

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

see above

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

see above

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

Reject. Issue refers to wrong document

"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,

Accept

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.

see above

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

see above

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/

Accept.

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

Accept

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

Accept.

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

Accept.

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

Accept.

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.

see above

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

Accept.

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

Accept

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.

Accept.

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.

Reject (withdrawn).

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

No, SPEM follows UML 1.4 specification. Reject

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

see above

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

see above

The Model stereotype conflicts with the UML Model metaclass.

Accept.

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.

Accept.

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

Accept

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

Resolved by 4673

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.

Accept.

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.

Accept.

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.

Accept

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.

Accept.

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.

Accept

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.

Withdrawn by Pete: reject

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

Reject. SPEM follows UML 1.4 on this point

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 ?

Accept.

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.

see above

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.

Accept a minor change of wording, no extra metaclass.

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.

Accept

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

Accept

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)

Withdrawn by Pete: reject.

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.

Reject

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.

Reject. StructuralFeature and Attribute will not be included

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.

This is a diagrammatic change, with no alteration to the text or metamodel.

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.

No Data Available

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.

This is a change to the specification text, with no change to the metamodel.