Lineamientos técnicos, criterios DOR, DOD.

Objetivo:

Los criterios DOR, tiene como propósito la definición de una de un conjunto de criterios que deben cumplirse antes de que una tarea, historia de usuario o funcionalidad pueda ser considerada como lista para ser abordada por el equipo scrum.

Los criterios de definición de hecho (DOD), tiene como propósito, la definición de lineamientos que debe cumplir la implementación de una historia de usuario para que la misma pueda ser considerada como completada y pueda ser presentada en el incremento una vez finalizada la ejecución de un sprint.

Contenido:

I. Clean Flow(Flujos limpios).

II. Conceptos claves en el proceso de automatización.

III. Convenciones desarrollo.

IV: Proccess templates (Plantillas de trabajo).

V. DOR (Definición de listo).

VI. DOD (Definición de hecho).

I. Clean Flow(Flujos limpios).

1. Flujo principal de subprocesos

• Toda actividad se debe descomponer en módulos o subtareas más simples. Cada tarea representa una actividad completa y se configura de manera independiente, con una responsabilidad única.

• Cada subproceso debe ser escrito de tal manera que pueda ser reutilizado en cualquier subproceso o en cualquier otra automatización.

2. Tipos de variables proyecto.

• Constantes.

  • Nombrar en mayúscula.
  • No varían desde la definición hasta la finalización de la ejecución.
  • Ej. DB_SERVER, DB_USER, DB_PASSWORD.

• Variables temporales o de estado..

  • Se usan para validar estados momentáneos..
  • Son genéricas y se definen previamente al momento que deben ser usadas. .
  • Ej. boolStep, boolRetry, boolIsSuccess, boolExists, boolEmpty, temp.

• Variables de proceso.

  • Nombrar en lowerCamelCase..
  • Se usan para almacenar información del proceso que se puede utilizar en otros puntos o actividades..
  • Ej. rutaReporte, arrayCedulas, boolSubpConfiguracion, countRetryValue.

3. Definición de subprocesos.

• Se deben definir un contexto para las variables de un subproceso, definir los parámetros de entrada y salida, de tal manera que las actividades se puedan probar de manera independiente.

• Cada tarea o conjunto de process steps dentro de un subproceso debe tener sus validaciones y respectivos reintentos.

• Se deben parametrizar las actividades buscando partir y llegar a un punto estable.

4. Definición de variables y parámetros.

• Variables de comprobación subproceso.

  • Nombrar con bool + nombre sp.
  • Ej. boolSubpReadFile

• Parámetros de entrada y salida.

  • Nombrar con la estructura [in|out]_[ambito]_nombreDeVariable en lowerCamelCase.
  • Ej. in_spReadFile_path, out_spReadFile_content

• Variables de subproceso.

  • Nombrar con la estructura [ambito]_nombreDeVariable en lowerCamelCase.
  • Ej. spReadFile_nameFile

5. Pasos parametrización de subprocesos.

1. Nombrar subproceso Subp + Nombre SP (UpperCamelCase) Ej. SubpReadFile.

2. Definir nodo de parámetros con variables de entrada (in_ + contexto + nombre variable) y de salida (out_ + contexto + nombre variable).

3. Definir e inicializar variable de validación de subproceso y variables globales del subproceso.

