Ayuda para GPS

Este archivo forma parte integral de la obra Gestión de Proyectos de Software de Juan Grompone. Fue diseñado como ayuda de la planilla de cálculo GPS. En el libro se encuentra, además, el estudio de casos. En la planilla están programadas las funciones. En este archivo existe información sobre las siguientes áreas temáticas:

La métrica de Halstead

Complejidad ciclomática (McCabe)

Constructive Cost Model (COCOMO)

Metodología de los Puntos Funcionales

La metodología GPM

El modelo de Putnam

Las funciones de la planilla GPS

Acerca de este archivo

Todos los derechos reservados, La Flor del Itapebí, Montevideo, 1996.

ISBN 9974-592-05-4


La métrica de Halstead

Halstead, hacia fines de la década del 70, propuso una métrica derivada de la teoría general de la complejidad y de algunas hipótesis adicionales acerca de la producción de la programación. Si bien sus ideas no han tenido aceptación práctica, son una referencia obligada para comprender las ideas que manejan otras teorías.

Para Halstead un programa es una sucesión de órdenes elementales. A su vez, cada orden posee operandos y operadores. Estas cantidades definen los diferentes elementos de su métrica.

Algunas de sus expresiones se asocian con el contenido de información de Shannon, con la complejidad matemática de problemas y con otras ecuaciones similares. Por esta razón -más que por la presunta justificación de Halstead- esta métrica ha sido exitosa.

Halstead introduce muchos otros conceptos, basados en una visión psicológica del proceso de elaboración de la programación. Dentro de ellos se destacan:

Vocabulario

Largo

Largo teórico

Volumen

Dificultad

Esfuerzo

Tiempo de desarrollo

Número de errores

La teoría de Halstead, contemplada con los ojos de la presente década, se presenta como una colección de arbitrariedades sin fundamento. No obstante este hecho, todavía hoy continúa siendo citada y analizada. Ha sido el esfuerzo teórico más inspirador de todos cuantos se han realizado.


Vocabulario de un programa (Halstead)

n =  n1  + n2

donde:

n1 : es el número de operadores diferentes del programa

n2:: es el número de operandos diferentes del programa


Largo de un programa (Halstead)

N = N1 + N2

donde:

N1: es el número total de operadores que aparecen en el programa

N2: es el número total de operandos que aparecen en el programa


Largo teórico de un programa (Halstead)

Se supone que es el largo de un programa bien estructurado es:

donde:

n1 : es el número de operadores diferentes del programa

n2 : es el número de operandos diferentes del programa


Volumen de un programa (Halstead)

Es la cantidad de elecciones que es necesario realizar para escribir el programa!

donde:

N = N1 + N2  es el largo del programa

n1 : es el número de operadores diferentes del programa

n2 : es el número de operandos diferentes del programa

N1 : es el número total de operadores que aparecen en el programa

N2 : es el número total de operandos que aparecen en el programa


Dificultad de un programa (Halstead)

Se supone que tiene que ver con la dificultad de diseño de un programa.

donde:

n1 : es el número de operadores diferentes del programa

n2 : es el número de operandos diferentes del programa

N2 : es el número total de operandos que aparecen en el programa


Esfuerzo de un programa (Halstead)

donde:

V: es el volumen del programa

D: es la dificultad del programa

N = N1 + N2   es el largo del programa

n1 : es el número de operadores diferentes del programa

n2 : es el número de operandos diferentes del programa

N1 : es el número total de operadores que aparecen en el programa

N2 : es el número total de operandos que aparecen en el programa


Tiempo de desarrollo de un programa (Halstead)

Es la suma de la cantidad de momentos de tiempo psicológico empleados en el esfuerzo total, en segundos:

donde:

K: es el esfuerzo del programa

V: es el volumen del programa

D: es la dificultad del programa

N = N1 + N2  es el largo del programa

n1 : es el número de operadores diferentes del programa

n2 : es el número de operandos diferentes del programa

N1 : es el número total de operadores que aparecen en el programa

N2 : es el número total de operandos que aparecen en el programa


Número de errores de un programa (Halstead)

donde:

V: es el volumen del programa

N = N1 + N2   es el largo del programa

n1 : es el número de operadores diferentes del programa

n2 : es el número de operandos diferentes del programa

N1 : es el número total de operadores que aparecen en el programa

N2 : es el número total de operandos que aparecen en el programa


Complejidad ciclomática (McCabe)

Una métrica abstracta que ha tenido importancia en la ingeniería del software es la complejidad ciclomática de McCabe. Para este autor, la complejidad de un programa se basa en la estructura lógica de los programas.

Esta métrica se basa solamente en el flujo de control de un programa. Si se abstrae todo el código del programa y solamente tenemos en cuenta los puntos de bifurcación de la secuencia de instrucciones, podemos dibujar un grafo que describe la estructura lógica interna. La métrica actúa sobre este grafo.

Sea e en número de caminos del grafo lógico del programa. Sea n el número de nodos del grafo. La complejidad ciclomática se define como:

c = e - n + 1

Este valor se lo puede interpretar como el número de decisiones, más una, que tiene el programa. Según McCabe un módulo bien estructurado tiene entre 3 y 7 de complejidad. Considera que 10 es el límite superior razonable que se puede esperar.


Medida de la cantidad de líneas de código

Es universal emplear como unidad de medida:

KLOC

que significa miles de líneas de programación objeto, finales, sin comentarios. Es usual aclarar, como información complementaria, el lenguaje en el cual se han escrito estas líneas.


Metodología COCOMO
Constructive Cost Model (COCOMO)

El modelo COCOMO (COnstructive COst MOdel), modelo constructivo de los costos, es el modelo más exitoso dentro de las métricas que emplean el número de líneas de código como elemento fundamental. Fue creado por Barry H. Boehm hacia 1980. Se basaba en el estudio de casos reales y su posterior análisis. Sus principales características son:

  es un modelo estático: estudia resultados globales

  emplea ecuaciones exponenciales de origen empírico

  emplea factores de costo como modificadores de ambiente

Su campo de aplicación son los proyectos realizados en lenguajes donde el concepto de línea de código es dominante, por ejemplo, en los sistemas de Tiempo Real.

La metodología COCOMO comprende diversos pasos que se deben recorrer ordenadamente:

1) Se toma como punto de partida conocido las KLOC del proyecto. Una de las dificultades mayores consiste en realizar esta estimación.

2) Se determina el tipo de proyecto considerado: Organic, Semidetached o Embedded.

3) Se calcula, mediante las ecuaciones empíricas suministrada por el modelo (Korg, Kemb o Ksd) el esfuerzo nominal Kn (en meses-persona).

