Vous êtes sur la page 1sur 23

Desarrollo de una aplicación

web utilizando PHP

TITULACIÓN: Ingeniería Técnica en Informática de Gestión

Autor: Aleix Royo Obregón


Tutor URV: M.Àngels Moncusí
Tutor Empresa: Jordi Compte

Fecha: Junio 2012

1
Agradecimientos

Agradecer tanto al jefe de la empresa como a los jefes de proyecto respectivamente el


apoyo y la confianza demostrada durante este tiempo y a mis compañeros de trabajo,
diseño y comercialización sin los cuáles no hubiéramos podido llegar tan lejos.

2
Índice
1. Descripción de la empresa ..................................................................... 4
2. Ubicación del proyectante dentro de la empresa ................................... 5
3. Descripción del trabajo realizado ........................................................... 7
3.1. Objetivos del proyecto ..................................................................... 7
3.2. Especificaciones del proyecto .......................................................... 7
3.3. Diseño .............................................................................................. 8
3.4. Desarrollo ........................................................................................ 9
3.5. Evaluación ...................................................................................... 17
3.6. Recursos utilizados ......................................................................... 19
4. Aportaciones del proyecto a los conocimientos del alumno................. 20
5. Aportaciones de los estudios realizados al proyecto ............................ 21
6. Conclusiones ........................................................................................ 22

3
1. Descripción de la empresa

SMARTOXIDE, SL nace en el 2008 con la idea de que se puedan generar productos de


calidad de base tecnológica dentro de nuestro territorio y con el objetivo de ser una
puerta más para todos los ingenieros en el sector de la informática y la electrónica.

Como sectores importantes dónde se desarrollan productos y se ofrecen servicios hay


la telefonía móvil, la domótica en distintos ámbitos, las soluciones Linux, el diseño de
hardware y la consultora general. Esta iniciativa empresarial mereció el primer premio
del “Concurs Tàrraco Empresa Jove 2007” y fue finalista en los” IV Premis Reus a la
Creació d’Empreses 2007”.

En los últimos meses ha surgido de ella “IgnicioLabs”, cuya finalidad es la de actuar


como acelerador de negocios entre el talento universitario y los empresarios
proporcionando un espacio de trabajo en equipo para diferentes colaboradores del
sectores fomentando de esta forma la colaboración y el trabajo en equipo.

“IgnicioLabs” se ha creado a principios del 2012 y somos los primeros universitarios en


formar parte de la empresa.

4
2. Ubicación del proyectante dentro de la empresa

A mediados de Octubre del año pasado comencé a trabajar de becario en la empresa


“SmartOxide”, puesto que tendría que en principio tendría que ocupar hasta finales de
febrero de este año.

Después de una entrevista inicial por teléfono con Jordi Compte, jefe de proyecto y
cofundador de “SmartOxide”, decidí que su empresa podía ser un buen lugar para
acabar el proyecto de final de carrera dado que mi intención era la de hacer una
aplicación web con PHP y era lo que ellos estaban buscando.

El primer día en la oficina conocí a Eusebi que sería mi compañero de trabajo durante
los próximos meses y a los demás colaboradores que estaban trabajando en el otro
proyecto de la empresa.

El proyecto que ambos teníamos que realizar conjuntamente se puede dividir en dos
partes bien diferenciadas. Por un lado una aplicación web con base de datos colgada
en el servidor capaz de generar códigos Quick Response (Q.R.) y por el otro, una
aplicación para terminales móviles que utilizaría un “framework” llamado “Phonegap”,
el cual permite realizar aplicaciones multiplataforma sin tener que trabajar con los
lenguajes nativos del terminal como pueden ser “Java” para “Android” u “Objective C”
para “iOs”.

Fue en este momento en el que ambos nos pusimos de acuerdo que Eusebi realizaría
la aplicación móvil y yo me encargaría de la aplicación web y de gestionar la base de
datos.

Lo primero que hice el primer día de trabajo fue formatear el ordenador e instalar todo
el entorno de trabajo que en un principio iba a necesitar (“NetBeans IDE 7.1.1”,”
Xampp Version 2.5”, “Mozilla Firefox”, “Google Chrome”).
A partir del segundo día fui completando las tareas que se me iban asignando
mediante “google docs” y que básicamente consistían en búsqueda de las mejores y

