AGIL-MANTEMA
Una propuesta metodológica ágil para el mantenimiento de Software
Índice General
1. Introducción...6
2. Fundamentos...7
2.1. Scrum...7
2.1.1. Participantes de Scrum...9
2.1.2. El Ciclo de Vida de Scrum...10
2.1.3. Estructura Detallada de Scrum...11
2.2. MANTEMA...15
2.2.1. Estructura general de la Metodología...15
2.2.2. Estructura Detallada de la Metodología...21
2.2.3. Métricas usadas en MANTEMA...31
3. AGIL-MANTEMA...32
3.1. Estructura General de la Metodología...32
3.1.1. Integración con otros Procesos...33
3.1.2. Tipos de Mantenimiento en la Metodología...34
3.1.3. Participantes en el Proceso de Mantenimiento...36
3.1.4. Descripción del Proceso de Mantenimiento...38
3.2. Estructura Detallada de la Metodología...40
3.2.1. Planificación del Proceso...40
3.2.2. Actividad Inicial...44
3.2.3. Actividades y Tareas del Sprint Mantenimiento No Planificable...47
3.2.4. Actividades y Tareas del Sprint Mantenimiento Planificable...50
3.2.5. Actividades y Tareas Intermedias...53
3.2.6. Actividades y Tareas Finales...56
3.2.7. Finalización de la Externalización...61
4. Interfaces con otros procesos...63
4.1. Aseguramiento de la Calidad...63
4.1.1. Tarea AC1: Revisión del Mantenimiento...64
4.1.2. Tarea AC2: Comprobación de la Existencia del Plan de Pruebas de Regresión ...64
4.1.3. Tarea AC3: Revisión de la Realización de las Pruebas de Regresión...65
4.2. Gestión de la Configuración...66
4.2.1. Tarea GC1: Implementar proceso de Gestión de Configuración...67
4.2.2. Tarea GC2: Registro del Cambio en el Sistema de Gestión de la Configuración ...67
4.2.3. Tarea GC3: Registro de la Nueva Versión de los Productos Afectados por el Cambio en el Sistema de Gestión de la Configuración...68
5. Discusión y Conclusiones...69
Anexo A: Contenido de los Diferentes Documentos...71
Anexo A.1. DOC1 – Petición de Modificación...71
Anexo A.2. DOC2 – Pruebas Unitarias Realizadas...73
Anexo A.3. DOC3 – Diagnóstico y Posibles soluciones...74
Terminología...75
6. Bibliografía...76
Índice de Figuras.
Figura 2.1. Ciclo de Vida de Scrum...10
Figura 2.2. Ciclo de Carrera de Scrum...12
Figura 2.3. Product Backlog de Scrum...12
Figura 2.4. Sprint Backlog de Scrum...13
Figura 2.5. Macroestructura del Proceso de Mantenimiento de ISO/IEC 12207...15
Figura 2.6. Visión General de los Procesos en la Metodología...16
Figura 2.7. Tipos de Mantenimiento en MANTEMA...17
Figura 2.8. Actividades que componen la Metodología...19
Figura 2.9. Actividades Cíclicas en la Metodología...20
Figura 3.1. Macroestructura del Proceso de Mantenimiento en AGIL-MANTEMA...32
Figura 3.2. Proceso de AGIL-MANTEMA...39
Figura 4.1. Interfaz del proceso de mantenimiento con el Aseguramiento de la Calidad...64
Figura 4.2. Interfaz del proceso de mantenimiento con la Gestión de Configuración...67
Índice de Tablas.
Tabla 3.1. Tabla con niveles de servicios disponibles en AGIL-MANTEMA...33 Tabla 3.2. Tabla Resumen de Actividad I0. Planificación del Proceso...43 Tabla 3.3. Tabla Resumen de Actividad I1. Análisis de la Petición...46 Tabla 3.4. Tabla Resumen de Actividades y Tareas del Sprint Mantenimiento No Planificable.
...49 Tabla 3.5. Tabla Resumen de Actividades y Tareas del Sprint Mantenimiento Planificable....52 Tabla 3.6. Tabla Resumen de Actividades y Tareas Intermedias...55 Tabla 3.7. Tabla Resumen de Actividades y Tareas Finales (Finalización de la Intervención) ...58 Tabla 3.8. Tabla Resumen de Actividades y Tareas Finales (Retirada)...60 Tabla 3.9. Tabla Resumen de Actividad Finalización de la Externalización...62
1. Introducción.
En los últimos años, la tecnología ha desencadenado una revolución que ha tenido claras repercusiones en el mundo de los negocios. Todo esto ha generado que el mantenimiento de software cobre una enorme importancia haciendo necesario no sólo el adaptar los sistemas a nuevos requerimientos de las empresas, sino también la continua vigilancia de su correcto funcionamiento.
Según múltiples estudios se ha comprobado que las tareas del proceso de mantenimiento son la parte más costosa del ciclo de vida del software, en algunos casos llega a duplicar los costos de desarrollo [CAR1990]. La tendencia es creciente con el paso del tiempo a medida que incrementa la producción de software [HAN1993]. Esta tendencia se agudiza al utilizarse técnicas y metodologías poco aptas para el mantenimiento del software.
Las micro, pequeñas y medianas empresas (Pymes) son una pieza muy importante en el engranaje de la economía mundial. La industria del software en la mayoría de los países ésta formada en gran parte por Pymes [REV2006]. Para fortalecer este tipo de organizaciones se necesitan prácticas eficientes de Ingeniería del Software adaptadas a su tamaño, tipo de negocio y necesidades.
Es por estas razones, que en este trabajo se presenta una metodología para la gestión del proceso de mantenimiento de manera ágil en las Pymes. Esta metodología incluye:
1. Un modelo del proceso de mantenimiento, en el que se entiende como proceso una secuencia de actividades y tareas.
2. Un marco para definir la estructura de las organizaciones que intervienen en el proceso de mantenimiento.
3. Principios como lo son la colaboración, motivación, simplicidad, trabajo en equipo y el incremento de responsabilidad a través de la auto-gestión, auto-organización y compromiso que se deben adquirir durante el proceso.
4. Interfaces, susceptibles de ser empleadas en determinados momentos del proceso.
2. Fundamentos.
2.1. Scrum.
Esta es, después de XP, la metodología ágil mejor conocida y la que otros métodos ágiles recomiendan como complemento.
Como metodología ágil específicamente referida a ingeniería de software, Scrum fue aplicado por Jeff Sutherland y elaborada más formalmente por Ken Schwaber. Poco después Sutherland y Schwaber se unieron para refinar y extender Scrum. En Scrum se aplicaron principios de procesos de control industrial, junto con experiencias metodológicas de Microsoft, Borland y Hewlett-Packard. Schwaber, en particular, había trabajado con científicos de Du Pont para comprender mejor los procesos definidos de antemano, y ellos le dijeron que a pesar que CMM se concentraba en hacer que los procesos de desarrollo se tornaran repetibles, definidos y predecibles, muchos de ellos eran formalmente impredecibles e irrepetibles porque cuando se está planificando no hay primeros principios aplicables, los procesos recién comienzan a ser comprendidos y son complejos por naturaleza. Schwaber se dio cuenta entonces de que un proceso necesita aceptar el cambio, en lugar de esperar predictibilidad.
Scrum no está concebido como método independiente, sino que se promueve como complemento de otras metodologías, como XP, MSF o RUP. Como método, Scrum enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, implementación y demás cuestiones técnicas; de allí su deliberada insuficiencia y su complementariedad. Scrum se define como un proceso de administración y control que implementa técnicas de control de procesos; se lo puede considerar un conjunto de patrones organizacionales [REY2004].
Los valores de Scrum son:
Equipos auto-dirigidos y auto-organizados. No hay manager que decida, ni otros títulos que “miembros del equipo”; la excepción es el Gestor del Scrum (Scrum Master) que debe ser 50% programador y que resuelve problemas, pero no manda.
Los observadores externos; pueden observar, pero no interferir ni opinar.
Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa.
Encuentros diarios con las tres preguntas: ¿Qué has hecho desde el último encuentro? ¿Qué obstáculos hay para cumplir la meta? ¿Qué harás antes del próximo encuentro? Los encuentros se realizan siempre en el mismo lugar, en círculo. El encuentro diario impide caer en atrasos.
Iteraciones de treinta días; se admite que sean más frecuentes.
Demostración a participantes externos al fin de cada iteración.
Al principio de cada iteración, planeamiento adaptativo guiado por el cliente.
Algunos textos sobre Scrum establecen una arquitectura global en la fase de pre-juego;
otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseño emanan de múltiples iteraciones (creación de nuevas funcionalidades). No hay una ingeniería del software prescrita para Scrum; cada quien puede escoger entonces las prácticas de automatización, inspección de código, prueba unitaria, análisis o programación en pares que le resulten adecuadas.
Es habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un marco de gestión basado en patrones organizacionales, mientras XP constituye la práctica de programación, usualmente orientada a objetos y con fuerte uso de patrones de diseño. Uno de los nombres que se utiliza para esta alianza es XP@Scrum.
2.1.1. Participantes de Scrum.
Scrum define cuatro roles:
Gestor del Scrum (Scrum Master). Interactúa con el cliente y el equipo. Es responsable de asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de Scrum y que progrese según lo previsto. Coordina los encuentros diarios, formula las tres preguntas canónicas y se encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la par.
Propietario del Proyecto (Product Owner). Es el responsable oficial del proyecto, gestión, control y visibilidad de la lista de acumulación (Product Backlog). Es elegido por el Gestor del Scrum, el cliente y los ejecutivos a cargo. Toma las decisiones finales de las tareas asignadas al registro y convierte sus elementos en rasgos a desarrollar.
Equipo de Scrum. Tiene autoridad para reorganizarse y definir las acciones necesarias o sugerir remoción de impedimentos. Son los que transforman los requerimientos en funcionalidad en cada incremento.
Usuarios.
La dimensión del equipo total de Scrum no debería ser superior a diez ingenieros. El número ideal es siete, más o menos dos. Si hay más, lo más recomendable es formar varios equipos. No hay una técnica oficial para coordinar equipos múltiples, pero se han documentado experiencias de hasta 800 miembros, divididos en Scrums de Scrum, definiendo un equipo central que se encarga de la coordinación, las pruebas cruzadas y la rotación de los miembros.
2.1.2. El Ciclo de Vida de Scrum.
Esta metodología comienza cuando la organización requiere agilizar un proyecto de software, es aquí donde empieza su ciclo de vida el cual se divide en 3 partes: Pre-juego, Juego y el Pos-juego. En el pre-juego se busca el planeamiento del proyecto y se identifican los requerimientos más importantes para la organización, esta fase dará lugar al juego en donde se realizara la implementación de los requisitos, cuando esta implementación termine ingresaran a la fase final llamada pos-juego, en donde será la presentación de la funcionalidad a los clientes y también se extraerán las posibles mejoras al proceso.
Figura 2.1. Ciclo de Vida de Scrum
2.1.3. Estructura Detallada de Scrum.
A continuación se detallaran cada una de las fases de Scrum.
2.1.3.1. Pre-Juego:
El pre-juego es la etapa inicial del ciclo de vida de Scrum, esta actividad se divide en las dos tareas que se describirán a continuación:
Planeamiento: El propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (Backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción.
Montaje (Staging): El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.
2.1.3.2. Juego o Desarrollo.
El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas Sprints. Esta actividad la descomponemos en las tareas de planeamiento del Sprint, la definición y estimación del Sprint Backlog, y una serie de encuentros diarios dentro del Sprint.
2.1.3.2.1. Ciclo de Carrera.
Figura 2.2. Ciclo de Carrera de Scrum.
La lista de Acumulación del Producto (Product Backlog figura 2.3) contiene todos los rasgos, tecnología, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará debilidades o problemas que deberán resolverse.
Product Backlog Fecha:
Estimado Tipo: Nuevo_ Mejora_ Arreglo_ Fuente:
Descripción:
Notas:
Figura 2.3. Product Backlog de Scrum.
El Sprint Backlog tiene este formato:
Sprint Backlog Fecha:
Propietario: Trabajo Pendiente/Fecha
Status: Pendiente_ Activo_ Completo_
Descripción:
Notas:
Figura 2.4. Sprint Backlog de Scrum.
El registro incluye los valores que representan las horas de trabajo pendiente; en función de esos valores se acostumbra elaborar un gráfico de quemado.
Al fin de cada iteración de treinta días hay una demostración a cargo del Gestor del Scrum (Scrum Master). Las presentaciones en PowerPoint están prohibidas. En los encuentros diarios, el cliente debe estar fuera del círculo. Todos tienen que ser puntuales.
2.1.3.3. Pos-Juego.
El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta, también dentro de estas actividades se destacan la revisión del sprint y la reunión retrospectiva.
2.1.3.3.1. Revisión del Sprint.
Reunión del equipo, gestor del Scrum y el propietario del producto con todas las personas implicadas en el proyecto. Su finalidad es presentar al propietario del producto y a los usuarios las nuevas funcionalidades implementadas, al final de la reunión se interrogan individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia, el propietario del producto trata con los asistentes y con el equipo las posibles modificaciones en la pila del producto. [PAL2001]
2.1.3.3.1. Reunión Retrospectiva.
Acuden el equipo y el Gestor del Scrum, y opcionalmente el Propietario del Producto.
Se pregunta: ¿Qué cosas fueron bien en el último sprint? y ¿Qué cosas se podrían mejorar?, el Gestor anota todas las respuestas, el equipo prioriza las mejoras posibles, el Gestor del Scrum no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum, las acciones de mejora localizadas que se puedan implementar en el próximo Sprint deben introducirse en la pila de producto como elementos no funcionales. [PAL2001]
2.2. MANTEMA.
La metodología MANTEMA muestra la visión del proceso de mantenimiento desde el mayor nivel de abstracción, en el que probablemente no interesa el contenido de las instrucciones ni los campos de los archivos, aunque sí las mejores técnicas para entenderlos y modificarlos. Desde este punto de vista, el proceso puede verse como el conjunto de todas las operaciones que es necesario realizar sobre el software para implementar las modificaciones solicitadas. Sin embargo, para dotar a este conjunto de operaciones de una base metodológica, es preciso definir con anterioridad el propio proceso de mantenimiento, detallando qué debe realizarse, cuándo, cómo y por quién, de tal manera que cada intervención de mantenimiento que se ejecute conforme una instancia de un proceso de mantenimiento predefinido. [POL1999].
2.2.1. Estructura general de la Metodología.
El estudio detallado del proceso de Mantenimiento de ISO/IEC 12207 permitió la identificación en él de la macroestructura mostrada en la Figura 2.5. Tal estructura fue elegida como punto de partida para esta metodología.
Figura 2.5. Macroestructura del Proceso de Mantenimiento de ISO/IEC 12207.
2.2.1.2. Integración de Procesos.
Por otro lado, la metodología pretende la definición de un único proceso de aquéllos que componen el ciclo de vida software: el mantenimiento. Durante éste se realizan trabajos de análisis y diseño, programación, pruebas, documentación, etc. Se pretende que esta metodología constituya una guía completa de mantenimiento, por lo que integra y describe, un único proceso software, las actividades de los procesos habituales del ciclo de vida software [POL1999].
Esquemáticamente, el resultado de tal integración puede verse de la forma expresada en la Figura 2.6, en la que se observan, como procesos satélites al mantenimiento y otros procesos del ciclo de vida cuya integración no se ha llevado a cabo pero que, sin embargo, son utilizados por nuestro proceso de mantenimiento estableciendo interfaces en algunas tareas:
Figura 2.6. Visión General de los Procesos en la Metodología.
2.2.1.3. Tipos de Mantenimiento en la Metodología.
En MANTEMA se distinguen dos grandes grupos de tipos de mantenimiento los planificable y los no planificables. Dentro del primero se pueden identificar: Correctivo no urgente, perfectivo, preventivo y adaptativo mientras que en el segundo solo podemos encontrar un tipo el correctivo urgente. Esta división la podemos ver con mejor claridad en la Figura 2.7. A continuación describiremos brevemente cada uno de ellos:
1) Correctivo urgente: Son aquellos cambios precisos para corregir errores urgentes del producto de software.
2) Correctivo no urgente: Son aquellos cambios precisos para corregir errores no urgentes del producto de software.
3) Perfectivo: Son las incorporaciones, modificaciones y eliminaciones necesarias en un producto de software para cubrir la expansión o cambio en las necesidades del usuario.
4) Adaptativo: Son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, gestores de bases de datos, comunicaciones, etc.
5) Preventivo: Son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.
Figura 2.7. Tipos de Mantenimiento en MANTEMA.
2.2.1.4. Participantes del Proceso de Mantenimiento.
MANTEMA distingue tres organizaciones que pueden participar en el proceso de mantenimiento y estas a su vez constan de perfiles dentro de ella. Dependiendo de la situación de cada organización pueden coincidir varias en una sola. Lo mismo puede ocurrir con los perfiles. A continuación se definen las organizaciones y sus participantes dentro del proceso de mantenimiento descritos en MANTEMA [POL1999].
1) Cliente: Es la organización propietaria del software y por tanto, la que recibe el servicio de mantenimiento, dentro de esta organización encontramos los siguientes perfiles:
a) Solicitante: es quien presenta las solicitudes de modificación. Establece los requerimientos necesarios para su implementación y los entrega a la organización de mantenimiento.
b) Organización del Sistema: es el departamento que conoce el sistema que será mantenido.
c) Atención a Usuarios: es el departamento que presta asistencia a los usuarios.
2) Organización de Mantenimiento: Es la organización que realiza el servicio de mantenimiento y consta de los siguientes perfiles:
a) Gestor de peticiones : acepta o rechaza las peticiones modificación y decide el tipo de mantenimiento que debe aplicarse.
b) Planificador: planifica la cola de peticiones de modificación aceptadas.
c) Equipo de Mantenimiento: es el grupo de personas que implementa la solicitud de modificación.
d) Responsable de Mantenimiento: prepara la etapa de mantenimiento, y establece las normas y procedimientos necesarios para llevar a cabo la metodología de mantenimiento usada.
3) Usuario: Es la Organización que utiliza el software objeto del mantenimiento.
2.2.1.5. Ciclo de Vida del Mantenimiento.
El proceso de mantenimiento descrito en MANTEMA comienza con la solicitud de prestación de servicios de mantenimiento de una organización a otro.
Una vez que la organización cliente se pone en contacto con la organización suministradora del servicio de mantenimiento, ésta realiza un estudio inicial del software cuyo mantenimiento se solicita y del hardware sobre el que éste se ejecuta. Tras este estudio, se pretende que la organización que presta el servicio conozca las características del sistema de información que se va a mantener, de manera que, si procede, pueda ir preparando presupuestos, contratos de prestación de servicios, etc.
Cuando la organización cliente acepta la propuesta de mantenimiento de la organización suministradora del servicio, se realiza una planificación del proceso a la medida de la organización cliente. Estas acciones se llevan a cabo en el conjunto de Actividades y tareas iníciales Tras esta segunda actividad (Planificación del proceso), la responsabilidad de la ejecución de las intervenciones de mantenimiento sobre el software convenido en la actividad primera (Estudio inicial) recae ya sobre la organización de mantenimiento, que estará preparada para recibir peticiones de modificación, clasificarlas de acuerdo a uno de los tipos de mantenimiento definidos en MANTEMA y servirlas conforme a las actividades (y a sus correspondientes tareas) enunciadas en los nodos centrales de la Figura 2.8.
[POL1999].
Figura 2.8. Actividades que componen la Metodología.
Actividades y Tareas Finales Actualiz.
De la BD histórica
Registro Interv.
Retirada Fin Externaliz.
Actividades y Tareas Iníciales Estudio
Inicial
Planif. Del Proceso
Análisis de la Petición
Análisis del Error
Intervención Cierre Actividades y Tareas del no
Planificable
Análisis del Error
Intervención y Pruebas
Cierre Actividades y Tareas del
Planificable
Ya servida completamente la petición (lo cual incluye el paso a producción del software modificado), la organización de mantenimiento llega al nodo final, en el que, para cada petición de modificación, debe ejecutar algunas de las Actividades y tareas finales, comunes también a todos los tipos de mantenimiento. En particular, debe realizarse la actualización de la base de datos histórica para almacenar toda la información relevante de la petición, registrar la intervención y, en caso necesario, proceder a la retirada del software. La actividad denominada Fin de la externalización es realizada cuando ha existido una relación contractual de prestación de servicios de mantenimiento entre organizaciones diferentes que llega a su punto final o, más genéricamente, cuando va a cambiar la organización suministradora del servicio de mantenimiento.
Se observan dos conjuntos de actividades claramente diferentes (Figura 2.9):
El primero, formado por las actividades que, por lo general, son realizados solamente una vez, tanto al principio como al final del proceso de mantenimiento (Estudio inicial y Planificación del proceso, en las Actividades y tareas iníciales, y Fin de la externalización, en las Actividades y tareas finales).
El segundo, compuesto de un conjunto de actividades repetitivo, que se ejecuta una vez para cada petición de modificación recibida, y que son las que se encuentran situadas, en la Figura 2.9, entre las mencionadas en el punto anterior.
Figura 2.9. Actividades Cíclicas en la Metodología.
Actividades y Tareas Finales Actualiz.
De la BD histórica
Registro Interv.
Retirada Fin Externaliz.
Actividades y Tareas Iníciales Estudio
Inicial
Planif. Del Proceso
Análisis de la Petición
Análisis del Error
Intervención Cierre Actividades y Tareas del no
Planificable
Actividades y Tareas del Planificable Análisis
del Error
Intervención y Pruebas
Cierre
2.2.2. Estructura Detallada de la Metodología.
En esta sección se mostrarán en resumen las actividades y tareas iníciales, actividades y tareas propias de cada tipo de mantenimiento y las actividades y tareas finales.
2.2.2.1. Actividades y Tareas Iníciales Comunes.
Actividad I0. Estudio inicial. Esta actividad consta de las siguientes tareas:
Tarea I0.1 Iniciar y recoger información. En esta tarea, como respuesta a una Solicitud de prestación del servicio de mantenimiento, el Equipo de mantenimiento y la Organización del sistema rellena un Cuestionario inicial en el que detalla ciertos aspectos del software que se deberá mantener (sistema operativo, lenguaje o lenguajes de programación, número de programas y cualesquiera otros datos que puedan resultar de interés para la Organización de mantenimiento), según una muestra tomada del producto software.
Tarea I0.2 Preparar propuesta de mantenimiento. De los datos recogidos en la tarea I0.1, el Responsable de mantenimiento crea una Propuesta de mantenimiento del software. En la preparación de la propuesta (a la que, en su caso, acompañará una propuesta económica), puede utilizarse la técnica de Identificación de Riesgos.
Tarea I0.3 Contrato. Se redacta y se firma el Contrato de mantenimiento entre la Organización del sistema y el Responsable de mantenimiento. Esta tarea puede omitirse si ambas organizaciones son la misma, aunque su ejecución sea obligatoria cuando exista externalización.
Actividad I1. Planificación del proceso. Esta actividad consta de las siguientes tareas:
Tarea I1.1 Planificar calendario y responsables. Se genera un calendario de
reuniones y se enumeran los interlocutores válidos y los responsables de ambas partes.
Las reuniones planificadas pueden servir como hitos de comprobación de resultados.
Tarea I1.2 Adquirir conocimiento de la aplicación. En esta tarea, el Equipo de mantenimiento debe estudiar la documentación existente del software objeto de la prestación del servicio, el código de los programas, referencias cruzadas, entrevistarse con los usuarios, observar cómo trabaja la organización de mantenimiento actual, etc.
Durante esta tarea, el encargado de resolver las peticiones de modificación es el propio Cliente (o la organización que tenga en ese momento contratada); sin embargo, el Equipo de mantenimiento observa su trabajo para conocer mejor el software objeto de la prestación del servicio.
Esta tarea puede durar entre uno y dos meses, durante los cuales el Equipo de mantenimiento no habrá probablemente modificado una sola línea de código. Al finalizar esta tarea, el Equipo de mantenimiento debe entregar al Cliente un informe acerca del estado de su software, de manera que, entre otras cosas, se permite verificar que el Equipo de mantenimiento ha adquirido un conocimiento adecuado del software que deberá mantener.
Por otro lado, las circunstancias pueden hacer que esta tarea no sea ejecutada total o parcialmente (el software no ha sido mantenido con anterioridad, por ejemplo).
Tarea I1.3 Desarrollar planes. El Equipo de mantenimiento desarrolla los planes de mantenimiento y construye el Resumen Técnico del aplicativo, una vez adquirido el conocimiento.
Debe inventariarse el sistema de información que se va a mantener, para cada aplicación y base de datos.
Tarea I1.4 Definir procedimientos de petición de modificación. El Equipo de mantenimiento genera modelos de documentos para la presentación de cada Petición de modificación. Así mismo, establece, junto al Cliente, los procedimientos de petición de modificación, en los que indica quién será el receptor de la petición, quién es el encargado de su estudio, etc.
Tarea I1.5 Implementar proceso de Gestión de Configuración. Esta tarea establece una interfaz con el proceso de gestión de configuración existente en la organización para gestionar las modificaciones que se realicen sobre el sistema existente.
Tarea I1.6 Preparar entornos de pruebas. El Equipo de mantenimiento prepara copias del entorno software de producción para implementar sobre ellas las intervenciones de mantenimiento.
Actividad I2. Análisis de la petición de modificación. Esta actividad consta de las siguientes tareas.
Tarea I2.1 Recibir petición de modificación. El Solicitante o, en caso de estar autorizado para ello, el Usuario, entrega una Petición de modificación que es recibida y registrada por el Gestor de peticiones, que le asigna un identificador único.
Tarea I2.2 Decidir tipo de mantenimiento. A partir de la Petición de modificación recibida y registrada en la tarea I2.1, el Gestor de peticiones decide o bien rechazar la petición, o bien aceptarla y decidir el tipo de mantenimiento que debe aplicarse. En caso de elegir la primera opción, deben justificarse las razones. En caso de aceptación, la petición de modificación es entregada al Planificador que la distribuye y encauza al tipo de mantenimiento que corresponda.
2.2.2.2. Actividades y Tareas del Mantenimiento NO Planificable.
Actividad NP1. Análisis del error. Esta actividad consta de las siguientes tareas:
Tarea NP1.1 Investigar y analizar causas. El Equipo de mantenimiento analiza la Petición de Modificación, verifica el problema (quizás con la colaboración del Usuario) y lo reproduce, y estudia diferentes alternativas para implementar la modificación. Además, debe construir una lista de los elementos software a corregir (módulos, rutinas, documentos, etc.).
Actividad NP2. Intervención correctiva urgente. Esta actividad consta de las siguientes tareas:
Tarea NP2.1 Realizar acciones correctivas. El equipo de mantenimiento ejecuta las acciones necesarias para corregir el problema detectado.
Deben identificarse las rutinas y bases de datos afectadas por la intervención.
Tarea NP2.2 Cumplimentar documentación. El Equipo de mantenimiento debe documentar los cambios realizados en el Documento de Acciones Correctivas Realizadas.
Tarea NP2.3 Ejecutar pruebas unitarias. El Equipo de mantenimiento debe comprobar la corrección de todos los cambios realizados. Estas pruebas se documentarán en el Documento de Pruebas Unitarias Realizadas.
Actividad NP3. Cierre intervención. Esta actividad consta de la siguiente tarea:
Tarea NP3.1 Pasar a producción. El Equipo de mantenimiento pasa al entorno de producción el software corregido para su utilización por parte de los usuarios. Se establece aquí una interfaz con el proceso de Gestión de la Configuración para garantizar la corrección de la tarea.
2.2.2.3. Actividades y Tareas del Mantenimiento Planificable.
Puesto que no todas las actividades del mantenimiento planificable son aplicables a todos los tipos de mantenimiento que hemos englobado bajo esta denominación (correctivo no urgente, perfectivo, preventivo y adaptativo) -ya que conservan algunas diferencias-, indicamos con las siguientes claves los tipos de mantenimiento a los que cada tarea es aplicable. Las claves serán CP para el Mantenimientos correctivo no urgente y perfectivo. A para el mantenimiento Adaptativo y P para el Preventivo.
Actividad P1. Análisis de la petición. Esta actividad consta de las siguientes tareas:
Tarea P1.1 Valorar petición (CP/P). La Petición de modificación que fue recibida en la tarea I2.1 del conjunto de Actividades y tareas iníciales comunes y distribuida en la tarea I2.2- está ya en posesión del Equipo de mantenimiento que va a llevar a cabo la intervención.
En esta tarea, se valoran los costes y esfuerzos necesarios para servir la petición.
Igualmente, se valoran la disponibilidad de recursos y de calendario para estimar los plazos de la intervención.
Tarea P1.2 Documentar posibles soluciones (CP/P). A partir del producto software en explotación y de la petición de modificación:
Si se trata de CP (correctivo no urgente o perfectivo), se documenta la causa del error y se indican las posibles alternativas de implementación en el documento de Diagnóstico del Error y Posibles Soluciones dejando pendiente de rellenar la alternativa de implementación elegida.
Si se trata de P (preventivo), se produce una Lista de Elementos Software y Propiedades Mejorables.
Tarea P1.3 Elegir alternativa adecuada (CP). El equipo de mantenimiento completa el documento de Diagnóstico del Error y Posibles Soluciones indicando la alternativa de corrección elegida. Para la elección de la alternativa pueden realizarse estimaciones de datos de proyectos anteriores para optimizar la dedicación de recursos.
Actividad P2. Intervención y pruebas. Esta actividad consta de las siguientes tareas:
Tarea P2.1 Planificar calendario (A). El Equipo de mantenimiento realiza una planificación del calendario de la intervención en el que debe detallar cuándo se acometerán las diferentes fases de la adaptación.
Tarea P2.2 Realizar copia del producto software (A). Antes de iniciar la intervención adaptativa, el equipo de mantenimiento realiza una copia del producto software y de todas las bases de datos, ficheros, etc. relacionados.
Tarea P2.3 Ejecutar intervención (CP/P/A). El equipo de mantenimiento debe ejecutar las acciones necesarias para servir la petición de modificación conforme a la alternativa seleccionada.
Tarea P2.4 Ejecutar pruebas unitarias (CP/P/A). El Equipo de mantenimiento realiza las pruebas unitarias sobre el producto software intervenido. Debe comprobarse que la Petición de Modificación queda servida. Una vez finalizadas, se genera el Documento de Pruebas Unitarias Realizadas.
Tarea P2.5 Ejecutar pruebas de integración (CP/P/A). El Equipo de mantenimiento debe comprobar que los diferentes elementos software funcionan correctamente de forma conjunta.
Tarea P2.6 Ejecutar paralelamente en software antiguo y nuevo (CP/P/A). El Equipo de mantenimiento ejecuta acciones reales en el producto software antiguo y en el modificado para detectar y prevenir posibles errores de proceso. Pueden aplicarse pruebas de no regresión, de manera que se repiten casos de prueba anteriores a la intervención. En el caso del mantenimiento adaptativo se reconstruye, si es preciso, la documentación técnica del sistema.
Tarea P2.7 Verificar y validar corrección con el cliente (CP/P/A). El Equipo de mantenimiento y la Organización del sistema (o el perfil en que se haya delegado) se reúnen para comprobar que el producto intervenido funciona correctamente.
Tarea P2.8 Redocumentar manual de usuario (CP/P/A). El Equipo de mantenimiento debe redocumentar el manual de usuario, si es que ha cambiado el modo de operación del software.
Tarea P2.9 Pasar a producción (CP/P/A). El Equipo de mantenimiento instala el producto software modificado en el entorno de trabajo real. En el caso del mantenimiento adaptativo (y tal vez en algún caso aislado de otro tipo de mantenimiento), puede establecerse una interfaz con el Proceso de Infraestructura por si es preciso cambiar o agregar máquinas, etc.
Tarea P2.10 Realizar revisión (CP/A). El Equipo de mantenimiento comprueba que el producto modificado funciona correctamente en el entorno de trabajo real.
Actividad P3. Cierre de intervención. Esta actividad consta de la siguiente tarea:
Tarea P3.1 Archivar datos del producto software inicial (A). El Equipo de mantenimiento realiza una copia de seguridad de todo lo relacionado con el producto software que se ha adaptado (programas, datos, documentación, etc.).
2.2.2.4. Actividades y Tareas Finales Comunes.
Actividad F1. Registro de la intervención. Esta actividad consta de la siguiente tarea:
Tarea F1.1 Registrar intervención. La intervención queda registrada, según los procedimientos de la organización.
Actividad F2. Actualización de la base de datos histórica. Esta actividad consta de las siguientes tareas:
Tarea F2.1 Recoger información de la intervención. Si las métricas indicadas para cada tarea no se hubieran ido recogiendo y almacenando durante la intervención, tal recolección debería ser hecha en esta tarea.
Tarea F2.2 Actualizar base de datos. Los datos recogidos en la tarea anterior son incorporados a la base de datos histórica.
Actividad F3. Retirada. Esta actividad consta de las siguientes tareas:
Tarea F3.1 Desarrollar plan de retirada. El Equipo de mantenimiento redacta un documento en el que describe cuándo se llevará a cabo la retirada del software.
Tarea F3.2 Notificar futura retirada. El Equipo de mantenimiento notifica al Cliente el momento en el que se ejecutará la retirada.
Tarea F3.3 Ejecutar paralelo. El Usuario, con el visto bueno del Cliente y bajo la supervisión del Equipo de mantenimiento, realiza operaciones reales sobre el software que se va a retirar y el software nuevo (si es que aquél va a ser sustituido).
Tarea F3.4 Notificar retirada. Se notifica la inminencia de la retirada.
Tarea F3.5 Almacenar datos del entorno antiguo. Los datos del entorno antiguo son almacenados.
Actividad F4. Fin de la externalización.
Tarea F4.1 Entrega del inventario y de la documentación. Dependiendo de lo que se pactara en el contrato, posiblemente la Organización de mantenimiento se encuentre obligada a entregar al cliente todos los productos software generados y modificados durante el periodo en que ha sido responsable del mantenimiento.
Tarea F4.2 Traspaso de experiencia y formación. Esta es la tarea inversa a la I1.2 (Adquirir conocimiento de la aplicación), durante la cual el Equipo de mantenimiento aprendió las características del sistema observando el modo de trabajo de la organización de mantenimiento que el Cliente tuviera a la sazón. En este caso, es la Organización de mantenimiento la que debe formar al nuevo personal de mantenimiento. En el último periodo de esta tarea (variable según el contrato), el mantenimiento se realiza con equipos mixtos.
Tarea F4.3 Cesión definitiva del servicio. La Organización de mantenimiento deja de prestar sus servicios al Cliente con carácter definitivo.
2.2.3. Métricas usadas en MANTEMA.
En MANTEMA encontramos una serie de técnicas y métricas, cuya utilización se recomienda como apoyo al proceso de mantenimiento antes descrito, en esta sección se describirán estas métricas y técnicas.
Una técnica que identifica, las características de los proyectos de mantenimiento que más riesgos producen. (Identificación y estimación de riesgos)
Modelo económico del proyecto de mantenimiento, que permite calcular la cantidad de recursos que deben dedicarse a un periodo a servir peticiones de mantenimiento no planificable. (Estimación de Recursos para el mantenimiento no planificable)
Una serie de métricas de mantenibilidad de esquemas conceptuales y lógicos de base de datos.
Un conjunto de métricas de tamaño y complejidad de sistemas orientadas a objeto.
Un conjunto de métricas para controlar el proceso de mantenimiento.
3. AGIL-MANTEMA.
En este capítulo se presenta la propuesta metodológica ofrecida por AGIL- MANTEMA, que nace de la agilización de MANTEMA a través de Scrum, y está organizado de la siguiente forma: en la sección 3.1 explicaremos como se obtuvo una estructura básica para la definición del proceso de mantenimiento a partir de MANTEMA, presentando gráficamente la estructura general de la metodología y explicando la integración de procesos sobre el mantenimiento, así como los diferentes tipos de mantenimiento que se consideran y la identificación de las organizaciones que intervienen en el proceso. Posteriormente, en la sección 3.2 pasaremos a describir muy en detalle las diferentes partes de la metodología, deteniéndose en cada actividad y tarea especificando cuidadosamente cada una de ellas.
3.1. Estructura General de la Metodología.
La macroestructura general de esta metodología se basa en la presentada en MANTEMA y en la del estándar ISO/IEC 12207. Esta macroestructura se puede observar en la siguiente figura.
Figura 3.1. Macroestructura del Proceso de Mantenimiento en AGIL-MANTEMA.
Esta macroestructura se complementa con la utilización de niveles de servicio extraída de Métrica Versión 3 y adaptada en esta metodología. En AGIL-MANTEMA contamos con dos niveles de servicio (ver Tabla 3.1) primero uno básico el cual abarca los mantenimientos del tipo urgente, no urgente y perfectivo cuya interfaces con otros procesos (Operación y
Definición del proceso de Mantenimiento
Registro y Análisis de la
Petición
Ejecución de la Intervención
Migración y retirada del
software
Documentación) no están establecidas en este documento, pero de todas maneras se indica en que tareas del proceso de mantenimiento se debería establecer esta interfaz. Al alcanzar el nivel básico podemos optar por el nivel Avanzado que incluye los mantenimientos de tipo adaptativo y preventivo, en este nivel se incluyen las interfaces con los procesos de Aseguramiento de la Calidad, Gestión de Configuración y Mejora. En las interfaces con los procesos de Aseguramiento de la Calidad y de Gestión de la Configuración se establecen las tareas y el momento en que deben realizarse, esta integración la explicaremos en mayor profundidad en la siguiente sección.
Nivel Básico Nivel Avanzado
Tipos de Mantenimiento
Correctivo Urgente Correctivo No Urgente Perfectivo
Adaptativo Preventivo
Interfaces Operación
Documentación
Gestión de la Configuración Aseguramiento de la Calidad Mejora
Tabla 3.1. Tabla con niveles de servicios disponibles en AGIL-MANTEMA
3.1.1. Integración con otros Procesos.
Tomando como referencia la integración de procesos de MANTEMA y los procesos de la ISO/IEC 12207, esta metodología integra procesos en dos niveles, en el primero llamado nivel básico, solo se menciona como referencia el proceso auxiliar que debería utilizarse en la tarea indicada y el segundo el nivel avanzado, un nivel más profundo donde se indica que tareas se deben realizar de este proceso en el mantenimiento del software.
Se llama integración de procesos, a los procesos que se encuentran establecidos dentro de la organización, generalmente en el ciclo de vida del software y serán ocupados también dentro del proceso de mantenimiento.
Procesos Principales.
o Operación (Nivel Básico): Se define las actividades del operador, que es la organización que provee el servicio de operación o explotación de un sistema informático en su entorno de trabajo real.
Procesos de Soporte.
o Documentación (Nivel Básico): Define las actividades necesarias para almacenar la información generada durante el ciclo de vida.
o Gestión de la Configuración (Nivel Avanzado): Define las actividades de gestión de la configuración.
o Aseguramiento de la Calidad (Nivel Avanzado): Define las actividades para garantizar que los productos y procesos software son conformes a los requisitos especificados y a los planes establecidos.
Procesos Organizacionales.
o Mejora (Nivel Avanzado): Es un proceso para establecer, valorar, medir, controlar y mejorar los procesos del ciclo de vida del software.
3.1.2. Tipos de Mantenimiento en la Metodología.
A continuación se describe los tipos de mantenimiento en AGIL-MANTEMA. Es de suma importancia recordar que gracias a esta división de mantenimientos se logra una mejor optimización del Registro de Peticiones, esta optimización seguirá la secuencia que encontramos a continuación y es la que debería utilizar el Gestor de Peticiones (Rol que se encarga de ordenar las peticiones de modificación) junto con su criterio.
Debemos recordar que los tipos de mantenimiento se dividen en dos niveles el básico, el cual involucra los mantenimientos urgente, no urgente y perfectivo. Una vez alcanzado un cierto nivel de experiencia en el nivel básico podrá optar por el nivel avanzado el cual incluye los mantenimientos adaptativo y preventivo, además de incorporar los procesos de la ISO 12207 (Gestión de la configuración y Aseguramiento de la Calidad).
1) Mantenimiento No Planificable.
a) Correctivo urgente: (Nivel Básico) Es aquel que se da en situaciones en que existe un error en el producto software que bloquea la aplicación o el proceso de funcionamiento de la empresa, que debe ser resuelto con brevedad (por ejemplo, el día veintiocho falla la aplicación de cálculo de nóminas). Estas peticiones deben ser rápidamente atendidas.
2) Mantenimiento Planificable.
a) Correctivo no urgente: (Nivel Básico) Se produce cuando existe un error en el producto software que no es crítico, pero que tal vez impida el funcionamiento de la aplicación o el normal funcionamiento de la empresa en un periodo de tiempo relativamente corto (por ejemplo, el fallo en la aplicación de nóminas se produce el día diez)
b) Perfectivo: (Nivel Básico) Se ocupa de añadir al software en explotación nuevas características o funcionalidades solicitadas por los usuarios.
c) Adaptativo: (Nivel Avanzado) Se aplica cuando el software en explotación va a cambiarse para que continúe funcionado correctamente en un entorno cambiante.
d) Preventivo: (Nivel Avanzado) Es aplicado cuando se desea mejorar las características internas de un producto software para hacerlo, por ejemplo, más fácilmente mantenible.
3.1.3. Participantes en el Proceso de Mantenimiento.
AGIL-MANTEMA define a sus participantes en un modelo basado en roles, esto quiere decir, que cada organización define a un/unos integrante(s) con un conjunto de tareas y responsabilidades para que se desempeñe dentro del proceso de mantenimiento. Estas tareas y responsabilidades las definiremos a continuación.
1) Cliente: Es la organización propietaria, por lo tanto es quien recibe el servicio de mantenimiento.
a) Propietario del Producto: Representa a todos los interesados en el producto final.
Sus áreas de responsabilidad son: La financiación del proyecto, retorno de la inversión del proyecto y el lanzamiento del proyecto.
El propietario del producto por lo general formula peticiones de modificación del tipo perfectivo o adaptativo.
2) Usuario: Es quien utiliza el software.
a) Usuario: Propone las peticiones de modificación, ya sea correctivas, correctivas urgentes o perfectivas.
3) Mantenedor: Es quien realiza la modificación del Software.
a) Gestor de Peticiones: Es quien acepta o rechaza las peticiones de modificación y decide el tipo de mantenimiento que debe aplicarse, en caso de ser perfectivo pone al tanto al propietario del producto para ver la viabilidad del mantenimiento, en caso de ser cualquiera de los otros tipos lo sitúa en la Lista de Espera de Peticiones, según la prioridad de éste.
b) Responsable de Mantenimiento: Responsable del Proceso, prepara la etapa de mantenimiento, y establece las normas y procedimientos necesarios para llevar a cabo la metodología. Es quien interactúa con el cliente y el equipo de trabajo. Es el responsable que se lleven a cabo las practicas, valores y reglas de Scrum, debe ser miembro del equipo de trabajo y trabajar a la par. Coordina los encuentros permanentes, se encarga de eliminar eventuales obstáculos.
c) Equipo de Mantenimiento: Es el grupo de Personas que implementa la solicitud de modificación. Tiene autoridad para reorganizarse y definir las acciones necesarias o sugerir remoción de impedimentos. También puede proponer peticiones de mantenimiento del tipo preventivo.
3.1.4. Descripción del Proceso de Mantenimiento.
El proceso de mantenimiento comienza cuando el mantenedor y el cliente comienzan a trabajar en conjunto, esto quiere decir, asignar responsables, criterios y explicar cómo se va a trabajar, estas tareas se agrupan en la actividad llamada planificación del proceso.
Al pasar esta etapa se inicia el ciclo que cada petición de mantenimiento tendrá que seguir. Primero se formula la petición de mantenimiento, que luego pasará a manos del Gestor de Peticiones el cual se encargara de asignar el tipo y prioridad de la petición. Este grupo ordenado de peticiones se llamará Registro de Peticiones.
Desde este registro se seleccionará un primer grupo de peticiones llamado Lista de Espera de Peticiones, este grupo podrá entrar a dos tipos de Sprint, uno rápido para las peticiones del tipo no planificable y uno más extenso para las del tipo planificable. Dentro del Sprint se realizaran una serie de reuniones con el fin de obtener su estado de avance y posibles problemas que puedan ocurrir dentro de su ejecución.
Cuando la petición ha sido resuelta se finaliza el ciclo del proceso de mantenimiento con las actividades de registro de la intervención y la retirada del software. La finalidad de este conjunto de actividades es la validación y verificación del producto por parte del cliente, el paso del producto a producción, registro de documentos, reuniones de retrospección y en caso de ser necesario aplicar el plan de retirada del software.
Para finalizar el proceso de mantenimiento se cuenta con la actividad final llamada finalización de la externalización, que sirve para una cesión de actividades por parte del mantenedor de forma que no repercuta negativamente en la organización cliente.
Se puede observar que las actividades inicial y final se desarrollarán tan solo una vez y no entorpecerán la agilidad del proceso.
Por otro lado están los dos tipos de sprint que serán un conjunto repetitivo de actividades, esto no quiere decir que los cambios no estén permitidos, por lo contrario son bienvenidos, debido a que existe un feedback rápido con el cliente, junto con una entrega rápida y periódica de las peticiones de mantenimiento.
Teniendo en cuenta estas observaciones, podemos precisar un poco más el concepto de
“proceso de mantenimiento” indicando que está formado por:
1. Un conjunto de actividades destinadas a preparar y planificar las actividades.
2. El conjunto de intervenciones que producen modificaciones sobre el software.
3. Reuniones para medir el estado de avance y resolver problemas dentro de las intervenciones.
4. Un conjunto de actividades que deben realizarse con posterioridad a cada modificación sobre el software.
5. Opcionalmente,
(1) Tareas que incorporen interfaces con los procesos auxiliares de la ISO 12207.
(2) Una actividad que guíe en la finalización de la prestación del servicio de mantenimiento.
Con estas descripciones se genera el proceso de mantenimiento en AGIL-MANTEMA el cual podremos observar en la figura 3.2 y que describiremos en el siguiente punto.
Figura 3.2. Proceso de AGIL-MANTEMA.
Retroalimentación de buenas Prácticas Retroalimentación de buenas Prácticas Actividades Sprint No
Planificable
Análisis del Error
Intervención y Pruebas
Actividades Sprint Planificable
Análisis del Error
Intervención y Pruebas Planificación
del Proceso
Análisis de
la Petición Controles
Finalizar Intervención
Actividades Finales
Retirada
Fin de la Externalización
3.2. Estructura Detallada de la Metodología.
En esta sección dedicamos un epígrafe para cada actividad y tarea del ciclo de vida de AGIL-MANTEMA, entre las que podemos encontrar la planificación del proceso, el análisis de la petición de modificación, el Sprint no Planificable, el Sprint Planificable (dependiendo del tipo de mantenimiento), las actividades y tareas intermedias, y para concluir el ciclo con las actividades y tareas finales, en caso de que fuera necesario se incorporara la finalización de la externalización. Del mismo modo, detallamos las entradas, salidas, personal responsable y técnicas de cada tarea, de manera que determinamos los “qué, cómo, dónde, cuándo y por qué” del proceso.
Muchos de los objetos que las tareas toman como entradas y que producen como salida son documentos, que en el texto aparecerán etiquetados con el prefijo DOC seguido de un número; las plantillas de estos documentos se encuentran recogidas en el Apéndice I.
3.2.1. Planificación del Proceso.
La actividad inicial planificación del proceso solo se ejecuta cuando el cliente contacta con el mantenedor para que realice el proceso de mantenimiento en, esta actividad consta de las siguientes tareas:
Actividad I0. Planificación del Proceso. Esta actividad consta de las siguientes tareas:
Tarea I0.1. Asignar Responsables. Se asignara cada rol, sobre un miembro de la organización a la cual corresponda. Esto quiere decir, que el Gestor de Peticiones, el Responsable de Mantenimiento, el Propietario del Producto y el Equipo se Mantenimiento ya no serán solo palabras sino personas, que podrán ser identificadas con estos nombres.
Tarea I0.2. Adquirir Conocimiento de la Aplicación. Aquí, el Equipo de mantenimiento debe obtener información del software que se va a mantener, esto
quiere decir, estudiar la documentación, código fuente, referencias cruzadas, entrevistarse con los usuarios, observar cómo trabaja la organización Cliente, etc.
Durante el tiempo que dure esta tarea no se realizara ningún tipo de mantenimiento. Al finalizar esta tarea, el Equipo de mantenimiento debe entregar al Cliente un informe acerca del estado de su software, de manera que el cliente verifique que el Equipo de Mantenimiento ha adquirido un conocimiento adecuado del software.
Tarea I0.3. Preparar entornos de pruebas. En esta tarea el Equipo de mantenimiento prepara el entorno de pruebas, esto quiere decir realiza copias del software, preparar base de datos y archivos, que sean semejantes a la realidad y que cubran la totalidad de las funcionalidades del sistema, todo esto para que el software pueda funcionar en un ambiente aislado, para que no afecte la operación normal de los sistemas en uso.
Tarea I0.4. Definir procedimientos de petición de modificación. El Equipo de mantenimiento genera el documento que el usuario presentara para solicitar mantenimiento. Dicho documento será llamado Petición de Modificación (DOC1).
En esta tarea también se establecerá, junto con el cliente, los procedimientos de la Petición de Modificación, a los usuarios se les indicara quien será el receptor de dicha Petición llamado Gestor de Peticiones.
3.2.1.1. Diagrama de Actividades: Planificación del Proceso.
3.2.1.2. Tabla Resumen: Planificación del Proceso.
Planificación del Proceso
Asignar Responsables
Adquirir
Conocimiento de la Aplicación
Preparar Entornos de Prueba
Definir Procedimientos de la Petición de Modificación
Entradas Listado con Posibles responsables
Producto de Software en operación o desarrollo
Elementos Software del sistema en operación
Plan de Mantenimiento
Salidas Listado con responsables
Lista de Elementos Software
Copias de los elementos Software
Documento Petición de Modificación
Procedimientos
Técnicas Estudio de la
Documentación Observación y entrevistas
Instalación de Herramientas
Roles Propietario del Producto Responsable de Mantenimiento
Equipo de mantenimiento Usuarios
Equipo de Mantenimiento
Equipo de mantenimiento Usuario
Interfaces con otros Procesos
Adaptación2 Gestión de la Configuración (GC1)1
Tabla 3.2. Tabla Resumen de Actividad I0. Planificación del Proceso.
1 Interfaz Incorporada en AGIL-MANTEMA.
2 Interfaz No Incorporada en AGIL-MANTEMA.
3.2.2. Actividad Inicial.
Actividad I1. Análisis de la Petición de Modificación.
En esta actividad comienza el ciclo que cada petición de modificación tendrá que seguir, esta actividad consta de las siguientes tareas.
Tarea I1.1. Recibir Petición de Modificación. El usuario entrega una Petición de modificación (DOC1), que es recibida y registrada por el Gestor de Peticiones. Este deberá asignar un identificador único a cada Petición de Modificación.
Tarea I1.2. Decidir el tipo de Mantenimiento. A partir de la Petición de modificación (DOC1) recibida y registrada en la tarea I1.1 el Gestor de Peticiones decide o bien rechazar la petición, o bien aceptarla y decidir el tipo de mantenimiento que debe aplicarse, junto con esto agregarla al Registro de Peticiones en orden de prioridad. En caso de rechazarla, debe justificar las razones.
A continuación, se analiza la relación entre las peticiones que están en el Registro de Peticiones y se decide cuales pueden abordarse en forma conjunta (Lista de Espera).
3.2.2.1. Diagrama de Actividades: Análisis de la Petición de Modificación.
3.2.2.2. Tabla Resumen: Análisis de la Petición de Modificación.
Análisis de la Petición de Modificación
Recibir Petición de Modificación. Decidir el tipo de Mantenimiento
Entradas Petición de Modificación Petición de Modificación Recibida
Salidas Petición de modificación recibida Informe sobre el tipo de mantenimiento, necesario.
Decisión sobre el tipo de mantenimiento a realizar.
Técnicas Grafico de quemado
Tipos de Mantenimiento de AGIL- MANTEMA
Evaluación de Impacto
Roles Gestor de Peticiones Usuario
Gestor de Peticiones
Interface con otros
Procesos
Aseguramiento de la Calidad (AC1)1
Tabla 3.3. Tabla Resumen de Actividad I1. Análisis de la Petición.
1 Interfaz Incorporada en AGIL-MANTEMA.
2 Interfaz No Incorporada en AGIL-MANTEMA.
3.2.3. Actividades y Tareas del Sprint Mantenimiento No Planificable.
Estas actividades se ejecutan cuando el error paraliza de manera seria el funcionamiento normal del resto del sistema de información o el de la organización, de forma que la corrección del error deba ser inminente, se recomienda sprint cortos a lo más 15 días, con reuniones todos los días.
Actividad SNP1. Análisis del error. Esta actividad consta de las siguientes tareas:
Tarea SNPI1.1. Investigar y Analizar Causas. El Equipo de mantenimiento analiza la Petición de Modificación (DOC1), verifica el problema con la colaboración del Usuario que realizo la petición y lo reproduce, estudia diferentes alternativas para implementar la modificación. Además, debe construir una lista de los elementos software a corregir (módulos, rutinas, documentos, etc.).
Actividad SNP2. Intervención correctiva urgente. Esta actividad consta de las siguientes tareas:
Tarea SNP2.1 Realizar acciones correctivas. El equipo de mantenimiento ejecuta las acciones necesarias para corregir el problema detectado. Deben identificarse las rutinas y bases de datos afectadas por la intervención.
Tarea SNP2.2 Ejecutar pruebas unitarias. El Equipo de mantenimiento debe comprobar la corrección de todos los cambios realizados. Estas pruebas se documentarán en el Documento de Pruebas Unitarias Realizadas (DOC2). Esta tarea sirve para comprobar el correcto funcionamiento del modulo al que se le han practicado las acciones correctivas.
3.2.3.1. Diagrama de Actividades: Sprint Mantenimiento No Planificable.
3.2.3.2 Tabla Resumen de Actividades y Tareas del Sprint Mantenimiento No Planificable.
Análisis del Error Intervención Correctiva Urgente
Investigar y Analizar Causas
Realizar Acciones Correctivas
Ejecutar Pruebas Unitarias
Entradas Producto Software en explotación con error bloqueante o Critico Petición de Modificación
Conjunto de elementos Software a corregir
Elementos de Software Corregidos Casos de Prueba
Salidas Conjunto de elementos Software a corregir
Conjunto de elementos software corregidos
Elementos de Software Corregidos y Aprobados
Documento con las pruebas unitarias realizadas
Técnicas Codificación Técnicas de Prueba de Software
Uso de Herramientas como JUnit o SimpleTest
Pruebas de Regresión
Roles Equipo de Mantenimiento Usuario
Equipo de mantenimiento
Equipo de Mantenimiento
Interface con otros Procesos
Aseguramiento de la calidad (AC1)1 Gestión de la Configuración (GC2)1
Aseguramiento de la Calidad (AC2)1 Verificación2
Validación2
Tabla 3.4. Tabla Resumen de Actividades y Tareas del Sprint Mantenimiento No Planificable.
1 Interfaz Incorporada en AGIL-MANTEMA.
2 Interfaz No Incorporada en AGIL-MANTEMA.
3.2.4. Actividades y Tareas del Sprint Mantenimiento Planificable.
El Sprint del mantenimiento planificable se ejecuta cuando estamos hablando de los mantenimientos correctivo no urgente, perfectivo, preventivo y adaptativo. Al ser un sprint con menor urgencia que el anterior se recomienda sprint más largos de 30 días con dos reuniones semanales.
Actividad SP1. Análisis de la petición. Esta actividad consta de las siguientes tareas:
Tarea SP1.1. Analizar y elegir Solución. Si se trata de CP (correctivo no urgente o perfectivo), se documenta la causa del error y se indican las posibles alternativas de implementación en el Documento de Diagnóstico del Error y Posibles Soluciones (DOC3).
Si se trata de P (preventivo) o A (adaptativo), solamente se indican las posibles alternativas de implementación en el Documento de Diagnostico del Error y Posibles Soluciones (DOC3).
Luego de analizar cada una de las posibles soluciones se elige la alternativa de implementación adecuada, se rellena el Documento de Diagnostico del Error y Posibles Soluciones (DOC3), indicando la alternativa de corrección elegida.
Actividad SP2. Intervención y pruebas. Esta actividad consta de las siguientes tareas:
Tarea SP2.1. Ejecutar intervención (CP/P/A). El equipo de mantenimiento debe ejecutar las acciones necesarias para servir la petición de modificación conforme a la alternativa seleccionada, la cual está desarrollada en el documento Diagnostico del Error y Posibles Soluciones (DOC3)
Deben identificarse las rutinas y bases de datos afectadas por la intervención,