4) Se estiman los 15 factores de costo considerados según las reglas del modelo. Se calcula el factor de ajuste f. Se calcula el esfuerzo ajustado K (en meses-persona).

5) Se aplican otras ecuaciones empíricas (Torg, Temb o Tsd), suministrada por el modelo, para obtener el tiempo nominal o sugerido Tn de desarrollo del proyecto (meses).

Mediante el esfuerzo y el tiempo de desarrollo se puede estimar el número de personas promedio que empleará el proyecto. En el diagrama que sigue se ilustran los pasos a seguir, desde la información de entrada al modelo hasta los resultados obtenidos.

El modelo se basa en ecuaciones y coeficientes empíricos que permiten, a partir del número de líneas de código a desarrollar, estimar los parámetros del proyecto.

Es interesante observar que el lenguaje de programación no es dato explícito que se emplee, tal como se verán en lo que sigue. También es interesante observar que la metodología exige que la estimación del número de líneas del proyecto se realice mediante técnicas que no forman parte de la metodología COCOMO.

A partir del tipo de proyecto y del número de líneas de código se obtiene el esfuerzo nominal del proyecto en meses-persona. Esta cifra debe ser ajustada por los factores de costo.

A los efectos de la normalización de tiempos, en el caso de desear convertir los datos a horas, días o semanas, el modelo considera las siguientes relaciones:

Un mes-persona son 152 horas de trabajo efectivas, a los efectos de tener en cuenta los días de licencia y de enfermedad. Un mes de trabajo tiene 19 días efectivos.


Proyecto Organic (COCOMO)
Proyecto Organic

El caso Organic se trata de un grupo pequeño de programadores expertos que desarrollan un proyecto en un ambiente que les es muy conocido. Esta es la situación habitual en los pequeños grupos de trabajo, en el trabajo de personas aisladas, estudiantes de cursos y situaciones similares. Usualmente el proyecto tiene un tamaño pequeño o mediano (decenas de miles de líneas de código).


Proyecto Embedded (COCOMO)
Proyecto Embedded

El caso Embedded se trata de un proyecto con condicionantes estrictas de todo tipo, que debe ser realizado con un costo determinado y entregado en una fecha precisa, para una plataforma determinada. Es un proyecto único que posiblemente no se repita y sobre el cual no existe experiencia previa. Usualmente se trata de un proyecto mediano o grande.


Proyecto Semidetached (COCOMO)
Proyecto Semidetached

El caso Semidetached se trata de una situación intermedia entre los casos extremos Organic y Embedded. Es claro que esta situación comprende la gran mayoría de los proyectos que se realizan en condiciones normales de los sistemas de información. En caso de dudas, éste debe ser el caso a aplicar.


Los factores de costo de COCOMO
Los factores de costo (COCOMO)

Los factores de costo son características del proyecto que modifican la estimación cruda del esfuerzo. Se determinan a partir de los siguientes conjuntos de atributos del proyecto:

Atributos del producto:

Exigencias de confiabilidad

Tamaño de la base de datos

Complejidad del producto

Atributos de la plataforma:

Exigencias de tiempo de ejecución

Exigencias de memoria

Obsolescencia de la plataforma

Capacidad de respuesta del ambiente

Atributos del equipo de trabajo:

Capacidad de los analistas

Experiencia en la aplicación

Capacidad de los programadores

Experiencia en la máquina lógica

Experiencia en el lenguaje de programación

Atributos del proyecto:

Empleo de técnicas modernas de programación

Empleo de herramientas

Exigencias de plazo de entrega

Cada atributo se debe evaluar en una escala entre 1 y 5. En algunos atributos es posible llegar al valor 6, en otros casos el valor 1, o aún el valor 2, carecen de interés. El valor 3 representa el caso promedio. Existen criterios para determinar el valor de cada atributo según se analiza en detalle en lo que sigue.

Para cada valor asignado, el atributo determina el valor de un factor de costo, que actúa como un coeficiente de ajuste. El ajuste completo se obtiene por el producto de todos los factores combinados. Como se puede experimentar fácilmente, colocando valores extremos en la planilla, los resultados pueden arrojar diferencias enormes en los factores de ajuste.

Cada factor de costo es identificado con un nombre simbólico que tiene importancia a los efectos del empleo de la planilla de cálculo. Estos nombres son los originales de Boehm y se indican entre paréntesis.


Exigencias de confiabilidad (COCOMO)
Exigencias de confiabilidad (RELY)

El valor 1 significa que los errores en el producto no tienen mayores consecuencias. El valor 3 significa que una falla provoca inconvenientes pero que son tolerables. El valor 5 significa que se exige confiabilidad máxima, porque existe posible riesgo de vida humana.


Tamaño de la base de datos (COCOMO)
Tamaño de la base de datos (DATA)

Este factor relaciona el tamaño de la base de datos con el tamaño del programa para manejarla. Se emplea una escala de tipo geométrico 10-100-1000 que determina los valores efectivos 2, 3 o 4, a aplicar. En forma cualitativa, el valor 1 significa una base de datos simple y sencilla de manejar; el valor 5 significa un diseño complejo con funciones de administración y recuperación importantes. La importancia de este punto tiende a ser disminuida por la aparición de nuevas tecnologías de manejadores de base de datos.


Complejidad del producto (COCOMO)
Complejidad del producto (CPLX):

El valor 1 significa que es un producto muy simple, con algoritmos sencillos. El valor 6 significa que es un producto extremadamente complejo. La mayoría de la programación para uso comercial puede ser catalogada como normal y asignar el valor 3.


Exigencias de tiempo de ejecución (COCOMO)
Exigencias de tiempo de ejecución (TIME)

El valor 3 indica que el proyecto tiene exigencias normales, los valores menores carecen de importancia. El valor 6 indica un manejo complejo de recursos, prototipos, simulaciones, validación y todo lo necesario para cumplir con las exigencias de tiempo.


Exigencias de memoria (COCOMO)
Exigencias de memoria (STOR)

El valor 3 significa que la optimización del uso de la memoria no es importante. El valor 6 significa que se han tomado medidas extraordinarias para reducir el empleo de memoria, se han realizado prototipos, simulación, validación y todo lo necesario.


Obsolescencia de la plataforma (COCOMO)
Obsolescencia de la plataforma (VIRT)

Este atributo caracteriza lo que sucederá durante el desarrollo y puesta en marcha del proyecto. El hecho que la plataforma (lógica o física) cambie a lo largo del proyecto agrega dificultades extraordinarias. El valor 2 indica que no esperan cambios. El valor 5 indica que es un elemento del proyecto el cambio de la plataforma y que este elemento deberá ser tenido en cuenta. Esta situación ocurre, por ejemplo, si el proyecto se extiende varios años en el tiempo.


