Вы находитесь на странице: 1из 15

MTODO DE ANLISIS PUNTOS DE FUNCIN MKII

Los puntos de funcin MKII se obtienen de manera similar al mtodo de Albrecht, esto es, son el producto de dos componentes, el "tamao de procesamiento de la informacin" y el "ajuste de complejidad tcnica".

Componentes del mtodo Mark II


TAMAO DEL PROCESAMIENTO DE LA INFORMACIN. En vez de utilizar cinco componentes: entradas, salidas, interfaces, consultas y ficheros lgicos, el sistema se examina desde el punto de vista de las transacciones lgicas, consistiendo cada una de ellas en entrada, proceso y salida. Se define una transaccin lgica como una combinacin nica de entrada/proceso/salida desencadenada por un nico evento de inters para el usuario, o una necesidad de recuperar informacin. Ejemplos de ello son crear un nuevo cliente actualizar una cuenta generar un informe mensual. La cuenta de PF's no ajustada para una transaccin lgica se basa en la hiptesis

donde los pesos Wi se obtienen por calibrado. AJUSTE DE COMPLEJIDAD TCNICA MKII. Se modifica el ajuste Albrecht en dos sentidos ampliar la lista de caractersticas generales. Se incluyen cinco caractersticas especficas ms y se permite introducir otras. se permite determinar el peso del total de los grados de influencia por calibrado de la instalacin. 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 proporcin de horas trabajadas como se muestra a continuacin Horas totales del proyecto X horas para el "Tamao del Procesamiento de la Informacin" Divididas en - Entrada - Proceso - Salida Utilizado para determinar WI, WO, WE Y horas para los "Factores de Complejidad Tcnica" Divididas en cada uno de los 19 factores (para valorarlos). Si lo que se proporciona es la relacin Y/X entonces TCA(real) = 0.65 (1 + Y/X)

REGLAS PRCTICAS PARA APLICAR MKII FPA EN LA MEDICIN DEL TAMAO DEL SISTEMA
I. ENTIDADES Una entidad es cualquier cosa del mundo real (objeto, transaccin, periodo de tiempo, etc. tangible o intangible, y grupos de clases) acerca de la que queremos saber informacin. 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 aplicacin comercial son: tipo de producto, almacn, cliente, orden, factura, pago, proveedor, orden de compra, empleado, departamento, cuenta, volumen de ventas, volumen de compra, volumen de produccin, 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 seran el nmero total de empleados, media de aos de servicio, etc.

En el caso de tener que resolver relaciones 'varias a varias' (por ejemplo, en el modelo entidad-relacin) las entidades 'interseccin' se tratarn como si fueran una entidad ms.
Para el modelo relacional, una entidad sera 'el sujeto de una relacin en tercera forma normal'. As una ent idad se puede definir como el sujeto de un fichero normalizado. ENTIDADES SISTEMA. En un sistema de personal, "empleado" sera una entidad para la que los datos se introducen y almacenan. Entonces habra que contarla. Por el contrario, un ejemplo de una entidad para la que slo se creara informacin con propsitos de salida sera la entidad colectiva "todos los empleados de la empresa". Si ocurre que esta entidad colectiva slo aparece en la salida, entonces no necesitamos contarla en el tamao del componente de procesamiento de la transaccin, porque se contabilizar en el tamao del componente de salida. ENTIDADES PRIMARIAS VERSUS TABLAS MAESTRAS Y FICHEROS DE PARMETROS. Entidades primarias son las entidades para las que el sistema se ha construdo con la intencin de recolectar y almacenar datos. Pero nos pueden aparecer ficheros que contienen datos fijos acerca de multitud de circunstancias, que se utilizan con el propsito de referencia, validacin, adaptacin del sistema, etc. INTRODUCIDAS Y/O ALMACENADAS EN EL

