DISEÑO Y PUESTA EN MARCHA DEL SISTEMA DENOMINADO LABOITFIP PARA

SOLICITUD, REGISTRO Y CONTROL DE EQUIPOS DE LABORATORIO PARA EL

PROGRAMA DE INGENIERIA CIVIL DEL ITFIP.

CRISTIAN JAMIR BARRERA LEAL

SEBASTIAN NUÑEZ LARA

INSTITUCION DE EDUCACION SUPERIOR ITFIP

FACULTAD DE INGENIERIAS Y CIENCIAS AGRONOMICAS
TECNOLOGIA EN GESTION INFORMATICA
ESPINAL
1
2020

2
DISEÑO Y PUESTA EN MARCHA DEL SISTEMA DENOMINADO LABOITFIP PARA
SOLICITUD, REGISTRO Y CONTROL DE EQUIPOS DE LABORATORIO PARA EL
PROGRAMA DE INGENIERIA CIVIL DEL ITFIP.

CRISTIAN JAMIR BARRERA LEAL

SEBASTIAN NUÑEZ LARA

PROYECTO DE GRADO PARA OPTAR AL TITULO DE TECNOLOGOS EN

GESTION INFORMATICA

DOCENTE MAUREN ANDRES GUAYARA

INSTITUCION DE EDUCACION SUPERIOR ITFIP

FACULTAD DE INGENIERIAS Y CIENCIAS AGRONOMICAS
TECNOLOGIA EN GESTION INFORMATICA
 ESPINAL
2020

RESUMEN

Con los avances de las tecnologías de la información y la comunicación y las estrategias

del gobierno nacional en cabeza del Ministerio de Tecnologías de la Información y las
Comunicaciones (MINTIC), las cuales se promueven en todos los sectores del país:
educación, industria, recreación, salud, entre otros; favorece la sistematización de sus
procesos a través de los diferentes recursos tecnológicos, con el fin de optimizar el
desarrollo de las operaciones.

Este aplicativo llamado LABOITFIP para los laboratorios de topografía, concretos, suelos y
agregados, lograran una modernización en el manejo de la información de los procesos de
movimiento de equipos e inventarios, los cuales actualmente se realizan de forma manual
y el almacenamiento de los datos es en medio físico. Debido a esto se presenta
ineficiencia en las tareas, baja confiabilidad para la toma de decisiones e inseguridad en la
información, por tal razón la implementación de software para el Préstamo de Equipos es
de suma importancia para atender la necesidad puntual de los laboratorios de nuestra
institución.

Para realizar el desarrollo del proyecto se partió de las necesidades específicas de

sistematización de la información de los procesos de movimientos e inventarios de los
laboratorios, las cuales fueron base fundamental en el proceso de programación del
software, para ello se realizó el montaje de una base de datos en PHP MY-ADMIN
ajustada a los requerimientos de la oficina de préstamo de los laboratorios, así como una
interfaz gráfica orientada al usuario de fácil acceso y muy amigable, la cual una vez
demuestre su funcionalidad continuara con el proceso de implementación.
1.1 OBJETIVOS

1.1.1 OBJETIVO GENERAL

Desarrollar una aplicación para el control de inventario y préstamo de la maquinaria y

equipos de los laboratorios de topografía, concretos, suelos y agregados, del Instituto
Tolimense de Formación Técnica Profesional “ITFIP” en el municipio del Espinal
Tolima.

1.1.2 OBJETIVOS ESPECÍFICOS

 Obtener la información primaria para dar inicio a la ejecución de las actividades del
proyecto en lo referente al desarrollo del aplicativo

 Analizar la problemática que se presenta en el proceso de control de inventario y

préstamo de equipos de los laboratorios de topografía, concreto, suelos y
agregados del Instituto Tolimense de Formación Técnica Profesional “ITFIP” en el
municipio del Espinal Tolima.

 Proponer una solución tecnológica para la problemática identificada.

 Desarrollar el software que permitirá la solución al problema establecido.

 Implementar el aplicativo Préstamo de Equipos para el laboratorio topografía,

concreto, suelos y agregados del Instituto Tolimense de Formación Técnica
Profesional “ITFIP” en el municipio del Espinal Tolima.
1.2 JUSTIFICACIÓN

Se pretende que la aplicación pueda tener dicho control, pero no es posible

afirmar que el problema esté resuelto, ya que controlar es una tarea también
difícil, sin embargo al implementar un aplicativo que ayude en el control de
registrar usuarios, solicitudes de préstamos y devoluciones e inventario de
estos elementos y algunos de los eventos que puede ocurrir, puede llegar a
permitir a los usuarios mejor servicio y relación entre ellos.

Además que a través del registro de los elementos se puede llegar a mitigar
los riesgos, ya que se tendrá visibilidad del inventario para saber los
elementos faltantes, los que se encuentran en préstamo o los nuevos que
adquiera el laboratorio y así reducir las pérdidas o daños de estos.

Con el manejo adecuado de esta aplicación también se estaría

contribuyendo con el medio ambiente, ya que no se creería necesario la
utilización de papel para dicho proceso.
También, es de resaltar que al realizar estas solicitudes de préstamo por un
aplicativo Web minimizamos el impacto ambiental puesto que no tendremos
que generar un registro en físico ya que todo quedara registrado en una
base de datos la cual puede ser consultada en momento real y de esta forma
evitar llevar el histórico por medio de hojas u otros elementos.
 CAPITULO I
2. GENERARILIDADES

2.1 DESCRIPCIÓN DEL PROBLEMA

Originalmente se plantearon 5 interrogaciones que permitieron identificar la problemática y

la necesidad de crear una aplicación que permite dar una solución a la misma, los cuales
fueron:

1. ¿cómo se llevan a cabo la verificación de los equipos con los que cuentan los
laboratorios?
2. ¿Cómo desarrollar un software ideal para el control de inventario y préstamo de
equipos para los laboratorios de Topografía, concretos, suelos y agregados del
Instituto Tolimense de Formación Técnica Profesional “ITFIP” en el municipio del
Espinal Tolima?
3. ¿Cómo se realiza y que herramientas se utilizan, para el control de los inventarios y
préstamos de los equipos en los respectivos laboratorios?
4. ¿Cuál es el grado de confiabilidad de la información de Inventarios?
5. ¿Cuánto tiempo es dedicado a la verificación de los inventarios

3.1.1. Descripción del problema.

Desde el año 2006 el Instituto Tolimense de Formación Técnica profesional “ITFIP”, se

