Examen 2019, preguntas y respuestas PDF

Preview

Summary

Sobre las líneas base (LB) en Gestión de la Configuración (GCS): Una Línea Base es una versión de un elemento de configuración (EC) que se considera como una ‘versión de referencia’. Una vez que los cambios han llegado al punto en que se define una LB, ésta se considera definitiva: no se puede retro...

Description

1. Sobre las líneas base (LB) en Gestión de la Configuración (GCS): Una Línea Base es una versión de un elemento de configuración (EC) que se considera como una ‘versión de referencia’. Una vez que los cambios han llegado al punto en que se define una LB, ésta se considera definitiva: no se puede retroceder más, aunque se puede seguir avanzando. Es un elemento central de la disciplina de GCS (Disciplina que identifica la configuración de un sistema en puntos discretos del tiempo, con el objetivo de controlar sistemáticamente los cambios de esa configuración y mantener su calidad y trazabilidad a través del ciclo de vida del sistema). Marca el final de una fase del ciclo de vida del software. 2. Sobre las métricas de mantenimiento, asigne cada razonamiento con una de ellas: -

-

-

-

-

Número de peticiones de cambios pendientes. Si aumenta, significa que la mantenibilidad disminuye, porque se piden más cambios de los que el equipo es capaz de implementar. Tiempo medio empleado en implementar una petición de cambio?. Si aumenta, significa que la mantenibilidad disminuye en cada cambio que se realiza, ya que llevarlo a cabo resulta cada vez más complejo. No se identifica con ninguna. Si aumenta, significa que la mantenibilidad está mejorando. Se piden cada vez más cambios, porque los usuarios están contentos con el trabajo previo. Número de peticiones de mantenimiento correctivo. Si aumenta, significa que se han introducido más errores de los que se han corregido durante el proceso de mantenimiento. Tiempo medio requerido para el análisis de impacto. Si aumenta, significa que la mantenibilidad global disminuye porque cada cambio implica a un número mayor de componentes.

3. La primera Ley de Lehman o del cambio continuo: Se relaciona con el Principio de Incertidumbre del Software: dado que el software no es capaz de describir todos los aspectos del dominio que intenta simular, es también inevitable que el sistema deba evolucionar a medida que este dominio cambia en la realidad.

4. Asigne una tarea a cada una de las actividades del proceso de Gestión de la Configuración.

-

Control de la configuración: Evalúa el impacto de cambio en los entregables y los recursos del proyecto. Auditorías y revisiones de la configuración: Garantiza que una línea base se corresponde con la descripción de los EC que la componen. Contabilidad del estado de la configuración: Define los procedimientos para registrar la evolución del producto. Identificación de la configuración: Define los procedimientos de almacenamiento y recuperación de los EC controlados. Control de la configuración?: Permite comprobar que el proceso de cambio se ajusta al presupuesto inicial.

5. Sobre la terminología de control de versiones respecto a los tipos de evolución: -

Entrega. Se define como una versión del sistema que se concibe para ser proporcionada al cliente final para su despliegue y explotación. Versión. Se define como una instancia de un sistema que difiere, de manera significativa, con otra instancia anterior o posterior del mismo sistema. Variante. Se define como una versión de un sistema que se concibe para ser diferente por algún motivo, y se agrega a la ya existentes sin sustituirlas. Delta. Se define como el conjunto de cambios que tiene una versión con respecto a la inmediatamente anterior (o posterior) Revisión. Se define como una versión que se concibe no simplemente para evolucionar, sino para sustituir a la versión anterior.

6. Sobre los sistemas de contenedores: El objetivo inicial de los sistemas de contenedores es encapsular todas las dependencias de un elemento software dentro de una misma entidad, que pueda tratarse como un módulo portable, fácil de transportar de un sistema a otro; también permite desplegar distintas versiones en el mismo sistema.

7. Asigne una propiedad a cada una de las actividades del proceso de reingeniería. -

Reestructuración de código. Puede basarse en los resultados de un análisis dinámico. Análisis de inventario. Debe irse modificando a medida que varía el estado del software.

-

Ingeniería inversa. Permite recuperar información sobre cambios que nunca fueron documentados. Reestructuración de documentos. Si los recursos son limitados, puede hacerse solo cuando haya modificaciones. Reestructuración de datos. Debe utilizarse para eliminar sinonimias y polisemias.

