1. ¿Cuál es el objetivo de la Etapa de Ing. de Sistemas? ¿Cuál es el nombre de su salida?

¿Cuál es
la Estructura de su salida?
Los objetivos y requisitos operacionales de mayor detalle son identificados gracias a la información
facilitada por el cliente. Los requisitos son analizados para valorar su claridad, completitud y
consistencia. Finalmente, los requisitos del sistema son gestionados para asegurar que los cambios se
controlan adecuadamente.
El producto final obtenido por la ingeniería de sistemas es una representación global del sistema. Se
puede realizar a través de un prototipo, una especificación o, incluso, un modelo simbólico, debiendo
comunicar la operativa, la funcionalidad y las características de comportamiento del sistema que se va
a construir o modificar e incorporarlo dentro del modelo que llamamos: proceso de negocio.

Adicionalmente, se adjuntan alternativas de solución en un paquete denominado Propuesta de

Solución. Las alternativas contenidas en la Propuesta de Solución son sometidas a juicio por el cliente
quién determinará cuál es la que más se adapta a sus requerimientos.

Por lo general, denominamos a la salida de la ingeniería de sistemas como: Estudio Previo.

2. Liste las Actividades que se desarrollan en la Etapa de Planificación de Proyecto.

Algunas de las actividades que se realizan, son las siguientes:

 Descomposición del Ámbito de producto.

 Descomposición del Producto.
 Selección del Modelo de Proceso.
 Descomposición del Proceso.
 Ajustes de Proceso.
 Ajustes de Proyecto.
 Estimación de Esfuerzos.
 Estimación de Costos.
 Estimación de Tiempos.
 Cálculo de Indicadores de Evaluación de Proyecto.
 Planificación Temporal de Actividades y Asignación de recursos. Plan de Desarrollo de
Software.

3. Liste las tres Actividades que se desarrollan en la Etapa de Análisis. Desarrolle cada una.

MODELADO
Los modelos se crean para entender mejor la entidad que se va a construir. El conjunto de modelos
que se obtienen con la etapa de análisis se denomina: Modelo de Análisis.

Debe ser capaz de modelar la información que transforma el software, las funciones que permiten que
ocurran las transformaciones y el comportamiento de sistema cuando ocurren estas transformaciones.
El proceso de modelado convierte los requisitos, sólo listados en la etapa anterior, en especificación de
requisitos.

ESPECIFICACION DE REQUISITOS
Se produce en la culminación de la tarea de análisis. La función y rendimiento asignados al software
como parte del sistema se refinan estableciendo una completa descripción de la información, una
descripción detallada de la función y el comportamiento, una indicación de los requisitos de rendimiento
y restricciones del diseño, criterios de validación apropiados y otros datos pertinentes a los requisitos.

Luego de determinados los requisitos en la Etapa de Ingeniería de Sistemas, esta Etapa comienza la
especificación de los mismos con el modelado y concluye con la creación de la Carpeta de
Especificación de Requisitos que contiene el Modelo de Análisis.
 REVISION Y VALIDACION
La revisión es llevada a cabo tanto por el desarrollador del software como por el cliente. Como la
especificación forma el fundamento para el diseño y las subsiguientes actividades de la ingeniería, se
debería poner extremo cuidado al realizar esta actividad o proceso.

Inicialmente la revisión se lleva a cabo a nivel macroscópico. A este nivel, los revisores intentan
asegurarse que la especificación sea completa, consistente y correcta cuando la información general,
funcional y de los dominios del comportamiento son considerados. Asimismo, una exploración completa
de cada uno de estos dominios, la revisión profundiza en el detalle, examinando no solo las
descripciones superficiales, sino la forma en la que los requisitos fueron especificados.

Una vez que se ha completado la revisión, se firma la especificación de requisitos por el cliente y el
desarrollador. La especificación se convierte en un “contrato” para el desarrollo de software. Las
peticiones de cambios en los requisitos una vez que se ha finalizado y firmado la Carpeta de
Especificación, no se eliminarán o desecharán, pero el cliente debe saber que cada cambio a posteriori
significa una ampliación del ámbito del sistema, y por tanto, pueden aumentar los costos y prolongar
los plazos de planificación temporal del proyecto inicial.

4. ¿Cuál es el objetivo de la Etapa de Análisis? ¿Cuál es el nombre de su salida? ¿Cuál es la

Estructura de la Salida? Indique los objetivos de cada una de sus partes.
El modelo de análisis debe lograr tres objetivos primarios:

1. Describir lo que requiere el cliente.

2. Establecer una base para la creación de un diseño del software.
3. Definir o “Especificar” el conjunto de requisitos de forma que se pueda validar una vez que se
construye el software.
La Carpeta de Especificación es el producto final de la actividad de análisis , es comúnmente llamada
también Modelo de Análisis.

