ESTIMACIÓN DE PROYECTOS DE SOFTWARE PARA DESARROLLOS DE APLICACIONES INTRANET/INTERNET BASADA EN LA TÉCNICA DE PUNTOS DE FUNCIÓN

Transcripción

1 ESTIMACIÓN DE PROYECTOS DE SOFTWARE PARA DESARROLLOS DE APLICACIONES INTRANET/INTERNET BASADA EN LA TÉCNICA DE PUNTOS DE FUNCIÓN Lautaro Guerra Genskowsky Universidad Técnica Federico Santa María, Valparaíso, Chile - lguerra@uv.utfsm.cl Pamela Hermosilla Monckton Universidad Técnica Federico Santa María, Valparaíso, Chile - phermosi@uv.utfsm.cl Resumen Se presenta una variación al método de estimación de tamaño y esfuerzo basado en los Puntos Función, para proyectos de software con Reutilización de componentes objetuales. El método establecido define los elementos a considerar y su importancia a partir de datos experimentales. Éste representa una primera aproximación a un modelo que refleje el problema analizado, el resultado obtenido muestra adecuadamente el impacto o ajuste necesario en la estimación del esfuerzo en proyectos de desarrollo de aplicaciones Internet/Intranet con desarrollo utilizando UML. Palabras Clave: Ingeniería de Software, Puntos de Función, Desarrollo Intranet.. Abstract A modification of the function point analysis is presented, oriented to software projects with object reutilization. The method defines the relevance of the elements to be considered in the model. This is a first approximation established from experimental data. The result reflects adequately the necessary adjusts in the estimation of function points for projects based on UML and Intranet/Internet. Keywords Software Engineering, Function Points, Intranet Software Projects 1. INTRODUCCIÓN En el complejo mundo del desarrollo de Sistemas de Información, resalta como principal métrica de tamaño el indicador Punto Función (PF) [1]. No cabe duda, que la información entregada por el citado indicador es importante al momento de realizar una estimación en el desarrollo de productos de software, sin embargo, las contemporáneas técnicas de desarrollo han incorporado innumerables mecanismos que facilitan la Reutilización de componentes de Software [2], lo que induce a pensar que este indicador puede estar requiriendo de mejoras que lo acerquen más a la realidad actual en esta área de la ingeniería de software y desarrollo de sistemas. Puntos de Función fue desarrollado por Albrecht (1984). En 1986 se creó el International Function Point User Group, que se comprometió a difundir esta metodología, publicando periódicamente un Manual Práctico, cuya versión 4.1 ha aparecido en marzo de De este modo la metodología del Punto Función se ha convertido en el Estándar ISO/IEC Software Measurement Functional size measurement publicado en [8, 10] La técnica de análisis de Punto Función entrega una estimación del tamaño del software independiente de la tecnología utilizada para su desarrollo y dependiente, únicamente de la funcionalidad del sistema. Esta definición pareciera resolver la inquietud que presenta este artículo, pues habla de la independencia de la tecnología utilizada, pero será que la tecnología actual, merece el mismo tratamiento que la de hace una década?, Considera efectivamente la enorme posibilidad de Reutilización que proporcionan las nuevas tecnologías y metodologías de desarrollo basadas en la Orientación a objeto? [4,5,6]. Si ambas preguntas, encontraran sus respectivas respuestas en el indicador PF, entonces por qué los proyectos de desarrollo de software presentan sólo un 1,75% de uso sin modificación?(ver figura1). Diversos estudios demuestran que gran parte de los fracasos en los proyectos de desarrollo de software se deben precisamente a una de las primeras etapas de este proceso como es el Análisis de Requerimientos, el que depende directamente del usuario y se encuentra estrechamente ligado a tal indicador [7]. La realidad presentada en la Figura1 nos lleva a hacernos, la siguiente pregunta Es Punto Función la técnica de estimación que requiere el desarrollo de software actual? [9].

