Método de Análisis
Puntos de Función MkII
Los puntos
de función MkII se obtienen de
manera similar al método de Albrecht, esto es, son el producto de dos
componentes, el "tamaño de
procesamiento de la información" y el "ajuste de complejidad técnica".
Componentes
del método Mark II
Tamaño del Procesamiento de la Información.
En vez de
utilizar cinco componentes: entradas, salidas, interfaces, consultas y ficheros
lógicos, el sistema se examina desde el punto de vista de las transacciones
lógicas, consistiendo cada una de ellas en entrada, proceso y salida. Se define
una transacción lógica como una combinación única de entrada/proceso/salida
desencadenada por un único evento de interés para el usuario, o una necesidad
de recuperar información. Ejemplos de ello son
• crear un
nuevo cliente
•
actualizar una cuenta
• generar
un informe mensual.
La cuenta
de PF's no ajustada para una transacción lógica se basa en la hipótesis
donde los pesos Wi se obtienen por
calibrado.
Ajuste de Complejidad Técnica MkII.
Se
modifica el ajuste Albrecht en dos sentidos
• ampliar
la lista de características generales. Se incluyen cinco características
específicas más y se permite introducir otras.
• se
permite determinar el peso del total de los grados de influencia por calibrado
de la instalación.
Así
TCA = 0.65
+ C · (grado de influencia total).
C se obtiene por calibrado.
Calibrado de los Pesos MkII.
Los pesos
se calibran analizando la proporción de horas trabajadas como se muestra a
continuación
Horas
totales del proyecto
•
X horas para el "Tamaño del Procesamiento de la Información"
Divididas
en
-
Entrada
-
Proceso
-
Salida
Utilizado
para determinar WI, WO, WE
•
Y horas para los "Factores de Complejidad Técnica"
Divididas
en cada uno de los 19 factores (para valorarlos).
Si lo que se proporciona es la relación Y/X entonces
TCA(real)
= 0.65 · (1 + Y/X)
Reglas Prácticas
para Aplicar MkII FPA en la Medición del Tamaño del Sistema
I. Entidades
Una entidad es cualquier cosa del mundo real
(objeto, transacción, periodo de tiempo, etc. tangible o intangible, y grupos
de clases) acerca de la que queremos saber información. Por ejemplo, en un
sistema de personal "empleado" es una entidad. "Fecha de
Nacimiento", sin embargo, no lo es. La fecha de nacimiento es algo que
queremos conocer de la entidad "empleado" (fecha de nacimiento es un
atributo de la entidad empleado).
Ejemplos de entidades primarias que pueden ser introducidas y/o almacenadas en una aplicación comercial son: tipo de producto, almacén, cliente, orden, factura, pago, proveedor, orden de compra, empleado, departamento, cuenta, volumen de ventas, volumen de compra, volumen de producción, etc.
Una
entidad puede ser una cosa cuyas ocurrencias son identificables
individualmente, por ejemplo "empleado", o una cosa colectiva tal
como "todos los empleados de la empresa". Los atributos de esta
entidad serían el número total de empleados, media de años de servicio, etc.
En el caso de tener que resolver relaciones 'varias a varias' (por ejemplo, en el modelo entidad-relación) las entidades 'intersección' se tratarán como si fueran una entidad más.
Para el
modelo relacional, una entidad sería 'el sujeto de una relación en tercera
forma normal'. Así una entidad se puede definir como el sujeto de un fichero
normalizado.
Entidades introducidas y/o almacenadas en el sistema.
En un
sistema de personal, "empleado" sería una entidad para la que los
datos se introducen y almacenan. Entonces habría que contarla. Por el
contrario, un ejemplo de una entidad para la que sólo se crearía información
con propósitos de salida sería la entidad colectiva "todos los empleados
de la empresa". Si ocurre que esta entidad colectiva sólo aparece en la
salida, entonces no necesitamos contarla en el tamaño del componente de
procesamiento de la transacción, porque se contabilizará en el tamaño del
componente de salida.
Entidades Primarias versus tablas maestras y ficheros de parámetros.
Entidades
primarias son las entidades para las que el sistema se ha construído con la
intención de recolectar y almacenar datos. Pero nos pueden aparecer ficheros
que contienen datos fijos acerca de multitud de circunstancias, que se utilizan
con el propósito de referencia, validación, adaptación del sistema, etc.
Habitualmente contienen códigos de países, unidades de medida, departamentos, rangos en determinados números de serie, tablas de autorización, mensajes del operador, mensajes de error, etc.
Aunque
representan "cosas" del mundo real, nos referiremos a ellas como
entidades no primarias. Todas estas entidades no primarias se engloban en una
única denominada Entidad del Sistema.
Para
cualquier transacción que hace al menos una referencia a estos ficheros de
parámetros, la regla es contar una referencia a la Entidad del Sistema en la
cuenta de entidades referenciadas en esa transacción.
Entidades y Subentidades.
Todas las
subentidades deben contarse como entidades primarias separadas dentro de una
transacción sólo si la transacción procesa cada tipo de subentidad con una lógica
de procesamiento diferente, o si las subentidades tienen diferentes atributos.
Cuenta de Entidades
Hay que
contar el número de entidades primarias a las que se hace referencia en una transacción
(no el número de referencias a entidades en una transacción). Por ejemplo, si
una entidad es referenciada dos veces en una transacción (una para leer y otra
para modificarla), se cuenta solamente una referencia a esa entidad en esa
transacción.
Relaciones circulares en una entidad.
Si una
entidad se relaciona con ella misma, habrá que contarla dos veces.
II. Transacciones
Lógicas.
Definición.
Una
transacción lógica es una combinación de uno o más tipos de entrada, algún
procesamiento, y uno o más tipos de salida correspondientes a un proceso lógicamente único. Una
transacción se desencadena por un evento en el mundo real que tiene significado
para el usuario, o es el resultado de una consulta o extracción de información
que no modifica los datos almacenados.
Ejemplos
de transacciones:
•
extracción de un registro (o selección de registros de acuerdo a los parámetros
de entrada) de un fichero maestro, y mostrarlo o imprimirlo
• añadir
un nuevo cliente a un fichero maestro de clientes
• procesar
la cabecera de un pedido (antes de introducir una o más líneas)
• procesar
un pedido (la salida puede ser una nota de envío, confirmación, etc.)
• calcular
la nómina mensual (las entradas pueden ser las horas extras, etc.; las salidas
pueden ser la carta de la nómina, instrucciones de pago al banco, informe de
pagos de nómina, etc.)
• calcular
el plan mensual de requerimientos de materiales.
De estos
ejemplos se deduce que estamos definiendo las transacciones al nivel más bajo
de los procesos de la empresa, que se separan por la necesidad de interacción
con el mundo real.
Los
procesos internos que suceden repetidas veces deben contarse en la transacción
en la que aparecen. No deben contarse como transacciones diferentes a menos que
se desencadenen por un suceso de significado para el usuario.
Cambios en
el valor de un dato de entrada no pueden desencadenar diferentes transacciones
lógicas.
Un ejemplo
para diferenciar las transacciones lógicas lo encontramos en un sistema simple
para gestionar las reservas de un hotel. La figura 20 muestra el diagrama
entidad-relación, y una secuencia de pantallas para solicitar una habitación se
muestra en la figura 21.
Tenemos,
paradójicamente, dos transacciones lógicas:
1. Una
transacción consultando precio y disponibilidad de habitación, involucrando
2
entradas: fecha de llegada y de salida
2
entidades referenciadas: tipo de habitación, tiempo de disponibilidad
4
salidas: fechas, tipo de habitación y precio
(en
este momento el diálogo podría interrumpirse, bien por falta de habitaciones o
porque el cliente no desea esas habitaciones).
2. Una
transacción lógica para reservar una habitación, involucrando
9
entradas: fechas, selección de habitación simple y pantalla 02
3
entidades referenciadas: habitación, cliente y tiempo de disponibilidad
3
salidas: información de confirmación.
Si el
cliente desea modificar la reserva, las transacciones lógicas serían
-
búsqueda de la reserva
-
cancelación
-
solicitud de nueva habitación
Cancelar
una reserva será siempre una transacción lógica sea cual sea la situación.
Solicitar una nueva habitación es la misma que la que acabamos de ver.
III. Determinación
de las Transacciones Lógicas en una Especificación Funcional
Dado que
el enfoque funcional y el enfoque orientado a los datos pueden dar lugar a
diferentes transacciones lógicas, aunque teóricamente debieran dar lugar a las
mismas, es la tarea del analista decidir qué es lo que se trata como
transacción lógica, teniendo en cuenta qué es lo que genera procesamientos
diferentes desde el punto de vista de los requerimientos de usuario.
IV. Determinación de
las Transacciones lógicas de un Sistema Instalado
Ver
referencia [Symmons, 1991]
V. Cuenta de los
Elementos de Datos.
• Contar
tipos de elementos de datos, no ocurrencias de elementos de datos.
• No
contar los elementos de datos de las cabeceras y pies de pantallas o informes
que no se generan específicamente para esa pantalla.
• No
contar etiquetas, cajas, subrayados, etc.
•
Considerar todos los mensajes de error como posibles ocurrencias del tipo de
datos "mensaje de error". Del mismo modo todos los mensajes del
operador se deben considerar como valores del tipo de elemento de datos
"mensajes del operador".
• Contar
las fechas (día/mes/año) como un sólo elemento de datos (aunque se pueden dar
excepciones).
• Para las
tablas se aplica esta última regla, contando tipos de elementos de datos, no
ocurrencias, tanto para las filas como para las columnas. Por ejemplo, si las
columnas de una página muestran las ventas desde enero a diciembre y la última
columna muestra el total anual, y si el procesamiento para cada mes es el
mismo, entonces hay que contar dos tipos de columna, una para el mes y otra
para el año.
Para las
filas pueden ocurrir dos circunstancias
- si cada
fila se calcula mediante el mismo proceso, esto es, si en el informe mencionado
cada fila corresponde a un vendedor, entonces hay que contar un sólo tipo de
fila
- cuando
las filas se calculan con procesos diferentes (por ejemplo, ventas previstas,
ventas reales, ventas facturadas), hay que contar el número de tipos de filas,
que en este caso son tres.
Finalmente, número de tipos de elementos de datos = (número de tipos de columnas) · (número de tipos de filas).
• si el
sistema proporciona valores por defecto para los elementos de datos de entrada,
y los muestra al usuario, quizá para reescribirlos, se contarán como elementos
de datos normales.
• cuando
un elemento de datos de entrada se vuelve a mostrar como salida, hay que
contarlo como entrada y como salida. Sin embargo si, después de una validación,
un campo de entrada se señala como incorrecto, no hay que contarlo dos veces.
Esta situación es análoga a la generación de un mensaje de error: la
transacción todavía está en la fase de entrada.
•
elementos de control de datos, como por ejemplo campos para la selección de
opciones de menús, no deben, en general, contarse. Asimismo, tampoco hay que
contar el uso de las teclas de función. Sin embargo, debe tenerse en cuenta que
cada transacción lógica debe tener, al menos, un elemento de datos de entrada.
VI. Ajuste de la
Complejidad Técnica
Las secciones anteriores han definido las reglas para contar lo que Albrecht denominó 'Puntos de Función No-Ajustados'. Albrecht propuso multiplicar este valor por un factor que refleje el grado de influencia de otros 14 factores de naturaleza técnica. Cada característica puede tener un grado de influencia de 0 a 5, y la suma de todas las características se utiliza para calcular este factor, que puede variar de 0.65 a 1.35.
MkII FPA
sigue exactamente el mismo enfoque, excepto que
• se
incluyen cinco características técnicas más, y se pueden incluir otras
justificándolas
• el peso
de cada influencia se obtiene por un proceso de calibración, en vez de utilizar
constantes
• el
factor se denomina 'Ajuste de la Complejidad Técnica', más que 'Factor de
Ajuste del Valor'.
Las reglas
de puntuación general de la influencia de cada característica son:
• ausente,
o ninguna influencia si presente = 0
•
influencia insignificante =
1
•
influencia moderada =
2
•
influencia media =
3
•
influencia significativa =
4
•
influencia fuerte =
5
Estas
reglas generales se sustituyen por las reglas específicas como se indica a
continuación.
1. Comunicación de Datos
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 se interactiva
2. Función Distribuída. "Distribuída" significa que los
componentes de la aplicación están distribuídos en dos o más procesadores
diferentes.
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-3 Los datos se preparan para trasferencia,
se trasfieren y se procesan en otro componente del sistema
4 Igual que 2-3, pero con
realimentación al sistema inicial
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 requieren 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)
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
Sistema batch
1-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 las convenciones de cuenta de entidades de MkII FPA).
¿Qué
características tiene la aplicación?
•
mucho procesamiento matemático y/o lógico
•
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-3 Se aplica alguna cosa
4
Se aplican dos 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. Añadir puntos por
cada uno de los siguientes factores
0
El usuario no requiere la
consideración de más de un puesto
1 De uno a cuatro puestos
2 Cinco o más puestos
1 Se proporciona documentación y plan
de apoyo para soportar la aplicación en varios lugares
2 Los puestos están en países
diferentes
14. Facilidad de Cambio (esfuerzo específico de diseño para facilitar
cambios futuros). Añadir puntos por cada uno de los siguientes factores
0 No hay requerimientos especiales del
usuario para minimizar o facilitar el cambio
1-3 Se proporciona capacidad de consulta
flexible
1-2 Datos importantes de control se
mantienen en tablas que son actualizadas por el usuario a través de procesos
on-line interactivos.
15. Requerimientos de otras Aplicaciones
0 El sistema es stand-alone
1-4 Requerimientos del sistema para
interfaces o compartición de datos deben ser sincronizados con otras
aplicaciones
5 Se deben sincronizar los
requerimientos del sistema con cuatro o más aplicaciones
16. Seguridad, Privacidad y Auditoría. Añadir puntos por cada uno de
los siguientes factores
1 Si el sistema debe cumplir
requerimientos personales (incluso legales) de privacidad
1 Si el sistema debe cumplir
requerimientos especiales de auditoría
1-2 Si el sistema debe cumplir
requerimientos excepcionales de seguridad para prevenir pérdidas de naturaleza
financiera o militar
1 Si se requiere el criptografiado de
los datos de las comunicaciones
17. Necesidad de Adiestramiento al Usuario
0 Si no es necesario material ni cursos
1-4 Si se requiere entrenamiento especial o
se proporcionan facilidades de ayuda on-line
•
utilización de facilidades de "help" estándares
•
desarrollo de " " especiales
•
entrega de material especial de adiestramiento
5 Se requiere un sistema separado de
entrenamiento o simulador
18. Uso directo de otras empresas
0 No existe otra empresa conectada al
sistema
1 Los datos se envían o reciben de empresas
conocidas
2 Empresas conocidas están conectadas
al sistema en modo de lectura solamente
3-4
Empresas conocidas están conectadas
directamente al sistema con capacidad de actualización on-line
5 Empresas desconocidas (público en
general o un grupo demasiado extenso como para ser adiestrado) pueden acceder
al sistema
19. Documentación. Contar 1 por cada tipo de documento listado a
continuación que se entrega al final del proyecto.
•
Especificación Funcional del Sistema (datos y procesos)
•
Especificación Técnica del Sistema
•
Documentación del programa (al menos diagramas de flujo)
•
Librería de Elementos de Datos
•
Elemento de Datos/ Registro/ X-referencia del programa
•
Manual de usuario
•
Folleto de información general del sistema
•
Librería de datos de prueba
•
Material de curso de adiestramiento al usuario
•
Documentos de coste/beneficio del sistema
•
Informe de petición de cambios y errores
Se
calcula el grado de influencia utilizando la siguiente tabla
0
si 0-2 tipos de documento
1 si 3-4
2 si 5-6
3 si 7-8
4 si 9-10
5
si 11-12 tipos de documento
20. Características definidas por el cliente
La lista de Características de la
aplicación se puede extender, pero teniendo en cuenta que deben provenir de los
requerimientos del usuario.
Como regla general se debe tratar de encajar los requerimientos en las anteriores 19 características, y extenderlo sólo en caso que sea necesario. Ejemplos que han sido incluídos son
• requerimiento de salida
gráfica
•
requerimientos para salida en formato de código de barras y etiquetas, que han
de ser proporcionados específicamente a esta aplicación
• requerimientos para que
el sistema se adapte a más de un lenguaje natural.
VII. Ecuaciones de
Cálculo FP
Para proyectos
de desarrollo, las reglas a utilizar son como sigue
i) Puntos de Función No-Ajustados
Para todas
las transacciones lógicas del sistema, añadir la suma total de
Elementos
de Datos de Entrada NI
Entidades
Referenciadas NE
Elementos
de Datos de Salida NO
La fórmula
para calcular el total del Tamaño de Procesamiento de la Información expresada
en Puntos de Función No-Ajustados es entonces
UFP's
= NI · WI + NE · WE + NO · WO
donde
WI = Peso para un elemento de datos de entrada
WE = Peso para una entidad referenciada
WO = Peso para un elemento de datos de salida.
Podemos
utilizar pesos calibrados en nuestro propio entorno o bien utilizar pesos
estándares distribuídos por algunas compañías
WI = 0.58
WE = 1.66
WO = 0.26
ii) Ajuste de la Complejidad
Técnica - TCA
TCA = 0.65
+ C · (suma del grado de Influencia para las 19 características de la
aplicación, más las definidas por el cliente)
El valor
actual medio industrial de 'C' es 0.005
iii) Indice de Punto de Función
= (Total de UFP's) · (TCA)
Método de Estimación
MkII FP
Es un
proceso con cinco pasos
1)
Calcular o "adivestimar" el tamaño del sistema en MkII PF.
a) identificación de las transacciones
lógicas del sistema. Si el proyecto está en una fase muy temprana se puede
"adivestimar" el sistema, basándonos en nuestra experiencia en
proyectos similares y en la tabla 59.
Aplicar
los pasos b) a f) separadamente para las partes on-line y batch del sistema.
b) para
cada transacción lógica contar el
número de elementos de datos de entrada, tipos de entidades
referenciadas y elementos de datos de salida. Así se obtienen NI, NE y NO.
c) cálculo de los UFP
UFP = 0.58
NI + 1.66 NE + 0.26 NO
(los
coeficientes son industriales).
d) valorar los grados de influencia
de las características de la aplicación
e) cálculo del TCA
TCA = 0.65
+ 0.005 · (grados totales de influencia)
0.005 es
un coeficiente industrial.
f) obtención del tamaño para las
partes on-line (So) y batch (Sb)
tamaño
= UFP · TCA
g) S = So + Sb
2)
Cálculo del Esfuerzo
h) cálculo de la productividad para
el desarrollo según la fórmula
- para S <
1000 puntos de función
- para S
> 1000 puntos de función
P = L
donde
P
es la productividad en puntos de función por hora de trabajo con respecto al
tamaño del sistema
S
es el tamaño del sistema
A
es un factor de escala calibrado al entorno (valores industriales son A = 1.0
para un entorno 3GL, A = 1.6 para un 4GL)
L
es la "productividad en grandes proyectos" (en ausencia de datos se
calcula S = 0.06 · A para S > 1000).
i) cálculo del esfuerzo
B = 1.0 para un sistema on-line
B = 1.5
para un sistema batch
Si tenemos
un sistema combinado
j) cálculo de la tasa de tiempo de entrega
según la fórmula
donde D
son los puntos de función por semana
k) cálculo del tiempo de entrega
Ejemplo. Sistema de
Almacenamiento de Material -SSS-.
Figura 26:
Diagrama de contexto del SSS.
4
entidades externas
almacén
dpto.
de cuentas
proveedores
gerencia.
Figura 28:
Nivel cero del DFD donde se indican tres subsistemas
-
iniciar orden
-
tratar orden de compra
-
informes a gerencia.
nos
centramos en "iniciar orden", mostrada en la figura 28 (a).
Figura 29:
Muestra el DFD nivel uno para "iniciar orden". Este sistema comprende
tres funciones
-
mantener SRR's (petición de recuperación de stocks)
-
contactar proveedor
-
tratar precios.
Los DFDs
para las dos primeras funciones se muestran en las figuras 30 y 31. Examinando
estas dos funciones brevemente, "mantener SRRs" trata de la entrada
inicial y creación de SRRs y la reconsideración de SRRs. La función
"contactar proveedor" (figura 31) consiste en seleccionar a los
proveedores.
La figura
32 muestra el diagrama de entidades de datos para el SSS.
Figura 33:
definiciones de cada una de las entidades y atributos.
Figura 34:
relaciones entre entidades de datos y almacenamientos de datos.
En la
figura 32 se mantienen registros de las
- SRRs
activas
- RFQs
- precios
y órdenes de compra
- algunas
entidades de control del sistema.
Transacciones Lógicas.
• La
decisión de recuperar el stock genera los procesos informáticos "validar
SRR" y "crear SRR"
- entrada:
el flujo de datos "SRR for Val" tiene 5 elementos de datos
-
procesamiento: cuatro almacenamientos de datos, de los que dos provienen de la
entidad del sistema.