EuroSPI 2000

Practical and innovation based software process improvement to prepare for the new millenium.

European Software Process Improvement SPI and Requirements

Category Index

Rated Newspaper Supported by EU Project

Dynamic CMM for Small Organisations - Implementation Aspects

Terttu Orci
Umeå University/Stockholm University

Astrid Laryd
Umeå University

Introduction

Software process improvement (SPI) is a current topic in software engineering community. Most organisations, in order to maintain their competitive edge, plan or are in progress to apply SPI with the desired results of predictability in the software development considering time, cost, and quality. SPI effort can take many forms, e.g. it can be based on a road map like Software CMM [13], SPICE, Bootstrap, ISO9000, or it can focus on improving specific working practices in an organisation. There are models for implementation, e.g. IDEAL [12], guidelines for and experiences of implementation [3],[15], and other related information, e.g. [2],[5],[6],[14].

It is commonly agreed that a software development organisation with notably symptoms of chaos caused by immaturity should start a software process improvement program. However, when a chaos is already a fact, it is difficult to find time and personnel resources for an improvement program. It would be wiser to start an improvement program before the chaos is a reality. In fact, the wisest thing to do would be to start an improvement program when starting the operation of the organisation. Obviously, we would in that case not think about an improvement, but see it as a sound business and engineering strategy.

The next best thing is to start an improvement program while an organisation is a very small one, with a few software engineers, and with a simple management. In the start-up phase, with a few software engineers, with one or a few versions of one product or only one project running at a time, the communication is simple, configuration management is relatively easy, everybody knows what the colleague engineer is doing, neither the development work nor the management offers bigger problems.

The existing models, e.g. CMM, are not, however, directly applicable for small organisations for various reasons. CMM, for example, proposes more than 25 organisational roles, with various tasks and responsibilities. In a small organisation, there is not enough people to fill the roles proposed, neither is there any need of many of those roles. Further, the models are usually described on a huge number of text pages, being cumbersome and time consuming to get oversight, digest, and apply. Therefore, the models need to be scaled down to the needs and possibilities of small organisations. A usual restriction in a small organisation is that there is not enough resources for appointing external competence for a long term SPI, but local competence is the only realistic possibility. Therefore, the models should include guidelines for internal assessment and application of the model. Further, it is essential that such a model is applicable continuously in the course of time, while the organisation grows, otherwise it will cease to be useful after a while.

We have developed a model called Dynamic CMM for Small Organisations. The model has been briefly presented in 114] and in detail in [10]. In this paper, the model is briefly presented together with some implementation guidelines.

The model is primarily intended to be used by an organisation's internal staff, with some experience of SPI and by the management. The basic idea is that the model users can easily get an overview of the model, of the magnitude of the effort required and of the roles, responsibilities, tasks, and documents. With those intentions in mind, the original CMM has been interpreted, reduced, reorganised, and partially represented in a graphical notation.

The Dynamic CMM for Small Organisations

A small organisation, according to the classification of EC, has 1-50 employees. That range represents a wide variety of organisations. The employees adding to the count are assumed to be either development staff, management or marketing and sales, excluding administrative services and human resources staff. We believe that special conditions apply to an organisation with one or two employees, because it is easy to be continuously informed of what the colleague engineer is doing. Such organisations are here called eXtra eXtra Small organisations (XXS). As soon as the organisation grows to include three persons, the loss of oversight and easy communication is at risk. Yet, an organisation with three employees is very much smaller and easier to manage than an organisation with nearly 50 employees with several products, several versions of each product or customers at a time. It seems adequate to further classify the organisations to eXtra Small (XS) with 3-15 employees and Small (S) with 16-50 employees. The models are intended to be applicable for organisations developing software products to open market, as well as for organisations developing customer specific solutions. In case there is a difference in roles or otherwise between these organisations, it is indicated in the text.

The Role Models

We have studied the roles in CMM, their interdependencies, responsibilities and activities. There is only one role, Software Quality Assurance group (SQA), that should not involve any person from the management, neither should it include persons involved in the software development. The reasons are obvious: quality assurance without impartiality does not fulfil its purpose.

