Está en la página 1de 41

1

Título

Plataforma informática de transporte compartido para funcionarios y estudiantes de

Unisarc.

Integrantes: Mateo Berrio Gallego, Valentina Rendón Gaviria

Descripción del problema

Unisarc es la Universidad rural y agropecuaria de Colombia Ubicada en la Vereda El

Jazmín Kilómetro 4 Vía Santa Rosa de Cabal – Chinchiná (unisarc.edu.co/quienes-somos),

reconocida a nivel nacional por su gran trabajo en educación sobre temas relacionados con la

agricultura, zootecnia y veterinaria. Debido a estas carreras, la universidad se encuentra

ubicada en zonas rurales del municipio, esto facilita el aprovechamiento del entorno para la

educación, sin embargo, cuando terminan las jornadas de clases, los estudiantes se encuentran

con una problemática que hace años viene sucediendo en la universidad y es el tema del

transporte. Debido a la lejanía de la universidad por estar en un sector rural, el transporte

público se desplaza cada determinado tiempo, desde por la mañana hasta una hora

determinada temprano en la noche; esto ha venido afectando a todos los estudiantes quienes

no cuentan con un transporte propio a lo largo de sus carreras universitarias ya que se les

dificulta encajar sus horarios de clases con los del transporte público, esto ha ocasionado que

varios estudiantes se queden sin transporte para sus casas después de salir de clases en la

noche.

Los estudiantes son conscientes de esta situación del transporte público, y por las

noches cuando se van a dirigir a sus hogares, les preguntan a sus docentes (con el que estén

cursando la materia actualmente o alguno de confianza ) la ruta que van a realizar y


2

preguntan si se pueden quedar en el transcurso del camino, de esta manera se hace un aporte a

esos estudiantes quienes no cuentan con un transporte propio y no poseen la suficiente

cantidad de dinero disponible como para pagar un servicio de transporte privado todos los

días.

Teniendo en cuenta esta problemática mencionada anteriormente, siempre se ha

buscado una solución para mejorar el transporte de los estudiantes, una de ellas, son los

medios de comunicación que nos permiten tener contacto más fácil con las demás personas.

Esto les ha permitido a los estudiantes poder contactarse con otros quienes tengan transporte

propio y cuenten con espacios disponibles en sus vehículos.

Sin embargo, la problemática siempre ha existido porque no se ha formalizado ninguna

opción de transporte para los estudiantes, esto implica que muchos de ellos tengan que hacer

un esfuerzo mayor monetariamente para transportarse o tengan que abandonar la clase un

poco más temprano para poder coincidir con el horario del transporte público, esto directa o

indirectamente, genera afectaciones ya sea académicamente o monetariamente en el

estudiante.

Teniendo en cuenta lo expuesto anteriormente, podemos concluir en que el tema del

transporte siempre ha sido complicado y poco tratado, tanto por las directivas de la

institución como por la administración del transporte público en el municipio, y si no se

plantea una solución prontamente, esto afectaría el ingreso de nuevos estudiantes a largo

plazo.
3

Formulación del problema /pregunta

¿Cómo desarrollar un sistema informático que permita la relación entre funcionarios y

estudiantes con rutas comunes de transporte?

Propuesta de solución

La solución presentada de acuerdo a la necesidad que representa el transporte a los

estudiantes de UNISARC requiere incentivar la participación de estos con otros funcionarios

con rutas comunes al momento de trasportarse, a través de una plataforma que ofrezca

servicios de transporte a los estudiantes de UNISARC con tan solo ingresar a la dicha

plataforma e interactúe con los funcionarios.

La principal interacción de la plataforma se basa en: la creación de los tipos de usuarios

(funcionarios y estudiantes). Para los funcionarios se dispondrá el despliegue un formulario,

donde se le permite ingresar la información requerida y ofrecer su servicio. El formulario

principalmente debe pedir (características del vehículo, datos del mismo, etc.). Para los

estudiantes también se maneja con formulario, donde se le permite ingresar sus datos para

buscar el servicio deseado. El formulario principalmente debe pedir (nombre, horarios,

dirección, etc.).

La idea de este proyecto, se basa fundamentalmente en relacionar tanto a los estudiantes

como a los funcionarios externos que ofrezcan un medio de transporte y permita satisfacer la

necesidad del estudiante.


4

Justificación

Teniendo en cuenta la problemática que se ha presentado en la universidad en los últimos

años referente al transporte de los estudiantes y sus respectivos horarios, nace la idea de

desarrollar un sistema informático, que permita crear relación entre dos tipos de usuarios

(estudiantes y funcionarios) de acuerdo a rutas comunes entre ellos y que tengan facilidad de

consultar y tener variedad de opciones al elegir de movilizarse. El sistema que se usara va a

ofrecer un servicio factible a los estudiantes, esta idea de desarrollo promete una opción

diferente y muy accesible para los estudiantes quienes tienen horarios o por una u otra razón

estén en un horario nocturno en la universidad.

La realización del proyecto, es importante ya que resulta más eficiente y eficaz crear una

relación estudiante- funcionario mediante el sistema informático generando solución al tema

de transporte. En primera instancia el estudiante se sentirá a gusto con el buen servicio y

rapidez y segundo le permitirá elegir cumpliendo con sus expectativas.

Por lo ya mencionado anteriormente, se plantea el desarrollo e implementación de la

plataforma, debido a que la institución no ha encontrado la respectiva solución a esto y para

que mejore el problema económico de los estudiantes, debido a los horarios tardíos que a

veces cursan en la universidad y los obliga a abordar transporte privado. Del mismo modo

que no afecte el rendimiento académico al no asistir a clase por no tener transporte disponible

para su movilización. La implementación de este desarrollo, no solo dará confiabilidad y

seguridad a los usuarios, sino que también tendrá gran impacto en la imagen de la

universidad, debido a que la misma podrá decir que cuenta con un sistema propio de

transporte para dar una ayuda a aquellos estudiantes quienes no cuentan con un transporte

propio o salen demasiado tardes de clases. Esto generará un gran impacto debido a que
5

muestra un interés de la universidad con respecto a sus estudiantes, y en ofrecer

subsanaciones a esas problemáticas las cuales hacen desmotivar a los estudiantes a venir a

estudiar.

También, cabe recalcar que los usuarios no tendrán un precio fijo o establecido dentro de

la plataforma, esto quiere decir que el valor del servicio será un acuerdo entre el usuario y el

funcionario. Puede haber ocasiones en las que estos servicios de transporte quizás no tengan

ningún valor ya sea porque así se acordaron las dos partes. Esto será un gran aporte para la

economía de cada estudiante, debido a que se busca de que este medio de transporte sea

