Puntos de Función Albrecht
NOTA IMPORTANTE: el siguiente texto
tiene como base el libro de J.B. Dreger, "Function Point Analysis",
Prentice-Hall, 1989,
por lo que las afirmaciones que se realizan deben entenderse dentro de ese contexto.
Los Puntos de
Función miden la aplicación desde una perspectiva del usuario, dejando de lado
los detalles de codificación.
Es una técnica
totalmente independiente de todas las consideraciones de lenguaje y ha sido
aplicada en más de 250
lenguajes
diferentes. Se supone que FPA evalúa con fiabilidad
- el valor
comercial de un sistema para el usuario
-
tamaño del proyecto, coste y tiempo de desarrollo
-
calidad y productividad del programador MIS
-
esfuerzo de adaptación, modificación y mantenimiento
-
posibilidad de desarrollo propio
-
beneficios de implementación en 4GL.
Un
Punto de Función se define como una función comercial de usuario final. De esta
manera un programa que tenga
“x” PF’s entrega “x” funciones al
usuario final. El mejor modo de trabajo es la interacción analista-usuario.
El proceso requiere dos etapas
fundamentales:
1. Se identifican las funciones disponibles para el usuario
y se organizan en cinco grupos (mejor en este orden)
- Salidas
-
Consultas
- Entradas
- Ficheros
- Interfaces.
Después se
clasifica y pondera cada función por su nivel de complejidad (simple, media,
compleja).
2. Se ajusta este total de acuerdo con unas características
del entorno. Ver la figura 1.
I. Salidas .
Se debe
contar cada dato único de usuario o salida de control generado proceduralmente
y que sale del límite de la aplicación. Esto incluye informes y mensajes a
otras aplicaciones y usuarios.
Una salida
se considera única si
1. tiene
formato diferente
2. tiene
el mismo formato que otra salida pero requiere diferente lógica de
procesamiento.
Además de
las pantallas y los listados (papel o pantalla), también pueden ser salidas:
• fichero
de transacción enviado a otra aplicación
• facturas
• cheques
• fichas
perforadas
•
transacciones automáticas
• mensajes
al usuario
• cintas
• gráficos
• ficheros
back-up, etc.
No se
deben contar como salidas:
•
cabeceras de columna, títulos, número de página
• mensajes
individuales (información, confirmación o respuestas a consultas de error)
• salida
en igual formato y lógica que ya se hay contado para otro soporte.
Salidas
|
II. Entradas
.
Se debe
contar cada dato único de usuario o entrada de control que se introduce en los
límites de la aplicación y actualiza un fichero lógico interno, conjunto de
datos, tabla o dato independiente. Esto incluye ficheros de entrada y
transacciones recibidas de otras aplicaciones.
Una
entrada se considera única si
1. tiene
un formato diferente
2. tiene
el mismo formato que otra entrada pero requiere una lógica diferente de
procesamiento, o se modifica un fichero interno lógico diferente.
Supongamos que tenemos dos pantallas de entrada, cada una con el mismo formato pero con diferente lógica de procesamiento. Se cuenta cada pantalla como una entrada diferente; pero si tuvieran la misma lógica sólo se contaría una. Lo mismo sucede con la repetición de pantallas.
Supongamos
que tenemos un pantalla cuya función es actualizar un fichero o un conjunto de
datos. Puesto que cada una de las tres funciones de actualización (añadir,
cambiar, borrar) requiere diferente lógica de procesamiento tendremos tres
entradas, no una. Cada fichero tendrá tres entradas, así como una salida (el
fichero formateado de salida) y una consulta.
Tipos de
entradas pueden ser:
• el ratón
•
documentos MICR
•
transacciones de cintas
•
pantallas sensitivas
• lectores
de código de barras, etc.
Entradas
|
III. Consultas
.
Se debe
contar cada combinación única de entrada/salida en la que la entrada on-line definida
por el usuario genera una salida inmediata on-line. Las consultas se pueden
proporcionar a/desde otra aplicación; por ejemplo, responder a otra aplicación
que pregunta por el precio de un producto se contaría como una consulta. Una
consulta se considera única si
1. tiene
un formato diferente de otras bien en su entrada o salida
2. tiene
el mismo formato, tanto entrada como salida, que otra consulta pero requiere
diferente lógica de procesamiento en cualquiera de los dos.
Una
consulta directa en una base de datos o fichero maestro es aquella que
1. utiliza
claves simples para recuperar datos específicos -esto es, un registro simple o
grupo de registros, no un rango-
2.
requiere respuesta inmediata, y
3. no
realiza funciones de actualización (aunque se pueden efectuar cálculos).
Las
consultas pueden aparecer en
• consulta
de usuario/display sin actualización de fichero u otra entidad lógica
• fichero
de transacción que sale del límite de la aplicación si está accesible al
usuario on-line
• pantalla
de selección de menú (todas las pantallas de menú cuentan como una consulta)
• mensaje
de información o pantalla de ayuda.
Consultas
|
IV. Ficheros
Se debe
contar cada grupo lógico mayor de datos de usuario o de información de control mantenidos
dentro de los límites de la aplicación. FPA distingue entre dos tipos de
ficheros: ficheros con transacciones temporales y ficheros con registros
lógicos de datos permanentes. Sólo los almacenamientos de datos permanentes se
ven como ficheros lógicos. Cuando se mantienen dentro de la aplicación se
clasifican como "ficheros internos lógicos". Si se comparten entre
aplicaciones se clasifican como interfaces y cómo ficheros internos lógicos.
Las
transacciones, por el contrario, se considera que son sucesos que desencadenan
cambios en los ficheros lógicos internos; no se clasifican como ficheros. Un
fichero transacción se puede clasificar como entrada si es leído para
actualizar datos en un fichero lógico interno. Un fichero transacción puede ser
un interface o una salida si trasfiere transacciones de actualización a otra
aplicación.
Cuando se
utiliza análisis estructurado cada almacenamiento de datos contendrá al menos
un fichero lógico interno. Hay que enfatizar que hablamos de ficheros lógicos.
Supongamos que un fichero físico contiene dos claves diferentes, entonces
contaríamos dos ficheros lógicos internos, puesto que cada camino presenta
diferente información. Del mismo modo, cada vista lógica del usuario en una
base de datos se cuenta como un fichero.
Se pueden
encontrar ficheros en :
• bases de
datos: 1 por vista lógica o camino de acceso
• ficheros
maestros: 1 por cada grupo de claves
• tablas
mantenidas por los usuarios: estados, tarifas, mensajes, etc.
• fichero
de procesamiento batch
• índices
de referencias cruzadas
Ficheros
|
V. Interfaces.
Se debe contar
como uno cada fichero lógico de otro grupo de datos ( o información de control)
que se envía fuera de los límites de la aplicación, o se comparte o es recibido
desde otra aplicación. Los ficheros que se comparten entre aplicaciones se
cuentan como ficheros y como interfaces en cada aplicación en la que se
utilizan; de otro modo sólo se puntuará como fichero en aquella aplicación que
utilice o mantenga el fichero (la otra sólo recibirá puntos de interface). Esto
es, cada fichero interface debe ser también un fichero interno lógico en esa
aplicación, en otra o en ambas; o puede ser un fichero transacción o de
impresión generado en la propia aplicación. Los interfaces presentan una de
estas situaciones:
1. Datos o
información de control se pasa del fichero A al fichero B. En A se puntúa
fichero e interface y en B sólo interface
2. Datos o
información de control se pasa del fichero B a A. En B se puntúa fichero e
interface y en A sólo interface
3. Datos o
información de control se comparte entre A y B. A y B reciben puntos de fichero
e interface.
Ver tabla
adjunta.
Utilización del fichero: |
en esta aplicación A contar |
en las otras aplicaciones B |
recibido de B |
sólo interface (sin actualizaciones) |
ambos fichero e interface |
compartido con B |
ambos fichero e interface |
ambos fichero ( si se mantiene) e interface |
enviado a B |
ambos fichero e interface |
sólo interface (sin actualizaciones) |
Los interfaces habitualmente involucran ficheros maestros, no transacciones. Hay diferencia entre ficheros maestros lógicos y ficheros transacción. Si las aplicaciones se relacionan a través de transacciones entonces se puntuarán entrada, salida, y/o consulta, y, quizá, interface. Si lo hacen a través de ficheros maestros entonces se puntuará interface y, quizá, fichero. Un fichero transacción no se contará como interface si el formato con el que lo recibe el otro programa es el mismo (no hay conexión). El programa receptor lo contaría como entrada. Si el programa que lo envía realiza el trabajo de conversión entonces se contará (para éste) una salida y un interface.
Los
interfaces se pueden encontrar en:
• ficheros
lógicos internos accesibles desde otra aplicación
• ficheros
lógicos internos accedidos en otra aplicación
• base de
datos compartida
• lista de
parámetros compartida
• fichero
de impresión exportado
• fichero
transacción compartido que requiere conversión.
Se
contarán como un interface
• fichero
de registros de otra aplicación (en la otra aplicación (+1 fichero,
+1
interface)
Ficheros
Transacción |
en esta
aplicación A |
en otras
aplicaciones B |
Situación: |
contar: |
contar: |
NO SE REQUIERE CONVERSIÓN DE DATOS |
|
|
1. Recibido
de B |
entrada (lo
normal) o |
salida |
2. enviado a
B |
salida o |
entrada (lo
normal) |
SE PRECISA CONVERSIÓN DE DATOS |
|
|
1. Recibido
de B, A convierte |
ambos
fichero e interface |
------------------------------ |
2. Recibido
de B, B convierte |
------------------------------ |
ambos
fichero e interface |
3. Enviado a
B, A convierte |
ambos
fichero e interface |
------------------------------ |
4. Enviado a
B, B convierte |
------------------------------ |
ambos
fichero e interface |
• fichero de registros a otra aplicación (+1 fichero) (otra
aplicación +1 interface)
• fichero
de registros a varias aplicaciones (+1 fichero) - afecta al peso de complejidad
también-
• fichero
de registros compartido entre dos o más aplicaciones (+1 fichero) (para las
otras aplicaciones: +1 interface, +1 fichero en cada aplicación si realizan
mantenimiento)
• base de
datos compartida con otras aplicaciones (+1 fichero) 1 interface por cada vista
realmente enviada (para la otra aplicación: +1 fichero, +1 interface por cada
vista utilizada)
• base de
datos compartida de otras aplicaciones (+1 fichero) 1 interface por cada vista
utilizada (para la otra aplicación: +1 fichero, +1 interface por vista)
• fichero
transacción de otra aplicación con conversión de datos (+1 entrada)
• fichero
transacción enviado a otra aplicación con conversión de datos (+1 salida). Los
ficheros transacción sólo se cuentan en una aplicación (no en las dos)
• lista de
parámetros.
Interfaces
|
1-19 items de datos referenciados |
20-50 items de datos referenciados |
51 o más items de datos referenciados |
1 formato/relación de registro lógico |
Simple (5) |
Simple (5) |
Medio (7) |
2-5 formatos/relaciones de registro lógico |
Simple (5) |
Medio (7) |
Complejo (10) |
6 o más formatos/ relaciones de registro lógico |
Medio (7) |
Complejo (10) |
Complejo (10) |
VI. Características
generales FPA de la aplicación.
Según este
método, la cuenta de puntos de función no ajustada debe calibrarse con otros 14
elementos que dependen del entorno. Estos son:
1.
Comunicaciones de datos
2. Datos o
procesamiento distribuídos
3.
Objetivos de rendimiento
4.
Configuración utilizada masivamente
5. Tasa de
transacción
6. Entrada
de datos on-line
7.
Eficiencia para el usuario
8.
Actualización on-line
9.
Procesamiento complejo
10.
Reutilización
11.
Facilidad de instalación y conversión
12.
Facilidad de operación
13.
Puestos múltiples
14.
Facilidad de cambio.
Estos
factores se puntúan de 0 a 5; también se pueden asociar porcentajes, como se
muestra en las figuras.
Valor del Factor |
Influencia en el Sistema |
Porcentaje que afecta o es
requerido por la aplicación |
0 |
Ninguna |
0% |
1 |
Insignificante |
1-20% |
2 |
Moderada |
21-40% |
3 |
Media |
41-60% |
4 |
Significativa |
61-80% |
5 |
Fuerte |
81-100% |
Escala de influencia (excepto para el factor 10) |
Valor del Factor |
Porcentaje que afecta o es requerido
por la aplicación |
0 |
0-10% |
1 |
11-20% |
2 |
21-30% |
3 |
31-40% |
4 |
41-50% |
5 |
>50% |
Escala
de influencia para el factor 10 |
1. Comunicación de Datos: los datos o
información de control que la aplicación utiliza se envía o recibe a través de
las facilidades de comunicación.
0 Aplicación es batch exclusivamente
1-2 Impresión o entrada de datos remota
3-5 Teleproceso (TP) interactivo
3 TP interface a un proceso batch
5 La aplicación es interactiva
predominantemente
2. Función Distribuída. "Distribuída" significa que
los componentes (o los datos) de la aplicación están distribuídos en dos o más
procesadores diferentes (esto también incrementa el factor anterior).
0
La aplicación no ayuda a la
trasferencia de datos o a la función de procesamiento entre los componentes del
sistema
1 La aplicación prepara datos para el
usuario final de otro procesador
2-4 Los datos se preparan para trasferencia,
se trasfieren y se procesan en otro componente del sistema
5 Las funciones de procesamiento se
realizan dinámicamente en el componente más apropiado del sistema.
3. Rendimiento: referido a la importancia de respuesta dentro
de todo el sistema
0-3 Análisis y diseño de las consideraciones
del rendimiento son estándar. No se precisan requerimientos especiales por
parte del usuario
4 En la fase de diseño se incluyen
tareas del análisis del rendimiento para cumplir los requerimientos del usuario
5
Además se utilizan herramientas
de análisis del rendimiento en el diseño, desarrollo e instalación
4. Configuración utilizada masivamente: referente a la
importancia del entorno. Esto es, si hay restricciones de memoria o del
hardware.
0-3 La aplicación corre en una máquina
estándar sin restricciones de operación
4 Restricciones de operación requieren
características específicas de la aplicación en el procesador central
5 Además hay restricciones específicas a
la aplicación en los componentes distribuídos del sistema.
5. Tasas de Transacción: una alta llegada de transacciones
provoca problemas más allá de los de la característica 3
0-3 Las tasas son tales que las
consideraciones de análisis de rendimiento son estándares
4 En la fase de diseño se incluyen
tareas de análisis de rendimiento para verificar las altas tasas de
transacciones
5 Además se utilizan herramientas de
análisis del rendimiento.
6. Entrada On-Line de datos
0-2
Hasta el 15% de las transacciones
tienen entrada interactiva
3-4 15% al 30% tienen entrada interactiva
5 30% al 50% tienen entrada
interactiva.
7. Diseño para la eficiencia de usuario
final
0-3 No se especifican requerimientos
especiales
4 Se incluyen tareas de diseño para la
consideración de factores humanos
5 Además se utilizan herramientas
especiales o de prototipado para promover la eficiencia.
8. Actualización On-Line
0
Nada
1-2 Actualización on line de los ficheros de
control. El volumen de actualización es bajo y la recuperación fácil.
3 Actualización on line de la mayoría
de los ficheros internos lógicos
4 Además es esencial la protección
contra la pérdida de datos
5 Además se considera el coste de
recuperación de volúmenes elevados.
9. Complejidad del procesamiento: esto es, complejidad interna
más allá de la media en lo referente a la entrada, salida o lógica de
procesamiento
¿Qué
características tiene la aplicación?
•
mucho procesamiento matemático y/o lógico
•
procesamiento complejo de las entradas
•
procesamiento complejo de las salidas
•
muchas excepciones de procesamiento, muchas transacciones incompletas y mucho
reprocesamiento de las transacciones
•
procesamiento de seguridad y/o control sensitivo
0 No se aplica nada de esto
1 Se aplica alguna cosa
2 Se aplican dos cosas
3 Se aplican tres cosas
4
Se aplican cuatro cosas
5
Se aplica todo.
10. Utilizable en otras aplicaciones: el código se diseña para
que sea compartido o utilizable por otras aplicaciones (no confundir con 13).
0-1 Una aplicación local que responde a las
necesidades de una organización usuaria
2-3 La aplicación utiliza o produce módulos
comunes que consideran más necesidades que las del usuario
4-5 Además, la aplicación se
"empaquetó" y documentó con el propósito de fácil reutilización
11. Facilidad de Instalación
0-1 No se requieren por parte del usuario
facilidades especiales de conversión e instalación
2-3 Los requerimientos de conversión e
instalación fueron descritos por el usuario y se proporcionaron guías de
conversión e instalación
4-5 Además se proporcionaron y probaron
herramientas de conversión e instalación
12. Facilidad de Operación
0
No se especifican por parte del
usuario consideraciones específicas de operación
1-2 Se requieren, proporcionan y prueban
procesos específicos de arranque, backup y recuperación
3-4 Además la aplicación minimiza la
necesidad de actividades manuales, tales como instalación de cintas y papel
5 La aplicación se diseña para
operación sin atención
13. Puestos Múltiples.
0
El usuario no requiere la
consideración de más de un puesto
1-3 Se incluyeron necesidades de varios
puestos en el diseño
4-5 Se proporciona documentación y plan de apoyo
para soportar la aplicación en varios lugares
14. Facilidad de Cambio: esfuerzo específico de diseño para
facilitar cambios futuros.
0 No hay requerimientos especiales del
usuario para minimizar o facilitar el cambio
1-3 Se proporciona capacidad de consulta
flexible
4-5 Datos importantes de control se
mantienen en tablas que son actualizadas por el usuario a través de procesos
on-line interactivos.
Así, para
calcular el total de puntos de función utilizaremos la fórmula
PF's
no ajustados * (0'65 + 0.01 (influencia 14 factores)).
VII. Ejemplo.
Sistema de Piezas On-Line.
Supongamos
que tenemos en funcionamiento un sistema batch de inventario de piezas.
Queremos añadir a este sistema las siguientes facilidades de menú on-line:
• petición
on-line de informes
• display
on-line del inventario de piezas
• display
on-line de la descripción de las piezas
•
mantenimiento de ficheros on-line.
Debido a
restricciones de almacenamiento, rendimiento y restricciones de tiempo de
respuesta, no se utilizará totalmente el Fichero Maestro de Piezas -FMP- en el
nuevo sistema on-line (se seguirá utilizando en el sistema batch). En vez de
ello, sólo se utilizará una parte del mismo en el Fichero de Piezas
Seleccionadas -FPS- (aquellas con más alta demanda). Los usuarios identificarán
las piezas que se añaden al FPS, al igual que indicarán piezas que no desean
que estén el FPS. Ambas situaciones se llevarán a cabo a través de la Tabla de
Selección de Piezas - TSP-, que relaciona items de FPS con los del FMP, y
mantiene un registro del número actual del FPS.
Se debe proporcionar un informe de control que liste todos los cambios del FPS y liste el tamaño y estado actual (definido al último día laborable). Se debe proporcionar un Informe del Inventario de Piezas, que será solicitado por los operadores y listará las piezas contenidas en el FPS.
Además del
FMP, que es una entidad externa y no será utilizado directamente,
consideraciones de diseño y rendimiento indican que hacen falta dos ficheros
físicos más. Uno de estos es la TSP que consiste sólo en los ítems de datos
número de pieza y código de tamaño, y se relaciona lógicamente con el FMP
(sólo) a través de interface batch. El otro fichero físico es el FPS. Tiene el
mismo formato que el fichero maestro y consiste en dos ficheros lógicos, el
Fichero de Descripción de Piezas, -FDP-, y el Fichero de Localización de Piezas
-FLP-, cada uno de los cuales se relaciona lógicamente con el FMP (a través de
interface batch). El fichero lógico FDP contiene los siguientes ítems:
1. número
de pieza
2. código
de tamaño
3.
descripción
4. precio
unitario
5.
comentarios
La clave
de este fichero lógico es la clave múltiple 1-2-3
El FLP
consiste en
6. número
de pieza
7. código
de tamaño
8. identificación
de la localización
9. stock
disponible
10. stock
pedido
11. fecha
de petición.
La clave
de este fichero es 6-7-8.
En las
figuras 9A y 9B se muestra un diagrama de flujo del sistema. Al tratarse de un
sistema nuevo clasificaremos primero las salidas, consultas y entradas, y
después los ficheros e interfaces.