Clase 7 SW - Mediciones Metricas

CALIDAD DE LOS SISTEMAS DE
INFORMACIÓN
CÓDIGO DE LA ASIGNATURA: 41410
CARRERA: LICENCIATURA EN SISTEMAS DE INFORMACIÓN
Lic. Carlos Paz Soldán (cpazsoldan@unlu.edu.ar)

Ing. Fabián Marchesotti (fabianmarchesotti@gmail.com)
Calidad en Sistemas de Información (SI)
SITUACIÓN ACTUAL DE LA CALIDAD EN SISTEMAS DE

INFORMACIÓN (SI)
“ Our civilization runs on software
”
(Barjne Sroustrup, científico que desarrolló C++)
✓ El software forma parte de nuestras vidas (medios de transporte,

telecomunicaciones, equipos médicos, industria, ocio, ....)
✓ La calidad de los SI es un objetivo estratégico de las
organizaciones ➔ sus procesos más importantes dependen de
dichos sistemas
2
Situación actual de la Calidad en SI
La mala calidad de
los SI ha costado
millones de dólares a
La demanda de software los gobiernos y
por parte de la sociedad empresas, y es
ha crecido más deprisa responsable de varios
que la capacidad de la desastres que han
industria para producir
La satisfacción de los cobrado vidas humanas
software de calidad
usuarios con los SI es
muy desigual, en
comparación con otros
tipos de sistemas
desarrollados por
ingenierías más
tradicionales
3
Algunos estudios relacionados con la Calidad
GARTNER NIST IBM
Sólo en EEUU se Las pérdidas económicas

debido a los fallos de El 40% de las
desperidicia el 20%
software en diferentes inversiones de TI
del gasto en TI sectores (ej.:
no retornan su valor a
(u$s 600.000 Aeroespacial, Defensa) las organizaciones
millones) suman varios centenares
de millones de dólares
4
Otros datos
Algunos ejemplos de “desastres” debido a fallas en SI:

• ENERGÍA ➔ Apagones y problemas en red eléctrica (EEUU 2003/4)
• FINANZAS ➔ Suspensión de la Bolsa de Tokio durante 4,5 horas (Japón 2005)
• JUEGOS DE AZAR ➔ Caída del sistema de Lotería sin poder confirmar si
había ganadores (EEUU 2007)
• TELECOMUNICACIONES ➔ Caída en sistema de telefonía móvil por varios
días afectando a miles de usuarios (Noruega 2005)
• POLÍTICA ➔ Anomalías en votación electrónica (EEUU 2004)
• TRANSPORTE ➔ Aterrizaje inesperado de un vuelo Airbus por fallos en el
ordenador (Canadá 2008)
5
Más datos sobre la (mala) Calidad - CHAOS Report (*)
✓ Elaborado por Standish Group, es el Informe más famoso sobre el

éxito / fracaso de los proyectos en el sector de las tecnologías de
la información
✓ Hasta el año 2014 se evaluaba el éxito de un proyecto en función

del cumplimiento de los criterios: plazos, presupuesto y alcance
(triple restricción)
✓ A continuación se presentan los resultados hasta el año 2014

según dichos criterios
(*) Informe del CAOS
6
CHAOS Report – Resultados hasta 2014
7
CHAOS Report – Nueva definición de “éxito”
✓ A partir del 2015, la nueva definición de éxito es el cumplimiento de

plazos, presupuesto y resultados satisfactorios (no tiene porqué
cumplirse el alcance)
✓ En el informe del año 2015 se han estudiado unos 50.000
proyectos de todo el mundo desde mantenimientos pequeños
hasta gigantescos proyectos de reingeniería
✓ A continuación se presentan los resultados 2015 según los nuevos
criterios
8
CHAOS Report – Resultados 2011/2015
9
CHAOS Report - Tendencias
✓ Los resultados oscilan sobre los mismos valores: los exitosos