The roles may be one of three types. First, a role may be important enough to be included as a role, assigned to a person with associated responsibilities, e.g. Senior Management (SM) as every organisation must have such a role irregarded the size. Second, a role may be important in terms of activities and responsibilities, but without need for a formal role. In such a case, the activities and responsibilities can be carried out by a person having some other role, with the consequence that the responsibilities and activities of that person will be more extensive than implied by his formal role. An example of such a role is Documentation Support Group (DSG) which is unrealistic in a one person company, but still there is some documentation to do, assumed to be taken over by software engineers (SE). Third, some roles are irrelevant, e.g. an organisation not applying subcontracting does not need Software Subcontract Management (SSM).

XXS Organisations

An XXS organisation is assumed to have one or two employees and one version of the first product is under way. Alternatively, the first customer project has been initiated. This is the starting scenario for many software development organisations. If there is only one employee, the person is both the manager in the role Senior Manager (SM) and a Software Engineer (SE). If there are two employees, the one is both SM and SE, the other only SE. Still, two persons have a good chance to get insight into each others work, and we see no reason to have formally assigned project management. By that, we do not claim that project management is abandoned, project planning and tracking are important activities. The implication is only that project management activities can be carried out informally by SM. SoftWare Manager (SWM) is responsible for the software development environment, but also for the operative software and hardware in the organisation. In companies developing customer specific solutions, SWM becomes the expert on computers and adjustments at the customer site. Still, a person possessing one of those roles may very well work also in another role.

We make the assumption that subcontracting is not realistic in a two-person organisation, implying that the Key Process Area (KPA) Software Subcontracting Management KPA is irrelevant. System Test Group (STG) is supposed to be responsible for system tests, while SE has the responsibility of tests during the development. Validation and verification is of primary importance to obtain a quality product. Still, an internal STG role is hardly realistic in a two person company. For organisations with customer specific development, the customer is the most adequate group for acceptance tests. In product development organisations in the beginning of the business, an external test service can be used.

SQA should not be shared with persons involved in development activities or in the management. In a two person organisation, it is not realistic to appoint an internal SQA. In an organisation with specific customers, Customer SQA (CSQA) can be used to conduct SQA activities, if SQA is available at the customer site. In product development organisations, an external SQA service can be bought.

System Engineering Group (SG) is responsible for the systems with both software and hardware. The roles in an XXS organisation are presented in Figure 1.

Fig. ORCI-LAR.1 The Roles in an XXS Organisation

In the model, a circle denotes a role. A dotted line around a circle means that the role is relevant only in organisation developing customer specific solutions. The links between the roles have the semantics of "shared-by", which is a binary relation, more exactly an equivalence relation. Therefore, transitivity applies. For example, the activities and responsibilities of SE may be shared by SG. From Figure 1 it is obvious that model is applicable in an organisation with only one person, who possesses the roles SM/PM, SE, SG, SCM, and SWM, and buys external services for STG and SQA, or uses CSQA, if applicable.

XS Organisations

An XS organisation has 3-15 employees, and a few products/product versions or projects. If the organisation is developing products for open market, the time of entering XS model is probably the time of the first release, i.e. the time when the hard work with successive releases and change management begins. Moreover, the life after the first product is of strategic importance. In order to keep the first product successful and on the market, the organisation needs to grow. Most probably, new products are on the way, also implying need to recruit more staff. Going from XXS to XS, new roles are needed. Correct project management requires Project Manager (PM) role. Most probably, marketing and sales (MS) is a role with increasing importance at the time an organisation grows out from XXS. System testing (STG) should become an internal role as the number of products/product versions and projects grows.

Figure 2 presents the model for XS organisations. The shading of a circle indicates that the role is an additional one compared to the XXS organisation. For example, when growing out of XXS, PM and MS are roles to be added. The frames depict projects. The roles within a frame denote roles, which may be specific for each project, while the roles outside the frame are roles having responsibility in the whole organisation. For example, there is SCM role in each project. SWM is general for the organisation, but the person in SWM role may belong to SCM in one or several projects. SM and MS are general for the organisation, possibly one and the same person. SM can also work as SE.

Fig. ORCI-LAR2. The Roles in an XS Organisation.

S Organisations

