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