HERRAMIENTA PARA ESTIMAR EL TAMAÑO DE SOFTWARE...

1

HERRAMIENTA PARA ESTIMAR EL TAMAÑO DE SOFTWARE POR EL MÉTODO DE PUNTOS DE FUNCIÓN

PRESENTADO POR: LUIS ANGEL VARGAS TORRES.

HAMMER EMILIO YANDY TORRES.

UNIVERSIDAD DE SAN BUENAVENTURA, SECCIONAL CALI

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS

SANTIAGO DE CALI, 18 DE JULIO DE 2011

2

HERRAMIENTA PARA ESTIMAR EL TAMAÑO DE SOFTWARE POR EL MÉTODO DE PUNTOS DE FUNCIÓN

PRESENTADO POR: LUIS ANGEL VARGAS TORRES.

HAMMER EMILIO YANDY TORRES.

TRABAJO DE GRADO PRESENTADO PARA OPTAR POR TÍTULO DE INGENIERO DE SISTEMAS

DIRECTOR:

INGENIERO LUIS MERCHAN

PROFESOR TITULAR

UNIVERSIDAD DE SAN BUENAVENTURA, SECCIONAL CALI



SANTIAGO DE CALI, 18 DE JUILIO DE 2011

3

UNIVERSIDAD DE SAN BUENAVENTURA CALI



RECTOR:

FRAY ÁLVARO CEPEDA VAN HOUTEN

DECANO FACULTAD DE INGENIERÍA:

CLAUDIO CAMILO GONZÁLEZ CLAVIJO

DIRECTOR DEL PROGRAMA DE INGENIERÍA DE SISTEMAS:

INGENIERO EDGAR FELIPE ECHEVERRY

4

Nota de aceptación:

_____________________________________

_____________________________________

_____________________________________

_____________________________________

_____________________________________

_____________________________________

_____________________________________

_____________________________________

Firma del director del proyecto de grado

_____________________________________

Firma del jurado

_____________________________________

Firma del jurado

Santiago de Cali, 18 de Julio de 2011

5

DEDICATORIA:

Este proyecto está dedicado en primer lugar a Dios, porque gracias a él este logro es alcanzado.

A todas las personas que estuvieron presentes para poder llevar a cabo la culminación del mismo. También, está dedicado a todas las personas que nos brindaron el apoyo para lograr lo que un día nos propusimos con tanto empeño y entusiasmo, como fue estudiar la carrera de Ingeniería de Sistemas.

Por último dar gracias a nuestros familiares que siempre estuvieron a nuestro lado apoyándonos y aconsejándonos para que no decayéramos en momentos difíciles.

6

CONTENIDO

INTRODUCCIÓN ............................................................................................................. 13

OBJETIVOS ..................................................................................................................... 14

OBJETIVO GENERAL .................................................................................................. 14

OBJETIVOS ESPECÍFICOS ......................................................................................... 14

1. MARCO TEÓRIO ...................................................................................................... 15

1.1. Estimación ........................................................................................................ 15

1.1.1. Consecuencias de una mala estimación ..................................................... 15

1.1.2. Beneficios de una buena estimación ........................................................... 16

1.2. Errores en la estimación ................................................................................... 17

1.3. Administración de proyectos de software .......................................................... 18

1.4. Importancia de la estimación para el modelo CMM - CMMI en el nivel 2........... 20

1.4.1. Niveles de madurez del modelo CMM –CMMI ............................................ 21

1.4.2. Ventajas del modelo CMM – CMMI ............................................................. 23

1.4.3. Desventajas del modelo CMM – CMMI ....................................................... 23

1.4.4. Métodos basados en Modelos..................................................................... 24

1.5.1.1. PRICE – S ............................................................................................... 24

1.5.1.2. Módelo Slim (Software Lifecycle Management) ........................................ 25

1.5.1.3. Módelo SEER (System Evaluation and Estimation of Resources) ............ 27

1.5.1.4. COCOMO 81 ........................................................................................... 28

1.5.1.5. Módelo ESTIMACS .................................................................................. 30

1.5.2. Métodos basados en expertos .................................................................... 32

1.5.2.1. Juicio de expertos ................................................................................ 32

1.5.2.1.1. DELPHI: .......................................................................................... 32

1.5.2.1.2. WBS (Work Breakdown Structure): ................................................. 33

1.5.2.1.3. Sistemas basados en reglas (SBR)................................................. 33

1.5.3. Otros Métodos de Estimación ..................................................................... 35

1.5.3.1. Método de Puntos de Función (FP) ...................................................... 35

1.5.3.2. Estimación basada en líneas de código (LOC)..................................... 41

1.5.3.3. Puntos de casos de uso (UCP) ............................................................ 42

1.5.3.4. COCOMO II ........................................................................................ 43

1.5.3.5. Estimación por analogía ....................................................................... 45

1.6. Resumen comparativo de los modelos y métodos. ........................................... 47

2. LA ESTIMACIÓN DEL TAMAÑO BASADA EN PUNTOS DE FUNCIÓN .................... 49

2.1. Esquema del método de puntos de función ........................................................... 49

7

2.1.1. Paso 1: CALCULO DE LOS PUNTOS DE FUNCIÓN SIN AJUSTAR .............. 49

2.1.1.1. Determinar el peso de cada componente funcional .................................. 49

2.1.1.2. Hallar los componentes funcionales ......................................................... 50

2.1.1.3. Calcular el total de puntos de función sin ajustar ..................................... 56

2.1.2. Paso 2: CALCULO DE LOS PUNTOS DE FUNCIÓN AJUSTADOS ................ 58

2.1.2.1. Evaluar las Características Generales del Sistema (GSC) ....................... 58

2.1.2.2. Determinar el valor del factor de Ajuste (VAF). ......................................... 66

2.1.2.3. Calcular el total de puntos de función de toda la aplicación. .................... 67

3. Importancia de la estimación con base en puntos de función. ................................... 68

3.1. Características del método de puntos de función ................................................... 68

3.2. Predicciones basadas en puntos de función .......................................................... 69

3.2.1. Predicciones del tamaño de volúmenes de código fuente ............................... 69

3.2.2. Predicción del tamaño de los entregables en papel ......................................... 70

3.2.3. Predicción de fechas límite para el software .................................................... 71

3.2.4. Predicción de número de empleados para desarrollar una aplicación ............. 72

3.2.5. Predicción de años que estará en uso la aplicación ....................................... 73

3.2.5. Predicción de costos para el total de empleados ............................................. 74

4. Herramienta desarrollada (EstimaSoft)...................................................................... 75

5. CONCLUSIONES ..................................................................................................... 83

BIBLIOGRAFIA ................................................................................................................ 84

8

LISTA DE TABLAS

Tabla 1. Errores en la estimación. ................................................................. 18

Tabla 2. Ejemplo de los sistemas basados en expertos. ............................... 34

Tabla 3. Cuadro comparativo métodos de estimación. .................................. 48

Tabla 4. Complejidad para cada componente funcional ................................ 50

Tabla 5. Clasificación de complejidad para las entradas externas. ................ 51

Tabla 6. Clasificación de complejidad para las salidas externas. ................... 52

Tabla 7. Clasificación de complejidad para las consultas externas. ............... 54

Tabla 8. Clasificación de complejidad para los archivos lógicos .................... 55

Tabla 9. Clasificación de complejidad para los archivos de interfaz externos.55

Tabla 10. Calculo total de los puntos de función no ajustados ....................... 56

Tabla 11. Ejemplo calificación complejidad de cada componente funcional ... 56

Tabla 12. Tabla ejemplo cálculo total de los puntos de función sin ajustar. .... 57

Tabla 13. Tabla ejemplo sumatoria total GSC. ............................................... 66

Tabla 14. Tabla conversión PF a líneas de código [JC., 2008]. ..................... 69

9

LISTA DE FIGURAS

Figura 1. Cono de la Incertidumbre de Steve McConnell [MCS., 1997] ......... 19

Figura 2. Curvas de Rayleigh ........................................................................ 25

Figura 3. Evolución métodos basados en puntos de función. ........................ 40

Figura 4. Entradas externas .......................................................................... 51

Figura 5. Salidas externas............................................................................. 52

Figura 6. Consultas externas ....................................................................... 53

10

GLOSARIO

ISO (International Organization For Standardization): La Organización Internacional para la Estandarización (ISO) es una federación de alcance mundial integrada por cuerpos de estandarización nacionales de 159 países, uno por cada país, con una secretaría central en Ginebra, Suiza, que coordina el sistema [ISO., nd].

LOC (Line Of Code): Métrica de tamaño tradicional para estimar el esfuerzo de

desarrollo y productividad [WIKILC., 2011].

TI (Tecnología de Información): Según lo definido por la asociación de la

tecnología de información de América (ITAA) es “el estudio, diseño, desarrollo, implementación, soporte o dirección de los sistemas de información computarizados, en particular de software de aplicación y hardware de computadoras.” Se ocupa del uso de las computadoras y su software para convertir, almacenar, proteger, procesar, transmitir y recuperar la información [WIKITI., 2011].

CU (Case of Use): Es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico [WIKICU., 2011].

POO (Programación Orientada a Objetos): Paradigma de programación que usa objetos y sus interacciones, para diseñar aplicación y programas informáticos. Esta basados en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento [WIKIPOO., 2011].

IBM (International Business Machine): Empresa multinacional estadounidense que fabrica y comercializa herramientas, programas y servicios relacionados con la informática [WIKIIBM., 2011].

COCOMO (Constructive Cost Model): Modelo paramétrico usado para estimar el

esfuerzo y calendario de un proyecto de desarrollo de software [CSE., 1999].

11

PUNTOS DE FUNCIÓN (Function Point): Medida del tamaño de un sistema de software y del proyecto que lo construye, esta medida se basa en la teoría de que la funcionalidad del software es la mejor medida de su tamaño [IFPUG., 1999].

12

RESUMEN

En este proyecto de grado se explica la importancia de la estimación en proyectos de software para la industria de desarrollo y se presenta una revisión cronológica de los métodos de estimación utilizados en esta industria. Así mismo, se explica en detalle el método para el cálculo de puntos de función de un proyecto de software, y se explica el porqué se selecciono este método para ser implementado. También se explica cómo se puede hacer una estimación del tamaño, costo, tiempo, documentación, entre otros, con base en los puntos de función. Finalmente, se explica el funcionamiento de la aplicación EstimaSoft, un prototipo desarrollado para calcular el tamaño total de un proyecto de software por el método de puntos de función, producto de este trabajo de grado.

13

INTRODUCCIÓN El mundo actual se está viendo afectado por una dependencia tecnológica que aumenta cada vez más con el pasar de los años. Así mismo, las empresas dedicadas al desarrollo de software ven la necesidad de cumplir con las exigencias del mercado de la industria de software. Para ello estas empresas necesitan cumplir metas con el fin de suplir rápidamente las necesidades de la industria. La estimación de desarrollo de software puede ser la salida a ese inconveniente, una buena estimación no solo ayuda a cumplir con las actividades de una organización dentro de las metas previstas, si no también, ayudan a generar mayores ingresos, mejor ámbito de trabajo, extender más la relación con los clientes, entre otros. En este documento se explica la importancia de la estimación en los proyectos de software haciendo hincapié en los beneficios que conlleva el realizar una buena estimación en un proyecto de software y las posibles consecuencias de realizar una mala estimación. El tener claro cada uno de los aspectos anteriores, resulta de vital importancia para el ciclo de vida de un proyecto, porque así se podrán tomar las decisiones adecuadas antes de emprender cada una de las etapas que comprenden el ciclo de vida de un proyecto de software. Por otra parte se analizan algunos métodos de estimación de tamaño, coste y esfuerzo utilizados en la industria de software como soporte para planificar proyectos de software. Como ya se explicó, el mundo moderno está evolucionando cada vez más rápido a nivel tecnológico y son muchas las empresas de desarrollo que tienen la obligación de suplir las necesidades del avance tecnológico y para ello necesitan de los métodos de estimación (Puntos de función, COCOMO II, Delphi, Slim etc), que ayuden a planificar correctamente el ciclo de vida del proyecto. Sin embargo, hay que ser cuidadosos al momento de saber cuál es el método más apropiado que se debe elegir para que se adapte a las políticas y necesidades de una organización dedicada al desarrollo de software, pues no todos los métodos de estimación se acoplan a las políticas y necesidades de una organización. Por último se hace hincapié en el uso del método de puntos de función como método para realizar la estimación del tamaño en un proyecto de software y se explica porque debería de ser utilizado. También se describe el procedimiento (desde la obtención de la cantidad dé componente funcionales hasta la entrega final de los puntos de función ajustados) para obtener el total de puntos de función que tomará desarrollar un proyecto de software con algunas de las predicciones que se pueden obtener mediante el cálculo de este método.

14

OBJETIVOS

OBJETIVO GENERAL

- Desarrollar una herramienta para la estimación del tamaño de proyectos de software por el método de puntos de función.

OBJETIVOS ESPECÍFICOS

- Hacer una revisión acerca de la importancia y el uso de la estimación en las organizaciones de desarrollo de software.

- Analizar algunos métodos de estimación y describir sus ventajas y desventajas.

- Hacer un análisis comparativo de los métodos de estimación estudiados.

- Profundizar en el uso y la importancia del método de puntos de función, así como el proceso para llevar a cabo el cálculo total de los puntos de función, y de esta manera, poder aplicarlo en la herramienta que se desea desarrollar.

15

1. MARCO TEÓRIO 1.1. Estimación

De acuerdo a Tom De Macro la estimación puede ser definida como:

“Una estimación es una predicción que tiene la misma probabilidad de estar por encima o por debajo del valor actual”

Otras definiciones de estimación encontradas en internet son:

“Determinación del valor o valores del o los parámetros de un cierto modelo con base en la observación de los resultados de un experimento”

“Una suposición cercana al valor real, normalmente por medio de algún cálculo o razonamiento”

De acuerdo con lo anterior, se puede decir que la estimación en un proyecto de software es una aproximación cercana en cuanto al tiempo, costo y esfuerzo que se espera al finalizar un proyecto de software. La estimación de proyectos de software es un factor importante no solo por los resultados que arroja, sino porque ayuda a determinar que tan viable puede llegar a ser el proyecto que se va a desarrollar. Pues que caso tiene realizar un proyecto de software que se sabe no va a ser exitoso [FOL., 2010].

1.1.1. Consecuencias de una mala estimación Muchas de las empresas de desarrollo de software en su afán de vender no tiene en cuenta factores como, alcances del proyecto, fechas límites, administración de recursos, entre otros, que al final resultan decisivos para el desarrollo en un proyecto de software. Estos factores muchas veces se deben a que no se tiene el conocimiento adecuado sobre los pasos a seguir al inicio de un proyecto de software o porque las estimaciones realizadas están muy alejadas de la realidad. Las consecuencias de incurrir en estos errores son graves, ya que muchas veces el equipo de trabajo se ve desmotivado a causa de tener que realizar correcciones que están por fuera de lo acordado. Este a su vez genera que se entregue al cliente un mal producto (Software). Otras de las causas que conllevan a una mala estimación son:

16

Perdida de miembros del mismo equipo, que genera volver a incurrir en los mismos errores, al no tener personas con experiencia.

Pérdida de clientes, debido a los incumplimientos en cuanto a fechas, costos y calidad en el producto (software).

