PROYECTO INFORMATICO II Ciclo Lectivo 2022

RESUMEN DE TEMAS INCLUIDOS EN EL EXAMEN Nº 3

Análisis de Impacto

Impacto: Son los resultados directos o indirectos de la implementación (o no) de un proyecto

informático o de la posible ocurrencia de los riesgos que se hayan detectado en el proyecto.

Lo ideal sería contar con un “grupo de comparación” que nos permita determinar:

a) Cuál sería la situación al implementarse el proyecto informático respecto de la situación

con el proyecto no implementado y viceversa (que sucedería si no se implementa el

proyecto en comparación a la situación con el proyecto implementado).

b) Cuál sería la situación de haberse producido el problema anticipado como “riesgo” del

proyecto informático.

Los impactos pueden ser directos o indirectos. Los impactos directos son aquellos que se

producen por efecto de la implementación de un proyecto informático o la ocurrencia de un

hecho detectado como riesgo (Por ejemplo: Cambios en los procedimientos de la empresa).

Los impactos indirectos son aquellos se producen como consecuencia de un impacto anterior

(Por ejemplo: Redistribución del personal en áreas diferentes a las que ocupaban

originalmente)

Los impactos pueden ser tangibles (concretos) o intangibles (abstractos), es decir pueden

cuantificarse (expresarse en cantidades) o no (valorarse en términos de buenos o malos,

positivos o negativos o de mejores o peores). Una cuestión interesante de los impactos

tangibles es que de una u otra manera pueden terminar expresándose en términos de dinero.

Por ejemplo: aumentar un determinado porcentaje las ventas, equivale al ingreso de una

Página 1 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

determinada suma de dinero… Despedir o contratar una determinada cantidad de empleados

equivale a tener que pagar una determinada suma de dinero en indemnizaciones o aumentar la

suma a abonar en sueldos en una determinada cantidad.

Los impactos producidos por la implementación (o no) de un proyecto informático pueden

abarcar, para todas las combinaciones de impacto, diversos aspectos tales como:

- Económico (Relación costo/beneficio, aumento o disminución de utilidades, pérdidas,

mejor posicionamiento de una empresa en el mercado o de su imagen, etc.)

- Humano (Pérdida de puestos de trabajo, cambios en el “clima laboral”, cambios en la

productividad)

- Ambiental (Mejoras en la protección o daños al medio ambiente)

- Social (Ayuda o perjuicio a un grupo social, cambios en el “humor” social)

Los impactos dependerán exclusivamente de cada proyecto en cuestión, su objeto y alcance y

su análisis debe ser parte fundamental en la etapa de planificación y desarrollo.

Los costos o beneficios tangibles y de impacto directo son fáciles de valorar y por lo tanto

pueden ser explícitamente cuantificados o expresados en términos monetarios.

Página 2 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Los intangibles de impacto directo son generalmente difíciles de cuantificar por lo que

habitualmente son expresados en términos cualitativos. Por ejemplo: la satisfacción de los

usuarios debido a la implementación de un proyecto informático puede ser un resultado

(impacto) directo pero muy difícil de cuantificar por lo que se les asigna una interpretación

subjetiva (opinión).

Los costos o beneficios tangibles o intangibles de impacto indirecto son los más difíciles de

valorar en términos cuantitativos (cantidades) por lo que suelen usarse parámetros o

interpretaciones subjetivas (supuestos u opiniones basados en algún caso similar o

antecedentes)

Una cuestión a tener en muy cuenta sobre los impactos es que muchas veces son ellos los que

generan a su vez otros impactos. Por lo general los indirectos pueden ser consecuencia de los

directos y muchas veces los indirectos generan a su vez nuevos impactos indirectos, sean

estos tangibles o intangibles. Con los impactos se produce una especie de reacción en cadena

que en muchos casos son absolutamente impredecibles y si bien es importante un análisis de

los posibles escenarios el resultado real será determinado por lo que suceda efectivamente a

lo largo del tiempo (algo similar a lo visto con las proyecciones y la realidad cuando se

analizó la Factibilidad Económica)

Un error muy frecuente consiste en confundir los impactos de la implementación (o no) de un

proyecto informático con los objetivos que se buscan con la implementación (o no) del

mismo.

Los objetivos pueden identificarse con lo que el cliente o el equipo de desarrollo (cuando no

existe un cliente determinado que solicite el desarrollo) esperan lograr con el mismo y los

impactos son los resultados que efectivamente se producen. En algunos casos pueden

Página 3 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

coincidir los unos con los otros, en otros puede que el impacto no coincida con el objetivo

