INGENIERA

METODOLOGAS Y CICLOS DE VIDA

INTRODUCCIN A LA INGENIERA DEL SOFTWARE

SOFTWARE
IEEE Std. 610 define el software como programas, procedimientos y documentacin y
datos asociados, relacionados con la operacin de un sistema informtico
Segn el Websters New Collegiate Dictionary (1975), software es un conjunto de
programas, procedimientos y documentacin relacionada asociados con un sistema,
especialmente un sistema informtico.
El software se puede definir como el conjunto de tres componentes:
Programas (instrucciones): este componente proporciona la funcionalidad deseada y el
rendimiento cuando se ejecute.
Datos: este componente incluye los datos necesarios para manejar y probar los
programas y las estructuras requeridas para mantener y manipular estos datos.
Documentos: este componente describe la operacin y uso del programa.
Componentes del software
Programas
Los programas son conjuntos de instrucciones que proporcionan la funcionalidad deseada
cuando son ejecutadas por el ordenador. Estn escritos usando lenguajes especficos que
los ordenadores pueden leer y ejecutar, tales como lenguaje ensamblador, Basic,
FORTRAN, COBOL, C Los programas tambin pueden ser generados usando
generadores de programas.
Datos
Los programas proporcionan la funcionalidad requerida manipulando datos. Usan datos para
ejercer el control apropiado en lo que hacen. El mantenimiento y las pruebas de los
programas tambin necesitan datos. El diseo del programa asume la disponibilidad de las
estructuras de datos tales como bases de datos y archivos que contienen datos.
Documentos

Adems de los programas y los datos, los usuarios necesitan tambin una explicacin de
cmo usar el programa.
Documentos como manuales de usuario y de operacin son necesarios para permitir a los
usuarios operar con el sistema.
Los documentos tambin son requeridos por las personas encargadas de mantener el
software para entender el interior del software y modificarlo, en el caso en que sea
necesario.
Tipos de software
El software puede dividirse en dos grandes categoras:
Software de aplicaciones: se usan para proveer servicios a clientes y ejecutar negocios
de forma ms eficiente. El software de aplicaciones puede ser un sistema pequeo o uno
grande integrado. Como ejemplos de este tipo de software estn: un sistema de cuentas,
un sistema de planificacin de recursos
Software de sistemas: el software de sistemas se usa para operar y mantener un
sistema informtico. Permite a los usuarios usar los recursos del ordenador directamente
y a travs de otro software. Algunos ejemplos de este tipo de software son: sistemas
operativos, compiladores y otras utilidades del sistema.
INGENIERA DEL SOFTWARE
Historia
El trmino ingeniera del software apareci por primera vez en la conferencia de ingeniera
de software de la OTAN en 1968 y fue mencionado para provocar el pensamiento sobre la
crisis de software del momento. Desde entonces, ha continuado como una profesin y
campo de estudio dedicado a la creacin de software de alta calidad, barato, con capacidad
de mantenimiento y rpido de construir. Debido a que el campo es todava relativamente
joven comparado con otros campos de la ingeniera, hay todava mucho trabajo y debate
sobre qu es realmente la ingeniera del software, y si se merece el ttulo de ingeniera. Ha
crecido orgnicamente fuera de las limitaciones de ver el software slo como programacin.
Mientras que el trmino ingeniera del software fue acuado en una conferencia en 1968, los
problemas que intentaba tratar empezaron mucho antes. La historia de la ingeniera del
software est entrelazada con las historias contrapuestas de hardware y software.
Cuando el ordenador digital moderno apareci por primera vez en 1941, las instrucciones
para hacerlo funcionar estaban conectadas dentro de la maquina. Las personas
relacionadas con la ingeniera rpidamente se dieron cuenta de que este diseo no era
flexible e idearon la arquitectura de programa almacenado o arquitectura von Neumann. De
esta forma la primera divisin entre hardware y software empez con la abstraccin
usada para tratar la complejidad de la computacin.

Los lenguajes de programacin empezaron a aparecer en la dcada de 1950 y este fue otro
paso importante en la abstraccin. Los lenguajes principales como Fortran, Algol y Cobol se
lanzaron a finales de los 50s para tratar con problemas cientficos, algortmicos y de negocio
respectivamente. Dijsktra escribi Go to Statement Considered Harmful en 1968 y David
Parnas introdujo el concepto clave de la modularidad y encapsulacin en 1972 para ayudar
a los programadores a tratar con la complejidad de los sistemas de software. Un sistema
software para gestionar el hardware, denominado sistema operativo tambin se introdujo,
ms notablemente por Unix en 1969. En 1967, el lenguaje Simula introdujo el paradigma de
la programacin orientada a objetos.
Estos avances en software se encontraron con ms avances en el hardware. A mediados de
los 70s, la microcomputadora fue introducida, haciendo econmico a los aficionados a
obtener una computadora y escribir software para l. Esto sucesivamente condujo al famoso
ordenador personal o PC y Microsoft Windows. El ciclo de vida de desarrollo de software o
SDLC tambin empez a aparecer como un consenso para la construccin centralizada de
software a mediados de los 80s. A finales de los 70s y principios de los 80 se vieron varios
lenguajes de programacin orientados a objetos inspirados en Simula, incluyendo C++,
Smalltalk y Objective C.
El software open source empez a aparecer a principios de los 90s en la forma de Linux y
otros software introduciendo el bazaar o el estilo descentralizado de construccin de
software. Despus aparecieron Internet y la World Wide Web a mediados de los 90s
cambiando de nuevo la ingeniera del software. Los sistemas distribuidos ganaron dominio
como forma de disear sistemas y el lenguaje de programacin Java se introdujo como otro
paso en la abstraccin, teniendo su propia mquina virtual. Varios programadores
colaboraron y escribieron el manifiesto gil que favoreci procesos ms ligeros para crear
software ms barato y en menos tiempo.
Etapas
La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas como
las siguientes:
Anlisis de requisitos
Extraer los requisitos de un producto software es la primera etapa para crearlo. Mientras que
los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad
y experiencia en la ingeniera del software para reconocer requisitos incompletos, ambiguos
o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el
documento Especificacin de Requisitos. Asimismo, se define un diagrama de
entidad/relacin, en el que se plasman las principales entidades que participarn en el
desarrollo de software.
La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte
crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han
ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est
formalizada, se habla de la Ingeniera de Requisitos.

