SlideShare una empresa de Scribd logo
TECNICAS DE ESTIMACION DE COSTOS DE PROYECTO SOFTWAREJENNIFER ANDREA CANO GUEVARAINGENIERIA DE SISTEMAS
La EstimaciónNo necesita realizarse en una forma improvisada.La experiencia es una gran ayuda.La estimación implica riesgo inherente, y este conduce a la incertidumbre.El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas para recursos, costos y programa de trabajo.
La dificiltarea de estimarLa estimación de software es difícil. Los jefes, directivos, clientes y desarrolladores no parecen entender por qué la estimación es tan difícil. No se puede estimar con precisión el costo de un programa hasta que se comprendan con detalle cada una de las funciones que realizará el sistema. La incertidumbre sobre la naturaleza del producto aporta incertidumbre a la estimación.
EstimaciónUn gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.
FACTORES QUE INFLUYEN EN EL COSTO DEL SOFTWARE La estimación de lo que costará el desarrollo de un software es una de las actividades de planeación que reviste especial importancia, ya que una de las características que debe tener un producto de software es que su costo sea adecuado, de lo contrario el proyecto puede fracasar.
Los factores que afectan el costo del software1. Capacidad del programador 2. Complejidad del producto 3. Tamaño del programa 4. Tiempo disponible 5. Confiabilidad requerida
El Proceso de Estimación 1. Estimar el tamaño del producto ( en número de líneas de código fuente o puntos de función ). 2. Estimar el esfuerzo ( personas - mes ). 3. Estimar el plan ( meses ).
Técnicas de DescomposiciónLa técnica de descomposición basada en el problema, se basa en la descomposición del producto en funciones y estimar el tamaño del software• Por tanto, la primera estimación que sirve de base para todas las demás, es la estimación del tamaño del software
Estimación Basada en el Problema
Técnicas de DescomposiciónTamaño del SoftwarePodemos considerar dos tamaños del software:Tamaño en LDC.Tamaño en PF.• En cualquier caso, la precisión de la estimación depende de:El grado en el que el planificador ha estimado adecuadamente el tamaño del producto a construir.
Técnicas de DescomposiciónTamaño del Software- La habilidad para traducir la estimación del tamaño en esfuerzo y dinero. Depende fundamentalmente de la existencia de métricas.El grado en que el plan del proyecto refleja las habilidades del equipo de software.
Técnicas de descomposiciónBasadas en el Problema• Dicha estimación puede basarse en:Datos históricos.Experiencia/intuición.• Con estos valores se calcula un valor esperado:	VE = (Vo + 4Vm + Vp)/6• Una vez estimado el tamaño se aplican los datos históricos de productividad LDC
Técnicas de  DescomposiciónBasadas en el Proceso• La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar• Utilizando el proceso identificamos un conjunto pequeño de actividades de trabajo o tareas de trabajo y se estima el esfuerzo requerido para llevar a cabo cada tarea
METRICA“Un Método y una escala cuantitativos que pueden ser usados para determinar el valor que toma cierta característica en un producto de software concreto.”
Ecuaciones de los Modelos Empiricos
CLASIFICACION DE LAS METRICASMÉTRICAS TÉCNICAS: Se centran en las características de software.MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software.
CLASIFICACION DE LAS METRICASMÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos.MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar.
CLASIFICACION DE LAS METRICASMÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla.
Métricas del SoftwareMétricas Orientadas al tamañoMedidas directas del resultadoy del procesoMétricas Orientadas a la funciónMedidas indirectas del software y del proceso
Métricas orientadas al tamañoPáginas de documentaciónEsfuerzo humano (persona - mes)N° de erroresLDCN° de defectosCoste (USD)Productividad =KLDC / persona-mesCalidad =N° de errores (defectos) / KLDCCoste medio =USD / KLDCDocumentación =KLDC / persona-mes
METRICA LDCCalcular  la productividad, calidad, coste medio y documentación de acuerdo a la información proporcionada en la tabla que se muestra a continuación:Productividad = KLDC / personas-mes
Calidad = Nº errores (defectos) / KLDC
Coste medio = Dólares / KLDC
Documentación = Páginas de documentación / KLDCMETRICAS LDCCon los datos contenidos en la tabla se puede obtener un conjunto de métricas simples adicionales: No. De Errores por LDC 134 / 12,100         0.01 Errores / LDC No. De Defectos por LDC 29/12,100          0.002 Defectos / LDC Costo por LDC 168,000 / 12,100          $ 13.88 / LDC LDC por persona-mes 12,100 / 24         904 LDC/p-m
METRICA LDCVentajas: - Es una métrica fácil de comprender. - Muchos modelos, herramientas automáticas y literatura de estimación se basan en LDC.
METRICA LDCDesventajas: Las LDC son dependientes del lenguaje. Escribir el mismo programa en lenguajes diferentes puede arrojar una diferencia en LCF bastante grande. Resulta difícil que el planificador estime las LCF a producirse mucho antes de que se complete el análisis y el diseño, más aún si no tiene datos históricos.
-25-Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información  de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.Funciones identificadas:interfaz de usuario y facilidades de control (IUFC)análisis geométrico de dos dimensiones (AG2D)análisis geométrico de tres dimensiones (AG3D)gestión de base de datos (GBD)facilidades de la interfaz gráfica (FIG)control periféricos (CP)módulos de análisis del diseño (MAD)Estimación en LDC de AG3D:optimista: 		4600más probable: 	6900pesimista: 		8600descomposiciónde funcionesVE = (Sopt + 4Sm + Spes)/6Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pmTarifa laboral: 8000 $ /mesCoste LDC:$ 13 ($12.90)Función        LDC estimadaIUFC	2300AG2D	5300AG3D	6800GBD	3350FIG	4950CP	2100MAD	8400	Total33200métricas deproyectos anterioresCoste total proyecto:$431.600Esfuerzo estimado: 54 personas-mes
Métricas orientadas a la funciónconsultassalidasFicheros logicos internosPFentradasFicheros de interfaz
EstimaciónUna mejor estimación viene dada por:S = (Sopt + 4Smed + Spes)/6cálculo de la desviación de las estimaciones
EntradasInformaciones que llegan a la aplicación desde el exterior.Tienen una sola dirección 	(Exterior à Interior)Siempre actualizan algún fichero interno. 4. Apendice, Métrica de los puntos de función.28
Clasificación de las salidas
SalidasInformaciones elaboradas por la aplicación que son transmitidas al usuario.Tienen una sola dirección 		(Interior a Exterior)4. Apendice, Métrica de los puntos de función.30
ConsultasEntradas que producen inmediatamente una salidaNo modifica los datos del sistema4. Apendice, Métrica de los puntos de función.31
4. Apendice, Métrica de los puntos de función.32Clasificación de las consultasCalculamos la complejidad de la parte de entradaCalculamos la complejidad de la parte de salidaNos quedamos sólo con la complejidad mayor de las dos.
Ficheros Lógicos o Internos4. Apendice, Métrica de los puntos de función.33Agrupaciones de datos, tal y como los percibe el usuarioEs diferente de:Entidades y RelacionesTablas o archivos resultantes del diseño físicoLos grupos de datos serán accedidos y actualizados por la aplicación
Clasificación de los Ficheros Lógicos o Internos
Ficheros de InterfazFicheros a los que accede la aplicación con el único objetivo de obtener información.Son mantenidos por otras aplicacionesNunca los actualiza la aplicación.4. Apendice, Métrica de los puntos de función.35DIAGRAMA DE CONTEXTO
Clasificación de los Ficheros de Interfaz
TABLA PARA CALCULAR PUNTOS DED FUNCION
FACTORES DE COMPLEJIDADSon catorce factores que completan la visión externa de la aplicación.No están recogidos en la funcionalidad de la aplicación.Toman un valor entre 0 y 5
Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 50- Sin influencia	 3- Medio	1- Incidental		 4- Significativo   	2- Moderado		 5- Esencial¿Requiere el sistema copias de seguridad fiables?¿Se requieren comunicaciones de datos?¿Existen funciones de procesamiento distribuido?¿Es crítico el rendimiento?¿Será ejecutado el sistema en un entorno operativo existente y utilizado?¿Se requiere entrada de datos interactiva?¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?¿Se actualizan los archivos maestros de forma interactiva?¿Son complejas las entradas, las salidas, los archivos o las peticiones?¿Es complejo el procesamiento interno?¿Se ha diseñado el código para ser reutilizable?¿Están incluidas en el diseño la conversión y la instalación?¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario?
Métricas orientadas a la funciónPF = cuentatotalX [0,65 + 0,01 * Sumatoria (Fi) ]Punto de funciónSumatoria total resultante de la ejecutar las operaciones en la tabla siguienteEn función de un cuestionario de 14 preguntas  Valores de ajuste de complejidad
Para el ejemplo descrito se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente:      PF = 50 x (0,65 + 0,01 x 46) = 55.5 ≈ 56Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad". 
-42-Copia de seguridad y recuperación	        4Comunicaciones		        2Proceso distribuido		        0Rendimiento crítico		        4Entorno operativo existente	        3Entrada de datos online		        4Transacciones entrada en varias pant.       5Archivos maestros actualizados online      3Complejidad valores dominio información 5Complejidad procesamiento interno	        5Código diseñado para reutilización	        4Conversión en diseño		        3Instalaciones múltiples		        5Aplicación diseñada para cambios	        5PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)PF estimado = 372Coste total proyecto:$ 457.843Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pmTarifa laboral:8000 $ /mesCoste por PF:$ 1.230 ($1230,76)métricas deproyectos anteriores
4. Apendice, Métrica de los puntos de función.43UTILIDADES DE LOS PUNTOS DE FUNCIÓN.Comparar lo que solicitó el cliente con lo que recibió.Comparar la productividad de los diferentes entornos de desarrollo.Comparar la calidad que se obtiene mediante las diferentes técnicas de desarrollo.
TECNICAS DE ESTIMACION DE COSTOS JUICIO EXPERTO La técnica más utilizada para la estimación de costos es el uso del juicio experto. El juicio experto se basa en la experiencia, en el conocimiento anterior y en el sentido comercial de uno o mas individuos dentro de la organización.
JUICIO EXPERTO El experto, por ejemplo, puede hacer una estimación de costos razonando de la siguiente manera: - El sistema que se va a desarrollar es muy similar a uno que se desarrollo anteriormente y que costó $ 8,000.00 y tardó 4 meses. - Se puede reutilizar la base del proyecto anterior. - Se utilizará el mismo equipo de cómputo y a muchos de los programadores que participaron en el proyecto anterior, por lo que la estimación se puede reducir en un 20 %.
JUICIO EXPERTO - Mucho código y rutinas comunes se podrán reutilizar por lo que el esfuerzo se reduce otro 20%. - Por lo tanto el nuevo proyecto puede ser un 20% más económico que el anterior.
JUICIO EXPERTOVentajas Se obtiene una estimación en corto tiempo.Desventajas 1. El experto puede confiarse y olvidar algunos factores importantes del Nuevo proyecto, creyendo que es casi igual al anterior. 2. El experto puede no tener familiaridad con el área del proyecto.
TECNICAS DE ESTIMACION DE COSTOS TECNICA DELFI Se desarrollo en la corporación Rand en 1948, con el fin de lograr un acuerdo de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica se lleva a cabo de la siguiente manera:
TECNICA DELFI 1. Un coordinador proporciona a cada experto la documentación con la Definición del Sistema y una papeleta para que escriba su estimación.2. Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar al coordinador, pero no entre ellos.
DELFI3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos. 4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos en que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.
TECNICA DELFI 5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.
ECUACION DE PRIMER ORDEN DE JONES Carpes Jones propone una ecuación derivada del análisis de su base de datos de cientos de proyectos. Este es también un modelo empírico de estimación. Con la suma total de puntos de función , se puede realizar a partir de ellos un cálculo aproximado de la planificación.
ECUACION DE JONESLa ecuación de Jones tiene la forma:     TDEV = #PF n     Donde TDEV = Tiempo de planificación ( meses )     #PF = No. de Puntos de Función     n = Exponente según la tabla siguiente
ECUACION DE JONES
TECNICA ITERATIVA Se basa en la entrega evolutiva del software ( por etapas o iteraciones ). En cada etapa se construye un pequeño conjunto de funciones del software ( miniproyecto ), que implica análisis, diseño, codificación, pruebas, documentación y evaluación del cliente. La técnica permite determinar el número de iteraciones y su longitud necesaria para desarrollar el proyecto completo.NOTA: Las estimaciones son de los desarrolladores, no de los gerentes.
TECNICA ITERATIVA1.- Estimar el esfuerzo de cada función del software. Asegurarse de que quien haga la estimación sea el desarrollador que posea el mayor conocimiento de la función dada.
TECNICA ITERATIVA2.- Determine el número de programadores. Utilizando los registros de proyectos anteriores, busque una aproximación con el Esfuerzo del proyecto actual y deduzca el número de programadores que convendría utilizar. Ejemplo: Si en un proyecto anterior de 38 semanas-programador requirió 4 programadores, puede ser razonable que el nuevo proyecto requiera de 5.
TECNICA ITERATIVA3.- Determine el factor de eficiencia de los programadores ( productividad ). Aunque los desarrolladores sean de tiempo completo, no dedicarán el 100% de la jornada en trabajo productivo. Investigaciones de cómo usan su tiempo los programadores indican QUE:Ejemplo: Suponga una productividad del 50% para este ejemplo.
TECNICA ITERATIVA4.- Determine la longitud de la iteración. Se busca una longitud de iteración fija para todo el proyecto, de modo que se pueda lograr un ritmo regular de entrega del proyecto. Cada iteración debe ser lo suficientemente larga para realizar varias funciones del software. Puede considerar longitudes de iteración de 2 a 8 semanas. Ejemplo: Suponer para este ejemplo que se implementará en un lenguaje conocido, por lo que una longitud de iteración de 3 semanas permitirá implementar de 2 a 4 funciones del software por iteración
TECNICA ITERATIVA5.- Calcular el esfuerzo por iteración. Esfuerzo por iteración ( semanas-programador ) = No. Programadores * Long. Iteración * Factor de Productividad Ejemplo: Esfuerzo por iteración = 5 * 3 * 0.5 = 7.5 semanas-programador
TECNICA ITERATIVA6.- Calcular el número de iteraciones. No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteración ) + 1 Ejemplo: No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones
7.- Calcular el tiempo de desarrollo. Teniendo la longitud y el número de iteraciones es fácil determinar el tiempo de desarrollo Tdev = Long. Iteración * No. Iteraciones Ejemplo: Tdev = 3 * 8 = 24 semanas = 6 meses.
8.- Considerar un factor de contingencia. Agregue un factor del 10% al 20% del tiempo de construcción, dependiendo de lo arriesgada que parezca la situación. Ejemplo: Considerando el factor 40-20-40, es decir, el 40% de esfuerzo es Analisis-Diseño, 20% Codificación y 40% Pruebas, calculamos que el tiempo posible de construcción ( codificación ) es el 20% de las 24 semanas totales. Tcodif = 0.2 * 24 = 4.8 aprox. 5 semanas
Suponiendo que nuestro factor de contingencia es del 15% entonces el tiempo de contingencia será Tconting = 0.15 * 5 = 0.75 semanas o aprox. 4 dias. Por lo tanto el plan debe ser formulado para desarrollar el producto en 24 semanas, pero el compromiso de entrega final sería para 24.75 semanas, 4 días más.
TECNICAS DE ESTIMACION DE COSTOS METODO HISTORICO Este método se basa en registros cuidadosos que se mantienen de esfuerzos de desarrollo previos. MODELO DE COSTOS COCOMO El modelo de costos COCOMO ( Modelo Constructivo de Costos ), se basa en el uso de ecuaciones que se utilizan de acuerdo a la complejidad del sistema a desarrollar:
CocomoEl Modelo Constructivo de Costos (COnstructiveCOstModel) es una jerarquía de modelos de estimación para el software.
Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:
E = ab (KLDC) exp (bb)
D = cb (E) exp (db)
Las ecuaciones del modelo COCOMO intermedio toma la forma:
E = ai (KLDC) exp (bi) x FAE
donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuídas para el proyecto.Jerarquías de CocomoEl modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.COCOMOEl modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa  y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
cocomoEl modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.
Cocomo Orientado a los Tipos de proyecto de software Modelo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico).Cocomo Orientado a los Tipos de proyecto de software Modelo Semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos).
Cocomo Orientado a los Tipos de proyecto de software Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).
Tecnicas de estimacion de costos de proyecto software
COCOMOLas ecuaciones son de la forma: PM = a * ( KDSI ) b ; TDEV = c * ( PM ) d Programas de Aplicación: PM = 2.4 * ( KDSI ) 1.05; TDEV = 2.5 * ( PM ) 0.38 Programas de Apoyo: PM = 3.0 * ( KDSI ) 1.12; TDEV = 2.5 * ( PM ) 0.35 Programas de Sistemas: PM = 3.6 * ( KDSI ) 1.20; TDEV = 2.5 * ( PM ) 0.32
Calendarización FundamentosLa realidad de un proyecto técnico, tal como uno de software, es que hay que realizar cientos de tareas pequeñas en un orden determinado antes de poder alcanzar la meta final. Las tareas están interrelacionadas en una secuencia lógica en el sentido de que algunas de ellas no pueden empezar hasta que otras se hayan terminado.
-76-CalendarioDividir el proyecto en actividades o tareasEstimar el tiempo necesario para realizarlas (algunas se harán en paralelo)Los administradores Coordinan las actividades Organizan el trabajo para optimizar la mano de obraAsignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...)Duración aconsejable de una actividad: entre 1 y 8 semanas