In an S organisation, the number of employees is 16-50, and there are several products/versions or projects running in parallel. In particular for organisations with product development, documentation support is of great importance implying introduction of Documentation Support Group (DSG). Also, software subcontracting is relevant. This implies the introduction of the Key Process Area (KPA) Software Subcontract Management with the role Software Subcontract Manager (SSM). In some organisations, SM may not be involved in MS activities, but in some organisations, sharing SM and MS by one persons is considered important. Therefore, we leave this possibility open by retaining the link between MS and SM. The links imply possibility, not a mandatory sharing of responsibilities. MS is related to DSG, and the same person can share DSG and MS roles. Further, until subcontracting is widely practised, the person in role SM may also have the role SSM. Quality assurance in this size of the organisation motivates an independent internal SQA, which is also important for obtaining continuity in the software process improvement activities. SCM is a more requiring task in an organisation with several projects/products/product versions, and therefore it is assumed that the person in SCM role does not also work as SE. The model for an S organisation is presented in Figure 3.

Fig. ORCI-LAR3. The Roles in an S Organisation

Responsibilities and Activities

For each role, there are responsibilities and activities. Here, only the responsibilities and activities for one role, SWM, are described as an example of the representation, in Table 1.

Table 1. The Responsibilities and Activities of SWM

Type	Object of concern
Is responsible for Reviews	- the development environment HW and SW -statement of work -project plan -resource estimates -quality assurance plan -configuration management plan -the progress against the project plan -specification for subcontract -subcontract

Documents

CMM requires a large number of documents, required as the basis for activities or as input or output to/from activities. The phrase "according to a documented procedure" appears frequently in CMM text. The documents can be classified as follows:

policy documents - one for each KPA
documented procedures, e.g. requirements management, project planning, estimation
plans, e.g. configuration management plan, project plan, quality assurance plan
status reports, e.g. quality assurance report

In CMM, the documents are described in text, but it is hard to get oversight of the number and the types of documents. In our model, documents are classified by type along the above document types. The documents are not described here for space reasons, but can be found in [10].

Activity Diagrams

One of the intentions with the model is to get an easy overview. Graphics support both overview and structure and therefore, the activities are represented graphically, in a simplified form. A graphical overview of only the KPA Software project Planning is given in Figure 4. The activities take allocated requirements as input, and the output consists of statement of work, estimates, project administrative data, and project plan. The activities are reviewed periodically with SM, and periodically as well as event-driven with PM. SQA reviews the activities and work products of the KPA, indicated by SQA outside the KPA frame. SM is responsible for a written organisational policy, and a set of documented procedures in project planning. The PM is responsible for measurement data concerning the status of project planning activities. An overview of the SPP KPA is given in Figure 4 and the activities in Figure 5.

Fig. ORCI-LAR4. Software Project Planning - overview

Fig. ORCI-LAR5. Software Project Planning - the Activities

Implementation of Dynamic CMM

In this section, guidelines for implementation of Dynamic CMM in small organisations will be presented. We do not argue that the guidelines are the best, or even appropriate for all situations. To do that, the guidelines must be used in a number of real situations, followed by systematic analyses of the results, and of the opinions of the practitioners. The guidelines presented here have been developed by common sense, experience of ours and others, and should so far be regarded only as a proposal.

A software process improvement effort should be driven in a project form, with project plan, resource estimates, budget, and schedule. It is also important that the project management of the improvement process is conducted in the way proposed in Software Process Planning KPA at Level 2 for development projects, to serve as a good picture of what is expected from management issues in the development projects. In order to maintain the focus and to prevent misunderstandings in the following discussion about projects, processes, and roles, a distinction must be made between software project improvement and development. For both improvement and development, we can distinguish projects and processes. The terms I-Project, D-Project, I-Process, and I-Project are used to make a distinction. A long term improvement effort is called an I-Process. An I-Process involves some particular steps to be taken initially, and a number of iterations of smaller improvement efforts, realised in project form, in I-Projects. Each of the I-Projects includes planning, doing and analysing the results. The doing coincides with design and use of a D-Process, e.g. one particular KPA like Requirement Management. The use of the newly designed D-Process is in a pilot D-Project. Also for the roles needed in the improvwment work, the distinction is useful. The roles prescribed by CMM are roles in software development organisation, in the development work, and are called D-Roles. The roles needed for SPI work are called I-roles, e.g. SEPG. The distinction between improvement and development is illustrated in Figure 6.

Fig. ORCI-LAR6. An I-Process including an I-Project

The activities of an I-Process are described in detail below.