entorno el 30%, los fallidos entorno al 20% y los deficientes
entorno al 50%
✓ Pareciese que no hay ninguna tendencia marcada en el éxito de los
proyectos y que no hay mucha influencia ni de metodologías, ciclos
de vida, etc.
✓ Entonces... otros factores afectarían al éxito o fracaso de los
proyectos
✓ Cuáles serían esos factores?
10
CHAOS Report – Otra forma de analizar sus resultados
11
CHAOS Report – Distribución Proyectos Exitosos
✓ Se muestran ahora sólo los resultados de los proyectos exitosos

(2011-2015) segmentados por su tamaño:
12
CHAOS Report – El tamaño SÍ importa
✓ Se confirmaría así que cuando un proyecto es pequeño es más

fácil de controlar, de manejar, de dirigir y, por tanto, es más
probable de conseguir el éxito
✓ “DIVIDE y VENCERÁS” ➔ Los proyectos grandes son
exponencialmente más complejos que los proyectos pequeños
✓ Por lo tanto, si dividimos un proyecto en partes más pequeñas y lo
vamos haciendo poco a poco, será más sencillo tener éxito
13
Problemas de Calidad - Posibles motivos
✓ Falta de madurez de la propia disciplina
✓ Problemas en el gobierno de las tecnologías y sistemas

informáticos
✓ Falta de formación de los responsables de empresas y organismos
✓ Priorizar la puesta en marcha de los sistemas en forma oportuna,

sacrificando la calidad de los mismos
14
Influencia del Mercado
✓ Según Card (1995) la industria del software pasó por una serie de
modas en función de su foco de preocupación:
➢ Productividad (70’s)
➢ Calidad (80’s)
➢ Time-To-Market (90’s)
✓ Y afirma que para su éxito, las organizaciones deberían considerar los
factores que determinan el mercado ➔ consumidores y
proveedores
✓ Dichos factores determinarán diferentes estrategias de negocio
15
Estrategias de negocio: Calidad vs. Mercado

CAPACIDAD COSTO TIME TO CALIDAD
MARKET
Cuando se inicia
En un mercado con Cuando hay pocos En los mercados
un mercado, la
muchos Proveedores que maduros, la
CAPACIDAD de
Proveedores pero compiten por CALIDAD es la
ofrecer un
pocos muchos determinante
producto es
Consumidores, Consumidores, lo principal de éxito,
prioritaria, ya que
estos determinan la más importante es ya que será difícil
los 1ros.
CALIDAD que poner el producto conseguir el
Consumidores
desean, debiendo el LO ANTES COSTE MENOR
están dispuestos a
Proveedor conseguir POSIBLE en el
aceptar menos
la misma al mercado
CALIDAD si
MENOR COSTE
existen pocos
posible
Proveedores
capaces de
ofrecerles el
producto
16
Mercado según cantidad Consumidores/Proveedores

C
M
O
U
N C TIME TO
S H MARKET CALIDAD
O
U
S
M
I
P
D O
O C
CAPACIDAD COSTE
R O
S
E
S POCOS MUCHOS
PROVEEDORES
17
Componentes de la Calidad de un SI
✓ En función de lo antedicho, la calidad de los SI ha ido

evolucionando....
Mejora de
la calidad
DE: de:
Inspección y detección
procesos,
de errores en programas HACIA:
Aproximación más proyectos,
sistémica productos,
personas,
....
18
Componentes de la Calidad de un SI
MODELO DE LAS 5 “P” (*)
1 2 3 4 5
Quienes
desarrollan,
Aplicaciones, Hardware,
mantienen y De los que
Llevados a datos, software,
operan el dispone la
cabo por la información, telecomunica-
software organización
organización servicios ciones
+
Directivos,
jefes y staff
PERSONAS PROCESOS PROYECTOS PRODUCTOS PLATAFORMAS
(*) Según Mario G. Piattini y otros

19
Calidad de Software
Mediciones, Métricas y Estimaciones
Software - Mediciones, Métricas y
Estimaciones
¿POR QUÉ SE DEBE MEDIR EL SOFTWARE?
“
Si no se mide, no hay forma real de determinar
”
si se está mejorando.
Y si no se está mejorando, se está perdido.
(ROGER S. PRESSMAN)
“ ”
No se puede gestionar lo que no se puede medir.
Se mide lo que se hace y se hace lo que se mide.
(PETER DRUCKER)
21
Estimaciones
✓ Algunos motivos por los cuales medir el software:
▪ PARA DEFINIR UN DETERMINADO PROCESO O PRODUCTO,

