Virtual reality systems estimation vs. traditional systems estimation

The Journal of Systems and Software 72 (2004) 187–194

www.elsevier.com/locate/jss

Virtual reality systems estimation vs. traditional systems estimation

Mar�ıa I. S�anchez-Segura a,*, Juan J. Cuadrado a, Ana-Mar�ıa Moreno b,Antonio de Amescua a, Ang�elica de Antonio b, Oscar Marb�an a

a Computer Science Department, Universidad Carlos III de Madrid, Avda. De la Universidad, 30, 28911 Legan�es (Madrid), Spainb Facultad de Inform�atica, Universidad Polit�ecnica de Madrid, Campus de Montegancedo s/n, 28660 Boadilla del Monte (Madrid), Spain

Received 29 October 2002; received in revised form 21 April 2003; accepted 22 April 2003

Abstract

This paper examines the problems of applying traditional function points count rules to virtual reality systems (VRS). From the

analysis of the differences between traditional and VRS systems, a set of deficiencies in the IFPUG 4.1 function points count method

was detected. Due to the increasing importance of these kinds of applications, it is necessary to study how traditional function points

count rules can be adapted to estimate VRS. In this paper, we are going to focus on the possibility of estimating function points

accurately using a proposed guideline which was successfully applied to estimate two VRS.

� 2003 Elsevier Inc. All rights reserved.

Keywords: Estimation methods; Function points; Interactive systems; Virtual worlds

1. Introduction

In this article, we present an adaptation of the Alb-

retch/IFPUG function points to virtual reality systems

(VRS). This section gives a brief overview of VRS and

function points.

Interactive systems, in software terms, are tradition-

ally associated with the relationship between the user

and the software product through the system’s interface.Today, it is generally accepted that adequate interaction

is offered by the technologies developed by Douglas

Engelbart (the mouse, windows, etc.) (Engelbart, 1986);

and by Alan Kay (the first graphic interfaces) (Kay and

Golberg, 1997) at the beginning of the seventies. Since

then, there have been many advances in this field.

However, there are three features which determine the

differences between past and future interactive systems(Berenguer, 1997):

*Corresponding author. Tel.: +34-91-624-94-21; fax: +34-91-624-

91-29.

E-mail addresses: [email protected] (M.I. S�anchez-Segura),[email protected] (J.J. Cuadrado), [email protected] (A.-M.

Moreno), [email protected] (A. de Amescua), [email protected]

(A. de Antonio), [email protected] (O. Marb�an).

0164-1212/$ - see front matter � 2003 Elsevier Inc. All rights reserved.

doi:10.1016/S0164-1212(03)00173-0

• The amount of control the user has, that is, the de-gree of autonomy which allows the user to decide

what to do, where to navigate, etc.

• The amount of interaction allowed which depends on

the possibilities the user has to interact with the sys-

tem.

• The presence or personal involvement of the user,

that is, how immersed they are in the images and

sounds. In this paper, the amount of presence is notstrictly linked to virtual reality devices, but rather,

to how credible the VRS is for the user.

If we take the three variables: interaction required,

autonomy and presence, as the axes of coordinates, we

will obtain a three dimensional space (Fig. 1) in which

we can place present and future interactive programs.

These programs are called VRS when the sensation ofpresence and immersion are high. We have used VRS in

a broader sense of the term; that is, systems which have

a high degree of presence and which do not imply the

use of virtual reality devices to interact with the user.

Today, virtual environments are the maximum repre-

sentation of VRS.

The size of a project is usually measured in the first

stage of the software lifecycle through the functionalityrequired for the system. Therefore, one of the first steps

mail to: [email protected]

Fig. 1. Variables which describe virtual reality systems.

188 M.I. S�anchez-Segura et al. / The Journal of Systems and Software 72 (2004) 187–194

in the management of a VRS is, as in the rest of software

systems, the estimation of function points to establish

the size of the software that will allow project managers

to obtain estimations of effort and time required to build

the VRS. For traditional applications, function points

count rules are perfectly defined in the main function

points count methods: IFPUG (2000), UKSMA (1998),NESMA (1997), COSMIC (2000).

Software systems are evolving continuously, so tra-

ditional function points count rules must provide good

estimation results for both traditional software and for

new and emerging kinds of software systems like VRS.

Some studies have reviewed the function points analysis

methodology and identified some of its weaknesses in