Capacidad de respuesta del ambiente (COCOMO)
Capacidad de respuesta del ambiente (TURN)

Este parámetro mide la capacidad del ambiente de trabajo para simplificar el desarrollo. El valor 2 significa que se dispone de sistemas interactivos en los cuales es muy simple realizar cambios y nuevas versiones. El valor 5 significa que el sistema de desarrollo exige muchas horas para cada cambio, tal vez esperar hasta el otro día. Este atributo se vincula con la plataforma de trabajo y no con la plataforma objeto del desarrollo, es una observación que se debe tener en cuenta en los casos que no coincidan.


Capacidad de los analistas (COCOMO)
Capacidad de los analistas (ACAP)

Este atributo mide la capacidad técnica y habilidad de trabajo en equipo de los analistas del proyecto. No se trata de una calificación individual sino de la capacidad de cooperación, comunicación y de realización como conjunto.


Experiencia en la aplicación (COCOMO)
Experiencia en la aplicación (AEXP)

Este atributo mide la experiencia del equipo en la aplicación que se considera. El valor 1 significa menos de 4 meses de experiencia. En valor 2 significa un año de experiencia. El valor 3 (valor promedio) significa tres años de experiencia en la aplicación. El valor 5 significa más de 12 años de experiencia.


Capacidad de los programadores (COCOMO)
Capacidad de los programadores (PCAP)

Este atributo se aplica al equipo de programadores y no a las personas individuales. El valor 1 indica que existe un mala relación con los analistas y una pobre eficiencia de trabajo. El valor 5 indica la situación opuesta.


Experiencia en la máquina lógica (COCOMO)
Experiencia en la máquina lógica (VEXP)

Este atributo mide el conocimiento que se tiene de la máquina lógica sobre la cual se trabaja, no se trata del lenguaje de programación, el cual se tiene en cuenta en el atributo siguiente. El valor 1 significa menos de 1 mes de experiencia. El valor 2 significa unos 4 meses de experiencia. El valor 3 (valor promedio) significa un año de experiencia. El valor 4 significa más de 3 años.


Experiencia en el lenguaje de programación (COCOMO)
Experiencia en el lenguaje de programación (LEXP)

Este atributo mide el conocimiento del lenguaje de programación o de la herramienta que se emplea. El valor 1 significa menos de 1 mes de experiencia. El valor 2 significa unos 4 meses de experiencia. El valor 3 (valor promedio) significa un año de experiencia. El valor 4 significa más de 3 años.


Técnicas modernas de programación (COCOMO)
Empleo de técnicas modernas de programación (MODP)

Se consideran técnicas modernas: análisis y diseño top-down, la documentación estructurada, el desarrollo top-down, el control de calidad durante el desarrollo, el código estructurado y el manejo sistemático de bibliotecas de módulos. El valor 1 significa que no se usan estas técnicas. El valor 3 significa que existe una cierta experiencia en su empleo. El valor 5 indica que todas estas técnicas son práctica de rutina.


Empleo de herramientas (COCOMO)
Empleo de herramientas (TOOL)

Este atributo mide el uso de herramientas que mejoran el rendimiento del desarrollo. El valor 1 significa herramientas elementales, que no pasan de un nivel simple. El valor 3 significa que existen manejadores de bases de datos, depuradores de programa y herramientas interactivas. El valor 5 significa que existen herramientas especializadas para el proyecto.


Exigencias de plazo de entrega (COCOMO)
Exigencias de plazo de entrega (SCED)

Este atributo mide las exigencias de plazo de entrega comparadas con el tiempo nominal de proyecto que proponen las ecuaciones de COCOMO. De hecho, este modificador exige una cierta interacción en el cálculo. El valor 1 significa que existe un aumento de velocidad (realizar el proyecto en el 75% del tiempo nominal). El valor 2 supone un aumento moderado (realizar en 85%). El valor 4 supone que el proyecto se extenderá más de lo nominal (realizar el proyecto en un 130% del tiempo nominal). El valor 5 supone más del 160% del tiempo nominal. Es interesante observar que ambos extremos, acelerar o retardar el tiempo nominal, penalizan el esfuerzo del proyecto.


Normalización del IFPUG

La metodología de los Puntos Funcionales o Puntos de Función deriva de una propuesta, interna de IBM, realizada por Allan J. Albrecht en 1979. Esta metodología adquiere carácter público en 1981 y es revisada en 1984, fecha en la cual Albrecht introduce los modificadores. A partir de este momento gana aceptación creciente. Buena parte de su éxito se debe a que es una metodología normalizada. Debido a esta característica se puede esperar que personas diferentes, en países diferentes y con tecnologías de desarrollo diferentes obtengan resultado razonablemente coherentes.

La normalización es responsabilidad del International Function Point Users Group (IFPUG). Esta asociación de empresas usuarias es de libre afiliación y, además de la tarea de elaboración de la documentación normalizada, realiza reuniones periódicas, certifica técnicos y mantiene publicaciones regulares.

International Function Point Users Group

Blendonview Office Park

5008-28 Pine Creek Drive

Westerville, Ohio 43081-4899

Tel:	(614) 895 7130

Fax:	(614) 895 3466

El camino de la normalización fue largo y continúa como una actividad corriente.

El IFPUG fue formado en 1986. La primera normalización del IFPUG es de 1990.

La aceptación del IEEE es de 1992. El manual corriente es la versión 4.0, de Enero de 1994.


Metodología de los Puntos Funcionales

Esta métrica  pretende medir las funcionalidades que ve el usuario del sistema de información. Por esta razón se debería traducir al castellano como puntuación de las funcionalidades, pero es habitual llamarla Puntos Funcionales o Puntos Función.

Fue diseñada para sistemas de información clásicos y, hasta el momento, este es su único campo de aplicación. La métrica se basa en contar cinco funcionalidades básicas y luego aplicar modificadores que conducen a un factor de ajuste.

El procedimiento de trabajo para contar Puntos Funcionales requiere seguir una serie de pasos bien definida y normalizada:

1) Determinar el tipo de cálculo a realizar.

2) Identificar las fronteras del sistema.

3) Contar las funciones tipo datos.

4) Contar las funciones tipo transacciones.

5) Mediante las funciones básicas se calculan los Puntos Funcionales sin ajustar. (Ver las funciones de la planilla GPS).

6) A los efectos de tener en cuenta otros aspectos del proyecto, se evalúan las 14 características modificadoras:

Comunicaciones

Performance

Funciones distribuidas

Configuración muy usada

Frecuencia de transacciones

Entradas on-line

Eficiencia para el usuario

Actualización on-line

Procesamiento complejo

Reusabilidad

Facilidad de instalación

Facilidad de operación

Múltiples lugares

Facilidad de cambio

Cada una de estas características debe ser evaluada mediante una escala de 0 a 5. El valor típico o normal es 3, en algunos casos también 2 es un valor típico. A los efectos de la normalización, existen definiciones que permiten ajustar la cuenta de puntos a una práctica precisa. Cada punto asignado agrega un 1% a un factor de ajuste. De este modo se llega a la puntuación corregida de las funcionalidades:

7) Con estos modificadores se puede calcular el factor de ajuste y los Puntos Funcionales ajustados.

En los planes originales de Albrecht, esta medida servía como dato de un estimador empírico. Hoy ya no se lo considera más así y la noción de Puntos Funcionales se ha separado de toda metodología de estimación de esfuerzo.


Tipos de cálculo de Puntos Funcionales

El primer paso de aplicación de la metodología consiste en determinar en cuál de tres situaciones nos encontramos:

Un proyecto nuevo, a desarrollar o en desarrollo, total o parcial.

Ampliaciones de un proyecto existente y ya completado.

Replanteo de un proyecto existente y completado.

Las tres situaciones poseen interés. El caso del proyecto nuevo es la situación típica que se enfrenta todo jefe de proyecto. La ampliación de un proyecto que se hizo aplicando la metodología es, sin duda, el caso más simple de todos: se trabaja en un terreno conocido y se tienen cifras previas.

El replanteo de proyectos ya completados tiene una importancia muy especial en los casos de emigración de un sistema viejo, con funcionalidades no despreciables y que ha desempeñado un buen trabajo durante años (heritage software), a una tecnología nueva. En este caso, el replanteo de lo hecho mediante la métrica de los Puntos Funcionales permite obtener una información muy valiosa a los efectos de la evaluación de la emigración, tal como se ve en los casos de estudio.


Las fronteras del sistema (Puntos Funcionales)
Las fronteras del sistema

La determinación de las fronteras del sistema en estudio es el primer paso del análisis. Tal como se analiza en otra sección, la cantidad de Puntos Funcionales de un sistema depende, de una manera no trivial, de la elección de las fronteras. Por esta razón se debe ser cuidadoso en este punto.

La frontera entre dos sistemas que interactúan se define desde el punto de vista del usuario. No es una frontera técnica sino una frontera funcional. Cuando las fronteras no se conocen exactamente, deben ser estimadas, aunque para esto se deban emplear criterios convencionales.

Cuando se amplía un proyecto existente, las fronteras se deben considerar en forma coherente. De otra forma no es posible aplicar las ecuaciones y la metodología. En caso que la ampliación exija una redefinición de las fronteras, se debe replantear el proyecto existente de acuerdo con la nueva definición de las fronteras.


Las funciones tipo datos (Puntos Funcionales)
Las funciones tipo datos

Las funciones (o funcionalidades) de tipo datos comprenden todo lo que signifique almacenamiento dentro del sistema. Pueden pensarse como los viejos archivos, pero con una visión renovada. En el contexto de los Puntos Funcionales, archivo significa simplemente un grupo de datos lógicamente vinculado. No tiene nada que ver con la implementación física de las entidades. Esta funcionalidades se clasifican en tres niveles: simples, promedio y complejas.

Existen dos grandes grupos de archivos:

Archivos lógicos internos

Archivos de interfaz externa

Para cada uno de los archivos es necesario determinar su complejidad. La complejidad depende de la organización lógica de los datos considerados.

A los efectos de normalización, existe un cuadro de complejidad que vincula estas dos características. Esta cuadro se aplica tanto a archivos internos como a interfaces externas al sistema.


Archivos lógicos internos (Puntos Funcionales)
Archivos lógicos internos

(Internal Logical File, ILF): es un grupo identificable por el usuario de entidades de datos o de control que se encuentran vinculados lógicamente, mantenidos dentro de la aplicación.


Archivos de interfaz externa (Puntos Funcionales)
Archivos de interfaz externa

(External Interface File, EIF): es un grupo identificable por el usuario de entidades de datos o de control que se encuentran vinculados lógicamente, mantenidos fuera de la aplicación.


Tipo de elemento de datos (Puntos Funcionales)
Tipo de elemento de datos

(Data Element Type, DET): es un campo, no recursivo, que el usuario puede identificar como una unidad.


Tipo de registro de datos (Puntos Funcionales)
Tipo de registro de datos

(Register Element Type, RET): es un subgrupo de elementos de datos que el usuario puede reconocer como tal.


Complejidad de archivos e interfaces (Puntos Funcionales)
Complejidad de los archivos lógicos internos e interfaces externas.

La manera normalizada de proceder consiste en determinar el número de tipos de registros de datos y el número de tipos de elementos de datos empleados. Luego se usa este cuadro de complejidad:

RET / DET	1 a 19 DET	20 a 50 DET	> 50 DET
1 RET	simple	simple	promedio
2 a 5 RET	simple	promedio	complejo
> 5 RET	promedio	complejo	complejo


Las funciones tipo transacciones (Puntos Funcionales)
Las funciones tipo transacciones

Las funciones (o funcionalidades) tipo transacciones comprenden las clásicas operaciones de entrada, salida y consulta de datos dentro de la aplicación. En el contexto de los Puntos Funcionales, estas operaciones significan simplemente operaciones sobre un grupo de datos lógicamente vinculado. No tiene nada que ver con la implementación física de las entidades.

Entradas externas

Salidas externas

Consultas externas

Para cada uno de las operaciones es necesario determinar su complejidad. La complejidad depende de la organización lógica de los datos considerados. A los efectos de normalización, existe un cuadro de complejidad para cada caso (entradas, salidas o consultas) que vincula estas dos características.


Entradas externas (Puntos Funcionales)
Entradas externas

(External Input, EI): es un ingreso elemental de información de datos o de control, en forma unitaria, que proviene desde afuera de la aplicación.


Salidas externas (Puntos Funcionales)
Salidas externas

(External Output, EO): es un proceso elemental que genera información de datos o de control fuera la frontera de la aplicación.


Consultas externas (Puntos Funcionales)
Consultas externas

(External Inquiry, EQ): es un proceso elemental que combina una entrada y una salida de modo de recuperar información. No existe procesamiento de datos para la salida ni cambio de los archivos lógicos internos (excepto formato).


