Comparando Predicciones de Estimación de Esfuerzo en una Start-up, Utilizando Puntos de Función

Transcripción

1 Comparando Predicciones de Estimación de Esfuerzo en una Start-up, Utilizando Puntos de Función Luis Emmanuel Herrera Gárnica Resumen: Existen numerosas técnicas para estimar plazos y esfuerzo de proyectos de desarrollo de software, incluyendo Puntos de Función (FP, Function Points) y estimación con ojo experto, pero pocas han sido aplicadas a start-ups. Este trabajo estimará plazos y esfuerzo para un desarrollo específico en una start-up chilena, usando el modelo de FP: IFPUG FPA. Al término de este trabajo de tesina, se podrá comprobar que las estimaciones obtenidas utilizando IFPUG FPA, son sistemáticamente más cercanas que el "ojo experto" respecto a las horas hombre reales. La empresa recibirá información sobre la precisión de las estimaciones y sobre el esfuerzo requerido para realizar cada una. Esta información será un apoyo sobre su eventual adopción para futuros desarrollos, siendo de gran ayuda, a la hora de la planificación de un nuevo proyecto. Palabras Clave: Medición, estimación, IFPUG, Software. 1 Introducción En el presente trabajo de tesina comienza con las bases teóricas que sustentan el trabajo, dando a conocer los conceptos principales del modelo de medición utilizado de puntos de función IFPUG FPA. En el capítulo 3 se describirá el ámbito del problema, así como los conceptos importantes involucrados en el caso de estudio. El capítulo 4 expondrá el desarrollo del caso de estudio en donde se obtendrá el peso de la aplicación en puntos función obtenidos. El capítulo 5 detalla el análisis de los resultados obtenidos, tanto como el peso de cada punto de función y los tiempos reales dedicados al desarrollo del sistema utilizado como caso de estudio. Finalmente, el capítulo 6 revelará las conclusiones de los análisis realizados, determinando así la factibilidad de incentivar la aplicación de este modelo a otras start-up como tareas futuras a realizar. 2 Marco teórico Medición es el proceso mediante el cual se asignan números o símbolos a los atributos de las entidades en el mundo real, de manera que se les define de acuerdo con reglas claramente determinadas, en las ciencias físicas, medicina, economía y más recientemente en ciencias sociales, ahora es posible medir atributos que anteriormente se consideraban inmensurables. Desde luego, tales mediciones, no son tan refinadas como muchas mediciones en las ciencias físicas, pero existen y con base en ellas se toman importantes decisiones. Sentimos que la obligación de intentar medir lo inmensurable para mejorar la comprensión de las entidades particulares es tan poderosa en la ingeniería de software, como en cualquier otra disciplina (Pressman, 2010). En los últimos cuarenta años, se ha propuesto un número significativo de métricas de software para controlar y comprender mejor las prácticas y los productos de desarrollo, Aunque esta expresión se utiliza ampliamente en la literatura, no necesariamente tiene la misma interpretación de autor a autor, diversos trabajos a veces indican que en el mismo texto la misma expresión se utiliza a menudo, con distintos significados, dejando confusiones en cuanto a los temas precisos que se discuten e investigan. Del mismo modo, del número significativo de 1

2 métricas propuestas, pocas se han estudiado Estrechamente desde una perspectiva metrológica. Además, actualmente es difícil analizar la calidad de estas métricas debido a la falta de un marco de trabajo que siga un estándar acordado (Abran, 2010). El análisis de puntos de función, es un método estándar para medir el desarrollo de software desde el punto de vista del usuario. Mide el software cuantificando la funcionalidad proporcionada al usuario, basado principalmente en el diseño lógico. Con esto en mente, los objetivos del análisis de puntos de función son: (Gómez, 2014) Medir la funcionalidad que el usuario solicita y recibe. Medir el desarrollo y mantenimiento de software independientemente de la tecnología utilizada para la implementación. Además de cumplir los objetivos anteriores, los procesos de contar los puntos de función deben ser: Suficientemente simples para minimizar la sobrecarga del proceso de medición. Una medida consistente entre varios proyectos y organizaciones (International Function Point Users Group (IFPUG), 2009). IFPUG FPA es el método de análisis en puntos función (FPA, Function Point Analysis) heredero directo del método creado por Allan Albrecht en IFPUG es el International Function Points Users Group o, en español, el Grupo Internacional de Usuarios de Puntos Función. Una pieza vital del IFPUG FPA es el usuario. Toda la identificación de funciones de datos y funciones transaccionales se basa en esta figura y en la percepción que tiene de la aplicación o sistema. Usuario es cualquier persona que especifica los Requerimientos Funcionales de Usuario y/o cualquier persona o cosa que se comunique o interactúe con la aplicación en cualquier momento. Un usuario puede ser tanto un operador que utiliza las pantallas de la aplicación como otro sistema que se comunica a través de interfaces de datos. Además, cada punto de función debe ser identificable por el usuario, es decir, los requisitos acordados y entendidos por desarrolladores y por usuarios, definidos para los procesos y/o los grupos de datos del sistema. Con estos conceptos, se sabe que es lo que determina y define cada elemento dentro del software, entonces queda acotar el objeto del conteo y para ello se debe identificar el propósito y alcance de la medición. 2.1 Propósito de la medición El propósito de la medición determina el tipo de medición de los puntos función. Las mediciones de puntos de función pueden estar asociadas tanto a proyectos como a aplicaciones, existen tres tipos de medición: Medición de puntos de función de un proyecto de desarrollo. En este tipo de medición de puntos de función se miden las funciones proporcionadas al usuario por el proyecto en la primera instalación del software que se ha desarrollado. Medición de puntos de función de un proyecto de mejora. En este tipo de medición de puntos de función se miden las modificaciones a la aplicación existente entregadas a la finalización del proyecto. Las modificaciones se entienden como las acciones que incorporan, cambian o eliminan funciones de usuario. Medición de puntos función de una aplicación. En este tipo de medición de puntos de función se miden las funciones actuales que la aplicación proporciona al usuario. Este tipo de medición se refiere siempre a una aplicación existente y también se denomina medida de puntos función de línea base o instalada. Se puede conseguir directamente a través de la medición de la aplicación o partiendo de la medición de un proyecto de desarrollo como primera medida, para posteriormente actualizarla con las mediciones de todos los proyectos de mejora que hayan tenido lugar después. 2