2 Nuestra respuesta a la pregunta anterior es, sí, el Punto Función sigue siendo hoy una técnica válida para la estimación de esfuerzo en un proyecto de desarrollo de software, sin embargo creemos necesario que este método debe ser modificado para destacar la importancia del concepto de reutilización en el desarrollo de aplicaciones Intranet/Internet , nunca usado rehecho o abandonado pagado pero nunca liberado usado con cambios usado s/modificación 47.1 Fuente: Case Strategies, jul.1992 (DOD, USA) Figura 1: Análisis de desarrollos de software 2. MEJORA A LA TÉCNICA DE PUNTO FUNCIÓN : CASOS DE APLICACIÓN EN PROYECTOS CON REUTILIZACIÓN DE COMPONENTES La pregunta que habría que plantearse al momento de sugerir una mejora en los resultados proporcionados por este indicador es Cómo es posible estimar el porcentaje de Reutilización en un proyecto de desarrollo de software?. La respuesta a esta pregunta es la base para la incorporación de una mejora a la técnica actual. No resulta tan evidente como se otorga un valor numérico a los factores que formarían parte de nuestra respuesta, y por otro lado, cómo este valor afectaría a la estimación inicial realizada con la técnica de PF tradicional. He aquí entonces, donde se plantea a partir de casos prácticos nuestra metodología de estimación de proyectos de software con utilización de componentes reusables y enfocada a desarrollos con tecnologías de Intranet/Internet. Se presenta inicialmente el marco conceptual de los sistemas que evaluaremos así como también una breve descripción de la metodología de desarrollo y plataforma tecnológica empleada para su realización. A partir de dos productos de software: Sistema de Gestión Académica y Sistema de Gestión Contable, denotados por P1y P2 respectivamente, se ha construido un tercer producto, Sistema de Gestión para Ex Alumnos, el que denominaremos P3 con componentes reusables provenientes de ambos proyectos iniciales. Todos los productos utilizan la misma metodología de desarrollo bajo una plataforma Intranet/Internet. Se entregará lo que podría considerarse una mejora para el modelo de estimación de PF, que sin duda puede ser un interesante punto de partida para estudios posteriores al nuestro. A continuación se presenta un breve resumen con los antecedentes necesarios para comprender los conceptos utilizados en la estimación de los proyectos. Cabe destacar que los tres productos de software mencionados P1, P2, P3 se encuentran enmarcados en el área académica universitaria a la cual pertenecemos. 2.1 Requerimientos Funcionales para los Proyectos en Estudio Requerimientos Funcionales Sistema de Gestión Académica (P1) Lograr obtener información precisa y oportuna referente a: Total alumnos inscritos por actividad y/o cursos para un rango de fechas determinado. Búsqueda de alumnos por región, empresa, profesión, cargo, edad o rango de edad, género, país Cursos que componen un diploma, un Postítulo o una actividad específica Cursos que ha dictado un profesor Evaluación recibida desde los alumnos a un profesor para un curso determinado Evaluación recibida desde los alumnos a un curso y/o actividad Histórico de inscripciones por curso para una actividad determinada Consulta de personas por situación (activa, ausente, desinscrito, etc.) Reporte de calificación(notas finales) del curso o por programa (faltas de entrega) Reporte de calificaciones (nota final) pendientes por curso y/o actividad Alumnos por concluir una actividad específica en un periodo próximo Alumnos finalizados por actividad Cantidad de alumnos diplomados a la fecha por actividad Cantidad de profesores con actividades vigentes (para un rango de fecha dada)