encarga de ofertar el programa de ingeniería civil por ciclos propedéuticos, para la
orientación con calidad de dicho programa se establecieron espacios y recursos como lo
son los laboratorios de topografía, concretos, suelos y agregados. Cada laboratorio se
encuentra dotado por maquinaria, equipos u herramienta necesaria para el desarrollo y
cumplimiento de las diversas actividades u laboratorios.
En este caso en particular, se decidió realizar un estudio más a fondo acerca del control de
inventario y préstamos de equipos, de modo de identificar el fallo más significativo,
disminuirlo y en el mejor de los casos eliminarlo.
El objetivo de este estudio es evaluar el método de trabajo y control que se tiene sobre
esta actividad, así como también el análisis del manejo de almacenamiento en aspectos
como la organización de áreas y control de inventario, asociado a los inconvenientes que
se generan al no cumplir con una buena gestión de almacenaje, garantizando una
excelente atención, así como también generar oportunidades de mejoras en cada uno de
los puntos críticos encontrados en el análisis.

La situación actual de los laboratorios ya mencionados, desde el inicio se lleva a cabo por
la solicitud del personal académico, es decir estudiantes y docentes que hacen parte del
programa ofertado, quienes por medio de un formato físico realizan la solicitud de equipos
o laboratorios. Dichos préstamos son manejados por personal administrativo, quien se
encarga de inspeccionar y verificar que los implementos y equipos se encuentren en
perfecto orden al ser solicitados y en su respectiva entrega, además de verificar que
corresponda con un código de inventario, el cual es manejado para control de inventario,
siendo incluidos los formatos en archivo. Así mismo se hace una auditoria de la maquinaria
y equipos con los que cuenta cada uno de los laboratorios.

En el análisis y resultado de esta práctica se obtuvieron los siguientes resultados, así: En

la oficina de préstamos de los laboratorios de topografía, concretos, suelos y agregados, el
método que se utiliza actualmente para el control, monitoreo e inventario de los equipos
con los que cuenta cada laboratorio, presenta una variedad de fallas que afecta el
rendimiento del día a día del almacén. Una de las causas principales es que los
préstamos, entregas y monitoreo de inventario se manejan en medio físico, causando
fallas e inconvenientes en cuanto al orden y proceso de registro.

¿Será posible la elaboración de un aplicativo que ayude en la labor de

préstamos de los elementos de laboratorio de topografía y suelos?
 3. MARCO REFRENCIAL

3.1 MARCO TEORICO

Dado que todo el proyecto gira en torno al desarrollo de una solución tecnológica
que solvente la problemática presentada por el manejo de archivos que
actualmente ostenta falencias en sus procesos de préstamos y manejo de
inventarios; se hace necesaria la búsqueda de información y conocimientos
previos que sirvan de antecedentes y de partida inicial para dar comienzo al
mismo. Por tal motivo es indispensable la abstracción de los distintos conceptos
que intervendrán en desarrollo del proyecto (préstamo de equipos, inventarios,
identificación de la problemática, análisis de requerimientos, estudio de
factibilidad, ciclo de vida de los equipos), que serán fundamentales para su
ejecución.

Sin más preámbulo se dará comienzo a la interpretación de los conceptos

anteriormente mencionados.

En la actualidad la oficina de préstamo de equipos de los laboratorios de

Topografía, concretos, suelos y agregados del Instituto Tolimense de Formación
Técnica Profesional “ITFIP” que centran la función de préstamo, manejo y control
de equipos, se ve obligada a llevar el control de solicitud de préstamo, ingresos e
inventarios por medio de un control organizado y confiable que permita identificar
claramente el estado actual y uso que se le ha dado anteriormente a los equipos;
También se hace necesario conocer los inventarios reales al día a día que los
laboratorios poseen, ya que estos representan los bienes con que esta cuenta.

3.1.1. La investigación en el campo del desarrollo del software

Identificación de la problemática. La identificación y argumentación de una idea de

negocio o un problema cuya solución necesita la elaboración de un proyecto, es
un proceso primordial e indispensable que está conformado por factores como los
son la experiencia, el conocimiento previo y el tiempo.

La tarea de identificar de manera objetiva una problemática no es algo sencillo,

pero si es el punto de partida para dar inicio a la elaboración de una solución
preliminar a una problemática; si se identifica de manera correcta la problemática
se puede dar una solución que la satisfaga.

Análisis de la problemática. Un problema es una circunstancia en la que se genera

un obstáculo al curso normal de las cosas. Su etimología nos demuestra que un
problema es aquel que requiere de solución.

Otras definiciones nos indican que el problema es una situación de

inconveniencia, insatisfacción, que no puede ser resuelto en forma autónoma, por
los propios afectados (vulnerabilidad). Se puede manifestar por la carencia de algo
bueno, por la existencia de algo malo. También se puede identificar un problema
ante una oportunidad de desarrollo no aprovechada

Para dar una solución a una problemática hay que identificar en primera instancia
los aspectos que forman parte de esta, como lo son los elementos que intervienen
en esta, los parámetros que lo caracterizan y los hechos o circunstancias que la
rodean. Si se desea lograr una visión global de la problemática se puede usar el
esquema CPC (causas, problemática y consecuencias).

Elementos de la problemática. Si se desea identificar una problemática de manera

objetiva hay que llegar a la causa raíz de la misma, pero para ello hay que conocer
que elementos componen una problemática:

 Causas: Entiéndanse como los distintos factores que originan el problema,

los cuales pueden ser de carácter directo (primarias), que están
estrechamente involucrados con el problema, y de carácter indirecto
(secundarios) que son los que dan origen a las causas primarias
  Consecuencias: Son el resultado o el efecto originado por una determinada
causa que puede materializarse en un futuro si esta no se trata
adecuadamente. Por lo general las consecuencias pueden ponderasen
según el impacto que lleguen a tener para la empresa (ya se económico,
organizacional, entre otros), y es por este motivo que en su gran mayoría
se acude a la elaboración de planes de prevención y contingencias que
mitiguen estas consecuencias.
 Soluciones: Son todas aquellas acciones que permiten suprimir de manera
parcial o total las causas de un problema. Aplicándolo al objetivo del
proyecto de desarrollo, seria elaborar una solución tecnológica que
contribuya y mejore los procesos de facturación y manejo de inventarios
del almacén Secretos Íntimos.

3.1.2. Análisis de requerimiento en la ingeniería del software

Para entender que es el análisis de requerimientos hay que tener claros cada
concepto por separado.

 Análisis: Se entiende por análisis a la acción de comprender un

determinado fenómeno después de haber recopilado información sobre el
mismo; Básicamente consiste en descomponer un fenómeno en la suma de
sus elementos con el fin de aclarar el cómo se interrelacionan y así
identificar las causas que generan el fenómeno.
 Requerimiento: En desarrollo de software, se entiende como requerimiento
a una característica propia del sistema o descripción de algo que el sistema
pueda realizar para poder satisfacer el objetivo del sistema.

Una vez aclarado que significa cada concepto por separado y haciendo la
integración de los mismos, se tendría que análisis de requerimientos es como su
nombre lo indica, analizar las posibles necesidades presentadas por nuestra
fuente con el fin de comprenderlas y poder brindar soluciones tecnológicas que
suplan dichas necesidades.
Aplicándolo al desarrollo de software, un requisito es la descripción de los
servicios que debe ofrecer el sistema y sus restricciones.

