Planificacion De Proyectos De Software
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Planificacion De Proyectos De Software

  • 26,580 views
Uploaded on

Como realizar una buena planificacion de proyectos en el software,,,, beta

Como realizar una buena planificacion de proyectos en el software,,,, beta

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
26,580
On Slideshare
24,048
From Embeds
2,532
Number of Embeds
6

Actions

Shares
Downloads
1,060
Comments
3
Likes
6

Embeds 2,532

http://www.tecnar.edu.co 1,324
http://eadsaia.uft.edu.ve 1,131
http://splavia.tecnar.edu.co 46
http://www.slideshare.net 29
http://cms.sistemas2psm.webnode.com.ve 1
http://sistemas2psm.webnode.com.ve 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Planificación de Proyectos de Software
    Iván Sánchez
    Ronald Sáenz
    Gissellor
    Karen Navarro
    Muñoz
    Andrea Estrella
    Katichula
    Megan Fox
  • 2. 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…
  • 3. 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.
  • 4. 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.
  • 5. 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.
  • 6. Actividades
    La planificación del proyecto del software abarca 5 grandes actividades:
    • Estimación
    • 7. Programa de Trabajo
    • 8. Análisis de Riesgos
    • 9. Planificación de la Gestión de Calidad
    • 10. Planificación de la Gestión del Cambio
  • 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
  • 11. 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.
  • 12. La Estimación
    Variabilidad en requisitos = inestabilidad
    Un gestor no debe obsesionarse con las estimaciones.
  • 13. 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.
  • 14. Ambito del Software
    Describe:
    Funciones
    Características
    Entradas
    Salidas
    Contenido a Presentar
    Desempeño
    Restricciones
    Interfaces
    Confiabilidad a entregar al Usuario final.
  • 15. 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.
  • 16. Factibilidad
    Cuatro elementos esenciales:
    Tecnología
    Finanzas
    Tiempo
    Recursos
  • 17. Recursos
    Divididos en Tres Grandes Categorías:
    Personal
    Componentes de Software Reutilizables
    Entorno
  • 18. La Trinidad
  • 19. Recursos Humanos
    El planificador debe especificar:
    Habilidades Requeridas
    Posición Organizacional
    Especialidad
    El personal puede estar Geográficamente disperso.
  • 20. 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
  • 21. Recursos del Entorno
    Hardware
    Software (Herramientas de Desarrollo)
  • 22. Estimación
    Un gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.
  • 23. 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
  • 24. ¿Como lograr estimaciones Confiables?
  • 25. Estimación
    Usar Datos Históricos
  • 26. 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
  • 27. Tamaño del Software
  • 28. Estimación Basada en el Problema
    Métricas basadas en la Productividad
    LDC/pm
    PF/pm
    Combinaciones
  • 29. Estimación Basada en el Problema
  • 30. Estimación
    Una mejor estimación viene dada por:
    S = (Sopt + 4Smed + Spes)/6
    cálculo de la desviación de las estimaciones
  • 31. Estimación basada en LDC
    Descomposición funcional absolutamente esencial
    considerables niveles de detalle
    LDC se estima directamente.
  • 32. Ejemplo
  • 33. 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.
  • 34. Ejemplo
  • 35. 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).
  • 36. 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
  • 37. 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
  • 38. Ejemplo
  • 39. 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
  • 40. Metodología General a Usar con Estimación de Casos de Uso
  • 41. ¿Cómo Estimar usando Casos de Uso?
  • 42. 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
  • 43. 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.
  • 44. 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
  • 45. Ecuaciones de los Modelos Empiricos
  • 46. 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
  • 47. Cocomo
    El 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)
    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.
  • 48. 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.
  • 49. 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).
  • 50. Cocomo Ejemplo
    El chino lo pondra en esta diapo
  • 51.
  • 52. 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
  • 53. 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.
  • 54. Puntos Objeto
    Estimando el % de reutilizacion se ajusta la cuenta de PO
    • NPO = (PO) * [(100- %reut)/100]
    Para obtener la estimacion de esfuerzo se debe calcular la tasa de Productividad
    • PROD = NPO/persona-mes
    Una vez obtenida pasamos a estimar el esfuerzo
    • Esfuerzo Estimado = NPO/PROD
  • 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
  • 55. Técnicas de Estimación especializadas
  • 56. 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.
  • 57. 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
  • 58. Los Expertos Dicen
    Es mejor Comprender el trasfondo de una estimación antes de utilizarla.
  • 59. 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
  • 60. ¿Desarrollar o Comprar?
  • 61. Árbol de Decisión
    La organización tiene estas opciones:
    Construir el Sistema desde 0
    Reutilizar Componentes existentes de “experiencia parcial”
    Comprar un Producto disponible y modificarlo.
    Contratar una empresa externa para el desarrollo.
  • 62. Árbol de Decisión
    $ 380000
    $ 450000
    $ 275000
    $ 310000
    $ 490000
    $ 210000
    $ 400000
    $ 350000
    $ 500000
  • 63. 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
  • 64. ¿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
  • 65. ¿A qué se refiere Parnas?
    PRÁCTICAS EN PLANIFICACIÓN – GESTIÓN DE PROYECTOS
    Automated estimation tools (1973)
    Evolutionarydelivery (1988)
    Measurement (1977)
    Productivityenvironments (1984)
    Riskmanagementplanning (1981)
    PRÁCTICAS EN INGENIERÍA DE REQUISITOS
    Changeboard (1979)
    Throwawayuser interface prototyping (1975)
    JAD sessions (1985)
    Requirements (1989)
  • 66. Calendarización
  • 67. 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
  • 68. ¿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
  • 69. 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
  • 70. ¿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
  • 71. 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
  • 72. “Adoro las Fechas limite. Me gusta cuando pasan como una exhalación cuando se alejan.”
    Douglas Adams
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. 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
  • 77. 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
  • 78. 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
  • 79. 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
  • 80. 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).
  • 81. Curva Putnam-Norden-Rayleigh (PNR)
  • 82. 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
  • 83. 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
  • 84. Conclusiones de PNR
    Se pueden obtener beneficios al emplear menos personal durante un periodo un poco mas largo para lograr el mismo objetivo
  • 85. 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%
  • 86. 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
  • 87. PLANIFICACIÓN…
  • 88. 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?
    Speedoriented
    Schedule-riskoriented
    Visibilityoriented
    1
  • 89. Requisitos estables, completos y escritos
    2
  • 90. 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.
  • 91. Técnicas para definir Requisitos estables
    Requirementsworkshop
    User interface prototyping
    User interview
    Use cases
    User manual
    Usabilitystudies
    Incremental delivery
    Requirementsreviews/inspections
  • 92. 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
  • 93. Gestión de Proyectos Efectiva
    La “pobre” gestión – planificación es el segundo riesgo más común.
    4
  • 94. 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
  • 95. 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
  • 96. Exactitud de la Estimación y mejora
  • 97. Resultados Reales como Porcentaje deResultados Estimados
  • 98. Efecto de la Estimación
  • 99. 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
  • 100. “No morir por la planificación”
    Evitar las dos causas de sobre planificación...
    Planes inamovibles
    Planes excesivamente detallados
    6
  • 101. Ajuste en la Planificación
    Tiempo
  • 102. Enfoque en la Calidad
    7
  • 103.
  • 104. ¿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
  • 105. 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
  • 106. Gestión Activa de los Riesgos
    9
  • 107.
  • 108. 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
  • 109.
  • 110.
  • 111.
  • 112.
  • 113. Gestión de Riesgos
  • 114.
  • 115. 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
  • 116. El Factor Humano
    Seguir Desarrollando
  • 117.
  • 118. 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.
  • 119. De aquí en Adelante son diapos que no se si van a ir en la presentacion final
  • 120. ¿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.
  • 121. ¿Es lo Mismo?
  • 122. 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.