Modelos para El Desarrollo de Software

Modelos para el desarrollo de software
Una visión integrada y orientada a proyectos vinculados con la Administración y

las Ciencias Económicas
Autor: Lic. César Ariel Briano
Facultad de Ciencias Económicas

Universidad de Buenos Aires
2009
Contenido
1. Objetivo ........................................................................................................................................... 2
2. Introducción .................................................................................................................................... 2
3. Desarrollo de Sistemas. Enfoque clásico ......................................................................................... 2
4. Una propuesta integral.................................................................................................................... 3
5. Distintos problemas y sistemas, distintos modelos ........................................................................ 4
6. Modelo “Lineal Secuencial” (“En Cascada” o “Ciclo de Vida”) ........................................................ 7
7. Modelo “Lineal Secuencial Iterativo o Incremental” ...................................................................... 8
8. Modelo de “Prototipos” .................................................................................................................. 9
9. Modelo en “Espiral” ...................................................................................................................... 10
10. Modelo de “Desarrollo Rápido de Aplicaciones” ...................................................................... 12
11. Otros modelos ........................................................................................................................... 13
12. Elección de un modelo adecuado ............................................................................................. 14
13. Limitaciones............................................................................................................................... 15
Agradecimiento ..................................................................................................................................... 15
Bibliografía y sitios consultados ............................................................................................................ 15

Lic. Cesar Ariel Briano 1
1. Objetivo
Los modelos a utilizar para desarrollar aplicaciones informáticas son parte fundamental de
cualquier bibliografía dedicada a la ingeniería de software.
El objetivo de este trabajo es presentar esos modelos de un modo más claro y ordenado,
haciendo hincapié en aquellos modelos que más se utilizan. Se busca además adaptar los modelos a
un enfoque más realista, más local y más orientado al desarrollo de sistemas vinculados a la
administración y a las ciencias económicas.
2. Introducción
Muchas profesiones tienen protocolos o guías para encarar su arte, su ciencia o su técnica.
Un pintor sabe que antes de empezar su cuadro debe preparar la tela conforme la técnica de pintura
que luego utilizará. Un médico que visita a un paciente a domicilio sabe que primero debe tomarle la
fiebre, auscultarlo, revisar su garganta y luego decidir un diagnostico. Podrá optar por realizar más
estudios de laboratorio o prescribir algún medicamento.
Algo similar pasa con la construcción del software: no es simplemente sentarse y empezar a
programar. Por el contrario, un proyecto de construcción de un sistema informático requiere
desarrollar una serie de tareas. Algunas de estas tareas son previas y otras son posteriores a la
programación propiamente dicha y deben ejecutarse con cierto orden y cumpliendo ciertas pautas
para asegurar un proyecto exitoso y un software de calidad.
Los modelos para el desarrollo de software dan al ingeniero un marco teórico a seguir para
desempeñar eficazmente su tarea. La existencia de múltiples tipos de sistemas, de múltiples tipos de
organizaciones y de contextos muy diferentes, hace que sea necesario contar con varios modelos. Las
diferentes características de cada modelo lo hacen más o menos apto ante determinados supuestos.
3. Desarrollo de Sistemas. Enfoque clásico
La teoría de construcción de sistemas planteó desde sus comienzos la necesidad de

desarrollar una serie de actividades sucesivas para lograr el éxito del proyecto. Los ingenieros de
software destacan la existencia de un modelo lineal, clásico o secuencial, en el cual se encadena una,
tras otra, las siguientes etapas:
Análisis Diseño Codificación Prueba Puesta en marcha
Este modelo presenta algunas variantes en cuanto su concepción. Algunos autores incluyen
otras etapas, como la de relevamiento o la de mantenimiento (más adelante se hablará de esto) o las
nombran de modo diferente (por ejemplo “implementación” o “implantación” en lugar de “puesta
en marcha”). Sin embargo, la esencia es similar en todos: Un modelo de etapas secuenciales las

cuales deben ser desarrolladas una tras otra hasta arribar al producto final ya instalado. Solo cuando
se finaliza una etapa puede pasarse a la etapa siguiente.
Queda fuera de alcance de este trabajo el análisis exhaustivo de cada una de estas etapas.
Sin embargo, es necesaria una breve descripción de cada una de ellas.
Etapa Descripción
Análisis Los analistas relevan una determinada organización para detectar sus
necesidades y los problemas a ser resueltos por un sistema informático.
Diseño En esta etapa se diseña una solución informática a los problemas encontrados,
contemplando las necesidades de los usuarios. Generan la documentación con el
detalle técnico necesario para que los programadores puedan construir el
código.
Codificación Basado en las especificaciones del diseño, los programadores construyen el

