INFORME DE AVANCE

Desarrollo del Sistema de préstamo y recepción de equipos para los

laboratorios de la universidad Santo Tomás

PRESENTADO A:
UNIDAD DE INVESTIGACIÓN
UNIVERSIDAD SANTO TOMÁS

ELABORADO POR:
DARIO ALEJANDRO SEGURA TORRES

Bogotá, D.C.
Colombia
2017

1
 1. INFORMACIÓN GENERAL DE PROYECTO

Supervisor:
Carlos Enrique
Supervisor/ Director Montenegro
Código Interno N/A Centro de Narváez
Investigación Centro de costos:
Recursos de
Facultad
Nombre del proyecto Fecha de inicio del 16/10/2016
de investigación proyecto.
Nombre del Fecha de finalización 30/11/2017
Dario Alejandro Segura
Investigador principal del proyecto.
Fecha de 09/08/2017
Nombre de los co-
presentación del
investigadores
informe de avance.
Nombre de los
auxiliares de
investigación Ninguno
/estudiantes de
semillero vinculados
Grupo de Ingeniería
Modelado, Electrónica y
Investigación/Semiller Unidad académica Electrónica
Monitoreo (MEM)
o
Nombre de la línea de Porcentaje estimado 69%
Automática
investigación de avance

2
 2. CONTENIDO

2.1 Título
Desarrollo del Sistema de préstamo y recepción de equipos para los laboratorios de
la universidad Santo Tomás.

2.2 Resumen del proyecto en general

Hasta antes del inicio de este proyecto existía en la Universidad Santo Tomás un
sistema que soportaba el proceso de préstamo y recepción de equipos dentro de los
laboratorios ETM, este sistema es conocido como LabManager. El sistema fue
desarrollado e implementado en 2002, hace casi ya 14 años, y al rededor del proceso
de préstamo y recepción de equipos se generaron nuevos requerimientos que el
sistema LabManager del 2002 ya no podía cumplir, además de presentar problemas
de compatibilidad con los sistemas operativos actuales. Por ello fué necesario
actualizar este sistema de apoyo y reemplazar el LabManager, de allí la necesidad de
implementar un nuevo sistema, LabManager II, el cual es un sistema que emplea
tecnologías actuales y cumple los nuevos requerimientos que han surgido alrededor
de este proceso de préstamo y recepción.

2.3 Palabras clave del proyecto en general

 Automatización
 Sistemas de prestamos
 Metodologías de desarrollo
 Microsof Solution Framework
 MSF
 .NET
 Arquitectura de software

2.4 Problema de investigación

El proyecto planteado es un desarrollo e implementación que busca solucionar una
problemática actual de una empresa, en este caso de la propia Universidad Santo
Tomás, el problema gira en torno a la automatización del proceso de préstamo y
recepción de equipos en los laboratorios ETM de la Universidad Santo Tomas,
dicho proceso es soportado por un sistema informático que debe ser actualizado por
presentar falencias ante los requerimientos actuales de los usuarios, como se explica
a continuación.
3
El sistema existente, que estaba en funcionamiento desde el año 2002, al iniciar el
proyecto, es llamado LabManager I, es un sistema con una arquitectura simple que
está conformada por dos componentes: una aplicación y una base de datos. La
aplicación estaba diseñada para correr sobre sistemas operativos Windows 95, y la
base de datos estaba soportada por un motor de bases de datos Microsoft Access
(MDB).

La base de datos Microsoft Access tiene como limitación hasta 2GB de espacio en
disco para información [1], esta limitación más un diseño de datos deficiente, genera
que el sistema LabManager I, no pueda almacenar información de préstamos y
estudiantes por más de 2 años consecutivos, por ello la información de los estudiantes
debe ser eliminada totalmente de la base de datos cada semestre, lo cual se tornó un
proceso adicional para los usuarios de este sistema. El problema no se limita a la
información de los estudiantes sino al uso de equipos y responsabilidades como las
multas que a los estudiantes se les generan, toda esta información se elimina en este
sistema semestre a semestre. Eliminar esta información evita poder generar
estadísticas de uso por parte de los administrativos de los laboratorios y llevar un
control sobre el manejo de las multas. Para poder incrementar el tiempo de
almacenamiento de información es necesario cambiar el motor de base de datos por
uno que permita almacenar mayor cantidad de datos y por un mejor diseño del modelo
de datos, un cambio de este tipo no lo soporta la aplicación actual.

