MODELO EN CASCADA

Se denomina modelo en cascada porque su caracterstica principal es que no se comienza con un paso hasta que no se ha terminado el anterior.

Ingeniera y Anlisis del Sistema .- establece los requisitos de todos los elementos del sistema Anlisis de los requisitos del software.-Se analizan las necesidades de los usuarios

Documento de Especificacin de Requisitos(SDR)

Diseo.-traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin.

Documento de Diseo del Software(SDD)

Codificacin.-diseo debe traducirse en una forma legible para la maquina Prueba.-Se comprueba que funciona correctamente antes de ser puesto en explotacin. Mantenimiento.-Los cambios ocurrirn cuando se hayan encontrado errores,

Ingeniera y Anlisis del Sistema

Anlisis de los requisitos del software

Diseo

Codificacin

Prueba

Mantenimiento

Ventajas

La calidad de este tipo de proyectos es muy alta dado que una vez terminada una versin puede mejorarse e incluso redisearse para que su funcionamiento sea ms eficiente Es de los modelos ms usados ya que es un mtodo intuitivo. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. Un error encontrado en la etapa de pruebas, conduce al rediseo del producto Los primeros resultados se obtienen despus de un tiempo considerable Documentar los resultados de cada actividad

Desventajas

METODO EN ESPIRAL

Es un modelo de proceso de software evolutivo.

En cada giro se construye un nuevo modelo del sistema completo.

Cada bucle o iteracin representa un conjunto de actividades.

El modelo en espiral se divide generalmente entre tres y seis regiones de tareas.

Comunicacin con el cliente: Las tareas que se llevaran a cabo para obtener un buen diseo del software Planificacin: Las tareas requeridas para definir recursos, el tiempo.

Anlisis de riesgos: Las tareas requeridas para evaluar riesgos tcnicos.

Ingeniera: Las tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y adaptacin: Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluacin el cliente: Las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas.

Ventajas El modelo en espiral puede aplicarse a lo largo de la vida del software.

El desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
Modelos evolutivos como el espiral, son apropiados, particularmente para el desarrollo de Sistemas OO.

Desventajas

Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable. Es nuevo y no se ha utilizado tanto como otros modelos de ciclo de vida. Si un riesgo importante no es detectado y gestionado a tiempo, indudablemente surgirn problemas.

Modelo RUP
EL PROCESO UNIFICADO RACIONAL (RUP) ES UN MODELO DE PROCESO MODERNO. PROVIENE DEL TRABAJO EN UML Y EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE.

RUP se describe desde tres perspectivas:

1. Perspectiva Dinmica : Muestra las fases del modelo sobre el tiempo. 2. Perspectiva Esttica : Muestra las actividades del proceso que se representan. 3. Perspectiva Prctica : Sugiere buenas prcticas a utilizar durante el proceso. R.U.P. Perspectivas

RUP es un modelo en fases , que identifica 4 fases diferentes en el proceso del software
La Figura siguiente nos muestra las fases en RUP La Perspectiva Dinmica: Sus Fases

1. Inicio.
El objetivo de esta fase es establecer un caso de negocio para el sistema . Se deben identificar todas las entidades externas ( personas y sistemas ) que interactuarn con el sistema y definir estas interacciones. Esta informacin se utiliza entonces para evaluar qu aporte hace el sistema al negocio . Si este aporte es de poca importancia, se cancela el proyecto.

2. Elaboracin.
Los objetivos de esta fase son: Comprender el dominio del problema Establecer un marco de trabajo arquitectnico para el sistema Desarrollar el plan del proyecto Identificar los riesgos clave del proyecto. Al terminar esta fase, conseguimos un modelo de los requerimientos del sistema (se especifican los casos de uso en UML), una descripcin arquitectnica y un plan de desarrollo del software.

3. Construccin
Esta fase comprende: el Diseo del Sistema , la Programacin las Pruebas . En esta fase se desarrollan e integran las partes del sistema. Al terminarla, tenemos: un Sistema de Software operativo la Documentacin lista para entregar al usuario.

4. Transicin
Fase final del RUP . Mueve el sistema desde la comunidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno real. Esto se deja de lado en la mayor parte de los modelos de procesos del software pero es, en realidad, una actividad de alto costo y problemtica. Al terminar esta fase, tenemos un Sistema de Software Documentado, que funciona correctamente en su entorno operativo.

Otras caractersticas de RUP:

Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio. Reduce el costo del riesgo a los costos de un solo incremento Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo. Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteracin.

Ventajas de RUP
Requiere conocimientos del proceso y de UML. Progreso visible en las etapas tempranas. El uso de Iteraciones (actividades)Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integracin final del sistema Facilita la reutilizacin del cdigo teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual adems permite que se aprecien oportunidades de mejoras en el diseo.

Desventajas de RUP
Por el grado de complejidad puede no resultar muy adecuado. RUP es generalmente mal aplicado en el estilo cascada.

MODELO PROTOTIPO
Este modelo se encarga del desarrollo de diseos para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones. Se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las reas donde es obligatorio ms definicin. Construir y revisar la maqueta (prototipo). El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. Este modelo es til cuando: El cliente no identifica los requisitos detallados. El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombremquina.

Ventajas

Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina

Desventajas

Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de programacin inadecuado. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

MODELO POR ETAPAS

Es similar al Modelo de prototipos, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto

Plan operativo.-se define el problema que resolver. Especificacin de requisitos.- Permite entregar una visin de alto nivel sobre el proyecto.

Especificacin funcional.- Especifica la informacin sobre la cual el software a desarrollar trabajar.

Diseo.-Permite describir como el sistema va a satisfacer los requisitos.

Implementacin.- Aqu es donde el software a ser desarrollado se codifica. Integracin.- Es la fase donde todos los subsistemas codificados independientemente se juntan. Validacin y verificacin.- Es donde es probado para verificar que el sistema es consistente con la definicin de requisitos y la especificacin funcional.

Mantenimiento.-El mantenimiento ocurre cuando existe algn problema dentro de un sistema existente.

Plan operativo
Especificacin de requerimientos Especificacin funcional Diseo
Iteracin

Implementacin

Integracin Validacin y verificacin Mantencin

Cascada
Analisis del sistema Analisis de requisitos Diseo

Espiral

RUP

Prototipo

Etapas

Planeacion Codificacion
Integracion Evaluacion Riesgos Ingenieria