Introducing the Object-Oriented paradigm in a medium size software ...

Software Process: Improvement and Practice 3(1):

35-46 (1997)

Introducing the Object-Oriented paradigm in a medium size software development company. V.A. Makris1 MSc, K.C. Thrampoulidis2 PhD. 1 KNOWLEDGE SA, Industrial Information Systems Department NEO Patron Athinon 37, GR 26441 Patras, Greece Tel: +30-61-652820; Fax: +30-61-653819 E-mail: [email protected] 2

Electrical & Computer Engineering Dep., Computer Science Laboratory University of Patras, GR-265 00 Rio Patras, Greece Tel: +30-61-997325; Fax: +30-61-994798 E-mail: [email protected]

ABSTRACT. Software development is an inefficient and expensive process. More than a quarter of the software projects fail and almost everyone exceeds its budget and requires extra time to finish. At the same time high competition forces prices down. Object-Orientation seems to be at the time the most promising approach to address most of the software development problems. This paper describes the process of introducing the Object-Oriented approach to a medium size software development company as well as the experience gained through this transition. The use of Object-Oriented techniques and tools is also evaluated in terms of improving the efficiency of the software development process. The experiment was based on a combination of OMT, Booch and OOSE methodologies with Paradigm Plus as the supporting CASE tool.

KEYWORDS: Object-Oriented Analysis, Object-Oriented Design, OMT, Use Cases, CASE tools, OO experience.

0

Software Process: Improvement and Practice 3(1):

35-46 (1997)

1. Introduction Software industry increasingly faces today the challenge of creating complex custom-made applications within time and budget, while high competition forces prices down. New technologies in Software Engineering as well as modern CASE tools assist in improving the efficiency of the software development process. However, this is not always enough. There is a wide gap between the state of the art and the state of the practice, as is well reported in [Hsia et al 1993]. At Knowledge S.A., which is a middle size software developing company, we recognised that the basic source of problems lies in the failure to capture early enough and correctly the user requirements. Poor user requirements specification always results in costly late modifications which complicate code and destroy the application’s structure. In addition many iterations with the end users are needed until the system reaches a stage of conformity with the user needs. For new applications, we usually delivered three to four versions of the final system before we manage to cover the user requirements. Besides the extremely high cost that these iterations introduce, there was no planning for reuse, which was left merely to the programmers’ good will. We had also been facing the problem of passing smoothly from the analysis models to the design ones, which is a common difficulty appearing in traditional software engineering methodologies, such as SA/SD. Aiming to cut down costs, by improving the efficiency and effectiveness of the software development process, in order to strengthen our market position and increase our market share, we decided to initiate a project that would tackle these issues. The project, called ORASIS, started in 1994 within the framework of the European Union ESPRIT/ESSI Programme and involved the introduction of state of the art techniques in the software development process.

1

Software Process: Improvement and Practice 3(1):

35-46 (1997)

The ORASIS consortium consisted of Knowledge SA, Marac SA and Fanco SA. Marac produces telecommunication systems and electronic devices, and develops software for these products. Fanco is one of the biggest clothing manufacturers in Greece and develops software for internal use. The Computer Science Laboratory of the University of Patras and Lattice Ltd, a British consulting company, undertook the training and consulting roles in this project. Since Object-Oriented (OO) technology is being recognised as perhaps the best known way to revolutionise and improve dramatically the efficiency of software development process, we selected this as the basis for the process improvement. OO is attracting a major area of interest from software developers in recent years, under the promise to address all the concepts of modern software engineering or to make the introduction of new such concepts, where appropriate. Information hiding, messaging, data abstraction, encapsulation above the subprogram level, polymorphism and concurrency are examples of such concepts. OO analysis produces models that are easier understood by end users, as they are direct representations of real world concepts. The OO paradigm promotes and facilitates reusability, interoperability and when applied well, produces solutions, which closely resemble the original problem. The use of the OO approach leads up to systems that are easily modified, extended and maintained. A large number of encouraging results is reported from the software community last years [Fayad et al 1994][Berg et al 1995]. However, the existence of more than 40 published Object-Oriented methodologies that claim to support the full development life-cycle, makes the selection process for a new user absolutely confusing. The objective of the project was the introduction of Object-Oriented techniques in the software development practices of the three partners of the consortium, so as to enhance the end user - developer relationship and improve the efficiency and effectiveness of the whole software development process. A seamless transition from requirements analysis and design to coding and GUI building, was required. To satisfy this goal we defined a strategy in order to secure a smooth and effective transition. Among the main phases we highlight: training to 2

