Caso práctico sobre análisis de punto de función, parte 2

Bienvenidos a la segunda parte de este caso práctico sobre análisis de puntos de función. Como podrán recordar, el objetivo de este ejercicio es mostrar como se utiliza la técnica de puntos de función aplicada a un caso real. En nuestro caso, la aplicación consiste en un sistema para administrar las ventas de automóviles que realiza una empresa de compra-venta de autos usados.

En la parte 1, publicada en el número de Marzo-Abril 2007, planteamos los requerimientos iniciales, en los cuales nos basaremos para realizar el análisis. Para poder dar seguimiento a este caso, es necesario tener a la mano dicho artículo, así que por favor rescaten su ejemplar impreso, o descarguen el PDF del sitio web de SG.

Como se comentó en la parte anterior, el proceso para el análisis de puntos funcionales está formado por los siguientes pasos:
1. Determinar el tipo de conteo
2. Identificar el alcance, propósito y límites de la aplicación
3. Contar las funciones de datos
4. Contar las funciones transaccionales
5. Determinar los puntos de función no ajustados
6. Determinar el valor del factor de ajuste
7. Determinar los puntos de función ajustados

1. Determinar el tipo de Conteo
El IFPUG distingue entre 3 tipos de conteos:
• Conteo de Proyectos de Nuevo Desarrollo
• Conteo de Proyectos de Mantenimiento
• Conteo de Aplicaciones

En el caso de nuestro ejemplo, no existe una aplicación ya desarrollada que se vaya a complementar o modificar, así que estamos hablando de un nuevo desarrollo.

2. Identificar el alcance, propósito y límites de la aplicación
La identificación del alcance, es normalmente establecida en la fase de inicio o planeación del proyecto, y típicamente está documentada en forma de requerimientos de alto nivel, especificaciones funcionales, casos de uso, etc. Es común que al inicio del proceso no tengamos los requerimientos completos, pero esto no significa que no podamos continuar con el conteo. Lo que se hace en estas situaciones es complementar o llenar los vacíos de los requerimientos estableciendo supuestos que deberán ser documentados y validados con el experto de la aplicación o del negocio. La idea final es que el conteo de Puntos de Función sea reflejo fiel de los requerimientos y los supuestos. Si estos cambian, el conteo también deberá ser actualizado.
Los límites de la aplicación, establecerán la funcionalidad que será considerada externa a la aplicación. Para establecer dichos límites se tomará el punto de vista del usuario y nunca un criterio técnico o de implementación. De esta forma, si tenemos una aplicación en donde la parte batch, obtiene y procesa información para crear tablas temporales que después serán utilizadas para generar reportes on-line, dicha aplicación será considerada como una sola aplicación para este propósito.

Aplicación al caso
Alcance. El alcance es todo lo documentado en la parte 1 de este artículo (pantallas y descripciones). Así mismo, hay cosas que no están documentadas y que deberán ser asumidas con base a nuestra experiencia. Por ejemplo, en los requerimientos no se indica si habrá un login y administración de usuarios y perfiles, entonces nuestro supuesto asociado al alcance será:
• Se asume que no se requerirá funcionalidad para el manejo de seguridad.

Este supuesto será documentado y se le dará seguimiento durante el ciclo de vida, con el fin de validarlo e identificar aquellas situaciones que lo invaliden, para que en su caso, se haga una actualización del conteo.

Propósito. El conteo de puntos de función será utilizado como herramienta para la estimación, ejecución y control y cierre del proyecto. Precisamente, el propósito quedaría planteado de la forma siguiente:
1. Estimar el esfuerzo, duración y personal requeridos por el proyecto de desarrollo, utilizando algún modelo de estimación estadístico y una Base de Datos de Proyectos Históricos.
2. Controlar el crecimiento de tamaño a lo largo del ciclo de vida.
3. Controlar la cantidad de producto que es generado a lo largo del proyecto.
4. Evaluar productividad (Puntos de Funcion / Personas-Mes) y Calidad (Defectos / Puntos de Función) para dar información a los procesos de Mejora Continua del Desarrollo de Software y alimentar la Base de Datos de Proyectos Históricos que será utilizada en futuras estimaciones.

Límites de la aplicación. En la descripción del caso práctico, se describe la funcionalidad para la venta de artículos por Internet y también se hace referencia al Sistema de Inventario de Vehículos. Desde el punto de vista del usuario, se trata de aplicaciones independientes, puesto que las necesidades de negocio son diferentes e incluso los usuarios que atienden son distintos. De esta forma, tenemos 2 aplicaciones:
•Aplicación de Venta de Vehículos por Internet (la que vamos a desarrollar)
•Aplicación de Inventario de Vehículos (será referenciada por nuestra aplicación)