(para mejor o para peor) y en otros casos pueden producirse impactos no previstos, esperados

o anticipados, sean estos positivos o negativos.

Veamos algunos ejemplos:

a) Un cliente encarga el desarrollo de un producto software para reducir su planta de personal

y prescindir de los servicios de empleados encargados en determinadas tareas de control de

información o elaboración de informes. Este es el objetivo del proyecto software. Un impacto

directo de la implementación puede ser que a partir del despido de una determinada cantidad

de empleados, la empresa deba afrontar el pago de indemnizaciones (directo tangible), pero

puede traer aparejados otros impactos (previstos o no, pero definitivamente no considerados

como un objetivo del proyecto) tales como el malestar de los empleados despedidos (directo

intangible), una posterior caída en la imagen que el público tiene de la empresa (indirecto

intangible) y una caída en las ventas originada en el deterioro de la imagen de la empresa

(indirecto tangible)

b) Un equipo de desarrolladores idean una aplicación de geolocalización para celulares con el

objetivo de compartir un porcentaje del mercado actualmente ocupado por Google Maps,

Waze y Moovit (por citar algunas apps similares). Como impacto directo tangible, la

aplicación registra una determinada cantidad de descargas en el día de su lanzamiento (que

puede o no coincidir con las expectativas u objetivo inmediato) pero como resultado de las

fallas que los usuarios reportan se genera una opinión desfavorable sobre el producto (directo

o indirecto intangible) que hace que la app no sea tenida en cuenta en el futuro como una

herramienta a utilizar, por lo que el objetivo inicial del equipo no llegara alcanzarse nunca.
puede

Página 4 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Para ver las cosas de manera más positiva, podemos pensar en Bill Gates y Paul Allen

(Fundadores de Microsoft) quienes al momento de decidirse a desarrollar un nuevo lenguaje

de programación para ordenadores no creo que hayan tenido como objetivo llegar a poner a la

empresa que fundaron en el lugar que hoy ocupa en el mundo de la tecnología debido a los

impactos producidos por su trabajo, ¿verdad?

Análisis de Riesgo

Riesgo es un problema potencial que puede o no ocurrir y afecta futuros acontecimientos

teniendo diversas características o ámbitos (Tecnológico, legal, económico, etc.).

Básicamente afecta el éxito del proyecto en general o tiene efectos negativos sobre el o los

destinatarios del proyecto.

Los riesgos en un proyecto informático implican cambios (¿Cómo afectarían los futuros

requerimientos del cliente o los cambios tecnológicos al cumplimiento de la planificación y al

éxito del proyecto en general?) y requieren la toma de decisiones (¿Qué métodos o

herramientas utilizar? ¿Cuánta gente debería estar involucrada en el proyecto?)

El Análisis de Riesgo consiste en una serie de pasos y análisis que ayudan a comprender y a

gestionar efectivamente la incertidumbre y es responsabilidad de todo el equipo participar en

el desarrollo de este análisis y está íntimamente asociado al Análisis de Impacto.

El tratamiento de los riesgo depende de o implica adquirir información, debe estar

debidamente documentado y siempre es (o debe ser) proactivo, es decir, tienen que definirse

Página 5 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

o tomarse las medidas preventivas antes que el riesgo potencial se convierta en hecho real

para que si esto sucede el daño o perjuicio sea mínimo o no llegue a producirse ninguno.

Y así llegamos a la tercera palabra mágica que rigen a todos los proyectos informáticos:

Proactividad.

El análisis de riesgo de un proyecto informático puede evaluarse desde tres aspectos

fundamentales:

Clasificacion de los Riesgos

 Riesgos del Proyecto

Amenazan el plan del proyecto, la planificación temporal y los costos.

Ejemplo: La pérdida de un integrante del equipo de programadores

 Riesgos del Producto

Amenazan la calidad y/o la confiabilidad del producto y la posibilidad de

implementación.

Ejemplo: Fallas de seguridad.

 Riesgos del Negocio

Amenazan la viabilidad del proyecto o la usabilidad del software.

Ejemplo: Aparición de competidores.

La diferencia entre posibilidad de implementación y viabilidad del proyecto radica en que lo

primero implicaría no tener el software para implementar o lanzar al mercado (por ejemplo se

pierden los programas fuente del Proyecto) y lo segundo implicaría tener el proyecto

terminado y que:

a) El cliente ya no lo quiera.

b) Nadie lo use o no pueda usarlo en caso de haberlo instalado o haberse implementado.

Página 6 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Hay riesgos exclusivos para cada una de las categorías pero por lo general están relacionados

entre sí, por ejemplo si un programador muy calificado abandona el proyecto esto tendrá