La IEEE Std. 830-1998 normaliza la creacin de las especificaciones de requisitos software.

Especificacin
Es la tarea de escribir detalladamente el software a ser desarrollado, en una forma
matemticamente rigurosa. En la realidad, la mayora de las buenas especificaciones han
sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las
especificaciones son ms importantes para las interfaces externas, que deben permanecer
estables.
Diseo y arquitectura
Se refiere a determinar cmo funcionar el software de forma general sin entrar en detalles.
Consisten en incorporar consideraciones de la implementacin tecnolgica, como el
hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizar el
sistema, y se transformarn las entidades definidas en el anlisis de requisitos en clases de
diseo, obteniendo un modelo cercano a la programacin orientada a objetos.
Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera del
software, pero no necesariamente es la que demanda mayor trabajo ni la ms complicada.
La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los
lenguajes de programacin utilizados, as como al diseo previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo
del software y luego probarlo de forma integral, para as llegar al objetivo. Se considera una
buena prctica que las pruebas sean efectuadas por alguien distinto al desarrollador que la
program.
Mantenimiento
Mantener y mejorar el software para solventar errores descubiertos y tratar con nuevos
requisitos. El mantenimiento puede ser de cuatro tipos: perfectivo (mejorar la calidad interna
de los sistemas), evolutivo (incorporaciones, modificaciones y eliminaciones necesarias en
un producto software para cubrir la expansin o cambio en las necesidades del usuario),
adaptativo (modificaciones que afectan a los entornos en los que el sistema opera, por
ejemplo, cambios de configuracin del hardware, software de base, gestores de base de
datos, comunicaciones) y correctivo (correccin de errores).
Principios de la ingeniera del software
Entre los principios ms destacados de la ingeniera del software, podemos sealar los
siguientes:

Haz de la calidad la razn de trabajar.

Una buena gestin es ms importante que una buena tecnologa.

Las personas y el tiempo no son intercambiables.

Seleccionar el modelo de ciclo de vida adecuado.

Entregar productos al usuario lo ms pronto posible.

Determinar y acotar el problema antes de escribir los requisitos.

Realizar un diseo.

Minimizar la distancia intelectual.

Documentar.

Las tcnicas son anteriores a las herramientas.

Primero hazlo correcto, luego hazlo rpido.

Probar, probar y probar.

Introducir las mejoras y modificaciones con cuidado.

Asuncin de responsabilidades.

La entropa del software es creciente.

La gente es la clave del xito.

Nunca dejes que tu jefe o cliente te convenza para hacer un mal trabajo.

La gente necesita sentir que su trabajo es apreciado.

La educacin continua es responsabilidad de cada miembro del equipo.

El compromiso del cliente es el factor ms crtico en la calidad del software.

Tu mayor desafo es compartir la visin del producto final con el cliente.

La mejora continua de tu proceso de desarrollo de software es posible y esencial.

Tener procedimientos escritos de desarrollo de software puede ayudar a crear una

cultura compartida de buenas prcticas.
La calidad es el principal objetivo; la productividad a largo plazo es una consecuencia
de una alta calidad.

Haz que los errores los encuentre un colaborador, no un cliente.

Una clave en la calidad en el desarrollo de software es realizar iteraciones en todas

las fases del desarrollo excepto en la codificacin.

La gestin de errores y solicitud de cambios es esencial para controlar la calidad y el

mantenimiento.

Si mides lo que haces puedes aprender a hacerlo mejor.

Haz lo que tenga sentido; no recurras a los dogmas.

No puedes cambiar todo de una vez. Identifica los cambios que se traduzcan en los
mayores beneficios, y comienza a implementarlos.

Capas
El enfoque de ingeniera del software cuenta con un compromiso organizacional con la
calidad porque no es posible incorporar la ingeniera del software en una organizacin que
no est centrada en conseguir calidad.

La ingeniera del software es una tecnologa multicapa. Se puede ver como un conjunto de
componentes estratificados, que reposan sobre ese enfoque de calidad.

Herramientas Mtodos Procesos

