AO DE LA PROMOCIN DE LA INDUSTRIA RESPONSABLE Y

COMPROMISO CLIMTICO

CICLO DE VIDA DEL SOFTWARE

CURSO: ANLISIS DE SISTEMAS I

31 DE OCTUBRE DE 2014
PROFESOR: ING. JOS ALBERTO NAVARRO PARDO
ALUMNA: SCARLETT THAYS LANGLEY BENITES

CICLO DE VIDA DEL SOFTWARE

I)

DEFINICION
I.1) Ciclo de Vida
El trmino ciclo de vida del software describe el desarrollo de
software, desde la fase inicial hasta la fase final. El propsito de este
programa es definir las distintas fases intermedias que se requieren
para validar el desarrollo de la aplicacin, es decir, para garantizar
que el software cumpla los requisitos para la aplicacin y verificacin
de los procedimientos de desarrollo: se asegura de que los mtodos
utilizados son apropiados.
Estos programas se originan en el hecho de que es muy costoso
rectificar los errores que se detectan tarde dentro de la fase de
implementacin. El ciclo de vida permite que los errores se detecten
lo antes posible y por lo tanto, permite a los desarrolladores
concentrarse en la calidad del software, en los plazos de
implementacin y en los costos asociados.
I.2) Segn la norma ISO 12207:
La ISO/IEC 12207 (Information Technology/Software Life Cycle
Processes), tiene como objetivo principal proporcionar una estructura
comn para que compradores, proveedores, desarrolladores,
operadores, gestores, personal de mantemiento y tcnicos
involucrados en el desarrollo de software usen un lenguaje comn,
es otras palabras es el estndar para los procesos de ciclo de vida
del software.
I.3) Estructura
La estructura del estndar ha sido concebida de manera que pueda
ser adaptada a las necesidades de cualquiera que lo use. Para
conseguirlo, el estndar se basa en dos principios fundamentales:
Modularidad y responsabilidad.
Con la modularidad se pretende conseguir procesos con un mnimo
acoplamiento y una mxima cohesin. En cuanto a la
responsabilidad, se busca establecer un responsable para cada
proceso, facilitando la aplicacin del estndar en proyectos en los
que pueden existir distintas personas u organizaciones involucradas,
no importando el uso que se le d a este.
I.4) Procesos
Los procesos se clasifican en tres tipos: Procesos principales,
procesos de soporte o apoyo y procesos organizativos. Los procesos
de soporte y de organizacin deben existir independientemente de la

organizacin y del proyecto ejecutado. Los procesos principales se

instancian de acuerdo con la situacin particular.

II)

Procesos principales.
Adquisicin.
Suministro.
Desarrollo.
Operacin.
Mantenimiento.

Procesos de soporte.
Documentacin
Gestin de la configuracin.
Aseguramiento de calidad.
Verificacin.
Validacin.
Revisin conjunta.
Auditora.
Resolucin de problemas.

Procesos de la organizacin.
Gestin.
Infraestructura.
Mejora.
Recursos Humanos.

MODELOS DE CICLO DE VIDA

Las principales diferencias entre distintos modelos de ciclo de vida
estn divididas en tres grandes visiones:
El alcance del ciclo de vida, que obedece de hasta dnde
queremos llegar con el proyecto: slo saber si es asequible el
desarrollo de un producto, el desarrollo completo o el desarrollo
completo ms las actualizaciones y el mantenimiento.
La cualidad y cantidad de las etapas en que fragmentaremos el
ciclo de vida: segn el ciclo de vida que adoptemos, y el proyecto
para el cual lo adoptemos.
La estructura y la sucesin de las etapas, si hay realimentacin
entre ellas, y si tenemos libertad de volverlas a hacer (iterar).
En los diferentes modelos de ciclo de vida aludiremos el Riesgo que
suponemos aceptar al elegirlo. Cuando hablamos de riesgo, nos
referimos a la probabilidad que tendremos de volver a retomar una
de las etapas anteriores, perdiendo tiempo, dinero y esfuerzo.