8. Sobre la barrera de mantenimiento. Se relaciona con el porcentaje de recursos que se dedican a mantenimiento: cuando éste supera un límite, fijado en torno al 95%, la organización ya no tiene recursos para nada más, y no puede dedicarse a producir nada nuevo, con lo que queda estancada en su actividad actual. 9. Sobre las diferencias entre sistemas de control de versiones (CVS) centralizado y distribuido. En un CVS centralizado hay un servidor central que mantiene la versión de referencia, que es la que se considera más actualizada. En un CVS distribuido, no hay ningún servidor: el último nodo-cliente en el que se ha actualizado el repositorio se convierte en la versión de referencia. En un CVS centralizado hay un servidor central que mantiene la versión de referencia, que es la que se considera más actualizada. En un CVS distribuido, cualquiera de los nodos puede actuar como servidor y ser utilizado como referencia por cualquiera de los demás nodos-cliente. Los nombres son engañosos: la diferencia es que el CVS centralizado tiene un servidor, que no tiene por qué ser único, y en un CVS distribuido la arquitectura no es cliente servidor, sino peerto-peer. Pero uno de los pares debe declararse central (GitHub, por ejemplo), y si ése no está activo, no pueden funcionar. 10. Sobre la Cuarta Ley de Lehman, o de la Estabilidad Organizacional.. Significa que toda organización tiende a la estabilidad, lo que se traduce en que cualquier cambio se enfrenta a fuerzas en sentido contrario, lo que implica que el ritmo de trabajo es, en promedio, invariante. 11. Asigne un razonamiento a cada una de las estrategias de evolución en sistemas heredados. - Desechar completamente el sistema heredado. Los procesos de negocio han cambiado desde que se instaló el sistema, y aunque se sigue utilizando ya no dependen de él. - Reemplazar el sistema total o parcialmente. El sistema sigue siendo necesario, pero hay partes de él que han quedado obsoletas y no le permiten continuar funcionando.

-

Hacer reingeniería del sistema. El sistema sigue funcionando, pero se quiere modificar su funcionalidad para que haga algo completamente distinto, porque ya no es necesario. Reemplazar el sistema total o parcialmente. El sistema funciona y es todavía necesario, pero su comportamiento se ha degradado y necesita todavía más cambios. Continuar con un mantenimiento regular. El sistema sigue siendo estable, y se solicita un número comparativamente pequeño de cambios.

12. Sobre el ISO 12207, incluyendo sus versiones anteriores (IEEE 1074).. -

Incluye el Proceso de Mantenimiento de Software.. como un proceso principal. Incluye el Proceso de Análisis de Requisitos.. como proceso de desarrollo especial. Incluye el Proceso de Gestión de la Infraestructura.. como parte de los procesos propios de la organización. Incluye la Gestión de la Configuración de Software.. como un proceso de soporte. Incluye el Proceso de Adquisición de Software.. como un proceso principal desde la versión inicial.

13. Sobre los sistemas de Retroalimentación (feedback).. Las leyes de Lehman se basan implícitamente en lazos de retroalimentación. La excepción es la Séptima Ley, o de la Calidad Decreciente, que no se basa en magnitudes, sino en una percepción.

14. Diferencia entre Evolución y Mantenimiento. Todo mantenimiento es evolución; pero no toda la evolución es mantenimiento. 15. ¿Qué tipo de mantenimiento se corresponde con cada una de estas operaciones? - Mantenimiento perfectivo: La velocidad del almacén de datos se ha degradado en los últimos tiempos, por lo que se definen nuevos índices para mejorar su rendimiento. - Mantenimiento adaptativo: El código utiliza tres estructuras de datos distintas para la misma información; se decide reunirlas en una sola para evitar discrepancias entre ellas. - Mantenimiento preventivo: El sistema utiliza una base de datos antigua, que se encapsula dentro de un contenedor para evitar conflictos con el actual sistema operativo. - Mantenimiento correctivo: En la versión anterior se implementó una consulta simplificada que, en algunos casos, podría perder información. Se decide arreglarlo antes de que falle. - Mantenimiento adaptativo: El nuevo sistema de seguridad exige el uso de certificados digitales y la aplicación debe soportarlos como nuevo sistema de autenticación. 16. Sobre la ingeniería inversa..

Se denomina ingeniería inversa a la que se da en el sentido contrario a la ingeniería ‘normal’ o directa: es decir, cuando se obtiene un artefacto más abstracto a partir de otro más concreto. El objetivo es utilizar luego este artefacto para construir una nueva implementación, u obtener información en el proceso. 17. Sobre las estrategias de control de versiones, en particular Bloqueo-ModificaciónDesbloqueo.. La estrategia CMM permite realizar cambios en paralelo sobre el mismo repositorio, lo que es ideal en sistemas distribuidos. Sin embargo, esto no significa que no haya que trabajar de manera cuidados. Si dos nodos están modificando exactamente el mismo código, el merge posterior puede ser muy complejo.

18. Sobre la erosión arquitectónica.. Se denomina erosión arquitectónica a lo que ocurre cuando la evolución del sistema lo va alejando progresivamente de la arquitectura inicial. Esto va degradando el comportamiento del sistema y puede llegar hasta el punto de que esta ya no sea la arquitectura adecuada.

