Está en la página 1de 17

Doctorado en Sistemas Computacionales

Seminario de Ingeniería de Software

MÉTRICAS DEL PROCESO DE


SOFTWARE
Octavio Ulises Pérez Siliceo

13 de Agosto de 2016
Métricas y Medición
La medición es una herramienta administrativa. Si se realiza adecuadamente,
ofrece entendimiento al gerente de un proyecto. Y, como resultado, lo auxilia a él
y al equipo de software para tomar decisiones que conducirán hacia un proyecto
exitoso.

Las métricas de proceso se recopilan a través de todos los proyectos y durante


largos espacios de tiempo.

Las métricas de proyecto permiten al gerente de un proyecto de software:


1) Valorar el estado de un proyecto en marcha,
2) Rastrear riesgos potenciales,
3) Descubrir áreas problema antes de que se vuelvan “críticas”,
4) Ajustar el flujo de trabajo o las tareas y
5) Evaluar la habilidad del equipo del proyecto para controlar la calidad de los
productos operativos del software.
Métricas para el proceso y mejora del software.

Para mejorar el proceso, se miden sus atributos específicos


.

Hay que destacar que el proceso es sólo uno de varios


factores controlables en la mejora de la calidad del
software y el desempeño organizacional.
MEDICIÓN DEL SOFTWARE
Las medidas directas del proceso de software incluyen costo y esfuerzo aplicado. Las
medidas directas del producto incluyen líneas de código (LOC) producidas, rapidez
de ejecución, tamaño de memoria y defectos reportados sobre cierto espacio de
tiempo.

Las medidas indirectas del producto incluyen funcionalidad, calidad, complejidad,


eficiencia, confiabilidad, capacidad de mantenimiento y muchas otras “habilidades”

Sin embargo, la calidad y funcionalidad del software o su eficiencia o capacidad de


mantenimiento son más difíciles de valorar y pueden medirse sólo de manera
indirecta.

El dominio de la métrica del software se dividió en métricas de proceso, proyecto y


producto, y se dijo que las métricas de producto que son privadas para un individuo
con frecuencia se combinan para desarrollar métricas de proyecto que son públicas
para un equipo de software.
Reglas de Etiqueta para Métricas de software
Grady sugiere un programa de métricas de proceso del proceso tanto para gestores
como para profesionales:

 Aplique el sentido común y sensibilidad organizativa cuando interprete datos


métricos.
 Ofrezca retroalimentación regular a los individuos y equipos que recopilan
medidas y métricas.
 No utilice las métricas para evaluar a los individuos.
 Trabaje con los profesionales y equipos para establecer metas claras y las
métricas que se emplearán para conseguirlas.
 Nunca use métricas para amenazar a los individuos o equipos.
 Los datos métricos que indican un área problema no pueden considerarse
“negativos”. Dichos datos sólo son un indicador de la mejora del proceso.
 No se obsesione con una sola métrica y excluya otras métricas importantes.
Métricas orientadas a tamaño

Con la finalidad de desarrollar métricas que puedan asimilarse con métricas similares de
otros proyectos, pueden elegirse líneas de códigos como un valor de normalización.
Métricas orientadas a tamaño

Errores por KLOC (miles de líneas de código).


• Defectos por KLOC.
• $ por KLOC.
• Páginas de documentación por KLOC.

Además, es posible calcular otras métricas


interesantes:
• Errores por persona-mes.
• KLOC por persona-mes.
• $ por página de documentación
Métricas orientadas a objetos
No proporcionan suficiente granularidad para la planificación y
los ajustes de esfuerzo. Las siguientes son métricas sugeridas
para proyectos OO:

• Número de guiones de escenario

• Número de clases clave

• Número de clases de apoyo

• Número promedio de clases de apoyo por clase clave.

• Número de subsistemas.
Métricas orientadas a casos de uso
El caso de uso se define en etapas tempranas del proceso de software, lo que permite
emplearlo en la estimación antes de iniciar las actividades significativas de modelado
construcción.

Métricas de proyectos de ingeniería Web

“El objetivo de los proyectos de ingeniería Web es construir una aplicación Web que
proporcione una combinación de contenido y funcionalidad al usuario final.” Entre las
medidas que se recopilan existen las siguientes:

• Número de páginas web estáticas


• Número de páginas web dinámicas
• Número de vínculos internos de la página
• Número de objetos de datos persistentes
• Número de sistemas externos en interfaz
• Número de objetos de contenido estático
• Número de objetos de contenido dinámico
• Número de funciones ejecutables
Metricas para la calidad del software

La meta primordial de la ingeniería del software es producir un


sistema, aplicación o producto de alta calidad dentro de un
marco temporal que satisfaga una necesidad del mercado

Corrección
Facilidad de mantenimiento
integridad
Facilidad de uso
Métricas para la calidad del software

Corrección: es el grado en que el software desempeña la función


para la que fue creado donde los defectos se definen como una
falta de concordancia con los requisitos.

Facilidad de mantenimiento: es la sencillez con la que un


programa puede corregirse si se cuenta con un error, adaptarse si
su entorno cambia, o mejorar si el cliente desea un cambio en los
requisitos esta medida demanda mas esfuerzos dentro de las
actividades de la ingeniería de software.

Medida: tiempo medio de cambio( análisis, diseño,


implementación, prueba, distribución).
Métricas para la calidad del software

Integridad: mide la habilidad de un sistema para resistir a ataques


ya sea accidentales o intencionales a su seguridad. Se pueden dar
en los programas, datos y documentos. La medición de la
integridad define dos atributos:
Amenaza: puede estimarse o deducirse es la probabilidad de que un ataque suceda
en un tiempo determinado.
Seguridad: es la probabilidad de que se repela la amenaza.
Integridad = 1 – (amenaza x (1 – seguridad ))

Facilidad de uso: es un intento por cuantificar el uso de la


aplicación al utilizarla y se puede medir en términos del Diseño de
la Interfaz del Usuario(cap 12).
Integridad

Por ejemplo:
si la amenaza (la probabilidad de que un ataque ocurrirá ) es 0,25 y
la seguridad (la posibilidad de repeler un ataque) es 0,95, la
integridad del sistema es 0,99 (muy elevada).

Si por otra parte, la probabilidad de amenaza es 0,50 y la


posibilidad de repeler un ataque es solo 0,25, la integridad del
sistema es 0,63(inaceptablemente baja).
Eficacia en la Eliminación de Defectos (EED)

 Ofrece beneficios tanto en el ámbito como en el


proceso del proyecto.

 Filtra actividades de cualidad y de control dentro de


las actividades del marco de trabajo del proceso

 Cuando se considera un proyecto como un todo de


define:
EED = E / (E + D)
Donde el E es el numero de errores encontrados antes de entregar el s/w al usuario final, y D es el numero
de defectos encontrados después de la entrega. El valor ideal de EED es 1
Eficacia en la Eliminación de Defectos (EED)

La EED también se puede aplicar antes de que pase a la


siguiente actividad del marco de trabajo o a la siguiente
tarea de la ingeniería del software. Se define como:

donde Ei es el numero errores encontrados durante la


actividad i y Ei+1 es el numero de errores encontrado
durante la actividad i+1 de ingeniería de software.
Software

http://www.javiergarzas.com/herramientas-software-recomendadas

ChecKing QA. Es una herramienta Google CodePro Analytix. También es


que controla tanto los elementos una herramienta de gestión de la calidad
del proceso de desarrollo software del software. Ofrece un entorno para
(actividades,requisitos, cambios) evaluación de código, métricas, análisis
de dependencias, cobertura de código,
generación de Test etc.
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 ScrumDo. Permite gestionar las listas de
cosas. Para Java, PHP, Javascript, C#, tareas e historias de usuario, crear y
COBOL, ABAP IV, VB.net, C/C++, gestionar iteraciones, obtener gráficos de
Objective-C, Android, JSP, avance “burndown” y también dar soporte
Hibernate, SQL, PL/SQL. Cuadro de a la estimación con Planning Poker.
mando basado en la ISO 9126. (Comercial)
Bibliografía

Ingeniería de software, Pressman 7a edición,


McGrowHill, 2010

Ingeniería del software, Ian sommerville, 7ma. Ed.


Pearson 2005

Ingeniería de software: una guía para crear sistemas de


información, Alejandro Peña Ayala , México, IPN, 2006.

También podría gustarte