La Única forma racional de mejorar cualquier proceso es medir atributos del proceso, desarrollar un juego de métricas significativas según estos atributos y entonces utilizar las métricas para proporcionar indicadores que conducirán a una estrategia de mejora.
el proceso se sitúa en el centro de un triángulo que conecta tres factores con una profunda influencia en la calidad del software y en el rendimiento como organización. La destreza y la motivación del personal se muestran como el Único factor realmente influyente en calidad y en el rendimiento
METRICAS ORIENTADAS A TAMAÑO
Las métricas del software orientadas al tamaño provienende la normalización de las medidas de calidad y/oproductividad considerando el «tamaño» del softwareque se haya producido. Si una organización de softwaremantiene registros sencillos, se puede crear una tablade datos orientados al tamaño
Para desarrollar métricas que se puedan compararentre distintos proyectos, se seleccionan las líneas de
código como valor de normalización. Con los rudimentariosdatos contenidos en la tabla se pueden desarrollarpara cada proyecto un conjunto de métricassimples orientadas al tamaño:errores por KLDC (miles de líneas de código)
defectos4 por KLDC
E por LDC
páginas de documentación por KLDC
errores por persona-mes
LDC por persona-mes
E por página de documentación
METRICAS ORIENTADAS A LA FUNCION
Las métricas del software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. Las métricas orientadas a la función fueron propuestas por primera vez por Albretch , quien sugirió una medida llamada punto de función. Los 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.
Los puntos de función se calculan completandola tabla Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla.
Los valores de los dominios de información se definen de la forma siguiente:
Número de entradas de usuario.
Se cuenta cada entrada de usuario que proporciona diferentes datos a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada.puntos de función se derivan de medidas directas del dominio de la información.
Número de salidas de usuario.
Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elemento de datos particulares dentro de un informe no se cuentan de forma separada.
Número de peticiones de usuario.
Una petición sed efine como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada petición por separado.
Número de archivos.
Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo independiente).
Número de interfaces externas.
Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema. Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad.
Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja .No obstante la determinación de la complejidades algo subjetiva.
METRICAS DE CALIDAD
El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros del software deben aplicar métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo de software. Además, un buen ingeniero del software(y buenos gestores de la ingeniería del software) deben medir si la alta calidad se va a llevar a cabo. calidad de un sistema, aplicación o producto es tan bueno como los requisitos que describen el problema, el diseño que modela la solución, el código que conduce a un programa ejecutable, y las pruebas que ejercitan el software para detectar errores. Un buen ingeniero del software utiliza mediciones que evalúan la calidad del análisis y los modelos de diseño, el código fuente, y los casos de prueba que se han creado al aplicarla ingeniería del software. Para lograr esta evaluación de la calidad en tiempo real, el ingeniero debe utilizar medidas técnicas que evalúan la calidad con objetividad, no con subjetividad
El gestor de proyectos también debe evaluar la calidad objetivamente, y no subjetivamente. A medida proyecto progresa el gestor del proyecto también debe evaluar la calidad. Las métricas privadas recopiladas por ingenieros del software particulares se asimilan para proporcionar resultados en los proyectos. Aunque se pueden recopilar muchas medidas de calidad, el primer objetivo en el proyecto es medir errores y defectos. Las métricas que provienen de estas medidas proporcionan una indicación de la efectividad de las actividades de control y de la garantía de calidad en grupos o en particulares.
Un programa debe operar correctamente o proporcionará poco valor a sus usuarios. La 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 es defectos por KLDC, en donde un defecto se define como una falta verificada de conformidad con los requisitos.
Facilidad de mantenimiento.
El mantenimiento del software cuenta con más esfuerzo que cualquier otra actividad de ingeniería del software. La facilidad de mantenimiento es la facilidad con la que 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.
En esta época de «hackers» la integridad del software ha llegado a tener mucha importancia. Este atributo mide la capacidad de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes del software: programas, datos y documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad.
Amenaza es la probabilidad (que se puede estimar o deducir de la evidencia empírica) de que un ataque de un tipo determinado ocurra en un tiempo determinado.
La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia empírica)de que se pueda repeler el ataque de un tipo determinado. La integridad del sistema se puede
definir como: integridad = C [( 1 - amenaza) x (1 - seguridad)]donde se suman la amenaza y la seguridad para cada tipo de ataque.
Facilidad de uso.
El calificativo «amigable con el» se ha convertido en omnipresente en las discusiones sobre productos de software. Si un programa no es «amigable con el usuario», frecuentemente está abocado al fracaso, incluso aunque las funciones que realice sean valiosas. La facilidad de uso es un intento de cuantificar «lo amigable que puede ser con el usuario» y se puede medir en función de cuatro características:
(1) habilidad intelectual y/o física requerida para aprender el sistema;
(2) el tiempo requerido parallegar a ser moderadamente eficiente en el uso del sistema;
(3) aumento neto en productividad (sobre elenfoque que el sistema reemplaza) medida cuando lguien utiliza el
sistema moderadamente y eficientemente;y
(4) valoración subjetiva (a veces obtenidamediante un cuestionario) de la disposición de los usuarios hacia el
sistema.
Una organización pequeña puede seleccionar el siguiente conjunto de medidas fácilmente recolectables :
- Tiempo (horas o días) que transcurren desde el momento que es realizada una petición hasta que se complete su evaluación, tcola
- EsFuerzo (horas-persona) para desarrollar la evaluación, WeVa1.
- Tiempo (horas o días) transcurridos desde la terminación de la evaluación a la asignación de una orden de cambio al personal, teval.
- Esfuerzo (horas-persona) requeridas para realizar el cambio, Wcambio.
- Tiempo requerido (horas o días) para realizar el cambio
- Errores descubiertos durante el trabajo para realizar el cambio, Ecambio
- Defectos descubiertos después de que el cambio se haya desviado a la base del cliente, Dcambio.
el porcentaje de esfuerzo requerido para la evaluación y la implementación puede también ser determinado. Estas métricas pueden ser evaluadas en el contexto de los datos de calidad, Ecambio y DcanIbio .Los porcentajes proporcionan un análisis interno para buscar el lugar donde
los procesos de petición de cambio se ralentizan y pueden conducir a unos pasos de mejoras de proceso para reducir tco!a ' wevgl i.teva[ ; Wcambioy y/o Ecambio*
la eficiencia de eliminacion de defectos (EED) puede ser calculada de la siguiente manera:
EED = Ecambio ' (Ecambio+Dcamhio)
EED puede compararse con el tiempo transcurrido y el esfuerzo total para determinar el impacto de las actividades de aseguramiento de la calidad sobre el tiempo y el esfuerzo requeridos para realizar un cambio.
