PROTOTIPO DE AUTOMATIZACIÓN DEL PROCESO DE...

Trabajo de Grado para Optar por el Titulo de Especialista

en Ingeniería de Software

PROTOTIPO DE AUTOMATIZACIÓNDEL PROCESO DE IMPORTACIONES

A COLOMBIA

Manios Rojas Santiago

Alarcón Caballero Carlos

Universidad Distrital Francisco José de Caldas

Facultad de Ingeniería

Especialización en Ingeniería de Software

Bogotá D.C. 2015

Santiago Rojas: En agradecimiento a mis padres por ese apoyo

incondicional que a pesar de la distancia y el tiempo que dejamos de

compartir juntos, me brindaron la fuerza para continuar y poder

realizar un sueño más en mi carrera como profesional; a mi novia,

quien pasó conmigo las noches de desvelo brindándome la compañía

que me permitió entregar a tiempo las actividades académicas; a

todos los compañeros de del grupo dos de la especialización quienes

con su espontaneidad y carisma hicieron alegre todas las clases en la

universidad. Finalmente un enorme y sincero agradecimiento a mi

compañero de tesis, que junto a su disciplina y conocimiento

lográramos terminar esta investigación.

Carlos Alarcón: Agradezco especialmente a mis padres, los cuales me

aconsejaron y animaron para continuar con mis estudios, a mis

compañeros y profesores los cuales me aportaron conocimientos

técnicos y �nalmente a mi novia quien me dio su apoyo y sus

conocimientos sobre el tema de la tesis.

Índice general

I. CONTEXTO DE LA INVESTIGACIÓN 12

1. DESCRIPCIÓN DE LA INVESTIGACIÓN 131.1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.2. Objetivos Especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4.1. Togaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.2. Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . . . . 161.4.3. ArchiMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.4. Capas del Lenguaje Archimate . . . . . . . . . . . . . . . . . . . . 171.4.5. OpenUp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.6. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4.7. Java Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . 191.4.8. Java Server Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4.9. Enterprise Java Bean . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.10. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.5. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.5.1. Comercio Exterior . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.5.2. Importación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.5.3. Incoterm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.5.3.1. Incoterm FOB . . . . . . . . . . . . . . . . . . . . . . . . 221.6. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.6.1. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

II. DESARROLLO DE LA INVESTIGACIÓN 25

2. MODELO DE NEGOCIO 262.1. Misión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2. Visión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3. Objetivos Organizacionales . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3

Índice general

3. MODELAMIENTO DEL NEGOCIO 283.1. Punto de Vista de Organización . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1. Modelo Punto de Vista de Organización . . . . . . . . . . . . . . . 283.2. Punto de Vista de Colaboración de Actores . . . . . . . . . . . . . . . . . 30

3.2.1. Modelo Punto de Vista de Colaboración de Actores . . . . . . . . . 313.3. Punto de Vista de Funciones de Negocio . . . . . . . . . . . . . . . . . . . 32

3.3.1. Modelo Punto de Vista de Funciones de Negocio . . . . . . . . . . 333.4. Punto de Vista de Proceso de Negocio . . . . . . . . . . . . . . . . . . . . 34

3.4.1. Modelo Punto de Vista de Proceso de Negocio . . . . . . . . . . . 353.5. Punto de Vista de Cooperación de Procesos de Negocio . . . . . . . . . . . 36

3.5.1. Modelo Punto de Vista de Cooperación de Procesos de Negocio . . 363.6. Punto de Vista del Producto . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.6.1. Modelo Punto de Vista del Producto . . . . . . . . . . . . . . . . . 38

4. MODELAMIENTO DE LA APLICACIÓN 394.1. Punto de Vista de Comportamiento de Aplicación . . . . . . . . . . . . . . 39

4.1.1. Modelo Punto de Vista de Comportamiento de Aplicación . . . . . 404.2. Punto de Vista de Colaboración de Aplicación . . . . . . . . . . . . . . . . 41

4.2.1. Modelo Punto de Vista de Colaboración de Aplicación . . . . . . . 414.3. Punto de Vista de Estructura de Aplicación . . . . . . . . . . . . . . . . . 42

4.3.1. Modelo Punto de Vista de Estructura de Aplicación . . . . . . . . 434.4. Punto de Vista de Uso de Aplicación . . . . . . . . . . . . . . . . . . . . . 44

4.4.1. Modelo Punto de Vista de Uso de Aplicación . . . . . . . . . . . . 44

5. MODELAMIENTO DE LA INFRAESTRUCTURA 475.1. Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . 47

5.1.1. Modelo Punto de Vista de Infraestructura . . . . . . . . . . . . . . 485.2. Punto de Vista de Uso de Infraestructura . . . . . . . . . . . . . . . . . . 49

5.2.1. Modelo Punto de Vista de Uso de Infraestructura . . . . . . . . . . 495.3. Punto de Vista de Implementación y Despliegue . . . . . . . . . . . . . . . 50

5.3.1. Modelo Punto de Vista de Implementación y Despliegue . . . . . . 505.4. Punto de Vista de Estructura de la Información . . . . . . . . . . . . . . . 51

5.4.1. Modelo Punto de Vista de Estructura de la Información . . . . . . 515.5. Punto de Vista de Realización de servicios . . . . . . . . . . . . . . . . . . 52

5.5.1. Modelo Punto de Vista de Realización de Servicios . . . . . . . . . 535.6. Punto de Vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6.1. Modelo Punto de Vista de Capas . . . . . . . . . . . . . . . . . . . 54

6. MODELO MOTIVACIONAL 556.1. Punto de Vista de Implicados . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1.1. Modelo Punto de Vista de Implicados . . . . . . . . . . . . . . . . 566.2. Punto de Vista de Realización de Objetivos . . . . . . . . . . . . . . . . . 57

6.2.1. Modelo Punto de Vista de Realización de Objetivos . . . . . . . . 58

4

Índice general

6.3. Punto de Vista de Contribución de Objetivos . . . . . . . . . . . . . . . . 596.3.1. Modelo Punto de Vista de Contribución de Objetivos . . . . . . . . 60

6.4. Punto de Vista de Principios . . . . . . . . . . . . . . . . . . . . . . . . . 616.4.1. Modelo Punto de Vista de Principios . . . . . . . . . . . . . . . . . 61

6.5. Punto de Vista de Realización de Requisitos . . . . . . . . . . . . . . . . . 626.5.1. Modelo Punto de Vista de Realización de Requisitos . . . . . . . . 63

6.6. Punto de Vista de Motivación . . . . . . . . . . . . . . . . . . . . . . . . . 646.6.1. Modelo Punto de Vista de Motivación . . . . . . . . . . . . . . . . 64

7. IMPLEMENTACIÓN Y MIGRACIÓN 667.1. Punto de Vista de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.1.1. Modelo Punto de Vista de Proyecto . . . . . . . . . . . . . . . . . 677.2. Punto de Vista de Migración . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.2.1. Modelo Punto de Vista de Migración . . . . . . . . . . . . . . . . . 687.3. Punto de Vista de Implementación y Migración . . . . . . . . . . . . . . . 69

7.3.1. Modelo Punto de Vista de Implementación y Migración . . . . . . 70

8. Meta-Modelo de la Arquitectura 71

9. PATRONES DE DISEÑO 729.1. Patrones Creacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

9.1.1. Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729.1.1.1. Aplicación Patrón Singleton . . . . . . . . . . . . . . . . . 73

9.1.2. Patrón Constructor . . . . . . . . . . . . . . . . . . . . . . . . . . . 749.1.2.1. Aplicación Patrón Constructor . . . . . . . . . . . . . . . 74

9.1.3. Patrón Método Fábrica . . . . . . . . . . . . . . . . . . . . . . . . 759.1.3.1. Aplicación Patrón Método Fábrica . . . . . . . . . . . . . 75

9.1.4. Patrón Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769.1.4.1. Aplicación Patrón Prototipo . . . . . . . . . . . . . . . . 76

9.2. Patrones Estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.2.1. Patrón Puente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9.2.1.1. Aplicación Patrón Puente . . . . . . . . . . . . . . . . . . 779.2.2. Patrón Componente . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.2.2.1. Aplicación Patrón Componente . . . . . . . . . . . . . . . 799.2.3. Patrón Decorador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

9.2.3.1. Aplicación Patrón Decorador . . . . . . . . . . . . . . . . 809.2.4. Patrón Fachada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

9.2.4.1. Aplicación Patrón Fachada . . . . . . . . . . . . . . . . . 819.2.5. Patrón Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9.2.5.1. Aplicación Patrón Proxy . . . . . . . . . . . . . . . . . . 829.3. Patrones de Comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . 83

9.3.1. Cadena de responsabilidades . . . . . . . . . . . . . . . . . . . . . 839.3.1.1. Aplicación Patrón Cadena de Responsabilidad . . . . . . 83

5

Índice general

9.3.2. Patrón Comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849.3.2.1. Aplicación Patrón Comando . . . . . . . . . . . . . . . . 84

9.3.3. Patrón Iterador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859.3.3.1. Aplicación Patrón Iterador . . . . . . . . . . . . . . . . . 85

9.3.4. Patrón Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869.3.4.1. Aplicación Patrón Estado . . . . . . . . . . . . . . . . . . 86

9.3.5. Patrón Mediador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.3.5.1. Aplicación Patrón Mediador . . . . . . . . . . . . . . . . 88

9.3.6. Patrón Observador . . . . . . . . . . . . . . . . . . . . . . . . . . . 889.3.6.1. Aplicación Patrón Observador . . . . . . . . . . . . . . . 89

9.3.7. Patrón Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899.3.7.1. Aplicación Patrón Estrategia . . . . . . . . . . . . . . . . 90

10.Descripción del Prototipo 9110.1. Módulo Orden de Compra . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.2. Módulo de Negociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.3. Módulo de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.4. Módulo de Nacionalización . . . . . . . . . . . . . . . . . . . . . . . . . . . 9510.5. Módulo de Tablero de Seguimiento . . . . . . . . . . . . . . . . . . . . . . 96

III. CIERRE 97

11.Conclusiones 98

12.Trabajo Futuro 100

13.Aportaciones 101

IV. ANEXOS 104

A. Anexos Meta-modelos de las Vistas de Archimate 105A.1. Meta-modelo Punto de Vista de Organización . . . . . . . . . . . . . . . . 105A.2. Meta-modelo Punto de Vista de Colaboración de Actores . . . . . . . . . . 106A.3. Meta-modelo Punto de Vista de Funciones de Negocio . . . . . . . . . . . 106A.4. Meta-modelo Punto de Vista de Proceso de Negocio . . . . . . . . . . . . 107A.5. Meta-modelo Punto de Vista de Cooperación de Procesos de Negocio . . . 108A.6. Meta-modelo Punto de Vista del Producto . . . . . . . . . . . . . . . . . . 108A.7. Meta-modelo Punto de Vista de Comportamiento de Aplicación . . . . . . 109A.8. Meta-modelo Punto de Vista de Colaboración de Aplicación . . . . . . . . 109A.9. Meta-modelo Punto de Vista de Estructura de Aplicación . . . . . . . . . 110A.10.Meta-modelo Punto de Vista de Uso de Aplicación . . . . . . . . . . . . . 110A.11.Meta-modelo Punto de Vista de Infraestructura . . . . . . . . . . . . . . . 111A.12.Meta-modelo Punto de Vista de Uso de Infraestructura . . . . . . . . . . . 111

6

Índice general

A.13.Meta-modelo Punto de Vista de Implementación y Despliegue . . . . . . . 112A.14.Meta-modelo Punto de Vista de Estructura de la Información . . . . . . . 113A.15.Meta-modelo Punto de Vista de Realización de Servicios . . . . . . . . . . 113A.16.Meta-modelo Punto de Vista de Capas . . . . . . . . . . . . . . . . . . . . 114A.17.Meta-modelo Punto de Vista de Implicados . . . . . . . . . . . . . . . . . 114A.18.Meta-modelo Punto de Vista de Realización de Objetivos . . . . . . . . . 115A.19.Meta-modelo Punto de Vista de Contribución de Objetivos . . . . . . . . 115A.20.Meta-modelo Punto de Vista de Principios . . . . . . . . . . . . . . . . . . 116A.21.Meta-modelo Punto de Vista de Realización de Requisitos . . . . . . . . . 116A.22.Meta-modelo Punto de Vista de Motivación . . . . . . . . . . . . . . . . . 117A.23.Meta-modelo Punto de Vista de Proyecto . . . . . . . . . . . . . . . . . . 117A.24.Meta-modelo Punto de Vista de Migración . . . . . . . . . . . . . . . . . . 117A.25.Meta-modelo Punto de Vista de Implementación y Migración . . . . . . . 118

B. Anexo Patrones de Diseño 119B.1. Estructura Patrón Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . 119B.2. Estructura Patrón Constructor . . . . . . . . . . . . . . . . . . . . . . . . 119B.3. Estructura Patrón Método Fábrica . . . . . . . . . . . . . . . . . . . . . . 120B.4. Estructura Patrón Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . 120B.5. Estructura Patrón Puente . . . . . . . . . . . . . . . . . . . . . . . . . . . 121B.6. Estructura Patrón Componente . . . . . . . . . . . . . . . . . . . . . . . . 121B.7. Estructura Patrón Decorador . . . . . . . . . . . . . . . . . . . . . . . . . 122B.8. Estructura Patrón Fachada . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.9. Estructura Patrón Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123B.10.Estructura Patrón Cadena de Responsabilidad . . . . . . . . . . . . . . . . 123B.11.Estructura Patrón Comando . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.12.Estructura Patrón Iterador . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.13.Estructura Patrón Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . 125B.14.Estructura Patrón Mediador . . . . . . . . . . . . . . . . . . . . . . . . . . 125B.15.Estructura Patrón Observador . . . . . . . . . . . . . . . . . . . . . . . . . 126B.16.Estructura Patrón Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . 126

C. Anexo Entrevista a Expertos 127

D. Anexo: Código Fuente del Prototipo 130

E. Anexo: Código Fuente Patrones de Diseño 131

7

Índice de �guras

1.1. Componentes Usados en el Proceso de Importación. Fuente Propia . . . . 131.2. Marco de trabajo ArchiMate. [7] . . . . . . . . . . . . . . . . . . . . . . . 171.3. Esquema Metodología OpenUp. [5] . . . . . . . . . . . . . . . . . . . . . . 181.4. Esquema JEE Aplicación Web. [14] . . . . . . . . . . . . . . . . . . . . . . 191.5. Respuesta a un cliente usando una página JavaServer Faces. [15] . . . . . 201.6. Incoterm FOB. [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.7. Cronograma de trabajo alto nivel. Fuente Propia . . . . . . . . . . . . . . 24

3.1. Modelo punto de vista de organización. Fuente: Propia . . . . . . . . . . . 293.2. Modelo de punto de vista de colaboración de Actores. Fuente: Propia . . . 313.3. Modelo de Punto de Vista de Funciones de Negocio. Fuente: Propia . . . . 333.4. Modelo Punto de Vista de Proceso de Negocio. Fuente: Propia . . . . . . . 353.5. Modelo de Punto de Vista de Cooperación de Procesos de Negocio. Fuente:

Propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.6. Modelo de Punto de Vista del Producto. Fuente: Propia . . . . . . . . . . 38

4.1. Modelo de Punto de Vista de Comportamiento de Aplicación. Fuente: Propia 404.2. Modelo de Punto de Vista de Colaboración de Aplicación. Fuente: Propia 414.3. Modelo de Punto de Vista de Estructura de Aplicación. Fuente: Propia . . 434.4. Modelo de Punto de Vista de Uso de Aplicación. a). Fuente: Propia . . . . 444.5. Modelo de Punto de Vista de Uso de Aplicación. b). Fuente: Propia . . . . 454.6. Modelo de Punto de Vista de Uso de Aplicación. c). Fuente: Propia . . . . 454.7. Modelo de Punto de Vista de Uso de Aplicación. d). Fuente: Propia . . . . 45

5.1. Modelo de Punto de Vista de Infraestructura. Fuente: Propia . . . . . . . 485.2. Modelo de Punto de Vista de Uso de Infraestructura. Fuente: Propia . . . 495.3. Modelo de Punto de Vista de Implementación y Despliegue. Fuente: Propia 505.4. Modelo de Punto de Vista de Estructura de la Información. Fuente: Propia 515.5. Modelo de Punto de Vista de Realización de servicios. Fuente: Propia . . . 535.6. Modelo de Punto de Vista de Capas. Fuente: Propia . . . . . . . . . . . . 54

6.1. Modelo de Punto de Vista de Implicados. Fuente: Propia . . . . . . . . . . 566.2. Modelo de Punto de Vista de Realización de Objetivos. Fuente: Propia . . 586.3. Modelo de Punto de Vista de Contribución de Objetivos. Fuente: Propia . 606.4. Modelo de Punto de Vista de Principios. Fuente: Propia . . . . . . . . . . 616.5. Modelo de Punto de Vista de Realización de Requisitos. Fuente: Propia . 636.6. Modelo de Punto de Vista de Motivación. Fuente: Propia . . . . . . . . . . 64

8

Índice de �guras

7.1. Modelo de Punto de Vista de Proyecto. Fuente: Propia . . . . . . . . . . . 677.2. Modelo de Punto de Vista de Migración. Fuente: Propia . . . . . . . . . . 687.3. Modelo de Punto de Vista de Implementación y Migración. Fuente: Propia 70

8.1. Meta-modelo de la Arquitectura. Fuente Propia . . . . . . . . . . . . . . . 71

9.1. Aplicación del Patrón Singleton. Fuente Propia . . . . . . . . . . . . . . . 739.2. Aplicación Patrón Constructor. Fuente Propia . . . . . . . . . . . . . . . . 749.3. Aplicación Patrón Método Fábrica. Fuente Propia . . . . . . . . . . . . . 759.4. Aplicación Patrón Prototipo. Fuente Propia . . . . . . . . . . . . . . . . . 769.5. Aplicación Patrón Puente. Fuente Propia . . . . . . . . . . . . . . . . . . . 779.6. Aplicación Patrón Componente. Fuente Propia . . . . . . . . . . . . . . . 799.7. Aplicación Patrón Decorador. Fuente Propia . . . . . . . . . . . . . . . . . 809.8. Aplicación Patrón Fachada. Fuente Propia . . . . . . . . . . . . . . . . . . 819.9. Aplicación Patrón Proxy. Fuente Propia . . . . . . . . . . . . . . . . . . . 829.10. Aplicación Patrón Cadena de Responsabilidad. Fuente Propia . . . . . . . 839.11. Aplicación Patrón Comando. Fuente Propia . . . . . . . . . . . . . . . . . 849.12. Aplicación Patrón Iterador. Fuente Propia . . . . . . . . . . . . . . . . . . 859.13. Aplicación Patrón Estado. Fuente Propia . . . . . . . . . . . . . . . . . . . 879.14. Aplicación Patrón Mediador. Fuente Propia . . . . . . . . . . . . . . . . . 889.15. Aplicación Patrón Observador. Fuente Propia . . . . . . . . . . . . . . . . 899.16. Aplicación Patrón Estrategia. Fuente Propia . . . . . . . . . . . . . . . . . 90

10.1. Prototipo SAPI. Fuente Propia . . . . . . . . . . . . . . . . . . . . . . . . 9110.2. Modulo Orden de Compra. Fuente Propia . . . . . . . . . . . . . . . . . . 9210.3. Módulo de Negociación. Fuente Propia . . . . . . . . . . . . . . . . . . . . 9310.4. Módulo de Transporte. Fuente Propia . . . . . . . . . . . . . . . . . . . . 9410.5. Módulo de Nacionalización. Fuente Propia . . . . . . . . . . . . . . . . . . 9510.6. Módulo de Tablero de Seguimiento. Fuente Propia . . . . . . . . . . . . . 96

9

INTRODUCCIÓN

Las empresas importadoras de productos y servicios mediante el Incoterm FOB1, formanparte crucial en el crecimiento de la economía de la nación y por tanto es necesarioque su nivel de calidad y e�ciencia durante el proceso de importación sea aumentadoexponencialmente conforme es requerido por la creciente demanda de clientes y aún másimportante, con el evidente aumento en los acuerdos de libre comercio que se estángenerando entre el país con otras naciones.

