Tema I - Gestión de Proyectos Software: Estimación

Transcripción

1 Tema I - Gestión de Proyectos Software: Estimación

2 Bibliografía Calvo-Manzano, J.A., Cervera, J., Fernández, L., Piattini, M. Aplicaciones Informáticas de Gestión. Una perspectiva de Ingeniería del Software. Ra-ma, 2004 Pressman, R. S., Ingeniería del Software. Un Enfoque Práctico.McGraw-Hill, S. McConell, Desarrollo y Gestión de Proyectos Informáticos. McGraw-Hill.

3 Índice 1. Planificación 1.1. Conceptos generales 1.2. Actividades 1.3. Técnicas 2. Estimación de costes 2.1. Métodos de estimación 2.2. Modelos de estimación 2.4. Enfoque recomendado 3. Seguimiento y supervisión 3.1. Supervisión de resultados 3.2. Acciones correctivas 4. Gestión de Riesgos

4 Estimación de Costes Estimación de coste para proyectos de software: No se miden en unidades monetarias. Suelen ser valoraciones, con un cierto error ( 20%), del esfuerzo y plazos de tiempo. El software es un producto sin existencia física, cuyo coste principal reside en su desarrollo o diseño: el coste de su producción está dominado por los gastos de personal. La principal unidad de medición de coste suele ser el número de salarios mensuales o anuales, especificados en personas-mes o personas-año. Razones que dificultan la estimación en proyectos software: Peculiaridades del software: desarrollar un nuevo producto cada vez, empleando distintas técnicas y herramientas. Presiones políticas en la empresa: para disminuir el coste o los plazos Existe una carencia generalizada de datos sobre proyectos terminados Actitud habitual de los responsables de la estimación: se espera que esta actividad no cueste

5 Estimación de Costes Se pretende responder a dos preguntas: Cuánto costará? Qué plazo de tiempo requerirá su desarrollo? La estimación es un proceso continuo, con constantes refinamientos y mejoras, más que una actividad puntual Los métodos actuales dependen de la cantidad de información disponible. A medida que se avanza en el proyecto, se obtiene mas información y más fiable

6 Índice 1. Planificación 1.1. Conceptos generales 1.2. Actividades 1.3. Técnicas 2. Estimación de costes 2.1. Métodos de estimación 2.2. Modelos de estimación 2.4. Enfoque recomendado 3. Seguimiento y supervisión 3.1. Supervisión de resultados 3.2. Acciones correctivas 4. Gestión de Riesgos

7 Métodos de Estimación Métodos para la estimación de costes: 1. Juicio de expertos 2. Estimación por analogía 3. Estimación por descomposición 4. Otros: Precio para ganar

8 Métodos de Estimación 1. Juicio de los expertos Existen técnicas específicas que intentan sistematizar y mejorar la opinión de las distintas personas involucradas en la estimación: Se suele emplear la opinión de más de un experto para obtener una mayor fiabilidad en la estimación. En algunos casos, se calcula la media de los valores ofrecidos por las distintas personas. RIESGO: la estimación puede resentirse mucho de uno o dos valores extremos. Realizar una reunión tan larga como sea necesaria hasta llegar a un consenso. RIESGO: que las personas más influyentes, por su capacidad o por su poder de convencimiento, sean las que determinen el resultado final. Técnica Delphi

9 Métodos de Estimación 1. Juicio de los expertos Técnica Delphi: 1. Un coordinador proporciona a cada experto una especificación del proyecto y un impreso para expresar su opinión. 2. Los expertos rellenan el impreso de forma anónima. Pueden hacer al coordinador preguntas sobre el proyecto pero no pueden intercambiar opiniones entre ellos. 3. El coordinador ofrece a cada experto el valor medio de las opiniones para que la compare con la suya. Se pide realizar una nueva estimación anónima, indicando las posibles razones de la misma. 4. Se repite el proceso de recogida de opiniones hasta que se llega a un consenso en la estimación. No se realizan reuniones en grupo durante todo el proceso.