5
más perdurables librerías que podíamos necesitar para evitar los odiosos
“deprecateds” como sucedió en su día con la versión 2.0 de “google maps”.

De este modo las primeras semanas recibía información constantemente tanto de la


finalidad del proyecto como de las funcionalidades que se iban a necesitar con lo que
fui estructurando toda esta información a modo de clases buscando así integrar los
conceptos de la programación orientada a objetos que había ido entendiendo durante
la carrera.

Los coordinadores de los proyectos iban realizando controles periódicos del estado de
la aplicación de igual modo que iban aportando nuevas tareas las cuáles se nos
notificaban a base de reuniones internas, motivo que permitió una rápida integración
en la empresa.

6
3. Descripción del trabajo realizado

3.1 Objetivos del proyecto

Hacer una aplicación web con base de datos para comercios y usuarios mediante PHP
que sea capaz de generar códigos Quick Response (QR) y geo localizarlos.

3.2 Especificaciones del proyecto

Para desarrollar la aplicación se han llevado a cabo las siguientes especificaciones:

 Incorporar un generador de códigos QR para generar nuestros propios códigos


e incorporarlos a nuestro sistema.

 Geo localización automática de nuestros códigos QR en un mapa.

 Generación de diferentes modelos de QR con sus funcionalidades específicas


para segmentar la comercialización (QR Favorito, QR Postal, QR Queja).

 Generar fichas de los comercios de manera automática en función a unos


modelos genéricos de comercios y la información introducida al sistema por los
mismos.

 Acceso al sistema independiente para los comercios con funcionalidades de


contacto en tiempo real con sus posibles clientes.

 Funcionalidades de acceso, privacidad e histórico de su paso por nuestro


sistema para nuestros usuarios.

7
3.3 Diseño

Una vez comprendidas las especificaciones del proyecto quedó patente que tendría
total libertad para estructurar el mismo siguiendo mis propios criterios. En este
momento decidí que lo ideal sería seguir el patrón Modelo Vista Controlador siguiendo
la arquitectura del modelo Cliente/Servidor.

El primer paso fue plasmar un diseño de clases en papel que reflejaría a su vez las
tablas a generar en la base de datos y el conjunto de clases a generar en PHP.

Todas las clases han sido identificadas siempre con identificadores únicos y con fechas
de inicialización ya que resulta mucho más seguro y eficiente trabajar con
identificadores de tipo “BigInt” y no con cualquier tipo de datos.

De igual modo, fui implementando los atributos específicos de cada una de ellas, el
correspondiente constructor y el conjunto de “getter’s” y “setter’s” básico para poder
modificar y consultar los atributos de los objetos una vez instanciados.

A su vez el número de las tablas de la base de datos iba aumentando paralelamente


con la incorporación de nuevas clases siguiendo la correspondencia lógica entre
campos y atributos.

Dada que se necesitaba un conjunto básico de funcionalidades por clase que pudieran
acceder a la base de datos (“insert”, “select”, “update”, “delete”), fui implementando
nuevos métodos que incorporasen sentencias en SQL y que de manera genérica
accediesen a la misma separando por un lado, la información que se inserta o consulta
de la información básica de acceso a la misma.

Las reuniones de empresa comenzaban a producirse periódicamente y con cada una


de ellas se incorporaban nuevas ideas a raíz de las cuáles la idea inicial del proyecto
comenzaba a evolucionar, lo que hizo que cada vez me sintiera más integrado en la
empresa.

8
3.4 Desarrollo

Durante el principio de la fase de desarrollo he trabajado en local. Para ello he


utilizado la versión 2.5 de la “Xampp” programando con el entorno de desarrollo de
“NetBeans” en su versión 7.1.1. para “PHP”.

He seguido el modelo Cliente/Servidor, el cuál explicaré ahora, combinándolo a su vez


con la esencia del patrón Modelo Vista Controlador y manteniendo en todo momento
una separación entre la vista y el control de la información:

Modelo Cliente/Servidor:

El modelo Cliente/Servidor se puede definir como una arquitectura distribuida que


permite a los usuarios finales obtener acceso a la información de forma transparente
aún en entornos multiplataforma.
En él, el cliente envía un mensaje solicitando un determinado servicio a un servidor y
este envía uno o varios mensajes con la respuesta.
Veamos ahora más específicamente cuáles son sus roles:

Cliente:

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos


al servidor.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
• Administrar la interfaz de usuario.
• Interactuar con el usuario.
• Procesar la lógica de la aplicación y hacer validaciones locales.
• Generar requerimientos de bases de datos.
• Recibir resultados del servidor.
• Formatear resultados

9
Servidor:

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún


recurso administrado por él. El servidor normalmente maneja todas las funciones
relacionadas con la mayoría de las reglas del negocio y los recursos de datos.

Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes
puntos:
• Aceptar los requerimientos de bases de datos que hacen los clientes.
• Procesar requerimientos de bases de datos.
• Formatear datos para trasmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de
datos.

Durante este proceso tuve que crear una base de datos con su nombre de usuario y
contraseña de manera que se consulta su información cada vez que se ejecuta una
consulta a la misma.

Dado el grado de repetitividad de algunas de las consultas opte por generar clases en
las que determinadas consultas se llaman a medio de métodos. De esta forma, la
aplicación es más genérica y no se repite el mismo código de una anterior consulta.

Así, poco a poco, fui generando una pequeña API de clases con sus métodos
particulares de cada una, siguiendo el patrón Modelo Vista Controlador, el cuál
explicaré ahora:

Patrón Modelo Vista Controlador (MVC):

El Patrón MVC, es una arquitectura de Software que define la separación de los datos
que conforman la vista de la lógica de una aplicación.

Esto se hace con la finalidad de que cada una de las partes de una aplicación solo
realice lo que está en su responsabilidad, además de que le da mayor entendimiento a
nuestros desarrollos y los hace más fácil de mantener, ya que la parte del diseño solo
tiene la cantidad de código de programación que necesita al igual que en la parte que

10
conforma nuestro código del negocio solo se va a encontrar lógica de programación en
el lenguaje que estemos trabajando (PHP en nuestro caso).

De este modo, lo que este patrón desea evitar es que el un código de inserción de un
registro se encuentre junto con la vista en un mismo archivo, algo nada recomendable,
ya que puede provocar fallos de seguridad.

Veamos ahora más específicamente cuál es el rol de cada uno de los elementos del
patrón:

Vista:

La vista como su nombre lo indica es la parte visual, lo que el usuario final visualizara
en su aplicación. Es la que comunica al usuario lo que quiere ver, esta tiene acceso
directo al modelo y es esta la que transmite los datos a la aplicación para hacer el
proceso que necesitemos.

Modelo:

El modelo es el lugar donde se encuentra la lógica del sistema de almacenamiento de


nuestro producto y es ahí donde se procesan todos los datos provenientes de la vista.

Controlador:

Finalmente, el controlador es el encargado de hacer la conexión entre la parte visual y


la lógica del modelo, este se encarga de pasar los datos de la vista hacia el modelo
cargando la información correspondiente según la respuesta que este le entregue.

11
Una vez definido el método de trabajo, ahora explicaré las características básicas de la
base de datos:
Está formada por más de una treintena de relaciones, el tipo de motor de la misma es
“InnoDB” y el cotejamiento, tanto para las tablas como para sus conexiones “MySQL”
es “utf8_unicode_ci”.
Al generar la base de datos, basándome en una de las premisas que tendría que
soportar nuestro sistema en algunos de sus registros, la concurrencia, decidí que era
mejor utilizar el motor “InnoDB” y no el “MyISAM” por los siguientes motivos:
 Al contrario de “MyISAM”, “InnoDB” tiene capacidad de ejecutar transacciones
de tipo ACID cuyas siglas en ingles significan Atomicity, Consistency, Isolation
and Durability, es decir, Atomicidad (es la propiedad que asegura que la
operación se ha realizado o no, y por lo tanto ante un fallo del sistema no
puede quedar a medias), Consistencia (es la propiedad que asegura que sólo se
empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas
operaciones que no van a romper las reglas y directrices de integridad de la
base de datos), Aislamiento (es la propiedad que asegura que una operación no
puede afectar a otras. Esto asegura que la realización de dos transacciones
sobre la misma información sean independientes y no generen ningún tipo de
error) y Durabilidad (es la propiedad que asegura que una vez realizada la
operación, ésta persistirá y no se podrá deshacer aunque falle el sistema).
 “InnoDB” permite mantener la integridad referencial, de esta manera se