mucho más económico que el usual o gratuito, y la idea es que se compartan una misma ruta

de transporte
6

Objetivos

General

Diseñar e implementar una plataforma informática que permita poner en contacto a los

funcionarios con los estudiantes de la universidad, para obtener un servicio de transporte.

Específicos

- Establecer la recolección de información necesaria para el desarrollo del proyecto.

- Determinar y aplicar una metodología apropiada y adaptable.

- Diseñar una base de datos práctica y segura para la consulta de información.

- Permitir al usuario adquirir el servicio mediante un proceso de inscripción al sitio.


7

Alcances

- La plataforma busca interactuar con el usuario brindando servicios de consultas,

solicitudes y registros, generando información precisa y oportuna sobre las rutas

comunes que tiene con los funcionarios. Así podrá realizar su respectiva ruta y ser

controlada

- El sistema de información planteado pretende eliminar la necesidad de transporte

creando relación entre los estudiantes y funcionarios con vehículos propios.

- Se manejarán rutas que estén dentro del rango de la universidad (Santa Rosa de Cabal,

Dosquebradas, Pereira, Chinchiná, Quinchia, Manizales, entre otros).

- Uso exclusivo para estudiantes de UNISARC y funcionarios que se encuentren dentro

del rango establecido.

- La metodología se basará en el modelado UML, permitiendo mejorar el tiempo del

desarrollo, así que el proyecto estará debidamente documentado.


8

Marco teórico

Referente teórico

Durante el proyecto se va a desarrollar una plataforma informática, esta herramienta es un

sistema de información, que es un conjunto de datos que interactúan entre sí con un fin

común. En informática, los sistemas de información ayudan a administrar, recolectar,

recuperar, procesar, almacenar y distribuir información relevante para los procesos

fundamentales y las particularidades de cada organización.

La importancia de un sistema de información radica en la eficiencia en la correlación de

una gran cantidad de datos ingresados a través de procesos diseñados para cada área con el

objetivo de producir información válida para la posterior toma de decisiones.

Los sistemas informáticos están estructurados por tres componentes: el componente físico,

que constituye el hardware del sistema informático. Lo conforman, básicamente, los

ordenadores, los periféricos y el sistema de comunicaciones. Los componentes físicos

proporcionan la capacidad y la potencia de cálculo del sistema informático. El componente

lógico, constituye el software del sistema informático y lo conforman, básicamente, los

programas, las estructuras de datos y la documentación asociada El software se encuentra

distribuido en el hardware y lleva a cabo el proceso lógico que requieren los datos. el

componente humano, constituido por todas las personas participantes en todas las fases de la

vida de un sistema informático (diseño, desarrollo, implantación, explotación). Este

componente humano es sumamente importante ya que los sistemas informáticos están

desarrollados por humanos y para uso de humanos. (Jiménez, 2017).

Por otra parte, la expansión de Internet ha permitido la creación de espacios de libertad de

expresión y asociación, incrementando el acceso a la información por parte de los


9

ciudadanos. Su difusión ha alcanzado tal magnitud que a menudo se afirma la existencia de

una relación causal entre su aparición y el empoderamiento de la sociedad civil y la llegada

de la democracia. Sin embargo, esta ciberutopía es a menudo confrontada por diversos

Estados. Ante el dilema del conservador, acuñado por George Schultz, estos Gobiernos han

optado por servirse del mundo digital como un medio propagandístico y de control, en vez de

impedir el acceso a este.

En este contexto, el objeto principal de este trabajo ha consistido en analizar cómo el

Gobierno de Venezuela está empleando Internet para controlar los movimientos disidentes

dentro de sus fronteras. Mediante una minuciosa investigación con un especial énfasis en la

red social Twitter, se ha podido comprobar cómo el chavismo ha hecho uso de Internet para

extender su dominio en la red. (Sáez, 2020).

Sobre el desarrollo de software, se tiene en los últimos 20 años, las notaciones de

modelado y posteriormente las herramientas, pretendieron ser el éxito en el desarrollo de

software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a

que otro importante elemento, la metodología de desarrollo, había sido postergado. De nada

sirven buenas herramientas si no se proveen directivas para su aplicación. Así, esta década ha

comenzado con un creciente interés en metodologías de desarrollo. Hasta hace poco el

proceso de desarrollo de software, llevaba asociado un marcado énfasis en el control del

proceso mediante una rigurosa definición de roles, incluyendo modelado y documentación

detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado

ser efectivo y necesario en proyectos de gran tamaño, donde por lo general se exige un alto

grado de cumplimiento en el proceso. Sin embargo, este enfoque no resulta ser el más

adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy

cambiante y en donde se exige reducir drásticamente los tiempos de desarrollo, pero

manteniendo una calidad alta. Ante las dificultades para utilizar metodologías tradicionales
10

con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a

renunciar de la ingeniería del software, asumiendo el riesgo que ello conlleva. En este

escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío

metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías

ágiles constituyen una solución a medida para ese entorno, aportando una elevada

simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la

calidad del producto. El avance de las tecnologías es acompañado por el incremento de los

sistemas de software donde la calidad y la innovación toman un lugar esencial tanto en el

desarrollo de productos como de servicios. Actualmente al incluir al usuario en los procesos

de innovación y ubicarlo en una posición centralizada se da lugar a la aparición de nuevos

espacios de interacción y comunicación en los que el actor que consume productos y

servicios adquiere un rol activo. En referencia al uso de las tecnologías es muy importantes

determinar la adecuada según necesidad del usuario para hacer fácil los procesos y de esta

forma satisfacer de manera correcta el cliente. (Moreno, 2020).

En la década de los noventa surgieron metodologías de desarrollo de software ligeras, más

adelante nombradas como metodologías ágiles, que buscaban reducir la probabilidad de

fracaso por subestimación de costos, tiempos y funcionalidades en los proyectos de desarrollo

de software. Estas metodologías nacieron como reacción a las metodologías existentes con el

propósito de disminuir la burocracia que implica la aplicación de las metodologías

tradicionales en los proyectos de pequeña y mediana escala.

Las metodologías tradicionales buscan imponer disciplina al proceso de desarrollo de

software y de esa forma volverlo predecible y eficiente. Para conseguirlo se soportan en un

proceso detallado con énfasis en planeación propio de otras ingenierías. El principal

problema de este enfoque es que hay muchas actividades que hacer para seguir la

metodología y esto retrasa la etapa de desarrollo. Las metodologías ágiles tienen dos
11

diferencias fundamentales con las metodologías tradicionales; la primera es que los métodos

ágiles son adaptativos –no predictivos-. La segunda diferencia es que las metodologías ágiles

son orientadas a las personas –no orientadas a los procesos.