4. Definir variables del subproceso (contexto + nombre variable.

5. Ejecutar y validar acciones claves.

6. Parametrizar reintentos en caso de error.

7. Actualizar estado de ejecución del SP en caso de éxito.

6. Niveles.

• Las actividades y subprocesos se deben parametrizar de izquierda a derecha, con una extensión moderada que facilité la lectura y entendimiento del subproceso.
• Si el subproceso es demasiado extenso se debe segmentar en flujos principales mas cortos.
• Los niveles de profundidad de un subproceso no deben ser mas de cuatro niveles.
  

7. Normas de parametrización.

• Los subprocesos se deben definir en el orden en que se invocan en sentido vertical.
• Cada que se llame un subproceso se debe asignar el consecutivo. Ej. CallSubpReadFile1, CallSubpReadFile2.
• No deben existir nodos con un mismo nombre.
• los nombres deben ser acordes al conjunto de proccess steps que ejecuta, (verbo + complemento - Ej. AbrirPaginaWeb1).
• Los nodos se nombran en formato UpperCamelCase.
• Los nombres de los nodos no deben tener espacios.
• Los nodos de finalización deber estar hacia abajo.
• No se debe conectar mas de un nodo a un nodo de finalización.
• Los nodos deben estar perfectamente alineados.
• Un nodo de decisión no debe tener mas de 1 conexión de entrada y un nodo de actividad no debe tener mas de 3 conexiones de entrada.
  
• Todos los process step deben estar enumerados y comentados acorde a la acción que se esta ejecutando.
  

II. Conceptos claves en el proceso de automatización.

1. Tipos de excepciones.

• Excepción de sistema.

  • Se producen debido a problemas técnicos o de infraestructura, como errores en la red, fallas en el hardware, errores de conexión con bases de datos, entre otros.
  • Estas excepciones no están relacionadas con la lógica del negocio y suelen ser impredecibles.
  • Si se reinicia el proceso o se restablecen los sistemas podría ejecutarse el proceso.

• Excepción de regla de negocio..

  • Se producen cuando se violan las reglas de negocio establecidas en la aplicación.
  • Pueden ser impuestas por la organización o el cliente y suelen ser específicas del dominio de la aplicación.
  • Estas excepciones son controlables y predecibles por los desarrolladores, ya que se basan en las reglas establecidas.

2. Manejador de excepciones.

• Excepción Handler.
  • Toda automatización debe tener un mecanismo de manejo de excepciones.
  • Es un flujo que se utiliza para manejar errores o excepciones que pueden ocurrir durante la ejecución de una automatización.
  • Se encarga de detectar y manejar excepciones, permitiendo que el programa continúe ejecutándose de forma controlada.
  • Intenta resolver el problema o proporcionar información sobre el error para que el usuario pueda tomar medidas para solucionarlo.

3. Auditoria.

• Sistema de auditoria.
  • Toda automatización debe tener un mecanismo de registro del estado de ejecución del proceso.
  • Registran eventos, actividades o mensajes que pueden contener información sobre errores, advertencias, acciones realizadas, datos de entrada o salida, entre otros detalles relevantes.
  • Son importantes para los administradores de sistemas, desarrolladores y otros profesionales de TI, ya que permiten analizar y solucionar problemas en el sistema o en una aplicación en particular. Los registros también se utilizan para el monitoreo y análisis de seguridad, la auditoría y el seguimiento de las operaciones.
  • Son una fuente importante de información para el mantenimiento y el monitoreo de un sistema, así como para la resolución de problemas y la mejora continua.

4. Sistema de notificaciones.

Toda automatización debe tener un mecanismo de notificaciones.

• Capacidad de un robot de RPA para enviar notificaciones a los usuarios u otros sistemas cuando se produce un evento específico durante la ejecución del robot.
• Incluye reportes de ejecución al control room.

EJ. cuando un robot completa una tarea, puede enviar una notificación al usuario indicando que la tarea se ha completado correctamente o si ha habido algún error durante la ejecución. También puede enviar notificaciones cuando se produce una excepción o un error durante la ejecución del robot, o cuando se necesita una intervención manual por parte del usuario.

5. Estructura del proyecto.

*Estructura de directorios y archivos: *

Toda automatización debe tener un directorio asignado, lo mas cercano a el disco local, con la información del proyecto (archivos de configuración, plantillas, herramientas, insumos. etc.).

• Insumos.
• Plantillas.
• Herramientas.
• Archivos de configuración.
• Documentación.
• Imágenes.
• Logs.
• Screenshots.

No se recomienda usar la carpeta autos.

6. Manejador de parámetros.

Toda automatización debe tener parametrizable desde una fuente externa (Archivos conf., control room … etc.) el valor de los parámetros que puede variar (Ej. Url, Rutas, Formulas).

Se recomienda utilizar el configurador de parámetros de Agility, para variables asociadas al proceso y deban ser modificados por los ejecutores, la configuración técnica debe estar por medio de archivos de configuración.

7. Propiedades del proyecto.

• Se debe nombrar el proyecto con la estructura Agt_[Cliente]_[Proceso] en UpperCamelCase.
• Toda automatización debe estar correctamente diligenciada sus propiedades.
• Por cada automatización se debe solicitar un ID de send report y debe estar asignado en el campo id Proceso.
• Se debe parametrizar variables del manejador de parámetros (si se requiere)

8. Versionado

• Toda automatización publicada debe tener una versión asociada.
• Las versiones 0.x.x se corresponden a la etapa de desarrollo y se basa en el sprint y el consecutivo de publicación. Ej. 0.10, 0.11, 0.12, 0.20…etc.
• Cada versión en productivo debe estar en versiones 1.x o superior.
• Cada publicación de soporte debe publicarse con un consecutivo de la versión ej. 1.01, 1.02, 1.03.
• Si existen control de cambios significativos se debe subir la versión ej. 2.x , 3.x.

Despliegue.

Al momento de publicar una automatización, se debe proporcionar al equipo de soporte:

Descripción del proceso.

• Breve descripción del proceso
• Responsable de la operación por parte del cliente.
• Nombre del cliente, área y proceso.
• Condiciones de ejecución del proceso.
• Tiempos ASIS y tiempos meta TOBE, tipo y valor de ahorro.
• Flujo del proceso.

Datos del proyecto.

• Fecha Inicio
• Fecha Aprobación
• Fecha Fin
• Fecha Producción
• Programador
• Arquitecto

Documentación

• Arquitectura detallada y de contexto.
• Manual de usuario.
• Checklist de prueba.

Automatización

• Zip firmado.
  En el .zip se debe cargar como adjunto la carpeta del proyecto, los insumos no deben tener datos.

III. Convenciones de desarrollo

1. Definición, uso y optimización de variables.

2. Nombramiento de variables.

3. Diagramación.

• Nodos alineados correctamente.
  

• No se debe exceder el numero de conexiones permitidas por nodo.
  

• No se deben cruzar líneas de conexión.
  

• Nodos nombrados correctamente (UperCamelCase, Verbo + Descripción, sin espacios)
  

• Optimización del uso del lienzo. (Nodos ni muy acoplados ni muy dispersos).
  

• Flujos principales definidos en subprocesos, llamados nombrados correctamente
  

• Nivel y profundidad simple y entendible.
  

• Validación de actividades claves parametrizados y ciclos de reintentos parametrizados.
  

• Subprocesos definidos con parámetros de entrada y salida ,que faciliten la ejecución de pruebas unitarias.
  

• Nodos de finalización con una única conexión y ubicados hacia abajo.
  

• No debe existir ciclos infinitos.
  

• Diagramar de Izq. – Der, por niveles de profundidad.
  

• Mal uso de time Wait.
  

• Uso de periféricos vs Native
  

IV. Proccess templates

Plantilla básica proyecto RPA.

• Parametrización ruta de insumos automatización.
• Estandarización y optimización de manejo de archivos de configuración.
• Captura y estandarización parámetros de configuración por defecto.
• Estructura de directorios predefinida.
• Manejo de excepciones básico.
• Sistema de auditoria básico.
• Sistema de notificaciones básico.
• SendReport preconfigurado.

Parametrización ruta de insumos automatización

Estandarización y optimización de manejo de archivos de configuración.

Captura y estandarización parámetros de configuración por defecto.

Estructura de directorios predefinida

Manejo de excepciones

Manejo de excepciones y Sistema de auditoria básico

Sistema de notificaciones básico y SendReport preconfigurado.

Descargar Plantillas

• AgilityRPATransactionProccessTemplate
• UI Interactions

V. DOR (Definición de listo)

VI. Definición de hecho (DOD).

• Implementación cumple con los estándares de calidad definidos.
• Los diagramas o código fueron refactorizados y se encuentran correctamente integrados.
• Pruebas unitarias y funcionales ejecutadas y aprobadas.
• Pruebas rendimiento y no funcionales ejecutadas.
• Pruebas de integración realizadas.
• Caminos alternos y notificaciones en caso de error parametrizadas.
• Todos los criterios de aceptación se cumplen.
• Documentación actualizada.
• Historias validadas y verificadas por el Product Owner o algún miembro del equipo.