guía pf 2006 versión completa

8/7/2019 Gua PF 2006 versin completa

1/88

UNIVERSIDAD DE COSTA RICA

ESCUELA DE CIENCIAS DE LACOMPUTACIN E INFORMTICA

Metodologa para medir el proceso de software

Profesora: Gabriela Salazar Bermdez

Versin 2

Ao - 2006


2/88

2

TABLA DE CONTENIDO

CAPTULO 1 3

Metodologa de Anlisis de Puntos de Funcin 3Paso 1. Determinar el tipo de conteo de puntos de funcin. 4Paso 2. Identificar el alcance del conteo y la frontera de la aplicacin. 5Paso 3. Identificar todas las funciones de datos y su complejidad y determinar lospuntos de funcin desajustados. 6Paso 4. Identificar todas las funciones transaccionales y su complejidad y determinar lospuntos de funcin desajustados. 13Paso 5. Determinar el Factor de Ajuste de Valor (FAV) a travs de las 14 CaractersticasGenerales 31Paso 6. Calcular el Punto de Funcin de Ajuste Final. 39

CAPTULO 2 40

Casos Prcticos de Estimacin de Puntos de Funcin 40Caso 1: Sistema de Planilla 40Caso 2: Sistema de Administracin de Contrataciones 51Caso 3: Sistema de Administracin de Requerimientos 57Caso 4: Sistema de Control de Horas 67

CAPTULO 3 81

Estimacin del costo y el esfuerzo con base en los Puntos de Funcin estimados 81Procedimiento para estimar costo y esfuerzo cuando no contamos con datos histricos. 81Procedimiento para estimar costo y esfuerzo cuando contamos con datos histricos. 84

REFERENCIAS BIBLIOGRFICAS 86


3/88

Resumen

El Anlisis de Puntos de Funcin (FPA, en ingls Function Point Analysis) fuedesarrollado por A. J. Albrecht y sus colegas de IBM a mediados de 1970, con su primerapresentacin pblica en 1978. El propsito era solucionar algunos de los problemasasociados con el clculo del tamao en Lneas de Cdigo (LOC, en ingls Lines of code)y las medidas de productividad, especialmente por las diferencia en los clculos de LOCque resultaban de los diferentes niveles de lenguajes que se utilizaban. [1, pg 95] A l leinteresaba medir la funcionalidad del software desde el punto de vista del usuario,independientemente de su implementacin. l introdujo los Puntos de Funcin como unamedida del tamao de una aplicacin desde un punto de vista funcional o de usuario.

En 1984 la organizacin responsable de definir y aclarar las reglas para el clculo dePuntos de Funcin fue dada a International Function Point Users Group (IFPUG).IFPUG adems de aclararlas, modific el mtodo original de Albrecht, publicando elCounting Practices Manuals que provee los estndares para la aplicacin del clculo de

los Puntos de Funcin. [1, pg. 456]A travs de los aos la mtrica de Puntos de Funcin ha ganado aceptacin como unamedida de productividad clave. El principal beneficio es que han dado a la industria desoftware la habilidad de realizar estudios econmicos serios. Como permite medir todas lasactividades del software (requerimientos, diseo, codificacin, pruebas, documentacin,administracin, etc.) ha llegado a ser un estndar de lnea base y benchmarks delsoftware.

El estndar actual de Puntos de Funcin publicado por IFPUG en su versin 4.1, fueexplicada por David Garmus y David Herron en su obra Function Point Analisis:Measurement Practices for Successful Software Projects [2]. Ellos han contribuido

durante mucho tiempo con el IFPUG.Este documento intenta explicar en idioma espaol y con casos prcticos, la metodologa dePuntos de Funcin, utilizando como base los captulos 7 al 10 de la obra de Garmus yHerron [2]. Es conveniente indicar que esta tcnica no es trivial, que sus reglas son bastantecomplejas y que de acuerdo a Kan [1, pg 456] y a Garmus y Herron [2, pg xvi] requierensuficiente capacitacin para entenderlas.

Para facilitar la comprensin de esta tcnica en el captulo 1 se presentan las reglas delIFPUG que permiten estimar el tamao de una aplicacin y en el captulo 2 se muestrancasos prcticos de cmo aplicarlas.

El objetivo de este documento es que los estudiantes de pregrado y posgrado de la Escuela

de Computacin e Informtica aprendan a cuantificar con mayor precisin el tamao delsoftware, y consecuentemente a derivar el cronograma y el presupuesto del proyecto adesarrollar. Actualmente la metodologa que se utiliza es poco precisa, por estar basadasolamente en la experiencia de los planificadores en proyectos similares. En cambio, lametodologa de Puntos de Funcin logra estimar con mayor precisin el cronograma y elpresupuesto con solo conocer su funcionalidad y complejidad de la aplicacin. Otroobjetivo de este documento es promover a travs de los estudiantes, a que las empresas oinstituciones pblicas inicien su proceso de elaboracin de mtricas.


4/88

Universidad de Costa Rica. Escuela de Computacin e Informtica.Fecha de creacin: 2005-08. Autora: Profesora Gabriela Salazar.

2

Los Puntos de Funcin son independientes del lenguaje del computador, de la metodologade desarrollo, de la tecnologa o de la capacidad del equipo del proyecto usado paradesarrollar la aplicacin. Adems pueden ser usados para estimar sistemas GUI (en ingls,Graphical User Interfaces), sistemas cliente/servidor o desarrollo orientado a objetos.


5/88


3

Captulo 1

Metodologa de Anlisis de Puntos de Funcin

Los Puntos de Funcin deben representar la funcionalidad que el usuario del negociorequiere, por lo tanto nunca es muy temprano para realizar conteo de Puntos de Funcin.

Tradicionalmente se cree que el conteo no puede ocurrir hasta que el diseo no se hayaterminado. Las reglas y guas del IFPUG hacen posible realizar el conteo de Puntos deFuncin una vez que los requerimientos se hayan finalizado. Sin embargo hay heursticasque permiten estimarlo an ms temprano en el ciclo de vida. Durante la obtencin de losrequerimientos para muchos proyectos se desarrolla el modelo de objetos del dominio, o elmodelo de anlisis los cuales generalmente, no tienen atributos ni est en tercera formanormal. Sin embargo en este punto el analista puede comenzar a identificar las entidadesque necesita procesar para insertar, modificar, borrar y eliminar datos. En este momento sepuede hacer una buena estimacin del tamao asumiendo que todas las transaccionesidentificadas tienen una complejidad media. An en este punto del ciclo de vida se puedenpredecir con certeza el Valor de Factor de Ajuste (explicada en el paso 5 de estedocumento). Una vez que se han completado los requerimientos es posible contaracertadamente los Puntos de Funcin, porque ya las entidades tienen todos los atributos.Todas las interacciones de la aplicacin, incluyendo pantallas y reportes deberan habersido identificadas y los elementos de datos asociados con ellas especificados. No esnecesario que las pantallas y reportes sean formateadas en este momento. Por supuesto,siguiendo con la fase de diseo el conteo se llega a perfeccionar, an considerando enalguna medida cambios en los requerimientos. Se espera que ya entre el fin del diseo y elde las pruebas de aceptacin no debera haber ms cambios en el conteo.

El proceso de medicin se puede resumir en los siguientes siete pasos:1.Determinar el tipo de conteo de puntos de funcin.

2. Identificar el alcance del conteo y las fronteras de la aplicacin.3. Identificar todas las funciones de datos y su complejidad.4. Identificar todas las funciones transaccionales y su complejidad.5.Determinar los puntos de funcin sin ajustar.6.Determinar el valor del Factor de Ajuste basado en las 14 caractersticas generales del

sistema.7.Calcular los puntos de funcin ajustados.

El tiempo de conteo de los puntos de funcin vara dependiendo del estado particular deuna aplicacin. Tpicamente hay menos informacin disponible en las etapas tempranas deldesarrollo, y significativamente hay ms informacin disponible conforme se desarrolla yentrega la aplicacin. Al inicio del proceso la nica informacin disponible podra serverbal. Durante el desarrollo la informacin disponible para ayudar en el conteo seincrementa al incluir algunos de los siguientes documentos potenciales, los cuales ayudan adeterminar el conteo de puntos de funcin:

Propuesta del proyecto. Diagrama del sistema de alto nivel (mostrando relaciones con otras aplicaciones). Diagrama de Entidad-Relacin. Modelo de datos lgico.


6/88


4

Diagrames de flujos de datos. Modelos de objetos. Modelos de procesos. Documento de requerimientos del sistema. Prototipos.

Especificacin funcional. Casos de Uso. Especificacin del Sistema. Especificacin del diseo detallado. Modelos de diseo fsicos. Modelos operacionales. Especificacin de mdulos/programas. Pantallas para sistemas en lnea. Diseo de archivos. Copias de reportes o diseo de reportes.

Manuales de usuario. Bases de datos. Casos de prueba. Manuales de usuario y documentacin tcnica. Materiales de capacitacin. Ayuda del sistema.

A continuacin se explica el detalle de cada uno de los siete pasos de la metodologatomando como base los captulos 6 al 9 de [2].

Paso 1. Determinar el tipo de conteo de puntos de funcin.

Existen tres posibles tipos de conteo que se describen a continuacin:1. Conteo de puntos de funcin para Proyectos en Desarrollo.

Mide la funcionalidad provista a los usuarios finales en la primera instalacin de laaplicacin. Incluye la funcionalidad que se contar de la nueva aplicacin y larequerida por los usuarios, para convertir los datos que residen en los archivos de datosviejos, hacia los nuevos archivos de datos. Conforme avanza el desarrollo delproyecto, a menudo hay que actualizar el conteo. Los siguientes conteos deben validarla funcionalidad identificada previamente y capturar la funcionalidad agregada. Losconteos podran ocurrir durante las siguientes fases, ya sea en un enfoque de cascada oun proceso iterativo. Ver figura 1.

Figura 1. Conteo durante el desarrollo.


7/88


5