Un enfoque de calidad

Figura 2.

Capas de la ingeniera del software

Estos componentes que forman parte de la ingeniera del software son:

Procesos: un marco de trabajo que ayuda al jefe de proyecto a controlar la gestin

del proyecto y las actividades de ingeniera.

Mtodos: las actividades tcnicas requeridas para la creacin de productos de

trabajo.

Herramientas: la ayuda automatizada para los procesos y mtodos.

Procesos
El fundamento de la ingeniera del software es la capa de proceso. El proceso define un
marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para
la entrega efectiva de la tecnologa de la ingeniera del software.
La capa de proceso define el proceso que se usar para construir el software y las
actividades y tareas que un jefe de proyecto tiene que gestionar. Por lo tanto, las reas
claves del proceso forman la base del control de gestin de proyectos del software y
establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos de
trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se
asegura la calidad y el cambio se gestiona adecuadamente. El proceso de la ingeniera del
software es la unin que mantiene juntas las capas de tecnologas y que permite un
desarrollo racional y oportuno de la ingeniera del software.
Mtodos
La capa de proceso identifica las tareas de ingeniera que se deben realizar para construir
software de alta calidad.
La siguiente capa, la capa de mtodos se centra en las actividades tcnicas que se deben
realizar para conseguir las tareas de ingeniera. Proporciona el cmo y cubre las
actividades de ingeniera fundamentales.
Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo,
construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera del
software dependen de un conjunto de principios bsicos que gobiernan cada una de las
reas de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.
La construccin de software implica una amplia coleccin de actividades tcnicas. La capa
de mtodos contiene los mtodos definidos para realizar esas actividades de forma
eficiente. Se centra en cmo se han de realizar las actividades tcnicas. Los personas

involucradas usan los mtodos para realizar las actividades de ingeniera fundamentales
necesarias para construir el software.
Herramientas
La capa de herramientas proporciona soporte a las capas de proceso y mtodos
centrndose en el significado de la automatizacin de algunas de las actividades manuales.
Las herramientas se pueden utilizar para automatizar las siguientes actividades:

Actividades de gestin de proyectos

Mtodos tcnicos usados en la ingeniera del software

Soporte de sistemas general

Marcos de trabajo para otras herramientas

La automatizacin ayuda a eliminar el tedio del trabajo, reduce las posibilidades de errores,
y hace ms fcil usar buenas prcticas de ingeniera del software. Cuando se usan
herramientas, la documentacin se convierte en una parte integral del trabajo hecho, en vez
de ser una actividad adicional. De ah que la documentacin no se tenga que realizar como
actividad adicional. Las herramientas se pueden utilizar para realizar actividades de gestin
de proyecto as como para actividades tcnicas.
CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE
CICLOS DE VIDA
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se est
desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado
(muere). Tambin se denomina a veces paradigma.
Entre las funciones que debe tener un ciclo de vida se pueden destacar:

Determinar el orden de las fases del proceso de software

Establecer los criterios de transicin para pasar de una fase a la siguiente

Definir las entradas y salidas de cada fase

Describir los estados por los que pasa el producto

Describir las actividades a realizar para transformar el producto

Definir un esquema que sirve como base para planificar, organizar, coordinar,
desarrollar
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas
que se pueden planificar. Segn el modelo de ciclo de vida, la sucesin de fases puede
ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se
considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto,

recibiendo en cada pasada de ejecucin aportaciones a los resultados intermedios que se

van produciendo (realimentacin).
Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el
desarrollo del proyecto. Se construye agrupando tareas (actividades elementales)
que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La
agrupacin temporal de tareas impone requisitos temporales correspondientes a la
asignacin de recursos (humanos, financieros o materiales).
Entregables: son los productos intermedios que generan las fases. Pueden ser
materiales o inmateriales (documentos, software). Los entregables permiten evaluar
la marcha del proyecto mediante comprobaciones de su adecuacin o no a los
requisitos funcionales y de condiciones de realizacin previamente establecidos.
Tipos de modelo de ciclo de vida
Las principales diferencias entre distintos modelos de ciclo de vida estn en:
El alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente.
Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un
producto, o su desarrollo completo o en el extremo, toda la historia del producto con
su desarrollo, fabricacin y modificaciones posteriores hasta su retirada del mercado.

Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede
depender del propio tema al que se refiere el proyecto, o de la organizacin.

La estructura y la sucesin de las etapas, si hay realimentacin entre ellas, y si

tenemos libertad de repetirlas (iterar).

MODELOS DE CICLO DE VIDA

La ingeniera del software establece y se vale de una serie de modelos que establecen y
muestran las distintas etapas y estados por los que pasa un producto software, desde su
concepcin inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento,
hasta la retirada del producto. A estos modelos se les denomina Modelos de ciclo de vida
del software. El primer modelo concebido fue el de Royce, ms comnmente conocido
como Cascada o Lineal Secuencial. Este modelo establece que las diversas actividades
que se van realizando al desarrollar un producto software, se suceden de forma lineal.
Los modelos de ciclo de vida del software describen las fases del ciclo de software y el
orden en que se ejecutan las fases.
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante
el desarrollo de software, intenta determinar el orden de las etapas involucradas y los
criterios de transicin asociados entre estas etapas.
Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software