II.1) Ciclo de vida lineal

Es el ms sencillo de todos los modelos. Consiste en descomponer
la actividad global del proyecto en etapas separadas que son
realizadas de manera lineal, es decir, cada etapa se realiza una sola
vez, a continuacin de la etapa anterior y antes de la etapa siguiente.
Con un ciclo de vida lineal es muy fcil dividir las tareas, y prever los
tiempos (sumando linealmente los de cada etapa).
II.1.1) Caractersticas
-

Las actividades de cada una de las etapas citadas deben ser

independientes entre s, es decir, que es condicin primordial que
no haya retroalimentacin entre ellas, aunque s pueden admitirse
ciertos supuestos de realimentacin correctiva.
Desde el punto de vista de la gestin, requiere tambin que se
conozca desde el primer momento, con excesiva rigidez, lo que
va a ocurrir en cada una de las distintas etapas antes de
comenzarla.
Esto ltimo minimiza, tambin, las posibilidades de errores
durante la codificacin y reduce al mnimo la necesidad de
requerir informacin del cliente o del usuario.

II.1.2) Ventajas
Se destaca como ventaja la sencillez de su gestin y administracin
tanto temporal como econmica, ya que se adapta perfectamente a
proyectos internos de una empresa para programas muy pequeos
de ABM (sistemas que realizan Altas, Bajas y Modificaciones sobre
un conjunto de datos).
Es vlido tomar este ciclo de vida cuando algn sector pequeo de
una empresa necesita llevar un registro de datos acumulativos, sin
necesidad de realizar procesos sobre ellos ms que una consulta
simple. Es decir, una aplicacin que se dedique exclusivamente a
almacenar datos, sea una base de
datos o un archivo plano. Debido a que la realizacin de las etapas
es muy simple y el cdigo muy sencillo.
II.1.3) Desventajas

Tiene como desventaja que no es apto para Desarrollos que superen

mnimamente requerimientos de retroalimentacin entre etapas, es
decir, es muy costoso retomar una etapa anterior al detectar alguna
falla.
II.2) Ciclo de vida en V
El modelo de ciclo de vida V, fue diseado por Alan Davis, proviene
del principio que establece que los procedimientos utilizados para
probar si la aplicacin cumple las especificaciones ya deben haberse
creado en la fase de diseo.
II.2.1) Caractersticas
- Este ciclo contiene las mismas etapas que el ciclo de vida en
cascada puro. La diferencia es que, a ste se le agregaron dos
subetapas de retroalimentacin entre las etapas de anlisis y
mantenimiento, y entre las de diseo y debugging.
- El modelo en V hace ms explcita parte de las iteraciones y
repeticiones de trabajo que estn ocultas en el modelo en
cascada. Mientras el foco del modelo en cascada se sita en los
documentos y productos desarrollados, el modelo en V se centra
en las actividades y la correccin.

II.2.2) Ventajas
La relacin entre las etapas de desarrollo y los distintos tipos de
pruebas
facilitan
la
localizacin
de
fallos.
Es un modelo sencillo y de fcil aprendizaje.
Hace explcito parte de la iteracin y trabajo que hay que revisar.
Especifica bien los roles de los distintos tipos de pruebas a
realizar.
Involucra al usuario en las pruebas.
II.2.3) Desventajas
Es difcil que el cliente exponga explcitamente todos los
requisitos.
El cliente debe tener paciencia pues obtendr el producto al final
del ciclo de vida.

 Las pruebas pueden ser caras y, a veces, no lo suficientemente

efectivas.
El producto final obtenido puede que no refleje todos los
requisitos del usuario.
II.3) Ciclo de vida en cascada con subproyectos
Se entiende como una variacin sobre el ciclo de vida en Cascada del
software, denominada Cascada con Subproyectos, porque permite la
ejecucin de algunas de las tareas de la cascada en paralelo.

