Mantenimiento Sistemas de Información

PRACTICA DE FUNDAMENTOS DE INGENIERÍA DEL SOFTWARE

CURSO: 2009-10

GRUPO 1.5

Luis Villazón Esteban

TEMA: Mantenimiento de Sistemas de Información.

Esta obra está bajo una licencia Reconocimiento-No comercial 3.0 España de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/bync/3.0/es/ o envie una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

2

Índice 1.

Desarrollo Conceptual ....................................................................................................... 4

2.

Desarrollo Metodológico ................................................................................................... 8

3.

Aportaciones Personales ................................................................................................. 22

4.

Bibliografía ...................................................................................................................... 27

5.

Presentación ................................................................................................................... 28

3

1. Desarrollo Conceptual

Índice Conceptual 1. Definiciones Inherentes al Mantenimiento 2. Tipos de Mantenimiento 3. Costes del Mantenimiento 4. Factores del Mantenimiento 5. Reingeniería 6. Ingeniería Inversa

Definiciones inherentes al Mantenimiento Mantenimiento: Llamamos mantenimiento a las modificaciones que se realizan en el producto software después de la entrega al usuario. Estas modificaciones podrán ser realizadas para mejorar el rendimiento, corregir defectos, adaptar el producto software a un nuevo de entorno, software o hardware, u otras propiedades deseables en el producto. Barrera de Mantenimiento: Se define como el porcentaje máximo o límite de los recursos que son necesarios para el mantenimiento del software. El llegar a la barrera de mantenimiento imposibilitaría la realización de nuevos desarrollos. Actividades de Mantenimiento: También llamadas Proceso de Mantenimiento, son cada una de las actividades que se deben realizar en el proceso del mantenimiento, estas actividades serán: Gestión de peticiones, comprensión del software y de los cambios que se deben realizar sobre el mismo, modificación del software (modificando código y actualizando documentación) y realización de pruebas.

4

Tipos de Mantenimiento Correctivo: Se trata del mantenimiento que se realiza a cabo para corregir los errores detectados durante la explotación del sistema. Perceptivo (evolutivo): Se trata del mantenimiento que se realiza para mejorar o añadir alguna característica nueva al programa. Es el mantenimiento que mayor coste supone (hasta un 60% relativo respecto al resto de mantenimientos). Adaptativo: Se trata del mantenimiento llevado a cabo para adaptar el sistema a un nuevo entorno tecnológico (software, hardware, etc.). Preventivo/ perfectivo (reingeniería): Se trata del mantenimiento que se realiza para prevenir futuros problemas o para facilitar el mantenimiento futuro del sistema.

Costes del Mantenimiento Definición: Los costes del Mantenimiento se refieren a los costes tanto en tiempo como dinero y recursos de la empresa que son utilizados para la realización del proceso de mantenimiento. Puede suponer hasta el 80%-90% del coste total del ciclo de vida del Software. Existen dos tipos, Directos e Indirectos. Directos: Son los costes referidos a las actividades de Mantenimiento enumeradas anteriormente. La comprensión del software y los cambios a realizar en el mismo suponen prácticamente el 50% del coste y las pruebas un 28%. Indirectos: Son los costes ajenos a la realización del mantenimiento y no involucrados directamente en el ciclo de vida del Software, entre los cuales se pueden encontrar los siguientes: Costes de Mantenimiento Indirectos (Insatisfacción del Cliente): Se refiere a la imposibilidad de realizar en un tiempo razonable una petición de mantenimiento. Costes de Mantenimiento Indirectos (Deterioro del Software): Al modificar el software en el proceso de mantenimiento se puede producir una disminución de la calidad y aparición de nuevos errores en el software. Costes de Mantenimiento Indirectos (Perdida de Oportunidades): Al utilizar demasiados recursos en el proceso de mantenimiento es posible que se dejen de realizar nuevos desarrollos al carecer de los recursos necesarios.

5

Factores del Mantenimiento Definición: Se tratan de factores que dificultan el mantenimiento del software, entre los cuales se encuentran: Código Heredado: Código antiguo, el cual la mayoría fue construido para ocupar poco espacio, sin importar la eficiencia, diseño y mantenimiento del mismo. A su vez el código se encuentra muy deteriorado lo que aumenta el coste y la dificultad de su mantenimiento. Evolución del Software: El software va sufriendo cambios a lo largo del tiempo, lo que disminuye su calidad y lo hace menos eficiente, aumentando su complejidad y deteriorándolo. Si tampoco se ha llevado un control de la documentación su mantenimiento se vuelve más costoso. Ausencia de herramientas: No se utilizan herramientas, métodos ni técnicas que faciliten la realización del mantenimiento. Por lo tanto la mayoría de las veces el mantenimiento se realiza Ad-hoc.

