Unidad 4: Gestión de riesgos de TI (MAGERIT)

Calidad y técnicas de evaluación de los sistemas

GESTIÓN DE RIESGOS EN INGENIERÍA DEL SOFTWARE

Pierre Sergei Zuppa Azúa

¿CÓMO DEFINE ROBERT CHARETTE

EL RIESGO?

EL riesgo es inevitable como la muerte.

1. El riesgo afecta a los futuros

acontecimientos.
2. El riesgo implica cambio, que puede
venir dado por cambios de opinión, de

acciones, de lugares. Diagrama de necesidades de seguridad

3. El riesgo implica elección y la incertidumbre que entraña la elección.

En ingeniería del software se consideran los tres pilares conceptuales de Charette .

1. El futuro es lo que nos preocupa, ¿qué riesgos podrían hacer que nuestro proyecto
fracasara?
2. El cambio es nuestra preocupación ¿cómo afectarán los cambios en los requisitos del
cliente, en las tecnologías de desarrollo, en los ordenadores a las que van dirigidas, el
proyecto y todas las entidades
relacionadas con él, al cumplimiento
de la planificación temporal y al éxito
en general?
3. En las elecciones ¿qué métodos y
herramientas deberíamos emplear,
cuánta gente debería estar
implicada, qué importancia hay que
darle a la calidad?

Componentes de la gestión de riesgos

1
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

ESTRATEGIAS DE RIESGO REACTIVAS Y PROACTIVAS

La estrategia reactiva supervisa el proyecto en previsión de posibles riesgos. Los recursos se

ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente
es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal.

Clasificación de Riesgos

La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se
identifican los riesgos potenciales, se valoran su probabilidad y su impacto y se establece una
prioridad según su importancia. Después el equipo de software establece un plan para controlar
el riesgo. El primer objetivo es evitar el riesgo, poco común no se pueden evitar todos los
riesgos. el equipo trabaja para desarrollar un plan de contingencia que le permita responder de
una manera eficaz y controlada. A lo largo de lo que queda de este capitulo, estudiamos la
estrategia proactiva para el control de riesgos.

RIESGOS DEL SOFTWARE

Características:
• Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir.
• Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no
deseadas o pérdidas.

2
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

Cuando se analizan los riesgos

es importante cuantificar el nivel
de incertidumbre y el grado de
pérdidas asociado con cada
riesgo. Para hacerlo, se
consideran diferentes
categorías de riesgos.

Los principales riesgos del

negocio son:
Perspectiva Marsh de gestión de riesgos

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de

mercado).
2. Construir un producto que no encaja en la estrategia comercial general de la compañía
(riesgo estratégico).
3. Construir un producto que el departamento de ventas no sabe cómo vender.
4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de
personal (riesgo de dirección).
5. Perder presupuesto o personal asignado (riesgos de presupuesto).

IDENTIFICACIÓN DEL RIESGO

Es un intento sistemático para
especificar las amenazas al plan
del proyecto (estimaciones,
planificación temporal, carga de
recursos, etc). Identificando los
riesgos conocidos y predecibles,
el gestor del proyecto da un paso
adelante para evitarlos cuando
sea posible y controlarlos cuando
sea necesario.

3
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo
algunas categorias pueden ser:

• Tamaño del producto.

• Impacto en el negocio.
• Características del cliente.
• Definición del proceso.
• Entorno de desarrollo.
• Tecnología a construir.
• Tamaño y experiencia de la plantilla..
Matriz de Riesgos

COMPONENTES DE RIESGO

 Riesgo de rendimiento.
 Riesgo de coste.
 Riesgo de soporte.
 Riesgo de la planificación temporal.

Modelo del Pulmón

ESTIMACIÓN DEL RIESGO

 Establecer una escala que refleje la probabilidad percibida del riesgo.
 Definir las consecuencias del riesgo.
 Estimar el impacto del riesgo en el proyecto y en el producto.
 Apuntar la exactitud general de la proyección del riesgo de manera que no haya
confusiones.

4
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

Criterios de aceptación de riesgos

Los controladores de riesgo pueden valorarse en una escala de probabilidad cualitativa que
tiene los siguientes valores: imposible, improbable, probable, frecuente y real. Después puede
asociarse una probabilidad matemática con cada valor cualitativo.

FACTORES AFECTAN A LAS CONSECUENCIAS PROBABLES DE UN RIESGO

