Ciclos Vida SW PDF

C
o
n
f
i
d
e
n
c
i
a
l

Ciclos de Vida de Software

Versin 1.0
05/02/09

C
o
n
f
i
d
e
n
c
i
a
l
CITIS
Ciclos de Vida de Software v. 1.0

05/02/09

2/32

Control De Versiones

Nombre del Archivo Versin Fecha Autor Comentarios
Ciclos de Vida 0.1 23/01/2005 JC Versin Inicial
del Documento
Ciclos de Vida 0.2 24/03/2005 CT Correcciones al
documento
GM_06_Asgnto_Calidad 0.3 09/04/2005 CT Comentarios
corregidos
GM_06_Asgnto_Calidad 1.0 01/06/2005 CT Versin Final

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

3/32

ndice del documento
1 Introduccin .............................................................................................. 5
1.1 PROPSITO................................................................................................. 5
1.2 OBJETIVO ................................................................................................... 5
1.3 VISIN GENERAL.......................................................................................... 5
1.4 ALCANCE.................................................................................................... 6
1.5 ACRNIMOS................................................................................................ 6
1.6 REFERENCIAS ............................................................................................. 6
1.7 DEFINICIONES ............................................................................................. 7
2 Descripcin de los ciclos de vida ............................................................. 7
2.1 DEFINICIN DE CICLO DE VIDA...................................................................... 7
2.2 ELEMENTOS DEL CICLO DE VIDA ................................................................... 8
3 Definicin de Modelo del Ciclo de Vida................................................... 10
3.1 DIFERENCIAS ENTRE LOS DISTINTOS MODELOS DE CICLO DE VIDA ................ 10
3.2 MODELO DE CASCADA ............................................................................... 11
3.2.1 Estructura en Secuencia de las Etapas del Modelo de Cascada..... 11
3.2.1 Explicacin de las Etapas del Modelo de Cascada.......................... 12
3.2.2 Principales Caractersticas del Modelo de Cascada. ....................... 13
3.2.3 Documentos Generados por el Modelo de Cascada. ...................... 13
3.2.4 Problemas del Modelo de Cascada. ................................................ 14
3.2.5 Consideraciones del Ciclo de Vida de Cascada .............................. 14
3.3 MODELO EVOLUTIVO.................................................................................. 15
3.3.1 Consideraciones del Ciclo de Vida Evolutivo................................... 17
3.4 MODELO DE DESARROLLO INCREMENTAL .................................................... 17
3.4.1 Beneficios del Modelo Incremental .................................................. 17
3.4.2 Consideraciones del Ciclo de Vida Incremental............................... 18
3.5 MODELO DE PROTOTIPO ............................................................................ 18
3.5.1 Consideraciones del Modelo de Prototipo ....................................... 19
3.6 MODELO EN ESPIRAL ................................................................................. 19
3.6.1 Fundamentos del Modelo en Espiral................................................ 20
3.6.2 Ventajas del Modelo en Espiral........................................................ 21
3.6.3 Limitaciones del Modelo en Espiral.................................................. 21
3.6.4 Consideraciones del Ciclo de Vida en Espiral ................................. 22
3.7 MODELO RAD (RAPID APPLICATION DEVELOPMENT).................................... 23
3.7.1 Aspectos importantes del Modelo RAD ........................................... 23
3.7.2 Fases del Modelo RAD. ................................................................... 23
3.7.3 Ventajas del Modelo RAD................................................................ 25
3.7.4 Limitaciones del Modelo RAD.......................................................... 25
3.7.5 Consideraciones del RAD................................................................ 25
3.8 MODELO EN V......................................................................................... 25
3.8.1 Consideraciones del ciclo de vida en V ......................................... 27
3.9 MODELO DE TRANSFORMACIN .................................................................. 27
3.9.1 Consideraciones del ciclo de vida de transformacin ...................... 29
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

4/32

3.10 USO DE PROTOTIPOS................................................................................. 29
3.11 PROCESO DE PROTOTIPOS......................................................................... 30
3.11.1 Tipos de Prototipos.......................................................................... 30
3.11.2 Tcnicas de Prototipado .................................................................. 31
3.11.3 Posibles Problemas ......................................................................... 31

ndice de imgenes
Figura 2-1 Elementos del Ciclo de Vida .................................................................. 8
Figura 2-2 Esquema general de una fase ............................................................... 9
Figura 2-3 Descomposicin de una fase................................................................. 9
Figura 3-1 Modelo de Cascada ............................................................................. 11
Figura 3-2 Modelo Evolutivo.................................................................................. 16
Figura 3-3 Desarrollo en Cascada Incremental ..................................................... 18
Figura 3-4 Modelo de Prototipo............................................................................. 19
Figura 3-5 Modelo en Espiral ................................................................................ 21
Figura 3-6 Modelo RAD......................................................................................... 24
Figura 3-7 Modelo en V ...................................................................................... 26
Figura 3-8 Modelo de Transformacin ................................................................. 28
Figura 3-9 Proceso Prototipado............................................................................. 30
Figura 3-10 Prototipo de Anlisis .......................................................................... 30

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

5/32

1 Introduccin
Este documento es una gua para seleccionar el ciclo de vida ms adecuado que
se adoptar en el desarrollo de un proyecto de software.

La eleccin del ciclo de vida es posiblemente una de las actividades ms
importantes que se efectan al iniciar el proyecto, debido a que se debe adoptar
desde las fases iniciales del mismo.

El desarrollo de un producto de software con ciertas caractersticas de calidad,
costo y complejidad representa un reto a nivel intelectual tanto para la
organizacin en la que se desarrolla como para cada una de las personas que
intervienen en su desarrollo.

La atencin de la ingeniera de software se centra en los procesos del producto a
desarrollar, porque en ellos deben incorporarse los requerimientos que el usuario
desea y de ello depende el resultado final, de estos procesos de desarrollo
depende que los requerimientos sean realmente satisfechos en el producto final
con las condiciones de tiempo y costo negociadas con el cliente.
1.1 Propsito
Ofrecer una gua que permita construir el ciclo de vida ms adecuado para el
desarrollo del proyecto software. Guiar en este proceso permitir establecer las
fases por las cuales se deber pasar, de acuerdo a las caractersticas y
consideraciones especiales del proyecto. Adicionalmente el ciclo de vida del
proyecto ser la base para determinar los procesos de software que se utilizarn
dentro del proyecto.
1.2 Objetivo
Facilitar la seleccin del ciclo de vida a emplear de acuerdo a las caractersticas
del proyecto, para poder optimizar los recursos de desarrollo y cumplir con los
requisitos de tiempo, costo y calidad de los proyectos de desarrollo de software
dentro de la Universidad Popular Autnoma del Estado de Puebla.
1.3 Visin general
El ciclo de vida debe cumplir con las siguientes caractersticas:
Ser el adecuado para los recursos tanto humanos como materiales con los
que se cuenta.
Permitir cumplir con los compromisos de tiempo, costo y calidad
establecidos entre la universidad y el cliente.
Garantizar la calidad de los componentes que se produzcan.
Que los participantes en el proyecto entiendan ampliamente el ciclo de vida
a emplear.

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