Pero la calidad y e�ciencia se ve opacada, por que durante el proceso de importaciónlos datos están dispersos en diferentes sistemas de software y en formatos en papel, quedi�cultan una búsqueda e�ciente de información. Los documentos físicos como factu-ras, recibidos, bitácoras, listados de inventario entre otros; son el resultado de procesostransaccionales que se realizan durante el ejercicio de la importación y son almacenadosen archivadores, encapsulado la información e impidiendo realizar de forma ágil reportesactuales o históricos en temas de proveedores, gastos, inventario, etc. El uso excesivo delas herramientas tecnológicas actuales, como el correo electrónico y las hojas de cálculono son un sistema integrado que permita llevar de forma correcta y e�ciente el sopor-te verdadero de los procesos de importaciones de productos e insumos de las empresascolombianas.

Con la implementación de un sistema de (software) que permita gestionar, administrarde forma con�able, ágil y oportuna todos los procesos implicados durante el ejercicio decompras de productos del exterior; se reducirá la aplicación de malas prácticas que lasempresas están usando y se mejorará la calidad y e�ciencia de los procesos de importación,bene�ciando de forma directa las compañías que lo implementen y de forma indirectatodos los involucrados en la actividad.

Por lo descrito con anterioridad, el presente documento describe la investigación realizadasobre el proceso de importación de mercancías a Colombia mediante el Incoterm FOBy el desarrollo de un prototipo de software web, que registra, controla y administrala información generada por el mismo; Durante el desarrollo de la investigación y elprototipo web, se hace uso del método de desarrollo ágil iterativo incremental, que estásustentado en una muy completa metodología, en base a las de�niciones de actividadesy entregables que se deben llevar durante todo el proceso.

Finalmente el documento de investigación está comprendido por tres grandes partes, endonde la primera comprende el Contexto de la Investigación, que realiza una síntesis delanteproyecto planteado para la investigación y donde se presenta el problema propuesto,

1Incoterm: Free On Board

10

Índice de �guras

junto a la hipótesis planteada y el objetivo general y especí�cos para el resultado dela investigación; adicionalmente cuenta con sencillo marco teórico y conceptual parapresentar al lector los conceptos tratados dentro del documento.

El desarrollo de la Investigación es la segunda parte donde se realiza la síntesis del modelode negocio y la presentación del resultado de la investigación mediante el planteamientodel modelo arquitectónico del dominio del proceso de importación con una descripción ydetalle de gran profundidad con el uso de los diferentes puntos de vista que presentan lascapas de negocio, aplicación, infraestructura, motivación y migración e implementación.También presenta el diseño de patrones de desarrollo de software, de�nidos y estructura-dos a partir de las de�niciones en la arquitectura; esto con el propósito de implementarbuenas prácticas en el desarrollo del prototipo de software web.

La tercera y última parte se comprende como el Cierre, y es es donde se describen lasconclusiones de la investigación, donde se desenlaza el resultado de la hipótesis propuesta,el cumplimiento del objetivo general y especí�cos junto a las anotaciones de los trabajosfuturos, las aportaciones y todos los anexos que soporten el contenido del proyecto.

11

Parte I.

CONTEXTO DE LA

INVESTIGACIÓN

12

1. DESCRIPCIÓN DE LAINVESTIGACIÓN

1.1. Planteamiento del Problema

El uso inadecuado de las herramientas tecnológicas actuales, como el correo electrónicoy las hojas de cálculo no son el soporte verdadero de los procesos [2] de importaciones deproductos e insumos de las empresas Colombianas. Por esta razón, la información histó-rica resulta difícil de recuperar y analizar, dado que los datos se encuentran distribuidospor diferentes medios de comunicación, incluso mucha no se encuentra en medios digita-les, en este último escenario es muy complicado realizar búsquedas y generar reportes dela información histórica[2].

Figura 1.1.: Componentes Usados en el Proceso de Importación. Fuente Propia

�Algunas instituciones de micro �nanzas utilizan sistemas manuales y hojasde cálculo (así como Excel o Lotus) para realizar el seguimiento de las cuen-tas de sus clientes y para preparar los reportes de cartera. Estas herramientaspueden ser elaboradas, modi�cadas y mantenidas con mayor facilidad que lasbases de datos, pero su utilidad es mucho más limitada, particularmente enaquellas instituciones donde se manejan más de 500 préstamos activos. Asi-mismo, los sistemas manuales y las hojas de cálculo pueden colapsar cuandola estructura de la institución se vuelve más compleja. También es difícil con-solidar la información manual o en hojas de cálculo que proviene de diferentessucursales�[2].

13

1. DESCRIPCIÓN DE LA INVESTIGACIÓN

Muchas empresas de manufactura en Colombia que realiza importaciones no realiza unadigitalización de la información, si bien es importante llevar los documentos originales enfísico, las copias digitales representan un gran apoyo al momento de consultar informaciónhistórica y hacer seguimiento al proceso de importación. En este momento es complicadoaplicar métricas, hacer seguimientos sobre las labores propias de las importaciones, yaque al tener la información distribuida en correos electrónicos y hojas de cálculo o inclusoal no tenerlas digitalizadas, no se puede medir los tiempos de nacionalización, transporte,estudio de proveedores, e�ciencia de las navieras, costos, entre otras.

La Ausencia de un sistema de información que permita automatizar los datos transac-cionales en el proceso de importaciones resulta en costos de re-procesos e incertidumbreen algunas tareas complementarias a las importaciones. Actualmente el cálculo de loscostos de las importaciones es dispendioso y toma bastante tiempo realizarlo, ya que esun proceso manual de recolección y análisis de información. Por otra parte, estos pro-cesos manuales y dispendiosos contienen una incertidumbre del ejecutor de tal acción.Adicionalmente otro proceso importante que se ejecuta de manera manual es el de rea-lizar simulaciones sobre los costos que conlleva realizar la importación por diferentesproveedores, este es complicado y costoso en tiempo.

Existe actualmente una carencia de software [6, 10, 21] para las empresas Colombianasque realizan importaciones, que estén ajustados a la realidad y al mercado colombiano.Los sistemas de información actuales no están hechos para las empresas que importanmateria prima, sino para las agencias de aduanas, por tal razón las empresas del sectorse ven obligadas a llevar su información en papel, correo electrónico y hojas de cálculo.

Adicionalmente, las aplicaciones software que se han investigado y mencionado [6, 10, 21]que administran importaciones están orientadas al ejercicio local en las empresas dejandofuera la posibilidad que todos los entes externos que intervienen en el ejercicio puedaninteractuar directamente con las empresas a través de sus aplicaciones.

En el afán por un mundo globalizado, suprimiendo las barreras comerciales entre lospaíses, es probable que los tratados de libre comercio que hace el gobierno colombianocon otros países aumente y esto permite a empresas colombianas realizar cada vez másimportaciones hacia Colombia de productos e insumos, lo cual implica directamente unaumento en la cantidad de transacciones comerciales realizadas. Estos crecimientos enlas operaciones de las empresas si no se hacen con el respectivo control y seguimiento deprocesos puede llevar a desórdenes, pérdidas de información, demoras en los procesos, locual se traduce en pérdidas de dinero y tiempo para las empresas.

Teniendo en cuenta lo mencionado, con el aumento de las transacciones comerciales, sepodría evidenciar que las herramientas tecnológicas como correo electrónico y hojas decálculo, para procesos complejos y de alta transaccionalidad no resultan ser e�cientespara el manejo de la información histórica y seguimiento de un proceso de�nido.

Así mismo, cuando se trabaja con grandes volúmenes de información, producto de muchastransacciones comerciales, es complicado realizar seguimiento, gestión y control; sin estastareas bien ejecutadas por parte de una empresa, se pierde la capacidad de toma dedecisiones y predicción.

14


El hecho de tener cada vez más tratados comerciales con otros países, no es una variableque se pueda controlar, pero se puede afrontar de una manera que pueda llegar a seruna oportunidad de crecimiento para las empresas colombianas, claro está, si se lleva acabo con procesos bien establecidos y herramientas tecnológicas que permitan realizar lagestión, análisis y revisión de los procesos que involucran las transacciones comercialesentre empresas de diferentes países.

1.2. Objetivos

1.2.1. Objetivo General

Elaborar una propuesta de automatización del proceso de importación a Colombia, me-diante el desarrollo de un prototipo de software web para agilizar y hacer más efectivaslas actividades en el departamento de compras de la empresa Químicos Manios S.A.

1.2.2. Objetivos Especí�cos

1. Realizar el levantamiento de información sobre el funcionamiento del ejercicio ac-tual de importar mercancías a Colombia, a través de entrevistas a profesionales yconsulta de documentos del área de interés, para la identi�cación de los procesos asistematizar.

2. Analizar la información recolectada, clasi�cando e interpretando tareas, diagnosti-cando problemas, sintetizando procedimientos y proponiendo mejoras para la de�-nición de los requerimientos del software.

3. Desarrollar un prototipo de software web, con el método iterativo incremental enbase a los requerimientos de�nidos para sistematizar el proceso de importación.

1.3. Hipótesis

Implementar un software de administración de importaciones, adaptado a la realidaddel mercado colombiano, permite a las empresas que realizan compras de productos einsumos al exterior; controlar, gestionar, realizar seguimiento y llevar la trazabilidad delas transacciones comerciales internacionales.

1.4. Marco Teórico

1.4.1. Togaf

Es un marco de trabajo, un método detallado y un set de herramientas de apoyo- pa-ra desarrollar una arquitectura empresarial. Puede ser usado libremente por cualquier

15


organización que desee desarrollar una arquitectura empresarial para usar dentro de laorganización [9].

Togaf es desarrollado y mantenido por miembros de �the Open Group�[8]. El desarrollooriginal de la versión 1 de Togaf en 1995 fue basado en el TAFIM (Technical ArchitectureFramework for Information Management). desarrollado por el departamento de defensade los Estado Unidos (DoD).

Togaf de�ne una �empresa� como cualquier colección de organizaciones que tienen unaserie de objetivos en común, por ejemplo, una empresa puede ser una agencia de gobierno,una corporación completa, una división de una corporación, un solo departamento o unacadena de organizaciones unidas por el mismo dueño[9].

Cabe notar que Togaf puede ser aplicado a todo tipo de arquitecturas, incluyendo ar-quitecturas basadas en sistemas de planeación de recursos empresariales. Un ejemplo deesto es SAP1, quien provee su propio marco de trabajo EAF como una adaptación deTogaf [17].

El amplio tamaño del documento de referencia de togaf no debe eclipsar la orientación deproyecto, el cual se centra en el enfoque de transformación de la arquitectura empresarial.Este enfoque, descrito por el ADM2, constituye el corazón del documento de referencia.

1.4.2. Arquitectura Empresarial

No está limitada a sistemas de información únicamente. El objetivo sigue siendo la im-plementación de sistemas de software operacionales, pero para lograr este objetivo, senecesita de una amplia vista, estrategia, negocio y aspectos organizacionales. además,el alineamiento de �negocio� y �tecnología� es de mayor interés para los administradoresde negocio y los jefes de información de o�cina (CIO3), quienes están constantementebuscando agilidad en sistemas de información.Por consiguiente, arquitectura cubre requi-sitos y estrategias así como procesos de negocio y aplicaciones técnicas e infraestructuras,esforzándose por la óptima articulación entre estas diferentes facetas[17].

Cualquier transformación necesita colaboración entre gobierno, interesados y equipo de-dicado a arquitectura. Esta colaboración es basada en un proceso organizado, este esel rol del ADM el cual provee una estructura para el progreso de proyectos de trans-formación empresarial. El lenguaje de modelado de arquitectura empresarial ArchiMa-te ha sido desarrollado para proveer una representación uniforme para diagramas quedescriben arquitecturas empresariales. ArchiMate ofrece un enfoque arquitectural inte-grado que describe y visualiza los diferentes dominios de arquitectura y sus relaciones ydependencias[17].

1SAP SE es una empresa multinacional alemana dedicada al diseño de productos informáticos2Architecture Development Method3Chief Information O�ce

16


1.4.3. ArchiMate

El rol del estándar ArchiMate es proveer un lenguaje grá�co para la representación dearquitecturas empresariales a través del tiempo así como sus motivaciones y razones [7].

El lenguaje consiste en tres tipos principales de elementos, elementos activos de estruc-tura, elementos de comportamiento y elementos de estructura pasiva (objetos). Un ele-mento de estructura activa es de�nido como una entidad que es capaz de efectuar uncomportamiento. Un elemento de comportamiento es de�nido como una unidad de acti-vidad realizada por uno o mas elementos de estructura activa. Un elemento de estructurapasiva es de�nido como un objeto sobre el cual el comportamiento es realizado.

1.4.4. Capas del Lenguaje Archimate

ArchiMate de�ne tres principales capas, basado en especializaciones de los conceptosprincipales descritos. Estas capas son diferenciadas por colores. La capa de Negocio ofre-ce productos y servicios a clientes externos, los cuales son realizado en la organización porprocesos de negocio, ejecutados por actores de negocio. La capa de aplicación soporte lacapa de negocio con los servicios de aplicación los cuales son realizados por aplicacionesde software. La capa de tecnología ofrece servicios de infraestructura que se necesitanpara ejecutar aplicaciones, como procesamiento, almacenamiento y servicios de comuni-cación. Estos son realizados por computadores, hardware de comunicación y sistemas desoftware.[7]

Figura 1.2.: Marco de trabajo ArchiMate. [7]

1.4.5. OpenUp

OpenUp es un proceso uni�cado que aplica enfoques iterativos e incrementales dentrode un ciclo de vida estructurado. OpenUp aplica una �losofía pragmática ágil que secentra en la naturaleza colaborativa del desarrollo de software [5]. El esfuerzo personal

17


en proyectos de Open UP es organizado en micro-incrementos, los cuales representancortas unidades de trabajo que aportan al progreso de un proyecto.

Figura 1.3.: Esquema Metodología OpenUp. [5]

OpenUP divide el proyecto en iteraciones planeadas, generalmente por semanas, enfo-cando cada iteración a una entrega cada vez con más valor para los interesados de unamanera predecible.

Está basado en cuatro principios que se apoyan mutuamente:

Equilibrar prioridades competitivas para maximizar el valor para los interesados:Promover prácticas que permite a los participantes del proyecto e interesados paradesarrollar una solución que maximiza los bene�cios para los interesados y cumplecon las restricciones impuestas en el proyecto.

Colaborar para alinear intereses y compartir entendimientos: Promover prácticasque fomenten un ambiente de equipo saludable, permite la colaboración y desarro-llar un entendimiento compartido del proyecto.

Enfocarse en la arquitectura prematura para minimizar riesgo y organizar el desa-rrollo: Promover prácticas que permita al equipo enfocarse en la arquitectura paraminimizar riesgo y organizar el desarrollo.

Evolucionar para continuamente obtiene retroalimentación y mejoramiento: Pro-mover prácticas que permitan al equipo obtener temprana y continua retroalimen-tación por parte de los interesados y demostrar valor incrementado para ellos.

1.4.6. Java

En amplio mundo de los lenguajes de programación, Java es toda una tecnología dedesarrollo de programas de software de escritorio, móvil y web. Toda la plataforma estásoportada por un ambiente de ejecución o Java Runtime Environment (JRE) formada

18


por la maquina virtual java (JVM), constituida por un gran número de bibliotecas declases que forman todo el core de soporte que permite la �uida, rápida y segura ejecuciónde las aplicaciones. Con más de 9 millones de desarrolladores Java en todo el mundo [12],esta tecnología es una de las más usadas y distribuidas en la mayoría de computadoras ydispositivos móviles en mundo; esto es en gran medida a que el licenciamiento [16] de latecnología es de código abierto y en la actualidad es propiedad de la compañía ORACLE,quien brinda un completo soporte.

1.4.7. Java Enterprise Edition

Java EE es una plataforma empresarial de programación que se usa para desarrollary ejecutar software de aplicaciones en lenguaje de programación Java con arquitecturade n niveles distribuida, basándose ampliamente en componentes de software modularesejecutándose sobre un servidor de aplicaciones. Algunos de los componentes se puedendesplegar los desarrollos se mencionan a continuación [14].

Figura 1.4.: Esquema JEE Aplicación Web. [14]

Componentes[14]:

Clientes de aplicación y applets (en el cliente)

Java Servlet, JavaServer Faces (JSF), y JavaServer Pages (JSP) (en el servidor)

Enterprise JavaBeans (EJB) (o enterprise beans) (en el servidor)

Contenedor de applets en un navegador Web

Contenedor Web Tomcat

Contenedor de EJBs

1.4.8. Java Server Faces

Dentro del amplio campo de tecnologías de Sun Microsystems, JavaServer Faces (JSF) esun framework o marco de trabajo liberado en marzo del 2004, que establece el estándarpara el desarrollo simple de interfaces de usuario en aplicaciones Java EE basadas en web[15].

19


Diseñado para ser �exible, la tecnología orientada a controles JSF se basa en patrón dedesarrollo MVC4 que permite desacoplar la interfaz de usuario de los diferentes procesosdel negocio, utilizando Java Server Pages (JSP) para realizar los despliegues de las pági-nas. Su �exibilidad permite no solo trabajar con páginas JSP, también trabaja con otrastecnologías como XUL (acrónimo de XML-based User-interface Language, lenguaje basa-do en XML para la interfaz de usuario) y sobre páginas XHTML ( extensible HyperTextMarkup Language).

Figura 1.5.: Respuesta a un cliente usando una página JavaServer Faces. [15]

Dentro de las características de JSF, se destaca la gestión de su ciclo de vida a travésdel servidor construyendo los distintos tipos de controles que se necesitan usar, juntocon la asociación directa de cada una de las etiquetas a los datos de la aplicación en lasespeci�caciones del negocio en los Java Beans [15].

La tecnología Java Server Faces incluye:

Un conjunto de APIs para representar componentes de interfaz de usuario.

Gestión de estados, el manejo de eventos y validación de entradas de los compo-nentes.

De�nición de las reglas de navegación entre páginas.

Una librería de etiquetas JSP personalizadas para dibujar componentes de interfazde usuario dentro de las páginas JSP.

1.4.9. Enterprise Java Bean

Los EJBs (o beans empresariales) son componentes Java EE que implementan la tecno-logía Enterprise JavaBeans (EJB). Un EJB se ejecuta en un contenedor de EJB que esun entorno de ejecución dentro un servidor de aplicaciones. Aunque transparente para laaplicación, el contenedor de EJB provee una serie de servicios a nivel de sistema entrelos que se incluyen las transacciones y la seguridad de los EJBs. Escritos en lenguajede programación Java, un EJB es un componente de servidor que encapsula la lógica denegocio de una aplicación [13].

4Model View Controller

20


El contenedor de EJB se encarga de la seguridad y el manejo de transacciones, dejando albean solo la lógica de negocio Como la lógica de negocio está en los beans, el desarrolladorpuede ocuparse de desarrollar la capa de presentación sin tener que codi�car lógica denegocio o acceso a bases de datos. Como resultado se producen clientes muy ligeros,especialmente deseables para ejecutarse en pequeños dispositivos como los smartphones[13].

1.4.10. PostgreSQL

PostgreSQL es un potente sistema de base de datos, de código abierto objeto-relacional.Cuenta con más de 15 años de desarrollo activo y una arquitectura probada que se haganado una sólida reputación por su �abilidad, integridad de datos y corrección. Se eje-cuta en todos los sistemas operativos, incluyendo Linux, UNIX (AIX, BSD, HP-UX, SGIIRIX, Mac OS X, Solaris, Tru64), y Windows. Es totalmente compatible con ACID,tiene soporte completo para claves foráneas, combinaciones, vistas, triggers y procedi-mientos almacenados (en varios idiomas). Incluye tipos de datos, INTEGER, numéricos,booleanos, CHAR, VARCHAR, DATE, INTERVAL y TIMESTAMP. También es com-patible con el almacenamiento de grandes objetos binarios, incluyendo imágenes, sonidoso vídeos. Cuenta con interfaces de programación nativo de C / C ++, Java, .Net, Perl,Python, Ruby, Tcl, ODBC, entre otros, y la documentación excepcional [18].

1.5. Marco Conceptual

1.5.1. Comercio Exterior

