1. PROCESOS DE INGENIERÍA DE SOFTWARE
MÉTRICAS DE PROCESO Y PROYECTO
LORENA LEÓN
GABRIELA PUGLLA

2. Métricas de Proceso y Proyecto

3. Métricas de Proceso y Proyecto
Hay cuatro razones para medir: Caracterizar, Evaluar, Predecir y Mejorar.
• Medida: Valor asignado a un atributo de una entidad mediante una medición.
Ejemplo: 35.000 líneas de código
• Medición: Es el acto de determinar una medida.
Ejemplo: Ana será la encargada de medir las LDC de cada módulo del sistema.
• Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso
posee un atributo dado. Incluye el método de medición.
Ejemplo: La productividad de este proyecto fue de 500 líneas (LDC/persona-mes)
• Indicador: Es una métrica o combinación de métricas que proporcionan una visión
profunda del proceso de software.
Ejemplo: La productividad media de nuestra empresa es de 500 (LDC/pm).
Las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para
desarrollar un producto, como el propio producto. El proceso para intentar
mejorarlo y el producto para intentar aumentar su calidad.

4. Métricas de Proceso y Proyecto
INTRODUCCIÓN
• Son medidas cuantitativas que permiten a los
ingenieros de software obtener una visión de la
eficacia del proceso de software y los proyectos
que llevan a cabo utilizando el proceso como
marco de trabajo.
• Los involucrados en analizar, evaluar y recopilar
estas métricas son los gestores de software.
• Se comienza definiendo un conjunto limitado de
medidas del proceso y del proyecto que puedan
recopilarse con facilidad, se normaliza empleando
métricas orientadas al tamaño o la función.

5. Métricas en los dominios del proceso y
del proyecto
• Las métricas del proceso se recopilan en el curso
de todos los proyectos.
• Las métricas del proyecto permiten que un gestor
del proyecto de software:
– Valore el estado de un proyecto en curso.
– Rastree los riesgos potenciales.
– Descubra las áreas problema.
– Ajuste el flujo de trabajo o las tareas
– Evalúe la habilidad del equipo del proyecto para
controlar la calidad de los productos de trabajo de
software.

6. Métricas para el proceso y la mejora
del proceso de 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.

7. Determinantes para la calidad del
software y la eficacia organizacional

8. • La eficacia de un proceso de software se mide
indirectamente.
• Los resultados incluyen medidas de errores descubiertos
antes de liberar el software.
– Los defectos que detectan y reportan los usuarios finales
– Los productos de trabajo entregados (productividad).
– El esfuerzo humano gastado.
– el tiempo de la planificación consumido.
– Concordancia con la planificación y otras medidas.
• Las métricas del proceso de software ofrecen beneficios
significativos conforme una organización trabaja en mejorar
su grado de madurez del proceso. Sin embargo como todas
las métricas éstas pueden emplearse mal y crear más
problemas de los que solucionan

9. 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.
• Np se obsesione con una sola métrica y excluya otras métricas
importantes.

10. Métricas del proyecto
• En la mayoría de los proyectos de software ocurre durante
la estimación.
• Conforme el proyecto avanza las medidas de esfuerzo y
tiempo utilizados, se comparan con las estimaciones
originales y planificación
• Para las métricas del proyecto, se miden los índices de
producción representados en términos de modelos
creados, horas de revisión, puntos de función y líneas
fuente entregadas.
La finalidad de las métricas del proceso:
• Se emplean para minimizar el tiempo de desarrollo.
• Se utilizan para valorar la calidad del producto sobre una
base actual.

11. MEDICIÓN DEL SOFTWARE
La medición de software se clasifica en dos
categorías.
1. Medidas directas del proceso de software
(Costo, esfuerzo) y del producto (Líneas de
código producidas, rapidez de ejecución y
efectos reportados.)
2. Medidas indirectas del producto que incluyen
funcionalidad, calidad, complejidad, eficiencia, c
onfiabilidad, facilidad de mantenimiento, y
muchas otras habilidades.

12. MEDICIÓN DEL
SOFTWARE

13. Métricas orientadas al tamaño
• Proceden de la normalización de las medidas
de calidad o productividad considerando el
tamaño del software que se ha producido
• Las métricas orientadas al tamaño se aceptan
universalmente como la mejor forma de medir
el tamaño del proceso.

14. Métricas orientadas a la función.
• Se emplean como un valor de normalización
una medida de la funcionalidad que entrega
la aplicación

15. 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.

16. 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

17. 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.

18. Medición de la calidad
• Corrección
• Facilidad de mantenimiento
• integridad
• Facilidad de uso
Estas medidas de la calidad del software ofrecen indicadores
útiles para el equipo del proyecto

19. • 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).

20. • 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).

21. 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).

22. 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

23. 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.