Software Process: Improvement and Practice 3(1):

35-46 (1997)

new concepts, selection of the most appropriate OO methodology to be used, tailoring of the selected methodology, and introduction of an integrated OO CASE environment. A real world application was selected to become the pilot project for the transition, so that safe comparisons could be made with our traditional development methodologies. The application experiment’s objective was the development of the third version of a Production Planning Decision Support System (DSS), based on the MRP II philosophy. The system supports inventory management, production planning and production monitoring. It was built on top of an ORACLE database. For the development of the new version, a combination of OMT [Rumbaugh et al 1991], Booch [Booch 1994] and Jacobson [Jacobson 1992] methodologies was used. The whole process was supported by the Protosoft's Paradigm Plus CASE tool and Oracle Development 2000 tool. In section 2, we briefly describe and comment the strategy followed to secure a smooth and effective transition to the new approach. In section 3, the method and tool selection process is presented and discussed. Section 4 highlights two of the main key concepts of our resulting OO approach and evaluates their use in terms of improving the efficiency of software development process. In section 5, we present the lessons learned from this quite successful transition and finally we conclude the work. 2. Followed Strategy An internal study, aiming at assessing the current software development practices and defining the areas where the ORASIS would focus, was the first project task. We soon realised the need for a formal software maturity assessment as well as that to complete this assessment, the objective view and expertise of an external consultant was necessary. In addition to the valuable experience of the consultant, having a third party perform the evaluation:

3

Software Process: Improvement and Practice 3(1):

35-46 (1997)

• helps in mitigating the expected unwillingness of the company staff and the arguments regarding the objectivity of the results and • proves the management commitment to the project, which is a crucial factor for the project success. For the assessment of our current software development practices the consultant (Lattice Ltd) used a formal Maturity Assessment procedure which was based on the SPICE, BOOTSTRAP [Kuvaja et al 1994] [Bicego et al 1993] and ISO/IEC methods. The maturity assessment proved to be a difficult and intense process, which could not be performed but by a professional expert. It required the involvement of more than a half of the company personnel, with representatives from every hierarchical level and caused approximately a week’s disruption of everyday work. It involved a one-day presentation, the answering of large questionnaires covering all aspects of the software engineering process and individual interviews by the consultants. Questions were difficult to answer and required serious thought, but the results proved to be worthwhile. The importance of this assessment lies not only in the fact that it revealed the weak points in software development but also that it helped everyone realise the need for improvement. The maturity assessment results established consensus as to which maturity level the software development team is and became the main source for the definition of the basic requirements of the CASE tool to be adopted. Having finished the assessment, we agreed on the objectives and set out measurable targets against which the success of the project would be determined. At this moment we decided about the application to become the pilot experiment for the transition, and formed the project team involving the more enthusiastic engineers. We selected developers that had had significant experience in Production Planning, which was the problem domain of the application experiment. The fact that they all had degrees in computer science and high level commitment to their profession, proved to be essential for the project success. However the importance of a carefully planned training programme should not be 4

Software Process: Improvement and Practice 3(1):

35-46 (1997)