10 Métodos de Estimación 1. Juicio de los expertos Técnica Delphi de banda ancha (Bohem, 1981): 1. El coordinador proporciona a cada experto una especificación del proyecto y un impreso. 2. El coordinador reúne a los expertos para que intercambien puntos de vista sobre el proyecto. 3. Los expertos rellenan el impreso de forma anónima. 4. El coordinador ofrece a cada experto un resumen con el valor medio de las opiniones para que la compare con la suya. Se pide realizar una nueva estimación anónima, sin indicar las posibles razones de la misma. 5. El coordinador convoca una reunión de grupo para que los expertos discutan las razones de las diferencias entre sus estimaciones. 6. Se rellenan anónimamente los impresos y se repiten los puntos 4, 5 y 6 hasta que se llegue a un consenso.

11 Métodos de Estimación 1. Juicio de los expertos Ventaja: Permite contemplar las diferencias entre experiencias anteriores y el proyecto actual, difíciles de evaluar sin recurrir a personas experimentadas. Desventaja: Subjetividad e inexperiencia que pueden mostrar las personas a las que se consulta.

12 Métodos de Estimación Métodos para la estimación de costes: 1. Juicio de expertos 2. Estimación por analogía 3. Estimación por descomposición 4. Otros: Precio para ganar

13 Métodos de Estimación 2. Estimación por analogía Es un complemento a la de juicio de expertos. Las personas involucradas no sólo trabajan con su experiencia, sino que disponen también de datos de proyectos acabados similares. Por comparación, se pueden evaluar las diferencias entre el nuevo proyecto y los antiguos y extrapolar su coste. Los ajustes en el coste, esfuerzo o tamaño del nuevo proyecto pueden realizarse de forma lineal (se mantiene aproximadamente la proporcionalidad). Sin embargo, los plazos de tiempo no guardan una relación lineal con el esfuerzo o el tamaño del proyecto. Cuando se dispone de bastantes datos de proyectos terminados, se puede mejorar la analogía. Así, seleccionando dos proyectos parecidos al actual, uno mayor y otro menor, se puede obtener una mejor estimación interpolando los valores de ambos.

14 Métodos de Estimación 2. Estimación por analogía Ventaja: Basada en la experiencia real (no sólo en la subjetiva) de los proyectos. Desventaja: Es difícil conocer realmente el grado de similitud del proyecto que se estima con el terminado elegido. Su éxito depende de contar con una buena colección de datos de proyectos (por otra parte, esto es esencial para el buen funcionamiento de todos los métodos de estimación).

15 Métodos de Estimación Métodos para la estimación de costes: 1. Juicio de expertos 2. Estimación por analogía 3. Estimación por descomposición 4. Otros: Precio para ganar

16 Métodos de Estimación 3. Estimación por descomposición El responsable de cada componente del software estima el coste de su desarrollo. La estimación se calcula mediante la suma de las cantidades parciales (enfoque abajo-arriba o bottom-up). Para poder aplicarla con una mínima eficacia: Se necesita disponer de un diagrama de descomposición del producto (WBS del producto) que representa la jerarquía del producto. Suele complementarse con un diagrama de descomposición de actividades (WBS del trabajo) que indica la jerarquía de tareas. De esta manera se asegura que actividades como la integración de componentes o la gestión de la configuración queden reflejadas en la estimación del coste.

17 Métodos de Estimación 3. Estimación por Descomposición Ventajas: Obliga a comprender mejor la tarea a desarrollar Permite a cada componente del equipo de desarrollo planear su trabajo, asegurando el compromiso personal de cada uno con la estimación obtenida Desventajas (proceden de la dificultad para considerar dos posibles fuentes adicionales de coste (Boehm, 1981)): Actividades relacionadas con el proyecto que no suelen incluirse en la definición del mismo. Actividades no relacionadas con el proyecto.

18 Índice 1. Planificación 1.1. Conceptos generales 1.2. Actividades 1.3. Técnicas 2. Estimación de costes 2.1. Métodos de estimación 2.2. Modelos de estimación 2.4. Enfoque recomendado 3. Seguimiento y supervisión 3.1. Supervisión de resultados 3.2. Acciones correctivas 4. Gestión de Riesgos