código del programa, utilizando algún lenguaje de programación.
Prueba Consiste en buscar posibles errores en un sistema, reportándolos para su

solución.
Puesta en En esta etapa se instala el programa en las computadoras del cliente y se

marcha capacita a los usuarios para que puedan utilizar el nuevo software.
4. Una propuesta integral
Antes de avanzar con el análisis de los diferentes modelos que pueden ser utilizados para
construir software, es necesario aclarar que este modelo clásico tampoco abarca todas las etapas
existentes en un proyecto de construcción de una aplicación informática. Por ejemplo, no es cierto
que un desarrollo de software empiece directamente con la etapa de análisis. Tampoco es cierto que
solo estas cinco etapas basten para construir software de calidad. El modelo tradicional podría
mejorarse, agregando algunas etapas y reformulando otras.
Etapa Descripción
Comunicación Es el primer contacto entre desarrollador y cliente. Se acuerdan los lineamientos

inicial básicos del proyecto y se presentan en forma global los problemas, las
necesidades y las restricciones existentes.
Estudio de No todos los problemas pueden resolverse mediante un sistema informático o

Factibilidad con un desarrollo tradicional del software. Pueden aparecer también enfoques o
propuestas alternativas. Además, las condiciones particulares del entorno, del
cliente, del desarrollador y hasta el presupuesto o los tiempos disponibles
también pueden condicionar la realización de un sistema. Es necesario entonces
estudiar la factibilidad o no de seguir adelante con el proyecto.
Plan y Es necesario planificar el proyecto de desarrollo en su totalidad. Habrá que

Presupuesto estimar recursos: Humanos (incluyendo la contratación y/o asignación temporal
de personal), de software (licencias, entornos de desarrollo, librerías de

software, componentes reutilizables, etc.) y de entorno (hardware,
comunicaciones, espacio físico de trabajo, etc.).
También, y en función del tipo de software a desarrollar, deberá definirse cuál

será el modelo de desarrollo de software que se utilizará, los tiempos que se
estima llevará cada una de las etapas y la forma en la que se de desarrollarán
cada una de las actividades del proyecto.
Por último, en esta etapa también será necesario elaborar un presupuesto

económico para presentarle al cliente. No siempre será posible presupuestar de
antemano la totalidad del sistema, en cuyo caso podrá hacerse un presupuesto
parcial que alcance solo las próximas etapas.
Construcción de Los modelos de desarrollo de software abarcan las etapas de análisis, diseño,
la aplicación codificación, prueba y puesta en marcha. Cada una de estas actividades tendrá
utilizando un particularidades y agregados según las características de cada modelo y de los
modelo sistemas a desarrollar.
Protección de la Para desarrollar de software de calidad es necesario desarrollar, en forma

Calidad paralela a las etapas constructivas, una serie de actividades tendientes a
proteger la calidad del software. Dichas actividades son auditorías; revisiones
técnicas; la gestión del riesgo y planes de contingencia; la aplicación de
mediciones y métricas; el control de cambios y versiones; la verificación y el
seguimiento del plan de software trazado; el cumplimiento de plazos y la
elaboración de documentación y registros.
Garantía Aunque no siempre esta etapa se da de manera explícita y a veces queda en un

mero anuncio de la propuesta comercial, queda claro que el compromiso de
quien desarrolla un software es que este funcione tal como fue especificado. Es
necesario entonces contemplar una etapa en donde se solucionen los errores
que pueda tener el software. El costo de esta etapa debe ser también
contemplado dentro de los costos generales del proyecto.
Mantenimiento Ni los sistemas ni las organizaciones en las que estos funcionan son estáticos.
Una vez instalado un sistema es posible que sean necesarios cambios o mejoras.
Puede incorporarse nuevos pedidos de los clientes; agregar nuevas
funcionalidades; mejorar las existentes; corregir errores; adaptarlo a nuevas
tecnologías o a cambios del entorno.
Por supuesto también existen casos donde esta etapa no se lleva a cabo.
5. Distintos problemas y sistemas, distintos modelos
Los sistemas son diferentes entre sí. Y aunque sean parecidos, las organizaciones para los
cuales estos sistemas se desarrollan tienen diferente cultura. Resulta difícil pensar que un único
modelo, como el modelo clásico o secuencial, pueda servir para todos los tipos de software que
pueden construirse.
Es más, las críticas a este enfoque tradicional son variadas: que los proyectos de software
rara vez son tan lineales, que hay poca interacción con el cliente, que los errores u omisiones de una

