copia no controlada - CPBA...2.4. Gestión de la Disponibilidad y Continuidad del Servicio 2.5....

PROCEDIMIENTO GENERAL PG-T-01 Rev. 10

Sistemas - Gestión de Servicios Informáticos Página 1 de 23

1. OBJETIVO Asegurar la correcta gestión de los Servicios Informáticos alineados con las necesidades de la organización, con calidad y valor añadido para los clientes internos y externos, asegurando una optimización de los costes y garantizando la seguridad de la entrega en todo momento. 2. ALCANCE Comprende la gestión y administración de los siguientes servicios:

2.1. Catálogo de Productos y Servicios 2.1.1. Aplicativos (Sistemas CPBA) 2.1.2. Aplicativos Terceros 2.1.3. Boletines electrónicos 2.1.4. Conectividad e Internet 2.1.5. Correo electrónico 2.1.6. Disco de Red 2.1.7. Documentación del SGC ON-LINE 2.1.8. Firma Digital 2.1.9. Impresión 2.1.10. Puesto de trabajo 2.1.11. Sitio Web Institucional 2.1.12. WEBMAIL

Para ello se organiza en las siguientes actividades:

2.2. Gestión de Incidentes 2.3. Gestión de Cambios 2.4. Gestión de la Disponibilidad y Continuidad del Servicio 2.5. Gestión de la Seguridad de la información

Luego, se manifiesta la medición de la gestión:

2.6. Indicadores Operativos de la gestión de los servicios TICs 3. DEFINICIONES Seguridad de la información: entendida como la preservación de la confidencialidad, integridad y disponibilidad de la información. Confidencialidad: garantía de que acceden a la información, sólo aquellas personas autorizadas a hacerlo.

Integridad: mantenimiento de la exactitud y totalidad de la información y los métodos de procesamiento.

Disponibilidad: capacidad de un servicio o componente para realizar la función que le es requerida en un momento determinado o en un período de tiempo determinado (1). También

1 Según IRAM-ISO/IEC 20000:2008

copia no controlada



garantía de que los usuarios autorizados tienen acceso a la información y a los recursos relacionados con la misma, toda vez que lo requieran (2)

Incidente: todo evento que no forma parte del funcionamiento normal de un servicio y que causa o puede causar una interrupción o una reducción de la calidad de ese servicio. Los Incidentes son gestionados a través del sistema CRM Incidentes.

Mesa de Ayuda de Servicio Técnico: grupo de apoyo de atención al cliente que realiza una gran parte del total del trabajo de soporte técnico. El objetivo es servir como punto de contacto los usuarios y el área de Sistemas para realizar consultas, reclamos o pedidos de Soporte Técnico por los Servicios Informáticos prestados.

Infraestructura de Tecnologías de Información: conjunto de recursos humanos, hardware (equipos), software (programas), enlaces de comunicaciones e instalaciones edilicias necesarios para prestar los servicios de tecnologías de la Información y comunicación. Servicio Informático o Servicio TICS (Servicio de Tecnología de Información y Comunicación): servicio provistos por el área de sistemas al cliente interno para cubrir necesidades de sus procesos. Incidente Crítico: aquel incidente que detiene la ejecución de un proceso de realización o tiene un impacto grave en un Matriculado-Afiliado; que no existe una alternativa para ser subsanado por parte del usuario. Ejemplos de incidentes críticos

El Sistema CPBA de Matrículas muestra un mensaje de error durante el Alta de un Trámite de Rehabilitación de Matrícula Profesional. El mismo mensaje de error aparece en todas las computadoras disponibles.

El Sistema CPBA de Beneficios Previsionales muestra un mensaje de error que impide realizar el Alta de un Trámite de Jubilación o Pensión. El mismo mensaje de error aparece en todas las computadoras disponibles.

No es posible ingresar al Sistema CRM Consultas, muestra un mensaje de error. El mismo mensaje de error aparece en todas las computadoras disponibles.

Incidente No Crítico (o Estándar): aquel incidente que no afecta la continuidad de ejecución de un proceso de realización y no tiene impacto grave en un matriculado-afiliado.. Ejemplos de incidentes que pueden ser subsanados por el usuario y por lo tanto no considerados como Críticos:

Que una computadora de escritorio esté fuera de servicio y que sea posible utilizar una computadora alternativa.

Que un servicio (correo electrónico) no esté disponible o tenga alguna falla y la tarea del usuario pueda hacerse de otra forma (comunicación telefónica).

CRM Incidentes: sistema informático utilizado para registrar y hacer seguimiento de las Consultas, Pedidos y Reclamos por Soporte Técnico. 2 Según IRAM-ISO/IEC 17799

copia no controlada



Sistema CPBA (también denominado Software de Aplicación, Aplicación o Aplicativo) es un producto software concebido por el Cliente Interno como una herramienta más para la ejecución de sus procesos implementado por personal del área de sistemas. Sistema Informático de Gestión de Tercero: producto software y/o servicio enlatado o estándar de mercado, adquirido a un tercero y adaptado a las necesidades del Cliente Interno. Sistema de Gestión de Requerimientos: sistema informático que permite a los usuarios cargar requerimientos al área de Sistemas orientados al Análisis y Programación de los Sistemas CPBA así como a los Datos que por ellos se administran. En general estos requerimientos son:

Nueva Funcionalidad: función que no existía antes en el sistema, que se incorpora. Cambio de funcionalidad: función que ya existe en los sistemas y se solicita un cambio. Falta funcionalidad: el sistema no contempla una función que debería estar, y hoy la

realiza personal de sistemas. Esto incluye consultas y actualizaciones sobre la base de datos en forma manual.

Análisis/Corrección de Casos: casos de análisis de la información que hacen necesaria la intervención del personal de sistemas para realizar correcciones y/o sólo consultas de datos

