argo (sistema contractual y compras) autor:...

ANÁLISIS, DISEÑO Y DESARROLLO DEL MÓDULO DE GESTIÓN DE

NECESIDADES Y SOLICITUD DE DISPONIBILIDAD PARA EL SISTEMA

ARGO (SISTEMA CONTRACTUAL Y COMPRAS)

AUTOR:

CAMILO ANTONIO TORRES CAMACHO

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.

2017

ANÁLISIS, DISEÑO Y DESARROLLO DEL MÓDULO DE GESTIÓN DE NECESIDADES Y SOLICITUD DE DISPONIBILIDAD PARA EL SISTEMA

ARGO (SISTEMA CONTRACTUAL Y COMPRAS)

AUTOR:

CAMILO ANTONIO TORRES CAMACHO

20102020097

PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS

DIRECTOR:

ING. ALEJANDRO PAOLO DAZA CORREDOR

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.

2017

TABLA DE CONTENIDO

Capítulo 1. Introducción.....................................................................................9

Capítulo 2. Planteamiento del problema..........................................................11

2.1 Descripción del problema.......................................................................11

2.2. Formulación del problema.....................................................................12

Capítulo 3. objetivos.........................................................................................13

3.1. Objetivo general.....................................................................................13

3.2. Objetivos específicos.............................................................................13

Capítulo 4. Justificación...................................................................................15

Capítulo 5. Alcances y limitaciones..................................................................16

5.1 Alcances.................................................................................................16

5.2 Limitaciones............................................................................................17

Capítulo 6. Antecedentes.................................................................................18

6.1 Oracle Si C@pital...................................................................................18

6.2 Aplicación necesidades y solicitudes de cdp..........................................19

Capítulo 7. Marco Teórico................................................................................21

5.1 Herramientas..........................................................................................21

5.1.2 PostgreSQL.....................................................................................21

5.1.2 Repositorios GIT..............................................................................23

5.1.3 WEB Services..................................................................................24

5.1.4 AngularJs.........................................................................................26

5.1.5 Beego...............................................................................................27

5.2 Gestión de Contratación y Compras de la Universidad Distrital..............29

5.2.1. Proceso pre-contractual..................................................................31

5.2.2. Proceso contractual........................................................................32

5.2.3 Proceso Post-Contractual................................................................32

Capítulo 8. Metodología...................................................................................33

Capítulo 9. Análisis y Diseño............................................................................35

9.1 Modelo de Datos.....................................................................................35

9.2 BPMN.....................................................................................................39

9.3 Arquitectura de Información....................................................................41

Capítulo 10. Desarrollo.....................................................................................44

10.1 Back-End..............................................................................................44

10.2 Front-End..............................................................................................48

Capítulo 11. Resultados...................................................................................56

Capítulo 11. Trabajos Futuros..........................................................................58

Capítulo 12. Conclusiones...............................................................................59

Capítulo 13. Bibliografía...................................................................................60

Capítulo 14: Anexos.........................................................................................62

ÍNDICE DE FIGURAS

Figura 1 Solicitud CDP Si C@pital............................................................................19

Figura 2 Proyecto nuevo Beego..................................................................................27

Figura 3 Componentes Beego.....................................................................................28

Figura 4 Lógica ejecución Beego...............................................................................29

Figura 5 Mapa de Procesos IDEXUD.......................................................................30

Figura 6 Metodología SCRUM.....................................................................................33

Figura 7 Modelo de datos precontractual...............................................................37

Figura 8 Diagrama BPMN Precontractual..............................................................40

Figura 9 Arquitectura de la Información..................................................................42

Figura 10 Transacción 1..................................................................................................45



Figura 13 Transacción 4.................................................................................................47

Figura 14 Formulario completo solicitud necesidad..........................................50

Figura 15 Sección Responsables...............................................................................50

Figura 16 Sección General............................................................................................50

Figura 17 Sección Objeto Contractual.....................................................................51

Figura 18 Sección Marco Legal...................................................................................51

Figura 19 Sección Especificaciones Compras.....................................................51

Figura 20 Sección Especificación Servicios..........................................................52

Figura 21 Sección Financiación inversión..............................................................52

Figura 22 Sección Financiación Funcionamiento...............................................53

Figura 23 Gestión de Necesidades...........................................................................54

Figura 24 Detalles Necesidad......................................................................................54

Figura 25 Aprobación Necesidad...............................................................................55

CAPÍTULO 1. INTRODUCCIÓN

Toda entidad, ya sea pública o privada, requiere una gestión contractual

que permita un control preciso sobre la planeación, organización y ejecución de

los diferentes contratos tanto a nivel interno como a nivel externo, teniendo en

cuenta unas etapas pre-contractuales, contractuales y post-contractuales.

Una de las entidades más importantes del distrito es la Universidad

Distrital Francisco José de Caldas, el cual es un ente universitario autónomo de

carácter estatal del orden Distrital de Santa Fe de Bogotá D.C., con Personería

Jurídica, gobierno, rentas y patrimonio propio e independiente [1]. La

Universidad, de acuerdo a lo mencionado previamente, maneja sus propios

procesos de gestión de contratos, los cuales se han venido realizando sobre un

sistema especializado del cual se quiere separar debido a ciertos

inconvenientes que se explicarán más adelante.

La Universidad Distrital Francisco José de Caldas es autónoma de acuerdo

con la Constitución Política y la ley, tiene plena independencia de decidir sobre sus

programas. Tiene autonomía para gozar y disponer de los bienes y rentas que

conforman su patrimonio, con el fin de programar, aprobar, modificar y ejecutar su

propio presupuesto en los términos definidos en la ley y normas pertinentes. Los

bienes de la Universidad son imprescindibles e inembargables. Para la

administración y manejo de los recursos generados por actividades académicas,

asesorías o de extensión, puede crear fondos especiales con el fin

Universidad Distrital Francisco José de Caldas 9

de garantizar el fortalecimiento de la institución. Su manejo, administración y

control se hace conforme a la ley. [1]

En este trabajo se va a realizar el análisis, diseño y desarrollo detallado de

los módulos para el sistema ARGO (Sistema contractual y compras de la

Universidad Distrital Francisco José de Caldas) concernientes a la etapa pre-

contractual de la misma, haciendo especial énfasis en la solicitud de una

necesidad, aprobación de una necesidad, solicitud de CDP (Certificado de

Disponibilidad Presupuestal) y si es el caso la desaprobación de una necesidad.

Todo lo anterior teniendo en cuenta la filosofía de la oficina asesora de sistemas en