Es otra forma de llamar a la deuda técnica: los compromisos que se han realizado durante el proceso de desarrollo hacen que se implemente una arquitectura distinta a la ideal. Cada una de estas decisiones fue razonable cuando se tomó, pero eventualmente produce problemas y ‘malos olores’. 19. ¿En qué circunstancias se aplica un proceso de reingeniería? Cuando no queda otro remedio. El software se ha deteriorado a tal nivel que resulta imposible seguir manteniéndolo, y se toma esta opción, que por lo demás es muy costosa. 20. Sobre los Procesos de Evolución, concebidos de manera genérica.. Los procesos de evolución son cíclicos y continúan durante toda la vida del sistema. En realidad, se puede ver como un único proceso, en el que se van identificando cambios y se produce una evolución continua. 21. ¿Cuál es la relación entre los Principios de Diseño SOLID? El SRP define el objetivo. El OCP permite detectar los problemas. LSP e ISP proporcionan las condiciones necesarias. El DIP da la solución a los problemas detectados. Conjuntamente, y aplicados de manera correcta definen un sistema con la máxima cohesión y el mínimo acoplamiento.

22. Sobre los tipos de sistemas informáticos.. Un sistema socio técnico es aquel cuya función se enmarca en un objetivo más amplio, y que por tanto no puede ser considerado fuera de su entorno.

MÉTRICAS DE PREDICCIÓN DEL MANTENIMIENTO: TEMA 1

Número de peticiones de mantenimiento correctivo: Si crece el número de informes de fallos de ejecución puede indicar que se han introducido más errores en el programa de los que se han corregido durante el proceso de mantenimiento. Tiempo medio requerido para el análisis de impacto: Refleja el número de componentes del sistema que se ven implicados en una petición de cambio. Si se incrementa, implica que más y más componentes se ven implicados y que la mantenibilidad disminuye. Tiempo medio empleado en implementar una petición de cambio: Relacionado con el análisis de impacto. Se trata de la cantidad de tiempo que se necesita realmente para modificar el sistema y su documentación. Un incremento en el tiempo necesario para implementar un cambio puede indicar una disminución en la mantenibilidad. Número de peticiones de cambio pendientes. Un incremento en este número a lo largo del tiempo puede implicar una disminución en la mantenibilidad.

Tipos de mantenimiento:   



Mantenimiento perfectivo: Conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario. Mantenimiento adaptativo: Conjunto de actividades para adaptar el sistema a los cambios (hardware o software) en su entorno tecnológico. Mantenimiento correctivo: Conjunto de actividades dedicadas a corregir defectos en el hardware o en el software detectados por los usuarios durante la explotación del sistema. Mantenimiento preventivo: Conjunto de actividades para facilitar el mantenimiento futuro del sistema.

Legacy systems. Sistemas técnico-informáticos: Incluyen hardware y software pero no procesos ni procedimientos. Los individuos usan estos sistemas para algún fin, pero ese fin no es parte del sistema. Sistemas socio-técnicos: Son sistemas que comprenden uno o más sistemas técnicos pero que además incluyen conocimiento de como debe usarse el sistema para alcanzar algún objetivo más amplio. Sistemas heredados: Anticuado pero se siguen utilizando; no se puede o no se quiere actualizar o reemplazar.





 

Desechar completamente el sistema: Cuando el sistema no constituye una contribución efectiva para los procesos de negocio == Si los procesos de negocio han cambiado desde que se instaló el sistema y son completamente independientes. Dejar el sistema sin cambios y continuar con un mantenimiento regular : El sistema aún es necesario y muy estable; los usuarios solicitan un número muy pequeño de cambios. Reemplazar todo o parte del sistema con un nuevo sistema : Cuando otros factores hacen que el sistema antiguo no pueda continuar (ej: hardware). Hacer reingeniería del sistema para mejorar su mantenibilidad : Cuando el sistema se ha ido modificando continuamente puede suceder que la calidad del sistema se ha degradado y los cambios son aún necesarios.

Leyes de Lehman: TEMA 2 Sistemas Tipo-S: Aquellos que se han implementado siguiendo una especificación exacta de lo que el software debe hacer. Sistema Tipo-P: Aquellos que implementan un conjunto de procedimientos que se ejecutan de manera independiente y, en conjunto, desarrollan un comportamiento complejo. Sistemas Tipo-E: Pretenden realizar actividades relacionadas con el mundo real, es decir, que satisfacen una necesidad real.