Las metodologías ágiles son adaptativas. Este hecho es de gran importancia ya que

contrasta con la predictibilidad buscada por las metodologías tradicionales. Con el enfoque de

las metodologías ágiles los cambios son eventos esperados que generan valor para el cliente,

además son flexibles, y pueden ser modificadas para que se ajusten a la realidad de cada

equipo y proyecto.

La mayoría de equipos ágiles exitosos han adaptado prácticas ágiles de distintas

metodologías para generar un proceso de desarrollo propio que se ajusta a sus necesidades.

Estas adaptaciones parecen estar centradas en mezclas de Scrum con XP. XP se enfoca en

prácticas de desarrollo mientras que Scrum apunta a la administración de proyectos (Cadavid

& Martínez & Morales,2013).

Por lo dicho anteriormente se mencionan las diferentes metodologías agiles que existen y

el objetivo que tiene cada uno en el proceso del software:

Scrum:

La metodología Scrum para el desarrollo ágil de software es un marco de trabajo diseñado

para lograr la colaboración eficaz de equipos en proyectos, que emplea un conjunto de reglas

y artefactos y define roles que generan la estructura necesaria para su correcto

funcionamiento.

Scrum utiliza un enfoque incremental que tiene como fundamento la teoría de control

empírico de procesos. Esta teoría se fundamenta en transparencia, inspección y adaptación; la

transparencia, que garantiza la visibilidad en el proceso de las cosas que pueden afectar el
12

resultado; la inspección, que ayuda a detectar variaciones indeseables en el proceso; y la

adaptación, que realiza los ajustes pertinentes para minimizar el impacto de las mismas.

Los llamados Equipos Scrum son auto-gestionados, multifuncionales y trabajan en

iteraciones. La autogestión les permite elegir la mejor forma de hacer el trabajo, en vez de

tener que seguir lineamientos de personas que no pertenecen al equipo y carecen de contexto.

Los integrantes del equipo tienen todos los conocimientos necesarios (por ser

multifuncionales) para llevar a cabo el trabajo. La entrega del producto se hace en

iteraciones; cada iteración crea nuevas funcionalidades o modifica las que el dueño del

producto requiera.

En Scrum un proyecto se ejecuta en bloques temporales (iteraciones-sprints) de un mes

natural (pueden ser de dos o tres semanas, si así se necesita). Cada iteración tiene que

proporcionar un resultado completo, un incremento de producto que sea susceptible de ser

entregado con el mínimo esfuerzo cuando el cliente lo solicite (Perez,2012).

Scrum define tres roles: el Scrum master, el dueño del producto y el equipo de desarrollo.

El Scrum master tiene como función asegurar que el equipo está adoptando la metodología,

sus prácticas, valores y normas; es el líder del equipo pero no gestiona el desarrollo. El dueño

del producto es una sola persona y representa a los interesados, es el responsable de

maximizar el valor del producto y el trabajo del equipo de desarrollo; tiene entre sus

funciones gestionar la lista ordenada de funcionalidades requeridas o Product Backlog. El

equipo de desarrollo, por su parte, tiene como responsabilidad convertir lo que el cliente

quiere, el Product Backlog, en iteraciones funcionales del producto; el equipo de desarrollo

no tiene jerarquías, todos sus miembros tienen el mismo nivel y cargo: desarrollador. El

tamaño óptimo del equipo está entre tres y nueve personas.


13

Scrum define un evento principal o Sprint (Figura 1) que corresponde a una ventana de

tiempo donde se crea una versión utilizable del producto (incremento). Cada Sprint, como en

el rugby, es considerado como un proyecto independiente. Su duración máxima es de un mes.

Un Sprint se compone de los siguientes elementos: reunión de planeación del Sprint, Daily

Scrum, trabajo de desarrollo, revisión del Sprint y retrospectiva del Sprint.

En la reunión de Planeación del Sprint se define su plan de trabajo: qué se va a entregar y

cómo se logrará. Es decir, el diseño del sistema y la estimación de cantidad de trabajo. Esta

actividad dura ocho horas para un Sprint de un mes. Si el Sprint tiene una duración menor, se

asigna el tiempo de manera proporcional.

El Daily Scrum es un evento del equipo de desarrollo de quince minutos, que se realiza

cada día con el fin de explicar lo que se ha alcanzado desde la última reunión; lo que se hará

antes de la siguiente; y los obstáculos que se han presentado. Este evento se desarrolla

mediante una reunión que normalmente es sostenida de pie con los participantes reunidos

formando un círculo, esto, para evitar que la discusión se extienda.

La Revisión del Sprint ocurre al final del Sprint y su duración es de cuatro horas para un

proyecto de un mes (o una proporción de ese tiempo si la duración es menor). En esta etapa:

el dueño del proyecto revisa lo que se hizo, identifica lo que no se hizo y discute acerca del

Product Backlog; el equipo de desarrollo cuenta los problemas que encontró y la manera en

que fueron resueltos, y muestra el producto y su funcionamiento. Esta reunión es de gran

importancia para los siguientes Sprints.

La Retrospectiva del Sprint es una reunión de tres horas del equipo Scrum en la que se

analiza cómo fue la comunicación, el proceso y las herramientas; qué estuvo bien, qué no, y

se crea un plan de mejoras para el siguiente Sprint. El tiempo, tal como en los casos
14

anteriores, se debe ajustar proporcionalmente en el caso de proyectos de duración menor a un

mes.

Existen también Artefactos de Scrum. Estos son subproductos de las actividades del marco

de trabajo que le brindan dirección y transparencia al equipo. Los artefactos de Scrum son:

Product Backlog, Sprint Backlog, Monitoreo de Progreso e Incremento.

El Product Backlog es una lista −ordenada por valor, riesgo, prioridad y necesidad− de los

requerimientos que el dueño del producto define, actualiza y ordena. La lista tiene como

característica particular que nunca está terminada, pues evoluciona durante el desarrollo del

proyecto.

El Sprint Backlog es un subconjunto de ítems del Product Backlog y el plan para realizar

en el Incremento del producto. Debido a que el Product backlog está organizado por

prioridad, el Sprint backlog es construido con los requerimientos más prioritarios del Product

backlog y con aquellos que quedaron por resolver en el Sprint anterior. Una vez construido,

el Sprint backlog debe ser aceptado por el equipo de desarrollo, pertenece a éste y solo puede

ser modificado por él. Requerimientos adicionales deben ser incluidos en el Product backlog

y desarrollados en el siguiente Sprint, si su prioridad así lo indica.

El Monitoreo de Progreso consiste en la suma del trabajo que falta por realizar en el

Sprint. Tiene como característica que se puede dar en cualquier momento, lo que le permite al