La naturaleza del riesgo indica los problemas probables que aparecerán si ocurre. Por ejemplo,
una interfaz externa mal definida para el hardware del cliente (un riesgo técnico) impedirá un
diseño y pruebas tempranas y probablemente lleve a problemas de integración más adelante en
el proyecto.
El alcance de un riesgo combina la severidad (¿cómo de serio es el problema?) con su
distribución general (¿qué proporción del proyecto se verá afectado y cuantos clientes se verán
perjudicados?).
La temporización de un riesgo considera cuándo y por cuánto tiempo se dejará sentir el
impacto.

Pasos para la evaluación del riesgo:

1. Definir los niveles de referencia de riesgo para el proyecto.
2. Intentar desarrollar una relación entre cada uno de los niveles de referencia.
3. Predecir el conjunto de puntos de referencia que definan la región de abandono,
limitado por una curva o áreas de incertidumbre.

5
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

4. Intentar predecir como afectarán las combinaciones compuestas de riesgos a un nivel

de referencia.

Una estrategia eficaz debe considerar:

• Evitar el riesgo
• Supervisar el riesgo
•Gestion del riesgo y planes de
contingencia

Mapa de riesgo
Estrategia para reducir la movilidad:
• Reunirse con la plantilla actual y determinar las causas de la movilidad (por ej.: malas
condiciones de trabajo, salarios bajos, mercado laboral competitivo) para reducirlo.
• Una vez que comienza el proyecto, asuma que habrá movilidad y desarrolle técnicas
para asegurarse la continuidad cuando se vaya la gente.
• Organice los equipos del proyecto de manera que la información sobre cada actividad
de desarrollo esté ampliamente
dispersa.
• Defina estándares de
documentación y establezca
mecanismos para asegurarse de
que los documentos se
cumplimenten puntualmente.
• Convoque reuniones de revisión
de todo el trabajo de manera que
más de una persona a la vez esté
familiarizada con el trabajo.
• Defina un miembro de la plantilla
como reserva para cada técnico
crítico.

Matriz de riesgo LA\FT

6
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

En el caso de gran movilidad del personal:

• Actitud general de los miembros del equipo basándose en las presiones del proyecto.
• El grado de compenetración del equipo.
• Relaciones interpersonales entre los miembros del equipo.
• La disponibilidad de empleo dentro y fuera de la compañía.

Cuadro de importancia

El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después de

haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos están
típicamente asociados con las consecuencias del fallo del software una vez en el mercado.

7
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

MAGERIT
MAGERIT es el acrónimo de "Metodología de
Análisis y Gestión de Riesgos de los Sistemas
de Información de las Administraciones
Públicas". Es una metodología de carácter
público, perteneciente al Ministerio de
Administraciones Públicas. Su utilización no
requiere autorización previa del MAP.
Matriz de Riesgos
No es posible una aplicación racional de medidas de seguridad sin antes analizar los riesgos
para, así implantar las medidas proporcionadas a estos riesgos, al estado de la tecnología y a
los costes (tanto de la ausencia de seguridad como de las salvaguardas).

MAGERIT persigue los siguientes objetivos:

Directos Indirectos

Concienciar a los responsables de las Preparar a la Organización para procesos de

organizaciones de información de la
existencia de riesgos y de la necesidad de
gestionarlos.
Ofrecer un método sistemático para analizar
los riesgos derivados del uso de tecnologías
de la información y comunicaciones (TIC).
Ayudar a descubrir y planificar el tratamiento
oportuno para mantener los riesgos bajo
control.
evaluación, auditoría, certificación o
acreditación, según corresponda en cada
caso.
Busca la uniformidad de los informes que
recogen los hallazgos y las conclusiones de
las actividades de análisis y gestión de
riesgos.

MAGERIT interesa a todos aquellos que trabajan con información digital y sistemas informáticos
para tratarla. Si dicha información, o los servicios que se prestan gracias a ella, son valiosos,
MAGERIT les permitirá saber cuánto valor está en juego y les ayudará a protegerlo. Conocer el
riesgo al que están sometidos los elementos de trabajo es, simplemente, imprescindible para
poder gestionarlos. Con MAGERIT se persigue una aproximación metódica que no deje lugar a
la improvisación, ni dependa de la arbitrariedad del analista.

8
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

MINTZBERG 5Ps DE LA ESTRATEGIA

