El objetivo de esta guía es ayudar a los implicados en un proyecto a estimar con mayor precisión el trabajo que se debe realizar en la elaboración de servicios web independientemente de la estimación de la lógica de negocio que contenga dicho servicio, ya que en este punto son los grupos los que tienen toda la información para hacerlo.

¿Qué debo estimar cuando diseño un servicio?

• Análisis: El tiempo que invertirá el equipo en estudiar cómo abordar el servicio.
• Alta del endpoint: El tiempo que costará crear el endpoint del servicio. Esto incluye tanto el alta en sí como las transformaciones de los datos de la lógica de negocio en los DTO que se envíen como respuesta. En este punto no es lo mismo que el servicio sea SOAP o REST ya que los servicios SOAP, por norma general, suelen tener un coste mayor en la definición del servicio como modelado del DTO.
  • Dependiendo del servicio también se tiene que tener en cuenta cómo se devuelven esos datos lo que afecta a la estimación:
    • ¿Deben ir firmados/securizados?
      • En caso de ir securizados se debe estimar si se implementa OAUTH u otro mecanismo. La estimación que se haga no se tiene que trasladar al resto de endpoints que se hagan ya que esto sólo se hace una vez y debería ser común para todos.
    • Si el servicio es REST deben devolverse en formato HATEOAS
    • ¿El servicio debe poder paginarse? Esto afecta tanto a cómo se reciben y devuelven los datos (incluir número de página, etc) a cómo se modela la lógica de negocio.
• Lógica de negocio: El tiempo que el equipo estime oportuno en implementar las características requeridas por el servicio. Esta estimación sólo incluye la lógica de negocio pura de la aplicación no cómo crear el endpoint o como leer y devolver los datos, eso se estima en el "Alta del endpoint".
• Documentación: El tiempo en hacer la documentación del servicio y el cliente para que lo usen otros grupos. La documentación incluye
  • Documentación en formato OpenApi (FundewebJS) o Enunciate (Fundeweb) que incluya todos los detalles necesarios para saber usar el servicio, así como algún ejemplo de uso. En caso de no poder documentar en ninguno de los dos formatos anteriores, documentación en Confluence en el espacio del proyecto con el mismo contenido.
  • Creación de librería cliente y documentación en Confluence de la misma para su uso por parte de otras aplicaciones. El equipo desarrollador del servicio debe mantener el cliente acorde a los cambios que se vayan haciendo en el servicio. Dichos clientes se deberán alojar en archiva.um.es para que los grupos puedan incluirlos mediante una dependencia maven.
• Control de calidad: Estimación de la realización de todas las pruebas de calidad del código requeridas:
  • Realización de test unitarios
  • Realización de pruebas de seguridad: Test de penetración, asegurar que los endpoints privados no son vulnerables, garantizar que los parámetros que se reciben se validan antes de pasarlos a la lógica de negocio, etc.
  • Realización de test de carga: Los accesos al servicio no suponen un problema de rendimiento ni en tiempos de respuesta ni en memoria.
  • Realización de pruebas de aceptación: Verificar que la funcionalidad proporcionada por el servicio es la que quería el demandante del mismo. Permitir que tenga una ventana de pruebas para poder validarlo.
  • Realización de pruebas funcionales: Realizar diversas pruebas de funcionalidad para asegurar que el servicio devuelve las salidas pertinentes en base a los datos recibidos.