Define las fases primarias esperadas de ser ejecutadas durante esas fases

Ayuda a administrar el progreso del desarrollo

Provee un espacio de trabajo para la definicin de un proceso detallado de desarrollo

de software

En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie
de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de
vida, y la eleccin de un modelo para un determinado tipo de proyecto es realmente
importante; el orden es uno de estos puntos importantes.
Existen varias alternativas de modelos de ciclo de vida. A continuacin se muestran algunos
de los modelos tradicionales y ms utilizados.
Modelo en cascada
Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del
software, de forma que el inicio de cada etapa debe esperar a la finalizacin de la
inmediatamente anterior.
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve
fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.
Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido
ampliamente en la ingeniera el software. La innovacin estuvo en la primera vez que la
ingeniera del software fue dividida en fases separadas.
La primera descripcin formal del modelo en cascada se cree que fue en un artculo
publicado en 1970 por Winston W. Royce, aunque Royce no us el trmino cascada en este
artculo. Irnicamente, Royce estaba presentando este modelo como un ejemplo de modelo
que no funcionaba, defectuoso.
En el modelo original de Royce, existan las siguientes fases:
1. Especificacin de requisitos
2. Diseo
3. Construccin (Implementacin o codificacin)
4. Integracin
5. Pruebas
6. Instalacin
7. Mantenimiento
Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma
puramente secuencial.

REQUISITOS

DISEO

IMPLEMENTACIN

PRUEBAS

MANTENIMIENTO

Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo
el paradigma ms seguido a da de hoy.
Modelo en V
El modelo en v se desarroll para terminar con algunos de los problemas que se vieron
utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados
demasiado tarde en el ciclo de vida, ya que las pruebas no se introducan hasta el final del
proyecto. El modelo en v dice que las pruebas necesitan empezarse lo ms pronto posible
en el ciclo de vida. Tambin muestra que las pruebas no son slo una actividad basada en
la ejecucin. Hay una variedad de actividades que se han de realizar antes del fin de la fase
de codificacin. Estas actividades deberan ser llevadas a cabo en paralelo con las
actividades de desarrollo, y los tcnicos de pruebas necesitan trabajar con los
desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y
tareas y producir una serie de entregables de pruebas. Los productos de trabajo generados
por los desarrolladores y analistas de negocio durante el desarrollo son las bases de las
pruebas en uno o ms niveles. El modelo en v es un modelo que ilustra cmo las
actividades de prueba (verificacin y validacin) se pueden integrar en cada fase del ciclo de
vida. Dentro del modelo en v, las pruebas de validacin tienen lugar especialmente durante
las etapas tempranas, por ejemplo, revisando los requisitos de usuario y despus por
ejemplo, durante las pruebas de aceptacin de usuario.
El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del
ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser
producidos durante el desarrollo del producto. La parte izquierda de la v representa la
descomposicin de los requisitos y la creacin de las especificaciones del sistema. El lado
derecho de la v representa la integracin de partes y su verificacin. V significa Validacin y
Verificacin.

INGENIERA
DE REQUISITOS

Validar requisitos

DISEO DEL
SISTEMA

VALIDACIN
DEL SISTEMA

Verificar
diseo

VERIFICACIN
DEL SISTEMA

VERIFICACIN
DEL SOFTWARE

DISEO DEL
SOFTWARE

CODIFICACIN

Realmente las etapas individuales del proceso pueden ser casi las mismas que las del
modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de una
forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificacin, formando
una v. La razn de esto es que para cada una de las fases de diseo se ha encontrado que
hay un homlogo en las fases de pruebas que se correlacionan.
Modelo iterativo
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo
que surge entre las necesidades del usuario y el producto final por malos entendidos
durante la etapa de recogida de requisitos.
Consiste en la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le
entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El
cliente es quien despus de cada iteracin evala el producto y lo corrige o propone
mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las
necesidades del cliente.

ANLISIS

ANLISIS

DISEO

ANLISIS

DISEO

CODIFICACIN

DISEO

CODIFICACIN

PRUEBAS

CODIFICACIN

PRUEBAS

PRUEBAS

Versin 2

Versin 1

Versin 3

Este modelo se suele utilizar en proyectos en los que los requisitos no estn claros por parte
del usuario, por lo que se hace necesaria la creacin de distintos prototipos para
presentarlos y conseguir la conformidad del cliente.
Modelo de desarrollo incremental
El modelo incremental combina elementos del modelo en cascada con la filosofa interactiva
de construccin de prototipos. Se basa en la filosofa de construir incrementando las
funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento
del software.

ANLISIS

ANLISIS

DISEO

ANLISIS

DISEO

CODIFICACIN

CODIFICACIN

PRUEBAS

CODIFICACIN

PRUEBAS

Figura 6.

DISEO

PRUEBAS

Modelo de ciclo de vida incremental

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto

esencial, slo con los requisitos bsicos. Este modelo se centra en la entrega de un