2. Conteo de puntos de funcin para proyectos en mantenimiento.Mide las modificaciones a una aplicacin existente e incluye la funcionalidad provistaa los usuarios al agregar nuevas funciones, borrar funciones viejas y cambiar lasfunciones existentes. La funcionalidad por conversin tambin podra existir en unproyecto de mantenimiento. Despus de realizarse el mantenimiento se debe revisar el

conteo para reflejar los cambios apropiados en la funcionalidad de la aplicacin actual.

3. Conteo de puntos de funcin para una aplicacin desarrollada.Mide una el tamao de una aplicacin ya instalada. Es conocido como conteo de lneabase o instalado y provee el total de la funcionalidad provista a los usuarios finales.Tpicamente representa las aplicaciones que actualmente estn siendo utilizadas ymantenidas.

Paso 2. Identificar el alcance del conteo y la frontera de la aplicacin.

El alcance del conteo se determina por el propsito del conteo. Identifica lossistemas, aplicaciones o subconjuntos de una aplicacin que ser medida. Podra incluir lasfunciones que sern satisfechas por la compra de un paquete; todas las aplicaciones quesern contratadas; o podra restringir las funciones dentro de una aplicacin con unpropsito especfico como por ejemplo: los reportes. La frontera de la aplicacin es ellmite entre la aplicacin que est siendo medida y las aplicaciones externas al dominio delusuario.

IFPUG ha definido las siguientes reglas para identificar las fronteras: Las fronteras se basan en el punto de vista del usuario. El usuario debe ser capaz de

definir el alcance de la aplicacin y la funcionalidad del negocio en el lenguaje delusuario.

Las fronteras entre aplicaciones relacionadas se basan en la funcionalidadindividual del negocio y no en consideraciones tcnicas. Por ejemplo: MicrosoftOffice actualmente consiste de Word, Excel, Power Point y Access, cada una es unaaplicacin individual dentro de Microsoft Office. Otro ejemplo es System Alpha queconsiste de un proceso de entrada de datos en lnea, seguido por un proceso deactualizacin en lote; sta es una aplicacin simple que incluye ambos procesos en lneay en lote.

Las fronteras establecidas para una aplicacin no influyen en el alcance del conteo.La frontera de una aplicacin que est en mantenimiento permanece como estaba,excepto por supuesto si se le agrega funcionalidad que pueda expandir la frontera yborrar funcionalidad que pueda reducir la frontera. Una mejora no define su propia

frontera de aplicacin, pero esta es definida por el alcance del conteo. Los proyectos endesarrollo y mantenimiento a menudo incluyen ms de una aplicacin simple. En estoscasos, las fronteras de la aplicacin son identificadas dentro del alcance del conteo, perose cuentan en forma separada. En la figura 2 se presenta en forma grfica el conteo depuntos de funcin.


8/88


6

Figura 2. Funcionalidad reconocida en el conteo de puntos de funcin.

Existe mucha confusin en los usuarios respecto a la definicin de las fronteras. Es

extremadamente importante que el conteo se realice consistentemente y en forma correcta.El conteo tiene poco beneficio si es consistente pero incorrecto, especialmente cuando lasfronteras de la aplicacin se estn identificando. Las fronteras no deben ser establecidas anivel de programas o de mdulos, sino al nivel ms alto de la aplicacin.

Paso 3. Identificar todas las funciones de datos y su complejidad ydeterminar los puntos de funcin desajustados.

Existen dos tipos de funciones de datos que se deben identificar los cuales son: los Archivos Lgicos Internos (ILF, en ingls Internal Logical Files) y

los Archivos de Interfases Externas (EIF, en ingls External Interface Files).

1. Definicin de los Archivos Lgicos Internos (ILF, en ingls Internal Logical Files)

Un ILF es un grupo identificable por el usuario, de datos relacionadoslgicamente o informacin de control administrada dentro de las fronteras dela aplicacin. El propsito principal de un ILF es mantener los datosadministrados a travs de uno o ms procesos elementales, de la aplicacin quese est contando.

A continuacin se describe cada trmino.

Identificables por el usuario se refiere a requerimientos definidos para procesos y o gruposde datos que son acordados y entendidos por el usuario y el desarrollador. Por ejemplo: unregistro de cuentas de cheques que podra requerirse en una aplicacin financiera.

Los datos se refieren a un conjunto de hechos administrados dentro de la aplicacin. Porejemplo: nmero de cheque, cantidad, fecha, pago, etc. que se pueden administrar en unregistro de cuentas de cheques.

Relacionados lgicamente se refiere al requerimiento que cada grupo de datos unidoslgicamente debe satisfacer de acuerdo a las descripciones provistas. Un ILF no debe


9/88


7

depender ni ser atributo de otro ILF para mantener su existencia. Los grupos deben sermezclados tanto como sea necesario, particularmente aquellos creados por razones derendimiento o de implementacin. Tpicamente los ILF deben presentarse en segunda otercera forma normal. Un ejemplo puede ser una tabla de direcciones que probablementepertenece a un nivel superior, tal como un archivo de clientes, un archivo de pagos, un

archivo de ubicacin de inventario o un archivo de empleados.Informacin de control es un dato usado por la aplicacin para influir en un procesoelemental de la aplicacin que se est contando. ste especifica qu, cundo y cmo losdatos van a ser procesados. En el caso de los ILF estos datos, reglas o parmetros sealmacenan y actualizan dentro de la aplicacin. Algunos ejemplos son: un dato de controlpara administrar la impresin, la fecha y la hora administrada por el usuario para establecerel tiempo de ciertos eventos.

Administrados se refiere a la capacidad de modificar datos a travs de un procesoelemental. Los datos o la informacin de control pueden ser administrados a travs detransacciones como: agregar, cambiar, borrar, enviar, transferir, evaluar, mantener,

revisar, actualizar, etc.. Un ILF se puede administrar y contar como un ILF dentro de msde una aplicacin; sin embargo se cuenta solo una vez para cada aplicacin donde ste esadministrado.

Un proceso elemental es la unidad de actividad ms pequea que tiene significado para elusuario. Ejemplo: Un problema de stock en un almacn podra descomponerse en variossubprocesos tales como: Crear, Leer, Actualizar y Desplegar de manera que el problemacrea una cantidad dada, lee un archivo para validar si es por crdito y actualiza la cantidaddel stock disponible. El problema del stock es un proceso elemental, no es un subprocesosubordinado y puede actualizar ms de un ILF a travs de la misma transaccin.

1.1 Reglas para contar los ILFIFPUG ha definido las siguientes reglas para que datos o informacin de control seancontados como un ILF: El grupo de datos o informacin de control debe estar relacionado lgicamente y debe

ser reconocible por el usuario. El grupo de datos debe ser administrado a travs de un proceso elemental dentro de las

fronteras de la aplicacin que est siendo contada.

Una vez que se ha identificado un ILF dentro de una aplicacin, este no puede ser contadocomo un EIF para la misma aplicacin, an si ste es usado por referencia por otras

transacciones, ni puede ser contado como EIF durante un proyecto de mantenimiento paraesa aplicacin.

Algunos ejemplos adicionales de ILF son:- Datos transaccionales tales como: registros de inventarios, registros de capacitacin de

empleados, registro de planilla, transacciones de tarjetas de crdito, ventas de productos.- Datos de seguridad o password administrados dentro de la aplicacin.- Datos de ayuda administrados dentro de la aplicacin.- Datos de edicin administrados dentro de la aplicacin.


10/88


8

- Datos de parmetros administrados dentro de la aplicacin.- Archivos de error y su descripcin administrados dentro de la aplicacin.

Algunos ILF errneos que no deben ser contados son: Archivos temporales o iteraciones del mismo archivo. Archivos de trabajo. Archivos de ordenamiento. Archivos de vistas que contienen datos extrados de otros ILF o EIF antes de

desplegarlos o imprimirlos, como parte del procesamiento necesario para producir unasalida externa (EO, en ingls External Output) o una consulta externa (EQ, en inglsExternal Inquiry).

Copias del mismo archivo ordenados en forma diferente o mantenidos en localizacionesadicionales.

Archivos introducidos por problemas de tecnologa. Archivos de ndices, uniones, relaciones o conexiones, a menos que ellos contengan

atributos no claves administrados independientemente.

Datos de auditora o histricos, estos deben ser contados junto con los datostransaccionales de la aplicacin. Archivos mantenidos por otras aplicaciones y ledos o referenciados solamente, estos

deben contarse como EIF. Datos de respaldo usados como backup y recuperacin de la empresa, esta capacidad se

reconoce dentro de las 14 caractersticas solamente.

2. Definicin de los Archivos Interfases Externas (EIF, en ingls External InterfaceFiles)

Un EIF es un grupo identificable por el usuario, de datos relacionadoslgicamente o informacin de control referenciados por la aplicacin que se

est contando, pero administrados dentro de las fronteras de una aplicacindiferente. El propsito principal de un EIF es mantener datos referenciados atravs de uno o ms procesos elementales dentro de la frontera de la aplicacinque se est contando. Un EIF contado para una aplicacin debe ser contadocomo ILF en otra aplicacin

A continuacin se describe cada trmino de esta definicin. Las definiciones son muysimilares a los de los ILF descritos en la seccin anterior.

Identificables por el usuario se refiere a requerimientos definidos para procesos y gruposde datos que son acordados y entendidos por el usuario y el desarrollador. Por ejemplo: unregistro de cuentas de cheques que podra ser usado para la validacin en una aplicacin, el

cual lee los datos solamente mientras valida una transaccin no relacionada.Los datos se refieren a un conjunto de hechos administrados por otra aplicacin. Porejemplo: nmero de cheque, cantidad, fecha, pago, etc. que se pueden administrar en unregistro de cuentas de cheques.

Relacionados lgicamente se refiere al requerimiento que cada grupo de datos unidoslgicamente debe satisfacer de acuerdo a las descripciones provistas. Un EIF no debedepender ni ser atributo de otro EIF para mantener su existencia. Los grupos deben ser


11/88


9

mezclados tanto como sea necesario, particularmente aquellos creados por razones derendimiento o de implementacin. Tpicamente los EIF deben presentarse en segunda otercera forma normal. Un ejemplo puede ser una tabla de direcciones que probablementepertenece a un nivel superior, tal como un archivo de clientes, un archivo de pagos, unarchivo de ubicacin de inventario o un archivo de empleados.

