Rápido, más rápido, el más rápido

Los métodos de desarrollo rápido de aplicaciones pueden acelerar la entrega de sistemas en hasta un 1.300%. Sin embargo, la mayor parte de las compañías obtienen una mejora de 0%, ya que se limitan a hablar de cambiar las herramientas, y no las técnicas.

Muchos de los grupos responsables de sistemas de información darían cualquier cosa por acelerar el desarrollo de aplicaciones aunque sólo fuera un poco. Después de todo, hacer que las aplicaciones lleguen más rápidamente a los usuarios significa clientes y codificadores más satisfechos.

El incremento de la productividad en el desarrollo de aplicaciones está ligado al acortamiento de los ciclos de producción de programas. La receta se conoce como Desarrollo Rápido de Aplicaciones, RAD (Rapid Application Development).

Como su nombre implica, RAD ayuda a entregar sistemas más rápidamente, mediante una combinación de rápidas iteraciones de diseño, modelización de datos, trabajo en equipo usuario/desarrollador, y herramientas de desarrollo automatizado. En realidad, algunos proponentes de este enfoque afirman que el aumento de 25% en la velocidad de las entregas es una cifra conservadora, siendo posibles aumentos de 500% y 1.300% para algunas firmas.

Desafortunadamente, hay que desechar aquí algunos optimismos exagerados. La mayor parte de las compañías que utilizan RAD alcanzarán un aumento escaso o nulo en sus tiempos de entrega, ya que tienen una idea fundamentalmente equivocada de lo que es RAD. En el caso de RAD, no se trata de herramientas automatizadas muy vistosas y atractivas, sino de replatearse de forma significativa las metodologías de desarrollo y las técnicas de gestión. La idea consiste en acelerar el aprendizaje de manera que los desarrolladores puedan utilizar nuevas técnicas en beneficio de la empresa.

El éxito de RAD depende de que las compañías adopten ideas como las siguientes:

- Entrega incremental de componentes de sistemas. El sistema nunca es entregado en su totalidad. El primer componente queda terminado en un plazo de tres a cuatro meses y el resto a intervalos de tres a seis meses. Ninguna entrega requiere más de seis meses.

- Trabajo en equipo. Los desarrolladores trabajan en equipos, y los equipos colaboran estrechamente con los usuarios comerciales, mostrando a los usuarios iteraciones oportunas antes de finalizar el diseño.

- Objetivos alcanzables. Son los empleados, no la Dirección, los que establecen los productos a entregar, que están determinados por los objetivos.

- Menos pérdidas. Con vistas a la innovación, los desarrolladores trabajan para eliminar pasos innecesarios en la metodología de desarrollo de sistemas. Por ejemplo, la compañía productora de energía mencionada anteriormente desarrolló en su primera entrega una plantilla o template para generación de pantallas online, y la reutilizó para replicar pantallas adicionales en releases posteriores.

El Bing Bang

En contra de la creencia popular, utilizar herramientas novedosas y atractivas en el desarrollo puede en realidad retrasar el plazo de entrega. Este es el motivo de que no dé resultado simplemente introducir nuevas herramientas en un método riguroso y lineal de definición de requerimientos, diseñando sistemas y creándolos, y esperar que hagan milagros. El enfoque big bang de los años 70 a la implementación de sistemas, en el que toda la funcionalidad se entrega de una sola vez, no está dando resultado.

Por ejemplo, una compañía que tenía previsto entregar su software de control de procesos en tiempo real de una sola vez, tuvo que poner fin al proyecto después de fallar repetidamente en sus plazos de entrega.

En el punto en que la compañía suspendió el trabajo, el sistema tenía un retraso de 18 meses.

Utilizar RAD en un escenario IS es un desafío formidable, ya que nuestra disciplina espera precisión, rigor y herramientas para ser la solución, afirma Bob King, un patrocinador de RAD en la firma The Travelers Corporation de Hartford, Conn. RAD se está utilizando en Travelers desde 1990.

La compañía de energía de Houston, por su parte, rompió con un esquema de requeriimientos cambiantes y planes de entrega ampliados, al alterar los rígidos métodos de gestión de proyectos de los 70. En su lugar, adoptó RAD y su técnica de gestión para entrega incremental de sistemas, en forma de releases.

El equipo IS de la compañía petrolífera estableció objetivos de innovación récord iniciales, según los cuales los desarrolladores terminaron primero ciertas aplicaciones básicas o núcleo, como el subsistema de tarifas para contabilidad de gas natural. Los desarrollado- res pudieron entonces centrar el énfasis en crear más rápidamente las partes restantes de ese sistema - partes que contenían importante funcionalidad, tales como interfaces con el mayor general o con el sistema de cuentas por pagar.

Este proyecto, para el que estaba prevista una duración de un año desde el comienzo de la creación, requirió siete meses - cuatro meses para los primeros sistemas núcleo, terminando las piezas restantes tres meses después.

Lo más notable sobre este caso es que los desarrolladores no utilizaron las herramientas más avanzadas. Lo más novedoso que obtuvo el departamento IS fue un generador de aplicaciones que facilitó la producción de codificación. Por lo demás, los desarrolladores trabajaron con tecnologías convencionales, como Cobol. El trabajo se centró en comprender los requerimientos de la empresa, aplicar tecnología de bases de datos y aprender a trabajar eficientemente en equipos.

Los desarrolladores del Departamento de Impuestos del estado de Virginia optaron también por mantener simples las cosas. Crearon el extenso sistema de contabilidad de impuestos de la empresa - una síntesis de 1.500 programas y 40 bases de datos - acoplando tecnología convencio- nal de lenguajes de tercera generación y bases de datos con técnicas de gestión RAD. Actualmente, los usuarios no tienen que esperar más de un año para cualquier nueva funcionalidad.

Según el personal IS, el proyecto prosperó porque se concentraron en establecer objetivos agresivos pero alcanzables y asegurar nuevas funciones cada tres a seis meses.

Bajo presión

El sector IS continúa bajo presión para entregar sistemas más rápidamen- te, e incluso los proponentes de la actividad por fases podrían recurrir en su desesperación a RAD para satisfacer necesidades comerciales críticas. RAD ha surgido en pequeñas islas en muchas organizaciones, aunque estas compañías no lo han adoptado aún de manera abierta. Es en estos grupos aparte donde RAD obtiene sus mejores relaciones públicas; si funciona allí, es más probable que encuentre un lugar en la organiza- ción a largo plazo.

En la firma Travelers, por ejemplo, el departamento IS de una de sus divisiones se encontró bajo fuerte presión de tiempo para entregar aplicaciones comerciales. Como la entrega requería en promedio 18 meses utilizando métodos de desarrollo tradicionales, el grupo recurrió a RAD en la esperanza de aprovechar las herramientas de desarrollo automatiza- do. Con el tiempo, las herramientas se convirtieron en algo incidental, al pasar el grupo a depender en gran medida del trabajo en equipo, de asociados comerciales participantes y de la toma de decisiones basada en equipos y con asunción de riesgos en IS.

Actualmente, este grupo está utilizando RAD como ayuda para mejorar las aplicaciones, y está entregando porciones en un plazo de tres a seis meses. Aunque la compañía no está utilizando aún estos métodos para sus actividades principales de desarrollo, según King, la aceptación de RAD está aumentando de manera continua.

Hay que enfrentarse a la realidad: los viejos hábitos desaparecen con dificultad. Sin embargo, RAD puede contribuir a aumentar de manera significativa la productividad en el