UTNianos

Versión completa: [APORTE] Final ADR 17/02/2016
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Hola les comento lo que recuerdo del final de ADR de ayer

1_Verdadero o falso
A_ El capex es siempre dinámico cuando el entorno del proyecto es cambiante en una infraestructura Cloud
B_Consistencia se refiere a que una transacción no puede leer datos hasta que no esten confirmados

2_ Multiple choice
A_Básicamente como se calculaba el EAC, te decía que era dividir BAC por:
*Tenias que eligir la opción CPI

B_Te daban tres propuestas con su total de puntos de poderación, y el VPP =30. Y tenias que elegir la opción correcta. La propuesta 1 y 2. Diferían por menos de un punto (P1>P2)
*Recomienda P1 y no analiza VPP
*Como difieren en menos del VPP, gana P2
*VPP mal calculado
*Todas las anteriores
*Ninguna

3_Te daban la situación de inscripción a materias de la facultad entonces tenias que proponer un plan de contingencia y mitigación de riesgos a nivel infraestructura, software y procedimientos. A su vez decir valores óptimos de RTO y RPO.

4_Te decían porque una base no relacional no es recomendable en un modelo de datos relacional y cuando recomendaría una base de datos no relacional y porque.
Gracias por el aporte! tenes idea de cual es la rta correcta en el 2-b? gracias!
4) Podria ser por que la no relacional tiene ciertas limitaciones en cuanto a hacer un full scan, al tener la información distribuida tiene costos de performance.
Creo que hay varias razones, no se si solo una... si no te interesa o no tenes que tener los datos centralizados y consistentes, si podes tolerar que tengas algunos desactualizados, si no tenes mucho presupuesto

Si alguien me la corrige o completa, mil gracias!
Hola!

Medium...

1.
A. Verdadero.
B. Falso porque se refiere a si se ejecuto una transacción, se ejecutaron todas.

2. Multi siempre es fácil. u.U

4. A donde lo apuntaste la respuesta?

Saludos!

(18-02-2016 16:03)CarooLina escribió: [ -> ]4) Podria ser por que la no relacional tiene ciertas limitaciones en cuanto a hacer un full scan, al tener la información distribuida tiene costos de performance.
Creo que hay varias razones, no se si solo una... si no te interesa o no tenes que tener los datos centralizados y consistentes, si podes tolerar que tengas algunos desactualizados, si no tenes mucho presupuesto

Si alguien me la corrige o completa, mil gracias!

El tema de full scan es el tema de buscar datos porque utiliza memoria en vez de disco? Podría ser. Conflictos que se podría tener son que al no cumplir con ACID y vos diseñaste un DER considerando ACID, ya estas en problemas; después que no hay estándares de las mismas. Se recomienda para, además de lo mencionado anteriormente, cuando manejas muchos datos y el sistema tiene necesidad de escalar y queres recuperar datos muy rápidamente.

Les va?

Saludos!
Hola, yo en el punto 2)B) puse "Recomienda P1 y no analiza VPP". Me hubiese gustado aclarar que si se tiene un especial interes por P2 entonces hay sí se analiza el VPP para ver en $$ cuanto me sale obtener esa satisfacción extra.

En el Punto 1)B) Ahora que recuerdo decía era en ACID, no consistencia en no sql.

En el pto 4)Puse ventajas y desventajas de db no sql, por ejemplo su rapido tiempo de respuesta, escalabilidad horizontal, particionamientos en distintos clusters, la posibilidad de armar esquemas de nodos redundantes con la información distribuida, su gran manejo en bases con muchisimos datos, etc. pero que no tenia estándares bien definidos, no tienen gran madurez aún y no cumplen con ACID sino con el teorema CAP. Al no cumplir con ACID entonces puedo tener desactualizada en nodos y encima redundante, por lo que por ejemplo en un modelo de datos para por ejemplo un carrito de compra o sistema de facturación No utilizaria un tipo de bd no relacional por que puede que compre algo --> persista en un nodo y me baje mi credito --> hago otra consulta y no haya terminado de replicar a otros nodos o se caiga el nodo que persistio mi compra --> Me contesta otro nodo y mi credito queda intacto.
Donde si se aplicaria una BD no sql, en sistemas que manejan gran cantidad de información, que necesiten gran tiempo de respuesta, hacemos foco en la eficiencia, por ejemplo en una red social donde para poder ver un historial o relaciones entre amigos en una BD relacional significaria hacer consultas con N joins o recursivas que provocarian una gran perdida de performance sin embargo al no tener normalizado los datos en una nosql seria mucho más eficiente su tiempo de respuesta....
o algo por ese estilo respondí
Genial! Gracias a los dos
Aplauso
Hola,