pueden definir llaves foráneas entre tablas “InnoDB” relacionadas para
asegurarse de que un registro no puede ser eliminado de una tabla si aún está
siendo referenciado por otra.
 A su vez, “InnoDB” permite el bloqueo de registros a nivel de filas. Con
“MyISAM”, al tener que ejecutar consultas muy grandes que requieren de
mucho tiempo, simplemente no se podían ejecutar más consultas hasta que
terminaran las consultas que estaban en ejecución. En cambio, las tablas
“InnoDB” usan bloqueo a nivel de filas. Con esto consiguen mejorar el
rendimiento en casos como que una lectura esté siendo bloqueada por otra
consulta que está haciendo cambios en la misma tabla, facilitando de este
modo la concurrencia.

12
Pese a la menor velocidad de codificación del cotejamiento “utf8_unicode_ci” frente al
“utf8_general_ci”, decidí utilizar el primero dado su mayor grado de precisión ya que,
en un futuro, iba a ser necesario almacenar información en otros idiomas como el
alemán que requieren del cotejamiento “utf8_unicode_ci” para evitar errores durante
el proceso de codificación/decodificación.

También he utilizado claves primarias a modo de identificadores comprobando en


todo momento la coherencia de los datos. De igual modo he controlado que no se
hicieran nuevas inserciones en caso de repetición de ciertos campos.

Respecto a la interficie de la aplicación he de decir que partiendo de las


especificaciones del proyecto, dadas desde un principio por los coordinadores del
mismo (Jordi y Carlos) y el jefe de la empresa (Armand), yo he decidido en todo
momento la manera en que se iban a hacer todas las peticiones al servidor junto con
los parámetros que se iban a recibir (el paso de parámetros siempre es por POST) y
que se han de retornar a cada instante.

De igual modo, he decidido en todo lo referente al control de la información tratando


independientemente en función al tipo de datos que han de ser tratados.

Decidí utilizar sesiones las cuáles, al igual que son creadas, son destruidas llegado el
momento oportuno.

He implementado la subida de imágenes al servidor. Estas se limitan por su formato y


se transforman automáticamente y de forma transparente para el usuario en función
del peso que se quiere almacenar en el mismo. De este modo no tan sólo existe un
control de la información sino que, posibles problemas para un usuario poco avanzado,
como puede ser bajar el peso de una imagen, se hacen totalmente transparentes.

De igual modo, he implementado la descarga de imágenes desde el servidor.

13
En lo que a la interficie gráfica se refiere, he trabajado conjuntamente tanto con los
jefes de empresa y de proyecto, como con el equipo de diseño gráfico (Gerard y Jose).
He tenido la oportunidad de compartir opinión con ellos a modo de “brainstorming” y
he sido el encargado de estructurar tanto la información que aparecería en los
“header’s” como los “bodies” como los enlaces que comportan.
He de decir que el diseño de los iconos y en general, el diseño gráfico puro
(“PhotoShop”, “FreeHand”, etc) ha sido trabajo de los diseñadores gráficos pero sin
embargo, si ha sido competencia mía, generar los ficheros correspondientes de estilo
en los que quedan definidos los patrones con los que se muestran los diferentes
elementos que aparecen en pantalla y la manera en la que se interactúa con ellos.

Para ello, utilizo “html” como lenguaje de navegador, junto con “css” para definir el
estilo de las vistas.

Para el acceso de los comercios, decidí que lo más innovador era integrar un
“fancybox” el cuál se abre sobre un fondo más oscuro al clicar sobre el icono de
registro y que, a su vez, tiene un formulario de acceso implementado internamente.

Esto comporta el uso de “Javascript” o “jQuery” para el control de la información y de


PHP para el paso de parámetros el cuál siempre se hace por $_POST evitando así que
la información aparezca en la barra del navegador y haciendo de este modo más
seguras las transferencias de información.

En lo que a desarrollo se refiere, el siguiente paso fue integrar un generador de


códigos QR el cuál, no solo tuve que integrar sino que, dada la especificación del
proyecto, también lo tuve que modificar previamente para que permitiera generar los
tipos de QR ya nombrados (Favorito, Postal, Queja).

