OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software

+44 1249 815081


Business Modelling

Adopting a Process



Business Builder

Component Development



Full Life Cycle

Delivering on the J2EE


OIG provides help with choosing a methodology, by addessing issues such as scope, scalability, project management and tool support.

We have considerable experience of helping companies with all aspects of the development life cycle, including technology selection, choosing methodologies, tailoring software development processes, business modelling, requirements gathering, tool selection and tailoring. Recent technologies we have helped companies adopt include Use Cases, UML, RUP, Agile methods, J2EE and component-based development.

Would you like to know more about what we do ?

Perhaps you would like to discuss your specific issues with choosing a methodology - then please phone us on +44 1249 815081 or mail us at more@oig.co.uk

Or learn about the guidelines developed by a consortium of large scale users - the Object Interest Group - for choosing a methodology. The page that follows details this work and although the guidelines were developed sometime ago many are still relevant.

Choosing a Methodology

The objective of the ‘Choosing a Methodology’ work was to address the questions :

  • What methodology do I choose ?
  • How do I implement it ?
Our members, and a number of the practitioners/suppliers, felt that comparing methodologies simply by ‘box-ticking’, produced a rather shallow assessment. Consequently, the main part of our work was concerned with collecting together both members’ and external practitioners’ practical experiences of using the different methodologies. The methodologies we looked at were those used, or evaluated for use, by either members, or external practitioners we spoke to.

OIG members first shared their own experiences to identify key concerns. Then from April ‘93 to December ‘93 experienced practitioners and suppliers were invited to give presentations to respond to these concerns.

Members’ key concerns were loosely grouped into the following categories :

  • How do OO methodologies compare with conventional ?
  • Evidence and experience of use.
  • What is the scope of OO methodologies ?
  • Project management.
  • CASE support.

How do OO methodologies compare with conventional ?

Many of the productivity promises of conventional methodologies have not delivered. They are too prescriptive in that they result in a lot of specification about what is not important and key features are not adequately visible.

Two important reasons why conventional methodologies failed to meet their hype are :

  • They use both a data and a function model with no clear mapping between the two.
  • The conventional ‘waterfall’ development life cycle does not reflect practice and is therefore more difficult to communicate.

OO combines data and function and it encourages seamless and continuous enrichment in the OO approach. This combined model is closer to reality which means it is simpler to understand, and less information is lost because of the seamless approach from analysis through to implementation.

At the time of the project we observed that object methodologies had evolved in either evolutionary, or revolutionary ways. Evolutionary have a stronger foundation in structured, conventional approaches. They are much more data-driven, and are based around isolating elemental data ‘objects’, within the domain being studied, followed by event analysis and functional specification. OMT is an example of an evolutionary methodology. Whereas revolutionary start and continue with OO concepts throughout. This approach, is more responsibility-driven, where the interactions and functionality of ‘objects’ are defined as part of the first stage. An example is Booch’s methodology. As such, evolutionary methodologies offer something of a migration path to OO, but in doing so, they lose some of the benefits of OO’s seamless development approach.

In general most methodologies are complex and appear unwieldy. The unwieldy nature is a consequence of the continuous enrichment process which does not lend itself to clear breakpoints and deliverables. Some members and practitioners, however have addressed this problem by treating each evolution as a step and linking their reviews etc to each of these.

Much of the terminology was alien to developers and particularly managers (eg abstraction, polymorphism etc) and did not relate to their experiences. Thus, understanding the differences between methodologies, without getting too immersed in the detail could be a problem. But experience has shown that evolutionary delivery again helps in this situation, because there is something to show very early on in the development, which can then be used to explain the rest of the terminology.

Evidence and experience of use

Managers know that taking a new methodology on board, particularly across a large IT division is a major undertaking and not something they want to commit to whilst methodologies are immature. They were therefore particularly concerned to learn about other people’s experiences, so they could make an informed judgement about the maturity of the various OO methodologies. Plus they wanted to know what they could do if they did not want to commit to a particular methodology at this stage.

When the OIG concluded its first assessment of OO in March ‘91, there were about a dozen methodologies available, all very immature. There are now many more, of varying maturity.

At the time of this project, none of the methodologies were complete, so in general it was considered too early to make a major commitment to one particular methodology. We did however, see some evidence of this, in for example, the telecommunications industry. We were also starting to see the beginning of natural convergence and combining of the best features amongst the leading OO methodologies, for example Rumbaugh intending to include use cases from Jacobson’s ObjectOry at the front of his Object Modelling Technique (OMT).

In the meantime, our members, and the external practitioners we spoke to, who had significant OO developments, eg airline yield control, communication management systems and car dealerships, were all using OO methodologies. The majority had chosen to ‘mix-and-match’ the best features of several different methodologies, whilst recognising they might need to change at a later date, with the implied conversion effort. The wisdom being that it was better to use an imperfect methodology, than no methodology at all !

What is the scope of OO methodologies ?

Concerns relating to the scope of OO methodologies were focused on how they provided support for new features such as evolutionary delivery and reuse.

At the time of the project, none of the OO methodologies we looked at covered the whole life cycle and provided little support for reuse.

In general, OO methodologies were initially particularly poor at supporting reviews, source control, integration and maintenance, all of which become more important on larger projects. Similarly, only a few OO methodologies at the time, eg ObjectOry covered testing and documentation control.