producto operativo con cada incremento. Los primeros incrementos son versiones
incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y
tambin una plataforma para la evaluacin.
Modelo en espiral
El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en
1985, utilizado de forma generalizada en la ingeniera del software. Las actividades de este
modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las
actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis
de riesgos, comenzando por el bucle anterior.
Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de
esfuerzos y tiempo que se consume en hacer productos software; y modelos de ciclo de
vida, ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: el
Modelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta fuertemente
el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las
posibles alternativas de desarrollo, se opta por la de riesgos ms asumibles y se hace un
ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a
evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que
llegue un momento en el que el producto software desarrollado sea aceptado y no necesite
seguir mejorndose con otro nuevo ciclo.
Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modelo
en cascada. El modelo en espiral est pensado para proyectos largos, caros y complicados.
Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en
explicar las iteraciones.
Este modelo fue propuesto por Boehm en 1988 en su artculo A Spiral Model of Software
Development and Enhancement. Bsicamente consiste en una serie de ciclos que se
repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que
dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamente
ha de ser as.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por
ejemplo, la creacin de un sistema operativo.
Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de los
aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.
Tareas:
Para cada ciclo habr cuatro actividades:
1. Determinar o fijar objetivos:
a. Fijar tambin los productos definidos
especificacin, manual de usuario.

obtener:

requerimientos,

b. Fijar las restricciones

c. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos
d. Hay una cosa que solo se hace una vez: planificacin inicial o previa
2. Anlisis del riesgo:

a. Se estudian todos los riesgos potenciales y se seleccionan una o varias

alternativas propuestas para reducir o eliminar los riesgos
3. Desarrollar, verificar y validar (probar):
a. Tareas de la actividad propia y de prueba
b. Anlisis de alternativas e identificacin de resolucin de riesgos
c. Dependiendo del resultado de la evaluacin de riesgos, se elige un modelo
para el desarrollo, que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfaz
de usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos.
4. Planificar:
a. Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos si
continuamos con las fases siguientes y planificamos la prxima actividad.
El proceso empieza en la posicin central. Desde all se mueve en el sentido de las agujas
del reloj.

DETERMINAR
OBJETIVOS

EVALUAR
RIESGOS

PLANIFICAR

DESARROLLAR
Y PROBAR

Las cuatro regiones del grfico son:

La tarea de planificacin: para definir recursos, responsabilidades, hitos y

planificaciones

La tarea de determinacin de objetivos: para definir los requisitos y las restricciones

para el producto y definir las posibles alternativas

La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin

La tarea de ingeniera: para disear e implementar uno o ms prototipos o ejemplos

de la aplicacin

Modelo UML
Qu es UML?
UML es el primer mtodo en publicar una meta-modelo en su propia notacin, incluyendo la
notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un
meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general debera
ser capaz de modelarse a s mismo).
UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse
para visualizar, especificar, construir y documentar todos los artefactos que componen un
sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de
informacin hasta aplicaciones distribuidas basadas en Web, pasando por sistemas
empotrados de tiempo real.
UML es solamente un lenguaje por lo que es slo una parte de un mtodo de desarrollo
software, es independiente del proceso aunque para que sea optimo debe usarse en un
proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.
UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, adems es
un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representacin conceptual y fsica del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o
mediante texto obteniendo modelos explcitos que ayudan a la comunicacin durante el
desarrollo ya que al ser estndar, los modelos podrn ser interpretados por personas que no
participaron en su diseo (e incluso por herramientas) sin ninguna ambigedad. En este
contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos.

Debido a su estandarizacin y su definicin completa no ambigua, y aunque no sea un lenguaje

de programacin, UML se puede conectar de manera directa a lenguajes de programacin
como Java, C++ o Visual Basic, esta correspondencia permite lo que se denomina como
ingeniera directa (obtener el cdigo fuente partiendo de los modelos) pero adems es posible
reconstruir un modelo en UML partiendo de la implementacin, o sea, la ingeniera inversa.
UML proporciona la capacidad de modelar actividades de planificacin de proyectos y de sus
versiones, expresar requisitos y las pruebas sobre el sistema, representar todos sus detalles
as como la propia arquitectura. Mediante estas capacidades se obtiene una documentacin
que es valida durante todo el ciclo de vida de un proyecto.
El lenguaje UML se compone de tres elementos bsicos, los bloques de construccin, las
reglas y algunos mecanismos comunes. Estos elementos interaccionan entre s para dar a
UML el carcter de completitud y no-ambigedad que antes comentbamos.
Los bloques de construccin se dividen en tres partes:

Elementos, que son las abstracciones de primer nivel.

Relaciones, que unen a los elementos entre s.

Diagramas, que son agrupaciones de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:
Elementos estructurales.

Elementos de comportamiento.

Elementos de agrupacin

