# Obligatorio 2
-----------------------------

**M3B - Docente**: Gabriela y Pablo Sanchez
* Violeta Clerc - 233379
* Nicolas Artola - 213616

**Fecha de entrega:** 23/11/2020

**Nombre del Repositorio:** [ORT-FIS-202008/ob1-artola-clerc](https://github.com/ORT-FIS-202008/ob1-artola-clerc/tree/main/Obligatorio%202) (Carpeta Obligatorio 2)

## Repositorio
---------------

Al comenzar nuestro Obligatorio creamos un nuevo repositorio en GitHub el cual trabajamos unos días en el mismo. Pero luego recomendaron en clase utilizar el repositorio ya creado del Obligatorio 1, y así fue que nos trasladamos hacia ese repositorio.

Utilizamos GitHub desde la página ya que consideramos que tiene mejor visualización comparado con la terminal.

En este archivo README, planteamos toda la documentación para el Obligatorio 2; incluyendo punto a punto lo que pide realizar la rúbrica.

## Calidad de código
----------------------

El uso de un estándar de codificación es uno de los aspectos que forman la calidad del código, es de gran importancia a la hora de desarrollar, y más en un trabajo en equipo, donde hay más de una persona realizando modificaciones casi simultáneamente, ya que impacta fuertemente en la legibilidad del código, y consecuentemente, en la velocidad y correctitud de compresión de la misma.

Mientras realizamos el obligatorio, intentamos participar ambos integrantes en la máxima cantidad de modificaciones que tenía el mismo, pero a veces como no era posible decidimos tener las pautas claras y bien definidas antes de comenzar. Esto nos ayudó a trabajar en equipo de forma más organizada y pudiendo facilitar el mantenimiento del código tanto corto como a largo plazo.

### Estándares de codificación:
Fuimos desarrollando el código del obligatorio mediante varias técnicas y buenas prácticas que están detalladas a continuación:

**Limite líneas de código:** En este caso se planteó entre los integrantes, definir un largo de 130 caracteres por línea. Esto hace que sea mas fácil de comprender el código y que no quede tan extenso el recorrido visual horizontal.

**Uso de comentarios:** Realizamos el uso de comentarios para poder facilitar la lectura del código y quien quiera modificar algo que no sea nosotros pueda entender de qué se trata.

*Ejemplo uso de comentarios Javascript:*


**CamelCase:** Este nombre hace referencia a las jorobas de un Camello. Para los elementos que tienen más de una palabra, utilizamos esta metodología con el fin de que los nombres compuestos sean más legibles y tengan mayor claridad.

**Archivos en HTML:** Para los elementos de Javascript y HTML se utilizó nombres estandarizados para mejorar el nivel de aceptación de la página por Google. Gracias a esto también es que mejora la visibilidad.
Elementos con accesibilidad determinada: Utilizamos elementos privados como también públicos, sabiendo que estos últimos podrían dificultar el mantenimiento del código.

**Variables:** Comienzan en minúscula, deben ser fáciles de comprender y nemotécnicas. Si contienen más de una palabra se utiliza CamelCase para diferenciar una palabra de la anterior. Deben dejar en claro que representan y no generar una posible confusión. Una mala práctica sería darle nombre a las variables con números como '1,2,3,4...' , al utilizarlas así no quedaría claro que representa cada una.

**Paquetes:** Los paquetes deben comenzar con minúscula y en caso de contener más de una palabra estas se deben conectar por medio de una barra baja.

*Ejemplo de Paquetes de forma correcta:*


**Indentación:** Se respetan los tabs y los corchetes que abren y cierran cada sentencia para disponer de un código más ordenado y de fácil comprensión. La correcta indentación del código permite comprender que parte de cada método cumple cada función.


### Analizador estáticos de código

Para llevar a cabo este sector, utilizamos la herramienta Lintern, en particular, SonarLint, ya que estaba disponible como extensión de Visual Studio Code. Nos pareció muy útil esta herramienta dado que a medida que el código se escribió, fue reportando los errores y detallando claramente cuál era el error, como solucionarlo y donde estaba ubicado.

A su vez, SonarLint categoriza los errores presentados en distintas categorías y niveles de severidad.

_**Categorías**_

**Bug:** Error que puede dirigir a comportamientos no deseados. De solución inmediata.

**Vulnerability:** Problema de seguridad.

**Code Smell:** Violacion de algún tipo de “buenas prácticas de codificación”.

_**Niveles de severidad**_

**Info:** un hallazgo, algo para mejorar.

**Minor:** Puede afectar levemente la productividad de un desarrollador

**Major:** Defecto significativo,gran impacto en la productividad del desarrollador

**Critical:** Error con pocas chances de afectar funcionalidades

**Blocker:** Error con altas chances de afectar funcionalidades.

A lo largo de la producción del código, tuvimos errores principalmente de tipo Smell Code y Info, cada uno con distintos grados de severidad. Encontramos esta herramienta altamente útil y creemos que será de gran ayuda a lo largo de nuestra carrera tanto estudiantil como profesional.

## Pruebas Unitarias
----------------------

Esta es una de las formas de probar el sistema que se está desarrollando, busca probar si su funcionamiento es correcto; este debería realizarse en módulos y antes de que ese modulo sea agregado al resto del sistema, debe pasar por dicha prueba.

### Metodología:

Las pruebas unitarias fueron realizadas mediante Visual Studio Code.

Lo primero que hicimos fue instalar Jest en el proyecto mediante npm.

Luego creamos para cada clase del dominio su Test correspondiente con el nombre seguido de .test.js

A cada clase del dominio (Estudiante, Profesor y Lección) le hicimos un module.exports para exportar todas las funciones de la clase.

Al principio de la clase .test.js, importamos el Jquery y la clase del dominio mediante el require, para posteriormente definir las pruebas que ibamos a realizar.

* Ejemplo caso de prueba en clase lecciones:


## Interfaz de usuario
------------------------

Para realizar la interfaz de usuario y sus funcionalidades, utilizamos una herramienta que Violeta aprendio en MoonIdeas, empresa de software donde ella trabaja. Esta hearramienta ulitiza *[YiiFramework](https://www.yiiframework.com/doc/guide/2.0/en/intro-yii)* que es un "marco de programación web genérico, lo que significa que se puede utilizar para desarrollar todo tipo de aplicaciones web.Debido a su arquitectura basada en componentes y sofisticado soporte de almacenamiento en caché, es especialmente adecuado para el desarrollo de aplicaciones a gran escala."

*[Yii](https://www.yiiframework.com/doc/guide/2.0/en/intro-yii)* Resulto ser una herramienta de gran ayuda y que llevo a la eficiencia en cuanto a codigo, creando algunas de las funciones JavaScript complementado con funciones hechas por nosotros, (siguiendo su metodologia y estructura) pudimos llegar al producto final.

### Análisis heurístico:

Para este análisis de los principios de usabilidad se siguieron las reglas de Heurísticas de Nielsen, evaluando así:

**Facilidad de uso:** Se puede navegar por la interfaz con sencillez y comodidad. La tecla “Tab” es un botón que permite avanzar de un campo a otro de manera rápida y simple.

**Visibilidad del estado del sistema:** Esta regla se cumple ya que el usuario recibe un feedback cuando realiza las diferentes acciones, por ejemplo al crear una lección, el sistema muestra un mensaje si se creó correctamente o si hay algún campo incorrecto.

**Prevención de errores:** Se controla mediante varias validaciones en todos los registros para que el sistema nunca deje de funcionar. Ejemplo, valor mínimo para campos numéricos, aviso de error si no coloca @ en el email, etc.

**Diseño minimalista:** La interfaz es intuitiva y esto permite al usuario sentirse cómodo y que le sea fácil. Se evita información innecesaria, por lo tanto todo lo que figura en la página es esencial.

**Ayudar a los usuarios a reconocer, diagnosticar, y recuperarse de los errores:** Se intenta que ante toda acción invalida por parte del usuario el sistema le notifique pero que permita continuar su uso normal.

**Libertad y control del usuario:** El usuario tiene un acceso rápido e intuitivo para moverse por todas las pantallas. Puede acceder con total libertad a todas las funciones. El sistema en sí no presenta complejidades, por lo que este aspecto no presenta ningún problema.

**Reconocimiento en vez de memorización:** cada uno de los campos es independiente al otro, se presenta una única instrucción de dos líneas cortas.

**Ayuda y documentación:** se provee al administrador de la página y del sistema las documentaciones pertinentes.

**Consistencia y estándares:** El sistema no muestra problemas a la hora de analizar la consistencia del diseño, ni tampoco genera duda alguna en el usuario.

**Coincidencia entre el sistema y el mundo real:** Nuestra página ofrece elementos al usuario para entender cómo funcionan los diferentes campos que se estén usando, por ejemplo al ingresar el horario aparece con una estructura de calendario que se puede identificar fácilmente lo que es.

### Pruebas con usuarios:

Para tener más pruebas sobre el sistema, invitamos a tres usuarios externos (según Nielsen, cada usuario halla ⅓ de los problemas que se encuentren en el sistema) para que prueben el producto. Cada uno de estos usuarios se va a enfocar en una sección del programa. El usuario 1 probará en su totalidad la sección de estudiantes, el usuario 2 la sección de lecciones y el usuario 3 la de profesores. Al final de sus pruebas, pedimos una leve evaluación considerando eficiencia, eficacia y satisfacción (muy satisfactorio, satisfactorio, poco satisfactorio).

### Primer usuario: Estudiantes

**Características del usuario:** 19 años, utiliza tecnología muy frecuentemente, atareado.

**Eficiencia:** El tiempo requerido para manipular el sistema (agregar, editar, eliminar) fue no mayor a 5 minutos.

**Eficacia:** Al ingresar todos los campos, noto que en el campo de nombre y apellido, se podían ingresar números y caracteres especiales. El resto de los campos los encontró bien.

**Satisfacción:** Satisfactorio. Resaltó el dinamismo y diseño de la página, pero que faltan correcciones en los campos de texto.

**Conclusión:** fácil de usar, leve error en el campo de texto, satisfactorio.

## Segundo usuario: Lecciones

**Características del usuario:** 38 años, utiliza tecnología frecuentemente, muy atareado.

**Eficiencia:** Le resultó fácil y rápido registrar una lección. Total de 8 minutos (agregar, editar, realizar lección, eliminar).

**Eficacia:** Noto que en los mensajes tanto de error como de notificación hay un error en la ortografía.

**Satisfacción:** Muy satisfactorio. Remarcó el funcionamiento del drag and drop.

**Conclusión:** de fácil uso, pequeño error externo al funcionamiento, muy satisfactorio.

## Tercer usuario: Profesores

**Características del usuario:** 82 años, utiliza tecnología con cautela, poco atareado.

**Eficacia:** total de 10 minutos.

**Eficiencia:** Funcionamiento correcto en todos los aspectos (agregar, editar, eliminar)

**Satisfacción:** satisfactorio, difícil de leer la tabla por el tamaño de la letra.

**Conclusión:** más tiempo del esperado, funcionamiento correcto, cambiar tamaño de letra en tabla, satisfactorio.

## Construcción
----------------

### Proceso de Build

Para poder ingresar a la página creada se deben seguir los siguientes pasos:

1. Instalar MAMP
2. Descargar archivo Fis.Oblig.zip (extraerlo al escritorio) y archivo fis_oblig_db.sql de la carpeta "Descargas" (dentro de "Obligatorio 2")
3. Ejecutar MAMP, seleccionar opción MAMP y luego Preferences
4. Seleccionar Web Server
5. Seleccionar Select new document y darle a la carpeta Fis.Oblig/public_html y darle a OK
6. Seleccionar Open WebStart page
7. Seleccionar la opcion Tools y dentro de ella phpMyAdmin (nota: recordar el numero de *server:localhort* al tope de la pagina)
8. Seleccionar new (izquierda pág), colocar el nombre fis_oblig_db y darle al boton Create
9. En la barra de opciones darle a Import y seleccionar el archivo ya descargado llamado fis_oblig_db.sql
10. Darle al botón Go al final de la página
11. En la barra de opciónes darle a Privileges y seleccionar Add user account
12. LLenar los siguientes datos:
User name: fis_user
Host name: Seleccionar opción Local
Password: olqPxFv9Z4qf9Nrg
13. En la sección Global privileges, tickear la opción Check all
14. Darle al botón Go
15. Dentro de *Fis.Oblig/protected/config/db.php* cambiar la opcion port al numero que muestra PhpMyAdmin (nota en el punto 7)


16. Repetir Paso 3
17. Añadir al URL: lecciones/view-add

En caso de que no funcione este método, dejamos en el [link](https://youtu.be/Wnx1u3tBZfA).

### Funcionalidades:

Nos pareció importante desde un principio, el hecho de hacer una página fácil de usar, y que a su vez sea atractiva a la vista del usuario. Dado que nuestra página está referida hacia un público bastante amplio, niños y adolescentes por un lado y jóvenes y adultos como profesores por el otro, decidimos crear la página que su interacción sea intuitiva y de fácil acceso para todas las edades.

Para fomentar la usabilidad de las vistas, nos basamos en 3 principales pilares: la paleta de colores, iconos intuitivos y sobre todo el modelado de la página con una distribución visible de todos sus elementos.

Cada sector de la aplicación está solamente a dos clicks de distancia, logrando una página ágil, dinámica y por ende, simple de usar. Como todo usuario, éstos desean que no sea una página compleja.

Para la paleta de colores decidimos utilizar distintos tonos de azul, para mantenerlo elegante y maduro para los profesores, y divertido para los niños a la hora de utilizar el programa.
Los iconos intuitivos fueron elegidos para cumplir la función de lección, profesor y estudiante, cada uno de estos representando gráficamente cada una de estas palabras.

Al construir el modelado y distribución de la página, éste fue diseñado para que su recorrido sea fácil e intuitivo, y esto no sería posible sin los otros dos pilares.

Por último, también agregamos mensajes concretos, para que sea lo más claro posible para el usuario, siguiendo con la estética del resto de la página, incluyendo el logo de la aplicación y su característico color azul como muestra la siguiente imágen.


## Testing Funcional
----------------------

### Técnicas de pruebas aplicadas:

Una vez finalizado el software, se realizaron dos distintas técnicas de pruebas, las pruebas de “caja blanca” y pruebas de “caja negra” para encontrar defectos y evaluar la calidad del producto.

Las pruebas de caja blanca evalúa principalmente el código y la estructura del producto para realizar distintas pruebas, en otras palabras, la estructura lógica interna de la aplicación. Esta técnica intenta demostrar que los componentes de la aplicación funcionan como deberían funcionar, y se usa para detectar lo contrario.

Por otro lado, las pruebas de caja negra es evaluado en cuanto a las entradas que recibe y sus respectivas salidas, no teniendo en cuenta el funcionamiento interno. Estas pruebas son principalmente generadas desde la interfaz gráfica del programa.

Para obtener un estudio correcto de las pruebas de caja negra, realizamos varios casos de prueba en el registro, modificación y eliminación de los “objetos” que componen el sistema de guitarra para niños (Lecciones, Estudiantes y Profesores).

### Casos de prueba

A la hora de hacer los casos de prueba, tuvimos en cuenta que hay dos tipos de ingresos diferentes: el registro de un estudiante o profesor y el registro de una lección.

**Caso de prueba 1: Registro de Estudiante/Profesor**

Ya que la clase Estudiante y la clase Profesor tienen las mismas variables, optamos por hacer su respectivos casos de prueba como uno. El registro de un estudiante o profesor posee cuatro variables: nombre, apellido, edad e email. Decidimos englobar el nombre y el apellido, ya que posee las mismas características, y clases válidas como inválidas.

**Clases de equivalencia:**


**Generar casos de prueba:**


**Caso de prueba 2: Registro de Lección**

El registro de una lección posee cinco variables, pero nuevamente, resolvimos que la mejor opción era evaluar ambos profesor y estudiante como una sola variable ya que poseen muchas similitudes. Por ende, estaremos evaluando cuatro variables en el registro de una Lección: cancion, tablatura (una imagen), horario y estudiante/profesor

**Clases de equivalencia:**


**Generar casos de prueba:**


### Testing exploratorio

El testing exploratorio es una herramienta generalmente utilizada cuando hay poco tiempo y está basado en sesiones. Una sesión es una unidad básica de testing, no se asimila ni a los casos de prueba ni al reporte de issues.

Al realizar el testing exploratorio, consideramos que el tester, no es desarrollador, eso influye en que no puede corregir los issues que se encuentra, sino que deben ser documentados con precisión para que el desarrollador pueda arreglarlos

**Testing exploratorio 1**

* Aplicación bajo prueba: Interfaz Web

* Unidad de tiempo: 60 min

* Objetivo: Verificación del correcto funcionamiento de agregar Estudiante/Profesor.

* Tester: Nicolás Artola

* Notas: Cuando se ingresa un valor numérico en el campo “Edad”, el sistema permite el ingreso de una cantidad indeterminada de cifras y las toma como válidas. Lo ideal en este caso sería imponer una limitante a dicho campo como 2 cifras. De esta forma se podría ingresar una edad con un valor de 0 a 99, tomando sentido el valor ingresado con la realidad.

Al agregar un Estudiante/Profesor y luego otro con exactamente los mismos datos, queda registrado dos personas que en el sistema no es posible visualizar la diferencia, de tal forma que se puede utilizar la misma persona para diferentes funcionalidades teniendo así un duplicado de este Profesor o Alumno. Esto ocurre por la falta de manejo de un identificador que valide la unicidad (comúnmente conocido como primary key).

En los campos de texto nombre y apellido, éstos permiten la utilización de símbolos y números, lo que puede causar conflicto de datos ya que no existe ningún nombre ni apellido que utilice símbolos o números.

**Testing exploratorio 2**

* Aplicación bajo prueba: Interfaz Web

* Unidad de tiempo: 45 min

* Objetivo: Validar el uso, funcionamiento y apariencia correcta de todos los elementos en los navegadores: Internet Explorer, Google Chrome, Safari, Microsoft Edge.

* Tester: Violeta Clerc

* Notas: En Internet Explorer, al momento de llenar el campo de nombre y apellido a la hora de agregar un Estudiante/Profesor, si los dejamos vacíos, éste lo registra de forma correcta y no muestra el mensaje de error correspondiente.

En cuanto a la funcionalidad de reajuste de tamaño de pantalla, todos cumplen de forma correcta la misma, aunque en Microsoft Edge al no permitir reducir su anchura a un tamaño menor que el 50% del ancho de la pantalla no se pudo evaluar este punto.

También en Internet Explorer, cuando se quiere ingresar el campo nombre y apellido, éste no permite ingresar más de una palabra a la hora de agregar un Estudiante/Profesor. Es decir, si mi nombre es Juan Martín, lo toma como invalido mostrando un mensaje de error.

## Reporte de defectos
------------------------

Al momento de tener una documentación y estructura de código avanzada, fue que comenzamos a reportar los defectos del mismo. Para hacerlo eficientemente y con él un registro apropiado, fue que implementamos el uso de la herramienta de issues de nuestro repositorio GitHub.

Definimos cada issue encontrado con un título, un resumen de que trata, la plataforma en la que se ejecuta, la severidad del mismo, los pasos para reproducir este issue, el resultado actual que ocurre en el sistema, el resultado que esperamos (solución del issue) y si es posible se adiciona una captura de pantalla del defecto en su entorno.

En el momento que se soluciona este issue, realizamos el commit que corresponde y lo cerramos, quedando un registro de que ya no es un problema para nosotros.
Nos resulto muy cómoda esta herramienta en la cual nos ayudó para tener un seguimiento de los bugs y forma organizada saber cuales issues se solucionaron y cuales no.

Se registraron un total de 15 issues de los cuales 11 fueron cerrados, es decir, se pudieron solucionar, y 4 de ellos quedaron en estado abierto.
Para definir la severidad de cada issue utilizamos las siguientes categorías

### Categorías de severidad:

Dentro del área de reporte de defectos, existen tres tipos distintos de severidades (“Alta”, “Media”, “Baja”), siendo “Alta” la más importante y el que se debe reparar con mayor rapidez.

**Severidad “Alta”**

Afecta directamente la funcionalidad del sistema. En caso de que no se corrijan los errores de ésta, se pierden las funcionalidades claves del sistema, o en el peor de los casos, el sistema deja de funcionar. Estos defectos deben ser reparados al instante y posterior a crear versiones definitivas, por ejemplo, hacer todos los commits del obligatorio en la rama testing.

**Severidad “Media”**

Afecta la funcionalidad del sistema de forma moderada. Suelen causar fallas en la funcionalidad del sistema, pero no afecta la funcionalidad general del sistema. Algunas de las fallas que pueden generar los defectos de severidad “Media” son: falta de algún reglamento y mensajes de confirmación de registro, poca navegabilidad de la página.
Consideramos que estas fallas bajan la calidad del software, pero no lo deja inutilizable, por lo que categorizamos estos defectos como detalles para mejorar en cuanto a código y diseño.

**Severidad “Baja”**

Fallas que no afectan en absoluto las funcionalidades del sistema. Estas fallas tienden a ser de interfaz, por ejemplo, estilos y tamaño de letra, la elección de paleta de colores (muy cargado o poco cargado) o faltas de ortografía. El usuario podría utilizar el sistema sin problema, e incluso no notar los defectos bajo la categoría de severidad “Baja”.
Consideramos, de todas maneras, que estos pequeños errores deberían ser solucionados para lograr un sistema de primera categoría.

### Estado general de la calidad de código

Se implementaron todas las herramientas teóricas y prácticas aprendidas durante el curso que ayudaron a facilitar la realización del trabajo. En lo que a calidad global respecta, el equipo cree haber logrado un software que cumple con la mayoría de los requisitos de sistema solicitados.

Se cumplió con uno de los objetivos principales planteados, realizar una interfaz intuitiva y rápida para el usuario. A medida que fuimos desarrollando el código, se fueron identificando errores que supimos ir corrigiendo y así mejorar la calidad del mismo.
Muchas veces los desarrolladores tienden a ignorar fallas que están fuera del entorno de desarrollo, como por ejemplo estándares nuevos de calidad, dificultad de entendimiento para un usuario común, entre otros.

Cumplimos con los estandares de codificacion vistos en clase que nos parecieron más importantes, como la correcta indentación y anidamiento, ubicar correctamente los métodos en su clase correspondiente, correcta utilización de variables, definir métodos con nombres nemotécnicos, entre otros consiguiendo así un software de código ordenado.

En cuanto a la calidad del código mismo, sabemos que podríamos seguir perfeccionandolo, ya que siempre si se busca, se puede encontrar mejoras posibles, pero si se hace un análisis general estamos satisfechos con el trabajo realizado.

## Conclusiónes
----------------

### Trabajo individual

**Violeta Clerc:**

Al iniciar el Obligatorio, nos dividimos tareas en cuanto a la codificación. Si bien ambos hicimos todo, en algunos aspectos, como en el css, predomine yo, ya que me llevo bien con el diseño.

En el sector de JavaScript lo fuimos haciendo entre los dos, haciendo llamadas por Discord nos dividimos las funciones. Una vez arrancada la documentación, también dividimos tareas para usar el tiempo eficientemente, también siguiendo los estándares de calidad de código.

Procuramos la subdivisión de las distintas secciones de la rúbrica, para que ambos podamos hacer un sector de cada sección. Las pruebas unitarias las hicimos entre los dos, en la computadora de Nicolás, vía Discord.

En cuanto a la interfaz de usuario, me focalice más que nada en las pruebas con los usuarios, ya que tengo paciencia y para trabajar con mayores es necesaria. Considerando las pruebas funcionales, me enfoque en las de caja negra.

Por otro lado, en los testings funcionales me enfoque en el caso de prueba (2) y el testing exploratorio (2).

Por último, en el reporte de defectos, supe distinguir las distintas categorías de severidad.

**Nicolás Artola:**

A la hora de realizar la calidad de código del obligatorio, aunque ambos trabajamos en el mismo, yo fui principalmente quien me ocupe de que se cumplan las buenas prácticas y técnicas aprendidas en clase. Ya sea, uso de comentarios, buena indentación, limite de líneas de código, entre otras.

Un aspecto fundamental de nuestro obligatorio fue la interfaz de usuario. Ambos buscamos llegar a tener un software de calidad y eso se llega mediante muchos aspectos, uno de ellos, tener en cuenta las heurísticas de Nielsen.

En cuanto a las pruebas funcionales, me enfoque en las de caja blanca, mientras que en testing funcional realicé el caso de prueba (1) y el testing exploratorio (1).

Finalmente en la categoría reporte de defectos, fui quien utilizó mayoritariamente la herramienta de registro de issues del repositorio a pesar de que el trabajo siempre fue en conjunto.

### Conclusión general

Este proyecto fue un gran desafío para el equipo ya que se presentaban nuevos retos. Nos planteamos como objetivo generar un software de buena calidad, y para lograr eso teníamos que implementar todo lo aprendido a lo largo del curso.

Uno de los puntos que no nos sentimos muy cómodos a la hora trabajar con ellas, principalmente por falta de conocimiento, fueron las pruebas unitarias.
A medida que nos informamos del tema, fuimos aprendiendo y descubriendo a utilizar nuevas herramientas para la parte de pruebas, tanto de interfaz o usabilidad, como también para la codificación y pudimos lograr realizar las mismas. Si hay algo de lo que estamos seguros, es que nos serán muy útiles en un futuro.

En lo que fue la codificación en general, no tuvimos muchos problemas, las herramientas como MAMP nos ayudaron a construir la página a nuestro gusto, siguiendo con las heurísticas planteadas como referencia, sumado a las funcionalidades que proponía el obligatorio.

Un aspecto fundamental que hasta el momento no habíamos trabajado es el de usabilidad y accesibilidad. Al hablar de usabilidad nos referimos a que tan fácil de usar es un sistema y accesibilidad que variedad de gente puede utilizarlo. Descubrimos que hay que tener una cantidad de consideraciones a la hora de asegurar una buena usabilidad y accesibilidad, ya sea en el manejo de los contrastes de color para la visibilidad del usuario, el manejo de elementos que vinculen al usuario con el mundo real, entre otras. Todas ellas formaron parte para llegar a nuestra versión final y poder así generar software de calidad.

El uso de la herramienta de gestión de versiones GIT, a pesar de que tuvimos algunos errores como el de commitear ciertas cosas en ramas que no deberíamos, no tuvimos mucho más problemas que eso.

En resumen, creemos que esta instancia fue muy productiva para nosotros, incorporamos conocimientos nuevos y los pusimos en práctica. Además logramos un buen trabajo en equipo. Creemos que todo esto se va a ver reflejado en el trabajo que se entregó.