Aunque parezca trivial, el correcto establecimiento de las fronteras es crítico para validar la completitud y consistencia del conteo.

3. Contar las Funciones de Datos
En este paso, primero debemos identificar los almacenamientos lógicos (también conocidos como entidades de información), en cuanto a que sean totalmente independientes y que tengan un significado para el usuario. Por ejemplo, índices, tablas temporales son considerados almacenamientos técnicos creados con propósitos de implementación y no contribuyen al tamaño funcional de la aplicación. Así mismo, catálogos que contienen sólo un ID y una descripción, son almacenamientos considerados como “Code Table” y tampoco tendrán una contribución en el tamaño funcional. El punto clave para agrupar los almacenamientos lógicos, es verificando la dependencia entre ellos. Una pregunta clave, es respondernos si dicho almacenamiento puede existir de manera aislada, o si para tener significado debe formar parte de otro almacenamiento. Por ejemplo: Si tenemos la tabla de empleado, y la tabla telefonos_empleado, ambas son consideradas como un solo almacenamiento lógico, ya que telefonos_empleado no tiene significado por si sola.

Otra forma de ver esta independencia es preguntarnos: Si desaparece un registro de la tabla de empleado ¿tiene sentido para el negocio conservar el registro asociado en telefonos_empleado?. Si la respuesta es positiva, entonces se considera que cada entidad puede existir de manera independiente y por lo tanto serán dos almacenamientos lógicos. Por el contrario, si la respuesta es negativa, los almacenamientos no existen de manera independiente, y por lo tanto son un solo almacenamiento lógico.

Una vez agrupado e identificado el almacenamiento lógico, lo clasificaremos en ILF (Internal Logical File) o un EIF (External Interface File). Será ILF si dicho almacenamiento es mantenido por al menos una funcion transaccional dentro de la aplicación que contamos. Por otro lado, será un EIF si dicho almacenamiento es UNICAMENTE referenciado y no mantenido por la aplicación que estamos contando.

Para determinar la complejidad de un almacenamiento, ya sea ILF o EIF, se debe hacer un conteo de lo que se conoce como DETs y RETs. Los DETs son los campos de datos únicos e identificables por el usuario y por otro lado, los RETs, son los subgrupos de datos en el mismo almacenamiento y que son identificables por el usuario, cuando en el almacenamiento no hay subgrupos de datos, se considera que el almacenamiento tiene un solo RET.
Por último, la contribución en function points del almacenamiento, será obtenido con base a la complejidad y tipo de almacenamiento, utilizando las siguientes tablas:

Tabla 1. Tabla para determinar complejidad de funciones de datos

Tabla 2. Puntos de función correspondientes a funciones de datos de acuerdo a su complejidad

Aplicación al caso
En nuestro caso práctico, vemos que el Sistema de Inventario de Vehículos, tiene responsabilidad de mantener las tablas de “vehículo” y “accesorios_vehículo”. Dichos almacenamientos forman un solo almacenamiento lógico llamado “vehículo”, puesto que el almacenamiento de “accesorios_vehículo” no tiene significado por sí solo. Dicho almacenamiento de “vehículo” es referenciado por nuestra aplicación, pero no es mantenido por esta, por lo cual es catalogado como un “EIF”.

La complejidad de nuestro almacenamiento está en función de sus DETs y RETs. Para ver el número de DETs debemos ver los campos que son únicos e identificables por el usuario. En este caso tenemos número de serie, marca, modelo, año-modelo, color, kilometraje, condición, foto, precio, disponibilidad y nombre accesorio, para un total de 11 DETs. Para este almacenamiento, no existen subgrupos de información, por lo que el almacenamiento tendrá un solo RET. De acuerdo a esto, usando los valores de las tablas 1 y 2 determinamos que nuestro almacenamiento corresponde a una complejidad baja, y una contribución de 5 puntos de función.

Por otro lado, existe otro almacenamiento que debemos considerar, y es el de “Compra”. En dicho almacenamiento, son guardados los datos del comprador, su financiera, su aseguradora, el ID de la compra y el número de serie del vehículo comprado. Al ser mantenido por la aplicación que estamos contando, dicho almacenamiento se clasifica como “ILF”, y al contar sus campos únicos identificables por el usuario, llegamos a un total de 13 DETs. No tenemos subgrupos de información identificables por el usuario, así que tenemos un solo RET. Buscando en las tablas, encontramos que dicho almacenamiento corresponde a una complejidad baja y corresponde a 7 puntos.

4. Contar las Funciones Transaccionales
Este es uno de los pasos que tienen mayor impacto en el conteo de los Puntos de Función y comienza con la identificación de los Procesos Elementales. Un proceso elemental es la unidad mínima de actividad significativa al usuario, que deja al negocio en un estado consistente y es autocontenido.