Alguno me explica porqué el 1.A es verdadero?
Por una cuestión de lógica diría que si, pero en la ppt de tipos de computadores, en la parte de capex y opex de Cloud Computing dice
"Conclusiones del uso o implementación de servicios
de CLOUD:
Disminuyen la inversión CAPEX y permiten que el
OPEX crezca dinámicamente en la medida en que
crecen las necesidades."

Por lo que debería poner falso con eso como explicación.
(25-05-2016 20:33)turco91 escribió: [ -> ]Hola,

Alguno me explica porqué el 1.A es verdadero?
Por una cuestión de lógica diría que si, pero en la ppt de tipos de computadores, en la parte de capex y opex de Cloud Computing dice
"Conclusiones del uso o implementación de servicios
de CLOUD:
Disminuyen la inversión CAPEX y permiten que el
OPEX crezca dinámicamente en la medida en que
crecen las necesidades."

Por lo que debería poner falso con eso como explicación.

Para mi también es falso y se equivocó el de acá.

El caprex es el costo de capital en inversiones o bienes que compra la empresa para realizar el proyecto en una primera instancia, que la mayoria de las veces va a ser fijo y no varia dinamicamente de acuerdo a como crezca el proyecto durante su ciclo de vida. En cambio, el oprex que es el costo operativo y los gastos que se tienen mes a mes por así decirlo, sí podría crecer y más si se tiene un alquiler de un Cloud ya que si el proyecto crece se necesitan más recursos de Cloud y por lo tanto aumenta el alquiler del mismo y por ende el oprex. Con Cloud el caprex no va a crecer, al revés va a disminuir porque no es necesario comprar cierto equipamento, sino que lo "alquilas" con Cloud Computing
En el 2 alguien me puede explicar por que recomienda p1 y no analiza VPP??
Hola, esto respondería yo:

1A) El capex es siempre dinámico cuando el entorno del proyecto es cambiante en una infraestructura Cloud
Falso, el concepto de Cloud apunta a la adquisición de servicios a demanda, lo cual no representaría CAPEX, sino OPEX.

1B) Consistencia se refiere a que una transacción no puede leer datos hasta que no estén confirmados
Verdadero, Consistencia es la característica que garantiza integridad. Una transacción consistente comienza en un estado válido y finaliza en otro estado válido.

2_ Multiple choice
A_Básicamente como se calculaba el EAC, te decía que era dividir BAC por:
*Tenias que eligir la opción CPI
EAC = BAC / CPI

B_Te daban tres propuestas con su total de puntos de poderación, y el VPP =30. Y tenias que elegir la opción correcta. La propuesta 1 y 2 diferían por menos de un punto (P1>P2)
*Recomienda P1 y no analiza VPP
*Como difieren en menos del VPP, gana P2
*VPP mal calculado
*Todas las anteriores
*Ninguna
[i]NINGUNA??? Todas las propuestas que estén en el cuadro, cumplen los requerimientos. Habría que validar, con el VPP, que las propuesta no se va de presupuesto.
A mayor ponderación, mayor satisfacción, no necesariamente sea mayor costo.
[/i]

3_Te daban la situación de inscripción a materias de la facultad entonces tenias que proponer un plan de contingencia y mitigación de riesgos a nivel infraestructura, software y procedimientos. A su vez decir valores óptimos de RTO y RPO.

EXPO AL RIESGO = probabilidad * impacto

Identificar los riesgos y clasificarlos según el tratamiento:
Mitigan : bajar la probabilidad de ocurrencia
Aceptan (se ignoran): NADA
Eliminar o prevenir: eliminar el impacto
Trasladan: derivar el impacto a otros

PLAN de contingencia, se ejecuta para los riesgos que se van a tratar
PLAN de mitigación, se ejecuta para los riesgos que se van a mitigar.

Riesgos:
El alumno no se puede inscribir por problemas de correlatividad
No le aparecen una materia que tiene que recursar
No le aparecen materias que se le vencieron en el período previo
Cuello de botella produce pérdida de datos
Plan de contingencia para eliminar/trasladar riesgos:

Luego del cierre de la inscripción, se solicita la inscripción presencial y/o confirmación, brindando la posibilidad de corrección a un usuario con mayores permisos que el alumno.
Durante ese período se tiene que garantizar que el sistema está cerrado a los alumnos y que sólo personal administrativo tiene acceso al mismo.
Se garantiza el acceso al sistema, en la sede Medrano, a través de una red LAN privada, que estará disponible 100% durante este período. Se cuenta con 2 servidores de respaldo, equipo de red (router, cables, placas de red, etc) y terminales (PCs) de reemplazo en caso de problemas con los mismos.


Plan de mitigación:

Se enviaran 2 recordatorio (email o sms) a los alumnos con el objetivo de evitar cuellos de botella al fin del período de inscripción, uno al comienzo y otro a la mitad del período.
Se da la posibilidad de informar la baja instantánea de materias, tal que los los alumnos que deban recursar una materia que figura en la cursada actual, puedan acceder a las mismas.
Se abre el canal de consultas sobre el sistema de inscripción, asignando a 1 persona por departamento, para atender las consultas y con el permiso necesario para habilitar materias ocultas por correlatividad o no disponibles por otros motivos.

RTO: response time objective. Tiempo máximo de tolerancia en el cual el sistema está inactivo, debido a un problema, hasta que se recupera: 12hs
RPO: recovery point objective. Representa, en tiempo, el volúmen de datos que se está dispuesto a perder ante un problema: Sacar cuentas, pero RPO bajo


4_Te decían porque una base no relacional no es recomendable en un modelo de datos relacional y cuando recomendaría una base de datos no relacional y porque.

No se recomiendan, debido a sus desventajas:
Falta de madurez
No garantizan ACID
Falta de estándares

En qué casos conviene una noSQL:
Cuando se tiene que manejar grandes volúmenes de información
Se necesita poder escalar horizontalmente
Modelos no muy definidos que posiblemente sufran cambios
Cuando es más importante el tiempo de respuesta que la consistencia o coherencia
Cuando se requiere alto tiempo de rta
B_Te daban tres propuestas con su total de puntos de poderación, y el VPP =30. Y tenias que elegir la opción correcta. La propuesta 1 y 2 diferían por menos de un punto (P1>P2)
*Recomienda P1 y no analiza VPP
*Como difieren en menos del VPP, gana P2
*VPP mal calculado
*Todas las anteriores


Yo hubiera elegido P2 y la opc 2, pero no me convence que diga "difieren en menos del vpp". Por que es casi la misma satisfaccion que producen las dos propuestas y la de P1 es mas cara.

De donde sacaste eso del riesgo nuema ? Por que yo tengo que es un plan de contingencia, definición de riesgo, la gestión del riesgo... pero nada mas.
La teoría está en la ppt de control y seguimiento de proyecto, habla de Gestión del riesgo.
Cómo hacer un plan, etc, te lo enseñan en Ing. de software. Pero serían los mismos pasos a seguir que el "proceso de gestión de riesgos":

Identificación: reconocimiento de las fuentes de riesgo y sus consecuencias potenciales
Análisis: determinación de la necesidad de tratamiento del riesgo y la prioridad de su implementación
Tratamiento o respuesta: selección de opciones para actuar sobre el riesgo y la implementación de las mismas
Monitoreo y revisión: evaluación del progreso en la implementación del tratamiento

Creo que para poder definir el plan, al menos tenés que tener un par de riesgos identificados.

La 2b) no se, no hay info sobre las propuestas. Se supone que a mayor ponderación mas satisfacción, pero no es justificación "Como difieren en menos del VPP..."
Yo no hice ing en software y probablemente hubiera ido por los pasos de gestion de riesgos. Gracias!
Buenas! Respecto al V y F, estoy de acuerdo con que el 1.A) es FALSO por la misma razón que explicaron antes y lo que dice la PPT.

Respecto a la otra afirmación: 1.B) Consistencia se refiere a que una transacción no puede leer datos hasta que no estén confirmados

Para mí es FALSA según la definición de ACID.
Que una transacción pueda leer o no datos que no estén confirmados depende de la propiedad Isolation (Niveles de aislamiento), que define cómo y cuándo se ven los cambios en una operación. Consistencia es la propiedad que verifica que solo se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos.

Saludos!
URLs de referencia