Skip to content

desarrollo

Métricas del Software: Puntos Función

Actualmente trabajo en una empresa multinacional cuya actividad principal es el desarrollo de software y que me ofrece la posibilidad de realizar distintos cursos de formación a lo largo del año. La mayoría de los cursos están encaminados, o bien a reforzar mis conocimientos en las áreas en las que normalmente trabajo, o bien a conocer el detalle de las nuevas herramientas y arquitecturas que se desarrollan dentro de la propia empresa.

Uno de los objetivos principales de estos cursos es el de consolidar y unificar todos los procesos de desarrollo en torno a un único estándar que sirva de referencia a los distintos equipos, que en cierta forma trabajan aislados los unos de los otros en el día a día de cada proyecto en particular. Lo que se hace es tomar las fases características por las que se pasa durante el proceso de desarrollo: toma de requerimientos, análisis, diseño, codificación, prueba, documentación, etc. y se estudia cuales son los métodos y las herramientas más adecuadas a aplicar en cada fase en concreto.

En estos momentos estoy estudiando el método de “Puntos Función” que sirve para obtener métricas del software, o dicho de otra forma, para calcular (medir) distintos indicadores de un proyecto de software, sobre todo estimaciones de tamaño, tiempo y esfuerzo. Conocer con la máxima precisión posible el tiempo y las personas que se van a dedicar a realizar una tarea concreta es un factor clave para triunfar en el competitivo mundo en el que vivimos hoy en día.

El método está orientado a ser utilizado para proyectos de desarrollo de aplicaciones de gestión, y a grandes rasgos consiste en separar los procesos de los datos y asignar a cada una de ellos un peso. Los procesos se dividen en entradas, salidas y consultas. Los datos se dividen en internos y externos. Las entradas son cada uno de los procesos únicos y distinguibles a través de los que los datos se introducirán en el sistema, las salidas los procesos que retornarán al menos un dato calculado, y las consultas los que implicarán una interacción con el propósito de obtener un determinado dato. Los datos internos son los que se mantendrán dentro de los límites del sistema, y los externos los que no. El método consiste en delimitar el sistema, identificar cada uno de sus elementos y asignarles una medida adimensional que es el punto función. En una versión simplificada del método los puntos función se toman de una tabla de medidas medias en la que se indica que para una entrada se necesitan 4 puntos función, 5 para una consulta, y así sucesivamente. Multiplicando cada elemento por su número de puntos función se obtiene el número de puntos función brutos del sistema. Finalmente el tiempo y el esfuerzo se determinan considerando la historia de la empresa, es decir, si un programador medio de la empresa suele desarrollar 2 puntos función al día entonces se podrán desarrollar 10 puntos función en una semana (2 pf x 5 días = 10 pf/semana)

Una de las cosas que primero me llamaron la atención es que el método aborda el problema desde el punto funcional y no técnico. Es decir, estudia la complejidad de los sistemas que se quieren construir o modificar desde el punto del vista de los usuarios que los utilizarán, y no desde el punto de vista de los equipos que los desarrollarán. Lo paradójico de este planteamiento es que quien realizará la medición es un equipo normalmente técnico con el objetivo de determinar cuanto tiempo va a tardar en ejecutar el proyecto, o mejor dicho, en entregar el producto.

¿Se lo imaginan? Un método que promete obtener una estimación fiable del tiempo y esfuerzo que se necesitará para desarrollar un programa que cubra todas las necesidades solicitadas por los usuarios examinando sólo los requerimientos de los mismos. Naturalmente mi escepticismo inicial se está convirtiendo en desilusión a medida que avanzo en el aprendizaje del método.

