Case Study: SITINA - A Software Engineering Project Using Evolutionary Prototyping

Transcription

1 Case Study: SITINA - A Software Engineering Project Using Evolutionary Prototyping Nuno Jardim Nunes dnnunes@dragoeiro.uma.pt Phone/Fax: +351 (91) / +351 (91) Address: UMa - Madeira Tecnopolo, Penteada, Funchal, Portugal João Falcão e Cunha jfcunha@garfield.fe.up.pt Phone/Fax: +351 (2) / +351 (2) Address: FEUP - Rua dos Bragas 4099 Porto CODEX - Portugal ABSTRACT This paper presents a case study based on a complex software engineering project that took place in a Portuguese SME, Small to Medium sized Enterprise. Our initial goal was to evaluate and adapt Software Engineering theory to the reality of SMEs, usually working in chaotic environments, and following no standard method. We refer to such absence of method as the just do it process model. We shortly present the project, critically discuss its results, and summarise what we believe has been learnt from the experience. We will consider the highly interactive collaboration model, evolutionary prototyping model, object-oriented A&D methods, and CASE tool support. We will discuss its theoretical principles and evaluate its expected advantages and shortcoming on the project mentioned. Finally we propose a new model for evolutionary prototyping, better adapted to the reality of the environment we faced. 1. INTRODUCTION The SITINA 1 project started with the need that the EDM utility company 1 had to monitor two small, completely automated, hydroelectric power plants [1]. The main goal was to develop a low cost application that enabled the board of directors to monitor those power plants and retrieve statistical data on their production. It is not in the scope of this paper to offer a detailed description of SITINA [2]. However, as we can see from its final general architecture on Figure 1, we are dealing with a complex SCADA/EMS 2 based system with many technologies and different software products. 1 SIstema de Telemetria para Instalações Não Acompanhadas (Telemetry System for Unaccompanied Utilities).

2 SITINA Software SITINA User User Interface (forms, gráphs and reports) RDMS Client (4D Client) MacOS / Windows95 TCP/IP or AppleTalk Administration Facilities SITINA Database Server RDMS Server (4D Server) MacOS / Windows95 / Windows NT WWW Server TCP/IP or AppleTalk SITINA Communication Server SITINA Software RDMS Client (4D Client) TCP/IP or AppleTalk MacOS / Windows95 DNP 3.0 L1 Serial Communications Ethernet Utilitie: Electric Power Production Plant Powermeter IED (Intelligent Electronic Device) Measurement Transformers: Voltage and Current Concentrator / Protocol Converter SITINA Software ISDN / Analog Commuted Network Instrumentation Software Binary ModBus Serial Communications RDMS 4D DNP 3.0 L1 Binary ModBus MacOS / Windows95 Serial Communications WWW Browser SITINA Remote User RS422 Multidrop Figure 1 SITINA s General Architecture Before starting the project we decided to choose a suitable subset of well-known and well-established software engineering methods and techniques. We mean suitable in both the senses that they could help in attaining all the user requirements and also in that they could be used successfully in the organisational context in which SITINA was going to be developed. It was also our own research goal to study them and evaluate their ability to improve the development process and help in solving problems that would arise. Initially we considered the following issues that should be considered in choosing reference models and methods: (i) Maintaining user satisfaction by allowing the system to adapt to changes in user requirements; (ii) Maintaining user satisfaction in terms of usability of the system and time to deploy it; (iii) Adding value to the Software Engineering SME that was used to a just do it process model [6]; (iv) Ability of the project team, in particular developers, to learn and use such new models, methods and techniques; (v) Adaptability of the models, methods and techniques to building an embedded system. In this process we used what we call a catalytic Trojan-horse 3 approach. We introduced in the SME well-known models, methods and tools that have been established for some time and are accessible to regular practitioners. We have 1 EDM, Electricidade da Madeira, is the company that has all the responsibility for electrical production, transport and distribution in Madeira Island. 2 SCADA/EMS technology was introduced about 50 years ago to enable the operation and control of energy production, transport and distribution systems: EMS [5] (Energy Management System): systems that maximise the efficiency of the production, transport and distribution of electric energy; SCADA [3] [4] (Supervisory Control and Data Acquisition): technology that enables a user to collect data and send commands to one or more remote utilities. 3 We use the term Trojan-horse approach to indicate the way we worked within the company. We wanted to gain the developers confidence and we wanted them to know that our main intention was to help them being more productive and more satisfied. The term should therefore be regarded only with its positive connotations, regarding success, as no harm was meant or delivered.

