...

Para poder documentar las APIs utilizaremos la iniciativa OpenAPI que establece un lenguaje común para describir los diferentes elementos necesarios para realizar la documentación. Dentro de un proyecto FundewebJS estarán cargadas las librerías necesarias para poder generar esta documentación directamente desde Java, a su vez la guía Documentar APIs con OPENAPI indica cómo podemos configurarlo y utilizarlo.

6. Calidad

La revisión de la calidad de los desarrollos es un paso imprescindible en el desarrollo de los mismos y así se indica en MEDEA P9. Gestión de la calidad del software no obstante, en Mi Campus, al estar dividido entre APIs de servicios distribuidas y un frontend único hay ciertas peculiaridades que debemos tener en cuenta:

• Pruebas de código fuente: Se realizarán tal y como se indica en MEDEA
• Pruebas de accesibilidad web: Sólo se tienen que realizar cuando se realicen cambios en el frontend del proyecto. Deberán ajustarse a los plazos que indica en OAW y se recogen dentro de la metodología.
  • ¿Si hago un pequeño cambio en el frontend de algún servicio tengo que hacer el análisis de la pantalla y actualizar la declaración de accesibilidad?
    • Si el cambio es pequeño y no incorpora elementos nuevos no es necesario porque ya estarán contemplados en la declaración existente. En caso contrario se deberá analizar y, si incorpora nuevos incumplimientos, modificar la declaración de accesibilidad existente.
  • ¿Si hago un cambio sustancial o introduzco un servicio nuevo tengo que hacer el análisis de la pantalla y actualizar la declaración de accesibilidad?
    • En este caso sí que es obligatorio hacer el análisis de la pantalla para detectar nuevos incumplimientos posibles. La declaración de accesibilidad sólo se deberá actualizar si se detectan incumplimientos nuevos.
  • ¿Cuándo debo hacer el informe de accesibilidad que se presenta al Observatorio de Accesibilidad Web?
    • Este informe se hace una vez cada 3 años, salvo que MNCS pida que se haga expresamente, independientemente que durante ese periodo se hayan puesto en marcha nuevos servicios o no.
    • Cuando venzan los 3 años se deberá hacer el informe basándose en todos los análisis de las pantallas ya realizados y ampliando con los servicios nuevos que todavía no tengan el análisis hecho.
• Pruebas de seguridad: Se realizarán tal y como se indica en MEDEA
• Pruebas funcionales: En el caso de mi campus todas las pruebas funcionales de las APIs se deben hacer con Cucumber. De esta manera tenemos, a la vez, test funcionales en el código y pruebas funcionales actualizadas en todo momento. Esto supone un gran beneficio ya que, gracias a cómo se describen los test con Cucumber podemos alinearlos directamente con los requisitos dados por el responsable de la API y utilizar el propio lenguaje usado para describirlos, lo cual facilita el asentamiento del dominio y un punto común entre responsable del producto y API desarrollada.
• Pruebas de carga: Se realizarán tal y como se indica en MEDEA. Se deberán realizar en local para asegurar que la aplicación tiene un buen rendimiento antes de lanzarlos en los servidores con el departamento de sistemas. Desde MNCS se recomienda usar JMeter y VisualVM (en local) para lanzar el test y medir la memoria RAM utilizada. No obstante se puede utilizar cualquier herramienta que permita obtener, al menos, los siguientes resultados:
  • Por cada petición diferente que haga nuestro test
    • Tiempo medio de respuesta
    • Porcentaje de error
    • Bytes transmitidos
    • Número de peticiones realizadas
  • A nivel global:
    • Memoria RAM máxima
    • Memoria RAM mínima
    • Evolución de la memoria RAM durante la ejecución del test
• Pruebas de usabilidad: Se realizarán tal y como se indica en MEDEA
• Pruebas de aceptación: Se realizarán tal y como se indica en MEDEA. En este caso también pueden servir de apoyo los test Cucumber realizados en las pruebas funcionales ya que deberían cubrir todos los requisitos del proyecto.

7. Rendimiento