etapa se arrastran con facilidad a etapas posteriores, que los requerimientos deben obtenerse al
comienzo sin posibilidad de cambio, que es difícil aplicarlo en proyectos grandes o complejos...
La construcción de software implica encarar un proyecto que tiene diversas complicaciones.

Existen varios factores que pueden afectarlo y desviarlo de sus estimaciones iniciales, entre los que
podemos mencionar a:
• El tamaño del software a desarrollar:
Aun cuando la funcionalidad o la complejidad técnica de un software sean parecidas, no

es lo mismo construir un software chico que uno grande. Tampoco es lo mismo hacerlo
para una pequeña empresa que para una de mayor tamaño.
Un software más grande presupone más líneas de código, más usuarios, más problemas
para relevar, una mayor cantidad de recursos asignados, un mayor despliegue en la
implementación, una mayor capacitación, más horas de prueba, más documentación,
etc.
En resumen: Es más difícil desarrollar un software de gran tamaño que uno pequeño. Es
más difícil mantener controlado un proyecto grande que otro más chico.
• La complejidad para obtener requerimientos:
Los sistemas buscan resolver problemas organizacionales. Y para esto es necesario

relevar diferentes usuarios e involucrados. Sin embargo, estos requerimientos no
siempre son fáciles de obtener.
Muchas veces la comunicación entre los especialistas en informática y los usuarios

clientes no es tarea sencilla. Los usuarios pueden no tener en claro sus necesidades o
pueden no saber expresarlas correctamente.
Tampoco puede asegurarse que lo que el analista entendió es exactamente lo que el

usuario le quiso explicar. No es fácil explicar verbalmente por ejemplo el
comportamiento deseado una pantalla con múltiples botones.
También pueden ocultarse cosas, a veces por una simple omisión, otras veces
deliberadamente. No debe olvidarse que el usuario puede asumir diversas actitudes
frente a la instalación de un nuevo software. A veces puede incluso no querer
implementarlo por temores a ser desplazado para conservar cierto poder dentro de la
organización.
Incluso debe considerarse que los usuarios no siempre tienen el tiempo suficiente para
dedicarle a los analistas que realizan el relevamiento. También existe la posibilidad de
que estos requerimientos no puedan ser explicitados al inicio o que cambien conforme
va avanzando el proyecto.
Es importante entonces asegurar que los requerimientos sean bien comprendidos y que
coincidan con las necesidades reales de la organización.
• La complejidad técnica:
Realizar un software también implica desafíos técnicos. Muchas veces deben

desarrollarse software para nuevos sistemas operativos, con nuevos lenguajes de

programación, para nuevos entornos o vinculados con dispositivos de hardware especial
(equipos portables, celulares, máquinas industriales, etc.)
Incluso hay casos en los cuales el cliente fija determinados requerimientos tecnológicos
que pueden resultar desafíos adicionales para el desarrollador que puede no tener la
suficiente experiencia en esa tecnología.
Las cuestiones técnicas representan entonces un factor de complejidad adicional que

debe ser tenido en cuenta.
• El tiempo disponible:
Se supone que una de las cosas que se estiman y presupuestan al realizar un software es
cuánto tiempo se tardará en el desarrollo.
Sin embargo, muchas veces las organizaciones requieren tener disponible el software
para una fecha específica (por ejemplo para el lanzamiento de un nuevo producto, el
cambio de período fiscal, la necesidad adelantarse a la competencia, la apertura de un
nuevo local, etc.) En estos casos los plazos de desarrollos son parte del requerimiento e
imponen restricciones al proyecto.
• El riesgo:
Todo nuevo proyecto es un desafío e implica riesgos. De hecho, las situaciones descriptas
anteriormente implican diferentes grados de riesgos que pueden alterar los planes y los
resultados previstos.
Pero existen también otras situaciones propias del proyecto que implican riesgos
concretos. Se debe prestar especial atención a estas situaciones ya que pueden
determinar la necesidad de redefinir o incluso de abandonar el proyecto.
La lista de posibles riesgos es larga, pero como ejemplo puede mencionarse: pérdida de
apoyo político, cambios de personal, cambios en el presupuesto, cambios en la
legislación, cambios en el mercado, lanzamiento de nuevo hardware, aparición de nuevo
software o de un nuevo sistema operativo, cambios en sistemas de la competencia,
ventas o fusiones de la empresa…
En resumen: Existen entonces diversos problemas a tener en cuenta a la hora de desarrollar