3 Requerimientos Funcionales Sistema de Gestión Contable (P2) Lograr obtener información precisa y oportuna referente a: Deuda de Alumnos por conceptos de matrícula, escolaridad, bibliografía, fotocopias, videos, materiales, etc. Pagos totales (Ingresos al sistema), por alumnos, empresas, para una actividad, rango de fecha. Ingresos por conceptos de: Matíicula, arancel, capacitación, seminarios y otros, por actividad, alumno y rango de fechas Ingresos por tipos de pagos Saldo presupuestario a la fecha por ítems o por actividad (disponible, contable) Gasto de un ítem determinado para un periodo de tiempo y actividad determinada Cantidad total por recibir por distintos conceptos ítem de presupuesto y de transacciones en un periodo determinado. Requerimientos Funcionales Sistema de Gestión ExAlumnos (P3) Lograr obtener información precisa y oportuna referente a: Administración de Personas, Empresas, Movimientos Contables y Cierre Mensual. Mantención de información referente a: Isapre, AFP, Cargos, Calidad, Cuenta Corriente, Idioma, Giro, Item de Presupuesto, Banco, Plaza, Tipos de pago, Campus USM, Carreras USM, Universidades y/o Institutos, etc. Consultas con relación a: Listado General de Ex Alumnos, Páginas Amarillas y Listado de Empresas, Oferta Laboral, Listado Demanda Laboral, Listado de cobranza, Estado de cuentas corrientes socios Servicios: Publicación de Actividades y/o cursos, Demanda de Trabajo, Compra, Venta, Biblioteca 2.2. Metodología y Arquitectura de Desarrollo Los sistemas mencionados se desarrollaron bajo un enfoque de Orientación a Objetos (OO), el que toma elementos reales existentes, los analiza y les da un modelado semántico, con lo cual se logra concretar un software más cercano y acorde a la realidad cotidiana. Por ello, las actuales herramientas de desarrollo procuran ocupar las potencialidades de la OO, es así que se construyen módulos o librerías Reutilizables (como por ejemplo, archivos DLL), con lo que hay un importante ahorro de código escrito. La metodología considera un desarrollo iterativo, de tal forma de refinar el trabajo y obtener mejores resultados finales en forma cíclica. En el desarrollo de los sistemas también se considera el Unified Modeling Languaje (UML) (Lenguaje Unificado de Modelado). El que se define como un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software. La Arquitectura Cliente/Servidor es, en su esencia, una arquitectura de procesos, en donde se definen claramente dos roles: los procesos llamados Clientes, que solicitan servicios y datos; y los procesos llamados Servidores, cuyo papel es atender estas solicitudes. Clientes y Servidores; son independientes entre sí, debido a que un proceso servidor puede atender requerimientos de cualquier proceso cliente, sin importar el ambiente de hardware o software en que residen ambos procesos. Los sistemas presentan una arquitectura Cliente/Servidor en tres niveles la que se encuentra orientada a diseño de aplicaciones basadas en arquitecturas multicapas, la que se utiliza para separar responsabilidades en diferentes componentes de los sistemas de información. Cada capa corresponde a un conjunto de componentes (clases, controles, servicios de base de datos, etc.) que ofrecen servicios hacia componentes de otras capas (o de la misma), o hacia el usuario final. Los servicios que una capa coloca a disposición de otras equivalen a los puntos de entrada a esa capa. Es posible utilizar las mismas reglas del negocio para diferentes aplicaciones, corriendo sobre distintas plataformas. La lógica, en términos de reglas del negocio, se aísla de los elementos de interfaz y de la forma de almacenamiento de los objetos. Bajo este tipo de arquitectura, es posible separar físicamente los componentes del negocio, pudiéndose centralizar en servidores especializados, a través del uso de monitores transaccionales como Microsoft Managment Transaction Server (MTS) Consideraciones especiales de los proyectos En el desarrollo de los casos presentados participa el mismo equipo de trabajo, por lo que no se requiere un tiempo previo de aprendizaje en la metodología de desarrollo para enfrentar un nuevo proyecto. La decisión de Reutilización es la única estrategia viable en P3, dada las severas restricciones de tiempo impuestas al proyecto y es aplicada desde el inicio en cada uno de los tres proyectos.

