Primer Parcial del 08/05/08 (Ingeniería II)

El parcial consiste de un ejercicio de arquitecturas de software y 6 preguntas teóricas. El ejercicio vale 4 puntos, y las preguntas un punto cada una. Para aprobar el parcial se debe tener al menos 2 puntos en el ejercicio de arquitecturas y 6 puntos en total. Realice el ejercicio de arquitecturas en hojas separadas a las preguntas teóricas.

Ej. Arquitectura

La república de Casinópolis ha decidido recientemente centralizar todas las operaciones referentes a su industria de los juegos de azar (la única industria que existe en la república, bah). En esta primera etapa del proyecto de centralización, la administración ha decidido concentrarse en los juegos de sorteo del estilo Loto. Según la operatoria actual, un jugador se presenta en cualquiera de las miles de oficinas distribuidas por todo el país. enuncia la apuesta que quiere realizar (en general, esto se reduce a la elección de cierta cantidad de números distintos) y el encargado de recibir la apuesta la anota en la libretita negra oficial de Casinopolis. entregando copia al apostador. Evidentemente. este sistema tiene varias falencias que la administración se ha decidido a resolver mediante la informatización y centralización del servicio: en primer lugar, el uso de un sistema de comprobantes manual es completamente inseguro debido a la alta probabilidad de fraudes (es común ver comprobantes falsos o agencieros que agregan apuestas posteriormente al sorteo). Por otra parte, segun los ultimos estudios encargados a la oficina de estadisticas de juego, la administracion pierde millones en ingresos debido a la obligacióu de cerrar las apuestas 2 días antes del sorteo (para tener tiempo de acumular todos los comprobantes). La administración querría reducir este tiempo a como máximo 5 minutos para aprovechar la avalancha de apostadores de última hora. Además, se quiere conocer si existen ganadores de manera inmediata, apenas terminado el sorteo. Vale aclarar que si bien se quiere ofrecer la posibilídad de apostar hasta 5 minutos antes, algunas oficinas de apuestas pueden no hacerlo y estarán cerradas (y con sus sistemas apagados) horas antes y durante el sorteo.

En reuniones preliminares con el departamento de informática de la administración de juegos de azar de Casinopolis, además, hizo notar algunas cuestiones que considera importante para el proyecto:

• en primer lugar, éste será el primer sistema informático a gran escala implementado en la república. Por esta razón, resulta que la administración no tiene a su disposición sistemas de hardware capaces de responder a la demanda que se espera tener del sistema. En particular, sostienen que el sistema probablemente experimente demandas en los momentos pico en el orden de los cientos de pedidos por segundo a nivel nacional, mientras que los sistemas de hardware disponibles apenas pueden soportar demandas en el orden de decenas de pedidos por segundo.
• esta falta crítica de recursos de calidad se traslada también a los servidores de bases de datos, que cuentan con las mismas características en cuanto a calidad de servicio.
• en contrapartida, la infraestructura de comunicaciones a nivel nacional es excelente. Se puede contar con conectividad en cualquier lugar del país (aunque esto, claro, no quiere decir que ocasionalmente se caigan las comunicaciones). De todas formas, hay tantas oficinas de apuestas que en general, cuando un apostador no puede colocar su apuesta por no haber comunicación, se dirige a otra oficina. No es común que se experimenten fallas globales de conectividad, y dado el estado “piloto” de la centralización, no es un aspecto que preocupe a la administración.
• se desea tener, en tiempo lo más cercano posible a tiempo real, información estadística para los sorteos (dinero apostado, número más apostado, desgloses por oficina de apuestas, etc, etc.).

Para el ejercicio, se pide:

• Especifique al menos un atributo de calidad referente a performance/disponibilidad y otro referente a seguridad para el sistema. Especifíquelos mediante el uso de escenarios.
• Presente una arquitectura global del sistema que responda a los atributos de calidad planteado. Tenga en cuenta también todos los atributos de calidad derivados del enunciado, aunque no haya especificado todos. Utilice los diagramas que crea necesarios y no deje de aclarar todo aquello que no quede explícito en los mismos.

Rta:

Escenarios para QA's

	Fuente	Estimulo	Artefacto	Entorno	Respuesta	Medicion
Perf/Disp	Agencia	Request Info	Sist Central	Op Normal	Lista Ganadores	Delay despreciable e/estimulo y resp
Seguridad	Apostador	Apuesta/Batch	Sist Central	Sorteo Realizado	Apuestas Ignoradas	0 fraudes p/ap posterior

