computer communications

ELSEVIER Computer Communications 21 (1998) 21 I-219

Rapid prototyping of new telecommunications services: a procedural approach

Dionisis X. Adamopoulos”‘*, George Haramisb, Constantine A. Papandreouc

“Centre for Satellite Engineering Research, Department of Electronic and Electrical Engineering, University of Surrey, Guildford. Surrey, UK bAssociate Professor of Information Systems, University of Macedonia, Thessaloniki, Greece

‘Training and Research Centre, Hellenic Telecommunications Organisation (OTE). Athens, Greece

Received 3 April 1997; revised 24 July 1997

Abstract

This paper examines the influence of rapid prototyping on the development life cycle of new telecommunications services (telematic

services). After a brief introduction in the field of Teleinformatics (Telematics), the concept of prototyping is analysed. The main issues related to the design and management of telematic services are identified and the application of the rapid prototyping process to the area of telematic services is proposed. A relative methodology is then described following a procedural approach. The characteristics and main elements of this methodology are discussed in considerable detail. Finally, a number of important evaluation criteria are highlighted, an

application of the proposed methodology is outlined, and some conclusions are given. 0 1998 Elsevier Science B.V.

Keywords: New telecommunications services; Telematic services; Rapid prototyping; Service engineering; Service design

1. Introduction

The introduction of digital technology in telecommunica- tions provides the opportunity to integrate and collaborate

with computer systems, which are modernization factors

and necessary instruments for the survival and development of businesses and organisations. Telecommunications and

computer science are no longer examined as two separate

and distinct fields, as their convergence produces new telecommunications products and services. For new

telecommunications services the name telematic services

is alternatively used by many authors. Considering that benefits of the new telecommunications

technology come mainly from the deployment and exploita- tion of telematic services, which utilise the infrastructure

provided by modem telecommunications networks, the

need to speed the development life cycle of the new telecommunications services, without making quality com-

promises, is evident. In this paper, the rapid prototyping process is presented as a possible effective and efficient

solution to this problem.

2. The concept of rapid prototyping

A prototype is an approximation of a system that exhibits

* Corresponding author.

0140-3664/98/$19.00 0 1998 Elsevier Science B.V. All rights reserved

PII SO140-3664(97)00178-3

the essential features of the final version of that system.

Prototyping is used in many areas, including engineering and information systems development. In the latter

area, prototyping (which is also known as rapid

prototyping when suitable tools are used to support

the rapid creation of design elements) addresses some of the problems of traditional systems analysis, in particular,

the complaint that users only saw their information system at implementation time when it was too late to make

changes. In that case, the risk of failure because of

