0% encontró este documento útil (0 votos)
21 vistas123 páginas

Gestión de Proyectos: Enfoques y Riesgos

Cargado por

nchavez
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
21 vistas123 páginas

Gestión de Proyectos: Enfoques y Riesgos

Cargado por

nchavez
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

Planificación y gestión de recursos

Gestión de proyectos y alcance

DEFINICIÓN DE PROYECTO

Definiciones según los estándares: hay dos estándares: PMI y Prince. Ambos definen lo que es un
proyecto. Es importante seguir los estándares y metodologías para evitar fallas comunes en los
proyectos.
● PMI (EE.UU): es un esfuerzo temporal (tiene principio y fin) comprometido con la creación de
un producto o servicio de resultado único. El proyecto termina cuando ha alcanzado sus
objetivos o resulta claro que no pueden alcanzarse o bien la necesidad del proyecto ya no
existe. Los proyectos avanzan de manera progresiva, en incrementos continuos.
● PRINCE (Reino Unido): es una organización temporal creada con el propósito de entregar uno
o más productos de acuerdo con un caso de negocio especificado.

Diferencia entre un proyecto y un producto: la diferencia es que un proyecto tiene una fecha de inicio,
un desarrollo y un fin, mientras que un producto prevalece más allá de los proyectos de
actualizaciones que tenga emparejados.

Enfoque a medida o enfoque de diamante: se refiere a la aplicación de una gestión de proyectos


flexible y adaptable, especialmente cuando el proyecto presenta altos niveles de incertidumbre y
complejidad. En este enfoque se reconoce que no todos los proyectos pueden ser gestionados de la
misma manera y se busca adaptar la metodología y las prácticas de gestión a las particularidades y
necesidades específicas de cada proyecto.

Talle único vs. a medida: el enfoque de diamante es el que permite decidir si mi proyecto necesita un
PM talle único o a medida. Mientras mayor sea la incertidumbre y complejidad del proyecto mayor
será la necesidad de una gestión flexible y adaptable, con un PM especializado en la temática del
proyecto.

PM talle único PM a medida

Objetivo Triple restricción (tiempo, alcance, Resultados al negocio, cumpliendo


costo) múltiples criterios

Planificación Se planifica una vez al inicio Plan inicial + replanificación


Enfoque de dirección Rígido, enfocado en el plan inicial Flexible

Trabajo del proyecto Predecible, lineal, simple Impredecible, no lineal

Control del proyecto Busca desvíos respecto al plan y Identifica cambios en el entorno y
toma acciones para alinearlo ajusta el plan de acuerdo al entorno

Metodología Todos los proyectos siguen la Adaptada a la complejidad e


misma metodología incertidumbre del proyecto

FASES

CICLO PDCA (plan, do, check, act): si bien hay más de un modo de gestionar un proyecto, un
concepto común que todos siguen es el PDCA:
● Plan: identificar y analizar el problema.
● Do: elaborar e implementar una solución.
● Check: evaluar los resultados.
● Act: estandarizar la solución y capitalizarla en nuevas oportunidades.

Fases de un proyecto: los procesos involucrados en la gestión de un proyecto se dividen en


segmentos temporales llamados fases. Estas fases varían según el método de gestión utilizado. Una
de las funciones del PM es determinar cuáles de estas fases se utilizarán según el tipo de proyecto.
● Pre-proyecto: determinar la factibilidad técnica y económica para decidir si comenzamos el
proyecto.
● Inicio: se trata de que todos los involucrados comprendan qué producirá el proyecto, cuándo,
con qué costo y con qué calidad y que se elabore un plan que permita realizarlo.
● Ejecución: se trata de elaborar el producto o servicio, controlar el flujo de trabajo de los
equipos, gestionar riesgos y problemas y monitorear e informar el avance del proyecto.
● Cierre: comprobar que todo se ha realizado e informar cómo ha finalizado el proyecto.

RIESGOS Y PROBLEMAS

Riesgo: es un evento o condición incierta que, si sucede, tiene un efecto en por lo menos uno de los
objetivos del proyecto. Existen riesgos “conocidos”, aquellos que identificamos y analizamos y para
los cuáles podemos planificar respuestas y otros “desconocidos” que no podemos gestionar de
manera proactiva. Los riesgos normalmente tienen un impacto negativo en el proyecto pero existen
algunos (muy escasos y difíciles de identificar) que podrían tener un impacto positivo
(oportunidades).

Atributos del riesgo: Severidad = Probabilidad de ocurrencia * Impacto


Una vez que determinemos la severidad de todos los riesgos debemos determinar cuáles
gestionaremos (en general los de severidad alta y media).

Gestión del riesgo: el documento de gestión de riesgos es un documento “vivo” porque va cambiando
a medida que avanza el proyecto (por ejemplo, un riesgo puede dejar de serlo). Involucra:
● 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.
○ Evitar/eliminar: implica eliminar por completo la amenaza ya sea eliminando la
actividad que produce el riesgo o sustituyendo al activo por otro que no se vea
afectado por la amenaza.
○ Aceptar/asumir: se asume el riesgo y se decide no tomar acción. Ya sea porque está
debajo del umbral aceptable o porque los costos de su tratamiento son elevados y su
probabilidad de ocurrencia es baja. Se arma el plan de contingencia para poder tomar
acción una vez que ocurrió.
○ Transferir: en ocasiones la empresa no tiene la capacidad de tratamiento y precisa la
contratación de un tercero con capacidad para reducir y gestionar el riesgo. No
elimina un riesgo. Cuando yo transfiero un riego no se transfiere la responsabilidad.
○ Mitigar/reducir: implicar tomar las medidas oportunas para que el nivel de riesgo se
sitúe por debajo del umbral.
● Monitoreo y revisión: evaluación del progreso en la implementación del tratamiento.

Plan de contingencia vs. plan de mitigación:


● Contingencia: también se lo llama “plan de recuperación de desastres” o “plan de
continuación de negocios”. Este plan indica cómo recuperarse y responder ante un riesgo que
se materializó. Específica el quién, cómo, cuándo y dónde realizar acciones para responder al
desastre. Es para riesgos conocidos porque si al riesgo no lo conocíamos entonces no le
podríamos haber armado un plan de contingencia. El plan de contingencia comprende 3
subplanes:
○ Plan de prevención: contempla las medidas preventivas antes de que se materialice
una amenaza. Su finalidad es contar con las medidas necesarias para que en caso de
materialización del riesgo se pueda restituir el servicio. Ej: contar con repuestos,
equipos sustitutos, datos de resguardo.
○ Plan de emergencia: contempla las medidas necesarias durante la materialización de
una amenaza, o inmediatamente después. Su finalidad es paliar los efectos adversos
de la amenaza.
○ Plan de recuperación: contempla las medidas necesarias después de materializada y
controlada la amenaza. Su finalidad es restaurar el estado de las cosas tal y como se
encontraban antes de la materialización de la amenaza.
● Mitigación: se enfoca en prevenir o reducir los riesgos antes de que se conviertan en
problemas (evento o condición esperada o no, que afecta negativamente los objetivos de un
proyecto).

Gestión de problemas: a diferencia de los riesgos (que representan incertidumbre), los problemas
son hechos sobre los que debe actuar para evitar o minimizar consecuencias negativas sobre los
objetivos. Se gestionan con un proceso cuyas etapas son:
● Registro.
● Evaluación.
● Resolución.
● Monitoreo.

SEGUIMIENTO Y CONTROL, ÉXITO Y COMPLEJIDAD DE PROYECTOS

Seguimiento y control: se necesitan realizar mediciones sobre un proyecto para determinar su grado
de avance. Comparando el grado de avance medido con el esperado verificaremos si se observan
desvíos respecto de lo planificado. De ser así, se tomarán acciones correctivas.

Éxito: un proyecto exitoso es el que contribuye al éxito de la organización.


Complejidad: hay que tener en cuenta el enfoque del diamante.

ALCANCE

Alcance: es la definición exacta y unívoca de todo lo que estará (y lo que no) comprendido dentro del
proyecto a ejecutar. El documento de alcance:
● Es guía del equipo de trabajo durante la ejecución.
● Proporciona la línea base para evaluar si las solicitudes de cambio (CRs) que puedan surgir
se encuentran dentro o fuera de los límites establecidos.
● Es la base para la estimación de esfuerzo y duración del proyecto.
● EDT (estructura de desglose de trabajo): es el desglose de las tareas que forman parte de un
proyecto. Se trata de ir desglosando las tareas en forma jerárquica hasta llegar a entregables,
es decir, tareas realizables.

Componentes del documento de alcance:


● Descripción clara y unívoca del objetivo del proyecto.
● Justificación del proyecto.
● Listado de todos los requerimientos.
● Listado y descripción de los entregables del proyecto.
● Definición clara de los límites y restricciones del proyecto.
● Descripción de los supuestos del proyecto: son cuestiones que nunca quedaron muy claras
en las reuniones con el cliente entonces se parte de un supuesto.
● Hitos (momentos importantes) del proyecto: es donde podemos poner un punto de control.
Un entregable es un hito pero un hito no necesariamente tiene un entregable.
● Dependencias con otros proyectos: a veces nuestro proyecto depende de otros proyectos o
actividades (por eso los proyectos tienen una fecha de inicio y una fecha de fin). Nuestro
proyecto quizás es el input de otro que se va a desarrollar posteriormente.

Verificar el alcance: revisar los entregables con el cliente para asegurarse que se han completado
satisfactoriamente y obtener su aceptación formal. Ocurre al final de cada fase y al final del proyecto.

REQUERIMIENTOS

Tipos de requerimientos: para definir los requerimientos uno NO debe preguntarle al cliente ¿qué
necesita? Uno debe preguntarle al cliente ¿cuál es su problema? y a partir de ahí confeccionar los
requerimientos.
● Funcionales: describen qué es lo que el sistema debe hacer. Establecen las funciones que el
PS tiene que incluir.
● No funcionales: son las restricciones a las que está sometido el PS a desarrollar. Las
restricciones influyen sobre el funcionamiento o sobre el proceso de desarrollo de software.
Aporta un grado de detalle sobre cómo se debe llevar a cabo la implementación de los
requerimientos funcionales.

Características de los requerimientos: un requerimiento es válido sólo si cumple con todas las
siguientes características:
● Necesario: es necesario si su omisión provoca una deficiencia en el producto.
● Conciso: fácil de leer y entender, de redacción simple y clara.
● Completo: proporciona la información suficiente para ser comprendido.
● Consistente: no es contradictorio con otro requerimiento.
● No debe ser ambiguo: tiene una sola interpretación.
● Verificable: puede ser cuantificado a través de inspección, pruebas y análisis.

PLANIFICACIÓN

Pasos para desarrollar una planificación:


1. Definir actividades: identificar las acciones a realizar para producir los entregables.
○ Descomposición: el objetivo es descomponer los paquetes de trabajo en entregables.
○ Planificación gradual: se planifica en detalle el trabajo que debe desarrollarse en el
corto plazo y el trabajo futuro se planifica a un nivel superior de la EDT.
○ Juicio de expertos
2. Secuenciar las actividades: identificar las relaciones entre las actividades para hallar el
camino crítico. Es importante monitorear el desarrollo de actividades críticas para saber si se
va a atrasar el proyecto (anticiparse).
○ PPM: es un diagrama que utiliza nodos y flechas para relacionar actividades.
3. Estimar recursos de las actividades: estimar el tipo y cantidad de recursos requeridos para
realizar cada actividad.
○ Juicio de expertos
○ Análisis de alternativas: consiste en encontrar la mejor forma de completar las
actividades mediante la combinación de recursos.
○ Datos de estimación publicados
○ Estimación ascendente: esta forma de estimación consiste en descomponer una
actividad o paquete de trabajo en mayor detalle para poder estimarla.
4. Estimar la duración de las actividades: estimar el número de periodos de tiempos laborales
necesarios para completar individualmente las actividades con los recursos estimados.
○ Juicio de expertos
○ Estimación análoga (top-down): se utiliza en los comienzos del proyecto, cuando aún
se cuenta con poca información. Utiliza el costo/tiempo real de un proyecto previo y
similar, como base para la estimación del costo/tiempo del proyecto actual.
○ Estimación por 3 valores: usa un promedio ponderado de estimaciones para calcular
la duración de la actividad. Se basa en 3 valores (más probable, optimista y
pesimista).
5. Desarrollar el cronograma: se analizan las actividades, duraciones y necesidades de recursos.
Se organiza la ejecución considerando los hitos del proyecto. Identificar el camino crítico
ayuda a estimar el tiempo más corto para completarlo. El GANTT se utiliza para visualizar el
cronograma, incluso asignando roles a las tareas. El cronograma es una documentación
"viva" porque evoluciona durante el desarrollo del proyecto.
○ Entregable: objeto tangible producido como resultado del proyecto.
○ Hito

DESARROLLAR CRONOGRAMA: GANTT

Línea base: la línea base no es el camino crítico. Es la foto que le sacamos en un momento al GANTT
y a partir de ese momento empezamos a trabajar. Se define luego de la planificación. Se usa para
comparar la realidad con la planificación (compara el desempeño). Cada foto que sacamos es una
nueva línea base.

PREGUNTAS DE PARCIAL

1. Un riesgo puede ser. Seleccione una:


a. Mitigado, de manera que no ocurra.
b. Aceptado, aquellos riesgos que no puedo identificar.
c. Transferido, de manera que se elimine la responsabilidad de las consecuencias.
d. Evitado, llevando a cero la probabilidad de ocurrencia o bien eliminando el impacto.

2. La triple restricción se puede interpretar como. Seleccione una:


a. La condición por la cual un proyecto, luego de haber sido analizado de manera
óptima no puede reducir sus tiempos si no reduce el alcance o aumenta los costos.
b. La condición por la cual un proyecto, luego de haber sido analizado de manera
óptima no puede aumentar su calidad sin impacto en al menos el costo o el tiempo
planificado.
c. Todas son correctas.
d. La condición por la cual un proyecto, luego de haber sido analizado de manera
óptima no puede reducir sus costos si no reduce el alcance.

3. El monitoreo de los proyectos permite. Seleccione una:


a. Conocer el estado de situación del proyecto al momento de control.
b. Evitar los desvíos en la dedicación de recursos.
c. Todas las opciones son correctas
d. Asegurar el éxito de los proyectos.

4. La importancia de una buena definición de alcance radica en. Seleccione una:


a. Todas las opciones son correctas.
b. Permite generar un desglose de tareas que a su vez define los recursos necesarios,
cuantificar esfuerzo y secuencias.
c. Fija los requerimientos para determinar la línea base del proyecto.
d. Sienta el acuerdo entre las partes sobre aquello que estará incluido tanto funcional
como no funcional, puede incluir explícitamente aquello que no será incluido.

5. Vas a llevar a tu sobrina de 11 años a nadar a una pileta a la que concurrís regularmente
pero ella no la conoce. Identificá y evaluá tres riesgos asociados a la actividad planificada
(nombre, descripción breve, probabilidad, impacto y posible tratamiento).

Nombre: riesgo I.
Descripción: si le agarra un calambre, entonces se podrá ahogar.
Probabilidad: baja.
Impacto: severo.
Tratamiento: como tratamiento de mitigación se podría proveer un flotador.

Nombre: riesgo II.


Descripción: si abre los ojos debajo del agua con cloro, entonces sus ojos podrán irritarse.
Probabilidad: media.
Impacto: medio.
Tratamiento: como tratamiento de eliminación se podrían proveer antiparras.

Nombre: riesgo III.


Descripción: si permanece debajo del sol, podrá sufrir quemaduras.
Probabilidad: alta.
Impacto: medio.
Tratamiento: como tratamiento de eliminación se podría ir a la pileta pasadas las 5 de la tarde.
6. ¿Cuál de las siguientes afirmaciones sobre los equipos de proyecto es incorrecta?
a. El equipo de gestión del proyecto suele ser un equipo externo al equipo del
proyecto. → El PM es parte del equipo del proyecto.
b. Para proyectos más pequeños, las responsabilidades de gestión del proyecto
pueden ser compartidas por todo el equipo.
c. Para proyectos más pequeños, las responsabilidades de gestión del proyecto
pueden ser administradas únicamente por el director del proyecto.
d. Ninguna de las anteriores es correcta.

7. Indique V o F. La planificación de los riesgos se hace siempre al principio, y el plan de


mitigación y contingencia es inamovible durante toda la vida del proyecto.
Falso. La gestión de riesgos se reformula constantemente a medida que cambian las condiciones, los
riesgos, el alcance del proyecto, el presupuesto, etc.

8. ¿Cuál/es de las siguientes herramientas utilizaría para conocer el estado de un proyecto?


a. Metodología de evaluación de propuestas (MEP)
b. EVM
c. Comparación de línea base
d. Análisis de riesgos
e. Estimación Top Down
f. Benchmarking
g. Todas las anteriores
h. Ninguna de las anteriores

PREGUNTAS DE FINAL

1. Indique V o F. Los riesgos no identificados están fuera del alcance de la gestión de riesgos.
Por lo tanto, no es posible aprender de ellos.
Falso. Si bien los riesgos desconocidos no pueden ser gestionados, eso no impide a la organización
aprender de ellos una vez que se materializan para que pasen a ser riesgos conocidos y puedan ser
gestionados a partir de ese momento.

2. Seleccione las opciones correctas y justifique. Un plan de mitigación de riesgos:


a. Siempre es más costoso que un plan de contingencia porque prevé que suceda el
riesgo. Falso.
b. Siempre tiene en cuenta todos los riesgos, porque no se puede dejar nada librado al
azar. Falso ya que no se pueden tener en cuenta los riesgos desconocidos.
c. Tiene en cuenta el impacto del riesgo pero no la probabilidad de ocurrencia del
mismo. Falso, ya que la severidad se calcula como impacto * probabilidad de
ocurrencia.
d. Todas las opciones son correctas.
e. Ninguna es correcta.

3. Seleccione las opciones correctas y justifique. Estándares y normas:


a. El cumplimiento de estándares y normas por parte de un producto o servicio se
logra mediante un proceso interno que acredita su cumplimiento. Para mi es falsa
porque quien acredita que se cumple un estándar es una organización externa, como
por ejemplo acreditar que se cumple con una norma ISO.
b. Dado que resultan del análisis de múltiples experiencias exitosas en variados
escenarios, su cumplimiento asegura el resultado feliz y provee herramientas para
la mejora continua. Y, para mi por un lado es verdadera porque técnicamente uno
adopta un estándar justamente para hacer las cosas bien (entiendo yo, en forma
exitosa) y si uno sigue paso a paso el estándar entonces se supone que tiene que ser
exitoso. Pero el resuelto no la marca.
c. Tienen una enorme importancia en el aumento de interoperabilidad, efectividad y
eficiencia de toda acción repetitiva. Está rara pero creo que es verdadera porque
cuando algo es repetitivo se busca la forma de estandarizarlo para garantizar que
toda vez que se haga se haga de la misma manera y de la forma más eficaz y
eficiente posible (pero si es así no tiene sentido que la anterior sea falsa…).
d. Todas las anteriores.
e. Ninguna de las anteriores.

4. Indique V o F. Si la ejecución de un conjunto de actividades falla, no existe diferencia entre


haber aplicado una norma y no haberlo hecho ya que sigue siendo un fracaso y eso es lo
relevante para cualquier organización.
Falso. En caso de fracaso, las normas proveen herramientas para comprender las razones de la falla y
de esa forma trabajar para que no se repita.

5. Indique V o F. En una auditoría de sistemas, las evidencias están constituidas


exclusivamente por documentos que reflejan resultados obtenidos o ejecución de tareas.
Por lo tanto, las afirmaciones orales de un entrevistado, si bien dan una orientación al
auditor, de ninguna forma constituyen una evidencia válida.
Falso. Las evidencias son de diferente naturaleza. Los testimonios orales de las personas
involucradas en lo que se audita constituyen evidencia sin duda alguna. Su pertinencia y relevancia
debe (como corresponde con toda evidencia) ser evaluada por el auditor.

6. Indique V o F. La incertidumbre de un problema amerita que se deban analizar estrategias de


mitigación para reducir a un umbral aceptable su probabilidad.
Falso. Los problemas no presentan incertidumbre, son hechos ya concretados. Cuando hablamos de
incertidumbre nos estamos refiriendo a riesgos.

7. Seleccione las opciones correctas. La línea base establecida al momento de la planificación


puede servir para:
a. Ser utilizado como input para el método EVM en sus variables de PV.
b. Ayudar a aprobar un cambio de alcance ya que podremos saber el impacto en
tiempos.
c. Determinar el plan de contingencia ante un riesgo no conocido. Los riesgos
desconocidos no se pueden gestionar.
d. Todas las anteriores.
e. Ninguna de las anteriores.

8. Seleccione las opciones correctas. Estás gestionando un proyecto vinculado a la extracción


de petróleo. El proyecto es rentable con el precio actual de USD 120 el barril. Sin embargo,
es posible que el precio del barril caiga por debajo de USD 80, lo cual eliminaría la
rentabilidad del proyecto. Esto es un ejemplo de:
a. Requerimiento.
b. Supuesto.
c. Riesgo.
d. Restricción.
e. Ninguna de las opciones.

9. Indique V o F. Lograr una definición de alcance pormenorizada y minuciosa en las etapas


tempranas constituye uno de los principales factores de éxito de la gestión de proyectos.
No sé, esta pregunta me parece bastante tonta. Yo creo que definir erróneamente el alcance va a
llevar a la gestión de un proyecto al fracaso sin dudas pero definir el alcance en forma detallada y
minuciosa no garantiza el éxito de la gestión. Por lo que sí, es verdadero que el tener un buen alcance
definido en forma temprana contribuye a lograr el éxito de la gestión de un proyecto pero no la
garantiza para nada.

10. Seleccione las opciones correctas. A la hora de llevar adelante una gestión de riesgos, voy a
considerar como principales o de mayor importancia a los riesgos que:
a. Tengan mayor probabilidad de que ocurran.
b. Tengan mayor impacto.
c. Tengan mayor severidad. Esta respuesta es correcta pero como la ecuación es
Severidad = Probabilidad * Impacto, se podría pensar que las opciones a y b se
podrían considerar como correctas también. No las marco porque puede haber un
riesgo con probabilidad muy alta pero impacto nulo entonces la severidad sería baja
(o al revés, que la probabilidad sea baja) y no se lo consideraría un riesgo principal.
d. Todas las opciones son correctas.
e. Ninguna es verdadera.

11. Seleccione la opción correcta y justifique. El patrocinador de un proyecto tiene aversión al


riesgo y, por lo tanto, está preocupado por los impactos negativos en el proyecto. Para
ayudar con esta preocupación, el equipo del proyecto identifica cuatro riesgos del proyecto
y luego evalúa tanto la probabilidad de ocurrencia como el impacto del riesgo si ocurre. El
equipo usa una escala de 1 a 5, siendo 1 el más bajo y 5 el más alto.
Riesgo Probabilidad Impacto Severidad
A 2 5 10
B 4 3 12
C 3 2 6
D 2 4 8
En base a la tabla anterior, ¿en qué orden debe priorizar el gerente del proyecto estos
riesgos para fines de su gestión?
a. D-A-C-B
b. C-D-A-B
c. B-C-A-D
d. B-A-D-C
e. Todas son equivalentes en prioridad
f. Ninguna es correcta

Calculo la severidad de cada riesgo y el orden queda: B-A-D-C

12. Indique V o F. La existencia de soporte comercial de un producto de software es, en última


instancia, un mecanismo para garantizar la transferencia de responsabilidad por el
funcionamiento del mismo en un escenario de análisis de riesgo.
El resuelto dice “Es verdadero, adquirir software con soporte comercial permite que en el peor de los
casos, si algún problema existiese, el proveedor deba dar respuestas por eso. Es independiente del
análisis de riesgo que pueda hacerse o no en un proyecto”. Para mi es falso porque la responsabilidad
no se transfiere.

13. Indique V o F. Personalizar un estándar es un oxímoron (combinación en una misma


estructura sintáctica de dos palabras o expresiones de significado opuesto que originan un
nuevo sentido) modificar lo que se acuerda respetar.
Verdadero. Personalizar un estándar va a permitir la adaptación de los cambios a los objetivos de la
organización.

14. Seleccione las opciones correctas. En el contexto de la Gestión de proyectos:


a. Los riesgos pueden transferirse.
b. Si un proyecto está correctamente planificado y gestionado puede no tener riesgos.
c. Un riesgo es un evento o condición incierta que, si sucede, siempre afecta al menos
al tiempo y/o costo del proyecto.
d. Todas las anteriores.
e. Ninguna de las anteriores.

15. Indique V o F. En algunos casos, en un proyecto, es posible reducir la duración de un


proyecto manteniendo el alcance y costo sin modificaciones.
Es verdadero dado que, por ejemplo, algún supuesto que se tomó durante la planificación del
proyecto que alargaba su duración haya resultado falso (por ejemplo, algo que parecía complejo
resultó simple y rápido). O también podría haberse modificado la calidad para lograr reducir la
duración del proyecto manteniendo los costos.

Gestión ágil

PROYECTOS MODELOS DE GESTIÓN

Planificación: la representación tradicional se centra en coordinar recursos para cumplir tareas


necesarias para el logro del objetivo. La planificación ágil se centra en priorizar pequeños objetivos
del negocio de corto plazo que permitan lograr el mayor valor en el más corto tiempo.

Representación tradicional Representación ágil

Basada en Identificación inicial de las tareas. Ciclo de mejora continua (PDCA).

Control Predictivo. Empírico.

Feedback Es tardío (llega tarde, cuando el Feedback constante.


proyecto ya está en otra etapa).

Cambios Los cambios pueden comprometer Facilita el realizar cambios.


los plazos y el presupuesto del
proyecto. Las tareas no se modifican
a lo largo del proyecto.

Retrospectivas Única retrospectiva al finalizar el Realiza retrospectivas durante todo el


proyecto (post producción), con lo proyecto, de manera que se mejore la
que las lecciones aprendidas ya no productividad y calidad dentro del propio
son aplicables en el propio proyecto. proyecto.
Entregas Realiza pocas entregas de producto Entregas constantes.
durante el proyecto.

Niveles de planificación:
● Nivel estratégico: planificación de objetivos de producto (product backlog).
● Nivel táctico: planificación de tareas para la iteración en curso, en la reunión de planificación
de iteración.
● Nivel operativo: replanificaciones diarias de las tareas de la iteración como consecuencia de
las reuniones diarias de sincronización.

Participación del equipo: agile hace partícipe al equipo en el proceso:


● En la planificación (de proyecto e iteraciones). Muchas veces el que planifica no es el que
desarrolla, por lo que puede ignorar ciertos aspectos. Por esto es importante que todos
participen de esta etapa.
● En la mejora del procedimiento de trabajo (retrospectivas).

DIAGRAMA STACEY

Ejes:
● Acuerdo: refiere al acuerdo entre las partes. Ej: sobre el problema, sobre la estrategia a
implementar.
● Certeza: grado de conocimiento sobre la situación y/o sobre cómo resolverla.

DOC PREGUNTAS DESAFIANTES

1. ¿Cómo se puede gestionar eficazmente un proyecto que involucra a múltiples equipos y partes
interesadas con diferentes objetivos y prioridades?
● Comunicación efectiva: es necesario establecer un canal de comunicación claro y efectivo y
asegurarse de que todas las partes estén informadas de los avances y los desafíos del
proyecto. Además, es importante escuchar a todas las partes interesadas y tener en cuenta
sus comentarios y sugerencias.
● Establecer objetivos claros y compartidos: es fundamental que todas las partes interesadas
estén alineadas en cuanto a los objetivos del proyecto. Es necesario establecer objetivos
claros y compartidos y asegurarse de que todas las partes los comprendan y los apoyen.
Esto ayudará a evitar conflictos y a garantizar que todas las partes estén trabajando hacia un
objetivo común.
● Definir roles y responsabilidades: esto ayudará a evitar confusiones y conflictos y asegurará
que cada parte sepa exactamente lo que se espera de ella.
● Implementar una metodología de gestión de proyectos: es recomendable para garantizar la
coherencia y la calidad de la gestión del proyecto.
● Gestionar los riesgos y los problemas: es importante la identificación temprana de problemas
y riesgos potenciales y la implementación de medidas adecuadas para abordarlos.
● Fomentar la colaboración y la resolución de problemas conjuntos: esto puede incluir la
realización de reuniones conjuntas, la identificación de soluciones conjuntas a los problemas
y la celebración de eventos para fomentar la cooperación y el trabajo en equipo.

2. ¿Cuáles son las mejores prácticas para garantizar que un proyecto se mantenga dentro del
presupuesto y del plazo previsto, al mismo tiempo que se alcanzan los objetivos de calidad y
rendimiento?
● Planificación adecuada: es esencial que el proyecto se planifique adecuadamente desde el
principio. Esto incluye la definición clara de los objetivos del proyecto, el establecimiento de
un plan de proyecto detallado, la identificación de los recursos necesarios y la definición de
los hitos y plazos clave.
● Gestión efectiva del alcance: es importante para evitar cambios no planificados que puedan
afectar al presupuesto y al plazo. Esto incluye la definición clara de los requisitos y objetivos
del proyecto desde el principio, y la comunicación efectiva con todas las partes interesadas.
● Gestión efectiva de riesgos: definición de un plan detallado de gestión de riesgos y
asignación de recursos para abordar los riesgos potenciales.
● Seguimiento y control de costos: es esencial para garantizar que se mantengan dentro del
presupuesto previsto. Esto incluye la definición de un plan detallado de gestión de costos, el
seguimiento de los costos reales y la comparación con los costos planificados.
● Gestión efectiva del tiempo: es importante para garantizar que se cumplan los plazos
previstos. Esto incluye la definición de un plan detallado de gestión del tiempo, el seguimiento
del avance del proyecto y la identificación temprana de cualquier retraso potencial.
● Comunicación efectiva: incluye la comunicación regular del progreso del proyecto, la
identificación temprana de cualquier problema o riesgo potencial y la resolución de
problemas de manera colaborativa.
● Uso de herramientas y tecnologías adecuadas: utilización de software de gestión de
proyectos y herramientas de seguimiento y control de costos.

3. ¿Cómo se pueden mitigar los riesgos y los obstáculos en un proyecto, especialmente cuando
estos surgen de forma imprevista y pueden afectar el éxito del proyecto?
La gestión de riesgos es una parte fundamental de la gestión de proyectos y es importante estar
preparado para enfrentar cualquier obstáculo que surja durante el proyecto.
● Identificar y evaluar los riesgos: es importante tener un enfoque proactivo. La identificación
temprana de los riesgos puede ayudar a tomar medidas preventivas para minimizar su
impacto en el proyecto.
● Desarrollar un plan de contingencia: es un plan de acción diseñado para abordar la
materialización de los riesgos que pueden afectar el proyecto. El plan de contingencia debe
ser detallado y completo, y debe incluir medidas correctivas de la contingencia y preventivas
de sus efectos secundarios.
● Asignar responsabilidades: cada miembro del equipo debe tener responsabilidades
específicas en la mitigación de riesgos y obstáculos. Se deben establecer claramente los
roles y responsabilidades de cada miembro del equipo para garantizar que se tomen las
medidas adecuadas en caso de un riesgo u obstáculo.
● Monitorear y revisar continuamente el proyecto: debe haber un proceso de monitoreo y
revisión regular para asegurar que el proyecto siga en la dirección correcta y se tomen las
medidas necesarias para abordar cualquier riesgo o problema.
● Comunicar y colaborar con las partes interesadas: es importante mantener a las partes
interesadas informadas sobre los riesgos y los problemas del proyecto y trabajar en estrecha
colaboración con ellas para encontrar soluciones efectivas.

4. ¿Cuáles son los principales desafíos a los que se enfrentan los equipos de gestión de proyectos
en entornos ágiles y cómo se pueden superar estos desafíos?
● Cambios rápidos en los requisitos del proyecto: esto puede dificultar la planificación y la
ejecución del proyecto. Para superar este desafío, los equipos deben mantener una
comunicación abierta y regular con los clientes y las partes interesadas, y estar dispuestos a
adaptarse rápidamente a los cambios.
● Colaboración en equipo: la colaboración en equipo es esencial en los entornos ágiles, pero
puede ser difícil de lograr en entornos virtuales o en equipos distribuidos. Para superar este
desafío, los equipos deben utilizar herramientas de colaboración en línea, establecer
reuniones regulares y fomentar la comunicación abierta y transparente.
● Gestión de prioridades: esto puede ser complicado debido a la naturaleza cambiante de los
requisitos del proyecto. Para superar este desafío, los equipos deben establecer una lista de
prioridades clara y comunicarla de manera efectiva a todos los miembros del equipo.
● Adaptación a los cambios: es importante estar dispuesto a adaptarse rápidamente a los
cambios y a aprender de los errores. Para superar este desafío, los equipos deben fomentar
una cultura de mejora continua.

5. ¿Cómo se puede garantizar la calidad de los entregables de un proyecto, especialmente en


