arquitectura de software para la gesti on del proceso de...

Arquitectura de software para la gestion del proceso de validacion de nucleosfamiliares

Caso de Estudio: La Unidad para la Atencion y Reparacion Integral a las Vıctimas.

Alvaro Tovar CasallasCodigo: 20161099043

Universidad Distrital Francisco Jose de CaldasFacultad de Ingenierıa

Especializacion En Ingenierıa De SoftwareBogota D.C. 2016

Indice general

Introduccion 8

I Contextualizacion de la Investigacion 11

1. Descripcion de la Investigacion 131.1. Identificacion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4. Hipotesis de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5. Marco Referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.5.3. Marco Legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.6. Organizacion de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.6.1. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.6.2. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.6.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.6.4. Estructura Organica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.5. Funciones Organizacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.6. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.7. Estudios de Sistemas Previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

II Desarrollo de la Investigacion 31

2. Aspectos Metodologicos y Cronograma 332.0.1. Tipo de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.0.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.0.3. Fuentes tecnicas para la recoleccion de informacion . . . . . . . . . . . . . . 352.0.4. Tratamiento de la informacion . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.1. Alcances, limitaciones y resultados esperados . . . . . . . . . . . . . . . . . . . . . 352.1.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.1.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1.3. Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.2. Cronograma de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3

4 INDICE GENERAL

2.3. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.1. Costos pos servicios personales . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.2. Gastos Personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.3. Costo Total del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3. Ingenierıa del Proyecto 393.1. Fase Inicializacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.1. Requerimientos del sistema propuesto . . . . . . . . . . . . . . . . . . . . . 413.2. Fase Elaboracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1. Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3. Fase Construccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.3.1. Analisis y Diseno de la Solucion . . . . . . . . . . . . . . . . . . . . . . . . 763.3.2. Descripcion de la Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . 773.3.3. Especificaciones de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.4. Fase Transicion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.4.1. construccion del ambiente de Pruebas . . . . . . . . . . . . . . . . . . . . . 82

4. Diseno y Construccion del prototipo 834.1. Caracterısticas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.1.1. Patrones de diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.1.2. Definicion de Componentes de software . . . . . . . . . . . . . . . . . . . . 85

III Cierre de la Investigacion 89

5. Resultados y Discusion 915.1. Pruebas al Modelo de Negocios definido . . . . . . . . . . . . . . . . . . . . . . . . 915.2. Pruebas a los Casos de Uso Establecidos . . . . . . . . . . . . . . . . . . . . . . . . 915.3. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.3.1. Conexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.3.2. Funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.3.3. Confiabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.3.4. Eficiencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.3.5. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.3.6. Portabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.3.7. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.4. Navegacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6. Conclusiones y Recomendaciones 956.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Bibliografıa 97

Anexo A - Matriz de Riesgos para el Desarrollo del Proyecto 99

Anexo B - Definicion y Descripcion de tipos de pruebas de Software 101

Indice de figuras

1.1. Diagrama Modelo Cliente-Servidor. Fuente: [Codejobs, 2015] . . . . . . . . . . . . 161.2. Modelo de Arquitectura Orientada a Servicios. Fuente: [Saiz, 2015] . . . . . . . . . 171.3. Diagrama Modelo 3 Capas Arquitectura n-Capas. Fuente: [Alfsan, 2012] . . . . . . 181.4. Diagrama Arquitectura Orientada a Eventos EDA. Fuente: [Saiz, 2015] . . . . . . . 181.5. Ejemplo de Arquitectura ESB. Fuente: [Tijs Rademakers, 2008] . . . . . . . . . . . 191.6. Correspondencia entre TOGAF y el Ciclo ADM de Archimate incluyendo las exten-

siones. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.7. Fases de RUP. Fuente: [Rodrıguez, 2012] . . . . . . . . . . . . . . . . . . . . . . . . 231.8. Los Servicios Web en Funcionamiento. Fuente: [W3C, 2012] . . . . . . . . . . . . . 251.9. Orquestacion y Coreografıa de Servicios Web. Fuente: [Perez, 2012] . . . . . . . . . 261.10. Modelo Organizacional UARIV. Fuente: [UARIV, 2012] . . . . . . . . . . . . . . . 29

2.1. Diagrama de Gantt del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1. caso de uso general para la solucion propuesta . . . . . . . . . . . . . . . . . . . . . 403.2. Meta Modelo punto de vista de la organizacion . . . . . . . . . . . . . . . . . . . . 443.3. Modelo punto de vista de la organizacion . . . . . . . . . . . . . . . . . . . . . . . 443.4. Meta Modelo punto de vista cooperacion actor . . . . . . . . . . . . . . . . . . . . 453.5. Modelo punto de vista cooperacion actor . . . . . . . . . . . . . . . . . . . . . . . . 453.6. Meta Modelo punto de vista Funcion de Negocio . . . . . . . . . . . . . . . . . . . 463.7. Modelo punto de vista funcion de negocio . . . . . . . . . . . . . . . . . . . . . . . 463.8. Meta Modelo punto de vista Proceso de Negocio . . . . . . . . . . . . . . . . . . . 473.9. Modelo punto de vista Proceso de negocio Administrador Indemniza . . . . . . . . 483.10. Modelo punto de vista Proceso de negocio (Documentador) . . . . . . . . . . . . . 483.11. Meta Modelo punto de vista Cooperacion Proceso de negocio . . . . . . . . . . . . 493.12. Modelo punto de vista Cooperacion Proceso de negocio . . . . . . . . . . . . . . . 503.13. Meta Modelo punto de vista Producto . . . . . . . . . . . . . . . . . . . . . . . . . 513.14. Modelo punto de vista Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.15. Meta Modelo punto de vista Comportamiento Aplicacion . . . . . . . . . . . . . . 523.16. Modelo punto de vista Comportamiento Aplicacion . . . . . . . . . . . . . . . . . . 523.17. Meta Modelo punto de vista Cooperacion Aplicacion . . . . . . . . . . . . . . . . . 533.18. Modelo punto de vista Cooperacion Aplicacion . . . . . . . . . . . . . . . . . . . . 543.19. Meta Modelo punto de vista Estructura de Aplicacion . . . . . . . . . . . . . . . . 543.20. Modelo punto de vista Estructura de Aplicacion . . . . . . . . . . . . . . . . . . . 553.21. Meta Modelo punto de vista Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . 563.22. Modelo punto de vista Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . 563.23. Meta Modelo punto de vista Infraestructura . . . . . . . . . . . . . . . . . . . . . . 57

5

6 INDICE DE FIGURAS

3.24. Modelo punto de vista Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . 583.25. Meta Modelo punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . . . . 583.26. Modelo punto de vista uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . 593.27. Meta Modelo punto de vista Implementacion y Organizacion . . . . . . . . . . . . 603.28. Modelo punto de vista Implementacion y Organizacion . . . . . . . . . . . . . . . . 613.29. Meta Modelo punto de vista Estructura de Informacion . . . . . . . . . . . . . . . 613.30. Modelo punto de vista Estructura de Informacion . . . . . . . . . . . . . . . . . . . 623.31. Meta Modelo punto de vista Realizacion de Servicio . . . . . . . . . . . . . . . . . 633.32. Modelo punto de vista Realizacion de Servicio . . . . . . . . . . . . . . . . . . . . . 633.33. Modelo punto de vista Realizacion de Servicio . . . . . . . . . . . . . . . . . . . . . 643.34. Meta Modelo punto de vista Implicados . . . . . . . . . . . . . . . . . . . . . . . . 653.35. Modelo punto de vista Implicados . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.36. Meta Modelo punto de vista Realizacion de Objetivos . . . . . . . . . . . . . . . . 663.37. Modelo punto de vista Realizacion de Objetivos . . . . . . . . . . . . . . . . . . . . 673.38. Meta Modelo punto de vista Contribucion . . . . . . . . . . . . . . . . . . . . . . . 673.39. Modelo punto de vista Contribucion . . . . . . . . . . . . . . . . . . . . . . . . . . 683.40. Meta Modelo punto de vista Principio . . . . . . . . . . . . . . . . . . . . . . . . . 683.41. Modelo punto de vista Principios - Objetivo 1 . . . . . . . . . . . . . . . . . . . . . 693.42. Modelo punto de vista Principios - Objetivo 2 . . . . . . . . . . . . . . . . . . . . . 693.43. Meta Modelo punto de vista Realizacion de Requerimientos . . . . . . . . . . . . . 703.44. Modelo punto de vista Realizacion de Requerimientos . . . . . . . . . . . . . . . . 703.45. Meta Modelo punto de vista Motivacion . . . . . . . . . . . . . . . . . . . . . . . . 713.46. Modelo punto de vista Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.47. Meta Modelo punto de vista Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 723.48. Modelo punto de vista Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.49. Meta Modelo punto de vista Migracion . . . . . . . . . . . . . . . . . . . . . . . . . 733.50. Modelo punto de vista Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.51. Meta Modelo punto de vista Implementacion Migracion . . . . . . . . . . . . . . . 753.52. Modelo punto de vista Implementacion Migracion . . . . . . . . . . . . . . . . . . . 753.53. Interoperabilidad del sistema Indemniza remoto y el sistema Indemniza local . . . 763.54. Interoperabilidad del sistema Indemniza remoto y el sistema Indemniza local . . . 773.55. Modelo Relacional BD Indemniza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.56. Diagrama de Actividad, Descarga de Datos a BD Local . . . . . . . . . . . . . . . 803.57. Diagrama de Actividad, Sincronizacion con la BD Remota . . . . . . . . . . . . . . 81

4.1. Creacion automatica de la clase persona, realizada por las funcionalidades dispuestaspor Entity Framework de ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2. Ejemplo de instanciacion de la clase Persona para la insertar datos en la base dedatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.3. Validacion de credenciales de acceso desde el modulo Login del prototipo. . . . . . 864.4. Modulo de descarga de datos desde el sistema remoto al sistema local . . . . . . . 864.5. Codigo fuente contrato sincronizacion entre sistema local y remoto . . . . . . . . . 87

6.1. Codigo fuente contrato sincronizacion entre sistema local y remoto . . . . . . . . . 100

Indice de cuadros

2.1. Cronograma general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2. Costos pos servicios personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3. Gastos Personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1. Especificacion del requerimiento funcional 01 . . . . . . . . . . . . . . . . . . . . . 413.2. Especificacion del requerimiento funcional 02 . . . . . . . . . . . . . . . . . . . . . 413.3. Especificacion del requerimiento no funcional 01 . . . . . . . . . . . . . . . . . . . . 423.4. Especificacion del requerimiento no funcional 02 . . . . . . . . . . . . . . . . . . . . 423.5. Especificacion del requerimiento no funcional 03 . . . . . . . . . . . . . . . . . . . . 423.6. Especificacion del requerimiento no funcional 04 . . . . . . . . . . . . . . . . . . . . 43

5.1. Especificaciones de la maquina usada para el ambiente de pruebas de la solucion . 92

6.1. Metodo de Pruebas Orientada a Objetos para el Ciclo de Vida Completo (FLOOT).Fuente [Ambler, 2012] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7

8 INDICE DE CUADROS

Introduccion

La Unidad para la Atencion y Reparacion Integral a las Vıctimas, es la entidad definida por elgobierno nacional colombiano, para adelantar el proceso de identificacion, atencion y reparacion delos ciudadanos que han sido vıctimas del conflicto armado al interior del paıs, dentro del procesode reparacion implementado por la entidad, se contemplan 5 medidas a reconocer a las personasincluidas en el registro unico de vıctimas, en donde una de las medidas corresponde a la mate-rializacion de una indemnizacion por vıa administrativa a nombre de la vıctima, la cual busca lareconstruccion del proyecto de vida del nucleo familiar que se vio afectado por el conflicto armadocolombiano, actualmente para poder hacer efectivo el tramite de la medida de indemnizacion, serequiere realizar un proceso de documentacion con las vıctimas, con el fin de realizar la actuali-zacion de la informacion previamente registrada en el sistema y validar los integrantes del nucleofamiliar afectado para ası realizar la distribucion de la medida de indemnizacion segun lo dicta laLey 1448.

Al culminar el presente proyecto, se va a estructurar el modelo actual del proceso de documentacionde vıctimas, con el fin de ampliar el espectro de victimas atendidas por la entidad, sin importar suubicacion dentro del territorio nacional y el acceso a las tecnologıas de informacion centrando suenfoque al acceso a Internet del que dispongan.

9

10 INDICE DE CUADROS

Parte I

Contextualizacion de laInvestigacion

11

Capıtulo 1

Descripcion de la Investigacion

1.1. Identificacion del problema

Para llevar a cabo el proceso de documentacion mencionado en la introduccion del proyecto, laentidad establece unas jornadas de atencion a vıctimas en las cuales sus funcionarios se desplazanhasta ciudades y poblaciones dentro y fuera del territorio nacional colombiano, con el fin de dar laoportunidad a las vıctimas de conocer el estado actual de su proceso de reparacion, y realizar lostramites pertinentes para acceder a las medidas de reparacion contempladas por la ley.

El resultado del proceso de documentacion mencionado anteriormente, es principalmente contro-lado y almacenado en la herramienta Indemniza, en esta herramienta se almacena la informacionsobre las vıctimas del conflicto armado, que ya han sido identificadas por el area encargada alinterior de la entidad, y que pueden iniciar su proceso de reparacion. Esta herramienta funcionaen un ambiente web y es de acceso autorizado para los funcionarios de la entidad que justifiquenel acceso a la informacion que reposa en ella.

Segun lo mencionado anteriormente, el almacenamiento de la informacion recopilada en el pro-ceso de documentacion de vıctimas, se ve restringido al acceso a la herramienta Indemniza a travesde un dispositivo conectado a Internet, lo cual implica que para la atencion de victimas ubicadasen poblaciones con limitaciones en el acceso a las tecnologıas de informacion, se deben implementarmecanismos alternos de recoleccion de datos dentro de los cuales se contemplan las bases de datosen formato Excel, o recoleccion manual de informacion que posteriormente debe ser ingresada alsistema.

Lo anterior ocasiona perdida parcial o total de la informacion recopilada en dichas jornadas, debidoa que las bases de datos en formato Excel contemplan datos basicos y carecen de un formato defi-nido, la caligrafıa del funcionario que ejecuta el proceso no es clara o, los documentos recopiladossufren danos durante su almacenamiento fısico. Por lo cual la informacion que posteriormente escargada al sistema, figura incompleta o no es de gran utilidad para el proceso de reparacion de lasvıctimas, lo cual genera demoras en el proceso y molestias en las vıctimas las cuales acuden a lasvıas judiciales para agilizar el tramite.

Para subsanar esta falla, se requiere el desarrollo de una extension de la herramienta Indemni-za, que implementando una arquitectura de software orientada a servicios asegure en primerainstancia, la captura de datos y permita el almacenamiento de la informacion de las victimas asis-

13

14 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION

tentes a los espacios de atencion y, que en segunda instancia se sincronice con el sistema principalpara llevar el control de esta informacion desde el mismo.

Formulacion del problema ¿Cual debe ser la arquitectura de software ideal, que asegure el inter-cambio de informacion entre la herramienta Indemniza y la extension de sı misma, para desarrollarel proceso de documentacion de vıctimas del conflicto armado en poblaciones con restricciones deacceso a tecnologıas de informacion?

Sistematizacion del problema

¿Cual es la manera adecuada para actualizar la informacion sobre vıctimas del conflictoarmado con los insumos recopilados en las jornadas de atencion a vıctimas?

¿Como debe funcionar la arquitectura disenada, con el fin de asegurar que la informacion delas vıctimas se actualice y almacene de manera segura y sea trasmitida al sistema principalpara su disposicion?

1.2. Objetivos

1.2.1. Objetivo General

Estructurar el sistema usado por la Unidad para la Atencion y Reparacion Integral a la Victi-mas para funcionar sin conexion con el sistema principal, mediante el diseno de una arquitecturaorientada a servicios, con el fin de adelantar procesos de documentacion de personas en lugares sinconexion a Internet.

1.2.2. Objetivos Especıficos

Analizar el proceso actual de documentacion de vıctimas del conflicto armado desarrolladopor la Unidad para la Atencion y Reparacion Integral a las Victimas, mediante el estudiode la documentacion suministrada por la entidad, con el fin de conocer su implementacion atraves del sistema de informacion definido para tal fin.

Documentar la arquitectura disenada, basandose en el estandar ISO/IEC 42010 para facilitarsu implementacion por parte de la entidad.

Determinar una metodologıa de desarrollo que permita disenar y modelar cada uno de losrequerimientos planteados por los actores intervinientes del sistema.

1.3. Justificacion

El desarrollo del presente proyecto, se centra en complementar y fortalecer el proceso actualde documentacion de personas gestionado por la Unidad para la Atencion y Reparacion Integral alas Victimas, esto con el fin de minimizar el riesgo de perdida de informacion que actualmente sepresenta en la entidad, ya que como se menciono anteriormente en lugares de difıcil acceso a lasTIC, la informacion recolectada no es consistente y no se almacena en optimas condiciones parasu tratamiento y posterior utilizacion por las areas de la entidad que lo requieran.