dueño del producto evaluar el progreso del desarrollo. Para que esto sea posible, los

integrantes del equipo actualizan constantemente el estado de los requerimientos que tienen

asignados indicando cuánto consideran que les falta por terminar.

El Incremento es la suma de todos los ítems terminados en el Sprint backlog. Si hay ítems

incompletos deben ser devueltos al Product backlog con una prioridad alta para que sean
15

incluidos en el siguiente Sprint. Se considera que un ítem está terminado si es funcional. La

suma de ítems terminados es el producto a entregar.

El ciclo de vida de este marco de trabajo está compuesto de cuatro fases: planeación,

puesta en escena, desarrollo y entrega. En la planeación se establece la visión, se fijan las

expectativas y se asegura el financiamiento. En la puesta en escena se identifican más

requerimientos y se priorizan para la primera iteración. En la implementación se desarrolla el

sistema, y en la entrega se hace el despliegue operativo.

Figura 1. Metodología Scrum: Fases de un Sprint

Extreme Programming [XP]:

XP es la metodología ágil más conocida. Fue desarrollada por Kent Beck buscando guiar

equipos de desarrollo de software pequeños o medianos, entre dos y diez desarrolladores, en

ambientes de requerimientos imprecisos o cambiantes. XP tiene como base cinco valores:

Simplicidad, Comunicación, Retroalimentación, Respeto y Coraje.

Las prácticas de XP incluyen: planning game, pequeñas entregas, diseño simple,

programación en pareja, pruebas, refactoring, integración continua, propiedad común del

código, paso sostenible, cliente en sitio, metáfora y estándares de código.

Planning Game define el alcance y la fecha de cumplimiento de una entrega funcional

completa −es decir, la fecha de entrega de un release que pueda ser puesto en funcionamiento
16

y divide las responsabilidades entre el cliente y los desarrolladores. El cliente define,

utilizando Historias de Usuario, una versión simplificada de los tradicionales Casos de Uso,

los requerimientos de manera general, y precisa su importancia; Con base en ellas, los

desarrolladores estiman el costo de implementarlas y se definen las características de una

entrega y el número de iteraciones que se necesitarán para terminarla. Para cada iteración el

cliente define cuáles de las historias de usuario que componen la entrega funcional desea que

se desarrollen. Se pueden crear o modificar historias de usuario en cualquier momento

excepto cuando forman parte de una iteración en curso.

Entregas Pequeñas se refiere al uso de ciclos cortos de desarrollo (iteraciones) que le

muestran software terminado al cliente y obtienen retroalimentación de él. La definición de

terminado está relacionada con las pruebas de aceptación.

Diseño Simple indica que el sistema debe ser tan simple como sea posible, en un momento

determinado, lo cual implica que los desarrolladores deben preocuparse únicamente por las

historias de usuario planeadas para la iteración actual, sin importar cuanto pueden cambiar

por funciones futuras.

Programación en pareja indica que todo el código debe ser desarrollado por dos

programadores. Las parejas deben cambiar con cierta frecuencia para que el conocimiento de

todo el sistema quede en todo el equipo, una práctica que fortalece los principios de diseño

simple, calidad y propiedad colectiva del código

Las Pruebas son la guía del desarrollo del producto ya que los detalles de las historias de

usuario (i.e., requerimientos específicos) se obtienen en el desarrollo de la prueba de

aceptación. Las pruebas son lo primero que se desarrolla; con base en ellas, se desarrolla el

código que las satisfaga. A este concepto se le denomina Desarrollo orientado a las pruebas.
17

El ciclo de vida de esta metodología (Figura 2), por su parte, está compuesto por

Exploración, Planeación, Iteraciones hacia la primera entrega, Productionizing y

Mantenimiento (Cadavid & Martínez & Morales,2013).

Figura 2. Ciclo de vida de metodología XP

AUP (AGIL UNIFIED PROCESS)

El AUP es un acercamiento aerodinámico a desarrollo del software basado en el Proceso

Unificado Rational de IBM (RUP), basado en disciplinas y entregables incrementales con el

tiempo. El ciclo de vida en proyectos grandes es serial, mientras que en los pequeños es

iterativo. Las disciplinas de Aup son:

 Modelado

 Implementación

 Prueba

 Despliegue

 Administración de la configuración
18

 Administración o gerencia del Proyecto

 Entorno

Iconix:

El proceso de ICONIX maneja casos de uso, como el RUP, pero le falta mucho para llegar

al nivel del RUP. También es relativamente pequeño y firme, como XP, pero no desecha el

análisis y diseño que hace XP. Este proceso también hace uso aerodinámico del UML

mientras guarda un enfoque afilado en el seguimiento de requisitos.

Figura 3. Esquema de trabajo Iconix

Y el proceso se queda igual a la visión original de Jacobson del manejo de casos de uso,

esto produce un resultado concreto, específico y casos de uso fácilmente entendible, que un

equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real. La

Figura 3 muestra el cuadro del proceso. El diagrama retrata la esencia del enfoque

aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML

y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y

eficazmente. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros

aspectos del UML para complementar los materiales básicos (Figueroa & Solís & Cabrera,

2017).
19

Kanban

Esta metodología visualiza el flujo de trabajo, divide el trabajo en bloques, se trata de

escribir cada elemento en una tarjeta y colocarla en el muro, utiliza columnas con nombre

para ilustrar dónde está cada elemento en el flujo de trabajo. Limita el WIP (Work in

Progress, trabajo en curso), asigna límites concretos a cuántos elementos pueden estar en

progreso en cada estado del flujo de trabajo, mide el lead time (tiempo medio para completar

un elemento, a veces llamado "tiempo de ciclo"), optimiza el proceso para que el lead time

sea tan pequeño y predecible como sea posible (Kniberg & Skarin, 2010).

UML (Lenguaje de Modelado Unificado)

UML, recomienda utilizar los procesos que otras metodologías tienen definidos. Una parte

del UML detalla, entonces, una abstracción con significado de un lenguaje para expresar

otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas

que se organizan para conseguir un propósito. De esta forma simplemente se dice que UML,

además, define un lenguaje con el que se puede abstraer cualquier tipo de modelo). El UML

es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para

llegar a construirlo en términos concretos.

La formalización de los diagramas del UML permite que cada modelo de sistemas se

refine, admitiendo la inclusión y la refinación de las relaciones entre los elementos,

chequeando la consistencia interna de cada uno de los elementos, y verificando la

interconexión entre los elementos. UML surge como una herramienta de gran aceptación

cuando es necesario soportar el diseño y la implementación de una solución automatizada,

que subyace en un modelo de gestión de cualquier sistema. Para ello se debe tener la