II.3.1) Caractersticas
Cuenta con tres etapas iniciales:
- Concepto del software,
- anlisis de requerimientos y
- diseo global,
stas se realizan linealmente, y luego propone separar el proyecto
global en subproyectos ms pequeos de forma que las siguientes
fases:
-

el diseo detallado,
la codificacin y depuracin, y
las pruebas iniciales

se realicen linealmente para cada subproyecto definido, logrando as

que cada subproyecto se desarrolle llevando a cabo tareas y tcnicas
particulares de acuerdo a sus respectivas necesidades.
La etapa final de la metodologa consiste en llevar a cabo la
integracin de los subproyectos y la realizacin de pruebas globales.

II.3.2) Ventajas
- Permite la construccin del sistema con requisitos poco claros o
cambiantes.
- El cliente recibe una versin del sistema en muy poco tiempo, por
lo que lo puede evaluar, probar e, incluso, empezar a utilizarlo.
- Se pueden introducir cambios en las funcionalidades del sistema
en cualquier momento.
- Involucra al usuario en la evaluacin de la interfaz de usuario.
- Se reduce el riesgo y la incertidumbre sobre el desarrollo.
- Genera signos visibles de progreso, que se utilizan cuando existe
una demanda en la velocidad del desarrollo.
- Permite entender bien el problema antes de la implementacin
final.
- La aplicacin de esta metodologa podra ser el desarrollo de un
sistema de informacin para una empresa, en donde deben estar
involucradas todas las reas de la misma porque siempre estn
compartiendo informacin.
II.3.3) Desventajas
- El cliente puede quedar convencido con las primeras versiones y,
quizs, no vea la necesidad de completar el sistema o redisearlo
con la calidad necesaria.
- Requiere trabajo del cliente para evaluar los distintos prototipos y
traducirlo en nuevos requisitos.
- Requiere un tiempo adicional para definir adecuadamente el
sistema.
- No se sabe exactamente cunto ser el tiempo de desarrollo ni
cuantos prototipos se tienen que desarrollar.
- Si un prototipo fracasa, el coste del proyecto puede resultar muy
caro.
II.4) Ciclo de vida en espiral
Boehm, ide y promulg un modelo desde un enfoque distinto al
tradicional en Cascada: El Modelo Evolutivo Espiral. ste es un
modelo orientado a riesgo que divide el proyecto de software en
miniproyectos. Cada proyecto se encargar de resolver uno o varios
riesgos hasta que estn todos controlados. Para ello, se comienza
mirando las posibles alternativas de desarrollo, se opta por la de
riesgo ms asumible y se hace un ciclo de la espiral. Si el cliente
quiere seguir haciendo mejoras en el software, se vuelve a evaluar las
distintas 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.

A menudo, la fuente de incertidumbres es el propio cliente o usuario,

que en la mayora de las oportunidades no sabe con perfeccin todas
las funcionalidades que debe tener el producto.

II.4.1) Caractersticas
En este modelo hay cuatro actividades que envuelven a las etapas.
- Planificacin: Relevamiento de requerimientos iniciales o luego de
una iteracin.
- Anlisis de riesgo: De acuerdo con el relevamiento de
requerimientos decidimos si continuamos con el desarrollo.
- Implementacin: desarrollamos un prototipo basado en los
requerimientos.
- Evaluacin: El cliente evala el prototipo, si da su conformidad,
termina el proyecto. En caso contrario, incluimos los nuevos
requerimientos solicitados por el cliente en la siguiente iteracin.
En cada iteracin seguimos los siguientes pasos:

Determinar objetivos, alternativas y lmites.

Identificar y resolver riesgos.

Evaluar las alternativas.

Generar entregas de esta iteracin, y comprobar que son

correctas.

Planificar la siguiente iteracin.

 Si se decide ejecutar la siguiente iteracin, hay que establecer un