Con la implementacion de la arquitectura disenada como resultado del proyecto, se busca que

1.4. HIPOTESIS DE TRABAJO 15

para las jornadas de atencion a vıctimas del conflicto armado que se desarrollen en lugares ale-jados de la civilizacion con acceso limitado a Internet, la informacion de las personas atendidassea capturada dentro del sistema que la entidad utiliza para esto de forma controlada, realizandolas respectivas validaciones que se definen dentro del proceso mismo, para que posteriormente estainformacion sea enviada al sistema principal y se sincronice con la base de datos de vıctimas delconflicto armado en proceso de reparacion.

1.4. Hipotesis de trabajo

El diseno de una arquitectura orientada a servicios, permitira que el modelo actual de atenciony documentacion de vıctimas del conflicto armado sea mas robusto y asegura mayor fiabilidad enla informacion que reposa en la herramienta definida por la Unidad para la Atencion y ReparacionIntegral a Victimas, esto debido a que se controlara en mayor medida la perdida de informacionen los procesos de documentacion lo cual impacta de manera positiva en la materializacion de lasmedidas de reparacion a favor de las vıctimas del conflicto armado.

1.5. Marco Referencial

1.5.1. Marco Teorico

Patrones de Arquitectura de Software

En el diseno de la arquitectura de software los elementos y relaciones estan definidos a un altonivel mediante los requisitos funciones y no funcionales. Los requisitos definen la arquitectura, porejemplo, si se quiere implementar una sitio web en el que se pida autenticacion para acceder, suarquitectura estara marcada por los requisitos de seguridad, confidencialidad e interfaz, los cualesdefinen finalmente las tecnologıas y sus interacciones.

Teniendo en cuenta los requisitos y restricciones se proporcionan los patrones de diseno arqui-tectonicos, ya que estos ayudan a resolver problemas de calidad, rendimiento y disponibilidad.

Dominio de los patrones de arquitectura

Estos patrones se encuentran en 4 dominios:

Control de acceso: personas que pueden acceder al sistema.

Concurrencia: manejar multiples tareas en paralelo.

Distribucion: sistemas distribuidos y la forma en que se comunican entre sı.

Persistencia: almacenar datos en bases de datos para leer o modificarlos.

Relacion entre patrones de arquitectura y los requerimientos no funcionales

Los patrones tienen relacion con los requisitos no funcionales mas caracterısticos como:

Escalabilidad y mantenimiento:: define caracterısticas de rendimiento, concurrencia y capa-cidad del sistema.

Seguridad: autentica y autoriza el acceso a la informacion o datos sensibles, evita o resuelveamenazas que ponen en riesgo la confidencialidad e integridad de la informacion.


Pruebas de aceptacion y verificacion: permite conocer el estado de verificacion y los resultadosdel sistema.

Documentacion: determina la documentacion tecnica y de comprension del sistema.

Recursos: define los lımites en costos, fısicos, tecnologicos y humanos.

Interoperabilidad: Garantizar que el software pueda ser implementado en cualquier sistemasoperativo.

Salvaguarda y replicacion de datos: Garantizar tener la informacion replicada en caso de unfallo, ademas de poder replicar el sistema en otros escenarios.

Patrones de arquitectura

A continuacion se presentaran los patrones de arquitectura de software mas comunes, indican-do sus principales caracterısticas y su relacion con los requisitos no funcionales en los que se haceenfasis.

Modelo cliente-servidor: Este modelo se caracteriza por tener dos partes: un cliente y un servi-dor. El modelo basicamente consiste en hacer peticiones desde el cliente hacia el servidor y recibiruna respuesta de este. Las peticiones y respuestas son informacion en forma de texto HTML,imagenes u otros elementos, ver imagen 1.1.

Figura 1.1: Diagrama Modelo Cliente-Servidor. Fuente: [Codejobs, 2015]

Estas peticiones viajan normalmente por TCP que es una de las capas del modelo OSI detransporte. El servidor puede soportar multiples conexiones simultaneas de diferentes clientes. Porlo tanto, el requisito funcional mas importante es la concurrencia y escalabilidad.

Arquitectura orientada a servicios SOA: La arquitectura orientada a servicios (en ingles:Service Oriented Architecture) es un patron que establece restricciones a tener en cuenta por eldesarrollador del software: respuestas rapidas, adaptativas y posibles cambios en los requisitos. Estepatron orquesta el funcionamiento del software a partir de un servidor central (Registro Servicio)quien es el que reparte los servicios entre diferentes servidores y estos a su vez lo llevan hacia susclientes respectivos. [Saiz, 2015]

1.5. MARCO REFERENCIAL 17

En la figura 1.2 se pueden observar el paradigma descubrir, publicar e invocar de la arquitec-tura SOA. El consumidor de servicios localiza dinamicamente (descubre) un servicio consultandoel registro del servicio el cual tiene la descripcion de los servicios. Una vez localiza el servicio,si existe, el registro proporciona al consumidor la interfaz de contrato y la direccion del servicioproveedor. El consumidor invoca al proveedor de servicio para llevar a cabo los procesos requeridos.

Figura 1.2: Modelo de Arquitectura Orientada a Servicios. Fuente: [Saiz, 2015]

Las conexiones se realizan mediante peticion - respuesta, igual que el modelo cliente-servidor,siendo este la base de un SOA. El requisito no funcional que mas se ajusta es la escalabilidad.

Modelo cliente-servidor multinivel En este modelo se varıa el modelo cliente-servidor me-diante la distribucion de capas para procesar las peticiones [Escalante, 2013].

El modelo mas usado es el de tres capas que son:

Capa de presentacion: que basicamente es la interfaz grafica del usuario (capturando movi-miento, eventos y acciones).

Capa de negocio: almacena la logica de la aplicacion (procesos del negocio, librerıas, core).

Capa de datos: donde se encuentra la informacion almacenada en bases de datos. [Alfsan,2012]


Figura 1.3: Diagrama Modelo 3 Capas Arquitectura n-Capas. Fuente: [Alfsan, 2012]

La orquestacion en este modelo la realiza la capa de negocios que es la que interactua con lacapa de presentacion y la capa de datos. El requisito no funcional mas importante es la escalabili-dad y mantenimiento. [lt, 2012]

Arquitectura orientada a eventos EDA: La arquitectura orientada a objetos (en ingles: EventDriven Architecture EDA) monitoriza, visualiza, produce y reacciona a eventos. Este patron tiene4 elementos: productores, canal, consumidores y actividad. Un productor genera un evento el cualse transmite por un canal hasta llegar al consumidor el cual lleva acabo alguna actividad. Ver lafigura 1.4.

Figura 1.4: Diagrama Arquitectura Orientada a Eventos EDA. Fuente: [Saiz, 2015]

El requisito no funcional que se espera es la escalabilidad y la concurrencia. Esta arquitecturaesta muy normalizada a eventos de tipo asıncrono y no predecibles [Saiz, 2015].

Bus de Servicios Empresariales: Un bus de servicios empresarial (en ingles Enterpriser ServiceBus - ESB) son elementos de integracion (multiprotocolo y multiproposito) en SOA que combinanservicios web, mensajerıas, enrutamiento y enriquecimiento de datos, polıticas de seguridad entreotro [W3C, 2012].

Integra los enfoques dirigidos por eventos (EDA) y orientado a servicios (SOA). Su principalcaracterıstica es permitir la interaccion entre aplicaciones heterogeneas. En la figura 1.5 se observa


una arquitectura que utiliza un ESB para integrar distintas aplicaciones con diferentes orıgenes ytecnologıas que comparten en comun un ESB para intercambiar informacion entre ellas [Tijs Ra-demakers, 2008].

Figura 1.5: Ejemplo de Arquitectura ESB. Fuente: [Tijs Rademakers, 2008]

Protocolos y Estandares de Servicios Web

La comunicacion desde y hacia un servicio web implica un determinado lenguaje, con una es-tructura definida. Por esta razon encontramos protocolos y estandares que nos definen la forma enque los servicios web se comunican, la estructura de la informacion que se debe enviar y recibir,entre muchas otras cuestiones tecnicas [W3C, 2012].

Los siguientes son los protocolos y estandares basicos que un servicio web puede utilizar:

XML (eXtensible Markup Language): es un formato o lenguaje de marcado para descri-bir contenido de forma separada de su formato. Dentro de este estandar hay estandares comoel DTD o XSD para la definicion del lenguaje y el XSL-FO y XSLT para la transformaciony presentacion.

JSON (JavaScript Object Notation): es un formato o lenguaje ligero de intercambio dedatos mas simple de leer y escribir por humanos.

SOAP (Simple Object Access Protocol): este protocolo complejo define una gramaticaXML con el formato de los documentos que se deben intercambiar entre quien realiza lasolicitud (cliente) y quien la responde (servicio) por lo general se utiliza en los servicios web.

REST (Representational State Transfer): es un estandar de transferencia de represen-tacion de estado el cual no tiene estado (en ingles stateless), lo que quiere decir que, entredos llamadas cualesquiera, el servicio pierde todos sus datos.


WSDL (web Services Description Language): este estandar define la gramatica XMLpero de la interfaz del servicio web o sea los metodos y parametros que se exponen tanto ala entrada como salida necesarios para invocar los servicios.

UDDI (Universal Description Discovery): este estandar pertenece a OASIS2 , permiteconfigurar un servicio de registro o directorio donde los proveedores de servicios publican susservicios, como un servicio de paginas amarillas de servicios web.

ISO/IEC 42010

Para el desarrollo del proyecto se debe toma como base el estandar internacional ISO/IEC42010, el cual define los requisitos que se deben cumplir en la descripcion de arquitecturas de unaempresa, de sistemas o de un producto de software.

Segun [Rodriguez, 2016], el objetivo de este estandar es estandarizar la practica de la descripcionde la arquitectura, mediante la definicion de terminos estandar, presentando una base conceptualpara la expresion, la comunicacion y la revision de la misma.

Dentro de este estandar, se define como una arquitectura a los conceptos fundamentales, pro-piedades de un sistema en su ambiente, concretados en elementos, sus relaciones y los principiosque guıen su diseno y evolucion.

Segun ISO/IEC 42010 las propiedades que definen una arquitectura, son los puntos de vista de losinvolucrados del sistema, las percepciones que estos tienen, definen los requerimientos del sistemacomo tal, y guıan la lınea de vida del sistema entero, adicionalmente estan las vistas que represen-tan estos puntos de vista de los actores. En sıntesis las vistas son las representaciones de los puntosde vista, en ellas se muestran las relaciones entre los componentes del sistema y se evidencia elflujo de la informacion y los procesos que se llevan a cabo dentro del sistema.

Aplicando el concepto de arquitectura definido por ISO/IEC 42010 y centrando el tema de in-vestigacion en el presente proyecto, se debe aplicar el concepto de SOA (Arquitectura Orientadaa Servicios), lo cual corresponde a un paradigma de arquitectura para facilidad y flexibilidad deintegracion con sistemas legados, alineacion directa a los procesos de negocio reduciendo costos deimplementacion.

La arquitectura orientada a servicios (SOA) no se trata de software o de un lenguaje de pro-gramacion, SOA es un marco de trabajo conceptual que permite a las organizaciones unir losobjetivos de negocio con la infraestructura de TI integrando los datos y la logica de negocio de sussistemas separados [Marsili, 2007].

Archimate: Es un lenguaje arquitectonico que proporciona los elementos de informacion necesa-rios para mostrar la funcionalidad dentro de un proyecto de arquitectura empresarial. Archimatetiene la ventaja como lenguaje que lo puede usar un experto del dominio y un experto tecnico [JuanCarlos Cedeno, ].

Archimate define que la arquitectura empresarial es la identificacion de unos problemas y el desa-rrollo que hace un grupo de personas para resolverlos utilizando tecnologıas de informacion.

Archimate representa los conceptos de las capas mediante grafos, algunos tomados del lengua-je unificado de modelado del ingles Unified Modeling Language (UML) y los presenta en distintos


colores. Los colores son para generar conceptos similares en las capas y su trazabilidad.

Correspondencia entre Archimate y TOGAF Archimate esta relacionado con TOGAF, perono es TOGAF aunque se mezclan muy bien ambos [Antonio Villalpando, 2014]. En la figura 1.6 esfacil de identificar la correspondencia entre el ciclo ADM (izquierda) y TOGAF (derecha), debidoal uso de colores:

La fase A, H junto con Requerimientos y Preliminar agrupadas de color lila, representan lomotivacional y nos responde el porque vamos a hacer la arquitectura.

Las fases B, C y D agrupadas cada una de tres colores que representan la informacion (Verde),el comportamiento (Amarillo) y la estructura (Azul), nos responde el que vamos a hacer.

Las fases E, F y G agrupadas de color rojo representan la migracion y nos responde el comovamos a hacer la arquitectura.

Figura 1.6: Correspondencia entre TOGAF y el Ciclo ADM de Archimate incluyendo las extensio-nes. Fuente: [Group, 2013]

El Ciclo ADM

El Metodo de Desarrollo de la Arquitectura en ingles Architecture Development Method (ADM),permite iniciar la arquitectura desde una lınea base o estado actual (AS-IS) hacia una arquitecturaobjetivo o futura (TO-BE).

Fases del Ciclo ADM El metodo ADM consta de ocho fases identificadas por las letras A,B, C, D, E, F, G y H, y dos secciones: Preliminar y Administracion de Requerimientos. Ver figura1.6


La fase A define la vision de la arquitectura, alcance y punto al que se quiere llegar. Enesta fase se presentan el diagrama del estado actual (AS-IS) de la arquitectura del negocio,aplicacion y/o infraestructura y el estado al que quiero llegar o estado futuro (TO-BE).

Las fases B, C, D son los niveles de abstraccion del negocio, aplicacion o infraestructuraen mas detalle. Cada fase puede estar representada por puntos de vista, como se vera masadelante.

La fase E lista las oportunidades y soluciones para lograr el objetivo o estado futuro (TO-BE)propuesto en la arquitectura empresarial.

En la fase F se identifican y seleccionan los activos para llevar a cabo la arquitectura deun estado AS-IS a un estado TO-BE. Como en las anteriores se identifica que se pacta,que se modifica y que se elimina, los activos pueden ser los diagramas o entregables candi-datos, clasificados en paquetes de trabajo para ver como impactan la organizacion u otrasarquitecturas.

Las fases G y H son la gobernabilidad y gestion de control de cambios de la arquitecturaempresarial antes, durante y despues de cada iteracion entre el estado AS-IS a TO-BE.

Archimate y su Integracion con el ADM Archimate cuenta con 43 elementos graficos, los cualesse distribuyen en 3 capas (Negocio, Aplicaciones e Infraestructura Tecnologica) y 2 extensiones(Extension de Motivacion y Extension de Implementacion y Migracion). Ademas cuenta con 12relaciones, todos los elementos estan en un 99 % alineado al Framework TOGAF [Antonio Villal-pando, 2014].

RUP (Rational Unified Process)

Se hara uso del Proceso Unificado de Rational (RUP), el cual se fundamenta en el uso de lasMejores practicas como el desarrollo iterativo, el seguimiento a los requerimientos por medio deUML (Lenguaje Unificado de Modelado), el uso de arquitecturas que permiten la reutilizacion decodigo y la continua verificacion de calidad del producto. Esta metodologıa esta compuesta porcuatro fases que incluyen las actividades relacionadas con la ingenierıa de software:


Figura 1.7: Fases de RUP. Fuente: [Rodrıguez, 2012]

En el desarrollo de la fase de inicio, las personas interesadas buscan establecer el enfoquedel sistema que se va a desarrollar, se determinan los casos de uso crıticos o funcionalidadesmas importantes, se propone una arquitectura candidata que soportara el funcionamientodel sistema y los riesgos potenciales que se puedan presentar.

Durante la fase de elaboracion se debe asegurar que los riesgos relacionados con la arquitec-tura esten resueltos para luego implementar los requerimientos en los prototipos que seranutilizados de manera exploratoria, para mitigar riesgos o para realizar demostraciones.

En la fase de construccion se realizan las iteraciones necesarias para completar el analisis,diseno, desarrollo y pruebas de las funcionalidades que componen el sistema hasta obtenerla version que sera entregada a los usuarios.

Finalmente, en la fase de transicion el usuario realizara pruebas de usabilidad y rendimientosobre el nuevo sistema que le permitiran validar las expectativas. Los problemas que seanencontrados luego de las pruebas seran corregidos en la version que entrara a produccion.

Este concepto estara enmarcado dentro de la fase de inicializacion y elaboracion desarrollada dentrodel capıtulo 3: Ingenierıa del Proyecto

1.5.2. Marco Conceptual