Error del Sistema: fallas en los sistemas detectados por el usuario y corregidos. Riesgo: contingencia o proximidad de que suceda algo que tendrá un impacto negativo en los objetivos, en un proceso de la organización. Se mide en términos de una combinación entre la probabilidad de ocurrencia de un evento y su consecuencia. Usuario: Autoridades y Empleados de la Instituciones que son consumidores de los Servicios Informáticos. Usuario Clave: personal del Cliente Interno asignado para formular requerimientos al Área de Sistemas para responder a necesidades de sus procesos. Fase de Inicio: En esta fase se establece el objetivo del negocio con el fin de delimitar el alcance del sistema, saber qué se cubrirá y delimitar el alcance del proyecto. Además se realiza el relevamiento de los requerimientos de usuario. Fase de Elaboración: Su objetivo principal es realizar el análisis de los requerimientos funcionales, el diseño la aplicación y plantear la arquitectura del sistema a desarrollar. En esta fase se acumula la información necesaria para el plan de construcción y se obtiene la suficiente información para hacer realizable el caso del negocio. Fase de Construcción: Su objetivo principal es alcanzar la capacidad operacional del sistema. En esta fase a través de sucesivas iteraciones e incrementos se desarrolla el software, listo para operar.

copia no controlada



Fase de Implementación: Su objetivo principal es realizar la entrega del sistema operando, una vez realizadas las pruebas de aceptación por un grupo conformado por recursos pertenecientes al área solicitante y al área de sistemas, habiendo efectuado los ajustes y correcciones que sean requeridos AF: Analista Funcional RTI: Responsable de Tecnologías de Información ARQ: Arquitecto de Aplicaciones AAS: Administrador de Ambientes de los sistemas AP: Analista Programador RSI: Responsable de Proceso Sistemas CI: Cliente Interno UC: Usuario Clave SOLREQ: Documento de Solicitud de Requerimientos VISALC: Documento de Visión y Alcance ESPREQ: Anexo Especificación de Requerimientos del VISALC ADMRIE: Anexo Administración de Riesgos del VISALC PLNPRO: Plan de Proyecto ESPFUN: Anexo Especificación de Funcionalidades al VISALC CASACEPUSU: Documento Casos de Aceptación del Usuario QA: ambiente de calidad para realizar las pruebas de las versiones de los sistemas. COPRO: Comité de evaluación de proyectos conformado por el Analista Funcional (AF), Analista Programador (AP), Responsable de Tecnologías de Información (RTI), Arquitecto de Aplicaciones (ARQ) y el Responsable de Sistemas (RSI). Mail: mensaje de correo electrónico utilizado para notificaciones. SGR.cpba.com.ar: sistema de gestión de requerimientos. PATRA: Papel de trabajo, documento sin formato preestablecido elaborado por el usuario. 4. RESPONSABILIDADES Gerencia de Sistemas y Tecnología Informática - Gerente Gerencia de Sistemas y Tecnología Informática - Responsable de la Administración de Infraestructura Tecnológica Gerencia de Sistemas y Tecnología Informática - Responsables de Arquitectura de Sistemas Gerencia de Sistemas y Tecnología Informática - Responsable de Análisis Funcional 5. DESARROLLO El área de Sistemas debe garantizar la disponibilidad de los servicios informáticos en apoyo a los procesos Gestión de Matrículas Profesionales, Atención Afiliados y Otorgamiento de Beneficios Previsionales mediante una adecuada Infraestructura de servicios TICs, el cual abarca la administración de un conjunto de recursos (hardware, software, comunicaciones, aplicativos) y dar soporte a los mismos.

5.1. GESTIÓN DE INCIDENTES El objetivo de la Gestión de Incidentes es resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible, procurando: Detectar cualquiera alteración en los servicios TICS. Registrar y clasificar estas alteraciones.

copia no controlada



Asignar el personal encargado de restaurar el servicio según se define en el acuerdo de servicio correspondiente.

Ante una falla en los sistemas o servicios informáticos, si ésta se detecta en una Delegación o Receptoría, el usuario debe verificar la lista de comprobación de acuerdo al documento IT-T-01 Verificación Servicio de Internet para determinar si la falla es un problema menor que está en sus manos resolver. A continuación se describen las principales actividades de la Gestión de un Incidente.

5.1.1. REGISTRO DE CASO El usuario comunica un incidente a través del CRM Incidentes, o bien vía correo electrónico o telefónicamente en caso de no tener disponible el CRM Incidentes. El usuario cuenta con el Instructivo I-T-02 Manual de Usuario CRM Incidentes para registrar el Incidente. Personal de Sistemas también puede detectar un incidentes por medio de una aplicación o servicio, que puede generar una alerta automática, o bien por tareas propias de monitoreo. La Mesa de Ayuda de Servicio Técnico toma el incidente registrado por el usuario, o bien lo registra si el usuario no pudo hacerlo.

La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo.

El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.

Se realiza también la comprobación de que ese incidente aún no ha sido registrado. Es frecuente que más de un usuario notifique el mismo incidente y por lo tanto han de evitarse duplicaciones innecesarias.

5.1.2. ATENCIÓN PRIMARIA DEL CASO La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo.

El proceso de clasificación debe implementar los siguientes pasos:

Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.

Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.

Asignación de recursos: si la Mesa de Ayuda de Servicio Técnico no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).

copia no controlada



Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al

incidente (abierto, activo, cancelado, resuelto) y se estima el tiempo de resolución del incidente en base al Acuerdo de Servicio correspondiente y la prioridad.

El Personal de Mesa de Ayuda de Servicio Técnico evalúa si existe una solución preestablecida. Incluso apela a consultar la Base de Conocimiento.

Si conoce el método de solución, se asignan los recursos necesarios.

En caso de no conocer una solución preestablecida, escala el incidente a un nivel superior de Servicio Técnico.