3 not used or evaluated advanced methods and techniques, namely on the object-oriented area. Although they play a substantial role on the software engineering discipline, they were not considered mainstream tools for the regular SME software Development Company or practitioner. Following the same policy, we have not used or evaluated experimental or sophisticated tools and technologies, like version and configuration control, automated metrics or object-oriented databases. Some of these tools and techniques were not available for the development team, and others would have taken a considerable amount of time or other resources to use and integrate. Related work concerning process assessment and improvement efforts, using CMM 1 and QIP 2 in SMEs, clearly concluded that these methods are not suitable to such organisations. Cattaneo et al [7] present a case study of CMM and QIP assessment in SMEs and conclude that "we should define assessment and methodology with a broader vision of the problem (...); it is not sufficient to consider just engineering issues (...), we have to take into account that most software companies are still at a very low maturity level". Brodman and Johnson [8] report about applying CMM in small organisations and conclude that SMEs "want to improve, but they have concerns with being measured against a model whose requirements they cannot rigidly meet". 2. THE PROJECT AND THE PEOPLE 2.1. Organisational Context Three separate institutions were involved in the development of the SITINA system. A customer company with the endusers, the software supplier company with the development and management team, and finally the research institution that co-ordinated the project regarding the software process and the modelling method: analysis, design and implementation of the system. One benefit of our Trojan-horse approach was the capability it gave us to influence directly the way people were going to collaborate and communicate during the system development. Since we required a pro-active attitude from everybody, we suggested that all the entities involved could communicate and collaborate directly. This model (see Figure 2) enabled us to have continuous feedback and to react very quickly to users and developers during the entire system development process. Client Company General Specification Prototype Evaluation Final Tests Research Institution Requirements Analysis Coordenation: ISystem Analysis and Design, mplementation,tests Supplier Company Implementation Installation Tests Maintenence Figure 2 - Organisational Development Context 1 Capability Maturity Model of the Software Engineering Institute. 2 Quality Improvement Paradigm of the University of Maryland.

4 The distribution of tasks indicated in Figure 2 was not defined at the beginning of the project, but was itself a product of the evolutionary process described later on this paper. To understand in detail the conditions imposed by the organisational context, we describe some of the characteristics of the other two institutions and professionals involved in the project: Customer Company: Involved in the project were the actual end-users, mainly senior engineers from the Board of Directors. They were very experienced on the application domain, i.e., power management, but had moderate computer experience, mainly from the users point of view. Their co-operation and comments, during all the evolutionary prototyping process, were always excellent, leading to a considerable amount of suggestions and new features added to the prototypes. Usability of the system was their main emphasis. Supplier Company: It is a good example of the software engineering SMEs. The development team was based on a small number of computer skilled people, without higher degrees, simultaneously involved in several small or medium sized projects. They used mainly the just do it approach, but were aware of other models and methods of software development. They had a strong dependency on the platform and development tool that had been adopted by the project: the MacOS 1 based fourth generation language SITINA s Project Schedule The project ended up having two phases, each one corresponding to the construction of two distinct versions of SITINA. The first version only dealt with two small hydroelectric power plants, but the second version is monitoring all the 10 hydroelectric power plants in the production network. The project had a time to market of approximately 14 months. The project team consisted of 2 people from the Research Institution (RI), 1 project manager, 2 software engineers and 2 hardware engineers from the Supplier Company (SC), and 3 senior engineers from the Board of Directors of the Customer Company (CC). Figure 3 represents the monthly summary of the actual project schedule. Month Tasks RI SC CC (in general terms) (2 Men) (5 Men) (3 Men) 1 General requirements analysis for SITINA V Survey of similar commercial products. Requirement gathering from SCADA/EMS systems General specification and analysis of SITINA V Implementation and design of the 1st SITINA V1 prototype. Select and install data acquisition hardware Partial tests, 1st prototype evaluation for SITINA V1. Analysis and Design iteration (2nd SITINA V1 prototype) Implementation and partial tests for the 2nd SITINA V1 prototype. 2nd prototype evaluation Final tests. Install and deploy SITINA V Evaluation (requirements gathering) and maintenance of SITINA V Evaluation (requirements gathering) and maintenance of SITINA V Final evaluation of SITINA V1. Requirements analysis for SITINA V Analysis and design of SITINA V2 1st prototype. Partial tests and implementation of SITINA V2. Data acquisition hardware installation Partial tests, 1st SITINA V2 prototype evaluation. Analysis and design iteration (2nd SITINA V2 prototype) Partial tests and implementation of the 2nd SITINA V2 prototype. 2nd SITINA V2 prototype evaluation Final tests SITINA V2. Install and deploy SITINA V2. SITINA V2 maintenance Figure 3 - Actual Project Schedule: activities and effort in person.hour 1 Apple Computer Inc.

