UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

PROGRAMA DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWARE
_______________________________________________________________________

Taller METRICAS SW

TEMA : Métricas de producto y de calidad

Sami Arévalo Montes Rol: Director Del Proyecto Cod.1151351

Laura Daniela Buitrago Espitia Rol: Analista de base de datos Cód. 1151354

Manuel Salazar Rol: desarrollador Cód. 1151382

Natalia Reyes Rol: desarrollador Cód. 1151372

 Explicar las principales métricas de calidad de código e interpretar los resultados de estas métricas
sobre sus proyectos a través de la herramienta SonarQube.

Hemos podido observar la potencia de la herramienta y de que con muy poquito esfuerzo podemos
obtener grandes beneficios controlando el nivel de calidad de los proyectos para un futuro
mantenimiento. Creo, personalmente, que es muy importante hacer este tipo de análisis cuando
estás a cargo de mantener distintos proyectos software. Este tipo de técnicas es muy sencilla de
implementar, y podemos obtener mucha información y resultados a cambio de nada.

1. Dar ejemplos de uso de diversos tipos de métricas (según el proyecto en desarrollo)

 Promedio de esfuerzo por KLOC

 Porcentaje de reinspecciones
 Promedio de fallas detectadas por KLOC
 Total KLOC inspeccionadas
 Promedio de líneas de código inspeccionadas
 Eficiencia de los defectos removidos
 Promedio de esfuerzo por defecto detectado

2. Describir la utilidad de las métricas de software

Las métricas de Software ayudan a una organización en dos frentes:

 Evaluación de la calidad del producto
 Evaluación de la calidad del proceso para producir productos de software

Uno de los objetivos primordiales al planear, es determinar el esfuerzo y, por ende, el tiempo, que va a
tomar un proyecto.
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

Estándares del producto: se aplican al producto a desarrollar

 Estándares de documentos (p.ej., estructura del documento de requerimientos a producir)
 Estándares de documentación (encabezados estándar de comentarios para una definición de
clase)
 Estándares de codificación (cómo utilizar un lenguaje de programación)

Estándares del proceso: definen los procesos a seguir durante el desarrollo

 Definiciones de los procesos de especificación y análisis, diseño, validación, descripción de los
documentos a generar en cada uno de estos procesos

3. Explicar la importancia de la medición en los procesos de calidad

La acción de medir es el proceso por el cual números o símbolos son asignados a atributos de
entidades en el mundo real, de tal forma que los describen de acuerdo a reglas claramente
definidas.

Uno de los objetivos de la ciencia es encontrar formas para medir atributos de las cosas en las
que estamos interesados. Las métricas hacen los conceptos más visibles y por lo tanto más
entendibles y controlables.

4. Diferenciar las principales métricas de productos de software orientados a objetos

Para un Producto, Proceso o Recurso tenemos:

Atributos externos
Pueden ser medidos únicamente con respecto a su interacción con el ambiente.
Por ejemplo: Confiabilidad
Atributos Internos
Pueden ser medidos en términos puramente de las entidades en si mismas.
Por ejemplo, líneas de código
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

Entidad Interno Externo

Especificaciones tamaño, reutilización, Entendible

modularidad, corrección mantenibilidad
sintáctica

Diseños tamaño, reuse, calidad, complejidad

modularidad, mantenibilidad
acoplamiento,
funcionalidad

Código tamaño, reuse, confiabilidad,

complejidad algorítmica, mantenibilidad
flujo de control
estructuración

5. Formular metas y planes de calidad

Construir un plan de calidad basado en ciertos índices de desempeño.

Contenido del Plan
 Resumen de Porcentajes
 Porcentaje libre de defectos (PDF)
 Defectos por Página
 Defectos por KLOC
 Proporción de defectos (Ratio)
 Proporción de tiempos de desarrollo
 A/FR
 Porcentaje de revisión e inspección
 Porcentaje de inyección de defectos
 Porcentaje de eliminación de defectos
 Rendimiento (yield) de fase
 Rendimiento (yield) de proceso
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

Resumen de Porcentajes
 Las tres medidas del resumen dan una perspectiva global de la calidad del Proceso:
 LOC/Horas: mide la productividad global del grupo. Un número grande indica