1.1.2. Beneficios de una buena estimación Los beneficios de realizar una buena estimación son muchos, entre ellos se pueden mencionar los siguientes:

La entrega de un buen producto (software): Si al

principio de un proyecto se define claramente cuáles van a ser las condiciones (alcances, fechas, costos) bajo las cuales se desarrollará un proyecto de software, es seguro que al final se tendrá un producto (software) de buena calidad, que llene las expectativas del cliente.

Fidelización de los clientes: Si se cumplen con los

acuerdos realizados al inicio de un proyecto, como resultado se tendrá un cliente satisfecho.

Un buen grupo de trabajo: Como consecuencia de una

buena estimación, se tendrá un buen ambiente laboral entre los miembros de un grupo de trabajo, esto debido a que no se cometerán errores que conllevan a disgustos entre los miembros del grupo de trabajo, y por ende la renuncia.

Mayores ingresos económicos: Como resultado de una

buena estimación, vamos a obtener mayores ingreso económicos debido a que no se van a cometer errores como atrasos en la entrega, correcciones que generan más costos y por ende menos ingreso. Como resultado de no cometer estos errores se tendrá a un cliente satisfecho desembolsando la cantidad de dinero acordada desde un principió y gustoso de volver a realizar nuevos proyectos con la empresa.

Ahorro de costos: El hecho de realizar una buena

estimación en un proyecto de software conlleva a que no se incurra en errores que más adelante causen costos adicionales generados por atrasos en las fechas límites, cambios en la aplicación entre otros.

17

1.2. Errores en la estimación

El error en la estimación es un factor que se debe analizar muy bien antes de realizar cualquier tipo de estimación en un proyecto de software. Estos errores muchas veces conducen a incumplir en el contrato pactado inicialmente con los clientes que desean una aplicación, errores que en muchas ocasiones causan incumplimiento de fechas, costos, mala calidad del producto, entre otros, son los que muchas veces conllevan a que el mismo grupo de trabajo de una organización se vea desmotivado y origine como consecuencia la perdida de personal clave dentro de una organización. Capers Jones en [JC., 2008], menciona que existen 12 problemas muy comunes que suelen suceder al momento de realizar una estimación. A continuación se representará mediante un cuadro los 12 errores de estimación mencionados por Capers Jones de forma resumida:

ERRORES EN LA ESTIMACIÓN

DESCRIPCIÓN

Errores en las métricas

El error más común en la estimación de software son las variaciones en la forma en que se cuenta el código por medio del conteo de (LOC).El problema principal no es ese, el problema principal radica en que suele relacionarse el esfuerzo total del desarrollo de software directamente con el código fuente sin tener en cuenta otros factores entorno al desarrollo.

Errores de escala Se suele utilizar datos históricos de proyectos pequeños para implementarse como base de estimación en proyectos grandes. Esto difiere en que los proyectos grandes requieren de más esfuerzo, y por ende su costo es más elevado que el de un proyecto pequeño.

Errores de ejecutivos y clientes

En muchas ocasiones las estimaciones realizadas por el gerente de un proyecto de software suele ser precisa, pero se presenta que los ejecutivos que aprueban la estimación no estén de acuerdo debido a que piensan que están por fuera del rango de costo y tiempo.

Errores en la predicción del tamaño

Los errores de predicción de tamaño total de diversos entregables suelen ser otro de los errores más comunes en la estimación de software, y más cuando se relaciona con la cantidad de entregables externos donde se incluye la calidad del código fuente, numero de pantallas y número de páginas en materiales de cursos y documentación del usuario.

Errores en la selección de actividades

Las organizaciones dedicadas a desarrollar software en ocasiones cometen el gran error de omitir actividades y tareas a la hora de realizar la estimación. Uno de los errores comunes que se ha encontrado es que pasan por alto los costos de documentación del usuario.

Errores en el ámbito de asignación

La frase ámbito de asignación denota la cantidad de trabajo asignada a un miembro del personal. Los errores en el ámbito de asignación es que muchas veces se le establece demasiado trabajo a una sola persona, de tal forma que el trabajo se vuelve abrumador.

Errores en el índice de producción

La frase índice de producción se refiere a la cantidad de trabajo que una persona puede realizar en un periodo ordinario: una hora, día de trabajo, semana laboral o mes de trabajo. El error que se comete es que se tiende a tener un optimismo excesivo, como asumir índices de redacción de código con más de 3000 instrucciones por mes.

18

Requisitos progresivos del usuario

Omitir los requisitos progresivos se refiere a un fenómeno muy común de no realizar una estimación a la tasa de crecimiento de requisitos no planeados.

Errores de ruta critica

El desarrollo de software se puede definir como una red compleja de cientos de actividades entrelazadas. Un error muy común es no identificar la ruta crítica a través de esta red de actividades, de forma tal que los retrasos en algún componente o entregable clave bajaran el ritmo de avance, y se excedan fechas límites.

Errores de acumulación de personal

Este tipo de error no suele suceder comúnmente, sin embargo, cuando sucede puede llegar a ocasionar daños severos. Este tipo de error sucede cuando hay escasez de personal disponible o el proceso de subcontratación tarda más tiempo del anticipado. Esto lleva a que se excedan fechas.

Errores de ajuste de tecnología

Se refiere a que existen muchos lenguajes, metodologías y herramientas de programación. Y resulta muy difícil ajustar una herramienta de estimación con varios lenguajes, metodologías y herramientas.

Situaciones especiales o únicas

Se refiere a situaciones inusuales que pueden afectar a un proyecto de software. Situaciones como incendios, desastres naturales, incapacidad de miembros claves para el proyecto, entre otras.

Tabla 1. Errores en la estimación.

1.3. Administración de proyectos de software

La administración en los proyectos de software es una tarea vital, debido a que de aquí depende el futuro de un proyecto de desarrollo. En la administración de proyectos de software, se debe tener en cuenta factores como tiempo, costo y esfuerzo que son fundamentales para saber el futuro de un proyecto de software y que sin un manejo adecuado de estos factores se podrían tener serios inconvenientes en el proceso de desarrollo. La administración de proyectos de software, ayuda a tener una visión más clara del camino que se debe seguir para lograr el objetivo final, que en consecuencia es el producto (software) terminado. Para la buena administración en los proyectos de desarrollo se han definido métodos que se explican más adelante, que ayudan a estimar el tamaño, costo y esfuerzo que va a tener un proyecto de desarrollo.

19

Existe una relación entre el tamaño, costo y esfuerzo. Y es que los proyectos de desarrollo basan su coste y esfuerzo a partir del tamaño del mismo, es decir, el tamaño del software es el punto de partida para calcular el coste y esfuerzo de un proyecto de software. Por tal motivo los métodos de estimación del tamaño de software tratan de considerar todos los aspectos (tecnología, tipos de recurso, complejidad) que influyan directamente sobre el costo y esfuerzo de un proyecto. Debido a que este proyecto está enfocado más hacia la estimación del tamaño en los proyectos de desarrollo, vale la pena hacer la siguiente aclaración:

La estimación basada en el tamaño de software se puede aplicar a un proyecto de desarrollo independiente de la etapa en que este se encuentre (planificación, análisis, diseño, o implementación). Un elemento para resaltar de este tipo de estimación es que hay una correspondencia directa entre la estimación del tamaño y la etapa en la que esta es realizada, es decir, entre más avanzado esté el proyecto más real será la estimación del mismo. Tal y como se muestra en la figura 1 donde Steve McConnell en [MCS., 1997] dice: “cualquier variable x del proyecto, por ejemplo costo o esfuerzo, estimada al principio de un proyecto variará entre 4x y 0,25x. A medida que se avanza en el proyecto, se conoce más y se reduce el error, hasta llegar a la certeza, pero sólo cuando el proyecto finaliza”

Figura 1. Cono de la Incertidumbre de Steve McConnell [MCS., 1997]

Factibilidad Requerimientos Diseño Código Entrega

4x

0.25x

0.5x

x

2x

20

1.4. Importancia de la estimación para el modelo CMM - CMMI en el nivel 2.

Para poder entender la importancia de la estimación en el modelo CMM (Capability Maturity Model) en el nivel 2, hay que introducirnos un poco más hacia el concepto como tal. El modelo CMM surge como una necesidad del departamento de defensa de los EEUU, que veía como las aplicaciones que pedían desarrollar por otras empresas sobrepasaban fechas y presupuestos. En el año de 1985 se crea en la Universidad de Carnegie - Mellon el SEI (Software Engineering Institute), instituto encargado de desarrollar y mantener el modelo CMM. La necesidad de generar un modelo más completo hace que en el año 2000 surja un nuevo modelo conocido como CMMI (Capability Maturity Model Integration). [GJ., 2005]. La diferencia entre el modelo CMM y CMMI es que el CMM se concentra solo en procesos de software, mientras que, el modelo de CMMI tiene una visión más amplia de toda la organización. El CMMI es considerado un modelo más robusto, debido a que se enfoca en todos las procesos (sistemas, software, integración de productos y relación con proveedores) de una organización [OBA., 2008]. El SEI, institución encargada de desarrollar y promover este modelo dice en [SEI., 2011], que “CMMI define las prácticas que las empresas deben implementar en su camino hacia el éxito. Estas prácticas cubren temas como obtención y gestión de los requerimientos, toma de decisiones, medición del rendimiento, planificación del trabajo, manejo de riesgos y muchos más”. El modelo CMMI define un marco de referencia para que las organizaciones realicen sus procesos de una manera adecuada. Dentro de este marco de referencia se encuentran definidos unos niveles de madurez en el cual las empresas se ubican dependiendo de la implementación adecuada en los procesos de calidad, es decir, dependiendo de qué tan eficaces sean sus procesos de calidad, así mismo, se define su nivel de madurez.

21

1.4.1. Niveles de madurez del modelo CMM –CMMI

Los niveles de madurez son: Nivel 0 ó Incompleto: En este nivel se clasifican todas

aquellas empresas que no cumple los objetivos, no definen un plan de trabajo o simplemente que los niveles de madurez no son aplicables. [CJM., 2008].

Nivel 1 ó Inicial: En este nivel se clasifican todas aquellas

empresas que no tienen definido ningún tipo de proceso, no toman en cuenta tiempo ni presupuestos para el desarrollo de un proyecto. [GJ., 2005].

Nivel 2 o Gestionado cuantitativamente: También conocido

como repetible debido a que el éxito de los resultados obtenidos en tareas anteriores se pueden repetir. [BSB., 2006]. En este nivel lo que se busca es que se definan procesos al principio de cada etapa de un proyecto de desarrollo. Y que estos procesos se lleven a cabo de la manera adecuada.

Los procesos que se encuentran en este nivel son:

- Gestión de Requisitos: Administración adecuada de

todos los requisitos de un proyecto, tanto los funcionales como los no funcionales.

- Planificación de proyectos: Realizar estimaciones a lo

largo del proyecto de desarrollo con el fin de tener un plan para cada actividad del proyecto.

- Monitorización y Control de proyectos: Realizar

acciones de monitoreo y control, para así saber si se tiene que tomar medidas correctivas en caso de que el proyecto se esté desviando del plan.

- Medición y Análisis: Desarrollar y mantener la

capacidad de tomar mediciones que atiendan las necesidades de información de un proyecto de desarrollo, esto con el fin de saber cómo va el proyecto.

22

- Aseguramiento de la calidad: Proporcionar personal

que supervisen el cumplimiento de todos los procesos en un proyecto de desarrollo. Y así de esta manera asegurar que el software cumplirá con criterios de calidad esperados.

- Gestión de la configuración: Administrar y controlar

los elementos de trabajo involucrados en un proyecto de desarrollo, con el fin de establecer y mantener la integridad de estos elementos.

Nivel 3 ó Definido: En este nivel se define el plan de desarrollo de un proyecto de software, es decir, que ya todos los procesos para el desarrollo de un proyecto de software están documentados de forma clara, para así poder tener un mayor control del proyecto y poder alcanzar los objetivos concretos de la empresa. [GJ., 2005].

Para llegar a este nivel los procesos que se deben realizar son:

Gestión de requisitos. Solución técnica. Integración del producto. Verificación. Validación. Enfoque organizacional del proceso. Definición del proceso de la organización. Formación en la organización. Gestión de riesgos. Análisis de decisiones y resolución.

Nivel 4 ó Gestionado: En este nivel se mide y se controla la

calidad de los productos y procesos de la organización basados en métricas ya establecidas. [OBA., 2008].


Gestión cuantitativa de proyectos. Mejora de los procesos de la organización.

23

Nivel 5 u Optimizado: En este nivel se analizan y se

controlan procesos permanentemente con el fin de realizar mejoras en todo momento. Mejoras que son identificadas y evaluadas mediante métricas. [GJ., 2005].


Innovación organizacional. Análisis y resolución de las causas.

Según Joaquín Gracia en [GJ., 2005] dice: “Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.”

1.4.2. Ventajas del modelo CMM – CMMI

Las ventajas de utilizar el modelo CMM –CMMI son: [HDAM., 2009].

Incremento de productividad de la organización.

Mejor comunicación con los clientes y entre profesionales de la organización.

Mayor satisfacción de las solicitudes de los clientes.

Ofrece un camino de mejora continua.

Permite a un interesado externo tener certeza sobre el potencial de una organización.

1.4.3. Desventajas del modelo CMM – CMMI

Las desventajas de utilizar el modelo CMM – CMMI son: [HDAM., 2009].

Su implementación en las empresas toma tiempo.

Su aplicación resulta compleja.

Luego de haber introducido un poco más el concepto y el funcionamiento del modelo CMM – CMMI, se puede observar la importancia de la estimación no solo para el nivel 2 ó gestionado sino para los niveles de madurez 3, 4 y 5. Pues la estimación es un factor crucial para cada uno de los niveles mencionados anteriormente, debido a que si no se realiza la estimación no se tendrían los resultados esperados al finalizar un proyecto de desarrollo, y por ende no se podría avanzar hacia los siguientes niveles de madurez

24

del modelo CMM – CMMI. El modelo CMM – CMMI se relaciona estrechamente con la estimación, ya que esta es una de las metas específicas para el área de planificación de proyectos del CMM –CMMI en el nivel 2, esto quiere decir que se deben determinar y documentar los estimados para cumplir con la planificación de proyectos de lo contrario no se cumpliría con el área de planificación de proyectos y esto conllevaría a no alcanzar los niveles del modelo CMM –CMMI. A continuación se hará una breve descripción de los métodos más conocidos para el desarrollo de las estimaciones en los proyectos de software:

1.4.4. Métodos basados en Modelos

1.5.1.1. PRICE – S

Este modelo fue creado por Frank Freiman y fue lanzado al mercado en el año de 1977 como la primera herramienta de estimación de costes de software en los Estados Unidos [JC., 2008]. El modelo PRICE – S fue desarrollado en Radio Corporation of América (RCA) para su propio uso. Posteriormente fue lanzada para uso público.

Las ecuaciones de este modelo no se hicieron públicas, sin embargo, algunos de los algoritmos fundamentales del modelo fueron publicados. [Anónimo1., n.d.].

El modelo PRICE – S se compone de tres submodelos. Estos submodelos son [Anónimo1., n.d.]:

Submodelo de adquisición: Este submodelo predice los costos y

plazos de un proyecto de desarrollo.

Submodelo de tamaño: Este submodelo se encarga de hacer la estimación del tamaño de un proyecto de desarrollo.

Submodelo de costo del ciclo de vida: este submodelo se utiliza para estimar el costo de mantenimiento de una aplicación.