Reingeniería Definición: Alternativa al mantenimiento. Modificación del producto software o componentes del mismo para mejorar su mantenimiento futuro. La reingeniería del software se compone de los siguientes pasos: Análisis de inventarios: Lista con información de las aplicaciones candidatas a la reingeniería, ordenadas para conocer cual son las mejores candidatas para la misma. Restructuración de documentos: Realizar la documentación necesaria para llegar comprender el sistema y hacer que el software sea más fácil de entender y cambiar. También se puede definir como una representación funcionalmente equivalente dentro de un mismo nivel de abstracción. Ingeniería inversa: Es el proceso de analizar un programa con la finalidad de conocer su comportamiento. De esta forma se logra una representación del programa con una mayor abstracción que la ofrecida por el código fuente y proporciona información del diseño y la arquitectura del programa. Ingeniería directa: También llamada renovación, consiste en utilizar los principios, métodos y conceptos de la ingeniería del software para volver a implementar la aplicación. 6

Herramientas CASE: Se tratan de Aplicaciones destinadas a facilitar y aumentar la productividad en el desarrollo Software. Uno de los objetivos de la Reingeniería es capturar información en un repositorio que será utilizado posteriormente por estas herramientas. Migración: Consiste en trasladar la aplicación de un sistema a otro nuevo en condiciones de compatibilidad. La reingeniería facilita esta acción. Esperanza de vida: Es el tiempo que la aplicación puede estar funcionando sin presentar inconvenientes graves. La reingeniería permite aumentar la esperanza de vida de la aplicación. Prototipo de Software: Versión inicial de una aplicación Software la cual se va refinando a través de diferentes versiones. Aumenta la productividad al utilizarse Ingeniería Directa.

Ingeniería inversa Extracción de Abstracciones: Extracción a partir del código fuente una documentación significativa del proceso que se realiza, así como de la interfaz de usuario y de las estructuras de datos que se utilizan. Completitud: Se refiere al nivel de detalle que se obtiene, a medida que aumenta el nivel de abstracción la completitud disminuye. Interactividad: Se refiere al grado con el cual las personas se integran con las herramientas de ingeniería inversa, para de este modo crear un proceso más efectivo. A medida que crece la abstracción hay que aumentar la interactividad. Direccionalidad Monodireccional: toda la documentación extraída del código fuente se utilizará para facilitar la actividad de mantenimiento. Direccionalidad Bidireccional: documentación obtenida del código fuente se utiliza adicionalmente para el proceso de ingeniería directa.

7

2. Desarrollo Metodológico Previo Para la realización del desarrollo metodológico se ha decido utilizar el modelo unificado como modelo de procesos, por lo tanto se va a utilizar un enfoque orientado a objetos, pues este modelo de procesos nos obliga a ello. A su vez, dentro del modelo de procesos se incluye la utilización de prototipos como una actividad del modelo. Para la realización del desarrollo se ha realizado un Estudio de Viabilidad del Sistema, y se ha decidido realizar un desarrollo a medida, no utilizando por ello otros tipos de desarrollo como el desarrollo por componentes. Debido a que el mantenimiento depende de actividades previas del ciclo de vida, se tendrá en cuenta aquellas actividades realizadas que condicionan el desarrollo de la actividad propuesta, en este caso estas actividades son “Preparación del mantenimiento del Sistema” y “Establecimiento del acuerdo de nivel de Servicio” , ambas pertenecientes al proceso de Implantación y Aceptación del Sistema. Los tipos de mantenimiento que se van a realizar en el desarrollo metodológico van a ser el mantenimiento correctivo y el perfectivo o evolutivo, ya que ambos se encuentran estrechamente relacionados. Los mantenimientos adaptativo y preventivo se dejan fuera de este desarrollo debido a que quedan fuera del alcance del mismo y no son contemplados en el proceso

de

Mantenimiento

de

Sistemas

Inventario de Actividades y Tareas Actividad MSI 1: Registro de la Petición

Tarea MSI 1.1

Registro de la Petición.

MSI 1.2

Asignación de la Petición.

8

de

Información

de

Métrica

v3.

Actividad MSI 2: Análisis de la Petición.

Tarea MSI 2.1

Verificación y Estudio de la Petición.

MSI 2.2

Estudio de la Propuesta de la Solución.

Actividad MSI 3: Preparación de la Implementación de la Modificación.

Tarea MSI 3.1

Identificación de Elementos Afectados.

MSI 3.2

Establecimiento del Plan de Acción.

MSI 3.3

Especificación del Plan de Pruebas de Regresión.

Actividad MSI 4: Seguimiento y Evaluación de los Cambios hasta la Aceptación.

Tarea MSI 4.1