Tipo de archivo referido (Puntos Funcionales)
Tipo de archivo referido

 (File Types Referenced, FTR): es un archivo lógico o una interfaz que el usuario puede identificar como tal.


Complejidad de las entradas externas (Puntos Funcionales)
Complejidad de las entradas externas

La manera normalizada de proceder consiste en determinar el número de tipos de archivos referidos y el número de tipos de elementos de datos empleados. Luego se usa este cuadro de complejidad de las entradas externas:

FTR / DET	1 a 4 DET	5 a 15 DET	> 15 DET
1 FTR	simple	simple	promedio
2 FTR	simple	promedio	complejo
> 2 FTR	promedio	complejo	complejo


Complejidad de las salidas externas (Puntos Funcionales)
Complejidad de las salidas externas

La manera de proceder con las salidas es similar. Consiste en determinar el número de tipos de archivos referidos y el número de tipos de elementos de datos empleados. Luego se usa este cuadro de complejidad de las salidas externas:

FTR / DET	1 a 5 DET	6 a 19 DET	> 19 DET
1 FTR	simple	simple	promedio
2 a 3 FTR	simple	promedio	complejo
> 3 FTR	promedio	complejo	complejo


Complejidad de las consultas externas (Puntos Funcionales)
Complejidad de las consultas externas

La manera de determinar la complejidad de las consultas es consecuencia del hecho de tratarse de una operación doble. A estos efectos se procede como se indica:

1) Se determina la complejidad de la parte de entrada de la consulta, mediante el cuadro correspondiente.

2) Se determina la complejidad de la parte de salida de la consulta, mediante el cuadro correspondiente.

3) Se emplea la mayor de las dos complejidades anteriores.

Procediendo de esta manera se puede clasificar cada una de las funcionalidades tipo transacciones en uno de los tres niveles. Esto completa el análisis de funcionalidades.


Comunicaciones (Puntos Funcionales)
Comunicaciones

Este modificador tiene en cuenta en qué medida el proyecto posee funcionalidades basadas en las comunicaciones. Cuanto mayores sean estas funcionalidades, más aumentará la cuenta final de Puntos Funcionales.

La definición normalizada de la escala de evaluación es la siguiente, según sean las características de comunicaciones del sistema en medición:

0	El sistema es batch o ejecuta en un PC autónomo.

1	El sistema es batch pero tiene entradas o salidas remotas.

2	El sistema es batch pero tiene entradas y salidas remotas.

3	El sistema tiene entradas on-line o teleprocesamiento.

4	Se ejecuta en varios procesadores pero existe un único protocolo de comunicaciones.

5	Se ejecuta en varios procesadores y existen varios protocolos de   comunicaciones.

El valor 0 se aplica a un proceso sin comunicaciones. El valor 3 se aplica al caso normal: existe procesamiento on-line o teleprocesamiento. El valor 5 se aplica a una red compleja de máquinas, por ejemplo, donde coexisten máquinas UNIX, mainframes y redes locales. Los diversos protocolos agregan una complejidad general al sistema.


Performance (Puntos Funcionales)
Performance

Este modificador tiene en cuenta las performance que se espera del sistema en consideración. El cuadro de evaluación es:

0	No existen exigencias de performance.

1	Se establecieron exigencias de performance pero no se tomó ninguna medida especial.

2	La performance es crítica en los momentos pico. No hubo diseño especial para cumplirlo. El procesamiento puede diferirse al día siguiente.

3	La respuesta es crítica en todas las horas de trabajo. No hubo diseño especial pero hay exigencias de comunicación con otros módulos.

4	Fue necesario un análisis de procesos en la etapa de diseño para cumplir con las exigencias.

5	Fue necesario emplear herramientas de análisis de performance para cumplir con las exigencias.

El valor 0 se aplica a un sistema sin exigencias de performance. Los valores 2 y 3 corresponde a situaciones típicas: hay exigencias críticas y el procesamiento puede diferirse o no al día siguiente. Los valores 4 y 5 se aplican a sistemas sumamente críticos, pocas veces encontrados en los sistemas de información habituales.


Funciones distribuidas (Puntos Funcionales)
Funciones distribuidas

Este modificador tiene en cuenta en qué medida se trata de un sistema distribuido. Es un aspecto diferente de las comunicaciones: en aquel modificador importaba la complejidad de la comunicación, aquí importa el manejo de los recursos computacionales disponibles. El cuadro correspondiente es:

0	La aplicación no interviene en ningún procesamiento distribuido.

1	La aplicación prepara datos para que el usuario final los procese en forma independiente.

2	Los datos son preparados por la aplicación, transferidos y luego procesados por otra parte del sistema.

3	El procesamiento es distribuido pero la transferencia ocurre en una dirección solamente.

4	El procesamiento es distribuido y la transferencia es en ambas direcciones.

5	El procesamiento ocurre, dinámicamente, en el componente más apropiado del sistema.

El valor 0 es el caso en el cual no existen exigencias. La situación normal es 2 o 3: el sistema de información es distribuido pero existe solamente una transferencia simple de datos. El valor 5 se aplica solamente a un complejo sistema distribuido con asignación dinámica de recursos, situación muy rara. Esta situación no ocurre si la plataforma realiza esta operación sin que sea necesario diseñarlo específicamente.


Configuración muy exigida (Puntos Funcionales)
Configuración muy exigida

Este modificador tiene en cuenta las exigencias de seguridad, de tiempos o de otro tipo que el sistema de información debe cumplir. El cuadro de valores es la siguiente:

0	No hay exigencias de ningún tipo.

1	Hay restricciones operacionales pero menos que lo normal. No es necesario nada para cumplirlas.

2	Se incluyen algunas condiciones de seguridad o de tiempos.

3	Se incluyen exigencias específicos para el procesador en algunas partes de la aplicación.

4	Existen restricciones específicas para el procesador principal o el procesador dedicado.

5	Existen, además, condiciones en las componentes distribuidas del sistema.

El valor 0 ocurre cuando no hay exigencias. El valor 5 se aplica al caso que existan condicionantes específicas, de seguridad o de tiempos, en cada una de las partes de la aplicación. La situación típica de un sistema de información es 2 o 3.


Frecuencia de transacciones (Puntos Funcionales)
Frecuencia de transacciones

Este modificador tiene en cuenta la frecuencia de las transacciones y sus posibles picos. Es natural que cuanto más complejo sea el pico de carga a enfrentar, más complejo sea el sistema de información. El cuadro de valores correspondientes es:

0	No se espera ningún pico de carga.

1	Se espera un pico periódico (mensual, anual, etc.).