5 As we can see in the table above (Figure 3), system development tasks included building 4 main prototypes, 2 corresponding to the first version of SITINA (SITINA V1) and 2 to the second version (SITINA V2). The first phase took 7 months and the second 5 months, if we exclude 2 months of evaluation and requirements gathering in-between. We note that task descriptions presented are an indicator of the main activity the team was working on, as the project was much more iterative than one could expect CC SC RI Figure 4 - Effort provided by the Institutions (in person.hour, each of the 14 months) Regarding Figure 4, we can clearly see the increasing effort on the development and on the prototype evaluation tasks. This pattern can be seen in both phases of the project, with a shorter evaluation period in-between. One should stress that the second evaluation period is clearly shorter than the first one. 100% 80% 60% 40% CC SC RI 20% 0% Figure 5 - Effort provided by the Institutions (percentage of total effort, each of the 14 months) In Figure 5 we can clearly see a strong contribution of the research institution in the analysis and design tasks, which decreases in implementation and testing. It is also visible the decreasing influence of this institution as the project evolves. This factor shows the learning curve of the development team, gradually integrating the new models and methods introduced. An important note regarding the end-users participation, in particular in the requirements gathering and prototype evaluation tasks: we can clearly see their continuous participation during the project, obviously excluding the periods of intense implementation.

6 3. THE THEORY In this section we will make a short review of the models, methods, techniques and tools selected for usage in the project, based on our experience and knowledge of the initial characteristics of the Developer Company. We will also mention their main advantages and disadvantages, the ones expressed or that we could anticipate from the theory The Nike Approach to Software Development As mentioned, the approach used by the Supplier Company was based on the Nike approach to software development. Booch [6] refers to this approach on the architectural planning activity of the design phase. He summarises it is the urge to delay building something real until you have a complete knowledge of the problem. This urge leads to a real solution, too late in the development phase, when the problem will likely have changed. On this paper we use the lets do it concept to characterise a process based on a battery of unplanned acts of hacking, with the overall aim of having projects finished with a running application. They are similar concepts, leading to similar practices. The just do it approach lacks the architectural planning, i.e., it is not a planned activity embedded in the development process, but the absence of actual planning. An early survey on the status of the software engineering practice in Portugal [9] showed that more than 70% of software SMEs in Portugal did not use a process model. The Nike approach, in actual use at our case study company, inspired us to define the Trojan horse strategy to introduce productive software engineering practices in that organisation. We wanted to retain the benefits of the Nike approach, namely the practical effect of building something real. We also wanted to prevent its risks, ultimately the institutionalised chaotic environment, which is not sustainable in the long term, and often leads to the team building the wrong thing Evolutionary Process Model Evolutionary development [10] was the general software engineering model chosen to approach the problem. By using this model, based on an iterative cycle of analysis/design and implementation, followed by user comments and validation, we tried to cope with the inability to gather specific and objective user requirements. On the other hand, we wanted the system to be as close to user expectations as possible, and the process to react quickly to requirements change. From the perspective of the development team, the lack of any process model imposed a steep learning curve of the model introduced. The evolutionary model was closer to the just do it model the company was used to, i.e., it was the only option between no model at all, and more strict models like the one in the waterfall approach. Other key factors that suggested this option were the required short delivery schedule, the relative inexperience on the application domain of developers, and finally, all of the platform and development tools' weaknesses (MacOS platform and 4 th Dimension) regarding integrated tools to support standard or advanced models. There were, however, some problems we anticipated when choosing this model. One is the classical bad structure of the applications produced under this kind of approaches, mainly caused by the iterative process; the other was bad process visibility, i.e., it would be difficult to measure process evolution and progress towards the final solution. Both these problems were anticipated, and we tried to restrict their adverse impact on the project using object-oriented analysis and design methods and CASE tools.