Además, por ser una aplicación de escritorio, LabManager I, debe ser instalada en los
equipos de las personas que quieren tener acceso a la información, y esta aplicación
ya presenta problemas de compatibilidad con sistemas operativos Windows Vista y
posteriores como lo reportaron los usuarios. Este punto refuerza el hecho de que la la
aplicación debe ser actualizada.

Al instalar la aplicación en diferentes equipos, esta aplicación necesita la información

de acceso a la base de datos, permitiendo que cualquier persona pueda entrar a la base
de datos y modificar la información y estructura de la misma sin control alguno.
Existen iniciativas de las directivas de los laboratorios, como lo son la verificación
de los equipos a cargo que tiene un estudiante, la reserva de equipos en línea, la
sincronización de información entre el sistema académico SAC, y en el sistema
LabManager I no pueden ser implementadas, ya que cualquier integración implica
conocer la contraseña de acceso a la base de datos. Los casos anteriores son un
problema de seguridad y escalabilidad que deben ser resueltos.

Por los motivos anteriores se debe crear un sistema de información que permita el
almacenamiento de datos de estudiantes, equipos y transacciones de préstamo y
4
 recepción, y garantice la seguridad de la información permitiendo que éste pueda ser
escalable a futuro, entonces el problema de investigación es crear un sistema de
información que soporte el proceso de préstamo y recepción de equipos, manteniendo
las características que el proceso requiere: un sistema rápido y eficiente en la atención
al público y de alta disponibilidad de la información para la toma de decisiones por
parte de los interesados.

2.5 Pregunta de investigación

Alrededor de este objeto de estudio específico y de este problema de investigación,
surge la siguiente pregunta de investigación:

¿Qué solución real y funcional satisface las necesidades del proceso del préstamo de
equipos de la Universidad Santo Tomás sede central que posea los elementos y
servicios de un sistema de información flexible, seguro y escalable?

2.6 Objetivos de investigación con ajustes pertinentes.

A continuación se describe el objetivo general y específico del trabajo que se viene

desarrollando:

 Objetivo General
Diseñar y desarrollar un sistema de préstamo y recepción de equipos que sea escalable
y permita un acceso seguro a la información para que cumpla con los requerimientos
actuales de los laboratorios ETM de la Universidad Santo Tomás sede central.

 Objetivos Específicos
o Seleccionar la metodología de desarrollo a utilizar para generar las
políticas y lineamientos del desarrollo de software y del equipo de
trabajo.
o Identificar los módulos básicos del nuevo sistema para crear la
arquitectura del mismo.
o Realizar el levantamiento de requerimientos para que sirvan como
referencia en el desarrollo del sistema.
o Lograr el aval, por parte del cliente, de los requerimientos levantados
para que sean reconocidos como referencia de funcionamiento del
sistema.

5
 o Desarrollar las aplicaciones necesarias que cumplan con los
requerimientos avalados por el cliente, es decir la administración de
los laboratorios.
o Realizar las pruebas necesarias para afinar las aplicaciones
desarrolladas.
o Lograr el aval del cliente para las aplicaciones desarrolladas.
o Entregar un sistema estable que cumpla con las expectativas del
cliente para demostrar la capacidad de la Facultad de Ingeniería
Electrónica como proveedor interno de desarrollo de software en la
Universidad.

2.7 Resultados Obtenidos

Actualmente el sistema cuenta con el 81% de las funcionalidades desarrolladas e
implementadas. El sistema está en funcionamiento desde el mes de abril del 2017 y
está soportando el proceso de préstamo y recepción de equipos en los laboratorios
ETM de la Universidad Santo Tomás, el sistema presenta un funcionamiento estable
y ya se ha iniciado la etapa de aceptación de requerimientos. Resultado del desarrollo
de este sistema se han realizado hasta el momento dos registros de software.

2.8 Metodología utilizada

