Software Process Engineering Metamodel[2]
EPF and the processes built on top of it share a common structure aimed at providing flexibility in supplying processes to users while maximizing reuse of common best practices. IBM has developed this metamodel, currently called the Unified Method Architecture (UMA), as an evolution of current OMG industry standard Software ProcessEngineering Metamodel (SPEM) v1.0.[3] With OMG, IBM and other OMG partners are working on improving UMA to become SPEM 2.0. As SPEM 2.0 stabilizes, EPF is expected to adopt this and other relevant industry standards around software process and software project management.
The metamodel provides a rich process engineering language. Below we will provide a brief overview of five core concepts: method content, delivery processes, capability patterns, categories, and plug-ins. Note that these and other concepts are optional. For example, you can author a process that does not define any tasks (part of the method content), or you can skip organizing method content into categories. Method Content
The method content defines key reusable process building blocks (see Figure A.1):
Figure A.1. Work Products, Roles, and Tasks.Method guidance defines reusable process building blocks. The figure shows that the analyst role is responsible for a number of work products: actor, use case, use-case model, and vision. The analyst also performs a set of tasks: define vision, find and outline requirements, and detail requirements.
Work ProductsWork products can take various shapes or forms, such as the following:
RolesA role describes a set of skills and responsibilities that must be supplied and assumed by a team member. Examples of roles include analyst, developer, and tester. An individual will typically take on several roles at one time and frequently change roles over the duration of a project. For instance, in a specific project you may take on some of the responsibilities of an analyst and all of the responsibilities of a developer. TasksTasks define how to move the project forward by creating or updating one or more work products. The work is performed by one or more people in specific roles, relates to work products as input and output, and is usually defined as a series of steps that involve creating or updating one or more work products. The following are examples of tasks:
GuidanceGuidance provides additional information related to key elements such as roles, tasks, work products, and processes (see following sections). Guidance includes guidelines, templates, checklists, tool mentors, supporting material, reports, and concepts. Delivery Processes
A delivery process describes a complete project lifecycle end to end and will be used as a reference or template for running projects with similar characteristics as defined for the process (see Figure A.2). A delivery process can, for example, provide guidance for a small J2EE project developing a new application, a large package implementation project, or a medium-sized project enhancing an existing application. The delivery process template provides users with a lifecycle, including a suggested iteration pattern. Figure A.2. The Inception Iteration Template in the OpenUP/Basic Delivery Process.On the left the OpenUP/Basic delivery process is represented as a work breakdown structure (WBS). On the right is a graphical depiction of the same information for the Inception iteration template. The WBS editor and graphical editor operate on the same data, ensuring that the two representations remain consistent. The delivery process suggests which capability patterns (see below) to use in each phase. The delivery process also suggests which activities should be assigned and tracked, because managing every task is typically too much overhead. This can be modified to fit the management style and size of the project. It is critical to understand that a delivery process is a template. One cannot know in advance exactly how many iterations a project should use. The number will be determined based on the specific problems and issues the project faces through its lifecycle. Likewise, one cannot know in advance which capability patterns to apply at what time. This question will be answered as current status, mitigated risks, and the goals of the current iteration are assessed. A delivery process, however, is very valuable to a project team, since it conveys what capability patterns and iteration patterns other teams have found useful when working on similar projects. Capability Patterns
A capability pattern is a recurring process pattern that describes a reusable cluster of activities in a common process area. Capability patterns are used as building blocks to assemble delivery processes or larger capability patterns to enable reuse of the key practices they express. Capability patterns aim to accomplish a well-defined objective, for example:
It is also good practice to design a capability pattern to produce one or more generic deliverables, so that the process engineer can select patterns for assembly by deciding which deliverables are required. You can also use capability patterns as a learning tool by describing knowledge for a key area such as a discipline (e.g., requirements management) or a specific technical area (e.g., relational database design). Figure A.3. Capability Pattern in OpenUP/Basic.OpenUP/Basic is constructed from a number of capability patterns. The figure shows a capability pattern for designing, implementing, and testing a scenario or other type of requirement. It comprises five tasks (shown in the central horizontal box on the right side: Design the Solution . . . Run Developer Tests) all performed by a developer. Each task has a set of defined input work products (shown above each task) and produces or updates a set of work products (shown below each task). Categories
A category is a logical grouping of process elements. There are many different types of categories, for example, a discipline, which is used to group related tasks. OpenUP/Basic divides its tasks into the disciplines requirements, architecture, development, implementation, test, and project management. Disciplines are useful for end users to learn about content in a certain domain and for process authors to ensure maximum reuse across capability patterns. Other examples of categories are domains for grouping work products and role sets for grouping roles. You can also define your own categories to create, for example, navigation structures or categorization of content into SEI CMMI levels.[4]
Plug-Ins
A plug-in is a container of any type of method and process content, such as content describing how to use J2EE effectively, how to do packaged application development, or how to use JUnit. It can add, remove, or modify tasks, work products, roles, or guidelines in a process framework. A plug-in contains information about how these process elements are added to capability patterns, delivery processes, and categories. A plug-in can also add, remove, or modify the capability patterns, delivery processes, and disciplines in a process framework. Plug-ins can be exchanged between organizations and project teams, enabling the development of an ecosystem of best practices. |