1.1.1 ESTRUCTURA DEL MODELO DE ANALISIS

Uno de los productos más importantes del proceso de análisis es el Modelo de Análisis.

La fig. 2 muestra su estructura.

Para lograr estos objetivos, el modelo de análisis producido durante el análisis estructurado contiene
los siguientes componentes.

DD: Diccionario de Datos: Se encuentra en el centro del modelo, es su núcleo. Es un almacén que
contiene definiciones de todos los objetos de datos consumidos y producidos por el software. Contiene
la especificación de los flujos de datos, elementos de dato, almacenes, etc.
de

Es Proc
s

pe es
tos eto

ci f o
Da e Obj

i ca ( E
cio P)

Diagrama Diagrama
d

ne

de Flujo
ión

de
sd

de
ipc

Entidad
e

Datos
scr

Relación Diccionario
De

de Datos

Diagrama de Transición
de Estados

Especificaciones de
Control (EC)

Figura 1: Estructura del Modelo de Análisis.

Tres diagramas diferentes rodean el núcleo.

DER – Diagrama de Entidad Relación: Representa las relaciones entre los objetos de datos. El DER
es la notación que se usa para realizar la actividad de modelado de datos. Los atributos de cada objeto
de dato señalados en el DER se pueden describir mediante una descripción de objetos de datos.

DFD – Diagrama de Flujo de Datos: Sirve para dos propósitos: (1) proporcionar una indicación de
cómo se transforman los datos a medida que se avanzan en el sistema, y (2) representar las funciones
que transforman el flujo de datos. El DFD proporciona información adicional que se usa durante el
análisis del dominio de información y sirve como base para el modelado de función.

DTE – Diagrama de Transición de Estados: Indica cómo se comporta el sistema como consecuencia
de sucesos externos. Para logra esto, el DTE representa los diferentes modos de comportamiento
(llamados estados) del sistema y la manera en que se hacen las transiciones de estado a estado. Sirve
como la base del modelado de comportamiento.

Más alejados de núcleo, se encuentran los Diagramas de Especificación de Procesos y las

Especificaciones de Control.

EP – Especificación de Procesos: Aquí se encuentra una descripción de cada función presentada en

el DFD. Puede utilizarse para la EP técnicas como la propuesta por los Diagramas N-S, Pseudocódigo,
diagramas de flujos convencionales (rectángulos, rombos, flechas, etc.), tablas de decisión, etc.

EC – Especificación de Control: Dentro de la EC se encuentra más información sobre los aspectos

de control del software.

Todos los modelos del modelo de análisis acompañan la Carpeta de Especificación.

5. Desarrolle la Etapa de Mantenimiento (objetivos, tipos) y Ejemplifique cada uno de los tipos de
Mantenimiento.
Durante la fase de mantenimiento encontramos cuatro tipos de cambios en el software.

1.2 MANTENIMIENTO CORRECTIVO

Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente
descubra defectos en el producto.

D
Mantenimiento Correctivo, Definición.
El mantenimiento correctivo cambia el software para corregir los defectos.

1.3 MANTENIMIENTO ADAPTATIVO

Con el paso del tiempo, es probable que cambie el entorno original para el que se desarrollo el producto.
Cambios de CPU, hardware, software de base, reglas de la empresa o características externas al
producto son posibles.

D
Mantenimiento Adaptativo, Definición.
El mantenimiento adaptativo produce modificaciones en el software para acomodarlo a los cambios de
su entorno.

1.4 MANTENIMIENTO PERFECTIVO

Conforme se utilice el software, el cliente o usuario puede descubrir funciones adicionales que van a
producir beneficios.
 D
Mantenimiento Perfectivo, Definición.
El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

1.5 MANTENIMIENTO PREVENTIVO

El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo
también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las
necesidades de los usuarios finales.
D
Mantenimiento Preventivo, Definición.
En esencia, el mantenimiento preventivo hace cambios en el producto a fin de que se puedan corregir,
adaptar y mejorar más fácilmente.

6. ¿Cuáles son las generalidades y elementos de cada Etapa Genérica de Desarrollo de Software?
Seleccione una y desarrolle.

1. Objetivos.
2. Protagonistas con distintos roles.
3. Herramientas y Métodos.
4. Procesos y Procedimientos.
5. Documentación.

HERRAMIENTAS Y METODOS
Las herramientas y métodos, en general, suelen ser las mismas pero cada empresa de desarrollo
elegirá un conjunto propio y seguramente utilizará herramientas particulares. Las herramientas son
independientes del proceso, y por naturaleza, no pertenecen a ninguno de ellos, por el contrario una
herramientas puede ser utilizada en distintos procesos de desarrollo, al igual que los métodos.
7. ¿Qué es un Modelo de Proceso? ¿Para qué sirve? ¿Por qué surgen varios modelos?

Un modelo de proceso de desarrollo es el ordenamiento estratégico de las fases genéricas de

