Exposicion evaluacion e_arquitecturas_de_softw

1,304 views
1,191 views

Published on

Exposicion de Evaluacion de Arquitecturas de Software

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,304
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Exposicion evaluacion e_arquitecturas_de_softw

  1. 1. CURSO DE TOPICOS AVANZADOS DE INGENIERIA DE SOFTWARE Evaluacion de Arquitecturas de Software David Lorett Velasquez Universidad de Cartagena - 2010
  2. 2. Escenario <ul><li>Un escenario es una secuencia especifica de pasos que involucra el uso o la modificación del sistema. </li></ul><ul><li>Estimulo   - Ambiente - Respuesta </li></ul><ul><li>Escenario de Caso de Uso Un usuario remoto de web requiere un reporte de bases de datos en hora pico y lo recibe a los 10 segundos Escenario exploratorio La mitad de los servidores se bajara durante operacion normal sin afectar la disponibilidad del sistema </li></ul>
  3. 3. ¿Por que Evaluar Arquitecturas? <ul><ul><li>Por razones económicas.1 </li></ul></ul><ul><ul><li>Fuerza la preparación de material para la revisión </li></ul></ul><ul><ul><li>Captura las motivaciones detrás de la arquitectura </li></ul></ul><ul><ul><li>Detección temprana de problemas </li></ul></ul><ul><ul><li>Validación de requerimientos </li></ul></ul><ul><ul><li>Para tomar mejores decisiones </li></ul></ul><ul><li>1.  http://www.gestiopolis.com/administracion-estrategia/procedimiento-para-la-evolucion-de-las-arquitecturas-de-software.htm </li></ul><ul><li>  </li></ul>
  4. 4. ¿Como saber si mi arquitectura es la correcta? <ul><li>Las decisiones arquitectonicas influyen directamente en la calidad del Software, entonces es posible evaluar dichas decisiones con respecto a su impacto sobre dichos atributos. </li></ul><ul><li>Cuanto mas temprano se encuentre un problema en un proyecto de Software, mucho mejor; Revisar la arquitectura es la manera mas economica de evitar desastres. </li></ul>
  5. 5. P recondiciones y Dificultades <ul><ul><li>Alcance definido y controlado </li></ul></ul><ul><ul><li>Relacion de Beneficio-Costo </li></ul></ul><ul><ul><li>Equipo de evaluacion para componentes </li></ul></ul><ul><ul><li>Multiples StakeHolders </li></ul></ul><ul><ul><li>Diferentes Valoraciones de la utilidad del sistema </li></ul></ul>
  6. 6. Técnicas de Evaluación
  7. 7. Fases de Evaluacion
  8. 8. ¿Por qué cualidades puede ser evaluada una Arquitectura? <ul><ul><li>  Observables vía ejecución: aquellos atributos que se determinan del comportamiento del sistema en tiempo de ejecución.  </li></ul></ul><ul><ul><li>  No observables vía ejecución: aquellos atributos que se establecen durante el desarrollo del sistema </li></ul></ul>
  9. 9. Atributos de calidad observables vía ejecución  <ul><li>Atributo de Calidad </li></ul>
  10. 10. Atributos de calidad no observables vía ejecucion <ul><li>  </li></ul>
  11. 11. ¿Qué resultados produce la evaluación de una Arquitectura? <ul><ul><li>¿Se ha diseñado la arquitectura más apropiada para el sistema? </li></ul></ul><ul><ul><li>¿Cuál de las arquitecturas propuestas es la más apropiada para el sistema a construir? </li></ul></ul><ul><ul><li>Lista priorizada de los atributos de calidad requeridos para la arquitectura que está siendo evaluada. </li></ul></ul><ul><ul><li>Riesgos y no riesgos. </li></ul></ul>
  12. 12. Presentacion de Resultados <ul><li>  P resentación de los resultados. </li></ul><ul><li>Para finalizar la aplicación del método se presenta un resumen de la aplicación del método, de forma oral y/o escrita. Se deben incluir entonces, los siguientes documentos a partir de los cuales se inició la evaluación: </li></ul><ul><li>a) Contexto del negocio. b) Requerimientos de Calidad. c) Restricciones. d) Arquitectura producida. e) Análisis de elementos de diseño identificados. f) Conjunto de escenarios negociados. g) Conjunto de preguntas para evaluación de atributos. h) Árbol de Utilidad. i) No-riesgos documentado. j) Puntos sensibles y de negociación. </li></ul>
  13. 13. Arbol de Propiedades Característica Sub-característica Escenario Fiabilidad Madurez Los componentes del sistema manejan entradas de datos de datos incorrectas. Tolerancia a fallas Todas las operaciones ejecutadas por los componentes se realizan correctamente bajo condiciones adversas. Capacidad de restablecimiento o recuperación Los componentes del sistema no fallan bajo ciertas condiciones especificadas. Ante problemas con el ambiente un subconjunto determinado de los componentes puede continuar prestando sus servicios.
  14. 14. Metodologias mas utilizadas <ul><li>ATAM : Encuentra puntos sensitivos y Trade-offs entre atributos de calidad </li></ul><ul><li>ALMA : Predice la facilidad de modificación </li></ul><ul><li>ARID : El método ARID evalúa mejor la factibilidad de la arquitectura. </li></ul><ul><li>SNA : Este método ayuda a identificar la capacidad que tiene un sistema para completar su misión a tiempo, ante la presencia de ataques, fallas o accidentes.  </li></ul>
  15. 15. Comparativa   ATAM SAAM ARID Atributos de Calidad Contemplados Modificabilidad Modificabilidad Conveniencia del diseño evaluado Seguridad Funcionabilidad Confiabilidad Desempeño Objetos Analizados Estilos Arquitectónicos, Documentación, Flujo de Datos y Vistas Arquitectónicas Documentación, y Vistas Arquitectónicas Especificación de los componentes Etapas del Proyecto en las que se Aplica Luego que el diseño de la arquitectura ha sido establecido Luego que la arquitectura cuenta con funcionalidad ubicada en módulos A lo largo del diseño de la arquitectura Enfoques Utilizados Árbol de Utilidad y lluvia de ideas para articular los requerimientos de calidad. Lluvia de ideas para escenarios y articular los requerimientos de calidad. Revisiones de diseño, lluvia de ideas para obtener escenarios. Análisis arquitectónico que detecta puntos sensibles, puntos de balance y riesgos. Análisis de los escenarios para verificar funcionalidad o estimar el costo de los cambios.
  16. 16. CONCLUSIONES <ul><li>Es bueno destacar que un método de evaluación no es mejor que otro, sino que evalúa mejor, en ciertas condiciones, un atributo de calidad dado por lo que en dependencia de las condiciones y lo que se desea evaluar, será el método de evaluación empleado (que no tiene que ser solo uno). </li></ul>
  17. 17. Bibliografia <ul><li>http://www.gestiopolis.com/administracion-estrategia/procedimiento-para-la-evolucion-de-las-arquitecturas-de-software.htm </li></ul><ul><li>www.fing.edu.uy/.../ Evaluacion %20de%20 Arquitecturas %20.../ Evaluacion %20de%20 Arquitecturas .pp </li></ul><ul><li>www.lisi.usb.ve/publicaciones/03%20 evaluacion / evaluacion _09.pdf </li></ul>
  18. 18. GRACIAS

×