Más contenido relacionado

La actualidad más candente

Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
Cesar Prado
 
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREPSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
Franklin Parrales Bravo
 
Ingeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de softwareIngeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de software
Moises Medina
 
Introduccion a la Ingeniería de Software
Introduccion a la Ingeniería de SoftwareIntroduccion a la Ingeniería de Software
Introduccion a la Ingeniería de Software
Lia IS
 
Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
Wilfredo Mogollón
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
Chuyito Alvarado
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
Andrés Felipe Montoya Ríos
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
EvelinBermeo
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
Camila Arbelaez
 
Cuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de softwareCuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de software
paoaboytes
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
Rosa Virginia Ortega Loaiza
 
Estandares y modelos de calidad del software
Estandares y modelos de calidad del softwareEstandares y modelos de calidad del software
Estandares y modelos de calidad del software
aagalvisg
 
Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)
Yaskelly Yedra
 
Métrica de punto de función y lineas de codigo
Métrica de punto de función y lineas de codigoMétrica de punto de función y lineas de codigo
Métrica de punto de función y lineas de codigo
Jesús E. CuRias
 
Gestión de riesgos de software
Gestión de riesgos de softwareGestión de riesgos de software
Gestión de riesgos de software
Omar S. Gomez
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
samuel ospino
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
CristobalFicaV
 
Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitos
inmacu_
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
Marvin Romero
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
landeta_p
 

