Printer Friendly

Experiencia docente en la Universidad de Costa Rica en el uso de puntos de funcion y metodologias orientadas a objetos para estimar proyectos de software.

Resumen

La estimacion de proyectos de software es uno de los temas actuales mas importantes dentro de la disciplina de la ingenieria de software. Este articulo describe la experiencia al ensenar a estimar y planificar un proyecto de software a estudiantes de pregrado de la carrera de Ciencias de la Computacion e Informatica en la Universidad de Costa Rica. Se describe en detalle la metodologia para estimar un proyecto de software, en una etapa en donde apenas se esta conceptualizando, utilizando puntos de funcion y metodologias orientadas a objetos. Ademas, se explica como derivar el esfuerzo requerido para implementarlo con base en el tamano estimado. Los puntos descritos en este articulo pueden interesar a profesores e instructores que deseen formar a futuros ingenieros de software en el campo de la planificacion.

Palabras clave: estimacion, metricas, tamano, esfuerzo, metodologias orientadas a objetos.

Abstract

Right now software project estimation is one of the most important subjects of the software engineering discipline. This article describes the teaching experience on estimation and planning of software projects, to bachelor's and master's degree students programs on Computer Science and Informatics in the University of Costa Rica. It describes in detail: the methodology to estimate and plan, object oriented methodologies to conceptualize the software to be developed, and Function Points to measure its size. It is also explained, how to derive effort and duration based on size estimation. These described items could interest teachers and instructors who wish to form future software engineers on planning fields.

Key words: estimation, measures, size, effort, object oriented methods.

1. INTRODUCCION

En la mayoria de las empresas donde se produce software para apoyar el negocio, las practicas de estimacion y planificacion son debiles. En general, los administradores estiman el costo y la duracion del proyecto por desarrollar, utilizando solamente el juicio de un experto. Con el fin de apoyar a la industria desarrolladora de software en Costa Rica, la Universidad de Costa Rica, como motor impulsor de las ultimas practicas internacionales, ha considerado la iniciativa de ensenarles a sus estudiantes, las nuevas metodologias de estimacion y planificacion de proyectos de software. Por esta razon, aproximadamente desde 1996, se les ha ensenado a estimar el tamano de la aplicacion utilizando los Puntos de Funcion (PF) y con base en el tamano, a estimar el esfuerzo requerido para desarrollar la aplicacion.

El Analisis de Puntos de Funcion (en ingles, Function Point Analysis, FPA) fue introducido por Albrecht en 1970. Su proposito era solucionar algunos de los problemas asociados con el calculo del tamano del software en Lineas de Codigo (en ingles "Lines of code", LOC) y las medidas de productividad que se daban, especialmente por las diferencias en los calculos de LOC que resultaban de los diferentes niveles de lenguajes que se utilizaban. A el le interesaba medir la funcionalidad del software desde el punto de vista del usuario, independientemente de su implementacion, por lo que introdujo los PF como una medida del tamano de una aplicacion, desde el punto de vista funcional o del usuario. Los PF son derivados de aspectos externos de las aplicaciones de software, los cuales son: entradas, salidas, consultas, archivos logicos e interfaces (Kan, 2003).

Desde entonces, el uso de los PF ha ganado aceptacion como una medida de productividad clave y los procedimientos de conteo han sido actualizados varias veces desde su primera publicacion. El FPA es ahora administrado por el International Function Point Users Group (IFPUG). Ellos proveen los estandares para aplicar el calculo de los PF a traves de su publicacion "Counting Practices Manuals" (Garmus, 2001).

2. ANTECEDENTES

Despues de haber ensenado las practicas recomendadas del FPA durante aproximadamente cuatro anos, se detectaron fundamentalmente dos problemas:

* En primer lugar, esta tecnica requiere disponer de informacion muy detallada en una fase temprana, en donde apenas se esta evaluando la viabilidad del proyecto. Las reglas de conteo del FPA se deben aplicar a dos elementos que son: los archivos y las transacciones de la aplicacion que se esta estimando. Esta reglas requieren conocer cierto nivel de detalle de dichos elementos, para poder determinar su complejidad y posteriormente, el tamano de la aplicacion.

* En segundo lugar, para identificar los elementos mencionados en el parrafo anterior y realizar la estimacion, se ha utilizado el diagrama de entidad-relacion, el cual es tipicamente una herramienta de las tecnicas de diseno estructurado. Esto ha provocado controversia, porque los estudiantes utilizan metodos orientados a objetos para desarrollar, y los modelos creados con estos metodos, son diferentes especialmente en las fases tempranas, debido a que no proveen documentacion tradicional como: diagramas de entidad-relacion, estructuras de bases de datos o modelos de procesos jerarquicos, sino que modelan el sistema como un conjunto de objetos cooperando.

Este articulo propone una metodologia para estimar el tamano de una aplicacion, utilizando los metodos orientados a objetos y los procedimientos de FPA, pero intentando corregir los problemas mencionados anteriormente. En la seccion tres se explican algunos conceptos teoricos para entender la metodologia propuesta, la cual se describe en la seccion 4 de este documento. Finalmente, en la seccion 5 se presentan las conclusiones.