3 2.2 Alcance de la medición Determina qué funcionalidad está dentro del estudio que estamos realizando. Define el conjunto o subconjunto del software que está siendo medido. Podría incluir más de una aplicación. Según su propósito, el alcance de la medición pueden ser sólo las funciones utilizadas por el usuario o todas las funciones entregadas (Gómez, 2014). El método IFPUG FPA se basa en dividir la funcionalidad del sistema a medir en dos tipos de funciones: Funciones de Datos. Estas funciones tratan de modelar las necesidades de almacenamiento de información que tiene el usuario. Las funciones de datos también se denominan grupos lógicos o información de control. y son una generalización del concepto de Entidad, pero se debe tener cuidado porque, aunque pueden coincidir no siempre es así. Además, representan la funcionalidad proporcionada al usuario para satisfacer los requisitos de datos internos y externos. Entendiendo por fichero a un grupo de datos lógicamente relacionados y no a una implementación física de estos grupos de datos, tenemos dos tipos diferentes de funciones de datos: ILF (Internal Logical File). Son grupos de datos o información de control relacionados lógicamente, identificables por el usuario y mantenidos dentro de la aplicación. El propósito principal es almacenar datos mantenidos por uno o más procesos elementales de la propia aplicación. EIF (External Interface File). Grupos de datos o información de control lógicamente relacionados, identificables por el usuario, pero mantenidos dentro de los límites de otra aplicación. El propósito principal de un EIF es almacenar datos referenciados por uno o más procesos elementales dentro de los límites de la aplicación. De aquí que un EIF para nuestra aplicación debe ser un ILF de otra. Elementos que componen los ILF y EIF. DET (Data Element Type). Es un campo único, no repetido, reconocible por el usuario, las reglas para determinar un DET son las siguientes: Contar un DET por cada campo único, no repetido, reconocible por el usuario, mantenido o recuperado por un proceso elemental de un ILF o EIF. Contar un DET por cada parte de información requerida por el usuario para establecer una relación con otro ILF o EIF. RET (Register Element Type). Es un subgrupo de elementos de datos reconocible por el usuario, dentro de un ILF o un EIF. Estos se pueden distinguir en dos tipos: Opcionales o subgrupos opcionales. Son aquellos en los cuales el usuario puede elegirlo o no al crear una ocurrencia de los datos. Obligatorios o subgrupos obligatorios. son aquellos en los cuales el usuario debe utilizar al menos uno. Las reglas para determinar estos RETs son las siguientes. Contar un RET por cada subgrupo opcional u obligatorio del ILF o EIF que se esté contando. Si no existe ningún subgrupo contar que el ILF tiene 1 subgrupo, es decir, tienen al menos un RET. Las funciones de datos se miden en Puntos de Función de acuerdo a los DET y RET que se les identifiquen. Funciones transaccionales. Estas funciones, también llamadas procesos elementales, intentan modelar las necesidades de proceso del usuario. Son la unidad de actividad más pequeña que tiene sentido para el usuario. Además, deben ser autosuficientes y dejar a la aplicación en un estado consistente desde un punto de vista del negocio de la aplicación. Representan la funcionalidad proporcionada al usuario para el procesamiento de los datos a través de la aplicación. Según el propósito principal de la función transaccional, éstas se dividen en tres tipos. Bien sea este propósito mantener un (ILF o EIF) o alterar el comportamiento del sistema, bien sea mostrar información al usuario. EI (External Input). Es un proceso elemental que procesa datos o información de control que provienen de fuera de los límites de la aplicación cuyo propósito principal es mantener uno o más (ILF o EIF) y/o modificar el comportamiento del sistema. 3

4 EO (External Output). Es un proceso elemental que envía datos o información de control fuera de los límites de la aplicación y cuyo propósito principal es presentar información al usuario conteniendo la lógica de proceso al menos una fórmula matemática o un cálculo, la creación de un dato derivado, el mantenimiento de al menos un (ILF o EIF) del sistema o alterar el comportamiento del mismo. EQ (External Inquiry). Es un proceso elemental que envía datos o información de control fuera de los límites de la aplicación y cuyo propósito principal es presentar información al usuario sin que su lógica de proceso contenta fórmulas matemáticas o cálculos, ni cree datos derivados, ni mantenga ningún (ILF o EIF) y no altere el comportamiento del sistema. Cada proceso elemental realiza una serie de acciones solicitadas por el usuario para cumplir una tarea determinada, esto es la lógica de proceso. Figura 1. Identificación del tipo de función transaccional (Gómez, 2014) La figura 1 muestra el cómo se identifica el tipo de función transaccional donde: (x) La acción es opcional. (o*) Al menos una de las acciones así, señaladas es obligatoria. (ob) La acción es obligatoria. (-) La acción está prohibida. El valor de una medición en puntos función de un sistema, es la suma del valor de los puntos función de sus funciones transaccionales y de sus funciones de datos. Las funciones transaccionales están compuestas de los DET y RET que se mencionaron en las funciones de datos, pero además estas contienen los denominados FTR (File Type Reference), esto es un ILF leído o mantenido por una función transaccional o un EIF leído por dicha función. Las reglas para la identificación de estos elementos para una función transaccional son las siguientes: Identificación de los DETs. Para un EI. Contaremos un DET por cada campo no repetido, reconocible por el usuario que entra o sale de los límites de la aplicación y es requerido para completar la entrada externa. 4

5 Contaremos un DET por la capacidad de enviar un mensaje de error durante el proceso fuera de los límites del sistema, confirmar que el proceso finalizó o verificar que el proceso debería continuar. Contaremos un DET por la capacidad de especificar la acción a realizar, aunque haya más de una forma de hacerlo. No se contarán campos que son recuperados o derivados por el sistema y almacenados en un ILF durante un proceso elemental si los campos no cruzan los límites de la aplicación. No se contarán literales (Labels) como DET. No se contarán variables de paginación o marcas generadas por el sistema. Para un EO/EQ Contaremos un DET por cada campo no repetido, reconocible por el usuario que entra en la aplicación y es requerido para especificar cuándo, qué y/o cómo los datos son recuperados o generados por el proceso elemental. Contaremos un DET por cada campo no repetido, reconocible por el usuario que sale de los límites de la aplicación. Si un DET entra y sale de los límites de la aplicación lo contaremos una sola vez. Contaremos un DET por la capacidad de enviar un mensaje de error durante el proceso fuera de los límites del sistema, confirmar que el proceso finalizó o verificar que el proceso debería continuar. Contaremos un DET por la capacidad de especificar la acción a realizar, aunque haya más de una forma de hacerlo. No se contarán campos que son recuperados o derivados por el sistema y almacenados en un ILF durante un proceso elemental si los campos no cruzan los límites de la aplicación. No se contarán literales como DET. No se contarán variables de paginación o marcas generadas por el sistema. Identificación de los FTR. Contaremos un FTR por cada ILF mantenido o mantenido y leído. Contaremos un FTR por cada (ILF/EIF) leído. Hasta el momento se está preparado entonces para determinar los puntos de función no ajustados, estos puntos de función son hasta donde llega el método IFPUG (ISO/IEC 20926:2009), pero además el método IFPUG FPA incluye el valor del factor de ajuste, este nos permite ponderar el valor de los puntos de función no ajustados en un valor ajustado. Este valor se calcula evaluando el grado de influencia que tiene cada una de las 14 Características Generales del Sistema ó GSCs (General System Caracteristics) en el sistema que estamos midiendo. El grado de influencia de cada característica va desde 0 (Sin influencia) a 5 (Influencia Fuerte). Las características generales del sistema son: (International Function Point Users Group (IFPUG), 2009) Comunicaciones de datos (Data Comunications). Los datos y la información de control usada en la aplicación son enviados o recibidos sobre recursos de infraestructura de comunicaciones. Valores: Sistema aislado del exterior, tiene un valor de 0. Aplicación Batch con entrada de datos remota o utilización de periféricos de salida remotos tiene un valor de 1. Aplicación Batch con entrada de datos remota y utilización de periféricos de salidas remotos, tiene un valor de 2. Aplicación de captura de datos en línea o hay un sistema de Teleproceso que pasa los datos a la aplicación Batch o sistema de consulta, tiene un valor de 3. Varios teleprocesos, pero con el mismo protocolo de comunicaciones, tiene un valor de 4. Hay teleproceso con varios protocolos de comunicación. Sistema abierto y con interfaces de todo tipo al exterior, tiene un valor de 5. 5

