Coloquio Final Flashcards
En gestión de valor ganado se cuenta con información de valor planeado para todo el proyecto y, valor ganado y costo real hasta el momento actual de la ejecución.
¿Si ese momento representa la finalización del primer tercio de la duración planificada para todo el proyecto y se cuenta con información completa de lo realizado hasta el día que indica un desvío significativo de costos, entonces qué escenarios puede vislumbrar para lo que resta del proyecto respecto de costos y duración y cómo estima el costo total del proyecto en cada uno de ellos.
En cuanto a costos
- AC > EV (gastas más de lo que habías pensado al principio)
- AC < EV (gastas menos de lo que habías pensado al principio)
Si lo gastado es menor que lo presupuestado tendría que asegurar la calidad del trabajo realizado, que los recursos se hayan utilizado apropiadamente, y asegurar que el alcance este cubierto apropiadamente.
En cuanto a cronograma
- PV > EV
- PV = EV (esta no va en caso de desvío)
- PV < EV
Escenario 1: sigue la misma desviación.
BAC / CPI
Escenario 2: primer trimestre con desvíos y el 2ndo y 3ero sin desvío.
EAC = BAC + AC - EV
Escenario 3: Los costos futuros se calcularán con base a los índices de rendimiento del costo y del cronograma a la fecha.
EAC = BAC / (CPI * SPI)
Escenario 4: Estimar en base a nuevas estimaciones.
Estimado del costo total = AC + estimación restante que falta gastar.
MEP
La empresa en la que trabaja está evaluando el mercado antes de invocar una acción de gestión de abastecimiento de un equipamiento que va a ser introducido dentro del sistema productivo.
Se ha definido utilizar MEP como metodología de evaluación. Previo a la publicación del ¿pliego?, se cuenta con cuatro presupuestos de referencia de diferentes alternativas que satisfacen los requerimientos indispensables. Al analizarlas, se detecta que dos de ellas se encontrarían por debajo de 20 puntos de ponderación, cumpliendo solamente los requerimientos mínimos. Mientras tanto, las otras dos, que son equipos que se encuentran dentro de la máxima expectativa, no superan los 80 puntos de ponderación. ¿Qué conclusiones puede sacar?
Las que tienen 20 puntos de ponderación se puede concluir que puede ser que sean más baratas que las demás en cuanto a precio o cumplen muy pocos requisitos de los deseables (por eso la ponderación tan baja) o ambas (lo tachado se puede decir para chamuyar en un caso hipotético de 20 solo aparte, porque como dice que “solamente los requerimientos mínimos” => son baratos, no cumplen con los requerimientos deseables).
En cambio las que no superan los 80 puntos, como están dentro de la máxima expectativa se podría concluir que no superan los 80 puntos por el precio.
(Hay que ver si con “encuentran dentro de la máxima expectativa” se refiere a que cumple con los requerimientos deseados entonces podría que no esté en 100 por el precio).
[Imagen oficina le pega a servidor en la nube]
Una empresa tiene su aplicación core corriendo desde un servicio de nube pública, desde una de las oficinas, se han reiterado los problemas de disponibilidad de acceso a la aplicación. Luego de extensos análisis se ha determinado que la latencia del enlace es el origen de los problemas, sobre todo en el momento diurno que es cuando se realiza la facturación.
Dada la inexistencia de otros proveedores en la zona, no existen posibilidades de subsanación desde el punto de vista de la conectividad.
Proponga una estrategia de solución.
Todo lo que no es facturación se puede ingresar en una cola, para que se realicen en otro momento del día en donde haya menos tráfico, para que sean realizas en orden de llegadas.
Hacer que la parte de facturación sea on premise replicando el sistema de facturación de la nube y que el resto sea en la nube.
El sistema de facturación en realidad está en la nube, y vos on premise tenés como un “hijo” de ese sistema. Localmente vos tenes que montar la información que está en la nube. Pero lo más probable, es que esa información que está en la nube cambie todo el tiempo, productos nuevos, cambios de precios. Por lo que el que está de forma local necesita que tenga algún tipo de actualización. Ahora nosotros tenemos que comunicarle al sistema de facturación que está en la nube lo que ha pasado acá (se emitió facturas, tarjetas de crédito).
… Chamuyar desventajas de on premise …
A partir del diagrama que se muestra a continuación identifique todos los riesgos de disponibilidad que visualiza:
[Imagen db en memoria, BC, 3 nodos aplicación y DB master-slave]
- Hay un único punto de falla en el balanceador de carga. Si se cae el balanceador de carga, se cae todo. Entonces, si queremos mejorar la disponibilidad, habría que hacer algo con el balanceador de carga (cluster).
- Todas las requests caen a master, aunque tenes HA.
- SI se cae la db en memoria se podría realentizar todo porque funciona como una cache.
- Quizás la cantidad de nodos no alcanza para la cantidad de usuarios, pero esto deberia analizarse no se puede ver en el grafico.
- También ver realmente qué pasa si se cae uno de los nodos y quedan los otros dos nodos trabajando. Ver si se puede afectar en esa situación la disponibilidad. Como se redirige a los dos nodos restantes, si se tiene una cantidad de tráfico importante, ver si realmente se puede soportar el trabajo si se cae uno de los nodos. Porque si el sistema funciona, pero por debajo de lo acordado => hay continuidad pero la disponibilidad se ve afectada (ya sea porque va más lento o porque alguna funcionalidad no funcione).
Te daban una situación de 3 propuestas que se diferenciaban por 1 punto de ponderación cada una. Sabiendo que no hay errores de cálculo ni de desarrollo de funciones, describa claramente paso por paso qué revisaría y cómo lo haría.
¿Utilizaría el VPP para esta revisión? ¿Si decidiera utilizarlo, cómo lo haría?
VPP: Cuánto estoy dispuesto yo a pagar por un punto más en la ponderación de un atributo.
Si se tiene 3 propuestas en total y todas son muy similares, puede ser que estás haciendo rangos muy extensos (acortar los rangos o usar funciones) (en la tabla de valorización de atributos) o que te hayan faltado requerimientos por evaluar.
Y, después de chequear lo de arriba, si sigo teniendo el mismo problema, entonces utilizaría VPP.
[fórmula VPP]
Usted debe hacerse cargo de un proyecto que inició hace 6 meses y el cual tiene una duración estimada de 24 meses. Este proyecto es gestionado según la metodología del PMI.
Al solicitar la documentación del mismo observa que el plan de gestión de riesgos está concluido, se detectaron 2 riesgos al inicio del proyecto los cuales fueron mitigados y en consecuencia la reserva de contingencia fue asignada a otros costos del proyecto.
Detalle y justifique qué acciones tomaría.
- El enunciado dice “gestión de riesgos está concluido…”, y algo que hay que tener en cuenta es que el plan de riesgos no puede haber terminado a mitad del proyecto.
- No te podes quedar sin reservas, porque pueden surgir nuevos riesgos a lo largo del proyecto.
Por lo que las acciones que tomaría son: - Continuar con el plan de gestión de riesgos.
- ## Poner reservas en contingencia.Lo primero que haría era decirle a la gerencia que se estaban manejando mal los riesgos, porque faltaba un montón de tiempo y solo porque se habían mitigado dos riesgos le daban la reserva a otras cosas
Hay que tener dos reservas:
De contingencia: Para riesgos conocidos Forman parte de la línea base de costos Puede ser un porcentaje del costo estimado, una cantidad fija, o puede calcularse utilizando métodos de análisis cuantitativos. Los maneja el director del proyecto
De gestión
Para riesgos desconocidos
Lo maneja el patrocinador del proyecto
No forman parte de la línea base de costos pero forma parte del presupuesto del proyecto
Decia algo como que tenias un SW y tenia que ser SEGURO y que actualmente cumplia con los siguientes items:
Acceso de usuarios restringido
Acceso por clave
Resistencia de ataques
… y así como 10 ítems, algunos muy técnicos que no tenía ni idea de que hablaba.
Y la pregunta era “Con todos estos ítems es seguro el SW?. Si respondes que NO que le agregarias, si decis que SI que orden le pondrías a los ítems”.
- Sinceramente no tenía ni idea de lo que me decía, pero lo asocie con la teoría y le dije que NO, y ahí empecé de que tenía que cumplir con los 3 pilares (Confidencialidad, integridad, y disponibilidad) y además otros como protección de duplicados, autentificación, auditoría, etc.
- Me pregunto como podía cumplir con la Disponibilidad y dije algo de que tenía que estar los datos replicados (o algo asi respondi)
- Mencione que faltaban aspectos de seguridad física, restricción de permisos, auditoria de seguridad, no se mencionaba que estándar se usó de base o guia, como iba a ser el proceso en caso de que suceda un incidente.
- Restricción de permisos.
- No se menciona un estándar.
- Cómo va a ser el proceso en caso de que suceda un incidene.
- Autenticación.
- ¿Cómo solucionar la disponibilidad? => con replicación de datos?
Si ud ofrece servicios cloud de hardware virtualizados en los cuales subcontrata otros proveedores y también posee un datacenter propio y quiere salir a vender su producto. En la planificación de sus precios y acuerdos de nivel de servicio que quiero ofrecer explique cómo determinaría ud el SLA sobre la disponibilidad de hardware para ofrecer a los potenciales clientes. ¿Qué variables tiene que considerar?
La principal variable a considerar, está en que se tiene varios proveedores de servicios y también un datacenter propio, por lo que hay que determinar cuál de los servicios brinda una disponibilidad más baja. Hay que revisar el SLA actual que se tiene con los proveedores y en base a eso comparar, para poder poner cual es tu piso de servicio garantizado.
A la hora de realizar el SLA lo que tendría en cuenta es:
- Cómo es que se va a medir la disponibilidad de hardware.
- Las personas responsables de medir la disponibilidad.
- Si la disponibilidad mensual se viera reducida, el cliente tendrá derecho a reclamar una compensación al final del mes, por los servicios afectados.
En la organización donde formás parte del equipo de gestión de servicios de IT, a pesar de contar con soluciones de HA para los servicios críticos on-premise, se plantea la necesidad de contar con un data center de contingencia para situaciones de desastre.
Te han encargado evaluar alternativas y encontraste dos opciones:
- Warm site: data center con conectividad, hardware, software e infraestructura con menor capacidad que el sitio productivo y con información actualizada diaria o semanalmente. Esto limita la pérdida de datos en caso de desastre y la disrupción puede extenderse durante horas o días. Su costo es significativamente menor que el sitio productivo.
- Hot site: data center con conectividad, hardware, software e infraestructura que permite replicar los datos productivos críticos casi en tiempo real. En caso de caída del sitio productivo, la carga de trabajo se transfiere en minutos. Este data center está siempre funcionando para asegurar la sincronización de los datos. Es una solución muy costosa para la organización.
Warm site te parece adecuada en costo pero los RTOs y RPOs que se podrían alcanzar para algunas soluciones son inaceptables por su impacto en los procesos de negocio.
Hot site cubre generosamente los requerimientos de continuidad del negocio pero su costo es excesivo.
Decidís consultar a un colega quien telefónicamente te indica que warm site/hot site es una falsa opción, ya que podés elegir un camino intermedio para lograr un mejor balance entre costos y RTOs/RPOs. Aunque la comunicación se corta abruptamente por problemas técnicos antes de que puedas escuchar los fundamentos del enfoque que te acababan de sugerir, ya tenés claro cómo armar tu estrategia.
¿Cuál es esa estrategia?
Log shipping: Cuando se activa hace un backup del log de transacciones, después ese backup se copia a una instancia secundaria de ese motor que está ocurriendo en ese lugar, esos archivos de backup una vez que llegan a otro servidor se restaura en esa base secundaria. Es una forma de tener actualizado un servidor secundario pero no con un mecanismo tradicional de replicación sino por una cadena de backups y restauraciones.
El log shipping es un método barato, sencillo y alternativo a otros métodos de alta disponibilidad.
Característica: pueden tenerse más de una instancia secundaria.
Te contrataron para la semana de inscripciones de la facultad, que riesgos tendrías y cómo los manejarías?
- Evitar (directamente evita que pase el riesgo)
- Transferir (en el caso de los seguros, que le estoy pasando el riesgo a otro)
- Mitigar (disminuye las probabilidades de que el evento ocurra)
- Aceptar (va a pasar y se acepta porque no hay nada para hacer)
Si [evento o condición incierta expresado en presente], entonces [impacto del riesgo expresado en futuro]
Riesgos de desastres naturales (un terremoto en los servers de tu solución (on premise)) (aceptar?).
Riesgos de seguridad (hackeos al sistemas).
Riesgo de disponibilidad (pico de carga y se cae el sistema, lo soluciono con clusters) (mitigar)
De la nada me empiezan a llegar muchos reclamos de parte de los usuarios y estaba ocupando mucho tiempo de los desarrolladores en atenderlos y me pregunto que medidas podía tomar para solucionarlos.
Después me dijo supone que los errores no son realmente errores sino que los usuarios están haciendo mal las cosas o no entienden el sistema.
le dije que primero deberia encontrar cual es la fuente de esos errores. Que separaria la parte que recibe los reclamos de los desarrolladores, para que se puedan priorizar los errores que se tienen que solucionar y filtrar los repetidos o los que no son realmente errores, mejorar la trazabilidad de la resolución de esos errores.
Mejoraria el testing porq esos errores no se estan atacando a tiempo.
y despues me dijo supone que los errores no son realmente errores sino que los usuarios estan haciendo mal las cosas o no entienden el sistema.
le dije que mejoraria la capacitacion a los usuarios finales, haria un manual de usuarios y con una parte de preguntas frecuentes por si el usuario es medio pajero y no quiere leer
Vos estas yendo a dar un discurso en una conferencia. Pero te das cuenta que si se te pincha una goma, llegarías tarde a la conferencia. Tenés dos opciones:
* ir con un amigo en caravana.
* ir una hora antes en vez de media hora antes.
¿que es un riesgo? ¿Cuáles son sus características? ¿estos planes a qué característica están atacando? Caracteriza ese tipo de plan.
Un riesgo es un evento incierto que, si sucede, tiene un efecto en uno o más objetivos del proyecto.
Atributos del riesgo
Probabilidad de ocurrencia * impacto (resultado de la materialización del riego) = severidad
- plan de mitigación: apunta a disminuir las probabilidades de que el evento ocurra.
- plan de contingencia: se ejecuta una vez ocurrido el incidente y trabaja sobre el impacto del mismo.
(le dijeron que el riesgo es llegar tarde)
caravana -> contingencia (se ejecuta una vez ocurrido el incidente, en este caso que se te pinche la goma, y trabaja sobre el impacto)
hora antes -> mitigación (apunta a disminuir las probabilidades de que el evento ocurra)
¿Cuándo se considera un proyecto exitoso?
Un proyecto exitoso es el que contribuye al éxito de la organización.
OKR. Ejemplo.
Los OKR’s constan de dos componentes principales:
- Objetivos: Lo que quieres lograr. Generalmente esto implica establecer un objetivo (normalmente de naturaleza cualitativa) en torno a una iniciativa específica que esperas mejorar o trabajar en ella.
- Resultados clave: Cómo alcanzarás tu objetivo. Estos son objetivos cuantitativos que se pueden medir y tienen un límite de tiempo definido en el que deben cumplirse.
OBJETIVO : ¿A dónde queremos llegar o qué queremos lograr?
RESULTADOS CLAVE: ¿De qué forma nos damos cuenta que estamos teniendo éxito con el objetivo?
INICIATIVAS: ¿Qué cosas haremos para cumplir esos objetivos clave?
Ejemplo:
OBJETIVO: “Poder dictar las clases de ADR – ciclo lectivo 2020 en su primer cuatrimestre. Adecuándonos al aislamiento preventivo obligatorio dictado por decreto resol. 297/2020”
RESULTADOS CLAVE
*Que el Net Promoter Score sea mayor a 70.
* El llenado de las encuestas y ejercitaciones sea mayor al 95%
*Que la utilización del foro de intercambio de opiniones supere las 50 interacciones por Clase.
INICIATIVAS
* Incorporar más elementos lúdicos en la ejecución de los talleres. * Mejorar el contenido del material de estudio para los alumnos. * Incrementar la ejercitación entre pares.
RTO y RPO
RTO: Tiempo que tarda en recuperarse un sistema.
RPO: Al punto que vamos a volver si se perdió el servicio.
Cuanto más chicos son, más plata hay que poner. El costo de mejora crece de forma exponencial.
RPO: se refiere al tiempo que transcurre entre el momento del desastre y el último punto de restauración de nuestros datos, es decir, la cantidad de datos que nuestra empresa va a perder en caso de que se produzca un fallo del sistema.
Para ello podemos lanzar más puntos de restauración a lo largo del día, si nuestro entorno está virtualizado realizar réplicas de las máquinas virtuales en otro servidor o incluso disponer de una replicación entre dos centros de datos.
RTO: tiempo de recuperación, es decir, el tiempo que estamos dispuestos a asumir entre la caída del sistema o la pérdida de datos.
Para reducir el RTO o tiempo de recuperación, hay que contar con un sistema de resguardo de datos (backup) ágil y moderno que nos permita volver al estado normal en el menor tiempo posible.
Es una buena práctica medir el RTO a partir del momento en que ocurre la interrupción, en lugar del momento en que el equipo de TI comienza a solucionar el problema.
Entre los factores que influyen en la determinación de RTO y RPO son la criticidad que posea el negocio, en el caso de las operaciones versátiles, debido al alto impacto que esto tiene si se pierde alguna transacción se busca minimizar ambos valores.
El aumento en la frecuencia de la toma de copias de seguridad permite disminuir el RPO.