6/32

La construccin del ciclo de vida debe hacerse a partir de entender las
necesidades del cliente y el diseo conceptual, durante la fase de planeacin y
considerar las restricciones del proyecto.
1.4 Alcance
El proceso descrito en este documento aplica para todos los proyectos generados
en la licenciatura en Sistemas Computacionales Plan 04 y la Licenciatura en
Ingeniera en Computacin Plan 03 dentro de la UPAEP.

Esta gua se limita a describir las actividades necesarias para establecer el ciclo
de vida a emplear para un proyecto de desarrollo de software.
Este documento est orientado a aquellos alumnos que participen en el desarrollo
de un producto de software, principalmente en sus fases iniciales.
1.5 Acrnimos
Acrnimo Descripcin
DLD Detailed Level Design
HLD High Level Design
IT Integration Test
SRS Software Requirements Specification
ST System Test
TSP Team Software Process
ESA European Space Agency

1.6 Referencias
Nm. Descripcin
1 Watts S. Humphrey, Team Software Process, CMU/SEI-2000-TR-023
http://www.sei.cmu.edu/publications/documents/00.reports/00tr023.html
2 Booch, Grady, Anlisis y Diseo Orientado a Objetos con Aplicaciones,
Segunda Edicin, Editorial, Wesley Logman
3 Sommerville, Ian, Software Engineering (6th Edition), Addison Wesley
4 Boehm, Barry, Software Engineering Economics, Prentice Hall
5 Universidad de Valladolid, Departamento de Informtica, Curso de Ingeniera
de Software, Apuntes, Manuel Barrio Solrzano, 2003
http://www.infor.uva.es/~mbarrio/ISO1/Teoria/modelosCicloVida.htm
6 Watts S. Humphrey, A Discipline for Software Engineering, Addison Wesley,
2000
7 Boehm, Barry, A Spiral Model of Software Development and Enhancement,
IEEE 1988
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

7/32

8 QuarkSoft
, Quarksoft Standard Software Development Process, Mxico D.F.

2003
9 Dynamic Systems Development, Version 3, DSDM Consortium, Tesseract
Publishing, www.dsdm.org

1.7 Definiciones

Palabra Definicin
Ciclo de Vida Secuencia de fases (conjunto de actividades) en cada una de
las cuales se establece un control para pasar de una fase a
otra y obtener as resultados en cada una de estas, y que
permitan el desarrollo de un producto desde su concepcin,
entrega al usuario, y evolucin posterior.
Fase Conjunto de actividades relacionadas con un objetivo en el
desarrollo del proyecto
Modelo de Ciclo de
Vida de Software
Describe las fases principales del desarrollo y permite un
desglose de las mismas segn el grado de detalle que se
requiera, adems de ayudar a administrar el progreso del
desarrollo y proveer de un marco de trabajo para el
proyecto.
Diagrama
Contextual
Representa el entorno del trabajo y del producto.
Diseo Conceptual Representacin grfica de los componentes o mdulos que
formarn el producto de software con el objetivo de facilitar el
proceso de estimacin

2 Descripcin de los ciclos de vida
2.1 Definicin de Ciclo de Vida
El ciclo de vida de un producto de software se entiende como una secuencia de
fases, es decir actividades en las cuales se establece un control para pasar de una
fase a otra y as obtener resultados en cada una de ellas, esto con la finalidad de
que permitan el desarrollo de un producto desde su concepcin, entrega al
usuario, hasta su evolucin posterior.
El desarrollo de un modelo de ciclo de vida surgi a partir de los aos setenta,
gracias a la experiencia adquirida en el desarrollo de software y al identificar un
conjunto de actividades comunes en todos los proyectos.
Actualmente, a las fases de desarrollo del modelo de ciclo de vida se le conoce
como proceso de desarrollo software.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

8/32

Dentro del desarrollo de software no existe un modelo de ciclo de vida nico, el
modelado de un ciclo de vida cambia dependiendo de mltiples factores que
puedan no estar controlados por el ingeniero de software.
2.2 Elementos del Ciclo de Vida
Un ciclo de vida se compone de fases sucesivas, a su vez estas fases estn
compuestas por tareas planeadas. Segn el modelo de ciclo de vida, la sucesin
de fases puede ampliarse y retroalimentarse, de modo que una misma fase se
puede ejecutar ms de una vez a lo largo de un proyecto, recibiendo en repetidas
ocasiones, aportaciones de resultados que se van produciendo en alguna etapa
intermedia. En la Figura 2-1 se pueden apreciar los elementos de un ciclo de vida.

Figura 2-1 Elementos del Ciclo de Vida

Fuente: Watts S. Humphrey 2000

Una fase es un conjunto de actividades relacionadas con un objetivo en el
desarrollo del proyecto. Se construye agrupando tareas que pueden compartir un
tiempo determinado dentro del ciclo de vida. La agrupacin temporal de tareas
sugiere una asignacin de recursos humanos, financieros o materiales.
Cada fase est definida por un conjunto de elementos externos como:
Actividades con las que se relaciona.
Datos de entrada que pueden ser resultados de la fase anterior.
Documentos o productos requeridos para la fase.
Datos de salida que son productos obtenidos en esta fase y que pueden ser
utilizados para la fase posterior.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

9/32

Experiencia adquirida en proyectos anteriores.
Pruebas o resultados efectuados y
La estructura interna de la fase.
En la Figura 2-2 se puede apreciar el esquema general de una fase.

Figura 2-2 Esquema General de una Fase
Tareas propias
de la fase
Re-planificacin y/o
Retroalimentacin
Procedente de la
fase anterior
A la fase posterior
Documentos
y productos
de entrada
Documentos
y productos
de salida
Validacin del Trabajo
Experiencia
adquirida