términos de cumplimiento de requisitos y satisfacción del cliente?
Esto es esencial para asegurar el éxito del proyecto y la satisfacción del cliente.
● Establecer requisitos claros: esenciales para garantizar que los entregables del proyecto
cumplan con las expectativas del cliente. Es importante que los requisitos se documenten de
manera clara y concisa y se comuniquen a todos los miembros del equipo.
● Diseñar una estrategia de prueba: ayuda a garantizar que los entregables cumplan con los
requisitos y las expectativas del cliente. Debe incluir pruebas unitarias, de integración, de
sistema y de aceptación del usuario final.
● Realizar pruebas exhaustivas: es importante para asegurarse de que los entregables del
proyecto cumplan con los requisitos y las expectativas del cliente. Las pruebas deben cubrir
todos los aspectos del entregable y realizarse de manera sistemática y rigurosa.
● Obtener retroalimentación del cliente: es esencial para garantizar su satisfacción y la calidad
de los entregables.
● Implementar un proceso de mejora continua: ayuda a garantizar que los entregables del
proyecto cumplan con los requisitos y las expectativas del cliente. Los equipos de proyecto
deben estar dispuestos a aprender de los errores y a implementar cambios para mejorar la
calidad de los entregables.

6. ¿Cuál es el papel de la comunicación efectiva en la gestión de proyectos, y cómo se pueden


superar los desafíos comunes en la comunicación entre los miembros del equipo y las partes
interesadas?
La comunicación efectiva permite que todos los miembros del equipo y las partes interesadas estén
alineados con los objetivos del proyecto, conozcan el estado del proyecto y puedan colaborar de
manera efectiva para lograr los resultados esperados. Algunos de los desafíos comunes son:
● Falta de claridad: puede llevar a malentendidos, errores y retrasos en el proyecto. Para
superar este desafío, es importante que los mensajes se transmitan de manera clara y
concisa, y que se utilicen herramientas de comunicación adecuadas.
● Comunicación insuficiente: puede llevar a la falta de información y conocimiento, lo que
puede llevar a decisiones incorrectas. Para superar este desafío, es necesario establecer una
comunicación regular y consistente, y utilizar herramientas adecuadas para la comunicación.
● Dificultades en la comunicación virtual: en un entorno de trabajo remoto, la comunicación
virtual puede ser un desafío debido a la falta de comunicación no verbal, la falta de contacto
personal y la dificultad para crear relaciones personales. Para superar este desafío, es
necesario utilizar herramientas de comunicación virtual adecuadas y establecer reuniones en
línea regulares.
● Diferentes culturas y lenguas: en proyectos internacionales, la comunicación puede ser un
desafío debido a las diferencias culturales y lingüísticas. Para superar este desafío, es
importante establecer una comunicación clara y concisa, y respetar las diferencias culturales
y lingüísticas.

7. ¿Cuáles son las mejores prácticas para la gestión del cambio en un proyecto, especialmente
cuando se trata de cambios en los requisitos, el alcance o la planificación del proyecto?
● Comunicación efectiva: es fundamental para la gestión del cambio. Es necesario comunicar a
todos los miembros del equipo y las partes interesadas los cambios que se han producido, el
impacto de esos cambios y las medidas que se van a tomar para gestionarlos.
● Planificación adecuada: es necesario planificar adecuadamente los cambios, incluyendo su
identificación, su impacto, los riesgos asociados y los recursos necesarios. Además, es
necesario establecer un proceso claro y efectivo para la gestión del cambio.
● Evaluación del impacto: es importante evaluar el impacto de los cambios en el proyecto, tanto
en términos de tiempo, recursos y presupuesto, como en términos de riesgos y calidad. Esta
evaluación ayudará a determinar si los cambios son necesarios y cómo se pueden gestionar
de manera efectiva.
● Gestión de riesgos: identificación de los riesgos, evaluación de su impacto y definición de
medidas para mitigarlos o eliminarlos.
● Gestión del alcance: definición de los requisitos, evaluación del impacto de los cambios en
los requisitos y gestión de los cambios en el alcance del proyecto.
● Seguimiento y control: asegurarse de que se gestionan de manera efectiva y se logran los
objetivos del proyecto.

8. ¿Cómo se puede garantizar la eficacia y la eficiencia en la asignación de recursos y la gestión del


tiempo en un proyecto, especialmente cuando hay múltiples tareas y prioridades a considerar?
● Identificación de los recursos necesarios: los recursos necesarios son el personal, los
materiales y los equipos.
● Priorización de tareas: es necesario priorizar las tareas según su importancia y urgencia.
● Establecimiento de plazos realistas: los plazos deben basarse en la complejidad de la tarea,
los recursos disponibles y cualquier otra limitación.
● Seguimiento y control: asegurarse de que se están cumpliendo los plazos y se está
realizando una asignación adecuada de recursos. Si hay desvíos en el avance del proyecto, es
necesario tomar medidas correctivas de manera oportuna.
● Optimización de recursos: puede incluir la reasignación de recursos según las necesidades
del proyecto y la eliminación de recursos innecesarios.
● Automatización de tareas: automatización de tareas repetitivas y de baja complejidad.

9. ¿Cómo se pueden abordar los desafíos comunes en la gestión de proyectos internacionales,


como la coordinación entre equipos ubicados en diferentes zonas horarias y culturas?
● Comunicación efectiva: establecer canales de comunicación claros y frecuentes entre los
miembros del equipo y colaboración en tiempo real.
● Definición de roles y responsabilidades: esto es especialmente importante cuando se trabaja
con equipos ubicados en diferentes zonas horarias, ya que puede haber retrasos en la
comunicación y en la toma de decisiones.
● Establecimiento de objetivos y plazos claros: esto permitirá una mayor coordinación y
colaboración entre los miembros del equipo y ayudará a evitar retrasos en el proyecto.
● Conocimiento de las diferencias culturales: permitirá una mejor comunicación y colaboración,
y evitará malentendidos y conflictos.
● Adaptación a las diferencias horarias: es posible que sea necesario ajustar los horarios de
trabajo de algunos miembros del equipo para garantizar una mejor coordinación.
● Utilización de herramientas de gestión de proyectos: permiten una mayor transparencia y
visibilidad en el progreso del proyecto.

10. ¿Cómo se puede garantizar la sostenibilidad y la continuidad del proyecto a largo plazo,
especialmente en proyectos de gran escala y complejidad?
● Planificación adecuada: definición clara de objetivos, evaluación de riesgos y elaboración de
un plan de gestión del proyecto.
● Participación de las partes interesadas: es necesario involucrar a las partes en todas las
etapas del proyecto, desde la planificación hasta la implementación y el monitoreo.
● Gestión adecuada del cambio: es necesario estar preparado para los cambios que puedan
surgir durante el proyecto y tener un plan de acción para abordarlos. Además, es importante
tener en cuenta el impacto de los cambios en la sostenibilidad y la continuidad del proyecto.
● Implementación de mejores prácticas: uso de metodologías de gestión de proyectos e
implementación de sistemas de monitoreo y evaluación adecuados, y de prácticas de gestión
de riesgos efectivas.
● Consideración de los aspectos ambientales y sociales: es necesario tener en cuenta el
impacto del proyecto en el medio ambiente y en la comunidad local, y minimizar cualquier
impacto negativo.
● Mantenimiento adecuado: establecer un plan de mantenimiento adecuado para el proyecto y
asegurarse de que se lleve a cabo de manera regular y efectiva.

Plan de negocios

BUSINESS PLAN

Definición: evaluación económica y financiera sobre cómo se va a llevar adelante un negocio.


● Económica: se refiere a si una organización gana o pierde dinero, es decir, el resultado del
ejercicio.
● Financiera: tiene que ver con la liquidez, la disponibilidad del efectivo. Tiene que ver con el
momento en que se realiza un pago o cobro, porque eso es lo que afecta la disponibilidad de
efectivo.

IMPUESTOS

Clasificación: según su aplicación:


● Directos: se aplican directamente al sujeto, gravando al sujeto.
○ Nacionales: ganancias.
○ Provinciales: no hay.
● Indirectos: se trasladan en la cadena de consumo. Gravan la transacción comercial. Gravan al
bien o servicio.
○ Nacionales: IVA, IDCB.
○ Provinciales: IIBB.

IVA: no afecta económicamente al flujo de fondos pero sí financieramente, ya que es trasladable de


un sujeto a otro en la cadena de consumo. Esto es así ya que se puede recuperar el IVA pagado en
sus compras a través de la deducción o compensación con el IVA generado por sus ventas. Sin
embargo, tiene un impacto financiero porque se debe pagar mensualmente. El IVA se considera
distorsivo porque las transacciones de compra y venta no suelen ocurrir simultáneamente.
El contribuyente actúa como prestamista para el Estado sin generar intereses, ya que debe pagar el
IVA por las compras incluso si no se realiza la venta correspondiente. Solo puede descontar el IVA de
las ventas si éstas se concretan. El IVA grava las compras y ventas generadas, independientemente
del momento de pago o cobro.
Este sistema aumenta los costos de producción debido a los costos financieros involucrados, ya que
el contribuyente debe pagar el impuesto antes de recibir los ingresos de las ventas.

Ejercicios IVA:
1. Ejemplo del alfajor I: Alfajores S.A. tiene $30 de costos directos e indirectos, más 20% de
rentabilidad: $30 + $6 = $36 → Lo que le cuesta hacer el alfajor.
Precio de venta a distribuidor: $36 + 21% (IVA) = $36 + $7,56 = $43,56
2. Ejemplo del alfajor II: el distribuidor le agrega $5 de costos directos e indirectos más 20% de
rentabilidad: $36 (no debería ser 43.56?) + $5 + $8,2 = $49,2
Precio de venta a kiosco: $49,2 + 21% (IVA) = $49,2 + 10,33 = $59,53
Lo que le debe el distribuidor al fisco (diff IVA): $10,33 - $7,56 = $2,77
3. Ejemplo del alfajor III: el kiosko (monotributista) le agrega 20% de rentabilidad: $59,53 +
$11,90 = $71,43 (el monotributista no puede agregar IVA)

Alícuota variable:
● 0%: ventas de libros, medicamentos, educación y transporte de pasajeros.
● 27%: se aplica a las ventas de gas, energía eléctrica y aguas reguladas por medidor, a quienes
presten servicios de telecomunicaciones y agencias de noticias, a quienes provean gas o
electricidad.
● 21%: si los servicios anteriores se prestan en domicilio particulares o casas de recreo o
veraneo.

Ingresos brutos (IIBB):


● Este impuesto se aplica sobre los ingresos generados por la actividad comercial o
empresarial de una persona o entidad.
● Alícuota variable: 0% a 15% (según el nivel de ingresos).
● No es trasladable. El fabricante está exento. Como se aplica sobre el total de la operación,
puede afectar significativamente la rentabilidad.

Impuesto a los débitos y créditos bancarios (IDCB, “impuesto al cheque”):


● Grava TODOS los débitos y créditos bancarios.
● Alícuota: 0,6% débitos y créditos.
● Las mutuales están exceptuadas.

Ganancias:
● Grava las ganancias (según la definición del fisco, cuidado con las amortizaciones).
● Alícuota: 35%.
● Para el fisco los bienes de uso no se consumen en su totalidad en el primer año, sino que
deben amortizarse en 10 años.
Ejemplo de primer año de actividad:
○ Ventas: $50.000.000
○ Inversión en bienes de uso: $33.000.000 → Amortización primer año: $3.300.000
○ Otros costos: $2.000.000
○ Ganancia estimada: $50.000.000 - ($3.300.000 + $2.000.000) = $44.700.000
○ Impuesto a las ganancias: $44.700.000 * 35% = $15.645.000

AMORTIZACIÓN

Definición: depreciación que sufren los bienes por su uso, obsolescencia o transcurso del tiempo. Se
contabiliza como una pérdida al depreciarse el bien. Se asocia al concepto de inversión, el cual debe
diferenciarse del concepto de gasto.
● Inversión: se resta del capital de la empresa y permite aumentar el valor productivo. Está
asociada a un bien o servicio NO consumible a corto plazo. La inversión se amortiza.
Ejemplos; patentes, rodados, maquinarias, etc.
● Gasto: se resta del capital de la empresa y NO permite aumentar el valor productivo. Está
asociado a un bien o servicio consumible a corto plazo. El gasto no se amortiza. Ejemplos:
electricidad, teléfono, sueldos, alquiler, papelería, etc.

Período de amortización:
● Herramientas: 3 años.
● Equipos de computación y accesorios de informática: 3 años.
● Rodados: 5 años.
● Equipos, aparatos e instrumental de precisión de uso técnico y profesional: 5 años.
● Equipos, aparatos e instrumental de uso técnico y profesional: 8 años.
● Muebles y útiles: 10 años.
● Maquinarias y equipos e instalaciones: 10 años.
● Inmuebles: 50 años.

LEASING

Definición: es un contrato de alquiler de un bien teniendo opción de compra del mismo al finalizar el
período de uso. Las cuotas son deducibles de impuesto a las ganancias (se considera un gasto).

COSTO LABORAL

Definición: cuánto le cuesta a un empleador tener a un empleado por mes. Está compuesto por:
Costo laboral = Sueldo Bruto + Contribuciones Patronales
● Sueldo bruto: consiste en: Sueldo Neto + Aportes y Deducciones (17-20%).
● Contribuciones patronales: carga impositiva por cuenta del empleador:
○ 20,4% para empresa categorizada como mediana, tramo 2 o superior.
○ 18% para el resto de las empresas.
○ + 6% de Obra Social.
○ Hay otros: SAC, vacaciones, lic. exámen, enfermedad, etc.

Horas efectivas de trabajo: tienen una implicancia directa en la planificación ya que la duración de las
tareas resulta del esfuerzo diario efectivo que puede entregar cada persona.

CAPEX Y OPEX
CAPEX: son todos los bienes comprados por la empresa. Como la vida de un CAPEX generalmente se
extiende más allá de un año fiscal, se debe usar la amortización y la depreciación para redistribuir
este costo.

OPEX: costo relacionado con las operaciones y servicios. Los gastos operacionales se pueden
deducir de sus impuestos durante el año fiscal en que tienen lugar.

OPEX → costo operativo


CAPEX → inversión

Ejemplo: comprar un automóvil para una empresa sería considerado como un CAPEX. Por otro lado,
un gasto único por servicios de transporte se clasificaría como OPEX.

KPIs: hacer una cuidadosa distinción entre CAPEX y OPEX es una buena forma de definir y analizar
los KPIs de su negocio, ya que esto ofrece una visión más profunda de los gastos de la empresa, lo
que ayuda al control financiero.

Diferencias: en general, la mayoría de los costos anuales de una corporación son gastos operativos.
Por lo tanto, la reducción del OPEX debe ser uno de los objetivos de la administración, siempre que
esto no comprometa la calidad de los productos y/o servicios que ofrece.

PREGUNTAS DE PARCIAL

1. Seleccionar la/las opciones correctas. A nivel impositivo, el impuesto IVA:


a. Genera una erogación económica. “Económica” es si una organización gana o pierde
dinero. El IVA se recupera entonces no es una pérdida.
b. Genera una erogación financiera. Verdadero porque el IVA se paga y cobra en
distintos momentos.
c. Afecta a los costos del consumidor final. Verdadero pues el IVA se traslada hasta él.
d. Puede generar un costo financiero significativo en las empresas. Verdadero.
e. Todas las anteriores.
f. Ninguna de las anteriores.

PREGUNTAS DE FINAL

1. El retorno de la inversión (Return Of Investment, ROI) de un proyecto se define como:


ROI = Beneficio neto obtenido / Costo total del proyecto
Por ejemplo, ROI = $25.000 / $100.000 = 0,25 ó 25%. Cuanto mayor es el ROI, más atractiva
es la inversión en el proyecto. El problema con el ROI es que no nos dice nada del tiempo.
¿Cuánto hay que esperar para que el negocio vea el retorno de la inversión? ¿6 meses, 2
años, 5 años? Además el ROI no muestra los riesgos de la inversión.
¿Qué puede hacerse para reflejar el aspecto temporal faltante? ¿Cómo influye la inflación en
lo anterior? En caso que el proyecto no sea de ejecución obligatoria (requerimiento legal,
decisión corporativa), ¿por qué realizarlo en vez de colocar la inversión a interés?
El tiempo se refleja mediante el período de repago (Payback Period): plazo en el cual se recupera la
inversión. Por ejemplo si invertimos $1.000.000 y obtenemos un beneficio neto anual de $250.000, el
período de repago es 4 años.
Esta es una foto estática. Cada año que pasa, tanto la inversión inicial como el beneficio aumentan su
valor nominal. Agreguemos que la inversión puede desplegarse en diferentes momentos y esto está
afectado por la inflación.
Respecto de la comparación con otras alternativas, hay que pensar si nos conviene invertir en el
proyecto o poner ese dinero a plazo fijo durante el período de repago. Existen fórmulas que ajustan el
período de repago descontando el efecto del valor del dinero.

2. Cuando se realiza un análisis de costo de un proyecto de IT, hay que considerar:


a. El capital inicial, flujo de ingresos y egresos.
b. La infraestructura necesaria para poder implementar el proyecto.
c. Los costos de cada rol del proyecto (técnico y no técnico), por ej: RRHH, gestión de
proyecto y developers, entre otros.
d. Todas las anteriores.
e. Ninguna de las anteriores

3. En TI, las diferencias entre la compra de activos y la contratación de servicios consiste en:
a. Activar el equipamiento patrimonialmente vs. imputar el gasto. Verdadero. Adquirir
el equipamiento permite incrementar el patrimonio (CapEx) y contratar el servicio
implica incurrir en gastos (OpEx).
b. Asumir el control total de los componentes adquiridos vs. transferir los riesgos por
la prestación. Verdadero. Es importante aclarar que se transfiere el riesgo pero no la
responsabilidad.
c. Descontar impositivamente la amortización del bien vs. descontar el costo del
servicio como pérdida. Verdadero.
d. Realizar una compra mediante licitación vs. realizar la contratación directa del
servicio a un proveedor. Falso. En cualquiera de las circunstancias se puede usar
cualquiera de las 4 formas de contratación vistas.
e. Ninguna de las anteriores

4. Las diferencias económicas/financieras entre comprar un inmueble para ser utilizado como
oficina y alquilarlo implica:
a. Aumenta la inversión inicial. Verdadero. Adquirir un inmueble representa una
inversión.
b. Aumentan los costos operativos. Falso. Esto sería verdadero si se lo alquila.
c. Tiene un costo de salida más alto
d. Aumentan los costos fijos
e. Todas las anteriores

EVM y métricas ágiles

GESTIÓN DEL VALOR GANADO (EVM)

Definición: es un método para el seguimiento y control de proyectos. Integra alcance, cronograma y


costos para medir el rendimiento y el avance del proyecto en forma objetiva. Se requiere contar con la
siguiente información:
● Presupuesto del proyecto.
● Duración del proyecto.
● Estimación del trabajo entregado en cada período del proyecto.
● Estimación de costo y duración restante al finalizar cada período del proyecto.
● Al final de cada período, datos de costo incurrido, incluyendo el trabajo no finalizado.

Variables principales:
● Valor planeado (PV): es cuánto yo estimaba que iba a gastar para cierto momento.
● Costo real/costo acumulado (AC): es efectivamente el costo incurrido para el trabajo
realizado. Lo que en efecto me costó.
● Valor ganado (EV): costo del trabajo realizado pero calculado con los valores establecidos en
el presupuesto.

Rendimiento y avance:
● Rendimiento: es la comparación entre el EV y el AC (costo presupuestado vs. costo real).
Representa lo que llegué a generar en función de cuánto me costó hacerlo.
● Avance: es la comparación entre el EV y el PV. Cuánto llegué a hacer contra lo que había
planificado.

Variables secundarias:
● BAC (presupuesto del proyecto): costo total previsto inicialmente para el proyecto.
● ETC (estimación para finalizar): es cuánto estimo que me falta gastar ($$$) para terminar. La
diferencia con el EAC es que el EAC es lo que estimo que va a ser el costo TOTAL del
proyecto.
● EAC (estimado a la conclusión (AC + ETC)): es cuánto estimo que va a ser el costo total a la
finalización del proyecto. Para calcular el EAC es necesario re-estimar el costo del proyecto
durante su ejecución. Se espera que esta estimación sea más certera que la inicial (BAC) ya
que estima un período más corto. El valor de EAC depende de ETC y éste de la forma en la
que consideremos que será el desempeño en lo que resta del proyecto. Lo que realmente
gasté + lo que estimo que voy a gastar para terminarlo.
● VAC (variación a la conclusión): es la diferencia entre el BAC y el EAC. Es el desvío en el costo
total del proyecto.

Fórmulas de indicadores:

Descripción Fórmula

Variación de costos CV = EV - AC

Variación de cronograma SV = EV - PV

Índice de desempeño de cronograma SPI = EV/PV


SPI > 1 → Estoy adelantado
SPI < 1 → Estoy atrasado

Índice de desempeño de costos CPI = EV/AC


CPI > 1 → Está por debajo del costo
CPI = 1 → Está exactamente en el presupuesto
CPI < 1 → Está por encima del costo

Variación a la conclusión VAC = BAC - EAC

Desempeño de costos requeridos para finalizar TCPI = (BAC - EV)/(BAC - AC)


dentro de BAC o EAC Si hay un nuevo presupuesto:
TCPI = (BAC - EV)/(EAC - AC)

Desempeño del tiempo requerido para finalizar TSPI = (BAC - EV)/(BAC - PV)
dentro del cronograma

Estimado a la conclusión (EAC = AC + ETC)


Desempeño típico: la performance de costos EAC = BAC/CPI
observada hasta el momento se mantendrá
hasta la finalización del proyecto (es decir, nos
vamos a extender sobre el presupuesto original
si venimos gastando de más o vamos a quedar
por debajo si venimos gastando menos)

Desempeño atípico: la performance de costos 𝐸𝐴𝐶 = 𝐴𝐶 + (𝐵𝐴𝐶 − 𝐸𝑉)


observada hasta el momento ha sido La fórmula es muy fácil de entender.
excepcional y no se mantendrá de aquí en Básicamente estamos reemplazando en el BAC
adelante sino que la eficiencia de costos el EV por el AC. Es decir, lo que estimamos (EV)
corresponderá a lo planificado (pero igual puede no lo cumplimos, lo cambiamos por lo que
ser que nos pasemos del presupuesto original si gastamos en realidad (AC) pero el desempeño a
ya gastamos de más) partir de acá va a volver a lo planificado.

Cambio a desempeño diferente: la performance 𝐵𝐴𝐶 − 𝐸𝑉


𝐸𝐴𝐶 = 𝐴𝐶 + [ ]
de costos observada hasta el momento no se 𝐶𝑃𝐼𝑛𝑢𝑒𝑣𝑜
mantendrá. De aquí en adelante habrá una
diferente. Si el nuevo CPI debe permitir concluir el
proyecto dentro del BAC:
𝐵𝐴𝐶 − 𝐸𝑉
𝐶𝑃𝐼𝑛𝑢𝑒𝑣𝑜 = [ 𝐵𝐴𝐶 − 𝐴𝐶 ]

Si el nuevo CPI estará afectado por la


performance de cronograma observada:
𝐶𝑃𝐼 𝑛𝑢𝑒𝑣𝑜 = 𝐶𝑃𝐼 * 𝑆𝑃𝐼

Nueva estimación detallada: los desvíos en la 𝐸𝐴𝐶 = 𝐴𝐶 + 𝑁𝑢𝑒𝑣𝑎 𝐸𝑠𝑡𝑖𝑚𝑎𝑐𝑖ó𝑛


performance son atribuibles a una mala
estimación o las condiciones del proyecto han
cambiado significativamente por lo que los
supuestos de la estimación original no resultan
válidos. Para lo que resta del proyecto se debe
realizar una nueva estimación detallada.

Plazo

Si suponemos que la variación del cronograma EACt = Plazo original * (BAC - SV) / BAC
fue atípica (y el resto del
proyecto será como originalmente planeado)

Si suponemos que la variación del cronograma EACt = Plazo original / SPI


fue atípica y se mantendrá

Cálculo de PV o EV en tareas incompletas: para las tareas que se encuentran en curso al finalizar un
período, se deben estimar los valores de PV y EV. Cuando no se cuenta con una estimación confiable
para el avance de esas tareas, existen diferentes criterios basados en porcentajes de avance fijos que
asignan al inicio una porción del valor de PV para la tarea y completan el resto cuando finaliza la
tarea.
● Método 0/100: considero sólo las tareas que están terminadas.
● Método 50/50: considero tareas completas y las que están iniciadas pero no completas, al
50%.
● Método 25/75: considero las que inicié y las completas.

ESTADO DEL PROYECTO


Definición: se mide en dos dimensiones: costos y cronograma.

Lo bueno, lo malo y lo feo de esta metodología:


● Lo bueno: conecta alcance, cronograma y costos. No sólo observa los costos planificados y
reales, sino también el trabajo planificado y el real.
● Lo malo: las métricas no indican cuáles son las acciones apropiadas que deben tomarse. Es
menos efectivo que CPM para evaluar el estado del cronograma y estimar la fecha de
finalización.
● Lo feo: es esencial comprender que algunas variaciones son inherentes y tratar de corregirlas
puede tener consecuencias negativas. En lugar de ello, se deben enfocar los esfuerzos en
controlar y evitar las causas de variación que se pueden manejar, permitiendo así un mejor
desempeño del proyecto.

EVM Y AGILE

Gestión agile Seguimiento y control con EVM

Alcance Flexible. Establecido en la línea base y se


controla.

Cronograma Fijo. Cada paquete finaliza cuando se


completa el trabajo del mismo.

Planificación Se planifica a último momento Se planifica todo el proyecto


(antes de que comience el antes de iniciarlo.
siguiente sprint).

Presupuesto No suele ser la prioridad. Establecido en la línea base.

Obtención de datos de No es obligatorio. Es crítico.


costos durante la ejecución

Puntos de contacto entre agile y EVM:


● En el enfoque ágil, es importante asegurarse de tener una planificación inicial sólida y de
calidad (línea base), ya que esto influirá en gran medida en el éxito general del proyecto.
● Agile permite dimensionar el proyecto y obtener presupuesto para el mismo pero no permite
definir el alcance porque los requerimientos cambian constantemente. En cambio, el proyecto
con gestión tradicional sí lo permite.
● La aplicación directa de EVM en proyectos ágiles probablemente resultará en un Valor
Planificado (PV) determinado al inicio del proyecto, que será inválido durante la ejecución del
proyecto que requeriría varias nuevas líneas de base.

Enfoque: lo primero es tomar un marco temporal que permita hacer proyecciones, es decir, debe tener
un alcance definido como para que sea relevante hacer proyecciones (en general se toman varios
sprints, un release).

Relación entre tamaño, velocidad y duración:

EVM tradicional vs. ágil:

Concepto EVM tradicional EVM ágil

BAC Presupuesto del proyecto Presupuesto del release

Baseline Valor planeado para cada período del Cantidad de puntos (y su equivalente
proyecto presupuestario) que deben completarse
en cada sprint.

PV Costo presupuestario del trabajo que Cantidad de puntos que deben


espera realizarse para un momento del completarse al finalizar un sprint
proyecto

EV Costo presupuestario acumulado del Cantidad de puntos acumulados que se


trabajo realizado para un momento del completaron al finalizar un sprint
proyecto

AC Costo real del trabajo realizado Costo real acumulado de los puntos
acumualdo para un momento del proyecto completados al finalizar un sprint

CPI Cuánto se obtiene por unidad de costo Cuánto se obtiene por unidad de costo
comparado con el estimado comparado con el estimado
originalmente: EV ÷ AC originalmente: (costo estimado/pto) ÷
(costo real/pto)

SPI Tasa de avance lograda en comparación Tasa de avance lograda en comparación


con el cronograma original: EV ÷ PV con el cronograma original: (cant. de ptos
entregados) ÷ (cant. estimada de ptos)

Cálculo de línea base:


1. Cantidad de sprints planificados para un release.
2. Cantidad de días calendario que dura un sprint.
3. Cantidad de puntos planificados para un release.
4. Monto del presupuesto definido para un release.
5. Fecha de inicio del proyecto.

Mediciones necesarias:
1. Cantidad de puntos completados.
2. Cantidad de iteraciones completadas.
3. Costo real acumulado.
4. Cantidad de puntos agregados y quitados del plan de release.

Burn down chart: representación descendente de los story points que restan completar. Este gráfico
no muestra el alcance del proyecto, por lo que puede mostrar que la performance del equipo no es
buena cuando en realidad el problema podría estar en un incremento del alcance.

Burn up chart: muestra la información en base al avance de abajo hacia arriba. Consta de tres líneas:
alcance, avance planificado y avance real. Muestra una ventaja importante al permitir separar el
alcance del avance.

PREGUNTAS DE PARCIAL

1. Dado un proyecto que cuenta con un presupuesto de USD 575.000 y en el cual el trabajo
realizado hasta el momento ha costado USD 252.000 aunque su valor presupuestario es de
USD 230.000, se cuenta con una reserva de gestión de USD 35.000 de la que se
comprometieron o utilizaron USD 8.000. En vista de la performance de costo observada, se
ha decidido utilizar la reserva de gestión disponible.
¿Cuál deberá ser la performance de costo sobre el trabajo remanente para poder finalizar el
proyecto con el costo total acordado?
2. Dado un proyecto que cuenta con un presupuesto de USD 575.000 y en el cual el trabajo
realizado hasta el momento ha costado USD 252.000 aunque su valor presupuestario es de
USD 230.000, ha sido autorizado un incremento de USD 27.000 sobre el costo total del
proyecto. ¿Cuál deberá ser la performance de costo sobre el trabajo remanente para poder
finalizar el proyecto con el costo total autorizado?

BAC = $575.000
AC = $252.000
EV = $230.000
Incremento = $27.000 → EAC = BAC + Incremento = $575.000 + $27.000 = $602.000

TCPI = (BAC - EV) / (EAC - AC) (porque hay nuevo presupuesto)


TCPI = (575.000 - 230.000) / (602.000 - 252.000)
TCPI = 0,9857

3. Dado un proyecto para desarrollar e instalar 11 drivers de impresoras en 22 semanas (1


driver cada 2 semanas) con un presupuesto de 99.000$ (9000$ por driver), cuando se ha
finalizado la instalación del 6° driver, se llevan gastados 60.000 $,y la partida presupuestaria
correspondiente es de 63.000$.
¿Qué conclusiones saca del estado del proyecto?
¿De continuar la performance observada, cuánto tiempo se prolongará el proyecto después
de la duración planificada y cuál será el costo excedente?

BAC = $99.000
AC_al_dia_x = $60.000 (6° driver)
PV_al_dia_x = $63.000

----------------------------------------
$99.000 → 11 drivers
$63.000 → x = 7 drivers → Esperaban ir por el 7mo driver
----------------------------------------

CPI = EV_6_drivers / AC = 6 * $9.000 / $60.000 = 0,9 → está por encima del costo.
SPI = EV / PV = 6 * $9.000 / $63.000 = 0.86 → está atrasado.

EAC = BAC / CPI = $99.000 / 0,9 = $110.000

Cada driver costó $1.000 más de lo planificado, por lo que el excedente total fue de $110.000 -
$99.000 = $11.000.

EAC(t) = semanas planificadas / SPI = 22 / 0,86 = 25,6 semanas totales

Excedente: 25,6 - 22 = 3,6 semanas.

4.
a. Tomando BAC = 12.
EAC = BAC/CPI = BAC * AC/EV = 12 * (8/4) = 24
b. SV = EV - PV = 4 - 4 = 0. En Abril el proyecto estaba respetando el cronograma.
c. Si EV > PV → SPI > 1 está adelantado en cronograma.
Si EV > AC → Está por debajo del costo.
Si EV < AC → Está por encima del costo.
d. No se produjo nada en ese período.
e. Implica que se cumplió con lo que se quería producir pero se excedió en los costos.

5. Usted está evaluando el rendimiento de un proyecto y posee los siguientes datos PV = 3000,
AC = 2000 y EV = 2500. ¿Qué puede afirmar de este proyecto?
a. El CV es un número positivo, lo que significa que se ha gastado más de lo
planificado gastar al momento del control.
CV = EV - AC = 2500 - 2000 = 500. Falso, no se gastó más.
b. El ETC es un número positivo, que significa que el proyecto se terminará por debajo
del presupuesto.
Falso. No hay forma de saberlo basándonos simplemente en la positividad del
resultado.
c. El SV es un número positivo, lo que significa que se ha gastado menos de lo
planificado gastar al momento del control.
SV = EV - PV = 2500 - 3000 = -500. Falso.
d. No tiene suficiente información para calcular el SPI por lo tanto no puede opinar
sobre el estado del proyecto.
SPI = EV / PV = 2500 / 3000 = 0,84 < 1 → está atrasado. Falso. Se puede calcular el
SPI.
e. Ninguna de las anteriores.

6.
a) Falso. No podemos inferir lo que pasa en la actualidad de manera certera en base a datos
anteriores.
b) Falso. EV < PV, no al revés.
c) Verdadero.
d) Falso. No podemos afirmar el estado actual del proyecto basándonos en datos pasados.

PREGUNTAS DE FINAL

1. Usted es el PM de un proyecto que consiste en instalar servidores on premise en distintas


ubicaciones físicas. Se deben instalar dos servidores por mes durante 18 meses. Cada
instalación tiene un costo planificado de $200.000. Es el comienzo del mes 15, se han
instalado 30 servidores y el CPI es 0,9.
a. ¿Cuál es el estado del proyecto?
b. ¿Cuál es el costo real del proyecto en este momento?
c. Suponiendo que la variación de costo experimentada hasta ahora continuará,
¿cuánto dinero adicional se necesitará para completar el proyecto?
d. Si la variación experimentada hasta ahora se detuvo, ¿cuál es la estimación del
proyecto al finalizar?
e. La gerencia quiere conocer el porcentaje del proyecto que se ha completado, ¿qué
se debe informar?
(Las respuestas están chequeadas)

