Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería

1. INGENIERÍA DE SOFTWAREProblemas, causas y solucionesGrupo de Construcción de SoftwareFacultad de IngenieríaUniversidad de los Andes Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes

2. Agenda Motivación Problemas Causas Soluciones

3. “Casos” • Ingeominas – Sistema de información minera • Presupuesto: 857 millones / 6 meses • Análisis: 80 Casos de Uso • Diseño: 120 Clases • Implementación: 54 Clases • Tamaño promedio por Clase: 12.000 líneas de código. • Real: 1700 millones / 3 Años y 2 meses • La empresa desarrolladora no quiere cuantificar sus perdidas • En la revista semana de noviembre se dijo que el 1 de enero de este año el sistema entraba a producción

4. “Casos” • IDAC – Sistema de información de Catastro, Notariado y Registro • Presupuesto: 5630 millones / 12 meses • No se hizo diseño • Real: Se cancelo a los 5 años / 1 año de pleito legal • “Un proyecto de ingeniería se convirtió en un proyecto de Abogados”

5. “Casos” • Supernotariado y Registro • Actualizar sistema en COBOL a J2EE • Presupuesto: 1000 millones / 14 meses • Real: 2500 millones / 36 meses • Se entrego la aplicación en una nueva versión de COBOL.

6. Problemas Durante la construcción

7. Un panorama pesimista Insatisfacción del cliente porque el sistema no satisface sus requerimientos Abandono de los proyectos Desfases de 2 o más veces el tiempo y el costo estimado Mala calidad percibida como: errores frecuentes sistemas no confiables difícil de usar Sistemas difíciles de adaptar, extender, mejorar

8. Algunas causas Durante la construcción La ingeniería del software La administración de la construcción La tecnología Durante el mantenimiento La herencia del desarrollo Factores Humanos El proceso de cambio caótico

9. Algunas causas Durante la construcción La ingeniería del software $$ Desarrollador Cliente o Usuario Desarrollador Cliente o Usuario No saber cuál es el sistema que se quiere construir: LOS REQUERIMIENTOS

10. Algunas causas Durante la construcción La ingeniería del software $$ Desarrollador Cliente o Usuario No hacer diseños ni especificaciones ni documentación

11. Algunas causas Durante la construcción La ingeniería del software $$ Desarrollador Cliente o Usuario Programemos rápido para tener tiempo de corregir y entender lo que tocaba hacer!!

12. Algunas causas Durante la construcción La ingeniería del software $$ Desarrollador Cliente o Usuario Se acabo el tiempo, entreguemos lo que tenemos y probamos después(además, debería funcionar)

13. Algunas causas Durante la construcción La ingeniería del software La administración de la construcción La tecnología Durante el mantenimiento La herencia del desarrollo Factores Humanos El proceso de cambio caótico

14. Algunas causas Durante la construcción La administración de la construcción Le puedo pagar por 3 meses. Cuánto tiempo estima que se va a demorar ? Desarrollador Cliente o Usuario

15. Algunas causas • Durante la construcción • La administración de la construcción Le puedo pagar por 3 meses. Cuánto tiempo estima que se va a demorar ? mmm ... más o menos 3 meses (?) Desarrollador Cliente o Usuario

16. Algunas causas Tenemos un contrato pónganse a trabajar! Y el plan? Departamento de Producción de Software C Equipo de desarrollo

17. Algunas causas Para qué? Igual nunca funciona y tenemos sólo 3 meses Departamento de Producción de Software C Equipo de desarrollo

18. Algunas causas

19. Algunas causas Ud. Dijo que hacia esa parte

20. Algunas causas No, esa era su responsabilidad!

21. Algunas causas Cuánto se demoraron en total? Cuál fue el esfuerzo? Que tan grande es el sistema? Qué aprendimos?

22. Algunas causas Durante la construcción La ingeniería del software La administración de la construcción La tecnología Durante el mantenimiento La herencia del desarrollo Factores Humanos El proceso de cambio caótico $$ Desarrollador Cliente o Usuario

23. Algunas causas $$ Desarrollador Cliente o Usuario Objects? Aspects? JSP? Servlets? XML? 3-Tiers? JEE5? SOA? BPEL? mmm... No debe ser tan difícil

24. Algunas causas Durante la construcción La ingeniería del software La administración de la construcción La tecnología Durante el mantenimiento La herencia del desarrollo Factores Humanos El proceso de cambio caótico $$ Desarrollador Cliente o Usuario