ESTABLECIENDO UNA LÍNEA BASE
Debe definirse un determinado proceso o producto que se esté
desarrollando para poder dotarlo de características que lo hagan
identificable frente a otros procesos y que permitan posicionarlo
en un determinado orden con respecto a ellos
22
Estimaciones

▪ PARA PODER COMPARAR OBJETIVAMENTE PROCESOS Y/O
PRODUCTOS
La línea base permite:
• Comparar productos distintos o procesos distintos:
Para determinar de una forma objetiva cuál de ellos es el
mejor o el más adecuado para nuestras circunstancias
• Comparar un proceso con la evolución de sí mismo:

Para poder determinar cuál es el grado de mejoría que se
ha alcanzado a la hora de implementar una serie de
mejoras y acciones evolutivas/correctivas
23
Estimaciones
▪ PARA REALIZAR EL SEGUIMIENTO Y CONTROL DE LOS

DESARROLLOS DE LOS PRODUCTOS Y DE LA EVOLUCIÓN DE
LOS PROCESOS
Dando una herramienta para observar el grado de desviación

que se va produciendo en cada una de las fases realizadas y
permitiendo -si fuera necesario- acometer medidas correctoras y
así poder hacer converger los valores tomados con los valores
previstos
24
Estimaciones
▪ PARA PREDECIR EL COMPORTAMIENTO Y LA EVOLUCIÓN DEL

DESARROLLO
A la hora de realizar una planificación se realiza una predicción

de la duración, del esfuerzo, del tamaño, etc., del desarrollo
Para poder realizar estas predicciones de forma objetiva y
precisa, es necesario conocer cómo es el proceso (definición) y
cómo se comporta (seguimiento y control), para poder así
establecer con seguridad los patrones que seguirán
25
Estimaciones
✓ Con respecto al propio producto/proceso, la medición permite:
DEFINIR
Conocer cómo es
SEGUIR y CONTROLAR PLANIFICAR

Dirigir su evolución y actuar Predecir resultados en función
frente a desviaciones con del conocimiento y del
respecto a la planificación seguimiento y control
EVALUAR MEJORAR
Permite evaluar si se han Con la definición, evaluación
conseguido los objetivos y el seguimiento y control
propuestos todo ello permite mejorar
26
Estimaciones
✓ Con respecto a otros productos/procesos, la medición permite:
EVALUAR LA PRODUCTIVIDAD
DE NUEVOS PROCEDIMIENTOS
ESTABLECER UNA LÍNEA BASE
Y HERRAMIENTAS
Para comparar con otros
Para ayudar a justificar del uso
procesos
de nuevas herramientas y/o
procedimientos
27
Estimaciones
MEDICIÓN DE SOFTWARE
¿PARA QUÉ Para identificar los

Para asignar un SIRVEN LAS componentes del
valor a los atributos
MEDICIONES sistema cuya calidad
de calidad del
DE está por debajo de
sistema
SOFTWARE? un estándar
28
Estimaciones
MEDICIÓN DEL SOFTWARE
La meta de la medición del

Al usar medición de software, se software es usar la medición en
puede valorar un sistema mediante lugar de revisiones para realizar
un rango de métricas e inferir un juicios de la calidad del software.
valor de calidad Si el software alcanzó un umbral de
calidad requerido, entonces podría
aprobarse sin revisión
29
Estimaciones
MEDICIÓN Y MÉTRICAS DE SOFTWARE – CONCEPTOS
✓ Objetivo de medición (para qué se mide)

Finalidad que se desea obtener con las actividades de medición y
análisis (recolección de información, almacenamiento, análisis y
distribución)
Cada necesidad de información tiene asociado uno o más objetivos de
medición, este puede ser cuantitativo o cualitativo
✓ Medición (proceso)
Proceso mediante el cual se asignan números o símbolos a atributos
de productos, procesos o recursos de forma tal que describe los atributos
conforme a reglas definidas de forma precisa
30
Estimaciones
✓ Medida (valor o dato)