Habitualmente contienen cdigos de pases, unidades de medida, departamentos, rangos en determinados nmeros de serie, tablas de autorizacin, 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 transaccin que hace al menos una referencia a estos ficheros de parmetros, la regla es contar una referencia a la Entidad del Sistema en la cuenta de entidades referenciadas en esa transaccin. ENTIDADES Y SUBENTIDADES. Todas las subentidades deben contarse como entidades primarias separadas dentro de una transaccin slo si la transaccin procesa cada tipo de subentidad con una lgica de procesamiento diferente, o si las subentidades tienen diferentes atributos. CUENTA DE ENTIDADES Hay que contar el nmero de entidades primarias a las que se hace referencia en una transaccin (no el nmero de referencias a entidades en una transaccin). Por ejemplo, si una entidad es referenciada dos veces en una transaccin (una para leer y otra para modificarla), se cuenta solamente una referencia a esa entidad en esa transaccin. RELACIONES CIRCULARES EN UNA ENTIDAD. Si una entidad se relaciona con ella misma, habr que contarla dos veces. II. TRANSACCIONES LGICAS. Definicin. Una transaccin lgica es una combinacin de uno o ms tipos de entrada, algn procesamiento, y uno o ms tipos de salida correspondientes a un proceso lgicamente nico. Una transaccin se desencadena por un evento en el mundo real que tiene significado para el usuario, o es el resultado de una consulta o extraccin de informacin que no modifica los datos almacenados. Ejemplos de transacciones: extraccin de un registro (o seleccin de registros de acuerdo a los parmetros de entrada) de un fichero maestro, y mostrarlo o imprimirlo aadir un nuevo cliente a un fichero maestro de clientes procesar la cabecera de un pedido (antes de introducir una o ms lneas)

procesar un pedido (la salida puede ser una nota de envo, confirmacin, etc.) calcular la nmina mensual (las entradas pueden ser las horas extras, etc.; las salidas pueden ser la carta de la nmina, instrucciones de pago al banco, informe de pagos de nmina, etc.) calcular el plan mensual de requerimientos de materiales. De estos ejemplos se deduce que estamos definiendo las transacciones al nivel ms bajo de los procesos de la empresa, que se separan por la necesidad de interaccin con el mundo real. Los procesos internos que suceden repetidas veces deben contarse en la transaccin 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 lgicas. Un ejemplo para diferenciar las transacciones lgicas lo encontramos en un sistema simple para gestionar las reservas de un hotel. La figura 20 muestra el diagrama entidad-relacin, y una secuencia de pantallas para solicitar una habitacin se muestra en la figura 21. Tenemos, paradjicamente, dos transacciones lgicas: 1. Una transaccin consultando precio y disponibilidad de habitacin, involucrando 2 entradas: fecha de llegada y de salida 2 entidades referenciadas: tipo de habitacin, tiempo de disponibilidad 4 salidas: fechas, tipo de habitacin y precio (en este momento el dilogo podra interrumpirse, bien por falta de habitaciones o porque el cliente no desea esas habitaciones). 2. Una transaccin lgica para reservar una habitacin, involucrando 9 entradas: fechas, seleccin de habitacin simple y pantalla 02 3 entidades referenciadas: habitacin, cliente y tiempo de disponibilidad 3 salidas: informacin de confirmacin. Si el cliente desea modificar la reserva, las transacciones lgicas seran

- bsqueda de la reserva - cancelacin - solicitud de nueva habitacin Cancelar una reserva ser siempre una transaccin lgica sea cual sea la situacin. Solicitar una nueva habitacin es la misma que la que acabamos de ver. III. DETERMINACIN DE LAS TRANSACCIONES LGICAS EN UNA ESPECIFICACIN FUNCIONAL Dado que el enfoque funcional y el enfoque orientado a los datos pueden dar lugar a diferentes transacciones lgicas, aunque tericamente debieran dar lugar a las mismas, es la tarea del analista decidir qu es lo que se trata como transaccin lgica, teniendo en cuenta qu es lo que genera procesamientos diferentes desde el punto de vista de los requerimientos de usuario. IV. DETERMINACIN DE LAS TRANSACCIONES LGICAS 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 especficamente 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 (da/mes/ao) como un slo 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 pgina 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 ao. 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 slo tipo de fila - cuando las filas se calculan con procesos diferentes (por ejemplo, ventas previstas, ventas reales, ventas facturadas), hay que contar el nmero de tipos de filas, que en este caso son tres.

