DISENO DE ARQUITECTURA EMPRESARIAL˜repository.udistrital.edu.co/bitstream/11349/5123/1... · diseno de arquitectura empresarial˜ caso de estudio: centro de inversiones empresariales

DISENO DE ARQUITECTURA EMPRESARIAL

CASO DE ESTUDIO: CENTRO DE INVERSIONESEMPRESARIALES LINEA DE NEGOCIO DE TRANSPORTE

PUBLICO INDIVIDUAL

Cesar Bolanos Cardozo

Giovanni Garcıa Rodrıguez

Directora: ALEXANDRA ABUCHAR

Revisor: SANDRO BOLANOS

22 de noviembre de 2016

2

Dedicatoria

Dedico de manera especial este trabajo a mi hija Angie, quien es mi motivacion para crecerdıa a dıa de forma profesional y personal; de igual forma a mi familia, quienes me han

apoyado e impulsado con sus palabras y companıa a lo largo del trayecto de laespecializacion, la cual es una meta mas para mi vida.

Un agradecimiento tambien a mis companeros de especializacion con quienes llevamos acabo un gran trabajo en equipo a lo largo de todo este proceso de forma muy responsable y

alegre dejando ası unos buenos lazos de amistad.

Finalmente agradecer al Centro de Inversiones Empresariales por brindarnos laoportunidad de realizar el presente proyecto en su companıa, y brindarnos toda la

informacion que se requirio, en aras de obtener un resultado satisfactorio de todo el trabajoque se llevo a cabo durante todo este 2016.

CESAR AUGUSTO BOLANOS CARDOZO

II

Dedicatoria

A mi esposa Margarita, quien me apoya con amor y sabidurıa.

A mi mama, papa y hermanos, quienes me alientan para seguir siendo una persona deejemplo.

A mis companeros de la especializacion de Ingenierıa de Software, profesionales ıntegros ygrandes personas, ahora buenos amigos.

A los profesores Alexandra Abuchar y Sandro Bolanos, por sus recomendaciones parasacar adelante este proyecto.

A la Empresa Centro de Inversiones Empresariales, que nos brindo la informacion queahora se traduce en herramientas para fortalecer sus procesos productivos.

Mother always said “my son, do the noble thing...”You have to finish what you started, no matter what, now sit, watch and learn...

“It’s not how long you live, but what your moral say”Can’t keep your part of the deal

So don’t say a word... don’t say a wordListening: “Don’t say a word” - Sonata Arctica

GIOVANNI GARCIA RODRIGUEZ

IV

INTRODUCCION

La oferta de taxis en Bogota para finales del ano 2015, fue de 51.523 vehıculos, de los cuales50.285 aparecen registrados en el censo oficial del Registro Distrital Automotor con nume-ro de orden, es decir, es la cantidad autorizada legalmente para operar dentro del DistritoCapital de la ciudad de Bogota; los otros 1.238 estan dentro del censo sin numero de ordenpero solo 350 de estos vehıculos tienen tarjeta de operacion, operan dentro del perımetrourbano pero sin la debida autorizacion por parte de Secretarıa de Movilidad [MOVILIDAD, ].Dentro del parque automotor bogotano, que es de 1’600.000 vehıculos aproximadamente, elsector de Transporte Publico Individual solo representa un 3 % de las opciones de movilidadque tienen los habitantes del Distrito [de Ambiente, 2016].

Muchos de estos automoviles de servicio publico son administrados por sus propietarios,quienes deben hacerle control y seguimiento a los gastos que presenta el vehıculo, el dine-ro obtenido producto de las carreras realizadas, ademas de tener confianza a que personacontratan como conductor y las consecuencias del ejercicio del oficio de ser taxista que estoconlleva: accidentes, seguros del vehıculo, seguros de responsabilidad civil, etc.

Dicho seguimiento que los propietarios le hacen a sus vehıculos es mas bien empırico, laadministracion de los taxis es precaria, se vive el dıa a dıa de lo que genere el vehıculo,pocas veces se tienen previsiones de dinero para solventar gastos que no se contemplan,como puede ser una reparacion de ultimo momento o cubrir los gastos de un accidente, nimucho menos se cuenta con un soporte tecnologico para medir como se comporta la inver-sion en estos automotores.

Muchas personas convierten este oficio en su manera de vivir y que mejor poder estable-cer lineamientos de administracion empresarial para un negocio que se convierte en unapequena empresa. Esta es la situacion que vive actualmente la empresa Centro de Inver-siones Empresariales en su lınea de negocio de Transporte Publico Independiente.

Considerando lo anterior, y conociendo el caso particular de la companıa Centro de In-versiones Empresariales, quien posee como una de sus lıneas de negocio el transportepublico independiente, trabaja prestando este servicio a la comunidad con una flotilla de

V

VI INTRODUCCION

taxis; el presente proyecto la tomara como caso de estudio para llevar a cabo por mediodel diseno de una Arquitectura Empresarial, y la generacion de un prototipo de software,la automatizacion de sus principales procesos administrativos, y de esta forma generarlesvalor tanto a nivel competitivo, como en pro de mejorar su operacion diaria.

Indice general

INTRODUCCION V

Indice de figuras XIII

Indice de tablas XVII

I CONTEXTUALIZACION DE LA INVESTIGACION 1

1. Descripcion de la Investigacion 31.1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2. Objetivos Especıfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1. My Taxi Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5.2. Vehicle Fleet Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.6. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6.1. Metodologıa en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6.2. ¿Que es Arquitectura? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.6.3. Contenido de TOGAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.6.4. Architecture Development Method . . . . . . . . . . . . . . . . . . . . . 111.6.5. Entity Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.7. Marco Espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.8. Marco Legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.8.1. Ley 769 de 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.8.2. Decreto 172 de 2001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.8.3. Decreto 400 de 2014 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.9. Metodologıa de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.9.1. Organizacion del trabajo de Grado . . . . . . . . . . . . . . . . . . . . . 181.9.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

VII

VIII INDICE GENERAL

1.9.3. Fuentes y tecnicas para la recoleccion de informacion . . . . . . . . . . 181.9.4. Tratamiento de la informacion . . . . . . . . . . . . . . . . . . . . . . . . 18

II DESARROLLO DE LA INVESTIGACION 21

2. Ejecucion del Proyecto 232.1. Fase I. Ingenierıa y analisis del sistema . . . . . . . . . . . . . . . . . . . . . . 232.2. Fase I. Requerimientos de software . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1. Login de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.2. Recuperacion de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.3. Gestion de Conductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.4. Gestion de Conductor - Retiro . . . . . . . . . . . . . . . . . . . . . . . 282.2.5. Gestion Licencia de Conduccion . . . . . . . . . . . . . . . . . . . . . . 292.2.6. Gestion de Vehıculos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.7. Gestion de Proveedores . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.8. Gestion de Soportes de mantenimiento . . . . . . . . . . . . . . . . . . 322.2.9. Gestion de Producido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.10. Gestion de Turnos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3. Fase I. Descripcion de la organizacion Centro de Inversiones Empresariales . 352.3.1. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.2. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.4. Matriz DOFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4. Fase II. Analisis de los requisitos de software . . . . . . . . . . . . . . . . . . . 372.5. Fase III. Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.5.1. Diseno de Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . 382.5.2. Diseno del modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6. Fase IV. Codificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.6.1. Implementacion del Modelo de Datos . . . . . . . . . . . . . . . . . . . 40

2.7. Fase IV. Generacion de prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . 412.7.1. Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.7.2. Modelo de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.7.3. Creacion de Controladores y Vistas . . . . . . . . . . . . . . . . . . . . 49

2.8. Fase IV. Aplicacion TaxiMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.8.1. Login de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.8.2. Modulo de Conductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.8.3. Modulo de Licencia de Conductor . . . . . . . . . . . . . . . . . . . . . 572.8.4. Modulo de Vehıculo y Propietarios . . . . . . . . . . . . . . . . . . . . . 602.8.5. Control de Turnos y Producido . . . . . . . . . . . . . . . . . . . . . . . 652.8.6. Proveedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672.8.7. Repuestos y Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.8.8. Mantenimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

2.9. Fase V. Pruebas y Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . 74

INDICE GENERAL IX

III CAPAS DE DISENO DE ARQUITECTURA EMPRESARIAL 75

3. Diseno de Arquitectura de Negocio 773.1. Punto de vista organizacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.1.1. Metamodelo P.V Organizacional . . . . . . . . . . . . . . . . . . . . . . 773.1.2. Aplicacion P.V Organizacional . . . . . . . . . . . . . . . . . . . . . . . . 77

3.2. Punto de vista de cooperacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.2.1. Metamodelo P.V cooperacion . . . . . . . . . . . . . . . . . . . . . . . . 793.2.2. Aplicacion P.V Cooperacion . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.3. Punto de vista de funcion de negocio . . . . . . . . . . . . . . . . . . . . . . . . 813.3.1. Metamodelo P.V Funcion de negocio . . . . . . . . . . . . . . . . . . . . 813.3.2. Aplicacion P.V Funcion de negocio . . . . . . . . . . . . . . . . . . . . . 81

3.4. Punto de vista de proceso de negocio . . . . . . . . . . . . . . . . . . . . . . . 833.4.1. Metamodelo P.V Proceso de negocio . . . . . . . . . . . . . . . . . . . . 833.4.2. Aplicacion P.V Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . 84

3.5. Punto de vista de Cooperacion de Proceso de Negocio . . . . . . . . . . . . . 853.5.1. Metamodelo P.V Cooperacion de Proceso de Negocio . . . . . . . . . . 853.5.2. Aplicacion P.V de Cooperacion de Proceso de Negocio . . . . . . . . . 85

3.6. Punto de vista de Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.6.1. Metamodelo de P.V de producto . . . . . . . . . . . . . . . . . . . . . . 863.6.2. Aplicacion de P.V de Producto . . . . . . . . . . . . . . . . . . . . . . . 86

4. Diseno de Arquitectura de Aplicacion 894.1. P.V. Comportamiento de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.1.1. Metamodelo de P.V de Comportamiento de Aplicacion . . . . . . . . . . 894.1.2. Aplicacion P.V de Comportamiento de Aplicacion . . . . . . . . . . . . . 90

4.2. P.V. Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.2.1. Metamodelo de P.V de Cooperacion de Aplicacion . . . . . . . . . . . . 904.2.2. Aplicacion P.V de Cooperacion de Aplicacion . . . . . . . . . . . . . . . 91

4.3. P.V. Estructura de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.3.1. Metamodelo de P.V de Estructura de Aplicacion . . . . . . . . . . . . . 924.3.2. Aplicacion P.V de Cooperacion de Aplicacion . . . . . . . . . . . . . . . 92

4.4. P.V. Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.4.1. Metamodelo de P.V de Uso de Aplicacion . . . . . . . . . . . . . . . . . 934.4.2. Aplicacion P.V de Cooperacion de Aplicacion . . . . . . . . . . . . . . . 94

5. Diseno de Arquitectura de Infraestructura y Datos 955.1. P.V. de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.1.1. Metamodelo de P.V de Infraestructura . . . . . . . . . . . . . . . . . . . 955.1.2. Aplicacion P.V de Infraestructura . . . . . . . . . . . . . . . . . . . . . . 95

5.2. P.V. de Uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.2.1. Metamodelo de P.V de Uso de Infraestructura . . . . . . . . . . . . . . . 975.2.2. Aplicacion P.V de Uso de Infraestructura . . . . . . . . . . . . . . . . . . 97

5.3. P.V. Organizacion e implementacion . . . . . . . . . . . . . . . . . . . . . . . . 98

X INDICE GENERAL

5.3.1. Metamodelo de P.V de Organizacion e implementacion . . . . . . . . . 985.3.2. Aplicacion P.V de Organizacion e implementacion . . . . . . . . . . . . 98

5.4. P.V. Estructura de Informacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.4.1. Metamodelo de P.V de Estructura de Informacion . . . . . . . . . . . . . 995.4.2. Aplicacion P.V de Estructura de Informacion . . . . . . . . . . . . . . . . 100

5.5. P.V. de Realizacion del Servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.5.1. Metamodelo de P.V de Realizacion del Servicio . . . . . . . . . . . . . . 1015.5.2. Aplicacion P.V de Realizacion del Servicio . . . . . . . . . . . . . . . . . 101

5.6. P.V. de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.6.1. Metamodelo de P.V de Capas . . . . . . . . . . . . . . . . . . . . . . . . 1035.6.2. Aplicacion P.V de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6. Diseno de Arquitectura Motivacional 1056.1. P.V. de Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.1.1. Metamodelo de P.V de Stakeholder . . . . . . . . . . . . . . . . . . . . 1056.1.2. Aplicacion de P.V de Stakeholder . . . . . . . . . . . . . . . . . . . . . . 106

6.2. P.V. de Realizacion de Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.2.1. Metamodelo de P.V de Realizacion de Objetivos . . . . . . . . . . . . . 1066.2.2. Aplicacion de P.V. de Realizacion de Objetivos . . . . . . . . . . . . . . 106

6.3. P.V. de Contribucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.3.1. Metamodelo de P.V de Contribucion . . . . . . . . . . . . . . . . . . . . 1086.3.2. Aplicacion P.V de Contribucion . . . . . . . . . . . . . . . . . . . . . . . 108

6.4. P.V. de Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.4.1. Metamodelo de P.V de Principios . . . . . . . . . . . . . . . . . . . . . . 1086.4.2. Aplicacion P.V de Principios . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.5. P.V. de Realizacion de Requerimientos . . . . . . . . . . . . . . . . . . . . . . . 1106.5.1. Metamodelo de P.V de Realizacion de Requerimientos . . . . . . . . . 1106.5.2. Aplicacion P.V de Realizacion de Requerimientos . . . . . . . . . . . . 111

6.6. P.V. de Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116.6.1. Metamodelo de P.V de Motivacion . . . . . . . . . . . . . . . . . . . . . 1116.6.2. Aplicacion P.V de Motivacion . . . . . . . . . . . . . . . . . . . . . . . . 112

7. Diseno de Arquitectura de Proyecto 1137.1. P.V. de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.1.1. Metamodelo de P.V de Proyecto . . . . . . . . . . . . . . . . . . . . . . 1137.1.2. Aplicacion de P.V de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . 113

8. Diseno de Arquitectura de Migracion 1158.1. P.V. de Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.1.1. Metamodelo de P.V de Migracion . . . . . . . . . . . . . . . . . . . . . . 1158.1.2. Aplicacion de P.V de Migracion . . . . . . . . . . . . . . . . . . . . . . . 115

8.2. P.V. de Migracion e Implementacion . . . . . . . . . . . . . . . . . . . . . . . . 1168.2.1. Metamodelo de P.V de Migracion e Implementacion . . . . . . . . . . . 1168.2.2. Aplicacion de P.V de Migracion e Implementacion . . . . . . . . . . . . 117

INDICE GENERAL XI

IV CIERRE DE LA INVESTIGACION 119

9. Conclusiones 121

10.Prospectiva del trabajo de grado 12310.1.Lıneas de investigacion futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . 12310.2.Trabajos de investigacion futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Appendices 125

Apendice A. Resumen PESI para C.I.E. 125

Apendice B. Diccionario de Datos 133

Bibliografıa 137

XII INDICE GENERAL

Indice de figuras

1.1. My Taxi Manager - Fuente: http://www.taxicabmanager.com . . . . . . . . . . . 61.2. Vehicle Fleet Manager - Fuente: http://www.vinitysoft.com/es/fleet-management-

software-4-0/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3. Metodologıa en Cascada Mejorada - Fuente: los autores, Diseno original:

http://ciclodevidasoft.blogspot.com.co/2012/07/modelos.html . . . . . . . . . . 91.4. Ciclo de ADM - Fuente: [The Open Group, 2009] . . . . . . . . . . . . . . . . . 121.5. Escenarios de Entity Framework - Fuente [Tutorial, ] . . . . . . . . . . . . . . . 141.6. Object/Relational Mapping - Fuente [Tutorial, ] . . . . . . . . . . . . . . . . . . 151.7. Escenarios de Entity Framework - Fuente [Tutorial, ] . . . . . . . . . . . . . . . 16

2.1. Matriz DOFA Centro de Inversiones Empresariales - Fuente: Los autores . . . 362.2. Diseno del modelo de datos - Fuente: Los autores . . . . . . . . . . . . . . . . 392.3. Implementacion del Modelo de Datos - Fuente: Los autores . . . . . . . . . . . 402.4. Estructura tıpica de una aplicacion web - Fuente: [Team, 2009] . . . . . . . . . 412.5. Estructura adoptada para Taximonitor - Fuente: [Team, 2009] . . . . . . . . . . 422.6. Nuevo proyecto Web - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 432.7. Nuevo proyecto Web - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 442.8. La aplicacion se ha generado - Fuente: Los autores . . . . . . . . . . . . . . . 442.9. Explorador de solucion y las tres carpetas de MVC - Fuente: Los autores . . . 452.10.Agregar nuevo Entity Model - Fuente: Los autores . . . . . . . . . . . . . . . . 462.11.Asistente para Entity Data Model - Database first - Fuente: Los autores . . . . 462.12.Cadena de conexion para el modelo de entidades y mapeo de BD . . . . . . . 472.13.Entidad ControlTurnos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 472.14.Diagrama de entidades generado por Entity Framework - Fuente: Los autores . 482.15.Agregar nuevo controlador por scaffolding - Fuente: Los autores . . . . . . . . 492.16.Condiciones para generar Controlador y Vista de Conductor - Fuente: Los

autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.17.Controlador y Vista para Conductor - Fuente: Los autores . . . . . . . . . . . . 502.18.Vista para Index de Conductor - Fuente: Los autores . . . . . . . . . . . . . . . 512.19.Vista para Create de Conductor - Fuente: Los autores . . . . . . . . . . . . . . 512.20.Vista para Edit de Conductor - Fuente: Los autores . . . . . . . . . . . . . . . . 522.21.Vista de Detalles de Conductor - Fuente: Los autores . . . . . . . . . . . . . . 522.22.Vista de Login - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . . . 53

XIII

XIV INDICE DE FIGURAS

2.23.Vista Home despues de Login - Fuente: Los autores . . . . . . . . . . . . . . . 532.24.Listado de Conductores - Fuente: Los autores . . . . . . . . . . . . . . . . . . 542.25.Creacion de nuevo Conductor - Fuente: Los autores . . . . . . . . . . . . . . . 552.26.Edicion de Conductor - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 562.27.Detalles de Conductor - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 562.28.Listado de Licencias de Conductor - Fuente: Los autores . . . . . . . . . . . . 572.29.Crear nueva Licencia de Conductor - Fuente: Los autores . . . . . . . . . . . . 582.30.Editar Licencia de Conductor - Fuente: Los autores . . . . . . . . . . . . . . . . 582.31.Borrar Licencia de Conductor - Fuente: Los autores . . . . . . . . . . . . . . . 592.32.Listado de Propietarios - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 602.33.Creacion de Propietario - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 602.34.Edicion de Propietario - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 612.35.Borrado de Propietario - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 612.36.Listado de Marcas de Vehıculos - Fuente: Los autores . . . . . . . . . . . . . . 622.37.Creacion de Marcas de Vehıculo - Fuente: Los autores . . . . . . . . . . . . . 622.38.Listado de Vehıculos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 632.39.Creacion de Vehıculos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 632.40.Edicion de Vehıculos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 642.41.Borrado de Vehıculos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 652.42.Listado de Turnos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . 652.43.Editar Turno - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . . . . 662.44.Editar Turno - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . . . . 672.45.Borrado de Turno - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . 672.46.Listado de Proveedores - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 682.47.Creacion de Proveedor - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 682.48.Editar proveedor - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . . 692.49.Borrar proveedor - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . . 692.50.Listado de Repuestos - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . 702.51.Crear un nuevo repuesto - Fuente: Los autores . . . . . . . . . . . . . . . . . . 712.52.Listado de Servicios - Fuente: Los autores . . . . . . . . . . . . . . . . . . . . . 712.53.Crear un nuevo servicio - Fuente: Los autores . . . . . . . . . . . . . . . . . . . 722.54.Listado de Mantenimientos - Fuente: Los autores . . . . . . . . . . . . . . . . . 722.55.Crear nuevo registro de Mantenimiento - Fuente: Los autores . . . . . . . . . . 732.56.Editar nuevo registro de Mantenimiento - Fuente: Los autores . . . . . . . . . . 732.57.Borrar un registro de Mantenimiento - Fuente: Los autores . . . . . . . . . . . 74

3.1. Metamodelo Punto de Vista Organizacional - Fuente: Sandro Bolanos . . . . . 773.2. Punto de Vista Organizacional - Fuente: los autores . . . . . . . . . . . . . . . 783.3. Metamodelo Punto de Vista Cooperacion - Fuente: Sandro Bolanos . . . . . . 793.4. Punto de Vista Cooperacion - Fuente: los autores . . . . . . . . . . . . . . . . 803.5. Metamodelo Punto de Vista de Funcion de Negocio - Fuente: Sandro Bolanos 813.6. Punto de Vista de Funcion de Negocio - Fuente: Los autores . . . . . . . . . . 823.7. Metamodelo Punto de Vista Proceso de Negocio - Fuente: Sandro Bolanos . . 833.8. Punto de Vista Proceso de Negocio - Fuente: los autores . . . . . . . . . . . . 84

INDICE DE FIGURAS XV

3.9. Punto de Vista de Cooperacion de Proceso de Negocio - Fuente: los autores . 853.10.Metamodelo Punto de Vista de Producto - Fuente: Sandro Bolanos . . . . . . . 863.11.Punto de Vista de Producto - Fuente: los autores . . . . . . . . . . . . . . . . . 87

4.1. Metamodelo Punto de Vista de Comportamiento de Aplicacion - Fuente: San-dro Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.2. Punto de vista Comportamiento de Aplicacion - Fuente: los autores . . . . . . 904.3. Metamodelo Punto de Vista de Cooperacion de Aplicacion - Fuente: Sandro

Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.4. Punto de vista Cooperacion de Aplicacion - Fuente: los autores . . . . . . . . . 914.5. Metamodelo Punto de Vista de Estructura de Aplicacion - Fuente: Sandro

Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.6. Punto de Vista de Estructura de Aplicacion - Fuente: los autores . . . . . . . . 934.7. Metamodelo Punto de vista de Uso de Aplicacion - Fuente: Sandro Bolanos . . 944.8. Punto de Vista de Uso de Aplicacion - Fuente: los autores . . . . . . . . . . . . 94

5.1. Metamodelo Punto de Vista de Infraestructura - Fuente: Sandro Bolanos . . . 965.2. Punto de Vista de Infraestructura - Fuente: los autores . . . . . . . . . . . . . . 965.3. Metamodelo Punto de Vista de Uso de Infraestructura - Fuente: Sandro Bolanos 975.4. Punto de Vista de Uso de infraestructura - Fuente: los autores . . . . . . . . . 985.5. Metamodelo Punto de Vista de Organizacion e Implementacion - Fuente: San-

dro Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.6. Punto de Vista de Organizacion e Implementacion - Fuente: los autores . . . . 1005.7. Metamodelo Punto de Vista de Estructura de Informacion - Fuente: Sandro

Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.8. Punto de Vista de Estructura de Informacion - Fuente: los autores . . . . . . . 1015.9. Metamodelo Punto de Vista de Realizacion del Servicio - Fuente: Sandro Bo-

lanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.10.Punto de Vista de Realizacion del Servicio - Fuente: los autores . . . . . . . . 1025.11.Metamodelo Punto de Vista de Capas - Fuente: Sandro Bolanos . . . . . . . . 1035.12.Punto de Vista de Capas - Fuente: los autores . . . . . . . . . . . . . . . . . . 104

6.1. Metamodelo Punto de Vista de Stakeholder - Fuente: Sandro Bolanos . . . . . 1056.2. Punto de Vista de Stakeholder - Fuente: los autores . . . . . . . . . . . . . . . 1066.3. Metamodelo Punto de Vista de Realizacion de Objetivos - Fuente: Sandro

Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.4. Punto de Vista de Realizacion de Objetivos - Fuente: los autores . . . . . . . . 1076.5. Metamodelo Punto de Vista de Contribucion - Fuente: Sandro Bolanos . . . . 1086.6. Punto de Vista de Contribucion - Fuente: los autores . . . . . . . . . . . . . . . 1096.7. Metamodelo Punto de Vista de Principios - Fuente: Sandro Bolanos . . . . . . 1096.8. Punto de Vista de Principios - Fuente: los autores . . . . . . . . . . . . . . . . 1106.9. Metamodelo Punto de Vista de Realizacion de Requerimientos - Fuente: San-

dro Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.10.Punto de Vista de Realizacion de Requerimientos - Fuente: los autores . . . . 111

XVI INDICE DE FIGURAS

6.11.Metamodelo Punto de Vista de Motivacion - Fuente: Sandro Bolanos . . . . . . 1126.12.Punto de Vista de Motivacion - Fuente: los autores . . . . . . . . . . . . . . . . 112

7.1. Metamodelo Punto de vista de Proyecto - Fuente: Sandro Bolanos . . . . . . . 1137.2. Punto de vista de Proyecto - Fuente: los autores . . . . . . . . . . . . . . . . . 114

8.1. Metamodelo Punto de vista de Migracion - Fuente: Sandro Bolanos . . . . . . 1158.2. Punto de vista de Migracion - Fuente: los autores . . . . . . . . . . . . . . . . . 1168.3. Metamodelo Punto de vista de Migracion e Implementacion - Fuente: Sandro

Bolanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.4. Punto de vista de Migracion e Implementacion - Fuente: los autores . . . . . . 117

Indice de tablas

1.1. Tipos de arquitectura soportados por TOGAF . . . . . . . . . . . . . . . . . . . 11

2.2. Requerimiento 001 - Login de Usuario . . . . . . . . . . . . . . . . . . . . . . . 252.4. Requerimiento 002 - Recuperacion de Login . . . . . . . . . . . . . . . . . . . 262.6. Requerimiento 003 - Gestion de Conductor . . . . . . . . . . . . . . . . . . . . 272.8. Requerimiento 004 - Retiro de Conductor . . . . . . . . . . . . . . . . . . . . . 282.10.Requerimiento 005 - Gestion de licencia de conduccion . . . . . . . . . . . . . 292.12.Requerimiento 006 - Gestion de vehıculos . . . . . . . . . . . . . . . . . . . . . 302.14.Requerimiento 007 - Gestion de Proveedores . . . . . . . . . . . . . . . . . . . 312.16.Requerimiento 008 - Gestion de Soportes de mantenimiento . . . . . . . . . . 322.18.Requerimiento 009 - Gestion de Producido . . . . . . . . . . . . . . . . . . . . 332.20.Requerimiento 010 - Gestion de Turnos . . . . . . . . . . . . . . . . . . . . . . 34

XVII

XVIII INDICE DE TABLAS

Parte I

CONTEXTUALIZACION DE LAINVESTIGACION

1

Capıtulo 1

Descripcion de la Investigacion

1.1. Planteamiento del Problema

Centro de Inversiones Empresariales es una companıa ubicada en Bogota en el barrio Ri-caurte, fundada en el ano 2010, con tres lıneas de negocio enfocadas en telecomunicacio-nes (venta de servicios y aparatos para telefonıa movil), ferrelectricos (venta y distribucionde material para la construccion) y transporte publico individual (vehıculos tipo taxi). Estaultima unidad de negocio se constituyo en octubre de 2013 como parte de una estrategia dediversificacion de inversiones por parte de los propietarios de la companıa y agregar activosy servicios a su portafolio actual.

La administracion de esta area la realiza un empleado de la companıa, y dentro de susfunciones esta recibir los vehıculos cuando los conductores terminan turno y coordinar elmantenimiento que corresponde en los dıas en que no opera el vehıculo; el registro de losgastos en que incurre el vehıculo y el recaudo de dinero producido en los diferentes turnosde los automotores es muy limitado y solo se incluye en la contabilidad general de la em-presa. No se toma al detalle las eventualidades que pueden surgir en la cotidianeidad ni seusa la poca informacion que se recopila para establecer planes de accion o estrategias parasalvaguardar la inversion de los vehıculos.

Ademas de eso, el servicio de transporte publico individual en el Distrito Capital no pasa porsus mejores momentos: la percepcion de la ciudadanıa no es buena, 5 de cada 10 usuariosde taxi no estan satisfechos con el servicio de taxi. Algunas de las razones expuestas coneste bajo nivel de satisfaccion serıan que los tiempos de desplazamiento han aumentadodebido al trafico de la ciudad en horas pico, el trato inadecuado de los conductores hacialos pasajeros, la inseguridad, entre otros [Vamos, ]. La presencia de otras alternativas detransporte individual como Uber, obliga a replantear el esquema de transporte actual frentea nuevas exigencias de los usuarios hacia las empresas prestadores de dicho servicio.

3

4 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION

Los elementos expuestos, ya sean externos o internos, pueden en cualquier momento afec-tar el desempeno de la unidad de negocio de la companıa Centro de Inversiones Empre-sariales, y sin la preparacion adecuada, se puede correr el riesgo la unidad de negocio detransporte publico individual de no sea mas rentable y desaparecer como actividad economi-ca para la empresa.

1.2. Objetivos

1.2.1. Objetivo General

Disenar la arquitectura empresarial para la flotilla de taxis de la empresa Centro de Inversio-nes Empresariales, basado en la informacion del estado actual de companıa, para optimizarlos procesos administrativos internos de la companıa.

1.2.2. Objetivos Especıfico

Realizar un diagnostico de la unidad de negocio de transporte publico individual de la em-presa Centro de Inversiones Empresariales, por medio de tecnicas de levantamiento deinformacion con el fin de identificar fortalezas, oportunidades, debilidades y amenazas enlos procesos internos de la companıa.

Disenar la arquitectura empresarial usando el metodo ADM, para presentar como propuestade mejora en los procesos administrativos a la empresa Centro de Inversiones Empresaria-les.

Disenar el prototipo de una herramienta de software usando proceso en cascada, para pre-sentar como propuesta de mejora en los procesos administrativos a la empresa Centro deInversiones Empresariales.

1.3. Justificacion

Los retos que surgen para la lınea de negocio de taxis de la empresa Centro de InversionesEmpresariales son varios, iniciando con establecer elementos solidos administrativos quepermitan generar un control mas estricto, y poder medir elementos fundamentales de esteproceso.

1.4. HIPOTESIS 5

El apoyo de herramientas tecnologicas que le permitan recolectar la informacion para tomade decisiones, podra ser fundamental, ya que segun la Encuesta de percepcion Ciudadanade 2015, solo un 3 % de la poblacion de Bogota se moviliza en taxi, frente a un 35 % queusan Transmilenio, y un 17 % eligen como alternativa de transporte publico el Sistema Inte-grado de Transporte (SiTP); segun este panorama, la competencia frente a otras opcionesde movilidad es fuerte, y si no se cuenta con apoyo tecnologico, esta lınea de negocio per-dera rentabilidad [Vamos, ].

De acuerdo a lo mencionado, se quiere proporcionar por medio de este proyecto al Cen-tro de Inversiones Empresariales, el diseno de un prototipo de herramienta de software quele permita optimizar la forma en que administra su lınea de negocio enfocada en transpor-te publico individual, y ası pueda ser mas fructıfera su actividad economica y repercuta enmejora del servicio ofrecido.

1.4. Hipotesis

“Debido a la forma empırica que se administra la empresa Centro de Inversiones Empresa-riales en su lınea de negocio de Transporte Publico Independiente se presentan deficienciasen el aprovechamiento de los recursos”.

“Con una herramienta de software que apoye la labor administrativa del Centro de Inver-siones Empresariales en su lınea de negocio de Transporte Publico Independiente se hacemas eficiente y controlada dicha labor”.


1.5. Marco referencial

Dentro de las soluciones a nivel comercial que se encuentran en internet que podrıan aten-der el problema que aflige a la companıa Centro de Inversiones Empresariales, son solu-ciones de software creadas para mercados locales y especıficos de diferentes partes delmundo. A continuacion se nombraran algunas herramientas de software que permiten admi-nistrar y registrar las actividades alrededor del transporte publico individual de pasajeros.

1.5.1. My Taxi Manager

Es un portal web con origen en Australia que administran flotas de taxis y limosinas desde2005.

Figura 1.1: My Taxi Manager - Fuente: http://www.taxicabmanager.com

Algunas de sus caracterısticas son:

• Acceso a toda la informacion desde cualquier parte y desde cualquier dispositivo co-nectado a internet

• El portal web permite a los conductores ingresar incidencias y depositos de dinerodesde cualquier dispositivo conectado a internet.

• Administracion de planillas de turnos de los conductores

• Ingreso de festivos y bloques de tiempo de no disponibilidad para los conductores

• Administracion de comisiones, recaudo de impuestos y tarifas

1.5. MARCO REFERENCIAL 7

• Ingreso de gastos de operacion, vouchers de pago y de combustible

• Las finanzas de los conductores siempre estaran al dıa

• Carga de fotografıa para facil identificacion de contratos

• Pagos para los conductores se pueden subir a su banco desde el clic de un boton

• Acuerdo de deudas pueden ser configurados periodicamente, de un solo pago o pagopor turno.

• Envıo de mensajes SMS instantaneamente a los conductores

• Reporte de fallas y accidentes por parte de los conductores; se pueden subir las fotosde los accidentes.

• El mantenimiento de los vehıculos son precisos basado en lecturas del odometro(cuentakilometros), fecha o lo que suceda primero.

• Registro de los gastos y trazabilidad de la rentabilidad de los vehıculos

• Mantenimientos programados en las planillas de operacion.

• Notificaciones que apareceran en la pantalla para alertar renovaciones de seguro, re-gistros, inspecciones y otros.

• Los conductores pueden ingresar detalles del accidente en la escena

• Estatus de reclamos y seguimiento

• Manejo de etiquetas para categorizar elementos del vehıculo

1.5.2. Vehicle Fleet Manager

Es una herramienta desktop para Windows creada por Vinity Soft, companıa ubicada enQuebec, Canada. Permite administrar flotas de cualquier tipo de vehıculo, no importa si sonparticulares o de servicio publico

Permite registrar toda la informacion relacionada con el vehıculo: llantas, kilometraje reco-rrido, consumo de combustible, seguros, ordenes de trabajo, etc. Tambien permite llevar unregistro de la informacion de los conductores y su relacion con los vehıculos, turnos, etc.

Tambien se pueden generar reportes de todas los detalles que se registran en la herra-mienta.


Figura 1.2: Vehicle Fleet Manager - Fuente: http://www.vinitysoft.com/es/fleet-management-software-4-0/

1.6. Marco Conceptual

Dentro de la exploracion de metodologıas para el desarrollo del proyecto, se contemplara eluso de la metodologıa de desarrollo de software Cascada Mejorada, para la exploracion dela Arquitectura Empresarial se utilizara ADM y para la construccion del prototipo se utilizaraEntity Framework de Microsoft.

1.6.1. Metodologıa en cascada

Este es el mas basico de todos los modelos y ha servido como bloque de construccionpara los demas paradigmas de ciclo de vida. Esta basado en el ciclo convencional de unaingenierıa y su vision es muy simple: el desarrollo de software se debe realizar siguiendo unasecuencia de fases. Cada etapa tiene un conjunto de metas bien definidas y las actividadesdentro de cada una contribuyen a la satisfaccion de metas de esa fase o quizas a unasubsecuencia de metas de la misma [Sommerville, 2011]. El arquetipo del ciclo de vidaabarca las siguientes actividades:

1. Ingenierıa y Analisis del Sistema.Debido a que el software es siempre parte de un sistema mayor, el trabajo comienzaestableciendo los requisitos de todos los elementos del sistema y luego asignandoalgun subconjunto de estos requisitos al software.

2. Analisis de los requisitos del software

1.6. MARCO CONCEPTUAL 9

Figura 1.3: Metodologıa en Cascada Mejorada - Fuente: los autores, Diseno original:http://ciclodevidasoft.blogspot.com.co/2012/07/modelos.html

El proceso de recopilacion de los requisitos se centra e intensifica especialmente enel software. El ingeniero de software debe comprender el ambito de la informacion delsoftware ası como la funcion, el rendimiento y las interfaces requeridas.

3. DisenoEl diseno del software se enfoca en cuatro atributos distintos del programa; la estruc-tura de los datos, la arquitectura del software, el detalle procedimental y la caracteriza-cion de la interfaz. El proceso de diseno traduce los requisitos en una representaciondel software con la calidad requerida antes de que comience la codificacion.

4. CodificacionEl diseno debe traducirse en una forma legible para la maquina. Si el diseno se realizade una manera detallada, la codificacion puede realizarse mecanicamente.

5. PruebasUna vez que se ha generado el codigo comienza la prueba del programa. La pruebase centra en la logica interna del software y en las funciones externas, realizandopruebas que aseguren que la entrada definida produce los resultados que realmentese requieren.

6. MantenimientoEl software sufrira cambios despues de que se entrega al cliente. Los cambios ocu-


rriran debidos a que se haya encontrado errores, a que el software deba adaptarse acambios del entorno externo (sistema operativo o dispositivos perifericos) o a que elcliente requiera ampliaciones funcionales o del rendimiento.

En el modelo vemos una ventaja evidente y radica en su sencillez, ya que sigue los pasosintuitivos necesarios a la hora de desarrollar el software. Pero el modelo se aplica en uncontexto, ası que debemos atender tambien a el y saber que:

• Los proyectos reales raramente siguen el flujo secuencial que propone el modelo.Siempre hay iteraciones y se crean problemas en la aplicacion del paradigma.

• Normalmente, al principio, es difıcil para el cliente establecer todos los requisitos explıci-tamente. El ciclo de vida clasico lo requiere y tiene dificultades en acomodar posiblesincertidumbres que pueden existir al comienzo de muchos productos.

• El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto no estaradisponible una version operativa del programa. Un error importante que no pueda serdetectado hasta que el programa este funcionando, puede ser desastroso.

1.6.2. ¿Que es Arquitectura?

La ISO/IEC 42010:2007 define ((arquitectura)) como: ((La organizacion fundamental de unsistema, compuesta por sus componentes, las relaciones entre ellos y su entorno, ası comolos principios que gobiernan su diseno y evolucion.))

Para TOGAF, The Open Group Arquitecture Framework, tiene dos significados segun el con-texto [The Open Group, 2009]:

1. Una descripcion formal de un sistema, o un plano detallado del sistema a nivel de suscomponentes para orientar su implementacion.

2. La estructura de componentes, sus interrelaciones, y los principios y guıas que gobier-nan su diseno y evolucion a traves del tiempo.

¿Que es TOGAF?

TOGAF, de las siglas en ingles The Open Group Architecture Framework, es una metodo-logıa bastante popular para desarrollar Arquitectura Empresarial. Segun define [The Open Group, 2009],”TOGAF es una herramienta para asistir en la aceptacion, creacion, uso, y mantenimientode arquitecturas. Esta basado en un modelo iterativo de procesos apoyado por las mejorespracticas y un conjunto reutilizable de activos arquitectonicos existentes”


Clases de arquitectura con TOGAF

Los cuatro tipos de arquitectura que se muestran a continuacion, son aceptados como sub-conjuntos de Arquitectura Empresarial y que TOGAF soporta.

Tipo de Arquitectura Descripcion

Arquitectura de negocioLa estrategia de negocio, gobierno, organizacion yprocesos clave de la organizacion.

Arquitectura de datosLa estructura de datos logicos y fısicos que poseeuna organizacion y sus recursos de gestion de datos.

Arquitectura de AplicacionUn plano de las aplicaciones individuales a implementar,sus interacciones y sus relaciones con los procesos denegocio principales de la organizacion.

Arquitectura Tecnologica

Las capacidades de software y hardware que se requierenpara apoyar la implementacion de servicios de negocio,datos y aplicacion. Esto incluye infraestructura de IT,capa de mediacion, redes, comunicaciones, procesamientoy estandares.

Tabla 1.1: Tipos de arquitectura soportados por TOGAF

1.6.3. Contenido de TOGAF

TOGAF comprende los siguientes elementos

1. El metodo para desarrollo de la arquitectura, llamado ADM.

2. La Capacidad Arquitectonica, que se encarga de operar el metodo.

3. Posee tecnicas y guıas para apoyar al metodo.

4. El repositorio que genera contenido de los ıtems anteriores, clasificado segun el Con-tinuum Empresarial.

1.6.4. Architecture Development Method

Es un metodo para obtener Arquitecturas Empresariales especıficas para una organizaciony que esta disenado para responder a los requerimientos del negocio.

ADM describe los siguientes elementos:

1. Un modo confiable para desarrollar y utilizar un AE.


2. Un metodo para desarrollar arquitecturas en diferentes niveles, llamado conjunto dedominios de Arquitectura, divididas en negocio, aplicaciones, datos y tecnologıa. Esteconjunto le permite al arquitecto asegurar que los requerimientos se aborden de formaadecuada.

3. Un conjunto de guıas y tecnicas para el desarrollo de la arquitectura.

Fases de ADM

ADM consiste en una serie de fases que se desarrollan a traves de varios Dominios deArquitectura y le permite al arquitecto asegurar que un cumulo de requerimientos se abordenadecuadamente.

Figura 1.4: Ciclo de ADM - Fuente: [The Open Group, 2009]

Como se ilustra en la figura 3.1, las fases tienden a aplicarse de forma iterativa hasta darcon un refinamiento de Arquitectura adecuado para la organizacion. En cada ciclo se debehacer una validacion frecuente de los resultados respecto a los requerimientos originales,


tanto en ciclo completo como en alguna fase particular.

1. Fase Preliminar

Prepara a la organizacion para ejecutar de forma exitosa la Arquitectura Empresarial.Comprende actividades de iniciacion y preparacion requeridas para crear la CapacidadArquitectonica.

2. Gestion de Requerimientos

Son requerimientos del negocio que se identifican, se almacenan y se gestionan alingreso y egreso de las fases relevantes del ADM. En dichas fases se priorizan, seabordan o se eliminan dichos requerimientos.

3. Fase A - Vision de Arquitecrura Establece el alcance, las limitaciones y expectativasde un proyecto de AE. Crea la vision de arquitectura, identifica los stakeholders, validael contexto de negocio y crea la Declaracion de Trabajo de Arquitectura.

4. Fases de Arquitectura de negocio, de SI y de tecnologıa

Aunque son tres fases, se desarrollan cuatro dominios que son:

a) Fase B - Dominio de Negocio

b) Fase C - Dominio de Aplicaciones, contexto Sistema de informacion

c) Fase C - Dominio de Datos, contexto Sistema de informacion

d) Fase D - Tecnologıa

5. Fase E - Oportunidades y soluciones Realiza la planificacion de la implementacioninicial y la identificacion de medios de entrega para los Bloques de Construccion identi-ficacos en las fases anteriores. Si requiere un enfoque incremental, ayuda a identificarlas Arquitecturas de Transicion.

6. Fase F - Planificacion de la migracion Desarrolla el plan detallado de la Implemen-tacion y Migracion que indica como moverse de la Arquitectura de la Lınea Base a laArquitectura de Destino.

7. Fase G - Gobierno de la Implementacion Brinda supervision arquitectonica parala implementacion. Prepara y publica los contratos de Arquitectura y asegura que elproyecto de implementacion este conforme con la arquitectura.

8. Fase H - Gestion de Cambios de la Arquitectura Proporciona seguimiento continuoy un proceso de gestion de cambios para asegurar que la arquitectura responda a lasnecesidades de la empresa y el valor de la arquitectura sea el maximo para el negocio.


1.6.5. Entity Framework

Definicion

Microsoft da la siguiente definicion sobre Entity Framework:

”Microsoft ADO.NET Entity Framework es un framework de Mapeo objeto-relacional (Objec-t/Relational Mapping ORM) que permite a los desarrolladores trabajar con datos relacionalescomo objetos de dominio especıfico, eliminando la necesidad de gran parte del codigo deacceso a datos que el desarrollador usualmente necesita escribir. Usando Entity Framework,los desarrolladores realizan consultas a traves de LINQ, que recupera y manipula datos co-mo objetos fuertemente tipados. La implementacion del ORM de Entity Framework proveeservicios como rastreo de cambios, resolucion de identidades, carga diferida (lazy loading)y traduccion de consultas para que los desarrolladores puedan enfocarse en la logica es-pecıfica de la aplicacion en lugar de los fundamentos de acceso a datos.”

Entity Framework es una mejora a ADO.NET que le permite a los desarrolladores un meca-nismo automatizado para acceder y almacenar datos en la base de datos.

Figura 1.5: Escenarios de Entity Framework - Fuente [Tutorial, ]

Entity Framework es util en tres escenarios, como se muestra en la figura 1.5:

1. Si existe una base de datos o si se quiere disenar la base de datos por delante de lasotras partes de la aplicacion, llamado Database First.


2. Si se quiere enfocar en las clases de dominio y luego crear la base de datos desde lasclases de dominio, llamado Code First.

3. Si quiere disenar el esquema de base de datos en el disenador visual y luego crear labase de datos y sus clases, llamado Model First.

¿Que es un ORM?

ORM es una herramienta para almacenar datos de objetos de dominio a bases de datosrelacionales, como MS SQLSERVER, de forma automatizada, sin muucha programacion.Los O/RM incluyen tres partes principales: objetos de clase del Dominio, objetos de basede datos relacionales e informacion de mapeo de como los objetos del dominio mapean aobjetos de base de datos relacionales (tablas, vistas y procedimientos almacenados).

Figura 1.6: Object/Relational Mapping - Fuente [Tutorial, ]

Los ORM permite mantener el diseno de la base de datos separado del diseno de clasesdel dominio. Esto hace la aplicacion mantenible y extendible. Tambien automatiza las ope-raciones CRUD estandar (Create, Reade, Update, Delete), de tal forma que el desarrolladorno requiere escribirlas manualmente.

Arquitectura de Entity Framework

De acuerdo a la figura 1.7, Entity Framework se compone de los siguientes elementos:

• EDM (Modelo de datos de Entidades): EDM consiste en tres partes importantes: elmodelo Conceptual, el Mapeo y el modelo de Almacenamiento

• Modelo Conceptual: el modelo conceptual contiene las clases del modelo y sus rela-ciones. Esto es independiente del diseno de las tablas de la base de datos.

• Modelo de Almacenamiento: el modelo de almacenamiento es el modelo de disenode la base de datos el cual incluye tablas, vistas, procedimientos almacenados, y susrelaciones y llaves.

• Mapeo: el mapeo se compone de la informacion sobre como el modelo conceptual esmapeado en el modelo de almacenamiento.


Figura 1.7: Escenarios de Entity Framework - Fuente [Tutorial, ]

• LINQ to Entities: Es el lenguaje de consultas usado para escribir consultas contra elmodelo de objetos. Este retorna entidades, las cuales estan definidas en el modeloconceptual.

• Entity SQL: es otro lenguaje de consultas como LINQ to Entities.

• Servicio de objetos: es un punto de ingreso principal para acceder a los datos desdela base de datos y luego retornarlos. Es responsable de la materializacion, el cual esel proceso de convertir datos devueltos de un proveedor de datos de entidad cliente(siguiente capa) a una estructura de objetos de entidades.

• Proveedor de datos de Entidades Cliente: la principal responsabilidad de esta capaes convertir las consultas de LINQ to Entities o Entity SQL en consultas SQL que sonentendidas por la base de datos subyacente. Esta se comunica con el proveedor dedatos ADO.Net el cual envıa o recupera los datos de la base de datos.

• Proveedor de Datos ADO.Net: esta capa comunica con la base de datos usando elestandar ADO.Net.

1.7. MARCO ESPACIAL 17

1.7. Marco Espacial

La investigacion del proyecto se enmarca en estudiar el estado actual de la empresa Centrode Inversiones Empresariales en su lınea de negocio de Transporte Publico Independiente,la cual esta ubicada en la Carrera 28 bis # 12 – 60 en el Barrio Ricaurte en la ciudad deBogota.

1.8. Marco Legal

Para el ejercicio de la actividad economica denominada Transporte Publico Individual depasajeros en vehıculos Taxi se deben contemplar algunos preceptos que se contemplan enla Ley Colombiana.

1.8.1. Ley 769 de 2002

“Por la cual se expide el Codigo Nacional de Transito Terrestre y se dictan otras disposi-ciones” [de la Republica de Colombia, ]. En esta Ley se contemplan todas las regulacionesde “la circulacion de los peatones, usuarios, pasajeros, conductores, motociclistas, ciclis-tas, agentes de transito, y vehıculos por las vıas publicas o privadas que estan abiertas alpublico, o en las vıas privadas, que internamente circulen vehıculos; ası como la actuaciony procedimientos de las autoridades de transito”.

1.8.2. Decreto 172 de 2001

“Por el cual se reglamenta el Servicio Publico de Transporte Terrestre Automotor Individualde Pasajeros en Vehıculos Taxi” [de Transporte, ]. En este decreto se contempla la regla-mentacion de empresas de Transporte Publico Terrestre Automotor Individual de Pasajerosen Vehıculos Taxi, entre las cuales esta la personerıa jurıdica de la empresa, relacion devehıculos propios o de terceros afiliados, la tenencia de polizas de seguros de responsabili-dad civil contractual y extracontractual, pagos y vigencias (art. 18, 19, 20), la prestacion delservicio, la tarjeta de operacion y de control

1.8.3. Decreto 400 de 2014

“Por el cual se fija la tarifa para el servicio de transporte publico individual de pasajeros envehıculos clase taxi en el Distrito Capital” [de Bogota, ]. En este decreto se publican la tarifaque debe cobrar el conductor del vehıculo taxi al pasajero al realizar una carrera. Hasta lafecha de la elaboracion de este documento, es la normativa vigente.


1.9. Metodologıa de investigacion

1.9.1. Organizacion del trabajo de Grado

El tipo de estudio que se piensa aplicar para el presente proyecto es del nivel explicativo,dado que los resultados del trabajo pueden constituirse en un aporte al modelo teorico de laexplicacion de hechos del porque el proceso de administracion que se lleva actualmente enla companıa Centro de Inversiones Empresariales en la lınea de negocio de Taxis requiereuna herramienta de software que apoye dicha labor.

1.9.2. Metodo de investigacion

El metodo de investigacion que se llevara a cabo sera de Analisis, por lo que se iniciara porla identificacion del estado actual de los procesos administrativos de la companıa Centro deInversiones Empresariales en su lınea de negocio de Transporte Publico Independiente TPI.De esta manera se establece una relacion causa efecto entre los elementos que componenel objeto de investigacion.

1.9.3. Fuentes y tecnicas para la recoleccion de informacion

Para el proyecto se utilizaran fuentes secundarias, con las cuales nos apoyaremos parahacer el levantamiento de informacion del estado actual de la companıa en sus procesosadministrativos de la lınea de negocio de taxis. Entre las fuentes que se utilizaran estan: laobservacion, las encuestas y las entrevistas, las que se aplicaran al personal de la empresaque maneja los procesos administrativos del Centro de Inversiones Empresariales. Tambiense utilizaran datos de estadısticas de la Secretaria de Movilidad enfocadas en el serviciopublico individual.

1.9.4. Tratamiento de la informacion

Una vez sea recopilada toda la informacion de las diferentes fuentes de informacion se co-dificaran, tabularan y luego se calificaran y analizaran las variables que hacen parte delproceso administrativo de la empresa, con el fin de identificar la informacion mas relevanteo mas crıtica dentro del mismo proceso y de esa forma determinar que sub procesos soncandidatos a sistematizarse en el prototipo de la aplicacion que apoyara esta actividad delnegocio.

Por medio de una calificacion que se le otorgara a cada proceso y con acompanamientopersonal de la empresa, se priorizaran los procesos mas crıticos y que requieren con mas

1.9. METODOLOGIA DE INVESTIGACION 19

urgencia de un apoyo tecnologico para mejorar sus labores administrativas. Una vez se de-terminen los procesos que van a hacer parte del diseno del prototipo, la informacion sepresentara en diagramas de procesos identificando las entradas y salidas de que manejaactualmente la companıa en cada uno de los subprocesos.


Parte II

DESARROLLO DE LAINVESTIGACION

21

Capıtulo 2

Ejecucion del Proyecto

Para llevar a cabo el desarrollo, se utilizo la metodologıa en Cascada de Ingenierıa de Soft-ware, de la cual en su fase de Diseno se hizo una profundizacion del marco de trabajoTOGAF y como tal de su metodo ADM para aplicar un ciclo de Arquitectura Empresarialsobre la lınea de negocio de TPI en el CIE.

Posterior a la ejecucion de las fases de Arquitectura empresarial, acompanado del Analisisy Diseno del Modelo en Cascada, se priorizan los elementos de software mas relevantes yque logren apoyar de forma mas efectiva los procesos administrativos de la companıa.

Una vez se identifican los componentes de software a disenar, se plantea el prototipo de laaplicacion que se presentara como uno de los entregables para el presente proyecto.

2.1. Fase I. Ingenierıa y analisis del sistema

Para esta fase del proyecto se empezo por establecer comunicacion directa con la companıay sus encargados, entendiendo el contexto de cada una de sus actividades economicas,principalmente en la de Transporte Publico Individual.

Durante algunas sesiones se fueron revisando e identificando cada uno de los componentesde TI con los que se contaba en la companıa, al igual que los principales procesos que setenıan para llevar a cabo la operacion del negocio.

Como uno de los temas que se identificaron como mas impactados por falta de aplicacionde tecnologıas de la informacion fueron los procesos administrativos para la lınea de ne-gocio de TPI, y a pesar que de logran actualmente operar de forma adecuada, se puede

23

24 CAPITULO 2. EJECUCION DEL PROYECTO

proyectar una mejora representativa para la empresa al incluir elementos tecnologicos parasu respectivo apoyo.

Como soporte a esta etapa se lleva a cabo el levantamiento de requerimientos del sistema,en el cual se incluyeron los siguientes:

• Login de usuario

• Recuperacion de Login

• Gestion de Conductor

• Gestion de Conductor - Retiro

• Gestion Licencia de Conduccion

• Gestion de Vehıculos

• Gestion de Proveedores

• Gestion de Soportes de mantenimiento

• Gestion de Producido

• Gestion de Turnos

2.2. Fase I. Requerimientos de software

Los requerimientos fueron redactados en forma de Casos de Uso, en formato de tabla deuna columna, segun se describe en [Cockburn, 2001]. Para evitar ser extensivo en la re-daccion de los Casos de Uso, se entrega una version resumida de los requerimientos quese consideraron para el diseno del prototipo. La gran mayorıa de requerimientos son for-mularios basados en acciones CUD (Create, Update, Delete) y de esa forma se condensandichas acciones en la palabra “Gestion”.

Se deja a consideracion para trabajos futuros, usar la tecnica Use Case 2.0 para expandir losrequerimientos en “tajadas” (slices) mucho mas concisos y que le aporten valor al proyecto,tal como recomienda [Lopes, ].

2.2. FASE I. REQUERIMIENTOS DE SOFTWARE 25

2.2.1. Login de usuario

