MODELO CASCADA Y MODELO V

2010

MODELO EN CASCADA Y MODELO EN V Metodologías para el Desarrollo de Proyectos Informáticos PUBLICADO PUBLICADO EN: http://www.calameo.com/bo http://www.calameo.com/books/000359039f05c oks/000359039f05cc9907e95 c9907e95

MARGARITA VARGAS CHACÓN UNEMI 30/07/2010

ADMINISTRACIÓN DE PROYECTOS UNIVERSIDAD ESTATAL DE MILAGRO

Modelo en Cascada y Modelo en V Margarita Vargas Chacón

MODELO EN CASCADA El modelo en cascada es una de las primeras metodologías que han sido propuestas para el desarrollo de proyectos informáticos, establecido por Winston Royce en 1970. El tratamiento de este proceso se considera como fluyendo constantemente hacia abajo (como una cascada); en este modelo se debe seguir un riguroso orden de todas las etapas que conforman el ciclo de vida de un proyecto de software Fig.1 (El Modelo de Cascada); donde cada una de las fases debe completarse antes de iniciar la siguiente, manteniendo un estricto control sobre cada etapa. De esta manera cuando todos los requisitos del cliente han sido detallados, analizados para comprobar su integridad y consistencia, y documentados, recién entonces el equipo de desarrollo del proyecto puede seguir con las actividades del diseño del sistema. Este modelo nos muestra una visión muy clara de cómo suceden las etapas dentro de su tratamiento, sugiriendo a los desarrolladores la secuencia de eventos que pueden encontrar en cada una de las etapas. ETAPAS DEL MODELO: El ciclo de vida de software está conformado por las siguientes actividades: 1. 2. 3. 4. 5. 6.

Ingeniería y Análisis del Sistema Análisis de los Requisitos del Software Diseño Codificación Prueba Aplicación y Mantenimiento

Ingeniería y Análisis del Sistema.- En esta fase se realiza un análisis global de todas las necesidades de los usuarios finales del sistema informático, para detallar los objetivos que el software desempeñara. Luego se redacta el Documento de Especificación de Requisitos conocido también como SDR; en la elaboración de este documento se debe plasmar los resultados del análisis en forma de contrato, con los requisitos que la aplicación informática deberá cumplir. El SDR debe lograr tres objetivos en mente: 1. Describir lo que requiere el usuario. 2. Establecer una base para la creación de un diseño de software. 3. Definir un conjunto de requisitos que se puedan validar una vez que se ha construido el software. Considerando previamente estos objetivos planteados, se logran establecer las bases para un buen diseño de sistemas. También es importante señalar que en esta fase se debe consensuar todo lo que se requiere del sistema informático, ya que esto servirá de base para las siguientes etapas, sin poder requerir nuevos resultados a mitad del proceso de elaboración del software. Análisis de los Requisitos del Software.- Su enfoque principalmente se centra e intensifica en detallar los requerimientos del software, se debe comprender el ámbito de la información del software, así como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Diseño.- El diseño del software se descompone y organiza el sistema en elementos que pueden elaborarse por separado, enfocándose en estos cuatro atributos: 1. 2. 3. 4.

La estructura de los datos, La arquitectura del software, El detalle de los procedimientos y La determinación de la interfaz.

Como resultado se obtiene el SDD o Documento de Diseño del Software, en el cual se describe el modelo relacional global del sistema, la función de cada una de sus partes y así como también se adjunta la interactividad que existe en cada una de ellas.



Logrando traducir los requisitos en una representación del software con la calidad que se requiere antes de que se dé inicio a la etapa de la codificación; es decir que el diseño del sistema no es más que una plataforma para la eficacia de un código de programación. La fase de diseño conduce a una salida para la próxima fase es decir, declaraciones formales obligatorias que es la codificación. Codificación.- Esta es la fase de la programación, en donde se implementará el código fuente dependiendo del lenguaje de programación que se vaya a utilizar, es decir en esta etapa las especificaciones del sistema se convierten en un lenguaje legible para la máquina y así construir el software. Según el lenguaje de programación y la versión que se utilice se podrá hacer uso de componentes reutilizables inmersos en el mismo proyecto que harán que el proceso de la codificación sea mucho más rápido. Prueba.- Este proceso consta de la elaboración de pruebas que nos sirven para comprobar si el software cumple con todos los requerimientos que se deseaba obtener, estas pruebas o evaluaciones están centradas netamente en la lógica del software; es decir, verificar su correcto funcionamiento, y validar todas las respuestas que se obtengan; si están de acuerdo con lo que se quería alcanzar. Aplicación y Mantenimiento.- Una vez terminada la fase de prueba se procede a implementar el sistema; es decir a la utilización del software por parte del usuario. También se debe tener en cuenta que el sistema sufrirá cambios al realizar la entrega al cliente. Los cambios sucederán debido a que el cliente haya encontrado posibles errores, a que el sistema deberá adaptarse a distintos cambios del entorno externo, o si el cliente desea implementar nuevas funcionalidades al sistema informático, por lo que es necesario un realizar un mantenimiento. VENTAJAS: •

•

•