Elementos de anotacin.
Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos
que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de
dependencia, relaciones de asociacin, relaciones de generalizacin y relaciones de
realizacin.
Se utilizan diferentes diagramas dependiendo de qu, nos interese representar en cada
momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de
detalle..., por esta razn UML soporta un gran numero de diagramas diferentes aunque, en la
practica, slo se utilicen un pequeo nmero de combinaciones.
UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones
entre objetos para poder obtener modelos bien formados, estas son reglas semnticas que
afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por
otros, a la integridad de unos elementos con otros y a la ejecucin, o sea la vista dinmica del
sistema.
UML proporciona una serie de mecanismos comunes que sirven para que cada persona o
entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo
unas ciertas reglas para que en el trasfondo de la adaptacin no se pierda la semntica propia
de UML. Dentro de estos mecanismos estn las especificaciones, que proporcionan la
explicacin textual de la sintaxis y semntica de los bloques de construccin.
Otro mecanismo es el de los adornos que sirven para conferir a los modelos de ms
semntica, los adornos son elementos secundarios ya que proporcionan ms nivel de detalle,
que quiz en un primer momento no sea conveniente descubrir. Las divisiones
comunes permiten que los modelos se dividan al menos en un par de formas diferentes para
facilitar la comprensin desde distintos puntos de vista, en primer lugar tenemos la divisin
entre clase y objeto (clase es una abstraccin y objeto es una manifestacin de esa

abstraccin), en segundo lugar tenemos la divisin interfaz / implementacin donde la interfaz

presenta un contrato (algo que se va a cumplir de una determinada manera) mientras que la
implementacin es la manera en que se cumple dicho contrato.
Por ultimo, los mecanismos de extensibilidad que UML proporciona sirven para evitar
posibles problemas que puedan surgir debido a la necesidad de poder representar ciertos
matices, por esta razn UML incluye los estereotipos, para poder extender el vocabulario con
nuevos bloques de construccin, los valores etiquetados, para extender las propiedades un
bloque, y las restricciones, para extender la semntica. De esta manera UML es un lenguaje
estndar "abierto-cerrado" siendo posible extender el lenguaje de manera controlada.
Elementos Estructurales
Los elementos estructurales en UML, es su mayora, son las partes estticas del modelo y
representan cosas que son conceptuales o materiales.
Clases
Una clase es una descripcin de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semntica. Una clase implementa una o ms interfaces.
Grficamente se representa como un rectngulo que incluye su nombre, sus atributos y sus
operaciones.
Clase

Interfaz
Una interfaz es una coleccin de operaciones que especifican un servicio de una determinada
clase o componente. Una interfaz describe el comportamiento visible externamente de ese
elemento, puede mostrar el comportamiento completo o slo una parte del mismo. Una interfaz
describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca su
implementacin. Se representa con un circulo, , y rara vez se encuentra aislada sino que ms
bien conectada a la clase o componente que realiza.
Interfaz

Colaboracin
Define una interaccin y es una sociedad de roles y otros elementos que colaboran para
proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de
sus elementos. Las colaboraciones tienen una dimensin tanto estructural como de
comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las
colaboraciones representan la implementacin de patrones que forman un sistema. Se
representa mediante una elipse con borde discontinuo.

Colaboracin

Casos de Uso
Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta y que
produce un determinado resultado que es de inters para un actor particular. Un caso de uso
se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es
realizado por una colaboracin. Se representa como en la figura 6, una elipse con borde
continuo.
Caso de uso

Clase Activa
Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por lo y tanto
pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que
sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.
Se representa igual que una clase, pero con lneas ms gruesas
Clase activa

Componentes
Un componente es una parte fsica y reemplazable de un sistema que conforma con un
conjunto de interfaces y proporciona la implementacin de dicho conjunto. Un componente
representa tpicamente el empaquetamiento fsico de diferentes elementos lgicos, como
clases, interfaces y colaboraciones.
Componente

Nodos
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso
computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de
capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Nodo

Estos siete elementos vistos son los elementos estructurales bsico que se pueden incluir en
un modelo UML. Existen variaciones sobre estos elementos bsicos, tales como
actores, seales, utilidades (tipos de clases), procesos e hilos (tipos de clases activas) y
aplicaciones, documentos, archivos, bibliotecas, pginas y tablas (tipos de componentes).
Elementos de comportamiento
Los elementos de comportamiento son las partes dinmicas de un modelo. Se podra decir que
son los verbos de un modelo y representan el comportamiento en el tiempo y en el espacio.
Los principales elementos son los dos que siguen.
Interaccin
Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un
conjunto de objetos, dentro de un contexto particular para conseguir un propsito especfico.
Una interaccin involucra otros muchos elementos, incluyendo mensajes, secuencias
de accin (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos). La
representacin de un mensaje es una flecha dirigida que normalmente con el nombre de la
operacin.
Mquinas de estados
Es un comportamiento que especifica las secuencias de estados por las que van pasando los
objetos o las interacciones durante su vida en respuesta a eventos, junto con las respuestas a
esos eventos. Una mquina de estados involucra otros elementos como son estados,
transiciones (flujo de un estado a otro), eventos (que disparan una transicin) y actividades
(respuesta de una transicin)
Elementos
de
comportamiento

Interaccin

Comprende un conjunto de
mensajes
que
se
intercambian
entre
un
conjunto de objetos, para
cumplir
un
objetivo
especifico.

Mquinas
de
estados

Especifica la secuencia de
estados por los que pasa un
objeto o una interaccin, en
respuesta a eventos.

Elementos de agrupacin
Forman la parte organizativa de los modelos UML. El principal elemento de agrupacin es
el paquete, que es un mecanismo de propsito general para organizar elementos en grupos.
Los elementos estructurales, los elementos de comportamiento, incluso los propios elementos
de agrupacin se pueden incluir en un paquete.
Un paquete es puramente conceptual (slo existe en tiempo de desarrollo). Grficamente se
representa como una carpeta conteniendo normalmente su nombre y, a veces, su contenido.