19 Barbara Kitchenham (Fenton, 1991) distingue dos tipos de modelos de estimación: Modelos de costes. Proporcionan estimaciones directas del esfuerzo o de la duración. La mayoría son modelos de factores empíricos que cuentan con una parte principal (habitualmente, una medida del tamaño del producto) y un cierto número de factores de ajuste. Ej. COCOMO (Boehm, 1981). Modelos de restricciones. Muestran las relaciones en el tiempo entre dos o más parámetros de coste (ej. esfuerzo, duración y nivel de plantilla). Los basados en el modelo de curva de Rayleigh son un caso típico de modelos de restricciones Ej. SLIM (Putnam, 1978).

20 E. Mills (Mills, 1988), en función de la base empleada para la construcción de los modelos, distingue: 1. Modelos empíricos. Basados en la opinión de expertos y la estimación, tanto top-down como bottom-up, apoyada en datos históricos. 2. Modelos estadísticos. Obtenidos mediante el análisis de regresión estadística sobre los datos recogidos de una gran cantidad de proyectos: Modelos lineales. La relación del esfuerzo con los distintos atributos del software es de tipo lineal. Modelos no lineales. Están constituidos por ecuaciones, en general, exponenciales respecto al tamaño del software que se desea construir, medido en número de líneas de código (LDC). 3. Modelos basados en una teoría. Se apoyan en alguna teoría previa sobre el esfuerzo de desarrollar software. Ej. SLIM (Putnam, 1978). 4. Modelos compuestos. Combinación de distintas técnicas. Ej. COCOMO (Boehm, 1981)

21 Modelos de estimación: 1. COCOMO 2. Puntos Función 3. Críticas a los modelos

22 1. COCOMO COnstructive COst Model (Modelo Constructivo de Costes). Barry Boehm(1981): COCOMO 81. Es el modelo de estimación de costes del SW más utilizado. En 1995 se publicó la versión COCOMO II, actualmente en vigor. Sus autores (Center for Software Engineering, University of Southern California) pretenden mejorar, ampliar y adaptar el modelo anterior a las nuevas formas en que se desarrolla el software: Nuevas aproximaciones: desarrollo evolutivo, dirigido a riesgos, colaborativo. Nuevos entornos: 4GL's, generadores de aplicaciones, orientación a objetos,... Nuevos paradigmas: reusabilidad, madurez, calidad total,...

23 1. COCOMO Se apoya en una estimación previa del tamaño del software en Líneas de Código (LDC). Este dato sirve como parámetro de las ecuaciones de cálculo de esfuerzo: Esfuerzo = a (KLDC)b El esfuerzo se mide en personas-mes KLDC es el tamaño en miles de líneas de código a y b son los parámetros de ajuste según el tipo de desarrollo del proyecto

24 1. COCOMO Tres modos de desarrollo de proyectos software: 1. Orgánico. Desarrollo en un entorno estable, con poca innovación técnica, con pocas presiones de tiempo y tamaño relativamente pequeño (< 50 KLDC). Aéreas específicas y bien conocidas por el equipo. 2. Empotrado (restringido). Desarrollo de software con requisitos muy restrictivos, con gran volatilidad de requisitos, complejo, en un entorno con gran innovación técnica. Participan muchas personas y se requiere un alto grado de fiabilidad. 3. Semi-libre (semi-empotrado). Situaciones entre el modo orgánico y el empotrado. El nivel de experiencia del equipo de desarrollo se sitúa en niveles intermedios y suelen ser sistemas con interfaces con otros sistemas, siendo su tamaño menor a 300 KLDC.

25 1. COCOMO Jerarquía de modelos de estimación según el nivel de detalle empleado en su utilización: 1. COCOMO básico 2. COCOMO intermedio 3. COCOMO detallado

26 1. COCOMO 1.COCOMO básico: Para estimaciones al inicio del proyecto cuando no se dispone de detalles. Por ejemplo, al empezar a negociar el contrato Moderadamente preciso Se calcula el esfuerzo en función del tamaño del software (LDC), aplicando la ecuación básica.

27 1. COCOMO 2. COCOMO intermedio: Cuando tenemos identificados los principales componentes del sistema. Por ejemplo, cuando se dispone de una especificación de requisitos más o menos terminada. Se estima el coste de dichos componentes: 1) Aplicando la ecuación básica para obtener el esfuerzo o el tiempo de desarrollo. Este desarrollo se denomina nominal, ya que no está adaptado a las características del entorno de desarrollo. 2) Este esfuerzo nominal se ajusta incorporando la influencia de 15 factores de coste.

