See FTF report for changes since adoption. Development processes are in many cases not only represented as models, but documented and managed as natural language descriptions. For many software development approaches and methods human consumable documentation providing understandable guidance for best development practices is more important than precise models. In other words, the practicality of techniques and methods expressed with these practices is in many cases perceived to provide higher value than strict obedience to a formally defined process. The reasons for this are that many development approaches see software development rather as a creative process that requires constant reevaluation and adoption than a strict sequence of activities. For example, for modern agile development teams, best practices of software development are communicated through mentoring and short practice descriptions in white paper format, rather than formally defined models. They assume certain values and a development culture that cannot be formalized with models, but can only be captured in natural language documentation. The Managed Content meta-model package introduced concepts for managing the textual content of such descriptions. These concepts can either be used standalone or in combination with process structure concepts. For example, a SPEM 2.0 based process could be solely comprised of a set of instances of the guidance meta-class defining development best practices in whitepaper format. It could also be comprised of a combination of these guidance elements with a process structure using relationships defined in the Managed Content meta-model package that allows associating guidance elements with process structure elements. Content Description is a Class that is used to store the textual description for a Describable Element. It defines standard attributes applicable for all Describable Element subtypes. Implementers of this specification can subclass Content Description to define their own matching Content Description subtypes that add user-defined description attributes to all instances of a specific Describable Element’s Content Description. Additionally, user-defined attributes can be added to individual Content Description instances when the SPEM 2.0 meta-model is instantiated creating UML 2.0 attributes for the Content Description class accessible via the ownedAttribute inherited from Class. Content Descriptions are typically localized using a resource allocation mechanism for its String type attributes. Every Describable Element described by a Content Description has a name (inherited from Named Element in UML 2.0 Infrastructure), which is used for internal references of the element. In addition to name every Describable Element can maintain a presentation name as part of the Content Description, which is the externally visible/published name of the element, which might be localized. Every Describable Element shall be briefly described with one or two sentences summarizing the element. This attribute stores the main descriptive text for the Describable Element. All text that is not part of any of the more specific attributes shall be stored here. If the description is divided into sections using the Section class, then only the text from the ‘head’ of the content description to the first section will be stored here (similar to a normal document where you can place text between its beginning and its first section heading). This attribute summarizes the main reason or rationale for having or performing this Describable Element as part of a Process or Method. It describes what is intended to be achieved with it and why the Process Practitioner should include it. A Content Description can optionally be structured into Sections. This association is use to decompose the mainDescription attribute into a hierarchy of Sections. Text stored in mainDescription when Sections are defined represents text presented before the first Section. Guidance is a Describable Element that provides additional information related to Describable Elements. The particular Guidance should be classified with Kinds (Section 8.2) that indicates a specific type of guidance for which perhaps a specific structure and type of content is assumed. Examples for Kinds for Guidance are Guidelines, Templates, Checklists, Tool Mentors, Estimates, Supporting Materials, Reports, Concepts, etc. A Category is a Describable Element used to categorize, i.e. group any number of Describable Elements of any subtype based on user-defined criteria. Because Categories are Describable Elements themselves they can be used to recursively categorize other Category instances as well. Categories can also be nested using the subCategory association. Categories can be used to categorize content based on the user's criteria as well as to define whole tree-structures of nested categories allowing the user to systematically navigate and browse method content and processes based on these categories. For example, one could create a Category to logically organize content relevant for the user's development organization departments; e.g. a "Testing" category that groups together all Roles, Work Products, Tasks, and Guidance elements relevant to testing. Another example would be Categories that express licensing levels of the content, grouping freely distributable method content versus content that represents intellectual property and requires a purchased license for use. Whereas Kinds are limited to one Kind instance per meta-model instance and stored as properties of the Extensible Element, Categories store the relationships to Describable Elements. Describable Elements can be categorized by as many Categories as needed. Categories can categorize Categories as well as well as can be hierarchical. Describable Element is a Extensible Element that represents an abstract generalization for all elements in SPEM 2.0 that can be documented with textual descriptions. Examples for Describable Elements are Roles or Work Products, which have descriptive text associated that textually define the element as well as providing guidance on how to use it. Describable Element is the superclass for elements in Process Structure as well as Method Content for which concrete textual descriptions are being defined in the form of documenting attributes grouped in a matching Content Description instance. Describable Elements are intended to be published in method or process publications. Describable Element defines that the element it represents will have content ‘attached’ to it. Content Description is the abstraction for the actual places in which the content is being represented. This separation allows a distinction between core model elements describing the structure of the model from the actual description container providing, for example, the documentation of the Describable Element in different alternatives languages, audiences, licensing levels, etc. A Section is a special Class that represents a structural subsection of a Content Description’s mainDescription attribute. It is used for either large scale documentation of Describable Elements organized into sections as well as to flexibly add new Sections to Describable Elements using contribution variability added to the Section concept for Method Plug-ins. This attributes stores the name or the header of the section. This attribute stores the description text for a Content Description’s Section. A Metric is special Guidance that contains one or more constraints that provide measurements for any Describable Element. Because Metric is Guidance, different Kinds (Section 8.2) can be defined for Metrics to distinguish different groups of Metrics such as Productivity, Quality, or Scale. A Metric defines a standard measurement for instances of a Describable Element in SPEM 2.0. For example, a process engineer can define Metrics for Work Definitions such as Activities (estimated effort in man hours), Metrics for Work Products (quality averages such as error per klocs), or Metrics for Roles (costs per hour; cost per delivered results). A Metric is documented with Content Descriptions associated to the Metric as well as formalized using instances of the UML 2.0 Constraint class. Metrics can be qualified with Kinds. A Metric defines one or more Constraints. The property subsets the inherited ownedRule property from UML 2.0 Infrastructure’s Namespace. A Category can have any number of Categories defined as sub-categories. Therefore, one could define Categories as n-level hierarchies. This relationship does not define a strict nesting, i.e. a Category can be a subcategory of many other Categories. A Describable Element can be related to many Guidance elements. A Describable Element can contain one Content Description element that stores textual descriptions for this Describable Element. A Category groups together any number of Describable Elements (including other Categories). A Content Description can optionally be structured into Sections. This association is use to decompose the mainDescription attribute into a hierarchy of Sections. Text stored in mainDescription when Sections are defined represents text presented before the first Section. Sections can be further decomposed into n levels of sub-sections. A Metric defines one or more Constraints. The property subsets the inherited ownedRule property from UML 2.0 Infrastructure’s Namespace. The concepts of the Process Structure package represent a process as a static breakdown structure allowing nesting of activities and defining predecessor dependencies amongst them. The Process Behavior meta-model package allows extending these structures with behavioral models. However, it does not define it own behavior modeling approach, but rather provides 'links' to existing externally defined behavior models enabling reuse of these approaches from other OMG or third party specifications. For example, a process defined with the Process Structure concepts can be linked to UML 2 Activity diagrams that represent the behavior of such process. Such process models can utilize the SPEM UML 2 Profile for a consistent presentation for such UML 2 models in addition to the 'links' defined in this Process Behavior meta-model package. The State_ext represents a reference to a model class in an external behavior model representing a state. The Transition_ext represents a reference to a model class in an external behavior model representing a transition between states. The ControlFlow_ext represents a reference to a model class in an external behavior model representing a control flow. The Activity_ext represents a reference to a model class in an external behavior model representing a definition of behavior. External Reference is a Classifier that represents an abstract generalization of all classes representing references to external behavior models. Given that an instance of Work Product Definition or Work Product Use has been specified as output for a specific Work Definition, then the Exist State attribute specifies the desired state of instances of the referenced work product instances when work on the Work Definition is finished. Given that an instance of Work Product Definition or Work Product Use has been specified as an input for a specific Work Definition, then the Entry State attribute specifies the desired state of instances of the referenced work product instance when work on the Work Definition is initiated. For some Work Products Definition or Uses, state is expressed in percentage of completion, compliance to work product checklist, informal state descriptions, etc. Others have very specific states expressed as enumerations such as [identified, briefly described, outlined, detailed] for use cases. Other Work Product states relate to some quality measures or lifecycle states such as [reviewed, implemented, tested]. This package extends the Work Definition Parameter class introduced in the Core package with associations to entry and/or exist states for its Work Product Use or Work Definition parameter values. Given that an instance of Work Product Use has been specified as output for a specific Activity, then the Activity Exist State attribute specifies the desired state of instances of the referenced Work Product Use instances when work on the Activity is finished. Given that an instance of Work Product Use has been specified as an input for a specific Activity, then the Activity Entry State attribute specifies the desired state of instances of the referenced Work Product Use instance when work on the Activity is initiated. For some Work Products Uses state is expressed in percentage of completion, compliance to work product checklist, informal state descriptions, etc. Others have very specific states expressed as enumerations such as [identified, briefly described, outlined, detailed] for use cases. Other Work Product states relate to some quality measures or lifecycle states such as [reviewed, implemented, tested]. This package defines the base for all process models. It supports the creation of simple and flexible process models. Its core data structure is a breakdown or decomposition of nested Activities that maintain lists of references to performing Role classes as well as input and output Work Product classes for each Activity. In addition it provides mechanism for process reuse such as the dynamic binding of process patterns that allow users assembling processes with sets of dynamically linked Activities. These structures are used to represent high-level and basic processes that are not textually documented and ideal for the ad-hoc assembly of processes especially the representation of agile processes and self-organizing team approaches. Process Elements is an Extensible Element that represents abstract generalization for all elements that are part of a SPEM 2.0 Process. Breakdown Element is an abstract generalization for any type of Process Element that is part of a breakdown structure. It defines a set of properties available to all of its specializations. Any of its concrete subclasses can be ‘placed inside’ an Activity (via the nested Breakdown Element association) to become part of a breakdown of Activities as well as the Activities namespace. As Activities are Breakdown Elements themselves and therefore can be nested inside other activities, an n-level breakdown structure is defined by n nested Activities. In addition to Activities other Breakdown Elements can be nested inside Activities as leaf elements of the breakdown. The hasMultipleOccurrences attribute expresses that if set to ‘true’ then when the process is enacted that the respective Breakdown Element typically will occur in more than one instance (i.e. more than one instance for the Breakdown Element instance). This might provide important guidance for creating plans from a Process. For example, a Work Definition such as “Detail Use Case” would be performed for every use case identified for a particular Iteration or Activity. Generating a plan would list one Work Definition instance per use case each listing a different use case instance as the input/output. In contrast to the isRepeatable attribute defined for Work Breakdown Element the hasMultipleOccurrences attribute does not assume any dependencies amongst the occurrences of the Breakdown Element. For example, the “Detail Use Case” Work Definition occurrences mentioned above can be performed in parallel as well as one after the other. The isOptional attribute indicates that the Breakdown Element describes work, a work product, or even work performer, which inclusion is not mandatory when performing a project that is planned based on a process containing this element. An Activity is a Work Breakdown Element and Work Definition that defines basic units of work within a Process. It relates to Work Product Use instances via instances of the Process Parameter class and Role Use instances via Process Performer instances. Activity supports the nesting and logical grouping of related Breakdown Elements forming breakdown structures. The concrete breakdown structure an Activity defines (i.e. its contained elements) can be reused by another Activity via the used Activity association, which allows the second Activity to inherit its complete sub-structure. Activity is a concrete Work Definition that represents a general unit of work assignable to specific performers represented by Role Use. An Activity can rely on inputs and produce outputs represented by Work Product Uses. Activity also represents a grouping element for other Breakdown Elements such as Activities, Method Content Uses, Milestones, etc. It is not per-se a ‘high-level’ grouping of only work as in other meta-models, but groups any kind of Breakdown Elements. For example, one can define valid Activities that group only Work Product Uses without any matching Role Uses or Parameters. Such a structure expresses the information that the Activity requires work on these Work Products, without specifying how and who providing the flexibility required for modeling partial or Agile processes. Activity instances can inherit, contribute, or replace properties from other reused activities. The semantics for the three kinds of reuse defined are specified for Activity Use Kind. This attribute is set to a value of the enumeration Activity Use Kind other than its default "na" when the Activity instance is associated to another Activity via the useActivity association for reuse. The value of the attribute of the Activity of the to-many end defines the semantics of the association according to the definitions in Activity Use Kind. This association represents breakdown structure nesting. It defines an n-level hierarchy of Activities grouping together other Breakdown Elements such as other Activities, Milestones, etc. This association defines a reuse generalization for Activities according to the semantics defined for Activity Use Kind. Activity instances on the to-many end of the association can reuse properties of the Activity instance on the to-one end (base) of the association. The association property subsets the ownedWorkDefinitionParamter of Work Definition. The suppressed association allows hiding any Breakdown Element from the interpretation of a process structure. It is used in combination with the usedActivity association for elements that are inherited by usedActivity. The reusing activity can define its own local elements that refer to the base activity’s element to denote the suppression (see Activity Use for more details). A Milestone describes a significant event in a development project, such as a major decision, completion of a deliverable, or meeting of a major dependency (like completion of a project phase). Because, Milestone is commonly used to refer to both the event itself and the point in time at which the event is scheduled to happen, it is modeled as a Breakdown Element (i.e. it appears as part of a breakdown structure). A Role Use is a special Breakdown Element that either represents a performer of an Activity or a participant of the Activity. If it is a performer the Role Use and Activity need to be related via a Process Performer. If it is a participant then the Role Use is stored in the nestedBreakdownElement composition of the Activity and might be used by one of the sub-activities as a performer and/or a Process Responsibility Assignment. Role Uses are only valid within and specific to the context of an Activity and not to be reused across activities. A Role Use represents an activity specific occurrence of an activity performer or participant. A Role Use is an Activity specific object and not a general reusable definition of an organizational role. (The meta-model package Method Content defines a concepts call Role Definition for that). A Role Use represents the occurrence of a real person performing activity-specific work and having activity-specific responsibilities. A Role Use participant stored with an Activity can be only accessed and reused by the Activity’s sub-Activities and not by any parent or sibling Activities in the Activity breakdown structure. This scoping of Role Use in the local namespace of Activities allows to model different Performers as well as different Responsibility Assignments for every Activity, which reflects the fact that work product responsibilities and performance of activities might change throughout the development lifecycle. In other words, Role Use instances with the same name can be created in different Activities, which all have different responsibilities and perform different work. Many processes do not comprise of Role Definitions and just define the occurrence of a role and imply that all team members know what the Role Use represents (e.g. by just interpreting the Role Use name). In these situations fitting individuals for the Role Uses are assigned when the process is enacted. Assigning Role Uses in such a way is also often referred to as ‘self-organizing’ teams in which team members choose by themselves or via their managers which roles they play during development. A Work Product Use is a special Breakdown Element that either represents an input and/or output type for an Activity or represents a general participant of the Activity. If it is an input/output then the Work Product Use needs to be related to the Activity via the Process Parameter class. If it is a participant then the Work Product Use is stored in the nestedBreakdownElement composition of the Activity and might be used by one of the sub-activities as an input/output and/or be related to a Role Use via a Process Responsibility Assignment. Role Use instances are only valid within and specific to the context of an Activity and not to be reused across activities. A Work Product Use represents an activity specific occurrence of a Work Product input/output type or an Activity participant. A Work Product Use instance is an Activity specific object and not a general reusable definition of a work product. (The meta-model package Method Content defines a concepts call Work Product Definition for that). A Work Product Use represents the occurrence of a real Work Product in the context of an activity. A Work Product Use participant stored with an Activity can only be accessed and reused by the Activity’s sub-Activities and not by any parent or sibling Activities in the Activity breakdown structure. This scoping of Work Product Use in the local namespace of Activities allows to model different Responsibility Assignments for every Activity, which reflects the fact that work product responsibilities might change throughout the development lifecycle. In other words, Role Use instances with the same name can be created in different Activities, which all have different Work Product Use responsibilities. Many processes do not comprise of Work Product Definitions and just define the occurrence of a work product and imply that all team members know what the Work Product Use represents (e.g. by just interpreting the Work Product Use name). For example a process might define that Stakeholder Requests need to be captured, but does not formally define what a Stakeholder Request is nor prescribes any templates or forms for them. Team members could choose by themselves which form of representation they choose as well as shift responsibilities for the Work Product during the lifecycle phases (i.e. activities). Work Sequence is a Breakdown Element that represents a relationship between two Work Breakdown Elements in which one Work Breakdown Elements depends on the start or finish of another Work Breakdown Elements in order to begin or end. The Work Sequence class defines predecessor and successor relations amongst Work Breakdown Elements. This information is in particular critical for use of the process in planning applications. This attribute expresses the type of the Work Sequence relationship by assigning a value from the Work Sequence Kind enumeration. A Work Breakdown Element is a special Breakdown Element that provides specific properties for Breakdown Elements that represent work. The properties are specific to breakdown structures and do not apply to all Work Definition subclasses, though. Work Breakdown Element represents a work specific breakdown element to be used in a work breakdown structure. This attribute is used to define repetition of work, e.g. iterations. A Work Breakdown Element with this attribute set to True shall be repeated more than once on the same set of artifacts. For example, if one wants to model that a specific Activity instance shall represent an iteration in a process then this attribute shall be set to true indicating that the Activity and therefore all of its sub-Activities will be performed more than once. The difference to the hasMultipleOccurrences attribute defined for Breakdown Element is that Work Breakdown Elements with the isRepeatable flag will be performed one after the other (i.e. not in parallel). For Breakdown Elements with hasMultipleOccurrences set to true this is undefined and up to the project planner. If both attributes are set to true then isRepeatable takes precedence. If the isOngoing attribute is set to true for a Work Breakdown Element instance, then the element describes an ongoing piece of work without a fixed duration or end state. For example, the Work Breakdown Element could represent work of an administrator continuously (e.g. 3h a day) working to ensure that systems are kept in a certain state. Another example would be program management work overseeing many different projects being scheduled for one particular project at specific reoccurring intervals during the whole lifecycle of the project. The isEventDriven attribute indicates that the Work Breakdown Element describes an instance of work which is not started because it has been scheduled to start at a certain point of time, because preceding work is being completed, or input work products are available, but because another specific event has occurred. Examples for such events are exceptions or problem situations which require specific work to be performed as a result. Also change management work can be modeled as event driven work analyzing a change request or defect and allocating work dynamically to resources to deal with it following the work described with such Work Breakdown Element. The events themselves are not modeled in this version of the specification. They shall be described as part of the normal descriptions fields available. A Process Parameter is a Work Definition Parameter used for process definitions. It defines input and output meta-types to be Work Product Uses. This association links zero or one Work Product Use instances to a parameter. Processes could leave the type specification open and not specify a concrete Work Product Use. A Process Performer is a Breakdown Element and Work Definition Performer that represents a relationship between Activity instances and Role Use instances. An instance of Process Performer links one or more Role Use instances to one Activity. (Modeled as 0..1 Activities because the Process with Methods meta-model package will add an alternative class to Activity.) The Process Performer links Role Uses to Activities indicating that the Role Use participated in the work defined by the activity in one or another way. The kind of involvement of the Role Use in the Activity needs to be defined by a Kind class instances that qualifies the Process Performer instances. Typical examples for Kinds of Process Performers would be Primary Performer, Additional Performer, Assisting Performer, Supervising Performer, Consulted Performer, etc. The popular RACI-VS diagram defines another set of commonly used Kinds for the Process Performer: Responsible, Accountable, Consulted, Informed, Verifies and Signs. A Process Performer links to zero or one Activity via this association. The linked Activity property subsets the linked Work Definition property from the Work Definition Performer defined in Core. A Process Responsibility Assignment is a Breakdown Element that represents a relationship between instances of Role Use and Work Product Use. An instance of the Process Responsibility Assignment links one or more Role Use instances to exactly one Work Product Use. The Process Responsibility Assignment links Role Uses to Work Product Uses indicating that the Role Use has a responsibility relationship with the Work Product Use. The Kind of responsibility of the Role Use for the Work Product Use needs to be defined by Kind class instances that qualify the Process Responsibility Assignment. The popular RACI-VS diagram defines a set of commonly used Kinds which cannot only be applied for the Process Performer, but also often used for work product responsibility: Responsible, Accountable, Consulted, Informed, Verifies and Signs. Note, that for many processes the Process Performer and Process Responsibility represent two quite different sets of information as a Role Use can be involved in an Activity that modifies a work product without being responsible for the Work Product itself and vice versa: A Role Use can be responsible for a Work Product Use without participating an all the Activities that modify it. Other processes might chose to only use one of these relationships. For example, there are processes for self-organizing teams that actually do not define detailed Activities describing which Role Use performs which work. These approaches might just utilize the Process Responsibility Assignment to express that a Role Use has a certain responsibility, but that the process does not prescribe how that responsibility is achieved. In such a case the Kinds defined might express work product states such as ‘detailed’, ‘implemented’, ‘documented’, ‘reviewed’ and so on. A Process Responsibility Assignment links to exactly one Work Product Use. A Process Responsibility Assignment links to one or more Role Use. A Work Product Use Relationship expresses a general relationship amongst work products. Kind class instances shall be used to specify the nature of this relationship. The Work Product Use Relationship can be used to express different kinds of relationships amongst Work Products Uses. Typical Kinds are ‘composition’ expressing that a work product use instance of an instance is part of another work product instance of an instance. For example, an instance of Actor is part of an instance of Use Case Model. In contrast to composition another Kind could express ‘aggregation’ indicating that a Work Product Use is used with another Work Product Use. For example, a customer design deliverable could be defined as a compilation of different other work product uses that are assemble as a report that is delivered to the customer for review. A third key Kind is ‘dependency’ indicating that a work product use impacts another work product use. For example, if a use case model work product changes the use case realization work product needs to be updated with these changes. Work Sequence represents a relationship between two Work Breakdown Element in which one Work Breakdown Element (referred to as (B) below) depends on the start or finish of another Work Breakdown Element (referred to as (A) below) in order to begin or end. This enumeration defines the different kinds of Work Sequence relationships available in SPEM 2.0 and is used to provide values for Work Sequence's linkKind attribute. Work Breakdown Element (B) cannot start until Work Breakdown Element (A) finishes. For example, if you have two Work Breakdown Elements, "Construct fence" and "Paint fence," "Paint fence" can't start until "Construct fence" finishes. This is the most common type of dependency and the default for a new Work Sequence instance. Breakdown Element (B) cannot finish until Work Breakdown Element (A) finishes. For example, if you have two Work Breakdown Elements, "Add wiring" and "Inspect electrical," "Inspect electrical" can't finish until "Add wiring" finishes. Breakdown Element (B) cannot start until Work Breakdown Element (A) starts. For example, if you have two Work Breakdown Elements, "Pour foundation" and "Level concrete," "Level concrete" can't begin until "Pour foundation" begins. Breakdown Element (B) cannot finish until Work Breakdown Element (A) starts. This dependency type can be used for just-in-time scheduling up to a milestone or the project finish date to minimize the risk of a Work Breakdown Element finishing late if its dependent Work Breakdown Elements slip. If a related Work Breakdown Element needs to finish before the milestone or project finish date, but it doesn't matter exactly when and you don't want a late finish to affect the just-in-time Work Breakdown Element, you can create an SF dependency between the Work Breakdown Element you want scheduled just in time (the predecessor) and its related Work Breakdown Element (the successor). Then if you update progress on the successor Work Breakdown Element, it won't affect the scheduled dates of the predecessor Work Breakdown Element. This enumeration defines the nature of the reuse for an Activity that relates to exactly one other Activity via the used Activity association. Activity Use in SPEM defines the ability to reuse the structures defined for one Activity via its nested Breakdown Element composition in a second Activity without the need to physically copy these structures. Instead Activity Use defines a way to dynamically inherit these structures from the referenced the activity. Such reuse is typically established via an Extension relationship and then further refined using additional local Contribution and local Replacement relationships amongst substructure elements of the extending activities. This is the default value for Activities that do not instantiate the usedActivity association. Extends provides a mechanism for dynamically reusing Activity substructures (elements contained via the nested Breakdown Element composition) in other Activities. Typical applications of Extension are to represent reusable process patterns as activities, which are then dynamically bound to different activities via the Extension use Kind in a larger process. An Activity is linked via extension by defining a usedActivity association instance from an Activity within the Processes to the Activity representing the process pattern and setting the useKind attribute to the Extension value. The source Activity inherits all association instances and sub-structures from the base Activity and the Activity appears to be part of the resulting Process after interpretation of the used Activity association. Local Contribution defines a mechanism for defining specific local additions (or contributions) to breakdown elements inherited via the extension Activity Use Kind within the context of the reusing Activity. Hence, usedActivity relationships of this kind are used in addition to a usedActivity relationship of the kind Extension. For example, an Activity could be defined as a child of a second Activity which defines an extension relationship to a third Activity adding additional new sub-elements (such as new sub-Activities) to the set of sub-elements the second Activity inherited from the third Activity via the extension relationship. Local Replace defines a mechanism for defining local replacements to specific breakdown elements inherited via the Extension Activity Use Kind in the context of the reusing Activity. UsedActivity relationships of this kind are used in addition to a usedActivity relationship of the kind Extension. Instances of this type replace inherited Activity sub-elements with their own sub-elements. For example, an Activity could be defined as a child of a second Activity which defines an extension relationship to a third Activity replacing the inherited sub-elements (such as its sub-Activities), that the second Activity inherited from the third Activity via the extension relationship, with its own set of sub-elements. This association represents breakdown structure nesting. It defines an n-level hierarchy of Activities grouping together other Breakdown Elements such as other Activities, Milestones, etc. A Process Responsibility Assignment links to one or more Role Use. This association links the Work Product Uses instances to a Milestone instance that need to be produced for that Milestone. This association links a Work Breakdown Element to its predecessor. Every Work Breakdown Element can have predecessor information associated to it. This predecessor information is stored in instances of the class Work Sequence, which defines the kind of predecessor another Work Breakdown Element represents for another. This association links a Work Breakdown Element to its successor. Every Work Breakdown Element can have successor information associated to it. This successor information is stored in instances of the class Work Sequence, which defines the kind of successor another Work Breakdown Element represents for another. A Process Performer links to one or more Role Use via this association. This association links zero or one Work Product Use instances to a parameter. Processes could leave the type specification open and not specify a concrete Work Product Use. This association defines a reuse generalization for Activities according to the semantics defined for Activity Use Kind. Activity instances on the to-many end of the association can reuse properties of the Activity instance on the to-one end (base) of the association. A Process Responsibility Assignment links to exactly one Work Product Use. A Process Performer links to zero or one Activity via this association. This composition association manages a list of ordered ProcessParameters for an Activity instance. The suppressed association allows hiding any Breakdown Element from the interpretation of a process structure. It is used in combination with the usedActivity association for elements that are inherited by usedActivity. The reusing activity can define its own local elements that refer to the base activity’s element to denote the suppression (see Activity Use for more details). The Method Plug-in meta-model package introduces concepts for 'designing' and managing maintainable, large scale, reusable, and configurable libraries or repositories of method content and processes. The concepts introduced in this package allow arranging different parts of such a library based on different layers of concern similar to layered software architectures. With concepts such as Method Plug-in, Process Component, and Variability one can define processes that are granularly extended with more and more capabilities. Users can then select the process capabilities they are interested in by defining so-called method configurations. Only those selected capabilities will then be surfaced within these configurations to the end-user allowing process authors to define consistent and maintainable processes for different audiences that are configurable for specific end-user needs. A Method Plugin is a Package that represents a physical container for Content and Process Packages. It defines a granularity level for the modularization and organization of method content and processes. A Method Plugin can extend many other Method Plugins and it can be extended by many Method Plugins. It can also be used stand-alone, i.e. with no Extension relationship to other plug-ins. Content Element in the package Method Plugin inherits from Variability Element and not directly from Method Element anymore. This is achieved using UML 2.0 package merge semantics. Only if an adopter of this meta-model decides to realize Method Plugins, he would get the variability and extension capabilities for all Content Elements. Content Element inherits the semantics of Variability Element. Variability Element is an abstract class derived from Classifier that provides capabilities for content variation and extension to a specific list of SPEM 2.0 classes. It defines a superclass for Activity (Section 9.1), and Section Section (11.6), and Method Content Element (Section 12.4) in the overall SPEM 2.0 taxonomy of classes using the UML 2 package merge mechanism. The association Variability Specialization shall only be instantiated between two subclasses of Variability Element of the same concrete type. The element on varaibilitySpecialElement side of the relationship defines a value for the attribute variabilityType defining the nature of the relationship using a literal from the enumeration Variability Type. Variability Element of the meta-model package Method Plugins adds the capabilities of variation and extension to SPEM Elements that derive from it. Variability provides a mechanism for customizing Variability Elements without actually directly modifying their original structures or textual content, but by just being able to describe with separate objects the differences (additions, changes, omissions) relative to the original. This Method Plugin concept allows users to factor their method content and processes in interrelated units and even to architect method content and processes in layers that extend each other with new capabilities. The resulting method and process design can be dynamically combined and applied on demand using the interpretation rules defined for Variability Element Specializations assembling for process practitioners the most accurate method and process descriptions possible. It also allows process practitioners to extend and tailor method content and processes they do not own and to easily upgrade to newer versions by simply reapply their personal changes to these upgrades. If in instance of the variabilitySpecialization association between two Variability Elements of the same type exists, then the variabilityType attribute specifies how the element at the variabilitySpecialElement end of the association changes the Content Element at the variabilityBasedOnElement end. See the Variability Type enumeration class for definitions for the different types of variability. Section in the package Method Plugin inherits from Variability Element and extends Section defined in Managed Content (Section 11.6) with new capabilities for variability. For example, when a Task Definition contributes to another Task Definition its description association is contributed including its Sections (i.e. its Steps), which are modeled as parts of the Content Description instance. Sections can be nested and therefore the Task Definition’s descriptions can be flexibly organized in Steps with sub-Steps. Sections are Variability Elements themselves, so they can contribute to each other. For example, one could model a Task Definition Step as a Section instance without relating it to a Task Definition’s Content Description that directly contributes to (or replaces) another Section which is part of a Content Description. This contribution (or replacement) would add new description text to the original step description (or replace the original step description). Another example would be to contribute to Guidance; for example contribute new check list items organized as Sections to an existing check list guidance element. This association defines the predecessor for contributed Sections to be inserted into an existing list of Sections of a Content Description. Activity in the package Method Plugin inherits from Variability Element to extend Activity with new capabilities for variability. Activity inherits the semantics of Variability Element which provides key mechanism to enable dynamic modification of Activities in a process from a Method Plugin. A Method Library is a physical container for Method Plugins and Method Configuration definitions. All Method Elements are stored in a Method Library. A Method Configuration is a collection of selected Method Plugins, as well as sub-sets of Method Content Packages and Process Packages of respective Method Plugins. The definition of a configuration can be further refined by subtraction of all Content Elements categorized by a Category associated via the subtracted Category association. A Process Component is a special Process Package that applies the principles of encapsulation. A Process Component contains exactly one Process and defines a set of Work Product Ports that define the inputs and outputs for a Process Component. There might be many components defining the same Work Product Ports, but using different techniques (i.e. Process) to achieve similar outputs for similar inputs. Whereas the Work Product Port represents the component specifications (black box view on the component), good candidates for component realizations can be found in Capability Patterns (white box descriptions for the component). SPEM 2.0 supports replaceable and reusable Process Components realizing the principles of encapsulation. Certain situations in a software development project might require that concrete realizations of parts of the process remain undecided or will be decided by the executing team itself (e.g. in outsourcing situations). Process components support an assembly mechanism that provides that is based on the "black box" principle. At any point during a project the component "realization" detailing the work can be added to the process. The component approach also allows that different styles or techniques of doing work can be replaced with one another. For example, a software code output of a component could be produced with a model-driven development or a code-centric technique. The component concept encapsulates the actual work and lets the development team choose the appropriate technique and fill the component's realization with their choice of Activities that produce the required outputs. A Process Component Use represents a Process Component application in a Process, i.e. the breakdown structure defining the Process. The Process Component Use is used to encapsulate the details of the component in a breakdown structure and to provide its own set of relationships such as it own predecessors and successors. This association links the Process Component Use to used Work Product Ports of the Process Component. A Work Product Port defines the work products input and outputs for a Process Component. It is defined based on exactly one type of Work Product and defines for exactly one Process Component if this Work Product type is to be expected as a required (input) or supplied (output) by the Process Component. It also specifies if this input or output is optional or not. This attribute defines if the port represents and input or output Work Product. This attribute specifies if the port represents a mandatory or optional Work Product input or output. A Work Product Port Connector is used to connect Work Product Ports for assembling Process Components. This association connects many Work Product Ports with many other Work Product Ports. Method Library Element is an abstract generalization for Method Plugin and Method Configuration supporting the redefinition of the packagedElement association of Method Library inherited from the UML 2 class. Method Library Packageable Element represents an element that can be packaged in a Method Library. It prevents SPEM 2.0 user from nesting Method Libraries. Method Plugin Element is an abstract generalization for Method Content Package and Process Package supporting the redefinition of the packagedElement association of Method Plugin inherited from the UML 2 class. Method Plugin Packageable Element represents an element that can be packaged in a Method Plugin. It prevents SPEM 2.0 user from nesting Method Plugins. Variability Type is an Enumeration used for values for instances of Variability Element's attribute variabilityType. It defines the nature of how a Variability Element extends another Variability Element. See enumeration literals for definitions for each type. This is the default "not assigned" value of a Variabillity Element's variabilityType attribute which is set in the case no variability association is present between the Variability Element and other Variability Elements. Contributes provides a way for instances of Variability Elements to contribute their properties into their base Variability Element without directly altering any of its existing properties, i.e. in an additive fashion. Properties contributed are: attribute values and association instances. The effect after interpretation of contribution is that the base Variability Element is logically replaced with an augmented variant of the element that combines attribute values and association instances. The way this combination is realized depends on the type of the attribute or association. For example, String attributes are concatenated resolving embedded commands for dependent text or merging text fragments (e.g. descriptions for content elements). Additional elements in to-many associations are added (e.g. additional Guidance elements or Task Descriptors of an Activity). Different elements in to-one associations are ignored (e.g. the one Primary Performer of a Task). Multiple Content Elements can contribute to the same base element and all of these contributions properties are added to the base in the same fashion. The following table provides the detailed list of interpretation rules: attribute values: String values from the special Variability Element are concatenated with values from the based-on Variability Element. Other values from the special Variability Element of any other type such as Integer, Date are ignored. The identifying attributes guid and name of Method Element are exempt from this rule and will not be modified. 0..1-association instances: The one association instance of the based-on Variability Element is kept and any association from the contributing special Variability Element is ignored. 0..n-association instances: Association instances of the special Variability Element are added to the already existing association instances of the based-on element. If both Variability Elements refer to the same object then only one instance of the association will remain. Extension allows Method Plugins to easily reuse elements from a Base Plugin by providing a kind of inheritance for the special Variability Element. Attribute values and Association instances are inherited from the based-on Variability Element to the special Variability Element. The result of interpretation is that the special element has the same properties as the based-on has, but might override the inherited properties with its own values. Hence extends is not used to modify content of the base Plugin, but to provide the ability for the extending Plugin to define its own content which is a variant of content already defined (e.g. a special version of a generic Review Record for a specific type of review). The effect of this is that the base Variability Element and any number of extending Variability Elements can be used side by side, but refer to each other via the extends relationship. Extends also provides the key mechanism for binding Capability Patterns to Processes: A pattern is applied by defining an extends relationships from an Activity of the applying Processes to the Pattern. The Activity inherits associations instances from the pattern and the pattern appears to be part of the resulting Process after Interpretation. attribute values: Values from the based-on Variability element are inherited and used to populate the special Variability Elements attributes. If the special element attributes are already populated the inherited values are ignored. The identifying attributes guid and name of Method Element are exempt from this rule and will not be modified. 0..1-association instances: The one association instance of the based-on Variability Element is inherited to the special Variability Element. If the special Variability Element defines its own association instance then the inherited one is ignored. 0..n-association instances: Association instances defined for the based-on Variability Element are inherited to the special Variability Element. If the special Variability Element defines its own association instances, then the inherited ones are ignored.