ESTIMACION DE COSTOS Expositores: José Alejandro Benítez A Sandra Milena Ruiz Catherine Ramírez C Rosa Marcela Viteri Claudia Patricia Martínez S Desarrollo de Software II – Universidad del Valle 2005

INTRODUCCION Al principio el costo del software constituía un pequeño porcentaje del costo total de los sistemas basados en computadoras. Hoy en día, el software es el elemento más caro de la mayoría de los sistemas informáticos. El costo de un proyecto es de interés continuo y vital para los integrantes, se han desarrollado varios métodos que han encontrado aceptación comercial. Desarrollo de Software II – Universidad del Valle 2005

ESTIMACION DE COSTOS Para realizar estimaciones seguras de costos y esfuerzos se tienen varias opciones posibles : * Dejar la estimación para más adelante. * Basar las estimaciones en proyectos similares ya terminados. * Utilizar “técnicas de descomposición” relativamente sencillas para generar la estimación de costo. * Desarrollar un modelo empírico. Desarrollo de Software II – Universidad del Valle 2005

ESTIMACION DE COSTOS El proceso de estimar los costos se realizan con el fin de evaluar las capacidades del grupo desarrollador, control de calidad y programaciones fijas. Los modelos de estimación actual (COCOMO), solo consideran modelos clásicos de desarrollo de software propietario, cuyas diferencias con los software libres radica en: * Proceso continuo de distribuciones. * Proceso continuo de distribuciones. * Control y solución de errores. * Reutlización, evolución e intercambio del código. * Modelo de desarrollo distribuido. Desarrollo de Software II – Universidad del Valle 2005

MODELO EMPIRICO Es necesario contar con registros de proyectos concluidos, con sus tamaños estimados en puntos de función para estimación temprana y el esfuerzo de desarrollo. Método de regresión lineal Método de regresión lineal Costo = f (tamaño del software) Así, el costo E es función del tamaño T, de la forma: Así, el costo E es función del tamaño T, de la forma: E = a + b. T Desarrollo de Software II – Universidad del Valle 2005

RECURSOS A TENER EN CUENTA EN LA ESTIMACION DE COSTOS DE UN PROYECTO El software al ser intangible, no tener peso, ni volumen, ni superficie, etc. Se mide a través de diversos aspectos claves en el desarrollo como: * Recursos Humanos. * Recursos de software reutilizables. * Recursos de entorno. * Materiales. * Misceláneos * Licencias Desarrollo de Software II – Universidad del Valle 2005

RECURSOS HUMANOS La cantidad de personas requeridas para el desarrollo de un proyecto de software, se determina : * Después de hacer una estimación de esfuerzo de desarrollo. * Seleccionar la posición dentro de la organización. * Costos que la empresa de software efectúa directa o indirectamente al personal, ya sea a través de su salario, honorarios, servicios temporales, etc. Desarrollo de Software II – Universidad del Valle 2005

RECURSOS HUMANOS Desarrollo de Software II – Universidad del Valle 2005

RECURSOS DE SOFTWARE REUTILIZABLES Para un estudio completo de estimación de costos se hace necesario estudiar la reutilización de bloques de construcción de software. Se debe tener en cuenta: Componentes ya desarrollados. Componentes ya desarrollados. Componentes ya experimentados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes con experiencia Parcial. Componentes nuevos. Componentes nuevos. Desarrollo de Software II – Universidad del Valle 2005

RECURSOS DE ENTORNO El entorno es donde se apoya el proyecto de software, llamado a menudo entorno de ingeniería de software. Incorpora: El hardware El software El líder del proyecto debe verificar que estos recursos estén disponibles y especificar cada elemento de hardware necesarios. Desarrollo de Software II – Universidad del Valle 2005

RECURSOS MATERIALES Materiales que son utilizados por la empresa de desarrollo de software para la iniciación, operación y mejora de la eficiencia en la prestación de los servicios. Algunos de los recursos materiales son : Útiles de escritorio y papelería. Equipos de computo. Muebles y enseres Vehículos, etc. Desarrollo de Software II – Universidad del Valle 2005

RECURSOS MICELANEOS Recursos que no han sido clasificados en los grupos anteriores (personal, materiales, entorno y componente de software reutilizable). Desarrollo de Software II – Universidad del Valle 2005

