You are on page 1of 5

Karin Adaly Hernndez Pacheco

0909-09-10773

Mtricas de calidad
sus objetivos son:

Medir lo que el usuario pide y lo que el usuario recibe.


Medir independientemente de la tecnologa utilizada en la implantacin
del sistema.

Proporcionar una mtrica del tamao.

Proporcionar un medio para la estimacin del software.

Proporcionar un factor de normalizacin para la comparacin de distintos


software.
Una vez presentado el mtodo, su autor realiz mejoras sobre el modelo inicial y
ha publicado diferentes versiones del mismo. En 1986, Allan Albrecht funda
el Grupo Internacional de Usuarios de Puntos de Funcin (en ingls International
Function Point User Group IFPUG). Esta organizacin se encarga de la difusin
del mtodo y de la publicacin de manuales de uso y documentos de cmo sacar
provecho del mismo.
Los Puntos de Funcin fueron diseados originariamente para ser aplicados
a sistemas de informacin de gestin, es por ello que se puso nfasis en la
dimensin de datos, excluyendo las dimensiones funcionales y de control. Su
aplicacin no era del todo adecuada para sistemas de ingeniera y embebidos,
pero con el correr del tiempo, se fueron subsanando estos inconvenientes. An
as, han surgido algunas variantes, entre las que se pueden contar:
Feature Points (Puntos de Caractersticas): este mtodo fue propuesto por
Caper Jones [Jones, 1987] como una alternativa que permitiera obtener puntos de
funcin en software cientfico y de ingeniera. Para evitar confusiones con los
Puntos de Funcin, Jones lo denomin puntos de caracterstica (en ingls feature
points). Actualmente es usado con mucho xito en software del tipo CAD (del
ingls Computer Aided Design), sistemas embebidos y sistemas en tiempo real.
MK II FPA: propuesto por Charles R. Symons [Symons, 1998], este mtodo es una
derivacin de los Puntos de Funcin de Albrecht, el que considera al sistema que
se est analizando, compuesto por cinco tipos de componentes (entradas

Karin Adaly Hernndez Pacheco

0909-09-10773

externas, salidas externas, consultas externas, grupos de datos lgicos internos y


externos), mientras que el MK II FPA mira al sistema como una coleccin de
transacciones lgicas discretas, compuestas cada una de ellas por
entrada, proceso y salida. Si se usan herramientas modernas de diseo para
el desarrollo del software, y esas herramientas permiten identificar fcilmente las
transacciones lgicas, resulta apropiado el uso de este mtodo.
3-D Function Point: entre los aos 1989 y 1992, Scott Whitmire [Whitmire, 1992]
desarroll un mtodo para la empresa internacional de aeronavegacin Boing.
El objetivo fue ampliar su espectro a sistemas con elevada complejidad como los
sistemas en tiempo real. El trmino 3D, se refiere a que considera tres
dimensiones en las que puede proyectarse un sistema software; ellas son:
datos, funciones y control. Visto de esta forma, resulta atractivo el uso del mtodo,
para aquel tipo de software, pero presenta el inconveniente de la necesidad de
disponer de mayor cantidad de informacin acerca del sistema, sobre todo de la
complejidad de los algoritmos a implementarse; esta informacin no siempre est
disponible en las primeras etapas del desarrollo.
Full Function Points (Puntos de Funcin Completos): esta tcnica ha sido
desarrollada por un equipo de la Universidad de Qubec en Montreal (Canad)
[Abran A., et al., 1998], siendo muy eficiente en la medicin de puntos de funcin
en sistemas de control, tiempo real y embebido. Particularmente, los sistemas en
tiempo real presentan dos factores crticos: primero, el tiempo de respuesta y en
segundo lugar, su interaccin con entidades externas. Los puntos de funcin de
Albrecht tienen limitaciones para medir sistemas software en tiempo real. Estos
ltimos trabajan con dos tipos de estructura de datos de control: grupo lgico de
ocurrencia mltiple, que puede tener ms de una instancia por cada tipo
de registro y el grupo lgico de ocurrencia nica, que puede tener solamente una
instancia por cada tipo de registro. En lo que respecta a las transacciones, los
sistemas en tiempo real, presentan una variacin importante en la cantidad de
subprocesos por proceso; es decir, el mtodo debera contemplar que
unos procesos contaran con unos pocos subprocesos y otros en cambio, con un
nmero significativo de ellos. Los puntos de funcin se basan ms en el nmero
de procesos que en el de subprocesos. Para paliar este inconveniente, Full
Function Points introduce en el clculo no solamente a los procesos, sino que
tambin incluye a los subprocesos.
COSMIC FFP: a finales de 1998, un grupo de expertos en mtricas de software,
establecieron el Common Software Measurement International Consortium
(COSMIC FFP). La iniciativa de COSMIC, ha sido bsicamente la de dar
respuesta a proveedores y a clientes de servicios de desarrollo de software,
principalmente en aquellos contratos de terceros donde no haba reglas claras
acerca del valor de este tipo de servicio. En tal sentido COSMIC apunta a
satisfacer tanto a proveedores de software que deben traducir los requerimientos

