Desarrollo eficiente de software

1

DESARROLLO EFICIENTE DE SOFTWARE

DESARROLLO EFICIENTEDE SOFTWARE

Alejandro Domínguez Torres Fundación Arturo Rosenblueth

Instituto Tecnológico Rosenblueth Junio de 1998

Conceptualización del Desarrollo Rápido

Existen diferentes enfoques del concepto de Desarrollo Rápido. Algunas de ellas

son:

Para la gente común: Aplicación o utilización de una única herramienta o

método

Para el hacker: Codificar el número de horas que el cuerpo resista y la

salud lo permita

Para el ingeniero en sistemas: Combinación de herramientas de

software, participación del usuario y horarios estrictos

Para el vendedor: Creación de prototipos con el lenguaje de moda o el

mas popular que permitan mostrar productos a los clientes

Para los desesperados: Leer los libros cuyos subtítulos lleven las frases

“en 7 días”, “en 21 días”, “for dummies”, “for idiots”, etc.

En los textos también este concepto se ha definido:

Para Roger Pressman [1, p. 25]: El Desarrollo Rápido de Aplicaciones

(DRA) (Rapid Application Development) es un modelo de proceso de

desarrollo del software lineal secuencial que enfatiza un ciclo de

desarrollo extremadamente corto. El modelo DRA es una adaptación a

<<alta velocidad>> del modelo lineal secuencial en el que logra el

desarrollo rápido utilizando un enfoque de construcción basado en

componentes. Si se comprenden bien los requisitos y se limita el ámbito

2


del proyecto, el proceso DRA permite al equipo de desarrollo crear un

<<sistema completamente funcional>> dentro de periodos cortos de

tiempo (p. ej. De 60 a 90 días). Cuando se utiliza principalmente para

aplicaciones de sistemas de información, el enfoque DRA comprende

las siguientes fases: Modelado de Gestión, Modelado de Datos,

Modelado de Proceso, Generación de Aplicaciones, Pruebas y

Entrega.

Para David Ruble [2, p. 12]: El [Desarrollo Rápido de Aplicaciones] RAD

combina el enfoque espiral con una estrategia de división de un proyecto

grande en fases de desarrollo o “cuadros de tiempo”.

Para Steve McConnell [3, p. 4]: <<desarrollo rápido>> es simplemente

una frase descriptiva opuesta a <<desarrollo lento y típico>>. No es

Desarrollo Rápido, una frase o palabras mágicas. El desarrollo rápido

es un término genérico que significa lo mismo que <<desarrollo veloz>>

o <<planificaciones más cortas>>. Significa desarrollar software a una

velocidad superior a la alcanzada en este momento. Entonces, un

<<proyecto de desarrollo rápido>> es cualquier proyecto que necesite

hacer énfasis en la velocidad de desarrollo. En circunstancias actuales,

esta descripción se adapta a una gran cantidad de proyectos.

Estrategias del Desarrollo Rápido

En lo que sigue se describirán las estrategias del desarrollo rápido desarrolladas

por Pressman, Ruble y McConnell.

Estrategia de Desarrollo Rápido de Pressman [1, pp. 25-26]

Modelado de Gestión. El flujo de la información entre las funciones de gestión se

modela de forma que responda a las siguientes preguntas:

¿Qué información conduce al proceso de gestión?

¿Qué información se genera?

3


¿Adónde va la información?

¿Quién la procesa?

Modelado de Datos. El flujo de información definido como parte de la fase de

modelado de gestión se refina como un conjunto de objetos de datos necesarios

para apoyar la empresa. Se definen las características (Ilamadas atributos) de

cada uno de los objetos y las relaciones entre estos objetos

Modelado del Proceso. Los objetos de datos definidos en la fase de modelado de

datos quedan transformados para lograr el flujo de información necesario para

implementar una función de gestión. Las descripciones del proceso se crean para

añadir, modificar, suprimir, o recuperar un objeto de datos.

Generación de Aplicaciones. El DRA asume la utilización de técnicas de cuarta

generación. En lugar de crear software con lenguajes de programación de tercera

generación, el proceso DRA trabaja para volver a utilizar componentes de

programas ya existentes (cuando es posible) o a crear componentes reutilizables

(cuando sea necesario). En todos los casos se utilizan herramientas automáticas

para facilitar la construcción del software.

Pruebas y Entrega. Como el proceso DRA enfatiza la reutilización, ya se han

comprobado muchos de los componentes de los programas. Esto reduce tiempo

de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se

deben ejercitar todas las interfaces a fondo.

El modelo de proceso DRA se ilustra en la figura siguiente. Obviamente, las