documentación apropiada para su desarrollo y su mantenimiento subsiguiente o eventuales

modificaciones. Lo anterior resulta deseable y debe tenerse en cuenta en las representaciones


20

visuales del sistema para su adecuada operación y un mejor entendimiento de los diseños

(Silva & Ledezma & Castorena & Domínguez & Riojas, 2018).

Esta metodología se compone de casos de uso, que es un diagrama que representa la

funcionalidad completa de un sistema (o una clase) mostrando su interacción con los agentes

externos. Esta representación se hace a través de las relaciones entre los actores (agentes

externos) y los casos de uso (acciones) dentro del sistema. Los diagramas de casos de uso

definen conjuntos de funcionalidades afines que el sistema debe cumplir para satisfacer todos

los requerimientos que tiene a su cargo. Esos conjuntos de funcionalidades son representados

por los casos de uso. Se pueden visualizar como las funciones más importantes que la

aplicación puede realizar o como las opciones presentes en el menú de la aplicación. Estos

casos de uso pueden ser divididos en otros (subcasos).

Figura 4. Descripción de casos de uso

En el momento de la descripción de Casos de Uso, se utiliza este formato (Figura 4) que

muestra una descripción para ayudar a comprender los Casos y SubCasos de Uso. También
21

hace referencia a los requerimientos consignados en el documento de Requerimientos, con

los cuales tiene relación.

En el caso del formato de los eventos, se establecen los eventos que pueden ser generados

por el actor y van a ser atendidos por cada Caso de Uso. Por evento entendemos la

interacción que tiene un actor con la aplicación a través de la interfaz gráfica, tal como el clic

de un ratón, el ingreso de un texto a un componente, el movimiento de un elemento de la

interfaz, etc. Todos los eventos van numerados en orden secuencial de acuerdo a la secuencia

lógica como ocurrirían en la aplicación (ciclo de vida del caso de uso). De este formato se

obtiene la información para la creación de los diagramas de interacción, más específicamente

el de secuencia. También se deben presentar los eventos alternos, los cuales permiten

establecer las excepciones que se pueden presentar en la ejecución del programa.

El Diagrama Conceptual, muestra los conceptos presentes en el dominio del problema. Un

concepto para este caso, en términos de la Programación Orientada a Objetos, es un objeto

del mundo real; es decir, es la representación de cosas del mundo real y NO de componentes

de software. En él no se definen operaciones (o métodos); en este modelo se pueden mostrar

los conceptos, los atributos de los conceptos (opcionalmente) y la relación o asociación entre

ellos. Informalmente podríamos decir que un concepto es una idea, cosa u objeto. Para

descubrirlos debemos analizar los sustantivos en las descripciones textuales del dominio del

problema, es decir, de la descripción del sistema, de los requerimientos y de los Casos de

Uso.

El Diagrama de Estructura Estática (de clases), muestra una vista de la aplicación en un

determinado momento, es decir, en un instante en que el sistema está detenido. Las clases son

la plantilla de los objetos, y aquí podemos ver representados a estos con sus atributos o

características y su comportamiento o métodos, así como la relación entre ellas.


22

Diagrama de Interacción Son aquellos que muestran las interacciones de un usuario con el

sistema. Interacción es una cadena de mensajes enviados entre los objetos en respuesta a un

evento generado por el usuario sobre la aplicación. Los diagramas de interacción pueden ser

Diagramas de Secuencia y Diagramas de Colaboración. Estos diagramas conforman la etapa

del diseño de la aplicación, y se crean a partir de los diagramas de Casos de Uso y el

Conceptual. Los Diagramas de Secuencia representan una interacción entre objetos de

manera secuencial en el tiempo. Muestra la participación de objetos en la interacción entre

sus “líneas de vida” (desde que se instancias) y los mensajes que ellos organizadamente

intercambian en el tiempo. El responsable o ACTOR es quien inicia el ciclo interactuando

inicialmente la interfaz de usuario: GUI; en seguida se inician todos los objetos que

intervienen en el funcionamiento del aplicativo. En este diagrama se comienza a observar el

comportamiento del sistema a partir de los eventos generados por los actores. Aquí se

interactúa con instancias, no con clases.

Los Contratos, describen lo que una operación debe satisfacer o lograr, en términos de lo

que se hace, más no de cómo se lo hace, y haciendo énfasis en los cambios de estado que

ocurren en las precondiciones y postcondiciones de la operación.

El Diagrama de Estado, muestra la secuencia de los estados de un objeto durante su ciclo

de vida, en respuesta a un estímulo recibido. Los estados de los objetos están dados por el

valor de sus atributos (estados) lo cual cambia sus comportamientos (métodos). Los estados

hacen referencia a una condición durante la vida de un objeto o a una interacción durante la

cual se satisface alguna condición (ejecutar alguna acción, esperar algún evento, etc.), por

ejemplo, una validación de una captura. Un objeto permanece en un estado por un tiempo

finito, hasta que se cumpla la condición de cambio. Se construyen a partir del Diagrama de

Estructura Estática, identificando cuáles objetos cambian de estado, cual es el estado inicial y
23

el final, definiendo a qué eventos puede responder el objeto, y qué transacciones ejecutará

(Canchala, 2017).
24

Marco conceptual

Herramienta: cualquier cosa usada como medio para realizar una tarea o propósito

(Kniberg & Skarin, 2010).

Modelado: es la construcción de un modelo a partir de una especificación (Canchala,

2017).

Modelo: es una abstracción de algo, que se elabora para comprender ese algo antes de

construirlo (Canchala, 2017).

Aplicaciones web: Se denomina aplicaciones web a aquellas aplicaciones cuya interfaz de

construye a partir de páginas web. Las páginas web no son más que ficheros de texto en un

formato estándar denominado HTML (HyperText Markup Language). Estos ficheros se

almacenan en un servidor web al cual se le accede utilizando el protocolo de HTTP

(HyperText Transfer Protocol), uno de los protocolos de internet. (Berzal & Cortijo &

Cubero, 2008)

Lenguaje de programación: Lenguaje artificial que se utiliza para expresar programas de

ordenador. Cada ordenador, según su diseño, ‘entiende’ un cierto conjunto de instrucciones

elementales (lenguaje máquina). No obstante, para facilitar la tarea del programador, se

dispone también de lenguajes de alto nivel más fáciles de manejar y que no dependen del

diseño específico de cada ordenador. Los programas escritos en un lenguaje de alto nivel no

podrán ser ejecutados por un ordenador mientras no sean traducidos al lenguaje propio de

éste. Para definir un lenguaje de programación es necesario especificar: •Conjunto de

