Evaluating the Achievable Service Availability by Integrating the State Controller

Debido a la crítica, los inconvenientes y la especificidad del análisis de puntos de función original se han desarrollado numerosas variantes del FPA, por ejemplo, Puntos de Datos, Puntos Característica, Puntos de Objeto, Puntos de Función SPR, Puntos de Función 3D, Puntos de Caso de Uso, NESMA, así como FFP COSMIC.

NESMA

La Netherlands Software Metrics Association2, en español, la Asociación Holandesa de Métricas del Software es la segunda asociación de medición funcional de software más grande del mundo. Fue fundada en mayo de 1989. Esta asociación surgió con el objetivo de adoptar el método de IFPUG para que se ajustara mejor a la medición de proyectos donde se modificaba funcionalidad, es decir, se adoptó a proyectos de mejora teniendo en cuenta únicamente los cambios realizados en las funciones transaccionales y en las funciones de datos [11]. Entre sus propósitos se encuentra el reunir a individuos y organizaciones para intercambiar conocimientos y experiencia en el desarrollo y aplicación de métricas de software; promover la contabilidad en el uso de métricas de software; apoyar la formulación y adopción de estándares en las métricas de software; y fomentar el desarrollo y la aplicación de métricas de software.

NESMA ha desarrollado y mantiene sus propias prácticas de conteo, incorporando los mismos conceptos, metodología y reglas de conteo que las publicadas por el Grupo Internacional de Usuarios de Puntos de Función (IFPUG). También ha desarrollado muchas directrices para ser utilizadas por los analistas de puntos de función con el fin de proporcionar orientación práctica en la aplicación y el uso del análisis de puntos de función [4].

Este método aplica un factor de impacto a las funciones modificadas o eliminadas del proyecto. El factor de impacto da una idea de cuál es el porcentaje de la función que se ha visto afectado por la modificación. Por tanto, una función nueva tendrá un factor de impacto del 100 % y una función modificada tendrá un valor menor que este. Utilizando este factor, podemos calcular los puntos función de la función completa afectados por la modificación. En este método, se distinguen tres tipos de funciones: funciones nuevas (se miden de igual forma que en IFPUG), funciones modificadas (e ven alteradas por el proyecto y se cuentan de forma diferente aplicando el factor de impacto correspondiente) y funciones eliminadas (se les asigna un factor de impacto fijo) [11].

Este método mide el tamaño funcional obtenido de dos maneras distintas:

• En puntos función mejorados (EFP), miden las modificaciones de funcionalidad del sistema. • En puntos función de pruebas (TFP), que miden la funcionalidad que no ha sufrido ningún

cambio pero que hay que probar para comprobar que siguen funcionando de la forma esperada. La medición de los puntos función de mejora se centra en 8 pasos:

1. Identificar las funciones transaccionales y de datos dentro del alcance de la mejora proyecto. Para iniciar este método es necesario disponer como prerrequisitos la propuesta de mejora, la documentación funcional del sistema actual y el análisis de puntos de función del sistema existente para identificar las funciones transaccionales y de datos incluidas dentro del alcance del proyecto que se va a realizar. Es necesario un análisis de puntos de función del sistema existente ya que todas las funciones existentes que se ven afectadas directa o indirectamente por el proyecto de mejora contribuyen al tamaño funcional del nuevo proyecto. Si no se dispone del análisis del sistema existente, se debe identificar, como mínimo, las funciones afectadas por la mejora.

CAPÍTULO 3. ESTADO DEL ARTE 43

El tamaño del sistema existente, o la parte afectada por el proyecto de mejora, se expresa en puntos función no ajustados, que constituyen elÍFPbase.

2. Determinar el tamaño de mejora de las funciones transaccionales y de datos añadidas. Este paso consiste en identificar las funciones que se van a añadir al sistema. Estas funciones se van a medir siguiendo método estándar de IFPUG. El factor de impacto que corresponde a dichas funciones es siempre de 1.

El número de puntos de función de mejora no ajustados para una función añadida se define de la siguiente forma:

U EFPaдreдados = FPaдreдados

3. Determinar el tamaño de mejora de las funciones transaccionales y de datos eliminadas. Se determinan las funciones que van a ser eliminadas del sistema por el proyecto de mejora, así como, el número de puntos función que les corresponde. El tamaño de estas funciones se expresa como FPeliminados.

El valor del factor de impacto que se asigna a estas funciones es de 0.4. La siguiente fórmula determina el valor en puntos función para una función eliminada:

U EFPeliminados = FPeliminados · 0,4

4. Determinar el tamaño de mejora de las funciones de datos modificadas.

Se identifican las funciones de datos que se modifican y se determina el tamaño de cada función de datos después de la modificación.

Estas funciones pueden verse modificadas de dos formas: cambian internamente (se añaden, eliminan o modifican sus DETs) o cambian de tipo, pero no internamente (un EIF se convierte en un ILF o viceversa).

Se utiliza el método FPA (análisis de puntos función) para determinar el tamaño de la función de datos después del cambio y se determina la función FPmodificados.

