Puntos de Funcin 1 Plan Visin general IFPUG

  • Slides: 40
Download presentation
Puntos de Función 1

Puntos de Función 1

Plan • Visión general • IFPUG ØFrontera de la aplicación ØTransacciones ØDatos 2

Plan • Visión general • IFPUG ØFrontera de la aplicación ØTransacciones ØDatos 2

PF - Visión general Objetivo: traducir en un Número el tamaño de la funcionalidad

PF - Visión general Objetivo: traducir en un Número el tamaño de la funcionalidad que brinda un producto de software • Desde el Punto de vista del usuario • Suma ponderada de características del producto: Transacciones Ø Nro. Entradas Externas Ø Nro. Salidas Externas Ø Nro. Consultas Exts. (EI- External Input) (EO- External Output) (EQ- External in. Quiry) Datos Ø Nro. Archivos Int. Lógicos Ø Nro. Arch. Interfaz Externa (ILF- Internal. Logical File) (EIF-External Interface File) 3

Modelo para contar PF Frontera de la aplicación EI Archivos Lógicos Internos (ILF) EQ

Modelo para contar PF Frontera de la aplicación EI Archivos Lógicos Internos (ILF) EQ No mantenidos por la aplicación EO datos derivados y/o afecta comportamiento Archivos de Interfaz Externos (EIF) transacciones PF = 14 Características Generales de la Aplicación datos PFSA x Factor de Ajuste 4

Estandarización por IFPUG Factores de ajuste Ø Ø Ø Ø comunicaciones de datos procesamiento

Estandarización por IFPUG Factores de ajuste Ø Ø Ø Ø comunicaciones de datos procesamiento distribuido consideraciones de performance configuración operacional altamente utilizada entrada de datos on-line eficiencia para el usuario final (diálogos interactivos) actualización on-line y respaldo y recuperación procesamiento interno complejo tasa de transacciones reusabilidad facilidad de instalación facilidad de operación uso en múltiples sitios facilitar el cambio 5

Visión del Cliente-Usuario Ø No todo archivo físico o tabla se traduce en un