enfoque para ella.
II.4.2) Ventajas
La ventaja ms notoria de este modelo de desarrollo de software es
que puede comenzarse el proyecto con un alto grado de
incertidumbre, se entiende tambin como ventaja el bajo riesgo de
retraso en caso de deteccin de errores, ya que se puede solucionar
en la prxima rama del espiral.
II.4.3) Desventajas
Algunas de las desventajas son: el costo temporal que suma cada
vuelta del espiral, la dificultad para evaluar los riesgos y la necesidad
de la presencia o la comunicacin contina con el cliente o usuario.
Se observa que es un modelo adecuado para grandes proyectos
internos de una empresa, en donde no es posible contar con todos los
requerimientos desde el comienzo y el usuario est en nuestro mismo
ambiente laboral.
Podemos citar una aplicacin que administre reclamos, pedidos e
incidentes, como ejemplo para utilizar este modelo de ciclo de vida, en
el que los sectores que utilizarn el sistema son demasiados y con
intereses muy diversos como para lograr un relevamiento exhaustivo y
completo de los requerimientos.
III)

Casos Prcticos
III.1.1) Ciclo de vida lineal
Una Universidad necesita que se cree un sistema en donde sus
estudiantes y profesores puedan crear y ver el horario de clases de
manera rpida y eficaz. Para ello, es de conocimiento del
desarrollador que tanto los alumnos como los profesores cuentan con
un carnet que los identifica y con el cual podrn acceder al sistema
para poder armar y consultar el horario.
En el caso que el cdigo del alumno/profesor no sea el correcto,
deber mostrarse una ventana que diga cdigo incorrecto. El sistema
de control de acceso permitir los intentos necesarios hasta que
puedan ver el horario.
El sistema deber detectar que el cdigo ha sido rellenado en el
espacio establecido y que dicho valor se corresponde con datos
previamente almacenados en la base.
Especificacin de Requisitos:
R1: El sistema debe permitir la identificacin del cdigo de alumno/
profesor.

R2: Los alumnos/profesores estn identificados por su cdigo. ste

cdigo no debe exceder la longitud de 10 caracteres ni debe
contener letras, slo son nmeros.
R3: Deber comprobarse que el cdigo de usuario corresponda con
un usuario con autorizacin para acceder al sistema, esta
informacin ya habr sido incorporada previamente al mismo.
R4: Cuando el usuario no est autorizado se mostrar el mensaje de
usuario no registrado XX No tiene permiso para acceder a este
sistema donde XX se corresponder con el cdigo que haya sido
escrito.
R5: Cuando no se haya introducido ningn valor para la palabra de
paso se mostrar el mensaje: Debe rellenar la informacin sobre el
cdigo
R6: Cuando el usuario est autorizado se mostrar una pantalla con
el mensaje: Bienvenido XX donde XX se corresponder con el
nombre que haya sido registrado previamente.
R7: El sistema permitir los intentos necesarios para acceder como
usuario identificado.
R8: No pueden existir dos cdigos iguales en el sistema.
R9: El usuario podr armar el horario libremente. El sistema mostrar
los cursos que tiene disponibles.
R10: Cuando el usuario guarde el proceso se mostrar una pantalla
con el mensaje: Horario guardado.
R11: Una vez guardado el horario este no podr modificarse de
ninguna manera.
Diseo
Tras la etapa anterior ya se tiene claro qu debe hacer el sistema;
ahora tenemos que determinar cmo va a hacerlo (cmo debe ser
construido el sistema?; aqu se definirn en detalle entidades y
relaciones de las bases de datos, se pasar de casos de uso
esenciales a su definicin como casos expandidos reales, se
seleccionar el lenguaje ms adecuado, el Sistema Gestor de Bases
de Datos a utilizar en su caso, configuraciones hardware, redes,
etc.).
Sin embargo el desarrollador y usuario debe tener en cuenta que una
vez que ste se elabore no podr ser modificado. Y que cada etapa
de desarrollar en forma paralela con las dems, para arrojar al final
un solo resultado.
Implementacin
Llegado este punto se empieza a codificar algoritmos y estructuras
de datos, definidos en las etapas anteriores, en el correspondiente
lenguaje de programacin.
Pruebas
El proyecto deber realizar las siguientes pruebas.