Para llevar a cabo el desarrollo de la investigacion, sera necesario conocer la definicion de pa-labras claves, las cuales seran de guıa para el entendimiento del problema y la propuesta de solucion.

El principal aspecto importante a tener en cuenta es el concepto de servicio web, ya que estecorresponde a una implementacion de SOA, cuya finalidad consiste en la integracion entre mas deun sistema dentro de una organizacion [W3C, 2012].


Servicio Web son aplicaciones que utilizan estandares para el transporte, codificacion y protocolode intercambio de informacion. Los servicios Web permiten la intercomunicacion entre sistemas decualquier plataforma y se utilizan en una gran variedad de escenarios de integracion, tanto dentrode las organizaciones como con partners de negocios [Microsoft, 2006].

La implementacion de servicios web, se requiere la construccion de la aplicacion que los imple-mente, esta aplicacion sera desarrollada en lenguaje de programacion C#.

C# es un lenguaje de programacion que se ha disenado para compilar diversas aplicaciones que seejecutan en .NET Framework. C# es simple, eficaz, con seguridad de tipos y orientado a objetos.Las numerosas innovaciones de C# permiten desarrollar aplicaciones rapidamente y mantener laexpresividad y elegancia de los lenguajes de estilo de C [Microsoft, ], [de la Torre, 2014].

API - Interfaz de Programacion de Aplicaciones: La Interfaz de Programacion de Aplica-ciones del ingles Applicaton Programming Interfac (API), en la programacion orientada a objetoses el conjunto de metodos que ofrece una librerıa o biblioteca para ser utilizada por otro software.

Arquitectura SOA: La arquitectura orientada a servicios del ingles Service Oriented Archi-tecture (SOA), permite construir sistemas distribuidos, o sea, un conjunto de sistemas ubicados endistintas partes que colaboran entre sı y que satisfacen los requerimientos de los usuarios.

Caracterısticas principales de la arquitectura SOA:

La principales caracterısticas de una arquitectura SOA son:

Los servicios deben estar definidos a traves de protocolos y lenguajes estandar de forma quesu uso sea independiente de la plataforma.

Los servicios deben estar accesibles y publicados en un repositorio de servicios con el objetivode poder monitorizar el estado de los mismos.

Los servicios definidos deben cumplir el requisito de re-utilizacion.

Los servicios encapsulan los detalles de implementacion y exponen sus funcionalidades atraves de una interfaz.

Un servicio debe ser independiente y no debe depender del estado de otro servicio.

Un servicio debe tener un nivel de granularidad o grado de complejidad en el funcionamiento.

Los servicios pueden reorganizarse en una orquestacion de servicios para representar funcio-nalidades mas complejas o integraciones de los procesos de negocio.

Servicio Web Los servicios web del ingles Web Services (WS), es un software que permite lacomunicacion entre maquinas a traves de una red. Visto de esta forma tambien pueden ser unconjunto de aplicaciones en la red que colaboran entre sı intercambiando datos con el objetivo deofrecer unos servicios [W3C, 2012].

Los servicios web sirven para proporcionar estandares de comunicacion entre aplicaciones, per-mitiendo ampliar el dominio de los datos, su administracion y analisis, llegando a ser posibleoperaciones complejas.


El siguiente es un ejemplo tomado de la pagina W3C4 (World Wide Web Consortium) dondese puede observar la interaccion de los componentes entre aplicaciones y servicios web. Ver la figu-ra 1.8

Figura 1.8: Los Servicios Web en Funcionamiento. Fuente: [W3C, 2012]

En la figura 1.8 tomada del sitio web de W3C se observa un servicio web central que hace deagente de viajes. El servicio web de agentes de viajes interactua con la aplicacion del cliente, elservicio web de tarjetas de credito, hotel y la empresa aerea mediante mensajes SOAP (basados enXML). Cuando el cliente realiza una peticion al servicio web del agente este coordina y orquestala comunicacion con los otros servicios, para ofrecerle al cliente informacion sobre el hotel y loshorarios de viaje y ası este pueda realizar su compra mediante tarjetas de credito.

Orquestacion y coreografıa de servicios web

Orquestacion Se puede interpretar como las actividades de un proceso que se deben llevar acabo en un orden al invocar servicios web o interaccion entre servicios web [lt, 2012].

Coreografıa Define las colaboraciones entre los tipos de aplicaciones, protocolos de negocio yreglas de interaccion.

Orquestacion y Coreografıa en Servicios Web La orquestacion sucede en un dominio especıfi-co, dentro de la misma arquitectura de un servicio web unico o conjunto de servicios web y lacoreografıa sucede entre dominios de servicios web para su interaccion ver figura 1.9.


Figura 1.9: Orquestacion y Coreografıa de Servicios Web. Fuente: [Perez, 2012]

SOA y Servicios Web

El paradigma SOA es general y abstracto. Un servicio web es un software que soporta la interac-cion maquina a maquina a traves de una red, mientras que los servicios web no son SOA o viceversa.

Una arquitectura orientada a los servicios trata sobre los servicios e interfaces y la forma y orden enque son llamados de acuerdo a una orquestacion. Un servicio web es un estandar de comunicaciondestacado para llevar a cabo o ser parte de un SOA y dependiendo del tipo de mensaje a manejarpuede tratar con formatos o lenguajes de comunicacion como: XML, JSON, REST, SOAP, WSDL,UDDI [Rodriguez, 2016].

1.5.3. Marco Legal

El marco legal bajo el cual se centra el desarrollo del proyecto, corresponde a lo dictado porla ley 1448 o ley de vıctimas, la cual dicta las polıticas a ejecutar por parte de la Unidad para laAtencion y Reparacion Integral a las Victimas, esta normativa esta disponible en la pagina web dela entidad, como se evidencia en la pagina oficial de la Unidad para las Vıctimas.

1.6. Organizacion de Trabajo

La Unidad para la Atencion y Reparacion Integral a las Vıctimas es una institucion creada enenero de 2012, a partir de la Ley 1448, de Vıctimas y Restitucion de Tierras, por la cual se dic-tan medidas de atencion, asistencia y reparacion integral a las vıctimas del conflicto armado interno.

La Unidad para las Vıctimas busca el acercamiento del Estado a las vıctimas mediante una coordi-nacion eficiente y acciones transformadoras que promuevan la participacion efectiva de las vıctimasen su proceso de reparacion. En atencion a eso, se encarga de coordinar las medidas de asistencia,atencion y reparacion otorgadas por el Estado, articular a las entidades que hacen parte del Siste-ma Nacional para la Atencion y Reparacion Integral a las Vıctimas.

1.6. ORGANIZACION DE TRABAJO 27

Es una entidad del orden nacional con autonomıa administrativa y patrimonial perteneciente alsector de la Inclusion social y la reconciliacion, liderado por el Departamento de la ProsperidadSocial –DPS.

1.6.1. Mision

Liderar acciones del Estado y la sociedad para atender y reparar integralmente a las vıctimas,para contribuir a la inclusion social y a la paz.

1.6.2. Vision

En el 2021, habremos logrado que las vıctimas, reparadas integralmente, ejerzan su ciudadanıay aporten en la consolidacion de la paz como resultado de la gestion efectiva y coordinada de laUnidad con los demas actores del Sistema.

1.6.3. Objetivos

El principal objetivo de la Unidad Para las Vıctimas se centra en acercar el Estado a las vıctimasmediante coordinacion eficiente y acciones transformadoras que promuevan la participacion efectivade las vıctimas en su proceso de reparacion

Estrategicos

Trabajar conjuntamente con las vıctimas en el proceso de reparacion integral para la recons-truccion y trasformacion de sus proyectos de vida.

Acercar el Estado a las vıctimas para brindarles una oferta pertinente, eficaz, sostenible yoportuna.

Definir con las entidades territoriales la implementacion de la Ley 1448/11, sus Decretosreglamentarios y los Decretos Ley.

Vincular de manera activa a la sociedad civil y a la comunidad internacional en los procesosde reparacion integral a las vıctimas del conflicto.

Fortalecer la cultura de confianza, colaboracion e innovacion para garantizar una atenciondigna, respetuosa y diferencial.

Operacionales

Construir e implementar junto con los sujetos colectivos las medidas y acciones que busquenlareparacion integral.

Brindar asistencia y reparacion individual a las vıctimas garantizando su participacion activaen el proceso.

Retornar y/o reubicar a las vıctimas del conflicto en condiciones de seguridad, dignidad yvoluntariedad.

Flexibilizar y crear la oferta para la superacion de la situacion de vulnerabilidad y la repa-racion integral.


Garantizar que las vıctimas organizadas, no organizadas y las que se encuentran en el exteriorparticipen en la formulacion e implementacion de la polıtica publica de atencion y reparacionintegral.

Prestar apoyo tecnico y presupuestal a las entidades territoriales para el cumplimiento de susresponsabilidades en la implementacion territorial de la Ley 1448/11 y de los Decretos Ley.

Crear mecanismos efectivos para hacer seguimiento a la implementacion de la Ley 1448 /11en los territorios.

Posicionar la reparacion integral a las vıctimas como una experiencia innovadora, transfor-madora y constructora de paz.

Adelantar acciones de pedagogıa social encaminadas al reconocimiento de las vıctimas comosujetos de derechos y al ejercicio pleno de su ciudadanıa.

Fomentar la construccion de redes de apoyo y solidaridad con las vıctimas del conflicto porla sociedad y la comunidad internacional.

Trabajar de manera colaborativa, gestionando el conocimiento y promoviendo la confianza.

Afianzar la cultura de gestion de la informacion con calidad y oportunidad.

Contar con una planta de personal motivada y coherente con la estructura organizacional dela Unidad.

Administrar los recursos del Fondo para implementar las medidas de reparacion.

Incrementar los recursos que las entidades del SNARIV destinan a la atencion a las vıctimas.

Apoyar la financiacion de las competencias de los entes territoriales frente a la atencion delas vıctimas.

Promover el compromiso de la sociedad y de la comunidad internacional en la financiacionde la reparacion integral.

Lograr eficiencia e impacto en la ejecucion de los recursos.

Implementar un Sistema de Atencion integral que permita brindar una respuesta efectiva alas vıctimas y a los ciudadanos.

Disponer de una Plataforma Integrada de Sistemas de Informacion que permita desarrollaruna atencion eficiente.

Contar con una estrategia de comunicacion con lenguaje incluyente que promueva la ciuda-danıa.

Contar con una estrategia de comunicacion interna efectiva enfocada al trabajo colaborativo.

Innovar permanentemente los procesos facilitando el acceso a la oferta institucional.

Fortalecer el proceso de induccion (acogida) y formacion del talento humano en los principiosque regulan el Estado Social de Derecho.

Contar con una estrategia de comunicacion interna efectiva enfocada al trabajo colaborativo.

Implementar una cultura de gestion de calidad que mejore la eficacia, eficiencia y efectividadde los procesos

1.6. ORGANIZACION DE TRABAJO 29

1.6.4. Estructura Organica

En la figura 1.10, se muestra el modelo organizacional de la Unidad Para las Vıctimas, en dondese muestra la organizacion vista desde sus dependencias.

Figura 1.10: Modelo Organizacional UARIV. Fuente: [UARIV, 2012]

1.6.5. Funciones Organizacionales

El desarrollo del presente proyecto se centrara, en una de las areas que componen la Subdireccionde reparacion individual, la cual corresponde al equipo de Ruta Integral, el cual es el encargado degestionar las actividades que ejecutan desde los puntos de atencion situados en el nivel territorial,los cuales dirigidos por las Direcciones Territoriales segun los visto en la figura 1.10 .

1.6.6. Procesos

Segun lo expuesto en el punto 1.6.5, se mencionan a continuacion el proceso que se lleva a cabopara tal fin.

Proceso de documentacion y validacion de nucleos familiares.

El cual se compone por las actividades:


Depuracion de informacion en el sistema.

Tramite de novedades de actualizacion de informacion.

Validacion de nucleos familiares.

La herramienta implementada por la organizacion para llevar a cabo este proceso se llama In-demniza, en esta herramienta se almacena la informacion sobre las vıctimas del conflicto armado,las cuales estan habilitadas segun lo dicta la Ley de vıctimas para ser reparados Integralmente,estos datos estan a disposicion de los funcionarios del nivel territorial, quienes son funcionarios dela Unidad para las Victimas situados en los puntos de atencion y estan bajo jurisdiccion de lasDirecciones Territoriales mencionadas en el modelo organizacional dispuesto en la figura 1.10.

1.7. Estudios de Sistemas Previos

En la actualidad, en la entidad Unidad para la Atencion y Reparacion integral a las Vıctimases implementado el sistema de informacion llamado Indemniza, este sistema de informacion es eldesignado por la entidad para depurar la informacion de la base de datos principal respecto a lasvıctimas del conflicto armado, y realizar la respectiva actualizacion de la misma con el fin de poderejecutar uno de los servicios que la entidad debe ejecutar segun la ley de victimas, la indemnizacionpor vıa administrativa de las vıctimas del conflicto armado.

Su objeto principal consiste en disponer de una base de datos historica con informacion del pago deindemnizacion a vıctimas del conflicto armado, sin embargo una de las falencias que se presentabacorrespondıa, a que en muchas ocasiones el pago de la medida de indemnizacion de las vıctimasse ve detenido ya que la informacion referente a nombres, apellidos, tipo y numero de documentoesta desactualizada, lo cual ocasiona que la persona no puede hacer efectivo el cobro del dineroa su nombre. Segun esto, la entidad desarrollo un nuevo proceso a llevar a cabo en Indemniza,la cual consiste en adelantar procesos de depuracion de la informacion a traves de un proceso dedocumentacion que involucra la participacion de la vıctima, con el fin de suministrar sus datosactualizados y ası disminuir el indice de pagos no efectivos por la problematica expuesta.

Parte II

Desarrollo de la Investigacion

31

Capıtulo 2

Aspectos Metodologicos yCronograma

2.0.1. Tipo de Estudio

La presente investigacion se realiza a traves de un tipo de estudio proyectivo, ya que se pretendeanalizar el estado actual del proceso realizado por la Unidad Para la Atencion y Reparacion Integrala las Victimas, para generar un diagnostico preliminar que definira los aspectos a tener en cuentaa lo largo del proyecto, para ası disenar la propuesta de la solucion a implementar y realizar lapropuesta formal de la misma.

2.0.2. Metodo de investigacion

Para el desarrollo de la investigacion se pretende estudiar el proceso de documentacion que serealiza en la unidad para las vıctimas, con el fin de llevar registro de la informacion de las perso-nas cuyos derechos han sido vulneradas a causa del conflicto armado, este proceso es sustentadobajo decretos, resoluciones y leyes que ha definido el gobierno colombiano, para entender la pro-blematica que sustenta el presente proyecto se requiere un analisis a fondo del proceso mencionadoanteriormente, con esto se detectaran variables claves a tener en cuenta.

De igual manera, se hace necesario comprender el modelo de datos bajo el cual funciona la he-rramienta actual llamada Indemniza, y realizar un trabajo conjunto con los funcionarios de laentidad que se encargan de administrar y dar mantenimiento a la misma, con esto se estableceranlos parametros de intercambio de informacion entre el sistema actual a traves de la arquitecturadisenada, los acuerdos de niveles de servicio y el flujo de datos y procesos de la arquitectura adesarrollar.

Para lo cual tenemos en cuenta las siguientes fases de la gestion del proyecto.

Fase de Observacion

Durante esta fase se realizara todo el proceso de obtencion y analisis de la informacion, partiendode este principio se implementaran como insumo principal la informacion suministrada por losfuncionarios de la Unidad para las Vıctimas la cual se menciona en el apartado 2.0.3, lo cualdeterminara de manera exacta los inconvenientes puntuales que se estan presentando durante

33

34 CAPITULO 2. ASPECTOS METODOLOGICOS Y CRONOGRAMA

el proceso de documentacion, posteriormente se procedera a analizar los resultados obtenidos,generando una conclusion que dara como resultado la hipotesis del proceso.

Fase de Creacion De La Hipotesis

Una vez culminada la fase de observacion y recopilada toda la informacion obtenida, se anali-zaran las variables que determinan las falencias que se presentan actualmente en el sistema (verseccion 2.0.4), las cuales consisten principalmente la dependencia total de la conexion a Internetpara adelantar la labor de documentacion, la cual sera subsanada con el diseno de una arquitecturaorientada a servicios que le permitira al sistema Indemniza funcionar en un ambiente sin conexional servidor central de la entidad y se sincronizara con el una vez se detecte una conexion estable ala red.

Fase de Deduccion

Una vez culminadas las dos anteriores fases y probada la hipotesis, se procede a plantear losresultados obtenidos de la fase de recoleccion de informacion, para posteriormente concluir que laimplementacion de la arquitectura desarrollada, permitira que el proceso de documentacion que seadelanta por los funcionarios de la Unidad para las Vıctimas se pueda llevar a cabo en ubicacionesgeograficas en donde el acceso a Internet es limitado o nulo, siendo estos los resultados que seespera obtener con la implementacion de esta arquitectura (ver seccion 2.1.3), sera fundamentalel mantenimiento en la plataforma ademas de las actualizaciones que este requiera, con el fin demantener un sistema robusto y escalable.

Fase de Experimentacion

Atendiendo la idea central que compone la hipotesis, el proyecto a desarrollar consiste en eldiseno de una arquitectura orientada a servicios la cual permita a la Unidad para las Victimasejecutar el proceso de documentacion de nucleos familiares que han sido victimas del conflictoarmado, a traves del sistema Indemniza sin tener una conexion a Internet.

Una vez el desarrollo concluya, se deben realizar las pruebas pertinentes para poder analizar losresultados obtenidos, donde se valoraran 3 tipos de procesos, el cumplimiento, la satisfaccion par-cial, y el no cumplimiento; Asimismo se deben realizar los ajustes pertinentes de acuerdo a laspruebas establecidas al desarrollo del proyecto.

Para dar cumplimiento a todas las etapas se analizara la metodologıa RUP como aplicabilidadal proceso, ademas de que nos permite comprobar lo formulado en la metodologıa de investigacion,a traves de los diferentes procesos que se generan en cada una de las etapas.

Para el cumplimiento dentro de la fase de experimentacion se tienen en cuenta las siguientesfases:

Fase de Inicializacion

Durante el desarrollo de esta fase se realizara el levantamiento de informacion, el cual estarasustentado por medio de la observacion y la documentacion suministrada por la entidad, posterior-mente se realizara la planeacion del proyecto, donde se tendra en cuenta el resultado obtenido delanalisis previo para establecer los requerimientos y especificaciones, esto con el animo de proponerla documentacion necesaria a la arquitectura en desarrollo. Esta fase estara detallada dentro delcapıtulo 3.

2.1. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS 35

Fase de Elaboracion

En esta Fase, se realizara el desarrollo de la arquitectura el cual contempla el diseno de los artefactosque la representan, lo cual se realizara abarcando los puntos de vista estimados por Archimate conel fin de definir la arquitectura empresarial desde la organizacion, Aplicacion, Infraestructura,Implicacion y Proyecto. Para finalizar esta fase se establecera la arquitectura base del sistema, estosera expuesto con mayor detalle en el capitulo 3.

Fase de Construccion

En esta fase se desarrolla el prototipo de los Web Services que buscan la comprobacion de los com-ponentes estimados en la fase de elaboracion y poner a prueba el funcionamiento de la arquitecturadesarrollada. Encontrara todo lo relacionado a la fase de construccion dentro del capıtulo 3.

Fase de Transicion

El proposito de esta fase es asegurar que la arquitectura disenada y los componentes que lo sopor-tan tengan 100 % de funcionalidad y este disponible para su evaluacion por parte de la entidad,ademas de ajustar los errores y defectos encontrados en las pruebas realizadas durante la fase deconstruccion. Esta fase estara detallada dentro del capıtulo 3.

2.0.3. Fuentes tecnicas para la recoleccion de informacion

Respecto a la recoleccion de la informacion necesaria para el desarrollo del proyecto, se partede la base teorica existente, la cual como se menciono anteriormente esta definida por la legislacionque regula el funcionamiento de la Unidad para las vıctimas, adicionalmente se establece que en lasreuniones de trabajo con los funcionarios que administran la herramienta actual, se hace necesariorealizar grabaciones de las mismas, levantamiento de actas de trabajo y diagramas que resultendel trabajo conjunto.

2.0.4. Tratamiento de la informacion

Luego de realizar el levantamiento de informacion para el desarrollo del proyecto, se recopilaracomo primera medida los datos obtenidos, estos seran presentados en un solo documento y seemplearan tecnicas de analisis de la misma que permitan la generacion de diagramas, o artefactosque permitan representar la situacion actual del sistema, y el estado futuro del mismo luego de laaplicacion de la solucion a desarrollar.

2.1. Alcances, limitaciones y resultados esperados

2.1.1. Alcances

La presente investigacion, se enmarca en estructurar el proceso actual de documentacion depersonas que realiza la Unidad para las Vıctimas, esto a traves del diseno de una arquitecturaorientada a servicios que permita, la actualizacion de la informacion previamente registrada sobrelas personas asistentes a las jornadas de atencion a vıctimas del conflicto armado definidas por laentidad y que esten ubicadas en poblaciones con difıcil acceso a las TIC.


2.1.2. Limitaciones

Debido a que el proceso de documentacion de vıctimas del conflicto armado estipulado porla entidad esta basado en la legislacion colombiana que regula el funcionamiento de la misma, laprincipal limitacion del proyecto radica en un cambio de alto impacto en la ley de vıctimas, ya queeste hipotetico cambio representarıa un cambio en el modelo actual de la organizacion y por endegenerarıa un nuevo enfoque del proyecto en desarrollo.

2.1.3. Resultados Esperados

Como conclusion de la investigacion se espera poder:

Tener una arquitectura de software orientada a servicios, aprobada por la entidad para suimplementacion en el sistema de documentacion de vıctimas del conflicto armado.

Consolidar un documento que contenga la informacion sobre la arquitectura desarrolladapara su comprension y puesta en marcha como complemento de la herramienta Indemniza.

Generar un prototipo funcional de la arquitectura disenada, con el fin de demostrar su fun-cionamiento y disponerla para su evaluacion por parte de la entidad.

2.2. Cronograma de Trabajo

A continuacion se presenta el cronograma para el desarrollo del proyecto, en la tabla 2.1,se muestran las actividades que regiran el ciclo de vida del mismo, el tiempo estimado para suejecucion y las fechas de inicio y culminacion para cada una de ellas.

Cuadro 2.1: Cronograma general del proyectoNombre de la Tarea Duracion Fecha Inicio Fecha Final

Diseno del proyecto 21 dıas mie 30/03/16 mie 27/04/16Seleccion y definiciondel tema de investigacion

6 dıas mie 30/03/16 mie 06/04/16

Consolidar anteproyecto 14 dıas mie 30/03/16 lun 18/04/16Problema de investigacion 6 dıas lun 04/04/16 lun 11/04/16Objetivos de la investigacion 6 dıas lun 11/04/16 lun 18/04/16Ajustes al anteproyecto 6 dıas mie 20/04/16 mie 27/04/16Desarrollo del proyecto 131 dıas lun 02/05/16 lun 31/10/16Fase de inicializacion 25 dıas lun 02/05/16 vie 03/06/16Fase de Elaboracion 45 dıas jue 02/06/16 mie 03/08/16Fase de Construccion 55 dıas mie 03/08/16 mar 18/10/16Fase de Transicion 10 dıas mar 18/10/16 lun 31/10/16

En la figura 2.1 se muestra el diagrama de Gantt en el cual se diagrama el cronograma expuestoanteriormente.

2.3. PRESUPUESTO 37

Figura 2.1: Diagrama de Gantt del proyecto

2.3. Presupuesto

2.3.1. Costos pos servicios personales

En la tabla 2.2, se muestran los costos por servicios profesionales estimados para el desarrollodel proyecto.

Cuadro 2.2: Costos pos servicios personalesElemento Cantidad Vlr. Unitario mes Cant. Meses Vlr. Total

Ingeniero desistemas

1 $3’000.000 7 $21’000.000.000

2.3.2. Gastos Personales

En la tabla 2.3, se muestran los costos por servicios profesionales estimados para el desarrollodel proyecto.

Cuadro 2.3: Gastos PersonalesElemento Cantidad Valor Unitario Valor Total

Visual Studio 1 $0 $0Equipo computacional 1 $ 2’000.000 $ 2’000.000Papelerıa 1 $100.000 $100.000


2.3.3. Costo Total del Proyecto

Para el desarrollo del proyecto Arquitectura de software para complementar el proceso devalidacion de nucleos familiares, en la Unidad Para La Atencion Y Reparacion Integral A LasVıctimas, se determino que el costo total corresponde a $ 23.100.000 pesos colombianos, usandocomo referencia los costos unitarios presentados en los literales 2.3.1 y 2.3.2, ası como la duraciondel proyecto.

Capıtulo 3

Ingenierıa del Proyecto

Una vez determinadas las necesidades y en concordancia con la justificacion del proyecto, seestablece que la metodologıa utilizada para el analisis, diseno y desarrollo del proyecto sera lametodologıa RUP (Proceso Racional Unificado). La cual se caracteriza por enfocar los casos de usodel sistema para dar solucion a las necesidades planteadas por el cliente y realizar el seguimientoa los requerimientos a traves de la implementacion de UML (Lenguaje de Modelado Unificado).

Dentro del proceso de desarrollo estipulado por la metodologıa RUP, las fases que se tendranen cuenta en el desarrollo de la ingenierıa se describen a continuacion:

3.1. Fase Inicializacion

En el desarrollo de la fase de inicializacion, se identificaron los procesos ejecutados en el sis-tema actual a traves del levantamiento de informacion, tal como se menciona en el capıtulo 1 enla seccion 2.0.2, donde se hace mencion a los instrumentos de recoleccion y analisis de datos, y sedeterminaron las necesidades del cliente, enfocando estos instrumentos desde las distintas perspec-tivas que deben ser tenidas en cuenta.

Adicionalmente, la informacion recopilada es analizada para determinar los requerimientos estable-cidos para el sistema, los cuales son clasificados en requerimientos funcionales y no funcionales, locual permitira la descripcion detallada del proceso documentacion que se adelantara por parte delos funcionarios de la Unidad para las Vıctimas una vez implementada la arquitectura desarrollada.

De acuerdo al analisis establecido, se realizara la descripcion tanto de los sistemas actuales co-mo del sistema propuesto, y la interaccion de los mismos con los usuarios intervinientes, con el finde determinar las mejoras a implementar en la solucion a desarrollar

Caso de uso general para la arquitectura propuesta

La arquitectura en desarrollo, se centrara en disponer un ambiente que permita llevar a cabo elproceso de documentacion y validacion de nucleos familiares reutilizando las funcionalidades imple-mentadas por el sistema Indemniza, para esto se deben contemplar componentes que le permitanal sistema trabajar sin conexion con la base de datos principal, esto sin afectar el funcionamientonormal del mismo y sin generar traumatismos al usuario que este ejecutando las actividades nece-sarias para realizar el proceso de documentacion de nucleos familiares.

39

40 CAPITULO 3. INGENIERIA DEL PROYECTO

A razon de esto, se presenta en la figura 3.1 el caso de uso general para la arquitectura propuesta,en donde se presentan los stakeholders y las acciones a ejecutar por cada uno de ellos, de igualmanera en la seccion 3.1.1 se realizara la explicacion especıfica de los requerimientos detectadospara el desarrollo del proyecto.

Figura 3.1: caso de uso general para la solucion propuesta

En la figura 3.1, se muestra como los stakeholders del sistema Indemniza que ejecutan lasfunciones del rol Enlace Integral, deberan realizar las acciones:

Inicio de sesion, con el fin de autenticarse en el sistema y acceder a los componentes delmismo.

Descargar informacion, esto con el fin de dar la accion al sistema de desligar cierta informacionde su interes, de la base de datos principal y ejecutar las tareas que haya lugar.

Documentar nucleos familiares: esta accion se ejecutara unicamente con la informacion des-cargada en la accion anterior y se regira por las pautas dadas por la entidad.

Por otra parte se muestra al stakeholder API, el cual ejecutara sus acciones desde web servicesque permitiran ejecutar las acciones:

Descarga de informacion, lo cual lo realizara segun las peticiones del Enlace Integral y alma-cenara en una base de datos local la informacion para su procesamiento.

Sincronizar, esta accion depende de la accion de documentacion de nucleos familiares reali-zada por el Enlace Integral, esto debido a que la finalidad de esta accion es cargar a la basede datos del sistema principal la informacion actualizada desde el sistema sin conexion, porende si no existe informacion a actualizar no se ejecutara accion alguna.

3.1. FASE INICIALIZACION 41

3.1.1. Requerimientos del sistema propuesto

Para asegurar que la arquitectura propuesta permita al sistema actual ejecutar los procesosnecesarios para cumplir con la institucionalidad de la entidad, se contempla realizar algunas mo-dificaciones al mismo, las cuales se enfocan en complementar su funcionamiento para integrarlocon las funcionalidades dispuestas por la nueva arquitectura en desarrollo, para esto se requierecontemplar los siguientes requerimientos.

Requerimientos Funcionales

Identificaciondel requerimiento

RF01

Nombredel requerimiento

Inicio de Sesion

Caracterısticas El usuario debera identificarse para acceder al sistemaDescripciondel requerimiento

El usuario debe contar con las credenciales de acceso suministradaspara poder acceder a la informacion almacenada en Indemniza

Requerimientono funcional

- RNF01

Prioridaddel requerimiento

Alta

Cuadro 3.1: Especificacion del requerimiento funcional 01


RF02


Descarga de informacion

CaracterısticasEl usuario debe seleccionar la informacion a descargar del sistemaprincipal

Descripciondel requerimiento

El usuario debera seleccionar los casos que desea documentarsin estar conectado con el sistema principal.

Requerimientono funcional

- RNF01 - RNF02


Alta

Cuadro 3.2: Especificacion del requerimiento funcional 02


Requerimientos No Funcionales


RNF01


Validar credenciales

CaracterısticasEl sistema debe validar la informacion de usuario y contra-sena digitados por el usuario.


El sistema debe verificar los datos de acceso digitadas porel usuario, y validar los permisos de acceso a las funcionalidadesparametrizadas por rol.


Alta

Cuadro 3.3: Especificacion del requerimiento no funcional 01


RNF02


Inhabilitar casos descargados

CaracterısticasEl sistema debe dejar una marca acerca de los casos que serandescargados del sistema


El sistema debe dejar una marca sobre los casos que sondescargados al sistema sin conexion, esto con el fin de evitarque un caso que se esta documentando en el sistema offline sedocumente en el sistema principal.


Alta



RNF03


Validar conexion con servidor

CaracterısticasEl sistema debe validar si existe o no conexion con el sistemaprincipal.


El sistema validara el estado de la conexion con el servidorremoto y dependiendo del estado de la misma trabajar conla base de datos local o remota.


Alta


3.2. FASE ELABORACION 43


RNF04


Sincronizacion

CaracterısticasEl Sistema debe sincronizar la base de datos del servidor localal servidor remoto.


El sistema debe replicar la informacion almacenada en la basede datos local a la base de datos remota y vaciar el contenidode la base de datos local.


Alta


En consecuencia, de acuerdo a la tablas expuestas en las secciones 3.1.1 y 3.1.1 en donde sedeterminan los requerimientos funcionales y no funcionales del sistema propuesto, se establece lafase de elaboracion, la cual dara continuidad al diseno del software propuesto.

3.2. Fase Elaboracion

Durante del desarrollo de esta fase, se establece la lınea principal para la arquitectura a desa-rrollar, de igual manera se realizan las actividades de analisis y diseno de los Web Services aimplementar, para la parametrizacion de los mismos.

Lo anterior inicia con la diagramacion de los puntos de vista definidos por Archimate, para verde esta manera la forma en que interactuan los procesos organizacionales, la infraestructura y loscomponentes de software, ası como la forma en que se veran abordados segun los requerimientosexpuestos en la seccion 3.1.1 para iniciar las actividades desarrollo de la arquitectura y los WebServices que la implementaran.

El segundo componente de esta fase se centra en el diseno del modelo de datos que seran im-plementado por los Web Services bajo los cuales se realizara la implementacion de la arquitecturadesarrollada, para esto se identificaran las variables que compondran dicho modelo y se definira laforma en que el sistema Indemniza interactuara con este.

De igual manera, esta fase incluye los diagramas de actividad y secuencia que representan elflujo de datos en el sistema Indemniza durante su interaccion con la arquitectura desarrollada. Acontinuacion se hara la descripcion de cada uno de los elementos que componen esta fase.

3.2.1. Arquitectura Empresarial

En esta seccion, inicia el proceso de analisis de la informacion suministrada por los funcionariosde la Unidad para las Vıctimas, con el fin de realizar el modelado de la informacion y conocera traves de artefactos el funcionamiento de la organizacion, desde los distintos puntos de vistacontemplados por Archimate para visualizar la arquitectura empresarial en una organizacion, acontinuacion se presentan los puntos de vista mencionados anteriormente para diagramar el fun-cionamiento de la Unidad para las vıctimas y las acciones definidas por la arquitectura desarrolladapara complementar la ejecucion de sus procesos.


Punto de Vista Organizacional

El punto de vista de organizacion se centra en la organizacion (interno) de una empresa, undepartamento, una red de empresas, o de otra entidad organizativa. Es posible presentar los mo-delos en este punto de vista como diagramas de bloques anidados, sino tambien de una maneramas tradicional, tales como organigramas.

El punto de vista Organizacion es muy util en la identificacion de las competencias, la autori-dad y las responsabilidades dentro de una organizacion, ver figura 3.2.

Modelo

Figura 3.2: Meta Modelo punto de vista de la organizacion

Ejemplo

En la figura 3.3, se observa que lo expuesto en el modelo organizacional de la Unidad para lasVıctimas (ver figura 1.10), la Subdireccion de Reparacion Individual se complementa por el equipode Ruta Integral quien a su vez tiene a cargo la supervision del actor Millenium y en donde todosestos actores complementarios ejecutan sus procesos a traves de el sistema Indemniza.

Figura 3.3: Modelo punto de vista de la organizacion

Punto de Vista Cooperacion de Actor

El punto de vista Cooperacion Actor se centra en las relaciones de los actores entre sı y con suentorno. Un ejemplo comun de esto es el ”diagrama de contexto”, lo que pone una organizacionen su entorno, que consiste en las partes externas, tales como clientes, proveedores y otros socioscomerciales, es muy util en la determinacion de dependencias externas y colaboraciones y muestra


la cadena de valor o de la red en el que opera el actor.

Otro uso importante de punto de vista Cooperacion Actor es en mostrar como una serie de actoresque cooperan de negocio y / o componentes de la aplicacion en conjunto dan cuenta de un procesode negocio. Por lo tanto, en este punto de vista, pueden ocurrir tanto a los actores comerciales ofunciones y componentes de la aplicacion, ver figura 3.4.

Modelo

Figura 3.4: Meta Modelo punto de vista cooperacion actor

Ejemplo

Como se observa en la figura 3.5, se genera el rol Documentador el cual es desempenado porlos funcionarios del nivel territorial, quienes consignan su labor a traves del sistema Indemniza,cuya informacion es administrada desde el nivel nacional por los funcionarios que pertenecen a losequipos Ruta Integral e Indemnizaciones.

Figura 3.5: Modelo punto de vista cooperacion actor


Punto de Vista Funcion de Negocio

El punto de vista de funcion de negocios muestra las principales funciones de negocio de unaorganizacion y sus relaciones en terminos de los flujos de informacion, el valor, y cosas entre ellos.Las funciones de la empresa se utilizan para representar los aspectos mas estables de una empresaen terminos de las actividades primarias que realiza, independientemente de los cambios de orga-nizacion o desarrollos tecnologicos.

Por lo tanto, la arquitectura funcion de negocio de las empresas que operan en el mismo mer-cado a menudo presentan grandes similitudes. Ası pues, el punto de vista de la funcion empresarialproporciona una vision de alto nivel en las operaciones generales de la empresa, y se puede utilizarpara identificar las competencias necesarias, o para estructurar una organizacion de acuerdo a susactividades principales, ver figura 3.6.

Modelo

Figura 3.6: Meta Modelo punto de vista Funcion de Negocio

Ejemplo

En la figura 3.7, se observa la forma en que los roles documentador y administrador herramientaIndemniza, ejecutan las funciones esenciales del negocio, las cuales ejecutan a traves del sistemaIndemniza quien a su vez sirve como canal de comunicacion entre ambos roles.

Figura 3.7: Modelo punto de vista funcion de negocio


Punto de Vista Proceso de Negocio

El punto de vista de procesos de negocio se utiliza para mostrar la estructura de alto nivel yla composicion de uno o mas procesos de negocio. Al lado de los procesos mismos, este punto devista contiene otros conceptos directamente relacionados, tales como:

Los servicios de un proceso de negocio ofrece al mundo exterior, que muestra como un procesocontribuye a la realizacion de productos de la companıa

La asignacion de los procesos de negocio a los roles, lo que da una idea de las responsabilidadesde los actores asociados

La informacion utilizada por el proceso de negocio.

Cada uno de ellos puede ser considerado como una ”sub vista”de la vista de procesos de negocio,ver figura 3.8.

Modelo

Figura 3.8: Meta Modelo punto de vista Proceso de Negocio

Ejemplo: modelo proceso Administrador Indemniza

En la figura 3.9, se muestra el servicio prestado por el rol de Administrador HerramientaIndemniza, a traves del proceso de cargue de datos al sistema, con el fin de disponer la informacionen el sistema Indemniza y ası asegurar que el rol Documentador pueda ejecutar su labor.


Figura 3.9: Modelo punto de vista Proceso de negocio Administrador Indemniza

Ejemplo: modelo proceso Documentador

En la figura 3.10, se observa el proceso de documentacion que ejecuta el rol documentadoren la herramienta Indemniza, cuyo objeto se centra en realizar la depuracion de la informacionpre cargada al sistema, identificar destinatarios con el mayor derecho a recibir la indemnizacionadministrativa y la cantidad de salarios mınimos mensuales legales vigentes a recibir por cada unode ellos, esto con el fin de adelantar el tramite financiero de la indemnizacion de las vıctimas yevitar que estas no puedan hacer efectivo el cobro de esta medida de reparacion por errores en lainformacion registrada.

Figura 3.10: Modelo punto de vista Proceso de negocio (Documentador)

Punto de Vista Cooperacion Proceso de Negocio

El punto de vista de Cooperacion de procesos de negocio se utiliza para mostrar las relacionesde uno o mas procesos de negocio entre sı y / o con su entorno. Puede ser utilizado tanto para crearun diseno de alto nivel de los procesos de negocio dentro de su contexto y para proporcionar ungestor operativo responsable de uno o mas de dichos procesos con penetracion en sus dependencias.Algunos aspectos importantes del proceso de cooperacion empresarial son:

Las relaciones causales entre los principales procesos de negocio de la empresa.


Mapeo de los procesos de negocio en las funciones de negocio.

La realizacion de los servicios por parte de los procesos de negocio.

El uso de datos compartidos.

La ejecucion de un proceso de negocio por los mismos papeles o actores.

Cada uno de ellos puede ser considerado como una ”sub-vista”de la vista de la cooperacion deprocesos de negocio, ver imagen 3.11.

Modelo

Figura 3.11: Meta Modelo punto de vista Cooperacion Proceso de negocio

Ejemplo

En la figura 3.12, se observa la interaccion entre los procesos de negocio que ejecutan el roladministrador de la herramienta Indemniza y el rol documentador, el cual se realiza a traves delsistema Indemniza, cada uno desde una ubicacion diferente pero encaminados hacia el cumplimientodel objetivo organizacional de contribuir al proceso de reparacion integral a las vıctimas del conflictoa traves de las medidas de reparacion contempladas en la Ley de victimas como se menciona en elmarco legal del proyecto.


Figura 3.12: Modelo punto de vista Cooperacion Proceso de negocio

Punto de Vista Producto

El punto de vista del producto representa el valor de estos productos ofrecen a los clientes uotras partes externas involucradas y se muestra la composicion de uno o mas productos en terminosde la constitucion (aplicacion o empresa) los servicios, y el contrato(s) asociado u otros acuerdos.Tambien puede ser utilizado para mostrar las interfaces (canales) a traves de los cuales se ofreceeste producto, y los eventos asociados con el producto.

Un punto de vista del producto se usa tıpicamente en el desarrollo de productos para disenarun producto mediante la composicion de los servicios existentes o mediante la identificacion denuevos servicios tienen que ser creados para este producto, dado el valor de un cliente espera deella. Puede entonces servir como entrada para los arquitectos de procesos de negocios y otros quenecesitan para disenar los procesos y las TIC la realizacion de estos productos, ver imagen 3.13.


Modelo

Figura 3.13: Meta Modelo punto de vista Producto

Ejemplo

En la imagen 3.14, se muestra la forma de obtener valor en la Unidad para las Vıctimas, la cualse centra en implementar las polıticas necesarias con el fin de apoyar el proceso de reconstrucciondel proyecto de vida de las vıctimas del conflicto armado, para esto requiere la depuracion yactualizacion de la informacion registrada en el sistema para asegurar la reparacion integral de lapersona acogida por la entidad.

Figura 3.14: Modelo punto de vista Producto

Punto de Vista Comportamiento Aplicacion

El punto de vista del comportamiento de aplicacion describe el comportamiento interno de unasolicitud. Por ejemplo, como se da cuenta de uno o mas servicios de aplicacion.


Este punto de vista es util en el diseno del comportamiento principal de aplicaciones, o en laidentificacion de solapamiento funcional entre diferentes aplicaciones, ver imagen 3.15.

Modelo

Figura 3.15: Meta Modelo punto de vista Comportamiento Aplicacion

Ejemplo

Como se muestra en la imagen 3.16, los componentes de la arquitectura en desarrollo correspon-den a los componentes mismos del sistema, los cuales funcionaran en concordancia con lo estipuladoen los requerimientos funcionales y no funcionales del sistema, para esto los componentes se centra-lizaran en el componente sincronizacion, el cual se diseno con el proposito de mantener el sistemaprincipal actualizado.

Figura 3.16: Modelo punto de vista Comportamiento Aplicacion


Punto de Vista Cooperacion de Aplicacion

El punto de vista de Cooperacion de aplicacion describe las relaciones entre los componentes delas aplicaciones en terminos de la informacion que fluye entre ellos, o en terminos de los serviciosque ofrecen y su uso. Este punto de vista se utiliza tıpicamente para crear una vision general delentorno de aplicaciones de una organizacion. Este punto de vista tambien se utiliza para expresarla cooperacion o la orquestacion (interna) de los servicios que en conjunto apoyan la ejecucion deun proceso de negocio, ver imagen 3.17.

Modelo

Figura 3.17: Meta Modelo punto de vista Cooperacion Aplicacion

Ejemplo

Se observa en la imagen 3.18 como se compone la distribucion de los componentes y su imple-mentacion de cara a los usuarios desde el front Office cuyo uso sera orientado hacia los usuariosfinales de la aplicacion, ası mismo se desde back office se realizaran la distribucion de componentesque aseguraran el correcto funcionamiento del front office.


Figura 3.18: Modelo punto de vista Cooperacion Aplicacion

Punto de Vista Estructura de Aplicacion

El punto de vista Estructura de la aplicacion muestra la estructura de una o mas aplicacioneso componentes.

Este punto de vista es util en el diseno o la comprension de la estructura principal de aplica-ciones o componentes y los datos asociados, por ejemplo, para romper la estructura del sistemaen construccion, o para identificar los componentes de aplicaciones heredadas que son adecuadospara la migracion / integracion, ver imagen 3.19.

Modelo

Figura 3.19: Meta Modelo punto de vista Estructura de Aplicacion


Ejemplo

Como se muestra en la imagen 3.20, todos los componentes entran a interactuar a traves de lasinterfaces dispuestas por Indemniza, la cual es la herramienta principal que permitira el acceso alos componentes de descarga de informacion, ası como de sincronizacion para los componentes decarga de datos post documentacion.

Ası mismo se muestra como se afectan los objetos de datos definidos por la base de datos lo-cal y la base de datos remota, a traves de la implementacion del plug in que se encargara detrasportar los datos entre estos dos componentes de la arquitectura de aplicacion.

Figura 3.20: Modelo punto de vista Estructura de Aplicacion

Punto de Vista Uso de Aplicacion

El punto de vista de uso de la aplicacion describe como se utilizan las aplicaciones para soportaruno o mas procesos de negocio, y la forma en que son utilizados por otras aplicaciones. Puede serutilizado en el diseno de una aplicacion mediante la identificacion de los servicios que necesitanlos procesos de negocio y otras aplicaciones, o en el diseno de procesos de negocio mediante ladescripcion de los servicios que estan disponibles. Ademas, ya que identifica las dependencias delos procesos de negocio en aplicaciones, puede ser util gerentes operativos responsables de estosprocesos, ver imagen 3.21.


Modelo

Figura 3.21: Meta Modelo punto de vista Uso de Aplicacion

Ejemplo

En la imagen 3.22, se muestra que la aplicacion se centra en dar el soporte para adelantar elproceso de documentacion, el cual es un proceso del negocio que se enfoca en depurar la informacionsobre las vıctimas del conflicto armado, con el fin de que se realice el tramite de la indemnizacion,para esto Indemniza cuenta con un componente propio que se encarga de realizar las respectivasvalidaciones que aseguran que el proceso es completo y satisfactorio.

Figura 3.22: Modelo punto de vista Uso de Aplicacion


Punto de Vista de Infraestructura

El punto de vista de infraestructura contiene los elementos de la infraestructura de hardwarey software de apoyo a la capa de aplicacion, tales como dispositivos fısicos, redes o software delsistema (por ejemplo, sistemas operativos, bases de datos y middleware).

Este punto de vista tiene como proposito, el identificar la localizacion fısica de los componentesdel sistema, para esto define los nodos, artefactos, nodos, dispositivos y medios de comunicacionentre ellos, ver imagen 3.23.

Modelo

Figura 3.23: Meta Modelo punto de vista Infraestructura

Ejemplo

Como se observa en la imagen 3.24, los componentes tecnologicos de Indemniza estan distri-buidos fısicamente en el centro de computo de la Unidad para las Vıctimas el cual se situa en laciudad de Bogota, dentro del cual se ejecutan los componentes de bases de datos, aplicaciones yservicios Web, el acceso a la informacion se realiza a traves de la Internet desde los dispositivosque usan los funcionarios en el nivel territorial.


Figura 3.24: Modelo punto de vista Infraestructura

Punto de Vista de Uso de Infraestructura

El punto de vista de uso de infraestructura muestra como las aplicaciones son compatibles conla infraestructura de software y hardware, los servicios de infraestructura son entregados por losdispositivos, el software y redes de sistema se proporcionan a las aplicaciones, ver imagen 3.25.

Modelo

Figura 3.25: Meta Modelo punto de vista Uso de Infraestructura


Ejemplo

Se observa que en el modelo dispuesto en la figura 3.26, que los componentes del sistema seubican en cada posicion fısica y se interconectan a traves de la Internet para prestar sus funcionesal nivel territorial desde cualquier dispositivo conectado a ella.

Estos componentes se ejecutaran dependiendo del usuario que utilice el sistema, esto se ve ex-presado en que debido a que Indemniza es un sistema que se ejecuta a traves de Internet todos losusuarios tanto administrativos como de operacion requeriran que de un ordenador para ejecutarsus labores las cuales se ejecutaran en el servidor de aplicaciones, y la informacion tratada seraalmacenada en el servidor de la base de datos a traves del componente designado para este fin.

Figura 3.26: Modelo punto de vista uso de Infraestructura

Punto de Vista Organizacion e Implementacion

El punto de vista de organizacion e implementacion muestra como se realizan una o mas apli-caciones en la infraestructura. Esto comprende el mapeo de aplicaciones (logicas) y componentesy artefactos (fısicas), el mapeo de la informacion utilizada por estas aplicaciones y componentessobre la infraestructura de almacenamiento subyacente, por ejemplo, bases de datos o tablas deotros archivos.

Las vistas de implementacion juegan un papel importante en el analisis de rendimiento y esca-labilidad, puesto que se refieren la infraestructura fısica para el mundo logico de aplicaciones. Enseguridad y analisis de riesgos, puntos de vista de implementacion se utilizan para identificar, porejemplo, las dependencias y los riesgos crıticos, ver imagen 3.27.


Modelo

Figura 3.27: Meta Modelo punto de vista Implementacion y Organizacion

Ejemplo

En la imagen 3.28, se diagrama como en una primera instancia los dispositivos de hardwareimplementan los componentes de software a traves de la Internet para adelantar el proceso de do-cumentacion en los puntos de atencion a vıctimas, una vez el proceso de documentacion es llevadoa cabo, la informacion es cargada a la base de datos central a traves del sistema Indemniza la cualesta alojada fısicamente en el centro de computo de la Unidad para las Vıctimas.

En una segunda instancia se muestra como a traves de una arquitectura SOA, los usuarios en elfront office podran acceder a la informacion del sistema central y realizar el proceso de documenta-cion sin depender de una conexion a Internet, esto a traves de la arquitectura SOA mencionada lacual se encargara de mantener la informacion sincronizada en la base de datos central del sistemaIndemniza.


Figura 3.28: Modelo punto de vista Implementacion y Organizacion

Punto de Vista Estructura de Informacion

El punto de vista estructura de informacion es comparable a los modelos tradicionales de infor-macion creadas en el desarrollo de casi cualquier sistema de informacion. Se muestra la estructurade la informacion utilizada en la empresa o en un proceso de negocio especıfico o aplicacion, enterminos de tipos de datos o las estructuras de clase. Ademas, puede mostrar como la informaciona nivel empresarial esta representado a nivel de aplicacion en la forma de las estructuras de datosutilizadas, y como estas son entonces mapeados sobre la infraestructura subyacente, por ejemplo,por medio de un esquema de base de datos, ver imagen 3.29.

Modelo

Figura 3.29: Meta Modelo punto de vista Estructura de Informacion


Ejemplo

En la imagen 3.30 se muestra como la arquitectura SOA se encargara de gestionar los eventosde sincronizacion entre la base de datos del sistema local y la base de datos del sistema remoto,esto con el proposito de realizar el proceso de documentacion de nucleos familiares vıctimas delconflicto armado.

Adicionalmente se ve que el servidor local y el servidor remoto implementan un modelo de datosigual, esto se debe a que se debe respetar la integridad de la informacion almacenada en Indemniza,el cual corresponde al sistema principal, por ende el sistema sin conexion debe implementar unmodelo de datos similar o en el mejor de los casos identico.

Figura 3.30: Modelo punto de vista Estructura de Informacion

Punto de Vista Realizacion de Servicio

El punto de vista Realizacion de servicio se utiliza para mostrar como uno o mas serviciosde negocio se realizan mediante los procesos subyacentes (y algunas veces por componentes de laaplicacion). De este modo, se forma el puente entre el punto de vista de los productos comercialesy la vista de procesos de negocio. Proporciona una ”vista desde el exterior.en uno o mas procesosde negocio, ver imagen 3.31.


Modelo

Figura 3.31: Meta Modelo punto de vista Realizacion de Servicio

Ejemplo

Como se muestra en la imagen 3.32, el servicio prestado por la Unidad para las Vıctimas, bajo elcual se centra el presente proyecto, consiste en realizar la depuracion de la informacion pre cargadaen el sistema Indemniza, con el fin de tramitar la medida de indemnizacion por vıa administrativaa favor de las vıctimas del conflicto armado, para esto ejecuta un proceso de documentacion, el cualse realiza por los enlaces integrales quienes asumen el rol de documentador, para que finalmente elresultado de este proceso se almacene en la base de datos del sistema Indemniza.

Figura 3.32: Modelo punto de vista Realizacion de Servicio


Punto de Vista por Capas

El punto de vista en capas de imagenes de varias capas y aspectos de una arquitectura empre-sarial en un diagrama. Las capas son el resultado de la utilizacion de la relacion agrupacion parauna particion natural de todo el conjunto de objetos y las relaciones que pertenecen a un modelo,la infraestructura, la aplicacion, el proceso y los actores/capas de papeles pertenecen a la primeracategorıa.

Por lo tanto, podemos separar facilmente la estructura interna y la organizacion de una capadedicada por parte de su comportamiento observable externamente expresado como la capa deservicio que da cuenta de la capa dedicado.

El objetivo principal del punto de vista en capas es proporcionar informacion general en un dia-grama. Ademas, este punto de vista se puede utilizar como apoyo para el impacto de analisis delcambio y analisis de rendimiento o para la ampliacion de la cartera de servicios.

Ejemplo

Figura 3.33: Modelo punto de vista Realizacion de Servicio

Como se muestra en la imagen 3.33, se visualizan las 3 capas de la infraestructura, de la siguientemanera:

Capa de Negocio: se centra en realizar el proceso de documentacion de nucleos familiares, elcual se ejecuta con el proposito de depurar la informacion existe sobre las personas vıctimasdel conflicto armado.


Capa de Aplicacion: se muestra el componente Indemniza, el cual corresponde al sistema enel cual se realiza el proceso de documentacion.

Capa de Infraestructura: se muestra el nodo dado por el servidor de la base de datos, el cualse encarga de almacenar la informacion sobre el proceso realizado en Indemniza.

Punto de Vista Implicados

En este punto de vista se plasman de manera grafica cuales son los usuarios internos y externosdel negocio que interactuan entre para cumplir la meta de la entidad, ası mismo se plasman losobjetivos de cada uno frente al proceso a explicar y la motivacion de cada uno de ellos para queestos objetivos se cumplan, ver imagen 3.34.

Modelo

Figura 3.34: Meta Modelo punto de vista Implicados

Ejemplo

En la imagen 3.35, se muestra como el unico interesado para este caso es el actor Enlace Integral,quien es el funcionario designado por la Unidad para las Vıctimas para atender las solicitudes delas personas vıctimas del conflicto armado, de igual manera se muestran los objetivos empresarialesque este actor abarca y la motivacion empresarial que soporta el desempeno de sus labores.


Figura 3.35: Modelo punto de vista Implicados

Punto de Vista Realizacion de Objetivos

En este punto de vista, se realiza el analisis mas a fondo de los objetivos empresariales mencio-nados en punto de vista de Implicados, ası mismo menciona cuales son las restricciones y reque-rimientos que se deben dar para cumplirse, y las posibles relaciones entre cada uno de ellos, verimagen 3.36.

Modelo

Figura 3.36: Meta Modelo punto de vista Realizacion de Objetivos

Ejemplo

En la imagen 3.37, se muestran como los objetivos expuestos en la imagen 3.35 son comple-mentados por los requisitos y requerimientos que implican un amplio conocimiento de la Ley devıctimas, lo cual es el principal requisito para poder adelantar el proceso de documentacion de


nucleos familiares, el cual a su vez requiere seguir las actividades estipuladas en el protocolo dedocumentacion disenado por la entidad.

Figura 3.37: Modelo punto de vista Realizacion de Objetivos

Punto de Vista Contribucion de Objetivos

En este punto de vista, se realiza el analisis mas a fondo de los objetivos empresariales, asımismo menciona cuales son las restricciones y requerimientos que se deben dar para cumplirse, deigual manera se muestra la influencia positiva o negativa que cada requerimiento o requisito generafrente a los objetivos empresariales, ver imagen 3.38.

Modelo

Figura 3.38: Meta Modelo punto de vista Contribucion

Ejemplo

Como se observa en la imagen 3.39, todos los requerimientos generan una influencia positiva parala materializacion de los objetivos empresariales, lo cual es consecuente y logico, ya que al asegurarque los funcionarios que realizan la atencion de las vıctimas conozcan la ley de vıctimas, generauna mejor y mas eficaz atencion a las solicitudes realizadas por las personas a las que atienden, y


posteriormente al realizar el proceso de documentacion, evitaran uno de los mayores riesgos de laentidad el cual consiste en revictimizar a las personas cuyos derechos han sido vulnerados por elconflicto armado.

Figura 3.39: Modelo punto de vista Contribucion

Punto de Vista Principios

En este punto de vista se muestran los principios que deben asegurar los objetivos de la arqui-tectura empresarial, ver imagen 3.40.

Modelo

Figura 3.40: Meta Modelo punto de vista Principio

Ejemplo

Como se observa en las imagenes 3.41 y 3.42, cada objetivo empresarial tiene asociados susprincipios en donde se repiten los principios de confidencialidad e Integralidad, esto debido alenfoque que tiene la entidad para la atencion de cada vıctima con los mismos parametros decalidad.


Figura 3.41: Modelo punto de vista Principios - Objetivo 1

Figura 3.42: Modelo punto de vista Principios - Objetivo 2

Punto de Vista de Realizacion de Requerimientos

Este punto de vista busca representar graficamente como se relacionan los objetivos empresaria-les con los requisitos y requerimientos empresariales, esto con el fin de asegurar que estos objetivosse cumplan, ver imagen 3.43.


Modelo

Figura 3.43: Meta Modelo punto de vista Realizacion de Requerimientos

Ejemplo

En la imagen 3.44, se muestran como los requerimientos se relacionan con los objetivos organi-zacionales, para este caso se observa como los requerimientos se centran en cumplir el objetivo dedocumentacion de nucleos familiares.

Figura 3.44: Modelo punto de vista Realizacion de Requerimientos

Punto de Vista Motivacion

Este punto de vista relaciona los implicados internos y externos de la organizacion asociandolesa cada uno de ellos, los objetivos organizacionales con los que se relacionas sus funciones, asıcomo la motivacion de cada uno de ellos en cumplir cada objetivo asociado y los requisitos y/orequerimientos que debe cumplir para llevar a cabo su labor, ver imagen 3.45.


Modelo

Figura 3.45: Meta Modelo punto de vista Motivacion

Ejemplo

Figura 3.46: Modelo punto de vista Motivacion

En la imagen 3.46, se muestra como el interesado Enlace Integral, se relaciona con las motiva-ciones necesarias para realizar el cumplimiento de la polıtica organizacional, con esto se busca quecumpla con los requisitos necesarios para realizar el proceso de documentacion de nucleos familiaresy concluya el proceso de atencion a las personas vıctimas del conflicto armado.


Punto de Vista de Proyecto

Un punto de vista del proyecto se utiliza principalmente para modelar la gestion del cambioarquitectura. La arquitectura del proceso de migracion de una vieja situacion (arquitectura em-presarial estado actual) a una nueva situacion deseada (objetivo de arquitectura de la empresaestatal) tiene consecuencias importantes en la estrategia de crecimiento a largo plazo medio y latoma de decisiones y la subsiguiente, ver imagen 3.47.

Modelo

Figura 3.47: Meta Modelo punto de vista Proyecto

Ejemplo

En la imagen 3.48, se muestra como el resultado del presente proyecto se centra en el desa-rrollo de una arquitectura SOA, la cual busca cumplir con el objetivo de realizar el proceso dedocumentacion de nucleos familiares sin la necesidad de estar conectado a Internet, labor que seradesempenada por el funcionario de la Unidad para las vıctimas desde la herramienta Indemniza.

Para esto se generaran los respectivos Web Services que le permitan al funcionario descargar lainformacion a una extension de Indemniza que funcionara de manera local y que una vez culminadala labor se sincronizara con el sistema principal para mantener la informacion actualizada en elsistema central.


Figura 3.48: Modelo punto de vista Proyecto

Punto de Vista Migracion

El punto de vista de migracion implica modelos y conceptos que se pueden utilizar para espe-cificar la transicion de una arquitectura existente a una arquitectura deseada. Aquı el punto devista de migracion solo se describe brevemente y se coloca por medio de los conceptos ilustradosen la figura 3.49.

Modelo

Figura 3.49: Meta Modelo punto de vista Migracion

Ejemplo

En la figura 3.50, se muestran los componentes bajo los cuales se realizara el complementode la arquitectura actual, y con el fin de llevar a cabo la migracion del sistema actual bajo laarquitectura en desarrollo se requiere la creacion de los componentes que soporten el modelo de


datos, ası mismo los contextos bajo los cuales se realizara la trasmision de informacion entre elsistema local y el sistema remoto.

Figura 3.50: Modelo punto de vista Migracion

Punto de Vista Implementacion y Migracion

El punto de vista de la implementacion y la migracion se utiliza para relacionar los programasy proyectos de las partes de la arquitectura que se implementan. Esta vista permite el modeladodel alcance de los programas, proyectos, actividades del proyecto en terminos de las mesetas quese realizan o los elementos de la arquitectura individuales que se ven afectados. Ademas, la formaen que se ven afectados los elementos puede ser indicado por la anotacion de las relaciones, verimagen 3.51.

Por otra parte, este punto de vista se puede utilizar en combinacion con el punto de vista delos programas y proyectos para apoyar la gestion de la cartera:

El punto de vista de los programas y proyectos es adecuado para relacionar los objetivos denegocio a los programas y proyectos. Por ejemplo, esto hace posible el analisis a un nivel altosi todos los objetivos de negocio se cubren de manera suficiente por la cartera (s) actual.

El punto de vista de la implementacion y la migracion es adecuado para relacionar los objeti-vos de negocio (y requisitos) a traves de programas y proyectos de (partes de) la arquitectura.Por ejemplo, esto hace posible el analisis de la posible superposicion entre las actividades delproyecto o para analizar la coherencia entre las dependencias y las dependencias del proyectoentre las mesetas o elementos de la arquitectura.


Modelo

Figura 3.51: Meta Modelo punto de vista Implementacion Migracion

Ejemplo

Figura 3.52: Modelo punto de vista Implementacion Migracion


Como se muestra en la imagen 3.52, se relacionan los conceptos de las figuras 3.50 en dondese evidencian los componentes que se desarrollaran para la implementacion de la nueva arquitec-tura, junto con los elementos de la figura 3.50 en donde se muestran los componentes de softwarenecesarios para la nueva implementacion.

3.3. Fase Construccion

Una vez culminado el analisis ejecutado en las fases de Inicializacion y Elaboracion, inicia laetapa de desarrollo de la solucion de software que sera implementada como producto de la puestaen marcha de la arquitectura orientada servicios disenada disenada como objetivo del proyecto.

3.3.1. Analisis y Diseno de la Solucion

Establecer el diseno de una arquitectura de software orientada a servicios que permita a laUnidad para las Vıctimas, estructurar el proceso de documentacion de nucleos familiares parafuncionar sin conexion con el sistema principal, a traves de la implementacion de Web Services quepermitan:

Descargar informacion del sistema central a una una extension del mismo que funcione demanera local.

Sincronizar el sistema local con el sistema remoto, para actualizar en este ultimo con lainformacion recopilada sin conexion.

Inicialmente, se toma como principio que el insumo principal de trabajo esta disponible en la basede datos del sistema Indemniza, y que para acceder a ella se requiere que en el este se desarrollenlas funcionalidades que permitan descargar la informacion al sistema local.

En una segunda etapa, se parte del principio en el cual el proceso de documentacion fue eje-cutado en su totalidad y se requiere la sincronizacion de esta informacion con el sistema principal,para esto la arquitectura desarrollada debe implementar un nuevo Web Service que permita realizaresta labor, tal como se ilustra en la figura 3.53.

Figura 3.53: Interoperabilidad del sistema Indemniza remoto y el sistema Indemniza local

Segun se muestra en la figura 3.53, el intercambio de informacion desde el sistema Indemnizase realizara con una extraccion de si misma, con esto se busca asegurar una interoperabilidad entreambos sistemas de manera fluida para asegurar la confiabilidad, velocidad, eficiencia, mantenibili-dad, potabilidad y disponibilidad permanente de los mismos.

3.3. FASE CONSTRUCCION 77

3.3.2. Descripcion de la Arquitectura

De acuerdo a los requerimientos establecidos se describe una arquitectura orientada a servicios(SOA) a traves del uso de un Bus de servicios, diseno arquitectonico basado en servicios web quesoportan la transformacion de los datos a traves de la interoperabilidad de los sistemas.

La arquitectura del componente de la aplicacion esta basada en disponer servicios web, tecno-logıa que permite la comunicacion entre el el sistema Indemniza remoto y a extension del mismoque funciona de manera local en un ordenador personal, diseno de una interfaz de software quedescribe un conjunto de operaciones a traves de la mensajerıa XML estandarizada con el objetivode intercambiar datos con otro servicio web.

En la figura 3.54,se muestra un ejemplo de los procesos que el BUS entrarıa atender para lo-grar dicho objetivo. Cuando la Unidad para las Vıctimas defina realizar una jornada de atenciona personas que son vıctimas del conflicto armado e identifica que en el lugar de atencion no existeuna buena cobertura de las TIC o que el acceso a Internet es limitado, los funcionarios deberanrealizar la descarga de la informacion al sistema local, se debe dejar una marca que genera unefecto bloqueante sobre la informacion descargada en el sistema principal, esto con el fin de evitarque la informacion sea modificada en el sistema remoto y en el sistema local.

Posteriormente, cuando el proceso de documentacion en la jornada de atencion termine, desdeel sistema local se deberan realizar las operaciones de sincronizacion con el sistema principal, estocon el fin de actualizar el sistema principal con la informacion recopilada, evitando ası la perdidade informacion y asegurar la integridad de datos sobre las vıctimas del conflicto armado.

Figura 3.54: Interoperabilidad del sistema Indemniza remoto y el sistema Indemniza local

La propuesta de interoperabilidad es cumplir con el objetivo que desde el sistema Indemnizase pueda ejecutar las funciones de depuracion sobre la informacion pre-cargada sobre las personasvıctimas del conflicto armado, definicion de destinatarios con igual o mejor derecho a recibir laindemnizacion, distribucion de porcentajes de la medida de Indemnizacion aplicando la logica denegocios definida por la Unidad para las Vıctimas, en lugares en donde no sea posible establecer


conexion con el sistema principal a traves de la Internet.

Aspectos que implican el uso de componentes de software que permitan homologar datos entreel sistema Indemniza (remoto) y su extension que funciona de manera local, y realizar las tareasde consolidacion y sincronizacion entre ambos sistemas con el fin mantener la informacion sobrelas vıctimas del conflicto actualizada y disponible para ayudar en el proceso de reparacion integralde las mimas.

Los componentes de software planteados se obtienen a traves del uso de un Bus de servicios,el cual es una tecnologıa que permite que aplicaciones se comuniquen entre sı, sin importar quesean heterogeneas a nivel de uso de lenguajes de programacion, modelos de datos, o interfaz deusuario. El Bus dispone componentes encargados de estandarizar los tipos de datos de las diferen-tes aplicaciones a interconectar, funcionando como una capa intermedia, o tercero que permite lacomunicacion entre las partes. Esta tecnologıa es empleada cuando:

existen numerosos puntos de integracion,

existen perspectivas de crecimiento de la arquitectura,

se requieren procesos de mediacion entre dos o mas puntos de gestion de datos (transformacionde los datos por ejemplo), y

es necesario asegurar la escalabilidad, gestion, monitoreo, transformacion y seguridad en elintercambio de la informacion.