Informacin de control es un dato usado por la aplicacin para influir en un procesoelemental de la aplicacin que se est contando. ste especifica qu, cundo y cmo losdatos van a ser procesados. En el caso de los EIF estos datos, reglas o parmetros sealmacenan y se actualizan dentro de la aplicacin. Algunos ejemplos son: un dato decontrol para administrar la impresin, la fecha y la hora administrada por el usuario paraestablecer el tiempo de ciertos eventos.

Administrados se refiere a la capacidad de modificar datos a travs de un proceso elementalde otra aplicacin.

Un proceso elemental es la unidad de actividad ms pequea y significativa para el usuario.Por ejemplo: una pantalla de stock en un almacn podra descomponerse en varios

subprocesos, de manera que un archivo pueda ser ledo para determinar la cantidad de stocky otro archivo independiente pueda ser ledo para determinar la descripcin de los tems. Elproceso elemental puede leer ms de un EIF a travs de la misma transaccin.

2.1 Reglas para contar los EIF.

IFPUG ha definido las siguientes reglas para que datos o informacin de control seancontados como un EIF: El grupo de datos o informacin de control est relacionado lgicamente y es

identificable por el usuario. El grupo de datos es referenciado por una aplicacin externa a la que se est contando. El grupo de datos no es administrado por la aplicacin que se est contando. El grupo de datos es administrado en un ILF de otra aplicacin.

Una vez que un grupo de datos se ha identificado como EIF dentro de una aplicacin, elEIF no puede ser contado de nuevo dentro de la misma aplicacin, an si ste es usado porreferencia por otras transacciones, o contiene diferentes datos del mismo archivo.

Algunos ejemplos comunes de EIF son:- Datos de la aplicacin extrados o ledos de otra aplicacin.- Datos de seguridad o password administrados fuera de la aplicacin.- Datos de ayuda administrados fuera de la aplicacin.

- Datos de edicin administrados fuera de la aplicacin.- Datos de parmetros administrados fuera de la aplicacin.- Archivos de error y su descripcin administrados fuera de la aplicacin.

Algunos EIF errneos son: Un dato recibido de otra aplicacin que administran uno o ms ILFs dentro de la

aplicacin que se est contando. Esto es considerado como un dato transaccional y sedeben contar como EI.


12/88


10

Un dato que es administrado por la aplicacin que est siendo contada pero accesado yusado por otra aplicacin diferente. Es contado como EIF por la aplicacin que loaccesa.

Un dato formateado y enviado por la aplicacin que se est contando a otra aplicacin.Debera ser contado como una consulta externa (EQ, en ingls external inquiry) o una

salida externa (EO, en ingls external output). Archivos temporales o iteraciones del mismo archivo. Estos no se cuentan en el FPA. Archivos de trabajo no se cuentan en el FPA. Archivos de ordenamiento no se cuentan en el FPA. Archivos de extracciones o vistas que contienen datos extrados de EIF previamente

contados, antes de desplegarlos o imprimirlos. No se cuentan en el FPA pero sonreconocidos como parte del procesamiento necesario para producir las salidas oconsultas externas.

Archivos introducidos por la tecnologa no se cuentan en el FPA. Archivos de ndices, uniones, relaciones o conexiones, a menos que ellos contengan

mantenidos independientemente, atributos no claves. Datos de auditora o histricos, estos deben ser contados junto con los datos

transaccionales de la aplicacin.

3. Reglas para determinar la complejidad y contribucin de los ILF y de los EIF

El conteo fsico de ILFs y EIFs junto con la complejidad funcionalrelativa de cada uno, determina la contribucin de los tipos funcionales dedatos para el conteo de los puntos de funcin desajustados. A cada ILF yEIF se le debe asignar una complejidad funcional basada en el nmero detipos de elementos de datos (DET) y en los tipos de elementos de registros(RET) asociados con el ILF o el EIF.

Cada trmino usado en la definicin se define a continuacin:Complejidad funcional es el peso asignado a cada funcin de dato individual. Posiblesvalores como bajo, medio y alto son asignados usando una matriz de complejidad la cualconsidera el nmero de DET y RET.

Tipos de Elementos de Datos (DET) son campos/atributos nicos, reconocibles por elusuario, no repetitivos y pueden incluir claves forneas.

Tipos de Elementos de Registros (RET) son subgrupos de elementos de datos reconociblespor el usuario (opcionales u obligatorios) que se encuentran dentro de un ILF o un EIF.Los RET son tpicamente representados dentro de un diagrama de entidad relacin como

los subtipos de entidad o entidades de atributo, comnmente llamados relaciones padre-hijo. Opcionales: el usuario tiene la opcin de usar uno o ningn subgrupo opcional durantela ejecucin de un proceso elemental que agrega o crea una instancia de datos. Obligatorio:el usuario debe usar al menos uno de los subgrupos obligatorios.

IFPUG ha definido las siguientes reglas para el conteo de elementos de datos, camposo atributos (conocidos como DET por IFPUG) para los ILF y los EIF:


13/88


11

Contar un DET por cada campo reconocible, no repetido, administrado o recuperadodesde un ILF o EIF a travs de un proceso elemental. Por ejemplo: Un nmero decheque, una cantidad, una fecha, un nmero de cuenta, almacenados en un registro decuenta de cheques puede ser contado cada uno como un DET, sin tomar en cuenta elnmero de cheques escritos con datos exclusivos de cada uno y sin tomar en cuenta

cmo se va a almacenar el dato fsicamente. Cuando dos o ms aplicaciones mantienen y/o referencian el mismo ILF o EIF pero con

DET independientes, contar solamente los DET que estn siendo usados por cadaaplicacin. Por ejemplo un ILF que es actualizado por dos aplicaciones (A y B) y esreferenciado por una tercera (C), podra contar los DET en forma exclusiva, tal como semuestra en la tabla 1. Consecuentemente A puede ser contado con 8 DET, B con 7 y Ccon 2.

Contar un DET por cada pieza de dato requerido por el usuario para establecer unarelacin con otro ILF o EIF. Este tipo de DET se conoce como llave fornea. Porejemplo: una relacin que existe con otro ILF o EIF requiere una clave con el nmero de

parte y el cdigo del fabricante. El nmero de parte y el cdigo del fabricante puedenser contados como dos DET a menos, por supuesto, que cualquiera o ambos se hayancontado previamente.

Los campos que aparecen ms de una vez en un ILF o un EIF por causa de latecnologa o tcnicas de implementacin, tales como las llaves ya mencionadas, soncontadas solamente una vez en el ILF o EIF. Sin embargo un campo puede ser un DET paramuchos ILF o EIF.

Los campos repetitivos que son idnticos en formato y existen para permitirocurrencias mltiples de valores de datos son contados solo una vez en el ILF o EIF. Porejemplo: un ILF que contiene campos con 12 cantidades mensuales y un campo con un

total anual puede ser contado como 2 DET uno por cada cantidad mensual repetitiva yuno para identificar el total; un DET adicional debe haber indudablemente para identificarel mes.

Tabla 1. Ejemplo de conteo.

DET Uso del DET Conteo del DET

Nmero de parte Clave primaria de A, B y C DET para A, B y C.

Nombre de parte Mantenido por A.

Referenciado por B y C.

DET para A

DET para B y C

Uso semanal Mantenido por B. DET para B

Uso por departamento Mantenido por B. DET para BPrecio de compra Mantenido por A.

Referenciado por B.

DET para A

DET para B

Nombre proveedor Mantenido por A.

Referenciado por B.

DET para A

DET para B

Direccin Calle proveedor Mantenido por A. DET para A


14/88


12

Ciudad proveedor Mantenido por A. DET para A

Estado proveedor Mantenido por A. DET para A

Cdigo postal proveedor Mantenido por A. DET para A

Direccin total proveedor, ledo

como un bloque de datos

Referenciado por B. DET para B

Los datos de auditora, los cuales incluyen imgenes antes y despus de 15 camposdistintos, se cuentan como 2 DET uno para la imagen del antes y uno para la imagen deldespus.

Los clculos que ocurren internamente durante el procesamiento de una entradaexterna (EI) y almacenado en la base de datos se cuenta como un DET del ILF.

IFPUG recomienda las siguientes reglas para contar RETs dentro de un ILF o EIF: Se cuenta un RET por cada subgrupo opcional u obligatorio en un ILF o un

EIF. No se cuentan los RET que existen por causa de la tecnologa o por la

metodologa utilizada (estos es encabezados, archivos de texto independientes,etc.) Dos o ms archivos a menudo pertenecen al mismo archivo lgico (ILF oEIF). Estos RET pueden tambin ser identificados por la existencia de llavessecundarias usadas para el almacenamiento de datos y la creacin de relacionesentre los archivos lgicos. Los datos en un archivo lgico tpicamente estn entercera forma normal.

Si no hay subgrupos contar el ILF o el EIF como un RET.

4. Determinar los puntos de funcin sin ajustar (PFSA) para los ILF y los EIF.Para determinar los puntos de funcin sin ajustar de los ILF y de los EIF se deben seguir lassiguientes instrucciones:

1. Identificar con base en el alcance de la aplicacin y en las secciones 3.1 y 3.2 losILF, los EIF y sus atributos.

2. Aplicar las reglas descritas en las secciones 3.1.1 y 3.2.1 para determinar el nmerode ILF y de EIF y obtener una lista clasificada por ILF y EIF.

3. Aplicar las reglas de la seccin 3.3 y obtener los DET y los RET para cada ILF yEIF de la lista anterior.

4. Con base en la lista con ILF, EIF, con sus DET y RET y la Matriz de complejidadpara los ILF y EIF (refirase a l atabla 2), determinar la complejidad de cada ILF yEIF. Por ejemplo: un ILF con 3 RET y 51 DET tiene una complejidad Alta. Un EIFcon 2 RET y 22 DET tiene una complejidad Media.


15/88


13

Tabla 2. Matriz de complejidad para los ILF y EIF.

Nmero deRegistros (RET)

Nmero de Elementos de Datos (DET)

1-19 20-50 51