Resultado de una medición. Toda medida debe obtenerse para poder
calcular como mínimo una métrica
✓ Métrica (indicador)
Forma de expresar el resultado de una o más medidas, diseñada para
comunicar o explicar el significado de esos resultados
Esta expresión debe obtenerse para cubrir como mínimo un objetivo de
medición
31
Estimaciones
OBJETIVO DE
MEDICIÓN
P
R
O
C
E
S
O
RESULTADOS
Medidas
Medición
MÉTRICA
32
Estimaciones
✓ Ejemplo
• Objetivo de medición: medir la calidad de las entregas de software
realizadas en base al volumen y severidad de incidencias reportadas
por el usuario durante el proceso de Certificación
• Medición: Se contabilizarán todas las incidencias reportadas por el
usuario en etapa de Certificación, acumuladas para cada entrega de
software, diferenciándolas según su Severidad
• Medidas: Cant. de Defectos de Certific. de Severidad Crítica, Cant. de
Defectos de Certific. de Severidad Alta, Cant. de Defectos de Certific. de
Severidad Media, Cant. de Defectos de Certific. de Severidad Baja
• Métrica/Indicador: Calidad de Entregas a Certificación
33
Estimaciones
MÉTRICAS DE SOFTWARE - DEFINICIÓN
✓ Una métrica de software es una característica de un sistema de

software, documentación de sistema o proceso de desarrollo
que puede medirse de manera objetiva
✓ Ejemplos de métricas:
▪ tamaño de un producto en líneas de código
▪ el número de fallas reportadas en un producto de software
entregado
▪ el número de días/hombre requerido para desarrollar un
componente de sistema
34
Estimaciones
Métricas de Software- Atributos Medibles y No Medibles
✓ Existen atributos que son externos, que se ven afectados por

factores subjetivos (como la experiencia y educación del usuario) y, por
lo tanto, no pueden medirse de manera objetiva. Por ejemplo:
✓ Para valorarlos, hay que medir algunos atributos internos del

software (como tamaño, complejidad, etc.) y suponer que estos se
relacionan con las características de calidad que interesan
35
Estimaciones
✓ Atributos externos de calidad del software y atributos internos
(intuitivamente) relacionados con ellos :
36
Estimaciones
✓ Condiciones para que la medida del atributo interno sea un factor

de predicción útil de la característica externa del software:
1 El atributo interno debe medirse con exactitud
Debe existir una relación entre el atributo que pueda medirse y

2 el atributo de calidad externo que es de interés
3 Esta relación entre los atributos interno y externo debe

comprenderse, validarse y expresarse en términos de una
fórmula o un modelo
37
Estimaciones
✓ Algunas clasificaciones de las métricas de software pueden ser:
MÉTRICAS DE
MÉTRICAS
CONTROL o
TÉCNICAS
PROCESO
MÉTRICAS DE
MÉTRICAS
PREDICCIÓN o FUNCIONALES
PRODUCTO
38
Estimaciones
Métricas de Software- De Proceso y Producto
✓ Las métricas de software pueden ser:
MÉTRICAS DE CONTROL o MÉTRICAS DE PREDICCIÓN o

PROCESO PRODUCTO
➢ Apoyan la gestión del proceso ➢ Ayudan a predecir las

características del software
➢ Se asocian por lo general con
procesos de software y se conocen ➢ Se asocian con el software en sí y
como métricas de proceso se conocen como métricas de
➢ Ejemplos: esfuerzo promedio y el tiempo
producto
requerido para reparar los defectos ➢ Ejemplos: la complejidad ciclomática de
reportados un módulo, la longitud promedio de los
identificadores de un programa, el
número de atributos y operaciones
asociados con las clases de objetos en un
diseño
39
Estimaciones
Métricas de Software- De Proceso y Producto
✓ Las métricas de software sirven para:
MÉTRICAS DE MÉTRICAS DE
CONTROL o PROCESO PREDICCIÓN o PRODUCTO
Ayudan a decidir Ayudan a estimar

si deben hacerse el esfuerzo requerido
cambios al proceso para hacer
cambios al software
40
Estimaciones
Métricas de Proceso – Medidas Básicas
✓ Son métricas de control que aportan datos cuantitativos acerca

