ANEXO A PUNTOS FUNCIÓN

Tamaño: px

Comenzar la demostración a partir de la página:

Download "ANEXO A PUNTOS FUNCIÓN"

Felisa Quintana Rubio
hace 7 años
Vistas:

1 ANEXO A PUNTOS FUNCIÓN Área: Aplicaciones Informáticas Fecha: Marzo de Santa Engracia, Madrid

2 Anexo A Puntos función 1. INTRODUCCIÓN Para la medición de puntos de función en las peticiones se utilizará una metodología propia basada en IFPUG, en la que se cuantificará la funcionalidad aportada para valorar el esfuerzo en el que se incurre. Se deben tener en cuenta los siguientes criterios al hacer la estimación: Se distinguirán varias complejidades, al menos, complejidad baja, media y alta. Para cada solicitud tipo de mantenimiento se deberá indicar qué factores determinan la complejidad (de forma cuantitativa si es posible) Se distinguirá entre la creación de nuevos programas u objetos y las modificaciones o eliminaciones de objetos/programas ya existentes Reutilización de código: aplicar un factor reductor en base a la reutilización de código Tareas repetitivas: aplicar un factor reductor en base a la realización de tareas repetitivas. Organización: se aplicará un factor modificador en base a la complejidad de la organización y la madurez de los sistemas, que se irá revisando en base a los resultados empíricos de mutuo acuerdo entre Canal y el Adjudicatario. Los pasos a seguir para el cálculo de puntos de función son los siguientes: 1. Diseño lógico de la funcionalidad 2. Relación de procesos y funciones 3. Determinación de la complejidad de los componentes identificados 4. Cálculo de puntos de función sin ajustar 5. Factores de ajuste por función 6. Cálculo de puntos función suministrados A continuación pasamos a detallar cada uno de ellos 2. DISEÑO LÓGICO DE LA FUNCIONALIDAD Se realizará un diseño lógico de la funcionalidad a realizar en base al documento de requisitos funcionales de usuario que será la base para el recuento de puntos de función. En este diseño se indicarán: - Usuarios funcionales identificados: por usuario funcional se entiende cualquier (persona, aplicativo, destino) remitente y/o destinatario de datos necesario para cumplir un requisito funcional. - Funciones de datos: funcionalidad proporcionada al usuario para satisfacer los requisitos de datos internos y externos. - Funciones transaccionales: funcionalidad proporcionada al usuario para procesar datos. Pueden ser entradas externas, salidas externas o consultas externas. Página 2 de 7

3 - Procesos funcionales: componentes elementales de un conjunto de requerimientos de usuario formados por al menos 2 funciones (movimientos) de datos: uno debe ser de entrada y otro de salida o escritura. - Tipo de alcance: se deberán identificar, para su posterior ajuste, las funcionalidades nuevas, las modificaciones o las eliminaciones. 3. REALACIÓN DE PROCESOS Y FUNCIONES En base al diseño anterior se procederá a relacionar los procesos funcionales junto a las funciones de datos y transaccionales identificadas con el número de campos únicos (DETs) y el número de subgrupos o registro de datos (RETs) reconocidos por el usuario. A continuación mencionamos algunas reglas a tener en cuenta para el recuento de funciones de datos y transaccionales: Funciones de datos: - Ficheros lógicos internos (ILFs) Un fichero lógico interno debe ser visible al usuario (no contar los ficheros que dependen del diseño interno del sistema), y debe ser actualizado por la aplicación. Cada fichero lógico interno representa datos que se almacenan temporal o permanentemente, y normalmente se corresponden con una entidad del modelo lógico de datos. Sólo se contabilizarán los que sean necesario incorporar o modificar para realizar la nueva funcionalidad. Los que sólo sean referenciados en las funciones transaccionales no se incluirán en este conteo. - Ficheros lógicos externos (ELFs) Un fichero de interfaz externa debe ser visible al usuario (no contar los ficheros que dependen del diseño interno del sistema), y debe ser actualizado fuera de la aplicación. Cada fichero de interfaz externa representa datos que se almacenan temporal o permanentemente, y normalmente se corresponden con una entidad del modelo lógico de datos. Sólo se contabilizarán los que sean necesario incorporar o modificar para realizar la nueva funcionalidad. Los que sólo sean referenciados en las funciones transaccionales no se incluirán en este conteo. Funciones transaccionales: - Entradas (EIs) Deben ser visibles al usuario y llevar datos al sistema modificando un fichero interno. Página 3 de 7