La métrica del software es un factor realmente importante en el análisis de un proyecto. A continuación hablaremos de las métricas utilizadas para la estimación de costos de software estas son: La métrica del software es un factor realmente importante en el análisis de un proyecto. A continuación hablaremos de las métricas utilizadas para la estimación de costos de software estas son: Las métricas orientadas a tamaño Las métricas orientadas al tamaño proporcionan medidas directas del software y del proceso por el cual se desarrolla. Algunas de las mas utilizadas son: Las métricas orientadas al tamaño proporcionan medidas directas del software y del proceso por el cual se desarrolla. Algunas de las mas utilizadas son: LOC (LINE OF CODE) LOC (LINE OF CODE) El fundamento de la medida LOC es que la longitud del programa se puede utilizar como pronostico de las características del programa tal como el esfuerzo y la facilidad del mantenimiento. La medida del LOC se utiliza para medir el tamaño del software. El fundamento de la medida LOC es que la longitud del programa se puede utilizar como pronostico de las características del programa tal como el esfuerzo y la facilidad del mantenimiento. La medida del LOC se utiliza para medir el tamaño del software. Las ventajas del LOC son: 1. simple para medir METRICAS Desarrollo de Software II – Universidad del Valle 2005

Las desventajas del LOC son: 1. se define en código. Por ejemplo no puede medir tamaño de especificación 2. caracteriza solamente una vista especifica del tamaño, no tiene en cuenta la funcionalidad o la complejidad 3. el mal diseño del software puede causar líneas excesivas de código 4. es dependiente de la lengua 5. los usuarios no pueden entenderlo fácilmente Se han propuesto multitud de unidades de medida del volumen, cada una de las cuales define a su vez un procedimiento para medir el sistema. Se han propuesto multitud de unidades de medida del volumen, cada una de las cuales define a su vez un procedimiento para medir el sistema. Entre las más difundidas se encuentran (vamos a emplear sus siglas en inglés, ya que son más conocidas) : Entre las más difundidas se encuentran (vamos a emplear sus siglas en inglés, ya que son más conocidas) : Desarrollo de Software II – Universidad del Valle 2005

Los Bytes necesarios para almacenar el código fuente (Bytes de ocho bits) Los Bytes necesarios para almacenar el código fuente (Bytes de ocho bits) Las líneas de código fuente SLOC (Source Lines Of Code) Las líneas de código fuente SLOC (Source Lines Of Code) existe una herramienta para medir el SLOC la cual es llamada Sloccount, que tiene una definición propia de “líneas de código fuente físicas”, por lo tanto se puede decir que se contabiliza un SLOC cuando esta herramienta lo hace, si bien sloccount ha sido cuidadosamente diseñado para responder a la definición habitual de SLOC físicas: " una línea física de código fuente es una línea que acaba en un marcador de nueva línea o de fin de fichero, y que contiene al menos un carácter que no es un espacio en blanco ni un comentario." Líneas de código fuente sin comentarios (NCSLOC, Non Comentary Source Lines Of Code) Líneas de código fuente sin comentarios (NCSLOC, Non Comentary Source Lines Of Code) SIZE1= Es una variación de la tradicional LOC (Líneas de Código) SIZE1= Es una variación de la tradicional LOC (Líneas de Código) SIZE2 = número de atributos + número de métodos locales. SIZE2 = número de atributos + número de métodos locales. Desarrollo de Software II – Universidad del Valle 2005

Métrica Basada en la Funcionalidad Métrica Basada en la Funcionalidad El tamaño del SW podría medirse en términos de los bytes que ocupa en el disco, el número de programas, el número de líneas de código, la funcionalidad que proporciona, o simplemente el número de pantallas o reportes que tiene. A simple vista podríamos intuir que algunas de estas propuestas son mejores que otras si queremos medir el tamaño de una forma que tenga más correlación con el esfuerzo. Pero antes de seleccionar alguna, hagamos otras consideraciones. Una aplicación de software es un conjunto de líneas de código que se ejecutan en una computadora. Sin embargo mucho del costo de producir ese SW no está directamente relacionado con la codificación, que es entre el 20 y 25% del costo total. Elementos como la administración del proyecto, el nivel de detalle de la documentación técnica o la documentación de pruebas, y las pruebas por sí mismas también deben considerarse. Por otro lado, hoy en día hay una amplia gama de lenguajes y herramientas para producir SW, lo que ha provocado que pueda generarse la misma funcionalidad con lenguajes de programación distintos. Y esto con un número de líneas de código distintos y, lo que es más impactante, con un esfuerzo distinto. Desarrollo de Software II – Universidad del Valle 2005

