AGIL-MANTEMA
Una propuesta metodológica ágil para el mantenimiento de Software
Índice General
1. Introducción...7
2. Marco Teórico...9
2.1. Scrum...9
2.1.1. Participantes de Scrum...11
2.1.2. El Ciclo de Vida de Scrum...12
2.1.3. Estructura Detallada de Scrum...13
2.2. MANTEMA...17
2.2.1. Estructura general de la Metodología...17
2.2.2. Estructura Detallada de la Metodología...23
2.2.3. Métricas usadas en MANTEMA...33
3. AGIL-MANTEMA...34
3.1. Estructura General de la Metodología...34
3.1.1. Integración de Procesos...35
3.1.2. Tipos de Mantenimiento en la Metodología...36
3.1.3. Participantes en el Proceso de Mantenimiento...37
3.1.4. Ciclo de Vida del Proceso de Mantenimiento...39
3.2. Estructura Detallada de la Metodología...41
3.2.1. Actividades y Tareas Iníciales...41
3.2.2. Actividades y Tareas del Sprint Mantenimiento No Planificable...46
3.2.3. Actividades y Tareas del Sprint Mantenimiento Planificable...48
3.2.4. Actividades y Tareas Intermedias...51
3.2.5. Actividades y Tareas Finales...53
3.3. Diagrama de Actividades de AGIL-MANTEMA...59
3.3.1. Tareas Iníciales de la Actividad Planificación del Proceso...59
3.3.2. Tareas Iníciales de la Actividad Análisis de la Petición de Modificación...59
3.3.3. Tareas del Sprint No Planificable: Análisis del Error e Intervención Correctiva Urgente...60
3.3.4. Tareas del Sprint Planificable: Análisis de la Petición e Intervención y Pruebas No Urgentes...60
3.3.5. Tareas de Controles: Reuniones Habituales y Seguimiento de los Cambios....61
3.3.6. Tareas Finales: Finalización de la Intervención...61
3.3.7. Tareas Finales: Retirada...62
3.3.8. Tareas Finales: Fin de la Externalización...62
3.4. Métrica Propuesta para la ejecución de los Sprint...63
3.4.1. Gráficos de Quemado...63
4. Discusión y Conclusiones...65
Anexo A: Contenido de los Diferentes Documentos...67
Anexo A.1. DOC1 – Petición de la Modificación...67
Anexo A.2. DOC2 – Pruebas Unitarias Realizadas...69
Anexo A.3. DOC3 – Diagnóstico y Posibles soluciones...70
Tareas Auxiliares para Interfaces con otros procesos...71
Aseguramiento de la Calidad...71
Tarea AC1: Revisión del Mantenimiento...72
Tarea AC2: Comprobación de la Existencia del Plan de Pruebas de Regresión...72
Tarea AC3: Revisión de la Realización de las Pruebas de Regresión...72
Gestión de la Configuración...74
Tarea GC1: Implementar proceso de Gestión de Configuración...75
Tarea GC2: Registro del Cambio en el Sistema de Gestión de la Configuración...75
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...76
Tarea GC4: Registro de la Nueva Versión de los Sistemas de Información en el Sistema de Gestión de la Configuración...76 Terminología...77 5. Bibliografía...78
Índice de Figuras.
Figura 3.1. Ciclo de Vida de Scrum...12
Figura 3.2. Ciclo de Carrera de Scrum...14
Figura 3.3. Product Backlog de Scrum...14
Figura 3.4. Sprint Backlog de Scrum...15
Figura 3.5. Macroestructura del Proceso de Mantenimiento de ISO/IEC 12207...17
Figura 3.6. Visión General de los Procesos en la Metodología...18
Figura 3.7. Tipos de Mantenimiento en MANTEMA...19
Figura 3.8. Actividades que componen la Metodología...21
Figura 3.9. Actividades Cíclicas en la Metodología...22
Figura 4.1. Macroestructura del Proceso de Mantenimiento en AGIL-MANTEMA...34
Figura 4.3. Ciclo de Vida de AGIL-MANTEMA...40
Figura 4.4. Ejemplo Gráfico de Quemado...64
Índice de Tablas.
Tabla 4.1. Tabla Resumen de Actividades y Tareas Iníciales (Planificación del Proceso)...44
Tabla 4.2. Tabla Resumen de Actividades y Tareas Iníciales (Análisis de la Petición)...45
Tabla 4.3. Tabla Resumen de Actividades y Tareas del Sprint Mantenimiento No Planificable. ...47
Tabla 4.4. Tabla Resumen de Actividades y Tareas del Sprint Mantenimiento Planificable....50
Tabla 4.5. Tabla Resumen de Actividades y Tareas Intermedias...52
Tabla 4.6. Tabla Resumen de Actividades y Tareas Finales (Finalización de la Intervención) ...56
Tabla 4.7. Tabla Resumen de Actividades y Tareas Finales (Retirada)...57
Tabla 4.8. Tabla Resumen de Actividades y Tareas Finales (Fin de la Externalización)...58
Tabla 6.1. Diferencias entre AGIL-MANTEMA y MANTEMA...60
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 utilizar 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 desarrolladoras de software [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 entre las que encontramos la alta calidad de su servicio y diferenciarse de las demás empresas de su rubro todo esto con el menor coste posible, rapidez y flexibilidad en su proceso de mantenimiento, sin dejar de lado lo que ocurre dentro de la organización, como la comunicación y cooperación entre sus integrantes.
Es por estas razones, que en este trabajo se presenta una metodología para la gestión del proceso de mantenimiento de manera ágil, 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. Varias técnicas, susceptibles de ser empleadas en determinados momentos del proceso.
5. Una métrica para medir el estado de avance del proceso.
2. Marco Teórico.
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 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 corridas (creación de nuevas funcionalidades). No hay una ingeniería del software prescripta 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 management 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:
El 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 o lista de retraso del producto (Product Backlog). Es elegido por el Scrum Master, 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 3.1. Ciclo de Vida de Scrum.
2.1.3. Estructura Detallada de Scrum.
A continuación se mostraran cada una de las fases de Scrum en detalle.
2.1.3.1. Pre-Juego:
2.1.3.1.1. 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.
2.1.3.1.2. 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 “corridas” (Sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum.
2.1.3.2.1. Ciclo de Carrera.
Figura 3.2. Ciclo de Carrera de Scrum.
La lista de Acumulación del Producto (Product Backlog figura 3.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.
Figura 3.3. Product Backlog de Scrum.
La lista de acumulación de corrida sugerida tiene este formato:
Figura 3.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 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, Scrum Manager y el propietario del producto con todas las personas implicadas en el proyecto. Su finalidad es presentar al propietario del producto y a las gallinas 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 Scrum Master, y opcionalmente el Propietario del Producto. Se pregunta: ¿Qué cosas fueron bien en el último sprint? y ¿Qué cosas se podrían mejorar?, el Scrum Manager anota todas las respuestas, el equipo prioriza las mejoras posibles, el Scrum Manager 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 3.5. Tal estructura fue elegida como punto de partida para esta metodología.
Figura 3.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 3.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 3.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 3.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 3.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 3.8.
[POL1999].
Figura 3.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 3.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 3.9, entre las mencionadas en el punto anterior.
Figura 3.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 4.1 explicaremos como se obtuvo una estructura básica válida 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 algunos de los procesos del ciclo de vida en 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 4.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. Luego en la sección 4.3 definiremos las interfaces con los procesos auxiliares Gestión de la Configuración y Aseguramiento de la Calidad. Para finalizar en el 4.4 se mostrara una métrica para el proceso de mantenimiento.
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 4.1. Macroestructura del Proceso de Mantenimiento en AGIL-MANTEMA.
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
3.1.1. Integración de Procesos.
Tomando como referencia la integración de procesos de MANTEMA y los procesos de la ISO/IEC 12207, en nuestra metodología integramos procesos en dos niveles, en el primero, solo se menciona como referencia el proceso auxiliar que debería utilizarse en la tarea indicada y el segundo nivel, un nivel más profundo donde se indica que tareas se deben realizar de este proceso en el mantenimiento del software.
A lo que integración de procesos se refiere, son 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 mantenimiento.
Procesos Principales.
o Operación (NIVEL 1): 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 1): Define las actividades necesarias para almacenar la información generada durante el ciclo de vida.
o Gestión de la Configuración (NIVEL 2): Define las actividades de gestión de la configuración.
o Aseguramiento de la Calidad (NIVEL 2): 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 1): 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 Product Backlog (Conjunto de peticiones ordenadas por prioridad), 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.
También contamos con dos niveles de servicio de mantenimiento uno básico que constara de los mantenimientos urgente, no urgente y perfectivo, ya que estos mantenimientos siempre están presentes en la organización y que son indispensables para un óptimo funcionamiento dentro de esta. Una vez alcanzado un cierto nivel de experiencia en el nivel básico se podrá optar por el nivel avanzado el cual tendrá los mantenimientos adaptativo y preventivo, además de incorporar los procesos auxiliares de la ISO 12207(Gestión de la configuración y Aseguramiento de la Calidad).
1) Mantenimiento No Planificable.
a) Correctivo urgente: 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: 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: Se ocupa de añadir al software en explotación nuevas características o funcionalidades solicitadas por los usuarios.
c) Adaptativo: Se aplica cuando el software en explotación va a cambiarse para que continúe funcionado correctamente en un entorno cambiante.
d) Preventivo: 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.
Dado que AGIL-MANTEMA está pensado para la pequeña y mediana empresa, se piensa que los roles aquí presentes formaran todos partes de la misma organización. De todas maneras se propone tratar como dos organizaciones distintas, estas organizaciones serian el cliente y la organización de mantenimiento.
1) Cliente: Seria la organización propietaria y que utiliza el software, 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.
b) Usuario: Es quien utiliza el software y propone las peticiones de modificación.
2) Organización del Mantenimiento: 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 pone en la cola de peticiones aceptadas o Sprint Backlog, 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.
3.1.4. Ciclo de Vida del Proceso de Mantenimiento.
El proceso de mantenimiento comienza cuando la organización de mantenimiento y la organización cliente comienzan a trabajar en conjunto, esto quiere decir, asignar responsables, criterios y explicar cómo se va a trabajar, estas son las denominadas tareas iníciales.
Al pasar esta etapa se inicia la secuencia que cada petición de mantenimiento tendrá que seguir, primero será la formulación de la petición de mantenimiento por parte de los usuarios, que luego pasará a manos del Gestor de Peticiones el cual se encargara de decir su tipo y prioridad, este grupo ordenado de peticiones se llamará Product Backlog.
Desde el Product Backlog se seleccionará un primer grupo de peticiones llamado Sprint Backlog 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 desarrollarán las actividades y tareas finales que recogerán las mejores prácticas del Sprint, se tratarán posibles modificaciones en el Product Backlog y se registraran las intervenciones. También se analizará el cese del mantenimiento por la organización que lo provee, dando lugar a otra organización que como ya hemos mencionado puede ser parte de la organización cliente.
Se pueden observar que algunas actividades iníciales y finales se desarrollarán tan solo una vez y no entorpecerán la agilidad del proceso, como por ejemplo las tareas de planificación del proceso dentro de las actividades iníciales, y las tareas de retirada y finalización de la intervención en las actividades finales.
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, 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 Ciclo de vida de AGIL-MANTEMA el cual podremos observar en la figura 4.3 y que describiremos en el siguiente punto.
Figura 4.2. Ciclo de Vida de AGIL-MANTEMA.
Retroalimentación de buenas Prácticas Retroalimentación de buenas Prácticas
Actividades Iníciales
Planificación del Proceso
Análisis de la Petición
Actividades Finales
Finalizar Intervención
Retirada Fin de la Externalización
Actividades Sprint No Planificable
Análisis del Error
Intervención y Pruebas
Actividades Sprint Planificable
Análisis del Error
Intervención y Pruebas
Actividades IntermediasControles
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 4 grandes grupos, las actividades y tareas iníciales, el Sprint no Planificable, el Sprint Planificable (dependiendo del tipo de mantenimiento), las actividades y tareas intermedias, y para concluir con las actividades y tareas finales. 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. Actividades y Tareas Iníciales.
Las actividades y Tareas iníciales comienzan con la planificación del proceso de mantenimiento, entre sus tareas podemos encontrar: Asignar responsables, Adquirir conocimiento de la Aplicación, etc. Y continua con el análisis de la petición en donde comienza el ciclo que recorrerá cada petición de modificación, tiene dos tareas recibir y determinar el tipo de mantenimiento de la petición en cuestión.
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.
Actividad I1. Análisis de la Petición de Modificación. 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 Product Backlog 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 Product Backlog y se decide cuales pueden abordarse en forma conjunta (Sprint Backlog).
3.2.1.1 Tablas Resumen: Actividades y Tareas Iníciales.
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 4.1. Tabla Resumen de Actividades y Tareas Iníciales (Planificación del Proceso)
1 Interfaz Incorporada en AGIL-MANTEMA.
2 Interfaz No Incorporada en AGIL-MANTEMA.
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 Configuración de software
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 4.2. Tabla Resumen de Actividades y Tareas Iníciales (Análisis de la Petición)
1 Interfaz Incorporada en AGIL-MANTEMA.
2 Interfaz No Incorporada en AGIL-MANTEMA.
3.2.2. Actividades y Tareas del Sprint Mantenimiento No Planificable.
Estas actividades se ejecutan cuando La petición 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.
Ejecutar pruebas de regresión
3.2.2.1 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 4.3. 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.3. Actividades y Tareas del Sprint Mantenimiento Planificable.
El Sprint del mantenimiento planificable se ejecuta cuando la petición 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,
Tarea SP2.2. Ejecutar pruebas unitarias y de Integración (CP/P/A). El Equipo de mantenimiento realiza las pruebas unitarias y de integración sobre el producto software intervenido. Debe comprobarse que la Petición de Modificación (DOC1) queda servida y de que los diferentes elementos software funcionan correctamente en forma conjunta. Una vez finalizadas, se genera el Documento de Pruebas Unitarias Realizadas (DOC2).
La idea es probar el correcto funcionamiento del software tanto en módulos como el correcto funcionamiento con el resto del sistema o subsistema.
Tarea SP2.3. Ejecutar Paralelamente el software Antiguo y Nuevo. 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 no se repitan errores anterior a la intervención. ¿????????