Se de�ne como comercio internacional, al intercambio de bienes, productos y serviciosentre dos o más países o regiones económicas al exportar (vender), e importar (comprar).Las economías que participan del comercio exterior se denominan economías abiertas.La comercialización entre los países se logra promoviendo acuerdos de las empresas decada país. Los países deben impulsar las relaciones comerciales e implementar proyectosenmarcados en el crecimiento y desarrollo continuo de la comunidad [11].

1.5.2. Importación

Según la DIAN, el termino importación se de�ne como.

La introducción de mercancías de procedencia extranjera, o de zona francacolombiana industrial, al resto del territorio nacional, previo el cumplimientode los requisitos legales establecidos y del pago de los tributos aduaneros a quehaya lugar. También se considera importación la introducción de mercancíasprocedentes de Zona Franca Industrial de Bienes y de Servicios, al resto delterritorio aduanero nacional en los términos previstos en Decreto 2685 de1999 [4].

21


1.5.3. Incoterm

De las siglas en ingles (International Commerce Terms), el incoterm determina en quemomento y donde se produce la transferencia de riesgos sobre la mercancía del vendedoral comprador. También determina el lugar de entrega de la mercancía, quien contrata ypaga los servicios y que documentos tramita cada parte y su costo.

Existen 2 grupos de incoterms, el primer grupo aplica para cualquier modo de transporte,dentro de los cuales están: EXW, FCA, CPT, CIP, DAT, DAP, DDP. El segundo grupoes solo para el transporte marítimo y vías navegables interiores, los cuales son FAS, FOB,CFR, CIF[19].

1.5.3.1. Incoterm FOB

Las obligaciones del vendedor incluyen entregar la mercancía a bordo del buque elegidopor el comprador en el puerto de embarque convenido y efectuar el despacho de exporta-ción. Mientras que el comprador debe designar y reservar el buque, correr con los gastos yriesgos inherentes a la mercancía desde que traspasa la borda del buque, ademas obtenerlas licencias para la importación y efectuar el despacho de importación de la mercancía[19].

Figura 1.6.: Incoterm FOB. [19]

22


1.6. Metodología

Desde la concepción de la idea sobre un proyecto de investigación que permitiera indagaren el problema que se presenta durante el seguimiento en proceso de importación de mer-cancías (insumos) en el área de compras de una empresa; el concepto de un desarrollo queaplicará el enfoque iterativo e incremental, siempre estuvo en la mira de los integrantesdel proyecto. OpenUp es un proceso uni�cado de desarrollo que implementa el enfoqueiterativo e incremental y que bajo una �losofía pragmática y ágil se centra en trabajocolaborativo; pero la metodología presenta una estructura de trabajo de muy alto nivel,lo que generaba complicaciones para un desarrollo de dos integrantes en un plazo de tancorto de tiempo. El equipo del proyecto no desiste en sobre el planteamiento del enfoqueiterativo e incremental, por lo cual plantea la siguiente metodología de desarrollo para elproyecto.

Iteraciones Con base en OpenUp [5], se de�ne un plan de proyecto que presenta un ciclode vida o ejecución de 4 iteraciones, representando los 4 meses de duración del proyectoen una iteración cada uno.

Hitos de las iteraciones En cada una de las iteraciones, el equipo de trabajo del proyectoplantea realizar incrementos diarios sobre los temas generales de:

Conceptualización del negocio: identi�car la misión, visión, objetivos organizacio-nales, procesos y producto de la organización; lo anterior teniendo como base elproceso de importación en el área de compras de la empresa.

Descripción de la arquitectura del negocio: mediante las capas de arquitectura deArchimate (Capa de negocio, Capa de aplicación, Capa de infraestructura, capa demotivación y la Capa de implementación y migración), lograr describir los conceptosdel negocio sobre el proceso de importación mediante cada uno de los puntos devista que las capas presentan.

Desarrollo prototipo: A medida que se adquiere conocimiento sobre el dominio delnegocio y el proceso de importación, se realizan incremento en el desarrollo delprototipo de software web.

Cierre del proyecto: Realizar apuntes sobre las conclusiones y trabajos futuro amedida que se desarrolla el proyecto.

1.6.1. Cronograma

Con una de�nición de alto nivel basado en las iteraciones y los cuatro (4) temas estruc-turales para desarrollar el proyecto, se de�ne el siguiente cronograma de trabajo:

23


Figura 1.7.: Cronograma de trabajo alto nivel. Fuente Propia

Recopilar información OpenUp propone una serie de documentos guía, con sus respectivasplantillas que permiten registrar la información recolectada durante cada una de lasiteraciones a realizar; Para la recopilación de la información o resultados del proceso deinvestigación sobre el problema planteado, el equipo de trabajo de�ne que hará uso delos diferentes diagramas de los puntos de vista planteados en las capas del modelo dearquitectura de Archimate [7].

24

Parte II.

DESARROLLO DE LA

INVESTIGACIÓN

25

2. MODELO DE NEGOCIO

En las empresas en que su objeto principal de negocio reside totalmente en la activi-dad de realizar importación de mercancías, insumos o productos desde el extranjero; laimportación es el proceso principal, y por eso la organización de�ne su misión, visión,objetivos, principios, procesos y productos en función del objeto de negocio.

Pero en las empresas cuyo objeto de negocio principal no es el proceso de importación,si no cualquier otra actividad económica que para su realización requiere en ocasiones laadquisición de productos o insumos que no son comercializados en país. El proceso deimportación se realiza en el departamento de compras de la entidad y no se re�eja en lade�nición de la misión, visión y objetivos organizacionales.

Por lo anterior, y como la entidad Químicos Manios S.A. que se utilizó como ejemplo realdurante la investigación no presenta esta estructura organizacional; se plantea la misión,visión, objetivos para el área de compras de la entidad, teniendo como objeto principalel proceso de importación. Esto con el objetivo de tener un horizonte en la investigaciónsobre el modelo de negocio en el que intervienen la importación de insumos o productosen la empresa.

2.1. Misión

Coordinar la importación de mercancías hacia Colombia haciéndolo de manera e�cienteen tiempo y costo, para que la empresa tenga los insumos a tiempo y al menor costeposible para su operación y obtener mayores márgenes de utilidad.

2.2. Visión

Que el departamento de compras e importaciones de la empresa sea un organismo con�a-ble, responsable y e�ciente, manteniendo los costos de operación al mínimo para apoyara la empresa en tener más utilidades y ser más competitiva en el mercado.

2.3. Objetivos Organizacionales

Realizar la cadena logística de importación de mercancías a Colombia para la em-presa disminuyendo los costos de operación.

26

2. MODELO DE NEGOCIO

Realizar la operación de importación de las mercancías con en el menor tiempoposible para abastecer a tiempo a la empresa los productos necesarios para suoperación.

Garantizar que los elementos importados y entregados a la empresa correspondena lo solicitado inicialmente en su totalidad.

27

3. MODELAMIENTO DEL NEGOCIO

3.1. Punto de Vista de Organización

Se enfoca en la organización interna de la compañía y departamentos, el objetivo es ilus-trar la organización jerárquica de la compañía. Es un punto de vista útil para identi�carresponsabilidades, autoridad y competencias dentro de la compañía[7].

El meta-modelo A.1 explica cómo se debe relacionar los actores, roles, interfaces. identi-�cando claramente la responsabilidad y jerarquía dentro de la compañía.

El elemento localización, representa el lugar geográ�co donde se encuentran los actores,cada actor debe estar ubicado en un lugar especí�co, esto permite identi�car las posiblesrestricciones que se pueden presentar debido a la ubicación, por ejemplo si dos actoresjuegan el mismo rol, pero en diferentes países, la diferencia horaria toma vital importanciay debe ser tenida en cuenta en las aplicaciones.

El actor puede representar una entidad, no únicamente a una persona, esto se utiliza eneste meta-modelo para identi�car la estructura organizacional.

Los actores, las empresas y las personas cuando se encuentran en un entorno juegan unoo varios roles determinados, en este meta-modelo se debe identi�car claramente cualesson los roles que desempeña cada actor del sistema, esto facilita la identi�cación de losroles principales que van a participar en el sistema.

En las compañías, cuando los actores juegan roles para ejecutar sus funciones necesitande otras entidades, áreas o personas que les permitan ejecutar a cabalidad sus funciones,este concepto se representa con una colaboración, la cual permite identi�car cuáles rolesse combinan para cumplir con una función o tarea especí�ca. Los roles se relacionan conel entorno para ejecutar las tareas que les corresponden, para representar esta relacióncon entidades externas o internas a la organización, se utiliza el concepto de interfaz, deesta manera, a través de una interfaz de negocio, se puede relacionar con otros roles.

3.1.1. Modelo Punto de Vista de Organización

Una vez identi�cados los elementos principales del punto de vista y sus relaciones basadasen el meta-modelo, se debe implementar la estructura organizacional de la empresa y suubicación geográ�ca.

28


Figura 3.1.: Modelo punto de vista de organización. Fuente: Propia

El punto de vista de organización describe que la empresa esta localizada en la ciu-dad de Bogotá distrito capital de Colombia; que su estructura contempla dos (2) áreasimportantes, el almacén y el departamento de compras.

Dentro del almacén se de�ne como actor relevante el profesional industrial, encargado deadministrar el inventario y responsable por tener el almacén con los insumos necesariospara que producción no presente contratiempos.

El Director de Compras, es el actor a cargo del Departamento de Compras y es quienaprueba las órdenes de compra de insumos generadas desde el almacén.

En el departamento de compras también se encuentra el profesional en comercio exterior,el cual se encarga de ejecutar, administrar y controlar los procesos correspondientes ala importación de los insumos. Este profesional en comercio exterior se presenta comoel actor principal, dentro de todo el proceso de la importación de insumos, es quienrecibe la orden de compra de parte del director del departamento de compras e inicialas negociaciones con el proveedor en busca de un contrato de compra que bene�cie laorganización. Al generarse el contrato de compra, es el mismo profesional en comercioquien debe gestionar en el puerto de origen o puerto de salida, los contratos de transportede la mercancía, que será recibida en puerto de destino para su posterior nacionalización,actividad que también corresponde al profesional.

29


3.2. Punto de Vista de Colaboración de Actores

El punto de vista de colaboración de actores se enfoca en la relaciones que tienen losactores con su ambiente. El trabajo a realizar es poner la organización en su ambiente,mencionando entidades externas como clientes o proveedores[7].

El meta-modelo A.2 muestra cómo se deben relacionar los actores, roles colaboraciónpara demostrar la relación de los actores con su ambiente.

En este meta-modelo A.2, al igual que en el anterior punto de vista, se encuentranlos elementos de actor, rol, colaboración e interfaz. conceptualmente tienen la mismasemántica, pero cuenta con relaciones adicionales que proporcionan otro signi�cado.

El Servicio de negocio representa el servicio que es ofrecido por parte de un rol a través deuna interfaz, este servicio está asociado a través de una interfaz de aplicación, indicandoque un objeto de negocio puede ser ofrecido desde una aplicación.

El servicio de aplicación se provee a través de una interfaz de aplicación, este serviciorepresenta el cómo se logra exponer un servicio desde la aplicación para que sea utilizadodesde otra interfaz.

El Componente de aplicación, representa a los elementos de aplicación que ejecutanalgunos procesos que se exponen a través de una interfaz de aplicación.

Es mediante el componente de colaboración de actores, que el meta-modelo permitedescribir en el negocio, como trabajan en cooperación dos o más roles asignados a losactores, para la realización de actividades necesarias en el cumplimiento de los procesosde negocio.

30


3.2.1. Modelo Punto de Vista de Colaboración de Actores

Figura 3.2.: Modelo de punto de vista de colaboración de Actores. Fuente: Propia

El punto de vista identi�can claramente tres (3) colaboraciones entre los roles principales,donde el Comprador junto al Importador y el Vendedor generan el momento en el cualse de�ne los insumos a comprar y las condiciones de la transacción comercial.

El Transporte describe todo el proceso que se realiza para lograr llevar la mercancía desdeel puerto el origen al puerto de destino, lo cual se obtiene a partir de la colaboración delImportador, el Operador de Transporte y el Transportador.

Finalmente la Nacionalización es el momento en cual se realiza el proceso de legalizaciónde los insumos en el país de destino, que para el negocio descrito es Colombia; esto selogra mediante la colaboración del Importador, el Tramitador y el Regulador.

31


3.3. Punto de Vista de Funciones de Negocio

Muestra las principales funciones de la organización y sus relaciones en término del �ujode información, valor o bienes entre ellos. Este punto de vista es usado para determinarlos aspectos más estables de una compañía en términos de actividades primarias que serealizan. También es utilizada para conocer las competencias necesarias [7].

El meta-modelo A.3 evidencia cómo se relacionan las funciones del negocio junto a unrol y los actores.

En este punto de vista, el elemento que se descubre es la función de negocio, estasfunciones representan con precisión cada una de las responsabilidades u obligaciones quese tienen dentro de la organización.

Estas funciones son realizadas por actores, pero no directamente, para poder ejecutar lasfunciones los actores juegan un rol determinado. En este punto de vista debe ser clarocuáles funciones son ejecutadas por cada rol y cada actor qué rol juega para determi-nar posibles sobrecargas de trabajo o cuellos de botella presentados debido a la maladistribución de las funciones.

En este punto de vista se adicionan dos relaciones entre funciones, la de �ujo y la dedisparo. La relación de �ujo indica que una función se ejecuta después de otra, pero queno necesariamente de manera inmediata, mientras que la relación de disparo indica quecuando una función se completa, genera automáticamente un evento para que la otrafunción inicie.

32


3.3.1. Modelo Punto de Vista de Funciones de Negocio

Figura 3.3.: Modelo de Punto de Vista de Funciones de Negocio. Fuente: Propia

Es el rol �Comprador� mediante la función de �Solicitar Insumos� dispara y crea la nece-sidad de Generar una Orden de Compra que se describe como una función que interactúacon el rol Importador, el cual es el rol más importante del ejercicio y que es interpretadopor el actor Profesional en Comercio.

Es a través de rol de Importador que se desencadena las funciones de negocio que soportanel proceso de importación, como es la negociación con el proveedor que está representadopor el vendedor y quien realiza las oferta de los insumos a comprar. Al concretarse lanegociación, se debe enviar el instructivo de carga al operador de transporte para realizarla reserva y esperar que el transportador cumpla con la labor de llevar los insumos alpuerto de destino.

Al arribo de los insumos al puerto de destino, el importador debe enviar los documentospara la nacionalización (una función de gran importancia) que dispara la función delevante la cual es realizada por el Tramitador y quien junto al ente Regulador buscanotorgar el levantamiento de la mercancía en el país de destino.

En la etapa �nal, la recolección de los insumos en puerto y la recepción por parte delComprador, son las funciones �nales que cierran el ciclo del proceso de importación parala empresa.

33


3.4. Punto de Vista de Proceso de Negocio

Es usado para mostrar la estructura de alto nivel y la composición de uno o más procesosde negocio. Este punto de vista contiene otros conceptos relacionados directamente [7]:

Los servicios que ofrece un proceso de negocio al entorno, mostrando como unproceso contribuye a la realización de los productos de la compañía.

La asignación de procesos de negocio a roles los cuales dan responsabilidades a losactores asignados.

La información usada por los procesos de negocio.

Para los servicios, eventos, procesos, objetos del negocio junto a los objetos y las repre-sentaciones, el meta-modelo A.4 describe las diferentes relaciones que se generan entrelos diferentes componentes.

El punto de vista de procesos de negocio, da más claridad sobre el cómo trabaja laorganización, que toma como insumos y como resultados, partiendo del concepto deprocesos es posible llegar a identi�car cual es el servicio que se ofrece y los objetos queson generados o requeridos.

En el modelo se debe partir del servicio que ofrece la organización, incluso si es un objetoconcreto el que se construye, este presta un servicio a los clientes, por ejemplo si es unafábrica de zapatos, el objeto es un zapato pero el servicio podría ser, brindar comodidadpara caminar.

Una vez se tiene identi�cado el servicio y el objeto a construir, se debe determinar cuáles el proceso general y abstracto que se realiza, en el caso anterior podría ser �construirzapatos�. La relación entre servicio y proceso es �realizado por� lo cual da un signi�cadotrascendental para el entendimiento de la organización. Siguiendo con el ejemplo, se leeríade la siguiente manera: �brindar comodidad para caminar es realizado por el proceso deconstruir zapatos�.

Después de tener identi�cados los servicios, procesos y objetos, se deben identi�car loseventos que generan el inicio y el �n del proceso, esto para dar límites concretos alproceso. continuando con el ejemplo anterior, se podría de�nir los eventos como iniciacon una solicitud del cliente y termina con el embalaje de los zapatos.

Es recomendado realizar una especi�cación del proceso general a procesos más concretos,los cuales se diagraman de manera secuencial con la relación de �ujo, dando así un nivelde detalle más preciso de cómo se realiza el proceso general. En el ejemplo del proceso deconstruir zapatos, los procesos especí�cos podrían ser secuencialmente así: cortar cuero,coser suela, agregar cordones, empacar en caja. Cada uno de los procesos se debe asignara un rol determinado, para tener claridad en quién debe realizar qué proceso.

34


3.4.1. Modelo Punto de Vista de Proceso de Negocio

Figura 3.4.: Modelo Punto de Vista de Proceso de Negocio. Fuente: Propia

La empresa de�ne para la compra de insumos, el servicio de �Importar insumos de ma-nera segura y e�ciente�, el cual es realizado por el proceso de Importación y atendidopor el profesional en comercio exterior quien mediante procesos más especí�cos como lanegociación con el proveedor o vendedor, el transporte de los insumos, la nacionalizacióny entrega a cliente dan cumplimiento al servicio.

El evento que da inicio al proceso de importación es tener de�nida una decisión de compra,teniendo claridad y detalle en los insumos y las cantidades que se van a comprar; esteproceso se de�ne como la Negociación con el Proveedor, en cual interviene el profesionalen comercio exterior, junto a un contacto de�nido por el proveedor.

Al concretarse una negociación de compra de insumos, por la modalidad del IncotermFOB, el proveedor debe dejar en puerto de salida la mercancía lista para que el profesionalen comercio realice la contratación con el agente de marítimo para realizar el proceso deTransporte de Insumos identi�cado en modelo de negocio de la entidad.

Durante el tiempo que toma el arribo de la mercancía de insumos al puerto de destino,el profesional en comercio exterior va organizando los documentos necesarios para sulegalización frente a la Dian en el puerto de destino en Colombia.

Finalmente el evento que termina el proceso de importación es la recepción de los insumospor parte del cliente, en este caso, es el departamento de almacén de la empresa.

35


3.5. Punto de Vista de Cooperación de Procesos de

Negocio

Es usado para mostrar las relaciones de uno o más procesos de negocio con su ambiente.También puede ser creado para relacionar los procesos con unos procesos de más altonivel y su contexto. Los aspectos importantes a considerar para este punto de vista son[7]:

Relaciones entre los procesos de negocio macro de la compañía.

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

Relación entre servicio y procesos de negocio.

Uso de datos compartidos.

En este punto de vista, descrito en el meta-modelo A.5 se debe identi�car cuáles proce-sos realizan una cooperación, se debe prestar mayor atención a las relaciones entre losprocesos, cuales son dependientes de otros o cuales colaboran para la correcta ejecuciónde los demás procesos.

A pesar que el punto de vista comparte muchos aspectos semánticos con el anterior, eltrabajo es tratar de descubrir nuevas relaciones entre los procesos, utilizando relacionesde disparo y de �ujo, entrando más en el detalle del comportamiento de la organización.

3.5.1. Modelo Punto de Vista de Cooperación de Procesos de Negocio

Figura 3.5.: Modelo de Punto de Vista de Cooperación de Procesos de Negocio. Fuente:Propia

36


En igual medida que la Importación es el proceso central en la compra de insumos enel exterior, la importación es también la interacción que se genera entre los procesosde negociación con proveedor, transporte y nacionalización de insumos y la entrega alcliente.

3.6. Punto de Vista del Producto

Describe el valor de los productos ofrecidos al cliente o otras entidades externas involu-cradas y muestra la composición de uno o más productos en términos de la composiciónde servicios y contratos asociados o otros acuerdos. También puede ser usado para ilus-trar las interfaces mediante las cuales el producto es ofrecido y los eventos asociados alproducto. Este punto de vista es usado en el desarrollo de productos para diseñar unproducto mediante la composición de servicios existentes o identi�cando cuales nuevosservicios se pueden crear a partir de un producto dando el valor esperado por el cliente[7].

