Definicin de Escenarios:

Escenario de Desempeo y escalabilidad 1.- Calidad Deseada El sistema web de EL TREBOL debe ofrecer funcionalidad, permitir la ejecucin de los procesos realizados por parte de los stakeholders, usuarios del sistema, de tal forma que se cumpla con el nivel de desempeo deseado, y se maneje, ptimamente, el incremento en los volmenes de procesamiento, cada vez que sean requeridos a travs de las solicitudes hechas por los clientes, estas pueden surgir frente al aumento de flujo de las transacciones y/u operaciones normales del sistema, o del nmero de clientes, sin afectar, en mayor cantidad, la funcionalidad del sistema. Aplicabilidad Al favorecer o afectar este atributo de calidad, la web y sistemas del EL TREBOL ver alterado el punto de vista de concurrencia, ya que, a mayor nmero de usuarios accediendo al mismo tiempo, menor es la velocidad con la que el sistema puede responder, debido a que los recursos disponibles deben ser divididos entre ms transacciones. El punto de vista de despliegue tambin se ve afectado, ya que para poder generar tiempos ms cortos de procesamiento y/o adecuarse a cambios en la demanda de servicios, se requiere de un diseo ptimo asociado a los recursos fsicos para poder ofrecer una funcionalidad sostenible. Preocupaciones (concerns) Se espera que los tiempos de respuesta y la capacidad de procesamiento no se afecten de manera significativa a causa del incremento del volumen de transacciones, navegacin a travs de la pgina y las distintas funciones que esta tendr. De igual forma, se debe ofrecer, en los parmetros normales de funcionamiento, tiempos de respuesta ptimos.

Un factor clave que afecta directamente el desempeo es el rendimiento, el cual se refiere al volumen de informacin utilizado en los procesos normales del sistema para ofrecer la funcionalidad deseada. Los requerimientos asociados a los recursos de hardware, deben ser tomados en cuenta para garantizar el desempeo deseado. Actividades Las actividades para aplicar esta perspectiva arquitectural a los puntos de vista de concurrencia y despliegue seran los siguientes: Identificar los requerimientos de desempeo deseados para la aplicacin. Evaluar la condicin actual del sistema para ver si, con las caractersticas actuales, puede soportar (sin salirse de los requerimientos de tiempos) la nueva demanda. Adicionalmente identificar si es posible realizar cambios en el diagrama de despliegue a fin de favorecer la nueva situacin. Evaluar el riesgo que representan los cambios identificados frente a los dems requerimientos del sistema. Implementar los cambios que se hayan considerado que tienen un impacto significativo en el desempeo y la escalabilidad del sistema.

Tcticas

Las tcticas necesarias para la cumplir con este atributo de calidad son bsicamente: Optimizar el procesamiento repetitivo, de forma que se tienda a minimizar los tiempos de respuesta y procesamiento, consolidar unidades de negocio relacionadas de acuerdo a su funcionalidad, priorizar los procesos ms significativos del sistema en trminos de atencin y tiempos de respuesta, minimizar el uso de fuentes compartidas a fin de reducir el tiempo necesario para recibir las respuestas de stas, usar procesos asincrnicos en aquellas partes de la lgica de negocio que no necesiten tener la informacin actualizada de forma continua y realizar compromisos de diseo asociados al fortalecimiento y cumplimiento del desempeo deseado.

2.- Seguridad Calidad Deseada El Sitio Web debe estar en capacidad de controlar, monitorear, y auditar, de forma confiable, las acciones relacionadas con el proceso de bsqueda de productos, consultas y compra de los mismo, el usuario autorizado para realizar acciones determinadas dentro de la funcionalidad del sistema, y la administracin de los datos almacenados orientada hacia la integridad y conservacin de la informacin. La funcionalidad ofrecida por parte del sitio Web de EL TREBOL depende del rol que desempea el usuario dentro de la organizacin. Para controlar que la debida funcionalidad est asociada a un rol en particular, se requiere de mecanismos de seguridad que permitan la debida autenticacin de usuarios, y la administracin controlada de los privilegios que deben ser concedidos. En este sentido, el sistema debe estar en capacidad de controlar, monitorear, y auditar, quin puede desempear determinadas acciones dentro del sistema, y qu recursos se encuentran disponibles para llevarlas a cabo. De igual forma, la manipulacin de la informacin almacenada por parte de los usuarios debe estar orientada hacia la integridad y conservacin de la misma, mediante mecanismos de seguridad que permitan el acceso a dicha informacin nicamente por parte de usuarios autorizados. Aplicabilidad Al favorecer este atributo de calidad se genera una compensacin (tradeoff) con el punto de vista de desempeo principalmente ya que realizar la verificacin de las identidades y dems procesos de seguridad consume ms recursos y hace que las operaciones se realicen de manera ms lenta. Igualmente para poder asegurar que este atributo se pueda cumplir el punto de vista de despliegue ya que ser importante contar con hardware y protocolos de seguridad. Preocupaciones (concerns) Se espera que durante la ejecucin de la aplicacin no se presenten problemas de suplantacin de identidad de parte de un cliente o que un funcionario de la empresa llegue a poder realizar una accin sobre el sistema que no debera estar en posibilidad de hacer. Actividades