Elementos
de
agrupacin

Elementos de anotacin
Los elementos de anotacin son las partes explicativas de los modelos UML. Son comentarios
que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento
de un modelo.
El tipo principal de anotacin es la nota que simplemente es un smbolo para mostrar
restricciones y comentarios junto a un elemento o un conjunto de elementos.
Elementos
de
notacin
Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo
UML. Dependencia, asociacin, generalizacin y realizacin,
estas
se
describen
a
continuacin:
Dependencia
Es una relacin semntica entre dos elementos en la cual un cambio a un elemento (el
elemento
independiente) puede afectar a la semntica del otro elemento (elemento dependiente). Se
representa como una lnea discontinua, posiblemente dirigida, que a veces incluye una
etiqueta.
Dependencia

Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones
entre objetos. La agregacin es un tipo especial de asociacin y representa una relacin
estructural entre un todo y sus partes. La asociacin se representa con una lnea continua,
posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos
para indicar la multiplicidad y roles de los objetos involucrados.
Asociacin

Generalizacin

Es una relacin de especializacin / generalizacin en la cual los objetos del elemento

especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta
forma, el hijo comparte la estructura y el comportamiento del padre. Grficamente, la
generalizacin se representa con una lnea con punta de flecha vaca.
Generalizacin

Realizacin
Es una relacin semntica entre clasificadores, donde un clasificador especifica un contrato
que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en
dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de
uso y las colaboraciones que los realizan. La realizacin se representa como una mezcla entre
la generalizacin y la dependencia, esto es, una lnea discontinua con una punta de flecha
vaca.
Realizacin

D
iagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que
un diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas
que normalmente se usan en pequeos subconjuntos para poder representar las cinco vistas
principales de la arquitectura de un sistema.
Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Estos
diagramas son los ms comunes en el modelado de sistemas orientados a objetos y cubren la
vista de diseo esttica o la vista de procesos esttica (s incluyen clases activas).
Diagrama de Clases

Ejemplo de Diagrama de Clases

Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los
diagramas de clases y cubren la vista de diseo esttica o la vista de procesos esttica desde
la perspectiva de casos reales o prototpicos.
Objetos

Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones.
Cubren la vista esttica de los casos de uso y son especialmente importantes para el modelado
y organizacin del comportamiento.

Casos de Uso

Diagramas de Secuencia y de Colaboracin

Tanto los diagramas de secuencia como los diagramas de colaboracin son un tipo de
diagramas de interaccin. Constan de un conjunto de objetos y sus relaciones, incluyendo los
mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinmica del sistema. Los
diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los
diagramas de colaboracin muestran la organizacin estructural de los objetos que envan y
reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de
colaboracin sin perdida de informacin, lo mismo ocurren en sentido opuesto.
Secuencia

Colaboracin

Son diagramas de interaccin, muestran

un conjunto de objetos y sus relaciones,
as como los mensajes que se
intercambian entre ellos. Cubren la vista
dinmica del sistema. El diagrama de
secuencia
resalta
la
ordenacin
temporal de los mensajes, mientras que
el
de
colaboracin
resalta
la
organizacin estructural de los objetos,
ambos siendo equivalentes o isomorfos.
En el diagrama de colaboracin de la
figura de la izquierda, se puede ver que
los elementos grficos no son cajas
rectangulares, como cabra esperar, y
en su lugar encontramos sus versiones
adornadas. Estas versiones tienen
como finalidad evidenciar un rol
especfico del objeto siendo modelado.
En la figura encontramos de izquierda a
derecha y de arriba abajo un Actor, una
Interfaz, un Control (modela un
comportamiento) y una Instancia
(modela un objeto de dato).

Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades.
Estos diagramas cubren la vista dinmica de un sistema y son muy importantes a la hora de
modelar el comportamiento de una interfaz, clase o colaboracin.

Estados

Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades
dentro de un sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y
se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre
objetos.
Actividades

Diagramas de Componentes
Muestra la organizacin y las dependencias entre un conjunto de componentes. Cubren la vista
de la implementacin esttica y se relacionan con los diagramas de clases ya que en un
componente suele tener una o ms clases, interfaces o colaboraciones

Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y los
componentes que residen en ellos. Muestran la vista de despliegue esttica de una arquitectura
y se relacionan con los componentes ya que, por lo comn, los nodos contienen uno o ms
componentes.

Diagrama de Despliegue
Arquitectura

El desarrollo de un sistema con gran cantidad de software requiere que este sea visto desde
diferentes perspectivas. Diferentes usuarios (usuario final, analistas, desarrolladores,
integradores, jefes de proyecto...) siguen diferentes actividades en diferentes momentos del
ciclo de vida del proyecto, lo que da lugar a las diferentes vistas del proyecto, dependiendo de
qu interese ms en cada instante de tiempo.
La arquitectura es el conjunto de decisiones significativas sobre:
La organizacin del sistema
Seleccin de elementos estructurales y sus interfaces a travs de los cuales se
constituye el sistema.

El Comportamiento, como se especifica las colaboraciones entre esos componentes.