6 Procesamiento Distribuido (Distributed Data Procesing). Los Datos o funciones de procesamiento distribuido son una característica dentro de los límites de la aplicación. Valores: Sistema totalmente Centralizado o no tiene como objetivo el transferir datos o procesos entre componentes del sistema, tiene un valor de 0. El sistema realiza sus procesos en un equipo, pero las salidas se preparan de modo que son utilizadas vía software de otros equipos. Por ejemplo, a la salida del sistema se accede vía una hoja de cálculo o un procesador de textos en un PC, tiene un valor de 1. El sistema captura los datos en un equipo, que les da formato, siendo enviados a otro equipo del sistema que los trata, tiene un valor de 2. Proceso distribuido, pero con transferencia de datos "en línea" en una sola dirección, tiene un valor de 3. Proceso de datos distribuidos y transferencia de datos "en línea" en ambas direcciones. Por ejemplo, una red de cajeros automáticos en donde éstos procesan parte la transacción, tiene un valor de 4. El sistema está ejecutándose en una red con procesos cooperantes ejecutándose en distintos equipos, tiene un valor de 5. Rendimiento (Performance): Los Objetivos del funcionamiento de la aplicación, indicados o aprobados por el usuario, en tiempo de respuesta o throughtput, influyen (o impactarán) el diseño, el desarrollo, la instalación y el soporte de la aplicación. Valores: Rendimiento normal, tiene un valor de 0. Se indican requerimientos de rendimiento y del diseño que son revisados, pero no es necesario tomar medidas especiales, tiene un valor de 1. El tiempo de respuesta o cantidad de operaciones por hora es crítico en algunos momentos. No se solicita que realicemos un diseño de la utilización de la CPU. Los procesos deberán estar terminados antes de la siguiente sesión de trabajo (próximo día), tiene un valor de 2. El tiempo de respuesta o cantidad de operaciones por hora es crítico durante todas las horas de trabajo. No se solicita que realicemos un diseño de la utilización de la CPU. Los requerimientos indican que los procesos con sistemas de interfaz deberán estar terminados según ciertas restricciones, tiene un valor de 3. Además, los requerimientos indican que el tiempo de respuesta o la cantidad de operaciones por hora es lo suficientemente crítico, como para requerir tareas de análisis de rendimiento durante la fase de diseño, tiene un valor de 4. Además, se utilizan herramientas de análisis de rendimiento durante el diseño, desarrollo e instalación, con el objetivo de alcanzar el rendimiento demandado por el usuario, tiene un valor de 5. Grado de uso de la configuración operacional (Heavily used configuration). Una configuración operacional con alto grado de uso, requiere consideraciones especiales del diseño, es una característica de la aplicación. Valores: No se han indicado restricciones ni explícita ni implícitamente, tiene un valor de 0. Existen restricciones, pero son las usuales de cualquier equipo departamental. No es necesario hacer consideraciones especiales, tiene un valor de 1. El usuario declara explícitamente características de seguridad o relativos a tiempos, tiene un valor de 2. Algunos programas deben funcionar con restricciones en algún procesador, tiene un valor de 3. Las restricciones operativas definidas implican que el software deberá funcionar con restricciones de uso del procesador central o en un procesador dedicado, tiene un valor de 4. Además, hay restricciones especiales para la aplicación en los componentes distribuidos, tiene un valor de 5. Tasa de Transacciones (Transaction Rate). La tasa de transacciones será elevada. Se tendrá que hacer consideraciones especiales durante el diseño, codificación e instalación. Valores: No se prevén períodos con picos de transacciones, tiene un valor de 0. Se prevén picos de operaciones de forma regular, pero poco frecuente (mensualmente, trimestralmente o anualmente). Ejemplos serían los cierres de contabilidad, o el préstamo de libros antes de los exámenes, tiene un valor de 1. 6

7 Se prevén picos de operaciones semanales, tiene un valor de 2. Se prevén horas punta, diarias. Ejemplo sería las ventas en los supermercados, tiene un valor de 3. La tasa de transacciones se prevé tan elevada que durante el diseño se debe incluir tareas de análisis del rendimiento, tiene un valor de 4. Se ha especificado una cantidad de transacciones muy elevada. Se utilizarán herramientas de análisis de rendimiento durante el diseño, implementación e instalación, tiene un valor de 5. Entrada de datos en línea (Online Data Entry). La entrada de datos será directa desde el usuario a la aplicación, de forma interactiva. Valores: No hay entrada de datos interactiva, todo es Batch, tiene un valor de 0. Entre el 1% y el 7% de las transacciones son entradas interactivas, tiene un valor de 1. Entre el 8% y el 15% de las transacciones son entradas interactivas, tiene un valor de 2. Entre el 16% y el 23% de las transacciones son entradas interactivas, tiene un valor de 3. Entre el 24% y el 30% de las transacciones son entradas interactivas, tiene un valor de 4. Las entradas de datos interactivas superan el 30% de las transacciones, tiene un valor de 5. Eficiencia del Usuario Final. (End User-Efficiency). Se demanda eficiencia para el usuario en su trabajo, es decir se tiene que diseñar e implementar la aplicación con interfaces fáciles de usar y con ayudas integradas. Los factores asociados a la eficiencia del usuario son: Menús, Ayudas en línea, Movimiento automático del cursor, Efectos de Scroll (papiro). Impresión remota (mediante transacciones en línea), Teclas de función predefinidas. Lanzamiento de procesos Batch desde las transacciones "en línea. Selección mediante cursor de datos de la pantalla, Pantallas con muchos colores y efectos. Documentación impresa de las operaciones en línea, Uso de mouse, Ventanas de pop-up. Forzar la aplicación a tener el menor número posible de pantallas por transacción, Aplicación bilingüe. Aplicación Multilingüe. Valores: No hay especial énfasis en los interfaces de uso con el usuario, tiene un valor de 0. De uno a tres de los factores anteriores, tiene un valor de 1. De cuatro a cinco, tiene un valor de 2. Seis o más factores, pero sin especiales requerimientos de eficiencia, tiene un valor de 3. Más de seis factores, con requerimientos lo suficientemente específicos como para justificar en el diseño estudios de los factores humanos. Ejemplo: minimizar la cantidad de pulsaciones, proveer valores por defecto, uso de marcos estandarizados, etc., tiene un valor de 4. Igual al anterior, pero los requerimientos son tan fuertes que se demanda la construcción de prototipos y utilización de herramientas para su evaluación y comprobar que se alcanzarán los objetivos, tiene un valor de 5. Actualizaciones en línea (OnLine Update). Los archivos maestros y las Bases de Datos son modificadas directamente de forma interactiva. Valores: No hay actualizaciones interactivas, tiene un valor de 0. Actualización en línea de uno a tres ficheros con información de control. Ejemplo fichero con usuarios, horas en que se puede acceder, etc. La cantidad de actualizaciones es baja y es fácil recuperar el fichero, tiene un valor de 1. Igual al anterior, pero con cuatro o más ficheros de control, tiene un valor de 2. Actualización En-Línea de ficheros lógicos internos importantes. Ejemplo: en un banco sería TRANSACCIONES, CLIENTES, CUENTAS, etc., tiene un valor de 3. Además de lo anterior, es esencial la protección ante perdidas y el sistema se ha de diseñar e implementar con estas consideraciones, tiene un valor de 4. 7

