Es (un proceso para la creación del software) en que el desarrollo
se considera como fluyendo constantemente hacia abajo (como a cascada) con las fases de análisis de requisitos, diseño, puesta
en práctica, prueba (Validación), integración, y mantenimiento.
El origen del término “cascada” se cita a menudo para ser un artículo
publicado adentro 1970 por Winston W. Royce (1929-1995), Royce presentaba este
modelo como ejemplo de un modelo dañado, non-working (Royce
1970).
Es (un proceso para la creación del software) en que el desarrollo
se considera como fluyendo constantemente hacia abajo (como a cascada) con las fases de análisis de requisitos, diseño, puesta
en práctica, prueba (Validación), integración, y mantenimiento.
El origen del término “cascada” se cita a menudo para ser un artículo
publicado adentro 1970 por Winston W. Royce (1929-1995), Royce presentaba este
modelo como ejemplo de un modelo dañado, non-working (Royce
1970).
Historia del modelo de la cascada
En Royce 1970
propuesto qué se refiere actualmente como el modelo de la cascada como concepto
inicial, un modelo que él discutió era dañado (Royce 1970). Su papel exploró cómo el
modelo inicial se podría desarrollar en un modelo iterativo, con la
regeneración a partir de cada fase que influenciaba fases subsecuentes.
Es solamente
el modelo inicial que recibió el aviso; su propia crítica de este modelo
inicial se ha no hecho caso en gran parte. La frase “modelo de la cascada” vino
rápidamente referirse no a Royce final, diseño iterativo, sino algo a su modelo
puramente secuencialmente pedido. Este artículo utiliza el significado
popular de la frase “modelo de la cascada”. Para un similar modelo
iterativo a la visión final de Royce.
A pesar de las
intenciones de Royce para que el modelo de la cascada sea modificado en un
modelo iterativo, el uso del modelo de la cascada como proceso puramente
secuencial sigue siendo popular, y, para alguno, la frase “modelo de la
cascada” tiene puesto que venido referir a cualesquiera acérquese a la creación
del software que se considera como inflexible y non-iterative. Los que utilizan
la frase “modelo de la cascada” pejoratively ven generalmente el modelo de la
cascada como ingenuo e inadecuado para un proceso iterativo.
Este Método es el más básico de todos
los modelos y ha servido como bloque de construcción para los demás paradigmas
de ciclo de vida. Está basado en el ciclo convencional de una ingeniería y su
visión es muy simple: el desarrollo de software se debe realizar siguiendo una
secuencia de fases.
Cada etapa tiene un conjunto de metas
bien definidas y las actividades dentro de cada una contribuyen a la
satisfacción de metas de esa fase o quizás a una sub secuencia de metas de la
misma. El arquetipo del ciclo de vida abarca las siguientes actividades:
1.
Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor, el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y
luego asignando algún subconjunto de estos requisitos al software.
2.
Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica
especialmente en el software. El ingeniero de software debe comprender el
ámbito de la información del software así como la función, el rendimiento y las
interfaces requeridas.
3.
Diseño: el diseño del
software se enfoca en cuatro atributos distintos del programa; la estructura de
los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño traduce los requisitos en
una representación del software con la calidad requerida antes de que comience
la codificación.
4.
Codificación: el diseño debe traducirse en una forma legible para la máquina. Si el
diseño se realiza de una manera detallada, la codificación puede realizarse
mecánicamente.
5.
Prueba: una vez que se ha
generado el código comienza la prueba del programa. La prueba se centra en la
lógica interna del software y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se
requieren.
6.
Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los
cambios ocurrirán debidos a que se haya encontrado errores, a que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos) o a que el cliente requiera ampliaciones funcionales o del
rendimiento.
Características
- Es el más utilizado.
- Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios.
- Para que el proyecto tenga éxito deben desarrollarse todas las fases.
- Las fases continúan hasta que los objetivos se han cumplido.
- Si se cambia el orden de las fases, el producto final será de inferior calidad.
Ventajas
-Se tiene todo bien organizado y no se mezclan las fases.
Es
perfecto para proyectos que son rígidos, y además donde se especifiquen muy
bien los requerimientos y se conozca muy bien la herramienta a utilizar
- La planificación es sencilla.
- La planificación es sencilla.
- La calidad del producto resultante es alta.
- Permite trabajar con personal poco cualificado.
Desventaja
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera.
- No refleja realmente el proceso de desarrollo del software
--Se tarda mucho tiempo en pasar por todo el ciclo
- Perpetúa el fracaso de la industria del software en
su comunicación con el
usuario final.
- El mantenimiento se realiza en el código fuente
- Las revisiones de proyectos de gran complejidad son
muy difíciles
- Impone una estructura de gestión de proyectos
Modelo en Espiral
El Modelo en espiral, propuesto originalmente por BOEHM en 1976, es un
modelo de proceso de software evolutivo donde se conjuga la naturaleza de
construcción de prototipos con los aspectos controlados y sistemáticos del
MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido
de versiones incrementales del software que no se basa en fases claramente
definidas y separadas para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.
EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.
HISTORIA
El creador del modelo en espiral fue Barry
Boehm quien recibió su grado de B.A. de Harvard en 1957, y sus grados de M.S. y
de Ph.D. de UCLA en 1961 y 1964, todo en matemáticas.
Barry Boehm era un Programador-Analista en General Dynamics entre 1955 y 1959, sus intereses actuales de la investigación incluyen modelar de proceso del software, ingeniería de requisitos del software, las arquitecturas del software, métrica del software y los modelos del coste, los ambientes de la tecnología de dotación lógica, y tecnología de dotación lógica basada en el conocimiento.
El modelo
espiral tuvo varias modificaciones que son:
- Modelo Original de Boehm.
- Modelo Típico de Seis Regiones.
- Modelo WINWIN.
MODELO ORIGINAL DE BOEHM
No hay un número definido de iteraciones. Las
iteraciones debe decidirlas el equipo de gestión de proyecto
Cada vuelta se divide en 4 sectores:
- Planeación : determinación de los objetivos, alternativas y restricciones
- Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
- Ingeniería : desarrollo del producto hasta "el siguiente nivel".
- Evaluación : valoración por parte del cliente de los resultados obtenidos.
El movimiento de la espiral, ampliando con
cada iteración su amplitud radial, indica que cada vez se van construyendo
versiones sucesivas del software, cada vez más completas.
Uno de los puntos más interesantes del
modelo, es la introducción al proceso de desarrollo a las actividades de
análisis de los riesgos asociados al desarrollo y a la evaluación por parte del
cliente de los resultados del software.
MODELO TIPICO DE SEIS REGIONES
A diferencia del modelo de proceso clásico que termina cuando se entrega
el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la
vida del software de computadora. Una visión alternativa del modelo en espiral
puede ser considerada examinando el eje de punto de entrada en el proyecto.
Las regiones de tareas que componen este modelo son:
- Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
- Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
- Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
- Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
- Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
- Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
MODELO WINWIN
El modelo en espiral WINWIN de Boehm, define un conjunto de actividades
de negociación al principio de casa paso alrededor de la espiral. Más que una
simple actividad de comunicación con el cliente se definen las siguientes
actividades:
- Identificación del sistema o subsistemas clave de los directivos.
- Determinación de las condiciones de victoria de los directivos.
- Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos
de fijación que ayudan a establecer la completitud de un ciclo alrededor del
espiral y proporcionan hitos de decisión antes de continuar el proyecto de
software.
VENTAJAS
- El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
- Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
- El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
- El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
- En la utilización de grandes sistemas a doblado la productividad.
DESVENTAJAS
- Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
- Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
- Genera mucho tiempo en el desarrollo del sistema
- Modelo costoso
- Requiere experiencia en la identificación de riesgos
No hay comentarios:
Publicar un comentario