Si analizamos un proyecto, y este resulta muy grande y complejo, se necesitar
mayor detalle en la definicin de sus fases para que el contenido de cada una de
ellas, siga siendo manejable y pueda ser llevada a cabo dentro de los lmites de
tiempo establecidos. De esta forma, cada fase en particular, puede considerarse
un sub-proyecto, compuesto a su vez por un conjunto de sub-fases y sub-tareas.
En la Figura 2-3 se puede apreciar la descomposicin de una fase.

Figura 2-3 Descomposicin de una Fase

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

10/32

Sub-contratado


Otra manera de descomponer una fase en sub-fases, puede ser separando alguna
parte del proyecto para que otra empresa u organizacin, se haga cargo de ella.
Esto implica distintos procesos de administracin.

3 Definicin de Modelo del Ciclo de Vida
Un Modelo de Ciclo de Vida de Software describe las fases principales del
desarrollo y permite un desglose de las mismas segn el grado de detalle que se
requiera, adems de ayudar a administrar el progreso del desarrollo y proveer de
un marco de trabajo para el proyecto.

Dentro de los diferentes tipos de ciclos de vida podemos encontrar:
Modelo en Cascada
Modelos Evolutivos
Modelo Incremental
Modelo en Espiral
Modelo RAD
Modelo en V
Modelo de Transformacin

3.1 Diferencias entre los Distintos Modelos de Ciclo de Vida
Las diferencias ms significativas entre distintos modelos de ciclo de vida son:
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

11/32

El alcance del ciclo depende de hasta dnde llegue el proyecto
correspondiente. Es decir un proyecto puede comprender un simple estudio
de viabilidad del desarrollo de un producto, o toda la historia del producto
con su desarrollo completo, fabricacin y modificaciones posteriores hasta
su salida al mercado.
El contenido de las fases en que se divide el ciclo. Esto puede depender del
propio tema al que se refiere el proyecto (no son las mismas tareas las que
deben realizar para proyectar un automvil que un puente), o de la
organizacin (inters de reflejar en la divisin en fases aspectos de la
divisin interna o externa del trabajo).
La estructura de la sucesin de las fases. Estas pueden caer en las formas
lineal, espiral o por prototipos.

3.2 Modelo de Cascada
Cuando nace la Ingeniera de Software propiamente como un rea, se define el
proceso de software para grupos de desarrollo conocido como proceso o ciclo de
vida en cascada. Este proceso se divide en fases claramente especificadas, que
pueden variar dependiendo de los autores consultados, pero conservan siempre la
misma idea, de que no puede empezar una fase hasta que no se termine la
anterior.
Es tambin llamado Modelo Clsico, es el paradigma ms antiguo y ms utilizado
en la Ingeniera del Software. Sugiere un enfoque sistemtico y secuencial del
desarrollo del software que comienza en un nivel de sistemas y progresa con el
anlisis, diseo, codificacin, pruebas y mantenimiento hasta la liberacin del
sistema.
3.2.1 Estructura en Secuencia de las Etapas del Modelo de Cascada.
En la Figura 3-1 se puede apreciar el Modelo de Cascada.

Figura 3-1 Modelo de Cascada

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

12/32

Modelo Cascada
Anlisis de
requisitos
Especificacin de
requisitos
Diseo preliminar
Diseo detallado
Programacin y
pruebas
Explotacin y
mantenimiento
UPAEP
Departamento de TI
Proyecto Id-MPH CITIS
Primavera 05


3.2.1 Explicacin de las Etapas del Modelo de Cascada.
Anlisis de Requerimientos: Son los elementos que se van a necesitar para
el desarrollo de Software.
Especificacin de Requerimientos: Descripcin detallada del procesamiento
de informacin, funciones, rendimientos, interfaces y restricciones que se
van a necesitar para el desarrollo.
Diseo: Contempla una fase de alto nivel y una de diseo detallado. Es la
traduccin de los requerimientos o requisitos, a un algoritmo o a un
lenguaje ms tcnico.
Codificacin: Utilizar un lenguaje de programacin para transcribir el diseo.
Pruebas de Integracin del Sistema: Se refiere a ensamblar todas las
partes del software progresivamente para verificar su correcto
funcionamiento en conjunto.
Operacin y mantenimiento: Esto se realiza con la finalidad de corregir
errores, realizar adaptacin por evolucin del entorno y reforzar o hacer
pequeas modificaciones.

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

13/32

3.2.2 Principales Caractersticas del Modelo de Cascada.
La ventaja de este modelo, es que ya se tiene cierta disciplina en el desarrollo de
sistemas; se introducen la planeacin y administracin, pues las fases se deben
planear en tiempo y recursos (humanos y fsicos) y se deben administrar, es decir,
alguien vigila que el grupo de desarrollo realmente se ajuste a lo que se ha
planeado y est cumpliendo con este proceso de desarrollo.
En este modelo, la fase de Codificacin se pospone hasta que se entienda bien el
objetivo del proyecto (los requerimientos) y hasta que se haga el diseo de todo el
sistema. Esto es una ventaja pues se evita construir productos que finalmente no
cumplirn en su totalidad con lo que el usuario requiere. La desventaja de este
modelo es que es lineal, rgido y monoltico, por lo tanto irrealista, pues la gente
difcilmente se espera para realizar sus propias actividades o a que terminen sus
compaeros de fases anteriores. Podemos ver aqu el antipatrn "anlisis -
parlisis": la persona que hace el anlisis no es capaz de decir que ya entendi el
problema, que ya tiene todos los requerimientos porque siempre le parece que
falta algo, dando como consecuencia el retardo en la entrega de los documentos
de anlisis a los grupos responsables de las siguientes partes. Difcilmente en la
realidad se puede organizar el trabajo en esta forma tan rgida.
Adems este modelo presenta dificultad para introducir modificaciones, sobre todo
en la fase de Mantenimiento, porque para realizarlo habra que volver a empezar
todo el ciclo, modificando la informacin de cada fase, para tener as una
especificacin y documentacin consistente con el mantenimiento realizado.
Esto ltimo es importante puesto que dentro del Mantenimiento se tiene que el
20% es correctivo (se corrigen los errores del sistema original), otro 20% es
adaptativo (adaptacin sin cambios esenciales en las funciones originales) y el
60% est dirigido al perfeccionamiento del sistema (se ampla el sistema con
nuevos requerimientos del usuario). De no documentar debidamente cada
mantenimiento, se corre el riesgo (que de hecho actualmente existe en gran
medida) de tener sistemas que no cuentan con su documentacin actualizada.
Este modelo est enfocado a la produccin de documentos. Cada fase tiene que
entregar un producto (documento o software) bien documentado, para que otros
grupos puedan trabajar con ellos. El modelo en cascada ha sido adoptado por
diversas entidades como base para el proceso de contratacin y para la
aceptacin del software entregado.
3.2.3 Documentos Generados por el Modelo de Cascada.
1. Documento de Viabilidad: Esto es un estudio que se hace para ver que tan
aplicable es el proyecto en el mundo real.
2. Documento de Requerimientos: Es la base para el ciclo de vida, de este se
obtienen los datos para la etapa de desarrollo.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