Si el Nivel 1 de Servicio Técnico no pudo arribar a una resolución del incidente, recurre a Técnicos de Nivel Superior (Nivel 2). Este se lo denomina Escalamiento Funcional.

Si el Nivel 2 tampoco arriba a una resolución, o bien el Incidente está fuera de los parámetros preestablecidos en los acuerdos de servicio, se escala al Nivel 3. A este se lo denomina Escalamiento Jerárquico.

También se produce un Escalamiento Temporal: Del Nivel 1 al Nivel 2 si se supera el 50% del plazo previsto para la resolución del incidente. Del Nivel 2 al Nivel 3 si se superó el plazo de resolución prevista.

5.1.3. RESOLUCIÓN Y CIERRE Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos (CRM Incidentes) para que los agentes implicados dispongan de la información sobre el estado del mismo.

Si el Incidente requiere un cambio que no forme parte del estándar vigente en cuánto a Infraestructura de Tecnología de Información o alguna Aplicación CPBA, se debe gestionar un Requerimiento vía Sistema de Gestión de Requerimientos, iniciando una Gestión de Cambio. Se debe continuar con el seguimiento del requerimiento y dar por finalizado el Incidente.

Si el Incidente fuera recurrente y no se encuentra una solución definitiva al mismo se deberá realizar las actividades propias de la Gestión de No Conformidades, Acciones Correctivas y Preventivas para el estudio detallado de las causas subyacentes.

Cuando se haya solucionado el incidente tenemos:

CRM Incidentes confirma con los usuarios la solución satisfactoria del mismo vía correo electrónico, en espera de su conformidad para un cierre definitivo. Es dable incorporar el proceso de resolución a la Base de Conocimiento de CRM Incidentes si luego del análisis así se establece conveniente. Reclasifica el incidente si fuera necesario. Cierra el incidente.

copia no controlada



5.1.3.1. Tratamiento de incidentes que dependen de Terceros Cabe aclarar qué, cuándo el cierre de un Incidente no dependa del personal del área de sistemas sino de un tercero, se podrá dar por cerrado el Incidente antes del vencimiento de los plazos con el debido registro de los motivos del cierre. En caso que no se haya podido dar una resolución definitiva, se deberá crear un nuevo Incidente (nuevo caso) con la categoría adecuada para su seguimiento. Ver Instructivo IT-T-06 Clasificación de Incidentes para mayor detalle.

5.1.4. ANÁLISIS DE LOS INCIDENTES En forma mensual y como parte de las actividades para obtener indicadores operativos, se realiza un análisis de los Incidentes para monitorear los niveles aceptados en cuánto a incidentes por Falta de Mantenimiento Preventivo así como Incidentes de Seguridad de la Información. Éstos últimos con foco en la continuidad de las operaciones en términos de disponibilidad e integridad (capacidad) de los servicios informáticos. En síntesis, los incidentes se clasifican en:

Falta de Mantenimiento: cuando el incidente se pudo haber evitado o disminuido la probabilidad de aparición con tareas de mantenimiento preventivo.

Falla de Seguridad: cuándo el Incidente es de carácter crítico que compromete la cobertura prevista, e impide o dificulta el manejo de contingencia como estaba previsto.

Así mismo, se determina si el incidente afecta a un proceso dentro del Sistema de Gestión de Calidad según la Institución afectada (Consejo Profesional o Caja de Seguridad Social), o bien se trata de un proceso fuera del alcance del SGC. En este último caso, el incidente no participa del cálculo de los indicadores del SGC según a la Institución que corresponda.

Ver instructivo I-T-06 “Clasificación de Incidentes” para conocer el criterio de clasificación de los incidentes.

El análisis mensual nos permite identificar patrones recurrentes y entonces hacer un análisis de causas y posibles correcciones, iniciando así una Gestión de No Conformidades, Acciones Correctivas/Preventivas u Oportunidades de Mejora.

copia no controlada



5.2. GESTIÓN DE CAMBIO La Gestión de Cambio tiene por objeto la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI. La Gestión de cambios en general se instrumenta a través de Proyectos, los cuales se componen de tareas, tiempos y recursos para hacerlos posible. La Gestión de Cambios alcanza tanto a proyectos de Desarrollo y Mantenimiento de los Sistemas Informáticos de Gestión (Análisis, Diseño, Programación, Pruebas, Ajustes y Correcciones, Puesta en Línea) así como proyectos de Infraestructura de Tecnologías de la Información (Almacenamiento de Información, Servicios de Correo Electrónico, Firma Digital, Seguridad Informática, etc.).

5.2.1. GESTIÓN DE REQUERIMIENTOS Y PROYECTOS

5.2.1.1. FASE DE INICIO

5.2.1.1.1. REGISTRO DE REQUERIMIENTO El Usuario Clave plantea su requerimiento a través del SGR.cpba.com.ar habilitado a tal fin. Puede optar por adjuntar el documento de Solicitud de Requerimientos u otro documento considerado como papel de trabajo propio del Usuario Clave, sin tener un formato preestablecido.

5.2.1.1.2. ANÁLISIS PRELIMINAR DE LOS REQUERIMIENTOS El Analista Funcional analiza los requerimientos solicitando al Usuario Clave modificaciones o ampliaciones en el caso que fuera necesario. El Usuario Clave amplia o modifica el requerimiento si fuera requerido por el Analista Funcional. El Analista Funcional realiza el relevamiento preliminar obteniendo mayor información del Usuario Clave a través de diversas técnicas (cuestionarios, entrevistas) generando registros de los avances ya sea a través de Minutas de Reunión, ampliación del requerimiento volcado en el SGR.cpba.com.ar, o bien sobre el documento acordado con el usuario. Durante esta actividad surge la disyuntiva si el requerimiento tiene una magnitud considerable como para gestionar el mismo como un proyecto. El criterio a utilizar para considerar un requerimiento o conjunto de requerimientos como un proyecto, es si cumplen con alguna de las siguientes condiciones: Realización mayor a 2 semanas. Requiere una innovación en tecnología de información. Requiere una nueva arquitectura con tecnología de información en uso. Es requisito entonces que el Analista Funcional confeccione el documento de Visión y Alcance, Especificación de Funcionalidades u otro documento que registre evidencia de las características del proyecto y así haya sido acordado con el usuario.

