¿Cómo se mide la calidad en el software?

 Este artículo viene como referido al artículo de Rodrigo Corral, “En el software, la calidad, no es opcional”.


¿Qué es la calidad en el software?¿Se puede medir?¿Cómo?
Cuando decimos que para nosotros la calidad es muy importante, ¿a que nos referimos?


 En primer lugar quiero puntualizar las siguientes afirmaciones de dicho artículo:




  • Directivos y personal de Márketin dan más importancia al número de características que tiene un software que a la calidad, porque la calidad no se puede poner en un anuncio o en una oferta.


  • Algunos directivos al mando de empresas que construyen software caen en el error de pensar en la producción de software desde los parámetros habituales en otras industrias. La producción de software es muy diferente, es un proceso creativo no un proceso manufacturero. (Léase ejemplo de bolígrafos en dicho artículo)


  • La principal diferencia cuando ‘fabricamos’ software es que la calidad no es opcional, no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad.

  • Nadie recuerda a quien hizo un buen software (de calidad), pero nadie olvida el que fallaba constantemente (¿os acordáis de los pantallazos azules del w95?)


  • Paradójicamente, y esto es un hecho, es que añadir calidad a nuestro software, al contrario de lo que puede parecer a primera vista, reduce los costes de desarrollo y acorta los plazos.

    Pantallazo

Y por último quiero citar un párrafo textualmente:


“He visitado empresas, con grandes carteles en recepción del estilo “La calidad es nuestra esencia” o “La calidad al servicio del cliente” y con todas las certificaciones habidas y por haber de ‘calidad’ que no tienen ni un solo especialista en calidad del software, ni un solo especialista en probar aplicaciones. Y no, los desarrolladores, no son expertos en calidad y pruebas.”


Bien, dicho esto, y reflexionado sobre ello, podemos afirmar que en otros entornos percibimos la calidad perfectamente, cuando probamos un coche de gama alta, percibimos la calidad, ¡y no tenemos conocimiento del proceso de producción!, pero si palpamos la calidad, por ejemplo (y siguiendo con el ejemplo del coche), cuando aceleras sientes rendimiento, cuando tomas una curva y percibes estabilidad, cuando frenas, notas seguridad… realmente son indicadores (“métricas”), que se podrían medir y poner una puntuación de calidad a cada vehículo.


¡¡Vamos a intentar medir la calidad del software!!


Primero vamos a intentar identificar los factores que desde un punto de vista externo definen la calidad del software, no me refiero a los procesos internos de desarrollo, como pruebas unitarias, gestión de cambios, calidad del código… no!! me refiero a lo que se percibe, una vez el software está terminado, implantado y en producción, lo que nota un usuario. Intentemos pensar (como ejemplo para evaluar la calidad) en un producto software…, uno de los primeros que desarrollamos o probamos, así veremos mejor su evolución y evaluaremos la calidad teniendo en cuenta factores temporales.



  • Satisfacción del cliente (se suelen hacer encuestas para obtener este dato)


    • Interfaz de usuario (usabilidad, accesibilidad, facilidad de manejo, curva de aprendizaje, diseño…)

    • Rendimiento de la aplicación, Seguridad, Despliegue, Actualizaciones, Integración con sistemas…


  • Número de bugs en producción (bugs encontrados y la importancia de los mismos, se podría incluir en satisfacción del cliente)

  • Rentabilidad económica (%, precio de venta – coste de desarrollo)


    • Este factor no es relevante para el usuario, pero tiene mucha información subliminal y por eso lo quiero incluir. Para mí está muy ligada la rentabilidad a la calidad, por muchas cosas como la (la buena estimación, buena planificación, gestión, previsión, pruebas, buena arquitectura, buen código, pocos bugs, aplicación modular y bien preparada para el cambio…) por ello lo quiero incluir como factor a tener en cuenta, aunque no le afecte al cliente diréctamente, si indirectamente, ya que si el software es rentable, el cliente obtendrá un mejor servicio, soporte, mantenimiento… en definitiva un buen producto…(bueno este es otro tema)

  • Tiempo de vida por cliente (años que el software está funcionando)


    • El usuario quiere algo que le satisfaga y si (por ejemplo) en el banco de Cuenca tienen una aplicación Cobol, desarrollada hace 15 años, que les satisface las necesidades actuales, desde luego que es un aplicativo con calidad. Al igual que un coche, de hecho es muy típico ver mercedes de hace 20 años rodando a diario por las carreteras.

  • Número de clientes (clientes que tiene el software implantado y en producción)


    • Otro factor importante es el número de clientes que tiene un software, (no voy a poner más ejemplos de coches), por ejemplo existen productos software que están muy estandarizados (SAP, Subversion, PhotoShop, Office…) es software muy popular, muy testeado, en diferentes entornos y condiciones, y yo creo que eso es un síntoma de calidad.

Estos son los factores que se me han ocurrido, seguro que hay muchos mas (espero vuestros comentarios 😉 ).