Como se indica en el meta-modelo A.6, una vez identi�cado el producto, se debe enumerarlas características que hacen que el producto tenga valor, por ejemplo características comocon�abilidad, e�ciencia o garantía. Estos valores deben ser los más relevantes, para quela organización alinee sus piezas para cumplir a cabalidad con estas características.

Dependiendo el producto que se realiza en la organización existen diferentes tipos decontrato, en algunos casos pueden ser contratos complejos y en otros pueden ser tansencillos como una factura de compra, esto se debe aclarar para el producto, ya que deél depende el soporte legal que respalda al producto y por ende a la compañía.

El producto tiene una relación de composición con el servicio identi�cado en puntos devista anteriores, encontrando así una manera general y clara de identi�car las relacionesentre los procesos que se realizan en la organización junto con las características de valorque se ofrecen en los productos.

37


3.6.1. Modelo Punto de Vista del Producto

Figura 3.6.: Modelo de Punto de Vista del Producto. Fuente: Propia

SAPI, es acrónimo para �Sistema de Automatización del Proceso de Importación� y sede�ne como el Producto del negocio y que es agregado al servicio para facilitar y gestionarla compra de insumos provenientes del extranjero realizado por el proceso de importaciónde insumos y que tiene asignado como roles principales el importador y el comprador.

El producto SAPI, es el componente de negocio que permite dar soporte al ejercicio deimportación de mercancías desde el extranjero y tiene como características de valor parael cliente la facilidad en la compra, la entrega a tiempo de los insumos, el seguimientodel estado de los insumos y el bajo costo.

38

4. MODELAMIENTO DE LAAPLICACIÓN

Los meta-modelos describen la relaciones correctas entre los diferentes componentes, perono obliga a hacer uso de todos ellos en la realización o diseño de un modelo; El arquitectoes libre de diseñar el modelo respetando los componentes y sus relaciones.

4.1. Punto de Vista de Comportamiento de Aplicación

Describe el comportamiento interno de una aplicación. Este punto de visto es útil diseñan-do el principal comportamiento de aplicaciones, o identi�cando coincidencias funcionalesentre diferentes aplicaciones, o identi�cando coincidencias funcionales entre diferentesaplicaciones[7].

El punto de vista de comportamiento de aplicación, describe un meta-modelo A.7 quecomprende y/o implica la relación entre los componentes de aplicación.

Estos elementos permiten describir como una aplicación o aplicaciones se comportanentre sí en forma conjunta o individual; Como un servicio de aplicación opera sobre unobjeto de datos, o como los objetos de datos se comunican a través de las interaccionesy uso en las funciones de aplicación.

El meta-modelo indica como las funciones de aplicación puede ser asignadas a un compo-nente de aplicación, para describir una funcionalidad en particular, y como la agregaciónde dos o más componentes de aplicación generan o describen una colaboración de aplica-ción; Esto para identi�car y demostrar cómo la colaboración de dos o más componentespueden generar una funcionalidad más compleja.

A un nivel aún más alto, el componente de interacción de aplicación identi�ca y describeel comportamiento de una colaboración de aplicación mediante el �ujo y disparo de unafunción de aplicación, en la cual podrá realizar una función de aplicación o estar asignadaa un componente de aplicación.

39

4. MODELAMIENTO DE LA APLICACIÓN

4.1.1. Modelo Punto de Vista de Comportamiento de Aplicación

Figura 4.1.: Modelo de Punto de Vista de Comportamiento de Aplicación. Fuente: Propia

La trazabilidad de importación es la colaboración principal que agrupa a los compo-nentes de Gestión de Órdenes, Proveedor, Transporte, Nacionalización y el Tablero deseguimiento. Administrar las órdenes de compra, es la función asignada al componentede gestión de órdenes y es donde se evidencia el registro de cada una de las órdenesgeneradas en la empresa.

El componente de aplicación de Proveedor, mantiene al día la información pertinente acada uno de los diferentes proveedores o vendedores con los que la empresa tiene o hatenido relaciones comerciales; la función asignada al componente es la de Gestionar losProveedores.

Seguir el transporte de los insumos durante su trayecto desde el puerto de origen alpuerto de destino, es una función de aplicación que permite saber en todo momento endonde se encuentra la mercancía; está función está asignada al componente de aplicaciónde Transporte.

La Nacionalización es el componente de aplicación que tiene asignada la función desoportar el proceso de la nacionalización de la mercancía (insumos) cuando llega al puertode destino, el componente facilita el conocimiento de las actividades a realizar para lanacionalización y permite llevar registro de los documentos generados durante el proceso.

En última instancia se presenta el componente de aplicación de Tablero de Seguimiento,que en apoyo a los componentes anteriores, permite mediante la función asignada, Ilustrarel estado del proceso de importación.

40


4.2. Punto de Vista de Colaboración de Aplicación

Describe las relaciones entre aplicaciones de componentes en términos de los �ujos de in-formación entre ellos, o en términos de los servicios que ofrecen y utilizan. Adicionalmentese utiliza para crear una visión general de las aplicaciones de una organización. Tambiénse utiliza para expresar la cooperación (interna) o la orquestación de los servicios que enconjunto apoyan la ejecución de un proceso de negocio [7].

En punto de vista de cooperación de aplicación, se toma como referencia para su meta-modelo A.8 el meta-modelo del punto de vista de comportamiento de aplicación, estose debe a que da uso o implementación de los mismos componentes, con la salvedadque para el meta-modelo del punto de vista de cooperación de aplicación se adiciona elcomponente de localización.

A de quedar claro que para este punto de vista, el componente de localización puedeexpresar una ubicación lógica o conceptual dentro del diseño de los modelos.

En comparación con el meta-modelo del punto de vista de comportamiento de aplicación,el meta-modelo para el punto de vista de cooperación de aplicación permite diseñar unmodelo donde prevalece o se evidencia la relación entre los diferentes componentes de unao varias aplicaciones, en función del �ujo de información o en términos de los serviciosque se ofrecen.

4.2.1. Modelo Punto de Vista de Colaboración de Aplicación

Figura 4.2.: Modelo de Punto de Vista de Colaboración de Aplicación. Fuente: Propia

El modelo del punto de vista describe cómo se relacionan entre sí los componentes degestión de órdenes, transporte, proveedor y la nacionalización dentro de una ubicación

41


conceptual denominada �back o�ce� junto al componente de tablero de seguimiento cen-trado de igual forma en una ubicación conceptual �front o�ce�; entre todos apoyan losservicios y proceso en la importación de insumos generando una colaboración de compo-nentes denominada �Trazabilidad de Importación�.

La localización conceptual Back O�ce, se de�ne y agrupa a todos los componentes deaplicación, que con una visión profunda del negocio, se encargaran de registrar los pro-cesos y/o actividades que se realizan durante el proceso de importación. La informacióny datos sobre estos procesos será registrada en un esquema de base de datos relacional amanera de bitácora de las actividades realizadas. Lo anterior describe cómo la relación defuncionalidad por Creación, Lectura, Actualización y Borrado de la información en unabase de datos, genera el agrupamiento o cooperación entre los componentes de aplicaciónde gestión de órdenes, transporte, proveedor y la nacionalización.

El Front O�ce, es una localización conceptual, que agrupa o contiene el componente deTablero de Seguimiento, el cual presenta una funcionalidad de reporte o visualización delestado de los procesos de importación. Este componente se alimenta de la informacióngenerada por los componentes del Back O�ce, logrando así cumplir sus funciones.

Al igual que en el punto de vista de comportamiento de aplicación, la Trazabilidad deImportación es el nombre que se le da a la colaboración entre los componentes quecontiene el Back O�ce y el Front O�ce, esto para no confundir a los interesados entecnología dentro de la arquitectura.

4.3. Punto de Vista de Estructura de Aplicación

Muestra la estructura de una o más aplicaciones o componentes. Es útil en el diseño o lacomprensión de la estructura principal de aplicaciones o componentes y los datos asocia-dos; por ejemplo, para romper la estructura del sistema en construcción, o para identi�carlos componentes de aplicaciones que son adecuados para migración / integración [7].

Dentro del punto de vista de estructura de aplicación, el elemento sobresaliente en elmeta-modelo A.9, es el componente de aplicación; el cual se describe como una partemodular de un sistema de software que encapsula su comportamiento y datos y que losexpone mediante un grupo de interfaces.

Un componente de aplicación presenta las siguientes características:

Presenta una o más interfaces de aplicación. Los componentes cooperativos están conec-tados por una colaboración de aplicación. Puede ser asignado a una o más funciones deaplicación. Es independiente de despliegue, reutilizable y reemplazable. Realiza una másfunciones de aplicación.

Este meta-modelo permite representar, diseñar o esquematizar la estructura de un com-ponente de aplicaciones, logrando de esta manera comprender cómo se compone unaaplicación mediante el uso de componentes y los datos asociados.

42


La representación estructurada de una aplicación se da por la descripción y de�niciónde los componentes a utilizar, su relación y comportamiento a través de las interfaces deaplicación de�nidas.

4.3.1. Modelo Punto de Vista de Estructura de Aplicación

Figura 4.3.: Modelo de Punto de Vista de Estructura de Aplicación. Fuente: Propia

En puntos de vista anteriores, la trazabilidad de importación se de�ne como la colabora-ción entre los diferentes componentes; desde la perspectiva de estructura de aplicación sedescribe como un componente central que permite la asociación entre los componentes deGestión de Órdenes, Proveedor, Nacionalización, Transporte y Tablero de Seguimiento.

La orden de compra es la interfaz que asocia el componente de gestión de órdenes con elcomponente de trazabilidad de importación, al igual que lo hace el contrato de compracon el proveedor, los documentos de nacionalización con la nacionalización, el contra-to de transporte con el transporte y la información de seguimiento con el tablero deseguimiento.

43


4.4. Punto de Vista de Uso de Aplicación

Describe cómo se utilizan las aplicaciones para soportar uno o más procesos de negocio,y la forma en que son utilizados por otras aplicaciones. Se puede utilizar en el diseño deuna aplicación mediante la identi�cación de los servicios que necesitan los procesos denegocio y otras aplicaciones, o en el diseño de procesos de negocio mediante la descripciónde los servicios que están disponibles. Por otra parte, ya que identi�ca las dependenciasde los procesos de negocio en las aplicaciones, puede ser útil para los gerentes operativosresponsables de estos procesos [7].

El punto de vista de uso de aplicación describe cómo las aplicaciones dan soporte a losproceso del negocio, por esta razón, el meta-modelo A.10 comprende y adiciona compo-nentes de las capas de negocio, los cuales se integran y se relacionan con los componentesde la capa de aplicación.

Así como en meta-modelo del punto de vista de estructura de aplicación, el componente deaplicación es el elemento trascendente, en este meta-modelo, lo es el servicio de aplicación,elemento que expone la funcionalidad de los componentes de aplicación en el entorno yel cual es accedido mediante una o más interfaces de aplicación.

Los servicios de aplicación se realizan por uno o más componentes de aplicación, elservicio de aplicación a su vez puede requerir el uso o generación de un objeto de datos.

4.4.1. Modelo Punto de Vista de Uso de Aplicación

Figura 4.4.: Modelo de Punto de Vista de Uso de Aplicación. a). Fuente: Propia

44


Figura 4.5.: Modelo de Punto de Vista de Uso de Aplicación. b). Fuente: Propia

Figura 4.6.: Modelo de Punto de Vista de Uso de Aplicación. c). Fuente: Propia

Figura 4.7.: Modelo de Punto de Vista de Uso de Aplicación. d). Fuente: Propia

45


El proceso de transporte de insumos es apoyado por el componente de software Trans-porte, el cual presta los servicios de registro de embarque de insumos, reporte del estadodel buque y registro del desembarque de insumos.

El proceso de negociación con el proveedor es apoyado por los componentes de Gestiónde órdenes de compra y proveedor, el primero presta el servicio de registro de órdenes decompra y el segundo, registro de negociación con proveedores.

Los componentes que apoyan el proceso de nacionalización de insumos son pago y levan-tamiento. El componente de pago aporta el servicio de registro de pago de impuestos yel componente de levantamiento presta el servicio de registro del levantamiento.

El proceso de entrega es apoyado por el componente de entrega, el cual provee el serviciode registro de entrega.

46

5. MODELAMIENTO DE LAINFRAESTRUCTURA

5.1. Punto de Vista de Infraestructura

Contiene los elementos de infraestructura de hardware y software que soportan la capade aplicación, tales como dispositivos, redes o sistemas de software; por ejemplo sistemasoperativos, �rewall, bases de datos, compiladores [7].

Como se logra observar en el meta-modelo A.11, se debe orientar cómo va a ser soportadala capa de aplicación, empezando por los elementos locativos, determinando la ubicaciónde la infraestructura, ya sea física o lógica.

Se debe determinar los nodos principales, los servidores o contenedores principales, comose relacionan a nivel digital con su entorno, utilizando redes de internet, lan o cualquierotro protocolo de comunicación.

Asociados a cada nodo, se lista el software que debe estar en cada nodo, tener en cuen-ta que es software que soporta la capa de aplicación, por ejemplo sistemas operativos,contenedores web o motores de bases de datos.

Los dispositivos se deben identi�car, ya que estos representan la comunicación con elusuario �nal, y representan un lineamiento en la realización de las aplicaciones, depen-diendo si es un computador, una dispositivo móvil o un hardware con micro-controladores;las tecnologías y los retos a solucionar son diferentes.

47

5. MODELAMIENTO DE LA INFRAESTRUCTURA

5.1.1. Modelo Punto de Vista de Infraestructura

Figura 5.1.: Modelo de Punto de Vista de Infraestructura. Fuente: Propia

El lugar donde va a estar la aplicación, es en un servidor en el cual va a contener ungestor de bases de datos postgreSQL[18], También va a estar presente un servidor deaplicaciones donde se desplegará la aplicación desarrollada, la cual será accedida por elcliente desde un computador personal a través de internet.

La base de infraestructura se compone con un servicio de hosting soportado por el sis-tema operativo Linux y que contiene un servidor de aplicaciones WildFly [20] donde sedespliegan los desarrollos de software, La estructura de datos que soporta las aplicacionesse sustenta por un gestor de base de base de datos que contiene un motor Postgres Sql[18].

La comunicación entre el cliente y los servicios de aplicación se facilitan a través deuna red de área local Lan, que �nalmente esta conectada a la red de cobertura mundialInternet.

48


5.2. Punto de Vista de Uso de Infraestructura

Muestra cómo las aplicaciones son soportadas por la infraestructura de software y hard-ware: Los servicios de infraestructura son entregados por los dispositivos; sistemas desoftware y las redes son proveídas a las aplicaciones. Este punto de vista juega un rolimportante en el análisis de rendimiento y escalabilidad, desde este se re�ere a la in-fraestructura física al lógico mundo de las aplicaciones. Es muy útil determinando elrendimiento y los requisitos de calidad sobre la infraestructura basada en las demandasde las aplicaciones que se usan [7].

En el punto de vista de infraestructura, así como en su meta-modelo A.12 se identi�caronlos nodos, software y protocolos de comunicación que soportan la capa de aplicación, eneste punto de vista se debe ser mas especi�co, indicando exactamente qué infraestructurasoporta cuál aplicación. Para lograr esto se debe presentar un servicio de infraestructurael cual es realizado por una función de infraestructura.

El servicio de infraestructura se determina encontrando exactamente que ofrecen loselementos de infraestructura, por ejemplo un sistema operativo presta el servicio deadministración de los recursos de hardware, o el elemento de red presta el servicio decomunicación de datos entre servidores y dispositivos.

5.2.1. Modelo Punto de Vista de Uso de Infraestructura

Figura 5.2.: Modelo de Punto de Vista de Uso de Infraestructura. Fuente: Propia

Los nodos de servidor de aplicación y el servidor de replicación proveen los servicios quesoportan a los componentes de software. El componente de tablero de seguimiento utilizalos servicios del nodo de replicación, ya que es un componente que solo realiza consultas

49


para presentar la información. Los componentes que se encargan de la transaccionalidadde la aplicación van a utilizar los servicios del nodo de aplicación.

5.3. Punto de Vista de Implementación y Despliegue

Muestra como una o varias aplicaciones son realizadas en la infraestructura, Ademáscomprende el mapeo de aplicaciones lógicas y componentes dentro de artefactos, tal comoEnterprise Java Beans [13], y el mapeo de la información usada por estas aplicacionesy componentes dentro de la infraestructura de almacenamiento, por ejemplo bases dedatos o otros archivos. La vista de despliegue juega un papel importante en el análisis derendimiento y escalabilidad, relacionando la estructura física al mundo de las aplicacioneslógicas. En seguridad y análisis de riesgo, la vista de despliegue es usada para identi�car,por ejemplo, dependencias críticas y riesgos [7].

El meta-modelo A.13 describe e identi�ca cómo los componentes lógicos se relacionandentro de los componentes físicos, utilizando sistemas de software, muchos de estos yaexistentes, también mediante dispositivos y artefactos.

El meta-modelo permite identi�car la organización de los diferentes artefactos que satis-facen la realización de los servicios, nodos y sistemas de software presentados.

Un ejemplo claro de la organización o distribución en implementación, se puede evidenciaren sistemas de software complejos que pueden presentar el uso diferentes gestores de basesde datos, repositorios de almacenamiento de archivos, consulta a servidores de serviciosen la nube, servidores de correos y más.

5.3.1. Modelo Punto de Vista de Implementación y Despliegue

Figura 5.3.: Modelo de Punto de Vista de Implementación y Despliegue. Fuente: Propia

50


El punto de vista visualiza y describe como dentro del servidor de aplicaciones se despliegala aplicación SAPI, la cual contempla que todos sus componentes descritos en anteriorespuntos de vista y que se representan como el componente central de Trazabilidad deImportación, presentan una comunicación directa con la base de datos donde se almacenala información del proceso de negocio.

5.4. Punto de Vista de Estructura de la Información

Esta vista es comparable a los modelos tradicionales de información creados en el desa-rrollo de software de casi cualquier sistema de información. Permite mostrar la estructurade la información de la organización en general o de un proceso o aplicación del negocioen particular en términos de tipos de datos o estructura de clases (orientación a objetos)[7].

En el meta-modelo A.14 del punto de vista se indica que se debe partir de las entidadesque se encuentran en la capa de aplicación, identi�cando los principales objetos que sedeben llevar hasta la capa de aplicación, incluso hasta el modelo de persistencia.

Las dependencias que se utilizan en este punto de vista son las de realización, entendiendoque los elementos que se identi�can en la capa de negocio, son realizados digitalmentepor elementos de aplicación, y estos a su vez, realizados por artefactos de infraestructura.

Además se presentan los elementos de signi�cado, que está representado en conceptospropios del negocio y el elemento de representación que permite llevar más a la realidad unconcepto, como los los informes, reportes, presentaciones, indicadores, listados y cualquierotra salida de información.

5.4.1. Modelo Punto de Vista de Estructura de la Información

Figura 5.4.: Modelo de Punto de Vista de Estructura de la Información. Fuente: Propia

51


Durante el desarrollo de las capas negocio y de aplicación se han generado diversos y muyimportantes conceptos que permitirán dar forma a cualquier desarrollo de sistemas deinformación. Todos esos conceptos son retomados en este punto de vista, estructurarlosy dándole orden mediante las relaciones que pueden presentar entre ellos.

Se inicia describiendo las principales entidades de información de la capa de negocio,como la importación, transporte, nacionalización y compra, estas entidades se debenllevar a la capa de aplicación para poder ser procesadas por un software.

Se puede observar en el modelo que la importación es una composición de las demásentidades, la trazabilidad, el transporte, la nacionalización, la orden de compra y lanegociación, cada una de ellas aporta para la completa conceptualización de la entidadimportación.

Este diagrama de clases da la primera percepción de cómo se va a realizar el modelo declases de la aplicación, mostrando los módulos que se deben construir y especi�car pararepresentar en el prototipo de software todas las entidades de negocio involucradas.

5.5. Punto de Vista de Realización de servicios

Este punto de vista visualiza como por los procesos o componentes de aplicación se rea-lizan los servicios de negocio, evidenciando el puente entre el punto de vista de productodel negocio y la vista de procesos del negocio[7].

