El problema de la integración en grandes proyectos de software

imageUno de los desafíos más grandes a la hora de llevar adelante grandes proyectos de construcción de software es lograr integrar fluidamente las distintas partes en las que seguramente hemos dividido su construcción.

Hace muchos años me encontraba formando parte de un equipo de desarrollo numeroso que estaba abocado a construir un sistema en Java destinado a manejar la actividad “core” de la empresa. La construcción del sistema se estaba haciendo, obviamente, por partes y el responsable de todo el desarrollo había repartido entre distintos equipos la construcción de los módulos funcionales. 

Mi rol no era de desarrollo sino que estaba manejando temas de gestión del proyecto y testing. 

En un determinado momento, la construcción aislada de cada uno de los "silos" iba sobre ruedas (o inclusive más rápido de lo previsto) pero yo comencé a preocuparme por la integración de todas esas partes. Veía demasiado ensimismados a los grupos de trabajo y prestando muy poca atención a cómo iban a dialogar sus módulos con los demás. Mi hipótesis era que cuanto más tardásemos en abordar el tema de la integración, más difícil sería poner todo a funcionar.

A partir de eso comencé a insistir con el responsable del proyecto para hacer pruebas de integración en forma temprana. Haciendo corta la anécdota, no tuve éxito. Las pruebas de integración no comenzaron a planearse hasta después de haber terminado los módulos por separado. Al final, integrar los módulos nos demoró 3 veces el tiempo empleado para construir los módulos locales.

Esta fue la primera vez que me encontré con el problema pero no la última. He visto lo mismo en muchas otras situaciones: en desarrollos "desde cero", en implementaciones de producto(s) donde hay que realizar customizaciones, en instalación de productos que (supuestamente) sólo debe configurarse, en software que se construía utilizando las técnicas más sofisticadas de desarrollo (por ejemplo técnicas agile como TDD), etc.

La moraleja es que cuanto más grande el equipo de trabajo y mayor es la cantidad de piezas de software involucradas, más tiempo debemos destinar a la integración. A saber, definir qué integraciones habrá, definir cómo funcionarán, definir cómo se probarán, probarlas, etc.

Por último, para aquellos que quieran saber cómo se puede hacer esto, un buen comienzo es leer el ensayo “The Whole and the Parts” del libro The Mythical Man-Month de Fred Brooks.

Seguimos pensando..

Comentarios

  1. Marcelo Varela11/3/12, 10:37 p.m.

    Sin duda lo que planteas es una gran verdad, se minimiza la integración, hoy mucho mas complejas que las anteriores "migracioens", pero tan o mas complicadas que aquellas. He sido parte de proyectos dónde esto se minimizó y luego el tiempo nos hizo pagar las consecuentas

    ResponderBorrar
  2. Gracias Marcelo por tu comentario!

    Saludos,

    ResponderBorrar

Publicar un comentario

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing