PR-03 Gestión de Evolutivos de Pequeño Tamaño

PR-03 GESTIÓN DE EVOLUTIVOS DE PEQUEÑO TAMAÑO
PROCEDIMIENTO INTERNO
Versión del Documento v0.7
10/02/2015
TABLA DE MODIFICACIONES A LOS CAPÍTULOS
Ver.Rev Fecha Modificado Descripción Páginas afectadas

por
0.1 04/03/2009 PC Se adapta generalizando Todas

la aplicación del plan de
Calidad
independientemente de la
SWF
0.2 06/07/2009 PC Se especifica el desglose Todas

del Gestor ESSL o SM en
Bussines Partner (RMC) y
Solution Manager (GAF)
0.3 30/09/2009 PC Se modifica el workflow Pag 9

incluyendo al Gestor de
ESSL en el alta de la
petición.
Se incluye también en el
workflow la tarea de Pag 10
aprobación de DFU y PPU
medida por indicador ANS
Se incluye la definición de Pag 8

Mejora Crítica
0.4 06/10/2009 PC Revisión general tras Todas

validación de ESSL
0.5 16/11/2009 PC Revisión general por Todas

revisión de las actividades
paralelas del
procedimiento de
Desarrollo de Proyectos
0.6 9/12/2009 PC Revisión tras validación de Todas

Gestión Interna
0.7 10/02/2010 PC Adaptación a la última Todas

versión de VU
ELABORA APRUEBA
FECHA 03/03/2014
NOMBRE
ÍNDICE Nº Pág.
1. INTRODUCCION.......................................................................................................... 7
1.1 Objeto........................................................................................................................ 7
1.2 Alcance..................................................................................................................... 7
1.3 Referencias............................................................................................................... 7
1.4 Definiciones............................................................................................................... 7
1.4.1 Evolutivo Pequeño Tamaño................................................................................7
1.4.2 Proyecto.............................................................................................................. 7
1.4.3 Ventanilla Única..................................................................................................7
1.4.4 Aviso................................................................................................................... 7
1.4.5 EPT Crítico......................................................................................................... 8
1.5 Funciones y responsabilidades.................................................................................8
1.5.1 Funciones........................................................................................................... 8
1.5.2 Responsabilidades..............................................................................................8
2. DESCRIPCIÓN DEL PROCESO DE GESTIÓN DE EVOLUTIVOS DE PEQUEÑO

TAMAÑO (EPT’S)................................................................................................................11
2.1 Alta del EPT............................................................................................................11

2.1.1 Obtención de requerimientos de usuario...........................................................11
2.1.2 Valoración.........................................................................................................12
2.1.3 Solicitud realización del EPT.............................................................................13
2.2 Resolución del EPT.................................................................................................13
2.2.1 Evaluación requerimientos................................................................................13
2.2.2 Devolución aviso...............................................................................................13
2.2.3 Bloqueo o Replanficación.................................................................................14
2.2.3.1 Solicitud bloqueo/replan.............................................................................14
2.2.3.2 Contestación solicitud bloqueo/replan........................................................14
2.2.4 Envío resolución...............................................................................................15
2.3 Pruebas del EPT.....................................................................................................15
2.3.1 Pruebas de aceptación.....................................................................................15
2.3.2 Pruebas de usuario...........................................................................................15
2.4 Puesta en Explotación.............................................................................................15
2.5 Cierre del EPT.........................................................................................................16
2.6 Tabla RECI..............................................................................................................16
2.7 Tratamiento Peticiones de Cambio..........................................................................17
2.8 Tratamiento de situaciones especiales....................................................................17
2.8.1 Desistimiento....................................................................................................17
2.8.2 Recatalogación.................................................................................................18
2.8.3 Procedimiento para agrupación de mejoras en proyectos de evolutivo.............19
3. ANEXOS.................................................................................................................... 19
3.1 Anexo 1: Glosario de Términos...............................................................................19

3.2 Anexo 2: Flujo de la Gestión de Pequeñas Mejoras Funcionales............................20
MANUAL DE PROCEDIMIENTOS PÁG. 5/21

1. INTRODUCCION
1.1 Objeto
Describir el proceso de gestión de mejoras a alto nivel.
Formalizar el modelo de gestión entre XXXXXXXX Servicios (ESSL en adelante), y los