Como su nombre lo indica y se observa en el meta-modelo A.15, en este punto de vista sedeben identi�car los elementos claves para realizar el servicio que ofrece la compañía, esun tipo de resumen de los elementos generales y que se deben resaltar para comprenderen su totalidad el servicio.

En este punto de vista el elemento por el cual se debe iniciar el diseño, es el servicio denegocio, de él se derivan los procesos principales y los objetos de negocio asociados alservicio; teniendo claro que los procesos de negocio se soportan con servicios de aplicacióny componentes de aplicación, mientras que los objetos de negocio se realizan con objetosde aplicación.

Los elementos que rodean los servicios, se utilizan para hacer claridad en los roles, actoresy colaboraciones principales que intervienen en la realización de los procesos.

52


5.5.1. Modelo Punto de Vista de Realización de Servicios

Figura 5.5.: Modelo de Punto de Vista de Realización de servicios. Fuente: Propia

El servicio de importación de insumos de manera e�ciente es utilizado por el departa-mento de almacén, representado como un rol de negocio, el cual solicita una compra quees ejecutada por el profesional de comercio exterior realizando el proceso de importaciónde insumos con el uso del objeto de aplicación de importación que es accedido medianteel componente de Trazabilidad de Importación.

5.6. Punto de Vista de Capas

Representa algunas capas y aspectos de una arquitectura empresarial en un diagrama.Hay dos categorías o capas, llamada capas dedicadas y capas de servicio. Las capas son elresultado del uso de �agrupar� relaciones para un particionamiento natural de los objetosy relaciones que pertenecen al modelo. Las capas de infraestructura, la aplicación, elproceso y los actores/roles pertenecen a la primera categoría. El principio de estructuradetrás del punto de vista de capas está dedicado a lo que expone cada capa. Las capasdescriben la interacción mediante la relación �usado por�[7].

El meta-modelo A.16 presentan un nuevo componente denominado Paquete, el cual per-mite agrupar elementos para las capas de negocio, aplicación e infraestructura, logrando

53


así presentar un paquete de negocio, paquete de aplicación y paquete de infraestructu-ra. Cada uno de ellos interactuando el uno con el otro, para que sea posible realizar elservicio que ofrece la compañía.

En estos paquetes agrupan los elementos principales de cada capa, en donde la capa denegocio presenta el proceso principal o general, para el paquete de aplicación el com-ponente principal que apoya al proceso, y para la infraestructura, el nodo principal quesoporta el componente de aplicación.

Esta es una manera muy resumida y concreta de representar toda la arquitectura haciendouso de las tres capas y sus elementos representativos, además se puede interpretar comoel resultado de la abstracción de las capas elaboradas.

5.6.1. Modelo Punto de Vista de Capas

Figura 5.6.: Modelo de Punto de Vista de Capas. Fuente: Propia

El servicio de importar insumos de manera e�ciente es realizado por el proceso de impor-tación en la capa de negocio, mediante el componente de trazabilidad de importación quese presenta en la capa de aplicación, el cual se soporta mediante la capa de infraestructuraque contiene el servidor de aplicaciones.

54

6. MODELO MOTIVACIONAL

6.1. Punto de Vista de Implicados

Permite el análisis para modelar los interesados, los manejadores para cambio internos yexternos, y las mediciones (en términos de peso, debilidad, oportunidades y amenazas)de estos manejadores. También, las relaciones a los objetivos (de alto nivel) que direccio-nando estas preocupaciones y mediciones pueden ser descritas. Estos objetivos de basepara los requisitos de los procesos de ingeniería, incluyendo re�nería de objetivos, análisisde contribución y con�icto, y la derivación de requisitos que realizan los objetivos [7].

El meta-modelo A.17 describe como el componente de implicado está asociado al com-ponente de objetivos motivacionales y al driver de negocio o manejador. De igual formael meta-modelo visualiza la asociación entre el assessment o evaluación con el objetivomotivacional y el manejador.

Se describen los objetivos principales de cada implicado, aclarando las preocupaciones ointereses de cada uno en términos de objetivos y manejadores. Esta relación entre objetivoe implicado, puede dar una visión clara de las preocupaciones o intenciones de cada uno,incluso se puede presentar que diferentes implicados tienen los mismos objetivos, de talmanera que estos son los primeros que se deberían resolver.

El elemento de valoración, en inglés assesment, es utilizado para indicar cómo se midenlos objetivos, con un valor cuantitativo, de tal manera que al �nal del ejercicio se puedadeterminar si los objetivos se cumplieron.

55


6.1.1. Modelo Punto de Vista de Implicados

Figura 6.1.: Modelo de Punto de Vista de Implicados. Fuente: Propia

Para cualquier proyecto es importante lograr de�nir en primera instancia quienes seránlos principales involucrados y/o bene�ciarios en la de�nición y realización del proyectoy los objetivos del negocio o empresa que se verán impactados. No es necesario unade�nición precisa con nombre puntuales, puesto que las personas en muchas entidadesestán de paso; Para ello se de�nen bajo los roles o per�les que desempeñan, como es el casopara la empresa Químicos Manios S.A, que para ejercicio del proyecto de investigaciónsobre el proceso de importación de insumos, se ha logrado identi�car como Stakeholdero involucrados el Gerente de la entidad, el director de bodega, el director de compras yun profesional en comercio.

Dentro de sus objetivos de negocio y más puntual en el área de compras, han de�nido quela realización de la cadena logística de importación junto a la realización de la operaciónde importación de insumos, son objetivos principales; al igual que la garantía de que losinsumos importados y entregados en la empresa, corresponda a los solicitados.

56


Sobre los objetivos para el proceso de importación, se han de�nido unos assessment o va-loraciones que puedan revelar fortalezas, debilidades, oportunidades y amenazas durantela investigación.

Para la realización de la cadena logística de importación, su valoración se da sobre lacantidad de órdenes de compra sin costos que se han generado. En la realización dela operación de importación de los insumos, la valoración se realiza en la cantidad deórdenes de compra entregadas en los tiempos pactados.

El número de órdenes de compra entregadas en su totalidad, es el assessment que dala valoración al objetivo de garantizar que los insumos importados y entregados a laempresa, correspondan a los solicitados.

6.2. Punto de Vista de Realización de Objetivos

Permite a un diseñador modelar el re�namiento de objetivos (alto nivel) en objetivos másconcretos, en el re�namiento de objetivos concretos en requisitos o limitaciones que des-criben las propiedades que son necesitadas para realizar los objetivos. El re�namiento deobjetivos en sub-objetivos es modelado usando la relación de agregación. El re�namientode objetivos en requisitos es modelada usando la relación de realización. Adicionalmente,los principios pueden ser modelados para guiar el re�namiento de objetivos en requisitos[7].

El el diseño del punto de vista de implicados, guiado por su meta-modelo A.18, surgenlos objetivos motivacionales como componentes asociados a los implicados o interesadosen el dominio de negocio de la compañía. Pero es en el meta-modelo del punto de vistade realización de objetivos donde estos son complementados o realizados mediante loscomponentes de restricción �constraint�, que son elementos que se de�nen como unarestricción a la forma en que se realiza un sistema.

Es mediante las declaraciones de necesidad o requerimiento en un sistema que se puederealizar en igual medida también los objetivos motivacionales, los cuales presentan unarelación muy arraigada con los principios.

Un principio se de�ne como una propiedad normativa de todos los sistemas en un contextodado, y es con esta de�nición que un principio logra la realización de los requerimientosy de las restricciones.

57


6.2.1. Modelo Punto de Vista de Realización de Objetivos

Figura 6.2.: Modelo de Punto de Vista de Realización de Objetivos. Fuente: Propia

Para el punto de vista de realización de objetivos, es importante visualizar los requeri-mientos y restricciones que pueden abordar a los objetivos del negocio; por ellos, se lograidenti�car para cada objetivo un requerimiento y una restricción.

Para garantizar que los insumos importados y entregados a la empresa correspondana los solicitados inicialmente en la orden de compra, es requerimiento que los insumos

58


adquiridos deben cumplir con las normas de calidad y seguridad del país; como restricción,es necesario tener el listado con el detalle de los insumos requeridos en la orden de compra.En la realización de la operación de importación de los insumos en el menor tiempo posiblepara abastecer a tiempo el inventario con los insumos necesarios para su operación,es requerimiento tener contratación con un agente de carga para el transporte de losinsumos; teniendo como restricción, los acuerdos de compra con diferentes proveedores.Sobre la realización de la cadena logística de importación de insumos a Colombia, parareducir costos de operación, es requerimiento el que los costos de importación estánsujetos al comportamiento del mercado de divisas; y como restricción, tener disponible yaccesible los costos de las actividades a realizar en la importación.

6.3. Punto de Vista de Contribución de Objetivos

Permite a un diseñador o analista modelar las relaciones de in�uencia entre objetivos yrequisitos. La vista resultado puede ser usada para analizar el impacto que los objetivostienen en cada uno o para detectar con�ictos entre los objetivos de los interesados.

Típicamente, este punto de vista puede ser usado después de tener objetivos, a algunaextensión, sido re�nados en sub-objetivos y posiblemente, en requisitos. Sin embargo, lasrelaciones de agregación y realización también pueden ser presentadas en este punto devista [7].

En este punto de vista y en su meta-modelo A.19 se adiciona la relación de in�uencia,la cual no se había utilizado en las anteriores vistas, esta relación se utiliza para indicarque un elemento in�uye positiva o negativamente sobre otro elemento. Es común que losobjetivos de�nidos por diferentes interesados no se puedan realizar al mismo tiempo oque no tengan resultados con bene�cios para otros, por tal razón estas relaciones danuna referencia de cuáles son las consecuencias de realizar un objetivo.

De la misma manera los principios pueden in�uir positiva o negativamente a un objetivoo requisito, por ejemplo, si un principio para la compañía es preocuparse por el bienestarde los empleados, podría afectar negativamente el objetivo de reducir costos de operaciónde la compañía.

Los requerimientos son importantes para llegar al cumplimiento de los objetivos, perotenemos la misma situación mencionada, puede que un requisito afecte positivamente aun objetivo, pero negativamente a otros, de tal manera que a partir de este punto devista se debe tener claridad en cuáles requisitos tienen menor o mayor impacto sobre losobjetivos y principios.

Cabe aclarar que las relaciones no son solo hacia elementos diferentes, de objetivo aprincipio, de principio a requisito, etc; sino que también pueden in�uir a elementos delmismo tipo, de objetivo a objetivo, de principio a principio y de requisito a requisito. Estopuede revelar un posible con�icto entre objetivos o requisitos que se desean implementar.

59


6.3.1. Modelo Punto de Vista de Contribución de Objetivos

Figura 6.3.: Modelo de Punto de Vista de Contribución de Objetivos. Fuente: Propia

Se permite evidenciar cómo in�uyen los requerimientos y/o restricciones sobre los obje-tivos, como lo hace el requerimiento de garantizar la seguridad al momento de solicitarlos insumos requeridos, que in�uye positivamente sobre el objetivo de garantía que losinsumos importados y entregados a la empresa correspondan a los solicitados.

Es relevante aclarar que un mismo requerimiento y/o restricción puede in�uir positiva-mente sobre un objetivo y al mismo tiempo de forma negativa sobre otro; como lo hace elrequerimiento de realizar labores adicionales para mantener actualizada la información,el cual in�uye positivamente sobre el objetivo de garantía de entrega de los insumos,pero que in�uye de forma negativa sobre el objetivo de realizar la cadena logística deimportación de insumos a Colombia; el requerimiento de transferencia física internacionalde documentos originales, también in�uye de manera negativa, sobre este objetivo.

Pero el objetivo de la realización de la cadena logística, no solo recibe in�uencia negativa,él recibe in�uencia positiva del requerimiento de dar prioridad a los proveedores delmercado oriental; requerimiento que a su vez, genera un in�uencia negativa en el objetivode la realización de la operación de importación de los insumos en el menor tiempo posiblepara abastecer a tiempo el inventario.

De esta forma, se puede evidenciar como un requerimiento y/o restricción pueden in-�uenciar, positiva o negativamente a los objetivos del negocio.

60


6.4. Punto de Vista de Principios

Permite al analista o diseñador modelar los principios que son relevantes para el diseñodel problema a la mano, incluyendo los objetivos que motivan esos principios. Adicional-mente, relaciones entre principios y sus objetivos, pueden ser modelados. Por ejemplo,principios pueden in�uenciar cada uno positiva o negativamente [7].

6.4.1. Modelo Punto de Vista de Principios

Figura 6.4.: Modelo de Punto de Vista de Principios. Fuente: Propia

En este punto de vista y como se evidencia en su meta-modelo A.20 se deben listar todoslos principios, y sus relaciones con los objetivos, relaciones de realización e in�uencia,

61


de tal manera que se permita descubrir conceptos que no se habían descubierto en losanteriores puntos de vista donde el elemento principal eran los objetivos.

Los principios pueden ser confusos de de�nir, existe una delgada línea entre las normas,políticas, reglas de una organización o restricciones; de tal manera que este punto de vistadebe quedar totalmente de�nido y aclarado que es un principio para la organización parapoder relacionarlo a los objetivos que se desean cumplir.

Los principios son una propiedad normativa de todos los sistemas en un contexto dado;es así como el punto de vista de principios permite describir aquellos principios sobre loscuales se sustenta el proceso de importación de insumos.

Bajo el principio de Calidad, para vender siempre lo mejor, es que se basa el objetivode garantizar que los insumos importados y entregados a la empresa correspondan a lossolicitados. Esto como premisa para que la organización pueda desarrollar o producirproductos de calidad.

La e�ciencia, para producir en los tiempos idóneos, es el principio sobre el que el objetivode realizar la operación de importación de los insumos en el menor tiempo posible, sesustenta. La mejora continua con base a los antecedentes, es el principio que apoya elobjetivo de realizar la cadena logística de importación de insumos a Colombia.

Finalmente, un principio de mayor alcance es el de maximizar el bene�cio para la empresa,el cual soporta a los tres objetivos principales del proceso de importación de insumos.

6.5. Punto de Vista de Realización de Requisitos

Permite al diseñador modelar la realización de requisitos por los elementos principales, talcomo actores de negocio, servicios de negocio, procesos de negocio, servicios de aplicación,componentes de aplicación, etc. Típicamente, los requisitos resultan desde el punto devista de re�namiento de objetivos[7].

Es en punto de vista de realización o re�namiento de objetivos motivacionales, dondesurgen por primera vez los requerimientos en diseño de la capa motivacional. Pero es eneste meta-modelo A.21 donde los requerimientos que realizan los objetivos, son descritosa más detalle.

El objetivo principal de este meta-modelos es permitir a los arquitectos adicionar nuevosrequerimientos mediante la relación de agregación y de ser necesario los requerimientosexistentes pueden ser descritos con un mayor detalle en profundidad, para dar claridaden la realizaciones de los componentes implicados a ellos.

62


6.5.1. Modelo Punto de Vista de Realización de Requisitos

Figura 6.5.: Modelo de Punto de Vista de Realización de Requisitos. Fuente: Propia

Dentro del punto de vista de re�namiento de objetivos se enunciaron algunos requisitoso requerimientos para los objetivos; en este punto de vista se describe el re�namientoy adición de nuevos requerimientos, como: Garantizar la trazabilidad de las actividadesdel procesos de importación, es un requisito de mayor envergadura puesto que permitela realización de los tres objetivos principales del proceso de importación de insumos.

Surgen nuevos requisitos como, hacer evidente la aceptación de los insumos, deja evi-dencia mediante �rma digital, el tener conocimiento concreto en todas las actividadesde importación a realizar y tener documentado los manuales de procesos, son nuevosrequisitos que surgen y se detallan en este punto de vista.

63


6.6. Punto de Vista de Motivación

Permite al diseñador o analista modelar el aspecto motivacional, sin enfocarse en ciertoselementos dentro de este aspecto. Por ejemplo, este punto de vista puede ser usado parapresentar un resumen completo o parcial de el aspecto motivacional mediante la relaciónentre interesados, sus objetivos primarios, los principios que son aplicados, y los requisitosprincipales en servicios, procesos, aplicaciones y objetos [7].

Como sucede en las diferentes capas de la arquitectura, existe un diagrama que cumpleel papel de resumir los elementos descritos, esto para presentar los principales elementosde�nidos durante el ejercicio, así como se evidencia en su respectivo meta-modelo A.22.

Este punto de vista se centra en los objetivos generales que se desean cumplir, sin llegar adescribir los especí�cos. A partir de estos objetivos generales se debe tener la capacidad dede�nir las valoraciones, manejadores, interesados, requisitos y principios determinantesen la de�nición y realización de los objetivos.

De igual manera se deben presentar las principales relaciones que existen entre los ele-mentos, sobre todo las asociaciones a los interesados y las in�uencias entre requisitos,principios y objetivos.

Teniendo este resumen, se debe comprender claramente cuáles son las motivaciones de laorganización para realizar el trabajo de arquitectura y cual va a ser el estado al cual seva a llegar después de ejecutar la arquitectura.

6.6.1. Modelo Punto de Vista de Motivación

Figura 6.6.: Modelo de Punto de Vista de Motivación. Fuente: Propia

Después de haber logrado describir en los objetivos, interesados, requerimientos, restric-ciones, valoraciones y principios que sustentan y modelan la capa motivacional de la

64


empresa Químicos Manios S.A, este punto de vista permite representar un resumen muyconciso sobre la capa motivacional.

Los tres objetivos principales que sustentan el proceso de importación de insumos, seven realizados por un requerimiento generalizado que es garantizar la trazabilidad de lasactividades del proceso de importación.

Así mismo, para los tres objetivos se tiene asociado el rol más importante en todo elproceso, el cual es el profesional en comercio y quien sustenta el ejercicio sobre un driverde negocio que es el automatizar el proceso de importación.

65

7. IMPLEMENTACIÓN Y MIGRACIÓN

7.1. Punto de Vista de Proyecto

Usado para modelar la administración de cambios arquitectónicos. La arquitectura delproceso de migración desde una situación anterior (Actual estado de la arquitectura dela empresa) a una nueva situación deseada (estado Objetivo de la arquitectura de laempresa) tiene consecuencias signi�cativas a mediano y largo plazo de la estrategia decrecimiento. Algunos de los problemas que deberían ser tenidos en cuenta por los modelosdiseñados en este punto de vista son:

Desarrollar una arquitectura empresarial plena en toda la organización es una tareaque puede necesitar varios años.

Todos los sistemas y servicios deben permanecer operacionales e independientesa todos los problemas, modi�caciones y cambios de la arquitectura empresarialdurante el proceso de cambio.

El proceso de cambio puede tener que lidiar con los estándares de la tecnologíainmadura (Ejemplo, mensajería, seguridad, datos, etc). El cambio tiene serias con-secuencias para el personal, la cultura, la manera de trabajar y la organización.

Además, estos son algunos otros aspectos de gobernanza que puede limitar el procesode transformación, tal como cooperación interna y externa, administración de portafoliode proyecto, administración de proyectos (Entregables, objetivos, etc), �Plateas� hitos deplaneación, aspectos �nancieros y legales, etc[7].

Para el punto de vista de proyecto se de�ne un meta-modelo A.23 que permite a partir deun objetivo motivacional, identi�car un paquete de trabajo a ser analizado, diseñado ydesarrollado; realizando así un liberable que puede ser un proyecto, sistema de software,servicio, proceso entre otros.

El meta-modelo también indica que los roles y actores implicados en el proyecto quepresentan participación o interés, deben ser agregados y descritos como componentespara visualizar un mayor compromiso organizacional en diseño.

66


7.1.1. Modelo Punto de Vista de Proyecto

Figura 7.1.: Modelo de Punto de Vista de Proyecto. Fuente: Propia

Este punto de vista permite dar una visión generalizada de todo el proyecto de investi-gación sobre el proceso de importación.

El punto de vista describe como dentro del proyecto de investigación sobre un objetivoprincipal de facilitar y gestionar la compra de insumos provenientes del extranjero, serealiza un paquete de trabajo central, para el desarrollo de un sistema de automatiza-ción del proceso de importación a Colombia, que liberará un prototipo de software webdenominado SAPI.

El proyecto también identi�ca que sobre el objetivo principal, están asociados los dos rolesprincipales del proceso, el rol del importador y el rol del comprador. El rol importadortiene asignado un actor de un profesional en comercio y el rol del comprador se asignaal actor del almacén.