cuanto al uso de las herramientas de software libre y siguiendo los estándares y/o

lineamientos que la oficina ha desarrollado para este tipo de productos.


CAPÍTULO 2. PLANTEAMIENTO DEL

PROBLEMA

2.1 DESCRIPCIÓN DEL PROBLEMA

Cada año la Universidad Distrital Francisco José de Caldas realiza unos

contratos de todo tipo con actores internos y externos a la misma. Todos estos

contratos se han tramitado con ayuda de un software especializado llamado “Sí

C@pital”.

El Sistema de Información “Sí C@pital” nació en 1998 con el objetivo de

tener un manejo eficaz y confiable de la información en entidades del sector

público, con lo cual se encuentra incluida la gestión de la información de la

Universidad Distrital, así como su unidad de extensión IDEXUD. Sin embargo,

debido al crecimiento de la universidad ahora cualquier proceso realizado

mediante esta herramienta es muy problemático y se vuelve tedioso su manejo

para cualquier usuario incluso con tareas muy pequeñas.

Debido a esto, la universidad comenzó a buscar alternativas, siendo una de

ellas el desarrollo de su propio sistema de control financiero, administrativo y

académico. Varios de estos elementos actualmente se manejan mediante “Sí

C@pital”, pero se ha buscado la manera de trasladarlos poco a poco a una nueva

herramienta. Actualmente el nuevo sistema requiere la inclusión de la gestión pre-

contractual debido al volumen de contratos que normalmente tiene la entidad


educativa, por lo cual se necesita que la información se mueva en una

aplicación más robusta y que facilite las tareas de mantenimiento y extensión.

2.2. FORMULACIÓN DEL PROBLEMA

Ante la problemática descrita anteriormente, ¿Cómo se puede incluir

todo lo referente a la parte pre-contractual en el sistema al cual la Universidad

quiere utilizar en reemplazo de “Sí C@pital”?


CAPÍTULO 3. OBJETIVOS

3.1. OBJETIVO GENERAL

Realizar el análisis, diseño y desarrollo de los módulos que se van a

encargar de la administración de las necesidades y solicitud de Certificados de

Disponibilidad Presupuestal (CDP) de la Universidad Distrital para optimizar el

desarrollo de éstos y tener una herramienta completa que permita a la

universidad seguir desligándose de “Sí C@pital”.

3.2. OBJETIVOS ESPECÍFICOS

1. Definir los requerimientos funcionales de los módulos de necesidades y

Certificados de Disponibilidad Presupuestal (CDP) para identificar su

prioridad en el desarrollo, a qué módulos se asocian cada uno, entre otros.

2. Realizar el diseño correspondiente de las funcionalidades requeridas

para visualizar el comportamiento del sistema y el traslado de

información en el mismo.

3. Crear un modelo de datos completo de los módulos de necesidades y

Certificados de Disponibilidad Presupuestal (CDP) para construir una

base de datos que asegure la integridad de la información.


4. Brindar los servicios CRUD correspondientes del modelo propuesto a

partir de un api para que la información sea transversal en los sistemas

relacionados de la Oficina Asesora de Sistemas.

5. Desarrollar los módulos concernientes a las necesidades y las

solicitudes de Certificados de Disponibilidad Presupuestal (CDP) de

acuerdo al diseño planteado para poder integrar la gestión pre-

contractual en el sistema ARGO.


CAPÍTULO 4. JUSTIFICACIÓN

Debido a que la Universidad Distrital gestiona muchos procesos a

diferentes niveles, el sistema “Sí C@pital” ha sido y sigue siendo ineficiente

para agilizar la realización de éstos procesos. La institución de educación

superior ha considerado e iniciado la creación de varios sistemas que se

encarguen de cierto tipo de trámites con el objetivo de ya no depender del

sistema de información de la Secretaría Distrital de Hacienda. Sin embargo, el

funcionamiento complejo de los procesos de la universidad hace que sea

indispensable construir sistemas de alta calidad y extensibles.

Por esta razón se ha optado por hacer un análisis, diseño y desarrollo

completo para los módulos mencionados anteriormente que pertenecen a la

parte pre-contractual de la universidad con el objetivo de poder solventar este

proceso de forma fácil y rápida. Pero se puede presentar el mismo problema

así que se plantean nuevas herramientas el ¿Cómo evitar repetir los mismos

errores?


CAPÍTULO 5. ALCANCES Y

LIMITACIONES

5.1 ALCANCES

Los alcances para el proyecto precontractual de Argo el cuál conforman

los módulos de necesidad (solicitud y aprobación o rechazo) y solicitud de CDP

son:

• El equipo de trabajo se organizará por los roles definidos de la

metodología SCRUM. Los roles que se asumirán en la pasantía

corresponden al equipo de análisis, equipo de diseño y equipo desarrollo.•• Se deben definir todos los requerimientos con respecto a las tareas de la

solicitud, aprobación y desaprobación de necesidad y la solicitud de CDP.•• Realizar un modelo de datos que soporte el desarrollo pensado para

estos módulos y que se apegue a los estándares OAS.•• Análisis y diseño de los módulos a desarrollar incluyendo arquitectura

de datos y bpmn.•• Desplegar servicios de CRUD sobre el modelo de datos definido

por medio de Apis.


5.2 LIMITACIONES

A continuación se muestran algunas limitaciones que tiene el

proyecto frente a los temas a tratar:

• Desarrollo del cliente en angular y desarrollo en Apis con Beego según

lineamientos y/o estándares de la Oficina Asesora de Sistemas.•• El desarrollo simula un usuario determinado pero no tiene un sistema

de logeo ni manejo de roles ya que se encuentra esta parte en

desarrollo con WSO2 en la Oficina Asesora de Sistemas.•• El módulo de necesidades corresponde a aquellas más comunes y no

acoge los casos especiales como lo son necesidades para nóminas.•• El módulo de necesidades no tendrá en este proyecto un sistema de

edición y el sistema de notificaciones no se ha implementado debido a

que se encuentra en desarrollo por parte de la Oficina Asesora de

Sistemas.•• El proyecto debe realizarse sobre el marco de software libre.

• No se tiene relación con el PAA (Plan Anual de Adquisiciones de la

Universidad Distrital Francisco José de Caldas) ya que aún está en

etapa de análisis en la Oficina Asesora de Sistemas.•• No se incluye la parte de centros de costos debido a que se encuentra

en planeación por parte de la Oficina Asesora de Sistemas.


CAPÍTULO 6. ANTECEDENTES

6.1 ORACLE SI C@PITAL

