[Las cosas que no interesan]

El Software

La Ingeniería de Software siendo una de las áreas que se desprende de las ciencias de la computación, cuenta con un alto nivel de incertidumbre en cuanto a sus metodologías, procesos, disciplinas, etc. Uno de los problemas con los que siempre hemos tenido que lidiar quienes estamos involucrados en el desarrollo de software es tratar de hacerlo un negocio rentable y predecible, por que sabemos que aproximadamente el 70% de este tipo de proyectos fracasan en cuanto a sus costos y tiempos. Esta aterradora cifra nos plantea inmediatamente la pregunta: ¿por qué si es un negocio que genera tantas pérdidas, tiene tantas empresas que siguen empecinadas en invertir en él?

Seguramente la respuesta a esta pregunta no es fácil, seguramente es un negocio que genera tanto pérdidas como ganancias y eso lo hace atractivo. Pero para mí la respuesta es diferente. El software es mucho más que un negocio, es una necesidad real. Jonathan Schwartz's (http://blogs.sun.com/jonathan/) decía hace algunos meses en su Weblog que el software era una industria que estaba jugando un papel similar al que juega el petróleo hoy día: la civilización se está construyendo sobre él. Y esto es cierto, el mundo como lo entendemos hoy no sería posible sin el software, desde hipótesis matemáticas que solo se pudieron demostrar con la aparición del computador, hasta la invención de Internet que ha cambiado nuestra forma de interactuar, trabajar, leer, opinar y hasta jugar y entretenernos.

Estos hechos le dan al software la categoría de IMPRESCINDIBLE, es decir, por más problemas y pérdidas que nos implique su desarrollo tenemos que "lidiar" con él. Para mí esta es la razón por la cual después más proyectos fallidos que exitosos, la industria del software sigue avanzando y las empresas siguen invirtiendo en ella. Seguramente al principio la Ingeniería Civil, mucho antes de llamarse "Ingeniería Civil", tuvo que soportar grandes edificaciones derrumbadas, pequeños sismos que acabaron con ciudades a causa de las malas construcciones y muchos proyectos que tomaban 2 ó 3 veces el tiempo estimado; eso solo se pudo soportar por que es una ciencia imprescindible, por que los seres humanos necesitamos casas para vivir y carreteras para comunicarnos, no importan lo malas que estas sean.

Claro, como esta es una nueva disciplina, nos hemos enfrentado a muchos inconvenientes para llevar a cabo proyectos exitosos. Durante los 90, el modelo de desarrollo de software en cascada fue el paradigma a seguir; había un número de etapas que se ejecutaban una a continuación de la otra, la aplicación se definía en su totalidad y luego se implementaba, igualmente, en su totalidad. Este modelo aunque parece ser que funcionó bien al principio, hizo que nos restregáramos en la cara el dinamismo y la incertidumbre de los negocios que teníamos que implementar, fue descubrir que era poco menos que imposible definir completamente un negocio antes de implementarlo. Esto ocurre bien sea por que los encargados del negocio no lo tienen claro, por que el mercado cambie las reglas del juego, por que esté regido por normas del estado que pueden cambiar en cualquier momento o simplemente por que los clientes no saben exactamente lo que quieren.

Pero los únicos inconvenientes del desarrollo no son por la incertidumbre en el negocio, la tecnología también trae muchos problemas implícitos: enfrentarnos a nuevos lenguajes de programación, frameworks o bases de datos con los que no tenemos experiencia o peor aún, no han sido probados en el dominio del negocio; también siempre hay problemas de integración entre módulos o integración con sistemas heredados (legacy); el rendimiento de las aplicaciones, la infraestructura de la red, la diversidad de sistemas operativos, etc. son factores que silenciosamente pueden llevar al fracaso. La innovación tiene un precio, y es muy alto.

Para mí esta situación es poco menos que aterradora: nunca tenemos claro lo que vamos a implementar y tampoco estamos seguros si va a funcionar.

Ante esta situación angustiante, salieron al rescate las metodologías iterativas. Donde se siguen pasos similares a los del modelo en cascada, pero se hacen una y otra vez sobre los diferentes módulos de la aplicación. Estas iteraciones mitigan inteligentemente el riesgo de lo desconocido, seleccionando en una etapa temprana del proyecto un caso de negocio a implementar y con el cual se hace una prueba de todo el proceso a seguir, la tecnología a implementar y se entrega rápidamente al usuario una "muestra" de lo que va a ser el sistema, aterrizando de esta forma las expectativas y trabajando sobre la base de un producto real. Si la primera iteración complace al cliente y al equipo de desarrollo, se continúa con otra iteración seguramente más grande, pero con la confianza de ambos bandos: hay una idea general y clara de lo que se está haciendo.

Además hay otro factor clave para el éxito de esta metodología: el cambio es algo natural dentro del proceso. Esto quiere decir que un cambio en los requerimientos no va a tener el impacto que tiene cuando se usa una metodología en cascada y es que para eso están diseñadas las iteraciones, para construir nuevos módulos y para refinar los que ya están construidos, por que otro mito que se derrumbó es el de tener módulo perfectos en un solo tirón.

Después de haber estudiado sobre el modelo iterativo, sobre todo RUP, me queda claro que una aplicación nunca está completamente terminada, con el desarrollo de software ocurre lo que le ocurre a cualquier artista con su obra: nunca la termina, siempre habrá algo que no nos gusta y que puede ser mejorado. Esto hace parte de la naturaleza humana.

Hay una gran pregunta que me queda dando vueltas:

¿Qué tan seguro es definir e implementar una arquitectura y tomar decisiones basados en una pequeña parte del problema?
¿Aplica acá la ley de Pareto? ¿El 20% de la funcionalidad me mostrará el 80% de lo que va a ser el proyecto?

Pero a pesar de todas las dudas, estoy encantado con los modelos iterativos. El mundo del software nos ofrece demasiados enigmas que pueden ser descubiertos en su mayoría con una pequeña implementación temprana y hay que olvidarnos de las implementaciones perfectas para empezar a pensar en productos imperfectos que siempre deben ser mejorados.

Posted at 09:34PM sep 15, 2007 by Carlos Alexander Zuluaga in General  |  Comentarios[2]