Functional Size Measurement Method for Object-Oriented Conceptual

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE HOVENIERSBERG 24 B-9000 GENT Tel. : 32 - (0)9 – 264.34.61 Fax. : 32 - (0)9 – 264.35.92

WORKING PAPER Functional Size Measurement Method for Object-Oriented Conceptual Schemas: Design and Evaluation Issues

Silvia Abrahão 1 Geert Poels 2 Oscar Pastor 1 March 2004 2004/233

1 Department of Computer Science and Computation, Valencia University of Technology 2 Management Informatics Research Unit, Department of Management Information, Operations Management and Technology Policy, Ghent University This paper has been written during a research stay of Silvia Abrahão at the Faculty of Economics and Business Administration, Ghent University (January 2004).

D/2004/7012/19

A Functional Size Measurement Method for Object-Oriented Conceptual Schemas: Design and Evaluation Issues Silvia Abrahão1, Geert Poels2, and Oscar Pastor1 1

Department of Computer Science and Computation, Valencia University of Technology Camino de Vera, s/n, 46022, Valencia, Spain {sabrahao, opastor}@dsic.upv.es 2

Faculty of Economics and Business Administration, Ghent University Hoveniersberg 24, 9000 Gent, Belgium [email protected]

Abstract. Functional Size Measurement (FSM) methods are intended to measure the size of software by quantifying the functional user requirements of the software. The capability to accurately quantify the size of software in an early stage of the development lifecycle is critical to software project managers for evaluating risks, developing project estimates and having early project indicators. In this paper we present OO-Method Function Points (OOmFP), a new FSM method for object-oriented systems that is based on measuring conceptual schemas. OOmFP is presented following the steps of a process model for software measurement. Using this process model we present the design of the measurement method, its application in a case study, and the analysis of different evaluation types that can be carried out to validate the method and to verify its application and results. Keywords. Conceptual Modeling, Object Orientation, Software Measurement, Functional Size Measurement, Measure Validation, Measurement Verification.

1

Introduction

A functional size measurement (FSM) method measures the logical external view of the software from the users’ perspective by evaluating the amount of functionality to be delivered. The capability to accurately quantify the size of software in an early stage of the development lifecycle is critical to software project managers for evaluating risks,

developing project estimates (e.g., effort, cost) and having early project indicators (e.g., productivity). The most widely used FSM method is IFPUG Function Point Analysis (IFPUG FPA) [17]. It is based on the method proposed by Alan Albrecht [6]. This technique was developed specifically to measure the amount of data that each function accesses as an indicator of functional size. However, this method assumes the use of traditional software development methodologies such as structured analysis and design. One of the most serious practical limitations of existing FSM methods is their inability to cope with object-oriented systems. A number of approaches have been proposed in the literature to address this issue [8], [9], [15], [16], [18], [27], [28], [30], [40], [42], [45], [48], [49], but so far, none of these has been widely accepted in practice. Some problems related to these proposals are: they focus on implementation aspects and hence lack generalization [40], they do not consider all concepts of the OO paradigm (inheritance, aggregation, etc.), and they take into account only the static dimension of an OO system (i.e. the structural aspects commonly represented in an object model) [8] and do not consider dynamic aspects like object interaction and object behaviour. Also, some proposals do not use an ISO-standardized method like IFPUG FPA, but define new methods of sizing. One disadvantage is that the functional size measured with these approaches is not comparable with the standards accepted in practice. Apart from these problems, no systematic evaluation of the ‘validity’ of the proposed FSM alternatives for OO systems could be found in the literature. In this paper we present a new method, OO-Method Function Points (OOmFP) [1], [35] that has been developed to overcome the above mentioned difficulties in the specific context of an automated software production method called OO-Method [36]. In an OO-Method system specification two models are distinguished: the conceptual model (centered on the problem space) and the execution model (centered on the solution space). The OO-Method conceptual model uses UML-compliant diagrams [11] for specifying four orthogonal views of an OO system: •

Object Model: static representation of the classes and their relationships.

•

Dynamic Model: object lifes described in a State Transition Diagram and interobject interaction described in an Object Interaction Diagram.

•

Functional Model: a description of the semantics associated to the changes of an object’s state as a consequence of service occurrences.

•

Presentation Model: patterns to describe user interaction with the system.

These four model views can subsequently be transformed into a formal system specification which acts as a high-level system repository. Furthermore, using the execution model, an OO software system which is functionally equivalent to the formal system specification is generated in an automated way [36]. OOmFP was designed to conform to the IFPUG FPA counting rules [1]. It basically redefines the IFPUG counting rules in terms of the concepts used in OO-Method. But apart from this, the method was designed to overcome the difficulties that are usually encountered when measuring the functional size of OO systems. The main features built into OOmFP are: •

The functional size measurement is made at the conceptual schema level. As a consequence, the functional size is measured in the problem space and is independent of any implementation choices.

•

All information related to functional size that is specified in the four OO-Method conceptual model views is used for measurement.

•

Object-oriented concepts like inheritance and aggregation are explicitly dealt with.

The purpose of this paper is to present the construction, application and evaluation of OOmFP in a systematic way, using the process model for software measurement proposed by Abran and Jacquet [4]. This model was used as the development framework in which OOmFP can be evaluated and improved. The rest of this paper is structured as follows: Section 2 discusses previous work on functional size measurement of OO systems. Section 3 reviews the main steps of the process model proposed for software measurement. Section 4 describes the design of OOmFP. Section 5 presents a framework for applying OOmFP and a case study. Section 6 contains an analysis of the different types of evaluation that can be carried out to ensure the validity and efficacy of OOmFP. We discuss our findings and reflect upon our evaluation procedure and make some suggestions as to how it might be improved for future investigations. Finally, section 7 summarizes the conclusions and future work.

2

Previous Work

Function Point Analysis (FPA) proposed by Albrecht [6] can be considered as the first FSM method. FPA’s view on functional size is that a software system consists of logical files and functions that perform transactions using or altering the data in the logical files. The amount of data (types) ‘handled’ by a logical file or transactional function determines the amount of functionality that the software delivers, hence its functional size. FPA has evolved from Albrecht’s method and is currently supported by the International Function Point User Group (IFPUG), which has proposed detailed rules for applying FPA [17]. Also a number of FPA variants have been proposed taking alternative views on functional size, the most important of which are Mark II FPA [46], Full Function Points (FFP) [43] and recently COSMIC FFP [3]. Moreover, in order to cope with objectoriented systems measurement several approaches have been proposed. We can group these approaches into three categories of FSM methods for OO systems. A first category consists of methods that are compliant to IFPUG FPA. These methods reformulate the IFPUG rules in terms of OO concepts to facilitate the function points counting process. The final result of the function point count is the same as what would have been obtained by directly applying IFPUG FPA. In this category we find an IFPUG proposal for OO systems [18], and proposals by Lehne [28], Fetcke [15], and Uemura et al. [45]. Lehne [28] presents an experience report in function points counting for object oriented analysis and design using a method called OOram. Fetcke [15] demonstrates the applicability of FPA as a FSM method for the OO-Jacobson method [22]. Uemura et al. [45] propose FPA measurement rules for design specifications based on UML (Unified Modeling Language) [11] and demonstrate a function point measurement tool, whose input products are design specifications developed using the Rational Rose CASE tool. Other FSM methods are not compliant to IFPUG FPA, but take a view on functional size that is related to the IFPUG FPA view. For these methods, the underlying model of the items that are considered to contribute to functional size is a data-oriented abstraction similar to that of IFPUG FPA. The count that is obtained would, however, not be considered a valid count according to the IFPUG FPA rules. In this category we find the proposals of Whitmire [47], [48] ASMA [9], and Antoniol and Calzolari [8]. Apart from these two categories, there is a third category of methods that take a fundamentally different view on functional size by no longer distinguishing between data

and transactions, but considering the object (actually the class definition of an object) as the main item that contributes to functional size. In this category are the proposals of Laranjeira [27], Rains [40], Zhao and Stockman [49], Sneed [42], Gupta and Gupta [16], and Minkiewicz [30]. OOmFP is a first-category FSM method, since it is compliant to the IFPUG FPA rules and consistent with the IFPUG view on functional system size. It was designed to improve upon IFPUG FPA for the function point counting of OO systems that are developed using the OO-Method approach [36], taking into account its specific modeling constructs in the four complementary conceptual model views. The quoted OO-Method approach provides a method to go from the conceptual schema to the corresponding software product in an automated way, through a process of conceptual model compilation. In accordance with that, a main contribution of this work is to provide a concrete method for evaluating the functional size of a conceptual schema that is going to become a kind of high-level source program. Anyway, the work presented here is not entirely specific to OO-Method. It can be applied to any OO-based model that provides the basic OO conceptual modeling primitives. It also differs from the related work in the sense that we define and evaluate a new FSM method using a systematic approach. This approach is based on a process model for software measurement, which we present and discuss in the next section. The goal of this paper is therefore not only to present ‘yet another method’, but also how a new FSM method can be systematically designed and evaluated using a generic framework.

3

A Process Model for Software Measurement

Jacquet and Abran [4] [23], in their work as ISO editors for the Guide to the Verification of FSM methods (ISO 14143-3) [21] suggest a process model for software measurement (see Figure 1). Step 2

Step 1 Design of the measurement method

Application of the measurement method rules

Step 3 Analysis of the measurement result

Step 4 Exploitation of the measurement result

Figure 1. Measurement Process Steps (Source: Jacquet and Abran [23])

In the first step, a measurement method is designed. In this step, the concept to be measured is defined and the rules to measure it are conceived. In addition, all tasks associated with a method’s measurement procedure are described. In the second step, the measurement method is applied to measure the size of software applications. In this step it is necessary to evaluate questions such as “Which level of knowledge is required in order to be able to apply the rules of the measurement method?”, “Can the data storage and the measurement rules application be automated?”. In the third step, the results provided by the measurement method are presented and verified (i.e. “Is the value that is produced the result of a correct application and interpretation of the measurement rules?”). Finally, in the fourth step the results are exploited. In this step the results of functional size measurement are used in different types of models (e.g., productivity analysis models, effort estimation models, schedule estimation models, budgeting models). Only the first three steps of the measurement process are within the scope of this paper. Figure 2 shows the substeps of the software measurement process model related to these steps. Step 1 Design of the Measurement Method

Definition of the numerical assignment rules

Step 3 Measurement Result

Software documentation gathering

Definition of the objectives

Characterization of the concept to be measured

Step 2 Measurement Method Application

Selection of the metamodel

Construction of the software model

Application of the numerical assignment rules

Analysis of the measurement result

Figure 2. Measurement Process – Detailed Model (Source: Jacquet and Abran [23])

4

Design of the Measurement Method

Within step 1 of the process model described in Figure 2, four steps were suggested for a complete design of the measurement method: definition of the objectives, design or selection of a metamodel, the characterization of the concept to be measured, and finally, the definition of the numerical assignment rules. The use of these steps in the development of OOmFP is presented in the following subsections.

4.1 Definition of the Objectives In terms of the Goal/Question/Metric (GQM) template for goal-oriented software measurement [10], the goal pursued in this work is: define and evaluate a functional size measurement method for the purpose of measuring object-oriented software systems with respect to their functional size from the point of view of the researcher. The context concerns a requirements specification of an object oriented system.