4 Las transacciones de inserción, modificación, y borrado se cuentan como entradas separadas porque la lógica de procesamiento es diferente para cada una. La transacciones tipo case se cuentan también como entradas separadas ya que, aunque pueden introducirse desde la misma pantalla, la lógica de procesamiento es diferente para cada una de ellas. Los menús u otras navegaciones no se cuentan como entradas ya que no añaden o modifican datos en el sistema. Cada tabla mantenida por el usuario se debe asociar con al menos una entrada. - Salidas (EOs) Una salida debe ser visible al usuario y sacar datos o datos de control del sistema a través de los límites de la aplicación, tanto si es hacia el usuario como a un fichero de transacción para otra aplicación. Las salidas muy complejas deben tratarse como colecciones de salidas, aunque se presenten en el mismo informe físico. Cada tabla mantenida por el usuario se debe asociar con al menos una salida - Consultas (EQs) Una consulta debe ser visible para el usuario, representar un flujo de entrada/salida donde la entrada inmediatamente genera la salida, y no debe modificar los ficheros de datos. Considerar la consulta como un único flujo, no contar de forma separada la entrada y la salida. Analizar la entrada y la salida por separado y utilizar el más alto de los valores de complejidad. 4. DETERMINACIÓN DE LA COMPLEJIDAD DE LOS ELEMENTOS Una vez que se han clasificado las funciones de la aplicación según los componentes anteriores, se les debe asignar una complejidad baja, media o alta. Para los ficheros lógicos se clasificarán en función del número de campos únicos (DETs) y el número de subgrupos o registro de datos (RETs) reconocidos por el usuario. Tabla de complejidades funciones de datos DETs RETs o más 1 Baja Baja Media Página 4 de 7

5 2-5 Baja Media Alta 6 o más Media Alta Alta Para las salidas, entradas o consultas la puntuación vendrá dada por el número de tipos de ficheros que actualicen (FTRs) y el número de campos (DETs) Tabla de complejidades funciones transaccionales Entradas DETs FTRs o más 0-1 Baja Baja Media 2-3 Baja Media Alta 4 o más Media Alta Alta Salidas DETs FTRs o más 0-1 Baja Baja Media 2-3 Baja Media Alta 4 o más Media Alta Alta Consultas Las consultas no modifican el sistema. Se calcula la complejidad de la parte de entrada y de la parte de salida y se coge la de mayor complejidad. 5. CÁLCULO DE PUNTOS FUNCIÓN SIN AJUSTAR A continuación, se asignan puntos para cada nivel de complejidad y cada tipo de componente. La suma total de estos puntos dará el número de puntos función sin ajustar. Asignación puntos función sin ajustar Complejidad Componentes Baja Media Alta Página 5 de 7

6 Ficheros internos (ILFs) X 7 = X 10 = X 15 = Ficheros externos (ELFs) X 5 = X 7 = X 10 = Entradas (EIs) X 3 = X 4 = X 6 = Salidas (EOs) X 4 = X 5 = X 7 = Consultas (EQs) X 3 = X 4 = X 6 = 6. FACTORES DE AJUSTE Sobre los puntos de función calculados en el apartado anterior aplicaremos unos factores de ajuste para cada función de datos o transaccional en función de: - Tipo de alcance - Reutilización de código - Tareas repetitivas - Entorno: factor de ajuste por productividad según entorno Se aplicarán estos factores sobre los puntos función calculados para cada función FACTOR DE AJUSTE POR TIPO DE ALCANCE Se aplicará un factor de ajuste a los puntos función calculados según el tipo de desarrollo a realizar, diferenciando entre nueva funcionalidad, modificación o adaptación de una existente, eliminación de un proceso, regularización de datos, extracción de información o parametrización del sistema. Se realizará una valoración distinta para cada funcionalidad aplicando el factor correspondiente. Tipo trabajo Nuevo desarrollo 1 Modificación / Adaptación 0,85 Eliminación 0,4 Regularización de datos 0,5 Extracción de información 0,6 Parametrización 0, FACTOR REDUCTOR POR REUTILIZACIÓN DE CÓDIGO Se aplicará un factor reductor a la funcionalidad según la reutilización de código Reutilización de código No se reutiliza 1 Baja reutilización 0,85 Media reutilización 0,5 Página 6 de 7

7 Alta reutilización 0, FACTOR REDUCTOR POR TAREAS REPETITIVAS Cuando los procesos funcionales identificados sean repetitivos, se calcularán los puntos función para uno de ellos y el resto será el resultado de aplicar el siguiente factor reductor, siendo el total la suma de todos. Tareas repetitivas Factor a aplicar 0, FACTOR DE AJUSTE POR ENTORNO Se aplicará al resultado final del cálculo un factor corrector calculado en función del entorno de desarrollo y la metodología exigida en este pliego, factores que influyen en la productividad final. Este factor corrector para la aplicación a mantener en este pliego se ha establecido en: Factor de entorno Factor a aplicar 0,94 7. CÁLCULO DE PUNTOS FUNCIÓN SUMINISTRADOS El número total de puntos de función suministrados será el resultado de aplicar al número de puntos función calculados aplicando los factores reductores indicados en el apartado anterior. Página 7 de 7

Documentos relacionados

Ayuntamiento de Gijón/Xixón

Ayuntamiento de Gijón/Xixón Referencia: 005041/2010 Sección de Contratación ASUNTO : PLATAFORMA TECNOLÓGICA PARA LA CREACIÓN DE PORTALES WEB 2.0 CONTRATO ADMINISTRATIVO DE SERVICIO DEL EXCMO AYUNTAMIENTO