underestimated. Text books are not enough to make the transition. Only after training, were software engineers able to identify the right problem abstractions and think in an OO way, although some of them had already read some OO literature. In the context of this project, training was targeted at software engineers, project leaders and managers. A detailed description of the basic OO concepts as well as OO Analysis and Design methods were presented to software engineers with a more focused training on the specific chosen methodology. An introduction to the OO technology focusing on project management issues was given to the managers of the organisation so that they become aware of the implications and difficulties of such a venture. We selected to apply three training sessions, since a compressed one does not give the necessary time for the software engineers to feel comfortable with the new concepts. Furthermore, using a consultant was worth the cost as it provided the opportunity for on demand answers to every day problems. Method and tool selection was the next step to be accomplished. A market survey in order to find the most appropriate tools to support the new processes is essential, since CASE tools are an expensive investment. Valuable assistance have been provided by magazine articles, relevant books and papers such as the ones by Culver-Lozo [Culver-Lozo et al 1992] and Colleman [Colleman 1994]. Although expert consulting was indispensable to avoid traps, care must be taken since consultants sometimes tend to recommend tools that they already are familiar with. After the CASE tool-set has been bought and people have acquired some basic training on its use, it was time to perform the pilot experiment, so as to gain hands-on experience. Having finished the application experiment, we reviewed and adjusted the whole process using the acquired experience. The resulting methodology was written down to form the base for the definition of the company’s software development process. An in-house workshop was organised to expand the use of the new approach to other development teams within the organisation. In the workshop, the methodology was outlined and the experience, good and 5

Software Process: Improvement and Practice 3(1):

35-46 (1997)

bad, from the experiment was presented. Positive results of the new approach and its potential for even greater performance was pointed out. 3. Method and Tool selection process For a team that decides to adopt the OO paradigm, the existence of more than 40 published Object-Oriented methodologies which claim to support the full development life-cycle, as well as the absence of standardisation makes the selection process absolutely confusing. At the time we started the project, OMT appeared to be at the top position and the most common used methodology in the European market. It was also supported by most of the known available CASE tools and training programmes were provided by many consultants. We were guided to select it as the basis on which the system's development would proceed, without realising that this selection would have an impact on almost every stage of the company’s software development process. Unfortunately the selected technique focused only on requirements analysis, design and OO programming. Testing, verification and validation were rather ignored and we are currently working to formalise them. A proposal to mix OO phases with functional ones was early abandoned. In order to determine the most appropriate CASE tool for the selected methodology, we used the results of the software assessment. This assessment has also helped determine the most appropriate steps to achieve the transition to the new paradigm. A market survey was carried out in order to find the most appropriate tool set to be bought. Guidelines to form a common basis for the comparison were established. According to Yourdon, the key issues for OO CASE tool selection should include the ability to support diagramming notation for all basic OO concepts, ability to hide and reveal portions of the model, browsing capabilities, consistency and error checks, groupware support, code generation, integration with other tools and price [Yourdon 1994]. Since these guidelines cover mainly the tool functionality

6

Software Process: Improvement and Practice 3(1):

35-46 (1997)

ignoring other important issues, we agreed on a set of broader selection criteria, that were classified into four categories: 1. Commercial Characteristics, which include the tool name and version release, the vendor's and distributor's telephone, address and a contact name, price per seat, training, user base and customer names, technical support and maintenance, prime competitors, etc. 2. Functional Characteristics. The functional description of the tool, the development phases it supports (analysis, architectural and detail design, code generation, etc.) and the methodologies it covers are among the functional characteristics. The ability to support most of the phases of the development life-cycle was regarded as a basic requirement. 3. Product Characteristics, which include the hardware and software platform supported, the maturity of the product and its developer, information about the underlying repository, single or multi-user support, security features, integration with other tools and nonstandard software and hardware requirements. 4. Special characteristics. These include specific requirements that were put by the participants of the project. First and most important was the support of the OO approach. Many vendors claim that their product support Object-Orientation, without this always being absolutely true. Encapsulation, inheritance and polymorphism were looked as evidence of real OO. Equally important was considered the fact that the new tool should be able to generate code for various data formats, preferably ORACLE and INGRES RDBMSs which were used by the project partners. Finally client-server awareness was considered an essential feature. In the market survey, over 22 tools have been thoroughly examined and evaluated. Almost 75% of the tools bearing the title "Object-Oriented" were able to justify this characterisation. Tools were classified in two categories; upper CASE tools supporting analysis, design and some code generation and lower CASE tools, otherwise referenced as Software Development Environments (SDEs), covering coding and GUI building. Unfortunately, no tools had been 7