software. Las características propias de cada uno de los modelos permiten actuar con mayor o menor
eficacia ante los problemas mencionados. En función de las características de los sistemas a
desarrollar y de los problemas que se deseen resolver puede entonces ser conveniente elegir un
determinado modelo en lugar de otro.
Resulta apropiado aclarar que, así como se destacaron las posibles limitaciones de tiempo,
seguramente al leer esta lista pueda pensarse en el costo como un factor limitante. O mejor dicho en
el presupuesto que el cliente tiene disponible. Por supuesto que es necesario desarrollar software
que el cliente pueda pagar, pero esto no debe tomarse como un condicionante a la hora de elegir un
modelo u otro. En efecto y como se verá a continuación, hay modelos que insumen más recursos que
otros y por ende son más costosos. Pero hay que tener en cuenta que hay otros factores para
determinar el costo total de un sistema. Quizá un modelo a priori más caro termine generando
ahorros. Por ejemplo, un modelo que permita comprender mejor los requerimientos evita las
reprogramaciones. Aun con presupuestos limitados debe elegirse el modelo más adecuado y no
necesariamente el mas barato.

6. Modelo “Lineal Secuencial” (“En Cascada” o “Ciclo de Vida”)
Ya se ha comentado alguna de las desventajas y críticas que recibe el modelo lineal

secuencial. Sin embargo para sistemas sencillos y pequeños la elección de un modelo simple no deja
de ser una muy buena idea. Este sistema contempla 5 etapas, de características muy similares a las
del modelo clásico.
Etapa Descripción
Ingeniería de Esta etapa coincide con la etapa de análisis, aunque no solo debe relevarse
requerimientos usuarios y analizar la información proporcionada. El término ingeniería de
requerimientos hace referencia a una actitud activa en la búsqueda de todos los
problemas y en tratar de obtener los requerimientos de la manera más completa
y exacta posible, aun aquellos que los usuarios ocultan o desconocen. Además de
relevar usuarios debe también analizarse la documentación, la normativa vigente
y los procesos internos de la organización.
Diseño Es la primera de las actividades técnicas. En esta etapa se diseña una solución a
los problemas encontrados, contemplando las necesidades de los usuarios.
Produce un modelo de lo que se construirá más adelante. Proporciona detalles
acerca de las estructuras de datos, las arquitecturas, las interfaces y los
componentes del software que son necesarios para programar el sistema.
Codificación Basado en las especificaciones del diseño los programadores generan el código
utilizando un lenguaje de programación. Construyen el software propiamente
dicho.
Prueba Frecuentemente se señala a esta etapa como aquella en la cual se prueba que el
software no contenga errores. Sin embargo, no debe probarse que el software
funcione sino que se debe buscar que este falle. Se debe entonces atacar y
someter al programa a diversas condiciones extremas, buscando que aparezcan
errores no detectados en la etapa de la codificación.
Despliegue En esta etapa, denominada también como, “implementación”, “puesta en

marcha”,” o “implantación” por algunos autores, el software ya probado es
instalado en el entorno productivo del cliente. Deben contemplarse todas las
tareas adicionales necesarias para que el sistema esté operativo, incluyendo la
instalación de servidores y redes, la configuración de hardware y software de los
equipos de trabajo, la entrega de documentación y manuales y la provisión de
todo aquel material necesario para la operación del sistema
Una parte importante de esta etapa es la capacitación de todos los usuarios

involucrados y la adecuación de los circuitos administrativos a la nueva
operatoria basada en un sistema informático.

Ventajas Desventajas
• Es un modelo simple, sencillo y probado y por • Los proyectos rara vez siguen el flujo
supuesto es mucho mejor utilizar este modelo secuencial.
que no utilizar ninguno. • Los errores de las primeras etapas se arrastran
• Para proyectos sencillos es el modelo menos con facilidad a las etapas posteriores. Muchos
costoso y el más rápido. errores sólo se descubren al final cuando se
entrega el sistema.
• Pueden producirse estados de bloqueos por la
secuencialidad de las etapas.
• Es difícil que el cliente especifique todos los
requerimientos al inicio
• No prevé la posibilidad de introducir cambios
en el medio del proyecto.
• El cliente no ve el proyecto hasta que el
software está terminado.
7. Modelo “Lineal Secuencial Iterativo o Incremental”
Puede ocurrir que, por razones de tamaño, tiempo u operativas, sea conveniente construir y
entregar el sistema en partes. De este modo puede construirse una primera versión con algunas
funcionalidades. Una vez implementada esta versión, se vuelve a emplear el modelo lineal secuencial
para producir una nueva versión más completa.
Las etapas de este modelo obviamente no difieren del modelo Lineal Secuencial ya que, en
definitiva, son sucesivas iteraciones del mismo.
Es importante diferenciar este modelo de la división modular de un sistema. En cada

