Proyecto electiva I: Entregas CONTINUAS

Nombre Grupo: Intersolution

Proyecto: Buenos Planes

Primera entrega

- Ivan Espitia-Una aplicación que miraba el consumo de los electrodomésticos, de acuerdo a esto se añadían a la aplicación, para medir el total del consumo de electricidad, al final se le aconsejaba al usuario como seria mejor el consumo de electricidad en un periodo de tiempo determinado. No se valido esta idea, ya que es tedioso para alguien estar añadiendo información dentro de una aplicación

-David Sanchez- Una aplicación para saber los precios de un menú en un restaurante, no se valido la idea ya que es complicado que los restaurantes den esta información

- Jose Reyes — Una aplicación que mediante sensores, mande alertas al usuario de que sobrepasó el consumo básico de energía y como consecuencia el cobro sera mayor al habitual. No se valido ya que es complicado implementar estos sensores en los contadores de luz, y además sincronizar estos sensores con los teléfonos inteligentes

-Todos los integrantes-Una aplicación que muestre planes baratos en la ciudad, mediante la obtención de información de otras páginas web con el scraping. Esta idea si fue validada

  • Se buscaron tecnologías para desarrollar la aplicación

Para el desarrollo de la aplicación se escogió el framework ruby versión 2.2 ya que con esta se facilita el scraping. Para la base de datos se escogió MySQL. Hay problemas para la conexión de la base de datos con el servidor

Base de datos — David Sánchez

El modelo de la base de datos fue simple de crear, pero al no contar con usuarios, nos tocó revisar cómo crear la clasificación de los lugares de forma anónima.

Github Student Pack - David Sánchez

Gracias a Github Student Pack el repositorio se pudo hacer privado gratis y cambie sublime text por atom al ser gratuito y poder añadir funcionalidades de forma más simple que sublime.

En la experiencia de desarrollar un producto a base de entregas continuas, hace un poco compleja la forma en la que el producto empieza a llevar a cabo el objetivo por el cual es diseñado, ya que al momento de empezar es difícil encontrar qué tecnologías son las más adecuadas para la realización del mismo.

al comienzo se empezaron a generar múltiples ideas, pero ninguna tuvo un aval para poder ser llevadas a cabo. luego de pensar de nuevo qué ideas podrían ser viables y de gusto, encontramos la idea de un sitio web en donde cualquier persona pueda encontrar qué planes buenos y económicos hay en la zona donde se encuentra. esta idea se llamó Buenos Planes.

luego de ya contar con la idea procedimos a la parte de diseñar y elaborar estrategias conforme a las tecnologías que pensamos serían las más eficientes, para desarrollar la idea, pero se empezaron a generar conflictos ya que no contábamos con el manejo total de las tecnologías que escogimos, y empezamos a variar algunas tecnologías para poder saber cuales serian las más adecuadas.

Segunda entrega

Pruebas software:

Estas pruebas para que se hagan de una buena manera, se deben realizar en orden, primero las unitarias, luego las de integración, las funcionales, luego las de sistema, y por ultimo las de aceptación de las historias de usuario.

La mejor forma de realizar estas pruebas es a través de la automatización de las mismas, y de herramientas online; aunque hay otras que se pueden hacer manualmente.

Estas pruebas se realizan para encontrar errores, fallos o defectos, los cuales deben ser identificados en el menor tiempo posible, para poder corregirlos.

Primero que todo se realizaron las pruebas unitarias las cuales son sobre el código en si, es decir se prueban los distintos métodos que tiene el código.

A continuación se escribirá la experiencia de los integrantes del grupo de intersolutions

— Ivan Espitia — A comienzos de la semana pasada se nos propuso a mi grupo y a mí la tarea de realizar diferentes tipos de pruebas a nuestra página web en su primera versión, en donde veíamos pruebas como la velocidad, la cantidad de archivos que carga, como se acomodan los elementos de la página al tamaño de la ventana o al tamaño de un dispositivo, entre otras cosas.

Además de pruebas básicas, también se vieron pruebas más específicas como, pruebas a los métodos del back-end de la página, y la integración de estos métodos con métodos del front-end.

Posteriormente de ver que pruebas debíamos realizar, comenzamos con la tarea de buscar herramientas para realizar estas pruebas y realizar las pruebas. Al momento de realizar la prueba, documentamos los resultados y si lanzaba algún tipo de error, lo dejábamos como un pequeño foro abierto en donde algún integrante del grupo que supiese como solucionarlo, comentaba la solución y cerraba ese pequeño foro.

Luego de haber realizado la mayoría de las pruebas, las colocamos en un documento tipo informe en donde van todas las pruebas realizadas según su tipo y si es posible su solución a algún fallo reportado, gracias a esto pudimos encontrar ciertos fallos que no tuvimos en cuenta y realizas pequeñas mejoras al sitio.

— José Reyes — La dificultad al principio de la realización de esta actividad fue la de saber a que se refieran cada prueba, y que se debía hacer en estas pruebas. Ya que estas pruebas las había realizado de forma manual y no automatizada como la pedía el docente. Lo siguiente fue encontrar herramientas online para realizar las pruebas, muchas de estas herramientas son de pago, por esto era complicado encontrar buenas herramientas y fáciles de manejar. Pero al final se consiguieron buenas herramientas gracias a la ayuda del docente. A continuación hago la relación de las herramientas utilizadas con sus pruebas:

Prueba de funcionalidad: test studio(herramienta online)

Prueba de compatibilidad de plataformas: browserling.org(herramienta online)

Prueba de compatibilidad entre navegadores: browserling.org(herramienta online)

Prueba de usabilidad: mobile friendly test(herramienta online)

Prueba de accesibilidad: Examinator(herramienta online)

Prueba de seguridad: webcheck.me(herramienta online)

Prueba de Software performance testing: Pingdom website speed test (herramienta online)

Las demás pruebas realizadas por mi fueron manuales, ya sea por criterio propio, o por sugerencia del docente.

Me pareció buena la experiencia de haber realizado estas actividades, ya que no conocía que se podían automatizar las pruebas, y por lo tanto hacerlas mas rápida