La base de datos de Si C@pital que opera en la Universidad Distrital es

extensa con muchos esquemas y entidades (de los cuales hay muchos que ni

siquiera están en uso) haciendo uso de muchos procedimientos.

Al analizar el modelo de bases de datos que maneja el subsistema de

necesidades y de solicitud de disponibilidad presupuestal de Si C@pital se

puede ver como existen muchas entidades o atributos que ni siquiera se usan,

no se conoce a que corresponden los valores de estos o directamente es

información replicada debido a que es una base de datos que no está

normalizada. El problema de la información replicada es evidente cuando se

analizan las entidades correspondientes a las disponibilidades presupuestales,

las necesidades, los registros presupuestales por ejemplo se puede ver como

información importante y que no debería variar como objeto del contrato,

justificación del contrato, dependencia solicitante, entre otras se repite en cada

entidad provocando no solo que se replique la información sino que puede

cambiarse en cada entidad y generar graves problemas tanto en contratación

como la información financiera o legal de Universidad.

El modelo también tiene muchos problemas de integralidad con los demás

sistemas que maneja la Universidad Distrital y muchas de las funciones que


debería cumplir un sistema integral se tienen que hacer manual o en otros

sistemas debido a los problemas que se presentan con este modelo.

6.2 APLICACIÓN NECESIDADES Y SOLICITUDES

DE CDP

La aplicación La aplicación como ya se mostró en el apartado 6.1 está

ligada a un modelo de datos con muchas limitaciones y propenso a errores en

cuanto a la información que se le proporciona al sistema.

Figura 1 Solicitud CDP Si C@pital. Fuente: Propia.


La interfaz de usuario es poco intuitiva y no tiene validaciones y/o

verificaciones de ningún tipo. Además dicha interfaz se ve desactualizada

además de que mucha de la información en las bases de datos y mostrada en

la aplicación es irrelevante y ya que no tiene las validaciones correspondientes

permite que se guarden solicitudes mal redactadas o con información no útil

para el sistema.


CAPÍTULO 7. MARCO TEÓRICO

5.1 HERRAMIENTAS

Debido a ciertas exigencias del sistema (escalabilidad, robustez, etc.) se

requiere el uso de ciertos elementos para que los módulos nuevos puedan

integrarse exitosamente al sistema ARGO (el cuál es el encargado de la

gestión contractual y de compras) y a los demás sistemas de la Oficina

Asesora de Sistemas que hacen parte del ERP como KRONOS (Sistema

Financiero) y ÁGORA (Sistema único de registro de personas y proveedores).

Estos elementos son:

5.1.2 POSTGRESQL

PostgreSQL es un Sistema Gestor de Bases de Datos Relacional

(RDBMS) objeto-relacional de código abierto, inicialmente creado como Post

Ingres para solucionar problemas existentes de las bases de datos que existían

a mediados de los 80. Es totalmente compatible con ACID (Son las siglas de

atomicidad, consistencia, aislamiento, durabilidad; Conjunto de 4 propiedades

que garantizan que las transacciones en las bases de datos se realicen de

forma confiable). [2]


Incluye una biblioteca de funciones estándar con cientos de funciones

integradas que van desde las operaciones matemáticas básicas, operaciones

con strings para criptografía y compatibilidad con Oracle. Los disparadores

(triggers) y procedimientos almacenados pueden ser escritos en C y se cargan

en la base de datos como una biblioteca, lo cual permite una gran flexibilidad y

ampliación de sus capacidades. Del mismo modo, PostgreSQL incluye un

framework que permite a los desarrolladores definir y crear sus propios tipos de

datos personalizados. Como resultado, una gran cantidad de tipos de datos

avanzados se han creado que van desde los geométricos y espaciales para

direcciones de red, incluso para los tipos de datos ISBN / ISSN (International

Standard Book Number / Número Internacional Normalizado de Publicaciones

Seriadas), los cuales pueden ser opcionalmente agregados al sistema.QL

cuenta con una funcionalidad distinguible de otros sistemas gestores, la cual es

el control de concurrencia multiversión (MVCC), que permite hacer

transacciones consistentes, con lo cual se incrementa el rendimiento del

sistema. Esto es porque PostgreSQL permite que mientras un proceso se

escribe en una tabla, otros accedan a la misma tabla sin necesidad de

bloqueos y así cada usuario tiene una visión consistente de la base de datos y

de las tablas a partir del último commit.

Existen otras características en PostgreSQL como por ejemplo la llamada

Hot-Standby, la cual permite hacer búsquedas en los servidores mientras éstos se

encuentran en espera o en recuperación, por lo que no se requiere hacer bloqueo

completo al sistema para realizar tareas de mantenimiento. Otras características

que valen la pena remarcar son: PostgreSQL incluye la herencia entre tablas

haciéndolo un gestor de bases de datos objeto-relacional, realiza

[3] [4]

copias de seguridad en “caliente” (Online/hot backups) siendo esto muy útil a

no necesitar deshabilitar toda la base de datos a la hora de hacer un backup,

tiene múltiples métodos de autenticación, a pesar de ser una herramienta de

software libre posee una documentación muy completa aunque por obvias no

tiene soporte por una empresa como tal.

Este sistema de bases de datos ofrece la posibilidad de definir funciones

personalizadas como PL/Perl, PL/PHP, PL/pgSQL, entre otras. Se encuentra

disponible para muchas plataformas tales como Solaris, Windows, Ubuntu, etc.,

y cualquier usuario tiene a disposición el código fuente. [5]

5.1.2 REPOSITORIOS GIT

Git es un sistema de control de versiones libre, el cual tiene como

objetivo ayudar a que los desarrolladores puedan hacer mantenimiento

eficiente sobre archivos de código fuente de cualquier software desarrollado. [6]

Git tiene como principal particularidad la manera en que se gestionan

las modificaciones en los archivos fuente. Varios sistemas de control de

versiones tienen almacenados los archivos y solamente manejan los cambios

en una lista, pero Git realiza el control usando una “imagen” del estado de cada

archivo en un instante específico. Así en lugar de crear archivos que muchas

veces no tienen ningún cambio, se crean referencias a éstos. [7]

Los repositorios Git son la forma en que se almacenan los archivos para

hacer el control del versionamiento. Es posible tener repositorios Git de dos

formas: de forma local (instalando Git en el equipo) o en la nube (mediante


GitHub). GitHub, como tal, solamente es un sitio donde se puede manejar el

sistema Git, por lo que GitHub si es un proyecto comercial.

El Git que se instala en servidores locales tiene menos funcionalidades

