Estudiante: Lester Thomas

Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

INFORME DEL CAPÍTULO 4

PROCESO DE SOFTWARE Y MÉTRICAS DE PROYECTOS

Las métricas de procesos de software y productos son una medida cuantitativa que permite
a los profesionales de TI obtener información sobre la eficacia del proceso de software y los
proyectos que lideran utilizando el proceso. Las métricas también se utilizan para identificar
áreas problemáticas para que se puedan desarrollar medidas correctivas y mejorar el
proceso del programa. Los administradores del programa analizan y evalúan las métricas
del programa. Las mediciones suelen ser compiladas por ingenieros de software.

Sin medición, solo se puede juzgar sobre la base de la autonomía. Empiece por identificar un
conjunto limitado de métricas de productos, proyectos y procesos que sean fáciles de
recopilar. Los resultados se analizan y comparan con la tasa anterior de proyectos similares
implementados con la organización. Se trata de un conjunto de métricas de software que
proporciona información sobre el proceso y la información sobre el proyecto.

Adoptando un plan de medición simple pero consistente, que nunca usaremos para
evaluar, recompensar o penalizar el desempeño de una persona. La medición nos permite
obtener más información al proporcionar un mecanismo de evaluación objetivo.

Aunque los términos medida, medición y métricas se utilizan a menudo indistintamente, es

importante destacar las diferencias sutiles entre ellos. Dentro del contexto de la ingeniería
del software, una medida proporciona una indicación cuantitativa de la extensión, cantidad,
dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto. El IEEE
define métrica como una medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo dado.

Hay cuatro razones para medir los procesos del software, los productos y los recursos:

• Caracterizar
• Evaluar
• Predecir
• Mejorar

Las proyecciones y las estimaciones basadas en datos históricos también nos ayudan a
analizar riesgos y a realizar intercambios diseño/coste. Medimos para mejorar cuando
recogemos la información cuantitativa que nos ayuda a identificar obstáculos, problemas de
raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el
rendimiento del proceso.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

Cuando, simplemente, se ha recopilado un solo aspecto de los datos por ejemplo el número
de errores descubiertos en la revisión de un módulo se ha establecido una medida. La
medición aparece como resultado de la recopilación de uno o varios aspectos de los
datos. por ejemplo: se investiga un número de revisiones de módulos para recopilar
medidas del número de errores encontrados durante cada revisión. Una métrica del
software relata de alguna forma las medidas individuales sobre algún aspecto. Por ejemplo:
el número medio de errores encontrados por revisión o el número medio de errores
encontrados por persona y hora en revisiones.

MEDIDAS, METRICAS E INDICADORES

• Medida: indicación cuantitativa de extensión cantidad, dimensiones, capacidad y

tamaño de algunos atributos de un proceso o producto.
• Medición: es el acto de determinar una medida.
• Métrica: medida cuantitativa del grado en que un sistema, componente o proceso
posee un atributo dado.
• Indicador: se obtiene de la recopilación de medidas y desarrollo de métricas.
Proporciona: visión profunda del proceso de software, del proyecto de software y del
producto del software.

Las métricas permiten al gestor del proyecto y al Ingeniero Software la toma de decisiones
más fundamentadas.

METRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO

Indicadores del proceso: Permite:

• Visión de la eficiencia de un proceso ya existente.

• Evaluar lo que funciona y lo que no.
• Las métricas de recopilan de todos los proyectos un largo tiempo.

Indicadores del proyecto: Permite:

• Evaluar el estado del proyecto

• Seguir la pista de los riegos potenciales
• Detectar áreas de problemas antes de que se conviertan en criticas
• Ajustar flujo y tareas del trabajo
• Evaluar la habilidad del equipo del proyecto en controlar la calidad de los
productos.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

METRICAS DEL PROCESO

La eficiencia de un proceso de software se mide indirectamente. Se extrae un juego de

métricas según los resultados que provienen del proceso. Entre los resultados se incluyen:

• Errores detectados antes de la entrega del software.

• Defectos detectados e informados por los usuarios finales.
• Productos de trabajo entregado
• Esfuerzo humano y tiempo consumido
• Ajuste con la planificación
• Características de tareas específicas de la Ing. del software.

Para diferentes tipos de datos de proceso existen métricas de:

Uso privado: entre los ejemplos de métricas que son privadas del individuo se incluyen:

• Índices de defectos
• Índices de defectos por módulos
• Errores encontrados durante el desarrollo
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

Uso público: algunas métricas del proceso son privadas para el equipo del proyecto, pero
son públicas para todos los miembros del equipo. Entre los ejemplos se incluyen:

• Defectos informados de funciones importantes del software.

• Errores encontrados durante revisiones técnicas formales y líneas de código o puntos
de función por módulo y función.

A medida que una organización está más a gusto con la recopilación y utiliza métricas de
proceso, la derivación de indicadores simples abre el camino hacia un enfoque más riguroso,
llamado mejora estadística del proceso del software MEPS. MEPS utiliza: análisis de fallos
del software para recopilar información de errores y defectos encontrados al desarrollar y
utilizar una aplicación de sistema o producto.

El análisis de fallos funciona de la siguiente manera:

1) Todos los errores y defectos se categorizan por origen

2) Se registra tanto el coste de corregir cada error como el defecto.
3) El número de errores y de defectos de cada categoría se cuentan y se ordenen en
orden descendente.
4) Se computa el coste global de errores y defectos de cada categoría.
5) Los datos resultantes se analizan para detectar las categorías que producen el
costo más alto para la organización.
6) Se desarrollan planes para modificar el proceso con el intento de eliminar la clase
de errores y defectos que sean más costosos.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

La colección de métricas del proceso es el conductor para la creación del diagrama en espina
completo desde el cual se puede analizar para extraer los indicadores que permitan a una
organización modificar su proceso para reducir la frecuencia de errores y defectos.

METRICAS DEL PROYECTO

• Se deben recopilar métricas de proyectos anteriores que se utilizan como base para
estimaciones (medidas de esfuerzo y tiempo).
• Se miden índices de producción.
• Se miden horas de revisión
• Los puntos de función
• Líneas fuentes entregadas.
• Se sigue la pista de los errores detectados
• Se recopilan las métricas técnicas para evaluar la calidad del diseño.

El uso de métricas para el proyecto tiene dos aspectos fundamentales:

1) Minimizar la planificación de desarrollo

2) Evaluar la calidad de los productos en el momento actual

Otro modelo de métricas sugiere que todos los proyectos deberían medir:

• Entradas: la dimensión de los recursos (personas, entorno) que se requieren para

realizar el trabajo
• Salidas: medidas de las entregas o productos creados durante el proceso de
ingeniería del software.
• Resultados: medidas que indican la efectividad de las entregas.

Este modelo se puede aplicar tanto al proceso como al proyecto. Las salidas de una actividad
se convierten en las entradas de la siguientes.

MEDICIONES DEL SOFTWARE

Medidas Directas:

• Del proceso de la ingeniería del software: se incluyen el coste y el esfuerzo aplicados.

• Del producto: se incluyen las líneas de código producidas, velocidad de ejecución,
tamaño de memoria y los defectos.

Medidas Indirectas:

• Se incluyen la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de

mantenimiento.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

Las métricas del software se dividen en métricas de:

1) Proceso
2) Proyecto
3) Producto

METRICAS ORIENTADAS AL TAMAÑO

• Provienen de la normalización de las medidas de calidad y/o tamaño productividad

considerando el “tamaño” del software. que se haya producido.
• Si una organización de software mantiene registros sencillos, se puede crear una
tabla de datos orientados al tamaño. La tabla lista cada proyecto de desarrollo de
software de últimos años y las medidas correspondientes de cada proyecto.
• Se seleccionan líneas de código como valor de normalización (LDC)

Métricas simples orientadas al tamaño:

• Errores por KLDC (miles de líneas de código, Kilo LDC)

• Defectos por KLDC
• $ por LDC
• Páginas de documentación por KLDC
• Errores/persona-mes
• LDC por persona-mes
• $/página de documentación.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

METRICAS ORIENTADAS A LA FUNCION

Utilizan una medida de la funcionalidad entregada por la aplicación como valor de

normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar
indirectamente mediante otras medidas directas.

Punto de función: se derivan con una relación empírica según las medidas contables
(directas) del dominio de información del software y las evaluaciones de la complejidad del
software. Para aplicaciones de sistemas de información de gestión. Se determinan cinco (5)
características de dominios de información. Los valores de dominios se definen de la forma
siguiente:

1) número de entradas de usuario

2) número de salidas de usuario
3) número de peticiones de usuario
4) números de archivos
5) número de interfaces externas.

Una vez que se han recopilado los datos, a la cuenta se asocia un valor de complejidad. Las
organizaciones que utilizan métodos de punto de función desarrollan criterios para
determinar si una entrada en particular es simple, media o compleja.

Para calcular puntos de función (PF) se utilizan la siguiente relación:

PF= cuenta total * (0.65 + 0.01 *  Fi)

Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

METRICAS AMPLIADA DE PUNTO DE FUNCION