Selecting - Appointing - Training

Selecting

The basic parameters for selecting an appropriate model are the number of employees and the number of products/product versions or projects. The number of employees includes development, management, and marketing and sales staff, but excludes administrative and human resources staff. The number of products and product versions is applicable for product development organisations, while the number of projects is applicable for organisations developing solutions to specific customers. Table 2 gives the basics for the decision of an appropriate entry point to the model.

Table 2. The entry points to Dynamic CMM

	1-2 empl	3-15 empl	>15 empl
1 product/version or project	XXS	XS	S
2-5 products/versions or projects	-	XS	S
>6 products/versions or projects	-	S	S

The alternatives marked with "-" are unusual if not unrealistic. For example, an organisation with 2-5 products/product versions, with 1-2 employees might have a theoretical chance to stay on the market with a large number of subcontractors, but it is more a rule than an exception that the company growth implies growth in the number of employees. If the organisation characteristics are outside the limits of the table, it is assumed that the original CMM can be used.

Appointing

The I-Roles for SPI-work are steering group, SEPG, working groups, process users. The steering group decides which D-Processes are to be improved during the closest time period, selects working groups, and appoints SEPG. In a small organisation, the steering group may very well consist of the senior manager only. The SEPG (Software Engineering Process Group) is not required until Level 3 in CMM. However, there should be a change agent or an opinion leader, or group of those, with an interest in SPI and knowledge of both SPI and software development. That role is here called SEPG. The tasks of SEPG are to collaborate with the working groups in SPI work, to co-ordinate the details in realisation of the vision, to train the working groups and process users, to support and motivate the use of the process. The working groups use their knowledge and experience to do the main work in defining and evaluating the new processes, and train the process users. In a small organisation, there might not be any people being only process users, but everybody in the development teams might be involved in working groups. There might be one or several working groups, depending on the situation at hand.

Training

The training should concern the underlying ideas and motivations for SPI work in general, and the Dynamic CMM in particular, including the roles, responsibilities, tasks, and documents. The role models, the list of responsibilities and activities, and documents, are intended to serve the purpose. The activity diagrams, both the overviews and the detailed ones, give a picture of the KPAs, corresponding to D-Processes.

Prioritising

PRIO stand for prioritising, implying selection of one or more KPAs for the improvement work. The order of KPAs is not fixed by the original intentions of CMM. However, assuming that there are no defined and documented processes, but chaos and reactive way of work, it would not make much good to introduce SQA as the first priority. At least one other KPAs should be in place before SQA is meaningful. Project management is important as it has consequences for the delivery time and budget. However, if the entry point is XXS, PM is informally handled. The order of the formally handled KPAs, Requirement Management (RM) and Software Configuration Management (SCM), is not generally determined. Which one is introduced first is a question of the situation at hand. For example, if configuration management is experienced as a big problem, it would be natural to start to bring some order in that. At the other hand, if the requirements are volatile, and problems are encountered by introduction of new requirements, RM should probably get first priority.

The selection of the high priority KPA is not independent of the model selected. If the model is XS or S, SPP and SPTO are maybe the most adequate KPAs to start with. For the order of RM and SCM, the same reasons should apply as in XXS organisation.

The prioritising activity is the first task in Plan activity in an I-Project. Further planning in an I-Project requires, among other things, that appropriate resources are given by the steering group, that people are appointed to the organisational roles for the KPA in case, and that a project plan for the I-Project is developed and documented.

Workshop

Workshop is a suitable form for defining D-processes. The reasons and motivations for this technique have been presented in [3]. The final result of a series of workshops is a defined and documented D-process, e.g. a process for Software Project Planning. The form and content of respective D-process should conform to the activity diagrams for KPAs. In order to check whether the defined D-Process satisfies the model requirements, we have developed checklists for each KPA as well as for each activity within a KPA. The checklists include entry conditions, roles, activities, and exit conditions. The checklist for the Software Project Planning KPA (D-Process) is presented in Tables 3-5. The checklists for SPP activities are omitted for space reasons, but can be found in [13]. A defined and documented D-process must be approved by the working group and SEPG. If an approved status cannot be directly reached, a new workshop should be arranged to solve the problems and modify the D-Process.