copia no controlada



5.2.1.1.3. ANÁLISIS DE LA VIABILIDAD TÉCNICA En caso que se trata de un proyecto según alguno de los criterios precedentes, así como que el o los requerimientos requieran algún tipo de innovación tecnológica, se debe analizar la Viabilidad Técnica en el marco del Comité de Evaluación Técnica de Proyectos, formado por el Responsable de Proceso Sistemas, el Analista Funcional, Responsable de Arquitectura de Aplicativos y el Responsable de Tecnologías de Información. En el caso que el proyecto no fuera técnicamente viable el mismo puede ser Cancelado o Suspendido. En dicho caso un miembro del Comité de Evaluación de Proyecto informa al Cliente Interno el motivo vía mail, y registra en el SGR.cpba.com.ar los motivos. El Analista Funcional realiza el análisis de riesgos del proyecto. Si el proyecto requiere una arquitectura de sistemas nueva, o nuevas tecnologías de información, pueden participar del análisis de riesgos el Responsable Proceso Sistemas, Analista Programador y el Responsable de Tecnologías de Información. Si se hubieren identificado riesgos, el Analista Funcional los vuelca en la sección correspondiente en el mismo documento VISIÓN Y ALCANCE o bien en el documento a utilizar acordado junto con el Usuario Clave. Si el proyecto es viable se continúa con las tareas de esta fase. El Responsable de Sistemas junto con el Cliente Interno realizan el análisis de viabilidad económica del proyecto, Si el proyecto no fuera viable, es decir, si no hubiera recursos o presupuesto para su realización, deberá cancelarse. En caso contrario, se continúa con las tareas de esta fase. El Analista Funcional conjuntamente con el Analista Programador realiza la estimación preliminar de esfuerzo del proyecto en base al documento VISIÓN Y ALCANCE o documento de Requerimientos acordado con el Usuario Clave. Se elabora una propuesta de Módulos (o entregables) preliminar y se vuelcan en el SGR.cpba.com.ar, en la sección “Plan de Entregas de Sistemas”. Si la dimensión e impacto político del proyecto lo demanda y así se acuerda como conveniente con el Cliente Interno, el Analista Funcional junto con el Responsable Proceso Sistemas elaboran el documento de Plan de Proyecto versión Preliminar. El Analista Funcional y/o el Responsable Proceso Sistemas presenta al Usuario Clave el documento VISIÓN Y ALCANCE (o documento de Requerimientos acordado con el Usuario Clave o registro en el SGR.cpba.com.ar) para su aprobación, en caso que la magnitud de los requerimientos justifique el tratamiento como un proyecto. Este documento conforma el entregable de la Fase de Inicio. Si el Usuario Clave no aprueba dicho documento es necesario volver a la tarea de relevamiento de requerimientos con el objetivo de ampliar o modificar el documento VISIÓN Y ALCANCE (o documento de Requerimientos acordado con el Usuario Clave o registro en el SGR.cpba.com.ar) y otros documentos de carácter opcional utilizados. La no aprobación se realiza vía un mail de modificaciones o ampliaciones de requerimientos.

copia no controlada


Sistemas - Gestión de Servicios Informáticos

Página 10 de 23

Si el Usuario Clave aprueba el documento presentado se continúa con las próximas tareas. La aprobación se realiza vía un mail de aprobación de los entregables de la Fase de Inicio. El Cliente Interno y el Responsable Proceso Sistemas realizan la Revisión de la Viabilidad del Proyecto (coyuntura de recursos disponibles, otros proyectos en curso, limitaciones presupuestarias). En el caso que el proyecto no fuera viable el mismo puede ser Cancelado o Suspendido. Si el proyecto es viable se continúa con las tareas de la Fase de Elaboración.

5.2.1.2. FASE DE ELABORACIÓN

5.2.1.2.1. ELABORACIÓN CASOS DE ACEPTACIÓN DEL USUARIO Es requisito que el Analista Funcional elabore una primera versión del registro Casos de Aceptación del Usuario, luego de realizar el Análisis de los Requerimientos. La excepción será cuando de mutuo acuerdo entre Usuario Clave y Personal de Sistemas, se acuerda que la elaboración del registro de Casos de Aceptación del Usuario la realice el mismo Usuario Clave. Es requisito que el Usuario Clave y el Personal de Sistemas realicen conjuntamente la tarea de enriquecer y priorizar el registro Casos de Aceptación del Usuario, apelando a su mayor conocimiento de los procesos, a su mayor experiencia de campo. Como metodología de trabajo conjunta entre el Usuario Clave y el Equipo de trabajo de Sistemas, se deberá analizar en cada proyecto la necesidad o conveniencia de hacer una revisión del ciclo de vida del Producto o Servicio objeto de la gestión de cambio. Esto permitirá mitigar riesgos de impacto del cambio dentro del mismo proceso gestionado por el Cliente Interno o incluso otros procesos relacionados y administrados por otro Cliente Interno. Esta tarea se basará en la experiencia del Usuario Clave sobre sus procesos, y en la información sobre la composición de los sistemas que pueda aportar el equipo de trabajo de sistemas. Es requisito que el Usuario Clave apruebe el registro de Casos de Aceptación del usuario, así como los otros registros de carácter optativo que pudieren haber sido elaborados como parte del Proyecto. Esto es, Minutas de Reunión, Documento de Especificación de Funcionalidades (con bocetos de pantallas), Documento Visión y Alcance, y otros documentos de carácter optativo señalados en el PG-T-01, sección Gestión de Cambios. Es requisito del Personal de Sistemas así como del Usuario Clave la realización de las pruebas en base al registro Casos de Aceptación del Usuario aprobados. La realización de los casos de prueba determinará el grado de estabilidad y confiabilidad que tendrá el Sistema CPBA, consecuentemente una medida del riesgo que se asumirá una vez puesto el sistema en línea. Cabe la aclaración que cuanto menor es la cantidad de casos de prueba realizados respecto del total de casos priorizados y acordados con el usuario, mayor probabilidad de aparición de incidentes por error en el Sistema CPBA posterior a su puesta en línea.