La metodología de desarrollo empleada para el proyecto es una adecuación del
framework Microsoft Solution Framework (MSF) [1], el cual presenta la flexibilidad
de poderse adecuar a un proyecto de desarrollo como el desarrollo de , en especial a
las características de poseer un equipo de trabajo reducido y de dedicación inferior al
tiempo completo, ya que las demás metodologías como RUP, XP o SCRUM,
contemplan muchos roles específicos con alta dedicación al proyecto lo cual hace
inaplicables al caso de este proyecto de desarrollo.
Para el caso específico se mantienen los tres componentes principales de MSF
(Ilustración 1): Principios, Modelos y Disciplinas.

6
 Ilustración 1. Componentes de MSF

El componente de Principios especifica valores y estándares que serán comunes a todos los
elementos del framework y por lo tanto de a los involucrados.
El componente de modelos define la conformación, roles, responsabilidades e interacción
de cada uno de los miembros del equipo de trabajo y flujo y etapas del proceso de
desarrollo como tal.
El componente de Disciplinas especifica cómo se administran los procesos que intervienen
dentro del desarrollo.
Cada uno de estos componentes es adaptado a las necesidades y características del
proyecto, quedando cada uno de ellos descrito en los siguientes capítulos.

Principios
Los principios que se aplican a la metodología de desarrollo para el proyecto son:
 Comunicación abierta: Cada miembro del equipo posee conocimientos e información
que portan al proceso estos conocimientos deben ser difundidos y compartidos dentro
del equipo de manera abierta para que los demás miembros del equipo puedan tomar
decisiones acertadas que lleven al buen manejo del proyecto y a la entrega de un
sistema que entregue valor agregado al proceso a automatizar, en este caso el
préstamo y recepción de equipos.
 Visión compartida: Todos los miembros del equipo deben entender los objetivos
principales del sistema y sus ventajas, estos objetivos deben ser comunes y
compartidos. Cada uno de los miembros del equipo y de los interesados deben
entender las ventajas de la actualización del sistema y de la necesidad de su uso.
 Responsabilidad compartida: Cada uno de los miembros del equipo es responsable
del producto final, desde la definición de requerimientos que debe ser hecha de
manera responsable, pasando por la administración del proyecto y el desarrollo del
mismo. Un error dentro del proceso de desarrollo involucra a todas las partes. Pero si
la aceptación de las tareas y el desarrollo de las mismas, es tomado con

7
 responsabilidad cualquier dificultad es responsabilidad de todos y cualquier logro
también lo es. Todos los involucrados deben estar convencidos de su papel dentro del
desarrollo del proyecto y tener claras sus responsabilidades, cada miembro debe estar
atento a portar dentro del desarrollo de manera constructiva. No deben existir dentro
del equipo personas o roles cuyo aporte sea negativo al proceso de desarrollo.
 Generar valor de negocio: El valor de negocio es toda funcionalidad que representa
una mejora en el proceso, y en las actividades que de este proceso se desprenden. Si
una actividad, un requerimiento, o cualquier otro tipo de actividad no aporta a un
valor de negocio debe ser evaluado en cuanto a pertinencia y necesidad, si no aporta
un valor de negocio debe ser descartado dicho requerimiento o actividad.
 Mantenerse ágil y dispuesto al cambio: Ser conscientes de que existen cambios que
pueden afectar los tiempos programados es una fortaleza que permite la rápida
reacción y priorización de tareas, lo que lleva a que un proyecto sea exitoso. Se debe
estar dispuesto al cambio de requerimientos y la aparición de nuevos, la
administración del proyecto y los diseños deben estar orientados a ser flexibles ante
estos cambios, para que cuando aparezcan el impacto en tiempo sea el mínimo.
Modelos
La metodología propuesta implementa dos modelos: El modelo del equipo y el modelo del
proceso.
Modelos del equipo
El modelo del equipo de trabajo para el caso del proyecto está conformado por tres roles:
Desarrollador, usuario experto y Gestor, todos alrededor de una comunicación abierta y
unas metas (funciones y responsabilidades) claras en el proyecto.

Ilustración 2. Modelo de equipo

Metas del equipo de trabajo Transversal a todos los roles

Todos los integrantes del equipo sin importar su rol deben:
• Cumplir con los principios de la metodología planteada.
• Actuar en pro del proyecto.
8
 • Mantener la actitud ética.