gran productividad y bajos costos
 % Reutilización: mide el porcentaje global de este producto que fue reutilizado
de proyectos anteriores
 % Reutilización nuevo: mide la contribución de este ciclo al mejoramiento de
la productividad en ciclos posteriores o proyectos.

Porcentaje libre de defectos (PDF)

 Mide el porcentaje de los componentes de un producto que no tiene defectos en una
fase dada.
 Ejemplo:
 Un componente con 5 partes y cuatro tenían defectos en la fase de
compilación, el PDF del componente en la fase de compilación es del 20% (no
se tiene en cuenta el número de defectos)
 Entre mayor el número de partes, mayor la precisión del PDF para medir la
calidad del componente.
 Datos de PDF en todas las fases de eliminación de defectos permite ver el
mejoramiento de la calidad a través del proceso de desarrollo.

Defectos por Página

 Muestra el número de defectos removidos de cada página del documento de
requerimientos y del diseño de alto nivel

Defectos por KLOC

 Un defecto es cualquier elemento asociado con los requerimientos, el diseño o la
implementación que de no ser cambiado puede causar un diseño, implementación,
prueba, uso o mantenimiento del producto no adecuados.
 Un defecto mayor es cualquier problema que cuando se arregla cambia el código
ejecutable.
 Defectos en formatos o comentarios son considerados menores.
 El número de defectos encontrados en una fase de pruebas indica la calidad del
producto entrando y saliendo de esa fase.
 Cuando un producto tiene muchos defectos, una fase de pruebas encontrará muchos
de ellos poro también dejará sin encontrar muchos.
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

 Si hay muchos defectos en pruebas unitarias, probablemente habrá todavía muchos

terminada esa fase.
 La experiencia muestra que cuando un producto tiene menos de 0.5 defectos/KLOC en
construcción y pruebas de integración y menos de 0.2 defectos/KLOC en pruebas de
sistema, generalmente no habrá defectos para que encuentre el usuario (producto de
alta calidad).

Proporción de defectos (Ratio)

 Provee un mayor detalle de la calidad de las revisiones de diseño y de código
 La experiencia muestra que cuando se encuentra el doble de defectos en revisión de
código que en compilación, la revisión de código fue realizada a conciencia. En este
caso la proporción de defectos es 2.0
 Número de defectos encontrados en revisión de diseño contra número de defectos
encontrados en pruebas unitarias. Esta proporción debería ser más de 2.0 !!

Proporción de tiempos de desarrollo
 Según la experiencia, las siguientes proporciones dan una idea de la buena calidad del
producto (no es una garantía poro la probabilidad es alta):
 25% del tiempo de requerimientos debe ser en inspección de requerimientos
 50% del tiempo de diseño de alto nivel debe ser en revisiones e inspecciones
 >100% del tiempo de diseño detallado debería ser en revisiones e
inspecciones

A/FR (appraisal to failure ratio)

(Revisión/Pruebas)
 Para programas pequeños debería ser alrededor de 2.0
 Para programas grandes debería ser alrededor de 1.0 porque aun si los programas
tienen pocos defectos en pruebas, probarlos es dispendioso.

Porcentaje de revisión e inspección

 Requerimientos: <2.0 páginas de texto a espacio simple por hora
 Diseño de alto nivel: <5.0 páginas de diseño por hora
 Diseño detallado: < 100 líneas de pseudo código por hora
 Código: < 200 líneas de código por hora
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

Porcentaje de inyección de defectos

 de acuerdo con datos de varios cientos de programas escritos por estudiantes y por
ingenieros experimentados en un curso de PSP, se tiene que:
 la proporción de inyección de defectos durante diseño detallado es de 2
defectos por hora
 y es de 6 defectos por hora en codificación

Porcentaje de eliminación de defectos

 Tomando la misma muestra, los datos fueron más variados:
 en revisión de código va de 0 a 20 defectos por hora, el resultado fue de 6
defectos por hora para el 61.5% de los ingenieros
 en revisión de diseño, 2 o más defectos por hora para el 57.9% de los
ingenieros