3. MARCO TEORICO

3.1. Modelo de casos de uso

El modelo principal del Object-Oriented Software Engineering (OOSE) propuesto por Jacobson, es el modelo de casos de uso y es la base sobre la cual se desarrollan los otros modelos como: el de objetos del dominio, el de analisis, el de clases, el de implementacion y el de pruebas. Este modelo tiene dos elementos: los casos de uso y los actores.

De acuerdo con Larman, (1999) "Un caso de uso describe un proceso, un proceso de negocios por ejemplo. Un proceso describe, de comienzo a fin una secuencia de los eventos, de las acciones y las transacciones que se requieren para producir u obtener algo de valor para una empresa o actor. Algunos procesos pueden ser: solicitar un pedido, retirar efectivo de un cajero automatico".

Larman recomienda que durante las fases de conceptualizacion y planeacion, despues de haber identificado las funciones del sistema y definido sus fronteras se debe hacer lo siguiente: describir los casos de uso en formato esencial y dibujarlos en un diagrama de casos de uso, incluyendo las relaciones entre ellos. A continuacion se muestra un ejemplo de la descripcion esencial del caso de uso "Comprar productos" y en la Figura 1 se muestra el diagrama de casos de uso.

Caso de uso: Comprar productos

Actores: Cliente, Cajero

Descripcion: Un cliente llega a una caja con productos que desea comprar. El cajero registra los productos y obtiene el pago de parte del cliente. Al terminar la transaccion, el cliente se marcha con los productos.

[FIGURA 1 OMITTED]

Los casos de uso pueden ser refinados con las relaciones "include" y "extend". En una relacion de inclusion ("include"), las partes comunes pueden ser extraidas y modeladas para ser "usadas" por otros casos de uso. En una relacion de "extension" ("extend") un caso de uso puede ser insertado en un flujo de accion de un caso de uso existente, la extension agrega funcionalidad, independientemente del existente (Larman, 1999).

Posteriormente, conforme se avance en la investigacion de los requerimientos y se comience a entender mejor el alcance del problema y los requerimientos, los casos de uso se describiran en un formato expandido, el cual, a diferencia del formato esencial agrega una seccion para el curso normal de los eventos, en donde se describe paso a paso cada evento y otra para las excepciones (Larman, 1999).

3.2 Modelo de objetos del dominio

Es una identificacion y representacion de los objetos relevantes al dominio del problema. Un objeto es un concepto, abstraccion, o cosa con fronteras bien definidas y con significado para una aplicacion. Larman (1999) recomienda crear este modelo durante la fase de planeacion, para comprender los aspectos generales del sistema, entender el glosario y efectuar las estimaciones. El indica que: "no debe hacerse una investigacion exhaustiva para no saturar la investigacion desde el principio y evitar exceso de complejidad". En el enfoque de Jacobson este modelo es opcional durante el analisis de requerimientos.

3.3 Modelo de analisis

El modelo de analisis es una representacion de objetos clasificada en tres tipos: entidad, interfaces y control (Figura 2). Este modelo es derivado del modelo de casos de uso. Toma la funcionalidad de cada caso de uso, la particiona en objetos y a cada objeto le asigna una clasificacion. El objetivo de esta clasificacion es crear una estructura adaptable a los cambios. De manera que, si por ejemplo cambian los requerimientos de interfaz, solo se tengan que cambiar los objetos de interfaz.

Los objetos de entidad modelan la informacion que va a existir en el sistema en forma persistente, reflejan abstracciones de entidades del mundo real. Los objetos de interfaz se usan para modelar las interfaces del sistema. Proveen la interfaz del sistema al usuario o a otro sistema (es decir, la interfaz a un actor). Los objetos de control modelan la secuencia especifica de uno o mas casos de uso. Coordinan los eventos para realizar la conducta especificada en el caso de uso (Quatrani, 2003).

[FIGURA 2 OMITTED]

3.4 Tecnica de analisis puntos de funcion

La metodologia de FPA explicada en Garmus, (2001) puede resumirse en los siguientes siete pasos:

Paso 1. Determinar el tipo de conteo de puntos de funcion. Se determina el tipo de conteo de acuerdo con tres posibilidades: para proyectos en desarrollo, para mejora de proyectos y para aplicaciones ya desarrolladas.

Paso 2. Identificar el alcance y las fronteras de la aplicacion que se esta estimando. La frontera es el limite entre el proyecto o aplicacion que esta siendo medida y las aplicaciones externas o el dominio del usuario. En la Figura 3 se muestra la funcionalidad reconocida para el conteo. Se puede observar como los usuarios y las aplicaciones externas pueden interactuar con la aplicacion a traves de las entradas externas, consultas externas y salidas externas.

[FIGURA 3 OMITTED]

Paso 3. Identificar todas las funciones de datos y su complejidad. Las funciones de datos se clasifican en Archivos Logicos Internos (en ingles Internal Logical Files, ILF) y Archivos de Interfaz Externos (en ingles External Interface Files, EIF) y se explican a continuacion:

* Archivos Logicos Internos (en adelante ILF): Es un grupo de datos relacionados logicamente e identificables por el usuario, que se almacena completamente dentro de las fronteras del sistema y sus datos son administrados a traves de uno o mas procesos elementales (es decir, a traves de Entradas Externas que se explicaran mas adelante).