Los requerimientos se dividen en:

 Requerimientos funcionales: Son declaraciones de los servicios que

debe proporcionar el sistema, de la manera en que éste debe reaccionar
a entradas particulares y de cómo se debe comportar en situaciones
particulares. En algunos casos, los requerimientos funcionales de los
sistemas también pueden declarar explícitamente lo que el sistema no
debe hacer. Los requerimientos funcionales de un sistema describen lo
que el sistema debe hacer1. Estos requerimientos dependen del tipo de
software que se desarrolle, de los posibles usuarios del software y del
enfoque general tomado por la organización al redactar requerimientos.
Cuando se expresan como requerimientos del usuario, habitualmente se
describen de una forma bastante abstracta. Sin embargo. Los
requerimientos funcionales del sistema describen con detalle la función
de éste, sus entradas y salidas, excepciones, etcétera 2.
 Requerimientos no funcionales: Son restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo,
sobre el proceso de desarrollo y estándares. Los requerimientos no
funcionales a menudo se aplican al sistema en su totalidad.
Normalmente apenas se aplican a características o servicios
individuales del sistema. Los requerimientos no funcionales, como su
nombre sugiere, son aquellos requerimientos que no se refieren
directamente a las funciones específicas que proporciona el sistema,
sino a las propiedades emergentes de éste como la fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento. De forma alternativa,
definen las restricciones del sistema como la capacidad de los
1
[ CITATION www18 \l 9226 ]
2
[ CITATION boo18 \l 9226 ]
 dispositivos de entrada/salida y las representaciones de datos que se
utilizan en las interfaces del sistema.

3.1.3. Ciclo de vida del Software

En todo proceso de desarrollo de software requiere antes de iniciar con su ciclo de

vida, efectuar los estudios de factibilidad, que permitirá la aprobación de todo su
proceso de planeación del proyecto, permitiendo al grupo de trabajo tomar las
decisiones de ejecución o ajustes en cuanto al tiempo, ajuste de tipo tecnológico o
costos de proyecto.

El estudio de factibilidad tiene como objetivos:

 Reducir errores en los procesos de planeación y desarrollo del proyecto.

 Reducir costos eliminando los recursos no necesarios y optimizando los
recursos necesarios para la planeación y desarrollo del proyecto.
 Asegurar la disponibilidad de los recursos necesarios para llevar a cabo
el proyecto.
 Saber con certeza si se puede o no realizar un proyecto.

Se dice que un proyecto es factible para su ejecución si cumple con todo:

 Factibilidad operativa: Comprende una determinación de posibilidad que un

nuevo sistema se use como se debe hacer. Hay que considerar cuatro
aspectos:

o La utilización del nuevo sistema puede ser demasiado compleja para

los usuarios involucrados en su uso.
o Un nuevo sistema puede ocasionar que los usuarios se resistan a su
uso por miedo a ser desplazados u otras razones.
 o Un nuevo sistema puede ocasionar cambios de forma abrupta
impidiendo que los usuarios involucrados en su uso puedan
adaptarse de forma rápida a él.
o Contemplar la probabilidad de obsolescencia del sistema,
ocasionado por cambios en políticas administrativas, entre otras
causas.

También comprende al recurso humano que intervendrá tanto en el desarrollo,

implementación y uso del sistema.

 Factibilidad técnica: Permite hacer una evaluación de los recursos

tecnológicos (equipos, programas, entre otros) necesarios con respecto a la
elaboración, desarrollo, funcionalidad y rendimiento del sistema que se
piensa desarrollar. Adicional a esto también se evalúa si las organizaciones
cuentan con el personal competente para operar y mantener este sistema.

 Factibilidad legal: Se encarga de evaluar la normatividad legal vigente que

puede afectar o no a la ejecución del proyecto de desarrollo de software.

 Factibilidad económica: Permite identificar y justificar si económicamente un

proyecto cuenta con los recursos necesarios para todo el ciclo de vida de
software, así como demostrar a nivel de costos que la inversión que se está
realizando es justificada por la ganancia que se va a conseguir. Para esta
etapa se realiza una estimación de costos de los distintos factores que
intervendrán el proyecto, como lo son los costos por tecnología, costos por
mano de obra, costos de transporte, costos de capacitación, entre otros.

 Factibilidad de tiempo: Se encarga de evaluar si se cuenta con el tiempo

necesario para la culminación del proyecto desde su planificación hasta la
implementación del mismo. Para identificar si hay o no el tiempo necesario
 se suele realizar un cronograma de actividades, el cual contempla las
distintas etapas del proyecto, así como el tiempo máximo para la
terminación de cada una de ellas y la culminación del proyecto como tal.

3.1.4. Metodología de desarrollo del Software

Son aquellas metodologías con enfatizadas en la planificación y control del

proyecto, en la especificación precisa de requisitos y modelado. Hay dos tipos de
metodologías, las metodologías tradicionales (o también denominadas
metodologías pesadas, o peso pesado) y las metodologías agiles, las cuales están
más orientadas a una fuerte planificación durante todo el proceso de desarrollo
que se desarrollan durante un periodo a corto plazo.

Para fines del desarrollo del proyecto se escogió la metodología ágil denominada
SCRUM.

 Concepto de la metodología de desarrollo SCRUM

Más que un proceso o un conjunto de técnicas, SCRUM es un marco de trabajo

donde se pueden incorporar diferentes procesos.

Se utiliza para coordinar las acciones de un grupo de trabajo de forma que cada
ciclo de trabajo derive en una serie de elementos que proporcionen un incremento
en el valor del proyecto total. De esta forma al final de cada ciclo se añaden varios
puntos de funcionalidad de forma que no hay que esperar a las etapas finales de
desarrollo para ver elementos funcionales. Una de las características aconsejables
a la hora de trabajar bajo este marco de trabajo es la posibilidad de integrar al
cliente o usuario final en el proceso de desarrollo.
Debido a lo expuesto con anterioridad hemos decidido hablar sobre este marco de
trabajo, ya que al ser un equipo pequeño podemos coordinar bien nuestro trabajo.
Además, la posibilidad de integrar a los clientes es clave en nuestro desarrollo ya
que uno de nuestros pilares es el desarrollo centrado en el usuario. En realidad,
las características de las que se ha hablado antes se enmarcan en lo que se
conoce o al equipo de desarrollo. Su función no es desarrollar el producto, su
función es decir lo que quiere, cómo lo quiere y qué es lo que quiere en cada
iteración.

o Equipo desarrollo: consiste en profesionales que desarrollan el producto

y cuya función es entregar versiones estables y funcionales del producto
al final de cada iteración. Los equipos de desarrollo tienen la capacidad
para organizarse a sí mismos. El tamaño del equipo debería ser de
entre 3 y 9 personas.

o SCRUM master: es la persona que mejor conoce y maneja SCRUM en