Ventajas de PRICE – S

Realiza estimaciones precisas Potente funcionalidad.

25

Fácil de usar. Desventajas de PRICE – S

Difícil de predecir en cuanto aumenta la complejidad

de una aplicación.

1.5.1.2. Módelo Slim (Software Lifecycle Management)

Es un modelo de estimación de costos para proyectos de software muy grandes, desarrollado por el señor Lawrence H. Putnam en el año de 1978. Este modelo asume que el esfuerzo para proyectos de desarrollo de software se distribuye de manera similar a un conjunto de curvas, como se muestra que en la figura 2 “curvas de Rayleigh”, donde para cada actividad de desarrollo se asignada una curva [Anónimo., n.d.]. Estas curvas describen que entre más grande o complejo sea el proyecto más es la necesidad de personal para el desarrollo del mismo.

Figura 2. Curvas de Rayleigh

El señor Putnam se basó en la formula básica de la curva de Rayleigh y en sus experiencias sobre la productividad para desarrollar la ecuación del modelo SLIM. La ecuación es la siguiente:

26

Donde T = Tamaño en líneas de código. C= Factor de tecnología que depende del entorno de desarrollo, donde: El entornos de desarrollo pobres vale 2000 El entornos de desarrollo buenos vale 8000 El entornos de desarrollo excelentes vale 11000 K = Esfuerzo total de personas –mes Td = Tiempo para culminar el proyecto. Se mide en años. El modelo SLIM es un modelo empírico, que necesita de la información del tamaño y esfuerzo del software, suministrada por el usuario.

Ventajas del modelo SLIM

Es uno de los métodos que presenta mayor exactitud frente a otros métodos como PRICE – S, CHECKPOINT y SEER.

Es uno de los pocos modelos de estimación que tiene

presente la incertidumbre dentro de sus cálculos.

Desventaja del modelo SLIM

Para ser un modelo comercial no está muy bien documentado.

No es apto para proyectos pequeños.

Las estimaciones son muy sensibles a factores de

tecnología.

27

1.5.1.3. Módelo SEER (System Evaluation and Estimation of

Resources)

El modelo SEER es un modelo basado en el modelo Jensen creado en 1979 por el Dr. Randall Jensen en Hughes Aircraft Co. [SEI., 2010]. El modelo SEER fue publicado bajo el modelo de Jensen en el año de 1983 y patentado por Galorath Associates Inc. [Aemes1., 2010]. El objetivo de este modelo es cubrir todas las fases del ciclo de vida de un proyecto de desarrollo (Especificaciones, Diseño, Desarrollo, Entrega y Mantenimiento). Este modelo tiene aplicabilidad en diferentes tipos de desarrollo (OO, reutilización, desarrollo en espiral, en cascada, prototipo, incremental), diferentes tipos de lenguajes (C++, Cobol, Fortran, Ada, etc) y diferentes tipos de aplicaciones (cliente-servidor, distribuido, gráficos, etc.) [Aemes1., 2010]. Para ser más específicos el modelo SEER nos ayuda a saber: El tiempo y esfuerzo de un proyecto de desarrollo. El tamaño de un proyecto de desarrollo. La calidad del producto final (Software). La productividad de los desarrolladores. Según Aemes Ti en [Aemes1., 2010] dice “Las ecuaciones del modelo no han sido desarrolladas para el dominio público, aunque el algoritmo principal fue publicado por Jensen”. Dicho algoritmo se muestra en [SEI., 2010].

Ventajas del modelo SEER

Su estimación se basa en conocimiento de proyectos anteriores.

Puede ser aplicado en diferentes entornos de trabajo.

Desventajas del modelo SEER

Poca documentación.

28

1.5.1.4. COCOMO 81

Este modelo fue desarrollado por el señor Barry Boehm en el año de 1981. Este modelo conocido como Constructive Cost Model es el resultado de un análisis de 63 proyectos de software. El modelo COCOMO 81 considera que el desarrollo de software se realiza en proceso de cascada y se basa en una jerarquía de niveles de estimación de costos, compuestos de la siguiente manera [UKSS., 1998]: Nivel Básico: Calcula el esfuerzo de un proyecto de desarrollo con

base al tamaño del mismo, reflejado en líneas de código. Nivel Intermedio: Así, como en el caso anterior, se calcula el esfuerzo de un proyecto de desarrollo, pero no solo con base al tamaño, sino también con base en un conjunto de factores de costo, que incluyen evaluación subjetiva de los productos, equipos, personal y atributos del proyecto. Nivel Avanzado: En este nivel se tiene todas las características del nivel intermedio con la diferencia de que aquí se lleva a cabo una evaluación de impacto de los factores de costo para cada etapa del proyecto de desarrollo (Análisis, diseño, implementación, pruebas, etc.) El modelo COCOMO 81 fue definido para poder ser utilizado en 3 tipos de proyectos de software (Acoplados, semiacoplados y empotrados). A continuación se explica cada uno de ellos [UKSS., 1998]: Acoplado: Es para proyectos que no tiene mayor complejidad, donde no se trabaja con un número muy elevado de personas. Semiacoplado: Es para proyectos donde los proyectos de software son un poco más complejos y de mayor tamaño. Aquí se necesitan personas con buenos conocimientos y experiencias. Empotrado: Es para proyectos complejos donde los proyectos a desarrollar son proyectos robustos que necesitan de hardware, software y procedimientos.

29

Boehm, extrae 15 factores del costo de una lista de más de 100 de ellos. Con estos atributos se ajusta el costo nominal del proyecto al entorno real, de esta manera se incrementa la precisión de la estimación. Estos atributos se agrupan en cuatro categorías: atributos del software, atributos del hardware, atributos del personal y atributos del proyecto [WIKI., 2011]. Atributos del software:

RELY: Garantía de funcionamiento requerida al software. DATA: Tamaño de la base de datos. CPLX: Complejidad del producto.

Atributos del hardware:

TIME: Restricción del tiempo de ejecución. STOR: Restricción del almacenamiento principal. VIRT: Volatilidad de la maquina virtual. TURN: Tiempo de respuesta del ordenador.

Atributos del personal:

ACAP: Capacidad del analista. AEXP: Experiencia en la aplicación. PCAP: Capacidad del programador. VEXP: Experiencia en maquina virtual. LEXP: Experiencia en lenguaje de programación.

Atributos del proyecto:

MODP: Practicas de programación moderna. TOOL: Utilización de herramientas de software. SCED: Plan de desarrollo requerido.

Ventajas de COCOMO 81

A diferencia de otros modelos como SLIM, COCOMO permite ver como es su funcionamiento.

Los factores de costo ayudan al estimador a saber

en qué parte del proyecto aumentan más los costos.

Desventajas de COCOMO 81

Depende mucho de los datos históricos de la organización, datos que no siempre están disponibles.

30

No se puede asumir que el modelo sea válido para todos los entornos de desarrollo.

El éxito de la estimación depende mucho del modo de

desarrollo que se vaya a utilizar.

1.5.1.5. Módelo ESTIMACS

Este modelo fue desarrollado por el Dr. Howard Rubín en el año de 1985. Es un modelo de macro estimación que tiene como característica principal el uso de puntos de función en vez del uso de las líneas de código como medición del tamaño, sin embargo, así como en el modelo SEER los detalles internos del modelo no están disponibles. Este modelo cuenta con un total de 25 preguntas que son divididas en 6 grupos, y que luego de ser respondidas son ingresadas al modelo con el fin de obtener la estimación [RP., 1990]. Los grupos con sus respectivas preguntas son [RP., 1990]:

Variables de tamaño: Número de subsistemas importantes. Número de entradas externas lógicas al sistema. Número de salidas lógicas desde el sistema. Número de base de datos lógicas internas. Número de categorías de investigación.

Variables de productos:

Tipos de sistema. Detección de errores y corrección de requisitos. Complejidad. Copias de respaldo y recuperación de requisitos. Rigurosidad en el rendimiento de los requisitos. Rigurosidad en la fiabilidad de los requisitos.

Variables de entorno:

Modo de desarrollo. Requisitos de telecomunicación. Procesamiento distribuido.

Variables de personal:

Familiaridad con el tipo de aplicación Reubicación

31

Variables del proyecto: Viaje (Cambios en el proyecto) Volatilidad de los requisitos.

Factores de usuario:

Número de usuarios involucrados en la organización. Número de usuarios. Porcentaje de participación de los usuarios. Conocimientos del usuario en programación dinámica (DP). Luego de que son recolectadas todas las preguntas y son ingresadas al modelo se puede obtener información como:

Esfuerzo en horas, Duración meses – calendario. Desglose del trabajo a nivel de empleados y costos. Conteo de puntos de función. Esfuerzo de mantenimiento. Evaluación de riesgos. Información financiera.

Ventajas del modelo ESTIMACS.

Fácil de usar. Muy Objetivo. La experiencia de proyectos anteriores resulta útil en

un nuevo proyecto.

Desventajas del modelo ESTIMACS.

Solo es útil en aplicaciones de programación dinámica.

Calibrar o medir con base en experiencias anteriores puede ser una desventaja si el proyecto actual cambia.

32

1.5.2. Métodos basados en expertos

1.5.2.1. Juicio de expertos

Este tipo de métodos suelen ser muy útiles cuando en las empresas no se tiene información empírica cuantitativa. En ese caso se utiliza el conocimiento de personas con experiencia en desarrollo de proyectos de la misma naturaleza. Se considera que es un tipo de estimación subjetiva, debido a que depende de las experiencias adquiridas en proyectos anteriores. Entre los métodos más conocidos de la estimación basada en expertos se encuentra:

1.5.2.1.1. DELPHI: Este método fue desarrollada por la RAND Corporation (Research and Development), en el año de 1940. El método DELPHI se basa en la recopilación de un conjunto de información obtenida a través de una colección de cuestionarios repartidos de forma sucesiva a un grupo de personas llamadas expertos. En estos cuestionarios se realizan preguntas sobre acontecimientos futuros relacionados al tema de estudio. [Anónimo1., n.d.]. Luego de obtener la información, es estudiada muy minuciosamente con el fin de sacar conclusiones que ayuden a la estimación de un proyecto. Ventajas de DELPHI

La información recolectada es basada en la opinión de un grupo de experto y no en la de uno solo.

Conveniente cuando la información que se va a recolectar, necesita la opinión de varios puntos de vista. Desventajas de DELPHI

La experiencia no es garantía para emitir juicios acertados.

En últimas es costoso debido al número de reuniones.

Depende mucho de las experiencias de un grupo de expertos.

33

1.5.2.1.2. WBS (Work Breakdown Structure):

Este método fue desarrollado por el departamento de defensa estadounidense en el año de 1960, para la planificación de proyectos de la defensa nacional. El método WBS también conocido como “desglose de trabajo”, se basa en la descomposición global de un proyecto en manera jerárquica, para ser tratados como subproyectos donde cada uno forma parte del proyecto global. Esto con el fin de poder facilitar la asignación de recursos, control y tiempo [SLPF., 2006]. Este método trabaja bajo la estrategia de “divide y vencerás”, donde entre mas desglosado este el proyecto más acertadas serán las estimaciones. Un factor a tener en cuenta con este método es que la estimación tal vez no corresponda a la suma total del estimado de cada subproyecto, debido a que se tiene que tener en cuenta el tiempo y esfuerzo para la integración del mismo [SLPF., 2006]. Ventajas de WBS

Se puede aplicar a proyectos específicos. Permite llevar procesos bien documentados.

Desventajas de WBS

Depende mucho de la experiencia de los expertos. Los expertos suelen dar estimaciones en el mejor de los casos.

1.5.2.1.3. Sistemas basados en reglas (SBR)

Los sistemas basados en reglas funcionan bajo una base de conocimientos donde se almacenan datos (hechos o evidencias) y conocimientos (reglas) que administran las relaciones entre esos datos. Para obtener conclusiones o nuevos datos los sistemas basados en reglas usan motores de inferencia que incorpora estrategias y reglas diseñadas por un experto [SLPF., 2006]. Para entender cómo funcionan los sistemas basados en reglas, supongamos que existe un banco que realiza préstamos a sus clientes dependiendo de que se cumplan un conjunto de reglas, por ejemplo:

34

Datos Valores Posibles

Edad 18…..60

Salario 1 = 1 salario mínimo 2 = 2 salarios mínimos

Estrato 1, 2, 3, 4, 5

Préstamo 500.000 – 60.000.000

Aceptado Si/No

Tabla 2. Ejemplo de los sistemas basados en expertos.

Si Edad > 50 y Salario = 1 y Estrato < 3 y Préstamo = 4.000.000; Aceptado = No.

Si Edad <40 y Salario = 2 y Estrato > 3 y Préstamo = 2.000.000; Aceptado = Si. Entonces, si el cliente cumple con el conjunto de reglas, el banco le realiza el préstamo, en el caso contrario no se le realiza. Ventajas de los SBR

A partir de nuevos hechos se pueden obtener nuevas conclusiones (Desarrollo incremental).

Fácil manipulación.

Se pueden añadir, modificar o eliminar nuevas reglas. Desventajas de los SBR

Difícil de analizar acciones que van a ocurrir debido a que no se tiene una visión global.

Rápido crecimiento del número de reglas.

Difícil cubrir todo un conjunto de reglas.

35

1.5.3. Otros Métodos de Estimación

1.5.3.1. Método de Puntos de Función (FP)

Este método fue desarrollado por el señor Allan J. Albrecht y publicado por primera vez en el año de 1979. Este método es muy útil ya que se puede utilizar en cualquier etapa de un proyecto de desarrollo y es independiente de la tecnología que se utilice. Lo que busca el método de puntos de función es medir el tamaño de una aplicación con base a su funcionalidad.

El método de puntos de función desarrollado por Allan Albrecht mide el tamaño de la aplicación a partir de 5 componentes funcionales (Entradas Externas, Salidas Externas, Consultas Externas, Archivos Internos Lógicos y Archivos de interface externa). Luego de identificar cada uno de estos 5 componentes funcionales el paso a seguir es asignar el peso (la complejidad). Este peso depende de 3 elementos funcionales conocidos como Det,s (Tipos de elementos de datos), Ret,s (Tipos de elementos de registro) y Ftr,s (Tipos de archivos referenciados) . Después de asignar el peso se hace la suma total de cada uno de los componentes funcionales, esta suma total corresponde al total de puntos de función sin ajustar. Para hallar el total de puntos de función ajustados hay que calcular 14 puntos conocidos como “características generales del sistema (GSC)”. Estas características tiene que ver con el ambiente en que la aplicación va a ser desarrollada, lo que se considera como una desventaja debido a que no siempre se va a tener el mismo criterio a la hora de hacer la estimación. Luego de obtener el total de las “GCS”, procedemos a realizar el cálculo mediante la siguiente formula conocida como factor de ajuste: FA = 0,65 + (0,01 * TS-GCS) Donde: FA: Factor de ajuste TS-GCS: Total suma características generales del sistema. Luego de obtener el valor del factor de ajuste el siguiente paso es realizar el cálculo final del total de puntos de función, el cual se obtiene de la siguiente forma: PFA=PFSA * FA

36

Donde: PFA: Puntos de función ajustados. PFSA: Puntos de función sin ajustar. FA: Factor de ajuste. Ventajas de los puntos de función Es independiente de la tecnología. Se puede usar en cualquier fase del ciclo de vida de un proyecto de software. Es un método que está muy bien documentado. Mide lo que el usuario pide y lo que el usuario recibe. Existe una gran cantidad de datos históricos. Desventajas de los puntos de función