67


7.2. Punto de Vista de Migración

Conlleva modelos y conceptos que pueden ser usados para especi�car la transición desdeuna arquitectura existente a una arquitectura deseada [7].

El meta-modelo del punto de vista de migración A.24 describe el comportamiento yrelación de dos componentes de principales. La platea se identi�ca como los hitos haser alcanzados durante la migración y el componente �Brecha� que se describe o de�necomo un obstáculo o limitante tecnológica o de negocio a ser superada para ir pasandode platea en platea.

7.2.1. Modelo Punto de Vista de Migración

Figura 7.2.: Modelo de Punto de Vista de Migración. Fuente: Propia

El punto de vista de migración permite describir cómo poder pasar de una arquitecturaexistente a una arquitectura deseada de forma muy conceptual a través de conceptoscomo la platea y la brecha.

Es así como se puede describir que la de�nición de los requisitos del dominio del negocio,es un hito del proyecto el cual se requiere superar y realizar para lograr un segundohito de más alto nivel, que es el desarrollo del prototipo funcional del software parala trazabilidad del proceso de importación; pero para ello es necesario poder superar osobrepasar un obstáculo/brecha que es la aplicación de la metodología de desarrollo ágil.

68


7.3. Punto de Vista de Implementación y Migración

Es usada para relacionar programas y proyectos a las partes de la arquitectura que seimplementa. Esta vista permite modelar el alcance de programas, proyectos, actividadesde proyectos en términos de meseta que son realizados o elementos individuales de ar-quitectura que son afectados. Adicionalmente, la manera de los elementos son afectadospuede ser indicada por anotar las relaciones. Además, este punto de vista puede ser usa-do en combinación con los puntos de vista de programas y proyectos para soportar laadministración de portafolio [7]:

Los puntos de vista de programas y proyectos son adecuados para relacionar objeti-vos de negocio a programas y proyectos. Por ejemplo, esto hace posible para analizara un alto nivel si todos los objetivos de negocio son cubiertos su�cientemente porel actual portafolio.

El punto de vista de implementación y migración es adecuado para relacionar obje-tivos de negocio utilizando programas y proyectos enfocados a la arquitectura. Porejemplo, esto hace posible analizar una superposición entre actividades de proyec-tos o para analizar la consistencia entre dependencias de proyectos y dependenciasa lo largo de los hitos y elementos de arquitectura.

El meta-modelo del punto de vista de implementación y migración A.25 reúne los con-ceptos de�nidos en los puntos de vista de proyecto y el punto de vista de migración,adicionando el componente de requerimiento o restricción agregados al objetivo motiva-cional y que son realizados por el liberable.

Un componente con una gran relevancia y que es trabajado en el punto de vista deimplementación y migración y que el meta-modelo describe, es el componente de locali-zación. Este componente es muy importante a la hora de identi�car donde se realizaránlas implementaciones o migraciones de aplicaciones y/o proyectos.

69


7.3.1. Modelo Punto de Vista de Implementación y Migración

Figura 7.3.: Modelo de Punto de Vista de Implementación y Migración. Fuente: Propia

Este punto de vista genera una visión generalizada sobre los programas y proyectossobre las arquitecturas en las que se despliegan y como cada uno de los componentes serelacionan y son afectados.

Por lo anterior es que este punto de vista describe cómo los componentes del punto devista de proyecto mediante el liberable del prototipo SAPI se asocian con los componentesdel punto de vista de implementación y migración.

70

8. Meta-Modelo de la Arquitectura

Este es el meta-modelo que describe toda la arquitectura del negocio del proceso deimportación. El cual se desarrollará con un mayor nivel de profundidad a través de lospuntos de vista de las capas de negocio, aplicación e infraestructura.

Figura 8.1.: Meta-modelo de la Arquitectura. Fuente Propia

71

9. PATRONES DE DISEÑO

9.1. Patrones Creacionales

Patrones creacionales son patrones de diseño que lidian con mecanismos de creación deobjetos, tratando la creación de objetos de una manera apropiada a la situación. Laforma básica de crear objetos podría resultar en problemas de diseño.

Los patrones de diseño solucionan estos problemas controlando la creación de objetos.Los patrones creacionales de�nen la forma en la cual un objeto puede ser creado consi-derando re-uso y adaptabilidad al cambio, esto describe la mejor manera de manejar lainstanciación de los objetos[3].

Patrones creacionales abstraen el proceso de instanciación. Estos ayudan a construirsistemas independientes de cómo sus objetos son creados, compuestos y representados.Los patrones creacionales delegan la instanciación a otros objetos [22].

9.1.1. Singleton

Provee la posibilidad para controlar una única instanciación de un objeto cualquiera quepuede ser creado y además recibe la manera global de acceder a él [3].

En el amplio contenido existente sobre el patrón singleton, es presizo presentar algunasde las reglas de oro que se ha generado durante su implementación y la práctica [1]:

El patrón singleton se presenta como mejor opción sobre las variables globales, yaque presenta una absoluta seguridad en el número de casos a utilizar.

Singleton debe ser utilizado cuando una clase debe tener exactamente un caso,ni más ni menos. Los diseñadores utilizan con frecuencia Singleton en un intentoequivoco para reemplazar variables globales.

El singleton no acaba con lo global, simplemente cambia el nombre de la misma.

Los objetos fachada son a menudo Singleton porque se requiere solo un objeto dela fachada.

El patrón singleton es necesario cuando es más fácil pasar un recurso de objetocomo una referencia a los objetos que más lo necesitan, en ligar de dejar que losobjetos tengan acceso al recurso a nivel global.

En la estructura B.1 se evidencia como el constructor del objeto es privado, de tal maneraque sólo se puede crear una instancia desde él mismo, de tal manera que ningún objetoexterno puede instanciarlo.

72


9.1.1.1. Aplicación Patrón Singleton

Figura 9.1.: Aplicación del Patrón Singleton. Fuente Propia

Se presenta un elemento que se debe garantizar durante toda la aplicación y cuya exis-tencia debe ser única; Es el TRM1, este elemento representa la conversión del peso Co-lombiano a Dólares, ya que cada vez que se registran y consultan valores en la aplicaciónlos cuales serán en dólares y debe existir una única manera de obtener el valor del TRM,incluso para una fecha especí�ca.

Lo anterior describe la necesidad de diseñar un objeto que represente en todo el prototipode software una única instancia del valor y propiedades del TRM que será utilizado comorecurso único para las diferentes implementaciones requeridas por el sistema; esto convisión que solo exista un único valor del TRM sobre el sistema.

1Tasa Representativa del Mercado

73


9.1.2. Patrón Constructor

Puede ser usado para facilitar la construcción de un objeto complejo desde objetos sen-cillos. El patrón constructor también separa la construcción de un objeto complejo desdesu representación, de tal manera que el mismo proceso de construcción puede ser usadopara crear otra composición de objetos[3].

Puede ser usado para facilitar la construcción de un objeto complejo desde objetos sen-cillos. El patrón constructor también separa la construcción de un objeto complejo desdesu representación, de tal manera que el mismo proceso de construcción puede ser usadopara crear otra composición de objetos como se puede observar en su estructura B.2.

Algunas veces los patrones creacionales son complementarios, el constructor puede usaruno de los otros patrones para completar su construcción, como la fábrica abstracta,prototipo o singleton en algunas implementaciones.

El constructor se enfoca en la construcción de objetos complejos paso a paso, mientrasque la fábrica abstracta se enfoca en producción de familias de objetos sencillos. Elconstructor retorna el producto en el paso �nal.

Regularmente, el diseño empieza usando el método fábrica, ya que es menos complicadoy más con�gurable, esto se convierte en una fábrica abstracta o un constructor el cual esmás �exible y complejo, para que el diseño presente la �exibilidad que se necesita[1].

9.1.2.1. Aplicación Patrón Constructor

Figura 9.2.: Aplicación Patrón Constructor. Fuente Propia

Un objeto complejo a construir es el proceso que conlleva ejecutar un Incoterm, para esteproyecto solo se utiliza el Incoterm FOB, sin embargo, gracias al patrón constructor sepuede crear este objeto a partir de estructuras más simples y se deja la puerta abiertapara la futura creación de los otros incoterms.

74


9.1.3. Patrón Método Fábrica

Provee una manera de usar una instancia como una fabrica de objetos. La fábrica puederetornar una instancia de uno o algunos posibles casos, dependiendo de los datos dadosa él [3].

Algunas veces las clases de la fábrica abstracta son implementadas con el método fábrica,pero pueden ser implementadas usando prototipos. Es bueno aclarar que el método fa-brica resuelve la creación a través de herencia, mientras que el prototipo lo hace a travésde delegación, esto se ve re�ejado en su estructura B.3.

Una ventaja del método fábrica es que puede retornar la misma instancia múltiples veces,o puede retornar una subclase en lugar de un objeto de ese tipo exacto.

el operador �new� es considerado perjudicial, hay una diferencia entre solicitar un objetoy crear uno, el operador �new� siempre crea un objeto y falla para encapsular la creaciónde objetos. Un método fábrica refuerza dicha encapsulación, y permite a un objeto sersolicitado sin acoplar la creación [1].

9.1.3.1. Aplicación Patrón Método Fábrica

Figura 9.3.: Aplicación Patrón Método Fábrica. Fuente Propia

Durante el proceso de importación, se realiza el transporte de los insumos desde el paísde origen hasta el país de destino; existen varios medios de transporte con los cuales sepuede llevar a cabo este proceso, y es por ello que mediante el patrón método fábricase permitirá decidir con cuál medio de transporte se va a realizar para el transporte demercancía.

Como el proyecto presenta un modelo de importación de clase marítimo, el prototipo solohará uso de este objeto para el transporte; Sin embargo el patrón deja un diseño que afuturo permite incluir otros objeto de transporte.

75


9.1.4. Patrón Prototipo

Es la creación de de nuevas instancias mediante el copiado de instancias existentes. Pormedio de la creación de un prototipo, nuevos objetos son creados como copia del original[3], así como se describe en su estructura B.4.

Algunas veces los patrones creacionales son competidores, hay algunos casos en los que elprototipo o la fabrica abstracta no podrían ser usados apropiadamente. En otras ocasionesson complementarios, la fábrica abstracta puede almacenar un conjunto de prototiposdesde el cual se puede clonar y retornar objetos.

Algunos diseños se pueden volver pesados en el uso de los patrones componente y deco-rador, pero pueden ser bene�ciados en sus creaciones por el patrón prototipo.

Los prototipos son útiles cuando la iniciación de objetos es costosa y se anticipan pocasvariaciones en la inicialización de parámetros. En este contexto, el prototipo puede evitarla costosa creación, clonando los objetos desde un prototipo pre-inicializado [1].

9.1.4.1. Aplicación Patrón Prototipo

Figura 9.4.: Aplicación Patrón Prototipo. Fuente Propia

Es claro que todos los objetos de negocio de�nidos durante el diseño de la arquitecturapueden ser realizado como objetos de aplicación en el prototipo de software, y es precisoa�rmar que los cambios de estado, propiedades o atributos se re�ejarán en ellos durantela ejecución del mismo no deben ser alterados por procesos ajenos al modelo del negocio.

Objetos como los usuarios, orden de compra, negociación, transporte, nacionalización,trazabilidad entre otros. Son objetos que presentan atributos con valores de estado que nodeben ser alterados durante la ejecución de un procedimiento fuera del negocio, por lo cualse hace uso del patrón prototipo para crear las copias de objetos para los procedimientosinternos, lo cual permite mantener los objetos y sus atributos en un su estado original.

76


Como ejemplo práctico del patrón prototipo en aplicativo web, se de�ne la estructurapara crear el copiado de los objetos de Orden de Compra y Recibo de pago que medianteel objeto Prototipo Documento se permite crear un clon que es entregado al objeto clienteque representa una funcionalidad cualquiera dentro del desarrollo.

9.2. Patrones Estructurales

Son diseñados para facilitar el diseño identi�cando una manera simple para realizar lasrelaciones entre entidades. Describen cómo los objetos y clases pueden ser combinadoshacia y desde estructuras. Se debe distinguir patrones de objetos y patrones de clases.La diferencia es que patrones de clases describen relaciones y estructuras con la ayuda dela herencia, mientras que los patrones de objetos describen como pueden ser asociados yagregados desde estructuras más complejas [3].

Patrones estructurales se preocupan por cómo las clases y objetos son compuestos paraformar estructuras complejas. Las clases de los patrones estructurales utilizan herenciapara componer implementaciones, por ejemplo se puede considerar como la herenciamúltiple se combina en una clase, creando una estructura mucho más compleja [22].

9.2.1. Patrón Puente

Desacopla una abstracción o interfaz de su implementación de tal manera que las dospuedan variar independientemente. Puente crea un corte limpio entre abstracción e im-plementación [3].

9.2.1.1. Aplicación Patrón Puente

Figura 9.5.: Aplicación Patrón Puente. Fuente Propia

77


El patrón puente es diseñado para dejar que la abstracción y la implementación va-ríen independientemente como se observa en su estructura B.5, mientras que el patrónadaptador es implementado para que clases sin relación trabajen juntas.

Puente es un mecanismo de diseño que encapsula una clase implementación dentro deuna interfaz. El manejador es visto por el usuario como la clase actual, pero el trabajoestá hecho en el cuerpo. Este esquema permite descomponer una abstracción complejaen unas más sencillas, haciendo que las clases sean más fáciles de mantener [1].

En el dominio del negocio del proceso de importación, es el agente de carga el que garanti-za la entrega de los insumos, mediante el transporte por vía marítima o aérea. Resultandoasí como objetos de aplicación el Agente de Carga, el transporte, el transportador, trans-porte marítimo y aéreo, la naviera y la aerolínea. Generando la necesidad a nivel dedesarrollo de cómo interconectar todos estos objetos de dominio para el transporte.

Presentada la necesidad es mediante el diseño del patrón Puente, que permite desacoplarla implementación del proceso de transporte de las diversas entidades que lo realizan.Logrando individualizar el transporte marítimo realizado por la naviera y el aéreo porlas aerolíneas.

9.2.2. Patrón Componente

Ayuda a crear estructuras de árbol de objetos sin necesidad de forzar a los clientesa diferenciar entre ramas y hojas cuidando su uso. El patrón componente deja a losclientes tratar objetos individuales y composiciones de objetos uniformemente [3]. Estoes evidenciable en su estructura B.6.

La aplicación necesita manipular jerárquicamente una colección de objetos primitivos ycompuestos. Procesando un objeto primitivo de una sola manera y procesando al com-ponente de manera diferente.

Se debe considerar la heurística, �Contenedor que contiene contenidos, cada uno podríaser un contenedor�, por ejemplo ensamblados que contienen componentes, cada uno po-dría ser un ensamblado.

Componente y decorador tienen diagramas de estructura similares, re�ejando el hechoque ambos dependen de composición recursiva para organizar un abierto número deobjetos.

El componente puede ser recorrido con el iterador, El visitador puede aplicar una opera-ción sobre un componente. El componente puede usar una cadena de responsabilidadespara dejar a los componentes un acceso global a las propiedades a través de sus padres[1].

78


9.2.2.1. Aplicación Patrón Componente

Figura 9.6.: Aplicación Patrón Componente. Fuente Propia

En la aplicación de importación, el tablero de control es un componente que permiteobservar el estado de las órdenes de compra, para ello se utilizan reportes, los cuales seagrupan en contenedores de reportes que a través del patrón Contenedor permite crearlas estructuras para que puedan ser accedido de forma simple y rápida.

Como el componente de tablero de control requiere visualizar de diferentes formas losreportes generados por las diferentes actividades realizadas durante el proceso de impor-tación, se de�ne la estructura del patrón componente representada por los objetos ARe-porte, que es la clase abstracta que contiene los métodos gra�carReporte(), adicionar(),remover() y getHijo() que permitirá crear el objeto concreto Contenedor de Reporte quepresenta los atributos de la clase abstracta padre y almacenará los diferentes reportes aser utilizados por el tablero de control.

9.2.3. Patrón Decorador

El patrón decorador permite agregar responsabilidades adicionales y modi�car una fun-cionalidad instanciada dinámicamente. El decorador provee una alternativa �exible a unasubclase para extender la funcionalidad, usando composición en lugar de herencia [3].

El decorador puede ser visto como un compuesto degenerado con solo un componente,sin embargo, un decorador agrega responsabilidades adicionales. Este patrón no pretenderealizar una agregación de objetos, esto es claro cuando se observa su estructura B.7.

El decorador es diseñado para permitir agregar responsabilidades a objetos sin subclases.El foco del componente no es embellecer excepto en la representación [1].

79


9.2.3.1. Aplicación Patrón Decorador

Figura 9.7.: Aplicación Patrón Decorador. Fuente Propia

En el proceso de importación, la trazabilidad es el objeto de negocio central del prototipode software a realizar, el cual presenta atributos iniciales en su creación, pero que enel transcurso del ejercicio del proceso se presentan nuevos atributos importantes a serregistrados en la trazabilidad. Por ello es que mediante el patrón Decorador, se planteala estructura para poder adicionar al objeto de aplicación Trazabilidad nuevos atributos.

En el diseño del patrón fachada, se de�ne el componente de InformacionTrazable quepresenta el método agregarInformación() sobre el cual extiende el objeto InformaciónA-diciona, y hereda el método agregarInformacion() y que implementa los objetos concretosComentario e Incidente que representan la información nueva a ser adicionada al objetoTrazabilidad mediante el componente InformacionTrazable, logrando así que el patrónpermita a futuro ir adicionando nuevos objetos con información importante en objetoTrazabilidad.

80


9.2.4. Patrón Fachada

Provee una interfaz uni�cada a una serie de interfaces en un subsistema. Esto de�ne unainterfaz de alto nivel que hace el subsistema más fácil de usar. Una fachada es un objetoque provee una interfaz simpli�cada a un largo numero de código, como una librería declases [3].

La fachada encapsula un subsistema complejo dentro de una sencilla interfaz, como seve en su estructura B.8, esto reduce la curva de aprendizaje necesaria para liberar unsubsistema exitosamente. También promover desacoplando el subsistema de sus clientespotenciales. Por otra parte, si la fachada es el único punto de acceso para el subsistema,limitará las características y �exibilidad que podría necesitar.

Fachada de�ne una nueva interfaz, mientras adaptador usa una interfaz antigua. Se deberecordar que el adaptador hace que dos interfaces trabajen juntas opuesto a la fachadaque de�ne una completamente nueva.

Fachada de�ne una interfaz muy sencilla para un subsistema, no agrega funcionalidadesy no permite que sean conocidas directamente las clases del subsistema [1].

9.2.4.1. Aplicación Patrón Fachada

Figura 9.8.: Aplicación Patrón Fachada. Fuente Propia

La forma de gestionar los costos es un subsistema de gran relevancia en proceso deimportación; el patrón fachada permite de�nir una interfaz que encapsula la funcionalidaddel subsistema de costos en la interfaz costeable.

81


9.2.5. Patrón Proxy

Provee un sustituto o marcador por otro objeto para controlar el acceso a este [3], ensu estructura B.9se puede observar la manera para poder realizar esta implemantación.Existen algunas situaciones comunes donde puede utilizar el patrón proxy [1]:

Un proxy virtual se puede aplicar para la creación de objetos costosos, el objetoreal solo es creado cuando es la primera vez que el cliente lo solicita.

Un proxy protector controla el acceso a un objeto maestro. El objeto sustitutoveri�ca que el invocador tenga permisos de acceso para poder realizar la solicitud.

9.2.5.1. Aplicación Patrón Proxy

Figura 9.9.: Aplicación Patrón Proxy. Fuente Propia

En una orden de compra, cuando se agrega un insumo, es necesario validar que la im-portación del insumo está permitida por las normas colombianas; para la realización deestas validaciones se aplica el patrón Proxy, el cual permite hacer esta veri�cación antesde ser agregado a una orden de compra.

82


9.3. Patrones de Comportamiento

Los patrones de comportamiento identi�can las interacciones repetitivas entre objetos,que pueden ser estructuradas. Estos patrones incrementan la �exibilidad mientras se rea-liza la comunicación. Son patrones enfocados en las interacciones entre cooperación deobjetos. Las interacciones entre objetos que cooperan deben ser de tal manera que, mien-tras se comunican mantienen el más bajo acoplamiento posible. El bajo acoplamiento esla llave para la arquitectura de n-capas. La capa del cliente debe tener bajo acoplamientopara evitar código duro y dependencias [3].