Una vez identificado el proceso elemental, éste debe ser clasificado para convertirse en una función transaccional. Existen 3 tipos de funciones transaccionales: EI (External Input), EQ (External Inquiry), y EO (External Output). Dicha clasificación se hace con base al propósito principal de la función. Si el propósito principal de la función es recibir información para administrar (crear, modificar, eliminar) un almacenamiento, el tipo de función sera EI. Si, por el contrario, el propósito principal fuera sólo presentar información y no realizar ningún procesamiento adicional, la función es clasificada como EQ, y por último, si el propósito principal es presentar información y además realizar algún procesamiento adicional (como cálculos matemáticos, derivación de datos, etc) entonces la función se clasifica como un EO.

La complejidad de las funciones transaccionales depende del número de DETs y FTRs. Los DETs, en las funciones transaccionales, son campos únicos de información que son identificables por el usuario y que entran o salen de la función transaccional. Por mencionar sólo algunos criterios de conteo, aplicables al conteo de DETs para las funciones transaccionales, se tienen los siguientes:
•Para ser contado el DET debe entrar o salir de la aplicación, es decir un campo que sea utilizados internamente y que no entre o salga de la aplicación no es contado como DET.
•Las etiquetas, nombres de campo, nombres de columna y variables de sistema como (fecha de sistema, número de página, número de columna, etc) no son contados.
•En aplicaciones on-line, contamos 1 DET para la capacidad de ejecución sin importar de cuantas formas distintas se pueda ejecutar el proceso elemental. Por ejemplo, si podemos ejecutar la función de “Insertar Empleado” presionando el botón “Salvar” o presionando Ctrl-I o dando click en una opción de menú, sólo contaremos un DET por la capacidad para ejecutar dicha función.
•En aplicaciones on-line, contamos 1 DET para la capacidad de envio de mensajes, sin importar cuantos mensajes sean enviados dentro de la misma función transaccional. Por ejemplo, en la función “Insertar Empleado”, por ejemplo, podrían hacerse diversas validaciones sobre cada uno de los datos capturados (longitud del campo, formato de la fecha, etc), sin importar cuantas validaciones sean realizadas, sólo se contará un DET por la capacidad de generar mensajes en dicha función transaccional.

Por otro lado los FTRs, son el número de funciones de datos que son mantenidas y/o referenciadas por la Función Transaccional.

Con el número de DETs y FTRs y además el tipo de cada función transaccional, se consultará en las siguientes tablas la complejidad:

Tabla 3. Tabla para determinar complejidad de External Input (EI)

Tabla 4. Tabla para determinar complejidad de E xternal Inquiry (EQ) y External Output (EO)

Una vez obtenida la complejidad, la contribución de la función transaccional en Puntos de Función No Ajustados, se obtiene con la siguiente tabla:



Tabla 5. Puntos de función correspondientes a funciones transaccionales

Aplicación al caso
El primer proceso elemental identificado en nuestro caso de estudio es “Consultar Listado de Vehículos”, el cual está implementado por las pantallas 1 y 2. La pantalla 1 no es un proceso elemental por sí sola, debido a que no tiene sentido para el usuario el solo ingresar los parámetros de consulta y no hacer nada más. El ingresar los parámetros de consulta y mostrar los resultados de dicha consulta forman un solo proceso elemental, puesto que es la unidad mínima de actividad que tiene significado para el usuario, deja al negocio en un estado consistente y es autocontenido. Este proceso elemental tiene el propósito principal de presentar información y no incluye procesamiento adicional, por lo que es catalogado como un EQ. Los campos únicos que son presentados en las pantallas 1 y 2 y que corresponden a la función “Consultar Listado de Vehículos” son 7: año_modelo, marca, modelo, accesorios, precio, color y condición. Adicionalmente, se cuenta un DET para la capacidad de ejecución (cuando se presiona el botón de “buscar”), y otro DET para la capacidad de envío de mensajes (cuando no es encontrado ningún vehículo con las características indicadas), resultando en un total de 9 DETs. La información requerida por esta función transaccional es obtenida de la Función de Datos “Vehículo”, por lo tanto el número de FTR es uno. La complejidad resultante de esta función EQ, con 9 DETs y 1 FTR, es “Baja” según lo indicado en la tabla 4 y su contribución es de 3 puntos, según lo indicado en la tabla 5.
El segundo proceso elemental identificado es “Consultar Detalle de Vehículo”, el cual corresponde a una parte de la pantalla 2 (cuando se selecciona un vehículo y se presiona el botón “Ver Detalle”) y la pantalla 3. Dado que no se realiza procesamiento adicional, esta función se clasifica como un EQ con 7 DETs, correspondientes a: color, kilometraje, condición, número de serie, precio, accesorios (aunque el campo se repite, sólo se cuenta como un DET) y la capacidad de ejecución (cuando en la pantalla 2 se presiona el botón “Ver Detalle”). Toda la información se obtiene de la función de datos “Vehículo”, así que solo es un FTR. De esto, obtenemos que la complejidad de esta función tipo EQ, con 7 DETs y 1 FTR es baja y tiene una contribución de 3 Puntos de Función.