Login de usuario CU TAXMON 001

DESCRIPCION El usuario ingresa al Sistema de informacion por mediode un nombre de usuario y una contrasena.

ACTORES Cualquier actorPRECONDICIONES 1. El usuario existe en el sistema.POSTCONDICIONES 1. El usuario queda logueado, en sesion correspondiente

a su rol de forma exitosa(log on)2. Se deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. Nombre de Usuario (*)b. Contrasena (*)

PRIORIDAD ALTACOMPLEJIDAD MEDIAFRECUENCIA DE USUO ALTA

Tabla 2.2: Requerimiento 001 - Login de Usuario


2.2.2. Recuperacion de Login

Recuperacion de Login deusuario

CU TAXMON 002

DESCRIPCION El usuario quiere recuperar el ingreso a la plataforma encaso de olvidar la contrasena o ya sea que el sistema lohaya bloqueado 3 veces por ingreso incorrecto de contra-sena.

ACTORES Cualquier actorPRECONDICIONES 1. El usuario existe en el sistema.

2. El usuario ha olvidado su contrasena3. El usuario fue bloqueado por ingreso erroneo

POSTCONDICIONES 1. El usuario actualiza su contrasena2. Se deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA 1. vınculo de Recuperacion de contrasenaa. Nueva contrasenab. Confirmacion de contrasena

PRIORIDAD MEDIACOMPLEJIDAD BAJAFRECUENCIA DE USUO BAJA

Tabla 2.4: Requerimiento 002 - Recuperacion de Login


2.2.3. Gestion de Conductor

Gestion de conductores -C.U.D

CU TAXMON 003

DESCRIPCION Permite crear, editar y eliminar un conductor del sistemaACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de

informacion.POSTCONDICIONES · El conductor queda registrado en el sistema y en estado

“ACTIVO”, si es CREACION· El conductor queda con datos modificados si es EDI-CION· El conductor se elimina del sistema de informacion si esELIMINACIONSe deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. No de documento de identidad *b. Tipo de documento de identidad *c. Fecha de expedicion *d. Ciudad de expedicion *e. Apellido 1 *f. Apellido 2 *g. Nombres *h. Fecha de nacimiento *i. Email *j. Genero *k. Grupo sanguıneo *l. Movil *m. Telefono domicilion. Direccion domicilio *o. Barrio *p. Ciudad *q. Departamento *r. ESTADO CONDUCTOR *


Tabla 2.6: Requerimiento 003 - Gestion de Conductor


2.2.4. Gestion de Conductor - Retiro

Gestion de conductores -RETIRO

CU TAXMON 004

DESCRIPCION Permite retirar un conductor existente y deshabilitarlo delsistema, ya sea por retiro de la profesion, despido, muerteu otras razones

ACTORES AdministradorPRECONDICIONES El administrador debe estar logueado en el sistema de

informacion.El conductor debe existir en el sistema de informacion.

POSTCONDICIONES • El conductor queda con estado “RETIRADO”• Se deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA No de documento de identidad *ESTADO CONDUCTOR = RETIRADO

PRIORIDAD MEDIACOMPLEJIDAD BAJAFRECUENCIA DE USUO BAJA

Tabla 2.8: Requerimiento 004 - Retiro de Conductor


2.2.5. Gestion Licencia de Conduccion

Gestion de Licencia de con-duccion

CU TAXMON 005

DESCRIPCION Permite crear, editar o eliminar una licencia de conduc-cion y asociarla a un conductor. Estas presentan una vi-gencia definida por la autoridad competente por lo queun conductor puede tener varias licencias de conduccionpero una sola vigente.

ACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de

informacion.2. El conductor a quien se le vincula la licencia de con-duccion debe existir en el sistema de informacion.

POSTCONDICIONES 1. El conductor queda vinculado a una licencia de con-duccion vigente.2. Se deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA 1. Conductor para agregarle una licencia de conduccion,ya sea por la busqueda de documento de identidad (A1)o escogido de la lista desplegada.a. No de licencia *b. Fecha de expedicion *c. Restricciones del conductord. Organismo de transito expedidor *e. Categorıa *f. Fecha de vigencia *

PRIORIDAD MEDIACOMPLEJIDAD MEDIAFRECUENCIA DE USUO MEDIA

Tabla 2.10: Requerimiento 005 - Gestion de licencia de conduccion


2.2.6. Gestion de Vehıculos

Gestion de Vehıculos CU TAXMON 006

DESCRIPCION Permite crear, editar y eliminar un vehıculo en el sistemaACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de

informacion.POSTCONDICIONES · El vehıculo queda registrado en el sistema y en estado

“ACTIVO”, si es CREACION· El vehıculo queda con datos modificados si es EDICION· El vehıculo se elimina del sistema de informacion si esELIMINACIONSe deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. Placa *b. No Licencia de transito *c. Clase de vehıculo *d. Tipo Servicio *e. Marca *f. Modelo *g. Lınea *h. Color *i. No de seriej. No de motor *k. No de chasis *l. No VIN *m. Cilindraje *n. Tipo Carrocerıa *o. Tipo Combustible *p. Fecha Matricula inicial *q. Capacidad de cargar. Peso bruto *s. No ejes *t. Capacidad de Pasajerosu. Capacidad de pasajeros sentados *v. DATOS PROPIETARIOw. ESTADO DEL VEHICULO *


Tabla 2.12: Requerimiento 006 - Gestion de vehıculos


2.2.7. Gestion de Proveedores

Gestion de Proveedores CU TAXMON 007

DESCRIPCION Permite crear, editar y eliminar un proveedor del sistemaACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de

informacion.POSTCONDICIONES · El proveedor queda registrado en el sistema si es

CREACION· El proveedor queda con datos modificados si es EDI-CION· El proveedor se elimina del sistema de informacion si esELIMINACIONSe deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. NIT *b. Nombre *c. Direccion *d. Telefono 1 *e. Telefono 2 *f. Tipo Proveedor * (MANTENIMIENTO - ASEGURADO-RA)

PRIORIDAD MEDIACOMPLEJIDAD MEDIAFRECUENCIA DE USUO ALTA

Tabla 2.14: Requerimiento 007 - Gestion de Proveedores


2.2.8. Gestion de Soportes de mantenimiento

Gestion de Soportes deMantenimiento

CU TAXMON 008

DESCRIPCION Permite crear, editar y eliminar un soporte de manteni-miento realizado al vehıculo, ya sea factura de venta oremision


informacion.2. El vehıculo debe existir en el sistema de informacion3. El proveedor debe existir en el sistema de informacion

POSTCONDICIONES · El soporte de mantenimiento queda registrado en el sis-tema si es CREACION· El soporte de mantenimiento queda con datos modifica-dos si es EDICION· El soporte de mantenimiento se elimina del sistema deinformacion si es ELIMINACIONSe deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. No de Factura de venta o remision *b. Proveedor *c. Fecha *d. Vehıculo al que se le hace el mantenimiento o comprade producto *e. Referencia del servicio o producto adquirido*f. Cantidad *g. Valor servicio o producto *h. Tiempo garantıa

PRIORIDAD MEDIACOMPLEJIDAD ALTAFRECUENCIA DE USUO ALTA

Tabla 2.16: Requerimiento 008 - Gestion de Soportes de mantenimiento


2.2.9. Gestion de Producido

Gestion de Producido CU TAXMON 009

DESCRIPCION Permite crear, editar y eliminar un registro de producidorealizado por el conductor en un vehıculo.


informacion.2. El vehıculo debe existir en el sistema de informacion3. El conductor debe existir en el sistema de informacion

POSTCONDICIONES · El registro de producido queda creado en el sistema sies CREACION· El registro de producido queda con datos modificados sies EDICION· El registro de producido se elimina del sistema de infor-macion si es ELIMINACIONSe deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. Vehıculob. Conductorc. Fecha de entregad. Valor de producido


Tabla 2.18: Requerimiento 009 - Gestion de Producido


2.2.10. Gestion de Turnos

Gestion de Turnos CU TAXMON 010

DESCRIPCION Permite crear, editar y eliminar un turno que asocia a unconductor con un vehıculo en una jornada.


informacion.2. El vehıculo debe existir en el sistema de informacion3. El conductor debe existir en el sistema de informacion

POSTCONDICIONES · El turno se asigna en el sistema a un conductor con unvehıculo (CREACION)· El turno se modifica en el sistema (EDICION)· El turno se elimina del sistema de informacion (ELIMI-NACION)Se deja un rastro de auditorıa en el log del sistema.

DATOS DE ENTRADA a. Vehıculob. Conductorc. Turno (DIURNO – NOCTURNO)


Tabla 2.20: Requerimiento 010 - Gestion de Turnos

2.3. FASE I. DESCRIPCION DE LA ORGANIZACION CENTRO DE INVERSIONES EMPRESARIALES35

2.3. Fase I. Descripcion de la organizacion Centro de Inversio-nes Empresariales

2.3.1. Mision

La lınea de negocio de transporte publico individual, de la companıa Centro de InversionesEmpresariales, se dedica a administrar los automotores de su propiedad, buscando ofrecerun servicio confiable y optimo a todos sus pasajeros de su flotilla de taxis, al igual quegenerar empleo a los conductores mejor calificados para dicha labor.

2.3.2. Vision

Ser la empresa de taxis de mayor reconocimiento a nivel distrital por su atencion al pasajero,calidad de servicio y disponibilidad de vehıculos.

2.3.3. Objetivos

1. Brindar atencion al pasajero con calidad y calidez.

2. Ofrecer vehıculos seguros y confortables.

3. Conducir con responsabilidad.

2.3.4. Matriz DOFA

Basados en el Plan Estrategico que elaboramos para el Centro de Inversiones Empresaria-les unos meses antes de iniciar con el presente proyecto, nos es de gran apoyo contar conla siguiente matriz DOFA, donde basados en las fortalezas y debilidades de la evaluacioninterna, e intersectandolas contra las oportunidades y amenazas de la evaluacion externa,se obtienen algunas de las estrategias que se pueden observar en la figura 2.1.


Figura 2.1: Matriz DOFA Centro de Inversiones Empresariales - Fuente: Los autores

2.4. FASE II. ANALISIS DE LOS REQUISITOS DE SOFTWARE 37

2.4. Fase II. Analisis de los requisitos de software

En esta fase se empieza a organizar y validar el alcance de los requerimientos que se in-cluyeron en la fase anterior. Al igual se valida la viabilidad de cada uno de ellos y segunsu importancia y posibles dependencias entre ellos se organiza el plan de trabajo para elproyecto.

A este punto del proyecto ya se tiene la mayorıa de informacion por parte de la empresapara sesgar como tal el alcance y generar una lınea base del listado de actividades a reali-zar; tambien ya se logran definir de forma mas certera los recursos necesarios para llevar acabo la ejecucion del proyecto, hablando en temas de presupuesto, tiempo, recurso humanoy fısico.

Como resultado del analisis del proyecto, se estructura llevar a cabo los siguientes items enla ejecucion de fases posteriores de la metodologıa en cascada ası:

Diseno:

• Diseno de una Arquitectura Empresarial para el Centro de Inversiones Empresarialesen su lınea de negocio de Transporte publico independiente basada en el frameworkTogaf y su metodo ADM.

• Diseno de un modelo de datos acorde a los resultados de llevar a cabo la arquitecturaempresarial en la companıa.

Codificacion:

• Implementacion del modelo de Base de datos en el motor Microsoft SQLServer.

• Elaboracion del prototipo de la aplicacion que apoyara las labores operativas de laflotilla de taxis del Centro de Inversiones Empresariales.


2.5. Fase III. Diseno

Los items que se incluyeron en esta fase se llevaron a cabo como se mencionara en lossiguientes puntos.

2.5.1. Diseno de Arquitectura Empresarial

Basados en la el framework Togaf, y su metodo ADM se elaboraron los diferentes puntos devista que sugiere el framework, basados en la informacion de la empresa y en su lınea denegocio de transporte publico independiente.

El detalle del Diseno la Arquitectura Empresarial que se elaboro para el proyecto, se puedenobservar en la Parte III del documento Capas de Diseno de Arquitectura Empresarial.

2.5.2. Diseno del modelo de datos

Teniendo en cuenta los requerimientos, el levantamiento de informacion a la empresa y eldiseno de la arquitectura empresarial; se llevo a cabo el diseno del modelo de datos en elque se incluyeron las entidades mas relevantes para apoyar las labores administrativas delCentro de Inversiones Empresariales como se muestra en la figura 2.2. Sobre el modelo dedatos elaborado, se llevara a cabo la generacion del prototipo de software que hara parte dela entrega del proyecto.

2.5. FASE III. DISENO 39

Figura 2.2: Diseno del modelo de datos - Fuente: Los autores


2.6. Fase IV. Codificacion

A continuacion se explicara la forma como se implementaron los elementos que se incluye-ron desde el Analisis para esta fase.

2.6.1. Implementacion del Modelo de Datos

Teniendo en cuenta el modelo de datos construido en la fase de Diseno, se construyeron losscripts de creacion para cada una de las tablas con sus respectivos tipos de datos, longitu-des, restricciones de obligatoriedad y llaves primarias y foraneas; para obtener finalmente laBase de Datos funcional en el motor Microsoft SQLServer como se observa en la figura 2.3.

Figura 2.3: Implementacion del Modelo de Datos - Fuente: Los autores

2.7. FASE IV. GENERACION DE PROTOTIPO 41

2.7. Fase IV. Generacion de prototipo

2.7.1. Arquitectura de software

Para el prototipo de software, que de aquı en adelante se llamara TaxiMonitor, se opta poruna arquitectura web de acuerdo a una de las condiciones que solicita el cliente final en eldocumento de requerimientos. Esta exigencia pide que la aplicacion Taximonitor este dispo-nible la mayor parte del tiempo, que se pueda acceder desde cualquier computador y queno dependa de algun sistema operativo desde donde se consulta y/o ingresa la informacion.

Figura 2.4: Estructura tıpica de una aplicacion web - Fuente: [Team, 2009]

El desarrollo de la aplicacion se dividira en tres capas: capa de presentacion, capa de nego-cio y capa de datos, para disponer de una separacion de responsabilidades bien definida. Enla imagen 2.4 se definen los elementos que en cada capa se recomienda tener al desarrollaruna aplicacion en entorno web, de acuerdo con [Team, 2009].

Para el prototipo de Taximonitor, se contemplo una version simplificada de este modelo dedesarrollo por capas, como se muestra en la figura 2.5. En dicha figura se muestra que nohay elementos de tipo transversal, puesto que el alcance del prototipo no cubre elementos


de seguridad y administracion de operaciones. Para la capa de presentacion se dispondralos elementos graficos necesarios que el navegador del cliente necesitara para mostrar lainterfaz de usuario requerida y con esto realizar la navegacion entre las diferentes vistas dela UI. En capa de negocio, solo se trabajo en las Entidades del negocio, por medio de EntityFramework; la capa de datos establcera comunicacion con el repositorio de informacion(base de datos), creado en MS SqlServer.

Figura 2.5: Estructura adoptada para Taximonitor - Fuente: [Team, 2009]

El desarrollo del prototipo se realizo con ASP.NET MVC, tomando la ventaja que el patronde diseno Modelo Vista Controlador (MVC) permite separar responsabilidades en capa depresentacion, como se vera mas adelante. Las otras dos capas, Negocio y Datos, estancontroladas por Entity Framework; a continuacion se mostrara como se genero el prototipoen MS Visual Studio utilizando estas dos herramientas.

2.7.2. Modelo de entidades

Una de las primeras tareas que se ejecutaron en el desarrollo del prototipo fue la creaciondel modelo Entidad-Relacion, materializado en la implementacion de la base de datos como


se muestra en la seccion 2.5.2.

A partir de la base de datos creada, se opto por la construccion del prototipo de softwarepor medio del escenario Database First proporcionado por Entity Framework, de acuerdocomo se indica en [FitzMacken, ].

Entity Framework se encuentra como un componente del entorno de desarrollo Microsoft Vi-sual Studio, administrado a taves del gestor de paquetes llamado NuGet Package Manager.Actualmente EF esta en la version 6.1.3.

Creacion de aplicacion en Visual Studio

Se crea un nuevo proyecto en Visual Studio. La version utilizada para el presente trabajo fueVS2013 Community Edition, disponible de forma gratuita.

1. Dentro del nuevo proyecto, se navega dentro de la opcion Visual C#, seccion Web y seescoge “Aplicacion web ASP.NET”.

Figura 2.6: Nuevo proyecto Web - Fuente: Los autores

2. Se selecciona la opcion MVC, figura 2.7.

3. Visual Studio crea una plantilla de aplicacion que incluye los archivos necesarios paracrear una aplicacion ASP.NET MVC, como hojas de estilo (CSS) basados en Bootstrap,archivos de javascript, y tres carpetas especiales que se muestran en la figura 2.9


Figura 2.7: Nuevo proyecto Web - Fuente: Los autores

Figura 2.8: La aplicacion se ha generado - Fuente: Los autores

4. Las tres carpetas que se muestran en la figura 2.9 se llaman Controllers, Models yViews, que corresponden a cada una de las letras del patron de diseno Modelo VistaControlador.

El patron Modelo Vista Controlador es un medio poderoso y elegante de separacionde responsabilidades dentro de una aplicacion (separa la logica de acceso a datos dela logica de visualizacion) y se aplica extremadamente bien a aplicaciones web. Su


separacion de responsabilidades le agrega una cantidad extra de complejidad al di-seno de la aplicacion, pero sus extraordinarios beneficios compensa el esfuerzo extra.[Galloway et al., 2012]

Figura 2.9: Explorador de solucion y las tres carpetas de MVC - Fuente: Los autores

El patron MVC separa la Interfaz de Usuario (UI) de una aplicacion en tres aspectosprincipales:

• El Modelo: un conjunto de clases que describe los datos con que se esta traba-jando ademas de las reglas de negocio de como los datos pueden ser cambiadosy manipulados.

• La Vista: define como la Interfaz de Usuario (UI) de la aplicacion se mostrara.

• El Controlador: ses un conjunto de clases responsables de responder a las pe-ticiones hechas a un sitio web ASP.NET MVC.

5. Continuando con el paso a paso de la creacion del prototipo, se creara el Modelo deEntidades a partir de la base de datos y se mapeara en un archivo tipo EDMX. Se daclic derecho sobre la carpeta “Models”, clic en “Agregar” y clic en “Nuevo elemento...”.,como se muestra en la figura 2.10. En la seccion “Visual C#”, seleccione la opcion“Datos” y luego el elemento “ADO.NET Entity Data Model”. Se asigna un nombre alModelo de entidades, para este caso, se llamara “TaximonitorEntities”.