1. Dejar el espacio del cdigo vaco, el resultado esperado es la

pantalla Debe rellenar la informacin sobre el cdigo
2. Poner el cdigo correcto, el resultado esperado es la pantalla
Entrada.
3. Armar el horario y guardarlo, el resultado en la pantalla ser:
Horario guardado
Se va a desarrollar el proyecto en 4 fases:
Fase 1: Identificacin de usuario
Fase 2: Mensaje de error de acceso detallado
Fase 3: Mostrar los cursos disponibles segn el cdigo del usuario.
Fase 4: Mensaje de horario guardado.
IMPLEMENTACIN:
Una vez probado el sistema, se implementa en la Universidad.
III.1.2) Ciclo de vida en V
La ferretera NAVAR tiene la necesidad de contar con un sistema que
permita llevar un mejor control, que a su vez sea fcil de manejar; el
control consiste en llevar a cabo un registro de todos los productos
con los que se cuenta. Para dicho registro se necesitaran datos como
los siguientes:
PRODUCTOS. Para poder dar de alta cada producto se tendrn en
cuenta: una clave o cdigo del producto (esta se asignara tomando
en cuenta el tipo del producto), el nombre, la cantidad, el precio.
El tipo o clasificacin de los productos se da de la siguiente manera:
cemento, pisos y azulejos, yeso, de ferretera, herramientas Truper y
acero.
Especificacin de Requisitos:
R1: El sistema debe permitir la identificacin del cdigo de los
productos.
R2: Los productos estn identificados por su cdigo. ste cdigo no
debe exceder la longitud de 5 caracteres ni debe contener letras, slo
son nmeros.
R3: Deber comprobarse que el cdigo del producto corresponda
con un producto que se encuentre en la clasificacin mencionada
antes, esta informacin ya habr sido incorporada previamente al
mismo.
R4: El espacio de nombre no debe ser mayor a 15 caracteres; el de
precio no mayor a 4 cifras y el de cantidad sern ilimitado.

R5: Cuando no se haya introducido ningn valor para la palabra de

paso se mostrar el mensaje: Debe rellenar la informacin sobre el
cdigo
R6: No pueden existir dos cdigos iguales en el sistema.
R7: Cuando el usuario guarde el proceso de registro de producto se
mostrar una pantalla con el mensaje: Registro guardado.
Estos requerimientos debern ser validados, para poder iniciar la
etapa de diseo.
Diseo
Se dedica a las caractersticas funcionales del sistema propuesto.
Puede considerarse como una caja negra, y caracterizarla
nicamente con aquellas funciones que son directa o indirectamente
visibles por el usuario final, se traduce en un documento de anlisis
funcional.
Luego se detallaran y definirn los componentes del hardware y
software del sistema final, a cuyo conjunto se denomina arquitectura
del sistema.
Entonces aqu aparecer una entidad que es Producto con 4
atributos:
- Nombre: de tipo cadena de caracteres de tamao 15.
- Cdigo: de tipo cadena de caracteres de tamao 5.
- Precio: de tipo de cadena no mayor a 5.
- Cantidad: de tipo de cadena ilimitado.
Implementacin
Aqu se desarrollaran los mdulos del programa de registro de
productos.

III.1.3) Ciclo de vida en cascada con sub proyectos

