VTT Electronics VTT Electronics Kaitoväylä 1 P.O.Box 1100, FIN-90571 OULU, FINLAND
Tel. + 358 8 551 2111 Fax. + 358 8 551 2320 http://www.ele.vtt.fi
http://www.ele.vtt.fi/projects/finesse
2EMHFW2ULHQWHG$SSURDFKLQ3URFHVV ,PSURYHPHQW([SHULPHQWV
Disseminating European Experiences in Finland Deliverable 3.1
,1752'8&7,21
$3352$&+
7+(2%-(&725,(17('$3352$&+,1352&(66,03529(0(17(;3(5,0(176
3.1. 3.1. REDUCING TESTING TIME AND IMPROVING SOFTWARE QUALITY...5
3.2. 3.2. IMPROVING SOFTWARE PRACTICES AND THE REUSE OF EXISTING CODE...7
3.3. 3.3. IMPROVING SOFTWARE QUALITY...9
3.4. IMPROVING THE SOFTWARE DEVELOPMENT PROCESSES...11
3.5. IMPROVING THE BUSINESS PROCESS...12
6800$5<
)857+(55($',1*6
5()(5(1&(6
$33(1',;/,672)86('$&521<06
$33(1',;&$6(&203$1,(6&217$&7,1)250$7,21
,QWURGXFWLRQ
This research report is a deliverable of the Finesse project (Esprit project No. 27752). The aim of the Finesse project is to foster software process improvement experiments in Finland, and, at the European level, the focus is on the dissemination of the experiences gained in Finnish software process improvement experiments. Object-orientation was chosen as a topic for this research, since it has aroused great interest in software industry and its use is increasing continuously. Companies have a need to know how OO has been adopted in organisations and what kinds of positive and negative experiences have been gained during the introductions. This research report makes an attempt to answer the most common questions related to the adoption of the object-oriented approach in industry. The results of this report will be published in Finesse Newsletter, which will be distributed to Finnish software organisations in September - November 1999.
The main goal of this report is to inform Finnish software industry of the experiences of five European software companies which have adopted object-oriented methods and tools during Process Improvement Experiment (PIE, ESSI) projects. This is done by utilising and elaborating the results of the SISSI-project (ESSI Project No. 24151) [1], for which 50 case studies on ESSI software improvement projects were collected, along with the final reports of the projects from the ESI database [2]
$SSURDFK
A total of five cases were selected for this report. Two cases were picked out of the case studies collected in the SISSI project [1] and three of a collection of links to the ESI database [2] created by the Large Scope Dissemination project [3]. These cases were selected for the purpose of presenting experiences gained in different countries and industrial sectors, with different organisation sizes, application domains and processes. To ascertain the sufficiency of background information we made sure that either the final report or the SISSI report and the final report of the selected projects were available in the ESI database. The selected projects are described in Table 1.
7DEOH6HOHFWHGFDVHVWXG\SURMHFWV
&DVH1DPH 2UJDQLVDWLRQDQG
&RXQWU\ 6WDUW
<HDU %XVLQHVV6HFWRU
$SSOLFDWLRQ$UHD 0HWKRGRORJLHVDQG 7RROV8VHG Reducing Testing
Time and Improving Software Quality
LMS International, Belgium
1994 Noise and Vibration CAE software / Object-oriented Design and Development
OMT, C++, Purify, Quantify
Improving Software Practices and Reuse of Existing Code
TT Tieto Oy, Finland 1994 Public Sector / Library software
ODB++, C++, OMT
Improving Software Quality
Knapp Logistics Automation, Austria
1996 Machinery, electrical and optical instruments / Computer controlled conveying systems, picking plants and logistics for warehouses
Object-oriented analysis, object
oriented design, use cases, OMT, Booch, Jacobsen,
Improving Software Development Processes
MaXware AS, Norway 1997 Business Oriented Systems / Message handling system
OMT/UML, C++, Rational Rose
Improving Business Process
Gabor Shoes, Germany 1997 Shoe Industry (production and distribution) / MIS, administrative data processing
Rapid prototyping, object- oriented programming, user interface
7KH2EMHFW2ULHQWHG$SSURDFKLQ3URFHVV,PSURYHPHQW([SHULPHQWV
The case companies in this report represent various industrial sectors. Belgian /06 ,QWHUQDWLRQDO [4; 5] is a company specializing in developing CAE software in the field of noise and vibration analysis. The number of staff is over 330. The Finnish state-owned 5HJLRQDO*RYHUQPHQW6\VWHPV/WG group, 97..5*6 [6; 7], operating within TT Tieto, is a software group, representing various products for public administration purposes, library services, school systems, social services, health care systems and data systems for church practices. The group has 170 employees. The Austrian .1$33 /RJLVWLFV $XWRPDWLRQ
*HVPE+ [8; 9], produces computer-controlled conveying systems and focuses on picking installations and logistics for warehouses in the fields of pharma industry, tobacco and compact disks. The company employs 286 people. 0D;ZDUH $6 [10], a Norwegian company, develops advanced electronic messaging systems, e.g. e-mail and fax solutions.
The number of employees is about 100. *DERU 6KRHV $* [11] is one of the leading manufacturers of ladies shoes in Germany. The company employs a total of 3 300 persons in three countries (Germany, Austria, Portugal).
5HGXFLQJ7HVWLQJ7LPHDQG,PSURYLQJ6RIWZDUH4XDOLW\
LMS International wanted to reduce the amount of time used for testing software and wished both to maintain and to improve its software quality. There were a number of challenges the company was facing in the software market, one of these being that computer hardware, operating systems and standards are constantly changing. These challenges affected the issues of code maintenance, reusability and portability, which were poorly supported in the company’s existing software development process [4]. In the project, the major reasons for introducing the OO approach were: "(1) the highly modularised structure of OO does make it easier to manage (changes can be more efficiently applied); (2) object represent isolated data, which has a high potential for reuse, allowing OO software to be developed more efficiently (and hopefully faster), and (3) OO entities can to a large extent be developed and tested by separate teams or individual programmers (better team work)" [5].
Once the decision was made to introduce OO, the selection of OMT as the methodology was natural. OMT was considered a well-known method, largely used in practice, supported by
many CASE tools and it was based on the same concepts as the Yourdon methodology, with which the company was, to some extent, already familiar with. The PIE also evaluated various supportive and implementation tools (Unix-based) that were to be used in a pilot project. [5]
A 4-day training on fundamental OO issues was held in connection with a 3-day hands-on workshop on OO Analysis and Design (OMT). In addition to this, advanced C++ training was given, along with some smaller training courses (e.g. on advanced OMT analysis) for LMS development engineers. It was clear that the intensive training and workshop on C++
and OMT did improve the OO design and programming skills of developers, although the 3- day workshop was considered to be laboured, and separating it from the theoretical part of training was afterwards thought to be an unsuccessful solution. Shifting from a functional way of thinking towards an OO approach was also thought to require a lot of on-the-job training. [5]
The project results proved that adequate up-front design work was likely to reduce the testing effort. Before adopting the object-oriented design and implementation methods, the completion of requirements and specifications had taken only 9 % of the time used on the whole project. The design period had required even less, 5 % of the total time. 51 % of the time had been used for implementation, while testing had taken 35 % of the time. After adopting the object-oriented method (during the process improvement experiment) the values looked slightly different: of the total time used on the whole project, the share of requirements and specifications was 12 %, design 21 %, implementation 55 % and testing 12
%. However, the company realised that the object-oriented method could not, as such, guarantee software quality; to be able to make full use of the benefits, the company needed qualified people equipped with professional tools [4]
The software methodologies developed during the process improvement experiment have been adopted into the quality assurance system of the company. Since undertaking the experiment, LMS International has achieved the ISO9001 certification, which is most likely to make a positive impression on the customers. [4]
,PSURYLQJ6RIWZDUH3UDFWLFHVDQGWKH5HXVHRI([LVWLQJ&RGH
The Regional Government Services group (VTKK) within TT Tieto wanted to address the demands of its customers concerning the PALLAS software for libraries. The aim was to be able to provide several different pricing solutions for the customers. This was planned to be achieved by introducing object-oriented methods and tools in the organisation when building new applications on top of existing databases and systems. The experiment was expected to result in new mature practices and an increased reuse of existing code. [6; 7]
VTKK was also participating in the JOO project, which studied various object-oriented design and programming methods available. The project recommended OMT, i.e. Object Modelling Technique, OMT, due to the fact that OMT covers the software engineering life cycle, it is well-known, widely used, and the object models had similarities with the ER- model. The technique was chosen together with OMTool, the supporting modelling tool, which was planned to be used in the analysis and design phases of the baseline project. [7]
From a limited set of possible programming tools, Microsoft Visual C++ was selected to be used in the baseline project. C++ matched the objectives of the application experiment and met the requirements set by the group for object-oriented programming, database independence and graphical user interface. In addition, the ODB++ Database Class Library was taken into use, as the participants of the JOO project thought it would effect meaningful savings in the programming phase, compared to plain ODBC programming. [7]
The company arranged a short training period for the participants. The courses included the basics of o-o design and programming, OMT method and OMTool, C++ with MFC and ODB++ class libraries. The baseline project team and developers from other departments attended the course. After the course, the developers were able to start working with the new environment. [7]
The key lesson learned from the technological point of view was that object-oriented culture and object libraries were found a promising approach to a productive reuse of previous efforts. However, the reuse of code does not generate by itself, it does have to be designed.
Object-oriented technologies and C++ environments were thought to provide possibilities for
an "effective and creative software development". The major problem with the object- oriented technology was that the time it took for the developer to mature in the new technology was considered rather long. [6; 7]
The step between the C and 4GL programming languages and the object-oriented language (C++) sometimes seemed too strenuous an effort for the group members. The transition from C to C++ was considered more natural than the transition from 4GL to C++. The group also spent a lot of time overcoming the initial bugs in the programming systems (Visual C++ and ODB++), which made the task even harder. Demands on fast results led to non-object- oriented structures in code, which was transported from C code to the new application. The overall reaction with the project team towards the new technology was described as
"confusion caused by the overwhelming amount of new material". More training on the programming environment and C++ would have been beneficial for the whole project team.
After the project, the group has taken new development environments into use (Java and Delphi) and these new tools have been found capable of solving a lot of the earlier problems.
[6; 7]
The most important lesson learned was that the company realised the importance of experts.
During the project an external contractor was used, who provided the company with his expertise. After the project the employees had to gain experience by themselves. This led to changes in the business process: the ’right’ people were allowed to share their experiences with others and to give expert advise. This new structure was called ’the centre of excellence’. [6]
To conclude, experimenting with object-oriented technology resulted in a 40 % reduction in the schedule and effort at VTTK. The project succeeded in using different databases without having to change any of the source codes. This allowed the group to offer variously priced applications for different levels of performance, and thus to extending their potential customer base. [6]
,PSURYLQJ6RIWZDUH4XDOLW\
The objectives of the experiment in KNAPP Automation Logistics were: the improvement of software quality, the reduction of development costs in terms of reusability, the improvement of technical software documentation, better estimation of expenditure and deadlines as well as increasing the motivation of the developers. [9]
At the beginning of the experiment, a Bootstrap assessment was performed. To the disappointment of the company, the results were rather poor compared with similar companies in German-speaking countries. The process was defined exactly for non-object- oriented processes, but it suffered from too much bureaucracy and paper work in general.
One-person projects were performed without any guidelines at all. The process showed deficiencies in the fields of project control, training of the team and testing of software modules. For these reasons, defining an appropriate object-oriented process was thought to be essential for handling projects of various sizes. An iterative lifecycle model for OT projects was expected to result in improved project control and estimation. [9]
To reach the goals set for the experiment, software tools were introduced in the development process. The Rational Rose tool for analysis and design purposes was acquired, because it supported both the Booch methodology and OMT (further version also supported UML).
Another goal was to support the portability of the software. The company wanted to be able to cope with different hardware platforms as well as the operating system under which the software was used. Database independence was also desired. Due to the portability requirements, the company wanted to use platform-independent tools, programming languages that were available for different computer systems (C++), and commercial libraries providing connectivity for the most common database systems (DBTools++).
Courses were given on Object-Oriented Analysis and Design using Booch, and an advanced C++ (focusing on the design of applications). In addition, internal seminars were held in order to transfer the knowledge of those developers who attended the above-mentioned courses to the ones who did not. [9]
Overall, the results were really promising. The company found the Booch methodology to be a highly comprehensive dynamic component. It was also considered to offer a more
descriptive object model with its expanded dynamic components than OMT, which was, for its part, found very useful in client-server applications. Booch, however, requires habituation, and therefore a parallel use of OMT’s class diagrams is possible. Rational Rose was evaluated as a suitable tool for analysing and outlining any problems concerning the applications of the company. The PIE project created a new, incremental software process based on the object-oriented paradigm and defined a metric suite with metrics for design and quality. [9]
The experiment produced some promising reuse rates with different layers (for example, on database layer, a reuse rate of nearly up to 70 % was achieved for the communication framework). The PIE project considered an error rate reduction of 20 % to be more than realistic, which would also further decrease the maintenance costs. [9]
As a result of the project, four technical conclusions were drawn [9]:
• A complete object-oriented method supporting the full life cycle must include a preliminary analysis provided by Jacobsen use cases. This was not supported by the Rational Rose version that was used in the study.
• The transformation to OT was found to require an adopted project management, which was also refined during the experiment.
• Evaluating various object-oriented CASE tools was thought to need a roadmap for testing and finding the differences of the individual features of the tools.
• Developing object-oriented frameworks (to provide effective reuse of communication and graphical user interfaces) is significantly more difficult than developing individual application classes. There is also a documentation problem; a poorly documented concept will probably never be reused.
Another lesson learned was that the transition to OT must be done step by step. It was thought that "the benefits did not appear in the pilot project but if everything was done correctly, the investment would certainly pay off". The PIE suggests that the adoption of OT
should be started from a small project and then be scaled up. In any case, the fact that success depends on the people developing the software should never be forgotten. The motivation of developers in this case was highly increased when changing over to OT. The domain analysis has also improved through the process. The customers are now able to better understand the created class models and use cases. [9]
The overall conclusion of the work done can be recapitulated in the following statement:
"OT is a very promising approach worth pursuing, but still no "silver bullet" solution" [9].
,PSURYLQJWKH6RIWZDUH'HYHORSPHQW3URFHVVHV
The objective of this case project was to test if MaXware could increase the quality of the product and reduce the development time and costs by introducing object-oriented method for analysis, design and development. The PIE wished to make the development and maintenance processes more efficient. [10]
The process was planned to be improved by using the OMT object-oriented method and the UML modelling language (Unified Modelling Language) and also introducing the Rational Rose tool, object-oriented frameworks and class libraries. Training in object-oriented techniques was given to the baseline project members. [10]
There is no evidence of any short-term influence of the PIE project on MaXware’s businesses, but the participants of the PIE thought that there would be positive long term effects due to the continued use of OOAD and improved quality. It was considered difficult to separate the contribution of the PIE from that of OOAD, because it was likely that the method would have been introduced in any case. The unique contribution of the PIE was the introduction of measurements to monitor productivity and quality. [10]
The measurement analysis between pre-PIE and after-PIE projects did not show any improvement in development time and costs. Productivity remained at approximately the same level as before the project, even though OOAD was in use. However, the costs of finding and correcting errors in projects were reduced when using OOAD. It has become
evident after the PIE that the extra effort deriving from training has been compensated by a higher productivity in later projects. [10]
,PSURYLQJWKH%XVLQHVV3URFHVV
The overall objective of the Gabor Shoes company was the introduction of an object- oriented software development methodology along with the supporting CASE tools. The specific objectives with this PIE were to reduce cycle time, to reduce overall development costs, to react more rapidly to the changes in their business processes and to integrate their users more efficiently into the development process. 15 employees were responsible for the software development and maintenance. The company was expecting to gain a faster reaction to changing requirements because of shorter development times, as well as a higher quality of resulting program code due to reduced redundancies. [11]
The PIE chose the SELECT Enterprise toolset for CASE support, because it was considered to be a proven, widely used object-oriented analysis and design tool. The company also introduced a development environment called Obsydian. This environment was chosen largely because it allowed code generation for the platform used in the company (IBM AS/400) from object-oriented analysis and design. [11]
A total of 21 days of formal training, including a workshop, was given to the developers.
The period included a familiarization with both the method and the tools. External consultants assisted the PIE team in selecting the tools and during the training courses. [11]
Initial development efforts right after the training, when the developers were still getting familiar with the new development environment, required a longer time than before, but after that the company experienced a dramatic increase in productivity. Another result was an improved understanding of the source code. The introduction of the object-oriented method has also supported the business processes. With an object-oriented paradigm, any modifications to the application concerning allocation and de-allocation of production machines are relatively easy to carry out. The new functionality is gained by reusing the existing database. The integration of the end-users desires was also achieved. Thanks to Obsydian, the communication between the end-user and developers was significantly improved. The developers were now able to demonstrate the prototypes created after the
analysis phase to the end-users, thus fine-tuning the interface before any coding was done.
Obsydian also supported re-engineering of the existing legacy applications. [11]
The experiment proved that it was possible in an enterprise, which was not focusing on producing software, to use modern software development methods and tools, but only if the enterprise allocated enough time and sufficient resources for the transition. Experts were considered valuable in the transition phase and the involvement of end-users was thought worthwhile in demonstrating the potential of the new technology. [11]
The object-oriented method also made the development process a less linear one. An iterative process was found to be more effective in this case. It is expected that developers will return to previous phases and modify them based on the increased knowledge about the subject in matter. [11]
The key lessons learned from the experiment concerned four areas:
• The involvement of the end-users in the development of applications
• The documentation of the development
• The understanding and structuring of data
• The reuse of software components
From the business point of view, the effect of the experiment can be seen only in a mid- to long-term period of activity. The participants of the PIE project were expecting improvement in software quality and a reduction of maintenance efforts. As a whole, it was thought that the experiment had been useful and that the objectives set for it had been met. In the future the enterprise was planning to develop a strategy for a complete transition to an object- oriented software development process. [11]
6XPPDU\
The five cases presented in this report show that the object-oriented methodology and tools can be used in various contexts and for various tasks during the PIE’s. The project companies were employing various tools together with object-oriented methods, for example C++, OMT, Booch methodology and different class libraries. The results of adopting the object- oriented methodology were very positive overall, although some problems were faced during the introductory phases. Learning the object-oriented method is a challenging task; and during the introducing period the employers of the method tend not to be as productive as usual. The steep learning curve is often connected to object-orientation, and its effect on productivity should not be underestimated. Selecting an appropriate tool is essential, not only from the learning point of view, but also for the productive side;- using the right tools may, as such, increase productivity. The experiences of adopting an object-oriented methodology in the five cases presented are summarised in Table 2.
7DEOH3,(H[SHULHQFHVRIDGRSWLQJDQREMHFWRULHQWHGPHWKRGRORJ\GXULQJ3,(V
1R 0HWKRGRORJ\UHODWHG 7UDQVLWLRQWR22UHODWHG 7RROUHODWHG 5HWXUQRI,QYHVWPHQWUHODWHG 2WKHU
1 · The process of introducing OO in
a software development organisation is critical, since it involves retraining the development staff, and during this period the developers are less productive.
· Shifting from a functional way of thinking towards an OO approach requires a lot on-the-job training
· Selecting an appropriate tool is essential.
· Time used for testing reduced from 35 % to 12 %
· Since undertaking the application experiment, the company has achieved the ISO9001 certification.
· TheOO method does not equal to software quality; "to see the benefits the company needs good people and good tools too".
2 · The reaction to the new technology was a confusion caused by the overwhelming amount of new material.
· The benefits of adopting the object-oriented methodology cannot be realised during the initial adoption period because of the steep learning curve
connected with object- orientation.
· OO culture and object libraries were are the way to a productive reuse of previous efforts, but the reuse of code does not appear by itself, it has to be designed.
· OO technologies and C++
environment provides possibilities for effective and creative software development
· Α 40 % reduction on schedule and effort
· The role of the experts was highly valued
· Different tools taken into use after the PIE have solved a lot of problems faced with the tools introduced during the PIE.
3 · TheBooch methodology is a very comprehensive dynamic component and more descriptive than OMT.
However, it requires habituation.
· The transition to OT should happen step by step.
· The switch to OT needs an adopted project management.
· Evaluating various CASE tools requires a roadmap for testing and tracking down the differences of the tools.
· Developing object-oriented frameworks was found significantly more difficult than developing individual application classes.
· The benefits do not appear in the pilot project, but, if done correctly, the investment will certainly pay off.
· The PIE suggested that a complete object-oriented method should include a preliminary analysis provided by use cases (as UML now does).
1 LMS International , Belgium; 2 TT Tieto, Finland: 3 Improving Software Quality , Knapp Logistics Automation, Austria
1R 0HWKRGRORJ\UHODWHG 7UDQVLWLRQWR22UHODWHG 7RROUHODWHG 5HWXUQRI,QYHVWPHQWUHODWHG &RPPRQ
4 · The PIE found no evidence of
improved development time or costs through the adoption of the methodology. Productivity remained approximately at the same level as before the project.
· It was cheaper to find and to correct errors in projects using OOAD.
· After the PIE, it became evident that extra effort deriving from training had been compensated by higher productivity in later projects and activities.
· OOAD was expected to contribute to improved software development in the future.
5 · The object-oriented method makes the development process a less linear one, which in turn makes software develop more efficient.
· With the help of the Obsydian tool, the communication between the developers and the end-users improved, since the tool made it possible to demonstrate the prototypes after the analysing phase before any coding was done.
· Initial development efforts right after the training, when the developers were still getting familiar with the new
development environment, took longer than before, but later the company experienced a dramatic increase in productivity.
· The understanding of the source code improved.
· Experts were thought to be valuable in the transition phase.
4 Improving Software Development Processes, MaxWare, Norway; 5 Improving Business Process, Gabo
)XUWKHU5HDGLQJV
Further information of the cases presented in this report can be found from the web addresses as presented in Table 3.
7DEOH6,66,FDVHUHSRUWVDQG)LQDOUHSRUWVRIWKH3,(VSUHVHQWHGLQWKLVUHSRUW
&DVH1DPH :HEDGGUHVVHV6,66,UHSRUW)LQDOUHSRUW
Reducing Testing Time and Improving Software Quality, LMS International
(1) http://www.esi.es/VASIE/Reports/All/24151/23.pdf (2) http://www.esi.es/ESSI/Reports/All/10995/Report/10995.pdf Improving Software Practices and Reuse of
Existing Code, TT Tieto
(1) http://www.esi.es/VASIE/Reports/All/24151/22.pdf (2) http://www.esi.es/ESSI/Reports/All/10828/Report/10828.pdf Improving Software Quality (2) http://www.esi.es/ESSI/Reports/All/21358/Report/21358.pdf Improving Software Development Processes (2) http://www.esi.es/ESSI/Reports/All/23845/Report/23845.pdf Improving Business Process (2) http://www.esi.es/ESSI/Reports/All/24198/Report/24198.pdf
5HIHUHQFHV
[1] Software Improvement Case Studies Initiative.
http://www.esi.es/VASIE/Reports/All/24151/Download.html [2] ESSI Projects. http://www.esi.es/ESSI/Reports/
[3] Large Scope Dissemination. Object-Oriented Methodology in Process Improvement Experiments Case Studies. http://www.lsd.org.uk/e-oomet.htm
[4] LMS International, Project’s SISSI Case Study Report.
http://www.esi.es/VASIE/Reports/All/24151/22.pdf [5] LMS International, Project’s Final Report.
http://www.esi.es/ESSI/Reports/All/10995/Report/10995.pdf [6] TT Tieto, Project’s SISSI Case Study Report.
http://www.esi.es/VASIE/Reports/All/24151/23.pdf [7] TT Tieto. Project’s Final Report.
http://www.esi.es/ESSI/Reports/All/10995/Report/10995.pdf [8] KNAPP Logistics Automation, Short Project Introduction.
http://www.cordis.lu/esprit/src/21358.htm
[9] KNAPP Logistics Automation, Project’s Final Report.
http://www.esi.es/ESSI/Reports/All/21358/Report/21358.pdf [10] Maxware, Project’s Final Report
http://www.esi.es/ESSI/Reports/All/23845/Report/23845.pdf [11] Gabor Shoes, Project’s Final Report
http://www.esi.es/ESSI/Reports/All/24198/Report/24198.pdf
$SSHQGL[/LVWRIXVHGDFURQ\PV
CAE Computer Aided Engineering
CASE Computer Aided Software Engineering
ER Entity-Relationship
ESI European Software Initiative
ESSI European Systems and Software Initiative MIS Management Information Systems
OMT Object Modeling Technique
OO Object-Orientation
OOA Object-Oriented Analysis
OOD Object-Oriented Design
OT Object-oriented Technology
PIE Process Improvement Experiment UML Unified Modeling Language
$SSHQGL[&DVHFRPSDQLHVFRQWDFWLQIRUPDWLRQ
/06,QWHUQDWLRQDO Tonny Vanmunster Interleuvenlaan 68 B-3001 Leuven Belgium
Tel. +32 16 384 200 Fax. +32 16 348 350
0D[:DUH$6 Vivi Horn Marstrand Pirsenteret 7005 Trondheim Norway
Tel: +47 73 54 57 00 Fax: +47 73 54 57 50 777LHWR2\
Juha Pakkanen Ylistönmäentie 33 PO Box 203 FIN-40101 Jyväskylä Finland
Tel. +358 14 637 118 Fax. +358 14 637 440
*DERU6KRHV$*
Werner Vieth
Marienberger Straße 31 83024 Rosenheim Germany
Tel: +49 8031 801 298 Fax: +49 8031 801 275 .QDSS/RJLVWLFV$XWRPDWLRQ
Gerhard Fellrieser Günter-Knapp-Straße 5 - 7 A-8075 Hart bei Gratz Austria
Tel: +43-316-495623 Fax: +43-316-491394