• Mantener comunicación con los integrantes del equipo.
• Reportar errores.
• Reportar mejoras.
• Alertar riesgos detectados.
Desarrollador
Quien tome el rol de desarrollador debe estar en capacidad de:
• Levantar requerimientos.
• Programar las aplicaciones que el sistema necesite.
• Entregar un producto de acuerdo a las especificaciones de los requerimientos.
• Desplegar, instalar y poner en marcha las aplicaciones del sistema.
• Solicitar recursos a tiempo.
• Manejo de proyecto y riesgo.
Usuario experimentado
Quien tome el rol de usuario experimentado debe estar en capacidad de:
• Aportar el conocimiento del proceso en el levantamiento de requerimientos.
• Realizar las pruebas de las funcionalidades que a su rol correspondan a conciencia.
• Solicitar los recursos necesarios para la realización de las pruebas.

Gestor
Quien tome el rol de gestor debe estar en capacidad de:
• Aportar el conocimiento del proceso en el levantamiento de requerimientos.
• Gestionar los recursos necesarios.
• Velar por el correcto uso de los recursos.
• Realizar las pruebas de las funcionalidades que a su rol correspondan a conciencia.
• Fomentar el uso del sistema.
• Manejo de proyecto y riesgo.

Modelo del proceso

El proceso de desarrollo consta de 7 pasos que se muestran en la Ilustración 3, este
proceso se lleva a cabo para cada una de las funcionalidades que se van a desarrollar.

9
 Ilustración 3. Modelo del proceso

Requerimientos
En este paso del proceso se realiza la documentación y especificación de los
requerimientos funcionales del sistema por medio de casos de uso, un caso de uso es
una técnica para identificar el tipo de acción entre el sistema y los actores
involucrados [2]. Estas interacciones se plasman en un documento de casos de uso.
Este proceso lo realiza el desarrollador en conjunto con el usuario experto, donde se
realiza una explicación de cada uno de los procesos o casos de uso identificados. El
producto de este paso es el formato de caso de uso diligenciado, el cual se envía a los
miembros del equipo para sus comentarios y afinamiento.
Aceptación de requerimientos
Este paso es en el cual el usuario experto acepta el procedimiento descrito en el caso
de uso, el usuario experto avala que la información y el proceso descrito en el formato
del caso de uso corresponden a la realidad, y cumple las necesidades del negocio. El
producto de este proceso es el caso de uso firmado por el usuario experto dando su
aval sobre lo consignado allí.
Diseño
En este paso, el desarrollador, realiza el diseño de la aplicación, antes de codificar es
necesario una planeación del código que se va a generar y el modelo de datos que
soporta la solución del requerimiento. El producto en este paso del proceso es el
diagrama de clases y modelo entidad relación. Estos dos productos son el insumo para
el desarrollo.
Desarrollo
Esta etapa es en la cual se codifica la aplicación y se obtiene como resultado el
programa ejecutable o una librería en su defecto. La aplicación resultante debe
cumplir con las funcionalidades descritas en los requerimientos. En este paso es
donde se genera el producto.
10
Despliegue a pruebas
Es la instalación y/o actualización del sistema para que pueda ser usado por los
usuarios expertos, para que ellos puedan hacer uso del sistema y realizar las pruebas
que ellos consideren necesarias. El producto esperado es el sistema actualizado con
la funcionalidad. Esta etapa está a cargo del desarrollador.
Pruebas y estabilización
En esta etapa el usuario experto debe realizar las pruebas necesarias para verificar
que el sistema cumple con los requerimientos especificados y aprobados. Si el sistema
no cumple con los requerimientos se genera un reporte de error (bug), el cual es
reportado al desarrollador, el cual debe dar solución al error y desplegarlo, el
desarrollador informa que el sistema se encuentra actualizado para que el usuario
experto pueda validar la solución del problema. En caso de que se identifique un error
en el proceso descrito por el requerimiento, el requerimiento debe ser ajustado
regresando al paso de levantamiento de requerimientos. El producto de esta etapa es
la aplicación estabilizada.
Aceptación de la funcionalidad
En este paso del proceso se da el aval de los usuarios expertos sobre el producto
funcionando, sobre la aplicación. El producto de este paso es el caso de uso firmado
por los usuarios expertos, esta firma indica que el usuario experto avala la
funcionalidad del sistema y se encuentra satisfecho con el funcionamiento.
Disciplinas
Para la metodología de desarrollo se adoptan dos disciplinas: Manejo del proyecto y
Manejo del riesgo.
Manejo del proyecto
Se entiende como manejo del proyecto para este proyecto lo tratado en el capítulo 5.2
de [2]. El área de gestión y manejo de proyectos es muy extensa y no se pretende
abarcar la descripción de la misma. El proyecto tiene la característica de ser un
proyecto pequeño, por lo cual se propone para este proyecto solo la aplicación de
algunas de las técnicas de gestión y seguimiento. Los hitos del proyecto van a estar
dictados por los casos de uso previos que se han levantado.