A fin de cumplir con el atributo de seguridad se definen las siguientes actividades que se llevarn a cabo. Identificar los puntos de sensibilidad de la aplicacin donde puedan ocurrir situaciones que afecten la seguridad de la misma. Definir las polticas de seguridad que se van a tener en cuenta para toda la aplicacin. Identificar los posibles ataques que pueda sufrir la aplicacin. Disear la seguridad para la etapa de implementacin. Tcticas Las aproximaciones necesarias para el cumplimiento de este atributo comprenden: Aplicar un principio de autenticacin para la aplicacin donde se verifique la autenticidad y los permisos de la persona que desea realizar una operacin. Utilizar protocolos seguros como HTTPS para el transporte de datos entre los diferentes entes que usan la aplicacin. Crear un servicio de auditora en el cual se registren todas las actividades que se realizan. 3.- Disponibilidad Calidad Deseada La Web de EL TREBOL debe estar en capacidad de maximizar el tiempo disponible para los procesos involucrados de peticiones de compra, y ser tolerante a fallas. Para ello, debe tener la capacidad de recuperacin automtica de servicios, garantizando la alta disponibilidad de los mismos, y minimizando as la percepcin del fallo por parte de los usuarios. Esta capacidad de recuperacin automtica de servicios, debe garantizar la integridad y conservacin de la informacin y sus productos. Para garantizar la alta demanda y disponibilidad del sistema WEB, la funcionalidad del mismo estar a tiempo completo las 24 horas de la sema y todos los das del ao, salvo en periodos de mantencin de la misma.

Aplicabilidad Teniendo en cuenta lo anterior, a fin de cumplir con este atributo de calidad, es necesario su impacto en el punto de vista de despliegue al igual que en el funcional ya que, para el primero ser necesario contar con una mejor infraestructura tecnolgica si se espera que la aplicacin est disponible a tiempo completo. Igualmente para asegurar que la aplicacin soporte el procesamiento de gran cantidad de datos sin necesidad de un gran mantenimiento, es necesario que la estructura de la misma este bien diseada. Preocupaciones (concerns) El presupuesto, y los costos asociados a los empleados requeridos para esta aplicacin y que demanden alta disponibilidad, puede ser un factor limitante. Los requerimientos de hardware y software, deben ser tomados en cuenta para garantizar la disponibilidad deseada. La ubicacin geogrfica puede alterar el curso de la disponibilidad, por lo que posibilidades de desastres naturales y/o problemas ambientales, deben ser evaluados. El ambiente organizacional tambin puede interferir, en cunto a cambios imprevisibles en los negocios como las compras, adquisiciones, fusiones y cambios polticos de parte de la empresa EL TREBOL. Otros factores importantes son el tiempo de recuperacin, las cadas de servidores o sistemas no planeadas y planeadas, las clases de servicios y su prioridad frente a los usuarios, y los mecanismos de recuperacin ante cualquier falla de infraestructura o aplicacin. Actividades Identificar los requerimientos de disponibilidad deseados para la aplicacin. Producir un plan de procesos a seguir en torno a cumplir los requerimientos planteados. Estimar la disponibilidad de infraestructura y servicios funcionales deseados. Evaluar la condicin actual del sistema para ver si, con las caractersticas actuales, puede cumplir los requerimientos deseados de disponibilidad. Evaluar el riesgo que representan los cambios identificados frente a los dems requerimientos del sistema. Plantear los posibles tradeoffs relacionados a los cambios que ya se han identificado. Implementar los cambios que se hayan considerado que tienen un impacto significativo en la disponibilidad del sistema.