Métrica Basada en la Funcionalidad (cont.) Métrica Basada en la Funcionalidad (cont.) Veamos un poco más a detalle las implicaciones del enunciado anterior mediante un ejemplo sencillo. Supongamos que yo requiero de cierta funcionalidad en una aplicación de SW y tengo la opción de hacerlo con dos empresas. La empresa A utiliza un lenguaje que requeriría 8 mil líneas de código. La empresa B utiliza otro lenguaje que requeriría aproximadamente 5 mil líneas de código. A simple vista parecería que con la empresa A tendría “más” trabajo y con la empresa B me podría salir más barato, dado que tienen que hacer menos líneas de código. Pero la comparación se complica si los programadores de ambas empresas producen a distintas velocidades. Es decir, los de la compañía A producen casi el doble de código por día que los de la compañía B. Como resultado de lo anterior, tendría que la línea de código de la empresa A podría costar mucho menos que la de la compañía B. Entonces parecería que debería comprarle a la empresa A dado que cuesta menos cada línea de código, pero también podría comprarle a la empresa B dado que tiene que producir menos líneas de código, y por lo tanto el costo total sería menor o podría tener menos posibilidad de errores. Desarrollo de Software II – Universidad del Valle 2005

Métrica Basada en la Funcionalidad (cont.) Ciertamente esta secuencia de análisis puede ser engañosa. Si retomamos los conceptos mencionados previamente, entonces una mejor métrica para establecer el tamaño es la basada en los requerimientos del usuario y no en la tecnología que se va a utilizar; una métrica basada en la funcionalidad. Características de una métrica funcional A continuación mencionaré las características principales de una métrica funcional que nos ayudarán a entender mejor los beneficios de este tipo de métrica. INDEPENDIENTE DE LA TECNOLOGÍA INDEPENDIENTE DE LA TECNOLOGÍA SIMPLE SIMPLE ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA ENFOQUE EN LA FUNCIONALIDAD PROPORCIONADA BASADA EN LOS REQUERIMIENTOS DEL USUARIO BASADA EN LOS REQUERIMIENTOS DEL USUARIO CONSISTENCIA CONSISTENCIA Usos de una Métrica Funcional Estándar Una vez que tengo el tamaño de un SW, entonces puedo utilizar ese dato para distintos propósitos. La siguiente lista es más enunciativa que limitativa. Desarrollo de Software II – Universidad del Valle 2005

Usos de una Métrica Funcional Estándar (cont.) Usos de una Métrica Funcional Estándar (cont.) Administrar la productividad Administrar la productividad Administración de calidad Administración de calidad Comparabilidad Comparabilidad Administración de proyectos Administración de proyectos Administrar los cambios en el alcance Administrar los cambios en el alcance Estimar la adecuación de un paquete Estimar la adecuación de un paquete Valuar el SW de una organización Valuar el SW de una organización Estimar los recursos para un proyecto Estimar los recursos para un proyecto Presupuestar el mantenimiento Presupuestar el mantenimiento Administrar contratos Administrar contratos Desarrollo de Software II – Universidad del Valle 2005

CATEGORIA DE UN PROYECTO Grandes SO 100k – 1M 4 – 5 Años MuyGrande Sistema de Distribución > 1M 5 – 10 años Gigante SO pequeño 50k – 100k 2 – 3 años Grande Compilador de C 3k – 50k ½ - 2 años Media Biblioteca de funciones 1k – 3k 1 – 6 Meses1Pequeño Utilidad de ordenación < 1k 0 – 4 semanas1TrivialEjemplo Líneas de CódigoDuraciónProgramadoresCategoría Desarrollo de Software II – Universidad del Valle 2005

CARACTERISTICAS QUE DEBE POSEER UN MODELO DE ESTIMACION a.Poder adaptarse a la productividad de la organización. b.Considerar el costo de comunicación entre personas. c.Incorporar guías útiles para estimar aquellos parámetros que son subjetivos o no se deducen en forma explícita a partir del modelo. d.Usable. Desarrollo de Software II – Universidad del Valle 2005

e. Constar de etapas simples de entender y definidas en forma precisa. f. Objetivo. g. Costo efectivo. h. Proveer medios para adaptarse a cambios en el ambiente de desarrollo. i. Permitir una estimación temprana, disminuyendo el costo de obtener registros de proyectos terminados en la organización. Desarrollo de Software II – Universidad del Valle 2005

ESTIMACION JERARQUICA HACIA ARRIBA Estima los costos globales a partir de los de las partes Ejemplo: Un proyecto de un juego se compara con una simulación hecha anteriormente Simulación: tiene una cola de 120 a 400 líneas Nuestro Juego: tiene de 4 a 15 colas de este tipo Desarrollo de Software II – Universidad del Valle 2005

ESTIMACION JERARQUICA HACIA ABAJO Estima los costos de las partes a partir de los costos globales. Ejemplo: Nuestro juego se compara con otro juego muy bueno Desarrollo de Software II – Universidad del Valle 2005

MODELO COCOMO Constructive Cost Model, desarrollado por Boehm Usa el número de líneas de código (LDC) para estimar la mano de obra y la duración de desarrollo. Un producto se debe comparar con otros para estimar el numero de líneas de código. Desarrollo de Software II – Universidad del Valle 2005

JERARQUIA DE MODELOS COCOMO Básico, Intermedio y avanzado. Se aplica a tres diferentes tipos de software: Orgánico : proyectos sencillos Semiacoplado: proyectos intermedios Empotrado: proyectos bastante complejos Desarrollo de Software II – Universidad del Valle 2005

MODELO BASICO Estimar de manera rápida y sencilla proyectos pequeños y medianos E = Esfuerzo = a KLDC personas-mes T = Tiempo de duración de desarrollo = c E b d 0,322,5 1,20 3,6Empotrado 0,352,5 1,12 3,0Semiacoplado 0,382,5 1,05 2,4Orgánico dc a Proyecto de software b Desarrollo de Software II – Universidad del Valle 2005

MODELO INTERMEDIO Calcula el esfuerzo de desarrollo de software en función del tamaño del programa y de los atributos del proyecto. Se tienen 15 atributos de costo para tener en cuenta el entorno de trabajo E = Esfuerzo = a KLDC m(x) personas-mes m(x) es un multiplicador que depende de los 15 atributos b Desarrollo de Software II – Universidad del Valle 2005

Para los tres modos: Orgánico, Semiacoplado y Empotrado se utilizan las mismas ecuaciones que en el modelo básico pero variando los coeficientes a y b: Según la Tabla: 1,202,8Empotrado 1,123,0Semiacoplado 1,053,2Orgánico a Proyecto de software b Desarrollo de Software II – Universidad del Valle 2005

Los 15 atributos de costo son: Cada atributo se cuantifica para un entorno de proyecto la escala es: Muy bajo – bajo – nominal – alto – muy alto – extremadamente alto Atributos del Producto: RELY : Garantía de funcionamiento requerida al software DATA: Tamaño de la base de datos CPLX: Complejidad del Producto Atributos del Ordenador: TIME: Restricción de tiempo de ejecución STOR: Restricción del almacenamiento principal VIRT: Volatilidad de la maquina virtual TURN: Tiempo de respuesta del ordenador Desarrollo de Software II – Universidad del Valle 2005

Atributos del Personal: ACAP: Capacidad del analista AEXP: Experiencia de la aplicación PCAP: Capacidad del programador VEXP: Experiencia de maquina virtual LEXP: Experiencia en el lenguaje de programación Atributos del Proyecto : MODP: Prácticas de programación modernas TOOL: Utilización de herramientas del software SCED: Plan de desarrollo requerido - tiempo Desarrollo de Software II – Universidad del Valle 2005

MODELO AVANZADO Tiene las características del modelo intermedio y evalúa en cada etapa de desarrollo los atributos. Tiene 2 características: Multiplicadores de esfuerzo de acuerdo a la fase Jerarquía del producto a tres niveles: modulo, subsistema y sistema. Desarrollo de Software II – Universidad del Valle 2005

Las 4 fases de desarrollo son: Requerimientos: consume : 6 % al 8 % de E Y dura: 10 % al 40 % de T Y dura: 10 % al 40 % de TDiseño: consume : 16 % al 18 % de E Y dura: 19 % al 38 % de T Y dura: 19 % al 38 % de TCodificación: consume : 48 % al 68 % de E Y dura: 24 % al 64 % de T Y dura: 24 % al 64 % de TPruebas: consume : 16 % al 34 % de E Y dura: 18 % al 34 % de T Y dura: 18 % al 34 % de T Desarrollo de Software II – Universidad del Valle 2005