Para ello, tuve que decidir cómo se generarían los QR’s y el modelo a seguir para
identificarlos generando de este modo el sistema con la información que contendrían
en sí, al escanearlos con nuestra aplicación.

14
Dado que una gran parte de la aplicación debe ir sincronizada también con la “app”
para terminales móviles, ya que debe poder hacer peticiones al servidor para enviar y
recibir información de la base de datos y al hecho, que la conexión ha de hacerse a
través de un servidor que este en Internet y no en local, se hizo patente la necesidad
de coger un dominio gratuito capaz de soportar “PHP” para los ficheros y “MySQL”
para la base de datos.

Tras valorar una serie de críticas, mi compañero y yo decidimos que subir la


información a “000webhost.com” era la mejor opción debido principalmente a que es
gratis y actualmente trabaja con la última versión de PHP, la 5.2.

Por política de empresa los detalles más internos en lo que a código fuente,
funcionalidad o casos de uso se refiere no pueden ser desvelados públicamente,
motivo por el cuál continuaré a modo de memoria este apartado.

A partir de este momento y dada la imposibilidad de utilizar el “000webhost” a modo


de repositorio, me descargue el programa “FileZilla” para conectar con el servidor y
sincronice la edición de los archivos que estaban colgados en el “hosting” con mi
“NetBeans” diciéndole a su vez que almacenara copia en el “htdocs” de mi propia
“Xampp” en local.

De este modo conseguí evitar el tener que estar subiendo archivos al servidor cada vez
que modificaba información en local y a la inversa.

Con la nueva adhesión de miembros al grupo (Luis y Rubén) se hizo necesaria la


coordinación y gestión más cercana de las tareas, responsabilidad que llevo ejerciendo
como coordinador del proyecto desde hace ya tres meses a través del repositorio
asociado a codebasehq.com

Con esta herramienta se puede crear un proyecto (con su repositorio asociado), añadir
y modificar permisos a nuevos miembros del proyecto, añadir tareas y asignarlas a
determinados miembros, o generar puntos de control a modo de “milestones” para
seguir una evolución y un porcentaje del total del trabajo que queda para finalizar el
mismo.

15
Esto me permite seguir en tiempo real el transcurso de los acontecimientos al igual
que de los “commits” realizados a través de la asociación que tengo creada entre el
mismo “codebase” y mi cuenta de correo electrónico del trabajo.

Por este motivo, decidí instalarme el entorno de desarrollo de “Eclipse Enterprise


Edition” (EE) para desarrolladores web, junto con el “Android Standard Development
Kit”(SDK) y el ”plug-in” de “Phonegap”.

Al no disponer de un “smartphone” propio comencé a utilizar el emulador de


“Android” que se instala con el SDK pero dada la lentitud del mismo y el elevado
consumo de recursos del ordenador Armand (jefe de la empresa) compró uno.

El modelo con el que trabajo es un “Samsung Galaxy Young GT-S5360” con la versión
de sistema operativo 2.3.6 de “Android” versión depurada de la 2.3.3 “Gingerbread” y
pese a tener unas dimensiones más pequeñas que las de sus hermanos mayores, es
francamente un lujo poder utilizarlo para el desarrollo de aplicaciones móviles.

Para el intercambio de información tanto con el repositorio de la aplicación web como


con el de la aplicación móvil utilizo “Subversion”.
He utilizado el inspector de elementos de “Google Chrome” durante el desarrollo, no
tan sólo para el control en tiempo real de la aplicación, sino también, para acabar de
definir las características para el estilo o vista (CSS), ya que te permite realizar cambios
en el propio navegador y luego aplicarlos al documento con los estilos de los diferentes
elementos.

16
3.5 Evaluación

Conforme el proyecto fue adquiriendo forma y permitía realizar a través de él las


primeras consultas a la base de datos, he ido siguiendo una serie de mecanismos de
control de la información que se almacena en el servidor en cuanto a veracidad y
coherencia.

He realizado este control por medio de lenguajes como “Javascript” y “jQuery” de


manera que, cuando el usuario clique sobre un botón, se ejecuten asociados ciertos
mecanismos de control de los cuáles describiré los más sencillos brevemente:

 Suponiendo el caso de un campo de una tabla de la base de datos cuyo tipo sea