iteración se entrega un sistema completo y operativo y no módulos sueltos. El cliente puede usar el
sistema en entornos productivos aún cuando a este no tenga completas todas sus funcionalidades.
Como ejemplo puede mencionarse un sistema para un comercio minorista. Una primera
versión podría contener solamente funciones para emitir las facturas y controlar la caja. Una segunda
vuelta podría permitir registrar clientes y manejar la cuenta corriente de los mismos. Un tercer
incremento habilitaría la posibilidad de registrar las compras y los proveedores y finalmente una
última versión podría permitir un control de stock automatizado.
• Las entregas parciales reducen la complejidad • Sigue siendo un esquema secuencial, aunque
del proyecto y mejoran las estimaciones. esto sea menos grave que en el modelo
• El usuario recibe rápidamente una primera anterior.
versión con sus primeras necesidades ya • Los errores de las primeras etapas se arrastran
cubiertas. con facilidad a las siguientes.
• Requiere menos personal concurrente y los • Pueden producirse estados de bloqueos por la
recursos se asignan mejor en el tiempo. secuencialidad de las etapas.
• Las implementaciones parciales son más
sencillas que una implementación total.

8. Modelo de “Prototipos”
Ya se mencionó la dificultad existente para obtener requerimientos y para asegurar que los
analistas entendieron lo mismo que los usuarios quisieron explicar.
Así como al construir una casa los arquitectos construyen maquetas y diseños simulados para
que el cliente pueda tener una mejor idea de cómo será la futura construcción, los ingenieros de
software pueden construir un prototipo de lo que será el producto final. Este prototipo es una
versión acotada del software, construida solamente a los fines de poder interactuar con el cliente y
poder tener una mejor visión de que es lo que se está planificando hacer. Seguramente no todas las
funciones, pantallas u opciones del software serán incluidas en el prototipo, que podrá ser parcial e
incluir sólo aquellas funciones más representativas.
El prototipo también puede ser utilizado por el desarrollador para probar algún algoritmo
determinado o alguna funcionalidad compleja del software. Por ejemplo, si se construye un software
para interactuar y controlar algún dispositivo móvil, podría desarrollarse un prototipo para
comprobar que en efecto puede accederse al dispositivo y que se pueden realizar las operaciones
necesarias para controlarlo.
Aunque es lo más habitual, un prototipo no necesariamente tiene que ser un software. Un

diseño de pantallas o imágenes gráficas del producto también podrían utilizarse.
El prototipo puede tener varias versiones, cambios y ajustes. Podría trabajarse sobre el
prototipo hasta que se finalmente acuerdan los requerimientos o se comprueban y verifican los
temas técnicos. Recién cuando se logra el acuerdo final sobre el prototipo se avanza en la
construcción del software.
Es importante destacar que una vez que el prototipo es aprobado y que los requerimientos
han quedado finalmente claros, este debe desecharse para iniciar la construcción del software real.
Para ello, podrá utilizarse cualquiera de los modelos de desarrollo, según las necesidades específicas
del proyecto.
Las etapas de construcción del prototipo son similares a las del modelo lineal secuencial,
aunque en este caso no se busca la construcción de un producto final del software sino solamente de
un prototipo.
Etapa Descripción
Relevamiento Esta etapa se realiza un relevamiento general y luego de relevan con más
Rápido detalle aquellas opciones que serán incluidas en el prototipo. Este relevamiento
no se hace de un modo tan exhaustivo ya que no tiene como objetivo
determinar las funciones de todo el sistema sino sólo del prototipo.
Diseño del Se diseña el prototipo, detallando el modo en el que se presentará y cuál será
prototipo el alcance de cada una de las opciones del mismo.
Generación del Se construye el prototipo. Puede utilizarse el mismo lenguaje de programación

prototipo que luego se utilizará para programar el sistema; usar alguna herramienta
específica de desarrollo de prototipos o incluso mostrar ejemplos gráficos sin
programación.

Prueba Si el prototipo es un software operable, el mismo deberá ser probado para
buscar posibles errores.
Despliegue y Se entrega el prototipo al cliente y se analiza en conjunto con el desarrollador A