Visión del Cliente-Usuario Ø No todo archivo físico o tabla se traduce en un ILF (o EIF) Ø No todo archivo o tabla tiene por qué ser un ILF o EIF (archivos transitorios o de trabajo NO se cuentan) Ø Una transacción que ocurre en múltiples entradas físicas (archivo de transacciones o pantallas, con idéntica lógica de procesamiento, se considera como una sola transacción Ø Un mismo reporte físico, pantalla o archivo de salida pueden corresponder a más de un EO/EQ Ø Reordenar o reacomodar los datos no se considera como lógica de procesamiento única 6

Frontera de la Aplicación • Define lo que es “externo” a la aplicación •

Frontera de la Aplicación • Define lo que es “externo” a la aplicación • Interfaz entre lo “interno” y el “mundo exterior” • Se puede concebir como una “membrana” que atraviesan los datos procesados por las transacciones (EI, EO, EQ) • Encierra los archivos lógicos mantenidos por la aplicación(ILF) • Asiste en la identificación de los archivos lógicos referenciados pero no mantenidos por la aplicación (EIF) • Depende de la visión del negocio y externa del usuario • Es independiente de consideraciones técnicas o de implementación 7

Frontera de la Aplicación (2) Usuario 1 Contabilidad Fronteras definidas a partir de la

Frontera de la Aplicación (2) Usuario 1 Contabilidad Fronteras definidas a partir de la visión del negocio RR. HH. Ventas ¿cómo impactaría en la cuenta total de PF considerar esta otra frontera? 8

Frontera de la Aplicación (3) • Incide en la cuenta total de PF Ø

Frontera de la Aplicación (3) • Incide en la cuenta total de PF Ø al partir una aplicación se incrementan los PF totales porque los ILF se cuentan una vez como tales (por lo menos) y también se cuentan como EIF • Se determina a partir de la visión de usuario basada en áreas funcionales separadas y NO en consideraciones técnicas Ø una aplicación Cliente/Servidor es una unidad; la frontera debe englobar a ambos: Cliente y Servidor Ø una aplicación que se extiende para que funcione en Internet no se puede (por eso solo) considerar como dos aplicaciones a los efectos de los PF • Desconfiar de la frontera si: Ø no se identifican EIF Ø hay demasiados EIF o un mismo archivo es ILF en varias aplics. 9

Contar Transacciones Pasos: • Identificar transacciones • Asignar a cada un tipo (EI, EO,

Contar Transacciones Pasos: • Identificar transacciones • Asignar a cada un tipo (EI, EO, EQ) • Identificar la cantidad de DET y FTR • Asignar a cada un valor de complejidad (Alta, Media, Baja) en función de la cantidad de DET y FTR Definiciones: • Data Element Type (DET): Ø es un campo único (no repetitivo) reconocible por el usuario • File Type Referenced (FTR): Ø es un tipo de archivo al que se hace referencia en una transacción; tiene que ser un ILF o EIF 10

Tipos de transacciones Definiciones: • EI (External Input) - Entrada Externa Ø Proceso elemental

Tipos de transacciones Definiciones: • EI (External Input) - Entrada Externa Ø Proceso elemental en el que datos cruzan la frontera de la aplicación de afuera hacia adentro. La intención primordial es mantener uno o más ILF y/o alterar el comportamiento del sistema • EO (External Output) - Salida Externa Ø Proceso elemental en el que datos derivados a partir de uno o más ILF o EOF cruzan la frontera de adentro hacia fuera. Un EO puede actualizar un ILF o alterar el comportamiento del sistema. • EQ (External Query) - Consulta Externa Ø Proceso elemental en el que datos o información de control cruzan la frontera de adentro hacia fuera. NO incluye datos derivados y NO mantiene ningún ILF y NO altera el comportamiento del sistema 11

Proceso Elemental Definición: • Es la mínima unidad de actividad que tiene un significado

Proceso Elemental Definición: • Es la mínima unidad de actividad que tiene un significado para el Usuario Ø debe ser autocontenido, no requiere de otra actividad para que adquiera significado Ø debe dejar al sistema en un estado consistente Ejemplo: si el usuario desea agregar un empleado, puede requerir incorporar: Ø nombre Ø fecha de ingreso Este proceso Ø CI elemental se completa Ø sueldo al ingresar todos los Ø estado civil datos requeridos Ø fecha de nacimiento 12

Tipos de Transacciones - Resumen IP= Intención Primordial O= Opcional 13

Tipos de Transacciones - Resumen IP= Intención Primordial O= Opcional 13

Proceso en Transacciones p=posible p*=uno por lo menos debe estar presente 14

Proceso en Transacciones p=posible p*=uno por lo menos debe estar presente 14

Transacciones - Unicidad Se cuenta si se cumple al menos una de: • Para

Transacciones - Unicidad Se cuenta si se cumple al menos una de: • Para EI: Ø lógica distinta de otras EI Ø el conjunto de DET distinto del de otras EI Ø conjunto de ILF o EIF distinto del de otras EI • Para EO, EQ: Ø lógica distinta de otras EO o EQ Ø el conjunto de DET distinto del de otras EO o EQ Ø conjunto de ILF o EIF distinto del de otras EO o EQ 15

Complejidad de Tr - Número de FTR • Contar un FTR por cada ILF

Complejidad de Tr - Número de FTR • Contar un FTR por cada ILF mantenido • Contar un FTR por cada ILF o EIF leído durante el proceso del EI • Contar sólo un FTR por cada ILF que es leído y mantenido Ejemplo: Retiro de una cuenta bancaria ILF en la aplicación: Ø Cuenta Ø Movimientos Ø Cotizaciones dólar El proceso de retiro lee la cuenta, verifica saldo , graba movimiento y actualiza la cuenta. 2 FTR 16

Complejidad de Tr - Número de DET • Contar un DET por cada campo

Complejidad de Tr - Número de DET • Contar un DET por cada campo reconocible por el usuario, no repetido, que entra o sale de la aplicación atravesando su frontera y es requerido para completar el EI • No contar campos leídos o derivados por la aplicación y almacenados en un ILF si los campos no cruzaron la frontera • Contar un DET por la posibilidad de que el sistema envíe un mensaje fuera de la frontera de la aplicación para indicar un error , confirmar que el proceso está completo o verificar si el proceso debiera continuar • Contar un DET por la posibilidad de especificar una acción, mismo si hay múltiples métodos para invocar el mismo proceso lógico 17

Complejidad de EI - Número de DET Ejemplo 1 - agregar un empleado con

Complejidad de EI - Número de DET Ejemplo 1 - agregar un empleado con los datos: Ø Ø nombre fecha de ingreso CI fecha de nacimiento 4 DET Ejemplo 2 - ingreso de datos de factura de proveedor: Ø Ø código proveedor (E) nombre proveedor (S) fecha factura (E) importe total (E) ° * ( código artículo ° precio unitario ° cantidad ° importe) (E) 8 DET 18

Complejidad de Tr – Nro. de DET NO CONTAR: • Campos recuperados o derivados

Complejidad de Tr – Nro. de DET NO CONTAR: • Campos recuperados o derivados por el sistema y almacenados en un ILF por el proceso elemental, si no cruzaron la frontera de la aplicación Ejemplo: Al imprimir cheques, el registro en el archivo se marca para no volver a imprimirlo Esta marca NO se cuenta como DET • Literales Ejemplo: Los títulos (si son fijos) no se cuentan como DET • Variables generadas por el sistema relacionadas con el paginado o fecha y hora Ejemplos: Ø Ø nros. de página información de posicionamiento (filas 32 a 56 de 781) Comandos para paginar (anterior, siguiente, barra de posicionamiento) Fecha y hora 19

Caracterización de la complejidad Para EI 0 a 1 FTR 2 FTRs 3 o

Caracterización de la complejidad Para EI 0 a 1 FTR 2 FTRs 3 o más FTRs Para EO/EQ 0 a 1 FTR 2 a 3 FTRs 4 o más FTRs 1 a 4 DET 5 a 15 DET 16 o más DET Baja Media Alta 1 a 5 DET 6 a 19 DET 20 o más DET Baja Media Alta 20

Contribución de Transacciones  Complejidad Tipo de Transacción External Input (EI) External Output (EO)

Contribución de Transacciones Complejidad Tipo de Transacción External Input (EI) External Output (EO) External in. Quiry (EQ) Baja Media Alta 3 4 6 4 3 5 4 7 6 21

Contribución de Transacciones Ejemplo - Aplicación integrada por: • Alta cliente (#cliente, nombre, dirección)

Contribución de Transacciones Ejemplo - Aplicación integrada por: • Alta cliente (#cliente, nombre, dirección) • Listado de clientes (#cliente, nombre, dirección) • Consulta de la cantidad de clientes existentes • un único ILF (Clientes) Transacción Tipo Nivel Complejidad Cuenta Alta Cliente EI EQ EO Baja 3 3 4 10 Listado Clientes Cantidad Clientes Total de Contribución de Transacciones: 22

Consulta de Empleados Empleado Sistema de RRHH Tareas Asignaciones Informes Ayuda Lista de Empleados

Consulta de Empleados Empleado Sistema de RRHH Tareas Asignaciones Informes Ayuda Lista de Empleados Apellido Nombre CI Sueldo Pérez Juan 1. 234. 567 -8 10. 000 Martínez Pedro 2. 345. 678 -9 20. 000 Fernández María 3. 456. 789 -0 30. 000 Giménez Ana 4. 567. 890 -1 40. 000 Detalle Núcleo Familiar Cancelar 23

Consulta de Empleados Archivo Empleados: (CI, apellido, nombre, sueldo) • EQ • 1 FTR

Consulta de Empleados Archivo Empleados: (CI, apellido, nombre, sueldo) • EQ • 1 FTR • DET: Ø Nombre y Apellido (nombre) Ø CI Ø Sueldo Ø Acciones (Detalle, Núcleo Familiar, Cancelar) • Complejidad: Baja • Contribución: 3 PF 24

Consulta Implícita La modificación de datos del empleado es incómoda si no parte de

Consulta Implícita La modificación de datos del empleado es incómoda si no parte de los datos que existen. El usuario no pidió una consulta de los datos, sin embargo la espera. ¿Cómo considerarla? EQ Si ya está prevista la consulta del empleado ¿se debe contar dos veces? 25

Archivo para otra aplicación Al fin del día, la información de los cheques impresos

Archivo para otra aplicación Al fin del día, la información de los cheques impresos por la aplicación de RRHH se envía a la aplicación Contable usando un archivo de texto Archivos involucrados: Ø Cheque (#cheque, importe, banco, cuenta, orden) Ø Cheque_txt (linea) Ø ¿Es un proceso elemental? Ø En caso afirmativo, ¿de qué tipo y complejidad? EQ , 1 FTR, 5 DET, Baja 26

Datos 27

Datos 27

Modelo para contar PF Frontera de la aplicación EI Archivos Lógicos Internos (ILF) EQ

Modelo para contar PF Frontera de la aplicación EI Archivos Lógicos Internos (ILF) EQ 14 Características Generales de la Aplicación EO datos derivados y/o afecta comportamiento Archivos de Interfaz Externos (EIF) transacciones PF = datos PFSA x Factor de Ajuste 28

Contar Datos Pasos: • Identificar Archivos • Asignar a cada uno un tipo (ILF,

Contar Datos Pasos: • Identificar Archivos • Asignar a cada uno un tipo (ILF, EIF) • Identificar la cantidad de RET y DET • Asignar a cada uno un valor de complejidad (Alta, Media, Baja) en función de la cantidad de RET y DET Definiciones cortas: • Data Element Type (DET): Ø es un campo único (no repetitivo) reconocible por el usuario (ya lo habíamos visto al contar funciones) • Record Element Type (RET): Ø es un subconjunto de campos de un archivo, reconocible como tal por el usuario 29

Tipos de Archivos Internal Logical File (ILF) • Es un grupo de datos o

Tipos de Archivos Internal Logical File (ILF) • Es un grupo de datos o de información de control, lógicamente relacionado, identificable por el usuario y mantenido dentro de la frontera de la aplicación. External Interface File (EIF) • Es un grupo de datos o de información de control, lógicamente relacionado, identificable por el usuario, referenciado por la aplicación, pero mantenido fuera de la frontera de la aplicación. Nota: Un EIF para una aplicación tiene que ser un ILF para alguna otra. 30

Record Element Type (RET) • 2 tipos de subgrupos: Ø Opcionales - al crear

Record Element Type (RET) • 2 tipos de subgrupos: Ø Opcionales - al crear una instancia de los datos, puede no estar presente ninguno Ø Obligatorios - el usuario debe ingresar los datos de al menos un subgrupo obligatorio Ejemplo: Aplicación de RRHH. Empleado tiene datos generales y además puede ser mensual o jornalero. Adicionalmente, puede tener personas a su cargo (núcleo familiar). RET: Ø Mensual (incluyendo generales) - obligatorio Ø Jornalero (incl. generales) - obligatorio Ø Núcleo Familiar - opcional Nota: Los subgrupos no necesariamente son disjuntos 31

Data Element Type (DET) • Contar un DET por cada campo no repetitivo, reconocible

Data Element Type (DET) • Contar un DET por cada campo no repetitivo, reconocible por el usuario, que se recupera o mantiene desde ILF o EIF a través de un proceso elemental Ejemplos: Ø Número de cuenta que se almacena en varios campos cuenta como 1 (un) DET Ø Imagen previa y posterior de un archivo con 10 campos, para auditoría, cuenta como 2 DET (uno por la previa y otro por la posterior) Ø El registro de fecha y hora de alta/modificación en un archivo, cuenta como un DET si fue requerido por el usuario 32

Caracterización de la complejidad Para ILF/EIF 1 RET 2 a 5 RET 6 o

Caracterización de la complejidad Para ILF/EIF 1 RET 2 a 5 RET 6 o más RET 1 a 19 DET 20 a 50 DET 51 o más DET Baja Media Alta Contribución de datos Complejidad Tipo de Archivo Baja Media Alta Int. Logical File (ILF) Ext. Interface File(EIF) 7 5 10 7 15 10 33

Contribución de Datos Ejemplo - Aplicación mantiene los archivos: • • • Tarea (

Contribución de Datos Ejemplo - Aplicación mantiene los archivos: • • • Tarea ( #tarea, nom_tarea, escala) Descripcion_Tarea ( #tarea, #linea, l_descrip) Empleado ( CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea) ILF identificados: Tarea, Empleado Tarea: 2 RET - Tarea, Descripcion_Tarea 5 DET - #tarea, nom_tarea, escala, #linea, l_descrip Empleado: 1 RET 5 DET - CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea 34

Contribución de Datos (cont. ) Archivo Tipo Nivel Complejidad Cuenta Empleado ILF Baja 7

Contribución de Datos (cont. ) Archivo Tipo Nivel Complejidad Cuenta Empleado ILF Baja 7 7 Tarea Total de Contribución de Datos : 14 35

Usuario Definición: • Un usuario es cualquier persona que especifica Requerimientos Funcionales de Usuario

Usuario Definición: • Un usuario es cualquier persona que especifica Requerimientos Funcionales de Usuario y/o cualquier persona o cosa que se comunica o interactúa con el software Ejemplos: • Para la aplicación de RRHH incluye al personal departamento de RRHH que interactúan con la aplicación y a la aplicación contable que interactúa para recibir la información de los asientos contables correspondientes a la liquidación de sueldos 36

Contribución de Datos – Guía • ¿Los datos son un grupo lógico que soporta

Contribución de Datos – Guía • ¿Los datos son un grupo lógico que soporta requerimientos del usuario? • Una aplicación puede usar un mismo ILF o EIF en múltiples procesos, pero el archivo se cuenta una sola vez • Un mismo archivo no se puede contar a la vez como ILF y EIF; si cumple ambos criterios, contarlo como ILF • Si un grupo de datos no fue contado como ILF ni EIF, contar sus DET para el ILF o EIF que incluye al grupo • No asumir que un archivo físico, tabla o clase de objetos corresponde a un archivo lógico desde el punto de vista del usuario • No asumir que todo archivo físico debe ser contado o incluido como parte de un ILF o EIF 37

Contribución de Datos – Guía(2) 1. ¿Dónde se mantienen los datos, dentro o fuera

Contribución de Datos – Guía(2) 1. ¿Dónde se mantienen los datos, dentro o fuera de la aplicación? 1. Archivos lógicos mantenidos por más de una aplicación se consideran como ILF al contar cada una 2. Recordar que en el caso anterior, en cada aplicación sólo se consideran los DET que usa y estos se determinan desde el punto de vista de cada aplicación 38

Contribución de Datos – Ejemplo 1 Usuario desea poder: • • Ingresar, consultar y

Contribución de Datos – Ejemplo 1 Usuario desea poder: • • Ingresar, consultar y listar los datos de tareas La información relativa a las tareas consiste en: • • #tarea, nom_tarea, grado (#tarea, nro_linea, linea_descripcion) dos grupos de datos (tarea y descripción) (1) ILF con (2) RET 5 DET (#tarea se cuenta sólo una vez) 39

Contribución de Datos – Ejemplo 2 Para la aplicación de RRHH el Usuario desea:

Contribución de Datos – Ejemplo 2 Para la aplicación de RRHH el Usuario desea: • Poder restringir el acceso a cada pantalla a ciertas personas • • Poder cambiar estas restricciones Emitir un listado con todos los agregados o cambios en las restricciones de acceso que incluya los datos: • • • Id de usuario que hizo el cambio • Fecha y hora del cambio Id de pantalla cuya seguridad se cambió o agregó La Id de usuario y los datos de seguridad anteriores y posteriores 40