Post on 24-Feb-2020
1
INGENIERÍA DE SOFTWAREProblemas, causas y soluciones
Grupo de Construcción de Software
Facultad de Ingeniería
Universidad 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
“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
3
“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”
4
“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.
5
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
Cliente o UsuarioDesarrollador
No saber cuál es el sistema que se
quiere construir:
LOS REQUERIMIENTOS
Desarrollador Cliente o Usuario
$$
10
Algunas causas
Durante la construcción
La ingeniería del software
No hacer diseños
ni especificaciones
ni documentación
Desarrollador Cliente o Usuario
$$
11
Algunas causas
Durante la construcción
La ingeniería del software
Programemos rápido para
tener tiempo de corregir y
entender lo que tocaba
hacer!!
Desarrollador Cliente o Usuario
$$
12
Algunas causas
Durante la construcción
La ingeniería del software
Se acabo el tiempo,
entreguemos lo que tenemos
y probamos después
(además, debería funcionar)
Desarrollador Cliente o Usuario
$$
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
DesarrolladorCliente o Usuario
Le puedo pagar
por 3 meses.
Cuánto tiempo estima
que se va a demorar ?
15
Algunas causas
Desarrollador
mmm ...
más o menos
3 meses (?)
Cliente o Usuario
Le puedo pagar
por 3 meses.
Cuánto tiempo
estima que se va
a demorar ?
Durante la construcción
La administración de la construcción
16
Algunas causas
C
Tenemos un contrato
pónganse a trabajar! Y el plan?
Departamento de Producción
de Software
Equipo de desarrollo
Para qué?
Igual nunca funciona
y tenemos sólo 3 meses
17
Algunas causas
Departamento de Producción
de Software
Equipo de desarrollo
C
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
Objects? Aspects? JSP?
Servlets? XML? 3-Tiers?
JEE5? SOA? BPEL?
mmm... No debe ser tan difícil
Desarrollador Cliente o Usuario
$$
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
Desarrollo
Años3
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
Desarrollo
Años3
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
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 ....
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?
3434
Proceso
Mediciones
Historia
Evaluación
Seguimiento/
Aseguramiento
Ciclo de mejoramiento continuo
35
¿Qué es la IS?
Es la disciplina del desarrollo y mantenimiento
de sistemas computacionales 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
36
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
37
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
….