 |
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
|