copia no controlada



Página 11 de 23

5.2.1.2.2. ANÁLISIS DETALLADO DE LOS REQUERIMIENTOS El Analista Funcional entrevista al Usuario Clave con el objetivo de relevar los requerimientos de usuario en detalle. Este relevamiento se basa en lo registrado en los correos electrónicos, documentos de SOLICITUD DE REQUERIMIENTOS y DOCUMENTO VISIÓN Y ALCANCE o documento de Requerimientos acordado con el Usuario Clave. Luego de finalizado el Relevamiento detallado de los requerimientos de usuario, el Usuario Clave o el Analista Funcional puede generar el documento Especificación de Requerimientos como anexo del documento VISIÓN Y ALCANCE o documento de Requerimientos acordado con el Usuario Clave, si la dimensión de los requerimientos lo ameritan (complejidad, extensión). El Analista Programador junto con el Analista Funcional y el Responsable de Arquitectura de Aplicativos, realiza la definición de la arquitectura tomando como base el documento de requerimientos aprobado en la fase anterior. El Analista Funcional entrevista al Usuario Clave con el objetivo de evaluar en detalle la especificación de funcionalidades (casos de uso o funcionalidades), el diseño propuesto de las funcionalidades que responderán a los requerimientos planteados (mapa o maqueta de pantallas, boceto de cada pantalla, boceto de reportes). Esta tarea se realiza en base a lo registrado en el documento de requerimientos aprobado en la fase anterior. El Analista Funcional genera minutas de reunión por cada reunión realizada o bien vuelca las novedades en los documentos acordados con el Usuario Clave. Si se evalúa conveniente, el Analista Programador junto con el Analista Funcional diseña el prototipo de la aplicación. En ese caso, el Analista Programador genera el prototipo de aplicación si fuese necesario. El Analista Funcional luego realiza una nueva revisión del registro Casos de Aceptación del Usuario. Si el mismo sufre cambios, se vuelve a elevar al Usuario Clave para revisión. Este registro será el documento base para conformar la Planificación de Casos de Prueba Preliminar. El Analista Funcional realiza el análisis de riesgos del proyecto en esta fase. Si fuera conveniente (se identificara un nuevo riesgo que no es de carácter funcional), hace participar al Responsable Proceso Sistemas, Responsable de Tecnología de Información y Responsable de Arquitectura de Aplicativos. El Analista Funcional puede utilizar el anexo de Administración de Riesgos o bien especificar los riesgos en el DOCUMENTO VISIÓN Y ALCANCE o documento acordado con el Usuario Clave. Si existiera alguna novedad tecnológica, el Analista Funcional revisa el diseño de los componentes, módulos y subsistemas junto con el Responsable de Arquitectura de Aplicativos y el Responsable de Tecnologías de Información. El Analista Funcional realiza el diseño del modelo de datos junto con el Analista Programador. El Analista Funcional conjuntamente con el Responsable Proceso Sistemas y el Analista Programador realizan la estimación del proyecto en base al DOCUMENTO VISIÓN Y ALCANCE, Caso de Aceptación del Usuario y posibles anexos (Especificación de Funcionalidades, Especificación de Requerimientos, Prototipo) o documento acordado con el usuario.

copia no controlada



Página 12 de 23

Con la estimación finalizada el Analista Funcional elabora el Plan de Entregas (revisión del Plan de Entregas Preliminar). Si el proyecto tuviera una dimensión e impacto político considerables, el Responsable Proceso Sistemas genera el documento de Plan de Proyecto. El Analista Funcional conjuntamente con el Responsable Proceso Sistemas presenta al Cliente Interno los documentos de DOCUMENTO VISIÓN Y ALCANCE, Casos de Aceptación del Usuario, Plan de Entregas y posibles anexos para su aprobación. Estos conforman los entregables de la Fase de Elaboración. Si el Cliente Interno no aprueba dichos documentos es necesario volver a la tarea de relevamiento y especificación de funcionalidades con el objetivo de ampliar o modificar los documentos correspondientes. La no aprobación se realiza vía un mail de modificaciones o ampliaciones de funcionalidades o prototipo/maqueta. Si el Cliente Interno aprueba los documentos presentados se continúa con las próximas tareas. La aprobación se realiza vía un mail de aprobación de entregables de la Fase de Elaboración. El Cliente Interno y el Responsable Proceso Sistemas realizan la Revisión de la Viabilidad del Proyecto. En el caso que el proyecto no fuera viable el mismo puede ser Cancelado o Suspendido. El Responsable Proceso Sistemas conjuntamente con el Analista Funcional y el Analista Programador realizan un Plan de Trabajo detallado para la construcción e implementación del sistema tomando como guía el Plan de Entregas, comprometiendo tareas, tiempos y personal del equipo así como de soporte de proyectos en general. Si el proyecto es viable se continúa con las tareas de la Fase de Construcción.

copia no controlada



Página 13 de 23

