1 INGENIERÍA DE SOFTWAREisis2603/... · 2010-09-10 · 1 INGENIERÍA DE SOFTWARE Problemas, causas...

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


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


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


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



Cliente o UsuarioDesarrollador

No saber cuál es el sistema que se

quiere construir:

LOS REQUERIMIENTOS

Desarrollador Cliente o Usuario

$$

10

Algunas causas



No hacer diseños

ni especificaciones

ni documentación


$$

11

Algunas causas



Programemos rápido para

tener tiempo de corregir y

entender lo que tocaba

hacer!!


$$

12

Algunas causas



Se acabo el tiempo,

entreguemos lo que tenemos

y probamos después

(además, debería funcionar)


$$

13

Algunas causas




La tecnología



Factores Humanos


14

Algunas causas



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 ?



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




La tecnología



Factores Humanos



$$

23

Algunas causas

Objects? Aspects? JSP?

Servlets? XML? 3-Tiers?

JEE5? SOA? BPEL?

mmm... No debe ser tan difícil


$$

24

Algunas causas




La tecnología



Factores Humanos



$$

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


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


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


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?




La tecnología



Factores Humanos


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


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 ....


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

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

….

1 INGENIERÍA DE SOFTWAREisis2603/... · 2010-09-10 · 1 INGENIERÍA DE SOFTWARE Problemas, causas...

Documents

Transcript of 1 INGENIERÍA DE SOFTWAREisis2603/... · 2010-09-10 · 1 INGENIERÍA DE SOFTWARE Problemas, causas...