proveedores que presten los servicios de Soporte Funcional (SF en adelante) y Software
Factory (SWF en adelante) en la realización de Evolutivos de Pequeño Tamaño (EPT en
adelante) para los Sistemas Técnicos de Generación y Distribución de XXXXXXXX , para
que este se ajuste a los objetivos de productividad y calidad acordados en el marco del
contrato, así como a los requerimientos del Acuerdo de Nivel de Servicio (ANS).
1.2 Alcance
Los EPT’s se encuadran dentro de los servicios de Evolutivo de SF y SWF
Dentro de su alcance están las mejoras y las extracciones con software.
Afecta al personal de XXXXXXXX , SF y SWF implicado en la realización de los EPT’s.
1.3 Referencias
o IT-01 Gestión de Peticiones
o PR-xx Gestión de Valoraciones
1.4 Definiciones
1.4.1 Evolutivo Pequeño Tamaño
Funcionalidad a desarrollar cuyo esfuerzo de realización no supera las 200 horas / hombre.
1.4.2 Proyecto
Conjunto de funcionalidades a desarrollar cuyo esfuerzo de realización es superior a 200

horas / hombre.
1.4.3 Ventanilla Única
Herramienta corporativa de workflow de XXXXXXXX a través de la cual el usuario inicia el

flujo de solicitud de avisos. Esta herramienta se comunica bidireccionalmente con la
herramienta de ticketing de SF y SWF a través de la cual el proveedor gestiona su solución.
1.4.4 Aviso
Nombre genérico que reciben las peticiones gestionadas a través del workflow de VU.
1.4.5 EPT Crítico
Se considerará EPT Crítico aquel que cumpla uno o varios de los siguientes condicionantes:

 Su no realización puede paralizar las funciones básicas del negocio según cambios
en la empresa
 Se considera de imperativo legal
 Es necesaria estratégicamente para la empresa
1.5 Funciones y responsabilidades
1.5.1 Funciones
 UA. Usuario Autorizado (XXXXXXXX )
 AWF. Autorizador de workflow. (XXXXXXXX )
 RMC. Responsable de Módulo Coorporativo (ESSL)
 SM. Solucion Manager (ESSL)
 SF. Soporte Funcional (Proveedor)
 SWF. Software Factory (Proveedor)
 GC. Garantía de Calidad (ESSL).
 OPE. Operaciones (ESSL)
1.5.2 Responsabilidades
Las responsabilidades se definen a través del código de responsabilidad (RECI) RACI en

una tabla global al final de la descripción del proceso. Los códigos de responsabilidad son:
R RESPONSABLE. Es el máximo responsable de la actividad. Incluye autoridad y

derecho de veto. Sólo puede haber un “R” por actividad
E EJECUTOR. Es la persona responsable de la realización de la actividad. Puede

ser una función compartida. En este caso, el grado de responsabilidad viene
(A) determinado por la persona que detenta la “R” de la actividad.
C CONSULTADO. Puede ser consultado para tomar una decisión y/o al realizar una
acción.
I INFORMADO. Es la persona que debe ser informada después de la toma de una

decisión o de la realización de una acción
En términos generales,
- UA es responsable de:
o Solicitar la mejora
o Validar solicitudes de cierre por rechazo
o Validar la solución del EPT en explotación
- RMC es responsable de:

o Validar si el EPT solicitado debe llevarse a cabo
o Validar los rechazos que le son escalados
o Validar y resolver los bloqueos que le son escalados por tratarse de bloqueos de
usuario
o Realizar pruebas de usuario una vez entregado el EPT por el proveedor
o Validar solicitudes de reapertura por solución no conforme enviadas por el usuario
- SM es responsable de:
o Validar, refinar los requerimientos del EPT antes de solicitar su valoración al

proveedor
o Aprobar la valoración del mismo, el DFU y el PPU
o Validar los rechazos del proveedor
o Validar/aceptar/rechazar las solicitudes de bloqueo o replanificación del proveedor,

escalando al usuario los bloqueos del mismo
o Validar la solicitud de reapertura de la solución puesta en explotación procedente del

RMC
o Validar la solicitud de desistimiento del proveedor
o Además, los Gestores de ESSL(SM, Garantía de Calidad), previa notificación al

proveedor y acotamiento del alcance, podrán asumir tareas de responsabilidad SF.
En estos casos, se deberá informar de esta situación en el alta del EPT y acordar
que indicadores de SF no aplicarían en la resolución del EPT..
- AWF es responsable de:
o Aprobar el esfuerzo del EPT una vez aprobado por el SM
- SF es responsable de:
o Dar soporte a los Gestores de ESSL en la definición y/o agrupación de los

requerimientos en mejoras si así se solicita.
o Realizar la valoración del EPT (en tareas propias y de SWF)
o Elaborar el Diseño Funcional de Usuario (DFU) y el Plan de Pruebas de Usuario