Finalmente, nmero de tipos de elementos de datos = (nmero de tipos de columnas) (nmero 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 contarn 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, despus de una validacin, un ca mpo de entrada se seala como incorrecto, no hay que contarlo dos veces. Esta situacin es anloga a la generacin de un mensaje de error: la transaccin todava est en la fase de entrada. elementos de control de datos, como por ejemplo campos para la seleccin de opciones de mens, no deben, en general, contarse. Asimismo, tampoco hay que contar el uso de las teclas de funcin. Sin embargo, debe tenerse en cuenta que cada transaccin lgica debe tener, al menos, un elemento de datos de entrada.

VI. AJUSTE DE LA COMPLEJIDAD TCNICA

Las secciones anteriores han definido las reglas para contar lo que Albrecht denomin 'Puntos de Funcin No-Ajustados'. Albrecht propuso multiplicar este valor por un factor que refleje el grado de influencia de otros 14 factores de naturaleza tcnica. Cada caracterstica puede tener un grado de influencia de 0 a 5, y la suma de todas las caractersticas 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 caractersticas tcnicas ms, y se pueden incluir otras justificndolas el peso de cada influencia se obtiene por un proceso de calibracin, en vez de utilizar constantes el factor se denomina 'Ajuste de la Complejidad Tcnica', ms que 'Factor de Ajuste del Valor'. Las reglas de puntuacin general de la influencia de cada caracterstica son: ausente, o ninguna influencia si presente = 0 influencia insignificante influencia moderada influencia media influencia significativa influencia fuerte =3 =4 =5 =1 =2

Estas reglas generales se sustituyen por las reglas especficas como se indica a continuacin. 1. Comunicacin de Datos 0 Aplicacin es batch exclusivamente 1-2 Impresin o entrada de datos remota 3-5 Teleproceso (TP) interactivo 3 TP interface a un proceso batch 5 La aplicacin se interactiva 2. Funcin Distribuda. "Distribuda" significa que los componentes de la aplicacin estn distribudos en dos o ms procesadores diferentes. 0 La aplicacin no ayuda a la trasferencia de datos o a la funcin de procesamiento entre los componentes del sistema 1 La aplicacin 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 realimentacin al sistema inicial 5 Las funciones de procesamiento se realizan dinmicamente en el componente ms apropiado del sistema. 3. Rendimiento (referido a la importancia de respuesta dentro de todo el sistema) 0-3 Anlisis y diseo de las consideraciones del rendimiento son estndar. No se requieren requerimientos especiales por parte del usuario 4 En la fase de diseo se incluyen tareas del anlisis del rendimiento para cumplir los requerimientos del usuario

5 Adems se utilizan herramientas de anlisis del rendimiento en el diseo, desarrollo e instalacin 4. Configuracin utilizada masivamente (referente a la importancia del entorno) 0-3 La aplicacin corre en una mquina estndar sin restricciones de operacin 4 Restricciones de operacin requieren caractersticas especficas de la aplicacin en el procesador central 5 Adems hay restricciones especficas a la aplicacin en los componentes distribudos del sistema. 5. Tasas de Transaccin (una alta llegada de transacciones provoca problemas ms all de los de la caracterstica 3) 0-3 Las tasas son tales que las consideraciones de anlisis de rendimiento son estndares 4 En la fase de diseo se incluyen tareas de anlisis de rendimiento para verificar las altas tasas de transacciones 5 Adems se utilizan herramientas de anlisis 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. Diseo para la eficiencia de usuario final 0 Sistema batch 1-3 No se especifican requerimientos especiales 4 Se incluyen tareas de diseo para la consideracin de factores humanos 5 Adems se utilizan herramientas especiales o de prototipado para promover la eficiencia. 8. Actualizacin On-Line 0 Nada 1-2 Actualizacin on line de los ficheros de control. El volumen de actualizacin es bajo y la recuperacin fcil. 3 Actualizacin on line de la mayora de los ficheros internos lgicos 4 Adems es esencial la proteccin contra la prdida de datos 5 Adems se considera el coste de recuperacin de volmenes elevados. 9. Complejidad del procesamiento (esto es complejidad interna ms all de las convenciones de cuenta de entidades de MkII FPA). Qu caractersticas tiene la aplicacin? mucho procesamiento matemtico y/o lgico 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 cdigo se disea para que sea compartido o utilizable por otras aplicaciones -no confundir con 13). 0-1 Una aplicacin local que responde a las necesidades de una organizacin usuaria 2-3 La aplicacin utiliza o produce mdulos comunes que consideran ms necesidades que las del usuario 4-5 Adems, la aplicacin se "empaquet" y document con el propsito de fcil reutilizacin 11. Facilidad de Instalacin 0-1 No se requieren por parte del usuario facilidades especiales de conversin e instalacin 2-3 Los requerimientos de conversin e instalacin fueron descritos por el usuario y se proporcionaron guas de conversin e instalacin 4-5 Adems se proporcionaron y probaron herramientas de conversin e instalacin 12. Facilidad de Operacin 0 No se especifican por parte del usuario consideraciones especficas de operacin 1-2 Se requieren, proporcionan y prueban procesos especficos de arranque, backup y recuperacin 3-4 Adems la aplicacin minimiza la necesidad de actividades manuales, tales como instalacin de cintas y papel 5 La aplicacin se disea para operacin sin atencin 13. Puestos Mltiples. Aadir puntos por cada uno de los siguientes factores 0 El usuario no requiere la consideracin de ms de un puesto 1 De uno a cuatro puestos 2 Cinco o ms puestos 1 Se proporciona documentacin y plan de apoyo para soportar la aplicacin en varios lugares 2 Los puestos estn en pases diferentes 14. Facilidad de Cambio (esfuerzo especfico de diseo para facilitar cambios futuros). Aadir 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 travs de procesos online interactivos. 15. Requerimientos de otras Aplicaciones