— David Sanchez Ruiz — 
Para las pruebas de inserciones en la base de datos se usó una muy buena página web la cual genera los datos aleatorios ahorrando mucho tiempo. (http://www.generatedata.com)
En cuanto a correcciones de bugs, cuando dentro de un php o un html se incluye un php si ese archivo incluido tiene otro “include” que este en otra carpeta atrás del archivo, como tal el puntero de donde debería estar el archivo a la hora de incluirlo no es donde se encuentra el archivo digamos (php/sites/aquí.php), sino que lo toma como si estuviera en la misma carpeta donde está el primer archivo que incluyo a los demás php.
No sé si es adecuado que una base de datos deje insertar información inválida, pero que solo inserte algo valido o simplemente un 0. Aunque se supone que el Front End es el que filtra lo que se va a insertar.

Tercera Entrega: Integración Continua

- Iván Espita -

Consultando información acerca de pruebas unitarias y pruebas de calidad de código o de código estático, me encontré con una serie de dudas por resolver, como saber realizar una prueba de calidad de código por fuera de un IDE (Herramienta de desarrollo), o como realizar este tipo de pruebas de forma automática, y que además en este caso se hicieran para el lenguaje PHP.

Ya que en mi recorrido por las distintas materias vistas a lo largo de la carrera, no he utilizado herramientas que realicen este tipo de pruebas y como pasarlas.

Al momento de realizar las consultas necesarias para realizar estas pruebas, no encontraba la información precisa de cómo usarla, sino que encontraba información de cómo usarla con ciertos tipos de herramientas y además mucha de esa información se encontraba en inglés, dificultando un poco mi tarea.

Hasta que llegue a un momento en que ya había realizado muchas consultas pero no tenía nada realizado, me dedique a tomar pequeñas partes de las consultas he ir entendiendo el funcionamiento poco a poco de las distintas herramientas, hasta que encontré una herramienta llamada composer, la cual me ayuda a manejar o administrar herramientas de pruebas en PHP de una manera sencilla desde la terminal de Windows en este caso.

En esta primero se debe crear un archivo .json con las dependencias o librerías de las herramientas que necesitaremos, en este caso use PHP CodeSniffer que mira si mi código está bien documentado, si tiene buenas prácticas y demás. Después de crear el .json se procede a la terminal donde se ejecuta el composer e instala las librerías necesarias.

Para finalizar solo se requiere de una línea de comando para realizar las pruebas aunque se debe delimitar bien la ruta del archivo y lo hace un archivo a la vez, donde arrojaría los errores o advertencias que encuentre en determinado archivo.

— José Reyes —

En esta entrega se va a estudiar sobre la integración continua mediante la automatización de commits en los repositorios sin que hayan errores de codigo. Para automatizar commits en el Git Hub sin errores de código, hay que tener en cuenta:

- El repositorio sea público (hay herramientas online que hacen pruebas con repositorios privados, pero hay que pagar por utilizar esas herramientas)

- El usuario dentro del repositorio debe ser administrador, ya que no tendría permisos si es un usuario limitado

Al principio se tuvo en cuenta la herramienta Jenkins de integración continua, pero esta herramienta se maneja de manera local, además esta herramienta funciona con proyectos en java, aunque se pueden instalar plugins para que funcione con otros lenguajes. Como nuestro proyecto está en lenguaje PHP, esta herramienta fue descartada. Al descartar esta herramienta se exploró herramientas online para pruebas de integración continua como por ejemplo:

- IC de amigos

- Círculo CI

- Travis CI

- PHP CI

Se escogió la herramienta Travis IC, por los siguientes motivos:

- Es la que más se me facilito, ya que trabaja con proyectos en PHP

- Fue fácil la sincronización con el repositorio en GIT HUB

- Se encontró tutoriales en internet, que explicaban de una manera muy fácil como se podían hacer las pruebas de integración continua

Al principio tuve problemas con la sincronización de Travis IC con el repositorio en GIT HUB, ya que el repositorio es privado, y además mi usuario dentro del repositorio no era administrador. Solucioné estos problemas haciendo lo siguiente:

Cloné el repositorio, y lo hice dentro de un repositorio público, en el que mi usuario es administrador.

Para hacer las pruebas de integración continua de los commits, creé unos scripts que al hacer un commit en el repositorio, automáticamente va a lanzar errores si el código los presenta. Estos errores se enviaran al correo electrónico de los contribuyentes del repositorio, donde se relacionará:

- La rama del repositorio

- El código del commit

- Una descripción del commit

-El error encontrado por la herramienta Travis IC

— David Sánchez —

Buscando como hacer las pruebas Unitarias encontré php unit el cual se me hizo muy tedioso para implementar, y encontré test simple el cual realizaba los test de igual forma, pero solo se implementada bajando una librería, pero al bajarla mandaba error la librería, lo cual después de mucho tiempo, note que era por la versión del php, baje la otra versión y funciono perfectamente

Cuarta entrega: Pruebas guerrilla con usuarios reales

Como se ha hablado en las anteriores historias, hemos estado realizando el desarrollo de un sitio web llamado buenosPlanes en donde mostramos planes de todo tipo y se brinda la oportunidad de que las personas agreguen o compartan planes de forma gratuita.

Al final de la semana antes de semana santa se planteó la organización del día 17 de abril, en donde cada uno de los equipos de la clase presentaban al público lo que llevaba del sitio y escuchaba a cada una de las personas que lo probaban que cosas les gustaba, que cosas quisieran que tuviese el sitio y que cosas no les gusto.

El evento se realizó en una de las cafeterías de la universidad y aunque nunca lo había realizado, me pareció muy interesante y nos supimos desenvolver muy bien con las personas y sus comentarios. Me gustaría volver a realizarlo pero cuando se haya terminado de crear el sitio.

Se tuvo como guía los test guerrilla, para la realización y aplicación de las pruebas a los usuarios, ya que son las más sencillas de hacer y se acomodaban perfectamente a lo que queríamos lograr, que es la opinión de usuarios reales que en futuro utilizaran el producto que realizamos

Hasta el momento el proyecto de BuenosPlanes no había sido visto por personas que no fuera el equipo de desarrollo, el ingeniero o los integrantes de los demás proyectos, a pesar de todo la evolución de BuenosPlanes se ha visto a pasos grandes y era hora de realizar pruebas con personas que no fueran de nuestro ámbito.

No esperaba que las personas fueran a disponer de su tiempo, creía que iba a tomar más tiempo las pruebas, y no esperaba las reacciones y comentarios que realizaron. Les gustó la idea y el producto que se presentó a pesar de que casi todos resaltaban que los lugares deberían tener más información y cosas que ellos les gustarían ver como videos, más fotos, historias de los sitios, entre otras, las mejoras que no se apreciaron desde un inicio se apreciaron en esas pruebas.

También se vio algo reflejado que a pesar de la cantidad de sitios que existen y que ingresamos a internet todos los días para cualquier cosa se realizaron comentarios de ciertas dudas que reflejan que a pesar de que existen cosas como oprimir en el logo y que eso envié al index, prácticamente es desconocido para muchos.

Como futuros ingeniero de sistemas debemos tener claro que lo que realizamos debe ser de agrado de los usuarios, no solamente a nosotros, por eso debemos tener una constante realimentación con los clientes y usuarios para que el producto sea lo más agradable y sobre todo funcional para ellos. Por ello debemos adquirir competencias en la comunicación con los demás, ya que podemos ser los mejores ingenieros de sistemas, pero si no nos comunicamos de buena manera con los demás, no podremos saber cuáles son sus necesidades, trayendo como consecuencia malos entendidos.

Show your support

Clapping shows how much you appreciated Jose Reyes’s story.