Correspondencias entre las vistas del modelo

RM-ODP ofrece los diagramas de correspondencia para facilitar la transformación entre modelos. La correspondencia es realizada entre componentes, inicialmente entre la vista empresarial y la vista de la información, posteriormente cuando es definida la vista computacional es definida la correspondencia entre la misma y las dos vistas previamente diseñadas. A continuación son presentadas las correspondencias del modelo arquitectónico.

72 4.3.Construcción del modelo arquitectónico de interoperabilidad

Correspondencia Vista empresarial y de la información.

Al relacionar las dos vistas puede garantizarse que la información requerida en los procesos descritos a nivel empresarial sea suficiente o posea una correlación que los soporte.

Figura 26. Correspondencia entre vista empresarial y de la información. La figura 26 presenta tres componentes de correspondencias que agrupan de forma general las razones esenciales de necesidades e información de las dos vistas.

Correspondencia entre vista empresarial y computacional

A través de esta correspondencia son establecidos los componentes necesarios para garantizar el cumplimiento de los requisitos y necesidades definidas en la vista empresarial. Tal como en la anterior correspondencia la figura 27 presenta la agrupación de acuerdo a las funcionalidades requeridas en el proceso de interoperabilidad.

4. Modelo arquitectónico de interoperabilidad entre las IPS 73 Finalmente cada componente de correspondencia representa a la capacidad que ofrecen los componentes computacionales para afrontar las necesidades empresariales.

Correspondencia entre la vista de la información y la computacional

Con la correspondencia entre las vistas de información y computacional es definido el soporte de información necesario para garantizar la gestión de información, la interoperabilidad, la seguridad y acceso de la información al igual que a los servicios tal como es representado en la figura 28.

Figura 28. Correspondencia entre vista de la información y computacional

4.4. Conclusiones

Este capítulo expuso el modelo arquitectónico propuesto para la interoperabilidad entre las IPS, presentado a través de las distintas vistas establecidas por RM- ODP. Utiliza SOA para el desarrollo del modelo y el uso del estándar de mensajería para compartir los documentos clínicos a un nivel de interoperabilidad más adecuado. El modelo a través de las distintas vistas justifica la información a tratar, presenta las necesidades de interoperabilidad obtenidas por normatividad y las identificadas en la caracterización. Además, usa un modelo mediador implementado con un ESB para soportar los componentes necesarios para el intercambio de información, a través de servicios extraídos del negocio y las necesidades de seguridad para respaldar el transporte y el acceso a la información. Finalmente, el modelo propuesto satisface en gran parte las

74 4.4.Conclusiones necesidades del sector salud, fortalecido por tecnología al alcance de las IPS y el estado. Sin embargo es necesario realizar proyectos con el fin de apoyar las IPS en el mejoramiento de la infraestructura de comunicación, de equipos tecnológicos y el fortalecimiento de la infraestructura nacional de interoperabilidad que estaría gestionada directamente por el estado.

75

Capítulo 5

Validación del modelo arquitectónico

propuesto

5.1. Introducción

Con base en el modelo general de caracterización definido en el capítulo 3, se elaboró el modelo arquitectónico de interoperabilidad presentado en el capítulo 4, para el cuál es indispensable realizar una validación formal. (Barr, 2001) presenta el conflicto entre los términos validación, verificación, testeo y evaluación argumentando que en la literatura son considerados como conceptos diferentes, fases dentro de un proceso de revisión o técnicas que varían de acuerdo a unos objetivos planteados. Finalmente el autor concluye que los términos en si son equivalentes dentro de una escala de revisión, la cual varia teniendo en cuenta el nivel de detalle y refinamiento del producto software en cuestión. Por tanto se podría establecer que una evaluación de una arquitectura es equivalente a una validación de alto nivel, lo que implicó que para dar cumplimiento al objetivo específico planteado en la presente tesis, fuese necesario evaluar formalmente el modelo arquitectónico propuesto, usando un método formal seleccionado bajo los criterios correctos.

Cabe mencionar la forma en que son organizadas las evaluaciones de productos y procesos software son: (i) la experimentación en ingeniería de software, donde muchos sujetos (por ejemplo, ingenieros de software) realizan una o varias tareas

76 5.1.Introducción utilizando los diferentes métodos investigados. Los sujetos son asignados a cada método de forma que los resultados son imparciales y pueden ser analizados empleando técnicas estadísticas estándar, (ii) un estudio de caso, donde cada método que está siendo investigando sea probado en un proyecto real utilizando procedimientos para el desarrollo de un proyecto estándar de la organización que está realizando la evaluación y (iii) una encuesta, donde el personal/organizaciones que han empleado métodos en proyectos pasados son interrogados para que proporcionen información sobre dicho método. La información de los usuarios puede ser analizada utilizando técnicas estadísticas estándar. Sin embargo, no hay claridad acerca de cómo organizar la evaluación del modelo arquitectónico. DESMET(Kitchenham, 1996) ofrece una metodología para seleccionar uno de ellos, propone también nueve métodos que involucran las tres formas de organización de evaluaciones y la técnica para la aplicación del método seleccionado. Lo anterior fue un factor decisivo para seleccionar a DESMET para la evaluación del modelo arquitectónico propuesto, ya que ofrece un proceso integrar que incluye la metodología, los métodos de evaluación y la técnica a utilizar.

Analizado el modelo arquitectónico y las condiciones del proyecto con base en la evaluación de condiciones y aspectos favorables propuestos por DESMET, el método a utilizar seleccionado es el Análisis de Características por encuesta, descartando así todo método basado en estudio de casos y experimentos.

Existen otras aproximaciones válidas para la evaluación de arquitecturas (Delgado, Castro, & Germán, 2007; Losavio, F., Chirinos, 2007; Roy & Graham, 2008) algunas mayormente reconocidas son: (i) Software Architecture Analysis Method (SAAM) (Dobrica & Niemela, 2002), (ii) Architecture Tradeoff Analysis Method (ATAM) (Delgado et al., 2007; Islam & Rokonuzzaman, 2009), Architecture-Level Modifiability Analysis (ALMA) (Bengtsson, Lassing, Bosch, & Vliet, 2004), Layered Queuing Network (LQN) (Franks et al., 1995), SAM (Reussner, Schmidt, & Poernomo, 2003), etc. Sin embargo, algunos fueron pensados originalmente para el diseño de arquitecturas, para evaluar atributos de calidad muy específicos y a arquitecturas a niveles de detalle muy alto. Con DESMET fue posible definir una evaluación acorde a la necesidad, gracias a su facilidad de adaptación sin importar el tipo de producto o el alto nivel de especificación de la arquitectura.

5. Validación del modelo arquitectónico propuesto 77