Figura 2.10: Agregar nuevo Entity Model - Fuente: Los autores

6. En el asistente de Entity Data Mode se escoge la opcion “EF Designer desde base dedatos” y se establece la conexion con la instancia de Sql Server. Una vez escogidoel servidor, se selecciona la base de datos que se va a mapear, ilustrado en la figura2.11.

Figura 2.11: Asistente para Entity Data Model - Database first - Fuente: Los autores


7. La figura 2.12 muestra la cadena de conexion establecida por el asistente; se asignaun nombre a la configuracion que quedara en el archivo web.config, para este caso,“TaxiMonitorEntities”. Al dar clic en “Siguiente”, el asistente preguntara por los elemen-tos de la base de datos que seran mapeados. Para el prototipo, solo se mapearanlas tablas creadas en la seccion 2.5.2. Se da clic en “Finalizar” para la generacion delmodelo.

Figura 2.12: Cadena de conexion para el modelo de entidades y mapeo de BD

8. La creacion del modelo de entidades ha finalizado y como se muestra en la figura2.13, cada una de las tablas de la BD ha sido mapeada a una clase de entidades, ysus campos se convierten en propiedades para ser tratadas como objetos.

Figura 2.13: Entidad ControlTurnos - Fuente: Los autores

9. Entity Framework genera el diagrama de entidades como se muestra en la figura 2.14.


Si la base de datos cambia en cualquier momento, EF esta en capacidad de volver amapear el contenido y actualizar el diagrama y el modelo de entidades.

Figura 2.14: Diagrama de entidades generado por Entity Framework - Fuente: Los autores


2.7.3. Creacion de Controladores y Vistas

Continuando con la creacion del prototipo, Visual Studio permite al desarrollador crear losControladores y las Vistas a traves de un proceso llamado “scaffolding”, que no es masque el llamado a unos metodos que generan codigo a partir de plantillas (scaffolding enarquitectura es el uso de andamios para soportar una estructura). El Scaffolding permitecrear el controlador de la entidad mapeada por EF, quien tendra los metodos de accionrelacionados con el acceso a la base de datos, los famosos metodos CRUD (Create, Read,Update, Delete), y si el desarrollador lo requiere, tambien le generara las vistas relacionadascon el controlador y sus metodos de accion.

1. Para crear un controlador, se hace clic derecho sobre la carpeta “Controlers” y clic enla opcion “Agregar”, y clic en “Nuevo elemento con Scaffolding”. Aparecera la ventanade agregar scaffold y se selecciona la opcion “Controlador de MVC5 con vistas queusa Entity Framework”.

Figura 2.15: Agregar nuevo controlador por scaffolding - Fuente: Los autores

2. Se creara el controlador para la entidad “Conductor”, se escogera a Conductor enla opcion Clase de Modelo, TaxiMonitorEntities en la opcion Clase de contexto dedatos. Se marcan las opciones de Generar Vistas, y se usa en pagina de diseno, lavista compartida ubicada en ∼/Views/Shared/ Layout.cshtml, como se muestra en lafigura 2.16. El nombre del Controlador se registra como “ConductorController”. Debenotarse que el sufijo Controller es obligatorio.

~/Views/Shared/_Layout.cshtml


Figura 2.16: Condiciones para generar Controlador y Vista de Conductor - Fuente: Los au-tores

3. Se genera entonces el controlador Conductor, como se muestra en la figura 2.17, ylas vistas correspondientes a los metodos de accion CRUD, llamadas Create, Delete,Details, Edit e Index, todos de extension cshtml.

Figura 2.17: Controlador y Vista para Conductor - Fuente: Los autores


4. Al ejecutar la aplicacion, el acceso al controlador Conductor mostrara los siguientespantallazos, mostrados en las figuras 2.18, 2.19, 2.20 y 2.21:

Figura 2.18: Vista para Index de Conductor - Fuente: Los autores

Figura 2.19: Vista para Create de Conductor - Fuente: Los autores

El prototipo puede registrar informacion desde los formularios anteriormente presenta-dos en la base de datos mapeada. Ahora el desarrollador se podra enfocar en tareascomo validaciones de lado de cliente, crear las reglas de la logica del negocio, cambiarla plantilla de presentacion de las vistas al manipular el codigo HTML y las hojas deestilo CSS, generar reportes, etc.

Se repite todos los pasos descritos en esta seccion para generar los demas formula-rios que hacen falta para completar los controladores que manipularan al modelo deentidades.


Figura 2.20: Vista para Edit de Conductor - Fuente: Los autores

Figura 2.21: Vista de Detalles de Conductor - Fuente: Los autores

2.8. FASE IV. APLICACION TAXIMONITOR 53

2.8. Fase IV. Aplicacion TaxiMonitor

2.8.1. Login de Usuario

El usuario encontrara al ingresar a la pagina de Taximonitor, una pantalla que le pedirael correo electronico registrado en el sistema y la contrasena creada para el ingreso, deacuerdo a lo exigido en el requerimiento CU TAXMON 001, referido en la tabla 2.2. Despuesde ingresar los datos, el usuario dara clic en el boton “Ingresar”.

Figura 2.22: Vista de Login - Fuente: Los autores

El usuario encontrara la pagina Home o Inicio con una barra de menu donde tendra lasopciones que le permitira consultar o registrar la informacion del proceso que quiera llevar acabo.

Figura 2.23: Vista Home despues de Login - Fuente: Los autores


Las opciones que tendra el usuario logueado son:

• Conductor

• Licencia de conduccion

• Vehıculo y Propietarios

• Producido

• Proveedores

• Repuestos y Servicios

• Mantenimientos

2.8.2. Modulo de Conductor

El usuario tendra la opcion de listar los conductores actualmente registrados, crear un nuevoconductor, editar sus datos y borrar un conductor en caso de haber sido mal creado. Todoesto corresponde al requerimiento CU TAXMON 003, referido en la tabla 2.6.

Listado de Conductores

Por medio de una tabla, el sistema lista los conductores actualmente registrados, mostran-do datos basicos de contacto y el estado en el que se encuentra actualmente; el usuarioencontrara tres botones que le permitira: Ver los detalles del conductor (color azul celeste),Editar la informacion de conductor (color naranja), y Eliminar el conductor (color rojo).

Figura 2.24: Listado de Conductores - Fuente: Los autores


Creacion de Conductor

Permite crear un nuevo conductor y darlo de alta en el sistema de informacion. Los datosque se capturan son:

• Nro Identificacion

• Tipo Identificacion

• Nombres

• Apellidos

• Fecha Nacimiento

• Email

• Genero

• Grupo Sanguineo

• Fecha ExpedicionCedula

• Lugar ExpedicionCedula

• Nacionalidad

• Lugar Nacimiento

• Direccion Domicilio

• Barrio

• Ciudad

• Telefono Domicilio

• Telefono Movil

• EPS

• Pension

• Estado Conductor

• FechaIngreso

Figura 2.25: Creacion de nuevo Conductor - Fuente: Los autores


Edicion de Conductor

Permite editar los datos de un conductor existente en el sistema al seleccionarlo del listadode conductores, mostrado en la seccion 2.8.2.

Figura 2.26: Edicion de Conductor - Fuente: Los autores

Detalles de Conductor

Muestra los datos del conductor seleccionado del listado de conductor sin necesidad deaparecer en un formulario de edicion.

Figura 2.27: Detalles de Conductor - Fuente: Los autores


2.8.3. Modulo de Licencia de Conductor

El usuario tendra la opcion de gestionar la informacion pertinente a las licencias de losdiferentes conductores que estan registrados en el sistema. Responde al requerimientoCU TAXMON 004, referido en la tabla 2.8.

Listado de Licencias

El sistema muestra por medio de una tabla el listado de licencias vigentes en el sistema. Sepuede editar, ver detalles de y eliminar una licencia, segun sea la licencia escogida.

Figura 2.28: Listado de Licencias de Conductor - Fuente: Los autores

Crear Licencia

Le permite al usuario crear una licencia y asociarla a un conductor previamente registradoen el sistema, como se ilustra en la figura 2.29. Los datos que se capturan en este formularioson:

• Numero Licencia

• Conductor

• Fecha Expedicion

• Restriccion Conductor

• Organismo Transito que Expide

• Categoria Licencia

• Fecha Vigencia


Figura 2.29: Crear nueva Licencia de Conductor - Fuente: Los autores

Editar Licencia

Le permite al usuario editar una licencia existente en el sistema. Carga los mismos elemen-tos que la Creacion de Licencia, salvo que el dato de Numero de Licencia no es modificable.

Figura 2.30: Editar Licencia de Conductor - Fuente: Los autores


Borrar Licencia

Le permite al usuario borrar una licencia. Muestra un mensaje de confirmacion antes derealizar el borrado definitivo del dato. Si hay datos asociados a la licencia que se quiereborrar, el sistema no lo permitira para garantizar la integridad de la informacion.

Figura 2.31: Borrar Licencia de Conductor - Fuente: Los autores


2.8.4. Modulo de Vehıculo y Propietarios

El usuario podra gestionar la informacion de Vehıculos y sus Propietarios, tambien agregarmarcas de vehıculos que no existan en el sistema.

Listado de Propietarios

El sistema muestra el listado de propietarios de vehıculos creados en el sistema.

Figura 2.32: Listado de Propietarios - Fuente: Los autores

Creacion de Propietario

Permite crear un propietario de vehıculo para que sea asociado posteriormente a un nuevoo existente vehıculo.

Figura 2.33: Creacion de Propietario - Fuente: Los autores


Edicion de Propietario

Permite editar la informacion de un propietario, cargando los mismos datos que Creacion dePropietario, salvo Nro de Identificacion, que es de solo lectura.

Figura 2.34: Edicion de Propietario - Fuente: Los autores

Borrado de Propietario

Permite borrar la informacion de un propietario. Si esta asociado a un vehıculo, el sistemano permitira el borrado.

Figura 2.35: Borrado de Propietario - Fuente: Los autores


Listado de Marcas de Vehıculos

El sistema lista las marcas que han sido registradas para asociarse a un vehıculo.

Figura 2.36: Listado de Marcas de Vehıculos - Fuente: Los autores

Creacion de Marcas de Vehıculo

Permite crear la marca de un vehıculo. Es la unica tabla auxiliar que el usuario puede modi-ficar.

Figura 2.37: Creacion de Marcas de Vehıculo - Fuente: Los autores


Listado de Vehıculos

El sistema le muestra al usuario los vehıculos ingresados en el sistema con sus datos masimportantes y el estado qeu se encuentra dentro de la Empresa. Se puede seleccionar unvehıculo para tareas de Edicion, Detalles y Borrado.

Figura 2.38: Listado de Vehıculos - Fuente: Los autores

Creacion de Vehıculos

El usuario puede crear vehıculos (taxis) y vincularle un propietario. Cabe recordar que pri-mero debe crearse un propietario de vehıculo, como se senalo en la seccion 2.8.4.

Figura 2.39: Creacion de Vehıculos - Fuente: Los autores

Los datos que se capturan son:


• Placa

• Numero Licencia Tran-sito

• Clase Vehiculo

• Tipo Servicio

• Marca

• Modelo

• Linea

• Color

• Nro Serie

• Nro Motor

• Nro Chasis

• Nro VIN

• Cilindraje

• Tipo Carroceria

• Tipo Combustible

• Fecha Matricula

• Capacidad Carga

• Peso Bruto

• Nro Ejes

• Capacidad Pasajeros

• Capacidad PasajerosSentados

• Estado Vehiculo

• Propietario

Edicion de Vehıculos

El usuario puede editar la informacion de un vehıculo seleccionado. Todos los campos mos-trados en la seccion anterior, Creacion de Vehıculos, se muestran pero el campo Placa nose puede editar.

Figura 2.40: Edicion de Vehıculos - Fuente: Los autores


Borrado de Vehıculos

El usuario puede borrar un vehıculo que no este vinculado a ningun proceso mas adelante,como asignacion de turnos. El sistema le muestra un mensaje para confirmar el proceso.

Figura 2.41: Borrado de Vehıculos - Fuente: Los autores

2.8.5. Control de Turnos y Producido

En este modulo, el usuario podra registrar en que turno u horario fue asignado un conductor,con que vehıculo en especıfico trabajo y cuanto dinero reporta del trabajo realizado productode las carreras, mas conocido como producido.

Figura 2.42: Listado de Turnos - Fuente: Los autores


Listado de Turnos

El sistema le muestra al usuario una tabla con todos los registros realizados hasta el mo-mento de la asignacion de conductor y vehıculo, el inicio y el final del turno y el monto queha entregado el conductor al administrador de los taxis. Se puede seleccionar un turno paratareas de Edicion, Detalles y Borrado, como se puede apreciar en la figura 2.42.

Crear Turno

El usuario puede asignar turno a un conductor, vincularlo a un vehıculo y estableciendo elhorario de trabajo para la jornada. Si el turno ya se realizo, se puede registrar el valor deldinero que se produjo como producto de las carreras realizadas, en el campo Producido.

Figura 2.43: Editar Turno - Fuente: Los autores

Editar Turno

El usuario puede editar el turno de un conductor si desea hacer algun cambio en la progra-macion de los turnos. Tambien puede actualizar el monto del producido para dicho turno. Elmodulo se puede apreciar en la figura 2.44.

Borrar Turno

El usuario puede borrar el turno de un conductor. Esta accion no tiene opcion de deshacer.El modulo se puede apreciar en la figura 2.45.


Figura 2.44: Editar Turno - Fuente: Los autores

Figura 2.45: Borrado de Turno - Fuente: Los autores

2.8.6. Proveedores

Listado de Proveedores

El sistema le muestra al usuario un listado de proveedores registrados en el Sistema, queserviran como insumo para el registro de Control de Mantenimientos. Se puede seleccionarun proveedor para tareas de Edicion, Detalles y Borrado.


Figura 2.46: Listado de Proveedores - Fuente: Los autores

Crear Proveedor

El usuario puede crear un nuevo proveedor proporcionando los siguientes datos:

• NIT

• Nombre

• Direccion

• Telefono 1

• Telefono 2

• Tipo Proveedor

Figura 2.47: Creacion de Proveedor - Fuente: Los autores


Editar Proveedor

El usuario puede cambiar los datos de un proveedor selecionado de la lista de Proveedores.El unico dato que no puede modificar es el NIT.

Figura 2.48: Editar proveedor - Fuente: Los autores

Borrar Proveedor

El usuario puede eliminar un proveedor de la base de datos, siempre y cuando no esteasociado con informacion de Control de Mantenimientos.

Figura 2.49: Borrar proveedor - Fuente: Los autores


2.8.7. Repuestos y Servicios

En este modulo, el usuario puede crear repuestos y servicios para ser incluidos en un nuevoregistro de Mantenimientos.

Listado de Repuestos

El usuario puede consultar los repuestos que existen en el sistema a traves de una lista. Sepuede editar y borrar repuestos al ser seleccionados de este listado.

Figura 2.50: Listado de Repuestos - Fuente: Los autores

Crear un nuevo repuesto

Los repuestos pueden ingresarse en el sistema al solicitar los siguientes datos.

• Nombre del repuesto • Duracion aprox. en dıas (opcional)


Figura 2.51: Crear un nuevo repuesto - Fuente: Los autores

Listado de Servicios

El usuario puede consultar los servicios que existen en el sistema a traves de una lista. Sepuede editar y borrar servicios al ser seleccionados de este listado.

Figura 2.52: Listado de Servicios - Fuente: Los autores

Crear un nuevo servicio

Los servicios pueden ingresarse en el sistema al solicitar los siguientes datos.

• Nombre del servicio. • Duracion aprox. en dıas (opcional)


Figura 2.53: Crear un nuevo servicio - Fuente: Los autores

2.8.8. Mantenimientos

En este modulo, el usuario puede crear y editar registros de Mantenimiento de los vehıculos.

Listado de Mantenimientos

El usuario puede consultar los registros que existen en el sistema a traves de una lista. Sepuede editar y borrar repuestos al ser seleccionados de este listado.

Figura 2.54: Listado de Mantenimientos - Fuente: Los autores


Crear un nuevo registro de Mantenimiento

Los registros de Mantenimiento pueden ingresarse en el sistema al solicitar los siguientesdatos:

• Placa del vehıculo.

• Nombre del Proveedor

• Fecha

• Repuesto o servicio realizado

Figura 2.55: Crear nuevo registro de Mantenimiento - Fuente: Los autores

Editar un registro de Mantenimiento

Los registros de Mantenimiento pueden editarse para modificar informacion que haya que-dado mal registrada.

Figura 2.56: Editar nuevo registro de Mantenimiento - Fuente: Los autores


Borrar un registro de Mantenimiento

El usuario puede eliminar un registro de Mantenimientos. Esta accion no se puede deshacer.

Figura 2.57: Borrar un registro de Mantenimiento - Fuente: Los autores

2.9. Fase V. Pruebas y Mantenimiento

Estas fases de la metodologıa no aplican para el caso de estudio, dado que mediante elprototipo funcional, se llevara a cabo la presentacion del resultado al Centro de InversionesEmpresariales, para que a su vez, se valide en conjunto si se dara continuacion a unasegunda fase del proyecto, donde se implemente la solucion completa, lo cual vale aclarar,no hace parte del alcance del presente proyecto.

Parte III

CAPAS DE DISENO DEARQUITECTURA EMPRESARIAL

75

Capıtulo 3

Diseno de Arquitectura de Negocio

3.1. Punto de vista organizacional

3.1.1. Metamodelo P.V Organizacional

Este punto de vista destaca los actores que hacen parte de la organizacion, que roles le hansido asignados y como entran en relacion entre sı. Por supuesto es importante senalar enque entorno operara, ya sea fısico, al hacer uso de las instalaciones de la companıa o en unentorno digital, como por ejemplo, un sitio web. Ver Figura 3.1.

Figura 3.1: Metamodelo Punto de Vista Organizacional - Fuente: Sandro Bolanos

3.1.2. Aplicacion P.V Organizacional

Segun el levantamiento de informacion efectuado en el Centro de Inversiones Empresarialesse obtuvo la jerarquıa descrita en la figura 3.2, donde se evidencia que el Gerente Gene-

77

78 CAPITULO 3. DISENO DE ARQUITECTURA DE NEGOCIO

