Examenes

Junio de 2007

1.- Requisitos no funcionales

¿Qué son?

Delimitan las condiciones en que el sistema presta los servicios al usuario: básicamente requisitos de hardware, software preinstalado e infraestructura. También se refiere a tiempos de respuesta…

Pon un ejemplo de requisito no funcional de tu proyecto relacionando el ejemplo con tu propia explicación.

En nuestro caso, un sistema con:

  • Requisitos de hardware: 10GiB de disco (se recomienda grabadora).
  • Requisitos de software: Linux (Ubuntu 8.04) con Aptitude (en caso de no contar con un gestor de paquetes, se necesitan las aplicaciones Inotify, Python 2.5, xdelta3, dbus) y escritorio Gnome o librerías GTK.
  • Infraestructura extra: ninguna.

Respecto del software, era requisito no funcional que respondiese "lo bastante rápido" para cumplir el requisito funcional de la usabilidad, lo cual implicó cosas como hacer llamadas asíncronas para no bloquear el interfaz mientras se trabaja. Cuantificar dicho rendimiento "interactivo" es más complicado y se hizo estimando mediante pruebas.

2.- Riesgos

Describe las cuatro tareas básicas del proceso de gestión de riesgos

Las cuatro tareas básicas son:

  • Identificación de los riesgos: tecnológicos, de personal, de realización, de requisitos o de estimación.
  • Análisis: evaluar la probabilidad (desde muy baja hasta muy alta) y las consecuencias (de catastróficas, serias, tolerables o insignificantes) y asignar prioridades.
  • Planificar los riesgos: pensar planes para evitarlos o minimizar el impacto sobre el proyecto.
  • Seguimiento de los riesgos: revisar y actualizar los riesgos, sus probabilidades y consecuencias a lo largo del proyecto.

Explica en qué etapas del proyecto se ha trabajado sobre los riesgos

Durante la etapa de diseño (principalmente Noviembre) se llevaron a cabo las fases de identificación, análisis y planificación de riesgos y, como indica la etapa de seguimiento, a lo largo de todo el proyecto (al término de cada iteración) se revisaron los ya identificados y se descubrieron algunos nuevos.

Ejemplos: en Enero, en el que la tecnología de creación de diferencias binarias falló y en Marzo, y fue la falta de requisitos no funcionales en los equipos de prueba. En ambos casos los planes de contingencia nos ayudaron a resolver la dificultad.

3.- Pruebas de sobrecarga

Describe brevemente en qué consisten:

Consisten en llevar el sistema a un caso límite (a través de una simulación de uso extremo) y ver cómo reacciona en este caso.[1

Pon un ejemplo de prueba de sobrecarga que hayáis aplicado a vuestro proyecto o se pudiese haber aplicado:

  • Prueba exhaustiva de capacidad multiusuario: en las entregas, todas las instancias del programa corrían sobre la misma máquina remota aunque luego se accediese a ella mediante varias terminales (una por usuario).
  • Prueba exhaustiva de copia de seguridad (sobre 25000 archivos de tamaño medio, 1,4MiB): tomó unos 25 min. con un uso de memoria pico 30% y medio del 15%.

Patrones

Describe para qué sirve y dónde utilizarías un patrón Singleton:

Sirve para garantizar que sólo existe una instancia de una determinada clase y proporcionar un punto de acceso global a ella. Se usa por ejemplo para regular acceso a dispositivos que no se pueden compartir (como un puerto físico).

Pon un ejemplo de patrón que se haya (o hubiese) podido aplicar en vuestro proyecto, y explica lo que aporta (o habría aportado). Procura que no sea el patrón que has descrito en el apartado anterior2.

  • Singleton: sirve para garantizar que sólo existe una instancia de una determinada clase y proporcionar un punto de acceso al mismo. Lo utilizamos para garantizar que hay un sólo gestor de configuración (para que sea consistente), y se utiliza junto con factoría abstracta en la elección del método de backups para garantizar una sóla fábrica.
  • Adapter: convierte la interfaz de una clase en otra interfaz esperada por los clientes. Permite la cooperación de clases que de otro modo serían incompatibles. Queríamos usar pySqlite para las peticiones a base de datos y creamos un adaptador para ajustarlo a las necesidades del proyecto.
  • Proxy: proporciona un representante o sustituto de otro objeto para controlar el acceso a éste. La interfaz gráfica y la consola necesitan interactuar con el demonio de la aplicación. Para ello nos creamos un sustituto de los distintos objetos a los que hemos de acceder.
  • Factoría abstracta: el uso de este patrón está recomendado con las situaciones en las que tenemos una familia de productos (los sistemas de backups) concretos y prevemos la inclusión de distintas familias de productos en un futuro (sistemas de backups sobre red, sobre ZFS, con copia directa y enlaces duros, por diferencias binarias…)

Junio de 2006

1.- Requisitos no funcionales

¿Qué son?

Delimitan las condiciones en que el sistema presta los servicios al usuario: básicamente requisitos de hardware, software preinstalado e infraestructura.

Pon un ejemplo de requisito no funcional de tu proyecto relacionando el ejemplo con tu propia explicación.

En nuestro caso, un sistema con:

  • Requisitos de hardware: 10GiB de disco (se recomienda grabadora).
  • Requisitos de software: Linux (Ubuntu 8.04) con Aptitude (en caso de no contar con un gestor de paquetes, se necesitan las aplicaciones Inotify, Python 2.5, xdelta3, dbus) y escritorio Gnome o librerías GTK.
  • Infraestructura extra: ninguna.

Tarjetas CRC

Describe qué información contiene una tarjeta CRC

  • Nombre de la clase.
  • Nombre de la superclase.
  • Conjunto de subclases.
  • Lista de responsabilidades.
  • Lista de colaboraciones.
  • Opcionalmente, breve descripción.
  • Opcionalmente, lista de atributos.

Explica qué proceso habéis seguido para obtener las tarjetas CRC del proyecto, desde las versiones iniciales a las versiones finales

Usamos Brainstorming para tratar de obtener el mayor número de clases posibles.
Luego filtramos las clases básicas (fácilmente reconocibles y con participación activa) separándolas de las fantasma (piezas externas al sistem como una grabadora) y de los sinónimos (clases redundantes) y atributos.
Usamos Rol Playing que consiste en escenificar las interacciones entre clases usando los recorridos de los casos de uso.

Con todo ello se logra definir las responsabilidades y colaboraciones de cada clase.

UML

Elige una funcionalidad de tu sistema y explícala mediante un diagrama de clases

Funcionalidad ordenar crear una nueva versión
class-examen.png

Describe la interacción de las clases representadas mediante un diagrama de colaboración

sequence-userSnapshot.png

Mantenimiento

Describe los cuatros tipos posibles de mantenimiento estudiados.

  • Perfectivo: consiste en añadir nuevas funcionalidades.
  • Adaptativo:adaptar un sistema a un entorno nuevo sin cambiar la funcionalidad.
  • Correctivo: corrección de errores y bugs.
  • Preventivo: procurar hacer un sistema más mantenible de cara al futuro.

Pon un ejemplo de cada caso para vuestro proyecto

  • Perfectivo: añadir una interfaz de texto para situaciones en las que no se disponga de entorno gráfico.
  • Adaptativo: no se ha hecho pero se podría portar a Windows y a Solaris.
  • Correctivo: la retroalimentación de cada entrega nos ha permitido darnos cuenta de varios bugs y el bugtracking, seguirlos corregirlos.
  • Preventivo: iteraciones de mantenimiento y calidad, documentación del código y refactor.

Febrero de 2006

1.- Describe muy brevemente qué actividades establecisteis para documentar cada uno de los aspectos de la funcionalidad o especificación del sistema o del trabajo que se iba a realizar para el proyecto.

Primero establecimos los requisitos funcionales tratando de mejorar un software similar llamado TimeMachine el cual es propietario y pertenece a Apple. Se intentó mantener la usabilidad en todo momento. Luego, mediante procesos de Brainstorming y pensando en el usuario final, desarrollamos las historias de uso, los casos de uso y elaboramos los riesgos. Los requisitos no funcionales fueron establecidos teniendo en cuenta las tecnologías necesarias y el escenario de ejecución (en nuestro caso Linux.)

2.- Explica cómo se ha organizado la gestión de configuración en tu grupo, concretamente describe

¿Qué se gestiona?

Documentación, código, bugs y paquete de distribución.

¿Cómo se agregan y actualizan los elementos a la gestión de configuración y cómo se accede a los mismos?

  • Documentación: se hace uso de una wiki para mantener los conocimientos (informes de investigación, tutoriales, apuntes…). La wiki posee control de versiones y herramientas para recopilar la documentación que utilizamos al final de cada iteración, para controlar los añadidos al documento base que tiene el informe "final" del proyecto.
  • Código: utilizamos un sistema de versiones descentralizado (bazaar junto con Launchpad, una herramienta web tipo Sourceforge) lo que permite que los distintos miembros del equipo trabajen localmente en sus propias ramas de desarrollo (con control de versiones sobre estas), y luego integren trivialmente en un branch de grupo y a su vez en un branch final.
  • Bugs: se utilizó el bugtracker del mismo Launchpad para seguir los bugs existentes, asignar prioridades y responsables y resolver los problemas.
  • Paquete de distribución: se utiliza un sistema automático de generación de paquetes de Launchpad.

En cada punto, habla del problema más relevante que hayáis tenido y explica cómo lo resolvisteis.

  • Código: la inexperiencia utilizando branches nos llevó a problemas de integración entre versiones y pérdidas de código. Se resolvió, una vez localizado, utilizando a la vez un branch de integración y uno de pruebas para estabilizar el código.

3.- Explica qué pasos habéis dado para gestionar los riesgos

Las cuatro tareas básicas son:

  • Identificación de los riesgos: tecnológicos, de personal, de realización, de requisitos o de estimación.
  • Análisis: evaluar la probabilidad (desde muy baja hasta muy alta) y las consecuencias (de catastróficas, serias, tolerables o insignificantes) y asignar prioridades.
  • Planificar los riesgos: pensar planes para evitarlos o minimizar el impacto sobre el proyecto.
  • Seguimiento de los riesgos: revisar y actualizar los riesgos, sus probabilidades y consecuencias a lo largo del proyecto.

Elige uno de los pasos explicados junto con un riesgo y pon un ejemplo de tu proyecto.

  • Planificar los riesgos: uno de los riegos era el software de creación de diferencias binarias. Se planificó que, en caso de que no cumpliese con nuestras necesidades, se debería reescribir y reemplazar por lo que el diseño debía ser muy modular. Efectivamente, en Enero nos dimos cuenta del error y se utilizaron las siguientes iteraciones para corregirlo.

4.- Planificación y definición de iteración

Una iteración es cada uno de los periodos en los que se divide el desarrollo del proyecto. Son una serie de miniproyectos cada uno con varios flujos de trabajo, requisitos, análisis, diseño, implementación y pruebas y que producen un incremento en el diseño, la especificación, las pruebas y la implementación total del proyecto.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License