Seguimiento de los Cambios.

MSI 4.2

Realización de las Pruebas de Regresión.

MSI 4.3

Aprobación y Cierre de la Petición.

Diagrama de Actividades

Desarrollo de la Actividad Para la realización de este apartado se ha decidido desarrollar la actividad 2 del Mantenimiento de Sistemas de Información (MSI): Análisis de la petición. Descripción de la Actividad: productos de entrada, descripción de la actividad, productos de salida, técnica y participante En esta actividad, como su propio nombre indica, se llevará a cabo un análisis de la petición y un diagnóstico de la misma para dar una respuesta sobre la decisión tomada en la misma, es decir, si la petición ha sido aceptada, o rechazada.

9

En caso de que la actividad haya sido aceptada se llevará a cabo un análisis del alcance que tiene la petición, estimando cual sería el alcance de la misma en el ciclo de vida de la aplicación, llegando el caso de estudiar la necesidad de desviar la petición a un nuevo proceso, en este caso Viabilidad del Sistema (EVS) o Análisis de Información (ASI). Por último el enfoque sobre el que se realiza esta actividad, se verá afectada por el tipo de mantenimiento que se va a realizar, siendo diferente el enfoque que se realiza sobre un tipo de mantenimiento correctivo que sobre un mantenimiento evolutivo. Productos de Entrada  Plan de Mantenimiento (IAS 7.2). 

Acuerdo de Nivel de Servicio (IAS 8.3).



Catálogo de Peticiones (MSI 1.2).



Resultado del Estudio de la Petición (MSI 2.1).

Productos de Salida  Catálogo de Peticiones o

Verificación de la Petición.

o

Estudio del Impacto.

o

Aceptación / Rechazo de la Petición.



Resultado del Estudio de la Petición.



Propuesta de la Solución.

Técnicas y Prácticas  Sesiones de Trabajo. 

Catalogación.

Participantes  Responsable de Mantenimiento. 

Equipo de Mantenimiento.

Inventario de Tareas de la Actividad Seleccionada Verificación y Estudio de la petición Antes de iniciar el estudio de la petición, se verifica que la información registrada es correcta. Para determinar su validez: 10

o

Si se trata de un mantenimiento correctivo, se debe reproducir el problema.

o

En el caso de un mantenimiento evolutivo, hay que comprobar que la petición es razonable o factible.

Una vez examinada la petición comienza su estudio, que será diferente en función del tipo de mantenimiento establecido: o

Si se trata de una petición de mantenimiento correctivo, y según el acuerdo de nivel de servicio establecido para los sistemas de información afectados, se evalúa hasta qué punto es crítico el problema. Así es posible determinar si la solución es a corto plazo, es decir, urgente o inmediata, o si es a medio o a largo plazo: 

Si el problema es crítico, su análisis y solución comienza inmediatamente con el fin de reanudar rápidamente el nivel de servicio. Sin embargo, este modo de actuación no elimina la necesidad de una revisión posterior del problema para valorar los posibles efectos secundarios, establecer una solución definitiva y actualizar todos los productos implicados.



Si no es crítico, la petición se clasifica para proceder en la tarea siguiente a determinar cuál es la solución más adecuada.

o

En el caso de un mantenimiento evolutivo se delimita su alcance determinando si se trata de una modificación a los sistemas de información inicialmente afectados o de una incorporación para cubrir nuevas funcionalidades no contempladas hasta el momento en dichos sistemas de información.

Estudio de la Propuesta de Solución A partir del catálogo de peticiones, y para cada una de ellas, se estima su alcance valorando la prioridad inicialmente asignada, de acuerdo a los requisitos planteados. A continuación, se analiza la relación entre peticiones. Se decide cuáles pueden abordarse de forma conjunta asignando, si procede, una prioridad global a los grupos identificados y determinando en qué secuencia deben implementarse los cambios. 11