4.2 Characterisation of the Concept to be Measured The entity to be measured consists of an OO-Method conceptual schema. The attribute to be measured is functional size, defined by ISO/IEC 14143-1 [20] as “a size of the software derived by quantifying the Functional User Requirements”. The Functional User Requirements represent a subset of user requirements focusing on what the software must do to fulfill the user's needs, without considering how this will be accomplished. They exclude any non-functional or technical requirements.

4.3 Selection of the Metamodel A metamodel can be defined as the set of concepts used to represent software or a piece of software and its relationships. The metamodel of a FSM method provides a precise basis to design the measurement rules that identify and measure these concepts. A metamodel of a FSM method therefore reflects the particular view on functional size taken by the FSM method. The elements in the abstract model of a software application that is obtained through the instantiation of the metamodel are mapped by the measurement rules into numbers. These numbers represent the (relative) amount of functionality that these

elements contribute to the functional size of the system. Finally these numbers are aggregated into an overall functional size value for the system. As OOmFP was designed to conform to the IFPUG FPA counting rules [17], it assumes in essence the same metamodel as IFPUG FPA. Therefore, we first discuss the IFPUG FPA metamodel and next we present a set of rules to map the concepts of this metamodel onto the concepts used in the OO-Method conceptual schemas. 4.3.1

IFPUG FPA Metamodel

As described in Figure 3, IFPUG FPA’s view on functional size is that a software system consists of logical data files (internal logical files and external interface files indicated respectively by ‘ILF’ and ‘EIF’) and functions (external input functions, external output functions and external inquiry functions indicated respectively by ‘EI’, ‘EO’ and ‘EQ’) that perform transactions using or altering the data in the logical data files. The amount and complexity of the data (types) ‘handled’ by a logical data file or transactional function determines the amount of functionality that this piece of software delivers, hence its functional size. The boundary separates the software system being measured from its environment. Within this environment are the users of the system, which may include other systems. Also systems that are used by the system within the scope of measurement are identified. User External Inquiries (EQs)

External Inputs (EIs)

User

External Outputs (EOs)

System being Measured ILFs

EQs EIs / EOs

Other Systems

EIFs

Boundary

Figure 3. IFPUG FPA view on functional size

Figure 4 shows the IFPUG FPA metamodel. It illustrates the information we need to capture for representing a software system (called 'project' in IFPUG FPA terminology) that will be measured. Measuring a Project includes the following activities: determination of

the type of count (new project, enhanced project or running application), and identification of the counting scope and application boundary, identification and classification of data and transactional functions (FunctionType). With respect to the type of count, the development project function point count measures the functions of a new software application that will be provided to the users, upon completion of the project. The enhancement project function point count measures the modifications to an existing application that add, change, or delete user functions. Finally, the application function point count measures an installed application. The boundary indicates the border between the project or application being measured and the external applications or user domain. It must be drawn according to the user’s point of view. Once the border has been established, data and transactional functions can be identified. Data functions (DataFunction) can be data internally maintained by the system (ILFs) or referenced in other systems (EIFs). Transactional functions (TransactionalFunction) are processes of user interaction with the system. There are three kinds of transactional functions: the user enters data into the system (EIs), the system presents data to the user (EOs), and an input requests an immediate response from the system (EQs). Project Boundary description

1 has

name description 1 type

is composed of

1 FunctionType name

1 type={new, enhanced, application}

is composed of

0..*

0..*

TransactionalFunction

type=EI

EI

type=EO

DataFunction

type=EQ

EO

EQ

type=ILF

ILF

Figure 4. IFPUG FPA Metamodel – first level

type=EIF

EIF

4.3.2

Mapping Between Concepts

As our objective is to measure OO-Method conceptual schemas, we need to define a mapping between the concepts used in the IFPUG FPA metamodel and the conceptual primitives of OO-Method. This mapping of concepts is an extension of IFPUG FPA that is included in OOmFP. As OOmFP is a FSM method for object-oriented systems, mapping rules must be defined for the different perspectives of an OO system. These perspectives, along with their corresponding OO-Method conceptual model views, are: •

Data: the information that is maintained by the system. This information is defined in the Object Model.

•

Process: the computations that a system performs as defined in the Object Model with a precise definition of the semantics associated to state changes in the Functional Model.

•

Behaviour: the dynamic interactions of a system in terms of valid object lives and inter-object interaction, defined in the Dynamic Model.

•

Presentation: the user interactions with the system, defined in the Presentation Model.

The measurement scope defines the functionality which will be included in a particular measurement. The system boundary indicates the border between the project being measured and the external systems and user domain. In OO-Method, the system boundary is an imaginary line in the Object Model that can be identified applying the following rules: •

Accept each Agent as a user of the system.

•

Accept each Legacy View as an external application.

Agent relationships are used to state that objects of a class (acting as client) are allowed to activate services in other classes (acting as server). Legacy views are used to represent external functionality (pre-existing software systems) that is used by the system being specified. As in IFPUG-FPA, we take into consideration data and transactional functions. The main idea used to establish the mapping of concepts is to consider classes as internal logical files (ILF) and legacy views as external interface files (EIFs). The services defined in a class

or legacy view can be classified as external inputs (EIs). Finally, the presentation patterns3 defined in the Presentation Model for visualizing the object society of a class can be considered as or external outputs (EOs) or external inquiries (EQs). Crucial to the mapping is that IFPUG FPA takes the perspective of the end user and therefore only the functions that are visible to the end users contribute to the functional size. This is expressed in OO-Method through the definition of agent relationships. Only the functions that have at least one associated agent to interact with the class or legacy view via a service or presentation pattern are considered when applying the mapping rules of Table 1. Table 1. Mapping the IFPUG FPA concepts to OO-Method primitives Function IFPUG FPA ILF It is a user identifiable group of data or control information maintained within the boundary of the system. EIF It is logical groups of data referenced by the system being measured but maintained by other system. Processes data that enters from outside the EI boundary of the system. Its intent is to maintain one or more ILFs or to alter the behavior of the system through its processing logic. Present information to a user through EO processing logic that must contain at least one calculation, creates derived data, or alters the behaviour of the system. The data exits the boundary of the system. EQ

Retrieval data to send outside the system boundary. The intent is to present information to a user retrieving data from ILFs or EIFs. The processing logic contains no calculations and creates no derived data.

OO-Method It is a class that encapsulates a set of data items (attributes) representing the state of the objects in each class. It is a legacy view that is defined as a filter placed on a class by a preexisting software system. It is a service defined in a class or legacy view since a service always changes the state of the class (altering the behaviour of the system). It is an Instance Interaction Unit, Population Interaction Unit and Masterdetail Interaction Unit defined in the Presentation Model [31]. The intent is to present information to the user. The pattern must perform some calculations, or use some derived attribute. It is an Instance Interaction Unit, Population Interaction Unit and Masterdetail Interaction Unit defined in the Presentation Model [31]. The intent is to present information to the user without altering the system behaviour.

4.4 Definition of the Numerical Assignment Rules In this substep, the measurement rules that result in the assignment of a numerical value to the functional size of an OO-Method conceptual schema are defined. The mapping of the software system onto a number representing its functional size is accomplished by weighting the transactional and data functions according to their complexity. 3

The presentation patterns are: Instance Interaction Unit (IIU), Population Interaction Unit (PIU) and Master-detail Interaction Unit (MDIU) [25]. They describe different kinds of user interaction with the system where data generated within the system is presented to the user.

Figure 5 shows the detailed view of the IFPUG-FPA metamodel including the concepts used for weighting functions. The complexity of a transactional function is a function of the number of Data Element Types (DET_Transaction) and the number of File Types Referenced (FTR). A FTR is a data function referenced during the execution of a transactional function. Project name description type /ILFs_quantity Boundary /EIFs_quantity description 1 has 1 /EIs_quantity /EOs_quantity /EQs_quantity /functionalSize

type={new, enhanced, application} comp_level={low, average, high}

is composed of 1

FunctionType name comp_level weight

1 is composed of

DET name 0..*

0..*

TransactionalFunction name DET_Transaction has /DETs_quantity 1 1..* /FTRs_quantity

DataFunction has

DET_Data

1..*

name /DETs_quantity 1 /RETs_quantity

has 1

1..*

RET name

1..* has type=EI

EI

type=EO

EO

type=EQ

EQ

type=ILF

0..*

FTR

ILF

type=EIF

EIF

Figure 5. IFPUG FPA Metamodel – second level

The complexity of a data function is a function of the number of Data Element Type (DET_Data) and the number of Record Element Types (RET). A DET is a unique, user recognizable, non-repeated field. For instance, an account number that is stored in multiple fields is counted as one DET. A RET is a user recognizable subgroup of data elements within a logical file (ILF or EIF). For instance, in a Human Resources Application, information for an employee is added by entering some general information. In addition to the general information, the employee is a salaried or hourly paid employee. Then, two RETs are identified: salaried employee and hourly paid employee. The IFPUG [17] provides several tables to determine the complexity levels of each function type. In general, the more DETs and FTRs are identified for transactional functions, and the more DETs and RETs are identified for logical data files, the higher their

complexity. For instance, an ILF with one RET and until nineteen DETs is classified as having a low complexity. An important constraint that arises from the analysis of the metamodel shown in Figure 5 is that only the candidate functions that have at least one DET are considered. Accordingly, the following mapping rule is added: •

Reject candidate functions that have no DET.

Next, a weight (value) is assigned to each function depending on its type and complexity level. Table 2 summarizes the weights provided in the IFPUG-FPA counting manual [17] . For instance, the weight assigned to an ILF having low complexity is 7. Finally, the values are summed to produce the functional size of the project in unadjusted function points. Table 2. Complexity weights Function types ILF EIF

EI EO EQ

Low 7 5 3 4 3

Average 10 7 4 5 4

High 15 10 6 7 6

Therefore, given a conceptual schema produced during the OO-Method conceptual modeling step, OOmFP is calculated as follows: OOmFP

= OOmFP

Data

+ OOmFP

Transactio n

Where:

OOmFPData =

n

∑ OOmFP

classi

i =1

m

+ ∑ OOmFPlegacy view j j =1

n

m

i =1

j =1

OOmFPTransactio n = ∑ OOmFP service i + ∑ OOmFP IIU j / PIU j / MDIU j The additional information represented in the detailed view of the metamodel is captured by applying the measurement rules of OOmFP. Next, we introduce the proposed measurement rules for each OO-Method conceptual model view. 4.4.1

Measurement Rules for the Object Model

As in IFPUG FPA the complexity of a class (i.e. ILF) or legacy view (i.e. EIF) is determined by counting the number of Data Element Types (DET) and Record Element

Types (RET). Table 3 describes the measurement rules proposed to identify the DETs and RETs for a class. According to Table 3, DETs correspond to attributes in the object classes and RETs correspond to object classes. Data-valued attributes represent simple attributes such as integers and strings. Table 3. Measurement Rules for the Complexity of a Class Data Element Type (DET) Record Element Type (RET) 1 DET for each data-valued attribute 1 RET for the class of the class 4 1 DET for each attribute in the IF of 1 RET for each multivalued a class or legacy view referred to by a aggregation relationship (class or legacy view) univalued aggregation relationship 1 DET for each attribute in the IF of the superclasses of a class 5