Datos:
● Cronograma: 18 meses
● Objetivo: 36 servidores (2 x mes)
● Costo total: $7.200.000 ($200.000 x instalación)

Al comienzo del mes 15:


● 30 servidores instalados
● CPI = 0,9

a. Estado del proyecto:


CPI < 1 → Está por encima del presupuesto establecido
SPI = EV/PV = (30 servers * $200.000/server) / (28 servers * $200.000/server) = 1,071 → Está
adelantado en cuanto a cronograma

b. Costo real al comienzo del mes 15


CPI = EV/AC
AC = EV/CPI
AC = $6.000.000 / 0,9 = $6.666.667

c. Dinero adicional para completar el proyecto si la variación continúa:


EAC = BAC/CPI
EAC = $7.200.000 / 0,9 = $8.000.000

Dinero extra que se necesita: |BAC - EAC| = |$7.200.000 - $8.000.000| = $800.000

d. Estimación del proyecto al finalizar:


Entonces a partir del mes 15 vamos a empezar a regirnos por lo que estaba planeado pero en los
primeros 15 meses ya nos pasamos del presupuesto, así que el EAC que obtengamos ahora va a
tener que ser mayor al BAC:

EAC = AC + (BAC - EV)


EAC = $6.666.667 + $7.200.000 - $6.000.000
EAC = $7.866.667

e. Porcentaje:
36 servers _ 100%
30 servers _ x = 3000 / 36 = 83,33%

2. EVM establece dos indicadores de performance de lo realizado: uno de cronograma (SPI) y


otro de costos (CPI). Para la proyección de lo que resta del proyecto se define el índice de
performance a la completitud (To Complete Performance Index, TCPI) el cual fija la
performance de costos que un proyecto debe lograr sobre el trabajo restante para alcanzar
un resultado final específico.
Ese resultado final del proyecto podría ser el presupuesto actual al finalizar (BAC), el
estimado al finalizar (EAC) (actual o nuevo) o incluso una meta de resultado final
especificada por la gerencia. Si bien este indicador se refiere a performance de costos, este
aspecto no se refleja en su nombre. ¿Cómo puede definirse un indicador análogo para
cronograma (To Complete Schedule Performance Index, TCSPI)? Justifique.
3. Seleccione las opciones correctas. Se está analizando con el método de EVM el desarrollo
del proyecto desde su inicio a la fecha (semana 10 de 15). Según el gráfico se puede decir
que:
a. El proyecto está dentro del presupuesto y si mantiene la tendencia terminaría dentro
del mismo.
b. Se está trabajando más rápido de lo planificado.
c. El proyecto está adelantado y por debajo del presupuesto. No está por debajo del
presupuesto, está gastando lo presupuestado.
d. Todas las anteriores
e. Ninguna de las anteriores
Análisis del gráfico: SPI > 1 quiere decir que el proyecto está adelantado en cuanto a cronograma. CPI
= 1 quiere decir que el proyecto está dentro del presupuesto planteado.

4. Seleccione la opción correcta y justifique. El siguiente diagrama de Gantt muestra el


cronograma de un proyecto de actualización de software. La etapa del Análisis se completó
el 18 de marzo, pero Diseño y desarrollo todavía están en curso al 6 de mayo. Una vez que el
producto esté desarrollado, el equipo de proyecto tendrá que probarlo y desplegarlo, lo cual
debe finalizar el 20 de mayo.

El método para determinar el valor ganado es por el porcentaje de avance. ¿Cuál es la


variación de costo (CV) al 6 de mayo?
a. USD 650
b. USD 3750
c. USD 650
d. USD 3150
e. Ninguna de las opciones es correcta

Tareas:
Análisis (100%) AC = 600 USD (dato) EV = 500 USD (100% del PV)
Diseño (75%) AC = 500 USD (dato) EV = 750 USD (75% del PV)
Desarrollo (50%) AC = 2000 USD (dato) EV = 2500 USD (50% del PV)

CV = EV - AC
CV = (500 + 750 + 2500) USD - (600 + 500 + 2000) USD
CV = 3750 USD - 3100 USD
CV = 650 USD

5. Indicar V o F. Si el costo acumulado real de un proyecto ha sido mayor que el costo


acumulado planeado el proyecto va mal.
Lo que dice la afirmación es que si AC > PV. Esta afirmación es falsa dado que puede ser que el
proyecto esté adelantado y por eso se gastó más. La afirmación es verdadera para AC > EV.

6. Seleccionar las opciones correctas. EVM es un método muy potente para hacer el
seguimiento y control del proyecto. Entre sus principales ventajas están:
a. No resulta una carga operativa adicional para el PM ya que utiliza variables
conocidas y de uso diario. Falso, sí es una carga operativa para el PM.
b. Considera explícitamente los riesgos identificados para el proyecto. Falso, EVM no
considera riesgos.
c. Toma en consideración el camino crítico. Falso.
d. Todas las anteriores.
e. Ninguna de las anteriores.

7. Seleccionar las opciones correctas. Aplicando la técnica de EVM, si el proyecto a la fecha


tiene un valor ganado que es superior al costo actual y el AC es menor que el PV, entonces
puedo afirmar que:
a. El proyecto tiene costos menores que lo planificado para las tareas realizadas.
b. El proyecto se encuentra adelantado si PV es menor que el valor ganado. Si PV < EV,
entonces SPI = EV/PV = 1,... por lo que el proyecto estaría adelantado.
c. El proyecto terminará antes de tiempo No podemos afirmarlo
d. El proyecto terminará con ahorro de costos. No podemos saberlo porque el
enunciado no dice cómo será la performance en el futuro.
e. Ninguna de las anteriores
Lo que pregunta el ejercicio es qué sucede si EV > AC y AC < PV
Primero, si EV > AC, quiere decir que estamos por debajo del presupuesto, es decir, gastamos menos
de lo que esperábamos gastar (CPI = EV/AC = 1,...)
Ahora, si AC < PV, esto quiere decir que si para cierto momento habíamos planificado gastar una
cantidad X (PV), lo que realmente gastamos es menos (AC). Tiene sentido con el dato calculado
anteriormente aunque no sabemos qué está pasando con el cronograma.

Yo lo resolví así pero el resuelto pone que la a es falsa porque: “Solo se puede afirmar si el valor
ganado es superior al PV o bien la diferencia en costo es mayor que la diferencia en trabajo no
realizado a la fecha (en caso que EV < PV)”. No entiendo.
También pone que la b es falsa porque: “Solo podemos asegurar que está adelantado si EV > PV” que
es lo que plantea el ejercicio…

8. Seleccionar las opciones correctas. La implementación de la metodología EVM durante la


ejecución de un proyecto nos permite:
a. Determinar el estado de avance de un proyecto para un momento futuro. EVM te
permite estimar cuál será el costo al finalizar el proyecto y cuál será el cronograma si
se sabe cómo va a ser la performance a futuro. El profesor la marca como falsa
porque no permite “determinar” algo futuro… para mi es obvio que siempre hablamos
de estimaciones y que ninguna herramienta o método te va a decir el futuro y por eso
la hubiera marcado como verdadera pero bueno.
b. Proyectar el estado de costos a un momento futuro basado en el historial. Por la
justificación anterior, esta es verdadera.
c. Determinar el estado financiero del proyecto en el momento actual. Falso, no evalúa
información financiera.
d. Detectar desvíos de la planificación de costos. Verdadero, permite detectar desvíos
hasta el momento de corte de ejecución.
e. Determinar la performance de los empleados afectados a cada tarea. Falso, no es
una herramienta para evaluar empleados.
f. Ninguna de las anteriores.

9. En la técnica de medición de performance de proyectos (EVM):


a. Defina qué tipo de proyectos y/o en qué casos recomendaría la implementación de
la misma
b. Justifique: el CPI nos permite, en un determinado momento de evaluación, obtener
una medida relativa de la aplicación de fondos respecto de los flujos planificados
para el proyecto.
c. Determine y explique: cuál es la relación que nos permite obtener el estado de
avance respecto del cronograma del proyecto.
a. Proyectos donde pueden planificarse todas las actividades con razonable certidumbre
(tiempo y costo). En general no resulta adecuada para proyectos ágiles.
b. Verdadero. El CPI es un índice del desempeño de costos (de este no tengo la respuesta
correcta).
c. El SPI es un indicador que nos permite conocer el desempeño del cronograma. SPI = EV / PV

10. Una dependencia del Estado Nacional cuenta con un presupuesto de $30.000.000 para el
año en curso destinado al programa de apoyo a pequeñas unidades productivas.
Transcurridos 9 meses del año se han desembolsado $15.000.000 y se estima que en los
siguientes 12 días se pagarán $5.000.000 adicionales. De todos modos, los responsables de
los proyectos involucrados reclamaron haber incurrido en mayores costos (lo que fue
reconocido) y los desembolsos a la fecha indicada corresponderán al 90% del alcance
correspondiente a ese momento. Suponiendo que esto efectivamente se concrete y bajo un
enfoque de gestión de valor ganado:
● ¿Cuál es el estado del programa proyectado a esa fecha (9M + 12d)?
● De continuar el ritmo de ejecución proyectado a esa fecha, ¿qué monto total se
desembolsará y qué porcentaje de ejecución del alcance acordado se alcanzará a fin
de año?
● Si la proyección a fin de año no fuera del 100%, ¿qué ritmo de desembolso y de
concreción de alcance acordado debería aplicar en el resto del año (es decir, a partir
de 9M + 12d) para lograrlo?

Métricas, KPIs, CSFs y OKRs

MEDICIÓN Y ANÁLISIS

Medición: “medición es la reducción de la incertidumbre expresada cuantitativamente y basada en


una o más observaciones” - Teoría de la información de Shannon.
Este punto de vista es crítico para el negocio ya que las decisiones más importantes tomadas bajo un
estado de incertidumbre pueden mejorarse mediante la reducción de la incertidumbre.
La incertidumbre del observador puede cambiar como resultado de las observaciones. Por esto
tratamos la incertidumbre como una característica del observador, no necesariamente del objeto
observado.
Una medición no es opinable. Es objetiva y permite a los líderes tomar decisiones más acertadas.

Propósito: desarrollar y sostener las mediciones para satisfacer las necesidades de información de
gestión. Las mediciones son sólo herramientas. No deben convertirse en el objetivo. También hay que
tener cuidado con la sobre-información.

Tipos de métricas (asociadas al producto):


● Métricas vanidosas: están maquilladas para parecer que todo va bien. Utilizadas en
presentaciones cuando hay que vender/promocionar un producto. Se centran en el progreso
del proyecto y dejan de lado las demás cosas que no muestran lo positivo del producto.
● Métricas accionables: son métricas más “reales” y crudas que orientan a la acción. Con estas
métricas un líder puede realizar ajustes y aprender de los errores que se han cometido.
Cómo definir buenas métricas:
● Comparativa: debo tener una unidad de medida que permita ver una tendencia en el tiempo.
● Comprensible: por quien realiza la métrica.
● Debe guardar relación: contextualizarla. Ejemplo: “es más alto en relación a alguien”.

Categorías de mediciones:
● Cumplimiento (compliance): las métricas de compliance determinan si el proceso se está
realizando según lo documentado en las políticas y procedimientos.
○ Se pueden identificar los incidentes que no se registraron, mirando los datos de
Gestión de Problemas y Gestión de Cambios.
○ Porcentaje de cambios liberados dentro de la ventana de aprobación.
○ Porcentaje de servicios con SLAs.
● Calidad: se utilizan para medir cuán bien se hace algo.
○ Porcentaje de incidentes mal asignados.
○ Porcentaje de incidentes no cerrados luego de marcarse como “resueltos” (debido al
feedback del usuario que indica la persistencia de la dificultad).
● Rendimiento: demuestran qué tan rápido o lento está sucediendo algo.
○ Tiempo medio de resolución de incidentes.
○ Porcentaje de incidentes resueltos dentro de los plazos acordados.
○ Tiempo medio para realización de sesión de análisis de causa raíz luego de la
identificación del problema.
● Valor: es una de las categorías de KPI más poderosas porque esta es la verdadera medida de
lo que genera el proceso. El valor es difícil de definir ya que es el cliente quien generalmente
lo determina. Por lo tanto, debe entenderse quién está recibiendo el resultado del proceso y
las métricas de valor deben considerar el resultado desde su punto de vista.
○ Satisfacción del usuario posterior a la resolución de incidentes.
○ Porcentaje de incidentes abiertos por una herramienta de monitoreo y resueltos
antes de que impacte en los usuarios.

Indicadores: una medición entrega un número, pero, ¿qué quiere decir ese número? Acá es donde
entran en juego los indicadores. Hay que convertir la medición en un indicador. Si el tanque del auto
mide x litros restantes, nosotros quizás no sabemos qué significa esa medición pero vamos a tener
un indicador que nos diga “el nivel es bajo” o “el tanque está lleno” en función de la medición. Es decir,
el indicador brinda contexto a la medición. Un indicador es un KPI.

Cómo:
● Especificar objetivos de medición alineados con las necesidades de información.
● Especificar mecanismos para la recolección y almacenamiento de datos.
● Proveer resultados objetivos para la toma de decisiones y toma de acciones correctivas.
● Automatizar la captura, procesamiento, análisis e informe.

CRITICAL SUCCESS FACTOR (CSF) Y KEY PERFORMANCE INDICATOR (KPI)

CSFs: algo que debe suceder para que un servicio, proceso, plan o proyecto tenga éxito.

KPI: son métricas utilizadas para ayudar a gestionar una actividad y lograr cumplir los CSFs. Permiten
ver el día a día de un negocio. Pueden utilizarse muchas métricas, pero solo las más importantes se
definen como KPIs. Un KPI debe ser SMART:
● Specific.
● Measurable.
● Achievable.
● Relevant.
● Timely.

Hoja de KPI: debe incluir la siguiente información:


● Nombre del KPI: palabra o frase que lo describe.
● Dueño del KPI: ¿quién es el responsable de obtener los resultados esperados del KPI?
● Frecuencia o intervalo de cálculo: ¿cuán a menudo se calcula (mensualmente,
trimestralmente, anualmente)?
● Categoría: cumplimiento, calidad, rendimiento o valor.
● Meta del KPI: ¿qué es un buen resultado?
● Fuente de datos/procedimiento/definición: ¿de dónde vienen los datos?
● Cálculos a realizar: ¿qué cálculos se realizan con los datos para obtener el KPI?
● Informes: ¿cuándo, cómo, a quién se informa?

Cálculo de progreso del proceso: una vez que los KPIs se definen en una hoja, el KPI se calcula y se
establece una "puntuación" midiendo el progreso hacia el objetivo definido. Por ejemplo, si el objetivo
es que el 90% de los incidentes se resuelvan dentro de su tiempo objetivo y el 85% lo cumplió, se
puede calcular que el KPI obtuvo un 94%.

Relación entre KPIs, CSFs y objetivo: se deben elegir CSFs que se alineen con los objetivos definidos
del proceso y que estén respaldados por KPIs.

OBJECTIVES AND KEY RESULTS (OKRs)

Introducción: los OKRs son una forma de abordar la medición y el análisis. Es un enfoque para crear
alineamiento y compromiso en torno a objetivos medibles y ambiciosos. Los OKR se establecen,
monitorean y evalúan con frecuencia (trimestralmente), a diferencia de los métodos tradicionales. Se
adaptan a los cambios.

Objetivo: descripciones cualitativas de qué se quiere lograr, a dónde nos gustaría ir. Debe ser:
● Significativo (tiene sentido).
● Concreto.
● Orientado a la acción.
● Inspirador.
Se considera óptimo alcanzar el 60-70% de cada objetivo.

Resultado clave (key results): métricas que miden cómo avanzamos hacia el objetivo. Debe ser:
● Específico y limitado en el tiempo.
● Agresivo y realista.
● Medible y verificable.

Iniciativa: descripción de acciones para acercarnos al destino deseado.

Características:
● Objetivos ágiles: en lugar de utilizar una planificación estática anual, OKR adopta un enfoque
ágil. Mediante el uso de ciclos de objetivos más cortos, las empresas pueden adaptarse y
responder al cambio.
● Simplicidad: el uso de OKR es sencillo y los propios OKRs son fáciles de entender.
● Transparencia: el propósito principal de OKRs es crear alineamiento en la organización. Los
OKRs son públicos para todos los niveles de la empresa.
● Ritmos anidados: OKR entiende que la estrategia y la táctica tienen ritmos naturales
diferentes, ya que esta última tiende a cambiar mucho más rápido. Para solucionar esto, OKR
adopta diferentes ritmos:
○ Estratégico: OKRs de alto nivel y largo plazo para la empresa (generalmente anuales).
○ Táctico: OKRs a más corto plazo para los equipos (generalmente trimestrales).
○ Operativo: para el seguimiento de resultados e iniciativas (generalmente semanal).
● Establecimiento de objetivos bidireccionales: en lugar de utilizar el modelo en cascada, OKR
utiliza un enfoque basado en el mercado que es simultáneamente de abajo hacia arriba y de
arriba hacia abajo.
● Objetivos ambiciosos: la filosofía detrás de OKR es que si la empresa siempre está
alcanzando el 100% de las metas, son demasiado fáciles.
● Desacoplamiento de recompensas: separar los OKR de compensaciones y promociones. Los
empleados deben saber que no perderán compensaciones si establecen metas ambiciosas y
luego no las cumplen. OKR no es una herramienta de evaluación de empleados.

PREGUNTAS DE FINAL

1. Seleccione las opciones correctas y justifique. El “tiempo medio de resolución de


incidentes” es:
a. Una métrica de calidad.
b. Una métrica de rendimiento.
c. Una métrica de valor.
d. Todas las opciones son correctas.
e. Ninguna de las opciones es correcta.

Gestión de RR. HH.

ADMINISTRACIÓN DE RECURSOS HUMANOS

Definición: actividades que ponen en funcionamiento, desarrollan y movilizan a las personas para que
una organización alcance sus objetivos. De la definición podemos desprender que:
1. En el proceso de gestión de RR.HH. intervienen todas las personas de la organización.
2. Para poner en funcionamiento los RR.HH. es necesario definir políticas y articular las
funciones dentro del marco de los objetivos organizacionales (alineación con la estrategia).
3. Se necesitan métodos para captar, conservar y desarrollar los recursos humanos (operativa).
4. La gestión de RR.HH. debe ser realizada dentro de un marco reglamentario y administrativo.

LIDERAZGO

Liderazgo: capacidad de inspirar y guiar a individuos o grupos. Liderazgo es el proceso de influir en


otros y apoyarlos para que trabajen con entusiasmo en el logro de objetivos comunes. Se entiende
como la capacidad de tomar la iniciativa, gestionar, convocar, promover, incentivar, motivar y evaluar a
un grupo o equipo. Liderar ≠ Administrar. Liderar implica administrar, administrar no implica liderar.
● Administrar: asignar eficientemente los recursos y personas a las tareas.
● Liderar: influir en el comportamiento de las personas. El liderazgo es una habilidad que se
puede aprender y entrenar.

Características de líderes efectivos:


● Saben cómo administrar y resolver los conflictos del grupo.
● Saben planificar y conocen con precisión los roles de cada miembro del equipo.
● Son flexibles para adaptar su estilo de liderazgo a las necesidades de sus subordinados.
● Delegan la autoridad entre sus subordinados.
● Son buenos comunicadores.

DESARROLLO DE EQUIPOS

Importancia de los equipos:


● El equipo de proyectos se caracteriza por el hecho de que sus miembros cooperan entre sí y
se comprometen con la consecución de objetivos comunes.
● Debe ser capaz de generar SINERGIA entre sus miembros para que el todo sea mayor que la
suma de las partes.
● Se caracterizan por la definición de objetivos claros, compartidos por todos sus integrantes,
que les sirven de guía en su accionar.

Obstáculos al buen funcionamiento:


● Objetivos pocos claros y pobremente comunicados.
● Definición confusa de roles.
● Comunicación pobre.
● Falta de liderazgo.
● Alta rotación.
● Comportamiento inapropiado.
GESTIÓN DEL CAMBIO

Definición: proceso deliberadamente diseñado que mitigue los efectos no deseados de este mismo
cambio y potencie las posibilidades de crear futuro en la organización, su gente y contexto.

Niveles de cambio:
● Quiebres: ruptura en las recurrencias, transparencias, “pilotos automáticos” en los que
funcionan ciertos comportamientos, procesos, metodologías o prácticas de acción. La
ventaja del término es que no está asociado con ningún juicio de valor, lo positivo o negativo
del quiebre está en la mirada del observador de este.
○ Transformación: proceso in-out, que nace o emerge de los sujetos, actores, o de la
organización en pos de un futuro mejor. Los procesos de transformación implican
estructuras profundas de los sistemas, en realidad es un cambio de sistema.
○ Cambio: proceso out-in que responde a una demanda de adaptación dentro del
sistema. El sistema cambia, entonces yo tengo que cambiar para adaptarme a él.
La gestión del cambio nace desde la percepción del tipo de quiebre (cambio o transformación) que
está en juego y desde allí arma su estrategia de intervención y las herramientas a utilizar.

Fuerzas impulsoras del cambio: se encuentran dentro o fuera del proyecto. Están vinculadas a
diversos factores: características de la fuerza laboral, la competencia, la tecnología, las tendencias
sociales, las crisis económicas y la situación política mundial.
● Motivación: producir, proporcionar un motivo o causa para una acción. (Pirámide de Maslow).
Darle nuevos retos o desafíos intelectuales a personas que disfruten de ello.
● Persuasión: convencer con argumentos a alguien de algo. Ej: prometer que si se realiza cierta
tarea va a ser recompensado económicamente o que va tener un cargo mejor.

Fuerzas restrictivas del cambio:


● Resistencia individual: la gente no se resiste a los cambios, se resiste a ser cambiada.
Sienten aversión al riesgo.
● Resistencia organizacional: vinculado a factores como la inercia estructural. Las
organizaciones prefieren hacer las cosas como las hicieron siempre. El cambio es también
resistido cuando amenaza las relaciones de poder dentro del proyecto o las posiciones de las
actuales autoridades.

Objetivos generales de la administración de RRHH:


● Crear, mantener y desarrollar un conjunto de personas con habilidades, motivación y
satisfacción suficientes para conseguir los objetivos de la organización.
● Crear, mantener y desarrollar condiciones organizacionales que permitan la aplicación, el
desarrollo y la satisfacción plena de las personas y el logro de los objetivos individuales.
● Alcanzar eficiencia y eficacia con los recursos humanos disponibles.

NEGOCIACIÓN

Definición: es el proceso de comunicación que tiene por finalidad influir en el comportamiento de los
demás y donde ambas partes lleguen a un acuerdo GANAR-GANAR.

Otra definición: la negociación es el proceso por el cual las partes interesadas resuelven conflictos,
acuerdan líneas de conducta, buscan ventajas individuales y/o colectivas y procuran obtener
resultados que sirvan a sus intereses mutuos. Se contempla generalmente como una forma de
resolución alternativa de conflictos o situaciones que impliquen acción multilateral.

PREGUNTAS DE PARCIAL

1. Indicar V o F. Los líderes efectivos son flexibles para adaptar su estilo de liderazgo a las
necesidades de sus subordinados y delegar su responsabilidad sobre ellos.
Falso. La responsabilidad no se puede delegar.

2. Indicar V o F. La negociación es una habilidad indispensable que se debe profesar en el rol


del líder y está catalogada como una fuerza impulsora dentro de la gestión de cambios.
Falso. La negociación no es una fuerza impulsora. Las fuerzas impulsoras son la persuasión y la
motivación.

PREGUNTAS DE FINAL

1. Indicar V o F. El rol de un gerente de sistemas y/o tecnología, es un administrador de


recursos que tiene por objetivo alcanzar las metas organizacionales de producto y/o
servicios de manera eficiente.
Verdadero. El gerente administra recursos humanos y físicos para conseguir los objetivos de la
organización.

2. Indique V o F. En una negociación con un enfoque GANAR-GANAR ambas partes obtienen


un resultado que cada una considera valioso. Dado que se trata de un proceso de
comunicación a largo plazo, una de las partes puede obtener todo lo que está en disputa en
una instancia de negociación, y en la siguiente cederlo todo y de esta forma se mantiene el
balance de ganancia de cada parte.
Me parece cualquier cosa esta pregunta. Para mi es verdadera porque en ese acuerdo ambas partes
pueden estar ganando. Copio lo que dice el resuelto: “Falso. Es un proceso de comunicación que
consiste en influir en el comportamiento de los demás donde ambas partes llegan a un acuerdo
ganar o ganar. El enfoque de ganar o ganar no se trata de que uno tiene que cederlo todo sino que
ambas partes se beneficien”.
Abastecimiento, evaluación de productos/servicios y evaluación de
propuestas técnico-económicas

Benchmark

BENCHMARKING

Definiciones:
● Proceso continuo por el cual se toman como referencia los productos, servicios o procesos
de trabajo de las empresas líderes que evidencien las mejores prácticas sobre el área de
interés, para compararlos con los propios y poder realizar mejoras.
● Se trata de un indicador financiero utilizado como herramienta de comparación para evaluar
el rendimiento de una inversión (p. de vista económico).
● Como es un proceso, es sistemático, es decir, tiene pasos. Es continuo (cíclico), comparativo
y conlleva una decisión. Ejecutar benchmark es ejecutar un algoritmo e iterar hasta conseguir
el resultado adecuado para tomar una decisión.
● Siempre tiene aparejado una unidad de medida.

Benchmark vs benchmarking: benchmark es el punto de referencia que tomamos para realizar el


benchmarking. Es un pivot. El benchmark es objetivo.

Utilidades:
● Comparar elementos a través de características claves para la solución.
● Obtener un resultado objetivo.
● Obtener la mejor relación costo/beneficio.
● Comprobar si los elementos estudiados se adecuan a las necesidades.
Debemos ver cuándo conviene invertir tiempo y dinero en hacer un nuevo benchmark y cuándo
podemos usar los que ya existen.

Etapas del proceso:


1. Elegir elemento de estudio: ¿qué es lo que vamos a someter a la prueba?
2. Preparar el entorno de prueba: el benchmarking se debe poder ejecutar dentro de un entorno
controlado.
3. Test: se somete al test (se corre el algoritmo).
4. Resultado: el test devuelve un resultado que hay que analizar.
5. Calibrar: las calibraciones me pueden llevar al punto de partida. Esto quiere decir que tal vez
el objeto de estudio está mal definido, no es el correcto o, tal vez está mal definido el entorno
de prueba.

PREGUNTAS DE PARCIAL

1. Indicar V o F. En el proceso de benchmarking hay una contradicción entre la objetividad de


las mediciones realizadas y la subjetividad del análisis de los informes que contienen los
resultados finales.
Verdadero.

2. Un benchmark es una herramienta útil para:


a. Evaluar el costo por transacción.
b. Evaluar el costo por proceso.
c. Comparar 2 soluciones diferentes.
d. Todas las anteriores.
e. Ninguna de las anteriores.

Gestión de abastecimiento

ABASTECIMIENTO

Definición: proceso a través del cual una organización puede adquirir bienes o contratar servicios
provistos/prestados por terceros y que son necesarios para poder cumplir con sus operaciones.

Gestión de abastecimiento: es la acción de utilizar los recursos que disponemos de manera efectiva
y eficaz para poder mejorar el proceso de compra de los bienes y/o servicios que necesita la
organización.

Etapas del proceso de abastecimiento:


1. Definición de requerimientos: se trata de traducir la necesidad en un requerimiento para los
proveedores. Esto implica determinar cuáles son las características más importantes del bien
o servicio que se necesita adquirir o contratar y de la condiciones de compra y entrega.
Claves:
● Hacer partícipe a quienes necesitan del bien o servicio en la organización.
● Especificar claramente qué se desea comprar y para qué fin.
● Realizar bases de licitación precisas y claras.
● Considerar la instalación, soporte y servicio post venta.
2. Selección del mecanismo de compra: una vez que definimos qué necesitamos comprar, es
necesario determinar qué mecanismo utilizaremos para adquirirlo. Los mecanismos se
encuentran definidos por las leyes de Compras Públicas de cada jurisdicción (en el caso de
organismos públicos) y/o por los reglamentos de compras internos de cada organización.
Los mecanismos más comúnmente utilizados consisten en:
● Convenios marco:
○ Sistema pensado especialmente para las compras habituales o estándares.
○ La mayoría de las adquisiciones debieran realizarse por esta vía.
○ El procedimiento entrega amplias garantías de transparencia y permite
compras eficaces y eficientes.
● Licitación pública: participan todos los proveedores que consideren que pueden
satisfacer la demanda/necesidad que pide la organización. Si es un organismo
público, por ley está obligado a analizar todas las propuestas y elegir la más barata.
○ Se utiliza cuando el producto o servicio no se encuentra en convenio marco.
○ Es un proceso de amplia participación ya que es un llamado abierto.
● Licitación privada: la empresa llama a concurso a los proveedores que considere.
○ Es un mecanismo excepcional contemplado por la Ley.
● Trato directo:
○ También se trata de un mecanismo excepcional contemplado por la Ley.
○ Puede ser un proceso abierto o privado, o la emisión directa de la orden de
compra a un proveedor, dependiendo de la excepción que se trate.
3. Llamado y recepción de propuesta: esta etapa tomará diferentes formas dependiendo del
mecanismo de compra que se haya seleccionado.
● Convenios marco: se solicita la aceptación de una orden de compra y una vez que el
proveedor acepta se cierra esta etapa.
● Licitaciones: recibir propuestas.
4. Evaluación de propuestas: una vez que tenemos las propuestas de los oferentes, debemos
analizar si ellas satisfacen nuestras especificaciones mediante un proceso de evaluación. Es
fundamental definir previamente el método que se usará para comparar las alternativas, lo
que en la práctica significa establecer indicadores para los aspectos claves que se desean
evaluar y el modo en que se piensan calcular. Se debe comunicar previamente a los
oferentes/potenciales proveedores bajo qué criterios se les evaluará.
5. Adjudicación de ofertas: en esta etapa se cierra la evaluación y decide a quien se comprará.
Deben formalizarse los acuerdos de facturación, garantías, pago, servicio técnico, etc. La
adjudicación debe ser documentada, comunicada a todos los oferentes y publicada según
corresponda.
6. Recepción del producto/servicio: recepción y verificación del bien o servicio de acuerdo a lo
solicitado en las bases y condiciones y de acuerdo a lo ofertado..
7. Seguimiento y monitoreo de la compra: evaluación de los proveedores. Revisar
periódicamente fechas de término y renovación de contratos. Tener claro los mecanismos de
garantías. Ordenar y tabular la información relevante para futuras compras.

CONSIDERACIONES EN IT

Consideraciones de abastecimiento en IT: parámetros a analizar al adquirir productos de IT:


● Características de hardware:
○ Tipo de tecnología.
○ Prestaciones del equipamiento.
○ Características físicas.
○ Fecha de liberación del producto al mercado.
○ Fecha de fin de vida (EoL) y disposición final.
○ Posibilidad de crecimiento futuro.
● Características de software:
○ Modo de licenciamiento, instalación y actualización.
○ Compatibilidad con sistemas operativos y versiones.
○ Ciclo de vida del software: actualizaciones funcionales y de seguridad.
○ Interoperabilidad con otros software.
○ Mecanismos de migración de los datos.
○ Mecanismos de resguardo.
○ Lenguajes de programación compatibles para extensión funcional.
● Actualización tecnológica de los RRHH:
○ Capacitación específica necesaria para los operadores del sistema a incorporar.
○ Formato de capacitación: presencial o virtual e individual o grupal.
○ Idiomas utilizados en los cursos y para documentación.
○ Sistema a utilizar para la práctica de operación.
● Garantía y soporte técnico:
○ Tipo y plazo de la garantía.
○ Factibilidad y disponibilidad de soporte remoto y/o presencial.
○ Vías de contacto, cobertura y escalamiento.
○ Nivel de servicio comprometido (SLA):
- Para atención de consultas e incidentes.
- Para resolución de casos.
● Referencias y antecedentes del producto/servicio:
○ Instalaciones o prestaciones del mismo P/S o similares por el mismo fabricante.
○ Calidad de servicio de mantenimiento, soporte y asistencia técnica.
● Referencias y antecedentes del proveedor:
○ Currículum del proveedor:
- Antigüedad del proveedor en el mercado.
- Listado de clientes y antecedentes.
- Centros geográficos de servicio.
- Equipo técnico para el producto/servicio.
- Estados económicos/financieros.
○ Currículum de servicio:
- Antigüedad de representación en el producto/servicio.
- Antecedentes de entrega/prestación de magnitud similares a las requeridas.
- Antecedentes de cumplimiento de servicio.
- Volumen anual de venta del producto/prestación.
● Costo (Total Cost of Ownership - TCO = CapEx + OpEx): es el costo total de un producto a lo
largo de su ciclo de vida completo, tomando en cuenta los costos directos, indirectos y
ocultos.
○ Costo directo del sistema a adquirir: incluye como componente básico el precio de
compra/contratación/leasing y además todos los derivados con la implementación:
- Costos de financiación y cobro/pago.
- Impuestos internos y de exportación.
- Seguros de traslado y almacenamiento.
- Adecuación o preparación de instalaciones requeridas.
- Costos de implementación del bien o servicio.
○ Costo de operación: servicios de base (ej: energía eléctrica), recursos técnicos y
humanos necesarios para que el bien o servicio cumplan su función.

PREGUNTAS DE PARCIAL