El Esfuerzo se obtiene A través de: Seleccionar los valores apropiados de los atributos de costo para cada fase 2. Multiplicar los atributos de costo para cada modulo o fase. 3. Multiplicar los atributos globales por el esfuerzo nominal Desarrollo de Software II – Universidad del Valle 2005

La Métrica de Puntos Función Esta métrica se define como una métrica funcional, dado que se enfoca a la funcionalidad que el SW proporciona al usuario. Esta métrica se define como una métrica funcional, dado que se enfoca a la funcionalidad que el SW proporciona al usuario. Es una métrica para establecer el tamaño y complejidad de los sistemas informáticos basada en la cantidad de funcionalidad requerida y entregada a los usuarios. Los Puntos Función miden el tamaño lógico o funcional de los proyectos o aplicaciones de software basados en los requerimientos funcionales del usuario. FUNCIONALIDAD – se refiere a la capacidad del SW para que un usuario pueda realizar transacciones (lectura, escritura, etc.) y el guardar datos. Si analizamos a detalle, con estos elementos podemos describir cualquier sistema Desarrollo de Software II – Universidad del Valle 2005

Estándar Internacional ISO La medición de la funcionalidad con la que cuenta un sistema informático ha sido desde hace años una preocupación de la industria. No es suficiente contar con una métrica, sino que sea estándar para así poderla usar entre empresas o para tener indicadores a nivel industria que todos puedan entender y operar. El poder comparar la productividad (Puntos Función por Persona Mes) de una empresa con los datos de la industria, es fundamental en los planes de mejora. Desarrollo de Software II – Universidad del Valle 2005

ISO/IEC – Information Technology – Software Measurement – Functional Size Measurement. Este estándar define los conceptos de una métrica de tamaño basada en la funcionalidad y las características que debe cumplir un método para poder estar homologado al estándar y ser considerado una medida del tamaño de la funcionalidad. Para poder establecer la cantidad de puntos función que tiene una aplicación, existen varios métodos de conteo. En general todos estos métodos establecen un conteo basado en la identificación del tipo de funciones que tiene la aplicación, y a cada una le asocia un número de puntos función tomando en cuenta su complejidad. Un sistema en tiempo real tiene una complejidad muy distinta a un sistema tradicional de negocio, o a un sistema operativo o a una aplicación científica que realiza muchos cálculos, pero el resultado puede ser un solo dato. Desarrollo de Software II – Universidad del Valle 2005

ISO ISO/IEC 20926:2003 IFPUG 4.1 Unadjusted functional size measurement method. “Metodo de medida de tamaño funcional sin ajustar.” Este método ha sido definido por el International Function Point Users Group (IFPUG13) y evolucionado es el más conocido y más utilizado, sobre todo en Estados Unidos que es el mercado más grande de SW. Esto es muy importante porque se está convirtiendo de facto en el estándar de la industria. Desarrollo de Software II – Universidad del Valle 2005

NESMA -- Function Point Analysis. Análisis de Punto de función Estándar definido por la Netherlands Software Metrics Users Association. Esta es una pequeña variante del método del IFPUG. ISO ISO/IEC Desarrollo de Software II – Universidad del Valle 2005

ISO ISO/IEC 20968:2002 Mk II Function Point Analysis. II Análisis de Punto de Función. Este método ha sido desarrollado por la United Kingdom Software Metrics Association. Simplificando el método y haciéndolo compatible con ideas de análisis y diseño estructurado. Desarrollo de Software II – Universidad del Valle 2005

ISO ISO/IEC 19761:2003 COSMIC-FFP -- A functional size measurement method. Un método de medida de tamaño funcional. Este método ha sido definido por el Common Software Measurement International Consortium, integrado por expertos de Australia, Canadá, Finlandia, Alemania, Irlanda, Italia Japón, Holanda y el Reino Unido. La idea principal es adecuarse mejor a la medición de sistemas en tiempo real. Desarrollo de Software II – Universidad del Valle 2005

