Videos

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

 

 

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.

 

 

 

47. ¿Cuáles los documentos son necesarios para el cálculo de punto de función?

 

No hay un docu­mento espe­cí­fico de uso obli­ga­to­rio para medir un soft­ware (o con­tar pun­tos de fun­ción). Cual­quier docu­mento donde sea posi­ble extraer infor­ma­ci­o­nes de los requi­si­tos del usu­a­rio puede ser uti­li­zado en un cál­culo de pun­tos de fun­ción. Sean ellos casos de uso, manu­a­les, pro­to­ti­pos, docu­men­tos de visión, modelo de imple­men­ta­ción de soft­ware.

 

Se puede imple­men­tar un soft­ware a tra­vés de dis­tin­tos méto­dos y her­ra­mi­en­tas para aná­li­sis, mode­lado y cons­truc­ción, para diver­sas pla­ta­for­mas com­pu­ta­ci­o­na­les; pero nada de eso afecta la medi­ción de lo mismo en pun­tos de función.

 

Es claro que deter­mi­na­dos tipos de docu­men­tos pue­den traer la infor­ma­ción para un cál­culo de pun­tos de fun­ción de manera más fácil. Otros docu­men­tos pue­den con­te­ner sola­mente parte de la infor­ma­ción nece­sa­ria para el cál­culo de PFs, siendo nece­sa­rio el aná­li­sis con­junta de más docu­men­tos para efec­tu­arse la medi­ción.

 

Así como tam­bién otros docu­men­tos, como tie­nen un carác­ter más téc­nico para el pro­ceso de desar­rollo de soft­ware, pue­den ser más tra­ba­jo­sos para extraer los requi­si­tos de usu­a­rio. El mejor docu­mento para uti­li­zarse un cál­culo de PFs es aquel que con­ti­ene los requi­si­tos del usu­a­rio expli­ci­ta­dos en la len­guaje de su nego­cio, y no en len­guaje de TI.

 

Cada orga­ni­za­ción tiene su pro­ceso de desar­rollo par­ti­cu­lar, pro­du­cir una can­ti­dad de docu­men­tos (o arte­fac­tos) dis­tin­tos en deter­mi­na­das fases del pro­ceso. Luego, el momento donde la medi­ción es hecha acaba deter­mi­nando tam­bién cua­les docu­men­tos esta­rán dis­po­ni­bles para efec­tu­arse el tra­bajo de medi­ción (o esti­ma­tiva) del tamaño fun­ci­o­nal del proyecto.

48. ¿Cuál la importancia de los requisitos de software para el APF?

 

Los requi­si­tos de soft­ware son fun­da­men­ta­les para el APF, pues el pro­ceso de medi­ción es basado exclu­si­va­mente en ellos. La entrada básica de medi­ción son los requi­si­tos de sis­tema. Con­vi­ene des­ta­car que el APF mide sola­mente una parte de los requi­si­tos de usu­a­rio para el sis­tema: los requi­si­tos fun­ci­o­na­les no son medi­dos por el APF.

 

Ade­más en un modelo de esti­ma­tiva de costo basado en PF (costo = tamaño x $/PF), ambos los tipos de requi­si­tos (fun­ci­o­na­les y no fun­ci­o­na­les) son con­si­de­ra­dos: el pri­mer irá

afec­tar el tamaño fun­ci­o­nal y el segundo afec­tara el costo uni­ta­rio ($/PF).

 

Debido a esta impor­tan­cia de los requi­si­tos para el APF, cuanto mejor la cali­dad de los requi­si­tos, el pro­ceso de medi­ción tor­nase más fácil, ágil y pre­ciso el resul­tado. Requi­si­tos de cali­dad malos afec­tan nega­ti­va­mente todo el proyecto de soft­ware, incluso la acti­vi­dad de medi­ción. Ade­más un efecto cola­te­ral bené­fico de pro­ceso de medi­ción es jus­ta­mente evi­den­ciar fal­las en os resul­ta­dos. Cuanto más tem­prano en el proyecto estas fal­las fue­ren iden­ti­fi­ca­das, más pequeño el costo de arre­glar­las y mayor la opor­tu­ni­dad de suceso de proyecto.

 

 

46. ¿Cuáles son las principales causas para errores en un cálculo de punto de función?

 