We consider both aggregations and generalization/specialization relationships as contributing to the complexity of a class. IFPUG suggests counting a DET for each piece of data that exists because the user required a relationship with another ILF or EIF. It is also suggested to identify a RET for each group of data. Aggregations are measured according to the multiplicity property of the relationship. This property specifies the lower/upper number of objects that must/can be associated to a single object of the class. Aggregations in OO-Method allow for bidirectional navigation. If the number of target instances in the relationship is one (indicating a univalued aggregation) a DET is identified for each attribute that is part of the IF of the class that is referred to. On the other hand, if the number of target instances in the relationship is greater than one (indicating a multivalued aggregation) a RET is identified. Note that these rules can be applied regardless of the role of the class in the aggregation (i.e. “part” or “whole”). There is no danger of “double counting” required functionality, as the aggregation relationships are bidirectional. OO-Method allows defining aggregations with identification dependency. This means that the identifier of the whole (or part) class is constructed using the identifier of the whole (or part) class. The identification dependency is asymmetric and can be defined in the whole 4

The Identification Function (IF) is used to identify a class. A class can have 0, 1 or more IFs that are specified by indicating the attributes that define it. Zero IF indicates a specialization with Identification Dependency, where the subclass uses the IF inherited from the superclass. In this paper, to aid understandability, the attributes that compose the IF of classes or legacy views are depicted with “id_”.

.

5

The concept of aggregation in OO-Method includes the concepts of association and composition provided by UML [10].

or part class. The only constraint is that the multiplicity of the dependent class with respect to the other class must be 1:1. For functional size measurement purposes, an aggregation with identification dependency does not present a special case. The attributes of the IF of the whole/part class were already counted as DETS because of the presence of the univalued aggregation relationship. If the aggregation is inclusive (the part is encapsulated in the whole, that is, the part can only be accessed trough the whole), then both part and whole are considered as one data group. Hence two RETs are identified when rating the complexity of the whole class. From a user point of view, abstract classes are not explicitly differentiated from other classes in OO-Method. Therefore object instances of any of the classes that participate in an inheritance hierarchy can potentially exist. Thus, one ILF for each class involved in the inheritance hierarchy is considered. Specialization relationships are measured in the subclasses by adding DETs for attributes in the IF of their direct superclasses. Figure 6 shows the measurement of a class Employee with a reflexive aggregation relationship. The conceptual model follows the OO-Method notation. We denote a class by a box with the class name in a gray compartment at the top of the box. Applying the measurement rules shown in table 3, the data-valued attributes of the class Employee are counted as DETs and the class itself is considered as a RET. Because the relationship role of "manager" has a multiplicity of 0:1 and the IF is formed by only one attribute (id_employee), one DET is counted. In the same way, because the relationship role of "manages" has a multiplicity of 0:M, one RET is counted. Another DET is identified for the attribute id_rate in the IF of the legacy view Rate, that is connected through univalued aggregation relationship with Employee. Table 4 describes the measurement rules proposed to measure the complexity of a legacy view. A legacy view can be involved in aggregation relationships with classes. If this occurs, it is necessary to define an identification function in order to identify the objects we need to access in the legacy system. In fact, a legacy view represents a class in another system. Thus, its complexity is measured in the same way as classes. Table 4. Measurement Rules for the Complexity of a Legacy View Data Element Type (DET) Record Element Type (RET) 1 DET for each non-derived attribute of the 1 RET for the legacy view legacy view 1 DET for each attribute in the IF the class 1 RET for each multivalued aggregation related to by a univalued aggregation relationship with a class

Figure 6 shows a measurement example of a legacy view Rate. A legacy view is denoted by a box with the legacy view name in a black compartment at the top of the box. In this example, the employee’s salary is calculated on the basis of the current exchange rate in dollars. This is obtained via the Rate legacy view that converts the currency. By applying the measurement rules shown in table 4, the legacy view's attributes are counted as DETs and the legacy view itself is considered as a RET. Because the relationship with class Employee has a multiplicity of 0:1 and the IF of the Employee class has only one attribute, one DET is counted.

Employee Class Measurement: DETs = 5 3 attributes (id_employee, fullName, salary) + 1 univalued aggregation relationship (role manager) + 1 univalued aggregation relationship with Rate legacy view. RETs = 2 1 due to the class Employee + 1 multivalued aggregation relationship (role manages) Rate Legacy View Measurement: DETs = 3 2 attributes (conversionRate, relationship with class Employee

id_Rate)

+

1

univalued

aggregation

RETs = 1 1 due to the legacy view Rate

Figure 6. Example of Class and Legacy View Measurement

Next, we describe the measurement rules to determine the complexity for each transactional function. This complexity is determined by counting the number of data element types (DETs) and the number of file types referenced (FTRs) during the execution of the function. Table 5 shows the measurement rules for the complexity of a class service. In OOMethod there are two types of services: events and transactions. An event represents an abstraction of a state transition occurring at a given moment in time. A transaction is composed by more than one event. Furthermore, a same service can be included in the

specification of more than one class. These shared services represent a synchronous communication mechanism between the objects involved in the event occurrence. A service is measured once, even if it is inherited by several subclasses, or shared in more than one class. In order to measure a service, consider each data-valued argument as a DET and each object-valued argument (the type is an object) as a FTR. Also, the class in which the service is defined is considered as a FTR. We included two additional rules to be compliant to IFPUG FPA. IFPUG suggests counting one DET for the capability of the system to send a system response message (error, confirmation, control) outside the system boundary. Another suggestion is to count one DET for the ability to specify an action to be taken even if there are multiple methods for invoking the same logical process. In addition, we specify a set of measurement rules for identifying FTRs in a service. These rules are associated with the class signature6 and consist in verifying: whether in some formula (value by default, destroy event, transaction, specialization by condition, specialization by event, integrity constraint) a new class is referenced. If it occurs, one FTR for each new class is counted. Table 5. Measurement Rules for the Complexity of a Class Service Data Element Type (DET) File Type Referenced (FTR) 1 DET for each data-valued argument of 1 FTR for the class the service 1 DET for the capability to send messages 1 FTR for each new7 class referenced in the object-valued argument of the service. 1 DET for the action (Accept/Cancel) of If a value by default is defined, count one FTR the service execution. for new class referenced in the formula.

If the service is a destroy event, count one FTR for each new class accessed in the cascade formula. If the service is a transaction, count one FTR for each class referenced in the transaction formula. If a specialization by condition is defined, count one FTR for each new class accessed in the specialization formula. If a specialization by event is defined (carrier/liberator event), count one FTR for each new class for carrier/liberator.

which

the

event

is

a

If integrity constraints are defined, count one FTR for new class referenced in the formula.

6

There are a set of well-formed formulas associated to the class signature defined according to a formal language called OASIS [30].

In OO-Method, there are two kinds of inheritance hierarchies: permanent or temporal. In the former case, the corresponding condition on constant attributes must characterize the specialization relationship (specialization by condition)8; in the latter, a condition on variable attributes or carrier/liberator events that activates/deactivates a child role for an object of a class must be specified (specialization by event). The checking integrity constraint verifies all the possible states of an object during its life. Figure 7 shows an example of a service measurement. In this example, a Person is specialized in a Student when the carrier event register occurs; and the object leaves this class through the execution of the liberator event finish. A person can be identified using his/her identifier or SSN and a Student using his/her identifier. Signatures for services create_Person and register are shown in the right side of the box. By applying the measurement rules shown in table 5, data-valued (DV) arguments are counted as DETs and the class where the service is defined is considered one FTR. In the carrier event Register, one additional FTR is identified due to the subclass Student. Finally, for each service, two additional DETs (related to the system capability in provide messages and actions) are considered to be compliant with the IFPUG-FPA counting rules. Services Signature: create_Person(dv_id_Person, dv_id_SSN, dv_gender, dv_fullname)

register(ov_thisPerson, dv_id_Student, dv_school) createPerson Event Measurement: DETs = 6 4 DV attributes (dv_id_Person, dv_id_SSN, dv_gender, dv_fullname) + 1 capability to send messages + 1 action to execute the service FTR = 1 1 due to the class Person Register Event Measurement: DETs = 4 2 DV arguments (dv_id_Student, dv_school) + 2 (system capability to send messages + actions) FTRs = 2 1 due to the class Person+ 1 class Student

Figure 7. Example of Service Measurement 7 8

New in this context means that the class was not counted yet. It denotes a permanent specialization. If a specialization condition holds at the moment of creating the object, the object will belong to the superclass and subclass.

Table 6 shows the measurement rules for the complexity of a legacy view service. In a legacy view a service is specified by defining a set of input and output arguments. Also, a precondition or integrity constraints can be specified based on the input arguments. Table 6. Measurement Rules for the Complexity of a Legacy View Service Data Element Type (DET) File Type Referenced (FTR) 1 DET for each data-valued argument of 1 FTR for the legacy view the service 1 DET for the capability to send messages If preconditions are defined, 1 FTR for each new class referenced in the formula of a precondition definition. 1 DET for the action (Accept/Cancel) of If integrity constraints are defined, count one the service execution. FTR for new class referenced in the formula.

In order to measure a legacy view service, consider each data-valued argument as a DET and the legacy view in which the service is defined as a FTR. Two additional DETs are considered to be compliant with the IFPUG-FPA counting rules (related to the system capability in provide messages and actions). Finally, if a precondition or integrity constraint is defined, consider a FTR for each class that are referenced in these formulas. 4.4.2

Measurement Rules for Dynamic and Functional Models

The measurement rules described here are defined taking into account the complementary information for the Object Model, specified in the Dynamic and Functional models. We first introduce these conceptual models views and then the proposed rules for measure them. The Dynamic Model in OO-Method uses a State Transition Diagram (STD) and an Interaction Diagram (ID) to represent object life cycles and interobject communication, respectively. STD is used to describe the appropriate sequence of service occurrences that characterizes the correct behavior of the objects that belong to a specific class. Also, every service occurrence is labeled by the agent that is allowed to activate it. The syntax for transitions is the following: [ list_of_agents | * ] : [preconditions] service_name [ WHEN control_condition ]

where, preconditions are defined as conditions regarding the object attributes. They must comply with the object’s current state before a specific service may be carried out. Control conditions are conditions defined on object attributes to avoid the possible nondeterminism for a given service activation.

The interaction diagram (ID) specifies the interobject communication. Two basic interactions are defined: triggers, which are object services that are activated in an automated way when a condition is satisfied, and global interactions, which are transactions involving services of different objects. Trigger specifications follow the syntax: destination :: (trigger_condition) agent:service

The measurement rules for the Dynamic Model are defined taking into account the formulas associated to the definition of a class. It consists in identifying new FTRs for classes that are referenced in these formulas. The use of these rules can thus result in a higher complexity rating for the services that are identified as external input functions (EIs). The proposed measurement rules for the Dynamic Model are: •

1 FTR for each new class referenced in the formula of a control condition, defined in the state transition diagram.

•

1 FTR for each new class referenced in the formula of a trigger definition, defined in the interaction diagram.

•

1 FTR for each new class referenced in the formula of a precondition definition, defined in the state transition diagram.