14/32

3. Especificacin Funcional: Documento que va ms a detalle en cuanto a
requerimientos.
4. Plan de Pruebas: Este documento sirve de gua en la etapa de pruebas.
5. Especificacin de Interfaz: Provee al desarrollador de una visin ms
especfica.
6. Especificacin de Diseo: Suministra un diseo a detalle de lo que se
requiere.
7. Resultado de Pruebas: Los resultados obtenidos a partir de las pruebas son
recopilados.
8. Sistema Final: La documentacin de todo el proyecto terminado.
3.2.4 Problemas del Modelo de Cascada.
No es aplicable a productos de software altamente iterativos, aunque el
modelo puede acoplar iteracin y lo hace indirectamente.
Los requerimientos obtenidos no pueden ser cambiados durante el proceso.
Es difcil tener todos los requerimientos bien definidos al principio, como lo
requiere el modelo y adems presenta dificultades para acomodar posibles
incertidumbres existentes al comienzo de los proyectos.
Los productos de software raramente siguen el flujo secuencial que
propone el modelo. Siempre hay iteraciones y se crean problemas en la
aplicacin del paradigma.
Un error importante no detectado al principio puede ser desastroso, no slo
al final del proyecto sino durante todo el proceso.
Se requiere mucha paciencia por parte del cliente, porque solo hasta las
etapas finales del desarrollo podr tener una versin operativa del producto.
Los responsables del desarrollo del software siempre se retrasan
innecesariamente. La naturaleza lineal lleva a estados de bloqueo, en el
que algunos miembros del equipo deben esperar a otros miembros para
completar tareas pendientes, lo que aumenta el tiempo invertido en el
proyecto.
No refleja realmente el proceso de desarrollo del software.
El tiempo invertido en pasar a travs de todo el ciclo es demasiado.
El mantenimiento generalmente se realiza en el cdigo fuente.
Las revisiones de proyectos de gran complejidad son muy difciles.
Es inflexible y se dificulta el proceso de estimacin del proyecto completo.

3.2.5 Consideraciones del Ciclo de Vida de Cascada
En el ciclo de vida de cascada los autores difieren en cuanto al nmero de fases y
esto queda sujeto a las caractersticas propias del proyecto y al criterio del
ingeniero de software.
El ciclo de vida de cascada debe ser usado tomando en cuenta las siguientes
consideraciones:
Aunque las metodologas PSP / TSP se basan principalmente en el ciclo de
vida de cascada, tambin soportan otros modelos, como el desarrollo
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

15/32

cclico y el incremental. Considera que se pueden hacer adecuaciones al
PSP / TSP para cubrir necesidades especficas del proyecto.
Es muy fcil de implementar.
Se recomienda utilizar para sistemas donde los requerimientos tienen cierto
grado de estabilidad.
Se recomienda usar en proyectos de software que no son de
mantenimiento o versiones subsecuentes de proyectos anteriores.
Se puede utilizar si el sistema no requiere iteraciones para su desarrollo.
3.3 Modelo Evolutivo
El modelo Evolutivo conocido tambin como incremental e iterativo, consiste en
hacer la documentacin de las fases, realizando un prototipo del sistema, se
evala el qu tan lejos el prototipo est de la solucin final esperada por el cliente;
se toman en cuenta las observaciones de esta evaluacin, y se crea un nuevo
prototipo que las incluya. Esto se realiza en una vuelta repetitiva donde se
incrementa el alcance del prototipo en pequeas proporciones hasta cumplir los
requerimientos totales.
Este modelo es muy parecido al modelo incremental por su forma de desarrollo,
construye una serie de grandes versiones sucesivas de un producto; por lo que,
mientras que la aproximacin incremental presupone que el conjunto completo de
requerimientos es conocido al inicio del sistema, el modelo evolutivo asume que
los requerimientos no son completamente conocidos al inicio del proyecto o son
variables.
En este modelo los requerimientos son cuidadosamente estudiados y examinados,
y slo aquellos que son bien comprendidos son seleccionados para el primer
incremento. Los desarrolladores del sistema crean una implementacin parcial del
sistema que recibe slo estos requerimientos.
Despus de lo anterior, el modelo es entonces desarrollado e implementado, es
decir, se construye un prototipo el cual se entrega a los usuarios que a su vez lo
utilizan, y proveen retroalimentacin a los desarrolladores del sistema. Una vez
hecha esta retroalimentacin, la especificacin de los requerimientos es
actualizada, y una segunda versin del producto es desarrollada e implementada.
El proceso se repite de manera secuencial y sin lmite para mejorar lo ya realizado
y actualizado.

El modelo de ciclo de vida de tipo evolutivo del software cubre los siguientes
puntos:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas a ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo.
Provee un entorno de trabajo para la definicin de un proceso detallado de
desarrollo de software.

El modelo Evolutivo como se puede apreciar en la Figura 3-2, es muy afn al
modelo de Cascada en cuanto a su desarrollo y funcionalidad. El desarrollo
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

16/32

evolutivo no exige una forma especfica de observar el desarrollo de algn
incremento. De este modo el modelo cascada puede ser usado para administrar
cada esfuerzo de desarrollo realizado. Por lo consiguiente queda claro que el
desarrollo incremental y evolutivo pueden ser combinados tambin para mejorar
todo el proceso del sistema.
Los pasos que se deben de seguir son:
Construir un subconjunto de requerimientos conocidos (incremental) y
Comprender al principio que muchos nuevos requerimientos es probable
que aparezcan cuando el sistema sea desplegado o desarrollado.

Para desarrollar el software de la forma evolutiva se requiere un especial cuidado
en la manipulacin y seleccin de documentos, programas, datos de prueba, etc.
desarrollados para distintas versiones del software. Todos los pasos deben de ser
registrados, la documentacin debe ser recuperada con facilidad, los cambios
deben ser efectuados de una manera controlada y con un orden establecido para
su consulta y estudio.

Figura 3-2 Modelo Evolutivo