que el que se encuentra en GitHub, pero no por eso dejar de ser un sistema

completo que, en esencia, realiza exactamente lo mismo. Está disponible para

muchos de los sistemas operativos comunes como Mac, Windows o Linux. [6]

5.1.3 WEB SERVICES

Los Web Services (Servicios Web) son un conjunto de tecnologías y

aplicaciones que tienen la capacidad de operar en la web. Los usuarios de

Internet (que con seguridad son casi todas las personas del planeta) pueden

solicitar en la red un servicio que sea provisto por alguna persona o compañía.

Por ello se han establecido mecanismos de comunicación estándares entre

aplicaciones web, con la finalidad de presentar información dinámica al usuario.

En el proceso que realizan los distintos Web Services hay implícitas

varias tecnologías importantes que permiten la buena circulación de

información entre usuario y estos servicios. La primera a destacar es SOAP

(Protocolo Simple de Acceso a Objetos), el cual permite la interacción entre

varios dispositivos y sirve para transmitir información compleja, ya sea por

SMTP, HTTP, etc. [8]

Un desarrollador puede incluir en un sitio web las llamadas soluciones

sentencias, estas consisten en instrucciones que consumen Web Services de

terceros o propios. Un Web Service puede ser registrado para poder dejarlo a


disposición de otros usuarios y para que los mismos puedan localizarlo. Un

mecanismo para registrar estos servicios es por medio de UDDI (Universal

Description, Discovery and Integration), es decir un repositorio de Web Services.

El protocolo de comunicación utilizado es el SOAP por lo general el cual

es relativamente sencillo de utilizar. Pero ¿Qué es SOAP? SOAP es el

protocolo que define el formato XML para los mensajes de intercambio en el

uso de un Web Service. Para aquellos programadores que solían utilizar

llamadas del tipo RPC, SOAP también las soporta. Adicionalmente, es posible

mediante SOAP definir un mensaje HTTP y este punto es de especial interés

puesto que el protocolo imprescindible para Internet es HTTP. [9]

La otra tecnología distinguible en los Web Services es WSDL (Lenguaje

de Descripción de Servicios Web), el cual es una especificación de cómo se va

a enviar la información (sintaxis, mecanismos de intercambio de mensajes,

entre otras). Esta especificación se realiza en un documento que los

dispositivos pueden procesar donde se establecen todos los detalles del paso

de mensajes y de contenido. [10]

La arquitectura básica del modelo de web services describe a un

consumidor, un proveedor y ocasionalmente un corredor (broker). Relacionados

con estos agentes están las operaciones de publicar, encontrar y enlazar. La idea

básica consiste en que un proveedor publica su servicios en un corredor, luego un

consumidor se conecta el corredor para encontrar los servicios deseados y una

vez que lo hace se realiza un lazo entre el consumidor y el proveedor. Cada

entidad puede jugar alguno o todos los roles. Lo anterior facilita la ejecución de

muchas tareas y posee muchas ventajas entre las cuales están


la interoperabilidad, la ubicuidad, encapsulamiento, facilidad de uso y soporte

por parte de empresas importantes que trabajan generalmente con SOAP. [11]

5.1.4 ANGULARJS

“AngularJS es Javascript. Es un proyecto de código abierto, realizado en

Javascript que contiene un conjunto de librerías útiles para el desarrollo de

aplicaciones web y propone una serie de patrones de diseño para llevarlas a

cabo. En pocas palabras, es lo que se conoce como un framework para el

desarrollo, en esta caso sobre el lenguaje Javascript con programación del

lado del cliente.” [12]

AngularJs permite mejorar en el ámbito de HTML sin tener grandes

conocimientos de este, debido a su flexibilidad y su código fácil de entender y

aprender. Hay conceptos propios de AngularJs muy interesantes como lo son

las directivas las cuáles permiten una comunicación bidireccional entre las

vistas y los controladores ayudando mucho en el proceso de desarrollo.

Una parte importante de angular son los servicios ya que se comunican

con el servidor para obtener y/o enviar información que luego los controladores

harán uso y esto se mostrará en las vistas haciendo de AngularJs algo muy

completo.


5.1.5 BEEGO

Es un web framework para el lenguaje Go. Beego tiene muchas ventajas

como lo es ofrecer servicios de un muy completo ORM, soporte de sesiones,

internacionalización, soporte de despliegue, etc. Todo lo anterior siendo una

herramienta con licencia de código abierto, disponible en github.com/beego/bee.

[13]

Figura 2 Proyecto nuevo Beego. Fuente: [13]

El framework Beego es muy intuitivo y con solo un comando de creación

permite la creación de un nuevo proyecto organizado y que tiene algunos


archivos claves (que se pueden ver en el esquema de Beego, figura 2)

para realizar cualquier proyecto, los cuáles son:

Archivo Bootstrap (main.go)

Archivo de configuración (conf/app.conf)

Controlador por defecto (controller/default.go)

Pruebas (tests/default_test.go)

Plantilla de Vistas (views/index.tpl) [13]

Beego ha sido creado para la programación modular y está constituido por

8 componentes como se ve en la siguiente figura:

Figura 3 Componentes Beego. Fuente: [14]


Beego utiliza una arquitectura MVC (Modelo Vista Controlador). La lógica

de ejecución puede verse en la Figura 4. [14]

Figura 4 Lógica ejecución Beego. Fuente: [14]

5.2 GESTIÓN DE CONTRATACIÓN Y COMPRAS

DE LA UNIVERSIDAD DISTRITAL

El Sistema de Gestión de Contratación y Compras ARGO es

actualmente el encargado del proceso contractual de la universidad, el cual

cuenta con algunos componentes que intervienen durante gran parte de éste.

Uno de ellos es las Unidades Ejecutoras que están encargadas de esta

gestión, la cuales son dos. La primera de ellas está destinada para la unidad de

extensión IDEXUD (Instituto de Extensión y Educación para el Trabajo y

Desarrollo Humano), el cual se encarga de vincular a la universidad con

diferentes sectores (en especial el público) y que cuenta con secciones propias

de compras, contabilidad, presupuesto, jurídica, tesorería, etc. La segunda está

compuesta por dos secciones: Compras (para contratos con un monto menor a


100 SMMLV) y Jurídica (para contratos con monto superior a los 100 SMMLV). El

monto destinado para los contratos es denominado Registro Presupuestal (en

caso de que sea del año en curso), Reserva Presupuestal (en caso de ser del año

inmediatamente anterior) o Pasivo Exigible (si es de mayor antigüedad).

Figura 5 Mapa de Procesos IDEXUD. Fuente: [15]