1 Baja Baja Media

2-5 Baja Media Alta

>5 Media Alta Alta

5. Una vez determinada la complejidad de cada ILF y EIF se le debe asignar un peso.Con base en la tabla 3 se ubica la fila de los ILF y EIF y la columna correspondientea la complejidad (baja, media o alta) obtenida en el punto anterior, y se multiplica elnmero de ILF/EIF por el peso que le corresponde. Siguiendo el ejemplo: con elILF de complejidad Alta y el EIF de complejidad Media obtenidos en el puntoanterior, podemos contabilizar 15 puntos de funcin desajustados para el ILF y 7puntos de funcin desajustados para el EIF obteniendo un total de 22 puntos defuncin sin ajustar.

Tabla 3. Conteo de los ILF y EIF.

Componentes Baja Media Alta

Archivos Lgicos Internos (ILF) x7 x10 1 x15

Archivos de Interfase Externa (EIF) x5 1 x7 x10

Entradas Externas (EI) x3 x4 x6

Salidas Externas (EO) x4 x5 x7

Consultas Externas (EQ) x3 x4 x6

7 15

Total 22 puntos de funcin sin ajustar (PFSA)

Paso 4. Identificar todas las funciones transaccionales y su complejidad ydeterminar los puntos de funcin desajustados.

Existen tres tipos de funciones transaccionales que se deben identificar las cuales son:

Entradas Externas (EI, en ingls External Inputs) tales como agregar, cambiary borrar datos de un archivo Consultas Externas (EQ, en ingls External Inquiries) tales como recuperar

datos de un archivo Salidas Externas (EO, en ingls External Outputs) tales como la generacin dereportes.


16/88


14

A continuacin se explica el detalle de cada una de estas funciones transaccionales.1. Definicin de las Entradas Externas (EI, en ingls External Inputs)

Una entrada externa (EI) es un proceso elemental de la aplicacin queprocesa datos o informacin de control, que ingresa desde afuera de lafrontera de la aplicacin. Los datos procesados administran uno o ms

ILFs. La informacin de control procesada puede o no administrar unILF. La intencin principal de un EI es administrar uno o ms ILF y/oalterar la conducta de la aplicacin a travs de su lgica de procesamiento.

A continuacin se describen los siguientes trminos:

Un proceso elemental es la unidad de actividad ms pequea que tiene significado para elusuario final. El proceso debe estar autocontenido, es decir no debe su existencia a algnotro proceso, dejndolo en un estado consistente una vez que finaliza. Por ejemplo: unatransaccin de entrada al sistema para ingresar los beneficios de un empleado, puedeconsistir de tres pantallas, sin embargo la entrada se considera incompleta hasta que las trespantallas se completen, debido a que el proceso elemental requiere la completitud de las

tres pantallas. Si toda la informacin, reconociendo que algunos campos no sonobligatorios se ha ingresado, la transaccin podra estar concluida y el negocio puedequedar en un estado consistente.

Los datos se refieren a un conjunto de hechos procesados por la transaccin de entrada. Porejemplo: los datos pueden ser los campos de datos incluidos en la transaccin de beneficiode un empleado descrita arriba. Podra ser el nombre del empleado, seleccin del beneficio,acuerdo para participar(S/N), porcentaje de contribucin, entre otros.

La informacin de control es un dato que influye en un proceso elemental de la aplicacinque est siendo contada; En el caso de los EI, estos datos, reglas o parmetros o parmetrospueden ser almacenados o usados independientemente para administrar/iniciar un proceso

sin necesidad de que sea almacenado despus de que el proceso est completo. Por ejemploun dato de control es usado para administrar la configuracin del sistema. La informacinde control es usada por la aplicacin para asegurar el cumplimiento de los requerimientosdel negocio especificados por el usuario. Esto puede incluir caractersticas tales como:comparar o calcular. En sistemas de tiempo real puede incluir una seal de entrada desdeuna alarma, un instrumento, un sensor, u otra aplicacin.

Administrar se refiere a la capacidad de modificar datos a travs de un proceso elementalde otra aplicacin. Contar un EI por cada actividad de mantenimiento, por ejemplo:agregar, cambiar, borrar, revisar, actualizar, asignar, guardar y crear. No hay lmite en elnmero de verbos que se pueden seleccionar para mantener datos.

La lgica de procesamiento incluye especficamente los requerimientos solicitados por unusuario para completar un proceso elemental. Usualmente se requiere una lgica deprocesamiento para completar un proceso elemental. Una lgica de procesamiento no sedebe usar para determinar EI, EO o EQ exclusivos. Un proceso elemental de un EI puedeincluir mltiples validaciones, filtros, ordenamientos, etc. El ordenamiento por ejemplo nodetermina la exclusividad de la transaccin, es decir, la capacidad de ordenar no es unatransaccin adicional.

Una lgica de procesamiento para un EI puede incluir:


17/88


15

- Validaciones.- Frmulas o clculos matemticos.- Conversiones de valores equivalentes.- Filtros y seleccin de datos usando criterios especficos para comparar mltiples

grupos de datos.

- Anlisis de condiciones para determinar cul es aplicable.- Actualizacin de ILF (es obligatorio para un EI administrar uno o ms ILF oalterar la conducta del sistema).

- Referencias a ILF o EIF.- Recuperacin de datos o informacin de control.- Creacin de datos derivados.- Alteracin de la conducta del sistema (es obligatorio para un EI administrar uno o

ms ILF o alterar la conducta del sistema).- Preparacin y presentacin de informacin fuera de la frontera.- Capacidad de aceptar datos o informacin de control que ingrese a la aplicacin

(obligatorio para un EI).

- Ordenamiento o clasificacin de un conjunto de datos.

1.1 Reglas para contar los EI.

Las siguientes reglas se deben aplicar a los datos que estn siendo contados como entradasexternas (EI):

El dato debe ser recibido desde fuera de la frontera de la aplicacin.

El dato debe ser administrado en al menos un ILF a travs de un procesoelemental de la aplicacin.

El proceso debe ser la actividad ms pequea con significado para el usuario.

El proceso debe dejar el negocio de la aplicacin que est siendo contada en unestado consistente.

Para el proceso identificado se debe aplicar una de las tres siguientes reglas:

1. La lgica de procesamiento debe ser nica/diferente dentro de la aplicacin (nodeben haber dos lgicas de procesamiento iguales).

2. El conjunto de datos identificados debe ser diferente del identificado en otrasEI en la aplicacin (no deben haber dos flujos iguales).

3. Lo ILF y EIF referenciados deben ser diferentes de los referenciados por otrasEI en la aplicacin.

Para la informacin de control que se est contando como EI, IFPUG recomienda lassiguientes reglas:

La informacin de control debe ser recibida desde fuera de la frontera de laaplicacin.

La informacin de control debe ser especificada por el usuario para asegurar elcumplimiento de los requerimientos.


18/88


16

El proceso debe ser la actividad ms pequea con significado para el usuario.

El proceso debe dejar el negocio de la aplicacin que est siendo contada en unestado consistente.

Para procesos identificados se debe aplicar una de las siguientes reglas:

1. La lgica de procesamiento debe ser nica o diferente de otras lgicas deprocesamiento realizadas por EI en la aplicacin.

2. El conjunto de datos identificado es diferente a los conjuntos identificados porotras EI en la aplicacin (no deben haber dos flujos iguales).

3. Los ILF o EIF referenciados deben ser diferentes de aquellos referenciados porotras EI en la aplicacin.

Algunos ejemplos de Entradas Externas (EI) adicionales son:

Los datos transaccionales que se usan para administrar un ILF tales como: una venta,un recibo, una transferencia, una frmula de seguro, etc.

Las entradas que proveen informacin de control tal como: un reporte de losmovimientos de la tierra.

Los mensajes de otras aplicaciones que requieren procesamiento.

Los archivos transaccionales de otras aplicaciones, que pueden incluir transaccionesmltiples de diferente tipo, que requieren procesamiento separado y nico, por ejemplo:transacciones de tarjetas de ventas al contado o de crdito en cuyo caso podran sermltiples EIs.

Las entradas que mantienen un ILF.

Las funciones de usuario que inician un control o ingresan datos.

Los archivo de datos administrados en una aplicacin anterior que deben ser procesadosa travs de un esfuerzo de conversin dentro de un ILF nuevamente desarrollado,cuando el dato est migrando como parte de un proyecto en desarrollo o enmantenimiento. Esto puede ser incluido dentro del conteo del proyecto pero no dentrodel conteo de la aplicacin.

Los datos fsicos que inician el procesamiento, tal como una temperatura.

El mantenimiento de cualquier ILF incluyendo ayuda, cualquier archivo de mensajes,parmetros, etc..

Los siguientes son ejemplos de EI mal identificados:

Un dato referenciado que es ledo por la aplicacin desde datos almacenados en otra

aplicacin, pero que no se usa para administrar ningn ILF en la aplicacin que estsiendo contada; esto es tpicamente reconocido como EIF.

La parte de solicitud de entrada ya sea de una consulta o de una salida.

Las pantallas de men usada para navegacin o seleccin de opciones y que noadministra ningn ILF.

Las pantallas de ingreso que facilitan al usuario la entrada a la aplicacin.


19/88


17

Mtodos mltiples para invocar una misma lgica; por ejemplo, teclas de accin querealizan la misma funcin o la misma transaccin en diferentes pantallas deben sercontadas solo una sola vez.

Posicionamiento del cursor sobre una pantalla para llenar o mover campos.

Los datos para refrescar o cancelar una pantalla.

Respuesta a mensajes que requieren una confirmacin del usuario, como por ejemploborrar u otra transaccin.

Los datos enviados en lnea/lote dentro de la misma aplicacin, que no cruzan lafrontera de la aplicacin.

Los datos enviados entre el cliente/servidor dentro de la misma aplicacin, que nocruzan la frontera de la aplicacin.

1.2 Reglas para determinar la complejidad y contribucin de los EI

El conteo de los EI junto con la complejidad funcionalrelativa de cada uno,determina la contribucin de las entradas externas para el conteo de lospuntos de funcin desajustados. A cada EI identificado se le debe asignaruna complejidad funcional basada en el nmero de tipo de elementos dedatos (DET) y los tipos de archivos referenciados (FTRs) asociados con elEI.

