Software Process Engineering Metamodel


Software Process Engineering Metamodel[2]

[2] This section borrows from material contributed by Peter Haumer.

EPF provides flexibility while maximizing reuse of common best practices.


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.

[3] See http://www.omg.org/docs/formal/05-01-06.pdf.

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.


The method content defines key reusable process building blocks (see Figure A.1):

  • Work products. What is produced, or desired outcomes.

  • Roles. Who performs the work.

  • Tasks. How to perform the work.

  • Guidance. Additional information linked to the other method elements.

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 Products

Work products can take various shapes or forms, such as the following:

  • An artifact is a physical piece of information that is used or produced by a software development process. Examples of artifacts include documents such as a vision document or software development plan; models, such as a use-case model or design model; source files; scripts; and a binary executable.

  • A deliverable is one or more work products that are of value to a stakeholder and are packaged for delivery to a stakeholder.

  • An outcome is an intangible work product that is a result or state, such as an installed server, optimized network, or approved funding.

Roles

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

Tasks

Tasks 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:

  • Find and outline requirements. This task is performed by a person taking on the analyst role to identify use cases and key supporting requirements, and define a basic outline for them. The main input is the vision for the project, and the major outputs are outlined requirements.

  • Analyze architecture. This task is performed by a person taking on the software architecture role to come up with a candidate architecture for the system. The major inputs are requirements, including the vision. The major output is a description of the architecture.

Guidance

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


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.


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:

  • Produce a high-level understanding of requirements that have been validated with customers.

  • Detail requirements and in parallel design, implement, integrate, test, and validate a related scenario or use case with the end user.

  • Detail requirements and in parallel design, implement, integrate, and test a related component or capability.

  • Produce a candidate architecture.

  • Create a contract for a commercial off-the-shelf (COTS) solution.

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.


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]

[4] See www.sei.cmu.edu/cmmi/.

Plug-Ins

A plug-in is a container of any type of method and process content.


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.



Agility and Discipline Made Easy(c) Practices from OpenUP and RUP
Agility and Discipline Made Easy: Practices from OpenUP and RUP
ISBN: 0321321308
EAN: 2147483647
Year: 2006
Pages: 98

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net