sábado, 1 de agosto de 2009

MODELO DE CASCADA

Se le llama modelo de cascada porque ordena rigurosamente las etapas del ciclo de la vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior, así cualquier error de diseño que sea detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado.

Modelo en Cascada




El mas 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
- Análisis de Sistemas de Computación
- Diseño
- Codificación
- Prueba
- Implantación
- Mantenimiento


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 algun subconjunto de estos requisitos al software.

2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN

Se lleva a cabo teniendo den cuenta ciertos principios:
- Debe presentarse y entenderse el dominio de la información de un problema.
*-* Defina las funciones que debe realizar el Software.
*-* Represente el comportamiendo del Software a consecuencias de acontecimientos externos.
*-* Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento.Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe cubrir.

3.- DISEÑO

Traduce los requisitos en una representacion del Software con la calidad requerida antes de que comience la codificación.
*-* Diseño del sistema: Se descompone y organiza el sistema en elementos que pueda elaborarse por separado, aprovechando los ventajas del desarrollo en equipo, así como la manera en que se combinan unos con otros.
*-*Diseño del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

4.- CODIFICACIÓN

El diseño debe traducirse en una forma legible para la maquina. Se implementa el código fuente. Dependiendo del lenguaje de programacion y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucha más rápido.

5.- PRUEBA

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre errores de programacion ( o “bugs” ) y defectos de forma. en un defecto de forma, el programa no realiza lo que el usuario espera.

Por el contrario, un error de programación puede describirse como un fallo en la semántica de un rpograma de ordenador. A la versión del producto de pruebas y que es anterior a la versión final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing ( Release To Market ), dónde se comprueba cada funcionalidad del programa completo en entornos de producción.

6.- IMPLANTACIÓN

El Software obtenido se pone en producción. Se implantan los niveles Software y Hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto. Durante la explotación del sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar. Todo ello recoge en los Documentos de Cambios.

7.- 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.

VENTAJAS

*-* Se tiene todo bien organizado y no se mezclan las fases.
*-* Es perfecto para proyectos que son rigidos.
*-* Ideal para proyectos donde se especifiquen muy bien los requerimientos.
*-* Ideal para proyectos en que se conozca muy bien la herramienta a utilizar.
*-* Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software.

DESVENTAJAS

*-* Difícilmente un cliente va a establecer al principio todos los requerimientos necesaríos, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
*-* Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado.

No hay comentarios:

Publicar un comentario en la entrada