Software Process: Improvement and Practice 3(1):

35-46 (1997)

found in the market, at that time, supporting the entire software development life-cycle. Out of the surveyed tools, we pre-selected six, which seemed to fulfil most of the basic requirements. Three were upper and the other SDEs. The three upper were “Object Team” by Cadre Technologies, “Paradigm Plus” by Protosoft1 and “Rose” by Rational. The three SDEs were “Elements” by Neuron Data, “SQLWindows” by Gupta2 and “NS-DK” by Nat Systems. Due to the lack of available time and tight budget we did not follow a more rigorous process such as the one described by Lin Zucconi in [Zucconi 1989]. For this reason, in addition to the market survey, we considered useful to look for some experience reports on using CASE tools. In [Culver-Lozo et al 1992] for example, StP by Interactive Development and Teamwork by Cadre are suggested as "the most popular CASE tools". These tools were among the ones looked at in our market survey. The first one was excluded, because we could never be able to work with the demonstration disk we were provided with. The second one was rejected as it supported only the OMT methodology. In that phase we did not want in any case a strict commitment on the OMT methodology due to the uncertainty of the method selection process. That was proved true since OMT did not provide us with the necessary support for the design phase. Of all aforementioned upper CASE tools, the most attractive was “Paradigm Plus”. Although Protosoft provided us with just a rolling demo of the product, so we had no way to examine it in-depth and to identify the product's imperfections, our final decision judged it as the most appropriate CASE tool. The reason for this was basically the fact that it supported the most commonly used Object-Oriented methodologies, i.e. OMT, Booch, HP Fusion, Coad/Yourdon and Shlaer/Mellor. It also claimed to be a meta-CASE tool, meaning that it provided the ability for the user to modify the supporting methodologies and define his own

1 2

Protosoft has been recently bought by Platinum Technology Inc. Gupta has been renamed to Centura and so its SQLWindows tool. 8

Software Process: Improvement and Practice 3(1):

35-46 (1997)

types and constructs. This latter feature seemed extremely appealing, since it would enable the user tailor the notations and follow up any evolution in the supported methods. 4. Analysis and Design Approach As mentioned above, our Analysis and Design approach was primarily based on the OMT methodology. However, we soon discovered that this methodology although powerful enough in the analysis phase, it did not offer the means to record the user requirements, it did not provide a clear-cut distinction between the analysis and design phases and lacked a lot of features needed for the design phase. We decided to combine features of different ObjectOriented methodologies to create a complete Analysis and Design approach that would fully satisfy our needs. We used the Use Cases concept to enhance the user requirements capturing and documentation, while the design phase was primarily based on the Object Interaction Diagram (OID) concept. 4.1 Use Cases For the user requirements capturing process, Rumbaugh suggests using textual scripts and data flow diagrams to capture the functional aspects of the system [Rumbaugh et al 1991]. Such models have been proven difficult to integrate with the other models of this notation, so we used a user-driven approach as described by Ivar Jacobson [Jacobson 1992] to record a set of use cases. It should be noted that even Rumbaugh suggested later in his article, "Using use cases to capture requirements" a way to use the use cases concept to capture requirements [Rumbaugh 1994]. Although Rumbaugh's notation is different from Jacobson's one, it seems to be an always growing consensus on the use case concept as a way to capture requirements [Jacobson et al 1995][Embley et al 1995]. This is one of the key concepts on which the leading OO methodologists are converging. Use cases are diagrammatic and detailed textual descriptions of the system’s functionality, seen from the end user’s point of view. Paradigm Plus V 2.01 was used to record use cases, 9

Software Process: Improvement and Practice 3(1):

35-46 (1997)

even though as it was proved, it did not support them in a convenient way. There is no connection with the other models involved in the analysis phase so one can not talk about forward and backward traceability. Associations of the form uses, extends, and adds as described by Jacobson and Rumbaugh are not supported. The drawing of a diagram as the one shown in figure 1 and the provision of a name and a textual description for each use case, are the only things one can do. Nevertheless use cases proved a very good means of helping: • the end users think and determine their requirements correctly • the analysts to apply reuse by this early stage.