El Método Estándar Análisis de Puntos Función El método que se está convirtiendo en el estándar de la industria es el definido por el IFPUG. Este método utiliza como unidad de medida puntos función y su versión actual es la El método se basa principalmente en la identificación de los componentes del sistema informático en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario en su negocio. Desarrollo de Software II – Universidad del Valle 2005

Procedimiento Paso 1. Determinar el tipo de conteo Este paso consiste en definir el tipo de conteo entre desarrollo, mantenimiento o de una aplicación ya instalada. Desarrollo de Software II – Universidad del Valle 2005

Procedimiento Paso 2. Identificar los alcances de la medición y los límites de la aplicación. El propósito de una medición consiste en dar una respuesta a un problema de negocio. El propósito de una medición consiste en dar una respuesta a un problema de negocio. Desarrollo de Software II – Universidad del Valle 2005

Procedimiento Paso 3. Contar las funciones de datos ● Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Paso 4. Contar las funciones transaccionales. ● Este paso consiste en identificar y contar la capacidad de realizar operaciones. Desarrollo de Software II – Universidad del Valle 2005

Procedimiento Paso 5. Determinar los puntos de función no ajustados. Este paso consiste en sumar el número de componentes de cada tipo conforme a la complejidad asignada y utilizar la siguiente tabla para obtener el total. Desarrollo de Software II – Universidad del Valle 2005

Procedimiento Paso 6. Determinar el valor del factor de ajuste. El factor de ajuste se obtiene sumando 0.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema, multiplicado por Paso 7. Determinar los puntos función ajustados. Para determinar los puntos función ajustados se consideran los puntos función no ajustados por el factor de ajuste. Desarrollo de Software II – Universidad del Valle 2005

El alcance de la métrica Cualquier métrica tiene un ámbito de acción y alcance definido que hay que entender pasa usarla correctamente. Así por ejemplo, el metro lineal no es lo mejor para medir grandes distancias en el mar. Puntos Función, está enfocado a medir sistemas informáticos completos, no programas. En este sentido no tiene un nivel de precisión suficiente para medir el tamaño de programas individuales. Desarrollo de Software II – Universidad del Valle 2005

El alcance de la métrica Un punto que se le ha criticado a las métricas funcionales es que requieren que alguien “identifique” la funcionalidad y “evalúe” la complejidad basándose en los criterios y reglas establecidas; no puedo hacer un programa que cuente automáticamente. Debido a esto, distintas personas podrían llegar a un conteo diferente. En la industria del SW tanto desarrolladores como compradores, requiere mejores prácticas. Las métricas son un elemento fundamental de control en cualquier ingeniería y aquí no son la excepción. El tamaño del SW es un determinante fundamental en el esfuerzo de un proyecto de desarrollo de SW al igual que para la adquisición de un paquete. Desarrollo de Software II – Universidad del Valle 2005

Estimación Temprana del Tamaño del Software Para realizar la planificación de un proyecto software, es necesario poseer una estimación certera del esfuerzo necesario para el desarrollo lo más temprano posible, idealmente, con sólo la etapa de especificación de requisitos cubierta. De una "buena" especificación de requisitos se pueden obtener las características de la aplicación a desarrollar, antes de que comience el desarrollo del software. Si a partir de estas características se puede obtener una estimación del tamaño del software, se tendría una estimación temprana del tamaño del mismo. Una estimación temprana sería útil para generar la planificación del proyecto, la cual podría corregirse con el apoyo de las técnicas basadas en los puntos de función o líneas de código en etapas más avanzadas del desarrollo. Desarrollo de Software II – Universidad del Valle 2005

Métrica para Estimación Temprana del Tamaño del Software. Para poder realizar una estimación temprana, se propone la utilización de la métrica de puntos de función modificada. Este método consiste en clasificar, listar y contar a partir de la especificación de requisitos todos los componentes, desagregados en: Este método consiste en clasificar, listar y contar a partir de la especificación de requisitos todos los componentes, desagregados en: a.Entradas Externas. b. Salidas Externas c. Archivos Lógicos d. Consultas. En el método original además se consideraba la clasificación Archivos de Interfaces externos, los cuales son utilizados para la comunicación entre aplicaciones. Debido a que a esta altura del desarrollo difícilmente se puede contar con esta información, se ha eliminado. En caso de ser obvia la necesidad de contar con un archivo de interfaces, éste debe cuantificarse como un archivo lógico más. En el método original además se consideraba la clasificación Archivos de Interfaces externos, los cuales son utilizados para la comunicación entre aplicaciones. Debido a que a esta altura del desarrollo difícilmente se puede contar con esta información, se ha eliminado. En caso de ser obvia la necesidad de contar con un archivo de interfaces, éste debe cuantificarse como un archivo lógico más. Desarrollo de Software II – Universidad del Valle 2005