Otro componente importante son los Ordenadores de Gasto, quienes

tienen como función aprobar las necesidades solicitadas por parte de las

dependencias a la universidad. Existen 10 Ordenadores de Gasto, los cuales

son: Rector, Vicerrector Administrativo, Vicerrector Académico, Director del

CIDC (Centro de Investigaciones y Desarrollo Científico), Director del IDEXUD,


Decano de la Facultad de Ingeniería, Decano de la Facultad de Ciencias y

Educación, Decano de la Facultad Tecnológica, Decano de la Facultad de Artes

y Decano de la Facultad de Medio Ambiente.

Teniendo estos elementos mencionados previamente, la gestión de

contratación y compras de la universidad Distrital se divide en tres partes, las

cuales son:

5.2.1. PROCESO PRE-CONTRACTUAL

El proceso pre-contractual de la universidad se divide en diferentes

etapas. Se inicia con la solicitud de una necesidad que tiene la universidad por

parte de alguna de sus dependencias, la cual puede ser aprobada o no

mediante un Ordenador de Gasto. Si éste aprueba la necesidad se realiza otra

solicitud, pero ahora es de un Certificado de Disponibilidad Presupuestal

(CDP), el cual busca la destinación de recursos para suplir la necesidad.

Luego se pasa el CDP a aprobación (también realizada por un

Ordenador de Gasto, el cual puede variar dependiendo del dinero que se

necesita destinar). Al ser aprobado el CDP se procede a realizar la expedición

del mismo y luego se realiza una invitación y su posterior evaluación con el fin

de elegir el proponente más adecuado para destinar el dinero del CDP y así

iniciar el proceso contractual. Es importante aclarar que este proceso dee

funcionar en conjunto entre el sistema contractual y el sistema financiero.


5.2.2. PROCESO CONTRACTUAL

Al tener ya expedido el CDP se pasa a radicar una pre-contratación, y

con ello se procede a realizar la contratación. Para ello se asigna un número

de contrato, donde se especifica la persona natural o jurídica que está

solicitando el dinero, el cual se legaliza para adquirir formalmente un contrato

con el proponente seleccionado. Cuando se tiene un acta de inicio del contrato

ya suscrito y demás se inicia con la solicitud de Registro Presupuestal y una

vez aprobado y expedido se cuenta con un Certificado de Registro

Presupuestal (CRP).

5.2.3 PROCESO POST-CONTRACTUAL

Una vez se tiene el Certificado de Registro Presupuestal (CRP) se inicia

la gestión post-contractual en el cual se pueden registrar novedades sobre el

contrato como cambio de supervisores, adición de tiempo y/o valor,

suspensión, anulación, etc. Y con ello viene toda la parte de control y

seguimiento del contrato dando como finalizado todo el proceso.


CAPÍTULO 8. METODOLOGÍA

La metodología a aplicar en este proyecto es el modelo SCRUM,

teniendo en consideración los diferentes roles, iteraciones (Sprints) y

documentos propios de esta metodología ágil. SCRUM trabaja sobre la base

del manejo de buenas prácticas para trabajar en equipo, y por ello consta de

varios elementos organizacionales, documentales, etc.

Las actividades globales deben realizarse en un cierto intervalo de tiempo,

durante el cual se realizan algunos documentos y el desarrollo propio del trabajo

de implementación. También existen ciertas reuniones especiales de SCRUM

enfocadas a mejorar la productividad del equipo de trabajo haciendo de hitos de

éste para controlar y/o corregir el desarrollo del mismo de acuerdo a lo planeado.

Figura 6 Metodología SCRUM


Para poder realizar una mejor gestión con esta metodología se plantea

utilizar una herramienta de manejo de proyectos llamada Tuleap. Este software,

que es de código abierto, tiene gran versatilidad de características propias de la

metodología SCRUM como la documentación, la planeación de los sprints, entre

otras. Este proyecto requiere indudablemente de un seguimiento que sea fácil de

llevar debido a su tiempo de realización y al trabajo en sí que se pretende hacer, y

Tuleap facilita esto al tener acciones “drag and drop”.

Este es un software que incluso grandes compañías utilizan y que está

a disposición para una cantidad ilimitada de usuarios, proyectos y tiempo.

Tuleap permitirá que el proyecto en sí pueda ser resuelto con la cantidad

mínima de errores teniendo una excelente planeación, detallada hasta en lo

más pequeño, con una buena documentación plasmada en los diferentes

backlogs y con una carga de trabajo acorde al ritmo del equipo.


CAPÍTULO 9. ANÁLISIS Y DISEÑO

Dando inicio al proyecto se plantea la necesidad de migrar la parte

precontractual que opera en Si C@pital a nuevas tecnologías. Se definió lo que

el motor de base de datos para utilizar sería PostgreSQL y para el desarrollo se

utilizaría AngularJs y Beego como herramientas generales.

Primero se documentó sobre el proceso de la Universidad en los

aspectos contractuales como se detalló en el Marco Teórico para conocer el

negocio y a que estaba orientado. Al conocer la herramienta Si C@pital se

analizó la base de datos sobre la que estaba soportada. La base de datos está

sobre Oracle y sus entidades no están normalizadas debidamente, hay

información que se repite en muchas entidades muchas veces por tener llaves

compuestas de 7 atributos o más en las que se hacen redundantes. Los

modelos también eran muy difíciles de entender debido a que los nombres de

los atributos estaban cortados y no tenían una documentación como es debido.

También hay que agregar que había muchos atributos o incluso entidades que

no se sabía su propósito y/o no eran utilizados de ninguna manera.

9.1 MODELO DE DATOS

Con las premisas anteriores se llevó a cabo un análisis y se tuvieron varios

modelos de datos que con ayuda de reiteradas revisiones con ayuda de los DBA


y arquitectos de software de la Oficina Asesora de Sistemas se logró llegar a

uno definitivo que respetaba los estándares OAS que son:

• Nombres de atributos y tablas completos.

• Llaves foráneas solo desde el mismo esquema ya que se van a

utilizar apis y servicios diferentes para la comunicación entre

esquemas de la misma base de datos.

• Atributos que representan las llaves foráneas deben llevar el

nombre de la tabla referenciada.

• Todas las columnas, relaciones y entidades deben ser

debidamente documentadas.

• Las llaves primarias deben llamarse “id” y deben ser de

tipo integer o serial.

La herramienta que se utilizó para la creación del modelo de

datos precontractual fue pgmodeler.


Figura 7 Modelo de datos precontractual. Fuente: propia