(PPU)
o Elaborar el Business Blueprint y definición de la parametrización en los sistemas que

proceda
o Solicitar rechazos, bloqueos o replanificaciones al SM si lo considera oportuno
o Solicitar el desarrollo del EPT a la SWF
o Validar los rechazos de la SWF

o Validar las solicitudes de replanificación o bloqueo de la SWF
o Aprobar el enfoque técnico (DT) elaborado por la SWF
o Validar la entrega liberada por SWF
o Validar las entradas de incidencias procedentes de las pruebas de XXXXXXXX
o Dar soporte a la ejecución de las pruebas (a Garantía de Calidad y/o al Usuario)
o Dar soporte previo a la implantación en el entorno productivo
o Gestionar riesgos, cumplimiento de hitos y desviaciones
o Validar solicitudes de reapertura tras solución
Como actividades complementarias:
 Colaborar con la SWF en la realización del enfoque técnico
 Recepcionar y aceptar el software entregado por la SWF considerando los

informes aportados por Garantía de Calidad
 Asegurar la correcta aplicación y cumplimiento de las metodologías

establecidas
 Definir y gobernar la gestión de la configuración y versiones
 Creación de material formativo o de usuario
- SWF es responsable de:
o Recepcionar y aceptar para desarrollo el Diseño Funcional y de Usuario.
o Colaborar con SF en la valoración para la ejecución de los trabajos propios, así

como la planificación del EPT
o Elaborar el Diseño Técnico.
o Desarrollar el software.
o Ejecución de la parametrización definida por SF en los sistemas que proceda
o Realizar Pruebas Unitarias y de Integración (incluyendo las de Regresión).
o Empaquetar la versión.
o Solicitar los bloqueos o replanificaciones a SF cuando se presente la necesidad
o Solicitar desistimientos si así se ha acordado con XXXXXXXX
Así mismo la SWF podrá colaborar con el SF en las siguientes actividades:
 Determinación de las especificaciones no funcionales relativas a arquitectura,

rendimiento, usabilidad y seguridad de los desarrollos a realizar.
 Elaboración y ejecución del Plan de Pruebas de Usuario.
- Garantía de Calidad es responsable de:
o Establecer las metodologías y directrices de calidad que gobernarán el desarrollo de

proyectos.
o Validar y afinar Planes de Pruebas.
o Verificar la calidad del software.
o Realizar Pruebas de Aceptación previas a las del Usuario.
o Realizar pruebas de regresión antes de autorizar la puesta en producción
o Autorizar la puesta en producción de la versión
- Operaciones es responsable de:
o Realizar la puesta en pre-producción y puesta en producción de los sistemas.
2. DESCRIPCIÓN DEL PROCESO DE GESTIÓN DE EVOLUTIVOS DE PEQUEÑO

TAMAÑO (EPT’S)
El workflow de mejoras, está soportado por la herramienta corporativa de XXXXXXXX

Ventanilla Única (VU). Las comunicaciones entre los actores del proceso descrito a
continuación, se realizan utilizando esta herramienta y la correspondiente herramienta de
ticketing del proveedor, integrada con VU (el uso de esta herramienta de integración u otra
será decidida por el proveedor y consensuada con XXXXXXXX Servicios). El detalle de
actuaciones con las herramientas se encuentra descrito en la IT-01 Gestión de Peticiones.
2.1 Alta del EPT
2.1.1 Obtención de requerimientos de usuario
Los usuarios autorizados transmiten sus necesidades de evolutivo al RMC.
El RMC revisa la solicitud del EPT en el marco de globalidad de su área funcional y la

aprueba, modifica o rechaza según la estrategia de direccionamiento funcional o
presupuestario y de manera acordada con el usuario. Como resultado se generarán los
requerimientos de usuario del EPT.
Una vez aprobada la solicitud de mejora por el RMC, esta es enviada al SM para que
gestione su realización con SF y SWF.
El SM valida la solicitud del EPT pudiendo rechazarla al RMC si no está de acuerdo.
El SM acota si deberá aprobar el esfuerzo del EPT antes de solicitar su valoración y en

función de esto solicita la valoración a SF para aprobación previa o bien solicita la
valoración y planificación de la misma para su realización directa.
Para ello, acuerda la fecha en la que SF le tendrá que devolver la valoración, diseño
funcional, técnico y plan de pruebas de usuario.
SF revisa la solicitud del EPT, pudiendo devolverla para aclaraciones y detalle de