Asimismo, es necesario concretar los requisitos solicitados para cada petición y analizar con más detalle los sistemas de información implicados, valorando las características de mantenimiento de los mismos y la cantidad de cambios sufridos desde su puesta en producción. También se debe comprobar la existencia de otras peticiones en curso que afecten a los mismos sistemas de información, evaluando la repercusión que puede tener la realización de la petición de mantenimiento sobre estos cambios o desarrollos y analizar su convivencia. Además, se analiza el impacto que la modificación puede provocar en el entorno tecnológico y en los niveles de servicio inicialmente acordados para cada uno de los sistemas de información, valorando hasta qué punto pueden verse comprometidos. En el caso de una petición de mantenimiento evolutivo, se estudia cómo atenderla teniendo en cuenta la política de versiones vigente en ese momento. Si se trata de una incorporación o eliminación, se determina la necesidad de llevar a cabo algunas actividades del proceso Análisis del Sistema de Información de modo previo a la identificación de los elementos afectados. Igualmente, se puede tomar la decisión de abordar el proceso Estudio de Viabilidad del Sistema atendiendo a los requisitos a cubrir, al alcance de la modificación, a las implicaciones en el entorno tecnológico, y al ciclo de vida estimado para los sistemas de información afectados, así como a la existencia de opciones de mercado más idóneas. En el caso de peticiones de mantenimiento correctivo que hayan precisado de una solución de emergencia, no se darán por cerradas hasta que, o bien se compruebe que con dicha solución el sistema no se ha visto comprometido ni tampoco otros sistemas relacionados con él, o bien que después de haber aplicado una solución a corto/medio plazo y realizadas las pruebas pertinentes, el sistema conserva su integridad y operatividad. Por tanto, una vez que se ha reanudado el servicio, hay que realizar las restantes actividades para detectar el origen del problema y asegurar que los cambios introducidos no generan otros de mayor envergadura o comprometen el correcto funcionamiento de otros sistemas de información relacionados. En cualquiera de las situaciones anteriores, se hace una estimación preliminar del esfuerzo requerido mediante los indicadores establecidos en el acuerdo de nivel de servicio para cada sistema de información, según la tecnología aplicada, naturaleza y tamaño del sistema de información y los tipos de lenguajes utilizados, bases de datos, etc. 12

Por último, si se considera necesario, hay que proponer alternativas de solución para dar respuesta de forma satisfactoria a los requisitos planteados o problemas detectados, determinando una fecha límite de implantación y un coste aproximado en función de la estimación realizada anteriormente. Se elige, junto con el usuario, la solución más adecuada, y se obtiene la aprobación o rechazo de la petición. En caso de rechazo, la petición se da por cerrada en el catálogo.

Desarrollo de todas y cada una de las tareas: productos de entrada, descripción de la tarea, productos de salida, técnica y participante Registro de la Petición (MSI 1.1) Descripción Los responsables de mantenimiento recogen las peticiones de los usuarios, siendo estas peticiones fuente de problemas o de posibles mejoras en el sistema de información. En esta tarea se lleva a cabo la creación de un catálogo donde se realiza una descripción detallada de todas las peticiones realizadas por el usuario. Este catálogo será la base para el posterior análisis de la petición, así como de las modificaciones que se lleven a cabo sobre el sistema de información. Productos de Entrada  Petición de mantenimiento (externo, realizado por el usuario). Productos de Salida  Catálogo de peticiones Técnicas y Prácticas  Catalogación. Participantes  Responsable de mantenimiento.

13

Asignación de la Petición (MSI 1.2) Descripción En esta tarea se decide si se acepta, o no, la petición de mantenimiento, para ello se lleva un estudio sobre las peticiones anotadas en el catalogo de peticiones. En este estudio se determinará el tipo de mantenimiento requerido por la petición, así como comprobar si el tipo de mantenimiento necesario ha sido definido en el Plan de mantenimiento y un estudio de todos los sistemas de información que se verían afectados por la petición. En caso de que la petición haya sido aceptada, se determinará quién será el encargado de atender la solicitud para estudios posteriores. Productos de Entrada  Plan de mantenimiento (IAS 7.2).  Catalogo de peticiones (MSI 1.1). Productos de Salida  Catálogo de peticiones  Aceptación/Rechazo de la petición.  Asignación de Responsable. Técnicas y Prácticas  Catalogación. Participantes  Responsable de mantenimiento.

Verificación y estudio de la petición (MSI 2.1) Descripción En esta tarea se lleva a cabo la verificación de la petición, para ello según el tipo de mantenimiento a realizar se realizará, o bien una reproducción del problema en caso de un mantenimiento correctivo, o una comprobación de lo razonable y factible que puede llegar a ser el cambio a realizar en el mantenimiento evolutivo. 14

Una vez realizada la verificación se procede a realizar el estudio de la petición. En este punto si se lleva a cabo un mantenimiento correctivo se llevará a cabo un estudio sobre el nivel crítico de la petición y tomar las medidas oportunas en virtud del mismo. En caso de tratarse de un mantenimiento evolutivo, se realizará un estudio para comprobar el alcance que la modificación, determinando si se trata de una modificación de un sistema ya creado o una nueva funcionalidad que se desea añadir al sistema. Productos de Entrada  Catálogo de peticiones (MSI 1.2).  Acuerdo de nivel de servicio (IAS 8.3). Productos de Salida  Catálogo de peticiones:  Verificación de la petición.  Resultado del estudio de la petición. Técnicas y prácticas  Sesiones de trabajo.  Catalogación. Participantes  Equipo de mantenimiento.

