Every Process is comprised of an n-level breakdown structure. Core method content provides step-by-step explanations,
describing how very specific development goals are achieved, independent of the placement of these steps within a
development lifecycle. Processes take these method elements and relate them to semi-ordered sequences that are
customized to specific types of projects. Thus, a process is a set of partially ordered work descriptions intended to
reach a higher development goal, such as the release of a specific software system. A process focuses on the lifecycle
and the sequencing of work in breakdown structures.
There are different types of processes: Delivery Process and Capability Pattern.
Delivery Process
A Delivery Processes describes a complete and integrated approach for performing a specific type of development
project. A Delivery Process is a process that covers a whole development lifecycle from beginning to end. A Delivery
Process is used as a template for planning and running a project. It provides a complete lifecycle model with
predefined phases, iterations, and activities that have been detailed by sequencing method content in breakdown
structures. It is defined on the basis of experience with past projects or engagements, and/or the best practice use of
a development or delivery approach. It defines what gets produced, how those items are produced, and the required
staffing in the form of integrated Work, Work Product, and Team Breakdown Structures. For example, a process engineer
can define alternative Delivery Processes for software development projects that differ in the scale of the engagement
and staffing necessary, the type of the software application to be developed, the development methods and technologies
to be used, etc. Although, the Delivery Process aims to cover a whole project, it keeps certain decisions that are too
project-specific open. For example, the breakdown structure defines which Breakdown Elements have multiple occurrences
or is repeatable via its respective attributes, but does not say how many occurrences and how many repeats/iterations
it will have. These decisions have to be done by a project manager when planning a concrete project, project phase, or
project iterations.
Capability Pattern
A Capability Pattern describes a reusable cluster of Activities in common process areas. Capabilities Patterns express
and communicate process knowledge for a key area of interest such as a Discipline and can be directly used by a process
practitioner to guide his work. They are also used as building blocks to assemble Delivery Processes or larger
Capability Patterns ensuring optimal reuse and application of the key practices they express. Examples for Capability
Pattern could be 'use case-based requirements management', 'use case analysis', or 'unit testing'. Typically but not
necessarily, Capability Patterns have the scope of one discipline providing a breakdown of reusable complex Activities,
relationships to the Roles which perform Tasks within these Activities, as well as to the Work Products that are used
and produced. A capability pattern does not relate to any specific phase or iteration of a development lifecycle, and
should not imply any. In other words, a pattern should be designed in a way that it is applicable anywhere in a
Delivery Process. This enables its Activities to be flexibly assigned to whatever phases there are in the Delivery
Process to which it is being applied.
It is a good practice to design a Capability Pattern to produce one or more generic Deliverables. The typical
configuration is that each Activity in the Capability Pattern produces one Deliverable, and the last Task Descriptor in
the Activity explicitly outputs just this Deliverable. This enables the process engineer to select Patterns or just
Activities by deciding which Deliverables are required. It also offers a simple integration approach: an Activity from
a capability pattern is linked to the Phase or Iteration which is required to produce the Activity's Deliverable.
|