La actualidad más candente (20)

Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREPSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
 
Ingeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de softwareIngeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de software
 
Introduccion a la Ingeniería de Software
Introduccion a la Ingeniería de SoftwareIntroduccion a la Ingeniería de Software
Introduccion a la Ingeniería de Software
 
Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Cuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de softwareCuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de software
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
Estandares y modelos de calidad del software
Estandares y modelos de calidad del softwareEstandares y modelos de calidad del software
Estandares y modelos de calidad del software
 
Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)
 
Métrica de punto de función y lineas de codigo
Métrica de punto de función y lineas de codigoMétrica de punto de función y lineas de codigo
Métrica de punto de función y lineas de codigo
 
Gestión de riesgos de software
Gestión de riesgos de softwareGestión de riesgos de software
Gestión de riesgos de software
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitos
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 

Similar a Tecnicas de estimacion de costos de proyecto software

Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de Software
Angel Macas
 
Estimación de costo de software
Estimación de costo de softwareEstimación de costo de software
Estimación de costo de software
Jhoseph Lugo
 
Presentacionsii
PresentacionsiiPresentacionsii
Presentacionsii
Luisana Mia Leon Rengel
 
Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Vídeo métricas del software 1151354
Vídeo métricas del software 1151354
Daniela Buitrago
 
Ra semana 6 2
Ra semana 6 2Ra semana 6 2
Ra semana 6 2
victdiazm
 
