EAS

Sobre los cuatro tipos de mantenimiento más extendidos: El mantenimiento correctivo trata de corregir errores detectados, sobre todo, en explotación. El mantenimiento preventivo pretende eliminar los fallos antes de que se manifiesten. El mantenimiento perfectivo nunca añade nuevas funciones, sólo mejora las ya existentes. El mantenimiento adaptativo sólo adapta algunos detalles; nunca modifica la estructura.

Sobre los procesos de evolución y mantenimiento: Actualmente, se separa con claridad el proceso de evolución del proceso de desarrollo. El costo del proceso de desarrollo inicial es muy superior al de la etapa de mantenimiento. En un proceso de evolución, toda petición de cambio va seguida de un análisis de impacto. Una vez que una petición de cambio ha sido aceptada, no se vuelven a evaluar los requisitos.

Sobre la Inversión de Control: Se produce cuando durante la construcción de un framework se diseña una clase para que herede de una clase abstracta, de modo que la nueva clase es la que invoca la ejecución del sistema. Es el tipo concreto de inversión que se da cuando, en un sistema dirigido por eventos, se usa el patrón Service Locator, dándole el control y evitando las retrollamadas (callbacks). Es una forma de la Inversión de Dependencias, en la que no hay inyección, porque la relación no se hace por herencia sino por delegación. Se resume en el Principio de Hollywood: "no nos llame, nosotros le llamaremos".

La Segunda Ley de Lehman, o de la Complejidad Creciente: Indica que la complejidad del software se incrementa con su evolución, ya que cada cambio supone un nuevo tipo de interacción; a menos que se trabaje explícitamente para reducirla, lo que supone (a su vez) disminuir la capacidad de introducir nuevos cambios. Indica que la complejidad del software aumenta de manera continua, porque los usuarios demandan cada vez más funcionalidad, y esto causa un crecimiento constante. Se la relaciona con el Principio de Incertidumbre del Software: dado que el software no puede describir el dominio con precisión, cada revisión aporta más información nueva, y por tanto se alcanza una mayor complejidad. Se basa en lazos de realimentación, como las restantes Leyes de Lehman; pero es, además, la única que expresa explícitamente su influencia de sobre la complejidad de Kolmogorov, que adopta así una estructura ciclomática, como la de McCabe.

*No se dispone de la pregunta – ¿Principio de Responsabilidad Única (SOLID)?: La clase responsable de un concepto debe participar en todas las actividades que lo incluyan. Define la responsabilidad, literalmente, como un motivo para cambiar, a nivel de diseño. Cada método de una clase debe representar una abstracción completa, con toda su estructura. Su objetivo principal es maximizar la propiedad encarnada en el concepto de acoplamiento.

Sobre los sistemas heredados o sistemas de legado: Normalmente se corresponden con sistemas del tipo conocido como técnico-informático. Se puede plantear una estrategia de reemplazo evolutivo, en la que varias partes del sistema son gradualmente sustituidas por otras nuevas. El mantenimiento habitual es inviable en un sistema heredado, dado el alcance de los cambios. La estrategia de evolución nunca puede plantear desechar por completo un sistema heredado.

Sobre el coste del mantenimiento: Se habla de barrera de mantenimiento cuando las restricciones organizativas llevan a una situación en la que se impide mantener un software que aún es útil, incluso cuando los costes derivados son todavía asumibles. Se suele aplicar aquí el análisis de Pareto: indica que el 80% del coste se consume durante la fase de mantenimiento, siendo el 20% restante el coste de la etapa de desarrollo. Aunque el mantenimiento es posterior a la entrega, resulta más caro cuando se corresponde con trabajo realizado en una fase más temprana del desarrollo: los costes asociados a la arquitectura son mucho mayores que los asociados a la etapa de implementación. En los años 90, el coste del mantenimiento llegó a ser el 90% del coste de un sistema medio; sin embargo, esto se ha reducido enormemente desde la aparición de las metodologías ágiles.

Sobre el mantenimiento estructural: No es un tipo de mantenimiento por sí mismo, sino que es una categoría concreta dentro del preventivo, ya que su objetivo fundamental es mejorar el rendimiento del sistema. No es un tipo de mantenimiento por sí mismo, sino que es una categoría concreta dentro del adaptativo, ya que responde a la necesidad de adaptar la estructura a nuevos contextos. No es un tipo de mantenimiento por sí mismo, sino que es una categoría concreta dentro del perfectivo, ya que, al mejorar la estructura, se obtiene un software más perfecto. Puede hacer referencia a varios tipos de mantenimiento, pero su característica esencial es que, al modificar la estructura, se mejora la propia mantenibilidad del sistema.

La Tercera Ley de Lehman, o de la Auto-Regulación: Indica que los procesos de evolución son autorregulados, en el sentido de que tanto las métricas de los atributos de producto como los de proceso siguen una distribución normal. Indica que, a partir de cierto nivel de complejidad, ni siquiera los gestores de la organización son capaces de afectar al proceso, por lo que éste debe regularse por sí mismo. Se relaciona con el Principio de Incertidumbre del Software: precisamente esta incertidumbre es la que le impide evolucionar más allá de cierto punto, regulando implícitamente el proceso. Se basa en el principio de estabilidad de Gunther, y, por tanto, es la única Ley de Lehman que no se apoya, explícita o implícitamente, en lazos de realimentación.

Sobre la degradación del software: Puede adoptar la forma de deriva arquitectónica: en algún momento de su evolución, el software pasa a tener una utilidad totalmente distinta, y se aleja de su propósito original. Puede adoptar la forma de congestión arquitectónica: la situación en la que todavía se permite la adición de nuevos componentes, pero ya no resulta posible modificar los existentes. Puede adoptar la forma de erosión arquitectónica: cuando el software evoluciona, los elementos modificados (y añadidos) se van alejando progresivamente de la arquitectura original. En realidad, el software no se desgasta, al no ser tangible. Como indica la Séptima Ley de Lehman, la degradación es solo aparente, un efecto psicológico debido a la deuda técnica.

Sobre el mantenimiento, se puede afirmar que: El software perfecto no necesitaría cambiar; pero se ha de mantener, ya que es imperfecto. El software bajo mantenimiento debe dejar de usarse hasta que los errores sean corregidos. El propósito del mantenimiento es eliminar errores; por tanto, por su propia concepción, no puede introducir nuevos errores. Durante esta etapa, el software tiene una entropía creciente: la estructura de un programa se va deteriorando a medida que él mismo evoluciona.