todo el equipo. Es el responsable de que SCRUM sea entendido y
promulgado. Entre sus funciones está ayuda al propietario del producto
a entender la planificación y ayudar al equipo de desarrollo a crear
productos con gran valor, por ejemplo.

o Eventos: la principal característica de los eventos en SCRUM es que

tienen una duración fija, no pueden ser acortados ni alargados. Los
eventos que tenemos son los siguientes:

 Sprint: el sprint es el corazón de SCRUM. Lo que antes

llamábamos iteración el sprint. La duración de un sprint es de
un mes o menos en la que se produce un incremento
funcional del producto. Los eventos nombrados a continuación
forman parte de un sprint.
 Planificación del sprint: aquí se planifica el trabajo que será
realizado en un sprint. Para un sprint de un mes el tiempo
usado para su planificación no debería superar las 8 horas.
  Daily SCRUM: el Daily SCRUM es un periodo diario de 15
minutos en el que el equipo de desarrollo sincroniza sus
actividades y crea un plan para el siguiente día.
 Revisión del sprint: la revisión del sprint tiene lugar al final del
mismo y tiene una duración de 4 horas para un sprint de un
mes. Durante ese tiempo el equipo y los stakeholders
comprueban lo que se ha realizado en el sprint y discuten lo
que se puede hacer en el siguiente sprint para optimizar el
valor.
 Retrospectiva del sprint: la retrospectiva del sprint tiene lugar
después de la revisión y tiene una duración de 3 horas para
un sprint de 1 mes. La retrospectiva sirve al equipo para
revisarse a sí mismos y crear un plan para mejorar los fallos
para el siguiente sprint.

o Actividades Que Se Desarrollan En SCRUM

Las actividades que se llevan a cabo en SCRUM son las siguientes:

 Planificación de la iteración: el primer día de la iteración se

realiza la reunión de planificación de la iteración. Tiene dos
partes:

 Selección de requisitos (4 horas máximo). El cliente

presenta al equipo la lista de requisitos priorizada del
producto o proyecto. El equipo pregunta al cliente las
dudas que surgen y selecciona los requisitos más
prioritarios que se compromete a completar en la
iteración, de manera que puedan ser entregados si el
cliente lo solicita.
  Planificación de la iteración (4 horas máximo). El
equipo elabora la lista de tareas de la iteración
necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de
manera conjunta y los miembros del equipo se auto
asignan las tareas.

 Ejecución de la iteración: cada día el equipo realiza una

reunión de sincronización (15 minutos máximos). Cada
miembro del equipo inspecciona el trabajo que el resto está
realizando (dependencias entre tareas, progreso hacia el
objetivo de la iteración, obstáculos que pueden impedir este
objetivo) para poder hacer las adaptaciones necesarias que
permitan cumplir con el compromiso adquirido.

En la reunión cada miembro del equipo responde a tres preguntas:

¿Qué he hecho desde la última reunión de sincronización?

¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con

su compromiso y de que no se merme su productividad.

- Elimina los obstáculos que el equipo no puede resolver por sí

mismo.
- Protege al equipo de interrupciones externas que puedan
afectar su compromiso o su productividad.

Durante la iteración, el cliente junto con el equipo refina la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o re
planifican los objetivos del proyecto para maximizar la utilidad de lo que se
desarrolla y el retorno de inversión.

o Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene

dos partes:

 Demostración (1 horas máximo). El equipo presenta al cliente los

requisitos completados en la iteración, en forma de incremento de
producto preparado para ser entregado con el mínimo esfuerzo.
En función de los resultados mostrados y de los cambios que
haya habido en el contexto del proyecto, el cliente realiza las
adaptaciones necesarias de manera objetiva, ya desde la primera
iteración, re planificando el proyecto.
 Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido
su manera de trabajar y cuáles son los problemas que podrían
impedirle progresar adecuadamente, mejorando de manera
continua su productividad. El Facilitador se encargará de ir
eliminando los obstáculos identificados.

3.1.5. Estudio de factibilidad en el desarrollo del software

En todo proceso de desarrollo de software requiere antes de iniciar con su ciclo de

vida, efectuar los estudios de factibilidad, que permitirá la aprobación de todo su
proceso de planeación del proyecto, permitiendo al grupo de trabajo tomar las
decisiones de ejecución o ajustes en cuanto al tiempo, ajuste de tipo tecnológico o
costos de proyecto.

El estudio de factibilidad tiene como objetivos:

  Reducir errores en los procesos de planeación y desarrollo del proyecto.
 Reducir costos eliminando los recursos no necesarios y optimizando los
recursos necesarios para la planeación y desarrollo del proyecto.
 Asegurar la disponibilidad de los recursos necesarios para llevar a cabo
el proyecto.
 Saber con certeza si se puede o no realizar un proyecto.

Se dice que un proyecto es factible para su ejecución si cumple con todo:

 Factibilidad operativa: Comprende una determinación de posibilidad que un

nuevo sistema se use como se debe hacer. Hay que considerar cuatro
aspectos:

o La utilización del nuevo sistema puede ser demasiado compleja para

los usuarios involucrados en su uso.
o Un nuevo sistema puede ocasionar que los usuarios se resistan a su
uso por miedo a ser desplazados u otras razones.
o Un nuevo sistema puede ocasionar cambios de forma abrupta
impidiendo que los usuarios involucrados en su uso puedan
adaptarse de forma rápida a él.
o Contemplar la probabilidad de obsolescencia del sistema,
ocasionado por cambios en políticas administrativas, entre otras
causas.

También comprende al recurso humano que intervendrá tanto en el desarrollo,

implementación y uso del sistema.

 Factibilidad técnica: Permite hacer una evaluación de los recursos

tecnológicos (equipos, programas, entre otros) necesarios con respecto a la
elaboración, desarrollo, funcionalidad y rendimiento del sistema que se
 piensa desarrollar. Adicional a esto también se evalúa si las organizaciones
cuentan con el personal competente para operar y mantener este sistema.

 Factibilidad legal: Se encarga de evaluar la normatividad legal vigente que

puede afectar o no a la ejecución del proyecto de desarrollo de software.

 Factibilidad económica: Permite identificar y justificar si económicamente un

proyecto cuenta con los recursos necesarios para todo el ciclo de vida de
software, así como demostrar a nivel de costos que la inversión que se está
realizando es justificada por la ganancia que se va a conseguir. Para esta
etapa se realiza una estimación de costos de los distintos factores que
intervendrán el proyecto, como lo son los costos por tecnología, costos por
mano de obra, costos de transporte, costos de capacitación, entre otros.

 Factibilidad de tiempo: Se encarga de evaluar si se cuenta con el tiempo

necesario para la culminación del proyecto desde su planificación hasta la
implementación del mismo. Para identificar si hay o no el tiempo necesario
se suele realizar un cronograma de actividades, el cual contempla las
distintas etapas del proyecto, así como el tiempo máximo para la
terminación de cada una de ellas y la culminación del proyecto como tal.

