Object-oriented Process, Environment, and Notation (OPEN) is the premier third-generation, public domain, full lifecycle, process-focussed, methodological approach that was designed for the development of software intensive applications, particularly object-oriented and component-based developments. OPEN was developed and is maintained by the not-for-profit OPEN Consortium, an international group of over 35 methodologists, academics, CASE tool vendors and developers. OPEN was initially created by the merger of earlier methods: MOSES, SOMA, Firesmith, Synthesis and more recently enhanced by state of the art ideas from BON, Ooram, UML etc.

OPEN is defined as a process framework, known as the OPF (OPEN Process Framework). This is a process metamodel from which can be generated an organizationally-specific process (instance). Each of these process instances is created by choosing specific Activities, Tasks and Techniques (three of the major metalevel classes – see below) and specific configurations thereof. This is process construction. Process tailoring may also be needed whereby details of the Tasks and Techniques are “tweaked” for optimum fit to the problem domain.

OPEN thus provides flexibility. Derived from the metamodel-based framework, an OPEN process can be tailored to suit individual domains or projects taking into account personal skills, organizational culture and requirements peculiar to each industry domain. Consequently, while OPEN is a process framework, it can be regarded, more loosely, as a family of processes. On both counts, it is a highly flexible componentized methodological approach to building software and software intensive systems as well as offering support for business modelling. OPEN supports not only a use case driven approach but also a responsibility driven approach, a document driven approach and so on. It supports equally a translational approach versus an elaborational approach.

OPEN’s flexibility also permits it to be used on small projects and large, mission critical projects – not with the same process instance of course but with specifically engineered instances of OPEN. It can be used on rapid turnround web developments which may have short lifetimes or on business core software that must be of high and enduring quality.

OPEN provides strong support for the full lifecycle of a software application. It has an embedded project management and reuse framework; it supports business process modelling; offers guidelines on migration strategies and supports links to human relations issues. A prime concern of OPEN is software quality and the use of metrics. To that end, close links with quality frameworks including the Software Engineering Institute’s Capability Maturity Model are maintained and supported, and links to the new OOSPICE software process improvement project are strong.


Although there are many metaclasses in the OPF, they mostly cluster into five groups: Work Units, Work Products and Producers with support from Stages and Languages (Figure 1). These form a component library for OPEN from which individual instances are selected and put together, constructor set fashion, to create a specific instance of OPEN. Since you, the developer organization, have selected these components, you are confident that they conform fully to your requirements. In addition, the way these elements are put together is also your decision. If you wish to take advantage of a fully iterative, incremental and parallel (IIP) lifecycle model, then you use the supplied Assertions to sequence elements of the process to express your IIP needs. On the other hand, if you prefer more of a waterfall approach, then this too is easily constructed using more stringent constraints on the ordering of what are known as Activities (representing goals to be achieved) within the OPF. Activities, along with Tasks and Techniques, are all kinds of Work Units defined by the OPF. Activities state what needs to be done but not how. Tasks are similarly aimed at the what not the how but in this case are finer grained. They can be accomplished by a single developer or a small development team in a relatively short time and can be adjudged by the project manager to be complete (or not complete). Making these goals (of Tasks and Activities) achievable requires actions of an individual or a team, referred to as a Producer in the metamodel of the OPF. Producers may be human or non human and may be individuals or teams. They work utilizing one or more Tasks with the Techniques in order to produce the Work Products.

Thus the focus in OPEN, as shown in Figure 1, is the synergistic interaction between Producers (typically people), the things they do (Work Units) and the things they produce (Work Products). For a software development organization, it is generally the last, Work Products, for which they get paid! – although this would not be possible without the Producers and some knowledge of how to build software (as described in the various Work Units).

Outside the main trio, Stages and Languages (Figure 1) provide additional support. There are various kinds of stages, such as phase, life cycle, milestone which are used to give largescale organization (often in time) to the development process. On the other hand, languages, be they natural languages, modelling languages or coding languages, are needed as “tools” by which to help document many of the work products. OPEN supports both the UML notation, the OML notation and any other good OO notation of your choice in order to document the work products that the OPEN process produces.