desarrollo. Como sabemos, un objetivo se puede lograr de varias formas, cada una de estas formas es
una estrategia distinta.

Los modelos de proceso son muy importantes ya que las fases genéricas de desarrollo por sí solas no
son suficientes, hacen falta estrategias de aplicación para ellas, hace falta un modelo de proceso que
permita aplicarlas de manera exitosa.

Para resolver problemas reales de una industria, los ingenieros deben incorporar una estrategia de
desarrollo que acompañe al proceso de las fases genéricas, los métodos y capas de herramientas como
así también la calidad. Esta estrategia se llama modelo de proceso o paradigma de ingeniería de
software. Cada modelo representa un intento por ordenar una actividad inherentemente caótica. Es
importante recordar que cada uno de los modelos se ha caracterizado de forma que ayuden (con
esperanza) al control y la coordinación de un proyecto de software real. Y a pesar de eso, en el fondo,
todos los modelos exhiben características del “Modelo del Caos”.

8. ¿Cuáles son las particularidades y generalidades de los Modelos de Proceso?

Cada modelo de proceso que surgió desde aquellos años propuso estrategias distintas para el
desarrollo de software. Estas estrategias hacían que la configuración de los modelos de proceso
propuestos para el desarrollo de software se distinguiera el uno del otro. Cada cual ponía énfasis en
distintos detalles. Algunos modelos se centraron en las características del cliente, otros en los riesgos
del producto de software, otros surgieron como propuestas especializadas para sistemas de gran
escala, otros al contrario, en sistemas pequeños, otros se centraron en la calidad del producto y así las
diferencias siguen.

9. ¿Cuáles son los Tipos de Modelo de Proceso que conoce? Desarrolle.

TIPOS DE MODELOS
Existe una clásica tipología de modelos de proceso realizada a medida que nuevos procesos se
abrieron paso en la industria.

LINEALES O SECUENCIALES
Aplican las fases genéricas de forma lineal o también llamada secuencial. Significa que no se puede
iniciar una fase antes de concluir la otra. Y, luego de concluir una fase, ésta se da por terminada y no
se prevé volver hacia atrás.

Suponen una entrega de producto cuando éste ha sido completamente desarrollado y probado.

Son los primeros modelos aparecidos en la industria y son esencialmente caóticos y desastrosos. Sin
embargo, algunas pequeñas modificaciones sobre alguno de ellos, hoy por hoy, resultan muy
prometedoras.

ITERATIVOS EVOLUTIVOS
Parten de una filosofía centrada en la evolución y suponen que un producto siempre se puede mejorar
y no es posible entregar al cliente un producto sobre el que se diga: “está completamente concluido”.

La evolución hace que primero se llegue a una primera versión del software y luego, a través de
sucesivas iteraciones que aplican las fases genéricas de desarrollo de software una y otra vez, se van
consiguiendo nuevas y renovadas versiones del mismo producto que incluyen mejoras y nuevas
funciones.

La característica de iterativos, permite aplicar las fases genéricas una y otra vez al mismo producto
obteniendo así versiones nuevas con funciones que la versión anterior no contenía.

ITERATIVOS INCREMENTALES
Los modelos incrementales apuntan al desarrollo del producto final. La entrega contiene todas las
funciones requeridas, es un producto concluido funcionalmente.

Luego, las iteraciones sucesivas irán potenciando las nuevas versiones pero sin el agregado de nuevas
funciones, más bien perfeccionan la primera versión.

Esta filosofía indica que cualquier nueva función del producto lo transforma en otro producto, y no en
una nueva versión.

Los modelos incrementales obtienen en cada iteración un producto más potente o versiones más
potentes de un mismo producto.

Los modelos evolutivos obtienen en cada iteración un producto más funcional al usuario o una versión
con más funciones.

10.Desarrolle de forma completa e l Modelo: _______ (Fases, Ventajas, Desventajas, etc.)

MODELO DE CASCADA

Típicamente lineal y secuencial, sugiere un 3. Diseño.

enfoque sistemático, secuencial, para el 4. Generación de Código.
desarrollo del producto que comienza en un 5. Integración y Prueba.
nivel de sistemas y progresa con el análisis, 6. Mantenimiento.
diseño, codificación, pruebas y mantenimiento.

a. FASES PROPUESTAS Como regla, una etapa de desarrollo debe

completarse antes de dar comienzo a la
1. Ingeniería y modelado a nivel de siguiente.
información del sistema.
2. Análisis.
 b. VENTAJAS Y hoy en día sea el menos indicado para,
DESVENTAJAS justamente, grandes sistemas.
Su simplicidad hace que sea fácil explicarlo a
los clientes que no están familiarizados con el Otro tipo de producto para el cual no tuvo éxito
desarrollo de software, explicita los productos es el de productos nuevos o que nunca se
intermedios que son necesarios a fin de poder construyeron y que, a la par, tienen una alta
comenzar la siguiente etapa de desarrollo. cuota de riesgo de fracaso.