repercusiones en el proyecto en sí porque implicaría un retraso en los tiempos de desarrollo,

en el producto porque podría afectar la calidad final del software y en el negocio porque esta

situación podría poner en riesgo negocios futuros.

Carácterísticas de los Riesgos

Los riesgos pueden ser “cuantificados” asignándole valores a la posibilidad de ocurrencia

con valores porcentuales obtenidos de manera estadística o por información recabada. De

todas maneras y a los efectos prácticos se pueden agrupar los porcentajes por rangos de

valores (Por ejemplo: muy baja <10% – baja 10-25% – moderada 25-50% – alta 50-75% –

muy alta >75%) y considerar de la misma manera todos aquellos porcentajes dentro del

mismo rango o grupo. Esta condición recibe el nombre Probabilidad.

Los riesgos tienen también un grado de daño o perjuicio que la ocurrencia del mismo puede

producir, no siendo cuantificables por lo que deben identificarse con calificativos (Por

ejemplo: insignificante – tolerable – serio – catastrófico). Esta condición recibe el nombre

Sensibilidad.

Generalmente estas ponderaciones se hacen en base a opiniones de expertos o bien basados

en casos precedentes.

Cabe señalar que los rangos de Probabilidades y de Sensibilidades pueden ser expresados en

otros términos (Por ejemplo: Letras, números, colores, etc) quedando a criterio del equipo de

desarrollo emplear la convención que más adecuada le resulte pero, en definitiva, esos

valores tendrán un correlato con las palabras que describan cada situación.

Página 7 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Estructura de los Riesgos

Cuando se trata de gestionar riesgos podemos identificar lo que podríamos denominar como

Riesgo “Base” o Riesgo “Principal” y a continuación asociarlo a un motivo por el cual

puede llegar a ocurrir.

Por ejemplo: “Perder la información del proyecto o no tener acceso a la misma” puede ser

considerado el Riesgo Base y esto puede suceder porque se quema el disco rígido, porque se

quema la computadora por una falla en el suministro eléctrico, porque alguien borra la

carpeta donde se encuentra la información, porque alguien formatea el disco rígido, porque

un virus la infecta y la deja inutilizable, porque alguien hackea la computadora y encripta la

información dejándola inaccesible, etc.

Por un lado el Riesgo Base puede ser gestionado por una o más medidas pero por otro lado

cada una de las combinaciones de Riesgo Base + Motivo u Origen debe ser gestionada a su

vez por una o más medidas, pudiendo suceder que alguna de las medidas elegidas sirva para

gestionar más de un riesgo.

Aquí aparece un concepto que se vuelve fundamental a la hora de la gestión de riesgos: la

Redundancia. Esto significa que cuantas más medidas apliquemos para la gestión de riesgos

mejor será la protección brindada al proyecto informático, tanto en lo que respecta al

software en sí mismo como la información que el software utiliza o genera.

¿Cuál es el límite para la aplicación de medidas redundantes?... En primera instancia, el

mismo que existe para el desarrollo de las aplicaciones necesarias: acceso a la tecnología y/o

disponer de los conocimientos necesarios para su aplicación. Pero también existe otro límite:

una relación lógica entre el costo del desarrollo y la implementación del proyecto informático

(costo del proyecto) y el costo de las medidas a aplicar para la gestión de riesgos.

Página 8 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Otro tema a tener en cuenta respecto de las propiedades de los riesgos (Probabilidad y

Sensibilidad) es que la Sensibilidad de un riesgo está, fundamentalmente, vinculada con el

Riesgo Base, ya que el nivel de daño está determinado por éste y ningún factor externo

puede modificarlo y la Probabilidad está fundamentalmente asociada al Motivo u Origen

por el que se produce el riesgo y esto puede verse afectado por factores absolutamente

externos, tales como la ubicación geográfica del usuario o de la empresa del cliente que nos

encargó el proyecto (Por ejemplo: El riesgo de terremoto no es el mismo en las provincias de

San Juan o Mendoza que en las provincias de Entre Ríos o Buenos Aires).

Proceso lógico de Gestión de Riesgos

La Gestión de Riesgos no es una tarea que se desarrolle en etapas como cuando para llegar al

nivel 2 de un juego debemos completar previamente el nivel 1, pero si conlleva un orden

lógico en las tareas a desarrollar ya que no se puede hacer una cosa sin haber hecho antes lo

que se indica en la etapa anterior.

IDENTIFICACION Listado de riesgos potenciales indicando el Riesgo Base y sus

diferentes orígenes o motivos

ANALISIS Determinar la Probabilidad y sensibilidad de cada uno de los

