Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Monografía Problemas de-la-industria-de-software

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 18 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie Monografía Problemas de-la-industria-de-software (20)

Weitere von Leonardo Blanco (20)

Anzeige

Monografía Problemas de-la-industria-de-software

  1. 1. Problemas de la Industria de Software en la actualidad 1 Tendencia al crecimiento del volumen y complejidad de los productos. 2 Proyectos excesivamente tardes y se exige mayor productividad y calidad en menos tiempo. 3 Insuficiente personal calificado.
  2. 2. ¿ Por qué fallan los Proyectos ? de Software? 1 Planificación Irreal 2 Mala Calidad del Trabajo 3 Personal Inapropiado 4 No Controlar los Cambios 2
  3. 3. Planificación Irreal 1 “El sistema es para hoy y con costo 0” Los ingenieros no son capaces de enfrentar un plan porque: • NO están entrenados para usar métodos de planificación. • Frecuentemente, las estimaciones NO se basan en datos reales. 3
  4. 4. 2 Mala Calidad del Trabajo CAUSAS •Prácticas pobres de ingeniería •Carencia de métricas de calidad •Inadecuado entrenamiento en calidad •Decisiones de los directivos guiadas 4
  5. 5. 2 Mala Calidad del Trabajo CONSECUENCIAS • Tiempos de pruebas impredecibles • Productos con muchos defectos • Demoras en la aceptación de los usuarios • Extensa garantía de servicio y reparaciones “Una pobre calidad afecta la planificación y torna ineficente el proceso de prueba” 5
  6. 6. 3 Personal Inapropiado • Demora del personal PROBLEMAS • Escaso personal COMUNES • Miembros del equipo a tiempo parcial • Personal con conocimientos inapropiados • El trabajo se demora o descuida CONSECUENCIAS • Trabajo ineficiente • Sufre la moral del equipo Con independencia del plan, los proyectos deben comenzar en tiempo y con todo el personal. 6
  7. 7. Cambios NO controlados 4 HECHOS a RECORDAR: • Siempre ocurren cambios en los requerimientos. • Los planes del proyecto se basan en el alcance del trabajo conocido. • Los cambios siempre requieren más trabajo. • Sin planes detallados, los equipos no pueden estimar el efecto o magnitud de los cambios. • Si los equipos no controlan cada cambio, se pierde gradualmente el control del plan del proyecto 7
  8. 8. ? ¿Cómo enfrentarla? Las organizaciones requieren: 1 Desarrollar o adquirir una disciplina en el desarrollo del software. 2 Controlar que los ingenieros usen de forma consistente los nuevos métodos. 8
  9. 9. Cómo? ¿Qué debe hacer una empresa para obtener software de buena calidad? Mejorar el proceso de desarrollo de software
  10. 10. Cualquier modelo de calidad para mejorar el Proceso de Desarrollo de Software, IMPLICA utilizar los métodos y procedimientos de INGENIERIA Y GESTION DE SOFTWARE 10
  11. 11. ¿Qué es la Ingeniería de Software (IS)? “...la aplicación de un enfoque sistémico, disciplinado y cuantificable hacia el desarrollo, funcionamiento y mantenimiento de software, es decir la aplicación de ingeniería al software” IEEE,1993 11
  12. 12. IS es una tecnología multicapa Indican cómo construir técnicamente el Sw. Soporte automático o semiautomático para el proceso y los métodos. Es el fundamento de la IS. Es la unión que mantiene juntas las capas de la tecnología. 12
  13. 13. Síntomas - Causas Síntomas Diagnóstico Causas • necesidades usuarios • requerimientos insuficientes • requerimientos cambiantes • comunicación ambigua • módulos no calzan • arquitecturas frágiles • poco mantenible • complejidad excesiva • tardía detección • inconsistencias no detectadas • baja calidad • prueba pobre • baja performance • evaluación subjetiva • versiones y cambios • desarrollo en cascada • liberación y distribución • cambios no controlados • automatización insuficiente ...tratar los Síntomas no resuelve el problema 13
  14. 14. Las Mejores Prácticas de la IS atacan las causas Desarrolle Iterativamente Administre Use Verique Requerimientos arquitectura Modele Calidad de Visualmente componentes Controle Cambios 14
  15. 15. Mejores Prácticas de Software Son propuestas de desarrollo probadas comercialmente, que usadas en forma combinada atacan la raíz de las causas de las fallas, eliminando los síntomas y permitiendo el desarrollo y mantenimiento de software de calidad de manera predictiva y reiterativa. 15
  16. 16. Mejores Prácticas: Equipos de Alto Rendimiento Resultado • Proyectos más exitosos Ing. de porque están en plazo, en Performance presupuesto y satisfacen Analisis las necesidades del usuario Jefe de Develop Iteratively Proyecto Desarrollador Use Model Manage Component Visually Verify Requiremen Architectures Quality Probador ts Control Changes Liberación y Distribución 16
  17. 17. Enfrentando las Causas se eliminan los Síntomas SÍNTOMAS CAUSAS MEJORES PRÁCTICAS Requerimientos desarrolle iterativamente necesidades usuarios insuficientes requerimientos adm. requerimientos Comunicación ambigua cambiantes use arquitectura de arquitecturas frágiles componetes módulos no calzan complejidad excesiva modele el software poco mentenible inconsistencias no visualmente tardía detección detectadas verifique calidad baja calidad testing pobre controle cambios baja performance evaluación subjetiva versiones y cambios desarrollo en cascada liberación y distribución cambios no controlados automatización insuficiente 17
  18. 18. Mejores Prácticas se refuerzan entre si Asegura participación del usuario Administre mientrás evolucionan requerimientos Requerimientos Valida tempranamente Use Arquitecturas las decisiones arquitectónicas de Componentes Desarrolle Pemite manejar la complejidad Modele Iterativamente Visualmente de diseñar incrementalmente Mide la calidad en forma oportuna Verique y frecuente Calidad Evoluciona la línea base Controle incrementalmente Cambios 18

×