Sin datos históricos, es difícil mejorar las habilidades de estimación. Los puntos función no reflejan diferencias entre lenguajes, diseños o estilos. El factor de ajuste calculado a partir de las características generales del sistema resulta de dudosa utilidad. Carece de precisión cuando se realiza en proyectos pequeños, con menos de 100 puntos de función. Luego de que fuera publicado el método de puntos de función surgieron nuevas variantes procedentes del método original de Albrecht. A continuación se hará una breve descripción de cada una de estas variantes:

37

Puntos de características (Feature Points): Método propuesta por Capers Jones en el año de 1986. Según Juan Grompone en [GJ., 1996], “Los Feature Points son una extensión, no compatible en la teoría, de los Puntos Funcionales”. Esto se debe a que el método de Feature Points consiste en agregar una sexta funcionalidad (Complejidad de los algoritmos) que este a expensas de las otras cinco funcionalidades (Entradas Externas, Salidas Externas, Consultas Externas, Archivos Internos Lógicos y Archivos de interfaces externas), de lo contrario no existiría compatibilidad. Pero ¿como sabemos cuándo utilizar puntos de función y cuando utilizar puntos de características? El criterio para saber cual elegir es con base a la aplicación que se está desarrollando, por ejemplo: si la aplicación que se está desarrollando tiene un gran número de algoritmos, el método adecuado para medir su tamaño funcional es el de puntos de características. Si por el contrario el sistema que se desarrolla tiene pocos algoritmos y un gran número de entradas, salidas, consultas y ficheros lógicos, el método más adecuado es el método de puntos de función. [SRF., 1999]. IFPUG: El método de IFPUG se basa en el método de puntos de función de Albrecht publicado en el año de 1979. En el año de 1986, se crea el IFPUG (Grupo Internacional de Usuarios de Puntos de Función). Luego de que fueran publicadas varias versiones, en el año 2003, año en el que publicaron el manual IFPUG 4.1 fue reconocido como un estándar internacional por medio de la ISO/IEC 20926. Posteriormente a la publicación IFPUG 4.1, han surgido nuevas versiones como IFPUG 4.2 e IFPUG 4.3 esta ultima publicada el 1 de Enero de 2010 [IFPUG., 2010]. Hay que aclarar que este método no cuenta con la parte del factor de ajuste (VAF), debido a que no cumple con las condiciones exigidas por la ISO/IEC 14143-1 [CFN, 2006]. Esta última es la encargada de definir los conceptos fundamentales para las medidas del tamaño funcional.

38

Mk II FPA: Método propuesto por Charles Symons en el año de 1988. La principal diferencia en contraste al método de puntos de función es que el sistema se toma como un conjunto de funcionalidades conocidas como transacciones lógicas, donde cada transacción es un grupo formado por tres tipos de componentes (Entradas, Salidas y Procesos). Otra de las diferencias con respecto al método desarrollado por Albrecht, es que se le agregan otras 5 características generales del sistema, a parte de las 14 ya conocidas en el método de Albrecht y se pueden agregar mas según se considere necesario [SC., 1988]. MKII FPA es mantenida por la Asociación de Métricas (UKSMA) del Reino Unido. NESMA-FPA: Organización fundada en el año de 1989 con el nombre de NEFPUG Netherlands Function Point Users Group). Una de las primeras organizaciones en el mundo, en difundir y usar el método de puntos de función. Actualmente cuenta con más de 120 miembros (empresas) y es el mayor grupo de usuarios FPA en Europa. [Aemes., 2010]. Según La Asociación Española para la Gobernanza, la Gestión y la Medición de las Tecnologías de la Información en [Aemes., 2010] “NESMA mantiene su propio Manual de Prácticas de Conteo mediante FPA, que es compatible, y complementario, con el IFPUG CPM 4.2. Además de esto, NESMA mantiene varios libros y manuales sobre otras métricas de software”. NESMA e IFPUG (Grupo Internacional de Usuarios de Puntos de Función) identifican los mismos cinco componentes funcionales con la única diferencia de que la denominación no es la misma [BD., 2008]: Archivo lógico interno (ILF) en IFPUG = Dato interno lógico (ILGV) en NESMA. Archivo de interface externa (EIF) en IFPUG = Enlace de datos (KGV) en NESMA. Salida externa (EO) en IFPUG = Función de salida (UF) en NESMA. Entrada externa (EI) en IFPUG = Función de entrada (IF) en NESMA. Consulta externa (EQ) en IFPUG = Función de consulta (OF) en NESMA.

39

Otra de las diferencias con respecto a el método de IFPUG, es que existen unas cuantas excepciones para determinar el tipo y complejidad de las funciones, por ejemplo, para determinar la complejidad de una consulta externa (EQ) NESMA propone que la complejidad funcional de la parte de entrada se basa en las reglas de complejidad de las entradas externas (EI) y la complejidad funcional de la parte de salida se basa en las reglas de complejidad de las salidas externas (EO). Luego el valor más elevado de los dos determina la complejidad de la consulta externa. [BD., 2008]. 3D Function Point: Este método fue desarrollado por el señor Scott Whitmire en el año de 1992. El objetivo de este método era mejorar dos problemas clásicos del método original de Albrecth. El primero es que se consideraba difícil de usar, y en segundo es que no median adecuadamente los sistemas en tiempo real [SRF., 1999]. El término 3D se debe a que hace referencia a tres dimensiones (Datos, Funciones y Control). A simple vista el método de 3D function Point aparenta ser más viable que el método original de Albrecht pero la verdad es que este método necesita de mayor información, según Faustino Sánchez en [SRF., 1999] “sobre todo la relacionada con la complejidad de algoritmos que se van a implementar y a las posibles transiciones y estados acerca del sistema a implementar”, información que no siempre está disponible al inicio de un proyecto de software. COSMIC-FFP: En el año de 1997 un grupo de la universidad de Québec en Montréal [Abran A., et al.98], desarrollaron un método conocido como Full Function Points (FFP). Lo que se buscaba con este método era que permitiera calcular el tamaño funcional en las aplicaciones de tiempo real y embebido. Particularmente, los sistemas de tiempo real tienen 2 factores críticos: el primero, es el tiempo de respuesta y el segundo es la interacción con entidades externas [OJD., 2006]. En el año de 1999 el Consorcio Internacional Común de Medidas de Software, dirigidos por Alan Abran y Charles Symons, se inspiran en el método original de Full Function Points de St-Pierre et al, y publican la versión 2.0 del manual de medición COSMIC-FFP.

40

El modelo general de software COSMIC-FFP, parte de los requerimientos funcionales entregados por el usuario, que luego son implementados por un conjunto de procesos funcionales. Cada uno de estos procesos funcionales es conocido como un subproceso que realiza movimientos de datos. El método COSMIC-FFP distingue 4 tipos de movimientos de datos conocidos como [OJD., 2006]: Entradas: Datos transferidos desde el usuario hacia adentro de la aplicación. Salidas: Datos Transferidos desde el interior de la aplicación hacia el usuario. Lectura: Datos transferidos desde (trae datos) los sistemas de almacenaje. Escritura: Datos transferidos hacia (envía datos) los sistemas de almacenaje. En la figura 3 se muestra la evolución de los métodos desarrollados con base en el método origina desarrollado por Albrecht:

Figura 3. Evolución métodos basados en puntos de función.

41

1.5.3.2. Estimación basada en líneas de código (LOC)

La estimación basada en líneas de código (LOC) ha sido por muchos años uno de los métodos más utilizados para estimar el cálculo del tamaño total de un proyecto de software. La estimación basada en LOC parece ser sencilla a simple vista, sin embargo, al momento de realizar el conteo del número total de líneas de código para un proyecto de desarrollo hay que tener en cuenta factores como el lenguaje en el cual se está desarrollando la aplicación y saber diferenciar entre lo que es una línea de código y lo que es un comentario o una línea en blanco. Existen dos tipos de medidas de LOC conocidas como [GA., et al. 2008]: LOC FÍSICAS: Este tipo de medida comprende el número total de

líneas de código y los comentarios. Las líneas en blanco también son comprendidas pero bajo la siguiente condición: Si el número de líneas en blanco es inferior al 25% del total de una sección o del proyecto de desarrollo, se incluye. En el caso contrario no se incluye, es decir, si supera al 25% del total de una sección o del proyecto de desarrollo, no incluye [GA., et al. 2008]. LOC LÓGICAS: Este tipo de medida comprende el número de declaraciones en el código fuente. En este tipo de medida se debe tener en cuenta que las declaraciones dependen del lenguaje de desarrollo que se esté utilizando [GA., et al. 2008]. Ventajas de la estimación basada en LOC Fácil usabilidad Los datos históricos de muchas organizaciones se encuentran en términos de líneas de código.

Muchas herramientas de estimación utilizan las LOC como base para calcular sus costos, tiempos, etc. Desventajas de la estimación basada en LOC

Depende de la tecnología que se utilice. Solo se conoce el total de líneas de código al culminar un proyecto de desarrollo.

42

1.5.3.3. Puntos de casos de uso (UCP)

Este método fue desarrollado por el señor Gustav Karner en el año de 1993. Se trata de un método para la estimación del tamaño basado en el método original de Albrecht “Puntos de Función” [VOS., n.d.]. Este método utiliza tanto los casos de uso como los actores para determinar el esfuerzo que tomará desarrollar el total de casos de uso. Para ello a los casos de uso se les asigna una complejidad que depende de las interacciones entre el usuario y el sistema y a los actores se les asigna una complejidad que depende del tipo (si es un usuario u otro sistema). También se tiene en cuenta factores ambientales y técnicos para el ajuste total de los puntos de casos de uso [VOS., n.d.]. A continuación se hará una breve descripción de las formulas que utiliza el método de puntos de casos de uso para calcular el tamaño de un proyecto de desarrollo: Fórmula para calcular los “UCP” sin ajustar: UUCP = UAW + UUCW

Donde: UUCP = Puntos de casos de uso sin ajustar. UAW = Factor de peso de los actores sin ajustar. UUCW = Factor de peso de los casos de uso sin ajustar. Fórmula para calcular los UCP ajustados: UCP = UUCP x TCF x EF Donde: UCP = Puntos de casos de uso ajustados. UUCP = Puntos de casos de uso sin ajustar. TCF = Factores técnicos EF = Factores ambientales.

43

Nota: Para encontrar el valor y realizar el cálculo de todos los factores que intervienen (UAW, UUCW, TCF y EF), el método de “UCP” define unas tablas y unas formulas ya establecidas, que no se explican debido a que no hacen parte del estudio principal de este proyecto. Ventajas de UCP Fácil adaptación a las empresas que utilizan los casos de uso. Se ajusta en cualquier tipo de proyecto. Es independiente de la tecnología. Desventajas de UCP Depende de la especificación inicial que se haga de los casos de uso. La estimación obtenida por este método solo aplica para la parte de codificación del proyecto.

1.5.3.4. COCOMO II

El modelo COCOMO II se utiliza para estimar el costo, tiempo y esfuerzo que toma desarrollar un proyecto de software. Este modelo publicado por primera vez en el año de 1997, surge como una mejora del modelo anterior COCOMO 81, luego de que las empresas dedicadas a desarrollar productos de software, cambiaran con el pasar de los años sus estrategias y conceptos para desarrollar. Por ejemplo, el modelo COCOMO 81 considera que el desarrollo de software se realiza en proceso de cascada, donde, cada etapa debe finalizarse para poder seguir con la siguiente y poder corregir errores en una etapa anterior, aumentando así los costos de desarrollo. En contraste al modelo COCOMO 81, el modelo COCOMO II está asociado a ciclos de vida modernos, donde se tiene en cuenta factores esenciales como la planificación de sistemas. Otro de los cambios que sufrió el modelo COCOMO 81 respecto al modelo COCOMO II, es que la clasificación de los proyectos pasó de ser acoplado, semiacoplado y empotrado ha cinco factores de escala conocidos como [MA., n.d.]:

44

PREC: Precedencia. FLEX: Flexibilidad de desarrollo. RESL: Resolución de Arquitectura. TEAM: Cohesión del equipo. PMAT: Madurez del proceso.

Para el modelo COCOMO II se agregan 2 manejadores de costos con respecto a los 15 del modelo COCOMO 81 y se modifican algunos otros. Los 17 manejadores de costo incluidos en el modelo COCOMO II son: RELY: Fiabilidad. DATA: Tamaño Base de datos. CPLX: Complejidad. RUSE: Reutilización requerida. DOCU: Documentación. TIME: Restricción tiempo de ejecución. STOR: Restricción de almacenamiento principal. PVOL: Volatilidad plataforma. ACAP: Capacidad del analista. PCAP: Capacidad programador. AEXP: Experiencia aplicaciones. PEXP: Experiencia plataforma. LTEX: Experiencia lenguaje y herramienta. PCON: Continuidad del personal. TOOL: Uso de herramientas software. SITE: Desarrollo Multi-lugar. SCED: Planificación requerida.

Con el fin de apoyar las necesidades expresadas por los estimadores de proyectos de software, tales como, planificación de proyectos, la previsión de personal de proyecto, re – planificación, seguimiento, negociaciones de contrato o la evaluación del diseño, entre otras, el modelo COCOMO II proporciona 3 modelos conocidos como [MA., n.d.]: Modelo de composición de aplicaciones: Este modelo es

utilizado para estimar el tiempo, costo y esfuerzo para proyectos construidos con herramientas de interfaces graficas de usuario. Modelo de diseño anticipado: Este modelo se utiliza para

estimar el coste de un proyecto de software en etapas iniciales, aun cuando no se tiene definido completamente la arquitectura del

45

mismo. Este modelo está basado en los puntos de función sin ajustar ó en las miles de líneas de código fuente (KSLOC). Modelo de post – arquitectura: Este es el modelo más

completo y detallado, creado por COCOMO II. Este modelo se utiliza cuando ya se ha desarrollado por completo la fase de diseño, la arquitectura del proyecto se encuentra bien definida y se tiene bien detallada la información del mismo. Ventajas de COCOMO II Se adapta fácilmente en cualquier etapa de proceso de desarrollo. Altamente soportados por la industria. Tiene en cuenta varios factores para la estimación del costo. Está bien documentado. Desventajas de COCOMO II

No es recomendable para proyectos pequeños. Difícil de adaptar en empresas que no cuentan con personal asignado a la estimación. Existen factores que de no ser ingresados por un estimador experto, se perdería la fiabilidad de la estimación.

1.5.3.5. Estimación por analogía

Este método suele ser útil cuando se tiene información de proyectos anteriores que sean similares al proyecto que se desea estimar. La información para realizar la nueva estimación puede ser obtenida de los proyectos anteriores que se hayan realizado dentro de la misma organización o bien con proyectos realizados fuera de la organización, aunque se obtienen mejores resultados con la información de los proyectos internos de la organización. Para realizar la estimación por analogía se compara la información entre los proyectos anteriores y el nuevo proyecto con el fin de extraer conclusiones que ayuden a estimar el costo de un nuevo proyecto [SLPF., 2006].

46

Ventajas de la estimación por analogía.