3.3.3. Especificaciones de desarrollo

Desarrollo de Software

El desarrollo de los componentes de Software, especıficamente el desarrollo del/los Web Ser-vices que haran posible el funcionamiento de la arquitectura SOA, son desarrollados en lenguajeC# el cual corresponde a un lenguaje de programacion que se ha disenado para compilar diversasaplicaciones que se ejecutan en .NET Framework. Es simple, eficaz, con seguridad de tipos y orien-tado a objetos. Las numerosas innovaciones de C# permiten desarrollar aplicaciones rapidamentey mantener la expresividad y elegancia de los lenguajes de estilo de C.

Visual C# es una implementacion del lenguaje C# de Microsoft. Visual Studio ofrece compa-tibilidad con Visual C# con un completo editor de codigo, un compilador, plantillas de proyecto,disenadores, asistentes para codigo, un depurador eficaz y de facil uso y otras herramientas. Labiblioteca de clases de .NET Framework ofrece acceso a numerosos servicios de sistema operativoy a otras clases utiles y adecuadamente disenadas que aceleran el ciclo de desarrollo de manerasignificativa.

Procesamiento de datos

El procesamiento de los datos se realizo, implementando la base de datos del sistema Indem-niza la cual es en lenguaje SQL Server 2012 y su modelo entidad relacion actual ver figura 3.55,centrandose en las entidades que realizan el tratamiento de la informacion correspondiente exclu-sivamente el proceso de documentacion que se adelanta desde Indemniza, es decir, que la imple-mentacion del servicio Web se centrara en las entidades:

Persona

3.3. FASE CONSTRUCCION 79

PersonaDatosContacto

ProcesoDocumental

usuarioXRadicado

Figura 3.55: Modelo Relacional BD Indemniza

Integracion de Servicios

Service Bus de Azure, proporciona comunicacion habilitada para la nube, con mensajerıa em-presarial y comunicacion retransmitida que ayuda a conectar las soluciones locales con la nube.Cuenta con el servicio Retransmision de bus de servicio, el cual resuelve los retos de comunicacionentre las aplicaciones locales y el mundo exterior, ya que permite que los servicios web locales


proyecten extremos publicos. Despues, los sistemas pueden obtener acceso a estos servicios web,que continuan ejecutandose localmente desde cualquier lugar del planeta.

Ası mismo, asegura la escalabilidad de las aplicaciones y la comunicacion entre las mismas demanera asıncrona, por esto Service Bus de Azure, busca la integracion de recursos en la nube,como Base de datos SQL, Almacenamiento y Aplicaciones web del Servicio de aplicaciones de Azu-re, con mensajerıa del Bus de servicio garantiza un funcionamiento perfecto con cargas pesadas yvariables, con la durabilidad para superar interrupciones intermitentes.

Diagramas de Secuencia

Los diagramas de secuencia, se encargan de representar los objetos intervinientes en un procesodel sistema como lıneas de vida durante su ejecucion, representan las interacciones entre objetos atraves del intercambio de mensajes y respuestas entre ellos.

Los diagramas presentados a continuacion, hacen referencia a la comunicacion entre objetos paralos siguientes procesos del sistema:

Descarga de Informacion desde el sistema remoto

Como se observa en la figura 3.56, para la descarga de datos desde el sistema remoto haciala base de datos del sistema local, se requiere la actuacion del enlace integral quien en un primermomento, debe realizar la consulta de los casos que desea descargar, posteriormente el componentede descarga realizara el cargue de la informacion seleccionada a la base de datos local y realiza lamarcacion en el sistema remoto con el fin de evitar modificacion de los datos en ambos sistemas yfinalmente notificara al usuario sobre el resultado del proceso efectuado.

Figura 3.56: Diagrama de Actividad, Descarga de Datos a BD Local

3.4. FASE TRANSICION 81

Sincronizacion con el sistema remoto

Figura 3.57: Diagrama de Actividad, Sincronizacion con la BD Remota

Como se observa en la figura 3.57 para este caso, el proceso inicia desde el componente desincronizacion, el cual validara la conexion con el sistema remoto y en caso de obtener una conexionexitosa, realizara la consulta de la informacion en la base de datos local, para posteriormenteactualizarla en la base remota y una vez se obtenga la respuesta exitosa del proceso se eliminarande la base local los datos ya sincronizados.

3.4. Fase Transicion

En la fase de transicion se asegurara que el software que se entrega a los usuarios sea confiable,funcional y con un rendimiento aceptable de acuerdo a los resultados de las pruebas aplicadas sobrela version obtenida en la fase de Construccion.

Inicialmente se realiza la mitigacion de los riesgos asociados a la metodologıa a implementar parael proceso de pruebas y a continuacion se realiza la descripcion del despliegue de la solucion desa-rrollada en el ambiente de pruebas correspondiente.

A continuacion, se generara un conjunto de pruebas que estara conformado por los modulos decasos de uso, operaciones con la base de datos, rendimiento, seguridad y configuracion con el finde verificar que el total de funcionalidades que componen el software operen correctamente. Estosera de gran utilidad para detectar inconsistencias que implicaran realizar ajustes al codigo fuentesiempre y cuando se mantenga la funcionalidad establecida por la arquitectura.


Riesgos detectados en la fase de transicion

Debido a que esta fase contempla las actividades de prueba al software desarrollado, el riesgoprincipal detectado consiste en la dificultad, que se presenta en la escogencia de las actividadesde pruebas de software a implementar, ya que los resultados recopilados pueden influir de maneranegativa en el funcionamiento negativo del sistema.

Para minimizar estos riesgos se realizo una consulta sobre las diferentes tecnicas para realizarpruebas sobre el desarrollo de software orientado a objetos, los cuales se muestran en el anexo .Para este proceso, se determino que la prueba a implementar es la denominada caja negra, pruebade componentes, revision de prototipos y prueba de interfaz de usuarios.

3.4.1. construccion del ambiente de Pruebas

Como preambulo al proceso de pruebas, cabe resaltar que debido a la confidencialidad de lainformacion que implementa el sistema Indemniza, la Unidad Para las Vıctimas autorizo la im-plementacion de un modelo de datos similar al implementado en el sistema Indemniza, en dondese pueda observar la relacion entre las entidades del modelo relacional que intervienen durante elproceso de documentacion el cual se alimentara con informacion simulada, con el fin de simular elfuncionamiento de la implementacion de la SOA y los Web Services que ejecuta.

Una vez dicho esto, a continuacion se describe el ambiente bajo el cual se desarrollaron las pruebasa los Web Services desarrollados:

Ambiente Local

Para implementar de manera adecuada las pruebas de software se dispuso de un computadorde escritorio con las siguientes especificaciones:

Sistema Operativo: Windows 7 Ultimate SP 1

Procesador: Intel R©CoreTMi3-3110M CPU @ 2.40GHz

Memoria RAM: 8 GB

Arquitectura del sistema: 64 bits

Adicionalmente, se hizo necesario la instalacion del motor de la base de datos Microsoft. SQLServer 2012, y la activacion del servidor IIS V7 de Microsoft. la cual ya viene implementada dentrodel sistema operativo del sistema.

Una vez preparado el servidor, se procede a la creacion del sitio web a traves del IIS de Mi-crosoft y la configuracion de su usabilidad para asegurar la correcta compilacion de aplicacionesASP, finalizando esto, se realiza el cargue de los documentos de la solucion desarrollada en el ser-vidor.

Adicionalmente se realiza la creacion de la base de datos del sistema en el motor de base de datosSQL Server, lo anterior se realizo segun lo expuesto en el capitulo destinado para la explicacion afondo sobre la construccion del prototipo.

Capıtulo 4

Diseno y Construccion delprototipo

Introduccion

Como culminacion del proceso de desarrollo del proyecto y para dar cumplimiento a los objeti-vos dispuestos en la seccion 1.2, se presenta a continuacion las caracterısticas de mayor relevanciadurante el proceso de construccion del prototipo funcional en el cual se realizo la simulacion dedisposicion y consumo de los recursos dispuestos por la arquitectura SOA desarrollada.

Como punto inicial para el proceso de construccion del prototipo para poner a prueba la ar-quitectura disenada, cabe resaltar que la Unidad para las Vıctimas autorizo el acceso a parte delmodelo de datos para la construccion del mismo, esto a razon de las polıticas de confidencialidaddispuestas por la entidad, las cuales no permiten la manipulacion de la informacion de las vıctimasdel conflicto armado en ambientes ajenos a los institucionales, por esto la informacion cargada ymanipulada desde el prototipo construido corresponde a una simulacion y es valida unicamentepara fines academicos.

4.1. Caracterısticas de Software

Como se menciono en el capitulo de Ingenierıa del proyecto, se implemento como IDE de desa-rrollo Visual Studio en su version 2015 Enterprise, la cual ofrece distintas caracterısticas parafacilitar el proceso de desarrollo de soluciones de software, entre estas se destaca la integracion conBoostrap como Framework que permite crear interfaces web con CSS y JavaScript, cuya particula-ridad es la de adaptar la interfaz del sitio web al tamano del dispositivo en que se visualice. Es decir,el sitio web se adapta automaticamente al tamano de una PC, una Tablet u otro dispositivo. Estatecnica de diseno y desarrollo se conoce como “responsive design” o diseno adaptativo [Solis, 2014].

Otra de las caracterısticas de gran importancia en la implementacion de Entity Frameworks, el cualcorresponde a un conjunto de tecnologıas de ADO.NET que permiten el desarrollo de aplicacionesde software orientadas a datos, esto con el fin de suplir la necesidad de aplicaciones orientadas adatos de lograr dos objetivos muy diferentes, apoyando las labores de modelado de las entidades,las relaciones y la logica de los problemas empresariales que resuelven, y tambien trabajar con losmotores de datos que se usan para almacenar y recuperar los datos.

83

84 CAPITULO 4. DISENO Y CONSTRUCCION DEL PROTOTIPO

Entity Framework permite trabajar con datos en forma de objetos y propiedades especıficos deldominio, como clientes y direcciones de cliente, sin tener que preocuparse por las tablas y columnasde la base de datos subyacente donde se almacenan estos datos. Con Entity Framework, se puedetrabajar en un nivel mayor de abstraccion al momento de implementar estructuras de datos, y sepueden crear y mantener aplicaciones orientadas a datos con menos codigo que en las aplicacionestradicionales [MicrosoftCorporation, 2016].

4.1.1. Patrones de diseno

Segun lo mencionado anteriormente acerca de Entity Framework, todos los objetos del modelode datos implementados fueron mapeados y creados a forma de objeto dentro del proyecto, locual permite la creacion de estos objetos y la instanciacion de los mismos en el momento que serequiera [Hurtado, 2013].

A continuacion en la imagen 4.1 se muestra el ejemplo de como las funcionalidades dispuestaspor Entity Framework de ADO.NET realizan el mapeo de los objetos del modelo de datos y losgenera a modo de clases en el sistema para su implementacion, lo cual se realiza segun se muestraen la figura 4.2.

Figura 4.1: Creacion automatica de la clase persona, realizada por las funcionalidades dispuestaspor Entity Framework de ADO.NET

4.1. CARACTERISTICAS DE SOFTWARE 85

Figura 4.2: Ejemplo de instanciacion de la clase Persona para la insertar datos en la base de datos.

Este mismo procedimiento se realizo para el manejo de datos en la base de datos, en dondetodos los objetos requieren su instancia dentro de un contexto el cual se define por el modelo dedatos para definir un contexto de aplicacion, posteriormente se modifican las propiedades de losatributos de la instancia de la clase y se imputan en la base de datos guardando el contexto oentorno de datos con las modificaciones realizadas.

4.1.2. Definicion de Componentes de software

Inicio de sesion

En concordancia con lo establecido en los requerimientos definidos para el sistema, se hacenecesario que el usuario que va a realizar el proceso de documentacion, debe ser un funcionarioactivo de la Unidad para las Vıctimas y debe estar autorizado para acceder al sistema Indemniza,por tanto debe autenticarse para acceder al sistema y a la informacion dispuesta en el, para estose dispone un Modulo dentro del prototipo el cual se encarga de validar que un usuario tengaautorizado el acceso a Indemniza antes de poder trabajar con el sistema en su totalidad, tal comose muestra en la imagen 4.3, en donde en caso de que el usuario ingresado no cuente con un usuariovalido y activo no se tendra el acceso autorizado al sistema.

Descarga de informacion al sistema Local

Como se menciono en la imagen 3.56, se requiere una interfaz por medio de la cual el usuarioseleccione los casos que va a documentar y por ende los requiere disponibles para su tratamientocon o sin conexion con el sistema principal, para esto se dispone un modulo en el prototipo pormedio del cual el funcionario debera buscar los casos (desde el radicado o el numero de documento)y descargarlos al sistema local, para posteriormente proceder a su depuracion. En la figura 4.4, semuestra como desde el modulo dispuesto para la descarga de casos al sistema local, el funcionario


Figura 4.3: Validacion de credenciales de acceso desde el modulo Login del prototipo.

Figura 4.4: Modulo de descarga de datos desde el sistema remoto al sistema local

debera realizar la busqueda del caso que desea descargar ya sea teniendo el numero de radicado oel numero de documento de la vıctima que se va a documentar de manera Offline, y posteriormenteseleccionarlo desde la grilla de resultados para que despues el sistema cargue esta informacion a labase de datos del servidor Local.

Componente de sincronizacion

Dentro del prototipo para comprobar el funcionamiento de la arquitectura desarrollada, se hizonecesario construir el ambiente de software que se encargara de consumir los Web Services desarro-llados para sincronizar un ambiente que simula el funcionamiento de Indemniza y que funciona demanera local sin conexion con el servidor remoto, este ambiente y sus componentes se han descritoa lo largo de este capıtulo, ahora es momento de mostrar el verdadero componente que hace partede la Arquitectura SOA desarrollada.

4.1. CARACTERISTICAS DE SOFTWARE 87

Para la sincronizacion entre el ambiente local y el ambiente remoto, se dispuso de un Web Serviceel cual tiene un unico contrato para su operacion de nombre sincronizacionDatosServerLocal y tipobooleano, el cual recibe como parametros el usuario y contrasena del usuario logeado (esto paraasegurar que el usuario que realiza la peticion de actualizacion exista en la base de datos tantolocal como remota), y un objeto de tipo vw consultaCasoDocumentacion, tal como se muestra acontinuacion en la imagen 6.1.

Su funcionamiento se centra en tomar el objeto vw consultaCasoDocumentacion, y actualizar elobjeto de la base de datos que corresponda al mismo existe en la base de datos remota, paracargarle la informacion actualizada.

Figura 4.5: Codigo fuente contrato sincronizacion entre sistema local y remoto

El contrato es de tipo Booleano con el fin de evaluar el exito del proceso de sincronizacion, yen caso de que el resultado se exitoso se eliminara la informacion de la base local con el fin deasegurar que la informacion haya sido actualizada en el sistema remoto.

Parte III

Cierre de la Investigacion

89

Capıtulo 5

Resultados y Discusion

Segun los parametros establecidos en las pruebas de software determinadas, a continuacion sedescriben los resultados obtenidos:

5.1. Pruebas al Modelo de Negocios definido

En este apartado, se muestran las pruebas efectuadas al modelo de datos destinado para lasolucion propuesta, como se menciono en el capitulo anterior, se hizo necesaria la construccion deun prototipo para realizar la simulacion de consumo de los Web Services desarrollados como partede la arquitectura a implementar.

La ejecucion de dichos scripts tanto en el servidor local como el servidor remoto fue exitosa,la base de datos fue creada sin presentar errores y la generacion de los ındices, procedimientosalmacenados y vistas se realizo sin contratiempos.

Se realizo la comprobacion del funcionamiento de las bases de datos, en una primera instanciadesde el acceso al EntityDataFramework dispuesto por Visual Studio y C# con el fin de poderdefinir estructuras de datos las cuales se consultaron implementando LinQ, y en un segundo mo-mento se realizo el acceso a la informacion a traves de consultas en la base de datos implementandoconsultas estandar en lenguaje SQL, la respuesta del sistema y el resultado de la misma fue satis-factorio.

5.2. Pruebas a los Casos de Uso Establecidos

En este momento se especifican los resultados obtenidos al ejecutar las pruebas, que contemplanla interaccion entre los stakeholders y el sistema, esto depende del perfil de acceso que cada usuariotiene asociado.

Las pruebas ejecutadas se dividieron en dos ambientes, ambiente local y ambiente remoto. Dentrode las pruebas definidas dentro del ambiente local, no se observaron fallas de funcionamiento de laaplicacion y la interaccion interna del mismo frente con el motor de la base de datos, ası mismotampoco se generaron fallas en el llamados a los metodos implementados en el Web Service deintegracion y sincronizacion.

91

92 CAPITULO 5. RESULTADOS Y DISCUSION