Most OO methodologies also failed to differentiate between the business domain and the application, and therefore objects, which are business as opposed to application-specific were not identified. This produced significant limitations on reuse. However, a few methodologies, eg ObjectOry, were starting to recognise this and were at least acknowledging the difference between the domain and the application.

Project management

It was clear that evolutionary development, the tendency to merge traditional development roles, the need to maximise reuse and library interaction etc would involve significant project management changes for which support from methodologies would be needed.

Evidence showed that initial OO analysis and design did take longer - anything up to 3 times as long as conventional approaches. However, our members and external practitioners we spoke to, also reported eventual productivity gains, on their 3rd or 4th projects, of between 5 and 10 times.

OO analysis and design is more interactive, but the result is more accurate models, which can be reused. Moreover, use of the evolutionary approach means that managers and users can see demonstrable functionality earlier. This is because evolutionary delivery consists of first delivering a minimum, but important working part of the system, plus stubs for the rest of the system, and then continuously enhancing the stubs with more function, over the development lifespan. This is in contrast to prototyping which consists of producing a series of ‘throw-away story-boards’ to test the usability of the system.

Evolutionary delivery does, however raise a number of issues, eg will the process scale-up and are frameworks for the process provided ? Evidence showed that scale-up was feasible - a number of developments we looked at were significant, but were still using an evolutionary approach. But very few of the methodologies, at that time, explicitly supported a process framework, which did hinder the possibility of process repeatability and could have added to management’s view of OO as unwieldy. However, some CASE tools, for example Kappa and ObjectIQ had adopted a Rapid Application Development (RAD) format, which provides some support for the above process.

OO training improved, not surprisingly, as the methodologies themselves improved and their popularity increased. During Phase I, all that was generally available were expensive seminars, given by the gurus of the time, such as Cox, Coad and Booch. By the time of this Phase II project, third party consultancies and companies, such as Hoskyns, Admiral Training and QA Training were offering courses, and more workshops were being included at conferences, such as ECOOP and Object Technology. This was in addition to the training offered by the methodology suppliers themselves. However, OO training still needed to improve and become more widely available, to match the training for more conventional methodologies.

CASE support

Many large IT divisions effectively employ 4GLs or CASE tools to produce code. The idea of migrating a large division from a 4GL back to something like C++ initially filled most managers with dread and at that time it was thought that this was unlikely to happen on a large scale. The issues of CASE support were therefore particularly important, if OO methodologies were to compete affectively with conventional ones.

Most of the leading methodologies already had reasonable CASE support and were improving all the time. A few OO 4GLs also existed which provided rapid visual application development, as described above, but no tools at that time adequately supported the repository approach, which was needed to aid large-scale developments, and very few integration tools were available.

CASE tools, like the methodologies however were not stable, and there was no reason, why OO CASE was any less likely to lock you in, than conventional CASE. Therefore, it was believed to be too early to make major commitments, or investments in widespread expensive CASE support. As an alternative, many practitioners were using simple drawing tools and a word-processors. Indeed a number of practitioners stressed the fact that it is not always necessary to use complex diagrams. The Class Responsibility Collaborator (CRC) technique for example, used visualisation, presentation, organisation (spatial awareness) and discussion to capture and document systems. It also recommended the simplest notation and tools available - pens, paper and people !

An interesting and important development at that time, however, was metaCASE, ie CASE-tool shells, which could be configured/programmed to provide support for specific methods. In this way, metaCASE tools could support a variety of methodologies, including ‘mix-and-match’ ones, developed in-house. As such, a number of our members and external practitioners we spoke to, found they offered a good intermediate solution for OO CASE support.

Concluding remarks

Standards may help OO methodologies mature. OMG formed an Analysis and Design SIG and in May ‘93 they proposed a Tool Interoperability Task Force, whose purpose was to obtain common specifications for interchange of OOA and OOD information.

In the meantime, most companies were taking more of a phased approach and gradually migrating to object methodologies. This meant they had to look at coexistence of objects and IE, for example, and cope with providing support and training for both object and conventional methodologies at the same time. However, by taking this approach they were able to learn about objects, while allowing the technology (in particular OODB) to mature, but not lose out on their investment in existing systems.

The OIG continued to look at methodologies and to feed our findings back to both suppliers and standards bodies. We carried on with our general work, tracking the use of various methodologies in large-scale organisations. As well as, for example, taking a look at the applicability of methodologies to framework development. Thus providing support for large organisations right from helping them decide if the object approach is best for them, and if so which methodologies are suitable for their particular needs, to helping them assess if the latest trends in the technology are appropriate for their use, and if so how do they implement and integrate these trends into their existing environments.

Many of the problems and draw-backs we identified in this project have since been addressed and most methodologies are now considerably more mature. One particular advancement is the formal convergence of a number of the methodologies, for example the Unified Method from Booch, Rumbaugh and Jacobson and OPEN an ‘umbrella’ methodology created by the merger of 3+ methodologies, primarily MOSES, SOMA and Martin/Odell.

Created : 30th April 1996

Updated : 11th August 1996

Go to top of page


The Object Interest Group
History of the Object Interest Group
An Assessment of OO
Starting with Objects
Managing Reuse
Feasibility of CBOs
Components and BPR
The Object Interest Group Home Page
Go to OIG Ltd Home Page
© The Object Interest Group

Any comments on these pages to: more@oig.co.uk

© OIG Ltd 2002-2003