Tcticas Las tcticas necesarias para la cumplir con este atributo de calidad son bsicamente: Seleccionar hardware tolerante a fallas, utilizar clster de alta disponibilidad y balanceo de cargas, aplicar soluciones de disponibilidad de software, crear o seleccionar software tolerante a fallas, realizar backups continuos, buscar soluciones de recuperacin ante fallas y desastres, y poseer independencia geogrfica en cunto a ubicacin de los datos del sistema. 4.- Evolucin Calidad Deseada La arquitectura del sistema debe ser lo suficientemente flexible para aceptar cambios en los componentes del sistema (Crear, modificar o eliminar) que puedan surgir posterior a la implementacin. Se debe tener en cuenta que los cambios que se generen deben incurrir en la menor cantidad de costos para la compaa, por lo que se espera que stos puedan ser integrados con las interfaces que ya han sido definidas. Aplicabilidad El favorecer este atributo de calidad tiene consecuencias transversales en el punto de vista funcional ya que es necesario que la aplicacin tenga definida un conjunto de componentes e interfaces que puedan satisfacer los requerimientos que se puedan presentar en el futuro. Igualmente afecta el punto de vista de informacin ya que es necesario que los datos que estn circulando en la aplicacin puedan representar tanto la informacin que es necesaria en la actualidad como la informacin que pueda ser relevante ms adelante (descripciones de los productos, precios, ofertas, stock de productos, etc). Preocupaciones (concerns) Se espera que la arquitectura no se vea comprometida de manera crtica al introducir un cambio en la estructura de sus componentes y por ende de sus unidades de informacin. As mismo se espera que de efectuarse un cambio, el costo no sea tan alto. Actividades Las actividades para aplicar esta perspectiva a los puntos de vista funcional y de informacin son los siguientes: Se deben caracterizar las necesidades de evolucin que se desean tener, es decir, qu se podra agregar.

Evaluar la flexibilidad actual del sistema, es decir, mirar qu tan fcil es que evolucione con la arquitectura actual y se analizan los posibles impactos que puedan llegar a tener una modificacin de sta. Luego se consideran los tradeoffs asociados a los cambios que se planean realizar y su impacto en los viewpoints, especialmente en el de informacin y el funcional. Finalmente se pasa a la etapa de implementacin de los cambios. Se debe subrayar que los cambios que llegan a la etapa de presentacin, pasaron por un filtro, lo que indica que son lo suficientemente importantes y que los tradeoffs que implican valen la pena.

Tcticas Las aproximaciones y precisiones necesarias para el cumplimiento del atributo de modificabilidad comprenden bsicamente la creacin de interfaces flexibles, agrupar los elementos arquitecturales por su grado de especializacin, usar extensiones estndar en toda la aplicacin, preservar los ambientes de desarrollo, entre otros.

Paso 1: Presentando a ATAM Primero presentaremos los pasos de ATAM: * Paso 2: Los conductores actuales de negocio. * Paso 3: Arquitectura actual. * Paso 4: Identificar los enfoques arquitectnicos. * Paso 5: Generar atributos de calidad del rbol de utilidad. * Paso 6: Analizar los enfoques arquitectnicos (Templates). * Paso 7: Lluvia de ideas y priorizar escenarios (Anotacin de los atributos de calidad). * Paso 8: Analizar los enfoques arquitectnicos (Reiterar las jerarquas). * Paso 9: Presentar los resultados (riesgos descubiertos, puntos). Segundo, presentaremos las herramientas que utilizaremos para revisar nuestra Arquitectura: * Diagramas de rboles.

* Escenarios y casos de uso de los escenarios. * Presentar las salidas de la revisin de la arquitectura y los riesgos encontrados en ella.

Paso 2: Los conductores actuales de negocio. Primero debe presentarse la misma arquitectura: Requerimientos funcionales ms importantes: Contexto del negocio: La alta dirigencia de la empresa de retail El Trbol necesita agilizar los procesos comerciales Online, para ellos es necesaria la construccin de una plataforma que cumpla con todas las caractersticas y estndares a nivel mundial. * Presentacin de los manejadores: Los Ingenieros en Sistemas participan en este diseo de arquitectura. * Descripcin de las restricciones comerciales: Debe seguir los estndares de diseo de la empresa de retail El Trbol. * Descripcin de las restricciones tcnicas: No se cuenta an con la lnea de fibra para la conexin No se ha probado el acoplamiento con los sistemas ya existentes.

Atributos de calidad que se desea tener:

Funcionalidad Confiabilidad Usabilidad Mantencin Seguridad Internacionalizacin Portabilidad Escalabilidad

Paso 3: Arquitectura actual. Conducir requisitos arquitectnicos, las cantidades mensurables asociados con estos requisitos, y cualesquiera normas / modelos / enfoques existentes para el cumplimiento de estos.

Vista de la arquitectura de alto nivel: Funcional: funciones, abstracciones clave del sistema, y elementos de dominio junto con sus dependencias, flujo de datos. Cdigo: los subsistemas, capas y mdulos que describen la descomposicin del sistema de funcionalidad, junto con los objetos, procedimientos y funciones que pueblan estas y las relaciones entre ellos (por ejemplo, el procedimiento de ingreso producto, llamada a un mtodo, Ingreso Producto, contencin). Concurrencia: procesos, subprocesos, junto con la sincronizacin, el flujo de datos y eventos que los conectan. Fsico: CPU, almacenamiento, y dispositivos / sensores externos a lo largo con las redes y dispositivos de comunicacin que los conectan con los dems servidores y con internet. Enfoques arquitectnicos, estilos, patrones, o los mecanismos empleados, incluidos los atributos de calidad, que la direccin y la descripcin de cmo los enfoques abordan esos atributos. Rastreo de 1-3 de los escenarios de casos de uso ms importantes, incluyendo, de ser posible, los recursos de tiempo de ejecucin consumidos para cada escenario. Seguimiento de 1-3 de los escenarios de crecimiento ms importantes, describiendo, en lo posible, el impacto del cambio (tamao / dificultad del cambio estimado) en cuanto a los componentes modificados, conectores o interfaces. Problemas de arquitectura / riesgos en relacin con el cumplimiento de los requisitos de arquitectura de conduccin. Restricciones tcnicas: o o o Respaldos en tiempo real y en caliente. Respaldo de fibra para la conexin y as poder tener 99% up el sitio. Servidores de alta demanda, para poder responder a todas las solicitudes.

Paso 4: Identificar los enfoques arquitectnicos.

El ATAM se concentra en identificar propuestas arquitectnicas y estilos arquitectnicos porque estos representan la manera en que la arquitectura cumple con los atributos de calidad de mayor prioridad, esto significa que se asegura que los requerimientos crticos sern alcanzados de manera predecible. Estas propuestas arquitectnicas definen las estructuras importantes del sistema, y describen como el sistema puede crecer, responder a cambios, entre otros. Un estilo arquitectnico incluye una descripcin de los tipos de componentes y su topologa, una descripcin del patrn de datos y control de interacciones entre componentes, y una descripcin informal de los beneficios y perjuicios que tiene. Un estilo puede ser considerado como un conjunto de restricciones sobre una arquitectura, restricciones sobre los tipos de componentes y sus interacciones, y como esas restricciones definen una familia de arquitecturas que las satisfacen. Al descubrir estilos arquitectnicos en la arquitectura, los evaluadores pueden ver que estrategias utiliz el arquitecto para responder a las metas establecidas por los atributos de calidad del sistema.

Paso 5: Generar atributos de calidad del rbol de utilidad.

Atributo de Calidad
Funcionalidad

Refinamiento del Atributo

Tiempo de Respuesta

Escenarios
Informar de la aceptacin de un alta de actividad en menos de 1,5 seg (H,L) Informar de la aceptacin de la carga de un proceso dado en menos de 1 seg (M,L) Informar de la aceptacin de un pedido de versionado de un proceso en menos de 0.5 seg

confiabilidad

Tiempo de Respuesta

Informar de la fallas al usuario en menos 1,5 seg (H,L) Informar de la fallas al administrador de sistema en menos 1 seg (M,L) Informar de la aceptacin de un pedido de versionado de un proceso en menos de 0.5 seg

usabilidad

Capacidad para ser entendido

Informar de las ayudas al usuario en forma clara y en menos de 10 seg (H,L) Mostrar en forma clara y precisa las diferentes opciones que posee el sitio y su carga no puede ser superior a 6,5 seg (M,L)

mantencin

Capacidad para ser cambiado

Informar al administrador de sistema cualquier inestabilidad que se pueda generar en el sitio y sistema (H,L) Debe poder actualizar el sistema y sitio en un tiempo apropiado y en horarios que no hagan entorpecer el uso normal del sitio para los clientes (M,L) Debe poder tener la capacidad de habilitar y validar el software modificado.