2	Se espera un pico semanal.

3	Se espera un pico diario.

4	Se requiere un análisis de tareas en las etapas de diseño del sistema.

5	Se requieren herramientas de análisis durante el diseño, el desarrollo o la instalación.

La situación normal es que exista un pico diario o semanal de carga, correspondiente a cierres de archivos o consolidación de datos. Los valores 4 y 5 se aplican a aquellos sistemas en los cuales es necesario un estudio e implementación especial para enfrentar el pico de carga.


Entradas on-line (Puntos Funcionales)
Entradas on-line

Este modificador tiene en cuenta qué parte de las entradas son on-line. El cuadro es muy directo:

0	Todas las transacciones son batch.

1	Del 1% a 7% de las transacciones son interactivas.

2	Del 8% al 15% de las transacciones son interactivas.

3	Del 16% al 23% de las transacciones son interactivas.

4	Del 24% al 30% de las transacciones son interactivas.

5	Más del 30% de las transacciones son interactivas.

En los sistemas actuales de información es simple que se llegue a una puntuación alta en este modificador.


Eficiencia para el usuario (Puntos Funcionales)
Eficiencia para el usuario

Este modificador tiene en cuenta las ayudas que encuentra el usuario en el sistema de información. Son ayudas elementos tales como: documentación en línea, barras de herramientas, menús pop-down, posibilidad de cambiar el idioma, atajos paras las operaciones frecuentes, etc. El cuadro de valores es de aplicación directa:

0	El diseño no incluye ningún tipo de ayudas.

1	El diseño incluye de 1 a 3 tipos de ayudas.

2	El diseño incluye de 4 a 5 tipos de ayudas.

3	El diseño incluye más de 5 tipos de ayudas.

4	Se requiere un estudio de eficiencia para el usuario.

5	Se requieren herramientas especiales para asegurar la eficiencia final.

En los sistemas modernos de información se tiende a disponer de diversas ayudas. De todos modos no es sencillo llegar al valor normal 3. Los valores 4 y 5 están reservados a los casos en los cuales se ha estudiado y diseñado cuidadosamente los aspectos de ingeniería humana del sistema. Puede tomarse como referencia de nivel 3 o superior las interfaces humanas gráficas de McIntosh, Windows o UNIX.


Actualización on-line (Puntos Funcionales)
Actualización on-line

Este modificador presenta un aspecto diferente del que consideraba las entradas on-line. En este caso la preocupación es por la actualización on-line de los archivos y sus exigencias en casos de incidentes: errores humanos, cortes de energía u otros incidentes. El cuadro de valores es:

0	No hay exigencias.

1	Se actualizan entre 1 y 3 archivos. No hay exigencias especiales de recuperación.

2	Se actualizan más de 3 archivos. No hay exigencias especiales de recuperación en casos de incidentes.

3	Se actualizan todos los archivos importantes. Hay alguna exigencia de recuperación en caso de incidentes.

4	Es esencial la protección contra pérdida de datos y se la ha diseñado especialmente.

5	Debido a los volúmenes de información, el procedimiento de recuperación diseñado es muy cuidadoso.

El valor 0 se aplica a los casos donde no hay este problema. La situación normal, el valor 3, es que se actualicen los archivos importantes y que existan algunas exigencias de integridad de los datos. Los valores 4 y 5 se reservan para los casos donde la integridad de los datos es un punto importante y afecta el diseño y la implementación del sistema de información.


Procesamiento complejo (Puntos Funcionales)
Procesamiento complejo

Este modificador tiene en cuenta la complejidad del procesamiento, elemento que no aparece en forma directa en el cálculo de Puntos Funcionales. La calificación es igual a la cantidad de los elementos que siguen:

Exigencias importantes de seguridad o controles de auditoría.

Complejo procesamiento lógico.

Complejo procesamiento matemático.

Complejo manejo de excepciones: por transacciones incompletas, por datos perdidos, por errores humanos.

Manejo complejo de la entrada/salida debido a necesitar independencia de dispositivos, multimedia, etc.

El complejo procesamiento lógico ocurre, por ejemplo, cuando hay un complejo manejo de bloqueo de registros que no se realiza automáticamente y debe ser diseñado. Las demás situaciones se describen por sí mismas.


Reusabilidad (Puntos Funcionales)
Reusabilidad

Este modificador tiene en cuenta en qué medida el proyecto es más complejo debido a exigencias de reuso de la programación. En la medida que este es un objetivo, el proyecto es más complejo, aún para las mismas funcionalidades. Existen diversos niveles posibles que se definen en el siguiente cuadro:

0	El código no es reusable.

1	Se usa algo de código reusable dentro de la aplicación.

2	Menos del 10% de la aplicación tuvo en cuenta las necesidades de más de un usuario.

3	10% o más de la aplicación tuvo en cuenta las necesidades de más de un usuario.

4	La aplicación fue especialmente preparada y documentada para ser reusada. Se han adecuado los programas fuentes para ser adaptados a las necesidades de otros usuarios.

5	La aplicación fue especialmente preparada y documentada para ser reusada. Se han adecuado parámetros para ser adaptados a las necesidades de otros usuario.

La situación normal de reuso, niveles 2 y 3, corresponde a los casos en que existe una parte definida del proyecto que fue realizada pensando en su utilización posterior. Los niveles 4 y 5 corresponden a sistemas de información en los cuales se ha previsto su reutilización mediante cambios en el código o en parámetros.


Facilidad de instalación (Puntos Funcionales)
Facilidad de instalación

La facilidad de instalación es una característica modificadora que aumenta la complejidad de un proyecto. La escala que se emplea es la siguiente:

0	No existen exigencias de instalación.

1	No existen exigencias del usuario pero hay condicionantes para la instalación.

2	El usuario fijó condiciones de instalación y conversión de datos, pero no inciden en forma importante en el proyecto.

3	Las exigencias de instalación y conversión de datos inciden en forma importante en el proyecto.

4	Se exige, además, herramientas de conversión e instalación automática.

5	Las herramientas de conversión fueron suministradas y probadas intensamente.

La situación normal corresponden a los niveles 2 y 3 y son claras. Los niveles 4 y 5 ocurren cuando existe programación automática de conversión e instalación. La diferencia entre ellos es el grado de prueba y de flexibilidad que estas herramientas poseen: es una experiencia cotidiana que aún los paquetes de programación utilitaria masiva, tales como editores de texto, tienen dificultades para enfrentar la instalación y la conversión automática cuando ocurren cambios de versiones.


Facilidad de operación (Puntos Funcionales)
Facilidad de operación