Requerimientos 1a Iteracin
Diseo
Codificacin y
Pruebas Unitarias
Integracin del
Sistema
Operacin y
Mantenimiento
Requerimientos 2a Iteracin
Diseo
Codificacin y
Pruebas Unitarias
Integracin del
Sistema
Operacin y
Mantenimiento
Requerimientos Iteracin n
Diseo
Codificacin y
Pruebas Unitarias
Integracin del
Sistema
Operacin y
Mantenimiento


El prototipo evolutivo es un sistema a disposicin de los usuarios finales. El
proceso comienza con unos requerimientos claros. Debe usarse en sistemas en
los que no es posible, inicialmente, desarrollar la especificacin, como es el caso
de los sistemas que requieran implementar Inteligencia Artificial y la Interfaz de
usuario.
Se puede decir que este modelo se basa en tcnicas que permiten obtener de
forma rpida versiones del sistema. No permite la verificacin pues no hay
especificaciones y la validacin demuestra la adecuacin del sistema.

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

17/32

3.3.1 Consideraciones del Ciclo de Vida Evolutivo
Tomando como base los requerimientos, permite la construccin de incrementos
de desarrollo a travs de prototipos funcionales de la aplicacin, se recomienda
usar este modelo cuando:
Se requieren versiones sucesivas del producto.
Los requerimientos no son ampliamente conocidos al inicio del desarrollo
del sistema o son variables.
Los requerimientos que son conocidos deben ser muy claros.
Se cuenta con disponibilidad de los usuarios para verificar los prototipos.
Es necesario crear una arquitectura de software muy flexible y de fcil
mantenimiento ya que el desconocer todos los requerimientos al inicio
puede involucrar cambios significativos en la arquitectura por
requerimientos futuros.
Debido a que el modelo evolutivo es muy afn al modelo de cascada, su
adaptacin a las herramientas, mtodos, scripts y plantillas de PSP no ser
complicada.
Por ltimo considera que en el contexto de la organizacin, en la mayora
de los proyectos es necesario estimar y cotizar el total del proyecto al inicio.
Al utilizar el modelo evolutivo ser necesario hacer los acuerdos necesarios
con el cliente para permitir este esquema. Adicionalmente ser necesario
determinar claramente el alcance y hasta que incremento se terminar el
proyecto.

3.4 Modelo de Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son
enormes. Una forma de reducir los riesgos es construir slo una parte del sistema,
reservando otros aspectos para niveles posteriores. El desarrollo incremental es el
proceso de construccin que va siempre incrementando subconjuntos de
requerimientos del sistema. Tpicamente, un documento de requerimientos es
escrito al capturar todos los requerimientos para el sistema completo.
El desarrollo incremental es 100% compatible con el modelo cascada. El
desarrollo incremental no demanda una forma especfica de observar el desarrollo
de algn otro incremento. As, el modelo cascada puede ser usado para
administrar cada esfuerzo de desarrollo.
3.4.1 Beneficios del Modelo Incremental
Construir un sistema pequeo es siempre menos riesgoso que construir un
sistema grande. Al ir desarrollando parte de las funcionalidades, es ms
fcil determinar si los requerimientos planeados para los niveles
subsiguientes son correctos.
Se evitan proyectos largos y se entrega Algo de valor a los usuarios con
cierta frecuencia.
Se involucra el usuario.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

18/32

Si un error importante es realizado, slo la ltima iteracin necesita ser
descartada y el incremento previo puede ser usado.
Al reducir el tiempo de desarrollo de un sistema, decrecen las
probabilidades que esos requerimientos de usuarios puedan cambiar
durante el desarrollo.
Los errores de desarrollo realizados en un incremento, pueden ser
arreglados antes del comienzo del prximo incremento.

En la Figura 3-3 se puede apreciar el Modelo Incremental.

Figura 3-3 Desarrollo en Cascada Incremental


3.4.2 Consideraciones del Ciclo de Vida Incremental
El modelo de ciclo de vida incremental debe implementarse cuando:
Todos los requerimientos del sistema son conocidos al inicio.
El desarrollo del sistema es muy complejo y se pueden tomar segmentos de
requerimientos o clasificarlos por mdulos para construir un incremento.
Existe un alto grado de derivacin de los requerimientos (dependencia).
La metodologa PSP, soporta completamente el desarrollo incremental y
cclico (PSP3) por lo que su adaptacin a las herramientas, mtodos,
scripts y plantillas de PSP no representa un problema.

3.5 Modelo de Prototipo
Consiste en iterar en la fase de anlisis tantas veces como sea necesario,
mostrando prototipos al usuario para que pueda indicarnos de forma mas eficiente
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

19/32

los requisitos del sistema. La iteracin finalizar cuando el usuario de el visto
bueno al prototipo. En la Figura 3-4 se puede apreciar el modelo en prototipos.

Figura 3-4 Modelo de Prototipo


3.5.1 Consideraciones del Modelo de Prototipo
No modifica el flujo del ciclo de vida.
Reduce el riesgo de construir productos que no satisfagan las necesidades
de los usuarios.
Reduce costos y aumenta la probabilidad de xito.
Exige disponer de las herramientas adecuadas.
No presenta calidad ni robustez.
Una vez identificados todos los requisitos mediante el prototipo, se
construye el producto de ingeniera.

3.6 Modelo en Espiral
El modelo en espiral es una alternativa propuesta por Boehm [7] en 1986. l
sugiri un modelo que reconociera explcitamente riesgos y que podra formar la
base de un modelo genrico de procesos.
Es un modelo evolutivo que acompaa la naturaleza interactiva de construccin de
prototipos con los aspectos controlados y sistemticos del modelo lineal
secuencial, el software que se desarrolla en este modelo arroja una serie de
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

20/32

versiones incrementales representadas por una curva en el modelo, de ah el
nombre de espiral.
Cada giro de la espiral representa una fase del proceso de software, tal como fue
definido por la direccin del proyecto, donde el centro del modelo concierne a la
factibilidad del sistema. El siguiente giro corresponde a la definicin de los
requerimientos, el siguiente al diseo del sistema y as sucesivamente aunque
cabe mencionar que no existen fases fijas en el modelo. La direccin del proyecto
debe decidir como estructurarlo en fases y la organizacin debera trabajar sobre
un modelo ya sea con fases genricas, con fases extra o con fases agregadas
para proyectos especficos, principalmente cuando se identifiquen problemas
durante el desarrollo.
Cada paso de una fase a otra produce reajustes en el plan del proyecto, debido a
que cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el
plan para el siguiente. El costo y la planeacin se ajustan segn la evaluacin del
cliente.

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de
software a gran escala, como el software evoluciona a medida que avanza el
proceso, los desarrolladores y los usuarios comprenden y reaccionan mejor ante
riesgos en cada uno de los niveles evolutivos.
El modelo en espiral no siempre es bien definido o comprendido, para algunos
representa cualquier esquema de desarrollo con una recurrente actividad de
planeacin, mientras otros agregan las restricciones.