Se preocupan por los algoritmos y al tratamiento de las responsabilidades entre objetos,describe patrones de comunicación entre objetos y también sus comportamientos. Estospatrones se caracterizan por tener complejos �ujos de control que se pueden complicaren tiempo de ejecución [22].

9.3.1. Cadena de responsabilidades

Permite que mas de un objeto maneje una solicitud sin conocimiento mutuo. Así se evitaacoplamiento entre el que envía la petición y los posibles receptores. Se ubican todos losreceptores en una cadena, la cual permite a los objetos receptores pasar la petición a lolargo del siguiente receptor en la cadena hasta que un receptor lo maneje, o que el �nalde la cadena sea alcanzada [3].

En el patrón encadena a los objetos receptores, como se observa en su estructura B.10,entonces pasa cualquier petición de un objeto a otro hasta que encuentre un objetocapaz de manejar la petición. El número y tipo de objetos manejadores es desconocidoinicialmente, estos pueden ser con�gurados dinámicamente.

La cadena de responsabilidades, comando, mediador y observador, direcciona como sepuede desacoplar enviadores de receptores, pero con diferentes tratamientos. La cadenade responsabilidades pasa la petición del enviador a lo largo de los potenciales receptores[1].

9.3.1.1. Aplicación Patrón Cadena de Responsabilidad

Figura 9.10.: Aplicación Patrón Cadena de Responsabilidad. Fuente Propia

83


Dentro del proceso de importación, los costos se presentan en cada unas actividades arealizar; los cuales deben ser registrados y para ello es necesario identi�car en qué etapadel proceso se presentan para así dar el tratamiento respectivo. Por lo anterior, el patróncadena de responsabilidades, permite registrar los costos con base en cada una de lasactividades realizadas dependiendo de cada uno de los estados del proceso.

9.3.2. Patrón Comando

Es usado para crear objetos que representan una acción y eventos en una aplicación. Unobjeto comando encapsula una acción o evento y contiene toda la información requeridapara entender exactamente qué ha sucedido. Pasando el objeto comando como un pa-rámetro se puede, desde cualquier parte extraer la información necesario acerca de lasacciones o eventos ocurridos [3].

El problema que se presenta cuando se debería utilizar el patrón comando es cuando setiene la necesidad de resolver una petición sin conocer los detalles del elemento que envíala petición.

El comando desacopla el objeto que invoca la operación del objeto que tiene que tieneque ejecutarlo, como se observa en su estructura B.11. Para lograr esta separación, eldiseñador crea una clase abstracta que mapea un receptor con una acción. La clase basecontiene un método ejecutar que simplemente llama la acción en el receptor [1].

9.3.2.1. Aplicación Patrón Comando

Figura 9.11.: Aplicación Patrón Comando. Fuente Propia

El aplicativo prototipo web presenta formularios que registran información sobre los hitosa cumplir en el proceso de importación, en estos formularios se presentan componentesvisuales que requiere acciones a ejecutar, y para ello el patrón comando permite crear laestructura de diseño para identi�car cada uno de los eventos asignar a los componentes.

84


Para el formulario que registra la orden de compra, se de�ne un objeto abstracto Coman-doOC con la función de ejecutar() que permite heredar los objetos ComandoCreacionOC,ComandoActualizarOC y ComandoBorrarOC, objetos que implementan dentro de si, losprocedimientos a propios y que son ejecutados por el objeto ComandoOC.

9.3.3. Patrón Iterador

Provee una manera de acceder a los elementos de una objeto agregado secuencialmente sinexponer su representación [3]. Este problema se puede observar resuelto en su estructuraB.12.

9.3.3.1. Aplicación Patrón Iterador

Figura 9.12.: Aplicación Patrón Iterador. Fuente Propia

El agrupamiento de objetos de negocio representados en clases, dentro del desarrolloorientado a objetos, es una práctica muy útil que permite generar listas de objetos.

Las listas son estructuras muy utilizadas en diferentes puntos dentro del desarrollo de lalógica de los procedimientos que solucionan problemas en particular; sin embargo, paraacceder los elementos de un contenedor de objetos (ejemplo, una lista) es necesario lamanipulación de la representación interna del contenedor, lo que se presta a posiblesmodi�caciones de secciones de código funcional.

En el dominio del negocio del proceso de importación, el listado de órdenes de compra quese generan constantemente en el departamento de almacén, es un contenedor de objetosde órdenes que será accedido e iterado de forma secuencial y por su atributo de estado,de esta forma se de�ne:

85


Una clase abstracta que de�ne el agregado de orden de compra donde se describen losmétodos abstractos crearIteradorOrdenCompra que no recibe parámetros y retorna unobjeto iterador de órdenes de compra.

Un segundo método abstracto crearIteradorOrdenCompra recibe un parámetro de textoque describe el estado sobre el cual se quiere realizar la iteración de los objetos de órdenesde compra.

Un objeto concreto ListaOrdenCompra extiende de una clase abstracta IteradorOrden-Compra que describe los métodos abstractos que permiten el acceso iterativo del objetoorden de compra. Los métodos siguiente y anterior, permiten un acceso y recorrido se-cuencial a la lista de órdenes de compra y en sus versiones mejorada, los métodos siguien-teEstado y anteriorEstado permiten el recorrido y acceso a los objetos orden de comprade acuerdo a su estado.

9.3.4. Patrón Estado

Permite a un objeto alterar su comportamiento cuando se estado interno cambia. Usandoherencia y dejando que subclases representen diferentes estados y funcionalidades quepueden cambiar en tiempo de ejecución. Este es una manera limpia para un objeto paraparcialmente cambiar su tipo en tiempo de ejecución [3].

El patrón Estado, describe un modelo donde un contexto presenta una relación de agre-gación con una clase abstracta que de�ne los diferentes métodos (manejadores) que danel comportamiento a los diferentes objetos o clases concretas generalizadas de la claseabstracta que representan cada uno de los estados de�nidos para solución, lo mencionadose puede observar en la estructura del patrón estado B.13[1].

9.3.4.1. Aplicación Patrón Estado

Dentro del modelo de importación de mercancías a Colombia, la orden de compra es unode los componentes de negocios de gran relevancia en todo el �ujo del proceso. Esto es porque la orden de compra pasa por diferentes estados que describen momentos importantes.

En el departamento de almacén, una orden de compra es creada, quedando en un estadoinicial de espera mientras el análisis de costos es realizado en el departamento de com-pras. Al recibir aprobación por el departamento de compras, la orden es asignada a unprofesional en comercio exterior quien se encargará de ejecutar las diferentes actividadesque dan cumplimiento y terminación al proceso de importación.

Para el contexto anterior, el patrón estado permite bajo una estructura estandarizada,modelar una solución �able y práctica para el control de los diferentes estados por losque puede pasar una orden de compra.

86


Figura 9.13.: Aplicación Patrón Estado. Fuente Propia

La solución describe como el objeto Orden de Compra, presenta una relación de agrega-ción con la clase abstracta Estado de Orden, que de�ne los métodos abstractos Veri�carEstado y Siguiente Estado.

El método veri�car estado describe el estado actual que presenta una orden de compraen cualquier momento durante el �ujo del proceso.

El método siguiente estado es la operación que representa el disparo entre los estados ypresenta toda la lógica del negocio, para poder pasar de un estado a otro.

En Espera, Asignada, Ejecución y Terminada son las clases que describen los estados porlos cuales va a pasar una orden de compra y son una generalización de la clase abstractaestado de orden.

9.3.5. Patrón Mediador

Con el patrón mediador la comunicación entre objetos es encapsulada con un objeto me-diador. Lo objetos no se comunican directamente entre sí, excepto a través del mediador.Esto resulta en una implementación más cohesiva de la lógica y reduce el acoplamientoentre los otros objetos [3].

Cuando se necesita crear componentes reusables, pero existen dependencias entre piezaspotencialmente reusables, es posible terminar con el fenómeno de �código espagueti�,para este tipo de problemas el patrón mediador es una buena alternativa, esto se in�ereobservando la estructura del patrón B.14.

El mediador promueve una relación de red de muchos a muchos, modelando ínter-relaciones con un objeto que realza la encapsulación y permite el comportamiento deesas interrelaciones para ser modi�cadas y extendidas a través de subclases [1].

87


9.3.5.1. Aplicación Patrón Mediador

Figura 9.14.: Aplicación Patrón Mediador. Fuente Propia

En el proceso de importación existe un claro mediador entre las diferentes entidades queparticipan en el proceso: el proveedor, la agencia de carga y la agencia de aduanas, entreellas no se conocen, pero solo se comunican a través del mediador para determinar cuandouna ha terminado su proceso y la siguiente debe iniciar.

9.3.6. Patrón Observador

Es un patrón que habilita la funcionalidad de publicar/suscribir. Esto es realizado porun objeto autónomo, el publicador, que permite a otros objetos adicionar o remover sususcripción. El patrón no impone ningún límite al número de observadores que puedenadjuntarse o suscribirse, ellos mismos son noti�cados de futuros cambios en el estado delpublicador [3].

En este patrón se delega toda la funcionalidad de observador a distintos y desacopladosobjetos observadores, como se observa en su estructura B.15. Estos observadores se regis-tran y pierden el registro ellos mismos con respecto al objeto principal. Una vez el objetoprincipal sufre un cambio, este le informa los cambios realizados a los objetos registrados,para que cada uno de ellos haga el manejo correspondiente.

El mediador y el observador son patrones opuestos, mientras que el mediador encapsula lacomunicación entre objetos, el observador introduce los conceptos de sujeto y observador.Se puede ver que es más fácil construir reusables observadores y sujetos que mediadoresreutilizables [1].

88


9.3.6.1. Aplicación Patrón Observador

Figura 9.15.: Aplicación Patrón Observador. Fuente Propia

El tablero de control y todos sus elementos deben estar actualizados en línea, para ello,se utiliza el patrón observador, el cual consiste en que el tablero de control observa lasórdenes de compra, de tal manera que si alguna cambia de estado le noti�ca al tablerode control para que este se actualiza al instante.

El diseño del patrón observador, se implementa mediante la de�nición del objeto Re-porteGra�co, que funciona como observador del estado del objeto OrdenCompra parabrindar información al TableroControl.

9.3.7. Patrón Estrategia

El patrón estrategia se usa cuando se necesita de�nir una familia de algoritmos, encap-sulando cada uno, y haciendolos intercambiables. El patrón estrategia permite que elalgoritmo varíe independientemente del cliente que lo usa. Tiene patrones relacionadoscomo estado, peso ligero, decorador y componente [3].

Una clase base encapsula los detalles de una interfaz, pero la implementación concreta esdejada en clases derivadas, esto se describe en su estructura B.16. Los clientes entoncesacceden a la clase base sin conocer la cantidad de clases derivadas o el cómo estas clasesresuelven la petición [1].

89


9.3.7.1. Aplicación Patrón Estrategia

Figura 9.16.: Aplicación Patrón Estrategia. Fuente Propia

Existe una acción que se realiza con frecuencia en el proceso de importación y es consultarcual es estado de transporte de la carga, si ya salió del puerto o en qué parte del trayectoestá, para lograr esta acción existen diferentes maneras de hacerlo, puede ser llamandoal contacto de la agencia, por medio de correo electrónico o mediante la página web,dependiendo el grado de urgencia se puede utilizar alguna de estas, para ello se aplica elpatrón estrategia, que permite seleccionar cómo se va a realizar la consulta del estado detransporte de la carga.

90

10. Descripción del Prototipo

El presente prototipo de software se desarrolla con la �nalidad de lograr cumplir conuno de los objetivos propuestos en la de�nición del proyecto de investigación; prototipoque tiene como �nalidad lograr automatizar el proceso de importación de mercancías aColombia mediante la modalidad de Incoterm FOB. El código fuente del prototipo seencuentra en el anexo D.

Figura 10.1.: Prototipo SAPI. Fuente Propia

El desarrollo del prototipo se realizó bajo el concepto de la arquitectura planteada enel apartado número dos; en cual está diseñado bajo la arquitectura de desarrollo JavaJEE [14], con un gestor de base de datos PostgresSQL [18] y un Framework de interfazPrimeFaces 5.2 [15].

El prototipo presenta 5 módulos que re�ejan los componentes de aplicación de�nidos enla arquitectura de la capa de aplicación. Estos módulos son los siguientes:

Módulo de Orden de Compra

Módulo de Negociación

91


Módulo de Transporte

Módulo de Nacionalización

Módulo de Tablero de Seguimiento

Estos 5 módulos comprenden la funcionalidad o servicio de negocio planteado comoTrazabilidad de la Información del Proceso de Importación.

10.1. Módulo Orden de Compra

Figura 10.2.: Modulo Orden de Compra. Fuente Propia

El módulo Orden de Compra es el componente del prototipo de software web que con-tiene un formulario de registro de las órdenes de compra que se generan como resultadodel proceso de negocio de una empresa que necesita realizar la compra de productos oinsumos. El formulario permite registrar la fecha en la que se necesita los insumos seanentregados, junto a una descripción de la orden de compra; esta descripción debe ser endetalle el objeto por el cual se realiza la compra, dejando claro aspectos importantes atener en cuenta en el proceso de importación.

Al margen derecho se encuentra un elemento de lista paginada que visualiza todas lasórdenes de compra que se registren en el sistema, y permite ver en primera instancia, datosrelevantes como el estado, la fecha de entrega, la descripción y un atributo de asignación.Cada registro de orden de compra cuenta con dos (2) opciones que permiten ver medianteuna ventana emergente o modal, el detalle de la orden de compra (Icono lupa); la segundaopción es la que al seleccionar una orden de compra cualquiera, el módulo permite agregaro adjuntar a la orden de compra los archivos de soporte necesarios.

92


Adicional al formulario de registro de orden de compra, al margen izquierdo en la parteinferior se presenta un formulario para la asignación del profesional en comercio exteriorque atenderá el proceso de importación para la orden de compra seleccionada.

10.2. Módulo de Negociación

Figura 10.3.: Módulo de Negociación. Fuente Propia

La negociación es una de las actividades que se realiza en el proceso de importación; esdonde el profesional en comercio exterior determina el proveedor con el cual se realizaránlos contratos.

El módulo presenta un componente visual con dos pestañas Tab, en donde la primerapestaña �Registrar� contiene el listado de todas las órdenes de compra que están en estadoasignada junto al listado de los proveedores o empresas con los que se han realizadonegociaciones anteriores. Con la selección de una orden de compra y un proveedor, elprofesional en comercio exterior podrá registrar una negociación, creando la relacióncomercial para el proceso de importación.

En la pestaña denominada �Gestionar�, el profesional en comercio exterior, registrará loshitos necesarios para alcanzar la terminación de la negociación; dentro de los hitos asuperar se encuentra el registro de la negociación, la generación del contrato, la �rmadel contrato. Donde podrá adjuntar los documentos generados o necesarios para lograr elobjetivo. La �nalidad del módulo es llevar el registro de los hitos descritos anteriormentey los documentos generados, para poder hacer el seguimiento sobre el procedimiento denegociación.

93


10.3. Módulo de Transporte

Figura 10.4.: Módulo de Transporte. Fuente Propia

Al �nalizar el proceso de negociación, el profesional en comercio exterior debe accederal módulo de Transporte donde encontrara al igual que el módulo de negociación, dospestañas visuales Tab que contienen el listado de ordenes de compra en estado Negocia-ción Terminada y el listado de agentes marítimos con los cuales debe registrar la relacióncomercial para el transporte de la mercancía.

Al registrar la relación de la orden de compra junto a un agente marítimo, el profesionalen comercio exterior da inicio al proceso de transporte de la mercancía. El paso siguientees sobre la pestaña de �Gestionar� donde se podrá registrar cada uno de los hitos de�nidospara este proceso.

El registro de transporte, la generación del contrato de transporte, la �rma del contrato,el trasporte en curso, en puerto de destino, son los hitos sobre los cuales el profesionalen comercio exterior puede dejar registro en el seguimiento de proceso de transporte. Aligual que en el módulo de Negociación, este módulo también permite adjuntar todos losdocumentos de soporte generados y necesarios para el cumplimiento de esta etapa.

94


10.4. Módulo de Nacionalización

Figura 10.5.: Módulo de Nacionalización. Fuente Propia

En la pestaña �Registrar� se encuentra el listado de las órdenes de compra que se en-cuentran en estado de transporte terminado, lo que le indica al profesional en comercioexterior que la mercancía ya se encuentra en el puerto de destino y que al seleccionar dellistado de aduanas una empresa y una orden de compra, se podrá registrar el proceso denacionalización.

Al registrar la nacionalización, el profesional en comercio exterior podrá continuar reali-zando los hitos de registrar los documentos y realizar el levante; adjuntando en cada unode ellos los documentos necesarios y los documentos generados y logrando así terminarel proceso de nacionalización.

95


10.5. Módulo de Tablero de Seguimiento

Figura 10.6.: Módulo de Tablero de Seguimiento. Fuente Propia

Finalmente se presenta el módulo de tablero de seguimiento, donde el profesional encomercio exterior y cualquier otro actor de la empresa podrá visualizar en cualquiermomento el estado actual de una orden de compra. El módulo presenta un elemento devisualización Grilla o �Tabla� el cual lista todas las órdenes de compra y presenta lassiguientes columnas:

N°, esta columna se identi�ca como un literal para la lista.

Orden de Compra, la columna describe la orden de compra y permite visualizarcon más detalle la información.

Negociación, esta columna visualiza para cada una de las órdenes de compra, elestado en que se encuentra durante el proceso de negociación.

Transporte, esta columna visualiza para cada una de las órdenes de compra, elestado en que se encuentra durante el proceso de transporte de la mercancía.

Nacionalización, esta columna visualiza para cada una de las órdenes de compra,el estado en que se encuentra durante el proceso de nacionalización de los insumosde la mercancía.

Estado, la columna que resumen el estado global de la orden de compra en cualquiermomento para cada orden de compra.

El objetivo principal del presente módulo es permitir a cualquier actor en la empresa,poder visualizar de forma simple y rápida el estado de una orden de compra en susdiferentes procesos durante la importación de los insumos.

96

Parte III.

CIERRE

97

11. Conclusiones

Al inicio de la investigación y como punto de partida se de�nió un objetivo general que sedesglosó en tres objetivos especí�cos; con el propósito de veri�car la hipótesis planteadapara la investigación.

Comprobación de la hipótesis

El proyecto de investigación trazo como hipótesis, el siguiente enunciado: Implemen-

tar un software de administración de importaciones, adaptado a la realidad

del mercado colombiano, permite a las empresas que realizan compras de

productos e insumos al exterior; controlar, gestionar, realizar seguimiento y

llevar la trazabilidad de las transacciones comerciales internacionales. Comoresultado de la investigación, modelamiento de arquitectura y desarrollo de un prototipode software en el proyecto, se puede concluir que la hipótesis es positivamente viable.En la entrega de este proyecto de investigación, no se a�rma con seguridad una totalviabilidad de la hipótesis planteada, a razón que durante el desarrollo del proyecto nose alcanzó a realizar una aplicación práctica del prototipo de software en la empresa deejemplo.

Comprobación y evaluación de los objetivos

Realizar el levantamiento de información sobre el funcionamiento del ejercicio

actual de importar mercancías a Colombia, a través de entrevistas a profe-

sionales y consulta de documentos del área de interés, para la identi�cación

de los procesos a sistematizar. Con el apoyo de un profesional en comercio exteriorcomo asesor, la visualización de la empresa Químicos Manios S.A y la indagación sobrelos conceptos del dominio del proceso de importación; se logra recopilar información quepermitió realizar el modelamiento de la arquitectura y desarrollo del prototipo.

Analizar la información recolectada, clasi�cando e interpretando tareas, diag-

nosticando problemas, sintetizando procedimientos y proponiendo mejoras