8 Gran cantidad de actualizaciones interactivas, debiéndose considerar los costes de recuperación. Además, deben tenerse sistemas de recuperación, en caso de fallo, muy automatizados y con poca intervención del operador, tiene un valor de 5. Complejidad de procesamiento (Complex Processing). La complejidad de los procesos es una característica de la aplicación. Alguna de las siguientes características, están presentes: Los algoritmos matemáticos especificados complejos. Procesos con lógica compleja. Se han especificado muchas excepciones, consecuencia de transacciones incompletas, que deberán tratarse. Manejar múltiples dispositivos de entrada/salida. La aplicación llevará incorporados sistemas de seguridad y control. Valores: No se da ninguna de las características anteriores, tiene un valor de 0. Se da una característica de las enunciadas, tiene un valor de 1. Se dan dos características de las enunciadas, tiene un valor de 2. Se dan tres características de las enunciadas, tiene un valor de 3. Se dan cuatro características de las enunciadas, tiene un valor de 4. Se dan las cinco características de las enunciadas, tiene un valor de 5. Reusabilidad del código (Reusability). La aplicación y su código se han diseñado, desarrollado y soportado específicamente para ser usados en otras aplicaciones. Valores: No se piensa en reutilizar el código a generar, tiene un valor de 0. Se pretende reutilizar el código a generar dentro de la propia aplicación, tiene un valor de 1. Menos del 10% de la aplicación tiene en cuenta las necesidades de más de un usuario (sistema), tiene un valor de 2. El 10% de la aplicación o más tiene en cuenta las necesidades de más de un usuario (sistema), tiene un valor de 3. La aplicación ha sido específicamente empaquetada y/o documentada para ser fácil de reutilizar. La aplicación se adaptará a las necesidades de los usuarios a nivel de código, tiene un valor de 4. La aplicación ha sido específicamente empaquetada y/o documentada para ser fácil de reutilizar. La aplicación se adaptará a las necesidades de los usuarios por medio de parámetros, tiene un valor de 5. Facilidad de Instalación (Installation ease). Existencia de facilidades de conversión (upgrades) y de instalación. Las herramientas y planes de conversión y de instalación serán proporcionados y probados durante la fase de la prueba del sistema. Valores: No reemplazamos un sistema existente o no se requiere conversión. Tampoco se enuncia nada sobre la instalación, tiene un valor de 0. Se solicita facilidad de instalación, tiene un valor de 1. Se ha solicitado procesos de conversión e instalación, se han construido guías y han sido probadas, pero no son considerados importantes en el proyecto, tiene un valor de 2. Se han solicitado procesos de conversión e instalación, dándose guías explícitas, y estos procesos han de ser probados. En este proyecto se considera muy importante el proceso de conversión, tiene un valor de 3. Adicionalmente a la valoración de 2 se añade el que tendrán que desarrollarse herramientas de conversión e instalación probadas, tiene un valor de 4. Adicionalmente a la valoración de 3 se añade el que tendrán que desarrollarse herramientas de conversión e instalación probadas. El sistema es crítico para la empresa y ya estaba automatizado. Los usuarios no pueden permitirse el lujo de tener problemas o bajo rendimiento durante la transición. Estas condiciones se han descrito como requisitos a cumplir por el sistema, tiene un valor de 5. Facilidades Operacionales (Operational ease). Existencia de facilidades operacionales. Los procedimientos de partida, respaldo y recuperación serán provistos y probados en la fase de pruebas. Se pueden tener en cuenta las siguientes posibilidades de automatización: 8

9 Se proveerá de procesos de arranque, back-up y recuperación, pero con intervención del operador. Se proveerá de procesos de arranque, back-up y recuperación, pero sin intervención del operador (vale por dos). En la aplicación se minimiza la necesidad de montar cintas u otros dispositivos de almacenamiento externo. Se minimiza la necesidad de manejar papel. Valores: No se especifica nada, en todo caso lo que debieran ser procedimientos usuales de back-up, tiene un valor de 5. Sumar la cantidad de ítems en la lista anterior, tiene un valor de entre 1 a 4. Sistema automático sin intervención humana, tiene un valor de 5. Múltiples Localizaciones (Multiple Sites). La aplicación se ha diseñado para soportar múltiples sitios, instalaciones y en diferentes organizaciones. Valores: En sólo un lugar, tiene un valor de 0. Múltiples lugares, pero con idéntico Hardware y entorno Software, tiene un valor de 1. En el diseño se ha de tener en cuenta que rodará en diferentes entornos, pero con Hardware y Software similares, tiene un valor de 2. La aplicación deberá rodar en múltiples entornos de Hardware o Software y se tiene en cuenta desde la fase de diseño, tiene un valor de 3. Se documentará y se planearán sistemas para dar soporte a las situaciones descritas en las valoraciones 1 o 2, tiene un valor de 4. Se documentará y se planearán sistemas para dar soporte a la situación descrita en la valoración 3, tiene un valor de 5. Facilidades de cambio (Facilitate Change). La aplicación ha sido específicamente diseñada, desarrollada y soportada para facilitar los cambios Contempla: Valores: Si no se especifica nada, tiene un valor de 0. Consultas flexibles del usuario. Podemos tener Consultas: o Simples con condiciones lógicas And/Or que implican un solo fichero lógico. Contar 1. o Medias con condiciones lógicas de complejidad media mediante And/Or que relacionan a más de un o fichero lógico. Contar 2. Complejas con condiciones lógicas muy complejas mediante combinaciones lógicas And/Or entre varios ficheros lógicos). Contar 3. Parámetros de la aplicación vía tablas ajenas al código. o El cambio de la configuración se hace efectivo al arrancar el sistema al día siguiente. Contar 1. o El cambio de la configuración se hace interactivamente y tiene efecto inmediato. Contar 2. Se termina por determinar el valor acumulado. Cada una de las 14 Características Generales del Sistema ó GSCs (General System Caracteristics) en el sistema que estamos midiendo. El grado de influencia de cada característica va desde 0 Sin influencia a 5 Influencia Fuerte. Una vez obtenidos todos los grados de influencia de las características del sistema, los sumamos para obtener el Grado de Influencia Total o TDI (Total Degree of Influence). Así, el Valor del Factor de Ajuste queda finalmente de la siguiente manera: Valor de ajuste final (International Function Point Users Group (IFPUG), 2009) 9