Cada funcionalidad será aceptada por los usuarios expertos por medio de un
documento de aceptación. El seguimiento de los avances se realizará por parte de
Desarrollo empleando la herramienta Team Foundation Service (TFS), en la cual se
registrarán los casos de uso y su estado. De esta manera los interesados pueden ver el
estado actual (avance) del desarrollo, con el fin de realizar un seguimiento continuo
no presencial. Cada tres meses se genera por parte de Desarrollo un reporte con las
novedades presentadas durante el mes de dicho reporte. Para la entrega final del
sistema y aceptación del mismo: El objetivo es recibir la aceptación oficial del sistema
diseñado inicialmente.

11
Manejo del riesgo
Se entiende como riesgo y manejo del riesgo para este proyecto lo tratado en el
capítulo 5.4 de [2]. Entendiendo por riesgo toda realizada que pueda afectar el curso
normal del proyecto, ya sea retrasarlo o detenerlo por completo. Aceptando 3 tipos
de riesgos: Riesgos del proyecto, estos riesgos consisten en aquellos que pueden
afectar el cronograma del proyecto, como la falta de recursos. El segundo tipo de
riesgos, son los riesgos que afectan el producto y su desempeño, por ejemplo, la
calidad de la comunicación entre un cliente y un servidor. El tercer tipo de riesgo, son
los riesgos del negocio, son los que afectan al productor del software, por ejemplo, la
aparición de un software que compita con las funcionalidades que se están
desarrollando. Por la naturaleza del proyecto los riesgos se estiman bajos, pero es
indispensable los involucrados estén atentos a las señales que estos dan antes de
presentarse, y avisar con inmediatez la aparición de estos.
Para el registro y seguimiento de los riesgos se adopta el formato de gestión de riesgos
sugerido en [3], el cual se adapta a las necesidades de la institución.
El proceso de gestión de riesgos esta mostrado en la Ilustración 4, en esta se observan
los pasos del proceso. A continuación, se describe cómo se van a manejar cada uno
de estos pasos del proceso.

Ilustración 4. Flujo del manejo del riesgo

Identificar
La identificación de los riesgos puede ser hecha por cualquiera de los miembros del
equipo, y debe ser consignada en el formato de gestión de riesgos por cualquiera de
los encargados. Para el registro del riesgo es necesario conocer: Si este va a ser
generado por una persona, por la creación, carencia o modificación de algún proceso,
por la aparición, eliminación, o modificación de alguna tecnología o por un factor
ambiental, es decir un factor alrededor del proyecto y que lo impacta, pero es externo
al proyecto. Cuál es el efecto o cuales van a ser los efectos que el riesgo implica al
proyecto, es decir afectará los costos requiriendo más presupuesto, va extender el
tiempo, va a presentar un riesgo de seguridad para el proyecto o dentro del sistema
final, o va a representar una disminución en el rendimiento del mismo.

12
 En este paso deben quedar diligenciadas las columnas: fuente del riesgo, efecto del
