Modelo Lineal Secuencial Tambin llamado "Ciclo de vida bsico" o "Modelo de cascada" tiene su origen en el "Modelo de cascada" ingeniado

por Winston Royce, sugiere un enfoque sistemtico o ms bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. El MLS tiene las siguientes actividades: Anlisis de los requerimientos del software: es la fase en la cual se renen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos. Diseo: es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta hacindose parte del software. Generacin del cdigo: es la etapa en la cual se traduce el diseo para que sea comprensible por la mquina. Esta etapa va a depender estrechamente de lo detallado del diseo. Pruebas: esta etapa se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado, y en la deteccin de errores. Mantenimiento: debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios. El MLS es el paradigma de desarrollo de software ms antiguo que existe, sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de l basada en los siguientes errores reales: Los proyectos raramente siguen el paradigma secuencial que propone el proyecto. A menudo es difcil que el cliente exponga exactamente todos los requisitos. El cliente debe tener paciencia. Los responsables innecesariamente. del desarrollo de software siempre se retrasan

Modelo Espiral. Desarrollado por B. Boehm bsicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa; est orientado a evitar riesgos de trabajo. No define en detalle el sistema completo a la primera. Los desarrollares debern solamente definir las ms altas prioridades. Definir e implementarlas y entonces obtener un feedback de los usuarios (tal y como feedback distingue desarrollo "evolutivo" de "incremental"). Con este conocimiento, debern entonces retroceder o volver al punto de partida para definir e implementar ms y mejores partes. El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseo. Eso introduce un ciclo de prototipo iterativo. En cada iteracin, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo. Este mtodo est basado en dos importantes principios: 1. La prctica de diseo profesional es caracterizar en trminos de conocer, actuar en situaciones, conversacin con la situacin y reflexin en accin. Hay un distinto medio de proceso - orientacin en esta aproximacin al diseo. Es raro que el diseador tenga el diseo en su cabeza por adelantado y que despus meramente lo transcriba. Gran parte del tiempo del diseador esta inmiscuido en una progresiva relacin con su entorno. Una buena metfora para describirlo es "la conversacin con el material", como un escultor, quien est ocupado en una conversacin con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser. 2. La necesidad para diseadores de tomar la prctica de trabajo seriamente, de supervisar las formas en las que el trabajo se est haciendo, en el sentido de una solucin abierta y desplegada para aumentar la complejidad de una situacin que el diseador solo entiende parcialmente. El hecho por el cual se est tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperacin y comunicacin.

Una visin general del Modelo de Cascada puede ser la siguiente:

Leyenda. 1. 2. 3. 4. 5. 6. 7. 8. 9. Anlisis de Riesgos. Diversos Prototipos. Simulacin y Modelos Concepto de Operacin Requerimientos de Software. Validacin de Requerimientos. Diseo, validacin y verificacin de Software. Detalles de Diseo. Implementacin del Cdigo. Diversos test para el Cdigo (unificacin, integracin, aceptacin e implementacin). 10. Planes de integracin, requerimientos y ciclos de vida. En un plano ms general, cada cuadrante de la implementacin puede verse segn este esquema:

El desarrollo del software en el Modelo Espiral viene dado mediante un sistema incremental que se explica a continuacin: Desarrollo Incremental
o o o

Identificar elementos de funcionalidad separados en los requerimientos iniciales, Dar prioridad y crear un plan de desarrollo, Diferentes modelos de ciclos de vida pueden ser usados por diferentes incrementos.

Qu es un 'bug'? Se puede definir como falta (una definicin o instruccin incorrecta), falla (un resultado incorrecto) o error (una accin humana que genera una falla).

El modelo espiral para la ingeniera de software ha sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico, como de la creacin de prototipos, aadiendo al mismo tiempo un nuevo elemento: el anlisis de riesgo. El modelo representado mediante la espiral define cuatro actividades principales: 1. Planificacin: determinacin de objetivos, alternativas y restricciones. 2. Anlisis de riesgo: anlisis de alternativas e identificacin/resolucin de riesgos. 3. Ingeniera: desarrollo del producto del "siguiente nivel", 4. Evaluacin del cliente: Valorizacin de los resultados de la ingeniera. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creacin de prototipos en el cuadrante de ingeniera para dar asistencia tanto al encargado de desarrollo como al cliente.

El cliente evala el trabajo de ingeniera (cuadrante de evaluacin de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una decisin de "seguir o no seguir". Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez ms completa y, al final, al propio sistema operacional. Utiliza un enfoque evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos.

Modelo DRA (Rapid Application Development). Es un MLS pero que enfatiza en un ciclo extremadamente corto el desarrollo de software, convirtindose en una versin suya de "alta velocidad". Esta versin logra un desarrollo rpido utilizando un enfoque de construccin de componentes lo cual permite crear un "sistema completamente funcional" en un periodo de tiempo muy corto (60-90 das). El RAD comprende las siguientes etapas: Modelado de Gestin: aqu se modela el flujo de informacin entre las funciones de gestin. Este flujo debe "responder" a preguntas tales como Qu informacin conduce el proceso de gestin?, Quin la genera?, A dnde va la informacin?, Quin la procesa? Modelado de datos: se definen las caractersticas (atributos) de cada objeto, formado a partir del flujo de informacin, y las relaciones entre ellos. Modelado del proceso: las descripciones del proceso se crean para aadir, modificar, suprimir o recuperar un objeto de datos. Generacin de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas ya existentes o crea componentes reutilizables. Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo cual permite que el tiempo de duracin de las pruebas sea menor. Todo esto no impide que se tenga que probar cada uno

de los nuevos componentes. Al igual que todos los mtodos, el RAD conlleva inconvenientes tales como: Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el nmero suficiente de equipos. Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario.

Caractersticas De Rad Entre las principales caractersticas del RAD tenemos: 1. Equipos Hbridos Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema as como aquellas personas involucradas con los requisitos. Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y programadores en uno.

2. Herramientas Especializadas Desarrollo "visual" Creacin de prototipos falsos (simulacin pura) Creacin de prototipos funcionales Mltiples lenguajes Calendario grupal Herramientas colaborativas y de trabajo en equipo Componentes reusables Interfaces estndares (API) Control de versiones

3. "Timeboxing" Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario. 4. Prototipos Iterativos y Evolucionarios o o o o Reunion JAD (Joint Application Development): Se renen los usuarios finales y los desarrolladores. Lluvia de ideas para obtener un borrador inicial de los requisitos. Iterar hasta acabar:

o Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales. o Los diseadores revisan el prototipo. o Los clientes prueban el prototipo, depuran los requisitos. o Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios. o Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario. o Notas: Cada iteracin dura entre un da y tres semanas. Reuniones de 2 horas con facilitador que mantiene enfocado al grupo. RAD tiende a funcionar cuando: La aplicacin funcionar de manera independiente. Se pueden usar mayormente bibliotecas existentes. Desempeo no crtico. Distribucin limitada, interna o vertical. Alcance del proyecto limitado. Confiabilidad no crtica. El sistema puede dividirse en muchos mdulos independientes. El producto est dirigido a un mercado altamente especializado. El proyecto cuenta con fuertes limitantes de tiempos parciales (timeboxes). La tecnologa requerida tiene ms de un ao en el mercado.

RAD tiende a fallar cuando: La aplicacin debe interoperar con sistemas existentes. Existen pocos componentes reutilizables. Alto desempeo crtico. El desarrollo no puede aprovechar herramientas de alto nivel. Distribucin amplia, horizontal o masiva. RAD se convierta en QADAD (Quick And Dirty Application Development). Mtodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o juegos (desempeo demasiado alto). Riesgos tcnicos de tecnologa de punta. El producto pone en riesgo la misin o la vida. El producto no puede ser modularizado. Ventajas de RAD

Comprar puede ahorrar dinero en comparacin con construir. Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar.

Desventajas de RAD Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Menor precisin cientfica. Riesgo de revertirse a las prcticas sin control de antao. Ms fallas (por sndrome de "codificar a lo bestia"). Prototipos pueden no escalar, un problema maysculo. Funciones reducidas (por "timeboxing"). Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales.

MODELO DE PROTOTIPOS

Este modelo consiste en un procedimiento que permite al equipo de desarrollo disear y analizar una aplicacin que representa el sistema que sera implementado (McCracken y Jackson, 1982). Dicha aplicacin, llamada prototipo, est compuesta por los componentes que se desean evaluar (i.e. las funciones principales). Las etapas del modelo son: o Investigacin preliminar. o Colecta y refinamiento de los requerimientos y proyecto rpido: Anlisis y especificacin del prototipo. Diseo y construccin del prototipo. Evaluacin del prototipo por el cliente. Renacimiento del prototipo. o Diseo tcnico. o Programacin y test. o Operacin y mantenimiento. Para construir un prototipo del software se aplican los siguientes pasos: PASO 1. Evaluar la peticin del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los ltimos pasos, es esencial que: 1) el cliente participe en la evaluacin y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendr una fuerte influencia en la eficacia del prototipo. PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representacin abreviada de los requerimientos. Antes de que pueda comenzar la construccin de un prototipo, el analista debe representar los dominios funcionales y de informacin del programa y desarrollar un mtodo razonable de particin. La aplicacin de estos principios de anlisis fundamentales, pueden realizarse mediante los mtodos de anlisis de requerimientos.

PASO 3. Despus de que se haya revisado la representacin de los requerimientos, se crea un conjunto de especificaciones de diseo abreviadas para el prototipo. El diseo debe ocurrir antes de que comience la construccin del prototipo. Sin embargo, el diseo de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseo de datos, en vez de hacia el diseo procedimental detallado. PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construccin de software preexisten se utilizan para crear el prototipo de una forma rpida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementacin de un prototipo que funcione es impracticable, es escenario de construccin de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interaccin hombre-maquina usando una serie de hojas de historia. PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicacin y sugiere modificaciones. Este paso es el ncleo del mtodo de construccin de prototipo. Es aqu donde el cliente puede examinar una representacin implementada de los requerimientos del programa, sugerir modificaciones que harn al programa cumplir mejor las necesidades reales. PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estn formalizados o hasta que el prototipo haya evolucionado hacia un sistema de produccin. El paradigma de construccin del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el propsito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la produccin de programas mediante el uso de mtodos y tcnicas de ingeniera de programacin, o 2) el propsito de la construccin del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la produccin del software. Ambos mtodos tienen sus meritos y ambos crean problemas.

Este modelo tambin denominado modelo de desarrollo evolutivo. Para comprender este modelo, comenzaremos con la definicin de los objetivos globales para el software, despus identificaremos los requerimientos que conocemos y los sitios del diseo en donde es necesaria ms definicin. Entonces planteamos con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en forma de un diseo rpido). Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez ms completas del software.

El diseo rpido se basa en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. CONSTRUCCIN DE PROTOTIPOS A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. 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 humana mquina, entonces en este caso cuando utilizamos la construccin de prototipos.

El paradigma de construccin de prototipos se inicia con la comunicacin. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms definicin. Entonces se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en la forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario final. El diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La

iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer. VENTAJAS: No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera. DESVENTAJAS A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos se torna problemtica por las siguientes razones: El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema aun no ha sido construido. El desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.

Modelos de Procesos Evolutivos Si los requisitos del software son muy cambiantes, se requiere un modelo que contemple la naturaleza evolutiva del software. Estos son los llamados modelos evolutivos. Son modelos iterativos, donde se desarrollan versiones del software, cada nueva versin es ms completa y contempla nuevas funcionalidades.

Modelo Incremental

Perteneciente a la familia de los Modelos de Procesos Evolutivos, el Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. El proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o "Pipeline", utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. Al igual que los otros mtodos, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.

El Modelo de Ensamblaje de Componentes.

Incorpora muchas de las caractersticas del Modelo Espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo ensamblador de componentes configura aplicaciones desde componentes separados del software (algunas veces llamados "clases"). Esto se debe gracias a que, si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadoras. En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicacin y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en una biblioteca de clases o depsito. Se determina cules de ellas ya existen a fin de reutilizarlas. En caso de que exista alguna que no est diseada, se aplican los mtodos orientados a objetos. Este proceso se inicia en el estado de Anlisis de Riesgos del Espiral y se inserta en el estado de Construccin de Ingeniera. En resumen, este modelo se basa en ir construyendo con la construccin de cada sistema una biblioteca de Componentes (clases /objetos) , cuando se va a construir un nuevo sistema, se hace el proceso de definir los objetos del sistema, buscar en la librera de objetos, construir los que no existen, meterlos en la biblioteca, ensamblar los objetos, la metodologa busca que sea evolutiva pasando por una fase de planificacin, anlisis de riesgos, ingeniera, construccin y adaptacin, evaluacin del cliente y repetir estas fases de tal forma que las primeras iteraciones desarrollan los conceptos, al avanzar se desarrollan los

nuevos componentes, luego se busca mejorarlos y finalmente se les da mantenimiento.

Modelo de desarrollo concurrente Fue escrito por Davis y Sitaram, algunas veces llamado ingeniera concurrente. Se puede representar en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas. El modelo de proceso concurrente define una serie de acontecimientos que dispararn transiciones de estado a estado para cada una de las actividades de la ingeniera del software. 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 2 dimensiones: una dimensin de sistemas y una dimensin de componentes. Los aspectos del nivel de sistemas se afrontan mediante 3 actividades: diseo, ensamblaje y uso. La dimensin de componentes se afronta con 2 actividades: diseo y realizacin. La concurrencia se logra de 2 formas: 1).- las actividades de sistemas y de componentes ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos; 2).- una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente. El modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual del proyecto.

Es un modelo de tipo de red donde todas las personas actan simultneamente o al mismo tiempo. Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniera concurrente, de la siguiente forma: Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clsico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificacin, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultneamente. Por ejemplo, el personal est escribiendo requisitos diseando, codificando, haciendo pruebas y probando la integracin (todo al mismo tiempo). Los modelos de proceso de ingeniera del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo ms reciente de Kellner utiliza diagramas de estado para representar la relacin concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestin del software en mi proyecto...La

mayora de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto ms tarde sea, ms atrs se encontrara en el proceso de desarrollo. (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.

La figura siguiente proporciona una representacin esquemtica de una actividad dentro del modelo de proceso concurrente. La actividad "anlisis" se puede encontrar en uno de los estados destacados anteriormente en cualquier momento dado. De forma similar otras actividades se pueden representar de una forma anloga. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicacin con el cliente (no mostrada en la figura) ha finalizado su primera interaccin y existe en el estado de cambios en espera. La actividad de anlisis (que exista en el estado ninguno mientras que comenzaba la comunicacin inicial con el cliente) ahora hace una transicin al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad anlisis cambia del estado bajo desarrollo al estado cambios en espera. El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniera del software. Por ejemplo, durante las primeras etapas del diseo, no se contempla una inconsistencia del modelo de anlisis. Esto genera la correccin del modelo de anlisis de sucesos, que disparara la actividad de anlisis del estado hecho al estado cambios en espera. El modelo de desarrollo 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 divisin de sistemas y una divisin de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseo y realizacin. La concurrencia se logra de dos formas (1) las actividades del sistema y de componente ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente; (2) una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente. En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniera de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultneamente con otras. Los sucesos generados dentro de una actividad dada o algn otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.