A continuacin se describe cada trmino de la definicin:

Complejidad funcional: es el porcentaje asignado a cada funcin transaccional. Seasignan de acuerdo a la matriz de complejidad que considera el nmero de DET yFTR.

Tipo de elemento de dato (DET): usualmente son campos o atributos nicos,reconocibles por el usuario, no repetitivos, incluyendo atributos de claves forneas,que cruzan la frontera de la aplicacin.

Tipo de archivo referenciado (FTR): se refiere al nmero total de ILF administradoso ledos y de EIF ledos por la transaccin EI.

IFPUG recomienda las siguientes reglas para contar los elementos de datos, campos oatributos (conocido como DET por IFPUG) para un EI: Se cuenta un DET para cada campo/atributo nico, reconocible por el usuario,

incluyendo atributos de clave fornea que cruzan (ya sea porque ingresan o existen)la frontera de la aplicacin para completar un proceso elemental del EI. Tpicamentetales campos o atributos se mantienen en un ILF. Por ejemplo: nombre del empleado,monto de pago, nmero de tem, cantidad vendida.

No se cuenta como un DET cada campo que no lo ingresa el usuario (no cruza lafrontera de la aplicacin) pero a travs de un EI es derivado por la aplicacin yadministrado en un ILF. Algunos ejemplos son: una fecha generada por el sistema,un valor recuperado, un nmero de cuenta y un valor calculado.


20/88


18

Se cuenta como un DET cada campo lgico almacenado fsicamente comomltiples campos, pero requerido por el usuario como una simple pieza deinformacin. Por ejemplo: lneas de una direccin.

Contar un simple DET para cubrir todos los mensajes del sistema que indican queun error ha ocurrido durante el procesamiento, que confirman que el

procesamiento ha terminado, o que verifican que debe continuar. Aunque hayanmltiples posibilidades de mensajes contar solo un DET para todos los procesoselementales. Es decir contar solo un DET para todos los mensajes, aunque hayanmensajes de errores mltiples, de verificacin y de confirmacin.

Contar como un simple DET la capacidad de especificar una accin a tomar, ansi hay mltiples mtodos para invocar la misma lgica de procesamiento. Contar unDET por lnea de comando o tecla de funcin/accin (PF) que provea la capacidad deespecificar la accin a tomar por el EI. Contar esto como un DET por EI. No contar unDET por cada lnea de comando y tecla de funcin/accin (PF).

IFPUG recomienda las siguientes reglas que se aplican para contar tipos de archivosreferenciados (FTR): Contar un FTR para cada ILF administrado por un proceso elemental del EI. Contar un FTR para cada ILF o EIF ledo durante el procesamiento del EI. Contar solamente un FTR para cada ILF que es administrado y ledo por el EI.

1.3 Determinar los puntos de funcin sin ajustar (PFSA) para los EI.Para determinar los puntos de funcin sin ajustar de los EI se deben seguir las siguientesinstrucciones:

1. Aplicar las reglas descritas en la seccin 4.1.1 para listar los EI de la aplicacin.

2. Aplicar las reglas de la seccin 4.1.2 y obtener los DET y los FTR para cada EIidentificado en el punto anterior.

3. Con base en la lista de EI con sus DET y FTR y la Matriz de complejidad para losEI (refirase a tabla 4) determinar la complejidad de cada EI. Por ejemplo:supongamos que la aplicacin requiere una pantalla que requiere relacionar dostablas por lo tanto tiene 2 FTR. Adems tiene 10 DET con campos de ambas tablasy 2 DET porque va a tener al menos un mensaje de error y una tecla de comando.Con un total de 2 FTR y 12 DET y utilizando la tabla Matriz de complejidad paralos EI esa pantalla tendr una complejidad Media. Otra pantalla podra requerir larelacin de 3 tablas por lo que tienen 3 FTR. Est compuesta de 17 DET incluyendo2 DET de mensaje de error y de tecla de comando. Esta segunda pantalla tendr una

complejidad de Alta.

Tabla 4. Matriz de complejidad para los EI.

Nmero de Elementos de Datos (DET)Nmero deArchivos

Referenciados(FTR)

1-4 5-15 16


21/88


19

2 Media Alta Alta

4. Una vez determinada la complejidad de cada EI se le debe asignar un peso. Conbase en la tabla 5 se ubica la fila de los EI y columna correspondiente a lacomplejidad (alta, media o baja) obtenida en el punto anterior y se multiplica elnmero de EI por el peso que le corresponde. Siguiendo el ejemplo: tenamos 1 EIcon complejidad Media y 1 EI con complejidad Alta, obtenidos en el puntoanterior. Podemos contabilizar 10 puntos de funcin desajustados para los EI.

Tabla 5. Tabla de conteo para los EI.


Archivos Lgicos Internos (ILF) x7 x10 x15

Archivos de Interfase Externa (EIF) x5 x7 x10Entradas Externas (EI) x3 1x4 1x6


Consultas Externas (EQ) x3 x4 x6

4 6

Total 10 puntos de funcin sin ajustar (PFSA)

2. Definicin de las Salidas Externas (EO, en ingls External Output)

Una salida externa (EO) es un proceso elemental de la aplicacin queenva datos o informacin de control fuera de las fronteras de laaplicacin. El objetivo principal de una EO es presentar informacin alusuario final a travs del procesamiento de dicha informacin, adems derecuperar los datos o informacin de control. La lgica de procesamientodebe contener al menos una frmula matemtica o un clculo, o crea datosderivados, o mantiene uno o ms ILF y/o altera la conducta del sistema.


Un proceso elemental es la unidad de actividad ms pequea que tiene significado para elusuario. El proceso debe estar autocontenido, es decir no debe su existencia a algn otro

proceso, y debe dejar el negocio en un estado consistente una vez que finaliza. Por ejemplo:un reporte puede consistir de muchas pginas pero si las pginas no son requeridas yproducidas independientemente, el reporte solo cuenta un EO. Producir alguno de loscampos, an una pgina, podra no ser autocontenido ni dejar el negocio en un estadoconsistente. Si toda la informacin, reconociendo que algunos campos no se llenan ypueden ser nulos o blancos, fueron completados, esta transaccin est completa y elnegocio podra quedara en un estado consistente.


22/88


20

Los datos se refieren a un conjunto de hechos y/o figuras procesados por una transaccinde salida. Por ejemplo: los datos podran ser campos de datos incluidos en el reportedescrito anteriormente. Podramos esperar ver campos como: el nombre del departamento,el nmero del departamento, la direccin, el mes, el total de ventas mensuales, el total decompras y el total por ao.

La informacin de control es un dato usado por la aplicacin para influir en un procesoelemental de la aplicacin que est siendo contada; en el caso de los EO, estos datos, reglaso parmetros pueden ser enviados por la aplicacin a un usuario u otra aplicacin. Porejemplo informacin de control puede ser enviada por la aplicacin para asegurar elcumplimiento de los requerimientos especificados por el usuario. Esto podra incluir unaviso al usuario que advierta ciertos controles internos que se han puesto, tal como unaalarma.

La lgica de procesamiento incluye especficamente los requerimientos solicitados por unusuario para completar un proceso elemental. Usualmente se requiere una combinacin delgica de procesamiento para completar un proceso elemental. Una lgica de

procesamiento por s misma, no se debe usar para determinar la exclusividad de un EI, EOo EQ. Un proceso elemental de un EO puede incluir mltiples validaciones, filtros,ordenamientos, etc. Clasificar, ordenar o formatear un conjunto de datos no se considerauna lgica de procesamiento exclusiva, sin embargo podra haber otras lgicas deprocesamiento exclusivas durante cualquiera de esas operaciones. Como ejemplo unreporte puede ordenar totales por mes, producto y departamento. Si los campos del reportefueran los mismos (pero desplegados en formato diferente), los totales fueran por columnay el clculo no fuera exclusivo, podramos contar un EO. Mltiples EO podran sercontados si los totales fueran sumados en forma diferente y los clculos fueran nicos paracada ordenamiento. Quizs los totales internos podran representar un total del producto pormes dentro de un departamento, un total mensual de un departamento por divisin y las

ventas diarias del mes.Lgicas de procesamiento para un EO podran ser:- Validaciones.- Frmulas o clculos matemticos.- Conversiones de valores equivalentes.- Filtros y seleccin de datos usando criterios especficos para comparar mltiples

grupos de datos.- Anlisis de condiciones para determinar cul es aplicable.- Actualizacin de ILF.- Referencias a ILF o EIF.- Recuperacin de datos o informacin de control.

- Creacin de datos derivados.- Alteracin de la conducta del sistema.- Preparacin y presentacin de informacin fuera de la frontera (obligatorio para

un EO).- Capacidad de aceptar datos o informacin de control que ingrese a la aplicacin.- Ordenamiento o clasificacin de un conjunto de datos.


23/88


21

Los datos derivados requieren procesamiento, en lugar de recuperacin directa, conversiny edicin de la informacin, de uno o ms ILF o EIF. El dato derivado es creado por latransformacin de datos existentes, para crear un dato adicional. Frecuentemente los EOcontienen datos derivados.

Administrar se refiere a la habilidad de modificar datos a travs de un proceso elemental.

Por ejemplo, automticamente se podra ingresar un nmero de cheque en un ILF, duranteel proceso de generar los cheques de una planilla.

2.1. Reglas para contar los EO.

Para los datos o informacin de control que est siendo contada como EO, todas lassiguientes reglas del IFPUG se deben aplicar:

Los datos o informacin de control deben salir de la frontera de la aplicacin.

La lgica de procesamiento del proceso elemental de un EO debe realizar uno delos siguientes:

1. Contener al menos una frmula matemtica.2. Crear datos derivados.

3. Mantener al menos un ILF.

4. Alterar la conducta de la aplicacin.

El proceso debe ser la unidad ms pequea de actividad reconocible para elusuario.

El proceso debe estar autocontenido y deja el negocio en un estado consistente.

Para identificar el proceso se debe aplicar una de las tres siguientes reglas:

1. La lgica del proceso debe ser nica/diferente respecto a las otras EO dentrode la aplicacin (no hay dos procesos iguales).

2. El conjunto de elementos de datos identificados es diferente de los conjuntosidentificados por otras EO dentro de la aplicacin. Note que hay diferenteselementos de datos y no diferentes datos en los mismo campos. Por ejemplo unreporte de cuenta producido para personas que tienen diferentes datos en losmismos campos son contados como un EO. Dos reportes producidos en formaseparada a nivel de detalle y a nivel de resumen, pueden ser contados como dos EOporque tienen una lgica de procesamiento y clculos nicos.

3. Los ILF o EIF referenciados son diferentes de aquellos referenciados por otros

EO dentro de la aplicacin.Algunos ejemplos adicionales de EO se presentan a continuacin. Estos son solamenteejemplos; cualquier dato o informacin de control listada aqu debe corresponder con ladefinicin indicada y con las reglas para contar EO:

Reportes que requieren el uso de algoritmos o clculos. Por ejemplo un reporte decuentas corrientes por semana o mensual.


24/88


22

Transferencia de datos, archivos y/o mensajes que se envan a otra aplicacin cuando eldato es calculado o derivado y la actualizacin ocurre como parte del procesoelemental. Por ejemplo un archivo de transacciones se enva desde una aplicacin deCuentas por cobrar a una aplicacin Mayor general (administrada en formaseparada) cuando algn total es calculado u ocurre una entrada a la base de datos de la

aplicacin de Cuentas por cobrar para indicar cul transaccin fue enviada (se cuentacomo un EO para la aplicacin de Cuentas por cobrar y como un EI para laAplicacin General).

Un cheque que cuando se cre, simultneamente actualiz el registro de cheques con elnmero de cheques (este es un proceso elemental).

Un reporte de conversin que reporta el esfuerzo de conversin cuando los datos estnmigrando como parte de un proyecto en desarrollo o mantenimiento; esto debera serincluido como parte del conteo del proyecto pero no dentro del conteo de la aplicacin.

Informacin derivada o calculada desplegada sobre una pantalla o o pasada en unarchivo.

Informacin derivada/calculada desplegada sobre una pantalla. Despliegues grficos tales como grfico de barras, grfico pastel cuando ellos requieren

clculos.

Respuestas calculadas devueltas por el telfono.

Una notificacin de que una tarjeta de crdito ha sido reportada como perdida.

Clculo de un premio propuesto por una poltica de seguros.

Los siguientes son ejemplos que frecuentemente por error se cuentan como EO:

Reportes idnticos con valores de datos diferentes (se cuenta solo una vez) tales comoreportes de departamentos.

Reportes que no tienen frmulas, clculos o datos derivados y no administran un ILFdentro de la aplicacin que est enviando datos (ms probable es que se cuente como unEQ).

Campos reaumenten dentro de un reporte de detalles (el reporte de detalles es el EO).

Archivos enviados a otra aplicacin que no tiene frmulas, clculos o datos derivados yno administran un ILF dentro de la aplicacin que est enviando datos (ms probable esque se cuente como un EQ).

Mltiples medios cuando la lgica de procesamiento no es diferente.

Pantallas de refrescamiento o cancelacin de datos (no se cuenta).

Reordenamiento o clasificacin de un conjunto de datos sin otra lgica deprocesamiento.

Un dato referenciado ledo por otra aplicacin desde el almacn de datos en laaplicacin que se est contando (el dato no se cuentan como EO por la aplicacincontada).

Ayudas (contadas como EQ)

Sistema de ingreso.


25/88


23

Mtodos mltiples para invocar el mismo proceso de salida.

Mensajes de error que resultan de una edicin o validacin de un EI o la parte desolicitud de un EQ o EO.

Mensajes de confirmacin que reconoce que los datos se han procesado.

Mensajes que solicita al usuario confirmar un borrado o cualquier otra transaccin.

Datos idnticos que se envan a ms de una aplicacin (contado solo una vez).

Reportes ad-hoc que los usuarios dirigen o controlan a travs de lenguajes como SQL oFOCUS.

Datos enviados en lnea o en lote dentro de la misma aplicacin; no cruzan la fronterade la aplicacin.

Datos enviados entre el cliente y el servidor dentro de la misma aplicacin; no cruzan lafrontera de la aplicacin.

2.2 Reglas para determinar la complejidad y Contribucin de los EOEl conteo fsico de los EO junto con la complejidad funcional relativa de

cada uno, determina la contribucin de las EO para el conteo de los puntosde funcin desajustados. Cada EO identificado debe ser asignado a lacomplejidad funcional basada en el nmero del tipo de elementos de datos(DET) y los archivos referenciados (FTR) asociados con el EO.

A continuacin se describen los siguientes trminos:Complejidad funcional es un peso asignado a cada funcin transaccional. De acuerdo a lamatriz de complejidad la calificacin puede ser alta, media o baja considerando el nmerode DET y RET.

DETson usualmente campos o atributos nicos, reconocibles por el usuario, no repetitivosque cruzan la frontera de la aplicacin.

FTR son simplemente archivos referenciados. Se refieren al nmero total de ILF ledos oadministrados y de EIF ledos por la transaccin EO.

Las siguientes reglas del IFPUG se deben aplicar para contar los elementos de datos,campos, o atributos (conocidos como DET) para los EO:

Se cuenta un DET para cada campo reconocible por el usuario, no repetitivo queingresa la frontera de la aplicacin y requiere especificar qu, cundo y/o cmo eldato es recuperado y /o generado por un proceso elemental. Tales campos a menudose consideran como informacin de control, informacin de seleccin, o parmetros deprocesamiento.

Se cuenta un DET para cada campo reconocible por el usuario, no repetitivo o atributo que sale de la frontera de la aplicacin. Se incluyen atributos de llavesforneas e informacin de control.

Si un DET ingresa o sale de la frontera se cuenta solo una vez para el procesoelemental.

Se cuenta un DET por la capacidad de enviar un mensaje de respuesta a unsistema que est fuera de la frontera de la aplicacin para indicar que ha ocurridoun error durante el procesamiento, confirmar que el procesamiento est completo,


26/88


24

o verificar que el proceso debe continuar. Aunque hayan mltiples posibilidades demensaje, se cuenta solo un DET para el proceso elemental. Esto es, solamente se cuentaun DET para todos los mensajes, aunque hayan mltiples mensajes de error,verificacin y confirmacin.

Se cuenta un DET por la capacidad de especificar una accin a tomar por el EO

an si hay mtodos mltiples o llaves mltiples requeridos para invocar un unamisma lgica de procesamiento. Por ejemplo: botones de aceptacin, teclas defuncin, teclas de accin, o un click al ratn.

No contar variables de paginacin generadas por el sistema, incluyendo: elnmero de pgina, informacin de las posiciones de filas y columnas en pantallas oreportes, comandos de paginacin (como: previo, prximo, flechas) o campos dehora/fecha. Se cuentan DET para incluir un campo de fecha recuperado, pero no lasfechas generadas por el sistema, tal como cundo se imprime el reporte.

No contar literales como DET, incluyendo: ttulos de reportes, identificadores depantallas, encabezados de columnas, o ttulos de campos.

No contar campos que son administrados por el ILF durante el proceso elemental

del EO si los campos no cruzan la frontera. Contar un DET para cada campo lgico que es almacenado fsicamente como

campo mltiples pero que es requerido por el usuario como una nica pieza deinformacin. Por ejemplo un dato o nombre almacenado en tres campos pero usadocomo un campo se cuenta como un DET. Una direccin (calle, ciudad y cdigo postal)puede ser contado como un DET sobre una etiqueta de direccin si este es consideradopara representar un grupo de datos.

Contar un DET para cada tipo de etiqueta y cada tipo de equivalente numrico enun grfico. Por ejemplo un grfico pastel puede tener dos DET, uno para la categora yuno para el porcentaje aplicado, an si el porcentaje no tiene etiqueta.

Contar un DET para cada informacin de texto que consista de una simple

palabra, una oracin, o muchos prrafos.

Las siguientes reglas de IFPUG se aplican para contar tipos de archivos referenciados(conocidos como FTR por IFPUG) para los EO: Contar un FTR por cada ILF administrado o EIF ledo durante el procesamiento

del EO. Contar un FTR por cada ILF administrado por el proceso elemental del EO. Contar solamente un FTR para un ILF que es tanto ledo como administrado por

el EO.

2.3 Determinar los puntos de funcin sin ajustar (PFSA) para los EO.Para determinar los puntos de funcin sin ajustar de los EO se deben seguir las siguientesinstrucciones:

1. Aplicar las reglas descritas en la seccin 4.2.1 para listar los EO de la aplicacin.

2. Aplicar las reglas de la seccin 4.2.2 y obtener los DET y los FTR para cada EOidentificado en el punto anterior.


27/88


25

3. Con base en la lista de EO con sus DET y FTR y la Matriz de complejidad para losEO (refirase a l atabla 6) determinar la complejidad de cada EO. Por ejemplo:supongamos que la aplicacin requiere un reporte que requiere relacionar dostablas, realizar un clculo y actualizar un campo de 1 de las 2 tablas, por lo tantotiene 2 FTR. Las caractersticas de actualizar las tablas y de realizar los clculos lo

ubica como 1 EO y no como EQ. Adems presentar ms de 20 DET con camposde ambas tablas, incluyendo 1 DET de al menos un mensaje de error y 1 DET deuna tecla de comando. Con un total de 2 FTR y ms de 20 DET y utilizando latabla Matriz de complejidad para los EO ese reporte tendr una complejidad Alta.Otro reporte podra requerir la relacin de 3 tablas y tambin actualiza alguna de lastablas de la aplicacin. El reporte tendr 3 FTR y aproximadamente entre 6 y 19DET, incluyendo 2 DET de mensaje de error y de tecla de comando. Este segundareporte tendr una complejidad Media.

Tabla 6. Matriz de complejidad para los EO.

Nmero de Elementos de Datos (DET)Nmero de ArchivosReferenciados

(FTR) 1-5 6-19 20


28/88


26