24. INTEGRACIÓN DE LAS MÉTRICAS
DENTRO DEL PROCESO DE SOFTWARE
Los beneficios de la medición son muy
convincentes que el trabajo duro vale la pena.
¿Por qué es importante medir el proceso de la
ingeniería de software y el producto que se
elabora ?
• Argumentos para las métricas del software
• Establecimiento de una línea base
• Recopilación, calculo y evaluación de métricas.

25. Argumentos para las métricas del software:
 Si no se mide no existe una forma real de determinar
si se esta mejorando. Y si no se mejora, se esta
perdido.
 Si el proceso se puede mejorar producir un impacto
directo en lo sustancial
 Establecer objetivos de mejora dentro del proceso
actual del desarrollo de s/w.
 La recopilación de métricas de calidad permite qu
una organización centralice su proceso de s/w para
renovar las causas de los defectos que tienen mayor
impacto sobre el desarrollo del software.

26. Establecimiento de una Línea Base
 Se obtienen beneficios en los ámbitos del
proceso, del proyecto y del producto.
 La línea base de métricas consiste de datos
recopilados en proyectos previos.
 Los datos de la línea base deben tener los siguientes
atributos: los datos deben ser precisos, los datos
deben recopilarse para tantos proyectos sean
posibles, las medidas deben ser consistentes, las
aplicaciones deben ser similares al trabajo que se
estimara.

27. Recopilación, calculo y evaluación de
métricas

28. METRICAS PARA ORGANIZACIÓN
PEQUEÑAS
Un enfoque de sentido común respecto a la
implementación de cualquier actividad
relacionada con el proceso de software es
mantenerlo simple, personalizado para satisfacer
las necesidades locales y asegurarse de que valor
agregar.

29. • Mantenerlo simple: consiste en enfocarse no sobre
las mediciones sino mas bien sobre los resultados.
• Entrevistar al grupo de software para definir un
objetivo sencillo que requiere mejora.
• Una organización pequeña puede seleccionar el
siguiente conjunto de medidas:
– Tiempo transcurrido desde el momento en que se hizo una solicitud hasta que
la evaluación esta completa.
– Esfuerzo para realizar la evaluación.
– Tiempo transcurrido desde que se completa la evaluación hasta la asignación
del pedido de cambio del personal.
– Esfuerzo requerido para hacer el cambio.
– Tiempo requerido para hacer el cambio.
– Errores descubiertos durante el trabajo para hacer el cambio.
– Defectos descubiertos después de que el cambio es liberado a la base de
clientes.

30. ESTABLECIMIENTO DE UN PROGRAMA
DE MÉTRICAS DE SOFTWARE
Esta dirigido por metas según el
SEI(SOFTWARE ENGINEERING
INSTITUTE) y define los siguientes
pasos:
1. Identificar los objetivos de la empresa.
2. Identificar los que se quiere conocer o aprender.
3. Identificar los sub objetivos
4. Identificar las entidades y atributos relacionados
con los objetivos secundarios
5. Formalizar os objetivos de la medición
6. Identificar preguntas cuantificables y los indicadores
relacionados que se emplearan como apoyo para
lograr los objetivos de sus mediciones
7. Identificar los elementos de datos que se
recopilaran para construir los indicadores que
ayudaran a responder las preguntas
8. Definir las medidas que se e emplearan y hacer que
estas definiciones sean operativas
9. Identificar las acciones que se tomaran para
implementar las medidas
10. Prepara un plan para implementar las medidas

31. Al trabajar como equipo , la ingeniería del
software y los gestores del negocio pueden
confeccionar una lista de metas priorizadas
del negocio:
1. Mejorar la satisfacción de los clientes con los productos .
2. Hacer que los productos sean mas fáciles de usar.
3. Reducir el tiempo que toma poner un producto en el
mercado
4. Simplificar el soporte para los productos
5. Mejora la obtención global de utilidades

32. El personal de software desarrolla un conjunto de
preguntas relacionadas con características cuantitativas
por ejemplo, tamaño, costo, tiempo de
desarrollo, estas preguntas se derivan de sub objetivos
relacionadas con las entidades y actividades realizadas
como parte del proceso del software.
Para esto se puede derivar la siguiente lista de
preguntas:
¿la solicitud del cambio del cliente contiene la información requerida para evaluar
adecuadamente el cambio y luego implementarlo en un forma oportuna?
¿cuan grande es el registro de petición de cambio?
¿el tiempo de respuesta para fijar los bugs es aceptable con base en as necesidades del
cliente
¿se sigue el proceso de control de cambios?
¿los cambios de alta prioridad se implementan en forma oportuna?

33. • En base a la preguntas se puede deducir el
sub-objetivo: mejorara el desempeño del
proceso de gestión de cambio
• Se identifican entidades y atributos del
proceso de software
• Según el SEI en esencia se aplica un proceso
de refinamiento paso a paso en el que los
objetivos se refinan en preguntas que
posteriormente se refinan en entidades y
atributos que entonces se refinan en métricas.