1. DESARROLLODEAPLICACIONESWEB ESCUELA POLITÉCNICA DEL
EJÉRCITO
Carrera De Ingeniería En Sistemas
Desarrollo de Aplicaciones Web.
Ñauñay Jorge.
Andrade Gabriela.
Bravo Paulo.
CICLO DE VIDA TRADICIONAL
MODELO CASCADA
SEPTIMO NIVEL
05 DE MAYO DEL 2013
3. CICLO DE VIDA TRADICIONAL DEL SISTEMA
MODELO CASCADA
Especificar conceptos, elementos, diagramas UML, herramientas, procesos principales
de cada fase.
Introducción.
En los años 70 se impuso un nuevo enfoque de desarrollo del software, introducido por
Royce en 1970, a través de un ciclo de vida en “cascada” (así denominado por la
disposición de las distintas fases de desarrollo, en las que los resultados de una fase
parecen caer en cascada hacia la siguiente fase, tal como se muestra en la Figura 1). El
método ideado por Royce constituye uno de los primeros modelos de ciclo de vida
publicados, por lo que también recibe el nombre de modelo de ciclo de vida clásico. Este
método modela el ciclo convencional de la Ingeniería del Software, aplicando un enfoque
sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y
progresa a través de requisitos, análisis de requisitos, diseño, construcción,
implementación y mantenimiento.
Ventajas:
• Es un modelo sencillo y disciplinado.
• Es fácil aprender a utilizarlo y comprender su funcionamiento.
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de
cada etapa.
• Ha sido muy usado y, por tanto, está ampliamente contrastado.
Ingeniería y Análisis del
Sistema (REQUISITOS)
Análisis de los
Requisitos
Diseño
Construcción
Implementación
Mantenimiento
4. • Ayuda a detectar errores en las primeras etapas a bajo costo.
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas
Desventajas:
• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el
ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio.
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida.
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber
un gran componente iterativo.
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar
correcciones.
• El producto final obtenido puede que no refleje todos los requisitos del usuario.
Desarrollo del tema.
Requisitos.
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.
5. 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.
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.
Procesos Principales
I. Se analiza y clarifican los diferentes aspectos del problema que debe ser
resuelto por la aplicación con el fin de establecer claramente que debe ser
construido.
Análisis de Requisitos.
Es el proceso de recopilación de los requisitos se centra e intensifica
especialmente en el software. 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.
Diagramas uml
Diagrama de casos de uso: Un caso de uso es la típica interacción entre un usuario
y un sistema informático.
Diagramas de secuencia: Se los realiza en las fases de análisis de requisitos y
diseño para razonar en más detalle como es el comportamiento de un escenario,
también para detectar cuáles son los métodos de las clases, al observar cómo se
relacionan los objetos entre sí.
Diagramas de colaboración: Si se desea más detalle del sistema a desarrollar en
esta fase se puede utilizar los diagramas de colaboración.
6. Herramientas para diagramas.
Start uml
Rational Rouse
OMT
PowerDisigner
Procesos Principales
I. Se realiza un documento de requisitos de software que especifica claramente
las funcionalidades de la aplicación.
II. Funcionalidad = lo que tiene que hacer.
III. Funcionalidad ≠ como tiene que hacer.
Diseño.
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.
Diagramas UML
Diagramas de secuencia: Se los realiza en las fases de análisis de requisitos y
diseño para razonar en más detalle como es el comportamiento de un escenario,
también para detectar cuáles son los métodos de las clases, al observar cómo se
relacionan los objetos entre sí.
7. Diagrama de clases y objetos: las clases se pueden representar de tres formas sin
detalle, detalles a nivel de análisis y diseño, detalle a nivel de implementación.
Herramientas para diagramas.
Start uml
Rational Rouse
OMT
PowerDisigner
Procesos Principales
I. Se decide la organización y la estructura de la aplicación que satisfaga los
diferentes requisitos establecidos en la fase de análisis.
II. Se tiene como resultado uno o varios documentos de diseño que se
especifican claramente cómo es que se debe construir la aplicación.
III. En el análisis se ocupa de que hay que hacer en el diseño se ocupa de
cómo hacerlo.
Construcción.
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.
8. Diagramas UML
Diagrama de actividades: en situaciones donde todos o la mayoría de los eventos
representan la totalidad de acciones generadas internamente (es decir
procedimientos de control de flujo).
Diagrama de Estados: Los diagramas de estados muestran la secuencia de estados
por los que pasa un objeto durante su vida y que se corresponden con los
estímulos recibidos, junto con sus respuestas y acciones, cada diagrama de
estados se corresponde con una clase o con un método.
Herramientas para diagramas.
Start uml
Rational Rouse
OMT
PowerDisigner
9. Procesos Principales
I. Se construye la aplicación un lenguaje de programación correcto,
y siguiendo para ello las directrices marcadas por los
documentos de diseño.
II. El diseño caracteriza el artefacto a construir de forma
independiente de lenguajes, de herramientas de desarrollo, etc.
Implementación.
Aquí se implementa el código fuente, haciendo uso de prototipos así como
pruebas y ensayos para corregir errores.
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.
Diagramas UML
Diagrama de implementación: Los diagramas de implementación como su
propio nombre indica representan aspectos relativos a la implementación
incluyendo la estructura del código fuente y otras características propias
del tiempo de ejecución.
UML tiene dos tipos de diagramas de implementación:
a) Diagramas de Componentes: Muestran la estructura del código
fuente.
b) Diagramas Desplegables (Deployment Diagrams): Muestran la
estructura del sistema en tiempo de ejecución.
Herramientas para diagramas.
Start uml
Rational Rouse
10. OMT
PowerDisigner
Procesos Principales
I. Se verifica que la aplicación construida satisfaga los requerimientos del
usuario.
II. Dos pasos importantes:
Verificación: ¿Se ajusta la aplicación construida a los requisitos
establecidos?
Validación: ¿Resuelve la aplicación el problemas que realmente
tenía el usuario?
Mantenimiento.
Una de las etapas más críticas, 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.
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.
Diagramas UML
Se utiliza diagramas de secuencia para ver el funcionamiento del sistema y si se desea
realizar algún cambio.
Diagramas de secuencia: Se los realiza en las fases de análisis de requisitos y
diseño para razonar en más detalle como es el comportamiento de un escenario,
también para detectar cuáles son los métodos de las clases, al observar cómo se
relacionan los objetos entre sí.
Herramientas para diagramas.
Start uml
Rational Rouse
OMT
PowerDisigner
Procesos Principales
I. Esta es una de las actividades más costosas en el desarrollo del software.
II. En esta fase se modifica la aplicación para satisfacer cambios o
ampliaciones en los requisitos del usuario, corregir errores, etc.