Métrica para Estimación Temprana del Tamaño del Software (cont.) Para resolver el problema de determinar la complejidad asociada a cada componente de la aplicación (difícil de conocer en esta etapa), se ha optado por asignar a todos los componentes una complejidad promedio. Esta es una aproximación válida, debido a que normalmente "en media" las aplicaciones son de complejidad promedio, teniendo sólo unos pocos componentes de complejidad simple y otros complejos. De este modo, la fórmula para obtener los puntos de función para estimación temprana (PFET) es la siguiente: Donde PFET : Puntos de función para estimación temprana. IN : Número de Entradas Externas OUT : Número de Salidas Externas INQ : Número de Consultas FILE : Número de Archivos Lógicos ACP : Factor de Ajuste de Complejidad de Proceso Desarrollo de Software II – Universidad del Valle 2005

Estimación basada en el Proceso Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software. Desarrollo de Software II – Universidad del Valle 2005

Método Delphi Introducción Las organizaciones tienen como objetivo, tanto obtener los mayores beneficios económicos, como ser capaces de existir el mayor tiempo posible. Para ello realizan un plan estratégico donde deben conocer el entorno en el que se desarrolla la actividad, los peligros que la amenazan y las oportunidades que aparecen. Para ello, los métodos de prospectiva estudian el futuro En los que se refiere la evolución de los factores tecno-socio-económico y las interacciones entre ellos. Desarrollo de Software II – Universidad del Valle 2005

Método Delphi La técnica Delphi predice basada en la utilización de un Juicio emitido por un grupo de expertos; quienes a través de cuestionarios manifiestan sus opiniones de una manera anónima. El objetivo de los cuestionarios es “Disminuir el espacio intercuartil (desviación de la opinión del experto de la opinión del conjunto), precisando la mediana, de las respuestas obtenidas” Desarrollo de Software II – Universidad del Valle 2005

De manera resumida los pasos que se llevan a cabo para garantizar la calidad de los resultados, para lanzar y analizar la Delphi deberían ser los siguientes:  Fase 1: Formulación del problema  Fase 2: Elección de expertos  Fase 3: Elaboración y lanzamiento de cuestionarios  Fase 4: Desarrollo practico y explotación de resultados Desarrollo de Software II – Universidad del Valle 2005

Fase 1: Formulación del problema Se define el modelo de negocio que soporta la aplicación a desarrollar. Generalmente se utiliza la documentación de mercado, propuestas comerciales y procedimientos que estandarizan el funcionamiento del negocio que se quiere soportar con la aplicación. Desarrollo de Software II – Universidad del Valle 2005

Fase 2: Elección de expertos Se eligen las personas reconocidas por su participación en la planeación y seguimiento de diversos proyectos de software, preferiblemente con conocimiento en el modelo de negocio que soportará la aplicación. Desarrollo de Software II – Universidad del Valle 2005

Fase 3: Elección y lanzamiento de cuestionarios Se eligen y emiten cuestionarios con preguntas cuantificables, que permiten visualizar el esfuerzo estimado para el proyecto de software. De acuerdo a las respuestas de dichos cuestionarios y a las desviaciones por ronda, el repositorio de cuestionarios se actualiza. Las preguntas aplicadas en la primera ronda, son abiertas, las preguntas de la segunda y tercera ronda son cerrada y ligadas directamente a las respuestas de la primera ronda. Desarrollo de Software II – Universidad del Valle 2005

Fase 4: Desarrollo práctico y explotación de resultados Los expertos de forma independiente estiman el esfuerzo del proyecto. Se analizan los resultados de la primera estimación, se calcula la mediana y la desviación; de igual forma se identifican los máximos y mínimos de los resultados. Posteriormente se realiza una 2ª Consulta, donde se informa a los expertos sobre los resultados de la 1ª consulta, generando una nueva estimación. En la 3ª Consulta, cada experto justifica los casos en que su respuesta sea muy divergente de los demás. Desarrollo de Software II – Universidad del Valle 2005