Historia del modelo de cascada
En 1970 Royce propuso lo que actualmente se conoce como el modelo de cascada
como un concepto inicial, un modelo que según él era defectuoso ( Royce, 1970 ).
En 1970 Royce propuso lo que actualmente se conoce como el modelo de cascada
como un concepto inicial, un modelo que según él era defectuoso ( Royce, 1970 ).
Su trabajo explora cómo el modelo inicial podría ser convertido en un modelo interactivo, con comentarios de cada fase de influir en las fases posteriores. Es sólo el modelo inicial que recibió la notificación, su propia crítica de este modelo inicial se ha ignorado en gran medida. La expresión "modelo de cascada" rápidamente llegó a referirse no a la final de Royce, el diseño interactivo, sino más bien a su modelo puramente un orden
secuencial.
secuencial.
En este artículo se utiliza el sentido popular de la frase "cascada" del modelo. Para un modelo iterativo similar al final de la visión de Royce. A pesar de Royce intenciones para el modelo de cascada que ser modificado en un modelo interactivo, el uso del modelo de cascada como una secuencia proceso puramente sigue siendo popular, y, para algunos, la expresión "modelo de cascada" ha llegado a referirse a cualquier acercamiento al software creación que es visto como inflexible y no repetitivo. Aquellos que usan la frase "modelo de cascada" peyorativamente para modelos no-iterativo que por lo general no les gusta ver el modelo
en cascada a sí misma como ingenua e inadecuada para un proceso iterativo.
en cascada a sí misma como ingenua e inadecuada para un proceso iterativo.
El modelo
Sin modificar el "modelo de cascada". El progreso se deriva de la parte superior
hasta el fondo, como una cascada.
Sin modificar el "modelo de cascada". El progreso se deriva de la parte superior
hasta el fondo, como una cascada.
En cascada de Royce modelo original, las siguientes fases se siguen en este orden:
1. Requisitos de la especificación
2. Diseño
3. Construcción (también conocido como aplicación o codificación)
4. Integración
5. Pruebas y depuración (validación AKA)
6. Instalación
7. Mantenimiento
Para seguir el modelo de cascada, se procede de una fase a la siguiente en una manera puramente secuencial. Por ejemplo, primero se completa especificación de requisitos, que son inamovibles. Si las condiciones son totalmente terminado, se procede al diseño. El software en cuestión es un proyecto diseñado y es elaborado para los ejecutores (codificadores) para seguir - este diseño debe ser un plan para la aplicación de los requisitos establecidos. Cuando el diseño se haya completado, una puesta en práctica de ese diseño es hecho por los programadores. Hacia las últimas etapas de esta fase de ejecución, los componentes de software dispares producidas por diferentes equipos están integrados.
1. Requisitos de la especificación
2. Diseño
3. Construcción (también conocido como aplicación o codificación)
4. Integración
5. Pruebas y depuración (validación AKA)
6. Instalación
7. Mantenimiento
Para seguir el modelo de cascada, se procede de una fase a la siguiente en una manera puramente secuencial. Por ejemplo, primero se completa especificación de requisitos, que son inamovibles. Si las condiciones son totalmente terminado, se procede al diseño. El software en cuestión es un proyecto diseñado y es elaborado para los ejecutores (codificadores) para seguir - este diseño debe ser un plan para la aplicación de los requisitos establecidos. Cuando el diseño se haya completado, una puesta en práctica de ese diseño es hecho por los programadores. Hacia las últimas etapas de esta fase de ejecución, los componentes de software dispares producidas por diferentes equipos están integrados.
Después de la integración de las fases de ejecución y se completa, el producto de software ha sido probado y depurado, los defectos introducidos en las fases anteriores se eliminan aquí. Entonces el producto de software está instalado, y más tarde mantuvo introducir nuevas funcionalidades y corrigiendo
errores.
Así, el modelo de cascada sostiene que se debe pasar a una fase sólo cuando la fase anterior se ha completado y perfeccionado. Fases de desarrollo en el modelo de cascada son discretas, y no hay saltos hacia atrás y adelante o se superponen entre ellos. Sin embargo, hay varios modelos de cascada modificada (incluyendo modelo final de Royce) que puede incluir o grandes variaciones en este proceso.
errores.
Así, el modelo de cascada sostiene que se debe pasar a una fase sólo cuando la fase anterior se ha completado y perfeccionado. Fases de desarrollo en el modelo de cascada son discretas, y no hay saltos hacia atrás y adelante o se superponen entre ellos. Sin embargo, hay varios modelos de cascada modificada (incluyendo modelo final de Royce) que puede incluir o grandes variaciones en este proceso.
Uso
El modelo de cascada es ampliamente utilizado por ejemplo de desarrollo desoftware grandes casas como los empleados por el Departamento de Defensa deEE.UU. y la NASA , y para muchos proyectos gubernamentales de gran tamaño (ver" el modelo estándar de cascada "en el Internet Archive ). Los que utilizan esosmétodos no siempre formalmente distinguir entre el modelo de cascada pura y losdiferentes modelos de cascada modificada, por lo que puede ser difícil de discernirexactamente qué modelos se están utilizando y en qué medida.
Argumentos a favor del modelo de cascada
El tiempo pasado desde el principio en la producción de software puede dar lugara una mayor economía más tarde en el ciclo de vida del software, es decir, se hademostrado muchas veces que un error que se encuentran en las primeras etapas delciclo de vida de producción (como la especificación de requisitos o de diseño) es másbarato , en términos de dinero, esfuerzo y tiempo, para fijar que el mismo error que se encuentran más adelante en el proceso. ([McConnell, 1996], p. 72, estima que "undefecto de requisitos que no se detecta hasta que la construcción o el mantenimiento va a costar 50 a 200 veces más que fijar, ya que habría costado en el momento de fijar los requisitos.")
Para tomar un ejemplo extremo, si el diseño del programa resulta ser imposible de aplicar, es más fácil de arreglar el diseño en la fase de diseño que darse cuenta de meses más tarde, cuando los componentes del programa se han integrado, que todo el trabajo hecho hasta ahora tiene que ser desechado debido a un diseño roto.
Esta es la idea central detrás de Gran Diseño En la delantera (BDUF) y el modelo de cascada - el tiempo pasado desde el principio asegurándose de que los requisitos y el diseño son absolutamente correcta le ahorrará mucho tiempo y esfuerzo más tarde. Por lo tanto, el pensamiento de aquellos que siguen el proceso en cascada se va, hay que asegurarse de que cada fase es de 100% completa y correcta absolutamente antes de proceder a la siguiente fase de la creación del programa. Los requisitos del programa debe ser escrito en piedra antes de diseño se inicia (de lo contrario el trabajo puesto en un diseño basado en los requisitos correctos se pierde), programa de diseño debe ser perfecto para que la gente comenzará a trabajar en la aplicación del diseño (de lo contrario, están implementando el mal diseño y sus el trabajo se pierde), etc
Un argumento más para el modelo de cascada es que pone énfasis en la documentación (por ejemplo, documentos de requisitos y documentos de diseño), así como el código fuente . En diseñado y documentado metodologías menos, los miembros del equipo debe salir, el conocimiento se pierde y puede ser difícil para un proyecto de recuperación.
En caso de un diseño de documento de trabajo completose presente (como es la intención de Gran Diseño En la parte delantera y el modelo decascada) los miembros del equipo nuevo o incluso totalmente nuevos equipos deben ser capaces de familiarizarse con la lectura de los documentos.
Además de lo anterior, algunos prefieren el modelo de cascada para su y podría decirse que un enfoque más disciplinado simple. En lugar de lo que el adherente cascada ve como un caos, el modelo de cascada proporciona un enfoque estructurado, el modelo en sí mismo progresa linealmente a través de, fácilmente comprensible y explicable fases discretas y por lo tanto es fácil de entender, sino que también proporciona fácil hitos notable en el proceso de desarrollo. Es quizás por esta razón que el modelo de cascada se utiliza como un ejemplo a partir de un modelo de desarrollo en muchos textos de ingeniería de software y cursos.
Se argumenta que el modelo de cascada y Diseño Big Up Front en general puede ser adecuada para los proyectos de software que son estables (en especial los proyectos con los requisitos que no cambia, como software de plástico retráctil) y donde es posible y probable que los diseñadores podrán plenamente a predecir las áreas problemáticas del sistema y producir un diseño correcto antes de su ejecución se ha iniciado. El modelo de cascada también requiere que los implementadores seguir el bien hecho, el diseño completo de precisión, asegurando que la integración de los ingresos del sistema sin problemas.
La crítica del modelo de cascada
El modelo de cascada se sostiene por muchos como una mala idea en la práctica, principalmente debido a su creencia de que es imposible, para cualquier trivial proyecto no, para obtener la primera fase del programa de productos de ciclo de vida de un perfeccionado antes de pasar a las siguientes fases y aprender de ellos.
Por ejemplo, los clientes no pueden saber exactamente cuáles son los requisitos que quieren antes de ver un prototipo de trabajo y puede comentar sobre ella, ya que pueden cambiar sus necesidades constantemente, y los diseñadores y ejecutores del programa puede tener poco control sobre esto. Si los clientes cambiar sus necesidades después de un diseño está terminado, que el diseño debe ser modificado para dar cabida a las nuevas exigencias, invalidando toda una gran cantidad de esfuerzo si grandes cantidades demasiado tiempo se han invertido en gran diseño en la delantera.
Los diseñadores pueden no ser conscientes de las dificultades de aplicación futura al escribir un diseño para un producto de software sin aplicarse. Es decir, puede quedar en evidencia en la fase de ejecución que un área particular de la funcionalidad del programa es extraordinariamente difícil de aplicar. Si este es el caso, es mejor revisar el diseño que de persistir en el uso de un diseño que se hizo con base en las predicciones defectuosa y que no tiene en cuenta el problema de las zonas descubiertas recientemente. Steve McConnell en el código completo (un libro que critica el uso generalizado del modelo de cascada) se refiere al diseño como un " problema perverso "- un problema cuyas necesidades y limitaciones no puede ser totalmente conocido antes densu finalización. La implicación de esto es que es imposible para perfeccionar una fase de desarrollo de software, por lo tanto es imposible si se utiliza el modelo de cascada "para pasar a la siguiente fase.
David Parnas, en "Un proceso de diseño racional: ¿Cómo y por qué es falso", escribe:
"Muchos de [sistema] Detalles de la única a ser conocido por nosotros a medida que avanzamos en el [sistema] de la aplicación. Algunas de las cosas que aprendemos invalidar nuestro diseño y que debe dar marcha atrás. "
"Muchos de [sistema] Detalles de la única a ser conocido por nosotros a medida que avanzamos en el [sistema] de la aplicación. Algunas de las cosas que aprendemos invalidar nuestro diseño y que debe dar marcha atrás. "
La idea detrás del modelo de cascada se puede "medir dos veces, cortar una vez", y quienes se oponen al modelo de cascada argumentan que esta idea tiende a desmoronarse cuando el problema que se está midiendo cambia constantemente debido a la exigencia de modificaciones y nuevas realizaciones sobre el problema en sí.
Críticas adicionales de un enfoque de desarrollo iterativo-no (como el modelo decascada) incluyen:
· A menos que los que especifican los requisitos y las personas que diseñan el sistema de software en cuestión son muy competentes, es difícil saberexactamente lo que se necesita en cada fase del proceso de software antes dealgún tiempo se gasta en la fase que le sigue. Es decir, la retroalimentación delas siguientes fases que se necesita para completar las fases anteriores de manerasatisfactoria.
Por ejemplo, la fase de diseño puede ser necesario la retroalimentación de la fase de implementación para identificar áreas con problemas de diseño. El contra-argumento a favor del modelo de cascada es que los diseñadores experimentados pueden haber trabajado en sistemas similares antes, y así puede ser capaz de predecir con precisión las áreas problemáticas, sin tiempo de creación de prototipos e implementación.
· prueba constante desde el diseño, implementación y verificación necesarios para validar las fases que preceden ellos. prototipo de trabajo de diseño constante es necesaria para garantizar que los requisitos no son contradictorias y posibles de cumplir, la aplicación constante es necesaria para encontrar áreas de problema e informar el proceso de diseño; constante de integración y verificación del código de práctica es necesario garantizar que la aplicación sigue en marcha .
· prueba constante desde el diseño, implementación y verificación necesarios para validar las fases que preceden ellos. prototipo de trabajo de diseño constante es necesaria para garantizar que los requisitos no son contradictorias y posibles de cumplir, la aplicación constante es necesaria para encontrar áreas de problema e informar el proceso de diseño; constante de integración y verificación del código de práctica es necesario garantizar que la aplicación sigue en marcha .
El contraargumento a favor del modelo de cascada aquí es que la aplicación constante y pruebas para validar el diseño y los requisitos sólo es necesario si la introducción de errores es probable que sea un problema. Los usuarios del modelo de cascada puede argumentar que si los diseñadores (etcétera) siguen un proceso disciplinado y no cometer errores que no hay necesidad de un trabajo constante en las fases posteriores para validar las fases anteriores.
· Frecuentes incrementales (después de la "libertad anticipada, la liberación a menudo" la filosofía) a menudo son necesarios para construir la confianza de un equipo de producción de software y su cliente.
· Es difícil estimar el tiempo y el costo para cada fase del proceso de desarrollo sin hacer un "reconocimiento" de trabajo en esta fase, a menos que la estimación de tiempo y el costo son de gran experiencia con el tipo de producto software en cuestión.
· El modelo de cascada no trae ningún medio formal de ejercer el control sobre un proyecto de gestión y control de la planificación y gestión de riesgos no están cubiertos dentro del propio modelo.
· Muy conjunto de habilidades específicas necesarias para cada fase, por lo tanto
no es un requisito para varios proyectos para ejecutar en orden a optimizar el uso e los recursos si todos los miembros de la estancia en el transcurso de un determinado proyecto, o de sufrir los niveles mediante el uson de "hombre orquesta "los recursos a través de cada etapa.
· Frecuentes incrementales (después de la "libertad anticipada, la liberación a menudo" la filosofía) a menudo son necesarios para construir la confianza de un equipo de producción de software y su cliente.
· Es difícil estimar el tiempo y el costo para cada fase del proceso de desarrollo sin hacer un "reconocimiento" de trabajo en esta fase, a menos que la estimación de tiempo y el costo son de gran experiencia con el tipo de producto software en cuestión.
· El modelo de cascada no trae ningún medio formal de ejercer el control sobre un proyecto de gestión y control de la planificación y gestión de riesgos no están cubiertos dentro del propio modelo.
· Muy conjunto de habilidades específicas necesarias para cada fase, por lo tanto
no es un requisito para varios proyectos para ejecutar en orden a optimizar el uso e los recursos si todos los miembros de la estancia en el transcurso de un determinado proyecto, o de sufrir los niveles mediante el uson de "hombre orquesta "los recursos a través de cada etapa.
Modelos Modificados de Cascada
En respuesta a los problemas percibidos con el modelo de cascada pura, muchos modelos modificados cascada se han introducido. Estos modelos pueden abordar algunas o todas de las críticas del modelo de cascada pura. Muchos modelos están cubiertos por Steve McConnell en la "planificación del ciclo de vida", capítulo de su libro Desarrollo Rápido: fierecilla salvaje Software Listas. Si bien todos los modelos de desarrollo de software se guardan alguna similitud con el modelo de cascada, como todos los modelos de desarrollo de software se incorporar al menos algunas fases similares a las utilizadas en el modelo de cascada, en esta sección se ocupará de los más cercanos al modelo de cascada. Para los modelos que se aplican otras diferencias con el modelo de cascada, o radicalmente diferentes modelos buscar información general sobre el proceso de desarrollo de software .
En respuesta a los problemas percibidos con el modelo de cascada pura, muchos modelos modificados cascada se han introducido. Estos modelos pueden abordar algunas o todas de las críticas del modelo de cascada pura. Muchos modelos están cubiertos por Steve McConnell en la "planificación del ciclo de vida", capítulo de su libro Desarrollo Rápido: fierecilla salvaje Software Listas. Si bien todos los modelos de desarrollo de software se guardan alguna similitud con el modelo de cascada, como todos los modelos de desarrollo de software se incorporar al menos algunas fases similares a las utilizadas en el modelo de cascada, en esta sección se ocupará de los más cercanos al modelo de cascada. Para los modelos que se aplican otras diferencias con el modelo de cascada, o radicalmente diferentes modelos buscar información general sobre el proceso de desarrollo de software .
El modelo Sashimi
El modelo de sashimi (llamado así porque cuenta con fases superpuestas, como los peces japoneses superposición de sashimi ) fue creado por Peter Degrace . A veces es referido como el "modelo de cascada con la superposición de fases" o "el modelo de cascada con retroalimentación".
Desde las fases en el modelo de sashimi se superponen, la información de los puntos problemáticos se puede actuar en las fases que normalmente, en el modelo de cascada pura, preceder a otros. Por ejemplo, desde la aplicación y fases de diseño se solaparán en el modelo de sashimi, los problemas de aplicación se pueden descubrir durante la fase de diseño e implementación de la procesos.
Ese desarrollo ayuda a aliviar muchos de los problemas relacionados con el diseño de Big Up filosofía frontal de la cascada modelo.
El modelo de sashimi (llamado así porque cuenta con fases superpuestas, como los peces japoneses superposición de sashimi ) fue creado por Peter Degrace . A veces es referido como el "modelo de cascada con la superposición de fases" o "el modelo de cascada con retroalimentación".
Desde las fases en el modelo de sashimi se superponen, la información de los puntos problemáticos se puede actuar en las fases que normalmente, en el modelo de cascada pura, preceder a otros. Por ejemplo, desde la aplicación y fases de diseño se solaparán en el modelo de sashimi, los problemas de aplicación se pueden descubrir durante la fase de diseño e implementación de la procesos.
Ese desarrollo ayuda a aliviar muchos de los problemas relacionados con el diseño de Big Up filosofía frontal de la cascada modelo.
Modelo en Cascada Bennington 1956:
El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:
· 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.
· 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 (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.
· 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.
· Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.
· 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.
· Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
Ingeniería y Análisis del Sistema
Análisis de los Requisitos
Diseño
Codificación
Prueba
Mantenimiento
El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:
· 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.
· 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 (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.
· 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.
· Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.
· 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.
· Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
Ingeniería y Análisis del Sistema
Análisis de los Requisitos
Diseño
Codificación
Prueba
Mantenimiento
Desventajas:
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo,siempre hay iteraciones y se crean problemas en la aplicación del paradigma. Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivosnecesarios a la hora de desarrollar el software.
Modelo V (Ministerio de Defensa de Alemania, 1992:
El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución del mismo.
Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior.
ANALISIS DE DISEÑO DE LA IMPLEMENTACION DE PROGRAMAS Y PRUEBAS DE OPERACION.
Plan de Pruebas de Integración
Verificar diseño
Plan de Pruebas del Sistema Validar requerimientos
Plan de Pruebas de Aceptación
Los planes de rueba son el nexo entre el desarrollo y la verificación.
Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.
Desventajas:
El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.
El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.
Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclosEl modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.
de desarrollo, lo que disminuye el riesgo.
A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.