retroalimentación partir de este análisis podría modificarse el prototipo, construirse uno nuevo o
bien comenzar con el desarrollo de la aplicación final.
Construcción de Una vez definidos los requerimientos o probada alguna funcionalidad específica
la aplicación se generará la aplicación final, utilizando alguno de los modelos de desarrollo
utilizando un de software.
modelo
• Permite una mejor definición y comprensión • El cliente puede tentarse de utilizar el
de los requerimientos iniciales. prototipo, construido como tal y sin calidad,
• Permite un testeo de aquellas funciones como una primera versión operativa.
técnicamente complejas. • El desarrollador puede tentarse de ajustar el
• Reduce la incertidumbre. prototipo y entregarlo como producto final.
• Algunas de las funcionalidades presentes en el
prototipo podrían no ser tenidas en cuenta en
la versión final o quizá no sean posibles de
construir en el entorno real de desarrollo.
9. Modelo en “Espiral”
Ya se ha destacado que en escenarios riesgosos no todos los proyectos que se inician

terminan en un software que se implementa en forma exitosa. El modelo en espiral se presenta
como una buena elección situaciones de riesgo e incertidumbre.
El nombre del modelo deriva de la representación gráfica utilizada para ilustrarlo. Un espiral
marca el sucesivo recorrido de las distintas etapas, produciendo una versión operativa del software
en cada una de sus vueltas.
Despliegue Ingeniería de requisitos
Prueba
Diseño
Codificación Análisis de Riesgo

Las primeras de estas iteraciones podrían corresponder a una primera versión o al desarrollo
de un prototipo. Luego aparecerán, de modo similar al modelo lineal secuencial iterativo, diferentes
versiones operativas y más completas del software hasta que se complete finalmente el software.
La característica distintiva y saliente del modelo consiste en que agrega a las etapas
habituales un análisis de riesgo. En cada una de estas iteraciones se evalúan los riesgos del proyecto,
A partir de dicho análisis el proyecto puede ser modificado o incluso abortado sí las condiciones así lo
imponen.
Etapa Descripción
Ingeniería de Se relevan los requerimientos y necesidades generales de la organización y luego

requerimientos se presta especial atención a las funcionalidades que serán entregadas en la
primera etapa. Se buscan determinar cuáles son los posibles riesgos del
proyecto.
Diseño Es la primera de las actividades técnicas. En esta etapa se diseña una solución a
los problemas encontrados, contemplando las necesidades de los usuarios.
Produce un modelo de lo que se construirá más adelante. Proporciona detalles
acerca de las estructuras de datos, las arquitecturas, las interfaces y los
componentes del software que son necesarios para programar el sistema.
Análisis de Es la etapa distintiva del modelo. En ella se analizan los riesgos que pueden
riesgo afectar la continuidad del proyecto y se evalúa la conveniencia o no de continuar.
A diferencia de otros modelos, esta etapa actúa como vía de escape, permitiendo
no seguir gastando recursos en proyectos inviables
Codificación Basado en las especificaciones del diseño los programadores generan el código
utilizando un lenguaje de programación. Construyen el software propiamente
dicho.
Prueba Frecuentemente se señala a esta etapa como aquella en la cual se prueba que el
software no contenga errores. Sin embargo, no debe probarse que el software
funcione sino que se debe buscar que este falle. Se debe entonces atacar y
someter al programa a diversas condiciones extremas, buscando que aparezcan
errores no detectados en la etapa de la codificación.



• Las entregas sucesivas y el análisis de riesgo lo • No es simple medir los riesgos, mucho menos
vuelven un modelo apto para desarrollos en cuando de ellos depende o no la continuidad
entornos riesgosos y con incertidumbre. del proyecto.
• Puede utilizarse durante todo el ciclo de vida • No siempre el cliente entiende que, a pesar de
útil de un sistema, produciendo sucesivas sus etapas y mejoras sucesivas, es un modelo
versiones mejoradas del producto inicial. controlado con un final previamente
planificado.
• Puede resultar más caro que otros modelos. La
etapa de análisis de riesgo significa mayores
costos aunque también puede permitir ahorros
si los riesgos previstos finalmente ocurren.
10. Modelo de “Desarrollo Rápido de Aplicaciones”
Los actuales entornos avanzados de desarrollo de aplicaciones proveen a los desarrolladores

de poderosas herramientas que permiten generar código con gran rapidez y exactitud. El desarrollo
visual; la generación automatizada de código en múltiples lenguajes; los asistentes; los componentes
reusables o predefinidos; los calendarios grupales; las herramientas colaborativas y las herramientas
de prueba automatizada, entre otras, permiten generar aplicaciones robustas en espacios cortos de
tiempo.
La utilización de estas herramientas da entonces origen a un modelo de desarrollo rápido de