Se basa en la experiencia real de proyectos anteriores. Bastante preciso cuando se tienen proyectos similares. Si se cuenta con un buen número de proyectos similares al objeto de estudio se tendrá una mejor estimación. Desventajas de la estimación por analogía. Depende del conocimiento de proyectos anteriores. Difícil conocer el grado de similitud del nuevo proyecto con proyectos anteriores. No todas las organizaciones cuentan con proyectos similares al proyecto que se va a estimar.

47

1.6. Resumen comparativo de los modelos y métodos.

Con el fin de presentar un resumen donde se analizan algunos de los modelos y métodos antes descritos, se presenta la siguiente tabla comparativa:

CLASIFICACIÓN MÉTODOS

DESCRIPCIÓN VENTAJAS DESVENTAJAS

Métodos basados en

modelos

Price - s Comercializado en 1977 como la primera herramienta para la estimación de costos de un proyecto de software. Este modelo se compone de tres submodelos (submodelo de adquisición, submodelo de tamaño y submodelo del ciclo de vida).

- Tiene presente factores de incertidumbre para la realización de sus cálculos

- No es adaptable a proyectos poco complejos. - Sensible a factores tecnológicos.

Slim Modelo de estimación de costes para proyectos de software. Este método está basado en el análisis del ciclo de vida de las “curvas de Rayleigh” donde se describe la necesidad de más personal a medida que crece un proyecto de desarrollo.

- Realiza estimaciones precisas. - Potente funcionalidad.

- Difícil predecir cuando aumenta la complejidad de un proyecto de software.

Cocomo 81

Modelo que utiliza manejadores de coste como medida para estimar proyectos de software. Este modelo se basa en que los procesos de desarrollo se hacen en cascada y está diseñado para funcionar en 3 tipos de proyectos de software (Acoplados, semiacoplados y empotrados).

- Los manejadores de coste ayudan a descifrar en qué fase aumentan mas los costos

- Dependiente del modelo de desarrollo que se utiliza.

Métodos basados en

expertos

Delphi Este método se basa en la información obtenida a través de unos cuestionarios resueltos por un grupo de expertos. Esta información es recopilada y analizada para tomar conclusiones que ayuden a la estimación de un proyecto.

- La información recopilada de acuerdo a diferentes puntos de vista permite valorar diferentes alternativas. La información que se obtiene es con base a la opinión de varios expertos

- La experiencia no es garantía para emitir juicios acertados. - Depende de la experiencia de un grupo de personas.

WBS Este método funciona bajo la estrategia de divide y vencerás, donde entre mas desglosado se encuentre más fácil será trabajar y obtener estimaciones reales.

- Permite llevar procesos bien documentados.

- Depende de la experiencia de expertos. - Se suelen dar

48

Tabla 3. Cuadro comparativo métodos de estimación.

estimaciones siempre desde el punto de vista optimista.

Basado en reglas

Este método funciona bajo una base de conocimientos donde se almacenan datos y reglas. Las conclusiones se obtienen por medio de un motor de inferencia que funciona mientras se cumpla una condición.

- Permite el desarrollo incremental. Fácil manipulación.

- Difícil cubrir todo un conjunto de reglas.

Otros Métodos

Puntos de función

Método para estimar el tamaño de un proyecto de software basado en la funcionalidad del sistema. Para realizar la estimación utiliza 5 componentes funcionales y se clasifican dependiendo de su complejidad. También se incluyen 14 factores de entorno que afectan el desarrollo de un proyecto de software.

- Es independiente de la tecnología. - Se puede utilizar en cualquier etapa de un proyecto de desarrollo.

- No es recomendable para proyectos con menos de 100 PF.

- Sin datos históricos,

es difícil mejorar las

habilidades de

estimación.

Líneas de código

Método para estimar el tamaño de un proyecto de software basado en el conteo total de líneas de código del mismo.

- Los datos históricos de muchas organizaciones se encuentran en términos de líneas de código.

- Depende de la tecnología que se utilice. - No se recomienda en etapas iniciales de un proyecto de software.

Puntos de casos de

uso

Método para estimar el tamaño de un proyecto de software basado en los puntos de función Albrecht. Este método utiliza los casos de uso y los actores para determinar el esfuerzo que toma desarrollar el total de casos de uso de un proyecto de software

- Se adapta fácil a las empresas que utilizan casos de uso. - Independiente de la tecnología.

- Depende del levantamiento inicial de los casos de uso. - La estimación solo aplica para la fase de codificación.

Cocomo II Modelo para estimar el costo, tiempo y esfuerzo de un proyecto de software. Se basa en los procesos de desarrollo en espiral y utiliza 3 tipos de modelos (composición de aplicaciones, diseño anticipado y post – arquitectura) para ayudar a satisfacer las necesidades de los estimadores.

- Adaptable en cualquier etapa de un proyecto de software. - Utiliza 17 manejadores de coste que ayudan a ser mas real la estimación del costo de un proyecto de software.

- Depende del conocimiento de proyectos anteriores - Resulta complejo utilizarlo si no se tiene el personal adecuado para realizar la estimación.

49

2. LA ESTIMACIÓN DEL TAMAÑO BASADA EN PUNTOS DE FUNCIÓN

La estimación basada en el método de puntos de función ha sido por muchos años una de las técnicas más usadas por la industria del software para calcular el tamaño de un proyecto de desarrollo. El método de puntos de función se encarga de medir una aplicación desde una perspectiva del usuario, dejando de lado detalles como la codificación y de esta manera se hace útil en cualquier etapa del ciclo de vida del software, desde la formulación hasta la implantación. Según Capers Jones en [JC., 2008] dice que “La métrica de puntos de función ha sido aplicada en más de 250 lenguajes de programación diferentes”.

A continuación se explica de forma detallada el esquema del método de puntos de función:

2.1. Esquema del método de puntos de función

El proceso para llevar a cabo el cálculo total de los puntos de función se compone básicamente en 2 secciones (puntos de función sin ajustar y puntos de función ajustados) que se explicaran a continuación:

2.1.1. Paso 1: CALCULO DE LOS PUNTOS DE FUNCIÓN SIN AJUSTAR

Lo primero que se debe hacer cuando se realiza la estimación por el método de puntos de función es hallar el número de componentes funcionales que tiene la aplicación que se desea estimar, sin embargo, con el fin de comprender mejor este método se explica primero como se determina el peso (complejidad) de cada componente funcional:

2.1.1.1. Determinar el peso de cada componente funcional

Para determinar el peso de cada componente funcional es necesario identificar el número de elementos de datos de cada componente funcional. Los elementos de datos son [IFPUG., 1999]:

Recording Element Types (RET): Es un subgrupo de elementos de

datos que se encuentran dentro de un Archivo Lógico Interno o Archivos de Interfaz Externos.

File Referenced Type (FTR): Es un archivo lógico interno que es leído o

mantenido por una transacción (EQ, EO , EI).

50

Data Element Type (DET): Es un archivo no recursivo, los DET pueden invocar transacciones o puede facilitar información adicional respecto a las transacciones.

Nota: Todos los componentes se clasifican en función a los DET, y ya sea de RET o de FTR. La siguiente tabla muestra la complejidad correspondiente para cada uno.

Componentes funcionales RET,s FTR,s DET,s

Entradas externas

Salidas externas

Consultas externas

Archivos de interface externa

Archivos lógicos internos

Tabla 4. Complejidad para cada componente funcional

2.1.1.2. Hallar los componentes funcionales

El método de puntos de función calcula el tamaño de una aplicación basándose en la cantidad de funcionalidades de la misma, para ello, el señor Albrecht identificó 5 componentes funcionales que hacen parte de un proyecto de desarrollo. Los 5 componentes funcionales se dividen de la siguiente manera [IFPUG., 1999]:

Funciones transaccionales: son las funciones que un sistema le brinda al usuario con el fin de que este puede procesar datos. Los 3 componentes funcionales que se incluyen aquí son:

Entradas Externas (EI).

Salidas Externas (EO).

Consultas Externas (EQ).

Funciones de archivos: Son las funciones que un sistema le brinda al

usuario con el fin de satisfacer los requerimientos internos y externos que cruzan la frontera de la aplicación. Los 2 componentes funcionales que se incluyen aquí son:

Archivos Lógicos Internos (ILF).

Archivos de Interfaz Externos (EIF).

51

A continuación se explica cada uno de los componentes funcionales: La complejidad en las funciones transacciones se mide por la cantidad de DETs y FTRs que contenga el sistema. Entradas externas (EI): Son los datos que son ingresados por el usuario

al sistema sea para crear, borrar o modificar un archivo lógico interno [IFPUG., 1999].

Ejemplo: Un requerimiento que administre la información de los usuarios

del sistema, este requerimiento tiene 3 escenarios, crear usuarios, modificar usuarios, eliminar usuarios, siendo cada uno de estos una Entrada Externa.

Figura 4. Entradas externas En la figura 4 tomada de [LD., n.d.] de David Longstreet, se muestra una entrada que modifica 2 archivos lógicos internos.

Clasificación de complejidad.

FTR DET

1-4 5-15 MAS DE 15

MENOS DE 2 BAJO (3) BAJO(3) MEDIO(4) 2 BAJO(3) MEDIO(4) ALTO(6)

SUPERIOR A 2 MEDIO(4) ALTO(6) ALTO(6)

Tabla 5. Clasificación de complejidad para las entradas externas.

DET en entradas externas:

Campos de entrada de datos.

Mensajes de error.

Mensajes de confirmación.

Botones con funciones OK, NEXT.

52

FTR en entradas externas: cada archivo lógico interno que llegue de una entrada externa se cuenta como un FTR. Cualquier archivo lógico interno o archivo de interfaz externa que sean mantenidos por una entrada externa, es contada también como FTR.

Salidas externas (EO)

Son componentes donde intervienen entradas y salidas. Las salidas son mostradas desde la parte interna del sistema, y también pueden actualizar o modificar archivos lógicos internos. Las entradas pueden crear reportes de datos desde los archivos lógicos internos o archivos de interfaz externos. Se puede identificar una salida externa cuando uno o más datos son combinados por medio de una fórmula para generar nuevos datos de información [IFPUG., 1999]. Ejemplo: Un ejemplo claro seria un requerimiento llamado “generar reporte de horas trabajadas de un empleado”, donde el reporte tendrá la información de los días y horas trabajadas por el empleado, el actor dará un rango de fechas, y el sistema genera el reporte esto sería una Salida Externa.

Figura 5. Salidas externas. En la figura 5 tomada de [LD., n.d.] de David Longstreet, se puede ver una salida con datos simples y datos calculados de 2 archivos lógicos internos diferentes.

Clasificación de complejidad. FTR DET

1-5 6-19 MAS DE 19

MENOS DE 2 BAJO (4) BAJO(4) MEDIO(5) 2 a 3 BAJO(4) MEDIO(5) ALTO(7)

SUPERIOR A 3 MEDIO(5) ALTO(7) ALTO(7)

Tabla 6. Clasificación de complejidad para las salidas externas.

53

DET en salidas externas:

Mensajes de error.

Confirmación de mensajes.

Valores calculados.

Valores en reportes que son leídos desde archivos lógicos internos o archivos de interfaz externos.

FTR en salidas externas: puede actualizar un archivo lógico interno o un archivo de interfaz externa pero a diferencia de las entradas externas, no las mantiene es decir no hace crear, modificar, eliminar, por ejemplo al hacer un pago en línea, puede que haya una bandera que indique el pago se ha producido.

Consultas externas (EQ):

Son componentes donde intervienen entradas y salidas, pero donde las salidas con básicamente los mismos datos de los archivos lógicos internos [IFPUG., 1999]. Ejemplo: Un caso de uso llamado “consultar usuario por nombre”, donde

la interacción entre el usuario y el sistema da como resultado la búsqueda de la información y posteriormente mostrarla por el sistema.

Figura 6. Consultas externas

En la figura 6 tomada de [LD., n.d.] de David Longstreet, se muestra los datos extraídos de 2 archivos lógicos internos diferentes.

54

Calificación de complejidad. FTR DET

1-5 6-19 MAS DE 19


3 O MAS MEDIO(4) ALTO(6) ALTO(6)

Tabla 7. Clasificación de complejidad para las consultas externas.

DET en consultas externas:

Entrada.

Búsqueda de valores.

Botones de acción.

Mensajes de confirmación de búsqueda.

Mensajes de error.

Salida.

Valores leídos de los archivos internos lógicos.

Mensaje de confirmación.

Cambios en la pantalla.

FTR en consultas externas: En los dos escenarios tanto en lado de entradas como el de salida deben evaluarse los FTR en una consulta externa. Normalmente son los mismos pero hay casos en que no lo son, por ejemplo si un usuario quiere realizar una consulta a su correo electrónico debe primero evaluarse que el usuario tenga los permisos para poder acceder a esa información.

Las funciones de archivos se refieren a los datos almacenados en bases de datos o cualquier otro tipo de almacenamiento de datos y su complejidad es medida por la cantidad de DETs y RETs que contiene cada función. Archivos lógicos internos (ILF)

Son los datos relacionados lógicamente en el sistema mantenidos por las Entradas Externas [IFPUG., 1999]. Ejemplo: El requerimiento de administrar los usuarios tiene crear,

modificar y borrar usuarios teniendo en este caso un archivo lógico interno que es el que almacena la información del usuario.

55

Calificación de complejidad.

RET DET

1-19 20-50 51 O MAS



Tabla 8. Clasificación de complejidad para los archivos lógicos internos.

RET en Archivos Internos Lógicos: Es un subgrupo de campos de un

archivo, por ejemplo seria una relación de uno a muchos en base de datos relacional.

Archivos de interfaz externos (EIF)

Son los datos relacionados lógicamente en el sistema mantenidos por las Entradas Externas de otras aplicaciones, es decir, es un Archivo Lógico Interno de otra aplicación [IFPUG., 1999]. Ejemplo: siempre que un requerimiento o caso de uso indique que el sistema debe consultar información de una base de datos externa, indica que es un Archivo de Interfaz Externa, suponga una compra con tarjeta de crédito en algún centro comercial, el sistema registra la información de la tarjeta y consulta su crédito en el banco al que corresponda.

Calificación de complejidad. RET DET

1-19 20-50 51 O MAS

1 BAJO (5) BAJO(5) MEDIO(7) 2 a 5 BAJO(5) MEDIO(7) ALTO(10)


Tabla 9. Clasificación de complejidad para los archivos de interfaz externos.

56

2.1.1.3. Calcular el total de puntos de función sin ajustar

Una vez identificados el número de componentes funcionales con su respectiva complejidad se ubican en la siguiente tabla:

COMPONENTES Bajo Medio Alto TOTAL

Entradas Externas ___*3 ___*4 ___*6

Salidas Externas ___*4 ___*5 ___*7

Consultas Externas ___*3 ___*4 ___*6

Archivos Lógicos Internos ___*7 ___*10 ___*15

Archivo de Interface Externa ___*5 ___*7 ___*10

Total Puntos de Función Sin Ajustar

Tabla 10. Calculo total de los puntos de función no ajustados

Con el fin de comprender mejor este paso, a continuación se desarrolla un ejemplo donde se calcule el total de puntos de función sin ajustar:

Cuando se califica el peso (complejidad) de cada componente funcional, se tendrá algo similar a lo siguiente:

Tabla 11. Ejemplo calificación complejidad de cada componente funcional

FUNCIONES DE ARCHIVOS RET DET COMPLEJIDAD

Archivos Internos Lógicos

Información de los usuarios 1 6 BAJO