* Archivos de Interfaz Externos (en adelante EIF): Es un grupo de datos relacionados logicamente e identificables por el usuario, que se utilizan solamente para fines de referencia por la aplicacion que se esta estimando, ya que los datos son administrados por las Entradas Externas de otras aplicaciones, es decir, cada EIF es un ILF de otra aplicacion.

El conteo fisico de ILF y EIF junto con la complejidad relativa de cada uno, determina la contribucion a los PF desajustados. Esta complejidad se encuentra determinada por el numero de elementos de datos o atributos del archivo (en ingles "data element types", DET) y de tipos de registros (en ingles "record element types", RET) asociados a cada uno. Los RET son los grupos o subgrupos que constituyen una parte de un archivo; en el enfoque OOSE se puede ver como una agregacion de un objeto. Dependiendo del numero de DET y RET de los ILF y EIF la metodologia FPA propone determinados pesos, los cuales ayudan a establecer si la complejidad es alta, media o baja. Para mas referencia consultar (Garmus, 2001).

Paso 4. Identificar todas las funciones transaccionales y su complejidad. Las funciones transaccionales se clasifican en Entradas Externas, Salidas Externas y Consultas Externas y se describen de la siguiente manera:

* Entradas Externas (EI, External Inputs en ingles): Es un proceso elemental que procesa datos o informacion de control que ingresan a la aplicacion. Los datos procesados administran uno o mas ILF. La informacion de control puede o no administrar un ILF. La intencion de un EI es administrar uno o mas ILF y alterar la conducta de la aplicacion a traves del procesamiento logico. La tarea de administrar puede ser reconocida por los verbos: agregar, modificar, eliminar, actualizar, asignar, evaluar, guardar como y crear.

* Salidas Externas (EO, External Outputs en ingles): Es un proceso elemental que genera datos o informacion de control desde adentro hacia afuera de la aplicacion. El objetivo principal es presentar informacion al usuario mediante el procesamiento logico, el cual debe contener al menos una formula matematica, calculo o crear datos derivados, los cuales se calculan a partir de otros. Adicionalmente, un EO puede actualizar uno o mas ILF y/o alterar el comportamiento del sistema.

* Consultas Externas (EQ, External Inquiries en ingles): Es un proceso elemental que recupera datos o informacion de control para enviarlos fuera de la aplicacion. El objetivo principal es mostrar informacion al usuario a traves de la recuperacion de datos o informacion de control desde un ILF o un EIF. El procesamiento logico no contiene formulas matematicas o calculos, ni crea datos derivados. Ningun ILF es administrado durante el procesamiento por un EQ, por lo que la conducta de la aplicacion no se altera.

El conteo fisico de EI, EO y EQ, junto con la complejidad relativa de cada uno, determina la contribucion a los PF desajustados. Esta complejidad se encuentra determinada por el numero de elementos de datos (o DET) y de archivos referenciados (en ingles "file types referenced", FTR) asociados a cada transaccion. Los FTR para las transacciones EI y EO corresponden al numero total de ILF administrados o leidos y de EIF leidos por dichas transacciones. En el caso de los EQ los FTR se refieren al numero total de ILF y EIF leidos por las transacciones EQ.

Dependiendo del numero de DET y de FTR en las transacciones EI, EO y EQ, la metodologia FPA propone determinados pesos los cuales ayudan a establecer si la complejidad es alta, media o baja. Para mas referencia consultar Garmus, (2001).

Paso 5. Determinar los puntos de funcion sin ajustar. Para obtener el total de Puntos de Funcion Sin Ajustar (en adelante PFSA) se utilizan la informacion obtenida en los pasos anteriores y, dependiendo de la complejidad de cada archivo o transaccion, se le asigna un peso de acuerdo con el Cuadro 1.

Paso 6. Determinar el valor del Factor de Ajuste. Con el fin de adaptar la estimacion de los PFSA a las condiciones de trabajo bajo las cuales la aplicacion va a ser desarrollada, se debe calcular el Factor de Ajuste (FA). Para estimar el FA se debe aplicar la formula (1), pero antes se debe estimar el Grado Total de Influencia (GTI).

FA = (GTI x 0,1) + 0,65 (1)

El GTI corresponde a la suma de catorce caracteristicas las cuales son: Comunicacion de Datos, Procesamiento de Distribuido de Datos, Rendimiento, Configuracion fuertemente utilizada, Frecuencia de Transacciones, Frecuencia de Transacciones, Entrada de Datos en Linea, Diseno para la eficiencia del Usuario Final, Actualizacion de datos en Linea, Procesamiento complejo, Reusabilidad del codigo, Facilidad de instalacion, Facilidad de operacion (Soporte de respaldo), Instalacion en distintos lugares, Facilidad de cambio.

A cada una de esas caracteristicas se le asigna un peso entre 0 y 5 que indica la importancia de la caracteristica para el sistema bajo analisis. El peso 0 indica que la caracteristica no presenta ninguna influencia en el desarrollo de la aplicacion y 5 indica que influye fuertemente.