7 3.3. Evolutionary Prototyping The evolutionary process model has a privileged application with prototyping techniques, although it can be used with other techniques like exploratory development [10] on the AI domain. Key factors for selecting prototyping techniques were the experience of the development team with a 4th generation tool [11] and its integration with the evolutionary model itself. Badly defined requirements and user satisfaction were other factors in mind when selecting evolutionary prototyping as the fundamental paradigm. The success of evolutionary prototyping is mainly based on careful selection of tools and techniques that provide a fast iteration process, enabling the integration of user suggestions and comments. Another key issue on prototyping is system validation and verification. Verification can only be done when we have a well-defined system specification. System validation, on the other hand, can be done during prototyping delivery Object-Oriented Analysis and Design Methods (OOADM) When we selected OOADM, we wanted to cope with the lack of visibility and the bad system structure of the evolutionary approach. Since OOADM base their strategy on encapsulation, viewing the system as a set of interacting objects, we could use this characteristic to provide a strong abstraction layer to the development team. This abstraction level should also benefit from other object-oriented paradigm characteristics [12] and from the clear method notation, enabling all the participants to interact on system analysis. Our main goal was then to balance the problems of the evolutionary approach with the discipline of the OOADM, in such a way that developers and users could benefit from a clear common notation, and visibility could be qualitatively measured 1 with analysis and design diagrams. Diagrams also maintain the system structure enabling the use of analysis and design patterns and CASE tools. Although only using OOADM could not prevent bad system structure, its use enables a more stable system rewrite policy, keeping the evolutionary effort intact. There are many OOADM [14], and for the present project we selected OMT (Object Modelling Technique) from Rumbaugh et al [15]. The main reasons for selecting OMT were the following: It is an easy to understand method with a good learning curve, this is a key factor since the development team and the end users had little or no contact with OO methods; The static model as a very clear notation, somewhat similar to the relational model (i.e., there is usually a simple mapping to a relational schema), the only model known by the development team; Its dynamic model uses one of the most expressive notations Harel Statecharts [16], this factor is extremely important for modelling communication protocols, an important part of SITINA; It is reasonably well supported by commercial CASE tools [17]; 3.5. CASE Tools CASE tools were expected to introduce productivity gains similar to the ones achieved with the introduction of CAD tools on other engineering disciplines. However, the real impact of CASE tools has been far from what we would expect [18]. CASE tool efficiency depends mainly on its adjustment to the problem domain and to the analysis and design method used. On the other hand, the tool needs an adequate support from the supplier since it will be used through all the system life until its obsolescence. Other key factors include integration with the development environment and

8 proper user training. The CASE tool we selected was Rose 1. The main function of the tool was to maintain conceptual OMT models throughout the evolutionary process and enable future versions of the product to evolve from this repository. The development tool (4GL) was used in all the implementation tasks involved in the project, from code editing to database and user interface design. 4. FROM PRACTICE TO THEORY: LESSONS LEARNED This section presents the lessons learned from our experience with the SITINA project, regarding the models, methods and techniques mentioned before Regarding Evolutionary Prototyping As mentioned before, evolutionary development and prototyping techniques are closely coupled models, usually used together and having therefore common problems. These problems are well identified and documented in [10], [19], [20], [21] and [22]. We will mention below those we met during the project development, together with some ideas or workarounds used and tested on this experience. (i) Visibility is reduced and regular deployments are required to measure progress. Although several authors mention this problem as a cause for systems high cost and increased deploying time, our experience was quite different. OMT and prototype evaluation used together enabled the development team and the users to measure progress; the conceptual models and diagrams enabled communication between end-users and the development team. The 4GL, although limited and without CASE tool integration, was an excellent development tool for rapid prototyping. The development team could easily integrate users requirements and let them experience different interfaces. From our perspective regular testing deployments was not a problem, on the contrary, it was a key issue for project success and user satisfaction. (ii) End systems are badly structured. This was a problem, but again OMT and the CASE tools provided the basis for system stability. Conceptual models enabled the team to track system analysis and design, keeping in mind the requirements. The 4GL enabled the team to quickly rewrite parts of the system, reacting to requirement changes. The major problem here was the lack of integration between the conceptual models (CASE tools) and the actual code (4GL). A great effort was needed to keep the conceptual models up-to-date. Another key factor was the prototype objectives, as it was very important, for overall system stability, to keep them always in mind, maintaining objectives already achieved from other iterations and focusing only in the new ones. This policy prevented the development team from rewriting the system each time a prototype was evaluated. (iii) You need highly qualified people. The impact of people's qualification in the software process is not fully studied and it was not our intention to do so. The work of Bach [23] highlighting the human factor on the software development process and the idea of heroes opens some interesting discussion points. Nevertheless, it seems clear that this evolutionary prototyping approach is more suitable for small highly motivated teams, working on small/medium scale projects. Communication between practitioners and between the development team and end-users was definitely a key factor for project success. 1 Quantitative approaches to process visibility measurement can be adapted from proposals like the Personal Software Process (PSP) [13].