Estudio de la Propuesta de Solución (MSI 2.2) Descripción En esta tarea se lleva a cabo una estimación de la prioridad de cada una de las peticiones teniendo en cuenta los requisitos planteados, se realiza un análisis de los mismos y se comprueba si algunos de ellos se pueden agrupar para abordarlos de forma conjunta, asignándoles una prioridad y el orden de implantación de los mismos. En esta tarea también se lleva a cabo una validación de las características del mantenimiento , la concreción de los requisitos solicitados por la petición y la comprobación de la existencia de otras peticiones que afecten a los mismos sistemas que la petición que se encuentra en estudio, una valoración de los sistemas que se podrían ver comprometidos por la modificación 15

, una estimación preliminar de los esfuerzos que se llevarían a cabo para la labor de mantenimiento y la propuesta de soluciones alternativas que cumplan con los requisitos solicitados por la petición. Productos de Entrada  Plan de Mantenimiento (IAS 7.2).  Acuerdo de nivel de servicio (IAS 8.3).  Catálogo de peticiones (MSI 2.1).  Resultado del estudio de petición (MSI 2.1). Productos de Salida  Propuesta de Solución.  Catálogo de Peticiones:  Estudio de impacto.  Aceptación / Rechazo de la petición. Técnicas y prácticas  Sesiones de trabajo.  Catalogación. Participantes  Responsable de Mantenimiento.  Equipo de Mantenimiento.

Identificación de elementos afectados (MSI 3.1) Descripción En esta tarea se llevará a cabo un análisis detallado de la petición, para de esta forma conocer el alcance y el número de sistemas afectados por la misma. Gracias a este paso se puede realizar una planificación y secuencia de los pasos a llevar a cabo para el desarrollo de los cambios. Una vez realizado el análisis se tendrán reflejados los elementos implicados en la modificación y una asociación entre los elementos de la petición así como referencias cruzadas de los mismos. 16

Uno de los motivos de reflejar las referencias cruzadas de los elementos implicados es facilitar la labor de la tarea de Especificación del Plan de Pruebas de Regresión, indicando de esta forma todas las referencias que tiene la modificación a realizar con diferentes módulos del sistema y que pueden dar lugar a efectos no deseados en estos. Productos de Entrada  Catálogo de Peticiones (MSI 2.2).  Propuesta de Solución (MSI 2.2).

Productos de Salida  Catálogo de peticiones:  Elementos Afectados.  Análisis de Impacto de los Cambios. Técnicas y Prácticas  Catalogación.  Análisis de Impacto.

Participantes  Equipo de Mantenimiento.  Jefe de Proyecto.

Establecimiento del Plan de Acción (MSI 3.2) Descripción En esta tarea se lleva a cabo la identificación de las actividades y tareas a realizar en el modelo de procesos de la aplicación, es decir: Estudio de Viabilidad, Análisis del Sistema de Información, Diseño del Sistema de Información, Construcción del Sistema de Información e Implantación y Aceptación del Sistema de Información, así como la complejidad y el alcance de los cambios. Una vez delimitado el plan de acción se establecerá un Plan de Trabajo determinando los plazos, costes, equipo de trabajo, esfuerzo, etc..., requeridos para el plan de trabajo. Finalmente se realizan unos puntos de control para llevar un seguimiento del plan de trabajo.

17

Productos de Entrada  Plan de Mantenimiento (IAS 7.2).  Propuesta de Solución (MSI 2.2).  Análisis de Impacto de los Cambios (MSI 3.1).  Catálogo de Peticiones (MSI 3.1).

Productos de Salida  Catálogo de peticiones.  Actividades y tareas de los procesos de Desarrollo a Realizar.  Plan de Acción de la modificación. Técnicas y Prácticas  Planificación.  Catalogación.

Participantes  Responsable de Mantenimiento.  Equipo de Mantenimiento.  Jefe de Proyecto.

Especificación del Plan de Prueba de Regresión (MSI 3.3) Descripción En esta tarea se intenta evitar que modificaciones en una parte del sistema tengan efectos contraproducentes (comportamientos no deseados o errores adicionales) en otras partes del sistema que no han sido modificadas, asegurando de esta forma que la nueva versión satisface todas las necesidades planteadas. Productos de Entrada  Propuesta de la Solución (MSI 2.2).  Análisis del Impacto de los Cambios (MSI 3.1).  Catálogo de Peticiones (MSI 3.2).

18

Productos de Salida  Plan de Pruebas de Regresión.

Participantes  Equipo de Mantenimiento.  Jefe de Proyecto.