Una empresa quiere implantar un sistema de control de acceso de
usuarios previo al arranque del resto de aplicaciones que tiene
Instaladas. Cada usuario deber indicar su nombre y palabra de paso
para poder tener acceso al resto del sistema.
El sistema de control de acceso permitir un mximo de tres intentos
antes de bloquear el terminal durante cinco minutos.
El sistema deber detectar que tanto el nombre como la palabra de
paso han sido rellenadas y que dichos valores se corresponden con
los que previamente han sido almacenados en la base de datos de
control de accesos.
Bajo ningn concepto, el nombre de usuario y la palabra de paso
podrn quedar sin rellenar.

En el caso de no poder realizar la identificacin de los usuarios que

quieren acceder al sistema, deber mostrarse un mensaje de error
que indique cual es la causa de fallo de identificacin.
Este sistema ser usado en todos los departamentos de la empresa,
para al final centralizarse toda la informacin en el departamento de
recursos humanos, quien es quien lleva el registro de todos los
trabajadores. Bsicamente el sistema le permitir ver mediante el
control de acceso, quines estn laborando y quines no.

ESPECIFICACION DE REQUISITOS:
Se han detectado los siguientes requisitos:
R1: El sistema debe permitir la identificacin de usuarios
R2: Los usuarios estn identificados por su nombre y palabra de
paso. En nombre no exceder la longitud de 15 caracteres y la
palabra de paso de 8.
R3: Es obligatorio que tanto el nombre como la palabra de paso sean
cumplimentados por el usuario
R4: Deber comprobarse que el nombre de usuario y la palabra de
paso se corresponden con un usuario con autorizacin para acceder
al sistema, esta informacin ya habr sido incorporada previamente
al mismo.
R5: Cuando el usuario no est autorizado se mostrar el mensaje de
error XX No tiene permiso para acceder a este sistema donde XX
se corresponder con el nombre que haya sido escrito.
R6: Cuando no se haya introducido ningn valor para el nombre se
mostrar el mensaje: Debe rellenar la informacin sobre su nombre
R7: Cuando no se haya introducido ningn valor para la palabra de
paso se mostrar el mensaje: Debe rellenar la informacin sobre la
palabra de paso
R8: Cuando el usuario est autorizado se mostrar una pantalla con
el mensaje: Bienvenido XX donde XX se corresponder con el
nombre que haya sido escrito.
R9: El sistema permitir tres intentos para acceder como usuario
identificado.
R10: Despus del tercer intento el sistema quedar bloqueado
durante cinco minutos y se mostrar el mensaje Terminal
bloqueado. Quedan: YY minutos donde YY representa el nmero de
minutos que resten de bloqueo.
R11: No pueden existir dos pares nombre y clave repetidos en el
sistema.
ANALISIS:
Se va a plantear como solucin una visin estructurada basada en
diagramas Entidad/Relacin y diagramas de flujo de datos.
DISEO:

Modelo Entidad/Relacin
Slo aparece una entidad que es Usuario con dos atributos:
- Nombre: de tipo cadena de caracteres de tamao 15.
- Palabra de paso (Clave): de tipo cadena de caracteres de tamao
8.

CLAVE

NOMBRE

USUARIO

INTEGRACIN DE SUBPROYECTOS:
Cada subproyecto de cada rea, debern realizar las siguientes
pruebas:
1. Dejar nombre y palabra de paso vaca, el resultado esperado es la
pantalla Error1.
2. Dejar palabra de paso vaca, el resultado esperado es la pantalla
Error2.
3. Poner un nombre y una palabra de paso incorrecta, el resultado
esperado es la pantalla Error3.
4. Poner un nombre y una palabra de paso correcta, el resultado
esperado es la pantalla Entrada.
5. Poner tres veces un nombre y palabra de paso incorrecta, el
resultado esperado es la pantalla Bloqueado.
Se va a desarrollar el proyecto en dos fases:
Fase 1: Identificacin de usuario
Fase 2: Mensaje de error de acceso detallado
Luego de haberse puesto a prueba en cada departamento, se
centralizar la informacin en el departamento de recursos
humanos.
IMPLEMENTACIN:

Una vez probado el sistema, se implementa a la empresa.