Figure 1. The “production planning“ Use Case. As is shown in figure 1, the “view load” use case is optionally extended by the “input overtime” use case. The “input overtime” functionality was modelled as a distinct use case, that can be also called from other use cases, introducing reusability at this early stage. We must notice that according to the use case notation, ellipses represent use cases while the arrows represent associations.

10

Software Process: Improvement and Practice 3(1):

35-46 (1997)

However useful the Use Cases were to describe all system functions from the user's point of view, they were greatly enhanced by the accompanying User Interface model of the system [Jacobson 1992]. Our prototype, based mainly on both the Use Cases and the User Interface model gave to our end user, at a very early stage of the development process, a clear view of how the system will operate. Use case diagrams mainly helped our analysts while users remarked that more focus should be placed on the textual descriptions rather than the diagrams. We must also notice the significant contribution of the use cases in the class diagram construction process. First cut class diagrams, produced by simply recording the problem domain objects and their associations, were greatly enhanced by considering the system’s use cases. For example, the class diagram of figure 2 presents a part of the Production Planning system class diagram that was refined using use cases. One can notice that the Bill of Material (“BoM”) class, which models the recipe of a product, is an association class between “product” and “processed product”. “Routing” class is an aggregate composed of associations between “processed product” and “process”. 4.2. Object-Interaction Diagrams (OIDs) Reaching the design phase, we discovered that OMT lacks support for expressing certain strategic issues such as class categories, parameterised classes, design features defining ownership

and

lifetime (e.g. containment by

reference), access

11

value versus

containment by

Software Process: Improvement and Practice 3(1):

35-46 (1997)

Figure 2. The production planning system Object Diagram (part). control, visibility, etc. In addition it does not propose specific steps for the design phase, it just suggests to use the object model notation to represent object design. Therefore we decided to use the OID technique [Thrampoulidis et al 1995] also found in the Booch and Jacobson methods. OIDs illustrate the sequence of messages exchanged between objects and describe the operations triggered by each such message, in every Use Case. OIDs are used extensively in the design phase to illustrate scenarios that trace the execution of common system functions which require the collaboration of several system objects. For example, the “Capacity Calculation” OID, shown in figure 3, illustrates the procedure for calculating the capacity of every production department and machine for every planning period. With such an information for every Use Case and for every specified complex method, the transition from design to implementation phase became an easy process. However, we had to manually draw the rectangles on OID’s columns to represent the operation which the specific message

12

Software Process: Improvement and Practice 3(1):

35-46 (1997)

exchange belongs to. Paradigm plus did not support this notation and as a result code generation had nothing to gain from the information recorded to OIDs.

Figure 3. “Capacity Calculation” Object-Interaction diagram Class Responsibility and Collaboration (CRC) session proposed by Rebbeca Wirfs-Brock [Wirfs-Brock et al 1990] and best described in the book "Using CRC Cards" by N. Wilkinson [Wilkinson 1995] assisted significantly the process of assigning operations to objects. Regardless of practising CRC sessions to assign class responsibilities or not, participating in a CRC session considerably helped our non OO experts understand the fundamentals of ObjectOrientation and realise how Object-Oriented systems work internally. 5. Key Lessons The work accomplished in the ORASIS application experiment has taught several important lessons. This experience can be categorised into lessons from a technological point of view and lessons from a business point of view.

13

Software Process: Improvement and Practice 3(1):

35-46 (1997)