3.6.1 Fundamentos del Modelo en Espiral
En la propuesta de Barry Boehm, la espiral representa muy bien la idea del
desarrollo iterativo e incremental, as como la del desarrollo por prototipos, en
donde estos al principio abarcan una pequea parte del sistema, (la evaluacin de
riesgos) y empiezan en el centro de la espiral.
Boehm ha definido que existe un conjunto de seis fundamentos que denomina
invariantes en cuanto a que deben necesariamente aparecer en todo proyecto
que utilice este tipo de desarrollo.
1. Determinacin concurrente de los aspectos clave (operaciones, conceptos,
requerimientos, planes, diseo y cdigo).
2. Cada ciclo tiene: objetivos, restricciones, alternativas, riesgos, revisiones y
compromisos para proceder.
3. El nivel de esfuerzo se dirige de acuerdo a las consideraciones de riesgo.
4. El grado de detalle se dirige de acuerdo a las consideraciones de riesgo.
5. Los resultados a producirse durante el proceso en espiral se constituyen en
puntos de anclaje:
Objetivos del Ciclo de Vida
Arquitectura del Ciclo de Vida
Capacidad Operativa Inicial
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

21/32

6. El nfasis se pone sobre las actividades del ciclo de vida, el sistema y los
productos o resultados.

Algunos otros analistas como Kitaoka, han coincidido en que un proyecto en
espiral tendr los siguientes rasgos de ciclo de vida:
Los requerimientos no estn predefinidos.
Existen mltiples ciclos de desarrollo internos.
Pueden existir mltiples entregas a los clientes.
Los requerimientos constituyen el manejo primario del contenido funcional.
La reduccin del riesgo es el conductor primario del proceso.

3.6.2 Ventajas del Modelo en Espiral
El modelo en espiral utiliza la construccin de prototipos como un
mecanismo de reduccin de riesgos pero, lo que es ms importante,
permite a quien lo desarrolla aplicar el enfoque de construccin de
prototipos en cualquier etapa de evolucin del producto.
Mantiene el enfoque sistemtico de los pasos sugeridos por el ciclo de vida
clsico, pero lo incorpora a un marco de trabajo interactivo que refleja casi a
la perfeccin el mundo real.
Existe un reconocimiento de las diferentes alternativas para alcanzar los
objetivos de un proyecto.
Si se aplica adecuadamente debe reducir los riesgos antes de que se
conviertan en problemticos.

3.6.3 Limitaciones del Modelo en Espiral
Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es
controlable y que las personas involucradas operan en un contexto
consistente.
Requiere una considerable habilidad para la evaluacin del riesgo y cuenta
con esa habilidad para su xito.
Si un riesgo no es descubierto y gestionado surgirn problemas.
Es un esquema relativamente nuevo en relacin con esquemas lineales o
de construccin de prototipos a los que muchos estn acostumbrados.

En la Figura 3-5. Se puede apreciar el Modelo en Espiral.

Figura 3-5 Modelo en Espiral
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

22/32


3.6.4 Consideraciones del Ciclo de Vida en Espiral
El modelo de ciclo de vida en espiral debe implementarse cuando:
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

23/32

Se requiere reconocer, administrar y reducir riesgos de manera explcita.
Por lo mismo se requiere una completa administracin de riesgos del
proyecto.
Se necesita mantener una construccin interactiva de los prototipos.
Se requiere flexibilidad en la definicin o reajustes en las fases del modelo.
El costo y la planeacin requieren ser evaluadas por el cliente.

3.7 Modelo RAD (Rapid Application Development)
Se trata de un modelo lineal secuencial (o cascada) de proceso del desarrollo del
software que enfatiza un ciclo de desarrollo extremadamente corto.
El modelo RAD es una adaptacin a alta velocidad del modelo lineal en el que
se logra el desarrollo rpido utilizando un enfoque de construccin basado en
componentes.
Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso
RAD permite al equipo de desarrollo crear un sistema completamente funcional
dentro de perodos cortos de tiempo (entre 60 y 90 das), esto es un periodo
mucho menor al esperado por los otros ciclos de vida.
Es una metodologa ideal para aplicaciones de mediana complejidad en un
perodo extremadamente corto de desarrollo del software.

3.7.1 Aspectos importantes del Modelo RAD
Es un enfoque de desarrollo iterativo.
Permite analizar rpidamente el problema del negocio.
Recoleccin de requerimientos usando grupos dirigidos.
Permite disear una solucin viable por medio de una intensa cooperacin
entre usuarios y desarrolladores.
Permite conseguir rpidamente la finalizacin de la aplicacin.
Utilizacin de herramientas automticas para la creacin rpida de
prototipos y la generacin de cdigo.
Permite la reutilizacin de componentes de software.

3.7.2 Fases del Modelo RAD.
En la Figura 3-6Imagen_310 Se pueden apreciar las fases del modelo RAD, las
cuales se describen a continuacin:
Modelado de Gestin. Incluye la definicin de las funciones de gestin y el
modelado del flujo de informacin entre ellas.
Modelado de Datos. Se refina el flujo de informacin como un conjunto de
objetos; se definen los atributos y las relaciones.
Modelado del Proceso. Se modelan las transformaciones y transacciones
que se requieren.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

24/32

Generacin de Aplicaciones. Se utilizan lenguajes de cuarta generacin; se
trabaja para reutilizar componentes ya existentes o para crear componentes
reutilizables.
Pruebas y Entrega. Como el proceso enfatiza la reutilizacin, se presume
que se reduce el tiempo de pruebas. Se deben probar los componentes
nuevos y las interfaces.

Las limitaciones de tiempo impuestas en un proyecto RAD demandan lo que se
denomina mbito de escalas.
Si una aplicacin de gestin permite completar cada una de las funciones
principales en menos de tres meses, es un candidato del RAD.

Figura 3-6 Modelo RAD


Al igual que todos los modelos de desarrollo de software, este enfoque tiene
ventajas e inconvenientes, las cuales se mencionan a continuacin.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

25/32