requerimientos o cierre si procede o bien solicitar un bloqueo. (ver apartados 2.2.2.
Devolución aviso y 2.2.3 Bloqueo o replanificación)
A efectos ANS, se descontarán los tiempos que el aviso pase fuera de SF.
En la información de alta del EPT el usuario habrá indicado si realizará pruebas sobre la
mejora antes de la puesta en explotación.
2.1.2 Valoración
Con los requerimientos de usuario definidos, SF, con el apoyo que precise de la SWF,
realiza la valoración total del EPT (trabajo SF + trabajo SWF) según el método especificado
en el PR-Gestión de Valoraciones.
Si el EPT está marcado como que necesita ser aprobada su valoración antes de su
realización, SF envía el esfuerzo al SM para ser aprobado, junto con el DFU y PPU.
 SM aprueba esfuerzo: lo envía al AWF para su aprobación, que a su vez, podrá:
o Aprobar el esfuerzo y solicitar la planificación del EPT a SF
o No aprobar el esfuerzo y retornarlo hacia el SM para ser revisado
o No aprobar el esfuerzo y cerrar definitivamente el EPT
 SM no aprueba el esfuerzo: envía la devolución por no aceptación del esfuerzo a SF

para ser revisado en espera de un nuevo envío.
Una vez el esfuerzo fuera aprobado, SF enviará la planificación al SM.
Si el EPT no necesitara que su valoración sea aprobada previamente, SF comunica el

esfuerzo a SM junto con una planificación acordada con la SWF, el DFU y el PPU.
Para la realización de estos documentos se utilizarán las plantillas DIS-050-Definición EPT y

CON-020-Reporte Pruebas EPT
El envío de la valoración, DFU y PPU debe realizarse antes de la fecha comprometida

medida por el indicador SFEP01 ‘Porcentaje de valoraciones, Diseños Funcionales, Planes
de Prueba y Material de Usuario entregadas en plazo’.
El SM valida la documentación (DFU y PPU) y coordina su aprobación con el RMC que a su

vez lo hará con el usuario.
La calidad de los entregables será medida por el indicador SFEC01 ‘Porcentaje de Diseños
Funcionales, Planes de Prueba y Material de Usuario no conformes’
2.1.3 Solicitud realización del EPT
SF solicita la realización del EPT a la SWF.
Para ello aporta el DFU, el Plan de Pruebas de Usuario y la Valoración del mismo.

2.2 Resolución del EPT
2.2.1 Evaluación requerimientos

La SWF recepciona el EPT y realiza una validación general del mismo.y de los documentos
asociados.
Si necesitara más información, realizaría una devolución del aviso según apartado 2.2.2.
Si la mejora lleva la información necesaria, debe proceder a la aceptación de los

requerimientos según normativa establecida en la IT-01 Gestión de Peticiones, apartado
2.4.2.1.
Si la SWF acepta los requerimientos procede a desarrollar.
Realizará también el Diseño Técnico (donde opcionalmente, podrá participar SF) y el Plan
de Pruebas de Sistemas del EPT y los enviará a SF y a Garantía de Calidad
respectivamente para su validación.
En el proceso de resolución puede surgir la necesidad de realizar una nueva devolución o

bien solicitar un bloqueo o una replanificación. Estas casuísticas se detallan en los
siguientes apartados.
2.2.2 Devolución aviso
La SWF realiza una devolución del EPT a SF indicando la causa de la misma.
SF evaluará el rechazo de la SWF y podrá aceptarlo o rechazarlo.
a) Si lo rechaza, significa que el EPT volverá a ser solicitado a la SWF, ampliando la

información faltante o rechazando lo solicitado.
b) Si lo acepta, pasará el aviso al SM de ESSL para que corrobore su decisión.
El SM a su vez podrá de nuevo aceptar o rechazar la devolución de SF.
b1 ) Si lo rechaza, el aviso volverá a ser enviado a SF para llegar a un acuerdo sobre

la devolución del aviso.
b2) Si lo acepta, el aviso pasará al RMC para que este a su vez acepte o rechace. Si
finalmente acepta el rechazo, el aviso pasará al UA para que acepte o rechace. Si eté
acepta se cerrará informando al RMC, SM y al proveedor de dicha situación.
Las contestaciones a través de reapertura por devolución que lleguen a SF, si

procedían de la SWF, serán enviadas automáticamente a la misma para continuar con
el desarrollo.
2.2.3 Bloqueo o Replanificación
Durante la fase de resolución del aviso es posible que ocurra algún evento que impida
seguir con la resolución del mismo (Bloqueo) o bien la necesidad de cambiar la fecha
comprometida de resolución por una replanificación a acordar con el SM.
Si en el proceso de resolución no se da ninguna de estas situaciones, la descripción del