riesgo, condición del riesgo, y explicación.
Esto es responsabilidad de todo el equipo.
Analizar
En este punto se debe realizar la cuantificación del riesgo y sus consecuencias, se
debe avaluar que va a ocurrir si el riesgo llega a ser y como impactaría esto al proyecto
y/o al producto, al igual que estimar la probabilidad de que esto llegue a darse. En
este punto deben quedar diligenciadas las columnas: Consecuencias, probabilidad
inicial, impacto inicial y con ellas la columna exposición inicial, que será el factor
que indique la prioridad de un riesgo.
Esto es responsabilidad de los gestores y desarrolladores.
Planear
En esta etapa se deben generar estrategias para reducir el riesgo, estas estrategias se
entienden como actividades que deben realizarse dentro del equipo para disminuir la
probabilidad de que el riesgo se dé, estas son estrategias de mitigación. Por otro lado,
se deben plantear estrategias de contingencia, estas son actividades que se deben
realizar después de que el riesgo llega a ser, para poder disminuir el impacto nocivo
de este, para el proyecto. Además, se deben generar los indicativos para la medición
de los efectos negativos del riesgo dentro del proyecto, con el fin de evaluar si el nivel
de impacto o probabilidad ha cambiado. En este punto deben quedar diligenciadas las
columnas: mitigación, contingencia e indicativos. Esto es responsabilidad de los
gestores y desarrolladores.
Seguimiento y Control
Esta etapa consiste en la reunión periódica, verificación de los riesgos registrados y
la re-evaluación de cada uno de ellos con el fin de ajustar los indicadores de impacto
y probabilidad, ajustando el índice de exposición, y ajustar las actividades del equipo
de acuerdo a las nuevas necesidades y dadas por el índice de exposición. Esto es
responsabilidad de los gestores y desarrolladores.
Aprender
El aprendizaje es una tarea intelectual, para el caso de este proyecto las experiencias
de buenas prácticas pueden quedar consignadas en un documento que se puede
levantar al finalizar el proyecto. Esto es responsabilidad de todos los miembros del
equipo.

2.9 Actividades de formación a la fecha: describir actividades específicas de

formación en investigación para los estudiantes vinculados a los
proyectos de semilleros (requerido) y grupos (con auxiliares de
investigación).

13
 Inicialmente en el proyecto no interviene ningún tipo de recurso estudiantil, sin
embargo este logra contar con la colaboración de los siguientes estudiantes quienes
aportan como desarrolladores:
o María Carolina Bravo: Desarrollo de aplicación web. 2017-04-01 a 2017-05-
30.
o Miguel Jiménez: Desarrollo .NET. 2017-04-01 a la fecha.

2.10 Relación con el currículo: Describir posibles aportes del proyecto al

currículo los programas y unidades académicas a la fecha.
Este proyecto ha generado un espacio a estudiantes para que puedan practicar los
conocimientos adquiridos en asignaturas como: Programación I y Programación II,
adicionando un acercamiento a los procesos de desarrollo de software que lleva acabo
una empresa.

2.11 Avance alcanzado con respecto al cronograma inicial

El avance estimado del proyecto está en un 69%, existen retrasos respecto al

cronograma inicial ya que dentro del proceso se debieron atender requerimientos no
detectados en un inicio y que se acordó que eran indispensables para el desarrollo del
sistema, una explicación de esto se realiza en el capítulo 2.14. El avance reportado
hace referencia a las actividades desarrolladas y las que faltan por desarrollar. A
continuación se presenta una tabla con los porcentajes de avance de cada una de las
actividades programadas inicialmente y su porcentaje de avance.

Actividad Inicio Fin Avance

Levantamiento de requerimientos del sistema 10/10/2016 25/05/2017 68%
Generación de la arquitectura del sistema 10/11/2016 10/12/2016 100%
Implementación de la solución
100%
de software para el desarrollo del arquitectura 10/11/2016 26/12/2016
Desarrollo del sistema 21/02/2017 05/09/2017 81%
Pruebas internas del sistema 26/01/2017 12/04/2017 100%
Pruebas del sistema 13/04/2017 10/08/2017 81%
Evaluación de funcionalidades entregadas 13/04/2017 09/09/2017 38%
Corrección de fallos y detección de mejoras 26/01/2017 10/08/2017 80%
Manual de usuario 10/08/2017 09/09/2017 0%
Aceptación del sistema y oficialización de mejoras 09/09/2017 25/09/2017 38%
Avance general 69%

14
La fecha de inicio fue 10 de octubre de 2016, y el proyecto fue planeado para terminar en
2017-11-30, es decir un total de 13 meses, de los cuales hasta el 10 de agosto de 2017 han
trascurrido 10 meses es decir ha transcurrido un 77% del tiempo. A continuación se muestra
el diagrama de avances sin tener en cuenta los trabajos adicionales.