Composicin de los elementos estructurales y de comportamiento en subsistemas

progresivamente ms grandes.
El estilo arquitectnico que gua esta organizacin: elementos estticos y dinmicos y
sus interfaces, sus colaboraciones y su composicin.
La una arquitectura que no debe centrarse nicamente en la estructura y en el comportamiento,
sino que abarque temas como el uso, funcionalidad, rendimiento, capacidad de adaptacin,
reutilizacin, capacidad para ser comprendida, restricciones, compromisos entre alternativas,
as como aspectos estticos. Para ello se sugiere una arquitectura que permita describir mejor
los sistemas desde diferentes vistas, donde cada una de ellas es una proyeccin de la
organizacin y la estructura centrada en un aspecto particular del sistema.
La vista de casos de uso comprende la descripcin del comportamiento del sistema tal y como
es percibido por los usuarios finales, analistas y encargados de las pruebas y se utilizan los

diagramas de casos de uso para capturar los aspectos estticos mientras que los dinmicos
son representados por diagramas de interaccin, estados y actividades.
La vista de diseo comprende las clases, interfaces y colaboraciones que forman el vocabulario
del problema y de la solucin. Esta vista soporta principalmente los requisitos funcionales del
sistema, o sea, los servicios que el sistema debe proporcionar. Los aspectos estticos se
representan mediante diagramas de clases y objetos y los aspectos dinmicos con diagramas
de interaccin, estados y actividades.
La vista de procesos comprende los hilos y procesos que forman mecanismos de
sincronizacin y concurrencia del sistema cubriendo el funcionamiento, capacidad de
crecimiento y el rendimiento del sistema. Con UML, los aspectos estticos y dinmicos se
representan igual que en la vista de diseo, pero con el nfasis que aportan las clases activas,
las cuales representan los procesos y los hilos.
La Vista de implementacin comprende los componentes y los archivos que un sistema utiliza
para ensamblar y hacer disponible el sistema fsico. Se ocupa principalmente de la gestin de
configuraciones de las distintas versiones del sistema. Los aspectos estticos se capturan con
los diagramas de componentes y los aspectos dinmicos con los diagramas de interaccin,
estados y actividades.
La vista
de
despliegue de
un
sistema
contiene
los
nodos
que
forman
la topologa hardware sobre la que se ejecuta el sistema. Se preocupa principalmente de
la distribucin, entrega e instalacin de las partes que constituyen el sistema. Los aspectos
estticos de esta vista se representan mediante los diagramas de despliegue y los aspectos
dinmicos con diagramas de interaccin, estados y actividades
Ciclo de Vida
Se entiende por ciclo de vida de un proyecto software a todas las etapas por las que pasa un
proyecto, desde la concepcin de la idea que hace surgir la necesidad de disear un sistema
software, pasando por el anlisis, desarrollo, implantacin y mantenimiento del mismo y hasta
que finalmente muere por ser sustituido por otro sistema.
Aunque UML es bastante independiente del proceso, para obtener el mximo rendimiento de
UML se debera considerar un proceso que fuese:
Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto bsico para
establecer el comportamiento del deseado del sistema, para validar la arquitectura, para las
pruebas y para la comunicacin entre las personas involucradas en el proyecto.
Centrado en la arquitectura de modo que sea el artefacto bsico para conceptuar, construir,
gestionar y hacer evolucionar el sistema.
Un proceso iterativo, que es aquel que involucra la gestin del flujo de ejecutables del
sistema, e incremental, que es aquel donde cada nueva versin corrige defectos de la anterior
e incorpora nueva funcionalidad. Un proceso iterativo e incremental se denomina dirigido por el
riesgo, lo que significa que cada nueva versin se ataca y reducen los riesgos ms
significativos para el xito del proyecto.
Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo e incremental
pude descomponerse en fases, donde cada fase es el intervalo de tiempo entre dos hitos
importantes del proceso, cuando se cumplen los objetivos bien definidos, se completan los
artefactos y se toman decisiones sobre si pasar o no a la siguiente fase.
En el ciclo de vida de un proyecto software existen cuatro fases. La iniciacin, que es cuando
la idea inicial est lo suficientemente fundada para poder garantizar la entrada en la fase
de elaboracin, esta fase es cuando se produce la definicin de la arquitectura y la visin
del producto. En esta fase se deben determinar los requisitos del sistema y las pruebas sobre
el mismo.
Posteriormente se pasa a la fase de construccin, que es cuando se pasa de la base
arquitectnica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan
los requisitos y las pruebas que ha de soportar. La transicin, cuarta fase del proceso, que es

cuando el software se pone en mano de los usuarios. Raramente el proceso del software
termina en la etapa de transicin, incluso durante esta fase el proyecto es continuamente
reexaminado y mejorado erradicando errores y aadiendo nuevas funcionalidades no
contempladas.
Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteracin, que es
un conjunto bien definido de actividades, con un plan y unos criterios de evaluacin, que
acaban en una versin del producto, bien interna o externa.
Caso Prctico
Requerimientos
No
Consultas / Informes
R01
R02
R03
No
Almacenamiento
R04

R05
R06
R07

R08
R09
R10
R11
R12
R13

No
No
Procesamiento

R14
Diagramas de Casos de Uso

Ejemplo