El mayor problema con el modelo de cascada
es que no refleja la manera en que realmente
se hace el desarrollo del código. Excepto para
los problemas perfectamente comprendidos, el
software se desarrolla normalmente con un alto
grado de repetición.
Aunque según su autor, está creado para el
desarrollo de grandes sistemas [ROY70], la
evolución de los procesos de software hace que
Este modelo es posible prescribirlo sólo para el
desarrollo de sistemas muy pequeños, donde
exista muy poco riesgo y los requisitos sean
perfectamente definibles por desarrollador y
cliente. Es también indicado para productos de
sistemas ampliamente conocidos,
generalmente de nivel transaccional
(facturación, stock, proveedores, clientes,
impuestos y bancos, ventas, compras, etc).

MODELO DRA – DESARROLLO RAPIDO DE APLICACIONES

El Desarrollo Rápido de Aplicaciones (DRA) es
un modelo de proceso para el desarrollo de
productos de software lineal secuencial que
enfatiza un ciclo de desarrollo extremadamente
corto. El modelo DRA es una adaptación de
“alta velocidad” del modelo de cascada en el
que se logra el desarrollo rápido utilizando una
construcción basada en componentes.
Si se comprenden bien los requisitos y se limita
el ámbito del proyecto, el proceso DRA permite
al equipo de desarrollo crear un “sistema
completamente funcional” dentro de períodos
cortos de tiempo que van de los 60 a los 90 días
[MAR91]1.
c. FASES PROPUESTAS
atributos, de cada uno de los objetos y las
relaciones entre estos objetos. El modelado de
datos, coincide perfectamente con el modelado
de datos propuesto por las fases genéricas.
Modelado de Procesos. 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.

2. Modelado de Gestión.
3. Modelado de Datos.
4. Modelado de proceso.
5. Generación de aplicaciones.
6. Pruebas y Entrega.

Modelado de Gestión. El flujo de información

entre las funciones de gestión se modela de
forma que responda a las siguientes preguntas:
¿Qué información conduce el proceso de
gestión? ¿Qué información se genera? ¿Quién
la genera? ¿A dónde va la información? ¿Quién
la procesa? El modelado de gestión posee
técnicas específicas que adaptan las primeras
etapas de la fase genérica de definición a
procesos típicamente empresariales.

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, llamadas
 sistemas de información insertos en procesos
Equipo DRA 3
de negocio empresarial.
Modelado de
Gestión Esto significa que no es apto para el desarrollo
de productos sobre los que no se posean
Modelado de antecedentes o que sean empotrados,
Datos
empaquetados o que tengan implícito
Modelado de
demasiado riesgo. Obviamente, las limitaciones
Procesos de tiempo impuestas en un proyecto DRA
Equipo DRA 2 demandan “ámbito en escalas” [KER94]. Es
Generación de
Aplicaciones
decir, si una aplicación de gestión puede
Modelado de modularizarse de forma que permita
Gestión
completarse cada una de las funciones
Pruebas y Entrega
Modelado de
principales en menos de tres meses utilizando
Datos las fases descritas, es un candidato del DRA.

Modelado de Cada una de las funciones del producto debe

Procesos
Equipo DRA 1
ser afrontada por un equipo DRA separado y
Generación de ser integradas a un solo conjunto.
Aplicaciones
Modelado de
Gestión Al igual que todos los modelos de proceso, el
Pruebas y Entrega enfoque DRA tiene inconvenientes [BUT94] 2:
Modelado de
Datos
 Para proyectos grandes aunque
Modelado de fraccionados en escalas pequeñas, el
Procesos
DRA requiere recursos humanos
Generación de
suficientes como para crear el número
Aplicaciones correcto de equipos DRA, situación
difícil de lograr de primera instancia.
Pruebas y Entrega
 DRA requiere clientes y
60 a 90 Días desarrolladores comprometidos en las
rápidas actividades necesarias para
Figura 2: El Modelo DRA.
completar un sistema en un marco de
tiempo abreviado. Si no hay
Generación de Aplicaciones. El DRA asume
compromiso por ninguna de las partes
la utilización de técnicas de cuarta generación
constituyentes, los proyectos DRA
(que veremos más adelante). En lugar de crear
fracasan.
software con lenguajes de programación de
tercera generación, el proceso DRA trabaja
 No todos los tipos de aplicaciones son