Karin Adaly Hernndez Pacheco

0909-09-10773

del cliente en un tamao del software como un paso clave en la estimacin de


los costos del proyecto, como a los clientes que quieren conocer ese tamao
recibido como un componente importante para la medicin del rendimiento del
proveedor. El mtodo se puede aplicar a dominios de software de gestin, tiempo
real e hbridos.

Aplicacin de los puntos de funcin al proyecto SGPC

nmero de entradas del usuario = 2


nmero de salidas del usuario = 2
nmero de consultas de usuario = 2
nmero de archivos = 1
nmero de interfaces externas = 0

se multiplicar por un facto de ponderacin simple


Factor de ponderacin
Parmetro de medicin
Nmero de entradas del usuario
Nmero de salidas del usuario
Nmero de consultas del usuario
Numero de archivos
Numero de interfaces externas
Cuenta total

cuenta
2
2
2
1
0

Simple
3
4
3
7
5

Media
4
5
4
10
7

FORMULA PARA CALCULAR LOS PUNTOS DE FUNCION

compleja
6
7
6
15
10

total
6
8
6
7
0
27

Karin Adaly Hernndez Pacheco

0909-09-10773

Donde sumatoria de fi se saca en el anlisis con base a 14 preguntas, para


nuestro caso es 46 que es un producto moderadamente complejo.
PF = 27 * (0.65+(0.01* 46))
PF = 29.97
Con esto podemos decir que segn la estimacin son 30 lneas que se
tendrn que desarrollar para cumplir con esta funcin.
Tiempo medio entre fallas (MTBF)
Es la media aritmtica (promedio) del tiempo entre fallos de un sistema. El
MTBF es tpicamente parte de un modelo que asume que el sistema fallido se
repara inmediatamente (el tiempo transcurrido es cero), como parte de un proceso
de renovacin.
Tiempo medio de reparacin (MTTR)
Es una medida bsica de la capacidad de mantenimiento de reparables
artculos. Representa el promedio de tiempo necesario para reparar un
componente o dispositivo que ha fallado. expresa matemticamente, es el total de
mantenimiento correctivo tiempo para fallos dividido por el nmero total de
acciones de mantenimiento correctivas para fallos durante un perodo determinado
de tiempo. por lo general no incluye el tiempo de entrega de piezas no estn
fcilmente disponibles u otros administrativos o logsticas tiempo de inactividad
(ALDT).
En el diseo tolerante a fallos, tiempo medio de reparacin por lo general se
considera que incluye tambin el momento en que la culpa es latente (el tiempo
desde que se produce el fallo hasta que se detecta). Si una falla latente no se
detecta hasta que se produzca un fallo independiente, el sistema puede no ser
capaz de recuperarse.
MTTR es a menudo parte de un contrato de mantenimiento, donde un sistema
cuyo tiempo medio de reparacin es de 24 horas es generalmente ms valioso
que uno de 7 das si el tiempo medio entre fallos es igual, ya que su operativa
disponibilidad es mayor.
Aplicacin de la mtrica MTBF y MTTR al proyecto SGPC
1. Calcular el MTBF Y MTTR de la base de datos del proyecto si ha tenido 4
cadas en los ltimos 5 meses la primera y la segunda cada se solucion
en 10 minutos y las dos ltimas en 50 minutos.
4 fallos en 5 meses
5 meses a minutos 5 * 30 * 24*60 = 216,000 min

Karin Adaly Hernndez Pacheco

0909-09-10773

4 fallos en minutos 10 + 10 + 50 + 50 = 120 min


Minutos funcionando correcto 216,000 120 = 215,880
MTTR = 120 / 4 = 30 min
MTBF = 216,000 / 4 = 54000 min
con esto podemos decir que el tiempo medio de fallos de nuestra base de
datos ocurre cada 54,000 min y el tiempo medio de reparacin de los fallos
es de 30 min.

You might also like