areas such as domain of applicability or the structure ofits primary components (Desharnais, 1990; Desharnais,

1998; St-Pierre et al., 1997; Garmus, 1996).

The differences between traditional and VRS software

are explained in Table 1 (Bricken, 1990). These differ-

ences imply the identification of a set of components

endowed with specific visualization features, special

procedures which facilitate the use of the VRS (by the

user) and which allow VRS components to adapt to theuser instead of the user adapting to the VRS. Devices

and their representation in the VRS (devices manager)

must be considered because they allow the user to feel he

or she is immersed in the VRS.

We have developed a set of guidelines which, com-

pared with the estimation of traditional function points

Table 1

VRS versus traditional software

Traditional software V

The interface is used to offer functionality T

People learn to use the computer through its own mechanisms V

Users use the software developed U

g

Normally traditional software is only visual V

d

Metaphors are used to offer the rest of users a mental model of what

they can expect from the application

I

w

count rules, improved the estimation results of our VRS

projects. These guidelines allow the accurate association

between VRS features and function points count rules

for projects since, in these kind of projects, is not clear

how to select values for factors which correct non ad-

justed function points.Section 2 defines the steps included in the IFPUG 4.1

Function Points count method, in which the specific

features of VRS and the way they can be taken into

account in the count process must be considered; even

the estimation obtained will be more realistic. Section 3

describes the results obtained through the application of

the proposed guidelines in two different VRS develop-

ment, and Section 4 presents the conclusions and iden-tifies future studies.

2. Proposal on virtual reality systems function points

counts

Some authors like Larijani (1994), affirmed that VRS

can be developed using object oriented methodologies,so an estimation based on Objects can be useful for

VRS. This is the reason why this proposal is based on

Fetcke’s work (Fetcke et al., 1997) which maps the

Object Oriented Paradigm into function points analysis.

Our focus is on VRS boundaries as well as a set of

guidelines to count function points in VRS. Anything

not discussed in this paper, for example, how to obtain

the complexity of any element used by the functionpoints count method such as ILF, EIF; etc., can be

found in Fetcke et al. (1997).

2.1. Virtual reality systems boundary

The first step in the process of measuring any soft-

ware is to delimit the application. As VRS are new

kinds of applications, there are no references whichdescribe the boundaries and/or the elements of a VRS.

In Fig. 2 we propose a set of elements to be considered

when estimating a VRS and then describe these ele-

ments as well as the things found inside and outside the

VRS.

irtual reality systems

he interface includes the user in the VRS

RS technology adapts the computer to the tasks to be done by man

sers are active agents (in the application) because VRS are prepared to

row and change with users’ actions

RS can be multi-modals, can be endowed with 3D sound, 3D images,

evices to improve the immersion sensation, etc

n VRS, the metaphor is not necessary because users interact directly

ith objects as if they were real

Fig. 2. VRS boundary outside the VRS.

M.I. S�anchez-Segura et al. / The Journal of Systems and Software 72 (2004) 187–194 189

2.1.1. Outside the VRS

As in traditional software systems, the VRS user and

External systems are considered external actors. How-

ever, Avatars, Agents and Virtual devices must also beconsidered external actors.

The user representation within the VRS is called

Avatar. 1 Tasks can be delegated to the avatar making it

as autonomous as the user wants it to be. Therefore,

although the avatar is sometimes guided by a person, it

must be considered an external actor which demands

functionality of the VRS when it acts independently.

Virtual reality devices send information to the VRSand, consequently, must be considered external ele-

ments.

It is important to emphasize the possibility of navi-

gating between different VRS, which means that VRS,

other than the one under development, must be con-

sidered external systems.

2.1.2. Inside the VRS

Due to the amount of components which can appear

in a VRS, and due to the dimensions of the VRS, it is

necessary to sub-divide the whole VRS in order to best

describe each component and its features, and to make it

easier to understand and measure each part of the sys-

tem. Each subdivision will be called sub-VRS.

Sub-VRS can contain a lot of components which can

vary from decorative pieces to intelligent elements in theVRS. This explains why each component can be en-

dowed with some of the following features:

1 Avatar comes from Sanskrit and means reincarnation.

• Perception: to be aware of the rest of components.

• Reason: to decide what to do on each situation.

• Action: to represent or to perform the result of the

reasoning process.

The classification of perception–reason–action is

taken from the agents’ theory (Sloman, 1999) because

this model can be used to describe the behavior of all the

components which inhabit the VRS.

To endow components with credibility, three ele-