para volver a utilizar componentes de programa
apropiados para DRA. Si un sistema
ya existentes (cuando esto sea posible) o crear
no puede modularizarse
componentes reutilizables (cuando sea
adecuadamente, la construcción de
necesario). En todos los casos se utilizan
los componentes necesarios será
herramientas para facilitar la construcción del
problemática. Si está en juego el alto
software.
rendimiento, que se piensa que se
obtendrá, convirtiendo interfaces en
Pruebas y Entrega. Como el proceso DRA
componentes de sistema, el enfoque
enfatiza la reutilización, ya se han comprobado
DRA puede que no funcione.
muchos de los componentes de los programas.
Esto reduce tiempo de pruebas. Sin embargo,
 DRA no es adecuado cuando los
se deben probar todos los componentes
riesgos técnicos son altos. Esto ocurre
nuevos y se deben ejercitar todas las pruebas
cuando una nueva aplicación hace uso
de integración de interfaces a fondo.
de tecnologías nuevas, o cuando el
a. VENTAJAS Y software nuevo requiere un alto grado
DESVENTAJAS de interoperatividad con programas de
computadora ya existentes.
Está orientado fundamentalmente a la
producción de productos que prestan soporta a
MODELO DE CONSTRUCCION DE PROTOTIPOS
La filosofía del prototipado es que cliente y
desarrollador se entiendan con un modelo de
sistema, inoperable, que muestre
prácticamente todas las interfaces de entrada y
salida (o por lo menos las más importantes). De
esta forma el desarrollador puede comprender
bien lo que el sistema debe hacer para
transformar entradas en salidas. Luego que los
requisitos fueron comprendidos, recién se
comienza con el desarrollo del producto real. El
prototipo se desecha después que el nuevo
sistema está en operación.
El uso y aplicación de prototipado ha cambiado
con el tiempo. Aunque el modelo de prototipos
ha sido comprendido como modelo en su
época, hoy sabemos que no reviste las
características de un modelo, ya que, de la
forma en que se lo describe, sólo interviene en
una etapa o fase de otro modelo y sólo sirve
para el descubrimiento de los requisitos.
Lo que sucede es que el desarrollador jamás
estará de acuerdo en tirar a la basura un trabajo
ya realizado que, supuestamente, puede
reciclar y continuar sobre él la construcción del
sistema definitivo. Por otro lado, el cliente no
estará de acuerdo que se cambie la idea inicial
contenida en el prototipo, al cliente le gusta lo
que ya está hecho y no concibe pagar para que
se haga de nuevo, a lo que se le agrega, que
no comprende aún por qué eso que “ve” es
inoperable e inutilizable.
Ambas fuerzas (cliente y desarrollador), con el
tiempo, han convertido el prototipado en un
completo modelo con serios riesgos.
El modelo de prototipado surge con la
necesidad de reducir los riesgos que plantea la
comunicación insuficiente entre cliente y
desarrollador, pero si no se lo complementa,
más que facilitarla, la confunde. Siendo así, hay
que observar el prototipado como una técnica
que colabora con algún modelo de proceso,
más que como un modelo.
b. FASES PROPUESTAS
El modelo de prototipado comienza con la
recolección de requisitos. El desarrollador y el
cliente encuentran y definen los objetivos
globales para el software, identifican los
requisitos conocidos y las áreas del esquema
en donde es obligatoria más definición.
Entonces aparece un “diseño rápido” con la
escucha del cliente. El diseño rápido se centra
en una representación de esos aspectos del
software que serán visibles para el usuario y el
cliente (por ejemplo enfoques de entrada y
formatos de salida).
El diseño rápido lleva a la construcción de un
prototipo, también llamado maqueta. El
prototipo es evaluado por cliente y usuario y se
utiliza para refinar los requisitos del producto a
desarrollar.
La primera iteración ocurre cuando el prototipo
se pone a punto para satisfacer las
necesidades del cliente, permitiendo al mismo
tiempo que el desarrollador comprenda mejor lo
que necesita hacer.
La puesta a punto del prototipo significa que se
completa con los procesos internos para la
conversión de entradas en salidas.
Tomado de esta forma, el prototipado es
fundamentalmente un modelo iterativo
incremental.
Construir y
Revisar
Escuchar al Maqueta
Cliente
El Cliente
Prueba la
Maqueta
Figura 3: Modelo de Construcción de
Prototipos.
c. ETAPAS
El modelo trabaja iterativamente en dos etapas
con varias iteraciones cada una:
 En una primera etapa refina la
comunicación cliente/desarrollador
completando los requisitos del cliente y
usuarios, una vez completada la vista
externa del producto.
 La siguiente etapa que se logra con