mismo continuará en el apartado 2.3.2 Envío resolución, si no en el apartado siguiente.

2.2.3.1 Solicitud bloqueo/replan
En ambos casos (replanificación o bloqueo) SF enviará al SM la información del bloqueo o

la replanificación.
El aviso quedará a la espera de la contestación del SM de ESSL.
2.2.3.2 Contestación solicitud bloqueo/replan
El SM evaluará si la solicitud de bloqueo o replanificación es de responsabilidad ESSL o de

responsabilidad Usuario. En el primer caso, el SM validará dicha solicitud y en el segundo,
la derivará al RMC para ser validada.
Se describen a continuación las posibilidades de aceptación/denegación (del SM o del RMC

según afectación):
a) Bloqueo aceptado:
El SM/RMC informará a SF de dicha aceptación, que a su vez informará a SWF.
El aviso continuará en este estado hasta que el SM compruebe que ya no se da la

situación que no permitía resolver el aviso y lo desbloqueé informando entonces a la
SWF.
b) Bloqueo no aceptado:
El SM devuelve la mejora al SF para continuar con su resolución informando del

motivo de su denegación.
c) Replanificación aceptada:
El SM devuelve la mejora al SF para continuar con su resolución oficializando las

nuevas condiciones de la replanificación.
d) Replanificación no aceptada:
El SM devuelve la mejora al SF para continuar con su resolución informando del

motivo de su denegación.
Una vez las contestaciones a los bloqueos o replanificaciones lleguen al SF, si procedían de
SWF, serán enviados automáticamente a la misma para continuar con el desarrollo.
A efectos de ANS de la fábrica, siempre que SF corrobore la solicitud de bloqueo o

replanificación, se descontarán los tiempos que el aviso pase fuera de la SWF.
2.2.4 Envío resolución
Una vez la SWF ha desarrollado el EPT, realizará las pruebas unitarias y de integración.
Una vez pasadas las pruebas internas, la SWF realizará el manual de cambios con la
plantilla TVR-010-Control de Cambios y enviará la versión empaquetada a SF.
SF comprobará la entrega y realizará pruebas antes de enviar la solución a ESSL.
Si encontrara defectos de entrega, los remitirá a la SWF para que sean solucionados con
una nueva entrega.

El envío de la solución a ESSL deberá realizarse antes de la fecha de resolución
comprometida según el indicador SWEP02 ‘Porcentaje de resolución de peticiones de
evolutivo en plazo’.
2.3 Pruebas del EPT
2.3.1 Pruebas de aceptación
Garantía de Calidad, junto con el apoyo de SF, realizará las pruebas de aceptación del EPT.
Si encuentra errores, serán reportados a la SWF (filtrados por SF previamente) para su
corrección y la realización de una nueva entrega.
Garantía de Calidad realizará también inspecciones sobre el software desarrollado.
SF realizará la aceptación del EPT en función de los informes de resultados de Garantía de

Calidad.
2.3.2 Pruebas de usuario
Una vez realizada la aceptación de ESSL, el usuario, con el apoyo que precise de SF,
realizará pruebas de aceptación si así lo solicitó en el alta del EPT. Los posibles errores
encontrados serán contrastados por Garantía de Calidad y por SF, y reportados a la SWF
para su solución y realización de nueva entrega.
A efectos de ANS de la fábrica, si hubiera reaperturas por reporte de error en pruebas, se

descontarán los tiempos que la mejora pase fuera de la SWF y se sumarán los de la nueva
resolución.
Tras las pruebas de usuario, Garantía de Calidad realizará una batería de pruebas de
regresión. Si encontrara errores, los remitirá a SF para su corroboración y envío a la SWF
para solución y nueva entrega.
Una vez pasadas las pruebas de regresión, deberá aprobar la puesta en producción del
EPT.
2.4 Puesta en Explotación
El departamento de Operaciones de ESSL, en la fecha planificada, realiza la puesta en

producción de la versión que contiene la mejora.
La SWF o el SF, a través de los retenes, realizará el apoyo que se precise.
2.5 Cierre del EPT
El usuario validará la mejora tras la puesta en producción de la misma.
Existe un tiempo máximo llamado de demora para que el usuario valide la solución.
Si el Usuario no evalúa la solución en ese tiempo, la evaluación pasaría al RMC.

