The OPEN Process Framework (OPF) is a practical, public-domain, industry-standard, general purpose management and engineering process framework that is primarily intended for the object-oriented, component-based development of software-intensive systems.
OPF consists of a:
OPF provides managers, developers, strategists, user experience personnel, process engineers, methodologists, consultants, trainers, and academics with the best current industry practices for processes to perform:
The OPEN Consortium is a non-profit group of over 35 dedicated individuals spread around the world, whose membership includes international-recognized methodologists, consultants, academic researchers, CASE tool vendors and users. The three principal members are Donald Firesmith, Ian Graham, and Brian Henderson-Sellers, each noted methodologists with significant experience and multiple technical books to their credit. Other well-known members include Dinu Anastasiu, Colin Atkinson, Franck Barbier, Jean Be’zivin, Ed Colbert, Philippe Desfray, Richard Due, Daniel Duffy, Roger Duke, Yossi Gil, Cesar Gonzalez Perez, Kitty Hung, Richard Hubert, Don Kavanagh, Norm Kerth, Graham Low, Jim McKim, Daniela Mehandjiska-Stavrova, Simon Moser, Kinh Nguyen, Alan O’Callaghan, Meilir Page-Jones, Dilip Patel, Rajesh Pradhan, Dan Rawsthorne, Tony Simons, Madhu Singh, Paul Swatman, Louis Taborda, Richard Thomas, Bhuvan Unhelkar, Katharine Whitehead, Alan Wills, Russel Winder, Houman Younessi, Ed Yourdon, and Hadar Ziv.
The OPEN Consortium’s official website provides detailed information about OPEN, the OPEN Consortium, news about OPEN events and presentations at upcoming conferences, and lists of OPEN publications including books, journal articles, and conference papers. You can also use the official OPEN website to contact the OPEN membership and find out about CASE tool and training support.
For more detailed and complete information about OPF’s repository of reusable process components, you can use this website, contact other OPEN CASETool vendors, and read the various OPEN books.
Think of a process framework as a tool to build a process, or as a warehouse containing the parts needed to build a process, or better yet, as a factory for building processes. It is something like the difference between an car factory and the cars it produces. The factory contains the tools and the parts needed to build the cars, and the factory workers that build the cars are like the process engineers that take the process components and build processes. However, unlike a car factory that produces large numbers of only a few car models, a process framework is used to build a different, endeavor-specific process each time.
The short answer is that the development of software-intensive systems is a large and complex field that requires a lot of information to model.
The OPEN Process Framework (OPF) is NOT a development process or method and does not compete with such methods. In fact, XP and other more complex methods can be considered instances of the OPF. Instead, the OPF is a process framework (consisting of a large and hopefully relatively complete repository of reusable process components based on an underlying metamodel). As such, it competes with other process frameworks (e.g., the Unified Process is becoming more and more a process framework rather than a method).
I prefer to think of the OPF as a large, complete, expensive toolkit that can be used by everyone from beginners to master craftmen to build things (in this case, endeavor-specific processes). Whereas grocery stores commonly sale small inexpensive toolkits containing a small hammer, a pair of pliers, and a couple of screw drivers, I find that I cannot even maintain my house without a lot of additional tools. I would never want to build a large office building without a complete set of tools. The experience of a craftsperson can be seen in the size and completeness of his or her toolbox. Similarly, whereas a beginner may only need a relatively small (although still not insignificant) number of process components for a project building a small, simple, software application that is not business-critical, we need much larger toolkits (processes) for building large, complex, distributed, business-critical applications containing software, hardware, data, and wetware components. We need even more tools when we include business reengineering based on the use of modern information technology and related topics such as digital branding. Luckily, the average person on such an endeavor plays only one (or at most a few) roles and only needs to learn those process components that are relevant to his or her role. It is the poor process engineer or methodologist that needs to master the process framework and thus know which of the reusable process components are relevant and how to tailor them. This is just like the beginning programmer who can learn the syntax of a relatively pure OO language (e.g., Smalltalk, Java) relatively quickly, the associated lowerCASE IDE takes more time, but it takes multiple years to incrementally master every class in the associated class libraries. Are the Smalltalk, Java, and C++ class libraries too complex? Only if you think you have to use every method of every class in every application. The same applies to process frameworks.
We have worked hard to make the metamodel (structure and meaning) of the OPF reusable process components logical, intuitive, and simple. I have similarly worked hard to make it easy to find the desired (relevant) process components easy in my website (e.g., via a site map organized according to the metamodel, a site search engine, an index, and several kinds of numerous links).
Also, my experience is that it is a lot easier, more productive, and less risky to select what you need from a preexisting set of process components than it is to try to produce an important missing process component in the middle of a project (or worse still, to let it slip through the cracks because of either ignorance or carelessness).
I believe that the size and resulting complexity of the OPF is not accidental, but based on the size and complexity of the development of software-intensive systems (as well as the associated business reengineering and digital branding). It is only after a lot of years of experience with a lot of applications of many different sizes, complexities, criticalities, and domains does one really see just how large and complex. Which process components would you leave out? And how can you be so sure that they are not needed on multiple projects, given the thousands and thousands of projects that exist?
No one complains that the class libraries assocated with languages are too big and complex as long as they are logically and intuitively organized and it is easy to find what you need. The same should be true for process frameworks.
Our problem is to clearly explain the difference between an endeavor-specific process or methodologist’s favorite method (no larger than needed for that endeavor and thus relatively small and simple) and a process framework from which endeavor-specific processes can be constructed (hopefully complete enough to support all aspects of all reasonably common projects).
Small, simple methods such as XP and Agile Computing are very incomplete and are not scalable to support the development of large, complex business-critical applications containing software, hardware, data, and personnel components. They certainly ignore many roles, tools, tasks, techniques, etc. They also don't support business reengineering, digital branding, etc.
It depends on what you mean by complete. Although the OPF is very large and complete compared to the other existing process frameworks (e.g., RUP, Zachman Framework) and probably contains all of the reasonably common process components, we are constantly identifying new components to add as we learn more about business engineering and the development of software-intensive systems. As time has past, the number of new process components being added has become less and less, and most of our available resources are currently invested in maintaining and completing the existing components.
OPF and the SEI’CMM use a different, although related metamodel. OPF contains a much larger superset of process components than CMM or CMMI. Significant work has been performed to ensure that all of the components of CMMI up to level 5 have been included in the OPF, but that work has not yet been completed and there may still remain a few CMMI components that are not completely included in the latest version of the OPF.
To be a complete framework, the OPF is almost certain to comtain at least some process component that are not needed on any project, no matter how large and complex. Just like a large Java class library, you would not expect to use every class on any Java application. Thus, there is bound to be a process engineering task during which the relevant OPF process components are selected for use on the endeavor so that irrelevant components can be ignored.
Definitely. In fact, the smaller and simpler, the fewer OPF components that will be needed to instantiate the process. As resources permit, effort is being expended to ensure that all major agiles methods can be created using a subset of the OPF process components. Note also that to produce an agile process, tailoring out of unnecessary pieces of reusable process components will also be necessary. This is just like when a programmer reuses a standard Java class; only some of the methods and attributes will be used.