En caso de las funciones de datos que cambian internamente, se calcula el porcentaje de DETs modificados, que se define como el cociente de los DETs modificados dividido por el número original de DETs. Según este porcentaje se obtiene el factor de impacto:

Porcentajde de DETs <= 33 % <= 67 % <= 100 % >100 % Factor de impacto 0.25 0.50 0.75 1.00

Tabla 3.10: Factor de impacto

Si una función cambia de tipo se utiliza un valor fijo de 0.4 para el factor de impacto.

Si el número de DETs cambia así como el tipo, el valor del factor de impacto debido al cambio de tipo se compara con el valor debido al cambio en el número de DETs y el valor más alto se utiliza en el cálculo del tamaño de los puntos función de mejora.

Este tamaño se determina como se indica a continuación: U EFPmodi f icados = FPmodi f icados · Imodi f icados

5. Determinar el tamaño de mejora de las funciones transaccionales a modificar.

Se identifican las funciones transaccionales que cambian y se determina el tamaño de cada una de ellas después de la modificación.

Estas funciones se consideran modificadas si se alteran de alguna manera, pero conservan el mismo nombre y propósito después de la mejora que antes de esta. El número de puntos de función después del cambio se expresa como FPmodificado.

44 3.3. ESTIMACIÓN POR ANALOGÍA

• Una operación se ve afectada por un DET que se añade, modifica o borra

• Una operación se ve afectada por un FTR (ILF o EIF) que se añade, modifica o elimina. • Si se modifica la interfaz de usuario.

• Si se modifica la lógica empresarial que soporta una operación. • Se realiza un cambio cosmético visible en la interfaz de usuario. • Una modificación de un total en un informe.

• Se sustituye o modifica un título en un informe o en una pantalla. Existen cuatro pasos para calcular este tamaño:

1. Identificar los DETs y FTRs utilizados en la transacción: si se produce únicamente un cambio cosmético, los DET y FTR afectados serán 0 lo que implica un factor de impacto mínimo: 0.25. 2. Determinar los porcentajes de DETs y FTRs modificados como resultado de la mejora: el factor de impacto viene determinado por las variaciones en el número de DETs y FTRs utilizados en comparación con el número original de DETs y FTRs.

PorcentajeDETs = N umeroDET saдr eдados/eliminados/modif icados ·100_{N umeroor iдinal DET s} PorcentajeFT Rs = N umeroFT Rsaдr eдados/eliminados/modif icados ·100_{N umeroor iдinal FT Rs}

3. Determinar el factor de impacto: este factor queda determinado en función de la siguiente tabla: Porcentaje de DETs Porcentaje de FTRs <=67 % <= 100 % >100 % <=33 % 0.25 0.50 0.75 <=67 % 0.50 0.75 1.00 <=100 % 0.75 1.00 1.25 >100 % 1.00 1.25 1,50

Tabla 3.11: Factor de impacto

Una función transaccional puede verse afectada también por alguna modificación en las funciones de datos.

4. Calcular el número de puntos de función de ampliación: el tamaño de los puntos función de mejora de las funciones transaccionales se calcula de la siguiente manera:

U EFPmodi f icados = FPmodi f icados · Imodi f icados

6. Calcular el tamaño en punto función no ajustado del proyecto de mejora.

El tamaño total del proyecto de mejora se obtiene de la suma del número de puntos de función de mejora para todas las funciones transaccionales y de datos afectadas:

U EFproyectos = ÍU EFPaдreдados + ÍU EFmodi f icados + ÍU EFPeliminados

7. Aplicar el valor del factor de ajuste y calcular el tamaño en puntos función ajustados del proyecto de mejora.

El valor del factor de ajuste (VAF) debe aplicarse al tamaño del proyecto en las organizaciones que se ciñen al uso de este factor. Las catorce características del sistema deben ser reevaluadas para el sistema mejorado.

8. Calcular el tamaño en puntos función ajustados del sistema después de la mejora. El tamaño del sistema después de la mejora queda determinado por:

CAPÍTULO 3. ESTADO DEL ARTE 45

Por otro lado, se han de medir los puntos función de prueba (FTP) que miden el tamaño de las funciones a probar. Este tamaño se mide usando la metodología estándar de FPA y no está sujeta a ningún factor de impacto. Las funciones medidas son las del sistema después de la mejora, por lo que no se tiene en cuenta si se ha añadido una función, se ha modificado, se ha combinado con otras funciones o se ha visto afectada de otro modo por la mejora. Además, las funciones borradas se excluyen de este recuento.

El número de FTPs se establece de manera que se ha determinar el tamaño de la FP de cada transacción o función de datos directamente implicada en una prueba y calcular el número total de puntos función para todas las transacciones o funciones de datos implicadas en la prueba.

El número total de puntos de función de prueba es la suma de los TFP transaccionales y los TFP de datos. El tamaño del punto de función de prueba es igual al tamaño de las funciones probadas, donde 1 FP resulta en 1 TFP. El tamaño total del punto de función de prueba es:

T FP = ÍU FPTEST COSMIC-FFP

Este método fue creado por el Common Software Metrics International Consortium en 1997 y es considerado como el primer método funcional de segunda generación. Fue propuesto con el objetivo de ofrecer una medida de talla funcional específicamente adaptada al software de tiempo real, ampliando el dominio funcional del método de puntos función hacia estos entornos ya que los puntos función tradicionales no permiten capturar todas las características de este tipo de software, cuando estos se utilizan se obtienen valores que no constituyen una medición adecuada de su tamaño funcional [4].

Se trata de una medida normalizada la cual ha sido diseñada para su aplicación en los siguientes dominios:

• Software de aplicación, típicamente de soporte a la administración de negocios bancarios, de seguros, de contabilidad, de gestión del personal, de compras o de distribución entre otros. • Software en tiempo real, algunos ejemplos serían los sistemas para intercambio de comunica-

ciones telefónicas y mensajes, ascensores, automóviles. . . • Softwares híbridos de los dos anteriores.

Este método implica la aplicación de una serie de procedimientos al software dado, tal como este es percibido desde la perspectiva de los requerimientos funcionales del usuario. Y se basa en dos principios generales: todo proceso funcional debe completar al menos dos movimientos de datos, una entrada y una salida/escritura. El segundo principio es que el software que va a ser medido manipula parcelas de información designadas como grupos de datos.

La talla funcional del software se obtiene como valor proporcional al número de movimiento de datos de dicho software. El software se descompone en distintos niveles de forma jerárquica, de manera que, se intercambian datos únicamente con sus niveles inmediatamente superior o inferior. Dentro de ellos el software se agrupa en componentes llamados pares (peers). Los niveles superiores confían en el servicio proporcionado por los niveles inferiores y los niveles inferiores proveen cierto servicio a los superiores.

En estos pares se recogen los procesos funcionales, que realizan el intercambio de información entre los distintos niveles. El tamaño de estos procesos queda determinado por la suma del tamaño de los movimientos de datos que lo forman.

46 3.3. ESTIMACIÓN POR ANALOGÍA

• Entrada: cruza la aplicación desde el lado del usuario de la frontera del software hasta el proceso funcional en el interior de dicha frontera. No actualiza los datos que desplaza.

• Salida: transfieren datos desde el proceso funcional hacia el exterior de la frontera. No lee los datos, solo los desplaza.

• Lectura: toma los datos del archivo de almacenamiento y los pone a disposición del proceso funcional al cual pertenece.

• Escritura: transfieren datos desde el interior del proceso funcional, hacia el exterior de la frontera, al almacenamiento de datos.

Figura 3.1: Flujo de datos

El tamaño funcional del software es directamente proporcional al número de sus subprocesos de movimientos de datos. La unidad de medida es el CFSU (Cosmic Functional Size Unit) y es equivalente a un movimiento de datos a nivel de subproceso. El tamaño de un proceso se determina como la suma aritmética de los subprocesos que lo conforman.

El tamaño funcional más pequeño de una pieza de software es de 2 CFSU ya que según el primer principio, cualquier proceso funcional, por pequeño que sea ha de tener al menos una entrada y una salida o una escritura.

El tamaño de un proceso funcional viene determinado por la suma del tamaño de los movimien- tos de datos que lo forman. Si se trata de modificaciones del software existente, el tamaño de la modificación de un proceso funcional es la suma de los tamaños de los movimientos de datos que han sido añadidos, modificados o eliminados de dicho proceso funcional.

La suma total nos dará el tamaño funcional del software que estamos midiendo. Puntos Característica

En 1986, Capers Jones, fundador de Software Productivity Research (SPR), introdujo el método Puntos Característica (Feature Point). Esta variante parte de los mismos elementos que los del IFPUG FPA pero elimando la complejidad y se amplía los tipos de función de usuario en un nuevo sexto tipo que tiene en cuenta los algoritmos. Además, el método de Punto de Característica se limita a dos características de aplicación general [4].

La complejidad de los algoritmos se mide entre 1 y 10, siendo el 1 las operaciones aritméticas básicas y el 10 complicadas operaciones matemáticas, operaciones con matrices, etc.

Para identificar los algoritmos se emplean también una serie de reglas:

CAPÍTULO 3. ESTADO DEL ARTE 47

• Deben concluir en un tiempo infinito. • Han de ser precisos.

• Deben admitir una entrada y devolver una salida. • Puede estar compuesto por varios sub-algoritmos. Puntos Objeto

Desarrollado en los años 90 por Rajiv D. Banker, Robert J. Kauffman y Rachna Kumar, propone un nuevo método para mejorar la precisión de las estimaciones teniendo en cuenta las características de los sistemas orientados a objetos [4].

El recuento de puntos de objeto se centra en el número de pantallas, informes y módulos de lenguaje de tercera generación de un nuevo sistema de software, de los cuales los elementos se pueden clasificar como simple, medio o difícil.