Anexo II. Guía de estimación de servicios web

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.

Es importante destacar que, si podemos elegir el tipo de aplicación de servicios web que vamos a realizar, intentemos decantarnos por una aplicación de servicios REST en FundewebJS, ya que a día de hoy la infraestructura disponible para este tipo de aplicaciones nos permite unos desarrollos más ágiles con gran flexibilidad. 

Estimación de servicios.

A la hora de estimar un servicio web tenemos que indicar si es un único endpoint o conjunto de los mismos. Lo que debemos estimar es el trabajo que supondrá cada endpoint, pudiendo además dar una estimación del servicio completo resultado de la suma de todos los endpoints. No obstante lo importante es tener la estimación cada endpoint concreto

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

• 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.
    • Si el servicio es SOAP se debe modelar un XMLSchema para estructurar la comunicación.
    • ¿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.

Plantilla para estimación

De cara a facilitar el trabajo de estimar servicios por parte de los grupos y homogeneizar la información de los mismos proponemos una plantilla a rellenar, no obstante para cualquier comentario y/o mejora podéis poneros en contacto con MNCS.

Ejemplo

Supongamos que para la web institucional se nos pide un conjunto de servicios que provean una serie de datos públicos relativos al profesorado y el centro. Dicho servicio constará de varios endpoints según los requisitos que nos hayan transmitido.

Como sólo nos han pedido servicios a la hora de planificar nuestro proyecto el escenario por el que debemos optar mayoritariamente es una pila de servicios REST ya que actualmente son los que mayor auge tienen y nos dan una gran flexibilidad. Esa pila de servicios REST la diseñaríamos sobre una aplicación FundewebJS por el mismo motivo. No obstante en este punto puede haber excepciones pero, por regla general si nos puden un conjunto de servicios deberemos crear un proyecto FundewebJS aunque haya uno Fundeweb de gestión. Esto es así porque se pretende separar los proyectos de gestión y su lógica, de los proyectos orientados a servicios. Esto no significa que siempre sea así ya que, como se ha mencionado antes puede haber excepciones que lleven a ubicar los servicios en proyectos Fundeweb o NoFundeweb, pero como norma general debemos ir a servicios REST en FundewebJS.

Ahora que ya tenemos decidido la tecnología y el framework sólo nos queda estimar el trabajo