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.

Desarrollo eficiente de software

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Desarrollo eficiente de software (20)

Más de Alejandro Domínguez Torres (20)

Último (20)

Desarrollo eficiente de software