ral en conjunto con el Administrador de la lınea de negocio de Trasporte Publico Individual,son en conjunto el rango mas alto de la jerarquıa organizacion. Luego del Administrador delınea de negocio, se tiene un apoyo de la Secretaria, quien esta al mismo nivel de todos losconductores de los vehıculos.

La companıa realiza sus operaciones en la carrera 28 #12B-66, en el barrio Ricaurte deBogota. Ver Figura 3.2.

Figura 3.2: Punto de Vista Organizacional - Fuente: los autores

3.2. PUNTO DE VISTA DE COOPERACION 79

3.2. Punto de vista de cooperacion

3.2.1. Metamodelo P.V cooperacion

Los actores se veran involucrados entre sı al realizar tareas de forma conjunta, a traves deun artefacto llamado colaboracion. Las labores conjuntas se pueden desarrollar a traves deservicios, que son expuestos a traves de interfaces. Dichos servicios cumpliran con las ne-cesidades que tiene la companıa para sus clientes, ya sean internos o externos.

Como se puede observar en la figura 3.3, un servicio del negocio hara uso de las inter-faces de aplicacion expuestas para utilizar un componente de software.

Figura 3.3: Metamodelo Punto de Vista Cooperacion - Fuente: Sandro Bolanos

3.2.2. Aplicacion P.V Cooperacion

Para la funcion incluida en la Figura 3.4, se plasma el proceso de recepcion de vehıculos ysus subprocesos a nivel de cada uno de los roles participantes, Administrador y Conducto.En este diagrama ya se puede evidenciar que podemos agrupar a partir de los conductoresun rol llamado Taxista, el cual tiene como obligaciones lavar, tanquear, revisar el estado delvehıculo a su cargo, para posteriormente al momento de entregarlo, informar cualquier no-vedad sobre el mismo. Como tarea adicional el taxista debe entregar el producido del dıa.


El administrador estara a cargo de recibir el vehıculo y la informacion del estado del mis-mo, al igual que el producido del dıa. Todo lo anterior dejandolo registrado en el sistemaCIETaxiMonitor.

Figura 3.4: Punto de Vista Cooperacion - Fuente: los autores

3.3. PUNTO DE VISTA DE FUNCION DE NEGOCIO 81

3.3. Punto de vista de funcion de negocio

3.3.1. Metamodelo P.V Funcion de negocio

La figura 3.5 como un actor tiene asociado a su rol dentro de la organizacion, una serie defunciones de negocio acorde a su labor. Normalmente estas funciones estan plasmadas enun manual que la companıa elabora acorde a temas contractuales y limitacion de accion delempleado, basados en criterios de recursos y competencias.

Las funciones pueden desarrollarse por secuencia, siguiendo un flujo (flecha discontinua)y pueden ser tambien acciones que desencadenan otras funciones (flecha continua).

Figura 3.5: Metamodelo Punto de Vista de Funcion de Negocio - Fuente: Sandro Bolanos

3.3.2. Aplicacion P.V Funcion de negocio

Para la funcion incluida en la figura 3.6, se plasma el proceso de recepcion de vehıculos ysus funciones de negocio para cada uno de los roles participantes: Administrador y Con-ductor.

Las funciones expuestas para el actor Conductor, con rol Taxista, son las siguientes:

• Lavar el vehıculo,

• Tanquear o llenar el tanque de combustible del vehıculo

• Realizar el inventario de elementos del vehıculo

• Entregar el vehıculo en condiciones pactadas con el administrador

• Entregar el producido del dıa (dinero producto de las carreras).

La funcion de negocio “realizar el inventario” desencadena la realizacion de otra funcion,llamada “informar problemas tecnicos”, que se informa en el momento que el Administradorrecibe el vehıculo.


Figura 3.6: Punto de Vista de Funcion de Negocio - Fuente: Los autores

El administrador estara a cargo de:

• Recibir el vehıculo

• Registrar la informacion del estado del mismo

• Registrar el producido del dıa.

Lo anterior queda consignado en sistema CIETaxiMonitor.

3.4. PUNTO DE VISTA DE PROCESO DE NEGOCIO 83

3.4. Punto de vista de proceso de negocio

3.4.1. Metamodelo P.V Proceso de negocio

El Proceso de negocio es uno de los elementos mas complejos pero a su vez brinda masinformacion sobre la Arquitectura Empresarial. En el centro de la figura 3.7 esta el procesoo funcion de negocio, representado por una flecha grande dirigida hacia la derecha. Elproceso puede ser iniciado o puede iniciar por un evento de negocio; esto dependera delcontexto donde se encuentra enmarcado.

Figura 3.7: Metamodelo Punto de Vista Proceso de Negocio - Fuente: Sandro Bolanos

El servicio de negocio, para cumplir con la satisfaccion del cliente, usara el proceso de ne-gocio para dar respuesta a su objetivo y se vera reflejado en el Objeto de negocio. Deforma especıfica, el servicio de negocio se vera como una representacion con un nivel deimportancia dentro de la organizacion.

Por otro lado, el proceso de negocio desencadenara una serie de interacciones con la co-laboracion entre los roles que se le asigna a cada actor de la companıa. Finalmente losobjetos de negocio tendran su campo de accion en la ubicacion que designe la organizacionpara cumplir con el proceso o funcion de negocio.


3.4.2. Aplicacion P.V Proceso de Negocio

Tomando como base el proceso de negocio “Transportar pasajeros de forma segura, comoday eficiente”, se muestra en la figura 3.8 la colaboracion entre Taxista y Pasajero para efectuardicho proceso. Adicional se puede visualizar los subprocesos que incluye “Transportar Pasa-jeros” (Seleccionar ruta, Acomodacion de Pasajero, Ejecucion del Servicio y Cobro Servicio)y cada uno de los eventos que se obtienen del proceso general

Figura 3.8: Punto de Vista Proceso de Negocio - Fuente: los autores

3.5. PUNTO DE VISTA DE COOPERACION DE PROCESO DE NEGOCIO 85

3.5. Punto de vista de Cooperacion de Proceso de Negocio

3.5.1. Metamodelo P.V Cooperacion de Proceso de Negocio

Se trabaja de forma similar a la seccion 4.4, ver figura 3.7.

3.5.2. Aplicacion P.V de Cooperacion de Proceso de Negocio

De nuevo se toma el servicio de negocio “Transportar pasajeros de forma segura, comoday eficiente” y dos actores entran en cooperacion para garantizar la calidad del vehıculo: elconductor en su rol de taxista, quien debe cumplir con el proceso de alistamiento de vehıculo,y el administrador,quien debe asegurar el control de mantenimientos del vehıculo.

Figura 3.9: Punto de Vista de Cooperacion de Proceso de Negocio - Fuente: los autores


3.6. Punto de vista de Producto

3.6.1. Metamodelo de P.V de producto

El enfoque de este punto de vista por supuesto es el producto que tiene o que tendra laorganizacion, ilustrado en 3.10 pero aun mas importante es el valor, importancia o utilidadque ofrecera el producto. Para poder lograrlo, el producto se compone de contratos queespecifican una serie de derechos y obligaciones asociadas con el producto. El productose apoya en servicios que van de la mano con el proceso que entra a reforzar. La idea delproducto es que utilice componentes de aplicacion a nivel tecnologico que interactuan conel proceso que entran a reforzar.

Figura 3.10: Metamodelo Punto de Vista de Producto - Fuente: Sandro Bolanos

3.6.2. Aplicacion de P.V de Producto

El prototipo de la aplicacion CIETaxiMonitor, mostrado en la figura 3.11 dara como benefi-cios a la empresa:

3.6. PUNTO DE VISTA DE PRODUCTO 87

• Evaluacion del personal: permitira llevar un mejor control de los conductores y po-derlos categorizar segun su rendimiento.

• Control y disminucion de gastos: Se evitaran fugas de capital, puesto que existiraun registro mas detallado y controlado.

• Reduccion de mantenimiento correctivo: Teniendo el estado detallado de cadavehıculo se facilita hacerles seguimiento para repararlos cuando lo requieran de formapreventiva y no correctiva.

• Control de Producido: Se podra analizar de forma mas sencilla y controlada el ingre-so que se tiene por cada vehıculo y su rentabilidad.

Figura 3.11: Punto de Vista de Producto - Fuente: los autores

Tambien se incluyen los controles de mantenimiento y de manejo de personal, al igual quelos soportes documentales que se tiene en cuanto a la contratacion de mantenimiento comoa los contratos laborales con los conductores.


Capıtulo 4

Diseno de Arquitectura de Aplicacion

4.1. P.V. Comportamiento de Aplicacion

4.1.1. Metamodelo de P.V de Comportamiento de Aplicacion

El enfoque de este punto de vista permite identificar los diferentes componentes que hacenparte de la aplicacion y que se ilustran en la figura 4.1, al igual que resaltar la interaccionentre los diferentes modulos de la misma y los eventos que o acciones que se tiene en cadauno de los componentes de software.

Figura 4.1: Metamodelo Punto de Vista de Comportamiento de Aplicacion - Fuente: SandroBolanos

89

90 CAPITULO 4. DISENO DE ARQUITECTURA DE APLICACION

4.1.2. Aplicacion P.V de Comportamiento de Aplicacion

Aquı podemos apreciar en la figura 4.2, como los dos grandes modulos que incluye la solu-cion Taximonitor, que son Gestion de conductores, y Gestion de vehıculos. En Gestion deconductores hay unos sub modulos que permiten registrar la informacion de comparendos,contratos, licencias de conduccion, documentacion adicional y tarjetas de operacion para losconductores; y por el lado de Gestion de Vehıculos, se tiene la gestion de accidentes, man-tenimientos, gastos, y la lista de chequeo, que es donde se podran identificar diariamente elestado de cada uno de los vehıculos de la flotilla de taxis.

Figura 4.2: Punto de vista Comportamiento de Aplicacion - Fuente: los autores

4.2. P.V. Cooperacion de Aplicacion

4.2.1. Metamodelo de P.V de Cooperacion de Aplicacion

El enfoque de este punto de vista nos permite identificar la cooperacion que existe entrelos diferentes componentes de la aplicacion dentro de una ubicacion determinada, se puedeobservar el metamodelo en la figura 4.3.

4.2. P.V. COOPERACION DE APLICACION 91

Figura 4.3: Metamodelo Punto de Vista de Cooperacion de Aplicacion - Fuente: SandroBolanos

4.2.2. Aplicacion P.V de Cooperacion de Aplicacion

Con base en la aplicacion Taximonitor que propone el proyecto, se puede ver en la figura4.4 como en la ubicacion Centro de Inversiones Empresariales se tienen los componentesde gestion de Vehıculos y gestion de conductores.

Figura 4.4: Punto de vista Cooperacion de Aplicacion - Fuente: los autores


4.3. P.V. Estructura de Aplicacion

4.3.1. Metamodelo de P.V de Estructura de Aplicacion

En este punto de vista se pueden observar los componentes de la aplicacion, y sus interfacescon las diferentes estructuras de informacion que posee el sistema. Al igual se puedenobservar las colaboraciones que puedan existir al interior de la aplicacion como se puedeobservar en la figura 4.5. Es de resaltar que desde este diagrama se empieza a tener unaidea mas relacionada con el modelo de datos donde se dejara almacenada la informacionque requiere el sistema de informacion o aplicacion que se esta modelando.

Figura 4.5: Metamodelo Punto de Vista de Estructura de Aplicacion - Fuente: Sandro Bo-lanos


En la figura 4.6 se puede observar como la aplicacion Taximonitor en su modulo de Gestionde Vehıculos tiene algunas interfaces con los sub modulos polizas, gastos, mantenimientos;al igual que el modulo de Gestion de conductores con los sub modulos de contratos, do-cumentacion, licencias de conduccion, tarjetas de operacion, comparendos y gestion deaccidentes. Tambien se pueden identificar algunas estructuras donde se almacenara la in-formacion tales como Datos de contratos, Datos de Conductores y TaxiCheck que es dondese lleva a cabo la lista de chequeo diaria para cada uno de los vehıculos que hacen partede la flotilla de taxis del Centro de Inversiones Empresariales.

4.4. P.V. USO DE APLICACION 93

Figura 4.6: Punto de Vista de Estructura de Aplicacion - Fuente: los autores

4.4. P.V. Uso de Aplicacion

4.4.1. Metamodelo de P.V de Uso de Aplicacion

Basado en el modelo de negocio en este punto de vista se puede ver como interactuan ca-da uno de los componentes de la aplicacion con respecto a los procesos de negocio y a suvez las los roles, objetos e interfaces de la aplicacion. En la figura 4.7 se observa como elproceso de negocio se apoya en el servicio de aplicacion para llevarse a cabo, al igual comose relacionan el objeto de negocio con la estructura de aplicacion. Es de resaltar que estediagrama es muy importante para poder identificar en que punto llega a intervenir o apoyarla capa de aplicacion a la capa de negocio.


Figura 4.7: Metamodelo Punto de vista de Uso de Aplicacion - Fuente: Sandro Bolanos


Para la aplicacion de este punto de vista, se partio del proceso del Centro de InversionesEmpresariales Administracion de Personal, el cual esta directamente relacionado con elmodulo de Gestion de conductores. Se observa en la figura 4.8 como en el proceso denegocio de contratacion se apoya desde la capa de aplicacion con el proceso Servicio decontratacion, el que a su vez tiene dos sub modulos para gestionar los contratos y la docu-mentacion de cada uno de los conductores. Por otro lado, el proceso de negocio de vincula-cion tiene un apoyo a nivel de aplicacion con el servicio de registro de conductores, para elcual existe el componente de aplicacion gestion de conductores.

Figura 4.8: Punto de Vista de Uso de Aplicacion - Fuente: los autores

Capıtulo 5

Diseno de Arquitectura deInfraestructura y Datos

5.1. P.V. de Infraestructura

5.1.1. Metamodelo de P.V de Infraestructura

En este punto de vista se incluyen los elementos de hardware e infraestructura tecnologicaque se tiene identificados, y que soportaran a las aplicaciones que se tienen dentro del di-seno de arquitectura empresarial. Como se observa en la figura 5.1, se incluyen las posiblesterminales del sistema, mencionando las respectivas ubicaciones de cada una, y sus res-pectivos protocolos de comunicacion por medio de los cuales se comunican. Tambien sirveeste punto de vista para identificar como es el flujo de la informacion entre los diferentescomponentes fısicos que hacen parte de la solucion tecnologica.

5.1.2. Aplicacion P.V de Infraestructura

En este punto de vista para el caso de estudio como se indica en al figura 5.2, se tuvieron encuenta dos ubicaciones, la primera el Centro de Inversiones Empresariales, que es dondese tendran los clientes del sistema, tanto en PC como en Tabletas o dispositivos moviles.Dentro de los dispositivos moviles se tendra el componente de software TaxiCheck que seradesde allı donde se hara la tarea de lista de chequeo a los vehıculos cuando el conductortermina su turno diario de trabajo. Tambien se incluye la ubicacion Nube, que sera en dondese alojara la aplicacion TaxiMonitor, y mas precisamente en el contenedor de MicrosoftAzure.

Entre la plataforma de Azure y el Centro de Inversiones Empresariales se tendra una comu-nicacion entre la aplicacion y el cliente por medio de Internet.

95

96 CAPITULO 5. DISENO DE ARQUITECTURA DE INFRAESTRUCTURA Y DATOS

Figura 5.1: Metamodelo Punto de Vista de Infraestructura - Fuente: Sandro Bolanos

Figura 5.2: Punto de Vista de Infraestructura - Fuente: los autores

5.2. P.V. DE USO DE INFRAESTRUCTURA 97

5.2. P.V. de Uso de Infraestructura

5.2.1. Metamodelo de P.V de Uso de Infraestructura

Este punto de vista ilustra la interaccion entre los componentes definidos para la capa dearquitectura y los servicios, eventos y componentes de aplicacion que van a dar uso de lainfraestructura. Adicional a las aplicaciones se incluyen los principales componentes de lamisma y su respectiva interaccion justo como se muestra en la figura 5.3.

Figura 5.3: Metamodelo Punto de Vista de Uso de Infraestructura - Fuente: Sandro Bolanos

5.2.2. Aplicacion P.V de Uso de Infraestructura

En la aplicacion de este punto de vista, como se puede observar en la figura 5.4, se incluyenlos clientes de la aplicacion en la ubicacion Centro de Inversiones Empresariales, y en la


Nube, y mas precisamente en el componente Azure, esta la aplicacion Taximonitor, la cualtiene un componente Gestor que se encarga de gestionar los vehıculos y los conductores.De esta forma dichos componentes de aplicacion estan contenidos en los componentes deinfraestructura que se puede apreciar en el grafico.

Figura 5.4: Punto de Vista de Uso de infraestructura - Fuente: los autores

5.3. P.V. Organizacion e implementacion

5.3.1. Metamodelo de P.V de Organizacion e implementacion

Este punto de vista como se ve en la figura 5.5, incluye los elementos de hardware quehacen parte de la infraestructura que soportara las aplicaciones incluidas en el diseno delcaso de estudio, al igual los protocolos de comunicacion que se utilizan para llevar a cabola interaccion entre los diferentes componentes de infraestructura. Tambien se puede iden-tificar como se relacionan los componentes de aplicacion con los objetos de datos, que esdonde se almacenara la informacion a nivel de aplicacion. Como algo adicional, se incluyela colaboracion que pueda existir entre los componentes de aplicacion para lograr llevar acabo un servicio de negocio.

5.3.2. Aplicacion P.V de Organizacion e implementacion

En este punto de vista, a diferencia del de Uso de infraestructura, se incluye la colaboracionque existe entre el componente de aplicacion TaxiCheck y el elemento de infraestructura

5.4. P.V. ESTRUCTURA DE INFORMACION 99

Figura 5.5: Metamodelo Punto de Vista de Organizacion e Implementacion - Fuente: SandroBolanos

Azure, el cual va a tener colaboracion directa con TaxiChek por medio de SOA. La aplicacionde este punto de vista se pude observar en la figura 5.6.

5.4. P.V. Estructura de Informacion

5.4.1. Metamodelo de P.V de Estructura de Informacion

Este punto de vista que se observa en la figura 5.7 ilustra como se relacionan los diferentesobjetos identificados en la capa de negocio, con las estructuras de aplicacion, al igual queel flujo de informacion entre ellos. Tambien se incluyen si es necesario los artefactos deinfraestructura que apoyan la realizacion de cada estructura de informacion a nivel de lacapa de aplicacion.


Figura 5.6: Punto de Vista de Organizacion e Implementacion - Fuente: los autores

