Proceso: Solicitudes de servicio para Arquitectura

Objetivo

Modelar los servicios que solicitan las aplicaciones centralizadas a la Oficina de Arquitectura.

Alcance

En principio se considerarán las soiicitudes que hacen las aplicaciones centralizadas a la Oficina de Arquitectura para unificar en las aplicaciones su visión sobre los frontales y las experiencias de usuario.

Cualquier nuevo desarrollo deberá hacerse según la normativa publicada en el espacio del área de Gobernanza y Calidad,

Roles

Independientemente de la metodología que se use, los roles que intervienen en este proceso son:

Flujo del proceso

• El Responsable de producto o bien el proveedor de una aplicación centralizada soicitarán el servicio a la Oficina de Arquitectura, para lo que crearán en el proyecto correspondiente un tipo de registro denominado "Solicitud servicio arquitectura", informando Título y Descripción. el tipo de servicio solicitado (por ahora sólo estará disponible UX/UI como se indica en el alcance) y la fecha en la que se quiere que esté el servicio terminado.
• Ua vez creada la solicitud de servicio, llega al grupo oficina-arquitectura, asignándose el servicio aquel de sus integrantes que se vaya a hacer responsable del mismo. En este punto, puede seguir tres caminos:
  • No aceptar hacer el servicio. En este caso el proceso se acaba.
  • Aceptar hacer el servicio.
  • Solicitar información normalmente a quien haya soliitado el servicio. Una vez que tenga la información requerida, decidirá si acepta o no la ejecución del servicio.
• Si acepta el servicio, éste entrará en fase de planificación del trabajo pendiente de Arquitectura (estado PLANIFICABLE). 
• Cuando Arquitectura planifica el servicio, informa las fechas de inicio y fin estimadas e indica igualmente quién es el proveedor que va a hacerse cargo del mismo.
• En ese momento, la solicitud de servicio queda en estado PARALIZADA y se crea una tarea enlazada con el servicio en el proyecto SCSD Diseño UX-UI (SDPNTRUX) asignada al proveedor que hubiera indicado Arquitectura. El estado de la solIcitud de servicio se mantendrá hasta que no se resuelva la tarea del proveedor.
• Cuando la tarea del proyecto SDPNTRUX se resuleve por parte del proveedor y se valida por parte de la Oficina de Aqruitectura, la solicitud de servicio queda liberada para que pueda ser validada normalmente por el responsable de la Oficina de Arquitectura que la tuviera asignada. Tras la validación, las dos posibles opciones son:
  • Aceptar la solicitud de servicio, pasando a CERRADA.
  • No aceptar la solicitud de servicio, con lo que pasa a estado NO ACEPTADA, pudiémdose en este estado crear subtareas de la propia solicitud de tipo NO CONFORMIDAD para qu sean resuletas por el proveedor de la aplicación. Esa NC una vez resuelta por el proveedor, deberá ser validada por el responsable de Arquitectura que tuviera asignada la solicitud de servicio en ese momento,.Una vez resueltas todas las NCs, acepatará la resolución de la solicitud de servicio pasando a CERRADA.