Metodología Gartner

Agenda – FUNCTION POINTs

• Objetivos TELECOM
• Conceptos Generales
• Proceso de medición
• Objetos lógicos
• Resumen
• Preguntas
• Ejemplos

2
 FUNCTION POINTs
OBJETIVOS TELECOM

Telecom no tenía hasta hoy un estándar de estimación para medir los

trabajos en IT:
 Servicios profesionales de proveedores
 Calcular y Comparar productividad entre proveedores.
 Medir productividad vs estándar del mercado

Telecom incluirá en los Nuevos Contratos estándar con los proveedores

la metodología “Gartner FFPA-I” lo que permitira:

 Dimensionamiento funcional del software

 Medición objetiva de la “cantidad de funcionalidades” producidas.
Productividad definida como la relación entre Function Point y la
correspondiente cantidad de días-hombre a cargo del Proveedor.

3
 Function Points

 La metodología de “Function Points” es una forma estándar de medir

las funcionalidades que le suministra una aplicación al usuario.
 Es independiente de la tecnología, proceso y plataforma utilizada.

 Es lineal, escalable y comparable

o 1000 FP = 2 x 500 FP
o 3000 FP codificados en COBOL son funcionalmente equivalentes a 3000 FP
codificados en Java

 Puede ser utilizado en diferentes contextos:

o Medición de un nuevo proyecto o requerimiento evolutivo.
o Medición de un sistema en producción.

4
 Proceso de la medición utilizando F.P.

 Identificar los Limites o Fronteras de la aplicación

 Identificar los Objetos lógicos (procesos y datos)

 Identificar la Complejidad de cada Objetos lógicos

 Calcular el Aporte funcional en F.P. de cada Objeto lógico

5
 Límite de la aplicación
 Definir el limite y el alcance permite medir todas las funcionalidades
que provee un sistema en particular.
 El límite o frontera de la aplicación analizada, lo separa de las
aplicaciones externas (otros sistemas de la organización).

6
 Objetos lógicos
 Datos:
o A1: Tablas lógicas internas (0-50; >50)
o A2: Tablas lógicas externas (0-50; >50)
 Inputs:
o B1: Formularios/pantallas/Inputs lógicos (<5;
5-15; >15)
o B2: Inputs desde otras aplicaciones (<5; 5-15;
>15)
o B3: Lista de elementos seleccionables (no se
encuentra diferenciado) 7
o B4: Pantallas/Formularios lógicos de consulta
(<6; 6-20; >20)
o B5: Procesos Background inicializados por el
usuario (no se encuentra diferenciado)
 Outputs:
o C1: Reportes (<6; 6-20; >20)
o C2: Outputs hacia otras aplicaciones (<6; 6-
20; >20)
 Reglas de negocio internas
o D1: Cálculos internos
o D2: Inferencias internas
 Configuración
 Listas
 Datos
 Reglas
 Almacenamiento de Datos Lógicos Internos – A.1

 Es la funcionalidad provista al usuario por el almacenamiento

de datos dentro de la aplicación.
 El sistema en cuestión, es el “dueño” y responsable del
mantenimiento de los datos.
 Se cuentan solo las tablas lógicas que son creadas o
“estructuralmente” modificadas (agregado/borrado de campos
de datos) por el pedido funcional.
 Siempre deberá calcularse el tamaño total de objeto para la
estimación.

8
 Acceso de Datos Lógicos Externos – A.2
 Es la funcionalidad provista al usuario por el acceso a datos de
otras aplicaciones.
 El sistema en cuestión, no es el “dueño” de los datos.
 Se cuentan solo los datos lógicos que son leídos (consultados)
por el pedido funcional.
 Siempre deberá calcularse el tamaño total de objeto para la
estimación.

9
 Inputs lógicos de formularios, pantallas – B.1
 Ingreso de datos al sistema a través de una pantalla de usuario.
 Actualiza bases internas o dispara procesos internos.
 Incluye la lógica necesaria para interpretar los datos con la
validaciones básicas de sintaxis y semántica.
 Para determinar la complejidad se contabilizan la cantidad de
elementos de datos que entran al sistema.
 Siempre se consideran todos los datos de la pantalla.

10
 Inputs desde otras aplicaciones – B.2

 Ingreso de datos al sistema a través de una fuente externa.

 Actualiza una base interna o dispara procesos internos.
 Incluye la lógica necesaria para interpretar los datos con la
validaciones básicas de sintaxis y semántica.
 Para determinar la complejidad se contabilizan la cantidad de
elementos de datos que entran al sistema.
 Siempre se consideran todos los elementos de datos.

11
 Lista de items seleccionables -
B.3
 Estructuras de datos del negocio utilizadas para permitir una elección
entre un conjunto de opciones (lista de valores).
 Son listas desplegables, cuadros de selección, etc. que proporcionan uno o
más elementos para que el usuario seleccione.
 Para determinar la complejidad se evalúa la cantidad de listas agregadas

12
 Consulta de pantallas/formularios lógicos – B.4
 Extracción de datos del sistema a través de una pantalla de
consulta sin ningún tratamiento especial.
 No se actualizan archivos internos (Read only)
 Para determinar la complejidad se contabiliza la cantidad de
datos que entran al sistema para la consulta (filtro) y los datos
que salen por pantalla.
 Siempre se consideran todos los elementos de datos de la
pantalla.

13
 Procesos internos – B.5

 Procesos background que modifican los datos de la aplicación dejándola