3.2 MARCO CONCEPTUAL

3.2.1. Inventarios

La base de toda empresa comercial es la compra y venta de bienes o servicios; de

aquí la importancia del manejo del inventario por parte de la misma. Este manejo
permitirá a la empresa mantener un control oportuno, así como también conocer al
final de un periodo un estado confiable de la situación económica de la empresa. 3
3
Espinosa, Pedro, Ramírez, Alejandra, Proyecto de Grado, Diseño E Implementación Del Sistema De Inventarios A La
Bodega Del Depósito Y Autoservicio La Colmena, Universidad Industrial de Santander, Escuela De Estudios Industriales
Y Empresariales, Bucaramanga, 2006.
Los inventarios forman parte importante dentro de la contabilidad de cualquier
empresa, debido a que son por decirlo así el alma de la misma; el inventario es
considerado el activo (fuente de ingreso económico) mayor en los balances
generales de la empresa, y la venta de los inventarios, también denominado
gastos por mercancía vendida por lo general son el gasto mayor en el estado de
resultados de la empresa.

Los inventarios son existencias de algún tipo de artículo o servicio que está
disponible para su comercialización. Dentro de los inventarios se encuentran las
materias primas necesarias para llevar un proceso productivo, los materiales de
empaque y envase necesarios para el envasado y empaquetado de las materias
primas que se encuentran en proceso productivo, el producto terminado, que es la
finalización de un producto después del proceso productivo, y la prestación de
algún servicio ofrecido por la empresa.

Para todas las empresas dedicadas a la compra y venta de productos y/o

servicios, se hace necesario tener de manera más sencilla y condensada toda la
información de los distintos movimientos económicos que esta genera, por tal
motivo se hace indispensable el uso de una serie de cuentas que permiten llevar
el control de esto movimientos. Dentro de estas cuentas están:

 Inventario Inicial: Esta cuenta representa el valor inicial de los inventarios

en la fecha de comienzo del periodo contable. Y solo se abre al comienzo
del periodo contable y no vuelve a tener movimientos hasta cerrarse este
periodo ya sea por cargo de Costo de Ventas o por Ganancias y Pérdidas.
 Gastos de compras: Esta cuenta hace referencia a los gastos generados
por adquisición y/o compra de mercancías. Un ejemplo práctico para aclarar
en qué casos se usa esta cuenta, son los gastos de transportes generados
por compra de mercancía. Esta cuenta no entra en el balance general de la
empresa.
  Devolución en compras: El objetivo principal de esta cuenta es reflejar la
mercancía adquirida y/o comprada por la empresa que ha sido devuelta por
algún motivo. Sin embargo vale la pena hacer la observación de que
aunque esta cuenta disminuirá la compra de mercancías, no se abonara a
la cuenta compras.
 Mercancía en tránsito: Esta cuenta se usa siempre y cuando la empresa
hace compra de mercancías al exterior, y sirve para identificar todas
aquellas obligaciones de pago que la empresa ha adquirido (documentos,
giros) o por el desembolso parcial o total del valor de compra de una
mercancía que por circunstancias de transporte o cualquier otra
circunstancia no han sido recibidas físicamente en la empresa.
 Mercancía en consignación: Esta cuenta se usa siempre y cuando la
empresa tenga alguna mercancía en “consignación”; entiéndase en
consignación a la mercancía que está en manos del vendedor pero que no
es propiedad del mismo, por tal motivo no tiene ninguna obligación de
realizar el pago de dicha mercancía hasta que este no la venda.
 Inventario actual (final): Este corresponde al inventario físico realizado al
finalizar el periodo contable, el cual, al relacionarse el inventario inicial, las
compras de mercancía y ventas de la misma, permiten identificar cuáles
fueron las Ganancias o Pérdidas brutas de ese periodo.

Ya entendiendo la importancia de los inventarios en cualquier tipo de organización

que se centra en brindar el servicio de préstamo de equipos/o servicios se puede
concluir que: si hay un buen manejo y una buena valoración de los inventarios la
organización no solo va a saber realmente con que cuenta, sino también va a ir
creciendo paulatinamente y así garantizar el éxito empresarial; Pero por el
contrario, si no hay un control ni una buena valoración de los inventarios, la
organización puede llegar a la quiebra.

3.2.2. Software
El software está compuesto por un conjunto de programas que son diseñados
para cumplir una determinada función dentro de un sistema, ya sean estos
realizados por parte de los usuarios o por las mismas corporaciones dedicadas a
la informática.

El concepto de software, como bien dijimos anteriormente, compone la parte

lógica de un sistema de computación, permitiéndole el funcionamiento. Esto quiere
decir entonces que no solo los programas son y forman un software, sino que la
información del usuario y los datos procesados integran el software, ya que forma
parte de él todo componente intangible y no físico.

Tipos principales de software

 Software de sistema: Este grupo clasifica a los programas que dan al

usuario la capacidad de relacionarse con el sistema, para entonces ejercer
control por sobre el hardware. El software de sistema también se ofrece
como soporte para otros programas. Ejemplos: sistemas operativos,
servidores, etcétera.
 Software de programación: Programas directamente diseñados como
herramientas que le permiten a un programador el desarrollo de programas
informáticos. Influyen en su utilización diferentes técnicas utilizadas y
lenguaje de programación específico. Ejemplos: compiladores, editores
multimedia, etcétera.
 Software de aplicación: Programas diseñados para la realización de una o
más tareas específicas a la vez, pudiendo ser automáticos o asistidos.
Ejemplos: vídeo juegos, aplicaciones ofimáticas, etcétera.

Fuente: https://concepto.de/software/#ixzz5aL2KBXAY
Otras definiciones nos indican que el problema es una situación de
inconveniencia, insatisfacción, que no puede ser resuelto en forma autónoma, por
los propios afectados (vulnerabilidad). Se puede manifestar por la carencia de algo
bueno, por la existencia de algo malo. También se puede identificar un problema
ante una oportunidad de desarrollo no aprovechada 4

Para dar una solución a una problemática hay que identificar en primera instancia
los aspectos que forman parte de esta, como lo son los elementos que intervienen
en esta, los parámetros que lo caracterizan y los hechos o circunstancias que la
rodean. Si se desea lograr una visión global de la problemática se puede usar el
esquema CPC (causas, problemática y consecuencias).

Elementos de la problemática. Si se desea identificar una problemática de manera

objetiva hay que llegar a la causa raíz de la misma, pero para ello hay que conocer
que elementos componen una problemática:

 Causas: Entiéndanse como los distintos factores que originan el problema,

los cuales pueden ser de carácter directo (primarias), que están
estrechamente involucrados con el problema, y de carácter indirecto
(secundarios) que son los que dan origen a las causas primarias
 Consecuencias: Son el resultado o el efecto originado por una determinada
