Ingenieria software

1,766 views
1,548 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,766
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
123
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ingenieria software

  1. 1. 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…
  2. 2. 1 Estimar 2 Planificar
  3. 3. ESTIMAR-> MIRAR AL FUTURO Y ACEPTAR CIERTO GRADO DE INCERTIDUMBRE. El gestor y el equipo Realizar Estimación del trabajo Estimación de recursos Estimación del tiempo
  4. 4.  COMPLEJIDAD DEL PROYECTO  TAMAÑO DE PROYECTO  GRADO DE INCERTIDUMBRE ESTRUCTURAL
  5. 5. Establecer plan de proyectos Defina Tareas Fechas clave Identificar responsables por tareas Especificar dependencia por tareas
  6. 6. El objetivo Se logra Proceso de descubrimiento de la información Proporciona Marco de trabajo Permita realizar Estimación del trabajo Estimación de recursos Estimación del tiempo
  7. 7.  Control  Datos a procesar  Función  Rendimiento  Restricciones  Interfaces  Fiabilidad Describe Primera tarea de la planificación de proyectos
  8. 8. Preguntas de contexto libre • ¿Quién esta detrás de la solicitud de trabajo? • ¿Quién utilizará la solución? • ¿Cuál será el beneficio económico de una buena solución? • ¿Hay otro camino para la solución? Comprender mejor el problema • ¿Cómo caracterizaría un resultado correcto que se generaría de una solución satisfactoria? • ¿Con qué problema se enfrentará esta solución? • ¿Hay aspecto o limitaciones especiales de rendimiento que afecten a la forma en que se aborde la solución? Meta-cuestiones Efectividad de la reunión. • ¿Es usted la persona apropiada para responder a estas preguntas? • ¿Son relevantes mis preguntas para su problema? • ¿Estoy realizando muchas preguntas? • ¿Hay alguien más que pueda proporcionar información adicional? • ¿Hay algo más que debería preguntarle?
  9. 9.  Lectura de la entrada del código de barras.  Lectura del tacómetro de pulsos.  Descodificación de los datos del código de pieza.  Búsqueda en la base de datos.  Determinación de la posición del comportamiento.  Producción de la señal de control para el mecanismo de maniobra. Funciones importantes:
  10. 10. Acometer el esfuerzo de desarrollo de software Segunda tarea de la planificación de proyectos Personal Software Reutilizable Entorno Desarrollo
  11. 11. El Planificador debe especificar Habilidades Requeridas Posición organizacional Especialidad
  12. 12.  Componentes ya desarrollados  Componentes ya experimentados  Componentes con experiencia parcial  Componentes nuevos No inventar el Agua Tibia
  13. 13. 1 • Si los componentes ya desarrollados cumplen los requisitos del proyecto, adquiéralos. 2 • Si se dispone de componentes ya experimentados, los riesgos asociados a la modificación y a la integración se aceptan. 3 • Si se dispone de componentes de experiencia parcial para el proyecto actual, su uso se debe analizar con detalle.
  14. 14.  Incorpora hardware y software  Se debe determinar el entorno de hardware y software y verificar que estén disponibles.
  15. 15.  Un gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida. Mala Estimación Desastre para el Desarrollador Tercera tarea de la planificación de proyectos
  16. 16. Implica muchas variables • Humanas • Técnicas • Ambientales • Políticas • etc Mientras mas se conozca menos errores serios se cometerán. Nunca es exacta
  17. 17. Basarse en proyectos similares Descomposición Simple Uso de Modelos Empíricos
  18. 18. USAR DATOS HISTORICOS
  19. 19. TECNICAS DE DESCOMPOSICION MODELOS EMPIRICOS HERRAMIENTAS AUTOMÁTICAS
  20. 20.  DESCOMPONER EL PROBLEMA EN CONJUNTO DE PEQUEÑOS PROBLEMAS.  SE DEBE DEFINIR ANTES EL TAMAÑO DE SOFTWARE 1. Estimación basada en el problema 2. Estimación basada en el proceso
  21. 21. El 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 Estabilidad de los requisitos del software y el entorno que soporta el esfuerzo de la ingeniería de software.
  22. 22.  Métricas basadas en la Productividad  LDC/pm  PF/pm  Combinaciones
  23. 23. Optimista Mas Probable Pesimista Valor Esperado
  24. 24. Descomposición funcional absolutamente esencial Considerables niveles de detalle LDC se estima directamente.
  25. 25. Datos geométricos
  26. 26.  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.
  27. 27.  Técnica más habitual  El proceso se descompone en actividades o tareas y el esfuerzo requerido para llevar a cabo cada tarea 2) Estimación Basada en el Proceso
  28. 28. 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
  29. 29.  Utilizan formulas empíricas para predecir el esfuerzo.  Los datos con los que se trabaja para estos modelos son datos resultantes de una muestra limitada de proyectos  Deben manejarse con prudencia.
  30. 30.  El Modelo Constructivo de Costos (COnstructive COst MOdel) es una jerarquía de modelos de estimación para el software.  Fue desarrollado por Boehm a finales de los años 70 y comienzos de los 80. COCOMO
  31. 31. Básico • calcula el esfuerzo del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas. 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. 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.
  32. 32. Modelo Orgánico • Proyectos de software relativamente pequeños y sencillos. • Trabajan pequeños equipos. • Con buena experiencia en la aplicación. • Conjunto de requisitos poco rígidos. Modelo Semiacoplado • Proyectos de software intermedios (en tamaño y complejidad). • Equipos intermedios • Con variados niveles de experiencia • Conjunto de requisitos poco o medio rígidos Modelo Empotrado • Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas programa de análisis termal desarrollado para un grupo calórico sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos software de control de navegación para un avión EJEMPLOS
  33. 33.  FALTA LO MIO LO DEL EJERCICIO
  34. 34. VS
  35. 35. Opciones de adquisición El software se puede comprar ya desarrollado. Se pueden adquirir componentes de software “totalmente o parcialmente experimentado”, y entonces modificarse e integrarse para cumplir las necesidades específicas. El software puede ser construido de forma personalizada por una empresa externa para cumplir las necesidades del comprador.
  36. 36. Sentido crítico del software Coste final
  37. 37. Menos caro comprar Menos caro experimentar Más caro es una evaluación de potenciales paquetes de software
  38. 38. Desarrollo de una especificación para la función y rendimiento del software deseado. Estimación de coste interno de desarrollo y la fecha de entrega. Selección de 3 o 4 aplicaciones candidatos que cumplan mejor las especificaciones. Selección de componentes de software reutilizables. Desarrollo de una matriz de comparación que permita una comparación una a una de las funciones clave. Evaluación de cada paquete de software o de componentes, según la calidad de productos anteriores, soporte del vendedor, dirección del producto. Contacto con otros usuarios de dicho software y petición del producto.
  39. 39. Coste de Soporte Externo Fecha entrega Coste de Adquisición
  40. 40. Es un apoyo a la decisión desarrollar – comprar. 1) Construir el sistema X desde el principio 2) Reutilizar los componentes existentes de “experiencia parcial” para construir el sistema 3) Comprar un producto de software disponible y modificarlo para cumplir las necesidades locales 4) Contratar el desarrollo del software a un vendedor externo
  41. 41.  Estrategia - táctica  Contratación a un tercero que hace el trabajo a bajo coste asegurando calidad. PRO CONTRA REDUCCION DE COSTES POR AHORRO DE INFRAESTRUCTURA AHORRO DE PERSONAL SE PIERDE EL CONTROL DEL SOFTWARE. PROCESOS QUEDAN EN MANOS DE TERCEROS
  42. 42.  Implementar en un software las técnicas de descomposición, o técnicas empíricas.  Permiten estimar costes y esfuerzo  Analizar “que pasa si”
  43. 43. Descripción del personal de desarrollo y/o entorno de desarrollo Estimación cuantitativa Características cualitativas
  44. 44. Yo se Lenguaje Ensamblador y Fortran. No necesito saber ingeniería de software A la larga 90 %
  45. 45. Se quedan estancados en el 90%, por no llevar una buena planificación, ni estimar un buen tiempo.
  46. 46. Fechas limite poco realista Cambio en los requisitos de los clientes Errores predecibles y no predecibles Dificultades técnicas no previstas Dificultades humanas Falta de comunicación entre el equipo de trabajo Falta de reconocimiento de retrasos
  47. 47. Es poco realista exigirle al cliente que cambie la fecha de entrega!!! Realizar una estimación en base a proyectos anteriores. Emplear modelo de proceso incremental Con bases explicar al cliente porque la fecha no es realista Ofertar estrategia al cliente Esfuerzo estimado. Duración Proyecto. Estrategia de desarrollo Apuntar estimaciones. Indicar mejora de porcentaje.
  48. 48. Evoluciona con el tiempo Planificación Temporal Detallada A media que progresa el proyecto Identifica y programa las tareas Planificación Temporal Macroscópica Durante las primeras etapas Identifica actividades y funciones
  49. 49. 1 • COMPARTIMENTACION 2 • INTERDEPENDENCIA 3 • ASIGNACION DE TIEMPO 4 • VALIDACION DE ESFUERZO 5 • RESPONSABILIDADES DEFINIDAS 6 • RESULTADOS DEFINIDOS 7 • HITOS DEFINIDOS
  50. 50. Proceso de Software eficaz debería Definir una colección de tareas Se diseñan Para acomodar diferentes proyectos diferentes grados de rigor
  51. 51. Proyectos de desarrollo de concepto Proyectos de desarrollo de una nueva aplicación Proyectos de mejoras de aplicaciones Proyectos de mantenimiento de aplicaciones Proyectos de reingeniería
  52. 52. Está en función de muchas características del proyecto Como se tratara al proyecto 4 grados de Rigor Casual Estructurado Estricto Reacción Rápida
  53. 53.  Tamaño de proyecto  Numero potencial de usuarios  Misión critica  Longevidad de la aplicación  Estabilidad de los requisitos  Facilidad de comunicación cliente/ desarrollador  Madurez de la tecnología aplicable  Limitaciones de rendimiento  Características empotradas/no empotradas  Personal del proyecto  Factores de reingeniería Se emplean para determinar el grado de rigor recomendado con el que el proceso de software debería aplicarse en un proyecto.
  54. 54. • Importancia de la distribución de un conjunto de tareas a lo largo de la duración del proyecto. • Cada uno de los tipos de proyectos puede enfocarse usando un modelo de proceso lineal, secuencial o iterativo
  55. 55. Ámbito del concepto Planificación preliminar del concepto Valoración del riesgo tecnológico Prueba del concepto Implementación del concepto Reacción del cliente ante el concepto
  56. 56. Tareas Principales Descomponer en sub-tareas Planificación Temporal Detallada
  57. 57.  Es una representación gráfica del flujo de tareas de un proyecto  Muestra las tareas principales de la ingeniería de software
  58. 58. • Técnica de evaluación y revisión de programaPERT • Método del camino críticoGANT
  59. 59. • Estimaciones de esfuerzo • Descomposición de la función del producto • Selección del modelo de proceso adecuado • Selección del tipo de proyecto y del conjunto de tareas Son dirigidas por la información ya desarrollada en actividades anteriores:
  60. 60.  En una red de trabajo, el esfuerzo, duración y fecha de inicio delas tareas se las puede definir como entradas.  Estas entradas generan un Grafico de tiempo Gráfico de Gantt UTILIDAD: SEGUIMIENTO DEL PROGRESO
  61. 61. Reuniones periódicas del estado del proyecto Evaluando resultados de las revisiones realizadas a lo lardo del proceso de ingeniería Determinando si se han conseguido lo planteado y en la fecha programada. Comparando la fecha real de inicio con las previstas para cada tarea del proyecto
  62. 62.  Se produce cuando se culminan todas las tareas de planificación.  Comunicar el ámbito y recursos a los gestores del software, personal técnico y al CLIENTE.  Definir los riesgos y sugerir técnicas de aversión al riesgo.  Definición de costes y planificación temporal  Proporcionar un enfoque general de desarrollo del software para el personal.  Describir como se garantizará la calidad.

×