Como se puede ver en la Figura 6 se tiene un modelo de datos nuevo

llamado administrativa, esto debido a que este pertenece al sistema Argo y a

su vez el sistema Argo pertenece al área administrativa de la Oficina Asesora

de Sistemas.

El modelo consta de 16 entidades en total, de las cuáles hay una central

llamada necesidad en la que se guardarán los atributos más importantes de

una solicitud de necesidad y una necesidad ya establecida.

En el atributo necesidad se tiene un id único como lo indica el estándar

OAS, una vigencia la cual es el año en curso e identifica las necesidades que

se hagan en dicho periodo. Esta tabla tiene en total 2 consecutivos que

funcionan de la siguiente manera:

numero_elaboracion: Es un consecutivo el cual es único según la

vigencia y corresponde al consecutivo de la solicitud de

necesidad, es asignado con la creación de una nueva necesidad.

numero: Es el número consecutivo de la necesidad ya aprobada,

al crearse la necesidad este atributo será de valor nulo y se le

asignará valor una vez se apruebe por parte del ordenador del

gasto determinado. También es un consecutivo único de acuerdo

a la vigencia.

La entidad necesidad también cuenta con atributos como la fecha

de solicitud, el objeto contractual, justificación y demás.

Cómo se puede ver en el modelo de datos se tienen entidades destinadas

para la gestión de la información de marcos legales, actividades económicas,


dependencias solicitantes y destino, especificaciones técnicas, actividades

específicas y demás.

Algo en lo que se hizo gran énfasis fue en la parte financiera que es una

carencia del sistema Si C@pital, en este modelo de datos se gestiona esta parte

mayormente con la entidad fuente_financiacion_rubro_necesidad en la que se

puede almacenar información de las apropiaciones elegidas en una necesidad, las

fuentes de financiamiento y los valores particulares para cada una solicitados.

En el modelo se evidencia la falta de foráneas entre esquemas como se

indica en el estándar de la Oficina Asesora de Sistemas pero se muestran las

entidades que se van a vincular de los demás esquemas por medio de

servicios, los esquemas a los que se vincularán son: financiera (Esquema del

sistema Kronos), Core (Esquema central con entidades transversales a todos

los sistemas), Agora (Esquema del sistema de registro único de personas),

Arka (Sistema de inventarios de la Universidad Distrital).

9.2 BPMN

El diagrama de procesos se realizó con las herramientas del toolkit de WSO2.

En este diagrama de procesos se llevó a cabo un análisis y se identificaron 2

actores (roles): El jefe de dependencia y el ordenador del gasto, aunque se

debe tener en cuenta que los jefes de dependencia también son jefes de

dependencia así que ellos pueden cumplir con los 2 roles dentro del sistema.


Figura 8 Diagrama BPMN Precontractual. Fuente: Propia


Cómo se puede ver en el diagrama BPMN el proceso consta de 2

actores, un jefe de dependencia encargado de crear la necesidad y un

ordenador del gasto al cual se le asigna para calificación de dicha necesidad, la

elección del ordenador del gasto se hace dependiendo de las apropiaciones

que se solicitan en la necesidad.

El ordenador del gasto es el encargado de que una vez esté calificada la

necesidad y haya sido aprobada solicita el Certificado de Disponibilidad

Presupuestal (CDP) del cual se ve como en el diagrama como luego de esto se

pasa a un subproceso de expedición de CDP que se efectuará en el sistema

financiero (Kronos) continuando así con todo el proceso contractual. Cómo

caso alternativo si el ordenador del gasto decide rechazar la solicitud de

necesidad debe dar una justificación del porqué).

9.3 ARQUITECTURA DE INFORMACIÓN

La arquitectura de información se realizó con la herramienta Archimate.

Así como en el modelo de datos y el diagrama de procesos de negocio

se modeló el sistema precontractual incluyendo tanto la parte de gestión de la

necesidad como de la solicitud de Certificados de Disponibilidad Presupuestal.


Figura 9 Arquitectura de la Información. Fuente: Propia

La arquitectura de la información para este proyecto consta de una entidad

general que es la necesidad pero para obtener la información de dicha necesidad

se deben tener unos datos claves así como diligenciar un formulario capaz de

soportar dicha información en el modelo de datos ya mostrado. La información que

se toma de otras entidades y que es vital para la creación de una necesidad son

las correspondientes a los centros de costos (parte que no se realiza en el

desarrollo debido a que aún está este submódulo en análisis), las actividades

económicas de los contratistas, la unidad ejecutora (Rector o convenios

dependiendo de las dependencias solicitantes y destino), las fuentes de

financiamiento y los rubros y/o apropiaciones los cuales los proveen servicios del

sistema financiero. También es parte importante la información proveniente de las

dependencias ya que dependiendo la dependencia solicitante y destino se

cambiarán las opciones del rol, las apropiaciones disponibles, etc.


Así mismo una solicitud de certificado de disponibilidad presupuestal se

asocia directamente a la necesidad ya que de allí proviene de la información

correspondiente y se tiene un formulario como base para obtener la

información que no le provee la necesidad directamente.

La relación entre ellas es de uno a muchos debido a que una solicitud de

CDP proviene siempre de una única necesidad pero las necesidades si pueden

tener una o varias solicitudes de Certificado de Disponibilidad presupuestal al

mismo tiempo.


CAPÍTULO 10. DESARROLLO

La parte de desarrollo consta de la parte front-end en el cuál se

encuentra todo el desarrollo del cliente y la parte back-end en la cual se

encuentra el api del proyecto.

10.1 BACK-END

La parte del back-end del proyecto como ya se menciona corresponde al

api que provee los servicios de CRUD sobre el modelo de datos desarrollado. El

api llamado administrativa_api_crud se ha generado con el framework Beego.

El api se compone básicamente de modelos y controladores, los

modelos contienen los atributos de las entidades en la base de datos y los

controladores definen los métodos CRUD sobre estos modelos como son: GET

(SELECT WHERE), GET ALL (SELECT), POST (INSERT), PUT (UPDATE) y

DELETE (DROP/DELETE).

Para hacer el guardado de información de la necesidad debido a la

complejidad fue necesario crear una transacción la cual se va a encargar de hacer

el guardado en todas las tablas que corresponda. Es importante que sea una

transacción ya que si se hiciera utilizando los post (INSERTS) de cada modelo al

momento de que haya un error solo se detendrá la inserción en la tabla que se

generen dificultades pero no en las demás provocando inconsistencias en la

información y problemas a nivel de aplicación y modelo. La transacción se