28 Valor de los factores (cost drivers) Factores (cost drivers) Muy bajo Bajo Medio Alto Muy alto Extra Fiabilidad requerida (producto) 0,75 0,88 1,00 1,15 1,40 Tamaño de la base de datos (producto) 0,94 1,00 1,08 1,16 Complejidad del software (producto) 0,70 0,85 1,00 1,15 1,30 1,65 Restricciones de tiempo de ejecución (hardware) 1,00 1,11 1,30 1,66 Restricciones de memoria (hardware) 1,00 1,06 1,21 1,56 Volatilidad del hardware (hardware) 0,87 1,00 1,15 1,30 Restricciones de tiempo de respuesta (hardware) 0,87 1,00 1,07 1,15 Calidad de los analistas (personal) 1,46 1,19 1,00 0,86 0,71 Experiencia con el tipo de aplicación (personal) 1,29 1,13 1,00 0,91 0,82 Experiencia con el hardware (personal) 1,21 1,10 1,00 0,90 Experiencia con el lenguaje de prog. (personal) 1,14 1,07 1,00 0,95 Calidad de los programadores (personal) 1,42 1,17 1,00 0,86 0,70 Técnicas modernas de programación (proyecto) 1,24 1,10 1,00 0,91 0,82 Empleo de herramientas (proyecto) 1,24 1,10 1,00 0,91 0,83 Restricciones a la duración del proyecto (proyecto) 1,23 1,08 1,00 1,04 1,10

29 1. COCOMO 3. COCOMO detallado: Cuando están identificados los componentes individuales del sistema. Por ejemplo, cuando se dispone de una especificación de requisitos totalmente acabada o cuando el diseño general está bien definido En este caso, el modelo COCOMO proporciona tablas para poder distribuir las cantidades, ajustadas al entorno, del esfuerzo y del tiempo de desarrollo del proyecto, a lo largo de las distintas fases del mismo. Incluso se permite refinar el ajuste de los factores para adaptarlo a las peculiaridades de cada etapa del proyecto. COCOMO permite estimar también el coste del mantenimiento del software.

30 Modo de desarrollo ED:Esfuerzo de Desarrollo (nominal) Personas-mes TD: Tiempo de desarrollo (nominal) Orgánico PM = 3.2 KLDC 1.05 TD = 2.5 PM 0.38 Semi-libre PM = 3.0 KLDC 1.12 TD = 2.5 PM 0.35 Empotrado PM = 2.8 KLDC 1.20 TD = 2.5 PM 0.32 Ecuaciones para el cálculo del esfuerzo y el tiempo de desarrollo para COCOMO INTERMEDIO

31 Orgánico Semiempotrado Empotrado Esfuerzo de desarrollo Para COCOMO básico Tiempo de desarrollo ED=2,4(KLDC)1,05 pm ED=3,0(KLDC)1,12 pm ED=3,6(KLDC)1,20 pm TD=2,5(ED)0,38 m TD=2,5(ED)0,35 m TD=2,5(ED)0,32 m Productividad Nº medio de personas a tiempo completo Esfuerzo De mantenimiento PR = LDC/ED FSP (Full-Time equivalent Software Personel) PE= ED/ TD p TCA (Tráfico de cambio anual): porción de instrucciones fuente que sufren algún cambio durante un año, bien sea por adición o por modificación. Se calcula como LDC que varían/ldc totales EM = TCA x ED Y por tanto el valor medio del número de personas a tiempo completo, dedicadas a mantenimiento durante 12 meses sería: PEM= EM/12 pm--- Personas/Mes m----mes p---personas

32 1. COCOMO Ejemplo: a) Se trata de estimar el esfuerzo de desarrollo de un sistema de comunicaciones de 30 KDLC, de alta complejidad. Afortunadamente podremos emplear personal de muy alta calificación con una gran experiencia específica en este tipo de software. b) Sabiendo que el coste del salario mensual de cada persona es de pts./mes Sería más rentable emplear a personas de nivel medio cuyo salario es pts.?