Finalmente, si no ha habido confirmación de la solución una vez superados los tiempos de
demora acordados, se procederá al cierre del EPT de manera automática.
Si el Usuario acepta la solución, procederá al cierre de la misma,
Si el Usuario rechaza la solución, podrá reabrirla para solicitar una nueva solución. Esta
reapertura será evaluada por el RMC y si procede, enviada de nuevo al SM, si este
corrobora la reapertura, la envía al SF, para que finalmente, si la acepta, la envíe de nuevo
a la fábrica para su solución.
A efectos de ANS, las reaperturas son medidas por el indicador SWEC01 ‘Porcentaje de
peticiones de evolutivo resueltas que se han reabierto por falta de conformidad del
peticionario’..
2.6 Tabla RECI (RACI)

Tareas Procedimiento UA RMC AWF SM GC OPE SF SWF
Alta del EPT E R/E E E

Valoración I I R/E E
Aprobación valoración R/E E I I
Realización DFU y Plan de Pruebas I I I R/E I
Aprobación DFU y Plan de Pruebas E R/E E I I
Solicitud realización del EPT R/E I
Evaluación requerimientos C R/E
Devolución I I I R/E R/E
Contestación a la devolución E E R/E E I
Comunicación Planificación I I I R/E E
Solicitud bloqueo/replanificación I I R/E R/E
Contestación bloqueo/replanificación C R/E I I
Desbloqueo I I R/E I I
Resolución I I I I R E
Pruebas de Aceptación I R/E C I
Pruebas de Usuario I R/E I I C I
Pruebas de regresión R/E C I
Pta en explotación I I I I R/E I E
Cierre R/E I I I I I
2.7 Tratamiento Peticiones de Cambio
Cualquier modificación de las especificaciones que ESSL pueda solicitar fuera de workflow
y que por tanto afecte a la valoración y planificación realizadas, deberán gestionarse
mediante el envío, por parte de ESSL del documento Inventario de Cambios..
 Si la petición de cambio se produce antes del análisis y planificación de la misma,

SF debe realizar una devolución solicitando la documentación que falte (doc
Inventario de Cambios, etc)
 Si se produce después del análisis, SWF solicitará una replanificación a través de

SF, enviado al SM para aprobación la nueva valoración y fecha de compromiso en
función del cambio de alcance. Se enviará como documentos anexos el Inventario
de Cambios con la parte de afectación del cambio rellena, la hoja de valoración y el
nuevo DFU actualizado.

2.8 Tratamiento de situaciones especiales
2.8.1 Desistimiento
Una vez el EPT está en el circuito del proveedor, es posible que surja la necesidad de
realizar un desistimiento del mismo (por acuerdo con ESSL) de anulación sin puesta en
explotación.
El desistimiento sólo lo podrá realizar el proveedor una vez el EPT esté analizado (y
siempre que no se trate de una reapertura por solución no conforme).
Posibles casuísticas:
1) el aviso se encuentra en el proveedor cuando se pide su desistimiento:
El proveedor analizará y resolverá el aviso incluyendo la información de

desistimiento (flag que lo marque y costes acordados)
La solicitud de desistimiento llegará al SM que podrá:
a1) aprobarla: el aviso se finalizará informando a todos los implicados
b2) rechazarla: el aviso llegaría a SF para que revisara la solicitud de reapertura por
desistimiento no aprobado
El SF a su vez podrá:
b21) aprobar la solicitud y enviar reapertura del aviso a SWF
b22) rechazar la solicitud y enviar una devolución al SM para proceder según

lo indicado en el apartado 222.Devolución aviso, apartado b)
2) el aviso se encuentra en algún estado fuera del circuito del proveedor y aun no ha sido
desarrollado
El SM o RMC harán llegar el aviso de nuevo al proveedor (reapertura por devolución si

estaba en devolución, desbloqueo si estaba bloqueado, o resolución replanificaciones o
solicitudes de bloqueo aun sin contestar), indicando que se el movimiento se produce
por desistimiento.
Una vez el aviso en el proveedor, éste procederá según casuística 1).
3) El aviso se encuentra en algún estado fuera del circuito del proveedor y ya ha sido
desarrollado
Si está en estados de pruebas de aceptación, o de pendiente aprobación para la puesta

en producción, GC, o el RMC y SM realizan los pasos para incluir una reapertura por
error en pruebas (marcando que se trata de desistimiento) para dejar el aviso en
situación de casuística 1)
2.8.2 Recatalogación
Dentro de los workflows establecidos para avisos, cuando en el alta inicial, un aviso llega al
CAU, éste llevará a cabo una tipificación del mismo, asignando el tipo de servicio que
corresponda, así como el subtipo (en el caso de Soportes) o bien, devolviendo el aviso al
SM para que sea solicitado como EPT si así lo considera.

