"[The authors] have done an excellent job of bringing forth the power and the flexibility of this most useful framework in an easy to read and understand introduction. Although it has been written to be an introductory text in OPF, I found [it] also readily useable as a handbook for initial process definition, an accessible treatment of important issues in software process design, and a textbook in OPF."
Houman Younessi
Associate Professor of Computer Science, Rensselaer Polytechnic Institute
The OPEN Process Framework provides a template for generating flexible, yet disciplined, processes for developing high-quality software and system applications within a predictable schedule and budget. Using this framework as a starting point, you can create and tailor a process to meet the specific needs of the project. Contents Preface xi Part I Introduction 1 1 Processes and Process Frameworks 3 1.1 Processes in Information Technology 3 1.1.1 Software applications 4 1.1.2 Software-intensive systems 4 1.1.3 Business modeling 5 1.1.4 Component-based development (CBD) 5 1.1.5 Organizational scope 6 1.1.6 Stages in the life cycle 6 1.2 The need for process 7 1.3 What is a process? 10 1.4 From process to process framework 15 1.5 What is a process framework? 22 1.6 Specification for a process framework 26 1.6.1 Completeness 27 1.6.2 Flexibility 29 1.6.3 Rigor 30 1.6.4 Object orientation 30 1.6.5 Component-based development (CBD) 33 Summary 33 2 OPEN Process Framework Overview 37 2.1 OPEN 37 2.2 The OPEN Process Framework 43 2.2.1 Work Products 44 2.2.2 Producers 50 2.2.3 Endeavors 52 2.2.4 Work Units 52 2.2.5 Stages 55 2.2.6 Languages 58 2.3 Framework usage 59 2.4 OPEN compliance 61 Summary 61 Part II Process Components and Usage
Guidelines 63 3 Work Products 65 3.1 Classes of Work Products 65 3.1.1 Applications 66 3.1.2 Architectures 66 3.1.3 Components 68 3.1.4 Metrics 68 3.1.5 Models 69 3.1.6 Increments 71 3.1.7 Requirements 71 3.1.8 Diagrams 72 3.1.9 Documents 74 3.2 Management Set of Work Products 74 3.3 Engineering Work Products 76 Summary 83 4 Producers 85 4.1 Direct Producers 85 4.1.1 Person 85 4.1.2 Roles 85 4.1.3 Tools 91 4.2 Indirect Producers 91 4.2.1 Teams 91 4.2.2 Organizations 94 4.2.3 Endeavors 95 Summary 95 5 Work Units 97 5.1 Activities 98 5.2 Tasks 102 5.3 Techniques 108 5.4 Assertions 109 5.4.1 Pre-conditions 109 5.4.2 Post-conditions 109 5.4.3 Invariants 110 5.5 Work Performances 110
contents # 5.5.1 Task Performances 110
5.5.2 Work Flows 111 Summary 111 6 Stages 113 6.1 Cycles 113 6.1.1 Life Cycles 113 6.1.2 Development Cycles 114 6.1.3 Life Cycle Models 114 6.2 Phases 119 6.2.1 Initiation 119 6.2.2 Construction 119 6.2.3 Delivery 119 6.2.4 Usage 120 6.2.5 Retirement 120 6.3 Builds 120 6.4 Milestones 120 6.4.1 Management Milestones 120 6.4.2 Technical Milestones 121 6.5 A Typical Life Cycle Configuration 121 6.6 Timeboxes 122 6.7 Relationship of Stages to Work Units 122 Summary 124 7 Languages 125 7.1 Introduction 125 7.2 Natural Languages 125 7.3 Modeling Languages 127 7.3.1 Metamodel 127 7.3.2 Constraint Language 128 7.3.3 Notation 129 7.3.4 Example Modeling Languages 130 7.4 Implementation Languages 131 7.4.1 Coding Languages 131 7.4.2 Database Languages 132 7.4.3 Interface Languages 133 Summary 133 # contentscontents # E Work Units 241 Activities 241 Project Management 241 Project Initiation 242 Project Planning 243 Configuration Management 243 Risk Management 243 Metrics Engineering 244 Quality Engineering 245 Process Engineering 245 Environment Engineering 246 Website Development 247 Requirements Engineering 249 Architecting 250 Design 251 Component Selection 252 Build 253 Implementation 253 Integration 254 Evaluation 255 Testing 256 Deployment 257 Business Engineering 259 Reuse Engineering 260 Programme Management 261 Resource Planning 261 Training 262 Organization Assessment 263 PreThe OPEN Process Framework is a public domain framework for constructing processes for developing software-intensive applications and object-oriented business models. The OPEN Consortium is responsible for its development and maintenance. The OPEN Process Framework provides a template for generating flexible, yet disciplined, processes for developing high-quality software-intensive applications within a predictable schedule and budget. This book introduces to the reader the OPEN (Object-oriented Processes, Environment and Notation) Process Framework (or OPF) by documenting its underlying concepts, its predefined components, and the process construction and tailoring guidelines that can be used to create a well tuned process for specific projects.
Goals of this book
Using this book, you will:
Learn what the OPEN Process Framework is and how its use differs from specific development methods, even those that permit some tailoring.
Master the basic concepts of the OPEN Process Framework and understand their structure and interrelationships.
Learn how to instantiate the OPEN Process Framework to construct a process that meets the needs of specific projects and organizations.
Intended audience
This book is not intended to be a manual containing all possible information on OPEN, particularly if utilized on a very large complex project. Rather it is intended to offer an introduction to OPEN, its contents and its underpinning philosophy (that of a framework). In parts, it synopsizes or just gives examples rather than giving a full inventory (e.g., of all possible Work Products). If you intend to use OPEN on commercial projects, you should also consult the other books in the OPEN series or access one of the Websites that many companies are increasingly making available either publicly as a product or on their own internal intranets.
This book was written in response to frequent requests that members of companies wished to get an overview of OPEN in order to assess whether it would suit their requirements before delving into the full process specifications as found in, for example, The OPEN Process Specification by Graham et al. (1997).
Preface--Chapter 2, OPEN Process Framework Overview, introduces the OPEN Process Framework, its components and how it is to be used.
Part II, Specifics, provides details concerning the specific components of the OPEN Process Framework (OPF) and how to use them.
Chapter 3, Work Products, documents the OPFs class library of predefined Work Products.
Chapter 4, Producers, documents the OPFs class library of predefined Producers of the Work Products.
Chapter 5, Work Units, documents the OPFs class library of predefined Work Units performed by the Producers of the Work Products.
Chapter 6, Stages, documents the OPFs class library of predefined Stages including Cycles, Phases, Builds, and Milestones.
Chapter 7, Languages, documents the OPFs class library of predefined Languages for documenting and constructing Work Products.
Chapter 8, Framework Usage Guidelines, provides guidelines for the extension, construction, and tailoring of the OPF for use on specific development or business reengineering projects.
The Appendices provide much more detailed and reference material.
Appendix A, List of acronyms a list of all acronyms used.
Appendix B, Glossary definitions of the most important technical terms used within OPEN.
Appendix C, Work Products a full discussion on several groups of Work Products with special focus on Documents and Components.
Appendix D, Producers detailed information on the full range of Producers, both Direct and Indirect.
Appendix E, Work Units discussions on Activities and Tasks; list of OPEN Techniques.
Appendix F, Example Work Flow one specific example related to the External Interface Specification Work Flow.
Appendix G, Metamodel Diagramsthe complete OPF metamodel.
Bibliography and References, listing all cited references plus some relevant background reading.
How to use this book
Managers considering using the OPF should use this book to gain a high-level description of the framework and overview of its reusable component parts. They should read Part I and skim the chapters in Part II, starting with development stages, producers, and work products.
Process engineers need an in-depth understanding of all parts of this book if they are to successfully construct project-specific processes from the OPF. They should read the entire book including the appendices.
Methodologists, with their extensive knowledge of development processes, may profitably skim the entire book, focussing on those areas of primary interest.
After reading Part I, developers may wish to first read the description of their role in the Producer chapter and their tasks in the Work Units chapter and the corresponding appendix. If they have been assigned to produce a work product, they may wish to immediately read about it in the Work Products chapter and the corresponding appendix. As with the documentation for any class or component library or repository, one typically reads about the relevant classes (in this case process components) first and then studies the remaining classes on an as-needed and/or time-available basis.
One can either read Part II of this book in a top-down or bottom-up manner. If you want to start with a top-level overview and work down, read the following chapters in the following order: stages, producers, work units, work products, and languages. If you prefer to start with the most primitive concepts and build upon them, read these chapters in the reverse order.
History of OPEN Process Framework
OPEN was created by a merger of several methodologies in the mid-1990s by active collaboration between a number of methodologists. Primarily, OPEN brings together the SOMA (Semantic Object Modeling Approach), MOSES and Firesmith methodologies with later merging of ideas from the Synthesis methodology. As well as these methodologists, there are over 30 other OO "gurus" worldwide who are involved in establishing the strategic direction of OPEN and helping improve it through their membership of the OPEN Consortium.
The main initial reason for creating OPEN was to help industry move to OO by decreasing the choice of methodology from over 20 in the early 1990s to a single digit figure by the end of the millennium.
Second, the members of the Consortium are those international figures who prefer a responsibility-driven approach to OO software development rather than a data-driven or perhaps a use-case driven approach such as Objectory with UML.
OPEN began to take shape in early 1995 with the merger of MOSES and SOMA, and by mid-1996 the Firesmith method was fully integrated. In the same timeframe, the Object Management Group (OMG) was calling for proposals for ideas on which to base a standard for an object-oriented metamodel, useful for OO analysis and design, which would permit CASE tool builders to create interoperable tools. This focus was very much smaller than a methodology and, although several members of 1 A metamodel is a model of a model. It delineates all the rules needed by which to construct models by creating instances of elements in the metamodel. These instances form the model.preface #the OPEN Consortium have spent time contributing to the OMG effort at standardizing an OO metamodel, it was clear to them that more than a standard metamodel was needed for efficient and effective OO software development. Thus OPEN was born, to encompass all the aspects of application development (including the modeling language being addressed by OMG and the UML Partners). The first book describing the elements of OPEN as a full life cycle methodology was published in September 1997. In this book, we update the metamodel, expand the scope of OPEN (e.g., to better support Web development and business engineering) and summarize the easier elements of that more extensive and sophisticated book in order to provide information for those companies (and educators) about to embark on an OO path to the future. We will assume you understand basic OT concepts such as encapsulation, abstraction, classification, objects, interfaces, classes etc. OPEN even has its very own modeling language4 which is an alternative to UML both are still supported and used, UML being by far the most commonly utilized by OPEN end-users.
Since that first book in 1997, the OPEN literature has grown, with a full book series being published with Addison-Wesley, a regular column in JOOP (Journal of Object-Oriented Programming) and an established and extensive Website (with mirrors) at http://www.open.org.au. A network of consultants, vendors, tools suppliers, and researchers offer worldwide support and the user base continues to grow. In 2001, a new initiative of the Object Management Group to create a standard metamodel for process has involved OPEN Consortium members as reviewers and the standards document cites OPEN in many places.
Finally, we note that OPEN supports true OO ideas. We believe that there are some very basic principles of object technology (OT) that should be your prime focus in developing software using OO principles. These are:
Acknowledgements
We wish to thank all our colleagues who have supported us over the years and helped to promulgate OPEN as a viable OO/CBD process/methodology. We also wish to thank a number of our colleagues for reading an earlier draft of this book manuscript and providing invaluable comments. In alphabetical order, we wish to express our thanks to Richard Heycock, Klaas Koomen, David Lowe, Henrik Ortlepp (particularly for Figures 1.6, 2.4, 2.9 and for suggesting the style of Figures 8.3, 8.4 and 8.6), Thomas Passin, Vit Rudovich, Magdy Serour, Errol Thompson, Richard Veryard and Houman Younessi.