Si sólo se miran los requerimientos, ¿qué ocurre entonces con la complejidad técnica? ¿Es lo mismo implementar un sistema de gestión que un sistema de control en tiempo real? ¿Podemos llegar a un nivel de abstracción tal que no sea necesario conocer detalles de implementación ni la tecnología que se utilizará? La respuesta por supuesto es que no. Así que, ¿cómo resuelve todos estos problemas el método para dar una medida final? Pues de la única forma posible, sacándose de la manga una decena de factores de ajustes de carácter técnico. Y es que no hay otra, al final alguien tiene que mojarse y dar una estimación subjetiva del tiempo que se va a tardar en desarrollar el sistema. Esos factores de ajuste ponderan los puntos función obtenidos anteriormente para tener en cuenta aspectos tales como la concurrencia o la disponibilidad, es decir, lo difícil que será implementar finalmente el sistema.

Pero en cualquier caso la conclusión final tiene que ser positiva. Lo importante es tener un método y aplicarlo, es hacer examen de conciencia y reconocer la necesidad de cuantificar lo que se está haciendo. Medir, medir y medir. Puede que el sistema no sea óptimo, pero es lo mejor que tenemos por ahora. Y no es una excusa. El hecho de que una empresa reconozca la necesidad de disponer de un método para medir de la mejor forma posible algo tan etéreo, complejo y difícil, como es el proceso de desarrollo de software es un paso muy importante.

cURL

Recientemente hemos tenido que acometer un encargo dentro del proyecto en el que trabajo consistente en automatizar un proceso de descarga de ficheros desde unas páginas web. La situación era que una serie de personas debían conectarse diariamente con un navegador a unas páginas web determinadas para descargarse de ellas unos ficheros con una información que le es necesaria para la normal realización de su trabajo. Lo que se quería era evitar el tiempo que se perdía en la descarga manual y que fuera en cambio un proceso automático el que descargarse los ficheros y los dejara en un servidor de red.

Nuestra primera opción fue utilizar wget, una aplicación multiplataforma, de uso gratuito y código abierto, que sirve precisamente para descargar archivos de webs. Es frecuente encontrarla instalada en máquinas UNIX, y quizás uno de sus usos más conocidos es el de descargar webs enteras, ya que es capaz de seguir todos los links que se le indiquen de forma recursiva.

Comprobamos que wget se encontraba instalado en el servidor que íbamos a utilizar, pero desgraciadamente resultó que era una versión antigua y no soportaba HTTPS, algo que necesitábamos utilizar porque algunas de las webs a las que teníamos que acceder utilizaban este protocolo. Mientras gestionábamos el upgrade de versión, algo complicado de conseguir ya que la máquina que teníamos que utilizar era un servidor de producción con un riguroso protocolo de certificación del software instalado, encontramos una alternativa en cURL, otra aplicación multiplataforma, de software libre y código abierto.

La funcionalidad que ofrece cURL es básicamente igual a la de wget, así que nos decidimos a probarla. Con un poco de recelo, y en vez de bajar un paquete de instalación ya preparado, nos decidimos por descargar los fuentes y compilarlos para la máquina destino. Increíblemente todo funcionó bien a la primera, y es que en estos casos nunca sabes lo que te puedes encontrar. Bastó con ejecutar un script con los parámetros adecuados para obtener el software listo para funcionar. El script tardó varios minutos en ejecutarse durante los cuales realizó una enorme lista de comprobaciones acerca de la máquina y el software disponible, así como el compilador instalado y las opciones que este soportaba.

Utilizar cURL es tan sencillo como pasarle la URL que se quiere descargar. Aunque naturalmente admite una larga serie de parámetros para controlar las salidas que genera por consola, para los distintos protocolos que soporta (HTTP, HTTPS, FTP, SFTP, …), para la configuración del proxy a utilizar, para enviar información en las cabeceras al servidor, y así un largo etcétera.

De esta forma el proceso automático que nos encargaron quedó como un sencillo shell script programado diariamente en el cron de la máquina.