9 4.2. A new Proposal for Evolutionary Prototyping The evolutionary approach did well on almost all aspects of the development process and it adapted well both to the organisational context and to the problem. As long as its weaknesses are well identified and workarounds planned in advance, this approach can be effective. Application Domain Analysis Organisational Context Analysis General System Specification OOADM selection Tools selection Prototype goal definition Design decisions Prototype implementation Analysis Models Partial tests Prototype evaluation Prototype adequate? No Yes Final Tests System Delivery Figure 6 - Refinement Proposed for the Evolutionary Process Model The model proposed (see Figure 6) enables the team to retain strategic functions of scheduling, risk management, and visibility, creating a sustained and contained context to use the Nike approach on the design and implementation level. Therefore, the development team is capable of integrating a more robust process model with minor changes to its habits and experience. The robustness of this refinement relies on four factors not considered in the base model [10]: (i) Start from the organisational and application domain analysis, not from the abstract problem specification. This factor ensures the development team and the end-users are aware of the model to be used and agree to follow an evolutionary approach. This approach also guaranties that application domain issues, like architectural and important design decisions, are evaluated before an actual problem specification can be stated. (ii) Careful selection of methods and tools is done before we enter the iterative cycle. This selection depends on the problem and organisational issues not on the process itself. (iii) On each iteration of the process we define and evaluate prototype objectives, facilitating risk management and project scheduling. 1 Rational Corporation

10 (iv) Last but not least, we propose the maintenance of design decisions and analysis models in the process model itself. These issues, preferably maintained by automated tools, enable process visibility and maintenance, retaining the system structure OMT (Object-Modelling Technique) The development process confirmed all the selection factors for OMT. There were, however, some problems with the method: (i) Functional decomposition on the architectural model [14] is clearly unsatisfactory for an object-oriented method; (ii) OMT has a weak support for external and user-interface modelling. Although UML [24] partially solved this problem integrating use-case diagrams from Jacobson [25], OOADM in general, still lack a good support for user interface design. Key issues are related to the mapping between the objects and actions from the task to the interface domain and the internal objects. Some of the problems could have been corrected if we had used UML as the OOADM, but, when the project started, in early 1996, UML was not sufficiently mature to be used. Information was scattered by tutorials and draft papers, clearly not stable enough to enable the development team to learn and use them effectively CASE Tools As we mentioned before, CASE tool integration played a major role controlling some of the problems of the evolutionary prototyping approach. The major problem was the lack of integration between the 4GL and the analysis and design support tool. Clear integration between these two kinds of tools [26], as mentioned by Forte [27] on a revision of 4GLs, can be a major benefit for process visibility, maintainability and comprehensibility. In this experience we learned that CASE tools, not only affect working practices, but also tend to be abandoned after an initial time of use 1. We think the integration with the 4GL could prevent this effect and increase CASE tool penetration in SMEs environments. The 4GL performance was also a key factor on process improvement and model support. The superior abstraction level of such languages (as opposed to 3GLs [28]) increases implementation productivity by accelerating code production, debugging and maintenance. The integration of user interface design and database access with these tools enables the development team to quickly react to user feedback. 5. CONCLUSION AND FUTURE DEVELOPMENTS This case study allowed us to evaluate the performance of the software engineering discipline when applied to a typical problem, involving typical people, companies, tools and products. We tried to adapt the software engineering theory to the organisational (and social) reality of the Nike approach. The careful selection of models, methods, techniques and tools and its use in reality requires that we know the people that will use them, their habits, the way they work together, their qualities and weaknesses. Only then must we evaluate the problem and the end-users' expectations, assuring good communication channels between all the parties involved in the software development process.

