Download - Planificacion De Proyectos De Software
![Page 1: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/1.jpg)
Planificación de Proyectos de Software
Iván SánchezRonald Sáenz
GissellorKaren Navarro
MuñozAndrea Estrella
KatichulaMegan Fox
![Page 2: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/2.jpg)
El Comienzo• En el principio se pidieron los
proyectos de Software.• Los proyectos estaban
desordenados y vacíos, y las tinieblas estaban sobre la haz del abismo, y el Espíritu de Dios se movía sobre este mar de Caos.
• Y dijo Dios: Sea la Planificación: y fue la Planificación.
• Y vio Dios que la Planificación era buena: y apartó Dios la Planificación del desorden…
![Page 3: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/3.jpg)
Introducción• Antes de comenzar se debe estimar…– Esfuerzo, tiempo, personal y demás recursos..
• Luego de estimar se debe planificar…– Establecer un Plan de Proyecto que defina tareas y fechas clave, identificar responsables por tareas y especificar dependencias entre tareas.
![Page 4: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/4.jpg)
Objetivos
• Resolver problemas corriente arriba a bajo costo.
• La experiencia dice que el proyecto promedio gasta 80 por ciento de su tiempo en reelaboración: corrigiendo errores que se cometieron en etapas tempranas del proyecto.
![Page 5: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/5.jpg)
Objetivos
• Proporcionar un Marco de Trabajo que permita al gestor estimar razonablemente los recursos, costo y programa de trabajo.• Adaptar y actualizar el plan conforme
se avance en el proyecto.
![Page 6: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/6.jpg)
Actividades
• La planificación del proyecto del software abarca 5 grandes actividades:
EstimaciónPrograma de TrabajoAnálisis de RiesgosPlanificación de la Gestión de CalidadPlanificación de la Gestión del Cambio
![Page 7: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/7.jpg)
Los expertos dicen
• Nuestras técnicas de estimación están pobremente desarrolladas. Mas seriamente, reflejan una suposición no expresada que es bastante incierta, es decir: que todo ira bien…
• Frederick Brooks, 1975
![Page 8: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/8.jpg)
La Estimación
• No 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.
![Page 9: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/9.jpg)
La Estimación
• Variabilidad en requisitos = inestabilidad• Un gestor no debe obsesionarse con las
estimaciones.
![Page 10: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/10.jpg)
Conjunto de Tareas para la Planificación de un Proyecto
• Establecer el ámbito del proyecto.• Determinar Factibilidad• Analizar Riesgos.• Definir los recursos requeridos (humanos, software, etc).• Estimar costo y Esfuerzo
– Descomponer el problema– Desarrollar 2 o mas estimaciones (Ej: puntos de función, casos de uso,
etc…)• Desarrollar un Plan de Proyecto
– Establecer un conjunto de tareas significativo.– Definir una red de tareas.– Desarrollar un cronograma con Herramientas de Planificación– Definir mecanismos de seguimiento del programa de trabajo.
![Page 11: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/11.jpg)
Ambito del Software
• Describe:– Funciones– Características– Entradas– Salidas– Contenido a Presentar– Desempeño– Restricciones– Interfaces
Confiabilidad a entregar al Usuario final.
![Page 12: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/12.jpg)
Ambito del Software
Divide y Vencerás• Muchas veces es bueno refinar.• Las estimaciones de costo y el programa de
trabajo están funcionalmente orientadas, por eso es útil cierto grado de descomposición.
![Page 13: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/13.jpg)
Factibilidad
Cuatro elementos esenciales:• Tecnología• Finanzas• Tiempo• Recursos
![Page 14: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/14.jpg)
Recursos
Divididos en Tres Grandes Categorías:• Personal• Componentes de Software Reutilizables• Entorno
![Page 15: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/15.jpg)
La Trinidad
Proyecto
Personal
EntornoSoftware Reutilizable
![Page 16: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/16.jpg)
Recursos Humanos
• El planificador debe especificar:– Habilidades Requeridas– Posición Organizacional– Especialidad
• El personal puede estar Geográficamente disperso.
![Page 17: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/17.jpg)
Recursos de Software Reutilizables
• Ingeniería de Software basada en Componentes.
• Énfasis en la reutilización• Componentes ya desarrollados.• Adquirir componentes de Terceros.• Componentes Experimentados• Componentes de Experiencia Parcial• No inventar el Agua Tibia
![Page 18: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/18.jpg)
Recursos del Entorno
• Hardware• Software (Herramientas de Desarrollo)
![Page 19: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/19.jpg)
Estimación
• Un gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.
Mala Esti
mación
Desastre para
el Desarrollador
![Page 20: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/20.jpg)
Estimación
• Nunca es exacta• Mientras mas se conozca menos errores serios
se cometerán.• Implica muchas variables – Humanas– Técnicas– Ambientales– Políticas– etc
![Page 21: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/21.jpg)
¿Como lograr estimaciones Confiables?
Basarse en proyectos similares
Descomposición Simple
Uso de Modelos Empíricos
![Page 22: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/22.jpg)
EstimaciónUsar Datos Históricos
![Page 23: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/23.jpg)
Técnicas de Descomposición
• El problema a resolver es muy complejo para considerarlo una sola pieza
• Descomponer el problema en problemas mas pequeños
• Hacer el problema mas MANEJABLE
![Page 24: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/24.jpg)
Tamaño del SoftwareEl grado con el cual se ha estimado adecuadamente el tamaño
Habilidad para traducir estimación en esfuerzo humano, cronograma y Dinero
Grado en el que la planificación refleja las habilidades del equipo de Software
![Page 25: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/25.jpg)
Estimación Basada en el Problema
• Métricas basadas en la Productividad• LDC/pm• PF/pm• Combinaciones
![Page 26: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/26.jpg)
Estimación Basada en el Problema
![Page 27: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/27.jpg)
Estimación
Optimista
Mas Probable
Pesimista
Valor
Esperado
Una mejor estimación viene dada por:S = (Sopt + 4Smed + Spes)/6
cálculo de la desviación de las estimaciones
![Page 28: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/28.jpg)
Estimación basada en LDC
• Descomposición funcional absolutamente esencial
• considerables niveles de detalle• LDC se estima directamente.
![Page 29: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/29.jpg)
Ejemplo
![Page 30: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/30.jpg)
Estimación basada en PF
• Los datos requeridos para estimar los Puntos de Función son más macroscópicos que en LDC.
• Nivel de descomposición considerablemente menos detallado que en LDC.
• PF se determina indirectamente mediante la estimación del número de entradas, salidas, archivos de datos, peticiones e interfaces externas, entre otras.
![Page 31: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/31.jpg)
Ejemplo
![Page 32: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/32.jpg)
LDC o PF Esperados
• A partir de los datos históricos o (cuando todo lo demás falla) usando su intuición, el planificador estima los valores optimista, más probable y pesimista de LDC o de PF para cada función. Cuando lo que se especifica es un rango de valores, implícitamente se proporciona una indicación del grado de incertidumbre.
• Entonces, se calcula el valor esperado de LDC o de PF. El valor esperado para la variable de estimación, E, se obtiene como una medida ponderada de las estimaciones LDC o PF óptima (a), más probable (m) y pesimista (b).
![Page 33: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/33.jpg)
Estimación basada en el Proceso
• Técnica más habitual• El proceso se descompone en actividades o
tareas y el esfuerzo requerido para llevar a cabo cada tarea
• Se presentan las tareas en forma de tabla
![Page 34: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/34.jpg)
Pasos de la Estimación basada en el Proceso
• delimitar las funciones obtenidas a partir del ámbito del software
• actividades del proceso para cada función• estimación de esfuerzo (persona-mes) para cada
actividad• en cada función• aplicación de índices de trabajo medios (esfuerzo
coste/unidad) al esfuerzo estimado para cada actividad• cálculo de costes y esfuerzo de cada función y de la
actividad
![Page 35: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/35.jpg)
Ejemplo
![Page 36: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/36.jpg)
Estimación basada en Casos de Uso
• Permiten que el equipo de software comprenda mejor el ámbito y los requisitos.
• El uso de casos de uso es a veces problemático porque:– no existe un formato estándar.– Representan una visión externa con diferentes grados de
abstracción– No abordan la complejidad de las funciones ni de las
características• Los expertos recomiendan no usar mas de 10 casos de
Uso con no mas de 30 escenarios
![Page 37: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/37.jpg)
Metodología General a Usar con Estimación de Casos de Uso
![Page 38: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/38.jpg)
¿Cómo Estimar usando
Casos de Uso?
![Page 39: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/39.jpg)
Reconciliación de Estimaciones
• La estimacion por LDC, PF y basadas en el proceso se realizan independientemente.
• Cuando se tienen algunas estimaciones de costo y esfuerzo se pueden comparar y armonizar.
• Si tienen un buen grado de concordancia son confiables las estimaciones.
• Si son poco concordantes los resultados de las estimaciones, entonces se debe investigar y analizar mejor
![Page 40: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/40.jpg)
Técnicas Delfi• Desarrolladas con el fin de obtener el consenso de un grupo de expertos sin contar
con los efectos negativos de las reuniones de grupos. La técnica puede adaptarse a la estimación de costos de la siguiente manera:
• Un coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.
• Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar con el coordinador, pero no entre ellos.
• El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.
• Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos 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.
• El proceso se repite varias veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.
![Page 41: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/41.jpg)
Modelos Empíricos de Estimación
Modelos empíricos de estimación:• Utilizan fórmulas derivadas empíricamente para
predecir el esfuerzo como una función de LDC o PF.• Datos empíricos obtenidos de una muestra de
proyectos:– difíciles de usar para todas las clases de software y
todos los entornos de desarrollo– se deben calibrar para las condiciones específicas de
una organización
![Page 42: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/42.jpg)
Ecuaciones de los Modelos Empiricos
![Page 43: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/43.jpg)
Observaciones
• Se nota claramente que cada uno de los modelos (ecuaciones) producira un resultado diferente para los mismos valores de LDC o PF.
• Los modelos deben CALIBRARSE para las necesidades locales
![Page 44: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/44.jpg)
Cocomo• El Modelo Constructivo de Costos (COnstructive COst Model) 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)• donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de
desarrollo en meses cronológicos y KLDC es el número estimado de Líneas de Código distribuídas (en miles) para el proyecto.
• 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.
![Page 45: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/45.jpg)
Jerarquías de Cocomo• El 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.
• El 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.
• El 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.
![Page 46: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/46.jpg)
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).
• 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).
• 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).
![Page 47: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/47.jpg)
Cocomo Ejemplo
• El chino lo pondra en esta diapo
![Page 48: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/48.jpg)
![Page 49: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/49.jpg)
COCOMO II
• Es una Evolución del COCOMO original propuesto por Boehm
• Aborda las siguientes áreas:– Modelo de composición de la aplicación– Modelo de la etapa de diseño temprano– Modelo de etapa posterior a la arquitectura
• Tres opciones de Tamaño:– Puntos de Funcion PF– Lineas de Codigo Fuente LDC– Puntos Objeto PO
![Page 50: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/50.jpg)
Puntos Objeto
• Son una manera indirecta de calcular el tamaño del software por medio de conteo de:– Pantallas de interfaz de usuario– Reportes– Componente requeridos para las construcción de la
aplicación.• Las ponderaciones se basan en una tabla• Se determina el numero de PO y se multiplica por la
ponderacion• Se suman todos los resultados para obtener una cuenta
total de PO.
![Page 51: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/51.jpg)
Puntos Objeto
• Estimando el % de reutilizacion se ajusta la cuenta de PONPO = (PO) * [(100- %reut)/100]
• Para obtener la estimacion de esfuerzo se debe calcular la tasa de ProductividadPROD = NPO/persona-mes
• Una vez obtenida pasamos a estimar el esfuerzoEsfuerzo Estimado = NPO/PROD
![Page 52: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/52.jpg)
La Ecuación del Software
• Es un modelo multivariable• Supone una distribución especifica del
esfuerzo a lo largo de la vida del proyecto– E = [LDC * B0.333/P]3 * (1/t4)• E = Esfuerzo en Personas-mes o Personas-año• T = duración del proyecto en meses o años• B = “Factor especial de habilidades”• P = Parámetro de productividad
![Page 53: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/53.jpg)
TÉCNICAS DE ESTIMACIÓN
ESPECIALIZADAS
![Page 54: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/54.jpg)
Estimación Orientada a Objetos• Estimaciones en PF o LDC• Aplicar el modelado de análisis OO.• Determinar el numero de Clases
Clave• Categorizar el tipo de interfaz para
la aplicación y desarrollar un multiplicador
• Multiplicar el numero total de clases por el numero promedio de unidades de trabajo por clase.
Tipo de Interfaz Multiplicador
Sin GUI 2.0
Interfaz basada en texto
2.25
GUI 2.25
GUI Compleja 3.0
![Page 55: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/55.jpg)
Estimación para Desarrollo Ágil
• Los requerimiento en este tipo de proyectos se presentan como un conjunto de escenarios de usuario.
• Se puede estimar de manera mas informal.• Se usan los enfoques de LDC o PF orientados a
escenarios
![Page 56: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/56.jpg)
Los Expertos Dicen
• Es mejor Comprender el trasfondo de una estimación antes de utilizarla.
![Page 57: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/57.jpg)
Estimación para Ingeniería Web• Los proyectos WEB adoptan el modelo de desarrollo ágil• Se usa un enfoque de puntos de función modificado– Entradas: Cada pantalla o formato de entrada incluidas las de
mantenimiento (CGI o JAVA)– Salidas: Cada pagina Web estática, cada guion de pagina Web
dinámica y cada reporte (ASP, DHTML)– Tablas: Cada tabla lógica en la DB y cada objeto XML– Consultas: Cada interfaz publicada externamente (referencias
externas DCOM o COM)• Los PF son un indicador razonable del volumen para un
WebApp
![Page 58: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/58.jpg)
¿DESARROLLAR O COMPRAR?
![Page 59: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/59.jpg)
Árbol de Decisión• La organización tiene estas opciones:1. Construir el Sistema desde 02. Reutilizar Componentes existentes de
“experiencia parcial”3. Comprar un Producto disponible y
modificarlo.4. Contratar una empresa externa para el
desarrollo.
![Page 60: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/60.jpg)
Árbol de DecisiónSistema X
Construir
Simple (0.30)
Difícil (0.70)
Reutilizar
Cambios Menores (0.40)
Cambios Mayores (0.6)
Simple (0.2)
Complejo (0.8)
Comprar
Cambios Menores (0.70)
Cambios Mayores (0.30)
Contratar
Sin Cambios (0.60)
Con Cambios (0.40)
$ 380000
$ 450000
$ 275000
$ 310000
$ 490000
$ 210000
$ 400000
$ 350000
$ 500000
![Page 61: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/61.jpg)
Subcontratación
• Es extremadamente simple.• Las actividades de ingeniería del software se
contratan con una tercera parte que realiza el trabajo a un costo mas bajo
• Efecto negativo que la compañía pierde cierto control sobre el software
• Corre el riesgo de poner el destino de su competitividad en manos de una tercera parte
![Page 62: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/62.jpg)
¿Cuáles son las claves del éxito?
• “Q: What are the most exciting/promising software engineering ideas or techniques on the horizon?
• A: I don’t think that the most promising ideas are on the horizon. They are already here and have been here for years but are not being used properly.”
• David L. Parnas
![Page 63: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/63.jpg)
¿A qué se refiere Parnas?
PRÁCTICAS EN PLANIFICACIÓN – GESTIÓN DE PROYECTOS• Automated estimation tools (1973)• Evolutionary delivery (1988)• Measurement (1977)• Productivity environments (1984)• Risk management planning (1981)PRÁCTICAS EN INGENIERÍA DE REQUISITOS• Change board (1979)• Throwaway user interface prototyping (1975)• JAD sessions (1985)• Requirements (1989)
![Page 64: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/64.jpg)
CALENDARIZACIÓN
![Page 65: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/65.jpg)
En que consiste la Calendarización
• En crear una rede de tareas de ingeniería que le permitirán tener el trabajo listo a tiempo.
• Una vez creada la red debe asignar responsabilidades a cada tarea
• Asegurarse que las tareas se realicen• Adaptar la red conforme los riesgos se vuelvan
realidad
![Page 66: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/66.jpg)
¿Por qué es importante?
• Construcción de un sistema complejo • Tareas de ingeniería ocurren en paralelo• Resultado de trabajo realizado durante una
tarea pude tener un profundo efecto en el trabajo llevado a cabo en otra tarea.
• Interdependencia difíciles de entender sin calendarización
![Page 67: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/67.jpg)
Calendarización Adecuada
• Requiere:• Que todas las tareas aparezcan en la red• Esfuerzo y tiempo asignados inteligentemente
por tarea• Interdependencias entre tareas indicadas
adecuadamente• Recursos asignados para el trabajo• Hitos espaciados de modo cercano para poder
seguir el progreso
![Page 68: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/68.jpg)
¿Por qué se entregan el software con retraso?
• Fecha limite irrealizable establecida por externo e impuesta
• Cambio en los requisitos no reflejados en modificaciones en la calendarización
• Subestimación de la cantidad de esfuerzo y recursos• Riesgos no considerados (Predecibles y no Predecibles)• Dificultades humanas imprevisibles• Dificultades técnicas no previstas• Falta de Comunicación entre el personal• Falla en la Gestión del Proyecto
![Page 69: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/69.jpg)
Los Expertos dicen
• “Cualquier comandante en jefe que pretenda lleva a cabo un plan que considera defectuoso comete un error; debe exponer sus razones, insistir en que el plan debe cambiarse y finalmente presentar su renuncia en lugar de ser el instrumento de la destrucción de su ejercito”
• Napoleón
![Page 70: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/70.jpg)
“Adoro las Fechas limite. Me gusta cuando pasan como una
exhalación cuando se alejan.”
Douglas Adams
![Page 71: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/71.jpg)
Lo que no se debe hacer
• Presentarse ante el cliente y demandarle que cambie la fecha de entrega impuesta por el mercado.
• Rechazar el trabajo¿Que hacer?• Estimación Detallada• Aplicar un Modelo de proceso Incremental• Explicar al cliente por que la fecha es irrealizable con
la estimación detallada• Funcionalidad faltante se entregara despues
![Page 72: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/72.jpg)
Generalidades
• Objetivo del gestor– Definir tareas– Construir la red de tareas– Bosquejar las interdependencias entre las tareas– Identificar las tareas cruciales y darles seguimiento
• La calendarización evoluciona a lo largo del tiempo.
• Una calendarización Macroscópica se realiza durante las primeras etapas de la planificación
![Page 73: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/73.jpg)
Generalidades
• Cientos de tareas deben realizarse para completar la meta mayor
• Algunas tareas se pueden completar sin preocuparse de su impacto sobre la fecha de terminación del proyecto
![Page 74: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/74.jpg)
Principios Básicos de Calendarización
• Compartimentación• Interdependencia• Asignación de Tiempo• Validación del Esfuerzo• Definición de Responsabilidades• Definición de Resultados• Definición de Hitos
![Page 75: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/75.jpg)
Interdependencia
• Algunas tareas deben ocurrir en secuencia• Otras pueden ocurrir en paralelo• Algunas tareas no pueden comenzar mientras
el producto de trabajo producido por otras tareas no este disponible
![Page 76: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/76.jpg)
Asignación de Tiempo
• A cada tarea se debe asignar cierto numero de unidades de trabajo (personas – días de esfuerzo)
• Asignar fecha de inicio y terminación en función de las interdependencias
![Page 77: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/77.jpg)
Relación entre Personal y Esfuerzo
• Mito: “Si nos retrasamos en la calendarización siempre podemos incorporar mas programadores y recuperarnos mas adelante en el proyecto”.
• Esto tiene un efecto perturbador en el equipo de trabajo
• Provoca mas desfases• Las personas agregadas recientemente deben
aprender el sistema y la gente que les enseña es la misma que estaba trabajando
![Page 78: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/78.jpg)
Relación entre Personal y Esfuerzo
• Las calendarizaciones de proyecto son elásticas.
• Es posible comprimir en cierta medida la fecha de terminación deseada del proyecto (al añadir recursos adicionales).
![Page 79: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/79.jpg)
Curva Putnam-Norden-Rayleigh (PNR)
![Page 80: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/80.jpg)
Curva Putnam-Norden-Rayleigh (PNR)
• Indica que un proyecto no se puede comprimir mas allá de 0.75 td
• Si se intenta mayor compresión el proyecto cae en la región imposible y el riesgo de fracaso se eleva mucho
• La opcion de entrega de menor costo es– to = 2td
• Esto implica que la demora en la entrega puede reducir los costos significativamente
![Page 81: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/81.jpg)
Curva Putnam-Norden-Rayleigh (PNR)
• La ecuación del software se obtiene de la curva PNR
• Relación enormemente lineal entre el tiempo cronológico para completar un proyecto y el esfuerzo humano aplicado a este.
• L = P * E1/3t4/3
• E = L3/(P3t4) es el esfuerzo humano en personas año durante el ciclo de vida para el desarrollo
• T es el tiempo en años
![Page 82: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/82.jpg)
Conclusiones de PNR
• Se pueden obtener beneficios al emplear menos personal durante un periodo un poco mas largo para lograr el mismo objetivo
![Page 83: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/83.jpg)
Distribución del Esfuerzo
• Regla 40-20-40• 40% de todos los esfuerzos se asignan al análisis y
el diseño de sistemas de entrada.• 40% en poner a prueba los sistemas de salida• 20% en codificación• Esta distribución de esfuerzo es solo una guía.• Las características del proyecto deben dictar la
distribución del esfuerzo.• Planeación = 2% – 3%
![Page 84: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/84.jpg)
10 CLAVESDE UN PROYECTO CON ÉXITO
• Evitar los errores clásicos• No ignorar las bases del desarrollo• Gestión activa del riesgo• Métodos de Planificación
![Page 85: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/85.jpg)
PLANIFICACIÓN…
![Page 86: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/86.jpg)
Visión Clara del Proyecto
• Sin una clara visión un proyecto puede terminar en cualquier punto.
• Los equipos trabajan para lograr las metas que se les fijan.
• Muchos Objetivos = no Objetivos• Una buena visión establece prioridades¿Qué tipo de desarrollo rápido quiere?• Speed oriented• Schedule-risk oriented• Visibility oriented
1
![Page 87: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/87.jpg)
Requisitos estables, completos y escritos2
![Page 88: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/88.jpg)
Los cambios en los requisitos…
Riesgo más común en un proyecto• Requisitos estables al 100% es casi imposible• La mayoría de los cambios en los requisitos
vienen de requisitos que definidos de forma incompleta la primera vez, y no por “cambios de mercado” u otras razones similares.
![Page 89: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/89.jpg)
Técnicas para definir Requisitos estables
• Requirements workshop• User interface prototyping• User interview• Use cases• User manual• Usability studies• Incremental delivery• Requirements reviews/inspections
![Page 90: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/90.jpg)
Prototipos de Interfaz de Ususario
Técnica Orientada al riesgo más común en un proyecto... El cambio en los requisitos
• Implican a los usuarios de forma amigable• Bajo coste, corta planificación y alta
satisfacción del usuario• Es necesario tener habilidad para desarrollar
prototipos exitosos
3
![Page 91: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/91.jpg)
Gestión de Proyectos Efectiva
• La “pobre” gestión – planificación es el segundo riesgo más común.
4
![Page 92: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/92.jpg)
Responsabilidades de un Jefe de Proyecto
• Una buena gestión software requiere (NECESITA) significativas habilidades.
• Estimación del Alcance• Análisis de Tiempo, Esfuerzo y Coste• Selección del Ciclo de Vida• Planificación de la Calidad• Personal Técnico• Gestión de Riesgos
![Page 93: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/93.jpg)
Estimaciones Precisas
• Las expectativas Injustificadas o no realistas son la mayor causa de los problemas
• El estado del arte es dramáticamente mejor que el estado de la práctica
5
![Page 94: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/94.jpg)
Exactitud de la Estimación y mejora
![Page 95: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/95.jpg)
Resultados Reales como Porcentaje deResultados Estimados
![Page 96: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/96.jpg)
Efecto de la Estimación
![Page 97: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/97.jpg)
Estimación Precisa
• La estimación es una habilidad técnica especializada
• Tratar la estimación como un mini proyecto• Tener un plan de reestimación periódica
![Page 98: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/98.jpg)
“No morir por la planificación”
• Evitar las dos causas de sobre planificación...• Planes inamovibles• Planes excesivamente detallados
6
![Page 99: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/99.jpg)
Ajuste en la Planificación
Tiempo
![Page 100: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/100.jpg)
Enfoque en la Calidad7
![Page 101: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/101.jpg)
![Page 102: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/102.jpg)
¿Por qué centrarse en la calidad?
• En la mayoría de los proyectos, el trabajo de corregir defectos no previstos es el mayor coste (40 – 80 % del total)
• Centrarnos en la calidad tiene un impacto económico positivo
• La calidad debe ser planificada durante el proyecto, no
• puede añadirse al final
![Page 103: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/103.jpg)
No olvidar las bases del desarrollosoftware
• Los fundamentos de Gestión• Siempre antes que los de Ingeniería• Estimación, Planificación, Seguimiento y
Medición• Las Bases Técnicas• Requisitos, Diseño, Construcción, Gest.
Configuración, etc.• Las Bases del Control de Calidad• Pruebas, Inspecciones, etc.
8
![Page 104: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/104.jpg)
Gestión Activa de los Riesgos9
![Page 105: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/105.jpg)
![Page 106: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/106.jpg)
Sobre la Gestión de Riesgos…• Según un estudio de KPMG…• 55% de los proyectos descontrolados no tenían gestión de riesgos• 38% tenían algo, pero la mitad de estos no usó los riesgos
hallados una vez que el proyecto comenzó• 7% no sabe si utilizó gestión de riesgos• sobre un 80% de los proyectos comenzados no mantenían una
gestión de riesgos significativa• Más del 50% de los proyectos muestran sus problemas durante
el inicio del desarrollo• Sobre el 25% muestran sus problemas durante la planificación
inicial
![Page 107: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/107.jpg)
![Page 108: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/108.jpg)
![Page 109: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/109.jpg)
![Page 110: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/110.jpg)
![Page 111: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/111.jpg)
Gestión de Riesgos
![Page 112: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/112.jpg)
![Page 113: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/113.jpg)
Riesgos más comunes (Best Hits)• Cambio en los Requisitos• Meticulosidad en Requisitos o Desarrollo• Escatimar en Calidad• Planificaciones Demasiado Optimistas• Diseño Inadecuado• Síndrome de la "Bala de Plata“• Desarrollo Orientado a la Investigación• Personal Mediocre• No definición de Roles y Responsables• Error en la Contratación• Diferencias entre Desarrolladores y Clientes• Falta de Sponsor• Falta de información del Usuario• Añadir gente a un proyecto retrasado• Sobreestimar de nuevas herramientas o métodos• Cambio de herramientas en mitad del proyecto• Falta de control automatizado del código fuente
![Page 114: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/114.jpg)
El Factor Humano
• Seguir Desarrollando
![Page 115: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/115.jpg)
![Page 116: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/116.jpg)
IEEE Std 830-1998
• Indica como realizar un documento de• especificación de requisitos de software (SRS).• • Establecer las bases para el acuerdo de lo que el• software realizará entre clientes y proveedores.• • Reducir el esfuerzo de desarrollo.• • Proveer las bases para estimar el costo y• calendarios.• • Proveer líneas base para validación y verificación• • Sirve de base para realizar mejoras.
![Page 117: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/117.jpg)
De aquí en Adelante son diapos que no se si van a ir en la presentacion final
![Page 118: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/118.jpg)
¿Por qué Planificar?
• • Boehm, 1975: 45% de los errores tienen su origen• en los requisitos y en el diseño preliminar.• • DeMarco, 1984: 56% de los errores que tienen• lugar en un proyecto software se deben a una mala• especificación de requisitos.• • Chaos Report, 1995: Los factores principales que• conducen al fracaso en los proyectos software son:• – Falta de comunicación con los usuarios.• – Requisitos incompletos.• – Cambios a los requisitos.
![Page 119: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/119.jpg)
¿Es lo Mismo?
![Page 120: Planificacion De Proyectos De Software](https://reader035.vdocuments.pub/reader035/viewer/2022081504/557585c8d8b42ae7708b45f2/html5/thumbnails/120.jpg)
Estimación basada en Casos de Uso
• La construcción de software es “human-intensive”.• Software es intangible.• El software depende del hardware y de otro
software.• Más y más sistemas son actualmente controlados
por software.• Una de las partes más críticas de un proyecto
informático es averiguar lo que costara desarrollarlo.