Henry Mintzberg argumentó que es muy difícil conseguir la estrategia correcta. Para
ayudarnos a pensar en ello con mayor profundidad, desarrolló su Estrategia de las 5Ps.

Estrategia de desarrollo de las 5 Ps

PLAN: De manera general, la estrategia es un plan una especie de curso de acción

conscientemente determinado, una guía (o una serie de guías) para abordar una
situación específica. Las estrategias tienen se elaboran antes de las acciones en las
que se aplicarán y se desarrollan de manera consciente y con un propósito
determinado.

PLANO O PAUTA DE ACCIÓN: Una estrategia también puede ser una, “maniobra”
para ganar la partida al contrincante o competidor.

9
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

PATRÓN: Las estrategias pueden ser intencionales (ya sea como planes generales o
maniobras específicas), por supuesto también pueden elaborarse.

POSICIÓN: Establece que la estrategia es una posición, en particular, un medio para

ubicar una organización en lo que los teóricos de la organización suelen llamar un
“medio ambiente”.

PERSPECTIVA: La estrategia mira hacia afuera, buscando ubicar a la organización en

un entorno externo y en posiciones concretas, la quinta mira hacia el interior de la
organización, mejor dicho, hacia el interior de las cabezas del estratega colectivo, pero
con una visión más amplia. Aquí, la estrategia es una perspectiva, su contenido implica
no sólo la selección de una posición, sino una manera de percibir el mundo. En este
sentido, la estrategia es para la organización lo que la personalidad es para el individuo.

TIPOS DE ANÁLISIS
Cuantitativo: Intenta establecer valores numéricos para los costos de daños y controles de
seguridad. Es un proceso que evalúa la prioridad de los riesgos identificados usando la
probabilidad. Impacto sobre los objetivos como: costos, cronograma, alcance y calidad.
Cualitativo: Establece un rango de valores cualitativos para determinar los costes de daños y
controles de seguridad. Permite establecer prioridades para la planificación de la respuesta a
los riesgos.

MÉTODOS CUALITATIVOS:
o Listas de chequeos.
o Análisis preliminar de riesgos
PHA.
o What if?.
o Análisis de modo de falla y
efecto FMEA.
o HAZID.
o HPA.
o HAZOP.
Gestió del riesgo de suspender

1
0
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

MÉTRICA DEL SOFTWARE

Pretenden mejorar los procesos de desarrollo de

Software y facilitar, por tanto, todos los aspectos de
la gestión de aquellos procesos. Estas medidas son
aplicables a todo el ciclo de vida del desarrollo, desde
la iniciación, cuando debemos estimar los costos, al
seguimiento y control de la fiabilidad de los productos
finales, y a la forma en que los productos cambian a
través del tiempo debido a la aplicación de mejoras.
Las medidas del Software y los modelos de medida
son entonces útiles para estimar y predecir costos y
para medir la productividad y la calidad del producto.
Un ingeniero del Software recopila medidas y
desarrolla métricas para obtener indicadores.

La función de las Métricas de Software es

proporcionar una verificación cuantitativa del Factor de calidad FURPS+
diseño de software.
Una métrica ideal debería ser:
 Objetiva
 Sencilla, definible con precisión para que puede ser evaluada
 Fácilmente obtenible ( a costo razonable)
 Valida, la métrica debería medir exactamente lo que se quiere medir y no otra cosa.
 Robusta. Debería de ser relativamente insensible a cambios poco insignificativos en el
proceso o en el producto.

Además, para una mejor utilización de estas medidas, a la hora de realizar estudios analíticos o
análisis estadísticos, deberían de tener unos valores que se ajusten a una cierta escala de
medida.

1
1
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

CLASIFICACIÓN DE LAS MÉTRICAS DE SOFTWARE

Métricas de Producto: son

Factores de Calidad de McCall
medidas de producto Software
durante cualquier fase de su
desarrollo desde los requisitos
hasta la instalación. Esta puede
medir la complejidad del diseño,
el tamaño del producto final
(fuente u objeto) o el número de
páginas de documentación
producida.

Métricas de Proceso: son medidas del proceso de desarrollo del Software tales como tiempo
de desarrollo total, esfuerzo en días/ hombre o mes / hombre de desarrollo del producto, tipo de
metodología utilizada o nivel medio de experiencia de los programadores. Muchos de los
trabajos iniciales realizados sobre las métricas de producto están relacionados con
las características del código fuente.