del proceso de software (Ej.: el tiempo que tarda en realizarse cierta
actividad del proceso)
✓ Hay cuatro características básicas y deben estar entre las

herramientas de gestión del proceso de desarrollo de software:
▪ Tamaño
▪ Esfuerzo
▪ Duración (plazo)
▪ Calidad
41
Estimaciones
✓ Estas medidas cubren importantes características de los

productos y el proceso software relevantes en la planificación,
control y mejora del proceso:
Unidad de medida Características que cubre

Número de módulos / programas
Número de puntos función Tamaño
Número de unidades físicas
Número de líneas físicas de código
fuente
Número de horas consumidas Esfuerzo, coste, recursos
Fechas del calendario Duración, plazos
Contador de problemas o errores
del software
Calidad
Contador de incumplimientos de
los estándares metodológicos
42
Estimaciones
✓ Cada medida necesita unos atributos para ser definida. Ejemplos:

▪ TAMAÑO ➔ definido de acuerdo a lenguajes de programación,
tipo de instrucciones, métodos de producción, nro. de entradas
al producto software y tipo de interfaz con el usuario
▪ ESFUERZO ➔ clasificado por horas de trabajo, tipo de trabajo
realizado y perfil profesional de quien lo realiza
▪ DURACIÓN ➔ definida en términos de fechas y criterios de
finalización
▪ CALIDAD ➔ obtenida de los problemas y defectos que
usualmente estarán clasificados de acuerdo a atributos como
estado, tipo, severidad, prioridad, y dónde se producen
43
Estimaciones
Métricas de Proceso – Medidas Básicas - TAMAÑO
✓ Hay diferentes tipos de medidas que pueden ser usadas para

medir el tamaño de un producto software:
▪ Puntos de Función ➔ técnica de medición de las
funcionalidades ofrecidas por un software, desde el punto de
vista de sus usuarios. Tiene por objetivo tornar la medición
independiente de la tecnología utilizada para su construcción
▪ Líneas físicas de código fuente ➔ atributos: sentencias
ejecutables, declaraciones, directivas de compiladores, líneas
programadas, ...
▪ Unidades de software que pueden ejecutarse ➔ ej.: nro. de
programas
44
Estimaciones
Métricas de Proceso – Medidas Básicas - ESFUERZO
✓ La unidad de medida de esfuerzos por excelencia, es la Hora de

Trabajo
✓ Atributos y valores de Hora de Trabajo típicos:
▪ Información de Horas ➔ regulares, extras, por salario, por hora,
etc.
▪ Clase de Empleo ➔ fijo, contratado, temporal, etc.
▪ Perfil Profesional o Categoría del Empleado ➔ gestor, analista,
programador, tester, etc.
▪ Actividad ➔ desarrollo, mantenimiento, soporte, etc.
▪ Departamento al que está asignado el empleado ➔ Desarrollo,
QA, Oficina de Proyectos, etc.
45
Estimaciones
Métricas de Proceso – Medidas Básicas - ESFUERZO
✓ Razones para medir Horas de Trabajo:

▪ Requisito imprescindible para conocer el costo del software:
✓ La planificación y seguimiento de los recursos humanos
asignados a c/actividad y tarea individual permite gestionar y
controlar los costes y las duraciones de las tareas
▪ Otras posibles unidades para medir los esfuerzos, pero que

presentan más inconvenientes que Horas de Trabajo:
✓ Meses laborables, Semanas laborables, Días laborables
✓ No hay un estándar respecto del nro. de horas que tiene un mes,
una semana o un día laborable y con frecuencia no facilitan
suficiente granularidad para medir y hacer seguimiento de
actividades y tareas individuales
46
Estimaciones
Métricas de Proceso – Medidas Básicas - DURACIÓN
✓ Razones para medir Duración/Plazos:

▪ Entregar a tiempo un producto software, es a veces tan
importante como su funcionalidad o calidad para determinar el
valor final de ese producto
▪ La planificación es una cuestión clave, por ello es crítico
monitorizar el progreso de hitos intermedios (desviaciones
tempranas en la planificación son indicadores de futuros problemas)
▪ Es importante tener objetivos de progreso identificados en el
tiempo, para que la información de las medidas resulte
relevante para conocer el estado y poder proyectar si se
alcanzarán los objetivos de finalización de fechas futuras
47
Estimaciones
Métricas de Proceso – Medidas Básicas - DURACIÓN
✓ Algunos aspectos a considerar:
▪ Los modelos de estimación de costos tienen una gran relación
con las planificaciones de los proyectos
▪ La duración de los proyectos es un parámetro clave a
considerar en la construcción de nuevos modelos de costos o
en la calibración de modelos existentes
▪ Entender que está incluido y qué está excluido en un
proyecto cuando se marca un plazo, es fundamental para poder
estimar su costo
▪ Entender las dependencias de tiempo existentes dentro del
proceso, es fundamental para poder identificar los cuellos de
botella
48
Estimaciones
Métricas de Proceso
✓ La medición es una forma de generar evidencia respecto a un

proceso y los cambios de proceso
✓ Dicha evidencia tiene que interpretarse junto con otra
información sobre el proceso antes de poder implementar
cambios al proceso
✓ Se debe usar la medición en conjunto con la valoración cualitativa
de los cambios
✓ Esto implica hablar con las personas implicadas en el proceso
acerca de los cambios que se introdujeron, y obtener su impresión
de la efectividad de los mismos
49
Estimaciones
Métricas de Producto
✓ Son métricas de predicción usadas para medir los atributos

internos de un sistema de software (Ej.: el tamaño del sistema, la
medida en líneas de código o el número de métodos asociados con cada
clase de objeto)
✓ Las métricas del producto se dividen en dos clases:

1) Métricas dinámicas: se recopilan mediante mediciones hechas de
un programa en ejecución, durante las pruebas del sistema o
después de que el sistema está en uso (Ej.: nro.de reportes de bugs o
tiempo necesario para completar un cálculo)
2) Métricas estáticas: se recopilan mediante mediciones hechas de
representaciones del sistema, como el diseño, el programa o la
documentación (Ej.: el tamaño del código y la longitud promedio de los
identificadores que se usaron)
50
Estimaciones
Métricas de Producto
✓ Las métricas dinámicas ayudan a valorar la eficiencia y fiabilidad

de un programa
✓ Tienen una relación directa con las características de calidad del
software
✓ Las métricas estáticas ayudan a valorar la complejidad,
comprensibilidad y mantenibilidad de un sistema de software o de
los componentes del sistema
✓ Tienen una relación indirecta con los atributos de calidad
51
Estimaciones
Ejemplos de Medidas: Proceso
Entidades de Proceso Atributos Medidas posibles
Proceso de desarrollo Duración Días de calendario
Días laborables
Esfuerzo de desarrollo Horas de trabajo, días, meses
Finalización Porcentaje de finalización en función del
esfuerzo
Porcentaje de finalización en función del
número de tareas
Pruebas Volumen Número de casos de prueba planificados
Número de casos de prueba ejecutados
Número de casos de prueba superados
Porcentaje de casos de prueba superados

respecto a los planificados
Solicitudes de cambio Volumen Número de solicitudes de cambio
esperando servicio
Estado Nombre del estado en el que se encuentra
cada solicitud
Esfuerzo Esfuerzo estimado (horas) para las
solicitudes de cambio pendientes
52
Bibliografía
• Ian Sommerville. “INGENIERÍA DE SOFTWARE”. 9na. Edic. Edictorial

Pearson. 2011
• Víctor Gómez Adán. “ASEGURAMIENTO DE LA CALIDAD”. 1ra. Edic. Kindle.
2016
• Julián Gómez. “GUÍA PRÁCTICA DE ESTIMACION Y MEDICIÓN DE
PROYECTOS”. Edic. Kindle. 2014
• Francisco Sanchis. “LA MEDICIÓN DEL SOFTWARE”. Dpto. OEI /UPM.
Programa de Doctorado
• Martin Alaimo & Martin Salias. “PROYECTOS AGILES CON SCRUM”. 2da.
Edic. Kleer. 2015.
• http://www.pmoinformatica.com/
• http://www.laboratorioti.com/
• http://www.proyectum.lat/2010/11/08/
• http://www.obs-edu.com/int/blog-investigacion/project-management
53