4 3. DATOS EXPERIMENTALES: CÁLCULO PUNTOS FUNCIÓN Cálculo de PF teóricos para los proyectos en estudio Resumen de cálculo de Punto Función para los tres proyectos: Factor P1 P2 P3 1. Comunicación de Datos Procesamiento Distribuido Performance Fuerte uso de la configuración Tasa de Transacción Entrada de datos en línea Eficiencia Usuario Final Actualización e línea Procesamiento Complejo Reusabilidad Facilidad de instalación facilidad Operacional Sitios Múltiples Facilitamiento del cambio Factor de Ajuste(FA) 1,07 1,03 1,12 Tabla 4: Complejidad para Proyecto P3 Finalmente, se tiene el resumen de los cálculos de Puntos de Función: Proyecto PFNA FA PFA P , P , P , Tabla 5: Puntos de función para P1, P2 y P3 Cálculo de PF real para P3 Para calcular cual fue el PF real para P3, debemos saber de antemano cual es la productividad con la cual se desarrollaron estos proyectos,. Para ello tomaremos los datos de PF de P1 y P2, en los cuales el esfuerzo promedio fue de 1,3 HM y considerando los plazos de ejecución respectivos. De esta forma se tiene: Tabla 1: Factores de Influencia Cálculo de complejidad P1 baja media alta Valor Valor real ponderado 1. Entradas Externas Salidas Externas Archivos lógicos internos Archivo de interfaz externo Consultas externas PFNA 167 Tabla 2: Complejidad para Proyecto P1 Cálculo de complejidad P2 baja media alta Valor Valor real ponderado 1. Entradas Externas Salidas Externas Archivos lógicos internos Archivo de interfaz externo Consultas externas PFNA 184 Tabla 3: Complejidad para Proyecto P2 Cálculo de complejidad P3 baja media alta Valor Valor real ponderado 1. Entradas Externas Salidas Externas Archivos lógicos internos Archivo de interfaz externo Consultas externas PFNA 153 Proyecto PF Duración Total Esfuerzo Productividad (Mes) (MH) (PF/HM) P ,8 P ,3 13,2 Promedio 13,5 Tabla 6: Cálculo de productividad promedio Para calcular el PF real de P3 se obtiene a partir de operar con la productividad promedio alcanzada en los proyectos P1 Y P2 que es de 13,5 PF/HM y el esfuerzo efectivamente realizado para obtener P3 (6, 5 HM). PF(P3) real = 13.5[pf/HM] * 6.5[HM] = 88[pf] (1) Impacto de la reusabilidad en el desarrollo de P3 El valor de P3teórico(ver Tabla 5) no considera que este software se desarrolló a partir de P1 y P2; el enfoque que tuvieron estos desarrollos nos da un indicio de los posibles factores que pueden influir directamente en la Reutilización. Estos factores se

