The following article is a preliminary draft, circulated in January 1996, for an article which eventually appeared in IEEE Computer, 29 (4), with the different title: OPEN - Toward Method Convergence? It is significant in its statement of the aims of the OPEN consortium. Contributors have subsequently changed their positions - some becoming more involved, others less involved.
B Henderson-Sellers and I M Graham, with additional input from C Atkinson, J Bezivin, L L Constantine, R Due, R Duke, D Firesmith, G Low, J McKim, D Mehandjiska-Stavrova, B Meyer, J J Odell, M Page-Jones, T Reenskaug, B Selic, A J H Simons, P Swatman and R Winder, to appear in IEEE Computer, 29 (4)
In the beginning, there were no OO methodologies. Around 1990, a collection of analysis and (predominantly) design techniques were published, either in paper or book form. These approaches were, in general, derived independently and (possibly) tested with local industry. Over the next few years, the increasing number of publications and international conferences allowed the OO methodologists to meet, discuss and exchange ideas. This then led to a ``second round'' of publications, which may loosely be termed second generation in the sense that they blatantly borrow from other sources. Examples are Fusion (using CRC, Booch, OMT and formal methods) and the second edition of Booch's OOAD. These second generation approaches do not invalidate the first generation approaches (unless they are a second version e.g. Booch94 does replace the 1991 version). Consequently, by the mid-1990s methods such as RDD, OMT and OOSE coexisted with more recently published methodologies such as Booch94, MOSES, SOMA, Martin/Odell, BON and OOram.
Whilst Grady Booch and Jim Rumbaugh continue to focus on OO modelling techniques, with some input from Booch on project management, there is no stated intention to include in their work any process model or any significant concern or focus on business issues, reuse strategies, metrics, legacy systems or transaction processing. The stated aim of the OMEGA project [1], to create the first, fully-tested third generation methodology known as OPEN (Object-oriented Process, Environment and Notation), is to do just this: provide a full process-model underpinning for systems to be developed, initially within the business context, across the full lifecycle including reuse, quality, transactions and legacy systems. In addition, OPEN will offer support for concurrency, databases and distributed systems. Incorporating, as it does, many ideas from methodologies such as RDD, BON, MOSES, SOMA, Martin/Odell, Syntropy, ROOM, OBA, OORAM etc., OPEN is a truly third generation methodology. In addition, many of those authors have pledged active support of OPEN, as evidenced by the author list for this column.
The good news, therefore, is that OPEN is not just another methodology. We do not add one more to the overall count of current OO methodologies. On the contrary, the OPEN methodological framework outlined here will significantly decrease the number of methods available to be chosen from, replacing as it does MOSES, SOMA, BON, Martin/Odell, etc. The draft handbook for the OPEN methodology is currently in the hands of the methodology developers and the industry users - such names as Dow Jones Telerate, Swiss Bank Corporation, SHL Systemhouse, JP Morgan, FourFront (in India), LBMS, IBM. Only following industry testing will we publish the definitive OPEN Handbook.
OPEN is fully object-oriented. Even its life-cycle model is represeted as a network of interacting objects (Figure 1). Each object represents an Activity. Transition between Activities is governed by a contract (pre- and post-conditions) - we thus call this life-cycle the contract-driven life-cycle. Activities include a well-specified testing programme and should deliver test results against both task scripts and a normal technical test plan.
The contract-driven lifecycle does not prescribe only one deterministic process. Rather, it permits (1) ordering in an iterative and incremental fashion and (2) the tailoring by a given organization to its own internal standards and culture - an important component for each organization's internal ``culture''. We indicate in this diagram only some of the likely routes between Activity objects. But remember, the main governing constraint on the routes are whether you do or do not meet the pre-conditions of the Activity to which you wish to transition. The post-conditions are your assurance of quality. Different process configurations, chosen to reflect the needs of different problems and different organizations, can be contructed from this flexible framework. Once chosen, the lifecycle process is fixed - although still, at least in an OO project, highly iterative, flexible and with a high degree of seamlessness [2].
On the left hand side of Figure 1 are Activities which are associated with a single project; on the right hand side, in the shaded box, are those Activities which transcend a single project and are associated more with strategic planning and implementation concerns e.g. resources across several projects; reuse strategies; delivery and maintenance aspects. OPEN includes both projects and organizational software strategies.
The Activities permit a largescale structuring of the project management for an OO product development. What they don't do is to identify things that have to be done at a low enough resolution to match with tasks that need to be done in order to meet the goals of each Activity. For example, when the developer is focussing on an Activity such as Evolutionary Development, there are a number of associated Tasks which need to be undertaken successfully. One of these is the Task: Structure the object model. This is a clearly delineated goal that someone can take responsibility for (the delivery of a well-structured object model for the problem in hand). We should also note that for this particular Activity, more than one task may well be identified; for other Activities there may be predominantly only one Task required. OPEN's Tasks are therefore statements of things that need to be done. They may be described as the ``smallest unit of work on a schedule which contributes to a milestone''. Tasks are either completed or not completed.
We can thus think of these links (Activities to Tasks) in a probabilistic manner and visualize them in a 2-D matrix which links together each Activity with each Task and allocates to that linkage a measure of probability of its occurrence. Following industry tests, we will give our overall recommendations for each Activity/Task pair in terms of M (=mandatory), R (recommended) O (=optional), P (=possible - but unlikely) and F (=forbidden). For example, planning the number of iterations in an OO development is not likely to occur in the Evaluation Activity. Finding the CIRTs (CIRT is a generic term to include class, instance, role and type) is almost certainly a mandatory activity in the Development Activity (Rapid OOA/D/P and testing). Constructing a Distributed Systems Strategy may be totally absent in some software projects; but critical to the project's success in others. For any specific project the actual pattern of M/R/O/P/F should be determined as part of the initial planning activity, usually the responsibility of the project manager. This is part of the process of tailoring the OPEN methodology to your own organization.
This two-dimensional matrix also offers the project manager significant flexibility. If new ideas/tasks are developed in a particular context, then incorporating them into this framework is extremely easy. It only requires the addition of a single line in the matrix and the identification of the M/R/O/P/F nature of the interaction between this new task and the activities of the chosen lifecycle process model.
However, knowing that the Task: Structure the object model is one (of several) tasks that the developer can undertake in order to complete the Activity does not tell the developer how to accomplish the Task(s). The Task is the goal, the what; the how is described by one or more Techniques. This is similar to saying that I want to hang a picture on my living room wall. This is today's Task. But how do I do that? I use some Technique - but often I have a choice between techniques; and furthermore I may use not just one but several techniques to accomplish my task. In this case I have a choice between using (a) a hammer to knock a nail into the wall or (b) a screwdriver and a screw together with (for either option) a piece of string and knowledge of how to tie an appropriate (reef) knot.
OPEN does not mandate techniques - you are at liberty to accomplish these tasks with whatever tools and techniques you are familiar with. However, in order to aid the developer, the OPEN methodology does include a large range of suggested techniques which we, and others, have found to be appropriate. Again there is a fuzzy nature to the linkage of techniques and tasks. Some tasks are clearly best accomplished with a single, specific technique - a technique applicable to that task and nothing else (for example, implementation of services which supports the coding task). Other techniques will be found useful in a range of tasks (for example, contract specification). And finally for some tasks there may be a choice that the project manager has to make. For example, there are many ways of identifying classes, objects and types. These include interactive techniques such as the use of CRC cards to identify responsibilities; scenarios/task models/scripts/use cases to focus on functionality delivered as a prelude to finding CIRTs within these scripts; textual analysis, in which nouns in the requirements analysis have the potential to be realized as CIRTs; simulation which focusses on the objects within the modelling exercise; and even (for some skilled people), the use of ER diagrams as a basis for an CIRT structure diagram.
OPEN has over 100 suggested and proven techniques from which to choose. Many focus on business issues (e.g. cost estimation and project planning), others on reuse (completion of abstractions and generalization). We believe in the importance of quality, through techniques such as contracting [3]. User requirements capture is also fully supported by the use of task scripts, a more sophisticated version of use cases [4] which provide a seamless link between business objects and (software) system objects. Tasks also provide the basis for the task point metric - a focus of the International OO Metrics Club.
The OPEN technology supports a metamodel compatible with the emerging OMG standard, a fully OO, responsibility-driven and contract-driven object model with connections which do not break encapsulation, a suite of techniques to manage large models and their inherent complexity, technical support for roles, patterns, frameworks and distributed object systems - all supported by a full notation and a growing number of CASE tools (e.g. SOMATiK, Simply Objects, MetaEdit, Graphical Designer).
OPEN is a methodology that contains many options from which to choose so that when that choice has been made the resulting method, tailored to your organization and your project, is readily learnable and becomes your organizational standard; yet ``your own methodology'' is completely compatible with the published (and larger, more comprehensive) OPEN methodology, supported worldwide by trainers (e.g. Tower, Vayda, COTAR), CASE tool vendors (e.g. Advanced Software Engineering, Adaptive Arts Pty Ltd) and users (e.g. Dow Jones, Swiss Bank Corporation) - a methodology which opens the door to your software development future.
Figure 1 Contract-driven lifecycle model