Segundo Parcial del 24/11/08 (Ingeniería II)

Consignas

• El examen está conformado por 7 preguntas teóricas y un ejercicio práctico.
• Cada pregunta equivale a 1 punto, pudiendo obtener medio punto por una respuesta parcial.
• Para aprobar el examen, debe sumar 4 puntos de preguntas teóricas y 50% del ejercicio.
• Por favor, responda las preguntas en forma concisa y justifique sus decisiones arquitectónicas.

Ej. ATAM

Se nos ha encargado al desarrollo de un juego RTS (Real Time Strategy) sobre Google Maps, al estilo Command & Conquer o Warcraft. La idea es desarrollar unidades militares sobre el terreno (en este caso, el mísmo planeta Tierra) y desarrollar combates con ias mismas. Para ello, es necesario valerse de los mapas de Goog1e, pero agregando información sobre los mismos (overlays).

Inicialmente, necesitaremos informacíón política (control de territorio por parte de cada jugador, fisica (impedimentos fisicos del terreno, actualizaciones climaticas, etc) tacticos (unidades y recursos naturales, etc.)

Se espera gran carga de usuarios jugando al mismo tiempo, y actualizar informacion climatica de manera externa ya que las fotos da Google no son actuales.

El cliente plantea los siguientes escenarios de atributos de calidad para la primera beta del producto:

• 1) Quiere que las condiciones climaticas y decisiones de los jugadores influencien inmediatamente al juego, que no tarde más de 5 segundos en verse reflejado el cambio.
• 2) Quiere que nadie más que los agentes autorizados puedan realizar cambios (los jugadores pueden tomar decisiones, ios agentes meteorologicos cambiar estados fisicos, etc ). No quiero gente haciendo trampa.
• 3) Nos especifico sin embargo que el programa cliente, el que corre en la maquina del jugador, no estara a cargo de nosotros sino de otros desarrolladores. Quiere que quede todo abierto para que sea posible que el cliente sea mu1tiplataforma.
• 4) Necesita que los datos del juego sean confiables, a fin de poder volver a estados pasados del juegos en caso de ser necesario, en menos de 1 hs.

Tras unos días de análisis, el equipo de ingenieros propuso la siguiente arquítectura para el sistema: Archivo:Ing2-241108.jpg

Se pide:

• 1) Identifique 4 tacticas o estrategias arquitectonicas presentes en la arquitectura relacíonadas con los escenarios especificados.
• 2) Identifique riesgos, no-riesgos, puntos sensibles y puntos de tradeoff en esta arquitectura en relacion con los atríbutos de calided requeridos tai como se lo hace en ATAM.

Rta:

1)

Las tacticas arquitectonicas fueron:

• A) Utilizacion de Firewall
• B) Interfaz RSS p/multiplataforma
• C) Replicacion de Hardware (servidores)
• D) Map Overlayer

2)

Tabla ATAM

	Esc/Tacticas	Firewall	RSS	SRV(1..n)	MapOverlayer
Performance	1 (clima y decisiones)	TO1		PS1	TO2
Seguridad	2 (cambios autoriz)	TO1
Confiabilidad	3 (estados pasados)				TO2
Interoperabilidad	4 (multiplataf)		NR

• TO1: El firewall es indispensable para detectar intrusos y dejar pasar los agentes autorizados, entonces es PS para el escenario de seguridad la que lo afecta positivamente. Tambien puede formarse un cuello de botella entre usuarios y servidores generando un impacto negativo de performance. Por estas razones, se tiene un punto de tradeoff. (Ademas, podria convertirse en riesgo porque puede dejar sin efecto las ventajas de multiples servidores).
• PS1: Tener replicas de servidores puede ayudar a manejar el caudal de clientes, tambien permite reemplazos si algun servidor no anda, todo esto ayuda a cumplir el servicio de performance.
• TO2: Las distintas partes del Map Overlayer (political, physical, tactial) se ocupan de informacion determinada, esta division como toda especializacion permite un mejor enfoque que repercute en datos mas confiables pero trae overhead, que afecta la performance. (aclarar redundancia de BDs)
• NR: Se considera RSS no riesgo porque no ata lo que esta brindando (informacion hacia afuera) a una plataforma, parece ser una buena interface que contribuye a que el cliente sea multiplataforma.

Ej. Teoricos

• 1. Describa brevemente el ciclo de trabajo según la filosofia de TDD ¿Cómo cree que pueda combinarse esta idea de trabajo con el pair programming?
• 2. En el contexto de SCM, ¿que documentos o artefactos se incluyen en ei baselíne de un release? Hint: alcanza solo con un tag sobre la version involucrada del codigo?
• 3. Proponga tres métricas para medir la eficiencia (output/input) de los procesos de testing o inspección. (Se piden 3 en total, no 3 para c/u).
• 4. Cuál es la diferencia entre validación y verificación?
• 5. En el nivel 4 de CMMI ¿cómo es el proceso que se utiliza pera poner distintos subprocesos de la organización (no de un proyecto) bajo control cuantitativo o estadistico? ¿Cual es el objetivo, respecto de este control estadístico, para pasar de nivel 4 a nivel 5?

Conteste V/F y justifique:

• 6. La única función del rol de SQA es asegurar ia calidad del producto final.
• 7. En el UAT (User Acceptance Test), los usuarios son responsables unicamante de ia ejecución de las pruebas.

Rtas:

• 1. TDD dice que deben realizarse los test de unidad sobre los productos antes de commitear y si hay un bug debe agregarse un caso de test que lo comtemple antes de resolverlo. Puede encajar con PP porque el diseño del test puede ser mas efectivo y completo cuando lo piensan 2 personas con sus puntos de vista.
• 2. El baseline es una foto de los artefactos (ej: codigo, documentacion req y arq, etc) para saber que se esta implementando, asi como tambien info del entorno, plataforma de ejecucion, framework etc.
• 3. # bugs encontrados por hora/persona, % bugs encontrados por tipo de documento, % cobertura de testing.
• 4. Validacion es para ver si se hace el producto correcto, Verificacion es para ver si se hace el producto correctamente. Ambas estan en el nivel 3 de CMMI
• 5. Identificar subprocesos de org de mayor importancia y aplicar control estadistico. El objetivo es utilizar esta informacion para mejorar el proceso y eliminar las causas comunes de variacion
• 6. [F] La funcion de SQA es evaluar la ejecucion del proceso (calidad, costo, trato de desvios, etc)
• 7. [F] Los usuarios tambien aportan a la hora de diseñar tests de aceptacion ya que deben manifestar que necesitan o esperan del producto.