Figure 1 The components of the OPEN process framework (after Firesmith and Henderson-Sellers, 2000)


The OPEN Process Framework provides a cohesive class library of predefined components that can be extended, instantiated and tailored for use on a specific project. As we saw above, these components are of the following five main types (Figure 1):

Work Products, the components that are developed by the project.
Languages, the components used to document most work products.
Producers, the components that develop work products.
Work Units, the components that model the operations performed by producers when developing work products.
Stages, the time intervals that provide a macro organization to the work units.
We now discuss briefly each of these five component types in turn.

Work Products

The primary objective of any development process is to develop one or more related products. A work product is any significant thing of value (e.g., document, diagram, model, class, application) that is developed during a project. One or more producers develop a work product during the performance of one or more work units.


A language is the medium used to document a work product. For example, documents are mostly written in a natural language such as English. Use case and object models are written using a modelling language such as the Unified Modeling Language (UML) or the OPEN Modelling Language (OML). Finally, code is written in an implementation language such as Java, Structured Query Language (SQL), or using CORBA’s Interface Definition Language (IDL).

OPEN can be (and has been) used in OO/CBD developments using various languages and is as appropriate if you are using Java, C++ or OO COBOL. Similarly, the modelling and constraint languages used are also flexible within the OPF.


A producer is anything that produces (i.e., creates, evaluates, iterates, or maintains), either directly or indirectly, versions of one or more work products. The OPF distinguishes between those direct producers (persons as well as roles played by the people and tools that they use) and indirect producers. This second category consists of teams of people (the membership of teams strictly being roles), organizations (the membership of which are teams) and endeavours. An endeavour is staffed by one or more organizations. Endeavours, in turn, may be classified as either projects, programmes or enterprises.

Work Units

The OPF defines a work unit as a functionally cohesive operation that is performed by a producer during an endeavour and that is reified as an object to provide flexibility during instantiation and tailoring of a process.

The OPF provides the following predefined classes of work units:

Task performance

Activities are generally large-scale descriptions of what is to be done. They are long-term objectives but are difficult to manage because of their potential duration. To manage the “what”, a finer discrimination is needed. In project management, a Task is the smallest unit of work that can be evaluated as either complete or not complete. Tasks are thus smaller scale “jobs to be done” associated with each of the activities in the lifecycle. But tasks don’t say “how” the jobs are to be done. This is the role of the Technique. The technique describes in full detail how we might use object technology, object-oriented concepts and years of experience of users to accomplish the Tasks we have set ourselves. Finally, for any given producer, a workflow is usually created as a sequence of tasks to be performed.

Since techniques are just ways of doing things, they can be thought of as the “tools of the trade”. Just as the tools of the trade of a plumber include hammers, screwdrivers and wrenches, the tools of an object technologist include knowledge about the use of, for instance, CRC card modelling, aggregation modelling and OO team building. Just as the value of a plumber is the knowledge and experience in choosing which of the screwdrivers and wrenches are needed to solve any particular problem, a skilled object technologist is one who is able to choose the best OO technique to accomplish the specific OPEN Task being worked on. Choosing the correct technique is largely a matter of experience, real or surrogate

Tasks and Techniques

The OPF defines a task as a functionally cohesive operation (reified as a work unit) that is performed by a direct producer (role or tool). A single responsibility of the producer will be fulfilled by the execution of one or more tasks. A task results in the creation, modification, or evaluation of a version of one or more work products.

An example of a task and associated techniques include:

Role: OO Modeler:
Task: Identify Classes – can be performed using the following techniques:
Reify domain concepts
Reify nouns as classes (i.e., perform lexical analysis)
Reify externals as interfacer classes
Reify states using the State Pattern
Reify operations using the Command Pattern
Reify transactions
Full details are to be found in other books in the OPEN series (see Bibliography).

Task Performances

The OPF defines a task performance as the combination of a producer and the task that they are responsible for. This emphasizes that it is not just the task that is important to model but the interaction of the task and its performer (the producer). Task performances provide the basis for the workflow concept (q.v.). They bring together synergistically the human side (in producer) and the technical side (the task).