símbolos y palabras clave utilizables. •Reglas gramaticales para construir sentencias

(instrucciones, ordenes) sintáctica y semánticamente correctas. a) Sintaxis: Conjunto de

normas que determinan cómo escribir las sentencias del lenguaje. b) Semántica:
25

Interpretación de las sentencias. Indica el significado de las mismas. (Rodríguez &

Santamaría & Rabasa & Martínez, 2014.)

POO (Programación Orientada a Objetos): El paradigma orientado a objetos (OO) se

refiere a un estilo de programación. Un lenguaje de programación orientado a objetos (LOO)

puede ser tanto imperativo como funcional o lógico. Lo que caracteriza un LOO es la forma

de manejar la información que está basada en tres conceptos: •Clase. - Tipo de dato con unas

determinadas propiedades y una determinada funcionalidad (ejemplo: clase ‘persona’).

•Objeto. - Entidad de una determinada clase con un determinado estado (valores del conjunto

de sus propiedades) capaz de interactuar con otros objetos (ejemplos: ‘Pedro’, ‘Sonia’, ...).

•Herencia. - Propiedad por la que es posible construir nuevas clases a partir de clases ya

existentes (ejemplo: la clase ‘persona’ podría construirse a partir de la clase ‘ser vivo’).

(Rodríguez & Santamaría & Rabasa & Martínez, 2014.)

Lenguaje de Maquina: Es el lenguaje que comprende la máquina de forma directa.

Internamente, el ordenador representa la información utilizando únicamente unos y ceros. Por

tanto, un programa escrito en lenguaje máquina (o código máquina) estará formado por una

secuencia finita de unos y ceros. 01011010 10101010 ... Este lenguaje rara vez se emplea

para programar ya que tiene muchos inconvenientes: •Difícil de escribir y entender.

•Laboriosa modificación y corrección de errores. •Depende del hardware (distintos

ordenadores ⇒ distintos lenguajes máquina). •Repertorio reducido de instrucciones

(Rodríguez & Santamaría & Rabasa & Martínez, 2014).

Compilador: Es un programa que toma como entrada un programa fuente y genera un

programa equivalente llamado programa objeto o código objeto. (Rodríguez & Santamaría &

Rabasa & Martínez, 2014).


26

Algoritmo: Conjunto de instrucciones que especifican la secuencia ordenada de

operaciones a realizar para resolver un problema. En otras palabras, un algoritmo es un

método o fórmula para la resolución de un problema. Un algoritmo es independiente tanto

del lenguaje de programación en que se exprese como del ordenador en el que se ejecute.

(Rodríguez & Santamaría & Rabasa & Martínez, 2014).


27

Marco legal

A continuación, se definen las leyes correspondientes para la implementación de la

plataforma, y también se tendrán en cuenta las leyes de transporte, debido a que el proyecto

se basa en la movilización de las personas en vehículos.

Primero se definen las leyes de la informática y por ultimo las de transporte.

1. Leyes de Informática:

- Norma ISO 27001 “del aseguramiento, la confidencialidad e integridad de los datos y de

la información, así como de los sistemas que la procesan”.

- Ley 1273 de 2009 “de la protección de la información y de los datos” (Sánchez, 2017).

- Artículo 269A: Acceso abusivo a un sistema informático.

- Artículo 269B: Obstaculización ilegítima de sistema informático o red de

telecomunicación.

- Artículo 269C: Interceptación de datos informáticos.

- Artículo 269D: Daño Informático.

- Artículo 269E: Uso de software malicioso.

- Artículo 269F: Violación de datos personales.

- Artículo 269G: Suplantación de sitios web para capturar datos personales.

- Ley estatutaria 1581 de 2012 “de la protección de datos personales.

2. Leyes de transporte:
28

- Ley 769 de 2002, se expide el Código Nacional de Tránsito Terrestre y se dictan otras

disposiciones.

- Artículo 87. de la prohibición de llevar animales y objetos molestos en vehículos para

pasajeros

- Artículo 88. tránsito por el carril derecho al transporte público individual.

- Artículo 90. luces interiores del servicio público colectivo urbano.

- Artículo 91. de los paraderos.

- Artículo 92. del comportamiento de los pasajeros.

- Artículo 93. control de infracciones de conductores de servicio público.


29

Antecedentes

Actualmente a nivel mundial se están implementando y desarrollando soluciones y

aplicaciones móviles para la movilidad, compartir el vehículo y convertir esa práctica en

sinónimo de conocer gente, reservar un cupo en un transporte, ahorrar gastos y tiempo es el

objetivo con las que fueron creadas.

Mi Águila. Esta herramienta fue desarrollada para que los usuarios que se encuentren en

puntos cercanos compartan un solo carro a la hora de desplazarse a su lugar de destino. Lo

importante es empezar a generar confianza entre la gente, porque muchos viven cerca, van

para el mismo sitio y no se conocen. Los usuarios deben pertenecer a una red registrada

previamente por Mi Águila; después la conexión se realiza a través de Facebook, por lo tanto,

los usuarios pueden ver el perfil de quienes estarán en el auto. Por último, Mi Águila verifica

cada uno de los datos proporcionados. Además, lo novedoso de esta aplicación es que el

conductor puede recibir un reconocimiento económico por transportar al resto de los

pasajeros. El objetivo de esta app es eliminar la congestión vehicular y disminuir el impacto

ambiental. Mi Águila se encuentra disponible para dispositivos IOS y Android. [1]

A partir de esta idea, se determina que se va a dar uso de la herramienta con el mismo fin,

es decir, se tendrá el mismo objetivo principal que es compartir un solo transporte a la hora

de desplazarse, pero con el diseño de una plataforma que permita a los usuarios tener

contacto entre sí. No solo se usará para carro, sino para otro tipo de vehículos y tendrá acceso

para computadores y móviles.

Uber Technologies INC. Es una empresa internacional que proporciona a sus clientes una

red de transporte privado, a través de su software de aplicación móvil (app), que conecta los
30

pasajeros con los conductores de vehículos registrados en su servicio, los cuales ofrecen un

servicio de transporte a particulares. La empresa organiza recogidas en decenas de ciudades

de todo el mundo y tiene su sede en San Francisco, California. [2].

Uber Technologies INC, es una plataforma tecnológica tal cual como la idea de este

proyecto, que provisiona a otra empresa (Rasier) una aplicación para teléfono móviles que

permite conectar al público en general con los denominados proveedores independientes de

servicios de transporte incorporados al sistema.

Esta plataforma es utilizada a niveles nacionales, es decir, es un proyecto extenso,

mientras que el proyecto a implementar será usado a nivel del eje cafetero y exclusivamente

para la Universidad Unisarc.