In the Functional model, the semantics associated to any change of an object state is captured as a consequence of a service occurrence. To do this, valuations are specified in this model to define a specific event’s effect on the value of an attribute of the class. An attribute can be categorized in the following types: push-pop, state-independent and discrete-domain based. Each type will fix the pattern of information required to define its functionality. Push-pop attributes are those whose relevant services increase, decrease or reset their value. State-independent attributes are those having a value that depends only on the latest service that has occurred. Finally, discrete-domain valued attributes are those that take their values from a limited domain. The object reaches a specific state, where the attribute value can be specified, through the activation of carrier or liberator services. In addition, a control condition can be used to indicate which valuation should be considered when the condition fulfills. The proposed measurement rules for the Functional Model are: •

1 FTR for each new class referenced in the formula of a valuation definition.

•

1 FTR for new class referenced in the formula of a control condition associated to the valuations.

Figure 8 shows an example of a service measurement with a precondition. A precondition is defined in the event finish of the class Student indicating that the object leaves this class through the execution of the liberator event finish only whether the course is closed. State Transition Diagram: : If course.closed=TRUE

Services Signature: finish(ov_thisPerson, dv_id_Student, dv_school)

Event finish Measurement: DETs = 4 2 DV arguments + 2 (system capability to send messages + actions) FTRs = 3 1 due to the class Student + 1 class Person + 1 class Course (precondition)

Figure 8. Example of Event Measurement

4.4.3

Measurement Rules for Presentation Model

Finally, in this subsection the measurement rules for measuring the presentation patterns Instance Interaction Unit (IIU), Population Interaction Unit (PIU), and Master-detail Interaction Unit (MDIU) are presented. Table 7 describes the measurement rules proposed to measure the complexity of an IIU. The aim of this pattern is to define the information that will be presented to the user, the actions that can be performed and the additional information that can be visualized for a class or legacy view. The information to be presented is defined in terms of a display set with attributes of the class/legacy view or from the classes or legacy views that can be reached from this class/legacy view. One DET for each class/legacy view attribute and one FTR for each referenced class/legacy view are counted. The actions that can be supplied for the object constitute its services (by default all class/legacy view services). One DET is counted for each service included in the offered action as the IFPUG counting rules suggest to count one DET for the ability to specify an action for invoking a logical process.

Table 7. Measurement Rules for the Instance Interaction Unit Pattern Data Element Type (DET) 1 DET for each attribute in the display set

File Type Referenced (FTR) 1 FTR for each class or legacy view in the display set

1 DET for each offered action (by default all class or legacy view services) 1 DET for each offered navigation (by default all inheritance/aggregation relationships in which the class or legacy view participates) 1 DET for the system capacity to display messages (error, control, etc.)

The additional information is obtained from navigations performed using the inheritance/aggregation relationships in which the class participates. One DET is counted for each class that can be reached because the IFPUG counting rules suggest to count a

DET for each piece of data required by the user to establish a relationship with another ILF or EIF. Finally, one additional DET is considered for the capacity of displaying messages. An instance interaction unit pattern (IIU) is defined in the Figure 9. This pattern allows us to review the information for a given employee depicted in Figure 6. Presentation Pattern Definition

DETs = 9

Name: IIU_Employee Display Set: id_employee, lastName, salary.

firstName,

Actions: create_instance, delete_instance, calcWage Navigations: IIU_Rate

Presentation Pattern Measurement 4 attributes in the display set + 3 actions + 1 navigation + 1 system capability to present messages FTRs = 1 class Person in the display set

Figure 9. Example of an Instance Interaction Unit Measurement

Table 8 describes the measurement rules proposed to measure the complexity of a Population Interaction Unit (PIU). Its main intention is to present information to the user providing filtering and/or ordering mechanisms that facilitate object selection and observation. A PIU is specified over a class defining: the information that will be presented, the filtering/ordering mechanisms, the actions that can be invoked over objects and additional information (by means of navigations) to facilitate the consultation of related objects. All measurement rules for an IIU are applicable for measuring a PIU. In addition, for each defined filter, one DET for each data-valued variable and one FTR for each object-

valued variable of the filter are counted. Also, one FTR for each new class referenced in the ordering criteria. Table 8. Measurement Rules for the Population Interaction Unit Pattern Data Element Type (DET) 1 DET for each attribute in the display set 1 DET for each data-valued unique variable of a filter 1 DET for each offered action (by default all class/legacy view services) 1 DET for each offered navigation (by default all inheritance/aggregation relationships in which the class or legacy view participates) 1 DET for the system capacity of presenting messages (error, control, etc.)

File Type Referenced (FTR) 1 FTR for each class or legacy view in the display set 1 FTR for each unique object-valued attribute of a filter 1 FTR for each new class referenced in the ordering criteria 1 FTR for each new class referenced in the filter formula

Finally, the intention of a Master-Detail Interaction Unit (MDIU) is to present information using the master/detail logical components. In a pattern of this kind, the information presented in the detail part depends on the selection made in the master part. It is defined on a class and the master part can be an IIU or PIU, and the detail part can be one or more IIU, PIU or MDIU. A MDIU is measured applying the measurement rules described in tables 7 and 8 depending on the presentation patterns used in the definition of the master/detail parts.

5

Measurement Method Application

Figure 10 contains a representation of the procedure that is used to apply OOmFP. This model clarifies the relation between OOmFP, OO-Method, and IFPUG FPA. As shown in the figure, OOmFP is used for the functional size measurement of systems that are modeled with OO-Method. The metamodel and view on functional size measurement is essentially that of IFPUG FPA. The OOmFP mapping rules help identifying the elements in an OO-Method conceptual schema that contribute to the functional size of the system. The OOmFP measurement rules support the IFPUG FPA counting rules in the process of assigning numerical values to the identified elements. For each step in this procedure we also show the equivalent step in the detailed process model proposed by Jacquet and Abran [23] (see step 2 in Figure 2).

Jacquet and Abran’s measurement process model [4], [23]

Software Documentation Gathering

Applying OOmFP

Fetcke’s generalised representation of FSM [14]

User Requirements Specification

OO-Method

OO-Method Conceptual Schema

Identification Step

OOmFP mapping rules (4.3.2)

Construction of the Software Model

IFPUG FPA View on Functional Size

Measurement Abstract Model

OOmFP measurement rules (4.4)

Application of the Numerical Assignment Rules

Measurement Step

IFPUG counting rules

Functional size value (x)

Figure 10. A model of the OOmFP Measurement Procedure

According to the process model of Jacquet and Abran [23] three steps were suggested for an application of the measurement method: software documentation gathering, construction of the software model, and application of the numerical assignment rules. In the software documentation gathering step, an OO-Method conceptual schema is built using the OO-Method approach based on the user requirements specification. This conceptual model includes four complementary conceptual schemas: Object Model, Dynamic Model, Functional Model and Presentation Model.

In the construction of the software model step, we use the OOmFP mapping rules to obtain the IFPUG FPA view on the functional size of the modeled system. This step consists in identifying the elements in the OO-Method conceptual schema that add to the functional size of the system and to abstract from those that do not contribute to functional size. The result of this step is a collection of data and transactional functions, which can be quantified in the next step. Hence, in the application of the numerical assignment rules step, a functional size value (x) is obtained through the application of two sets of rules. First, the OOmFP measurement rules are used to identify the elements that add to the complexity of the identified functions (e.g. DETs, RETs, FTRs). Next the standard IFPUG counting rules are used to rate the complexity of the functions, to assign weights to the functions, and to aggregate the assigned values into an overall functional size value for the system. The OOmFP application procedure is also compared to the generalized representation of functional size measurement of Fetcke et al. [14]. This representation was applied to represent IFPUG-FPA [18] , Mark II FPA [46], and Full Function Points [43]. According to this model, functional size measurement requires two steps of abstraction, called the identification step and the measurement step. The aim of the identification step is to identify the elements in the requirements documentation that add to the functional size of the system.

The result of this first

abstraction activity is an abstract model of the relevant elements for functional size measurement, according to the metamodel of the FSM method that is used. During the measurement step, the elements in the abstract model are mapped into numbers representing the (relative) amount of functionality that is contributed to the functional size of the system. Finally the numbers are aggregated into an overall functional size value. As shown in the figure, OOmFP conforms to the generalized representation of functional size measurement. During the identification step an abstraction of the modeled system is made using the OOmFP mapping rules. This abstraction contains only those elements of the system that are relevant for functional size measurement, according to the IFPUG FPA metamodel. Next, during the measurement step, the OOmFP measurement rules are used as part of the process of assigning numbers to the elements of the abstract model. In the remainder of this section, we illustrate the use of OOmFP with a case-study. To organize the section we use the steps in the left column of Figure 10.

5.1

Software Documentation Gathering

The documentation used to apply OOmFP was a requirements specification document for building a new Project Management System (PMS) for a company, the corresponding OOMethod conceptual model specification as well as a set of guidelines explaining how to apply the method. 5.1.1

User Requirements Specification