10 3 Contexto del Trabajo Universidad Técnica Federico Santa María Una compañía Start-Up Chilena que está comenzando consta de cuatro integrantes: dos desarrolladores, un experto en seguridad, y una diseñadora. Cuentan con la experiencia que han adquirido en las empresas donde se han desempeñado como empleados. Hasta ahora para estimar la duración de un proyecto han utilizado como única alternativa el ojo experto, además de trabajar solamente con productos de software ya construidos, en los que se aplicaban modificaciones y a lo más se agrega una que otra funcionalidad. En este tipo de situaciones, y debido a la naturaleza estocástica de muchos procesos en los que no se tiene claro la totalidad de los eventos que pudiesen ocurrir, las estimaciones efectuadas en la mayoría de los casos diferían enormemente con lo acordado en un principio, ya sea por sesgos de la persona que realiza la estimación, o por no dimensionar las reales funcionalidades que se están solicitando, entre otros aspectos que dejen espacio a la incertidumbre de los requerimientos. La empresa logística Delpa group ha solicitado una aplicación que controle el inventario de sus activos; a pesar de tener alternativas ya creadas, Delpa group posee varias sucursales a nivel internacional, y por tanto requiere que este sistema se adapte a sus necesidades a través del tiempo; por ejemplo, que se manejen en un principio múltiples idiomas. Los integrantes de la start up vieron en esto una gran oportunidad de partir desarrollando esta solución, pero se requiere tener un tiempo de desarrollo concreto para estimar los costos, ya que es una compañía que se está formando y los tiempos de los integrantes son escuetos. Es debido a esto que requiere un proceso de estimación profesional y serio, para tener bases fundadas a la hora de proponer los recursos necesarios y estimar los costos. Se propone resolver este problema mediante la aplicación de puntos de función, con ello la compañía dispondrá de una metodología robusta para enfrentar este tipo de situaciones, usando como caso de estudio el sistema que requiere Delpa group. Existen modelos de información alternativos en donde a través de la experiencia se logra una estimación más o menos acertada, pero como esta compañía se está iniciando no cuenta con expertos de gran experiencia, y por tanto no sería una alternativa contar con este método de estimación. También hay modelos más elaborados y probados, como COCOMO 81 o COCOMO II; estos modelos definen el esfuerzo mediante la cantidad de miles de líneas de código, pero para la orientación web de los productos a producir por la compañía esta técnica no sería muy efectiva, ya que además se tendría que estimar esa cantidad de líneas antes de comenzar a utilizar el modelo. A diferencia de los modelos descritos anteriormente, los FP (function points) o puntos de función, como su nombre lo dice, se enfoca en las funciones del sistema, y a partir de ellos se logra una estimación de la aplicación; por ello que se decide utilizar este último modelo. La estimación de tiempo y recursos es una tarea que afecta transversalmente al desarrollo de aplicaciones, en donde se destaca la materia relacionada con ingeniería de software, en donde la literatura relacionada en su mayoría, se describen apartados referentes a este tema. A continuación, se dará cuenta del trabajo que he realizado durante el proceso de desarrollo de la aplicación NetCaliper. 3.1 Descripción del proyecto. El sistema está delimitado a la administración por parte del área de TI de la empresa, más precisamente el encargado del soporte y serán ingresados paulatinamente los usuarios que vayan requiriendo algún activo para desempeñar su trabajo. Estos usuarios solo serán desactivados mas no eliminados, para conservar un historial con la finalidad de en una segunda etapa desarrollar reportes para su estudio. El principal riesgo de la aplicación es que la empresa Delpa posee sucursales en varias partes del mundo, por lo que el sistema debe permitir una traducción fluida. Esto se manejará desde un principio gestionando las 10

11 traducciones con un archivo que tendrá el diccionario con las palabras incluidas en el sistema; esta arquitectura permitirá cambios de idiomas, aunque esto no haya sido requerido por parte del cliente. Supuestos: El sistema incrementará su alcance tanto en funcionalidades como en el tamaño del modelo de datos. El sistema no dependerá de un solo administrador, sino que además las áreas de toma de decisiones también dispondrán en una próxima etapa de un módulo de análisis de datos. El sistema estará localizado en las dependencias de la empresa cliente. Hitos claves del Proyecto. Toma de requerimientos. Coordinación de los requerimientos e inicio de la construcción Puesta en producción aplicación web para uso interno. Habilitación acceso externo. Estimación de Tamaño utilizando ojo experto Plazo total estimado en cantidad semanas o días, 12 semanas. Esfuerzo total estimado en HH, 480 H/H. 4 Desarrollo del Caso Práctico. 4.1 Requerimientos funcionales del sistema. El sistema debe ser capaz de gestionar: R1 : Usuarios del sistema. R2 : Roles de usuarios del sistema. R3 : Cargos de los usuarios del sistema. R4 : Departamentos a los que pertenecen los usuarios del sistema. R5 : Activos que posee la empresa. R6 : Categorías se los activos de la empresa. R7 : Proveedores de los activos de la empresa. R8 : Rubros o giros de las empresas proveedoras. R9 : Oficinas que posee la empresa. R10 : Empresas proveedoras. R11 : Asignación de los activos. R12 : Entregas de los activos. R13 : Información de compras de los activos. Estos requerimientos deben permitir: Listar, Ingresar, Actualizar, buscar, Eliminar y mostrar detalles) de cada una de las entidades expuestas, debido a que se requiere que cada funcionalidad sea manejada íntegramente desde el mismo sistema sin tener que depender de un área tecnológica que, por ejemplo, actualice un dato desde algún sistema de administración de bases de datos. 11

12 4.2 Procedimiento para determinar los Puntos de Función utilizando el método IFPUG FPA Figura 2. Flujo para determinar los FP ajustados con IFPUF FPA (Gómez, 2014) Paso 1, determinando el tipo de medición. Dada las características del proyecto en el que se está trabajando y utilizando los criterios expuestos en el capítulo 2, se obtiene que el proyecto en el que se trabajará corresponde a un proyecto de desarrollo. Paso 2, Identificar alcance de la medición y límites de la aplicación. La medición contempla la totalidad de los requerimientos expresados por el cliente y no existe una aplicación externa que interactúe con la aplicación a desarrollar. Además, los límites de la aplicación serán reconocidos por el usuario mediante las interfaces de usuario reconocidas por este último. Paso 3, Medir las funciones de datos. Como se mencionó anteriormente, este sistema no interactúa con otras aplicaciones, por tanto, se debe reconocer los ILF (Internal Logical files), también llamados grupo de datos o información de control. Tabla 1. Lista de los ILFs de la aplicación Niveles de departamento Roles Cargos Departamentos Niveles de cargos Activos Proveedores Compra Estado de las asignaciones Asignaciones Categorías Empresas Estado del activo Oficinas Rubros Usuarios ILFs Figura 3. Complejidad de un ILF (Gómez, 2014) 12