5 han clasificado en tres categorías (basados en nuestra experiencia) que se describen a continuación: Interfaz Usuario Nº factor Criterio Definición 1 Formularios de datos Interfaces que permiten el ingreso de datos 2 Validaciones datos de entrada por campo Verificar que cada dato ingresado sea coherente a su tipo 3 Mensajes de errores en ingreso de datos Reglas del Negocio Alertas explicativas a algún error cometido al ingresar un dato Nº factor Criterio Definición 4 Clases genéricas Entidad que permite ser instanciada por un objeto determinado 5 Clases de tipo gestores Clase que permite emitir consultas básicas sobre una determinada clase 6 COTS Componentes reusables disponibles Almacenamiento de Datos Nº factor Criterio Definición 7 Funciones de rutinas de validaciones 8 Script de tablas y procedimientos almacenados 9 Módulo de procesos específicos Procedimientos empleados en rutinas específicas para validaciones Generación de la estructura de datos que sustenta un sistema Funciones que operan sobre determinadas clases El próximo paso será presentar como incorporamos estos factores a nuestro resultado anterior. Indicaremos, las ocurrencias de cada uno de estos factores en nuestro nuevo proyecto, considerando los componentes reusables en forma independiente según provengan del proyecto P1 o de P2: P3 a partir de P1 Nº Factor Reutilización Total % Reutilización , , , , , , , , ,33 Tabla 7: Reutilización de P3 a partir de P1 P3 a partir de P2 Nº Factor Reutilización Total % Reutilización , , , , , , , , ,33 Tabla 8: Reutilización de P3 a partir de P2 Para calcular nuestro factor de Reutilización, es necesario ponderar de alguna forma los porcentajes de Reutilización obtenidos, en cada uno de los casos presentados, para ello analizaremos los puntos de función teóricos con los puntos de función reales, ya entregados, los cuales se conocen a priori de este estudio, pues se dispone de los datos exactos de los proyectos mencionados. De esta forma se tiene que (diferencia relativa a P3 real): PF( P3) teórico 1 - = 0,49 (2) PF( P3) real Donde los valores para ambas variables son: PF(P3) teórico = 171, PF(P3) real = 88 Para validar el porcentaje de Reutilización, verificaremos cual es la relación de P3 con respecto a P1 y P2. De este Modo P3 a partir de P1 se tiene: 1 - PF(P3) teórico = 0,04 PF(P1) teórico (3) P3 a partir de P2 se tiene: 1 - PF(P3) teórico = 0,09 PF(P2) teórico (4) De estas diferencias relativas obtenemos que en total P3 reutilizó un 13%. Si comparamos tal valor con el obtenido en la ecuación (1) vemos que es posible encontrar un factor de ajuste asociado a la Reutilización, el que se encuentra en el rango 15 50%. Para estimar cual es la ponderación necesaria que deben tener nuestros factores en estudio, tomaremos como referencia el valor medio de este rango, el que corresponde a 32%. Con este valor analizamos las tablas 7 y 8 y establecemos la siguiente relación para la ponderación de los factores:

6 32 = 9 å i= 1 9 å i= 1 Ci* Fi Ci Donde: Ci son los coeficientes que otorgan el peso a cada factor Fi son los correspondientes porcentajes de Reutilización Al estudiar los valores obtenidos en las tablas 1 y 2, vemos que es posible considerar la siguiente tabla de ponderaciones para los factores en estudio. Tabla de ponderaciones para los factores Factor Poderación % 1. Formularios de datos 3 2. Validaciones datos de entrada 2 por campo 3. Mensajes de errores en ingreso 3 de datos 4. Clases genéricas 5 5. Clases de tipo gestores 6 6. COTS 4 7. Funciones de rutinas de 3 validaciones 8. Script de tablas y 2 procedimientos almacenados 9. Módulo de procesos 4 específicos Total 32 Tabla 9: Factor de Reutilización Estas ponderaciones se obtuvieron a partir del 32% que era necesario atribuir como ahorro por la Reutilización realizada y su distribución está basada en la experiencia de los autores. A partir de estos valores y las tablas 7 y 8 se obtienen los siguientes resultados: Caso P3 a partir de P1 Nº Factor % Reutilización Poderación Aporte Por factor 1 0,32 3 0,96 2 0,62 2 1,23 3 0,42 3 1,25 4 0,17 5 0,83 5 0,20 6 1,20 6 0,50 4 2,00 7 0,33 3 1,00 8 0,28 2 0,56 9 0,33 4 1,33 0,32 Tabla 11: Factor de Reutilización para P3 por aporte de P2 Caso P3 a partir de P2 Nº Factor % Reutilización Poderación Aporte Por factor 1 0,40 3 1,20 2 0,77 2 1,54 3 0,83 3 2,50 4 0,42 5 2,08 5 0,70 6 4,20 6 0,50 4 2,00 7 0,50 3 1,50 8 0,39 2 0,78 9 0,33 4 1,33 0,54 Tabla 12: Factor de Reutilización para P3 por aporte de P2 Como promedio de los casos de estudio en el desarrollo de P3, se puede establecer que el porcentaje de Reutilización es de un 43%. Si analizamos el error para nuestro caso de estudio se tiene: Pf(P3)reuso = PF(P3)teórico* (1-factor reuso) = 98, lo que establece que el error es del orden de un 12%, con respecto al valor real obtenido en la fórmula (2). Estimamos que el error es razonable, para los casos mostrados. Sin duda que con más casos y comparaciones obtenidos a partir de nuevos datos experimentales este modelo puede ser mejorado 4. MÉTODO DE PUNTO FUNCIÓN INCORPORANDO LA REUSABILIDAD EN EL DESARROLLO DE SOFTWARE Cómo aplicamos el factor de Reutilización al resultado obtenido en el modelo de PF?. He aquí entonces, donde se plantea nuestra metodología de estimación de proyectos de software con utilización de componentes reusables basada en PF y enfocada a desarrollos con últimas tecnologías de Intranet/Internet. La metodología se utiliza realizando las siguientes fases: 1) Analizar los requerimientos funcionales del sistema a desarrollar 2) Aplicar la técnica actual de punto función, para los requerimientos establecidos en el punto anterior 3) Identificar los factores candidatos para definir los componentes reusables a utilizar en la estimación mostrados en la tabla de ponderaciones para los factores. A cada uno de estos factores se les debe estimar el