Metricas tecnicas del software
Metricas tecnicas del softwareMetricas tecnicas del software
Metricas tecnicas del software
aimeemoir
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos Informáticos
Pilar Pardo Hidalgo
 
Gestion de proyectos de SW
Gestion de proyectos de SWGestion de proyectos de SW
Gestion de proyectos de SW
Pilar Pardo Hidalgo
 
Presupuesto Software, victor mamani catachura, boreasH
Presupuesto Software, victor mamani catachura, boreasHPresupuesto Software, victor mamani catachura, boreasH
Presupuesto Software, victor mamani catachura, boreasH
victor mamani
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacion
everfavi0
 
Cocomo
CocomoCocomo
Cocomo
Hugo Galvan
 
Proyecto De Software
Proyecto De SoftwareProyecto De Software
Proyecto De Software
monik1002
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
monik1002
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
monik1002
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
monik1002
 
Metricas01
Metricas01Metricas01
Metricas01
americajuarez
 
Metricas01
Metricas01Metricas01
Metricas01
americajuarez
 
Metricas01
Metricas01Metricas01
Metricas01
americajuarez
 
Metricas01
Metricas01Metricas01
Metricas01
americajuarez
 
Metricas01
Metricas01Metricas01
Metricas01
americajuarez
 

Similar a Tecnicas de estimacion de costos de proyecto software (20)

Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de Software
 
Estimación de costo de software
Estimación de costo de softwareEstimación de costo de software
Estimación de costo de software
 
Presentacionsii
PresentacionsiiPresentacionsii
Presentacionsii
 
Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Vídeo métricas del software 1151354
Vídeo métricas del software 1151354
 
Ra semana 6 2
Ra semana 6 2Ra semana 6 2
Ra semana 6 2
 
Metricas tecnicas del software
Metricas tecnicas del softwareMetricas tecnicas del software
Metricas tecnicas del software
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos Informáticos
 
Gestion de proyectos de SW
Gestion de proyectos de SWGestion de proyectos de SW
Gestion de proyectos de SW
 
Presupuesto Software, victor mamani catachura, boreasH
Presupuesto Software, victor mamani catachura, boreasHPresupuesto Software, victor mamani catachura, boreasH
Presupuesto Software, victor mamani catachura, boreasH
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacion
 
Cocomo
CocomoCocomo
Cocomo
 
Proyecto De Software
Proyecto De SoftwareProyecto De Software
Proyecto De Software
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 

Más de Jennifer Andrea Cano Guevara

Merchandising
MerchandisingMerchandising
B-learning y sus aplicaciones en la informática educativa como modelo de apre...
B-learning y sus aplicaciones en la informática educativa como modelo de apre...B-learning y sus aplicaciones en la informática educativa como modelo de apre...
B-learning y sus aplicaciones en la informática educativa como modelo de apre...
Jennifer Andrea Cano Guevara
 
DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...
DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...
DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...
Jennifer Andrea Cano Guevara
 
Manejo de la Herramienta GIMP
Manejo de la Herramienta GIMPManejo de la Herramienta GIMP
Manejo de la Herramienta GIMP
Jennifer Andrea Cano Guevara
 
Dispositivos de red
Dispositivos de redDispositivos de red
Dispositivos de red
Jennifer Andrea Cano Guevara
 