Las leyes SOLO SE APLICAN A LOS SISTEMAS TIPO-E (es decir, la mayoría del software) 1º Ley. Ley del cambio continuo. Todo sistema tipo-E que se utilice debe ser adaptado de manera continua o, de lo contrario, se irá haciendo progresivamente menos satisfactorio. Se relaciona con: El mundo real también cambia de manera inevitable y con el Principio de Incertidumbre del software (el software nunca describe el dominio operacional deseado de manera exacta). 2º Ley. Ley de la complejidad creciente. A medida que un sistema tipo-E evoluciona, su complejidad se incrementa, a menos que específicamente se trabaje para mantenerla, o incluso para reducirla. 3º Ley. Ley de la Auto-Regulación. Los procesos de evolución de los sistemas tipo-E son autorregulados, de modo que las métricas de los atributos de proceso y producto son cercanas a la distribución normal.

4º Ley. Ley de la Conservación de la Estabilidad Organizacional. La media efectiva del ritmo global de actividad en un sistema tipo-E que evoluciona es invariante a lo largo del tiempo de vida del producto. ‘Todo intento por incrementar la productividad es contrarrestado por fuerzas de signo contrario’ Ley de Brooks = Aumentar el nº de miembros de un equipo de un equipo aumenta el overhead de comunicación. 5º Ley. Durante la vida activa de un sistema tipo-E que evoluciona, el ritmo medio de crecimiento permanece invariante: es decir, el incremento en contenido entre las sucesivas versiones es estadísticamente invariante. ‘Cuantos más cambios haya en cada versión, más difícil será que todos sean conscientes de ellos, los entiendan y los aprecien’ 6º Ley. El contenido funcional de un sistema tipo-E debe incrementarse de manera continua durante todo su tiempo de vida para mantener el grado de satisfacción de los usuarios. 7º Ley. En un sistema de tipo-E se percibe que la calidad decae con el tiempo, a menos que se mantenga de manera rigurosa, y que se adapte a los cambios del entorno operacional. 8º Ley. Ley del Sistema de Retroalimentación (Feedback).

Los procesos de evolución de los sistemas de tipo-E se constituyen como sistemas de retroalimentación multinivel, con múltiples agentes y múltiples lazos; y deben tratarse como tales si se desea lograr en ellos cualquier mejora significativa sobre cualquier base razonable.

ACTIVIDADES DE LA GCS: TEMA 3!!

Identificación de la configuración: Actividades para identificar, nombrar y describir las características del código, de las especificaciones, del diseño y de los elementos de datos a controlar en el proyecto. -

Identifican los EC y las LB (registrar los elementos a controlar y mantener las listas de elementos y líneas base) Nombrar los EC. Obtener los EC (identificar las bibliotecas de almacén de documentación de GCS y describir los procedimientos de almacenaje y recuperar los EC).

Control de la configuración: -

-

-

Identificación de la necesidad del cambio y documentación. Especificación de los procedimientos del control de cambios. Se registra la información (nombre y versión de ECs, fecha, datos del autor de la solicitud…). Análisis y evaluación de la petición de cambio. Especifica el análisis a realizar para evaluar el impacto del cambio y los procedimientos para revisar el análisis de los resultados. Se evalúan los entregables y los recursos del proyecto. Aprobación o desaprobación de cambio. Comités de Control de Cambio (CCC); pueden existir varios CCC y de diferentes niveles. Implementación de los cambios. Se necesita información como la petición de cambio asociada, nombres y versiones de los ECs afectados, identificador de la nueva versión…

Contabilidad del estado de la configuración: Permiten dar a conocer el equipo de desarrollo. -

Define e implementa los procedimientos; visibilidad: ofrece vista del proceso; trazabilidad: registra la evolución del producto. Mecanismos de determinación: Qué ha ocurrido en el proceso de desarrollo y cuando. Ahorra tiempo y dinero.

Auditorías y revisiones de la configuración: Medio por el cual una organización asegura que los desarrolladores han hecho su trabajo de forma que se satisfacen todas las obligaciones externas. - Se aseguran de que un cambio ha sido implementado correctamente. - Garantizan que la LB corresponde con la descripción de sus elementos. - Garantizan que los elementos auditados están completos y siguen el plan de GCS.

CONTROL DE VERSIONES. TEMA 4!!  Branch: copiar un fichero original con la intención (o no) de modificarlo.  Merge: Incorporar en un repositorio los cambios que se produjeron en otro de forma independiente. Entrega: Versión del sistema que se entrega a los clientes. Revisión. Conjunto de versiones en un instante determinado con el objetivo de reemplazar versiones anteriores. Variante. Versión de un componente o sistema que se añade a las versiones existentes sin reemplazarlas. Versión. Instancia de sistema que difiera de alguna manera de otras instancias del mismo sistema. Delta. Conjunto de cambios de una versión respecto a la anterior.

Estrategias de versionado: Bloqueo-Modificación-Desbloqueo: este tipo de estrategia es problemática. Es siempre centralizado. Copiar-Modificar-Mezclar: este tipo de estrategia es el ideal. Puede ser centralizado o distribuido....