Вы находитесь на странице: 1из 6

CAPITULO 4

EL PROCESO DE SOFTWARE Y METRICAS DEL PROYECTO

Métricas del software: Son medidas para el software de computadora. La medición se puede aplicar:
- al proceso (para mejorarlo)
- en el proyecto (para ayudar en la estimación, control de calidad etc).
- El ingeniero del software (para evaluar calidad de productos/ para ayudar en la toma de decisiones)

4.1 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.
Metrica: 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 soft, del proyecto de soft y del producto del soft
Las métricas permiten al gestor del proyecto y/o ing. soft la toma de decisiones más fundamentadas.

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

METRICAS DEL PROCESO

La eficiencia de un proceso de soft 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 soft.
- 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:
- indices de defectos
- índices de defectos por módulos

1
- errores encontrados durante el desarrollo
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.
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:


- Minimizar la planificación de desarrollo
- 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 soft.
- 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.

2
4.3 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.
Las métricas del software se dividen en métricas de:
- proceso
- proyecto
- 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 soft. que se haya producido.
- Si una organización de soft mantiene registros sencillos, se puede crear una tabla de datos
orientados al tamaño. La tabla lista cada proyecto de desarrollo de soft 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, KiloLDC)
- defectos por KLDC
- $ por LDC
- páginas de documentación por KLDC
- errores/persona-mes
- LDC por persona-mes
- $/página dedocumentación.

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 soft y las evaluaciones de la complejidad del soft. Para aplicaciones de
sist de inf de gestión. Se determinan cinco (5) características de dominios de información. Los valores
de dominios se definen de la forma siguiente:
- número de entradas de usuario
- número de salidas de usuario
- número de peticiones de usuario
- números de archivos
- 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:

3
PF= cuenta total * (0.65 + 0.01 * ∑ Fi)

4
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:
- Punto de característica: se acomoda a aplicaciones dónde la complejidad del algorítmo es alta (soft
de tiempo real, control de procesos etc).
Algoritmo: problema de cálculo limitado que se incluye dentro de un programa de computadora
específico.
- 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 soft.

4.4 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 extrae 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.

4.5 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:

5
- Corrección: es el grado en el que el soft lleva a cabo su función requerida. La medida mas 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: éste 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.

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= numero de errores encontrados antes de la entrega del soft al usuario final.


D= numero de defectos encontrados después de la entrega.

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


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

Вам также может понравиться