III.1.4) Ciclo de vida en espiral
La librera SUNSHINE tiene la necesidad de contar con un sistema
que permita llevar un mejor control, que a su vez sea fcil de
manejar; el control consiste en llevar a cabo un registro de todos los
productos con los que se cuenta. Para dicho registro se necesitaran
datos como los siguientes: Para poder dar de alta cada producto se
tendrn en cuenta: una clave o cdigo del producto (esta se asignara
tomando en cuenta el tipo del producto), el nombre, la marca, la
cantidad, el precio.
Especificacin de Requisitos:
R1: El sistema debe permitir la identificacin del cdigo de los
productos.
R2: Los productos estn identificados por su cdigo. ste cdigo no
debe exceder la longitud de 5 caracteres ni debe contener letras, slo
son nmeros.
R3: Deber comprobarse que el cdigo del producto corresponda
con un producto que se encuentre en la base de datos, esta
informacin ya habr sido incorporada previamente al mismo.
R4: El espacio de nombre no debe ser mayor a 15 caracteres
(letras); la marca a 10 (letras); el de precio no mayor a 4 cifras y el de
cantidad sern ilimitado.
R5: Cuando no se haya introducido ningn valor para la palabra de
paso se mostrar el mensaje: Debe rellenar la informacin completa
sobre el productos
R6: No pueden existir dos cdigos iguales en el sistema.
R7: Cuando el usuario guarde el proceso de registro de producto se
mostrar una pantalla con el mensaje: Registro guardado.
Diseo
El desarrollador elaborara el nuevo producto en base a los
requerimientos del usuario.
Entonces aqu aparecer una entidad que es Producto con 5
atributos:
- Nombre: de tipo cadena de caracteres de tamao 15.
- Marca: de tipo cadenas de caracteres de tamao 10.
- Cdigo: de tipo cadena de caracteres de tamao 5.
- Precio: de tipo de cadena no mayor a 5.
- Cantidad: de tipo de cadena ilimitado.
El cliente o usuario observa que al sistema le falta el siguiente
requerimiento:
R8: En el caso que exista un producto que no se encuentre en la
base datos deber ser ingresado

Entonces se deber mejorar el producto incluyendo este nuevo

requerimiento. El cliente lo volver a evaluar y conforme, lo aceptar.
Implementacin
Aqu se aplica el sistema y se le da mantenimiento respectivo.
IV)

CONCLUSION
Despus de ver los distintos modelos de ciclo de vida del software,
resulta muy difcil elegir uno para aplicarlo al proyecto que se desea.
Es por eso, que es muy importante tener en claro el proyecto y los
requerimientos que necesitamos cumplir, ya que esto regir la
decisin a tomar. Podemos tomar como referencia la complejidad del
problema, el tiempo que se dispones para poder entregar el
producto, o si se desean entregas parciales.

V)

BIBLIOGRAFA
Implementacin y debugging [en lnea]: documento electrnico
encontrado en internet. [fecha de consulta: 28/10/14]. Disponible
en:<http://img.redusers.com/imagenes/libros/lpcu097/capitulogratis.p
df />.
Ciclo de vida en sistemas [en lnea]: documento electrnico
encontrado en internet. [fecha de consulta: 29/10/14]. Disponible
en:<http://www.ieonline.unan.edu.ni/av1/pluginfile.php/77977/mod_re
source/content/1/Ciclo%20de%20vida%20de%20sistemas.pdf >.
Ciclo de vida lineal [en lnea]: documento electrnico encontrado en
internet.
[fecha
de
consulta:
29/10/14].
Disponible
en:<http://ciclodevidasoftware.wikispaces.com/CICLO+DE+VIDA+LIN
EAL>.
Modelo espiral [en lnea]: documento electrnico encontrado en
internet.
[fecha
de
consulta:
30/10/14].
Disponible
en:<http://modeloespiral.blogspot.com/ >.