0 El sistema es stand-alone 1-4 Requerimientos del sistema para interfaces o comparticin de datos deben ser sincronizados con otras aplicaciones 5 Se deben sincronizar los requerimientos del sistema con cuatro o ms aplicaciones 16. Seguridad, Privacidad y Auditora. Aadir 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 auditora 1-2 Si el sistema debe cumplir requerimientos excepcionales de seguridad para prevenir prdidas 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 utilizacin de facilidades de "help" estndares 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 envan o reciben de empresas conocidas 2 Empresas conocidas estn conectadas al sistema en modo de lectura solamente 3-4 Empresas conocidas estn conectadas directamente al sistema con capacidad de actualizacin on-line 5 Empresas desconocidas (pblico en general o un grupo demasiado extenso como para ser adiestrado) pueden acceder al sistema 19. Documentacin. Contar 1 por cada tipo de documento listado a continuacin que se entrega al final del proyecto. Especificacin Funcional del Sistema (datos y procesos) Especificacin Tcnica del Sistema Documentacin del programa (al menos diagramas de flujo) Librera de Elementos de Datos Elemento de Datos/ Registro/ X-referencia del programa Manual de usuario Folleto de informacin general del sistema Librera de datos de prueba Material de curso de adiestramiento al usuario Documentos de coste/beneficio del sistema

Informe de peticin 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. Caractersticas definidas por el cliente La lista de Caractersticas de la aplicacin 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 caractersticas, y extenderlo slo en caso que sea necesario. Ejemplos que han sido includos son
requerimiento de salida grfica requerimientos para salida en formato de cdigo de barras y etiquetas, que han de ser proporcionados especficamente a esta aplicacin requerimientos para que el sistema se adapte a ms de un lenguaje natural. VII. ECUACIONES DE CLCULO FP Para proyectos de desarrollo, las reglas a utilizar son como sigue i) Puntos de Funcin No-Ajustados Para todas las transacciones lgicas del sistema, aadir la suma total de Elementos de Datos de Entrada NI Entidades Referenciadas N E Elementos de Datos de Salida N O La frmula para calcular el total del Tamao de Procesamiento de la Informacin expresada en Puntos de Funcin 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 estndares distribudos por algunas compaas WI = 0.58 WE = 1.66 WO = 0.26 ii) Ajuste de la Complejidad Tcnica - TCA TCA = 0.65 + C (suma del grado de Influencia para las 19 caractersticas de la aplicacin, ms las definidas por el cliente) El valor actual medio industrial de 'C' es 0.005 iii) Indice de Punto de Funcin = (Total de UFP's) (TCA)

MTODO DE ESTIMACIN MKII FP


Es un proceso con cinco pasos 1) Calcular o "adivestimar" el tamao del sistema en MkII PF. a) identificacin de las transacciones lgicas del sistema. Si el proyecto est en una fase muy temprana se puede "adivestimar" el sistema, basndonos 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 transaccin lgica contar el nmero de elementos de datos de entrada, tipos de entidades referenciadas y elementos de datos de salida. As se obtienen NI, NE y NO. c) clculo de los UFP UFP = 0.58 NI + 1.66 N E + 0.26 NO (los coeficientes son industriales). d) valorar los grados de influencia de las caractersticas de la aplicacin e) clculo del TCA TCA = 0.65 + 0.005 (grados totales de influencia) 0.005 es un coeficiente industrial. f) obtencin del tamao para las partes on-line (So) y batch (S b) tamao = UFP TCA g) S = S o + Sb 2) Clculo del Esfuerzo h) clculo de la productividad para el desarrollo segn la frmula

- para S < 1000 puntos de funcin

- para S > 1000 puntos de funcin P=L donde P es la productividad en puntos de funcin por hora de trabajo con respecto al tamao del sistema S es el tamao 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 > 10 00). i) clculo del esfuerzo

B = 1.0 para un sistema on-line B = 1.5 para un sistema batch Si tenemos un sistema combinado

j) clculo de la tasa de tiempo de entrega segn la frmula donde D son los puntos de funcin por semana k) clculo del tiempo de entrega

EJEMPLO. SISTEMA DE ALMACENAMIENTO DE MATERIAL -SSS-. Figura 26: Diagrama de contexto del SSS. 4 entidades externas almacn 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 (peticin de recuperacin 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 creacin de SRRs y la reconsideracin de SRRs. La funcin "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 LGICAS. La decisin de recuperar el stock genera los procesos informticos "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.