otras varias iteraciones, completa la
operatoria interna de procesos que
convertirán entradas en salidas. Esta
mecánica se aplica una y otra vez
hasta que el producto está en
operación completa.
Es incremental porque, por lo general, se
trabaja sobre el producto de forma completa, es
decir, sobre la totalidad de requisitos
funcionales. Cada iteración completa
solamente los requisitos definidos inicialmente
y no agrega otra función al producto.
d. VENTAJAS Y
DESVENTAJAS
Un cliente, a menudo, define un conjunto de
objetivos generales para el software, pero no
identifica los requisitos detallados de entrada,
proceso o salida.
En otros casos el responsable del desarrollo
puede no estar seguro de la eficacia de un
algoritmo, de la capacidad de adaptación, o de
la forma en que debería tomarse la interacción
hombre máquina. En estas y otras muchas
situaciones, un modelo de construcción de
prototipos puede ofrecer el mejor enfoque.
Lo ideal sería que el prototipo sirviera sólo para
la identificación de requisitos, sin embargo, la
construcción de prototipos suele ser
problemática por las siguientes razones:
 El cliente ve lo que parece ser una
versión final del producto, sin tener
conocimiento de que el prototipo
también está junto con “el chiclé y el
cable de embalar”, sin saber que con la
prisa de hacer que funcione no se ha
tenido en cuenta la calidad del producto
global o la facilidad de mantenimiento a
largo plazo. Cuando se informa que el
producto se debe construir otra vez
para que puedan mantener los niveles
altos de calidad, el cliente no lo
MODELO INCREMENTAL
El modelo incremental combina elementos del
modelo de cascada con la filosofía iterativa de
construcción de prototipos. Cada secuencia
lineal produce un incremento del software.
e. FASES PROPUESTAS
El modelo incremental comienza con un
análisis preliminar para determinar los
requisitos, continúa con las descomposiciones
del producto y proceso y planifica qué funciones
se desarrollarán en cada iteración.
Se comienza así con el núcleo del producto en
una primera iteración, es decir, se afrontan los
requisitos básicos, y se deja para iteraciones
posteriores el desarrollo de las demás
funciones, algunas conocidas otras no.
Cualquier incremento puede, o no, utilizar el
apoyo de la construcción de prototipos.
entiende y pide que se apliquen “unos
pequeños ajustes” para que se pueda
hacer del prototipo un producto final.
De forma demasiado frecuente la
gestión del proyecto es demasiado
lenta para lograr lo que el cliente pide.
 El desarrollador, a menudo, hace
compromisos de implementación
(poner en operación el producto) para
hacer que el prototipo funcione
rápidamente. Sin embargo, lo que
sucede siempre es que se utiliza para
la construcción del prototipo un sistema
operativo o lenguaje de programación
inadecuado simplemente porque está
disponible y porque es conocido; un
algoritmo eficiente se puede
implementar simplemente para
demostrar la capacidad o, el desarrollo
de las interfaces entre la capa de
presentación (interfaces de usuario) y
la capa de recursos (bases de datos)
resulta doblemente trabajoso porque
es sólo un prototipo y no se desarrolló
con el lenguaje que tuviera en cuenta
estas interfaces. Después de algún
tiempo, el desarrollador debe
familiarizarse con estas selecciones, y
olvidarse de las razones por las que
son inadecuadas. La consecuencia es
que la selección más inapropiada
ahora es una parte integral del sistema.
El cliente utiliza el producto central. Como un
resultado de la utilización y/o evaluación, se
desarrolla un plan para el incremento siguiente.
El plan afronta la modificación del producto
central o núcleo a fin de cumplir mejor las
especificaciones del cliente y la entrega de
funciones y características adicionales. Este
proceso se repite siguiendo la entrega de cada
incremento, hasta que se elabore el producto
completo.
A diferencia de la construcción de prototipos, el
modelo incremental se centra en la entrega de
un producto operacional con cada incremento.
Los primeros incrementos son versiones
incompletas del producto final, pero
proporcionan al usuario la funcionalidad que
precisa y también una plataforma para la
evaluación definitiva.

Incremento 1

Ingeniería de Sistemas
de Información
Pruebas y Entrega del 1º
Análisis Diseño Código
Entrega Incremento

Incremento 2 Pruebas y Entrega del 2º

Análisis Diseño Código
Entrega Incremento

Pruebas y Entrega del 3º

Incremento 3 Análisis Diseño Código
Entrega Incremento

Pruebas y Entrega del 4º

Incremento 4 Análisis Diseño Código
Entrega Incremento

Tiempo Calendario

Figura 4: Modelo Incremental.

Los primeros incrementos se pueden

f. VENTAJAS Y implementar con menos personal.
DESVENTAJAS
Es particularmente útil cuando la dotación de Así se puede igual firmar contrato por un grupo
desarrolladores no está disponible para una de funciones iniciales y dejar para más adelante
implementación completa en la fecha límite que las funciones secundarias o que no
se haya establecido para el proyecto. correspondan al núcleo del producto.

MODELO EN ESPIRAL DE BOEHM

El modelo en espiral, propuesto inicialmente número de tareas de trabajo y su formalidad es

por Barry Boehm [BOE88]3 es el padre de los
modelos evolutivos.
Conjuga la naturaleza iterativa de construcción
de prototipos con los aspectos controlados y
sistemáticos del modelo de cascada.
Proporciona el potencial para el desarrollo
rápido de versiones de mayor evolución de un
producto en sucesivas iteraciones.
g. FASES PROPUESTAS
Durante las primeras iteraciones, las primeras
evoluciones podrían ser en papel o prototipo.
Durante las últimas iteraciones, se producen
versiones cada vez más completas del sistema
diseñado.
bajo. Para proyectos mayores y más críticos en
relación al riesgo cada región de tareas
contiene tareas de trabajo que se definen para
lograr un nivel más alto de formalidad. En todos
los casos, se aplican las actividades de
protección de proyectos (gestión de
configuración, garantía de calidad, gestión de
proyectos, revisiones técnicas formales,
generación y archivo de documentación del
sistema, gestión de riesgos, etc., que veremos
más adelante en esta misma materia).

El modelo en espiral se divide en un número de

actividades de marco de trabajo, también
llamadas regiones de tareas. Generalmente
existen entre tres y seis regiones. Ver fig. 4.

Cada una de las regiones está compuesta por

un conjunto de tareas que se adaptan a las
características del proyecto que va a
emprenderse. Para proyectos pequeños, el
 Planificación
de Proyectos
6. Evaluación del Cliente. Incluye las
tareas requeridas para obtener la
reacción del cliente según la
Comunicación
con el Cliente Análisis de evaluación de las representaciones del
Riesgos
producto creadas durante la etapa de
ingeniería de producto e implementada
Proy Proy Proy Proy
Eje de Punto de Entrada de Proyectos durante la fase de construcción y
4 3 2 1
acción.

Ingeniería de ii. PROYECTOS

Producto (o
Ingeniería de
Evaluación
del Cliente
Construcción y
Acción
Proy 1 Proyecto de Desarrollo de Conceptos.
Proy 2 Proyecto de Desarrollo de Aplicaciones y Nuevos Productos.
Proy 3 Proyecto de Mejora de Productos Desarrollados.
Proy 4 Proyecto de Mantenimiento Perfectivo y Evolutivo.
Figura 5: Modelo en Espiral de Boehm.
i. FASES DE
ITERACIÓN
PROYECTO
1. Comunicación con el Cliente. Incluye
las tareas requeridas para establecer
comunicación entre el desarrollador y
el cliente.
2. Planificación de Proyectos. Incluye
las tareas requeridas para definir la
estimación del proyecto, recursos,
tiempo, planificación temporal, costos,
etc.
3. Análisis de riesgos. Incluye las tareas
requeridas para evaluar riesgos
técnicos y de gestión. También incluye
análisis de riesgos de comunicación
con el cliente.
Cuando comienza el proceso evolutivo, el
Software) equipo de ingeniería gira alrededor de la espiral
en la dirección de las agujas del reloj,
comenzando por el centro. Cada uno de los
cubos situados a lo largo del eje puede usarse
para representar el punto de arranque para
diferentes tipos de proyectos sobre un mismo
producto.
 Proyecto de Desarrollo de
Conceptos. El primer circuito de la
espiral puede producir el desarrollo de
una especificación de productos; los
pasos siguientes en la espiral se
podrían utilizar para desarrollar un
CADA prototipo. Este proyecto se aplica para
O productos que son en extremo nuevos
o que nunca se desarrollaron. Un
proyecto de desarrollo de conceptos
comienza en el centro de la espiral y
continuará hasta que se concluye la
primera iteración cuando el concepto
ya está desarrollado o definido. Tal
como se dijo, el concepto del sistema
se puede expresar en un prototipo en
papel o una especificación que aplique
tecnología de programación.
 Proyecto de Desarrollo de
Aplicaciones y Productos Nuevos.
Una vez definido el concepto del
sistema a desarrollar, comienza el
desarrollo de la aplicación o producto
con una nueva iteración y un nuevo
proyecto.

4. Ingeniería de Producto. Se Aunque en el gráfico se representa el desarrollo

desarrollan aquí todas las fases de aplicaciones con el segundo proyecto y en
genéricas de desarrollo de software. una sola iteración, puede adaptarse el modelo
Incluidas las de desarrollo de manuales de forma tal que este desarrollo se logre
de usuario, documentación del evolutivamente en varias iteraciones. De
sistema, etc. cualquier forma habrá un proyecto de desarrollo
de aplicaciones para cada iteración que genere
5. Construcción y Acción. Aplica las el producto completo, partes del producto o
tareas requeridas para la implantación productos que se vallan sumando al sistema.
del producto en el sistema, concluir las
relaciones del sistema con su ámbito,  Proyecto de Mejora. El nuevo
capacitación de personal y soporte de producto evolucionará a través de
usuario. iteraciones alrededor de la espiral
 siempre dentro del segundo proyecto.