encarga de manejar estas referencias foráneas a partir de id generados ya sea

por un row (consulta interna sql en el modelo de la transacción) o haciendo uso

de los nextval y/o secuencias de la base de datos con el parámetro “auto” en

los modelos pero lo más importante es el manejo que se le da ya que al

encontrar cualquier error la transacción se encarga del rollback completo y

retorna el error específico que ha ocurrido haciendo más fácil su corrección.

Figura 10 Transacción 1. Fuente: Propia



Cómo se puede ver para definir esta transacción se debe primero crear

un modelo cuyos atributos son apuntadores a los demás modelos así se tiene

la referencia de estos y se puede hacer la inserción de datos a cada uno de

ellos, se deben definir como arreglos de apuntadores los atributos que van a

ser insertados masivamente por cada registro como las tablas de rompimiento

por ejemplo.


10.2 FRONT-END

La parte de cliente que consume los servicios proporcionados desde el

back-end se desarrolló completamente en AngularJs.

Para la solicitud de la necesidad a cargo del jefe de dependencia se

muestra el formulario en la Figura 14 el cual está dividido por diferentes

secciones las cuales se encuentran en las figuras:

Figura 15: Se muestra la sección de responsables, aquí se elige la

dependencia destino y el jefe dependencia destino ya que la dependencia

solicitante está en la información de la persona que se ha autenticado en el

sistema, el ordenador del gasto por el momento se va a elegir de entre los 10

posibles. En la parte superior se muestra la duración que brinda 3 opciones:

Duración (En la cual se pueden elegir los días, meses y/o años), único pago y

hasta agotar presupuesto (en la cual también es posible elegir días, meses y/o

años).

Figura 16: Se muestra la sección general, aquí se muestran varios

campos importantes para la necesidad como la unidad ejecutora, el estudio de

mercado, la modalidad de selección, etc.

Figura 17: Se muestra la sección de objeto contractual, en esta se debe

digitar el objeto de contrato y la justificación (los campos tendrán un límite de

800 y 600 caracteres respectivamente).


Figura 18: Se muestra la sección de marco legal, en esta se debe elegir

los acuerdos, actas, etc. que correspondan a la necesidad. (Es posible no

elegir ninguna si se desea).

Figura 19: Se muestra la sección de especificaciones, el formulario se

adapta de acuerdo al tipo de necesidad, si es de compra (Figura 19) o de

servicio (Figura 8). Aquí se ha elegido compras para observar la subsección de

compras en la cual se podrá elegir un subgrupo del catálogo y asociar todos los

datos correspondientes del elemento que se va a comprar como lo es la

descripción del elemento, el IVA, la cantidad, etc.

Figura 20: Se muestra la subsección de servicio en la cual se podrán

elegir datos como lo es el perfil del contratista o el SNIES, etc.

Figura 21: Se muestra la sección de financiamiento, aquí se puede

elegir el tipo de rubro (inversión y funcionamiento). Se muestra la subsección

de inversión, al elegir esta opción se muestran los rubros y apropiaciones

correspondientes y así al elegirlos se muestran las fuentes de financiamiento

asociadas a dicha apropiación pero que hayan sido asignadas a la

dependencia solicitante, una vez se elige una fuente de financiamiento se

puede digitar el valor que se va a solicitar de dicha fuente.

Figura 22: Se muestra la subsección de funcionamiento, al elegir esta

opción se muestran los rubros y apropiaciones correspondientes y por lo tanto

al elegirlos no tendrán fuentes de financiamiento asociadas por lo que se

desplegará la opción para solicitar cierto monto directamente de la apropiación

elegida.


Figura 14 Formulario completo solicitud necesidad. Fuente: Propia

Figura 15 Sección Responsables. Fuente: Propia

Figura 16 Sección General. Fuente: Propia


Figura 17 Sección Objeto Contractual. Fuente: Propia

Figura 18 Sección Marco Legal. Fuente: Propia

Figura 19 Sección Especificaciones Compras. Fuente: Propia


Figura 20 Sección Especificación Servicios. Fuente: Propia

Figura 21 Sección Financiación inversión. Fuente: Propia


Figura 22 Sección Financiación Funcionamiento. Fuente: Propia

En la Figura 23 se puede ver la siguiente vista, es usada por el

ordenador del gasto, en esta puede ver las necesidades que tiene asociadas y

las cuales muestran su estado actual, así como detalles correspondientes a su

consecutivo de elaboración o el objeto. Los estados son:

Solicitada: Cuando una necesidad ha sido solicitada y está

esperando ser calificada por el ordenador del gasto.

Aprobada: Cuando el ordenador del gasto ha aprobado una

necesidad que se encontraba en estado Solicitada.

Rechazada: Cuando el ordenador del gasto ha rechazado una

necesidad que se encontraba en estado Solicitada y ha escrito

una justificación de este rechazo.

Cdp_Solicitado: Cuando el ordenador del gasto ha hecho la

solicitud de Certificado de Disponibilidad Presupuestal a partir de

una necesidad que se encontraba en estado Aprobada.


Figura 23 Gestión de Necesidades. Fuente: Propia

En la figura 24 se puede observar el detalle de la necesidad, se puede acceder

allí al abrir una necesidad con la opción ver (Figura 23), aquí se puede apreciar

información relevante de la necesidad en cuestión.

Figura 24 Detalles Necesidad. Fuente: Propia


Al final del detalle se pueden ver varias opciones dependiendo del

estado actual de la necesidad (Figura 25). Si la necesidad está en estado:

Solicitada: Las opciones serán aprobar y rechazar.

Aprobada: Tendrá una única opción que es Solicitar CDP

Rechazada: No tendrá acción disponible debido a que se ha rechazado

la necesidad.

Cdp_Solicitado: No tendrá acción alguna ya que se ha creado una

solicitud de disponibilidad.

Figura 25 Aprobación Necesidad. Fuente: Propia


CAPÍTULO 11. RESULTADOS

Como resultado del proyecto se obtuvo un análisis detallado de la parte

pre-contractual del sistema Argo planteando una arquitectura de servicios,

análisis de los procesos que se manejan y un modelo de datos robusto capaz

de soportar la gestión de estos módulos.

Se muestra el resultado (%) frente a los objetivos específicos y las

actividades realizadas con respecto a estos:

Definir los requerimientos funcionales de los módulos de necesidades y Certificados de Disponibilidad Presupuestal (CDP) para identificar su prioridad en el desarrollo, a qué módulos se asocian

cada uno, entre otros.

(100%): Se definieron los requerimientos y se hizo un análisis frente al