Fuimonos. “La mayoría de usuarios de estas aplicaciones son personas que trabajan en la

misma empresa, o estudiantes que quieren compartir su carro para reducir los costos de

movilización”, apuntó el directivo. Garzón detalló que en tan solo un mes de operaciones se

han transportado unos 1.400 pasajeros, que se han comunicado a través de unos 13.000

mensajes internos en la aplicación. Estos emprendedores lograron triplicar la ocupación

vehicular promedio en la ciudad que, según Garzón, es de 1,5 pasajeros por auto y así

"reducir el tiempo que se demoran las personas en ir a sus trabajos". Para emplear los

servicios de la aplicación, los usuarios tienen que ingresar al portal y seleccionar la

comunidad a la que pertenecen, es decir, confirmar si son empleados o estudiantes de alguna

de las entidades reconocidas por el sistema. Luego el interesado registra un correo

institucional que valide esa información, pone un nombre y crea una contraseña con la que

ingresará al sistema. En esta aplicación los conductores tienen la libertad de decidir si cobran

o no por su servicio. Además, pueden dar detalles de su itinerario para que las personas

tengan más información sobre la ruta. [3]


31

A opinión personal, este tipo de aplicación es la que más se adapta al proyecto, debido a

que consiste principalmente a compartir el vehículo a estudiantes o trabajadores reduciendo

costos de transporte. El sistema de registro es preciso y adaptable para la plataforma y

presenta condiciones comunes a la idea planteada en este proyecto.

Según lo investigado, “fuimonos” ha dado buenos resultados en cuanto reducir costos y

tiempos en el momento de movilizarse.

Tappsi. es una aplicación que se creó para tratar de simplificar la forma actual en que se

piden o reservan taxis, se crea de la necesidad que casi todos vivimos al momento de querer

reservar un taxi, para solo darnos cuenta que nos va mejor saliendo a la lluvia para tratar de

frenar uno, o mirando a ver si se puede caminar a nuestro destino final. [4]

Tripda. Es una aplicación creada por brasileños y apoyada por la aceleradora alemana

Rocket Internet. Promueve el uso de carro compartido entre ciudades e incentiva el ahorro en

gastos de viaje. Fue lanzada en Colombia en julio del 2015. La aplicación se ha popularizado,

sobre todo, en periodos vacacionales y festivos. Durante la temporada navideña, 1.200

personas viajaron con Tripda cubriendo rutas como Bogotá-Villavicencio, Bogotá-Cali,

Bogotá-Girardot, Bogotá Melgar, Barranquilla- Santa Marta, Cali-Palmira, Bogotá-Tunja y

Bogotá Manizales. Tripda busca fomentar el consumo colaborativo. No buscamos que el

usuario se lucre con la aplicación, sino que comparta los gastos del viaje. Dependiendo de la

ruta elegida, compartir carro puede suponer un ahorro de hasta el 80 por ciento en los costos

de desplazamiento. [5]

Esta aplicación administra rutas extensas y permite compartir los gastos de manera

equitativa. El proyecto que se está proponiendo manejará rutas más precisas y cortas dentro

de un rango departamental y será decisión del usuario que presta el servicio si cobra o no el

traslado.
32

Con relación a los proyectos anteriormente mencionados (Guzmán & Chaparro, 2017), el

proyecto pretende desarrollar la plataforma tomando algunos aspectos de los mismos y

desechando otros, y al mismo tiempo es orientado hacia la comunidad universitaria, con el fin

de optimizar y facilitar el tiempo y recorrido de los usuarios desde sus puntos de origen hacia

la universidad y viceversa, contribuyendo a la movilidad en la ciudad, los costos de trasporte

y al cumplimiento en los horarios académicos.


33

Metodología

Al término de mencionar algunas de las metodologías agiles más recomendadas a usar en

un proyecto y obtener conocimiento sobre cómo funciona cada una, se logra analizar y tomar

la metodología UML como parte del proceso. Sabiendo como resultado que el UML permite

seguir paso a paso cada uno de los requerimientos del cliente, analizarlos y tomar mejores

decisiones. Reduce el tiempo de desarrollo considerablemente y facilita el control del proceso

y la ejecución de las tareas programadas para culminar el proyecto dentro de los tiempos

previstos, facilita la comunicación entre los desarrolladores, permite elegir el orden en que

pueden hacerse las cosas mediante casos de uso. Aunque este tipo de modelado no es una

metodología con tal, reúne aspectos de las demás metodologías agiles y los utiliza para

generar un buen proceso en el desarrollo del software, con el objeto de poder especificar,

construir, visualizar y documentar.


34

Cronograma

OBJETIVOS ACTIVIDADES
1. Establecer la recolección de Actividad 1 =
información necesaria para el - Diseñar instrumentos de recolección
desarrollo del proyecto - Recolectar información
- documentar requerimientos
2. Determinar y aplicar una Actividad 2 =
metodología apropiada y - Diseñar modelado de
adaptable requerimientos.
- Análisis del modelado.

3. Diseñar una estructura de base de Actividad 3=


datos práctica y segura para la - Recopilar y analizar requisitos.
consulta de información. - Diseño conceptual.
- Elección de un sistema de gestión
de bases de datos.
- Diseño lógico y físico.
- Implementación.
4. Permitir al usuario adquirir el Actividad 4=
servicio mediante un proceso de - Construir sistema de ingreso de
inscripción al sitio. información por parte del usuario.
- Entrega de plataforma y
documento.

Fecha de inicio: 18 octubre 2020

Tiempo Mes 1 Mes 2 Mes 3 Mes 4 Mes 5


Actividad S1 S2 S3 S4 S1 S2 S3 S4 S1S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4

Actividad 1 x x x x
Actividad 2 x x x x

Actividad 3 x x x x x x x x x x

Actividad 4 x x x x x x x x
35

Fecha de finalización: 7 marzo 2021

Presupuesto

Actividad 1 Recurso Unidad Cantidad


medida
Diseñar Ingeniero Horas 25
instrumento Equipos computo Horas 18
Papelería Unidad 25
Recolectar Celular Minutos 100
36

información Viáticos Unidad 3


Gastos de Unidad 2
representación
Souvenirs Unidad 20
Secretaria Horas 0,9
Auxiliares Horas 8
Ingeniero Horas 5
Documento Equipo de computo Horas 20
Ingeniero Horas 20

Actividad 2 Recurso Unidad Cantidad


medida
Diseñar modelado Ingeniero Horas 30
Equipos computo Horas 20
Secretaria Horas 0,9
Análisis del Ingeniero Horas 18
modelado Equipos de cómputo Horas 15
Analista Horas 18

Actividad 3 Recurso Unidad Cantidad