5.1. Technological point of view A) a seamless transition from requirements capturing through analysis and design to implementation could not be fulfilled with the existing tools. There were several Object-Oriented CASE tool-sets available in the market, each supporting some phases of the software development life-cycle, but none was found to cover the entire life-cycle. Only recently have OO upper CASE tools, which claim integration to specific development tools, such as the Rational Rose/SQLWindows, emerged. However, this integration is not yet very successful, as it was reported by one of the project partners, and it still requires a lot of manual intervention to pass from the analysis and design models to the implementation one. Given the limitations of the used tools, automatic integration that would allow a seamless development process with reverse engineering support has not been achieved in this project. Depending on the specific needs of a company, two approaches can be envisioned for moving to Object-Oriented technology: 1. Companies heavily involved into software production with a need to introduce formal and rigid analysis and design methods should focus on upper CASE tools. These tools will enable such companies formalise their existing development procedures. In our case, we faced difficulties with the Paradigm Plus CASE tool, as it did not support the latest additions to the OMT method. Despite the fact that Paradigm Plus claimed to offer the ability for the user to extend and modify the supported methods, it has not been possible to exploit this feature because it required the use of an internal proprietary programming language that was not available to the user. Compatibility with existing RDBMSs and the ability to generate source code, are two more features that should be carefully examined. In any case, the introduction of OO Development tools in parallel to the upper CASE ones should be considered. These tools will enable a more effective exploitation of the OO paradigm. 14

Software Process: Improvement and Practice 3(1):

35-46 (1997)

2. Organisations with a need to develop prototypes easily and fast should follow this approach. According to this, focus should be placed on SDEs which have the benefit of addressing the problem of integrating the OO model to Relational or other DBMSs. They assist and automate the creation of business applications with graphical user interfaces. Many of these tools partially support the design phase, assuming that the analysis has already taken place. Classes and relationships defined in the analysis and design phases must be entered in the SDE. Care must be taken of the platforms and data source they support and the overhead they add to the efficiency of the developed applications compared to traditional programming. B) Lack of ODBMSs with industrial strength. In our dilemma, whether to use an Object or Relational DBMS, we discovered that the lack of ODBMSs with industrial strength could deter a software developer from following the Object-Oriented paradigm. Current ODBMSs have not reached yet a well proven level in security, data locking, integrity and performance, compared to RDBMSs. However things pace fast and it is expected that robust ODBMSs will soon become available. For the time, we decided to use development tools that support a direct mapping of the object model to the relational one. Such tools deal with the low level issues of such an integration, but certainly there is a price to pay in performance. The part of our application, which was based on this approach, was quite slow when running on 486 PC and required high system resource capacity. We overcame this problem with faster PCs. C) Object-Oriented tools have not reached yet an adequate level of maturity. We discovered that the capabilities of the upper CASE tools used proved to be inferior to our original expectations, including the technical support offered by the vendors. For example there was not always good integration between the various models, we faced problems with the fonts and the resizing of diagrams and code generation was rather elementary. The lack of standardisation was also apparent. Despite these problems, the upper CASE tools proved very 15

Software Process: Improvement and Practice 3(1):

35-46 (1997)

useful in the sense that they assisted the creation of analysis and design models and imposed consistency and formality in these phases. Since CASE technology is not mature yet in the support of the OO paradigm, it would be better never purchase a CASE tool before trying it on a real project by acquiring a short term license. 5.2. Business point of view Object-Orientation is not a panacea. Its effective adoption requires a determined and committed top management, which will take all the necessary steps to achieve it. Establishing an Object-Oriented software development team within an organisation requires investment in people, tools and training. Frequently, experienced software engineers are not willing to change their current methods, where they have become experts, in order to adopt to new procedures. Substantial training was required, which emphasised the expected benefits of the new approach. Not all OO benefits appeared in the first project, but if everything is done right, we expect that the initial investment will certainly pay off. The most striking benefit was the fact that we managed to adopt methodologies which produce models that are better understood by end users. This enabled us to get the end user substantially involved to the analysis phase of the application and build the right system, right at first time. Problem domain classes and object scenario diagrams in the analysis model were proved more tangible constructs to the eyes of the novice user than what he would see in a structured analysis diagram. The Use Case approach in conjunction with the early prototyping, helped the end user get an idea of how the system will function. In fact, the Production Planning System has worked successfully right from the first customer shipment, as opposed to our past experience which required about three efforts until the system accomplished the end user needs. Solely by this achievement, we managed to reduce the overall development labour costs by about 20%, despite the fact that we spent about 50% more labour time during the analysis and 16

