PhDThesis SilviaAbrahao

On the Functional Size Measurement of Object-Oriented Conceptual Schemas: Design and Evaluation Issues
by Silvia Mara Abraho
PhD Thesis
Presented to the Department of Information Systems and Computation of the Valencia University of Technology in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Computer Science
October 2004
The research reported in this thesis has been financially supported by CARE Technologies S.A, the WEST research project of the CYTED Program (VII.18), and by the CICYT research project with reference TIC 2001-3530C02-01, Spain.
Silvia Mara Abraho ISBN:0-496-1510-3, UMI ProQuest Digital Dissertations Printed in Spain, Valencia. The figures used in this thesis are taken from the collection of Kaat and Geert Poels.
ii
Thesis Advisor: Dr. Oscar Pastor, Valencia University of Technology, Spain Thesis Committee: Dr. Alain Abran, Universit du Qubec, Canada Dr. Geert Poels, University of Ghent, Belgium Dr. Joo Falco e Cunha, University of Porto, Portugal Dr. Mario Piattini, University of Castilla-La-Mancha, Spain Dr. Vicente Pelechano, Valencia University of Technology, Spain
iii
OlivaNova Model Execution is a trademark of CARE Technologies S.A. ONME is a trademark of CARE Technologies S.A. OASIS is a trademark of CARE Technologies S.A.
iv
Abstract
Functional Size Measurement (FSM) methods are intended to measure the software size by quantifying the functional user requirements. The capability to accurately quantify the software size in an early stage of the development lifecycle is critical for evaluating risks, developing project estimates and having early project indicators. Despite wide spread practitioner acceptance, the FSM methods have been criticized for their inability to correctly measure the size of object-oriented systems. Moreover, most organizations have a number of Web Applications for which functional size must be measured. None of the ISOstandardized FSM methods were designed taking the particular features of Web applications into account. In this thesis, OO-Method Function Points (OOmFP) is presented as a measurement procedure for modeling and sizing object-oriented systems developed by an automatic software production method called OO-Method. This procedure maps the concepts used in OO-Method onto the concepts used by Function Point Analysis, a standard FSM method supported by the International Functional Point Users Group (IFPUG FPA). Additionally, OOmFP is extended to size Web applications. We called this extension OOmFP for the Web (OOmFPWeb), and it measures the functional size of Web applications from conceptual schemas that are specified with Object-Oriented Web Solutions modeling approach (OOWS). We describe the design and the application of the proposed measurement procedure following the steps of a process model for software measurement (Jacquet and Abran, 1997). This thesis also reports on the evaluation of OOmFP and OOmFPWeb. This comprises the validation of the design of the measurement procedures (theoretical validation) and the validation of the application of the measurement procedures (empirical validation). We show the first results towards the theoretical validation of the OOmFP and OOmFPWeb functional size measures using a formal framework called DISTANCE (Poels and Dedene, 1999). With regard to empirical validation, we report the results of two laboratory experiments. In the first experiment, OOmFP is compared to IFPUG FPA using a range of performance-based (i.e., efficiency, reproducibility, accuracy) and perceptionbased variables (i.e., perceived ease of use, perceived usefulness and intention to use). The goal is to determine whether OOmFP results in better size assessments and is more likely to be adopted in practice than IFPUG FPA. An important contribution is the development and empirical testing of a theoretical model for evaluating FSM methods in general. The results show that OOmFP is more time-
consuming than IFPUG FPA, but the measurement results are more reproducible and accurate. In the second experiment, OOmFPWeb is evaluated on a range of variables, including productivity, reproducibility, perceived ease of use, perceived usefulness and intention to use. The results show that OOmFPWeb is efficient when compared to current industry practices. Furthermore, it produces reproducible functional size assessments and is perceived to be easy to use as well as useful in the context of the OOWS development process. Lastly, part of the results of this thesis were put into practice at CARE Technologies S. A. Specifically, the measurement procedure for sizing objectoriented systems was personalized and automated to be used with OlivaNova Model Execution, a model-based code generation environment.
vi
Resumen
Los mtodos de medicin de tamao funcional (FSM)1 miden el tamao del software a travs de la cuantificacin de los requisitos funcionales del usuario. La capacidad de cuantificar el tamao del software en las primeras fases del ciclo de vida es crtica para la evaluacin de riesgos, generacin de estimaciones y la obtencin de indicadores del proyecto. A pesar de su extensa aceptacin en la prctica, los mtodos FSM han sido criticados por su incapacidad para la correcta medicin de sistemas orientados a objetos. Por otra parte, muchas organizaciones hoy en da requieren medir aplicaciones Web y los mtodos FSM estndares son inadecuados ya que no han sido diseados teniendo en cuenta las caractersticas particulares de este tipo de artefactos. En esta tesis se presenta OO-Method Function Points (OOmFP) como un procedimiento para el modelado y la medicin de sistemas software desarrollados con el mtodo de produccin automtica de software OO-Method. La propuesta OOmFP se define en base a un mapeo entre las primitivas de modelado de OOMethod y los conceptos del Anlisis de Puntos de Funcin, un mtodo FSM estndar mantenido por el Internacional Function Point Users Group (IFPUG FPA). Asimismo, OOmFP es extendido para la medicin de aplicaciones Web. Esta extensin ha sido llamada OOmFPWeb y permite medir el tamao funcional de aplicaciones Web a partir de esquemas conceptuales especificados con la aproximacin OOWS (Object-Oriented Web Solutions). OOmFP y su extensin para la Web (OOmFPWeb) son diseados y aplicados siguiendo los pasos de un modelo de proceso para la medicin del software (Jacquet and Abran, 1997). En esta tesis tambin se presenta la evaluacin de OOmFP y OOmFPWeb. Dicha evaluacin abarca no slo la validacin del diseo de los procedimientos (validacin terica) sino tambin la validacin del uso de los procedimientos de medicin (validacin emprica). Los primeros resultados hacia la validacin terica de la medida de tamao de OOmFP y OOmFPWeb son demostrados usando el marco formal DISTANCE (Poels y Dedene, 1999). Con respecto a la validacin emprica, se presentan los resultados de dos experimentos controlados. En el primer experimento, OOmFP es comparado a IFPUG FPA usando un conjunto de variables basadas en rendimiento (eficacia, reproducibilidad, precisin, etc.) y en percepcin (facilidad de uso percibida, utilidad percibida e
1
del ingls Functional Size Measurement
vii
intencin de uso). El objetivo ha sido determinar si OOmFP produce mejores estimaciones de tamao y si es ms probable de ser adoptado en la prctica que IFPUG FPA. Una contribucin importante es el desarrollo y prueba de un modelo terico para evaluar mtodos FSM en general. Los resultados demuestran que OOmFP consume ms tiempo que IFPUG FPA pero los resultados de medicin son ms reproducibles y precisos. En el segundo experimento, OOmFPWeb se evala usando un conjunto de variables que incluyen productividad, reproducibilidad, facilidad de uso percibida, utilidad percibida e intencin de uso. Los resultados demuestran que OOmFPWeb es eficiente cuando se compara con las prcticas actuales en la industria. Adems, produce estimaciones de tamao reproducibles y es percibido como fcil de usar y til por sus usuarios en el contexto del mtodo de desarrollo OOWS. Por ltimo, parte de los resultados de esta tesis fueron puestos en prctica en CARE Technologies S. A. Especficamente, el procedimiento de medicin para sistemas orientados al objeto ha sido personalizado y automatizado para su uso con el OlivaNova Model Execution, un ambiente de generacin automtica de cdigo basado en modelos conceptuales.
viii
Resum
Els mtodes de mesurament de grandria funcional (FSM)2 mesuren la grandria del software a travs de la quantificaci dels requisits funcionals de lusuari. La capacitat de quantificar la grandria del software en les primeres fases del cicle de vida s crtica per a lavaluaci de riscos, generaci destimacions i lobtenci dindicadors del projecte. A pesar de la seua extensa acceptaci en la prctica, els mtodes FSM han sigut criticats per la seua incapacitat per al correcte mesurament de sistemes orientats a objectes. Daltra banda, moltes organitzacions hui en dia requerixen mesurar aplicacions Web i els mtodes FSM estndards sn inadequats ja que no han sigut dissenyats tenint en compte les caracterstiques particulars deste tipus dartefactes. En esta tesi es presenta OO-Method Function Points (OOmFP) com un procediment per al modelatge i el mesurament de sistemes software desenvolupats amb el mtode de producci automtica de software OO-Method. La proposta OOmFP es definix en base a un mapeig entre les primitives de modelatge dOO-Method i els conceptes de lAnlisi de Punts de Funci, un mtode FSM estndard mantingut per lInternacional Function Point Users Group (IFPUG FPA). Aix mateix, OOmFP s ests per al mesurament daplicacions Web. Esta extensi ha sigut anomenada OOmFPWeb i permet mesurar la grandria funcional daplicacions Web a partir desquemes conceptuals especificats amb laproximaci OOWS. OOmFP i la seua extensi per a la Web (OOmFPWeb) sn dissenyats i aplicats seguint els passos dun model de procs per al mesurament del software. En esta tesis tamb se presenta lavaluaci dOOmFP i OOmFPWeb. La dita avaluaci abraa no sols la validaci del disseny dels procediments (validaci terica) sin tamb la validaci de ls dels procediments de mesurament (validaci emprica). Els primers resultats cap a la validaci terica de la mesura de grandria dOOmFP i OOmFPWeb sn demostrats usant el marc formal DISTANCE (Poels i Dedene, 1999). A ms, es presenten els resultats de dos experiments controlats. En el primer experiment, OOmFP s comparat a IFPUG FPA usant un conjunt de variables basades en rendiment (eficcia, reproduibilitat, precisi, etc.) i en percepci (facilitat ds percebuda, utilitat percebuda i intenci ds). Lobjectiu ha sigut determinar si OOmFP produx millors estimacions de grandria que IFPUG FPA i si s ms probable de ser adoptat en la prctica que IFPUG FPA. Una contribuci important s el desenvolupament i prova dun model teric per a avaluar mtodes FSM en general. Els resultats demostren que OOmFP consumix
2
De langls Functional Size Measurement
ix
ms temps que IFPUG FPA per els resultats de mesurament sn ms reprodubles i precisos. En el segon experiment, OOmFPWeb savalua usant un conjunt de variables que inclouen productivitat, reproduibilitat, facilitat ds percebuda, utilitat percebuda i intenci ds. Els resultats demostren que OOmFPWeb s eficient quan es compara amb les prctiques actuals en la indstria. A ms, produx estimacions de grandria reprodubles i s percebut com fcil dusar i til pels seus usuaris en el context del mtode de desenvolupament OOWS. Finalment, part dels resultats desta tesi va ser posada en prctica en CARE Technologies S. A. Especficament, el procediment de mesurament per a sistemes orientats a lobjecte ha segut personalizat i automatitzat per al seu s amb lOlivaNova Model Execution, un ambient de generaci automtica de codi basat en models conceptuals.
Acknowledgements
First of all, I would like to thank my supervisor Prof. Oscar Pastor for his support and encouragement during the work on this thesis. I would also like to give special thanks to Prof. Geert Poels, who arranged a three-month stay at University of Ghent. His valuable critique of this work had a great influence on the progress of my research. I am also very grateful to CARE Technologies S.A. Important parts of the research conducted as part of this thesis would not have been possible without the cooperation and participation of the people in this company. I would like to thank all of the following: Emilio Iborra, Jos Miguel Barber, Juan Carlos Molina, Sofia Mart, Ismael Torres, Fernando Calatrava , and many others. I would also like to thank all my colleagues of the OO-Method Research Group: Pele, Juan, Manoli, Joan, Jorge, Hugo, Alicia, Isabel(s), Pedro, Marta, Javi, Enric, Eva, Javier, Gonzalo, Ausis, Victoria and a special thanks to Nelly for working with me and for continuing research of the many ideas presented in this thesis. I thank Daniel Moody for his contribution to the initial design of the laboratory experiments and the definition of a theoretical model for FSM. I also thank Eberhard Rudolph and Prof. Alain Abran for their very helpful comments and suggestions. Thanks to all the PhD and Masters students that participated in the empirical studies presented as part of this thesis. Thanks to Claudia Hazan, manager of the Brazilian Function Point Users Group (BFPUG), for sharing very useful discussions by e-mail. Thanks to Luis Olsina for encouraging me to finish this thesis. Also thanks to Marcela Genero for providing me with useful materials and references on the theoretical and empirical validation of software metrics. Thanks to Ann Maes and Frederik Gailly for all their help and support during my research stay in Ghent. I want to give very special thanks to my husband and colleague, Emilio Insfrn, for his love, support and encouragement throughout this research work. Also thanks to Sebastian (my cat) for accompanying me (even sleeping on my papers) all the nights I spent writing this book. Last but not least, I have to thank my parents Jos Alves and Ana Lucia for giving me the opportunity to study my Ph.D. in Spain. This thesis would not have been possible without their loving support and care. Silvia Abraho, October 2004
xi
Contents
1 Introduction .............................................................................................. 21
1.1 Software size measurement .......................................................................... 21 1.1.1 Functional sizing: the users viewpoint................................................... 22 1.1.2 Technical sizing: the developers viewpoint........................................... 24 1.2 Functional size measurement (FSM) ............................................................ 25 1.2.1 Existing standards and frameworks for FSM.......................................... 25 1.2.1.1 The ISO/IEC 14143 standard series for FSM (1998) ..................... 25 1.2.1.2 A process model for FSM (Jacquet and Abran, 1997).................... 27 1.2.1.3 A generalized representation of FSM (Fetcke, 2001)..................... 29 1.2.1.4 Comparison of different standards and frameworks for FSM ........ 30 1.2.2 Usefulness of functional size measurement ............................................ 31 1.3 Problem statement and research goal............................................................ 33 1.3.1 The OO-Method paradigm: from problem space to solution space ........ 34 1.3.2 Research goals ........................................................................................ 37 1.4 Research environment .................................................................................. 39 1.5 Research design ............................................................................................ 40 1.5.1 Selection of research methods................................................................. 41 1.5.1.1 Stage I............................................................................................. 41 1.5.1.1.1 Participants ............................................................................. 42 1.5.1.1.2 Research process .................................................................... 43 1.5.1.2 Stage II ........................................................................................... 44 1.5.1.2.1 Experimental Process ............................................................. 45 1.6 Thesis outline................................................................................................ 47
Part I: The Design of the Functional Size Measurement Procedure 2 Literature Review..................................................................................... 53
2.1 Functional size measurement for object-oriented systems ........................... 53 2.1.1 First category .......................................................................................... 55 2.1.1.1 The IFPUG proposal (1995) ........................................................... 55 2.1.1.2 The Lehne proposal (1997)............................................................. 56 2.1.1.3 The Fetcke et al. proposal (1998) ................................................... 56 2.1.1.4 The Uemura et al. proposal (1999) ................................................. 57
2.1.2 Second category ...................................................................................... 59 2.1.2.1 The ASMA proposal (1994) ........................................................... 59 2.1.2.2 The Kammelar proposal (2000)...................................................... 60 2.1.2.3 3-D Function Points (Whitmire, 1996)........................................... 62 2.1.2.4 Object-Oriented Function Points (Antoniol and Calzolari, 1998) .. 63 2.1.2.5 Object-Oriented Design Function Points (Ram and Raju, 2000).... 65 2.1.3 Third category......................................................................................... 66 2.1.3.1 The Laranjeira proposal (1990) ...................................................... 67 2.1.3.2 Object Point Analysis (Banker, 1991) ............................................ 68 2.1.3.3 Object Workload Analysis Gauge (Rains, 1991)............................ 69 2.1.3.4 The Thomson et al. proposal (1994)............................................... 70 2.1.3.5 Object-Function Point Analysis (Zhao and Stockman , 1995) ....... 71 2.1.3.6 Object-Points (Sneed, 1996)........................................................... 72 2.1.3.7 Predictive Object Points (Price Systems, 1999) ............................. 73 2.1.4 Discussion............................................................................................... 75 2.2 Functional size measurement for Web artifacts............................................ 78 2.2.1 IFPUG guidelines (IFPUG, 1998)........................................................... 79 2.2.2 Web Objects (Reifer, 2000) .................................................................... 80 2.2.3 Web-Points (Cleary, 2000) ..................................................................... 82 2.2.4 Internet Points (Cost Xpert Group, 2001) ............................................... 82 2.2.5 Data Web Points (Ochoa et al., 2003)..................................................... 83 2.2.6 Discussion............................................................................................... 84
3 Foundations............................................................................................... 87
3.1 Conceptual modeling with OO-Method ....................................................... 87 3.1.1 Object Model .......................................................................................... 89 3.1.2 Dynamic Model ...................................................................................... 91 3.1.3 Functional Model .................................................................................... 93 3.1.4 Presentation Model ................................................................................. 95 3.2 OASIS formal specification ........................................................................... 97 3.2.1 The formal specification as the system repository ................................ 102 3.3 Execution Model ........................................................................................ 104 3.4 Conceptual modeling with OOWS ............................................................. 105 3.4.1 Navigational Model .............................................................................. 106 3.4.1.1 Basic navigational modeling primitives ....................................... 106 3.4.1.2 Advanced navigational modeling primitives ................................ 110 3.4.2 Presentation Model ............................................................................... 111 3.5 Conclusions ................................................................................................ 114
xiv
4 A Functional Size Measurement Procedure for OO Systems: The OOmFP Approach ................................................................................. 115
4.1 Design of the measurement method............................................................ 115 4.1.1 Definition of the objectives................................................................... 115 4.1.2 Characterization of the concept to be measured.................................... 116 4.1.3 Selection of the metamodel................................................................... 116 4.1.3.1 IFPUG FPA metamodel................................................................ 117 4.1.3.2 Mapping between concepts .......................................................... 119 4.1.4 Definition of the numerical assignment rules ....................................... 122 4.1.4.1 Measurement rules for the Object Model ..................................... 124 4.1.4.2 Measurement rules for the Dynamic Model ................................. 131 4.1.4.3 Measurement rules for the Functional Model............................... 133 4.1.4.4 Measurement rules for the Presentation Model ............................ 134 4.2 Measurement method application............................................................... 136 4.2.1 Software documentation gathering ....................................................... 139 4.2.1.1 User requirements specification ................................................... 139 4.2.1.2 OO-Method conceptual schema ................................................... 141 4.2.2 Construction of the software model ...................................................... 143 4.2.3 Application of the numerical assignment rules ..................................... 145 4.2.3.1 Application of the OOmFP measurement rules ............................ 145 4.2.3.2 Application of the IFPUG counting rules ..................................... 147 4.3 4.4 4.5 Field testing: applying action research in the design of OOmFP................ 148 Comparison with related work.................................................................... 151 Conclusions ................................................................................................ 153
5 Extending OOmFP for Sizing Web Applications ................................ 155

5.1 Introduction ................................................................................................ 155 5.2 Design of the measurement method............................................................ 157 5.2.1 Definition of the objectives................................................................... 157 5.2.2 Characterization of the concept to be measured.................................... 157 5.2.3 Selection of the metamodel................................................................... 158 5.2.3.1 Mapping between concepts .......................................................... 158 5.2.4 Definition of the numerical assignment rules ....................................... 161 5.2.4.1 Measurement rules for the Navigational Model ........................... 162 5.2.4.2 Measurement rules for the Presentation Model ............................ 165 5.3 Measurement method application............................................................... 168 5.3.1 Software documentation gathering ....................................................... 169 5.3.1.1 OOWS conceptual schema ........................................................... 170 5.3.2 Construction of the software model ...................................................... 179
xv
5.3.3 Application of the numerical assignment rules ..................................... 180 5.3.3.1 Application of the OOmFPWeb measurement rules .................... 180 5.3.3.2 Application of the IFPUG counting rules ..................................... 181 5.4 5.5 Comparison with related work.................................................................... 182 Conclusions ................................................................................................ 183
Part II: The Evaluation of the Functional Size Measurement Procedure 6 Validation of the Design of the Measurement Procedure ................... 187
6.1 Introduction ................................................................................................ 187 6.2 Previous research on the theoretical validation of FSM methods............... 189 6.2.1 Measurement Theory ............................................................................ 189 6.2.2 Validation of FSM methods using Measurement Theory ..................... 192 6.3 Implications for the validation of the design of OOmFP and OOmFPWeb196 6.3.1 Measurement processes and primitive functional size measurements in OOmFP ................................................................................................. 197 6.4 DISTANCE: a framework for software measurement (Poels and Dedene, 1999)..............................................................................................................201 6.4.1 Validating the OOmFP primitive functional size measures using DISTANCE........................................................................................... 202 6.4.1.1 Step 1. Find a measurement abstraction ....................................... 203 6.4.1.2 Step 2. Model distances between measurement abstractions........ 205 6.4.1.3 Step 3. Quantify distances between measurement abstractions.... 206 6.4.1.4 Step 4. Find a reference abstraction.............................................. 207 6.4.1.5 Step 5. Define the software measure ............................................ 207 Validating the OOmFPWeb primitive functional size measures using DISTANCE................................................................................................ 209 6.5.1 Find a measurement abstraction............................................................ 211 6.5.2 Model distances between measurement abstractions ............................ 211 6.5.3 Quantify distances between measurement abstractions ........................ 212 6.5.4 Find a reference abstraction .................................................................. 212 6.5.5 Define the software measure (metric) ................................................... 212 Metrics-based definition of OOmFP and OOmFPWeb measurement rules213 Conclusions ................................................................................................ 214
6.5
6.6 6.7
7 Validation of the Application of the Measurement Procedure........... 217

7.1 Introduction ................................................................................................ 217
xvi
7.2 Theoretical models in IS research............................................................... 219 7.2.1 The Technology Acceptance Model (Davis, 1989)............................... 220 7.2.2 The Method Evaluation Model (Moody, 2001) .................................... 221 7.3 A general theoretical model for evaluating FSM methods ......................... 224 7.3.1 Operationalization of the model............................................................ 224 7.3.1.1 Constructs for performance-based variables................................. 224 7.3.1.2 Constructs for perception-based variables (OOmFP) ................... 225 7.3.1.3 Constructs for perception-based variables (OOmFPWeb)............ 228 7.3.1.4 Development of the measurement instrument .............................. 229 7.4 Conclusions ................................................................................................ 229
8 Experiment 1: Comparative Evaluation of OOmFP against IFPUG FPA........................................................................................................... 231

8.1 8.2 Introduction ................................................................................................ 231 Experiment design ...................................................................................... 232
8.3 Planning...................................................................................................... 234 8.3.1 Selection of subjects ............................................................................. 234 8.3.2 Variable selection.................................................................................. 234 8.3.3 Experimental treatments ....................................................................... 236 8.3.4 Instrumentation ..................................................................................... 236 8.3.5 Experimental tasks ................................................................................ 238 8.3.6 Hypothesis formulation......................................................................... 239 8.4 Experiment operation ................................................................................. 245 8.4.1 Preparation ............................................................................................ 245 8.4.2 Execution .............................................................................................. 246 8.4.3 Data recording and validation ............................................................... 246 8.5 Analysis and interpretation ......................................................................... 247 8.5.1 Comparative analysis of the performance of the FSM methods ........... 247 8.5.2 Comparative analysis of the likelihood of adoption in practice of the FSM methods......................................................................................... 251 8.5.3 Analysis of the acceptance of OOmFP ................................................. 258 8.5.4 Validation of Method Adoption Model (MAM) ................................... 260 8.6 Discussion................................................................................................... 268 8.6.1 Summary of findings............................................................................. 271 8.6.2 Model revision ...................................................................................... 271 8.6.3 Validity evaluation................................................................................ 273 8.6.3.1 Threats to conclusion validity....................................................... 273 8.6.3.2 Threats to construct validity ......................................................... 274 8.6.3.3 Threats to internal validity............................................................ 274
xvii
8.6.3.4 8.7
Threats to external validity ........................................................... 275
Conclusions ................................................................................................ 276
9 Experiment 2: Evaluating the Performance and Acceptance of OOmFPWeb............................................................................................ 279

9.1 Experiment design ...................................................................................... 279 9.2 Planning...................................................................................................... 280 9.2.1 Selection of subjects ............................................................................. 280 9.2.2 Variable selection.................................................................................. 280 9.2.3 Experimental tasks ................................................................................ 281 9.2.4 Instrumentation ..................................................................................... 282 9.2.5 Hypothesis formulation......................................................................... 282 9.3 Experiment operation ................................................................................. 286 9.3.1 Execution .............................................................................................. 286 9.3.2 Data recording and validation ............................................................... 286 9.4 Analysis and interpretation ......................................................................... 287 9.4.1 Analysis of the actual performance of OOmFPWeb............................. 287 9.4.2 Analysis of the perceived performance and likelihood of adoption of the OOmFPWeb.................................................................................... 290 9.4.3 Validating the validity and reliability of the MAM constructs ............. 293 9.4.4 Validation of the Method Adoption Model........................................... 296 9.5 Discussion................................................................................................... 303 9.5.1 Validity evaluation................................................................................ 304 9.5.1.1 Threats to conclusion validity....................................................... 304 9.5.1.2 Threats to construct validity ......................................................... 304 9.5.1.3 Threats to internal validity............................................................ 305 9.5.1.4 Threats to External Validity ......................................................... 305 9.6 Conclusions ................................................................................................ 305
10 Conclusions and Further Research..................................................... 309

10.1 Conclusions ................................................................................................ 309 10.1.1 Design of the measurement procedure .................................................. 309 10.1.2 Validation of the design of the measurement procedure ....................... 310 10.1.3 Validation of the application of the measurement procedure................ 310 10.1.4 Actual usage.......................................................................................... 311 10.1.5 Summary of the main contributions...................................................... 312 10.2 Related publications ................................................................................... 314 10.2.1 International journals ............................................................................ 314
xviii
10.2.2 Book chapters........................................................................................ 314 10.2.3 International conferences and workshops ............................................. 315 10.2.4 Ibero-american workshops.................................................................... 316 10.2.5 National conferences and workshops.................................................... 317 10.2.6 Working papers..................................................................................... 318 10.3 Future research directions........................................................................... 318
List of Figures ............................................................................................. 321 List of Tables............................................................................................... 325 List of Abbreviations and Acronyms........................................................ 329 Bibliography ............................................................................................... 333 Appendix A. Experimental Materials ...................................................... 347 Appendix B. Survey Instruments Used in the Experiments .................. 399 Appendix C. Measurement Results .......................................................... 405
xix
Chapter 1
Introduction
The research work presented in this thesis was conducted in the context of a branch of the Software Engineering field, known as Software Measurement. More specifically, this work can be classified in the Functional Size Measurement field. This chapter contains the motivation, context, and the objectives of this research work. The chapter first discusses the different viewpoints to software sizing. Then, the concept of functional size measurement, the current frameworks to represent it, as well as its usefulness are discussed. Finally, the research question addressed, a list of research goals and the structure of the thesis are outlined.
1.1
Software size measurement
The development and the maintenance of software systems accounts for one percent of the worlds economy [1]. However, according to a recent Standish group research study [2], only an average of 34% of software projects are completed on time and within budget. Therefore, 32% of projects failed due to over-time, over-budget or cancelations. In addition, this study pointed out that on average only 61% of the originally specified functionality was delivered to customers. In this context, software size measurement plays an important role. It is widely accepted that software size is one of the key factors that potentially affect the cost and time of the software projects [3] [4] [5] [6] [7]. Basically, a software system can be measured from two viewpoints: the users viewpoint and the developers viewpoint (see Figure 1). The
Chapter 1. Introduction
perspective of the user relates to what the system can do for the user (Problem Domain) and functional size measures support the users perspective. The developer sees the system in terms of the internals of what needs to be built (System Domain) and is able to relate better to technical size measures. These views are not necessarily correlated to each other. We might find a system which is very large in terms of functionality, but which is relatively small in terms of technical items (modules, objects, etc.).
Figure 1. Software domains and models
As pointed out by Meli [8], measuring software from a functional perspective has different purposes than measuring the same software from a technical viewpoint. The main difference is that functional size measures can be obtained in the initial stages of the system development whereas technical size measures are obtained in terms of the actual software elements (i.e., the lines of code, number of classes, etc.). Both viewpoints are introduced in the sections that follow.
1.1.1
Functional sizing: the users viewpoint
Functional Size Measurement (FSM) is defined in the ISO/IEC 14143-1 standard [9] as the process of measuring functional size. The aim of this ISO/IEC standard is to define the concepts related to Functional Size Measurement (FSM) and to describe the general principles for applying an FSM method (this standard will be discussed later in this chapter). Functional Size is defined as the size of the software derived by quantifying the Functional User Requirements (FURs). FURs are a sub-set 22
of the user requirements that represent the user practices and procedures that the software must perform to fulfill the users needs. They exclude quality requirements (as defined in the ISO/IEC 9126 standard [10]) and any technical requirements. In fact, quality requirements correspond to non-functional requirements as defined in the Requirements Engineering community [11]. Requirements of this kind express how the system must perform, including aspects such as reliability, usability, portability, etc. Technical requirements express how the system will be built. It relates to the technology and environment (programming language, operating system, etc.), for the development, maintenance, support and execution of the system. Therefore, the challenge for software size measurement from the users viewpoint is to have good software requirements specifications to enable accurate measurement. As shown in Figure 2 the first FSM method can be considered Function Point Analysis (FPA), which was proposed by Albrecht and Gaffney [12] at IBM in the 1970s. The FPA 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 transaction function determines the amount of functionality that the software delivers, hence its functional size. One advantage of this kind of measure is that it is independent of physical and technological components (e.g., programming languages) of the software being measured and thus allows early size measurement. The major limitation of FPA is its restricted applicability to Management Information Systems (MIS).
Figure 2. Evolution of FSM methods (Source: [13])
23
FPA has evolved from Albrechts method and is currently supported by the International Function Point User Group (IFPUG), which has proposed detailed rules for applying FPA [14]. Hereafter, when we refer to FPA, we always refer to the FPA method release 4.1 in its current form as supported by IFPUG. A number of variants that take alternative views on functional size have been proposed. The most important are Mark II FPA [15], Full Function Points (FFP) [16] and recently COSMIC FFP [17]. Mark II FPA [15] attempted to improve on Albrechts size measurement and to be compatible with ideas from structured analysis and design. The United Kingdom Metrics Association (UKSMA) maintains this method. In 1997, FFP [16] was proposed as an extension of the IFPUG FPA to capture the functional size of real-time applications. At the end of 1990s, the Common Software Metrics International Consortium (COSMIC) published the COSMIC-FFP method [17] to measure real-time or business application software that is organized in different layers and peer items.
1.1.2
Technical sizing: the developers viewpoint
As the project progresses, more is known about the technical aspects of the system. When there is sufficient knowledge about the project, one of the common ways of sizing it is by break the system down into smaller pieces. The sum of the size measurements of each of the broken parts is assumed to provide the size of the overall system. Breaking down divides a large and complex system into smaller manageable parts that can be sized easily. In such cases, the size measure of each component is typically expressed in terms of number of source lines of code (SLOC). SLOC is typically used to estimate the amount of effort that will be required to develop a system, as well as to estimate productivity or effort once the software is produced. Although SLOC is a widely used software size measure, it has been object of many criticisms [5] [18] [19]. The main reason is that this kind of measure comes too late. In general, the technical size of the software is measured in the detailed design of the project or when it is finished. Moreover, the arrival of new generation languages and coding styles has caused large variations in the amount of SLOCs required to build a function.
24
1.2
Functional size measurement (FSM)
In this section, we revise the existing standards and frameworks proposed to define the concepts involved in functional size measurement. Such concepts include the requirements needed to define and apply a FSM method. In addition, we discuss the usefulness of functional size measurement in the context of project estimation, quality assessment, benchmarking, and outsourcing contracts, amongst others.
1.2.1
1.2.1.1
Existing standards and frameworks for FSM

The ISO/IEC 14143 standard series for FSM (1998)
The ISO/IEC 14143 series of standards provide a framework in which a new FSM method can be developed, tested and refined. It is composed by the following five parts: Part 1: Definition of concepts Part 2: Conformance evaluation of software sizing methods to ISO/IEC 14143-1:1998 Part 3: Verification of a functional size measurement method Part 4: Functional size measurement reference model Part 5: Determination of functional domains for use with functional size measurement.
Part 1 [9] defines the general concepts and outlines the characteristics and requirements necessary for a software sizing method to qualify as a functional size measurement method. According to the ISO/IEC 14143-1 standard, a FSM method is: A specific implementation of FSM defined by a set of rules, which conforms to the mandatory features of this part of ISO/IEC 14143. Part 2 [20] provides a process for checking whether a candidate FSM method conforms to the concepts described in Part 1. The conformity evaluation is performed by cross-referencing each component of a candidate FSM method against Part 1. 25
Part 3 [21] provides a framework for verifying the statements of an FSM method and/or for conducting tests with the following performance criteria: repeatability and reproducibility, accuracy, convertibility, discrimination threshold, and applicability to functional domains. However, these performance criteria are not part of the characteristics and requirements defined in Part 1. Part 4 [22] defines a reference model to be used when verifying a FSM method. It is an input to the evaluation process of an FSM Method and consists of two components: a classification framework of Reference User Requirements (RUR), which can be sized using an FSM method, and a guide to select Reference FSM Methods, against which an FSM method can be compared. Although this part of the standard provided some examples of reference objects against which an FSM method can be applied and compared, the formulation and execution of evaluation tests as well as the interpretation of their results is outside the scope of this document.
ISO/IEC 20926: IFPUG
Gives processes to verify the performance properties Gives processes to enables a FSM Method to be assessed against some standard reference point.
ISO/IEC 14143-6:
Guide to 14143 & related standards
Figure 3. Relationships between ISO/IEC 14143 and ISO-standards FSM methods (adapted from [23])
26
Finally, Part 5 [24] addresses the determination of functional domains for use with functional size measurements. A Functional Domain is: A class of software based on the characteristics of Functional User Requirements which are pertinent to FSM. Examples of functional domains are Management Information Systems (MIS), Real Time (RT) and Scientific Software (SS). The aim for Part 5 is to assist users with the information to analyze which FSM method is most appropriate to the functional domain of the software to be measured. After the 14143 standard had been proposed, several FSM methods started a standardization process. Nowadays, the following FSM methods are ISO standards: IFPUG FPA (20926), Mark II FPA (20968), COSMIC-FPP (19761) and NESMA FPA (24570). Moreover, Part 6 [23] for this standard is under definition. The purpose of this part is to give clear guidance about the relationship between the various parts of the ISO/IEC 14143 series and to assist the user to select the FSM Methods that best suits the users needs from the available ones. Figure 3 summarizes the relationships between ISO/IEC 14143 series and the ISO-standards FSM methods. 1.2.1.2 A process model for FSM (Jacquet and Abran, 1997)
In their work as ISO editors for the Guide to the Verification of FSM methods (ISO 14143-3) [21], Jacquet and Abran [25] [26] suggest a process model for functional size measurement (see Figure 4).
Figure 4. Measurement process steps (Source: Jacquet and Abran [25])
In the first step, a measurement method is designed, the concept to be measured is defined and the rules to measure it are conceived. In addition, all tasks associated with a methods 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 27
such as which level of knowledge is required in order to be able to apply the rules of the measurement method, whether the data can be storaged, and whether the measurement rules application can 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, the results are exploited in the fourth step. 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 thesis. Figure 5 shows the substeps of the software measurement process model related to these steps.
Figure 5. Measurement process detailed model (Source: Jacquet and Abran [25])
In the design of the method (Step 1), the objectives of the FSM method should be specified first. This activity includes the precise definition of the object and the attribute that will be measured using the method. This is in accordance with others frameworks proposed for software measurement such as the frameworks proposed by Zuse [27], Kitchencham et al. [28] and Fenton [29]. Then, in the characterization of the concept to be measured step, the meaning of the attribute is properly captured using mathematical notations or 28
axiomatic approaches. In a parallel step, a metamodel is selected or designed to represent the software to which the proposed FSM method will be applied. This metamodel should describes the elements that will be used to represent the software and the rules that will be used to identify the elements in terms of which attribute will be measured. Finally, the rules to assign a numerical value to the couple (attribute, object) are defined. The measurement method application (Step 2) comprises three substeps. First, the documentation necessary to apply the method is gathered. Second, the metamodel underlying the FSM method is used to model the software that will be measured. Third, the numerical assignment rules are applied. Finally, Step 3 illustrates that the application of the FSM method provides a measurement result that can subsequently be verified and analyzed. 1.2.1.3 A generalized representation of FSM (Fetcke, 2001)
Fetcke et al. [13] proposed a generalized representation for functional size measurement that captures the main concepts used by FSM methods to represent a system so that its functional size is emphasized. This representation was applied to IFPUG FPA [30], Mark II FPA [31], and Full Function Points [16]. All these methods can be characterized as data-oriented. 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. Figure 6 illustrates all the concepts existing in a data-oriented abstraction. These concepts are: User concept: the users that interact with a system. These can be human users or software and hardware. Application concept: the object of measurement. Applications provide functions to the users. Transaction concept: the processes of interaction between the user and the system from a logical perspective. Data concept: the data stored by the system. Data elements represent the smallest data items that are meaningful to the user. Data elements can be structured in logically related groups of data. 29
Figure 6. The data-oriented abstraction (Source: [13])
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. 1.2.1.4 Comparison of different standards and frameworks for FSM
The ISO/IEC 14143 standard is useful in the sense that it defines the concepts handled in the functional size measurement. It also clearly defines what mandatory requirements are needed for a FSM method to be recognized as ISO standard. However, it does not provide an integrated view about all activities involved in the definition and the use of a FSM method. This is accomplished by the Jacquet and Abran [25] [26] process model. Hence, this process model complements the ISO/IEC 14143 standard by identifying all the tasks associated with a methods measurement procedure as well as the links between these tasks. On the other hand, the contribution of the Fetckes work [13] is on the formalization of an software abstraction that is data-oriented. This can be classified as a class of metamodel to represent software systems. It is necessary because instead of using the concepts and models of a development method, FSM methods introduces its own concepts to describe a system software. According to Fetcke, functional size measurement requires two steps of abstraction: Identification step, where the software documentation is represented in the data-oriented abstraction. This step is equivalent to the software documentation gathering and construction of the software model activities in Step 2 (measurement method application) of the Jacquet and Abran measurement process model. Measurement step, where the items in the data-oriented representation are mapped into numbers. This step is equivalent to 30
the application of the numerical assignment rules activity in Step 2 of the Jacquet and Abran measurement process model. Therefore, the Jacquet and Abran [25] measurement process model [26] may be considered more complete than the Fetcke abstract model [13]. It includes not only the activities needed for a measurement method application but also the activities for the design of the measurement procedure.
1.2.2
Usefulness of functional size measurement
Software size measurement is an important part of the software development process [18] [32]. Functional size measures are used to assess the logical external view of the software from the users perspective by measuring the amount of functionality to be delivered. These measures can be used for a variety of purposes, such as project estimation [18] [7], quality assessment [32], benchmarking [33], outsourcing contracts [34]. According to ISO/IEC 14143-1 [9] functional size measurements can be used for3: Budgeting software development or maintenance Tracking the progress of a project Negotiating modifications to the scope of the software Determining the proportion of the functional requirements satisfied by a software package Estimating the total software asset of an organization Managing the productivity of software development, operation or maintenance processes Analyzing and monitoring software defect density.
The use of functional size measures has been extensively discussed in the literature. These measures can be used for generating a variety of indicators (productivity, financial and quality) in different phases of the software development process. Next, we discuss the use of functional size in conjunction with other software measures. Productivity indicators consider the software product (new or improved) with respect to the effort and people in the project. Examples of productivity
3
These applications relate to Step 4 in the Jacquet and Abran measurement process (exploitation of the measurement result).
31
indicators are: project delivery rate (functional size / h), duration delivery rate (functional size /months). Also, hours per function point (total number of project hours / number of function points delivered) is an industry-accepted, unit-of-work measure. It measures the number of hours required to develop one function point. An example of a financial indicator is the measure cost per function point (total cost/ total function points). It identifies the cost of each function point developed. This measure is often used to compare the cost of developing a system with the cost of purchasing a commercial package solution, or to compare internal cost with an external industry (benchmark) cost. Another financial indicator used in industry is portfolio asset value (cost per function point x total function points). It is used to track the value of an organizations entire portfolio of system software. Finally, quality indicators refer to defect density, repair costs, stability, defect rates, testing skills and reliability with regard to the software product. For instance, defect density [32] measures the number of defects identified across one or more phases of the development project lifecycle and compares that value to the total size of the application. This measure is calculated as: number of defects (by phase or in total) / functional size. Some examples of these measures are: repair cost ratio (Cost / Functional Size), Stability Ratio (1 - (#changes / functional size)), test proficiency (#defects / functional size). In addition, it is widely accepted that among the many factors that potentially affect the cost of software projects, software size is one of the key cost drivers [3] [4]. Therefore, we can also use functional size measures to estimate project cost, schedule and effort [5] [6] [7] . Garmus and Herron [32] discussed the use of a functional size measure at different organizational levels: first, at the project manager level for improving the accuracy of the time and cost of the project estimates. Second, at the IT management level as a normalizing measure in establishing performance benchmarks, and lastly, at the organizational level as the base measure for establishing quantitative service levels. With regard to the use of size measures for benchmark purposes, Reifer [33] published a study that provides software cost and productivity benchmarks for twelve application domains that can be used to know how well an organization compares to industry averages and whether their software estimates are reasonable.
32
1.3
Problem statement and research goal
The capability to accurately quantify the size of software at 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). Moreover, the advent of new technologies such as object-orientation and Web paradigms has created many problems that are related to how the software developed following these paradigms can be accurately sized. One of the most serious practical limitations of existing FSM methods is their inability to accurately size object-oriented systems. A number of approaches have been proposed in the literature to address this issue [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48], 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 [36] [37]. They do not consider all concepts of the OO paradigm (inheritance, aggregation, etc.) [30] [35] [38] [41] [42]. Most of them take into account only the static dimension of an OO system (i.e. the structural aspects commonly represented in an object model) and do not consider dynamic aspects like object interaction and object behaviour [30] [36] [44] [45].
Some proposals rather than use an ISO-standardized method like IFPUG FPA 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. The situation is even worse in Web projects. We agree with Reifer [49], that projects of this kind differ from traditional software projects. This difference comprises two key dimensions: the rate of releases is higher, and the extent of what is deployed in each release is smaller. The traditional balance between the project tradeoffs of time, cost, and quality is changing. The nature of Web development forces project managers to focus primarily on the time variable in order to achieve the required short cycle times. Because of this imbalance, several problems with Web projects have been observed such as exceeding budgets and unknown or bad product 33
quality [50]. To avoid a Web crisis, development approaches are needed that provide high-quality Web applications on time and within budget. In the last few years, several development methods have been proposed that specifically aim at Web application development such as OOHDM [51], WebML [52], W2000 [53] and OOWS [54] [55]. Of these proposals, those that start with a user-defined problem space representation (i.e. conceptual model) of the Web application seem to be the most promising. Adopting such a method, however, poses new problems to the Web project manager, in particular with respect to resource estimation and project planning. A fundamental problem in this context is the size measurement of the future Web application based on its conceptual model. The FSM methods used in industry (mainly FPA) date from a pre-Web era. None of the ISOstandardized FSM methods were designed taking the particular features of Web applications (i.e., navigation, presentation, personalization, etc.) into account. Hence, existing FSM methods need to be adapted or extended to cope with Web application development projects. Another problem is the fact that despite the wide usage of established FSM methods and the proliferation of newer ones for measuring OO systems or Web applications, no methodology for the systematic evaluation of the validity of the proposed functional size measures can be found in the literature. The validation of a measure is essential in order to be able to use it with confidence [29] [27]. In general, two approaches for measure validation have been employed in the software engineering field: theoretical validation and empirical validation. These two types of validation are used to demonstrate that a measure is actually measuring the attribute it is purporting to measure, and that a measure is useful in the sense that it is related to relevant software process or management variables, which it might be used for prediction purposes (e.g. software quality, maintenance effort). Although the principles of software measure validation are well accepted, there is yet little evidence of the validity of the functional size measures used in industry [56] [28] [13].
1.3.1
The OO-Method paradigm: from problem space to solution space
OO-Method [57] is an object-oriented method for conceptual modeling and automatic code generation. In fact, it is a model-driven development (MDD) approach, which comprises two models: the Conceptual Model and the 34
Execution Model. The OO-Method development process is automated by implementing the provided set of mappings between conceptual primitives (problem space) and their software representations (solution space). The Conceptual Model (see Figure 7) captures the relevant properties of an objectoriented system in a graphical way. It is based on the specification of four complementary conceptual schema views that follows an UML-compliant notation: Object Model: captures the static behaviour of the system in terms of classes identified in the problem domain and their relationships. Dynamic Model: captures the dynamic behaviour of the system in terms of valid object lives and interaction between objects. Functional Model: captures the semantics associated to the state changes of the objects. Presentation Model: captures the user interaction patterns for the system interface. Rather than just providing four notations for modeling different perspectives of the system, these conceptual models describe the OO systems functionality within a well-defined OO framework in an integrated fashion. The OO-Method notation can be considered a subset of the UML notation.
The OO-Method Approach
Problem Space Level
User Requirements
Obtain
OO-Method Conceptual Schemas

Object Model Dynamic Model Functional Model Presentation Model
Uses
Repository
Automated Translation
OASIS Formal Specification

Application Tier (COM+, CORBA) Persistence Tier (SQL Server, ORACLE) Interface Tier (Visual Environments, XML)
Solution Space Level
Figure 7. The OO-Method approach
35
This specification generates an OASIS (Open and Active Specification of Information Systems) formal specification [58] that acts as a high-level system repository. Once we have an appropriate system description, a welldefined Execution Model (in the Solution Space level) will fix the characteristics of the final software product in terms of user interface, access control, method activation, etc. According to the execution model, a software system that is functionally equivalent to the specification is built in an automated way. The code generation strategy is independent of any specific target development environment. The complete OO-Method development process was automated by a set of tools that are under development at CARE Technologies S.A. The Conceptual Model level is supported by the OlivaNova Modeler tool and the execution model is supported by the OlivaNova Transformation Engine tool. Nowadays, the currently supported software development environments where code is generated include Visual Basic and Java. Currently, in the OO-Method research group at the Valencia University of Technology, efforts are underway to extend OO-Method with the required expressiveness to develop Web applications. This extension is called OOWS (Object-Oriented Web Solutions) [54] [55]. It adds to the classical OOMethod framework (Object, Dynamic and Functional) two new conceptual schema views: Navigational Model: captures the navigational properties in terms of the valid paths that each user type can go through in the application. Presentation Model: captures presentation features of the application in terms of information layout, information ordering criteria and information access mode. It is a new conceptual model that is built on the base of the Navigational Model.
Following the OO-Method paradigm, the basic goal of OOWS is to obtain a precise specification that will be transformed into the corresponding software product (Web application). This process is currently being defined by implementing the provided set of mappings between conceptual primitives (problem space) and their software representations (solution space). This specification generates an XML document that acts as a high-level system repository. Furthermore, using a precise Execution Model, a Web application that is functionally equivalent to the formal specification can be generated in a semi-automated way. 36
1.3.2
Research goals
The primary research goal of this thesis is to provide a measurement procedure4 for sizing object-oriented systems from OO-Method conceptual schemas, according to IFPUG FPA. Our choice in defining a measurement procedure instead of defining a new FSM method is due to the fact that IFPUG FPA is the most widely used FSM method in industry and a standard approved by ISO. Consequently, the functional size measure obtained is comparable to a standard accepted in practice. There are some benefits to this, such as the definition of cost-estimation models and the execution of benchmarks since there are a lot of data available in the industry that were obtained using IFPUG FPA. This procedure consists of a set of measurement rules for modeling and sizing object-oriented software systems from conceptual model specifications obtained in the context of the OO-Method. With respect to measurement rules for modeling, we refer to rules that map the concepts used in OO-Method onto the concepts existing in the IFPUG FPA metamodel. Measurement rules for sizing are used to assign a numerical value for each concept identified in the OO-Method conceptual schema that is relevant to the functional size. A second goal is to extend the measurement procedure for sizing Web applications developed using OOWS. This will be accomplished by incorporating new measurement rules for modeling and sizing Web applications that take into account the specific features of this kind of artifact captured in the OOWS approach. As design science is not complete without evaluating the research outputs [59], this thesis also reports on the evaluation of the proposed measurement procedure. This will comprise: The validation of the design of the measurement procedure (theoretical validation) The validation of the application of the measurement procedure (empirical validation).
It is defined in the International Vocabulary of Basic and General Terms in Metrology [60] as a set of operations, described specifically, used in the performance of particular measurements according to a given method of measurement. A method of measurement is defined in this vocabulary as a logical sequence of operations, described generically, used in the performance of measurements.
37
By theoretical validation, we refer to the evaluation of the measures that are defined by the proposed measurement method. By empirical validation, we refer to the evaluation of the performance of the procedure and its likely adoption in practice using experimental techniques and statistical data analysis. In summary, our goal is to develop a comprehensive and systematic FSM framework for OO-Method and OOWS, comprising the design, the application and the evaluation of a new IFPUG FPA measurement procedure. The process model for software measurement proposed by Abran and Jacquet [25] will be used as the basis for such a framework. The research goals will be satisfied by dealing with the following subgoals: To study the ontological background of terms used in functional size measurement. Our intention is to define a measurement procedure that is compliant with the terminology defined in the ISO International Vocabulary of Terms in Metrology [60] and ISO/IEC 14143 [9] as well as the process model of Jacquet and Abran, and the generalized representation of Fetcke [13]. To study the different approaches that deal with FSM, especially those based on conceptual models due to their growing relevance in the literature for sizing software systems at an early stage of the development life cycle. To design a measurement procedure for sizing object-oriented systems from OO-Method conceptual schemas, according to IFPUG FPA. It should include the mapping rules between the OO-Method and IFPUG FPA metamodels and all subsequent tasks associated to functional size measurement. To extend the measurement procedure for sizing Web applications. It should include additional measurement rules and procedures for the proposed method based on the primitives of the OOWS approach. To apply the FSM method in the measurement of real systems. To validate the design of the proposed FSM measurement procedure to verify whether the measures used satisfy the representation condition of measurement. To validate the application of the proposed FSM measurement procedure in order to assess the degree of confidence in the measurement results.
38
1.4
Research environment
This thesis was developed in the context of the Research Group Logic Programming and Software Engineering in the subgroup Object-Oriented Methods for Software Development Group (OO-Method Group) of the Valencia University of Technology (UPV Universidad Politcnica de Valencia) in close collaboration with the company CARE Technologies S. A. The work presented in this thesis arises from the efforts of researchers at the OO-Method Group and a group of practitioners at CARE Technologies in which the author has actively participated since 2001. The results obtained from these efforts are being applied in case studies in academia and in real project measurement. Currently, there are great investments being made in developing tools to incorporate the technology in commercial software developments products through R&D contracts between UPV and CARE Technologies. The works that have made the development of this thesis possible are in the context of R&D contracts and R&D government projects. The R&D contracts are the following: Advanced OO-Method, CONSOFT S.A. and Valencia University of Technology, Main researcher: Oscar Pastor, From December 2002 to December 2003. Estimating the Functional Size of Object-oriented Systems, CARE Technologies and Valencia University of Technology, Main researcher: Silvia Abraho, From February 2003 to February 2004.
The R&D government projects are the following: Web Environment Engineering - (Ingeniera de Ambientes Web), Spanish National Agency, CICYT Project under grant TIC20013530-C02-01. From 2002 to 2004. WEST: Web-oriented Software Technology Task #2. Quality in the Development Process of Web Applications CYTED Project VII-18 (Iberoamerican Program for the Development of Science and Technology). From August 2000 to August 2003.
39
1.5
Research design
The research work presented in this thesis takes place in six phases, which are summarized in Figure 8. The first four phases relate to the definition of the FSM procedure, a field-testing to refine and improve the procedure, as well as its extension to size Web applications.
Figure 8. Summary of research design
The field-testing is carried out in the company CARE Technologies, where a CASE tool for the OO-Method approach is being developed. This phase consists of applying the proposed FSM procedure in practice using the action research approach. The experiences in practice are then used to improve the procedure as part of an ongoing learning and discussion process. Finally, the last two phases relate to the evaluation of the FSM procedure. First, the design of measurement procedure is validated using the prescriptions of the Measurement Theory and formal frameworks. Second, the application of the measurement procedure is validated using experimental techniques. Next, we describe the selection and the justification of the research methods used to perform each stage of this research work. 40
1.5.1
Selection of research methods
For the definition of the FSM procedure (Stage I), we applied action research. This is a collaborative approach suitable for testing new proposals for the mutual benefit of researchers and practitioners [61] [62] [63] [64] [65]. For the evaluation of the FSM procedure empirical validation (Stage II), we applied laboratory experiments. 1.5.1.1 Stage I
Action research is an alternative social science research approach which links theory and practice to solve practical problems. In general, qualitative research methods have proven to be appropriate for the Information Systems field [65]. It can be described as a research methodology which pursues action (or change) and research (or understanding) at the same time. It is usually described (see Figure 9) as cyclic (or spiral), with action and critical reflection taking place in turn. The reflection is used to review the previous action and plan the next one. It can be engaged in by a group of people who share an interest in a common problem. This research method involves the following seven-step process: selecting a focus, clarifying theories, identifying research questions, collecting data, analyzing data, reporting results and taking informed action. The process starts with the identification of a particular challenge or problem and then focuses upon specific questions which need to be answered. These questions then guide the type of literature and/or expertise that needs to be used. That increased knowledge then translates into the creation and use of assessments or data collectors to gather information from ones own culture or direct environment in order to continue the effort to answer those initial questions. Data is then objectively reflected upon and analyzed to determine the action steps required for improvement. In general, the application of action research for the definition of the FSM procedure consists of two major steps. First, we defined a FSM procedure called OOmFP (OO-Method Function Points) to answer the following question of: how to size object-oriented systems from OO-Method Conceptual Schemas, according to IFPUG FPA. Second, this procedure has been applied to the resolution of real problems on the part of diverse critical groups of reference (members of the OOMethod Group, practitioners of the CARE Technologies), and has produced 41
feedback to the researcher, who has served to refine the measurement procedure in successive iterations. The proposed FSM procedure was then extended to answer the question of how to size Web applications from OOWS Conceptual Schemas, according to IFPUG FPA. In the following, we explain in more detail how the FSM procedure proposed in this thesis has been put into practice using the action research method.
M3
Plan
M2
Plan
Reflect
Act
Observe
M1
1 Reflect
Act
Observe
Action Research Cycles
Figure 9. Action Research Phases
1.5.1.1.1 Participants In this type of research, all the parts involved participate by examining the existing situation in accordance with the intended objectives. Four types of roles exist: the researcher, the object, the critical group of reference and the external entities that benefit from the results. In this research work, these four roles correspond to the following: a. Researcher: the OO-Method research group composed by professors and researchers of the Department of Information Systems and Computation at the Valencia University of Technology. The author of this thesis is a member of the OO-Method research group. b. Object: the proposed FSM procedure (OOmFP) and its extension to sizing Web applications (OOmFPWeb). 42
c. Critical Group of Reference (CGR): practitioners in CARE Technologies, who participate in the measurement of real projects. d. Beneficiaries: they are the organizations that can be benefited by the results of this research work. That is, all those who develop software in the object-oriented technology. Specifically, the beneficiaries are the customers that contract the services of CARE Technologies. 1.5.1.1.2 Research process Action research is one of the few approaches that are valid to study the effects of specific alterations in development methods in human organizations [64]. Therefore, the definition of a FSM procedure that is applied in the context of OO-Method (a software automatic production method) is an appropriate domain to apply action research. We applied this research method taking into account the following conditions: 1) The researcher proposed a procedure that was accepted by the critical group of reference. 2) The researcher worked actively so that the benefits were mutual, that is, scientific benefits for the researcher, and practical benefits for the critical group of reference. 3) The obtained knowledge could be applied immediately. 4) The investigation was developed in a cyclical and iterative typical process combining theory and practice. Putting action research into practice during the research process of this work has meant a continuous feedback between the researcher and the critical group of reference. While the researcher studied the problems and proposed solutions, the CGR analyzed these solutions in their real work environment. Then, the obtained results were discussed together. In this way, each typical cycle (see Figure 9) that was carried out allowed us to obtain more refined measurement rules in a participative manner. These rules were analyzed and tested, and the results were used to improve the FSM procedure or to define new measurement rules. This confirms that the activities of the measurement process depicted in Figure 5 are not just linear. They have an interactive character: first, the measurement procedure is defined and then applied in practice. This provides relevant feedback that allows for the improvement of the measurement procedure definition. It also corresponds to the verification of the measurement procedure. 43
1.5.1.2
Stage II
There is an increasing understanding in the Software Engineering (SE) community that empirical studies are needed to develop or improve processes, methods and tools [66] [67] [68] [69]. Depending on the purpose of the evaluation, three different kind of empirical studies can be carried out: surveys, case studies and laboratory experiments. In Stage II, we use laboratory experiments as a research method to validate the application of a FSM procedure. Experimentation is a crucial part of the evaluation and can help determine whether the methods used are in accordance with some theory [67]. An experiment is more formal and rigorous when compared to the other strategies. We agree with Moody [70] that action research is a useful approach for testing and improving an approach in the first stages of its definition, but not to evaluate it or compare it with related approaches. Experiments are appropriate for investigating different aspects such as confirming or testing existing theories, evaluating the accuracy of models, or validating measures, etc. Engineering disciplines are founded on a scientific body of knowledge. For this body of knowledge to be considered scientific, its truth and validity must be proven. Empirical studies have traditionally been used in the social sciences and psychology. However, the need for more empirical studies in the field of SE has been put into evidence. According to Basili [66] [71] SE can be a laboratory of science in which the researchers role is to understand the nature of the processes and products in the context of the system, and the practitionerss role is to build systems using knowledge. In their study of 600 papers, where new methods and technologies were proposed, Zelkowitz and Wallace [67] observed that: (a) too many papers have no experimental validation at all, (b) too many papers use an informal form of validation (lessons learned or case studies are used about 10% of the time), and finally, (c) experimentation terminology is sloppy. Tichy [68] discussed some arguments used to explain the lack of experimentation in the computer science field. He concluded that only experiments test theories and without them, computer science is in danger of drying up and becoming an auxiliary discipline. Kitchenham et al. [69] presented a set of preliminary guidelines for Empirical research in Software Engineering. These guidelines are based on medical guidelines. Their aim is to assist researchers in the design, conduct, and evaluation of empirical studies. 44
Finally, some frameworks for performing empirical studies in the Software Engineering field have been proposed [72] [73]. These frameworks are useful in evaluating new software engineering techniques. To design laboratory experiments in this thesis, we used the framework for experimental software engineering of Wohlin et al. [72]. The experimental process underlying this framework is introduced below. 1.5.1.2.1 Experimental Process Figure 10 illustrates the main activities contained in the experiment process suggested by Wohlin et al. [72]. The experiment definition is the first activity where the experiment is defined in terms of problem, objectives and goals. The intention is to explain why the experiment is being conducted. Commonly, the Goal/Question/Metric (GQM) template [74] for goal-oriented software measurement is used as follows: Analyze <Object(s) of study> For the purpose of <Purpose> With respect to their <Quality Focus> From the point of view of the <Perspective> In the context of <Context>
Figure 10. Overview of the experiment process (Source: [72])
45
The object of study is the entity that is being studied. It can be products, processes, models, resources, etc. The purpose describes what the intention of the experiment is. For instance, the purpose of an experiment can be to evaluate the use of different methods. The quality focus describes which effect is studied. Examples of quality focus are: usability, effectiveness, reliability, maintenance, etc. The perspective describes what the view of the experiment is. An experiment can take the perspective of the analyst, developer, tester, researcher, manager, amongst others. Finally, the context describes where the study is conducted (the environment). It includes the description of the people (i.e., students, practitioners) and software artifacts involved in the experiment. The experiment planning is the next activity, where the design of the experiment is determined. Here, the subjects of the study are identified, the hypothesis of the experiment is stated formally, and the independent and dependent variables are determined. The intention here is to explain how the experiment is conducted. Furthermore, the choice of the experiment design and the instrumentation used need to be justified. The design describes how the tests are organized and run (i.e., on-line/off-line, randomization procedure, etc.). In the operation of the experiment, measures are collected. This activity has three steps: preparation, execution and data validation. The first step consists in preparing the subjects and the material needed. The second step consists in ensuring that the experiment is conducted according to plan. In the third step, the collected data is revised to make sure that it is complete and valid. In the analysis and interpretation, the collected data is analyzed and interpreted. As an informal analysis, the data is first analyzed using descriptive statistics. If necessary, the data is then reduced either by removing data points or by reducing the number of variables (if more than one variable provide the same data). After some data has been removed, the hypotheses are tested using the appropriate parametric or non-parametric tests. We can only draw conclusions on the influence of the independent variables on the dependent variables if the null hypothesis is rejected. Finally, the presentation and package activity is related to preparing documentation (i.e., research paper, lab package) with the experiment findings. It is very useful for replication purposes or as part of an experiment database.
46
1.6
Thesis outline
The remainder of this thesis is organized in the following chapters: Chapter 2. Literature Review This chapter contains a review of the state-of-the-art in functional size measurement for Object-Oriented systems and Web applications. Our intention is to discuss the strengths and weaknesses of these proposals. Chapter 3. Foundations This chapter introduces the OO-Method approach. First, the conceptual model level is described including each one of its four complementary views: Object, Dynamic, Functional and Presentation Models. Then, a brief introduction of the OASIS formal specification language is explained. This is followed by the description of the Execution Model that allows the automatic code generation of a system by compiling the information contained in the conceptual model views. Later, the OOWS approach is presented as an extension of the OO-Method approach to develop Web applications. Chapter 4. A Functional Size Measurement Procedure for ObjectOriented Systems: The OOmFP Approach This chapter introduces OO-Method Function Points (OOmFP) as a suitable approach to sizing object-oriented systems from OO-Method conceptual schemas. OOmFP is designed by mapping the concepts defined in the IFPUG FPA metamodel to the modeling primitives of the OO-Method approach. We present the design of OOmFP and its application in a case study following the steps of the process model for software measurement proposed by Jacquet and Abran [26]. We also describe how the action research improved the design of OOmFP. Chapter 5. Extending OOmFP for Sizing Web Applications This chapter discusses the differences that exist between traditional software development and Web development projects. Then, an extension of OOmFP for sizing Web applications (OOmFPWeb) is 47
proposed. We present the design of the measurement method and its application in a case study. Chapter 6. Validation of the Design of the Measurement Procedure This chapter presents the first steps towards the theoretical validation of the functional size measure used by OOmFP. This attempt of validation is conducted using a formal framework called DISTANCE (Poels and Dedene, 1999) for software measure construction that satisfies the measurement needs of empirical software engineering research. In addition, we discuss the problems that were encountered when theoretically validating a FPA-compliant measure. Chapter 7. Validation of the Application of the Measurement Procedure This chapter justifies the need for experimental evaluation of the proposed FSM method. We examine the theoretical models proposed in the IS research field to provide an overview of the theories used to predict and explain the acceptance of information technology. Then, a theoretical model and associated measurement instrument for evaluating FSM methods is proposed. It is used as the theoretical basis for the laboratory experiments presented in the following two chapters. Chapter 8. Experiment 1: Comparative Evaluation of OOmFP against IFPUG FPA This chapter describes a laboratory experiment which evaluates the efficiency, effectiveness, and likely adoption in practice of OOmFP for sizing object-oriented systems developed using the OO-Method approach. The proposed method is evaluated in comparison to the IFPUG FPA, an ISO-standardized-FSM method. Chapter 9. Experiment 2: Evaluating the Efficiency and Acceptance of OOmFPWeb This chapter describes a laboratory experiment which evaluates the efficiency, effectiveness, and likely adoption in practice of OOmFPWeb for sizing Web applications developed using the OOWS approach.
48
Chapter 10. Conclusions and Further Research This chapter presents the main contributions of this thesis. Current and future research works, as well as the publications originated from this research work, are also presented. Appendix A. Experimental Materials This appendix summarizes the materials used to carry out the experiments described in Chapters 8 and 9. The materials used in the first experiment consist of a requirement specification of a case study, and measurement guidelines for IFPUG FPA and OOmFP. Finally, the materials used in the second experiment consist of an OOWS conceptual schema, the OOmFPWeb measurement guidelines, and a form to collect the data. Appendix B. Survey Instrument used in the Experiments This appendix contains the measurement instrument that we use in the laboratory experiments to measure the perception of subjects using FSM methods. Appendix C. Measurement Results This appendix illustrates all the data we have collected in the experiments described in Chapters 8 and 9.
49
Part I
The Design of the Functional Size Measurement Procedure
When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind. (Lord Kelvin, Popular Lectures and Addresses, 1889)
Chapter 2
Literature Review
This chapter provides a review of the state-of-the-art in functional size measurement for object-oriented systems and Web applications. In the following, we discuss the strengths and weaknesses of the proposed FSM methods.
2.1
Functional size measurement for objectoriented systems
According to reported industry experience, FPA has also been used for sizing Object-Oriented systems [32] [75]. We agree with Dekkers and Cartwright [75] that in OO systems development, functional user requirements are captured in a different way (using OO methods and techniques). Though it is certainly possible to size these functional user requirements using FPA, a number of FPA variants and extensions have been proposed for the specific purpose of sizing OO systems, primarily because of its wide acceptance in industry. We group these approaches into three categories of FSM methods for OO systems. A first category is composed of FSM methods that are compliant with IFPUG FPA. A second category contains FSM methods that are not compliant with IFPUG FPA, but take a view on functional size that is related to the IFPUG FPA view. Apart from these two approaches, there is a third category of FSM methods that take a fundamentally different view on functional size by no longer distinguishing between data and transactions, but consider the object (actually the class definition of an object) as the main item
Chapter 2. Literature Review
that contributes to functional size. In the following subsections, we review the proposals in these three categories according to their: Category. FSM method or measurement procedure. By FSM method we refer to those proposals that provide a new way to model the elements that contribute to the functional size of a system (i.e., define a new metamodel). By measurement procedure we refer to those proposals that take an existing metamodel (e.g., IFPUG FPA [14]) and adapt it to a specific context of use. If the proposal is a measurement procedure, the name and the release of the FSM method used is provided. Input artifact. Artifact(s) used as input for measurement. Abstract model: A brief overview of the concepts used to model the elements which contribute to functional size (only applicable for FSM methods). Measurement process: A brief overview of the steps used to apply the FSM method (only applicable for FSM methods). Mapping and measurement rules. A brief overview of the mapping and measurement rules defined to operationalize the measurement procedure (only applicable for measurement procedures). Functional domains. Class(es) of software that the proposal is suitable for. Examples of functional domains are: Management Information Systems (MIS), Real time embedded (RT), and Algorithmic/Scientific (A/S), etc. Tool support: description of the tool that implements the FSM method. Validation procedure. Description of the procedure used to validate the proposal. It can be case studies, pilot projects, empirical studies using students, or empirical studies using practitioners, etc. Empirical data. Amount of published data that supporting the FSM method. Actual usage. Context in which the FSM method is being used. It can be a multi-company (a company with more than one branch in a country and/or across the world), a local company (in a city), a consulting company, in-house (in the company where the proposal was defined), or an academic environment.
54
2.1.1 First category

This section contains the FSM procedures that are compliant with IFPUG FPA. They reformulate the IFPUG rules in terms of OO concepts to facilitate the function point counting process. The result of a size assessment is (or should be) the same as what would have been obtained by directly applying IFPUG FPA. In this category, we find a proposal of IFPUG [30], and other proposals by Lehne [42], Fetcke [43], and Uemura et al. [76]. 2.1.1.1 The IFPUG proposal (1995)
The International Function Point Users Group (IFPUG) published a case study [30], which illustrates the application of the IFPUG FPA counting rules to an object-oriented analysis and design. This case study uses Object Models in which the methods of classes are identical to the functions specified in the requirements document. Under this assumption, methods can be directly counted as transactions. The general information for this proposal is: Category. FSM procedure Input artifact. Depends on whether the measurement is made in the analysis or construction phase. In the analysis phase, user requirements, generic class diagrams and/or use case diagrams can be used. On the other hand, in the construction phase, updated user requirements, object-oriented class diagrams and/or use case diagrams as well as graphical user interface (GUI) windows can be used. Mapping and measurement rules. In the case study published by IFPUG, the input artifact is an Object Model. The classes are considered as ILFs and the methods of classes are identical with the services recorded in the requirements. Under this assumption, the methods are considered as transactions. Functional domains. MIS Tool support. No Validation procedure. Not mentioned. Empirical data. Not found Actual usage. Primarily used by consulting companies (The David Consulting Group, Galorath, and Longstreet Consulting) for training purposes. 55
2.1.1.2
The Lehne proposal (1997)
Lehne [42] presents an experience report in function point counting for object-oriented analysis and design using a method called OOram [77]. This method is based on the concept of role, for performing object-oriented modeling. The structures of roles, called Role Models in OOram, define a family of UML models [78]. OOram supports the following nine views on the role model, namely: area of concern view, stimulus-response view, relation view, collaboration view, interface view, scenario view, process view, state diagram view and method specification view. The mapping between FPA concepts and the primitives of the OOram conceptual models is established by identifying the ingoing/outgoing messages of the application as transactional functions (EIs, EOs and EQs). FTRs are identified as the number of objects/roles. Internal logical files (ILFs) are identified based on the information objects / roles in the Collaboration Diagram. Finally, external interface files (EIFs) are not taken into account. The general information for this proposal is: Category. Measurement procedure for applying IFPUG FPA to OO systems modeled with OOram. The version of the FSM method used was not specified. Mapping and measurement rules. A collaboration diagram is used for identifying the data functions. However, the artifact (product of the different OOram views) that should be used for identifying the transactional functions is not mentioned. Functional domains. MIS Tool support. No Validation procedure. Not described Empirical data. Not found Actual usage. In-house (Taskon) and other multi-companies based in Norway (Det Norske Veritas, Exxon, Brown & Root, Agip, Statoil, and The Norwegian Research Council). The Fetcke et al. proposal (1998)
2.1.1.3
In 1998, Fetcke [43] demonstrated the applicability of FPA as a FSM method for OO specifications. He suggested a mapping to the OO-Jacobson method 56
(based on use cases) [79] starting from an abstract Function Point Model. This mapping has been formulated as a small set of rules that support the IFPUG counting rules. The main features of this proposal are: Category. Measurement procedure for applying IFPUG FPA when using the OO-Jacobson method. It was used the Function Point Counting Practices Manual, release 4.0 [80]. Input artifacts. Use case and domain object models Mapping and measurement rules. First, the use case model is used to identify the system boundary, the users, and the external systems that interact with the system being measured. The same model is used to identify one or more transactional functions for each use case. FTRs are identified for each object maintained and/or read by a use case. Then, the domain object model is used to identify data functions. Attributes of objects are candidates for DETs and a domain or entity object that is aggregated into another object or super-objects in a specialization relationship are candidates for RETs. Functional domain. MIS Tool support. No Validation procedure. Case studies Empirical data. Results of the measurement procedure application in three industry projects (Ericsson company) were reported. Little data available. Actual usage. Unknown. The Uemura et al. proposal (1999)
2.1.1.4
Uemura et al. [76] proposed a set of FPA-based measurement rules for measuring design specifications based on UML (Unified Modeling Language)[78]. UML is a graphical language for specifying and documenting the artifacts of a software system. It provides different diagrams to capture complementary perspectives of an OO system. These diagrams are divided into three categories: static structure diagrams, behavior diagrams and implementation diagrams. Static structure diagrams describe the structure of the system and include class diagrams. Behavior diagrams describe the dynamic (behavior) perspective of the system and include use-case diagrams, interaction 57
diagrams, sequence diagrams, collaboration diagrams, state diagrams and activity diagrams. Finally, implementation diagrams provide the information of source code and include component diagrams and deployment diagrams. The general characteristics of the Uemura et al. proposal are: Category. Measurement procedure for applying IFPUG FPA to UML design specifications. The procedure was defined using UML version 1.1, IFPUG version 4.0, and Rational Rose version 4.0. Input artifacts. The proposed rules are based on only class and sequence diagrams. Mapping and measurement rules. Sequence diagrams are used to determine the counting boundary. That is, actor objects are considered outside the boundary and the other objects are considered inside the boundary. Then, data functions are identified based on the information of both diagrams. Objects that have operations that change the attributes of other objects are considered as ILFs. Others objects are considered as EIFs. The authors stated that RETs cannot be identified from the class and sequence diagrams. For this reason, they always consider the RET to be one. Finally, transactional functions are identified for each of the messages that are exchanged by the object specified as data function in the sequence diagrams. Functional domains. MIS Tool support. A measurement tool was constructed to automate the measurement procedure, whose input products are design specifications developed using the Rational Rose CASE tool. Validation procedure. The first results of the tool application in three projects were reported [76]. These results were also compared to the results obtained by a FPA specialist of a software organization, who manually sized the same specifications. The authors observed that, for the data functions, the tool results are quite similar to the specialists results, whereas for the transactional functions some differences were found. In a second study [48], the authors assumed four conditions in the UML diagrams in order to adjust the differences observed in the previous study. Then, they concluded that the FPs automatically obtained from the UML documented specifications were closer to the values obtained by the specialist. Empirical data. Little data available. Actual usage. Unknown.
58
2.1.2 Second category

This category contains FSM methods that are not compliant with 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 which is similar to but not the same as that of IFPUG FPA. The count that is obtained would, however, not be considered a valid count according to the IFPUG rules for FPA. In the second category are the proposals of ASMA [38], Kammelar [46], Antoniol and Calzolari [44], and Ram and Raju [47]. 2.1.2.1 The ASMA proposal (1994)
The Australian Software Metrics Association (ASMA) [38] follows an approach similar to that proposed by Whitmire. Methods that implement services that are delivered by objects to the client are considered as transactions. The complexity of methods is weighted based on the number of accessed attributes and inter-object communications. Objects are treated as files, with their attributes determining their complexity. The main features for the ASMA proposal are: Category. FSM method. Input artifact. Object Model Abstract model. The concepts in the FPA metamodel is extended to measure OO systems. The main feature of this approach is the clear distinction between the client and the supplier domains, where a supplier provides functionality to its clients across an application interface. Then, the objects that are logically visible to the client contribute to the external size of the system. On the other hand, the services and objects that are not logically visible to the client domain contribute to the internal size of the system. This method considers the following function types: Input Services, Output Services, Inquiry Services, Object Data and External Interface File, which are defined by mapping the concepts existing in the FPA metamodel (EI, EO, EQ, ILF and EIF, respectively). Measurement process. Four sizes can be obtained from these function types: Functional Size (FS), Internal Size (IS), Application Size (AS), and Object Size (OS). They are calculated as follows: 59
FS = ExtObjectDataCompl + ExtServiceCompl + EIFw

IS = IntObjectDataCompl + IntServiceCompl
AS = FS + IS + ObjectSize
OS = ObjectDateCompl + ServiceCompl
2.1.2.2
All sizes are measured in units of Object Points (OP). However, for the functional size (FS) measure, object points are equivalent to unadjusted function points. It implies that if only FS is calculated, the ASMA proposal is a measurement procedure for FPA. However, because it includes other size measurements, it is also a FSM method in its own right. Basically, the object data complexity is measured in terms of attributes and relationships with other classes, whereas the service data complexity is proportional to the number of communications a service has with other objects and the number of attributes it accesses. Finally, a weighting table for object data complexity was defined. The weighting table for services were taken from IFPUG transaction weights. Functional domains. MIS Tool support. No Validation procedure. Not described Empirical data. Not published Actual usage. Unknown. The Kammelar proposal (2000)
In the Kammelar proposal [46], the functional size is expressed in Component Object Points (COPs) obtained from elements which may be candidates for reusable software components. The main features for this proposal are: Category. FSM method. Input artifacts. Two counting types are distinguished: analysis count and design count. In both counting types the following specifications are required: business processes (workflow diagrams, activities/use
60
cases, tasks/services), business object model, class diagram, relation service/class (use cases, class/collaboration/sequence diagrams), object life cycle diagrams, and interfaces with other applications. Abstract model. A conceptual size model is proposed to represent the entities that determine the functional size of an OO system. These entities are organized in the User Domain and the System Domain which are separated by the user interface. The user domain comprises the elements that can be determined from the Functional User Requirements (FURs) and they are independent of the implementation choices the business process, use case and business object. The system domain comprises elements by which the FURs are implemented. These elements can vary according to the chosen implementation environment (e.g., services, class and operations / transformations). The authors also proposed several matrixes to identify the number of COPs depending on the elements that contribute to the functional size. Measurement process. The first step is to choose the type of counting (analysis or design). Then, the counting boundary is identified by applying the same rules proposed by Fetcke [43]. In the third step, the specifications used to measure are revised to verify their degree of detail and consistency. This is followed by the identification and valuation of: use case services, service /class relation (analysis count only), objects, classes and object structures, and operations & transformations (design count only). For instance, the counting rules for use case services (analysis count) are: Decompose the use case activities into services Count 2 points per service (COPs); summarize per use case After identifying all functions and determining their size, the next step is to determine the reusable elements. This step is strongly dependent on the development environment. Finally, the last step is to determine the total size of the application. It is derived by adding the service functionality to the class functionality. Functional domains. MIS Tool support. No Validation procedure. No example illustrating the rules of the method is mentioned. 61
2.1.2.3
Empirical data. Not available. Actual usage. Unknown. 3-D Function Points (Whitmire, 1996)
In 1996, Whitmire [81] proposed 3-D Function Points, an extension of FPA to OO systems. This proposal measures three dimensions of a software project: data, control and functionality. This is accomplished by adding transformations (algorithms) and transitions (changes in application state) to the conventional FPA focus on data. While 3D Function Points method addresses many of the problems encountered using traditional FPA (and it measures different dimensions of functionality), size measurement is only accomplished at the class level. Whitmire provides updated FPA tables for determining the complexity of input and output entities in OO software and a new table for the complexity of transformations. Transitions are assumed to have an average complexity. The general characteristics of the method are presented below: Category. FSM method. It based on the original FPA method proposed by Albrecht [12]. Input Artifact. Class diagram. Abstract model. This approach takes into account three dimensions of a software project: data, control and functionality. The data dimension is measured according to the IFPUG FPA version 4.0 (1994). The functional dimension is measured based on the number of process steps and the set of semantic statements (i.e., invariants, that manage the operations) that are called Transformations (T). It must alter data or create new data. The control dimension represents the dynamic behaviour of the system in terms of a set of unique states and transactions. In addition, as in FPA, this method provides a weighting table to classify the complexity of transformations as low, average and high. For the states and transactions, there is only one level of complexity, which is 1. Measurement process. The data dimension (DD) is calculated as follows:
DD = EIW + EOW + EQW + ILFW + EIFW
Then, the functional dimension (FD) is calculated: 62
FD = TW
This is followed by the calculation of the control dimension (CD):

CD = S + R
Finally, the total size of a system is calculated as the 3D Function Point Index (3DFPI):
3DFPI = DD +FD +CD
Functional domains. Management information systems, scientific and real-time domains. Tool support: No Validation procedure. Not found Empirical data. Little data available Actual usage. Used in the context of the company Boeing. However, no data was published outside the company. Object-Oriented Function Points (Antoniol and Calzolari, 1998)
2.1.2.4
Antoniol and Calzolari [44] proposed Object-Oriented Function Points (OOFP), a FSM method for applying IFPUG FPA to OO systems. Measurement rules were proposed based on the elements of a static Object Model. One relevant aspect of this method is its flexibility. An organization can experiment with several measurement procedures and find the one that is best suited to its environment. The general characteristics of this proposal are: Category. FSM method for applying IFPUG FPA to generic objectoriented methodologies. We consider OOFP as a method since it simplifies the IFPUG FPA metamodel. It was defined using the IFPUG counting practices manual release 4.0 [80]. Input artifact. Object Model. Abstract model. The system boundary is an imaginary line in the Object Model, which separates the classes belonging to the system from the classes outside the system. Classes in the Object Model are identified as ILFs. External classes correspond to parameterized classes, which encapsulate non-system components. In the identification of ILFs four perspectives are proposed based on 63
different choices of how to deal with aggregations and generalization / specialization relationships. These perspectives are: single class, aggregations, generalization / specialization and mixed. The weight of each logical file also depends on the number of data element types (DETs) and record element types (RETs). Transactional functions are treated as generic Service Requests (SRs) between objects. Thus, this approach does not distinguish the three categories of transactional functions (input, output or inquiry) existing in IFPUG FPA. Measurement process. OOFPs are defined to be a function of objects based on a given Object Model produced at design phase or extracted from the source code. They are calculated as follows:
OOFP = OOFPILF + OOFPEIF + OOFPSR

where,
OOFPILF =
o A
ILF
( DETo , RETo )
OOFPEIF = W EIF ( DETo , RETo )

o A
OOFPSR = W SR ( DETo , FTR o )

o A
A denotes a set of objects belonging to the system being measured and o is a generic object in the Object Model. W are complexity matrixes to determine the complexity of each function type.
The measurement process with OOFPs contains four steps. First, the Object Model is analyzed to identify the classes, parametrized classes and generic Service Requests. Then, the complexity for each one of these elements is determined (low, average or high). To do this, the IFPUG weighting table is used [80]. In the following step, the complexity scores are translated into values. Finally, the values are summed to produce the final functional size. Functional domains. MIS Tool support. The process for sizing with OOFP has been automated using an intermediate language called Abstract Object Language (AOL), which is based on the UML language. This process starts when an Object Model specification is produced using a CASE tool. Then, this specification is translated in an AOL specification. Lastly, the AOL specification is parsed producing an Abstract Syntax Tree
64
2.1.2.5
(AST), to which the counting process is applied in order to produce the functional size of the OO system. One translator was implemented to convert the output from OMT to an AOL specification. Validation procedure. A pilot study was conducted in a specific company to test the different strategies for identifying ILFs. The results suggest that the best size prediction was obtained with the generalization strategy. However, given the lack of statistical evidence, the authors suggest that for this organization there is no reason to prefer one strategy over another. Empirical data. Little data available. Data from eight sub-systems of a software system was reported. Actual usage. Unknown. Object-Oriented Design Function Points (Ram and Raju, 2000)
Ram and Raju [47] proposed Object-Oriented Design Function Points (OODFP) as a FSM method to apply IFPUG FPA in the measurement of OO systems. This proposal considers all the concepts of OO systems such as inheritance, aggregation, association and polymorphism. It takes the designers perspective (instead of the users perspective) and considers two factors: the functionality of the OO system and the complexity of each class, which depend on the problem domain. The main features of OODFP are: Category. FSM method for applying IFPUG FPA to object-oriented systems. As in OOFP, this proposal simplifies the IFPUG FPA metamodel. It was defined using the IFPUG counting practices manual release 4.1 [14]. Input Artifact. Object Models in the design development phase. Abstract model. At the design phase, a logical file (ILFs or EIFs) is considered as a collection of data elements which are visible to all methods of a class. The complexity of a logical file is also assessed based on the number of RETs and DETs. In contrast to other proposals such as OOFP [44], the inherited data is considered as part of the complexity of derived classes. On the other hand, transactional functions are identified based on the class methods. Nevertheless, the 65
inherited method is not considered, as it is coded only once. Again, as in OOFP [44] this proposal does not distinguish different types of transactions. The complexity of a transactional function is also assessed based on the number of FTRs and DETs identified through the methods signature. OODFP uses the same complexity tables provided by the IFPUG [14]. As mentioned above, this proposal also considers the complexity of each class that is classified as: low (if a class processes less than 50% of data), average (if a class processes 51% to 70% of data) or high (if a class processes more than 70% of data). These values are mapped to a numerical value where low is 0.3, average is 0.6, and high is 0.9. Measurement process. Overall, the unadjusted OODFP of a class is obtained by multiplying the size of the class in the design (as in FPA) with its complexity value. Finally, the unadjusted OODFP of the OO system is obtained by adding all unadjusted OODFP of the system classes. Functional Domains. MIS Tool Support. No Validation Procedure. Case study - OODFP was applied in eight development projects (with sizes between 27-110) in comparison to OOFP. Empirical Data. No data available. Only the final sizes were reported. Actual Usage. Unknown.
2.1.3 Third category

Finally, this category contains the FSM methods that take a fundamentally different view on functional size, where the object is the main item that contributes to functional size. In this third category are the proposals of Laranjeira [35], Banker [36], Rains [37], Thomson et al. [39], Zhao and Stockman [40], Sneed [41], and Minkiewicz [45].
66
2.1.3.1
The Laranjeira proposal (1990)
Laranjeira [35] reviewed traditional FSM methods. His study showed difficulties in applying FPA to non-business information systems. Consequently, he proposed a FSM method based on layers of abstractions. Increasing levels of detail are revealed at each layer leading to more precise estimates. Laranjeira suggest that using an object-oriented representation of software allows an earlier estimation of size and development effort due to the fact that implementation of the system will correlate more directly with its specification. The main features of the Laranjeira proposal is described below: Category. FSM method. Input artifact. object-oriented functional model. Abstract model. The way to estimate the size and complexity of an OO system starts with the identification of object classes, methods and interfaces from a high-level natural language description of the system (requirements document). Measurement process The size estimation process whose functional model is characterized by a number of levels of decomposition may be summarized in the following steps: Beginning at the lowest level of decomposition, evaluate the size of each object by considering each function executed by the object as well as the data structures of the object. Continue to higher levels taking into account that object sizes may receive contributions of component objects. Include utility objects to account for housekeeping functions. Finally, the estimated size of the whole system will be the sum of the size estimates of the objects at the top level of decomposition plus the size of possibly existing utility objects. Functional domains. MIS Tool support. No Validation procedure. The only evaluation is a demonstration proof (by Laranjeira himself) on two projects. Empirical data. 16 small- to medium-sized projects. Actual usage. Unknown. 67
2.1.3.2
Object Point Analysis (Banker, 1991)
Object point analysis (OPA), which was introduced by Banker [36], is similar to function points except that object counts are used instead of function counts. Although this method has other applications, it was primarily used in development environments using integrated CASE tools. The general characteristics of OPA are: Category. FSM method. Input artifact. instructions and procedures written in CASE tools high-level language or third-generation languages (3GL). Abstract model. Two object-based measures are obtained from these object types. The first, object-counts, is merely a sum of the number of instances of each object type and is analogous to FPA. It includes the following four object types: Rule sets: a collection of instructions and routines written with a CASE tools high-level language. These are analogous to programs when 3GL such as FORTRAN or COBOL are used. Third generation language modules: existing procedures written in a 3GL. Screen definitions: logical representations of on-screen images. User reports: specific types of reports. The second, object-points, is determined by weighting each object type by the development effort associated to it. Measurement process. Object points are the sum of object instances for each type multiplied by an effort weight for each type. The average effort weights for each type are as follows: Rule Sets-3 Days, 3GL Modules-10 Days, Screen Definitions-2 Days, and User Reports5 Days. Therefore, object points are an estimation of effort needed for an integrated CASE tool development environment. Functional domains. MIS Tool support. No Validation procedure. A comparison between OPA and function points was performed. The authors conclude that the correlation between the function point metrics and the object-based metrics
68
2.1.3.3
(object-counts and object-points) were lower (0.889 maximum). This could indicate that the proposed metrics are not good measures of the functionality of an OO system or that the proposed OO metrics complement function points by measuring a construct that is ignored by function points. They also examine the quality of the development effort estimates produced by the metrics. However, this is not relevant for the purpose of our analysis. Empirical data. Data from nineteen software development projects from a single organization were provided. Actual usage. Unknown. Object Workload Analysis Gauge (Rains, 1991)
Rains [37] proposed Object Workload Analysis Gauge (O-WAG) to measure the size of an object. It is based on the features of an Ada package specification. The main characteristics of this proposal are: Category. FSM method. Input Artifact: Programs written in the ADA language Abstract Model. The following concepts are considered as contributing to the size of an OO system: attributes, operations, exceptions, withs, constants, and used bys. Measurement process. The concepts in the abstract model are multiplied by their weights and summed to obtain the relative size of each object in the system. Withs, constants and used bys are considered as having a weight of 1, attributes and exceptions as having a weight of 2, and operations as having a weight of 3. Rains also suggests some extrapolations to project scheduling when the object sizes have been determined. For instance, a class with 4 attributes, 5 operations, 1 exception, 2 withs, 3 constants, and used by three other packages has an O-WAG of 33. He suggests that an object with an O-WAG size of 21 will take a week to implement. Functional Domains. MIS Tool Support. No Validation Procedure. No Empirical Data. No data available. 69
2.1.3.4
Actual Usage. Unknown. The Thomson et al. proposal (1994)
In the proposal of Thomson et al. [39], each system requirement is expressed as a single abstract functional capability (expressed in use cases) that is measured using a set of metrics: number of use cases, events, classes, etc. The main features of the Thomson et al. proposal are: Category. FSM method. Input artifact. Use case models. Abstract model. Three levels of metrics are identified based on the system requirements in terms of use cases, system interactions in terms of events and messages, and classes in terms of objects, methods and attributes. Measurement process. At requirements level, the following metrics are collected based on use case models: # detailed scenarios or use cases per capability, # work items (system level jobs, changes to subsystems, etc.). Then, these elements are rated as having a low, average or high level of complexity. Other metrics are also proposed to measure the size delivered in terms of interactions (i.e., # new public messages, # new/changed system data) and class (i.e., # new/ modified class, # new/changed attributes). In addition, some weighting factors are suggested to adjust the size measurement such as the customers priorities, number of customers that require the capability, and the impact on the customer (critical, high, low). However, no procedures are proposed to assess these factors. The measurement process is not explicitly explained and no measurement example is provided. Functional domains. MIS Tool support. No Validation procedure. No example is shown to explain the approach. Empirical data. No data available. Actual usage. The method was proposed by Bell-Northen Research Limited in Canada. It is currently being used inside this company.
70
2.1.3.5
Object-Function Point Analysis (Zhao and Stockman , 1995)
Zhao and Stockman [40] proposed Object-Function Point Analysis (OFPA) as an extension of the Laranjeira approach with physical size factors and reuse size factors. OFPA predicts software size from user requirements (similar to FPA), but assumes a different view (called OFPA size model), which is based on the OO paradigm. Another particular feature of this approach is that the functional size can be adjusted for reuse. Then, three kinds of size are obtained based on the analysis of size factors: total size, reused size and final size. Category. FSM method. Input artifact. No specific artifact is described, only the development phase in which the size measurement can be applied (requirement analysis and design). Abstract model. Corresponds to the OFPA size model. According to Zhao and Stockman there are a set of factors that influence the software size. They classified these factors in the following way: physical size factors, logical size factors and reuse size factors. The physical size factors are those that directly influence the software size such as the total number of objects, total number of methods the average number of SLOC per method, etc. The logical size factors are those that reflect the degree of complexity of the software. Examples of these factors are: the total number of message paths, total number of inheritance and composition structures in a system, etc. Finally, the reuse size factors such as the number of reused internal and external objects, number of reused internal attributes, etc. Measurement process. It corresponds to a set of algorithms for calculating OO software size based on an assumed general OO model. According to this model, the total size (basic or detailed) is the estimated size for the whole software system. The basic total size is the sum of the total number of objects, attributes, methods and rules identified in a system. The detailed total size is estimated by adding the complexity factors to the basic total size. These complexity factors are considered the average depth of the inheritance and decomposition trees in the system as well as the number of children objects in the system. The reused size estimation is made by identifying reused objects in the system. Finally, the final size is the total size minus reused size. 71
2.1.3.6
Functional domains. MIS Tool support. No Validation procedure. No example or case study that described the method application was found. Empirical data. No data available. Actual usage. Unknown. Object-Points (Sneed, 1996)
Object-Points proposed by Sneed [41] are measured by weighting the following elements: object types, object attributes, object relations, methods, messages, parameters in messages, message source, message destinations and percentage of reuse. The obtained value is weighted using 10 influential factors. The main features of the Sneed proposal are: Category. FSM method. Input artifact. Object-Points measure three dimensions of the OO systems: objects, communication and process. This information is captured in three different models that are used as input: the Object Model, the Communication Model and the Process Model. Abstract Model. In the Object Model, the relevant information that contributes to the system size is the class and its properties. In the Communication Model, the main entities are messages or interfaces derived from the interface analysis. In this model, the following contribute to size: type of messages, complexity rate, number of parameters, number of sources, number of targets, and the degree of changes. In the Process Model, the relevant information is the process type, its complexity and variations. Processes are the transactions that call the functions of the classes and there are four types: system, batch, online and real-time processes. Measurement Process. First, the class volume is determined taking into account the number of attributes, the number of relationships to other classes, and the number of methods provided by the class. Attributes are weighted by 1, relationships by 2, and methods by 3. The class volume is then multiplied by the change rate. Thus, classpoints are calculated as follows:
72
Class Po int s = ( Attrib + (Re l 2) + ( Meth 3)) Change Rate
The sum of the points of all classes is considered a measure of the class development effort. In the following step, the message-points are measured. To do this, the number of parameters is added to the number of senders and receivers multiplied by two. This count is then adjusted by the complexity rate and the change rate. Message points are calculated as follows:
Message Po int s = ( Params + ( Sources 2) + (T arg ets 2)) Complexity Rate ) Change Rate
Then, the process-points are calculated as a measure for the system test effort. It is calculated as follows:
Pr ocess Po int s = (Pr ocess Type + Variation ) Compexity Rate
2.1.3.7
Lastly, ten influence factors are proposed to adjust the obtained object-point value. Examples of these factors are the degree to which object-oriented methods are used, the OO language level, and the availability of OO CASE tools. Functional domains. MIS Tool support. SoftCalc. Validation procedure. No validation was carried out. Empirical data. No data available. Actual usage. Unknown. Predictive Object Points (Price Systems, 1999)
Predictive Object Points (POPs) [45] incorporate three dimensions of OO systems: the amount of functionality the software delivers, communication between objects and reuse through inheritance. Unlike FPA-based methods, which are based on the data and transactions model, POPs are based on objects and their characteristics. The main features of this proposal are: Category. FSM method. 73
Input artifact. Developed software using OO programming languages such as Smalltalk and C++. Abstract Model. POPs combine the following metrics presented in the literature to measure object-oriented systems: number of top level classes (TLC), average number of weighted methods per class (WMC), average depth of inheritance tree (DIT), average number of children per base class (NOC). WMC, DIT, and NOC are taken from the MOOSE metrics suite of Chidamber and Kemerer [82]. Measurement process. The following formula was proposed to calculate the size of the overall system:
POPs (WMC , NOC , DIT , TLC ) = WMC * f 1(TLC , NOC , DIT ) * f 2( NOC , DIT ) 7.8
where, f1 attempts to size the overall system, and f2 applies the effects of reuse through inheritance.
First, the WMC is calculated for each kind of method suggested by Booch [83]: constructor/destructor, selector, modifier, and iterators. These methods are classified as having a low, average or high complexity. Then, a weight is assigned depending on the methods complexity. To do this, the authors proposed a complexity table for each method type based on data collected from 20 developed software systems. The complexity assignments are made considering the number of properties of the method and the number of message responses. The total weighted methods per class are calculated by summing the values obtained for each kind of method. Functional domains. MIS Tool support. A tool called Predictive Object Point Builder was built to automate the measurement process. Validation procedure. Not mentioned. Empirical data. Data was collected from 20 developed projects. These data contain information from 775 classes and 5900 methods. Most of the software was written in C++ or Smalltalk. Actual usage. The method was developed by Price Systems. It is currently being used in this company.
74
2.1.4 Discussion
An overview of the FSM methods that are compliant with IFPUG FPA is shown in Table 1. The intention of the first two criteria is to determine which dimension (static and dynamic) of the OO systems is used for measurement proposes. By static dimension, we refer to the static properties of the system in terms of data and structure. This dimension can be captured in Use Case diagrams, Class Diagrams or Object Diagrams. By dynamic dimension, we refer to the dynamic properties of the system in terms of object interaction and behaviour. This dimension can be captured in the following UML-compliant diagrams: interaction diagrams (Sequence Diagrams, Collaboration Diagrams), State diagrams and Activity Diagrams. The aim of the third criterion (covers all OO concepts?) is to verify whether the FSM methods or procedures cover all the basic concepts of the OO systems (inheritance, aggregation, composition, polymorphism etc.). The last three criteria have already been discussed in this section and here are summarized. As can be observed, all the proposals take into account the static dimension of an OO system (i.e. the structural aspects commonly represented in an Object Model) whereas only the Lehne [42] and the Uemura et al. [76] proposals partially (depicted with P) consider the dynamic aspect (i.e., object interaction). In the case of the Lehne proposal, it is represented in collaboration diagrams, and in the Uemura et al. proposal it is represented in sequence diagrams. With regard to the third criterion, only the Fetcke proposal [43] deals with all the basic OO concepts. For instance, the other proposals do not consider the kind of structural relationships between classes (i.e., inheritance, aggregation, composition) to properly identify the logical files.
Table 1. Comparison between first category FSM methods
Criteria Static dimension Dynamic dimension Covers all OO concepts? Automated support Validated? Empirical data available? IFPUG proposal Lehne proposal P Fetcke et al. proposal Uemura et al. proposal P
75
In addition, only the proposals of Uemura et al. and Fetcke provide some empirical data and were validated using case studies. Finally, only the Uemura et al. proposal offers automated support for functional size measurement. Table 2 summarizes the second category of FSM methods for objectoriented systems. Similarly, all the proposals address the static dimension of an OO system. With exception of OOFP and OODFP, all the proposals in this category capture some dynamic aspect of the OO system (i.e., the communications that a service has with other objects in the case of the ASMA proposal). Kammelars proposal, OOFP and OODFP are the FSM methods in this category that cover all the basic concepts of OO systems. On the other hand, only OOFP [44] provides automated support for size measurement.
Table 2. Comparison between second category FSM methods
Criteria Static dimension Dynamic dimension Covers all OO concepts? Automated support Validated? Empirical data available? ASMA proposal P Kammelar proposal 3DFP OOFP OODFP
Another problem related to these proposals is its lack of validation. For instance, in the Kammelar proposal [46], the measurement steps and rules are presented but no example is mentioned. Also, OODFP [47] is presented as a more accurate proposal than OOFP to size OO systems in the design phase, but, no evidence about this is provided. The authors also suggest that OODFP is useful to estimate the cost of projects more accurately, but again, no evidence about the relationship between the size delivered by OODFP and the project cost is provided. Finally, some empirical data provided by 3D Function Points [81] and OOFP [44] FSM methods were found in the literature. Table 3 summarizes the third category of FSM methods for objectoriented systems. The criteria related to system dimension are not relevant in the case of the Rains proposal, because it measures software programs instead of conceptual models. As in the other categories, all FSM methods takes the static dimension into account for measurement purposes. In contrast to this, only the Thomson 76
proposal and the Object-Points method take the dynamic dimension into account. The former measures the system size delivered in terms of interactions, while the latter measures the message-points based on a Communication Model.
Table 3. Comparison between third category FSM methods
Criteria Static dimension Dynamic dimension Covers all concepts? Automated support Validated? Empirical data available? Laranjeira proposal OPA Rains proposal Thomson proposal OFPA ObjectPoints POPs
With respect to the third criterion, only OFPA deals with all OO concepts when defining the methods measurement rules. Predictive Object Points (POPs) [45] is the only method that fulfills almost all the criteria. However, POPs, as well as the Rains proposal [37] focus on implementation aspects (i.e., ADA package characteristics) and lack generalization. Also, according to Garmus and Herron [84] some FSM methods such as 3D Function Points (3DFP) require detailed knowledge about system processing that is not available early enough for accurate counting. Again, the lack of validation of these proposals is evident. Almost none of them provide any evidence on the suitability of the method in sizing OO systems or in predicting other variables. For instance, Rains [37] suggested the use of O-WAG for project scheduling, but no further evidence about this relationship is provided. OPA is the unique proposal which was partially validated. A simple case study was conducted to verify the correlation of its function types to FPA. However, OPA was specifically designed for CASE environments, therefore, it is not applicable for OO systems in general. Lastly, although some empirical data is available, it is not described in detail. Hence, it is not possible to use these data for replication purposes. Besides these criteria, a main criterion for the success of a proposed FSM method is its adoption in practice. Although many alternatives for sizing OO 77
systems have been proposed, from the mid 90s to date, none of them seemed to have gained sufficient recognition from practitioners to be used on a regular basis across a large number of organizations and in many countries. Some methods for sizing OO systems that were discussed above, like 3D Function Points [81], and Predictive Object Points [45] have been developed in the context of companies (e.g. Boeing, Price Systems). No details about their actual usage in these companies are publicly available. Another factor that could be affect the adoption of FSM methods in practice is the lack of support tools to help estimators in their tasks. From sixteen FSM methods that were analyzed in this section, only four were automated. Another problem is the lack of validation. Some empirical studies that investigate the ability of a FSM method to produce a size value that can be used for effort prediction have been published in the literature. For instance, Moser et al. [85] present an empirical study using 36 projects that demonstrate that the System Meter method, which explicitly takes reuse into account, predicts effort substantially better than a model based on function points. However, as far as we know, no study has been published that contains a rigorous empirical evaluation of the suitability of IFPUG FPA or other methods for sizing OO systems. For the other academic proposals that present FPA variants or extensions for OO systems, no systematic evaluation of their validity could be found in the literature. The only validation of any kind are proofs of concept presented by the method developers themselves, mostly in the same paper that proposes the new FSM method. Typical of this situation is Laranjeira [35] who applied his method to two projects. Some methods never transcend the stage of the original proposal, and the paper in which they are proposed does not even offer an illustrative example of how the rules should be applied [42] [47] [37] [39] [40] [41].
2.2
Functional size measurement for Web artifacts
This section reviews some proposals for sizing Web applications that were published in the literature. It includes a proposal of IFPUG and other solutions in the form of Web-extensions to FPA.
78
2.2.1 IFPUG guidelines (IFPUG, 1998)

In 1998, the IFPUG published some guidelines for sizing Web applications using the FPA counting rules [86]. For instance, the white paper suggests the following:
Identify what files are being used by the application (ILFs). An ILF is identified by applying the following rules: (a) A user recognizable group of data that is logically related, (b) a group of data that is maintained by an elementary process of the application. Identify what files are being referenced by the application (EIFs). An EIF is: (a) a user recognizable group of data that is logically related, (b) a group of data that is external to (and referenced by) the application, (c) a group of data that is not maintained by the application, and (d) a group of data that is maintained in another application as an ILF.
The guidelines suggest that a logical group of data is either an ILF or an EIF depending upon how and where the Web site is maintained. In a similar way, guidelines for identifying transactional functions (EIs, EOs, and EQs) for a Web application are also proposed. These guidelines were criticized and are not accepted in practice. Rollo [87], for instance, discussed some of the difficulties when measuring Web applications with IFPUG FPA, such as the difficulties encountered in identifying the systems boundary and its logical files. He concludes that sizing e-commerce applications is difficult using IFPUG FPA. Rollo argues that COSMIC-FFP is more flexible for counting Web applications. However, no evidence of this comparison is provided. Later, the company Total Metrics [88] recognized that the IFPUG guidelines did not resolve many of the counting issues faced when sizing Web applications. They provided interpretations of the IFPUG guidelines and explained how FPA can be applied to size Web Applications. To do this, they first classify the existing Web applications into the following categories:

Collections of static HTML pages: simple Web sites that comprise a collection of hyperlinked documents. Simple form fill and information provision applications: record and provide access to data maintained either in a host application database or database developed for the Web application. 79
Fully functioning business applications: provide all the business functions of an on-line application built on any other platform. Hybrid applications: which combine elements such as e-mail functionality, bulletin boards, security functions, browser functions, advertising and links to other Web sites or applications.
For instance, for the second category of Web application (simple form fill and information provision applications), they suggest considering the files that have been built specifically for the Web application (that are maintained by the forms functions) as ILFs. On the other hand, they suggest that the files referenced from a host application are EIFs. Also, the following may be considered as EIs: maintenance functions on data files that reside within the Web application boundary, and maintenance functions for data files that reside on the host application. Finally, reporting/enquiry functions on the data files are considered as EOs and EQs. Finally, Reifer [89] compared IFPUG FPA to Web objects (introduced below) using actual data from 64 completed Web projects. The findings reveal that Web objects have better accuracy than traditional function points when counted using conventions developed for that purpose.
2.2.2 Web Objects (Reifer, 2000)

In the Reifer Web Objects approach [49], functional size is determined by taking into account the components that make up a Web application. These components are the number of operands (the five function types defined in FPA plus four new function types) and the number of operators (operations that can be applied to the object). The new function types introduced in Reifers proposal (see Figure 11) are [90]: 80 Multimedia files: physical and persistent entities (e.g., MPEG-1&2 files) used by the Web application to generate output in multimedia format. Web building blocks: logical or persistent entities (e.g., ActiveX, applets, shopping carts, etc.) used to develop Web applications and automate their functionality. Scripts: logical or persistent entities (to link html/xml data) used by the Web application to link internal files and building blocks together in predefined patterns.
Links: logical or persistent entities (e.g., xml, html and query language lines) maintained by the Web application to find links of interest to external applications
Figure 11. The abstract model of the Web object
A set of counting rules is defined as in IFPUG FPA. In addition, a table of complexity ratings with weights is also defined. The Web Objects measurement process starts by counting the number of operands primarily from the information in the Web page specification. Next, the number of unique operations that will be required to manipulate the predictors estimated by the operands is estimated. Once the operands and operators are estimated, their weights are determined by using new complexity ratings proposed specifically for Web Objects. Then, the adjusted number of links and unadjusted number of function point are added to calculate the number of Web Objects. The main advantages of this proposal are the use of a mathematical basis for prediction (the Halstead equations [91]) and the existence of an extension mechanism allowing the addition of new types of operands and operators. Also, an adaptation of the COCOMO II [92] estimation model called WebMo for estimating the effort and duration of Web applications based on Web Objects was proposed. Web Objects was developed and is currently maintained by the Reifer Consultants company. The complexity ratings for the function types were developed empirically using a database of Web applications from this company. 81
2.2.3 Web-Points (Cleary, 2000)

Cleary proposed Web-Points [93] to measure the size of static Web sites. This proposal was developed in the context of the company Charismatek Software Metrics. This method takes into account the complexity of the HTML pages of a Web site. The number of Web-Points assigned to a page is a function of the size of the page in words, the number of existing links, and the number of non-textual elements of the Web page. As in FPA, a page is classified as having a Low, Average or High complexity. To do this, a complexity table is proposed based on the Link count (in, out & non-textual) and word count. For instance, a HTML page with 0 to 5 links and 0 to 300 words is classified as having a low complexity. On the other hand, a HTML page with 6 to 15 links and 301 to 500 words is classified as having an average complexity. Finally, a HTML page with more than 15 links and more than 500 words is classified as having a high complexity. Then, according to the FPA metamodel, a value is assigned for each HTML page based on its complexity. The following values are proposed: 4 for low complexity, 6 for average complexity and 7 for high complexity. The ranges used for assessing link and word count and the values assigned for each HTML page have been calibrated for Charismateks data. Web Points was used with productivity data to determine the effort required for the development or improvement of static Web sites. Clearys proposal focuses on static Web sites and therefore does not consider behavioural and navigational properties of Web applications.
2.2.4 Internet Points (Cost Xpert Group, 2001)

Another proposal is Internet Points [94], which extend FPA to explicitly support Web project estimation. This method was proposed by the Cost Xpert Group, Inc. over the last two years. A Web site is sized by counting seven types of functions: External Interface Files, Logical Internal Tables, Messages/External Queries, Reports (hard copy), static screens, and dynamic screens. The first two function types correspond to the same definition as EIFs and IFFs of the FPA method. The others function types are defined as: 82
Messages/External Queries: functions that are published for external use (as in an API) or message formats supported for external use (as in MQSeries), or functions/messages from an external application. Reports: reports and read-only screens. Static screens: static HTML screens. Dynamic screens: dynamic HTML screens generated using technologies such as ISAPI, NSAPI, DHTML report engines, ASP, etc. Interactive screens: screens that include significant business logic and user interaction or error checking.
The measurement process with Internet Points starts by identifying the seven types of functions in the requirements specification of the Web application. Then, the amount of each function type is multiplied by a weight factor. Different weight factors are proposed for each function type: 3.5 for External Interface Files, 5 for Internal Logical File, 2 for messages, 2.5 for Reports, 1 for Static Screens, 2.5 for Dynamic and Interactive Screens. Finally, the size for each function type is summed to obtain the final size of the Web application. This measurement process was automated in a tool called Cost Xpert. This tool also generates the equivalent size in SLOC as well as effort schedule and cost estimations.
2.2.5 Data Web Points (Ochoa et al., 2003)

Data Web Points (DWPs) [95] was proposed to represent the Web application functionality from the point of view of its data model. Additionally, DWPs attempt to simplify the effort estimation process. The types of entities and relationships associated to DWPs are the following: Regular: are those that do not contain a foreign key and whose primary key identifies them. Dependent: are those related to a regular entity through a foreign key and whose primary key is formed by the primary key of a regular entity and a key of its own. Relation: separate an N to M relationship between two other entities that do not have a primary key of their own; their key are formed by the primary keys of the entities participating in the relationship. 83
1 to N Relationship: this is established between a relation entity and another entity, where one or more instances of the relation entity is associated with an instance of the other entity. 1 to 1Relationship: this is established between two relation entities, where one and only one instance of the relation entity is associated with an instance of the other entity.
The central idea of this proposal is that each of these entities represents a design pattern that has a typical functionality associated with it. This functionality can be translated into standard services provided to the Web Application. The process of applying Data Web Points starts by counting the number of each of the entity types that exists in a data model. The amount of each entity type is then multiplied by a weight factor. The following weight factor is proposed for each type of entity: 3 for relationship entities and relationship 1 to 1, 6 for relationship 1 to N, and 9 for regular entities and dependent entities. The authors mentioned that weight factors were defined from the experience of the expert estimator. However, no more detail on how these factors were obtained is provided. This method was tested using computer science graduate and undergraduate students in a regular course of Software Engineering of the last 3 years (2000-2003). The course instructor and two industry experts (who know the course development scenario very well) evaluated the size estimation quality. The size estimation was evaluated as: good if it is similar to expert opinion, medium if the estimation and the experts opinion are close, and poor if they are not similar. The following results were reported with 22 Web projects: 15 projects having good size estimation (9 projects in production and 6 projects needed minor adjustments), 5 projects having medium size estimation (2 projects needed minor adjustments and 3 projects were incomplete), and 2 projects having poor size estimation (both were incomplete).
2.2.6 Discussion
An overview of the proposals that deal with Web applications is shown in Table 4. As can be observed, all the proposals take into account the static dimension of a Web application. Some proposals also provide measurement 84
rules for measuring the navigation viewpoint. This is the case of the Web Objects proposal that take into account the number of links (xml, html and query language lines) as part of the size of a Web application. Internet Points [94] is the only proposal that provides automated support to size Web applications.
Table 4. Comparison between FSM methods for Web applications
Criteria Static dimension Dynamic dimension Navigation dimension Presentation dimension Automated support Validated? Empirical data available? IFPUG proposal Web Objects WebPoints Internet Points Data Web Points
Apart from these criteria, the major limitation of the proposals discussed above is their dependence on implementation technology and the impossibility of being applied at an early stage of the Web application development lifecycle. As previously mentioned, a main criterion for the success of the proposed methods is their adoption in practice. With the exception of the Ochoa et al. proposal, all the proposals for Web applications that were discussed above have been developed in the context of companies (e.g. Reifer Consultants Inc., Cost Xpert Group Inc.). No details about their actual usage in and outside these companies are publicly available. Some empirical studies on effort prediction for Web application projects have been published [96] [97]. For instance, Ruhe et al. [96] validate Web Objects [49] in the context of a small Australian Web development company. Similarly, Baresi et al. [97] present an empirical study to estimate the effort needed to design Web applications that are developed using W2000 [53]. As far as we know, no study has been published that contains a rigorous empirical validation of a proposed FSM method for measuring the functional size of Web applications. Demonstrating an empirical relationship with effort is of course useful, but does not validate a proposed method as delivering a functional size measure for Web applications. In addition, 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 85
standards accepted in practice. Apart from these problems, no systematic evaluation of the validity of the proposed FSM alternatives for Web applications could be found in the literature.
86
Chapter 3
Foundations
This chapter introduces the OO-Method approach. First, the conceptual model level is described including each one of its four complementary views: Object, Dynamic, Functional and Presentation Models. Then, a brief introduction of the OASIS formal specification language is explained. This is followed by the description of the Execution Model that allows the automatic code generation of a system by compiling the information contained in the conceptual model views. Later, the OOWS approach is presented as an extension of the OOMethod approach to develop Web applications.
3.1
Conceptual modeling with OO-Method
OO-Method [57] [98] is a Model-Driven Development (MDD) approach [99] which automatically generates complete object-oriented systems based on the information contained in the conceptual models. The key feature of this proposal is the integration of formal specification techniques with conventional object-oriented modeling techniques. The main advantage of this is that the models are built using concepts that are much more closer to the problem space domain. In addition, this integration avoids the complexity associated to the use of formal methods. In a MDD approach, two main aspects must be clearly stated: which conceptual modeling patterns are provided by the method and which notation is provided to properly capture those conceptual modeling patterns. Figure 12 shows an abstraction of the MDD approach provided by OO-Method.
Chapter 3. Foundations
Conceptual modeling patterns and notation
OO system
conceptual modeling primitives software components in a given platform
Problem Space
Solution Space
Figure 12. OO-Method as a MDD approach
With regard to conceptual modeling patterns, OO-Method has adopted the well-known OMT strategy [100] by dividing the conceptual modeling process into three complementary views: the object view, the dynamic view, and the functional model view (adding a fourth view to specify presentation patterns). When software engineers are specifying the system, what they are doing is capturing a formal specification of the system according to the OASIS formal specification language [58]. This feature allows the introduction of a well-defined expressiveness in the specification, which is often lacking in conventional methodologies. The use of such a formal specification provides the context to validate the system in the problem space, obtaining a software product that is functionally equivalent to the specification. This equivalence is achieved by creating a model compiler that implements all the mappings specified between the conceptual patterns (problem space level) and their software representations (at the solution space level). Naturally, we have had to introduce relevant information to address specific features of OASIS in these diagrams (Object Model, Dynamic Model, Functional Model, and Presentation Model). Nevertheless, this is always done preserving the external view that is compliant with the most extended modeling notation, which is the UML [78]. 88
Hence, the subset of UML used in OO-Method is the one that is necessary to complete the information that is relevant for filling a class definition in OASIS. In this way, the arid formalism is hidden from the modeler when is describing the system by making it more comfortable to use a conventional modeling notation. Another principal objective in the design of OO-Method was to keep modelers from having to learn another graphical notation in order to model an information system. Having a formal basis allows us to provide a modeling environment where the set of needed diagrams is clearly established. In the following, we briefly introduce the four conceptual model views that exist in the OO-Method approach.
3.1.1 Object Model

The Object Model is a graphical model where system classes and relationships (association, aggregation, and inheritance) are defined. Additionally, agent relationships are specified to state the services that objects of a class are allowed to activate. These primitives capture the static point of view of the system. The corresponding UML-based diagram is the Class Diagram, where the additional expressiveness is introduced by defining the corresponding stereotypes. Specifically, for each class, the Object Model captures: attributes: to indicate whether the attribute is constant, variable or derived; services: name of the services with their corresponding arguments, distinguishing the new and destroy class services. Also, a service definition can be included in the specification of more than one class, representing a synchronous communication mechanism between the objects involved in their occurrence. They are called shared services and the participating services are linked with a double line. derivations: derivation expressions for the derived attributes (those whose value is dependent on other attributes), constraints: well-formed formulas representing conditions that objects of a class must satisfy.
The additional information associated with association, aggregation, and inheritance is the following: 89
For associated classes, to specify whether there is an aggregation or a composition (following the UML characterization) and whether the association is static or dynamic. For inheritance hierarchies, to specify whether a specialization is permanent or temporal. In the former case, the corresponding condition on constant attributes must characterize the specialization relationship; in the latter, a condition on variable attributes or the carrier service that activates the child role must be specified.
Finally, integrity constraints allow specifying conditions that must hold in any valid state of an object. They are specified within the class scope as well-formed formulas built on class attributes. Figure 13 shows an example of an Object Model, a view of a Library system with books, readers, and loans. Classes and their relationships are depicted using the OO-Method notation using the OlivaNova Modeler.
Figure 13. Class Diagram for the library system
90
For example, the discontinuous lines indicate agent relationships. In this model, there is one client class (Librarian) and the others are server classes. In the example, the objects of the librarian class can activate the services new_reader, destroy_reader, and modify_reader of the reader class. The arrow between reader and unrealible_reader denotes that this class is a temporal specialization of reader. This occurs when the event to_punish is triggered. The solid lines between reader and loan, loan and book, author and book, and book and supplier represent an association between these classes. Finally, the double lines denote shared services. For instance, the service to_loan is shared between the classes reader and loan.
3.1.2 Dynamic Model

The system class architecture has been specified using the Object Model. Additionally, basic features (such as which object life cycles can be considered valid and which inter-object communication can be established) have to be introduced in the system specification. To do this, OO-Method provides a dynamic model. It uses two kinds of diagrams: State Transition Diagrams and Interaction Diagrams. The State Transition Diagram (STD) is used to describe correct behavior by establishing valid object life cycles for every class. By valid life, we mean an appropriate sequence of service occurrences that characterizes the correct behavior of the objects that belong to a specific class. The corresponding UML base diagram is the State Diagram. The syntax for transitions is the following: [ list_of_agents | * ] : [preconditions] service_name [ WHEN control_condition ] where services preconditions state what conditions must hold for activating an event and control conditions are conditions defined on object attributes to avoid the possible non-determinism for a given service activation. Figure 14 shows a simple STD for the book class. Once a book is in the state labeled book0, if a to_loan service occurs and the precondition available = true is satisfied, the object will move to the loaned state. Here, if a return service occurs, the object will move to the book0 state. Every service occurrence (i.e. new_book) is labeled by the agent librarian, which is allowed to activate it. In this example, the * denotes that any valid agent class can activate the transition. As the only valid agents for 91
the new_book service are objects of class librarian, both representations are equivalent.
Figure 14. State Transition Diagram for the book class
In the example in Figure 15, once a reader is in the state labeled WithoutB (without books ), if a to_loan service occurs, the object will move to the WithB (with books) state. Here, if a return service occurs, the selected transition will be the one that satisfies the corresponding control condition (n_books = 1 or n_books > 1).
Figure 15. State Transition Diagram for the reader class
92
The Interaction Diagram (ID) specifies the inter-object communication. We define two basic interactions: 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. The corresponding UML base diagram is the Collaboration Diagram where the context of the interaction is not shown. Trigger specifications follow the syntax: destination :: (trigger_condition) agent:service The first part of the formula is the destination (the object(s) to which the triggered service is addressed). The trigger destination can be the same object where the condition is satisfied (self), or a specific object (indicating the oid involved), or the entire class population if we are broadcasting the service (class). The last part of the formula is the triggered service with the corresponding agent. Global interactions are graphically specified by connecting the services involved in the declared interaction. These services are represented as solid lines linking the objects (boxes) that provide them. There is one STD for every class, but only one ID for the whole system, where all the inter-object interactions will be graphically specified. For the library system, an interaction diagram with the following trigger can be defined: self:: (if (today() - loan.return_date) > 7) librarian: disable It indicates that a trigger action (librarian:disable()) must be activated when the return_date is greater than 7 days.
3.1.3 Functional Model

A correct functional specification is a shortcut of many of the most extended OO methods. Sometimes, the model used breaks the homogeneity of the OO models, as happened with the initial versions of OMT, which proposed using the structured DFDs as a functional model. The use of DFD techniques in an object-modeling context has been criticized for being imprecise, mainly because it offers a perspective of the system (the functional perspective) that differs from the other models (the object perspective). 93
Other methods leave the free-specification of the system operations in the hands of the designer. The OO-Method functional model (FM) is quite different from these conventional approaches. In this model, the semantics associated to any change of an object state is captured as a consequence of a service occurrence. To do this, it is declaratively specified how every service changes the object state depending on the arguments of the service involved and the object's current state. A clear and simple strategy is given for dealing with the introduction of the necessary information. The relevant contribution of this functional model is the concept of categorized attributes. Three types are defined: push-pop, state-independent, and discretedomain based. Each type will define the pattern of information required to define its functionality. Push-pop attributes are those whose relevant events increase or decrease their value by a given quantity. Events that reset the attribute to a given value can also exist. State-independent attributes have a value that depends only on the latest action that has occurred. Once a relevant action is activated, the new attribute value of the object involved is independent of the previous one. In such a case, we consider that the attribute remains in a given state, having a certain value for the corresponding attribute. Discrete-domain valued attributes take their values from a limited domain. The different values of this domain model the valid situations that are possible for objects of the class. Through the activation of carrier actions (which assign a given domain value to the attribute), the object reaches a specific situation. The object abandons this situation when another event occurs (a liberator event).
Table 5 shows the Functional Model for the attribute n_books of the book class. This attribute is categorized as a push-pop because its relevant services increase or decrease the attribute value by a given quantity.
Table 5. Functional Model example
Class: book Action Type increase decrease Attribute: n_book Action librarian: to_loan() librarian: return() Category: push-pop Effect +1 -1
94
In the example, librarian:to_loan() is the increasing action and librarian:return() is the decreasing action. This categorization of attributes allows us to generate a complete OASIS specification in an automated way, where service functionality is completely captured.
3.1.4 Presentation Model

The object society structure, behavior, and functionality are specified using the three conceptual models described above. The last step is to specify how users will interact with the system. This is done by the Presentation Model [101] through the definition of a set of Presentation Patterns. The Presentation Patterns capture the information required to characterize what appearance the application will have, and how the user will interact with the application. These Presentation Patterns can be organized in three levels: Level 1: The first level contains the Hierarchical Action Tree (HAT) pattern, providing the access to the application. Level 2: The second level contains the Interaction Units. The user interface is then decomposed in the following scenarios to support user tasks: Service Interaction Unit (SIU): represents a dialogue where a user executes a service. As part of the dialogue, the user must provide the arguments of the service and the system must validate them. In addition, the user can perform an action to execute the service or to cancel it. The system will have to inform the users of the occurrence of errors. Instance Interaction Unit (IIU): the intention is to present data (from one class instance) to the user. It is defined on a class and has the following properties: a visualization display (to show the information), actions (performed on the object) and navigation (reachability between instances). Population Interaction Unit (PIU): the intention is to present data (from a set of class instances) to the user. Filtering and ordering mechanisms can also be added to improve the object selection and consultation.
95
Master/Detail Interaction Unit (MDIU): the intention is also to present information to the users. It is defined from IIUs and PIUs to show related information. Level 3: the third level is composed of patterns that add additional semantics to the interaction units.
The precise description of the patterns can be found in [101]. Figure 16 gives an overall view of the levels and the corresponding interdependencies among patterns.
Figure 16. Pattern Language and use relationship (Source: [101])
96
3.2
OASIS formal specification
OASIS [58] [102] is an object-oriented formal specification language developed at the Information Systems and Computation Department at the Valencia University of Technology. In this section, we give a general explanation of the foundation and structure of the language. A detailed description of the language can be found in [58] and [102]. A class in OASIS is made up of a class name, an identification function for instances (objects) of the class, and a type or template that all the instances share. The identification function characterizes the naming mechanism used by objects. It gives a set of surrogates belonging to a predefined sort or to a sort defined by the user (the so-called domains in OASIS). They are imported in the class definition. The most common are predefined as Int, Nat, Real, Bool, Char, String and Date. They represent numbers, boolean values, characters, strings, and dates in a particular format. New domains can be introduced in a specification by defining the corresponding abstract data type. A type is the template that collects all the properties (structure and behavior) shared by all the potential objects of the class being considered. Syntactically, it can be formalized as: A signature, which contains sorts, functions, attributes, and events to be used. A set of axioms, which are formulas in a dynamic logic. A process query, as a set of equations with variables of a sort process that are solved in a given process algebra.
When these variables are instantiated, we have the ground terms that represent possible lives of instances (objects)5. The semantics is given in terms of the (W,,) structure (KRIPKE semantics). We now consider these three class definition components. A class signature contains: A set of sorts with a partial order relation. Among this set of sorts, there is, in particular, the sort of interest (the class name) associated with the class being defined. A set of functions including:
It is then a presentation of a theory in the modal logic outlined.
97
Those functions included in the definition of the (predefined) sorts. The identification function whose sort is the ADT for identities implicitly provided with a class specification. It provides us with values of a given sort to identify objects, to assure that any object of a given class has a unique identity6. A set of (constant, variable and derived ) attributes, (see constant_attributes and variable_attributes sections in Figure 17). They all have the sort of the class as domain, and the given sort associated to the attribute being considered as codomain. A set of events (see private events and shared events in Figure 17), with the sort of the class as domain (plus any additional sort representing event information), and with the sort of the class (sort of interest) as codomain. It is important to remark that this so-called sort of interest can be seen as a subsort of a general sort process when objects are viewed as processes.
The agent that is allowed to activate it will label every event occurrence. Following the approach taken by [103] when dealing with this actor notion, we will write i:a if the agent i initiates event a and call i:a an action. Note that i could be the environment or any object of a system class. When defining an event, the designer is forced to state who will be able to activate it. In consequence, we will assume that a set A of actions is defined. This set of actions is obtained from and attached to the initial set of events. In this way, we can represent the notion of the set of object services as the interface that allows other objects to access the state. They can be events (server view) or actions (client view) depending on whether these services are offered or requested. Actions become services requested by an object, by which it can consult or modify another objects state (or its own state).
For specification purposes, an identification mechanism is introduced consisting of the declaration of one or more key maps used as aliases for identifying objects. They are similar to the candidate key notion of the relational model. From a given key value these maps return its associated object identity. Key maps will be declared as (tuples of) constant attributes.
98
Figure 17. Excerpt of an OASIS specification
99
In OASIS, there are the following types of dynamic formulas (set of class axioms): Valuations. They are formulas of the form [a] whose semantics is given by defining a function that, returns a function between possible worlds from a ground action a. (a) WW In other words, with any valid state being a possible world for an object, the function determines which transitions between object states are valid after the execution of an action a. In the example of the Library system, we have the following valuations: [to_loan ()] n_books= n_books + 1; [return ()] n_books= n_books - 1; It is important to note that, within this dynamic logic environment, the formula is evaluated in sW, and is evaluated in (a), with (a) being the world represented by the object state after the execution in s of the action considered. Derivations. They are formulas of the type . They allow us to define derived attributes () in terms of the given derivation condition (stated in ). They differ from the evaluation formulas in that these derived evaluations are done in a unique state. In our example, there are no derivations. Integrity constraints. They are formulas that must be satisfied in every world. We distinguish between static and dynamic. Static integrity constraints are those defined for every possible world. They must always hold. In the example: static n_books < 10; Dynamic integrity constraints are those relating different worlds. They require the use of a temporal logic, with the corresponding temporal logic operators.
Preconditions. They are formulas with the template [a] false, where is a formula that must hold in the world previous to the execution of action a. Only in the worlds where holds, is a allowed
100
to occur. If holds, the occurrence of a gives no state as successor. We have the following precondition in the OASIS specification: librarian:destroy_reader () if n_books = 0 ; librarian:to_loan () if punish = false ; Triggers. They are formulas of the form [a] false, where a is the action negation7. If holds and an action other than a occurs, then there is no successor state. This forces a to occur or the system remains in a blocked state. For instance, using the appropriate dynamic formula, where we include information about the destination in the triggered service (according to the trigger expressiveness presented when the OO-Method Interaction Diagram was introduced), we will declare: self:: (if (today() - loan.return_date) > 7) librarian: disable Thus, triggers are actions that are activated when the condition stated in holds. The main difference between preconditions and triggers comes from the fact that, in triggers, there is an obligation to activate an action as soon as the given condition is satisfied. In this way, triggers allow us to introduce internal activity in the object society that is being modeled. In any of these dynamic formulas, and are well-formed formulas in a first order logic that usually refer to a given system state characterized by the set of values attached to attributes of objects in the state or world considered. In OASIS, an object is defined as an observable process [104]. The process specification in a class allows us to specify object dynamics and determines the access relationship between the states of instances. Processes are constructed by using events as atomic actions. However, the designer also has the choice of grouping events in execution units, so-called transactions. The molecular units that are the transactions have two main properties: They follow an all-or-nothing policy with respect to the execution of the involved events: when a failure happens during a transaction execution, the resultant state will be the initial one. The non-observability of intermediate states.
7
It means that a does not occur.
101
We finish this section by introducing the process specification of the reader class from Figure 17.
reader = librarian:new_reader () withoutB; withoutB = (to_punish () + librarian:modify_reader (p_name,p_lastname, p_address,p_phone,p_SSN,p_state,p_company,p_email)) withoutB + librarian: destroy_reader () + librarian: to_loan () withB; withB = (librarian:to_loan () + if n_books > 1 return ()) withB + if n_books =1 librarian:return () withoutB;
The execution of processes are represented by terms in a well-defined algebra of processes, which is based on the approach presented in [105]. It allows us to declare possible object lives as terms whose elements are transactions and events. Every process can be rewritten to a term in a basic process algebra BPA with the (sequence) and + (alternative) process operations. This provides an implementation of concurrency based on arbitrary interleaving. This section provides a short introduction of the formal features of OASIS. A complete description of its semantics and formal foundations can be found in [106].
3.2.1 The formal specification as the system repository

After having presented the OO-Method architecture, and the OASIS formal concepts attached to it, the basic mappings to translate the graphical representation to the textual one are presented. This process takes as input the graphical information introduced in any OO-Method conceptual schema and generates a textual system representation that is a specification in OASIS. This formal specification has, in fact, been obtained using conventional techniques and constitutes a solid system documentation to obtain a final software product which is compliant with the initial requirements, as represented in the starting conceptual schema. According to the class template introduced in the previous section, the set of OO-Method conceptual patterns and their corresponding OASIS representation are identified. The system classes are all obtained from the Object Model. For each class, we have: 102 Its set of (constant, variable or derived) attributes.
Its set of services, including (private and shared) events and local transactions. The integrity constraints specified for the class. The derivation expressions corresponding to the derived attributes.
If we are dealing with a complex class (those defined by using the provided aggregation and inheritance class operators), the Object Model also provides the particular characteristics specified for the corresponding complex, aggregated, or specialized class. With the information given by the Object Model, we have the system class framework, where the class signature is precisely declared for every class of the system. The Dynamic Model uses two kinds of diagrams: State Transition Diagrams (STD) and Interaction Diagrams (ID). For the STD, we obtain: Event preconditions (those formulas labeling the event transitions). The process definition of a class, where the template for valid object lives is fixed.
And from the Interaction Diagram, we complete two other features of an OASIS class specification:

Trigger relationships. Global transactions (those involving services of different class objects).
Finally, the Functional Model gives the dynamic formulas related to evaluations, where the effect of events on attributes is specified. This is how the formal specification corresponding to an OO-Method conceptual schema provides a precise system repository where the system description is completely captured, according to the OASIS object-oriented model. This allows us to undertake the implementation process (Execution Model) from a well-defined starting point, where the involved pieces of information are meaningful because they come from a finite catalog of conceptual modeling patterns, that also have a formal counterpart in the OASIS language.
103
3.3
Execution Model
The OASIS specification is the source for an execution model that must accurately state the implementation-dependent features associated to the selected object society machine representation. In order to easily implement and animate the specified system, we predefine a way in which users interact with system objects. The template used to achieve this behavior is: 1. Identify the user 2. Obtain the object system view 3. Service activation 3.1 Identify the object server 3.2 Introduce service arguments 3.3 Send the message to object server 3.4 Check state transition 3.5 Check preconditions 3.6 Valuations fulfillment 3.7 Integrity constraint checking in the new state 3.8 Trigger relationships test The process starts by logging the user into the system (step 1) and providing an object system view (step 2) determining the set of object attributes and services that it can see or activate. After the user is connected and has a clear object system view, the user can then activate any available service in his/her worldview. Among these services, there will be observations (object queries) or local services or transactions served by other objects. Any service activation (step 3) has two steps: build the message and execute it (if possible). In order to build the message, the user has to provide information to identify the object server (step 3.1). Subsequently, the user must introduce service arguments (step 3.2) of the service being activated (if necessary). Once the message is sent (step 3.3), the service execution is characterized by the occurrence of the following sequence of actions in the server object:
Check state transition (step 3.4), which is the process of verifying that a valid transition exists in the OASIS specification for the selected service in the current object state. The precondition satisfaction (step 3.5) indicates that the precondition associated to the service must hold.
104
If any of these actions do not hold, an exception will arise and the message is ignored. Otherwise, the process continues with:

The valuation fulfillment (step 3.6), where the induced service modifications take place in the involved object state. To assure that the service execution leads the object to a valid state, the integrity constraints (step 3.7) are verified in the final state. If the constraint does not hold, an exception will arise and the previous change of state is ignored. After a valid change of state, the set of condition-action rules that represents the internal system activity is verified. If any of them hold, the specified service will be triggered (step 3.8).
The previous steps guide the implementation of any program to assure the functional equivalence between the object system specification collected in the conceptual schema and its reification in an imperative programming environment.
3.4
Conceptual modeling with OOWS
Given the recent advent of the Web, there is no consensus about the meaning of the terminology used in this context (i.e., navigation, presentation). However, it is widely accepted by the different communities that work in this field that the Web corresponds to a directed graph whose nodes correspond to Web pages and whose arcs correspond to links between these pages [107]. Our position is that the Web can be modeled. Thus, navigation can be defined as the changing of a conceptual node through the activation of a navigational link. By conceptual node, we mean an interaction unit that provides access to data and functionality for a given user type (agent). By navigational link, we refer to the reachability relationship between conceptual nodes to satisfy a given agents goal. Following these ideas, an extension of OO-Method to develop Web applications was defined [54] [55]. This extension is called OOWS (ObjectOriented Web Solutions) and provides two new conceptual models to represent navigational and presentational features to the classical OO-Method framework. These models are briefly introduced in the following subsections.
105
3.4.1 Navigational Model

The Navigational Model is defined as navigational views over the Object Model. For navigational purposes, we assume that any valid navigation must be accomplished by traversing a path that exists in the underlying Object Model. This means that we can navigate from one class to another, if and only if, a relationship between the involved classes is specified. Navigational views are defined for each user type (agent) by means of a navigational map. Next, we present the basic navigational modeling primitives that must be provided to define a navigational map. This is followed by the introduction of the advanced navigational modeling primitives. 3.4.1.1 Basic navigational modeling primitives
The navigational map is the core modeling primitive of the navigational model. It represents the valid paths that an agent can taken in the application. Figure 18 shows the conceptual modeling primitives of the Navigational Model to represent the navigational requirements of Web applications. A navigational map is represented by a directed graph where nodes are navigational contexts and arcs are navigational links. A navigational context represents the perspective a user has on a subset of the Object Model, while a navigational link allows the navigation from one context to another. Thus, any navigational map is made up of: Navigational contexts, which are the basic user interaction units, containing a set of navigational classes and navigational relationships. They are graphically represented by UML packages that are stereotyped with the context reserved word. Navigational links, which are binary relationships specifying a reachability relationship between two navigational contexts.
In order to illustrate the use of these primitives, we model the navigational requirements for a Library web application. In this application, the following kinds of users were identified: Anonymous user (Internaut), Registered Users (Librarian, Reader, and Manager).
106
Figure 18. Conceptual modeling primitives of the Navigational Model
Figure 19 shows the navigational map for the Librarian user. When a Librarian user accesses the Web application, she/he can navigate to any one of the navigational contexts indicated with the E label (represented by the dashed arrows). These are exploration contexts and can be reached from any other context of the application. For instance, an Internaut can navigate to see information about the suppliers, readers, books and loans.
Figure 19. Navigational map for the Librarian user
107
The solid arrows indicate possible navigation paths between the contexts. The contexts represented with the S label are called sequence contexts because they can only be accessed by following predefined navigational paths. For instance, the context Reader_Details can only be reached from the contexts Readers, or Loan_Details. Once the structural aspect of the Web application is captured in terms of its user kinds and its navigational maps, the next step is to specify the content of each one of the navigational contexts contained in those maps. A navigational context is composed of a set of navigational classes stereotyped with the reserved word view, which is connected by navigational relationships. A navigational class includes the set of attributes and the set of services that an agent can access. These accessible properties must exist in the Object Model previously defined. This allows us to define a navigational class as a view of a class, where the subset of visible and accessible class properties is specified. Each navigational context has one mandatory navigational class, called manager class and other optional navigational classes (called complementary classes) to provide complementary information of the manager class. Finally, a navigational relationship is defined as a unidirectional, binary relationship that exists between two navigational classes of a given navigational context. It needs to have a structural relationship counterpart in the associated Object Model. There are two different types of navigational relationships: Contextual dependency relationship: is used to provide the required additional information in the current context without denoting any further navigation. It is graphically represented as:
Context relationship: is used to define navigation from a source navigational context towards the target one. The following information should be provided: the target navigational context and the link attribute that will be used as anchor for activating the navigation. It is graphically represented as follows:
link-attribute attribute target-context [context]
108
Figure 20 shows the navigational context Reader_Details for the Librarian user. The purpose of this context is to provide detailed information about readers, their loans and their penalties. The following navigational classes have been defined in this context: reader (manager class), unrealible_reader and loan. All these classes include the set of attributes and services that are relevant for the Librarian user. In this context, there is a contextual dependency relationship between reader and unrealible_reader classes that is used to show the punish date. In addition, there is a context relationship between reader and loan classes to retrieve information about the loans of a given reader. It creates a link to the Loan_Details context, using the link attribute id_loan as the navigation anchor.
Figure 20. Navigational context Reader_Details for the Librarian user
Service links can also be attached to a service representing a target navigational context that the user would reach after a service execution. In the Figure 20, the Librarian user will see all loans (in the navigational context Loans) after executing the service loan() in the navigational context Reader_Details.
109
3.4.1.2
Advanced navigational modeling primitives
In addition, the following modeling primitives can be added to the navigational context specification: index and population filter. An index is defined by Paolini et al. [108] as a facility to provide a fast access to a group of objects, for users who are interested in one or more of them, and are able to make a choice. In OOWS, an index [109] is a modeling primitive that provides an indexed access to the population of the manager class. Two kinds of indexes can be specified depending on the properties of the manager class: Attribute index: is defined using a subset of attributes of the manager class. The template to define an attribute index is the following:
ATTRIBUTE INDEX <name_index> ATTRIBUTES <attribute_list> LINK ATTRIBUTE <link_attribute(s)>
Relationship index: is defined using a subset of attributes of the classes related to the manager class. The template to define a relationship index is the following:
RELATIONSHIP INDEX <name_index> ATTRIBUTES <attribute_list> LINK ATTRIBUTE <link_attribute(s)>
Note that when an index is defined, at least one of the attribute(s) must act as the link attribute to select instances. Therefore, when the user selects an index entry using a link attribute, the related instance(s) is presented in the navigational context. A population filter is a search mechanism which allows the retrieval of only those instances of a navigational class that fulfills a given criteria. It is defined by selecting one attribute of the manager class. Three kinds of population filters can be defined: Exact filter: take one attribute value as input and return all the instances that match it exactly. Approximate filter: take one attribute value as input and return all the instances whose attribute values include this value as a substring. Range filter: take two values as input and return all the instances whose attribute values fit within the range. 110
The template to define filters is the following:

FILTER <filter_name> ATTRIBUTE <attribute_list> TYPE EXACT / APPROXIMATE / RANGE
Figure 21 shows the navigational context Books for the Librarian user. This context provides information about all books in the library (e.g., title, place, year, publish and IBSN) and their author. Also, there is a navigation capability to the context Book_Details by selecting the book title.
Figure 21. Navigational context Books for the Librarian user
In addition, we have also defined an attribute index (book_year) to create a list of summarized information about books. It presents the title, the author and the year. When an element of the active index list is chosen, all specified information of the select instances becomes visible in the Books navigational context. Finally, two filters are defined to improve the book search: an approximate filter to search for books by title, and a range filter to search for books by year. In the following, we introduce a set of conceptual presentation patterns to describe how the navigational contexts will be presented to their intended audience.
3.4.2 Presentation Model

The intention of this model is to complement the navigational context definition through the specification of presentation properties. These 111
properties will also guide the user interaction provided by the Web Application. The conceptual presentation patterns are the following: Information layout to indicate how the information will be visualized. Visualization facilities to define how the required information can be structured. Ordering criteria to indicate an order to view the required information
In order to specify information layout, four patterns are provided in OOWS: register, tabular, tree, and master-detail (when the main information unit the master determines the dependent information units the details). They can be applied to the navigational class and relationships (see Figure 22). In the first case, these patterns describe the way in which the instances of the navigational class will be presented to the user. In the second case, they are used to define how the instances of the target related class are presented with respect to the source class. The visualization facilities are useful when a great number of instances should be presented. This information can be divided into logical blocks to show one block at a time. Then, the following presentation patterns can be applied: Cardinality: indicates the number of instances per logical block. Mechanisms to move forward and backward are also provided. It can be static (the number of instances per logical block is fixed) or dynamic (the number of instances per logical block can be changed by the user). Access mode: provides facilities to access the different logical blocks. They can be sequential (mechanisms to go to the next, previous, first and last logical block) or random (the same mechanisms as sequential mode plus the facility to go directly to a given logical block). Circularity: organizes the set of logical blocks in a circular buffer.
Finally, the ordering pattern defines the ordering (ASCendant or DESCendant) in which the information will be presented according to the value of one or more attributes. It can be applied to the manager class or searching mechanisms. 112
Figure 22 shows how the conceptual presentation patterns can be introduced in a navigational context definition (in navigational class or relationship levels).
Figure 22. Conceptual Modeling Primitives of the Presentation Model
Figure 23 shows the presentation requirements specified for the navigational context Book_Details. This context specifies that the instances of books will be shown in a tabular layout, being only possible to see four instances at a time (static cardinality to four is specified). Sequential access is provided for accessing the different logical blocks, i.e., access to the first block, previous, next and last one. In addition, the books will be sorted by title. The navigational class Book has two contextual dependency relationships: one with the class Author and the other with the class Supplier. Both relationships will be shown applying the master-detail layout. In the relationship with the class Author, the master role is played by book objects that will be presented in a register layout, and the detail role is played by the authors that will be presented in a tabular layout. Authors will be shown ordered by the name in the book. These presentation patterns, together with the specified navigation features, capture the specific requirements for the web interface development. Additional information about these conceptual modeling primitives can be found in [55] [109] [110].
113
Figure 23. Navigational context Book_Details for the Librarian user
3.5
Conclusions
This chapter has introduced the OO-Method approach and each one of its four complementary views: Object, Dynamic, Functional and Presentation Models. This follows a model-driven development approach where a complete OO system is obtained by compiling the information contained in the conceptual model views. This is done by implementing a set of mappings between conceptual primitives and their corresponding software representations. Next, the OOWS approach has been introduced as a natural extension of the OO-Method to develop Web applications. In OOWS, navigational and presentational conceptual primitives are introduced to complement the conventional conceptual primitives that capture the static and dynamic perspective of an OO system. All these views are used as input for the development of Web applications. OO-Method and OOWS are the basis for the design of the measurement procedures that are presented in the following two chapters.
114
Chapter 4
A Functional Size Measurement Procedure for OO Systems: The OOmFP Approach

This chapter presents the definition of OO-Method Function Points (OOmFP) following the steps of the process model for software measurement proposed by Jacquet and Abran [26]. Using this process model, we present the design of the measurement method and its application in a case study. We also describe how the action research improved the design of OOmFP.
4.1
Design of the measurement method
In Step 1 of the process model described in Figure 5, 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.1 Definition of the objectives

In terms of the Goal/Question/Metric (GQM) template for goal-oriented software measurement [74], the goal pursued in this work is: design a FSM method for the purpose of measuring object-oriented conceptual schemas
Chapter 4. A FSM Procedure for Object-Oriented Systems: The OOmFP Approach
that are developed using OO-Method with respect to their functional size from the point of view of the researcher. The context is that the measurement procedure of this FSM method should conform to the FPA counting rules.
4.1.2 Characterization of the concept to be measured

OOmFP is based on measuring conceptual schemas in the sense that these are the input artifacts used for measuring functional size. A conceptual schema is a formal representation of a part of the real world (the so-called Universe of Discourse), where its relevant components and their relationships are properly described and represented. This conceptualization process is done at the Problem Space level, focusing on the concepts that characterize the system as required by its users (or client) in a manner that is independent of the system design and implementation. Our approach assumes that the functional user requirements for a system are modeled using OO-Method and then derives a functional size value from this conceptual schema. The obtained size value reflects the amount of functionality contained in the user requirements specification as modeled in the OO-Method conceptual schema. Consequently, the entity to be measured consists of an OO-Method conceptual schema. We stress that a conceptual schema is a problem space representation, meaning that it does not dependent on choices made during design and implementation, which is a requirement for applying functional size measurement. The attribute to be measured is functional size, defined by ISO/IEC 14143-1 [9] 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 users needs, without considering how this will be accomplished. They exclude any non-functional or technical requirements.
4.1.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 116
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 representing 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 [14], it assumes in essence the same metamodel as IFPUG FPA. Therefore, we first discuss the IFPUG FPA metamodel and then we present a set of rules to map the concepts of this metamodel onto the concepts used in the OOMethod conceptual schemas. 4.1.3.1 IFPUG FPA metamodel
As described in Figure 24, the IFPUG FPA view on functional size is that a software system consists of logical data files (internal logical files and external interface files respectively indicated by ILF and EIF) and functions (external input functions, external output functions and external inquiry functions respectively indicated by EI, EO and EQ) that perform transactions using or altering the data in the logical data files.
Figure 24. IFPUG FPA view on functional size
The amount and complexity of the data (types) handled by a logical data file or transactional function determines the amount of functionality that 117
these 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. In addition, systems that are used by the system within the counting scope are identified. Figure 25 shows the IFPUG FPA metamodel. It illustrates the information we need to capture in order to represent 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).
Project Boundary
description
1 has
name description 1 <<enum>> type
is composed of
1 FunctionType name
1 type={new, enhanced, application}

is composed of 0..*
0..* DataFunction
TransactionalFunction
type=EI
type=EO
type=EQ
type=ILF
type=EIF
EI
EO
EQ
ILF
EIF
Figure 25. IFPUG FPA metamodel first level
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. In this thesis, we address the first type of count: development project function point count. The boundary indicates the border between the project or application being measured and the external applications or user domain. It must be 118
drawn according to the users view. The user view is an important principle in this method and is defined as follows: A user view represents a formal description of the users business needs in the users language. A function point count is accomplished using the information in a language that is common to both user(s) and developers. Once the border has been established, data and transactional functions can be identified. Data functions (DataFunction) can be data that is internally maintained by the system (ILFs) or referenced in other systems (EIFs). Transactional functions (TransactionalFunction) represent the functionality provided to the user to process data. There are three kinds of transactional functions: external inputs (EI), external outputs (EO) and external inquiries (EQ). These concepts will be introduced in the next section. 4.1.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 adaption of IFPUG FPA, which 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 the following: 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 counting scope defines the functionality that will be included in a particular measurement. The scope of a development function point count includes all functions impacted (built or customized) by the project activities. 119
In OOmFP, the counting scope is an OO-Method conceptual schema including the four complementary views. The application 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 mapping rules shown in Table 6. 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.
Table 6. Mapping rules to identify the system boundary
System Boundary Accept each client class as a user of the system. Accept each legacy view as an external application
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 patterns defined in the Presentation Model [101] (e.g., Instance Interaction Unit (IIU), Population Interaction Unit (PIU) and Master-detail Interaction Unit (MDIU)) for visualizing the object society of a class can be considered as either external outputs (EOs) or external inquiries (EQs). These patterns describe different kinds of user interactions with the system where data generated within the system is presented to the user. In fact, the IFPUG manual does make clear distinction between an EO and EQ. We assume the difference is that an EQ does not contain derived or calculated data (otherwise, it is an EO). What is 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 user 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 7. This table summarizes the mapping between the IFPUG FPA concepts and the OO-Method conceptual modeling primitives. 120
Table 7. Mapping the IFPUG FPA concepts to OO-Method primitives

Function Counting scope Application boundary IFPUG FPA Defines the functionality which will be included in a particular function point count. It defines a (sub) set of the software being sized. Indicates the border between the software being measured and the user. It is the conceptual interface between the internal application and the external user world. A user identifiable group of logically related data or control information maintained within the boundary of the system. A user identifiable group of logically related data or control information referenced by the system, but maintained within the boundary of another system. An elementary process that process data or control information that comes from outside the system boundary. Its primary intent is to maintain one or more ILFs and/or to alter the behaviour of the system. An elementary process that sends data or control information outside the system boundary. Its primary intent is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, or to create derived data. An external output may also maintain one or more ILFs and/or alter the behaviour of the system. OO-Method An OO-Method Conceptual Schema including the Object, Dynamic, Functional and Presentation model views. An imaginary line traced in the Object Model. The client classes and legacy views are considered outside the boundary whereas the server classes are considered inside the boundary. A class that encapsulates a set of data items (attributes) representing the state of the objects in each class. A legacy view that is defined as a filter placed on a class by a preexisting software system. 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). An Instance Interaction Unit, Population Interaction Unit and Master-detail Interaction Unit defined in the Presentation Model [101]. The intent is to present information to the user. The pattern must perform some calculations, or use some derived attribute.
ILF
EIF
EI
EO
121
Function EQ
IFPUG FPA An elementary process that sends data or control information outside the system boundary. Its primary intent is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, nor is the behaviour of the system altered.
OO-Method An Instance Interaction Unit, Population Interaction Unit and Master-detail Interaction Unit defined in the Presentation Model [101]. The intent is to present information to the user without altering the system behaviour.
4.1.4 Definition of the numerical assignment rules

In this substep, the measurement rules that lead to 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. Figure 26 shows a 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 that is referenced during the execution of a transactional function. The complexity of a data function is a function of the number of Data Element Types (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 employee. Then, two RETs are identified: salaried employee and hourly employee. The IFPUG [14] 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. 122
Project
name description <<enum>> type /ILFs_quantity Boundary /EIFs_quantity description 1 has 1 /EIs_quantity /EOs_quantity /EQs_quantity /functionalSize
type={new, enhanced, application}

is composed of 1
comp_level={low, average, high}
FunctionType
name <<enum>> comp_level weight
1 is composed of
DET name 0..* DataFunction DET_Data

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

1..* has type=EI type=EO type=EQ 0..*
RET name
type=ILF
type=EIF
EI
EO
EQ
FTR
ILF
EIF
Figure 26. IFPUG FPA metamodel second level
An important constraint that arises from the analysis of the metamodel shown in Figure 26 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 8 summarizes the weights provided in the IFPUG FPA counting manual [14]. 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 8. 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
123
Therefore, given a conceptual schema produced during the OO-Method conceptual modeling step, OOmFP is calculated as follows:
OOmFP
Where:
= OOmFP
n
Data
+ OOmFP
m
Transactio n
(1)
OOmFPData =
OOmFPclassi + OOmFPlegacy view j

i =1 j =1
(2)
OOmFPTransactio n = OOmFP service i + OOmFP IIU j / PIU j / MDIU j

i =1 j =1
(3)
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.1.4.1 Measurement rules for the Object Model
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) as in IFPUG FPA. Table 9 describes the measurement rules proposed to identify the DETs and RETs for a class. According to Table 9, DETs correspond to data-valued attributes of a class as well as the attributes that identify related classes. Data-valued attributes represent simple attributes such as integers and strings. A RET is identified for the class itself, but also for some of the object classes and legacy views that are related to the class. We consider both aggregations8 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. IFPUG also suggest identifying 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 can be associated to a single object of the class.
8
The concept of aggregation in OO-Method includes the concepts of association and composition provided by UML [78].
124
Table 9. Measurement rules for the complexity of a class

Data Element Type (DET) 1 DET for each data-valued attribute of the class 1 DET for each attribute in the IF9 of a class or legacy view referred to by a univalued aggregation relationship 1 DET for each attribute in the IF of the superclasses of a class Record Element Type (RET) 1 RET for the class 1 RET for each multivalued aggregation relationship (class or legacy view)
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 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 users point of view, abstract classes are not explicitly differentiated from other classes in OO-Method. Therefore, object instances
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_.
9
125
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 27 shows the measurement of two classes connected with an 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. Let the id_country and id_countryname be the identification function (IF) of the class Country and let the id_name be the IF of the class City.
Figure 27. Example of class measurement
By applying the measurement rules shown in Table 9, the data-valued attributes of the class Country are counted as DETs and the class itself is considered as a RET. Because the relationship with the class City " has a multiplicity of 0:M, one RET is counted. In the same way, the data-valued attributes of the class City are counted as DETs and the class itself is considered as a RET. Because the relationship with class Country has a multiplicity of 0:1 and the IF is formed by the attributes id_name and id_country, two DETs are counted. Table 10 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. 126
Table 10. Measurement rules for the complexity of a legacy view

Data Element Type (DET) 1 DET for each non-derived attribute of the legacy view 1 DET for each attribute in the IF of the class that is related to a univalued aggregation Record Element Type (RET) 1 RET for the legacy view 1 RET for each multivalued aggregation relationship with a class
Figure 28 shows the measurement of a class connected with a legacy view through an aggregation relationship. A legacy view is denoted by a box with the legacy view name in a black compartment at the top of the box. We start measuring the class Employee with a reflexive aggregation relationship. By applying the measurement rules shown in Table 9, the datavalued attributes of the class 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, which is connected through univalued aggregation relationship with Employee.
Figure 28. Example of class and legacy view measurement
127
Now, we measure the legacy view Rate. In this example, the employees 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 10, the legacy views 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 class Employee has only one attribute, one DET is counted. 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 11 shows the measurement rules for the complexity of a class service. In OO-Method, 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.
Table 11. Measurement rules for the complexity of a class service
Data Element Type (DET) 1 DET for each data-valued argument of the service 1 DET for the capability to send messages 1 DET for the action (Accept/Cancel) of the service execution. File Type Referenced (FTR) 1 FTR for the class 1 FTR for each new class referenced in the object-valued argument of the service. If integrity constraints are defined, count one FTR for new class referenced in the 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 which the event is a carrier/liberator. If a value by default is defined, count one FTR for each new class referenced in the formula.
128
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. In addition, 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 signature10 and consist of verifying whether in some formula (value by default, transaction, specialization by condition, specialization by event, integrity constraint) a new class is referenced. In this context, new means that the class was not identified before (as a result of applying another rule) as a FTR for the class service considered. If it occurs, one FTR for each new class is counted. In OO-Method, there are two kinds of inheritance hierarchies: permanent or temporal. In the former, the corresponding condition on constant attributes must characterize the specialization relationship (specialization by condition)11; 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 29 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.
There are a set of well-formed formulas associated to the class signature defined according to a formal language called OASIS [58] . 11 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.
10
129
Figure 29. Example of Service Measurement
By applying the measurement rules shown in Table 11, 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. Table 12 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. In addition, a precondition or integrity constraints can be specified based on the input arguments.
Table 12. Measurement rules for the complexity of a legacy view service
Data Element Type (DET) 1 DET for each data-valued argument of the service 1 DET for the capability to send messages 1 DET for the (Accept/Cancel) of the execution. action service File Type Referenced (FTR) 1 FTR for the legacy view If integrity constraints are defined, count one FTR for each new class referenced in the formula.
130
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 is referenced in these formulas. 4.1.4.2 Measurement rules for the Dynamic Model
The measurement rules described in this section are defined taking into account the complementary information of the Object Model in terms of object life cycles and inter-object communication. This information is captured in State Transition Diagrams (STDs) and Interaction Diagrams (IDs), respectively. STDs are 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 objects current state before a specific service can be carried out. Control conditions are conditions that are defined on object attributes to avoid the possible non-determinism for a given service activation. The interaction diagram (ID) specifies the inter-object 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 (see Table 13). It consists of 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). 131
Table 13. Measurement rules for the complexity of a class service (Dynamic Model)
File Type Referenced (FTR) Count 1 FTR for each new class referenced in the formula of a control condition, defined in the State Transition Diagram. Count 1 FTR for each new class referenced in the formula of a trigger, defined in the Interaction Diagram. Count1 FTR for each new class referenced in the formula of a precondition, defined in the State Transition Diagram
In a similar way, Table 14 shows the additional measurement rule defined taking into account the formulas associated to the definition of a legacy view service.
Table 14. Measurement rules for the complexity of a legacy view service (Dynamic Model)
File Type Referenced (FTR) Count1 FTR for each new legacy view or class referenced in the formula of a precondition, which is defined in the State Transition Diagram
Figure 30 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 if the course is closed.
132
Figure 30. Example of Event Measurement
4.1.4.3
Measurement rules for the Functional Model
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 the effect of a specific event on the value of an attribute of the class. An attribute can be categorized in the following types: push-pop, stateindependent 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. Stateindependent attributes are those that have 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 is satisfied. Table 15 shows the measurement rules related to the primitives of the functional model.
133
Table 15. Measurement rules for the Functional Model

File Type Referenced (FTR) Count 1 FTR for each new class referenced in the formula of a valuation definition Count 1 FTR for new class referenced in the formula of a control condition associated to the valuations
4.1.4.4
Measurement rules for the 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 16 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.
Table 16. Measurement rules for the instance interaction unit pattern
Data Element Type (DET) 1 DET for each unique attribute of an Object Identifier (OID). 1 DET for each attribute in the display set (only if it is different from the attribute(s) of an OID) 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 present messages (error, control, etc.) File Type Referenced (FTR) 1 FTR for each class or legacy view in the display set
In the IFPUG FPA method, the External Inquiry function type (EQ) has both an input side and an output side. In an IIU, the object identifier (OID) can be used to represent the input side of an EQ. For this reason, one DET for each variable that composes an object identifier is counted. On the other hand, the information to be presented which represents the output side of an EQ 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 134
from this class/legacy view. One DET for each class/legacy view attribute and one FTR for each referenced class/legacy view are counted. Conform to the IFPUG FPA counting rules, an attribute that appears on both the input and output sides of the query should be identified only once as a DET. In fact, the input side of an IIU in our approach is optional because the desired object can be selected in a previous phase as part of the specification of another interaction unit. 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 counting one DET for the ability to specify an action to invoke a logical process. 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 counting 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 by the capacity of the system to present messages. An instance interaction unit pattern is defined in Figure 31. This pattern allows us to review the information for a given employee depicted in Figure 28.
Figure 31. Example of an Instance Interaction Unit Measurement
Table 17 describes the measurement rules proposed to measure the complexity of a Population Interaction Unit (PIU). The main goal 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. In this pattern, the filter(s) mechanisms acts as the input part of the PIU and the display set as the output part of the PIU. With exception of the one 135
DET for each OID rule, all measurement rules for an IIU are applicable for measuring a PIU. In addition, for each defined filter, one DET for each datavalued 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. Again, conform to the IFPUG FPA counting rules, an attribute that appears on both the input and output sides of the query should be identified only once as a DET.
Table 17. Measurement rules for the population interaction unit pattern
Data Element Type (DET) 1 DET for each data-valued unique variable of a filter formula. 1 DET for each attribute in the display set (only if it is different from the attribute(s) of the 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 to present 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
1 FTR for each class referenced in a complementary information pattern of an object-valued filter variable
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. The MDIU 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, by applying the measurement rules described in Table 16 and 17 depending on the presentation patterns used in the definition of the master/detail parts.
4.2
Measurement method application
Figure 32 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 136
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 identify the elements in an OO-Method conceptual schema that contribute to the functional size of the system. Only the elements which are relevant to measurement are selected. The OOmFP measurement rules support the IFPUG FPA counting rules in the process of assigning numerical values to the identified elements.
Figure 32. A model of the OOmFP Measurement Procedure
137
For each step in this procedure, we also show the equivalent step in the detailed process model proposed by Jacquet and Abran [26] (see step 2 in Figure 5). According to the Jacquet and Abran process model [26], 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. According to Wandji et al. [111] such a model is just an instantiation of what is commonly called the metamodel12 of the considered measurement method, from specification documents of the software being measured. 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 that 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. [13]. This representation was applied to represent IFPUG FPA [30], Mark II FPA [31], and Full Function Points [16]. 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
12
It should correspond to the domain ontology (the explicit formal specifications of the terms in the domain and relations among them) related to the methods measurement procedure.
138
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 to 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 hand column of Figure 32.
4.2.1 Software documentation gathering

The documentation used to apply OOmFP included a requirements specification document for building a new Project Management System (PMS) for a company, the corresponding OO-Method conceptual model specification and a set of guidelines explaining how to apply the method. 4.2.1.1 User requirements specification
The system requirements are described in the format of the IEEE 830 standard [112]. Using this standard, a software requirements specification is described in terms of functionality (what the software is supposed to do from the users 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.). 139
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 as follows: when the company starts a new project, the employee in charge of the project must enter the data into the system. A project is created with the following data: identification number, description, name of the employee in charge (responsible), start date, estimated duration, estimated final date, actual duration (sum of the duration of the tasks performed until now), cost (sum of all tasks costs associated to the project), situation (0=developing, 1=small delay, <10% more than the estimated time, 2=large delay, >= 10% more than the estimated time, 3=finished), observations. The system should distinguish among three kinds of users: employee, employee in charge (responsible) and manager. An employee works in a Department. A department in the company can have several projects which the employees are working on. The types of project are: conceptual modelling, implementation and consultancy. Employees must register the tasks performed on the projects daily. 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 employee in charge by the manager. An employee in charge (responsible) will be able to have three active projects simultaneously and cannot be removed from this position while involved in an active project. In general, the responsibilities of the different types of users are: Employee: task maintenance Employee in charge: project maintenance, project type maintenance, task type maintenance, user maintenance Manager: promote employees, assign an employee in charge to a project, demote an employee in charge, and access all other functionalities in the system. The system should communicate with an external interface that will provide the resources associated to the projects. 140
4.2.1.2
OO-Method conceptual schema
Figure 33 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 33. Object Model for the PMS system
Figure 34 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, * 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.
141
Figure 34. State transaction diagram for class employee
Table 18 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 done using the predefined function today(). The attribute category is state-independent since its value depends on the latest service that has occurred.
Table 18. Functional Model example Class: Responsible, Attribute: start_date, Category: state-independent
Action promote Effect today()
Figure 35 shows an example of Population Interaction Unit (PIU_project_tasks) for the class Project. The purpose of this pattern is to present information about a project and all tasks associated to it. The definition of this pattern includes the following information:
Figure 35. Example of a Population Interaction Unit
142
4.2.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 built, 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. We therefore identify the following candidate data functions for the PMS system: ILFs: Project, ProjectType, Task, TaskType, Department, Employee, Responsible, and Manager. EIF:Resource Table 19 shows the client and server classes in the agent relationships declared in the Object Model for the PMS system.
143
Table 19. 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_instance, delete_instance, InsTask* modify_password* create_instance, modify_instance, modify_password TCREATE, modify_instance, 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_instance, delete_instance TCREATE, modify_instance, delete_instance create_instance, modify_instance, delete_instance InsDepartment*, DelDepartment*, DELETEALL create_instance, modify_instance, delete_instance, InsEmployee, InsResponsible*, DelResponsible*, InsDepartment, DelDepartment create_instance, modify_instance, 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. An external input (EI) is identified for each service. The services in capital letters are transactions. Services depicted with * denote shared events between classes and should be measured once. Therefore, excluding the shared events, we identify thirty-three services. Table 20 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 the exception of these two patterns, all of them are classified as external inquiries.
144
Table 20. EOs and EQs identification

Class Task Type/Name of Pattern Description IIU_task Shows information about a task. When a task is created or modified, the start and end hour is provided and the duration is calculated. PIU task Shows information about tasks filtered by date TaskType IIU_taskType Shows information about type of tasks Project IIU_project 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. PIU_project_tasks Shows information about a project and all tasks associated with. PIU_project_resources Shows information about a project, its responsible and all resources associated with it. MDIU_project Shows information about projects classified by their type. ProjectType IIU_projectTypes Shows information about type of projects Department IIU_department Shows information about a department MDIU_dep_employee Shows information about a department and all employees that work in it. Resource IIU_resource Shows information about a resource Employee MDIU_employee Shows information about an employee and all tasks that he/she works on. Responsible MDIU_responsible Shows information about a responsible and all projects that he/she works on.
4.2.3 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. 4.2.3.1 Application of the OOmFP measurement rules
Table 21 shows the DETs and RETs that were counted for each class when applying the measurement rules described in Table 9. Note that, because the Manager class has no attributes, it is not considered as an ILF. 145
For instance, the class Project has ten DETs and four RETs. Nine of the ten DETs are due to the data-valued attributes, and one due to the univalued aggregation relationship with the class ProjectType. One of the RETs is due to the project class, two due to the multivalued aggregation relationship with classes Department and Task, and one due to the multivalued aggregation relationship with the legacy view Resource.
Table 21. 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 2 2 7 3 5 1 RETs 4 2 2 1 3 2 2
Table 22 shows the DETs and RETs for the identified legacy view when applying the measurement rules described in Table 10. 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 22. Legacy view measurement
Legacy View Resource Attributes id_Resource, descr_resource, disponibility DETs 3 RETs 2
Table 23 shows the DETs and FTRs for an example service. These counts are obtained by applying the measurement rules described in Table 11. 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 objectvalued arguments).
146
Table 23. Class 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 24 shows the DETs and FTRs for the PIU_project_tasks Population Interaction Unit (shown in Figure 35) of the class Project. It is obtained by applying the measurement rules described in Table 17. 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 24. Example of a PIU measurement
Pattern Type PIU Pattern name PIU_project_tasks DETs 14 FTRs 3
4.2.3.2
Application of the IFPUG counting rules
Once the function elements (DETs, RETs and FTRs) have been identified, IFPUG tables [14] 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 Table 21 and Table 22, all of them are found to be in the low complexity category. The service create_instance() of the class Project shown in Table 23 has a high complexity. Finally, the presentation pattern PIU_project_tasks shown in Table 24 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 8. 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 147
(EIF) having low complexity are identified. Applying the weights described in Table 8, the obtained functional size for data functions is: OOmFPD = 49 + 5 OOmFPD = 54 Wich regard to the transactional functions, 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 Table 8, 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. Next, we explain how the OOmFP approach was designed and improved using action research.
4.3
Field testing: applying action research in the design of OOmFP
The OOmFP proposal was developed in the context of two R&D contracts with the company CARE Technologies. Table 25 shows the most important facts that occurred during the first R&D contract. The participation of the researcher (OO-Method group - OOM) and the critical group of reference (CARE) are also shown. The second contract involved the empirical validation of the OOmFP and it is out of the scope of this chapter. The objective of the first two tasks of the project was to identify the participants and their roles (T1 and T2). This is necessary to be able to promote a collaborative activity between the participants. Next, the researcher prepared a presentation about FSM (T3 and T4), and all the participants 148
discussed the state of the art in FSM as well as its application to size OO systems (T5). The objective was to delimit the scope of the work to be done. For instance, the advantages of defining a new FSM method or of adapting an existing one were discussed. We decided to adapt the IFPUG FPA due to the fact that it is the most widely used FSM method in industry and a standard approved by ISO.
Table 25. Action research in the design of OOmFP
Module
2001 M1: Task planning M2: Problem statement
Task
Fact
Participants
CARE OOM
M3: FSM procedure definition
M4: OOmFP Application 2002 M5: OOmFP Automation
Starting the R&D contract Advanced OO-Method T1 Identification of the participants T2 Establishment of roles and responsibilities T3 Preparation of a presentation about FSM T4 Analysis of the state of the art in FSM methods for object-oriented systems T5 Discussion of the state of the art in FSM and planification of the work to be done. T6 Definition of the initial proposal (OOmFP) T7 Technical meetings to discuss the initial proposal T8 Improvement of the initial proposal T9 Extension of OOmFP T10 Technical meetings to discuss the extension T11 Improvement of the OOmFP proposal T12 Preparation of a Measurement Manual for OOmFP T13 Application of OOmFP in real-world projects T14 Identification of problems and inconsistencies T15 Improvement of the OOmFP proposal T16 Improvement of the OOmFP Measurement Manual Putting OOmFP into practice T17 Formalization of the measurement rules T18 Design of a metamodel in ONME to represent OOmFP T19 Improvement of the metamodel T20 Automated generation of a measurement tool from the metamodel T21 Integration of the measurement tool into the ONME suite tool T22 Use of the measurement tool in real-world projects T23 Comparison of the results obtained manually wich the results obtained with the tool T24 Customization of the OOmFP measurement rules
In task T6, we defined how to map the IFPUG FPA onto the OO-Method. The phases of the measurement process and a set of measurement rules were defined. Specifically, we defined how to identify data and transactional 149
function in an OO-Method conceptual schema. In addition, we defined measurement rules to determine the complexity of each identified function. However, such a set of measurement rules only considers the static viewpoint of an OO system including measurement rules for the complexity of a class, legacy view, service and presentation pattern. We then initiated a series of technical meetings to discuss the initial proposal and to improve it (T7 and T8). An extension of the OOmFP was proposed to include measurement rules for the Dynamic Model. This extension (T9) involved the definition of new measurement rules for the behaviour of the OO system in terms of valid object lives and interaction between objects (Table 13 and 14). In this extension, we also consider other OO conceptual modeling aspects such as the type of aggregation relationship (referential or inclusive). New rules for the OO system presentation viewpoint such as count 1 FTR for each class referenced in a complementary information pattern of an object-valued filter variable were also defined. Similarly, we initiated a series of technical meetings to discuss the extension of the proposal and to improve it (T10 and T11). When the proposal was established, we reported all the work done in a Measurement Manual (T16). The objective of the next phase of the project was to put OOmFP into practice. We first formalized the OOmFP measurement rules to facilitate the automation of the measurement process (T17). A metamodel for OOmFP was defined in the ONME (T18). This metamodel was used to generate a measurement tool which was integrated in the ONME suite tool (T19-T21). We used the measurement tool to size the same real-world projects that were measured in a manual manner. We then compared these results with the results obtained with the tool. This contributed to the improvement of the tool (T22 and T23). Lastly, the OOmFP measurement rules were customized by a team of CARE Technologies (T24) to support changes that occurred in the primitives of the conceptual models, especially with the structuring of the Presentation Model. The use of action research supposed successive refinements of the OOmFP proposal through several typical cycles of planning, action, observation, and reflection. It also allowed the collaboration between researchers and practitioners, facilitating the knowledge transfer between them and bridging the gap between research and practice.
150
4.4
Comparison with related work
OOmFP is a first-category of FSM methods since it was designed to be conform with IFPUG FPA counting rules. Table 26 shows a comparison between OOmFP and the other FSM methods that are compliant with IFPUG FPA.
Table 26. Comparison between first category FSM methods and OOmFP
Criteria Static Dimension Dynamic Dimension Covers all OO concepts? Automated Support Validated? Empirical data available? IFPUG proposal Lehne proposal P Fetcke et al. proposal Uemura et al. proposal P OOmFP
As shown in the table, all the proposals take into account the static dimension of an OO system captured in an Object Model in terms of static relationships between objects. The dynamic dimension captures the life cycle of individual objects and the interactions among objects. It helps establish all control states, which a system or an object can be in, and helps establish local control flow. OOmFP is the only proposal that provides measurement rules to measure the behaviour of an OO system in terms of object life cycles and inter-object communication. The measurement rules are based on State Transition Diagrams and Interaction Diagrams. Basically, OOmFP considers that FTRs can be counted based on the definition of a class in terms of preconditions, control conditions and triggers. These primitives can be used to express the functional user requirements, increasing the number of FTRs of a class, hence its functional size. In addition, OOmFP also provides measurement rules for a Functional Model. This means that the semantics associated to the change of an object state can increase the number of FTRs for a class, hence its functional size. The Lehne [42] and the Uemura et al. [76] proposals partially (depicted with P) consider the dynamic dimension of a OO system (i.e., object 151
interaction). In the case of the Lehne proposal, it is represented in collaboration diagrams. The Uemura et al. proposal uses sequence diagrams to identify the transactional functions and five patterns are proposed to represent the different kind of interactions between the user and the system. With regard to the third criterion (covers all OO concepts?), only OOmFP and the Fetcke proposal [43] deals with all the OO concepts. For instance, the other proposals do not consider the kind of structural relationships between classes (i.e., inheritance, aggregation, composition) to properly identify the logical files. In OOmFP, the following OO concepts are dealt with and used for measurement purposes: objects, associations, generalizations / specializations, aggregations (referential and inclusive), states, events, transactions, triggers, control conditions, state changes, precondition, and valuations. The OOmFP and the Uemura et al. [48] proposals are those which provides automated support for measuring functional size from conceptual schemas. OOmFP is fully automated from the information contained in an OO-Method conceptual schema. Automatic data collection does not only reduce the risk of errors but also decreases the work effort for measuring functional size. The following criterion to be considered is validation. The validation of a measure is essential in order to use it with confidence. Although the principles of software measure validation are well accepted, there is still little evidence of the validity of the functional size measures used in industry. Table 26 shows that the Uemura et al.[48] and the Fetcke [43] proposals address this issue. In the case of Uemura et al.[48] a study was conducted to compare the results obtained with a tool to the results obtained by a FPA specialist of a software organization, who manually sized the same specifications. Fetcke et al. [43] conducted a case study with three industry projects and compared the results obtained with the approaches proposed in the literature. However, the references of the proposals were not mentioned. Despite these studies on the validation of FSM measures, no methodology for the systematic evaluation of the validity of the proposed functional size measures is found in the literature. This criterion will be addressed further in this thesis. Finally, with the exception of Lehne proposal, all the other proposals provide some empirical data available. This comparison shows that OOmFP is the only proposal that fulfills all the criteria described in Table 26.
152
4.5
Conclusions
In this chapter, we have presented a functional size measurement procedure, called OOmFP, for object-oriented systems based on the information contained in conceptual schemas. This method enables the quantification of the functional size of OO systems at an early stage of the development lifecycle. OOmFP is compliant with 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 OO-Method (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 such as UML. OOmFP adds a precise measurement procedure, so this should improve the reproducibility of measurements when OO-Method conceptual schemas are used. In addition, OOmFP makes FPA more applicable to size systems based on object-oriented conceptual models. The design of OOmFP 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 Fetckes generalized representation of functional size measurement methods that have a dataoriented metamodel. As a proof of concept, the application of the procedure was illustrated with a case study. OOmFP was adopted and automated by a local company in Spain and is now being applied to several real-world projects. The experience gained has allowed us to put this method into practice and to refine the proposed measurement rules. In addition, the design of OOmFP was carried out using the principles of action research. This allowed us to test the OOmFP in an organizational context using real practitioners and the evolution of OOmFP as a result of experience in practice. Therefore, it is an appropriate research method to use in the exploratory phases of the research.
153
Chapter 5
Extending OOmFP for Sizing Web Applications

This chapter discusses the differences existing between traditional software development and Web development projects. An extension of OOmFP for sizing Web applications (OOmFPWeb) is then proposed and we present the design of the measurement method and its application in a case study.
5.1
Introduction
The World Wide Web was originally designed to present information using a simple structure primarily based on hyperlinked documents. However, in the last few years a new type of software, so-called Web applications, has been established in the business world. This new environment has also created a new research field called Web engineering [113] [114] [115]. Its main purpose is to apply engineering principles to develop and maintain high quality Web applications. A Web application can be defined as a software application that is executed in a Web browser environment. It can have the same complexity as a traditional software system. In fact, a complexity of a Web application can vary widely: from small applications (i.e., intranets) to large applications distributed in the Internet (i.e., Web portals). The following are other examples of Web applications: online newspapers and banking, electronic shopping, chat groups, etc.
Chapter 5. Extending OOmFP for Sizing Web Applications
In order to classify the different kinds of Web applications that currently exist, Ginige and Murugesan [115] proposed the following seven categories: informational, interactive, transactional, workflow, collaborative work environments, online communities and marketplaces, and Web portals. They also state that a given Web application may belong to more than one category. Developing Web applications is significantly different from traditional software development and poses many additional challenges. According to Reifer [49], these differences affect the software development methods and technology, development team, among others. Basically, Web projects differ from traditional software projects in two key dimensions: the rate of release is higher; and the extent of what is deployed in each release is smaller. The traditional balance between the project tradeoffs of time, cost, and quality is therefore changing. The nature of Web development forces project managers to focus primarily on the time variable in order to achieve the required short cycle times. For instance, the development life-cycle time is shorter than 6 months, within an average life-cycle time of 3 months. Because of this imbalance, several problems with Web projects have been observed such as exceeding budgets and unknown or bad product quality [50]. To avoid a Web crisis [116], development approaches are needed that provide high-quality Web applications on time and within budget. Over the last years, several development methods have been proposed that specifically aim at Web application development such as OOHDM [51], WebML [52], W2000 [53], OOH [117] and OOWS [54] [55]. Of these proposals, those that start with a user-defined problem domain representation (i.e. conceptual model) of the Web application seem to be the most promising. Adopting such a method, however, poses new problems to the Web project manager, in particular with respect to resource estimation and project planning. A fundamental problem in this context is the size measurement of the future Web application based on its conceptual model. The functional size measurement (FSM) methods used in industry (mainly Function Points Analysis (FPA) [14]) date from a pre-Web era. None of the ISO-standardized FSM methods (i.e. FPA, COSMIC [17], Mark II Function Points [118]) were designed taking the particular features (i.e., navigation, presentation, personalization, etc.) of Web applications into account. Hence, existing FSM methods need to be adapted or extended to cope with Web application development projects. 156
Some approaches have been proposed in the literature to size Web sites and applications [49] [93] [94]. The main limitation of these approaches is that they apply measurement to the final software product (i.e. the implemented Web application), and hence depend on the implementation technology used. Furthermore, for project resource estimation purposes this type of measurements come too late. What is needed is a timely and implementation-independent FSM method that is based on the user-defined requirements captured in the conceptual model of the Web application. In order to address this problem, in this chapter, we present an extension of OOmFP to cope with Web applications. We called this extension OOMethod Function Points for the Web (OOmFPWeb). The aim of OOmFPWeb is to size Web applications that were developed or maintained using the OOWS (Object-Oriented Web Solutions) [54] [55] approach. It adds to OO-Method the required expressiveness to capture navigational and presentational features of Web applications. Next, we present OOmFPWeb following the steps of the Jacquet and Abran measurement process [25].
5.2
Design of the measurement method
5.2.1 Definition of the objectives

In terms of the Goal/Question/Metric (GQM) template for goal-oriented software measurement [74], the goal of this chapter is to extend OOmFP for the purpose of measuring Web applications with respect to their functional size from the point of view of the researcher. The context refers to OOWS conceptual schemas of Web applications.
5.2.2 Characterization of the concept to be measured

The entity to be measured consists of OOWS conceptual schemas. It is composed of the classical OO-Method conceptual schemas (Object, Dynamic and Functional models) enhanced with Navigational and Presentation models to capture the specific characteristics of Web applications. The attribute to be measured is functional size as defined by ISO/IEC 14143-1 [9]. 157
5.2.3 Selection of the metamodel

Our objective is to extend OOmFP by incorporating new rules to measure presentational and navigational features of Web applications. Therefore, in essence we assume the same metamodel as IFPUG FPA. These measurement rules are defined by mapping the concepts of the IFPUG FPA metamodel onto the OOWS conceptual modeling primitives. 5.2.3.1 Mapping between concepts
The OOWS approach extends OO-Method by introducing two conceptual models: the Navigational Model, which captures the navigation semantics of a Web application, and the Presentation Model, which contains patterns that specify how a navigational context will be visualized. It is a simplified presentation model that is used in conjunction with navigational patterns. According to the OOWS approach, a Web application has the following perspectives: Data: the information that is maintained by the application. This information is defined in the Object Model. Process: the computations that the application performs are defined in the Object Model along with a precise definition of the semantics associated to object state changes in the Functional Model. Behaviour: the dynamic interactions of an application in terms of valid object lives and inter-object interaction, defined in the Dynamic Model. Navigation: the navigational structure of the application, defined in the Navigational Model. Presentation: the user interactions with the applications Web interface, defined in the Presentation Model. OOmFPWeb assumes that the five model views of the OOWS conceptual schema contain all the elements that may contribute to the functional size of the Web application. The OOWS conceptual schema is thus the basis for identifying these elements. The kind of elements that are relevant for the functional size measurement of a Web application are described in the OOmFPWeb Measurement Abstract Model. Given the conformity of OOmFPWeb to IFPUG FPA, this abstract model is in essence the same as the metamodel underlying FPA. 158
It should be noted, however, that the Data, Process and Behaviour perspectives are the same as those described for OO-Method conceptual schemas. It implies that the measurement rules described in Chapter 4 is still valid for sizing Web applications. Given the above-mentioned challenges for Web projects, we next formulate some mapping rules that adapt the concepts of the IFPUG FPA metamodel to the Web Engineering environment. Mapping Rule 1. A user view is defined in terms of IFPUG FPA concepts as a formal description of the users business needs in the users language. A user can be a person that specifies the system requirements, a final user or an external system that communicates with the software application. In general, there are three kinds of final users in a Web application: anonymous users, registered users and administrators. Anonymous users can be anyone who connects to the application. Registered users can access specific functionality that was designed for this kind of audience. Finally, administrators maintain the application. This classification can be more specific depending on the domain of the Web application. For instance, in the academic domain, Olsina et al. [119] identified three general views of a Web application: the visitors view, the developers view, and the managers view. Within the visitors view, three different audiences are identified: students, academic personnel (researchers and professors), and sponsors. In OOWS, each kind of user that interacts with a Web application is considered to be an agent. A navigational map is built to represent the information and the functionality that an agent can access as well as the valid paths that she/he can go through the application. Therefore, we propose the following mapping rule for identifying a user view in our proposal: Accept each navigational map defined in the OOWS navigational model as a user view of the Web application. Mapping Rule 2. The measuring scope limits which functionality is measured in a particular measurement (a subset). In order to properly define the measuring scope, the user view should be previously established. In fact, the user view defines how the user sees the application. This is an important activity before measurement because in a Web environment this view can vary. For instance, a Web portal offers a variety of Internet services from a single location. It can be viewed as different applications in the same location. Thus, the user can view the portal as a single application or as separate applications. 159
Therefore, how can a correct measuring scope be defined? This is one of the problems to be deal with when designing FSM methods for Web applications. In our approach, this problem is solved since we measure conceptual schemas that were previously defined from the user point of view. Using the OOWS conceptual model primitives, one or more applications can be defined in accordance with the business goal and the requirements of the Web application. As a result, three measuring scopes can be defined in OOmFPWeb taking into account the type of Web projects: A complete Web application (taking into account all agents and their corresponding navigational maps), A navigational map for one agent (to measure the application functionality for a specific kind of user), A navigational context. The first measuring scope is more concerned with application development (where all functions specified in the requirements document are included), whereas the other two are more appropriate for maintenance of Web applications (where the functionality of the application(s) reflects the impact of the functions being added, changed or deleted). Mapping Rule 3. The application boundary indicates the border between the software being measured and the user. We determine the application boundary from the user point of view. In OOWS, the system boundary is an imaginary line in the Navigational Model that can be identified by applying the following rule: Accept each Agent as a user of the Web application. Mapping Rule 4. Data and transactional functions. The main idea used to establish the mapping between IFPUG FPA concepts and the OOWS primitives (see Table 27) is to consider navigational contexts as external inquiries (EQ). In IFPUG FPA, an EQ is defined as an elementary process that sends data or control information to the user (refer to Table 27 for a complete definition). In OOWS, a navigational context represents an interaction unit with the user where information can be visualized and services can be executed. Later, navigational contexts are materialized as Web pages following a code generation strategy. However, a navigational context is measured only once, even if it is inherited by several agents. 160
Table 27. Mapping the IFPUG FPA concepts to OOWS primitives

Function
EQ
IFPUG FPA
An elementary process that sends data or control information outside the system boundary. Its primary intent is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, nor is the behaviour of the system altered.
OOWS
A unique Navigational Context defined in the Navigational Model. The intent is to present information to the user without altering the system behaviour.
5.2.4 Definition of the numerical assignment rules

In this substep, the measurement rules that lead to the assignment of a numerical value to the functional size of an OOWS conceptual schema are defined. Given a conceptual schema produced during the OOWS conceptual modeling step, OOmFPWeb is calculated as follows:
OOmFPWeb
(4)
= OOmFP
Data
+ OOmFP
Transactio n
Where:
OOmFPData =
OOmFP
i =1
n i =1
class
+ OOmFPlegacy view
j =1
w
(5)
OOmFPTransactio n = OOmFP service +

x =1
OOmFP
y =1
nContext x y
(6)
In the same way, the size of a Web application is measured in an early phase of the development life cycle by measuring the data and transaction functions. It could be noted that the Data part remains the same. In the transaction part, we incorporate the size related to the navigational and presentation features of a Web application, where x corresponds to each unique navigational context of a navigational map, and y corresponds to each navigational map of a Navigational Model. Next, we introduce the proposed measurement rules for the OOWS conceptual model views. 161
5.2.4.1
Measurement rules for the Navigational Model
As in IFPUG FPA, the complexity of a navigational context (i.e. EQ) is determined by counting the number of Data Element Types (DET) and File Type Referenced (FTR). Table 28 and 25 describe the measurement rules proposed to identify the DETs and FTRs for a navigational context, respectively.
Table 28. Measurement rules for a navigational context (navigational perspective)
Data Element Type (DET) 1 DET for each attribute of the navigational class 1 DET for each contextual dependency relationship 2 DETs for each context relationship 1 DET for each service defined in the navigational classes 1 DET for each service link associated to a service 1 DET for each attribute defined in the formula of a population filter 1 DET for each attribute defined in the formula of a information access filter 1 DET for each attribute defined in the formula of an index File Type Referenced (FTR) 1 FTR for each navigational class 1 FTR for each new class referenced in the population filter formula 1 FTR for each new class referenced in the information access filter formula 1 FTR for each new class referenced in the index formula
According to these tables, DETs correspond to attributes in the navigational classes, and FTRs correspond to navigational classes that appear in the navigational context or in a population filter formula of a navigational class. Each navigational class is considered to be a group of data that is logically related and user recognizable. However, only the classes that have at least one attribute or service should be considered. This is because a class without attributes or services indicates that a logical data file is not read by the transactional function. No element crosses the boundary. Additionally, the IFPUG suggests counting one FTR for each ILF or EIF read during the processing of the elementary process. In order to explain the proposed measurement rules we use a typical ecommerce application for CD sales. This application allows anonymous users (Internauts) to explore and purchase CD albums online. Furthermore, 162
Internauts can sign in to access personalized information according to their preferences. The navigational context Albums and its corresponding measurement are shown in Figure 36. The information presented in this context represents instances of the navigational class Album complemented by information of the class Artist.
Figure 36. Albums Navigational Context Measurement
By applying the measurement rules of Table 28, each attribute of each class is identified as a DET. Also, one DET for each contextual dependency relationship or context relationship is counted. This is because IFPUG FPA suggests counting one DET for each piece of data that exists because the user requires a relationship with another ILF or EIF (navigational classes in this case). Finally, both navigational classes that appear in the context are considered as FTRs as they are logically related groups of data that are recognizable by the Internaut. Now suppose that we need to provide an indexed access to the Albums context using the attribute title. The following index is defined as follows: ATTRIBUTE INDEX Album_title ATTRIBUTES title, price, photo LINK ATTRIBUTE title Then, one more DET is added to the measurement of the context Albums because of the attribute photo. The other attributes are not considered since they have been previously counted. Figure 37 shows the navigation context Album_Track for the Internaut user. This context includes information about albums and their respective tracks. From this navigational context, the Album_Details context can be 163
reached by selecting the album title. In addition, after executing the service purchase, the Internaut will navigate to the context ShoppingCart.
Figure 37. Album_Track Navigational Context Measurement
Applying the same reasoning as above, we consider the attributes of the navigational classes and the relationships between them to be DETs. Since the link attribute defined in the context relationship expresses navigation between contexts (allows the user to access another EQ), one DET is counted. For the same reason, one DET is counted for the service link because it represents navigation to the context ShoppingCart after the service execution. These measurement rules are related to the complexity of the Web application, indicating readability between contexts. Finally, one more DET is counted for the purchase service. Figure 38 shows the navigation context ShoppingCart for the Internaut user. This context shows all items that were selected by the Internaut, their corresponding data (title, price, quantity) as well as the name of the artist. From this context, two target contexts can be reached: the Album_Details context by selecting the album title and the Invoice context by executing the service checkout. The Internaut can also perform services to modify the number of items, to delete items, to save the selected items to buy later, and to proceed to the checkout. Additionally, a population filter is defined for the class Internaut to show the shopping cart of the connected user. The formula of the filter is: ShoppingCart.internaut = #internaut#
164
Figure 38. ShoppingCart Navigational Context Measurement
In the same way, we consider each attribute and service of the navigational classes, the relationships between navigational classes, the link attribute, and the service link to be DETs. Additionally, one FTR is counted for each navigational class. Finally, as the population filter does not imply the reference to any other navigational class, no more DETs and FTRs are considered. 5.2.4.2 Measurement rules for the Presentation Model
The measurement rules proposed for the Presentation Model help to identify additional DETs for a navigational context. They represent the size of the application related to additional properties that are defined in the navigational contexts for improving the access and the visualization of the information. Table 29 describes the measurement rules proposed to identify additional DETs for a navigational context. According to this table, four DETs are counted for the sequential access mode since this pattern provides mechanisms to go to the next, previous, first, and last logical block (used to 165
arrange the instances of a navigational context). Otherwise, if a random access mode is specified, five DETs are counted because in addition to the same mechanisms of the sequential mode, this pattern allows the user to go to a desired logical block.
Table 29. Measurement rules for a navigational context (presentation perspective)
Data Element Type (DET) If a sequential access mode is defined, count 4 DETs, whereas, if the access mode is random, count 5 DETs. 2 DETs for the cardinality pattern (static). If the cardinality is dynamic, count 3 DETs. 1 DET for the ordering criteria of the navigational
context
1 DET for the ability to specify an action to be taken 1 DET for the application capacity to present messages (error, control, etc.)
On the other hand, the cardinality pattern allows the user to navigate between logical blocks. It provides mechanisms to go to the previous and to the next logical block. Because of these mechanisms, two DETs are counted for the static cardinality (the same number of instances in each logical block). However, a dynamic cardinality implies an additional facility to the user: the number of instances of a logical block can be defined at run-time. Consequently, three DETs are counted for cardinalities of this kind. This is because of the capability to go to the previous and next logical blocks, and to specify the number of instances that will be presented in each block. We also count one DET for the capability of ordering the instances of a navigational context. Finally, two more DETs are counted to be compliant with IFPUG FPA counting rules: one related to the actions that a user can perform and the other related to the system capability to provide messages. However, if an access mode is defined in conjunction with a cardinality pattern, the measurement is as follows: A sequential access mode with a static cardinality pattern, count only 4 DETs. A sequential access mode with a dynamic cardinality pattern, count 5 DETs. A random access mode with a static cardinality pattern, count 5 DETs. A random access mode with a dynamic cardinality pattern, count 6 DETs. 166
In order to illustrate the application of these rules, suppose that we are defining the following facilities to the context Album_Track: Navigational class Album: layout (register), pagination (static cardinality 6), access mode (sequential), ordering criteria (price, DESC) Contextual dependency relationship between Album and Track classes: layout (Master-Detail: tabular) and ordering criteria (name, ASC) The navigational context Album_Track including the presentational features are depicted in Figure 39. As is shown, additional DETs are counted for the ordering criteria, cardinality, access mode plus two others DETs in order to be compliant with IFPUG FPA. The context Album_Track now has eighthteen DETs.
Figure 39. Navigational context Album_Track measurement with presentational features
167
5.3
Measurement method application
Figure 40 shows a simplified representation of the OOmFPWeb Measurement Procedure. According to this procedure, functional size measurement requires two steps of abstraction, which are called the identification step and the measurement step. In the identification step, an OOWS conceptual schema is built from the User Requirements Specification and includes the following perspectives of a Web application: data, process, behaviour, navigation, and presentation. An OOWS conceptual schema corresponds to the OO-Method classical framework enhanced with two complementary views: the navigational model and the presentation model. OOmFPWeb assumes that the five conceptual model views of the OOWS conceptual schema contain all the elements that contribute to the functional size of a Web application. The OOWS conceptual schema is thus the basis for identifying these elements. This phase corresponds to the software documentation gathering activity in the Jacquet and Abran measurement process.
Figure 40. A simplified model of the OOmFPWeb Measurement Procedure
168
The kind of elements that are relevant to the functional size measurement of a Web application are described in the OOmFPWeb Measurement Abstract Model. Elements of this kind are more aptly defined as Base Functional Component (BFC) Types, as in the ISO/IEC standard for functional size measurement [9]. Given the conformity of OOmFPWeb to IFPUG FPA, the Measurement Abstract Model is in essence the same as the metamodel underlying FPA (basically distinguishing between five BFC types: internal logical files, external interface files, external inputs, external outputs, external inquiries [14]). The difference with the IFPUG FPA metamodel is that the BFC types are described in terms of the OOWS conceptual primitives. To identify BFCs and classify them according to the defined BFC types, OOmFPWeb offers a collection of measurement rules. In the measurement step, an abstract model of the required Web application is specified by applying these OOmFPWeb measurement rules. This phase corresponds to the construction of the software model activity in the Jacquet and Abran measurement process. After that, the functional size of each of the identified BFCs is quantified by rating their complexity and translating this complexity rating into a Function Points value, using the schemes provided by IFPUG. The corresponding activity in the Jacquet and Abran measurement process is the application of the numerical assignment rules activity. Finally, the functional size values of the BFCs are summed to obtain the functional size value of the Web application. Next, we illustrate the application of OOmFPWeb using the case study of the Project Management System introduced in Chapter 4.
5.3.1 Software documentation gathering

The documentation used to apply OOmFPWeb was the requirements specification of the Project Management System (PMS) introduced in the section 4.2.1.1. This specification is also presented in detail in Appendix A. In addition, we prepared a guideline with the measurement rules of the method (see Appendix A) for the purpose of facilitating the method application.
169
5.3.1.1
OOWS conceptual schema
According to Figure 40, an OOWS conceptual schema consists of the OOMethod classical framework enriched with two additional conceptual models to capture the navigational and presentational features of Web applications. As the perspectives of data, process and functionality were previously captured in the OO-Method conceptual schema shown in section 4.2.1.2, here we focus on presenting the navigational and presentation models for the PMS application. The construction of the navigational model first identifies the users of the application. The following users are identified for the PMS application: employee, employee in charge (responsible) and manager. Then, a navigational map is defined for each one of them. Figure 41 shows the navigational map of the employee user. It shows information about tasks and type of projects when an employee user connects to the PMS application.
Figure 41. Navigational Map of the Employee User
Figure 42 shows the definition of the Tasks navigational context of the employee user. This context includes information about the tasks of the employees (descr_task, date, startHour, endHour, duration) and their task types (id_taskType) by using a context dependency relationship. The description of the project (descr_project) as well as the corresponding project type (id_projType) are also shown using the same kind of relationship.
170
Figure 42. Navigational Context Tasks of the Employee User
In addition, employees can create, modify or delete tasks that they perform in a project. The presentation patterns indicate that the instances of the manager class Task will be presented in a tabular layout using a static cardinality (ten instances of tasks per logical block). Tasks will be classified by the startHour attribute. Sequential access is also provided to access the different logical blocks. Figure 43 shows the definition of the Type of Projects navigational context of the employee user. It includes information about the type of projects (id_projType, descry_projType) as well as the projects associated to this project type (id_project, descry_project) by using a context dependency relationship. A navigation capability to the Tasks context is defined using the context relationship between the navigational classes Project and Task. Both attributes id_project and descr_project are used as anchors to navigate to the Tasks context. Five instances of the ProjectType is presented in a tabular layout using a static cardinality. Project types will be classified by their description (descry_projType). Sequential access is also provided to access the different logical blocks. When the employee users navigate to the Tasks context they can see detailed information about their tasks in a given project. In addition, five instances of tasks per project are shown using a static cardinality with sequential access.
171
Figure 43. Navigational Context Type of Projects for the Employee User
Figure 44 shows the navigational map of the responsible user. It describes all navigational contexts that this user can access in the PMS application. Users of this kind will be able to manage employees, projects and tasks. As a responsible is also an employee user, two navigational contexts are inherited: Tasks and Type of Projects. However, for measurement purposes, these contexts are not taken into account. With the exception of the context Tasks all navigational contexts are accessible from any other context of the application.
Figure 44. Navigational Map of the Responsible User
172
Figure 45 shows the Employees navigational context of the responsible user. It includes information about employees (id_employee, fullname) and their department. It also includes the capability to navigate to the context Tasks to see the tasks of an employee. In addition, it includes the capability to navigate to the context Projects by using the project identifier (id_project) as anchor. Also, by clicking on the description of the project (descr_task), the responsible can also see the task of an employee associated to a project or add new employees and change their data or passwords. In terms of presentation patterns, the employee information (four instances each time) is shown in a tabular layout using static cardinality and sequential access. Information about tasks is shown in two ways: associated to an employee or to a project (using the master-detail pattern).
Figure 45. Navigational Context Employees of the Responsible User
Figure 46 shows the Tasks navigational context of the responsible user. When accessing this context the responsible user will see information about tasks as well as their type and the project associated with them. Also, the project type associated to a project is also shown. The responsible user can also create a new task, change it or delete it. Tasks will be shown (five instances each time) by startHour in a tabular layout. The instances of tasks will be accessed in a sequential mode. 173
Figure 46. Navigational Context Tasks of the Responsible User
Finally, Figure 47 shows the navigational context Projects of the responsible user. It shows information about projects, their type and the employees associated with them. The tasks of an employee in a given project are also accessible by selecting the link attribute descr_task. In addition, the responsible user can create new projects or modify an existing one.
Figure 47. Navigational Context Projects of the Responsible User
174
Projects will be visualized by the project type identifier (id_projType) in a tabular layout. Project instances can be accessed in a sequential mode using a dynamic cardinality. Also, the tasks associated to an employee in a project are shown. Figure 48 shows the navigational map of the manager user. It describes all navigational contexts that a manager user can access in the PMS application, which are the following: projects, type of projects, employees in charge, departments, employees and type of tasks. In addition, this user type can access the functionality for the other user types (employee and responsible).
Figure 48. Navigational Map of the Manager User
Figure 49 shows the Employees navigational context for the manager user. When accessing this context, the manager user will see information about all employees in the company as well as their departments. Employee information is presented by fullname in a tabular layout.
175
Figure 49. Navigational Context Employees for the Manager User
Figure 50 shows the Projects navigational context of the manager user. In this context, information about projects including their type is shown. In addition, the manager user can create a new project, or modify or delete an existing one. Presentation patterns are used to describe how the projects will be shown. In this case, four instances of projects are presented in a tabular layout. In addition, the manager user can go directly to a desired instance (random access). Project types will be presented following a master-detail pattern.
Figure 50. Navigational Context Projects of the Manager User
176
Figure 51 shows the Type of Projects navigational context of the manager user. This context presents information about type of projects as well as the projects associated to them. Project types are presented in a tabular layout, whereas projects are presented following a master-detail pattern. Project types instances are shown by its description (descr_projType) in a tabular layout. These instances can be accessed in a sequential mode using a static cardinality. On the other hand, the projects associated to this project type are shown using the same access mode and cardinality.
Figure 51. Navigational Context Type of Projects of the Manager User
Figure 52 shows the Type of Tasks navigational context of the manager user. It shows information about type of tasks as well as the tasks associated to them. With the exception of the services execution (create, modify and delete type of tasks), this context has the same design as the Type of Projects navigational context shown in Figure 51.
177
Figure 52. Navigational Context Type of Tasks for the Manager User
Figure 53 shows the Employees in Charge navigational context of the manager user. When accessing this context, the manager user can see information about employees in charge. This information is shown in a tabular layout using a static cardinality, and a sequential access mode.
Figure 53. Navigational Context Employees in Charge of the Manager User
Finally, Figure 54 shows the navigational context Departments of the manager user. It shows information about departments, their responsible and 178
the employees that work in it. In addition, there is a capability to navigate to the Employees in Charge context by selecting the link attribute fullname. The manager user can also create, modify or delete departments as well as insert a new employee, insert a new responsible, or delete a responsible.
Figure 54. Navigational Context Department for the Manager User
Departments will be presented by their description (desc_Department) in a tabular layout. It can also be accessed in a sequential mode using a static cardinality. Additionally, employees in charge associated to the departments will be presented using the master-detail pattern.
5.3.2 Construction of the software model

The software model for the PMS system is built by applying the OOmFPWeb mapping rules described in section 5.2.3.1. The measurement scope includes the complete Web application represented by the navigational maps of the three user types: employee, responsible and manager. The users of the PMS application are indicated by the agent Employee, Responsible and Manager. Then, for each navigational context, an external inquiry (EQ) is identified. Thus, for the PMS we therefore identify the following external inquiries: EQs for the employee user: Tasks and Type of Projects. 179
EQs for the responsible user: Employees, Projects, and Tasks. EQs for the manager user: Projects, Employees, Type of Projects, Employees in charge, Departments, and Type of Tasks.
5.3.3 Application of the numerical assignment rules

Finally, in order to obtain the functional size value for the PMS application, we first apply the OOmFPWeb measurement rules and then the IFPUG counting rules. 5.3.3.1 Application of the OOmFPWeb measurement rules
Table 30 shows the DETs and FTRs that were counted for each navigational context applying the measurement rules described in Table 28 and Table 29. For instance, the navigational context Tasks has twenty-three DETs and four RETs that are detailed as follows: Navigational Context Tasks DETs: 8 for the attributes in the navigational classes, 3 for the relationships between classes, 3 for the services in the navigational classes, 4 for the sequential access mode with static cardinality, 1 for the ordering criteria, and finally two for the application ability to offer actions and display messages. RETs: 4 for each one of the navigational classes that appears in the context.
Table 30. Navigational Contexts Measurement
User Employee Responsible Navigational Context Tasks Type of Projects Employees Tasks Projects Employees Projects Type of Projects Type of Tasks Responsibles Departments DETs 21 16 31 22 25 22 24 16 20 17 24 FTRs 4 2 4 4 3 2 2 2 2 2 3
Manager
180
Note that in the measurement of the navigational contexts Type of Projects, Employees and Projects (in the navigational maps of the employee and responsible users), the navigational class Tasks does not add complexity to the FTRs counting. This is because there are no attributes in the class, indicating that no DET crosses the boundary. 5.3.3.2 Application of the IFPUG counting rules
In this section, IFPUG tables [14] are used to classify the transactional functions as having low, average, or high complexity. With regard to the transactional functions (navigational contexts) shown in Table 30, the Type of Projects contexts of the employee and manager navigational maps are in the average complexity category. The rest of the navigational contexts are in the high complexity category. The functional size is then obtained by mapping the function types and complexity ratings into numbers that represent the amount of functionality that these functions contribute to the functional size of the Web application. The complexity levels are attributed by applying the complexity weights described in Table 8. Finally, these numbers are aggregated into an overall functional size value for the Web application. Therefore, for the PMS, three navigational contexts (EQs) having average complexity and eight having high complexity are identified. By applying the weights described in Table 8, the obtained functional size for navigational contexts is: OOmFPnContext = (3 * 4) + ( 8 * 6) OOmFPnContext = 60 In order to obtain the functional size for the transactional functions, we need to sum the obtained size for the navigational contexts (EQs) with the size for the services (EIs). As illustrated in section 4.2.3.2 (Chapter 4), we have identified nineteen services (EIs) having low complexity, eight services having average complexity, and six services having high complexity. Thus, the functional size for the transactional functions is calculated as follows:
OOmFPTransactio n = OOmFP service +
i =1 x =1 n w
OOmFP
y =1
nContext x y
OOmFPTransactio n = 125 + 60 OOmFPT = 185
181
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 Web application is: OOmFPWeb = OOmFP Data + OOmFP Transactio n OOmFPWeb = 57 + 191 OOmFPWeb = 245
5.4
Comparison with related work
Table 31 shows a comparison between OOmFPWeb and the other FSM methods proposed to size Web sites and applications. As can be observed, all the proposals take into account the static dimension of a Web application. However, OOmFPWeb is the only approach that deals with the dynamic dimension of a Web application. This suggests that the other approaches were defined to size static Web sites (i.e., a collection of static documents and tied together with links). However, the majority of the applications being used in the Internet today are complex Web applications. Such an application has more in common with traditional client/server applications rather than static Web sites.
Table 31. Comparison between OOmFPWeb and related work
Criteria Static dimension Dynamic dimension Navigation dimension Presentation dimension Automated support Validated? Empirical data available? IFPUG proposal Web Objects WebPoints Internet Points Data Web Points OOmFPWeb
182
Web Objects, Web-Points and OOmFPWeb are the proposals that provide measurement rules to size the navigation dimension of Web sites and applications. For instance, Web Objects considers the number of links counted from xml, html and query language lines as part of the size of a Web site. In contrast with these approaches, which measure functional size on the final product, OOmFPWeb measures the functional size from a Navigational Model, which captures the navigational semantic of a Web application at an early stage of the Web application development lifecycle. Another important dimension of a Web application is the presentation. Only the proposals of Internet Points [94] and OOmFPWeb provide measurement rules that explicitly address with the presentation dimension of a Web application. However, Internet Points is the only proposal that offers automated support to size Web applications. With regard to the fifth criterion (validated?), only Data Web Points (DWPs) and OOmFPWeb address some kind of validation. This criterion will be addressed further in this thesis. Finally, Web Objects, Data Web Points and OOmFPWeb have some empirical data available. To date there is no standard way of sizing Web applications. However, in accordance with the principles of functional size the most promising approaches seems to be those that focused on the functional user requirements representations excluding any implementation choices. Data Web Points and OOmFPWeb are the only proposals that follow a problem-oriented approach to size Web applications. However, DWPs represents functional size of a Web application from the point of view of its data model whereas OOmFPWeb assumes that the five model views (i.e., data, process, behaviour, navigation and presentation) of the OOWS conceptual schema contains all the elements that may contribute to the functional size of the Web application. This comparison also shows that with the exception of the automated support criterion, OOmFPWeb fulfills all the criteria described in Table 31.
5.5
Conclusions
In this chapter, we have presented the extension of OOmFP to size Web applications. It included a set of measurement rules to map the IFPUG FPA concepts onto the OOWS conceptual primitives. The contribution of our approach is to provide a functional size measurement procedure at the conceptual schema level. In consequence, the size of a Web application is 183
calculated in the problem space, improving the existing approaches that focus on the final software product. Thus, OOmFPWeb adds a precise measurement procedure, so this should improve the reproducibility of measurements when OOWS conceptual schemas are used. In addition, OOmFPWeb makes FPA applicable to size Web applications based on conceptual schemas. Although OOmFPWeb is designed to be used in conjunction with OOWS, many of the modeling primitives in its metamodel can also be found in other Web development methods, such as OOHDM [51], WebML [52], and OOH [117]. With the exception of the WebML that uses a data-oriented approach, the other methods follow an OO approach to define the Navigational Model. All these development methods provide primitives to model the Web graph, which is represented by navigational nodes and links between nodes. Furthermore, these methods share the same constraint: a valid navigation must be accomplished by traversing a path that exists in the underlying data/object model. Consequently, the measurement rules proposed to measure the navigational and presentational perspectives of a Web application are general enough to be applied to other Web development methods with minor adaptation. OOmFPWeb is currently being used to size several Web applications in different domains. It has been applied in an e-commerce application for ticket sales of a Theatre company, in a store of the Amazon (books store), and several academic applications. The experience gained has allowed us to put this method into practice and to refine the proposed measurement rules.
184
Part II
The Evaluation of the Functional Size Measurement Procedure
All the mathematical sciences are founded on relations between physical laws and laws of numbers, so that the aim of exact science is to reduce the problems of nature to the determination of quantities by operations with numbers. (Maxwell, On Faraday's Lines of Force, 1856)
Chapter 6
Validation of the Design of the Measurement Procedure

This chapter presents the first steps towards the theoretical validation of the functional size measure used by OOmFP. This attempt of validation is conducted using a formal framework called DISTANCE (Poels and Dedene, 1999) for software measure construction that satisfies the measurement needs of empirical software engineering research. In addition, we discuss the problems that were encountered when theoretically validating a FPAcompliant measure.
6.1
Introduction
The first type of validation relates to the output of the first step in the measurement process model of Jacquet and Abran [26] (see Figures 4-5). The objective is to demonstrate that the measure that is defined by the measurement method really measures the concept it is purporting to measure [29]. As the criteria that are used to verify this assertion are mostly derived from theory (in particular from Measurement Theory [120]), this type of validation is also known as the theoretical validation of a software measure [28]. In a broader context, theoretical validation is part of the evaluation of the design of the measurement method [121]. Apart from measure validity, the evaluation pertains to issues such as the definition of a measurement unit, the accuracy of the measurement method
Chapter 6. Validation of the Design of the Measurement Procedure
rules, the quality of the metamodel, and the soundness of the mathematical operations applied in the measurement rules (e.g. dimensional analysis) [28]. 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 masures was reported in the literature by Fetcke [13], Zuse [27] and Poels [122]. 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 have identified serious drawbacks with the underlying structure of Function Point Analysis with respect to the prescriptions of Measurement Theory. Abran and Robillard [56] have investigated the measurement scales used in the process of counting FPA. They observed that functional size measurement starts with absolute scales that are transformed into ordinal scales (losing information in this process). This is in agreement with the findings of Poels [123], who noted that many of the scale transformations within the FPA process are not allowed according to Measurement Theory. Also, Kitchenham et al. [28] confirm these findings after applying their framework for software measurement validation to function points. This evidence suggests that since OOmFP follows the underlying structure of IFPUG FPA, it inherits all the problems related to function points. In this chapter, we first analyze the previous research on the theoretical validation of FSM methods and discuss its implications for the validation of the design of OOmFP. Then, the DISTANCE framework for software measurement is introduced and used to validate some of the primitive functional size measures used by OOmFP. We conclude the chapter by pointing out the problems and the open questions in this kind of validation.
188
6.2
Previous research on the theoretical validation of FSM methods
Existing research on the theoretical validation for FSM methods was conducted using the prescriptions of the Measurement Theory [124] [120] [125]. We first present some terminology and definitions from Measurement Theory. Next, previous works on the theoretical validation of FSM methods are discussed.
6.2.1 Measurement Theory

The aim of Measurement Theory is to prescribe conditions for modeling and defining measures in general. Roberts [120] defined measurement as the assignment of numbers that correspond to or represent or preserve certain object relations. For instance, in the case of size, measurement is the assignment of numbers that preserve the observed relation greater than. Additionally, this theory provides an empirical interpretation of the numbers (of software measures) by the hypothetical empirical relational system. Using this interpretation, we can compare two objects a and b and say a is greater than b (a >b). We can also say a is equally great than b (a b). Consequently, we can say a is equally or greater than b (a b). The sign is an empirical relation. According to this theory, measurement is a mapping of properties of empirical objects to formal objects (e.g., numbers in a numerical relational system) by a homomorphism13 . This is usually called a function in mathematics. More formally, we can give these definitions: Definition 1. A relational system is defined as an ordered tuple (S, rel1,, reln, op1,, opm), where: S is a nonempty set of objects; rel1,, reln are ki -ary relations on objects in S (this means that the relation reli defines a relationship among ki objects); op1,, opm are binary operations on objects in S (this means that each operation operates on exactly two objects, producing a third object in S).
13
It occurs when two relational system have the same type. It is also a mapping that preserves all structures and relationships.
189
An example of an empirical relational system (real-world objects) is one with S being the set of all software systems, a binary relation bigger than or same size as, and a binary operation combine with. The binary relation orders or classifies these objects with respect to some attribute (size in the example). An example of a numerical relational system (formal objects) is one with S being the set of all nonnegative integer numbers, the binary relation, and the binary operation . Definition 2. Let A be a set of empirical objects. Let B be a set of formal objects, such as numbers. A measure is defined to be a one-to-one mapping : A B. The requirement that the measure be a one-to-one mapping from an empirical relational system into a numerical relational system guarantees that every object has a (only one) measure (i.e. a measure is a total function). However, it does not require that every number (in set B) be the measure of some object (in set A). Another concept used in measurement, and in particular on software measurement, is metric. Some (but not all) measures are metrics. A metric is a way of measuring the distance between two entities, and its precise mathematical definition is: Definition 3. Let A be a set of objects, let R be the set of real numbers, and let m: A R be a measure. Then, m is a metric if and only if it satisfies these three properties: m(x, y) = 0 for x = y m(x, y) = m(y, x) for all x, y m(x, z) m(x, y) + m(y, z) for all x, y, z We could allow other sets of numbers in this definition, as long as the set includes zero and the addition and less-than-or-equal operations are defined on the set. Definition 4. Let A = (SA, relA1,, relAn, opA1,, opAm) be an empirical relational system, and let B = (SB, relB1,, relBn, opB1,, opBm) be a numerical relational system . Let :SA SB be a measure. Then the triple (A, B, ) is a scale if and only if relAi (ai1,, aik) relBi ( (ai1),, (aik)) and (a opAj b) = (a) opBj (b) for all values of i and j, and for all a, b, ai1,, aik SA. 190
Definition 5. Let (A, B, ) be a scale, where the set of objects in B is the set of real numbers. Let the notation (A) mean the set of all real numbers that are measures of some object in A. Then a mapping t: (A) B is defined to be an admissible transformation if and only if the triple (A, B, t o ) is also a scale. We can interpret this definition as saying that if we have one scale of measure for a certain kind of object, we can formulate another by applying admissible transformations to the original scale. Roberts [120] defined a classification of scale types according to their admissible transformations (see Table 32):
Table 32. Measurement scale types and transformations
Scale Type Nominal Ordinal Interval Ratio Absolute Transformation t Any one-to-one g g: strictly increasing function t(x) = a x + b t(x) = a x t(x) = x Permissible Arithmetic Operations Greater than or less than operations Addition and subtraction of scale values Multiplication and division of scale values Counting
According to Table 32, the simplest scale is nominal. Its basic empirical operation is established by the determination of equivalence classes (e.g., the numbers 1, 2, 3, 4, 5,...). Therefore, a measurement in the nominal scale is a classification of objects with no inherent ranking between the classes; the only admissible transformations are those that preserve the fact that the objects are different, such as the one-to one transformations. An ordinal scale is a ranking of objects according to some ordering criterion. In this kind of measurement, the empirical objects are ordered (greater or smaller than), but differences between values are not important (e.g., Likert scales, rank your degree of satisfaction on a scale of 1 to 5). The interval or distance scale, which is more complex, is used when the equality of intervals between values is meaningful. An example is the measurement of the temperature in Celsius scale: the water is freezes at 0C, and boils to 100C. In the interval scale, the differences between the values are significant, but not the values of the own measurement (e.g., 30-20=2010, but 20/10 is not twice as hot). 191
The ratio scale is more sophisticated. It is used when the equality of ratios between values is meaningful. Its features are: equal distance between the degrees, it supposes a natural zero, it provides information on the order of the objects according to an attribute and the intervals among them. Measurements of height, weight, length are typically ratio variables. It is meaningful to say that 10 m is twice as long as 5 m. This ratio holds true regardless of which scale the object is being measured in (e.g. meters or yards). This is because there is a natural zero. Finally, in a measurement on the absolute scale, no transformation is significant (i.e., count of objects). Another requirement in this theory is that the measurement needs to be meaningful. It concerns every numerical statement involving numerical images. For instance, if f(ai) and f(aj) are numerically different, is the statement f(ai) > f(aj) meaningful? A statement is meaningful if (and only if) it holds under all admissible transformations. It can be formally defined as: Definition 6. Let (A, B, ) be a scale, where the set of objects in B is the set of real numbers. A statement about the measures (a) of objects in A is meaningful if and only if the true value of that statement is unchanged after applying any admissible transformation to . Next, we discuss some works that use measurement theory in conjunction with specific measurement structures in order to theoretically validate FSM methods.
6.2.2 Validation of FSM methods using Measurement Theory

Zuse [27] applied the theorems of modified extensive structure to validate the FPA measurement function at the ratio scale level. He demonstrates that the functional size property measured by FPA does not assume this structure. In order to illustrate the structure of the FPA method, Zuse uses the extensive structure to define a measure assuming an additive combination rule as follows: UFP (P1 o P2) = UFP (P1) + UFP (P2), where: UFP is the unadjusted function point 192
P1 and P1 are FPA measures products P1 o P2 is the empirical concatenation of two projects The empirical meaning of the numerical sign + and the empirical concatenation operation P1 o P2 were studied. First, it was assumed that the data and transactional functions of the two projects have the same weights and that both projects have the same logical functions. If the combination rule above holds for the measure UFP, then UFP (P1 o P2) is the sum of the sizes of the logical functions of the two projects. In some cases this can occur, but, there are other cases in which the same logical function can appear in both projects. This fact suggests the following combination rule: UFP (P1 o P2) = UFP (P1) + UFP (P2) UFP (Intersection (P1, P2)) According to Zuse, the first part of the concatenation rule (UFP (P1) + UFP (P2)) can assume an extensive structure and can lead to non-additive ratio scales. However, the second part of the rule (UFP (Intersection (P1, P2)) violates the extensive structure. Consequently, the UFP measure does not assume an extensive structure. Even though FPA does not assume this structure or cannot be used as a ratio scale, this combination rule does make sense from the perspective of maintenance effort. In addition, the intersection part can be zero in some cases (e.g., if two different projects are combined). Thus, FPA can assume an extensive structure under certain conditions. Following this idea, Zuse also shows that the FPA measurement function that returns unadjusted function points is a modified function of belief [27]14, which validates the measure above the level of the ordinal scale type. The concept of the function of belief is used by Zuse to describe non-additive measures. These findings suggest that FPA can only be used to rank software systems according to the notion of functional size. The second work on the theoretical validation of FSM methods was presented by Fetcke [13] [126]. He presented a formalization of the generalized representation for data-oriented FSM methods (e.g., FPA and COSMIC-FFP). Fetcke applied a weak ordering relation, a dominance axiom, and a monotonicity axiom to describe the relational structure of functional size that is assumed by the data-oriented FSM methods. This approach enables the study of the empirical assumptions made by the variants of FPA (IFPUG FPA
14
It is a concept that describes the belief in a hypothesis and the belief in a combination of hypotheses.
193
4.0 [80], Mark II FPA 1.3.1 [31], and FFP 1.0 [16]) and the properties of different measures. Fetcke assumed that function point count defines an ordinal scale on applications, assuming that the axioms of the weak order (transitivity and completeness) described in [27] hold. The axiom of dominance is used to express the following instance relation: if application A is an instance of an application A, then A must be at least as large in functional size as A. This axiom was formulated as follows: A A UFP (A) UFP (A) The results show that IFPUG FPA violates the axiom of dominance whereas Mark II and FFP assume it. The consequence is that if function point count is used in the prediction of development effort, an extension of the functionality may increase or decrease the required effort (which is unexpected). The axiom of monotonicity was formulated to express the following relation between three applications: if application A is smaller in functional size than A according to the function point count, then an extension of both applications with the same function types A cannot have the result that the extended application A A A is larger then the extended A A A. This axiom was formulated as follows: UFP (A) UFP (A) UFP (A A A) UFP (A A A) By applying this axiom on the FSM methods, Fetcke observed that IFPUG FPA and FFP violate the axiom of monotonicity. Both methods have similar rules for measuring data function types. This indicates that the sum of the parts of an application does not correspond to the whole application, which is also an unexpected result. On the other hand, Mark II assumes this axiom. Consequently, the results from the Fetcke study allow the validation of these methods as an ordinal scale type functional size measure. However, these axioms do not allow the validation of the measures in more sophisticated scale type (e.g., ratio). In another study, Poels [122] applied a distance-based software measurement to validate the COSMIC-FFP [17] measurement function as a functional size measure for OO systems. This approach is different from the 194
one mentioned above since it uses a framework that offers a measure construction procedure to model properties of software artifacts and to define the corresponding software metrics. It also uses a special kind of proximity structure15 called segmentally additive proximity structure [125]. This structure allows the definition of a measure at the ratio scale level, which is the desirable scale for software measures [127]16. Using this framework, Poels demonstrated that the COSMIC-FFP metamodel allows the representation of the property of functional size according to ratio scale measurement. Poels described a number of empirical assumptions to properly characterize functional size according to the COSMIC-FFP metamodel. First, functional size is described using a relational structure that satisfies the axioms of the segmentally additive proximity structure. Second, a metric space with additive segments [125] is constructed and used to define a ratio scale type. It allows the representation of the notion of functional size as described in the COSMIC-FFP metamodel. From a theoretical point of view, this it is not sufficient to validate the COSMIC-FFP method. This method has some particularities that cannot be expressed using distance-based software measurement. For instance, the theoretical smallest piece of software according to COSMIC-FFP metamodel is a functional process with two data movements, whereas it is represented in distance-based software measurement by the value zero. The findings of Poels study demonstrated that the COSMIC-FFP metamodel of functional user requirements for a piece of software allows the representation of functional size using a ratio scale type. However, to draw definite conclusions, a more detailed study on the transformation of scale between the COSMIC-FFP measurement function and the function that was proposed using distance-based software measurement is necessary.
15
It is described in Measurement Theory to represent the concept of distance or dissimilarity. 16 Ratio scales measurement instruments allow the use of parametric statistics, which are more powerful than non-parametric statistics.
195
6.3
Implications for the validation of the design of OOmFP and OOmFPWeb
IFPUG function points are a derived measure. A IFPUG function point value is obtained by applying a formula to other more primitive measurements (e.g. the counts of Data Element Types (DET) and Record Element Types (RET) for an Internal Logical File (ILF)). Validating function points as a measure of functional size means verifying the stated relationships between function points and each of the measures they are based on. These relationships can be examined empirically. However, this would require the use of an alternative way to obtain function point values (i.e. independent of the primitive measurements). Furthermore, given the inadmissible transformations of scale that were observed in the process of determining the function points value [56] [123], it is highly unlikely that such a study has any chance of success in validating function points as a measure of functional size at the intended scale type (which is the ratio scale type). Another strategy was outlined in Poels [123]. When functional size measurements are used as input to models that predict the value of other attributes (e.g. project resource consumption, maintenance budgets, etc.), then there is no need to first calculate a derived measure or index of functional size. Primitive functional size measurements can be directly related to measurements of the attributes for which prediction models are needed. Empirical research can determine the functional form and other parameters of the relationships underlying prediction models without going through the function point calculations. Given this new software measurement strategy, the first issue that must be raised here is the validity of the primitive functional size measurements. Each set of measurement rules in OOmFP (i.e., RETs for Classes) relates to one primitive functional size measure. Do these measures really measure functional size, and if so, on what type of scale?. In the rest of this chapter, we present an analysis of the measurement processes and primitive functional size measurements in OOmFP. Using distance-based software measurement [128] we illustrate the theoretical validation of one such primitive measure within the context of the OOmFP method. We also extend this validation for OOmFPWeb. We conclude the chapter by discussing some problems encountered when validating the proposed method. 196
6.3.1 Measurement processes and primitive functional size measurements in OOmFP

When analyzing the FPA measurement process, Abran and Robillard [56] found two main processes: the function measurement process, which results in the unadjusted function point count, and the adjustment measurement process, which is used to adjust a function point count so as to better predict effort. However, in the design of OOmFP, we do not take into account the adjustment measurement process. Therefore, our validation strategy is only concerned with the function measurement process. According to the FPA metamodel, this process can be divided into two subprocesses: the data measurement process and the transaction measurement process. The former is concerned with the measurement of classes and legacy views, while the latter is concerned with the measurement of services and presentation patterns. Each set of measurement rules in OOmFP relates to one primitive functional size measure. Table 33 summarizes all the primitive functional size measures existing in the OOmFP data measurement process. These measures were defined taking into account the measurement rules described in Table 9 and Table 10.
Table 33. Direct measures existing in OOmFP for the data measurement process (data perspective)
Entity Class Attribute Number of DETs for Classes (NDC) Direct Measures DETs for Class Attributes (DCA) DETs for Univalued Relationship (DUAR) Aggregation
Legacy View
DETs for Inheritance Relationship (DIR) RET for the Class (RC) RETs for Multivalued Aggregation Relationship (RMAR) Number of DETs for DETs for Legacy view Attributes (DLA) Legacy views (NDL) DETs for Univalued Aggregation Relationship (DUAR) Number of RETs for RET for the Legacy View (RL) Legacy views (NRL) RETs for Multivalued Aggregation Number of RETs for Classes (NRC) Relationship (RMAR)
197
As an example, the rules count 1 RET for a class and count 1 RET for each multivalued aggregation relationship describe a measurement procedure to obtain the value of the attribute number of Record Element Types for Classes [129]. These rules were proposed taking into account the metamodel of OOmFP (the same as the IFPUG FPA metamodel) and how the elements of this metamodel map onto the elements of the OO-Method Conceptual Model metamodel (e.g. classes are ILFs). Applying both rules to an OO-Method conceptual schema, results in a value that represents the number of RETs for classes. These rules can therefore be considered as the prescription of a measure taking an OO-Method conceptual schema as its input and producing a value for the number of RETs for classes as its output. Similar OOmFP measurement rules have been proposed to measure the other primitive functional size attributes used in FPA. In an analogous manner, a set of primitive functional size measurements for the transaction measurement subprocess can be defined. Table 34 and Table 35 show the direct measures existing in OOmFP for the transactional measurement process. The former presents the direct measures for assessing the behaviour and process perspectives. It was defined by considering the measurement rules described in Table 11-15; whereas the latter presents the direct measures for assessing the presentation perspective, defined by considering the measurement rules described in Table 16 and Table 17.
198
Table 34. Direct measures existing in OOmFP for the transactional measurement process (behaviour and process perspectives)
Entity Class Service Attribute Direct Measures Number of DETs for DETs for Data-valued Arguments of Class Services Services (DDAS) (NDCS) DETs for Messages (DM) DETs for Actions(DA) Number of FTRs for FTR for the Class Service (FCS) Class Services FTRs for Object-valued Arguments of (NTCS) Services (FOAS) FTRs for Classes in the Integrity Constraint formula(FCIC) FTRs for Classes in the Transaction formula (FCT) FTRs for Classes in the Specialization by Condition formula (FCSC) FTRs for Classes in the Specialization by Event formula (FCSE) FTRs for Classes in the Value by Default formula (FCVD) FTRs for Classes in the Control Condition formula(FCCC) FTRs for Classes in the Trigger formula(FCT) FTRs for Classes in the Precondition formula(FCP) FTRs for Classes in the Valuation formula(FCP) FTRs for Classes in the Control Condition associated to the Valuation formula(FCCCV) Number of DETs for DETs for Data-valued Arguments of Legacy View Services Legacy View Services (DDAS) (NDLVS) DETs for Messages (DM) DETs for Actions(DA) Number of FTRs for FTR for the Legacy View Service (FLVS) Legacy View Services FTRs for Legacy Views/Classes in the (NTLVS) Integrity Constraint formula(FLVIC) FTRs for Legacy Views/Classes in the Precondition formula(FLVP)
Legacy View Service
199
Table 35. Direct measures existing in OOmFP for the transactional measurement process (presentation perspective)
Entity Instance Interaction Unit Attribute Direct Measures Number of DETs for DETs for Attributes in the Display Set Instance Interaction (DADS) Units (NDIIU) DETs for Offered Actions (DOA) DETs for Offered Navigations (DON) DETs for Messages (DM) Number of FTRs for FTRs for Classes or Legacy views in the Instance Interaction Display Set(FCLDS) Units (NFIIU) Number of DETs for DETs for Attributes in the Display Set Population Interaction (DADS) Units (NDPIU) DETs for Data-valued Attributes in the Filter formula (DDAF) DETs for Offered Actions (DOA) DETs for Offered Navigations (DON) DETs for Messages (DM) Number of FTRs for FTRs for Classes or Legacy views in the Population Interaction Display Set(FCLDS) Units (NFPIU) DETs for Object-valued Attributes in the filter formula (DADS) FTRs for Classes in the Ordering criteria (FCO) FTRs for Classes in the Filter formula Master-Detail Interaction Unit Number of DETs for DETs for Attributes in the Display Set Master-Detail (DADS) Interaction Units DETs for Data-valued Attributes in the (NDMDIU) Filter formula (DDAF) DETs for Offered Actions (DOA) DETs for Offered Navigations (DON) DETs for Messages (DM) Number of FTRs for FTRs for Classes or Legacy views in the Instance Interaction Display Set(FCLDS) Units (NFMDIU) DETs for Object-valued Attributes in the filter formula (DADS) FTRs for Classes in the Ordering criteria (FCO) FTRs for Classes in the Filter formula
Population Interaction Unit
200
As an example we show how the attribute Number of RETs for classes of an OO-Method conceptual schema can be defined, such that its measure (as defined by OOmFP measurement rules) is validated using the DISTANCE framework.
6.4
DISTANCE: a framework for software measurement (Poels and Dedene, 1999)
In order to validate the design of OOmFP, we apply a formal framework called DISTANCE [130] [128] that is based on the rationale of Measurement Theory. This framework uses the concepts of similarity and dissimilarity between software entities. In DISTANCE, the software attributes are modeled as distances (i.e., conceptual distance) between the software entities that they represent and other software entities that act as reference points. These distances are then measured by mathematical functions that satisfy the axiom set of the metric space [125]. The advantages of DISTANCE in comparison with other formal approaches [27] [131] are the following: It provides a constructive and systematic framework which is adapted for object-oriented systems. It is used for the theoretical validation of object-oriented metrics [132] [133] and functional size measures [122]. It supports the ordinal and ratio scale types, while the Zuse approach [27] does not support the ratio scale type for object-oriented metrics. It uses concepts (dissimilarity) that have been formally defined in measurement theory by means of proximity structures [125]. This guarantees the theoretical validity of metrics obtained with DISTANCE.
This framework provides a process with constructive procedures to model the attributes of interest and to define the corresponding software measures. In this section, we introduce some empirical assumptions to apply DISTANCE in the validation of OOmFP primitive functional size measurements. Then, we show an example of validation using the five steps of the distance-based measure construction process. 201
6.4.1 Validating the OOmFP primitive functional size measures using DISTANCE
In this section, we use DISTANCE to formally define and theoretically validate the OOmFP primitive functional size measurements. The validation process is illustrated using the measurement Number of RETs for classes. Here we introduce some empirical assumptions. First, the functional size attribute Number of RETs for classes is defined using a relational structure that satisfies the axioms of the segmentally additive proximity structure [125]. This activity corresponds to the substep Characterization of the concept to be measured in step 1 of the FSM process model of Jacquet and Abran [26] (see Figure 55). The process model also shows that this activity depends upon another substep: Selection of the metamodel. In fact, the FPA metamodel as defined by IFPUG [14] and as mapped onto the OO-Method Conceptual Model metamodel [57] provides the empirical assumptions for the functional size attribute Number of RETs for Classes. Second, a metric space with additive segments [125] is constructed and used to define a ratio scale for the functional size attribute previously defined. This activity is the substep Definition of the numerical assignment rules in Figure 55. We will show that it results in the definition of the two OOmFP measurement rules that were mentioned above.
Figure 55. DISTANCE & Process Model of Jacquet and Abran
202
The validation process is summarized in the template shown in Table 36. A description of the primitive functional size measure is provided in the first row. Next, the name of the primitive functional size attribute (attr), and the software entity that is characterized by this attribute are given. The five individual steps of the distance-based measure construction are further discussed in subsections 6.4.1.1 to 6.4.1.5. 6.4.1.1 Step 1. Find a measurement abstraction
Measurement abstractions are used in software measurement to emphasize the attribute of interest. The result of step 1 is a function abs: P M that maps this attribute into it representation. The range of abs is the set M of measurement abstractions of the chosen type. The function abs is total, but neither injective, nor surjective. A first assumption is that a measurement abstraction can be defined that contains only those components of a conceptual schema that contribute to the schemas functional size, according to the attribute that is considered. Given the mapping in [129] of FPAs Internal Logical File (ILF) onto the OOMethod Conceptual Model concept of class, we abstract a conceptual schema into its set of classes. OO-Method Function Points considers as Record Element Types (RET) of a class c, the class itself (i.e. as a collection of attributes), but also the target classes of multivalued aggregation relationships with c [129]. Therefore the measurement abstraction contains all classes of the conceptual schema and all classes that are linked to these classes by multivalued aggregation relationships. This means that if there are multivalued aggregations in the conceptual schema, then, a same class may occur more than once in the measurement abstraction. In other words, the measurement abstraction is a bag of classes (i.e. a multiset instead of a set). We define the abstraction function (abs), by returning the chosen measurement abstraction for a software entity as a projection SRC of an OOMethod conceptual schema (OOmCS) onto its set of RETs for classes. The set of measurement abstractions (M) contains all possible sets of RETs for classes (URC), over all syntactically and semantically correct OO-Method conceptual schemas, regardless of the application domain. We therefore equate M with the power set of the Universe of RETs for Classes (URC). In Table 36, the abstraction function is defined by: absNRC: UOOmCS (URC): OOmCS SRC(OOmCS) 203
Table 36. Distance-based definition of the NRC metric

NRC Measure Software attribute (attr) The Number of RETs for classes is defined as the total number of RETs in a class of the OO-Method conceptual schema. amount of RETs for Software Entity OOmCS UOOmCS classes (p P) (remark 1) Underlying measurement theoretical constructs & formal definitions
Output of distance-based process M abs Te (URC) absNRC: UOOmCS (URC): OOmCS SRC(OOmCS) (remark 2) Te- NRC = {t 0- NRC , t 1- NRC }, where t0-NRC: (URC) (URC): s
s {rc}
SAPS
NRC ((URC), NRC)
t1-NRC: (URC) (URC): s

s - {rc} with rc URC
ref
(remark 3) NRC: (URC) ( URC) : (s, s') s - s' + s' - s refNRC: UOOmCS OOmCS (URC):
MSAS
((URC), NRC)
STabs(p),ref(p) Attribute def.
STSRC(OOmCS), The amount of RETs for classes in an OO-Method Conceptual Schema is the distance between the set of RETs for classes SRC(OOmCS) and the empty set. The amount of RETs for classes of an OO-Method conceptual schema is measured as the number of RETs for classes that exist in the set SRC(OOmCS).
NNC: UOOmCS : OOmCS SRC(OOmCS) (remark 4)
Measure def.
Remarks: 1: UOOmCS is the Universe of OO-Method conceptual schemas, over all syntactically and semantically correct OO-Method conceptual schemas (OOmCS), regardless of the application domain. 2: URC is the Universe of RETs for classes, i.e. the collection of all syntactically and semantically correct classes that can be defined in OO-Method conceptual schemas. (URC) is the power set of URC. The abstraction function absNRC projects an OO-Method conceptual schema onto its set of RETs for classes. 3: s is a set of RETs for classes, i.e., an element of (URC). As (URC) is a set of sets, Te-NRC is constructively complete and inverse constructively complete. 4: OOmCS UOOmCS: NRC(OOmCS) = NRC(SRC(OOmCS), ) = SRC(OOmCS) - + SRC(OOmCS) = SRC(OOmCS)
204
6.4.1.2
Step 2. Model distances between measurement abstractions
The aim of this step is to model distances between the elements of the set M. To do this, elementary transformations (Te) on the elements of the set M must be defined (t: M M). For all a M, t(a) is the abstraction that results when modifying a in some prescribed way. The modification is assumed to be atomic, i.e. it cannot be subdivided into more elementary changes. For a given set M, there might exist many elementary transformation functions, each associated with one particular type of atomic change. The set T of elementary transformations on M is required to be constructively complete and inverse constructively complete. This means that: There is an initial abstraction ai in M; Each element of M can be built by applying a finite sequence of elementary transformations of T to ai; For each elementary transformation t included in T, the inverse of t is also contained in T;
If these conditions are satisfied, then any element of M can be transformed into any other element of M. Intuitively, the minimum number of elementary transformations necessary to transform an element into another one represents the distance between those elements. Therefore, a second assumption is that a set of homogeneous functions can be defined such that by repeatedly applying one or a combination of these functions, any bag of classes can be transformed into any other bag of classes. These functions are add a class to the bag and remove a class from the bag. In terms of proximity measurement [125] a segmentally additive proximity structure (SAPS) is constructed that defines a notion of distance between bags of classes. Basically this means that the more times homogeneous functions must be applied to transform a bag of classes into another bag of classes, the greater the distance between those two bags. As a result, the concept of a distance is formally defined in M by means of a SAPS. The set of empirical objects in the relational system is M. We only need to define the dissimilarity relation on M. The empirical dissimilarity or conceptual distance ordering is defined as follows: Let M be a set and T be a constructively complete and inverse constructively complete set of elementary transformations on M. Then, for a, b, c, d M, (a, b) (c, d) denotes the observation that we need at least as 205
many elementary transformations to transform a into b than to transform c into d. It can be shown that when the dissimilarity ordering on M is defined as it was defined before, then the axioms of the segmentally additive proximity structure are satisfied. For more information on the formal proofs of these concepts please refer to [132]. 6.4.1.3 Step 3. Quantify distances between measurement abstractions
In this step, a metric is proposed for the distances in M. The definition of a metric function is relatively straightforward: Let M be a set and T be a constructively complete and inverse constructively complete set of elementary transformations on M. Then, for all a, b M: (a, b) = kab . c, where: kab = the minimal number of elementary transformations needed to transform a into b; c = any positive real number. Hence, the distance between a pair of elements in M is measured by counting the elementary transformations in the shortest sequence(s). This count may be multiplied by any positive real number. It is formally proven that a function defined by previous definition is a metric with additive segments if (A, ) is a segmentally additive proximity structure in [132]. After executing this step all distances in M can be modeled and measured. However, we do not need to know all these distances. Only a subset of them is related to the software attribute of interest. In our example, we quantify the distances that were defined in (URC) through elementary transformations (Te). A function that returns a value for the distance between two elements in M is a metric defined on M. As M is a set of sets, a metric function can be defined as using the symmetric difference operation on sets (s, s (URC)). In the following steps, we determine the distances that model the attribute of interest and show how to measure them.
206
6.4.1.4
Step 4. Find a reference abstraction
This is a crucial step in the distance-based measurement procedure as it reflects our understanding of the attribute being measured. The distance-based approach cannot be used for attributes that are only nominal categorizations of software entities. To perform this step, we must imagine what abs(p) would look like if p is characterized by the theoretically lowest value of the attribute. This imaginary representation of p is called the reference abstraction of p for the attribute of interest. It can then be argued that the closer abs(p) is to this reference abstraction, the lower the value of the attribute. Analogously, the farther abs(p) is from the reference abstraction, the higher the value of the attribute is. Hence, the conceptual distance or dissimilarity between the measurement abstraction and the reference abstraction is used as a model of the attribute of interest. Formally, the reference abstraction is returned by a function ref: P A. As ref is a deterministic function, there is exactly one reference abstraction associated with p for the attribute of interest. It is however common (but not required) that ref maps all elements of P into the same abstraction, which is often the initial abstraction ai of A. A third assumption is that we can identify the measurement abstraction for the OO-Method conceptual schema that is characterized by the theoretical lowest value of attr (Number of RETs for Classes). It is safe to assume here that this is the empty schema, which has no classes. This imaginary representation of p is called the reference abstraction of p for attr, (ref(OOmCS)). In this case, for an OO-Method conceptual schema (OOmCS), the set with a minimum number of RETs for Classes (URC) is the empty set (). 6.4.1.5 Step 5. Define the software measure
This last step of the process is trivial. According to DISTANCE, the Number of RETs for Classes of an OO-Method conceptual schema can now be expressed as the distance between the measurement abstraction and the reference abstraction. This means that the more classes must be added to the empty bag to arrive at the measurement abstraction of the conceptual schema, the greater the Number of RETs for Classes of the conceptual schema. Formally, the measure of the attribute of interest is given by the distance between abs(NRC) and ref(NRC). As ref(NRC)= and abs(OOmCS) = 207
SRC(OOmCS), this indicates a set of RETs for classes of an OO-Method conceptual schema. Then, the distance between abs(OOmCS) and ref(OOmCS) is: (OOmCS)=(abs(OOmCS),ref(OOmCS)) = (SRC(OOmCS), ) =SRC(OOmCS) - + - SRC(OOmCS) =SRC(OOmCS) Consequently, the NRC measure is correctly defined as the number of RETs for classes. Table 37 summarizes the required inputs and expected results of the five steps explained above.
Table 37. Required inputs and expected results
Find a abstraction Step measurement Inputs The attribute of interest attr A set of software entities P M M, Te Attr, P, M P, abs, , ref Outputs A set of software entities M (to be used as measurement abstractions) A function abs: P M A set of elementary transformation types Te A metric : M M A function ref: P M (to return a reference abstraction for attr) A function : P
Model distances between measurement abstractions Quantify distances between measurement abstractions Find a reference abstraction Define measure the software
Moreover, the NRC measure was theoretically validated during the process measure definition. This can be observed in the underlying measurement theoretical constructs & formal definitions section of the Table 36. It describes the definition and validation of the NRC measure in detail. The distance-based software measure construction process results in the definition of: an attribute as a segmentally additive proximity structure, and a scale based on a metric with additive segments [125]. According to the uniqueness theorem associated to the representation theorem for segmentally additive proximity structures the resulting measures are characterized by the ratio scale type. Further details on the measurement theoretic principles underlying this approach are presented in [134]. 208
6.5
Validating the OOmFPWeb primitive functional size measures using DISTANCE
The OOmFPWeb measurement rules are concerned only with the transaction measurement process (e.g., measurement of navigational contexts). Similarly, each set of measurement rules in OOmFPWeb relates to one primitive functional size measure. Table 38 summarizes all primitive functional size measures existing in the OOmFPWeb transaction measurement process. These measures were defined based on the measurement rules described in Table 28 and 27. As an example, we show how the attribute Number of FTRs for Navigational Contexts of an OOWS conceptual schema can be defined and validated using the DISTANCE framework.
Table 38. Direct measures existing in OOmFPWeb (navigation and presentation perspectives)
Entity Navigational Context Attribute Direct Measures Number of DETs DETs for Navigational Class Attributes (DNCA) for Navigational DETs for Contextual Dependency Relationship Context (NDNC) (DCDR) DETs for Context Relationship (DCR) DETs for Services (DS) DETs for Service Links (DSL) DETs for Attributes in Population Filters (DAPF) DETs for Attributes in Information Access Filters (DAIAF) DETs for Attributes in Indexes (DAIAF) DETs for Access Mode (DAM) DETs for Cardinality (DC) DETs for Ordering (DC) DETs for Actions (DA) DETs for Messages (DM) Number of FTRs FTRs for Navigational Classes (FNC) for Navigational FTRs for Classes in Population Filters (FCPF) Context (NRNC) FTRs for Classes in Information Access Filters (FCIAF) FTRs for Classes in Indexes (FCI)
209
Table 39. Distance-based definition of the NFNC measure

NFNC Measure Software attribute (attr) The Number of FTRs for navigational context is defined as the total number of FTRs in a navigational context of the OOWS conceptual schema. amount of FTRs for Software Entity OOwsCS UOOwsCS navigational contexts (p P) (remark 1) Underlying measurement theoretical constructs & formal definitions
Output of distance-based process M abs Te (UFNC) absNFNC: UOOwsCS (UFNC): OOwsCS SFNC (OOwsCS) (remark 2) Te- NFNC = {t 0- NFNC , t 1- NFNC }, where t0-NFNC: (UFNC) (UFNC): s
s {fnc}
SAPS
NFNC ((UFNC), NFNC)
t1-NFNC: (UFNC) (UFNC): s

s - {fnc} with fnc UFNC
ref
(remark 3) NFNC: (UFNC) ( UFNC) : (s, s') s - s' + s' - s refNFNC: UOOwsCS (UFNC): OOwsCS
MSAS
((UFNC), NFNC)
STabs(p),ref(p) Attribute def.
STSFNC(OOwsCS), The amount of FTRs for navigational contexts in an OOWS Conceptual Schema is the distance between the set of FTRs for navigational contexts SFNC(OOwsCS) and the empty set. The amount of FTRs for navigational contexts of an OOWS conceptual schema is measured as the number of FTRs for navigational contexts that exist in the set SFNC(OOwsCS).
NFNC: UOOwsCS : OOwsCS SFNC (OOwsCS) (remark 4)
Measure def.
Remarks: 1: UOOwsCS is the Universe of OOWS conceptual schemas, over all syntactically and semantically correct OOWS conceptual schemas (OOwsCS), regardless of the application domain. 2: UFNC is the Universe of FTRs for navigational contexts, i.e. the collection of all syntactically and semantically correct navigational contexts that can be defined in OOWS conceptual schemas. (UFNC) is the power set of UFNC. The abstraction function absNFNC projects an OOWS conceptual schema onto its set of FTRs for navigational contexts. 3: s is a set of FTRs for navigational contexts, i.e., an element of (UFNC). As (UFNC) is a set of sets, Te-NFNC is constructively complete and inverse constructively complete. 4: OOwsCS UOOwsCS: NFNC(OOwsCS) = NFNC(SFNC(OOwsCS), ) = SFNC(OOwsCS) - + - SFNC(OOwsS) = SFNC(OOwsCS)
210
6.5.1 Find a measurement abstraction

A first assumption is that a measurement abstraction can be defined using only those components of an OOWS conceptual schema that contribute to the schemas functional size, according to the attribute that is considered. Given the mapping in [135] of FPAs External Inquiry (EQ) onto the OOWS Conceptual Model concept of navigational context, we abstract a conceptual schema into its set of navigational contexts. OOmFPWeb considers the navigational classes that appear in a context (i.e. as a collection of attributes), as File Type Referenced (FTR) of a navigational context nc, but also the navigational classes that are referenced in the formulas of the population filters, information access filters and indexes attached to the nc. Therefore, the measurement abstraction contains all navigational classes that appear in navigational contexts of the OOWS conceptual schema and all navigational classes that appear in the formulas (e.g., filters and indexes) attached to the navigational context definition. This means that the same navigational class may occur more than once in the measurement abstraction. In other words, the measurement abstraction is a bag of navigational classes (i.e. a multiset instead of a set). We define the abstraction function (abs), returning the chosen measurement abstraction for a software entity, as a projection SFNC of an OOWS conceptual schema (OOwsCS) onto its set of FTRs for navigational classes. The set of measurement abstractions (M) contains all possible sets of FTRs for navigational context, over all syntactically and semantically correct OOWS conceptual schemas. We therefore equate M with the power set of the Universe of FTRs for Navigational Contexts (UFNC). In Table 39, the abstraction function is defined by: absNFNC: UOOwsCS (UFNC): OOwsCS SFNC(OOwsCS)
6.5.2 Model distances between measurement abstractions

The next step is to model distances between the elements of the set M. Therefore, a second assumption is that a set of homogeneous functions can be defined such that by repeatedly applying one or a combination of these functions, any bag of navigational classes can be transformed into any other bag of navigational classes. These functions are add a navigational class to the bag and remove a navigational class from the bag. In terms of 211
proximity measurement [125], a segmentally additive proximity structure is constructed that defines a notion of distance between bags of navigational classes. This means that the more times homogeneous functions must be applied to transform a bag of navigational classes into another bag of navigational classes, the greater the distance between those two bags.
6.5.3 Quantify distances between measurement abstractions

In this step, we quantify the distances that were defined in (UFNC) through elementary transformations (Te). Hence, the distance between a pair of elements in M is measured by counting the elementary transformations in the shortest sequence(s). This count can be multiplied by any positive real number. A function that returns a value for the distance between two elements in M is a metric defined on M. Similarly, as M is a set of sets, a metric function can be defined as using the symmetric difference operation on sets (s, s (UFNC)).
6.5.4 Find a reference abstraction

A third assumption is that we can identify the measurement abstraction for the OOWS conceptual schema that is characterized by the theoretical lowest value of attr (Number of FTRs for Navigational Contexts). In this case, it is also safe to assume that this is the empty schema, having no navigational classes. This imaginary representation of p is called the reference abstraction of p for attr, (ref(OOwsCS)). In this case, for an OOWS conceptual schema (OOwsCS), the set with a minimum number of FTRs for Navigational Contexts (UFNC) is the empty set ().
6.5.5 Define the software measure (metric)

According to DISTANCE, the Number of FTRs for Navigational Contexts of an OOWS conceptual schema can now be expressed as the distance between the measurement abstraction and the reference abstraction. This can be interpreted as: the more navigational classes must be added to the empty bag to arrive at the measurement abstraction of the conceptual schema, the greater the Number of FTRs for Navigational Contexts of the conceptual schema. 212
Formally, the measure of the attribute of interest is given by the distance between abs(NFNC) and ref(NFNC). As ref(NFNC)= and abs(OOwsCS) = SFNC(OOwsCS), this indicates a set of FTRs for navigational contexts of an OOWS conceptual schema. Then, the distance between abs(OOwsCS) and ref(OOwsCS) is:
(OOwsCS)=(abs(OOwsCS),ref(OOwsCS)) = (SFNC(OOwsCS), ) =SFNC(OOwsCS) - + - SFNC(OOwsCS) =SFNC(OOwsCS)
6.6
Metrics-based definition of OOmFP and OOmFPWeb measurement rules
According to Measurement Theory, the concept of distance or dissimilarity (i.e., a conceptual distance) is represented by means of an empirical relational structure called a proximity structure. DISTANCE uses a special kind of proximity structure, the segmentally additive proximity structure (SAPS). This is constructed using a weak ordering relation , which represents a ranking of the distances in M and a standard unit of distance, which is equal to one elementary transformation. The quantification of distances between the measurement abstractions (in the numerical relational system) is called metrics space with additive segments (MSAS) [125]. Following the guidelines described in [130], the minimum number of classes that must be added to and removed from one bag of classes to transform it into another bag of classes qualifies as a MSAS for the proximity structure that was defined. Therefore, a function that counts the minimum number of times that homogeneous functions were applied to a bag of classes to arrive at another bag of classes can be used to measure the distance between those bags. Furthermore, as the scale type of a metric with additive segments is ratio [125], any function that is derived through a similarity transformation of the metric can also be used as a measure (allowing for rescaling of the counts). In terms of FPA, the classes in the measurement abstraction of a conceptual schema are the Record Element Types of the schemas Internal Logical Files. As the reference abstraction is an empty bag, the attribute Number of RETs for Classes of a conceptual schema can be measured by counting all occurrences of the classes in the measurement abstraction. This 213
is exactly what is done by the OOmFP measurement rules count 1 RET for a class and count 1 RET for each multi-valued aggregation relationship. Hence, we have theoretically validated these measurement rules. These results can also be extended to validate OOmFPWeb since this method presented similar measures to those for OOmFP. For instance, the attribute Number of FTRs for Navigational Context (NFtrNC) of an OOWS conceptual schema can be measured by counting all occurrences of the navigational classes for a navigational context. This is done by counting 1 FTR for a navigational class, 1 FTR for a navigational class in a population filter formula, 1 FTR for a navigational class in the information access filter formula, and 1 FTR for a class in the index formula. Therefore, the validation of the attribute NFNC can be performed following the same strategy used to validate the attribute Number of RETs for Classes (NRC). In summary, a same procedure can be followed for the other sets of OOmFP and OOmFPWeb measurement rules, measuring other primitive functional size attributes of OO-Method / OOWS conceptual schemas. As long as the reference abstraction for the primitive attribute considered is an empty set or bag, the theoretical validation is analogous to the example worked out in this chapter.
6.7
Conclusions
Evidence of the validity of proposed functional size measures is scarce. Most studies focus on demonstrating the usefulness of a functional size measure as a predictor of development effort or other software process management variables. It is our position that two other types of evaluation must also be performed: the validation of the design of the FSM method and the validation of the application of the FSM method (discussed in the following three chapters). The validation of the design of the FSM method includes the validation of the measure that is defined by the FSM method as a measure of functional size. This chapter reported some first results in validating functional size measures for OOmFP and OOmFPWeb. The validation approach used is DISTANCE, which is based on proximity measurement. It has been shown that the primitive measurements defined by the OOmFP and OOmFPWeb measurement rules can be validated as ratio scale functional size measurements for object-oriented systems and 214
Web applications, respectively. Although the primitive measures that are defined by the OOmFP measurement rules can be validated, the validity of the function point measure that is obtained by integrating these rules into the FPA structure is still unknown. In future work, we will explore the use of other measurement theoretic structures [131] that can possibly offer a solution to validate a derived measure like the one defined by OOmFP (or other IFPUG FPA-compliant FSM methods). Whether this work will be successful is still an open issue at this time.
215
Chapter 7
Validation of the Application of the Measurement Procedure

This chapter justifies the need for experimental evaluation of the proposed FSM procedure. We examine the theoretical models proposed in the IS research field to provide an overview of the theories used to predict and explain the acceptance of information technology. Then, a theoretical model and associated measurement instrument for evaluating FSM methods are proposed. They are used as the theoretical basis for the laboratory experiments presented in the following two chapters.
7.1
Introduction
The second type of validation relates to the second and third steps in the measurement process model of Jacquet and Abran [26] (see Figures 4 and 5). 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 [136]. They distinguish this type of validation from the a priori validation, which aims at reviewing the procedures of the data collection process.
Chapter 7. Validation of the Application of the Measurement Procedure
Independent of a specific application, evaluating the use of OOmFP in general allows the assessment of the degree of confidence in the measurement results and verifies whether the method satisfies its intended use and the user needs. The evaluation of a new FSM method can be guided by the ISO/IEC standard on functional size measurement. Part 1 of the standard [9] presents general concepts on functional size measurement and specifies the characteristics and requirements of a FSM method. Part 2 [20] describes a process to verify whether a candidate FSM method conforms to part 1 of the standard. Finally, part 3 [21] describes a process to verify whether a FSM method exhibits stated performance properties (e.g. accuracy, convertibility, applicability to functional domains) and meets the (prospective) users needs. We acknowledge the value of a conformity check against the ISO/IEC standard for the newly proposed FSM method. For our purposes, part 3 is, however, more relevant for evaluating OOmFP and OOmFPWeb. It was specifically proposed to adapt FPA in order to enable and facilitate the functional size measurement of OO systems and Web applications (produced with OO-Method and OOWS). The development of OOmFP and its extension to Web environments therefore grew out of the need for a FSM procedure for OO systems and Web applications, taking into account their specific features. Hence, the evaluation should focus on the efficiency and effectiveness of OOmFP and OOmFPWeb in satisfying its goal, i.e. measuring the functional size of OO systems and Web applications. Although the performance properties and verification procedures in part 3 of the ISO/IEC standard provide a starting point for evaluating OOmFPWeb, what is missing is a comprehensive view of the quality of a FSM method. A simple list of isolated quality criteria hides the interrelationships between quality properties and their impact on overall quality. What is needed is a structured quality framework or model that allows for a systematic evaluation of FSM methods. Such an evaluation should not only seek objective evidence of the performance of a method in achieving its objectives. It should also test the users response to a new method and allow us to predict its acceptance in practice. Empirical studies can help determine the performance of proposed theories and methods [71] [68] [67]. According to Riemenschneider et al. [137] the acceptance of software engineering methodologies is also determined by the users perception. If its intended users do not regard a method as useful, then, its prospects for successful deployment are undermined. We therefore believe that future research directions for empirical 218
software engineering should take into account not only the performance of a method in achieving its objectives, but also the likelihood of the method being accepted by practitioners based on their perception of performance. Following these ideas, a theoretical model for assessing the performance and acceptance of FSM methods is proposed [138]. This theoretical model heavily borrows from existing theoretical models. In this chapter, we first examine existing theoretical models proposed in the context of technology acceptance and IS design method acceptance. Then, we explain how these models can be used to analyze and evaluate FSM methods.
7.2
Theoretical models in IS research
According to Pfeeger [139], the field of Software Engineering needs to better understand the role of people in the adoption process. It is addressed in the Social Science field through the development of theoretical models to explain the acceptance of technology, methodologies and methods. In this field, current models of technology acceptance have their roots in a number of diverse theoretical perspectives. Such theoretical models incorporate constructs to measure the psychological reactions of the user and organizational factors in a systematic way. The Technology Acceptance Model (TAM) proposed by Davis [140] is a widely used theoretical model, from the perspective of general system usage. Heilman [141] states that even when applied in a general sense, the TAM model appears to be robust and should be used as a means to assess systems and user behavior. Recently, some theoretical models were employed in the field of software engineering to explain software developer acceptance of methodologies and IS methods. In the context of object-oriented system development, Johnson et al. [142] identified specific beliefs underlying the attitude, subjective norm, and perceived behavioral control constructs of the Theory of Planned Behavior (TPB). However, the relationships between these constructs were not empirically tested. Riemenschneider et al. [137] examined five theoretical models of individual intentions to accept information technology tools in the context of methodology acceptance. They apply a field study using 128 developers in a large organization. The results show that, if a methodology is not regarded as useful by developers, its prospects for successful deployment may be severely 219
limited. The authors also explain why software developers accept or resist methodologies. Moody [70] proposes the Method Evaluation Model (MEM) [70] as a theoretical model for evaluating IS design methods. It was built upon others modes and incorporates both aspects of method success: actual performance and likely adoption in practice. This model was successfully applied in the comparison and evaluation of large data model representation models (Entity Relationship Model [143], Structured Data Models [144], Clustered Entity Models [145] and Levelled Data Modes [146]). Due to the absence of established theoretical models in the particular domain of intentions to adopt FSM methods, we next examine the most relevant theoretical models for the purpose of this thesis.
7.2.1 The Technology Acceptance Model (Davis, 1989)

The Technology Acceptance Model (TAM) [140] is perhaps one of the most frequently tested models in MIS literature. The model attempts to predict and explain computer-usage behavior. It was derived from the Theory of Reasoned Action (TRA) proposed by Fishbein and Ajzen [147]. TRA is a widely-studied model from social psychology, which is concerned with the determinants of consciously intended behaviors. According to TRA, a persons performance of a specified behavior is determined by his/her behavioral intention to perform the behavior, and the behavioral intention is jointly determined by the persons attitude and subjective norms concerning the behavior in question. TAM uses two beliefs of the potential adaptors, perceived ease of use and perceived usefulness of the technology as the main determinants of the attitudes toward a new technology. These attitudes influence intentions and, ultimately, behavior. In this model, usage is modeled as a direct function of intention (see Figure 56).
Perceived Ease of Use Attitude Perceived Usefulness Behavioral Intention
Usage
Figure 56. Simplified Technology Acceptance Model
220
The meaning of each primary construct of TAM is Perceived Ease of Use (PEOU): the degree to which the user expects the target system to be free of effort. Perceived Usefulness (PU): users subjective probability that using a specific application system will increase his/her job performance within an organizational context. Attitude (A): the users desire to use the system. Both PU and PEOU predict attitude toward using the system. Behavioral Intention (BI): the measure of the strength of ones intention to perform a specified behavior. A and PU influence the individuals BI to use the system. Usage: the actual use of the system. It is predicted by behavioral intentions.
Several researchers have replicated Daviss original study [140] to provide empirical evidence on the relationships that exist between ease of use, usefulness, and system use [148] [149] [150] [151] [152]. For instance, Adams et al. [148] replicated the study of Davis to demonstrate the validity and reliability of his instrument and measurement scales. Segars and Grover [150] re-examined Adams et als [148] replication of the Davis model. They were critical of the measurement model used, and postulated a different model based on three constructs: usefulness, effectiveness, and ease-of-use. Moreover, a large number of experimental studies have also validated the TAM using a variety of specific systems, such as the prediction of Website usage [153] and the success of existing e-commerce applications [154]. These studies have shown that this model has reasonable explanatory power to predict technology adoption and usage [155] [156] [157].
7.2.2 The Method Evaluation Model (Moody, 2001)

The Method Evaluation Model (MEM) [70] is a theoretical model for evaluating IS design methods, which incorporates both aspects of method success: actual performance and likely adoption in practice. It combines Reschers Theory of Pragmatic Justification [158], a theory for validating methodological knowledge, and Daviss Technology Acceptance Model of [140]. 221
Reschers theory of methodological pragmatism is a contribution to the theoretical understanding of methods. Two kinds of human knowledge are identified in this theory: knowledge how (which is a thesis that defines statements about the word) and knowledge that (which is a method that defines ways of doing things). According to Rescher [158], a method is a collection of rules and procedures designed to assist people in performing a particular task. It is intended to achieve certain objectives. Rescher argues that methods have no true value, only pragmatic value. Thus, the validity of a method can only be established by its successful use in practice. Based on this theory, Moody states that: The objective of a validation process should not be to demonstrate that the method is correct but that it is rational practice to adopt the method based on its pragmatic success. In this context, pragmatic success is defined as the efficiency and effectiveness with which a method achieves its objectives. Therefore, the core of the MEM (see Figure 57) consists of the same perception-based constructs as the Technology Acceptance Model (TAM) [140], but now adapted for evaluating methods. These constructs are: 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 be effective in achieving its intended objectives. Intention to Use: the extent to which a person intends to use a particular method.
These central constructs are called the Method Adoption Model (MAM). This model is extended with additional constructs that provide inputs to the MAM and predict its ultimate output (i.e. whether the method will be used in practice). These additional constructs are: 222 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. Actual Usage: the extent to which a method is used in practice. This represents an output variable from the Method Adoption Model.
Method Adoption Model

Performance Perceptions Perceived Ease of Use
Actual Efficiency
Intentions
Behaviour
Intention to Use Actual Effectiveness External (Performance Based) Variables

ACTUAL EFFICACY PERCEIVED EFFICACY
Actual Usage
Perceived Usefulness External Behaviour
Internal (Perception Based) Variables
ADOPTION IN PRACTICE
Figure 57. Method Evaluation Model MEM (Source: [70])
The input variables relate to the actual performance of users in employing a method. The assumption underlying the Method Evaluation Model is that perceptions of performance are the result of actual experience with the method and that a users performance in using a method has an impact on the users perception of the methods performance, which in turn determines the users intention to adopt the method. The actual usage of a method will be determined by this intention to use. Empirical studies of the TAM have reported a significant causal relationship between behavioural intention to use and actual usage [157]. This theoretical model recognizes that for a method to be successful, it not only has to improve task performance, but also that people must want to use it. In this model, the ultimate dependent variable is Usage in Practice this is when research has an impact on practice. This is determined by Intention to Use, which is in turn determined by perceptions of Ease of Use and Usefulness. Actual Efficiency and Effectiveness (pragmatic success as defined by Rescher) determine intentions to use a method only via perceptions of ease of use and usefulness.
223
7.3
A general theoretical model for evaluating FSM methods
We have adapted the constructs of the MEM to evaluate the performance and acceptance of a specific kind of method, i.e. FSM methods [138]. Our theoretical model for evaluating FSM methods provides a range of performance-based and perception-based variables, including efficiency, reproducibility, accuracy, perceived ease of use, perceived usefulness and intention to use. The operationalization of the model is presented in detail.
7.3.1 Operationalization of the model

Due to the absence of established theoretical models in the functional size measurement domain, there are no FSM-method specific measures we could draw on. Thus, the proposed theoretical model was operationalized by revising the criteria defined in the ISO 14143 and adapting measures used in the TAM and MAM theoretical models. We distinguish between two types of measures: Performance based (objective) measures: How well are people able to use the FSM method? Perception based (subjective) measures: How effective do people believe the FSM method to be in achieving its objectives? Constructs for performance-based variables
7.3.1.1
Evaluating the actual performance of a FSM method requires measurement of the effort required (inputs) and the quality of the results (outputs). Hence, we distinguish between two performance-based variables: efficiency and effectiveness: The efficiency of a FSM method is defined by the effort required to understand and apply the FSM method. It can be measured using the following measures: time, cost, productivity and cognitive effort. The effectiveness of a FSM method is defined by how well it achieves its objectives. This can be measured by evaluating the measurement results of the method. Evaluation of actual effectiveness is important to establish an evidence base for functional size measurement practice. Effectiveness can be 224
measured using the specific properties and requirements of functional size measurement. This choice was guided by part 3 [21] of the ISO/IEC standard where performance properties for FSM methods are listed. These performance properties include: Repeatability: the closeness of the agreement between the results of successive measurements of the same measurand17 carried out under the same conditions of measurement18. Reproducibility: closeness of the agreement between the results of measurements of the same measurand carried out under changed conditions of measurement19. Accuracy: the closeness of the agreement between the result of a measurement and the true value of the measurand. Convertibility: the ability to convert the results from applying two or more FSM Methods in the measurement of a functional size of the same set of Functional User Requirements (FUR). Discrimination threshold: largest change in a stimulus that produces no detectable change in the response of a measuring instrument, the change in the stimulus taking place slowly and monotonically. Applicability to Functional Domains: the ability of an FSM Method to take into account the characteristics of FUR which are pertinent to FSM in a Functional Domain. Constructs for perception-based variables (OOmFP)
7.3.1.2
For the perception-based variables, we relied on an existing measurement instrument for the MAM/TAM, though we adapted this instrument for use with FSM methods (basically by rewording statements). Figure 58 shows how the Method Adoption Model (MAM) was operationalized for evaluating OOmFP. In the diagram, the circles represent
17
It is a particular quantity subject to measurement. In Part 3 of ISO/IEC 14143, the measurand refers to the FUR. Repeatability conditions include: the same measurement procedure, the same observer, the same measuring instrument used under the same conditions, in the same location. The repetition should be made over a short period of time. The changed conditions can include: principle of measurement, method of measurement, observer, measuring instrument, reference standard, location, conditions of use or time.
18
19
225
theoretical constructs (latent variables), the rectangles represent observed variables, solid lines represent causal relationships between theoretical constructs and dotted lines represent measurement relationships between theoretical constructs and their empirical indicators (measures).
PEOU1 PEOU2 PEOU3 PEOU4 PEOU5 ITU1
Perceived Ease of Use
Intention to Use
PU1 PU2 PU3 PU4 PU5 PU6
ITU2 ITU3
Perceived Usefulness
Figure 58. Operationalized FSM Method Adoption Model
In fact, the model shown in Figure 58 represents the resulting TAM model after successive refinements. After an empirical testing of the model presented in Figure 56 [140], it was found that PEOU and PU directly influence intention to use. Also, PEOU was found to directly affect intentions to use. Next, we describe how this model was adapted to the FSM methods domain. 7.3.1.2.1 Perceived Ease of Use
Items used to operationalize the Perceived Ease of Use (PEOU) construct were adapted from the studies of Davis [140] and Moody [70]. The objective of this construct is to measure the perceptual judgement about the effort required to learn and use a FSM method. Five items were used to measure PEOU. These items are the following: PEOU1. I found the procedure for applying the FSM method simple and easy to follow PEOU2. Overall, I found the FSM method easy to use 226
PEOU3. I found the measurement rules of the FSM method clear and easy to understand PEOU4. I found the FSM method easy to learn PEOU5. I found it easy to apply the FSM method to the case study 7.3.1.2.2 Perceived Usefulness
In the same way, items used to operationalize the Perceived Usefulness (PU) construct were adapted from items used in studies by Davis [140] and Moody [70]. The objective of this construct is to measure the perceptual judgement about the effectiveness of a FSM method. Six items were used to measure PU: PU1. PU2. PU3. PU4. PU5. PU6. I believe that this FSM method would reduce the time required to measure object-oriented systems. Overall, I found the FSM method to be useful I think that this FSM method would improve the accuracy of estimates of object-oriented systems Overall, I think this FSM method does provide an effective way of measuring the functional size of OO systems during the requirements phase. Using this FSM method would improve my performance in measuring OO systems Overall, I think this FSM method is an improvement to the IFPUG FPA method
The last item was included because in the context of this thesis, the relevant comparison is to the standard IFPUG FPA method, as this is the most widely used FSM method used in practice. In addition, OOmFP and OOmFPWeb were designed as an extension of this method to sizing OO systems and Web applications, respectively. 7.3.1.2.3 Intention to Use
The studies of Davis [140] and Moody [70] were also used to operationalize the Intention to Use (ITU) construct. The objective of this construct is to measure the perceptual judgement about the performance a FSM method. The following three items were defined to measure perceptions in intention to use: ITU1. I will use this FSM method if I have to measure object-oriented systems in the future 227
ITU2. ITU3. 7.3.1.3
It would be easy for me to become skilful in using this FSM method I intend to use this FSM method in the future Constructs for perception-based variables (OOmFPWeb)
In this section, we describe how the items of the perception-based constructs were adapted to evaluate OOmFPWeb 7.3.1.3.1 Perceived Ease of Use
The same items described in section 7.3.1.2.1 can be applied to operationalize the Perceived Ease of Use (PEOU) construct for OOmFPWeb. 7.3.1.3.2 Perceived Usefulness
To operationalize the Perceived Usefulness (PU) construct to measure OOmFPWeb, the following items were used: PU1. PU2. PU3. PU4. PU5. I believe that this FSM method would reduce the time required to size Web applications. Overall, I found the FSM method to be useful. I think that this FSM method would improve the accuracy of size estimates of Web applications Overall, I think this method provides an effective way of measuring the functional size of Web applications. Using this method would improve my performance in sizing Web applications
The main difference with respect to the items that operationalize OOmFP is that the PU6 is not applicable in this case. The reason is that we plan to evaluate OOmFPWeb separately (not in a comparison with IFPUG FPA). 7.3.1.3.3 Intention to Use
To operationalize Intention to Use (ITU), the same constructs as those for OOmFP were used (basically adapting the OO systems domain for the Web application domain): ITU1. 228 I will use this FSM method if I have to size Web applications in the future
ITU2. ITU3. 7.3.1.4
It would be easy for me to become skilful in using this FSM method I intend to use this FSM method in the future Development of the measurement instrument
The items defined for each construct were combined together into a survey consisting of fourteen questions. The items were formulated using a 5-point Likert scale, using the opposing statement question format. Various items within the same construct group were randomized to prevent systemic response bias. In addition, to ensure the balance of items in the survey, half of the questions on the lefthand side were negated to avoid monotonous responses [159]. The resulting measurement instrument is shown in Appendix B. One of the major advantages of using the MAM and the measurement instrument associated to it is that it is based on previous works were similar surveys were used and validated in the context of technology adoption [140] [157] and IS methods adoption [70]. For instance, some works provide evidence of the robustness and validity of the questionnaire instrument used by Davis. Adams et al. [148] replicated the work of Davis (1989) to demonstrate the validity and reliability of his instrument and his measurement scales. They also extended it to different settings and, they demonstrated the internal consistency and replication reliability of the instrument using two different samples. Hendrickson et al. [149] found high reliability and good test-retest reliability. Szajna [152] found that the instrument had predictive validity for intent to use and self-reported usage. The results of this research have confirmed the validity of the instrument to support its use with different populations of users and different software choices. Recently, a field study that uses the same kind of instrument as the one used by Davis was used to explain software developer acceptance of methodologies [137].
7.4
Conclusions
In this chapter, a general theoretical model and associated measurement instrument for explaining and predicting the adoption of FSM methods in 229
practice was proposed. The model incorporates both performance-based and perception-based variables of a methods performance. Furthermore, it allows the prediction of the likely adoption in practice of a FSM method. However, performance-based measures of efficiency and effectiveness must be developed for each class of FSM method, based on its specific objectives. For instance, a theoretical model for evaluating FSM methods for Web applications should be built taking into account the specific features of methods of this kind. This can be done by instantiating the general theoretical model that was proposed in a more specific one. This process is further illustrated in the following chapters (Chapters 8 and 9), since the proposed model is used as the theoretical basis for conducting laboratory experiments to: Evaluate OOmFP compared to IFPUG FPA in terms of its efficacious, effectiveness, perceived ease of use, perceived usefulness and intentions to use (Laboratory Experiment 1). Predict the likehood of adoption of OOmFP in practice using final year Computer Science students (Laboratory Experiment 1). Assess the validity and reliability of MEM for evaluating OOmFP (Laboratory Experiment 1). Evaluate OOmFPWeb in terms of its efficacious, effectiveness, perceived ease of use, perceived usefulness and intentions to use (Laboratory Experiment 2). Predict the likehood of adoption of OOmFPWeb in practice using PhD. Students in the Software Engineering field (Laboratory Experiment 2). Assess the validity and reliability of MEM for evaluating OOmFPWeb (Laboratory Experiment 2). Validation of the application of FSM methods is rarely addressed in the literature. One of the reasons could be the lack of an underlying theoretical model for validation of methods in general. The proposed theoretical model provides a first attempt towards developing such a method. Understanding the factors which determine FSM method acceptance by practitioners may help to reduce the gap between theory and practice in the FSM field.
230
Chapter 8
Experiment 1: Comparative Evaluation of OOmFP against IFPUG FPA

This chapter describes a laboratory experiment which evaluates the efficiency, effectiveness, and likely adoption in practice of OOmFP for sizing objectoriented systems developed using the OO-Method approach. The proposed method is evaluated in comparison to the IFPUG FPA, an ISO-standardizedFSM method.
8.1
Introduction
IFPUG FPA was developed specifically to measure the functional size of Management Information Systems (MIS). However, according to reported industry experience, this method has also been used for sizing ObjectOriented systems [75] [32]. We agree with Dekkers and Cartwright [75] that, in OO systems development, functional user requirements are captured in a different way (using OO methods and techniques). Although it is certainly possible to size these functional user requirements using FPA, a number of FPA variants and extensions have been proposed for the specific purpose of measuring OO systems [30] [42] [43] [76] [38] [46] [44] [47] [81] [35] [37] [39] [40] [41] [45] [160] [161] [162]. None of these proposals has yet been widely accepted in practice. OOmFP has been proposed to overcome these difficulties in the context of OO-Method [57]. As a first-category FSM method, OOmFP is compliant
Chapter 8. Comparative Evaluation of OOmFP against IFPUG FPA
with IFPUG FPA. At the same time, it is meant to improve upon IFPUG FPA for the function point counting of OO systems that are developed using the OO-Method approach. As design science is not complete without evaluating the research outputs [59], in this chapter, we evaluate OOmFP using a laboratory experiment based on a general evaluation model for FSM methods that is grounded on theory. Therefore, IFPUG FPA is treated as the benchmark FSM method against which the new proposal, OOmFP is evaluated. To predict the success of OOmFP in terms of its actual usage, the actual and perceived performance of applying this method and the intention to use the method in practice are evaluated and compared to IFPUG FPA. It is this attention to the necessary evaluation component of a design science project that distinguishes this work from the other proposals existing in the literature.
8.2
Experiment design
The experiment design was guided by the framework for experimental software engineering suggested by Wohlin et al. [72]. The goal of the experiment was to determine which method (OOmFP or IFPUG FPA) results in the best functional size assessment of object-oriented systems when measuring the user requirements. In other words, which method has the highest performance and/or likely adoption in practice. In terms of the Goal/Question/Metric (GQM) template for goal-oriented software measurement [74], the goal pursued in this experiment is: analyze functional size measurements for the purpose of evaluating OOmFP and IFPUG FPA with respect to their performance and adoption 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 this experiment are: Research Question 1: Is the actual performance of OOmFP in measuring the functional size of OO systems based on their functional user requirements higher than that of IFPUG FPA?
232
Research Question 2: Is the perceived performance of OOmFP and the intention to use OOmFP higher than the perceived performance of IFPUG FPA and the intention to use IFPUG FPA? Research Question 3: Is OOmFP likely to be adopted in practice? Research Question 4: Is the Method Adoption Model a valid model and measurement instrument for evaluating FSM methods?
As previously mentioned, the evaluation of the performance of a method requires the measurement of the effort required (inputs) and the quality of the results (outputs). Thus, the research questions are broken down in the following questions: Research Question 1 (Efficiency): how efficient is OOmFP compared to IFPUG FPA for sizing object-oriented systems based on requirements specifications? Research Question 1 (Effectiveness): how effective is OOmFP compared to IFPUG FPA for sizing object-oriented systems based on requirements specifications? In order to measure effectiveness, we selected the following criteria described in Part 3 of the standard ISO/IEC for functional size measurement [21]: a. Reproducibility: does OOmFP produce more consistent measurements of functional size when used by different people than IFPUG FPA? Reproducibility refers to the use of the method on the same product in the same environment by different subjects. The obtained results should be identical. b. Accuracy: does OOmFP produce more accurate measurements of functional size from requirements specifications than IFPUG FPA? Research Question 2 (Perception of Performance and Intention to Use): is the perceived performance of OOmFP and the intention to use OOmFP higher than with IFPUG FPA ? Research Question 3 (Acceptance): Is OOmFP likely to be adopted in practice? Research Question 4 (Validity): is the Method Adoption Model a valid theoretical model and measurement instrument for evaluating FSM methods?
233
8.3
Planning
8.3.1 Selection of subjects

The subjects that participated in this study were 22 students in the final year of Engineering in Computer Science with a major in Information Systems. Final-year students were used as proxies for practitioners for the following reasons: Accessibility: the possibility of getting practitioners is difficult given time and cost constraints. The costs and benefits of empirical studies with students are discussed in [163]. Similarity: final year students were the closest to practitioners [164]. Students are the next generation of professionals and are therefore close to the population under study [69]. The students were between 22 and 24 years old and had similar backgrounds (they attended the same courses on project development and management). The subjects were chosen for convenience, i.e., they were students enrolled in the Software Development Environments course during the period from February until June of 2003. This course was selected because it was an advanced unit (where students learn advanced techniques about software development). The necessary preparation and the task itself also fitted in well with the content of the course. Originally, the content of the course included conceptual modeling and development approaches, but we included a new topic about functional size measurement. Thus, during this course, these students were trained in the use of UML and OO-Method approaches for the purpose of conceptual modeling, and they were trained in IFPUG FPA and OOmFP for the purpose of functional size measurement and project estimation.
8.3.2 Variable selection

The independent variable is a single variable, which is the method used by subjects to size an OO system. The independent variable has two levels, corresponding to the different sizing methods being compared: OOmFP [165] and IFPUG FPA [14]. 234
We distinguish between two types of dependent variables: performancebased (objective) and perception-based (subjective) variables. The classification of dependent variables in this experiment is shown in Table 40. Performance-based variables measure how well the subjects perform the experimental task. These variables operationalize the actual performance constructs in the Method Evaluation Model, i.e. the external variables that are used as inputs to the Method Adoption Model. Three performance-based variables are distinguished: Sizing effort (D1): the time taken by a subject to complete the measurement task. Reproducibility (D2): the agreement between the measurement results of different subjects using the same method. Accuracy (D3): the agreement between the measurement results and the true value. Perception-based variables measure the perceived performance and subsequent intention to use OOmFP and IFPUG FPA. These variables operationalize the constructs of the Method Adoption Model. Three perception-based variables are distinguished: Perceived Ease of Use (D4): the degree to which a subject believes that using a particular method would be free of effort. Perceived Usefulness (D5): the degree to which a subject believes that a particular method will be effective in achieving its intended objectives. Intention to Use (D6): the degree to which an individual intends to use a particular method as a result of his/her perception of the methods performance.
Table 40. Classification of dependent variables
Dependent Variables Efficiency Effectiveness Sizing Effort Reproducibility Accuracy Perceived Ease of Perceived Usefulness Use Adoption
Performance Based Perception Based
Intention to Use
235
8.3.3 Experimental treatments

The treatments correspond to the two levels of the independent variable: the use of OOmFP versus the use of IFPUG FPA to size an OO system. We chose a within-subject design experiment to control for differences in human ability. In a within-subject design, each subject contributes an observation for each treatment, which is an additional advantage given the small sample size. In order to cancel out a possible learning effect due to similarities in the treatments (i.e. the relatedness of both FSM methods), we consider the sequence in which the tests are given to the subjects as a factor. In addition, there is a learning effect due to the fact that the same requirements specification is used for all students. If one system is used, the order of applying the methods might introduce a confounding effect. However, this learning effect is also cancelled taking into account the sequence of the tests as a factor. Using the counterbalancing procedure, the subjects were randomly assigned to two groups, with equal numbers in each group and tests presented in a different order: Experimental Group 1: IFPUG FPA first and OOmFP second (n=11) Experimental Group 2: OOmFP first and IFPUG FPA second (n=11)
8.3.4 Instrumentation
The instrumentation used in this experiment includes the experimental object, training materials and a post-task survey. The experimental object was a requirement specification document for building a new Project Management System (PMS) for a fictitious company. This document describes the requirements for the system using the IEEE 830 standard [112]. A software requirements specification is described using this standard in terms of functionality (what is the software supposed to do from the users 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 should support the following transactions: project maintenance (create, change, delete, tasks assignment), type of task maintenance (create, 236
change, delete), task maintenance (create, change, delete), user maintenance (create, change, delete, change password), and inquiries (users, projects and type of tasks). An example of a functional requirement is the following: when the company starts a new project, the employee in charge of the project must enter the data into the system. A project is created with the following data: identification number, description, name of the employee in charge (responsible), start date, estimated duration, estimated final date, actual duration (sum of the duration of the tasks performed until now), cost (sum of all tasks costs associated to the project), situation (0 = under development, 1 = small delay, <10% more than the estimated time, 2 = large delay, >= 10% more than the estimated time, 3=finished), observations. The following training materials were prepared for all subjects: a set of instructional slides, describing each FSM method and the procedure for applying it; a working example showing how the methods could be applied; and a measurement guideline summarizing the measurement rules of the methods. The working example for the IFPUG FPA training session included a requirements specification document of a Banking System as well as the specification of an ER model and screens of the system. The worked example for OOmFP included the requirement specification of a Library System and a complete specification of an OO-Method conceptual model. For each method, two training sessions of two hours were needed. In the first session, we explained the measurement rules of the method and demonstrated their application using some toy examples. In the second session, we demonstrated the application of the measurement rules on a complete case study. We also defined a post-task survey with 14 closed questions, which were the items used to measure the constructs of the Method Adoption Model [166]. These items were formulated using a 5-point Likert scale, using the opposing statements question format. The order of the items was randomized and half the questions negated to avoid monotonous responses. The perceived ease of use was measured using five items on the survey (Questions 1, 3, 4, 6, and 9). The perceived usefulness was measured using six items on the survey (Questions 2, 5, 8, 10, 11, and 13). Finally, the intention to use was measured using three items on the survey (Questions 7, 12, 14). The survey is shown in Appendix B. 237
8.3.5 Experimental tasks

The experiment included the following experimental tasks: conceptual modeling task, sizing task, and post-task survey. In the conceptual modeling task, each experimental group was given the requirements specification and asked to specify a conceptual schema using the OO-Method approach. Subjects were allowed to use the Oliva Nova Modeling Software to document their models. Moreover, they were allowed to refer to the training materials while performing this task. In the sizing task, each experimental group used IFPUG FPA and OOmFP in a different order. Sizing with OOmFP includes a measurement task where the measurement rules of the method are applied. However, sizing with IFPUG FPA includes two activities: a modeling task, where an ER model and screen prototypes are developed, and a measurement task, where the measurement rules are applied. Finally, in the post-task survey, when the subjects had finished the sizing task for a method, they were asked to complete a survey to evaluate the FSM method they had used. Table 41 shows the sequence of the training sessions and experimental tasks performed.
Table 41. Summary of training sessions and experimental tasks
Trial 1 2 3 4 5 6 7 8 Training Sessions and Experimental Tasks Experimental Group 1 Experimental Group 2 Training session in conceptual modeling Conceptual Modeling Task Training session in IFPUG FPA Training session in OOmFP Sizing Task with IFPUG FPA Sizing Task with OOmFP - Modeling Task - Measurement Task - Measurement Task Post-task survey for IFPUG FPA Post-task survey for OOmFP Training session in OOmFP Training session in IFPUG FPA Sizing Task with OOmFP Sizing Task with IFPUG FPA - Measurement Task - Modeling Task - Measurement Task Post-task survey for OOmFP Post-task survey for IFPUG FPA
238
8.3.6 Hypothesis formulation

In order to evaluate whether the proposed method (OOmFP) is more efficient and/or effective than IFPUG FPA and (more) likely to be adopted in practice, we planned to test a number of hypotheses. Included are also hypotheses related to the validation of the MAM as an evaluation instrument for FSM methods. Figure 59 shows the theoretical model being tested in this experiment. It summarizes the hypotheses that will be tested and the relationships between the independent variable and the dependent variables and the causal relationships between the constructs of the MAM.
SIZING EFFORT (D1)
H1
REPRODUCIBI LITY(D2)
H7
H2
Independent (predictor) variable
ACCURACY (D3)
FSM METHOD (I)
H3
H4
PERCEIVED EASE OF USE (D4)
H8
Dependent (outcome) variables

H9
H5
H10
H6
PERCEIVED USEFULNESS (D5)
H11
H12
INTENTION TO USE (D6)
Figure 59. Theoretical Model (First Experiment)
239
Research Question 1: Comparison between methods (Efficiency) Hypothesis 1: This hypothesis tests the relationship between the independent variable (FSM method) and Sizing Effort (D1). Null hypothesis, H1N: OOmFP will take more or as much time as IFPUG FPA. Alternative hypothesis, H1A: OOmFP will take less time than IFPUG FPA. To allow for a fair comparison of the efficiency of both methods, we have to take separate timings of different activities for both methods. Separating these times is necessary because the FSM methods compared in the experiment require different activities in the identification and measurement steps that lead from the user requirements to the functional size value. For each subject we have collected the time (in work-hours) spent to complete the (conceptual) modeling and measurement tasks associated with each FSM method. The modeling time for the application of IFPUG FPA corresponds to the time the subjects spent to develop an Entity-Relationship diagram and screen prototypes. This modeling is required in the sizing task for IFPUG FPA. In fact, the subjects made their ER models using the implicit knowledge gathered when they built their OO-Method conceptual models in the previous phase. For OOmFP, the modeling time is the time the subjects spent on building a complete OO-Method conceptual model specification, which includes all aspects that contribute to functional size. The requirements modeling considered here is part of the conceptual modeling task of the experiment. The measurement time in both methods is the time that the subjects spent to apply the method measurement rules (as part of the sizing tasks). Given the research questions and context of the experiment, we do not include the OO-Method conceptual modeling time in the sizing effort required for the application of the FSM methods. As OOmFP is specifically intended to be used in conjunction with OO-Method, constructing an OO-Method conceptual model is done anyway, regardless whether this FSM method or another is used. We assume, however, that if IFPUG FPA is used, an ER data model and a set of screen prototypes are needed before the elements that contribute to functional size can be identified20.
20 As remarked before, this is an implicit requirement of the IFPUG rules for FPA. Due to a lack of examples in the IFPUG manual, counting function points directly from the original requirements document is obviously more difficult and hence there is a danger that requiring
240
Research Question 1: Comparison between methods (Effectiveness) Hypothesis 2: This hypothesis tests the relationship between the independent variable and Reproducibility (D2). Null hypothesis, H2N: OOmFP will produce less or equally consistent assessments than IFPUG FPA. Alternative hypothesis, H2A: OOmFP will produce more consistent assessments than IFPUG FPA. The effectiveness of a FSM method depends amongst others on the interrater reliability of the measurements [167]. We postulate that the closer the measurements obtained by different raters, the more effective the FSM method is. Hypothesis 3: This hypothesis tests the relationship between the independent variable and Accuracy (D3). Null hypothesis, H3N: OOmFP will produce less or equally accurate assessments than IFPUG FPA. Alternative hypothesis, H3A: OOmFP will produce more accurate assessments than IFPUG FPA. Even when the obtained measurements are (nearly) identical, they can be far away from the true value for functional size. Therefore, another dimension of effectiveness is related to the accuracy of the method in producing the right value. This third hypothesis requires an objective standard against which to evaluate accuracy. Thus, we can only compare OOmFP and IFPUG FPA if there is a third (and supposedly right) way of assessing functional size. In order to do this, the system is sized with IFPUG FPA by a Certified Function Point Specialist (CFPS), and we take this count as our standard. The CFPS is a formal recognition of a level of expertise in the area of Function Point Analysis. A CFPS is acknowledged as having the skills necessary to perform consistent and accurate function point counts and comprehension of the most recent counting practices. In order to apply FPA, the CFPS was given the original requirements documentation. The CFPS was not familiar with OO-Method, and hence no OO-Method conceptual model was provided. Once the function point count was obtained from the CFPS, we compared how close the measurements were
subjects to do so would bias the experimental results in favour of OOmFP (especially with respect to reproducibility and accuracy).
241
that were produced by the subjects that used IFPUG FPA and by the subjects that used OOmFP21. Research Question 2: Comparison between methods (perception of Performance and Intention to Use) Hypothesis 4: This hypothesis tests the relationship between the independent variable (FSM method) and Perceived Ease of Use (D4). This hypothesis follows from H1 (i.e. differences in actual efficiency between the FSM methods) and the causal relationship between actual efficiency and Perceived Ease of Use (i.e. perception of efficiency) as shown in Figure 59 (see Hypothesis 10 below). Null hypothesis, H4N: Participants will perceive OOmFP to be more or equally difficult to use than IFPUG FPA. Alternative hypothesis, H4A: Participants will perceive OOmFP to be easier to use than IFPUG FPA. As the post-task survey for a FSM method is applied directly after the sizing task associated with that method, it is hypothesized that the perception of efficiency will be influenced by the experiences with applying the FSM method (according to the Method Evaluation Model). Therefore the relationship between the independent variable and Perceived Ease of Use that is tested is an indirect one. This observation also holds for the following hypotheses: Hypothesis 5: This hypothesis tests the relationship between the independent variable and Perceived Usefulness (D5). This follows from H2 and H3, and the causal relationship between actual effectiveness and Perceived Usefulness defined in the MEM (see H11 and H12 below). In addition, this follows from the relationship between Perceived Ease of Use and Perceived Usefulness in the MEM (see H13 below). Null hypothesis, H5N: Participants will perceive OOmFP to be less or equally useful than IFPUG FPA. Alternative hypothesis, H5A: Participants will perceive OOmFP to be more useful than IFPUG FPA.
21 Although there is of course no certainty that the CFPS produced the true value of functional size, the certification is our best guarantee for the trust that we have in the functional size measurement that was obtained.
242
Hypothesis 6: This hypothesis tests the relationship between the independent variable and Intention to Use (D6). This follows from H4, H5 and the relationships between Perceived Ease of Use, Perceived Usefulness and Intention to Use defined in the MEM (see H14 and H15 below). Null hypothesis, H6N: Participants will be less or equally likely to use OOmFP than IFPUG FPA. Alternative hypothesis, H6A: Participants will be more likely to use OOmFP than IFPUG FPA. Research Question 3: Acceptance of OOmFP The following hypotheses test whether the proposed method is likely to be adopted in practice. Thus, here the question of likely adoption in practice is more an absolute one than the relative question of which method (OOmFP or IFPUG FPA) is more likely to be adopted in practice in research question 2. Even if the results of the experiment demonstrate that OOmFP is more likely to be adopted in practice than IFPUG FPA, it is not sure whether the subjects really intend to adopt it. Therefore, the following hypotheses are introduced. Hypothesis 7: This hypothesis tests how efficient the subjects thought the OOmFP was in achieving its objectives. Null hypothesis, H7N: Participants will perceive OOmFP to be difficult to use. Alternative hypothesis, H7A: Participants will perceive OOmFP to be easy to use. Hypothesis 8: This hypothesis tests how effective the subjects thought the OOmFP was in achieving its objectives. Null hypothesis, H8N: Participants will perceive OOmFP not to be useful. Alternative hypothesis, H8A: Participants will perceive OOmFP to be useful. Hypothesis 9: This hypothesis tests whether the subjects intend to use OOmFP in the future. Null hypothesis, H9N: Participants do not intend to use OOmFP. Alternative hypothesis, H9A: Participants intend to use OOmFP.
243
Research Question 4: Validation of the Method Adoption Model (MAM) Finally, we test a number of hypothesized relationships between the dependent variables in our experiment based on the causal relationships defined in the Method Evaluation Model. This represents a test of the predictive and explanatory power of the model. However, we remark that only the MAM and its inputs from actual performance are tested. Actual Usage of a method will be determined by Intention to Use. This follows from empirical studies of the Technology Acceptance Model (TAM) [140], which have reported a strong significant causal link between behavioural intention to use and actual behaviour [157]. Hypothesis 10: Measurement Time is a performance-based measure of efficiency, whereas Perceived Ease of Use is a perception-based measure of efficiency. According to the Method Evaluation Model, perceptions of efficiency are determined by actual efficiency. Null hypothesis, H10N: Perceived Ease of Use is not determined by Measurement Time. Alternative hypothesis, H10A: Perceived Ease of Use is determined by Measurement Time. Hypothesis 11: Reproducibility is a performance-based measure of effectiveness, whereas Perceived Usefulness is a perception-based measure of effectiveness. According to the Method Evaluation Model, perceptions of efficiency are determined by actual effectiveness. Null hypothesis, H11N: Perceived Usefulness is not determined by Reproducibility. Alternative hypothesis, H11A: Perceived Usefulness is determined by Reproducibility. Hypothesis 12: Accuracy is a performance-based measure of effectiveness, whereas Perceived Usefulness is a perception-based measure of effectiveness. According to the Method Evaluation Model, perceptions of efficiency are determined by actual effectiveness. Null hypothesis, H12N: Perceived Usefulness is not determined by Accuracy. Alternative hypothesis, H12A: Perceived Usefulness is determined by Accuracy. 244
Hypothesis 13: This is one of the causal relationships defined in the Method Evaluation Model and based on the Technology Acceptance Model [140]. Null hypothesis, H13N: Perceived Usefulness is not determined by Perceived Ease of Use. Alternative hypothesis, H13A: Perceived Usefulness is determined by Perceived Ease of Use. Hypothesis 14: This is one of the causal relationships defined in the Method Evaluation Model and based on the Technology Acceptance Model [140]. Null hypothesis, H14N: Intention to Use is not determined by Perceived Ease of Use. Alternative hypothesis, H14A: Intention to Use is determined by Perceived Ease of Use. Hypothesis 15: This is one of the causal relationships defined in the Method Evaluation Model and based on the Technology Acceptance Model [140]. Null hypothesis, H15N: Intention to Use is not determined by Perceived Usefulness. Alternative hypothesis, H15A: Intention to Use is determined by Perceived Usefulness.
8.4
Experiment operation
8.4.1 Preparation
At the time the experiment was performed, the subjects had taken a course in conceptual modeling using OO-Method. We also ran separate training sessions on IFPUG FPA and OOmFP for each treatment group prior to getting them to do the sizing tasks. However, the subjects were not aware of what aspects we intended to study, nor were they informed of the stated hypothesis. The course in conceptual modeling was run in three sessions of two hours each. In the first session, we explained the primitives of the OO-Method conceptual models using some practical examples. In the second session, we applied the concepts presented in the previous session in the resolution of a complete case study involving a Library system. Then, in the third session, we 245
demonstrated how the conceptual model obtained in the previous session can be built and documented using the Oliva Nova Modeling Software. The training sessions on IFPUG FPA and OOmFP were run before the subjects applied a given method (see Table 41). Two sessions of two hours were needed for each method. In the first session, we explain the measurement rules of the method and demonstrate their application using some toy examples. In the second session, we demonstrate the application of the measurement rules on a complete case study (i.e. the Library system).
8.4.2 Execution
The subjects received all the materials as described before. We also explained how to do the experimental tasks. The experimental tasks were run on-line as part of a course [72]. For the conceptual modeling task with OO-Method, we gave them a maximum of six hours (two sessions of three hours each). For the sizing task, we gave them a maximum of about five hours (two sessions of two hours and thirteen minutes). The sequence of the experimental tasks can be seen in Table 41. Each subject had to do each test alone. The use of the training materials when performing the tasks was allowed, but we made sure that no interaction whatsoever between subjects occurred.
8.4.3 Data recording and validation

The performance-based dependent variables were measured using two different data collection forms. The first form was used to record the outputs of the IFPUG FPA functional size measurement and the time spent to size the requirement specifications. For the IFPUG FPA method, we called the time that the subjects spent to develop the data oriented abstraction assumed by FPA modeling time, and the time that the subjects spent to measure it measurement time. The second form was used to record the outputs of the OOmFP functional size measurement and the time spent to size the requirements specifications. For the OOmFP method, we called the time that the subjects spent to develop the OO-Method conceptual schema modeling time, and the time that the subjects spent to apply the OOmFP rules measurement time. The following data was collected as part of the experiment: 246
Subjects were timed as to how long it took them to complete the conceptual model task (for OOmFP) and sizing task (for IFPUG FPA and OOmFP). In the sizing task for IFPUG FPA, we have collected separate times for modeling and measurement tasks. The results of the sizing task were analyzed for completeness. The responses to the post-task survey were coded in numerical form.
Once the data were collected, we verified whether the tests were complete. As two students used only OOmFP, we took into account the responses of twenty subjects.
8.5
Analysis and interpretation
In general, the results are described in terms of their statistical significance, which is measured by alpha (). This represents the probability that the result could have occurred by chance due to a Type I error. We define the following levels of significance: Not significant: > .1 Low significance: < .1 Medium significance: < .05 High significance: < .01 Very high significance: < .001
The analysis and interpretation of the results are divided into four phases according to the research questions stated.
8.5.1 Comparative analysis of the performance of the FSM methods

We first tested hypothesis H1 related to the efficiency of the FSM methods. Given the differences in the steps of these FSM methods previously mentioned, we decided to use only the time related to the measurement time (presented in Appendix C). 247
The descriptive statistics for the IFPUG FPA and OOmFP methods measurement time are presented in Table 42.
Table 42. Descriptive statistics for measurement time
Measurement Time Number of observations Mean Standard deviation Minimum Maximum Percentiles (25th, 50th and 75th) IFPUG FPA 20 2.4105 .3334 1.85 3.33 2.17; 2.38; 2.53 OOmFP 20 3.0070 0.6689 2.00 4.23 2.35; 2.97; 3.38
The Kolmogorov-Smirnov test for normality was applied to the differences of the paired observations. As this distribution was normal and measurement time is a continuous variable, we decided to use the Paired t-test to check for a difference in mean measurement time between OOmFP and IFPUG FPA. In order to evaluate the significance of the observed difference, we applied the test with a significance level of 5 %, i.e. = .05. The result of the test does not allow the rejection of the null hypothesis (H1N), meaning that we cannot empirically corroborate that OOmFP will take less time than IFPUG FPA. In fact, the test shows that, for the data collected, the mean measurement time for IFPUG FPA is significantly lower than that for OOmFP (Table 43). The reason could be that the object used takes into account all perspectives of an OO system (data, process, and behaviour). Consequently, the subjects spent more time in applying all the OOmFP measurement rules. However, this problem can be solved by providing tool support for measurement rules application.
Table 43. Paired samples t-test rank for differences in mean measurement times (IFPUG FPA versus OOmFP; = 0.05)
Dependent variable Measurement Time Mean -.596 Std. Dev. .7716 Std. Error Mean .17254 95% Confidence Interval of the difference -.957 (lower) -.235 (upper) t -3.45 1-tailed p-value .0015
Then, we test hypothesis H2 related to the effectiveness of the FSM methods, in terms of reproducibility. Table 44 shows descriptive statistics for 248
the functional size produced (presented in Appendix C) for the IFPUG FPA and OOmFP methods. Note that the values of the column Size in IFPUG FPA are unadjusted function point values.
Table 44. Descriptive statistics for functional size
Functional Size Number of observations Mean Standard deviation Minimum Maximum Percentiles (25th, 50th and 75th) IFPUG FPA 20 132.40 17.443 114 174 121; 126; 144.50 OOmFP 20 159.55 7.964 148 173 151.75; 159; 164.50
In order to measure the degree of variation between assessments produced by different subjects using the same method, we used a practical statistic similar to that proposed by Kemerer [167]. This statistic is calculated as the difference in absolute value between the count produced by a subject and the average count (for the same FSM method) produced by the other subjects in the sample, relative to this average count. Reproducibility measurements (REP) were thus obtained for each observation by applying the following equation:
REPi = Average Other assessments Subject Assessmenti Average Other Assessments
The REPi obtained for both methods are presented in Appendix C. Then, the differences in reproducibility assessments obtained using both methods were described using the Kolmogorov-Smirnov test to ascertain if the distribution was normal. The skewness of the distribution is close to one (1.230), meaning more observations in the left tail than normal. Because of this indication of a non-normal distribution, we used the Wilcoxon signed rank test for the difference in median reproducibility assessments, which is a non-parametric alternative to the paired samples t-test. The result of the onetailed test (see Table 45) allows the rejection of the null hypothesis (H2N), meaning that we empirically corroborate that OOmFP produces more consistent assessments than IFPUG FPA.
249
Table 45. 1-tailed Wilcoxon signed rank test for differences in median reproducibility assessments (IFPUG FPA versus OOmFP; = 0.05)
Dependent variable Reproducibility Mean Rank 5.25 Sum of Ranks 10.50 z -3.409 1-tailed pvalue .000
Next, we tested hypothesis H3 related to the effectiveness of the FSM methods, in terms of accuracy. The value obtained by the CFPS is 153 unadjusted function points. In order to compare the assessments produced by both methods and a Certified Function Point Specialist (CFPS), the Magnitude of Relative Error (MRE) was used [168] [169] [170] [171]. Accuracy measurements were obtained by applying the following equation for each observation:
MREi = CFPS assessment Subject assessmenti CFPS assessment
The MREi obtained for both methods are presented in the Appendix C. Then, the differences in accuracy assessments obtained were described using the Kolmogorov -Smirnov test to ascertain if the distribution was normal. As the distribution was not normal, we used the Wilcoxon signed rank test for the difference in median accuracy assessments. In order to evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %. The result of the test (see Table 46) allows the rejection of the null hypothesis (H3N), meaning that we empirically corroborate that OOmFP produces more accurate assessments than IFPUG FPA.
Table 46. 1-tailed Wilcoxon signed rank test for differences in median accuracy assessments (IFPUG FPA versus OOmFP; = 0.05)
Dependent variable Accuracy Mean Rank 4.75 Sum of Ranks 9.50 z -3.442 1-tailed p-value .000
250
8.5.2 Comparative analysis of the likelihood of adoption in practice of the FSM methods
We then tested hypotheses H4, H5, and H6 related to the perceptions of the FSM methods, in terms of perceived ease of use, perceived usefulness and intention to use. Descriptive statistics for the perceived ease of use of the IFPUG FPA and OOmFP methods are presented in Table 47. The mean values obtained show that OOmFP has a higher mean score than IFPUG FPA, meaning that is it perceived to be easier to use than IFPUG FPA.
Table 47. Descriptive statistics for perceived ease of use
Perceived Ease of Use Number of observations Mean Standard deviation Minimum Maximum Percentiles (25th, 50th and 75th) IFPUG FPA 20 2.7100 .4517 1.80 3.60 2.40; 2.60; 3.15 OOmFP 20 2.90 .7033 1.60 4.40 2.60; 2.60;3.40
In order to evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %, i.e. = .05. As the data were normal, we decided to use Paired t-test to evaluate the statistical significance of the observed difference in mean perceived ease of use. The result of the one-tailed test (see Table 48) allows the rejection of the null hypothesis (H4N), meaning that we empirically corroborate that the participants perceived OOmFP as easier to use than IFPUG FPA.
Table 48. 1-tailed Paired samples t-test rank for differences in mean perceived ease of use (IFPUG FPA versus OOmFP; = 0.05)
Dependent variable Perceived Ease of Use Mean .190 Std. Deviation .8620 Std. Error Mean .1927 95% Confidence Interval of the difference -.213 (lower) .593 (upper) t .986 1-tailed p-value .01685
Table 49 shows descriptive statistics for the perceived usefulness of the IFPUG FPA and OOmFP methods. In the same way, the KolmogorovSmirnov test for normality was applied to the differences of the paired observations. As this distribution was normal, the Paired t-test was selected to 251
check for a difference in mean perceived usefulness between OOmFP and IFPUG FPA.
Table 49. Descriptive statistics for perceived usefulness
Perceived Usefulness Number of observations Mean Standard deviation Minimum Maximum Percentiles (25th, 50th and 75th) IFPUG FPA 20 2.4800 .4606 1.60 3.60 2.20; 2.50; 2.80 OOmFP 20 3.5250 .4920 2.80 4.60 3.20; 3.40; 3.80
In order to evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %. The result of the onetailed test (see Table 50) allows the rejection of the null hypothesis (H5N), meaning that we empirically corroborate that participants perceive OOmFP to be more useful than IFPUG FPA.
Table 50. 1-tailed Paired Samples t-test rank for differences in mean perceived usefulness (IFPUG FPA versus OOmFP; = 0.05)
Dependent variable Perceived Usefulness Mean 1.020 Std. Deviation .6582 Std. Error Mean .1471 95% Confidence Interval of the difference .7119 (lower) 1.3281 (upper) t 6.930 1-tailed p-value .000
Table 51 shows descriptive statistics for the intention to use of the IFPUG FPA and OOmFP methods. Kolmogorov-Smirnov test for normality was applied to the differences of the paired observations. As this distribution was normal, the Paired t-test was used to check for a difference in mean intention to use between both FSM methods. To evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %.
252
Table 51. Descriptive statistics for intention to use

Intention to Use IFPUG FPA OOmFP
Number of observations Mean Standard deviation Minimum Maximum Percentiles (25th, 50th and 75th)
20 2.6333 .6657 1.33 3.67 2,33; 2,66; 3,00
20 3.6667 .6839 2.33 4.67 3,33; 3,66; 4,33
The result of the one-tailed test (see Table 52) allows the rejection of the null hypothesis (H6N), meaning that we empirically corroborate that participants will be more likely to use OOmFP than IFPUG FPA.
Table 52. 1-tailed Paired samples t-test rank for differences in mean intention to use (IFPUG FPA versus OOmFP; = 0.05)
Dependent variable Intention to Use Mean 1.033 Std. Deviation .8976 Std. Error Mean .2007 95% Confidence Interval of the difference .6132 (lower) 1.4535 (upper) t 5.148 1-tailed p-value .000
Finally, Figure 60 shows the mean responses to each question on the post-task survey for each FSM method. The obtained results show that the OOmFP method scored highest on all items except Q1 and Q2.
5
Mean Response
Q1
2,9
Q2
2,6
Q3
2,9
Q4
2,7
Q5
3,65
Q6
2,8
Q7
3,6
Q8
3,9
Q9
3,2
Q10
3,5
Q11
3,85
Q12
3,85
Q13
3,85
Q14
3,55
OOmFP
FPA
2,95
2,7
2,7
2,1
2,7
2,65
2,15
2,1
3,15
2,35
2,55
2,9
2,55
2,85
Figure 60. Mean Responses to Post-task Survey
253
Overall, the responses to the post-task surveys suggest that OOmFP is more useful and is more likely to be used in the future. However, scores on individual items are not meant to be interpreted in isolation as different items measure the same construct. Thus, we need to evaluate the construct validity and reliability of the items used to measure perception-based variables. This validates the measurement instrument associated with the Method Adoption Model Construct Validity Factor Analysis is the most widely used technique for evaluating the construct validity for this type of measurement instrument. However, a sample size of 200 is recommended to achieve stability of the results [172]. As the sample size of this experiment is too small, inter-item correlation analysis was carried out. We assume that all items associated with a particular construct have equal weights. Campbell and Fiske [173] proposed the concepts of convergent and discriminant validity in the context of construct validity: Convergent validity (CV): refers to the convergence among different indicators used to measure a particular construct. The correlation between indicators used to measure the same construct should be as high as possible. CV of an indicator is measured by the average correlation between the indicator and the other indicators that are used to measure the same construct. Discriminant validity (DV): refers to the divergence of indicators used to measure different constructs. The correlation between indicators used to measure different constructs should be as low as possible. DV of an indicator is measured by the average correlation between the indicator and the indicators that are used to measure a different construct. Table 53 shows the inter-item correlations for all fourteen items that were used in the survey. The last three columns of the matrix show the results of the construct validity analysis. An item is valid if convergent validity is higher than discriminant validity (as suggested by Campbell and Fiske [173]). The results of the validity analysis for each construct are: Perceived Ease of Use (PEOU): The obtained results show that convergent validity was greater than discriminant validity for all items. The average convergent validity of all items was .57. Overall, 254
convergent validity was more than twice the size of discriminant validity. Perceived Usefulness (PU): The obtained results show that the convergent validity was greater than discriminant validity for five of the six items. Q11 item have the same value for convergent and discriminant validity. The average convergent validity across all indicators was 0.40. Overall, convergent validity was greater than the size of discriminant validity. Intention to Use (ITU): The obtained results show that the convergent validity was high. The average convergent validity across all indicators was .62. Overall, convergent validity was more than twice the size of discriminant validity. The problem that emerged from the analysis was the low level of convergent validity for the item Q11. This item has a value for CV that is equal to its value for DV. The average convergent validity for Perceived Usefulness is .40. For this reason, Q11 was excluded from the analysis. With the exclusion of this item, the results of the validity analysis are improved as shown in Table 54. This can be noted since the average convergent validity for Perceived Usefulness is now .47.
255
Table 53. Correlation between survey items (construct validity analysis)

Perceived Ease of Use Q1 Q3 Q4 Q6 Q9 1,00 0,61 0,42 0,37 0,47 0,61 1,00 0,46 0,40 0,51 0,42 0,46 1,00 0,48 0,36 0,37 0,40 0,48 1,00 0,56 0,47 0,51 0,36 0,56 1,00 0,24 0,18 0,21 0,43 0,28 0,55 0,68 0,41 0,45 0,50 0,37 0,08 0,03 0,27 0,14 0,51 0,33 0,48 0,31 0,10 0,54 0,51 0,34 0,13 0,26 0,31 0,24 0,33 0,66 0,31 0,15 0,24 -0,24 0,02 0,04 0,39 0,06 0,07 0,41 -0,12 0,40 0,36 -0,14 0,11 0,19 Q2 0,24 0,18 0,21 0,43 0,28 1,00 0,57 0,22 0,00 -0,16 0,41 0,20 0,15 0,30 Perceived Usefulness Q5 Q8 Q10 Q11 0,55 0,37 0,51 0,54 0,68 0,08 0,33 0,51 0,41 0,03 0,48 0,34 0,45 0,27 0,31 0,13 0,50 0,14 0,10 0,26 0,57 0,22 0,00 -0,16 1,00 0,03 0,37 0,44 0,03 1,00 0,27 0,16 0,37 0,27 1,00 0,54 0,44 0,16 0,54 1,00 0,52 0,30 0,41 0,13 0,38 0,39 0,29 0,33 0,17 0,41 0,41 0,13 0,61 0,27 0,32 0,55 Q13 0,31 0,24 0,33 0,66 0,31 0,41 0,52 0,30 0,41 0,13 1,00 0,14 0,43 0,20 Intention to Use Q7 Q12 Q14 0,15 0,39 0,40 0,24 0,06 0,36 -0,24 0,07 -0,14 0,02 0,41 0,11 0,04 -0,12 0,19 0,20 0,15 0,30 0,38 0,17 0,61 0,39 0,41 0,27 0,29 0,41 0,32 0,33 0,13 0,55 0,14 0,43 0,20 1,00 0,14 0,85 0,14 1,00 0,27 0,85 0,27 1,00 CV 0,58 0,60 0,54 0,56 0,58 0,34 0,49 0,33 0,43 0,35 0,46 0,66 0,47 0,71 Overall DV VALID? 0,38 YES 0,30 YES 0,17 YES 0,31 YES 0,19 YES 0,25 YES 0,47 YES 0,24 YES 0,35 YES 0,35 NO 0,33 YES 0,18 YES 0,23 YES 0,29 YES
PEOU Q1 Q3 Q4 Q6 Q9 Q2 Q5 Q8 Q10 Q11 Q13 Q7 Q12 Q14
PU
ITU
256
Table 54. Correlation between survey items (after Q11 removed)

Perceived Ease of Use Q1 Q3 Q4 Q6 Q9 1,00 0,57 0,37 0,37 0,44 0,57 1,00 0,40 0,41 0,48 0,37 0,40 1,00 0,48 0,32 0,37 0,41 0,48 1,00 0,57 0,44 0,48 0,32 0,57 1,00 0,31 0,25 0,28 0,44 0,33 0,65 0,80 0,50 0,46 0,56 0,28 -0,06 -0,10 0,27 0,05 0,48 0,29 0,45 0,31 0,06 0,31 0,24 0,33 0,66 0,30 0,22 0,32 -0,21 0,03 0,08 0,39 0,05 0,06 0,41 -0,13 0,47 0,43 -0,11 0,12 0,23 Perceived Usefulness Q2 Q5 Q8 Q10 Q13 0,31 0,65 0,28 0,48 0,31 0,25 0,80 -0,06 0,29 0,24 0,28 0,50 -0,10 0,45 0,33 0,44 0,46 0,27 0,31 0,66 0,33 0,56 0,05 0,06 0,30 1,00 0,55 0,32 0,03 0,43 0,55 1,00 0,12 0,43 0,54 0,32 0,12 1,00 0,21 0,30 0,03 0,43 0,21 1,00 0,41 0,43 0,54 0,30 0,41 1,00 0,18 0,36 0,50 0,34 0,15 0,17 0,18 0,43 0,41 0,43 0,28 0,60 0,36 0,36 0,21 Intention to Use Q7 Q12 Q14 0,22 0,39 0,47 0,32 0,05 0,43 -0,21 0,06 -0,11 0,03 0,41 0,12 0,08 -0,13 0,23 0,18 0,17 0,28 0,36 0,18 0,60 0,50 0,43 0,36 0,34 0,41 0,36 0,15 0,43 0,21 1,00 0,15 0,84 0,15 1,00 0,28 0,84 0,28 1,00 CV 0,55 0,57 0,51 0,57 0,56 0,47 0,53 0,39 0,42 0,54 0,67 0,48 0,71 Overall DV VALID? 0,39 YES 0,29 YES 0,15 YES 0,34 YES 0,19 YES 0,28 YES 0,51 YES 0,22 YES 0,34 YES 0,33 YES 0,20 YES 0,24 YES 0,29 YES
PEOU Q1 Q3 Q4 Q6 Q9 PU Q2 Q5 Q8 Q10 Q13 ITU Q7 Q12 Q14
257
Reliability We also conducted a reliability analysis on the items used to measure the PEOU, PU and ITU variables. The reliability of a test is the extent to which it can be relied upon to produce true scores as a measure of its consistency/ variability across occasions or with different sets of equivalent items. The item Q11 was excluded for this analysis. Table 55 shows the results obtained for each construct using Cronbachs alpha, which is the most common measure of scale reliability. These values are all .70 or above as required for constructs to be deemed reliable as suggested by Nunally [174]. Also, Caplan et al. [175] argue that alphas as low as .50 are considered acceptable in some cases.
Table 55. Item reliabilities for constructs
Item Reliability Construct CRONBACHS Perceived Ease of Use .82 Perceived Usefulness .70 Intention to use .70
In addition, the general Cronbach alpha obtained for the instrument was .74. As a result of this analysis, we conclude that the items on the survey (except Q11) are reliable and valid measures of the underlying constructs of the proposed theoretical model. Also, as a result of this analysis, it can be observed that if Q12 is deleted, the reliability for Intention to Use will be 0.91, indicating that this item is not related to this constructor. Therefore, these results also allow the partial validation of the Method Adoption Model (Research Question 4) in terms of the validity and reliability of the measurement instrument (the measurement part of the model).
8.5.3 Analysis of the acceptance of OOmFP

The objective of this section is to evaluate the likely acceptance in practice of OOmFP (Research Question 3). This requires comparing the mean values of the constructs of the Method Adoption Model for OOmFP (shown in Table 47, Table 49, and Table 51) in order to verify if these values were significantly greater than 3. 258
We first tested hypothesis H7, which is related to the perceived ease of use of the OOmFP method. The Kolmogorov-Smirnov test for normality was applied to the OOmFP perceived ease of use observations. As this distribution was normal, we decided to use the One sample t-test to check for a difference in mean perceived ease of use OOmFP and the value 3. In order to evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %, i.e. = .05. The result for perceived ease of use (Table 56) does not allow the rejection of the null hypothesis (H7N), meaning that we cannot empirically corroborate that participants will perceive OOmFP to be easy to use.
Table 56. 1-tailed One sample t-test rank for differences in mean perceived ease of use
Dependent variable Perceived Ease of Use Mean 2.900 Std. Deviation .7033 Std. Error Mean .1572 95% Confidence Interval of the difference -.4292 (lower) .2292 (upper) t -.636 1-tailed p-value .266
Then, we tested hypothesis H8, which is related to the perceived usefulness. The Kolmogorov-Smirnov test for normality was applied to the OOmFP perceived usefulness observations. As this distribution was normal, we used the One sample t-test to check for a difference in mean perceived usefulness OOmFP and the value 3. In order to evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %, i.e. = .05. The result for perceived usefulness (Table 57) allows the rejection of the null hypothesis (H8N), meaning that we can empirically corroborate that participants will perceive OOmFP to be useful.
Table 57. 1-tailed One sample t-test rank for differences in mean perceived usefulness
Dependent variable Perceived Usefulness Mean 3.500 Std. Deviation .4920 Std. Error Mean .1100 95% Confidence Interval of the difference .2697 (lower) .7303 (upper) t 4.544 1-tailed p-value .000
Finally, we tested hypothesis H9 related to the intention to use. The Kolmogorov-Smirnov test for normality was applied to the OOmFP intention 259
to use observations. As this distribution was normal, we use the One sample ttest to check for a difference in mean intention to use OOmFP and the value 3.
Table 58. 1-tailed One sample t-test rank for differences in mean intention to use
Dependent variable Intention to Use Mean 3.666 Std. Deviation .6839 Std. Error Mean .1529 95% Confidence Interval of the difference .3466 (lower) .9868 (upper) t 4.359 1-tailed p-value .000
In order to evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %, i.e. = .05. The result for intention to use shown in Table 58 allows the rejection of the null hypothesis (H9N), meaning that we can empirically corroborate that participants intend to use OOmFP.
8.5.4 Validation of Method Adoption Model (MAM)

According to the Method Evaluation Model (MEM), there exist a number of hypothesized causal relationships between the dependent variables in our study. In general, the relationships between the constructs of the Method Adoption Model (MAM) and the external variables of the MEM explain the external behaviour towards a method (see Figure 61). If these relationships are validated, then the MAM can be used to predict the actual usage of a method. The intention of this section is to validate the structural part of the MAM in terms of the causal relationships between its constructs and with its external variables, with the exception of Actual Usage. According to Davis [140] and Moody [70] it is not possible to validate the hypothesized relationship between Intention to Use and Actual Usage in an experimental context such as the one used here22. We have chosen regression analysis to evaluate the MAM since the hypotheses to test are causal relationships between continuous variables. This evaluation was conducted in four phases using four separate regression analyses taking into account each dependent variable:
22 Note that the third research question that we wish to answer relates to the validation of the Method Adoption Model, not the Method Evaluation Model which would also require validating the causal relationship between Intention to Use and Actual Usage.
260
Phase 1 (simple regression): the effect of Actual Efficiency (independent variable) on Perceived Ease of Use (dependent variable); this is a test of hypothesis H7. Phase 2 (multiple regression): the effect of Actual Effectiveness (Reproducibility and Accuracy independent variables) on Perceived Usefulness (dependent variable); this is a test of hypothesis H8 and H9. Phase 3 (simple regression): the effect of Perceived Ease of Use (independent variable) on Perceived Usefulness (dependent variable); this is a test of H10. Phase 4 (multiple regression): the effect of Perceived Ease of Use and Perceived Usefulness (independent variables) on Intention to Use (dependent variable); this is a test of H11 and H12.
METHOD ADOPTION MODEL
Actual Efficiency Perceived Ease of Use
H14 H13
H10
Intention to Use
H15
Actual Usage
Actual Effectiveness
H11, H12
Not evaluated in this study
Figure 61. Relationships between dependent constructs (adapted from Moody, 2001)
Phase 1: A regression model for Actual Efficiency vs Perceived Ease of Use In this phase, we tested hypothesis H10 to verify if perceptions of efficiency are determined by actual efficiency. In order to do this, Actual Efficiency (in terms of measurement time) was used as the independent (predictor) variable and Perceived Ease of Use as the dependent (predicted) variable. The regression equation resulting from the analysis is: Perceived Ease of Use = 5.40 - .83 * Measurement Time 261
The details of the regression analysis are: R squared (r2) = .63 F-statistic = 30.33 Significance level (p) = .000 The result of the regression (see Table 59) allows the rejection of the null hypothesis (H10N), meaning that we empirically corroborate that perceived ease of use is determined by measurement time.
Table 59. Simple regression between Perceived Ease of Use and Measurement Time (OOmFP; = .05)
Model Constant Measurem ent time Unstd. Coeff. (b) 5.405 -.833 Std. Error .465 .151 -.792 Std. Coeff. (Beta) t 11.614 -5.507 Sig. .000 .000 95% Confidence Interval for b 4.42 (lower) 6.38 (upper) -1.15 (lower) -.515 (upper) (r)
-.79
With regard to statistical significance, the regression equation was found to have very high significance with < .001. This means that H7 was strongly confirmed. The significance of the regression coefficient for measurement time indicates that perceptions of efficiency are (partially) determined by actual efficiency. With respect to the predictive power of the model, Actual Efficiency explains 63% of the variance in Perceived Ease of Use. This is indicated by R squared (r2), which measures the proportion of the variance of the dependent variable predicted by the independent variable. The regression coefficient (b) defines the effect of the independent variable on the dependent variable. In this case, an increase in Measurement Time of one minute results in a decrease of .83 in Perceived Ease of Use. This means that the variables are inversely related, as expected. The Pearson correlation coefficient (r) is the degree of linear relationship between two variables measured from the same individual. This defines the effect of the independent variable on the dependent variable. In this case, the correlation coefficient (r) obtained was -.79, which represents a strong correlation between variables. Thus, all results show that the causal relationship between Actual Efficiency and Perceived Ease of Use is statistically significant. Figure 62 shows the scatterplot for Measurement Time against Perceived Ease of Use scores with the regression line. 262
4,00
Perceive d Ease of Use
A A A A A A
3,00
A A A A A A A A
2,00
2,00
2,50
3,00
3,50
4,00
Me a sure m ent Time
Figure 62. Scatterplot: Measurement Time vs Perceived Ease of Use
Phase 2: A regression model for Actual Effectiveness vs Perceived Usefulness In this phase, we tested hypotheses H11 and H12 to verify if Perceived Usefulness (PU) is determined by Reproducibility and Accuracy. To do this, reproducibility and accuracy were used as independent (predictor) variables and PU as the dependent (predicted) variable. The regression equation resulting from the analysis is: Perceived Usefulness = 3.61 + 3.23 * Reproducibility 4.57 * Accuracy The details of the regression analysis are: R squared (r2) = .13 F-statistic = 1.3 Significance level (p) = .1575 The result of the regression summarized in Table 60 does not allow the rejection of the null hypotheses (H11N and H12N), meaning that we cannot empirically corroborate that perceived usefulness is determined by actual effectiveness.
263
Table 60. Multiple regression between PU, Reproducibility and Accuracy (OOmFP; = .05)
Model Constant Reproducibility Accuracy Unstd. Coeff. (b) 3.608 3.228 -4.566 Std. Error .215 3.8 2.9 .202 -374 Std. Coeffi. (Beta) t 16.8 .834 -1.544 Sig. .000 .416 .141 95% Confidence Interval for b 3,15 (lower) 4,06 (upper) -4,94 (lower) 11,39 (upper) -10,80 (lower) 1,674 (upper) (r)
.069 -.302
The regression coefficients for reproducibility and accuracy were not significant ( > .1). This means that H11 and H12 (see Figure 61) were not confirmed. This also suggests that perceptions in usefulness are not determined by perceptions in actual effectiveness. A possible explanation is that the participants do not know the results of their measurement. Consequently, they do not have the perception of usefulness of the method they applied. For future experiments a solution could be to present the results prior to getting them to do the surveys.
A A
A A A A A A
A A A A
A A A A
Figure 63. Scatterplot: Perceived Usefulness vs. Reproducibility and Accuracy
With respect to the predictive power of the model, Reproducibility and Accuracy explain only 13% of the variance in Perceived Usefulness as 264
indicated by (r2). Figure 63 shows the scatterplot of the REP and MRE values against the Perceived Usefulness scores with the regression line. Phase 3: A regression model for Perceived Ease of Use vs Perceived Usefulness In this phase, we tested H13 to verify if perceived usefulness is determined by perceived ease of use. Thus, Perceived Ease of Use was used as the independent (predictor) variable and Perceived Usefulness as the dependent (predicted) variable. The regression equation resulting from the analysis is: Perceived Usefulness = 2.13 + .47 * Perceived Ease of Use The details of the regression analysis are: R squared (r2) = .46 F-statistic = 15.09 Significance level (p) = .0005 The result of the regression (see Table 61) allows the rejection of the null hypothesis (H13N), meaning that we empirically corroborate that perceived usefulness is determined by perceived ease of use.
Table 61. Simple Regression between PEOU and PU (OOmFP; = .05)
Model Constant Perceived Ease of Use Unstd. Coeff. (b) 2.130 .472 Std. Error .362 .122 .675 Std. Coeff. (Beta) t 5.878 3.884 Sig. .000 .001 95% Confidence Interval for b 1.369 (lower) 2.892 (upper) .217 (lower) .728 (upper) (r)
.675
With regard to statistical significance, the regression equation was found to have very high significance with < .001. This means that H13 was strongly confirmed. The significance of the regression coefficient for Perceived Ease of Use indicates that perceptions in usefulness (H5) are partially determined by perceptions in ease of use (H4). With respect to the predictive power of the model, Perceived Ease of Use explains 46% of the variance in Perceived Usefulness as indicated by (r2). Figure 64 shows the scatterplot of Perceived Ease of Use scores against Perceived Usefulness scores with the regression line. 265
4,50
Perceive d Usefulness
4,00
A A
A A
A A A
3,50
A A
3,00
A A
A A
2,50 2,00 3,00 4,00
Pe rce ived Ease of Use
Figure 64. Scatterplot: Perceived Ease of Use vs. Perceived Usefulness
Phase 4: A regression model for Perceived Ease of Use and Perceived Usefulness Vs. Intention to Use In this phase, we test hypotheses H14 and H15 to verify if Intention to Use (ITU) is determined by Perceived Ease of Use (PEOU) and Perceived Usefulness (PU). To do this, PEOU and PU were used as independent (predictor) variables and ITU as the dependent (predicted) variable. The regression equation resulting from the analysis is: Intention to Use = .71 + 1.13 * Perceived Usefulness - 0,34 * Perceived Ease of Use The details of the regression analysis are: R squared (r2) = .40 F-statistic = 5.6 Significance level (p) = .007 The result of the regression summarized in Table 62 allows us to empirically corroborate that intention to use is determined by perceived ease of use and perceived usefulness. 266
Table 62. Multiple regression between PEOU, PU and ITU (OOmFP; = .05)
Model Constant Perceived Ease of Use Perceived Usefulness Unstd. Coeff. (b) .71 -.34 1.13 Std. Error .934 .249 .355 -.350 .810 Std. Coeff. (Beta) t .765 -1.368 3.166 Sig. .455 .189 .006 95% Confidence Interval for b -1.256 (lower) 2.684 (upper) -.865 (lower) .185 (upper) .573 (lower) .609 (upper) (r)
.315 .609
With regard to statistical significance, the regression coefficient for Perceived Usefulness was found to be highly significant with < .01. This means that H15 was confirmed. This indicates that perceptions in intention to use are partially determined by perceptions in usefulness. The results do not allow the rejection of the H14N since the regression coefficient for Perceived Ease of Use is not significant. Hence, we found no support for the hypothesized causal relationship between Perceived Ease of Use and Intention to Use. With respect to the predictive power of the model, Perceived Ease of Use and Perceived Usefulness together explain 40% of the variance in Intention to Use as indicated by (r2). Figure 65 shows the 3D scatterplot of Intention to Use scores against Perceived Ease of Use and Perceived Usefulness scores. In fact, we agree that there are other factors that affect the decision of people in using a given technology (i.e., FSM method). Bailey and Pearson identified 39 factors that can influence user satisfaction [176]. In our case, other factors that could influence the decision of people to use a FSM method are technology infrastructure adoption, government decisions, standardization, etc. However, as pointed out by Cheney et al. [177] there are uncontrollable factors (i.e., organizational time frame), partially controllable factors (i.e., systems development backlog) and fully controllable factors (i.e., end-user computing). Our objective here was select variables that can be controlled such as the behaviour of people using the method. We considered perceived ease of use and perceived usefulness due to the fact that these are the most important factors in explaining system use. The objective was to provide a base for tracing the impact of external variables (measurement time, reproducibility, and accuracy) on internal beliefs, attitudes, and intentions.
267
A A
A A A A
A A A A A A A
A A A A A
Figure 65. Scatterplot: Intention to Use vs. Perceived Ease of Use and Perceived Usefulness
However, we are aware that it is necessary to replicate this experiment and to carry out new ones that consider other factors in order to draw definite conclusions. For instance, in [137], factors such as voluntariness, compatibility and perceived behavior are used to explain software developer acceptance of methodologies.
8.6
Discussion
With respect to the comparison between methods (Research Questions 1 and 2), Figure 66 shows all the significant differences found between OOmFP and IFPUG FPA. The labels on the arrows show the variables for which significant differences were found, while the arrowheads show the direction in which the difference was found (from superior to inferior). As observed in Figure 66, only H1 was not confirmed. As mentioned above, the subjects spent more time to apply the OOmFP measurement rules than the IFPUG measurement rules. However, this problem can be solved by providing tool support for measurement rules application. OOmFP has now been automated in a tool called OlivaNova Function Point Counter [178] that 268
automatically obtain the functional size of OO systems from OO-Method conceptual schemas.
H1: Measurement Time (p= 0,0015)
IFPUG FPA
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)
OOmFP
Figure 66. Comparison between methods results
Note that the significantly higher perceived ease of use of OOmFP is somewhat unexpected as OOmFP took on the average more time to apply than IFPUG FPA. Probably other factors than measurement time impacted the subjects perceptions of ease of use. This is an issue that we need to address in future research. It should also be noted that even if OOmFP is perceived to have better performance 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 acceptance in practice of OOmFP. The results summarized in Table 63 show that only H7 was not confirmed. The statistical significance was found to be very high ( < .001) for H8 and H9. Moreover, we made an analysis of the construct validity and reliability of the instrument used to measure the perception-based variables. In the construct validity analysis, we found an invalid question (Q11) that was excluded from the analysis. In the reliability analysis, all questions (except Q11) were found to be reliable and valid (Cronbachs 7) measures of the underlying constructs in the proposed theoretical model.
Table 63. OOmFP acceptance analysis results
Construct H7: Perceived Ease of Use H8: Perceived Usefulness H9: Intention to Use Significance (p) .266 .000 .000 Confirmed? NO YES YES
However, these analyses also revealed that the majority of questions that measure a given construct have high correlations with questions that measure other constructs (i.e., divergent validity is high). For future experiments, we 269
need to be careful in the definition of the questions to measure these constructs. In addition, the reliability analysis reveals that Q12 is more related to PEOU than ITU. With regard to the validation of the MAM (Research Question 4), Table 64 summarizes the results of the regression analysis in terms of statistical significance (p). With the exception of Actual Effectiveness Perceived Usefulness relationship and Perceived Ease of Use Intention to Use, all the relationships were confirmed. The statistical significance was found to be very high ( < .001) for H10 and H13, and medium ( < .05) for H14 and H15.
Table 64. Regression analysis results
Relationship H10: Actual Efficiency Perceived Ease of Use H11 and H12: Actual Effectiveness Perceived Usefulness H13: Perceived Ease of Use Perceived Usefulness H14: Perceived Ease of Use Intention to Use H15: Perceived Usefulness Intention to Use Significance (p) .000 .315 .001 .094 .003 Confirmed? YES NO YES NO YES
Figure 67 shows the results of the regression analysis in diagrammatical form. The relationship between Actual Effectiveness and Perceived Usefulness was found to be not significant. The Method Adoption Model was therefore partially validated by the regression analysis.
Actual Efficiency
b= -0,83 p= 0,000
b= -0,34 p= 0,094
b= 2,13 p= 0,001
Intention to Use
Actual Usage
Not Significant
b= 1,13 p= 0,003
Figure 67. Validation of theoretical model
270
8.6.1 Summary of findings

The results for each research question are: Research Question 1: Out of three hypotheses, two were supported. OOmFP was found to be superior to IFPUG FPA in actual effectiveness as measured in terms of the reproducibility and accuracy of the functional size measurements. Research Question 2: All three hypotheses were supported. The results show that OOmFP is perceived to be easier to use, more useful and more likely to be adopted in practice than IFPUG FPA. The results for perceived usefulness and intention to use suggest that participants perceived OOmFP to be a significant improvement on IFPUG FPA for measuring OO systems developed using the OOMethod approach. Research Question 3: Out of three hypotheses, two were supported. The results show that OOmFP is perceived to be useful and is likely to be adopted in practice. However, the result for perceived ease of use was not statistically significant. Research Question 4: Three hypotheses were supported and two were not supported. The results show that the Method Adoption Model is a partially reliable and valid instrument for evaluating FSM methods. The relationships between Actual Effectiveness and Perceived Usefulness and between Perceived Ease of Use and Intention to Use were not found to be significant.
8.6.2 Model revision

It is common practice to drop any variable or relationship from the model that is found to be not significant [172]. This means that the relationships between Actual Effectiveness and Perceived Usefulness, and between Perceived Ease of Use and Intention to Use should be removed from the model. The model then becomes a three-stage simple regression model. A regression analysis was carried out using Perceived Usefulness as the independent variable and Intention to Use as the dependent variable (i.e. removing Perceived Ease of Use from Phase 4 of the analysis). The regression equation which results is: 271
Intention to Use = .88 * Perceived Usefulness + .80 The scatterplot of Perceived Usefulness against Intention to Use is shown below, with regression line, 95% confidence intervals:
5,00
A A
Intention to Use OOmFP
A A
A A
4,00
A A A A A
A A A
3,00
3,00
3,50
4,00
4,50
Pe rce ived Use fulne ss OOmFP
Figure 68. Scatterplot: Perceived Usefulness vs Intention to Use
The details of the regression are: R squared (r2) = .33 F statistic = 8.8 Significance level (p) = .004 The result of the regression (see Table 65) allows us to empirically corroborate that intention to use is determined by perceived usefulness.
Table 65. Simple regression between PU and ITU (OOmFP; = 0.05)
Model Constant Perceived Usefulness Unstd. Coeff. (b) .877 .797 Std. Error .948 .268 .573 Std. Coeff. (Beta) t .925 2.969 Sig. .367 .008 95% Confidence Interval for B -1.11 (lower) 2.86 (upper) .233 (lower) 1.36 (upper) (r)
.573
272
The major advantage of removing Perceived Ease of Use is that it simplifies the model, and all relationships are now highly significant ( < .01). The revised model is shown in Figure 69.
b= -0,83 p= 0,000 b= 1,13 p= 0,003 b= 0,88 p= 0,004
Actual Efficiency
Intention to Use
Figure 69. Validation of revised theoretical model
However, we argue against removing the link between Perceived Ease of Use and Intention to Use for two reasons. First, as discussed earlier, there is strong evidence that the relationship between Perceived Ease of Use and Intention to Use is a contingent relationship. Such relationships cannot be easily analyzed using linear regression techniques. Second, the participants in this experiment (students) are different to the target population (practitioners). Practitioners may use different decision-making processes than novices to make decisions about whether to use a method or not (this is investigated in [70]).
8.6.3 Validity evaluation

In this section, we discuss several issues that can affect the validity of the empirical study and how we attempted to alleviate them. 8.6.3.1 Threats to conclusion validity
In order to control the risk that the variation due to individual differences is larger than due to the treatment, we selected a homogeneous group of subjects. Another risk in the experiment implementation is that the subjects were trained one day and the experiment was run the next day. Thus, they might inform each other about the other method. However, we believe that the risk of this is low. 273
Another issue that could affect the validity of this experiment is the time spent in the training session with IFPUG FPA. We are aware that in a practical environment more time is required to apply the FPA measurement rules in a consistent way. However, due to time constraints (the experiment was conducted on-line as part of a course), we decided to use a guideline that summarizes the measurement rules of the method (see Appendix A) instead of using the official IFPUG FPA Counting Practices Manual, which is more time-consuming. Using this guideline, the students sized a case study before to do the experimental tasks. We also allowed the students to use all the training materials when performing the experimental task. We are also aware that a total training of eight hours is not sufficient to turn students into expert users of the FSM methods. On the other hand, the main objective of the training was to enable a fair comparison between both FSM methods. So for our experiment, more important than the intensity and duration of the training was that the training was the same for both methods. Nevertheless, we plan to replicate this experiment in a near future in order to verify whether this issue might have some impact on the interpretation of the experiment results. 8.6.3.2 Threats to construct validity
The performance-based dependent variables we used are criteria proposed in the ISO/IEC 14143-3 [21]. The perception-based dependent variables were measured according to subject ratings, using a measurement instrument based on the literature. Moreover, we evaluated the construct validity and the reliability of this measurement instrument. 8.6.3.3 Threats to internal validity
We informed the students that their grade on the course was not affected by their performance in the experiment, but only by their attendance. The following issues were also considered: Differences among subjects. Using a within-subjects design, error variance due to differences among subjects was reduced. In addition, we used the counterbalancing procedure where subjects were randomly assigned in two groups. This procedure cancels out a possible learning effect (due to similarities in the treatments) and a
274
confounding effect (due to the order in which the methods were learned or applied). Knowledge of the universe of discourse. We used the same requirement specification document for all subjects. It specifies the requirements of a Project Management System for a fictitious company. This is a known universe of discourse. Fatigue effects. On average, each subject took three hours per session to solve the experimental tests. We ran separate sessions for each treatment group in the same day. The section was run in parallel, so fatigue was not very relevant. Persistence effects. In order to avoid persistence effects, the experiment was carried out by subjects who had never done a similar experiment. Subject motivation. We motivated students in the last year in the Computer Science area to participate in the experiments by explaining to them that functional size measurement is a topic used in practice by companies for developing early project indicators. Threats to external validity
8.6.3.4
The greater the external validity, the more the results of an empirical study can be generalized. Three threats which limit the ability to apply any such generalization were identified: Materials and tasks used. We tried to use a representative requirement specification of a real case in the MIS functional domain23. However, more empirical studies are needed using other user requirement specifications within this functional domain. Subjects. We are aware that experiments with practitioners must be carried out in order to be able to generalize these results. OO-Method approach. We used a functional size measurement method for object-oriented systems that follows the OO-Method concepts. Therefore, in order to generalize the results obtained in the context of OO-Method to OO systems measured using other
Defined in ISO/IEC 14143-1 as a class of software that is based on the characteristics of Functional User Requirements.
23
275
approaches, we need to include the evaluation of convertibility criteria defined in [21] in future experiments.
8.7
Conclusions
This chapter has described a laboratory experiment which compares IFPUG FPA and OOmFP. The goal was to investigate which method has the highest performance and/or likely adoption in practice for sizing OO system within the context of an OO-Method development process. The important results from the experiment are: Effectiveness: we have corroborated that within its context, OOmFP produces more consistent and accurate assessments than IFPUG FPA. Acceptance: The results show that the likely acceptance of OOmFP is higher than that of IFPUG FPA. However, perceived ease of use needs to be revised. The results allow a partial validation of the Method Adoption Model in terms of the validity and reliability of the measurement instrument. Validation of the theoretical model: as discussed in previous section part of the MAM was validated.
Despite the initial experiment validity, we are aware that more experimentation is needed in order to reconfirm these results. Several threats to the validity of this study have been identified. Specifically, these are the choice of experimental objects (which is limited to a unique requirements specification) and the time spent in the training of IFPUG FPA. In a future replication of this experiment, we will address these issues to verify a possible impact on the interpretation of the results. The greatest threat to the generalizability of the findings of this study was the use of students as experimental subjects. We are planning a new experiment using practitioners in the context of the Spanish Association of Software Metrics. The findings are positive in terms of future revisions of the proposed theoretical model. This is the first study to empirically evaluate the suitability of IFPUG FPA for measuring the functional size of OO systems and the first to test theoretical models (i.e., MAM and TAM) in the context of FSM 276
methods. This research contributes to the creation of a body of knowledge needed in Software Engineering by establishing the foundation of theories. Further work includes the replication of the experiment using practitioners, the measurement of other criteria such as the convertibility of FSM methods and finally, the improvement of the proposed theoretical model (i.e., increasing exploratory power).
277
Chapter 9
Experiment 2: Evaluating the Performance and Acceptance of OOmFPWeb

This chapter describes a laboratory experiment which evaluates the efficiency, effectiveness, and likely adoption in practice of OOmFPWeb for sizing Web applications developed using the OOWS approach. Such an evaluation is conducted by comparing OOmFPWeb to the current industry practices.
9.1
Experiment design
In order to design the experiment, we used the framework for experimental software engineering of Wohlin et al. [72]. In terms of the Goal/Question/Metric (GQM) template [74], the goal of the experiment is to analyze functional size measurements for the purpose of evaluating OOmFPWeb with respect to its performance and likely adoption in practice from the point of view of the researcher. The context of the experiment was an OOWS conceptual schema of a Web application that is measured by PhD students in the Department of Computer Science at the Valencia University of Technology. The broad research questions addressed by this experiment are: RQ1: Is OOmFPWeb efficacious? RQ2: Is OOmFPWeb likely to be adopted in practice?
Chapter 9. Evaluating the Performance and Acceptance of OOmFPWeb
RQ3: Is MAM a valid theoretical model for evaluating OOmFPWeb?
9.2
Planning
9.2.1 Selection of subjects

The subjects that participated in this study were fifteen students in the PhD Program in Software Engineering at the Valencia University of Technology. The students were between 24 and 28 years old and had similar backgrounds in the use of the OOWS approach. The subjects were chosen for convenience, i.e., they were students enrolled in the Software Engineering for Web Environments course during the period from March until July of 2003. The course included the topic of functional size measurement of Web applications. This course was selected because it was a specialized teaching unit (where students learn advanced techniques about Web development). Furthermore, the necessary preparation and training and the experimental task itself fitted in well with the scope of this course. The experiment was therefore organized as a mandatory part of the course.
9.2.2 Variable selection

Evaluating the actual performance of a method requires the measurement of the effort required (inputs) and the quality of the results (outputs). Hence, we distinguish between two performance-based variables: efficiency and effectiveness: Effectiveness can be further refined as the reproducibility of measurements. Reproducibility is defined as the agreement between the measurements of a same system, taken at different points in time or by different people. The reproducibility of measurements determines the reliability of the measurement method, i.e., the trust that people can have in the measurement results. To evaluate effectiveness, the proposed evaluation model for FSM methods also considers the accuracy of measurements. Accuracy is defined as the agreement between the measurement value and its true value. The 280
evaluation of accuracy assumes that there is another, supposedly right way of finding the true value of functional size. Such an evaluation makes sense if an alternative method is proposed that aims to improve the efficiency or other performance properties (e.g., reproducibility) of an existing and validated FSM method, or if the new method is more likely to be accepted in practice. However, in our case, no method exists to measure the functional size of Web applications based on their conceptual models. Therefore, there is no independent way of obtaining the true value of functional size. Hence, in this experiment, effectiveness is operationalized as the reproducibility of measurements, not their accuracy. To further operationalize the performance-based variable efficiency and effectiveness (or consistency) we used: Productivity: the productivity of a subject to measure an OOWS conceptual schema using OOmFPWeb. Reproducibility: the agreement between the measurement results of different subjects using OOmFPWeb (for the same system).
To evaluate the perceived performance and intention to use OOmFPWeb, we selected the three perception-based variables of the MAM (or TAM): Perceived Ease of Use: the degree to which a subject believes that using OOmFPWeb would be free of effort. Perceived Usefulness: the degree to which a subject believes that OOmFPWeb will be effective in achieving its intended objectives. Intention to Use: the degree to which an individual intends to use OOmFPWeb as a result of his/her perception of the methods performance.
9.2.3 Experimental tasks

This experiment includes two tasks: a measurement task and a post-task survey. In the measurement task, each subject used the OOmFPWeb measurement rules for measuring an OOWS conceptual schema. This task was used to collect data for evaluating the performance-based variables. Next, in the post-task survey task, students were asked to complete a survey for evaluating OOmFPWeb. The survey is a measurement instrument to collect data for evaluating the perception-based variables. 281
9.2.4 Instrumentation
The instrumentation used in this experiment includes the experimental object, training materials and the survey instrument. The experimental object was an OOWS conceptual schema of an e-commerce application for a Photography Agency. Part of the requirements for this application are described below. The Photography Agency works with photographers who deliver features. These features can be bought by Press Agencies. Occasionally, a Press Agency asks for exclusive features in topics that are not covered by the Agency. Each exclusive feature is assigned to just one photographer and he/she is supposed to finish it in order to be assigned to another exclusive feature. The application must be used by four kinds of users: administrators, anonymous users and registered users (photographer and Press Agency). The complete requirements specification for the Photography Agency is provided in Appendix A. The following training materials were prepared for all subjects: a set of instructional slides describing OOmFPWeb and the procedure for applying it; a case-study that describes an example application of OOmFPWeb; and a measurement guideline summarizing the measurement rules of the method. The survey instrument included 14 closed questions (i.e. survey items), which were based on the items used to measure the constructs of the Method Adoption Model [70] (which itself adapted the items normally used to measure the constructs of the Technology Acceptance Model [140]). The items we used were formulated using a 5-point Likert scale, using the opposing statements question format. This survey is shown in Appendix B. The order of the items was randomized and half the questions negated to avoid monotonous responses. Perceived Ease of Use is measured using 5 items on the survey (Questions 1, 3, 4, 6, and 9). Perceived Usefulness is measured using 6 items on the survey (Questions 2, 5, 8, 10, 11, and 13). Finally, Intention to Use is measured using 3 items on the survey (Questions 7, 12, 14).
9.2.5 Hypothesis formulation

To evaluate whether OOmFPWeb is efficient, effective, and likely to be adopted in practice, we tested a number of hypotheses. Figure 70 shows the 282
operationalization of the theoretical evaluation model for FSM methods used in this experiment. As there is currently no other method for measuring the functional size of Web applications based on a problem-space representation, we cannot evaluate OOmFPWeb against a control method. Hence, the independent variable has only one value (i.e. using OOmFPWeb). Instead of using a control group (as in a between-subjects experiment) or letting each subject be its own control (as in a within-subject experiment), we decided to evaluate the performance-based variables in a qualitative way by comparing the data collected for OOmFPWeb against similar performance data reported in industry or in other empirical studies. To evaluate the perception-based variables, a more quantitative analysis could be used as the measurement instrument itself provides a reference point to assess the significance of the results.
PRODUCTIVI TY(D1)
H1
REPRODUCIBI LITY(D2)
H6
H2
Independent (predictor) variable
FSM METHOD (I)
H3
PERCEIVED EASE OF USE (D3)
H7
Dependent (outcome) variables
H4 H5
H8
PERCEIVED USEFULNESS (D4)
H9
H10
INTENTION TO USE (D5)
Figure 70. Theoretical Model (Second Experiment)
283
Research Question 1: Evaluating the Performance of OOmFPWeb Hypothesis 1: This hypothesis tests the relationship between the independent variable (OOmFPWeb) and Productivity (D1). OOmFPWeb is efficient when compared to current industry practices.
In this experiment, efficiency is evaluated by comparing the measurement productivity of subjects using OOmFPWeb against reported industry averages. Since the time required to apply the procedures and rules of a measurement method depends on the size of the application measured, we cannot directly compare the recorded measurement times with industry findings. Therefore, the evaluation is made by comparing the measurement productivity of subjects using OOmFPWeb against reported industry averages. Measurement productivity is defined in this context as the number of Function Points that can be counted per unit of time (e.g. per day). We are aware that the productivity of people in sizing a specification or application can vary considerably, even when using the same FSM method. It depends on many factors such as experience, the quality of the specifications, the use of tools, etc. Notwithstanding these limitations, a comparison of the measurement productivity observed in the experiment with what is considered as being normal in industry gives us some basis to assess the performance of people using OOmFPWeb. Hypothesis 2: This hypothesis tests the relationship between the independent variable (OOmFPWeb) and Reproducibility (D2). OOmFPWeb is effective when compared to similar studies reported in the literature. We evaluate the effectiveness of OOmFPWeb in terms of reproducibility. To do this, the measurement assessments obtained by the subjects is compared to similar studies reported in the literature. Research Question 2: Evaluating the Likely Adoption in Practice of OOmFPWeb Hypothesis 3: This hypothesis tests the relationship between the independent variable (OOmFPWeb) and Perceived Ease of Use (D3). 284
OOmFPWeb is perceived as easy to use.
Hypothesis 4: This hypothesis tests the relationship between the independent variable (OOmFPWeb) and Perceived Usefulness (D4). OOmFPWeb is perceived as useful. Hypothesis 5: This hypothesis tests the relationship between the independent variable (OOmFPWeb) and Intention to Use (D5). There is an intention to use OOmFPWeb. These hypotheses relate to a direct relationship between the use of OOmFPWeb and the users performance, perceptions and intentions. Research Question 3: Evaluating the MAM The theoretical model contains a number of other hypothesized relationships that indicate causal links between dependent variables (like performance having an effect on perceptions or perceptions influencing intentions). The purpose of these hypotheses is to test the predictive and explanatory power of the model. These hypothesized causal relationships are as follows: Hypothesis 6: Productivity is a performance-based measure of efficiency, whereas Perceived Ease of Use is a perception-based measure of efficiency. According to the Method Evaluation Model [70], perceptions of efficiency are determined by actual efficiency. Null hypothesis, H6N: Perceived Ease of Use is not determined by Productivity. Alternative hypothesis, H6A: Perceived Ease of Use is determined by Productivity. Hypothesis 7: Reproducibility is a performance-based measure of effectiveness, whereas Perceived Usefulness is a perception-based measure of effectiveness. According to the Method Evaluation Model [70], perceptions of efficiency are determined by actual effectiveness. Null hypothesis, H7N: Perceived Usefulness is not determined by Reproducibility. Alternative hypothesis, H7A: Perceived Usefulness is determined by Reproducibility. 285
Hypothesis 8: This is one of the causal relationships defined in the Method Evaluation Model and based on the Technology Acceptance Model [140]. Null hypothesis, H8N: Perceived Usefulness is not determined by Perceived Ease of Use. Alternative hypothesis, H8A: Perceived Usefulness is determined by Perceived Ease of Use. Hypothesis 9: This is one of the causal relationships defined in the Method Evaluation Model and based on the Technology Acceptance Model [140]. Null hypothesis, H9N: Intention to Use is not determined by Perceived Ease of Use. Alternative hypothesis, H9A: Intention to Use is determined by Perceived Ease of Use. Hypothesis 10: This is one of the causal relationships defined in the Method Evaluation Model and based on the Technology Acceptance Model [140]. Null hypothesis, H10N: Intention to Use is not determined by Perceived Usefulness. Alternative hypothesis, H10A: Intention to Use is determined by Perceived Usefulness.
9.3
Experiment operation
9.3.1 Execution
The experiment took place in a single room. It was ensured that no interaction among subjects occurred. To avoid a possible ceiling effect, there was no time limit to size the OOWS conceptual schema. We also allowed the use of the material used in the training session. After they finished the measurement task, the subjects were asked to perform the post-task survey.
9.3.2 Data recording and validation

The performance-based dependent variables were measured using a data collection form. This form records the outputs of the OOmFPWeb functional 286
size measurement (called subject assessment using Function Points as the measurement unit) and the time spent to measure the size of the OOWS conceptual schema. We called this time measurement time, expressed in hours. Once the data were collected, we verified whether the tests were complete. As all tests had been completed, we took into account the responses of all subjects.
9.4
Analysis and interpretation
The presentation of the analysis and interpretation of the results is divided into three parts according to the research questions (and the distinction between performance-based and perception-based variables). As in the previous experiment, we consider the following levels of significance: Not significant: > .1 Low significance: < .1 Medium significance: < .05 High significance: < .01 Very high significance: < .001
9.4.1 Analysis of the actual performance of OOmFPWeb

We first evaluate the efficiency of OOmFPWeb in terms of measurement productivity. According to reported industry experience,24 we can expect counting rates of 300 Function Points per day (FP/day) by first-time counters with one days training. The IBM stated counting rate is 800 FP/day with one week of counting assistance. After two weeks of assisted counting, 1000-1500 FP/day can be measured. As further evidence, the company Total Metrics published different counting levels [179]. According to these levels, the productivity of an estimator can vary between 200-750 FP/day. Considering the performance data reported in industry, we can conclude that the lowest productivity for first-time counters is 200-300 FP/day. As a day is assumed to have 8 working hours, the obtained productivity rate is approximately 25-37.5 FP/hour.
24
http://www.functionpoints.com/faq.asp#a14
287
In this experiment, we adopted 37.5 FP/hour as the benchmark industry rate for the productivity of not so experienced function point counters. To calculate the measurement productivity of a subject, we divided the subject assessment by the measurement time.25 The obtained productivity rate for each subject measuring the experimental object is presented in Appendix C. As can be seen in Table 66, the mean measurement productivity that was observed (108.79 FP/hour) is about three times the size of the benchmark. Although the experiment provides some empirical evidence of the efficiency of using OOmFPWeb, it must be noted that the industry values that are reported are not specific to Web application projects. Thus, even though the results look promising, we cannot draw definite conclusions about the measurement productivity obtained with OOmFPWeb.
Table 66. Descriptive statistics for productivity and reproducibility
Productivity Num. of observations Minimum Maximum Mean Standard deviation Productivity 15 85.50 140.00 108.79 18.52 Reproducibility 15 .01 .19 .06 .04
Next, we evaluate the effectiveness of OOmFPWeb in terms of reproducibility. The effectiveness of a FSM method depends amongst other factors on the inter-rater reliability of the measurements [167]. We postulate that the closer the measurements obtained by different raters, the more effective the FSM method is. Some studies in the literature address the inter-rater reliability question. In a first study reported by Rudolph [180], twenty subjects calculated the Function Point value for a system based on its requirements specification. Values within the range of +/- 30% of the average Function Point value were observed. In a related study by Low and Jeffery [18], the functional size assessments produced by twenty-two practitioners in seven Australian organizations were compared to those obtained by twenty inexperienced raters. Low and Jeffery measured the consistency of the Function Point counts as the standard deviation divided by the mean. The inter-rater reliability for
25
It is of course better to use the true value of the functional size of the experimental object as the output measure in the productivity ratio. As discussed above, it was impossible to establish this true value. Therefore, the true value is approximated by the subject assessment.
288
both groups was about the same (about 45%), but the differences between the two groups were larger. The results obtained by Low and Jeffery are worse than those reported by Rudolph if the range of the Function Point counts is considered (counts that differed by a factor of four were observed). Moreover, in Low and Jefferys study, program-level specifications were measured (i.e. program flowcharts), whereas in Rudolphs study [180], measurement was applied to requirementlevel specifications. Also, Kemerer [167] reported a study that addressed the inter-rater and inter-method Desharnais questions. In this study, twenty-seven actual applications were sized using two FSM methods: the FPA method proposed by IFPUG [14] and the ER method proposed by Desharnais [181]. Each system was independently sized by four practitioners (two of them using the IFPUG method and the other two using the ER method). The mean pairwise inter-rater reliability obtained using the IFPUG method was 26.53%, whereas the mean value obtained for the ER method was 20.66%. In addition, an inter-rater error for the ER method that was almost twice that of the IFPUG method was observed. The explanations made by authors were that the subjects had no experience with ER modeling, and that this view on functional size normally appears in the requirements analysis documentation and not in the detailed design documentation that was used in the experiment. Perhaps the experimental objects used did not included ER diagrams. In order to measure the degree of variation between assessments produced by different subjects using OOmFPWeb, we used a practical statistic similar to that proposed by Kemerer [167]. This statistic is calculated as the difference in absolute value between the count produced by a subject and the average count (for the same FSM method) produced by the other subjects in the sample, relative to this average count. Reproducibility measurements (REP) were thus obtained for each observation by applying the following equation:
REPi = Average Other assessments Subject Assessmenti Average Other Assessments
The REPi obtained for each observation are presented in Appendix C. Table 66 shows descriptive statistics for reproducibility. Compared to the results reported by Kemerer [167], the consistency of measurements was high (mean REPi was 6%). The variation around the mean subject assessment (i.e. 289
range of values divided by mean value) was 24.5%, which compares well with Rudolphs study [180]. Finally, the standard deviation divided by the mean was as low as 7.2%, which is a fraction of what was reported by Low and Jeffery [18]. All these results are indications of the reproducibility of measurements using OOmFPWeb. One possible explanation could be that the subjects were familiar with the OOWS approach, used to produce the experimental object.
9.4.2 Analysis of the perceived performance and likelihood of adoption of the OOmFPWeb
The objective of this section is to evaluate the likely acceptance in practice of OOmFPWeb for sizing Web applications (Research Question 2). To do this we tested hypotheses H3, H4, and H5 related to the perceived ease of use, perceived usefulness and intention to use OOmFPWeb. These hypotheses can be formally tested by verifying whether the scores that students assign to the constructs of the MAM are significantly better than the middle score (i.e. score 3) on the Likert scale for an item. If a subject indicated this middle score, then his/her perception was neutral, meaning for instance that the method was not perceived as easy or difficult to use. If a subjects rating of an item was significantly better than the middle (i.e. neutral) score, then some evidence for the perceived quality of the method is found. Table 67 shows the first question of the survey instrument. This is one of the questions used to measure Perceived Ease of Use.
Table 67. Excerpt of the survey instrument
I found the procedure I found the procedure for for applying the FSM applying the FSM method O O O O O method simple and easy complex and difficult to to follow follow
As a first step, the scores of a subject are averaged over the items that are relevant for a construct. This way, we obtain three scores for each subject (see Appendix C). These scores can then be compared against the value 3. We first tested hypothesis H3 related to Perceived Ease of Use (PEOU). The descriptive statistics are presented in Table 68.
290
Table 68. Descriptive statistics for PEOU, PU and ITU

Descriptive Statistics Number of observations Minimum Maximum Mean Standard deviation PEOU 15 3.00 5.00 3.86 0.58 PU 15 2.20 4.60 3.80 .67 ITU 15 1.67 5.00 3.73 1.01
The Kolmogorov-Smirnov test for normality was applied to the PEOU data. As this distribution was normal, we used the one-tailed sample t-test26 to check for a difference in mean PEOU for OOmFPWeb and the value 3. To evaluate the significance of the observed difference, we applied a statistical test with a significance level of 5 %, i.e. alpha = 0.05. The results in Table 69 allow for the rejection of the null hypothesis, meaning that we empirically corroborated that participants perceived OOmFPWeb to be easy to use. Next, we tested hypothesis H4 related to Perceived Usefulness (PU). The descriptive statistics for PU are presented in Table 68. The KolmogorovSmirnov test for normality was applied to the PU observations. As this distribution was also normal, we again used the One-tailed sample t-test to check for a difference in the mean PU score and the value 3.
Table 69. 1-tailed One sample t-test rank for differences in mean PEOU
Perceived Ease of Use Mean 3.866 Std. Deviation .583 Std. error mean .150 95% confidence interval .5433 (lower) of the difference 1.1900 (upper) t 5.748 1-tailed p-value .000
Using a significance level of 5 %, the results of the test (Table 70) allow for the rejection of the null hypothesis. Hence, participants perceived OOmFPWeb as being useful.
The Likert scales used for PEOU, PU and ITU are meant to approximate interval scales. Given the robustness of the parametric techniques (e.g. t-tests) to non-linear distortions of interval scales [127], we decided to use them instead of the less powerful non-parametric alternatives.
26
291
Table 70. 1-tailed One sample t-test rank for differences in mean PU
Perceived Usefulness Mean 3.800 Std. deviation .671 Std. error mean .173 95% confidence interval of .429 (lower) the difference 1.172 (upper) t 4.611 1-tailed p-value .000
Finally, we tested hypothesis H5 related to the Intention to Use (ITU) OOmFPWeb. The descriptive statistics for intention to use are presented in Table 68. The same procedure as before was used to test this hypothesis. The Kolmogorov-Smirnov test for normality showed a normal distribution. The result of the One-tailed sample t-test for ITU (Table 71) allows for the rejection of the null hypothesis, meaning that we empirically corroborated that participants intend to use OOmFWeb. Although the statistical significance of the results was very high ( < 0.001) for H3 and H4, and high ( < 0.01) for H5, it is necessary to validate the survey items used to measure the constructs of the MAM before any definite conclusions can be drawn. An analysis of the construct validity and reliability of the survey instrument is presented in the next subsection.
Table 71. 1-tailed One Sample t-test rank for differences in mean ITU
Intention to Use Mean 3.73 Std. deviation 1.017 Std. error mean .262 95% conf. interval of the .1733 (lower) difference 1.2996 (upper) t 2.792 1-tailed p-value .007
292
9.4.3 Validating the validity and reliability of the MAM constructs

In order to evaluate the validity of the MAM constructs, an inter-item correlation analysis was carried out. We assumed that all items associated with a particular construct have equal weights. Specifically, we used the concepts of convergent and discriminant validity proposed by Campbell and Fiske [173]. Convergent validity (CV) refers to the convergence among different indicators used to measure a particular construct.The CV of an indicator is measured by the average correlation between the indicator and the other indicators that are used to measure the same construct. This average correlation should be as high as possible. Discriminant validity (DV) refers to the divergence of indicators used to measure different constructs. The DV of an indicator is measured by the average correlation between the indicator and the indicators that are used to measure a different construct. This average correlation should be as low as possible. The results of the validity analysis for each construct (see Table 72) are:
Perceived Ease of Use (PEOU): the average CV of all items was .45. Overall, CV was almost twice the size of DV. Perceived Usefulness (PU): the average CV across all indicators was .44. Overall, CV was greater than the size of DV. Intention to Use (ITU): The average CV across all indicators was .72. Overall, CV was twice the size of DV.
The problem that emerged from the analysis was the low level of convergent validity for the item Q10 (intended to measure Perceived Usefulness). This item has a value for DV that is greater than its value for CV. For this reason, Q10 was excluded from the analysis. Correlation between survey items after Q10 was removed is presented in Table 73.
293
Table 72. Correlation between survey items (construct validity analysis)

Perceived Ease of Use Q1 Q3 Q4 Q6 Q9 1.00 0.73 0.39 0.30 0.62 0.73 1.00 0.23 0.00 0.57 0.39 0.23 1.00 0.23 0.12 0.30 0.00 0.23 1.00 -0.11 0.62 0.57 0.12 -0.11 1.00 0.12 0.21 0.15 -0.30 0.37 0.36 0.12 -0.32 0.26 0.50 0.29 -0.05 -0.26 0.18 0.14 0.67 0.65 0.07 0.24 0.55 0.56 0.34 0.07 0.22 0.45 0.72 0.33 0.36 0.42 0.56 0.44 0.47 0.40 0.26 0.00 0.75 0.49 0.43 0.44 0.59 Perceived Usefulness Q2 Q5 Q8 Q10 Q11 0.12 0.36 0.29 0.67 0.56 0.21 0.12 -0.05 0.65 0.34 0.15 -0.32 -0.26 0.07 0.07 -0.30 0.26 0.18 0.24 0.22 0.37 0.50 0.14 0.55 0.45 1.00 0.13 -0.31 0.24 0.42 0.13 1.00 0.60 0.32 0.63 -0.31 0.60 1.00 0.03 0.40 0.24 0.32 0.03 1.00 0.28 0.42 0.63 0.40 0.28 1.00 0.36 0.46 0.29 0.68 0.69 -0.15 -0.11 0.02 0.38 0.23 0.37 0.43 0.23 0.70 0.72 Intention to Use Q7 Q12 Q13 0.72 0.44 0.75 0.33 0.47 0.49 0.36 0.40 0.43 0.42 0.26 0.44 0.56 0.00 0.59 0.36 -0.15 0.37 0.46 -0.11 0.43 0.29 0.02 0.23 0.68 0.38 0.70 0.69 0.23 0.72 1.00 0.36 0.96 0.36 1.00 0.44 0.96 0.44 1.00 CV 0.61 0.51 0.40 0.29 0.44 0.30 0.54 0.34 0.37 0.55 0.77 0.60 0.80 Overall DV VALID? 0.49 YES 0.32 YES 0.11 YES 0.22 YES 0.40 YES 0.14 YES 0.21 YES 0.10 YES 0.49 NO 0.41 YES 0.49 YES 0.19 YES 0.52 YES
PEOU Q1 Q3 Q4 Q6 Q9 PU Q2 Q5 Q8 Q10 Q11 Q7 Q12 Q14
ITU
294
Table 73. Correlation between survey items (after Q10 removed)

Perceived Ease of Use Q1 Q3 Q4 Q6 Q9 1.00 0.73 0.39 0.30 0.62 0.73 1.00 0.23 0.00 0.57 0.39 0.23 1.00 0.23 0.12 0.30 0.00 0.23 1.00 -0.11 0.62 0.57 0.12 -0.11 1.00 0.12 0.21 0.15 -0.30 0.37 0.36 0.12 -0.32 0.26 0.50 0.29 -0.05 -0.26 0.18 0.14 0.56 0.34 0.07 0.22 0.45 0.72 0.33 0.36 0.42 0.56 0.44 0.47 0.40 0.26 0.00 0.75 0.49 0.43 0.44 0.59 Perceived Usefulness Intention to Use Overall Q2 Q5 Q8 Q11 Q7 Q12 Q13 CV DV VALID? 0.12 0.36 0.29 0.56 0.72 0.44 0.75 0.61 0.33 YES 0.21 0.12 -0.05 0.34 0.33 0.47 0.49 0.51 0.16 YES 0.15 -0.32 -0.26 0.07 0.36 0.40 0.43 0.40 -0.09 YES -0.30 0.26 0.18 0.22 0.42 0.26 0.44 0.29 0.09 YES 0.37 0.50 0.14 0.45 0.56 0.00 0.59 0.44 0.37 YES 1.00 0.13 -0.31 0.42 0.36 -0.15 0.37 0.31 0.14 YES 0.13 1.00 0.60 0.63 0.46 -0.11 0.43 0.59 0.21 YES -0.31 0.60 1.00 0.40 0.29 0.02 0.23 0.42 0.10 YES 0.42 0.63 0.40 1.00 0.69 0.23 0.72 0.61 0.41 YES 0.36 0.46 0.29 0.69 1.00 0.36 0.96 0.77 0.47 YES -0.15 -0.11 0.02 0.23 0.36 1.00 0.44 0.60 0.17 YES 0.37 0.43 0.23 0.72 0.96 0.44 1.00 0.80 0.49 YES
PEOU Q1 Q3 Q4 Q6 Q9 PU Q2 Q5 Q8 Q11 ITU Q7 Q12 Q14
295
We also conducted a reliability analysis on the items used to measure the PEOU, PU and ITU variables. The reliability of an instrument describes the consistency (or repeatability) the instrument gives in measuring the same phenomenon over time or by different people. Q10 was excluded for this reliability analysis item. Table 74 shows the results obtained for each construct using Cronbachs alpha, which is the most common measure of scale reliability. These values are all .7 or above as required for constructs to be deemed reliable (as suggested for instance by Nunally [174]).
Table 74. Item reliabilities for constructs
Construct Perceived Ease of Use Perceived Usefulness Intention to use CRONBACHS .70 .75 .80
In addition, the general Cronbach alpha obtained for the instrument was .79. As a result of this analysis, we conclude that the items on the survey (except Q10) are reliable and valid measures of the underlying perceptionbased constructs of the proposed theoretical model.
9.4.4 Validation of the Method Adoption Model

According to the Method Evaluation Model (MEM) there exist a number of hypothesized causal relationships between the dependent variables in our study. The intention of this section is to validate the structural part of the MAM (see Figure 71) in terms of the causal relationships between its constructs and with its external variables, with the exception of Actual Usage. As in the experiment described in Chapter 8, we have chosen regression analysis to evaluate the MAM since the hypotheses to be tested are causal relationships between continuous variables. This evaluation was conducted in four phases using four separate regression analyses taking into account each dependent variable: Phase 1 (simple regression): the effect of Actual Efficiency (independent variable) on Perceived Ease of Use (dependent variable); this is a test of hypothesis H6.
296
Phase 2 (simple regression): the effect of Actual Effectiveness (Reproducibility independent variable) on Perceived Usefulness (dependent variable); this is a test of hypothesis H7. Phase 3 (simple regression): the effect of Perceived Ease of Use (independent variable) on Perceived Usefulness (dependent variable); this is a test of H8. Phase 4 (multiple regression): the effect of Perceived Ease of Use and Perceived Usefulness (independent variables) on Intention to Use (dependent variable); this is a test of H9 and H10.
METHOD ADOPTION
Actual Efficiency Perceived Ease of Use
H6
H9 H8
Intention to Use
Actual Usage
H10
H7
Figure 71. Relationships between Dependent Constructs (adapted from Moody, 2001)
Phase 1: A regression model for Actual Efficiency vs Perceived Ease of Use In this phase, we test hypothesis H6 to verify if perceptions of efficiency are determined by actual efficiency. In order to do this, Actual Efficiency (in terms of productivity) was used as the independent (predictor) variable and Perceived Ease of Use as the dependent (predicted) variable. The regression equation resulting from the analysis is: Perceived Ease of Use = 3.54 + .17 * Productivity The details of the regression analysis are: R squared (r2) = .01 F-statistic = .115 Significance level (p) = .740 297
The result of the regression (see Table 75) does not allow the rejection of the null hypothesis (H6N), meaning that we cannot empirically corroborate that perceived of use is determined by measurement time.
Table 75. Simple regression between Perceived Ease of Use and Measurement Time (OOmFPWeb; = .05)
Model Constant Productivity Unstd. Coef. (b) 3.539 .167 Std. Error .981 .494 Std. Coeff. (Beta) t 3.609 .093 .339 Sig. .003 .740 95% Confidence Interval for b 1.420 (lower) 5.657 (upper) -.900 (lower) 1,235 (upper)
With regard to the statistical significance, the regression equation was found to be not significant with > .1. This means that H6 was not confirmed. Figure 72 shows the scatterplot for Productivity against Perceived Ease of Use scores with the regression line.
5,00
A
4,50
A A A A
4,00
3,50
A
3,00
A A
1,60
1,80
2,00
2,20
Measurement Time Productivity
Figure 72. Scatterplot: Productivity vs Perceived Ease of Use
298
Phase 2: A regression model for Actual Effectiveness vs Perceived Usefulness In this phase, we tested hypotheses H7 to verify if Perceived Usefulness (PU) is determined by Reproducibility. To do this, reproducibility was used as an independent (predictor) variable and PU as the dependent (predicted) variable. The regression equation resulting from the analysis is: Perceived Usefulness = 3.28 + 8.65 * Reproducibility The details of the regression analysis are: R squared (r2) = .37 F-statistic = 7.52 Significance level (p) = .017 The result of the regression summarized in Table 76 allows the rejection of the null hypotheses (H7N), meaning that we can empirically corroborate that perceived usefulness is determined by reproducibility.
Table 76. Simple regression between Perceived Usefulness and Reproducibility (OOmFPWeb; = .05)
Model Constant Reproducibility Unstd. Coeff. (b) 3.281 8.645 Std. Error .237 3.15 .605 Std. Coeffi. (Beta) t 13.83 2.74 Sig. .000 .017 95% Confidence Interval for b 2.769 (lower) 3.794 (upper) 1.836 (lower) 15.454 (upper)
The regression coefficients for Reproducibility were found to have high significance ( < .01). This means that H7 was confirmed. This also suggests that perceptions in usefulness are partially determined by perceptions in actual effectiveness. With respect to the predictive power of the model, Reproducibility explains 37% of the variance in Perceived Usefulness as indicated by (r2). Figure 73 shows the scatterplot of the Reproducibility (REP) values against the Perceived Usefulness scores with the regression line.
299
5,00
A A A A A A A A A A A A A
4,00
3,00
0,04
0,08
0,12
0,16
Reproducibility
Figure 73. Scatterplot: Perceived Usefulness vs. Reproducibility
Phase 3: A regression model for Perceived Ease of Use vs Perceived Usefulness In this phase, we tested H8 to verify if perceived usefulness is determined by perceived ease of use. Then, Perceived Ease of Use was used as the independent (predictor) variable and Perceived Usefulness as the dependent (predicted) variable. The regression equation resulting from the analysis is: Perceived Usefulness = 2.50 + .34 * Perceived Ease of Use The details of the regression analysis are: R squared (r2) = .08 F-statistic = 1.205 Significance level (p) = .292 The result of the regression (see Table 77) does not allow the rejection of the null hypothesis (H8N), meaning that we cannot empirically corroborate that perceived usefulness is determined by perceived ease of use.
300
Table 77. Simple regression between PEOU and PU (OOmFPWeb; = .05)

Model Constant Perceived Ease of Use Unstd. Coeff. (b) 2.504 .335 Std. Error 1.193 .305 .291 Std. Coeff. (Beta) t 2.099 1.098 Sig. .056 .292 95% Confidence Interval for b -.073 (lower) 5.081 (upper) -3.24 (lower) .995 (upper)
With regard to statistical significance, the regression equation was found to be not significant with > .1. This means that H8 was not confirmed. With respect to the predictive power of the model, Perceived Ease of Use explains only 8% of the variance in Perceived Usefulness as indicated by (r2). Figure 74 shows the scatterplot of Perceived Ease of Use scores against Perceived Usefulness scores with the regression line.
5,00
A A A A A A A
4,00
A A A A
3,00
3,00
3,50
4,00
4,50
5,00
Figure 74. Scatterplot: Perceived Ease of Use vs. Perceived Usefulness
Phase 4: A regression model for Perceived Ease of Use and Perceived Usefulness Vs. Intention to Use In this phase, we tested hypotheses H9 and H10 to verify if Intention to Use (ITU) is determined by Perceived Ease of Use (PEOU) and Perceived Usefulness (PU). To do this, PEOU and PU were used as independent 301
(predictor) variables and ITU as the dependent (predicted) variable. The regression equation resulting from the analysis is: Intention to Use = -2.96 + 1.16 * Perceived Ease of Use + 0,58 * Perceived Usefulness The details of the regression analysis are: R squared (r2) = .74 F-statistic = 17.06 Significance level (p) = .000 The result of the regression summarized in Table 78 allows us to empirically corroborate that intention to use is determined by perceived ease of use and perceived usefulness.
Table 78. Multiple regression between PEOU, PU and ITU (OOmFPWeb; = .05)
Model Constant Perceived Ease of Use Perceived Usefulness Unstd. Coeff. (b) -2.962 1,160 .582 Std. Error 1.160 .268 .233 Std. Coeff. (Beta) .666 .384 t -2.554 4.325 2.497 Sig. .025 .001 .028 95% Conf. Interval for b .025 .001 .028
With regard to statistical significance, the regression coefficients for PEOU and PU were found to have high ( < .01) and medium significance ( < .05), respectively. This means that H9 and H10 were confirmed. This also indicates that perceptions in intention to use are partially determined by perceptions in ease of use and usefulness. With respect to the predictive power of the model, Perceived Ease of Use and Perceived Usefulness together explain 74% of the variance in Intention to Use as indicated by (r2). Figure 75 shows the 3D scatterplot of Intention to Use scores against Perceived Ease of Use and Perceived Usefulness scores. However, the constant for intention to use (regression coefficient) was found to be negative. This means that an increase in perceived ease of use and perceived usefulness results in a decrease of Intention to Use, which was not expected. 302
A A A A A A A A A
A A A A A
Figure 75. Scatterplot: OOmFPWeb ITU vs. PEOU and PU
For this reason, we decided to analyze both links in separately. Thus, two simple regression models were conducted: Perceived Ease of Use vs. Intention to Use, and Perceived Usefulness vs. Intention to Use. The results show that the first regression model (Perceived Ease of Use vs. Intention to Use) was not significant but the second regression model (Perceived Usefulness vs. Intention to Use) was significant.
9.5
Discussion
With regard to whether OOmFPWeb is efficacious, the experimental data collected indicate that the measurement productivity obtained with OOmFPWeb is several times higher than industry rates. In addition, we have corroborated that users of OOmFPWeb produce consistent assessments. This result can be explained by the detailed measurement procedures and rules of OOmFPWeb, which provide a precise mapping between OOWS constructs and the concepts used in Function Point Analysis. With regard to whether OOmFPWeb is likely to be adopted in practice, the perceptions of the subjects seem to confirm the performance-related results. Subjects perceived OOmFPWeb as easy to use and useful and they 303
intend to use the method when sizing OOWS conceptual schemas. A further analysis is required to investigate whether these perceptions and intentions are really a result of their performance in using OOmFPWeb, as suggested by the theoretical model. Finally, with respect to the whether MAM is a valid theoretical model for evaluating OOmFPWeb, Table 79 summarizes the results of the regression analysis in terms of statistical significance (p). Two hypotheses of three were confirmed. The statistical significance was found to be medium for H7 and H10 ( < .05).
Table 79. Regression analysis results
Relationship H6 Actual Efficiency Perceived Ease of Use H7: Actual Effectiveness Perceived Usefulness H8: Perceived Ease of Use Perceived Usefulness H9: Perceived Ease of Use Intention to Use H10: Perceived Usefulness Intention to Use Significance (p) .740 .017 .292 .001 .028 Confirmed? NO YES NO NO YES
9.5.1 Validity evaluation

In this section, we discuss several issues that can affect the validity of the empirical study and how we attempted to alleviate them. 9.5.1.1 Threats to conclusion validity
We selected a homogeneous group of subjects in order to control the risk of the variation due to individual differences being larger than the variations due to the treatment. 9.5.1.2 Threats to construct validity
The performance-based dependent variables we used (i.e., reproducibility and accuracy) are criteria proposed in the ISO/IEC 14143-3 [21]. The perceptionbased dependent variables were measured according to subject ratings, using a measurement instrument based on the literature. 304
9.5.1.3
Threats to internal validity
The following threats to internal validity have been considered in this experiment: Measurement time. The starting measurement time was self-reported by the subjects, whereas the ending time was reported by the experimenter. Very small differences were observed in the starting time. Knowledge of the universe of discourse. We used the same OOWS conceptual schema of an e-commerce application for all subjects. Subject grade. To avoid a potential bias in subject responses, the subjects were identified in the measurement task, whereas the post-task survey was anonymous. Before performing the post-task survey, the students were informed about their grade. Thus, their grade on the course was not affected by the performance in the experiment. Fatigue effects. On average, each subject took two hours to solve the experimental tests, so fatigue was not very relevant. Persistence effects. In order to avoid persistence effects, the experiment was carried out by subjects who had never done similar experiments. Threats to External Validity
9.5.1.4
The greatest threat is the generalizability of the findings of this study. Our experimental subjects were PhD students which is not a representative sample of the population that would normally use a FSM method. Therefore, we are planning a new experiment using practitioners of OOWS in the context of the Spanish Association of Software Metrics.
9.6
Conclusions
This chapter describes an empirical study which evaluated the performance and likely adoption in practice of OOmFPWeb for sizing Web applications within the context of an OOWS development process. The conclusions that we can draw from the empirical results of this study are the following: Efficiency: the experimental data collected indicate that the measurement productivity obtained with OOmFPWeb is several times 305
higher than industry rates. This result can probably be explained by the experimental object that was used. Although the subjects were inexperienced in functional size measurement, the conceptual schema they had to size was a very well documented specification of the required Web application. Furthermore, the subjects were well versed in the OOWS method that was used to produce this schema. In practice, these conditions are not always met, which might explain why industry productivity rates are low compared to what was observed in this study. Effectiveness: we have corroborated that users of OOmFPWeb produce consistent assessments. This result can be explained by the detailed measurement procedures and rules of OOmFPWeb, which provide a precise mapping between OOWS constructs and the concepts used in FPA. The more precise these mapping rules are, the less interpretation problems people will have when using a functional size measurement method. Acceptance: The perceptions of the subjects seem to confirm the performance-related results. Subjects perceived OOmFPWeb as easy to use and useful and they intend to use the method when sizing OOWS conceptual schemas. A further analysis is required to investigate whether these perceptions and intentions are really a result of their performance in using OOmFPWeb, as suggested by the theoretical model. Another explanation (and perhaps more plausible) is that there is currently no alternative to OOmFPWeb.
Our work is different from the studies that were described in Chapter 2. We evaluated OOmFPWeb as a functional size measurement method for Web applications, not as a predictor of project effort. Another difference is that our evaluation is based on a laboratory experiment. To organize this experiment, we used a general and theory-based evaluation model for FSM methods. We are aware that more experimentation is needed in order to confirm the first results obtained. Recently, we ran three replications of the experiment described in this chapter. The first replication was run at the Valencia University of Technology with forty-six students in the final year of Engineering in Computer Science. The second replication was run with eighteen students in the PhD Program in Software Engineering at the Valencia University of Technology in the same course (Software Engineering for Web Environments) of the experiment described in this Chapter. Finally, the third 306
replication was run with twenty-eight Masters students at the University of Klagenfurt in Austria. We need to analyze these data in order to draw more definite conclusions on the adoption of OOmFPWeb in practice. In future replications, some changes need to be made to the experimental set-up, for instance with respect to some possible threats to validity. A more fundamental change is that, in the new experiment, a control would be used in the form of FPA. Given the many problems encountered when using FPA to size Web applications, it would be interesting to see to what extent OOmFPWeb improves the Function Point counting, both from a performancebased and a perception-based perspective.
307
Chapter 10
Conclusions and Further Research

This chapter revises the research objectives stated and the main findings that can be drawn from this work. We also examine to what extent the research objectives have been met. Finally, we discuss the contributions of this research to theory and practice and opportunities for further research.
10.1 Conclusions
The contributions of this thesis are discussed in terms of the design of the measurement procedure (and its extension for the Web), the validation of the design of the measurement procedure, the validation of the application of the measurement procedure, and finally, the actual usage of the measurement procedure.
10.1.1 Design of the measurement procedure

We have defined a functional size measurement procedure, called OOmFP, for object-oriented systems based on the information contained in conceptual schemas. This procedure enables the quantification of the functional size of OO systems at an early stage of the development lifecycle. Furthermore, OOmFP is compliant to the IFPUG FPA counting rules (unadjusted function point counting), which is the most widely FSM method used in practice and is a standard for functional size measurement approved by the ISO. Although OOmFP is designed to be used in conjunction with OO-
Chapter 10. Conclusions and Further Research
Method, many of the modeling primitives in its metamodel can also be found in other object-oriented analysis methods. The proposed procedure was also extended for measuring Web applications based on the primitives of the navigational and presentation models that were included in the OO-Method classical framework for developing Web applications. The design of the measurement procedure was presented using a generic process model for software measurement proposed by Jacquet and Abran [26]. It was also shown that OOmFP adheres to Fetckes generalized representation of functional size measurement methods that have a dataoriented metamodel [13]. As a proof of concept, the application of OOmFP was illustrated with a case study. Therefore, the objectives of defining the measurement procedure for OO system based on OO-Method conceptual schema and of extending it in order to size Web applications were fully fulfilled.
10.1.2 Validation of the design of the measurement procedure

This work revised the proposals existing in the literature for validating the design of the FSM methods. This is a forgotten aspect in the FSM field due to the fact that most of the studies published in the literature have been conducted to validate the use of size measures as effort or cost predictors. Some evidence of the validity of the primitive functional size measures of the proposed measurement procedure has been provided, but the validation of the derived measure is a future work. Therefore, the objective of the theoretical validation of the measurement procedure has only been partially fulfilled.
10.1.3 Validation of the application of the measurement procedure

A laboratory experiment was carried out to evaluate the application of OOmFP. The goal was to investigate which method (IFPUG FPA or OOmFP) has the highest performance and/or is more likely to be adopted in practice for sizing OO systems within the context of an OO-Method development process. The results show that the measurement results obtained with OOmFP are more consistent and accurate. OOmFP is perceived to be a useful FSM procedure in this context. The findings of this study are also positive in terms 310
of future revisions of the proposed theoretical model. This is the first study to empirically test theoretical models (i.e., MAM and TAM) in the context of FSM methods. This research contributes to the creation of a body of knowledge needed in Software Engineering by establishing the foundation of theories. Moreover, the theoretical model proposed might help to bridge the gap between research and practice in Empirical Software Engineering research, as it addresses the issue of method adoption in practice, which has been ignored by the Empirical Software Engineering (ESE) researchers. We also ran a laboratory experiment which evaluates OOmFPWeb This procedure was evaluated using the proposed theoretical model. The results show that OOmFPWeb is efficient when compared to current industry practices. Furthermore, the method produces consistent functional size assessments and is perceived to be easy to use and useful. Therefore, the objective of the empirical validation of the measurement procedure (OOmFP and OOmFPWeb) was fulfilled. However, we are aware that more experimentation is needed in order to generalize the obtained results.
10.1.4 Actual usage

OOmFP was adopted and automated [178] by a company in Spain (CARE Technologies) and is now being applied to several real-world projects. In fact, this measurement procedure was defined in a collaborative environment in which practitioners of the company and researchers of the OO-Method group participated. The experience gained has allowed us to put into practice this measurement procedure and to refine the proposed measurement rules. The measurement procedure was also evaluated as part of a benchmarking study27 conducted by the Gartner Group28. The goal of this study was to verify the advantages of using the OlivaNova Model Execution environment as compared to traditional software development approaches. In this study, the Gartner Group used IFPUG FPA to assess the size and the productivity of the projects being compared. Six software development projects using the OlivaNova Model Execution were compared to thirty-one similar projects from the Gartner repository. One of the results of this study was that the functional size of the OO systems assessed by Gartner is very similar to the functional size obtained by the tool which automates OOmFP.
27 28
http://www.care-t.com/technology/gartner.html http://www.gartner.com/
311
The extension of OOmFP for the Web (OOmFPWeb) is being used in the context of the Valencia University of Technology for academic purposes. It was used during two consecutive years, as part of the following courses: Software development environments: an advanced Software Engineering course in the final year of the Computer Science degree. Software Engineering for Web Environments: a PhD course where students learn advanced techniques about Web Engineering.
Recently, OOmFPWeb was also applied in a Masters course at the University of Klagenfurt in Austria. This procedure will be automated as soon as an automated support for the conceptual modeling using OOWS is developed. As a complementary activity, the proposed measurement procedure was presented to professional associations. Specifically, OOmFP and OOmFPWeb were presented as invited conferences in the last three years for a group of practitioners of the Spanish Association of Software Metrics (AEMES), where the author is actively participating as a board member. OOmFPWeb will be used during sessions of experience interchanges promoted by AEMES, and hopefully could be adopted by one of the companies that participate in this association.
10.1.5 Summary of the main contributions

This thesis has made several contributions. We list the main ones. The OOmFP proposal. A measurement procedure to apply IFPUG FPA to object-oriented conceptual schemas according to OO-Method was proposed. It is useful to both practictioners that uses the ONME tool (the envieronment in which the measurement procedure was implemented) as well as to researchers who would to generalize this proposal to other object-oriented environments. The OOmFPWeb proposal. This is the first measurement procedure that allows using the IFPUG FPA to size Web applications at the conceptual schema level. Research design. A field-based qualitative method (action research) was used when the measurement procedure was in its initial development stage, while a laboratory-based, quantitative method (laboratory experiment) was used to evaluate the measurement
312
procedure once it had become stable. The combination of different research methods is a more effective way of validating methods as argued by Fitzgerald [182]. Theoretical model. In preparation for the validation of the application of the FSM procedure, a theoretical model and measurement instrument for evaluating FSM methods was developed. This was based on a synthesis of the Technology Acceptance Model of Davis [140] and the Method Evaluation Model of Moody [70]. A part of the constructs of the theoretical model was operationalized using the performance criteria defined in Part 3 [21] of the ISO/IEC 14143. This model not only considers the quality of the measurement outputs (measured by the performance criteria) but also the perceptions of people using the FSM method (measured by the perception criteria). This was developed in the absence of any existing theoretical model for evaluating FSM methods. This was used as a theoretical base for the experimental work. As far we know, this is the only work published in the field of FSM and Software Measurement that provides a theoretical foundation for the definition and the execution of laboratory experiments. Empirical Studies. This thesis has conducted the first empirical comparison of FSM methods, which represents a contribution to this research area. OOmFP was defined on the basis of the IFPUG FPA standard, and it is used as the benchmark to which the new proposal (OOmFP) is evaluated. Prior to this research, there had been no systematic empirical research into the comparative effectiveness of FSM methods. This thesis also reported the first empirical study to evaluate the suitability of a FSM method for sizing Web applications.
In conclusion, the results of this thesis are useful from a theoretical point of view due to the fact that several theories are integrated in a multidisciplinary and systematic way: ISO standards for FSM, frameworks for FSM, Measurement Theory, IT / IS method evaluation models and Empirical Software Engineering. From a practical point of view, this research deals with two current problems in the industry today: the accurate sizing of objectoriented systems and complex Web applications.
313
10.2 Related publications

The work related to this thesis was published in two international journals, three book chapters, nineteen conferences and workshops, and two working papers.
10.2.1 International journals

Abraho S., Geert P., Pastor O. A Functional Size Measurement Method for Object-Oriented Conceptual Schemas: Design and Evaluation Issues Journal on Software & System Modeling (SoSyM), January 2004 (approval pending by a last review). Abraho S., Pastor O. Measuring the Functional Size of Web Applications International Journal of Web Engineering and Technology (IJWET), Vol. 1, No. 1, 5-16, 2003, Inderscience Enterprises, Ltd., England, ISSN : 1476-1289. Pastor O., Abraho S. M. and Fons J. J. Building E-Commerce Applications from Object-Oriented Conceptual Models, ACM SIGecom Exchanges, 2(2):24-32, June 2001.
10.2.2 Book chapters

Abraho S., and O. Pastor, Quality of Web-based Systems, Quality in the Software Development and Maintainance, Piattini, M.G. y Garca F. O., Ra-Ma, January 2003. Rstica, 344 pgs. ISBN:8478975446 (in Spanish) Abraho S., Olsina L., Pastor O. A Methodology for Evaluating Quality and Functional Size of Operative Web Applications 2nd International Workshop on Web Oriented Software Technology (IWWOST'02), ECOOP02 Workshops, Mlaga, Spain, June 2002, ISBN: 84-931538-9-3, pp. 1-20. Pastor O., Abraho S. M., Molina J. C., Torres I. A FPA-like Measure for Object-Oriented Systems from Conceptual Models, Proc. of the 11th International Workshop on Software Measurement, Montral, Canada, in Current Trends in Software Measurement,
314
Reiner Dumke, Alain Abran (Eds.), ISSN 1618-7946, Shaker Verlag, 2001.
10.2.3 International conferences and workshops

Abraho S., Poels G., Pastor O., Evaluating a Functional Size Measurement Method for Web Applications: An Empirical Analysis, in 10th IEEE International Software Metrics Symposium (METRICS 2004), Chicago, USA, September 2004. Abraho S., Poels G., Pastor O., Assessing the Accuracy and Reproducibility of FSM Methods through Experimentation, in 3rd International ACM-IEEE International Symposium on Empirical Software Engineering (ISESE 2004), Redondo Beach CA, USA, ISBN 0-7695-2165-7, August 2004. Abraho S., Poels G., Pastor O., Validation Issues on Functional Size Measurement of Object-Oriented Conceptual Schemas: The Case of OOmFP, in 8th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2004), Oslo, Norway, June 2004. Abraho S., Condori N., Olsina L., and Pastor O., Defining and Validating Metrics for Navigational Models in 9th IEEE International Software Metrics Symposium (METRICS 2003), Sydney, Australia, ISBN 0-7695-1987-3, pp. 200-210, IEEE Press, September 2003. Olsina L, Martin M., Fons J., Abraho S., and Pastor O., Towards the Design of a Metrics Cataloging System by Exploiting Conceptual, Navigational, and Semantic Web Approaches, 3rd International Conference on Web Engineering (ICWE 2003), Oviedo, Asturias, Spain, Lecture Notes on Computer Science 2722, Springer-Verlag, ISSN:0302-9743, pp. 324 333, 2003 Abraho S., Olsina L. and Pastor O., Towards the Quality Evaluation of Functional Aspects of Operative Web Applications in International ER'02 Workshop on Conceptual Modeling Quality (IWCMQ 2002), Tampere, Finland, October 2002, M. Genero, F. Grandi, W. van den Heuvel, J. Krogstie, et al. (Eds.), Lecture Notes in Computer Science 2784, Springer-Verlag. 315
Abraho, S., Pastor, O., Applying Function Points to Measure WebBased Applications, International Function Point Users Group 2002 Annual Conference (IFPUG 2002), San Antonio, Texas, USA, September 2002. Abraho S., Fons J. J., Gonzlez M. and Pastor O., Conceptual Modeling of Personalized Web Applications 2nd International Conference on Adaptive Hypermedia and Adaptive Web Based Systems (AH 2002), Mlaga, Spain, May 2002, in De Bra, P., Brusilovsky, P., Conejo, R., (Eds.), Lecture Notes in Computer Science 2347, Springer-Verlag. Pastor, O., Abraho S. M., Fons J. J., An Object-Oriented Approach to Automate Web Applications Development, 2nd International Conference on Electronic Commerce and Web Technologies (EC-Web 2001), Munich, Germany, September 2001, in K.Bauknecht, S.K.Madria, G.Pernul (Eds.), Lecture Notes in Computer Science 2115, Springer-Verlag, pp. 1628. Pastor O., Abraho S. M., Fons J. J. Navigational Patterns and Web Conceptual Modeling 1st Conference on Internet Business and the Industry of Construction (IBIC 2001), Joo Cunha, Nuno Nunes, Enriqueta Novoa (Eds.), ISBN 972-752050-2, Porto, Portugal, November 2001, pp. 19-29. Abraho S., Pastor O. Estimating the Applications Functional Size from Object-Oriented Conceptual Models International Function Points Users Group Annual Conference (IFPUG 2001), Las Vegas, USA, October 2001. Pastor O., Abraho S., Fons J. OOWS: An Object-Oriented Approach for Web-Solutions Modeling International Conference on Information Society, Media in Information Society (MEIS 2000), C.Bavec,M.Gams,V.Rajkvic,J.Gyrks (Eds.), ISBN 961 6303-26-0, Ljubljana, Slovenia, October 2000.
10.2.4 Ibero-american workshops

Condori-Fernandez N., Abraho S., and Pastor O. An Experience in the Theoretical Validation of Software Metrics 7th Ibero-american Workshop on Requirements Engineering and Software Environments
316
(IDEAS 2004), Arequipa, Per, May 2004, in L. Olsina et al. Eds., ISBN 9972-9876-1-2, pp. 114-121 (in Spanish). Pastor O., Fons J. J., Abraho S., Ramon S. An Object-Oriented Approach to the Design of Web Applications 4th Ibero-american Workshop on Requirements Engineering and Software Environments (IDEAS 2001), San Jos, Costa Rica, Abril 2001, ISBN 9968-32-000, pp. 239-251. (in Spanish).
10.2.5 National conferences and workshops

Abraho, S., Defining and Validating a FSM method for Web Applications Spanish Association of Software Metrics Annual Conference (AEMES 2003), Madrid, Spain, November 2003. Abraho, S., Pastor, O. A Sizing Approach for Web Applications Spanish Association of Software Metrics Annual Conference (AEMES 2002), Madrid, Spain, November 2002. Abraho, S., Pastor, O. Estimating the Functional Size of ObjectOriented Systems from Conceptual Models Spanish Association of Software Metrics Annual Conference (AEMES 2001), Madrid, Spain, October 2001. Abraho S., Pastor O., Olsina L. and Fons J. An approach to Measure the Functional Size and to Evaluate the Quality of Web Sites VI Jornadas de Ingeniera de Software y Base de Datos (JISBD 2001), Almagro, Spain, November 2001, Oscar Daz, Arantza Illarramandi, Mario Piattini (Eds.), ISBN 84-699-6275-2, pp. 478491. Abraho S., Fons J., Gonzlez M., Pastor O., Pelechano V. An Object-Oriented Method to Develop E-Commerce Applications, In New Methods and Tools Supporting E-Commerce Proceedings of the ZOCO Meeting. Corchuelo, R., Ruiz, A., Prez, J.A. Eds., Catedral Publications, Salamanca, Spain. ISBN:84-96086-02-X, 2002.
317
10.2.6 Working papers

Abraho, S., Poels, G. and Pastor, O. A Functional Size Measurement Method for Object-Oriented Conceptual Schemas: Design and Evaluation Issues, Working Paper 200/233, Faculty of Economics and Business Administration, Ghent University, Belgium, March 2004, 48 p. Abraho, S., Poels, G. and Pastor, O. Comparative Evaluation of Functional Size Measurement Methods: An Experimental Analysis, Working Paper 2004/234, Faculty of Economics and Business Administration, Ghent University, Belgium, March 2004, 50 p.
10.3 Future research directions

This thesis is not the end of research efforts in this area. Many research activities are currently underway, and further research is ongoing in different and complementary directions. The main issues that we are currently addressing are: Replication of the experiment using practitioners Measurement of other criteria such as the convertibility of FSM methods Investigation of the theoretical validation of OOmFP Definition of a measurement unit Construction of predictive models Improvement of the proposed theoretical model (i.e., increasing exploratory power). We are particularly interested in the use of OOmFP measurements in descriptive or predictive models. We are currently working on a Web repository project to gather information about projects that were developed using OO-Method / OOWS and that were measured using OOmFP/OOmFPWeb. Our goal is to build budget and productivity estimation models. As our approach is applied in a model-driven development environment, effort and schedule estimation models are less relevant as the system is obtained in an automatic way. 318
Another goal is to compare company-specific models with models based on multi-company data. To do this, an industrial data set maintained by the International Software Benchmarking Standards Group (ISBSG) [183] will be used.
319
List of Figures
Figure 1. Software domains and models..................................................................... 22 Figure 2. Evolution of FSM methods (Source: [13]) .................................................. 23 Figure 3. Relationships between ISO/IEC 14143 and ISO-standards FSM methods (adapted from [23]) ............................................................................................ 26 Figure 4. Measurement process steps (Source: Jacquet and Abran [25]) ................... 27 Figure 5. Measurement process detailed model (Source: Jacquet and Abran [25]). 28 Figure 6. The data-oriented abstraction (Source: [13])............................................... 30 Figure 7. The OO-Method approach........................................................................... 35 Figure 8. Summary of research design ....................................................................... 40 Figure 9. Action Research Phases............................................................................... 42 Figure 10. Overview of the experiment process (Source: [72]).................................. 45 Figure 11. The abstract model of the Web object ....................................................... 81 Figure 12. OO-Method as a MDD approach .............................................................. 88 Figure 13. Class Diagram for the library system ........................................................ 90 Figure 14. State Transition Diagram for the book class ............................................. 92 Figure 15. State Transition Diagram for the reader class............................................ 92 Figure 16. Pattern Language and use relationship (Source: [101])............................. 96 Figure 17. Excerpt of an OASIS specification ............................................................. 99 Figure 18. Conceptual modeling primitives of the Navigational Model................... 107 Figure 19. Navigational map for the Librarian user................................................. 107 Figure 20. Navigational context Reader_Details for the Librarian user................... 109 Figure 21. Navigational context Books for the Librarian user................................. 111 Figure 22. Conceptual Modeling Primitives of the Presentation Model................... 113 Figure 23. Navigational context Book_Details for the Librarian user ..................... 114 Figure 24. IFPUG FPA view on functional size ....................................................... 117 Figure 25. IFPUG FPA metamodel first level ....................................................... 118 Figure 26. IFPUG FPA metamodel second level................................................... 123 Figure 27. Example of class measurement ............................................................... 126 Figure 28. Example of class and legacy view measurement..................................... 127 Figure 29. Example of Service Measurement........................................................... 130 Figure 30. Example of Event Measurement ............................................................. 133 Figure 31. Example of an Instance Interaction Unit Measurement........................... 135 Figure 32. A model of the OOmFP Measurement Procedure ................................... 137 Figure 33. Object Model for the PMS system .......................................................... 141 Figure 34. State transaction diagram for class employee.......................................... 142 Figure 35. Example of a Population Interaction Unit ............................................... 142
List of Figures
Figure 36. Albums Navigational Context Measurement .......................................... 163 Figure 37. Album_Track Navigational Context Measurement................................. 164 Figure 38. ShoppingCart Navigational Context Measurement ................................. 165 Figure 39. Navigational context Album_Track measurement with presentational features............................................................................................................. 167 Figure 40. A simplified model of the OOmFPWeb Measurement Procedure .......... 168 Figure 41. Navigational Map of the Employee User ............................................... 170 Figure 42. Navigational Context Tasks of the Employee User................................. 171 Figure 43. Navigational Context Type of Projects for the Employee User .............. 172 Figure 44. Navigational Map of the Responsible User ............................................. 172 Figure 45. Navigational Context Employees of the Responsible User ..................... 173 Figure 46. Navigational Context Tasks of the Responsible User.............................. 174 Figure 47. Navigational Context Projects of the Responsible User .......................... 174 Figure 48. Navigational Map of the Manager User .................................................. 175 Figure 49. Navigational Context Employees for the Manager User ......................... 176 Figure 50. Navigational Context Projects of the Manager User ............................... 176 Figure 51. Navigational Context Type of Projects of the Manager User.................. 177 Figure 52. Navigational Context Type of Tasks for the Manager User.................... 178 Figure 53. Navigational Context Employees in Charge of the Manager User ......... 178 Figure 54. Navigational Context Department for the Manager User........................ 179 Figure 55. DISTANCE & Process Model of Jacquet and Abran.............................. 202 Figure 56. Simplified Technology Acceptance Model ............................................. 220 Figure 57. Method Evaluation Model MEM (Source: [70]) .................................. 223 Figure 58. Operationalized FSM Method Adoption Model...................................... 226 Figure 59. Theoretical Model (First Experiment)..................................................... 239 Figure 60. Mean Responses to Post-task Survey ...................................................... 253 Figure 61. Relationships between dependent constructs (adapted from Moody, 2001) ......................................................................................................................... 261 Figure 62. Scatterplot: Measurement Time vs Perceived Ease of Use ..................... 263 Figure 63. Scatterplot: Perceived Usefulness vs. Reproducibility and Accuracy ..... 264 Figure 64. Scatterplot: Perceived Ease of Use vs. Perceived Usefulness ................. 266 Figure 65. Scatterplot: Intention to Use vs. Perceived Ease of Use and Perceived Usefulness........................................................................................................ 268 Figure 66. Comparison between methods results ..................................................... 269 Figure 67. Validation of theoretical model ............................................................... 270 Figure 68. Scatterplot: Perceived Usefulness vs Intention to Use ............................ 272 Figure 69. Validation of revised theoretical model................................................... 273 Figure 70. Theoretical Model (Second Experiment) ................................................ 283 Figure 71. Relationships between Dependent Constructs (adapted from Moody, 2001) ......................................................................................................................... 297 Figure 72. Scatterplot: Productivity vs Perceived Ease of Use................................. 298 Figure 73. Scatterplot: Perceived Usefulness vs. Reproducibility ............................ 300 Figure 74. Scatterplot: Perceived Ease of Use vs. Perceived Usefulness ................. 301
322
List of Figures
Figure 75. Scatterplot: OOmFPWeb ITU vs. PEOU and PU ................................... 303
323
List of Tables
Table 1. Comparison between first category FSM methods ....................................... 75 Table 2. Comparison between second category FSM methods .................................. 76 Table 3. Comparison between third category FSM methods...................................... 77 Table 4. Comparison between FSM methods for Web applications........................... 85 Table 5. Functional Model example ........................................................................... 94 Table 6. Mapping rules to identify the system boundary.......................................... 120 Table 7. Mapping the IFPUG FPA concepts to OO-Method primitives................... 121 Table 8. Complexity weights .................................................................................... 123 Table 9. Measurement rules for the complexity of a class........................................ 125 Table 10. Measurement rules for the complexity of a legacy view .......................... 127 Table 11. Measurement rules for the complexity of a class service ......................... 128 Table 12. Measurement rules for the complexity of a legacy view service .............. 130 Table 13. Measurement rules for the complexity of a class service (Dynamic Model) ......................................................................................................................... 132 Table 14. Measurement rules for the complexity of a legacy view service (Dynamic Model).............................................................................................................. 132 Table 15. Measurement rules for the Functional Model ........................................... 134 Table 16. Measurement rules for the instance interaction unit pattern ..................... 134 Table 17. Measurement rules for the population interaction unit pattern ................. 136 Table 18. Functional Model example Class: Responsible, Attribute: start_date, Category: state-independent............................................................................. 142 Table 19. EIs identification....................................................................................... 144 Table 20. EOs and EQs identification ...................................................................... 145 Table 21. Classes measurement ................................................................................ 146 Table 22. Legacy view measurement........................................................................ 146 Table 23. Class service measurement ....................................................................... 147 Table 24. Example of a PIU measurement ............................................................... 147 Table 25. Action research in the design of OOmFP ................................................. 149 Table 26. Comparison between first category FSM methods and OOmFP .............. 151 Table 27. Mapping the IFPUG FPA concepts to OOWS primitives ........................ 161 Table 28. Measurement rules for a navigational context (navigational perspective) 162 Table 29. Measurement rules for a navigational context (presentation perspective) 166 Table 30. Navigational Contexts Measurement........................................................ 180 Table 31. Comparison between OOmFPWeb and related work ............................... 182 Table 32. Measurement scale types and transformations.......................................... 191 Table 33. Direct measures existing in OOmFP for the data measurement process (data perspective)...................................................................................................... 197
List of Tables
Table 34. Direct measures existing in OOmFP for the transactional measurement process (behaviour and process perspectives).................................................. 199 Table 35. Direct measures existing in OOmFP for the transactional measurement process (presentation perspective) ................................................................... 200 Table 36. Distance-based definition of the NRC metric ........................................... 204 Table 37. Required inputs and expected results........................................................ 208 Table 38. Direct measures existing in OOmFPWeb (navigation and presentation perspectives) .................................................................................................... 209 Table 39. Distance-based definition of the NFNC measure ..................................... 210 Table 40. Classification of dependent variables ....................................................... 235 Table 41. Summary of training sessions and experimental tasks.............................. 238 Table 42. Descriptive statistics for measurement time ............................................. 248 Table 43. Paired samples t-test rank for differences in mean measurement times (IFPUG FPA versus OOmFP; = 0.05) .......................................................... 248 Table 44. Descriptive statistics for functional size ................................................... 249 Table 45. 1-tailed Wilcoxon signed rank test for differences in median reproducibility assessments (IFPUG FPA versus OOmFP; = 0.05) ...................................... 250 Table 46. 1-tailed Wilcoxon signed rank test for differences in median accuracy assessments (IFPUG FPA versus OOmFP; = 0.05) ...................................... 250 Table 47. Descriptive statistics for perceived ease of use......................................... 251 Table 48. 1-tailed Paired samples t-test rank for differences in mean perceived ease of use (IFPUG FPA versus OOmFP; = 0.05).................................................... 251 Table 49. Descriptive statistics for perceived usefulness.......................................... 252 Table 50. 1-tailed Paired Samples t-test rank for differences in mean perceived usefulness (IFPUG FPA versus OOmFP; = 0.05)......................................... 252 Table 51. Descriptive statistics for intention to use .................................................. 253 Table 52. 1-tailed Paired samples t-test rank for differences in mean intention to use (IFPUG FPA versus OOmFP; = 0.05) .......................................................... 253 Table 53. Correlation between survey items (construct validity analysis)................ 256 Table 54. Correlation between survey items (after Q11 removed) ........................... 257 Table 55. Item reliabilities for constructs ................................................................. 258 Table 56. 1-tailed One sample t-test rank for differences in mean perceived ease of use .................................................................................................................... 259 Table 57. 1-tailed One sample t-test rank for differences in mean perceived usefulness ......................................................................................................................... 259 Table 58. 1-tailed One sample t-test rank for differences in mean intention to use.. 260 Table 59. Simple regression between Perceived Ease of Use and Measurement Time (OOmFP; = .05) ............................................................................................ 262 Table 60. Multiple regression between PU, Reproducibility and Accuracy (OOmFP; = .05) ............................................................................................ 264 Table 61. Simple Regression between PEOU and PU (OOmFP; = .05)................ 265 Table 62. Multiple regression between PEOU, PU and ITU (OOmFP; = .05)...... 267 Table 63. OOmFP acceptance analysis results ......................................................... 269
326
List of Tables
Table 64. Regression analysis results ....................................................................... 270 Table 65. Simple regression between PU and ITU (OOmFP; = 0.05)................... 272 Table 66. Descriptive statistics for productivity and reproducibility........................ 288 Table 67. Excerpt of the survey instrument .............................................................. 290 Table 68. Descriptive statistics for PEOU, PU and ITU........................................... 291 Table 69. 1-tailed One sample t-test rank for differences in mean PEOU................ 291 Table 70. 1-tailed One sample t-test rank for differences in mean PU ..................... 292 Table 71. 1-tailed One Sample t-test rank for differences in mean ITU ................... 292 Table 72. Correlation between survey items (construct validity analysis)................ 294 Table 73. Correlation between survey items (after Q10 removed) ........................... 295 Table 74. Item reliabilities for constructs ................................................................. 296 Table 75. Simple regression between Perceived Ease of Use and Measurement Time (OOmFPWeb; = .05)..................................................................................... 298 Table 76. Simple regression between Perceived Usefulness and Reproducibility (OOmFPWeb; = .05)..................................................................................... 299 Table 77. Simple regression between PEOU and PU (OOmFPWeb; = .05) ......... 301 Table 78. Multiple regression between PEOU, PU and ITU (OOmFPWeb; = .05) ......................................................................................................................... 302 Table 79. Regression analysis results ....................................................................... 304
327
List of Abbreviations and Acronyms

A/S ASMA BFC CARE CASE CBO CFPS COCOMO COPs COSMIC CV DIT DV DWPs EI EIF EO EQ ESE FFP FPA FPs FSM FTR FURs Algorithmic/Scientific Australian Software Metrics Association Base Functional Component Computer Aided Requirements Engineering Computer Aided Software Engineering Coupling Between Objects Certified Function Point Specialist Constructive Cost Model Component object points COmmon Software Metrics International Consortium Convergent Validity Depth of Inheritance Tree Discriminant Validity Data Web Points External Input External Interface File External Output External Inquiry Empirical Software Engineering Full Function Points Function Point Analysis Function Points Functional Size Measurement File Types Referenced Functional User Requirements
GQM HTML IFPUG ID IEC IF IIU ILF ITU ISO MAM MDIU MEM MIS MRE NESMA OASIS OMT OO OOH OOHDM OOmFP OOmFPWeb OOWS PEOU PIU POP PU PMS
Goal/Question/Metric HyperText Markup Language International Function Point Users Group Interaction Diagram International Electrotechnical Commission Identification Function Instance Interaction Unit Internal Logical File Intention To Use International Organization for Standardization Method Adoption Method Master-Detail Interaction Unit Method Evaluation Method Management Information Systems Magnitude of Relative Error Netherlands Software Metrics Users Association Open and Active Specification of Information Systems Object Modeling Technique Object-Oriented Object-Oriented Hypermedia Object-Oriented Hypermedia Design Method OO-Method Function Points OO-Method Function Points for the Web Object-Oriented Web Solutions Perceived Ease of Use Population Interaction Unit Predictive Object Points Perceived Usefulness Project Management System
330
REP RET RT RUR SE SLOC STD TAM TRA UKSMA UML UPV WebML
REProducibility measurements Record Element Type Real-time embedded Reference User Requirements Software Engineering source lines of code State Transition Diagram Technology Acceptance Model Theory of Reasoned Action United Kingdom Metrics Association Unified Modeling Language Universidad Politcnica de Valencia Web Modeling Language
331
Bibliography
[1] [2] [3] [4] [5] P. G. Rule, "The Importance of the Size Software Requirements", Software Measurement Services Ltd. UK, 18 p. 2001. Standish_Group, "The 2003 CHAOS Chronicles", The Standish Group International, Inc. 2003. B. W. Boehm, Estimating Software Costs, Prentice Hall, N. J., 1981, T. C. Jones, Estimating Software Costs, McGraw-Hill, New York, 1998, A. J. Albrecht and J. E. Gaffney, "Software function, source lines of code, and development effort prediction: a software science validation", IEEE Transactions on Software Engineering, vol. 9, no. 6, pp. 639648, 1983. C. F. Kemerer, "An Empirical Validation of Software Cost Estimation Models", Communications of the ACM, vol. 30, no. 5, pp. 416-429, 1987. B. Kitchenham, "Using Function Points for Software Cost Estimation - Some Empirical Results", 10th Annual Conference of Software Metrics and Quality Assurance in Industry, Amsterdam, The Netherlands, 1993. R. Meli, "Functional and Technical Software Measurement: Conflict or Integration?" 3 rd. European Software Measurement Conference (FESMA'00), Madrid, Spain, 2000. ISO, "ISO/IEC 14143-1- Information Technology - Software measurement Functional Size Measurement. Part 1: Definition of Concepts", 1998. ISO, "ISO/IEC 9126-1, Software engineering - Product quality - Part 1: Quality model", 2001. L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, Non-functional requirements in software engineering, Kluwer Academic Publishers, 2000, A. J. Albrecht, "Measuring application development productivity", IBM Application Development Symposium, 1979. T. Fetcke, A. Abran, and R. Dumke, "A Generalized Representation for Selected Functional Size Measurement Methods", 11th International Workshop on Software Measurement, Montral, Canada, 2001. IFPUG, "Function Point Counting Practices Manual, Release 4.1", International Function Point Users Group, Westerville, Ohio, USA 1999.
[6] [7]
[8]
[9] [10] [11] [12] [13]
[14]
Bibliography
[15] [16]
UKSMA, "MKII Function Point Analysis Counting Practices Manual. Version 1.3.1", United Kingdom Software Metrics Association 1998. D. St.Pierre, M. Maya, A. Abran, J. M. Desharnais, and P. Bourque, "Full Function Points: Counting Practices Manual." Software Engineering Management Research Laboratory and Software Engineering Laboratory in Applied Metrics Technical Report 1997-04, 1997. A. Abran, J. M. Desharnais, S. Oligny, D. St.Pierre, and C. Symons, "COSMIC-FFP Measurement Manual, The COSMIC Implementation Guide for ISO/IEC 19761, Version 2.2", The Common Software Measurement International Consortium January 2003. G. C. Low and D. R. Jeffery, "Function Points in the estimation and evaluation of the software process", IEEE Transactions on Software Engineering, vol. 16, no. 1, pp. 64-71, 1990. J. E. Matson, B. E. Barret, and J. M. Mellichamp, "Software Development Cost Estimation Using Function Points", IEEE Transactions on Software Engineering, vol. 20, no. 4, pp. 275-287, 1994. ISO, "ISO/IEC 14143-2 - Information Technology - Software measurement Functional Size Measurement. Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1:1998", 2002. ISO, "ISO/IEC 14143-3 - Information technology -- Software measurement -Functional size measurement -- Part 3: Verification of functional size measurement methods", 2003. ISO, "ISO/IEC TR 14143-4:Information technology -- Software measurement -- Functional size measurement -- Part 4: Reference model", 2002. ISO, "NWI Proposal - Information Technology - Software Measurement Functional Size Measurement - Part 6: Guide for use of ISO/IEC 14143 series and related international standards", S. WG12, Ed., 2003. ISO, "ISO/IEC TR 14143-5:2004, Information technology -- Software measurement -- Functional size measurement -- Part 5: Determination of functional domains for use with functional size measurement", 2004. A. Abran and J. P. Jacquet, "A Structured Analysis of the new ISO Standard on Functional Size Measurement - Definition of Concepts", 4th IEEE Int. Symposium and Forum on Software Engineering Standards, 1999. J. P. Jacquet and A. Abran, "From Software Metrics to Software Measurement Methods: A Process Model", 3rd Int. Standard Symposium and Forum on Software Engineering Standards (ISESS'97), Walnut Creek, USA, 1997.
[17]
[18]
[19]
[20]
[21]
[22] [23]
[24]
[25]
[26]
334
Bibliography
[27] [28]
H. Zuse, A Framework for Software Measurement. Berlin, Germany, Walter de Gruyter, 1998, B. Kitchenham, S. Pfleeger, and N. Fenton, "Towards a Framework for Software Measurement Validation", IEEE Transactions on Software Engineering, vol. 21, 929-943, 1995. N. Fenton, Software Metrics: A Rigorous Approach, Chapman & Hall, 1991, IFPUG, "Function Point Counting Practices: Case Study 3 - Object-Oriented Analysis, Object Oriented Design (Draft)", 1995. UKSMA, "MK II Function Point Analysis Counting Practices Manual, Version 1.3.1", United Kingdom Software Metrics Association September 1998. D. Garmus and D. Herron, Function Point Analysis: Measurement Practices for Sucessful Software Projects, 2000, D. J. Reifer, "Let the Numbers Do the Talking", CrossTalk: The Journal of Defense Software Engineering, March 2002. L. Molini and A. Abran, "Software Outsourcing Contracts: An Economic Analysis based on Agency Theory", International Workshop on Software Measurement (IWSM'98), Qubec, Canada, 1999. L. Laranjeira, "Software Size Estimation of Object-Oriented Systems", IEEE Transactions on Software Engineering, vol. 16, no. 5, pp. 510-522, 1990. R. D. Banker, R. J. Kauffman, and R. Kumar, "An Empirical Test of Objectbased Output Measurement Metrics in a Computer Aided Software Engineering (CASE) Environment", Journal of Management Information Systems, vol. 8, no. 3, pp. 127-150, Winter 1991-92. E. Rains, "Function Points in an ADA Object-Oriented Design", OOPS Messenger, vol. 2, no. 4, pp. 23-25, 1991. ASMA, "Sizing in Object-Oriented Environments", Australian Software Metrics Association (ASMA), Victoria, Australia 1994. N. Thomson, R. Johnson, R. MacLeod, G. Miller, and T. Hansen, "Project Estimation Using an Adaptation of Function Points and Use Cases for OO Projects", OOPSLA'94 Workshop on Pragmatic Theoretical Directions in Object-Oriented Software Metrics, 1994. H. Zhao and T. Stockman, "Software Sizing for OO software development Object Function Point Analysis", GSE Conference, Berlin, Germany, 1995. H. M. Sneed, "Estimating the Development Costs of Object-Oriented Software", 7th European Software Control and Metrics Conference, Wilmslow, UK, 1996.
[29] [30] [31] [32] [33] [34]
[35] [36]
[37] [38] [39]
[40] [41]
335
Bibliography
[42]
O. A. Lehne, "Experience Report: Function Points Counting of Object Oriented Analysis and Design based on the OOram method", Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'97), 1997. T. Fetcke, A. Abran, and T. H. Nguyen, "Function point analysis for the OOJacobson method: a mapping approach", FESMA'98, Antwerp, Belgium, 1998. G. Antoniol and F. Calzolari, "Adapting Function Points to Object Oriented Information Systems", 10th Conference on Advanced Information Systems Engineering (CAiSE'98), 1998. F. Minkiewicz, "Measuring Object Oriented Software with Predictive Object Points", Project Control for Software Quality, A. C. Rob Kusters, Fred Heemstra and Erik van Veenendaal, Ed.: Shaker Publishing, 1999. J. Kammelar, "A Sizing Approach for OO-environments", 4th International ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering, Cannes, 2000. D. J. Ram and S. V. G. K. Raju, "Object Oriented Design Function Points", First Asia-Pacific Conference on Quality Software, 2000. T. Uemura, O. Kusumoto, and I. Katsuro, "Function-point analysis using design specifications based on the Unified Modelling Language", Journal of Software Maintenance and Evolution: Research and Practice, John Wiley & Sons, Ltd., vol. 13, no. 4, pp. 223-243, 2001. D. Reifer, "Web Development: Estimating Quick-to-Market Software", IEEE Software, vol. 17, no. 6, pp. 57-64, 2000. "Cutter Consortium, Poor Project Management Problem of E-Projects": http://www.cutter.com/consortium/press/001019.html, October 2000. D. Schwabe and G. Rossi, "The Object-Oriented Hypermedia Design Model", Communications of the ACM, vol. 38, no. 8, pp. 45-46, 1995. S. Ceri, P. Fraternali, and A. Bongio, "Web Modeling Language (WebML): a modeling language for designing Web sites", 9th Word Wide Web Conference (WWW'00), Amsterdam, The Netherlands, 2000. L. Baresi, F. Garzotto, and P. Paolini, "From Web Sites to Web Applications: New Issues for Conceptual Modeling", ER'2000 Workshop on Conceptual Modeling and the Web, 2000. O. Pastor, S. Abraho, and J. Fons, "An Object-Oriented Approach to Automate Web Applications Development", 2nd International Conference on Electronic Commerce and Web Technologies (EC-Web'01), LNCS 2115, Munich, Germany, 2001.
[43] [44]
[45]
[46]
[47] [48]
[49] [50] [51] [52]
[53]
[54]
336
Bibliography
[55]
J. Fons, V. Pelechano, M. Albert, and O. Pastor, "Development of Web Applications from Web Enhanced Conceptual Schemas", International Conference on Conceptual Modeling (ER 2003), Chicago, USA, 2003. A. Abran and P. N. Robillard, "Function Points: A Study of Their Measurement Processes and Scale Transformations", Journal of Systems and Software, vol. 25, pp. 171-184, 1994. O. Pastor, J. Gmez, E. Insfrn, and V. Pelechano, "The OO-Method Approach for Information Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming", Information Systems, vol. 26, no. 7, pp. 507-534, 2001. O. Pastor and I. Ramos, OASIS version 2 (2.2): A Class-Definition Language to Model Information Systems, vol. 3rd edition. Valencia, Espaa, Servicio de Publicaciones Universidad Politcnica de Valencia, 1995, S. T. March and G. F. Smith, "Design and natural science research on information technology", Decision Support Systems, vol. 15, 251-266, 1995. ISO, "International Vocabulary of Basic and General Terms in Metrology, Second edition", 1993. J. A. Bubenko, Information Systems Methodologies - A Research View, T. W. Olle, H. G. Sol and A. A. Verrijn-Stuart (eds.), North-Holland, 1986, D. Avison, "Action Programmes For Teaching And Researching In Information Systems", Australian Computer Journal, vol. 23, no. 2, pp. 66-72, 1991. P. B. Checkland, From Framework Through Experience To Learning: The Essential Nature of Action Research, H. E. Nissen, H. K. Klein and R. Hirschheim (eds.): Information Systems Research: Contemporary Approaches and Emergent Traditions, 1991, R. L. Baskerville and T. Wood-Harper, "A Critical Perspective on Action Research as a Method for Information Systems Research", Journal of Information Technology, vol. 3, no. 11, pp. 235-246, 1996. D. Avison, F. Lau, M. Myers, and P. A. Nielsen, "Action Research", Communications of the ACM, vol. 42, no. 1, pp., 1999. V. R. Basili, R. W. Selby, and D. H. Hutchens, "Experimentation in software engineering", IEEE Transactions on Software Engineering, vol. 12, no. 7, pp. 733 - 743, July 1986. M. V. Zelkowitz and D. R. Wallace, "Experimental Models for Validating Technology", IEEE Computer, vol. 31, no. 5, pp. 23-31, 1998.
[56]
[57]
[58]
[59] [60] [61] [62]
[63]
[64]
[65] [66]
[67]
337
Bibliography
[68] [69]
W. F. Tichy, "Should Computer Scientists Experiment More?" IEEE Computer, vol. 38, no. 5, pp. 32-40, 1998. B. A. Kitchenham, S. Pfleeger, and e. al, "Preliminary Guidelines for Empirical Research in Software Engineering", IEEE Transactions on Software Engineering, vol. 28, no. 8, pp. 721-734, 2002. D. L. Moody, "Dealing with Complexity: A Practical Method for Representing Large Entity Relationship Models", PhD. Thesis, Department of Information Systems, University of Melbourne, Melbourne, Australia, 2001. V. R. Basili, "The role of experimentation in software engineering: past, current, and future", 18th International Conference on Software Engineering (ICSE'96), 1996. C. Wohlin, P. Runeson, M. Hst, M. C. Ohlsson, B. Regnell, and A. Wessln, Experimentation in Software Engineering: An Introduction, Kluwer Academic Publishers, 2000, N. Juristo and A. M. Moreno, Basics of Software Experimentation, Kluwer Academic Publishers, Boston, 2001, Engineering
[70]
[71]
[72]
[73] [74]
V. R. Basili and H. D. Rombach, "The TAME Project: Towards ImprovementOriented Software Environments", IEEE Transactions on Software Engineering, vol. 14, no. 6, pp. 758-773, 1988. C. A. Dekkers and S. Cartwright, "Can Function Points Be Used to Size RealTime, Scientific, Object-Oriented, Extreme Programmed, or Web-Based Software?" IT Metrics Strategies, Cutter Information Corp., vol. 7, no. 7, pp., July 2001. T. Uemura, S. Kusumoto, and K. Inoue, "Function Point Measurement Tool for UML Design Specification", 5th International Software Metrics Symposium (METRICS'99), Florida, USA, 1999. T. Reenskaug, O. Wold, and A. Lehne, Working with Objects: the OOram Software Engineering Method. England, 1996, G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language Users Guide, Addison-Wesley, 1999, I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use--Case Driven Approach, Addison Wesley Longman, Inc., 1992, IFPUG, "Function Point Counting Practices Manual, Release 4.0", International Function Point Users Group, Westerville, Ohio 1994.
[75]
[76]
[77] [78] [79]
[80]
338
Bibliography
[81] [82]
S. A. Whitmire, "3D Function Points: Specific and Real-Time Extensions of Function Points", Pacific Northwest Software Quality Conferene, 1992. S. R. Chidamber and C. F. Kemerer, "A Metrics Suite for Object Oriented Design", IEEE Transactions on Software Engineering, vol. 20, no. 6, pp. 476 493, June 1994. G. Booch, Object Oriented Analysis with Applications - 2nd Edition. Redwood City, CA, USA, Benjamin/Cummings Publishing Co. Inc., 1994, D. Garmus and D. Herron, "Estimating Software Earlier and More Accurately", Object-Z, Systems Inc., http://objectz.com/columnists/2davids/07232001.asp July 2001. S. Moser, B. Henderson-Sellers, and V. B. Misic, "Cost Estimation Based on Business Models", Journal of Systems and Software, vol. 49, no. 1, pp. 33-42, 1999. IFPUG, "Hints to Counting Web Sites": IFPUG White Paper, 1998. T. Rollo, "Sizing E-commerce", Proc. of the Australian Conference on Software Metrics (ACOSM'00), Sydney, Australia, 2000. "Total Metrics, Web Based Applications: How is FPA applied to sizing Web Based applications?" 2001. D. J. Reifer, "Estimating Web Development Costs: There Are Differences", CrossTalk: The Journal of Defense Software Engineering, Jun 2002. D. Reifer, "Web Objects Counting Conventions". Torrance, CA.: White Paper, Reifer Consultants Inc., 2002. M. H. Halstead, Elements of Software Science. Elsevier North Holland, The Netherlands, 1977, B. W. Boehm, C. Abts, A. W. Brown, S. Chulami, B. K. Clark, E. Horowitz, M. R., D. Reifer, and B. Steece, Software Cost Estimation with Cocomo II, 1st edition ed, Prentice-Hall, 2000, 544 p. D. Cleary, "Web-Based Development and Functional Size Measurement." IFPUG Annual Conference, San Diego, USA, 2000. "Cost Xpert Group Inc." Estimating Internet http://www.costxpert.com/Reviews_Articles/SoftDev/. Development.
[83] [84]
[85]
[86] [87] [88] [89] [90] [91] [92]
[93] [94] [95]
S. F. Ochoa, M. C. Bastarrica, and G. Parra, "Estimating the Development Effort of Web Projects in Chile", First Latin American Web Congress (LAWEB 2003), 2003.
339
Bibliography
[96]
M. Ruhe, R. Jeffery, and I. Wieczorek, "Using Web Objects for Estimating Software Development Effort for Web Applications", 9th International Software Metrics Symposium (METRICS'03), Sydney, Australia, 2003. L. Baresi, S. Morasca, and P. Paolini "Estimating the Design Effort of Web Applications", 9th International Software Metrics Symposium (METRICS'03), Sydney, Australia, 2003. O. Pastor, V. Pelechano, E. Insfrn, and J. Gmez, "From Object-Oriented Conceptual Modeling to Automated Programming in Java", 17th Int. Conference on Conceptual Modeling (ER'98), Singapore, 1998. B. Selic, "The Pragmatics of Model-Driven Development", IEEE Software, vol. 20, no. 5, pp. 19-25, 2003.
[97]
[98]
[99]
[100] J. Rumbaugh, M. Blaha, W. Premerlanoi, F. Eddy, and W. Lorensen, Object Oriented Modeling and Design, Prentice Hall, 1991, [101] P. J. Molina, "User Interface Specification: From Requirements to Code Generation", PhD. Thesis, Department of Information Systems and Computation, Valencia University of Technology, 2003 (in Spanish). [102] P. Letelier, P. Snchez, I. Ramos, and O. Pastor, OASIS 3.0: Un enfoque formal para el modelado conceptual orientado a objetos. Valencia, Espaa, Servicio de Publicaciones Universidad Politcnica de Valencia, 1998, 184 p. [103] R. J. Wieringa and J.-J. C. Meyer, "Actors, Actions and Initiative in Normative System Specification", Annals of Mathematics and Artificial Intelligence, vol. 7, no. 1-4, pp. 289-346, 1993. [104] I. Ramos, O. Pastor, J. Cuevas, and J. Devesa, "Objects as Observable Processes", 3rd Workshop on the Deductive Approach to Information System Design, Costa Brava, Catalua, 1993. [105] R. J. Wieringa, "Algebraic Foundations for Dynamic Conceptual Models", PhD. Thesis, Dept. of Mathematics and Computer Science, Vrije Universiteit. Amsterdam, May 1990. [106] O. Pastor, "Diseo y Desarrollo de un Entorno de Produccin Automtica de Software Basado en el Modelo Orientado a Objetos", PhD. Thesis, Departamento de Sistemas Informticos y Computacin (DSIC), Universidad Politcnica de Valencia, Valencia, Espaa, Mayo 1992. [107] A. Broder, R. Kumar, F. Maghoul, P. Raghavan, S. Rajagopalan, R. Stata, A. Tomkins, and J. Wiener, "Graph Structure of the Web", 9th World Wide Web Conference,, 2000. [108] HPR, "Hypermedia design http://www.designpattern.lu.unisi.ch/", 2004. patterns repository,
340
Bibliography
[109] J. Fons, P. Valderas, M. Ruiz, G. Rojas, and O. Pastor, "OOWS: A Method to Develop Web Applications from Web-Oriented Conceptual Models", 7th World Multiconference on Systemics, Cibernetics and Informatics (SCI 2003), Orlando, Florida, USA, 2003. [110] O. Pastor, J. Fons, V. Torres, and V. Pelechano, "Conceptual Modelling versus Semantic Web: the two sides of the same coin?" Application Design, Development and Implementation Issues in the Semantic Web, in conjunction with WWW Conference, New York (USA), 2004. [111] E. V. B. Wandji, G. Lvesque, and J. Meunier, "Toward an ontological formalization for a software functional size measurement method's application process: The FPA case", Conference Internationale Associant Chercheurs Vietnamiens et Francophones en Informatique (RIVF 2004), Hanoi, Vietnam, 2004. [112] 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. [113] R. S. Pressman, "Can Internet-Based Applications Be Engineered?" IEEE Software, vol. 15, no. 5, pp. 104-110, Sept./Oct. 1998. [114] T. A. Powell, Web Site Engineering: Beyond Web Page Design. Upper Saddle River, N. J., USA, Prentice Hall, 1998, [115] A. Ginige and S. Murugesan, "Web Engineering: An Introduction", IEEE Multimedia, vol. 8, no. 1, pp. 14-18, 2001. [116] N. Zelnick, "Nifty Technology and Nonconformance: The Web in Crisis", Computer, vol. 31, no. 10, pp. 115 -116 and 119, October 1998. [117] J. Gmez, C. Cachero, and O. Pastor, "Conceptual Modeling of DeviceIndependent Web Applications", IEEE MultiMedia, vol. 8, no. 2, pp. 26-39, 2001. [118] C. R. Symons, Software sizing and estimating: Mk II FPA (Function point analysis), John Wiley & Sons, 1991, [119] L. Olsina, D. Godoy, G. J. Lafuente, and G. Rossi, "Specifying Quality Characteristics and Attributes for Website", Y. D. E. San Murugesan, LNCS 2016, Springer Verlag, Ed., Web Engineering 2001, pp. 266-278. [120] F. S. Roberts, Measurement Theory with Applications to Decisionmaking, Ttility, and the Social Sciences, Reading, Mass, Addison-Wesley, 1979, [121] J. P. Jacquet and A. Abran, "Metrics Validation Proposals: A Structured Analysis", 8th International Workshop on Software Measurement, Magdeburg, Germany, 1998.
341
Bibliography
[122] G. Poels, "Definition and Validation of a COSMIC-FFP Functional Size Measure for Object-Oriented Systems", 7th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2003), Darmstadt, Germany, 2003. [123] G. Poels, "Why Function Points Do Not Work: In Search of New Software Measurement Strategies", Guide Share Europe Journal, vol. 1, no. 2, pp. 9-26, 1996. [124] D. H. Krantz, R. D. Luce, P. Suppes, and A. Tversky, Foundations of Measurement, vol. 1. New York, Academic Press, 1971, [125] P. Suppes, D. Krantz, R. Luce, and A. Tversky, Foundations of Measurement: Geometrical, Threshold, and Probabilistic Representations, vol. 2. San DiegoCA, USA, Academic Press, 1989, [126] T. Fetcke, "A Generalized Structure for Function Point Analysis", 9th International Workshop on Software Measurement (IWSM'99), MontTrembland, Canada, 1999. [127] L. Briand, K. El-Emam, and S. Morasca, "On the Application of Measurement Theory in Software Engineering", Empirical Software Engineering: An international Journal, vol. 1, no. 1, pp., 1996. [128] G. Poels and G. Dedene, "Distance-based software measurement: necessary and sufficient properties for software measures", Information and Software Technology, vol. 42, no. 1, pp. 35-46, 2000. [129] S. Abraho, G. Poels, and O. Pastor, "A Functional Size Measurement Method for Object-Oriented Conceptual Schemas: Design and Evaluation Issues", Working Paper 2004/233, Faculty of Economics and Business Administration, Ghent University, Belgium March 2004. [130] G. Poels and G. Dedene, "Modelling and Measuring Object-Oriented Software Attributes with Proximity Structures", 3rd ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE'99), Lisbon, Portugal, 1999. [131] S. A. Whitmire, Object-Oriented Design Measurement, John Wiley & Sons, Inc., 1997, 452 p. [132] G. Poels and G. Dedene, "DISTANCE: A Framework for Sofware Measure Construction", Research Report 9937, Department of Applied Economics, Catholic University of Leuven 1999. [133] M. Genero, "Defining and Validating Metrics for Conceptual Models", PhD. Thesis, Departament of Informatics, University of Castilla-La-Mancha, Ciudad Real, Spain, 2002.
342
Bibliography
[134] G. Poels, "On the Formal Aspects of the Measurement of Object-Oriented Software Specifications", PhD. Thesis, Department of Applied Economic Sciences, Katholieke Universiteit Leuven, Belgium, 1999. [135] S. Abraho and O. Pastor, "Measuring the Functional Size of Web Applications", International Journal of Web Engineering and Technology, Inderscience Enterprises Ltd., England, vol. 1, no. 1, pp. 5-16, 2003. [136] P. Morris and J. M. Desharnais, "Function Point Analysis. Validating the Results", IFPUG Spring Conference, Atlanta, USA, 1996. [137] C. K. Riemenschneider, B. C. Hardgrave, and F. D. Davis, "Explaining Software Developer Acceptance of Methodologies: A Comparison of Five Theoretical Models", IEEE Transactions on Software Engineering, vol. 28, no. 12, pp. 1135-1145, 2002. [138] S. Abraho, G. Poels, and O. Pastor, "Comparative Evaluation of Functional Size Measurement Methods: An Experimental Analysis", Working Paper, Faculty of Economics and Business Administration, Ghent University, Belgium February 2004. [139] S. L. Pfleeger, "Understanding and Improving Technology Transfer in Software Engineering", Journal of Systems and Software, vol. 47, no. 2-3, pp. 111-124, 1999. [140] F. D. Davis, "Perceived Usefulness, Perceived Ease of Use and User Acceptance of Information Technology", MIS Quarterly, vol. 13, no. 3, pp., 1989. [141] G. E. Heilman and D. White, "On General Application of the Technology Acceptance Model", Working Paper 2001-9-WPS, University of Northen Colorado, Kenneth W. Monfort College of Business December 2001. [142] R. Johnson and B. Hardgrave, "Object-Oriented Systems Development: Current Practices and Attitudes in Industry", Journal of Systems and Software, vol. 48, no. 1, pp. 5-12, 1999. [143] P. P. Chen, "The Entity Relationship Model: Towards an Integrated View of Data", ACM Transactions on Database Systems, vol. 1, no. 1, pp. 9-36, 1976. [144] G. C. Simsion, "A Structured Approach to Data Modeling", The Australian Computer Journal, vol 21, no. 3, pp. 108-117, 1989. [145] T. J. Teory, G. Wei, D. L. Bolton, and J. A. Koenig "ER Model Clustering As An Aid For User Communication and Documentation in Database Design", Communications of the ACM, vol 32, no. 8, pp. 975-987, 1989.
343
Bibliography
[146] M. Gandhi, E. L. Robertson, and D. Van Gucht, "Levelled Entity Relationship Models", 13th International Conference on the Entity Relationship Approach, Manchester, England, 1994. [147] M. Fishbein and I. Ajzen, Beliefs, Attitude, Intention and Behavior. An Introduction to Theory and Research. Reading, MA, 1975, [148] D. A. Adams, R. R. Nelson, and P. A. Todd, "Perceived usefulness, ease of use, and usage of information technology: A replication", MIS Quarterly, vol. 16, no. 2, 227-247, 1992. [149] A. R. Hendrickson, P. D. Massey, and T. P. Cronan, "On the test-retest reliability of perceived usefulness and perceived ease of use scales", MIS Quarterly, vol. 17, no. 2, 227-230, 1993. [150] A. H. Segars and V. Grover, "Re-examining perceived ease of use and usefulness: A confirmatory factor analysis", MIS Quarterly, vol. 17, no. 4, 517-525, 1993. [151] G. H. Subramanian, "A replication of perceived usefulness and perceived ease of use measurement", Decision Sciences, vol. 25, no. 5/6, pp. 863-873, 1994. [152] B. Szajna, "Software evaluation and choice: predictive evaluation of the Technology Acceptance Instrument", MIS Quarterly, vol. 18, no. 3, pp. 319324, 1994. [153] T. Fenech, "Using perceived ease of use and perceived usefulness to predict acceptance of the World Wide Web", 7th International World Wide Web Conference (WWW7), Brisbane, Australia, 1998. [154] P. Schubert and W. Dettling, "Extended Web Assessment Method (EWAM) Evaluation of E-commerce Applications from the Customer's Viewpoint", 35th Annual Hawaii International Conference on System Sciences (HICSS'02), Big Island, Hawaii, 2002. [155] S. Taylor and P. A. Todd, "Understanding Information Technology Usage: A Test of Competing Models", Information Systems Research, vol. 6, no. 2, pp. 144-176, 1995. [156] F. D. Davis, "User Acceptance of Information Technology: System Characteristics, User Perceptions, and Behavioral Impacts", International Journal of Man Machine Studies, vol. 38, no. 3, 475-487, 1993. [157] K. Mathieson, "Predicting User Intention: Comparing the Technology Acceptance Model with the Theory of Planned Behaviour", Information Systems Research, vol. 2, no. 3, pp. 173-191, 1991. [158] N. Rescher, The Primacy of Practice. Oxford, Basil Blackwel, 1973,
344
Bibliography
[159] P. J. Hu and P. Y. K. Chau, "Examining the Technology Acceptance Model Using Physician Acceptance of Telemedicine Technology", Journal of Management Information Systems, vol. 16, no. 2, pp. 91-113, 1999. [160] R. Gupta and S. K. Gupta, "Object Point Analysis", IFPUG 1996 Fall Conference, Dallas, Texas, USA, 1996. [161] T. E. Hastings, "Software Size Measurement Foundations", Research paper, Monash University 1996. [162] S. A. Whitmire, "Applying Function Points to Object-Oriented Software Models", Software Engineering Productivity Handbook, J. Keyes, Ed.: McGraw-Hill, 1992, pp. 229-244. [163] J. Carver, L. Jaccheri, S. Morasca, and F. Shull, " Issues in Using Students in Empirical Studies in Software Engineering Education," 9th International Software Metrics Symposium (Metrics'03), Sydney, Australia, 2003. [164] M. Hst, B. Regnell, and C. Wohlin, "Using Students are Subjects - A Comparative Study of Students and Professionals in Lead-Time Impact Assessment", Empirical Software Engineering, vol. 5, 201-214, 2000. [165] S. Abraho and O. Pastor, "Estimating the Applications Functional Size from Object-Oriented Conceptual Models", International Function Points Users Group Annual Conference (IFPUG'01), Las Vegas, USA, 2001. [166] D. L. Moody, "Comparative Evaluation of Large Data Model Representation Methods: The Analyst's Perspective." International Conference on Conceptual Modeling (ER 2002), Tampere, Finland, 2002. [167] C. F. Kemerer, "Reliability of Function Points Communications of the ACM, vol. 36, no. 2, pp. 85-97, 1993. Measurement",
[168] S. D. Conte, H. E. Dunsmore, and V. Y. Shen, Software engineering metrics and models, The Benjamin/Cummings Publishing Company, Inc., 1986, [169] L. C. Briand, K. El Emam, D. Surmann, I. Wieczorek, and K. D. Maxwell, "An assessment and comparison of common software cost estimation modeling techniques", 21st International Conference on Software Engineering, 1999. [170] L. C. Briand and J. Wst, "The Impact of Design Properties on Development Cost in Object-Oriented Systems", 7th International Software Metrics Symposium (METRICS'2001), London, England, 2001. [171] R. K. Smith, J. E. Hale, and A. S. Parrish, "An Empirical Study Using Task Assignment Patterns to Improve the Accuracy of Software Effort Estimation", IEEE Transactions on Software Engineering, vol. 27, no. 3, pp. 264-271, 2001.
345
Bibliography
[172] E. J. Pedhazur and L. P. Schmelkin, "Measurement, Design and Analysis: An Integrated Approach", Lawrence Erbaum Associates Inc, Hillsdale, NJ 1991. [173] D. T. Campbell and D. W. Fiske, "Convergent and Discriminant Validation by the Multitrait-Multimethod Matrix", Psychological Bulletin, vol. 56, 1959, pp. 81-105. [174] J. Nunally, Psychometric Theory, 2nd ed. ed. New York, NY, McGraw-Hill, 1978, [175] R. D. Caplan, R. K. Naidu, and R. C. Tripathi, "Coping and defense: Constellations vs. Components", Journal of Health and Social Behavior, vol. 25, 303-320, 1984. [176] J. E. Bailey and S. W. Pearson, "Development of a tool for measuring and analyzing computer user satisfaction", Management Sciences, vol. 29, no. 5, pp. 530-545, 1983. [177] P. H. Cheney, R. I. Mann, and D. L. Amoroso, "Organizational factors affecting the success of end-user computing", Journal of Management Information Systems, vol. 3, no. 1, 65-80, 1986. [178] I. Torres and F. Calatrava, "Function Points Counting on Conceptual Models": Whitepaper, CARE Technologies, http://www.caret.com/html/whitepapers.html, 2003. [179] "Total Metrics, Total Metrics - Levels of Counting", Australia August 2001. [180] E. E. Rudolph, "Productivity in computer application development", Working paper 9, Department of Management Studies, University of Auckland, New Zealand 1983. [181] J. M. Desharnais, "Analyse statistique de la productivite des projets de developpement en informatique a partir de la technique des points de fonction (Enghish version)." Masters thesis, Universit du Quebec, Montreal 1988. [182] G. Fitzgerald, Validating New Information Retrospective Analysis, North-Holland, 1991, [183] ISBSG, "International http://www.isbsg.org. Software Systems Techniques: A
Benchmarking
Standards
Group".
346
Appendix A
Experimental Materials
In this appendix, we present all the material used in the experiments of this thesis. First, we present the material related to the comparison between IFPUG FPA and OOmFP (the first experiment) and then, the material related to the evaluation of OOmFPWeb (the second experiment).
A1. The First Experiment

The material of this experiment consists of a software requirements specification (SRS) of a case study, the IFPUG FPA and OOmFP measurement guidelines. These materials are presented below:
Software Requirements Specification (SRS)

This document is a specification of software requirements for the Project Management System (PMS) of a software development company. This specification has been structured according to the directives given by the standard IEEE Recommended Practice for Software Requirements Specification ANSI/IEEE 830 1998.
1 Introduction
1.1 Purpose of the system
The object of the specification is to define in a clear way all the functionalities and constraints of the system. The intention of the PMS is to provide computerized
Appendix A. Experimental Materials (First Experiment)
management for the control of the projects and tasks of a software development company as well as to control the time spent for each employee on each one of his/her assigned tasks.
1.2 Scope of the system

The product to be developed will comprise one of the management systems of a software development company. This system is intended to manage the tasks developed by the employees of the company as well as the time dedicated by each employee to the tasks that she/he has been assigned. The product shall allow users to: Manage projects, tasks and employees: in this section all the management related to the projects and their associated tasks will be covered, such as the creation of new projects, creation of new tasks for projects, elimination of tasks or projects, creation or discharge of new employees, etc.) Monitor tasks and projects: knowledge of the situation of each project or each employee, i.e., a control of the time that is spent on each project, or the time spent by an employee on a project, with the purpose of being able to establish future planning or to verify that the established planning is being followed. This section includes inquiries on projects, employees, etc.
1.3 Definitions, acronyms and abbreviations

Definitions: o Project: A temporary process, which has a clearly defined start and end time, a set of tasks, which is developed to create a product. o Tasks Type: Brief description of the tasks that make up a project. A task type can be created when a project is created. o Task: Represents the work that an employee performs within a project. It is associated to a task type. o Employees: Set of people who carry out the projects. Abbreviations: o PMS: Project Management System o IEEE: Institute of Electrical & Electronics Engineers. o DB: Database.
1.4 References
IEEE Std 830-IEEE Guide to Software Requirements Specifications. IEEE Standard Board.
348
2. Overall Description
This section describes the factors that affect the product to be developed and its requirements:
2.1 Product Perspective

The product to be developed should be able to work correctly in any company. It is an independent application intended to execute on any compatible computer IBM-PC that supports Windows 98 or superior.
2.2 Product Functions

The product functions are divided into six groups: a. PMS access control b. c. d. Access control to the system Change access profile Create project type Delete project type Modify project type description Project type inquiry Assign project type Create project Assign employee in charge Delete employee in charge Delete project Modify project description Modify project start date Project inquiry Assign end date to a project Calculate project duration Close project Create task type Delete task type Modify task type description Task type of a project inquiry Assign task type to a project
Project type maintenance
Project maintenance
Task type maintenance
349
e.
Task maintenance Create task Delete task Modify the start date of a task Modify the end date of a task Modify the duration of a task Create employee Delete employee Modify employee password Promote employee Demote employee Employee inquiry Employees tasks by period inquiry Employees tasks by project inquiry Employees tasks by task type inquiry
f.
Employee maintenance
2.3 User Characteristics

This section describes the features of the user community (kind of users), including their expected expertise with software systems and the application domain. We consider a user of the PMS to be a person who is registered in the system and can execute any one of its functionalities. Three kinds of users can access the PMS: Employees, the employee in charge and the manager. Employees are the people who work on the different projects maintained by the company. They can register, modify or delete their tasks on all of the projects that they participate in daily. Each employee can only have access to his/her tasks. An employee can be promoted to an employee in charge. This kind of user can create, modify or delete employees and projects as well as perform their tasks as an employee. An employee in charge can access all the functionalities of the employee user. In addition, he/she can also modify the password of an employee, create and delete tasks. The manager can promote an employee to an employee in charge. This kind of user can also create, delete or modify task types, assign or remove an employee in charge of a project, or demote an employee in charge. In fact, he/she can access all the functionalities of the PMS.
2.4 Constraints
It is mandatory to maintain the efficiency of the system, the format of the information entrance and the measurement systems and standards used such as the hour format, the work zone, etc. The system will have to control the access of the different user
350
types. In addition, it is recommended to maintain the initial hardware in the same condition as the system implantation.
2.5 Assumptions and Dependencies

2.5.1. Assumptions The Project Management System will run on the Windows platform. Therefore, it should follow the Microsoft Windows application programming interface (API). 2.5.1. Dependencies The PMS works independently, with no need to communicate with other external systems, this is why there are no dependencies with respect to other systems.
3 Specific Requirements
3.1 Functional Requirements
This section lists the functional requirements in ranked order. Functional requirements describe the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements. 1. Access Control to the System 2. Introduction: A validation of the user access to the system is required. Entrance: employees login id and the password. Process: The system will have to verify the user type of the employee who wishes to access the system (Employee, Employee in charge or Manager) and to validate his/her access to the PMS. Exit: Depending on the user type, the functions that he/she will be able to execute will appear.
Change Access Profile Introduction: This function is used to change the user profile to access the system. It can be performed by any user of the system. Entrance: employees login id and the password. Process: The system will have to verify the user type of the employee who wishes to access the system and to validate his/her access.
351
3.
Exit: Depending on the user type, the functions that he/she will be able to execute will appear.
Create Project Type Introduction: This function creates a new project type. Currently, there are three project types: conceptual modeling, implementation and consulting. Entrance: identifier number and the description of the new project type. The identifier number is constant but its description can change. Process: This function must verify whether or not the new project type exists. Then, the new project type will be inserted in the D.B. Exit: New project type created.
4.
Delete Project Type Introduction: This function allows the elimination of a project type that is not desired to be maintained in the PMS. Entrance: identifier number. Process: This function will verify that the project type exists before deleting it. Exit: Project type deleted.
5.
Modify Project Type Description Introduction: This function allows changes in the description of a project type. Entrance: identification number of the project type to be modified and the new description. Process: The function will verify the existence of the project type description associated to the identifier number being entered into the PMS. If the description exists, the new description will replace it. Exit: The project type is updated.
6.
Project Type Inquiry Introduction: This inquiry gives the project type details. Entrance: project type identifier number Process: Search for all the projects that match the project type identifier number. Exit: Data about project types are shown.
352
7.
Assign Project Type Introduction: This function assigns new project types that will be made in a project. Entrance: project identifier number and project type identifier number. Process: This function will assign the project type to the project whose identifier number has been introduced. Exit: The project is associated to a project type.
8.
Create Project Introduction: When the company starts a new project the employee in charge of the project must enter the data in the system. Entrance: A project is created with the following information: identifier number description starting date employee in charge of the project estimated duration (in hours) estimated ending date current duration (in hours, which is calculated as the sum of the duration of all tasks performed until now) cost (sum of all tasks costs associated to the project), state (0=opened, 1= closed) situation (0 = under development, 1 = small delay (<10% more than the estimated time), 2 = large delay (>= 10% more than the estimated time) 3 = finished) observations Process: This function must verify that the project being created does not exist. Exit: New project created.
9.
Assign Employee in Charge Introduction: This function assigns an employee in charge to a project. Entrance: login id and the password of the employee in charge of the project and the project identifier number. Process: This function will assign the employee in charge to the project whose identifier number has been introduced. Exit: The employee in charge is associated to a project.
353
10. Delete Employee in Charge Introduction: This function removes an employee in charge of a project. Entrance: password of the employee in charge and project identifier number. Process: The manager of the company removes an employee in charge of a project from his/her responsibility only after the first work month. The employee in charge cannot be eliminated while he/she is assigned to an open project. The possible error messages are: invalid password, employee not found, and employee in charge has been working on the project less than 30 days. Exit: The employee in charge of the project has been removed from his/her responsibility.
11. Delete Project Introduction: This function deletes an existing project of the PMS. It can only be performed for the employee in charge of the project or the manager of the company. Entrance: project identifier number. Process: The function will verify that the project exists before deleting it. The related tasks will also be deleted. Exit: The project and their tasks have been deleted.
12. Modify Project Description Introduction: This function modifies the description of an existing project in the PMS. It can only be performed by the employee in charge of the project or by manager of the company. Entrance: project identifier number and the new project description. Process: This function will have to find the project whose identifier number has been entered into the PMS and to replace its description with the new description. Exit: The description of the project has been changed.
13. Modify Project Start Date Introduction: This function modifies the starting date of an existing project in the PMS. It can only be performed by the employee in charge of the project or by manager of the company. Entrance: project identifier number to be modified and the new project starting date.
354
Process: This function will have to find the project whose identifier number has been entered into the PMS and to replace its starting date with the new starting date. Exit: The starting date of the project has been changed.
14. Project Inquiry Introduction: Information about the projects being developed in the company needs to be queried. Entrance: project identifier number, employee login id or situation. Process: The system will search and present all projects that exist in the database. The possible error messages are: invalid project identifier, project not found. Exit: All data associated to the projects will be presented.
15. Assign End Date to a Project Introduction: This function assigns an estimated end date to a project. It can only be performed by the employee in charge of the project or by the manager of the company. Entrance: project identifier number to be modified and the project ending date. Process: The function will find the project whose identifier number has been entered into the PMS. Then, the ending date being entered is assigned to the project. Exit: The ending date of the project has been assigned.
16. Close Project Introduction: This function closes an open project. Only the manager of the company or the employee in charge of the project can close a project. Entrance: project identifier number. Process: This function searches for the project whose identifier number is being entered. Then, the end date of the project is updated with the current date. Exit: The project has been closed.
17. Create Task Type Introduction: There is the need to create new task types in the company. Currently, there are eight task types: requirements specification, conceptual modeling, coding, testing, implantation, maintenance, training, and customer support.
355
Entrance: identifier number, description, cost per hour and observations. Process: This function must verify whether or not the new task type exists. Then, the new task type will be inserted in the D.B. Exit: New task type created.
18. Delete Task Types 19. Introduction: This function deletes an existing task type of the PMS. Entrance: task type identifier number. Process: The function will verify whether the task type exists before deleting it. Exit: The task type has been deleted.
Modify Task Type Description Introduction: This function modifies the description of an existing task type in the PMS. Entrance: identifier number of the task type to be modified and the new task type description. Process: This function will have to find the task type whose identifier number has been entered into the PMS and to replace its description with the new description. Exit: The description of the task type has been changed.
20. Task Type of a Project Inquiry Introduction: This inquiry gives the task type details associated to a given project. Entrance: project identifier number. Process: The PMS will search all the task types associated to the project. Exit: The list of task types of the project is shown.
21. Assign Task Types to a Project Introduction: This function assigns new task types that will be made within a project. Entrance: Project identifier number and task type identifier number. Process: This function will assign the task type to the project whose identifier number has been introduced. Exit: The project is associated to a task type.
356
22. Create Task Introduction: This function allows the employees to create the daily tasks to be performed in the different projects of the company. Each task will have an employee in charge. Once a task has been created with an employee in charge, he/she could not be changed. Entrance: Project identifier number, task number (constant), task type, description, start date, end date, duration (in hours), cost (calculated taking into account the duration and the task type), the employees in charge login id. In the task types of "maintenance" and "training" the cost of the task is calculated in a different way. In addition, the task type maintenance has the following information: displacement kilometers, cost by kilometer and place. These data will have to be registered in the task and must be considered for the calculation of the task cost. In addition, the task type training has the number of people to train and the training cost per person that must be registered into the task. It also will be used for the calculation of the task cost. Process: It must be verified whether the start date is smaller (or equal) than the end date. It must be also verified that decimals are not entered in the duration. The system will create a new task with the data entered. If the end date of a task is greater than the estimated end date of the project, the company must try to finish the project as soon as possible. For this reason, all the tasks must have a duration greater than two hours (except if they are of the type customer support). The sum of the task durations of a project must be inferior to the estimated project duration. Exit: A new task is inserted into the PMS. An identifier number is associated with it.
23. Delete Task Introduction: The employee in charge of the project or the manager of the company uses this function to delete a task from the PMS. Entrance: employee password and the identifier number of the task to be deleted. Process: The system will verify that the task is associated to the employee, whose password is being entered into the system before deleting it. Exit: The task is deleted.
357
24. Modify the Start Date of a Task Introduction: This function allows the modification of the start date of a task. The task duration including the start and end dates can only be modified by the employee in charge of the project or by the manager of the company (not by the employee in charge of the task). The employee in charge of the task will only be able to modify the description of the task. Entrance: password of the employee, task identifier number and the new start date. Process: The system will verify that the task is associated to the employee whose password is being entered. Then, the start date will be changed for the new date being entered into the PMS. Exit: The task start date is modified.
25. Modify the End Date of a Task Introduction: This function allows the modification of the end date of a task. The tasks duration including the start and end dates can only be modified by the employee in charge of the project or by the manager of the company (not by the employee in charge of the task). The employee in charge of the task will only be able to modify the description of the task. Entrance: password of the employee, task identifier number and the new end date. Process: The system will verify that the task is associated to the employee whose password is being entered. Then, the end date will be changed for the new date being entered into the PMS. Exit: The task end date is modified.
26. Modify the Duration of a Task Introduction: This function allows the modification of the duration of a task. The task duration including the start and end dates can only be modified by the employee in charge of the project or by the manager of the company (not by the employee in charge of the task). The employee in charge of the task will only be able to modify the description of the task. Entrance: password of the employee, task identifier number, and the new task duration. Process: The system will verify that the task is associated to the employee whose password is being entered. Then, the duration will be changed with the new duration being entered into the PMS. Exit: The task duration is modified.
358
27. Employee's Tasks Inquiry Introduction: This function allows the retrieval of all the tasks that an employee has introduced into the PMS. This information can be used to verify whether the employees have correctly introduced the hours that they worked on the projects. Entrance: password of the employee. Process: The system will look for all the tasks of the employee. Exit: The tasks of the employee are shown.
28. Create Employee Introduction: This function creates a new employee. There are three kinds of employees: employee, employee in charge, and manager. Entrance: login id, password, fullname, and start date. Process: This function must verify whether the new employee exists or not. Then, the new employee will be inserted in the D.B Exit: The new employee is introduced into the PMS.
29. Delete Employee Introduction: This function deletes an employee of the PMS. Entrance: login id Process: The function will verify that the employee exists before deleting it. The employee in charge cannot be eliminated while he/she is assigned to an open project. Exit: The employee is deleted.
30. Modify Employee Password Introduction: This function modifies the password of an employee in the PMS. Entrance: the employees login id, the old password and the new password. Process: The system will replace the old password for the new one. To do this, the employee should type the password twice to ensure that the correct password is entered. Exit: The employee password is changed.
31. Promote Employee Introduction: The manager of the company uses this function to promote an employee.
359
Entrance: login id Process: The system will search and change the category of the employee. The possible error message is: invalid login id, employee not found. Exit: The category of the employee is changed.
32. Demote Employee Introduction: The manager of the company uses this function to demote an employee. Entrance: login id Process: The system will search and change the category of the employee. The possible error messages is: invalid login, employee not found. Exit: The category of the employee is changed.
33. Employee Inquiry Introduction: This inquiry gives the employee details. Entrance: login id Process: The system will search and present all employees of the company. The possible error messages are: invalid employee-id, employee not found. Exit: The employees of the company will be shown.
34. Employees Tasks by Period Inquiry Introduction: This function allows the retrieval of the tasks that an employee has introduced in the PMS within a given time interval. Entrance: login id of the employee and the time interval (start and end dates) Process: The system will search for all the tasks whose employee id matches the identifier being entered into the PMS and whose dates are within the requested interval. Exit: The tasks of the employee that are within a time interval will be shown.
35. Employees Tasks by Project Inquiry Introduction: This function shows a list of all the tasks performed by an employee in a given project. Entrance: login id of the employee and the project identifier number
360
Process: The system will search for all the tasks whose employee login id and project identifier match the ones being entered. Exit: The employee task per project is shown.
36. Employees Tasks by Task Type Inquiry Introduction: This inquiry shows a list of all the tasks performed by an employee in a project and a given task. Entrance: login id of the employee, project identifier number, and the task type identifier number. Process: The system will search for all the tasks that have the same task type in a project for one employee. The possible error messages are: invalid login id, invalid project identifier, invalid task type, project not found. Exit: The employee tasks classified by task type are shown.
3.2 External Interface Requirements

User Interfaces This section describes how the software interfaces with other software products or users for input or output. The following recommendations should be taken into account: Access to the functionality of the PMS should be restricted based on the user type. The PMS should be designed for screen resolution of 800 x 600 pixels. Arial font should be used across the application. Terminology used in the application should be easily understandable by the user. All application forms performing similar functionality should have consistent Look & Feel (same order and color for the elements, same images for functions etc.). Appropriate alternate text should be provided for all the images, to help in the readability. Completion/Confirmation messages should be displayed when the PMS processes the data successfully. Error messages should be displayed when the PMS processes the data unsuccessfully.
361
Hardware Interfaces PMS should be implemented in a hardware-independent fashion and should not rely on any particular hardware interfaces. Software Interfaces No software interfaces for the PMS are necessary.
362
Appendix A. Experimental Materials (First Experiment) Function Point Analysis (FPA) - Measurement Guideline The measurement process of FPA is made according to the following steps: 1. 2. 3. 4. 5. 6. 7. Determine the Type of Function Point Count Identify the Counting Scope and Application Boundary Count Data Functions Count Transactional Functions Determine Unadjusted Function Point Count Determine Value Adjustment Factor Calculate Adjusted Function Point Count 1. 2. 3. Development project function point count Enhancement project function point count Application function point count The boundary is determined based on the users view. STEP 3. Count Data Functions Data functions represent the functionality provided to the user to meet internal and external data requirements. There are two types of data functions: Internal Logical File (ILF) It is a user identifiable group of logically related data or control information maintained within the boundary of the application. Identification Rules: The primary intent of an ILF is to hold data maintained through one or more elementary processes29 of the application being counted.
We describe here only the first type of count. It measures the functions provided to the users with the first installation of the software delivered when the project is completed. STEP 2. Identify the Counting Scope and Application Boundary The counting scope defines the functionality which will be included in a particular function point count. Identification Rule: A development function point count includes all functions impacted by the Project activities. The application boundary indicates the border between the software being measured and the user. Identification Rule:
Given the purpose of this course, we use the unadjusted function point count. Hence, only the steps 1 til 5 are described. STEP 1. Determine the Type of Function Point Count Function point counts can be associated with either projects or applications. There are three types of function point counts:
An elementary process is the smallest unit of activity that is meaningful to the user(s).
29
363

External Interface File (EIF) It is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. Identification Rules: The primary intent of an EIF is to hold data referenced through one or more elementary processes of the application being counted. An EIF counted for an application must be in an ILF in another application. Determine the amount of DETs and RETs for each identified ILF and EIF: DET: a unique user recognizable, nonrepeated field RET: user-recognizable subgroup of data elements within an ILF or EIF. There are two types: Optional: are those that the user has the option of using one or more of the subgroups. Mandatory: are subgroups where the user must use at least one. Counting Rules for DETs of an ILF: 1 DET for each unique user recognizable, non-repeated field maintained in or retrieved from the ILF or EIF through the execution of an elementary process When two applications maintain and/or reference the same ILF/EIF, but each maintains/references separate DETs, count only the DETs being used by each application to size the ILF/EIF. Count a DET for each piece of data required by the user to establish a relationship with another ILF or EIF. Counting Rules for DETs of an EIF: One of the following rules applies when counting RETs: 1 RET for each optional or mandatory subgroup of the ILF or EIF, or If there are no subgroups, count the ILF or EIF as one RET. Determine the complexity level of the identified data functions using this table: Complexity table for ILFs and EIFs
RETs 1 2-5 6+ 1-19 DETs Low Low Average 20-50 DETs Low Average High 51 + DETs Average High High
Count Transactional STEP 4. Functions Transactional functions represent the functionality provided to the user to process data. They are either EI, EO or EQ. External Input (EI) It is an elementary process that processes data or control information that comes from outside the applications boundary. Identification Rules: The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.
364

External Output (EO) It is an elementary process that sends data or control information outside the applications boundary. Identification Rules: The primary intent of an EO is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, or create derived data. An EO may also maintain one or more ILFs and/or alter the behavior of the system. External Inquiry (EQ) It is an elementary process that sends data or control information outside the application boundary. Identification Rules: The primary intent of an EQ is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered. The next table summarizes the features of the transactional functions (m=mandatory,
m*=mandatory at least one of these features, c= can perform, n= cannot perform).
Assign to each identified EI, EO, and EQ a functional complexity based on: DET: a unique user recognizable, nonrepeated field FTR: an ILF read or maintained by a transactional function or an EIF read by a transactional function. Counting Rules for DETs of an EI: 1 DET for each user recognizable, non-repeated field that enters or exits the application boundary and is required to complete the EI. Do not count fields that are retrieved or derived by the system and stored on an ILF during the elementary process if the fields did not cross the application boundary. 1 DET for the capability to send a system response message outside the application boundary to indicate an error occurred during processing, confirm that processing is complete or verify that processing should continue. 1 DET for the ability to specify an action to be taken even if there are
Function Type Form of Processing Logic EI EO EQ Mathematical formula and c m* n calculations are performed At least one ILF is updated m* m* n At least one ILF or EIF is c c m referenced Data or control information c c m is retrieved Derived data is created c m* n Behavior of the system is m* m* n altered Prepare and present inform. c m m outside the boundary Capability to accept data or m c c control inform. that enters the application boundary
365

multiple methods for invoking the same logical process. Determine the complexity level of the identified EIs using the following table: Complexity table for EIs
FTRs 0-1 2 3+ 1-4 DETs Low Low Average 5-15 DETs Low Average High 16 + DETs Average High High
Shared DET Rules for EOs and EQs: 1 DET for each user recognizable, non-repeated field that enters the application boundary and is required to be retrieved or generated by the elementary process. 1 DET for each user recognizable, non-repeated field that exits the boundary. If a DET both enters and exits the boundary, count it only once for the elementary process. 1 DET for the capability to send a system response message outside the application boundary to indicate an
error occurred during processing, confirm that processing is complete or verify that processing should continue. 1 DET for the ability to specify an action to be taken even if there are multiple methods for invoking the same logical process. Do not count fields that are retrieved or derived by the system and stored on an ILF during the elementary process if the fields did not cross the application boundary. Do not count literals as DETs. Do not count paging variables or system-generated stamps. Shared FTR Rules for EOs and EQs: 1 FTR for each ILF or EIF read during the processing of the elementary process. Additional FTR Rules for an EO: 1 FTR for each ILF maintained during the processing of the elementary process. 1 FTR for each ILF that is both maintained and read during the elementary process.
Determine the complexity level of the identified EIs using the following table: Complexity table for EOs and EQs
FTRs 0-1 2-3 4+ 1-5 DETs Low Low Average 6-19 DETs Low Average High 20 + DETs Average High High
STEP 5. Determine Unadjusted Function Point Count Now, uses the following table to obtain the unadjusted function point count:
TYPE Low Aver. High EI __x3 __x4 __x6 EO __x4 __x5 __x7 EQ __x3 __x4 __x6 ILF __x7 __x10 __x15 EIF __x5 __x7 __x10 Unadjusted function point count = Total
Reference:
Function Point Counting Practices Manual, Release 4.1. 1999, International Function Point Users Group: Westerville, Ohio, USA.
366

OO-Method Function Points (OOmFP) Measurement Guideline 4. Given a conceptual schema CS produced in the OO-Method conceptual modeling phase, OOmFP is calculated as follows: 5. measuring the transactional functions (OOmFPT). Levels of complexity for functions are translated into values using IFPUG tables. The sum of values produces the functional size of a Web application (non-adjusted OOmFP). STEP 2. Sizing Data Functions The measurement of data functions is made using the Object Model and includes two activities: the identification of the functions and the determination of its complexity. Please, identify ILFs and EIFs by applying the following rules: Identification Rule for ILF: Accept each class (with agent relationships) as an ILF. A class encapsulates a group of data (attributes) which represent the objects state of the class. Reject classes that have no DET. Identification Rule for EIF: Accept each legacy view (with agent relationships) as an EIF. A legacy view encapsulates a group of data (attributes) which represent the objects state of the legacy view. It represents an external functionality of the system.
OOmFP = OOmFP D + OOmFP T

Where, OOmFPD is the size related to the data logical functions, and OOmFPT is the size related to the transactional logical functions. The measurement process is according to the following steps: 1. 2. 3. made
The Object Model is analyzed to determine the system boundary and the measuring scope. The Object Model is used for measuring the data functions (OOmFPD). The Object, Dynamic, Functional and Presentation Models are used for
STEP 1. Identifying the Measurement Scope and the System Boundary The measurement scope defines the functionality which will be included in a particular measurement. It includes the functionality captured in the four OOMethod conceptual schema views. The system boundary indicates the border between the software being measured and the user. To identify the system boundary uses the Object Model, and apply the following rules: Consider each agent as a user type of the system. Consider each legacy view as an external system.
367

Reject legacy views that have no DET. Determine the amount of DETs and RETs for each identified class and legacy view: DET: a unique user recognizable, nonrepeated field. It can be a data-valued attribute of a class or legacy view. RET: user-recognizable subgroup of data elements within a class or legacy view. Measurement Rules for DETs of a Class: 1 DET for each data-valued attribute of the class 1 DET for each attribute in the Identification Function (IF)30 of a class or legacy view referenced in a univalued aggregation relationship. 1 DET for each attribute in the IF of the superclasses of a class. Measurement Rules for RETs of a Class: 1 RET for the class. 1 RET for each multivalued aggregation relationship (class or legacy view). Measurement Rules for DETs of a Legacy View: 1 DET for each non-derived attribute of the legacy view 1 DET for each attribute in the IF the class related to by a univalued aggregation Measurement Rules for RETs of a Legacy View: 1 RET for the legacy view. 1 RET for each multivalued aggregation relationship with a class. Determine the complexity for identified class and legacy view: each Complexity - Classes and Legacy View RETs 1-19 20-50 DETs 51 + DETs DETs 1 Low Low Average 2-5 Low Average High 6+ Average High High STEP 3. Functions Sizing Transactional
The measurement of the transactional functions is made using the Object, Dynamic, Functional and Presentation conceptual models. It includes two activities: identification of the functions and the determination of their complexity. Reglas de Identificacin de EIs: Identification Rule for EI: Accept each unique class service in the Object Model (with agent relationships) as an EI. A service changes the state of the objects of a class or legacy view, altering the behavior of the system.
30 Composed by constant attributes that identifies the objects of a class.
368

Hints for identifying EIs: An event or transaction are measured only once (in the class in which they are declared), even if they are inherited by several subclasses. Shared events must measured only once (in any class in which they are declared). Reject event or transactions that are not activated by any client class. Identification Rules for EO and EQ: Accept each unique Instance Interaction Unit (IIU) pattern of a Presentation Model as an EO, only if it includes some derived attribute or performing some calculation. If not, it can be considered as an EQ. Its main intention is to define the information that will be presented to the user, the actions that must be supplied on the object and the additional information that can be consulted. Accept each unique Population Interaction Unit (PIIU) pattern of a Presentation Model as an EO, only if it includes some derived attribute or performing some calculation. If not, it can be considered as an EQ. Its main intention is to present information to the user and to provide mechanisms (filtering and ordering) that facilitate the selection and consultation of objects. Accept each unique Master-Detail Interaction Unit (MDIU) pattern of a Presentation Model as an EO, only if it includes some derived attribute or performing some calculation. If not, it can be considered as an EQ. Its main intention is to present information using the logical components master /detail. The information presented in the part details depend on the information of the master part. Determine the amount of DETs and FTRs for each service and presentation pattern: DET: a unique user recognizable, nonrepeated field. It can be an attribute or a data-valued argument. FTR: subgroup of logical data referenced/maintained by a transactional function. It can be a class referenced or maintained by a service or a presentation pattern. Measurement Rules for DETs of a Class Service: 1 DET for each data-valued argument of the service. 1 DET for the capability of the application to send messages 1 DET for the action (Accept/Cancel) of the service execution. Measurement Rules for FTRs of a Class Service: 1 FTR for the class in which the service is declared.
369

1 FTR for each new31 class referenced in the object-valued argument of the service (only if it is different of the class service). If integrity constraints are defined, count one FTR for new class referenced in the formula. [constraint] 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 [when clausule]32 If a specialization by event is defined (carrier/liberator event), count one FTR for each new class for which the event is a carrier/liberator. If a value by default is defined, count one FTR for new class referenced in the formula.
31
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, defined in the Interaction Diagram. [triggers] 1 FTR for each new class referenced in the formula of a precondition, defined in the State Transition Diagram. [preconditions] Measurement Rules for DETs of a Legacy View Service: 1 DET for each data-valued argument of the service. 1 DET for the capability to send messages (control, error, etc). 1 DET for the action (Accept/Cancel) of the service execution. Measurement Rules for FTRs of a Legacy View Service: 1 FTR for the legacy view in which the service is declared.
If integrity constraints are defined, count one FTR for new class referenced in the formula. 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, defined in the Interaction Diagram. 1 FTR for each new class referenced in the formula of a precondition, defined in the State Transition Diagram Determine the complexity for each class and legacy view services: Complexity L. view and classes services FTRs 1-4 5-15 16 + DETs DETs DETs 0-1 Low Low Average 2 Low Average High 3+ Average High High
New in this context means that the class was not counted yet 32 [ ] session in the OASIS specification
370

Measurement Rules for DETs of an Instance Interaction Unit: 1 DET for each attribute of an Object Identifier (OID).
1 DET for each attribute in the display set (only if it is different from the attribute(s) of an OID ). 1 DET for each offered action (by default all class or legacy view services). 1 DET for each offered navigation (by default all inheritance or aggregation relationships in which the class or legacy view participates) 1 DET for the system capacity to present messages (error, control, etc.).
Measurement Rules for FTRs of an Instance Interaction Unit:
1 DET for each data-valued unique variable in a filter formula. 1 DET for each attribute in the display set (only if it is different from the attribute(s) of the filter). 1 DET for each offered action (by default all class/legacy view services). 1 DET for each offered navigation (by default all inheritance or aggregation relationships in which the class or legacy view participates). 1 DET for the system capacity of presenting messages (error, control, etc.) .
Measurement Rules for FTRs of a Population Interaction Unit:
1 FTR for each new class referenced in the filter formula.

1 FTR for each class referenced in a complementary information pattern of a object-valued filter variable. Measurement Rules for Master-Details Interaction Units: Measurement rules for the Master part If it is an IIU, apply the measurement rules for DETs and FTRs of an Instance Interaction Unit. If it is a PIU, apply the measurement rules for DETs and FTRs of a Population Interaction Unit. Measurement rules for the Detail part If it is an IIU, apply the measurement rules for DETs and FTRs of an Instance Interaction Unit. If it is a PIU, apply the measurement rules for DETs and FTRs of a Population Interaction Unit. If it is a MDIU, apply the same measurement rules for IIUs and PIUs described here.
1 FTR for each class or legacy view in the display set.

Measurement Rules for DETs of a Population Interaction Unit:
1 FTR for each class or legacy view in the display set. 1 FTR for each unique objectvalued attribute of a filter. 1 FTR for each new class referenced in the ordering criteria.
371

Determine the complexity for each identified presentation pattern by using the following table: Complexity - IIUs, PIUs and MDIUs
FTRs 1-5 DETs 0-1 Low 2-3 Low 4+ Average
6-19 DETs Low Average High
20 + DETs Average High High
TYPE Classes L. Views Services IIUs PIUs MDIUs
Low __x7 __x5 __x3 __x3 __x3 __x3
Average __x10 __x7 __x4 __x4 __x4 __x4
High Total _x15 _x10 __x6 __x6 __x6 __x6
STEP 4. Translating the Complexity Levels into Values This step is made using the weights proposed by the International Function Point Users Group (IFPUG). These weights are summarized in the following table:
STEP 5. Calculating OOmFP The sum of the values obtained for data and transaction functions results in the functional size of an object-oriented system (non-adjusted OOmFP).
372
Appendix A. Experimental Materials (Second Experiment)
A2. Second Experiment

The material of this experiment consists of an OOWS conceptual schema specification, the OOmFPWeb measurement guidelines, and a form to collect the data.
OOWS Conceptual Schema Specification

1. Requirements Specification
A Photography Agency manages illustrated features for their distribution to Press Agencies. The Photography Agency works with photographers which are free professionals (they are not agencys employees). A photographer that wants to work with the agency present an application form to the Technical Department including: personal data, its photographic equipment characteristics, a brief curriculum vitae and a "book" with several previous works (features). Photographers are classified in three levels of quality, and for each level minimum photographic equipment characteristics are required. The Commercial Department at the beginning of every year fixes the price per photography for each level and specifies the amount of money to be paid to the photographers and the amount of money which will be retained by the Press Agencies. An Agency Management Team meeting (compound of a person from each one of the departments) takes place every Monday morning. After the general meeting, and if there are applications forms of photographers they proceeded to their evaluation. Depending on the photographers documentation he or she is classified in the corresponding level and the application is accepted or refused. After the meeting, the Technical Department is in charge of communicating the evaluation result of the application forms to the corresponding photographer sending a letter to him or her. If he or she has been accepted, a photographer record is created in the photographers file. When a photographer delivers a feature, a feature record is opened assigning to it a sequential code and setting the price for the Press Agency (depending on the number of photos and depending on the established rate for their level). Also, in the record we store an annotation from predefined descriptors about the content of the feature. If Press Agencies want to work with the Photography Agency must be subscribed before. Usually they go to the Agency where an employee of the commercial department explains them the way of work, the type of features that are prepared and the used rates. If the Press Agency is interested, a record is opened and a
373
payment is made as a subscription fee. With this subscription fee the Press Agencies receive information of available features on a topic or on a determined event. When a Press Agency is interested in a feature, they call to the agency requesting information. The Press Agency is attended by the Production Department that searches for features considered more interesting related to the requested theme. A listing with the description of the features on a determined topic is sent by fax (if necessary). The Press Agency, after reading the listing that has received, asks for the features that are interested in by phone. When a Press Agency asks for a feature, the Photography Agency sends the feature by courier with their corresponding delivery notes that will be signed by the Press Agency. The courier returns the signed delivery notes to the Photography Agency that will be used for billing. Occasionally, the Press Agency asks for exclusive features in topics that are not covered by the Agency. The Press Agency specifies the price that they could pay for the exclusive. Technician Department attends each exclusive feature request and then opens a record for the exclusive feature assigning it a code and recording the data of the feature. A copy of the record is left in the notice board. The photographers are in permanent touch with the agency, for the delivery of features or to see the exclusive features that were solicited by Press Agencies. If any photographer is interested in an exclusive, he or she gets the record from the notice board and goes to the Technical Department to be assigned to it. Each exclusive feature is assigned to just one photographer and he or she is supposed to finish it in order to be assigned to another exclusive feature. When the exclusive feature is assigned to a photographer, a copy of the exclusive feature record is given to him/her for its later identification. When a photographer finishes an exclusive feature, it is delivered to the Production Department with the copy of the exclusive feature record. This department registers the delivery date and emits a nominal check for the 40% of the price of the exclusive feature (that it is the part that corresponds to the photographer). The Agency sends the exclusive feature to the Press Agency with the delivery note by courier. Once delivered, the courier returns the signed delivery note to the Commercial Department. The Commercial Department, at the beginning of every month proceeds to check all the delivery notes to send one invoice to the corresponding Press Agency with the amount of the features and exclusive features requested. Also, every month is proceeded to pay to photographers for sold features. In order to prepare this payment, the delivery notes for each photographer are revised and the corresponding rates are applied. Finally, a nominal check for the total amount of the commissions is emitted in order to be sent to the photographer.
374
2. OOWS Conceptual Schema Specification

1.1 Modelo de Objetos
Agent Classes
Suppose that the class User can activate all services that exist in the other classes. Client class User Server class ApplicationForm, Feature, Exclusive, AssignedExclusive, Invoice, PressAgency, Albaran, User
375
Class ApplicationForm
Constant Attributes Variables Attributes Private Events id_appform, SSN, delivery_date Idenfification Function:id_appform name, address, equipment, CV, book, level, price create_instance (id_appform, SSN, delivery_date, name, address, equipment, CV, book, level, price) delete_instance (AppForm) edit_instance(AppForm, name, address, equipment, CV, book, level, price) accept(AppForm, level, price) [edit_instance(p_name, p_address, p_equipment, p_CV, p_book, p_level, p_price)] name=p_name and address=p_address and equipment=p_ equipment and CV=p_CV and book=p_book and level=p_level and price=p_price; [accept(arg_level,arg_price)] level=arg_level and price=arg_price; Solicitud = create_instance () Solici0; Solici0 = delete_instance () + (edit_instance (p_name, p_addresso, p_equipment, p_CV,p_book, p_level,p_price) + accept (arg_level, arg_price)) Solici0;
Valuations
Process(DTE)
Class Photographer specialization of Application_form class

Process (DTE) Photographer = ApplicationForm.accept (arg_level, arg_price) Solici0; Solici0 = ApplicationForm.delete_instance () + ApplicationForm.edit_instance (p_name, p_address, p_equipment, p_CV,p_book, p_level, p_price) Solici0;
376
Class Exclusive
Constant Attributes Variables Attributes Private events id_exclusive, request_date, title, price Idenfification Function: id_exclusive info create_instance (p_agrPressAgency, p_atrid_Exclusive, p_atrrequest_date, p_atrtitle, p_atrprice p_atrinfo) delete_instance(p_thisExclusive) edit_instance (p_thisExclusive, p_info) asignar (p_thisExclusive, p_agrPressAgency, p_atrassig_date) [edit_instance (p_info)] info=p_info; Exclusive = create_instance () Exclus0; Exclus0 = delete_instance () + (edit_instance (p_info) + assign ()) Exclus0;
Valuations Process(DTE)
Class AssignedExclusive specialization of Exclusive Class

Constant Attribute Private events Process(DTE) assign_date deliver(p_thisAssignedExclusive, p_atrdeliv_date) AssignedExclusive = Exclusive.assign () Exclus0; Exclus0 = Exclusive.delete_instance () + (Exclusive.edit_instance (p_info) + deliver ()) Exclus0;
377
Class DeliveredExclusive - specialization of AssignedExclusive

Constant Attribute Process(DTE) Deliv_date DeliveredExclusive = AssignedExclusive.deliver () Exclus0; Exclus0 = Exclusive.delete_instance () + Exclusive.edit_instance (p_info) Exclus0;
Class Feature
Constant Attributes Variables Attributes Private Events id_feature, title, n_photos, delivery_date Idenfification Function: id_feature theme, price, description create_instance (p_agrPhotographer, p_atrid_Feature, p_atrtitle, p_atrn_photos, p_atrdelivery_date, p_atrtheme,p_atrdescription) delete_instance (p_thisFeature) edit_instance(p_ thisFeature, p_theme, p_description) assign(p_ thisFeature) With Invoice: InsFeature (p_thisFeature,p_evcDeliveryNote) DelFeature (p_thisFeature,p_ evcDeliveryNote) [edit_instance (p_tematica,p_description)] theme=p_theme and description=p_description; [assign_price ()] price=Photographer.price * n_photos; Feature = user: ABRIRFICHA Report0; Report0 = user:delete_instance () + (user:edit_instance (p_theme, p_description)+ user:InsFeature () + user:DelFeature ()) Report0; ABRIRFICHA = create_instance(pt_p_agrPhotographer, pt_p_atrid_Feature, pt_p_atrtitle, pt_p_atrn_photos, pt_p_atrtheme, pt_p_atrdelivery_date, pt_p_atrdescripcion). assign_price(THIS);
Shared Events Evaluations Process(DTE)
Transactions
378
Class DeliveryNote
Constant Attributes Derived Attributes Private Events id_delnote, delivery_date Idenfification Function: id_delnote price create_instance (p_agrInvoice, p_agrPressAgency, p_agrFeature, p_atrid_Albaran,p_ delivery_date) delete_instance (p_thisDeliveryNote) edit_instance (p_ thisDeliveryNote) Con Reportaje: InsFeature(p_ thisDeliveryNote, p_evcFeature) DelFeature(p_ thisDeliveryNote, p_ evcFeature) Invoice = create_instance () Albara0; Albara0 = delete_instance () + (edit_instance () + InsFeature () + DelFeature ()) Albara0;
Shared Events Process(DTE)
379
Class Invoice
Constant Attributes Derived Attributes Private Events id_invoice, date Idenfification Function: id_invoice VAT, total, total_invoice, total_feature, total_exclusive create_instance (p_DeliveryNote, p_PressAgency, p_DeliveredFeature, p_atrid_invoice, p_atrdate) delete_instance (p_thisInvoice) edit_instance (p_thisInvoice) Factura = create_instance () Factur0; Factur0 = delete_instance () + edit_instance () Factur0;
Process(DTE)
Class PressAgency
Constant Attributes Variables Attributes Private Events id_pressag,name Idenfification Function:id_Editorial address, phone, fax create_instance (p_atrid_ pressag, p_atrname, p_atrphone, p_atrfax, p_atraddress) delete_instance (p_thisPressAgencyl) edit_instance (p_ thisPressAgencyl, p_phone, p_fax, p_address) [edit_instance (p_phone,p_fax,p_address)] phone=p_phone and fax=p_fax and address=p_address; PressAgency = create_instance () Editor0; Editor0 = delete_instance () + edit_instance p_phone,p_fax,p_address) Editor0;
Valuations Process(DTE)
380
Class User
Constant Attributes Private Events Process(DTE) id_user Identification Function: id_user create_instance(p_atrid_user) delete_instance (p_thisUser) edit_instance (p_thisUser) user = user:create_instance () usuari0; usuari0 = usuario:delete_instance () + usuario:edit_instance () usuari0;
1.2 Navigational Model

The navigational model for the administrator User of the Photography Agency is next introduced. This user kind may access all functionality of the application as well as create news users.
381
1.2.1 Navigational Map for the administrator User
382
1.2.2 Navigational Context Users
1.2.3 Navigational Context ApplicationForms
383
1.2.4 Navigational Context AppForm_Details
1.2.5 Navigational Context Photographers
384
1.2.6 Navigational Context Photographer_Details
1.2.7 Navigational Context Exclusives
385
1.2.8 Navigational Context Exclusive_Details
1.2.9 Navigational Context AssignedExclusive_Details
386
12.10 Navigational Context Features
12.11 Navigational Context Features_Details
387
12.12 Navigational Context PressAgency
12.13 Navigational Context PressAgency_Details
388
12.14 Navigational Context DeliveryNotes
12.15 Navigational Context Invoices
389

OO-Method Function Points for the Web (OOmFPWeb) - Measurement Guideline Given a conceptual schema CS produced in the OOWS conceptual modeling phase, OOmFPWeb is calculated as follows: 3. The Object, Navigational and Presentational Models are used for measuring the transactional functions. c. Transactional functions are identified. d. A level of complexity is assigned for each transactional function based on IFPUG tables. Levels of complexity for functions are translated into values using IFPUG tables. The sum of values produces the functional size of a Web application (non-adjusted OOmFPWeb). A Navigational Map for a specific agent (measures the functionality for a given user type) A Navigational Context The first one is applied in a new development whereas the latter ones in the restructuring phase of a WebApp (e.g. adaptive or corrective maintenance) The application boundary indicates the border between the project or application being measured, and the external applications or user domain. Identification rule: Accept each agent as a user of the application. The boundary corresponds to all navigational maps existing in a Navigational Model. STEP 2. Sizing Data Functions The measurement of data functions is made using the Object Model and includes two activities: the identification of the functions and the determination of
OOmFPWeb = OOmFP D + OOmFP T

Where, OOmFPD is the size related to the data logical functions, and OOmFPT is the size related to the transactional logical functions. The measurement process is made according to the following steps: 1. The Object Model is analyzed to determine the application boundary and the measuring scope. 2. The Object Model is used for measuring the data functions . a. Data functions are identified. b. A level of complexity is assigned for each data function based on IFPUG tables. 4. 5.
STEP 1. Identifying the Measurement Scope and the Application Boundary The measurement scope limits which functionality will be measured in a particular measurement (a sub-set). It can include in OOmFPWeb: A complete Web application (WebApp), tacking into account all Navigational Maps and Agents.
390

its complexity. Please, identify ILFs and EIFs by applying the following rules: Identification Rule for ILF: Accept each class (with agent relationships) as an ILF. Reject classes that have no DET. Identification Rule for EIF: Accept each legacy view (with agent relationships) as an EIF. Reject legacy views that have no DET. Determine the amount of DETs and RETs for each class and legacy view: DET: a unique user recognizable, nonrepeated field. It can be a data-valued attribute of a class or legacy view. RET: user-recognizable subgroup of data elements within a class or legacy view. Measurement Rules for DETs of a Class: 1 DET for each data-valued attribute of the class 1 DET for each attribute in the Identification Function (IF)33 of a class or legacy view referenced in a univalued aggregation relationship. 1 DET for each attribute in the IF of the superclasses of a class. Measurement Rules for RETs of a Class: 1 RET for the class. 1 RET for each multivalued aggregation relationship (class or legacy view). Measurement Rules for DETs of a Legacy View: 1 DET for each non-derived attribute of the legacy view 1 DET for each attribute in the IF the class related to by a univalued aggregation Measurement Rules for RETs of a Legacy View: 1 RET for the legacy view. 1 RET for each multivalued aggregation relationship with a class. Determine the complexity for each class and legacy view: Complexity Classes and Legacy Views
RET 1 2-5 6+ 1-19 DETs Low Low Average 20-50 DETs Low Average High 51 + DETs Average High High
STEP 3. Functions:
Sizing
Transactional
33 Composed by constant attributes that identifies the objects of a class.
The measurement of the transactional functions is made using the Object, Navigational and Presentational Models. It includes two activities: the identification of the functions and the determination of their complexity.
391

Identify EIs and EQs applying the following rules: Identification Rule for EI: Accept each unique class service in the Object Model (with agent relationships) as an EI. Hints for identifying EIs: An event or transaction are measured only once (in the class in which they are declared), even if they are inherited by several subclasses. Shared events must measured only once (in any class in which they are declared). Reject event or transactions that are not activated for any client class. Identification Rule for EQ: Accept each unique navigational context of a Navigational Model as an EQ. Hints for identifying EQs: A navigational context is measured only once (in the root Navigational Map in which they are declared), even if they are inherited by several Navigational Maps. Determine the amount of DETs and FTRs for each service and navigational context: DET: a unique user recognizable, nonrepeated field. FTR: subgroup of logical data referenced/maintained by a transactional function. Measurement Rules for DETs of a Class Service: 1 DET for each data-valued argument of the service 1 DET for the capability of the application to send messages 1 DET for the action (Accept/Cancel) of the service execution. Measurement Rules for FTRs of a Class Service: 1 FTR for the class in which the service is declared. 1 FTR for each new34 class referenced in the object-valued argument of the service (only if it is different of the class service). If integrity constraints are defined, count one FTR for new class referenced in the formula. [constraint] 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 [when clausule]35 If a specialization by event is defined (carrier/liberator event), count one FTR for each new class for which the event is a carrier/liberator. If a value by default is defined, count one FTR for new class referenced in the formula.
34
New in this context means that the class was not counted yet 35 [ ] session in the OASIS specification
392

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, defined in the Interaction Diagram. [triggers] 1 FTR for each new class referenced in the formula of a precondition, defined in the State Transition Diagram. [preconditions] Measurement Rules for DETs of a Legacy View Service: 1 DET for each data-valued argument of the service. 1 DET for the capability to send messages (control, error, etc). 1 DET for the action (Accept/Cancel) of the service execution. Measurement Rules for FTRs of a Legacy View Service: 1 FTR for the legacy view in which the service is declared. If integrity constraints are defined, count one FTR for new class referenced in the formula. 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, defined in the Interaction Diagram. 1 FTR for each new class referenced in the formula of a precondition, defined in the State Transition Diagram Determine the complexity for each class and legacy view services:
FTRs 0-1 2 3+ 1-4 DETs Low Low Average 5-15 DETs Low Average High 16 + DETs Low Average High
Measurement Rules for DETs of Navigational Context 1 DET for each attribute of the navigational class 1 DET for each contextual dependency relationship 2 DETs for each context relationship 1 DET for each service defined in the navigational classes 1 DET for each service link associated to a service1 DET for each attribute defined in the formula of a population filte. 1 DET for each attribute defined in the formula of a information access filter 1 DET for each attribute defined in the formula of an index Measurement Rules for DETs of Navigational Context (Presentation Perspective) 4 DETs for each sequential access mode to data blocks (previous-nextfirst-last).
Then, determine the amount of DETs and FTRs for each navigational context applying the following rules:
393

5 DETs for each random access mode to data blocks (previous-next-first-lastnum). 1 DET for the cardinality (dynamic). 1 DET for each ordering criteria of the navigational context. 1 DET for the ability to specify an action to be taken 1 DET for the application capacity of presenting messages (error, control, etc.) Hints for Measuring DETs of Navigational Contexts (Presentation Perspective) If an access mode is defined in conjunction with a cardinality pattern the measurement is as follow: A sequential access mode with a static cardinality pattern, count only 4 DETs. A sequential access mode with a dynamic cardinality pattern, count 5 DETs. A random access mode with a static cardinality pattern, count 5 DETs. A random access mode with a dynamic cardinality pattern, count 6 DETs. Measurement Rules for FTRs of Navigational Context 1 FTR for each navigational class 1 FTR for each new class referenced in the population filter formula 1 FTR for each new class referenced in the information access filter formula 1 FTR for each new class referenced in the index formula Determine the complexity for each unique navigational context identified in the Navigational Model: Complexity Navigational Context
FTR 0-1 2-3 4+ 1-5 DETs Low Low Average 6-19 DETs Low Average High 20 + DETs Average Alta High
STEP 4. Translating the Complexity Levels into Values This step is made using the weights proposed by the International Function Point Users Group (IFPUG). These weights are summarized in the following table:
TYPE Class Legacy View Service Navegat ional Context Low __x7 __x5 __x3 __x3 Average High __x10 _x15 __x7 _x10 __x4 __x4 __x6 __x6 Total
STEP 5. Calculating OOmFPWeb The sum of the values obtained for data and transaction functions results in the functional size of a Web application (nonadjusted OOmFPWeb).
OOmFPWeb = OOmFP D + OOmFP T
394
COLLECTION FORM
PROJECT: PHOTOGRAPHY AGENCY Name and Fullname: Register the Starting Hour:.. Note: Please, use decimals for minutes (Example:1.5 hour). STEP 1. IDENTIFYING THE MEASUREMENT SCOPE AND THE APPLICATION BOUNDARY 1.1 Measurement Type: New Development Project 1.2 Application Boundary:
STEP 2. SIZING DATA FUNCTIONS 2.1 Identifying ILFs (List the classes inside the application boundary) 395
2.2. Measuring the Complexity of Classes

Id 1 .. N Class DETs RETs Complexity
2.3. Identifying EIFs (List the legacy views defined in the Object Model)
STEP 3. SIZING TRANSACTIONAL FUNCTIONS 3.1. Identifying EIs: (List the services for each class or legacy view)
Id 1 .. N Class EIs
396
3.2. Measuring the complexity of the class services

Service of the class #1 DETs FTRs Complexity
..
Service of the class #n DETs FTRs Complexity
..
Register the Ending Hour::.. 3.3. Identififying EQs: (List all the unique navigational contexts of a Navigational Map) Register the Starting Hour:..
Id 1 .. N N. Context DETs FTRs Complexity
397
STEP 4. TRANSLATING THE COMPLEXITY LEVELS INTO VALUES 4.1 Calculating OOmFPWebD
TYPE Class Legacy View Total OOmFPWebD _ _ LOW X7 X5 AVERAGE _ _ X 10 X7 _ _ HIGH X 15 X 10 TOTAL
4.2 Calculating OOmFPWebT

TYPE Service Navegational Context Total OOmFPWebT _ _ LOW X3 X3 AVERAGE _ _ X4 X4 _ _ HIGH X6 X6 TOTAL
STEP 4. CALCULATING OOmFPWeb The sum of the values obtained for data and transactional functions results in the functional size of a Web application (non-adjusted OOmFPWeb)
OOmFPWeb = OOmFP D + OOmFP T OOmFPWeb =

Register the Ending Hour::..
398
Appendix B
Survey Instruments Used in the Experiments

Survey Used in the First Experiment
For each of the following paired statements, please mark a cross over the circle which most closely matches your opinion. There are no right answers to these questionsjust give your honest opinion, based on your experience using the sizing method.
PLEASE READ EACH QUESTION CAREFULLY BEFORE GIVING YOUR RESPONSE
1. I found the procedure for applying the FSM method complex and difficult to follow I believe that this FSM method would reduce the time required to measure object-oriented systems. Overall, I found the FSM method difficult to use I found the procedure for applying the FSM method simple and easy to follow
2.
I believe that this FSM method would increase the time required to measure object-oriented systems. Overall, I found the FSM method easy to use
3.
Appendix B. Survey Instruments Used in the Experiments
4.
I found the measurement rules of the FSM method clear and easy to understand Overall, I found the FSM method to be useful I found the FSM method difficult to learn I will use this FSM method if I have to measure object-oriented systems in the future I think that this FSM method would NOT improve the accuracy of size estimates of objectoriented systems I found it difficult to apply the FSM method to the case study
I found the measurement rules of the FSM method confusing and difficult to understand Overall, I did NOT find the FSM method to be useful I found the FSM method easy to learn I will NOT use this FSM method if I have to measure object-oriented systems in the future I think that this FSM method would improve the accuracy of estimates of size objectoriented systems
5.
6.
7.
8.
9.
I found it easy to apply the FSM method to the case study Overall, I think this FSM method provides an effective way of measuring the functional size of OO systems during the requirements phase. Using this FSM method would NOT improve my performance in measuring OO systems It would be difficult for me to become skilful in using this FSM method
10. Overall, I think this FSM method does NOT provide an effective way of measuring the functional size of OO systems during the requirements phase. 11. Using this FSM method would improve my performance in measuring OO systems 12. It would be easy for me to become skilful in using this FSM method
400
13. Overall, I think this FSM method is an improvement to the FPA method 14. I intend to use this FSM method in the future
Overall, I think this FSM an method is NOT improvement to the IFPUG FPA method I do NOT intend to use this FSM method in the future
Please provide free text answers to each of the following questions: 15. Do you have any suggestions as to how to make the FSM method easier to use? 16. Do you have any suggestions as to how to make the FSM method more useful for measuring the functional size of object-oriented systems?
17. What are the reasons why or why not you intend to use this method in a future? Please write any other comments you would like to make about the sizing method or the experiment in the space below ______________________________________________________________ ______________________________________________________________ ______________________________________________________________ ______________________________________________________________
401
Survey Used in the Second Experiment

For each of the following paired statements, please mark a cross over the circle, which most closely matches your opinion. There are no right answers to these questionsjust give your honest opinion, based on your experience using the FSM procedure.
PLEASE READ EACH QUESTION CAREFULLY BEFORE GIVING YOUR RESPONSE
1. I found the procedure for applying the FSM method complex and difficult to follow I believe that this FSM method would reduce the time required to size Web applications. Overall, I found the FSM method difficult to use I found the measurement rules of the FSM method clear and easy to understand Overall, I found the FSM method to be useful I found the FSM method difficult to learn I will use this FSM method if I have to measure Web applications in the future I found the procedure for applying the FSM method simple and easy to follow
2.
I believe that this FSM method would increase the time required to measure Web applications. Overall, I found the FSM method easy to use I found the measurement rules of the FSM method confusing and difficult to understand Overall, I did NOT find the FSM method to be useful I found the FSM method easy to learn I will NOT use this FSM method if I have to measure Web applications in the future
3.
4.
5.
6.
7.
402
8.
I think that this FSM method would NOT improve the accuracy of sizecestimates of Web applications I found it difficult to apply the FSM method to the case study
I think that this FSM method would improve the accuracy of estimates of size Web applications
9.
I found it easy to apply the FSM method to the case study Overall, I think this FSM method provides an effective way of measuring the functional size of Web applications. Using this FSM method would NOT improve my performance in measuring Web applications It would be difficult for me to become skilful in using this FSM method I do NOT intend to use this FSM method in the future
10. Overall, I think this FSM method does NOT provide an effective way of measuring the functional size of Web applications. 11. Using this FSM method would improve my performance in measuring Web applications. 12. It would be easy for me to become skilful in using this FSM method 13. I intend to use this FSM method in the future
Please provide free text answers to each of the following questions: 1. Do you have any suggestions as to how to make the FSM procedure easier to use?
2. Do you have any suggestions as to how to make the FSM procedure more useful for sizing Web applications?
403
3. What are the reasons why or why not you intend to use this procedure in a future? Please write any other comments you would like to make about the FSM method in the space below
_________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________
404
Appendix C
Measurement Results
C1. First Experiment
This appendix shows the data set obtained for the performance and perception-based variables for IFPUG FPA and OOmFP. First, we outline the IFPUG FPA performance-based values in the following table:
Subject 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Size for IFPUG FPA 129 125 115 124 143 121 114 118 145 159 121 122 165 174 132 114 147 128 125 127 REPi for IFPUG FPA 0.03 0.06 0.14 0.07 0.08 0.09 0.15 0.11 0.10 0.21 0.09 0.08 0.26 0.34 0.00 0.15 0.12 0.03 0.06 0.04 MREi for IFPUG FPA 0.16 0.18 0.25 0.19 0.07 0.21 0.25 0.23 0.05 0.04 0.21 0.20 0.08 0.14 0.14 0.25 0.04 0.16 0.18 0.17
Appendix C. Measurement Results
Then, the functional size assessments, reproducibility, and accuracy values for OOmFP are introduced below:
Subject 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Size in OomFP 150 158 172 155 151 148 158 148 160 165 151 170 163 171 163 158 173 160 163 154 REPi in OomFP 0.06 0.01 0.08 0.03 0.06 0.08 0.01 0.08 0.00 0.04 0.06 0.07 0.02 0.08 0.02 0.01 0.09 0.00 0.02 0.04 MREi in OomFP 0.02 0.03 0.12 0.01 0.01 0.03 0.03 0.03 0.05 0.08 0.01 0.11 0.07 0.12 0.07 0.03 0.13 0.05 0.07 0.01
Finally, the collected data for the perception-based measures (IFPUG FPA and OOmFP) are introduced in the next two tables.
Data set for perception-based measures (IFPUG FPA)
Subject 1 2 3 4 5 6 7 8 9 10 PEOU IFPUG FPA 3.60 3.20 3.20 3.00 2.80 2.60 3.40 2.60 2.40 2.80 PU IFPUG FPA 2.60 2.20 1.80 2.00 2.80 2.40 3.00 2.20 2.60 3.60 ITU IFPUG FPA 3.67 1.67 1.67 1.33 3.00 3.00 3.67 2.33 2.67 3.67
406
Data set for the perception-based measures (IFPUG FPA) cont.

Subject 11 12 13 14 15 16 17 18 19 20 PEOU IFPUG FPA 1.80 2.20 2.80 2.60 2.20 2.40 3.20 2.40 2.60 2.40 PU IFPUG FPA 2.60 2.80 2.80 2.00 2.80 2.40 2.40 2.20 2.80 1.60 ITU IFPUG FPA 2.33 3.33 2.33 2.67 2.00 2.67 3.00 2.33 2.67 267
Data set for the perception-based measures (OOmFP)

Subject 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 PEOU OOmFP 3.20 2.60 2.60 3.40 2.60 2.60 1.60 3.40 3.80 4.40 2.80 2.60 2.60 2.40 2.60 3.80 3.40 2.00 2.00 3.60 PU OOmFP 4.00 3.20 3.20 4.60 3.40 3.80 3.40 3.20 3.60 4.40 3.40 3.20 2.80 3.00 3.60 3.60 3.80 3.00 2.80 4.00 ITU OOmFP 4.33 3.67 3.33 4.67 4.33 3.67 3.67 4.00 3.33 3.67 3.33 4.33 2.33 3.33 4.00 2.33 4.33 3.00 3.00 4.67
407
C2. Second Experiment

The next two tables summarizes the collected data in the second experiment.
Data set for performance-based measures (OOmFPWeb)
Subject 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Functional Size (FPs) 212 196 218 210 218 221 201 205 222 217 207 221 219 182 171 Measurement Time (h) 2.2 2.1 2.1 1.55 2.15 2.25 1.55 1.5 2.3 1.55 2.2 2.3 1.4 1.48 2 Productivity (FPs/h) 96.36 93.33 103.81 135.48 101.40 98.22 129.68 136.67 96.52 140.00 94.09 96.09 101.86 122.97 85.50 Repi 0.02 0.06 0.05 0.01 0.05 0.07 0.04 0.02 0.07 0.05 0.01 0.07 0.06 0.13 0.19
Data set for perception-based measures (OOmFPWeb)

Subject 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 PEOU OOmFPWeb 3.00 3.80 3.80 3.00 3.00 4.20 3.80 4.20 4.20 4.60 4.20 3.80 5.00 3.40 4.00 PU OOmFPWeb 2.20 4.00 4.20 3.20 3.40 4.20 3.20 3.80 4.40 4.00 4.00 4.20 3.00 4.60 4.60 ITU OOmFPWeb 2.33 3.67 4.33 2.67 1.67 4.33 2.67 4.33 4.33 4.33 4.00 3.00 5.00 4.33 5.00
408

PhDThesis SilviaAbrahao

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PhDThesis SilviaAbrahao

Uploaded by

Copyright:

Available Formats

On the Functional Size Measurement of Object-Oriented Conceptual Schemas: Design and Evaluation Issues

by Silvia Mara Abraho

del ingls Functional Size Measurement

De langls Functional Size Measurement

5 Extending OOmFP for Sizing Web Applications ................................ 155

7 Validation of the Application of the Measurement Procedure........... 217

8 Experiment 1: Comparative Evaluation of OOmFP against IFPUG FPA........................................................................................................... 231

Threats to external validity ........................................................... 275

Conclusions ................................................................................................ 276

9 Experiment 2: Evaluating the Performance and Acceptance of OOmFPWeb............................................................................................ 279

10 Conclusions and Further Research..................................................... 309

Software size measurement

Figure 1. Software domains and models

Functional sizing: the users viewpoint

Figure 2. Evolution of FSM methods (Source: [13])

Technical sizing: the developers viewpoint

Functional size measurement (FSM)

Existing standards and frameworks for FSM

ISO/IEC 20926: IFPUG

Figure 4. Measurement process steps (Source: Jacquet and Abran [25])

Figure 6. The data-oriented abstraction (Source: [13])

Usefulness of functional size measurement

Problem statement and research goal

The OO-Method paradigm: from problem space to solution space

OO-Method Conceptual Schemas

OASIS Formal Specification

Solution Space Level

Figure 7. The OO-Method approach

Figure 8. Summary of research design

Selection of research methods

Action Research Cycles

Figure 9. Action Research Phases

Figure 10. Overview of the experiment process (Source: [72])

Functional size measurement for objectoriented systems

Chapter 2. Literature Review

Chapter 2. Literature Review

2.1.1 First category

Chapter 2. Literature Review

The Lehne proposal (1997)

Chapter 2. Literature Review

Chapter 2. Literature Review

Chapter 2. Literature Review

2.1.2 Second category

Chapter 2. Literature Review

FS = ExtObjectDataCompl + ExtServiceCompl + EIFw

Chapter 2. Literature Review

Chapter 2. Literature Review

Then, the functional dimension (FD) is calculated: 62

Chapter 2. Literature Review

This is followed by the calculation of the control dimension (CD):

Chapter 2. Literature Review

OOFP = OOFPILF + OOFPEIF + OOFPSR

OOFPEIF = W EIF ( DETo , RETo )

OOFPSR = W SR ( DETo , FTR o )

Chapter 2. Literature Review

Chapter 2. Literature Review

2.1.3 Third category

Chapter 2. Literature Review

The Laranjeira proposal (1990)

Chapter 2. Literature Review

Object Point Analysis (Banker, 1991)

Chapter 2. Literature Review