La mayo­ría de los erro­res encon­tra­dos en un cál­culo de pun­tos de fun­ción de un sis­tema es oca­si­o­nada por 4 factores:

  • Des­co­no­ci­mi­ento de la téc­nica: aun hay un gran número de pro­fe­si­o­na­les que son desig­na­dos para con­tar pun­tos de fun­ción de un sis­tema sin el cono­ci­mi­ento nece­sa­rio del pro­ceso del cál­culo. Qui­zás esto ocurra por haber una idea gene­ra­li­zada de que el APF sea muy sim­ples. Y en la rea­li­dad ella es, sin embargo esto no sig­ni­fica que sea des­ne­ce­sa­rio entre­na­mi­ento pro­fe­si­o­nal o un estu­dio más dedi­cado de la téc­nica.

     

    Con sola­mente un cono­ci­mi­ento super­fi­cial del APF es bien pro­ba­ble que el ana­lista cometa erro­res bási­cos. Sobre este aspecto, el IFPUG esta­blece su pro­grama de cer­ti­fi­ca­ción pro­fe­si­o­nal CFPS, que visa garan­tir que el pro­fe­si­o­nal cer­ti­fi­cado conoce todas las defi­ni­ci­o­nes y reglas de su Manual de Prac­ti­cas de Cál­culo en su ver­sión más recenté.

     

  • Dejar el cál­culo ser “con­ta­mi­nado” por la implan­ta­ción: el APF es una téc­nica para medir requi­si­tos fun­ci­o­na­les de un soft­ware. O sea, mide lo que el usu­a­rio soli­cita y recibe del soft­ware inde­pen­di­ente de cómo este fue imple­men­tado. Luego, el resul­tado de una cál­culo de pun­tos de fun­ción tiene que ser lo mismo, inde­pen­di­ente de la solu­ci­ona de imple­men­ta­ción (pro­ceso, arqui­tec­tura, her­ra­mi­en­tas, ambi­ente com­pu­ta­ci­o­nal) adop­tada por el desen­vol­ve­dor.

     

    Con­tar pun­tos de fun­ción de un sis­tema es un ejer­ci­cio de abs­trac­ción de pro­blema de nego­cio de usu­a­rio que el soft­ware debe aten­der, sin embargo ni siem­pre esto es una tarea fácil y mismo ana­lis­tas de pun­tos de fun­ción con expe­ri­en­cia pue­den des­viar el foco del cál­culo para la solu­ción de imple­men­ta­ción del desen­vol­ve­dor. Muchas veces el ana­lista es indu­cido en este camino por falta de docu­men­ta­ción adecuada.

     

  • Falta de cono­ci­mi­ento de nego­cio: de nada sirve ser espe­ci­a­lista en APF y no cono­cer el nego­cio del usu­a­rio. Para que el cál­culo de pun­tos de fun­ción sea hecho de forma cor­recta, o sea, de punto de vista de usu­a­rio, es nece­sa­rio que el ana­lista de pun­tos de fun­ción bus­que el enten­di­mi­ento de nego­cio pri­mero y sola­mente des­pués rea­lice el cál­culo de pun­tos de fun­ción.

     

    Muchas veces no hay tiempo dis­po­ni­ble para que el ana­lista de pun­tos de fun­ción bus­que este cono­ci­mi­ento. En este caso él ira actuar en con­junto con un ana­lista de nego­cio o con un usu­a­rio para poder rea­li­zar el cál­culo de pun­tos de función.

     

  • Cali­dad de los requi­si­tos dis­po­ni­bles: mucho se dice en la inge­ni­e­ría de soft­ware sobre la impor­tan­cia del levan­ta­mi­ento de requi­si­tos y del impacto que esto tiene en todo el proyecto cuando esta tarea no es bien eje­cu­tada. Para el cál­culo de pun­tos de fun­ción esto no es dife­rente. Si los docu­men­tos de donde el ana­lista de pun­tos de fun­ción extrae los requi­si­tos del usu­a­rio para rea­li­zar el cál­culo están ambi­guos, incom­ple­tos o mal escri­tos, cier­ta­mente el resul­tado del cál­culo será afectado.

Esta rela­ción de fac­to­res no están pre­sen­ta­das en nin­guna orden espe­ci­fica, pero es bas­tante repre­sen­ta­tiva de los prin­ci­pa­les fac­to­res que cau­san el cál­culo de pun­tos de fun­ción incorrectas.

.

 

.