Una vez apuntados los factores vamos a medir la calidad, … ¿qué?¿cómo?… si si, vamos a medir la calidad…, de las propiedades del software de calidad, podemos sacar métricas y de esas métrica (de una manera muy simple y lógica) vamos a preparar una primera versión de la fórmula:


Formula irreal de la calidad del software


Por si alguién no se ha dado cuenta está fórmula me la acabo de sacar “de la manga”, pero yo creo que tiene los factores clave para darnos una medida de la calidad que percibe un usuario de software.

Es tan dificil medir la calidad…, no cabe duda de que si diésemos con una fórmula válida, nos haríamos multimillonarios, pero la calidad no es algo tan trivial, que se pueda medir en una escala de 0 a 10… la calidad tampoco es binario o 0 o 1, o se tiene o no se tiene, es algo mas complejo, la calidad es el día a día, el trabajo meticuloso, de trabajo organizado y estructurado, probado y documentado, orientado a la petición de cambio del cliente y a la facilidad para llevar a cabo el cambio en el equipo de desarrollo, la calidad no es CMMI o SCRUM, aunque si es cierto que cualquier metodología actual sienta las bases para desarrollar un producto de calidad.

Por todo esto y para terminar, decir que la calidad no se puede medir, pero los factores que afectan a la calidad si se pueden identificar y mejorar… por lo tanto la calidad está en la mejora diaria, en cada uno de los eslabones del desarrollo de software, en la buena gestión, en cada línea de código, … todos deben aportar calidad, desde la codificación (tratando de documentar el código, haciendolo, legible, mantenible…), hasta la implantación del producto (haciendo un aterrizaje suave sobre un entorno de pre-producción, pasar de nuevo el plan de pruebas), hasta incluso después de la puesta en producción aportando al cliente un buen bug-tracker y comunicación continua…

¿Entonces, que tengo que hacer para aplicar calidad a mis desarrollos? … ¡mejorar! Mejorar en todos y cada uno de los procesos, hitos y tareas de la producción de software. (Y para decir esta frase el rollo que he soltado…)
PD: Si has tenido la paciencia de leer hasta el final, ¡¡enhorabuena!! estás reálmente interesado en mejorar y ese es el requisito fundamental para aplicar calidad al software.


Vamos a cambiar el mundo 😉


 

¿Qué tipo de informático eres?

Cuando trabajas con gente, de este gremio en concreto (aunque es aplicable a muchos otros), te das cuenta que hay gente de todo tipo: altos, bajos, guapos, simpáticos, frios, amables, meticulosos, solitarios… Pero cuando agrupamos aún mas a la gente (en mi opinión), tenemos a dos grandes grupos…

Grupo de los “busca vidas”: Es gente autodidacta, que les gusta investigar y a la vez que programan tienen preparado el google, el msdn, codeproject, codeplex… y cuando les surge una duda, consulta, investiga, busca una segunda opción, por lo general, comprueba que el método que acaba de escribir es optimo o incluso antes de escribir una funcionalidad, se da unas vueltas por la red buscando lo que tiene que hacer, (no vaya a ser que ya esté hecho), repasan y comentan el código a la vez que piensan en la siguiente tarea. Interpretan la labor de programar como un “arte”, en el que cada trozo de código adquiere una parte de ellos, lo ven como una forma mas de expresión, justificando las decisiones que toman, aportando comentarios en el código (aquí he utilizado una función recursiva por que mejora el rendimiento, bal bla bla). Que, a veces, cuando llegan a casa siguen pensando en la resolución del problema, que no solo se limitan a programar, a cumplir, sino que buscan la manera de mejorar, de innovar, pero lo mas importante de todo esto, es que este tipo de programador, aporta un valor añadido fundamental en los desarrollos, la calidad.

Grupo de los “Esqueeee”: Les suele caracterizar la parsimonia y la apatía, generalmente son gente desmotivada, que no les gusta demasiado su trabajo y carecen de vocación. Cuando se encuentran un problema, que no está en su guión de trabajo habitual, les identifica la frase: “Es que eso no se puede hacer” o “Es que no sé como hacerlo (pero tampoco me he molestado en buscar como)”. Solamente ven líneas de código, no piensan, solo programan, están convencidos de que solo hay una manera de hacer las cosas, la mas rápida. Es gente que les tienen que dar apoyo constante al desarrollo y no mejoran su actitud con la experiencia adquirida. Generalmente es necesario explicarles el problema, orientarles y guiarles hasta la solución. Ven su trabajo como una cadena de producción, en la cual, únicamente, tienen que cumplir sus 8 horas diarias y esperar el ingreso a final de mes, sin preocuparse demasiado de la calidad del desarrollo, solo lo justo, solo cumplir “Yo hago lo que me mandan…”. No dan valor añadido al desarrollo, solo programan, mecanizan instrucciones, líneas de código, limitándose al requisito 36 del documento de requisitos, ¡sin mas! y ¿para que van a hacer mas? Les van a pagar lo mismo.

Una vez definidos, a mi modo de ver, estos grupos, quiero aclarar y puntualizar que esto no es siempre así, que las cosas no son o blancas o negras, que cada persona tiene características y cualidades diferentes a otras, que cada uno somos de nuestro padre y nuestra madre y que hay muchas factores que nos caracterizan, por no hablar de los estados de ánimo, que es al final, lo que define las acciones de las personas. No quiero que nadie me ubique de racista, machista o generalista por hacer 2 grandes agrupaciones, es solo una opinión, un pensamiento, una idea que seguro… si pensáis un poco, vais a identificar dentro de estos grupos al 80% de la gente con la que trabajáis.

¡Bien! Una vez dicho esto tenemos que hacer examen de conciencia, ver donde estamos, hacia donde vamos y hacia donde queremos ir, es necesario preguntarnos que, si ahora mismo nuestros ideales, son los mismos que en nuestro primer día de trabajo… y si cuando empezamos en este mundo, nos identificábamos con un grupo, no nos estaremos desviando hacia otro (el lado oscuro de la fuerza 😉 ), o incluso, si tenemos compañeros de trabajo que han cambiado de grupo ¿cual es el motivo? ¿El síndrome del funcionario?

Y para terminar… recomendar este artículo a todo oveja descarriada, que no piense que el desarrollo es un arte… ¡que corra hacia la luz!

¡¡¡Vamos a cambiar el mundo!!!

¡Algo está cambiando… en el desarrollo de software!


Cuando se estudia Ingeniería de software, es común estudiar los mitos del software y en concreto hay un mito de los gestores que dice lo siguiente:
¿Por qué debemos cambiar nuestra forma de desarrollar software, si estamos haciendo el mismo tipo de programación ahora que hace 10 años?
Evidentemente las funciones del software son las mismas (como por ejemplo, sacar los datos de una base de datos y mostrarlos en un monitor), pero los requisitos han cambiado, el software ahora controla procesos de fabricación mas sensibles, el nivel de tolerancia al fallo tampoco es el mismo, las necesidades de escalabilidad y reusabilidad no son las mismas, el nivel de seguridad, la accesibilidad, los interfaces de usuario, la multitarea, … Porque ahora además de mostrar datos en un monitor, hay que presentar un informe con los datos, exportarlo a PDF, JPG, Excel y rtf…, Además tiene que tener la lógica de negocio publicada mediante servicios Web, integrarse con un gestor documental, actualizar los datos de 4 gestores de bases de datos diferentes, mostrar los datos en una PDA y en un Spectrum…  ¡¡¡nada es lo mismo!!! Bueno! los bucles, los condicionales y la declaración de variables, apenas ha cambiado… pero evidentemente la manera de hacerlo funcionar no es la misma, ahora tenemos arquitecturas en capas, programación modular, orientada a Objetos, orientada a Aspectos, orientada a Servicios, …


Este mito, también está en muy presente en algunos desarrolladores estancados en el “cuaternario”, habilidosos con el Visual Basic 5, cuyo único argumento es que para hacer un desarrollo, es que son más productivos utilizando la tecnología que conocen y dominan. Son muy comunes comentarios del tipo: los informes vamos a hacerlos con Crystal Reports 7, que así los llevo haciendo yo siempre y nadie nunca se ha quejado. No os olvidéis: “Así se ha hecho siempre” y el “nunca nadie se ha quejado”, son las frases que identifican a este tipo de desarrolladores. ¡Ojo! No hay que huir de ellos, ni obligarles a cambiar ya que su experiencia es muy valiosa cuando hay que hacer mantenimientos en entornos “Natural/Adabas”…, simplemente hay que aceptarlos y convivir… y ¿si podemos? enseñarles los nuevos entornos, metodologías, sistemas, tecnologías y herramientas, pero no imponérselos, porque de la imposición sale el rencor, y del rencor el odio, y del odio sale la desmotivación y la baja productividad.


¿Entonces? ¿Tenemos que cambiar nuestra manera de crear software?
La respuesta: Si ¿y mañana? También ¿pasado mañana? ¡Seguro!


Por todo esto doy un grito de “ÁNIMO” a las nuevas generaciones de desarrolladores, de mentes abiertas e inquietas, cuyo afán es mejorar, innovar, probar las nuevas tendencias y tecnologías, y todo esto tiene como trasfondo el aplicar procesos de mejora y calidad al desarrollo de software.



 

Comenzamos …

Hoy inicio mi andadura en Geeks…, espero no ser muy pesado y contribuir a la comunidad aportando artículos de calidad e interés.
El objetivo de este blog será el de contar y compartir mis vivencias y experiencias en el desarrollo de software… siempre con el afán de mejorar, con todo lo que esto conlleva (aprender, investigar, compartir…) y darlo a conocer.
Espero, a partir de ahora, poder ampliar y compartir la experiencia y conocimientos acumulados a lo largo del tiempo, aplicando procesos de calidad en el desarrollo de software.


Espero no aburrir a casi nadie 😉