Figura 5.7: Metamodelo Punto de Vista de Estructura de Informacion - Fuente: Sandro Bo-lanos

5.4.2. Aplicacion P.V de Estructura de Informacion

El punto de vista para el caso de estudio, es presentado en la figura 5.8, e incluye la re-lacion entre el objeto de negocio CIE TaxiMonitor y su elemento estructura de aplicacionConductor, la cual incluye otras estructuras como Licencia, Comparendo y Accidente. Esta

5.5. P.V. DE REALIZACION DEL SERVICIO 101

ultima tambien se incluye informacion del vehıculo que se ve involucrado en el siniestro.

Figura 5.8: Punto de Vista de Estructura de Informacion - Fuente: los autores

5.5. P.V. de Realizacion del Servicio

5.5.1. Metamodelo de P.V de Realizacion del Servicio

El punto de vista de realizacion del servicio que se observa en la figura 5.9, se basa princi-palmente en los componentes de la capa de negocio en donde se describıan los procesosy cadena de valor para lograr efectuar el servicio descrito. Al igual, en este punto de vistase relacionan directamente los objetos de negocio con las estructuras de informacion de lacapa de aplicacion, y los componentes de arquitectura que los van a contener.

5.5.2. Aplicacion P.V de Realizacion del Servicio

En la figura 5.10 se observa que basado en los servicios de control de taxis y taxistas, y enlos procesos de Gestion de Vehıculos y Gestion de Conductores respectivamente, se creanlas estructuras de aplicacion Conductor y Vehıculo, los que a su vez se consumen por laaplicacion CIE Taximonitor que se aloja en Azure ubicado en la nube.


Figura 5.9: Metamodelo Punto de Vista de Realizacion del Servicio - Fuente: Sandro Bolanos

Figura 5.10: Punto de Vista de Realizacion del Servicio - Fuente: los autores

5.6. P.V. DE CAPAS 103

5.6. P.V. de Capas

5.6.1. Metamodelo de P.V de Capas

En este punto de vista se separan cada uno de los elementos del diagrama de realizaciondel servicio en cada una de las capas de arquitectura a que pertenecen, tal como se puedever en el metamodelo del punto de vista en la figura 5.11. El diagrama se debera separar enlas capas de negocio, aplicacion e infraestructura.

Figura 5.11: Metamodelo Punto de Vista de Capas - Fuente: Sandro Bolanos

5.6.2. Aplicacion P.V de Capas

El proceso de realizacion de servicio, donde se involucraban elementos de las capas denegocio, aplicacion e infraestructura, se ilustran de forma mas organizada segun lo proponeel punto de vista de capas de la figura 5.12.


Figura 5.12: Punto de Vista de Capas - Fuente: los autores

Capıtulo 6

Diseno de Arquitectura Motivacional

6.1. P.V. de Stakeholder

6.1.1. Metamodelo de P.V de Stakeholder

El punto de vista de Stakeholder como su nombre lo indica, incluye a los actores y rolesinvolucrados en el proceso de negocio, al igual que los objetivos, manejadores y valoracionesque se relacionen o interactuen entre ellos. El metamodelo de este punto de vista se puedeobservar en la figura 6.1.

Figura 6.1: Metamodelo Punto de Vista de Stakeholder - Fuente: Sandro Bolanos

105

106 CAPITULO 6. DISENO DE ARQUITECTURA MOTIVACIONAL

6.1.2. Aplicacion de P.V de Stakeholder

Para el caso de este punto de vista se hara la aplicacion basados en el objetivo de la or-ganizacion “Elaborar estrategias de apoyo a las labores administrativas”, sobre el cual hayuna relacion directa con el rol Administrador, y Gerente, que seran los encargados en gene-rar y apoyar dichas estrategias de negocio. Se incluyen dos valoraciones que afectan dichoobjetivo como se puede observar 6.2.

Figura 6.2: Punto de Vista de Stakeholder - Fuente: los autores

6.2. P.V. de Realizacion de Objetivos

6.2.1. Metamodelo de P.V de Realizacion de Objetivos

Para este metamodelo se incluyen los requerimientos y restricciones que pueden afectar larealizacion de los objetivos incluidos en el diseno. Tambien se involucran los stakeholders oroles que apoyen la ejecucion del mismo como se observa en la figura 6.3.

6.2.2. Aplicacion de P.V. de Realizacion de Objetivos

En la aplicacion de este punto de vista para el caso de estudiose incluyo el objetivo de laorganizacion “Brindar atencion al pasajero con calidad y calidez” sobre el cual participanlos Roles Conductor y Administrador y sus respectivos requerimientos para poder lograr larealizacion del objetivo. Este diseno se observa en la figura 6.4.

6.2. P.V. DE REALIZACION DE OBJETIVOS 107

Figura 6.3: Metamodelo Punto de Vista de Realizacion de Objetivos - Fuente: Sandro Bo-lanos

Figura 6.4: Punto de Vista de Realizacion de Objetivos - Fuente: los autores


6.3. P.V. de Contribucion

6.3.1. Metamodelo de P.V de Contribucion

El punto de vista de contribucion permite la identificacion de principios, requerimientos eincluyo objetivos especificos que permitan la realizacion de el objetivo general sobre el cualse este efectuando el diseno. El metamodelo para este punto de vista se puede observar enla figura 6.5.

Figura 6.5: Metamodelo Punto de Vista de Contribucion - Fuente: Sandro Bolanos

6.3.2. Aplicacion P.V de Contribucion

Para el caso de estudio y diseno de este punto de vista, se tomo el mismo objetivo del puntoanterior, sobre el cual se identifo que es necesario cumplir con unos objetivos especıficospara lograr cumplir con el requerimiento “Es necesario tener los vehıculos en buen estadomecanico y bien presentado”. Lo anterior se puede observar en la figura 6.6.

6.4. P.V. de Principios

6.4.1. Metamodelo de P.V de Principios

En este punto de vista se indentifican los principios de la que organizacion que puedentener relacion con la realizacion del objetivo que se este tratando en el diseno. Para tener unmejor entendimiento tambien se pueden involucrar mas elementos de la capa motivacional.El metamodelo de este punto de vista es el ilustrado en la figura 6.7.

6.4. P.V. DE PRINCIPIOS 109

Figura 6.6: Punto de Vista de Contribucion - Fuente: los autores

Figura 6.7: Metamodelo Punto de Vista de Principios - Fuente: Sandro Bolanos

6.4.2. Aplicacion P.V de Principios

En la aplicacion del punto de vista de principios para el caso de estudio, se tomo comoobjetivo “Elaborar estrategias de apoyo a las labores administrativas” y se involucraron losvalores organizacionales de Innovacion, Calidad. Se incluyen tambien valoraciones que se


tendrıa como resultado de la realizacion del objetivo. El diseno se puede ver en la figura 6.8.

Figura 6.8: Punto de Vista de Principios - Fuente: los autores

6.5. P.V. de Realizacion de Requerimientos

6.5.1. Metamodelo de P.V de Realizacion de Requerimientos

En este punto de vista se da un mayor detalle al punto de vista de realizacion de objetivos,en el que se especificaban requerimientos y restricciones para lograr la realizacion de unobjetivo. Para este caso se incluye mas informacion sobre pre requisitos de los requerimien-tos y/o restricciones del objetivo que se este disenando. El metamodelo para este punto devista se puede observar en la figura 6.9.

Figura 6.9: Metamodelo Punto de Vista de Realizacion de Requerimientos - Fuente: SandroBolanos

6.6. P.V. DE MOTIVACION 111

6.5.2. Aplicacion P.V de Realizacion de Requerimientos

El diseno de este punto de vista parta de lo disenado previamente en el punto de vista derealizacion de objetivos. Se incluye otro nivel mas detallado de requerimiento que sera prerequisito de la realizacion del requerimiento principal “Es necesario tener los vehıculos enbuen estado mecanico y bien presentados”. Se puede observar como se generaron dos prerequisitos, uno responsabilidad del conductor, y del otro el administrador sera en encargado.El diseno explicado se ilustra en la figura 6.10.

Figura 6.10: Punto de Vista de Realizacion de Requerimientos - Fuente: los autores

6.6. P.V. de Motivacion

6.6.1. Metamodelo de P.V de Motivacion

Este punto de vista incluye todos los componentes que se han disenado previamente, y susrespectivas interacciones. Todo el diseno se va a centrar en la realizacion del objetivo de laorganizacion como se ve en la figura 6.11.


Figura 6.11: Metamodelo Punto de Vista de Motivacion - Fuente: Sandro Bolanos

6.6.2. Aplicacion P.V de Motivacion

Para la aplicacion del punto de vista de motivacion, se partio del objetivo de la organizacion“Brindar atencion al pasajero con calidad y calidez” sobre el cual se incluyen los principios,roles, requerimientos y pre requisitos para su respectiva realizacion tal como se muestra enla figura 6.12.

Figura 6.12: Punto de Vista de Motivacion - Fuente: los autores

Capıtulo 7

Diseno de Arquitectura de Proyecto

7.1. P.V. de Proyecto

7.1.1. Metamodelo de P.V de Proyecto

El punto de vista de proyecto se basa al igual que los anteriores en la realizacion de unobjetivo, solo que para este caso ya se generan los paquetes de trabajo y entregables delproyecto que propone el diseno de arquitectura. La idea es que cada paquete de trabajo yatengo definido el responsable de llevar a cabo el su ejecucion. En diagrama del meta modelode la figura 7.1.

Figura 7.1: Metamodelo Punto de vista de Proyecto - Fuente: Sandro Bolanos

7.1.2. Aplicacion de P.V de Proyecto

Para aplicar este punto de vista en el caso de estudio, se partio del objetivo ”Brindar atencional pasajero con calidad y calidez”, para lo que se definio un requerimiento que implica tener

113

114 CAPITULO 7. DISENO DE ARQUITECTURA DE PROYECTO

actualizado el historico de mantenimiento de los vehıculos para realizar los mantenimientospreventivos del mismo. Como paquete de trabajo se incluyo entonces un prototipo de soft-ware para apoyar dicha labor administrativa. Tenemos entonces como salida del paquetede trabajo, el prototipo de software, el cual debera ejecutar el area de sistemas como semuestra en la figura 7.2.

Figura 7.2: Punto de vista de Proyecto - Fuente: los autores

Capıtulo 8

Diseno de Arquitectura de Migracion

8.1. P.V. de Migracion

8.1.1. Metamodelo de P.V de Migracion

En este punto de vista se incluyen basicamente dos componentes, las mesetas o plateas,que son las versiones de evolucion de nuestro sistema o proceso de negocio. Y las brechasque son los mecanismos para lograr llegar a cada meseta. El meta modelo de este punto devista se puede observar en la figura 8.1.

Figura 8.1: Metamodelo Punto de vista de Migracion - Fuente: Sandro Bolanos

8.1.2. Aplicacion de P.V de Migracion

Aplicando este punto de vista, se pude observar en la figura 8.2 como se proyecta la evolu-cion del proceso de mantenimiento preventivo para la companıa, al igual que se ve relacionde como las brechas apoyan dicha evolucion.

115

116 CAPITULO 8. DISENO DE ARQUITECTURA DE MIGRACION

Figura 8.2: Punto de vista de Migracion - Fuente: los autores

8.2. P.V. de Migracion e Implementacion

8.2.1. Metamodelo de P.V de Migracion e Implementacion

En el meta modelo de este punto de vista se incluye el paquete de trabajo que permitirallevar a cabo la platea o meseta, y sus respectivos componentes adicionales como son elresponsable, la ubicacion, el entregable, y si es el caso, los requerimientos y/o restriccionesque estaran relacionadas con el objetivo de la organizacion. La figura 8.3 nos muestra estemeta modelo.

Figura 8.3: Metamodelo Punto de vista de Migracion e Implementacion - Fuente: SandroBolanos

8.2. P.V. DE MIGRACION E IMPLEMENTACION 117

8.2.2. Aplicacion de P.V de Migracion e Implementacion

Para el caso de estudio se tomara en cuenta solo la meseta de ”Historial de mantenimientode vehıculos”, y vemos como se relaciona con el entregable del paquete de trabajo que seilustro en el punto de vista de proyecto. Tambien, como se puede apreciar en la figura 8.4,se relaciona el objetivo y responsable del paquete.

Figura 8.4: Punto de vista de Migracion e Implementacion - Fuente: los autores

118 CAPITULO 8. DISENO DE ARQUITECTURA DE MIGRACION

Parte IV

CIERRE DE LA INVESTIGACION

119

Capıtulo 9

Conclusiones

El presente trabajo establecio un diagnostico del estado actual de la empresa Centro deInversiones Empresariales a traves de una matriz DOFA. Dicho diagnostico revelo que sibien la linea de negocio en que se encuentran enfocados, transporte publico individual, tie-ne musculo financiero, es rentable, cuentan con experiencia e infraestructura para crecer, nose puede descuidar elementos como el no uso de tecnologıas de informacion aplicadas enel desarrollo de la actividad economica y deben estar siempre atentos al comportamiento delmercado con competencias emergentes como Uber y la competencia tradicional con otrosmedios de transporte en Bogota.

Los disenos de arquitectura empresarial permitieron conocer de forma mas profunda elcomportamiento y funciones que tiene la empresa en sus actividad economica. Este puntode vista de alto nivel permitio establecer que procesos son los mas importantes para sercomplementados con soluciones de TI, y que si bien no da detalles profundos de implemen-tacion, si da una hoja de ruta para la construccion de herramientas de software y su futuroimpacto dentro de la organizacion.

El prototipo de software elaborado para el presente proyecto se llevo a cabo mediante elmodelado del negocio a traves de Entity Framework, y permitio generar el codigo necesariopara interactuar con la base de datos disenada para TaxiMonitor. Las lıneas de codigo ge-neradas por Entity Framework permitieron que se enfocara el trabajo mas en la parte visual(front end) que en la parte de almacenamiento de datos (backend). Si bien EF genera unosformularios HTML para la captura de datos, se quiso dar un impacto visual mas acorde ala lınea del negocio. Es por esto que se adapto una plantilla, basada en un framework webllamado Bootstrap y se logro un prototipo bastante llamativo y agradable para el usuariofinal.

121

122 CAPITULO 9. CONCLUSIONES

Capıtulo 10

Prospectiva del trabajo de grado

10.1. Lıneas de investigacion futuras

A partir del planteamiento del actual proyecto y la informacion que recolectara TaxiMonitor,se pueden plantear las siguientes lıneas de investigacion:

• Inteligencia de Negocios

• Internet de las Cosas (IOT)

• Inteligencia de regla de negocios

10.2. Trabajos de investigacion futuros

Con las construccion del prototipo y los lineamientos generados desde la vision de Arquitec-tura empresarial, se pueden generar trabajos posteriores:

• Ampliacion de los requerimientos de software para modulos no contemplados en lafase de prototipado.

• Creacion de reglas de negocio para la aplicacion de software

• Integracion con el Sistema de Registro Unico de Transito (RUNT) para la descarga decomparendos o multas que puedan causar los conductores en el ejercicio de transpor-te publico individual.

• Inteligencia de negocios (BI) basado en la informacion que captura el sistema de in-formacion TaxiMonitor, bien para predecir duracion de los repuestos de los vehıculos,como analisis de la rotacion del personal encargado de conducir los automoviles.

123

124 CAPITULO 10. PROSPECTIVA DEL TRABAJO DE GRADO

• Generacion de informacion a partir de los mismos conductores de los taxis a travesaplicaciones moviles conectadas al sistema Taxi Monitor.

• Generacion de informacion autonoma que el vehıculo puede transmitir hacia Taxi Mo-nitor sin intervencion humana.

• Integracion con el sistema de seguimiento satelital para determinar el uso y abuso alque se somete el vehıculo por parte de los conductores designados.

Apendice A

Resumen PESI para C.I.E.

125

RESUMEN GERENCIAL

PROPUESTA DE PLANEACIÓN ESTRATÉGICA BASADA EN TECNOLOGÍAS DE LA INFORMACIÓN PARA LA UNIDAD DE NEGOCIO DE TRANSPORTE PARA LA EMPRESA CENTRO DE INVERSIONES EMPRESARIALES

GIOVANNI GARCÍA RODRÍGUEZ – COD: 20161099010

CESAR AUGUSTO BOLAÑOS CARDOZO – COD: 20161099003

INTRODUCCIÓN

Se parte del hecho que los propietarios de taxis no conforman empresa alrededor del ejercicio de la actividad, transporte público individual, debido a que no hay regulación por parte del Estado

colombiano que lo obligue, pero si se quiere dar una dirección empresarial al desarrollo de la actividad de acuerdo a lineamientos establecidos en gerencia de negocios y darle un aire de pequeña empresa para una ejecución efectiva.

La empresa Centro de Inversiones Empresariales, con NIT 900377468-6, ubicada en el barrio Ricaurte de la ciudad de Bogotá, en su línea de negocio de Transporte Publicó Individual será el centro del ejercicio del actual proyecto, la cual se compone por una flotilla de taxis como activos y personal dedicado tanto a la labor operativa (conductores) como a labores administrativas (administrador).

Para el actual proyecto, se propone la siguiente metodología:

a. Creación de la misión. Como se menciona anteriormente, el ejercicio de la actividad de transporte público individual (TPI)

no es obligante a constitución de empresa. Es ahí donde se debe crear la misión y objetivos que los propietarios de estos vehículos sientan como si estuviesen creando empresa de manera formal. Al no existir estos elementos, se parte prácticamente de ceros.

b. Análisis de entorno – evaluación externa c. Identificación de Oportunidades y amenazas d. Análisis de recursos – evaluación interna

e. Identificación de Fortalezas y debilidades f. Formulación de objetivos y estrategias

126

FORMULACIÓN DE NUEVA MISIÓN

La línea de negocio de transporte público individual, de la compañía Centro de Inversiones Empresariales, se dedica a administrar los automotores de su propiedad, buscando ofrecer un servicio confiable y óptimo a todos sus pasajeros de su flotilla de taxis, al igual que generar empleo a los conductores mejor calificados para dicha labor.

La empresa no contaba con una misión definida para ésta línea de negocio, por lo que se formuló una nueva con la ayuda del siguiente cuadro:

Elemento VALORACION

Cumple No Actualizar Complementar

Actividad Económica X

Segmento del Mercado X

Valores Institucionales X

Imagen Institucional X

Responsabilidad Empresarial

X

EVALUACIÓN EXTERNA