5.2.1.3. FASE DE CONSTRUCCIÓN El Analista Programador y el Analista Funcional revisan el diseño de la aplicación en el caso de ser necesario. El Comité de Evaluación de Proyectos realiza nuevamente un análisis de la viabilidad técnica, si algo ha cambiado. Inclusive se realiza una revisión del análisis de riesgos. Si no aprueba el diseño es necesario volver a la tarea de revisión del Visión y Alcance o documento acordado con el usuario en la fase de Elaboración. El Administrador de los Ambientes de los Sistemas realiza la configuración de los ambientes de desarrollo y calidad (pruebas). El Analista Programador realiza la programación de los componentes, módulos o subsistemas de acuerdo a lo especificado en el documento VISIÓN Y ALCANCE, Casos de Aceptación del Usuario y documentación anexa, o documento acordado con el usuario generando una versión Preliminar de la aplicación. El Analista Programador ejecuta las pruebas unitarias en base al documento de Casos de Aceptación de Usuario Sección Casos de Prueba (si fuera acordado con el usuario una priorización de los casos). Si las pruebas no son satisfactorias el Analista Programador realizará un nuevo ciclo de programación haciendo las correcciones y ajustes y actualizando la versión Preliminar, volviendo a ejecutar las pruebas unitarias. Si las pruebas son satisfactorias se continúa con las próximas tareas de esta fase. El Administrador de Ambientes de los Sistemas realiza la implementación de la Versión Preliminar de la aplicación en el Ambiente de Calidad (o pruebas). El Analista Funcional realiza las pruebas funcionales junto con el Usuario Clave en base al documento de Seguimiento de Pruebas de Usuario (derivado de Casos de Aceptación del Usuario), las mismas se realizarán en varias iteraciones. Si las pruebas del Analista Funcional y/o el Usuario Clave no son satisfactorias, quien haya ejecutado las pruebas debe dejar registro de las mismas en el documento Seguimiento de Pruebas de Usuario detallando los errores detectados o bien lo informa por correo electrónico. El Analista Programador realizará una reprogramación de las correcciones actualizando la Versión Preliminar de acuerdo al documento Seguimiento de Pruebas de Usuario, volviendo a ejecutar las pruebas unitarias. Si las pruebas del Analista Funcional y el Usuario Clave son satisfactorias se continúa con las próximas tareas de la fase. Si las pruebas del Cliente Interno y el Usuario Clave no son satisfactorias, el Cliente Interno deberá enviar un mail de No Aceptación de la Versión del Sistema al Analista Funcional y/o Responsable Proceso Sistemas indicando el motivo. El Analista Funcional junto con el Responsable Proceso Sistemas analizarán la No Aceptación del Cliente Interno y/o Usuario Clave. Si la No Aceptación es producto de un cambio en los requerimientos o por nuevas funcionalidades solicitadas, se deberá volver a la fase de inicio para relevar, analizar y diseñar dichas funcionalidades, evaluando los cambios en el plan de proyecto. Si la No Aceptación es por un Error del sistema el Analista Programador deberá reprogramar o modificar la Versión, volviendo a realizar las pruebas unitarias y luego las pruebas funcionales correspondientes. Si las pruebas del Cliente Interno y del Usuario Clave son satisfactorias se continúa con las próximas tareas de esta fase. El Cliente Interno deberá enviar un mail de Aceptación de la Versión del Sistema al Analista Funcional y al Responsable de Proceso Sistemas.

copia no controlada



Página 14 de 23

5.2.1.4. FASE DE IMPLEMENTACIÓN El Usuario Clave dicta los cursos de capacitación a los usuarios finales. El Analista Programador realiza junto con el Analista Funcional los scripts de actualización de estructuras de la Base de Datos y los instaladores para la aplicación. El Administrador de Ambientes de los Sistemas ejecuta los scripts de actualización de estructuras de la Base de Datos y los instaladores para la aplicación. El Administrador de Ambientes realiza la configuración del ambiente de Pre-producción y la implementación de la aplicación en dicho ambiente siendo asistido por el Analista Funcional. El Responsable Proceso Sistemas realiza el análisis de riesgos de esta fase junto con el Analista Funcional, el Analista Programador y si fuera conveniente (innovación tecnológica) el Responsable de Arquitectura de Aplicativos y el Responsable de Tecnologías de Información. El Analista Funcional actualiza el anexo o documentos dónde se ha decidido volcar la Administración de Riesgos. El Administrador de Ambientes de Sistemas ejecuta la migración de datos en Pre-producción junto con el Analista Funcional. El Usuario Clave junto con el Analista Funcional realiza las pruebas de implementación de la aplicación y el control de los datos migrados en pre-producción. Si la prueba No fue Satisfactoria el Administrador de Ambiente de los Sistemas deberá volver a configurar, implementar y migrar los datos. Si la prueba fue Satisfactoria el Usuario Clave deberá enviar un Mail de Aprobación de Implementación y Migración de datos en Pre-producción y se continúa con las próximas tareas de la fase. El Administrador de Ambientes de los Sistemas realiza la configuración del ambiente de Producción y la implementación de la aplicación en dicho ambiente siendo asistido por el Analista Funcional. El Administrador de Ambientes de los Sistemas ejecuta la migración de datos en Producción junto con el Analista Funcional. El Usuario Clave junto con el Analista Funcional realiza las pruebas de implementación de la aplicación y el control de los datos migrados en Producción. Si la prueba No fue Satisfactoria el Administrador de Ambientes de los Sistemas deberá volver a configurar, implementar y migrar los datos. Si la prueba fue Satisfactoria el Usuario Clave deberá enviar un Mail de Aprobación de Implementación y Migración de datos en Producción y se continúa con las próximas tareas de la fase. El Administrador de Ambientes de los Sistemas realiza la Puesta en Producción de la Aplicación. En esta fase se realizarán tantas iteraciones como se definan dependiendo de las funcionalidades del sistema. 5.2.1.5. GESTIÓN DE CAMBIOS DE PROYECTOS Dentro del Plan de Proyecto se debe incluir el cronograma de entregas de los módulos (o partes del sistema), tanto para su prueba por parte de los usuarios como para su puesta en línea para comenzar con su uso. De producirse pedidos de cambios en las funcionalidades del Sistema, cambios en los requerimientos, o surgir nuevos requerimientos durante la realización del proyecto, se