ments must be considered:

• Internal features: which can be mood, a set of person-ality traits, a social model, etc.

• Past history: which represents the things that hap-

pened to each component in previous connections

to the VRS.

• Memory: which represents the things happening to

each component while connected to the VRS.

In order to enhance a VRS, it can also be providedwith a simulation manager or an intelligent tutor. If the

VRS uses Virtual reality devices, then a device manager

must be incorporated to manage the signals coming

from different devices. The VRS can also be provided

with something like a collective manager or an envi-

ronment manager to control physical features such as

gravity or collisions.

2.2. Counting function points in VRS

We proposed some guidelines to overcome the pre-

viously-mentioned deficiencies in current function points

estimation methods. Taking the known IFPUG 4.1


function points method (IFPUG, 2000) as a starting

point, only the steps which present variations for VRS

are described. The other steps can be followed from the

IFPUG method without any important variations over

the function points count.

First of all, we summarized the boundary rules for aVRS, then the influences of VRS on elemental processes

and lastly, defined the guidelines to determine the degree

of influence.

2.2.1. Boundary rules

• Accept each human actor as a user of the system.

• Accept each non-human actor as a separate system

which was not created to provide functionality onlyto the system under consideration. Therefore, avatars

or agents cannot be considered because they are de-

signed to provide functionality to the system.

• Reject each non-human actor which is part of the un-

derlying system, for instance, a virtual reality device.

2.2.2. Elemental processes

We have proposed rules to identify ILF, EI and EO.EIF rules are not necessary because EIFs can be iden-

tified in the same way in VRS and traditional software

applications.

• Internal Logical File (ILF)

� For each virtual reality device, one ILF must be

counted because each virtual reality device gathers

information that the system must collect and man-age.

� For each kind of component:

– consider one ILF to store perception parame-

ters. It is necessary to store at least the location

of the avatar or agent.

– count one ILF to store internal features. These

can be mood, personality traits, social traits, etc.

– count one ILF to store memory. This may holdthe most recent events that occurred in the VRS.

– count one ILF to store past history; this may be

the history of the avatar or agent related to their

connections to the VRS.

• External Input (EI)

� The connection process must be considered an

external input because it interferes with the perfor-

mance of the system.� All the functionalities the user can delegate to its

representation in the VRS must be considered

external input. This is because the user decides

what he or she wants to control and what to leave

to its representation in the VRS.

� The information input received through the inter-

face and those initiated through the action of an

agent must be considered external input becauseboth interfere with the performance of the system.

• External Output (EO)

� For each kind of component in the VRS, an exter-

nal output must be counted for each action to be

perceived by the user.

2.2.3. Degree of influence

A set of recommendations for some general system

characteristics is proposed for those who want to use

adjusted function points. Some characteristics were not

mentioned because they are not dependent on VRS and

can be obtained using traditional methods.

• Factor 1. Data Communication

Value 0 must be selected if the VRS to be imple-mented is not networked. If the system is networked, but

only uses a one-communication protocol, value 4 is se-

lected. Value 5 is chosen when more than one type of

communication protocol is used.

• Factor 2. Distributed Data Processing

Select Value 2 if the VRS, and not the final user,

processes and transfers data to other components of the

system, for example, the virtual reality device.• Factor 3. Performance

Select Value 3 if the VRS operates in real time.

• Factor 5. Transaction Rate

Select Value 5 if performance studies must be

achieved since, in these kinds of applications, the ma-

chine capability in many components must be taken

into account.

• Factor 7. End-User Efficiency

The possibility of adapting elements identified for

traditional software to a three dimensional space must

be taken into account. For instance, (the possibility

of) implementing the VRS help as an agent which is

part of the three dimensional space. In this case, the

value selected will correspond to a system which has

‘‘help’’.

• Factor 8. Online Update

The same criterion as in Factor 6 is applied, bearing

in mind that an agent can update the Internal Logical

Files or it can be done automatically by the VRS.

• Factor 9. Complex Processing

We identified a set of features which allows the

selection of the complexity factor, degree of influence by

interviewing experts. The selection of these features was

established by analyzing the complex processes whichmust be developed inside the VRS.

Taking the description of Factor 9 Complex Pro-

cessing in IFPUG (2000) as a reference, we described a

set of guidelines to identify the relation between Factor

9 values and VRS features.

� Sensitive control (for instance, special audit pro-

cessing) and/or application specific security pro-

cessing: for a VRS, a specific security processingmay be the network performance which allows

the multi-user operation mode.


� Extensive logical processing: for a VRS, this

feature can be understood as the need to endow

the VRS with a personality traits model, a social

model or a complex reasoning model.

� Extensive mathematical processing: a VRS must

be endowed with this feature if the implementationof a perception (also called awareness) model and/

or graphic capabilities are necessary.

� Many exceptions in processing resulting in incom-

plete transactions that must be processed again

(for example, incomplete ATM transactions

caused by TP interruption, missing data values,

or failed validations). This feature is not applicable

to VRS because are not transactional systems.� Complex processing to handle multiple input/out-

put possibilities (for example, multimedia, or de-

vice independence). This feature will be taken

into account only if the VRS requires the use of

virtual reality devices and/or if VRS components

have multimedia features like video, sound, etc.

• Factor 12. Operational Ease

Select Value 5 for this factor. In these systems, theoperator only takes part to start up the system and

control the error recovery because each time the VRS is

drawn, possible errors must be corrected.

• Factor 14. Facilitate Change

Select Value 2 for this factor if the VRS maintains

control data in tables which are updated by the users

through the on-line interactive process and change

is effected immediately. Control data is the informationmanaged in the elements identified in each component.

Table 2

Unadjusted function points count for the Escondite Ingles project

Complexity Weight Escondite I

Without pr

Number

External input High 6 0

Average 4 14

Low 3 0

External output High 7 0

Average 5 0

Low 4 0

Internal logical file High 15 0

Average 10 0

Low 7 29

External logic file High 10 0

Average 7 0

Low 5 0

External queries High 6 1

Average 4 0

Low 3 2

Total unadjusted function points

3. Experimental results

Two projects were developed to validate the VRS

function points estimation guidelines described above.

Both focus on the development of two VRS with dif-

ferent features. One of them is oriented toward enter-tainment, in particular to the game ‘‘Escondite Ingles’’,

with other users on line. The other is oriented toward

training in nuclear power stations.

Function points estimation was applied to both pro-

jects with and without the VRS estimation guidelines

proposed. In both projects, the estimations were made

after the project was developed because real code lines

were used for the final comparison. If the estimationshad been done in the early stages of the projects, there

would have been significant deviations in the function

points.

The results obtained for each project appear in Tables

2 and 3 respectively. As can be seen in both tables, the

greatest differences appear in External Outputs. For

the Escondite Ingles project, the guidelines defined allow

the identification of 25 high complexity and 14 lowcomplexity EOs. These EOs represent actions to be

performed by the avatar or any other component, and

which must be observed by the user. These kinds of

interactions are difficult to identify without the proposed

guidelines. The same happens with the PRVIR project:

32 high complexity EOs and five low complexity EOs

were identified, which again represent actions to be

performed by the avatar, while 0 EOs were identifiedusing traditional function points guidelines.

ngles project

oposed guidelines With proposed guidelines

Total Number Total

0 0 0

56 15 60

0 0 0

0 25 175

0 0 0

0 14 56

0 0 0

0 0 0

203 29 203

0 0 0

0 0 0

0 0 0

6 1 6

0 0 0

6 2 6

271 506

Table 3

Unadjusted function points count for the PRVIR project

Complexity Weight PRVIR Project

Without proposed guidelines With proposed guidelines

Number Total Number Total

External input High 6 0 0 1 6

Average 4 37 148 37 148

Low 3 0 0 0 0

External output High 7 0 0 32 224

Average 5 0 0 0 0

Low 4 0 0 5 20

Internal logical file High 15 0 0 0 0

Average 10 0 0 0 0

Low 7 34 148 34 148

External logic file High 10 0 0 0 0

Average 7 0 0 0 0

Low 5 0 0 0 0

External queries High 6 0 0 0 0

Average 4 0 0 0 0

Low 3 0 0 0 0

Total unadjusted function points 296 546

Table 5

PRVIR project degree of influence

Feature PRVIR adjustment factor

Without proposed

guidelines

With proposed

guidelines

1: Data Communications 4 4

2: Distributed Data

Processing

0 0

3: Performance 3 3

4: Heavily Used

Configuration

1 1


Tables 4 and 5 show the degree of influence value for

both projects with and without the proposed guidelines.

The factors which appear in italics were the ones which

were considered in the proposed guidelines.

The following can be observed in Table 4:

• The value for Distributed Data processing changed

from 0 to 2 because the virtual reality device usedin this project would not have been identified without

the proposed guidelines.

Table 4

Escondite Ingles project degree of influence

Feature Escondite Ingles adjustment factor

Without proposed

guidelines

With proposed

guidelines

1: Data Communications 4 4

2: Distributed Data

Processing

0 2

3: Performance 3 3

4: Heavily Used

Configuration

2 2

5: Transaction Rate 0 5

6: Online data entry 5 5

7: End-user efficiency 2 2

8: Online Update 0 2

9: Complex Processing 2 4

10: Reusability 1 1

11: Installation Ease 0 0

12: Operational Ease 0 5

13: Multiple Sites 1 1

14: Facilitate Change 0 2

Total 20 38

5: Transaction Rate 0 5

6: Online Data Entry 5 5

7: End-User Efficiency 1 1

8: Online Update 0 2

9: Complex Processing 1 2

10: Reusability 1 1

11: Installation Ease 0 0

12: Operational Ease 0 5

13: Multiple Sites 0 0

14: Facilitate Change 0 2

Total 16 31

• The value for Transaction Rates changed from 0 to 5

because the impact of the technology for these kinds

of systems cannot be observed without the proposed

guidelines.

• The value for Online update changed from 0 to 2 be-

cause the updating done by agents would not have

been identified without the proposed guidelines.

• The value for Complex Processing changed from 2 to4 because the need for a personality traits model and

a perception model would not have been identified

without the proposed guidelines.

Fig. 3. Summary of function point estimation.


• The value for Operational Ease changed from 0 to 5

because it would not have been easy to know how

often the operator interacts with the system without

the proposed guidelines.• The value for Facilitate Change changed from 0 to 2

because it would not have been possible to know that

the system updates tables with data provided by the

user without the use of proposed guidelines.

Changes in Transaction Rates, Online Update,

Operational Ease, and Facilitate Change can be observed

in Table 5 for the same reasons described for Table 4.Fig. 3 summarizes the rest of the operations carried

out following the IFPUG recommendations to obtain

adjusted function points.

The results obtained from the estimation with and

without the guidelines were compared with the size in

the source code lines of both the current PRVIR and

Escondite Ingles systems. We used Caper Jones’ con-

version tables (Capers, 1998) to obtain the source codelines from the adjusted function points estimated and

considered the following conversion data:

• 1 adjusted function point for Escondite Ingles corre-

sponds with 29 Visual Basic 5.0 source code lines be-

cause Escondite Ingles was developed in a basic script

language similar to Visual Basic 5.0.

• 1 adjusted function point for PRVIR correspondswith 34 Visual C++ source code lines because PRVIR

was developed in Visual C++.

The results of the above conversion can be seen in

Fig. 4. For both projects, the code lines obtained with

6680,15

15114,22

16500

8151,84

17821,44

21080

0

5000

10000

15000

20000

25000

LOC without guideline LOC with guideline Actual LOC

Project

LOC Escondite

Ingles

PRVIR

Fig. 4. Relation between actual and estimated code lines.

the use of the proposed guidelines are closer to the ac-

tual code lines than the ones obtained with traditional

estimation. It can be concluded that the estimation with

the proposed guidelines is more exact than the one ob-tained without them.

4. Conclusions of experiment results and future work

Since their first definition at the end of the seventies,

function points have evolved significantly. The main

vehicle for these changes has been the continuous needto adapt the method to:

• The new types of software applications which are

being developed, and which include VRS.

• The new software analysis and design methods,

among which the main innovation was the object ori-

ented paradigm.

The most widely used system in the evolution of the

estimation method for software applications for func-

tion points is made up of two sequential stages:

1. Theoretical modification proposals or amplification

of same to provide greater scope in new types of sys-

tems.

2. Experiments to test the merits and deficiencies of thesolution proposed.

This study was an attempt to find the deficiencies

or ambiguities in IFPUG function points estimation

method and to propose solutions for a VRS count. No

attempt was made to rewrite the IFPUG method. As a

result of our findings, specific guidelines for VRS were

defined, and through subsequent validation, we canconclude that these guidelines improve the estimation of

traditional function points count for VRS.

These proposed guidelines were tested in two projects

only. Therefore, more projects should be estimated

using these guidelines in order to obtain more precise

data on its validity.

New emerging kinds of software applications will

demand an adjustment of function points count rules, sothe proposed guidelines can be used as a first step to

achieve more realistic size measures to calculate effort,

time, cost, etc., and to determine the specific needs of

new software.


Future studies will focus on new experiments to val-

idate and enhance the proposed guidelines presented.

References

Berenguer, X., 1997. Writing Interactive Programs.Magazine Formats.

Bricken, M., 1990. Virtual Worlds: no Interface to Design. Human

Interface Technology Center, University of Washington. Technical

Report R-90-2.

Capers, Jones T., 1998. Estimating Software Costs. McGraw Hill.

Common Software Measurement International Consortium (COS-

MIC), 2000. ‘‘COSMIC-FFP, version 2.1’’.

Desharnais, J.-M., 1988. Analyse statistique de la productivit�e des

projets de d�eveloppement en informatigue �a partir de la technique

des points de fonction. Maıtrise en informatique de gesti�on,

Universit�e du Qu�ebec �a Montreal.

Desharnais, J.-M., 1990. Adjustment model for function point scope

factors––a statistical study. In: Proc. IFPUG Spring Conf., Fla.

Engelbart, D.C., 1986. A research centre for augmenting human

intellect. In: Proceedings of the Fall Joint Computer Conference,

vol. 33. pp. 395–410.

Fetcke, T., Abran, A., Nguyen, T., 1997. Mapping the OO––Jacobson

Approach into Function Point Analysis. Software Engineering

Management Research Laboratory, Universit�e du Qu�ebec �aMontr�eal.

Garmus, D., 1996. Fuction Poits Counting in real time environment.

CrossTalk Journal 9 (1), 11–14.

International Function Points Users Group (IFPUG), 2000. Function

point counting practices, version 4.1.1.

Kay, A., Golberg, A., 1997. Personal dynamic media. IEEE Computer

10 (3), 33–41.

Larijani, L.C., 1994. Realidad Virtual. McGraw Hill.

Sloman, A. 1999. Evolvable architectures for human-like minds. In:

13th Toyota Conference on Affective Minds, Nagoya, Japan.

St-Pierre, D., Maya, M., Abran, A., Desharnais, J.-M., 1997. Adapting

function points to real-time software. In: IFPUG 1997 Fall

Conference, Scottsdale, Arizona, IFPUG.

The Netherlands Software Metrics Users Association (NESMA), 1997.

Definitions and counting guidelines for the application of function

point analysis, version 2.0.

United Kingdom Software Metrics Association (UKSMA), 1998. MK

II Function point analysis counting practices manual, version 1.3.1.

Mar�ıa-Isabel S�anchez-Segura has been faculty member of the Com-puter Science Department in the Carlos III Technical University ofMadrid since 1998. Her research interests include software engineering,and multi-user virtual environments. Mar�ıa-Isabel holds a B.S. inComputer Science, an M.S. in Software Engineering and a Ph.D. inComputer Science from the UPM.

Juan Jos�e Cuadrado has been faculty member of the Computer ScienceDepartment in the Carlos III Technical University of Madrid since1997. His research interests include software engineering and softwaremetrics. Juan Jos�e holds a B.S. in Physics, and a Ph.D. in ComputerScience from the Carlos III technical university.

Ana-Mar�ıa Moreno has been Assistant Professor at FI––UPM sinceOctober 1997. Her research interests include software engineering,Empirical validation of software engineering and Intersection ofSoftware engineering and knowledge engineering. Ana-Mar�ıa holds aB.S. in Computer Science, a M.S. in Software Engineering and a Ph.D.in Computer Science from the UPM.

Antonio de Amescua has been faculty member of the Computer ScienceDepartment in the Carlos III Technical University of Madrid since1989. His research interests include software engineering, processimprovement. Antonio de Amescua holds a B.S. in Computer Science,and is a Ph.D. in Computer Science from the UPM.

Ang�elica de Antonio has been Assistant Professor at FI––UPM since1990. Her research interests include software engineering, SoftwareProcess Improvement: Transition Packages, and Software ProcessEvaluation. Ang�elica de Antonio holds a B.S. in Computer Science, aM.S. in Knowledge Engineering and a Ph.D. in Computer Sciencefrom the UPM.

Oscar Marb�an has been faculty member of the Computer ScienceDepartment in the Carlos III Technical University of Madrid since2001. His research interests include software engineering, Datamining.Oscar Marb�an holds a B.S. in Computer Science, and is a Ph.D. stu-dent in Computer Science from the UPM.

Documents

Virtual reality systems estimation vs. traditional systems estimation