Trabajos suspendidos 2 6 BAJO

Archivos de interfaz externa

Ventana de ayuda 1 2 BAJO

Conversión de información 1 2 BAJO

FUNCIONES TRANSACCIONALES FTR DET COMPLEJIDAD

Entradas Externas

Añadir información de usuarios 1 7 BAJO

Definición de reportes 2 6 MEDIO

Salidas Externas

Reporte de ventas 3 7 MEDIO

Reporte de salarios de empleados 4 5 MEDIO

Consultas Externas

Lista de empleados 1 4 BAJO

Reporte semanal de usuarios 1 6 BAJO

57

Ahora se tendrá que realizar los cálculos según el peso (complejidad) de cada componente funcional así:

Tabla 12. Tabla ejemplo cálculo total de los puntos de función sin ajustar.

NOMBRE CANTIDAD COMPLEJIDAD MULTIPLICAR COMPLEJIDAD TOTAL

TOTALES

ILFs 2 BAJO x 7 14

0 MEDIO x 10 0

0 ALTO x 15 0

14

EIFs 2 BAJO x 5 10

0 MEDIO x 7 0

0 ALTO x 10 0

10

EIs 1 BAJO x 3 3

1 MEDIO x 4 4

0 ALTO x 6 0

7

EOs 0 BAJO x 4 0

2 MEDIO X5 10

0 ALTO x 7 0

10

EQs 2 BAJO x 3 6

0 MEDIO x 4 0

0 ALTO x 6 0

6

Total puntos de función sin ajustar 47

58

2.1.2. Paso 2: CALCULO DE LOS PUNTOS DE FUNCIÓN AJUSTADOS

2.1.2.1. Evaluar las Características Generales del Sistema (GSC)

En este paso se tienen en cuenta 14 características generales del sistema, que se relacionan con las condiciones de trabajo bajo las que el sistema ha de ser desarrollado. Para ello las 14 (GSC) se califican en un rango de 0 – 5, según lo considere el estimador. Las características generales del sistema son [IFPUG., 1999]: 1. Comunicación de los datos. 2. Procesamiento de datos distribuidos. 3. Desempeño. 4. Configuraciones. 5. Rata de transacción. 6. Entrada de datos en línea. 7. Eficiencia para el usuario final. 8. Actualización en línea. 9. Procesamiento complejo. 10. Reusabilidad del código. 11. Facilidad de instalación. 12. Facilidad operacional. 13. Funcionamiento en múltiples sitios. 14. Facilidad de cambio.

A continuación se mostrará las posibles calificaciones entre 0 y 5 en las que se puede evaluar cada una de las 14 características generales del sistema:

1. Comunicación de los datos 0, cuando la aplicación se ejecuta localmente en el PC.

1, cuando la aplicación tiene entrada remota o remota impresión. 2, cuando la aplicación tiene entrada remota y remota impresión. 3, cuando la aplicación tiene entrada de datos en línea o hace un

teleproceso a un sistema de consulta. 4, cuando la aplicación tiene más de un front-end y sólo admite un

protocolo de comunicación telemática. 5, cuando la aplicación tiene más de un front-end y soporta más de un

protocolo de comunicación telemática.

59

2. procesamiento de datos distribuidos

0, cuando la aplicación no ayuda en la transferencia de datos o procesamiento de funciones entre componentes.

1, cuando la aplicación prepara los datos para el usuario final o para algún otro componente del sistema.

2, cuando los datos son preparados para transferencia y luego son

procesados por otro componente del sistema. 3, cuando el procesamiento distribuido y la transferencia de datos es en

línea y en una dirección. 4, cuando el procesamiento distribuido y transferencia de datos es en

línea y en ambas direcciones. 5, cuando el procesamiento de datos sucede dinámicamente en varios

componentes del sistema.

3. Desempeño 0, cuando no hay requisitos especiales en cuanto a desempeño.

1, cuando los requisitos de desempeño fueron hablados pero no se

necesita tomar acciones especiales para implementar.

2, cuando el tiempo de respuesta es crítico en horas pico.

3, cuando el tiempo de respuesta es crítico durante todo el horario laboral.

4, cuando los requisitos de desempeño fueron explícitamente

declarados y requiere hacer análisis de desempeño durante el diseño del software.

5, cuando los requisitos de desempeño fueron explícitamente declarados y requiere hacer análisis de desempeño durante el diseño del software. Además durante el desarrollo deben estar presentes los requisitos de desempeño.

60

4. Configuraciones

0, cuando no hay restricciones operacionales implícitas, ni explícitas.

1, cuando existen restricciones operacionales pero no necesitan un esfuerzo especial para cumplirlas.

2, cuando existen restricciones operativas y además se deben

considerar algunas restricciones en cuanto a seguridad y desempeño.

3, cuando existen restricciones operativas y además hay requisitos

específicos del procesador.

4, cuando existen restricciones operativas y además hay requisitos específicos del procesador.

5, cuando existen restricciones de explotación y además existen

limitaciones específicas de la aplicación en el procesador central o en el procesador dedicado.

5. Rata de transacciones 0, cuando no se ha especificado si hay tiempos pico en transacciones.

1, cuando los periodos pico son anticipados. Los periodos pico pueden

ser diarios, semanales, mensuales o anuales.

2, cuando los picos semanales son anticipados.

3, cuando los picos diarios son anticipados.

4, cuando hay ratas de transacción solicitadas por el cliente. Hay que considerar esto en la etapa de diseño

5, cuando hay altas ratas de transacciones especificadas por el cliente.

Hay que considerar esto en la etapa de diseño. Necesita herramientas de análisis de desempeño en todas las fases

61

6. Entrada de datos en línea

0, cuando todas las transacciones se procesan en lotes.

1, cuando el 1% al 7% de transacciones son entradas de datos interactivas

2, cuando el 8% al 15% de transacciones son entradas de datos

interactivas. 3, cuando el 16% al 23% de transacciones son entradas de datos

interactivas. 4, cuando el 24% al 30% de transacciones son entradas de datos

interactivas 5, cuando más del 30% de transacciones son entradas de datos

interactivas

7. Eficiencia para el usuario final

0, cuando no hay expectativas en términos de eficiencia para el usuario final.

1, cuando en 2 y 3 veces aparece el desempeño en la lista de requisitos.

2, cuando en 4 y 5 veces aparece el desempeño en la lista de requisitos.

3, cuando más de 6 veces aparece el desempeño en la lista de requisitos.

4, cuando más de 6 veces aparece el desempeño en la lista de requisitos y se exige que en el diseño se tenga en consideración esto.

5, cuando más de 6 veces aparece el desempeño en la lista de requisitos y

se exige que en el diseño se tenga en consideración esto. Se exigen herramientas de análisis para probar estas implementaciones.

62

8. Actualización en línea

0, cuando ninguna actualización.

1, cuando se actualizan de 1 a 3 archivos de control. Los volúmenes de actualización es baja y la recuperación es rápida.

2, cuando actualizan de 4 archivos de control. Los volúmenes de

actualización es baja y la recuperación es rápida. 3, cuando se actualizan los principales ILF,s.

4, cuando se actualizan varios ILFs y la recuperación es especialmente

diseñada e incorporada. 5, cuando se actualizan varios ILFs y la recuperación es especialmente

diseñada e incorporada. Requiere poca intervención humana en el procedimiento de recuperación.

9. Procesamiento complejo

a) control de sensibilidad. b) procesamiento de seguridad. c) extensivo procesamiento lógico. d) extensivo procesamiento matemático. e) procesamiento detallado de excepciones y procesamiento

complejo.

0, cuando no se encuentra ninguno de los componentes anteriores.

1, cuando algún componente de los mencionados se encuentra en la aplicación.

2, cuando dos de los componentes de los mencionados se encuentra

en la aplicación. 3, cuando tres de los componentes de los mencionados se encuentra

en la aplicación. 4, cuando cuatro de los componentes de los mencionados se encuentra

en la aplicación. 5, cuando cinco de los componentes de los mencionados se encuentra

en la aplicación.

63

10. Reusabilidad 0, cuando no hay reusabilidad de código.

1, cuando existe código reusable pero solo es usado en la misma

aplicación. 2, cuando menos del 10% de la aplicación se considera que será

usada por más de un cliente. 3, cuando más del 10% de la aplicación se considera que será usada

por más de un cliente. 4, cuando la aplicación está diseñada, desarrollada y empacada para

reutilización.

5, cuando menos del 10% de la aplicación se considera que será usada por más de un cliente.

11. Facilidad de instalación

0, cuando no hay requisitos especiales para facilidad de instalación.

1, cuando no hay requisitos especiales para facilidad de instalación, pero al menos debe haber un instalador.

2, cuando hay instalación y requisitos de localización requeridos por el

cliente. Pero no es considerado importante. 3, cuando hay instalación y requisitos de localización requeridos por el

cliente. Instaladores son probados. 4, cuando hay instalación y requisitos de localización requeridos por el

cliente. Instaladores y localización son probados. 5, cuando hay instalación y requisitos de localización requeridos por el

cliente. Instaladores y localización son probados. Guías de instalación son probadas.

64

12. Facilidad operacional

0, cuando los procedimientos de respaldo son normales.

1, cuando al menos una consideración operacional aplica para la aplicación. Pero intervención manual es requerida.

2, cuando al menos dos consideraciones operaciones aplican para la

aplicación. Pero intervención manual es requerida. 3, cuando se implementa efectivo inicio, respaldo y restauración en la

aplicación. Pero es requerida la intervención manual. 4, cuando se implementa efectivo inicio, respaldo y restauración en la

aplicación. Pero se requiere de intervención manual mínima. 5, cuando se implementa efectivo inicio, respaldo y restauración en la

aplicación. La aplicación automatiza eso.

13. Funcionamiento en múltiples sitios

0, cuando no hay requisitos específicos para múltiples usuarios y

múltiples sitios.

1, cuando múltiples sitios son considerados en el diseño pero la aplicación es diseñada para sólo operar en un determinado ambiente.

2, cuando múltiples sitios son considerados en el diseño pero la

aplicación es diseñada para sólo operar en ambientes similares. 3, cuando múltiples sitios son considerados en el diseño pero la

aplicación es diseñada para sólo operar en ambientes diferentes. 4, cuando la documentación y soporte son dadas a las aplicaciones

mencionadas en el punto 1 y 2. 5, cuando la documentación y soporte son dadas a las aplicaciones

mencionadas en el punto 1 2 y 3.

65

14. Facilidad de cambio

a. Consultas flexibles y facilidad de reportes se pueden manejar por medio de peticiones simples; y/o lógica aplicada un solo archivo lógico interno (cuenta como un elemento).

b. Consultas flexibles y facilidad de reportes se pueden manejar por medio de solicitudes de complejidad media por ejemplo, y / o lógica aplicada a más de un archivo lógico interno (cuentan como dos puntos).

c. Consultas flexibles y facilidad de reportes se pueden manejar por medio de solicitudes de complejidad alta, por ejemplo, y / o combinaciones lógicas de uno o más archivos lógicos internos (cuentan como tres puntos).

d. Los datos de control de negocio están en tablas y son mantenidos por el usuario por medio de procesos interactivos en línea.

e. Los datos de control de negocio están en tablas y son mantenidos por el usuario por medio de procesos interactivos en línea y los cambios tienen efecto inmediato (cuentan como dos puntos).

0, cuando no se considera ninguno de los puntos anteriores.

1, cuando se considera cualquiera de los puntos anteriores. 2, cuando se consideran dos de los puntos anteriores. 3, cuando se consideran tres de los puntos anteriores. 4, cuando se consideran cuatro de los puntos anteriores. 5, cuando se consideran todos los puntos anteriores.

66

2.1.2.2. Determinar el valor del factor de Ajuste (VAF).

El factor de ajuste lo calculamos mediante la siguiente fórmula [IFPUG., 1999]:

Siendo:

VAF = Valor del Factor de Ajuste.

totalGSC

i

Ci1

= Sumatoria total de las 14 GSC.

Con el fin de comprender mejor este paso, a continuación se presenta un ejemplo donde se determina el factor de ajuste: Para realizar el ajuste se debe tener en cuenta la sumatoria total de 14 características generales del sistema. Obtenidas de la siguiente manera:

Tabla 13. Tabla ejemplo sumatoria total GSC.

1. Comunicación de los datos 3

2. Procesamiento de datos distribuido 0

3. Objetivos de desempeño 1

4. Configuraciones 1

5. Rata de transacciones 5

6. Entrada de datos en línea 1

7. Eficiencia para el usuario final 1

8. Actualización en línea 4

9. Procesamiento complejo 2

10. Reusabilidad 0

11. Fácil instalación 0

12. Facilidad de operar 2

13. Uso en múltiples sitios 2

14. Facilidad de cambio 5

Total GSC 27

totalGSC

i

CiVAF1

01.065.0

67

Ahora se necesita aplicar la fórmula del factor de ajuste de la siguiente manera:

Para este ejemplo, el resultado es el siguiente: Factor = 0.65 +0.01*27 Factor= 0.92

2.1.2.3. Calcular el total de puntos de función de toda la aplicación.

Para determinar los puntos de función ajustados se consideran los puntos

función no ajustados y el factor de ajuste, de acuerdo a la siguiente ecuación:

PFA = PFNA * VAF

Siendo:

PFA = Puntos de Función Ajustados.

PFNA = Puntos de Función No Ajustados.

VAF = Valor del Factor de Ajuste

Con el fin de aplicar el ejemplo considerado en los pasos anteriores, se toma el valor de la tabla 11 y el factor de ajuste calculado en el paso anterior, para así, realizar el cálculo total de los puntos de función ajustados: PFA = 47 X 0.92 PFA = 43.24 El total de puntos de función ajustados para la aplicación de este ejemplo son: 43.24

14

1

01.065.0i

CiFactor

68

3. Importancia de la estimación con base en puntos de función.

Una de las principales razones por lo que la industria del software se preocupa, es por encontrar un método de medición estándar que sea igual para todos, para así, poder utilizarlo entre las diferentes empresas dedicadas al desarrollo de software y que todos puedan entender y operar de la misma forma. El IFPUG (International Function Point User Group) de los Estados Unidos, ha definido el uso de los puntos de función (FPA), como el estándar para medir el desarrollo de software desde el punto de vista del usuario [DRSE., 2003]. De esta manera el método ha tomado mucha fuerza y se está convirtiendo en el método más utilizado por la industria del software para medir el tamaño de una aplicación que ayuda a controlar los gastos que se generan en las compañías. Según Sergio Duran en [DRSE., 2003] dice “No puedo controlar, lo que no puedo medir”. Así pues, se puede decir que una de las principales importancias del uso de este método es que se encuentra estandarizado y puede ser distribuido de manera pública. Entre algunas otras razones del porque la importancia de utilizar este método, es porque es un método que es independiente de la tecnología y es basado en la funcionalidad, lo que permite realizar estimaciones tempranas sin tener que esperar la culminación de un proyecto de desarrollo y además se adapta fácilmente en cualquier etapa del mismo.

3.1. Características del método de puntos de función

Algunas de las características más representativas del método de puntos de función son [DRSE., 2003]:

Independiente de la tecnología: Se refiere a que primero se debe

establecer la funcionalidad y después se escoge la tecnología que permita obtener esta funcionalidad.

Basadas en la funcionalidad: Se refiere a saber que nuevas capacidades

va a tener el software desarrollado.