3.7.3 Ventajas del Modelo RAD
El tiempo de desarrollo se reduce en un 50% o ms, con respecto al uso de
otros modelos.
Se requieren menos recursos, debido a la aplicacin de herramientas
avanzadas as como a la reutilizacin de componentes.
Alto grado de participacin del usuario en todas las etapas del proyecto.
Soluciona el problema del Modelo de Cascada que consiste en la dificultad
de retroceder una vez que se ha completado una fase lo cual impide que
los usuarios modifiquen los requerimientos del sistema y las
especificaciones, durante el desarrollo.

3.7.4 Limitaciones del Modelo RAD
Para proyectos grandes aunque por escalas, el RAD requiere recursos
humanos suficientes como para crear el nmero necesario de equipos.
RAD requiere clientes y desarrolladores comprometidos en las rpidas
actividades necesarias para completar un sistema en un marco de tiempo
abreviado. Si no hay un fuerte compromiso de las partes, un proyecto RAD
fracasar.
Se enfatiza el reuso de componentes realizados para otros sistemas.
No todos los tipos de aplicaciones son apropiados para RAD. Si un sistema
no se puede modularizar adecuadamente, la construccin de los
componentes necesarios ser problemtica.
No es un esquema apropiado cuando los riesgos tcnicos son altos. Esto
ocurre cuando una nueva aplicacin hace uso de tecnologas nuevas o se
requiere un alto nivel de interoperatividad con aplicaciones ya existentes.
No se puede satisfacer al mismo tiempo velocidad, costos y calidad.

3.7.5 Consideraciones del RAD
El modelo RAD debe implementarse cuando:
Se requiere un ciclo de vida extremadamente corto.
El desarrollo se basa en la construccin rpida de componentes.
Se comprenden ampliamente los requerimientos desde el inicio del ciclo.
El desarrollo del sistema se estima entre los 30 a 90 das.
El sistema cuenta con una sencilla a mediana complejidad.
Se cuenta con una alta cooperacin de los usuarios.

3.8 Modelo en V
El modelo en V es similar al modelo de cascada, pero da especial importancia a la
visin jerarquizada que se va teniendo de las distintas partes del sistema a medida
que se avanza en el desarrollo. Una fase adems de utilizarse como entrada para
la siguiente, sirve para validar o verificar otras fases posteriores.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

26/32

Este modelo toma en cuenta la simetra existente en varias etapas del ciclo de
vida, especialmente las concernientes al proceso de revisiones y pruebas de los
proyectos. Este modelo es uno de los ms interesantes y completos, dicho
sistema es propuesto por Alan Davis como base para el estudio y aplicacin de
mtodos.
En la Figura 3-7 se puede apreciar el Modelo en V.
El Modelo V determina un sistema uniforme de las actividades y de los productos
que se requieren durante el desarrollo del software (SD) y las actividades de
acompaamiento para el aseguramiento de la calidad (QA), la administracin de la
configuracin (CM) y la administracin tcnica del proyecto (PM).

Figura 3-7 Modelo en V

Anlisis de
Requisitos
Diseo Detallado
Diseo
Arquitectnico
Codificacin y
Unidad de Pruebas
Aceptacin de
Pruebas
Integracin de
Software
Sistema de
Integracin


La Representacin Grfica Secuencial del Modelo en V se define como sigue:
El Eje horizontal representa avance en el desarrollo y el eje vertical
corresponde al nivel de detalle con el que se trabaja en cada fase.
Las fases iniciales en la rama izquierda son descendientes (se van
descomponiendo en elementos cada vez ms sencillos hasta llegar a las
sentencias del lenguaje de programacin.)
Este modelo da especial nfasis a:
La validacin de los productos.
Procesos de anlisis (descomposicin) y sntesis (composicin).

Las caractersticas de este modelo son:
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

27/32

El producto de cada etapa es la entrada para la siguiente.
As tambin el producto determina los criterios para validar el resultado de
la composicin.
Es un modelo que satisface slo desarrollos conocidos y estables.
Se pueden establecer en un modelo en V el nmero de fases que se
considere necesario.
Incorpora el control o aseguramiento de la calidad.
Hace cumplir la equivalencia funcional.
Descompone y recompone, es decir la vinculacin entre los lados derecho e
izquierdo del modelo V implica, que si se encuentran problemas durante la
verificacin y la validacin, entonces el lado izquierdo de la V puede ser
ejecutado nuevamente, para solucionar el problema y mejorar los
requerimientos, el diseo y el cdigo antes de retomar los pasos de prueba
sobre el lado derecho. En otras palabras, el modelo V hace mas explicita
parte de la interaccin y rehacer tareas que estn ocultas en el modelo de
cascada.
Mientras que el modelo de cascada centra su foco en los documentos y
artefactos producidos, el modelo V lo pone en la actividad y exactitud. Es
decir, las principales consideraciones se basan en la inclusin de las
actividades de planeacin y ejecucin de pruebas como parte del proyecto
de desarrollo.

3.8.1 Consideraciones del ciclo de vida en V
El modelo de ciclo de vida en V debe implementarse cuando:
Se requiera una amplia y completa validacin de los productos. En este
punto cabe mencionar independientemente del modelo seleccionado, la
organizacin cuenta con procesos relacionados con el aseguramiento de la
calidad y prcticas que ayudarn a generar productos de calidad. [8]
Los componentes que se construyan requieran un profundo nivel de detalle.
La complejidad del sistema requiera procesos muy cuidadosos de anlisis y
sntesis.
El desarrollo sea muy estable.
Se requiere enfatizar la validacin del producto.
Se requiera una exigente validacin de la funcionalidad.

3.9 Modelo de Transformacin
Derivado del modelo en cascada, en l se considera que partiendo de las
especificaciones y gracias a las herramientas CASE estas se transforman en
diseo lgico del software, este se transforma en un diseo fsico (un diseo
dependiente de la tecnologa) y ste en el cdigo final.
El modelo de transformacin de Balzer intenta reducir las oportunidades de error
por medio de la eliminacin de varios de los pasos de desarrollo. Usando un
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

28/32

soporte automatizado, el proceso de transformacin aplica una serie de
transformaciones para convertir una especificacin en un sistema implementable.
Una muestra de las transformaciones puede ser la siguiente:
Cambiar la representacin de los datos.
Seleccionar algoritmos.
Optimizar.
Compilar.

Este modelo asume la transformacin automtica de la especificacin en el
producto software, por lo que solo es posible en pequeos dominios y cuando
exista poca flexibilidad.
En la Figura 3-8, se puede apreciar el Modelo de Transformacin.

Figura 3-8 Modelo de Transformacin

