sábado, 5 de febrero de 2011

Modelo Cascada

Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. la palabra cascada sugiere, mediante la metafora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.
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:
- Ingenieria y Análisis del Sistema
- Análisis de los Requisitos
- Diseño
- Codificación
- Prueba
- 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 unproblema.
- 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 represerntan 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 puedad 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.
- Idieal 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