Entry conditions
	A PM is designated to be responsible for the project plan	q
	Written policy	q
	Adequate resources and fundings are provided for the planning the software project	q
	PM, SWM, SE, and other individuals are trained in software planning and estimates	q
	Tools to support the activities are made available	q
	Documented procedures for developing the project’s plan	q
	Allocated requirements	q
	Cost data (optional)	q
	Historical data (optional)	q
	Project proposal	q
	Project and customer standards	q
	Statement of work	q
Roles
	Senior Manager (SM)	q
	Project Manager (PM)	q
	SoftWare Manager (SWM)	q
	Software Engineering group (SE)	q
	SQA group	q

Table 3. Software Process Planning Checklist - Entry Conditions and Roles

Activities
1	SE participates on the project proposal team	q
2	SE reviews the proposed commitments	q
3	SE reviews the overall project plan	q
4	Commitments made to individuals and groups external to the organization are reviewed with SM	q
5	A software life cycle with predefined stages of manageable size are identified or defined	q
6	The project’s plan is developed	q
7	PM, SWM, and other affected groups review the project’s plan	q
8	The project’s plan is documented	q
9	Software work products that are needed to establish and maintain control of the software project are identified.	q
10	Estimates for the size of the software work products (or changes to the size of software work products) are derived	q
11	Estimates for the software project’s effort and costs are derived	q
12	Estimates for the project’s critical computer resources are derived.	q
13	The project’s software schedule is derived	q
14	The software risks associated with the cost, resource, schedule, and technical aspects of the project are identified, assessed, and documented	q
15	Plans for the project’s software engineering facilities and support tools are prepared.	q
16	Software planning data are recorded	q
17	Measurement data are made and used to determine the status of the software planning activities	q
18	The activities are reviewed with SM on a periodic basis	q
19	The activities are reviewed with PM on both a periodic and event-driven basis	q
20	SQA reviews and audits the activities and work products and reports the result	q

Table 4. The Checklist for Software Project Planning - the Activities

Exit conditions
	Action items resulting from reviews with PM and SM are documented and reviewed	q
	Assumptions made in deriving the estimates for the project’s effort and costs are documented and reviewed	q
	Assumptions made in deriving the estimates for the project’s schedule	q
	Distribution of effort, staffing and cost estimates are prepared	q
	Estimates for critical computer resources size (or changes in size) of software work products project’s effort and costs capacity requirements for software engineering facilities and support tools	q q q q
	Mesurements	q
	Plans for involvement of SE in activities of other groups	q
	Plans for other groups involved in SE activities	q
	Plans for software engineering facilities and support tools	q
	Project’s software schedule	q
	Software life cycle	q
	Software project commitments	q
	Software risks	q
	Work products	q
	Summary report from each review with SM, PM	q
	Time phasing activities	q

Table 5. The Checklist for Software Project Planning - the Exit Conditions

Pilot D-Project

Pilot D-Project is simply an application of the defined and documented D-Process in a real development situation, in a D-Project. The pilot intends to result in opinions of what worked well and what did not work well.

Analyse

The opinions of the process users are analysed after the pilot D-Project. If the D-Process cannot reach the approved status, a workshop should be arranged to solve the problems and to modify the D-Process accordingly. The intention is that the D-Process is used in every D-Project after its definition. Until the D-Process has reached the approved status, it should also be analysed and modified after each application.

Concluding Remarks

In this paper, we have briefly presented the model called Dynamic CMM for Small Organisations. The approach is not unique, there is some related work on the issue.

The work presented in [1] describes the issues encountered by small businesses, organisations, and projects, if applying the existing models for SPI, e.g. CMM: documentation overload, layered management, scope of reviews overkill, limited resources, high training costs, and unrelated practices. A set of tailoring guidelines for each of the issues is presented in [1], and a tailored CMM, based on the original CMM with marked additions and deletions. The same authors present more detailed tailoring guidelines in [7] for different issues, e.g. documentation tailoring, review tailoring. It is important to emphasise the scalability issues of Software CMM for small organisations. We believe, however, that not only should the model be downscaled, but also the representation should be restructured, e.g. graphics, lists, for simplicity and easy overview. In [9], SPI work in small organisations has been presented, and critical success factors given, they being a flexible, tailored assessment and improvement approach, a functioning network of small enterprises and their environment, external technical help by mentors for change, and external financial support coupled to some conditions for performance. Our model is intended to support the first factor. Although external technical help may be needed to take the first steps in the SPI work, we believe that only organisations with an internal strong competence in SPI have the chance to conduct long-term SPI work. External services should only be needed for assessments to obtain impartiality.