en un estado consistente.
 Los procesos Batch suelen ser contados como B5
 Un solo proceso batch complejo puede incluir más de un B5; se debe
observar las transacciones completas en forma individual desde un
punto de vista del proceso del negocio.
 El procesamiento puede ser inicializado por una persona (con un botón
o una selección de menú) o por inputs automáticos (relojes, schedulers)
o por eventos específicos

14
 Outputs del sistema - Reportes – C.1

 Son reportes que salen del sistema en cualquier tipo de

soporte.
 Este tipo de objeto incluye todos los procesos necesarios
para calcular y mostrar los datos, así como también la
lógica de extracción (Ej. Sumas parciales y totales,
promedios, multiplicaciones, etc).
 Para calcular la complejidad, se sumara la cantidad de
elementos de datos del mismo.

15
 Outputs del sistema hacia otras aplicaciones – C.2

 Salidas hacia otros aplicativos sin importar el tipo de

soporte. Puede ser en forma batch u on line.
 La complejidad estará determinada por la cantidad de
datos que salen del sistema.
 Siempre se consideran todos los elementos de datos.

16
 Cálculos internos – D.1
 Una función de cálculo interno obtiene un resultado
mediante la realización de operaciones matemáticas en uno
o más datos.
 La función de cálculo interno debe ser un cálculo de
negocio, reconocible por el usuario
 Para determinar la complejidad se contabilizan cada
función de cálculo por separado. Ejemplos: cálculo del
ingreso total, cálculo de la tasa de pago máximo, cálculo del
total de tiempo de conversación, etc.

17
 Inferencias internas – D.2

 Una función de inferencia interna obtiene un resultado a través

de la evaluación de uno o más elementos de datos.
 La función de inferencia interna debe ser una regla de negocio,
reconocible por los usuarios.
 Para determinar la complejidad se contabilizan cada función
de inferencia por separado. Ejemplos: Validar categoría de
cliente; Validar Categoría de abono y tipo de línea, Evaluar
deuda de un cliente

18
 Configuration Points
 La metodología de medición también fue desarrollada con el fin de medir
actividades de configuración CP (Configuration Points) .
 La configuración permite entregar o activar funcionalidades sin crear ni
modificar objetos lógicos (archivos lógicos, inputs, outputs, consultas)
 La metodología permite medir las actividades de configuración de acuerdo a
una valorización de tres tipos de objetos lógicos: datos, listas lógicas y reglas.

Objeto Descripción
• Conjunto de atributos lógicos, homogéneos desde el punto de vista del
usuario y de la operación.
Listas lógicas • Muchos atributos pertenecen a una sola lista lógica si se encuentran
lógicamente vinculados entre ellos y son procesados como un solo objeto.

• Es el número de atributos lógicos que son valorizados por la actividad de

configuración.
Datos • Son los atributos de la lista lógica que pueden ser reconocidos por los
usuarios
• Son las diferentes reglas de tratamiento/manejo de los datos definidos a
Reglas través de la configuración
• Las reglas controlan el comportamiento de la aplicación.
19
Actividades medibles y no medibles

20
21
 Resumen
 Datos:
o A1: Tablas lógicas internas (0-50; >50)
o A2: Tablas lógicas externas (0-50; >50)
 Inputs:
o B1: Formularios/pantallas/Inputs lógicos (<5;
5-15; >15)
o B2: Inputs desde otras aplicaciones (<5; 5-15;
>15)
o B3: Lista de elementos seleccionables (no se
encuentra diferenciado)
o B4: Pantallas/Formularios lógicos de consulta 22
(<6; 6-20; >20)
o B5: Procesos Background inicializados por el
usuario (no se encuentra diferenciado)
 Outputs:
o C1: Reportes (<6; 6-20; >20)
o C2: Outputs hacia otras aplicaciones (<6; 6-
20; >20)
 Reglas de negocio internas
o D1: Cálculos internos
o D2: Inferencias internas
 Configuración
 Listas
 Datos
 Reglas

22
Estimaciones

23
Estimaciones (Continuación)

24
Estimaciones (Continuación)

25
Estimaciones (Continuación)

26
 Nuestro impacto

Esperamos que durante las capacitaciones y puesta a punto del modelo haya
retroalimentación y podamos identificar los aspectos fuertes y débiles del
modelo para cada aplicación y tecnología. Debemos iniciar las estimaciones en
FP desde hoy.

Que hay en juego:

Compensaciones económicas: Como en todo modelo de estimación
hay dinero en juego. Telecom nos medirá con parámetros de la
industria en cada tecnología.
Reputación: Debemos demostrar que podemos adaptarnos a un
nuevo paradigma manteniendo nuestro nivel de performance.
Exposición: Todas las consultoras están en las mismas condiciones y
ahora Telecom tendrá una herramienta de comparación.
Las estimaciones se asemejan a un modelo llave en mano. Telecom
pagará hasta el valor fijado por la consultora.
27
 Aspectos Importantes

Hay que considerar los siguientes factores en nuestras

estimaciones y durante el ciclo de vida del requerimiento:

 Metodología Rápida
 Funcionalidad visible por el usuario
 Nuestra Documentación (DIN - Estimaciones)
 Documentación y evidencias del cliente
 Experiencia y contraste con el modelo actual
 Cambios de definiciones
 Metodologías Agiles
 Hs no medibles
 Excepciones detectadas o aplicables

28
¿Dudas? ¿Preguntas?

29
30