Basada en requerimientos de usuario: Se refiere a que el usuario podrá

saber las razones del tamaño del software y las implicaciones, pero lo más importante es que puede tener esta información antes de realizarse el desarrollo.

Consistencia: Se refiere a que los resultados de diferentes proyectos

deben ser consistentes.

69

3.2. Predicciones basadas en puntos de función

Cuando se habla de estimación manual de costos de software, se habla de operaciones sencillas ya sean mentales o por medio de una calculadora, que puedan dar una visión de los posibles costos que tendrá una aplicación en proceso de desarrollo [JC., 2008]. Existen varias estimaciones de costos de software realizadas por la estimación manual, este tipo de estimación sirve para los siguientes tipos de proyectos:

Estimaciones tempranas antes de conocer los requisitos.

Proyectos pequeños que requieren solo uno o dos programadores.

Proyectos de bajo valor sin impacto decisivo en los negocios.

En caso que el proyecto sea grande o que implique riesgos de impacto en los negocios no se recomienda usar la estimación manual ya que no es muy precisa, y para que lo sea, se necesita integrar muchos tipos de información. A continuación se muestra la manera de realizar algunas de las predicciones basadas en los puntos de función [JC., 2008]:

3.2.1. Predicciones del tamaño de volúmenes de código fuente

A continuación se presenta en la tabla 14 tomada de [JC., 2008], la conversión de los puntos de función en líneas de código (LOC). Los siguientes valores según Capers Jones en [JC., 2008], son valores basados en instrucciones lógicas y no en líneas de codigo físicas. Esto debido a que las líneas de código físicas varían de un lenguaje a otro y también dependen de la experiencia del programador.

PUNTOS DE FUNCIÓN LOC LENGUAJE

1 320 Ensamblador 1 213 Ensamblador de macros 1 128 C 1 107 COBOL 1 107 FORTRAN 1 80 PL/I 1 71 ADA 83 1 53 C++ 1 50 JAVA 1 15 Smalltalk

Tabla 14. Tabla conversión PF a líneas de código [JC., 2008].

70

La fórmula para calcular el total de líneas de código por el método de puntos de función es:

TLOC = TPF * LOCL Donde:

TLOC = Total líneas de código TPF = Total puntos de función. LOCL = Líneas de código por lenguaje

Ejemplo: para conocer la cantidad total de LOC se deben tomar los puntos de función y multiplicarlo por el valor correspondiente al lenguaje donde se hará el desarrollo, por ejemplos si una aplicación tiene 150 puntos de función y el desarrollo será en java la operación es la siguiente:

TLOC = 150 * 50 TLOC = 7500

El total de líneas de código para los 150 puntos de función son: 7500

3.2.2. Predicción del tamaño de los entregables en papel

En la industria del software se utiliza mucho papel por la cantidad de documentos de respaldo que se deben crear, siendo las aplicaciones militares las que más papeleo necesitan y en algunas ocasiones estos documentos cuestan más que la propia aplicación. Los tipos más comunes de documentos relacionados con aplicaciones de software son [JC., 2008]:

Requisitos.

Estimaciones de costos.

Planes de desarrollo.

Especificaciones funcionales.

Solicitudes de cambio.

Especificaciones lógicas o internas.

Reportes del estado de proyectos.

Manuales de usuario.

Planes de prueba.

Reportes de errores de código o defectos.

71

El volumen de la documentación está relacionado con el tamaño del software, así pues que entre más grande sea la aplicación así mismo será la documentación generada. El método práctico para estimar la documentación de una aplicación de software comprende los documentos de requisitos, especificaciones internas y externas, planes de desarrollo y calidad, planes de pruebas, manuales de usuario y otros documentos relacionados con el negocio [JC., 2008]. Según Capers Jones en [JC., 2008] dice que “los puntos de función elevados a la potencia 1.15 predicen conteos aproximados de páginas para documentos en papel, asociados con proyectos de software” La fórmula para calcular la cantidad de páginas para una aplicación por el método de puntos de función es:

CP = TPF ^ 1.15 Donde:

CP = Cantidad de páginas. TPF = Total puntos de función.

Ejemplo: para predecir la cantidad de páginas de una aplicación de software se deben elevar los puntos de función a la potencia 1.15, así pues una aplicación

con 150 PF gastará: CP = 150 ^ 1.15 CP= 318.05 318.05 hojas se utilizaran para realizar una aplicación con 150 PF.

3.2.3. Predicción de fechas límite para el software

La fecha límite de entrega de las aplicaciones de software son de alta prioridad porque con esta los ejecutivos de las compañías o los clientes pueden saber aproximadamente en cuanto estará lista la aplicación que ellos necesitan y saber que decisiones tomar respecto a este tiempo estimado [JC., 2008]. Según Capers Jones en [JC., 2008] dice que “los puntos de función elevados a la potencia 0.4 predicen la fecha límite de desarrollo aproximada en meses calendario” La fórmula para calcular el total de meses para realizar una aplicación por el método de puntos de función es:

72

NM = TPF ^ 0.4 Donde:

NM = Número de meses. TPF = Total de puntos de función.

Ejemplo: para predecir el tiempo aproximado de finalización del software se deben tomar los puntos de función y elevarlos a la potencia 0.4, siguiendo el ejemplo de la aplicación con 150 PF el tiempo estimado para este desarrollo será: NM = 150 ^ 0.4 NM = 7.4 El número de meses que toma desarrollar la aplicación con 150 puntos de función son 7.4 meses.

3.2.4. Predicción de número de empleados para desarrollar una aplicación

Esta predicción incluye personal de control de calidad, comprobadores, redactores técnicos, administradores de base de datos y gerentes de proyectos [JC., 2008]. Según Capers Jones en [JC., 2008] dice que “los puntos de función divididos entre 150 predicen el número aproximado de empleados requeridos para el desarrollo de una aplicación” La fórmula para calcular el número de empleados para desarrollar una aplicación por el método de puntos de función es:

CE = TPF / 150 Donde:

CE= Cantidad de empleados. TPF = Total de puntos de función.

73

Ejemplo: para tener el número aproximado de empleados necesarios se debe dividir los puntos de función entre 150, por ejemplo una aplicación de 1000 PF necesitara: CE = 1000 / 150 CE = 6.66 El número de empleados para una aplicación con 1000 puntos de función son: 6.6 empleados

3.2.5. Predicción de años que estará en uso la aplicación

Según Capers Jones en [JC., 2008], para saber el número aproximado de años que la aplicación estará en uso se deberá tomar los puntos de función ajustados y se elevaran a la potencia 0.25. La fórmula para calcular los años de uso de una aplicación por el método de puntos de función es la siguiente:

AU = TPF ^ 0.25 Donde

AU = Años de uso de una aplicación. TPF = Total puntos de función.

Ejemplo: para tener el número aproximado años que estará en uso una aplicación se deben tomar los puntos de función y elevarlos a la potencia 0.25, por ejemplo Una aplicación con 1000 PF tendrá: AU = 1000 ^ 0.25 AU =6.0 Los años que una aplicación con 1000 puntos de función estará en uso son: 6 años.

74

3.2.5. Predicción de costos para el total de empleados Con el fin de agregar una predicción para calcular el costo del número de empleados para desarrollar una aplicación, se toman las siguientes predicciones:

Predicción del número de empleados para desarrollar una aplicación. Predicción de fechas límite para el software.

Existe un tercer factor para calcular el costo del total de empleados que se agrega dependiendo de las políticas de la organización que va a desarrollar una aplicación. Este factor, se refiere al salario mensual de los empleados que intervienen en el desarrollaran de una aplicación.

La fórmula para predecir el costo para el total de empleados es la siguiente:

PCE = (PFL * SME) * PNE

Donde:

PCE = Predicción de costos para el total de empleados. PLF = Predicción de fechas límite para el software. SME = Salario mensual empleado PNE = Predicción del número de empleados para desarrollar una aplicación.

Ejemplo: Para calcular el costo para el total de empleados, se debe tomar el valor del número de meses de que toma desarrollar una aplicación por el valor del salario mensual. Luego el valor resultante se multiplica por el número de empleados que intervienen en el desarrollo de una aplicación. Así pues, para una aplicación que se demore 4 meses, necesite de 15 empleados y el salario mensual de cada empleado sea de $800.000, el costo para desarrollar esa aplicación a partir del número total de empleados es el siguiente.

PCE = (4 * 800.000) * 15

PCE = 3.200.000 * 15

PCE = 48.000.000

El costo para desarrollar esa aplicación a partir del número de empleados que intervienen en la misma, es de $48.000.000.

75

4. Herramienta desarrollada (EstimaSoft)

Como parte final de este proyecto, se realizará la explicación de la herramienta desarrollada por el método de puntos de función. La siguiente explicación pretende aclarar el uso de la herramienta que se desarrollo. Para ello se explicara tanto las entradas (Lo que ingresa el usuario) como las salidas (Lo que muestra el sistema) por medio de capturas que permitan evidenciar mejor cómo funciona la herramienta. Entradas:

Lo primero que se debe hacer cuando se abre la aplicación es ingresar los siguientes datos para crear un proyecto:

Nombre: Nombre del proyecto que se va a crear. Fecha: Fecha en la que se creara un proyecto. Descripción: Pequeña descripción sobre el proyecto.

76

Luego de ingresar los datos correctamente a la aplicación, se encontraran dos botones: Crear: Para crear el proyecto que va a ser estimado. Consultar: Muestra el listado de todos los proyectos, en caso tal de que no

se haya escrito nada en el campo Nombre. De lo contrario mostrará los

nombres de los proyectos que contengan las letras ingresadas en el campo. El siguiente paso es ingresar los requerimientos para un proyecto creado con sus respectivos valores por componente funcional, es decir, por cada requerimiento que se ingrese al sistema se deben evaluar los 5 componentes funcionales para ese requerimiento. Para ello se ingresan los siguientes datos: Código requerimiento: El código del requerimiento que se va a crear. Nombre requerimiento: El nombre del requerimiento que se va a crear.

Archivos lógicos internos: Número de ILF,s encontrados para un

requerimiento con su respectiva complejidad (DET y/o RET).

Interfaz de archivos externos: Número de EIF,s encontrados para un requerimiento con su respectiva complejidad (DET y/o RET).

Entradas externas: Número de EI encontrados para un requerimiento con

su respectiva complejidad (FTR y/o DET).

Salidas externas: Número de EO encontrados para un requerimiento con su respectiva complejidad (FTR y/o DET).

Consultas externas: Número de EQ encontrados para un requerimiento

con su respectiva complejidad (FTR y/o DET). Luego de ingresar los datos correctamente a la aplicación, se encontraran cuatro botones: Guardar: Guarda el total de requerimientos ingresados con sus respectivos

valores por componente funcional.

Modificar: Modifica cualquiera de los valores ingresados previamente

Finalizar: Indicara que ya termino de ingresar los requerimientos.

77

La siguiente imagen presenta de forma más detallada lo descrito anteriormente:

Posteriormente se procede a ingresar las 14 características generales del sistema. Estas características se evalúan dentro de un rango de 0 – 5. La siguiente imagen ilustra lo anteriormente descrito:

78

Nota: Con el fin de hacer más amigable la evaluación de las 14 “GCS” para el usuario, se dispuso en la parte derecha de cada “GCS” un botón “ ”, para que el usuario pueda ver los criterios bajo los cuales se podrán evaluar las 14 “GCS”. A continuación se mostrara por medio de una captura tomada de la aplicación lo explicado anteriormente:

79

Luego de ingresar los datos correctamente a la aplicación, se encuentra el siguiente botón:

Ajustar: Realiza el cálculo del total de puntos de función ajustados y los

muestra en la parte superior del botón (Se considera como una salida debido a que es información suministrada por la aplicación).

Modificar ajuste: Modificar cualquiera de las 14 características generales

del sistema

Salidas:

Las salidas de la aplicación son:

Puntos de función sin ajustar: Se refiere al total de puntos de función calculados para un proyecto de software antes de aplicar las 14 características generales del sistema y el factor de ajuste. Como ya se había explicado en la fase donde se ingresan los requerimientos con sus respectivos componentes funcionales, luego de presionar el botón “Calcular”, el sistema mostrara el total de puntos de función sin ajustar calculados para la aplicación que se está estimando, de la siguiente manera:

80

Total Puntos de función ajustados: Se refiere a la suma total de puntos de función calculados para un proyecto de software luego de evaluar las 14 características generales del sistema y aplicar el factor de ajuste. Como ya se había explicado en la fase donde se ingresan las 14 características generales del sistema “GCS”, luego de presionar el botón “Guardar” el sistema mostrara el total de puntos de función ajustados que se calcularon para la aplicación que se está estimando, de la siguiente manera:

Así pues, se podría concluir que el número de puntos de función ajustados

que se calcularon para esa aplicación, son: 28

81

Predicciones: Se refiere a unos pronósticos que muestra la aplicación

(EstimaSoft), luego de hallar el total de puntos ajustados para un proyecto

de software. Para realizar el cálculo de las predicciones la aplicación

(EstimaSoft), dispone de un botón “Resumen” que muestra lo siguiente:

Nota: Queda a consideración del usuario modificar los valores predeterminados para realizar las predicciones, por ejemplo: El valor predeterminado para calcular el total de líneas de código en Java para un proyecto es igual a 50. Si lo desea modificar por otro valor, por ejemplo, que el total de líneas de código en Java para un proyecto sea igual a 60, lo puede realizar. Para realizar las modificaciones, lo primero que debemos hacer es seleccionar de la lista que se encuentra al frente de la palabra “Predicciones” la predicción que se desea modificar. A continuación se mostrará por medio de una captura tomada a la aplicación lo explicado anteriormente:

82

Luego de que se haya seleccionado la predicción, se podrá modificar el nombre y/o el valor de la predicción, ingresando los nuevos valores y haciendo click en el botón “Modificar”. En la siguiente captura tomada a la aplicación se puede apreciar lo explicado anteriormente: Si se desea poner de nuevo en blanco todos los campos de la pantalla, solo bastará con hacer click en el botón “Limpiar”.

Cabe aclarar que si el usuario desea conocer nuevamente las predicciones de un proyecto ya creado bajo las nuevas modificaciones, deberá consultar el proyecto creado y luego dar click en el botón “Predicciones”, así el sistema tomará el valor de las predicciones que se modificaron e imprimirá nuevamente las predicciones.

83

5. CONCLUSIONES

El uso de un método apropiado de estimación resulta de vital importancia para cualquier compañía que desarrolle proyectos de software, debido a que le permite tener una visión a futuro del esfuerzo tamaño y costo que tomará desarrollar una aplicación.

El cálculo de los puntos de función es sencillo y permite dar una visión de

los posibles costos del proyecto antes de desarrollarlo.

El método puntos de función es el método más usado en la actualidad para calcular el tamaño de un proyecto de software.

El método de puntos de función puede unirse con otros métodos, tal y como lo hace con el método COCOMO2, y así de esta manera entregar estimaciones más aproximadas a la realidad.

84

BIBLIOGRAFIA

[LGP., et al. 2008]. López Guerra, Elsydania y colaboradores (lunes 24 de marzo de 2008). Estimación Basada en Puntos de Función y Soluciones Híbridas. [Online]. Disponible en: http://www.monografias.com/trabajos55/estimacion-por-puntos-de-funcion/estimacion-por-puntos-de-funcion.shtml