seguridad

Capacidad para encriptar

Informar al administrador de sistema cualquier falla de seguridad que se produzca en el sistema o sitio.

Debe poder guardar e encriptar todos los datos tanto de los clientes como del sitio. Debe poder realizar toda transaccin de pago en menos del 20 seg y con toda seguridad de que los datos estn encriptados. Internacionalidad Capacidad de adaptarse Informar a los usuarios los distintos tipos de lenguajes en menos de 1 seg. Debe realizar la potabilidad en menos de 2 seg y poder ver qu tipo de plataforma mostrar al usuario Debe poder manejar msa de 5mil visitas simultaniamente.

Portabilidad

Tiempo de Respuesta

Escabilidad

Tiempo de Respuesta

Escenarios de Caso de Uso: Los escenarios de caso de uso describen una interaccin completa del usuario con el sistema corriendo. Por ejemplo, un usuario solicita un informe a una base de datos va Web durante un perodo pico y lo recibe en cinco segundos (performance). Notar que los escenarios de caso de uso expresan deseos especficos de los stakeholders. Escenarios de Crecimiento: Los escenarios de crecimiento representan cambios tpicos anticipados a un sistema. Cada escenario tambin tiene ramificaciones por atributos relacionados. Por ejemplo, el escenario migrar a un sistema operativo de la misma familia, o a una nueva versin del sistema operativo existente con menos de un ao-persona de trabajo, tiene implicaciones de performance, security y reliability. Escenarios exploratorios: Los escenarios exploratorios estresan el sistema. El objetivo de estos escenarios es exponer las condiciones lmite del diseo actual, exponiendo posibles suposiciones implcitas. Los sistemas son raramente concebidos o diseados para manejar esta clase de modificaciones, pero en el futuro estos podran cambiar a requerimientos reales, entonces a los stakeholders les podra gustar entender las ramificaciones de dichos cambios. Por ejemplo, cambiar la plataforma Unix subyacente a Macintosh. Cada tipo de escenario (de caso de uso, de crecimiento y exploratorio) ayuda esclarecer los diferentes aspectos de la arquitectura, y juntos proveen una estrategia de evaluacin de tres puntas. Los escenarios son un excelente vehculo con el cual todos los stakeholders comunican sus intereses arquitectnicos.

Paso 6: Analizar los enfoques arquitectnicos (Templates). Anlisis de una Propuesta Arquitectnica Escenario # 1 Detectar y Recuperarse de fallo Hardware de una CPU primaria Atributo: disponibilidad Entorno: Operacin Normal Estmulo: Una de las CPU falla Respuesta: en 0.99999 Decisin Arquitectnica Sensitivity Tradeoff Riesgo No Riesgo

Elemento 1 (viene del Utility Tree) Elemento 2 Razonamiento S1 disminuye la confiabilidad debido a La falla del hardware S2 Aumenta la confiabilidad debido al cambio oportuno del hardware pero disminuye la performance en 1,5 segundos R1 Aumenta el Riesgo que los datos quedan inconsistentes antes una eventual falla R2 Aumento en la dependencia entre la aplicacin y la BD T1 Mejora la performance en XX pero disminuye la mantenibilidad en YY T2 Mejora la performance en XX pero disminuye la reusability en YY T3 Aumenta la reusability en XX, pero empeora la performance en YY

Paso 7: Lluvia de ideas y priorizar escenarios (Anotacin de los atributos de calidad). rboles de utilidad Stakeholders tamao del grupo tpico Arquitectos, responsable del proyecto evaluadores; 2-3 personal de proyectos escenario de intercambio de ideas Todos los Stakeholders evaluadores, 5-10 de personal relacionados con el proyecto fomentar la comunicacin va para validar los objetivos de atributos de calidad provocada por el rbol de utilidad

objetivos principales

Concretar y priorizar las necesidades de atributos de calidad de conduccin. Proporcionar un enfoque para el restante der de la evaluacin.

enfoque

General a lo especfico: comenzar con los atributos de calidad, mejorar hasta que emerjan los escenarios.

Especfico a lo general: comienza con los escenarios, luego identificar los atributos de calidad que expresan

Stakeholders para Evaluacin de Arquitectura Stakeholders productores del sistema Arquitectos de Software Persona responsable de las arquitectura del sistema y responsable por el realizado intercambios entre presiones calidad competencias. programador o diseador La moderacin y la mediacin de todos los problemas de calidad de la otra Stakeholders. Definicin Intereses