aplicaciones también conocido como RAD por su sigla en inglés (Rapid Application Development). El
propio nombre del modelo hace referencia la posibilidad de generar aplicaciones con mayor
velocidad que los desarrollos tradicionales.
Para agilizar los tiempos de desarrollo el software debe dividirse en partes, para que puedan
ser desarrolladas por varios equipos que trabajan en forma concurrente. Esta división, mas la
reutilización de componentes y las herramientas RAD permiten construir piezas de software de
calidad en tiempos que van de 30 a 90 días. La permanente comunicación con el cliente y entre los
equipos de trabajo se vuelve imprescindible para el éxito final.
Etapa Descripción
Ingeniería de Se relevan los requerimientos y necesidades de la organización. Se prevé la

requerimientos división del sistema para que sea desarrollado por los distintos equipos
simultáneos.
Diseño Se diseña en función de las herramientas RAD y usando los asistentes de esta. Se
analizan los componentes que pueden ser reutilizados y aquellos que será
necesario programar.
Codificación Se utiliza la herramienta RAD para volcar en ella las características que tendrá
cada uno de los componentes del sistema. El código se genera mediante un
proceso semi-automático, pudiendo incluso utilizarse más de un lenguaje y/o
generar para más de un entorno operativo.

Prueba Además de la prueba tradicional, se utilizan las herramientas de prueba
automatizadas provistas en la propia herramienta RAD para reducir los tiempos
de la etapa.


• Los tiempos de desarrollo se acortan • El cliente debe también comprometerse con los
significativamente. plazos cortos de desarrollo y esto implica
• También se reducen los tiempos de prueba y asignar mayor personal al proyecto y por con
los errores no detectados. una mayor carga horaria.
• Pueden construirse sistemas portables o de • No todos los proyectos pueden dividirse ni son
fácil migración entre diferentes entornos y aptos de ser desarrollados con herramientas
sistemas operativos. RAD
• El código generado en forma automática suele
tener menor performance y consumir más
recursos.
• Se complica su implementación en proyectos
grandes porque requiere mucho personal en
forma concurrente.
11. Otros modelos
Si bien los modelos descriptos anteriormente son los más utilizados en desarrollos vinculados
a la administración y a las ciencias económicas, desde luego no agotan la totalidad de los modelos
existentes. El análisis y desarrollo de otros modelos escapa a los alcances del presente trabajo, pero
cabe de todos modos hacer una rápida mención de alguno de ellos, destacando algunas de sus
características principales:
• Desarrollo basado en componentes: Este modelo centra su desarrollo en la reutilización

de software y en el ensamble de componentes existentes. Si bien la reutilización no es
exclusiva de este modelo, puede utilizarse un marco de trabajo especialmente orientado
a trabajar reutilizando múltiples componentes preexistentes.
• Métodos formales: Este modelo intenta hallar modelos matemáticos formales para
asegurar un desarrollo de software libre de errores. Aun cuando difícilmente puedan

encontrarse modelos matemáticos para todo tipo de software, puede ser interesante
considerarse esta formalización cuando se requiera software con alto grado de precisión,
por ejemplo, el desarrollado para el diagnóstico médico o para el manejo de vehículos,
aviones o grandes maquinarias.
12. Elección de un modelo adecuado
Ya se ha mencionado que no existe un mejor modelo para todo tipo de desarrollos y por
ende tampoco la posibilidad de hacer una recomendación certera sobre qué modelo conviene
utilizar. El proyecto y sus características, así como también el cliente y la experiencia y forma de
trabajo del equipo de desarrollo, pueden inclinar la elección hacia un modelo u otro.
Tampoco estos modelos deben ser tomados como caminos obligatorios a seguir. Un proyecto
puede requerir que el desarrollo se realice tomando características de más de un modelo. Por
ejemplo, podría realizarse un prototipo y luego utilizar una herramienta RAD. O realizar un análisis de
riesgo en alguna de las iteraciones del modelo secuencial incremental.
Incluso es factible que el desarrollador experimentado o la empresa de desarrollo armen su

propio modelo, con las características que mejor se adapten a su forma de trabajar, al tipo de
sistemas que realicen o al tipo de clientes para los cuales desarrollen.
De cualquier manera, es posible dar algunas recomendaciones genéricas, comparando los