• Arquitectura del Sistema (vista C&C combinada con Deployment):

(pegar dibujo)

• Referencias

-|>-|>-|>  flujo de datos de apuestas
- - - -|>  requests
-------|>  otros flujos de informacion

• Funcionamiento del sistema
  • Cada Oficina toma las apuestas propias y las almacena en una Base Local, imprimiendo los tickets en una Impresora especial (tinta especial etc) para hacer dificil/imposible su falsificacion. Alternativamente, podria tomar los datos de los clientes y almacenarlos en la base local para evitar este tipo de fraudes.
  • El Sistema Central tiene una base de las oficinas que estan participando periodicamente (por ej c/10 min), hace pedidos a las oficinas para que manden las ultimas apuestas. Al hacerlo, se establece una conexion segura (tipo SSH). Si una oficina va a cerrar, informa a la sede central.
  • La Base de oficinas tiene la informacion del estado (online, cerrada o caida). No se aceptan apuestas no pedidas.
  • Si una maquina no responde, pasa a estar caida. en cada iteracion, 1ro se hace el request a las maquinas que figuraban como caidas, esperando ver si ya estan online para recibir las apuestas faltantes. Esto no escala demasiado si se agregan oficinas. Este sistema esta pensado para que el Aggregator tenga el control del flujo de las las apuestas de manera de no saturarse a si mismo ni a la base de datos (hace request a medidad que puede). Alternativamente podria poner varias bases para aumentar el flujo posible utilizando un dispatcher.
  • 5 min antes del sorteo, todas las oficinas pasan a estar cerradas (local y para el sistema).
  • Se hace el ultimo ciclo de pedidos, si alguna maquina no responde se seguira intentando hasta el sorteo.
  • Como la base se actualiza c/10 min, se tienen datos frescos para hacer estadisticas.
  • Al finalizar el sorteo, por medio de una query a la Base central, se tienen los ganadores casi inmediatamente.

Ej. Teoricos

• 1. Suponga un proyecto que tiene una duracion estimada de 10 meses con 10 hitos (uno asociado a c/mes), c/u asociado con un entregable distinguible. Es posible tener un grado de avance de 45% al finalizar el 6to mes si hasta el momento todo fue entregado en fecha y aceptado por el cliente? Justifique.
• 2. Esta utilizando el metodo Wideband Delphi para estimar el esfuerzo de desarrollo de un modulo que, en principio, resulta complejo. Tras 2 rondas de estimacion, se pasa al ensamblado de tareas. De al menos 2 motivos por los cuales pueden no haber sido necesarias mas rondas de estimacion.
• 3. Suponga que esta desarrollando un sistema para efectuar el seguimiento de planes de proyectos. Cual deberia ser la informacion minima necesaria para poder definir una linea base de un plan?

Conteste V/F y justifique:

• 4. Si el valor de un entregable se define inicialmente a partir de su esfuerzo, el seguimiento del esfuerzo y el seguimiento del avance representan lo mismo.
• 5. Segun Parnas, el equipo de desarrollo debe definir que cosas es posible que cambien y que cosas son "supuestos fundamentales" para poder implementar el concepto de "information hiding".
• 6. Los puntos de funcion y los puntos de casos de uso sin ajustar dan, en forma directa, estimaciones de tamaño o esfuerzo.

Rtas:

• 1. Si se puede. El avance de c/tarea no siempre es directamente proporcional al tiempo que demanda producirla (podria ser que el 55% de avance restante este en las tareas de los proximos 4 meses). "The mythical man-month" menciona: cuando una tarea no puede ser particionada por "sequential restrictions", la aplicacion de mas esfuerzo no tiene efecto en el schedule.
• 2.
  • No hubo cambios con respecto a las iteraciones anteriores
  • El desvio es aceptable
  • Los estimadores se sienten seguros de su estimacion
• 3.
  • Identificacion de Reqs funcionales, QAs, factores criticos (restricciones, obj que compiten)
  • Identificacion de Stakeholders (quien paga, usa, tiene el know how)
  • Estimacion de trabajo, esfuerzo y costo
• 4. [F] Puede ser que aun al cumplir con el esfuerzo no se haya obtenido el entregable, impidiendo asi establecer el avance.
• 5. [V] Esas cosas que pueden cambiar se ocultan en modulos mediante una interfaz general.
• 6. [F] Deben mejorarse por medio del ajuste, factor de productividad, complejidad tecnica y de entorno de CU, etc.