13 Figura 4. Puntos de función de una función de datos (Gómez, 2014) Junto con determinar los DETs y los RETs se estima el valor de la complejidad utilizando los datos de la figura 3, una vez teniendo la complejidad del ILF se procede a determinar los puntos de función utilizando los datos de la figura 4. Los resultados de los puntos de función para las funciones de datos se representan en la tabla 2. Tabla 2. Resultados obtenidos funciones de datos ILF DETs RETs Complejidad Puntos Función Roles 2 10 Media 10 Cargos 3 11 Media 10 Niveles de cargos 1 1 Baja 7 Activos 9 11 Media 10 Estado del activo 1 1 Baja 7 Proveedores 6 6 Media 10 Compra 2 1 baja 7 Asignaciones 6 18 Media 10 Estado de las asignaciones 1 1 Baja 7 Categorías 1 1 Baja 7 Empresas 3 2 Baja 7 Oficinas 3 3 Baja 7 Rubros 1 1 Baja 7 Usuarios 7 7 Media 10 Departamentos 3 2 Baja 7 Niveles de departamento 1 1 Baja 7 Total, puntos función para las funciones de datos 130 Paso 4, Medir las funciones transaccionales o procesos elementales. Se muestran los procesos elementales o funciones transaccionales identificados en el sistema. Tabla 3. Lista de los procesos elementales Funciones elementales Listar usuario Buscar usuario Eliminar usuario Ingresar usuario Actualizar usuario Ver detalles de usuario Listar rol Buscar rol Eliminar rol Ingresar rol Actualizar rol Ver detalle del rol Listar cargos Buscar cargos Eliminar cargos Ingresar cargo Actualizar cargo Ver detalle del cargo Listar departamentos Buscar departamento Eliminar departamento Ingresar departamento Actualizar departamento Ver detalle del departamento Listar activos Buscar activos Ver detalle del activo Ver detalle del activo Listar categorías Buscar categorías Eliminar categoría Ingresar categoría Actualizar categoría Ver detalle de la categoría Listar rubros Buscar rubros Eliminar rubro Ingresar rubro Actualizar rubro Ver detalle del rubro Puntos de función Listar oficinas 13

14 Buscar oficinas Eliminar oficina Ingresar oficina Actualizar oficina Ver detalle de la oficina Listar empresas Buscar empresas Eliminar empresas Ingresar empresa Actualizar empresa Ver detalle de la empresa Listar proveedores Buscar proveedores Eliminar proveedores Ingresar proveedor Actualizar proveedor Ver detalle del proveedor Listar usuarios para asignar Buscar usuarios para asignar Asignar activos Listar activos asignados Eliminar asignación Entregar activo Agregar compra Listar compras Eliminar compra Figura 5. Complejidad para las funciones transaccionales del tipo EI (Gómez, 2014) Figura 6. Complejidad para las funciones transaccionales del tipo EO y EQ (Gómez, 2014) Figura 7. Determinación los puntos de función de una función transaccional (Gómez, 2014) Se determina la complejidad de los procesos elementales del tipo EI, se utilizará la información que se muestra en la figura 5. Para complejidad de los procesos elementales del tipo EO y EQ, se utilizará la información de la figura 4.6. Una vez que tengamos la complejidad utilizamos los datos de la figura 7, para determinar los Puntos de Función. Tabla 4. Resumen de puntos de función por cada proceso elemental Función Pts. Función Pts. Función Pts. Listar usuario 3 Listar rol 3 Listar cargos 3 Buscar usuario 3 Buscar rol 3 Buscar cargos 4 Eliminar usuario 3 Eliminar rol 3 Eliminar cargo 4 Ingresar usuario 6 Ingresar rol 4 Ingresar cargo 4 Actualizar usuario 6 Actualizar rol 4 Actualizar cargos 4 Ver detalles de usuario 6 Ver detalles de rol 4 Ver detalles del cargo 4 Listar departamentos 3 Listar activos 3 Listar categorías 3 Buscar departamentos 3 Buscar activo 3 Buscar categorías 3 Eliminar departamento 3 Actualizar activo 3 Eliminar categoría 3 Ingresar departamento 3 Ver detalles del activo 4 Ingresar categoría 3 Actualizar departamento 3 Listar rubros 3 Actualizar categoría 3 14

15 Ver detalles del departamento 3 Buscar rubros 3 Ver detalles de la categoría 3 Eliminar rubro 3 Listar oficinas 3 Actualizar oficina 3 Ingresar rubro 3 Buscar oficinas 3 Ver detalles de la oficina 3 Actualizar rubro 3 Eliminar oficina 3 Listar empresas 3 Ver detalles del rubro 3 Ingresar oficina 3 Buscar empresas 3 Eliminar empresa 3 Listar proveedores 3 Actualizar proveedor 6 Ingresar empresa 4 Buscar proveedores 3 Ver detalles del proveedor 4 Actualizar empresa 4 Eliminar proveedor 3 Listar usuarios para asignar 3 Ver detalles de la empresa 3 Ingresar proveedor 6 Buscar usuarios para asignar 3 Asignar activos 6 Agregar compra 6 Listar activos asignados 3 Listar compras 3 Eliminar asignación 3 Eliminar compra 3 Entregar activo 4 TOTAL 235 Paso 5, Determinar el valor del Factor de Ajuste. De acuerdo con lo expuesto en el capítulo 2, los valores de la aplicación en los factores de ajustes son los que se muestran en la tabla 5. Tabla 5. Resultados del factor de ajuste Características generales del sistema Valor comunicaciones de datos. 4 procesamiento de datos distribuido. 4 rendimiento. 0 grado de uso de la configuración operacional. 0 tasa de transacciones. 0 entrada de datos en línea. 5 eficiencia del usuario final. 1 actualización on-line. 1 complejidad de procesamiento. 0 reusabilidad. 0 facilidad de instalación. 0 facilidad de operación. 0 múltiples localizaciones. 0 facilidad de cambio. 0 Grado de influencia total 15 Entonces aplicando la fórmula expuesta en el capítulo 2 obtenemos lo siguiente y los puntos de función ajustados son los siguientes Por tanto, se tiene que la aplicación NetCaliper posee un total de 292 Puntos de Función ajustados. 15

16 5 Análisis de los Resultados 5.1 Tabulación de los resultados Con la finalidad de medir el esfuerzo que toma cada requerimiento, los desarrolladores fueron registrando el tiempo empleado en cada una de estos, con alguna dificultad, esto debido a la falta de experiencia en tereas que sean distintas a desarrollar. Luego, aplicando otros métodos como el de verificar los horarios de asignación, a medida que avanzaba el desarrollo, finalmente se llegó a determinar mediante el desarrollo en vivo de 10 puntos función, lo que se tradujo en una estimación del promedio que tardaba cada desarrollador en finalizar un punto de función del proyecto NetCaliper. El programador 1 obtuvo un promedio de 2.7 horas mientras que el programador 2 obtuvo un promedio de 2.3 horas. Para determinar un aproximado del tiempo real del desarrollo de cada punto de función, se utilizará el promedio de estos dos integrantes, en donde obtenemos como resultado 2.5 horas por cada punto de función y esto significará para efecto de los cálculos, el tiempo real de desarrollo. De esta forma vemos el tiempo real del desarrollo del aplicativo en la tabla 6. Tabla 6. Resultados obtenidos de la medición real del desarrollo del aplicativo Requerimiento Tiempo en horas de desarrollo R1 101 R2 58 R3 64 R4 63 R5 40 R6 50 R7 87 R8 52 R9 54 R10 95 R11 57 R12 16 R13 39 Tiempo en horas de desarrollo 776 Luego tenemos los siguientes resultados: El tiempo de estimación del ojo experto fueron 480 horas. El tiempo real del desarrollo realizado significaron 776 horas como muestra la tabla 5.1. El tiempo estimado por Puntos de Función mediante el método IFPUG FPA fue de 292 x 2.5, es decir 730 horas (tabla 7). Las estimaciones utilizando Puntos de Función, fueron sistemáticamente más cercanas que el "ojo experto" a las HH reales, como indica la tabla 8, la tabla 9, la figura 8 y la figura 9 respectivamente. Para la visualización, se representarán los tiempos de dedicación a cada requerimiento de la siguiente forma (tabla 8): Para el ojo experto cada tarea es representada con el mismo valor lineal, ya que dicha estimación no contemplaba el detalle de cada requerimiento, sino que es una estimación del proyecto global. Para los tiempos de dedicación real serán expuestos los tiempos reales dado que se dispone de ellos. Para el caso de expresar gráficamente cada requerimiento traducido a puntos de función se utilizará el Punto de Función transaccional y de datos asociado a dicho requerimiento. 16