Paso 7. Calcular los puntos de funcion ajustados. Finalmente los Puntos de Funcion finales (ya ajustados) se obtienen a traves de la formula (2) y es el resultado de multiplicar Puntos de Funcion sin Ajustar por el Factor de Ajuste.

PF = PFSA * FA (2)

4. METODOLOGIA PROPUESTA PARA ESTIMAR Y PLANIFICAR

A continuacion se explica la metodologia propuesta para estimar el tamano de la aplicacion utilizando los procedimientos del FPA y los modelos orientados a objetos, y posteriormente, estimar el esfuerzo y la duracion del proyecto con base en el tamano estimado. Las tareas por realizar son las siguientes:

1. Modelar los casos de uso.

2. Identificar los objetos o archivos.

3. Identificar las transacciones o servicios.

4. Estimar el tamano de la aplicacion en puntos de funcion.

5. Estimar el esfuerzo con base en el tamano.

6. Estimar la duracion del proyecto.

4.1 Modelar los casos de uso

El modelo de casos de uso permite delimitar las fronteras de la aplicacion a la que se le esta estimando el tamano. No se puede hacer un mapeo uno a uno entre los actores y los usuarios o las aplicaciones externas. Sin embargo, cualquier usuario de la aplicacion representa a un actor. De la misma manera, cualquier otra aplicacion que se comunique con la aplicacion que se esta estimando, representa un actor.

Para asegurar un mapeo consistente entre los modelos de OOSE y los procedimientos de FPA se utilizaron las siguientes reglas segun Fetcke, T., Abran, A. & Nguyen, T, (1997):

1. Aceptar cada actor humano como un usuario del sistema.

2. Aceptar cada actor no humano como una aplicacion externa.

3. Rechazar cualquier actor no humano que sea parte del sistema en consideracion, como por ejemplo: un sistema administrador de base de datos o un dispositivo de impresion.

Para explicar la metodologia se va a tomar como ejemplo el desarrollo de un "Sistema de Ordenes de Compra": En la Figura 4 se muestran los requerimientos del sistema representado en un diagrama de casos de uso. Puede verse como la funcionalidad esta delimitada a traves de los casos de uso y de los actores, que en este ejemplo son usuarios solamente, porque el sistema no interactua con ninguna aplicacion externa.

[FIGURA 4 OMITTED]

Esta tarea corresponde al paso 2 de la metodologia FPA descrita en la seccion 3.4 de este documento.

4.2 Identificar los objetos o archivos

Para realizar esta tarea se requiere contar con documentacion del modelo de objetos del dominio o del modelo de analisis. Es probable que por ser una etapa tan temprana solo se disponga del primer modelo, es decir, solo se han identificado los objetos relevantes al dominio del problema.

Para cualquiera de los dos modelos se utilizaron las siguientes reglas recomendadas por Fetcke et al, (1997) para identificar los archivos:

Si se dispone del modelo de objetos del dominio las reglas son:

1. Seleccionar todo objeto del dominio como candidato a archivo logico.

2. Ningun otro objeto sera seleccionado. Si se cuenta con el modelo de analisis, las reglas son:

1. Seleccionar todos los objetos de tipo entidad como candidatos a archivos logicos.

2. Ningun otro objeto sera seleccionado.

Ademas de aplicar las reglas anteriores, esta tarea de identificar los archivos logicos se facilita si se utiliza la descripcion de los escenarios en los casos de uso, que deberian de complementar el diagrama de casos de uso del paso anterior. Dependiendo del grado de investigacion de los requerimientos, los casos de uso pueden estar descritos tal y como lo recomienda Larman, (1999), en formato de esencial o en formato expandido. Al principio se describira en formato esencial, y conforme se obtenga mas informacion se detallara mas y se describira en formato extendido. Pero sin importar el formato, cualquier procesamiento relacionado con la administracion de datos indica la presencia de algun ILF al que hay que administrarle los datos, y cualquier procesamiento que requiera consultar informacion de alguna base de datos externa, indica la presencia de algun EIF.

Tomando el ejemplo del "Sistema de ordenes de compra" (modelado en la figura 4) se deberian identificar los siguientes objetos: Clientes, Ordenes de Compra y Productos. (1)

Estos objetos son candidatos a ser archivos logicos o ILF de acuerdo con la metodologia del FPA. En un analisis posterior podria ser que entre Orden de Compras y Productos exista una relacion de agregacion, por lo que Productos no seria un ILF sino un RET, pero en una etapa tan temprana, en donde las tablas del sistema no estan todavia en tercera forma normal, esta relacion podria entenderse como una asociacion.

Algunos datos que bajo las convenciones de FPA son archivos (ILF o EIF) puede ser que no se representen en el modelo de objetos, aunque su funcionalidad sea requerida por el usuario. Por ejemplo: mensajes de error o textos de ayuda pueden ser un requerimiento y no necesariamente son modelados como objetos.

La metodologia propuesta no analiza la complejidad de los ILF o EIF desde el punto de vista de DET y RET, tal como lo propone el FPA, porque se supone que durante las primeras fases del ciclo de vida, no se conoce el detalle de los archivos como para determinar su complejidad. Esta tarea corresponde al paso 3 de la metodologia FPA descrita en el punto 3.4 de este documento.