medida
Recopilar y analizar Ingeniero Horas 20
requisitos Tecnólogo Horas 15
Equipos de computo Horas 20
Diseño conceptual Ingeniero Horas 12
Secretaria Horas 4
Tecnólogo Horas 70
Elección de un
sistema de gestión
de bases de datos. Ingeniero Horas 12
Diseño lógico y Equipos de computo Horas 10
físico Ingeniero Horas 30
Implementación Papelería 22
Tecnólogo Horas 150
Equipos de computo Unidad 130

Actividad 4 Recurso Unidad Cantidad


medida
Construcción de Ingeniero Horas 50
sistema de ingreso Equipos computo Horas 50
Tecnólogo Horas 100
Entrega de Ingeniero Horas 30
plataforma y Equipos de cómputo Horas 30
documento. Secretaria Horas 10
37

Presupuesto

Recurso Unidad Cantidad Vlr unit Vlr Total


medida
Ingeniero Horas 252 48000 12.096.000
Tecnólogo Horas 335 30000 10.050.000
Analista Horas 18 6250 450000
Secretaria Horas 14.9 6250 93125
Auxiliares Horas 8 1000 8000
Equipo de Horas 313 10000 313000
computo
Viáticos Unidad 10 10000 100000
Gastos Rep. Unidad 5 40000 200000
Souvenirs Unidad 30 2000 60000

Arrendamiento Mes 5 1500000 7500000


Serv.generales Mes 5 1125000 5625000
Refrigerios y Mes 5 200000 1000000
otros Mes 5 250000 1250000
Serv. públicos
Costo del proyecto 38.745.125
11.623.537
AIU (Administración de impuestos imprevistos) =30%
50.368.662
38

Bibliografía

 SISTEMAS INFORMATICOS - 2ª EDICION, Isabel Mª Jiménez Cumbreras

 Comillas Journal of International Relations (Internet como herramienta al servicio del

autoritarismo- Análisis de caso de Venezuela), Miguel Sáez Poveda.

 http://repositorio.uts.edu.co:8080/xmlui/handle/123456789/3364, METODOLOGÍAS

Y TECNOLOGIAS DE DESARROLLO DE SOFTWARE- MORENO ARENAS,

ARLEY FABIAN - 2020.

 Navarro Cadavid, Andrés; Fernández Martínez, Juan Daniel; Morales Vélez,

Jonathan. Revisión de metodologías ágiles para el desarrollo de software


39

PROSPECTIVA, vol. 11, núm. 2, julio-diciembre, 2013, pp. 30-39. Universidad

Autónoma del Caribe.

 Metodologías tradicionales vs. metodologías ágiles. Roberth G. Figueroa, Camilo J.

Solís, Armando A. Cabrera. Universidad Técnica Particular de Loja, Escuela de

Ciencias en Computación.

 Universidad de Valladolid E. U. de Informática (SEGOVIA). Guía Comparativa de

Metodologías Ágiles. María José Pérez Pérez, 2012.

 Kanban y Scrum – obteniendo lo mejor de ambos. Henrik Kniberg & Mattias Skarin

Prólogo de Mary Poppendieck & David Anderson, 2010.

 UML, ejemplo sencillo sobre Modelado de un Proyecto. Armando Canchala, 2017.

 Utilidad del Lenguaje Unificado de Modelado (UML) en el desarrollo de software

profesional dentro del sector empresarial y educativo. Universidad Autónoma de

Coahuila- Coordinación General de Estudios de Posgrado e Investigación.

CienciaCierta No. 56, octubre - diciembre 2018. Dra. Alicia Elena Silva Avila,

Esperanza Guadalupe Ledezma Zamora, Jesús Abraham Castorena Peña, Dra. Alma

Jovita Domínguez Lugo, Andrea Riojas Martínez.

 Metodología, método y propuestas metodológicas en Trabajo Social. Natty Andrea

Gordillo Forero, Revista Tendencia & Retos Nº 12: 119-135 / octubre 2007.

 Centro de Investigación de la web. Universidad de Chile-Claudio Gutiérrez Gallardo,

2008.

 Análisis de la ley 1273 de 2009 y la evolución de la ley con relación a los delitos

informáticos en Colombia. Zulay Nayiv Sánchez Castillo- universidad nacional

abierta y a distancia ―Unad‖ escuela de ciencias básicas e ingeniería especialización

en seguridad informática Chiquinquirá 2017.

 Ley estatutaria 1581 de 2012 (octubre 17).


40

 Ley 769 de 2002 (6 de julio). Diario Oficial No. 44.932 de 13 de septiembre de 2002.

Poder público - rama legislativa- Por la cual se expide el Código Nacional de Tránsito

Terrestre y se dictan otras disposiciones.

 [1] Revista Portafolio “Mi águila cambiara al mundo” [En línea] consultado

Noviembre 03 de 2016 10:00 am, disponible en:

http://www.portafolio.co/negocios/empresas/miaguila-cambiara-mundo-muestra-ruta-

uber-23122

 [2] Loizos, Connie (29 de abril de 2016). «Handcuffed to Uber». TechCrunch (en

inglés). Consultado el 22 de octubre de 2016

 [3] Solano Arenas John Camilo, Jaimes Fajardo Leonardo Andrés "Implementación

en Java del modelo de propagación Andino UIS® para planificación y análisis de

redes celulares sobre CellGis" [En línea] febrero de 2016, disponible en:

http://repositorio.uis.edu.co/jspui/bitstream/123456789/3308/2/125826.pdf

 [4] Diario el Tiempo “Tappsi el fenómeno de las mil descargas” [En línea] consultado

noviembre 03 de 2016 10:00 am, disponible en:

http://www.eltiempo.com/archivo/documento/CMS-12779543

 [5] Juan Bernardo Quintero, Raquel Anaya. (diciembre 2007). 2MDA Y EL PAPEL

DE LOS MODELOS EN EL PROCESO DE DESARROLLO DE SOFTWARE2.

EIA, ISSN 1794-1237 Número 8, 131-146. [En línea] Consultado en marzo de 2016,

disponible en:

http://repository.eia.edu.co/revistas/index.php/reveia/article/view/190/187

 Desarrollo de aplicación móvil de transporte entre la comunidad universitaria con

capacidad de geolocalización para el proyecto ud sobre ruedas. Néstor Raúl guzmán


41

Díaz & Miguel Chaparro Ariza- Universidad Distrital Francisco José de Caldas,

Bogotá D.C. 2017.

 Berzal & Cortijo & Cubero, Desarrollo profesional de Aplicaciones Web con

ASP.NET

 Introducción a la programación Teoría y práctica. Rodríguez & Santamaría & Rabasa

& Martínez, 2014.