The OPF defines an activity as a major work unit consisting of a cohesive collection of workflows that produce a related set of work products. Activities in OPEN are coarse granular descriptions of what needs to be done. If this were a waterfall process (which it isn’t) these Activities might be equated to Phases. The Activities identified at this high level for OPEN are, in many senses, fairly traditional. They include, but are not restricted to Project initiation, Requirements engineering, Analysis and model refinement, Project planning, Build (Evolutionary development or OOA/OOD/OOP together with verification and validation (V&V); User review and Consolidation), Evaluation and Implementation Planning including Implementation (or Deployment).

Which of these activities (and sub-activities within them) you choose depends on a number of things such as the size of the project, the maturity level of the organization and the safety criticality aspect of the system. For example, for small projects undertaken by a small number (1 or 2) of people, you will probably not have a Project Planning activity and even the Requirements Engineering activity may be absent, particularly if you, the developer, are also the user so that the requirements are in your head.


A stage is a formally identified and managed duration or a point in time. Stages provide a macro organization to the work units. The OPF contains the following predefined classes of stage:

(a) Stage with Duration

(b) Instantaneous Stage

Let us now consider each of these kinds of Stage in turn.


There are several types of cycle e.g. a development cycle, a delivery cycle and various kinds of lifecycle. The term “life cycle” is used to describe a sequence of phases that cover the extent of the temporal existence of whatever is being described. Thus a project development life cycle describes the duration over which the project is conceived and constructed (called, together, “development”). The project life cycle, on the other hand, includes not only the project development life cycle but extends far beyond it, including the duration of the software product, use on site and ended when the software becomes redundant and is no longer used. Delivery lifecycles focus on the repetitive nature of delivering product versions to customers.

At a larger scale than project lifecycles, there are cycles relative to programmes (of projects) i.e. multiple project considerations such as domain analysis and reuse strategies. Thus we can describe the programme life cycle as consisting of the sum of all the project life cycles plus a Strategy Phase in which high level business planning across all projects is undertaken.

We noted much earlier that OPEN is useful not only for software and software intensive systems but also for business modelling at the enterprise scale. OPEN thus describes a further type of life cycle, the enterprise life cycle in which business modelling and business re-engineering occur.

Each of these life cycles can be broken down into a number of phases, as described below.


A phase is a stage (with duration) of development consisting of a sequence of one or more related builds, releases and deployments. The OPF provides four classes of phases within the project life cycle:

Inception is the phase during which the endeavour is started and preparation for development is made.
Construction is the phase during which the work products are developed and prepared for release.
Usage is the phase during which the work products are released to the user organization and placed into service.
Retirement is the phase when the software is withdrawn from service. This is likely to result in strategies for switchover to a new system, checks for other software dependent upon this obsolete software and so on.
and one phase which is part of the programme lifecycle:

Strategy is the phase in which cross-project considerations at the business level are discussed
and two further phases which contribute to the enterprise lifecycle:

Business Modelling is the phase in which an appropriate modelling technique (here OT is recommended) is applied to modelling not the solution as expressed in software but the business itself irrespective of whether or not the business has any software assets
Business Reengineering is the phase in which the processes in the business are analyzed and reconsidered, usually resulting in significant restructuring. Object technology is seen as an enabler here.
Each of these phases contributes to one or more of the life cycles described above. For example, the project development cycle consists of two phases, Inception and Construction, whilst the programme life cycle consists of the project development life cycle’s two phases together with Strategy, Usage and Retirement phases (Figure 2).

Figure 2 The phases typical of the Programme Life Cycle (after Firesmith and Henderson-Sellers, 2000)


The OPF defines a workflow as a sequence of contiguous task performances (see above) whereby producers collaborate to produce a work product. Typically, a workflow involves multiple producers (teams, roles), thus providing a collection of time-ordered task performances combining producers and tasks.

Examples of workflows include the following requirements and architecture workflows:

Vision Statement Workflow
System Requirements Specification Workflow
Software Requirements Specification Workflow
Software Architecture Document Workflow

A build is a stage describing a chunk of time during which tasks are undertaken. It typically has a duration of a month or a quarter (i.e. three months). Builds are the only kinds of Stage that occur within the Inception Phase; in other phases they are frequently complemented by releases and deployments, together with another kind of Stage, the Milestone which indicates a point in time.