1. Seleccionar una opción. El costo total de propiedad (TCO) puede incluir:


a. CapEx.
b. Opex.
c. Costo de no poder operar por disrupción.
d. Costo de demandas judiciales por patentes.
e. Costo de recuperación de disrupción.
f. Costo de obsolescencia.
g. Todas las opciones anteriores son correctas.
h. a, b, c y e.
i. a, b, c, d y e.
j. Ninguna de las anteriores.

2. Indique V o F. Si se tiene que realizar un proyecto tecnológico en 6 meses para dar un


servicio de software, el cual se debe realizar sobre cierto tipo de hardware cuya
obsolescencia se da luego de 5 años y sabemos además que la vida del servicio es temporal
(solo va a dar servicio por 3 meses), es decir, se realiza para dar respuesta a un evento en
un momento de tiempo y luego no se utiliza más. ¿Podemos afirmar que optar por la compra
(CAPEX) de tecnología va a ser más rentable que alquilarla (OPEX) dado a que al final del
proyecto siempre voy a poder vender la misma y obtener un reintegro?
Falso. Comprar la infraestructura conlleva muchos más costos ocultos, además que la tecnología va
a seguir deprecándose a medida que pase el tiempo, disminuyendo su costo de reventa. No puede
afirmarse que la compra de la tecnología será más barata que alquilarla.
MEP

METODOLOGÍA DE EVALUACIÓN DE PROPUESTAS (MEP)

Definición: MEP es una metodología para evaluar las propuestas recibidas por los distintos oferentes.
Responde a la pregunta de ¿cuál es la propuesta que mayor satisfacción me da dadas mis
necesidades? El MEP es 100% subjetivo. Esa es la principal diferencia con el benchmark.
Conlleva 3 pasos:
1. Armar el cuadro de pesos relativos.
2. Armar el cuadro de valoración de atributos → no hace falta 1.
3. Armar el cuadro de ponderación de propuestas → hace falta 1 y 2.

Requerimientos: antes de hacer los pasos 1, 2 o 3 del MEP hay que hacer lo que se llama “cuadro de
requerimientos”. Este cuadro va a tener 4 columnas:
● Indispensable: acá van las características que sí o sí tienen que tener todos los proveedores.
Esto es como un filtro antes de hacer el análisis MEP. Solamente vamos a considerar a los
proveedores que cumplan con todos los requerimientos puestos acá. Es decir, cumplir con
los requerimientos indispensables no hace a una propuesta mejor que otra porque es lo
mínimo que necesita para ser analizada por MEP. Todas las propuestas van a cumplir con eso
así que no es algo que MEP considera.
● Preferido: estas son las características que analiza MEP porque es lo que distingue a una
propuesta de otras.
● No deseado:
● No considerado:

Ejemplo: selección de una tablet.


Indispensable Preferido No deseado No considerado

Tamaño de pantalla ≥ a 7" Tamaño de pantalla > 8" Pesos > 1 kg WebCam trasera

Resolución mínima de Resoluciones > 1024 X


1024 X 600 600

Capacidad de Velocidad de procesador >


almacenamiento ≥ 8 Gb 1Ghz

Conectividad Disco sólido

1. Cuadro de pesos relativos: tenemos que tomar las características que escribimos en la columna
“Preferido” y agruparlas en categorías, que podrían ser:
● Físicas: tamaños, colores, pesos, materiales, etc.
● De funcionamiento.
● Técnicos.
● Servicios de post venta: mantenimiento, garantía, capacitación, etc.
La idea es determinar los ítems que nos interesa evaluar.

Características de su desarrollo:
● Las filas tendrán el detalle de los ítems a analizar con sus distintos niveles de desagregación
(subitems). Tantos como sea necesario. Por ejemplo, si el ítem fuera memoria RAM podría
desagregarse en velocidad y capacidad.
● No necesariamente todos los ítems tienen que tener el mismo nivel de desagregación.
● En las columnas se visualizarán los n niveles con sus respectivos pesos por ítem y subitem.
Estos valores se colocan de acuerdo a la percepción de quien esté armando la tabla.
● Siempre en el nivel 1 y en el nivel general (máximo nivel de desagregación) la suma de los
pesos relativos sumará 100.
● El costo no se desagrega porque se analiza aparte. Puede haber otros ítems que no caigan
dentro de ninguna categoría y que también tengamos que analizarlos aparte. En estos casos
hay que tener cuidado con el valor que le damos al peso en el nivel 1. Como su % va a ir
directo al nivel general (NG) si le ponemos un % muy alto siempre va a terminar ganando el
producto más barato, por ejemplo (si hablamos del costo).

Ejemplo:

2. Valoración de atributos: para la mayoría de los ítems a evaluar el mercado nos ofrecerá varias
alternativas, a las que llamaremos atributos. Se deberán considerar para todos los ítems los atributos
posibles que nos ofrece el mercado (alcanzables por nuestro proyecto) y valorarlos respecto de qué
grado de satisfacción extra nos da ese atributo.
Como ya dijimos, una propuesta que no cumpla con alguno de los requerimientos obligatorios no
debe ser tenida en cuenta. Por tanto, deberá evaluarse el grado de satisfacción a partir de ese mínimo
especificado para cubrir nuestra necesidad. La asignación de valores a los atributos deberá estar
entre 0 y 100 siendo 0 para el atributo que cumpla mínimamente con el requerimiento y 100 para el
mayor nivel de satisfacción. Teniendo en cuenta que solo se tendrán en cuenta los atributos posibles
existentes siempre debería haber un atributo que nos dé 100% de satisfacción (a excepción de los
atributos aditivos). Existen 3 tipos de atributos:
● Mutuamente excluyentes: si el ítem toma un valor, no puede estar tomando otro. Cuidado con
los rangos [ ] y ( ).
● Aditivos: la suma de los valores deben dar 100. No como en los excluyentes.
● Binarios: tiene o no tiene. Es una particularidad de los mutuamente excluyentes. Uno vale 0 y
el otro 100.
3. Ponderación de propuestas: con las propuestas que hayan cumplido con los requisitos
indispensables se realizará el cuadro de valoración de propuestas, del cual saldrá la propuesta
seleccionada. Para completar el cuadro de ponderación hay que identificar para cada una de las
propuestas ítem por ítem cual es el atributo ofrecido y luego se realiza el producto del “Peso” del ítem
en el Nivel General por el “Valor” asignado al atributo ofertado en cada caso (dividiendo el producto
por 100). Luego se suman los productos obtenidos y se llega al total de la propuesta. Mejor será la
propuesta cuanto más cercano a 100 sea su total.

Vemos que ganó una que no es la más barata.


El valor de ponderación de cada propuesta es el porcentaje (Valor) del NG. Ejemplo: 70% de 10,5 es
7,35.
Para calcular el costo se reemplaza el valor en la f(costo).

Costos - concepto de vida útil: para lograr una correcta selección es fundamental determinar cuál
será la vida útil del bien a adquirir contextualizado en nuestro proyecto. Cualquier bien tiene una vida
útil acotada ya sea por desgaste, deterioro o por llegar al límite de sus capacidades. También se debe
tener en cuenta que una vez terminada la vida útil del bien en nuestro proyecto éste tiene un valor
residual (ya sea en su totalidad o por componentes) que puede ser positivo o negativo en el caso que
tengamos que pagar para que sea retirado, por ejemplo.
Dado que el costo es un ítem fundamental y complejo, es conveniente desglosarlo en un cuadro
diferente para su cálculo y luego incluirlo en el cuadro como un ítem sin desagregación.

Costos - Evaluación de la función de costos: considerando que el costo es un ítem para el cual
tenemos valores continuos es lógico pensar que existe una función continua que define la
satisfacción en función del costo. Esta función es lineal y con pendiente negativa.

Donde pagar el costo máximo (Cmáx) nos daría 0% de satisfacción y pagar el costo mínimo (Cmin)
nos daría 100% de satisfacción.
Para conocer la función costo debemos conocer los valores mínimos y máximos del producto en el
mercado y construir la siguiente tabla:

Incluyendo un margen de 5% de seguridad,


estimamos el coste mínimo y máximo como
1044,05 y 9817,5. Luego se calculan los
coeficientes de la función lineal con los puntos
que conocemos de la función y en este caso la
función costo queda: f(Costo) = -0,0114x + 111,9

Punto de ponderación: es el valor expresado en


unidades monetarias de la diferencia de importes
de costo que generan una diferencia de
ponderación igual a 1. Representa cuánto (en $$$)
estoy dispuesto a pagar para aumentar mi
satisfacción en 1 punto.
Cálculo de valores de atributos lineales mutuamente excluyentes: al igual que en el costo, la
satisfacción brindada por estos atributos puede ser representada por una función lineal.
Esta función será de pendiente positiva para aquellos atributos que a mayor valor nos ofrecen mayor
satisfacción (por ej. tamaño de una habitación) y de pendiente negativa para aquellos que a mayor
valor nos ofrecen menor satisfacción (por ej. consumo de energía). Utilizando la ecuación de función
para asignar los valores se obtendrá una ponderación más acertada para cada atributo.

PREGUNTAS DE PARCIAL

1. Usted es responsable del área de desarrollo de Software de una entidad estatal. Se decide
contratar un servicio de provisión de recursos, que brinde temporalmente por 3 meses el
servicio de 1 desarrollador java full time para sumarse al equipo de desarrollo. El
mecanismo de compra será LICITACION PRIVADA. El presupuesto tope asignado aprobado
por directorio para dicha contratación es de $200.000 (Pesos doscientos mil). Se requiere
que el perfil propuesto posea al menos 5 años de experiencia en desarrollo de aplicaciones
web, y al menos 4 años de experiencia en desarrollo de aplicaciones Java, valorándose en
ambos casos una mayor cantidad de años de experiencia. Es deseable que el recurso sea
empleado en relación de dependencia de la empresa proveedora, aunque también se
evaluarán ofertas en las cuales el recurso sea subcontratado por ella. Es requisito
fundamental que el recurso sepa hablar inglés y tenga experiencia de al menos 2 años en
utilización de bases de datos relacionales. Es deseable pero no obligatorio que el oferente
presente un informe de experiencias anteriores en este tipo de provisión de recursos.
Tendrán una valoración adicional aquellas propuestas cuyo perfil propuesto posea
experiencia en desarrollo de aplicaciones de escritorio.
En base a los requerimientos anteriores, confeccione las tablas de pesos relativos y
valoración de atributos necesarias para poder evaluar las propuestas que sean presentadas
para la contratación.

Tabla de pesos relativos:


Atributos N1 N2 NG

1. Experiencia

1.1 Aplicaciones web 65 30 19,5

1.2 Aplicaciones java 40 26

1.3 Informe de 10 6,5


experiencias

1.4 Experiencia en 20 13
apps de escritorio

2. Relación de 15 100 15
dependencia

3. Costo 20 100 20

TOTAL 100 - 100

Tabla de valoración de atributos:


Ítem Atributo Valor

1. Experiencia

1.1 Aplicaciones web 5 0

(5; 7] 40

(7; 10] 70

> 10 100

1.2 Aplicaciones java 4 0

(4; 7] 40

(7; 10] 70

> 10 100

1.3 Informe de experiencias Sí 100

No 0

1.4 Experiencia en apps de Sí 100


escritorio
No 0

2. Relación de dependencia Sí 100

No 0

3. Costo [100.000, 200.000] F(Costo)= - 0,001 * Costo + 200

Función costo:

f(100.000) = 100
f(200.000) = 0

y = mx + b
0 = 200.000m + b → b = - 200.000m = 200

y = mx + b
100 = 100.000m + b
100 = 100.000m - 200.000m
100 = - 100.000 m
m = - 0,001

y = -0.001x + 200

2. Detecte los principales errores y redacte un enunciado acorde a la solución desarrollada.


3. MEP:

Requerimientos preferidos:
● Se requiere mínimamente un procesador de 2.10 GHz (HARDWARE)
● Memoria mínima de 8 Gb (HARDWARE)
● Tamaño mínimo de disco rígido de 256 Gb (HARDWARE)
● Se prefiere que sea disco sólido (HARDWARE)
● Opcionalmente Wi-Fi (HARDWARE)
● Se valora que tenga puertos de conexión USB 3.0, HDMI y/o DVI (HARDWARE)
● Pantalla no menor a 17’’ (ESTÉTICA)
● Carcasa blanca o negra (ESTÉTICA)
● Límite en el presupuesto: $1.500.000 por cada equipo (COSTO)
● Garantía no puede ser menor a 1 año (SOPORTE)
● Se valora al proveedor que incluya soporte técnico en línea y presencial (SOPORTE)

Tabla de pesos relativos:


Atributos N1 N2 NG

1. Hardware

1.1 Procesador 65 20 13

1.2 Memoria 20 13

1.3 Tamaño disco 20 13

1.4 Disco sólido 20 13

1.5 Wi-Fi 10 6,5

1.6 Puertos 10 6,5

2. Estética

2.1 Tamaño pantalla 15 50 7,5

2.2 Color carcasa 50 7,5

3. Soporte

3.1 Garantía 10 50 5

3.2 Soporte 50 5

4. Costo 10 100 10

TOTAL 100 - 100

Tabla de valoración de atributos:


Ítem Atributo Valor

1. Hardware

1.1 Procesador (GHz) 2.10 0

(2.10, 3] 50

>3 100

1.2 Memoria (Gb) 8 0

(8, 16] 50

> 16 100
1.3 Tamaño disco (Gb) 256 0

(256, 512] 50

> 512 100

1.4 Disco sólido No 0

Sí 100

1.5 Wi-Fi No 0

Sí 100

1.6 Puertos USB 3.0 40

HDMI 20

DVI 20

2. Estética

2.1 Tamaño pantalla (’’) 17 0

(17, 20] 50

> 20 100

2.2 Color carcasa Otro 0

Blanco o negro 100

3. Soporte

3.1 Garantía (años) 1 0

(1, 2) 30

>2 70

3.2 Soporte En línea 50

Presencial 50

3. Costo ($) [400.000, 1.500.000] F(Costo)= - 0,00009 * Costo +


136

Función costo: y = mx + b
F(0) = $1.500.000 → (1) 0 = 1.500.000 m + b
F(100) = $400.000 → (2) 100 = 400.000 m + b

(1) en (2): 100 = 400.000 m - 1.500.000 m


100 = - 1.100.000 m
m = - 0,00009
b = 136
y = - 0,00009 x + 136
PREGUNTAS DE FINAL

1. Seleccione las opciones correctas y justifique. La metodología de evaluación de propuestas,


dentro del ciclo de gestión de abastecimiento, me permite establecer (la respuesta no está
chequeada, sólo sé que no es la b, a ni la e).
a. El peso relativo de aquellos atributos que generan ganancia sobre la propuesta
original.
b. El valor relativo de satisfacción de aquellos atributos que aportan valor de verdad a
la propuesta.
c. Cuánto estoy dispuesto a pagar por un atributo más que otro dentro de una misma
propuesta. Esta para mi no es verdadera. Lo que podés saber es cuánto dinero estás
dispuesto a pagar por 1 punto más de satisfacción.
d. Una comparación eficiente de las propuestas según las bondades específicas
requeridas para cubrir el alcance.
e. Todas las opciones anteriores son correctas.
f. Ninguna de las opciones anteriores es verdadera.

2. Indique V o F y justifique. Si un sector de una organización que provee servicios de IT a


otras empresas firma un SLA con un cliente y para brindar esos servicios requiere del apoyo
de otra área de la propia organización, es recomendable que establezca un acuerdo sobre el
nivel de los servicios recibidos de forma de asegurar parte del cumplimiento de lo firmado
con el cliente.
Falso. El SLA es un contrato firmado a nivel cliente-proveedor. Si el proveedor de servicios requiere la
colaboración de varias áreas dentro de su organización, tendrá que elaborar algún otro tipo de
acuerdo interno.

3. Seleccione las opciones correctas y justifique. Con respecto a MEP y benchmark:


a. El primero es un proceso objetivo y el segundo un método subjetivo. Esta no es
porque MEP es completamente subjetivo dado que depende de los atributos que la
persona que hace el MEP quiere valorar y qué peso le da a cada uno.
b. El primero es un método subjetivo y el segundo un proceso objetivo. Para mi esta es
verdadera porque MEP dijimos que es subjetivo y el proceso, es decir, el algoritmo de
benchmark se dice que es algo objetivo. O sea, uno ejecuta los pasos y obtiene un
resultado, eso es objetivo. Lo que es subjetivo en benchmark es el armado del
entorno de prueba y la elección del elemento de estudio. Pero el proceso es objetivo.
c. Benchmark sirve para establecer una métrica. Yo le pongo verdadero porque
benchmark sirve para establecer indicadores financieros.
d. Todas las opciones anteriores son correctas.
e. Ninguna de las opciones anteriores es verdadera.

4. Usted es el encargado de compras de una empresa y una de sus tareas es revisar las
evaluaciones que se van a realizar antes que lleguen las propuestas de los proveedores. En
este caso debe revisar cómo se va a evaluar la compra de 10 notebooks de alto rendimiento.
Uno de los requerimientos es el peso ya que será transportada con frecuencia, por lo tanto
el peso debe ser menor o igual a 2,5 kg aunque es ideal que esté entre los 2,2 y los 2 kg
(según un estudio de mercado no hay equipos con las características solicitadas que pesen
menos de 2 kg). La persona que armó la evaluación de propuestas determinó los siguientes
valores:
● El peso del costo es de 10.
● El costo total de cada notebook se estima entre $200.000 y $300.000.
● El peso del ítem “peso de la notebook” es de 15.
● La valoración de atributos del ítem “peso de la notebook” es la siguiente: para 2,5 kg
la valoración es 0, entre 2,49 kg y 2,20 kg la valoración es 50 y entre 2,19 kg y 2 kg
es de 100.
a. Tal como está armada la valoración, ¿cuánto más estaría dispuesto a pagar por adquirir
notebooks que pesen entre 2,49 y 2,20 kg? ¿Y cuánto más estaría dispuesto a pagar por
notebooks que pesen entre 2,19 y 2 kg?
b. ¿Cuál es la conclusión a la que arriba luego de resuelto el punto 4a?

Tabla de pesos relativos:


Atributos N1 N2 NG

1. Peso 15 100 15

… … … …

2. Costo 10 100 10

TOTAL 100 - 100

Tabla de valoración de atributos:


Ítem Atributo Valor

1. Peso (kg) 2,5 0

(2,5; 2,2] 50

(2,2; 2] 100

… … …

3. Costo ($) [$200.000, $300.000] F(Costo)= m * Costo + b

a. Una notebook que pese entre 2,49 kg y 2,20 kg da una satisfacción del 50%. Como el atributo
“peso de la notebook” tiene un peso de 15, eso significa que la notebook otorgaría 7,5 puntos
de satisfacción sobre el total.
Ahora, aumentar la satisfacción en 1 punto tiene un precio.
VPP = CM - Cm / Peso del Costo = $100.000 / 10 = $10.000
Por lo tanto, estamos dispuestos a pagar 7,5 * $10.000 = $75.000 de más por adquirir
notebooks que pesen entre 2,49 y 2,20 kg.
En el caso de que pesen entre 2,19 y 2 kg estamos dispuestos a pagar: 15 * $10.000 =
$150.000

b. No sé pero si hice bien las cuentas me parece que sería mejor definir una función para la
satisfacción del peso porque no me parece lógico estar pagando el doble por una notebook
que pesa apenas unos gramos menos que otra, cuando en la realidad uno no notaría la
diferencia. Si se usara una función decreciente (como en el costo) sería más acertado.

5. Indique V o F. Si el peso de ponderación de un ítem es 10 en su máxima valoración y el valor


del punto de ponderación del ejercicio es $400, entonces estoy dispuesto a pagar hasta
$4000 más para que una opción que no contenga el ítem sí lo tenga.
Me está diciendo que un ítem, si se encuentra al 100%, tiene un peso final de 10 en la valoración final.
El punto de ponderación es $400, lo que quiere decir que yo voy a pagar $400 por aumentar mi
satisfacción en 1 punto.
Para mi es verdadera, porque el tener este ítem aumenta la satisfacción en 10 puntos. O sea, que para
agregar este ítem estamos dispuestos a pagar hasta 10 * $400 = $4000.

6. En función de la matriz de evaluación de propuestas que se detalla a continuación y


suponiendo que el peso relativo del costo es el adecuado a la preferencia del requirente,
¿qué cambio debería realizar en la evaluación de costo, teniendo en cuenta el escenario
presentado, para que la oferta ganadora hubiera sido la propuesta 1?

Totales (no salieron en la foto):


1- 58,87
2- 61,3 → Propuesta ganadora
3- 46,67

Lo único que se me ocurre para que gane la propuesta 1 es definir una función distinta que haga que
la satisfacción sea máxima para el costo de propuesta 1.
El costo de la propuesta 1 es:
66,67 = -10 x/3 + 200
-133,33 = -10 x/3
x = -133,33 * 3/-10
x = 39,99 == 40

Entonces queremos que:


F(40) = 100
El costo de la propuesta 3 es:
16,67 = -10 x/3 + 200
-183,33 = -10 x/3
x = -183,33 * 3/-10
x = 54,99 == 55

F(55) = 0 → El costo máximo, que nos daría nula satisfacción pagar

Función: y = mx + b
100 = 40 m + b
b = 100 - 40 m

0 = 55 m + b
0 = 55 m + 40 m + 100
0 = 95 m + 100
m = -1,05 → b = 57,89 → y = -1,05 x + 57,89 Nueva Función Costo

7. Desarrolle la tabla de pesos relativos y la de valoración de atributos para la selección de un


servicio IaaS (Infrastructure as a Service) por parte de la empresa.
Habiendo realizado los correspondientes estudios de mercado y con la validación de los
requerimientos de la empresa se ha elaborado una lista final de tres oferentes líderes del
mercado que se encuentran dentro de un presupuesto de USD 60.000 anuales. Si bien todos
los servicios contemplan los aspectos requeridos para el negocio se busca valorar aquellas
características suplementarias a la hora de tomar una decisión.
Como punto de partida del análisis, si bien los servicios cloud pueden incrementarse o
disminuirse en cualquier momento, la forma más cara de contratarlos es bajo demanda. Por
lo tanto, se valorará positivamente la oferta de planes que otorguen importantes descuentos
por el consumo durante uno o más años de una demanda previamente acordada. Y resultará
conveniente la posibilidad de combinar un porcentaje de la contratación bajo esta
modalidad y el resto bajo demanda. También será atractiva la existencia de descuentos
adicionales por pago adelantado parcial o total. Para la evaluación del costo considerar 75%
fijo y 25% bajo demanda.
Para la modalidad bajo demanda, será deseable que la facturación sea por minuto en vez de
la hora para sacar ventaja del menor costo de las operaciones domésticas respecto de las
internacionales, aspecto contemplado por todos los oferentes.
Como criterio a posteriori de facturación del servicio, se valorarán los descuentos según
porcentaje de utilización durante el último mes de una determinada familia de productos.
La minimización del costo de utilización de almacenamiento de estado sólido será un
elemento especialmente importante.
En BBDD relacionales es deseable contar con MariaDB y en PostgreSQL.
Dado que la organización incorporará próximamente un área de data science, será muy
conveniente poder utilizar alguna implementación de Hadoop y Apache Spark.
(No tengo el resuelto de este).

Requerimientos preferidos:
● Presupuesto de USD 60.000 anual (COSTO ANUAL)
● Planes que ofrezcan descuentos en el consumo bajo demanda (DESCUENTOS)
● Posibilidad de combinar un porcentaje de la contratación bajo dos modalidades (fija y bajo
demanda?) (MODALIDADES)
● Existencia de descuentos adicionales por pago adelantado parcial o total (DESCUENTOS)
● En modalidad bajo demanda será deseable que la facturación sea por minuto en vez de por
hora (MODALIDADES)
● Se valorarán los descuentos según porcentaje de utilización durante el último mes de una
determinada familia de productos (DESCUENTOS)
● Minimización del costo de utilización de almacenamiento de estado sólido (DESCUENTOS)
● En BBDD relacionales es deseable contar con MariaDB y en PostgreSQL (APPLIANCES)
● Será muy conveniente poder utilizar alguna implementación de Hadoop y Apache Spark
(APPLIANCES)

Tabla de pesos relativos:


Atributos N1 N2 NG

1. Descuentos

1.1 Bajo demanda 65 25 16,25

1.2 Pago adelantado 25 16,25

1.3 % de utilización 25 16,25

1.4 Min. costo 25 16,25


almacenamiento

2. Modalidades

2.1 Combinación de 15 50 7,5


modalidades

2.2 Fact. por minuto 50 7,5

3. Appliances

3.1 Bases relacionales 10 50 5

3.2 Data science 50 5

5. Costo anual 10 100 10

TOTAL 100 - 100

Tabla de valoración de atributos:


Ítem Atributo Valor

1. Descuentos

1.1 Bajo demanda No 0

Sí 100

1.2 Pago adelantado Parcial 50

Total 50

1.3 % de utilización No 0
Sí 100

1.4 Min. costo No 0


almacenamiento
Sí 100

2. Modalidades

2.1 Combinación de No 0
modalidades
Sí 100

2.2 Fact. por minuto No 0

Sí 100

3. Appliances

3.1 Bases relacionales MariaDB 50

PostgreSQL 50

3.2 Data science Hadoop 50

Apache Spark 50

3. Costo anual ($) Intervalo Función Costo

8. Usted debe revisar una evaluación de propuesta (MEP) en la cual las ofertas han resultado
con un puntaje muy similar (menos de 3 puntos entre mejor y peor). Sabiendo que no hay
errores de cálculo ni desarrollo de funciones describa claramente paso por paso qué
revisaría y cómo lo haría ¿utilizaría VPP para esta revisión? Si decidiera utilizarlo, ¿cómo lo
haría? (No tengo la respuesta correcta)
Antes que nada hay que revisar los siguientes puntos:
● ¿La distribución de pesos es adecuada? ¿El peso del costo es un valor acorde?
● ¿Los atributos continuos (como peso, velocidad, etc) están siendo evaluados con funciones?
De esta forma evitamos que no penalicen por una pequeña diferencia.
● Revisar que en los atributos aditivos estén todas las opciones del mercado (que sean
pertinentes para el requerimiento) para que no se beneficie o penalice a alguna propuesta que
tenga o no la opción faltante.
Yo utilizaría el VPP para comparar en los ítems que se diferencian las propuestas lo que estoy
dispuesto a pagar de más por tener esa ventaja respecto a lo que esa ventaja significa en términos
monetarios en el mercado

9. Armar la tabla de valoración de atributos de la siguiente propuesta: una telco de proyección


internacional requiere para su filial local la contratación de un servicio de rediseño de
procesos de gestión de TI. El framework de procesos que se proponga debe basarse en ITIL
e ISO 2000. Dado el negocio de la compañía, contemplar la articulación con el modelo
operativo eTOM resultará particularmente ventajoso. El diseño de los flujos puede
entregarse en formato MS-Visio, pero es preferible que sea en Aris. Además, el abordaje
con flujos de valor de punta se alinea con el enfoque utilizado por la organización fuera del
ámbito de TI. Los consultores deberán integrar un equipo junto con el personal de la
gerencia de procesos. Se sugiere articular binomios formados por un consultor y un analista
de procesos de la compañía y proveer una capacitación inicial a todos los analistas sobre la
metodología de documentación de procesos que se proponga, la cual deberá ser
homologada con el área corporativa de estándares.
La compañía desea mostrar resultados rápidamente por lo que dará importancia a un plan
de trabajo basado en MVPs.
La configuración de las herramientas de apoyo (básicamente BMC Helix, Clarity PPM y Jira)
estará a cargo de otros proveedores pero los requerimientos funcionales para las mismas y
la validación final de su apoyo efectivo a los procesos será parte del servicio contratado. Se
considera conveniente el soporte a los proveedores de las herramientas durante el trabajo
de configuración de las mismas.
El costo no puede superar los $12.000.000 para el conjunto inicial de procesos, pudiendo
negociarse una segunda etapa equivalente hasta el 80% de la primera.

Requerimientos preferidos:
● Articulación con el modelo operativo eTOM (FUNCIONAL)
● El diseño de los flujos puede entregarse en formato MS-Visio, pero es preferible que sea en
Aris (FUNCIONAL)
● Se sugiere articular binomios formados por un consultor y un analista de procesos de la
compañía (FUNCIONAL)
● Proveer capacitación inicial (POST-VENTA)
● Plan de trabajo basado en MVPs (POST-VENTA)
● Soporte a los proveedores de las herramientas (POST-VENTA)
● Costo no puede superar los $12.000.000 (COSTO)

Tabla de valoración de atributos:

Ítem Atributo Valor

1. Funcional

1.1 Modelo operativo eTOM No 0

Sí 100

1.2 Formato MS-Visio 0

Aris 100

1.3 Binomios formados por No 0


analista y consultor
Sí 100

2. Post-Venta

2.1 Capacitación inicial No 0

Sí 100

2.2 Plan basado en MVPs No 0

Sí 100

2.3 Soporte proveedores No 0


Sí 100

3. Costos [9M, 12M] Función costo

10. Seleccione las opciones correctas. En el proceso comparativo que utiliza la metodología de
evaluación de propuestas como instrumento de análisis, la tabla en donde se definen las
valoraciones que pueden tomar los diferentes atributos deberá encontrar a los mismos
enmarcados dentro de un rango de valores posibles. ¿Cuál de las respuestas cubre todos
los casos en los que la afirmación anterior es válida?
a. Los atributos sean mutuamente excluyentes y/o binarios
b. Los atributos sean aditivos
c. Los valores para el atributo tienen unidad de medida continua y pueden ser
expresados mediante una función lineal
d. El valor que estamos analizando es el costo, que no puede tener pendiente positiva
ni ser cero como cota inferior.
e. Ninguna es correcta. Esta pregunta es cualquier cosa y la saqué de un resuelto la
respuesta correcta.
Big data y blockchain

Big data

BIG DATA

Definición: consiste en conjuntos extensos de datos, principalmente en las características de


volumen, variedad, velocidad y/o variabilidad, que requieren una arquitectura escalable para su
almacenamiento, manipulación y análisis eficientes.

Las 5 Vs: ¿qué tienen que tener estos datos?


● Volumen: grandes volúmenes de datos.
● Variedad: diferentes formatos de datos provenientes de diferentes fuentes de información:
○ Estructurados.
○ Semi-estructurados.
○ No estructurados.
● Velocidad: alta velocidad de acumulación de datos y necesidad de una alta velocidad de
procesamiento.
● Veracidad: precisión e integridad en la generación y procesamiento de los datos. La confianza
en la calidad de la información es vital para la toma de decisiones. Debe ser obtenida de
repositorios confiables con metodologías válidas de recopilación de datos.
● Valor: se tiene que poder establecer el valor que tiene el dato, para ser analizado y que
represente información para el negocio.

Casos de uso: casos que ameritan el análisis de big data.


● Experiencia de usuario: es el caso de uso principal.
● Desarrollo de productos: recaudar datos de experiencias anteriores para obtener información
valiosa para hacer mi producto de calidad.
● Mantenimiento predictivo: puedo hacer una predicción en función de una cantidad importante
de datos. Esto permite que la predicción sea buena.
● Eficiencia operacional:
● Fraude y conformidad: a partir de comportamientos podemos detectar fraude.

DATA ENGINEERING, SCIENCE Y ANALYTICS

Data engineering: dominio de la ingeniería que se dedica a superar los cuellos de botella en el
procesamiento de datos y los problemas de manejo de datos para aplicaciones que utilizan Big Data.
● Pipeline de datos: los datos de entrada se transforman en datos de salida mediante una serie
de operaciones. La idea es desarrollar un sistema que, dado un enorme input de datos, pueda
devolver información valiosa luego de haber procesado estos datos.
Data science: campo centrado en encontrar información procesable
a partir de grandes conjuntos de datos (sin procesar o
estructurados). Se concentra principalmente en encontrar respuestas
a las cosas que no sabemos que no sabemos.
Quienes trabajan en este campo utilizan varias técnicas diferentes
para obtener respuestas, incorporando ciencias de la computación,
análisis predictivo, estadísticas y machine learning para analizar
conjuntos masivos de datos en un esfuerzo por establecer
soluciones a problemas que aún no se han pensado. Se centra en lo
macro.

DBD: decisiones basadas en datos.

Data analytics: se enfoca en el análisis detallado de datos para tomar decisiones informadas. Los
analistas procesan y realizan análisis estadísticos en conjuntos de datos existentes con el objetivo de
descubrir información valiosa y encontrar la mejor manera de presentarla. Su objetivo principal es
resolver problemas y responder preguntas desconocidas. Los resultados obtenidos a través del
análisis de datos pueden conducir a mejoras inmediatas en diversas áreas. Se centra en lo micro.

Diferencias entre data science y data analytics:

Tecnologías/Productos:
● Data lakes: enormes repositorios de datos recopilados de diversas fuentes y almacenados en
su estado original. Se diferencian de los DataWarehouse, que también recopilan datos de
fuentes dispares, pero los procesan y estructuran para su almacenamiento.
● No-SQL databases: se especializan en almacenar datos no estructurados y proporcionar un
rendimiento rápido.
● Predictive analytics: pronostica eventos o comportamientos futuros basándose en datos
históricos.
● Big data security solutions: debido a que los repositorios de Big Data representan un objetivo
atractivo para hackers, su seguridad es importante.
● Big data governance solutions: abarca todos los procesos relacionados con la disponibilidad,
usabilidad e integridad de los datos.
● Streaming analytics: análisis de datos actuales (real-time) y "en movimiento" mediante el uso
de queries continuas que se activan por un evento específico que ocurre como resultado de
una acción, como una transacción financiera, una publicación en una red social, un click en un
sitio web o alguna otra actividad medible.
● Edge computing: es lo opuesto a cloud computing. En lugar de transmitir datos a un servidor
centralizado para su análisis, los sistemas de edge computing analizan datos muy cerca de
donde se crearon. Esto permite reducir la cantidad de información que debe transmitirse a
través de la red, disminuyendo así el tráfico y los costos relacionados.
Desafíos para el negocio y para IT:
● Lidiar con el crecimiento de los datos: se necesita más infraestructura y capacidad para
albergar la cantidad de datos.
● Generar conocimiento en forma oportuna.
● Reclutar y retener talento de Big Data.
● Integrar diferentes fuentes de datos.
● Validación de datos.
● Garantizar la seguridad de la información.

SEGURIDAD DE BIG DATA

Definición: conjunto de acciones de protección de datos frente a factores que podrían comprometer
su confidencialidad e integridad. Uno de los desafíos de la seguridad de Big Data es que los datos se
enrutan a través de un circuito establecido y, en teoría, podrían ser vulnerables en más de un punto.

Capas: opera en tres etapas:


1. Datos de entrada: se debe proteger el tránsito de los datos desde la fuente a la plataforma.
2. Datos almacenados: se requiere cifrado, autenticación de usuario sólida y protección contra
intrusiones. Además se deben proteger logs y herramientas de análisis de la plataforma.
3. Datos de salida (lo que se envía a otras aplicaciones y reportes): es necesario cifrar los datos
de salida y no enviar a los usuarios datos protegidos por regulaciones.

Tecnologías:
● Cifrado: las herramientas de cifrado deben proteger los datos en tránsito y en reposo.
● Control de acceso a usuarios: configuración de acceso basada en roles y usuarios que
permitan gestionar niveles de acceso a la información según las necesidades.
● Detección y prevención de intrusiones: Big Data y la arquitectura distribuida se prestan a
intentos de intrusión. Los sistemas de detección de intrusos (IDS) y los sistemas de
prevención de intrusos (IPS) toman relevancia en este tipo de soluciones.
● Seguridad física: debe ser tenida en cuenta tanto cuando implementamos una plataforma de
Big Data en nuestro data center, o gestionarla en el ambiente de seguridad del proveedor
cloud.
● Gestión centralizada de claves: usar buenas prácticas.

Responsables de la seguridad de Big Data:


● Operaciones de IT.
● DBAs.
● Programadores.
● Áreas de calidad.
● Seguridad de la información.
● Áreas de compliance.
● Unidades de negocio.

PREGUNTAS DE FINAL

1. Indicar V o F. Por su naturaleza, una solución de data lake no requiere un esfuerzo de


planificación para determinar los posibles escenarios de crecimiento de almacenamiento
dado que presupone un crecimiento no predecible.
No tengo el resuelto pero para mi es verdadera porque los data lakes están diseñados para escalar
rápidamente con facilidad.
Blockchain

BLOCKCHAIN

Definición: es una red peer-to-peer que no depende de ninguna entidad centralizada para llegar a un
consenso. Es una tecnología de registro distribuido donde cada par tiene su propia copia del registro.
Una vez que se realiza una transacción, se asigna a un bloque para su verificación a través del
método de consenso utilizado por blockchain. El bloque de transacción se extrae o se valida a través
de otros procesos. Si se confirma la transacción, ya no se puede alterar de ninguna manera posible.

Conceptos técnicos:
● P2P: protocolo de red de comunicación entre pares. Ejemplos: Emule, torrent, etc.
● Algoritmo de hash: algoritmo matemático que transforma cualquier bloque arbitrario de
datos en una nueva serie de caracteres con una longitud fija.
● Criptografía asimétrica: consiste en la posesión de 2 claves, una pública y otra privada. Se
pueden aplicar a contenidos (strings) una firma con la clave privada a través de una función
de hash F y se puede validar con otra función F1 que solo el tenedor de la clave privada firmó
ese contenido.
● Proof of Work (PoW): conceptualmente es requerir un trabajo, que luego es verificado por la
red. Normalmente el trabajo solicitado consiste en realizar operaciones de cómputo que
demuestran que alguien realizó un esfuerzo.
● Consenso: consiste en que toda la red está de acuerdo con el resultado de una prueba.

Principios de blockchain:
● Integridad en la red: la integridad está cifrada en todas y cada una de las etapas del proceso y
distribuida, y no depende de cada miembro individualmente. Comportarse sin integridad o es
imposible, o cuesta mucho más tiempo, dinero, energía y reputación.
● Poder distribuido: el sistema distribuye poder por una red de iguales sin que haya ningún
punto de control.
● El valor como incentivo: el sistema alinea los incentivos de todos los ‘stakeholders‘ y, por lo
tanto, todos los intereses. El bitcoin o algún tipo de valor es parte esencial de esta alineación
y correlativo a la reputación.
● Seguridad: las medidas de seguridad están integradas en toda la red sin puntos flojos y no
solo garantizan la confidencialidad, sino también la autenticidad de todas las actividades y la
imposibilidad de que sean negadas (no repudio).
● Privacidad: al eliminarse la necesidad de confiar en los otros se elimina la necesidad de
conocer la verdadera identidad de esos otros para interactuar con ellos.
● Preservación de derechos: los derechos de propiedad son transparentes y legítimos. Cada
transacción es inmutable e irreversible.
● Inclusión

Secuencia de pasos:
1. Un usuario solicita una transacción.
2. Se crea un bloque que representa la transacción.
3. El bloque se difunde a todos los nodos de la red.
4. Todos los nodos validan el bloque y la transacción.
5. El bloque se añade a la cadena.
6. La transacción se verifica y se ejecuta.
Otros usos de Blockchain: dada la naturaleza de imposibilidad de alterar una red blockchain, es
adecuada para: los contratos, libros contables, libros de registros, registros automotores, historias
clínicas, escrituras de propiedades y todo tipo de proyectos donde se necesiten registrar datos y que
sean confiables. Para todos estos casos, este tipo de red es ideal.

Blockchain Federal Argentina (BFA): plataforma multiservicios abierta y participativa pensada para
integrar servicios y aplicaciones sobre blockchain.
● Sin criptomoneda.
● Modelo liviano.
● Permisionada.
● Transacciones gratuitas.
● Almacenamiento Off-Chain.
● Software libre.

Ventajas:
● Naturaleza distribuida: cada nodo de la red es capaz de replicar y almacenar una copia de la
base de datos y, como resultado de esto, no hay un “single point of failure”: un único nodo que
se desconecta no afecta a la disponibilidad o seguridad de la red.
● Estabilidad: es muy improbable que los bloques confirmados sean revertidos, lo que significa
que una vez que los datos han sido registrados en la blockchain, es extremadamente difícil
eliminarlos o cambiarlos
● Sistema trustless: no requiere confiar en terceros y reduce también los costos y comisiones
por transacción al suprimir intermediarios y terceras partes.
● Incorruptible: la alteración de la información contenida en los bloques se vuelve algo
prácticamente imposible. Para empezar, siempre que se desee cambiar cualquier dato de un
bloque, es necesario cambiar todos los bloques de esa cadena. Y eso significa también
rehacer todo el proof-of-work asociado a los bloques.
● Mayor velocidad: la ausencia de una autoridad central o intermediarios hace que la
información esté al alcance de todos los participantes de la red in situ. La simplificación del
proceso de transmisión de datos lleva inherente una mayor velocidad.
● Transparencia: ofrece una visión más clara de la procedencia de las transacciones.
Cualquiera puede consultar las transacciones en el registro, incluso verificarlas.
● Trazabilidad: cada bloque de la cadena almacena información y los bloques se encuentran
vinculados entre ellos. Gracias a ello, las organizaciones pueden rastrear la información de
forma más sencilla y procesar el historial de forma permanente. Se crea así un mecanismo
de trazabilidad que puede ayudar a las organizaciones a hacer un seguimiento único de
cualquier transacción.
● Libre de errores: como existe una red de nodos que comprueban los datos constantemente, y
como la información es acordada por todos, los resultados son siempre comprobados y
correctos. Y como existe una red de nodos, cada uno con una copia de la blockchain, la
información contenida en ésta difícilmente pueda perderse.

Desventajas:
● Ataques del 51%: ocurre si una entidad logra hacerse con el control de más del 50% del
hashing power de la red, lo que eventualmente podría permitirle desorganizar la red mediante
la exclusión o modificación intencionada del orden de las transacciones.
● Modificación de datos: el cambio de datos o código de una blockchain es habitualmente muy
complicado y, a menudo, requiere de un hard fork -por el que una cadena es abandonada, y
una nueva es retomada.
● Claves privadas: blockchain utiliza criptografía asimétrica, donde cada cuenta de la
blockchain dispone de dos claves correspondientes: una clave pública y una clave privada.
Los usuarios necesitan sus claves privadas para acceder a los datos. Si un usuario pierde su
clave privada, perderá también sus datos (en el caso de BTC dinero), y no hay nada que pueda
hacerse al respecto.
● Ineficiente: las blockchains, especialmente aquellas que usan Proof of Work, son altamente
ineficientes ya que consumen más energía que muchos países como Dinamarca o Irlanda.
● Almacenamiento: los libros contables blockchain pueden crecer mucho con el paso del
tiempo.
● Apertura: al ser una red abierta, cualquiera puede consultar los datos de otro.

Posibles ataques: el protocolo de blockchain resuelve ambos problemas


● Doble gasto: defecto potencial del dinero digital por el que una misma moneda digital (token)
puede gastarse más de una vez. Esto es posible porque cada moneda consta de un archivo
digital que puede duplicarse o falsificarse.
● Redes fantasma: red impostora.

Blockchain as a service (BaaS): el alojamiento en la nube de aplicaciones blockchain es un servicio


ofrecido por terceros para empresas que desarrollan aplicaciones blockchain. Estos servicios
permiten a las empresas utilizar redes basadas en la nube para sus aplicaciones blockchain,
eliminando la necesidad de establecer y mantener sus propias infraestructuras. Esto les brinda
flexibilidad, escalabilidad y acceso a la experiencia técnica de los proveedores de servicios en la nube
especializados en blockchain.

¿Cómo funciona?: un proveedor de BaaS configura y administra la tecnología y la infraestructura


blockchain para un cliente. El cliente paga una tarifa al proveedor de BaaS por el uso del servicio. Es
responsabilidad del prestador del servicio mantener en funcionamiento la infraestructura. Puede
implementarse un SLA.

Factores determinantes para elección de plataforma BaaS:


● Integración con contratos inteligentes: dado que las plataformas BaaS son inmutables, las
pruebas y la implementación de contratos inteligentes son bastante complicadas para los
desarrolladores. Es crucial tener en cuenta que blockchain como empresa de servicios le
proporciona la integración de contrato inteligente con la implementación.
● IAM (Identity Access Management) Platforms: la integración de una plataforma de gestión de
identidades hará que la red blockchain sea totalmente segura y podrá otorgar permisos a las
personas.
● Runtimes y Frameworks diferentes: algunos proveedores de BaaS solo admiten un tipo de
implementación de blockchain empresarial. Elegir un BaaS que admita una amplia gama de
entornos de ejecución y marcos ayudará a aportar flexibilidad y portabilidad.
● Mecanismos de consenso basados en la identidad: la prueba de trabajo no ofrece la
escalabilidad suficiente que necesita la solución de nivel empresarial. Por lo tanto, ante un
escenario de gran escalabilidad, se debe tener en cuenta que los proveedores de blockchain
como servicio trabajen en un mecanismo de consenso que no dependa del cálculo, sino de
un algoritmo de consenso basado en identidad.

Análisis de costos - oferta de BaaS frente a blockchain on premise: el costo de una aplicación
Blockchain on premise incluye gastos iniciales, de retiro y operativos, así como el desarrollo e
implementación de contratos inteligentes. En contraste, una aplicación alojada en la nube a través de
BaaS tiene un costo basado en el uso real, con tarifas por hora de CPU asignada. Esto significa que
solo se paga por los servicios utilizados, lo que puede resultar más económico y flexible en
comparación con la infraestructura propia.

PREGUNTAS DE PARCIAL

1. Indicar V o F. Big data depende en gran medida de la nube, pero no es la nube por sí sola la
que crea riesgos de seguridad de big data. Tendencias como “Bring Your Own Device”
pueden introducir fácilmente riesgos en las redes empresariales.
La afirmación es incorrecta porque Big Data no depende exclusivamente de la nube. Aunque la nube
ofrece ventajas significativas en términos de escalabilidad y procesamiento distribuido, es posible
implementar y utilizar tecnologías de Big Data en infraestructuras locales sin necesidad de utilizar la
nube.
Además, es cierto que la nube introduce ciertos riesgos de seguridad para los datos, como el acceso
no autorizado o la pérdida de datos, aunque estos riesgos pueden ser mitigados con prácticas de
seguridad adecuadas.
En cuanto a la tendencia "Bring Your Own Device" (BYOD), es cierto que puede introducir riesgos de
seguridad en las redes empresariales, ya que el uso de dispositivos personales no gestionados puede
aumentar la exposición a amenazas y vulnerabilidades. Sin embargo, BYOD no está directamente
relacionado con la nube en este contexto.
Por lo tanto, la afirmación original es falsa porque Big Data no depende exclusivamente de la nube y
porque la introducción de riesgos de seguridad en las redes empresariales no se debe únicamente a
la nube, sino también a otras tendencias como BYOD.

2. Seleccione una opción. Un block en blockchain contiene:


a. Un puntero al bloque previo.
b. Información de valor por la que se creó el bloque.
c. Referencia que permite conectar la información almacenada en el block con algún
elemento identificado del mundo físico con el cual se relaciona.
d. Timestamp.
e. Todas las opciones anteriores son correctas.
f. a, b y d.
g. Ninguna de las anteriores.

PREGUNTAS DE FINAL

1. Indique V o F. Incluir la tecnología de blockchain en una solución que no tiene como factor
crítico el acceso a una red, convierte a ese acceso en un factor crítico.
Arquitectura de Software

ARQUITECTURA DE SOFTWARE

Definición: define de manera abstracta el conjunto de estructuras que componen a un software. Son
elementos de tecnología, relaciones y propiedades entre ellos. Un arquitecto de software no es un
diseñador.

Objetivos: los sistemas de software son construidos para satisfacer los objetivos del negocio.

Consiste en: Estructuras → Elementos → Relaciones (consiste en que las estructuras -que están
formadas por elementos- se relacionen). La arquitectura omite ciertos detalles internos de cada
elemento, se abstrae de su dificultad, y se ocupa de lo exterior.
● Interfaces: dividen lo privado de lo público. Se centra en la complejidad de la interacción de
los elementos.

¿Por qué es importante?/Cosas importantes a tener en cuenta:


● Manejo de datos.
● Escalabilidad.
● Usuario dependiente de la rapidez, disponibilidad y confiabilidad de los sistemas.
● Cliente preocupado porque se implemente una arquitectura, bajo calendario y presupuesto
seleccionado.
● Project Manager, preocupado porque los equipos trabajen en forma independiente
interactuando con disciplina.
● El arquitecto se ocupa de que los 3 puntos antes mencionados funcionen correctamente y en
forma sincronizada.

Interesados: en líneas generales, todos.


● Clientes: les importa que la aplicación tenga los datos correctos sobre ellos y que la
aplicación esté disponible.
● Usuarios: disponibilidad, accesibilidad y resguardo de la información.
● Project Manager:
● Arquitecto:
● Desarrolladores: porque desarrollan dentro de la arquitectura definida.
● Testers:

Decisiones a tener en cuenta:


● ¿Procesamiento distribuido o no?
● ¿Software dividido en capas? ¿Cuántas?
● ¿Comunicación sincrónica o asincrónica?
● ¿Se depende del sistema operativo?
● ¿Se depende del hardware?

Contexto:
● Técnico
● Negocio
● Ciclo de vida del proyecto
● Profesional
ATRIBUTOS DE CALIDAD

Definición: es una propiedad de medida o de testeo que permite indicar qué tan bien funciona un
sistema y cómo satisfacer las necesidades de los interesados.
● Requerimientos funcionales
● Requerimientos de calidad del sistema
○ Requerimientos no funcionales
● Restricciones: todo aquello que no vamos a poder alcanzar. Nos marca un límite.

Disponibilidad:
● Minimizar las interrupciones del servicio.
● Mitigar posibles fallas que puedan ocurrir.

Tácticas: detección, recuperación y prevención de fallas.

Interoperabilidad:
● Dos o más sistemas pueden intercambiar información vía interfaces y comprenderla.
● Si conocemos las interfaces de los sistemas externos, donde nuestros sistemas operan,
podemos diseñar este conocimiento.

Tácticas:
● Locate: los sistemas que operan deben ser descubiertos en tiempo de ejecución.
● Manage interfaces: agrega o elimina capacidades de una interfaz.

Adaptabilidad: cuánto me cuesta adaptarme y cómo tengo que adaptarme después del cambio. El
riesgo constituye lo que puedo hacer y lo que no puedo hacer para adaptarme.
● Cambio
● Costo
● Riesgo

Performance:
● Tiempo
● Habilidad: de poder adquirir la información que estoy necesitando.

Seguridad: determina cuán segura es la arquitectura de software


● Detectar ataques:
○ Detección de intrusos.
○ Denegación de un servicio.
○ Verificación de integridad de mensaje.
○ Atraso en los mensajes.
● Resistir ataques:
○ Autenticación de actores.
○ Límite de acceso.
○ Encriptación de datos.

Usabilidad:
● Cuán fácil es para el usuario ejecutar una tarea deseada.
● Es una de las formas más fáciles de mejorar la calidad de un sistema.
Capacidad de prueba y testeo: entre el 30% y el 50% del costo de una buena ingeniería en el
desarrollo de los sistemas es absorbida por las pruebas. La arquitectura de software debe estar bien
probada. La única forma de saber si la arquitectura funciona o no, se adapta o no, cumple con las
normativas de calidad o no, es probando. Esto es fundamental para poder garantizar que cumplimos
con todo esto.

Otros atributos de calidad:


● Variabilidad = adaptación al contexto.
● Portabilidad = cambios de plataforma.
● Desarrollo distribuído = diseño del software.
● Escalabilidad = agregar más recursos, como un server.
● Monitoreo = investigar el sistema mientras trabaja.
● Comerciabilidad = no siempre se adapta a lo que necesitamos.

TÁCTICAS DE ARQUITECTURA Y PATRONES

Definición: tener éxito en el diseño de la arquitectura es complejo y cambiante, por eso los
diseñadores buscaron las mejores formas de reutilizar el conocimiento arquitectónico.

Patrón de arquitectura:
● Es un paquete de decisiones de diseño que ya fue utilizado anteriormente y se sabe que
funciona.
● Conoce propiedades que permiten reutilización.
● Describe un class de arquitecturas.

Relación entre: contexto (dónde la organización está situada), solución (qué me puede brindar el
patrón) y problema (qué necesito atender).

ASR (REQUERIMIENTOS DE ARQUITECTURA SIGNIFICATIVOS) EN LOS CICLOS DE VIDA

Los ASR en la arquitectura:


● Reunir los ASRs de los documentos de requerimientos.
● Reunir los ASRs entrevistando a los interesados.
● Reunir los ASRs entendiendo los objetivos del negocio.

La arquitectura en los proyectos ágiles: los métodos y procesos se han agilizado y los proyectos han
tenido que cambiar. En muchas organizaciones existe una combinación de arquitecturas que se
basan en tipos de proyectos ágiles y arquitecturas de paradigmas estructurados. No siempre hay que
caer en lo que ofrece el mercado como solución.

Puntos importantes:
1. Alta satisfacción del cliente cuando se entrega una versión.
2. Si cambian los requerimientos, aunque sea tarde, se adapta bien.
3. Entregas de software: entre semanas y meses, tiempos en general cortos.
4. Hay gran interacción entre la gente del negocio y la gente de IT.
5. Motivación del grupo de trabajo.

GESTIÓN Y GOBIERNO

Definición: quién se hace cargo de la arquitectura de software dentro de la organización.


Evaluación de una arquitectura:
● Arquitecto: debe interesarse por la gestión de proyectos y que estos no tengan deficiencias.
● PM: junto al arquitecto deben trabajar en conjunto para que esos proyectos se desarrollen
bajo la perspectiva de la organización.
● A mayor complejidad de proyectos más útil es la implementación de una arquitectura.

Planificación:
● La planificación de un proyecto sucede constantemente, pero existe un plan inicial para
convencer a la dirección de construir el sistema y dar una idea de costo y agenda.
● El PM debe educar a otros managers para poder corregir desvíos en el desarrollo del
software.

Organización:
● Team leader: gestiona las tareas del equipo.
● Developer: diseña e implementa los subsistemas de código.
● Configuration manager: ejecuta y construye tests de integración.
● System test manager: testeo de sistema y testing de aceptación.
● Product manager: representa el marketing.

ARQUITECTURA CLOUD

Arquitectura cloud:
● Servicios a demanda.
● Acceso único de red.
● Pool de recursos.
● Independencia de ubicación.
● Elasticidad rápida.
● Servicios medidos.

Tipos de cloud: los modelos de desarrollo de cloud se diferencian por quiénes son dueños y quiénes
lo operan.
● Cloud privado: el uso de los recursos es exclusivo, no se comparte.
● Cloud público: los recursos son compartidos.
● Cloud híbrido: algunos de sus aspectos son de carácter público y otros de carácter privado.

Arquitectura en un entorno cloud: el arquitecto necesita prestar atención en la adaptabilidad, la


usabilidad, la interoperabilidad y el testeo, como haría en otra plataforma. Los atributos de calidad
que tienen diferencias y que hay que garantizar, son:
● Seguridad.
● Performance.
● Disponibilidad.

Arquitectura MSA y Monolítica

ARQUITECTURA DE MICROSERVICIOS (MSA)

Definición: estilo de arquitectura en el que una aplicación se desarrolla como un conjunto de


servicios que:
● Interactúan entre sí.
● Ejecutan en su propio proceso y se comunican con mecanismos ligeros.
● Se construyen en torno a capacidades de negocio.
● Pueden desplegarse de forma independiente mediante procesos automatizados.
● Poseen una mínima gestión centralizada.
● Pueden escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías
de almacenamiento de datos.
● Cada microservicio se piensa como una aplicación pequeña.

Principales características de una arquitectura de microservicios:


● Componentización a través de servicios: las MSA utilizan bibliotecas pero su forma principal
de crear componentes de su propio software es segmentarlo en servicios.
○ Componente: unidad de software que se puede reemplazar y actualizar
independientemente.
○ Bibliotecas: componentes vinculados a un programa que se invocan mediante
llamadas a funciones en memoria.
○ Servicios: componentes fuera del proceso que se comunican mediante mecanismos
como peticiones a web services o RPC.
● Utilización de servicios como componentes: se basa en que los servicios son
independientemente desplegables. Resulta en interfaces de componentes más explícitas.
Tiene algunas desventajas:
○ Las llamadas remotas son más costosas que las invocaciones en memoria.
○ Se dificulta el cambio de asignación de responsabilidades entre componentes
cuando los movimientos de comportamientos cruzan los límites del proceso.
● Organizada en torno a funcionalidades de negocio: “Cualquier organización que diseñe un
sistema (definido ampliamente) producirá un diseño cuya estructura es una copia de la
estructura de comunicación de la organización.” (Ley de Conway).
○ Equipos funcionales aislados:
- Incluso los cambios simples pueden llevar a que un proyecto entre equipos
tome tiempo y requiera aprobación presupuestaria.
- Los equipos suelen intentar optimizar su rendimiento introduciendo lógica en
la parte sobre la que tienen control directo.
○ Los servicios son definidos en torno a funcionalidades de negocio. Cada servicio
requiere una implementación amplia de software para el área de negocio a la que
pertenece por lo que los equipos son multifuncionales y poseen la gama completa de
habilidades requeridas.
● Productos, no proyectos:
○ Enfoque de proyecto: el objetivo es entregar una pieza de software que en algún
momento se considerará terminada. Al finalizar, el software se asignará a una
organización de mantenimiento y el equipo que lo creó se disuelve.
○ Mentalidad de producto: un equipo debe poseer un producto durante toda su vida útil.
El equipo de desarrollo asume toda la responsabilidad del software en producción. Se
establece una mejor relación entre el producto y la capacidad de negocio a la que
pertenece. Se concibe al software en una relación contínua en la que se busca cómo
éste puede ayudar a sus usuarios a mejorar sus capacidades en el negocio.
● Smart endpoints and dumb pipes:
○ La lógica de la aplicación se encuentra en los servicios y no en los mecanismos de
comunicación. La inteligencia está en los extremos, no en el canal de comunicación.
○ Los mensajes son coreografiados utilizando protocolos simples en lugar de
protocolos complejos. Los protocolos más utilizados son: HTTP request/response
con resource APIs. Lightweight messaging.
● Gobierno descentralizado:
○ Un gobierno centralizado tiende a estandarizar una única plataforma tecnológica. La
segmentación de una aplicación en servicios permite elegir para cada uno de ellos
cuál es el stack tecnológico que mejor se adapta a sus necesidades.
○ Se suelen implementar patrones de diseño específicos para gestionar los contratos
de los servicios buscando reducir su acoplamiento, limitando la necesidad de un
gobierno central de los contratos.
○ El concepto “You build it, you run it” es quizás la mayor expresión de gobierno
descentralizado.
● Gestión de datos descentralizada:

○ Descentralización del modelo conceptual:


- Bounded Context (DDD): segmenta un dominio complejo en múltiples
dominios delimitados y mapea las relaciones entre ellos.
○ Descentralización de las decisiones de persistencia de datos. Cada servicio
administra su propia base de datos. Hay diferentes instancias de una misma
tecnología y persistencia políglota.
Teorema de CAP: se aplica a soluciones distribuidas y establece que es imposible para un
sistema distribuido de persistencia de datos proveer siempre simultáneamente consistencia,
disponibilidad y tolerancia al particionamiento, aunque siempre vamos a poder asegurar dos
de ellas:
○ Consistencia: cada lectura recibe la escritura más reciente o un error.
○ Disponibilidad: cada request recibe una respuesta no errónea, sin garantizar que
contenga la escritura más reciente. El teorema de CAP no dice nada en cuanto a la
latencia de la respuesta. Si responde, hay disponibilidad.
○ Tolerancia al particionamiento: por lo general los ambientes distribuidos están
divididos geográficamente, donde es normal que existan cortes de comunicación
entre algunos nodos. El sistema debe permitir seguir funcionando aunque existan
fallas que dividan el sistema. El sistema debe seguir funcionando incluso si un
número arbitrario de mensajes son descartados (o retrasados) entre nodos de la red.
Manejo de actualizaciones:
○ Enfoque tradicional de transacciones.
- Alto nivel de consistencia.
- Impone un fuerte acoplamiento temporal.
○ Transacciones distribuidas.
- Alto costo de implementación.
○ Coordinación de servicios sin transacciones.
- Reconocimiento explícito de que la consistencia puede ser sólo consistencia
eventual.
- Los problemas se resuelven con operaciones de compensación.
● Automatización de infraestructura: para generar y desplegar unidades de software o
microservicios en forma independiente necesitamos apoyo de software e infraestructura.
○ Pipeline de entrega contínua (Continuous Delivery).
- Integración contínua del software desarrollado, construyendo ejecutables y
ejecutando pruebas automatizadas sobre éstos.
- Despliegue de componentes en entornos cada vez más similares a
producción.
○ Automatización en la gestión de microservicios en producción.
○ Orquestación de contenedores.
● Diseño tolerante a fallos: la idea es que el sistema pueda seguir operando (igual que antes o
restringido) a pesar de las fallas.
○ Las comunicaciones sobre redes son inherentemente poco confiables.
○ Las aplicaciones se diseñan para ser resilientes y manejar errores, no sólo para
prevenirlos.
○ Fuerte énfasis en el monitoreo en tiempo real de la aplicación.
- Monitoreo de elementos de arquitectura.
- Monitoreo de métricas relevantes del negocio.
● Diseño evolutivo:
○ El diseño modular busca mantener las cosas que cambian al mismo tiempo dentro
de un mismo módulo. La propiedad clave de un componente es la noción de su
independencia de cambio y actualización.
○ Los servicios evolucionan buscando reducir al mínimo el impacto de los cambios en
sus consumidores.
○ Los servicios se diseñan buscando el mínimo acoplamiento posible al contrato de
sus proveedores.
○ La utilización de servicios como componentes posibilita planeamientos de
despliegues más granulares.

Ventajas:
● Facilita el continuous delivery de aplicaciones grandes y complejas. Mejora la mantenibilidad.
○ Descomposición modular de la complejidad.
○ Ciclos de evolución de componentes más desacoplados.
○ Límites y contratos de servicios más explícitos.
● Facilita la incorporación de nuevas tecnologías.
● Permite el despliegue y escalado independiente de servicios.
● Permite organizar los esfuerzos de desarrollo en torno a múltiples equipos autónomos.
● Los servicios son relativamente pequeños:
○ Son más fáciles de entender para un desarrollador.
○ La aplicación inicia en menor tiempo.
● Mejora el aislamiento de fallos.
● Elimina compromisos a largo plazo con un stack tecnológico.

Inconvenientes:
● Aumento significativo de la complejidad.
○ Requiere la implementación de mecanismos de comunicación entre servicios y el
manejo de fallos parciales.
○ Se dificulta el testing de interacción entre servicios.
○ Aumenta la complejidad de implementación, gestión y monitoreo.
○ Se dificulta la detección de errores en tiempo de ejecución.
○ Las herramientas/IDEs están orientadas al desarrollo de aplicaciones monolíticas.
● Complejidad de la arquitectura de persistencia de datos particionada. Son muy comunes las
transacciones de negocio que requieren actualizaciones en repositorios pertenecientes a
múltiples servicios.
○ Las transacciones distribuidas no siempre son una opción.
○ El enfoque de persistencia eventual es más complejo que el enfoque tradicional
transaccional.
● Aumenta el consumo de memoria de la aplicación.

¿Cuándo utilizar un MSA?:


● En diversas situaciones una arquitectura monolítica es la mejor opción ya que, generalmente,
las primeras versiones de una aplicación no tienen los problemas que resuelve este enfoque.
● Si se requiere de una aplicación en el menor tiempo posible se debe considerar que el uso de
una arquitectura elaborada y distribuida ralentizará el desarrollo.
● A medida que una aplicación va creciendo y surgen los desafíos de escalado y segmentación
funcional, se complejiza la descomposición de un monolito en un conjunto de servicios.
● Las MSA tienen serias consecuencias en la operación de la aplicación por lo que existe un
conjunto de capacidades a considerar al evaluar su factibilidad de implementación:
○ Rápido aprovisionamiento.
○ Monitoreo básico.
- Técnico (latencia, disponibilidad del servicio, etc).
- De negocio (cantidades de pedidos).
○ Rápida implementación: generalmente, mediante un pipeline.

ARQUITECTURA MONOLÍTICA

Características:
● La aplicación se construye como una unidad (monolito), una sola pieza.
● Se utilizan las herramientas del lenguaje de implementación para modularizar la aplicación
(clases, funciones, namespaces).
● Todos los módulos se ejecutan dentro de un mismo proceso y sobre un mismo hardware.
● Cualquier cambio implica construir y desplegar una nueva versión de toda la aplicación.
● El escalado requiere que escale toda la aplicación. No escalan fácilmente.

Ventajas:
● Simplicidad.
● Facilidad de desarrollo.
● Facilidad de testeo.
● Facilidad de despliegue.
● Facilidad de operación.
● Facilidad de escalado.

Inconvenientes del enfoque monolítico:


● Hay mucho acoplamiento entre los componentes.
● A medida que la aplicación crece:
○ Aumenta la complejidad del monolito.
○ Aumenta la dificultad de mantener la modularidad.
○ Se ralentiza el tiempo de inicio de la aplicación.
○ Se dificulta la incorporación de nuevas tecnologías.
○Disminuye la fiabilidad. Un error en cualquier módulo puede potencialmente afectar la
disponibilidad de toda la aplicación.
● Escalado ineficiente.
○ Escala toda la aplicación.
○ Todos los módulos ejecutan sobre el mismo hardware.

MONOLITO VS. MICROSERVICIOS

Escalabilidad:

Estructura:
Monolítica Microservicios

MÉTRICAS

Métricas:
● Plazo de ejecución de cambios: desde que un usuario solicitó el cambio hasta que hay una
solución en producción relacionada a ese pedido.
● Tasa de falla en cambios: o bien falla el deploy del cambio a producción (en cuyo caso se
haría un rollback) o, si se deploya correctamente, el cambio presenta algún problema.
● Frecuencia de despliegue: señala qué tan efectivo es el trabajo.
● Tiempo de restauración del servicio: que cada vez que se cae, se levante rápido.

PREGUNTAS DE FINAL

1. Indique V o F. Las arquitecturas de microservicios optimizan el uso de memoria.


Falso. Las MSA requieren más uso de memoria por varias razones. Para empezar, al separar el
sistema en microservicios, se requiere un runtime environment (sean contenedores o VMs) para cada
servicio, además de que cada microservicio podría llegar a estar duplicado en caso de ser de alta
disponibilidad. También suele haber duplicación de librerías. Es importante también tener en cuenta
la memoria utilizada para poder establecer la comunicación entre los distintos servicios.

