ABSTRACT
The OMG RFI for a software process engineering architecture had six submissions by the March 1 1999 deadline. The first, and most important, question was whether the Object Management Group should be concerned with standardizing process at any level. Each panelist, all of whom are either involved in one of the RFI responses and/or are well-known authors on the topic of OO process, will make their position statement on the value to the industry of a possible RFP and subsequent adoption of a process framework technology. The subsequent discussions will center around the abstraction level of most value for such a standardization effort, as well as the scope of required submissions to any RFP(s) likely to be issued in 1999/2000.

Scott Ambler
Several years ago it became apparent that we needed a common modeling notation, hence the bubble wars. The fighting started on a reasonably level playing field, with coalitions eventually forming. Attacks were made on both the technical and marketing fronts, and the fight raged on until a victor emerged.

Fast forward to today. The winning coalition, still together after becoming fast amigos, now works together growing the company that they work for. The losing coalition, openly disgruntled with how things turned out, now work together to improve software engineering practices worldwide. Enter the process wars.

What neither coalition recognizes is that the situation is different this time around. Where there was consensus within the industry that we needed a common notation, there is not a similar consensus that we need a common software process, nor that we need a software process at all. One coalition must recognize that the industry actually needs a software process, not merely a development process. The other coalition, although looking at the bigger issue, must recognize that it needs to win the hearts and minds of the software professionals it is fighting for.

It is doubtful that the notation wars produced the best possible solution, and almost certainly not the complete solution, and it is equally doubtful that the same approach will work in the software process arena. Cooperation, not Darwinism, is what our industry needs. Are we willing to rise to the challenge?

Biographic sketch
Scott Ambler is the President of Ronin International (http://www.ronin-intl.com) and has been working in object-oriented development since 1990. Scott is the author of several books, including Process Patterns (1998) and More Process Patterns (1999) both published by Cambridge University Press. His personal web site is http://www.ambysoft.com.

Desmond D’Souza
Development processes are a necessary evil. When deployed, they are invariably adapted and customized in lots of ways, and these ways are not always mutually compatible æ leading to lots of trouble that is fixed in an ad-hoc basis. Moreover, adaptation often occurs across processes ("... let’s use the testing approach we used in that other project..."). This means that: (a) processes have to be "componentized" ^_ broken into parts with defined interfaces for composition as well as customization; and (b) treated as one (or many) "frameworks" that can be customized and re-composed.

For this to work the underlying process meta-model itself has to be precisely defined. The idea of a component-and-framework-based development process can be a real winner, particularly if it goes beyond the usual class-inheritance approach to a process meta-model. We outline the concept based on the Catalysis approach to using UML for components and frameworks.

Biographic sketch
Desmond D’Souza is senior vice president of component-based development at Computer Associates, responsible for defining methods, tools and architectures for effective component-based software engineering. He is co-author and developer of the CATALYSIS method.

Julian Edwards
There is often considerable agreement at a general level on the characteristics of a modern software process, characteristics. These, however, hide a wide range of diversity of processes reflecting a wide range of diversity of software projects. This diversity leads to the often-heard phrase "our project is different so we can’t follow the standard method" which is sometimes true and sometimes an excuse for taking shortcuts.

One view, which may help address this question, is that we should be applying good OO principles to the world of process in much the same way as we have applied them to the problems of software reuse and thus define standard and repeatable processes, possibly modified when applied to a particular project. These modified processes "inherit" from the core process library providing flexibility with consistency. We should therefore be looking to develop core software processes that can be stored in a library and then reused. In this view, we are able to "plug and play" process modules to develop specific processes for specific projects.

The question is whether the software industry in its present state is able to take on this relatively sophisticated view of process. If not, then perhaps the most useful next steps in the area of process should simply be to try to agree and formalize the common characteristics of an OO process. If the answer is that we are ready, then maybe our next steps should be larger and more ambitious, perhaps looking at possible process frameworks and standard process components.

Biographic sketch
Julian is a Principal Consultant and the Senior Methodologist with Object Oriented Pty Ltd., Australasia's largest consulting and training organization specializing in object technology. He is author of The Working Object with Brian Henderson-Sellers (Prentice Hall, 1994) and has published numerous research papers in international journals and conferences.

Don Firesmith
Because no single software development method will work for all kinds of projects, we should not try to standardize on a single development process or method, no matter how tailorable. Instead, we should concentrate on a development process framework that can be extended, instantiated, and tailored to meet the needs of specific projects.

The following should be requirements for any standard object-oriented process framework:

• It should be relatively complete, providing most necessary process components as predefined classes.
• It should be extensible, allowing the addition of new classes of process components as needed.
• It should be flexible, allowing the process engineer to choose the appropriate process components and hook them together.
• While providing flexibility, it should nonetheless provide the necessary rigor to make development manageable.

The OPEN Process Framework (OPF) is such a framework, consisting of a class library of predefined process components and associated usage guidelines.

Biographic sketch
Donald Firesmith has been working exclusively with object technology for over 15 years in all kinds of roles. He has written 4 books on object technology, published dozens of articles, and delivered dozens of papers at numerous international conferences. A principal member of the OPEN Consortium, he is currently working on books on the OPEN Process Framework and OO SQA.

John Smith
My views are colored by many years of software project management and attempts to construct development plans without even an organizational process definition – let alone one with industry wide acceptance. These plans all too often were mere facades, maintained to keep the customer happy, but a continuing nightmare for the project manager. The use of development standards such as Dod-Std-2167 did something to address this, but the heavy-handed imposition of these standards meant there were almost as many negative consequences as positive.

Today, we have shifted the emphasis to assessment against frameworks such as the SEI CMM and ISO 15504, and the US DoD has cancelled many government standards in favor of commercial equivalents, such as IEEE/EIA 12207 for software life cycle processes. However, these standards are now very abstract and generic, to permit a wide range of compliant process realizations – both in structure and contents.

The OMG initiative I think should be concerned with making something that is more directly usable by industry, to assist in creating compliant process instances which can serve a variety of software development domains, but which, through a shared model and structure, will allow process information exchange and even exchange of process fragments themselves. It does not make sense at this moment to think about standardizing on a single, concrete process but it is possible to envision structures and models on which sets of processes could be based.

Even so, this is quite a mountain to climb, and the initial RFP has, I think correctly, much more modest objectives – to settle on some terminology and a static metamodel. The achievement of even these modest goals would be a great step towards making defined process ubiquitous.

Biographic sketch
John Smith is a Principal Consultant with Rational Software Corporation. With Rational for six years now, he is currently working in the Rational Unified Process Development Group in Vancouver, B.C. Before joining Rational, he was with Computer Sciences Corporation Australia for twenty-two years, as software developer then project manager.