Esta característica modificadora tiene que ver con la administración del sistema y no con el usuario. La calificación es igual a la cantidad de los elementos que siguen que el sistema ha incorporado:

Hay procesos de arranque, respaldo y recuperación que requieren la intervención del operador.

Hay procesos de arranque, respaldo y recuperación que no requieren la intervención del operador.

Se ha minimizado el cambio de medios de almacenamiento removibles.

Se ha minimizado el empleo de papel.

Si la aplicación está diseñada para operación automática, sin operador, se califica como 5, situación que no es frecuente en los sistemas de información.


Múltiples lugares (Puntos Funcionales)
Múltiples lugares

Un sistema de información que se debe instalar en más de un lugar presenta dificultades adicionales para las mismas funcionalidades. La escala aplicable es la siguiente:

0	Existe un único lugar de instalación.

1	Se consideran múltiples lugares pero se opera bajo condiciones idénticas.

2	Se consideran múltiples lugares pero se opera bajo condiciones similares.

3	Se consideran múltiples lugares y se opera bajo condiciones diferentes.

4	Se ha elaborado y ensayado un plan para la operación en múltiples lugares similares.

5	Se ha elaborado y ensayado un plan para la operación en múltiples lugares diferentes.

Las situaciones normales corresponden a los valores 1 y 2. Lugares y condiciones diferentes quiere decir, por ejemplo, que el sistema está diseñado con una herramienta que puede trabajar en plataformas diferentes. Un ejemplo posible es un sistema que opera bajo PC, redes y máquinas UNIX. Las diferencias entre los valores 3, 4 y 5 contemplan diferentes grados de complejidad del diseño, pruebas y puesta en marcha de estas diferentes situaciones.


Facilidad de cambio (Puntos Funcionales)
Facilidad de cambio

La facilidad de cambio es una característica para el usuario, no se relaciona con el reuso de la aplicación. La calificación es igual a la cantidad de los elementos que el sistema ha incorporado. Los elementos pertenecen a dos grupos:

Consultas y reportes flexibles, simples, sobre un archivo (un punto).

Consultas y reportes flexibles, simples, sobre más de un archivo (dos puntos).

Consultas y reportes complejos sobre más de un archivo (tres puntos).

La información de control está en tablas que pueden ser actualizadas y entran en operación al día siguiente (es necesario detener el sistema).

La información está en tablas que pueden ser actualizadas y son operativas de inmediato (dos puntos).

El primer grupo de prestaciones no necesita aclaraciones adicionales. El segundo grupo tiene que ver con la capacidad del sistema de actualizar tablas de parámetros importantes. La posibilidad de modificar tablas que entran en operación de inmediato es bastante más que el ingreso on-line o la actualización de archivos que contemplan otros modificadores.


Ampliación de un proyecto (Puntos Funcionales)
Ampliación de un proyecto

En estos casos existen criterios normalizados para calcular la ampliación. Se emplean la siguientes definiciones:

EFP	Puntos Funcionales de la ampliación.

ADD	Puntos Funcionales, sin ajustar, que se deben agregar.

CHGA	Puntos Funcionales, sin ajustar, de la parte que se modificó.

CHGB	Puntos Funcionales, sin ajustar, antes de la modificación.

DEL	Puntos Funcionales, sin ajustar, que se quitan del proyecto.

CFP	Puntos Funcionales para realizar la conversión de datos para el proyecto nuevo.

VAFA	factor de ajuste de los Puntos Funcionales después de realizada la extensión del proyecto.

VAFB	factor de ajuste de los Puntos Funcionales en el proyecto viejo.

La ecuación recomendada por el IFPUG para calcular el incremento de Puntos Funcionales es:

EFP  = (ADD + CHGA + CFP).VAFA  - (CHGB +  DEL).VAFB

En casos que se cambie de tecnología el problema es similar a una ampliación de proyecto. Es importante tener en cuenta el cambio de los factores de ajuste, cosa que es seguro que ocurrirá, así como las extensiones y ampliaciones que son casi inevitables. En todo problema de emigración de sistemas aumenta lo que se espera del sistema, simplemente por el hecho que la tecnología de la información tiene prestaciones crecientes. Este es un punto que debe tener siempre en cuenta.


Distribución del esfuerzo del proyecto

Los proyectos pueden ser clasificados en tres grupos: pequeños (hasta 3 personas, hasta 12 meses); medianos y grandes (más de 10 personas, más de 30 meses.) A los efectos prácticos se puede tomar el siguiente cuadro para estimar componentes de un proyecto parcial:

	proyecto pequeño	proyecto mediano	proyecto grande
Análisis y codificación	65%	45%	20%
Documentación	5%	20%	40%
Depurado	20%	25%	30%
Administración	10%	10%	10%

Los valores indicados son solamente una referencia que pueden ser usados en ausencia de indicaciones mejores. Según sea el proyecto, además, podrá corregirse algo en los casos que se sepa que existe una desviación importante de algunos de estos parámetros, por ejemplo, si se exige una alta confiabilidad o una excelente documentación.


Estimación de esfuerzo (Albrecht)

Este estimador empírico resulta de relacionar las medidas de Albrecht (que correspondían a proyectos realizados en COBOL mayoritariamente) con el esfuerzo de realización del proyecto. La ecuación empírica que proponía era:

54 . PF - 13390   (horas de trabajo)


Lenguaje y Puntos Funcionales

En muchas oportunidades es necesario vincular Puntos Funcionales con cantidad de líneas de código. Un ejemplo típico es en los casos de emigración de tecnología.

Por cierto que no existe ninguna vinculación simple entre dos conceptos tan diferentes. No obstante esto, es posible obtener una primera aproximación mediante una tabla empírica realizada por Capers Jones y que se presenta en el cuadro:

Lenguaje	Líneas / PF
ASSEMBLER	320
C	128
FORTRAN 77	105
ANSI COBOL 74	105
ADA	71
PROLOG	64
manejador de base de datos	40
lenguaje de cuarta generación	20
generador de programas (CASE)	16
macros de una planilla electrónica	6

Las cifras de este cuadro permiten realizar una primera aproximación de gran utilidad, pero no pueden reemplazar nunca la medida directa. Queda claro, también, que no es posible aspirar a tener una única ecuación que relacione Puntos Funcionales con el tamaño de un proyecto.


La metodología GPM

La metodología GPM consiste en aplicar las ideas anteriores a una herramienta CASE. En la primera etapa se determinan los Puntos Funcionales -o una metodología extendida si fuese el caso- del proyecto:

A partir de los Puntos Funcionales, una ecuación empírica (específica para GeneXus) realiza la estimación de los meses-persona nominales. Para corregir el esfuerzo nominal se aplican los modificadores de ambiente -y otros modificadores si fuese el caso- siguiendo la metodología de COCOMO, tal como muestra la figura:

Una nueva ecuación empírica, similar a las empleadas por COCOMO permite calcular tiempo recomendado de desarrollo y, por lo tanto, el número promedio de personas.


El modelo de Putnam

La ecuación aceptada para la evolución del esfuerzo de un proyecto es la ecuación de Rayleigh-Norden:

Esta ecuación incluye el esfuerzo total del proyecto, K; pero incluye, además, un parámetro . Según el valor de este parámetro se tienen diferentes curvas que corresponden a diferentes plazos de entrega. Con esta ecuación, Putnam introduce, en 1978, el análisis dinámico de los proyectos de software.

Es interesante presentar un conjunto de curvas para un mismo esfuerzo total de proyecto (100 meses-persona):

Como puede apreciarse, en la curva azul -que podemos llamar de velocidad normal- se alcanza un máximo de 14 personas ocupadas en el cuarto mes. El plazo de entrega se alcanza en 10 meses. Esta situación es diferente si el proyecto se lo acelera o se lo frena. En la versión acelerada, color rojo, con 8 meses de plazo de entrega, para el mismo esfuerzo total se necesitan 18 personas ocupadas en el tercer mes. En la versión lenta, color amarillo, 15 meses de plazo de entrega, hay solamente 9 personas ocupadas y este máximo se alcanza en el séptimo mes.

El modelo de Putnam permite estimar los recursos humanos y la realización en el tiempo de un proyecto en base a datos obtenidos de un análisis estático. También permite ajustar el plazo de entrega del proyecto o considerar proyectos complejos formados por varios sub-proyectos.


Función Kemb (planilla GPS)

Kemb(KLOC)

Esfuerzo nominal COCOMO en un proyecto tipo Embedded con KLOC líneas de código.


Función Korg (planilla GPS)

Korg(KLOC)

Esfuerzo nominal COCOMO en un proyecto de tipo Organic con KLOC líneas de código.


Función Ksd (planilla GPS)

Ksd(KLOC)

Esfuerzo nominal COCOMO en un proyecto de tipo Semidetached con KLOC líneas de código.


Función Temb (planilla GPS)

Temb(MesesPersona)

Tiempo nominal COCOMO de desarrollo en un proyecto tipo Embedded que exige un esfuerzo MesesPersona.


Función Torg (planilla GPS)

Torg(MesesPersona)

Tiempo nominal COCOMO de desarrollo en un proyecto de tipo Organic que exige un esfuerzo MesesPersona.


Función Tsd (planilla GPS)

Tsd(MesesPersona)

Tiempo nominal COCOMO de desarrollo en un proyecto de tipo Semidetached que exige un esfuerzo MesesPersona.


Factores de COCOMO (planilla GPS)

El argumento de estos factores de costo de COCOMO es la calificación del nivel del atributo (de 1 a 6).

xACAP(i):  Capacidad de los analistas.

xAEXP(i):  Experiencia en la aplicación.

xCPLX(i):  Complejidad del producto.

xDATA(i):  Tamaño de la base de datos.

xLEXP(i):  Experiencia en el lenguaje de programación.

xMODP(i):  Empleo de técnicas modernas de programación.

xPCAP(i):  Capacidad de los programadores.

xRELY(i):  Exigencias de confiabilidad.

xSCED(i):  Exigencias de plazo de entrega.

xSTOR(i):  Exigencias de memoria.

xTIME(i):  Exigencias de tiempo de ejecución.

xTOOL(i):  Empleo de herramientas.

xTURN(i):  Capacidad de respuesta del ambiente.

xVEXP(i):  Experiencia en la máquina lógica.

xVIRT(i):  Obsolescencia de la plataforma.


Función ILF (planilla GPS)

ILF (simple; promedio; complejo)

Internal Logical File, Puntos Funcionales aportados por un archivo lógico interno según la cantidad clasificada como simple, promedio o compleja.


Función EIF (planilla GPS)

EIF (simple; promedio; complejo)

External Interface File, Puntos Funcionales aportados por una interfaz externa según la cantidad clasificada como simple, promedio o compleja.


Función EI (planilla GPS)

EI (simple; promedio; complejo)

External Input, Puntos Funcionales aportados por una entrada externa según la cantidad clasificada como simple, promedio o compleja.


Función EO (planilla GPS)

EO (simple; promedio; complejo)

External Output, Puntos Funcionales aportados por una salida externa según la cantidad clasificada como simple, promedio o compleja.


Función COBOL (planilla GPS)

COBOL (PuntosFuncionales)

Esfuerzo nominal, en horas, para desarrollar un sistema en COBOL de tamaño PuntosFuncionales..


Función GPM (planilla GPS)

GPM (PuntosFuncionales)

Esfuerzo nominal, en horas, para desarrollar un sistema en GeneXus de tamaño PuntosFuncionales.


Función TDEV (planilla GPS)

TDEV (MesesPersona)

Tiempo nominal de desarrollo, en meses, para un sistema de información que requiere un esfuerzo MesesPersona.


Función PUTNAM (planilla GPS)

PUTNAM (t; TiempoEntrega)

Cantidad de personas, según el modelo de Putnam, empleadas en el instante t, para obtener TiempoEntrega.


Funciones de la planilla GPS
Las funciones de la planilla GPS

Las funciones incluidas en la planilla GPS son las siguientes:

COBOL

EI

EIF

EO

GPM

ILF

Kemb, Korg, Ksd

PUTNAM

TDEV

Temb, Torg, Tsd

xACAP, xAEXP, xCPLX, xDATA, xLEXP, xMODP, xPCAP, xRELY, xSCED, xSTOR, xTIME, xTOOL , xTURN, xVEXP, xVIRT


Créditos de esta ayuda
Acerca de esta ayuda

Este archivo de ayuda forma parte integral de la obra Gestión de Proyectos de Software de Juan Grompone. Versión 1.0. Es el archivo de ayuda de la planilla electrónica GPS donde están las funciones de cálculo necesarias para la gestión. En el libro se encuentra, además, el estudio de casos.

Si bien esta información es propiedad registrada, el archivo puede ser usado y copiado libremente siempre que no sea alterado en forma alguna.

Editorial La Flor del Itapebí. Olmer S.A.

Luis Piera 1917, ap. 401

Montevideo, Uruguay.

Tel./fax: +(598 2) 49 01 91

Todos los derechos reservados, Montevideo, 1996.

ISBN 9974-592-05-4