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.