Software Process: Improvement and Practice 3(1):

35-46 (1997)

design phases. We believe that this is a very promising result, bearing in mind the fact that it was achieved without seriously exploiting reuse, which is presented as one of the greatest advantage of the OO paradigm. To reach a reasonable level of reuse requires a lot of planning to establish and maintain a library of reusable components. This may take years to achieve and the first projects will not be able to benefit by substantial reuse. However, some reuse has been achieved by this first project since most OO software development tools offer libraries of reusable components. We used the ORACLE Development 2000 tool library, but we found out that we had to spend a lot of time modifying the existing classes or define our own, according to the project needs. Therefore it would be unreasonable to try to evaluate the rate of reuse by having performed just one application. We feel that for future similar projects the reuse rate will be much greater, as we will be able to use the classes we defined during this project. Our analyst’s experience with production planning systems, was a key factor in identifying key abstractions and laying the foundations for software reuse. Although, there are cases, such as the one reported by William Berg, where “the initial development cost was less than it would have been with the use of traditional methods” [Berg et al 1995], in our case it has been proved that the use of OO methods requires a greater initial investment. But we expect it to be recovered as substantial reuse comes into effect or the product reaches the maintenance phase. Even though a considerable amount

of

approximately 50 kecus was spent in consulting, training and tools, the net development cost, which is the cost excluding the initial investment, was reduced by about 20% . Of course reuse is not the only factor for improving the software development process. The use of CASE and SDEs contributes significantly towards this direction. Such tools improve the quality of the produced software by enforcing the adoption of more formal processes and assisting documentation in all phases of the development life-cycle.

17

Software Process: Improvement and Practice 3(1):

35-46 (1997)

Reviewing the project results, we may point out the fact that despite the limited reuse, we managed to reduce the software development costs by about 20% mainly due to the better understanding of the user requirements that minimised the required late modifications to the application. It is envisaged that cost savings can reach a level of 40%, in future projects that will be able to take greater advantage of the reusable class libraries. We estimate that for a medium size software company which undertakes about 4-5 large projects every year, it will take about one and a half year, or 6-7 large projects, after the first pilot application, in order to redeem the initial investment. The effective use of the object technology can lead to better quality and lower cost products which means more competitive market position and higher profit. However, we must never underestimate the importance of the supporting procedures, such as project planning and management, reviewing, configuration and change management, in the successful completion of any software development project. For these procedures we have not yet seen a considerable support from Object Technology. 6. Conclusions The introduction of the Object-Oriented paradigm was done quite successfully through this project. However difficult is it to evaluate the overall process by just one project, some benefits became evident right from this first project. One of the objectives set out right from the very beginning of the Application Experiment was the affective capturing of user requirements by enhancing the user-developer relationship. The use of OO models, which are better understood by non experts, in conjunction with early prototyping techniques proved to be in the right direction. We achieved to reduce the number of user-developer interactions from an average of three, to a single cycle, thereby reducing development costs by more than 20%. In fact, the Production Planning System which was developed within the project complied with the end user needs 18

Software Process: Improvement and Practice 3(1):

35-46 (1997)

right from the first customer shipment! It is also estimated that now it would require about half the effort for customisation, than if it had been developed with our previous practices. The new methodology was well received by the majority of the involved engineers of the company. This is mainly attributed to the fact that most were young open minded professionals who had realised the need for improvements in the development process they had been practising. Of course, the maturity assessment, by revealing the weakest areas in the company’s practices, has helped everyone, especially the management, realise the need for change. This has played important role in the commitment everyone exhibited in this transition. The adoption of the OO approach requires a big and risky initial investment, which, if it is done properly, will certainly pay off. But many of the potential benefits may take some time to appear. This is perhaps the main reason why most medium and small size software development companies would hesitate to proceed without any support. Participation in initiatives such as the EU ESPRIT/ESSI programme, which funds software process improvement, can be for many software houses, the only chance to proceed with such an investment. However, some cost savings can appear right from the first pilot application, as in our case. In fact, if we manage to achieve a 30% to 40% cost reduction per project, we expect that the initial investment will be recovered within 7 additional large projects. Finally, it should be pointed out that the OO paradigm may offer the means for producing high quality modular software in a very effective way, but at the bottom line it is the people who control the whole software development process and it is in their hands to exploit these means for their benefit.