17 Determinamos el tiempo asociado a cada requerimiento, esto se determinó verificando los puntos función de una función transaccional y los puntos función de datos asociados a dicha tarea, multiplicado por el factor de ajuste, así como lo vemos en la tabla 7. Tabla 7. Detalle de los puntos función obtenidos por cada requerimiento REQUERIMIENTO PFT PFD PFT PFT X FA TOTAL, HORAS R ,6 74 R ,8 62 R R ,6 64 R R R R R R ,6 54 R ,4 56 R ,8 22 R ,2 38 TOTAL 730 Donde: PFT PFD FA : Puntos de función transaccional. : Puntos función de datos. : Factor de ajuste. Tabla 8. Resumen de las horas dedicadas al desarrollo REQUERIMIENTOS OJO EXPERTO HORAS DE DESARROLLO REAL PUNTOS FUNCIÓN ELEMENTAL Y DATOS R1 36, R2 36, R3 36, R4 36, R5 36, R6 36, R7 36, R8 36, R9 36, R10 36, R11 36, R12 36, R13 36, TOTALES

18 5.2 Diferencias entre los tiempos Tabla 9. Análisis de las diferencias REQUERIMIENTO (TR - OE) (TR - PF) R1 64,08 27 R2 21,08-4 R3 27,08-16 R4. 26,08-1 R5 3,08-20 R6 13,08 0 R7 50,08 17 R8 15,08 2 R9 17,08 4 R10 58,08 41 R11 20,08 1 R11-20,92-6 R12 2,08 1 TOTALES Donde: OE TR PF : Ojo experto. : Tiempo real de desarrollo. : Puntos función. 5.3 Gráficos asociados Ojo experto Horas desarrollo real Puntos función Elemental y Datos 0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 Figura 8. Gráfico comparativo de los tiempos trabajados en el proyecto 18

19 70,00 60,00 50,00 40,00 30,00 20,00 10,00 0,00-10,00-20,00-30,00 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 (TR - OE) (PF - OE) (TR - PF) Figura 9. Gráfico comparativo de las diferencias entre los tiempos 6 Conclusiones Al adquirir un bien o servicio siempre debemos tener en cuenta los beneficios que obtendremos, por ejemplo, si necesitamos oficinas nuevas debemos saber la superficie, o en el caso una empresa de trasporte al adquirir nuevos buses debe saber cuántos pasajeros necesita transportar. Esa es la razón por la que, en el software, a pesar de su carácter intangible, también deben ser cuantificados el tamaño de distintas soluciones, lo que se traduce en funciones requeridas; esto permite estimar el esfuerzo necesario para cubrirlas. En esta tesina, el proceso de medición de puntos de función permitió estimar este esfuerzo mediante la realización de un sistema que está actualmente en uso. Del estudio se concluye lo siguiente: 6.1 Respecto a las ventajas de la utilización de estimación con Puntos de Función. Representó consistentemente el punto de vista del usuario. Entregó un factor de comparación válido independiente de la tecnología utilizada para desarrollar el software. Será una medida para apoyar la calidad y los análisis de productividad. 6.2 Respecto a las desventajas que podría tener la utilización de estimación con Puntos de Función. Para algunos tipos de desarrollo donde el grado de complejidad de los algoritmos y fórmulas matemáticas es muy alto, no representa adecuadamente el tamaño de esa complejidad. No es fácilmente automatizable, ya que requiere de la interpretación humana de las reglas de contabilización. 6.3 Respecto a la comparación con la estimación del Ojo Experto. Los PF representan una estimación mejor detallada, debido a que se expone cada funcionalidad en cantidad de puntos función a diferencia de la naturaleza lineal de una estimación simplemente basada en la experiencia. Los datos expuestos en el capítulo 5 indican que, a pesar de no tener una estimación 100% acertada en cuanto al tiempo real utilizado, se logró una mayor aproximación a esta última, indicando que utilizar una estimación de esfuerzo basado en PF resultó más confiable que utilizar el Ojo Experto. Con el tiempo y la aplicación de Puntos Función en más proyectos de desarrollo, se podrá obtener una estimación más precisa de la propia medición de cada desarrollador, es decir en este caso se realizó mediante 19

20 el promedio de demora en tareas específicas, pero a medida que aumente la experiencia, se sabrá con una certeza casi natural el tiempo necesario de esfuerzo por cada punto de función que se necesite desarrollar. La estimación con Puntos de Función, fue un estimador de esfuerzo mucho más cercano a la realidad que la tradicional estimación por ojo experto respecto a las HH reales. 6.4 Por qué el requerimiento 1 y el requerimiento 10 se mostraron más distantes en comparación al resto? La gestión de usuarios fue el primer punto que se comenzó a desarrollar; esto tuvo una directa repercusión en las horas reales de desarrollo debido a que se comenzaba a conocer la herramienta, y por ello una vez que el conocimiento de la herramienta maduró el esfuerzo se acercó a lo estimado por los puntos de función. El desarrollo de las empresas proveedoras presentó dificultades no previstas, debido a un error de comunicación interno se comenzó con el desarrollo erróneo, y al descubrirse el error se tomó lo realizado y se reutilizó lo más posible. Esto se transformó en un retraso en los tiempos de desarrollo real que no estaba contemplado. 6.5 Qué implica para la start up haber aplicado IFPUG FPA? A partir de la realización de este proyecto en el que se aplicó un método de estimación, la start up lo considerará de forma muy seria el seguir incluyendo el método IFPUG FPA para futuros proyectos, además de tener en cuenta otros métodos existentes. El siguiente desafío para esta pequeña compañía que se comienza a formar, tiene que ver más con inteligencia de negocios, en el que está considerada la realización de un proyecto de software mucho más grande donde este tipo de métodos, serán de mucha ayuda, es por este mismo motivo que el haber tenido esta experiencia les ha resultado de mucha utilidad. 6.6 Recomendaciones Existen tantas formas de abordar un proyecto de software, que son casi una apuesta a la hora de escoger una, lo más común es que se opte por obviar un trabajo que requiera la investigación o cualquier acción extra que no sea <<producir>>, sin la realización de estas tareas tan importantes como la de investigar la forma de hacer nuestro trabajo más profesional, estaremos girando por mucho más tiempo dentro del mismo circulo de problemas que se mantendrán sin ser resueltos. Entonces, es deber de cada uno el abollar el muro de la incertidumbre y continuar aportando nuevos conocimientos y experiencias a esta ciencia, que no tiene otra finalidad más que la de ayudar a la humanidad, en la difícil tarea de cumplir con cada objetivo que se le imponga por delante. Agradecimientos. A mi gran grupo de trabajo, con el cual pasamos grandes momentos y logramos resolver cada desafío que se nos puso por delante: Rubén Jarpa, Luis Bastías, Alexis Loyola y Jorge Abarza; A mi profesor guía Hernán Astudillo, quien dedicó todo el tiempo que fue necesario para la finalización de este trabajo; Al grupo de Gignosoft: Ninoska Garcés, Ignacio Briones, Cristhian Paredes, quienes también dedicaron su tiempo para apoyar esta tarea, siendo que perfectamente pudieron negarse. Por último, a mi familia, que sin su apoyo todo hubiera sido mucho más difícil. 20