riesgos

Ordenar de mayor a menor por Sensibilidad y

Probabilidad

PLANIFICACION Elección de las medidas a aplicar para gestionar cada uno de los

riesgos.

SUPERVISION Simulación de la ocurrencia del riesgo y evaluación de la

efectividad de las medidas elegidas. Seguimiento en el tiempo.

Página 9 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Cabe señalar que al efectuar la supervisión de los riesgos podemos llegar a distintas

conclusiones:

a) Se le asignó al riesgo evaluado una Sensibilidad y/o Probabilidad errónea en el proceso de

Análisis.

b) La medida elegida en el proceso de Planificación no es la adecuada.

En cualquiera de los casos deberá reverse la situación y devolver el riesgo a la etapa donde se

cometió el error para una re evaluación y priorización.

Todo el proceso de identificación y análisis de los riesgos conlleva el trabajo de obtener

información. Cuanta mayor sea la lista de riesgos mayor será la cantidad de información que

sea necesario conseguir para su correcta descripción y valoración. Dentro del proceso de

análisis también deberían poder detectarse los posibles orígenes de los riesgos, lo cual

generaría un nuevo tipo de riesgo para cada origen y así poder elaborar correctamente la

planificación.

Una vez que se identifican los riesgos, se los analiza (califica) según la Probabilidad

(posibilidad de ocurrencia) y la Sensibilidad (grado de daño o perjuicio que pueden producir)

y de esa manera se puede elaborar una tabla de tres columnas:

Descripción del Riesgo Probabilidad de Ocurrencia Nivel de Daño/Perjuicio

Problemas financieros del Baja Catastrófico

cliente fuerzan a reducir el

presupuesto del proyecto

Página 10 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Imposibilidad de reclutar Alta Catastrófico

personal con los

conocimientos necesarios

El personal clave está Moderada Serio

enfermo o no disponible en

los momentos críticos

El tiempo requerido para Alta Serio

desarrollar el software fue

subestimado

Se proponen cambios en los Moderada Serio

requerimientos que requieren

un rediseño del proyecto

El tamaño del software fue Alta Tolerable

subestimado

Los componentes de Moderada Serio

hardware a utilizarse tienen

defectos que limitan su

rendimiento

y luego ordenarlos de mayor a menor según su Sensibilidad (según la categoría elaborada) y

de mayor a menor según su Probabilidad (según la categoría elaborada), ya que a igual nivel

de daño se deberían atender primero los riesgos con mayor posibilidad de ocurrencia y de

esta manera poder planificar la manera de atender a los mismos.

Tanto la lista de riesgos, aunque se pueden identificar muchos que resultan comunes a

cualquier tipo de proyecto, como la probabilidad y la sensibilidad de los mismos pueden

Página 11 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

depender de las características propias de cada uno así también como del lugar físico donde

se va a implementar. Por ejemplo un riesgo común a cualquier proyecto que corra en PCs de

escritorio (o notebooks) es que se queme por un pico de tensión teniendo una sensibilidad

alta, pero la probabilidad puede variar dependiendo de si se implementa en una localidad

donde se tiene una fuente confiable de suministro eléctrico o en una donde es común que el

suministro eléctrico sufra cortes inesperados o que la calidad de la electricidad no sea buena

(alteraciones bruscas de tensión o voltaje)

El proceso de Planificación de Riesgos determina las estrategias a seguir para cada caso y

estas estrategias pueden dividirse en tres categorías:

 Estrategias de Prevención: Son las que apuntan a reducir lo más que se pueda la

probabilidad de ocurrencia de un riesgo.

Por ejemplo: Comprar componentes de calidad reduce el riesgo de la línea 7 del

cuadro anterior.

 Estrategias de Minimización: Son las que tienden a modificar o revertir el nivel de

daño del riesgo una vez producido.

Por ejemplo: Solapar las tareas y hacer que todo el equipo comprenda las tareas a

realizar minimiza el riesgo de la línea 3 del cuadro anterior.

 Planes de Contingencia: Son los que determinan las acciones alternativas a las

previstas en el Plan de Acción Original, a realizar en caso de ocurrir el riesgo.

Por ejemplo: Tener elaborado un informe sobre los beneficios de la implementación

del software por parte de la empresa y alternativas de refinanciación del pago nos

permite estar preparados para actuar si se produce el riesgo de la línea 1 del cuadro

anterior.

Página 12 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

Para entender mejor en que consiste un Plan de Contingencia tenemos que tener en mente la

línea de vida de un Proyecto Informático:

Relevamiento Planificación Desarrollo Mantenimiento

Elaboración del Plan Implementación