19

Software Process: Improvement and Practice 3(1):

35-46 (1997)

Acknowledgements We gratefully thank our ORASIS partners (FANCO SA, MARAC Electronics SA, Lattice Ltd) for their valuable co-operation during the Application Experiment. We deeply thank the European Commission DGIII for funding this work. References Berg, W., Cline, M., Girou, M. 1995. Lessons Learned from the OS/400 OO Project. Communications of the ACM, October, 38, p54-64. ACM Press. Fayad, M., Tsai, W., Anthony, R., Fulghum, M. 1994. Object Modelling Technique : Experience report. Journal of Object-Oriented Programming, Nov-Dec, p46-58. SIGS Publications. Bicego, A., Kuvaja, P., Cacchia R., Koch, G., Krzanik, L., Simila, J., Saukkonen, S. 1993. BOOTSTRAP: Europe’s Assessment Method. IEEE Software, May. Booch,

G.

1994.

Object-Oriented

Design

with

applications.

Second

Edition,

Benjamin/Cummings Publishing Co. Colleman, D., Arnold, O., Bodoff, S., Dollin, C., Gilchrist, H., Hayes, F., Jeremaes, P. 1994. Object-Oriented Development The Fusion Method. Prentice Hall. Culver-Lozo, K., Glezman, V. Experiences Applying Methods Supported By CASE Tools. 1992. AT&T Technical Journal, November/December, p20-25. Due, RT., Henderson-Sellers, B. 1995. The Changing Paradigm for Object-Oriented Management. Object Magazine, USA, July/August, 5(4) p54-60. SIGS Publications. Embley, D., Jackson, R., Woodfield, S.1995. OO Systems Analysis: Is It or Isn't It? IEEE Software July, p19-33. Hsia, P., Davis, A., Kung, D., 1993. Status Report: Requirements Engineering. IEEE Software, November, p75-79. 20

Software Process: Improvement and Practice 3(1):

35-46 (1997)

Jacobson, I. 1992. Object-Oriented Software Engineering - A use case Driven Approach. Addison-Wesley Publishing Co. Jacobson, I., Christerson, M. 1995. A growing consensus on use cases. Journal of Object Oriented Programming, Vol. 8, No.1, March-April, p15-19. SIGS Publications. Kuvaja, P., Simila, J., Krzanik, L., Bicego, A., Saukkonen, S., Koch, G. 1994. Software Process Assessment & Improvement. The Bootstrap Approach. Blackwell Business Press. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W. 1991. Object-Oriented Modelling and Design. Prentice Hall. Rumbaugh, J. 1994. Using use cases to capture requirements. Journal of Object Oriented Programming, Vol. 7, No.5, Sep., p8-23. SIGS Publications. Thrampoulidis, K., Diamantopoulos, D. 1995. Combining OMT and Booch Methodology to Manage Rules in the Resource Rescheduling Problem. 8th International Conferrence on Software Engineering & Its Applications, Paris, Nov., p195-208. Thrampoulidis, K., Agavanakis K. 1995. Object Interaction Diagram, a new technique in OO Analysis and Design.

Journal of Object-Oriented Programming, June, p25-39.

SIGS

Publications. Wilkinson, N. 1995. Using CRC Cards. SIGS Publications, USA. Wirfs-Brock, R., Wilkerson B. 1990. Designing Object-Oriented Software. Prentice Hall, USA. Yourdon, E. 1994.Object-Oriented Systems Design, an integrated approach. Yourdon Press Prentice Hall, USA. Zucconi, L.1989. Selecting a CASE Tool. ACM SIGSOFT, Vol. 14, No 2. Apr.

21