21 7 Referencias [1] Abran, A. (2010). Software Metrics Need to Mature. Gaithersburg (Maryland): National Institute of Standards and Technology (NIST). [2] Gómez, J. (2014). Guía Práctica de Estimación y Medición de Proyectos Software. En J. Gómez, Guía Práctica de Estimación y Medición de Proyectos Software (pág. 242). Madrid: Goodreads Editorial Team. [3] International Function Point Users Group (IFPUG). (2009). Function Point Counting Practices Manual Clarkston, Michigan: The David Consulting Group. [4] Pressman, R. S. (2010). Ingeniería del software un enfoque práctico septima edición. En R. S. Pressman, Ingeniería del software un enfoque práctico septima edición (pág. 765). Mc Graw Hill editorial. 21

22 1 Anexos Anexo A, Modelo de base de datos del sistema. Anexo B, Detalle de extracción de puntos de función en funciones elementales. 2 ANEXO A - Modelo de base de datos del sistema. 22

23 3 Anexo B - Detalle de extracción de puntos de función en funciones elementales. Se presenta el detalle de la extracción de los puntos de función del sistema NetCaliper utilizados en presente trabajo de tesina. 3.1 Extracción de los puntos de función del requerimiento: Gestionar usuarios del sistema. Vistas 23

24 Resultados Procesos Listar usuario Buscar usuario Eliminar usuario Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar usuario Actualizar usuario Ver detalle de usuario Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada Alta Alta Alta Puntos función Procesos elementales Puntos de función Listar usuario 3 Buscar usuario 3 Eliminar usuario 3 Ingresar usuario 6 Actualizar usuario 6 Ver detalles de usuario 6 TOTAL 27 24

25 3.2 Extracción de los puntos de función del requerimiento: Gestionar los roles de usuarios del sistema. Vistas 25

26 Resultados Procesos Listar rol Buscar rol Eliminar rol Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar rol Actualizar rol Ver detalle del rol Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada Media Media Media Puntos función Procesos elementales Puntos de función Listar rol 3 Buscar rol 3 Eliminar rol 3 Ingresar rol 4 Actualizar rol 4 Ver detalles de rol 4 TOTAL 21 26

27 3.3 Extracción de los puntos de función del requerimiento: Gestionar los cargos de usuarios del sistema. Vistas 27

28 Resultados Procesos Listar cargos Buscar cargos Eliminar cargos Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Media Media Puntos función Proceso Ingresar cargo Actualizar cargo Ver detalle del cargo Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada media Media Media Puntos función Procesos elementales Puntos de función Listar cargos 3 Buscar cargos 4 Eliminar cargo 4 Ingresar cargo 4 Actualizar cargos 4 Ver detalles del cargo 4 TOTAL 23 28

29 3.4 Extracción de los puntos de función del requerimiento: Gestionar los departamentos a los que pertenecen los usuarios del sistema. Vistas 29

30 Resultados Procesos Listar departamentos Buscar departamento Eliminar departamento Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar departamento Actualizar departamento Detalle del departamento Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada baja baja baja Puntos función Procesos elementales Puntos de función Listar departamentos 3 Buscar departamentos 3 Eliminar departamento 3 Ingresar departamento 3 Actualizar departamento 3 Ver detalles del departamento 3 TOTAL 18 30

31 3.5 Extracción de los puntos de función del requerimiento: Gestionar los activos que posee la empresa. Vistas 31

32 Resultados Procesos Listar activos Buscar activos Actualizar activo Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja baja Puntos función Proceso Tipo de proceso Ver detalle del activo EQ DETS 7 FTRS 3 Complejidad de entrada Media Puntos función 4 Procesos elementales Puntos de función Listar activos 3 Buscar activo 3 Actualizar activo 3 Ver detalles del activo 4 TOTAL 13 32

33 3.6 Extracción de los puntos de función del requerimiento: Gestionar Categorías se los activos de la empresa. Vistas 33

34 Resultados Procesos Listar categorías Buscar categorías Eliminar categoría Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar categoría Actualizar categoría Detalle de la categoría Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada baja baja Baja Puntos función Procesos elementales Puntos de función Listar categorías 3 Buscar categorías 3 Eliminar categoría 3 Ingresar categoría 3 Actualizar categoría 3 Ver detalles de la categoría 3 TOTAL 18 34

35 3.7 Extracción de los puntos de función del requerimiento: Gestionar proveedores de los activos de la empresa. Vistas 35

36 Resultados Procesos Listar Buscar proveedores Eliminar proveedores proveedores Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar proveedor Actualizar proveedor Ver detalle del proveedor Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada Alta Alta Media Puntos función Procesos elementales Puntos de función Listar proveedores 3 Buscar proveedores 3 Eliminar proveedor 3 Ingresar proveedor 6 Actualizar proveedor 6 Ver detalles del proveedor 4 TOTAL 25 36

37 3.8 Extracción de los puntos de función del requerimiento: Gestionar rubros o giros de las empresas proveedoras. Vistas 37

38 Resultados Procesos Listar rubros Buscar rubros Eliminar rubro Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar rubro Actualizar rubro Ver detalle del rubro Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada baja baja Baja Puntos función Procesos elementales Puntos de función Listar rubros 3 Buscar rubros 3 Eliminar rubro 3 Ingresar rubro 3 Actualizar rubro 3 Ver detalles del rubro 3 TOTAL 18 38

39 3.9 Extracción de los puntos de función del requerimiento: Gestionar las oficinas que posee la empresa. Vistas 39

40 Resultados Procesos Listar oficinas Buscar oficinas Eliminar oficina Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar oficina Actualizar oficina Ver detalle de la oficina Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada Media media Baja Puntos función Procesos elementales Puntos de función Listar oficinas 3 Buscar oficinas 3 Eliminar oficina 3 Ingresar oficina 3 Actualizar oficina 3 Ver detalles de la oficina 3 TOTAL 18 40

41 3.10 Extracción de los puntos de función del requerimiento: Gestionar las empresas proveedoras. Vistas 41

42 Resultados Procesos Listar Buscar empresas Eliminar empresas empresas Tipo de proceso EQ EI EI DETS FTRS Complejidad de entrada Baja Baja Baja Puntos función Proceso Ingresar empresa Actualizar empresa Detalle de la empresa Tipo de proceso EI EI EQ DETS FTRS Complejidad de entrada Media media Baja Puntos función Procesos elementales Puntos de función Listar oficinas 3 Buscar oficinas 3 Eliminar oficina 3 Ingresar oficina 4 Actualizar oficina 4 Ver detalles de la oficina 3 TOTAL 20 42

43 3.11 Extracción de los puntos de función del requerimiento: Gestionar las asignaciones, entregas e información de compras de los activos. Vistas 43