Вы находитесь на странице: 1из 6

En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas

del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.1 Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos. Diseo del Sistema. Diseo del Programa. Codificacin. Pruebas. Implantacin. Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria[cita requerida], sigue siendo el paradigma ms seguido al da de hoy.

Contenido

1 Fases del modelo. o 1.1 Anlisis de requisitos o 1.2 Diseo del Sistema o 1.3 Diseo del Programa o 1.4 Codificacin o 1.5 Pruebas o 1.6 Verificacin o 1.7 Mantenimiento 2 Variantes 3 Desventajas 4 Vase tambin 5 Referencias 6 Enlaces externos

Fases del modelo.

El "modelo cascada" sin modificar. El progreso fluye de arriba haca abajo, como una cascada.

Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software.

Diseo del Sistema


Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin.

Diseo del Programa


Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin.

Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.

Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.

Mantenimiento
Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.

Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin 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. Esto es la base para que funcione bien. Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.

MITECNOLOGICO C:

Este enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalizacin 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 ms avanzadas de un proyecto. Modelo en Cascada: El mas conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades: - Ingenieria y Anlisis del Sistema - Anlisis de los Requisitos - Diseo - Codificacin - Prueba - Mantenimiento 1.- INGENIERA Y ANLISIS 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.- ANLISIS DE SISTEMAS DE COMPUTACIN Se lleva a cabo teniendo den cuenta ciertos principios: - Debe presentarse y entenderse el dominio de la informacin de unproblema. - Defina las funciones que debe realizar el Software. - Represente el comportamiendo del Software a consecuencias de acontecimientos externos. - Divida en forma jerrquica los modelos que represerntan la informacin, funciones y comportamiento. Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe cubrir. 3.- DISEO

Traduce los requisitos en una representacion del Software con la calidad requerida antes de que comience la codificacin. - Diseo 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. - Diseo del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. 4.- CODIFICACIN El diseo debe traducirse en una forma legible para la maquina. Se implementa el cdigo fuente. Dependiendo del lenguaje de programacion y su versin se crean las libreras y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucha ms rpido. 5.- PRUEBA Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotacin. 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 programacin puede describirse como un fallo en la semntica de un rpograma de ordenador. A la versin del producto de pruebas y que es anterior a la versin final ( o master ) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez ms habitual que se realice una fase de RTM testing ( Release To Market ), dnde se comprueba cada funcionalidad del programa completo en entornos de produccin. 6.- IMPLANTACIN El Software obtenido se pone en produccin. Se implantan los niveles Software y Hardware que componen el proyecto. La implantacin es la fase con ms duracin y con ms cambios en el ciclo de elaboracin de un proyecto. Es una de las fases finales del proyecto. Durante la explotacin 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 despus de que se entrega al cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que el Software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), 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: - Difcilmente un cliente va a establecer al principio todos los requerimientos necesaros, 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 recin cuando este est finalizado.

Вам также может понравиться