Archivo de la etiqueta: calidad del software

Fallos: la importancia de las pruebas.

Deja un comentario

Hace unos días, hablaba con un viejo amigo que se ha especializado en el área de Pruebas de sistemas (en LinkedIn podéis ver su perfil por si os interesa) y hablando de salarios me comentaba lo difícil que resultaba, habiéndose especializado en ese área, conseguir un salario alto.

 

Esto me hizo pensar en que quizás el problema podría estar en que si de por sí en nuestro sector la labor de Programador no estaba muy valorada, en el caso de Ingenieros de Pruebas la cosa era a veces incluso peor.

Lo curioso es que para mí, que llevo ya un tiempo en este mundillo, tan importante me resulta una tarea como otra, ya que ambas son parte del mismo proceso de Diseño y Desarrollo de Software. Y si la programación debe de conseguir implementar correctamente los requisitos de usuario, tanto en funcionalidad, operativa como en rendimiento, las pruebas deben de ser las que validen que así se ha hecho, además de validar (según la aplicación que estemos diseñando) cosas como la seguridad y estabilidad del sistema resultante.

 

Todo esto me hizo recordar una noticia que había leído hace muy poco (el 2 de agosto pasado) sobre las pérdidas sufridas por la firma de corretaje Knight Capital, de hasta 440 millones de dólares, por un error informático:

«Este problema estuvo relacionado con la instalación de un software para realizar transacciones en los mercados y que provocó que Knight enviase numerosas órdenes erróneas de valores cotizados en la bolsa de Nueva York (NYSE)», explicó hoy la empresa de Nueva Jersey en un comunicado.

 

Como podéis ver en este caso concreto, un fallo informático (aunque detrás de todo fallo informático está siempre un fallo humano, como bien dice Fernando Suárez)  ha supuesto un enorme descalabro en las cuentas de la empresa, y la pérdida de valor bursátil al día siguiente.

Y aunque no haya datos en este caso sobre el ‘error informático’, no estaría de más revisar cuál ha sido el proceso de diseño-desarrollo-pruebas del nuevo software, para establecer porqué no se detecto en las pruebas realizadas, o si es que realmente alguien decidió que no era necesario realizar tales pruebas (o no tenían que ser especialmente exhaustivas) pensando en ahorrar unos cuantos miles de dólares.

 

Esto, que a toro pasado parece algo evidente y lógico, por desgracia aún a día de hoy no está debidamente valorado, muchas veces por quien desarrolla el software, otras muchas por quien será el usuario de dicho software y paga la factura.

O sencillamente, las prisas por llevar a producción un sistema o no tener el entorno adecuado de pruebas, terminando provocando que lo que parecía una buena solución de ahorro pase a ser el motivo de pérdidas económicas.

 

Y es que según algún estudio, los fallos informáticos están a la orden del día y pueden suponer hasta 75.000€ de pérdidas por hora, algo que en tiempos de crisis y necesidad de optimizar y mejorar nuestra productividad no es algo como para no tener en cuenta.

Pérdidas que se pueden producir tanto por operaciones incorrectas, como en el caso anterior, como por número de horas de trabajo perdidas porque esa nueva versión software no funciona o lo hace a un rendimiento inferior al esperado.

Aunque también hay casos mucho más graves, como los que he encontrado en esta entrada en el blog ‘Pensamientos Computables’ donde se mencionan casos de fallo Software que han conllevado muertes humanas por mal funcionamiento.

Y por supuesto, no nos olvidemos de las pruebas relativas a la seguridad de aplicativos que se usen a través de internet, para evitar que algún intruso pueda acceder al sistema y liarla.

 

Por todo ello, en la Ingeniería del Software y según recogen las distintas metodologías de software, el proceso de pruebas es una parte más del proceso global, y por tanto nos lo debemos tomar muy en serio para asegurar la calidad del SW desarrollado y la menor tasa de errores en entornos de producción.

 

 

Y por eso mismo, asegurarnos de contar con la gente adecuada para realizar tanto el diseño de los casos de pruebas, como para montar los entornos de prueba adecuados (reproduciendo los entornos de producción finales), dotándoles de las herramientas adecuadas para poder realizar los distintos tipos de pruebas, evitando así llevarnos sustos innecesarios.

 

Si en algún momento nuestro proyecto requiere ahorrar en costes, la solución pasa por buscar el ahorro optimizando el trabajo o usando mejores herramientas, pero nunca eliminando partes necesarias del proceso de desarrollo o pensando que ‘cualquiera puede probar‘.

Productividad, costes y salarios.

Deja un comentario

Asistía hoy a un aula virtual, donde se trataba el tema de la situación económica actual en España, el tema del ‘rescate’ por parte de la UE y posibles salidas a la situación.

El caso es que en la ronda de preguntas, tras haberse mencionado el tema de ‘bajar los costes salariales’ para mejorar la productividad, yo he preguntado:

¿La rebaja de los salarios no supone también penalizar el ahorro y lastrar la recuperación? Los salarios ya son bajos y antes de la crisis la facilidad de acceso al crédito sostenía el consumo y causaba un alto endeudamiento, pero hoy el consume cae y bajarlos lastra la recuperación.

Aquí la respuesta ha sido que reducir los costes salariales nos hace más competitivos, puesto que consigue que se produzca más barato y facilita las exportaciones (en el 1er trimestre del año la balanza comercial nos es favorable).

Y aquí, si bien reconozco que el argumento es válido, no puedo estar totalmente de acuerdo.

El hecho es que si miramos la relación entre productividad y costes, vemos que la relación es la siguiente:

Productividad = Producto Generado / Coste

Está claro que no descubro nada nuevo, pero normalmente cuando se habla de los costes, es habitual escuchar siempre el término ‘costes salariales’ como único coste, o al menos como único coste ‘reducible’.

Lo cierto es que esto no es así, puesto que en los costes entran varios factores, y aún ciñéndonos solo a los ‘salariales’  debemos tener en cuenta que este coste se compone de:

Coste por hora * hora de trabajo

Y de nuevo no descubro nada, ya que esta relación es lógica y conocida.

Pero aquí debemos plantearnos una cosa, las hora de trabajo ¿son todas efectivas?

Todos sabemos que en una jornada media de 8h obtener un 100% de horas efectivas es imposible, debido a las distracciones, los pequeños problemas del día a día o que simplemente las personas no somos máquinas que puedan trabajar 8h sin descanso.

Pero asumiendo esa realidad, lo único que nos queda de hora a obtener una mayor productividad, es asegurarnos de que las horas improductivas no se disparan y que las horas efectivas sean lo más productivas posibles.

Y aquí entran diversos factores, como son:

  • dotar a cada trabajador de las herramientas adecuadas.
  • realizar un análisis de riesgos que nos permita adelantarnos a los problemas que puedan bloquear el trabajo.
  • identificar las tareas que no dependen de nosotros, pero requerimos o requeriremos en algún momento, y coordinar los esfuerzos de los equipos involucrados para evitar retrasos.
  • tener una planificación clara y accesible para que todos sepan qué deben hacer y cuándo…

En el mundo del desarrollo software hace tiempo que se vienen haciendo esfuerzos en este sentido, con modelos como el de CMMI que en su nivel 4 ya contempla estas cosas:

4 – Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El
software resultante es de alta calidad.

Así, cada vez más empresas que se embarcan en obtener la certificación, muchas veces exigida por grandes clientes y administraciones públicas, van incorporando formas de contabilizar las horas trabajadas y las métricas asociadas a la productividad.

O con frameworks de trabajo como Scrum, en los que además de buscar un mayor conocimiento de la propia capacidad del equipo y su avance, las figuras del Scrum Manager o el Product Owner ayudan a la hora de orientar los esfuerzos de una forma mucho más eficaz.

Pero fuera del mundo SW y de las grandes empresas que se embarcan en obtener estas certificaciones e incorporar métricas e indicadores de productividad, la norma general es encontrarse con innumerables empresas que descuidan muchos estos aspectos.

Desde empresas que no han automatizado muchos procesos, que no conocen mayor informatización que la de comprar PCs y un programa de contabilidad para su departamento de administración, o que simplemente no consideran analizar sus procesos de trabajo para ver dónde mejorar y ganar tiempo en sus tareas diarias.

Incorporar un CRM que te ayude a dar un mejor servicio a tus clientes, para que sus pedidos sean más cómodos y nos roben menos tiempo, o conocer las bondades de un BPM que nos ayude a conocernos mejor, identificar donde podemos mejorar o cambiar para ser más eficaces, son realidades al alcance de muchas empresas que por desgracia aún ven con reticencia y poco útiles.

Por todo esto es por lo que creo que a la hora de hablar de productividad, no solo debemos contar con los costes salariales como única variable de ‘abaratamiento’, si no que también debemos pensar en mejorar nuestras estructuras y procesos como empresa, como vía de reducir nuestros costes totales y mejorar la productividad.

Sirva un ejemplo:

Un desarrollador que diariamente emplea un 25-30% de su tiempo de trabajo en esperar a que determinados procesos (compilación, despliegue, rearranque de servidores, etc…) finalicen para poder continuar.

Quizás su equipo no sea el adecuado porque cuente con un viejo PC obsoleto, o el entorno de desarrollo o pruebas no es el adecuado.

Y aquí una inversión de unos 1000€ (el precio del HW en la actualidad ha bajado mucho)  podría suponer reducir ese 30% a un 10%, con lo que si el coste por hora es de 30€, un 20% de mejora supondría un ahorro de 48€ diarios (8h*30€ = 240€ diarios), es decir, en 21 jornadas de trabajo (1 mes) habríamos recuperado la inversión realizada y empezaríamos a ahorrar en costes.

Obviamente no siempre es tan sencillo ver el ahorro, pero una consultoría (aunque a priori nos parezca otro ‘gasto’) puede mostrarnos áreas de mejora, aconsejarnos soluciones y cómo modelar nuestro negocio para ser no solo más productivos (y por tanto más ‘baratos’) sino además más eficaces.

Si nos fijamos en nuestro sector, las empresas de mayor renombre (Google, Microsoft, Atlassian, …) son conocidas por los profesionales, entre otras cosas por pagar cifrar desorbitadas a sus desarrolladores.

Volviendo a la formula apuntada:

Productividad = Producto Generado / Coste

queda bien claro que mejorar la productividad no solo se consigue bajando el coste. También se consigue mejorando el valor Producto Generado, y esta parte es la que se olvida habitualmente.

Es muy facil cuadrar presupuestos al principio del proyecto bajando el salario. Pero, ¿que pasa con el presupuesto cuando ha pasado el 150% del tiempo planificado para hacer el proyecto y aquello no hay por donde agarrarlo?

En Madrid, por experiencia, si contratas a un desarrollador por menos de 22.000€, bajas los costes, pero consigues, iba a decir trabajo basura (que también), pero queda mas claro si digo Producto basura. Y ojo, es posible tener auténticos cracks contratables por debajo de 22.000€, en la misma proporción que puedes encontrar un Cristiano Ronaldo por menos de 1 millon de € de traspaso.

Entre 22.000 y 30.000 hay mucha mediocridad y algunos valores con futuro, pero tu equipo de desarrollo por esos precios de media, no van a hacer un Producto decente.

Sin embargo, por encima de 40.000, y teniendo cuidado con lo que se contrata, puedes aumentar exponencialmente el valor de tu Producto. Y es que, por mucho lo parezca, 2*22.000 no es igual a 1*44.000,  es bastante menor os lo puedo asegurar.

Ya lo decía mi abuela, que no era directiva ni se había pagado ningún Master en una escuela de negocios, «hay hijo, un día de darás cuenta de que, lo barato, a la larga,  sale caro».

Claro que los que piensa que no es así, son los mismos que piensan que 9 embarazadas hacen un niño en 1 mes, porque caen en el recurrente error de considerar al valor humano como un mero ‘recurso’ y considerar a todos sus ‘recursos’ como igual de productivos y válidos.

Por último, un par de gráficos y un artículo que vienen a corroborar lo dicho, donde podemos ver que la productividad española está en la media de la UE (desterrando el mito de nuestra baja productividad), donde los más productivos no son los países con manos de obra más barata, pero sí los que cuentan con mano de obra cualificada (y bien remunerada) y empresas que apuestan por innovar y mejorar.

Expansión:

¿Quien trabaja más en Europa y cual es el país más productivo?

Antipatrones

Deja un comentario

Un antipatrón es una mala solución de diseño, que termina llevando a una mala solución.

Para entendernos, estamos hablando de escoger una solución incorrecta para un problema, empujados por esa acuciante necesidad (que cada vez veo más a menudo) de recurrir con premura a soluciones ya implementadas porque nos encontramos con un problema ‘parecido’ a otro que en su día resolvimos de esa forma.

De momento, os dejo un pequeño extracto de los que podéis encontrar en la Wikipedia.

De Gestión:

  • Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la calidad de vida de sus empleados[…]
  • Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de «éxito a cualquier precio».
  • Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresión profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y madurez.
  • Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad antes de que esté implementada.

De Diseño Software:

  • Blob: Véase Objeto todopoderoso.
  • Sistema de cañerías de calefacción (stovepipe system): Construir un sistema difícilmente mantenible, ensamblando componentes poco relacionados.
  • Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado.
  • Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación.
  • Singletonitis: Abuso de la utilización del patrón singleton.
  • YAFL (yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

De Programación:

  • Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar.
  • Lava seca (lava flow): Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante. Esto es análogo a un flujo de lava en el que se van endureciendo pedazos de roca. La solución incluye un proceso de gestión de la configuración que elimina el código muerto y permite evolucionar o rehacer el diseño para acrecentar la calidad.
  • Programación por excepción (coding by exception): Añadir trozos de código para tratar casos especiales a medida que se identifican.

Metodológicos:

  • Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.
  • Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar los mismos problemas.
  • Reinventar la rueda cuadrada (reinventing the square wheel): Crear una solución pobre cuando ya existe una buena.

 

Y muchos más que podéis revisar en la entrada de la Wikipedia.

Obviamente nadie está a salvo de cometer errores y acabar cayendo en alguno de los muchos que se enumeran.

Yo mismo he caído en más de uno en alguna ocasión, pero solo conociéndolos y siendo conscientes de nuestros errores podemos ponerle remedio y evitarlos en el futuro.