Understanding the OPEN Process Framework (OPF) Metamodel is critical to understanding OPF, this website, and the repository of over 1,100 free, open-source reusable method components (i.e., classes of process components) that it contains. The metamodel defines the different method components and provides the organizational structure to the repository and this website. For example, the OPF Components part of the primary navigation frame on the left side of this webpage provides links to the core OPF classes of process components. If you understand this webpage, then you will go a long way towards understanding OPF and being able to easily navigate this website.
The following terms and definitions form the foundational concepts
of the OPEN Process Framework (OPF) Metamodel:
| Term | Definition / Description | Modeling Layer |
|---|---|---|
| Process |
the actual performance of work units by real producers to produce work products and provide servicers
during the stages of an actual endeavor
|
Process |
| Process Model |
a model of one or more processes
|
Method |
| Process MetaModel |
a model of process models
|
Framework |
| Process Component |
a component (i.e., cohesive part) of a process that when integrated with other
such components results in an actual process
|
Process |
| Process Component Class --- Method Component |
a class of process components that can be tailored (subclassed)
to construct a method and instantiated when producing a process
|
Framework, Class Library, and Method |
By definition, a metamodel is a model of a model. Because a development method is a model that describes a process (how development actually takes place), a process metamodel is a model that describes process models (i.e., methods). A good process metamodel must have the flexibility to describe all common development methods (from small, simple, agile methods to large and complex development methods) as well as produce appropriate endeavor-specific methods. A good process metamodel should also do this in a consistent standardized way in terms of common concepts and associated terminology. Thus, the key to a good process metamodel is the ability to provide an optimal compromise between flexibility and standardization.
As illustrated in the preceding figure, OPEN views process metamodeling and the associated storage of process component classes and methods as involving the following four horizontal levels and one vertical partition:
The preceding discussion is primarily of interest to methodologists and vendors of process modeling tools.
For the average process engineer, the distinction between approaches is of little consequence. The important
thing is to understand the following standard core classes of process components and the general relationships between
them that help clarify their meanings.
As illustrated in the preceding figure, the OPF class library of reusable method components forms
an inheritance hierarchy of abstract core classes of process components.
As illustrated in the preceding figure, the core process component classes have standard association relationships between them that help to clarify their meanings.
As illustrated in the previous figure, OPF recognizes the following reusable core method components (i.e., classes of process components), which are further subclassed in the following subsections:
As illustrated in the preceding figure, the OPF Metamodel classifies Endeavors as follows:
As illustrated in the preceding figure, the OPF Metamodel classifies Languages as follows:
As illustrated in the preceding figure, the OPF Metamodel classifies Producers as follows:
As illustrated in the preceding figure, the OPF Metamodel classifies Stages as follows:
As illustrated in the preceding figure, the OPF Metamodel classifies Work Products as follows:
For the sake of practicality, this website and repository also organizes work products by the activities that produce them (e.g., requirements work products, architecture work products).
As illustrated in the preceding figure, the OPF Metamodel classifies Work Units as follows:
It is often important to be able to deal with cohesive sets of method components instead of just individual method components. For example, there are so many work products that it is very useful to be able to group them by activity (e.g., management work products and requirements work products). Similarly, individual engineering disciplines (as opposed to the associated activities) such as the discipline of requirements engineering involve not only requirements engineering tasks but also the requirements team, the requirements engineer role, and all of the requirements work products. And producers are often interested in knowing all of the method components with which they are directly involved. In all these cases, we use method component sets consisting of cohesive collections of relevent method components.
A method component set is used to create a named cohesive collection of method components. Although several subclasses of method component sets (e.g., disciplines, producer sets, task sets, and work product sets) are commonly used, methodologists are free to create their own method component sets as needed.
Organized around a single activity, a discipline typically consists of the activity, its associated tasks and techniques, the producers (e.g., teams, roles, tools) that perform them, and the associated work products that they primarily produce. Different disciplines tend to have their own terminologies, books, and conferences.
A producer set consists of all method components of direct interest to a single kind of producer. This includes component producers, tools used, work units performed, and work products manipulated. Producer sets are subclassed into organization sets, team sets, role sets, and tool sets. These can be further subclassed (e.g., into the requirements team set and requirements engineer set).
A task set is used to group all of the tasks related by the single activity. Although some tasks are common to multiple activities (and therefore belong to the common task set, most tasks are unique to a single activity.
A work product set is typically used to group the work products related by the single activity during which they are produced. Most roles performed by people on an endeavor are specific to a single activity (and discipline), persons performing a role are typically interested in only those work products within a single work product set.