Ciclos de vida del software1. Ciclos de vida en cascada El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniera. Es el primero de los propuestos y el ms ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados as). Ordena rigurosamente las etapas del ciclo de vida del software Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa.Despus de cada etapa se realiza una revisin para comprobar si se puede pasar a la siguiente. Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo diferente gracias a la documentacin generada entre las fases. Los documentos son: Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document Documento de Requisitos del software). Anlisis de Requisitos del Sistema. Anlisis de Requisitos del Software. Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document Documento de Plan del software) Diseo Preliminar. Diseo Detallado. Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen tambin pruebas de unidad. Pruebas: A partir de los mdulos probados se realiza la integracin y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar. Mantenimiento: Se realizan constantemente al detectarse alguna falla en el sistema o para mejorarlo incluyendo algn nuevo modulo al mismo.1.1. Ventajas La planificacin es sencilla. La calidad del producto resultante es alta. Permite trabajar con personal poco calificado. Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados. Es mejor que no seguir ningn ciclo de vida.1.2. Desventajas Es difcil obtener todos los requisitos al comienzo. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas. Si se han cometido errores en una fase es difcil volver atrs. Al cambiar alguna de las etapas se debe revisar todas las etapas subsiguientes. Es comparativamente ms lento que los dems y el coste es mayor tambin. Se tarda mucho en disponer del software. No se tiene el producto hasta el final, esto quiere decir que: Si se comete un error en la fase de anlisis no lo descubrimos hasta la entrega, con el consiguiente gasto intil de recursos. El cliente no ver resultados hasta el final, con lo que puede impacientarse. No se tienen indicadores fiables del progreso del trabajo (sndrome del 90%). El mantenimiento se realiza en el cdigo fuente Impone una estructura de gestin de proyectos1.3. Tipos de proyectos para los que es adecuado Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniera. Se est desarrollando un tipo de producto que no es novedoso. Proyectos complejos que se entienden bien desde el principio. 1.4. Diseo grafico del ciclo de vidaAnlisisDiseoCodificacinPruebasMantenimientoFigura 2.1: Ciclo de vida en cascada

2.-PROTOTIPOA menudo, se define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptacin de un sistema operativo, o de la forma en que debera tomarse la interaccin hombre mquina.2.1. CaractersticasEl desarrollo y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las areas Escuchar al Cliente: El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es obligatoria ms definicin.

Construir/Revisar la maqueta: Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseo rpido lleva a la construccin de un prototipo.

El Cliente Prueba la maqueta: El prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.2.2 Ventajas Ayuda a identificar los requisitos del software. Hace el software amigable al usuario. El cliente estar seguro de que el producto final reflejara lo que l desea.2.3. Desventajas Primera versin de un producto es construido con poca funcionalidad y poca fiabilidad. El cliente ve lo que parece ser una versin de trabajo del software, y piensa que el trabajo esta hecho. Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es ms inteligente, y construir una versin rediseada en la que se resuelvan estos problemas2.4. Diferencia entre Prototipo y Producto FinalLa diferencia entre prototipo y producto final es que el prototipo es eficiente y el producto final debe serlo y, que en el prototipo no estn todos los detalles y, el producto final debe contenerlos.Clases de prototipos: Vertical: no recoge todas las funciones del sistema final.Horizontal: recoge todas las funciones, pero no las desarrolla por completo

4.5. Diseo grafico del ciclo de vida:Figura 2.4 Paradigma de construccin de Prototipos.

3.- EspiralPropuesto originalmente por Boehm en 1988, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo cascada (clsico). Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.

3.1. CaractersticasEl modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. La Figura 2.3 representa un modelo en espiral que contiene seis regiones de tareas: ms sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto.

El coste y la planificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para completar el software. Comunicacin con el cliente- Establecer comunicacin entre desarrollador y cliente planificacin- Definir recursos, el tiempo y otra informacin relacionadas con el proyecto. anlisis de riesgos- evaluar riesgos tcnicos y de gestin. ingeniera- las tareas requeridas para construir una o ms representaciones de la aplicacin. construccin y accin- construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentacin y prctica) evaluacin del cliente- las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.

Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, tambin se verifica que funciona correctamente. El propio cliente evala el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo. 3.2. Ventajas No necesita una definicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el final de la primera iteracin es ms fcil validar los requisitos. El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn bien). El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos. 3.3. Desventajas Es difcil evaluar los riesgos. Necesita de la participacin continua por parte del cliente. Cuando se subcontrata hay que producir previamente una especificacin completa de lo que se necesita, y esto lleva tiempo. 3.4. Dnde es adecuado Sistemas de gran tamao. Proyectos donde sea importante el factor riesgo. Cuando no sea posible definir al principio todos los requisitos. 3.5 Diseo Grafico del ciclo de vida Espiral

4.- Tcnicas de 4ta generacin:Facilitan al ingeniero del software la especificacin de algunas caractersticas del software a alto nivel. Luego, la herramienta genera automticamente el cdigo fuente basndose en la especificacin del tcnico.

Cada vez parece ms evidente que cuanto mayor sea el nivel en el que se especifique el software, ms rpido se podr construir el programa.

El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones grficas que describa el problema que hay que resolver en trminos que los entienda el cliente.

Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas: Lenguajes no procedimentales de consulta a bases de datos, Generacin de informes, Manejo de datos, Interaccin y definicin de pantallas, Generacin de cdigos, Capacidades grficas de alto nivel, Capacidades de hoja de clculo, Generacin automatizada de HTML y lenguajes similares utilizados para la creacin de sitios web usando herramientas de software avanzado.

Al igual que otros paradigmas, T4G comienza con el paso de reunin de requisitos. Por esta razn, el dilogo cliente-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.Las tcnicas de cuarta generacin ya se han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes el paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.

5.-Proceso Unificado de desarrollo de softwareCasos de uso: Los casos de uso son las funciones que proporciona un sistema para aadir valor a sus usuarios es un medio para capturar requisitos funcionales.5.1. Principales caractersticas 1. Dirigido por los casos de uso: El proceso de trabajo sigue un hilo de trabajo que parte de los casos de uso. Los casos de uso guan el proceso y se desarrollan a la vez que la arquitectura del sistema y la arquitectura del sistema influye en la seleccin de los casos de uso, la arquitectura del sistema y los casos de uso maduran segn avanza el ciclo de desarrollo.1. Centrado en la arquitectura: La arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro los casos de uso y la arquitectura deben evolucionar en paralelo debe disearse para permitir que el sistema evolucione1. Iterativo e incremental: Cada miniproyecto es una iteracin que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto las iteraciones deben estar controladas deben seleccionarse y ejecutarse de una forma planificada por lo que son miniproyectos.

5.2. Fases dentro de un ciclo Fase inicio: Es una descripcin del producto final a partir de una buena idea y se presenta el anlisis de negocio para el producto Fase de elaboracin: Especifica en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema. Se crea la lnea base de la arquitectura. Fase de construccin: Se construye el producto.Aqui la lnea base de la arquitectura crece hasta convertirse en el sistema completo y preparado para ser entregado a los usuarios. Fase de transicin: Cubre el periodo durante el cual el producto se convierte en versin beta. Un nmero reducido de usuarios y con experiencia prueba el producto e informa de defectos y deficiencias.

5.3 Flujos de trabajo Modelo de casos de uso: Con todos los casos de uso y su relacin con los usuarios. Modelo de anlisis: Con dos propsitos: refinar los casos de uso con ms detalle y establecer la asignacin inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento. Modelo de diseo: Define:a) La estructura esttica del sistema en la forma de subsistemas, clases e interfaces yb) Los casos de uso reflejados como colaboraciones entre los subsistemas, clases, e interfaces. Modelo de implementacin: Incluye componentes y la correspondencia de las clases con los componentes. Incluye un modelo de despliegue que define los nodos fsicos (ordenadores) y la correspondencia de los componentes con esos nodos. Modelo de prueba: Que describe los casos de prueba que verifican los casos de uso y por supuesto una representacin de la arquitectura.El sistema tambin debe tener un modelo del dominio o modelo del negocio que describa el contexto del negocio en el que se halla el sistema.Todos estos modelos estn relacionados. Juntos representan al sistema como un todo.

5.4 Las cuatro Ps1. Proyecto: Elemento organizativo a travs del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versin de un producto.1. Proceso: conjunto de actividades necesarias para transformar los requisitos de usuario en un producto. Un proceso es una plantilla para crear proyectos.1. Persona: Los principales autores de un proyecto software son los arquitectos, desarrolladores, ingenieros de prueba, y el personal que les da soporte, adems de los usuarios, clientes, y otros interesados. Las personas son realmente seres humanos a diferencia del trmino abstracto trabajadores.1. Producto: Artefactos que se crean durante la vida del proyecto, como los modelos, cdigo fuente, ejecutables y documentacin.5.5 Participantes. Convirtiendo recursos en trabajadores:Un tipo de trabajador es un papel que un individuo puede desempear en el desarrollo de software como puede ser un especificador de casos de uso, un arquitecto, un ingeniero de componentes, o un ingeniero de pruebas de integracin.El termino rol se emplea para hablar de los papeles que cumple un trabajador. Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades en el desarrollo de software.

5.6 Relaciones entre modelos:Un sistema contiene todas las relaciones y restricciones entre elementos incluidos en diferentes modelos. Por tanto un sistema no es solo la coleccin de sus modelos sino que contiene tambin las restricciones entre ellos.

5.7 Las actividades relacionadas conforman flujos de trabajoUn flujo de trabajo es un conjunto de actividades. El proceso unificado se basa en una amplia experiencia para encontrar el conjunto factible de artefactos y trabajadores.

En trminos de UML un flujo de trabajo es un estereotipo de colaboracin, en el cual los trabajadores y los artefactos son los participantes.

5.8 Ventajas1. De fcil comprensin para el equipo de desarrollo1. Fcil control de cambios 1. Se obtiene un modelado visual del software 1. Verificacin de la calidad del software1. Totalmente organizado.1. Los desarrolladores, los supervisores y directores pueden cambiar de proyecto o de divisin sin tener que aprender un nuevo proceso1. El desarrollo del software es repetible puede planificarse y estimarse en coste con suficiente exactitud como para cumplir las expectativas.5.9 Desventajas1. Si el grupo que desarrolla el proyecto no llega a un estndar de codificacin se produce entropa.1. Si no se realiza la documentacin apropiada se produce entropa en el grupo que desarrolla el proyecto.

6.-RAD (Desarrollo de aplicacin)

El Desarrollo Rpido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptacin a alta velocidaddel modelo lineal secuencial en el que se logra el desarrollo rpido utilizando una construccin basada en componentes.

6.1 Caracteristicas

Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de perodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque DRA comprende las siguientes fases:

Modelado de Gestin. El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera?Quin la genera? A dnde va la informacin? Quin la procesa?

Modelado de datos. El flujo de informacin definido como parte de la fase de modelado de gestin se refinacomo un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos

Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos.

Generacin de aplicaciones. El DRA asume la utilizacin de tcnicas de cuarta generacin En lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construccin del software.

Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos delos componentes de los programas. Esto reduce tiempo pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

6.2 Ventajas

El DRA hace un fuerte uso de componentes reutilizables.Obviamente, las limitaciones de tiempo impuestas en un proyecto DRA demandan mbito en escalas. Si una aplicacin de gestin puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA.

Cada una de las funciones pueden ser afrontadas por un equipo DRA separado y ser integradas en un solo conjunto.

6.3 Desventajas

Para proyectos grandes aunque por escalas, requiere recursos humanos suficientes como para crear el nmero correcto de equipos.

Requiere clientes y desarrolladores comprometidos en las rpidas actividades necesarias para completar un sistema en un marco de tiempo abreviado.

Aplicaciones no apropiadasSi un sistema no se puede modularizar adecuadamente, la construccin de los componentes necesarios Si est en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistemasNo es adecuado cuando los riesgos tcnicos son altos.

FIGURA 2.6. El modelo DRA.

7.- Win WinEl modelo en espiral sugiere una actividad del marco de trabajo que aborda la comunicacin con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar.

Desgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociacin, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o caractersticas del sistema frente al coste y al tiempo de comercializacin.

La obtencin de requisitos del software requiere una negociacin. Tiene xito cuando ambas partes ganan.Las mejores negociaciones se esfuerzan en obtener' victoria-victoria. El cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.

Adems del nfasis realizado en la negociacin inicial, el modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral.

El primer punto de fijacin, llamado objetivos del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de ingeniera del software. El segundo punto de fijacin, llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema. La capacidad operativa inicial (COI) es el tercer punto de fijacin y representa un conjunto de objetivos asociados a la preparacin del software para la instalacin/distribucin, preparacin del lugar previamente a la instalacin, y la asistencia precisada de todas las partes que utilizar o mantendr el software.

8.1 Diseo grafico

Figura 2.7. El modelo en espiral WINWIN.

8.-IncrementalEn este caso se va creando el sistema aadiendo pequeas funcionalidades. Cada uno de los pequeos incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento, en el sentido de aumentar mdulos. Combina elementos del modelo cascada (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos. Por un lado est el anlisis y el diseo global. Por otra parte estn los pequeos incrementos, con las fases de diseo detallado, codificacin y mantenimiento. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El modelo incremental entrega el software en partes pequeas, pero utilizables, llamadas ((incrementos).En general, cada incremento se construye sobre aqul que ya ha sido entregado. El primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin detallada). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.El modelo de proceso incremental, como la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza.El modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin.8.1. Ventajas No es necesario tener todos los requisitos en un principio. Entrega un producto operacional con cada incremento. til cuando la dotacin de personal no est disponible para una implementacin completa en la fecha lmite que se haya establecido para el proyecto Los primeros incrementos se pueden implementar con menos personas y proporcionan al usuario una plataforma para la evaluacin.8.2. Desventajas Los errores en la deteccin de requisitos se encuentran tarde. Cada incremento no es el producto final, sino mas bien un producto q se acerca cada vez mas a serlo, el incremento n ser el producto final.

8.3 Diseo grafico9.-FrameworkEn el desarrollo de software, un framework es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Tpicamente, un framework puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto.9.1. Arquitectura Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador => Modelo => Vista) ya que debemos fragmentar nuestra programacin. Tenemos que contemplar estos aspectos bsicos en cuanto a la implementacin de nuestro sistema: Controlador: Con este apartado podemos controlar el acceso (incluso todo) a nuestra aplicacin, esto pueden ser: archivos, scripts... programas; cualquier tipo de informacin que permita la interfaz. As, podremos diversificar nuestro contenido de forma dinmica, y esttica (a la vez); pues, solo debemos controlar ciertos aspectos (como se ha mencionado antes). Modelo: Este miembro del controlador maneja las operaciones lgicas, y de manejo de informacin (previamente enviada por su ancestro) para resultar de una forma explicable, y sin titubeos. Cada miembro debe ser meticulosamente llamado, en su correcto nombre y en principio, con su verdadera naturaleza: el manejo de informacin, su complementacin directa. Vista: Al final, a este miembro de la familia le corresponde dibujar, o expresar la ltima forma de los datos: la interfaz grfica que interacta con el usuario final del programa (GUI). Despus de todo, a este miembro le toca evidenciar la informacin obtenida hasta hacerla llegar con el controlador. Solo (e inicialmente), nos espera demostrar la informacin.10.- SASHIMINEn este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseo se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentacin de rodajas de pescado crudo en Japn. Las fases de este ciclo de vida son: Concepto.- consiste en definir los objetivos del proyecto, beneficios, tipo de tecnologa y el tipo de ciclo de vida. Anlisis.- Se analiza los requerimientos y se busca una solucin optima. El diseo arquitectnico.- es el de alto nivel. El diseo detallado.- es el de bajo nivel. Codificacin.- Se implementa el cdigo del proyecto Pruebas.- Se prueba si el proyecto funciona correctamente es decir sin entropa.10.1 Ventajas Una ventaja de este modelo es que no necesita generar tanta documentacin como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. 10.2 Inconvenientes Es an ms difcil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro. Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir inconsistencias.10.3 Diseo grafico

Figure 1.4: Ciclo de vida sashimi

11. Recursivo paralelo (Orientado a Objetos - OO)

Hoy en da el paradigma OO encierra una completa visin de la ingeniera del software. Edward Berard declara: Los beneficios de la tecnologa orientada a objetos se fortalecen si se usa antes y durante el proceso de ingeniera del software. Esta tecnologa orientada a objetos considerada debe hacer sentir su impacto en todo el proceso de ingeniera del software.

Un simple uso de programacin orientada a objetos (POO) no brindar los mejores resultados. Los ingenieros del software y sus directores deben considerar tales elementos: El anlisis de requisitos orientado a objetos (AROO), El diseo orientado a objetos (DOO), El anlisis del dominio orientado a objetos (ADOO), Sistemas de gestin de bases de datos orientadas a objetos (SGBDOO) y La ingeniera del software orientada a objetos assistida por comutadora (ISOOAC).

Los sistemas OO utilizan un modelo de ingeniera mediante proceso evolutivo. Ms adelante, en este mismo captulo, nos referiremos a l como el modelo recursivo paralelo.

El proceso OO se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es aqu donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base para el plan del proyecto OO. El trabajo tcnico asociado con la ingeniera del software OO sigue el camino iterativo. La ingeniera del software OO hace hincapi en la reutilizacin. Por lo tanto, las clases se buscan en una biblioteca (de clases O0 existentes) antes de construirse. Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de software aplica anlisis orientado a objetos (AOO), diseo orientado a objetos (DOO), programacin orientada a objetos (POO) y pruebas orientadas a objetos (PROO) para crear la clase y los objetos derivados de la clase. La nueva clase se pone en la biblioteca de tal manera que pueda ser reutilizada en el futuro.

11.1. Ventajas

Fomenta el ensamblaje (reutilizacin) de componentes es el mejor paradigma para ingeniera del software OO.

11.2. Desventajas Ser extremadamente difcil definir las clases necesarias para un gran sistema o producto en una sola iteracin. La visin orientada a objetos demanda un enfoque evolutivo de la ingeniera del software.

11.4 Diseo grafico

Figura 2.6 El modelo de proceso OO.12. EL MODELO RUP (Proceso Unificado de Rational)El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP.

Esfuerzo en actividades segn fase del proyecto.Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura.En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura.En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones.Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto.En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.