Para remediar la medida del punto de función que era inadecuada para muchos sistemas de
ingeniería y sistemas empotrados (que enfatizan función y control) se proponen un numero de
extensiones básicas a la métrica del punto de función básica:

1. Punto de característica: se acomoda a aplicaciones dónde la complejidad del algoritmo

es alta (software de tiempo real, control de procesos etc.).
2. Algoritmo: problema de cálculo limitado que se incluye dentro de un programa de
computadora específico.
3. Punto de función 3d: adecuada para aplicaciones que enfatizan capacidades de función
y control: sistemas en tiempo real y productos de ingeniería.

• Dimensión de datos: Las cuentas de datos internos y los datos externos se utilizan a lo largo
de las medidas de complejidad para derivar una cuenta de dimensión de datos.
• Dimensión funcional: Se mide considerando el número de operaciones internas requeridas
para transformar datos de entrada en datos de salida.
• Dimensión de control: Se mide contando el número de transiciones entre estados. Un estado
presenta algún modo de comportamiento externamente observable y una transición ocurre
como resultado de algún suceso que cambia el modo de comportamiento del sistema o del
software.

RECONCILIACION DE LOS DIFERENTES ENFOQUES DE METRICAS

La relación entre las líneas de código y los puntos de función depende del lenguaje de
programación que se utilice para implementar el software y la calidad del diseño.

LDC y PF: se utilizan para extraer métricas de productividad.

Cinco factores que inciden en la productividad:

➢ Factores humanos: El tamaño y la experiencia de la organización en desarrollo.
➢ Factores del problema: la complejidad del problema que se debe resolver y el número de
cambios en las restricciones o los requisitos del diseño.
➢ Factores del proceso: técnicas de análisis y diseño que se utilizan, lenguajes y herramientas
CASE.
➢ Factores del producto: fiabilidad y diseño del sistema basado en computadora.
➢ Factores del recurso: disponibilidad de herramientas CASE, y recursos de hardware y
software.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

METRICAS PARA LA CALIDAD DEL SOFTWARE

El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o

producto de alta calidad

VISION GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD.

Los factores de calidad evalúan al software desde tres puntos de vista distintos:
1. operación del producto (utilizándolo)
2. revisión del producto (cambiándolo)
3. transición del producto (modificándolo para que funcione en un entorno diferente)

La relación entre estos factores es llamada marco de trabajo.

MEDIDA DE CALIDAD

Proporcionan indicadores útiles:

- Corrección: Es el grado en el que el software lleva a cabo su función requerida. La
medida más común de corrección son los defectos de KLCD, en donde se define como
una falta verificada de conformidad con los requisitos.
- Facilidad de mantenimiento: Es la facilidad con la que se puede corregir un programa si
se encuentra un error. Se puede adaptar si su entorno cambia, o mejorar, si el cliente
desea un cambio de requisitos.
- Facilidad de uso: Es un intento de cuantificar lo amigable que puede ser con el usuario y
se puede medir en función de 4 características:

1. Habilidad intelectual y/o física requerida para aprender el sistema.

2. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del
sistema.
3. Aumento neto en productividad medida cuando alguien usa el sistema
moderadamente y eficientemente.
4. Valoración subjetiva de la disposición de los usuarios hacia el sistema.

- Integridad: Este atributo mida la habilidad de un sistema para resistir ataques contra su
seguridad. Para medir la integridad, se tienen que definir 2 atributos adicionales: amenaza
es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad de que se pueda repeler el ataque de un tipo
determinado.
Estudiante: Lester Thomas
Matricula: 2010-0423
Asignación: INGENIERIA DE SOFTWARE (SEP./DIC. 2013))
SECC. 555
Profesor: Daniel Mendez
Universidad Católica Santo Domingo

EFICACIA DE LA ELIMINACION DE DEFECTOS

Una métrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del
proceso es la eficacia de la eliminación de defectos (EDD). En esencia EED es una medida de
la habilidad de filtrar las actividades de la garantía de calidad y de control al aplicarse a todas
las actividades del marco de trabajo del proceso. Cuando se toma en consideración globalmente
para un proyecto, EED se define de la siguiente forma:
EED = E/ (E+D)

E= número de errores encontrados antes de la entrega del software al usuario final.

D= número de defectos encontrados después de la entrega.

El valor ideal de EED es 1, esto es, no se han encontrado defectos en el software.

EED también se puede usar dentro del proyecto para evaluar la habilidad de un equipo en
encontrar errores antes de que pasen a la siguiente actividad estructural o tarea de ingeniería
del software.