Embed Size (px)
Citation preview
Modelo de cascada 2010
1
INGENIERIA DE SOFTWARE
INVESTIGACION DE
MODELO DE CASCADA
INTEGRATES:
LILIANA CHAMBI
IVER MENDEZ CHAMBI
Modelo de cascada 2010
2
Introducción
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.
• Se popularizó en la década de los 70 y guía la mayor parte de la práctica
actual.
• El proceso es una “cascada” de fases, donde el producto de una fase es
la entrada de la siguiente.
• Cada fase se compone de una serie de actividades que deben realizarse
en paralelo.
Existen variantes del modelo básico de cascada, pero todas comparten la
misma filosofía.
Aplicación del Modelo de Cascada
• Se sigue una secuencia lineal de etapas.
• Las empresas establecen los productos y documentos que deben
producirse en cada etapa.
• Estos productos y/o documentos permiten seguir el avance del proyecto.
• También se establece qué métodos aplicar en cada etapa.
Estos métodos se organizan en forma coherente en lo que es la “metodología
de desarrollo de la empresa.
Variaciones al Modelo de Cascada
• Sistemas de áreas conocidas pueden omitir el análisis de factibilidad.
• 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.
Modelo de cascada 2010
3
• Un sistema con usuarios no especialistas puede requerir una etapa de
entrenamiento y preparación de material de apoyo.
Ciclo de vida del software
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.
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.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
Desarrollo en cascada
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
Modelo de cascada 2010
4
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.
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.
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.
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 algún subconjunto de estos requisitos al software.
Análisis de Requisitos
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.
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.
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),
Modelo de cascada 2010
5
que contiene la especificación completa de lo que debe hacer el sistema
sin entrar en detalles internos.
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.
Diseño del Sistema
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.
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.
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.
Codificación
Modelo de cascada 2010
6
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.
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.
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.
Pruebas
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.
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.
Las empresas pueden establecer estándares de pruebas:
– definición de un plan de pruebas,
– criterios de pruebas (caja negra, caja blanca),
– criterios de fin de las pruebas,
– administración de los casos de prueba.
• La depuración (“debugging”) es parte de esta etapa.
• Es el control de calidad llevado a cabo en esta etapa.
• Inspecciones para comprobar adhesión a los estándares.
Existen varios tipos de Pruebas:
Pruebas de unidad.- ver que cada componente del programa cumpla
con las especificaciones
Pruebas de integración.- se integra los componentes y se prueba el
funcionamiento del sw.
Modelo de cascada 2010
7
Pruebas de sistema.- Se prueban rendimiento y seguridades.
Pruebas de aceptación.- los hace el cliente y el usuario para estar
seguros que el sw cumple con las necesidades.
Mantenimiento
El software necesitará cambios después de la entrega.
El análisis de requisitos es una fuente de problemas, especialmente para
los usuarios finales:
los requisitos son difíciles de especificar,
los requisitos cambian con el tiempo.
Muchos errores no son resueltos hasta después de instalar el software en
el cliente:
es más caro corregir errores cuanto más tarde se detectan.
Los cambios son (casi) siempre posibles pero también (casi) siempre muy
difíciles
El mantenimiento son todas las actividades que ocurren después que el
software está instalado:
corregir errores,
agregar nueva funcionalidad.
Los tipos de mantenimiento son:
Mantenimiento Preventivo y Perfectivo
Mantenimiento Correctivo
Mantenimiento Evolutivo
Ventajas del modelo de cascada
1. Modelo y planificación fácil y sencilla.
2. Sus fases son conocidas por los desarrolladores.
3. Los usuarios lo pueden comprender fácilmente
Modelo de cascada 2010
8
Desventajas:
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.
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.
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.
La ventaja de este método radica en su sencillez ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.
Críticas al Modelo de Cascada
El modelo de Cascada tiene dos grandes aportes:
debe aplicarse disciplina, planificación y administración al proceso
de desarrollo de software,
la construcción del sistema en sí se pospone hasta que los
objetivos del sistema sean suficientemente comprendidos.
Pero tiene también serias desventajas:
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.
La verdad es que estas cosas raramente suceden: el desarrollo
comienza con requisitos incompletos, los errores y contratiempos
hacen (casi) volver a empezar.
Modelo de cascada 2010
9
rígido.- Cada etapa se termina completamente antes de comenzar
la siguiente.
Así, los requisitos están completos antes del diseño y el cliente no
participa más hasta la instalación del sistema completo.
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.
monolítico.- Se planifica el ciclo de vida de desarrollo para
entregar el sistema completo en una fecha dada.
El cliente no tiene adelantos del progreso del sistema.
Los desarrolladores construyen el sistema basados en los
requisitos originales.
Los errores sólo se detectan después de instalado el sistema.