A release is a stage which occurs less frequently than a build. In it, the contents of a build are released by the development organization to another organization (e.g., the customer or user organization) for evaluation or use (Figure 3).

Figure 3 The details of the Construction Phase (after Firesmith and Henderson-Sellers, 2000)


While a Build is a Stage internal to the development team, and a release is a kind of Stage which involves the user or client who receives it for consideration, a Deployment occurs when the user not only receives the product (or prototype) but also, probably experimentally, puts it into service for on-site evaluation. In other words, the software is deployed into the organization, but in the incremental fashion typical of an OO and CBD development.


A milestone is a kind of Stage with no duration. It marks an event occurring. Milestones are usually recognized as “achievements” i.e. a time for celebration that some part of the endeavour has been successful. There are two types of milestones: Business Milestones and Technical Milestones.


Figure 4 Using the OPEN Process Framework (after Firesmith and Henderson-Sellers, 2000)

The OPEN process framework cannot be used as is. Rather, it must first be instantiated and then the resultant process created to meet the needs of the specific endeavour (Figure 4). The process engineer thus requires usage guidelines covering:

Instantiating the class library to produce actual process components.
Choosing the best process components.
Tailoring the fine detail inside the chosen process components.
Extending the existing class library of predefined process components.

Process Construction Guidelines

A process construction guideline is a usage guideline intended to help process engineers instantiate the development process framework and then select the best component instances in order to create the process itself. Specifically, it will provide guidance concerning how to:

Select the work products to develop.
Select the producers (e.g., roles, teams, and tools) to develop these work products.
Select the work units to perform:
How to allocate tasks and associated techniques to the producers.
How to group the tasks into workflows, activities.
Select stages of development that will provide an overall organization to these work units.

Tailoring Guidelines

Once the process framework has been instantiated and placed into effect, one typically finds that one needs to perform some fine-tuning by tailoring the instantiated process components as lessons are learned during development. Tailoring guidelines are usage guidelines intended to help process engineers tailor the instantiated process components.

As an interesting postscript, we also note from Figure 4 that there is an additional opportunity not yet realized: to engineer an OPF-derived process specifically for a generic domain such as finance or realtime and consequently “productize” that OPF-compliant process.

Extension Guidelines

No class library can ever be totally complete. Because of the large differences between development projects, new classes of process components will eventually be needed. Also, software engineering is an evolving discipline, and new process components will need to be added as the field advances. (Witness the recent advent of component-based and web-based development approaches.)

A process framework should therefore come with extension guidelines, whereby an extension guideline is a usage guideline intended to help the process engineer extend the existing development process framework by adding new classes of process components.


To summarize, the OPF (OPEN Process Framework) defines, by means of metaclasses, a set of elements that must be present in an OO/CBD process. The main ones are Producers, Work Units, Work Products, Stages and Languages. To use the OPF, you, the organization, usually in the form of a process engineer, choose which of these elements are to be instantiated and which instances are to be drawn from the existing library – for instance, as documented in the OPEN books. Assertions are added to create a time sequence for the process, together with necessary identification of milestones, quality criteria etc. to be achieved. Selecting items from the library thus leads to the creation of an OPEN instance – a process rather than the process (meta)model as in the OPF. This instance uses the particular tasks, techniques and activities that the OPEN authors have made available (in books, on the website etc.) or, on rare occasions, you may identify organizationally specific ones you wish to add yourself. Nevertheless, there may still be some further tailoring you need to do, such as altering internal details of a Work Product or Technique. The result is an organizationally-specific or project-specific process offering exactly the support you need, no more and no less.

A good place to start learning about OPEN is the pair of chapters reproduced here with permission from The Handbook of Object Technology (ed. S. Zamir), Copyright CRC Press, Boca Raton, Florida 1999. Chapter 2 OPEN: the first full lifecycle, third generation OO method; Chapter 3 The OPEN process (tasks, techniques and management). If you want a more meatier introduction, have a look at the book by Henderson-Sellers and Unhelkar (2000): OPEN Modeling with UML.