Los contratiempos presentados durante la prueba al modelo de datos y el acceso a la informa-cion, se presentaron a nivel conceptual sobre el manejo de LinQ y su sintaxis para la consulta yacoplamiento de los objetos de la base de datos y su cargue en la interfaz que se presenta de cara alusuario, eso se soluciono gracias a la basta y completa documentacion que existe sobre este temala cual esta dispuesta en la pagina de Internet de Microsoft.

5.3. Arquitectura

Para realizar las pruebas correspondientes a la arquitectura del sistema propuesto, se tomaronen cuenta los siguientes aspectos:

5.3.1. Conexion

Como se menciono anteriormente, se dispuso de la instalacion del sistema propuesto en unambiente local y un ambiente remoto, las especificaciones de cada maquina utilizada es:

Item MaquinaProcesador Intel(R) Core(TM) i3-4005U CPU @ 1.70GHzSistema OperativoDisco Duro 1 TBMemorial (RAM) 8 GBDireccion de acceso http://localhost:8070/Account/Login

Cuadro 5.1: Especificaciones de la maquina usada para el ambiente de pruebas de la solucion

Bajo ambas plataformas se realizaron las pruebas de conectividad del portal y la base dedatos y la navegabilidad entre las diferentes paginas, de igual manera en el servidor remoto sedispuso el Web Service para su consumo desde el servidor Local y las operaciones se realizaron sincontratiempos entre ambos sistemas.

5.3.2. Funcionalidad

La solucion desarrollada, corresponde a un instrumento que brinda la informacion real y objetivacomo soporte para responder adecuadamente a las necesidades del negocio.

5.3.3. Confiabilidad

El portal define las diferentes metricas. Una es la navegabilidad, la cual es determinada atraves del diagrama de secuencia como se puede ver en la parte de ingenierıa, ademas se realizaronrespaldos para asegurar la informacion contenida en el portal, por lo que se asegura una facilrecuperacion en caso de perdida de la misma, dichas pruebas se realizaron en un ambiente basadoen Windows 7.

5.3.4. Eficiencia

Durante el desarrollo de las pruebas en el comportamiento del sistema, se realizaron pruebasque contemplan el intercambio de informacion entre pantallas, y entre la aplicacion y la base dedatos.

5.3. ARQUITECTURA 93

Los resultados obtenidos permiten determinar que la respuesta del sistema no lleva mas de 110msen el ambiente local y 125ms en el ambiente remoto, con lo anterior se comprueba que el com-portamiento de la aplicacion en ambiente local y remoto es eficiente con un consumo mınimo derecursos del servidor.

5.3.5. Mantenimiento

Debido a la implementacion del .NetFrameworks 4.5, definido por Visual Studio durante la fasede construccion de la solucion propuesta, se permite establecer que la implementacion de nuevasfuncionalidades, ası como la adaptacion de los metodos actuales segun nuevos requerimientos, noimpactarıa en gran magnitud el funcionamiento del sistema desarrollado, esto debido a que sepermite la creacion de entornos de prueba dentro del ambiente de desarrollo, lo cual no afecta losdatos reales.

5.3.6. Portabilidad

Recordando lo establecido dentro de la estructura tematica del sistema, la solucion desarrolla-da corresponde a un portal web, por ende la usabilidad de la herramienta se realiza a traves deInternet, lo cual asegura una portabilidad al 100 % de la herramienta.

El unico limitante que condiciona la implementacion del prototipo desarrollado para la ejecu-cion de las pruebas, corresponde al servidor en donde se debe alojar, ya que debido a la tecnologıaimplementada se requiere su funcionamiento bajo un servidor con arquitectura Microsoft.

Adicionalmente, cabe aclarar que para la implementacion de la arquitectura desarrollada juntocon sus componentes no se requiere un software especializado ya que los principales componentesde la misma corresponden a Web Services, los cuales son consumidos desde la herramienta que asılo requiera y la unica tarea que generarıa un esfuerzo adicional corresponde a la que se enfoque enel consumo de dichos Web Services.

5.3.7. Seguridad

Los niveles de seguridad implementados para el uso del sistema propuesto corresponden a:

El ingreso al prototipo requiere obligatoriamente que sea a traves de un usuario registradopreviamente en el sistema

Las contrasenas de acceso al sistema, son encriptadas mediante el algoritmo MD5 y almace-nadas en la base de datos.

La informacion que se transfiere y se trasforma dentro del Web Service, es almacenada en labase de datos del sistema principal con el fin de llevar el control de las fechas de consumo, lavigencia y validez de la informacion tratada.

En cada una de las paginas maestras que implementa el sistema, se valida el rol de acceso ala misma con el fin de impedir el acceso de usuarios a funcionalidades restringidas segun elperfil definido.

94 CAPITULO 5. RESULTADOS Y DISCUSION

5.4. Navegacion

Las interfaces desarrolladas en la prototipo propuesto, son del tipo amigable visualmente conel usuario del mismo, de igual manera los formularios implementados permiten un uso intuitivodel sistema. Sin embargo, se desarrollo el manual de usuario del sistema, con el fin asegurar que seaprovechen al 100 % las funcionalidades desarrolladas.

Capıtulo 6

Conclusiones y Recomendaciones

6.1. Conclusiones

El proceso que se ejecuta en la Unidad para las vıctimas, referente a la depuracion delregistro unico de vıctimas se centra en la recopilacion de informacion suministrada por laspersonas que estan reconocidas como vıctimas en proceso de reparacion integral, por esto elsistema Indemniza debe adaptarse a la normativa que dicta la Ley de vıctimas, lo cual debeir orientado a la polıtica del post conflicto adelantada por el gobierno nacional.

El acceso a las tecnologıas de informacion (TIC), no debe ser un impedimento para laspersonas que son sujeto de atencion por parte de la Unidad para las Vıctimas, por el contrarioes la entidad quien debe asegurar el abordaje de la poblacion con difıcil acceso a las TICcon el fin de cumplir la polıtica institucional y los objetivos organizacionales que rigen elfuncionamiento de la entidad misma.

La implementacion de los puntos de vista propuestos por Archimate permite abordar lanecesidad en las que se centra el proyecto, dejando de lado la complejidad de los temastecnologicos y volcando su esfuerzo en el modelado de la solucion a implementar en unlenguaje comprensible para la organizacion.

La arquitectura propuesta en la metodologıa no solamente se podra implementar con lastecnologıas seleccionadas, tambien se podran acoger a otros sistemas de informacion desa-rrollados en la entidad con el fin de controlar el proceso de reparacion integral mencionadoen la Ley de victimas llevando las trazabilidad de los procesos ejecutados en cada una de lasetapas que contempla la ruta de reparacion.

La estandarizacion y parametrizacion que se lleva a cabo desde el sistema Indemniza, permiteun mayor control sobre la informacion de cada vıctima del conflicto armado en proceso deatencion, lo cual se vera complementado con la implementacion de la arquitectura disenadasupliendo la necesidad actual de la entidad la cual radica en la dependencia obligatoria deuna conexion a la Internet.

La necesidad de la Unidad para las Vıctimas en cumplir su polıtica institucional, generanecesariamente la necesidad de evolucionar tecnologicamente al punto de actualizar sus sis-temas de informacion actuales con el fin de expandir su espectro de poblacion atendida, locual da cabida a la aprobacion de la arquitectura disenada como proposito de este proyectoy su posterior implementacion en sus procesos de atencion.

95

96 CAPITULO 6. CONCLUSIONES Y RECOMENDACIONES

Las facilidades que se ven implementadas por Visual Studio permiten realizar el desarrolloagil y confiable, de soluciones de software sin importar la complejidad de las mismas.

La metodologıa implementada en la ejecucion de pruebas, aseguro el desarrollo de las mismasde manera mas organizada, permitiendo enfocar el esfuerzo en los distintos aspectos quecomponen todo el software como son: el rendimiento, la configuracion, la logica del negocioy funcionalidad. Asegurando con esto una eficacia y correccion de fallas del sistema con unaeficacia del 100 %.

6.2. Recomendaciones

La implementacion del software debe realizarse en navegadores web que soporten complemen-tos AJAX e interpreten el lenguaje HTML5 de manera nativa, tales como Google Chromeen version 10 o posterior, Mozilla Firefox, Safari entre otros.

La Unidad para las Vıctimas con el fin de aplicar polıticas anti fraude en sus procesos, paraesto considero que serıa de gran ayuda la implementacion de lectores biometricos con el finde blindar en un nivel de seguridad mayor, ası como la firma digital con esto hacer uso delas TIC para minimizar el riesgo de fraude durante el proceso de indemnizacion.

Para una mayor seguridad sobre la informacion de los documentos cargados en el sistema, espertinente la implementacion en el mismo de certificados digitales, firmas digitales y encrip-tacion de archivos, para evitar ataques informaticos que atenten contra la integridad de lainformacion almacenada en el sistema.

La Unidad para las Vıctimas, implementa 4 sistemas de informacion que trabajan de maneraindependiente dependiendo del enfoque de cada uno de ellos, la recomendacion consiste enadelantar esfuerzos para trabajar en la integracion de los mismos aprovechando el ESB actualy las caracterısticas del mismo para tal fin, con eso se puede brindar una mejor asesorıa a lavıctima durante su proceso de reparacion.

Debido al enfoque institucional se puede pensar en el complementar el sistema Indemnizacon el fin de explotar las tecnologıas moviles y no depender de maquinas portatiles para eldesarrollo de sus labores, dando con esto comodidad a sus funcionarios, y a la cantidad deservicios desarrollados para estos dispositivos, las cuales pueden ayudar en la optimizacionen la ejecucion de los procesos.

Bibliografıa

[Alfsan, 2012] Alfsan (2012). Arquitectura de n capas.

[Ambler, 2012] Ambler, S. W. (2012). Metodo de pruebas orientada a objetos para el ciclo de vidacompleto (floot).

[Antonio Villalpando, 2014] Antonio Villalpando, Arnold Cisneros, D. E. C. H. C. Y. I. n. z. C. a.v. v. (2014). Arquitectura empresarial, architect, archimate y togaf.

[Codejobs, 2015] Codejobs (2015). ¿que es el modelo cliente-servidor? networking - aprende aprogramar.

[de la Torre, 2014] de la Torre, C. (2014). What is .net core 5 and asp.net 5 within .net 2015preview — cesar de la torre [microsoft] – blog.

[Escalante, 2013] Escalante, L. C. (2013). El patron de arquitectura n-capas con orientacion aldominio como solucion en el diseno de aplicaciones empresariales.

[Group, 2013] Group, T. O. (2013). Archimate: Specification motivation extension.

[Hurtado, 2013] Hurtado, C. (2013). Ejemplo patron singleton.

[Juan Carlos Cedeno, ] Juan Carlos Cedeno, Jonathan Delgado Guerrero, L. G. A. B. d. l. T.Archimate: lenguaje para modelamiento de la arquitectura empresarial.

[lt, 2012] lt, D. (2012). Orquestacion y coreografia de servicios web.

[Marsili, 2007] Marsili, D. (2007).

[Microsoft, ] Microsoft. C#.

[Microsoft, 2006] Microsoft (2006). Whitepaper: La arquitectura soa de microsoft aplicada al mun-do real.

[MicrosoftCorporation, 2016] MicrosoftCorporation (2016). Informacion general de entity frame-work.

[Perez, 2012] Perez, J. R. P. (2012). Servicios web: Orquestacion y coreografıas.

[Rodriguez, 2016] Rodriguez, F. (2016).

[Rodrıguez, 2012] Rodrıguez, E. (2012). Metodologia rup: Fases de diseNo y construcciOn.

[Saiz, 2015] Saiz, S. M. (2015). Estudio de arquitecturas software para servicios de internet de lascosas.

97

98 BIBLIOGRAFIA

[Solis, 2014] Solis, J. (2014). ¿que es boostrap y como funciona en el diseno web?

[Tijs Rademakers, 2008] Tijs Rademakers, J. D. (2008). Open-Source ESBs in Action.

[UARIV, 2012] UARIV (2012). Organigrama institucioal.

[W3C, 2012] W3C (2012). Guıa breve de servicios web.

100 BIBLIOGRAFIA

An

exo

A-

Matr

izd

eR

iesg

os

para

el

Desa

rroll

od

el

Pro

yect

o

Fig

ura

6.1:

Cod

igo

fuen

teco

ntr

ato

sin

cron

izaci

on

entr

esi

stem

alo

cal

yre

moto

Anexo B - Definicion y Descripcion detipos de pruebas de Software

La metodologıa de Pruebas Orientada a Objetos para el Ciclo de Vida Completo(en ingles ”FullLife-Cycle Object-Oriented Testing”, FLOOT) es una coleccion de tecnicas para verificar y validarsoftware orientado a objetos.

El ciclo de vida FLOOT, indica una amplia variedad de tecnicas (descritas en la Tabla 6.1) queestan disponibles en todos los aspectos del desarrollo de software. La lista de tecnicas no pretendeser completa – por el contrario su objetivo es hacer explıcito el hecho de que se cuenta con unamplio rango de opciones disponibles.

Es importante entender que aunque el metodo FLOOT es presentado como una coleccion de fa-ses secuenciales no necesariamente tiene que ser ası: las tecnicas de FLOOT pueden ser aplicadastambien con procesos agiles/evolutivos. La razon por la que presento FLOOT de una forma “tra-ditional” es para volver explicito el hecho de que en realidad usted puede realizar pruebas en todoslos aspectos del desarrollo de software no solamente durante la codificacion.

Prueba Descripcion

Prueba de Caja NegraLa prueba verifica que el Item que se esta probando, cuandose dan las entradas apropiadas produce los resultados esperados.

Prueba de ValoresFrontera

Es la prueba de situaciones extremas o inusuales que el Item debeser capaz de manejar.

Prueba de ClasesEs el acto de asegurar que una clase y todas sus instancias cumplencon el comportamiento definido.

Prueba de Integracionde Clases

Es el acto de asegurar que las clases, y sus instancias, conformansoftware que cumple con el comportamiento definido.

Revision de CodigoUna forma de revision tecnica en la que el entregable que se revisaen el codigo fuente.

Prueba de ComponenteEs el acto de validar que un componente funciona tal como estadefinido.

Prueba de CubrimientoEs el acto de asegurar que toda lınea de codigo es ejercita al menosuna vez.

Revision de Diseno Una revision tecnica en la cual se inspecciona un modelo de diseno.

Prueba de Regresionde Herencia

Es el acto de ejecutar casos de prueba de las super clases, tantode forma directa como indirecta, en una subclase especifica.

Prueba de IntegracionConsiste en realizar pruebas para verificar que un gran conjunto departes del software funcionan juntas.

Sigue en la pagina siguiente.

101

102 BIBLIOGRAFIA

Prueba Descripcion

Prueba de MetodoConsiste en realizar pruebas para verificar que un metodo (funcionmiembro) funciona tal como esta definido.

Revision deModelos

Un tipo de inspeccion, que puede ser desde una revision tecnicaformal hasta un recorrido informal, realizado por personasdiferentes a las que estuvieron directamente involucradas en eldesarrollo del modelo.

Prueba de CaminosEs el acto de asegurar que todos los caminos logicos en el codigose ejercitan al menos una vez.

Revision dePrototipos

Es un proceso mediante el cual los usuarios trabajan a traves deuna coleccion de casos de uso, utilizando un prototipo como sifuera el sistema real. El objetivo principal es probar si el disenodel prototipo satisface las necesidades de esos usuarios.

Demostrar conel codigo

La mejor forma de determinar si un modelo realmente refleja loque se necesita, o lo que se debe construir, es construyendosoftware basado en el modelo para mostrar que el modelo estabien

Prueba de RegresionEl acto de asegurar que los comportamientos previamente proba-dos todavıa trabajan como se espera luego que se han realizadocambios a la aplicacion.

Prueba de StressEl acto de asegurar que el sistema funciona como se espera bajograndes volumenes de transacciones, usuarios, carga y demas.

Revision Tecnica

Una tecnica de aseguramiento de la calidad en la cual el disenode tu aplicacion es revisado de forma exhaustiva por un grupode tus companeros. Una revision tıpicamente se enfoca en laprecision, calidad, facilidad de uso y completitud. A este procesousualmente se le llama recorrido, inspeccion, o revision decompaneros.

Prueba de Escenariosde Uso

Una tecnica de prueba en la cual una o mas personas valida unmodelo siguiendo la logica de los escenarios de uso.

Prueba de Interfazde Usuario

Consiste en probar la interfaz de usuario para garantizar quecumple los estandares y requerimientos definidos. Usualmentese refiere a la prueba de interfaz de usuario grafica.

Prueba de Caja BlancaConsiste en realizar pruebas para verificar que lıneas especıficasde codigo funcionan tal como esta definido. Tambien se le conocecomo prueba de caja transparente.

Cuadro 6.1: Metodo de Pruebas Orientada a Objetos para el Ciclode Vida Completo (FLOOT). Fuente [Ambler, 2012]

arquitectura de software para la gesti on del proceso de...

Documents