3. Definicin de las Consultas externas (EQ, en ingls External Inquiries)

Una consulta externa (EQ) es un proceso elemental de la aplicacin queresulta de recuperar un dato o informacin de control que se enva fuerade la frontera de la aplicacin. El objetivo principal de una EQ espresentar informacin al usuario a travs de la recuperacin de datos o

informacin de control desde un ILF o un EIF. La lgica de procesamientono posee frmulas matemticas ni clculos y no se crea datos derivados.Una EQ no administra un ILF durante su procesamiento, ni altera laconducta del sistema.


Un proceso elemental es la unidad de actividad ms pequea que tiene significado para elusuario. El proceso debe estar autocontenido, y dejar el negocio un estado consistente. Porejemplo: para realizar una recuperacin particular los usuarios han solicitado tener lacapacidad de ingresar 5 campos de informacin de control por ejemplo: un modelo, color,estilo, ao de produccin y garanta. Cualquier nmero de combinaciones puede ser

posible, pero cualquier de las 5 puede ser seleccionada como una seleccin y/o. Ingresaruno de los campos no es un proceso elemental ni ingresar los 5. Posibles campos quesatisfagan los criterios de la informacin de control ingresada deben ser extrados ypresentados al solicitante, antes de que la transaccin se considere un proceso elemental.Una EQ involucra una solicitud de informacin (generada internamente desde un procesode la aplicacin o externa a la aplicacin desde un proceso, persona, cosa u otraaplicacin), un extracto de uno o ms ILF o EIF, y la entrega de informacin al usuario; sinlas 3 subactividades la transaccin no est completa.

Los datos se refieren a campos de informacin procesados por la EQ. Por ejemplo: podranhaber campos de datos recuperados y desplegados como resultado de la consulta descrita

anteriormente - modelo, color, estilo, ao de produccin y garanta.La informacin de control es un dato que influye en un proceso elemental de la aplicacinque est siendo contada; en el caso de los EQ, estos datos, reglas o parmetros especificanqu, cundo o cmo el dato va a ser procesado. La informacin de control no es un procesoelemental por s mismo.

La lgica de procesamiento incluye aquellos requerimientos solicitados especficamentepor un usuario para completar un proceso elemental. Usualmente se requiere unacombinacin de lgica de procesamiento para completar un proceso elemental. Una lgicade procesamiento por s misma, no se debera usar para determinar la exclusividad de unEI, EO o EQ. Un proceso elemental de un EQ puede incluir muchas validaciones, filtros,ordenamientos, etc. Clasificar, ordenar o formatear un conjunto de datos no se considerauna lgica de procesamiento exclusiva, sin embargo podra haber otras lgicas deprocesamiento exclusivas durante cualquiera de esas operaciones.

Los datos derivados requieren procesamiento en lugar de recuperar, convertir y editarinformacin, de uno o ms ILF o EIF. El dato derivado es creado por la transformacin dedatos existentes para crear datos adicionales. Los EQ no contienen datos derivados.

Administrarse refiere a la capacidad de modificar datos a travs de un proceso elemental.Un EQ no administra datos, un EI o un EO administran datos.


29/88


27

3.1 Reglas para contar los EQ.

Para datos o informacin de controla ser contada como EQ, las siguientes reglas deIFPUG se deben aplicar:

Los datos o informacin de control deben salir de la frontera de la aplicacin. Los datos o informacin de control deben ser recuperados de uno o ms ILF o

EIF.

La lgica de procesamiento del proceso elemental no debe crear datos derivados.

La lgica de procesamiento del proceso elemental no debe contener frmulasmatemticas o clculos.

La lgica de procesamiento del proceso elemental no debe alterar la conducta de laaplicacin.

El proceso no debe administrar un ILF.

El proceso debe ser la unidad ms pequea de actividad que tiene significado parael usuario.

El proceso debe estar autocontenido y dejar la aplicacin en un estado consistente.

Para el proceso identificado se debe aplicar una de las tres siguientes reglas:

1. La lgica de procesamiento debe ser nica/diferente de las lgica deprocesamiento de otras EQ dentro de la aplicacin. (No hay dos procesosiguales)

2. El conjunto de elemento de datos identificado es diferente de los conjuntosidentificados en otras EQ dentro de la aplicacin (No hay dos flujos iguales).

3. Los ILF o EIF referenciados son diferentes de aquellos referenciados por otrasEQ dentro de la aplicacin.

Algunos ejemplos adicionales de EQ se presentan a continuacin. Estos son solamenteejemplos; cualquier dato o informacin de control listada aqu debe corresponder con ladefinicin indicada y con las reglas para contar EQ:

Un dato transaccional que es recuperado desde uno o ms ILF y/o EIF y desplegado --por ejemplo: un puesto, una descripcin de un elemento, un dato de empleado, un datode pago.

Las funciones de usuario tales como ver, desplegar, listar, imprimir (recuerde que unaimpresin y una vista con la misma lgica de procesamiento son contadas como una EQy no como dos).

Las consultas implcitas (recuperaciones de datos antes de una funcin de modificacino borrado) que hacen que la consulta pueda ser usada como un proceso nico y no unaduplicacin de otro previamente contada como EQ.

Los reportes generados sobre una base peridica que no contiene frmulas, clculos odatos derivados y no administran un ILF.

Los datos del sistema, parmetros y la configuracin a menos que sean calculados.


30/88


28

Las pantallas de ingreso que provean una seguridad especfica a la aplicacin.

Cualquier nivel de ayuda; por ejemplo, un campo, o una pantalla cuando se recuper deun ILF O EIF.

Recuperaciones de datos administrados va electrnica o telefnica.

Archivos Enviados a otra aplicacin que no contiene frmulas, clculos o datosderivados y no administran un ILF dentro de la aplicacin que est enviando los datos(la transaccin puede ser un EI para la aplicacin receptora).

Recuperacin de correo desde el mailbox.

Cajas de listas o posicionamiento de un dato sobre la pantalla para devolver un datoadministrado desde un ILF o EIF.

Los siguientes son ejemplos de aspectos que frecuentemente mal identificados como EQ:

Mtodos mltiples para invocar la misma lgica; por ejemplo dos teclas que realizan lamisma accin o la misma transaccin sobre mltiples pantallas (contarlas solamente

una vez). Mtodos mltiples cuando la lgica de procesamiento no es diferente.

Consultas que pueden ser accesadas desde mltiples reas o pantallas de una aplicacin(se cuentan solo una vez).

Pantallas de men usadas para navegar y seleccionar, y no recuperan datosadministrados (no contarlas).

Pantallas para ingresar que facilitan la entrada al usuario en la aplicacin pero noinvocan seguridad (no contarlas).

Datos derivados o calculados en oposicin a recuperacin de datos (contarlos como unEO).

Ordenamiento o clasificacin de un grupo de datos sin otra lgica de procesamiento.

Respuestas a mensajes que requieren una confirmacin del usuario.

Mensajes de error y/o confirmacin.

Documentacin del sistema en lnea.

Datos que pasan entre lnea y lote dentro de la misma aplicacin, no cruzan la fronterade la aplicacin.

Datos que pasan entre el cliente y el servidor dentro de una misma aplicacin, nocruzan la frontera de la aplicacin.

Datos que no son recuperados de los datos administrados. Por ejemplo: datos hard-coded (no contarlos).

3.2 Reglas para determinar la complejidad y Contribucin de los EQEl conteo fsico de los EQ junto con la complejidad funcional relativa decada uno, determina la contribucin de las consultas externas al conteo delos puntos de funcin desajustados. A cada EQ identificado se le debe


31/88


29

asignar una complejidad funcional basada en el nmero de DET y FTRasociados con el EQ.

A continuacin se describen los siguientes trminos:Complejidad funcional es un peso asignado a cada funcin transaccional. De acuerdo a lamatriz de complejidad la calificacin puede ser alta, media o baja considerando el nmero

de DET y FTR.DETson usualmente campos o atributos nicos, reconocibles por el usuario, no repetitivoso atributos que cruzan la frontera de la aplicacin.

FTR son simplemente archivos referenciados. Se refieren al nmero total de ILF y EIFledos por la transaccin EQ.

Las siguientes reglas IFPUG se deben aplicar para contar los elementos de dato,campos o atributos (conocidos como DET por IFPUG) para los EQ: Se cuenta un DET para cada campo reconocible por el usuario, no repetitivo que

ingresa la frontera de la aplicacin y requiere especificar qu, cundo y/o cmo eldato es recuperado y /o generado por el proceso elemental. Tales campos a menudose consideran como informacin de control, informacin de seleccin, o parmetros deprocesamiento.

Se cuenta un DET para cada campo reconocible por el usuario, no repetitivo o atributo que sale de la frontera de la aplicacin. Se incluyen atributos de llavesforneas e informacin de control.

Si un DET ingresa o sale de la frontera se cuenta solo una vez para el procesoelemental.

Se cuenta un DET por la capacidad de enviar un mensaje de respuesta fuera de lafrontera de la aplicacin para indicar que ha ocurrido un error durante el

procesamiento, confirmar que el procesamiento est completo, o verificar que elproceso debe continuar. Aunque hayan mltiples posibilidades de mensaje, se cuentasolo un DET para el proceso elemental. Esto es, solamente se cuenta un DET para todoslos mensajes, aunque hayan mltiples mensajes de error, verificacin y confirmacin.

Se cuenta un DET por la capacidad de especificar una accin a tomar por el EQan si hay mtodos mltiples o llaves mltiples requeridas para invocar unamisma lgica de procesamiento. Por ejemplo: botn de aceptacin, teclas de funcin,teclas de accin, o un clic al ratn.

No contar variables de paginacin generadas por el sistema, incluyendo nmerode pgina, informacin de posiciones de filas y columnas en pantallas o reportes,comandos de paginacin (como: previo, prximo, flechas) o campos de hora/fecha.

Se cuenta un DET por incluir un campo de fecha recuperado, pero no las fechasgeneradas por el sistema, tal como cundo un reporte es impreso.

No contar literales como DET, incluyendo: ttulos de reportes, identificadores depantallas, encabezados de columnas, o ttulos de campos.

