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. ¿ 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. 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. 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. 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. 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. 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. ? ¿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. Cómo?
¿Qué debe hacer una
empresa para obtener
software de buena
calidad?
Mejorar el proceso de
desarrollo de software
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. ¿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. 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. 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. 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. 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. 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. 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. 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