A continuación, el aviso llega al Proveedor para ser resuelto, y puede ocurrir, que en el
proceso de análisis, éste considere que la tipificación asignada no es correcta, proponiendo
cambiar el tipo de servicio al adecuado según su criterio.
Una vez en este estadio, existirán 3 métodos de realizar la recatalogación en función de los
servicios entre los que se produzca:
1. Recatalogación de aprobación automática
El proveedor cambiará el tipo y subtipo de servicio en su sistema sin necesidad de informar

a través de devolución a XXXXXXXX . En el movimiento de análisis viajará la nueva
información catalogada.
Aplica en las siguientes solicitudes de recatalogación:
 De Soporte a Correctivo (incidencias con sw)
 De EPT a Correctivo (incidencias con sw)
 De EPT a Soporte
2. Recatalogación de aprobación expresa de XXXXXXXX antes de continuar desarrollo
El proveedor solicita la aprobación de la recatalogación a través de una devolución que

espera respuesta para continuar.
Aplica en las siguientes solicitudes:
 De Correctivo a EPT
 De Soporte a EPT
3. Recatalogación de aprobación de XXXXXXXX que permite continuar el desarrollo
El proveedor solicita la aprobación de la recatalogación a través de una devolución pero no

espera la respuesta para continuar.
En caso de que la solicitud de recatalogación sea rechazada, no se admitirán nuevas

propuestas de recatalogación.
Aplica en las siguientes solicitudes:
 De Correctivo (incidencia con sw) a Soporte , subtipo Correctivo de datos

(incidencia sin sw)
4. Tanto en la casuística 2 como en la 3, para los solicitudes de recatalogación desde

Correctivo para las que el proveedor no haya avanzado el estado del aviso (todas en el
tipo 2 y las que lo cumplan en el tipo 3) y para las que el usuario acepte el rechazo,
llegarán a FINA, recatalogándose automáticamente a Consulta Operativa.
2.8.3 Procedimiento para agrupación de mejoras en proyectos de evolutivo
Se puede dar el caso de mejoras cuya resolución se ha iniciado con el presente

procedimiento y que ESSL considere que se deban incluir en un proyecto de agrupación de
mejoras.
En estos casos, la mejora deberá anularse en la herramienta corporativa de ticketing VU a

través de la solicitud de desistimiento, y tratarse dentro del procedimiento de Gestión de
Desarrollo de Proyectos.
3. ANEXOS
3.1 Anexo 1: Glosario de Términos
EPT Evolutivo de Pequeño Tamaño
ESSL XXXXXXXX Servicios
ANS Acuerdo de Nivel de Servicio
DFU Diseño Funcional
PPU Plan de Pruebas de Usuario
DT Documento de Diseño Técnico
3.2 Anexo 2: Flujo de la Gestión de Pequeñas Mejoras Funcionales

EPT Garantía de
Usuario Final RMC AWF SM Calidad Operaciones SF SWF
PACA SFRE
Y
OK SI OK AL SFAL Analiza
PRGA
Crea Aviso EPT EPT información
T BL A
L SFDV
SI
PREG
Cierra SI RE SI
Acepta PCCF SI Acepta Rechaza o
SI rechazo rechazo Bloqueo
bloquea
PAGF
Acepta PAUA SI
rechazo SWF
SI REAW SI
AECD 3 Comunica
T Acepta Acepta esfuerzo Aprobación
SI PAAW SI 3
L 4
Cierre PPCD Pendiente Mov.
aviso planificación Análisis
A
CSBR
11 Cliente 5 Comunica H
USBR
FINA SI planificación
L
7 DCDS
Acepta A
Acepta Analizado B
L SI 10 En desarrollo
SI
7 SI SI
Bloqueo Analizado B 7 S B L
Bloqueo SFAN
SI 8 8 PPAC SI
SI Pruebas Bloquea Rechaza, bloq
Bloqueado Movimiento C A Rechazo
Movimiento OK o replanifica o replan
desbloqueo Bloqueado
desbloqueo PUNC
BLUS
7 SI
BLCA 7 SI
SI
SI Pruebas
CAF H G Desistimiento
PPRR SI SFSO
Pruebas SI
C OK Entrega OK
PREP SI PROD
Regresión Permiso PAPP
SI OK PRO
D S SFIP
Instalación
RESO S Producción
Incidencia H
PREC SI
SI Acepta Acepta SI Acepta SI D
solución Reapert. Reapert.
PAGF SFRE
PUSA CDES Y
G AL
Cierre
aviso Aprueba
desist.
11
FINA
SI