user dissatisfaction, including outright user rejection, is significant [ 11.

On the other hand, by implementing a prototype first,

the analyst can show the users something tangible, inputs,

intermediary stages, and outputs, before finally committing the user to the new design. These prototypes are not

diagrammatic approximations, which tend to be looked at as abstract things, but actual output on paper or on work- station screens. The formats can be changed quickly, as the

users suggest changes, until the users are given a reasonable approximation of their requirements. Further, it may only be

by using this approach that the users discover exactly what they want from the system, as well as what is feasible. It is also possible to try out a run using real data, perhaps generated by the users themselves [2].

Rapid prototyping can therefore be seen as a much improved form of systems’ investigation and analysis, as

212 D.X. Adamopoulos et al./Computer Communications 21 (1998) 211-219

well as an aid to design, and can be used as a basis for a methodology of information systems development. This methodology may have [3,4]:

l an analysis phase, designed to understand the present

system and suggest the functional requirements of a new system;

l a prototyping phase to construct a prototype for evaluation by users;

l a set of evaluation and prototype modification stages;

l a phase to design and develop the target system using the

prototype as part of the specification.

A prototype is built using special software tools such as

computer aided software engineering (CASE) tools, fourth

generation systems, application generators, screen painters, graphical user interface (GUI) creators, and report

generators. These software tools reduce the costs associated

with prototyping and increase the ease and speed with which

prototypes can be created and modified.

Many prototypes are created with the intention of being discarded after evaluation and requirements capture

(‘throw-away’ prototypes) [4]. An alternative approach is

to use the prototype as the basis for the operational system

(exploratory prototyping). In this scenario, the information system ‘evolves’ by an iterative process. Once the users are

satisfied with the prototype, it ‘becomes’ the operational system [5]. The availability of powerful design environ-

ments has given rise to evolutionary prototyping, in which a series of prototypes is produced that converges as an

acceptable version of system behaviour. There is never a

‘final version’ of the prototype and there is always the possibility of iterative revision even when the system is

operational. The prototype is changed to reflect new

conditions [ 1,6].

3. Design and management of new telecommunications services

According to the International Consultative Committee

for Telephone and Telegraph (CCITT), telematic services are defined as: “All the services which are different from

the conventional telephony and telegraphy related services, and which can be provided to the subscribers of a tele- communications network. These services facilitate the

transmission and receipt of information public or private, which include file transfers, commercial, or banking transactions, etc.“. Examples of telematic services (new

telecommunications services) are: videoconference,

electronic mail, videotex, facsimile, mobile telephony, etc. For the categorisation of telematic services several

criteria can be used. The most important of them are [7]:

l the required network infrastructure (telephone network, ISDN, intelligent networks, etc.);

l the required bandwidth (narrowband, broadband);

l the status of the users (enterprises, households); l the form of the transmitted signal (analogue, digital); l the transmission medium used (copper, fibre, wireless,

etc.);

l the network topology used and the information flow inside the network (point-to-point, multipoint);

l the possibility for the subscriber to move (mobile,

fixed); l the form of the transmitted information (voice, text,

picture, video, data, multimedia);

l the output provided (hardcopy, softcopy).

The many possible categorisations of telematic services reveal the increased complexity of tasks which are associated with the design of a telematic service, as it

illustrates the difficulties when identifying an existing

telematic service and in describing its functional charac-

teristics in detail. The design task becomes even more

complex when taking into account that the diversification of the user’s needs result in many variations of the already

existing telematic services or even in completely new and

innovative telematic services. Once a telematic service is designed it has to be imple-

mented and offered to its users. Then the task of managing

the telematic service gains the outmost importance. This is another complex task, not only because the service consti- tutes a large-scale system (vulnerable to error conditions

and external actions), but also because the user’s needs change with time and the relevant technology is under con-

tinuous improvement [8]. In general, the design and man-

agement of telematic services involves all the actions which are necessary for the provision of a new telematic service

and the administration and constant evaluation of this

service after its deployment. In that way the service retains its usability and reliability through time, evolving in a

steady and successful way. Because of the complexity of the design and management

of telematic services a methodology for this purpose is

considered to be necessary. Such a methodology can result in a standardised process with appropriate quality charac-

teristics. In this case, a common approach can be used

throughout an organisation, ensuring that more integrated systems can result, staff can easily change from project to

project without retraining being necessary, the re-use of service software is greatly facilitated, and a base of common

experience and knowledge can be achieved.

Every methodology has a ‘philosophy’ which makes it appropriate in given circumstances. A pure engineering (‘hard’ systems) approach is not suitable for the design and management of telematic services, because it tends to ignore or underestimate the importance of the user’s needs, when the acceptance of the user greatly determines the practical value of the whole service (‘soft’ system). On the other hand, information systems’ methodologies tend to be rather abstract and differ greatly, because they usually address different objectives [2]. Thus, different information

D.X. Adamopoulos et al./Compurer Communications 21 (1998) 21 l-219 213

systems’ methodologies can address different parts of the

problem associated with the design and management of

telematic services. No single information systems’

methodology can address this problem as a whole, without significant alteration of its structure.

For this reason, a specialised methodology is necessary.

The main objective of the proposed methodology is to

represent an efficient and effective way to design and manage new telecommunications services systematically,

at lower cost, higher quality, increased speed, meeting the

needs of the users and the organisation better, and leading to lower maintenance costs.

The proposed methodology is based on the concept of rapid prototyping, because [9]:

telematic services are not very well defined;

most organisations are not familiar with the technology

(hardware, software, communications) required for a telematic service;

user involvement is critical to the success of a telematic service;

the communication between service designers and users

is not very good, in terms of understanding and

time required, because users usually span an entire organisation or even wider sectors of the public; the cost of rejection by users can be very high;

there is usually a requirement to assess the impact of a prospective telematic service.

4. The proposed methodology

The proposed methodology is considered to be a collection of procedures, which include techniques and

tools able to assist the service developers in their efforts

to design and manage a telematic service. The methodology consists of seven phases which guide the service developers in their choice of the techniques that might be appropriate at

each stage of the project and also help them design, control, manage and evaluate telematic services.

These phases, which can be seen in Fig. 1, are:

Service Description: the service concept is developed in a structured and comprehensible way.

Requirements Analysis: the requirements for the telematic service under consideration are accurately recorded. Service Specification: the decomposition of functionality

necessary for the service is produced.

Service Prototyping: a prototype of the service based on selected parts of the service specification is produced.

Prototype Verijcation: the performance and the quality characteristics of the service prototype are validated. Service Development and Verification: the service prototype is extended into the actual service, the service is placed into the target environment through software and database changes, and the performance and the quality characteristics of the service are validated.

7 Service Description

Requirements Analysis !_ _~_~~ -._ _~

-_z-_.__._.

kl Service Specification -I

T

iY Service Prototyping 4 I

’ r__ ~~~ L ~_~___

Prototype Verification I

. ~_.___ _-._ Service Development and Verification

~~ ~.___._

r-~~~ -Y

Service Management

Fig. 1. The proposed methodology for the design and management of

telematic services.

l Service Management: the telematic service is

administered and its successful evolution is catered for.

4.1. Service description

This is the initial phase of the methodology where a

service idea is refined from the initial service concept into a careful service definition and a comprehensible service description.

The definition of the service should be concise and clear

and should be accompanied by an attempt to categorise the service according to already existing service taxonomies

[lo], as this will assist better understanding of the service

concept. The description of the service is presented in a structured way and includes all the important characteristics of the service, such as basic service features, available

service extensions, alternative design options, and existing standards. These service characteristics take (if applicable) the form of a service profile, which has a layered structure and comprises the following layers (bottom-up)

[I 11:

l Infrastructure Layer: the necessary infrastructure

(network and end-computing) characteristics for the

provision of the service. l Distributed Processing Layer: service characteristics

related to the division of the required processing work into separate tasks able to be executed at a number of computing machines over a network in a distributed manner.

l Groupware Layer: service characteristics describing the interactions between the service features.

214 D.X. Adamopoulos et al./Computer Communications 21 (1998) 211-219

l User Interface L.uyer: service characteristics facilitating the user to interact with the service.

4.2. Requirements analysis

Requirements analysis sets the scene for the later phases,

because it enables a full understanding of the telematic

service under consideration and establishes the direction of the rest of the project. It comprises three tasks which

are interrelated, namely the investigation and analysis of

the user requirements, the examination of possible

implementation constraints, and the study of the present

system (if a similar service is under operation in the

organisation). As the user of the service can be considered either the

end-user who is in direct conduct with the service, or the

(management of the) organisation in the premises of which the service is provided. The requirements of the end-user are

mainly related to the user interface of the service, the

service performance, and the information that it delivers. It must be noted that a special category of end-user is the

service administrator who will have special needs, related to

security mechanisms, access control, management

functions, etc. On the other hand, the organisation expects the achieve-

ment of some goals through the use of the telematic service. These goals might be related to profitability, long-term

survival, expansion, greater market share, and employee and customer satisfaction. These expectations are the

organisational requirements, which have to be ‘translated’ to end-user requirements in order to be considered in the

following phases of the proposed methodology. This ‘translation’ is performed by the service designer taking

into account the operational environment of the service. The next task of the requirements analysis phase focuses

on the identification and interpretation of the implementa- tion constraints, which are imposed on the service by its

environment inside the organisation. The importance of these constraints is significant because they greatly affect

the feasibility of the user’s requirements. Implementation constraints can be categorised as technical and non- technical, and include, among others, a given network

infrastructure, a given hardware platform (e.g. terminal

equipment), software restrictions (e.g. use of a specific operating system), interfacing with other, already existing, telematic services, a given development time scale, specific

cost maxima and/or minima, expected performance, strict security policy, etc.

The final task of the requirements analysis phase is optional as it takes place only if a similar service already exists. The new service, which will be the outcome of the application of the current methodology, will either completely replace the old service, or be combined with it. Thus, some requirements of the new service can be defined by considering weaknesses of the present service. For this reason requirements of the new service are

examined along with detailed investigation of the processing methods and data of the current service and the problems associated with it.

Finally, when all the tasks of the requirements analysis

phase are completed, their results are examined together in

order to produce a set of service requirements, which

determine accurately the functionality of the service.

These service requirements must be documented and characterised by completeness of definition, because they

are considered as the objectives of the service. They also

have an important impact on the service profile produced in

the previous phase of the methodology as they limit the

alternative design options and refine its content (proposed

service profile). In this phase of the proposed methodology a variety of

tools and techniques can be used for the requirement’s elicitation and representation, in combination with the

service definition and description which took place in the

previous phase. Among others, data flow models can be produced with the use of data flow diagrams, matrices might be constructed which, for example, show the relation-

ship between processes and entities (that is, which processes

access the information in various entities), and catalogues can be created, such as the user catalogue, which lists the

activities carried out in each job, and the requirements

catalogue, which lists the functional and non-functional requirements.

4.3. Service specijcation

The service specification phase reveals the functionality of the service based on the requirements and proposed profile. It creates a logical design of the service and it

defines the technical options related to the service. The

technical options will be implementation specific,

because there are many alternative hardware, software,

communications and development strategies.

Service specifications are normally broken into four layers: user interface (describing the service and user inter-

actions), service architecture (describing service features and primitives and the way they interact with each other), physical network architecture (describing the topology

and the interconnection of network elements), and

communications drivers (describing the low level protocols to be used between network elements).

Important issues in the specification analysis, after the creation of the logical design of the service, include the detection and resolution of incompleteness or inconsistency, service interactions, and performance bottlenecks. Many of these service design complexities result from the need to coordinate interactions between the user of a service and the multiple computing and switching elements involved in providing that service. Besides handling expected service interactions, the service must also handle unexpected interactions generated by abnormal and error conditions. Ensuring that all of these special cases have been identified

D.X. Adumopoulos et al./Computer Communications 21 (1998) 21 l-219 215

and handled properly is necessary for a reliable, high quality

service. In addition, a new service must be analysed for any

problems in using it with existing services and features [ 121.

For creation of specifications for the service, formal models of message exchange and processing can be used.

Such a formal model can be constructed with a common

specification language, such as CCITT’s specification

description language (SDL), which is based on a

communicating finite state machine model. Formal service

specifications, which include semantics, can be analysed not only for completeness and consistency, but also for their

behaviour. In the case of finite state machine service

models, graph theoretic algorithms can detect deadlock

and livelock conditions, unused or unreachable machine

states, and unexpected message reception [ 131. However, the two upper layers of service specifications

(the user interface and the service architecture) tend not to

be amenable to formal models. Additionally, formal models

are rather complex to create and examine and they do not

lend themselves easily to modularity, which is desirable for

larger systems, such as telematic services. Thus, formal

models might be used to express some aspects of the service requirements, but not to create the entire logical model of

the service.

For this purpose the use of object-oriented techniques is proposed [ 14,151. The main advantages of this approach are [l&19]:

well designed objects in object-oriented telematic services are the basis for the services to be assembled

largely from reusable components, leading to higher productivity;

reusing existing classes that have been tested in the field

on earlier projects leads to services which are of higher quality, meet business requirements better and contain

fewer bugs;

inheritance makes it possible to define clearly services that are more flexible, more easily extensible, and less

costly to maintain; message passing allows the interface descriptions

between modules and external services to become much easier and enables services to share resources,

supporting thus GUI development and client/server systems;

object-orientation is a key tool for managing

complexity. Object-oriented services scale up better from small to large. Encapsulation helps with scalability

as project size and complexity increase; partitioning of work has a natural basis and should be

easier. Analysis and design by partitioning a domain into objects corresponding to a solution-oriented view of their real-world counterparts is often more natural than a top-down functional decomposition; information hiding assists the building of secure services; data-centred design captures more of the semantics of a model in implementable form;

l formal specification may be blended harmoniously with

object-oriented methods; . service evolution and maintenance problems are

mitigated by the strong partitioning resulting from

encapsulation and uniform object interfaces; l object-oriented services are potentially capable of

capturing the semantics of an application. In this way

changes are facilitated within the business and more

reversible systems result.

With the use of an object-oriented technique an object-

logical model is created, which represents the specifications

of the service. Initially the model includes only the basic characteristics of the service. Additional detail is added

gradually. The detail includes adding advanced and

specialised features, error processing, service administra-

tion and charging information, resource usage, overload

control, general exception condition handling, security, etc.

As the object model separates the service designer from the actual functions of the network by modelling generic

network objects, independent from a particular network

configuration, the same model can support multiple platforms and configurations within the network. Thus, a

service provider can design a generic service which is

then realised for a particular network configuration by different implementations of the same generic object model [20]. When new facilities become available in the

network, for example an intelligent data to voice converter

or an ATM switch, the object model can easily be extended to incorporate the new additions. However, the original set

of objects is not expected to change, because the original

facilities that they model have not changed. Instead, there will be new objects in an extended model, and perhaps

additional attributes and/or methods for some existing objects.

Together with a specific object-oriented technique, a

number of tools can be used [2 11. These tools have a

friendly, intuitive and easy to use interface. In most cases, this user interface consists of a set of icons from which the service designer selects to represent features of the service or functions in the network,

joins together to represent flow of control between

them, and customises to represent particular characteristics

of an individual invocation. Such tools provide a clear conceptual model of the features and resources available to the service designer, together with a clear and simple set of rules about the construction of services from these

components.

4.4. Service prototyping

In this phase the prototype of the telematic service under examination is constructed. For this reason it is necessary to determine initially the parts of the logical design of the service, which reflects the service specifications, that will be prototyped (e.g. basic service features, critical dialogues,

216 D.X. Adamopoulos et al./Computer Communications 21 (1998) 2/l-219

menu structures, etc.). These parts are then ‘mapped’ onto a particular physical environment.

It should be noted that the service prototyping phase can

occur repeatedly. The service designer enriches the parts of

the logical design of the service that are prototyped, until

they decide that the prototype includes all the necessary

functionality to proceed to the development of the service

(operational prototyping) [22].

Special software tools are necessary for the development

of the service prototype [ 121. These software tools should be

able to:

minimise the conceptual distance between the logical

model of the service (the problem domain) and the

implementation of the prototype;

support logical representation at any level of detail without limitations imposed by resource or language

constraints;

retain flexibility during all repetitions of the service

prototyping phase;

provide an interactive user interface.

The prototype can function as a software simulation of

the service, and also as a base for more realistic hardware/ software testbeds. Software simulation of complex systems,

such as telematic services, requires flexible software tools

that can represent the logical system design elements in an

executable form (rapid prototypes) [23]. These tools should support the rapid creation of design elements that represent

the level of service logic being simulated.

4.5. Prototype verijcation

In this phase the prototype created in the service prototyping phase is evaluated. The evaluation process includes performance measurement, user acceptability, making a comparison with the design objectives (service

requirements), and ensuring the quality of the service

prototype (acceptance criteria).

The task of examining the quality of the service prototype is very important, because a prototype with quality characteristics will lead to a service with quality charac-

teristics in the service development and verification phase. A quality service (prototype) implies (i) that it is

well tested, (ii) that standards, including those about documentation, have been applied, (iii) that it proves

maintainable, (iv) that it is efficient, and (v) that it meets

the specification. As a result of the evaluation process, the prototype

is recursively refined and expanded to simulate the logical model of the service in increasingly greater detail (see Fig. 1, return to the service prototyping phase). This process quickly leads to deeper insight of the model and the problems it may have. The model is frequently refined to eliminate problems as they are discovered (see Fig. 1, return to the service specification phase).

For the evaluation of the service prototype, the prototype verification phase includes the generation of

test data (preferably realistic data), performance of tests (preferably in operational situations), generation of

acceptance test data, performance of acceptance tests, and

obtaining approval. Verification is completed once the

acceptance criteria are satisfied. The use of test

support tools is recommended. Automated support for

testing is desirable to speed the prototype verification

phase and to increase the completeness of the set of test cases. Testing support can take the form of

generating test cases directly from the service specification,

which are then used by test drivers to exercise the prototype

[W.

4.6. Service development and verijication

In this phase of the proposed methodology, the telematic service is created from the prototype and is reviewed to

ensure that it conforms to the acceptance criteria set out at

the prototype verification phase. More specifically, the service development and

verification phase includes construction of the computing

environment, preparation of development procedures, development of the programs necessary to provide

the required service functionality, optimisation of the design of the service according to the service requirements,

construction of databases and files, generation of service modules, generation of module test data, generation

of acceptance test data, performance of acceptance

tests, performance of integration tests, generation of

documentation, and obtaining approval. The deployment

of the service is completed once the acceptance criteria are satisfied. The use of test support tools is recommended in this phase also.

Another important task of this phase is service

integration. It involves testing and correcting the service

in interaction with other services, monitoring the performance of the service, and ensuring that overload

controls are working correctly. The resultant telematic service will process the

appropriate data speedily and accurately, and provide information when and where required, complete and at the

correct level of detail, as it will have been set up for a

specific purpose. It will also be in full agreement with the service requirements set out at the requirements

analysis phase, and it will incorporate high-quality characteristics.

If there is a divergence between the operational service and the desired service, as described in the previous section, a decision is made either to look again at the service and to correct/enhance it (either by repeating the current phase or by returning to the service specification or to the service prototyping phase) or, in the worst case, to redesign it totally (by returning to either of the first two phases of the proposed methodology).

LXX. Adamopouh et a/./Computer Communications 21 (1998) 21 I-219 217

4.7. Service management

This is the final phase of the methodology and takes place continuously after the deployment of the telematic service. It includes tasks related to the administration, maintenance

and evolution of the service, and aims to ensure the

continued efficient operation of the service.

More specifically, the service management phase

includes tasks, such as monitoring performance, tuning software, reorganising databases, etc. and, in general,

tasks relevant to the handling of various changes. Some of

these changes are due to changes in the organisation or its

environment, some to technological advances, and some to

‘extras’ added to the service at an agreed period following operational running. In order to facilitate service manage-

ment and to increase its efficiency, special care has to be

taken during the service specification phase [ 131. The basic

management model which is proposed can be seen in Fig. 2.

In this model, managed service objects provide the mechanisms which are the means used for achieving

required results, policies dictate how to utilise the available

mechanisms, managers apply the policies to the managed

service objects, and management is the selection and use of

mechanisms according to policies.

Finally, it should be noted that some maintenance work is inevitably associated with the correction of errors found since the service’s operation. In these cases, the service

management phase sometimes requires repetition of the pro- posed methodology from a specific phase.

5. Important evaluation criteria

The value of the proposed methodology is determined

by the realisation of its objective as stated in Section 3.

From Section 4 it is evident that the proposed methodology addresses the design and management of

new telecommunications services in a systematic way,

resulting in service prototypes and, finally, services which meet the needs of the end-users and the organisation

and satisfy the service requirements. Quality checks incorporated in the prototype verification phase and the

service development and verification phase assure the high quality of the service prototype and the service. Finally, the

Fig. 2. The proposed basic management model.

rapid prototyping approach guarantees lower cost and

increased speed of the service design and development

process, leading additionally to lower maintenance costs.

However, the proposed methodology leaves the service designer a considerable amount of freedom regarding the

decisions which are necessary for the application of the

methodology for a specific service in a specific organisation,

and the tools and techniques that will be used in each phase.

Thus, each time the methodology is applied, a number of

extra elements are added to it. In order for the methodology

to retain its efficiency and effectiveness, it is necessary that

these elements be incorporated in such a way that the final

result (the service prototype and the service) is characterised

by the following properties [ 12,21,23,24]:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Acceptability: the service fulfils the user requirements.

Availability: the service is accessible; when and where

required.

Cohesiveness: there is interaction between the com-

ponents of the service so that there is overall integration.

Compatibility: the service fits with other services and

other information systems of the organisation.

Documentation: there is good documentation to help

communication between service designers, users,

service administrators, and managers. Ease of learning: the learning curve for new users is

short and intuitive. Economy: the service is cost-effective and within

available resources and constraints. Flexibility: the service is easy to modify and whether it

is easy to add or delete components. Low coupling: the interaction between the components of the service is such that they can be modified without

affecting the rest of the system.

Reliability: the error rate is minimised and outputs are

consistent and correct.

Robustness: the service is fail-safe and fault-tolerant. Security: the service is robust against misuse. Simplicity: ambiguities and complexities are minimised.

Timeliness: the service operates successfully under normal, peak and every conditions. Visibility: it is possible for users to trace why certain

actions occurred.

6. Application of the proposed methodology

In order to verify/demonstrate the feasibility and illustrate

the utility of the proposed methodology, and to gain more insight into the issues involved, the methodology has been applied to the specification of a multimedia conference service for education and training. The most important requirements of this service are presented graphically in the usage diagram of Fig. 3. This diagram consists of the users/ communicating entities and the channels which link them. Each channel corresponds to a specific communication task.

218 D.X. Adamopoulos et aL/Computer Communications 21 (1998) 21 I-219

human to human ‘1 conversational

\

conversational

Fig. 3. Usage diagram of a multimedia conference service for education and training.

In the service specification phase, the object-oriented

paradigm was selected because of the advantages stated in Section 4.3, More specifically, the Coad and Yourdon

object-oriented analysis and design (GOAD) method [25] was chosen, as it is widely accepted to be one of the

strongest methods as well as one of the most popular 1141. Thus, the service specification phase is composed of

three different models: (1) the object model, (2) the task model, and (3) the architectural model. Each of these

models give emphasis to different service features. The

object model primarily describes the functionality and data manipulated by the service. The task model describes the way control is enforced within the service. Finally, the

architectural model gives the actual layout and task distribution of the service.

The prototype of the multimedia conference service for

education and training is currently under development using the Visual C++ programming language together with the distributed processing environment provided by Microsoft for Windows 95 and Windows NT 4.0 (Distributed

Component Object Model, DCOM).

7. Conclusions

A methodology for the design and management of telematic services has been proposed. Rapid prototyping is a key concept in this methodology. By developing a prototype uncertainties about the service can be resolved. Short-term additional costs can result in long-term savings as requirements and design decisions are clarified during the prototyping phase. Furthermore, rapid prototyping is expected to realise its full potential in the area of

telematic services with the extensive use of object-oriented technology and support from enhanced tools for computer-

aided design and analysis.

References

[I] R. Budde, K. Kautz. K. Kuhlenkamp, H. Zullighoven, Prototyping: An

Approach to Evolutionary System Development, Springer, Berlin,

1991.

[2] D.E. Avison, G. Fitzgerald, Information Systems Development:

Methodologies, Techniques and Tools, McGraw-Hill, London, 1995.

[3] P.A. Deamley, P.J. Mayhew, In favour of system prototypes and their

integration into the systems development cycle, Comput. J., (1986)

26-27.

[4] I. Sommerville, Software Engineering, Addison-Wesley, Reading,

MA, 1992.

(51 D.E. Avison, D. Wilson, Controls for effective prototyping, J. Manag.

Syst. 58 (1992) 13-24.

[6] Q. Lu, W. Royce, Status report computer-aided prototyping, IEEE

Software 1 I (1991) 7781.

[7] CA. Papandreou. Die Entwicklung neuer Telekommunikations-

formen, R.v. Decker’s Verlag-G. Schenk, Heidelberg, 1984.

[8] D. Hough, Rapid delivery: an evolutionary approach for application

development, IBM Syst. J. 32 (I 993) 397-418.

[9] B.C. Hardgrave, When to prototype: decision variables used in indus-

try, Inf. Software Technol. 37 (1995) I 13- 1 18.

[IO] D. Cleevely, R. Cawdell, A telecommunications taxonomy,

Telecommun. Policy 6 ( 1986) IO7- I 19.

[I 11 CA. Papandreou, D.X. Adamopoulos, A framework for the

application of distributed broadband multimedia communication

services in education and training, FITCE Rev., 4 (1996) 2 13-2 16.

(121 M. Moser, A prototype service creation environment, Proc. IEEE

Conf. on Communications, 1990, pp. 341-345.

[ 131 D. Lewis, T. Tiropanis, A. McEwan, Inter-domain integration of

services and service management, Lecture Notes in Computer Science

No 1238 (Intelligence in Services and Networks: Technology for

Co-operative Competition), Springer Verlag, 1997, pp. 283-292.

D.X. Adamopoulos et al./Computer Communications 21 (1998) 211-219 219

[ 141 P. Fitsilis, Object-oriented development for telecommunication ser-

vices, lnf. Software Technol. 37 (1995) 15-22.

[ 151 Y. Seiichi, K. Kiyohiko, I. Mitsutaka, Y. Rynichi, Object-oriented

design of telecommunication software, IEEE Software I (1993)

8 I-87.

[ 161 G. Booth. Object-Oriented Analysis and Design with Applications,

Benjamin/Cummings, 1994.

[ 171 E.L. Cusack, ES. Cordingley, Object-orientation in communications

engineering, BT Technol. J. 3 (1993) 9-17.

[I81 I. Graham, Object-oriented methods, Addison-Wesley, Reading, MA,

1995.

1191 J. Rumbaugh, M. Blaha. W. Premerlani, F. Eddy, W. Lorensen,

Object-Oriented Modelling and Design, Prentice-Hall, Englewood

Cliffs, NJ, 1991.

1201 K. Hino, H. Tani. K. Takeda, S. Ishihara, T. Nishida, Object-oriented

telecommunications services testbed system, IEICE Trans. Telecom-

mun. E77 (B) (1994) 1332-1341.

[21] J. Allen, An environment for rapid service development, 4th IEE

Conf. on Telecommunications, IEE 1993, pp. 21 I-216.

[22] A.M. Davis, Operational prototyping: a new development approach,

IEEE Software 9 (1992) 70-78.

123) R.R. LeBlanc, intelligent network basic call model rapid prototype,

Proc. IEEE Conf. on Communications, IEEE Press, 1993, pp. 1543.

1547.

[24] W.T. Chang, W.Y. Li, D.G. Messerschmitt, N. Chang, Rapid

deployment of CPE-based telecommunications services, IEEE

GLOBECOM Conf. Proc., 1994, pp. 876-880.

1251 P. Coad, E. Yourdon, Object-Oriented Analysis, Yourdon, Englewood

Cliffs, NJ, 1991.