copia no controlada



Página 15 de 23

debe volver a la Fase de Elaboración, revisar los alcances, actualizar la documentación, incluyendo un nuevo acuerdo y Plan de Proyecto. Es requisito del Analista Funcional del Área de Sistemas completar el Estado de Situación Proyectos Sistemas en la Sistema de Gestión de Requerimientos y comunicárselo al Cliente Interno y Usuario Clave con objeto de alinear entre las áreas el estado de situación de Proyectos y Requerimientos a los efectos de ser presentado a la Alta Dirección. En el registro Estado de Situación Proyectos Sistemas se podrá volcar información del cronograma de entregas, desvíos y motivos de los mismos, tanto del Área de Sistemas como del Usuario Clave. Asimismo, podrá incluir información de los posibles riesgos en cuanto a la puesta en línea de nuevas versiones de los sistemas. Es requisito del Cliente Interno conjuntamente con el Responsable de Procesos del Área de Sistema mantener informado a la Alta Dirección en cuánto al nivel de riesgo asumido durante la implementación y puesta en línea de nuevas versiones de los Sistemas CPBA.

5.3. GESTIÓN DE LA DISPONIBILIDAD Y CONTINUIDAD DEL SERVICIO El objetivo es asegurar que se puedan cumplir en todas las circunstancias los compromisos de disponibilidad y continuidad del servicio acordado con los clientes. Los requisitos de disponibilidad y continuidad de los servicios se deben identificar sobre la base de los planes empresariales, los Acuerdos de Servicios celebrados con los clientes internos y las evaluaciones de riesgos. En relación a la gestión de resguardos de información (backups), debe seguirse lo indicado en el Instructivo I-T-04 Resguardos de Información y Monitoreo. Para mantener el flujo constante de energía eléctrica a la Sala de Servidores y Comunicaciones y de esta manera evitar el corte en el servicio de red, se debe contar con un equipos de alimentación in-interrumpida de potencia como UPS y un generador de electricidad con encendido automático a los 15 segundos del corte de energía eléctrica conectado a la red de gas natural para su alimentación. Se realizan comprobaciones del equipamiento de suministro alternativo de energía eléctrica según I-T-05 Control del suministro eléctrico.

5.4. GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN El objetivo es gestionar eficazmente la seguridad de la información dentro de todas las actividades de los servicios. En relación al otorgamiento de permisos de acceso a los usuarios, debe seguirse lo explicitado en el Instructivo I-T-03 Permisos de Usuarios. 5.5. INDICADORES OPERATIVOS DE LA GESTIÓN DE LOS SERVICIOS TICs La gestión de los servicios TICs se mide a través de los siguientes indicadores operativos:

Indicador Descripción del cómputo o metodología de cálculo Resolución de Incidentes

Cantidad de Incidentes resueltos en los plazos previstos / Total de Incidentes Resueltos. Alcanzar al menos un 85% Cálculo es mensual sobre los incidentes resueltos en el mes, que afectaron a los usuarios de la Institución, independientemente si afectan directa o indirectamente a los procesos del S.G.Calidad.

copia no controlada



Página 16 de 23

Incidentes por Falta de Mantenimiento

Cantidad de Incidentes resueltos mar-cados como Falta de Mantenimiento / Total de Incidentes Resueltos No superar el 20% Cálculo es mensual sobre los incidentes resueltos en el mes, que afectaron a los usuarios de la Institución, independientemente si afectan directa o indirectamente a los procesos del S.G.Calidad.

Incidentes por Seguridad de Información

Cantidad de Incidentes resueltos críticos vencidos pertenecientes al Sistema de Gestión de la Calidad / total de incidentes resueltos. No superar el 20%. Cálculo es mensual sobre los incidentes resueltos en el mes, que afectaron a los usuarios de la Institución, en el numerador sólo los directamente relacionados con procesos del sistema de gestión de calidad; en el denominador, todos los incidentes atendidos y resueltos de la Institución.

6. REGISTROS

Código del Registro Nombre del Registro Responsable Área de Archivo Tiempo

Mínimo

F-PG-T-01.01 Solicitud de Requerimientos RAS Área Solicitante Permanente

F-PG-T-01.02 Minutas de Reunión AF Sistemas Permanente

F-PG-T-01.03 Visión y Alcance AF Sistemas Permanente

F-PG-T-01.04 Plan de Proyecto RSI Sistemas Permanente

F-PG-T-01.05 Documento de Casos Aceptación del Usuario UC Sistemas Permanente

F-PG-T-01.08 Correo electrónico por cancelación de proyecto RAS Área Solicitante Permanente

F-PG-T-01.09 Correo electrónico por aprobación o rechazo de documentos RAS Área Solicitante Permanente

F-PG-T-01.10 Correo electrónico con aprobación o rechazo de la versión del Sistema RAS Área Solicitante Permanente

F-PG-T-01.11 Especificaciones de Requerimientos AF Área Solicitante Permanente

F-PG-T-01.12 Especificaciones de Funcionalidades AF Sistemas Permanente

F-PG-T.01.13 CRM Incidentes Todo Personal

del área de Sistemas

Sistemas Permanente

F-PG-T.01.16 Sistema de Gestión de Requerimientos

Todo Personal del área de Sistemas

Sistemas Permanente

copia no controlada



Página 17 de 23

7. ANEXOS Gestión de Incidentes

act CRM Incidentes

Usuario Servicio Técnico (Nivel 1) Especialistas Técnico-Funcionales (Nivel 2) Responsable de Proceso Sistemas (Nivel 3)

Detección del Incidente

Registro de Caso Atención Primaria delCaso