33 Solución ejemplo: KLDC<50 Modo orgánico ED=3,2 KLDC 1,05 Esfuerzo nominal = 3,2 Ajustando el esfuerzo nominal (30) 1,05 = 113,79 personas-mes. Esfuerzo = 113,79 1,15 (complejidad) 0,70 (personal) 0,91 (experienc.) ED= Esfuerzo = 83,35 personas-mes TD= 2,5 PM 0,38 TD= Tiempo = 2,5 83, = 13,42 meses PE= ED/TD Nº medio de personas = 83,35/13,42 = 6,2 personas

34 Solución ejemplo: El esfuerzo nominal no varía: ED= Esfuerzo = 83,35 personas-mes Coste = 83, = pts. ED= 113,79 personas-mes Ajustando el esfuerzo nominal Esfuerzo = 113,79 1,15 (complejidad) 0,91 (experienc.) ED = 119,08 personas-mes Coste = 119, = pts. (es más caro)

35 1. COCOMO II Modelos de Estimación En 1995 se publicó la versión COCOMO II. Objetivos: Desarrollar un modelo de estimación de costes y tiempos en consonancia con las prácticas actuales de ciclo de vida del software. Construir una base de datos y una herramienta de costes del software que incluya capacidades para la mejora continua del modelo. Proveer un marco analítico cuantitativo, y un conjunto de herramientas y técnicas para evaluar los efectos de las mejoras en la tecnología software sobre los costes y tiempos del ciclo de vida del software.

36 1. COCOMO II Mantiene una jerarquía de modelos en función de la fase de desarrollo en la que se desea estimar: Modelo de composición de aplicaciones (ACM) Modelo de diseño preliminar (EDM) Modelo posterior al diseño de arquitectura (PAM):

37 1. COCOMO II Los modelos COCOMO II requieren información de tamaño. Tres opciones diferentes: Puntos Objeto (PO) Puntos función (PF) Líneas de código fuente (LNDC)

38 1. COCOMO II Modelos de Estimación Modelo de Composición de Aplicaciones ACM (Application Composition Model): Se usa para estimaciones iniciales, para SW construido con componentes e interfaz gráfica de usuario. Esta adaptado a la información normalmente conocida al planificar un producto de este sector (composición de aplicaciones) y al nivel de exactitud requerido. Estas aplicaciones suelen ser desarrolladas por un equipo reducido de personas durante varias semanas o meses.

39 1. COCOMO II Modelo ACM: Para la estimación se basa en Puntos Objeto (PO). Se utiliza como medida de tamaño los puntos de objeto en función de: Pantallas, informes y componentes (3GL) requeridos para construir la aplicación. Cada instancia de objeto (por ejemplo, una pantalla o informe) se clasifica en base a tres niveles de complejidad: Simple, medio y difícil, en función de las vistas o secciones presentadas como parte de la pantalla o informe, de las tablas de datos del cliente y de los servicios requeridos para generar la pantalla o informe.

40 1. COCOMO II Modelos de Estimación Una vez determinada la complejidad se pondera en base a la siguiente tabla Tipo de objeto Peso de la complejidad Simple Medio Difícil Pantalla Informe Componente 3GL 10

41 1. COCOMO II El número de puntos de objeto se calcula como la suma del total de puntos de objeto multiplicado por su factor de ponderación. PO= O x FP Siendo: O cada instancia de puntos de objeto FP el factor de ajuste A continuación, el número de puntos de objetos se corrige en función de la reutilización de componentes: NPO= PO x ((100-%reutilización)/100) A continuación, se calcula la tasa de productividad: PROD= NPO/persona-mes Calculo de la estimación del esfuerzo: Esfuerzo= NPO/PROD

42 1. COCOMO II Modelos de Estimación Modelo de diseño preliminar EDM (Early Design Model): Usado en las etapas iniciales cuando se conoce poco sobre el tamaño del producto, la plataforma, el personal o el proceso. La estimación de tamaño se basa en puntos de función no ajustados. Utiliza 7 conductores de coste (cost drivers) que afectan multiplicativamente al coste del proyecto (por ejemplo, capacidad del personal). Trabaja con un nivel de detalle consistente con la información disponible y el nivel general de exactitud necesarios en la etapa de diseño inicial.