[GJ., 1996]. Grompone, Juan. Gestión de Proyectos de Software. Primera Edición. Editorial La Flor del Itapebí. Montevideo, Uruguay. [Online]. Disponible en: http://es.scribd.com/doc/53744474/Gestion-de-Proyectos-de-Software-Juan-Grompone

[SRF., 1999]. Sánchez Rodríguez, Faustino: Planificación y Gestión de Sistemas de Información : Medida del Tamaño Funcional de Aplicaciones de Software. Mayo 1999. Universidad de Castilla-La Mancha. Escuela Superior de Informática de Ciudad-Real. [Online]. Disponible en: http://alarcos.inf-

cr.uclm.es/doc/pgsi/doc/esp/T9899_FSanchez.pdf

[Abran A., et al.98]. Abran, A.; Desharnais J. M.; Maya M.; St-Pierre D.; Bourque P. (1998). Design of a Functional size Measurement for Real-Time Software. Research Report N° 13. Software Engineering Management Research Laboratory, Universite du Québec a Montreal, Canada.

[OJD., 2006]. Ovejero, José Daniel. Estimación de Proyectos Para Sistemas Basados en Conocimiento. Buenos Aires, 2006. Tesis de Magíster en Ingeniería del software. Universidad Politécnica Madrid. [Online]. Disponible en: http://www.itba.edu.ar/archivos/secciones/ovejero-tesisdemagister.pdf

[SC., 1988]. Symons, Charles. Function Point Analysis: Difficulties and Improvements. Enero 1988. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 14, NO. I. [Online]. Disponible en:

http://www.ceng.metu.edu.tr/~e120353/HoughTransform/FP_analysis.pdf

http://www.monografias.com/trabajos55/estimacion-por-puntos-de-funcion/estimacion-por-puntos-de-funcion.shtml

http://www.monografias.com/trabajos55/estimacion-por-puntos-de-funcion/estimacion-por-puntos-de-funcion.shtml

http://es.scribd.com/doc/53744474/Gestion-de-Proyectos-de-Software-Juan-Grompone

http://es.scribd.com/doc/53744474/Gestion-de-Proyectos-de-Software-Juan-Grompone

http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/esp/T9899_FSanchez.pdf

http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/esp/T9899_FSanchez.pdf

http://www.itba.edu.ar/archivos/secciones/ovejero-tesisdemagister.pdf

http://www.itba.edu.ar/archivos/secciones/ovejero-tesisdemagister.pdf

http://www.ceng.metu.edu.tr/~e120353/HoughTransform/FP_analysis.pdf

85

[Aemes., 2010]. Aemes Ti. Asociación Española para la Gobernanza, la Gestión y la Medición de las Tecnologías de la Información. Métricas e Indicadores. 12 de Enero de 2010. [Online]. Disponible en:

http://www.aemes.org/index.php/historico-de-noticias/1-ultimas-noticias/61-metricas-e-indicadores

[BD., 2008]. Bundschuh, Manfred Y Dekkers, Carol. The IT measurement compendium: estimating and benchmarking success with functional size measurement. Editorial Springer. Alemania (Berlin, Heidelberg). 01 de Enero de 2008. pp 390 – 392.

[IFPUG., 2010]. IFPUG. International Function Point User Group. Metric Views. Julio 2010. Vol.4. Issue1. pp 6. [Online]. Disponible en:

http://www.ifpug.org/newsletterArchives/newsletters/July%202010%20MetricViews.pdf

[CFN., 2006]. Condori Fernández, Nelly: Un Procedimiento de Medición de Tamaño Funcional para Especificaciones de Requisitos. Valencia (España), 19 de diciembre de 2006. Trabajo de grado (Ingeniero de Sistemas). Universidad Politécnica de Valencia. Programa de sistemas. [Online]. Disponible en: http://www.dsic.upv.es/docs/bib-dig/tesis/etd-01292007-183804/TesisNelly.pdf

[FB., 2007]. Forigua, sandra patricia y Ballesteros, óscar arturo: propuesta de un modelo de análisis para estimación del tamaño del software y gestión de costos y riesgos a partir de requerimientos funcionales. Bogotá dc, junio 2007. Trabajo de grado (Ingeniero de Sistemas). Pontificia Universidad Javeriana. Programa de sistemas.

[MCS., 1997]. McConnell, Steve. Desarrollo y gestión de proyectos informáticos. Editorial McGraw-Hill Interamericana de España. España, 1997.





http://www.dsic.upv.es/docs/bib-dig/tesis/etd-01292007-183804/TesisNelly.pdf

http://www.dsic.upv.es/docs/bib-dig/tesis/etd-01292007-183804/TesisNelly.pdf

http://dialnet.unirioja.es/servlet/editor?codigo=2558

86

[FOL., 2010]. Fernández O"Farrill, Lianny. Estimación de tiempo y esfuerzo en proyectos de software. Universidad Central Marta Abreu de las Villas. Santa Clara, Cuba. 02 de diciembre de 2010. [Online]. Disponible en: http://www.monografias.com/trabajos82/estimacion-tiempo-

esfuerzo-proyectos-software/estimacion-tiempo-esfuerzo-proyectos-software.shtml

[SEI., 2011]. Software Engineering Institute. Carnegie Mellon. CMMI Capability Maturity Model Integration (CMMI): Overview. [Online]. Disponible en: http://www.sei.cmu.edu/cmmi/

[GJ., 2005]. Gracia, Joaquin. CMM - CMMI. 14 de Agosto de 2005. [Online]. Disponible en: http://www.ingenierosoftware.com/calidad/cmm-

cmmi.php

[CJM., 2008]. Chacón, Juan Marcos. Modelos de gestión de la calidad de software. Jueves 3 de Enero de 2008. [Online]. Disponible en:

http://juanmarcosteoria2.blogspot.com/2008/01/para-el-enriquecimiento-de-los-lectores.html

[BSB., 2006]. Bonilla Sánchez, Beatriz. CMMI - Modelos de madurez 2 y 3. Viernes 31 de Marzo de 2006. [Online]. Disponible en: http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=cmmi2y3

[OBA., 2008]. Oré Bravo, Alexander. INTRODUCCIÓN AL CMMI – CMM. Domingo 13 de Abril de 2008. [Online]. Disponible en: http://www.calidadysoftware.com/otros/introduccion_cmmi.php

[HDAM., 2009]. Huayna Dueñas, Ana María. Modelo CMMI. 2009. pp 10. [Online]. Disponible en: http://www.slideshare.net/vivian12345/modelo-

cmmi-7

[Anónimo., n.d.]. Anónimo. MÉTODOS DE ESTIMACIÓN. [Online]. Disponible en: http://www.lsi.us.es/docencia/get.php?id=326

[SEI., 2010]. Software Engineering, Inc. Jensen Model. 2010. [Online]. Disponible en: http://www.seisage.net/jensen_model.htm

[Aemes1., 2010]. Aemes Ti. Asociación Española para la Gobernanza,

http://www.monografias.com/trabajos82/estimacion-tiempo-esfuerzo-proyectos-software/estimacion-tiempo-esfuerzo-proyectos-software.shtml



http://www.sei.cmu.edu/cmmi/

http://www.ingenierosoftware.com/calidad/cmm-cmmi.php

http://www.ingenierosoftware.com/calidad/cmm-cmmi.php



http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=cmmi2y3

http://www.calidadysoftware.com/otros/introduccion_cmmi.php

http://www.slideshare.net/vivian12345/modelo-cmmi-7

http://www.slideshare.net/vivian12345/modelo-cmmi-7

http://www.lsi.us.es/docencia/get.php?id=326

http://www.seisage.net/jensen_model.htm

87

la Gestión y la Medición de las Tecnologías de la Información. Revista de Procesos y Métricas. Volumen 7, numero 2. 2 de Mayo - Agosto de 2010. [Online]. Disponible en: http://www.aemes.org/index.php/revista-de-procesos-y-metricas/numeros-publicados/ano-2010-volumen-7/328-volumen-7-g-numero-2-g-mayo-agosto-2010

[RP., 1990]. Rook, Paul. SOFTWARE RELIABILITY HANDBOOK. First Edition 1990.KLUWER ACADEMIC PUBLISHERS. pp 504 -505.

[MKR., 1996]. Mertes, Karen R. CALIBRATION OF THE CHECKPOINT MODEL. TO THE SPACE AND MISSILE SYSTEMS CENTER (SMC). SOFTWARE DATABASE (SWDB). THESIS AFIT/GCA/LAS/96S-11. Air Force Institute of Technology (AFIT), Agosto 1996.

[Anónimo1., n.d.]. Anónimo. Modelos de estimación de costes de producción de software. [Online]. Disponible en:

http://bibing.us.es/proyectos/abreproy/10977/fichero/Memoria%252F2.pdf

[JC., 2008]. Jones, Capers. Estimación de costos y administración de proyectos de software. Edicion2da. McGraw-Hill, 2008.

[UKSS., 1998]. ÜMIT, KARAKAS y SULTANOGLU, SENCER. Cost Estimation Models. Octubre 12 de 1998. [Online]. Disponible en: http://yunus.hacettepe.edu.tr/~sencer/cocomo.html

[WIKI., 2011]. Colaboradores de Wikipedia. COCOMO. Wikipedia, La enciclopedia libre, 2011. 24 de marzo del 2011. [Online]. Disponible en:

http://es.wikipedia.org/w/index.php?title=COCOMO&oldid=45068599.

[WIKILC., 2011]. Colaboradores de Wikipedia. Líneas de código fuente. Wikipedia, La enciclopedia libre, 2011. 25 de abril del 2011. [Online]. Disponible en:

http://es.wikipedia.org/w/index.php?title=L%C3%ADneas_de_c%C3%B3digo_fuente&oldid=45892285

http://www.aemes.org/index.php/revista-de-procesos-y-metricas/numeros-publicados/ano-2010-volumen-7/328-volumen-7-g-numero-2-g-mayo-agosto-2010



http://bibing.us.es/proyectos/abreproy/10977/fichero/Memoria%252F2.pdf

http://yunus.hacettepe.edu.tr/~sencer/cocomo.html

http://es.wikipedia.org/w/index.php?title=COCOMO&oldid=45068599



88

[SLPF., 2006]. Salvetto de León, Pedro Fernando: Modelos Automatizables de Estimación muy Temprana del Tiempo y Esfuerzo de Desarrollo de Sistemas de Información. Uruguay (Montevideo), 8 de Mayo 2006. Tesis Doctoral. Universidad Politécnica de Madrid. Facultad de Informática.

[VOS., n.d.]. Valero Orea, Sergio. ESTIMACIÓN DE PROYECTOS DE SOFTWARE CON PUNTOS DE CASOS DE USO. [Online]. Disponible en: http://www.utim.edu.mx/~svalero/docs/id45.pdf

[GA., et al. 2008]. Gastaldo, Alfredo y colaboradores. Programación Orientada a Aspectos – POA. Rosario, Octubre de 2008. Pontificia Universidad Católica Argentina. Facultad Católica de Química e Ingeniería. pp 24. [Online]. Disponible en: http://es.scribd.com/doc/54136364/10/Metrica-LDCF-Lineas-De-Codigo-Fuente

[MA., n.d.]. Moreno, Ana. Estimación de Proyectos de Software. COCOMO II. [Online]. Disponible en: http://creaweb.ei.uvigo.es/creaweb/Asignaturas/PPI/apuntes/cocomo2k.pdf

[NTC., 2008]. NORMA TÉCNICA COLOMBIANA. NTC 1486, 23 de Julio de 2008. DOCUMENTACIÓN. PRESENTACIÓN DE TESIS, TRABAJOS DE GRADO Y OTROS TRABAJOS DE INVESTIGACIÓN. [Online]. Disponible en: http://www.uceva.edu.co/ingenieria/images/norma/ntc1486.pdf

[IFPUG., 1999]. International Function Point Users Group (IFPUG). Function Point Counting Practices Manual 4.1. January 1999. [Online]. Disponible en: http://es.scribd.com/doc/46260527/IFPUG-Counting-

Practices-Manual-4-1.

[DRSE., 2003] Durán Rubio, Sergio Eduardo. Puntos por Función: Una métrica estándar para establecer el tamaño del software. Boletín de Política Informática Núm. 6, 2003. [Online]. Disponible en: http://www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tecnologia/puntosxfuncion.pdf

http://www.utim.edu.mx/~svalero/docs/id45.pdf

http://es.scribd.com/doc/54136364/10/Metrica-LDCF-Lineas-De-Codigo-Fuente

http://es.scribd.com/doc/54136364/10/Metrica-LDCF-Lineas-De-Codigo-Fuente

http://creaweb.ei.uvigo.es/creaweb/Asignaturas/PPI/apuntes/cocomo2k.pdf

http://www.uceva.edu.co/ingenieria/images/norma/ntc1486.pdf

http://es.scribd.com/doc/46260527/IFPUG-Counting-Practices-Manual-4-1

http://es.scribd.com/doc/46260527/IFPUG-Counting-Practices-Manual-4-1

http://www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tecnologia/puntosxfuncion.pdf

http://www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tecnologia/puntosxfuncion.pdf

89

[ISO., nd]. International Organization for standardization. About ISO. [Online]. Disponible en: http://www.iso.org/iso/about.htm

[WIKITI., 2011]. Colaboradores de Wikipedia. Tecnología de la información. Wikipedia, La enciclopedia libre, 2011. 28 de febrero del 2011]. [Online]. Disponible en:

http://es.wikipedia.org/w/index.php?title=Tecnolog%C3%ADa_de_la_informaci%C3%B3n&oldid=44474315

[WIKICU. 2011] Colaboradores de Wikipedia. Caso de uso. Wikipedia, La enciclopedia libre, 2011. 5 de abril del 2011]. [Online]. Disponible en: http://es.wikipedia.org/w/index.php?title=Caso_de_uso&oldid=45381208

[WIKIPOO., 2011] Colaboradores de Wikipedia. Programación orientada a objetos. Wikipedia, La enciclopedia libre, 2011. 25 de abril del 2011]. [Online]. Disponible en: http://es.wikipedia.org/w/index.php?title=Programaci%C3%B3n_orientada_a_objetos&oldid=45886462

[WIKIIBM., 2011] Colaboradores de Wikipedia. IBM. Wikipedia, La enciclopedia libre, 2011. 22 de abril del 2011]. [Online]. Disponible en:

http://es.wikipedia.org/w/index.php?title=IBM&oldid=45809080

[CSE., 1999].CENTER FOR SOFTWARE ENGINEERING USC. Cocomo II ModelDefinition Manual. Ver2.1. COCOMO, 1999.

[LD., n.d.]. David Longstreet. Function Points Analysis Training Course. [Online]. Disponible en:

http://www.softwaremetrics.com/Function%20Point%20Training%20Booklet%20New.pdf

http://www.iso.org/iso/about.htm



http://es.wikipedia.org/w/index.php?title=Caso_de_uso&oldid=45381208

http://es.wikipedia.org/w/index.php?title=Programaci%C3%B3n_orientada_a_objetos&oldid=45886462

http://es.wikipedia.org/w/index.php?title=Programaci%C3%B3n_orientada_a_objetos&oldid=45886462

http://es.wikipedia.org/w/index.php?title=IBM&oldid=45809080



HERRAMIENTA PARA ESTIMAR EL TAMAÑO DE SOFTWARE...

Documents

Transcript of HERRAMIENTA PARA ESTIMAR EL TAMAÑO DE SOFTWARE...