Impact on Introducing
Object Oriented Software Development Methodologies
ESBI Computing Ltd., Dublin
ESBI Computing Ltd., Dublin
The SCOOP project objective was to enable an holistic
view of the impact of introducing OO software development methodologies
and tools. The specific objectives of the project were:
The SCOOP project had a number of deliverables, both internal
and public, which will reflect the success of the work achieved during
the 8-month duration.
Selection of an OO methodology.
Selection of software development tools incorporating the
Production of a test piece of OO software.
A three stage assessment of the test software production
experience, i.e. a direct productivity comparison, examination of the impact
of OO on the whole baseline project (Stores Controller ), and examination
of the impact on the whole company.
2.0 Selection of OO methodology
To find as many OO methodologies in the marketplace,
the Internet was used to find a list of books containing OO methodologies.
The book "A comparison of Object Oriented Methodologies"
was used as a guideline to selecting the following methodologies in more
The Fusion method is a combination of different sections
of different methods. It was discounted almost immediately due to its failure
to describe an organised methodology for developing applications. A large
amount of documentation is produced during the Fusion methodology, however
the processes by which that documentation is produced, the manner in which
that documentation links - or its overall cohesiveness, and the actual
worth of the documentation produced is sadly lacking.
Object- Oriented Modelling and Design, Prentice Hall International 1991
OMT along with Booch is considered to be one of the best Object-Oriented
methodologies. It is used extensively by many companies, has a wealth of
documentation available and a large number of case tools support it. The
text describing OMT is excellent with a section on Analysis, which is worth
reading regardless of the design methodology to be used. The main difficulty
with OMT is not what is produced, but the diagrams used to represent it.
The diagrams in this methodology are angular and to the uninitiated (even
with a notation guide) are difficult to follow; being ambiguous until a
textual description is read. Where OMT fails miserably is when it comes
to design, as it lacks the step-by-step approach of the analysis phase.
The Unified Method V 0.8
The Unified Modelling Language V 0.91
The Unified Modelling Language (UML) is a combination of Grady Boochs’
Booch methodology and Rumbaughs’ OMT methodology. It was initially developed
by Grady Booch and James Rumbaugh, both of whom now work for Rational Software
Ltd. Ivar Jacobson then joined Rational and thence the UML team. The fact
that there is a definite similarity of approach and thinking between the
Booch and OMT methodologies is apparent when comparing the two methods.
This feeling is backed by the following remark:
In comparing its’ self with the Booch-91 methodology the OMT manual
states: "The similarities between the approaches are more striking than
the differences, and both approaches complement one another".
Unfortunately UML was currently in development and as such was not considered
a contender for selection.
2.4 Selected Methodology - Booch
Object-Oriented Analysis and Design With Applications ~ Second Edition
The Booch design methodology is like OMT extensively used has ample
documentation and support tools. It has been chosen over OMT primarily
because it deals not only with the analysis stage of a project but also
the design. The diagramming notation used in Booch is also more readily
accessible and easier to understand than other methodologies. "Booch’s
notations are very comprehensive and can be used to document almost any
aspect of the system.". One of the advantages of Booch is the fact that
it is extremely versatile and robust. The diagramming notation can as stated
above be used to represent almost any feature of a given system.
It is felt that the OMT methodology offers an extremely good process
concerning the analysis section, and for this reason while Booch shall
be the methodology used, procedural and process methods concerning the
analysis of a problem may be taken from OMT. As UML develops further it
may then be possible to move over from Booch with a flavouring of OMT to
3.0 Selection of OO Development Tools.
To find as many OO development tools in the market, the Internet
was used again to find companies and their OO products. Questionnaires
were sent out to these companies to verify the suitability of their products
to use in the SCOOP project. The twenty-eight questionnaires received were
split up into the following categories : CASE, Development Tools, Object
Request Brokers(ORB) and Object Orientated Databases (OODBMS). Products
falling into the category of either ORB or OODBMS were discarded as being
unsuitable to our business. The remaining tools were scored using a weighing
system described below :
A score of 0-5 was given under each heading and the weighing
applied. This scoring system was then applied to each of the remaining
tools giving the following results:
After scoring the CASE and OO development tools , it was
decided that one CASE tool and 2 Development tools would be selected. Evaluation
software was bought for the following tools:
All the members of SCOOP ( 1 Project Manager, 1 Team
Leader and 2 Analysts / Programmers) were given an excellent 4 day training
course in the Booch OO methodology presented by Rational Software. A 3
day training course was organised for Delphi in Ireland , however this
training course was poorly designed and was not as useful as expected.
5.0 Selecting a Stores Controller module.
In selecting a Stores Controller (SC) module the following
criteria was used:
Also the following implementation assumption was made:
As Stores Controller was implemented in 1994 on Windows
3.1, certain improvements can be made to the user interface, as the SCOOP
implementation will be developed in Windows 95. Also the new concepts of
three-tier architecture and OLE may be used to implement SCOOP’s version
of the SC module. Even though the end result may look different the same
functionality will be emulated.
The implementation time of the module must approximately
match 30 days.
The chosen module must not have many database tables or links
to other modules. The module must be as independent as possible and have
Using the above criteria and implementation it was decided
that the Location functionality in SC would be selected.
6.0 The OO implementation Experience.
While implementing the Location functionality of Stores Controller
the following related concepts were added to the SCOOP implementation:
Design Patterns : These are standard set of design problems
and their solutions. Using both the Internet and a book called "Design
Patterns - Elements of reusable Object-Oriented Software". This helped
in the design phase.
Application Partitioning : It was decided to have a very
flexible architecture by partitioning the SCOOP application into GUI classes,
controller classes, Business classes and the Database classes.
Iterative Life Cycle : This was based on eliminating the
project risks early on in the life cycle.
7.1 Metric Assessment
The purpose of this assessment was to compare the original
module metrics with the SCOOP metrics to calculate which method was more
productive. Before the comparison was made the learning curve was taken
out of the SCOOP metrics to try and compare like with like. The following
metrics were calculated: -
Fig 1 PSULL.1
Based on the metrics the following conclusions about using
the OO methodology were made :
There was substantially more time spent designing in the
OO methodology and less time coding for the following reasons
The design using OO techniques is a much more thorough process.
All problems even implementation issues must be thought out at this stage.
Also if a business function is left out or is added at a later stage ,
the class design may change radically. The designer must also have the
‘big picture’ view of the project and must known how the business area
is used throughout the system.
There is much more documentation in the design phase. There
are class diagrams, scenario diagrams, use cases and Axis of change documents.
In the existing software process method there is at most two documents.
Coding takes less time due as the design documentation
provides classes that can be grouped together into programmable packages.
These packages can be written in isolation and accessed through interfaces.
The OO Metrics should decrease with time. If the ‘big picture’
view is taken in the OO design phase and if the system is well designed
, classes can be reused. Therefore as the life cycle progresses more classes
are written and re-use becomes more realistic. In this scenario the
percentage re-use could be estimated at 60% i.e. 60% of the code could
be potentially re-used in the next module in the Stores Controller application
and also for another application.
The OO metrics should decrease in the maintenance phase.
The OO approach abstracts functionality better than more traditional approaches.
7.2 Product Assessment
The purpose of this document was to assess the impact in
applying the OO methodology to the entire Stores Controller product. In
order to implement SC using the Booch methodology the following roles must
be created and training provided for these new roles:
Fig 2 PSULL.2
It was calculated that the 225 man-days were required
to train the required staff to implement Stores Controller effectively.
To estimate the number of man days needed to implement
Stores Controller, was achieved by getting the actual time spent implementing
each SC phase and multiplying these actuals by a ratio calculate by the
SCOOP experience. The following table shows how much time is spent in each
phase when uses the OO methodology in relation to the existing software
||125% ( 1.25 times)
|Analysis & Design
||140%. ( 1.4 times)
||60%. ( 0.6 times)
||90%. ( 0.9 times)
Using the above table and the actual metrics of the Stores
Controller system the following comparison is made:
Fig 3 PSULL.3
Note: The large training overhead was not included in the
7.3 Company Assessment
This assessment describes the impact on adopting the OO methodology
on the entire company. The following impacts were found:
Staff. The current staff will need to be trained in
the new OO methodology. Staff roles will have to change. These roles are
described below :
Class architect. The chief designer for each
project who is familiar with the entire functionality of the project.
OO Designer. A designer very familiar with
the OO methodology.
OO Delphi programmer. A programmer would understand
OO concepts and can use Delphi to implement these concepts.
OO C++ programmer. A specialist programmer
to write ‘C++’ using OLE.
Class Librarian. A person who is familiar with
all the business and utility classes used in the company. This person will
be responsible for object re-use across projects.
Technical Architect. This person understands
the technical framework and the development environment on which the projects
OO Project Manager. A person who knows how
to manage a successful OO project.
Life Cycle. The company life cycle could change dramatically
if the iterative development process is introduced to deal with the complex
problem of OO project management. The Quality life cycle will have to change
to reflect the correct use of the OO methodology.
8.0 Problems Encountered
The following problems were encountered during the SCOOP
Inadequate training for Borland Delphi.
During the project one of the personnel had to leave the
The change from a traditional Top-Down approach to an Object-Oriented
approach took a long time to master.
Many of the development tools vendors did not answer the
9.0 Conclusions and Recommendations.
The major disadvantage in adopting the OO methodology is
the overhead or learning curve. The staff will have to be given formal
training in the OO methodology. The company life cycle may also change
and there may be an overhead involved in changing the Quality documentation.
Also the managing of OO projects will be more difficult.
However SCOOP feels that the OO methodology is the correct
way forward for the following reasons
These advantages will be value for money over time, as the
following graph will illustrate:
The time to market will decrease over time.
The framework devised by SCOOP has greater flexibility and
solves many of the problems with the existing architecture. The OO methodology
made this possible.
Allows greater abstraction and object re-use.
Puts more emphasis on design, which means more system bugs
are caught at design time.
Fig 4 PSULL.4
The following are the recommendations of SCOOP to improve
the software process in ESBI Computing: -
Investigate and review the current SCOOP architecture and
enhance the current SCOOP framework as appropriate. Also review Delphi
3.0 , Visual J++ ..etc. and develop a clear future road map for MC/SC technical
Produce a demonstration system of the SCOOP architecture
to get user feedback. Based on the user feedback update the SCOOP framework
with agreed changes.
Review and select a module of the MC/SC suite of application
for re-engineering using the SCOOP framework and methodology.
Establish a training strategy to match both the short term implementation
of the selected module and also address the longer term goals.
Create a project plan for the selected module and set up standards for
the iterative development life cycle.
Review Quality system and implement required changes to adopt an iterative
life cycle and an OO methodology.
The opinions stated in this document are purely these
of ESBI Computing and relate to the findings of the SCOOP project.
ESBI Computing wish to thank the European Commission
for its assistance throughout the SCOOP project, without, which the SCOOP
project, would not have been such a success.
 Object-Oriented Development
