Pruebas

A la hora de plantear las pruebas se hace de nuevo patente la separaci´on entre el cliente y el servidor, y por ello lo trataremos en dos apartados diferenciados; no obstante, aunque las pruebas utilicen sistemas muy distintos para su reali- zaci´on, habr´a un tercer conjunto de pruebas, las de aceptaci´on, en las que se comprobar´a el correcto funcionamiento de la aplicaci´on atendiendo a los casos de uso planteados.

4.4.1 Pruebas del Cliente

Para la realizaci´on de las pruebas en el lado del cliente, se opt´o por utilizar, de manera conjunta, un falso servidor cuyas respuestas siempre sean id´enticas y una serie de scripts que simularan la interacci´on de un usuario con la interfaz gr´afica, ejecutando las llamadas pertinentes. Se opt´o por la elecci´on de ´este sistema en lugar de la utilizaci´on de un programa externo para reducir, en la medida de lo posible, el aprendizaje de nuevas herramientas y tecnolog´ıas, si bien puede ser un sistema m´as complejo en ´este caso.

4.4.2 Pruebas del Servidor

A la hora de plantar las pruebas en el lado del servidor, concretamente, las pruebas de los controladores, se opt´o por la utilizaci´on de los propios scritps de PHP para su realizaci´on, ejecutando los distintos casos de uso en ambientes controlados en los que se utilizar´an falsas entidades para simular los accesos al sistema de persistencia.

Por ´ultimo, el sistema de persistencia ejecutar´a, de igual forma, su conjunto de pruebas unitarias en las que se monitorizar´a que la entrada y la salida sean las adecuadas en cada caso.

5

Conclusiones y l´ıneas futuras de trabajo

Como conclusi´on a este proyecto, me gustar´ıa realizar una reflexi´on a tener de todo el trabajo realizado y de su enfoque. Si bien el proyecto parec´ıa, en un principio sencillo, la cantidad de material necesario para la realizaci´on de una buena documentaci´on y un an´alisis apropiado ha sido, como se ha podido com- probar, muy elevada, y es ah´ı donde radica, en mi opini´on, la diferencia entre ´este y otros proyectos del mismo tipo.

Muchas veces tenemos la tendencia de enfocar el problema de una manera muy concreta, esto es, a enfrentarnos al c´odigo escribi´endolo, necesitando en oca- siones refactorizar nuestras primeras aproximaciones, o directamente desechar- las, para adecuarlas a los casos de uso dados, que no es m´as que lo que en el fondo el cliente requiere. ´Este proceso de ensayo y error merma las horas de tra- bajo productivo y, por lo tanto, la calidad del producto, y es una manera poco productiva de afrontar un proyecto de una dimensi´on mediana o grande, pese a existir otras metodolog´ıas que, precisamente, se aprovechen de ´este funciona- miento. Sin embargo, cuando la cantidad y complejidad del c´odigo sobrepasa determinados umbrales, es necesario un an´alisis m´as detallado y, por lo tanto, no podemos, sencillamente, sentarnos y escribir c´odigo que luego no servir´a. De ah´ı, en mi opini´on, la importancia de una metodolog´ıa como la aqu´ı expuesta en la que, si bien se ha utilizado la gran parte del tiempo en realizar los an´alisis de las distintas partes del c´odigo y su interrelaci´on en lugar de, efectivamente, producir ´este c´odigo, la creaci´on del mismo ha sido y ser´a mucho m´as directa y eficiente, ya que la inmensa mayor´ıa de puntos conflictivos est´an resueltos, estudiados, y bien documentados, dejando poco margen al error.

En cuanto a los objetivos marcados en el cap´ıtulo??, creo que se han logrado todos ellos, aumentando as´ı mi conocimiento, tanto de la tipolog´ıa y uso de los diagramas UML, como de la metodolog´ıa en s´ı, lo que me ha permitido adquirir algo de experiencia no solo con la metodolog´ıa o el uso de los citados diagramas, sino con el desarrollo desde cero de un proyecto, aunque se trate de uno de muy peque˜nas dimensiones, que era el f´ın ´ultimo de ´este proyecto, m´as all´a de la metodolog´ıa utilizada o el nivel de completitud logrado.

5.1

Futuras l´ıneas de trabajo

Entre las sugerencias de mejora de la herramienta, podemos encontrar las si- guientes:

• Implementaci´on de un sistema de persistencia basado en BBDD:

al y como se vio en el apartado de la implementaci´on, quedaba fuera del alcance la gesti´on y creaci´on de una base de datos para incluirla como mo- delo de persistencia de la plataforma, permitiendo de ´esta manera que la gesti´on pueda realizarse en varios pasos, o que gestiones anteriores puedan ser heredadas de un proyecto a otro, funci´on ´util a priori si la empresa se

maneja siempre con un equipo similar de personas.

• Inclusi´on de frameworks que mejoren el aspecto visual:A la vista queda que el apartado visual no es el m´as apropiado, y por lo tanto, se sugieren la inclusi´on de frameworks como Bootstrap que no s´olo a˜naden mejoras est´eticas, sino tambi´en funcionales, ofreciendo un sistema de paga adaptativa cuyo tama˜no y disposici´on de los elementos variar´a en funci´on del tama˜no del navegador en el que se visualice.

• Migraci´on del sistema a una API de tipo REST: La creaci´on de un sistema tipo REST que ejecute los casos de uso permitir´ıa, en un fu- turo, sustituir las vistas programadas con Javascript por unas mucho m´as detalladas e inteligentes basadas en, por ejemplo, ´AngularJS.

• Creaci´on de un cliente m´ovil: Aprovech´andonos del punto anterior, ser´ıa sencillo establecer un cliente m´ovil cuyas vistas se comunicaran de manera remota con el servidor mediante llamadas a la API REST.

Referencias

[1] IT. Hello. Resumen de Scrum desde la trinchera.http://helloit.es/2014/ 09/resumen-de-scrum-desde-las-trincheras/. [Online; ´Ultimo acceso 23/6/2015].

[2] Luis Fern´andez Mu˜noz. Apuntes de la asignatura “Metodolog´ıas Pesadas pa- ra Desarrollo Web”. https://moodle.upm.es/titulaciones/oficiales/ course/view.php?id=3269&section=10. [Online; ´Ultimo acceso 1/7/2015]. [3] Wikipedia. Proceso unificado de Rational. https://es.wikipedia. org/wiki/Proceso_Unificado_de_Rational. [Online; Ultimo acceso´ 21/5/2015].