Post on 19-Feb-2021
CONTABILIDAD E INVENTARIO DE LA EMPRESA TELERASTREO
COMUNICACIONES SAS
JUAN DAVID ESCUDERO VARGAS
UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA
INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES
PRÁCTICAS PROFESIONALES
PEREIRA
2010
DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE PARA EL MANEJO DE LA
CONTABILIDAD E INVENTARIO DE LA EMPRESA TELERASTREO
COMUNICACIONES SAS
JUAN DAVID ESCUDERO VARGAS
Informe de Práctica Profesional
Tutor
ANDRÉS FELIPE RODAS USMA
Ingeniero de Sistemas y Telecomunicaciones
UNIVERSIDAD CATÓLICA POPULAR DEL RISARALDA
INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES
PRÁCTICAS PROFESIONALES
PEREIRA
2010
DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE PARA EL MANEJO DE LA
3
CONTENIDO
INTRODUCCION 11
1. PRESENTACIÓN DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA 12
1.1. HISTORIA 12
1.2. MISIÓN 13
1.3. VISIÓN 13
1.4. SERVICIOS QUE PRESTA 13
2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN 15
3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN O IDENTIFICACIÓN
DE LAS NECESIDADES 16
4. EJE DE INTERVENCIÓN 17
5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN 18
6. OBJETIVO GENERAL 19
7. OBJETIVOS ESPECÍFICOS 20
8. REFERENTE CONCEPTUAL 21
8.1. EL SOFTWARE COMO PRODUCTO INDUSTRIAL 21
8.2. QUÉ ES LA INGENIERÍA DEL SOFTWARE 22
8.3. EL CICLO DE VIDA DEL SOFTWARE 23
4
8.4. EL DESARROLLO BASADO EN PROTOTIPOS 24
8.5. EL SERVICIO WEB 25
8.6. RELACIÓN CLIENTE/SERVIDOR 26
8.7. DINAMISMO E INTERACTIVIDAD EN LAS PÁGINAS WEB 27
8.8. MODELO-VISTA-CONTROLADOR 28
8.9. TIPOS DE LENGUAJES DE PROGRAMACIÓN 29
8.10. FRAMEWORK 30
8.11. WICKET 32
8.12. BASES DE DATOS Y EL LENGUAJE SQL 34
9. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS 36
9.1. BASE DE DATOS 36
9.1.1. El Problema 36
9.1.2. La Solución 37
9.2. REPORTES 38
9.2.1. El Problema 38
9.2.2. La Solución 38
9.3. SEGURIDAD 40
9.4. ESCALABILIDAD 40
10. CONCLUSIONES 42
5
11. RECOMENDACIONES 44
11.1. RED LOCAL 44
11.2. INTERNET 45
11.3. SERVIDOR 45
11.4. TALENTO HUMANO 46
11.5. APLICACIONES 46
BIBLIOGRAFÍA 47
APÉNDICES 48
6
Figura 1. Reporte Unidades para Soporte 39
LISTA DE FIGURAS
7
LISTA DE APÉNDICES
Apéndice A. Formulario Órdenes de Instalación 48
Apéndice B. Formulario Órdenes de Soporte 48
8
GLOSARIO
FRAMEWORK: Estructura conceptual y tecnológica de soporte definida,
normalmente con artefactos o módulos de software concretos, con base en la cual
otro proyecto de software puede ser organizado y desarrollado.
SOFWARE: Comprende el conjunto de los componentes lógicos necesarios que
hacen posible la realización de tareas específicas, en contraposición a los
componentes físicos del sistema, llamados hardware.
PROTOTIPOS: Prototipado puede ser un modelo del ciclo de vida del Software, tal
como el desarrollo en espiral o el desarrollo en cascada.
FORMULARIO: Plantilla o página con espacios vacíos que han de ser rellenados
con alguna finalidad.
9
RESUMEN
En el siguiente documento se dará a conocer la forma en la cual se desarrollo el
software para el manejo de la contabilidad, cartera e inventario de la empresa
Telerastreo Comunicaciones SAS.
De igual forma se podrá comprender las metodologías utilizadas en la elaboración
del proyecto y el tiempo pronosticado para el desarrollo del mismo.
También se identificarán los objetivos, con sus respectivas conclusiones y análisis
de resultados, mostrando la secuencia en la cual se avanzó para lograr dichas
metas.
10
ABSTRACT
The following document will be released the way in which developed the software
for managing accounting and inventory for company Telerastreo Comunicaciones
SAS.
Similarly we will understand the methodologies used in developing the project and
the expected weather for the development.
Objectives will also be identified with their respective findings and analysis of
results, showing the sequence in which progress was made to achieve these
goals.
11
INTRODUCCIÓN
En vista a una serie de inconvenientes presentados en la empresa Telerastreo
Comunicaciones SAS, debidos al mal funcionamiento del software que permitía el
manejo del inventario y la contabilidad. Se tomo la decisión de generar uno nuevo
el cual supliera las necesidades de la compañía y además estuviese a la
vanguardia en desarrollos a medida.
Por ende se tomo la decisión de generar una aplicación basada en un framework
de java llamado wicket, que permitiera soportar una aplicación web para a si
unificar los datos de las diferentes sedes de la empresa a nivel nacional.
Para ello se genero un software, el cual podrá ser comprendido al momento de
leer este documento en el que se puede observar entre otras cosas, los
inconvenientes y dificultades que conllevaron a que la empresa, mencionada
anteriormente, tomara la decisión de crear un aplicativo a medida, que lograra unir
todas sus áreas y poder así generar mayor eficiencia en los procesos y a su vez
alcanzar una alta calidad en la prestación de los servicios para el beneficio de
todos sus clientes.
12
1. PRESENTACIÓN DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA
1.1 Historia:
Telerastreo Comunicaciones SAS aparece en Colombia, en 2001.
Inicialmente se creó con el nombre de Ingeniería de Transporte, en 2003
cambio su nombre a Telerastreo Comunicaciones SAS.
Fue fundada en Bogotá por ciudadanos de Santa Rosa de Cabal, por
múltiples motivos, esencialmente logísticos, se traslado su sede principal a
la Ciudad de las Araucarias.
A la fecha Telerastreo Comunicaciones SAS cuenta con sedes en
diferentes ciudades del país, entre las que se encuentran Bogotá, Medellín,
Barranquilla y Cali. Presta servicios a más de 3000 vehículos.
Al ser creada la empresa se pensó como objetivo principal el ser una
compañía especializada en sistemas electrónicos para rastreo y localización
de vehículos hurtados, con productos de alta tecnología y calidad que
respaldan hoy en día el alto porcentaje de recuperación y el excelente
servicio que ofrecemos a nuestros clientes, con soporte técnico permanente
y precios altamente competitivos.
Después de 9 años de experiencia y conocimiento del mercado, la
compañía brinda servicios de seguridad integrados, permitiendo no solo
tener conocimiento sobre el lugar y posición del vehículo, sino también
13
conocer sus niveles de gasolina, posibilidad de un botón de pánico, entre
otros. También ofrece soluciones que se adaptan a las necesidades del
cliente, como saber en qué momento se está cargando su carro o en qué
momento deja sus mercancías, o porque no el momento en que las puertas
se abren. Por esto y por otras razones Telerastreo Comunicaciones SAS es
una empresa líder y competitiva a nivel nacional que pretende seguir
creciendo cada día más.
1.2 Misión:
TELERASTREO COMUNICACIONES SAS, empresa de seguimiento
vehicular satelital, brinda a sus clientes: Seguridad, Confianza y
tranquilidad, a través del sistema de posicionamiento global "GPS", con un
alto compromiso en servicio, calidad y eficiencia.
1.3 Visión:
Vislumbramos a TELERASTREO COMUNICACIONES SAS. en el 2.011,
como una empresa Colombiana, líder en seguridad electrónica y vehicular,
eficiente en logística, como garantía de confianza y tranquilidad para
nuestros clientes.
1.4 Servicios que presta:
Somos una Sociedad orgullosamente Colombiana especializada en
brindar seguimiento de vehículos y carga a través del rastreo satelital,
resultado de la Asociación de Profesionales de diferentes áreas, con
14
amplia experiencia en el campo del transporte en temas como: LOGISTICA,
SEGURIDAD, RENTABILIDAD, MANTENIMIENTO.
15
2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN
La línea que se seguirá en el transcurso de la práctica, será Desarrollo de
Software.
Se determinó ubicarse en esta línea, ya que la labor del practicante es desarrollar
el software contable y de inventario para la empresa, mediante el uso de de bases
de datos en PostgreSQL y del framework Apache Wicket.
Es importante resaltar que a pesar de interactuar con una base de datos, el
practicante no es el directamente encargado de generar el diseño de la misma, ya
que para el caso del software contable la base de datos ya se encontraba
diseñada en su totalidad. En cuanto al software de inventario el jefe inmediato ha
sido el encargado del diseño, sin embargo el practicante pudo intervenir en el
diseño de la última base de datos.
16
LAS NECESIDADES
Al entrar a la empresa se pudo conocer por medio de la persona que realizó la
entrevista al Practicante, que el mayor problema que la compañía estaba
presentando en ese momento era el de contar con un software para el manejo
tanto del inventario como de la contabilidad, el cual no cumplía con las funciones
que la compañía necesitaba que desempeñara, además de su mal
funcionamiento, tampoco se lograba contar con un buen soporte por parte de la
empresa desarrolladora.
Todo este tipo de inconvenientes y molestias, hicieron que en la empresa se
generaran muchos problemas, entre los cuales se pueden mencionar: demora en
la facturación, falta de reportes de contabilidad, problemas en la ubicación de
equipos inventariados y descoordinación entre las diferentes áreas de la empresa.
Por lo anterior, la compañía llego a la conclusión de que se debería hacer un
cambio total en el sistema.
3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN O IDENTIFICACIÓN DE
17
4. EJE DE INTERVENCIÓN
A los problemas anteriormente mencionados se decidió darles una pronta
solución, creando una aplicación con las mismas funciones que inicialmente se
tenía pensado que cumpliría el software contable y de inventarios que hasta el
momento manejaba la empresa, pero mediante el framework de desarrollo
(Wicket) junto al sistema de base de datos (PostgreSQL).
En el periodo de práctica se determinó cumplir con la totalidad del desarrollo de la
aplicación la cual manejará el inventario y la contabilidad de la empresa. En el
caso de la contabilidad se incluirá la facturación del servicio que la empresa
presta.
18
5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN
El desarrollo de la aplicación de inventarios y de contabilidad es requerido por la
empresa para hacer eficiente su continuo desarrollo, ya que un nuevo aplicativo
ajustado a la medida de sus necesidades no retrasará sus procesos, ni generará
interferencia en el desarrollo de las actividades entre las diferentes dependencias
que la constituyen.
La decisión de seleccionar a Wicket como framework de desarrollo, fue debido a
que este cuenta con una serie de cualidades listas para aprovecharse, que
pueden hacer muy robusta la aplicación, lo cual permitirá tener un software
duradero en el tiempo, que no le genere grandes gastos a la empresa a medida
que las aplicaciones deban ser actualizadas.
De igual manera se determinó continuar con PostgreSQL como sistema gestor de
base de datos, ya que se logro detectar que este no presentaba ningún tipo de
problema ni le generaba ningún conflicto al aplicativo anterior y de igual forma no
le generaría ninguno al nuevo.
19
6. OBJETIVO GENERAL
Desarrollar e implementar un software para el manejo del inventario y la
contabilidad de la empresa Telerastreo SAS.
20
7. OBJETIVOS ESPECÍFICOS
Analizar en el transcurso del primer mes las diferentes necesidades de la
empresa y sus posibles soluciones.
Interactuar durante los 5 meses de la práctica, con las diferentes áreas de la
empresa con el fin de establecer fallas presentes en el software anterior, y así
lograr evitarlas en el nuevo.
Aportar en un 30 o 50 % en el diseño de la base de datos utilizada para el
manejo de inventario de la empresa.
Crear en el transcurso de los dos primeros meses el aplicativo para el manejo
del inventario.
Desarrollar el 100 % de la aplicación (Inventario y Contabilidad Telerastreo)
basado en una metodología de programación (Basada en Prototipos), para así
lograr satisfacer las diferentes necesidades de la empresa.
En los últimos tres meses de la práctica se desarrollará el software que
gestionará la base de datos de contabilidad ya diseñada.
21
8. REFERENTE CONCEPTUAL
Para entrar en contexto con el desarrollo de la aplicación de la empresa
Telerastreo Comunicaciones S.A.S, se hablará de algunos temas puntuales los
cuales ayudaran a entender mejor los que se desea realizar.
8.1 El software como producto industrial
Como todos pueden saber, un software no se realiza en una empresa por lujo,
sino para generar mayor productividad y mejor desempeño laboral, esto se puede
entender mejor en las palabras de Benet Campderrich, “Un software no es una
obra de arte, sino un producto de consumo utilitario y masivo; para una empresa o
trabajador autónomo, el software es un medio auxiliar que interviene de manera
más o menos indirecta, pero a menudo imprescindible, en su gestión y cada vez
más en su proceso productivo; también existe, como todos sabemos, un consumo
privado de software”1.
1 CAMPDERRICH FALGUERAS, Benet. Ingeniería del software. Barcelona: Editorial UOC, 2003. p. 16.
22
8.2 Qué es la ingeniería del software
Para comprender mejor el porqué de realizar ingeniería del software a un producto
es importante tener en cuenta los conceptos dados por algunos autores como por
ejemplo Benet Campderrich2, que en su obra inicialmente explica que un software
es un conjunto integrado de programas que en su forma definitiva se pueden
ejecutar, pero a su vez habla de la importancia de relacionar este software con un
conjunto de datos lo cual es más fácil de comprender realizando una
documentación clara, lo que al final de cuentas es practicar la ingeniería del
software.
De igual forma se puede comprender en si lo que se termina realizando con la
ingeniería del software tomando de nuevo la definición dada por Campderrich:
En general, a cada tipo de producto industrial corresponde un tipo de
ingeniería, entendida como el conjunto de métodos, técnicas y
herramientas que se utilizan tanto para desarrollar el producto como
para fabricarlo.
Una técnica es la manera preestablecida en la que se lleva a termino
un paso en la elaboración del producto, un método es una manera
determinada de aplicar varias técnicas sucesivamente y una
herramienta es un instrumento de cualquier tipo que se utiliza en la
aplicación de una técnica.
El software no es ninguna excepción a esta regla, y, por tanto, hay
una ingeniería del software que comprende las técnicas, métodos y
herramientas que se utilizan para producirlo.
2 Ibíd., p. 15.
23
En el caso de la ingeniería del software no se suele hablar de
ingeniería de proceso; quizá se podría pensar que es la que hace
referencia a la programación en sentido estricto, pero cada vez es
menos nítida la distinción entre la programación y las fases
anteriores en el desarrollo de software.3
8.3 El ciclo de vida del software
Siguiendo el camino mostrado por la ingeniería del software se puede entrar a
observar el desarrollo y la vida que debe tener un software para ello se sigue
tomando las palabras de Benet Campderrich que con su obra Ingeniería del
Software, permite aclarar toda una serie de conceptos que giran en torno a este
tema:
La producción de software es algo más que la programación; hay
etapas que la preceden y otras que la siguen.
El ciclo de vida del software está constituido por el conjunto de todas
estas etapas. Los métodos y técnicas de la ingeniería del software se
inscriben dentro del marco delimitado por el ciclo de vida del
software, y, más concretamente, por las diferentes etapas que se
distinguen.
La misma existencia de distintos modelos del ciclo de vida del
software hace comprender que no hay ninguno que sea ideal o que
no tenga grandes limitaciones.
3 Ibíd., p. 17.
24
Sin embargo, es indispensable que todo proyecto se desarrolle
dentro del marco de un ciclo de vida claramente definido, si se quiere
tener una mínima garantía de cumplimiento de los plazos, respetar
los límites de los recursos asignados. Además, la garantía de calidad
y las certificaciones de calidad también presuponen que el proceso
de producción de software se desarrolle según un ciclo de vida con
etapas bien definidas.4
8.4 El desarrollo basado en prototipos
Para entrar más a fondo del desarrollo que se pretende realizar en la empresa
Telerastreo Comunicaciones S.A.S, se observaran los términos relacionados con
el modelo seleccionado para desarrollar esta aplicación, el cual fue „El desarrollo
basado en prototipos‟. Que permite un desarrollo más rápido y con mejores
resultados, gracias a su constante prueba y por ende mayor evolución. Pero para
observar mejor las bondades otorgadas por este modelo, se citaran las palabras
plasmadas por Teresa Freire en su libro “Dirección y gestión de los sistemas de
información en la empresa”:
Los desarrollos de sistemas mediante el ciclo de vida basado en
prototipos se fundamenta en la elaboración de sucesivos modelos del
sistema o prototipos que se van perfeccionando mediante la
evaluación por parte de los usuarios.
Algunos de los aspectos que caracterizan esta metodología son:
4 Ibíd., p. 19.
25
- La posibilidad de realizar fases de forma paralela con lo que se
aprovecha mejor los tiempos.
- Los fallos o errores se detectan de manera planeada y más
rápidamente gracias a la repetición de las pruebas y el refinamiento.
El método, consiste en la iteración de las fases del ciclo de vida del
sistema. En el primer paso se crea un prototipo inicial que tenga en
cuenta todos los requerimientos aunque no tenga todas las
funcionalidades. Después los usuarios trabajan con esa primera
muestra del sistema y vuelven a especificar necesidades o mejoras
que sirven para revisar y mejorar el prototipo. El procedimiento
iterativo finaliza con la obtención del prototipo último que no requiere
mejoras.5
8.5 El servicio Web
Una de las herramientas que permiten realizar una aplicación multiusuario, es el
servidor web, el cual tiene mayores funcionalidades de las que se conocen como
lo muestra Gonzalo Cuevas:
El servicio WWW, o simplemente Web, se podría definir como un
amplio sistema multimedia de acceso a información heterogénea
distribuida por toda la red en forma de documentos hipertextuales.
Como ya fue comentado, este servicio surgió en 1990 en el CERN
con el objetivo de facilitar la distribución de información entre equipos
investigadores geográficamente dispersos. Se buscaba que los
5 FREIRE RUBIO, Teresa. Dirección y gestión de los sistemas de información en la empresa. España: Esic Editorial, 2008.
p. 163.
26
recursos disponibles en formato electrónico fuesen accesibles para
cada investigador desde su propia terminal de forma clara y simple,
posibilitando el salto entre elementos de información conexos. En
definitiva, se trataba de integrar todos los recursos existentes en una
red hipertextual.6
8.6 Relación cliente/servidor
Así mismo se debe comprender la forma como el cliente (o el usuario final),
interactúa con el servidor que en este caso es un servidor web. Para permitir un
mejor entendimiento de este término se tratara de dividir los conceptos en cliente
y servidor, para ello se citará a Ángel Cobo:
- Servidores: ordenadores que ofrecen sus servicios al resto de
equipos conectados. Suelen tener una presencia estable en la red, lo
que se concreta en tener asignadas direcciones IP permanentes. En
ellos es donde están alojadas, por ejemplo, las páginas web.
- Clientes: equipos que los usuarios individuales utilizan para
conectarse a la red y solicitar servicios a los servidores. Durante el
tiempo de conexión tienen presencia física en la red. Normalmente
los proveedores de acceso a Internet asignan a estos equipos una
6 CUEVAS AGUSTÍN, Gonzalo. Gestión del proceso software. España: Editorial Centro de Estudios Ramón Areces, 2002.
p. 124.
27
dirección IP durante su conexión, pero esa dirección es variable, es
decir, cambia de unas conexiones a otras (IP dinámica).7
8.7 Dinamismo e interactividad en las páginas web
Siguiendo con la terminología relacionada con el tema de los servidores web, se
hablara en este caso de cómo se logra que el cliente pueda interactuar con la
aplicación, es decir, la manipulación que el empleado en este caso de Telerastreo,
le hará a los diferentes datos que el software le provea, para entrar en una análisis
más profundo del dinamismo y la interactividad en la páginas web se tomaran las
palabras de Ángel Cobo:
HTML es un lenguaje puramente descriptivo que permite definir las
páginas web pero que en modo alguno se puede considerar un
lenguaje de programación. Con HTML no se pueden generar
estructuras iterativas o condicionales, no se pueden definir funciones
que sean utilizadas en distintos puntos del documento, no se pueden
declarar variables, no se pueden realizar cálculos matemáticos,…
Las páginas creadas únicamente con HTML son básicamente
estáticas, es decir, siempre muestran la misma información y no
ofrecen ningún grado de interactividad con el usuario. Los únicos
elementos de HTML que podrían de alguna forma considerarse
interactivos son los formularios a través de los cuales se solicita
información al usuario.
7 COBO, Ángel; GÓMEZ, Patricia; PÉREZ, Daniel. PHP y MySQL- tecnologías para el desarrollo de aplicaciones web.
España: Díaz de Santos, 2005. p. 5.
28
Si se requiere aumentar el dinamismo e interactividad de las páginas
se hace por tanto obligado el recurrir a otros lenguajes y tecnologías.
Esas dos características: dinamismo e interactividad son los dos
elementos clave que se deben tratar de potenciar para desarrollar
verdaderas aplicaciones web.8
8.8 Modelo-vista-controlador
Después de haberse hablado de todo lo relacionado con el diseño y la
documentación del software, se hablará de la herramienta y el método utilizado
para el desarrollo de la aplicación. En primera instancia se hablara de modelo-
vista-controlador, el cual permite tener un desarrollo independiente, pero que en
su conjunto hacen una solo y muy potente. Pero esto lo mostrará más claro el
autor Douglas Bell:
La tarea principal de un programa orientado a objetos es modelar la
aplicación de interés. Un modelo o simulación de una aplicación no
es suficiente, sería sorda, ciega y tonta. Se necesita una manera de
conectar el modelo con su usuario. En el objeto globo, hay números
que representan su posición y tamaño, pero son simplemente
patrones de bits invisibles dentro de la memoria de la computadora.
Necesitamos una manera de controlar un globo, alterar su posición y
tamaño (a esto le llamamos el controlador) y una manera de
mostrarlo en la ventana (a esto le llamamos la vista). Si escribimos
software para representar un automóvil, necesitamos un modelo del
motor y su transmisión. Este modelo sería invisible. Lo visible serían
8 Ibíd., p. 8.
29
los instrumentos que nos indican lo que el automóvil está haciendo
(la vista) y los controles que permiten al usuario alterar lo que está
sucediendo (el controlador).9
8.9 Tipos de lenguajes de programación
En el mundo del desarrollo existen muchos tipos de lenguajes de programación,
para contextualizar un poco se mostraran algunos de ellos, citados del libro “PHP
y MySQL- tecnologías para el desarrollo de aplicaciones web”, de una serie de
autores entre los que se encuentra Ángel Cobo:
Los lenguajes de programación pueden ser clasificados de acuerdo a
varios criterios. Una de las primeras clasificaciones que se suele
efectuar es la distinción entre lenguajes de bajo nivel y de alto nivel.
La programación en los primeros resulta más dificultosa puesto que
las instrucciones están muy próximas al hardware del equipo y
resultan difíciles de entender por un programador no especialista. El
ejemplo clásico de lenguaje de bajo nivel es el lenguaje
ensamblador.
La mayor parte de los programadores optan por utilizar lenguajes
cuyo código resulta más fácil de entender, por cuanto sus reglas
sintácticas se asemejan más a la forma de comunicarse las
personas; son lenguajes que están “más cerca” del programador
pero más lejos de la maquina a la que van dirigidos. Estos lenguajes
9 BELL, Douglas; PARR, Mike. Java para estudiantes. México: Pearson Educación, 2003. p. 174.
30
son los denominados “lenguajes de alto nivel” y a ellos pertenecen
los lenguajes de programación más conocidos.
Cuando se está desarrollando un programa usando un lenguaje de
programación se genera un código (código fuente) que es
comprensible para todo aquel usuario que tenga los conocimientos
suficientes sobre el correspondiente lenguaje, pero que en ningún
caso es comprensible directamente para la máquina. Los
ordenadores trabajan internamente mediante circuitos electrónicos
que admiten dos posiciones: abierto o cerrado (1 ó 0) y por tanto,
toda orden a dar a la máquina debe ser planteada en última instancia
como secuencias de ceros y unos (código binario). Parece claro por
tanto que se necesita un proceso de “traducción” del código fuente
que nosotros entendemos a instrucciones entendibles por la
máquina.10
8.10 Framework
Siguiendo con el tema de las herramientas para el desarrollo, se explicará el
significado de “framework”, el cual permitirá comprender mejor el porqué la
elección de una herramienta como Wicket. El siguiente significado fue tomado de
la página web jordisan.net:
Un Framework es un esquema (un esqueleto, un patrón) para el
desarrollo y/o la implementación de una aplicación. Sí, es una
definición muy genérica, pero también puede serlo un framework: sin
10
COBO, op. cit., p. 11.
31
ir más lejos, el paradigma MVC (Model-View-Controller) dice poco
más que "separa en tu aplicación la gestión de los datos, las
operaciones, y la presentación". En el otro extremo, otros frameworks
pueden llegar al detalle de definir los nombres de ficheros, su
estructura, las convenciones de programación, etc.
Pongamos un ejemplo: una aplicación web que utilice Java como
lenguaje de programación puede implementarse de multitud de
formas, mediante servlets y JSPs. Hay algunas convenciones que es
necesario seguir, como usar un fichero de configuración web.xml,
pero el programador sigue sin tener un patrón claro a seguir para la
creación de servlets, clases, JSPs, etc.
En una primera estandarización, la utilización de una arquitectura
MVC aconseja que separemos la lógica de la aplicación (en los
servlets) de la presentación (usando JSPs); en concreto, no sería
correcto codificar lógica de aplicación o accesos a base de datos
dentro de los JSP.
Un paso más allá: utilizando Faces como framework, la estructura de
la aplicación queda todavía más definida: un único servlet
(FacesServlet) va a controlar el flujo de la aplicación; además, el uso
de un fichero concreto (faces-config.xml) permite crear la navegación
de la aplicación, definir los objetos (beans) pasados como
parámetros, etc., todo ello sin necesidad de codificarlo en Java o
JSP.
Los frameworks no necesariamente están ligados a un lenguaje
concreto, aunque sea así en muchas ocasiones. En el cada vez más
popular Ruby on Rails, 'Ruby' es el lenguaje de programación y
32
'Rails' el framework; por otro lado, JavaServer Faces está orientado a
desarrollos en Java. Sin embargo, nada impide definir el mismo
framework para lenguajes diferentes: por ejemplo, existe un
framework llamado Biscuit cuyo objetivo es prácticamente convertirse
en un "PHP on Rails". Eso sí, cuanto más detallado es el framework,
más necesidad tendrá de ceñirse a un lenguaje concreto.
También es posible que el framework defina una estructura para una
aplicación completa, o bien sólo se centre en un aspecto de ella.
Siguiendo con los ejemplos, Ruby on Rails ofrece un marco para el
desarrollo completo de una aplicación web, mientras que JavaServer
Faces está más orientado a la interfaz de usuario.11
8.11 Wicket
Ahora que ya se introducido el significado de “framework” con sus respectivas
características y funcionalidades, se entrara a hablar del escogido para el
desarrollo en la empresa Telerastreo Comunicaciones S.A.S, el cual es el wicket.
Para poder brindar una definición clara, se optó por tomar la definición dada por la
página web del creador de la herramienta Apache:
Apache Wicket, comúnmente conocido como Wicket, es un
componente de peso ligero marco basado en aplicaciones web para
el lenguaje de programación Java conceptualmente similares a
JavaServer Faces y Tapestry.
11
Jordisan. (29 de Septiembre de 2006). Recuperado el 23 de Marzo de 2010, de Blog Jordisan: http://jordisan.net/blog/2006/que-es-un-framework
http://biscuitproject.tigris.org/
33
Trabaja con marcos MVC en términos de solicitudes y páginas
enteras. En cada ciclo de petición, la solicitud entrante se asigna a un
método en un objeto de controlador, el cual genera la respuesta de
salida en su totalidad, por lo general, tirando datos de un modelo
para rellenar la plantilla de la vista. Esto mantiene el flujo de la
aplicación de un control sencillo y claro, pero puede hacer que la
reutilización de código en el controlador sea difícil.
Wicket usa XHTML (que impone una clara separación de la
presentación y la lógica y permite que las plantillas puedan ser
editadas con las herramientas convencionales de diseño
WYSIWYG). Cada componente está unido a un elemento llamado en
el XHTML y se convierte en responsable de la prestación de ese
elemento en el producto final. La página es simplemente la del nivel
superior que contenga los componentes y se empareja con
exactamente una plantilla XHTML. Las partes reutilizables de las
páginas se pueden abstraer en componentes llamados paneles, que
luego se puede tirar todo en las páginas o de otros grupos con una
etiqueta especial.
Cada componente es respaldado por su propio modelo, que
representa el estado del componente. El marco no tiene
conocimiento de cómo los componentes interactúan con sus
modelos, que son tratados como objetos opacos de forma automática
en serie y persistente entre peticiones. Los modelos más complejos,
puede ser desmontables y proporcionar ganchos para organizar su
34
propio almacenamiento y restauración al principio y al final de cada
ciclo de petición. 12
8.12 Bases de datos y el lenguaje SQL
Por último y tal vez uno de los puntos más críticos en el desarrollo de una
aplicación, se platicara acerca de Bases de datos, el cual termina siendo el
objetivo de la creación de una aplicación, es decir, el permitir que una serie de
usuarios puedan manipular de una forma más clara y eficiente una serie de datos,
pero se puede ver mejor y comprender en la palabras Cobo:
Las bases de datos constituyen hoy en día los elementos clave sobre
los que se apoyan los sistemas de información de empresas e
instituciones. Una base de datos podría definirse como una colección
de datos interrelacionados que son almacenados en un soporte
informático. Algunas razones que justifican su uso son su capacidad
para almacenar grandes volúmenes de información, la optimización
de su gestión, la facilidad para realizar consultas y la exactitud,
rapidez y fiabilidad en su administración.
Aunque en ocasiones son términos que se confunden, a la hora de
hablar de las bases de datos debe distinguirse lo que es propiamente
la información almacenada (datos, restricciones y relaciones) y el
conjunto de programas que actúan de intermediarios entre la
12
Wicket. (29 de Septiembre de 2006). Recuperado el 23 de Marzo de 2010, de Blog Wicket: http://cwiki.apache.org/WICKET/
35
información y el usuario (SGBD: Sistema Gestor de Bases de
Datos).13
13
COBO, op. cit., p. 309.
36
9. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS
A continuación se darán a conocer los resultados alcanzados durante el proceso
de práctica profesional y su respectivo análisis, los cuales se demostrarán por
medio de un comparativo, entre la aplicación que se encontró él practicante al
momento de llegar a la empresa, y la desarrollada por el estudiante en el
transcurso de estos 5 meses.
9.1. Base de Datos
Al llegar a la empresa se pudo observar que se tenía un gran inconveniente en el
manejo de sus bases de datos.
El problema era que se tenía por cada sede una base de datos. Pero además de
estas se contaba con otra base de datos (En la sede Principal), en la cual se
almacenaba todo lo que ya se había guardado en la BD local de cada sede. Todo
esto conllevaba no solo a una fuerte duplicación de datos, sino también a un
problema con la lógica de los mismos, generada por la misma inconsistencia de la
aplicación.
Para muestra de estos inconvenientes se da un ejemplo: en algunas ocasiones los
empleados de la sede de Barranquilla se encontraban ingresando datos en su BD
9.1.1 El Problema
37
local y por ende en la Principal, por una u otra razón, el internet colapsaba
generando así una falta de comunicación entre la sede Barranquilla y la sede
Principal. A pesar de esta falta de comunicación, los datos se seguían guardando
en la BD local, pero en la principal no, lo que generaba una inconsistencia en los
datos almacenados localmente y los guardados en la principal.
Para dar solución a la problemática de la duplicación de datos, se optó en primer
lugar en crear una única Base de Datos, localizada en la sede Principal, que
distinguiera los datos pertinentes a cada sede, lo cual evita la perdida de datos en
un momento determinado, y a su vez permite tener un mayor control y una
facilidad en la manera en la cual se administra.
De igual manera se pensó que la solución total a la problemática no era solo esta,
sino también crear una aplicación Web que permitiera el acceso a los datos en
cualquier parte, sin necesidad de tener una previa instalación en los PCs de cada
sede y a su vez tener un control de los usuarios que ingresan a la misma.
Tomando como base el ejemplo anterior, se pueden demostrar beneficios
generados por la forma en la cual se manejan ahora los datos.
En primer lugar, en el momento en que los empleados de otra sede estuvieren
ingresando datos en la aplicación, y esta sufriera un colapso por falta de internet,
debido a que la aplicación es web, no se podrán ingresar más datos, lo que evitará
una inconsistencia en los mismos.
9.1.2 La Solución
38
Pero se puede dar el caso en que el ingreso de estos datos es urgente, lo cual se
puede solucionar ingresando a la aplicación desde cualquier parte con acceso a
internet, sin necesidad de realizar ningún tipo de instalación.
9.2 Reportes
Se logró observar que la aplicación anterior no generaba reportes consistentes o
que definitivamente no eran generados. Lo que llevaba a un mal manejo del
inventario.
El problema generado por la falta de estos reportes, se podía observar al
momento de realizarse una instalación a un vehículo, ya que el encargado de
despachar el producto, consultaba inicialmente en la aplicación la disponibilidad
del mismo para así realizar una salida de almacén, pero cuando se buscaba el
producto en la respectiva sede este no se encontraba, lo que impedía la
instalación.
Al ver todos estos problemas, la compañía opto por seguir llevando un inventario
paralelo en Excel, lo que no solo llevaba más tiempo, sino también menos
aprovechamiento de los recursos disponibles.
En la nueva aplicación los usuarios se podrán encontrar con un generador de
reportes fácil de manejar, y sobre todo muy consistente.
9.2.1 El Problema
9.2.2 La Solución
39
En la Figura 1. Se podrá observar la forma en la cual la aplicación arroja sus
resultados en formato PDF.
Como se puede observar los reportes son entregados de una forma ordenada por
sede y según sus características (Con SIM o Sin SIM).
Para la generación de estos reportes sé trabaja con las librerías del
JasperReports, y se diseñan en la aplicación llamada Ireports.
En general los reportes arrojados por la aplicación llevan la misma metodología
variando lo que se consulte. Dicha mejora estará ahorrándole a un empleado
hasta medio día de trabajo, que se debía desperdiciar en esta labor propia de un
aplicativo que gestiona el manejo del inventario.
De igual forma los reportes beneficiaran a todas las dependencias de las cuales,
según sus necesidades, debían consultar la capacidad en materia de equipos de
la empresa.
Figura 1. Reporte Unidades para Soporte
40
9.3 Seguridad
Con respecto a la seguridad se puede decir que es uno de los valores agregados
de la nueva aplicación. Gracias a la forma en la cual fue estructurada y planeada.
No solo su lógica como tal, sino también el manejo que se le da a sus datos.
En este caso se puede observar que los datos, tendrán mayor protección ya que
se controlaran desde una sede, lo que permite a la compañía crear condiciones
optimas para el manejo de los servidores. Mientras que la forma en la cual eran
manejados los datos anteriormente, acarreaba un gasto muy grande para la
protección de cada BD local, lo que impedía su completo desarrollo.
De igual forma se puede observar que la administración de la BD será realizada
por una persona idónea en el tema, quien tendrá la responsabilidad de protegerla,
lo cual no se podía realizar con una base de datos por sede ya que los empleados
podrían manipular los datos a su conveniencia.
A su vez se tendrá control sobre el ingreso a la aplicación mediante los
respectivos tiempos de sesión y con el bloqueo de usuarios, si fuese necesario.
9.4 Escalabilidad
Gracias al diseño de la aplicación, se podrá contar con un software que no solo
cumpla las funciones inicialmente deseadas, sino que podrá también evolucionar
con la creación de nuevos módulos, según la necesidad de la empresa.
Para explicar esto, se dará un ejemplo de un nuevo módulo que la empresa desea
implementar a futuro: este es el caso de un sistema que permita la gestión de
41
quejas y reclamos de los clientes. El cual se podrá integrar fácilmente a la nueva
aplicación.
Con este nuevo modulo se pretende dar seguimiento al usuario como tal, logrando
un desarrollo y una mejora sustancial en la prestación del servicio.
Pero ¿Por qué es importante unir este modulo a la aplicación y no mejor crear una
nueva aplicación? Esto se debe a que cada queja ira asociada a una placa con
sus respectiva unidad satelital, las cuales ya deben estar ingresadas al inventario.
Lo mencionado conlleva a un control sobre el correcto funcionamiento de la
unidad, su vida útil y hasta la garantía que esta pueda tener por parte de la
empresa con el cliente y de igual manera del proveedor con la empresa.
También se dice que la aplicación es escalable, ya que al iniciar su desarrollo se
pensó en lograr una unión entre la aplicación y el sistema que permite el manejo
de la ubicación de los vehículos, para lo cual se necesita una integración de los
datos que estas manejan. Por ende se debe pensar que no solo la aplicación
permite escalabilidad, sino también su base de datos.
42
10. CONCLUSIONES
Se pudo llegar a la conclusión, basándose en la observación y entrevista
con los empleados, que la empresa Telerastreo Comunicaciones S.A.S,
presentaba como principal necesidad, el reemplazo de la aplicación con la
cual trabajó durante los últimos 2 años. La anterior aplicación no le
proporcionaba las herramientas necesarias para el manejo e interacción de
todas sus dependencias. Por expuesto anteriormente, se determinó crear
una nueva aplicación, la cual crezca a la par con el desarrollo diario de
Telerastreo.
Después de la interacción con las diferentes áreas de la empresa durante el
tiempo de práctica, se pudo determinar que la principal mejora que deberá
tener la nueva aplicación con respecto a la anterior, son los reportes, como
los del inventario disponible o los referentes a la contabilidad de la
empresa. Así mismo se pudo concluir que el manejo dado al inventario
debe ser renovado, y tener la capacidad de controlarlo en el 95% en el
software nuevo.
Dado que al momento del practicante ingresar a la empresa, ya se estaba
desarrollando la nueva aplicación, la intervención al diseño de la base de
datos no pudo ser del 100%. Sin embargo se puede concluir que se
participó en el desarrollo del 50% final y del respectivo análisis del 50% ya
diseñado.
43
Según el cronograma planteado al inicio de la práctica, el tiempo propuesto
para el desarrollo del modulo de inventario era de 2 meses, pero este
término siendo de un mes y medio lo que permitió la interacción con el
modulo contable antes de lo previsto. Por lo anteriormente mencionado se
puede llegar a la conclusión que, el cronograma planteado fue cumplido en
su totalidad, sin ningún tipo de retraso y con algún tiempo sobrante para la
ejecución de algunos proyectos de menor tamaño, solicitados por la
empresa.
Como se mencionó anteriormente, la aplicación fue desarrollada en dos
módulos separados, los cuales son inventario y contabilidad. En los dos
casos la metodología fue la misma y se puede concluir que fue manejada
de manera correcta y eficaz, ya que en primer lugar se entregaron dos
prototipos del modulo de inventario con los cuales se logro determinar los
inconvenientes y problemas presentes en el mismo, para así realizar una
tercera entrega definitiva. Para la parte contable, se debieron entregar 4
prototipos, puesto que este era el modulo mas critico y con mayor robustez
del aplicativo, al final la quinta entrega fue la definitiva.
Según se puede observar con anterioridad, el tiempo tomado en el
desarrollo de la aplicación fue menor al esperado, lo cual conllevo a que el
tiempo necesario para el desarrollo del modulo contable, fuese de dos
meses y medio. Se puede concluir que en algunos casos no se toma en
consideración todas las variables para el desarrollo de un cronograma, lo
cual puede generar retrasos o como se puede ver en este caso adelantos,
que en algún momento pueden afectar o favorecer el valor de un proyecto
determinado.
44
11. RECOMENDACIONES
Gracias a que se realizó un muy buen trabajo durante el periodo de práctica, los
problemas presentados por la empresa fueron resueltos en un 98%. A pesar del
éxito logrado para que estas soluciones funcionen correctamente y durante mucho
tiempo, se deben tener en cuenta algunas recomendaciones:
11.1. Red Local
Se debe comprender que la aplicación entregada a la empresa Telerastreo
Comunicaciones S.A.S, es web, por ende la red de la empresa debe estar muy
bien constituida, ya que por ella viajará un flujo alto de información. Como medida,
deben aplicarse estándares básicos para que no se generen problemas, como por
ejemplo cuellos de botella.
De igual forma se debe tener en cuenta que a futuro se planea instalar un servidor
Asterisk para todo el manejo de la telefonía sobre IP, lo que a su vez hará que el
flujo de información que viaja por la red se mucho más alto impidiendo de esta
manera el correcto funcionamiento de la aplicación.
45
11.2. Internet
Así como se debe tener en cuenta el manejo de la red interna, también se debe
recordar que el acceso a la aplicación, por parte de las sedes a nivel nacional, se
realizara vía Internet; lo que conlleva a tener en cada una de las sedes y en la
principal un ancho de banda lo suficientemente grande para soportar el constante
flujo de información. Además de lo anterior es necesario garantizar la
disponibilidad casi en un 95%, ya que la mayoría de los procesos gira en torno a la
aplicación.
11.3. Servidor
En el caso del servidor es muy importante tener presente el consumo de recursos,
puesto que por ejemplo el Tomcat 14, en conjunción con un framework como el
Wicket y con un gestor de bases de datos como el Postgres, hacen uso intensivo
especialmente de memoria.
Así mismo se debe comprender que la base de datos se manejará en este
servidor, y que como medida se deberá aplicar una política de seguridad, en la
que se estipule la forma en la que se deben realizar los backups, como se
almacenarán y demás precauciones que se deben de tener con las herramientas
que terminan siendo el pilar de la compañía.
14
Tomcat (también llamado Jakarta Tomcat o Apache Tomcat) funciona como un contenedor de servlets desarrollado bajo el proyecto Jakarta en la Apache Software Foundation.
http://es.wikipedia.org/wiki/Servletshttp://es.wikipedia.org/w/index.php?title=Proyecto_Jakarta&action=edit&redlink=1http://es.wikipedia.org/wiki/Apache_Software_Foundation
46
11.4 Talento Humano
Una de las principales causas del mal funcionamiento de una aplicación, es el mal
uso que se le da por parte de los empleados. Para ello se recomienda realizar
constantes capacitaciones que permitan al personal comprender el funcionamiento
de la aplicación.
De igual forma es importante crear políticas de seguridad, que impidan la
propagación de virus o la congestión de la red local o del ancho de banda del
internet.
11.5 Aplicación
Si bien la aplicación queda funcionando en su totalidad, es importante que se
estén revisando las necesidades que cada día se presentan en una empresa
como Teleresatreo, con el fin de realizar las actualizaciones pertinentes y no dejar
que el software se vuelva obsoleto. De esta forma se podrá tener un sistema que
integra todas las dependencias de la compañía y que a su vez esta a la
vanguardia de los nuevas necesidades que el mercado exija.
47
BIBLIOGRAFÍA
CAMPDERRICH FALGUERAS, Benet. Ingeniería del software. Barcelona:
Editorial UOC, 2003.
FREIRE RUBIO, Teresa. Dirección y gestión de los sistemas de información
en la empresa. España: Esic Editorial, 2008.
CUEVAS AGUSTÍN, Gonzalo. Gestión del proceso software. España:
Editorial Centro de Estudios Ramón Areces, 2002.
COBO, Ángel; GÓMEZ, Patricia; PÉREZ, Daniel. PHP y MySQL-
tecnologías para el desarrollo de aplicaciones web. España: Díaz de
Santos, 2005.
BELL, Douglas; PARR, Mike. Java para estudiantes. México: Pearson
Educación, 2003.
Jordisan. (29 de Septiembre de 2006). Recuperado el 23 de Marzo de
2010, de Blog Jordisan: http://jordisan.net/blog/2006/que-es-un-framework
Wicket. (29 de Septiembre de 2006). Recuperado el 23 de Marzo de 2010,
de Blog Wicket: http://cwiki.apache.org/WICKET/
48
APÉNDICES
Apéndice A. Formulario Órdenes de Instalación
Apéndice B. Formulario Órdenes de Soporte
CUBIERTAPORTADACONTENIDO LISTA DE FIGURASLISTA DE APÉNDICESGLOSARIORESUMENABSTRACTINTRODUCCIÓN 1. PRESENTACIÓN DE LA ORGANIZACIÓN O SITIO DE PRÁCTICA 1.1 Historia: 1.2 Misión: 1.3 Visión: 1.4 Servicios que presta:
2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN 3. DIAGNÓSTICO DEL ÁREA DE INTERVENCIÓN O IDENTIFICACIÓN DE LAS NECESIDADES4. EJE DE INTERVENCIÓN 5. JUSTIFICACIÓN DEL EJE DE INTERVENCIÓN 6. OBJETIVO GENERAL 7. OBJETIVOS ESPECÍFICOS 8. REFERENTE CONCEPTUAL 8.1 El software como producto industrial 8.2 Qué es la ingeniería del software 8.3 El ciclo de vida del software 8.4 El desarrollo basado en prototipos 8.5 El servicio Web 8.6 Relación cliente/servidor 8.7 Dinamismo e interactividad en las páginas web 8.8 Modelo-vista-controlador 8.9 Tipos de lenguajes de programación 8.10 Framework 8.11 Wicket 8.12 Bases de datos y el lenguaje SQL
9. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS 9.1. Base de Datos 9.1.1 El Problema 9.1.2 La Solución
9.2 Reportes 9.2.1 El Problema 9.2.2 La Solución
9.3 Seguridad 9.4 Escalabilidad
10. CONCLUSIONES 11. RECOMENDACIONES 11.1. Red Local 11.2. Internet 11.3. Servidor 11.4 Talento Humano 11.5 Aplicación
BIBLIOGRAFÍA LISTA DE FIGURAS Figura 1. Reporte Unidades para Soporte
APÉNDICES Apéndice A. Formulario Órdenes de Instalación Apéndice B. Formulario Órdenes de Soporte