MODELOS EVOLUTIVOS

Margarita Areas Muoz Elizabeth Medina Morales Karla Adriana Huizar Flores

INTRODUCCIN
El

software, al igual que todos los sistemas complejos, evoluciona con el tiempo. Un modelo de desarrollo es una representacin abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cmo se debe desarrollar el software, sino que establece un enfoque comn.

El modelo lineal secuencial se disea para el desarrollo en lnea recta. En esencia, este enfoque en cascada asume que se va entregar un sistema completo una vez que la secuencia lineal se haya finalizado. El modelo de construccin de prototipos se disea para ayudar al cliente (o al que desarrolla) a comprender los requisitos. En general, no se disea para entregar un sistema de produccin. En ninguno de los paradigmas de ingeniera del software se tiene en cuenta la naturaleza evolutiva del software. Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez ms completas del software.

EL MODELO INCREMETAL

El modelo incremental combina elementos del modelo lineal secuencial con la filosofa interactiva de construccin de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podra extraer funciones de gestin de archivos bsicos y de produccin de documentos en el primer incremento; funciones de edicin ms sofisticadas y de produccin de documentos en el segundo incremento; correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de pgina en el cuarto.

EL MODELO EN ESPIRAL

El modelo en espiral, propuesto originalmente por Boehm , 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 lineal secuencial. 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. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado.

EL MODELO ESPIRAL WINWIN

El

modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin, que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisin antes de continuar el proyecto de software. 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.

EL MODELO DE DESARROLLO CONCURRENTE

Un modelo de proceso concurrente est dirigido por las necesidades del usuario, las decisiones de la gestin y los resultados de las revisiones. El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas. Por ejemplo, la actividad de ingeniera definida para el modelo en espiral, se lleva a cabo invocando las tareas siguientes: modelado de construccin de prototipos y/o anlisis, especificacin de requisitos y diseo'.

El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/ servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una dimensin de sistemas y una dimensin de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseo, ensamblaje y uso

El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. El Proceso Unificado tiene dos dimensiones : Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lgica de acuerdo a su naturaleza. La primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones). La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en construccin est hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces). El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparacin de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par. Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace nico al Proceso Unificado.

Es dirigido por casos de uso

Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema.

Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo. An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.

Est centrado en la arquitectura El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que est siendo construido. El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutar, la disponibilidad de componentes reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las caractersticas ms importantes hechas ms visibles y dejando los detalles de lado.

Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y rehus. Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.

Es Iterativo e Incremental Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada. Los desarrolladores basan su seleccin de qu van a implementar en una iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteracin anterior. En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseo usando la arquitectura como gua, implementan el diseo en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

RUP divide el proceso en cuatro fases: Inicio, Elaboracin, Construccin y Transicin; dentro de cada fase, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones con sus incrementos resultantes. Cada fase termina con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos o documentos han sido desarrollados hasta alcanzar un estado predefinido.

-Mediante este proceso de desarrollo de software hay varias oportunidades para revisar el sistema a desarrollar hasta quesea correcto. Se pueden encontrar errores y corregirlos. -Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios -Se define una arquitectura slida en etapas tempranas del desarrollo. La arquitectura de un sistema se define como un conjunto de componentes y las interacciones entre ellas. De este modo este tipo de ciclo de vida debe ser ampliable, por lo que el sistema es robusto y tiene facilidad de mantenimiento. -Se reducen los riesgos de no obtener el producto deseado -En cada momento hay una versin del sistema funcionando que se modifica segn las necesidades y deseos del cliente. -Progreso visible en las primeras etapas -Reducir la redundancia e incrementa la productividad, un software bien diseado evita la duplicidad del cdigo con lo cual se obtiene un software robusto. -Fcil ejecucin del proceso de elaboracin del sistema software, ya que describen como est estructurado el sistema desde diferentes perspectivas orientadas a los diferentes involucrados en un proyecto -El proceso es comprensible -La metodologa de PU es ms adaptable para proyectos de largo plazo

-El mtodo de PU requiere costos de dedicacin altos por lo que no es conveniente usarlo en procesos de un proyecto pequeo. -Si el proceso no se aplica bien desde el inicio el PU se puede volver muy grande y difcil, tanto para aprender como para administrar -Una cantidad sustancial de tiempo se gasta en tratar de adecuar el PU a cada proyecto. Aqu, tambin, se corre el riesgo de volverse un esclavo del proceso y perder de vista la razn del proceso -Es un proceso pesado -Se basa mucho en la documentacin

HERRAMIENTAS CASE

INTRODUCCIN
Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, clculo de costos, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras.

OBJETIVOS
Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo. Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones. Simplificar el mantenimiento de los programas. Mejorar y estandarizar la documentacin. Aumentar la portabilidad de las aplicaciones. Facilitar la reutilizacin de componentes software. Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilizacin de grficos.

UNA HERRAMIENTA CASE DEBE INCLUIR:

Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de bases de datos. Herramientas de diseo para dar apoyo al anlisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, as como los esquemas conceptual y lgico. Herramientas para desarrollar los prototipos de las aplicaciones. El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicacin de bases de datos.

VENTAJAS Y DESVENTAJAS
Tipo de case Ventajas Desventajas

I - case

Integra el ciclo de vida. Permite lograr importantes mejoras de productividad a mediano plazo.

No es tan eficiente para soluciones simples, sino para soluciones complejas. Es costos

Upper Case

Se utiliza en plataforma PC, es aplicable a diferentes entornos, Menor costo

Permite mejorar la calidad de los sistemas, pero no mejora la productividad. No garantiza la consistencia de los resultados a nivel corporativo. No permite la integracin del ciclo de vida.

Lower Case

Permite lograr importantes mejoras de productividad a corto plazo

CARACTERSTICAS
La herramienta CASE cliente/servidor tiene modelo de datos, generacin de cdigo de ciclo de vida. Las principales herrameintas son Knowledge Wares Application Development Workbench, TIs, Information Engineering Facility (IEF), y Andersen consultings Foundation for Cooperative Processing.

ESTRUCTURA GENERAL
La estructura CASE se basa en lo siguiente : Un CASE de alto nivel es la herramienta que automatiza o apoya las fases superiores del ciclo de vida del desarrollo de sistemas como la planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas. Un CASE de bajo nivel es la herramienta que automatiza o apoya las fases inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin de sistemas y el soporte de sistemas. Un CASE cruzado de ciclo de vida se aplica a las herramientas que apoyan actividades a lo largo de todo el ciclo de vida, se incluyen actividades como la gestin de proyectos y la estimacin.