Métricas del tamaño: provienen de la normalización de las medidas de `calidad y/o

productividad considerando -el tamaño - del Software que se haya producido.

Métricas de Calidad: el objeto primordial de la ingeniería del Software es producir un sistema,

aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros del software
deben aplicar métodos efectivos con herramientas modernas dentro del contexto de un proceso
maduro de desarrollo del Software. Se puede generar una larga lista de características de la
calidad de Software: corrección, eficacia, portabilidad, mantenibilidad, fiabilidad, etc.
Desafortunadamente, las características a veces se solapan y entran en conflicto unas con
otras. Por ejemplo, incrementar la portabilidad, que es muy deseable, puede dar lugar a una
eficacia menor.

1
2
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

Métrica para el esquema de puntuación

Las métricas pueden ir en forma de lista de comprobación para evaluar y puntuar
atributos específicos del software.
McCall, propuso un esquema de puntuación en una escala del 0 (bajo) al 10 (alto). Se
emplean las siguientes métricas en el esquema de puntuación:
Facilidad de La facilidad con la que se puede comprobar el cumplimiento de
auditoría los estándares.
Exactitud La exactitud de los cálculos y del control.
Estandarización de El grado de empleo de estándares de interfaces, protocolos y anchos
comunicaciones de banda.
Complexión El grado con que se ha logrado la implementación total de una
función.
Concisión Lo compacto que es el programa en términos de líneas de código.
Consistencia El empleo de un diseño uniforme y de técnicas de documentación a lo
largo del proyecto de desarrollo del software
Estandarización de El empleo de estructuras y tipos de datos estándares a lo largo del
datos programa.
Tolerancia al error El daño causado cuando un programa encuentra un error.
Eficiencia de El rendimiento del funcionamiento de un programa.
ejecución
Capacidad de El grado con que se pueden ampliar el diseño arquitectónico, de datos
expansión o procedimental.
Generalidad La amplitud de aplicación potencial de los componentes del programa.
Independencia del El grado con que se desacopla el software del hardware donde opera.
hardware
Instrumentación El grado con que el programa vigila su propio funcionamiento e
identifica los errores que ocurren.
Modularidad La independencia funcional de componentes de programa.
Operatividad La facilidad de operación de un programa
Seguridad La disponibilidad de mecanismos que controlan o protegen los
programas y los datos.
Autodocumentación El grado en que el código fuente proporcionan documentación
significativa
Simplicidad El grado de facilidad con que se puede entender un programa.
Independencia del El grado de independencia de programa respecto a las características
sistema software del lenguaje de programación no estándar, características del sistema
operativo y otras restricciones del entorno.
Trazabilidad La capacidad de seguir una representación del diseño o un
componente real del programa hasta los requisitos.
Formación El grado en que ayuda el software a manejar el sistema o los nuevos
usuarios.

1
3
 Unidad 4: Gestión de riesgos de TI (MAGERIT)
Calidad y técnicas de evaluación de los sistemas

CONSEJOS PRÁCTICOS
IDENTIFICAR LOS ACTIVOS
¿Qué activos son fundamentales para que
usted consiga sus objetivos?
¿Hay más activos que tenga que proteger por
obligación legal?
¿Hay activos relacionados con los anteriores?
Ejemplos de activos de naturaleza intangibles

credibilidad y buena imagen, conocimiento Determinantes de la calidad del software y de la

acumulado, independencia de criterio o efectividad de la organización

actuación, intimidad de las personas e integridad física de las personas.

PARA DESCUBRIR Y MODELAR LAS DEPENDENCIAS ENTRE ACTIVOS.

¿Dónde puede verse comprometida la seguridad de los activos? Si unos datos son importantes
por su confidencialidad se necesita saber en qué sitio van a residir dichos datos y por qué
lugares van a circular: En esos puntos pueden ser revelados.

Si unos datos son importantes, por su integridad se necesita saber en qué sitio van a residir
dichos datos y por qué lugares van a circular, ya que en cualquiera de esos puntos pueden ser
alterados.

PARA VALORAR AMENAZAS

 Lo más complicado es calificar los errores humanos.
 Motivos que agudizan el peligro de una amenaza:
 Que no requiera grandes conocimientos por parte del atacante.
 Que no requiera gran inversión en equipo por parte del atacante.
 Que haya un enorme beneficio económico en juego.

1
4