causa que puede materializarse en un futuro si esta no se trata
adecuadamente. Por lo general las consecuencias pueden ponderasen
según el impacto que lleguen a tener para la empresa (ya se económico,
organizacional, entre otros), y es por este motivo que en su gran mayoría
se acude a la elaboración de planes de prevención y contingencias que
mitiguen estas consecuencias.
 Soluciones: Son todas aquellas acciones que permiten suprimir de manera
parcial o total las causas de un problema. Aplicándolo al objetivo del
proyecto de desarrollo, seria elaborar una solución tecnológica que
contribuya y mejore los procesos de facturación y manejo de inventarios
del almacén Secretos Íntimos.

4
Metodología Para Análisis Y Solución De Problemas,2015,
www.cepal.org/ilpes/noticias/paginas/7/35117/03_arbol_1.pdf [Consulta: Viernes, 25 de Marzo de 2016]
3.2.3. Análisis de requerimiento en la ingeniería del software

Para entender que es el análisis de requerimientos hay que tener claros cada
concepto por separado.

 Análisis: Se entiende por análisis a la acción de comprender un

determinado fenómeno después de haber recopilado información sobre el
mismo; Básicamente consiste en descomponer un fenómeno en la suma de
sus elementos con el fin de aclarar el cómo se interrelacionan y así
identificar las causas que generan el fenómeno.
 Requerimiento: En desarrollo de software, se entiende como requerimiento
a una característica propia del sistema o descripción de algo que el sistema
pueda realizar para poder satisfacer el objetivo del sistema.

Una vez aclarado que significa cada concepto por separado y haciendo la
integración de los mismos, se tendría que análisis de requerimientos es como su
nombre lo indica, analizar las posibles necesidades presentadas por nuestra
fuente con el fin de comprenderlas y poder brindar soluciones tecnológicas que
suplan dichas necesidades.

Aplicándolo al desarrollo de software, un requisito es la descripción de los

servicios que debe ofrecer el sistema y sus restricciones.

Los requerimientos se dividen en:

 Requerimientos funcionales: Son declaraciones de los servicios que

debe proporcionar el sistema, de la manera en que éste debe reaccionar
a entradas particulares y de cómo se debe comportar en situaciones
particulares. En algunos casos, los requerimientos funcionales de los
sistemas también pueden declarar explícitamente lo que el sistema no
debe hacer. Los requerimientos funcionales de un sistema describen lo
 que el sistema debe hacer. Estos requerimientos dependen del tipo de
software que se desarrolle, de los posibles usuarios del software y del
enfoque general tomado por la organización al redactar requerimientos.
Cuando se expresan como requerimientos del usuario, habitualmente se
describen de una forma bastante abstracta. Sin embargo. Los
requerimientos funcionales del sistema describen con detalle la función
de éste, sus entradas y salidas, excepciones, etcétera.
 Requerimientos no funcionales: Son restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo,
sobre el proceso de desarrollo y estándares. Los requerimientos no
funcionales a menudo se aplican al sistema en su totalidad.
Normalmente apenas se aplican a características o servicios
individuales del sistema. Los requerimientos no funcionales, como su
nombre se sugiere, son aquellos requerimientos que no se refieren
directamente a las funciones específicas que proporciona el sistema,
sino a las propiedades emergentes de éste como la fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento. De forma alternativa,
definen las restricciones del sistema como la capacidad de los
dispositivos de entrada/salida y las representaciones de datos que se
utilizan en las interfaces del sistema.

3.2.4. Ciclo de vida del Software

En todo proceso de desarrollo de software requiere antes de iniciar con su ciclo de

vida, efectuar los estudios de factibilidad, que permitirá la aprobación de todo su
proceso de planeación del proyecto, permitiendo al grupo de trabajo tomar las
decisiones de ejecución o ajustes en cuanto al tiempo, ajuste de tipo tecnológico o
costos de proyecto.

El estudio de factibilidad tiene como objetivos:

 Reducir errores en los procesos de planeación y desarrollo del proyecto.

 Reducir costos eliminando los recursos no necesarios y optimizando los
recursos necesarios para la planeación y desarrollo del proyecto.
  Asegurar la disponibilidad de los recursos necesarios para llevar a cabo
el proyecto.
 Saber con certeza si se puede o no realizar un proyecto.

Se dice que un proyecto es factible para su ejecución si cumple con todo:

 Factibilidad operativa: Comprende una determinación de posibilidad que un

nuevo sistema se use como se debe hacer. Hay que considerar cuatro
aspectos:

o La utilización del nuevo sistema puede ser demasiado compleja para

los usuarios involucrados en su uso.
o Un nuevo sistema puede ocasionar que los usuarios se resistan a su
uso por miedo a ser desplazados u otras razones.
o Un nuevo sistema puede ocasionar cambios de forma abrupta
impidiendo que los usuarios involucrados en su uso puedan
adaptarse de forma rápida a él.
o Contemplar la probabilidad de obsolescencia del sistema,
ocasionado por cambios en políticas administrativas, entre otras
causas.

También comprende al recurso humano que intervendrá tanto en el desarrollo,

implementación y uso del sistema.

 Factibilidad técnica: Permite hacer una evaluación de los recursos

tecnológicos (equipos, programas, entre otros) necesarios con respecto a la
elaboración, desarrollo, funcionalidad y rendimiento del sistema que se
piensa desarrollar. Adicional a esto también se evalúa si las organizaciones
cuentan con el personal competente para operar y mantener este sistema.
  Factibilidad legal: Se encarga de evaluar la normatividad legal vigente que
puede afectar o no a la ejecución del proyecto de desarrollo de software.

 Factibilidad económica: Permite identificar y justificar si económicamente un

proyecto cuenta con los recursos necesarios para todo el ciclo de vida de
software, así como demostrar a nivel de costos que la inversión que se está
realizando es justificada por la ganancia que se va a conseguir. Para esta
etapa se realiza una estimación de costos de los distintos factores que
intervendrán el proyecto, como lo son los costos por tecnología, costos por
mano de obra, costos de transporte, costos de capacitación, entre otros.

 Factibilidad de tiempo: Se encarga de evaluar si se cuenta con el tiempo

necesario para la culminación del proyecto desde su planificación hasta la
implementación del mismo. Para identificar si hay o no el tiempo necesario
se suele realizar un cronograma de actividades, el cual contempla las
distintas etapas del proyecto, así como el tiempo máximo para la
terminación de cada una de ellas y la culminación del proyecto como tal.

3.2.5. Metodología de desarrollo del Software

Son aquellas metodologías con enfatizadas en la planificación y control del

proyecto, en la especificación precisa de requisitos y modelado. Hay dos tipos de
metodologías, las metodologías tradicionales (o también denominadas
metodologías pesadas, o peso pesado) y las metodologías agiles, las cuales están
más orientadas a una fuerte planificación durante todo el proceso de desarrollo
que se desarrollan durante un periodo a corto plazo.

Para fines del desarrollo del proyecto se escogió la metodología ágil denominada
SCRUM.

 Concepto de la metodología de desarrollo SCRUM