2. Seleccione las opciones correctas. En la comparación de arquitecturas MSA y monolíticas:


a. Las MSA posibilitan ciclos de evolución de módulos más desacoplados. Verdadero.
Las arquitecturas monolíticas presentan mayor acoplamiento.
b. Las MSA facilitan el monitoreo. Falso ya que ahora hay que monitorear varios
servicios y entornos para asegurarnos de que la aplicación funcione correctamente.
c. Las MSA facilitan la implementación de la arquitectura de persistencia de datos.
Falso ya que por lo general cada microservicio cuenta con su propia arquitectura de
persistencia, siendo esta muchas veces políglota.
d. Las MSA optimizan el uso de memoria. Falso. De hecho, utilizan más memoria.
e. Ninguna es verdadera.

3. Seleccione las opciones correctas. Si utilizamos persistencia políglota:


a. La mejora de la performance de los aspectos de persistencia de una solución
mediante la elección de un tipo de base de datos adecuado para tal fin, puede
acarrear un aumento de la complejidad. Verdadero. Utilizar persistencia políglota
puede aumentar la complejidad del sistema dado que los datos estarán guardados
en diversos formatos y estructuras, lo que requerirá de algún tipo de estandarización
en caso de querer interactuar con todos los datos del sistema. Además, el equipo
deberá de ser capaz de dar soporte a distintas soluciones de persistencia.
b. La mejora de la performance de los aspectos de persistencia de una solución puede
lograrse corrigiendo una mala implementación de una base de datos relacional.
Verdadero. Por ejemplo, se puede mejorar la performance creando índices dentro de
la base relacional y cambiando las estructuras de las queries para reducir el tiempo
de resolución de las consultas.
c. Numerosas bases de datos NoSQL están diseñadas para operar en cluster, lo que
les da capacidad de escalamiento vertical. Falso. Que una DB (independientemente
del tipo de DB que sea: SQL, NoSQL) corra en un cluster, quiere decir que es escalable
horizontalmente, ya que por definición, los clusters crecen en cantidad de nodos.
d. Todas las anteriores.
e. Ninguna de las anteriores.

4. Indique V o F. Siempre se recomienda utilizar la arquitectura de microservicios porque es la


que permite escalar horizontalmente en forma más rápida.
Falso. La elección del tipo de arquitectura a utilizar dependen de las características del sistema que
estemos considerando. Una arquitectura de microservicios no siempre es la recomendada.

5. Indique V o F. La rápida velocidad de despliegue de infraestructura que permiten las


arquitecturas de servicios basados en la nube convierten a la utilización de los mismos en
indispensable para el uso en las empresas de IT. Por este motivo, la utilización de DC
propios pierde terreno en el mercado.
Falso. Las principales causas/factores por lo que se toma una u otra decisión están asociados
predominantemente a uno o varios de los siguientes factores: cuestiones legales, comerciales,
económicas y financieras.

Procesamiento y almacenamiento de datos

PROCESAMIENTO DE DATOS

¿Qué esperamos de una infraestructura de procesamiento de datos?:


● Confiabilidad (del proceso): para que la información obtenida al finalizar el procesamiento
sea confiable.
● Rendimiento: no se puede poner a procesar información y que dentro de mucho tiempo
devuelva el resultado.
● Sustentabilidad económica: una relación costo-beneficio adecuada. No podemos costear un
centro de procesamiento de datos enorme para un volumen pequeño de datos. Alcanzar la
mejor relación costo beneficio para alcanzar la sustentabilidad económica.

¿Qué necesitamos para conformar una infraestructura de procesamiento de datos?:


1. Unidades de procesamiento: procesadores.
2. Unidades de almacenamiento: lugar donde guardamos la información que analizamos.
3. Sistemas de comunicaciones: todos los procesos deben estar comunicados.
4. Software de procesamiento: SW que permite realizar el procesamiento de la información.
5. Software de base:
En función de esto se establece el tipo de infraestructura que voy a tener que montar.
1. Unidades de procesamiento: deben tener las siguientes características
● Confiabilidad
● Disponibilidad
● Tolerancia a fallas
● Escalabilidad: preocuparse por la escalabilidad en cloud no es algo necesario porque se
transfiere al proveedor (se le solicitan más recursos, más OpEx). Al montar una
infraestructura local (CapEx), sí es algo a considerar.
● Compatibilidad: con los sistemas e infraestructuras preexistentes.
● Administración remota: relacionado con la accesibilidad de la infraestructura.
● Mantenimiento en caliente: si se tiene que parar todo para hacer una instalación, pierdo
mucha plata y confianza. Si se tiene que bajar un servidor, el resto de la infraestructura debe
seguir funcionando sin verse perjudicado.

Mainframes y supercomputadoras:

Aspecto Mainframe Supercomputadora

Función Actúa como un servidor de propósito Está orientada a la realización de


básica general, almacena grandes bases de complejos cálculos científicos. Ataca
datos y atiende a miles de usuarios en problemas limitados por la capacidad de
forma simultánea. Ataca problemas cálculo.
limitados por E/S y confiabilidad.

Velocidad Ejecuta millones de instrucciones por Ejecuta miles de millones de operaciones


segundo (MIPS). en punto flotante por segundo (FLOPS).

Sistema Puede correr varios sistemas Típicamente corre un sistema operativo


operativo operativos. con kernel Linux.

Principio Basa su fuerza de trabajo en clusters de Logra su velocidad masiva de


de mainframes (parallel sysplex) y procesamiento mediante parallel
trabajo dispositivos de almacenamiento computing. No se trata de una CPU sino de
compartidos entre mainframes (shared millones conectadas en paralelo.
direct access storage device, SDAS). El
foco está puesto en la performance de
las bases de datos masivas.

Consumo Un data center de una superficie de La temperatura de un supercomputer


de 68x68m consume alrededor de 5 MW. center es cercana a 0ºC con un consumo
energía de energía del orden de 15 MW para los
más potentes.

Memoria Hasta decenas de Tb RAM. Hasta miles de Tb RAM.

Usos de las supercomputadoras:


● Ciencia: predicción de clima (tamaño y zonas afectadas por tormentas extremas,
inundaciones), simulación en base a modelos de funcionamiento del cerebro, choque de
galaxias, dinámica de fluidos. Este es su uso principal.
● Industria: convergencia de tecnologías relacionadas con AI, high performance computing, big
data y cloud.
● Defensa: el Departamento de Defensa de USA realiza simulaciones sobre la evolución
segundo a segundo de una explosión nuclear y de sus efectos y como forma de testear y
perfeccionar armas.

SERVIDORES

Tipos de servidores:
● Rackeables: se compactan las dimensiones y se tienen varios servidores en un mismo rack.
Se encuentran dentro de unos lockers/contenedores especiales para organizarlos, etc.
● Tower: son más antiguos y se colocan en forma vertical.
● Blade: parecido a un rack pero se tienen diferentes niveles.

Virtualización: conceptualmente consiste en la simulación de un componente o entorno que parece


por sí mismo real y autónomo pero no lo es. La conformación de un sistema virtual busca como
objetivo aumentar la optimización de los recursos. Ejemplos de aplicación:
● Servidores virtuales: presentación de recursos como bios, cpu, memoria, almacenamiento,
redes y otros periféricos utilizando porciones de un hardware real subyacente.
● Sistemas de procesamiento: cluster de sistemas de procesamiento que se presentan al
usuario como un único sistema. También se conoce como “virtualización inversa” ya que
consiste en juntar un conjunto de máquinas distribuidas y que actúen como una sola.
● Terminales virtuales: sistemas de acceso local que simulan la ejecución pero se ejecutan en
un sistema remoto.
● Redes virtuales: sistemas que simulan el aislamiento y segmentación lógica con
independencia del medio físico compartido. Ej: VLAN.
● Appliances de seguridad: firewall, ids, siem, etc.
● Almacenamiento distribuido (DSS) y/o remoto (NAS)
● Implementación de servicios de contenedores.
● Sistemas de cluster de servicios.

Usos de la virtualización en IT:


● Infraestructura de procesamiento: se virtualiza infraestructura para poder procesar.
● Infraestructura de almacenamiento.
● Infraestructura de redes.
● Infraestructura de seguridad de la información.
● Infraestructura de software.
● Infraestructura de datacenter.
● Infraestructura de escritorios de trabajo

Servidores virtuales:
● Segmentación lógica de recursos con entidad propia.
● Tienen en mayor o menor medida abstracción del HW subyacente y de su mantenimiento.
● Permiten rápido despliegue: aunque sea propio, se va a comportar como la nube porque lo
estoy virtualizando. Es más rápido porque no es lo mismo levantar un servidor entero, que
levantar una instancia virtual del mismo.
● Los recursos disponibles pueden no ser reales y/o reservados.
● Su existencia permite la optimización del uso del HW: en base a uno puedo tener muchas
instancias virtuales.
● Facilitador del cloud, sin la existencia de los servidores virtuales no existiría cloud (ya que el
trabajo del proveedor es virtualizar su equipamiento y vender el consumo de ese servidor
virtual).
¿Por qué es importante la virtualización?:
● Optimiza el uso de recursos porque se trabajan desde una forma virtual, entonces se pueden
aumentar o disminuir los recursos fácilmente y usar solamente lo que necesitamos.
● Aumenta muy significativamente la velocidad de despliegue y redimensionamiento de
recursos porque como lo instancio y eso es algo inmediato, es mucho más rápido que
levantar un servidor on premise.
● Permite disminuir el tiempo de parada por mantenimiento del hardware.
● Aumenta los niveles de disponibilidad de los servicios: si no se tiene que hacer
mantenimiento del hardware (o se limita a lo mínimo), aumenta la disponibilidad.
● Permite la delegación de la gestión de los recursos: en función de lo que estamos usando o
no. Cuando tenemos una arquitectura on premise, la tenemos aunque esté ociosa.
● Permite consolidar la infraestructura.
● Permite mantener compatibilidad con el hardware real.

Contenedores: son como “orquestadores” de estas máquinas virtuales. Por ejemplo, Docker.
● Optimización de consumo de recursos técnicos y humanos para el despliegue de
aplicaciones especialmente en ciclo continuo.
● Potencia las arquitecturas basadas en microservicios.
● Componentes reutilizables.
● Despliegue rápido:
○ Facilita la integración continua
○ Facilita la administración de entornos
○ Facilita el versionado de entornos

Stack de máquinas virtuales y contenedores:

Orquestación: en infraestructura IT, la orquestación de un servicio consiste en la implementación de


herramientas de software que permitan simplificar la configuración, administración y coordinación de
los componentes de arquitecturas complejas.
● La orquestación de recursos involucra:
○ Procesadores, memoria y dispositivos de almacenamiento.
○ Redes: cómo los vamos a comunicar a través de las redes.
○ Configuraciones.
○ Gestión de cambio.
○ Copias de seguridad.
○ Monitoreo de recursos.
○ Análisis de uso de recursos.
● La orquestación de contenedores involucra: se orquestan todas estas cosas.
○ Administración de nodos (físico/virtual).
○ Pods.
○ Servicios.
○ Contenedores.
○ Almacenamiento.
○ Redes virtuales y puertos.
○ Configuraciones.
○ Monitoreo y logging.

Objetivo: simplificar y agilizar los procesos de aprovisionamiento y operación de los servicios, que
permite además aumentar de manera simple la escalabilidad y disponibilidad de los servicios.

Cluster de procesamiento: un cluster es un conjunto de recursos de procesamiento individuales


llamados “nodos” que pueden realizar una tarea en conjunto.

Objetivo: la finalidad de la conformación de un cluster consiste en aumentar la capacidad individual


de uno de los nodos o bien como contingencia ante la falla de alguno/s de ellos. La configuración de
cada nodo es generalmente de similares o iguales características técnico-funcionales.
La conformación de un cluster permite aumentar la escalabilidad y/o la disponibilidad de un sistema,
logrando así una alta confiabilidad.

Componentes:
● Nodos de procesamiento (CPU/memoria)
● Almacenamiento
● Sistemas operativos
● Conexiones de red
● Protocolos de comunicación y servicios: para comunicar a los nodos.
● Software de aplicación para su gestión

High availability cluster (HA-C)/Failover cluster/Cluster activo-pasivo: es un sistema que mediante la


redundancia de nodos permite aumentar el nivel de disponibilidad del servicio. Se tienen uno o más
nodos pasivos que están en espera para asumir el control de los nodos que salen de operación
normal. Sólo el nodo primario se utiliza para el procesamiento. Cuando falla el nodo primario, un nodo
en espera/secundario/pasivo se convierte en nodo primario. Para que el nivel de servicio no se vea
degradado ante la materialización de la falla, el/los nodos secundarios deberán contar con
características similares de recursos.
El nivel de redundancia (cantidad de nodos) determinará la cantidad de fallas admisibles sin pérdida
de servicio. El sistema seguirá dando servicio mientras exista al menos un nodo operativo.
Load balancing cluster (LB-C)/Cluster activo-activo: en este modo dos o más nodos trabajan en
conjunto de manera simultánea para resolver la totalidad de las cargas de trabajo y que el sistema
pueda escalar. Antes de que la información llegue a los nodos un distribuidor se encarga de distribuir
la carga de trabajo entre los nodos. Este se ubica entre el cliente y la granja de servidores. Este
esquema no tiene alta disponibilidad y puede generar cuellos de botella si un nodo pierde la
información. Como ventaja, aumenta la velocidad de procesamiento y la potencia total del sistema.
De la misma manera, permite disminuir el tamaño del cluster para que acompañe el decrecimiento de
las cargas de trabajo.
En éste tipo de implementaciones, se suele recomendar que las características técnicas de los
distintos nodos sean análogas, ya que si no fuera así, la afectación o desafectación de los distintos
nodos tendrían diferente impacto en el comportamiento de la solución.

No garantiza la disponibilidad. Sí aumenta la capacidad. Se puede procesar mucha más información


que en uno de alta disponibilidad.

High performance cluster (HP-C): está pensado específicamente para explotar el potencial del
procesamiento en paralelo entre múltiples computadoras. Es decir, se cuenta con muchos
procesadores (nodos) que trabajan en conjunto para resolver una operación. Este cluster es el más
indicado para el procesamiento de funciones complejas como simulaciones matemáticas.
Básicamente se posibilita el procesamiento de operaciones complejas, dividiendo las mismas y
realizando procesamiento paralelo distribuido en los nodos. No hay un balanceador de carga, sino
que ingresan los datos y se van distribuyendo para que todos los nodos procesen parte de esa
información en el mismo momento.

Combinación de clusters (LB+HA): es lo ideal porque se aprovechan las ventajas de cada alternativa
pero es más costoso. Tenemos procesamiento que balancea la carga y garantiza la alta
disponibilidad (los nodos están duplicados, redundantes).
Ejemplo de uso: un sitio web tiene grandes cantidades de contenido guardado en una base de datos.
El servidor web (que también puede estar probablemente en un cluster) hace consultas tipo lectura
sobre los nodos de consulta a través de un distribuidor de carga. Las solicitudes de escritura sobre la
base de datos son enviadas al nodo maestro, único con acceso de escritura de datos.

Grid computing: la idea es descentralizar el procesamiento y distribuirlo en nodos organizados en


forma de grilla. Los nodos pueden estar en máquinas distintas. Conjunto de elementos
“heterogéneos” trabajando en conjunto con un fin específico. Factores característicos:
● Descentralización/procesamiento distribuído.
● Diversidad de recursos y dinamismo.
● Administración descentralizada.
Grid computing suele hacer uso de la potencia de computación residual en una computadora de
escritorio conectada a una red, mientras que las máquinas en un clúster están dedicadas a trabajar
como una sola unidad y nada más.

HIPERCONVERGENCIA (HC)

Definición: consiste en una arquitectura de hardware y software que integra conjuntamente cómputo,
almacenamiento, virtualización y redes en un único sistema. En lugar de mantener servidores,
almacenamiento y redes como componentes separados, la hiperconvergencia combina estas
funciones en una plataforma única y escalable. Utiliza una arquitectura x86 y software de gestión
para reemplazar soluciones costosas de hardware existentes.
Objetivo: el problema de las arquitecturas tradicionales es que son complejas de construir y operar,
difíciles de escalar en capacidad y performance y tienen un costo muy elevado.
El objetivo de la hiperconvergencia consiste en aumentar la escalabilidad y flexibilidad, optimizar el
uso de recursos, reduciendo los tiempos de aprovisionamiento y despliegue, disminuyendo a la vez la
complejidad de la administración de los recursos. Logrando además alta confiabilidad del sistema
debido a la gran cantidad de elementos de disponibilidad que incorporan las soluciones.

Forma de trabajo:
● Todas las funcionalidades críticas del datacenter corren en una capa integrada de software
de administración.
● El software de virtualización se abstrae de los recursos físicos y puede asignar
dinámicamente recursos para las aplicaciones en ejecución de las VM o contenedores.
● Las configuraciones se administran por políticas, alineadas con las aplicaciones, eliminando
las necesidades de configuraciones complejas en capas subyacentes.
● Las capas de administración avanzada permiten automatizar tareas reduciendo las tareas
manuales y los tiempos de despliegue y de mantenimiento.

Diferencia entre hiperconvergencia y convergencia: ambas soluciones de infraestructura concentran


los cuatro elementos del datacenter: cómputo, almacenamiento, redes y software.
La diferencia es que la convergencia implica la integración de componentes de infraestructura de TI,
como servidores, almacenamiento y redes, pero no necesariamente en una solución totalmente
integrada. Aunque los componentes están integrados, siguen siendo unidades separadas. Esto
significa que, aunque están conectados y trabajan juntos, aún pueden gestionarse de manera
independiente.
El concepto de convergencia quedó ligado a la reutilización de hardware legado (legacy) al cual se le
incorporó una capa de software para gestionar de manera uniforme recursos heterogéneos.

DISPONIBILIDAD Y ALTA DISPONIBILIDAD

Disponibilidad: es una de las características de las arquitecturas que mide el grado con el que los
recursos del sistema están disponibles para su utilización por el usuario final a lo largo de un período
dado.
Esto está relacionado con el concepto de downtime/offline (tiempo en que el sistema no está
disponible) y también con la percepción de “caída” desde el punto de vista del usuario final. El usuario
va a considerar que el sistema está caído o tiene baja disponibilidad en cualquier circunstancia que le
impida trabajar productivamente con él (desde tiempos de respuesta prolongados o escasa
asistencia técnica).

¿Cómo se mide la disponibilidad?: de primera instancia, todo sistema debe tener establecido un SLA
que defina cuánto tiempo y en qué horarios debe estar en línea. Ejemplos:
● En el caso de aplicaciones de baja criticidad, dicho SLA puede ser de 8×5 horas a la semana
excluyendo días festivos.
● Para sistemas con mayor criticidad como una red de cajeros automáticos se tienen niveles
de servicio que alcanzan las 24 horas al día, los 365 días del año.

Cálculo: vamos a calcular la disponibilidad como: Disponibilidad = ((A – B)/A) x 100%)

Donde: A son las horas comprometidas de disponibilidad y B son las horas fuera de línea (horas de
“caída del sistema” durante el tiempo de disponibilidad comprometido). Por ejemplo: 15 horas por
falla en un disco o 9 horas por mantenimiento preventivo no planeado.
Alta disponibilidad: la disponibilidad de un sistema se suele expresar como un “100% menos el
tiempo que no está disponible”. Por tanto, cuando hablamos de alta disponibilidad, estamos hablando
de un porcentaje muy alto, cercano a 100, por ejemplo 99%, 99.9%, 99.99%, etc.
Con esto, lo que queremos decir, es que el sistema estará funcionando sin problemas, por ejemplo, el
99% del tiempo, es decir, en un año, estaría disponible siempre salvo 3 días y 15 horas
aproximadamente. Y con una disponibilidad de 99.99% solo estaría parado unos 53 minutos. Este
tiempo que el sistema no está disponible puede deberse a fallos imprevistos, pero también a tareas
necesarias de mantenimiento como reinicios, parches de software, etc.

CONCURRENCIA

Definición: concurrencia es la tendencia de las cosas a producirse al mismo tiempo en un sistema.


Dos o más procesos decimos que son concurrentes, paralelos, o que se ejecutan concurrentemente,
cuando son procesados al mismo tiempo, es decir, que para ejecutar uno de ellos, no hace falta que
se haya ejecutado otro. En sistemas multiprocesador, esta ejecución simultánea podría conseguirse
completamente, puesto que podremos asignarle, por ejemplo, un proceso A al procesador Nro 1 y un
proceso B al procesador Nro 2. Cuando tenemos un solo procesador se producirá un intercalado de
las instrucciones de ambos procesos, de tal forma que tendremos la sensación de que hay un
paralelismo en el sistema.

Problema de alta concurrencia: ¿de qué forma puede el sistema sostener un nivel de servicio ante
una alta demanda por parte de los usuarios? Es aquí donde debemos realizar un análisis del tráfico
y/o peticiones que deberá soportar el sistema para poder plantear una solución robusta, escalable y
paralelizable acorde a la demanda.

¿Cómo garantizar la concurrencia?: la forma de validar la capacidad de concurrencia viene de la


mano de las pruebas de concurrencia o stress. Para realizar las mismas se necesita de los casos
funcionales del sistema, la secuencia de uso, la alternancia y cuantificación de cada una de las
acciones sobre el sistema. Por otra parte, se requiere de alguna herramienta que sea capaz de
automatizar el proceso de entradas al sistema. La herramienta se configura para simular los casos en
la cantidad y secuencias definidas. Luego de correr los casos de prueba se evalúan los resultados
sobre los cuales deberá existir previamente una métrica de rangos de tiempo y respuesta esperados.
De la comparación de los resultados obtenidos con el esperado se podrá determinar si el nivel de
concurrencia probado está validado o no. En caso de no ser aceptable/esperado el resultado de las
pruebas, se deberán analizar las causas del desvío y proponer y aplicar las mejoras correspondientes
para que los resultados de las nuevas pruebas generen respuestas dentro del rango admisible.

ESCALABILIDAD

Definición: es la capacidad que posee un sistema o proceso de poder expandir sus capacidades para
satisfacer las necesidades del cliente. Esto puede suceder por necesidades transitorias o
permanentes que van más allá de las capacidades habituales del sistema hasta un momento dado.

¿De qué depende que un sistema sea escalable?: depende de innumerables factores, tales como la
arquitectura de la solución, la tecnología usada, la complejidad de la solución, el costo, entre muchos
otros. Uno de los factores de mayor peso, suele ser el diseño propio de la solución. Un mal diseño
inicial, difícilmente será escalable, salvo que se tomen acciones específicas para que ello suceda.
Sigue la frase “una cadena es tan fuerte como su eslabón más débil” ya que, en general, un
componente del sistema que no permita escalabilidad (o se vea reducido en ésta capacidad), afecta
o limita la capacidad de escalar del sistema entero.
¿Cómo puede escalar nuestro sistema?: puede escalar en forma vertical u horizontal.
● Escalado vertical: consiste básicamente en aumentar la capacidad de uno o varios elementos
concretos de nuestra arquitectura, por ejemplo ampliar la memoria de nuestro servidor, o
sustituir las CPUs por otras de mayor velocidad.
● Escalado horizontal: se basa en aumentar el número de elementos que desempeñan una
determinada tarea, por ejemplo si tenemos un servidor web saturado, añadimos otro para que
se haga cargo de parte de las tareas.

REDUNDANCIA

Definición: consiste en, al menos, duplicar los componentes que realizan un trabajo crítico y cuya
caída provocaría una disrupción del sistema. En el momento en el que un sistema informático maneja
datos críticos, se establece la necesidad de mantener dicho sistema en funcionamiento de forma
segura y continua.

Redundancia de discos duros: los discos duros son los dispositivos donde se graban los datos. El
fallo más común en un servidor es el fallo de un disco duro. Si el servidor tiene solamente un disco y
este falla, podrá fallar el servidor completo y no podremos acceder a los datos contenidos en el
mismo. Existen por ello técnicas que nos ayudan a minimizar este problema y a que el servidor siga
funcionando y no pierda datos incluso cuando falle algún disco duro.
● HotSwap: permite sustituir los discos que fallan sin necesidad de apagar el servidor en
caliente.
● RAID (redundant array of independent disks): es la técnica más común para proveer
redundancia a nivel de disco rígido. Con esta técnica agrupamos un conjunto de discos que
actuarán de manera redundante y nos pueden ayudar tanto a aumentar la velocidad y el
rendimiento del sistema de almacenamiento, como a que el sistema siga funcionando
aunque se presente falla en algún disco.

Redundancia de tarjetas de red: la tarjeta de red es el dispositivo que permite al servidor


comunicarse con el resto del mundo. Es muy común que los servidores tengan como mínimo 2
tarjetas de red, para garantizar que esta comunicación no se corte en caso de fallo de una de las
tarjetas o una de las conexiones cableadas.

Redundancia de fuentes de alimentación: la fuente de alimentación es la encargada de proporcionar


electricidad al servidor. Es común que los servidores tengan dos o más fuentes de alimentación, cada
una de ellas conectada además a diferentes sistemas eléctricos. Lo más normal es que se puedan
sustituir las fuentes de alimentación que fallan sin necesidad de apagar el servidor, es decir en
caliente (HotSwap). Otros componentes del sistema como routers, switches, storage, suelen utilizar
la misma técnica de redundancia.

Redundancia en el suministro eléctrico: un servidor necesita un suministro constante de electricidad


para funcionar. Fallos en este suministro, aunque sean por periodos muy cortos de tiempo, tendrán
consecuencias catastróficas para nuestro sistema. Y no solo necesitamos un suministro constante,
también necesitamos que no tenga subidas y bajadas bruscas de tensión que puedan estropear
componentes electrónicos. Para conseguir esto se pueden utilizar diferentes componentes según el
grado de protección que deseemos:
● SAI (UPS): son baterías que se conectan entre el servidor y la fuente de suministro eléctrico.
Garantizan un suministro constante y estable por un tiempo.
● Generadores eléctricos: pueden suministrar electricidad por un tiempo indefinido siempre que
tengan combustible en el tanque.
● Líneas independientes de suministro eléctrico: en centros de datos grandes, se suelen tener
al menos dos conexiones diferentes e independientes a la red de suministro eléctrico. En
Argentina, no existe más de un proveedor de red eléctrica por zona, por tanto éste tipo de
implementaciones queda limitado, en el mejor de los casos, a recibir dos líneas de tensión
desde diferentes estaciones transformadoras.

Redundancia en los componentes de red: los componentes más normales en una red son routers,
switches, access points, tarjetas NIC, cables de red, etc. Cualquiera de estos componentes puede
fallar, dejando al sistema incomunicado. Pero existen técnicas para evitar que esto ocurra, lo que se
suele hacer es configurar la red, para que al menos existan dos caminos diferentes entre dos
componentes A y B.

Redundancia de servidores, balanceo de cargas: ¿qué ocurre si el suministro eléctrico funciona y la


red funciona, pero nuestro servidor falla de tal manera que ninguno de los componentes redundantes
que tiene pueda evitar el fallo y la caída del mismo? Una solución es el balanceo de cargas con
tolerancia a fallos. En este tipo de clusters, no solo no importa que uno o varios de los servidores deje
de funcionar, sino que si necesitamos más recursos para proporcionar un servicio, podemos
incorporar nuevos servidores que incrementen la capacidad de proceso del cluster.
La implementación de éste tipo de soluciones convierte en el componente más crítico a los sistemas
de almacenamiento si los mismos son únicos entre todos los servidores que proporcionan un
servicio.

INTEROPERABILIDAD

Definición: es la capacidad que tienen los sistemas y/o equipos no sólo de intercambiar información
sino de interpretarla y procesarla en un formato amigable a su usuario.
La implementación práctica de la interoperabilidad se basa en el hecho fundamental de compartir
interfaces estándar, es decir, hacer que los sistemas se comuniquen entre sí utilizando un protocolo
de comunicación. Hablar de interoperabilidad refiere a cómo facilitar el intercambio de información
entre entidades o sistemas, a la creación de modelos estandarizados con los que puedan
representarse e intercambiarse datos. ¿Y cómo elegir entre tantos estándares disponibles? ¿Qué
formatos, protocolos y lenguajes son los más adecuados? ¿Cómo podemos determinar cuál es un
estándar abierto? Los estándares abiertos deberán tener, como mínimo, las características
siguientes:
● Disponibilidad.
● Que los derechos de autor estén disponibles, libres de regalías y condiciones.
● Madurez.
● Internacionalmente aceptados.
● De fácil distribución.
● Con amplio soporte en el mercado.

Ventajas de la interoperabilidad:
● Adaptabilidad: los distintos sistemas que absorben la información, se conectan y se
encargan de distribuir dicha información de forma automática y flexible.
● Cohesión de datos garantizada: con la interoperabilidad, la información es gestionada de
forma eficaz y controlada por todas las partes.
● Aumento de la productividad: de la anterior ventaja se puede desprender la idea de que
gracias a esta herramienta, se puede asociar toda la información disponible a la cadena de
valor. De tal forma, se puede trabajar y operar de forma concordante, a lo largo de todo el
proceso productivo, asegurando que la información está disponible y es accesible para todas
las partes, sistemas y personas.

DEVOPS

Definición: es una combinación de development + operations.


Designa la unión de personas, procesos y tecnología para
ofrecer valor a los clientes de forma constante. DevOps
permite que los roles que antes estaban aislados (desarrollo,
operaciones de TI, ingeniería de la calidad y seguridad) se
coordinen y colaboren para producir productos mejores, más
confiables y en menos tiempo. Al adoptar una cultura de
DevOps junto con prácticas y herramientas de DevOps, los
equipos adquieren la capacidad de responder mejor a las
necesidades de los clientes, aumentar la confianza en las
aplicaciones que crean y alcanzar los objetivos empresariales
en menos tiempo.
DevOps establece una intersección entre desarrollo, operaciones y calidad. No existe un marco
estándar de prácticas, sino que su aplicación es flexible según cómo cada organización quiera
llevarlo a la práctica. El objetivo final de DevOps es minimizar el riesgo de los cambios que se
producen en las entregas y dar así un mayor valor tanto a los clientes como al propio negocio.

¿Qué hace un DevOps?:


● Lograr ciclos de desarrollo más cortos (Continuous integration - CI).
● Hacer despliegue continuo, es decir pasar la versión de software a entorno de producción
mucho más frecuentemente (Continuous Deployment - CD).
● Mantener una plataforma estable con un 99% o más de disponibilidad.
● Eficiencia y automatización. Eliminar tareas humanas y manuales.
● Monitorear el rendimiento de una aplicación (performance) recopilar datos en determinado
tiempo (métricas), y en función del análisis de los mismos tomar decisiones en el equipo para
mejorar tiempos de respuesta.
¿Cómo implementar DevOps en la empresa?: una empresa tiene que empezar por adoptar bases de
metodologías ágiles en sus equipos. Al tener estos cimientos sólidos, se crea la necesidad de
implementar metodologías DevOps para acelerar la entrega del software; esto genera la importancia
de capacitar al equipo en herramientas de automatización y tecnologías con el fin de que no exista la
muralla entre operaciones y desarrollo. El objetivo es lograr un solo equipo que va hacia un mismo
objetivo: entregar software de calidad y más rápido.

PREGUNTAS DE FINAL

1. Seleccione las opciones correctas y justifique. ¿En un cluster de alta disponibilidad, cuál de
las siguientes afirmaciones es incorrecta?
a. Se monitorea constantemente el estado de cada nodo. Verdadero.
b. Si se pierde simultáneamente la comunicación entre todos los nodos y estos siguen
funcionando, cada nodo puede erróneamente asumir que el resto de sus pares está
caído e intentar iniciar el servicio que otros ya están corriendo, lo cual puede llevar a
múltiples estados de un mismo servicio. Verdadero.
c. Dado el elevado costo de un cluster de alta disponibilidad (dependiendo de la
cantidad de nodos: no es lo mismo dos que diez), para decidir su utilización se debe
considerar el costo de indisponibilidad (downtime). Verdadero.
d. Todas son correctas.
e. Ninguna es correcta.

2. Indique V o F. En el contexto de servicios de TI, tolerancia a fallas y alta disponibilidad son


sinónimos. Falso.
https://www.linkedin.com/pulse/alta-disponibilidad-vs-tolerancia-fallos-ausilsystems/?origina
lSubdomain=es

3. Indique V o F. El PUE (power usage effectiveness) es una medida orientativa que permite
conocer la potencia de cálculo de un data center.
Falso. Es un indicador que permite medir la eficiencia en el consumo de energía de un data center. Se
calcula como: PUE = Potencia eléctrica total del centro / Potencia eléctrica total consumida por los
sistemas.

4. Las supercomputadoras se utilizan para tareas que requieren extrema fiabilidad y manejo de
un gran número de dispositivos de E/S.
Falso. Se utilizan para aplicaciones que requieren enormes cantidades de cálculos matemáticos.
5. La alta disponibilidad se caracteriza por:
a. Hardware redundante
b. Software redundante
c. Punto único de falla
d. Datos redundantes
e. Todas las anteriores
f. Ninguna de las anteriores

6. Seleccione las opciones correctas. La madurez alcanzada por la virtualización permite:


a. Definir la infraestructura completamente por SW diferenciándose del enfoque
tradicional basado en HW.
b. Crear bloques flexibles de infraestructura que reemplazan a los tradicionales
servidores y almacenamientos separados.
c. Disminuir el riesgo de error humano por aumento de la automatización y la
estandarización en la gestión de la infraestructura.
d. Todas las anteriores
e. Ninguna de las anteriores