para la de�nición de los requerimientos del software. Con gran satisfacción, cla-ridad y orden se logra realizar el análisis de toda la información recolectada, haciendouso del estándar Archimate permitiendo modelar con un enfoque de alto nivel los dife-rentes puntos de vista para cada una de las capas propuestas. El nivel de entendimientodel negocio sobre el cual funciona el proceso de importación, la aplicaciones de softwareinvolucradas y necesarias, junto la infraestructura tecnológica requerida para el funcio-namiento, son puntos fundamentales que se abordaron mediante la descripción de laarquitectura. Y aunque el nivel de abstracción con el que están descritos los modelos delos puntos de vista es alto, la facilidad y factibilidad para adicionar en investigaciones

98

11. Conclusiones

futuras nuevos contenidos o aportaciones es viable. Con todos los puntos de vista de lasdiferentes capas de la arquitectura, fue más que su�ciente para aportar la informaciónnecesaria como requerimientos para el desarrollo del prototipo de software web. Sin llegara de�niciones puntuales de una aplicación a la medida, por lo contrario al desarrollo deun prototipo de aplicación general.

Desarrollar un prototipo de software web, con el método iterativo incremen-

tal en base a los requerimientos de�nidos para sistematizar el proceso de

importación. La creación del prototipo de software web que sistematiza el proceso deimportación se realizó a cabalidad siguiendo el enfoque de iterativo e incremental. Rea-lizando pequeñas implementaciones semanales de acuerdo a los nuevos conocimientosadquiridos durante la descripción de la arquitectura. El prototipo fue tomando formahasta lograr las funcionalidades planteadas, y obtener el producto previsto.

La homogeneidad del lenguaje común, lograda en la arquitectura sobre el dominio delproceso de importación, fue un gran aporte durante el desarrollo del prototipo, puestoque se tenía claridad en los conceptos, lo que llevó a generar una estructura de fondo,dentro de la aplicación, muy organizada y clara para futuras mejoras y adecuaciones porparte de cualquier desarrollador.

La capa de negocio de Archimate permitió que el análisis y el comprensión del proble-ma fuera más claro para los integrantes del proyecto, logrando que se tuviera claro elalcance del proyecto. Además con el uso de las capas de aplicación e infraestructura selogra describir todo el modelo de negocio para que la solución tecnológica esté alineadaestratégicamente con los objetivos de la organización.

Al desarrollar Prototipo se tuvo claridad en los componentes centrales a construir, te-niendo las siguientes ventajas al momento de iniciar el desarrollo, conocimiento en elcomportamiento entre los diferentes componentes, claridad y orden en la estructura dela información, avance progresivo, con forme se adquiere nuevos datos.

Al gestionar y controlar el proyecto, con la aplicación del concepto de �iterativo e incre-mental� de la metodología ágil OpenUP, el desarrollo del proyecto de investigación serealizó de forma estructurada; tomando como puntos de iteración la elaboración de cadauna de las capas de arquitectura. Las iteraciones permitieron avanzar progresivamenteen la investigación, elaboración del libro y desarrollo del prototipo, realizando aportes yajustes en cada iteración.

99

12. Trabajo Futuro

Como continuidad de este proyecto de investigación, quedan diversos temas abiertos enlos que posiblemente se puede continuar trabajando para desarrollar nuevas líneas deinvestigación o mejorar en un futuro este trabajo. En el siguiente apartado se describenalgunos trabajos futuros que pueden desarrollarse con resultado de este proyecto deinvestigación o que durante la limitación del alcance de este proyecto, no se lograronrealizar o tratar a profundidad.

El proyecto solo abarcó el Incoterm FOB del grupo F �Entrega indirecta, sin pago deltransporte principal�, dejando por fuera todos los demás incoterm de los demás grupos.Es así que es viable a partir de este proyecto de investigación, empezar a describir másy mejores mecanismos para automatizar el proceso de importación, a través de los otrosIncoterm.

Realizar en análisis de todos los costos implicados en las diferentes actividades que serealiza para alcanzar el proceso de importación y así lograr la generación automática decostos por producto, por actividad, por etapa y permitir realizar proyecciones de costosantes de realizar el proceso.

Analizar e Identi�car en todo el proceso de importación en las diferentes modalidades deIncoterm, todas las variables existentes y necesarias para diseñar y desarrollar un progra-ma de software que permita realizar simulaciones de compra de productos en el exterior,para identi�car cuál de las Proformas o cotizaciones entregadas por los proveedores, sonla mejor elección en momento determinado.

100

13. Aportaciones

Los sistemas de información de software web, son componentes tecnológicos que generanbene�cios para toda aquella entidad pública, privada con o sin ánimo de lucro y para laspersonas en general que las utilizan. Este componente tecnológico se soporta sobre unainfraestructura de tecnología que bajo colaboración brindan servicios para el cumplimien-to de los procesos de cualquier dominio de negocio; procesos como el de importación demercancías de insumos del exterior a Colombia y con una identi�cación de arquitecturaempresarial, permite ser automatizados.

Se presentan las siguientes aportaciones propias de resultado de esta investigación:

Se presenta un conjunto de conocimientos conceptuales que son abordados parabrindar apoyo en la realización del presente proyecto de investigación.

Se desarrolla la arquitectura empresarial sobre el dominio del negocio para el pro-ceso de importación mediante el modelo de Incoterm FOB para la compra de mer-cancías de insumos del extranjero hacia Colombia.

Se plantean patrones de desarrollo de software para la construcción de cualquierprototipo sobre el dominio del proceso de importación.

Se presenta el desarrollo de un prototipo de software web con los módulos de Ordende Compra, Negociación, Transporte, Nacionalización y Tablero de Seguimiento,acceso y persistencia de datos que realizan la lo propuesto en la arquitectura.

101

Bibliografía

[1] Marina Pavlova Alexander Shvets, Gerhard Frey. 101 design patterns & tips fordevelopers, Agosto 2015. http://sourcemaking.com/design-patterns-and-tips.

[2] Nick Ramsing. Charles Water�eld. Sistema de información gerencial para institu-ciones de micro �nanzas guia práctica, 1998.

[3] Benneth Christiansson. GoF Design Patterns - with examples using Java and UML2.2008.

[4] DIAN. Dian, Mayo 2015. www.dian.gov.co.

[5] Eclipse. Rup openup, Mayo 2015. http://epf.eclipse.org/wikis/openup/.

[6] Factory. Software de compras e importaciones, Mayo 2015.http://www.factory.com.co/software-erp/software-mrp-ii/software-de-compras-e-importaciones.

[7] The Open Group. Archimate® 2.0 speci�cation, Julio 2015.http://pubs.opengroup.org/architecture/archimate2-doc/.

[8] The Open Group. The open group, Julio 2015. http://www.opengroup.org/.

[9] The Open Group. Togaf® version 9.1, Mayo 2015.http://pubs.opengroup.org/architecture/togaf9-doc/arch/.

[10] Helisa/NIIF. Importaciones, Mayo 2015. http://helisa.com/importacion.php.

[11] MiPymes. Comercio exterior, Enero 2015. www.mipymes.gov.co.

[12] Oracle. Conozca más sobre la tecnología java, Junio 2015.https://www.java.com/es/about/.

[13] Oracle. Enterprise javabeans technology, Junio 2015.http://www.oracle.com/technetwork/java/javaee/ejb/index.html.

[14] Oracle. Java enterprise edition at a glance, Junio 2015.http://www.oracle.com/technetwork/java/javaee/overview/index.html.

[15] Oracle. Java server faces technology, Junio 2015.http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html.

[16] Oracle. Java standart edition documentation, Junio 2015.http://www.oracle.com/technetwork/java/javase/documentation/index.html.

[17] Gilbert Raymond Philippe Desfray. Modeling Enterprise Architecture with Togaf.Morgan Koufman, 2014.

102

Bibliografía

[18] Postresql. About postgresql, Julio 2015. http://www.postgresql.org/about/.

[19] ProExport. Proexport - publicaciones, Mayo 2015.http://www.procolombia.co/publicaciones.

[20] Inc. Red Hat. All wild�y 8 documentation, Mayo 2015.https://docs.jboss.org/author/display/WFLY8/AllWildFly8documentation.

[21] Tango. Importaciones, Mayo 2015. http://www.axoft.com/tango/software-de-gestion/funcionalidad/importaciones.php.

[22] Erich Gamma Richard Helm Ralph Johnson John Vlissides. Design Patterns Ele-

ments of Reusable Object Oriented Software. 1980.

103

Parte IV.

ANEXOS

104

A. Anexos Meta-modelos de las Vistasde Archimate

A.1. Meta-modelo Punto de Vista de Organización

Anexo Figura A.1: Meta-modelo punto de vista de organización. Fuente: Propia

105

A. Anexos Meta-modelos de las Vistas de Archimate

A.2. Meta-modelo Punto de Vista de Colaboración de

Actores

Anexo Figura A.2: Meta-modelo Punto de Vista de Colaboración de Actores. Fuente:Propia

A.3. Meta-modelo Punto de Vista de Funciones de

Negocio

Anexo Figura A.3: Meta-modelo de Punto de Vista de Funciones de Negocio. Fuente:Propia

106


A.4. Meta-modelo Punto de Vista de Proceso de Negocio

Anexo Figura A.4: Meta-modelo de Punto de Vista de Proceso de Negocio. Fuente:Propia

107


A.5. Meta-modelo Punto de Vista de Cooperación de

Procesos de Negocio

Anexo Figura A.5: Meta-modelo de Punto de Vista de Cooperación de Procesos deNegocio. Fuente: Propia

A.6. Meta-modelo Punto de Vista del Producto

Anexo Figura A.6: Meta-modelo de Punto de Vista del Producto. Fuente: Propia

108


A.7. Meta-modelo Punto de Vista de Comportamiento de

Aplicación

Anexo Figura A.7: Meta-modelo de Punto de Vista de Comportamiento de Aplicación.Fuente: Propia

A.8. Meta-modelo Punto de Vista de Colaboración de

Aplicación

Anexo Figura A.8: Meta-modelo de Punto de Vista de Colaboración de Aplicación.Fuente: Propia

109


A.9. Meta-modelo Punto de Vista de Estructura de

Aplicación

Anexo Figura A.9: Meta-modelo de Punto de Vista de Estructura de Aplicación.Fuente: Propia

A.10. Meta-modelo Punto de Vista de Uso de Aplicación

Anexo Figura A.10: Meta-modelo de Punto de Vista de Uso de Aplicación. Fuente:Propia

110


A.11. Meta-modelo Punto de Vista de Infraestructura

Anexo Figura A.11: Meta-modelo de Punto de Vista de Infraestructura. Fuente: Propia

A.12. Meta-modelo Punto de Vista de Uso de

Infraestructura

Anexo Figura A.12: Meta-modelo de Punto de Vista de Uso de Infraestructura. Fuente:Propia

111


A.13. Meta-modelo Punto de Vista de Implementación y

Despliegue

Anexo Figura A.13: Meta-modelo de Punto de Vista de Implementación y Despliegue.Fuente: Propia

112


A.14. Meta-modelo Punto de Vista de Estructura de la

Información

Anexo Figura A.14: Meta-modelo de Punto de Vista de Estructura de la Información.Fuente: Propia

A.15. Meta-modelo Punto de Vista de Realización de

Servicios

113


Anexo Figura A.15: Meta-modelo de Punto de Vista de Realización de Servicios.Fuente: Propia

A.16. Meta-modelo Punto de Vista de Capas

Anexo Figura A.16: Meta-modelo de Punto de Vista de Capas. Fuente: Propia

A.17. Meta-modelo Punto de Vista de Implicados

Anexo Figura A.17: Meta-modelo de Punto de Vista de Implicados. Fuente: Propia

114



Objetivos

Anexo Figura A.18: Meta-modelo de Punto de Vista de Realización de Objetivos.Fuente: Propia

A.19. Meta-modelo Punto de Vista de Contribución de

Objetivos

Anexo Figura A.19: Meta-modelo de Punto de Vista de Contribución de Objetivos.Fuente: Propia

115


A.20. Meta-modelo Punto de Vista de Principios

Anexo Figura A.20: Meta-modelo de Punto de Vista de Principios. Fuente: Propia


Requisitos

Anexo Figura A.21: Meta-modelo de Punto de Vista de Realización de Requisitos.Fuente: Propia

116


A.22. Meta-modelo Punto de Vista de Motivación

Anexo Figura A.22: Meta-modelo de Punto de Vista de Motivación. Fuente: Propia

A.23. Meta-modelo Punto de Vista de Proyecto

Anexo Figura A.23: Meta-modelo de Punto de Vista de Proyecto. Fuente: Propia

A.24. Meta-modelo Punto de Vista de Migración

117


Anexo Figura A.24: Meta-modelo de Punto de Vista de Migración. Fuente: Propia

A.25. Meta-modelo Punto de Vista de Implementación y

Migración

Anexo Figura A.25: Meta-modelo de Punto de Vista de Implementación y Migración.Fuente: Propia

118

B. Anexo Patrones de Diseño

B.1. Estructura Patrón Singleton

Anexo Figura B.1: Estructura Patrón Singleton: Fuente: Propia

B.2. Estructura Patrón Constructor

Anexo Figura B.2: Estructura Patrón Constructor. Fuente Propia

119


B.3. Estructura Patrón Método Fábrica

Anexo Figura B.3: Estructura Patrón Método Fábrica. Fuente Propia

B.4. Estructura Patrón Prototipo

Anexo Figura B.4: Estructura Patrón Prototipo. Fuente Propia

120


B.5. Estructura Patrón Puente

Anexo Figura B.5: Estructura Patrón Puente. Fuente Propia

B.6. Estructura Patrón Componente

Anexo Figura B.6: Estructura Patrón Componente. Fuente Propia

121


B.7. Estructura Patrón Decorador

Anexo Figura B.7: Estructura Patrón Decorador. Fuente Propia

B.8. Estructura Patrón Fachada

Anexo Figura B.8: Estructura Patrón Fachada. Fuente Propia

122


B.9. Estructura Patrón Proxy

Anexo Figura B.9: Estructura Patrón Proxy. Fuente Propia

B.10. Estructura Patrón Cadena de Responsabilidad

Anexo Figura B.10: Estructura Patrón Cadena de Responsabilidad. Fuente Propia

123


B.11. Estructura Patrón Comando

Anexo Figura B.11: Estructura Patrón Comando. Fuente Propia

B.12. Estructura Patrón Iterador

Anexo Figura B.12: Estructura Patrón Iterador. Fuente Propia

124


B.13. Estructura Patrón Estado

Anexo Figura B.13: Estructura Patrón Estado. Fuente Propia

B.14. Estructura Patrón Mediador

Anexo Figura B.14: Estructura Patrón Mediador. Fuente Propia

125


B.15. Estructura Patrón Observador

Anexo Figura B.15: Estructura Patrón Observador. Fuente Propia

B.16. Estructura Patrón Estrategia

Anexo Figura B.16: Estructura Patrón Estrategia. Fuente Propia

126

C. Anexo Entrevista a Expertos

Se realiza una entrevista a una profesional en comercio exterior, la cual nos da unadescripción sobre el dominio del negocio. Esta entrevista da las pautas iniciales para elinicio del modelamiento del negocio.

Profesional Entrevistada:

Nombre: Sindy Yuliana Rincón Montealegre

Per�l: Un año de experiencia realizando procesos de importación de insumos. Profesionalde Relaciones Económicas Internacionales de la Universidad Autónoma de Colombia.Estudiante de especialización en Gerencia en Comercio Exterior de la Universidad delRosario.

El objetivo del presente documento es de recopilar información sobre el proceso de im-portación de insumos; mediante la aplicación de una serie de preguntas:

¾Quien es la persona,per�l o área es la encargada de recibir la nueva orden de compra?

R. PROFESIONAL DE COMERCIO EXTERIOR

¾Cuales son los atributos o información importante en una orden de compra?

R. PRECIO CANTIDAD TERMINO DE NEGOCIACIÓN FECHA DE DESPACHOTERMINO DE PAGO

¾Además del documento de orden de compra, se adjuntan a esta otros documentos quebrinden ayuda o soporte para el proceso de importación de los insumos?, si la preguntaanterior es a�rmativa, enumere los documentos.

R. AL PROVEEDOR: ORDEN DE COMPRA

PARA NACIONALIZACIÓN:

FACTURA COMERCIAL CON INFORMACIÓN COMPLETA

LISTA DE EMPAQUE

BL ORIGINAL

CERTIFICADOS DE ORIGEN

CERTIFICADO DE ANÁLISIS SI APLICA

CERTIFICADOS DE FUMIGACIÓN DE PALLETS SI APLICA

127


¾Presenta la empresa un registro de la información de contacto y ubicación de los pro-veedores con los que han realizado procesos de compra anteriores?

R. SI, GERENCIA Y EL DEPARTAMENTO DE COMERCIO EXTERIORMANEJANUNA BASE DE DATOS

¾Si la pregunta anterior es a�rmativa; en qué formato se encuentra registrada la infor-mación de los proveedores?

R. EXCEL Y EL SISTEMA CONTABLE

¾cuáles son las pautas, eventos o subprocesos que se realizan para completar la negocia-ción?

R. PAUTAS:

PRECIO

INCONTERM

TERMINO DE PAGO

DISPONIBILIDAD DEL PRODUCTO

APOYO TÉCNICO

¾Se generan documentos durante la negociación con el proveedor? cuales son:

R. CONTRATO POR ORDEN DE COMPRA

¾Presenta la empresa un registro de la información de contacto y ubicación de los agentesmarítimos con los que ha realizado contratos de transporte?

R. SI ESTOS SON MANEJADOS POR EL DEPARTAMENTO DE COMERCIO EX-TERIOR

¾Si la pregunta anterior es a�rmativa; en qué formato se encuentra registrada la infor-mación de los agentes marítimos?

R. NO TENEMOS BASE DE DATOS, LOS CONTACTOS SON DE ACUERDO ALSERVICIO QUE NOS HAN PRESTADO

¾Durante el proceso de transportar la mercancía desde el puerto de origen al puerto dedestino, cuáles son las actividades o tareas que se realizan?

R. SEGUIMIENTO DE LA MERCANCÍA A TRAVÉS DE LAS PÁGINAS DE LASNAVIERAS, Y CON INFORMACIÓN DE LOS AGENTES, ESTAR PENDIENTE DERECIBIR LOS DOCUMENTOS ORIGINALES,

¾Se generan documentos durante el proceso de transporte de la mercancía para con elagente marítimo u otra entidad/organización? cuales son:

R. REALIZAR PODERES PARA LA AGENCIA DE ADUANAS ANTE LAS NAVIE-RAS Y GESTIONAR CON ESTA PAGOS PARA EL SERVICIO.

128


¾Presenta la empresa un registro de la información de contacto y ubicación de las enti-dades aduaneras del país?

R. GERENCIA FINANCIERA TIENE INFORMACIÓN DE LA ADUANAS Y ADE-MÁS NUESTRA AGENCIA DE ADUANAS ES NUESTRO PUENTE EN LAS OPE-RACIONES DE COMERCIO EXTERIOR

¾Si la pregunta anterior es a�rmativa; en qué formato se encuentra registrada la infor-mación de las entidades aduaneras del país?

R. NO LA TENGO DISPONIBLE, AUNQUE SERÍA MUY IMPORTANTE TENERLA

¾Durante el proceso de nacionalización de la mercancía, cuáles son las actividades o tareasque se realizan?

R. ACTIVIDADES:

PAGOS A LAS NAVIERAS

PAGOS A LA AGENCIA DE ADUANAS

PAGOS A LA ADUANA NACIONAL

ENVÍO DE DOCUMENTOS

¾Se generan documentos durante el proceso de nacionalización de la mercancía? cualesson:

R. DOCUMENTOS:

DECLARACIÓN DE IMPORTACIÓN Y DECLARACIÓN ANDINA DE VALOR

FACTURAS DE PUERTO

FACTURA DE LA AGENCIA DE ADUANAS

C.C. 1010201263

129

D. Anexo: Código Fuente del Prototipo

El código fuente del prototipo se encuentra en el siguiente archivo anexo:

RojasManiosSantiagoAnexo-D1.zip

130

E. Anexo: Código Fuente Patrones deDiseño

El código fuente de los patrones de diseño modelados se encuentran en el archivo:

RojasManiosSantiagoAnexo-E1.zip

131

PROTOTIPO DE AUTOMATIZACIÓN DEL PROCESO DE...

Documents

Transcript of PROTOTIPO DE AUTOMATIZACIÓN DEL PROCESO DE...