25. Algunas causas 3 Años Desarrollo Mantenimiento • No se puede evitar porque el software DEBE evolucionar (corregir, mejorar, adaptar, extender ...) • El problema no es que haya que hacer mantenimiento sino que es muy costoso • Costo de desarrollar una línea: 30 dólares. Costo de mantenerla: 4000 dólares !! [Boehm]

26. Algunas causas 3 Años Desarrollo Mantenimiento • La importancia del problema: • Las consecuencias de los errores detectados cuando el sistema ya está en operación (pueden ser catastróficos) • El deterioro del software hasta su muerte • Clientes insatisfechos debido a la dificultad para satisfacer los nuevos requerimientos • Dificultades para tratar todas las solicitudes de modificación

27. Algunas causas Durante el mantenimiento La herencia del desarrollo: Se entrega antes de ser terminado y debidamente probado. No se tiene la documentación del sistema. La única manera para entender el software es a través de las líneas de código! Código escrito por varias personas, cada una con estilos y convenciones distintas, difícil entender el software. Malos diseños (o ausencia de ellos) que se traducen en software poco flexible, difícil de extender o adaptar.

28. Algunas causas Durante el mantenimiento Factores Humanos : Menosprecio hacia estas actividades de mantenimiento. Típicamente, los costos del mantenimiento son a menudo subestimados. Las personas menos expertas son designadas para mantener software, los equipos de mantenimiento trabajan en malas condiciones (las nuevas tecnologías y herramientas son dejadas para los proyectos nuevos!) y en general, las soluciones rápidas son a menudo adoptadas.

29. Algunas causas Durante el mantenimiento Deficiente proceso de cambio : los cambios son hechos sin evaluar su impacto, causando inconsistencias con otros productos, creando conflictos con solicitudes previas, etc. se agrava en la medida que los cambios se realizan concurrentemente por desarrolladores distintos. bajo la presión de tiempo, es difícil mantener actualizados los demás productos asociados del software como la documentación, los manuales, las pruebas, etc.

30. Discusión Cuáles de estos problemas les han ocurrido sus experiencias como desarrolladores? Cuáles son novedosos o inesperados de acuerdo a su experiencia? Qué soluciones podrían plantear? Durante la construcción La ingeniería del software La administración de la construcción La tecnología Durante el mantenimiento La herencia del desarrollo Factores Humanos El proceso de cambio caótico 30

31. Las propuestas de solución Mejorar las prácticas de ingeniería de software: Ingeniería (análisis, diseño, programación, pruebas,..) Procesos de administración (control de cambios, contrata, admin. riesgos, manejo personal, …) Tecnología Formación y entrenamiento de las personas

32. Las propuestas de solución Guiar a las organizaciones en la selección de estrategias para mejorar los procesos de desarrollo de software. Evaluación: Capability Maturity Model CMM SPICE Normatización: ISO 9001, ISO 10007, ISO ....

33. Las propuestas de solución Los estándares podrían funcionarnos Pero, en nuestra casa de SW nosotros ya hacemos las cosas de cierta manera (nuestro CAOS) Implementar un estándar es muy costoso Cómo podemos mejorar?

34. Ciclo de mejoramiento continuo Proceso Seguimiento/ Aseguramiento Evaluación Mediciones Historia 34

35. Soluciones Reporte CHAOS 2003 • 34% de los proyectos fueron exitosos • 100% mejora (16% en 1995) • 15% se cancelaron antes de ser culminados • 50% Mejora (31% en 1995)

36. ¿Qué es la IS? Es la disciplina del desarrollo y mantenimiento de sistemascomputacionales que se comportan de manera confiable y eficiente y que su costo de desarrollo y mantenimiento puede ser pagado [1] [1] Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. A Volume of the Computing Curricula Series. ACM y IEEEComputer Society. 2004

37. Ejes de IS Casallas Rubby, Villalobos, Jorge. “El actual ingeniero de Software”. Revista ACIS. Edición Nº 93 Julio - Septiembre de 2005. Descargable de: http://www.acis.org.co/index.php?id=547

38. Ejes de la IS Dependencias profundas entre los ejes: No se puede ser un buen diseñador sin saber de tecnologías No se puede diseñar el proceso sin tener en cuenta la Arquitectura El proceso tiene que ir apoyado por metodologías No se puede ser un buen director de proyecto sin saber del resto No se puede ser un buen arquitecto sin saber de tecnología No basta con saber de tecnología para ser un buen arquitecto ….

39. Este material fue preparado por Rubby Casallas Andrés Yie Nicolás López