Seguimiento de los Cambios (MSI 4.1) Descripción En esta tarea se realiza un seguimiento del plan de acción creado en la tarea "Establecimiento del plan de Acción", siguiendo los puntos de control creados en dicha tarea. A su vez, se realiza un seguimiento de cada una de las actividades involucradas en el modelo de procesos identificadas anteriormente en la actividad de "Preparación de la Implementación de la Modificación". Otro paso en la realización de la tarea es el control de la planificación establecida, realizando: Una traza de los cambios realizados, validación de los cambios realizados así como la realización de test unitarios de integridad y de sistema, comprobar que solo se ha modificado lo establecido, etc. Productos de Entrada  Producto Software en Desarrollo (externo, procedente de los procesos de desarrollo).  Análisis de Impacto de los Cambios (MSI 3.1).  Plan de Acción para la Modificación (MSI 3.2).

Productos de Salida  Evaluación del Cambio.

Participantes  Equipo de Mantenimiento.  Responsable de Mantenimiento.  Jefe de Proyecto.

19

Realización de las pruebas de Regresión (MSI 4.2) Descripción En esta tarea se realizan pruebas de regresión para asegurar que los cambios realizados en el mantenimiento no han afectado el funcionamiento de otras partes del sistema. En caso de que hubiesen afectado a otras partes del sistema se recogerán las incidencias y se tomarán las medidas oportunas, en caso contrario se genera un informe con los resultados globales y la aceptación de las pruebas. Productos de Entrada  Plan de Pruebas de Regresión (MSI 3.3).  Producto Software en Desarrollo (externo).

Productos de Salida  Resultado de las pruebas de Regresión.  Evaluación del Resultado de las pruebas de Regresión.

Técnicas y Prácticas  Pruebas de Regresión.

Participantes  Responsable de Mantenimiento.  Equipo de Mantenimiento.  Jefe de Proyecto.

Aprobación y Cierre de la Petición (MSI 4.3) Descripción En esta tarea se realiza el cierre formar de la petición de mantenimiento y la actualización del catalogo de peticiones. En esta tarea también es importante registrar datos cuantitativos como el tiempo empleado en el análisis de la petición, estudio del impacto, resolución del cambio, recursos utilizados, etc., para de esta forma tener una base cualitativa sobre la que tomar decisiones relativas a la eficacia de las técnicas y procedimientos de mantenimiento utilizados. 20

Productos de Entrada  Catálogo de Peticiones (MSI 3.2).  Plan de Pruebas de Regresión (MSI 3.3).  Evaluación del Cambio (MSI 4.1).  Evaluación del Resultado de las pruebas de Regresión (MSI 4.2).

Productos de Salida  Catálogo de Peticiones.  Nueva Versión y Aprobación.

Técnicas y Prácticas  Catalogación.

Participantes  Directores de los Usuarios.  Responsable de Mantenimiento.

21

3. Aportaciones Personales Aportaciones personales en el apartado desarrollo conceptual En el desarrollo conceptual se ha decidido realizar los subapartados descritos por las siguientes razones: Definiciones inherentes al mantenimiento Existen algunas definiciones que son comunes para todo tipo de mantenimiento, como puede ser las actividades de mantenimiento, o proceso de mantenimiento. A su vez se han añadido algunas definiciones sin las cuales sería imposible dar una definición de alguna de las posteriores definiciones enumeradas en el desarrollo conceptual. Por ejemplo, no se podría dar una definición de mantenimiento correctivo ni de reingeniería sin antes conocer la definición mantenimiento. Tipos de Mantenimiento No existe un único tipo de mantenimiento. Según las necesidades extraídas en el proceso de mantenimiento será necesario realizar un tipo de mantenimiento u otro diferente, siendo cada uno independiente del resto. Por ejemplo, si existe un problema con una funcionalidad de la aplicación, será necesario realizar un Mantenimiento Correctivo, y si se desea añadir una nueva funcionalidad, se realizará un Mantenimiento Evolutivo. Costes del Mantenimiento Debido al gran coste, tanto en recursos como en tiempo, que conlleva el mantenimiento, se ha realizado un subapartado donde se expone una definición de “Costes de Mantenimiento” y de los tipos que existen del mismo. A su vez, dado que existen unos costes indirectos, se ha realizado una lista con un subconjuto de los costes indirectos más comunes que afectan al mantenimiento, como puede ser el deterioro del software y la pérdida de oportunidades debidas a invertir demasiados recursos en el mantenimiento y no disponer de suficientes recursos para el resto de proyectos. Factores de Mantenimiento Este subapartado se define justo a continuación de “Costes de Mantenimiento”, la razón para ello es que estos son uno de los causantes de los costes de mantenimiento directos definidos anteriormente. Se ha realizado una enumeración y definición de los tres factores más importantes que influyen en el mantenimiento, los cuales han sido seleccionados por los siguientes motivos:

22

 Código Heredado: La mayoría del código que se utiliza hoy en día tiene una gran antigüedad y no fue pensado para perdurar. Este software fue pensado para realizar una acción concreta y pensado para ocupar poco espacio, no para ser mantenido (además de ser poco eficiente tanto en rendimiento como en diseño), lo cual dificulta enormemente el mantenimiento del mismo. El mantenimiento del código heredado se podría disminuir, y además aumentar la calidad del código, aplicando Reingeniería sobre el mismo.  Evolución del Software: Este factor también viene implícito en el código heredado. El código se va modificando a lo largo del tiempo y por lo tanto va sufriendo cambios. Estos cambios con el paso del tiempo van a ocasionar que disminuya la eficiencia y se deteriore el software. A su vez, es muy normal realizar modificaciones únicamente en el código sin plasmar estos cambios en la documentación, lo que en un futuro dificulta el mantenimiento del mismo.  Ausencia de Herramientas: Este es un factor dependiente del equipo encargado del mantenimiento, pues, pese a existir herramientas para el mantenimiento del software, normalmente estas no son utilizadas para la realización del mismo, realizándose todo el proceso de una manera primitiva ad-hoc, por lo que el proceso de mantenimiento se complica y no se obtienen los resultados esperados. Reingeniería Dado que la reingeniería se puede considerar un tipo especial de mantenimiento se ha realizado un apartado específico para enumerar y definir todas las características principales de la misma. Así, se ha realizado una definición de cada una de las tareas que se realiza en el proceso de reingeniería: Análisis de inventario, Reestructuración de documentos, Ingeniería inversa e Ingeniería directa. A su vez se han definido varías características que pese no ser propias de la reingeniería en sí, si son importantes e intervienen en la misma, como son por ejemplo las Herramientas CASE, gracias a las cuales se facilita la reingeniería. Migración, pues al realizar la reingeniería se disminuye la complejidad para poder realizar la migración de una aplicación software a otro entorno (software o hardware). Esperanza de vida, la reingeniería al realizar modificaciones tanto en el código como en la documentación puede aumentar la esperanza de vida de la aplicación software. Prototipo Software, la reingeniería se basa en el producto anterior para realizar un producto nuevo, por lo tanto se basa en un prototipo totalmente funcional y operativo. 23

Ingeniería Inversa Por último se ha dejado la definición tanto de Ingeniería Inversa como de sus propiedades, se ha dejado para último lugar pues es necesario conocer las definiciones anteriores para comprender lo que es la ingeniería inversa. Dentro de las características de la misma se ha definido Extracción de Abstracciones, esta es sin duda la más importante de las tareas de la Ingeniería Inversa pues mediante esta tarea es posible extraer una documentación y unas interfaces del código que nos permitirán o bien disminuir los costes de mantenimiento, al tener una documentación bien definida, o el crear una nueva aplicación (mediante ingeniería directa), basada en la anterior, gracias a las interfaces extraídas.

Aportaciones personales en el apartado desarrollo metodológico Para el desarrollo metodológico se ha decido el modelo unificado como modelo de procesos, la elección de este modelo ha sido debida a la alta flexibilidad que ofrece: Es un modelo altamente probado y configurable pudiéndose adaptar a proyectos de diferente tamaño y complejidad, iterativo, por lo que el mantenimiento generaría una nueva versión de la iteración del ciclo, orientado a objetos, lo que permite utilizar todas las características que estos ofrecen así como la utilización de gran cantidad de herramientas que automatizan tanto la OO, como las diferentes actividades del proceso unificado. Además de estas características, el modelo unificado disminuye el proceso de especificación de requerimientos, asegura la calidad del producto e intenta disminuir los riesgos de cada uno de los procesos o actividades y permite una interacción total con el usuario desde el inicio del proyecto. A su vez, el proyecto unificado se enfoca en la reutilización lo cual le hace idóneo para un desarrollo basado en componentes, aún así en este desarrollo no se ha decidido utilizar un desarrollo basado en componentes, lo cual se explicará a continuación. Como paso previo, entre otros, se ha realizado un Estudio de Viabilidad del Sistema (Proceso EVS de métrica v3). Con el EVS se pretende proporcionar un marco de trabajo estratégico que sirva de referencia para el Sistema de Información proponiendo una solución a corto plazo que tenga en cuenta todas las restricciones pertinentes. Una vez realizado el Estudio de Viabilidad del Sistema se ha decidido realizar un desarrollo a medida pues se ha supuesto que no existen en el mercado productos que se puedan reutilizar en el proyecto y no existe ningún proyecto anterior sobre el cual reutilizar componentes. Por lo tanto, se realiza un desarrollo a medida no utilizándose un desarrollo basado en componentes. También se han tenido en cuenta actividades pertenecientes a otros procesos anteriores al Mantenimiento de Sistemas Informáticos, estas actividades son: Preparación del 24

