“MÉTRICAS DEL RIESGO EN EL SOFTWARE”

Agenda

  1. Definición de métricas
  2. Tipos
  3. Riesgos
  4. Tablas y matriz de riesgo
  5. Plan MMR
  6. Plan de contingencia

Información histórica

Ponerla de tal manera que no solo me sirva para el presente sino también para el futuro para acumular información.

“LAS MEDIDAS POR SÍ SOLAS NO ME PERMITEN SACAR NINGUNA INFORMACIÓN”.

De nada sirve acumular experiencia si no podemos utilizarla para compararla con los desarrollos presentes.

Se toman medidas

Se desarrollan métricas

(algo que puedo comparar con un estándar).

Ej. –Errores / 1k de riesgo.

-Hs. Trabajadas por día.

Estándar

-Interno

-Externo

Ej. Puedo trabajar con 5 errores por línea de código.

Métrica (definición de wikipedia).

Conjunto de medidas para estimar y realizar comparativas a los efectos de ver cómo estoy en el proyecto.

Pressman define a las métricas como medidas que nos permiten determinar qué tan eficientes somos.

El proceso de generación de software se mide constantemente para obtener medidas cuantitativas que permiten a los ingenieros de software obtener una visión de la eficacia del proceso. Con esas medidas se desarrollan métricas que luego pueden ser comparadas con procesos anteriores. Igualmente, es necesario establecer las métricas incluso en el primer proyecto aunque no haya alguno anterior con el cual comprar. En este último caso sirve para futuras comparaciones.

Características de las MÉTRICAS:

  1. Una clasificación diferencia a las métricas en:
    • Públicas: El equipo necesita saber cómo estamos dentro del presupuesto. Son las que tienen que ver con el avance del proyecto.
    • Privadas: No se comparten.
  2. Las métricas deben usarse con sentido común, interpretando correctamente.
  • No deben usarse solamente para sancionar ni para valorar a los individuos (no solamente con ese fin porque entonces las personas estarían directamente trabajando para ese fin). Ej: desempeño del mc. Donals, o Burguer, donde se busca superar o cumplir con las métricas sin entregar los pedidos en las condiciones que se debería.
  • No debe usarse una única métrica y deben considerarse resultados opuestos.
  • Los resultados negativos deben considerarse como una oportunidad de mejora. Me permiten detectar a tiempo que algo está pasando. Ej.: que a este ritmo no voy a llegar.
  • Las métricas pueden compararse con información histórica.
  • Las métricas forman la experiencia hacia el futuro. Generar métricas que no puedo comparar contra nada no tiene ningún sentido salvo, compararlo a futuro con otras métricas.

    • Otra clasificación distingue 2 tipos de métricas:

    1. Orientadas al tamaño: Son más sencillos de efectuar la comparación (se miden directamente). Se emplean cuando dos proyectos son iguales.
  • Orientados al puesto de función: Cuando los proyectos son diferentes, pueden igualmente tener determinadas funcionalidades iguales, que sí puedo comparar (partes). Siempre se deben comparar proyectos con alguna característica similar.

    • Riesgo:

    El 66% de los proyectos de software de gran escala, fallan al ajustarse a sus objetivos de negocios, se entregan tarde o están sustancialmente fuera del presupuesto.

    Se debe pensar , ¿Qué puede salir mal? Ej. Incendio.

    ¿Qué probabilidad existe? Al haber cables, la probabilidad si bien no es alta, es mayor a la que por ejemplo se daría en el aula de la facultad.

    ¿Qué daño causaría? Destrucción total de los equipos, pérdidas de datos.

    ¿Qué medidas podemos tomar? Instalar material para prevenir y tratar incendios (seguro, piso flotante, matafuegos y mantener backups fuera de las instalaciones de la empresa, en otra ubicación física o in the cloud).

    RIESGO = INCERTIDUMBRE + DAÑO