Clase 7 SW - Mediciones Metricas

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 7 SW - Mediciones Metricas

Cargado por

Copyright:

Formatos disponibles

CALIDAD DE LOS SISTEMAS DE

CARRERA: LICENCIATURA EN SISTEMAS DE INFORMACIÓN

Lic. Carlos Paz Soldán (cpazsoldan@unlu.edu.ar)

SITUACIÓN ACTUAL DE LA CALIDAD EN SISTEMAS DE

“ Our civilization runs on software

✓ El software forma parte de nuestras vidas (medios de transporte,

GARTNER NIST IBM

Sólo en EEUU se Las pérdidas económicas

Algunos ejemplos de “desastres” debido a fallas en SI:

Más datos sobre la (mala) Calidad - CHAOS Report (*)

✓ Elaborado por Standish Group, es el Informe más famoso sobre el

✓ Hasta el año 2014 se evaluaba el éxito de un proyecto en función

✓ A continuación se presentan los resultados hasta el año 2014

(*) Informe del CAOS

CHAOS Report – Resultados hasta 2014

CHAOS Report – Nueva definición de “éxito”

✓ A partir del 2015, la nueva definición de éxito es el cumplimiento de

CHAOS Report – Resultados 2011/2015

CHAOS Report - Tendencias

✓ Los resultados oscilan sobre los mismos valores: los exitosos

CHAOS Report – Otra forma de analizar sus resultados

CHAOS Report – Distribución Proyectos Exitosos

✓ Se muestran ahora sólo los resultados de los proyectos exitosos

CHAOS Report – El tamaño SÍ importa

✓ Se confirmaría así que cuando un proyecto es pequeño es más

Problemas de Calidad - Posibles motivos

✓ Falta de madurez de la propia disciplina

✓ Problemas en el gobierno de las tecnologías y sistemas

✓ Falta de formación de los responsables de empresas y organismos

✓ Priorizar la puesta en marcha de los sistemas en forma oportuna,

Influencia del Mercado

Estrategias de negocio: Calidad vs. Mercado

Mercado según cantidad Consumidores/Proveedores

✓ En función de lo antedicho, la calidad de los SI ha ido

MODELO DE LAS 5 “P” (*)

(*) Según Mario G. Piattini y otros

¿POR QUÉ SE DEBE MEDIR EL SOFTWARE?

¿POR QUÉ SE DEBE MEDIR EL SOFTWARE?

✓ Algunos motivos por los cuales medir el software:

▪ PARA DEFINIR UN DETERMINADO PROCESO O PRODUCTO,

¿POR QUÉ SE DEBE MEDIR EL SOFTWARE?

• Comparar un proceso con la evolución de sí mismo:

¿POR QUÉ SE DEBE MEDIR EL SOFTWARE?

▪ PARA REALIZAR EL SEGUIMIENTO Y CONTROL DE LOS

Dando una herramienta para observar el grado de desviación

¿POR QUÉ SE DEBE MEDIR EL SOFTWARE?

▪ PARA PREDECIR EL COMPORTAMIENTO Y LA EVOLUCIÓN DEL

A la hora de realizar una planificación se realiza una predicción

SEGUIR y CONTROLAR PLANIFICAR

✓ Con respecto a otros productos/procesos, la medición permite:

¿PARA QUÉ Para identificar los

La meta de la medición del

✓ Objetivo de medición (para qué se mide)

✓ Medida (valor o dato)

✓ Una métrica de software es una característica de un sistema de

✓ Existen atributos que son externos, que se ven afectados por

✓ Para valorarlos, hay que medir algunos atributos internos del

✓ Condiciones para que la medida del atributo interno sea un factor

1 El atributo interno debe medirse con exactitud

Debe existir una relación entre el atributo que pueda medirse y

3 Esta relación entre los atributos interno y externo debe

MÉTRICAS DE CONTROL o MÉTRICAS DE PREDICCIÓN o