1. ¿Qué entiende por Ciclo de Vida de un
Software?
Un modelo de ciclo de vida define el estado de las fases a
través de las cuales se mueve un proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por
Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han
seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo
cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y
rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su
lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo
modelos que pretenden desarrollar software más rápidamente, o más
incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a
escala total con algún conjunto de prototipos rápidos.
2. ¿De qué procedimientos consta un
Ciclo de Vida Básico?
·
Definición
de objetivos
·
Análisis de los requisitos y su viabilidad
·
Diseño
general
·
Diseño en
detalle
·
Programación
·
Prueba de
unidad
·
Integración
·
Prueba beta
·
Documentación
·
Mantenimiento
El orden y la presencia de cada uno de estos
procedimientos en el ciclo de vida de una aplicación dependen del tipo de
modelo de ciclo de vida acordado entre el cliente y el equipo de
desarrolladores.
3. Escriba 5 ejemplos de Modelos de Ciclos de Vida
- Modelo Cascada
- Modelo De Desarrollo Incremental
- Modelo De Desarrollo Evolutivo
- Modelo Espiral
- Modelo Concurrente
4. Explique el proceso del
Modelo Cascada
El modelo de ciclo de vida en cascada comenzó a diseñarse en
1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en
la que al final de cada una de ellas se reúne la documentación para garantizar
que cumple las especificaciones y los requisitos antes de pasar a la fase
siguiente:
5. ¿Qué es Desarrollo Incremental?
Los riesgos asociados con el desarrollo de sistemas largos y
complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte
del sistema, reservando otros aspectos para niveles posteriores. El desarrollo
incremental es el proceso de construcción siempre incrementando subconjuntos de
requerimientos del sistema. Típicamente, un documento de requerimientos es
escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El
desarrollo incremental no demanda una forma específica de observar el
desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado
para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
6. Explique los beneficios del Modelo de
Desarrollo Incremental
- Construir un sistema pequeño es siempre menos riesgoso que
construir un sistema grande.
- Al ir desarrollando parte de las funcionalidades, es más fácil
determinar si los requerimientos planeados para los niveles subsiguientes
son correctos.
- Si un error importante es realizado, sólo la última iteración
necesita ser descartada.
- Reduciendo el tiempo de desarrollo de un sistema (en este caso en
incremento del sistema) decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.
- Si un error importante es realizado, el incremento previo puede ser
usado.
- Los errores de desarrollo realizados en un incremento, pueden ser
arreglados antes del comienzo del próximo incremento.
7. ¿Qué pasos podemos seguir
para ejecutar el Modelo Espiral?
puedes seguir estos cuatros pasos:
* Determinar qué quieres lograr.
* Determinar las rutas alternativas que puedes tomar para lograr estas
metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar
la mejor.
* Seguir la alternativa seleccionada en el paso 2.
* Establecer qué tienes
terminado.
8. ¿Qué es el Modelo de Prototipado de
Requerimientos?
es la creación de una implementación parcial de un sistema, para el propósito
explícito de aprender sobre los requerimientos del sistema. Un prototipo es
construido de una manera rápida tal como sea posible. Esto es dado a los
usuarios, clientes o representantes de ellos, posibilitando que ellos
experimenten con el prototipo. Estos individuos luego proveen la
retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo
proporcionado, quienes capturan en la documentación actual de la especificación
de requerimientos la información entregada por los usuarios para el desarrollo
del sistema real. El prototipado puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el
prototipado puede servir su papel inmediatamente antes de algún o todo el
desarrollo incremental en modelos incremental o evolutivo.
9. Compare
el Modelo de Desarrollo Evolutivo y el Modelo de Desarrollo Incremental
Modelo De Desarrollo Incremental
Note que el desarrollo incremental es 100% compatible con el
modelo cascada. El desarrollo incremental no demanda una forma específica de
observar el desarrollo de algún otro incremento. Así, el modelo cascada puede
ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la
figura.
Modelo De Desarrollo Evolutivo
Note que el desarrollo evolutivo es 100% compatible con el
modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar
el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para
administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental
y evolutivo puede ser combinado también.
10. Describa un caso en el Modelo Concurrente
Los requerimientos son usualmente "líneas de base",
cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en
este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez
que comienza el diseño, cambios a los requerimientos son comunes y frecuentes
(después de todo, los problemas reales cambian, y nuestro entendimiento de los
problemas desarrollados también). Es desaconsejado detener el diseño en este
camino cuando los requerimientos cambian; en su lugar, existe una necesidad de
modificar y rehacer líneas de base de los requerimientos mientras progresa el
diseño. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseño puede no ser afectado, medianamente afectado o se
requerirá comenzar todo de nuevo.