•

Este modelo se basa en procesos sencillos e intuitivos fáciles de seguir a la hora de desarrollar el sistema. Provee seguridad en los requerimientos. Es ideal para proyectos rígidos, donde se especifiquen claramente los requerimientos concretos a utilizar y se conozca perfectamente la herramienta de aplicación. Es un modelo compresible para los usuarios.

DESVENTAJAS: • •

•

•

•

•

Es un modelo muy rígido. Es muy difícil para el cliente detallar todos los requerimientos que se desea obtener del sistema, por lo que hay un nivel muy alto de riesgos. En la práctica, difícilmente un proyecto sigue una estricta secuencia lineal, razón por la cual el proyecto tiene una mala implementación. La etapa de creación del proyecto necesita mucho tiempo, ya que primero se debe pasar por el proceso de prueba. El cliente debe ser paciente; la fase de operación se cumple a finales de las etapas del modelo. Los cambios establecidos en una etapa madura del proceso pueden ocasionar confusión a los desarrolladores del sistema, y sus consecuencias pueden ser desastrosas. MODELO EN V

Este paradigma nace de la evolución del modelo en cascada, implementando un proceso interactivo entre las distintas etapas que lo comprenden, donde se puede detallar la relación que existe entre las actividades de prueba, análisis y diseño del software.



Al estudiar su proceso podemos observar que sus primeras fases son similares al método cascada, teniendo como punto intermedio la etapa de la implementación de programas y prueba unitaria (que forma la punta de la V, véase Figura 2. Modelo en V) y las que lo complementan son las encargadas de la realización de pruebas e integrarse a cada una de las de la mitad anterior. Este modelo tiene la funcionalidad de poder hacer la a documentación para las pruebas que se realizarán posteriormente; opción que resulta muy favorable para los desarrolladores del sistema ya que así lograrán definir precisos detalles al momento de la codificación; en otras palabras funciona igual que el mecanismo análogo usado en clase al dar un examen, es muncho más fácil si antes de evaluar se proporciona un cuestionario con temas similares de los que tratará la prueba. Este mecanismo interactivo de verificación y validación en el diseño del software optimiza en un grado considerable la capacidad e aceptar el producto resultante. La verificación se fundamenta en demostrar si el producto se está construyendo correctamente. La validación certifica que el producto cumple con las exigencias detalladas por el cliente. Las pruebas que el modelo implementa son las siguientes: Prueba unitaria y de aceptación: En esta prueba los encargados de realizar el proyecto de software deberán asegurar que todos los requerimientos del programa han sido implementados de forma correcta en el proceso de la codificación, Prueba del sistema: Los desarrolladores en esta evaluación deben verificar el correcto funcionamiento del sistema informático, certificando que todos los aspectos analizados en el código estén efectuados correctamente. Prueba de aceptación: En esta última prueba interviene el cliente, mas no el desarrollador; valida los requerimientos asociando un paso de prueba con cada elemento de la especificación; con este tipo de prueba se puede verificar si todos los requisitos se han implementado por completo, antes de que el software será aceptado y pagado. VENTAJAS: • •

•

El modelo en V hace más explicita la tarea parte de la iteración de las actividades del proceso. Las pruebas de cada fase ayudaran a corregir posibles errores sin tener que esperar a que sean rectificados en la etapa final del proceso. Con las pruebas unitarias y de integración se consigue obtener exactitud en los programas.

DESVENTAJAS: •

Al encontrarse errores luego de realizar las pruebas se pierde tiempo y dinero, ya que cada prueba se realiza luego de haber terminado la implementación.

CONCLUSIÓN: Los dos modelos tienen sus respectivas ventajas y desventajas al momento de implementar un proyecto de software. El paradigma en cascada nos ofrece un desarrollo más estable y lineal, poniendo a los procesos en exactitud y actividad, mientras que el modelo en V es una mejora de el modelo cascada, ubicándolo en un nivel superior, ya que nos permite interactuar con las diferentes actividades haciendo el proceso más dinámico, y con la opción de realizar pruebas que nos ayudarán a corregir posibles errores durante su fase de desarrollo, implementando también el rehacer tareas que están ocultas en la representación de la cascada, ventajas realmente notables que lo convierten en un modelo más completo y robusto que nos ayudará a obtener un sistema de mejor calidad.

ADMINISTRACIÓN DE PROYECTOS UNIVERSIDAD ESTATAL DE MILAGRO ANEXOS:

Figura 1. El modelo en Cascada

Figura 2. El modelo en V




FUENTES CONSULTADAS:

SHARI LAWRENCE PFLEEGER, INGENIERÍA DE SOFTWARE TEORÍA Y PRÁCTICA http://es.wikipedia.org/wiki/Desarrollo_en_cascada http://www.worldlingo.com/ma/enwiki/es/Waterfall_model http://es.wikipedia.org/wiki/Software http://www.compute-rs.com/es/consejos-352291.htm http://www.biblioteca.co.cr/pdf/unidad12-4.pdf http://www.carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc http://caraujo334.blogspot.es/1192584300/

MODELO CASCADA Y MODELO V

Recommend Documents