4.3 Identificar las transacciones o servicios

Para realizar esta tarea se requiere contar con documentacion del modelo de casos de uso y con la descripcion de los casos de uso (suficiente en formato esencial). Hay una correspondencia entre las transacciones del FPA y los casos de uso de OOSE, pero no hay una relacion de uno a uno entre ambos, es decir, un caso de uso podria ser contado como una o mas transacciones, dependiendo de las tareas que realice.

Para asegurar un mapeo consistente entre los modelos de OOSE y las transacciones de FPA Fetcke et al, (1997) han creado las siguientes reglas:

1. Seleccionar cada caso de uso que tenga una relacion con un actor aceptado. Este caso de uso sera candidato para una o mas transacciones.

2. Seleccionar cada caso de uso que extienda a un caso de uso seleccionado por la regla anterior. La extension puede incluir una interaccion con un usuario o una aplicacion externa. Se debe notar que las flechas en el modelo de casos de uso no indican el tipo de transaccion.

3. Ningun otro caso de uso debe ser seleccionado.

Si se aplican estas reglas al ejemplo del "Sistema de ordenes de compra" se pueden identificar ocho transacciones, una por cada caso de uso, las cuales se muestran en el Cuadro 3.

De los ocho casos de uso identificados y presentados en el Cuadro 3, los cinco primeros son EI porque actualizan el ILF de Clientes, el ILF de Ordenes de Compras y el ILF de Productos. Los tres ultimos son EQ porque simplemente consultan los ILF. No se consideran EO porque hasta el momento el usuario no ha indicado que la consulta requiere algun calculo en los datos, ni actualizan uno o mas ILF que alteren el comportamiento del sistema.

Se observa como en el paso anterior, la metodologia propuesta no analiza la complejidad de las transacciones desde el punto de vista de DET y FTR, como lo propone la metodologia FPA, porque de igual manera no se cuenta con informacion detallada de las transacciones. Esta tarea corresponde al paso 4 de la metodologia FPA descrita en el punto 3.4 de este documento.

4.4 Estimar el tamano de la aplicacion en puntos de funcion

En esta tarea se deben realizar los pasos 5 y 6 de la metodologia FPA explicada en la seccion 3.4. Con la informacion obtenida de los archivos (ILF y EIF) y de las transacciones (EI, EO y EQ) identificados en los pasos anteriores para el "Sistema de Ordenes de Compra", se procedera a estimar el tamano de la aplicacion. En la tabla 4 puede observarse como a todos los archivos y transacciones identificadas se les asigna una complejidad media. Como se indico en los dos pasos anteriores, no se puede determinar la complejidad, porque no se dispone de informacion detallada por estar trabajando en una fase tan temprana del ciclo de vida, por lo que todos se consideran con una complejidad media.

Una vez obtenidos los PFSA se debe calcular el FA, pero previamente se debe haber estimado el peso de las catorce caracteristicas generales del GTI. Se asumira que despues de haberle asignado un peso a las catorce caracteristicas y aplicado la formula (1) se obtiene un FA de 1,0 2. Seguidamente se aplica la formula (2) y se obtiene un tamano estimado de 62 Puntos de Funcion Ajustados.

4.5 Estimar el esfuerzo con base en el tamano

Una vez que se ha estimado el tamano del software, se debe derivar el esfuerzo requerido para desarrollarlo. A pesar de que hay una larga lista de factores que influyen en la productividad del desarrollo tales como: funcionalidad solicitada, restricciones del proyecto, tecnologia, metodos y ambiente de desarrollo, nivel de las habilidades y estabilidad de los requerimientos, Lawrie, (2002) propone dos enfoques de estimacion importantes que se utilizan comunmente y se describen a continuacion:

1. Estimacion micro: en este metodo el esfuerzo asociado con cada componente o actividad de las tareas es estimado individualmente y el resultado produce una estimacion general del proyecto. Este es un enfoque "bottom-up".

2. Estimacion macro: este metodo usa un enfoque "top-down". Trabaja sobre la base de promedios estadisticos. Esencialmente trata de encontrar proyectos terminados con atributos similares y extrapolar la experiencia en los nuevos proyectos. Algunos atributos que se deben considerar son: el tipo de plataforma (cliente servidor, mainframe, etc.), tipo de lenguaje (C, Java), tipo de proyecto (software de sistema, software de aplicacion, etc.), tipo de sistema operativo (Windows, Unix, etc.).

La extrapolacion puede ser simplemente por analogia, pero a menudo es soportada por uno o mas algoritmos que producen la estimacion del esfuerzo, como una funcion del numero de variables las cuales son consideradas como "effort drivers" (factores de costos).

Respecto a la estimacion macro Lawrie, (2002) indica que: "Los algoritmos que se utilizan en la estimacion macro no son utiles en proyectos muy pequenos." Ademas, "hay un acuerdo general que indica que los proyectos muy pequenos pueden variar ampliamente en su productividad. Aunque no se ha especificado un tamano que constituya un proyecto pequeno, muchos especialistas en metricas han acordado un limite inferior entre 50-100 PF. (Por ejemplo, Capers Jones usa 50 PF. Bankers Trust, Australia, usa 40 PF.)"