The system requirements are described in the format of the IEEE 830 standard [7]. Using this standard a software requirements specification is described in terms of functionality (what is the software supposed to do from the user's perspective), external interfaces (interaction of the software with people, hardware and other software), performance (such as availability, response time, etc.), quality attributes (such as portability, maintainability, security, etc.), and design constraints imposed by implementation (required standards, implementation language, policies for database integrity, operating environments, etc.). The PMS is a new system that replaces the current manual hand drawing processes for project management. The PMS will provide the following major functions: task maintenance (create, change, delete), task type maintenance (create, change, delete), project maintenance (create, change, delete, task assignment), project type maintenance (create, change, delete), department maintenance (create, change, delete), user maintenance (create, change, delete, change password), and inquiries (users, projects and type of tasks, etc.). An example of a functional requirement is: when the company starts a new project the responsible employee of the project must enter the data in the system. A project is created with the following data: identification number, description, name of responsible employee, start date, estimated duration, estimated final date, actual duration (sum of the duration of the tasks made until now), cost (sum of all tasks costs associated to the project), situation (0=developing, 1=little delay, = 10% more than the estimated time, 3=finished), observations. The system should distinguish three kinds of user: employee, responsible and manager. An employee works in a Department. A department in the company can have several projects on which the employees are working. The types of project are: conceptual modelling, implementation and consultancy. Employees must daily register their tasks performed in the projects. These tasks can be classified according to a type of task such as Requirements Engineering, Conceptual Modeling, Testing, etc.

An employee can be promoted to the function of responsible by the manager. A responsible will be able to have three active projects simultaneously, and cannot be removed from his status of responsible while involved in an active project. In general, the responsibilities of the different types of user are: employee (task maintenance), responsible (project maintenance, project type maintenance, task type maintenance, user maintenance) and manager (promote employees, assign responsible to a project, demote responsible, and access to all other functionality in the system). The system should communicate with an external interface that will provide the resources associated to the projects. 5.1.1

OO-Method Conceptual Schema

Figure 11 shows the Object Model for the PMS system. The dashed lines are agent relationships that indicate the client/server behavior of the classes and legacy views.

Figure 11. Object Model for the PMS system

Figure 12 shows a simple STD for the employee class. Every service occurrence (i.e. create_instance()) is labeled by the agents that are allowed to activate it. In this example, the * denotes that any valid agent class can activate the transition. As the only valid agents for create_instance(), promote() and delete_instance() are objects of the classes Responsible and Manager, both representations are equivalent.

Figure 12. State Transaction Diagram for class Employee

Table 9 shows an example of a valuation for the attribute start_date of the class Responsible. This indicates that the attribute start_date is initialized when the event promote occurs. The initialization is made using the predefined function today(). The attribute category is state-independent since it value depends on the latest service that has occurred. Table 9. Functional Model Example – Class: Responsible, Attribute: start_date, Category: StateIndependent Action promote

Effect today()

Figure 13 shows an example of Population Interaction Unit (PIU_project_tasks) for the class Project. The purpose of this pattern is to present information about one project and all tasks associated with. The definition of this pattern includes the following information: Presentation Pattern Definition Name: PIU_project_tasks Display Set: descr_project, descry_projType, descry_task, begin_date. Filters: by project description and type of project. Ordering Criteria: ascendant (ASC) Actions: create_instance, delete_instance, edit_instance, insTask, insResource. Navigations: IIU_Task, IIU_Resource

Figure 13. Example of a Population Interaction Unit

5.2

Construction of the Software Model

The software model for the PMS system is built by applying the OOmFP mapping rules described in section 4.3.2. The measurement scope includes all the information specified in the four OO-Method conceptual schema views. The system boundary is delineated by identifying the users and external systems that interact with it. The users of the PMS system are indicated by the classes Employee, Responsible and Manager since they are client classes. However, as these classes are also information that will be maintained by the system being build, they are included as part of functionality of the system. The legacy view Resource is an external application that interacts with the PMS system. As previously explained, logical data files can be internal (ILFs) or external (EIFs) depending on whether they reside inside or outside the system boundary, respectively. For the PMS system we therefore identify the following candidate data functions: •

ILFs: Project, ProjectType, Task, TaskType, Department, Employee, Responsible, and Manager.

•

EIF: Resource

Table 10 shows the client and server classes in the agent relationships declared in the Object Model for the PMS system. Table 10. EIs identification Client Class Employee Responsible

Server Class Task Employee Employee Task TaskType Project Department

Manager

TaskType Task ProjectType Project Department Resource Employee Responsible

Services TCREATE, modify_intance, delete_instance, InsTask* modify_password* create_instance, modify_intance, modify_password TCREATE, modify_intance, delete_instance create_instance, modify_instance, delete_instance create_instance, modify_instance, InsDepartment*, DelDepartment*, InsTask, DELETEALL create_instance, delete_instance, modify_instance, InsEmployee*, DelResponsible* create_instance, modify_intance, delete_instance TCREATE, modify_intance, delete_instance create_instance, modify_intance, delete_instance InsDepartment*, DelDepartment*, DELETEALL create_instance, modify_intance, delete_instance, InsEmployee, InsResponsible*, DelResponsible*, InsDepartment, DelDepartment create_instance, modify_intance, delete_instance create_instance, modify_instance, modify_password , promote, DELETEALL demote, name manager, InsResponsible, DelResponsible

The services that can be activated for the client class are also shown. For each service an external input (EI) is identified. The services in capital letters are transactions. Services depicted with * denote shared events between classes and should be measured once. So, excluding the shared events, we identify thirty-three services. Table 11 shows the presentation patterns (IIU, PIU and MDIU) identified for the PSM system. The patterns IIU_task and IIU_project are classified as external outputs since a calculation is necessary to present the information to the user. With exception of these two patterns all of them are classified as external inquiries. Table 11. EOs and EQs identification Class Task

Type/Name of Pattern IIU_task

TaskType Project

PIU task IIU_taskType IIU_project

PIU_project_tasks PIU_project_resources MDIU_project ProjectType Department

IIU IIU_department MDIU_dep_employee

Resource Employee

IIU_resource MDIU_employee

Responsible

MDIU_responsible

5.3

Description Shows information about a task. When a task is created or modified, the start and end hour is provided and the duration is calculated. Shows information about tasks filtered by date Shows information about type of tasks Shows information about a project. When a project is created or modified, its actual duration (sum of the duration of the tasks made until now), and cost (sum of all tasks costs associated with) are calculated. Shows information about a project and all tasks associated with. Shows information about a project, its responsible and all resources associated with it. Shows information about projects classified by their type. Shows information about type of projects Shows information about a department Shows information about a department and all employees that work in it. Shows information about a resource Shows information about an employee and all tasks that he/she works on. Shows information about a responsible and all projects that he/she works on.

Application of the Numerical Assignment Rules

Finally, in order to obtain the functional size value for the PMS system we first apply the OOmFP measurement rules and then the IFPUG counting rules.

5.3.2 Application of the OOmFP measurement rules Table 12 shows the DETs and RETs that were counted for each class applying the measurement rules described in table 3. Note that because the Manager class has no attributes is not considered as an ILF. For instance, the class Project has ten DETs (nine due to the data-valued attributes and one due to the univalued aggregation relationship with ProjectType) and four RETs (one due to the project class and two due to the multivalued aggregation relationship with classes Department and Task and one due to the multivalued aggregation relationship with legacy view Resource). Table 12. Classes Measurement Class Project ProjectType TaskType Task Department Employee Responsible

Attributes id_project, descry_project, beginDate, endDate, est_duration, state, situation, type, observation id_projType, descr_projType id_taskType, descr_taskType id_task, descr_task, startHour, endHour, Date id_department, desc_department Id_employee, fullname, password, emplType start_date

DETs 10

RETs 4

2 2 7 3 5 1

2 2 1 3 2 2

Table 13 shows the DETs and RETs for the identified legacy view applying the measurement rules described in the table 4. The legacy view Resource has three DETs due to its attributes and two RETs (one due to the resource legacy view and another for the multivalued aggregation relationship with class Project). Table 13. Legacy View Measurement Legacy View Resource

Attributes id_Resource, descr_resource, disponibility

DETs 3

RETs 2

Table 14 shows the DETs and FTRs, for an example service. These counts are obtained by applying the measurement rules described in table 5. Services are measured based on their signatures. For instance, the service create_instance() of the class Project has eight DETs (six data-valued arguments, one due to the capability of the system to send messages and one to perform actions) and three FTRs (one for the Project class and two object-valued arguments).

Table 14. Example of Service Measurement Service Signature create_instance(ov_ProjectType, ov_Resource, dv_descr_project, dv_startDate, dv_endDate, dv_duration, dv_type, dv_observation)

DETs 8

FTRs 3

Table 15 shows the DETs and FTRs for the PIU_project_tasks Population Interaction Unit (shown in Figure 13) of the class Project. It is obtained applying the measurement rules described in the table 8. The pattern PIU_project_tasks of the class Project has fourteen DETs (four attributes in the display set, two date-valued filter variables, five offered actions, two offered navigations and one due to the capability of the system to send messages) and 3 FTRs due to three classes referenced in the display set (Project, ProjectType and Task). Table 15. Example of a PIU measurement Pattern Type PIU

Pattern name PIU_project_tasks

DETs 14

FTRs 3

5.3.2 Application of the IFPUG Counting Rules Once the function elements (DETs, RETs and FTRs) have been identified, IFPUG tables [17] are used to classify the data and transactional functions as having low, average or high complexity. With respect to the data functions (classes and legacy views) shown in tables 12 and 13, all of them are found to be in the low complexity category. The service create_instance() of the class Project shown in table 14 has a high complexity. Finally, the presentation pattern PIU_project_tasks shown in table 15 is found to be of average complexity. Then, the functional size is obtained by mapping the function types and complexity ratings into numbers that represents the amount of functionality that these functions contribute to the functional size of the system. The complexity levels are attributed by applying the complexity weights described in table 2. Finally, these numbers are aggregated into an overall functional size value for the OO system. In order to illustrate this process the amount of functionality is first aggregated into values for the data and transactional functions. For the PMS system seven classes (ILFs) having low complexity and one legacy view (EIF) having low complexity are identified.

Applying the weights described in the table 2 the obtained functional size for data functions is: OOmFPD = 49 + 5 OOmFPD = 54

The detailed measurement for all transactional functions of the PSM system is out of the scope of this paper, however, we have identified nineteen services (EIs) having low complexity, eight services having average complexity, and six services having high complexity. In addition, two presentation patterns that represent EOs (one having low complexity and another having high complexity) have been identified. Also, eleven presentation patterns that represent EQs (five having low complexity, five having average complexity, and one having high complexity) were identified. By applying the weights described in the table 2 the obtained functional size for data functions is: OOmFP T = 125 + 11 + 41 OOmFP T = 177

Finally, the partial functional sizes obtained for data and transactional functions are summed to obtain the functional size value of the system. Thus, the functional size obtained for the PMS system is 231.

6

Evaluation Issues

In software measurement, three types of validation are distinguished [24]: validation of the design of a measurement method, validation of the application of a measurement method, and validation of the use of the measurement results. In this section we analyse these types of validation and discuss their role in the evaluation of OOmFP. We present our evaluation strategy, the evaluation results obtained so far, as well as the planned work.

6.1 Validation of the Design of OOmFP The first type of validation relates to the output of the first step in the measurement process model of Jacquet and Abran [23] (see Figures 1 and 2). The objective is to demonstrate that the measure that is defined by the measurement method, is measuring the concept it is purporting to measure [13]. As the criteria that are used to verify this assertion are mostly

derived from theory (in particular from Measurement Theory [41]), this type of validation is also known as the theoretical validation of a software measure [26]. In a broader context, theoretical validation is part of the evaluation of the design of the measurement method [24]. Apart from measure validity, the evaluation pertains to issues such as the definition of a measurement unit, the preciseness and correctness of the measurement method rules, the quality of the meta-model, and the soundness of the mathematical operations applied in the measurement rules (e.g. dimensional analysis) [26]. The proper theoretical validation is performed by verifying whether the measure satisfies the representation condition of measurement. Basically this means that the semantics of the measured concept (here functional size) are preserved after the mapping into numbers. It means, for instance, that a new version of the software system that is developed as an enhancement of a previous version, should have a functional size value that is at least as great as that of the previous version. In general, Measurement Theory offers guidance (in the form of measurement structures and theorems) on how to check measure validity. Research on the theoretical validation of functional size measurement methods was reported in the literature by Fetcke [14], Zuse [50] and Poels [37]. As OOmFP is designed to conform to IFPUG FPA, its theoretical validity is determined by that of the function point measure. A number of studies identified serious drawbacks with the underlying structure of Function Point Analysis with respect to the prescriptions of Measurement Theory [5], [38] [26]. Abran and Robillard [5] have investigated the measurement scales used in the process of counting FPA. They observe that functional size measurement is started with absolute scales, to transform these into ordinal scales (losing information in this process). This is in agreement with the findings of Poels [38] who notes that many of the scale transformations within the FPA process are not allowed according to Measurement Theory. Also, Kitchenham et al. [26] confirm these findings after applying their framework for measurement validation to function points. This evidence suggests that since OOmFP follows the underlying structure of IFPUG-FPA, it inherits all problems related with function points. Hence, from a theoretical point of view, the functional size measure defined by OOmFP cannot be considered a measure according to Measurement Theory. From a pragmatic

standpoint, however, function points can be considered as an indicator of a complex web of system and project factors having a marked impact on important management variables like development cost, maintenance effort, productivity, etc. [38]. They have been successfully applied in a number of application fields and they are considered as a significant improvement over traditional ‘lines-of-code’-based measurements [29]. Nevertheless, these pragmatic considerations relate to step 4 in Jacquet and Abran’s measurement process model (see Figure 1) and are therefore no evidence of the validity of the functional size measure defined by OOmFP (i.e. step 1). As part of a comprehensive evaluation effort for OOmFP we therefore need to address again the issue of theoretical validation and the evaluation of the design of OOmFP in general. In future work we will use a new Measurement Theory-based validation framework, based on Poels and Dedene’s DISTANCE framework [39]. DISTANCE uses advanced Measurement Theoretic constructs that are more suitable than the ones usually used in the process of software measure validation. First results of applying DISTANCE to COSMICFFP, another functional size measurement method, are promising (see [37]), though not definitive, and can be used as a starting point to validate OOmFP. Apart from the theoretical validation, we also plan to evaluate other issues related to the design of OOmFP (like the definition of a measurement unit).

6.2 Validation of the Application of OOmFP The second type of validation relates to the second and third steps in the measurement process model of Jacquet and Abran [22] (see Figures 1 and 2). Even when the design of the measurement method is validated and the theoretical validity of the measure is proven (step 1), there is no guarantee that the rules of the measurement method will always be applied correctly (step 2). Therefore a verification (or audit) of the measurement result is a recommended activity during the measurement process (as part of step 3). Such a measurement audit (i.e. establishing the degree of quality of the data collection) is referred to as an a posteriori validation by Desharnais and Morris [33]. They distinguish this type of validation from the a priori validation, which aims at reviewing the procedures of the data collection process. Independent of a specific application, evaluating the use of OOmFP in general allows assessing the degree of confidence in the measurement results and verifies whether the method satisfies its intended use and the user needs.

6.2.1

A Theoretical Model for Evaluating FSM Methods

To evaluate the use of OOmFP we applied the Method Evaluation Model (MEM) [32], a theoretical model for evaluating IS design methods (Figure 14). The core of the MEM is the Method Adoption Model (MAM), which is based on the Technology Acceptance Model (TAM) of Davis [12]. The MEM incorporates dual aspects of method “success”: actual efficacy (i.e. does a method achieve its objectives in an efficient manner?) and actual usage (i.e. is the method used in practice?). The constructs of the MEM are: Method Adoption Model Performance

Perceptions

Actual Efficiency

Perceived Ease of Use

Intentions

Intention to Use Actual Effectiveness

Actual Usage

Perceived Usefulness

External (Performance Based) Variables ACT UAL EFFICACY

Behaviour

Internal (Perception Based) Variables PERCEIVED EFFICACY

External Behaviour

ADOPT ION IN PRACT ICE

Figure 14. Method Evaluation Model

•

Actual Efficiency: the effort required to apply a method. This represents an input variable to the Method Adoption Model.

•

Actual Effectiveness: the degree to which a method achieves its objectives. This also represents an input variable to the Method Adoption Model.

•

Perceived Ease of Use: the degree to which a person believes that using a particular method would be free of effort.

•

Perceived Usefulness: the degree to which a person believes that a particular method will achieve its intended objectives.

•

Intention to Use: the extent to which a person intends to use a particular method.

•

Actual Usage: the extent to which a method is used in practice. This represents an output variable from the Method Adoption Model.

To evaluate OOmFP, the constructs of the MEM must be operationalized for use on FSM methods. Efficacy is then defined as the efficiency and effectiveness of a FSM method in measuring the functional size of a system. Evaluation of the efficacy of a FSM method requires measurement of effort required (inputs) and the quality of the measurement results (outputs). 6.2.2

Evaluating OOmFP Through a Controlled Experiment

This theoretical evaluation model was applied in a laboratory experiment at the Valencia University of Technology, using a group of Computer Science students. The students were trained in OO-Method and were introduced to the principles of both IFPUG FPA and OOmFP. They also practiced functional size measurement using these FSM methods. As OOmFP was designed to be both compliant to and improving upon IFPUG FPA, IFPUG FPA was treated as the benchmark FSM method against which OOmFP could be evaluated. The basic idea of the experiment was therefore to assess if and how the functional size measurement of a system is improved if OOmFP is used instead of the (standard) IFPUG FPA method. Students were required to measure a same system using both methods and afterwards their measurements were compared. In terms of the GQM template [10] the goal pursued in the experiment was to analyze functional size measurements for the purpose of evaluating OOmFP and IFPUG FPA with respect to their efficacy and likely adoption in practice from the point of view of the researcher. The context of the experiment is the OO-Method approach to the conceptual modeling and development of object oriented systems as performed by students in the Department of Computer Science at the Valencia University of Technology. The broad research questions addressed by the experiment were: 1) Research Question 1: is the actual efficacy of OOmFP in measuring the functional size of OO systems higher than that of IFPUG FPA? a) Efficiency: how efficient is OOmFP compared to IFPUG FPA for sizing objectoriented systems based on requirements specifications. b) Effectiveness: how effective is OOmFP compared to IFPUG FPA for sizing object-oriented

systems

based

on

requirements

specifications?

Effectiveness is measured using the following criteria defined in ISO/IEC 14143-3 [21]:

i)

Reproducibility: does OOmFP produce more consistent measurements of functional size when used by different people than IFPUG FPA?

ii) Accuracy: does OOmFP produce more accurate measurements of functional size from requirements specifications than IFPUG FPA? 2) Research Question 2: is the perceived efficacy of OOmFP and the intention to use OOmFP higher than with IFPUG FPA? 3) Research Question 3: is OOmFP likely to be adopted in practice? OOmFP and IFPUG FPA were compared using a range of performance-based and perception-based variables, including efficiency (time required to apply the methods, hereafter called measurement time), reproducibility, accuracy, perceived ease of use, perceived usefulness and intention to use. The reliability of the measurements produced by using a FSM method was assessed using a practical statistic similar to that proposed by Kemerer [25]. This statistic is a ratio where the numerator is the difference (in absolute value) between the count produced by a subject and the average count produced by the other subjects for the same system and the denominator is this average count. The accuracy of the measurements was measured by comparing them with a supposedly 'right' functional size measurement that was produced by a Certified Function Point Specialist (CFPS). The perception-based variables (perceived ease of use, perceived usefulness and intention to use) were measured using a post-task survey with 14 closed questions, that was based on similar measurement instruments used with the MEM and TAM models ([32], [12]). Figure 11 summarises the main differences found between OOmFP and IFPUG FPA. The labels on the arrows show the variables on which significant differences were found, while the arrowheads show the direction in which the difference was found (from superior to inferior). Regarding research question 1, OOmFP was less efficient (i.e. more time-consuming) than IFPUG FPA. However, this problem can be solved by providing tool support to automate the measurement process. Actually, OOmFP has now been automated in a tool called Oliva Nova Function Points Counter [44] that obtains automatically the functional size of OO systems from OO-Method conceptual schemas.

H1: Measurement Time (p= 0,0015)

IFPUG FPA

OOmFP H2: Reproducibility ( p= 0,000 ) H3: Accuracy ( p= 0,000) H4: Perceived Ease of Use ( p= 0,016) H5: Perceived Usefulness ( p= 0,000) H6: Intention to Use ( p= 0,000)

Figure 15. Comparison between methods results

The findings are very significant (α < 0,001) in terms of reproducibility, accuracy, perceived usefulness and intention to use, and significant (α < 0,05) in terms of perceived ease of use.9 It should be noted that even if OOmFP is perceived to be more efficacious than IFPUG-FPA this does not indicate that it is likely to be adopted. Hence, the objective of Research Question 3 was to evaluate the likely adoption in practice of OOmFP. The results show that only the hypothesis of perceived ease of use was not confirmed. The statistical significance was found to be very high (α < 0,001) for the perceived usefulness of OOmFP as well as the intention to use this method. Concluding, this experiment directed towards the evaluation of the use of OOmFP, showed that the obtained measurement results were more consistent and accurate than those obtained with IFPUG-FPA. Furthermore, OOmFP is perceived to be a useful FSM method in the context of OO-Method systems development. A complete analysis of these findings can be found in [2].

6.3 Validation of the Models that Use the Measurement Results The third type of validation relates to the fourth step in the measurement process model of Jacquet and Abran [23] (see Figure 1). It assesses the quality (e.g. causality, prediction accuracy) of the descriptive and predictive models (e.g., productivity analysis models, effort estimation models, schedule estimation models, budgeting models) that use the measurement results. This type of validation was extensively discussed in the literature. Some empirical studies investigated the ability of a FSM method to produce a size value that can be used for effort prediction. For instance, Moser et al. [34] present an empirical study using 36 projects 9

Note that the latter result is not supported by the performance-based measurements. So even when OOmFP took on the average more time than IFPUG FPA, the subjects perceived OOmFP to be easier to use. Probably other factors than measurement time impacted the subjects' perceptions.

that demonstrate that the System Meter method, which explicitly takes reuse into account, predicts effort substantially better than a model based on function points. The use of OOmFP measurements in descriptive or predictive models was not the focus of this paper. Currently, we are working on a web repository project to gather information about projects that were developed using the OO-Method approach and measured using OOmFP. Our goal is to build budget and productivity estimation models. As our approach is applied in a model-based code generation environment, effort and schedule estimation models are less relevant as the system is obtained in an automatic way. Another goal of the project is to compare company-specific models with models based on multi-company data. To do so, an industrial data set maintained by the International Software Benchmarking Standards Group (ISBSG) [19] will be used.

7

Conclusions

We have presented a functional size measurement method, called OOmFP, for objectoriented systems based on the information contained in conceptual schemas. This method enables to quantify the functional size of OO systems in an early stage of the development lifecycle. Furthermore, OOmFP is compliant to the IFPUG FPA counting rules, which is the most widely FSM method used in practice and a standard for functional size measurement approved by the ISO. Although OOmFP is designed to be used in conjunction with OOMethod, an OO modeling and development method that allows automatic code generation, many of the modeling primitives in its metamodel can also be found in other object-oriented analysis methods. The design of the method and its application procedure were presented using a generic process model for software measurement proposed by Jacquet and Abran. It was also shown that OOmFP adheres to Fetcke's generalized representation of functional size measurement methods that have a data-oriented metamodel. As a proof of concept, the application of our method was illustrated with a case study. Furthermore, we discussed the different types of evaluation that could be performed to validate OOmFP. A controlled experiment was carried out to evaluate the application of the method. The results show that within the context of an OO-Method development process, the proposed method produces more consistent and accurate assessments and it is more

likely to be accepted in practice than IFPUG FPA. This is an encouraging result as OOmFP was developed to facilitate function point counting of OO systems. OOmFP was adopted and automated by a local company in Spain and is now being applied to several real-world applications. The experience gained has allowed us to put into practice this method and to refine the proposed measurement rules. Future work will take several directions: the investigation of the theoretical validation of OOmFP, the definition of a measurement unit, and the construction of predictive models.