7 porcentaje de Reutilización a partir de las ocurrencias. Tabla 13: Cálculo del % de reutilización 4) Finalmente predecir el impacto de los componentes reusables en el nuevo desarrollo. A través de la tabla de ponderaciones presentada, encontrar el factor de Reutilización Tabla 14: Cálculo del factor de reutilización 5) Analizar el resultado obtenido en el punto 2) para combinarlos con los del paso anterior y obtener la nueva estimación. Pf reuso = PFteórico * (1-factor reuso) Con lo que se obtiene el esfuerzo en PF corregido por la reutilización. 5. CONCLUSIONES Nº Factor Reutilización Total %Reutilización 1 x y a:= x/y Nº Factor %Reutilización Poderación AportePorfactor 1 a 3 a* El modelo que explica razonablemente el impacto de la reutilización en el desarrollo de software bajo la plataforma de desarrollos para aplicaciones en ambiente Intranet/Internet. De este modo se presenta como una primera aproximación a un modelo que contempla aspectos de reutilización, el que debe ser S iterado con más datos para su verificación y validación. Sin embargo, para que el modelo pueda ser usado adecuadamente, sus requerimientos tienen que ser conocidos a cabalidad y evaluado por un analista con experiencia tanto metodológica como tecnológica. Referencias [1]. Raffaela Ibba, David Longstreet, The Growth and Acceptance of Function Points, IT Metrics Strategies, June [2]. Linda H. Rosenberg, Lawrence E. Hyatt,Software Quality Metrics for Object Oriented Environments, Crosstalk The Journal of Defense Software Engineering, April [3]. Patricio Letelier Torres, Isidro Ramos Salavert, Pedro Sanchéz Palma, Oscar Pastor López, OASIS Versión 3.0 Un enfoque Formal para el Modelado Conceptual Orientado a Objeto, Universidad Politécnica de Valencia, [4]. Rob Donnellman, 10 Uses for Function Points: Some Old, Some New, Cap Gemini America, IT Metrics Strategies, June [5]. Estimating With Objects - Part II, Watts S. Humphrey, watts-humphrey/estimate-objects-002.html. [6]. Rob Donnellman,Function Point Shortcuts, Cap Gemini America, IT Metrics Strategies, October [7]. Lautaro Guerra Genskowsky. Apuntes de Administración de Proyectos de Software, Departamento de Informática, Universidad Técnica Federico Santa María, [8]. Estándar ISO/IEC Software Measurement Functional size measurement. [9]. Rob Donnellman,Common Function Point Counting Errors, Cap Gemini America, IT Metrics Strategies, May [10]. Como auditar las métricas del software realizadas con la Metodología de los Puntos Función según la nueva versión 4.1 del Manual del IFPUG, Lucero Manresa, José Luis.

8