EuroSPI98 
How to Reap the Business Benefit from SPI
European Software Process Improvement
SPI and Object Orientation
Category Index
Rated Newspaper Supported by EU Project  

Impact on Introducing Object Oriented Software Development Methodologies

Paul Sullivan
ESBI Computing Ltd., Dublin
Pat Caffrey
ESBI Computing Ltd., Dublin
 
 

1.0 Introduction


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.
 
 
 

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

2.1 Fusion

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.
 

2.2 OMT

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.
 

2.3 UML

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 (1994)

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

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:
 

CASE



Development Environment

 

 
 

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:

4.0 Training


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

7.0 Assessments

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 :

    1. 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.
    2. 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.
    3. 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.

 

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 process.
 
Phase OO 

Methodology 

Planning 125% ( 1.25 times)
Analysis & Design 140%. ( 1.4 times)
Coding  60%. ( 0.6 times)
Testing 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 above comparison.
 

7.3 Company Assessment

This assessment describes the impact on adopting the OO methodology on the entire company. The following impacts were found:

8.0 Problems Encountered

The following problems were encountered during the SCOOP project:

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:


Fig 4 PSULL.4

The following are the recommendations of SCOOP to improve the software process in ESBI Computing: -

Disclaimer


The opinions stated in this document are purely these of ESBI Computing and relate to the findings of the SCOOP project.
 

Acknowledgement


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.
 
 
 
 

References

References

[1] Object-Oriented Development The Fusion Method, Prentice Hall 1994. ISBN 0-13-101040-9

[2] Object-Oriented Analysis and Design With Applications, Second Edition (1994), Addison-Wesley Publishing.

[3] Object- Oriented Modeling and Design, Prentice Hall International 1991.

[4] The Unified Method V 0.8 The Unified Modeling Language V 0.91, Public domain - Internet.

[5] A Comparison of Object-Oriented Methodologies, The Object Agency 1995.

[6] 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 market.

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


Author 1

Paul Sullivan

Qualifications

BSc in Computer Applications

Dublin City University

IT Experience

¨5-6 years IT experience from developer to team leader

¨Microsoft Certified Professional in Visual Basic

Oracle and NT. Author 2

Pat Caffrey

Qualifications

BE

University College Dublin

IT Experience

¨15 years IT experience from developer to team leader

APPENDIX C – Design Differences between SSADM and OO.
  1. Documentation.
  2. SSADM Object Oriented
    Requirement document Use Cases
    Module Summary Class diagram
    Screen Design Screen Design
    Detailed Module Design Class Diagram
    Database Modeling Database Modeling
      Axis of change
      Scenario diagrams
  3. Differences
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.

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

Functional Details
 
Author Diarmuid Mac Carthy
Description 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 new location.

Actors StoresMan
Pre-Conditions
  • The new location must have a unique identification
Post-Conditions
  • A uniquely identified location has been created

Implementation Details
 
Classes Used eLocation
eLocationType
eBinEntry
eStoreItem
GUI Details  
Database Implementation
  • Location is inserted into the database through stored procedure SP_INS_LOCATION with parameters location code, description location type, active flag, comments, row version . 
 

 

Class Diagram (Sample)


 
 
 
 
 
 
 
 


Partners in EuroSPI

Editors
ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and Coordination Office, Florence House, 1 Florence Villas, Bray, Ireland, office@iscn.at, office@iscn.com, office@iscn.ie, Editing Done: 19.7.2002