problemas habituales a los cuales se enfrentan los desarrollos con las características propias de cada
modelo:
Problema a resolver Modelos recomendados

• El tamaño • Por su simplicidad, el modelo lineal secuencial presenta
ventajas para sistemas de pequeño tamaño.
• En el otro extremo, para proyectos de gran tamaño, la división
y la construcción por etapas suele ser una buena estrategia. En
este sentido, los modelos “evolutivos”, es decir aquellos que
permiten construir versiones sucesivas e incrementales del
software, parecen una buena elección para enfrentar este tipo
de proyectos.
• Complejidad de los • La elaboración de un prototipo ayuda en la comprensión de r

requerimientos requerimientos.
• Los modelos evolutivos evitan la necesidad de que todos los
requerimientos deban ser explicitados al comienzo del
relevamiento.
• Complejidad técnica • Puede utilizarse un prototipo para probar aquellas funciones

técnicamente más complejas.
• El modelo en espiral permite contemplar y evaluar riesgos
técnicos.
• Tiempos disponibles • El modelo de desarrollo rápido de aplicaciones permite reducir

los tiempos de generación de aplicaciones.

• Entornos riesgosos • El modelo en espiral contempla situaciones de riesgo y la
evaluación de impacto sobre el sistema.
13.Limitaciones
Si bien a lo largo del apunte se han mencionados diferentes modelos que se adecúan a diversas
situaciones, existen escenarios, particularmente aquellos sujetos a cambios continuos, en los cuáles
estos modelos se vuelven ineficaces. Entre las limitaciones de estos modelos podemos mencionar:
• Todos los requerimientos deben plantearse de antemano y no permiten incorporar

cambios, ni aquellos producidos por la organización ni aquellos surgidos por el contexto.
• Los cronogramas son definidos de antemano, impidiendo que el usuario cambie las
prioridades.
• Existe escasa participación del usuario en el proceso de desarrollo. El sistema finalmente
entregado no siempre cumple sus expectativas y requiere una capacitación importante.
• El ciclo de desarrollo, aun en aquellos modelos evolutivos, resulta demasiado extenso
para determinado tipo de organizaciones que se enfrentan a escenarios de cambio
permanente.
• La documentación y los procesos formales no siempre son bienvenidos por todas las
organizaciones
En los últimos años se han propuesto una serie de modelos denominados “agiles”, que buscan
satisfacer al cliente con la entrega rápida de software incremental, que puede ser cambiado
fácilmente para adaptarse a las nuevas necesidades.
Agradecimiento
Agradezco la especial dedicación del Dr. Carlos Waldbott en la colaboración para el armado y en la
revisión del presente trabajo.
Bibliografía y sitios consultados
1. ROGER PRESSMAN: Ingeniería del Software. 6ta Edición. 2005. Ed. McGraw-Hill.
2. IAN SOMMERVILLE: Ingeniería de Software. 6ta Edición. 2002. Pearson Education.
3. SHARI LAWRENCE PFLEEGER: Ingeniería de Software. 1ra Edición. 2002. Prentice Hall.
4. WIKIPEDIA: Ingeniería del Software http://es.wikipedia.org/wiki/Ingenieria_de_software
El presente trabajo ha sido preparado como material de lectura complementario a la bibliografía de las materias
de la Facultad de Ciencias Económicas de la UBA. Puede ser distribuido libremente y por cualquier medio entre
los alumnos de los cursos que así lo consideren. No debe alterarse el formato y/o contenido original.


Modelos para El Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Modelos para El Desarrollo de Software

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelos para El Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Modelos para el desarrollo de software

Una visión integrada y orientada a proyectos vinculados con la Administración y

Autor: Lic. César Ariel Briano

Facultad de Ciencias Económicas

3. Desarrollo de Sistemas. Enfoque clásico ......................................................................................... 2

4. Una propuesta integral.................................................................................................................... 3

5. Distintos problemas y sistemas, distintos modelos ........................................................................ 4

6. Modelo “Lineal Secuencial” (“En Cascada” o “Ciclo de Vida”) ........................................................ 7

7. Modelo “Lineal Secuencial Iterativo o Incremental” ...................................................................... 8

8. Modelo de “Prototipos” .................................................................................................................. 9

9. Modelo en “Espiral” ...................................................................................................................... 10

10. Modelo de “Desarrollo Rápido de Aplicaciones” ...................................................................... 12

11. Otros modelos ........................................................................................................................... 13

12. Elección de un modelo adecuado ............................................................................................. 14

Bibliografía y sitios consultados ............................................................................................................ 15