Book Review: The OPEN Process Framework

is of course a quote from a software-oriented process book -- though readers may be surprised to find that an "Application" could be a system 'which includes not only sofware but Hardware and Data Components' – both system and software applications are defined, and quite rightly so. Parts of this book are certainly software-specific, dealing briefly with topics as varied as software architecture, programming languages, and metrics. But since the focus of the book is to introduce a process framework, most of it can be seen as a powerful and general analysis of how to develop any complex product.

The framework itself is clean, rigorous, and thought out by some of the best minds in the Object-Oriented software world.

Firesmith runs a consulting firm and has written widely on object methods, specializing (or is that generalizing?) in project management, Requirements Engineering, system and software architecting, and testing.

Henderson-Sellers directs a research centre in Sydney and has many innovations in object methods as well as nine books to his name.

Ian Graham (author of other writings on OPEN, but not this book) is a long-time proponent of object methods and a trenchant critic of UML (the Unified Modeling Language) and all that goes with it, so it was with some surprise that I discovered a year or two ago his road-to-Damascus conversion. OPEN still maintains its own rival to UML, the Open Modeling Language or OML, but this is now tactfully redefined as 'a variant of UML' along with some criticism of the 'ambiguous and contradictory semantics' of UML and the hope that UML 2.0 will resolve these problems.

OPEN has been in print since 1997 (The OPEN Process Specification, by Ian Graham, Brian Henderson-Sellers and Houman Younessi). The current book is therefore an overview or introduction rather than a full account: but it is complete in its coverage of topics.

What is OPEN, and what is a process framework? It is

'not a process. It is more of a process to create a process. It must be instantiated before it can be used...'

So the idea is that you select what you need, tailor the components you have selected, and thereby construct the process that is exactly right for you. This is more work than simply going to the supermarket and buying a RUP (Rational Unified Process) off the shelf. But (it is argued), OPEN gives you a better result, just as going to the baker, fishmonger and delicatessen enables you to prepare a better meal than anything you could buy ready-cooked and shrink-wrapped.

The RUP is, incidentally, specifically critiqued for 'neglect[ing] the team-building aspects of software viewed as a social construct' and for 'only giv[ing] support for distinct individual "greenfield" projects' as well as not being tailorable.

OPEN provides a Contract-Driven Life-Cycle (based on Graham's SOMA and Henderson-Sellers' MOSES methods). This, it is claimed, subsumes other life-cycles such as the traditional waterfall model. The waterfall is just a CDLC which forbids iteration and assumes that each stage completes and delivers its work product as the precondition of the next stage (e.g. System Requirements are the precondition for System Design to start).

Since no standard ever thinks of everything, OPEN allows you to tailor your own process by adding concepts, by adding examples of existing concepts, or by tailoring existing examples. It thus provides a robust standard but allows you room to breathe.

How does this differ from more general introductions to software engineering, such as Sommerville's textbook? It clearly covers much of the same ground, discussing different activities and how they fit together within different possible life-cycles. OPEN is however purely object-oriented, so it has a particular 'take' on development. It is also certainly more industrial, being rooted in practice and intended to be used on projects of all sizes.

Questions a review can't answer on a book like this include 'how convenient is it to use?' and 'how much would it cost to implement', though these are obviously important. Would it work? Undoubtedly, and OPEN already has a loyal following.

A different issue is whether OPEN could or should be applied to systems in general. I think there is a strong and convincing case for arguing that since information is now the driving force in architectures of all kinds, making up most of the complexity in every system, it makes complete sense to think in terms of objects with interfaces, of messages and roles. For example, a jet engine is a system in its own right, but it is also a component of an aircraft. It responds to commands and provides information on its status. All that is required is a shift in thinking, from 'this is a piece of hardware with a software box in it' to 'this is a system of objects, some of which are implemented as hardware sensors or actuators', to see what is implied. The benefits will grow steadily as complexity increases.

This is a clear, comprehensive, and concise introduction to a major innovation in system and process thinking. If you haven't already met OPEN, this may be the best place to start.

© Ian Alexander 2002