Los modelos de actividades de ingeniera tienen el fin de establecer algo de orden en el desarrollo de grandes productos de software.

Consiste en diferentes etapas, las cuales son procesadas en diferentes maneras, Comparndolos con otros modelos de desarrollo de software en los que algunos suelen ser mucho ms rgidos y mejor administrables. El modelo cascada es un modelo de ingeniera diseado para ser aplicado en el desarrollo de software. La idea principal es la siguiente: existen diferentes etapas de desarrollo, la salida de la primera etapa fluye hacia la segunda etapa y esta salida fluye hacia la tercera y as sucesivamente. Tambin existen sub-etapas, dentro de cada etapa, pero stas difieren mucho de un proyecto a otro. Tambin es posible que ciertos proyectos de software requieran la incorporacin de una etapa extra o la separacin de una etapa en otras dos. Sin embargo, todas estas variaciones al modelo cascada poseen el mismo concepto bsico: la idea de que una etapa provee salidas que sern usadas como las entradas de la siguiente etapa (un flujo lineal entre las etapas). Por lo tanto, el progreso del proceso de desarrollo de un producto de software, usando el modelo cascada, es simple de conocer y controlar. Existen actividades que son llevadas a cabo en cada una de las etapas del desarrollo del software. stas son documentacin, verificacin y administracin. La documentacin es intrnseca al modelo cascada puesto que la mayora de las salidas que arrojan las etapas son documentos. El ciclo de vida clsico es el paradigma ms viejo y el ms ampliamente usado en la ingeniera del software. Sin embargo, su aplicabilidad en muchos campos ha sido cuestionada. Dos de las crticas que se hacan al modelo de ciclo de vida en cascada eran que es difcil tener claros todos los requisitos del sistema al inicio del proyecto, y que no se dispone de una versin operativa del programa hasta las fases finales del desarrollo, lo que dificulta la deteccin de errores y deja tambin para el final el descubrimiento de los requisitos inadvertidos en las fases de anlisis. Para paliar estas deficiencias se ha propuesto un modelo de ciclo de vida basado en la construccin de prototipos. En primer lugar, hay que ver si el sistema que tenemos que desarrollar es un buen candidato a utilizar el paradigma de ciclo de vida de construccin de prototipos o al modelo en espiral. En general, cualquier aplicacin que presente mucha interaccin con el usuario, o que necesite algoritmos que puedan construirse de manera evolutiva, yendo de lo mas general a lo ms especfico es una buena candidata. No obstante, hay que tener en cuenta la complejidad: si la aplicacin necesita que se desarrolle una gran cantidad de cdigo para poder tener un prototipo que ensear al usuario, las ventajas de la construccin de prototipos se vern superadas por el esfuerzo de desarrollar un prototipo que al final habr que desechar o modificar mucho. Tambin hay que tener en cuenta la disposicin del cliente para probar un prototipo y sugerir modificaciones de los requisitos. Puede ser que el cliente no tenga tiempo para andar jugando o no vea las ventajas de este mtodo de desarrollo. Tambin es conveniente construir prototipos para probar la eficiencia de los algoritmos que se van a implementar, o para comprobar el rendimiento de un determinado componente del sistema en condiciones similares a las que existirn durante la utilizacin del sistema. Es bastante frecuente que el producto de ingeniera desarrollado presente un buen rendimiento durante la fase de pruebas realizada por los ingenieros antes de entregarlo al cliente pero que sea muy ineficiente, o incluso inviable, a la hora de almacenar o procesar el volumen real de informacin que debe manejar el cliente. En estos casos, la construccin de un prototipo de parte del sistema y la realizacin de pruebas de rendimiento, sirven para decidir, antes de empezar la fase de diseo, cul es el modelo ms adecuado de entre la gama disponible para el soporte hardware o cmo deben hacerse los accesos para obtener buenas respuestas en tiempo cuando la aplicacin est ya en funcionamiento. No obstante, hay que tener en cuenta que el prototipo no es el sistema final, puesto que normalmente apenas es utilizable. Ser demasiado lento, demasiado grande, inadecuado para el volumen de datos necesario, contendr errores (debido al diseo rpido), ser demasiado general (sin considerar casos particulares, que debe tener en cuenta el sistema final) o estar codificado en un lenguaje o para una mquina inadecuadas, o a partir de componentes software previamente existentes. No hay que preocuparse de haber desperdiciado tiempo o esfuerzos construyendo prototipos que luego habrn de ser desechados, si con ello hemos conseguido tener ms clara la especificacin del proyecto, puesto que el tiempo perdido lo ahorraremos en las fases siguientes,

que podrn realizarse con menos esfuerzo y en las que se cometern menos errores que nos obliguen a volver atrs en el ciclo de vida. Uno de los problemas que suelen aparecer siguiendo el paradigma de construccin de prototipos, es que con demasiada frecuencia el prototipo pasa a ser parte del sistema final, bien sea por presiones del cliente, que quiere tener el sistema funcionando lo antes posible o bien porque los tcnicos se han acostumbrado a la mquina, el sistema operativo o el lenguaje con el que se desarroll el prototipo. Se olvida aqu que el prototipo ha sido construido de forma acelerada, sin tener en cuenta consideraciones de eficiencia, calidad del software o facilidad de mantenimiento, o que las elecciones de lenguaje, sistema operativo o mquina para desarrollarlo se han hecho basndose en criterios como el mejor conocimiento de esas herramientas por parte los tcnicos que en que sean adecuadas para el producto final. El utilizar el prototipo en el producto final conduce a que ste contenga numerosos errores latentes, sea ineficiente, poco fiable, incompleto o difcil de mantener. En definitiva a que tenga poca calidad, lo cual deja pensar mucho en qu modelo se ha de usar para la creacin de nuevos programas entre el ciclo de cascada y el ciclo de prototipo o el uso de cualquier otro mtodo se ha de encontrar errores el detalle es tener el menor de ellos para mejorar la calidad del software y eso es precisamente lo que se quiere conseguir aplicando la ingeniera del software.