Hola, soy José Luis Abellán Miguel y en esta unidad 7 vamos a ver las métricas de

productos SW.
Voy a empezar introduciendo las métricas, un marco conceptual en el cual debemos identificar
qué es una medida, qué es una métrica y qué un indicador ya que muchas veces se utilizan
de manera aleatoria pero que realmente son conceptos distintos y finalmente las métricas
el modelo de requisitos basándome en la medida de los puntos de función, la métrica de
puntos de función.
Las métricas nos ayudan es a que cuando nosotros vamos a elaborando nuestro producto SW
durante
todo el proceso SW: análisis, diseño, codificación y pruebas... debemos de tener ciertos valores
cuantificables que nos digan cuanto de bueno es nuestro SW.
Entonces, la métrica nos ofrece comprensión acerca de los atributos de ese SW que debemos
de medirlos y que nos den una idea de cuál es la calidad de nuestro SW.
¿Qué pasos debemos de dar para las métricas de producto?
Lo primero de todo es identificar cuáles son las mediciones simétricas que vamos a
llevar a cabo, a continuación recolectar los datos de nuestro producto SW, interpretar
los resultados y, finalmente, utilizar esa interpretación para modificar nuestro SW
si es que la calidad no es la adecuada.
Aquí distinguimos entre medida, métrica e indicador.
Una medida es básicamente cuando en un diagrama UML tenemos tres errores o nuestro código
tiene 100 líneas de código para la parte de diseño.
Una métrica, por otro lado, interpreta esos valores, darle semántica y poder relacionarlos
también como, por ejemplo, el número promedio de errores que se encuentran por revisión.
Finalmente un indicador nos proporciona compresión acerca de la métrica que hemos evaluado
y
que nos ayude a identificar si nuestro SW es de baja o alta calidad.
Aquí podremos decir que si la tasa de fallos, esa métrica que podíamos haber evaluado
si la tasa de fallo es mayor que 0.2 entonces se revisará el producto de SW, ya es un indicador
que nos ayuda a saber si nuestro SW es válido o no, es de alta calidad o no.
Vamos a pasar ahora a la métrica de punto de función que se utiliza en la parte del
análisis de nuestro SW y que nos permite medir la funcionalidad que entra a un sistema
mediante una serie de valores que ahora veremos y utilizando datos histórico, es decir, la
métrica punto de función se van aplicando sobre nuestros proyectos que vamos desarrollando
durante la vida de nuestra empresa de SW y nos ayuda a identificar estimaciones como,
por ejemplo, cuál es el costo o esfuerzo requerido para diseñar, codificar y probar
el SW, predecir si habrá un determinado número de errores, preveer el número de líneas
de código que tendremos...
Tened en cuenta que estamos en la parte del análisis de nuestro proceso de SW y nuestras
predicciones nos serán de gran ayuda.
Aquí vemos que para poder definir la métrica de punto de función vemos que para poder
definir la métrica del punto de función debemos de identificar una serie de valores
de dominio de información en los cuales vemos el número de entradas externas que cuando
nosotros tenemos nuestro producto SW que vamos a desarrollar, cuáles serán aquellas entradas
que van a facilitar las estructuras de datos internas de nuestro SW, ¿cuáles son las
salidas externas?
Pues por ejemplo, mensajes de errores, cómo se comporta mediante determinados eventos,
cuáles son las salidas por pantalla...
Más valores de dominio de información pues por ejemplo el número de consultas externas
que se van a realizar para recuperar datos, el número de archivos lógicos internos que
es una estructura de datos que utiliza nuestra app y, finalmente, número de archivos de
interfaz externos es decir, que otras estructuras de datos externas ajenas a nuestro producto
SW existe comunicación .
En esta tabla mostramos cómo se aplica la métrica de punto de función, lo primero
de todo es que vemos en la primera columna vemos valor de dominio de información que
he explicado anteriormente lo que tenemos que realizar es un conteo, ¿cuántas entradas
externas tiene?
10, ¿salidas internas?
Así vamos haciendo un conteo.
Luego tenemos el factor ponderado que lo que hacemos es indicar la complejidad de cada
uno de esos valores de dominio y asignarles un valor por el cual se multiplique.
Ese valor puede ser simple, promedio y complejo; como podéis ver es lógico que ese valor
ponderado aumenta, ¿de qué depende ese valor?
Pues muchas veces es un valor subjetivo que depende de la experiencia, de cuantos proyectos
hemos desarrollado antes, identificamos mediante un archivo lógico interno cuánto puede ser
su complejidad.
Al final vamos a realizar un conteo realizando esas operaciones y aquí determinaremos la
métrica de los puntos de función y utilizaremos ese valor parcial de conteo total y lo
multiplicaremos
05:20
por una serie de valores.
Aquí vemos un sumatorio, y atiende a los factores de ajuste de valor en los cuales
son una serie de catorce preguntas que vamos a numerar de 0 a 5 dependiendo si estamos
más o menos de acuerdo y vamos a ir preguntando, por ejemplo, ¿el sistema requiere respaldo y
recuperación confiables?
pues la respuesta es, si estamos muy acuerdo, un 5.
¿Existen funciones de procesamiento distribuidas?
pues si no estamos nada de acuerdo, pondremos un 0 y así con cada una de estas respuestas.
Aquí vamos a ver un ejemplo de cómo se aplica esta métrica de puntos de función y vemos
ahí un esquema donde identificamos cual va a ser a nivel de análisis cual es su diagrama
en el cual vemos una serie de componentes de agentes como usuario, sensores, datos de
configuración de sistema, sistemas de monitoreo y respuestas que afectaran a nuestro producto
de SW, que es una función de interacción con usuario de una app que se llama "Casa
segura"en la cual identificamos entradas externas, consultas externas, ALI, salidas externas,
AIE.
Entonces hemos visto que tenemos tres entradas externas, 2 consultas externas... y así vamos
realizando el proceso de conteo.
En la segunda columna tenemos donde pone conteo tenemos todos esos valores, realizamos las
distintas operaciones y vemos que el factor ponderado decimos que la complejidad es simple
para todos ellos, al final obtenemos un conteo total, que es 50, y ese 50 se integra dentro
de esa función en la cual al final decimos que hemos calculado que un 46, como vemos
ahí, ante esos factores de variación o ajuste de valor, mejor dicho, y obtenemos al final
un valor 56, ¿ese 56 que nos dice?
si nosotros a partir de nuestro histórico de SW decimos a qué equivale cada punto de
función, que son 56, y de acuerdo al histórico de nuestra empresa habiendo desarrollado unos
productos de SW decimos, ¿a cada punto de función le equivale que?
pues por ejemplo, ¿cuántas líneas de código?
unas 20, ¿horas por cada punto de función?
2,5, ¿punto de función al mes que se van desarrollando?
20 y entonces podemos hacer estimaciones.
Si hemos calculado que nuestro proyecto a va a tener 56 puntos de función decimos que
su duración estimada utilizando los puntos de función que hemos utilizado al mes al
final hacemos la operación y sabemos que tardaremos, más menos, 2.8 meses de trabajo.
¿Cuántas líneas de código vamos a desarrollar?
Pues si sabemos cuantas líneas de código tenemos por cada punto de función que son
20 hacemos la operación y decimos 1120 líneas de código y, ¿cuál será el tiempo total
que vamos a emplear?
pues si sabemos las horas por cada punto de función al final estimando lo que tenemos
que son unas 140 horas y entendemos así cual será la magnitud de nuestro proyecto de software.