El Analisis de Puntos de Funcion tiene un papel importante en ambos enfoques:

El Cuadro 5, indica que para la estimacion micro es necesario, ademas de conocer el tamano funcional de la aplicacion que se esta estimando, previamente haber determinado la tasa de productividad promedio de la organizacion. Para determinarla, la organizacion requiere haber pasado por un proceso de recoleccion de metricas sobre proyectos terminados con atributos similares. Entre los atributos estan: tipo de proyecto, tamano, metas del proyecto (en cuanto a costo, calidad y tiempo), plataforma de desarrollo, lenguaje y seleccion de tareas (en terminos de actividades y entregables asociados a esas actividades).

En cambio, en la estimacion macro lo unico que se requiere es conocer el tamano funcional de la aplicacion que se esta estimando y aplicarlo en las formulas recomendadas por la industria que se indicaran mas adelante.

Segun Lawrie, (2002): "Tipicamente los proveedores de servicios de Tecnologia de Informacion usan la tecnica de estimacion micro (por tarea o por algun componente) para desarrollar la estimacion del esfuerzo. Posteriormente, la tecnica de estimacion macro es utilizada, para validar la estimacion micro. Cuando la estimacion difiere de mas del (10-15) % entonces se retrabaja lo estimado. No es conveniente utilizar solamente las tecnicas de estimacion macro, cuando se trata de contratos o licitaciones para propositos comerciales serios."

En el curso de Ingenieria de Software de la carrera de Ciencias de la Computacion e Informatica en la Universidad de Costa Rica, aunque los proyectos son relativamente pequenos (aproximadamente entre 150 PF y 250 PF) se utilizan ambos enfoques por fines didacticos, aunque se le presta mas atencion y se le dedica mas tiempo a la estimacion micro. A continuacion se explica la forma como se aplican ambos enfoques en dicho curso.

4.5.1 Enfoque micro (o estimacion consolidada del esfuerzo)

Para estimar el esfuerzo utilizando el enfoque micro, se requiere conocer el tamano funcional de la aplicacion y la tasa de productividad de la organizacion, obtenida a traves de bases de datos con experiencias propias de la organizacion y aplicarla en la siguiente formula:

Esfuerzo = Tamano funcional * Tasa de productividad (3)

Donde la tasa de productividad puede expresarse como Horas/Puntos de Funcion.

En algunas organizaciones, para determinar la tasa de productividad asignan inicialmente un dia de esfuerzo por cada Punto de Funcion, y a medida que se van concluyendo los proyectos se actualiza dicho valor. Si no esta disponible la tasa de productividad, la organizacion puede ser ayudada por valores medios de la industria.

En mi caso, de acuerdo con metricas recogidas durante un ano con estudiantes del curso de Ingenieria de Software se encontro que la tasa de productividad promedio de los estudiantes era de seis horas por Punto de Funcion, aproximadamente. En esta investigacion se trabajo con ocho equipos de cinco estudiantes cada uno, desarrollando proyectos de una complejidad media. Trabajaron el ciclo de vida completo, desde la fase de conceptualizacion hasta la entrega. Ademas, los estudiantes desconocian las metodologias y herramientas que utilizaron en el desarrollo, porque eso lo aprendieron en el curso durante el ano.

Continuando con el ejemplo del "Sistema de Ordenes de Compra" se tiene que la aplicacion mide 62 PF. Si se asume una tasa de productividad de 6 h/PF y se aplican estos datos en la formula (3) se tiene:

Esfuerzo = 62 PF * 6 h/PF = 372 h persona (4)

Esto significa que una persona tardara aproximadamente 372 h desarrollando la aplicacion.

4.5.2 Enfoque macro (o estimacion indicativa del esfuerzo)

Una estimacion indicativa o rapida usualmente se utiliza cuando hay poco tiempo e informacion para desarrollar sus propias metricas de productividad. Lo unico que se debe hacer para estimar el esfuerzo es sustituir el tamano obtenido en PF en las formulas obtenidas por la industria. A continuacion se presentan dos tecnicas de estimacion macro recomendadas (Lawrie, 2002):

* Tecnica Capers, Jones del SPR "Software Productivity Research" nos propone la siguiente formula:

Esfuerzo = (Tamano en PF /150) * Tamano en [PF.sup.0,4] (5)

En los algoritmos de Capers Jones el esfuerzo incluye a los desarrolladores de software, al personal de calidad, a los encargados de pruebas, a los que escriben material tecnico, a los administradores de bases de datos y a los administradores del proyecto.

Siguiendo con el ejemplo del "Sistema de Ordenes de Compra", al aplicar la formula de Capers Jones en (5), se obtiene:

Esfuerzo = (62 PF /150) * 62 [PF.sup.0,4] = 2,15 meses persona = 345 h persona (3) (6)

Esto significa que una persona tardara aproximadamente 345 h desarrollando la aplicacion.

* Tecnica del ISBSGs. Las ecuaciones derivadas de los datos ISBSGs, para valores "benchmarked" como valores medios de esfuerzo para desarrollo son:

Para todos los proyectos: Esfuerzo = 11,79 * tamano en [PF.sup.0,898] (7)

Para proyectos 3GL: Esfuerzo = 5,76 * tamano en [PF.sup.1,062] (8)

Para proyectos 4GL: Esfuerzo = 9,32 * tamano en [PF.sup.0,912] (9)

En los algoritmos del ISBCG, el esfuerzo incluye a los desarrolladores de software, administradores de proyecto y a la administracion.

SE asume que el "Sistema de Ordenes de Compra" se va a programar con un Lenguaje de Cuarta generacion (o 4GL) y se aplica la ecuacion (9):

Para proyectos 4GL: Esfuerzo = 9,32 * [62.sup.0,912] = 401 h persona (10)

Esto significa que una persona tardara aproximadamente 401 h desarrollando la aplicacion.

4.6 Estimar la duracion del proyecto

Para estimar la duracion de un proyecto de software se usan los siguientes factores:

1. la estimacion del esfuerzo (obtenida en los pasos anteriores),

2. la plantilla de fases del ciclo de vida incluyendo el traslape entre fases y tareas,

3. la distribucion del esfuerzo en las diferentes fases-tareas, y

4. la disponibilidad del personal (en cuanto a numero y a tiempo).

Con esta informacion y una herramienta automatizada para administrar proyectos como por ejemplo: Microsoft Project, se estima la duracion total del proyecto.

5. CONCLUSIONES

1. El tamano estimado del software es muy importante en la planificacion de proyectos, porque es un indicador del esfuerzo, de la duracion, del costo y de los recursos requeridos (humanos, de software y de hardware) para desarrollarlo.

2. La tecnica FPA requiere disponer de informacion muy detallada en una fase temprana, como es la conceptualizacion del proyecto, en donde apenas se esta evaluando su viabilidad. Las reglas de conteo del FPA requieren conocer cierto nivel de detalle de los archivos y de las transacciones de la aplicacion para determinar su complejidad y estimar el tamano de la aplicacion. Para identificar dicha complejidad se ha utilizado el diagrama de Entidad- Relacion, el cual es tipicamente una herramienta de las tecnicas de diseno estructurado.

3. La dificultad de conocer informacion tan detallada en una etapa tan temprana como son: los atributos (DET) y los subgrupos (RET) en los archivos, y los atributos (DET) y los archivos referenciados (FTR) en las transacciones para estimar la complejidad, permite concluir que la metodologia se esta forzando al querer conocer tanta informacion en este punto y esto mas bien puede generar exceso de complejidad en esta fase. Cuando se esta evaluando la viabilidad del software es suficiente con identificar los archivos ILF y EIF y las transacciones EI, EO y EQ y asignarles una complejidad media.

4. Actualmente los estudiantes utilizan metodos orientados a objetos para desarrollar, y los modelos creados con estos metodos no proveen documentacion tradicional como son los diagramas de Entidad-Relacion, estructuras de bases de datos o modelos de procesos jerarquicos, sino que proveen una serie de modelos que se utilizan especialmente durante las primeras fases del ciclo de vida como: el modelado de casos de uso, el modelo de objetos del dominio y el modelo de analisis.

5. A traves de diferentes proyectos durante varios anos, he comprobado que el estimar la complejidad de los PF y el no hacerlo, representa una diferencia relativamente pequena, para el esfuerzo que representa estimarla en una fase temprana.

6. En una etapa tan temprana como es la conceptualizacion del proyecto se trabaja con requerimientos muy generales, pero no debe ser una excusa para dejar de estimar y planificar. Es importante formular el proyecto y evaluar su viabilidad para decidir si continuar o no el desarrollo. Es perfectamente valido, que despues de esta evaluacion se decida no implementarlo, por lo tanto, los recursos utilizados se podrian desaprovechar si se profundiza en el analisis y peor aun, en el diseno.

7. Una vez finalizada la fase de analisis y que los requerimientos se hayan concluido, es posible conocer la complejidad de los archivos y de las transacciones, y asi afinar mas la estimacion. En este punto se conocen todos los atributos, todas las interacciones del sistema incluyendo las interfaces y reportes. Ya en este momento se puede comenzar a analizar la volatibilidad de los requerimientos y su impacto en el proyecto.

8. Tradicionalmente se ha creido que el conteo de PF no puede ocurrir hasta que el diseno este terminado, lo cual convertiria esta metodologia en algo inutil, porque se perderia uno de los principales objetivos de la planificacion, el cual es determinar la duracion y el costo aproximado del proyecto para evaluar su viabilidad y planificar su desarrollo, desde las primeras etapas del ciclo de vida.

9. Da acuerdo con la experiencia durantes estos anos, es mejor que las organizaciones trabajen en recolectar sus propias metricas para conocer su tasa de productividad y no que tengan que usar una estimacion macro, que si bien es cierto brinda informacion cuando no se cuenta con datos historicos, no es tan acertada.