Acknowledgments We would like to thank CARE Technologies for supporting the research project. This work was partly funded by the Spanish National Agency, MCYT Project under grant TIC20013530-C02-01.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Abrahão, S. and Pastor, O., Estimating the Applications Functional Size from Object-Oriented Conceptual Models. in International Function Points Users Group Annual Conference (IFPUG'01), Las Vegas, USA, 2001. Abrahão, S., Poels, G. and Pastor, O. Comparative Evaluation of Functional Size Measurement Methods: An Experimental Analysis, Working Paper, Faculty of Economics and Business Administration, Ghent University, Belgium, 2004, 43 p. Abran, A., Desharnais, J.M., Oligny, S., St.Pierre, D. and Symons, C. COSMIC-FFP Measurement Manual, Version 2.1, The Common Software Measurement International Consortium, May 2001. Abran, A. and Jacquet, J.P., A Structured Analysis of the new ISO Standard on Functional Size Measurement - Definition of Concepts. in 4th IEEE Int. Symposium and Forum on Software Engineering Standards, 1999, 230-241. Abran, A. and Robillard, P.N. Function Points: A Study of Their Measurement Processes and Scale Transformations. Journal of Systems and Software, 25, 1994, 171-184. Albrecht, A.J., Measuring application development productivity. in IBM Application Development Symposium, 1979, 83-92. ANSI/IEEE. Standard 830-1998, IEEE Recommended Practice for Software Requirements Specifications, The Institute of Electrical and Electronics Engineers, Ed., New York, NY: IEEE Computer Society Press, 1998. Antoniol, G. and Calzolari, F., Adapting Function Points to Object Oriented Information Systems. in 10 th Conference on Advanced Information Systems Engineering (CAiSE'98), 1998. ASMA. Sizing in Object-Oriented Environments, Australian Software Metrics Association (ASMA), Victoria, Australia, 1994. Basili, V.R. and Rombach, H.D. The TAME Project: Towards Improvement-Oriented Software Environments. IEEE Transactions on Software Engineering, 14 (6), 1988, 758-773. Booch, G., Rumbaugh, J. and Jacobson, I. The Unified Modeling Language Users Guide. AddisonWesley, 1999. Davis, F.D. Perceived Usefulness, Perceived Ease of Use and User Acceptance of Information Technology. MIS Quarterly, 3 (3), 1989. Fenton, N. Software Metrics: A Rigorous Approach, 1991.

14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.

Fetcke, T., Abran, A. and Dumke, R., A Generalized Representation for Selected Functional Size Measurement Methods. in 11th International Workshop on Software Measurement, Montréal, Canada, 2001, Shaker Verlag, 1-25. Fetcke, T., Abran, A. and Nguyen, T.H., Function point analysis for the OO-Jacobson method: a mapping approach. in FESMA'98, Antwerp, Belgium, 1998, 395-410. Gupta, R. and Gupta, S.K., Object Point Analysis. in IFPUG 1996 Fall Conference, Dallas, Texas, USA, 1996. IFPUG. Function Point Counting Practices Manual, Release 4.1, International Function Point Users Group, Westerville, Ohio, USA, 1999. IFPUG. Function Point Counting Practices: Case Study 3 - Object-Oriented Analysis, Object Oriented Design (Draft), 1995. ISBSG. International Software Benchmarking Standards Group, http://www.isbsg.org. ISO. ISO/IEC 14143-1- Information Technology - Software measurement - Functional Size Measurement. Part 1: Definition of Concepts, 1998. ISO. ISO/IEC 14143-3 - Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 2003. Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. Object-Oriented Software Engineering: A Use--Case Driven Approach. Addison Wesley Longman, Inc., 1992. Jacquet, J.P. and Abran, A., From Software Metrics to Software Measurement Methods: A Process Model. in 3rd Int. Standard Symposium and Forum on Software Engineering Standards (ISESS'97), Walnut Creek, USA, 1997. Jacquet, J.P. and Abran, A., Metrics Validation Proposals: A Structured Analysis. in 8th International Workshop on Software Measurement, Magdeburg, Germany, 1998. Kemerer, C.F. Reliability of Function Points Measurement. Communications of the ACM, 36 (2), 1993, 85-97. Kitchenham, B., Pfleeger, S. and Fenton, N. Towards a Framework for Software Measurement Validation. IEEE Transactions on Software Engineering, 21, 1995, 929-943. Laranjeira, L. Software Size Estimation of Object-Oriented Systems. IEEE Transactions on Software Engineering, 16 (5), 1990, 510-522. Lehne, O.A., Experience Report: Function Points Counting of Object Oriented Analysis and Design based on the OOram method. in Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'97), 1997. Matson, J.E., Barret, B.E. and Mellichamp, J.M. Software Development Cost Estimation Using Function Points. IEEE Transactions on Software Engineering, 20 (4), 1994, 275-287. Minkiewicz, F. Measuring Object Oriented Software with Predictive Object Points. in Rob Kusters, A.C., Fred Heemstra and Erik van Veenendaal ed. Project Control for Software Quality, Shaker Publishing, 1999. Molina, P.J. User Interface Specification: From Requirements to Code Generation, PhD. Thesis Departament of Information Systems and Computation, Valencia University of Technology, 2003. Moody, D.L. Dealing with Complexity: A Practical Method for Representing Large Entity Relationship Models Department of Information Systems, University of Melbourne, Melbourne, Australia, 2001, 354p. Morris, P. and Desharnais, J.M., Function Point Analysis. Validating the Results. in IFPUG Spring Conference, Atlanta, USA, 1996. Moser, S., Henderson-Sellers, B. and Misic, V.B. Cost Estimation Based on Business Models. Journal of Systems and Software, 49, 1999, 33-42. Pastor, O., Abrahão, S.M., Molina, J.C. and Torres, I., A FPA-like Measure for Object-Oriented Systems from Conceptual Models. in 11th International Workshop on Software Measurement (IWSM'01), Montréal, Canada, 2001, Shaker Verlag, 51-69. Pastor, O., Gómez, J., Insfrán, E. and Pelechano, V. The OO-Method Approach for Information Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems, 26 (7), 2001, 507-534. Poels, G., Definition and Validation of a COSMIC-FFP Functional Size Measure for Object-Oriented Systems. in 7th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2003), Darmstadt, Germany, 2003. Poels, G. Why Function Points Do Not Work: In Search of New Software Measurement Strategies. Guide Share Europe Journal, 1 (2), 1996, 9-26. Poels, G. and Dedene, G. Distance-based software measurement: necessary and sufficient properties for software measures. Information and Software Technology, 42, 2000, 35-46. Rains, E. Function Points in an ADA Object-Oriented Design. OOPS Messenger, 2 (4), 1991, 23-25.

41. 42. 43. 44. 45. 46. 47. 48. 49. 50.

Roberts, F.S. Measurement Theory with Applications to Decisionmaking, Ttility, and the Social Sciences. Reading, Mass, Addison-Wesley, 1979. Sneed, H.M., Estimating the Development Costs of Object-Oriented Software. in 7th European Software Control and Metrics Conference, Wilmslow, UK, 1996, 135-152. St.Pierre, D., Maya, M., Abran, A., Desharnais, J.M. and Bourque, P. Full Function Points: Counting Practices Manual., Software Engineering Management Research Laboratory and Software Engineering Laboratory in Applied Metrics, 1997. Torres, I. and Calatrava, F. Function Points Counting on Conceptual Models, Whitepaper, CARE Technologies, http://www.care-t.com/html/whitepapers.html, 2003. Uemura, T., Kusumoto, S. and Inoue, K., Function Point Measurement Tool for UML Design Specification. in 5th International Software Metrics Symposium (METRICS'99), Florida, USA, 1999, 62-69. UKSMA. MK II Function Point Analysis Counting Practices Manual, Version 1.3.1, United Kingdom Software Metrics Association, September 1998. Whitmire, S.A., 3D Function Points: Specific and Real-Time Extensions of Function Points. in Pacific Northwest Software Quality Conferene, 1992. Whitmire, S.A. Applying Function Points to Object-Oriented Software Models. in Keyes, J. ed. Software Engineering Productivity Handbook, McGraw-Hill, 1992, 229-244. Zhao, H. and Stockman, T., Software Sizing for OO software development - Object Function Point Analysis. in GSE Conference, Berlin, Germany, 1995. Zuse, H. A Framework for Software Measurement. Walter de Gruyter, Berlin, Germany, 1998.

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE HOVENIERSBERG 24 9000 GENT

Tel. Fax.

: 32 - (0)9 – 264.34.61 : 32 - (0)9 – 264.35.92

WORKING PAPER SERIES

9

02/159 M. VANHOUCKE, Optimal due date assignment in project scheduling, December 2002, 18 p. 02/160 J. ANNAERT, M.J.K. DE CEUSTER, W. VANHYFTE, The Value of Asset Allocation Advice. Evidence from the Economist’s Quarterly Portfolio Poll, December 2002, 35p. (revised version forthcoming in Journal of Banking and Finance, 2004) 02/161 M. GEUENS, P. DE PELSMACKER, Developing a Short Affect Intensity Scale, December 2002, 20 p. (published in Psychological Reports, 2002). 02/162 P. DE PELSMACKER, M. GEUENS, P. ANCKAERT, Media context and advertising effectiveness: The role of context appreciation and context-ad similarity, December 2002, 23 p. (published in Journal of Advertising, 2002). 03/163 M. GEUENS, D. VANTOMME, G. GOESSAERT, B. WEIJTERS, Assessing the impact of offline URL advertising, January 2003, 20 p. 03/164 D. VAN DEN POEL, B. LARIVIÈRE, Customer Attrition Analysis For Financial Services Using Proportional Hazard Models, January 2003, 39 p. (forthcoming in European Journal of Operational Research, 2003) 03/165 P. DE PELSMACKER, L. DRIESEN, G. RAYP, Are fair trade labels good business ? Ethics and coffee buying intentions, January 2003, 20 p. 03/166 D. VANDAELE, P. GEMMEL, Service Level Agreements – Een literatuuroverzicht, Januari 2003, 31 p. (published in Tijdschrift voor Economie en Management, 2003). 03/167 P. VAN KENHOVE, K. DE WULF AND S. STEENHAUT, The relationship between consumers’ unethical behavior and customer loyalty in a retail environment, February 2003, 27 p. (published in Journal of Business Ethics, 2003). 03/168

P. VAN KENHOVE, K. DE WULF, D. VAN DEN POEL, Does attitudinal commitment to stores always lead to behavioural loyalty? The moderating effect of age, February 2003, 20 p.

03/169 E. VERHOFSTADT, E. OMEY, The impact of education on job satisfaction in the first job, March 2003, 16 p. 03/170 S. DOBBELAERE, Ownership, Firm Size and Rent Sharing in a Transition Country, March 2003, 26 p. (forthcoming in Labour Economics, 2004) 03/171 S. DOBBELAERE, Joint Estimation of Price-Cost Margins and Union Bargaining Power for Belgian Manufacturing, March 2003, 29 p. 03/172 M. DUMONT, G. RAYP, P. WILLEMÉ, O. THAS, Correcting Standard Errors in Two-Stage Estimation Procedures with Generated Regressands, April 2003, 12 p. 03/173 L. POZZI, Imperfect information and the excess sensitivity of private consumption to government expenditures, April 2003, 25 p. 03/174 F. HEYLEN, A. SCHOLLAERT, G. EVERAERT, L. POZZI, Inflation and human capital formation: theory and panel data evidence, April 2003, 24 p. 03/175 N.A. DENTCHEV, A. HEENE, Reputation management: Sending the right signal to the right stakeholder, April 2003, 26 p. 03/176 A. WILLEM, M. BUELENS, Making competencies cross business unit boundaries: the interplay between inter-unit coordination, trust and knowledge transferability, April 2003, 37 p. 03/177 K. SCHOORS, K. SONIN, Passive creditors, May 2003, 33 p. 03/178 W. BUCKINX, D. VAN DEN POEL, Customer Base Analysis: Partial Defection of Behaviorally-Loyal Clients in a Non-Contractual FMCG Retail Setting, May 2003, 26 p. (forthcoming in European Journal of Operational Research)

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE HOVENIERSBERG 24 9000 GENT

