Artículos

¿Cómo puedo obtener una medición simple?

 

Hace poco recibimos una pregunta de una de las participantes de nuestro curso Capacitación en Análisis de Puntos de Función: Medición y Estimación de Software y después de obtener su autorización, decidimos compartir sus comentarios y sus preguntas: 

 

"Llevo algún tiempo en el mundo de los Puntos de Función, y me gustaría saber qué es lo que se entiende por una medición simple. Yo entiendo por simple: sencillo, sin complicaciones ni dificultades. Y, por lo que he podido vivir, las mediciones en FPA no son ni simples, suelen ser complicadas y con bastantes dificultades. Por eso me gustaría saber cómo puedo conseguir que estas sean simples y que las mediciones lleven poco tiempo".

 

A continuación, presentamos la respuesta que uno de nuestros consultores, Carlos Vazquez, dió:

 

El objetivo de la medición son los requerimientos funcionales del usuario. Estos son derivados de artefactos disponibles desde antes de la implementación (o diseño) y después de ésta, como por ejemplo el software en operación plena.

 

Es común que artefactos de antes del diseño del software, que deberían describir la interacción del usuario con el software en términos del intercambio de datos y de la reglas de negocio relacionadas, describan como el software debe ser desarrollado.

 

 

  

Por ejemplo, desde el punto de vista del usuario, hay una única entrada de datos con el objetivo de actualizar una base de datos corporativa. Sin embargo, es necesario el desarrollo de dos programas de computador para eso. Es de esta manera, porque hay requerimientos de desempeño que no permiten que todo el procesamiento sea hecho de una vez; es necesario primero que se reciba y se confirme la validez de los datos para luego en la noche, cuando el volumen de transacción es menor, empezar el procesamiento de actualización efectiva en la base de datos corporativa.

 

El analista elabora dos casos de uso para describir la primera parte del procesamiento y otro caso de uso para describir la segunda. El analista de puntos de función no debe solamente evaluar los casos de uso, debe evaluar si esos artefactos no fueron elaborados desde un punto de vista técnico. Eso promueve la discusión en cuanto a la medición. No es que el método de medición que no sea simple. Es la correcta identificación de los requerimientos funcionales. Por eso, el método de puntos de función es también una herramienta para la verificación de la producción en la ingeniería de requerimientos.

 

El ejemplo provisto es uno con artefactos de antes de la implementación. Ahora presentamos otro diferente.

 

Cuando se evalúa el software o representaciones del software como su modelo de datos final, el proyecto de clases o el código, no se tiene una referencia en términos de la tareas y servicios del usuario. Es posible que una tarea única sea descompuesta en varios pasos implementados en transacciones diferentes.

 

Entonces cuando se hace la medición basada en estos insumos, es necesaria la información complementaria sobre el motivo para esa recomposición más allá que aquella asociada al nivel de una tarea del usuario. Esto también genera divergencias cuando se mide el software con puntos de función.

 

Observe que no es un problema inherente al método de medición y si a la representación adecuada del software para la medición.

 

Hay muchos profesionales que creen que saben el método del IFPUG. Sin embargo, lo que desean es una correspondencia perfecta entre las construcciones del proyecto e implementación con los componentes funcionales básicos del Análisis de Puntos de Función (EE, SE, CE, ALI, AIE). Eso no existe.

 

Uno de los puntos positivos al usar el Análisis de Puntos de Función PF es exactamente disminuir la brecha entre la visión de negocio, el proceso de negocio desde el punto de vista de sus tareas y servicios y la visión de TI con los términos y decisiones técnicas. La dificultad, por lo tanto, no está en la medición sino en disminuir la distancia entre estos dos mundos.

 

 

.

 

.