Developer

Claridad y exhaustividad de descripcin de la arquitectura, alta cohesin de las partes, el acoplamiento limitado de piezas, mecanismos

de interconexin claras mantenedor persona que hace los cambios despus de la implementacin inicial mantenimiento, capacidad de localizar cada lugar en el sistema que debe cambiar en respuesta a una modificacin mismo que devoloper

integrador

desarrollador responsable de la integracin (montaje) de los componentes desarrollador responsable de probar el sistema

Tester

integrado , protocolos de control de errores consistentes integrados acoplamiento componente limitado, alta cohesin componente; integridad conceptual Separacin de preocupaciones, modificabilidad, la interoperabilidad.

Experto Estndar

Desarrollador responsable de conocer los detalles de las normas (actuales y futuros) a los que el software debe cumplir. Persona que analiza los artefactos del sistema para ver si el sistema cumplir su desempeo y requisitos de rendimiento. Persona responsable de asegurarse de que el sistema cumpla con sus requisitos de seguridad. Persona que asigna recursos a los equipos, se hace responsable de calendario de reuniones y el presupuesto, las interfaces con los clientes.

ingeniero de funcionamiento

comprensibilidad, integridad conceptual, fiabilidad de funcionamiento

experto en seguridad

Seguridad.

gerente de proyecto

estructuracin clara de la arquitectura para impulsar la formacin del equipo, la estructura de desglose del trabajo, los hitos y los plazos, etc

Administradores del sistema administrador del sistema Persona que ejecuta el sistema (es diferente del La facilidad en encontrar la ubicacin de los

usuario). Administrador de la red. Persona que administra la red.

problemas que puedan surgir. Rendimiento de la red, la previsibilidad.

Stakeholders y Viewpoints Stakeholder Gerencia (Director General, Gerente Comercial, Gerente TIC).
Arquitecto de sistema Administrativos

Viewpoints Punto de Vista Funcional Punto de Vista de Despliegue, Punto de vista funcional, Punto de vista de informacin Punto de Vista Funcional Punto de Vista Funcional Punto de Vista Funcional Punto de Vista Funcional

Clientes Proveedores Futuros Clientes

Paso 8: Analizar los enfoques arquitectnicos (Reiterar las jerarquas).

En este paso el equipo de evaluacin realiza las mismas actividades que en el paso 6, mapeando los escenarios recientemente generados con ranking ms alto en los artefactos arquitectnicos. Como este es un paso de prueba, se espera que poca informacin sea descubierta.

Paso 9: Presentar los resultados (riesgos descubiertos, puntos).

Finalmente, la informacin recogida por el ATAM necesita ser resumida y presentada a los stakeholders. En esta presentacin el lder de la evaluacin recapitula los pasos del ATAM y toda la informacin recogida en cada paso, incluyendo el contexto del negocio, los requerimientos guas, las restricciones, y la arquitectura. Pero ms importante son las salidas del ATAM: El documento de propuestas arquitectnicas. El conjunto de escenarios priorizados. El conjunto de preguntas basadas en los atributos. El rbol de utilidad.

 Pasos de ATAM

Los riesgos descubiertos. Los no riesgos documentados. Los sensitivity points y tradeoff points encontrados. Declaracin priorizada de necesidades de atributos de calidad. Catlogo de enfoques arquitectnicos utilizados. Enfoque y preguntas de anlisis especficos de calidad. Mapeo de los enfoques arquitectnicos a los atributos de calidad. Riesgos y no Riesgos Sensibilidad y puntos relaciones de intercambio.

Presentando a ATAM Los conductores actuales de negocio. Arquitectura actual. Identificar los enfoques arquitectnicos. Generar atributos de calidad del rbol de utilidad Analizar los enfoques arquitectnicos (Templates). Lluvia de ideas y priorizar ** ** * *

**

**

**

**

**

**

**

escenarios (Anotacin de los atributos de calidad). Analizar los enfoques arquitectnicos (Reiterar las jerarquas). Presentar los resultados (riesgos descubiertos, puntos). * ** ** ** **

Clave: ** = el paso es un contribuyente principal a la salida; * = El paso es un contribuyente secundario.

Bibliografa paso 3 y 4 http://www.slideshare.net/JoanManuelZabala/atributos-de-calidad-en-el-desarrollo-de-software Bibliografa ATAM http://www.buenastareas.com/ensayos/Ejemplo-Revision-Con-Atam/4418346.html