mantenimiento del Sistema y Establecimiento del acuerdo de nivel de Servicio pertenecientes al proceso de Implantación y Aceptación del Sistema. Con la actividad Preparación del Mantenimiento del Sistema se pretende que el equipo de mantenimiento se encuentre familiarizado con el sistema antes de que este pase a producción y por lo tanto, cuando se necesite realizar una tarea de mantenimiento este se pueda realizar con una mayor facilidad y eficiencia. Con la actividad Establecimiento del acuerdo de nivel de Servicio se pretenden determinar los servicios que se van a establecer así como definir el nivel del mismo y los compromisos de entrega del sistema. Gracias a esta actividad se pueden tener determinados, establecidos y definidos los ámbitos en los cuales el mantenimiento va a ser requerido. Para la realización del Mantenimiento de Sistemas de Información se han tenido en cuenta las cuatro actividades que se contemplan en métrica v3, que concuerdan con los procesos de mantenimiento definidos en el desarrollo conceptual, aunque variando en nombre. Así pues, la actividad “Registro de Petición” de métrica se corresponde con “Gestión de Peticiones”, del mismo modo, “Análisis de Petición” se corresponde con “Comprensión del software y de los cambios que se deben realizar sobre el mismo”, “Preparación de la implementación de la modificación” con “Modificación del software” y “Seguimiento y evaluación de los cambios hasta aceptación” con “Realización de pruebas”. En el desarrollo metodológico además de haber contemplado todas las actividades pertenecientes al proceso de Mantenimiento de Sistemas de Información se han contemplado todas las tareas pertenecientes a cada una de las actividades, pues se considera que todas ellas son esenciales para el funcionamiento del proceso. Por ejemplo no tendría sentido realizar la actividad de “Registro de Petición” sin la tarea “Asignación de la petición” pues en esta tarea es donde se define el tipo de mantenimiento a realizar, y sin ella no se podrían realizar todos los pasos siguientes del Mantenimiento de Sistemas de Información. Uno de los puntos más importantes desde una perspectiva propia es la tarea “Establecimiento del Plan de Acción” perteneciente a la actividad “Preparación de la Implementación de la Modificación”. Esto es debido a que en esta tarea se lleva a cabo la identificación de todas las actividades y tareas pertenecientes a los procesos realizados, dependiendo del alcance, complejidad y propiedades del mantenimiento, así como del plan de mantenimiento. Gracias a esta tarea es posible establecer un plan de trabajo determinando todas las características y factores (costes, plazos de implementación, nivel de esfuerzo,…) que hagan que el mantenimiento de sistemas de información finalice satisfactoriamente. 25

También se ha añadido al desarrollo metodológico la tarea “Especificación del Plan de Regresión” perteneciente a la actividad “Preparación de la Implementación de la Modificación”, y por ende la tarea “Realización de las Pruebas de Regresión” perteneciente a la actividad “Seguimiento y Evaluación de los cambios hasta la Aceptación”. Estas dos tareas son quizás de las más importantes del proceso de mantenimiento de sistemas de información (aparte del “Establecimiento del Plan de Acción”), pues con estas tareas se pretende impedir que cambios realizados en el mantenimiento afecten a otras partes, implicadas o no en el mismo, produciendo nuevos errores y anomalías no deseadas. Para ello se especifican casos de prueba en función de las relaciones existentes en los componentes afectados por la modificación y se realizan las pruebas con el fin de asegurar que no se ha comprometido el funcionamiento normal del sistema de información.

26

4. Bibliografía 

[PAL09]Apuntes de la Universidad de Las Palmas de Gran Canarias de la Asignatura, Prueba y Mantenimiento del Software.



o

http://serdis.dis.ulpgc.es/~a013775/asignaturas/it-pms/Apuntes/6_Mantenimiento%20del%20software.pdf

o

http://serdis.dis.ulpgc.es/~a013775/asignaturas/it-pms/Apuntes/7_Mantenimiento.%20M%e9trica%20v3.pdf

[MET03]Métrica v3. Mantenimiento de Sistemas de Información. o

http://serdis.dis.ulpgc.es/~a013775/asignaturas/itpms/Apuntes/Mantenimiento%20de%20Sistemas%20de%20Informaci%f3n%20M%c9TRICA%20v3.pdf



[UO09]Apuntes de la Universidad de Oviedo, Fundamentos de Ingeniería Software. o



https://euitio178.ccu.uniovi.es/foros/download.php?id=1556

[PRES06] Ingeniería del Software. Un enfoque práctico. McGraw-Hill

27

5. Presentación

28