The Fusion Method, Prentice Hall 1994. ISBN 0-13-101040-9
 Object-Oriented Analysis
and Design With Applications, Second Edition (1994), Addison-Wesley
 Object- Oriented Modeling
and Design, Prentice Hall International 1991.
 The Unified Method
V 0.8 The Unified Modeling Language V 0.91, Public domain - Internet.
 A Comparison of Object-Oriented
Methodologies, The Object Agency 1995.
 Object Oriented Methods,
Ian Graham Addison Wesley.
APPENDIX A - Company Background
ESBI Computing (ESBIC) is a member of the ESB International
group of companies, which is a subsidiary of ESB (Electricity Supply Board)
Ireland. Established in 1989, ESBIC has built up a impressive track record
by delivering information technology solutions to the international utility
ESBIC has ISO 9001 certification and employs a Structured
System Analysis and Design Methodology (SSADM) approach to the development
life cycle. The legacy product that the SCOOP project used as a baseline,
is called Stores Controller (SC), and was developed using client-server
architecture. SC is a large part of the Maintenance Controller (MC) product
suite. The development tools of Visual Basic 3.0 / 4.0,Visual C++ version
5.0 and an Oracle Database were employed in the original software.
APPENDIX B - Author Information
BSc in Computer Applications
Dublin City University
years IT experience from developer to team leader
Certified Professional in Visual Basic
Oracle and NT.
I am well practised in the use of Visual Basic, Delphi, Visual
I have adhered to the quality standards of ISO 9001 for over
The last five years I have worked on the re-engineering of
a large utility-based maintenance management system. It is now a client
server application running in many power stations around the world.
University College Dublin
years IT experience from developer to team leader
APPENDIX C – Design
Differences between SSADM and OO.
Research and Development Manger for ESBIC
Production Manager for Stores Controller
The use case diagram in the OO methodology has many levels.
The first level is a simple definition of the business function the use
case is encapsulating. When the class diagram is finished the relevant
classes can be associated to the use case. When the Database Modeling is
complete the relevant entities added. When the scenario diagrams are completed
the relevant scenarios can be attached. The use case is the link from the
original requirement to the analysis and design – this does not occur as
easily with SSADM.
|Detailed Module Design
||Axis of change
The module summary, in SSADM, which is a textual description
of what the module does and how it interfaces with other modules, is generally
pure text. The actual function definitions only get added in detailed design
(in another document). However in the class diagram the analysis phase
has all the classes and their relationship to each other, the design phases
brings this class diagram a stage further by explain HOW they interact
with each other – by defining the methods and properties. This is done
using a notation that is much closer to how the code will work.
Below is a sample use case and class diagram: -
Define a Location
||Power stations generally have
a warehouse on-site. These are typically organised into areas of physical
storage such as floor space, shelves, trolleys, pallets, bins, drums, etc.
The majority of these will be normal storage areas but some may be dedicated
to inspecting suspect materials (e.g. a safe area to accommodate hazardous
goods), while others may be used for routine testing (e.g. a workshop for
stress testing). Locations occasionally become inactive, usually because
of structural defects or building renovations, contamination or cleaning.
This use case provides a mechanism for the storeman to
create a new area of storage.
In a situation where the new system replaces an older
one, or where a previous manual system is in operation, a means must be
provided for reflecting the fact that quantities of store items are already
in stock at a particular location.
This use case provides a mechanism to allow the storeman
specify the store items and their quantities that already exist at the
The new location must have a unique identification
A uniquely identified location has been created
Location is inserted into the database through stored procedure
with parameters location code, description location type, active flag,
comments, row version .
Class Diagram (Sample)
|Partners in EuroSPI
|ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and
Coordination Office, Florence House, 1 Florence Villas, Bray,
Ireland, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Editing Done: