Optimización del software

En ILERNA Online queremos ayudaros a pasar estos días de confinamiento y, por eso, hemos lanzado un calendario de charlas a través de Instagram donde encontraréis distintas propuestas. Por ejemplo, esta mañana nuestro profesor de Informática Martin Rivero ha compartido algunas prácticas para la optimización de software.

Una vez un programa ha sido creado y ejecutado, siempre se pueden llevar a cabo modificaciones para mejorar su rendimiento y para que funcione de forma más eficaz. Si te has perdido esta cita, no te preocupes, Martin Rivero ha preparado este artículo donde profundiza en varias métricas clave para otorgar calidad a un software. ¡Léelo atentamente!

La calidad, pilar del software

Primeramente debemos acotar qué se entiende por optimización del software. Si nos remitimos a la definición que da el autor Geoffrey Bessin, es “un proceso eficaz de software que se aplica de tal forma que crea un producto útil al que proporciona un valor medible”. 

Desde un enfoque más práctico, David Garvín [1984] sugiere que la calidad es un concepto complejo y tiene múltiples consideraciones, en función de qué perspectiva se tenga en cuenta a la hora de medirla. 

Desde un punto de vista más transcendental, la calidad es algo que se reconoce de forma inmediata, pero que no se puede definir explícitamente. Abordada desde la perspectiva del usuario, la calidad de un producto se mide por el grado de satisfacción: si el producto le satisface, tiene calidad.

Por lo que respecta a la perspectiva del fabricante, podemos medir la calidad en las especificaciones originales del producto: si las cumple, tiene calidad. Desde el punto de vista del producto, la calidad tiene en cuenta las funcionalidades y las características del mismo.

Por último, Gavín señala el punto de vista basado en el valor, que se mide en cuánto está dispuesto a pagar un cliente por dicho producto.

Pero, ¿por qué nos preocupa tanto el tema de la calidad? Sobre todo porque reducimos costes gracias a aplicar procesos de calidad a base de repetirlos.

El principal problema es que los defectos y errores los encontramos justo después de entregar el software a los usuarios finales. Por tanto, debemos realizar previamente revisiones técnicas, ya sea durante el proceso de modelado o el de construcción del software. Pero hay que tener cuidado: si hacemos pocas revisiones técnicas, el flujo del proceso no quedará ‘limpio’. Y, en cambio, si hacemos demasiadas, el proceso de creación del software se ralentizará. 

Cómo cuantificar las revisiones de la calidad

Necesitamos cuantificar todas las acciones que apliquemos de calidad y de optimización del software. Para ello existen diferentes factores medibles. Uno de ellos es calcular el esfuerzo. Así, podemos relacionar ese esfuerzo (horas-persona) conforme se vaya efectuando la revisión técnica:

• Esfuerzo de preparación (E_p): esfuerzo requerido para revisar un producto antes de la reunión de revisión. 
• Esfuerzo de evaluación (E_a): esfuerzo que se dedica a la revisión real.
• Esfuerzo de repetición (E_r): esfuerzo dedicado a la corrección de errores descubiertos durante esa revisión final

Otra forma de cuantificar las revisiones son las métricas del producto final:

• Tamaño del producto de trabajo (TPT): medición del tamaño del producto revisado (Modelos de UML, líneas de código, documentación…)
• Errores menores detectados: errores que podemos considerar que requieren un pequeño esfuerzo de corrección.
• Errores mayores detectados: errores que podemos considerar que requieren un mayor esfuerzo de corrección.

Por tanto, podemos calcular la densidad de errores por producto como:

Densidad Error = (Err_mayores + Err_menores) / TPT

Una de las conclusiones a las que podemos llegar es que las revisiones no quitan tiempo, sino que lo ahorran, como se plasma en este gráfico:

La métrica de Halstead

Una métrica es una medida cuantitativa del grado en el que un componente o proceso posee un atributo determinado (tasa de fallos, número promedio de errores…). 

Gracias a las métricas, podemos estimar el coste para diseñar, codificar y probar un software y predecir un número de errores que se encontrarán en la fase de pruebas.

Una de las métricas más utilizadas para código es la métrica de Halstead, que asignó unas normas que podemos aplicar una vez que el código ya esté generado:

• n₁=número de operadores distintos que aparecen en un programa
• n₂ =número de operandos distintos que aparecen en un programa
• N₁=número total de ocurrencias del operador
• N₂=número total de ocurrencias del operando.

Así, introdujo dos fórmulas para medir nuestro código:

Longitud de un programa

N=n₁*log₂(n₁) +n₂*log₂(n₂)

Volumen de un programa (en bits)

V= N*log₂ (n₁ + n₂)

Conclusiones

Podemos concluir que necesitamos responder a las necesidades del entorno e incluir metodologías de desarrollo de software ágil, herramientas de automatización de disciplinas básicas y lecturas de código de calidad para así lograr amplificar el desarrollo de software con calidad.

Bibliografía consultada

• Pressman, R., (2010). Ingeniería del Software: Un enfoque práctico. Madrid: McGraw Hill, 7ª edición.
• Sommerville, Ian (2011). “Ingeniería del software”. Ed. Pearson, 9ª edición.
• “The Business Value of Quality”, IBM developerWorks, junio 2004.

La optimización del software la trabajarás en los ciclos de Desarrollo de Aplicaciones Web y Multiplataforma de ILERNA Online.

Dentro del ciclo de charlas #QuédateEnCasa con ILERNA Online, quizás puede interesarte descubrir también las claves de una entrevista de trabajo online con este artículo de la profesora Laura Escabias.