Rendimiento (yield) de fase

 Porcentaje de defectos en un programa que fueron removidos durante una fase dada.
 Ejemplo:
 19 defectos en el programa a la entrada de la revisión de código
 se inyectó un defecto durante la revisión de código
 se encontraron 15 durante la revisión
 yield = 100* (defectos encontrados)/(defectos en el producto) = 100* 15/
(19+1) = 75%
 Se puede calcular sólo cuando se ha terminado el programa y se sabe el número total
de defectos

Rendimiento (yield) de proceso

 El porcentaje de defectos removidos antes de una fase dada.
 Ejemplo, antes de pruebas de sistema debería ser de 99%

6. Explicar la importancia de los datos históricos en los modelos predictivos

Los modelos predictivos son la clave para poder, mediante un esfuerzo analítico, detectar
oportunidades de inversión, conocer la previsión de ventas o la cuota de mercado, identificar los
segmentos de consumidores más rentables o los mercados de destino con mayor potencial. También
juegan un papel importante a la hora de identificar los riesgos asociados a los productos existentes o
los que pueden derivarse de la implementación de una determinada estrategia empresarial en el
futuro.
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

7. Aplicar las métricas de software para asegurar la calidad del producto de manera objetiva.

-Aseguramiento de la calidad
Establecimiento de un marco de trabajo de procedimientos y estándares corporativos que
conduzcan a la obtención de software de alta calidad

–Planificación de la calidad
Selección de procedimientos y estándares adecuados a partir de ese marco de trabajo y
adaptación de éstos para un proyecto de software específico

–Control de la calidad
Definición y aplicación de los procesos que aseguren que los procedimientos y estándares son
seguidos por el equipo de desarrollo

8. Identificar mecanismos de evaluación y adecuación de un proyecto.

Mejora de la calidad:
1. Identificar productos de calidad
2. Examinar el proceso utilizado para desarrollarlos
3. Generalizar esos procesos para aplicarlos a otros proyectos

Fabricación: relación clara entre calidad de proceso y del producto

–Proceso fácil de estandarizar y supervisar
–Una vez definido el proceso de fabricación se ejecuta una y otra vez para producir el mismo
producto con el mismo nivel de calidad

Software: existe relación, pero menos directa

–Proceso más creativo que mecánico: influencia de habilidades individuales y experiencia
–Factores externos (novedad de la aplicación, presión comercial,...)
–El proceso puede ser inapropiado para un tipo de software

Por ejemplo, un estándar puede indicar que la especificación tiene que estar terminada y aprobada
para implementar, pero puede hacer falta realizar prototipos.
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
_______________________________________________________________________

Control de calidad: Vigilar el proceso de desarrollo para asegurar que se siguen los procedimientos
de SQA y estándares de calidad ajustándose al plan de calidad
–Dos enfoques complementarios Revisiones técnicas: el software, documentación y procesos son
revisados por un grupo de personas

Valoración: normalmente automática, con algún tipo de herramienta

–El software y los documentos se procesan y se comparan con los estándares que se aplican
a ese proyecto
–Implica una medida cuantitativa de de algunos atributos del software (medición y métricas)

9. Buscar otras herramientas de software libre que permitan realizar métricas de software
diferentes a las anteriores. (por lo menos 3 por equipo de desarrollo)

ChecKing QA.
Es una herramienta que controla tanto los elementos del proceso de desarrollo software
(actividades,requisitos, cambios) como los elementos analizables del software (código fuente,
proyectos, documentación, scripts de pruebas etc) knewstuffknewstuff

Kiuwan.
Herramienta en Cloud (Saas) de análisis de código que permite medir la calidad y la deuda
técnica del software entre otras cosas. Para Java, PHP, Javascript, C#, COBOL, ABAP IV, VB.net,
C/C++, Objective-C, Android, JSP, Hibernate, SQL, PL/SQL. Cuadro de mando basado en la ISO
9126. knewstuffknewstuff

PMD.
Analizador estático de código, principalmente Java. Identifica problemas como repetición de
código, if`s anidados, etc. (BSD)

Check Style
Analizador estático de código, principalmente Java. Comprueba si se siguen las reglas de estilo.
(GNU Lesser General Public License Version 2.1)