11 The experience described in this paper also highlights evolutionary prototyping as a real alternative for software development, and a good rescue capsule to the Nike process model. Prototyping has always been a successful model in other engineering disciplines but we believe that its potential has always been underrated in the software engineering field. Its well-documented weaknesses, instead of being a problem, enable the practitioners to plan before using the model. The real key issue to prototyping success is to use other software engineering techniques and tools to control the process and maintain stability. Object-oriented analysis and design methods enable the practitioners to maintain visibility and control the structure of the system. They also enable users to interact with a clear common notation on system analysis and design. 4GLs enable rapid application development quickly integrating user requirements on the iterative evaluation process. Finally CASE tools, although not still well integrated with most of the current development tools, can bridge rapid development with systematic and careful analysis and design, maintaining conceptual models and enabling process verification, validation and progress measurement. The case study presented here showed us that success in SMEs process improvement is indeed possible. We believe it comes when we can improve our theories by applying them to the real practice. We feel it is possible and indeed desirable to generalise some of our results by evaluating them in a different SME context. 6. ACKNOWLEDGMENTS Nuno Jardim Nunes was partially supported by the FCT (JNICT), Praxis XXI national research project 2/2.1/TIT/1662/95 - SARA ("Society of Animated and Responsible Agents"). João Falcão e Cunha was partially supported by JNICT with grant BLS 47-P REFERENCES [1] Nunes, N., Cunha, J. F., SITINA: Report on a Supervisory and Decision Support System for the Hidroelectrical Power Plants in Madeira Island, Internal Research Report, UMa-T&B, [2] Nunes, N., SITINA Technical Manual - Architecture, Internal Technical Report UMa-T&B, [3] Boyer, S.A., SCADA: Supervisory Control and Data Acquisition, Instrument Society of America, [4] Strock, O.J., Rueger, E.M., Telemetry Systems Architecture, Instrument Society of America, [5] Turan Gonen, Electric Power Distribution System Engineering, MacGraw Hill, [6] Booch, G. Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, [7] Cattaneo, F., Fuggetta A., Lavazza L., An Experience in Process Assessment, Proceedings of the ICSE 95, pp , IEEE Computer Society, [8] Brodman, J., Johnson, D., What Small Businesses and Small Organisations say about CMM, Proceedings of the ICSE 94, pp , IEEE Computer Society, [9] Nunes, N., The Status of the Software Engineering Practice in Portugal - A Survey to the Small/Medium Sized Companies, Draft internal research report, [10] Sommerville, I., Software Engineering 5ed, Addison-Wesley, [11] Forte, G., Tools fair: out of the lab, onto the shelf, IEEE Software, 9(3), 70-9, [12] Booch, G., Object Oriented Analysis and Design with Applications 2ed., Benjamim/Cummings, [13] Humphrey, W., A Discipline for Software Engineering, Addison-Wesley, This effect was observed on post-project discussions with people from the company. They continued to use OMT and even started to embrace UML, but they are also shifting from Rose to a simple drawing program.

12 [14] Fowler, M., A Comparison of Object-Oriented Analysis and Design Methods, in OOPSLA 95 (Tut.12), [15] Rumbaugh, Blaha, Premerlani, Eddy, Lorensen, Object-Oriented Modeling and Design, Prentice Hall, [16] Harel, D., Statecharts: a Visual Formalism for Complex Systems, Science of Computer Programming [17] CASE Tool Index, URL: [18] Iivari, J., Why Are Case Tools Not Used, Communications of the ACM, 39(10), October [19] Pressman, R., Software Engineering - A Practitioner s Approach, 3rd Ed. Eur. Adapt., McGraw-Hill, [20] Humphrey, W., Managing the Software Process, Addison-Wesley, [21] Gordon, S., Bieman, J., Rapid Prototyping: Lessons Learned, IEEE Software, 12(1) January [22] Luqi, Royce, W., Status Report: Computer-aided Prototyping, IEEE Software, November [23] Bach, J., Enough About the Process: What we need are heroes, IEEE Software 12(2), [24] Rational Software Corporation, UML Summary, [25] Jacobson I., Christerson M., Jonsson P., Overgaard G., Object Oriented Software Engineering: a use case driven approach, Addison-Wesley, [26] Fuggeta A., A Classification of CASE Technology, IEEE Computer, December [27] G. Forte, Tools fair: out of the lab, onto the shelf, IEEE Software, 9(3), 70-9, [28] Matos, V., Jalics, P., An Experimental Analysis of the Performance of Fourth Generation Tools on PCs, Communications of the ACM 11 (32), 1989.