Evaluación y selección de tecnologías de información
Evaluación y selección de tecnologías de informaciónEvaluación y selección de tecnologías de información
Evaluación y selección de tecnologías de información
Jennifer Andrea Cano Guevara
 

Más de Jennifer Andrea Cano Guevara (6)

Merchandising
MerchandisingMerchandising
Merchandising
 
B-learning y sus aplicaciones en la informática educativa como modelo de apre...
B-learning y sus aplicaciones en la informática educativa como modelo de apre...B-learning y sus aplicaciones en la informática educativa como modelo de apre...
B-learning y sus aplicaciones en la informática educativa como modelo de apre...
 
DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...
DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...
DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA EL CONTROL DE RIEGO DE LOS CULTI...
 
Manejo de la Herramienta GIMP
Manejo de la Herramienta GIMPManejo de la Herramienta GIMP
Manejo de la Herramienta GIMP
 
Dispositivos de red
Dispositivos de redDispositivos de red
Dispositivos de red
 
Evaluación y selección de tecnologías de información
Evaluación y selección de tecnologías de informaciónEvaluación y selección de tecnologías de información
Evaluación y selección de tecnologías de información
 

Último

Catálogo LG de lavadora de ropa , manual
Catálogo LG de lavadora de ropa , manualCatálogo LG de lavadora de ropa , manual
Catálogo LG de lavadora de ropa , manual
RobertoAlvarez835593
 
Transporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdfTransporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdf
milagrosAlbanPacherr
 
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
241578066
 
590248542-Pruebas-de-auditoria-informatica.pdf
590248542-Pruebas-de-auditoria-informatica.pdf590248542-Pruebas-de-auditoria-informatica.pdf
590248542-Pruebas-de-auditoria-informatica.pdf
ivanbrito1105
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
Katia Reyes
 
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docxSEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
Eddy Nathaly Jaimes Villamizar
 
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
MenaOlortinYherlyEli
 
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptxDiapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
GnesisOrtegaDeLen
 
Evolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TICEvolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TIC
Henry W. Zavala
 
_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf
correodetareas
 
Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...
Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...
Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...
Telefónica
 
11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf
PanchoChangue
 
Conceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagaciónConceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagación
edgarcalle8
 
bomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexionesbomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexiones
JessAdrinGonzlezCade
 
Catalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdfCatalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdf
walter729637
 
DE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docx
DE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docxDE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docx
DE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docx
lourdesuribe6
 
Generaciones de Computadoras .
Generaciones de Computadoras                 .Generaciones de Computadoras                 .
Generaciones de Computadoras .
gregory760891
 
PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)
PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)
PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)
ADELAIDA90
 
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
bellomiguelangel68
 
DN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en PerúDN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en Perú
estudios22
 

Último (20)

Catálogo LG de lavadora de ropa , manual
Catálogo LG de lavadora de ropa , manualCatálogo LG de lavadora de ropa , manual
Catálogo LG de lavadora de ropa , manual
 
Transporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdfTransporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdf
 
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
 
590248542-Pruebas-de-auditoria-informatica.pdf
590248542-Pruebas-de-auditoria-informatica.pdf590248542-Pruebas-de-auditoria-informatica.pdf
590248542-Pruebas-de-auditoria-informatica.pdf
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
 
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docxSEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
 
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
 
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptxDiapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
 
Evolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TICEvolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TIC
 
_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf
 
Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...
Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...
Índice del libro "Metaverso y mundos virtuales: Tecnologías, Retos y Oportuni...
 
11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf
 
Conceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagaciónConceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagación
 
bomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexionesbomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexiones
 
Catalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdfCatalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdf
 
DE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docx
DE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docxDE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docx
DE LO HUMANO Y LO COMUNITARIO PROYECTO INTEGRADOR (2).docx
 
Generaciones de Computadoras .
Generaciones de Computadoras                 .Generaciones de Computadoras                 .
Generaciones de Computadoras .
 
PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)
PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)
PROTOCOLO DE NANOPOROS Kit de códigos de barras 16S (SQK-RAB204)
 
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
 
DN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en PerúDN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en Perú
 