No contar campos que son administrados por el ILF durante el proceso elementaldel EQ si los campos no cruzan la frontera.

Contar un DET para cada campo lgico que es almacenado fsicamente comocampo mltiples pero que es requerido por el usuario como una nica pieza de


32/88


30

informacin. Por ejemplo un dato o nombre almacenado en tres campos pero usadocomo un campo se cuenta como un DET. Una direccin (calle, ciudad y cdigo postal)puede ser contado como un DET sobre una etiqueta de direccin si este es consideradopara representar un grupo de datos.

Contar un DET para cada tipo de etiqueta y cada tipo de equivalente numrico en

un grfico. Por ejemplo un grfico pastel puede tener dos DET, uno para la categora yuno para el porcentaje aplicado, an si el porcentaje no tiene etiqueta. Un grfico puedeser un EQ si no hay clculos cuando el grfico es generado: esto es el porcentaje esledo de datos almacenados.

Contar un DET por cada informacin de texto que consista de una simple palabra,una oracin, o muchos prrafos.

La siguiente regla de IFPUG se aplica para contar los tipos de archivos referenciados(conocidos como FTR por IFPUG) para los EQ: Contar un FTR por cada ILF administrado o EIF ledo durante el procesamiento

del EQ.

3.3 Determinar los puntos de funcin sin ajustar (PFSA) para los EQ.Para determinar los puntos de funcin sin ajustar de los EQ se deben seguir las siguientesinstrucciones:

1. Aplicar las reglas descritas en la seccin 4.3.1 para listar los EQ de la aplicacin.

2. Aplicar las reglas de la seccin 4.3.2 y obtener los DET y los FTR para cada EQidentificado en el punto anterior.

3. Con base en la lista de EQ con sus DET y FTR y la Matriz de complejidad para losEQ (refirase a l tabla 8) determinar la complejidad de cada EQ. Por ejemplo:supongamos que la aplicacin requiere una consulta que requiere relacionar dos

tablas, por lo tanto tiene 2 FTR. Adems presentar ms de 20 DET con campos deambas tablas, incluyendo 1 DET de al menos un mensaje de error y 1 DET de unatecla de comando. Con un total de 2 FTR y ms de 20 DET y utilizando la tablaMatriz de complejidad para los EQ ese reporte tendr una complejidad Alta. Otraconsulta podra requerir la relacin de 3 tabla y aproximadamente entre 6 y 19 DET,incluyendo 2 DET de mensaje de error y de tecla de comando. Esta segundaconsulta tendr una complejidad Media.

Tabla 8. Matriz de complejidad para los EQ.

Datos (DET)Archivos

Referenciados(FTR)

1-5 6-19 20

1 Bajo Bajo Medio

2-3 Bajo Medio Alto

>3 Medio Alto Alto


33/88


31

4. Una vez determinada la complejidad de cada EO se le debe asignar un peso. Conbase en la siguiente tabla se ubica la fila de los EO y columna correspondiente a lacomplejidad obtenida en el punto anterior y se multiplica el nmero de EO por elpeso que le corresponde. Siguiendo el ejemplo: tenamos 1 EO con complejidadMedia y 1 EO con complejidad Alta, obtenidos en el punto anterior. Podemos

contabilizar 12 puntos de funcin desajustados para los EO.Tabla 9. Conteo para los EQ.


Archivos Lgicos Internos (ILF) x7 x10 x15

Archivos de Interfase Externa (EIF) x5 x7 x10

Entradas Externas (EI) x3 x4 x6


Consultas Externas (EQ) x3 1x4 1x6

4 6Total 10 Puntos de Funcin sin Ajustar (PFSA)

Paso 5. Determinar el Factor de Ajuste de Valor (FAV) a travs de las 14Caractersticas Generales

Las funciones propias de los sistemas de informacin incluyen factores generales que noson suficientemente representadas por las funciones transaccionales y las funciones dedatos. Esta seccin describe las definiciones, reglas y guas para identificar el Factor de

Ajuste de Valor (FAV), el cual es usado como un multiplicador de los Puntos de FuncinDesajustados para calcular los Puntos de Funcin Ajustados. El clculo del FAV se basa enla identificacin de 14 Caractersticas Generales del Sistema.

Las Caractersticas Generales del Sistema deben ser evaluadas en trminos del Grado Totalde Influencia (GTI) sobre una escala de 0 a 5:

0 Factor no presente o ninguna influencia

1 Influencia insignificante

2 Influencia moderada

3 Influencia media

4 Influencia significativa

5 Influencia fuerte

A continuacin se describen las 14 caractersticas generales con sus correspondiente GradoTotal de Influencia.

1. Comunicacin de Datos


34/88


32

Los datos y la informacin de control usados en la aplicacin son enviados o recibidos atravs de las facilidades de comunicacin. El peso se aplica como sigue:

0 La aplicacin es procesamiento en lote puro o solo PC. No hay interactividad.

1 La aplicacin es en lote pero tiene capacidad de ingreso remoto o de impresinremota.

2 La aplicacin es en lote pero tiene capacidad de ingreso remoto y de impresinremota.

3 La aplicacin incluye un conjunto de datos en lnea o teleprocesamiento (TP)front-end hacia un proceso en hacia un proceso en lote o sistema de consulta. Sonaplicaciones que tienen pantallas de entrada de datos front-end, pero actualizanarchivos lgicos internos a travs de un procesamiento en lote.

4 La aplicacin es ms que un front-end, pero soporta solo un tipo de protocolo decomunicacin TP. Igual que 3 pero la actualizacin ocurre interactivamente.

5 La aplicacin es ms que un front-end, pero soporta ms de un tipo de protocolode comunicacin TP.

Por lo general las aplicaciones en lote reciben un peso de 0 a 3, en lnea de 3 a 4 yen tiempo real, telecomunicacin o sistemas de control de procesos reciben de 4 a 5.

2. Procesamiento de Datos Distribuido

Es el grado en que una aplicacin transfiere datos entre los componentes de la aplicacin.El peso se aplica como sigue:

0 La aplicacin no soporta la transferencia de datos o funciones de procesamientoentre los componentes del sistema. Totalmente monoltica.

1 La aplicacin prepara los datos para que el usuario los procese en otrocomponente del sistema, tal como una hoja electrnica o un BBMS en una PC.

2 La aplicacin prepara los datos para transferirlos, entonces son transferidos yprocesados sobre otro componente del sistema (no para procesamiento de usuariofinal).

3 El procesamiento es distribuido y la transferencia de datos es en lnea y en unasola direccin.

4 El procesamiento es distribuido y la transferencia de datos es en lnea y en ambasdirecciones.

5 Las funciones de procesamiento son dinmicamente ejecutadas en muchoscomponentes del sistema.

Solo las aplicaciones distribuidas o en tiempo real tienen peso. Las distribuidasprimitivas pueden ser 1 0 2. Las de cliente-servidor o Web son de 2 a 4. Un peso de5 puede asignarse cuando son mltiples servidores o procesadores, cada uno de loscuales se ha seleccionado dinmicamente sobre la base de disponibilidad en tiemporeal.

3. Rendimiento


35/88


33

Describe el grado en que el tiempo de respuesta y consideraciones de rendimiento influyenen el desarrollo de la aplicacin. Los objetivos de rendimiento son indicados o aprobadospor el usuario en respuesta al diseo, desarrollo, instalacin y soporte de la aplicacin. Elpeso se aplica como sigue:

0 No hay requerimientos de rendimiento especiales indicados por el usuario.

1 Los requerimientos de rendimiento y diseo fueron indicados y revisados por elusuario pero no se requieren acciones especiales. El retraso en el procesamiento sedeja para el siguiente da comercial.

2 El tiempo de respuesta es crtico durante las horas pico pero no se requiere undiseo especial para la utilizacin del CPU.

3 El tiempo de respuesta es crtico durante todas las horas comerciales, pero no serequiere un diseo especial para la utilizacin del CPU. Los requerimientos en elretraso de procesamiento se consideran como restricciones.

4 Adems, los requerimientos de rendimiento indicados por el usuario son lo

suficientemente crticos como para realizar anlisis del rendimiento durante eldiseo.

5 Adems, las herramientas de anlisis de rendimiento fueron utilizadas durante eldiseo, el desarrollo y/o implementacin para alcanzar los requerimientos derendimiento indicados por el usuario.

Esta caracterstica se parece mucho a la 5, pero requiere consideraciones derendimiento durante las fases del desarrollo de la aplicacin. El tiempo de respuestase relaciona tpicamente con el procesamiento interactivo, y el throughput con elprocesamiento en lote. Un peso de 4 requiere tareas de anlisis de rendimientodurante la fase de diseo. Un peso de 5 requiere el uso de herramientas de anlisis

de rendimiento.4. Configuracin muy utilizada (procesamiento de equipo muy utilizado)

Una configuracin operacional pesada describe el grado en que las restricciones derecursos computacionales influyen en el desarrollo de la aplicacin. Una configuracinoperacional pesada requiere consideraciones especiales de diseo. El peso se aplica comosigue:

0 No hay restricciones operacionales implcitas o explcitas incluidas.

1 Las restricciones operacionales existen pero son menos restrictivas que unaaplicacin tpica. Ningn efecto especial es necesario para alcanzarlas.

2 Existen algunas consideraciones de seguridad o de tiempo.3 Hay requerimientos de procesador especficos para una parte de la aplicacin.

4 Las restricciones de operacin indicadas requieren restricciones especiales sobrela aplicacin en un procesador central o en un procesador dedicado.

5 Adems, hay restricciones especiales sobre la aplicacin en los componentesdistribuidos del sistema.


36/88


34

5. Tasa Transaccional

La tasa transaccional describe el grado en el que la tasa de transaccin comercial influye enel diseo, desarrollo, instalacin y soporte de la aplicacin. El peso se aplica como sigue:

0 No se anticipa un perodo pico transaccional.

1 Se anticipa un perodo transaccional pico mensualmente, trimestralmente,semestralmente o anualmente.

2 Un perodo transaccional pico se anticipa.

3 Un perodo transaccional pico se anticipa diariame

guía pf 2006 versión completa

Documents