¿Puede resolver?

FinTratamientoIncidente

¿Requiere escalar el Caso?

Registro deActiv idades

«Abierto»Caso

Resolución deCaso

«Resuelto»Caso

«Cancelado»Caso

¿Prospera el Caso?

CancelaciónCaso

Analiza Resolución

Superado el plazo de atención de Nivel 1, el caso escala automáticamente al Nivel 2.Esto puede suceder incluso sin la Atecnión Primaria del Caso, es decir, esta Actividad se puede llegar a realizar en Nivel 2, incluso 3.

Detección del Incidente

Registro de Caso

Notificación Usuario queReporta y al Autor en caso

que difieran

¿Está conforme?

Reabre Caso

«Abierto»Caso

Pasadas 48 hs tambiénse auto-confirma la resolución del caso

Cómputo de plazos

¿Venció plazo previsto Nivel 1?

Atención Incidente Niv el 2

No Si (Escalamiento Temporal a Nivel 2)

No

SiNo

Si (Escalamiento Temporal a Nivel 2)

Si

No

No

copia no controlada



Página 18 de 23

copia no controlada



Página 19 de 23

act Atención Incidente Niv el 3

Usuario Responsable Proceso Sistemas (Nivel 3)

Atención Primaria delCaso

¿Puede resolver?

FinTratamientoIncidente

Registro deActiv idades

Resolución deCaso

«Resuelto»Caso

«Cancelado»Caso

¿Prospera el Caso?

CancelaciónCaso

Analiza Resolución

Superado el plazo de atención de Nivel 2, el caso escala automáticamente al Nivel 3.Esto puede suceder incluso sin la Atecnión Primaria del Caso, es decir, esta Actividad se puede llegar a realizar en Nivel 3.

Inicio

Se toma el Caso de ColaNiv el 3

Notificación Usuario queReporta y al Autor en caso

que difieran

¿Está conforme?

Reabre Caso

«Abierto»Caso

Pasadas 48 hs tambiénse auto-confirma la resolución del caso

Cómputo de plazos

¿Venció plazo previsto Nivel 3?

¿Se incumple un Requisito?

Iniciar Gestion de NoConformidad

¿Requiere un cambio que noforme parte del estandarvigente?

Alta deRequerimiento

Gestion deCambio

Se crea un Requerimiento por la intranet del Cliente Interno.Se da por cerrado el Incidente asociando el Requerimiento generado.Se realiza el seguimiento por elRequerimiento

Si

No Si

Si

No

Si

No

No

No

Si

No

Si

copia no controlada



Página 20 de 23

Gestión de Cambio – Proyectos - FASE de INICIO

copia no controlada



Página 21 de 23

Gestión de Cambio – Proyectos - FASE de ELABORACIÓN

copia no controlada



Página 22 de 23

Gestión de Cambio – Proyectos - FASE de CONSTRUCCIÓN

copia no controlada


Sistemas-Gestión de los Servicios Informáticos Páginas 23 de 23

8. DOCUMENTOS RELACIONADOS AS-T-01 – Acuerdo de Servicios Informáticos IT-T-01 - Verificación Servicio de Internet IT-T-02 - Manual de Usuario CRM Incidentes IT-T-03 - Permisos de Usuario IT-T-04 - Resguardos de Información y Monitoreo IT-T-05 – Control del Suministro Eléctrico IT-T-06 - Clasificación de Incidentes IT-T-07 – Verificación Servicio Internet de Backup 9. MODIFICACIONES

Fecha Modificaciones

12/07/2010

Creación del documento. Se integran aspectos de la Gestión de la Seguridad de la Información, Gestión del Mantenimiento preventivo, Gestión de los Incidentes o mantenimiento reactivo y Gestión de Proyectos, en el marco de las recomendaciones y lineamientos de las normas IRAM/ISO 20000.

15/09/2010

Se adaptaron definiciones según IRAM-ISO/IEC 20000:2008. Se agregaron actividades que hacen a la Gestión de la Disponibilidad de los Servicios Informáticos, en el marco de las recomendaciones y lineamientos de la norma IRAM/ISO 20000. Se agregó un instructivo de resguardo de información así como la integración de Gestión de Incidentes con Gestión de No Conformidades, respondiendo a observaciones del auditor IRAM.

17/9/2010 Se hizo una corrección ortográfica y eliminación de texto con formato tachado.

2/11/2010 Se incluyó el diagrama de gestión de Incidentes de nivel 3 y su integración con la Gestión de No Conformidades, respondiendo a las observaciones realizadas por el Auditor de IRAM,

5/01/2011 Se amplió el criterio a utilizar cuando se clasifican los incidentes en “Falta de Mantenimiento” y “Falla de Seguridad”.

15/11/2011 Se quitaron los registros F-PG-T.01.14, F-PG-T.01.15 y F-PG-T.01.07 de indicadores operativos. Los mismos se encuentran declarados en otro registro.

24/05/2012 Se agregaron instructivos I-T-06 e I-T-07. Se modificó instructivo IT-T-03

16/07/2012 Se agregó registro referencia al F-PG-T.01.16. Se agregó Tratamiento de Incidentes que dependen de Terceros

8/11/2016 Se agregó la sección 5.5 con la descripción del cómputo o metodología de los indicadores operativos

26/8/2019 Se reemplazó el término SharePoint y el término INTRANET de Cliente Interno por Sistema de Gestión de Requerimientos (nuevo sistema cuya denominación técnica es RedMine).

Revisado por: Fecha: 26/08/19

Aprobado por:

Fecha: 26/08/19

copia no controlada

copia no controlada - CPBA...2.4. Gestión de la Disponibilidad y Continuidad del Servicio 2.5....

Documents

Transcript of copia no controlada - CPBA...2.4. Gestión de la Disponibilidad y Continuidad del Servicio 2.5....