Cronograma

Aceptación del sistema y…

Manual de usuario
Corrección de fallos y…
Evaluación de…
Pruebas del sistema
Pruebas internas del sistema
Desarrollo del sistema
Implementación de la…
Generación de la…
Levantamiento de…
10/10/2016
25/10/2016
09/11/2016
24/11/2016
09/12/2016
24/12/2016
08/01/2017
23/01/2017
07/02/2017
22/02/2017
09/03/2017
24/03/2017
08/04/2017
23/04/2017
08/05/2017
23/05/2017
07/06/2017
22/06/2017
07/07/2017
22/07/2017
06/08/2017
21/08/2017
05/09/2017
20/09/2017
05/10/2017
2.12 20/10/2017
Logros generales de la investigación.

2.13 Tipo de productos derivados del avance parcial del proyecto:

movilidades (Código ORII), publicaciones (ISBN, aceptación artículo o
publicación), alianzas/redes establecidas (cartas de intención, convenios,
etc.), otro tipo de productos (evidencia y medio de verificación).

Tipo de producto Descripción Evidencia

Registro de software MODELO DE DATOS PARA LA Registro número:
ACTUALIZACIÓN DEL SISTEMA DE 13-61-394

15
 PRÉSTAMO Y RECEPCIÓN DE EQUIPOS
LABMANAGER
Registro de software SERVICIOS DEL SISTEMA DE PRÉSTAMO Registro número:
Y RECEPCIÓN DE EQUIPOS 13-61-395
LABMANAGER

2.14 Dificultades enfrentadas en la realización del proyecto

La principal dificultad del proyecto estuvo en la aparición de nuevas necesidades que
debieron ser atendidas, la principal de ellas es la necesidad de implementar las
funcionalidades de administración de información base en la aplicación de escritorio,
este hecho no estaba contemplado, ya que estas funcionalidades fueron diseñadas para
la aplicación web, pero el cliente, en este caso los laboratorios de la Universidad
Santo Tomás expresaron la necesidad de implementar las funcionalidades en la
aplicación de escritorio también.

La adición de estas funcionalidades, impactan el tiempo de desarrollo y definición de

requerimientos ya que incrementan el número de tareas inicialmente propuesto, pero
debe ser atendido ya que se considera importante para el correcto funcionamiento del
sistema.

2.15 Proyección de resultados.

Se espera que con la finalización del proyecto se tengan los siguientes

resultados:
 Un sistema de préstamo y recepción de equipos funcional que pueda ser de
interés a otras entidades que tengan necesidades o procesos similares.
 Experiencia verificable de la Facultad de Ingeniería Electrónica en el diseño
y desarrollo de sistemas para la automatización de procesos empresariales,
aplicando metodologías de desarrollo.
 Un sistema que sirva de laboratorio para quienes deseen implementar
sistemas relacionados al proceso de manejo de equipos, tal como sistemas
de inventario, localización, seguridad, mantenimiento preventivo, entre otros,
y los sistemas asociados de acceso a la información así como los algoritmos
que apoyen estos procesos.

16
2.15 Convenios.
.
Ninguno

2.16 Informe financiero

El proyecto no cuenta con ningún tipo de recurso económico diferente al tiempo
dedicado por parte del docente que está a cargo del proyecto con una dedicación
promedio de 20 Horas mensuales.

2.17 Bibliografía

[1] Microsoft, «Access 2016 specifications,» Microsoft, [En línea]. Available:

https://support.office.com/en-us/article/Access-2016-specifications-0cf3c66f-9cf2-
4e32-9568-98c1025bb47c. [Último acceso: 14 8 2017].
[2] G. Lory,, D. Campbell,, A. Robin, G. Simmons y P. Rytkonen, Microsoft Solutions
Framework version 3.0 Overview, Microsoft, 2003.
[3] I. Sommerville, Ingeniería de software, Madrid, España: Pearson, 2005.
[4] Microsoft, «Risk Management Description Template,» Microsoft, [En línea].
Available: https://www.microsoft.com/en-us/download/confirmation.aspx?id=20007.
[Último acceso: 5 9 2016].
[5] U. S. Tomas, «Documento Marco Proyección Social,» Bogotá, Colombia, Ediciones
USTA, 2015, p. 17.

17