limitaciones de tiempo impuestas en un proyecto DRA demandan <<ámbito en

escalas>>. Si una aplicación de gestión puede modularse de forma que permita

completarse cada una de las funciones principales en menos de tres meses

(utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una

de las funciones pueden ser afrontadas por un equipo DRA diferente y ser

integradas en un solo conjunto.

4


Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

Para proyectos grandes aunque por escalas, el DRA requiere recursos

humanos suficientes como para crear el número correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en las rápidas

actividades necesarias para completar un sistema en un marco de tiempo

abreviado. Si no hay compromiso, por ninguna de las partes constituyentes,

los proyectos DRA fracasarán.

No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se

puede modularizar adecuadamente, la construcción de los componentes

necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se

va a conseguir el rendimiento convirtiendo interfaces en componentes de

5


sistemas, el enfoque DRA puede que no funcione. DRA no es adecuado cuando

los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso

de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de

interoperabilidad con programas de computadoras existentes.

DRA enfatiza el desarrollo de componentes de programas reutilizables. La

reutilización es la piedra angular de las tecnologías de objetos.

Estrategia de Desarrollo Rápido de Ruble [2, pp. 12-14]

Como ya se mencionó esta estrategia se basa en fases o <<cuadros de tiempo>>.

Un cuadro de tiempo es una conjunto de características definido que promete

entregar a los usuarios dentro de un marco de tiempo fijo, digamos 90 días. Dentro

del cuadro de tiempo se realiza algo de análisis, un diseño breve y luego, usando

herramientas de desarrollo de alto poder, se construye un prototipo funcional. El

prototipo es revisado por los usuarios y se solicitan modificaciones. El ciclo de

codificación y de refinación se repite tres veces, yendo en espiral volviendo a

analizar, diseñar, y evaluar. Al final del cuadro de tiempo se instala la aplicación

resultante.

6


En la práctica, el RAD sufre de malas aplicaciones igual que la cascada. Muchos

gerentes y programadores ven el modelo espiral como tres iteraciones de ajuste

de “codificación”. La ventaja principal de RAD es la codificación temprana, y en

muchos establecimientos [?] la producción de código es vista como la única

medida tangible de que se ha realizado una actividad significativa. Esto lleva a la

mentalidad de “tres strikes y out”, en donde cualquier cosa que parezca análisis y

diseño es rápidamente abandonada, dando como resultado sistemas débiles que

se desempeñan de forma dudosa en la fase de mantenimiento del ciclo de vida.

Los puntos fuertes del RAD son que los usuarios se involucren intensamente, la

creación temprana de prototipos y la implementación en fases. Sus puntos débiles

incluyen una tendencia a la codificación temprana, lo que hace que pasen muchas

tareas de análisis y diseño a manos del programador y, por lo tanto, depende de

los técnicos con conocimientos generales. Se apoya en programadores que son

maestros en sus respectivas herramientas de desarrollo y ambientes de

programación y al mismo tiempo son adeptos al diseño de interfaces y al análisis

de negocios, además son comunicadores talentosos. El enfoque abrumador sobre

el cuadro de tiempo hace difícil la construcción de componentes reutilizables a

largo plazo, y cuando se acerca la fecha de entrega lo primero que se entrega es

la documentación. En vez de administrar contra una especificación tangible, el

administrador se encuentra armado con un látigo y un cronómetro. La medida de

avance principal se convierte en la cantidad de revisiones que se han hecho del

código.

Estrategia de Desarrollo Rápido de McConnell [3, pp. 9-34]

Se puede obtener un desarrollo rápido siguiendo una estrategia de cuatro partes:

1. Evitar los errores clásicos

2. Aplicar las bases de desarrollo

3. Gestionar los riesgos para evitar un retorno catastrófico

7


4. Aplicar métodos orientados a planificación: Métodos orientados a la

velocidad, métodos orientados a los riegos de planificación, y métodos

orientados a la visibilidad.

Las siguientes figuras ilustran el efecto de cada una de estos pilares de desarrollo

rápido:

8


Referencias

1. Pressman, R.S. Ingeniería del software: un enfoque práctico. Cuarta edición,

McGraw-Hill Interamericana de España. España, 1998.

2. Ruble, D.A. Análisis y diseño práctico de sistemas cliente servidor con GUI.

Prentice-Hall Hispanoamericana. México, 1998.

3. McConnell, S. Desarrollo y gestión de proyectos informáticos. McGraw-Hill

Interamericana de España, Microsoft Press. España, 1997.

Technology

Desarrollo eficiente de software