43 1. COCOMO II Modelo posterior al diseño de la arquitectura PAM (Post- Architecture Model): Orientado a las etapas de desarrollo y mantenimiento de un producto SW. Se basa en convertir los puntos de función no ajustados a KLDC para aplicar un modelo parecido al COCOMO original donde los cost drivers se han reformado bastante. Se debe conocer la arquitectura del ciclo de vida para: Proveer información más exacta sobre los generadores de costes Permitir una estimación de costes más exacta. Utiliza instrucciones de código fuente (similar a las LDC) y/o PF. Incluye modificadores del tamaño para valorar la reusabilidad y otros aspectos. Incorpora 17 conductores de coste (en vez de los 7 de EDM), y 5 factores que afectan exponencialmente al coste del proyecto.

44 1. COCOMO II Ecuación básica de los modelos EDM y PAM para calcular el esfuerzo en personas-mes (PM) necesario para desarrollar un software: PM= A x (Size) B Siendo: Size = tamaño en KLCDF (miles de LDCF) de la aplicación, igual a la suma total de los tamaños estimados de todos los módulos. Si el tamaño se estima en PFNA, éstos se deben convertir a LDCF con las tablas ya vistas. A = constante de calibración (su valor actual es 2'45). B = factor de escala para tener en cuenta las diversas economías de escala, positivas o negativas, existentes en proyectos software. Su valor depende de 5 factores de escala, asignando a cada uno un peso de 0 (muy alto) a 5 (muy bajo). B= 0,91 + 0,01 x W i (desde i=1 hasta 5)

45 Modelos de estimación: 1. COCOMO 2. Puntos Función 3. Críticas a los modelos

46 2. Puntos función Es la técnica algorítmica de estimación del tamaño de un producto software más conocida. Propuesta por Albercht en 1979 y mejorada en 1983 para la estimación de costes Utiliza un modelo paramétrico (lista de parámetros) orientado hacia las aplicaciones de gestión Un punto función (PF) es una medida sintética del tamaño de un programa. La estimación del número de PF de un producto software pretende medir su funcionalidad y no el número de LDC.

47 2. Puntos función Modelos de Estimación El método de estimación de costes mediante los puntos de función ha sido denominado FPA o Análisis de Puntos de Función (Function Point Analysis). Este método se basa no en las LDC sino en una métrica que cuantifica la funcionalidad que hay que entregar al usuario al construir una aplicación. Dicha métrica se denomina puntos de función. Todas las variedades de puntos de función se apoyan en datos que implican, preferentemente, la existencia de una especificación más o menos formalizada.

48 2. Puntos función Los pasos a seguir son: 1)Calcular los Puntos Función no ajustados (PFNA) 2)Ajustar lo anterior para tener en cuenta la complejidad del proceso.

49 2. Puntos función 1)Calcular los Puntos Función no ajustados (PFNA): 1.1) Contar el número de funciones de usuario. Los parámetros que sirven de base son: número de entradas, número de salidas, número de ficheros lógicos internos, número de ficheros de interfaz externos y número de consultas externas 1.2) Determinar el nivel de complejidad (baja, media, alta) de cada función de usuario. Para ello se tienen en cuenta el número de tipos de elementos de datos y el número de tipos de archivos (o de elementos de tipo registro) referenciados. 1.3) Aplicar pesos de complejidad, según el nivel complejidad. La suma ponderada de todas estas cantidades equivale al nº de PFNA.

50 2. Puntos función Modelos de Estimación Parámetro significativo Complejidad baja Complejidad media Complejidad alta Entradas x 3 x 4 x 6 Salidas x 4 x 5 x 7 Ficheros internos lógicos x 7 x 10 x 15 Ficheros de interfaz externos x 5 x 7 x 10 Consultas externas x 3 x 4 x 6 Puntos de función no ajustados Total parámetro

51 2. Puntos función 2. Ajustar el valor obtenido a las características del proyecto Se utiliza un Factor de Complejidad (FA). Existen 14 factores que contribuyen a la complejidad de una aplicación. Se valora cada uno de ellos en una escala del 0-5 en función de las características del sistema. Factores de complejidad (FC) 0-5 Factores de complejidad (FC) 0-5 Comunicación de datos Rendimiento Frecuencia de transacciones Requisitos de manejo del usuario Funciones distribuidas Gran carga de trabajo Entrada on-line de datos Actualizaciones on-line final Procesos complejos Facilidad de mantenimiento Instalación en múltiples lugares Utilización con otros sistemas Facilidad de operación Facilidad de cambio

52 2. Puntos función El factor de ajuste de complejidad (FA) se calcula, a partir de la suma de los valores de los 14 factores de complejidad (FC), según la siguiente fórmula: FA = (0.01 FC) El factor FA puede oscilar entre 0,65 y 1,35, es decir, permite una variación máxima de 35% sobre el valor de los PFNA: Puntos de función (PF) = PFNA FA

53 Criterios de IFPUG para evaluar la complejidad de elementos de cálculo en los puntos de función Para ficheros lógicos internos y externos Para salidas y consultas Para entrada Registros Datos elementales Tipos de Datos elementales Tipos de Datos elementales elementales >51 ficheros >20 ficheros >16 1 Baja Baja Media 0-1 Baja Baja Media 0-1 Baja Baja Media 2-5 Baja Media Alta 2-3 Baja Media Alta 2-3 Baja Media Alta >6 Media Alta Alta >4 Media Alta Alta >3 Media Alta Alta

54 PF: equivalencia con LDC Lenguaje (o entorno de programación) 4GL 40 Ada Ada APL 32 BASIC - compilado 91 BASIC -interpretado 128 BASIC ANSI/Quick/Turbo 64 C 128 C++ 29 Clipper 19 Cobol ANSI Delphi 1 Ensamblador 320 Ensamblador (Macro) 213 LDC/PF

55 Lenguaje LDC/PF Forth 64 Fortran FoxPro Generador de Informes 80 Hoja de Cálculo 6 Java 53 Modula 2 80 Oracle 40 Oracle Paradox 36 Pascal 91 Pascal Turbo 5 49 Power Builder 16 Prolog 64 Visual Basic 3 32 Visual C++ 34 Visual Cobol 20

56 Modelos de estimación: 1. COCOMO 2. Puntos Función 3. Críticas a los modelos

57 3. Criticas a los modelos de costes Los que dependen del NLDC tienen el inconveniente de que hay que calcular de alguna manera este parámetro. Los modelos surgen del análisis estadístico de datos de proyectos. El problema es que la cantidad y representatividad de proyectos no es tan amplia como sería deseable. Los modelos pierden bastante precisión al utilizarse en entornos distintos de aquéllos en los que se crearon. Los factores de coste son difíciles de cuantificar y se consideran independientes aunque no necesariamente lo son. Aunque hay guías para aplicar de manera uniforme y consistente los modelos, existe un alto grado de subjetividad en la estimación. Tienen un cierto margen de error que, en algunos casos, es aceptable aunque, lamentablemente, en otros llega a cifras muy malas.

58 Índice 1. Planificación 1.1. Conceptos generales 1.2. Actividades 1.3. Técnicas 2. Estimación de costes 2.1. Métodos de estimación 2.2. Modelos de estimación 2.4. Enfoque recomendado 3. Seguimiento y supervisión 3.1. Supervisión de resultados 3.2. Acciones correctivas 4. Gestión de Riesgos

59 Enfoque Recomendado La estimación de costes se debe basar en el desarrollo de modelos y procedimientos de estimación apropiados a las características de cada organización. Esto significa que siempre hay que recoger datos de los proyectos desarrollados y crear procedimientos de estimación que puedan cambiarse a medida que se analizan los datos recogidos. En general, no es bueno ceñirse a un sólo método de estimación.

60 Enfoque Recomendado En general, se recomienda: Primeras estimaciones: apoyarse en el juicio de expertos con técnica Delphi. Que los expertos constituyan un grupo específico más o menos permanente. Con especificaciones detalladas y se puede medir su tamaño: evaluar cada caso. Lo más normal es aplicar modelos o ecuaciones de costes. Conviene aplicar modelos o ecuaciones locales, es decir, no tomar sin más modelos desarrollados en otros entornos. Es preferible adaptarlos o crear ecuaciones propias. Mejorar y refinar continuamente los métodos y las ecuaciones, informando a los expertos de los resultados obtenidos y corrigiendo las fórmulas.