The current research concerns validation of the model in real cases, one being in progress and two more under negotiations. The real cases involve not only application of the model in SPI work in the organisations in case, but empirical evaluation of the model and of the underlying ideas.

References

[1] Brodman J.G., Johnson D.L. The LOGOS Tailored CMM for Small Businesses, Small Organizations, and Small Projects. LOGOS International, Inc.1995.

[2] Byrnes P, Phillips M. Software Capability Evaluation, Version 3.0, Method Description, Technical Report CMU/SEI-96-TR-002, ESC-TR-96-002, 1996.

[3] Caputo K. Implementation Guide - Choreographing Software Process Improvement. Addison Wesley, 1998.

[4] Curtis, B.,Hefley, W.E., Miller, S. People Capability Maturity Model. Software Engineering Institute, Carnegie Mellon University, 1995.

[5] Dunaway D.K. et al. Why Do Organizations Have Assessments? Do They Pay Off?, Technical Report, CMU/SEI-99-TR-012, ESC-TR-99-012, 1999.

[6] Hayes W., Zubrow D. Moving On Up: Data and Experience Doing CMM-Based Process Improvement, Technical Report CMU/SEI-95-TR-008, ESC-TR-95-008, 1995.

[7] Johnson D.L., Brodman J.G. Tailoring the CMM for Small Businesses, Small Organizations, and Small Projects. LOGOS International Inc, USA.

[8] Kautz K. Software Process Improvement In Very Small Enterprises: Does It Pay Off?, Software Process - Improvement and Practive 4, 209-226, 1998.

[9] Kautz K. Even in Very Small Software Enterprises Metrics Can Make Sense!, in the Proceedings of IRIS 21, 1998.

[10] Orci, T., Laryd, A. CMM for Small Organizations, Level 2. Umeå University, UMINF-00.20, 2000.

[11] Laryd, A., Orci, T.: Dynamic CMM for Small Organizations. In Proceedings of ASSE2000, Argentina, 2000.

[12] McFeeley B. IDEAL - A User's Guide for Software process Improvement. Handbook, CMU/SEI-96-HB-001, 1996.

[13] Paulk, M.C. et al. The Capability Maturity Model - Guidelines for Improving the Software Process, Addison-Wesley, 1995.

[14] Stelzer D, Mellis W. Success Factors of Organizational Change in Software Process Improvement, Software Process - Improvement and Practice 4, 227-250, 1998.

[15] Zahran, S. Software Process Improvement. Practical Guidelines for Business Success. Addison-Wesley, 1997.

CV Terttu Orci

Terttu Orci received her PhD at the Royal Institute of Technology (KTH), Stockholm, and Associate Processor at Stockholm University. She works at lecturer, researcher, and supervisor at the department of Computer and Systems Sciences, Stockholm University/KTH. She is in charge of the competency track in Software engineering in the education programmes at both universities, with special focus on software process improvement and software metrics. Although the current research interest is in software engineering, the prior research interests include databases, temporal aspects of database modeling, and automated theorem proving and AI. She is often appointed by the EC as external expert in evaluations of project proposals and in projects. She also works as consultant in industry in various cooperation project between academia and industry. Currently she focuses on initiating SweSMA, Swedish Software Metrics Association, to be included in FESMA.

CV Astrid Laryd

Astrid Laryd received her M.A. at the University of Lund, Sweden. She has worked in the Swedish industry both as an employee and as a consultant. Examples of work are design and implementation of assemblers for minicomputers, construction and implementation of mathematical library functions for compilers, systems analysis and programming for processing documents using optical character recognition technique, design and implementation of device handlers for graphic equipment and for data panels and menus. The last ten years her work has been focused on safety in software intensive system (risk and safety assessments in nuclear power plants) and on software process improvement. She has also had a commission as a reviewer in a EU project (ESPRIT 22187); "Safety and Risk Evaluation using Bayesian Nets", addressing the safety justification process for software-intensive system. Currently she is engaged at Umeå University in a research project: "Quality Management for Small Enterprises (QMSE).

Partners in EuroSPI

Editors

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