un “varchar” de 50 caracteres y al cuál no queramos que entren valores igual a
7, por un lado, el número máximo de caracteres que se asociarán a su input
será de 50 y a su vez, dado que puede ser cualquier tipo de carácter menos el 7,
se le aplicarán dos restricciones a modo de condicionantes diciendo que, la
longitud del valor asociado al input ha de ser menor o igual que 50 y diferente
de 7.
 Suponiendo el caso de un campo de una tabla de la base de datos cuyo tipo sea
un “int” de 4 caracteres y al cuál no queramos que entren valores menores que
5000, por un lado, el número máximo de caracteres que se asociarán a su input
será de 4 y a su vez, se le aplicarán dos restricciones a modo de condicionantes
diciendo que, la longitud del valor asociado al input ha de ser menor o igual
que 4 y que, el valor tratado ha de estar en un rango de entre 5000 y 9999.

En el caso de que los datos a introducir sean contraseñas, he seguido un proceso de


encriptación al tratar el valor introducido por el usuario y le he asignado un tipo
“password” y no “text” para, de este modo, no se vea al escribir el usuario.

También he comprobado que, en caso de errores en el momento del “login” no se


muestren errores del tipo “Su email no es correcto” o “Su contraseña no es correcta”
dado que un posible intruso, experimentado, si sólo recibiera un mensaje, sabría que
en la opción que no ha aparecido ha acertado.

17
Por este motivo los mensajes que se envían son siempre del tipo “ERROR: Su email o
su contraseña no son válidos”.

Por otro lado, los botones se bloquean tras su primera pulsación. De este modo dejan
de estar funcionales, como mínimo hasta que reciben la información de la petición y se
reflejan sus resultados para, de este modo, no permitir que se puedan seguir enviando
nuevas peticiones clicando repetidas veces en el tiempo que tarda en producirse la
transferencia lo cual podría provocar una sobrecarga del servidor de hacerse desde
“malas manos”.

Para “debugar” las transferencias de información entre la aplicación y el servidor, he


utilizado el inspector de elementos del “Google Chrome”, controlando así, la correcta
recepción de los parámetros, los cuáles son encriptados si así es necesario.
He utilizado su inspector de elementos dado que es una herramienta capaz de detectar
el resultado, hasta incluso, en caso que las peticiones que se realizan al servidor sean
por “Ajax”.

He hecho pruebas periódicas con las últimas versiones de “Mozilla Firefox” y “Safari”.

He “debugado” ciertas consultas directamente en la misma base de datos a través de


la opción “SQL” del “phpMyAdmin”, verificando de este modo la información que se
obtenía de las mismas antes de plasmarla en el proyecto.
Principalmente, en determinados casos más complejos, en los que eran necesarias
consultas múltiples, asegurándome de este modo de que la consulta no provocaría un
error.

También he utilizado el “phpMyAdmin” en el caso de ciertas consultas en las cuáles,


debido a que se pueden hacer de varias formas, dudaba.
Para ello, evalúo el rendimiento de las mismas desde el mismo servidor, dado que
valorar una petición desde un navegador no tiene porque darnos una respuesta fiable,
puesto que dependemos de demasiados parámetros relacionados ya en menor grado
con la eficiencia de la consulta pero sí, sin embargo, en mucho mayor grado, con la
conexión de la que dispongamos y su ancho de banda.

18
Estos son algunos ejemplos de tiempos de carga al realizar peticiones al servidor:

Petición al servidor 1 Petición al servidor 2

Conecting 151 ms 154 ms 153 ms 0 0 0

Sending 1 ms 0 0 0 0 0

Waiting 902 ms 1,04 s 1,01 s 889 ms 857 ms 940 ms

Receiving 650 ms 671 ms 315 ms 153 ms 151 ms 111 ms

Total 1,70 s 1,87 s 1,48 s 1,04 s 1,01 s 1,05 s

Como se puede ver, en ambas peticiones, los tiempos de espera se mantienen estables
y dentro de la media siendo el tiempo de recepción (ver petición 1), el cual depende de
otros parámetros relacionados con la conexión a Internet, el principal causante de
aumentar el tiempo total, principalmente en el primer caso,

3.6 Recursos utilizados

Generador libre de códigos QR.


