634365673100INGENIERIA DE SOFTWARE<br />INVESTIGACION DE MODELO DE CASCADA<br />INTEGRATES:<br />LILIANA CHAMBI<br />IVER MENDEZ CHAMBI<br />Introducción<br />En ingeniería de software el desarrollo en cascada también llamado modelo en cascada es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software.<br />Se popularizó en la década de los 70 y guía la mayor parte de la práctica actual.<br />El proceso es una “cascada” de fases, donde el producto de una fase es la entrada de la siguiente.<br />Cada fase se compone de una serie de actividades que deben realizarse en paralelo.<br />Existen variantes del modelo básico de cascada, pero todas comparten la misma filosofía.<br />Aplicación del Modelo de Cascada<br />Se sigue una secuencia lineal de etapas.<br />Las empresas establecen los productos y documentos que deben producirse en cada etapa.<br />Estos productos y/o documentos permiten seguir el avance del proyecto.<br />También se establece qué métodos aplicar en cada etapa.<br />Estos métodos se organizan en forma coherente en lo que es la “metodología de desarrollo de la empresa.<br />Variaciones al Modelo de Cascada<br />Sistemas de áreas conocidas pueden omitir el análisis de factibilidad.<br />Sistemas complejos y/o grandes requieren dividir su desarrollo en porciones más pequeñas que puedan desarrollarse en forma más controlada y rigurosa.<br />Un sistema con usuarios no especialistas puede requerir una etapa de entrenamiento y preparación de material de apoyo.<br />Ciclo de vida del software<br />El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados. <br />Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados. <br />El ciclo de vida básico de un software consta de los siguientes procedimientos:<br />Desarrollo en cascada<br />Ingeniería y Análisis del SistemaAnálisis de los RequisitosDiseñoCodificaciónPruebaMantenimiento<br />Esta metodología elegida, de modelo en cascada, facilita una planificación sencilla. Podemos pasar por alto detalles concretos y después, en una nueva planificación, llevarlos a cabo. En nuestro caso, en una primera instancia nos ocupamos del funcionamiento básico de un CRM y más tarde, abordamos los aspectos más avanzados, como el módulo de inteligencia. <br />La calidad de este tipo de proyectos es muy alta dado que una vez terminada una versión puede mejorarse e incluso rediseñarse para que su funcionamiento sea más eficiente, fundamentalmente en las fases de interacción con el usuario del sistema y en la estructura del árbol de decisión. <br />Además, esta metodología estuvo bastante acertada, pues los requisitos no los tuvimos completados hasta casi la fase final. Además, dado el carácter del proyecto, principalmente descriptivo, no nos resultó muy traumático en el momento de hacer los cambios en la implementación. <br />Ingeniería y Análisis del Sistema<br />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 algún subconjunto de estos requisitos al software. <br />Análisis de Requisitos<br />el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.<br />El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. <br />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 especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. <br />Es importante señalar 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 pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software. <br />Diseño del Sistema <br />Se 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 Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. <br />Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación. <br />Diseño del Programa <br />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.<br />Codificación<br />Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. <br />El diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.<br />Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido. <br />Pruebas <br />Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. <br />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 puesto en funcionamiento.<br />Las empresas pueden establecer estándares de pruebas:<br />definición de un plan de pruebas,<br />criterios de pruebas (caja negra, caja blanca),<br />criterios de fin de las pruebas,<br />administración de los casos de prueba.<br />La depuración (“debugging”) es parte de esta etapa.<br />Es el control de calidad llevado a cabo en esta etapa.<br />Inspecciones para comprobar adhesión a los estándares.<br />Existen varios tipos de Pruebas: <br /> Pruebas de unidad.- ver que cada componente del programa cumpla con las especificaciones<br /> Pruebas de integración.- se integra los componentes y se prueba el funcionamiento del sw.<br /> Pruebas de sistema.- Se prueban rendimiento y seguridades.<br /> Pruebas de aceptación.- los hace el cliente y el usuario para estar seguros que el sw cumple con las necesidades.<br />Mantenimiento<br />El software necesitará cambios después de la entrega.<br />El análisis de requisitos es una fuente de problemas, especialmente para los usuarios finales:<br />los requisitos son difíciles de especificar,<br />los requisitos cambian con el tiempo.<br />Muchos errores no son resueltos hasta después de instalar el software en el cliente:<br />es más caro corregir errores cuanto más tarde se detectan.<br />Los cambios son (casi) siempre posibles pero también (casi) siempre muy difíciles<br />El mantenimiento son todas las actividades que ocurren después que el software está instalado:<br />corregir errores,<br />agregar nueva funcionalidad.<br />Los tipos de mantenimiento son:<br /> Mantenimiento Preventivo y Perfectivo<br /> Mantenimiento Correctivo <br /> Mantenimiento Evolutivo <br />Ventajas del modelo de cascada<br />1. Modelo y planificación fácil y sencilla.<br />2. Sus fases son conocidas por los desarrolladores.<br />3. Los usuarios lo pueden comprender fácilmente<br />Desventajas:<br />Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.<br />Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.<br />El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.<br />La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.<br />Críticas al Modelo de Cascada<br />El modelo de Cascada tiene dos grandes aportes:<br />debe aplicarse disciplina, planificación y administración al proceso de desarrollo de software,<br />la construcción del sistema en sí se pospone hasta que los objetivos del sistema sean suficientemente comprendidos.<br />Pero tiene también serias desventajas:<br />Lineal.- Un modelo lineal supone que todos los requisitos están disponibles, el diseño elegido es el más apropiado, la programación ocurre sin contratiempos, los errores encontrados son fácilmente corregidos.<br />La verdad es que estas cosas raramente suceden: el desarrollo comienza con requisitos incompletos, los errores y contratiempos hacen (casi) volver a empezar.<br />rígido.- Cada etapa se termina completamente antes de comenzar la siguiente.<br />Así, los requisitos están completos antes del diseño y el cliente no participa más hasta la instalación del sistema completo.<br />Si algunas personas terminan su tarea de una etapa antes que los demás, deberán esperar a que todos terminen para comenzar la siguiente etapa.<br />monolítico.- Se planifica el ciclo de vida de desarrollo para entregar el sistema completo en una fecha dada.<br />El cliente no tiene adelantos del progreso del sistema.<br />Los desarrolladores construyen el sistema basados en los requisitos originales.<br />Los errores sólo se detectan después de instalado el sistema.<br />