No es la primera vez que solucionamos este tipo de encargos mediante el uso de software libre. Hace unos meses por ejemplo utilizamos PDFCreator para permitir que los usuarios pudieran generar ficheros en formato PDF directamente desde nuestra aplicación. Y a diario utilizamos herramientas como PuTTY o FileZilla, por poner sólo dos.

Absurd Code Of The Week

Más diversión en The Daily WTF

Coding4Fun

Dentro del último MSDN Flash que he recibido esta semana me ha llamado la atención, aparte del próximo CodeCamp de Vic (Barcelona), un link a un artículo dedicado a la programación de videojuegos con el título de Inicio del desarrollo de juegos: Parte VII: detección de terreno y colisión.

Después de echarle un vistazo me he dado cuenta de que en realidad es una traducción al castellano de la serie de Coding4Fun.

Como nota curiosa destacar que para explicar algunos conceptos como el Depth o Stencil Buffer pone un enlace a la Wikipedia. Pero para eso la crearon, ¿no?

Prototipado rápido

Una de las ventajas de utilizar JavaScript para los juegos que estoy haciendo es la facilidad con la que puedo tener un prototipo básico funcionando en un tiempo razonablemente corto de tiempo. Estos prototipos me permiten hacerme una idea mejor del aspecto que puede llegar a tener el producto final, así como evaluar en una fase muy temprana del desarrollo el tiempo real que puedo tardar en hacerlo, darme cuenta de alguna de las dificultades que no había previsto inicialmente, y concretar los problemas principales a resolver.

La sintaxis de JavaScript es similar a la de otros lenguajes como C o Java, por lo que resulta fácil producir código, e igualmente resulta fácil leer el código ajeno. Obviando naturalmente lo estructurado y claro que resulte este. Además, JavaScript es un lenguaje de alto nivel interpretado, por lo que no hay tiempos de compilación, basta pulsar F5 para recargar la página y listo. La contrapartida es que no todos los navegadores interpretan y soportan el lenguaje de igual forma. Pero lo mismo ocurre con muchos compiladores de C++ por ejemplo.

Por otra parte, JavaScript es un lenguaje debilmente tipado, como PHP por ejemplo, por lo que muchas de las conversiones de tipos se realizan de forma explícita. Y la pérdida de rendimiento por el uso de esta característica es perfectamente asumible para el tipo de proyectos que estoy haciendo. JavaScript tampoco requiere liberar la memoria reservada explícitamente, aunque se puede hacer utilizando una sentencia delete. Existe un garbage collector encargado de liberar los recursos reservados.

Naturalmente no todo son ventajas, tiene sus incovenientes. Se hecha en falta la depuración paso a paso por ejemplo, en vez de tener que utilizar la escueta ventana de la consola. Naturalmente existen algunos programas que permiten hacer esto, incluido un bonito plugin para Eclipse. Una necesidad, un programa. Pero personalmente aún no he tenido la necesidad real de tener que utilizarlos.

Un ejemplo de prototipo rápido ha sido el que he hecho para un nuevo juego/experimento que estoy preparando. Tengo en mente un programa sencillo consistente en distribuir aleatoriamente unos rectángulos de colores sobre el tablero de juego con el objetivo de que se retiren en orden, primero los de arriba y luego los de abajo, de forma que no pueda retirarse un rectángulo si tiene uno o más encima. Es sólo una idea, sin pulir demasiado. Así que he escrito un pequeño programa que me distribuye los rectángulos y enseguida he visto que tengo que desarrollar más la idea. El aspecto es un poco caótico.

Lo primero que he cambiado ha sido el esquema de colores, y luego la distribución de los rectángulos haciendo que recaigan en coordenadas alineadas sobre una rejilla (virtual). Estas modificaciones han hecho que el aspecto mejore bastante, pero el juego sigue sin decir absolutamente nada, no resulta atractivo. Y es que el diseño en este tipo de programas constituye un tanto por ciento muy alto del éxito resultado final. Tendré que buscarme otra idea y dejar esta para más adelante.