ANEXO 4B
ANEXO 4B
Implementación de un Modelo de Operación.
El prestador del Servicio deberá apoyar a la DTI en la implementación de un Modelo de Operación conforme a la descripción de procesos, Metas / Objetivos, lineamientos específicos y productos que se describen, siendo estos enunciativos mas no limitativos.
El prestador del Servicio, deberá implementar los planes de acción para cumplir con el primer objetivo que es determinar las fortalezas y debilidades del proceso descrito y para implementar las oportunidades de mejora del modelo, considerando que el modelo debe asegurar que los diferentes prestadores de servicio en este servicio puedan ejecutar las prácticas solicitadas por el Modelo de Operación. La cobertura de las apreciaciones deberán incluir la totalidad de los procesos definidos.
El prestador del Servicio, deberá generar la documentación de los procedimientos para cada uno de los procesos del Modelo de Operación, así mismo, cada año, el prestador del Servicio deberá realizar evaluaciones de los procesos del Modelo para identificar nuevas áreas de oportunidad y proponer líneas de acción.
El prestador del Servicio se compromete a brindar bajo demanda el apoyo a la DTI del Instituto, para la definición de estrategias y/o acciones para la implementación de aplicaciones, arquitectura de aplicaciones y planeación asociadas con las diferentes aplicaciones propias o externas, actuales o futuras del Instituto.
A continuación se describen en forma general metas, objetivos, lineamientos específicos y productos, de forma enunciativa más no limitativa, por cada actividad de cada proceso.
1.- GESTIÓN
Este proceso cubre las actividades relacionadas con la definición de la estrategia y control de todos los proyectos, la atención de las necesidades de negocio y la Administración de la Arquitectura Tecnológica.
Administración de Solicitudes Estratégicas
La estrategia general de la organización se determina en el nivel ejecutivo del Instituto, quien establece y dirige los objetivos estratégicos. Como objetivo principal de la administración de estas solicitudes es la planeación, el comunicar e identificar los requerimientos de los diferentes usuarios finales, así como la arquitectura de la solución a utilizar en cada proyecto, para garantizar que los requerimientos generados estén alineados para lograr el cumplimiento de las metas organizacionales.
Metas y Objetivos Específicos
Realizar una administración integrada, considerando lo siguiente:
o Estrategia Organizacional
▪ Identificar los objetivos estratégicos del Instituto
▪ Establecer las bases para la planeación y administración de estos proyectos
▪ Costo - Beneficio
o Alineación de requerimientos
▪ Identificar, categorizar, evaluar, seleccionar, priorizar y balancear los proyectos
▪ Evaluar su desempeño en relación a indicadores clave y de acuerdo al plan estratégico
o Monitoreo y Control
▪ Revisar indicadores de desempeño periódico para su alineación con objetivos estratégicos
▪ Administrar el cambio estratégico.
Administración de Solicitudes de Atención
Metas y Objetivos Específicos
Los Requerimientos son la base para la selección y para el diseño o configuración del producto requerido, por lo que se deberá de:
• Generar y analizar los requerimientos de los usuarios con base a los diferentes requerimientos contractuales de los servicios
• Desarrollo de Requerimientos
o Analizar y Validar los Requerimientos
o Costo - Beneficio Lineamientos Específicos:
El Proceso Definido debe cumplir con las siguientes características:
• Obtención, análisis, validación y comunicación de las necesidades de los usuarios, sus expectativas y restricciones para generar los requerimientos de los usuarios que constituyen el entendimiento de las necesidades de todos los involucrados.
• Definición de los requerimientos de los usuarios
• Elaboración de los requerimientos siendo estos consistentes con las necesidades de los usuarios, a un nivel de detalle que sea suficiente para cumplir con los requerimientos contractuales de cada servicio
Los productos requeridos son: Requerimiento
Visión del Sistema
Modelo de Casos de Uso de Negocio
Plan de Administración de Requerimientos Registro de métodos de análisis de requerimientos
Registro de métodos de verificación de requerimientos
Administración de la Arquitectura Tecnológica
Metas y Objetivos
Establecer la definición de restricciones de diseño y arquitectónicas
Lineamientos Específicos:
Proveer las restricciones de diseño. Los productos o servicios deberán ser diseñados e implementados de acuerdo a las restricciones dadas.
El Proceso Definido debe cumplir con las siguientes características:
Desarrollar las restricciones de diseño para la solución técnica del prestador del servicio, la cual satisfaga un conjunto de requerimientos.
• Establecer una definición inicial de restricciones de diseño.
• Verificar el diseño de la arquitectura de la solución técnica en base al modelo de Arquitectura de Tecnología de Información del Instituto.
Productos Requeridos:
• Documento de Arquitectura de Software.
• Protótipo de interfase de usuário.
• Mapa de navegación.
• Arquitectura de referencia.
• Modelo de servicio.
• Prueba de concepto arquitectónico.
• Estrategia de migración de datos.
2.- ADMINISTRACIÓN DE PROYECTOS.
Este proceso cubre las actividades de:
• Planeación de Proyectos
• Monitoreo y Control de Proyectos
• Ajuste de Proyecto
El prestador de servicios deberá constituir y operar una oficina de administración de proyectos (PMO) acorde a los lineamientos que se establezcan en los procesos y será responsable de su ejecución con la organización y administración de los perfiles solicitados en la presente licitación
Planeación de proyectos
Metas y Objetivos Específicos
• Planeación de Proyectos
o Establecer Estimaciones
o Desarrollar un Plan de Proyecto
o Obtener el Compromiso del Plan
• Administración de Riesgos
o Prepararse para la Administración de Riesgos
o Identificar y Analizar los Riesgos
o Mitigar los Riesgos
Lineamientos Específicos:
El proceso de planeación de un proyecto debe iniciar con el establecimiento de los parámetros de estimación.
Los parámetros de estimación que deben utilizarse son:
• Requerimientos:
o De producto
o De Usuario
o Técnicos
• Contractual
• Alcance del proyecto
• Tamaño del producto
• Ciclo de vida seleccionado para el proyecto
• Datos históricos
Los requerimientos deben obtenerse de acuerdo al proceso de gestión, y se deberá acotar el alcance, identificar las áreas y usuarios que participaran, el requerimiento deberá desarrollarse hasta el punto que permita identificar el tamaño del producto. Así mismo se deberán definir las fases a realizar y la cantidad de recursos para llevar a cabo las actividades necesarias.
Se deberán de describir las actividades de administración del proyecto en un procedimiento denominado Plan de Desarrollo, que debe describir como gestionar los siguientes puntos:
• Presupuesto base del proyecto
• Cronograma del proyecto con hitos principales identificados
• Planeación de recursos
• Necesidades de perfiles y habilidades del equipo del proyecto
• Plan de comunicación con los usuarios involucrados
• Identificación de los riesgos del proyecto
El Plan de Desarrollo debe ser utilizado como base para revisar con todos los grupos de interés involucrados y obtener acuerdos. El proyecto sólo puede continuar a la fase de ejecución y control si se logra la total aprobación del mismo, por parte de los grupos de interés involucrados (usuarios del Instituto y representantes de la DTI).
Como parte de la planeación, cada proyecto debe identificar los riesgos asociados. Para lo cual se debe realizar el proceso de identificar y categorizar los riesgos de los proyectos en el contexto del Instituto y relacionados con la ingeniería de software.
Se deberá considerar en los planes de trabajo las actividades de aseguramiento de la Calidad de Proceso y Producto a fin de que no se vean afectados los compromisos y fechas de entrega de los proyectos por la omisión de estas actividades en los calendarios de trabajo.
Productos Requeridos:
• Administración de Proyectos
o Plan de Desarrollo de Software
o Caso de negocio
o Plan de iteraciones
o Plan de monitoreo y control
o Métricas de proyectos
o Registro de revisiones
o Lista de riesgos
o Evaluación de estado
o Plan de distribución
o Orden de trabajo
• Lista de asuntos pendientes
Las actividades de estimación del esfuerzo, costo y el cronograma del proyecto, se deberán de implementar a través de un procedimiento
estandarizado (metodología) y a través del uso de herramientas, que permitan dar consistencia a las estimaciones de esfuerzo de los diferentes proyectos que se establezcan.
La herramienta será evaluada y acordada con el Instituto al inicio del contrato, previa demostración de la funcionalidad y características de la herramienta en cuestión.
Una vez que el proyecto de software haya sido estimado y aprobado, el prestador deberá contar con una herramienta que permita evaluar el estatus del proyecto, comparando el plan de proyecto contra los datos actuales del mismo y generar un pronóstico de terminación. Los resultados de este análisis, serán utilizados por el Instituto y Grupo de Calidad para el seguimiento del avance del proyecto.
La(s) herramienta(s) propuesta(s), deberá(n) disponer de estadísticas de productividad, identificar cuellos de botella y sustentar estimados de proyectos futuros.
Monitoreo y Control de Proyectos
Metas/Objetivos Específicos
• Monitoreo y Control de Proyectos
o Monitorear el Proyecto contra el Plan de ejecución.
o Administrar las Acciones Correctivas hasta su cierre
• Administración de Riesgos
o Prepararse para la Administración de Riesgos
o Identificar y Analizar los Riesgos
o Mitigar los Riesgos
Lineamientos Específicos:
Una vez concluida la planeación del proyecto, la administración del mismo debe enfocarse al monitoreo y control.
Como parte del control del costo y tiempo del proyecto, se debe reportar las desviaciones en dichos rubros y realizando comparaciones con base al Plan de Desarrollo.
El monitoreo del proyecto se debe realizar sobre los siguientes puntos: Acuerdos
Riesgos del proyecto Progreso de hitos alcanzados Presupuesto devengado
Se debe dar seguimiento a los asuntos pendientes del proyecto y proponer acciones correctivas y si es necesario, incluir a los involucrados del Instituto y
de sus recursos para gestionar la resolución. Se debe identificar la o las acciones para mitigar los riesgos que se presentan en la Ingeniería de Software y aplicarlas por igual siempre y cuando sea necesario, en todos los proyectos.
Productos Requeridos:
Plan de Desarrollo de Software Caso de negocio
Plan de Iteración
Plan de monitoreo y control. Métricas de proyectos Registro de revisiones
Lista de riesgos Evaluación de estado Plan de distribución Orden de trabajo Lista de asuntos
Ajuste de Proyectos
Establecer y gestionar a los proyectos y a los equipos de trabajo involucrados de acuerdo a un proceso definido y ajustado
Metas/Objetivos Específicos
• Adecuar el plan del proyecto
• Coordinación y colaboración con los equipos de trabajo involucrados
• Gestionar acciones
Lineamientos Específicos:
Gestionar y Reportar las desviaciones y/o Ajustes Productos Requeridos:
Plan de Desarrollo ajustado
3.- MANTENIMIENTO Y DESARROLLO
Esta categoría cubre las áreas de proceso para soportar actividades de desarrollo y mantenimiento de aplicaciones, desde su concepción, como requerimiento de usuario, hasta la aceptación del producto.
El prestador del servicio debe establecer un grupo de Arquitectura de Aplicaciones y Datos que será responsable de coordinar los esfuerzos de ingeniería de productos de cada proyecto.
Dicho grupo debe definir en común acuerdo con el Instituto, el modelo de Arquitectura de Desarrollo y Mantenimiento de Software y la Arquitectura orientada a componentes reutilizables, cuidando que se siga fielmente la Arquitectura de Aplicaciones y Datos del Instituto.
El grupo de Arquitectura del prestador del servicio debe incluir a su homologo del Instituto para la toma de decisiones relacionadas con Arquitectura de Aplicaciones y Datos y la definición de criterios de reutilización de componentes.
Administración y análisis de requerimientos del producto
Metas/Objetivos Específicos
• Administración de Requerimientos
o Administrar los Requerimientos
• Desarrollo de Requerimientos
o Desarrollar los Requerimientos del Cliente
o Desarrollar los Requerimientos del Producto
o Analizar y Validar los Requerimientos
Lineamientos Específicos:
Para asegurar que el prestador de servicios controle los requerimientos e identifique las inconsistencias que se presenten entre los planes del proyecto y lo elaborado por la ingeniería de productos, debe implantar un área de proceso para la administración de requerimientos.
El prestador de servicios debe obtener y entender los requerimientos de los usuarios del Instituto, estableciendo criterios para identificar las fuentes apropiadas para conseguirlos; definir los criterios y objetivos para aceptar solicitudes de requerimientos y lograr un total entendimiento de los mismos para que los participantes del proyecto se puedan comprometer a ellos.
El prestador de servicios debe obtener el compromiso sobre los requerimientos, por parte de los usuarios participantes en el proyecto y en conjunto con la DTI negociar la obtención de dichos compromisos.
El compromiso obtenido de los usuarios participantes, deberá ser registrado por el prestador de servicios garantizando su integridad y utilizando las herramientas adecuadas y soportadas por los procesos
Cuando se presenten cambios en los requerimientos, el prestador de servicios debe administrarlos, registrando y controlando todos los que se presenten, manteniendo la historia del cambio y la razón que lo originó, evaluar el impacto de los cambios a los requerimientos con respecto al esfuerzo a aplicar y afectaciones al plan calendario de trabajo desde el punto de vista de los principales interesados y hacer que los requerimientos y los datos de sus cambios estén disponibles para el proyecto.
El prestador de servicio debe mantener la rastreabilidad de los requerimientos, manteniendo su consistencia hasta los requerimientos derivados, productos de trabajo y así tener un método para evaluar cambios. Así mismo será responsable de mantener actualizada la matriz de rastreabilidad de requerimientos durante todas las etapas del ciclo de vida de desarrollo de software.
Para producir y analizar los requerimientos del usuario, del producto y de los componentes del mismo, el prestador de servicio debe implementar el área de proceso para desarrollar requerimientos.
El prestador de servicios, debe desarrollar los requerimientos del usuario, a través de la agrupación de las necesidades de los usuarios involucrados, y obteniendo de ellos las necesidades funcionales, expectativas, restricciones e interfaces, y proponiendo las técnicas de recolección de información. Finalmente, debe plasmar en un documento de visión, los requerimientos identificados y definir las restricciones a ser utilizadas en el proceso de revisión y aceptación del producto.
Partiendo de los requerimientos aceptados por el usuario, se deben refinar y convertirlos en los requerimientos del producto y de los componentes de producto, y que se combinan con la arquitectura del producto.
Los requerimientos del producto forman la arquitectura funcional de la aplicación, la cual debe ser elaborada por el prestador del servicio, y en la cual debe incorporar Requerimientos Funcionales, Requerimientos No Funcionales y las Restricciones de Diseño.
El prestador de servicios debe representar a los requerimientos funcionales como un modelo en el cual se representen las funciones de un sistema y sus usuarios e interfases. La función del sistema debe ser descrita como un conjunto de flujos básicos que representa el comportamiento normal del sistema y los flujos alternos e incluir los escenarios principales del sistema
como una agrupación ordenada de flujos desde el inicio de la función hasta uno de sus puntos finales.
Los requerimientos funcionales deben ser documentados por el prestador del servicio, con el objetivo de que sean validados por los usuarios involucrados y el personal de la DTI asignado, para que sean el mecanismo para establecer un vocabulario común entre los participantes del proyecto y los usuarios involucrados. La documentación de los requerimientos funcionales deberán ser registrado por el prestador del servicio, garantizando su integridad
Los requerimientos no funcionales deben ser englobados en la clasificación de tipos de Usabilidad, Confiabilidad, Desempeño y Soportabilidad, y tratados como Requerimientos Suplementarios y satisfechos por medido de la arquitectura de la aplicación.
Una vez generado el documento con los requerimientos funcionales y no funcionales, deberá ser comunicado a los usuarios y personal de la DTI involucrados y servirá como la línea base de comparación para identificar posibles cambios al proyecto.
El prestador del servicio debe validar los requerimientos para garantizar la suficiencia y estabilidad de los mismos. La validación de requerimientos, permitirá verificar que los requerimientos recopilados sean:
- Correctos desde la perspectiva del alcance y contenido.
- No contengan ambigüedades en su definición.
- Lógicamente consistentes
Productos Requeridos Requerimientos Visión
Plan de administración de requerimientos Requerimientos de Software
Especificación de Requerimientos de Software Especificaciones suplementarias
Modelo de casos de uso Glosario
Solicitudes de los grupos de interés
Arquitectura, diseño, implementación e integración del producto
Metas/Objetivos Específicos
• Solución Técnica
o Seleccionar los Componente de la Solución
o Desarrollar el Diseño
o Implementar el Producto a Diseñar
• Integración del Producto
o Prepararse para la integración del Producto
o Asegurar la Compatibilidad de las Interfaces
o Ensamblar los Componentes del Producto y Liberar el Producto Lineamientos Específicos:
Esta área de proceso se integra por las siguientes actividades
Arquitectura de la aplicación Diseño de componentes
Implementación del diseño del componente
Integración de componentes y puesta en punto en producción
El prestador del servicio deberá elaborar, para cada proyecto los elementos arriba mencionados, asegurándose que la Arquitectura propuesta, para cada proyecto, esté acorde a los lineamientos de Arquitectura de Tecnología de Información del Instituto.
Cada arquitecto de proyecto, deberá trabajar en conjunto con el grupo de arquitectura de aplicaciones del Instituto, con el fin de que todos los proyectos utilicen los principios y servicios de Arquitectura de Tecnología de información definidos por el Instituto. La decisión de la inclusión o exclusión de las actividades de elaboración de cada uno de los elementos de Arquitectura será en base a lo que se defina en el proceso de Administración de Proyectos.
La arquitectura tecnológica y de aplicaciones se define como las actividades necesarias para la definición de la estrategia de aplicaciones, arquitectura de aplicaciones de alto nivel y planeación.
El prestador del servicio debe documentar la arquitectura de la(s) aplicaciones que atiende, para que el Instituto forme un repositorio de modelos de arquitectura de aplicaciones.
Para proporcionar los servicios solicitados, el prestador del servicio deberá utilizar un marco de referencia. Este marco de referencia es una estructura unificada dentro del cual se planean, desarrollan, documentan y mantienen las diferentes arquitecturas o aplicaciones solicitadas por el Instituto.
El marco de referencia propuesto, servirá como un punto de inicio para establecer los estándares (tecnologías de software, paquetes y herramientas) del Instituto relacionados con Arquitectura. El prestador del servicio se ajustará a los estándares definidos por el Instituto y en su defecto, contribuirá con la Institución en el establecimiento de dichos estándares, si así es requerido
Será responsabilidad del prestador del servicio el diseño del producto y/o sus componentes, así como las especificaciones técnicas, implementación del diseño, documentación y seguir los patrones y mejores prácticas de la tecnología sobre la cual se realiza la implantación del producto.
El prestador del servicio realizará el diseño e implantación de las interfaces de la aplicación. Las interfaces de la aplicación son los componentes que permiten integrar el sistema con la infraestructura tecnológica y/o aplicaciones existentes, que se definan o requieran.
El grupo de arquitectura del prestador de servicio deben llevar a cabo un análisis de re usar, o hacer una aplicación o componente; y estar en común acuerdo con el personal del Instituto que esté como responsable de la arquitectura.
Los componentes del producto y la documentación de los mismos deberán ser implementados a partir de sus diseños realizados, y adhiriéndose a los estándares y criterios aplicables. Para todos los componentes de productos, el prestador del servicio deberá llevar a cabo revisiones entre colaboradores. De igual manera, para cada componente del producto se deben realizar pruebas unitarias y de integración.
La documentación que da soporte al producto y que debe elaborar el prestador del servicio es: de instalación, operación y mantenimiento; y se deberá realizar el Control de Calidad de dicha documentación.
Al concluir los componentes del producto, el prestador del servicio deberá planear y preparar el ensamblado de los mismos para constituir el producto solicitado, así como asegurar que, una vez realizada la integración, se preserven los requerimientos solicitados y así realizar el empaquetado y entrega del producto al ambiente de producción, con la documentación y requerimientos solicitados por el área responsable de la operación de tecnologías de información y comunicaciones del Instituto. Será responsabilidad del prestador del Servicio realizar el despliegue necesario para la puesta en producción de los productos resultantes, objetos de la presente licitación.
El prestador del servicio debe asegurar la compatibilidad entre cada uno de los componentes del producto y sus interfases.
Es responsabilidad del prestador del servicio de la coordinación con el personal de la DTI del Instituto para establecer el ambiente de integración del producto.
Productos Requeridos Arquitectura y Planeación
• Arquitectura de aplicaciones
• Modelo de aplicaciones – procesos
• Modelo de flujo de aplicaciones (arquitectura para integración de aplicaciones)
• Modelo de aplicaciones – organización
• Modelo de aplicaciones – información
• Modelo de componentes aplicativos
• Recomendación de las mejores prácticas (planeación de aplicaciones, diseño de arquitectura de aplicaciones)
• Arquitectura de infraestructura
• Estrategias de TI
• Estándares tecnológicos y políticas
• Necesidades de infraestructura
o Modelo de conectividad lógica entre las diferentes localidades
o Matriz de infraestructura – organización
o Matriz de infraestructura – aplicación
• Vista de componentes
• Recomendaciones de las mejores prácticas (implantación de nuevas tecnologías, proceso de aprobación de arquitectura en nuevos proyectos)
• Arquitectura de Datos (información) e integración
• Modelo de flujo de información (arquitectura de integración entre unidades de negocio y la organización del Instituto)
• Inventario de clases de información
• Modelo información – organización
• Modelo información – función de negocio / proceso
• Modelo de datos estratégico (Modelo lógico de datos de alto nivel)
• Planeación, desarrollo y mantenimiento de la base de datos física para los ambientes de desarrollo y pruebas
• Recomendaciones de mejores prácticas (estándares de datos maestros del Instituto, evaluación de calidad de los datos )
Análisis y Diseño
• Modelo de análisis
• Modelo de diseño
• Modelo de datos
• Modelo de distribución
• Documento de Arquitectura de Software
• Prototipo de interfase de usuario
• Mapa de navegación
• Arquitectura de referencia
• Prueba de concepto arquitectónica
• Especificación de migración de datos Implementación
• Plan de integración de versiones
• Versión
• Pruebas de desarrollo
• Modelo de implementación Distribución
• Material de soporte a usuarios
Fabrica de Software
El objetivo es administrar al acuerdo formal entre el Instituto y la fábrica de software del prestador del Servicio para la construcción de productos y componentes reutilizables de software.
Los componentes reutilizables de software tienen como objetivo el satisfacer requerimientos técnicos y funcionales específicos de un proyecto; y ser integrado como parte del esfuerzo total de ingeniería de software.
El prestador del servicio debe revisar junto con el Instituto, los requerimientos que tendrán que ser cubiertos, estableciendo y documentado los acuerdos con su fábrica de software.
El prestador del Servicio debe ejecutar las actividades para la documentación de los acuerdos con su fábrica de software:
1. Establecer la declaración del trabajo, especificaciones, términos y condiciones, entregables, cronograma, presupuesto y procedimiento de aceptación
2. Identificar y asignar a los responsables de su fábrica de software y del proyecto, cuya obligación será la de seguir el acuerdo y negociar cambios al mismo.
3. Identificar como se determinarán, comunicarán y atenderán cambios a los requerimientos y al acuerdo.
4. Identificar los estándares y procedimientos que serán seguidos por su fábrica de software.
5. Identificar dependencias críticas entre el proyecto y su fábrica de software
6. Identificar el tipo de control, los procedimientos y el monitoreo del desempeño de su fábrica de software
7. Identificar los tipos de revisiones que serán ejecutadas
8. Identificar las responsabilidades de su fábrica de software con respecto al mantenimiento y soporte de los productos o componentes reutilizables.
9. Identificar las garantías, de los productos y componentes reutilizables.
10. Identificar criterios de aceptación.
La declaración de trabajo establece las características del proyecto de construcción y debe contener lo siguiente:
• Definición de los productos y/o componentes reutilizables
• Estructura de División de Tareas (WBS) y el diccionario de trabajo de la misma
• Detalle suficiente para garantizar el entendimiento por parte de su fábrica de software.
• Especificación técnica del componente reutilizable
• Niveles de calidad
• Cronograma y periodo de ejecución del proyecto
• Esquemas de monitoreo basado en calendario, esfuerzo, desempeño técnico.
• Roles y responsabilidades
• Criterios de aceptación y garantía
• Mecanismos de terminación y solución de controversias
• Procedimientos de control de cambios
• Confidencialidad
Dicho documento es la base para que la fábrica de software ejecute el proyecto. La declaración de trabajo debe ser aprobada por el Instituto.
Se debe proporcionar esquemas de monitoreo del progreso de su fábrica de software y reportarlas al Instituto.
En caso de desviaciones, se deberán tomar acciones correctivas para cumplir con los compromisos establecidos.
El Instituto coordinara las revisiones con la fábrica de software.
La ejecución del proyecto de los productos y/o componentes reutilizables es total responsabilidad de la fábrica de software.
La realización de la transferencia de los productos y/o componentes reutilizables de la fábrica de software hacia el proyecto que lo solicitó, es responsabilidad del prestador del servicio y este asegurará que se integre con la totalidad de la aplicación, utilizando el procedimiento de integración.
Revisión y Aceptación de Productos
Control de Calidad del producto Metas/Objetivos:
• Verificación
o Prepararse para la Verificación
o Realizar Revisiones entre Colegas
o De los Productos Seleccionados
• Validación
o Prepararse para la Validación
o De los Productos o Componentes del Producto
Lineamientos Específicos:
La revisión de los componentes del producto es la verificación que confirma que dichos componentes reflejan de manera correcta los requerimientos establecidos para la creación de los mismos.
Para cada proyecto, se deberán seleccionar los componentes del producto a verificar tomando como criterios aquellos que permiten cumplir con los objetivos del proyecto y sus requerimientos, y los que están relacionados con los riesgos identificados.
El prestador del servicio deberá desarrollar una estrategia de pruebas específica para cada proyecto de desarrollo y mantenimiento. Esta estrategia, debe proporcionar una cobertura óptima de pruebas a realizar e identificar los defectos que tengan impacto significativo en la aplicación que se encuentra en desarrollo o mantenimiento.
Para llevar a cabo esta etapa del proceso de verificación del producto, deberá entregar la documentación necesaria que permita asignar prioridades a la pruebas que se realizarán durante las diferentes etapas del ciclo de vida de desarrollo y mantenimiento de aplicaciones.
El prestador del servicio llevará a cabo las siguientes pruebas de verificación de la calidad del producto:
- Pruebas unitarias. Las pruebas unitarias deben ejecutarse para cada unidad específica de software y deberás de garantizar:
o Que el nuevo código empate con los detalles de diseño
o Que la rutas que se pueden seguir a través del código.
o Que los mensajes, pantallas, y menús pull-down, estén formateados apropiadamente.
o Que las entradas sean validadas por rango de valores y tipo de dato y que cumpla con los casos de prueba
o Que cada bloque de código, cuando se generan excepciones, regrese los mensajes de error apropiados
- Pruebas de integración. Las pruebas funcionales de integración, permitirán identificar las fallas entre las interfaces y la interacción entre componentes integrados. El propósito de este tipo de prueba de calidad del producto, es confirmar que cada unidad de software especificada se ejecuta de manera apropiada con otras unidades de software, a través de las interfaces definidas en el diseño.
El prestador del servicio debe coordinarse con los equipos de la DTI del Instituto para establecer el ambiente de verificación y de acuerdo a un procedimiento previamente acordado con el prestador del Servicio.
La revisión de los productos de trabajo que el prestador del servicio debe aplicar es la denominada revisión entre colegas y que consiste en sesiones de trabajo entre equipos de trabajo con el fin de identificar defectos y erradicarlos.
El objetivo de las revisiones entre colegas es la reducción de errores en las etapas de análisis de requerimientos, arquitectura y diseño del producto, y de implantación.
El prestador de servicio debe preparar las revisiones entre colegas, y considerando que las personas que forman el equipo verificador debe tener habilidades técnicas iguales o superiores a las del equipo revisado. El insumo para la revisión entre colegas es la lista de verificación, la cual debe ser acordada con el personal de la DTI del Instituto.
El personal de la DTI del Instituto tiene el derecho de participar como espectador de las revisiones y el prestador del servicio tiene la obligación de entregar cada una de las evidencias de las revisiones entre colegas de los proyectos.
La realización de la verificación de los componentes del producto es responsabilidad del prestador del servicio así como analizar los resultados de la verificación y realizar acciones correctivas.
El prestador del servicio debe tener en cuenta que, para toda acción correctiva realizada en el proyecto y que no se derive por cambios a los requerimientos del producto, el Instituto no la considera como horas de servicio, sino de garantía y estas son sin cargo para el Instituto.
Una vez que el prestador del servicio realice el proceso de verificación, deberá preparar al producto para que realice la Gestión de Calidad.
Si como resultado de la Gestión de Calidad, identifica fallas en el producto, deberá realizar acciones correctivas para suprimirlas.
La aceptación del producto es la validación que confirma que éste al ser entregado, al usuario, cumple con las requerimientos de usuario y dentro de un ambiente de preproducción.
El prestador del servicio debe identificar las características y fases clave para la validación del producto y de acuerdo al ciclo de vida del proyecto.
El prestador del servicio debe proponer los modelos de validación del producto y en conjunto las áreas usuarias se definirá que modelo de validación será utilizado.
La selección de la validación a realizar con los usuarios involucrados es responsabilidad del prestador del servicio y las áreas usuarias involucradas, pero debe coordinarse con el líder de proyecto de la DTI del Instituto para obtener el compromiso de los usuarios para realizar la validación
El prestador del servicio debe coordinarse con los equipos de la DTI del Instituto para establecer el ambiente de validación.
El prestador del servicio debe realizar validación y analizar los resultados de las mismas, registrando los asuntos que surjan y proporcionando evidencia de las validaciones dadas. El prestador del servicio debe considerar que cualquier defecto encontrado durante la fase de validación se toma como parte del servicio, y el Instituto lo considera garantía.
La aceptación del producto en ambiente productivo debe ser en común acuerdo con el Instituto y con base en la aceptación de los entregables, y teniendo como criterio los requerimientos aprobados y acordados con el Instituto.
Pruebas Funcionales de Integración.
Las pruebas funcionales de integración, permiten identificar las fallas entre las interfaces y la interacción entre componentes integrados.
El propósito de este tipo de prueba de calidad del producto, es confirmar que cada unidad de software especificada se ejecuta de manera apropiada con otras unidades de software, a través de las interfaces definidas en el diseño.
Las pruebas deben realizarse de manera progresiva, incorporando las unidades de software gradualmente hasta que el sistema o los productos se encuentre totalmente integrado.
El objetivo de la prueba funcional de integración, es mostrar que la interacción entre módulos contradice las especificaciones del sistema, de tal forma que los errores son detectados y corregidos antes de realizar las pruebas funcionales de sistema.
El prestador del servicio deberá realizar las pruebas necesarias que permitan:
o Asegurar que el grupo de módulos bajo prueba, interactúan apropiadamente y realizan las funciones requeridas. La interacción debe realizarse entre los componentes del sistema y en casos de requerirse, con entidades externas.
o La interacción entre unidades y tareas
o La interacción entre sub-sistemas
o La interacción adecuada de todas las unidades dentro de un sub- sistema y todos los sub-sistemas dentro de un sistema
4.- SOPORTE A LOS PROCESOS.
Este proceso proporcionará las actividades de apoyo para que los procesos de administración de proyectos y de ingeniería de productos se ejecuten en ambientes correctos y controlados.
Administración de la configuración
Metas/Objetivos Específicos
• Administración de la Configuración
o Establecer líneas base
o Registrar y Controlar los Cambios
o Establecer Integridad
• Medición y Análisis
o Alinear las Actividades y Métricas con las necesidades y objetivos del negocio
o Proporcionar los Resultados de Medición
Lineamientos Específicos:
Este proceso debe permitir y asegurar la integridad de los productos y controlar los cambios a los mismos.
El prestador del servicio debe establecer una línea base de productos, a través del cumplimiento de los siguientes puntos:
o Identificar todos los productos para ser controlados por la administración de la configuración,
o Establecer un sistema de administración de la configuración y de cambios con el fin de controlar los productos identificados, y elaborar todos los procedimientos para manejar múltiples niveles de control de configuración, procedimientos a seguir para guardar y cargar en el sistema de administración de configuración, y esquemas de archivado, respaldo y restauración del sistema.
o Crear la línea base, que es el conjunto de especificaciones y/o productos y que se ponen a disposición del personal de la DTI del Instituto
La práctica de seguimiento y control de la administración de cambios de los productos de la línea base, es responsabilidad del prestador del servicio.
Por cada cambio requerido, se debe evaluar el impacto generado y elaborar un procedimiento para aprobarlo, registrarlo y planificar la actividad para aplicar el cambio solicitado. El encargado de aprobar estos cambios, será el personal asignado de la DTI.
El prestador del servicio debe asegurar la integridad de los productos y establecer procedimientos de auditoria de la línea base, para que de manera periódica se asegure dicha integridad.
La DTI podrá realizar auditorias de administración de la configuración de manera independiente a fin de verificar el cumplimiento de los estándares y procedimientos para mantener la integridad de los productos de trabajo y los hallazgos detectados deberán ser corregidos por el prestador del servicio.
La Administración de Configuración de Software incluye las actividades asociadas con la identificación y mantenimiento de los componentes del sistema, las relaciones y sus dependencias. Esto permitirá al prestador identificar impactos por cambios a los entornos aplicativos y estimar mejor el esfuerzo requerido para los mismos. Estas actividades incluyen:
o Registro de las relaciones de aplicación a componente y de componente a componente.
o Mantenimiento de la historia en estas relaciones y las transformaciones necesarias para su administración y documentación (ej., control xx xxxxxxx, control de versiones, perfiles, planes de seguridad) para aquellos cambios de configuración que afectan la aplicación y su ambiente de procesamiento.
o Esta Administración se llevará a nivel lógico (componentes de programación, interfases, etc.), y la Administración de la Configuración a Nivel Físico (Hardware, Software Base, Middleware, etc.).
Productos Requeridos
Administración de cambios y configuraciones Plan de administración de la configuración Solicitud de cambio
Repositorio del proyecto
Hallazgos de auditorias de configuración
Evaluación de soluciones
Metas/Objetivos Específicos
• Análisis y Decisión de Soluciones
o Evaluar las alternativas Lineamientos Específicos:
El propósito es suministrar las guías y criterios a seguir cuando se tienen que tomar decisiones de alto impacto para un proyecto ejecutado
El prestador del servicio debe garantizar que las decisiones están basadas en alternativas de evaluación y usando criterios establecidos.
Tanto las alternativas de evaluación y criterios, deben tener como base las políticas, principios y normas establecidas por la DTI del Instituto
El establecimiento de las guías para el proceso de análisis es realizado por el prestador del servicio y las debe incorporar como parte del Modelo de Operación.
Los criterios de evaluación deben ser elaborados por el prestador del servicio estableciendo rangos y escalas de calificación para cada criterio.
La documentación de la solución recomendada es responsabilidad del prestador del Servicio. El personal de la DTI Instituto es quien aprueba la solución final, y cuando es autorizada, se realizan las actividades necesarias para el proyecto que se solicitó.
5.- SOPORTE A LA OPERACIÓN
Esta Categoría de proceso proporcionará las actividades de administración de servicios de Tecnología de Información, que permita llevar a cabo los acuerdos de niveles de servicio con las áreas aplicativas, operativas utilizando una estructura de escritorio de servicios.
Metas/Objetivos Específicos Administración de Cambios en servicios
Filtrar Solicitudes de Cambio Planear recursos para su liberación Aprobar las Solicitudes de Cambio Crear el comité de cambios
Coordinar el desarrollo de la Solicitudes de Cambio Administración de Liberaciones
Planear y controlar las liberaciones de Software.
Construir, probar e implantar las nuevas versiones de las aplicaciones de las Solicitudes de Cambio
Resguardar las copias maestras de las aplicaciones.
Administración de Aplicaciones
Lineamientos Específicos:
Este proceso deberá permitir la administración adecuada de las aplicaciones para minimizar el impacto al negocio debido a modificaciones al ambiente productivo, así como también asegurar que la liberación y despliegue de nuevas versiones se realice de manera adecuada.
El prestador del servicio deberá establecer actividades para asegurar el cumplimiento de los siguientes puntos:
o Asegurar el uso de procedimientos para el manejo eficiente y oportuno de todos los cambios
o Minimizar el impacto de los incidentes relacionados con cambios a las aplicaciones en producción, en la calidad de los servicios acordados, con un mínimo de riesgo
o Planear y controlar las liberaciones de Software.
o Implantar nuevas versiones de las aplicaciones en los ambientes de prueba, preproducción y producción
o Garantizar que todas las copias maestras de Software, estén controladas y resguardadas
El prestador del servicio tendrá la responsabilidad de diseñar y documentar las políticas, procesos y procedimientos, mediciones que garanticen estas prácticas y recomendar o apegarse a las herramientas existentes para una automatización exitosa.
La Administración de Cambios incluye las actividades para el manejo y documentación adecuada de cambios que se realicen sobre las aplicaciones y los componentes que forman parte de estas (ej. Análisis de impacto, control de versiones, administración de la biblioteca de programas, desarrollos paralelos, etc.), en base a los estándares definidos en ITIL. La Administración de Cambios, también contempla a aquellos cambios que sean necesarios en los ambientes de desarrollo. Incluyendo:
o Administración de la Biblioteca de Programas — la clasificación, control y almacenamiento físico de los componentes de la aplicación
o Control de Versiones – mantenimiento, seguimiento y auditoria a modificaciones a los componentes de la aplicación a través del tiempo, facilitando la recuperación de una aplicación durante fases previas de desarrollo
o Administración de la Rotación – La promoción automática de los cambios al Software a través de las diferentes fases del ciclo de desarrollo de sistemas (ej. Desarrollo, pruebas unitarias, pruebas de sistemas y producción), incluyendo la administración del proceso de aprobación, rotación en producción y control de migración del Software.
Todas estas actividades serán realizadas por el prestador del servicio de manera coordinada con los grupos de la DTI del Instituto, y siguiendo las políticas y procedimientos que sean definidos por el Instituto para tal efecto.
Planeación y Administración de Operaciones
Metas/Objetivos Específicos
• Administración de Niveles de Servicios
o Establecer acuerdos de niveles de servicio con clientes
o Establecer acuerdos de soporte con las áreas internas de DTI
o Establecer contratos de niveles de servicio con prestadores
• Administración de Disponibilidad
o Optimizar la capacidad de la infraestructura
o Establecer métricas
o Definir términos de disponibilidad y tiempos sin servicio claros
• Administración de la Capacidad
o Establecer categorías de análisis
o Diseñar y documentar proceso de producción del plan de capacidad
• Administración Financiera de TI
o Diseñar un modelo de costos
o Preparar presupuesto
o Analizar costos
o Identificar cargos
Lineamientos Específicos:
Establecer un conjunto de prácticas que aseguren una mejor entrega de servicios con actividades de planeación y análisis.
El prestador del Servicio deberá diseñar e implantar las políticas, procesos y procedimientos para el cumplimiento de los siguientes puntos:
Administración de Niveles de Servicio Producir un catalogo de servicios
Planear la estructura de los acuerdos de niveles de servicio Establecer los requerimientos de niveles de servicio
Crear formato de SLA Establecer métricas
Crear contratos y acuerdos de servicios operativos Definir reportes
Administración Financiera de TI
Diseñar estructura documental del modelo de costos Crear los procesos de contabilidad de TI
Establecer los métodos de recopilación de datos
Administración de la Capacidad Evaluar el ambiente actual
Planear la estructura del proceso de capacidad Inventariar las herramientas de monitoreo existentes Diseñar la base de datos de capacidad
Implementar el proceso Establecer el ambiente de prueba
Administración de la Disponibilidad
Determinar los requerimientos de disponibilidad para servicios nuevos a actuales
Categorizar actividades de diseño de disponibilidad Diseñar actividades de recuperación
Establecer consideraciones de seguridad Administrar el tiempo fuera de servicio planeado
El prestador del Servicio deberá asegurar la definición de los procesos y su implantación. El alcance de estos procesos será definido con el prestador del Servicio en mesas de trabajo 20 días posteriores a la firma del contrato.
Escritorio de Servicios
• Mesa de Servicios
o Responder llamadas
o Manejar incidentes
o Proporcionar información de avance a los usuarios
o Definir estructura de atención
• Administración de Incidentes
o Registro de incidentes
o Clasificación y soporte inicial
o Análisis y diagnostico
o Solución
o Cierre
• Administración de Problemas
o Control de problemas
o Control de errores Lineamientos Específicos:
El objetivo de este proceso es crear la estructura de manejo de incidentes a través del escritorio de servicios
El prestador del Servicio deberá diseñar e implantar las políticas, procesos y procedimientos que permitan cubrir los siguientes puntos:
Mesa de Servicios
Definir la estructura de soporte
Crear los procedimientos de atención a usuarios Administración de Incidentes
Definir los procedimientos de registro de incidente Crear los lineamientos de escalamiento
Definir las actividades para la clasificación y soporte inicial Diseñar e implantar la base de conocimientos
Crear el sistema de clasificación
Definir el proceso de investigación y diagnostico Diseñar el proceso de solución de incidentes Realizar el cierre del incidente
Administración de Problemas
Diseñar e implementar procedimientos de detección de problemas Crear el sistema de clasificación
Diseñar y documentar el proceso de investigación y diagnostico Diseñar el proceso de corrección de errores conocidos
5.- GESTIÓN DE LA CALIDAD.
En este proceso se define, planea, implementa, monitorea, controla y evalúa las áreas de los proceso a ejecutar.
Aseguramiento de calidad de procesos
Metas/Objetivos Específicos
• Aseguramiento de Calidad de Procesos y Productos
o Evaluar Objetivamente los Procesos y Productos
o Proporcionar Visibilidad Objetiva
Lineamientos Específicos:
La presente área de proceso deberá garantizar que los prestadores de servicios se desempeñan conforme al Modelo Operativo
La evaluación deberá ser realizada por medio de auditorias de aseguramiento de la calidad de procesos y productos. Los resultados de la auditoria deben ser reportados a la DTI.
El resultado de estas auditorias serán reportes donde se indique los proyectos que no cumplen con al menos uno de los requisitos solicitados, se deberá indicar con claridad las incidencias incurridas que generan el incumplimiento.
Se deben definir métricas y cada una de estas debe cumplir con un objetivo y en general, orientada a comprobar que se cumple con las metas fijadas en los procesos y los proyectos.
Las métricas están especificadas y deben estar orientadas a medir:
• La ejecución y control de proyectos.
• El desempeño de las áreas de proceso de Mantenimiento y Desarrollo
• La calidad en el producto
• La calidad y desempeño en la gestión del Modelo de Operación
• El desempeño de las áreas de proceso de Soporte al Modelo de Operación
El análisis y construcción de reportes de métricas debe ser realizado de manera periódica
Certificación de Calidad del Producto
Metas/Objetivos Específicos
• Preparar la verificación
• Seleccionar los productos a ser verificados contra los requerimientos
• Analizar y Verificar la solución técnica
• Validar los productos para asegurar que son correctos
Lineamientos Específicos:
El propósito de la certificación de calidad del producto es asegurar que los productos cumplan con los requerimientos contractuales y demostrar que el producto o servicio adquirido cumplirá con su uso deseado cuando sea colocado en el ambiente final.
El cumplimiento del uso deseado se pretende alcanzar a través de:
o Mejoramiento de la satisfacción de los clientes del Instituto y usuarios internos de los servicios de TI, reduciendo el número de defectos aplicativos descubiertos en producción
o Identificación de los defectos aplicativos de manera temprana en el ciclo de desarrollo, tal que permitan reducir los esfuerzos relacionados a actividades de reparación y re-trabajo.
o Aseguramiento que los proyectos buscan lograr la calidad desde que son conceptualizados y no hasta que los sistemas o funcionalidades correspondientes han sido construidos
o Adicionalmente se verificará el diseño detallado de la solución y su implementación para asegurarse que los requerimientos estipulados por la Gestión de Calidad en el proceso de la administración de la arquitectura tecnológica hayan sido respetados.
El Proceso para la certificación de Calidad del Producto debe cumplir con las siguientes características:
o Seleccionar los productos a ser verificados y los métodos que serán utilizados en cada caso.
o Establecer y mantener el ambiente necesario para soportar la verificación
o Establecer y mantener los procedimientos de verificación para los productos seleccionados.
o Evaluar el apego a las especificaciones de la solución técnica
o Analizar la descripción de las interfases
o Analizar los resultados de las revisiones.
o Ejecutar la verificación de los productos seleccionados.
o Analizar los resultados de las verificaciones.
Productos Requeridos
Plan de pruebas Estrategia de pruebas
Configuración del ambiente de pruebas
Bitácora de pruebas Resultado de pruebas Resumen de evaluación Suite de pruebas
Casos de prueba Datos de prueba Diseño de pruebas
Modelo de análisis de carga
Arquitectura de automatización de pruebas Lista de ideas de prueba
Especificación de interfase de pruebas Guión de pruebas
Pruebas Funcionales Planeación
Desarrollo de Casos de Prueba
Ejecución de los Casos de Prueba Desarrollados Registro y reporte de métricas de las pruebas realizadas
Adecuación de la matriz de rastreabilidad. Documento con Matriz de Rastreo de Requerimientos con ligas a Casos de Prueba
Pruebas no-funcionales Funciones de negocio Perfil de la carga de trabajo Especificaciones de prueba Scripts de prueba Resultados de prueba
Reporte de defectos encontrados Reporte de pruebas
Modelado y simulación
Evaluación y planeación – Metas y objetivos de la prueba de desempeño.
Construcción de los escenarios de prueba que reflejen la carga de usuarios a probar.
Ejecución y análisis – Predecir los cuellos de botella potenciales.
Documentar las observaciones y proporcionar recomendaciones.
Verificación de requerimientos y riesgos
El proceso de verificación de Requerimientos consiste en las actividades relacionadas con la definición y evaluación de los requisitos de los usuarios que son usados para determinar el diseño detallado de las aplicaciones Instituto.
Existen dos niveles de requerimientos a ser verificados:
Requerimientos de Negocio – Asociados con los procesos a ser soportados por un nuevo desarrollo, los objetivos y beneficios que se pretende lograr con la implantación de los mismos en un desarrollo aplicativo.
Requerimientos Funcionales – Asociados con las tareas, actividades o funciones específicas de los programas, para que de manera integrada cumplan con los objetivos definidos para el Requerimiento de Negocio
Pruebas de desempeño
Este tipo de prueba no-funcional se realizará una vez que los resultados de la prueba funcional de sistema han determinado que la aplicación o sistema es lo suficientemente estable para permitir una prueba de alto volumen.
Este tipo de prueba de calidad, establecerá los siguientes dos requerimientos de sistema:
Tiempo de respuesta Volumen y estrés
• Los requerimientos de tiempo de respuesta y volumen y estrés se establecerá a través de emuladores en lugar de utilizar los sistemas o medios externos de operación normal.
• Los emuladores utilizados deberán asegurar que la aplicación o sistema bajo prueba estará aislada de condiciones que puedan afectar los resultados de la prueba.
• Este tipo de prueba será ejecutada sólo en los proyectos que el INSTITUTO lo solicite y/o el plan de pruebas desarrollado por el prestador de esta partida lo recomiende.
Los tipos de prueba de desempeño que deberán ejecutarse a solicitud del Instituto son las siguientes:
• Pruebas de carga (Load Testing / Volume Testing / Peak Load Testing) – Este tipo de prueba consiste en hacer operar a la aplicación o sistema que se desea verificar su calidad, a una carga pico durante un periodo de tiempo corto que será determinado por los requerimientos establecidos en el plan de pruebas. El objetivo, es determinar si la aplicación o sistema es capaz de manejar los volumenes de usuarios y datos establecidos en las especificaciones de usuario (requerimientos)
• Pruebas de estrés (Stress Testing – Double Peak Load Testing) Este tipo de prueba consiste en hacer operar la aplicación o sistema que se desea verificar su calidad, a través del incremento gradual de la carga durante un periodo de tiempo corto que será determinado por los requerimientos establecidos en el plan de pruebas. El incremento continuará hasta que la aplicación o sistema deje de operar. La carga pico determinará el límite máximo de volumen de usuarios y datos que la aplicación o sistema es capaz de manejar y de esta forma verificar el cumplimiento de las especificaciones de usuario (requerimientos).