El proyecto de mejora no puede
iniciarse hasta que el producto se de
por concluido en el proyecto de
desarrollo. Hay veces en que el
proceso queda inactivo por años, pero
siempre que se inicie una mejora, el
proceso arranca en el punto de entrada
adecuado, para este caso en el
proyecto de mejora. Aunque podemos
hablar aquí de mejorar un producto ya
concluido, no es más que aplicar
mantenimiento adaptativo, pero a la
vez, el concepto de este tipo de
mantenimiento es tomado en este
contexto, como un proyecto de mejora
y no un proyecto de mantenimiento.
 Proyecto de Mantenimiento. Los
proyectos de mantenimiento son
orientados fundamentalmente al
mantenimiento evolutivo y perfectivo, y
no al mantenimiento correctivo o
adaptativo.
Al aplicarse mantenimiento perfectivo, el
producto no cambia su esencia. Sin embargo,
al aplicarse mantenimiento evolutivo, es
probable que el producto modifique su esencia
completamente y se transforme en otro
producto. Para éste último caso ya estaríamos
iniciando otra espiral desde sus inicios, desde
el desarrollo de (nuevos) conceptos sobre un
producto existente que lo transformará en otro
producto. Varios fueron los críticos que
fundamentaron que este último proyecto, en
realidad no existe. Al aplicarse mantenimiento
evolutivo, el resultado es otro producto. De
todas formas, nosotros debemos tomarlo tal
como lo propone su inventor Barry Boehm.
Finalmente, común e importante para cada
proyecto es el paso por la región de
planificación, que produce ajustes en la
planificación del proyecto. El costo y la
planificación se ajustan con la realimentación
ante la evaluación del cliente. Se ajusta aquí
también el número de iteraciones necesarias
para la conclusión del desarrollo que puede
sucederse en más de una iteración
dependiendo del tipo de proyecto.
h. VENTAJAS Y de construcción de prototipos.
DESVENTAJAS
El modelo en espiral es un enfoque realista del
desarrollo de sistemas y de productos de
software a gran escala. Como el producto
evoluciona, a medida que progresa el proceso,
el desarrollador y el cliente, comprenden y
reaccionan mejor ante riesgos en cada uno de
los niveles evolutivos.
El modelo en espiral utiliza la construcción de
prototipos como mecanismo de reducción de
riesgos, pero, lo que es más importante,
permite a quien lo desarrolla la flexibilidad de
aplicar este enfoque en cualquier etapa de
evolución del producto. De hecho, todo modelo
de desarrollo es propuesto como modelo de
proceso “a adaptar” a las condiciones del
cliente, del producto, del ambiente del sistema,
de los riesgos, etc.
Por otro lugar, mantiene el enfoque sistemático
de los pasos sugeridos por el ciclo de cascada
clásico, pero lo incorpora al marco de trabajo
iterativo que refleja de forma más realista el
mundo real.
El modelo en espiral demanda una
consideración directa de los riesgos técnicos en
todas las etapas de cualquier proyecto, y, si se
aplica adecuadamente, debe reducir los riesgos
antes de que se conviertan en problemáticos.
Al igual que otros modelos o paradigmas, este
no es la panacea. Puede resultar difícil
convencer a grandes clientes, particularmente
en situaciones bajo contrato, de que el enfoque
evolutivo es controlable. Así también, los
clientes no miran con mucho entusiasmo que
en cada planificación se consideren los costos
y los plazos iterativamente. Esta mecánica
traslada, cuando de plazos y costos se trata, los
riesgos al cliente.
Requiere también una considerable habilidad
para la evaluación del riesgo, y cuenta con esta
habilidad para el éxito. Si un riesgo importante
no es descubierto y gestionado,
indudablemente surgirán problemas. Al
respecto, un crítico podría decir que éstas
características no pertenecen al modelo sino
que pertenecen a la industria. Cualquiera que
no tenga experiencia en la aplicación de
cualquier modelo estará más susceptible de
cometer errores. Los errores se van puliendo a
medida que tomamos experiencia, cualquiera
sea el proceso adoptado.
Finalmente, el modelo no se ha utilizado tanto
como los paradigmas lineales secuenciales o
Hoy 2009, a veinte años de su aparición, la
experiencia de la industria con este modelo no
es la suficiente como para arrojar conclusiones
certeras, todavía tendrán que pasar muchos
años antes de que se determine con absoluta
certeza la eficacia de este nuevo, importante y
prometedor paradigma.
1
[MAR91] Martin, J., Rapid Application Development, Editorial Prentice-Hall, 1991.
2
[BUT94] Butler, J., Rapid Application Development in Action, Managing System Development, Applied
Computer Research, vol. 14, nro. 5, Mayo 1994, pp. 38-51.
3
[BOE88] Boehm, Barry, A Spiral Model for Software Development and Enhancement, Computer, vol. 21,
nro. 5, Mayo 1988, pp. 61-72.