sistema y modelo de datos ya existentes.

Realizar el diseño correspondiente de las funcionalidades requeridas para visualizar el

comportamiento del sistema y el traslado de información en el mismo.

(100%): Se diseñó y desarrolló una arquitectura de información y se

analizó el proceso y se desarrolló un diagrama consistente de procesos.

Crear un modelo de datos completo de los módulos de necesidades y Certificados deDisponibilidad Presupuestal (CDP) para construir una base de datos que asegure la integridadde la

información.

(100%): Se crea una modelo de datos “administrativa” de la base de datos

de la Oficina Asesora de Sistemas y se diseña y crea un modelo de datos robusto

el cuál soporta tanto el módulo de necesidades como el de solicitud de CDP.


Brindar los servicios CRUD correspondientes del modelo propuesto a partir de un api para que la

información sea transversal en los sistemas relacionados de la Oficina Asesora de Sistemas.

(100%): Se creó, desarrolló y desplegó un api CRUD del modelo

desarrollado llamado “administrativa_crud_api” que cumple con las funciones

necesarias para el funcionamiento de los módulos desarrollados en este

proyecto y proveen los servicios sobre los modelos a los demás sistemas que

deseen consumirlos.

Desarrollar los módulos concernientes a las necesidades y las solicitudes de Certificados de Disponibilidad Presupuestal (CDP) de acuerdo al diseño planteado para poder integrar la gestión pre-

contractual en el sistema ARGO.

(100%): Se desarrolló el cliente de la parte precontractual de Argo que

junto con el api cumplen con las funciones esperadas del módulo de

necesidades y solicitud de certificados de disponibilidad presupuestal.


CAPÍTULO 11. TRABAJOS FUTUROS

Este proyecto abre la posibilidad a nuevos proyectos y/o mejoras del

sistema Argo (Sistema contractual y compras):

Vincular las necesidades con el sistema Titán pudiendo

generar así necesidades para pagos de nómina y demás.

Vincular las necesidades a las novedades post-

contractuales tales como generación de otros sí.

Agregar toda la parte de autenticación única con WSO2 y manejo

de código de errores que actualmente se está desarrollando en la

Oficina Asesora de Sistemas.

Vincular con el Plan Anual de Adquisiciones de la

Universidad Distrital.

Vincular con los centros de costos y las actividades de los centros

de costos y permitir que el resto del ERP pueda consultarlas

desde los servicios de administrativa_crud_api.


CAPÍTULO 12. CONCLUSIONES

Ya que se utilizó la metodología SCRUM se hizo un seguimiento de todo

el proyecto muy de cerca por los DBA y Arquitectos de la Oficina Asesora de

Sistemas, además se hizo la revisión de avances con los Scrum masters y

algunos usuarios permitiendo que se generaran correcciones y se afinara el

proceso teniendo en cuenta las indicaciones de estos.

El desarrollo de estos módulos de la parte pre-contractual del sistema

Argo permite que se pueda vincular esta información a la del resto del ERP

como lo es toda la parte financiera de expedición de CDP, RP, órdenes de

pago, etc. Con lo anterior se corrige un grave problema que presenta Si

C@pital en cuanto a la información que maneja el sistema.

Como conclusión personal pude observar nuevas tecnologías muy

interesantes que permiten realizar tareas de forma más fácil e intuitiva con las

ventajas que se ofrecen como la comunicación bidireccional de AngularJS o los

servicios que se proveen a partir del framework Beego. Además se obtuvo la

experiencia del desarrollo de una aplicación compleja en el ámbito empresarial.


CAPÍTULO 13. BIBLIOGRAFÍA

[1] Consejo Superior Universitario, “Estatuto General de la Universidad,”

Universidad Distrital Francisco José de Caldas, 2007. [En línea].

Disponible en:

http://acreditacion.udistrital.edu.co/resoluciones/estatuto_general_actuali

zado.pdf

[2] “Qué es PostgreSQL y cuáles son sus ventajas”. [En línea]. Disponible

en: https://platzi.com/blog/que-es-postgresql/

[3] “ACID en las bases de datos” - Dos Ideas. [En línea]. Disponible en:

http://www.dosideas.com/noticias/base-de-datos/973-acid-en-las-

bases-de-datos.html

[4] “¿Qué es PostgreSQL?” | Microbuffer. [En línea]. Disponible en:

https://microbuffer.wordpress.com/2011/05/04/que-es-postgresql/

[5] “PostgreSQL: Características, limitaciones y ventajas”. [En línea].

Disponible en: http://postgresql-dbms.blogspot.com.co/p/limitaciones-

puntos-de-recuperacion.html

[6] “Que es Git/GitHub?” | /DEV/Blog. [En línea]. Disponible en:

https://barradevblog.wordpress.com/2013/01/21/que-es-gitgithub/

[7] “Introducción a Git y GitHub”. [En línea]. Disponible en:

http://www.desarrolloweb.com/articulos/introduccion-git-github.html

[8] “Servicios Web”. [En línea]. Disponible en:

http://www.hipertexto.info/documentos/serv_web.htm


[9] “Web Services, un ejemplo práctico”. [En línea]. Disponible

en: https://msdn.microsoft.com/es-es/library/bb972248.aspx

[10] “Guía Breve de Servicios Web”. [En línea]. Disponible en:

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

[11] “Web Services”. [En línea]. Disponible en:

http://library.gxtechnical.com/gxdlsp/pub/genexus/internet/technicalpaper

s/web_services.htm

[12] “Qué es AngularJs”, Basalo Alberto y Álvarez Miguel Angel. [En

línea]. Disponible en: https://desarrolloweb.com/articulos/que-es-

angularjs-descripcion-framework-javascript-conceptos.html

[13] “Go: Building new applications with Beego”, Setter Matthew. [En

línea]. Disponible en: https://www.sitepoint.com/go-building-web-

applications-beego/

[14] “What is Beego?” | Beggo.me. [En línea]. Disponible en:

https://beego.me/docs/intro/

[15] IDEXUD. [En línea]. Disponible en:

http://idexud.udistrital.edu.co/idexud/art_idexud.php?HrG=C

[16] “Islavisual.com - Diferencias Entre Scrum Y Xp.” [En línea].

Disponible en:

http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-

scrum-y-xp.php


CAPÍTULO 14: ANEXOS

Los siguientes anexos se encuentran en el CD adjunto a este documento:

Documento final en formato

digital. Códigos API y Cliente.

Diagrama BPMN.

Modelo de datos.

Arquitectura de la información.


argo (sistema contractual y compras) autor:...

Documents