10. El enfoque macro provee algoritmos que permiten estimar rapidamente el esfuerzo de desarrollo del proyecto con solo conocer el tamano de la aplicacion, y en general los resultados estan muy cercanos al obtenido por estimacion micro. De acuerdo con el ejemplo del "Sistema de Compra", con la estimacion micro se tiene que el proyecto requiere 372 h persona y por estimacion macro 345 h por Capers Jones y 401 h por ISBSG. Sin embargo, no recomiendo utilizar solamente este enfoque, especialmente en proyectos pequenos, sino utilizarlos como complemento al enfoque micro.

Recibido: 07 de julio del 2006 * Aprobado: 18 de enero del 2007

REFERENCIAS BIBLIOGRAFICAS

Fetcke, T., Abran, A. & Nguyen, T. (28 Jul--1 Aug 1997). Mapping the OO-Jacobson approach into function point analysis. TOOLS, 23'97. USA: Copyright 1998 IEEE.

Garmus, D. & Herron, D. (2001). Measuring the software process. A practical guide to funcional measurements. United States of America: Addison Wesley.

Kan, S. (2003). Metrics and models in software quality engineering. (2a ed). United States of America: Adisson Wesley.

Larman, C. (1999). UML Y PATRONES. Introduccion al analisis y diseno orientado a objetos. Mexico: Prentice Hall Hispanoamerica, S. A.

Lawrie, R (2002). Using functional sizing in software project estimating. Charismatek Software Metrics. Australia. http://www. Charismatek.com.

McConnell, S. (1997). Desarrollo y gestion de proyectos informaticos. Espana: McGraw-Hill Interamericana.

Peralta, M. (2004) Estimacion del esfuerzo basada en casos de uso. [Version electronica]. Reportes Tecnicos en Ingenieria de Software, 6(1), 1-16.

Pressman, R. (2006). Ingenieria de Software: un enfoque practico. (6a ed). Mexico, D. F: McGraw-Hill Interamericana.

Quatrani, T. (2003). Visual modeling with rational rose 2002 and UML. United States of America: Addison Wesley.

NOTAS

(1.) Se asume que toda orden de compra requiere asociar los productos solicitados en la compra.

(2.) Para facilitar el calculo se esta considerando un FA de 1,0.

(3.) Asumir 160 h de trabajo por mes. Esto incluye 4 semanas, de 5 dias de trabajo y 8 h laborales por dia.

Gabriela Salazar Bermudez

Universidad de Costa Rica, Escuela de Ciencias

de la Computacion e Informatica

Apartado postal: 36-2060. San Pedro, Costa Rica.

Telefono: 227 9544, Facsimil: 207 4020

Correo electronico: gsalazar@ecci.ucr.ac.cr
Cuadro 1. Pesos.

                                                Complejidad
Componentes                              Baja      Media     Alta

Archivos Logicos                         x7       x10         x15
Archivos de Interfaz Externos (EIF)      x5        x7         x10
Entradas Externas (EI)                   x3        x4          x6
Salidas Externas (EO)                    x4        x5          x7
Consultas Externas (EQ)                  x3        x4          X6
Total PFSA

Fuente: (Garmus, 2001)

Cuadro 2. Archivos logicos identificados en el
ejemplo "Sistema de ordenes de compra"

Archivo de Ordenes      ILF

Archivo de Clientes     ILF

Archivo de Productos    ILF

Cuadro 3. Transacciones
"Sistema de ordenes de compra"

Funcion                                 Tipo

Agregar un cliente                      EI
Modificar un cliente                    EI
Eliminar un cliente                     EI
Agregar una nueva orden                 EI
Iniciar una solicitud de cambio         EI
Revisar el estado de una orden          EQ
Notificar orden a los clientes          EQ
Generar un informe regional             EQ

Cuadro 4. Calculo de los Puntos de Funcion
Ajustados.

                                             Complejidad
Componentes                              Baja     Media    Alta

Archivos Logicos Internos (ILF)          X7       3x10     x15
Archivos de Interfaz Externos (EIF)      X5       0x7      x10
Entradas Externas (EI)                   X3       5x4      x6
Salidas Externas (EO)                    X4       0X5      x7
Consultas Externas (EQ)                  X3       3X4      x6
Puntos de Funcion Sin Ajustar (PFSA)     62
Factor de Ajuste (FA)                    1,0
Puntos de Funcion Ajustados (PFA)        62

Cuadro 5. Metodos de estimacion para uso de los
Puntos de Funcion

Metodo               Uso de los Puntos de Funcion

Estimacion micro     El alcance del proyecto establecido
                     como primer paso de la tecnica FPA
                     ayuda a aclarar las tareas que deben
                     realizarse. El tamano funcional permite
                     calcular la tasa de productividad
                     esperada, comparandola con datos

Estimacion macro     El tamano funcional es una entrada
                     clave en los algoritmos o formulas de
                     estimacion.

Fuente: (La autora)
COPYRIGHT 2006 Universidad de Costa Rica
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2006 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Nota tecnica
Author:Salazar Bermudez, Gabriela
Publication:Ingenieria
Date:Aug 1, 2006
Words:7112
Previous Article:Estudio catodico de cinetica de corrosion del acero al carbon en fluido geotermico mediante un electrodo de disco rotatorio.
Next Article:Sintonizacion de controladores PI y PID utilizando modelos de polo doble mas tiempo muerto.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters