Universidad Tecnolgica Mariano Escobedo

Nombre: Alejandro Garcia Martinez

Matricula: 301110187

Asignatura: Ingeniera de software

Carrera: Tecnologas de la Informacin y comunicacin rea de sistemas.

Tema: Modelos de desarrollo de software.

Maestra: Susana Maciel Salas

23-Enero-2013

Modelo Cascada
En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos. Diseo del Sistema. Diseo del Programa. Codificacin. Pruebas. Implantacin. Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.
Ingeniera y Anlisis del Sistema Anlisis de los Requisitos Diseo Codificacin Prueba Mantenimiento

Desventajas En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. Ventajas La planificacin es sencilla. La calidad del producto resultante es alta. Permite trabajar con personal poco cualificado. CARACTERISTICAS Es el ms utilizado. Es una visin del proceso de desarrollo de software como una sucesin de etapas que producen productos intermedios. Para que el proyecto tenga xito deben desarrollarse todas las fases. Las fases continan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final ser de inferior calidad

Modelo Incremental
El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, 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. De esta forma el tiempo de entrega se reduce considerablemente. 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 Incremental se puede ver aqu en forma grafica: Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucra ms. Difcil de evaluar el coste total. Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo.

Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucre ms. Difcil de evaluar el costo total. Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo.

Ventajas: Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico.

Desventajas: El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. Requiere de mucha planeacin, tanto administrativa como tcnica. Requiere de metas claras para conocer el estado del proyecto.

Modelo DRA
El modelo DRA, es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. (Es una adaptacin a alta velocidad del modelo lineal secuencial.) El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de perodos cortos de tiempo El enfoque DRA comprende las siguientes fases: Modelado de Gestin Modelado de datos. Modelado del proceso

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 refina como 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. El DRA asume la utilizacin de tcnicas de cuarta 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)

Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. VENTAJAS 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 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 en Espiral.
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 de la figura 2.4, define cuatro actividades principales:

1. 2. 3. 4.

Planificacin: determinacin de objetivos, alternativas y restricciones. Anlisis de riesgo : anlisis de alternativas e identificacin/resolucin de riesgos. Ingeniera : desarrollo del producto del "siguiente nivel", 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. El paradigma del modelo en espiral para la ingeniera de software es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. 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.

Ventajas El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos.

Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico. Desventajas

Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos

El modelo desarrollo concurrente.

Davis y Sitaranm [DAV94] han descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniera concurrente. 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 idea del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente complejos de actividades mediante modelos demasiado simples. Tenga en cuenta que aunque un proyecto [grande] est en la fase de codificacin, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultneamente. El modelo de proceso concurrente se puede sentar 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 acabo invocando las tareas siguientes: modelado de construccin de prototipos y/o anlisis, especificacin de requisitos y diseo. 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 en cualquier momento dado. De forma similar, otras actividades (por ejemplo el diseo o comunicacin con el cliente) se pueden representar de una forma analgica. Todas las actividades existen concurrentemente, pero residen en estados diferentes, por ejemplo, al principio del proyecto la actividad de comunicacin con el cliente ha finalizado su primera interaccin y esta en el estado de cambios en espera. La actividad de anlisis

(que esta en el estado ninguno mientras que se iniciaba la comunicacin inicial con el cliente) ahora hace una transaccin 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 dispara la actividad de anlisis del estado hecho al estado cambios en espera. 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. Las dimensiones de componentes se afrontan con dos actividades: diseo y realizacin. La concurrencia se logra de dos 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. En realidad, el modelo del proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.

Modelo de Construccin de Prototipos

Tambin denominado modelo de desarrollo evolutivo. 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.

Etapas Plan rpido Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin Comunicacin

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. 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 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Modelo basado en componentes. El modelo basado en componentes es un paradigma de desarrollo, donde el software es desarrollado mediante la reutilizacin de componentes de software pre existentes. Emergi como una importante solucin al problema del desarrollo de sistemas grandes y complejos, se caracteriza por ser: Evolutivo por naturaleza Exige un enfoque iterativo para la creacin de software Contiene diagramas de componentes y/o Interfaces Componentes y nodos

Restricciones El desarrollo de software basado en componentes permite reutilizar piezas de cdigo pre elaborado que permite realizar di versas tareas, conllevando a diversos beneficios como:

La mejora a la calidad La reduccin del ciclo de desarrollo y

Mayor retorno sobre la inversin El reutilizar trozos de experiencias, ideas y artefactos, no solo asegura no volver cometer errores del pasado sino que se puede lograr construir cosas cada vez ms grandes y maravillosas, con bases firmes y calidad incomparable. Algunas ventajas que pueden ser destacadas en este modelo de componentes consisten en: La reutilizacin de software Simplificacin de pruebas Simplificacin del mantenimiento del sistema Mayor calidad, Ciclos de desarrollo ms corto y Funcionalidad mejorada

Ventajas Reutilizacin del Software. Simplificacin de pruebas, simplificacin del mantenimiento del sistema. (ambas significan menos tiempo) Ciclos de desarrollo se hacen mas cortos. El dinero invertido regresa en menos tiempo. Hay mejor funcionalidad (aunque, insisto, depende si sabemos comprar bien).

Modelo de mtodos formales.

La denominacin mtodos formales se usa para referirse a cualquier actividad relacionada con representaciones matemticas del software, incluyendo la especificacin formal de sistemas, anlisis y demostracin de la especificacin, el desarrollo transformacional y la verificacin de programas. Todas estas actividades dependen de una especificacin formal del software. Una especificacin formal del software es una especificacin expresada en un lenguaje cuyo vocabulario, sintaxis y semntica estn formalmente definidos. Esta necesidad de una definicin formal significa que los lenguajes de especificacin deben basarse en conceptos matemticos cuyas propiedades se comprendan bien. La rama de las matemticas usada es la de matemtica discreta, y los conceptos matemticos provienen de la teora de conjuntos, la lgica y el lgebra.

Claramente, esta prediccin no se ha hecho realidad. Existen cuatro razones principales para esto: 1. Una ingeniera del software exitosa. El uso de otros mtodos de ingeniera del software como los mtodos estructurados, gestin de configuraciones y ocultacin de la informacin en el diseo del software y procesos de desarrollo ha conducido a mejoras en la calidad del software. La gente que sugiri que la nica forma de mejorar la calidad del software era usando mtodos formales estaba claramente equivocada. 2. Cambios en el mercado. En la dcada de los 80, la calidad del software fue vista como un problema clave de la ingeniera del software. Sin embargo, desde entonces, la cuestin crtica para muchas clases de desarrollo del software no es la calidad, sino la oportunidad de mercado. El software debe desarrollarse rpidamente, y los clientes estn dispuestos a aceptar software con algunos defectos si se les entrega rpidamente. Las tcnicas para el desarrollo rpido del software no funcionan de forma efectiva con las especificaciones formales. Por supuesto, la calidad todava es un factor importante, pero debe lograrse en el contexto de entrega rpida. 3. mbito limitado de los mtodos formales. Los mtodos formales no son muy apropiados para la especificacin de interfaces de usuario e interacciones del usuario. El componente de interfaz de usuario se ha convertido en una parte cada vez mayor de la mayora de los sistemas, de manera que realmente s6lo pueden usarse mtodos formales cuando se desarrollan las otras partes del sistema. 4. Escalabilidad limitada de los mtodos formales. Los mtodos formales todava no son muy escalables. La mayora de los proyectos con xito que han usado estas tcnicas han estado relacionados con ncleos de sistemas crticos relativamente pequeos. A medida que los sistemas incrementan su tamao, el tiempo y esfuerzo requerido para desarrollar una especificacin formal crece de forma desproporcionada. Ventajas Se comprende mejor el sistema. La comunicacin con el cliente mejora ya que se dispone de una descripcin clara y no ambigua de los requisitos del usuario. El sistema se describe de manera ms precisa. El sistema se asegura matemticamente que es correcto segn las especificaciones. Mayor calidad software respecto al cumplimiento de las especificaciones. Mayor productividad

Desventajas El desarrollo de herramientas que apoyen la aplicacin de mtodos formales es complicado y los programas resultantes son incmodos para los usuarios. Los investigadores por lo general no conocen la realidad industrial. Es escasa la colaboracin entre la industria y el mundo acadmico, que en ocasiones se muestra demasiado dogmtico. Se considera que la aplicacin de mtodos formales encarece los productos y ralentiza su desarrollo.

Desarrollo de software orientado a aspectos. Son muchos los intereses que un equipo de desarrollo de software debe fijar su atencin: entender el problema, entender su entorno, gestin del proyecto, equipo de desarrollo, aspectos tcnicos, entre otros. Los intereses referidos a aspectos tcnicos como seguridad, persistencia, presentacin, manejo de errores, etc. Han dado origen al paradigma orientado a aspectos. El enfoque orientado a aspectos define un mecanismo que ayuda a resolver problemas de codificacin en los requisitos, los cuales son un cdigo disperso (scattered) y diseminado (tangled), que no se resuelven fcilmente usando el enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la separacin de intereses (separation of concerns) de un sistema para obtener una mejor modularizacin

Desarrollo de software orientado a aspectos El desarrollo de software orientado a aspectos (DSOA) se enfoca en crear una mejor abstraccin modular del sistema. Incluye las siguientes fases: - Captura de requisitos - Anlisis - Diseo - Implementacin - Pruebas La primera fase trata la separacin de intereses tanto los funcionales como los no funcionales; los requisitos funcionales son modelados con casos de uso que representan la funcin bsica del sistema y los requisitos no funcionales se representan con casos de uso de infraestructura. En el anlisis y el diseo los casos de uso se representan en una estructura de composicin que se identifica con el estereotipo <<use case slice>> y agrupa elementos de modelo que colaboran para lograr los requisitos del sistema tanto funcionales como no funcionales. En la implementacin se genera el cdigo de las clases y aspectos. El Proceso Unificado de Desarrollo de Software (RUP) 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 resposabilidades 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. 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 (architecturecentric), iterativo e incremental. Esto es lo que hace nico al Proceso Unificado. El 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. El Proceso Unificado 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 disponiblidad 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 reuso.