Tecnicas de estimacion de costos de proyecto software

  • 1. TECNICAS DE ESTIMACION DE COSTOS DE PROYECTO SOFTWAREJENNIFER ANDREA CANO GUEVARAINGENIERIA DE SISTEMAS
  • 2. La EstimaciónNo necesita realizarse en una forma improvisada.La experiencia es una gran ayuda.La estimación implica riesgo inherente, y este conduce a la incertidumbre.El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas para recursos, costos y programa de trabajo.
  • 3. La dificiltarea de estimarLa estimación de software es difícil. Los jefes, directivos, clientes y desarrolladores no parecen entender por qué la estimación es tan difícil. No se puede estimar con precisión el costo de un programa hasta que se comprendan con detalle cada una de las funciones que realizará el sistema. La incertidumbre sobre la naturaleza del producto aporta incertidumbre a la estimación.
  • 4. EstimaciónUn gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.
  • 5. FACTORES QUE INFLUYEN EN EL COSTO DEL SOFTWARE La estimación de lo que costará el desarrollo de un software es una de las actividades de planeación que reviste especial importancia, ya que una de las características que debe tener un producto de software es que su costo sea adecuado, de lo contrario el proyecto puede fracasar.
  • 6. Los factores que afectan el costo del software1. Capacidad del programador 2. Complejidad del producto 3. Tamaño del programa 4. Tiempo disponible 5. Confiabilidad requerida
  • 7. El Proceso de Estimación 1. Estimar el tamaño del producto ( en número de líneas de código fuente o puntos de función ). 2. Estimar el esfuerzo ( personas - mes ). 3. Estimar el plan ( meses ).
  • 8. Técnicas de DescomposiciónLa técnica de descomposición basada en el problema, se basa en la descomposición del producto en funciones y estimar el tamaño del software• Por tanto, la primera estimación que sirve de base para todas las demás, es la estimación del tamaño del software
  • 10. Técnicas de DescomposiciónTamaño del SoftwarePodemos considerar dos tamaños del software:Tamaño en LDC.Tamaño en PF.• En cualquier caso, la precisión de la estimación depende de:El grado en el que el planificador ha estimado adecuadamente el tamaño del producto a construir.
  • 11. Técnicas de DescomposiciónTamaño del Software- La habilidad para traducir la estimación del tamaño en esfuerzo y dinero. Depende fundamentalmente de la existencia de métricas.El grado en que el plan del proyecto refleja las habilidades del equipo de software.
  • 12. Técnicas de descomposiciónBasadas en el Problema• Dicha estimación puede basarse en:Datos históricos.Experiencia/intuición.• Con estos valores se calcula un valor esperado: VE = (Vo + 4Vm + Vp)/6• Una vez estimado el tamaño se aplican los datos históricos de productividad LDC
  • 13. Técnicas de DescomposiciónBasadas en el Proceso• La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar• Utilizando el proceso identificamos un conjunto pequeño de actividades de trabajo o tareas de trabajo y se estima el esfuerzo requerido para llevar a cabo cada tarea
  • 14. METRICA“Un Método y una escala cuantitativos que pueden ser usados para determinar el valor que toma cierta característica en un producto de software concreto.”
  • 15. Ecuaciones de los Modelos Empiricos
  • 16. CLASIFICACION DE LAS METRICASMÉTRICAS TÉCNICAS: Se centran en las características de software.MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software.
  • 17. CLASIFICACION DE LAS METRICASMÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos.MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar.
  • 18. CLASIFICACION DE LAS METRICASMÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla.
  • 19. Métricas del SoftwareMétricas Orientadas al tamañoMedidas directas del resultadoy del procesoMétricas Orientadas a la funciónMedidas indirectas del software y del proceso
  • 20. Métricas orientadas al tamañoPáginas de documentaciónEsfuerzo humano (persona - mes)N° de erroresLDCN° de defectosCoste (USD)Productividad =KLDC / persona-mesCalidad =N° de errores (defectos) / KLDCCoste medio =USD / KLDCDocumentación =KLDC / persona-mes
  • 21. METRICA LDCCalcular la productividad, calidad, coste medio y documentación de acuerdo a la información proporcionada en la tabla que se muestra a continuación:Productividad = KLDC / personas-mes
  • 22. Calidad = Nº errores (defectos) / KLDC
  • 23. Coste medio = Dólares / KLDC
  • 24. Documentación = Páginas de documentación / KLDCMETRICAS LDCCon los datos contenidos en la tabla se puede obtener un conjunto de métricas simples adicionales: No. De Errores por LDC 134 / 12,100 0.01 Errores / LDC No. De Defectos por LDC 29/12,100 0.002 Defectos / LDC Costo por LDC 168,000 / 12,100 $ 13.88 / LDC LDC por persona-mes 12,100 / 24 904 LDC/p-m
  • 25. METRICA LDCVentajas: - Es una métrica fácil de comprender. - Muchos modelos, herramientas automáticas y literatura de estimación se basan en LDC.
  • 26. METRICA LDCDesventajas: Las LDC son dependientes del lenguaje. Escribir el mismo programa en lenguajes diferentes puede arrojar una diferencia en LCF bastante grande. Resulta difícil que el planificador estime las LCF a producirse mucho antes de que se complete el análisis y el diseño, más aún si no tiene datos históricos.
  • 27. -25-Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.Funciones identificadas:interfaz de usuario y facilidades de control (IUFC)análisis geométrico de dos dimensiones (AG2D)análisis geométrico de tres dimensiones (AG3D)gestión de base de datos (GBD)facilidades de la interfaz gráfica (FIG)control periféricos (CP)módulos de análisis del diseño (MAD)Estimación en LDC de AG3D:optimista: 4600más probable: 6900pesimista: 8600descomposiciónde funcionesVE = (Sopt + 4Sm + Spes)/6Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pmTarifa laboral: 8000 $ /mesCoste LDC:$ 13 ($12.90)Función LDC estimadaIUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400 Total33200métricas deproyectos anterioresCoste total proyecto:$431.600Esfuerzo estimado: 54 personas-mes
  • 28. Métricas orientadas a la funciónconsultassalidasFicheros logicos internosPFentradasFicheros de interfaz
  • 29. EstimaciónUna mejor estimación viene dada por:S = (Sopt + 4Smed + Spes)/6cálculo de la desviación de las estimaciones
  • 30. EntradasInformaciones que llegan a la aplicación desde el exterior.Tienen una sola dirección (Exterior à Interior)Siempre actualizan algún fichero interno. 4. Apendice, Métrica de los puntos de función.28
  • 32. SalidasInformaciones elaboradas por la aplicación que son transmitidas al usuario.Tienen una sola dirección (Interior a Exterior)4. Apendice, Métrica de los puntos de función.30
  • 33. ConsultasEntradas que producen inmediatamente una salidaNo modifica los datos del sistema4. Apendice, Métrica de los puntos de función.31
  • 34. 4. Apendice, Métrica de los puntos de función.32Clasificación de las consultasCalculamos la complejidad de la parte de entradaCalculamos la complejidad de la parte de salidaNos quedamos sólo con la complejidad mayor de las dos.
  • 35. Ficheros Lógicos o Internos4. Apendice, Métrica de los puntos de función.33Agrupaciones de datos, tal y como los percibe el usuarioEs diferente de:Entidades y RelacionesTablas o archivos resultantes del diseño físicoLos grupos de datos serán accedidos y actualizados por la aplicación
  • 36. Clasificación de los Ficheros Lógicos o Internos
  • 37. Ficheros de InterfazFicheros a los que accede la aplicación con el único objetivo de obtener información.Son mantenidos por otras aplicacionesNunca los actualiza la aplicación.4. Apendice, Métrica de los puntos de función.35DIAGRAMA DE CONTEXTO
  • 38. Clasificación de los Ficheros de Interfaz
  • 39. TABLA PARA CALCULAR PUNTOS DED FUNCION
  • 40. FACTORES DE COMPLEJIDADSon catorce factores que completan la visión externa de la aplicación.No están recogidos en la funcionalidad de la aplicación.Toman un valor entre 0 y 5
  • 41. Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 50- Sin influencia 3- Medio 1- Incidental 4- Significativo 2- Moderado 5- Esencial¿Requiere el sistema copias de seguridad fiables?¿Se requieren comunicaciones de datos?¿Existen funciones de procesamiento distribuido?¿Es crítico el rendimiento?¿Será ejecutado el sistema en un entorno operativo existente y utilizado?¿Se requiere entrada de datos interactiva?¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?¿Se actualizan los archivos maestros de forma interactiva?¿Son complejas las entradas, las salidas, los archivos o las peticiones?¿Es complejo el procesamiento interno?¿Se ha diseñado el código para ser reutilizable?¿Están incluidas en el diseño la conversión y la instalación?¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario?
  • 42. Métricas orientadas a la funciónPF = cuentatotalX [0,65 + 0,01 * Sumatoria (Fi) ]Punto de funciónSumatoria total resultante de la ejecutar las operaciones en la tabla siguienteEn función de un cuestionario de 14 preguntas Valores de ajuste de complejidad
  • 43. Para el ejemplo descrito se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente:      PF = 50 x (0,65 + 0,01 x 46) = 55.5 ≈ 56Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad". 
  • 44. -42-Copia de seguridad y recuperación 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)PF estimado = 372Coste total proyecto:$ 457.843Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pmTarifa laboral:8000 $ /mesCoste por PF:$ 1.230 ($1230,76)métricas deproyectos anteriores
  • 45. 4. Apendice, Métrica de los puntos de función.43UTILIDADES DE LOS PUNTOS DE FUNCIÓN.Comparar lo que solicitó el cliente con lo que recibió.Comparar la productividad de los diferentes entornos de desarrollo.Comparar la calidad que se obtiene mediante las diferentes técnicas de desarrollo.
  • 46. TECNICAS DE ESTIMACION DE COSTOS JUICIO EXPERTO La técnica más utilizada para la estimación de costos es el uso del juicio experto. El juicio experto se basa en la experiencia, en el conocimiento anterior y en el sentido comercial de uno o mas individuos dentro de la organización.
  • 47. JUICIO EXPERTO El experto, por ejemplo, puede hacer una estimación de costos razonando de la siguiente manera: - El sistema que se va a desarrollar es muy similar a uno que se desarrollo anteriormente y que costó $ 8,000.00 y tardó 4 meses. - Se puede reutilizar la base del proyecto anterior. - Se utilizará el mismo equipo de cómputo y a muchos de los programadores que participaron en el proyecto anterior, por lo que la estimación se puede reducir en un 20 %.
  • 48. JUICIO EXPERTO - Mucho código y rutinas comunes se podrán reutilizar por lo que el esfuerzo se reduce otro 20%. - Por lo tanto el nuevo proyecto puede ser un 20% más económico que el anterior.
  • 49. JUICIO EXPERTOVentajas Se obtiene una estimación en corto tiempo.Desventajas 1. El experto puede confiarse y olvidar algunos factores importantes del Nuevo proyecto, creyendo que es casi igual al anterior. 2. El experto puede no tener familiaridad con el área del proyecto.
  • 50. TECNICAS DE ESTIMACION DE COSTOS TECNICA DELFI Se desarrollo en la corporación Rand en 1948, con el fin de lograr un acuerdo de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica se lleva a cabo de la siguiente manera:
  • 51. TECNICA DELFI 1. Un coordinador proporciona a cada experto la documentación con la Definición del Sistema y una papeleta para que escriba su estimación.2. Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar al coordinador, pero no entre ellos.
  • 52. DELFI3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos. 4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos en que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.
  • 53. TECNICA DELFI 5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.
  • 54. ECUACION DE PRIMER ORDEN DE JONES Carpes Jones propone una ecuación derivada del análisis de su base de datos de cientos de proyectos. Este es también un modelo empírico de estimación. Con la suma total de puntos de función , se puede realizar a partir de ellos un cálculo aproximado de la planificación.
  • 55. ECUACION DE JONESLa ecuación de Jones tiene la forma: TDEV = #PF n Donde TDEV = Tiempo de planificación ( meses ) #PF = No. de Puntos de Función n = Exponente según la tabla siguiente
  • 57. TECNICA ITERATIVA Se basa en la entrega evolutiva del software ( por etapas o iteraciones ). En cada etapa se construye un pequeño conjunto de funciones del software ( miniproyecto ), que implica análisis, diseño, codificación, pruebas, documentación y evaluación del cliente. La técnica permite determinar el número de iteraciones y su longitud necesaria para desarrollar el proyecto completo.NOTA: Las estimaciones son de los desarrolladores, no de los gerentes.
  • 58. TECNICA ITERATIVA1.- Estimar el esfuerzo de cada función del software. Asegurarse de que quien haga la estimación sea el desarrollador que posea el mayor conocimiento de la función dada.
  • 59. TECNICA ITERATIVA2.- Determine el número de programadores. Utilizando los registros de proyectos anteriores, busque una aproximación con el Esfuerzo del proyecto actual y deduzca el número de programadores que convendría utilizar. Ejemplo: Si en un proyecto anterior de 38 semanas-programador requirió 4 programadores, puede ser razonable que el nuevo proyecto requiera de 5.
  • 60. TECNICA ITERATIVA3.- Determine el factor de eficiencia de los programadores ( productividad ). Aunque los desarrolladores sean de tiempo completo, no dedicarán el 100% de la jornada en trabajo productivo. Investigaciones de cómo usan su tiempo los programadores indican QUE:Ejemplo: Suponga una productividad del 50% para este ejemplo.
  • 61. TECNICA ITERATIVA4.- Determine la longitud de la iteración. Se busca una longitud de iteración fija para todo el proyecto, de modo que se pueda lograr un ritmo regular de entrega del proyecto. Cada iteración debe ser lo suficientemente larga para realizar varias funciones del software. Puede considerar longitudes de iteración de 2 a 8 semanas. Ejemplo: Suponer para este ejemplo que se implementará en un lenguaje conocido, por lo que una longitud de iteración de 3 semanas permitirá implementar de 2 a 4 funciones del software por iteración
  • 62. TECNICA ITERATIVA5.- Calcular el esfuerzo por iteración. Esfuerzo por iteración ( semanas-programador ) = No. Programadores * Long. Iteración * Factor de Productividad Ejemplo: Esfuerzo por iteración = 5 * 3 * 0.5 = 7.5 semanas-programador
  • 63. TECNICA ITERATIVA6.- Calcular el número de iteraciones. No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteración ) + 1 Ejemplo: No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones
  • 64. 7.- Calcular el tiempo de desarrollo. Teniendo la longitud y el número de iteraciones es fácil determinar el tiempo de desarrollo Tdev = Long. Iteración * No. Iteraciones Ejemplo: Tdev = 3 * 8 = 24 semanas = 6 meses.
  • 65. 8.- Considerar un factor de contingencia. Agregue un factor del 10% al 20% del tiempo de construcción, dependiendo de lo arriesgada que parezca la situación. Ejemplo: Considerando el factor 40-20-40, es decir, el 40% de esfuerzo es Analisis-Diseño, 20% Codificación y 40% Pruebas, calculamos que el tiempo posible de construcción ( codificación ) es el 20% de las 24 semanas totales. Tcodif = 0.2 * 24 = 4.8 aprox. 5 semanas
  • 66. Suponiendo que nuestro factor de contingencia es del 15% entonces el tiempo de contingencia será Tconting = 0.15 * 5 = 0.75 semanas o aprox. 4 dias. Por lo tanto el plan debe ser formulado para desarrollar el producto en 24 semanas, pero el compromiso de entrega final sería para 24.75 semanas, 4 días más.
  • 67. TECNICAS DE ESTIMACION DE COSTOS METODO HISTORICO Este método se basa en registros cuidadosos que se mantienen de esfuerzos de desarrollo previos. MODELO DE COSTOS COCOMO El modelo de costos COCOMO ( Modelo Constructivo de Costos ), se basa en el uso de ecuaciones que se utilizan de acuerdo a la complejidad del sistema a desarrollar:
  • 68. CocomoEl Modelo Constructivo de Costos (COnstructiveCOstModel) es una jerarquía de modelos de estimación para el software.
  • 69. Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:
  • 70. E = ab (KLDC) exp (bb)
  • 71. D = cb (E) exp (db)
  • 72. Las ecuaciones del modelo COCOMO intermedio toma la forma:
  • 73. E = ai (KLDC) exp (bi) x FAE
  • 74. donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuídas para el proyecto.Jerarquías de CocomoEl modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.COCOMOEl modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
  • 75. cocomoEl modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.
  • 76. Cocomo Orientado a los Tipos de proyecto de software Modelo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico).Cocomo Orientado a los Tipos de proyecto de software Modelo Semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos).
  • 77. Cocomo Orientado a los Tipos de proyecto de software Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).
  • 79. COCOMOLas ecuaciones son de la forma: PM = a * ( KDSI ) b ; TDEV = c * ( PM ) d Programas de Aplicación: PM = 2.4 * ( KDSI ) 1.05; TDEV = 2.5 * ( PM ) 0.38 Programas de Apoyo: PM = 3.0 * ( KDSI ) 1.12; TDEV = 2.5 * ( PM ) 0.35 Programas de Sistemas: PM = 3.6 * ( KDSI ) 1.20; TDEV = 2.5 * ( PM ) 0.32
  • 80. Calendarización FundamentosLa realidad de un proyecto técnico, tal como uno de software, es que hay que realizar cientos de tareas pequeñas en un orden determinado antes de poder alcanzar la meta final. Las tareas están interrelacionadas en una secuencia lógica en el sentido de que algunas de ellas no pueden empezar hasta que otras se hayan terminado.
  • 81. -76-CalendarioDividir el proyecto en actividades o tareasEstimar el tiempo necesario para realizarlas (algunas se harán en paralelo)Los administradores Coordinan las actividades Organizan el trabajo para optimizar la mano de obraAsignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...)Duración aconsejable de una actividad: entre 1 y 8 semanas
  • 82. -77-Calendario (cont.) Importante tener en cuenta posibles problemas (personal, hardware, software,...) que provocan retrasos.Problemas previstos: incrementar un 30% la estimación inicial.Problemas no previstos: incrementar un 20%.Utilización de diagramas de Gantty redes de actividades
  • 83. Herramientas Automáticas de Calendarización
  • 84. CONSEJOS SOBRE ESTIMACIONES 1. Evite estimaciones improvisadas ( ojo de buen cubero ). 2. Use datos de proyectos anteriores ( método histórico ). 3. Las estimaciones las debe hacer el desarrollador, no el directivo. 4. Estime por concenso ( técnica delfi ). 5. Evite estimar el proyecto como un todo. 6. Estime por descomposición, es decir, estime cada función o requisito del software individualmente. Luego la suma de ellos será la estimación del proyecto total. 7. Utilice diferentes técnicas de estimación, compare los resultados y resuelva las diferencias. 8. Si es posible use una herramienta automática de estimación. Con esto tendrá otro punto de comparación. 9. Refine sus estimaciones a medida que conozca más detalles del proyecto.
  • 85. 10. Emita una estimación preliminar después de revisar la Definición del Sistema. Refinela durante el Análisis y de una estimación definitiva después de revisar el Diseño. Si esto no es posible, trate de emitir su estimación definitiva al terminar el Análisis. Si aún esto no es posible, deberá formularla solo con la Definición del Sistema pero considere un factor de seguridad adecuado. 11. Presente sus estimaciones usando rangos o casos ( mejor, más probable, peor ). 12. Defienda sus estimaciones. Finalmente Ud. y su equipo son los que conocen el proyecto y lo desarrollarán. En lo posible evite que un directivo le imponga una estimación que no esté justificada, para esto debe prepararse para defender sus estimaciones. 13. Negocíe con el cliente.