Mediante el instrumento POAM se determinó cuáles variables encajan en las Oportunidades y Amenazas de la actual propuesta de Planeación estratégica y se exponen a continuación.

TIPO VAR UNIDAD DE ANÁLISIS Y VARIABLES

Importancia

Impacto Evaluación Ponderada

(1 a 5) (-3 a 3) (-15 a 15)

Ec

on

óm

ica

s

Poder adquisitivo 5 0 0

Valor de combustible 5 -2 -10

Tasa de cambio 2 1 2

Tasas de interés 3 -2 -6

Lucro Patrimonial 5 3 15

Valorización del cupo 4 2 8

So

cia

les

, c

ult

ura

les

,

de

mo

grá

fic

as

,

po

líti

ca

s

Actitud hacia la atención al cliente 5 -3 -15

Congestión del trafico 4 -2 -8

Control de la contaminación 2 -2 -4

Programas sociales 2 -2 -4

Red de transporte privado (UBER) 4 -3 -12

Seguridad y orden publico 4 1 4

127

TIPO VAR UNIDAD DE ANÁLISIS Y VARIABLES

Importancia

Impacto Evaluación Ponderada

(1 a 5) (-3 a 3) (-15 a 15)

Desastres naturales 3 -2 -6

Ju

ríd

ica

Reforma tributaria 3 -1 -3

Legislación de (UBER) 4 -3 -12

Codigo nacional de transito 2 2 4

Codigo sustantivo del trabajo 2 -2 -4

Te

cn

oló

gic

as

Competencia - -

Planeación y organización de SI/TI 1 1 1

Aplicación de tecnologías a la producción 3 1 3

Infraestructura 3 -2 -6

Facilidad de acceso a la tecnología 3 -1 -3

Clientes - -

Resistencia al cambio tecnológico 5 -3 -15

Facilidad de acceso a la tecnología 5 2 10

Proveedores - -

Resistencia al cambio tecnológico 3 -2 -6

Planeación y organización de SI/TI de los

proveedores 3 -1 -3

Aplicación de tecnologías a la producción 3 -2 -6

Infraestructura 2 -1 -2

128

EVALUACIÓN INTERNA

Mediante el instrumento PCI se determinaron cuáles variables encajan en las Debilidades y Fortalezas:

TIPO VAR UNIDAD DE ANÁLISIS Y VARIABLES Importancia

(1 a 5) Impacto (-3 a 3)

Evaluación

Ponderada (-15 a 15)

Fin

an

za

s

Rentabilidad 4 3 12

Flujo de Caja 5 3 15

Estabilidad de activos 4 2 8

Capacidad de endeudamiento 3 2 6

Estabilidad de costos 3 2 6

Pro

du

cc

ión

Estandarización 1 1 1

Infraestructura 5 3 15

Me

rca

de

o Impacto de campañas 2 2 4

Presupuesto 1 0 0

Experiencia 5 3 15

Satisfacción del cliente 4 -2 -8

Dir

ectiva

Uso de análisis y planes estratégicos 5 -2 -10

Comunicación 5 2 10

Habilidad para responder a tecnologías cambiantes

5 -3 -15

Sistemas de tomas de decisiones 4 3 12

Ta

len

to H

um

an

o

Nivel académico del recurso humano 5 2 10

Experiencia técnica 5 2 10

Motivación 4 2 8

Nivel de remuneración 3 -2 -6

Ausentismo 5 3 15

Accidentalidad 2 3 6

Retiros 3 2 6

Selección de personal 5 2 10

Manuales de funciones 5 -2 -10

Te

cn

oló

gic

as

Planeación y organización de SI/TI 4 -2 -8

Aplicaciones de tecnologías a la producción 4 -3

-12

Infraestructura 4 3

12

129

FORMULACIÓN DE LA ESTRATEGIA

Para identificar las estrategias candidatas se utilizaron las siguientes herramientas:

- Matriz de la gran estrategia - Matriz DOFA - Matriz Cuantitativa De Planeación Estratégica - Matriz De Planeación Estratégica Vs Factores Claves De Éxito - Comparación de los métodos MCPE y MPEvsFCE

Sobre ésta última se obtuvo el siguiente cuadro donde se observan los resultados del estudio y las estrategias mejor calificadas del mismo.

MCPE

MPEvsFCE

Estategia Candidata TPA

Estrategia Candidata TPA

Adquisición de mas cupos

aprovechando su valorización y los

operarios con que dispone

43

Proponer nuevas alternativas

tecnológicas para dar una mejor

experiencia en el servicio a los

usuarios

3,45

Utilización del flujo de caja para

llevar a cabo inversiones que

permitan crecimiento del patrimonio de la empresa

40

Utilizando la infraestructura de

la compañía generar

herramientas tecnológicas que

den una mejor experiencia al cliente mientras se le presta el

servicio

3,4

130

MCPE

MPEvsFCE

Estategia Candidata TPA

Estrategia Candidata TPA

Elaborar una herramienta que apoye las labores administrativas

de la empresa

40

Elaborar una herramienta que apoye las labores

administrativas de la empresa

3,1

Invertir los recursos de la compañía

para adecuar el sistema de combustible de toda la flotilla a un

combustible más económico como

el gas

-13

Invertir en publicidad que

incentive a los clientes al uso

personalizado de la flotilla por

un medio tecnológico

3,05

Proponer nuevas alternativas

tecnológicas para dar una mejor

experiencia en el servicio a los

usuarios

-26

Prestar un excelente servicio a

los clientes e incentivarlos a la

utilización de los taxis como

medio de transporte público

3

Utilizando la infraestructura de la

compañía generar herramientas tecnológicas que den una mejor

experiencia al cliente mientras se le

presta el servicio

-33

Incluir en el manual de

funciones de los operarios mejores prácticas para hacer

mejor la prestación del servicio

a los usuarios

2,9

Incluir en el manual de funciones

de los operarios mejores prácticas

para hacer mejor la prestación del

servicio a los usuarios

-72

Llevar a cabo las

recomendaciones del plan

estratégico que se esta

elaborando para la compañía

2,55

Levar a cabo las recomendaciones del plan estratégico que se esta

elaborando para la compañía

-75

Utilización del flujo de caja para

llevar a cabo inversiones que

permitan crecimiento del

patrimonio de la empresa

2,4

Prestar un excelente servicio a los

clientes e incentivarlos a la

utilización de los taxis como medio

de transporte público

-

101

Adquisición de mas cupos

aprovechando su valorización y

los operarios con que dispone

1,9

Invertir en publicidad que incentive

a los clientes al uso personalidado

de la flotilla por un medio

tecnológico

-

120

Invertir los recursos de la compañía para adecuar el

sistema de combustible de toda

la flotilla a un combustible más

económico como el gas

1,5

131

132 APENDICE A. RESUMEN PESI PARA C.I.E.

Apendice B

Diccionario de Datos

133

DICCIONARIO DE DATOS

PROTOTIPO TAXIMONITOR

CENTRO DE INVERSIONES EMPRESARIALES

CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN

Id IDENTITY(1) X Primary Identificado de la tabla

TipoIdNombre varchar (3) X Nombre del tipo de identificación

TABLA TipoIdentificacion



GeneroNombre varchar (1) X Nombre del Genero

TABLA Genero



GrupoSanguineoNombre varchar (3) X Nombre del Grupo sanguineo

TABLA GrupoSanguineo



EstadoNombre nvarchar (20) X Nombre del Estado de conductor

TABLA EstadoConductor



CategoriraLicenciaNombre nvarchar (20) X Nombre de la categoria de licencia

TABLA CategoriaLicencia



ClaseVehiculoNombre nvarchar (40) X Nombre de la clase de vehículo

TABLA ClaseVehiculo



TipoServiciooNombre nvarchar (30) X Nombre del tipo de servicio que presta el vehículo

TABLA TipoServicio



MarcaNombre nvarchar (40) X Nombre de la marca de vehículo

TABLA Marca



TipoCarroceriaNombre nvarchar (40) X Nombre del tipo de carroceria

TABLA TipoCarroceria



TipoCombustibleNombre nvarchar (40) X Nombre del tipo de combustible

TABLA TipoCombustible



FkEstadoVehiculoNombre nvarchar (40) X Nombre del estado del vehículo

TABLA EstadoVehiculo



TipoTurnoNombre nvarchar (10) X Nombre del Tipo de turno

TABLA TipoTurno



TipoProveedorNombre nvarchar (10) X Nombre del Tipo de proveedor

TABLA TipoProveedor

134


NroIdentificacion NUMERIC X Primary Numero de identificación del propietario

Nombre nvarchar(100) X Nombre del propietario

Telefono NUMERIC(15) X Telefono del propietario

Direccion nvarchar(100) X Dirreccion de ubicación del propietario

TABLA Propietario


IdRepuesto NUMERIC X Primary Identificador de la tabla

NombreRepuesto nvarchar(100) X Nombre del repuesto

DiasDuracionAprox NUMERIC Duracion en días de duración aproximada del repuesto

TABLA Repuesto


IdServicio NUMERIC X Primary Identificador de la tabla

NombreServicio nvarchar(100) X Nombre del servicio de mantenimiento

DiasDuracionAprox NUMERIC Duracion aproximada en horas del servicio de mantenimiento

TABLA Servicio


NIT nvarchar(16) X Primary Nit de identifiación del proveedor

Nombre nvarchar(100) X Nombre del proveedor

Direccion nvarchar(100) X Dirección de ubicación del proveedor

Telefono1 NUMERIC (15) X Telefono principal

Telefono2 NUMERIC (15) Telefono opcional

FkTipoProveedor NUMERIC X Foreign TipoProveedor(Id) Llave foranea con la tabla TipoProveedor

TABLA Proveedor


NumeroLicencia NUMERIC X Primary Número de la licencia de conducción

FkCedulaConductor NUMERIC X Foreign Conductor(NroIdentificacion) Número de identificación del conductor

FechaExpedicion DATE X Fecha expedición de la licencia

RestriccionConductor nvarchar(100) Restricciones que tenga el conductor

OrganismoTransExpide nvarchar(100) Organismo que expide la licencia de conducción

FkCategoriaLicencia NUMERIC X Foreign CategoriaLicencia(Id) Llave foranea con la tabla CategoriaLicencia

FechaVigencia DATE X Fecha de vigencia de la licencia de conducción

TABLA LicenciaConduccion


NroIdentificacion NUMERIC X Primary Número de identificación del conductor

FkTipoIdentificacion NUMERIC X Foreign TipoIdentificacion(Id) Llave foranea con la tabla TipoIdentificacion

Nombres nvarchar(100) X Nombres del conductor

Apellidos nvarchar(100) X Apellidos del conductor

FechaNacimiento DATE X Fecha de nacimiento del conductor

Email nvarchar(100) Correo electrónico del conductor

FkGenero NUMERIC X Foreign Genero(Id) Llave foranea con la tabla Género

FkGrupoSanguineo NUMERIC X Foreign GrupoSanguineo(Id) Llave foranea con la tabla Grupo sangüineo

FechaExpedicionCedula DATE Fecha de expedición de la cédula

LugarExpedicionCedula nvarchar(100) Lugar de expedición de la cédula

Nacionalidad nvarchar(100) Nacionalidad del conductor

LugarNacimiento nvarchar(100) Lugar de nacicmiento del conductor

DireccionDomicilio nvarchar(120) X Dirección de domicilio del conductor

Barrio nvarchar(100) Bario de domicilio

Ciudad nvarchar(100) Ciudad de domicilio

TelefonoDomicilio nvarchar(15) Teléfono domicilio

TelefonoMovil nvarchar(15) Teléfono movil

EPS nvarchar(50) EPS donde esta afiliado el conductor

Pension nvarchar(50) Fondo de pensiones donde contiza el conductor

FkEstadoConductor NUMERIC X Foreign EstadoConductor(Id) Llave foranea con la tabla EstadoConductor

FechaIngreso DATE X Fecha de ingreso a la compañía

TABLA Conductor


IdTurno NUMERIC X Primary Identificado de la tabla

FkNroIdentificacion NUMERIC X Foreign Conductor(NroIdentificacion) Llave foranea con la tabla Conductor

FkPlaca NUMERIC X Foreign Vehiculo(Placa) Llave foranea con la tabla Vehiculo

FechaHoraInicio DATE X Fecha y Hora de inicio del turno

FechaHoraFin DATE X Fecha y Hora de final del turno

FkTipoTurno NUMERIC X Foreign TipoTurno(Id) Llave foranea con la tabla TipoTurno

Producido NUMERIC Valor del producido durante el turno

TABLA ControlTurnos


IdMantenimiento NUMERIC X Primary Identificado de la tabla

FkPlacaVehiculo NUMERIC X Foreign Vehiculo(Placa) Llave foranea con la tabla Vehiculo

FkProveedor NUMERIC X Foreign Proveedor(NIT) Llave foranea con la tabla Proveedor

Fecha DATE X Fecha y Hora del mantenimiento

FkRepuesto NUMERIC Foreign Repuesto(IdRepuesto) Llave foranea con la tabla Repuesto

FkServicio NUMERIC Foreign Servicio(IdServicio) Llave foranea con la tabla Servicio

TABLA ControlMantenimiento

135


Placa nvarchar(10) X Primary Placa del vehículo

NumeroLicenciaTransito nvarchar(20) X Número de licencia de transito del vehículo

FkClaseVehiculo NUMERIC X Foreign ClaseVehiculo(Id) Llave foranea con la tabla ClaseVehiculo

FkTipoServicio NUMERIC X Foreign TipoServicio(Id) Llave foranea con la tabla TipoServicio

FkMarca NUMERIC X Foreign Marca(Id) Llave foranea con la tabla Marca

Modelo NUMERIC X Año del modelo del vehículo

Linea nvarchar(50) X Linea de la marca

Color nvarchar(50) X Color del vehículo

NroSerie nvarchar(50) X Número de serie del vehículo

NroMotor nvarchar(50) X Número de motor del vehículo

NroChasis nvarchar(50) X Número del chasis del vehículo

NroVIN nvarchar(50) X Número VIN del vehículo

Cilindraje NUMERIC (5) X Cilindraje del motor del vehículo

FkTipoCarroceria NUMERIC X Foreign TipoCarroceria(Id) Llave foranea con la tabla TipoCarroceria

FkTipoCombustible NUMERIC X Foreign TipoCombustible(Id) Llave foranea con la tabla TipoCombustible

FechaMatricula DATE X Fecha en que se matriculó el vehículo

CapacidadCarga NUMERIC Capacidad de carga del vehículo

PesoBruto NUMERIC Peso bruto del vehículo

NroEjes NUMERIC Número de ejes del vehículo

CapacidadPasajeros NUMERIC Capacidad de pasajeros

CapacidadPasajSentados NUMERIC Capacidad de pasajeros sentados

FkEstadoVehiculo NUMERIC X Foreign EstadoVehiculo(Id) Llave foranea con la tabla EstadoVehiculo

FkPropietarioNroIdentificacion NUMERIC X Foreign Propietario(NroIdentificacion) Llave foranea con la tabla Propietario

TABLA Vehiculo

136

Bibliografıa

[Cockburn, 2001] Cockburn, A. (2001). Writing Effective Use Cases. Work, 26(1):94.

[de Ambiente, 2016] de Ambiente, S. D. (2016). Observatorio ambiental de bogota. http://oab.ambientebogota.gov.co/comparar indicadores.php. [En lınea; consultada 10/3/2016].

[de Bogota, ] de Bogota, A. M. Decreto numero 400 de 2014. http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=59556. [En lınea; consultada 10/5/2016].

[de la Republica de Colombia, ] de la Republica de Colombia, C. Ley 769 de 2002.http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=5557. [En lınea; consulta-da 5/4/2016].

[de Transporte, ] de Transporte, M. Decreto numero 172 de 2001. https://www.mintransporte.gov.co/descargar.php?idFile=125. [En lınea; consultada 5/4/2016].

[FitzMacken, ] FitzMacken, T. Getting started with entity framework 6 database first usingmvc 5. https://www.asp.net/mvc/overview/getting-started/database-first-development/setting-up-database. [En lınea; consultada 25/9/2016].

[Galloway et al., 2012] Galloway, J., Wilson, B., Allen, K. S., and Haack, P. (2012). Profes-sional ASP.NET MVC 4. Wiley.

[Lopes, ] Lopes, E. Use case 2.0 – slices and relationships: Extension. http://blog.ivarjacobson.com/search/use+case+2.0/. [En lınea; consultada 17/8/2016].

[MOVILIDAD, ] MOVILIDAD, S. D. D. Resolucion 279 de 2015. http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=61531. [En lınea; consultada 20/4/2016].

[Sommerville, 2011] Sommerville, I. (2011). Software Engineering. Pearson.

[Team, 2009] Team, M. P. . P. (2009). Microsoft R© Application Architecture Guide (Patterns& Practices). Microsoft Press.

[The Open Group, 2009] The Open Group (2009). TOGAF Version 9.

[Tutorial, ] Tutorial, E. Entityframeworktutorial.net. http://www.entityframeworktutorial.net/what-is-entityframework.aspx. [En lınea; consultada 19/9/2016].

137

http://oab.ambientebogota.gov.co/comparar_indicadores.php

http://oab.ambientebogota.gov.co/comparar_indicadores.php

http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=59556



https://www.mintransporte.gov.co/descargar.php?idFile=125

https://www.mintransporte.gov.co/descargar.php?idFile=125

https://www.asp.net/mvc/overview/getting-started/database-first-development/setting-up-database

https://www.asp.net/mvc/overview/getting-started/database-first-development/setting-up-database

http://blog.ivarjacobson.com/search/use+case+2.0/

http://blog.ivarjacobson.com/search/use+case+2.0/



http://www.entityframeworktutorial.net/what-is-entityframework.aspx

http://www.entityframeworktutorial.net/what-is-entityframework.aspx

138 BIBLIOGRAFIA

[Vamos, ] Vamos, B. C. Encuesta de percepcion ciudadana 2015. http://www.bogotacomovamos.org/documentos/encuesta-de-percepcion-ciudadana-2015/. [Enlınea; consultada 30/3/2016].

http://www.bogotacomovamos.org/documentos/encuesta-de-percepcion-ciudadana-2015/

http://www.bogotacomovamos.org/documentos/encuesta-de-percepcion-ciudadana-2015/

DISENO DE ARQUITECTURA EMPRESARIAL˜repository.udistrital.edu.co/bitstream/11349/5123/1... · diseno de arquitectura empresarial˜ caso de estudio: centro de inversiones empresariales

Documents