Especificacin
Formal
Optimizacin
Cdigo
Transformacin
Automtica
Prueba / Ajuste
Especificacin

Fuente: Ian Sommerville 2000

Desde la visin de Ian Sommerville, este modelo se caracteriza porque un
concepto de aplicacin se transforma de modo paulatino en una especificacin
formal de software. Esto implica la reduccin de la cantidad de informacin bruta
en cada etapa de la transformacin, proceso que l denomina abstraccin. Una
vez establecida la especificacin, se aade la informacin, a esto le llama
materializacin. El sistema abstracto se transforma mediante un conjunto de
notaciones formales en un programa operacional. Es decir, este mtodo
sistemtico permite transformar programas de una clase ms compleja en otra de
complejidad menor.
El modelo de transformacin evita las dificultades de tener que modificar un cdigo
que tiene una estructuracin muy pobre -debido a las repetidas optimizaciones,
mediante la posibilidad de que las modificaciones sean fabricadas a travs de las
especificaciones, esto sin intervenir el cdigo, el cual se reconstruira cada vez.
Con este modelo se puede aumentar, al menos tericamente, la capacidad de dar
respuesta rpida a la evolucin que naturalmente estara asociada a las
organizaciones, pero, al igual que el modelo espiral, se ha alejado del problema de
cmo acortar la brecha conceptual entre los dominios del desarrollador y del
usuario. Con relacin a este problema, la crtica que se puede hacer al modelo de
transformacin es que necesariamente al transformar un problema se est
aplicando un reduccionismo que, probablemente, limite la expresin de toda la
complejidad del problema original.
El modelo de transformacin asume la existencia de una capacidad de
automticamente convertir una especificacin formal de un producto de software
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

29/32

en un programa que satisfaga la especificacin. Los pasos que son prescritos por
el modelo de transformacin son:
Una especificacin formal de la mejor comprensin inicial del producto
deseado.
Transformacin automtica de la especificacin en cdigo.
Un ciclo iterativo, si es necesario, para mejorar la ejecucin del cdigo
resultante para dar una gua de optimizacin al sistema de transformacin.
Probar el producto resultante, y
Un ciclo interactivo externo para ajustar las especificaciones basadas en el
resultado de la experiencia operacional, y para re-derivar, re-optimizar, y
probar el producto de software ajustado.
3.9.1 Consideraciones del ciclo de vida de transformacin
El modelo de ciclo de vida de transformacin debe implementarse cuando:
El dominio de la aplicacin sea muy especfico y reducido.
Se requiera un tiempo extremadamente corto de desarrollo y no se cuente
con mucha flexibilidad.
Se requiere dar respuesta rpida a la evolucin de un sistema.

3.10 Uso de Prototipos
1. El principal uso de prototipos, es ayudar a clientes y desarrolladores a
entender los requerimientos del sistema.
Licitacin de Requerimientos. Los usuarios pueden experimentar con un
prototipo la visualizacin de cmo el sistema da soporte a sus tareas.
Validacin de Requerimientos. El prototipo puede revelar errores y
omisiones en los requerimientos.
Requerimientos. Representacin visual y operacional de los
requerimientos.

2. Reducir riesgos en requerimientos.
Mal entendidos entre usuarios y desarrolladores son peligrosos.
La confusin de servicios pueden ser detectados a tiempo.

3. Interfaces de usuario son difciles de especificar sin un prototipo.
4. El funcionamiento de un sistema est disponible durante el proceso.
5. El prototipo sirve como base para obtener la especificacin de los
requerimientos.
6. Mejorar la usabilidad de los sistemas.
7. Estar ms cerca de coincidir con el sistema necesitado.
8. Reducir el esfuerzo de desarrollo.

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

30/32

3.11 Proceso de Prototipos
En la Figura 3-9. Se puede apreciar el proceso de prototipado

Figura 3-9 Proceso de Prototipos

Definir la
funcionalidad del
prototipo
Desarrollo del
prototipo
Evaluar el prototipo
Plan del prototipo
Definicin del
contorno
Prototipo
ejecutable
Reporte de
evaluacin
Establecer
objetivos del
prototipo


3.11.1 Tipos de Prototipos
Modelo de Prueba
Rapidez y
Modelo
Anlisis
Evolutivo

3.11.1.1 Prototipo de Anlisis y Evolutivo
Anlisis. Prototipo que usualmente se puede implementar en el sistema
producido para ayudar a descubrir problemas en requerimientos y despus
poder desecharlos.
Evolutivo. Logra una aproximacin al sistema desarrollado, donde un
prototipo inicial es producido y definido a travs de un nmero de etapas
en el sistema final.

3.11.1.2 Prototipo de Anlisis
En la Figura 3-10. Se puede apreciar el Prototipo de Anlisis.

Figura 3-10 Prototipo de Anlisis

C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

31/32


3.11.2 Tcnicas de Prototipado

Varias tcnicas pueden ser usadas para prototipar:
Prototipos basados en papel.
Herramientas grficas (Photoshop, Ilustradores, etc)
Storyboards
PowerPoint
Lenguajes dinmicos de alto nivel
Programacin en bases de datos
Implementacin de componentes y aplicaciones

No existen tcnicas exclusivas, a menudo son usadas en conjunto. La
programacin visual es una parte esencial para muchos prototipos de sistemas de
desarrollo.

3.11.3 Posibles Problemas
1. Los desarrolladores pueden apresurarse a liberar un prototipo de Anlisis
como si fuera un sistema final.
Puede llegar a ser imposible afinar el prototipo para encontrar
requerimientos no funcionales.
No se cuenta con documentacin del prototipo.
La estructura del sistema ir perdiendo su originalidad a travs de
cambios hechos durante el desarrollo.
Normalmente estndares de calidad organizacional no han sido
aplicados.

2. El proceso se sale de control cuando los usuarios se tornan muy exigentes.
3. No identificar diferencia entre prototipos y herramientas de desarrollo.
C
o
n
f
i
d
e
n
c
i
a
l
CITIS

05/02/09

32/32

4. Algunas partes de los requerimientos (p/e funciones de seguridad crtica),
puede ser imposible de generar prototipos y no aparecer en las
especificaciones.
5. Una implementacin no tiene un valor legal como lo tiene un contrato.
6. Requerimientos no funcionales no pueden probarse adecuadamente en un
prototipo.

Ciclos Vida SW PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ciclos Vida SW PDF

Transféré par

Droits d'auteur :

Formats disponibles

C

, Quarksoft Standard Software Development Process, Mxico D.F.

Vous aimerez peut-être aussi