El tercer proceso elemental identificado corresponde a la funcionalidad de comprar el vehículo o “Insertar Compra”. Dicha función está formada por el procesamiento que incluye permitir la captura, salvar la compra, actualizar el campo de estado en el inventario de vehículos y además enviar el correo al comprador. Aunque estos procesos parecieran ser funciones independientes, al analizarlos nos damos cuenta que no tienen sentido por sí solos o no dejan al negocio en un estado consistente. El proceso elemental de “Insertar Compra” se encarga de mantener la función de datos “Compra”, y por ello es clasificado como un “EI”. Los DETs únicos que entran o salen en los diferentes procesamientos que conforman esta función son: capturar los datos, salvar, almacenar el campo de estado del vehículo, y enviar el e-mail. Cuando se capturan los datos tenemos 11 DETs que aparecen en la pantalla 4, a lo que agregamos la capacidad de ejecución, para un total de 12 DETs. En el procesamiento de envío del e-mail al comprador, se tiene un DET que no ha sido contado en la función transaccional, que es: “número de compra”. Este nuevo DET mas los 12 previos, nos da un total de 13 DETs para esta función. Ahora bien, “Insertar Compra” requiere usar la función de datos “Compra” para insertar el nuevo registro y también requiere de la función de datos “Vehículo”, para actualizar el valor del campo “Estado de disponibilidad del Vehículo”, así que el FTR será igual a 2. La complejidad de la función EI con 13 DETs y 2 FTRs es igual a “Media” y su contribución es de 4 Puntos de Función.

Por último, se cuentan los drop-downs como funcionalidades de “Consultar Listado de…”. Por lo que consideraremos los siguientes procesos elementales:
•Consultar Listado de Año_Modelo. Drop Down
•Consultar Listado de Marca/Modelo. Drop Down
•Consultar Listado de Accesorios. Drop Down
•Consultar Listado de Rango de Precios. Drop Down

Los primeros 3 procesos solo presentan información y no realizan ningún procesamiento adicional, por lo que quedan clasificados como “EQs”. En cambio, “Consultar Listado de Rango de Precios”, requiere adicionalmente hacer algún procesamiento (calcular los rangos con base a los valores mínimos y máximos) para luego presentar los datos, por lo tanto dicho proceso es clasificado como un “EO”.

Para calcular la complejidad de los drop-downs, se considera un DET para la capacidad de ejecución (cuando se presiona la flechita y se despliega el drop down) y los DETs de datos que son mostrados. En el caso del drop-down de año modelo contamos 2 DETs (capacidad de ejecución y el DET año-modelo), para el drop down de Marca-Modelo, contamos 3 DETs (Capacidad de ejecución, marca y modelo), para el de Accesorios contamos 2 DETs (capacidad de ejecución y el DET de accesorio) y para el de Rango de Precios contamos 2 DETs (capacidad de ejecución y rango). Todos estos drop downs tendrán un FTR igual a 1 dado que sólo consultan la función de datos “Vehículo”.

Así que según nuestras tablas, los 3 procesos elementales tipo EQ que tenemos, tienen una complejidad baja que corresponde a 3 puntos cada uno, mientras que “Consultar Listado de Rango de Precios” también tiene complejidad baja, pero al ser una función del tipo “EO” contribuirá en 4 puntos de función.

5. Determinar los puntos de función no ajustados
En este paso, simplemente determinamos el total de puntos de función no ajustados, sumando los puntos correspondientes a las funciones de datos encontradas en el paso 3, y las funciones transaccionales encontradas en el paso 4. La siguiente tabla refleja el total de puntos de función no ajustados para nuestro caso:

Tabla 6. Total de puntos función

Próximos pasos
En el próximo artículo de esta serie, aprendemos a determinar el factor de ajuste, para poder determinar la cantidad de puntos de función ajustados que corresponde a nuestra aplicación. ¡Hasta entonces!

Acerca del autor
Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido responsable de la estimación de proyectos de software críticos para EDS de México y Latinoamérica. Ha impartido entrenamiento en la técnica de Puntos de Función y estimaciones a más de 300 personas en 5 países latinoamericanos y Canadá. Actualmente se desempeña como consultor en Project Management e Ingeniería de Software.