Tel. Fax.

: 32 - (0)9 – 264.34.61 : 32 - (0)9 – 264.35.92

WORKING PAPER SERIES

10

03/179 H. OOGHE, T. DE LANGHE, J. CAMERLYNCK, Profile of multiple versus single acquirers and their targets : a research note, June 2003, 15 p. 03/180 M. NEYT, J. ALBRECHT, B. CLARYSSE, V. COCQUYT, The Cost-Effectiveness of Herceptin® in a Standard Cost Model for Breast-Cancer Treatment in a Belgian University Hospital, June 2003, 20 p. 03/181 M. VANHOUCKE, New computational results for the discrete time/cost trade-off problem with time-switch constraints, June 2003, 24 p. 03/182 C. SCHLUTER, D. VAN DE GAER, Mobility as distributional difference, June 2003, 22 p. 03/183 B. MERLEVEDE, Reform Reversals and Output Growth in Transition Economies, June 2003, 35 p. (published in Economics of Transition, 2003) 03/184 G. POELS, Functional Size Measurement of Multi-Layer Object-Oriented Conceptual Models, June 2003, 13 p. (published as ‘Object-oriented information systems’ in Lecture Notes in Computer Science, 2003) 03/185 A. VEREECKE, M. STEVENS, E. PANDELAERE, D. DESCHOOLMEESTER, A classification of programmes and its managerial impact, June 2003, 11 p. (forthcoming in International Journal of Operations and Production Management, 2003) 03/186 S. STEENHAUT, P. VANKENHOVE, Consumers’ Reactions to “Receiving Too Much Change at the Checkout”, July 2003, 28 p. 03/187 H. OOGHE, N. WAEYAERT, Oorzaken van faling en falingspaden: Literatuuroverzicht en conceptueel verklaringsmodel, July 2003, 35 p. 03/188 S. SCHILLER, I. DE BEELDE, Disclosure of improvement activities related to tangible assets, August 2003, 21 p. 03/189 L. BAELE, Volatility Spillover Effects in European Equity Markets, August 2003, 73 p. 03/190 A. SCHOLLAERT, D. VAN DE GAER, Trust, Primary Commodity Dependence and Segregation, August 2003, 18 p 03/191 D. VAN DEN POEL, Predicting Mail-Order Repeat Buying: Which Variables Matter?, August 2003, 25 p. (published in Tijdschrift voor Economie en Management, 2003) 03/192 T. VERBEKE, M. DE CLERCQ, The income-environment relationship: Does a logit model offer an alternative empirical strategy?, September 2003, 32 p. 03/193 S. HERMANNS, H. OOGHE, E. VAN LAERE, C. VAN WYMEERSCH, Het type controleverslag: resultaten van een empirisch onderzoek in België, September 2003, 18 p. 03/194 A. DE VOS, D. BUYENS, R. SCHALK, Psychological Contract Development during Organizational Socialization: Adaptation to Reality and the Role of Reciprocity, September 2003, 42 p. (published in Journal of Organizational Behavior, 2003). 03/195 W. BUCKINX, D. VAN DEN POEL, Predicting Online Purchasing Behavior, September 2003, 43 p. (forthcoming in European Journal of Operational Research, 2004) 03/196 N.A. DENTCHEV, A. HEENE, Toward stakeholder responsibility and stakeholder motivation: Systemic and holistic perspectives on corporate sustainability, September 2003, 37 p. 03/197 D. HEYMAN, M. DELOOF, H. OOGHE, The Debt-Maturity Structure of Small Firms in a Creditor-Oriented Environment, September 2003, 22 p. 03/198 A. HEIRMAN, B. CLARYSSE, V. VAN DEN HAUTE, How and Why Do Firms Differ at Start-Up? A ResourceBased Configurational Perspective, September 2003, 43 p.

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE HOVENIERSBERG 24 9000 GENT

Tel. Fax.

: 32 - (0)9 – 264.34.61 : 32 - (0)9 – 264.35.92

WORKING PAPER SERIES

11

03/199 M. GENERO, G. POELS, M. PIATTINI, Defining and Validating Metrics for Assessing the Maintainability of EntityRelationship Diagrams, October 2003, 61 p. 03/200 V. DECOENE, W. BRUGGEMAN, Strategic alignment of manufacturing processes in a Balanced Scorecard-based compensation plan: a theory illustration case, October 2003, 22 p. 03/201 W. BUCKINX, E. MOONS, D. VAN DEN POEL, G. WETS, Customer-Adapted Coupon Targeting Using Feature Selection, November 2003, 31 p. (forthcoming in Expert Systems with Applications). 03/202 D. VAN DEN POEL, J. DE SCHAMPHELAERE, G. WETS, Direct and Indirect Effects of Retail Promotions, November 2003, 21 p. (forthcoming in Expert Systems with Applications). 03/203 S. CLAEYS, R. VANDER VENNET, Determinants of bank interest margins in Central and Eastern Europe. Convergence to the West?, November 2003, 28 p. 03/204 M. BRENGMAN, M. GEUENS, The four dimensional impact of color on shoppers’ emotions, December 2003, 15 p. (forthcoming in Advances in Consumer Research, 2004) 03/205 M. BRENGMAN, M. GEUENS, B. WEIJTERS, S.C. SMITH, W.R. SWINYARD, Segmenting Internet shoppers based on their web-usage-related lifestyle: a cross-cultural validation, December 2003, 15 p. (forthcoming in Journal of Business Research, 2004) 03/206 M. GEUENS, D. VANTOMME, M. BRENGMAN, Developing a typology of airport shoppers, December 2003, 13 p. (forthcoming in Tourism Management, 2004) 03/207 J. CHRISTIAENS, C. VANHEE, Capital Assets in Governmental Accounting Reforms, December 2003, 25 p. 03/208 T. VERBEKE, M. DE CLERCQ, Environmental policy uncertainty, policy coordination and relocation decisions, December 2003, 32 p. 03/209 A. DE VOS, D. BUYENS, R. SCHALK, Making Sense of a New Employment Relationship: Psychological ContractRelated Information Seeking and the Role of Work Values and Locus of Control, December 2003, 32 p. 03/210 K. DEWETTINCK, J. SINGH, D. BUYENS, Psychological Empowerment in the Workplace: Reviewing the Empowerment Effects on Critical Work Outcomes, December 2003, 24 p. 03/211 M. DAKHLI, D. DE CLERCQ, Human Capital, Social Capital and Innovation: A Multi-Country Study, November 2003, 32 p. (forthcoming in Entrepreneurship and Regional Development, 2004). 03/212 D. DE CLERCQ, H.J. SAPIENZA, H. CRIJNS, The Internationalization of Small and Medium-Sized Firms: The Role of Organizational Learning Effort and Entrepreneurial Orientation, November 2003, 22 p (forthcoming in Small Business Economics, 2004). 03/213 A. PRINZIE, D. VAN DEN POEL, Investigating Purchasing Patterns for Financial Services using Markov, MTD and MTDg Models, December 2003, 40 p. 03/214 J.-J. JONKER, N. PIERSMA, D. VAN DEN POEL, Joint Optimization of Customer Segmentation and Marketing Policy to Maximize Long-Term Profitability, December 2003, 20 p. 04/215 D. VERHAEST, E. OMEY, The impact of overeducation and its measurement, January 2004, 26 p. 04/216 D. VERHAEST, E. OMEY, What determines measured overeducation?, January 2004, 31 p. 04/217 L. BAELE, R. VANDER VENNET, A. VAN LANDSCHOOT, Bank Risk Strategies and Cyclical Variation in Bank Stock Returns, January 2004, 47 p. 04/218 B. MERLEVEDE, T. VERBEKE, M. DE CLERCQ, The EKC for SO2: does firm size matter?, January 2004, 25 p.

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE HOVENIERSBERG 24 9000 GENT

Tel. Fax.

: 32 - (0)9 – 264.34.61 : 32 - (0)9 – 264.35.92

WORKING PAPER SERIES

12

04/219 G. POELS, A. MAES, F. GAILLY, R. PAEMELEIRE, The Pragmatic Quality of Resources-Events-Agents Diagrams: an Experimental Evaluation, January 2004, 23 p. 04/220 J. CHRISTIAENS, Gemeentelijke financiering van het deeltijds kunstonderwijs in Vlaanderen, Februari 2004, 27 p. 04/221 C.BEUSELINCK, M. DELOOF, S. MANIGART, Venture Capital, Private Equity and Earnings Quality, February 2004, 42 p. 04/222 D. DE CLERCQ, H.J. SAPIENZA, When do venture capital firms learn from their portfolio companies?, February 2004, 26 p. 04/223 B. LARIVIERE, D. VAN DEN POEL, Investigating the role of product features in preventing customer churn, by using survival analysis and choice modeling: The case of financial services, February 2004, 24p. 04/224 D. VANTOMME, M. GEUENS, J. DE HOUWER, P. DE PELSMACKER, Implicit Attitudes Toward Green Consumer Behavior, February 2004, 33 p. 04/225 R. I. LUTTENS, D. VAN DE GAER, Lorenz dominance and non-welfaristic redistribution, February 2004, 23 p. 04/226 S. MANIGART, A. LOCKETT, M. MEULEMAN et al., Why Do Venture Capital Companies Syndicate?, February 2004, 33 p. 04/227 A. DE VOS, D. BUYENS, Information seeking about the psychological contract: The impact on newcomers’ evaluations of their employment relationship, February 2004, 28 p. 04/228 B. CLARYSSE, M. WRIGHT, A. LOCKETT, E. VAN DE VELDE, A. VOHORA, Spinning Out New Ventures: A Typology Of Incubation Strategies From European Research Institutions, February 2004, 54 p. 04/229 S. DE MAN, D. VANDAELE, P. GEMMEL, The waiting experience and consumer perception of service quality in outpatient clinics, February 2004, 32 p. 04/230 N. GOBBIN, G. RAYP, Inequality and Growth: Does Time Change Anything?, February 2004, 32 p. 04/231 G. PEERSMAN, L. POZZI, Determinants of consumption smoothing, February 2004, 24 p. 04/232 G. VERSTRAETEN, D. VAN DEN POEL, The Impact of Sample Bias on Consumer Credit Scoring Performance and Profitability, March 2004, 24 p. 04/233 S. ABRAHAO, G. POELS, O. PASTOR, Functional Size Measurement Method for Object-Oriented Conceptual Schemas: Design and Evaluation Issues, March 2004, 43 p. 04/234 S. ABRAHAO, G. POELS, O. PASTOR, Comparative Evaluation of Functional Size Measurement Methods: An Experimental Analysis, March 2004, 45 p.