7. Indique V o F. La replicación de sistemas y/o datos en un DC remoto es una excelente


herramienta de respaldo.
Falso. Para entender por qué es falso hay que entender la diferencia entre backup y réplica. Un
backup (también llamado copia de seguridad, respaldo, copia de respaldo, copia de reserva, etc) es
una copia de los datos originales que se realiza con el fin de disponer de un medio para recuperarlos
en caso de su pérdida. La copia es inalterable y se realizan varias copias correspondientes a otros
tantos momentos. La replicación, en cambio, es única y cambia periódicamente y, por lo general, se
hace para que un sistema alimente a otro sistema con sus datos.

8. Indique V o F. La creciente demanda de servicios en la nube, junto con la necesidad de


reemplazar el hardware obsoleto y reducir los costos operativos, está llevando a las
empresas a adoptar una infraestructura hiperconvergente.
Verdadero. La infraestructura hiperconvergente, al ofrecer una arquitectura más ágil y escalable, se
alinea con las necesidades de las empresas que buscan integrar eficientemente sus recursos locales
con servicios en la nube.
En cuanto al HW obsoleto, la infraestructura hiperconvergente proporciona una alternativa moderna al
consolidar recursos en una solución integrada y gestionada centralmente. Esto puede facilitar la
transición de la infraestructura heredada a una más eficiente y adaptable. Además, la consolidación
de recursos en una plataforma única, junto con la automatización y la gestión centralizada, puede
conducir a una mayor eficiencia operativa y, por lo tanto, a una reducción de costos.

9. Seleccione las opciones correctas. La principal característica diferencial entre un


mainframe y una supercomputadora es:
a. El mainframe es redundante en todos sus componentes y la supercomputadora
nunca lo es.
b. El mainframe no necesariamente es más costoso de adquirir.
c. Uno está orientado a resolver problemas que requieren gran capacidad de cálculo y
el otro está orientado a resolver transacciones y manejo de operaciones de E/S.
d. El mainframe no permite paralelizar procesos, la supercomputadora está pensada
para eso.
e. Todas las anteriores.
f. Ninguna de las opciones es correcta.

Persistencia de datos

INTRODUCCIÓN
¿Qué es?: es la capacidad de los datos de perdurar a lo largo del tiempo.

Tipos de persistencia:
● Volátil: no necesitan ser almacenados más allá del procesamiento de los mismos.
● No volátil: deben perdurar más allá del procesamiento.

DEFINICIONES BÁSICAS

Transacción: conjunto de instrucciones que se ejecutan como una unidad de trabajo, es decir, de
manera indivisible. El resultado es éxito (todas las acciones ejecutadas) o error (ninguna acción
ejecutada). Debe cumplir con las características ACID.

ACID: conjunto de propiedades propias de las bases de datos relacionales que permiten clasificar las
transacciones de los sistemas de gestión de bases de datos.
● Atomicidad: una transacción debe completarse en su totalidad o no ejecutarse en absoluto.
● Consistencia: cualquier cambio (transacción) debe conducir de un estado válido de la base
de datos a otro estado válido de acuerdo con las restricciones y el esquema de datos. Todos
los nodos deben garantizar la misma información al mismo tiempo, entonces si por ejemplo,
insertamos datos todos los nodos deben insertar los mismos datos, si actualizamos datos
todos los nodos deben aplicar la misma actualización a todos los datos y si consultamos
datos todos los nodos deben devolver los mismos datos.
● Aislamiento: múltiples transacciones ocurren cada una de manera independiente sin interferir
con ninguna otra.
● Durabilidad: una vez completada la transacción, ésta debe conservarse aunque se produzcan
fallos en la base de datos o el sistema completo.

Teorema de CAP: no podemos asegurar las siguientes 3 cosas siempre. Lo que siempre se puede
hacer es asegurar 2. La estrategia se basa en cuál de los 3 no voy a poder asegurar. Para el teorema
de CAP el tiempo no existe. Si uno hace una query y tarda 2 días en resolverse, igualmente se dice
que el sistema está disponible. Si bien en términos prácticos esto podría no ser cierto, en la teoría lo
es. Es por esto que algunos enfoques consideran la latencia.

SISTEMAS DE PERSISTENCIA VOLÁTIL

Sistema de CACHE: la caché es un buffer especial de memoria destinado a almacenar información


de rápido acceso que necesite un sistema particular. La idea es que si se copian los datos más
usados en una memoria ultra rápida volátil, entonces la performance va a mejorar ampliamente.
Primero se busca el dato en la caché, si está se devuelve y sino se va a buscar a la memoria no volátil
(y se considera si se lo debería mover a la caché). Es decir, igualmente el dato debe persistirse en un
medio no volátil y la caché es simplemente una copia. También hay que asegurarse de que los datos
estén actualizados (se tienen que actualizar en la memoria no volátil).
● ¿Cómo se determinan cuáles son los datos que más uso?: no es una pregunta fácil de
contestar y su respuesta puede cambiar con el tiempo.
● Tiempos de acceso: usar caché siempre mejora los tiempos de acceso, incluso cuando hay
miss y el dato se debe ir a buscar al disco.

Sistema MEMCACHE: es una solución de cacheo Free y Open Source utilizado en sistemas
escalables diseñado para acelerar soluciones web dinámicas disminuyendo los accesos a la base de
datos para almacenar o recuperar estructuras de datos. Hay tres comandos elementales:
● SET: acciona la inserción de una Key.
● GET: obtiene el dato identificado con la Key.
● DELETE: elimina el Value y Key.

Sistema VARNISH: más específico. Pensado para soluciones web más dinámicas, cuyo objetivo es
cachear contenido (archivos) que se utilicen frecuentemente. Está diseñado para cachear imágenes,
scripts, css y cualquier contenido de contenido estático. El sistema decide qué información guarda en
el disco duro y qué partes guarda en memoria RAM.
Sistema REDIS: sistema de almacenamiento en memoria pero que también puede ser no volátil.
Utiliza un esquema clave-valor. Es muy utilizado para guardar información de sesiones de usuarios.

SISTEMAS NO VOLÁTILES

Datos estructurados: los datos estructurados son aquellos que guardan o respetan una estructura de
datos que permite, más allá del posicionamiento físico, almacenarlos o recuperarlos de manera
predefinida.

Lenguaje SQL: lenguaje estructurado de tratamiento de datos para interactuar con sistemas de bases
de datos relacionales (RDBMS).

Bases de datos SQL: bases de datos que implementan modelos relacionales estrictos con el objetivo
de garantizar la consistencia de los datos a partir de relaciones.

Bases de datos NO SQL: bases de datos cuyo modelo no busca garantizar la consistencia de los
datos a partir de relaciones sino que tienen por objetivo soportar modelos flexibles que NO requieran
cambios estructurales a partir de la variabilidad de las estructuras de datos a lo largo del tiempo.

Clasificación de bases NO SQL: una solución puede tener más de una forma de persistencia de datos.
● Clave- valor: los datos se almacenan en pares del tipo clave-valor. El valor es un dato de tipo
blob. Ejemplo: Riak, Dynamo, Azure, Redis.
● Column family: permiten almacenar claves mapeadas a valores y esos valores agrupados en
múltiples familias de columnas siendo cada columna un mapa de datos. Ejemplo: Cassandra,
HBase, Amazon SimpleDB.
● Basadas en documentos: la base de datos almacena y recupera documentos que pueden
estar en XML, JSON o BSON. Ejemplo: MongoDB, Couchbase, CouchDB, Lotus Notes, Oracle
NoSQL Database.
● Basadas en grafos: permiten almacenar entidades y relaciones entre esas entidades. Tanto
los nodos como las relaciones tienen sus propiedades asociadas. Ejemplo: Neo4J,
InfiniteGraph, OrientDB, FlockDB

PERSISTENCIA DE DATOS

Persistencia de objetos (ORM): modelo de persistencia distribuida de archivos implementado


generalmente en servicios de nube pública. Ejemplo: amazon simple storage service (S3).
Persistencia de archivos distribuidos: sistema de archivos distribuido para manejo de grandes
volúmenes de datos, rápido acceso y alta disponibilidad. Ejemplo: hadoop distributed file system
(HDFS).

Content delivery network (CDN): sistema distribuido y escalable de entrega de contenidos basado en
minimizar el costo de red entre el punto de distribución y el usuario. Ejemplo: akamai, netflix. La idea
es acercar contenidos pesados a quienes los consumen para mejorar el tiempo de respuesta.
Al entregar contenidos de sitios web de gran escala a una audiencia global, los CDN pueden reducir la
latencia, acelerar los tiempos de carga del sitio, reducir el consumo de ancho de banda y, como
consecuencia de lo anterior, aumenta la calidad percibida por el usuario y disminuye costos de
distribución de los contenidos.
Ejemplo de implementación:

Sistemas de persistencia políglota: de una misma solución poder persistir de diferentes formas.

Persistencia políglota y microservicios: que todos los microservicios que tengan necesidad de
almacenar algo, tengan su propia forma de persistencia, que no necesariamente es la misma.
Ejemplo:

PREGUNTAS DE FINAL

1. Indique V o F. El almacenamiento en caché permite reutilizar de forma eficaz los datos


recuperados o procesados anteriormente. Sin embargo, en los casos en que la búsqueda en
caché falla, el costo total de recuperación de datos se incrementa respecto del escenario sin
caché.
Verdadero. Las memorias caché funcionan por “hit or miss”. En caso de buscar una entrada que no
está en la caché (miss), se tendrá que ir a buscar el dato a disco, por lo que a la operatoria normal (sin
caché) hay que sumarle el tiempo que se tardó en consultar la caché sólo para obtener que la entrada
no estaba allí.

2. Seleccione las opciones correctas y justifique. ¿Cuál de las siguientes opciones no es


verdadera en el contexto del teorema de CAP?
a. La pérdida de comunicación entre algunos nodos es algo que no se puede evitar.
Por lo tanto la tolerancia a las particiones (P) es imposible de lograr en un sentido
estricto. Falso. El teorema de CAP plantea que la tolerancia a partición es posible
pero sólo se podrá garantizar disponibilidad o consistencia.
b. Si se cumple con la disponibilidad (A), los clientes siempre reciben una respuesta
aunque no contenga los datos más recientes. Verdadero. La consistencia podría no
estar garantizada pero la disponibilidad sí.
c. Si se cumple con consistencia (C), todos los clientes reciben el dato más reciente o
un error cualquiera sea el nodo al que se conecten. Verdadero.
d. El cumplimiento de consistencia (C) puede hacerse en forma eventual:
inmediatamente después de la escritura de un dato, la lectura eventualmente lo ve
debido a la replicación asincrónica. No entiendo qué quisieron poner.
e. Todas las opciones anteriores cumplen con la premisa del enunciado.
f. Ninguna de las opciones cumple con la premisa del enunciado.

3. Seleccione las opciones correctas y justifique. El teorema de CAP para sistemas


distribuidos implica que:
a. Puede cumplirse con consistencia, disponibilidad y tolerancia a partición
simultáneamente. Verdadero pues pueden asegurarse 2 de ellas y la última si bien no
puede garantizarse, puede darse.
b. Puede asegurarse el cumplimiento de consistencia, disponibilidad y tolerancia a
partición en todo momento. Falso. Sólo pueden asegurarse 2 de ellas.
c. Para lograr la consistencia y replicar los datos a través de los nodos, se sacrifica la
disponibilidad. Verdadero aunque podría darse la disponibilidad.
d. Si se garantizan disponibilidad y tolerancia a particiones, no es posible conseguir
consistencia parcial en algunas particiones ni siguiera a través de la replicación y la
verificación. Falso ya que el Teorema de CAP no niega que pueda ocurrir, sólo no lo
asegura.
e. Todas las anteriores.
f. Ninguna de las anteriores

4. Indique V o F. CDN es una de las mejores soluciones para la distribución de contenido


multimedia ya que minimiza el costo de red entre el punto de distribución y el usuario. Sin
embargo, esta solución no mejora la latencia respecto de una solución centralizada.
Falso. CDN sí mejora la latencia.

5. En referencia a base de datos explique qué entiende por persistencia políglota, de al menos
un ejemplo y fundamente su elección, de qué tipo de bases de datos (y de ser posible, qué
producto) utilizaría para reporting, manejo de sesiones de usuarios, transacciones bancarias
y catálogo de productos.
La persistencia políglota hace referencia a la coexistencia de distintas tecnologías de
almacenamiento (tanto SQL como NoSQL) dentro de un sistema. La razón de combinar distintas
tecnologías de almacenamiento es poder dar respuesta a las diferentes necesidades de
almacenamiento y poder aprovechar las ventajas de cada tecnología.
Hay que tener cuidado en no caer en una sobre arquitectura y también hay que tener en cuenta que
sumar más de una tecnología de base de datos conlleva mayores costos de administración y
mantenimiento.
● Reporting → NoSQL (MongoDB, documental)
● Manejo de sesiones de usuario → NoSQL (Redis, key-value)
● Transacciones bancarias → NoSQL (MongoDB, documental)
● Catálogo de productos → SQL (SQL Server, Oracle, MySQL)

6. Indique V o F. El teorema de CAP es aplicable a soluciones distribuidas de bases de datos


relacionales.
Verdadero.

7. Se dispone a diseñar la implementación de una solución que incluye un sistema de usuarios


y una aplicación on-premises, un servicio de validación de datos provisto por una entidad
externa vía internet, un servicio de CDN provisto en nube pública. Describa al menos cinco
medidas de seguridad que tendría en cuenta para la implementación de la solución, describa
cómo las resolvería.
● Las comunicaciones con el servicio de validación de datos la haría de manera encriptada con
HTTPS.
● Usaría un sistema de IDS e IPS en mi red para detectar y actuar ante posibles ataques.
● Encriptaría los datos sensibles de mi base de datos.
● Haría backup de los datos cada un período X de tiempo y los guardaría en un sitio distinto al
datacenter.
● Elegiría un servicio de CDN que provea medidas adicionales de seguridad como CloudFlare
por ejemplo, que provee protección a ataques DDoS.

Escalabilidad y almacenamiento on premise

ALMACENAMIENTO DE DATOS

Evolución de los sistemas corporativos:


● Sistemas y almacenamiento centralizado.
● Cajas de discos conectados mediante controladoras de acceso directo (DAS).
● Cajas de discos accedidas mediante redes de almacenamiento (SAN).
● Cajas de discos accedidas mediante redes de datos IP (NAS).
● Sistemas de almacenamiento virtuales (vSAN).
● Servicios de almacenamiento en la nube.

Sistemas de almacenamiento accedidos de manera directa (DAS): accesible mediante controladoras


e interfaces conectadas en forma directa a los servidores implementando protocolos de
comunicación de acceso por bloques. Protocolos: SCSI, SAS, FC.
Ventajas:
● Ancho de banda garantizado. No hay problemas de conectividad.
● Facilidad de configuración y mantenimiento.

Desventajas:
● Escalabilidad: limitada cantidad de puertos disponibles en la unidad de procesamiento que lo
utiliza.
● Invisible para equipos no conectados físicamente

Red de almacenamiento de datos (SAN): accesible mediante controladoras e interfaces conectadas


a través de una red de almacenamiento con protocolos de red para acceso por bloques. Protocolos:
iSCSI, FC, FICON (IBM).

Representación de una red SAN en configuración de alta disponibilidad:

Ventajas:
● Tengo más dispositivos disponibles, los puede usar mucha gente.
● Gran capacidad de ancho de banda.
● Posibilidad de presentar los recursos a todos los miembros de la red SAN.

Desventajas:
● Costos altos por la necesidad de componentes específicos y redundantes de la red.
● Mayor complejidad de administración, suma un componente (SAN) a la infraestructura.

Almacenamiento conectado en red (NAS): consiste en almacenamiento accesible por medio de


redes IP de transferencia de archivos. Los servicios son expuestos bajo protocolos: NFS, CIFS, HTTP,
FTP.

Ventajas:
● Administración del sistema de archivos delegada en el dispositivo NAS.
● Posibilidad de acceso concurrente a los datos administrada por el dispositivo NAS.
● Utilización/reutilización de arquitectura de red de datos existente.

Desventajas:
● Menor rendimiento debido a las capas de abstracción.
● Mayor riesgo por uso de ancho de banda en red de datos, si es compartida con la red de otros
servicios.

NAS, SAN y DAS:

DISPONIBILIDAD DE LOS DATOS

Disponibilidad: es la posibilidad de poder continuar dando servicios de storages ante un evento de


falla en el hardware o software. Ejemplo de elementos que aumentan la disponibilidad:
● Controladoras redundantes.
● Fuentes de energía y ventiladores redundantes.
● Switches redundantes (SAN/NAS)
● Tarjetas con dos puertos o dos tarjetas.
● Protección RAID.
● Discos de repuesto (spare).

Rendimiento (performance): es la métrica usada para definir la velocidad de una sistema de


almacenamiento. Existen 3 métodos de medición:
● Input/Outputs per second (IOPS) – Bases de datos.
● Throughput per second (MB/sec) – Streaming media.
● Response Time – el tiempo que tarda en responder el almacenamiento ante un pedido de la
aplicación (se mide en milisegundos [ms]).

Soluciones para garantizar la disponibilidad de los datos: online vs offline. Factores para la toma de
decisiones:
● Nivel de disponibilidad de los datos para su uso, en términos temporales.
○ Inmediato (online)
○ Diferido (offline)
● Costos de inversión (CaPex) y de explotación (OpEx).

Medidas de resguardo offline:

Dispositivos de almacenamiento en cinta:


● Tapes drives manuales:
○ 1 cabezal de lectura/escritura.
○ 1 cinta.
○ Operación manual.
● Tapes drives semi automáticos (autoloader):
○ 1 cabezal de lectura/escritura.
○ 8 o 9 cintas.
○ Operación automática.
● Tapes drives automáticos:
○ Varios cabezales de lectura/escritura.
○ Varios slots para cintas.
○ Operación automática.
● Tapes Drives Virtuales (librerías Virtuales VTL):
○ Backup a disco que emula tecnología LTO.
○ Emula varios cabezales de lectura/escritura.
○ Emula varios slots para cintas.
○ Operación automática.
○ Mejora los tiempos para realizar el backup y el restore.
○ Utiliza técnicas de deduplicación / compresión para reducir espacio.

EJERCICIO DE PRÁCTICA

Descripción del proyecto: una agencia de seguridad requiere la implementación de una solución
central de consolidación de información a partir de los aportes realizados por diversas agencias
descentralizadas. Para ello, existe un estándar de catalogación de casos a partir de los cuales,
teniendo en cuenta una determinada puntuación, la información recolectada deberá ser puesta a
disposición en una base compartida. Cada una de las agencias descentralizadas tiene actualmente
sistemas propios con distintos niveles de maduración. Por lo cual el consejo de seguridad ha
dispuesto que hasta tanto cada uno de los sistemas evolucione, cada una de las agencias podrá
adoptar el mecanismo de transmisión de información de acuerdo a las posibilidades técnicas
actuales.

Objetivo: se te ha encomendado el diseño e implementación de la solución que sea capaz de recibir


la información desde distintas fuentes de datos, la cual compartirá criterios de catalogación
unificados. A partir de la información recolectada, deberá permitir realizar búsquedas por patrones
identificativos de personas físicas o jurídicas.

Relevamiento: del relevamiento de las agencias descentralizadas, se han identificado los siguientes
posibles mecanismos de reporte de información:
● Carga manual en un sistema provisto a tal fin (a desarrollar por la agencia central). Este será
el método para aquellas agencias que no cuentan actualmente con sistemas robustos.
● Envío de información por correo electrónico con archivo adjunto obtenido desde la salida de
los sistemas locales (con previa definición de protocolo). Este será el mecanismo que
utilizarán las agencias que ya cuentan con sistemas que exportan datos pero que no tienen
posibilidades de definir un protocolo automatizado de intercambio. La carga se realizará
mediante la subida del archivo exportado a la plataforma a desarrollar.
● Reporte automático desde sistemas locales (con definición previa de protocolo) Existen al
menos dos formatos relevados.
● Reporte automático desde sistemas locales, los cuales implementarán el mecanismo de
comunicación definido por la agencia central (API).
Los reportes que expondrá el sistema deberán cruzar la información de las distintas fuentes
permitiendo detectar relaciones directas de información y, por transitividad, vínculos entre personas.
Actualmente existen dos datacenters de la agencia de seguridad central los cuales estarán a
disposición para montar la infraestructura centralizada. Atento al volumen de información
dimensionado, se prevé que los recursos técnicos de conectividad tanto de acceso a internet como
entre ambas locaciones serán suficientes para soportar los sistemas actuales y además albergar
este nuevo servicio. Así mismo, se cuenta con un sistema de gestión de infraestructura que permite
disponibilizar servidores virtuales a demanda en cada uno de los datacenters. El remanente actual de
infraestructura disponible para este servicio consiste en hasta 128 vCPU, hasta 512GB de memoria
RAM y hasta 2TB de almacenamiento aprovisionado en un sistema de almacenamiento convergente.

NOTA: el enunciado no se corresponde con un caso real.

Supuestos:
● Existe capacidad de desarrollo por parte de la agencia central, acorde a las necesidades de la
solución a implementar.

Consideraciones:
● No existe una solución sino alternativas con diferente balance de fortalezas y debilidades.

En base al alcance anterior resuelva:


1. Defina, grafique y detalle la arquitectura de software a utilizar y justifique.
2. Defina, grafique y detalle la Infraestructura de implementación requerida y justifique.

PREGUNTAS DE FINAL
1. Indique V o F. Un dispositivo NAS (Network Attached Storage) es un servidor de propósito
general que habitualmente se utiliza como servidor de archivos.
Falso. Un servidor de propósito general se puede utilizar para hostear cualquier tipo de aplicación
porque posee un sistema operativo de propósito general. En cambio, un dispositivo NAS cuenta con
un sistema operativo dedicado al servicio de archivos mediante protocolos estándar de la industria.

2. Ud. está a cargo de la definición de la arquitectura de software y hardware de una


plataforma que debe recibir los parámetros (X, Y) (longitud, latitud) de celulares a cada
instante de tiempo (cada 0.1 segundos). Defina qué infraestructura de software y hardware
es adecuada para que la aplicación cuente con: alta disponibilidad, tolerancia a fallos y
escalabilidad. Explicar todos y cada uno de los conceptos, su justificación y grafique.
Aclaración: No hay límite de presupuesto para su solución, pero deberá buscar la solución
más económica posible.
De este ejercicio tampoco tengo la respuesta pero voy a escribir mis ideas. Para mi hay dos
alternativas de donde partir a plantear este ejercicio: una es tener la aplicación (software) alojada en
un servidor cloud y la otra opción es tenerla alojada on premise. Las dos pueden llegar a cumplir con
lo que pide la consigna: alta disponibilidad, tolerancia a fallos y escalabilidad pero lo cumplirían de
distintas formas: para cloud básicamente habría que pedirle más recursos al proveedor y la cuota
mensual aumentaría y para on premise habría que adquirir los equipos físicos (después se discute si
se replican los servidores o qué se hace específicamente para cumplir con lo que pide el ejercicio) y
mantenerlos.
Ahora, ¿cuál de estas es más barata? A mi me parece que lo más barato va a ser cloud en este caso y
el ejercicio no da más datos como para tomar una mejor decisión. Lo que pasa es que para mi lo que
querían en este ejercicio era ver si usabas un load balancer o un HAC o ese tipo de cosas, cosa que
se define si es on premise. En ese caso yo usaría ambas. El high availability cluster para garantizar la
alta disponibilidad (si se cae un server sigue el otro) y el load balancer para que la aplicación pueda
escalar horizontalmente. Ahora, para la tolerancia a fallos no sé. El tema es que esto va a ser muy
caro, no podemos duplicar servidores así como si nada. En cambio, si uno opta por cloud tiene la
posibilidad de que la escalabilidad sea elástica: el proveedor asigna más recursos cuando la
aplicación necesita crecer y en momentos de bajas le saca esos recursos.

3. Se desarrolló una aplicación para dar soporte a 100.000 usuarios concurrentes, y la misma
deberá funcional 7x24, es decir, deberá soportar Alta Disponibilidad, Tolerancia a Fallos y
Escalabilidad. La aplicación es de 3 capas (Cliente Web, Application Server y Base de Datos
Relacional).
Existe una baja probabilidad que entren a la vez 100.000 usuarios, pero puede darse el caso.
Antes de la salida en producción, enumere qué tipo de acciones realizaría y cómo las
realizaría para asegurar que la aplicación será un éxito.
Hay que realizar pruebas de stress para ver si la aplicación soporta una alta demanda y también hay
que dar nodos de baja para ver cómo se comportaría la aplicación en caso de que no todos los nodos
estén disponibles (pruebas de alta disponibilidad o de tolerancia a fallos).

4. Usted ha sido contratado como consultor para el diseño de la arquitectura de la


infraestructura de un proyecto web. El mismo estará alojado en un servicio de nube dado
que la empresa es un reciente emprendimiento sin DC propio y no cuenta con inversiones en
HW. Para la selección de la DB dispone de las siguientes opciones:
● Utilización de una instancia de base de datos
● Instalación de motor de base de datos
¿Cuáles son las ventajas y desventajas que observa en cada una de éstas opciones?
Instancia de base de datos: la gestión a nivel motor la realiza el proveedor, y la gestión de
disponibilidad de la misma también, lo que es una ventaja. Es más económica y no posee HW
dedicado. La optimización queda en manos del proveedor para ofrecer una determinada cantidad de
operaciones por segundo. Es menos customizable que la instalación de una DB propia.
Motor de base de datos: la gestión de la DB es propia, existe mayor control de la parametrización de
la misma, requiere de optimización propia, es decir, toda la responsabilidad del mantenimiento recae
sobre el equipo. Podría contar con HW dedicado, en cuyo caso el mantenimiento y disponibilidad
también recaen en el equipo. Entonces, como ventaja podemos decir que es más parametrizable pero
como desventaja podemos decir que requiere mucho más mantenimiento por parte del equipo.

5. Indicar V o F. Las características de escalabilidad de una aplicación se definen en tiempo de


implementación, el cual constituye el momento en que se configuran los elementos que
participan en la misma.
Falso. Las características de escalabilidad se definen en etapas anteriores:
● En la etapa de análisis justamente se analiza con el cliente cuál será el requerimiento de
escalabilidad. ¿Cuánto se espera que la aplicación crezca?
● En la etapa de diseño se define la arquitectura para lograr la escalabilidad deseada.

6. Proponga una solución informática para prestación de servicio web que requiera
protecciones de disponibilidad, confidencialidad e integridad.
Integridad:
● Utilizaría una base de datos relacional ya que cumple con integridad referencial.

Confidencialidad:
● Utilización de FW de aplicación y FW de base de datos.
● Utilización de HTTPS como protocolo para transmitir datos encriptados.
● Virtualización de red para disponibilizar sólo servicios específicos. Los demás serían
privados dentro de la red.

Disponibilidad:
● Uso de HAC (High Availability Cluster).
● Replicación de la/s base/s de datos.
Cloud

CLOUD COMPUTING

Definición: cloud computing es un modelo para permitir el acceso ubicuo (sin un lugar físico
especificado), conveniente y bajo demanda a través de la red a un conjunto compartido de recursos
informáticos configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios)
que se pueden aprovisionar y lanzar rápidamente con un mínimo esfuerzo de gestión o interacción
del proveedor de servicios.

HABLAMOS DE OPEX (COSTO OPERATIVO) PORQUE EL CONSUMO SE PAGA MENSUALMENTE


COMO UN SERVICIO. SI TUVIÉRAMOS TODA LA ARQUITECTURA PROPIA SERÍA CAPEX. EL OPEX SE
ADECUA A LO QUE CONSUMO.

Características esenciales:
1. Autoservicio bajo demanda: un cliente puede proporcionarse capacidades de cómputo de
manera unilateral, como tiempo de servidor y almacenamiento en la red, según sea necesario
de forma automática sin necesidad de interacción humana con cada proveedor de servicios.
2. Amplio acceso a través de la red: las capacidades están disponibles a través de la red y se
accede a ellas mediante mecanismos estandarizados que promueven el uso de plataformas
heterogéneas de clientes por parte de clientes (por ejemplo, teléfonos móviles, tabletas,
notebooks y puestos de trabajo).
3. Conjunto compartido de recursos: los recursos informáticos del proveedor se combinan para
brindar servicios utilizando un esquema compartido entre múltiples clientes, con diferentes
recursos físicos y virtuales asignados dinámicamente y reasignados de acuerdo con la
demanda de quien consume. En algún lugar físico están los recursos. Para el prestador de
este servicio es más redituable conocer la demanda que tiene que proveer, que desconocerla
(es decir, le conviene los clientes que tienen un consumo “estable” o “predecible”, que
aquellos que consumen el servicio en forma impredecible). Se relaciona con la elasticidad.
4. Rápida elasticidad: las capacidades pueden ser aprovisionadas y desplegadas elásticamente,
en algunos casos automáticamente, para escalar rápidamente aumentando y disminuyendo
de acuerdo con la demanda. Para el consumidor, las capacidades disponibles para el
aprovisionamiento a menudo parecen ser ilimitadas y pueden asignarse en cualquier
cantidad en cualquier momento. Tiene un costo inmenso. Se debe poder adecuar a la
elasticidad de los clientes y poder crecer rápidamente si fuera necesario.
5. Servicio medido: los sistemas en cloud controlan y optimizan automáticamente el uso de
recursos al aprovechar una capacidad de medición en algún nivel de abstracción apropiado
para el tipo de servicio (por ejemplo, almacenamiento, procesamiento, ancho de banda y
cuentas de usuario activas). Se debe poder cuantificar todo el consumo para luego poder
cobrar por él mismo.

MODELOS DE SERVICIO

Software as a Service (SaaS): la capacidad proporcionada al consumidor es utilizar las aplicaciones


del proveedor que se ejecutan en una infraestructura de nube. Se puede acceder a las aplicaciones
desde varios dispositivos, como un navegador web (por ejemplo, correo electrónico basado en web) o
una interfaz de programa.
Platform as a Service (PaaS): la capacidad proporcionada al consumidor es implementar en la
infraestructura en la nube aplicaciones creadas por el consumidor o adquiridas creadas con
lenguajes de programación, bibliotecas, servicios y herramientas compatibles con el proveedor. Se
despliegan aplicaciones en una plataforma.

Infrastructure as a Service (IaaS): la capacidad provista es aprovisionar procesamiento,


almacenamiento, redes y otros recursos informáticos fundamentales donde el consumidor puede
implementar y ejecutar software arbitrario, que puede incluir sistemas operativos y aplicaciones. Un
ejemplo de esto sería AWS.

Container as a Service (CaaS): la capacidad provista es aprovisionar container engines, orquestación


y otros recursos informáticos fundamentales donde el consumidor puede desplegar uno o más
containers (a diferencia de PaaS donde se despliegan aplicaciones). Aca se despliegan contenedores,
y se trabaja dentro de los mismos.

MODELOS DE DESPLIEGUE

Private cloud: la infraestructura se proporciona para uso exclusivo por una sola organización que
comprende múltiples consumidores (por ejemplo, unidades de negocios).

Community cloud: la infraestructura se proporciona para uso exclusivo de una comunidad específica
de consumidores de organizaciones que tienen inquietudes compartidas. Un cierto grupo comparte
los recursos. Como el grupo es selecto, se dice que es privado, pero como comparten los recursos
entre ellos, se dice que es público.

Public cloud: la infraestructura está prevista para uso abierto por el público en general.

Hybrid cloud: la infraestructura es una composición de dos o más distintas (privada, comunitaria o
pública) que siguen siendo entidades únicas, pero están unidas por una tecnología patentada o
estandarizada que permite la portabilidad de datos y aplicaciones (por ejemplo, la explosión de la
nube para el equilibrio de carga entre nubes).

Crecimiento en IaaS, PaaS, SaaS y Serverless:


● Las empresas con infraestructuras antiguas están reemplazando el hardware con IaaS.
● Los departamentos de TI de todo el mundo utilizan SaaS para proporcionar a sus empleados
aplicaciones empresariales (como aplicaciones de correo electrónico, almacenamiento y
procesamiento de textos), así como para proporcionar aplicaciones a los clientes, como el
seguimiento de paquetes para una empresa de logística o un catálogo y un carrito de
compras para una empresa de comercio electrónico.
● La cantidad de ofertas para PaaS continúa creciendo con compañías como Google, Amazon
y Microsoft que ofrecen plataformas específicas para las aplicaciones y la infraestructura
subyacente que desean los clientes.
● Amazon, Google e IBM también ofrecen opciones de serverless computing, también
conocidas como cloud functions.
● Serverless permite a los desarrolladores cargar código solo para funciones individuales y
hacer que se ejecuten sin preocuparse por la máquina o los problemas de carga. Es el uso
por un tiempo específico.
Si la informática empresarial tradicional era como comprar un automóvil y cloud computing
tradicional era como alquilarla por un día, serverless es como tomar un taxi.

TODO COMO UN SERVICIO

Definición: de la oferta mencionada en el Gartner Hype Cycle remarcamos:


● Windows as a Service: esto no se ajusta a la definición tradicional de XaaS. El usuario todavía
tiene una versión del sistema operativo (SO) que se ejecuta en su computadora, pero la
administración y las actualizaciones del sistema operativo son transparentes para el usuario
y se administran en la nube. El sistema operativo no tiene versión en la mayoría de los
aspectos porque se está actualizando continuamente.
Si bien la mayoría de la oferta XaaS se ajusta a las definiciones tradicionales, serverless computing
es difícil de definir. No hay máquinas virtuales para crear y el proveedor de PaaS descubre la mejor
manera de ejecutar sus funciones. ¿Dónde pondríamos serverless computing en el modelo actual? Y
Windows as a Service da vuelta las definiciones en nuestra cabeza al hacer que el cliente sea el
sistema operativo en lugar de una aplicación tradicional. Claramente las definiciones que tenemos no
siempre se aplican.

PREGUNTAS DE FINAL

1. Indicar V o F. En caso de contar con los recursos adecuados, siempre va a convenir usar un
datacenter local porque de esta manera no tenemos problemas con datos sensibles.
Falso. Utilizar un data center local no garantiza la seguridad de los datos sensibles. Se deberán
adoptar las medidas de seguridad necesarias para protegerlos de acuerdo a la Ley de Protección de
Datos Personales.

2. Seleccione las opciones correctas. Cuáles son unas ventajas de una arquitectura cloud
respecto de una arquitectura on-premise. No sé cuál es la correcta.
a. Permite desentenderse totalmente de la política de seguridad. Si bien el proveedor
de cloud puede garantizar cumplir con ciertos estándares de seguridad, esto le sigue
competiendo a la organización y también debería aplicar prácticas de seguridad en el
desarrollo del código de la aplicación.
b. La arquitectura on premise siempre es más barata que trabajar con cloud porque no
tiene OpEx. La arquitectura on premise sí tiene OpEx (gasto eléctrico, mantenimiento,
etc).
c. En cloud siempre el RTO tiende a 0. Si tuviera que marcar una como verdadera sería
esta pero no sé si siempre es así. De hecho esto es algo que se acuerda con el
proveedor en el SLA.
d. Todas son correctas.
e. Ninguna es correcta.
3. Seleccione las opciones correctas. La implementación de tecnología basada en servicios de
infraestructura en cloud (IaaS) permite trasladar al proveedor de servicios las siguientes
cuestiones:
a. Mantenimiento del hardware físico. Verdadero. El proveedor de servicios es quien es
dueño de la infraestructura y quien deberá mantenerla.
b. Mantenimiento del hardware virtual. Falso. Esto es responsabilidad del cliente
aunque a veces depende del modo de contratación.
c. Disponibilidad de las aplicaciones desplegadas en los servidores. Es falsa porque la
disponibilidad de la aplicación no depende exclusivamente de la infraestructura.
d. Confidencialidad y disponibilidad de los datos almacenados. Falso, esto debe ser
asegurado por el cliente, quien deberá implementar las medidas de seguridad que
considere necesarias de acuerdo a los datos que maneja.
e. Ninguna de las anteriores.

4. El RPO se encuentra directamente ligado a los sistemas de resguardo de información, a


diferencia de RTO que se encuentra ligado a los mecanismos de disponibilidad
implementados.
Verdadero, la posible pérdida de datos ante un incidente siempre dependerá de los mecanismos que
existan para obtener los datos consistentes más próximos al momento de falla, mientras que el
tiempo de recuperación ante incidentes dependerá de la velocidad en la que se recupere el servicio
pudiendo ser ésta en el mejor de los casos instantánea de manera que sea imperceptible para el
usuario del sistema.

5. Seleccione las opciones correctas. A la hora de implementar una solución que requiera
infraestructura informática, tomaría como primera opción la nube pública cuando: (Es
cualquier cosa esta pregunta)
a. Siempre que no pueda disponer de los recursos informáticos propios requeridos en
el tiempo necesario. Yo no la marcaría porque si bien me parece que en este caso
hay que ir a cloud, no siempre va a ser cloud público, podría ser cloud privado. Pero el
resuelto la marca como verdadera y dice que el único condicionante podría ser el
tiempo de acuerdo comercial.
b. Cuando el costo de operación de infraestructura virtual sea menor al de
infraestructura propia. Falso.
c. No existe capacidad ociosa en la infraestructura propia. El resuelto dice “falso, si así
fuera se dejaría de adquirir infraestructura para nuevos servicios”.
d. El nivel de demanda de los servicios es heterogéneo y se puede estimar. El resuelto
pone “verdadero, el escenario más complejo para una inversión es el
desconocimiento de la demanda, por ende su ROI se presenta inestimable, por eso
los nuevos startup arrancan”.
e. El sistema tributario de la aplicación presente mayores beneficios por OPEX SOBRE
CAPEX. El resuelto pone “verdadero, busca maximizar la ganancia”.
f. Ninguna de las anteriores.

Redes de datos

IMPORTANCIA

¿Cuál es la importancia?:
● Nos permiten acceder a sistemas remotos, nos permiten intercambiar datos.
● La disponibilidad de acceso a los sistemas informáticos remotos, depende de la
disponibilidad de las redes de datos.
● Los sistemas de alta disponibilidad de los servicios informáticos dependen de las redes de
datos.
● La disponibilidad de las redes depende de medios físicos (cables, antenas, microondas y
activos de red) y lógicos (protocolos y accesos).

SERVICIOS DISPONIBLES

Tipos de servicios:
● Enlaces de acceso a internet.
● Enlaces punto a punto (P2P).
○ Redes privadas virtuales (RPV).
○ LAN to LAN (L2L).
● Enlaces punto a multipunto (P2MP).
● Fibra oscura.

Implementación de servicios sobre MPLS: es un esquema para dar alta disponibilidad a la red, que
propone implementar un layout de anillos (switches) redundantes y con nodos interconectados.
Contiene múltiples pasos entre los puntos de interconexión. Si uno se queda sin conexión, se puede
switchear por otro. Nunca un nodo va a quedar incomunicado.

● Desde los nodos se realiza la comunicación a los distintos clientes, denominada “última
milla”.
● Para dar alta disponibilidad en el cableado hacia el cliente, se puede implementar en la
“última milla” caminos disjuntos.
● Para asegurar todo el circuito, se debe implementar “última milla” desde distintos nodos de la
red MPLS, porque si falla ese nodo y tenés todo conectado a él, te quedás sin conexión.

Redes WAN: SD-WAN (Software Defined WAN) vs. MPLS.


Notar que en MPLS no se necesita Internet para que los nodos secundarios se conecten al primario,
mientras que en SD-WAN sí.

Enlace por Fibra Óptica: es el cable más eficiente, de gran AB y baja latencia, no requiere
mantenimiento, pero no está libre de un incidente. ¿Qué pasa si se rompe el cable? En este caso,
quizás una buena opción es evitar el tendido subterráneo (lo que ahorra costos de despliegue) e
implementar alguna otra alternativa, que también tendrá sus desventajas y riesgos.
● Enlace por radiofrecuencia: permite unir dos puntos con línea de vista distantes a muchos
kilómetros, es económico y de bajo mantenimiento, pero no está libre de las inclemencias
climáticas. En este caso estamos sujetos al clima.
● Enlace satelital: llega a prácticamente a cualquier locación y tiene un despliegue rápido, pero
no está libre de las inclemencias climáticas.

CONCEPTOS DE DISTRIBUCIÓN DE REDES

Componentes del modelo “CORE”: cómo es el camino entre los distintos nodos de una red para
garantizar la contingencia y que se genere un camino activo en caso en que haya una disrupción:
● CORE: es el núcleo de distribución. Cómo se hace la distribución en los distintos nodos. Se
puede hacer en forma horizontal (spine-leaf) o vertical (traditional 3-tier).
● DISTRIBUTION/AGREGATION: conecta el core con los equipos de acceso.
● ACCESS: conecta los terminales.
ALTA DISPONIBILIDAD EN REDES DE DATOS LAN

Modelos de distribución interna:

Componentes del modelo “SPINE-LEAF”:


● Los SPINE trabajan “agrupados entre sí” manteniendo todos los caminos activos hacia los
LEAF.
● Los LEAF, creen estar conectados a un único SPINE, que luego redirigen a sus horizontales.
● La ventaja que me permite es la escalabilidad horizontal.
● Mayor ancho de banda, todos los caminos activos.
● Menor latencia, menos saltos. Porque no voy escalando en un nivel vertical.

Con qué contamos en las redes WIFI (Concentradores + APs):


● Controladores con autosensado de señal entre los AP y regulación de potencia.
● AP con regulación de potencia comandada por el controlador.
● Bloqueo de señal no permitida mediante interferencia automática desde los AP.

Transporte físico:

Cableado estructurado: disponibilidad también implica un orden de cableado, una organización de tal
manera que me permita realizar un cambio de manera sencilla.

Herramientas de seguridad de la información dentro de una arquitectura de


soluciones

FIREWALL

Definición: es un dispositivo de comunicaciones que permite restringir el acceso entre diversas redes
a través de ACLs. Es como una barrera entre una red privada y las redes públicas. Todo aquel tráfico
que no esté en la lista de control de acceso no va a ser permitido. Hay muchas reglas que se pueden
definir pero las más comunes son accept, reject y drop. ¿Cómo se pueden definir estas reglas? hay
dos estrategias básicas a seguir:
● Todo aquello que no está explícitamente permitido está prohibido.
● Todo aquello que no está explícitamente prohibido está permitido.

Firewall de aplicaciones: se utiliza para controlar el acceso a una aplicación o servicio web.
Firewall de bases de datos: provee una medida adicional para proteger el motor de base de datos.
Tiene muchas funciones pero la principal es que permite trabajar con un mayor nivel de discreción de
los permisos que puedo otorgar sobre la base de datos.

IDS e IPS

Definición: son sistemas de detección de intrusos. Es lo que pasa si se logra derribar el firewall. Se
trata de evitar que el ataque vaya directamente sobre el servidor. El IPS actúa como una segunda
capa del firewall.

IDS (intrusion detection system): son sistemas encargados de detectar intrusos por medio del
análisis de la información que se transmite a través de la red o por medio del análisis de
comportamiento de usuarios de un servidor.
Este sistema se basa en la hipótesis que existe un patrón de comportamiento de un intruso que es
diferente al patrón de comportamiento de un usuario legítimo. Para esto, el sistema lo que hace
primero es definir cuál sería o podría ser el comportamiento normal de un usuario legítimo
(transacciones, horarios, ubicación, dispositivos, etc).
● Diferencia con IPS: la principal diferencia es que el IPS puede tomar acción frente a un
ataque.

IPS (intrusion prevention system): es una nueva tecnología proactiva de seguridad para proteger y
controlar servidores y redes. Su función es bloquear ataques de hackers externos y/o internos de
amenazas conocidas o desconocidas. Tareas que realiza:
● Identificar actividad sospechosa.
● Loggear eventos de seguridad.
● Intentar bloquear intrusiones o limitar su daño.
● Reportar intentos de intrusión.
VPN (virtual private network): es una tecnología de red que brinda la posibilidad de conectarse a una
red pública generando una extensión de una red física local.
La comunicación que se establece entre un punto y el otro va encapsulada utilizando un protocolo de
cifrado, por lo que es una red privada que sirve para mantener comunicaciones confidenciales de
manera que no peligre la seguridad ni la integridad de la información interna (por eso también se lo
conoce como “tunnelling”).
No hay una infraestructura de red física dedicada para cada red privada. En su lugar, existe una única
red física compartida entre varias redes lógicas.

Usos más comunes:


● Acceder a la red interna de una organización desde una locación remota.
● Para acceder a contenido restringido en una región.

SIEM: ¿Cuáles son los pasos a seguir al detectar una intrusión? el SIEM establece los pasos a seguir
para recuperarse de una amenaza. Es decir, permite gestionar un evento que vulnera la disponibilidad
del sistema. Se aplican distintas reglas para conocer qué es lo que están, cómo lo están atacando

Actualizaciones de seguridad: en toda solución informática intervienen elementos de hardware,


software y comunicaciones. Todos ellos son en última instancia, controlados por algún componente
de software. Por ejemplo: firmware, sistemas operativos, bases de datos, aplicaciones.
Cualquiera de estos sistemas son susceptibles de presentar fallos de seguridad, por tanto resulta
clave en cualquier solución controlar el estado de TODOS los sistemas involucrados de manera que
se encuentren actualizados es sus versiones para impedir a cualquier atacante “explotar” posibles
vulnerabilidades conocidas. Buscamos entonces:
● Reducir la exposición a ciberataques.
● Eliminar la pérdida de productividad por salidas de servicio.
● Proteger los datos.
● Proteger a otros sistemas de la posible explotación propia para daño a terceros.

¿Por qué son importantes?: es importante porque la información es el activo más importante de una
empresa. Toda solución deberá contener en al menos alguno de sus elementos las características de:
● Disponibilidad: la disponibilidad, ¿no la resguarda la escalabilidad y la redundancia? Si, pero
solo en los casos de tráfico bien intencionado, cuando hablamos de tráfico NO genuino la
escalabilidad y la redundancia NO alcanza.
● Confidencialidad: la confidencialidad, ¿no deja de ser importante cuando el contenido es
público? Si, pero ese contenido es servido probablemente por algún código dinámico, alguna
base de datos o incluso administrado por otra aplicación que podría estar expuesta y ser
explotada de manera malintencionada.
● Integridad: en general el menor de los problemas de integridad es detectar alguna alteración
accidental o intencional de los datos. La mayor gravedad de los problemas de integridad
sobrevienen cuando a partir de fallas de integridad sobrevienen consecuencias con terceros
la organización, las cuales NO solo pueden sobrellevar problemas de imagen de marca, o
desvalorización de la empresa sino que pueden involucrar cuestiones legales.

Continuidad en las operaciones de negocio

PLAN DE CONTINGENCIA Y RECUPERACIÓN ANTE DESASTRES

Plan de mitigación: o baja la probabilidad de ocurrencia o baja el impacto.

Plan de contingencia: si el riesgo se materializa, se activa el plan de contingencia. Tengo que volver a
la operatoria. Un plan de contingencia incluye las medidas técnicas, humanas y organizativas
necesarias para garantizar la continuidad del negocio y las operaciones de una compañía ante un
desastre, para que pueda seguir operando.
● ¿Por qué puede ocurrir un desastre?: desastres naturales, pérdida del suministro eléctrico,
fallas de hardware/software o errores humanos.

RTO Y RPO

Recovery Time Objective (RTO): tiempo que tarda una infraestructura en volver a estar disponible y
operativa nuevamente luego de que ocurre un desastre. Se quiere que la infraestructura (servidores,
redes, almacenamiento, base de datos, aplicaciones, etc) esté disponible en el menor tiempo posible
pasado el evento de interrupción. Para reducir el RTO 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.
Mientras más backups tenga, más seguido, menor va a ser el tiempo de recuperación (RTO).

Recovery Point Objective (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. ¿Cuántos datos perdí?, ¿a qué punto
puedo volver? ¿cuántos datos está dispuesta a perder la organización?
Lo ideal es disponer de un RPO cuanto más bajo mejor, de manera que si sucede un desastre,
minimicemos el impacto que puede tener en nuestra compañía. Para ello podemos aumentar el
sincronismo de réplica de datos, realizar réplicas de las máquinas virtuales en otro servidor o incluso
disponer de una replicación entre dos centros de datos.
También se puede entender al RPO como la cantidad de datos que está dispuesto a perder antes de
que afecte las operaciones.

Cómo definir los valores de RTO y RPO: una práctica común es dividir aplicaciones y servicios en
diferentes niveles, así como establecer los valores de tiempo de recuperación y objetivo (RTPO) de
acuerdo con los acuerdos de niveles de servicio (SLA), con los que se compromete la organización.
La clasificación de protección de datos es importante para determinar cómo almacenar, acceder,
proteger, recuperar y actualizar datos e información de manera más eficiente en función de sus
criterios específicos.

BIA (análisis de impacto de negocio): es un proceso en el cual las organizaciones analizan sus
aplicaciones para determinar cuáles de ellas están impulsando su negocio, generando ingresos y
siendo imprescindibles para mantenerse operativo. Este proceso es esencial para un buen plan de
continuidad comercial ya que permite establecer protocolos y acciones para enfrentar un desastre.
Por ejemplo, puede usar un modelo de tres niveles para diseñar su plan de continuidad del negocio:
● Nivel 1: aplicaciones esenciales que requieren un RTPO de menos de 15 minutos.
● Nivel 2: aplicaciones esenciales para un negocio que requieren RTO de 2 horas y RPO de 4
horas.
● Nivel 3: aplicaciones no esenciales que requieren RTO de 4 horas y RPO de 24 horas.

ESTRATEGIAS DE PROTECCIÓN DE DATOS

Copias de resguardo en discos locales y externos:


● Ventajas:
○ Rápido acceso.
○ Integración con aplicaciones y bases de datos.
● Desventajas:
○ Costo alto.
○ No es transportable a otro datacenter
○ Si la falla se produce en el datacenter no puedo recuperar el dato.

Copias de resguardo periódicas en cinta, sin y con almacenamiento de manera externa en discos
locales y externos:
● Ventajas:
○ Costo bajo.
○ Transportable a otro datacenter.
● Desventajas:
○ Requieren mayor tiempo de recupero.

Replicación de datos en sitio externo:


● Ventajas:
○ Permite tener un resguardo de los datos fuera del datacenter principal.
● Desventajas:
○ Implica un costo en licencias de replicación (costo opex)
○ No me permite continuar la operación ante una contingencia en el datacenter
principal.

Replicación de datos en centro de datos externo implementado como sitio de contingencia. (Para
garantizar continuidad de negocio offsite):
● Ventajas:
○ Ante una contingencia en el datacenter principal se puede continuar la operación en
el datacenter de contingencia.
○ Permite volver a operar rápidamente (depende del RTO) y de forma más sencilla
(comparado con backup y restore de cintas).
● Desventajas:
○ Representa un costo alto dado que se debe duplicar la infraestructura necesaria para
operar.
○ Implica un costo en licencias de replicación.
Medidas para la recuperación ante desastres:
● Medidas preventivas: acciones para evitar la ocurrencia de eventos no deseados
● Medidas de detección: controles para la detección de eventos no deseados.
● Medidas correctivas: acciones para recuperar la operatoria de los sistemas.

GESTIÓN DE LA CONTINUIDAD DEL NEGOCIO (BCM)

Definición: es un software que conforma una parte integral de un proceso holístico de gestión de
riesgos que salvaguarda los intereses de las partes interesadas clave, la reputación, la marca y las
actividades de creación de valor de una organización a través de:
● Identificar amenazas potenciales que pueden causar impactos adversos en las operaciones
del negocio de una organización y los riesgos asociados.
● Proporcionar un marco para desarrollar resiliencia para las operaciones del negocio.
● Proporcionando capacidades, instalaciones, procesos, listas de tareas de acción, etc., para
respuestas efectivas a desastres y fallas.

Mitigación de impacto mediante BCM efectiva - Disrupción brusca: distintos pasos que seguimos
para ir restaurando el servicio por pasos según lo indicado por el BCM. En función del tiempo vamos
a ir restaurando el servicio: primero restauramos lo más importante y luego el resto, hasta volver a la
operatoria normal.
SLA (SERVICE LEVEL AGREEMENT)

Definición: es un acuerdo documentado entre un proveedor de servicios y el cliente donde se


establecen los requerimientos y el nivel de servicio que el proveedor se compromete a proveer (esto
se define mediante métricas que muestren la calidad del servicio alcanzada).
Es importante remarcar que los SLA definen lo que el cliente recibirá pero no definen cómo el
proveedor va a proporcionar el servicio en sí.

Ejemplo: en el SLA de un proveedor de servicios de Internet (ISP) se podrían definir las siguientes
métricas para definir los niveles de servicio que debe garantizar:
● Una descripción del servicio que se brinda: mantenimiento de áreas tales como conectividad
de red, servidores de nombres de dominio, servidores de protocolo de configuración dinámica
de host.
● Confiabilidad: cuándo el servicio está disponible (tiempo de actividad porcentual).
● Capacidad de respuesta: la puntualidad de los servicios que se realizarán en respuesta a las
solicitudes.
● Procedimiento para reportar problemas: con quién se puede contactar el usuario, cómo se
reportarán los problemas, el procedimiento para la escalada y qué otros pasos se toman para
resolver el problema de manera eficiente.
● Nivel de servicio de supervisión e informe: quién supervisará el rendimiento, qué datos se
recopilarán y con qué frecuencia y cuánto acceso tiene el cliente a las estadísticas de
rendimiento.
● Consecuencias por no cumplir con las obligaciones de servicio: puede incluir crédito o
reembolso a los clientes, o permitir que el cliente termine la relación.
● Cláusulas o restricciones de escape: circunstancias en las que no se aplica el nivel de
servicio prometido. Un ejemplo podría ser una exención de cumplir con los requisitos de
tiempo de actividad en caso de que las inundaciones, incendios u otras situaciones
peligrosas dañen el equipo del ISP.
Si bien las métricas específicas para cada SLA varían según el proveedor del servicio, las áreas
cubiertas son más o menos uniformes:
● Volumen y calidad del trabajo.
● Velocidad.
● Capacidad de respuesta.
● Eficiencia.
Al cubrir estas áreas, el documento pretende establecer un entendimiento mutuo de los servicios, las
áreas priorizadas, las responsabilidades y las garantías proporcionadas por el proveedor del servicio.
El nivel de definiciones de servicio debe ser específico y medible en cada área. Esto permite que la
calidad del servicio sea un punto de referencia y, si así lo estipula el acuerdo, se recompense o se
penalice en consecuencia. Un SLA usará comúnmente definiciones técnicas que cuantifiquen el nivel
de servicio, como el tiempo medio entre fallas (MTBF) o el tiempo medio de recuperación, respuesta
o resolución (MTTR), que especifica un valor "objetivo" (promedio) o "mínimo" para el rendimiento de
nivel de servicio.

PREGUNTAS DE FINAL

1. Cuando se planifica la implementación de un DRS (Disaster Recovery) para nuestro data


center:
a. Hay que usar siempre los servicios cloud disponibles del mercado. Falso porque una
solución (más costosa pero aceptable) podría ser tener la infraestructura on premise
duplicada. Sobre todo para un proveedor de servicios cloud: ¿qué hace aws si ocurre
un desastre? Tienen su infraestructura on premise duplicada en distintas locaciones.
b. Hay que planificar la replicación de los servicios.
c. Hay que planificar el rollback (vuelta al DC original).
d. Todas las anteriores.
e. Ninguna de las anteriores

2. Si tenemos un data center en el cual brindamos servicios cloud para base de datos
relacionales a terceros, nuestro SLA podría:
a. Estar basado en nuestro RPO. Verdadero. ¿A qué punto nos comprometemos a
restaurar el sistema?
b. Estar basado en nuestro RTO. Verdadero. ¿En cuánto tiempo nos comprometemos a
volver a tener operativo el sistema?
c. Ser definido de manera aleatoria, ya que es inherente a lo que queremos dar como
servicio.
d. Todas las anteriores.
e. Ninguna de las anteriores.

3. Seleccione las opciones correctas. Para la elaboración de un DRP debe considerarse:


a. Para la versión inicial, un plan de contingencia elaborado por TI con involucramiento
activo del negocio constituye un contenido suficiente. Para mi es falsa porque no
basta sólo con tener un plan de contingencia, sino que también hay que definir el RPO
y RTO.
b. Las expectativas de la organización respecto de performance se expresan en
términos de RPO y RTO. Verdadero.
c. Los lineamientos de la organización respecto de recuperación de desastres y
continuidad del negocio se establecen en el plan de pruebas del DRP. No sé qué es
eso.
d. Dado que el DRP es una iniciativa precisa para enfrentar un hecho (el desastre), su
enfoque no contempla consideraciones vinculadas con riesgos. Técnicamente es
falsa porque los riesgos se consideran en la gestión de riesgos.
e. Todas las anteriores
f. Ninguna de las anteriores

4. La empresa donde ud. trabaja desarrolló un producto para uso interno que ha resultado muy
exitoso en todas las filiales de la compañía. Debido al resultado feliz del mismo se está
evaluando comercializar el producto en un modelo SaaS a otras compañías. Como parte
esencial del plan le han encargado a ud. como ingeniero en sistemas que determine cuál es
el mejor SLA posible en cuanto a disponibilidad del sistema que se puede ofrecer a los
clientes. En la actualidad el producto se encuentra desplegado en el data center de la
empresa al que se accede vía VPN.
Para comenzar a comercializar el producto se definió que, por cuestiones de escalabilidad,
todos los componentes de procesamiento de datos se migren a servicios de nube pública.
Sin embargo, los componentes de almacenamiento de datos (no volátiles) se mantendrán
(al menos en una primera etapa) en el data center propio de la empresa.
Se espera vender el producto a 5 mil compañías en el primer año por lo que se piensa
contratar un servicio de autenticación y autorización de terceros.
Enumere y describa claramente todas las variables que deberá tener en cuenta para
determinar el mejor índice de disponibilidad que podría ofrecer. Para cada una de las
variables describa el mejor escenario que considere manteniendo la mejor relación costo
beneficio.

5. En recuperación de desastres:
a. ¿Qué información incluye un plan de recuperación de desastres (DRP, disaster
recovery plan)?
b. ¿Cuándo se considera que ha finalizado la recuperación de un desastre?
c. ¿Qué factores influyen en la determinación de RTP y RPO?
a. Un plan de recuperación de desastres incluye los pasos/procedimientos a llevar a cabo en caso de
que ocurra un desastre para poder retomar las actividades. Este plan debe contemplar cómo
recuperar los sistemas de hardware y software críticos para que la aplicación pueda estar operativa
nuevamente así como también cómo recuperar los datos hasta el momento más próximo en que
ocurrió el desastre. Para esto es necesario definir el RTO (recovery time objective) y el RPO (recovery
point objective).
b. Se considera que la recuperación de un desastre ha finalizado cuando cuando el sistema vuelve
nuevamente a estar operativo y se han tomado todas las medidas necesarias para recuperar el
hardware, software y datos afectados. (Esta no sé si está bien)
c. El RTO y el RPO se acuerdan con el cliente en el SLA. Uno de los factores que influyen en la
determinación del RTO y RPO es la criticidad que posea el negocio. (Esta no sé si está bien)

6. Seleccionar las opciones correctas. El RTO de la recuperación de un determinado servicio


es clave porque:
a. Determina la ventana en que un sistema no estará disponible en caso de
contingencia
b. Determina la cantidad de dinero que se dejara de ganar por la caída del sistema
c. Determina la cantidad de datos que podrían llegar a perderse. Falso ya que esto está
en el RPO
d. Condiciona el plan de riesgo de la operación del sistema
e. Todas las anteriores

Seguridad de la información
INTRODUCCIÓN

La información en la organización: “La información es un activo que, como otros, resulta esencial
para el negocio de la organización y consecuentemente debe protegerse adecuadamente.“ “La
información es poder”. La información es considerada como un activo de la organización, y como
todo activo, debe ser protegido.

¿Qué es la seguridad de la información? ¿Cómo aseguramos que la información está protegida?


¿Qué aspectos de la información debemos proteger?: la seguridad de la información hace referencia
a todas aquellas medidas preventivas, reactivas de las organizaciones y de los sistemas tecnológicos
que permitan resguardar y proteger la información buscando mantener la confidencialidad, la
disponibilidad y la integridad de la misma (trilogía de la ciberseguridad). Si logramos proteger cada
uno de estos aspectos de la información, podemos asegurar que la misma está protegida.
● Integridad: se mantiene la integridad si las modificaciones a la información (altas, bajas,
updates) se hacen siguiendo las reglas establecidas.
● Confidencialidad
● Disponibilidad

Sistema de Gestión de Seguridad de la Información (SGSI): la gestión de la Seguridad de la


Información busca establecer y mantener programas, controles y políticas que tengan como finalidad
conservar la confidencialidad, integridad y disponibilidad de la información. Es un proceso continuo.
Es un sistema que, en base a políticas de seguridad, permite controlar si las políticas se están
aplicando correctamente.

¿Qué es la seguridad de la información?


● Evento de seguridad de la información: ocurrencia identificada en un sistema, servicio o
estado de una red que indica una posible violación de la política de seguridad o falla en los
controles, o una situación previamente desconocida que podría ser relevante para la
seguridad. Representa una anomalía, es un comportamiento que llama la atención respecto
al comportamiento usual de algo. Puede significar un grave problema o no. Pueden ocurrir
dos cosas:
○ Que se haya afectado alguno de los 3 pilares (integridad, disponibilidad,
confidencialidad).
○ Que se haya debilitado algo que ayudaba a protegernos. Por ejemplo, perder un
backup
● Incidente de seguridad de la información: evento individual o serie de eventos de seguridad
de la información inesperados o no deseados que tiene una probabilidad significativa de
comprometer las operaciones del negocio y amenazar la seguridad de la información. El
incidente es un evento.

Plan de respuesta a incidentes - Fases:


● Acción inmediata para detener o minimizar el incidente. Lo primero que se hace es frenarlo.
● Investigación del incidente. ¿Por qué y cómo se generó? Investigar el incidente nos ayuda a
detenerlo. Es importante recolectar evidencia del incidente (para fines legales, por ejemplo).
● Restauración de los recursos afectados. No se refiere a un backup, sino a que las cosas
vuelvan a ser como eran antes.
● Reporte del incidente a los canales apropiados. ¿A quién, cuándo y cómo hay que informar?

Plan de respuesta a incidentes: los siguientes son los componentes que participan en la respuesta a
incidentes
● Equipo de expertos.
● Una estrategia legal revisada y aprobada.
● Soporte financiero de la organización.
● Soporte ejecutivo de la gerencia superior de la compañía o áreas afectadas.
● Recursos físicos

Principales ataques a las organizaciones


● Ataques de phishing
● Criptojacking
● Malware
● Ciberextorsiones
● Explotación de vulnerabilidades

Seguridad lógica:
● Restringir el acceso a los programas y archivos.
● Asegurar que los usuarios puedan trabajar sin supervisión minuciosa sin afectar ningún dato,
programa ni archivo que no deban.
● Asegurar que se están utilizando los datos, archivos y programas correctos en cada
situación.
● Que la información transmitida sea recibida sólo por el destinatario deseado.
● Que la información recibida sea la misma que ha sido enviada.
● Que existan sistemas alternativos secundarios de transmisión entre diferentes puntos

Seguridad Física:
● Administración de respaldos de información (Backups).
● Disponibilidad.
● Gestión de centros de cómputos principales y secundarios.

Seguridad de datos: acciones y herramientas:


● Análisis de vulnerabilidades en códigos fuentes y aplicaciones
● Análisis de escalabilidad.
● Adecuado uso de ambientes de desarrollo, testing, preproducción y producción
● Test (unit test, code review, integración, regresión, etc.)
● Control y auditoría de acceso
● Restricción de la visibilidad de datos
De la seguridad de la información somos todos responsables.

NORMAS

ISO/IEC 27000:
● Marco de gestión de la seguridad de la información utilizable por cualquier tipo de
organización
● ISO/IEC 27001: norma principal de la serie, contiene los requisitos del sistema de gestión de
seguridad de la información y es la norma que se certifica por auditores externos.
● ISO/IEC 27002: Es una guía de buenas prácticas que describe los objetivos de control y
controles recomendables en cuanto a seguridad de la información. No es certificable.

Enfoque: esta norma aplica un enfoque de gestión de la seguridad de la información basado en


riesgos. Conceptos básicos:
● Riesgo:
● Amenaza: lo que puede generar un incidente.
● Activo (no definido por la norma):
● Control: medida que modifica el riesgo. Incluye políticas, procesos, dispositivos, prácticas y
otras acciones que modifican el riesgo.
● Vulnerabilidad
● Impacto

PREGUNTAS DE FINAL

1. Continuidad del negocio es la capacidad de una organización para continuar entregando


productos y brindando servicios dentro de marcos temporales aceptables en base a una
capacidad predefinida en relación a una disrupción. Y entendemos por disrupción un
incidente, anticipado o no, que provoca un desvío negativo para entregar productos y brindar
servicios de acuerdo con los objetivos de la organización. Se plantea entonces cómo se
puede utilizar el ciclo Plan-Do-Check-Act. Se pide definir el contenido de cada uno de los
cuatro pasos del ciclo para lograr armar un plan de recuperación de desastres.
En este ejemplo se van a desarrollar las etapas del ciclo PDCA una vez ocurrido el desastre. Se trata
de un ciclo iterativo de 4 etapas:
● Plan: acaba de acontecer un desastre. Este desastre puede ser conocido o no. En caso de ser
conocido, entonces debimos haber definido un plan de contingencia cuando definimos la
gestión de riesgos. Si, en cambio, el desastre que ocurrió no era conocido ni esperado,
entonces es momento de recolectar toda la información posible sobre el desastre: ¿qué
ocurrió?, ¿por qué ocurrió? ¿cuáles son los activos afectados?
● Do: si tenemos un plan de contingencia entonces es momento de llevarlo a cabo. Si no
tenemos un plan de contingencia es momento de implementar una solución al problema.
Esta solución debe ser lo suficientemente completa y robusta como para permitir la
operabilidad del sistema en el menor tiempo posible. Hay que tener mucho cuidado con el
uso de “parches” ya que, si bien pueden permitir volver a la continuidad rápidamente, no
deben ser considerados como soluciones definitivas al problema.
● Check: se evalúan los resultados de la solución aplicada. ¿Nuestra solución cumple con el
RTP y RPO al que nos comprometimos?
● Act: en caso de funcionar debemos estandarizar y dar a conocer la solución para poder
aplicarla nuevamente si el desastre (ahora conocido) volviera a ocurrir.

También podría gustarte