Historial de página

...

• Solicitar información, al solicitante si tiene dudas.
• No aceptar la documentación, teniendo que aportar el solicitante un nuevo PID, es decir, volverá a tener permisos de edición.
• Aceptar si la documentación está revisada y correcta.

Los motivos por los que la documentación asociada a la PL se rechaza, se resumen en:

• Incongruencias entre lo que se indica en la PL y lo que se registra en el PID:
  • Entornos diferentes (o no reflejados en el PID), información de si existen o no cortes de servicio o incluso plataformas distintas. Recordad siempre que es fundamental elegir bien la plataforma en la creación de la PL porque el PID se crea en la página de la plataforma.
  • Versiones o entregas diferentes.
  • Observaciones registradas en la PL que son incoherentes con lo que se indica en el PID. Recordad que esas observaciones nunca pueden suponer una ampliación o modificación de lo que se indica en el PID, en todo caso una restricción.

• Falta de especificación de forma explícita de parámetros solicitados en pasos del PID para cada uno de los entornos. Será motivo de rechazo que estos parámetros vengan indicados a modo de ejemplo.

• Incongruencias en la codificación entregada por el proveedor. En el caso de que no se especifique ninguna referencia concreta al respecto, la codificación utilizada es pk15.( NLS_LANG=SPANISH_SPAIN.WE8ISO8859P15)

• Incongruencia entre los nombres de los scripts indicados en el PID y los que se adjuntan en la herramienta. Recordad que para las PLs de datos no deben adjuntarse scripts en la PL, sólo se considerarán válidos los aportados en la SVD puesto que pasan la revisión de la Oficina de Calidad. Será por tanto motivo de rechazo solicitar en el PID la ejecución de un script que no se haya adjuntado a la SVD. Será igualmente motivo de rechazo solicitar la ejecución de parte de scripts.

• No indicar en la PL el campo de planificación detallada si se indica en el PID la necesidad de una planificación por fases para realizar validaciones.

• La no existencia de esquemas de BBDD y plataforma destino necesarios en la ejecución de cada paso del PID.

• Incluir en el PID información de instalaciones completas en versiones no iniciales. Recordad qué si la versión a instalar no corresponde con un despliegue inicial, el PID sólo debe indicar los cambios que se deben realizar en esta instalación exclusivamente, con lo que es una mala práctica “copiar y pegar” la documentación de despliegues anteriores.

• No incluir un procedimiento de marcha atrás. Recordad que nunca hacer un backup de la BBDD o de un servidor de aplicaciones es un procedimiento autorizado de marcha atrás.

• Solicitar la modificación de los .WAR y/o .EAR

• No reflejar la información de los datasources necesitados y de cómo instalarlos tratándose de una versión inicial.

• Solicitar regenerar por pl más de 20 escenarios.

• Marcar en una PL de datos el campo de ventana horaria sin haber acordado una ventana de ejecución.

• No tener el código a desplegar en el repositorio de software habitual (DML).

• Que los cambios solicitados en la PL no estén en concordancia con la normativa recomendada (por ejemplo, que se indique que se haga con TOAD).

Al finalizar la revisión de la documentación la PL estará en estado PLANIFICABLE que indica al solicitante que se ha finalizado el ciclo de lectura de documentación y ya ha sido aprobada. En este estado, y aunque CTI esté leyendo la documentación, el peticionario de la PL va a poder:

...