de Trabajo Publicación/Lanzamiento
Presupuesto/Contrato

Cuando finaliza la etapa de Planificación, se decide la manera en que se va a proceder en la

etapa de Desarrollo (Por ejemplo: Tiempos estimados, sprints, orden de los procesos, costos,

etc.) y en caso de existir un cliente que haya encargado el desarrollo, también se agregaría la

forma en que el cliente va a pagarle al equipo de desarrollo lo que constituiría, muy

probablemente, la elaboración de un Presupuesto que, de ser aprobado por el cliente, se

convertirá en el Contrato de Servicio. Si por cualquier razón fuera imposible seguir al pie de

la letra ese plan original en cualquiera de sus aspectos, se considerará como Plan de

Contingencia el nuevo plan a seguir teniendo como objeto llevar a buen puerto el Proyecto

Informático (La finalización, implementación o lanzamiento)

La Planificación de Riesgos debe estar debidamente documentada de manera que se

conozcan los pasos a seguir para cada uno de ellos.

A la hora de elegir las medidas a tomar ante cada riesgo se tiene que considerar también el

costo de implementarlas en relación a las características de cada riesgo y a la efectividad de

las mismas en cuanto a reducir la probabilidad o revertir el daño en niveles aceptables (lo que

Página 13 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

constituye un riesgo serio termina teniendo un efecto tolerable), lo cual puede afectar la

valoración generada en el análisis preliminar.

Cabe señalar también que no es obligatorio implementar una única medida para la gestión de

un riesgo ya que muchas veces la redundancia de medidas garantiza una mejor gestión de los

riesgos.

La Supervisión de Riesgos consta de dos aspectos. Uno es el de simular la ocurrencia del

riesgo y determinar si las medidas elegidas en el proceso de planificación son adecuadas para

tratar de disminuir la probabilidad y/o revertir o minimizar el daño efectivamente producido

(ya que la sensibilidad es intrínseca al tipo de riesgo y no podemos modificarla).

El otro es el “seguimiento” que se hace sobre los riesgos identificados de manera de llevar un

control sobre los riesgos que fueron eliminados, los cambios que pudieran producirse sobre la

probabilidad de ocurrencia o la sensibilidad y/o la posible aparición de nuevos riesgos.

La aparición de nuevas tecnologías y/o de nueva información que tenga alguna relación con

los riesgos detectados o las medidas implementadas para su gestión puede determinar la

incorporación de nuevos procedimientos o la modificación o el reemplazo de los

procedimientos implementados y esto también constituye parte del seguimiento necesario

para una correcta supervisión de riesgos.

Por último, si pese a todo resulta que se produce aquello que se identificó como riesgo se

deberán rever las medidas que trataron de evitar su ocurrencia y se analizará si el resultado de

la implementación de las medidas tendientes a reducir o revertir el daño producido fue el

esperado.

Todo este análisis puede determinar la necesidad de implementar funcionalidades en el

software que no fueron explícitamente solicitadas por el cliente o que no constan en el listado

Página 14 de 15
PROYECTO INFORMATICO II Ciclo Lectivo 2022

de requerimientos original de manera que el software esté preparado para responder

correctamente ante la aparición de un riesgo sea impidiéndolo o limitando los efectos no

deseados.

Como vemos, esta tarea (supervisión) no se agota con la implementación del proyecto sino

que debe continuar a lo largo de toda su vida útil.

Notas generales:

Es prácticamente imposible lograr una probabilidad nula (0%) de ocurrencia de un riesgo ya

que muchas veces eso está fuera del alcance tanto del equipo de desarrollo como de los

usuarios, pero esto no inhabilita la determinación de acciones que busquen reducir en algo la

probabilidad de ocurrencia.

Como se dijo antes, la sensibilidad de un riesgo no varía por la posibilidad de revertirlo con

las acciones resultantes de la planificación de los riesgos. Si un riesgo es muy dañino, esta

característica no cambia aunque con las medidas tomadas el daño sea revertido.

Por otra parte no hay que confundir una medida de gestión de riesgos con las acciones a

realizar una vez ocurrido el mismo como consecuencia lógica.

Por ejemplo: Si un riesgo detectado y a gestionar es que se queme el servidor, obviamente en

caso de producirse el riesgo deberemos reponer el servidor por uno nuevo o mandarlo a

arreglar, pero esta es la acción lógica a realizar (la afectación de futuros acontecimientos), la

medida de gestión de ese riesgo sería tener una computadora de respaldo para reemplazar el

servidor quemado y de esa manera disminuir al mínimo el tiempo en que el proyecto estaría

no operativo.

Página 15 de 15