Más que un proceso o un conjunto de técnicas, SCRUM es un marco de trabajo
donde se pueden incorporar diferentes procesos.

Se utiliza para coordinar las acciones de un grupo de trabajo de forma que cada
ciclo de trabajo derive en una serie de elementos que proporcionen un incremento
en el valor del proyecto total. De esta forma al final de cada ciclo se añaden varios
puntos de funcionalidad de forma que no hay que esperar a las etapas finales de
desarrollo para ver elementos funcionales. Una de las características aconsejables
a la hora de trabajar bajo este marco de trabajo es la posibilidad de integrar al
cliente o usuario final en el proceso de desarrollo.
Debido a lo expuesto con anterioridad hemos decidido hablar sobre este marco de
trabajo, ya que al ser un equipo pequeño podemos coordinar bien nuestro trabajo.
Además, la posibilidad de integrar a los clientes es clave en nuestro desarrollo ya
que uno de nuestros pilares es el desarrollo centrado en el usuario. En realidad,
las características de las que se ha hablado antes se enmarcan en lo que se
conoce como metodologías ágiles, por tanto la pregunta que habría que hacerse
es ¿por qué SCRUM y no XP (Extreme Programming) por ejemplo?

En primer lugar, XP se suele utilizar cuando los requisitos son desconocidos o de

carácter incierto, además se requiere que, normalmente, la pareja de
programadores tenga una amplia experiencia trabajando juntos y se coordinen
bien. En cambio, bajo el marco SCRUM se puede trabajar utilizando algún tipo de
proceso más ordenado basado en alguna metodología concreta.

Por esa razón se ha decidido tratar SCRUM, ya que nuestras características

personales están más enfocadas a este marco de trabajo. De forma que nuestra
productividad y calidad de trabajo en un posible futuro sea mayor.

 Equipo de trabajo
En SCRUM tenemos lo que se llama “SCRUM tema” que consiste en el propietario
del producto, el equipo de desarrollo y el SCRUM master. Los equipos de SCRUM
se organizan a sí mismos lo que quiere decir que ellos mismos deciden la manera
de trabajar que mejor les convenga sin depender de que los dirija nadie de fuera.
Este modelo de equipo está diseñado para optimizar la flexibilidad, creatividad y
productividad. A continuación, se explicará la función de cada miembro del equipo:

o Propietario del producto: es el responsable de maximizar el valor del

producto y del trabajo del equipo de desarrollo. El propietario del
producto es una persona (que puede estar representando a una
empresa) que trabaja junto al equipo de desarrollo. Su función no es
desarrollar el producto, su función es decir lo que quiere, cómo lo quiere
y qué es lo que quiere en cada iteración.

o Equipo desarrollo: consiste en profesionales que desarrollan el producto

y cuya función es entregar versiones estables y funcionales del producto
al final de cada iteración. Los equipos de desarrollo tienen la capacidad
para organizarse a sí mismos. El tamaño del equipo debería ser de
entre 3 y 9 personas.

o SCRUM master: es la persona que mejor conoce y maneja SCRUM en

todo el equipo. Es el responsable de que SCRUM sea entendido y
promulgado. Entre sus funciones está ayuda al propietario del producto
a entender la planificación y ayudar al equipo de desarrollo a crear
productos con gran valor, por ejemplo.

o Eventos: la principal característica de los eventos en SCRUM es que

tienen una duración fija, no pueden ser acortados ni alargados. Los
eventos que tenemos son los siguientes:
  Sprint: el sprint es el corazón de SCRUM. Lo que antes
llamábamos iteración el sprint. La duración de un sprint es de
un mes o menos en la que se produce un incremento
funcional del producto. Los eventos nombrados a continuación
forman parte de un sprint.
 Planificación del sprint: aquí se planifica el trabajo que será
realizado en un sprint. Para un sprint de un mes el tiempo
usado para su planificación no debería superar las 8 horas.
 Daily SCRUM: el Daily SCRUM es un periodo diario de 15
minutos en el que el equipo de desarrollo sincroniza sus
actividades y crea un plan para el siguiente día.
 Revisión del sprint: la revisión del sprint tiene lugar al final del
mismo y tiene una duración de 4 horas para un sprint de un
mes. Durante ese tiempo el equipo y los stakeholders
comprueban lo que se ha realizado en el sprint y discuten lo
que se puede hacer en el siguiente sprint para optimizar el
valor.
 Retrospectiva del sprint: la retrospectiva del sprint tiene lugar
después de la revisión y tiene una duración de 3 horas para
un sprint de 1 mes. La retrospectiva sirve al equipo para
revisarse a sí mismos y crear un plan para mejorar los fallos
para el siguiente sprint.

o Actividades Que Se Desarrollan En SCRUM

Las actividades que se llevan a cabo en SCRUM son las siguientes:

 Planificación de la iteración: el primer día de la iteración se

realiza la reunión de planificación de la iteración. Tiene dos
partes:
  Selección de requisitos (4 horas máximo). El cliente
presenta al equipo la lista de requisitos priorizada del
producto o proyecto. El equipo pregunta al cliente las
dudas que surgen y selecciona los requisitos más
prioritarios que se compromete a completar en la
iteración, de manera que puedan ser entregados si el
cliente lo solicita.
 Planificación de la iteración (4 horas máximo). El
equipo elabora la lista de tareas de la iteración
necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de
manera conjunta y los miembros del equipo se auto
asignan las tareas.

 Ejecución de la iteración: cada día el equipo realiza una

reunión de sincronización (15 minutos máximos). Cada
miembro del equipo inspecciona el trabajo que el resto está
realizando (dependencias entre tareas, progreso hacia el
objetivo de la iteración, obstáculos que pueden impedir este
objetivo) para poder hacer las adaptaciones necesarias que
permitan cumplir con el compromiso adquirido.

En la reunión cada miembro del equipo responde a tres preguntas:

¿Qué he hecho desde la última reunión de sincronización?

¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador (SCRUM Master) se encarga de que el equipo

pueda cumplir con su compromiso y de que no se merme su productividad.
 - Elimina los obstáculos que el equipo no puede resolver por sí
mismo.
- Protege al equipo de interrupciones externas que puedan
afectar su compromiso o su productividad.

Durante la iteración, el cliente junto con el equipo refina la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o re
planifican los objetivos del proyecto para maximizar la utilidad de lo que se
desarrolla y el retorno de inversión.

o Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene

dos partes:

 Demostración (4 horas máximo). El equipo presenta al cliente los

requisitos completados en la iteración, en forma de incremento de
producto preparado para ser entregado con el mínimo esfuerzo.
En función de los resultados mostrados y de los cambios que
haya habido en el contexto del proyecto, el cliente realiza las
adaptaciones necesarias de manera objetiva, ya desde la primera
iteración, re planificando el proyecto.
 Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido
su manera de trabajar y cuáles son los problemas que podrían
impedirle progresar adecuadamente, mejorando de manera
continua su productividad. El Facilitador se encargará de ir
eliminando los obstáculos identificados.

3.2.6. Estudio de factibilidad en el desarrollo del software

En todo proceso de desarrollo de software requiere antes de iniciar con su ciclo de

vida, efectuar los estudios de factibilidad, que permitirá la aprobación de todo su
proceso de planeación del proyecto, permitiendo al grupo de trabajo tomar las
decisiones de ejecución o ajustes en cuanto al tiempo, ajuste de tipo tecnológico o
costos de proyecto.

El estudio de factibilidad tiene como objetivos:

 Reducir errores en los procesos de planeación y desarrollo del proyecto.

 Reducir costos eliminando los recursos no necesarios y optimizando los
recursos necesarios para la planeación y desarrollo del proyecto.
 Asegurar la disponibilidad de los recursos necesarios para llevar a cabo
el proyecto.
 Saber con certeza si se puede o no realizar un proyecto.

Se dice que un proyecto es factible para su ejecución si cumple con todo:

 Factibilidad operativa: Comprende una determinación de posibilidad que un

nuevo sistema se use como se debe hacer. Hay que considerar cuatro
aspectos:

o La utilización del nuevo sistema puede ser demasiado compleja para

los usuarios involucrados en su uso.
o Un nuevo sistema puede ocasionar que los usuarios se resistan a su
uso por miedo a ser desplazados u otras razones.
o Un nuevo sistema puede ocasionar cambios de forma abrupta
impidiendo que los usuarios involucrados en su uso puedan
adaptarse de forma rápida a él.
o Contemplar la probabilidad de obsolescencia del sistema,
ocasionado por cambios en políticas administrativas, entre otras
causas.
 También comprende al recurso humano que intervendrá tanto en el desarrollo,
implementación y uso del sistema.

 Factibilidad técnica: Permite hacer una evaluación de los recursos

tecnológicos (equipos, programas, entre otros) necesarios con respecto a la
elaboración, desarrollo, funcionalidad y rendimiento del sistema que se
piensa desarrollar. Adicional a esto también se evalúa si las organizaciones
cuentan con el personal competente para operar y mantener este sistema.

 Factibilidad legal: Se encarga de evaluar la normatividad legal vigente que

puede afectar o no a la ejecución del proyecto de desarrollo de software.

 Factibilidad económica: Permite identificar y justificar si económicamente un

proyecto cuenta con los recursos necesarios para todo el ciclo de vida de
software, así como demostrar a nivel de costos que la inversión que se está
realizando es justificada por la ganancia que se va a conseguir. Para esta
etapa se realiza una estimación de costos de los distintos factores que
intervendrán el proyecto, como lo son los costos por tecnología, costos por
mano de obra, costos de transporte, costos de capacitación, entre otros.

 Factibilidad de tiempo: Se encarga de evaluar si se cuenta con el tiempo

necesario para la culminación del proyecto desde su planificación hasta la
implementación del mismo. Para identificar si hay o no el tiempo necesario
se suele realizar un cronograma de actividades, el cual contempla las
distintas etapas del proyecto, así como el tiempo máximo para la
terminación de cada una de ellas y la culminación del proyecto como tal.

3.3 MARCO LEGAL

A la hora de desarrollar aplicaciones debemos tener muy en cuenta los aspectos

legales. Haciéndolo podremos evitar sanciones y también proteger nuestra app
y nuestro trabajo como programadores.

Este mercado emergente de las aplicaciones, a diferencia del diseño de páginas

web, parece prestar menos atención a los aspectos legales, muchas veces por
desconocimiento. Los usuarios aceptan la gratuidad de las apps renunciado a la
privacidad y los desarrolladores aceptan carencias y vacíos en la legalidad por
lograr llegar a un público amplio, sin reparar en las futuras repercusiones. Así
como las peculiaridades de hacer la declaración de la renta siendo desarrollador. 

3.3.1 Derechos propios y de terceros

Contar con las respectivas licencias de los recursos que utilicemos es de

primordial importancia, ya sean librerías de programación, bases de datos,
elementos gráficos, melodías, textos, etc. Siempre leer las condiciones para evitar
problemas ya que en algunas ocasiones esos recursos excluyen el uso comercial
y no podríamos utilizarlos en el desarrollo de aplicaciones.

3.3.2 Requisitos legales que debe cumplir una app

1. Permisos, licencia y condiciones de uso. "Hay que ser claros y explícitos a

la hora de solicitar permisos al usuario para acceder a contactos de su
dispositivo, realizar pagos o ceder datos. Además, es obligatorio desarrollar
licencias y condiciones de uso. En todos los casos no basta con informar al
usuario, sino que éste tiene que aceptar, ya que en caso de reclamación
tendremos una mejor defensa", advierten.
2. Derechos propios y de terceros. "Es obligatorio disponer de licencias de los
recursos que se vayan a utilizar. Para ello, hay que leer detenidamente las
condiciones ya que hay casos en los que los recursos excluyen el uso
comercial, no pudiéndose ejecutar en aplicaciones. Además, conviene
proteger el contenido para evitar plagios y copias", aseguran.
3. Menores. "En caso de apps dirigidas a menores de 14 años se deben
consultar las leyes correspondientes y las obligaciones impuestas ya que
 existe una regulación especial en materia de consumidores y usuarios,
protección de datos, derechos de imagen, etc", apuntan.
4. Funcionalidades lícitas. "Al igual que en el marketing tradicional, lo que es
ilícito offline en la App también lo es como, por ejemplo, el estimular un
ámbito de vida poco saludable, como el consumo excesivo de alcohol u
otras sustancias", recomiendan.
5. Privacidad y geolocalización. "La recogida de información del usuario debe
ser la indispensable para el funcionamiento de la App y éste debe tener la
posibilidad de configurar la privacidad. Además, si nuestra aplicación
dispone de geolocalización, se tiene que contar con la aceptación del
usuario para poder acceder a ella", alertan.
6. Información y cookies. "Es fundamental informar al usuario de los aspectos
regulados en la ley y mostrar los datos sobre los creadores y sobre quienes
se encuentra tras la App. También es necesario que el usuario acepte las
cookies, mediante un aviso informativo con la información básica y precisa
sobre las mismas, y los aspectos exigidos por la ley", aseguran.
7. Markets. "Tienen condiciones muy estrictas para que se puedan publicar las
aplicaciones por lo que hay que cumplir siempre lo que piden. De hecho,
incluso cumpliendo las condiciones al colgar la app, éstas pueden cambiar
y hacer que la aplicación no esté disponible para usuarios nuevos. Un
ejemplo que suelen alegar los markets para rechazar una App es que su
interfaz de usuario es compleja o menos que 'muy buena'", recuerdan.
8. Publicidad. "Si monetizas una aplicación a través de publicidad, ésta debe
identificarse siempre como tal", concluyen.