PR-03 Gestión de Evolutivos de Pequeño Tamaño

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PR-03 Gestión de Evolutivos de Pequeño Tamaño

Cargado por

Copyright:

Formatos disponibles

PR-03 GESTIÓN DE EVOLUTIVOS DE PEQUEÑO TAMAÑO

Versión del Documento v0.7

Ver.Rev Fecha Modificado Descripción Páginas afectadas

0.1 04/03/2009 PC Se adapta generalizando Todas

0.2 06/07/2009 PC Se especifica el desglose Todas

0.3 30/09/2009 PC Se modifica el workflow Pag 9

Se incluye la definición de Pag 8

0.4 06/10/2009 PC Revisión general tras Todas

0.5 16/11/2009 PC Revisión general por Todas

0.6 9/12/2009 PC Revisión tras validación de Todas

0.7 10/02/2010 PC Adaptación a la última Todas

2. DESCRIPCIÓN DEL PROCESO DE GESTIÓN DE EVOLUTIVOS DE PEQUEÑO

2.1 Alta del EPT............................................................................................................11

3.1 Anexo 1: Glosario de Términos...............................................................................19

MANUAL DE PROCEDIMIENTOS PÁG. 5/21

Describir el proceso de gestión de mejoras a alto nivel.

Formalizar el modelo de gestión entre XXXXXXXX Servicios (ESSL en adelante), y los

Los EPT’s se encuadran dentro de los servicios de Evolutivo de SF y SWF

Dentro de su alcance están las mejoras y las extracciones con software.

Afecta al personal de XXXXXXXX , SF y SWF implicado en la realización de los EPT’s.

o IT-01 Gestión de Peticiones

o PR-xx Gestión de Valoraciones

1.4.1 Evolutivo Pequeño Tamaño

Conjunto de funcionalidades a desarrollar cuyo esfuerzo de realización es superior a 200

1.4.3 Ventanilla Única

Herramienta corporativa de workflow de XXXXXXXX a través de la cual el usuario inicia el

1.4.5 EPT Crítico

MANUAL DE PROCEDIMIENTOS PÁG. 7/21

 Se considera de imperativo legal

 Es necesaria estratégicamente para la empresa

1.5 Funciones y responsabilidades

 UA. Usuario Autorizado (XXXXXXXX )

 AWF. Autorizador de workflow. (XXXXXXXX )

 RMC. Responsable de Módulo Coorporativo (ESSL)

 SM. Solucion Manager (ESSL)

 SF. Soporte Funcional (Proveedor)

 SWF. Software Factory (Proveedor)

 GC. Garantía de Calidad (ESSL).

 OPE. Operaciones (ESSL)

Las responsabilidades se definen a través del código de responsabilidad (RECI) RACI en

R RESPONSABLE. Es el máximo responsable de la actividad. Incluye autoridad y

E EJECUTOR. Es la persona responsable de la realización de la actividad. Puede

I INFORMADO. Es la persona que debe ser informada después de la toma de una

o Validar solicitudes de cierre por rechazo

o Validar la solución del EPT en explotación

- RMC es responsable de:

o Validar los rechazos que le son escalados

o Realizar pruebas de usuario una vez entregado el EPT por el proveedor

o Validar solicitudes de reapertura por solución no conforme enviadas por el usuario

o Validar, refinar los requerimientos del EPT antes de solicitar su valoración al

o Aprobar la valoración del mismo, el DFU y el PPU

o Validar los rechazos del proveedor

o Validar/aceptar/rechazar las solicitudes de bloqueo o replanificación del proveedor,

o Validar la solicitud de reapertura de la solución puesta en explotación procedente del

o Validar la solicitud de desistimiento del proveedor

o Además, los Gestores de ESSL(SM, Garantía de Calidad), previa notificación al

- AWF es responsable de:

o Aprobar el esfuerzo del EPT una vez aprobado por el SM

o Dar soporte a los Gestores de ESSL en la definición y/o agrupación de los

o Realizar la valoración del EPT (en tareas propias y de SWF)

o Elaborar el Diseño Funcional de Usuario (DFU) y el Plan de Pruebas de Usuario

o Elaborar el Business Blueprint y definición de la parametrización en los sistemas que

o Solicitar rechazos, bloqueos o replanificaciones al SM si lo considera oportuno

o Solicitar el desarrollo del EPT a la SWF