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”.
6 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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.
8 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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-
10 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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”
1.6. MARCO CONCEPTUAL 11
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.
12 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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,
1.6. MARCO CONCEPTUAL 13
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.
14 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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.
1.6. MARCO CONCEPTUAL 15
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.
16 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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.
18 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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.
20 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION
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
26 CAPITULO 2. EJECUCION DEL PROYECTO
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. FASE I. REQUERIMIENTOS DE SOFTWARE 27
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 *
PRIORIDAD ALTACOMPLEJIDAD MEDIAFRECUENCIA DE USUO ALTA
Tabla 2.6: Requerimiento 003 - Gestion de Conductor
28 CAPITULO 2. EJECUCION DEL PROYECTO
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. FASE I. REQUERIMIENTOS DE SOFTWARE 29
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
30 CAPITULO 2. EJECUCION DEL PROYECTO
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 *
PRIORIDAD ALTACOMPLEJIDAD MEDIAFRECUENCIA DE USUO ALTA
Tabla 2.12: Requerimiento 006 - Gestion de vehıculos
2.2. FASE I. REQUERIMIENTOS DE SOFTWARE 31
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
32 CAPITULO 2. EJECUCION DEL PROYECTO
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
ACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de
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. FASE I. REQUERIMIENTOS DE SOFTWARE 33
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.
ACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de
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
PRIORIDAD ALTACOMPLEJIDAD MEDIAFRECUENCIA DE USUO ALTA
Tabla 2.18: Requerimiento 009 - Gestion de Producido
34 CAPITULO 2. EJECUCION DEL PROYECTO
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.
ACTORES AdministradorPRECONDICIONES 1. El administrador debe estar logueado en el sistema de
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)
PRIORIDAD ALTACOMPLEJIDAD MEDIAFRECUENCIA DE USUO ALTA
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.
36 CAPITULO 2. EJECUCION DEL PROYECTO
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.
38 CAPITULO 2. EJECUCION DEL PROYECTO
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
40 CAPITULO 2. EJECUCION DEL PROYECTO
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
42 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.7. FASE IV. GENERACION DE PROTOTIPO 43
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
44 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.7. FASE IV. GENERACION DE PROTOTIPO 45
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”.
46 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.7. FASE IV. GENERACION DE PROTOTIPO 47
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.
48 CAPITULO 2. EJECUCION DEL PROYECTO
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. FASE IV. GENERACION DE PROTOTIPO 49
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.
50 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.7. FASE IV. GENERACION DE PROTOTIPO 51
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.
52 CAPITULO 2. EJECUCION DEL PROYECTO
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
54 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.8. FASE IV. APLICACION TAXIMONITOR 55
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
• 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
56 CAPITULO 2. EJECUCION DEL PROYECTO
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. FASE IV. APLICACION TAXIMONITOR 57
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
58 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.8. FASE IV. APLICACION TAXIMONITOR 59
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
60 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.8. FASE IV. APLICACION TAXIMONITOR 61
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
62 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.8. FASE IV. APLICACION TAXIMONITOR 63
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:
64 CAPITULO 2. EJECUCION DEL PROYECTO
• 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
2.8. FASE IV. APLICACION TAXIMONITOR 65
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
66 CAPITULO 2. EJECUCION DEL PROYECTO
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.
2.8. FASE IV. APLICACION TAXIMONITOR 67
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.
68 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.8. FASE IV. APLICACION TAXIMONITOR 69
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
70 CAPITULO 2. EJECUCION DEL PROYECTO
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)
2.8. FASE IV. APLICACION TAXIMONITOR 71
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)
72 CAPITULO 2. EJECUCION DEL PROYECTO
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
2.8. FASE IV. APLICACION TAXIMONITOR 73
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
74 CAPITULO 2. EJECUCION DEL PROYECTO
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.
80 CAPITULO 3. DISENO DE ARQUITECTURA DE NEGOCIO
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.
82 CAPITULO 3. DISENO DE ARQUITECTURA DE NEGOCIO
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.
84 CAPITULO 3. DISENO DE ARQUITECTURA 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
86 CAPITULO 3. DISENO DE ARQUITECTURA DE NEGOCIO
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.
88 CAPITULO 3. DISENO DE ARQUITECTURA DE NEGOCIO
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
92 CAPITULO 4. DISENO DE ARQUITECTURA DE APLICACION
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
4.3.2. Aplicacion P.V de Cooperacion de Aplicacion
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.
94 CAPITULO 4. DISENO DE ARQUITECTURA DE APLICACION
Figura 4.7: Metamodelo Punto de vista de Uso de Aplicacion - Fuente: Sandro Bolanos
4.4.2. Aplicacion P.V de Cooperacion de Aplicacion
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
98 CAPITULO 5. DISENO DE ARQUITECTURA DE INFRAESTRUCTURA Y DATOS
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.
100 CAPITULO 5. DISENO DE ARQUITECTURA DE INFRAESTRUCTURA Y DATOS
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.
102 CAPITULO 5. DISENO DE ARQUITECTURA DE INFRAESTRUCTURA Y DATOS
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.
104 CAPITULO 5. DISENO DE ARQUITECTURA DE INFRAESTRUCTURA Y DATOS
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
108 CAPITULO 6. DISENO DE ARQUITECTURA MOTIVACIONAL
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
110 CAPITULO 6. DISENO DE ARQUITECTURA MOTIVACIONAL
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.
112 CAPITULO 6. DISENO DE ARQUITECTURA MOTIVACIONAL
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
GeneroNombre varchar (1) X Nombre del Genero
TABLA Genero
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
GrupoSanguineoNombre varchar (3) X Nombre del Grupo sanguineo
TABLA GrupoSanguineo
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
EstadoNombre nvarchar (20) X Nombre del Estado de conductor
TABLA EstadoConductor
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
CategoriraLicenciaNombre nvarchar (20) X Nombre de la categoria de licencia
TABLA CategoriaLicencia
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
ClaseVehiculoNombre nvarchar (40) X Nombre de la clase de vehículo
TABLA ClaseVehiculo
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
TipoServiciooNombre nvarchar (30) X Nombre del tipo de servicio que presta el vehículo
TABLA TipoServicio
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
MarcaNombre nvarchar (40) X Nombre de la marca de vehículo
TABLA Marca
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
TipoCarroceriaNombre nvarchar (40) X Nombre del tipo de carroceria
TABLA TipoCarroceria
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
TipoCombustibleNombre nvarchar (40) X Nombre del tipo de combustible
TABLA TipoCombustible
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
FkEstadoVehiculoNombre nvarchar (40) X Nombre del estado del vehículo
TABLA EstadoVehiculo
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
TipoTurnoNombre nvarchar (10) X Nombre del Tipo de turno
TABLA TipoTurno
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
Id IDENTITY(1) X Primary Identificado de la tabla
TipoProveedorNombre nvarchar (10) X Nombre del Tipo de proveedor
TABLA TipoProveedor
134
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
CAMPO TIPO DE DATO OBLIGATORIO LLAVE DESCRIPCIÓN
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
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].