API PHP (http://php.net/manual/en/)
API v3 Google maps (https://developers.google.com/maps/documentation/)
Páginas webs como: http://www.cristalab.com/tutoriales/
http://www.w3schools.com/
http://www.lawebdelprogramador.com/foros/PHP/index1.html
Más.

19
4. Aportaciones del proyecto a los conocimientos del alumno

Durante el tiempo que llevo en el proyecto he adquirido una mayor experiencia en


lenguajes de programación como PHP y SQL trabajando siempre en un entorno de
trabajo innovador y haciendo frente día a día a los nuevos retos que surgían.

A resultas de este tiempo, he conseguido practicar la arquitectura cliente/servidor a


medida que iba avanzando el proyecto.

A parte de ello, he adquirido mayor experiencia a la hora de gestionar las tareas y los
tiempos de entrega coordinando estos últimos tres meses los recursos como “Project
Manager”.

He tenido que crear y gestionar repositorios y crear cuentas en varios servidores de


Internet, subiendo así toda la estructura de carpetas del proyecto, al igual que su base
de datos.

Durante este tiempo he debatido y aportado ideas, algunas de las cuales siguen aún en
proceso de desarrollo.

He de decir que día a día estoy aprendiendo en campos no tan sólo relacionados con la
técnica sino más relacionados con la buena comunicación con los miembros de la
empresa, mirando de hacerles participe de lo que están haciendo, valorando sus ideas
y motivándoles para seguir en la dirección correcta.

20
5. Aportaciones de los estudios realizados al proyecto

He de decir que pese a que del total de los lenguajes utilizados tan sólo había
trabajado con SQL en la carrera, asignaturas como Lenguajes de Programación (L.P.) y
Sistemas Abiertos (S.O.) han sido claves para entender los principios seguidos durante
el desarrollo del proyecto.

Sin los conocimientos aprendidos en L.P. no hubiera sido capaz de generar todo el
sistema de clases a modo de API accediendo e implementando en ellas nuevas
funcionalidades conforme los requisitos del proyecto lo iban necesitando.

De igual modo, al cursar S.O. pude apreciar la diferencia entre los lenguajes
mostrativos de navegador como “html” y los lenguajes de programación de servidores
como es el caso de PHP, así pude aprender el Modelo Cliente/servidor o el Patrón
Modelo Vista Controlador en el que se separa la vista de la información y se accede a
ella por medio de un conjunto de funcionalidades. De hecho conceptos tan básicos
como el de formulario (form) o el de paso de parámetros entre navegador y servidor
son otros ejemplos de conceptos que aprendí cursando la misma.

A su vez, tanto Introducción a las Bases de Datos (I.B.D.) como Base de Datos (B.D.),
me han servido a la hora de visualizar y generar las relaciones de información que sería
necesarias implementar en la propia base de datos de modo que permitiesen generar
todo tipo de consultas y de control de la información con la que trabajo.

Para acabar, conceptos como los de escalabilidad y “overhead” han resultado a su vez
muy útiles los cuáles comprendí cursando Redes P2P y a su vez tanto Proyectos
Informáticos (P.I.) a la hora de gestionar y asignar los recursos del proyecto como
Ingeniería del Software (E.S.) con los conceptos de intuitivo y los diagramas
estructurales me han ayudado a posicionarme a la hora de programar pensando
siempre desde el punto de vista del usuario, simplificando así al máximo los casos de
uso de modo que la mecánica interna de funcionamiento resulte transparente para el
mismo.

21
6. Conclusiones

El haber tenido la oportunidad de realizar un proyecto de final de carrera como este


partiendo de unas premisas básicas que han tenido que ir evolucionando con el tiempo
me ha permitido poder participar más activamente en el proyecto de lo que jamás
hubiera esperado en un principio.

A día de hoy ya hemos llegado prácticamente al punto de comercialización de nuestro


producto y de resultas de esta proximidad inminente, mi compañero y yo ya hemos
realizado dos presentaciones junto con el jefe de la empresa ante dos grupos distintos
de posibles compradores los cuales en su mayoría se mostraron francamente
interesados en el producto que ofrecemos, sin duda, una sensación muy gratificante la
cuál tengo que agradecer a toda la estructura que nos compone.

22
23

Vous aimerez peut-être aussi