Calidad en el desarrollo de Software

¡España!, y al decirlo se me llena la boca… España! ese país en el que pensamos que la productividad de las personas se mide por sus horas de trabajo, ese país en el que pensamos que las tarjetas de marcaje son un método para controlar a los empleados, el país donde los controladores aéreos deciden por el resto, ese país en el que Belén Esteban tendría un asiento en el parlamento… ¡en ese país vivimos!

¿Tarjetas de marcaje? ¡empresarios ilusos! acaso creen que estar en el puesto de trabajo es igual a trabajar… Y en la construcción de software… ¡ocurre lo mismo! Tenemos jornadas marcadas, con horarios marcados, con lugares de trabajo marcados y con las tarjetitas de marcaje de rigor.

¿Existe diferencia entre un trabajo de componente artístico frente a un trabajo manufacturero? Evidentemente ¡Sí! El número de decisiones por minuto (NDPM) que se toman en un trabajo artístico es mucho mayor que las que tomamos en un trabajo manufacturero.

En mi época de estudiante me pasaba los veranos trabajando en Nestlé, metiendo chocolatinas en cajas o vaciando sacos de cacao y os puedo asegurar que el número de decisiones por minuto (NDPM) que se toman en una cadena de producción de ese tipo tiende a cero y es por ello que durante tu jornada laboral tiendes a ocupar tu mente con ideas o pensamientos que no aportan valor al propio proceso productivo. No lo recuerdo bien, pero seguramente estaría pendiente de mirar el reloj, de la vida de los compañeros, de si Belén Esteban se separa, si Andrea se come el pollo… pero no de cómo optimizar el proceso o de cómo mejorar la calidad…, aunque… seguramente no hubiese servido de nada.

La construcción de software es un trabajo artístico e ingenieril (si alguien tiene algo que decir al respecto, que hable ahora o calle para siempre) bien! Yo lo declaro artístico e ingenieril! … Y para un trabajo con alto componente artístico necesitamos tener un estado de abstracción mental, de concentración y de motivación muy alto. Mi pregunta es… ¿Los estados dependen de un reloj o de una jornada de 8 horas? ¿Somos todos los días igual de productivos? Llego a la conclusión que nuestra productividad depende de nuestra capacidad de concentración y de nuestro estado de ánimo.

Os propongo una reflexión. Se propone una tarea semanal a dos empleados, la cual ambos la completan ¿Quién es más productivo?

• Señor A, de nombre José Metoras. A la semana trabaja 60 horas en la oficina, 12 horas al día de lunes a viernes.
• Señor B, de nombre Julián Rasbonsable. A la semana trabaja 40 horas, algunas de ellas en la oficina, distribuidas según su criterio.

¿Es válido el modelo productivo que tenemos en España? Y es que medimos la productividad por el número de horas invertidas, un sistema válido para la revolución industrial o para trabajos donde el NDPM sea igual a cero, pero no para muchos de los trabajos que hacemos los españolitos de hoy en día y en ningún caso para la construcción de software.

¿Qué opináis? ¿Lo estamos haciendo bien? ¿Estáis a favor de las tarjetas de marcaje y de los horarios estáticos? ¿Tenéis tarjetas de marcaje en vuestros trabajos? ¿Sirven para algo?

PD: Perdonad el título… es un reclamo publicitario 😉

Es una cuestión que lleva muchos días dándome vueltas en la cabeza…

Los tiempos que corren son tremendamente competitivos, donde los márgenes son ajustados, los plazos cortos y la exigencia de calidad y funcionalidad es muy alta. Es por ello que a todo responsable de equipos o proyectos le exigen más eficiencia y por lo tanto un aumento de la productividad.

Pero mi pregunta es… ¿cómo?

Por otro lado tenemos, de forma general, gente menos motivada, faltos de ilusión y como consecuencia, faltos de compromiso. Personalmente percibo en mis compañeros de trabajo (algunos ya son ex compañeros) que este año pasado, no han recibido el reconocimiento que esperaban… ¿tenemos falsas expectativas?, ¿nos valoran de manera objetiva y justa?, es evidente que la situación económica de las empresas, condiciona las valoraciones y las mejoras retributivas al personal…entonces…¿es realmente justo? ¿Es justo que se estanquen o deceleren las carreras profesionales por causas ajenas a tu actividad laboral?, no obstante creo que es algo que debemos intentar comprender y saber razonar.

¿Mejorar la productividad? Ummm, no dejo de darlo vueltas… pero la pregunta sigue siendo: ¿cómo? … seguro que tiene que haber alguna fórmula…

El caso es que mi jefe me dijo hace unos días: «Este año tenemos que mejorar la productividad de los equipos un 10%» y el eco resuena en mi cabeza «diezporciento, zporciento, ciento, ento, ento…»

Eso se traduce en que cada miembro de cada equipo tiene que ser más productivo en su especialidad (el programador, el analista, el tester, el diseñador…), es decir que tienen que hacer el mismo trabajo pero un 10% más rápido, por lo tanto tenemos que terminar la ejecución de las tareas cuando estas lleguen al 90% de la estimación.

foreach persona in equipos.personas
{
persona.productividad += 10%;
}

Ojala tratar con personas fuese tan fácil como tratar con máquinas…

Para construir software tenemos: Personas, Herramientas y Procesos.

Y el objetivo es hacer software en plazo, funcionalidad y con un coste de un 10% menos.

(Cómo veis he colocado a los individuos y su interacción por encima de los procesos y herramientas)… Es que desde hace algún tiempo hago unos estiramientos todas las mañanas y me estoy volviendo muy ágil.

Las herramientas son las que nos proporciona el mercado, unas mejoras, otras peores, más productivas, menos… son las que son y están las que están, y ¡creedme! No se ha incrementado tanto la productividad como aseguraban las campañas de marketing con cada versión de Visual Studio.

Los procesos los define tu metodología de desarrollo y están muy depuradas y optimizadas, solo tenemos que seleccionar una e incorporar esos procesos.

Yo creo que la clave está en las personas… Hace tiempo leí que para ser ágil había que serlo con las personas adecuadas http://www.elraul.com/?p=812 ¡Y estoy de acuerdo!

Pero es evidente que el Racing de Santander no puede prescindir de todos sus jugadores y contratar a los Ronaldinhos de turno. ¡Hay que mejorar la productividad de la gente que tienes! (salvo excepciones)

Pero mi pregunta es… ¿cómo? ¿Motivación o imposición?

 Yo tengo muy clara esta disyuntiva, creo que la motivación es el mejor remedio para aumentar la productividad. Mi opinión es que de la imposición obtienes beneficios instantáneos, pero la productividad desciende de manera exponencial en el tiempo. Esta conclusión es a la que llego, haciendo memoria y examen de conciencia, al experimentar estas dos técnicas sobre mi propio trabajo. Mi experiencia profesional ha sido mas enriquecedora, creativa y productiva cuando mas motivado me he encontrado, cuando he percibido un alto nivel de confianza y la presión ha sido la justa y necesaria. Por otro lado, cuando he recibido imposición, he intuido desconfianza y eso ha implicado desmotivación. Entiendo que no todas las personas somos iguales, ni reaccionamos de la misma forma a los agentes externos, pero sí creo que para profesiones que requieren un alto grado de pericia, creatividad y concentración es muy necesario sentirse motivado.

¿Todavía sigues leyendo? … ¡qué bien! Porque hasta ahora no he dicho nada interesante, pero ahora viene mi propuesta para combatir la baja productividad.

¿Qué factores mejoran la motivación?

En realidad no he conseguido realizar una ordenación que me satisfaga, así que lo dejaré así tal y como se ve en la pirámide y espero que me hagas un comentario con el orden que estimes e incluyas alguno que falte, ya que esto es algo muy personal.

Pues bien, ahora viene mi estrategia para conseguir mejorar la productividad del 10% el equipo:

• Interés en el proyecto: Tenemos que intentar conseguir proyectos interesantes y asignarlos a las personas menos motivadas y con un índice de motividad alto. Es necesario que lo vean como una oportunidad para expresar su capacidad. Por supuesto esto varía dependiendo de los intereses de cada uno, por eso es importante conocer a las personas, averiguar sus intereses y tener comunicación continua.
• Formación y conocimiento recibido: Es muy importante que la gente se forme en cursos o de compañeros de más nivel y aprenda nuevas tecnologías y técnicas de desarrollo. Creo que este aspecto nos diferencia de otras profesiones, la necesidad imperiosa del reciclaje tecnológico.
• Ambiente de trabajo: Para mejorar el ambiente de trabajo es necesario transmitir cercanía, cordialidad y compañerismo, no excederse en la presión, promover la justicia entre compañeros y evitar las rivalidades y enfrentamientos. En definitiva tratar de crear un grupo de compañeros que tengan un objetivo común y velen por su cumplimiento de una forma agradable.
• Salario percibido: Esto es lo más complicado pero creo que dentro de nuestras posibilidades tenemos que intentar ser justos y evidenciar y notificar las injusticias en este aspecto.
• Responsabilidad y confianza: Dar responsabilidad a alguien denota confianza y por lo tanto es una compensación y una expresión de un trabajo previo bien hecho.
• Horario flexible: La diferencia entre un trabajo manufacturero y uno artístico, como es la construcción de software, reside en el número de decisiones que se toman por unidad de tiempo, y para tomar esas decisiones de la manera más eficiente debemos tener un estado mental de alta concentración, es por ello que aunque sí es bueno que tengamos un horario marco de trabajo, no debamos ceñirnos a él, al son de una bocina.
• Evolución profesional: Es importante generar perspectivas de crecimiento profesional en las personas, mantener un cierto grado de ilusión, por una progresión, que, aunque no sea inmediata es algo que se valora a la hora de elegir un empleo y creo que también influye en la motivación, al menos a mi me influye. También es importante para tu propio crecimiento, que el equipo crezca contigo.

Es evidente que no solo basta con estas medidas, pero si me parece que son las mas destacables. Y si, además de estas medidas personales las complementamos y  trabajamos de una manera mas efectiva la faceta comercial e intentamos desarrollar de manera estandarizada, es decir orientarlo a productos o al repeat business seguro que vamos a mejorar aún mas la productividad.

En resumen, ¡motivación! ¡motivación! y ¡motivación! es la mejor gasolina para mover el motor de la creatividad y productividad.

Me satisface enormemente que hayas llegado al final de la lectura… ahora me gustaría saber tu opinión.

¿estás de acuerdo con este planteamiento?

Bueno!, han sido unas semanas muy duras… pero al fin hemos terminado con la evaluación SCAMPI para CMMI nivel 2.

Antes de continuar, aprovecho para hacer una reflexión:

El modelo CMMI no tiene demasiados adeptos en el mundo del software, ya que el esfuerzo que exige, es grande y no se obtiene valor añadido a corto plazo. De hecho, yo estaba en ese grupo de gente, que le gustaba mas seguir metodologías de desarrollo ágiles, las cuales no me exigian cierta «burocracia» a la hora de gestionar mis proyectos y podía profundizar mas en el ámbito tecnológico. El caso es que, al verme «forzado» a aprenderlo y aplicarlo, con el tiempo… me he dado cuenta, que es un modelo que me ha aportado muchas cosas… ¡he aprendido mucho!, pero sobre todo, ahora tengo mucho mas control sobre mis proyectos. Es por ello que ahora me encuentro en «el lado oscuro de la fuerza», ¡Que nadie piense que es síndrome de Estocolmo! … esta reflexión sale desde la razón, y a día de hoy me considero un firme defensor del modelo. Habrá gente que piense «bueeenooo, un purista a darnos clases de gestión de proyectos»… No pretendo!! únicamente contar como me fue y como, la cantidad de cosas buenas, que me aportó el modelo, me hizo inclinar la balanza. Bien! pues una vez aclarado esto, voy a contar como son este tipo de auditorías y las cosas buenas que me ha aportado este sistema de trabajo.

Han sido una serie de entrevistas duras en las que han participados numerosos miembros de la empresa y han tenido que contestar a preguntas de todo tipo relacionadas con cada una de las areas de proceso en las que hemos sido auditados:

1. REQM – Gestión de Requisitos
2. PP – Planificación de Proyectos
3. PMC – Seguimiento y Control de Proyectos
4. SAM – Acuerdos con Proveedores
5. MA – Medición y Análisis
6. PPQA Aseguramiento de la Calidad de Procesos y Productos
7. CM – Gestión de la Configuración

La evaluación, como ya he dicho, ha sido dura. El evaluador realiza una serie de entrevistas personales de una hora y media de duración en las que te pone a prueba, te «dispara» con preguntas de los diferentes áreas de proceso, algo parecido a un interrogatorio, intentando detectar alguna debilidad en alguno de los áreas de proceso, tratando de buscar la institucionalización. Este tipo de evaluaciones orales y personales, van orientadas a identificar el nivel experiencia que tienes con proyectos reales bajo el modelo CMMI. No sirve de nada, sólamente, estudiar la teoría… es necesario tener experiencia, diaria, gestionando proyectos CMMI.

A continuación voy a lanzar una serie de preguntas como las que te puede hacer el auditor:

¿Serías capaz de …?

1. Identificar las tareas y pruebas funcionales relacionadas con un requisito concreto
2. Identificar las partes de código fuente a las que afecta un cambio de requisito
3. Decir cuando se realizó una tarea en concreto y la cantidad de esfuerzo que supuso
4. Realizar una estimación precisa de una tarea que ya realizaste en algún proyecto anterior
5. Listar las tareas que tienes pendientes en un determinado módulo de tu proyecto
6. Decir el tiempo restante para terminar un módulo de tu proyecto
7. Sacar un listado de las incidencias de un proyecto y la desviación en esfuerzo, tiempo y coste
8. Sacar un listado de las peticiones de cambio de un cliente
9. Certificar que los requisitos del proyecto han sido entendidos y comprometidos por el equipo de trabajo
10. Identificar, si una prueba falla, que requisitos se ven afectados
11. Entregar una versión del producto, mas o menos estable, al cliente, ahora mismo
12. Decir el porcentaje de contrucción del producto o proyecto
13. Certificar el coste actual, «on the fly», del producto
14. Decir los riesgos activos que hay en tu proyecto
15. Enumerar las personas dedicadas al proyecto y el porcentaje de ocupación
16. Decirme cuando queda liberado un recurso en concreto
17. Decir las medidas correctivas que has tomado cuando has tenido desviaciones
18. Contar lo que se habló en la ante última reunión de seguimiento con el cliente
19. Enumerar las tareas y esfuerzo que te va a suponer la puesta en producción
20. …

Con esta pequeña muestra intento dar una idea del nivel de control de proyectos que exige el modelo.
Como ya he dicho, a mí, personalmente me ha enriquecido mucho, aunque no tenía mucha fé en ello, cuando comenzamos, ya hace más de un año y medio.

Es muy interesante la parte de histórico de estimaciones, trazabilidad, planificación, auditorías, métricas… si el tema despierta interés, en futuras entradas comentaré cada área de proceso por separado, que cosas buenas tiene y también las malas, que también creo que las hay, intentando dar una visión objetiva, personal y en base a la propia experiencia.

Me gustaría poder terminar recomendando algún libro o web que de una visión real del proceso, pero no he encontrado nada, al menos fácilmente legible, entendible y práctico.

Espero, al menos, haber despertado curiosidad por el CMMI y aportado un punto a favor de este modelo tan criticado, creo que en la mayoría de los casos por desconocimiento, y que se tenga en cuenta, como una opción para aportar calidad o madurez al desarrollo de software.

Es habitual que un equipo de desarrollo tenga un sistema de trabajo implantado, basado en la experiencia propia y en la definición interna de los procesos que componen el ciclo de vida de desarrollo de software.
Pero lo realmente esperanzador es que, cada vez más, nos encontramos con organizaciones y personas que quieren mejorar esos procesos.

Yo creo que en la industria del software está llegando un punto de inflexión en el que nos estamos dando cuenta de que no es suficiente con terminar los proyectos, hacer nuestro trabajo, sino que es imprescindible que los productos software tiendan a tener cero defectos. El uso de la ingeniería del software, las mejoras en gestión de proyectos, nuevas metodologías de desarrollo, pruebas de software, gestión de la configuración, integración continua,… nos está ayudando a pasar la línea que divide la artesanía de la ingeniería.

Sobra decir que hoy en día el software controla procesos de producción demasiado críticos y complejos como para invertir el 100% del tiempo en la construcción y olvidarnos de factores clave como el análisis, la planificación, pruebas, calidad…

Si hace tiempo dejaba entrever que la calidad en el desarrollo de software reside en la mejora continua, en la intención de buscar mejores maneras de hacer las cosas, hoy voy a presentar un roadmap (http://es.wikipedia.org/wiki/Roadmap) de mejoras en el desarrollo de software.

Este artículo no va dirigido a las grandes factorías de software, que tengan ya un sistema de trabajo guiado sobre el marco de una metodología, ¡no! El objetivo es mostrar a los equipos de desarrollo que están en fase de expansión y tengan la clara intención de mejorar en sus procesos de desarrollo, una serie de puntos a tener en cuenta y darles una visión del camino que (bajo mi punto de vista) deberían seguir.

A cada uno de las fases de este roadmap les he asignado una puntuación que indica el nivel de importancia (0-10) que, estimo, tiene cada una de las fases.

Este roadmap no sigue un orden marcado por ninguna metodología, insisto en que es una opinión personal:

 1.       Gestión de requisitos (7): No voy a destacar la importancia de realizar una buena ingeniería de requisitos, catalogarlos, priorizarlos, consensuarlos, enlazarlos con las pruebas funcionales, tareas… pero si quiero insistir en que un buen documento de requisitos, (sin entrar en formalismos ni burocracia)  product backlog, ERD, DRF,… va a ser la base de nuestro producto software.

2.       Gestión del código fuente (7): A menudo escucho frases del tipo, “no necesito un control de versiones, desarrollo en solitario”, por desgracia es un mito muy extendido. Poder consultar cambios y hacer un rollback a una versión es algo fundamental hoy en día. Cuando se trabaja en equipo las virtudes de los sistemas de control de versiones se multiplican.

3.       Gestión de tareas (8): Si la gestión de requisitos le daba un 7 de importancia, a esta fase  le doy más aún, creo que sin una buena gestión de requisitos se podría llegar a hacer software, pero sin gestión de tareas bien definidas, estimadas y priorizadas es muy difícil hacer software de calidad. Creo que es muy importante también integrar las tareas (workítems, jiras, etc) con la parte de código fuente que a la que afecta.

4.       Iteraciones (6): Versionado, hitos, prototipado, tags en subversion, maquetas, base lines (líneas base), sprints… el objetivo de las iteraciones es marcarse objetivos visibles, a corto o medio plazo y presentar al cliente cuando se tenga algo tangible. Por lo general el cliente no tiene la visión del producto que va a obtener y cuanto primero, y con más frecuencia presentemos el producto más nos vamos a acercar a la solución óptima.

5.       Documentación en entornos colaborativos (6): Si versionar el código fuente es importante, también lo es versionar toda la documentación asociado al proyecto (requisitos, diseño, actas,…), disponer de un entorno colaborativo (preferiblemente wiki) donde poder publicar información útil para el equipo de desarrollo y evitar, en la medida de lo posible, las dependencias personales, es fundamental. No me cabe ninguna duda de que el valor de una organización reside en el sumatorio de conocimientos de las personas que la conforman, pero debemos evitar riesgos, ya que las personas rigen su vida basándose en estados de ánimo, contratiempos, enfermedades, vacaciones,… al fin y al cabo ¡a todos nos puede tocar la lotería!.

6.       Securizar y respaldar ficheros (4): Aunque se podría hacer software de calidad, sin un buen sistema de respaldo, no quería dejar pasar la oportunidad de anotarlo como un punto importante de mejora, ya que, si mitigamos el riesgo de la pérdida de información, evitaremos sustos, imprevistos, posibles retrasos, etc. Creo que es importante respaldar la documentación, código fuente, pruebas, máquinas virtuales,… todo el resultado de nuestro trabajo.

7.       Gestión de proyectos (8): La buena gestión de proyectos nos va a ayudar a realizar un buen seguimiento, a integrar todas las partes de las que he hablado y de las que voy a hablar. Averiguar si vamos a llegar en fecha, a los hitos o sprints, a tomar las acciones correctivas oportunas, aseguramiento de la calidad, controlar los costes, certificar el porcentaje del proyecto realizado, aportar visibilidad… no me voy a extender, importancia: 8.

8.       Integración y entornos de trabajo (7): Un problema bastante habitual cuando se termina un proyecto es la fase de integración (puesta en marcha, pre-producción, producción…), la dificultad de realizar esta labor en un entorno diferente al de trabajo se mitiga definiendo un buen plan de integración y teniendo diferentes entornos de trabajo (desarrollo, pruebas y producción), aunque dependiendo de la importancia del proyecto se podrían definir mas entornos en el propio cliente (pre-producción, Ok Técnico…). Otro punto importante de tener diferentes entornos de trabajo (cada uno con su bbdd, application server, etc) es el de no interferir en el trabajo de los demás integrantes del equipo de desarrollo (testers), ni tocar datos de producción, ni siquiera trabajar con datos reales (ofuscados). Lo habitual es tener un servidor de máquinas virtuales y arrancarlas y pararlas en función de las necesidades puntuales.

9.       Pruebas funcionales o pruebas de caja negra (9): Creo que es la parte más importante en el aseguramiento de la calidad, (http://geeks.ms/blogs/rcorral/archive/2006/10/21/Pon-un-tester-en-tus-proyectos.aspx). Mucha gente cree que el tester se dedica a cacharrear con la aplicación e intentar romperla. La realidad no es esta o no debiera ser esta. El tester debe definir el plan de pruebas partiendo de los requisitos y verificando que se cumplen todos y cada uno de ellos, pasando este plan de pruebas en los diferentes entornos, utilizando técnicas definidas (AVL, conjetura de errores…), automatizando las pruebas en la medida de lo posible, indicando y responsabilizándose de las diferentes versiones del producto y dando validez al paso a producción. Es una responsabilidad muy grande y a veces la parte que genera código no valora y menosprecia este trabajo, ya que su objetivo es encontrar sus errores.

10.   Gestión de defectos (7): Si es importante disponer de un equipo de testers dedicados, no es menos importante catalogar y organizar todos los defectos que encontramos, incluso darle la posibilidad al cliente de notificarnos mediante un bugtracker de las anomalías del software. Esto puede resultar paradójico, ya que le estamos anticipando que nuestro producto va a fallar, el argumento que debemos utilizar es que no nos podemos comprometer a desarrollar un software sin fallos, aunque tendamos a ello y sea nuestro objetivo final, pero lo que si nos vamos a comprometer es con la calidad de gestionar, catalogar y por supuesto solventar cualquier fallo encontrado. Este tipo de herramientas aportan mucha información de alto nivel a la parte de gestión sobre la calidad de los desarrollos, con gráficas de bugs reportados y bugs reparados, tiempo medio de resolución, eficiencia de los testers,… ya que, aunque por todos es sabido, me gustaría recalcar que un proyecto de software no termina cuando termina la construcción.

11.   Guía de estilos de codificación (4): No voy a insistir en las ventajas que tiene el realizar un código limpio, legible y mantenible, que todos los miembros del equipo o de la organización sean homogéneos y cuidadosos nombrando variables, funciones,… pero no solo basta con escribir un documento, sino que es necesario una herramienta que vele por la integridad y calidad del código fuente, que antes de compilar el código verifique que sigue el estilo definido (como por ejemplo StyleCop).

12.   Pruebas unitarias (7): Es un aspecto clave si se quiere mejorar la calidad de nuestro software. Mejorar la complejidad ciclomática e ir aumentando la cobertura de código es algo fundamental. No puedo hablar de pruebas unitarias y no hacer referencia al blog de Ibon Landa. No voy a incidir demasiado en las ventajas de realizar pruebas unitarias, pero sí que me gustaría hacer un apunte si aún no estás haciendo pruebas unitarias, es más sencillo de lo que parece, solo debe marcarse un objetivo alcanzable de cobertura de código, y luego ir mejorando.

13.   Metodología de desarrollo (6): Si hemos llegado a este punto, sin duda, estamos aplicando calidad en nuestros procesos de desarrollo. Ahora nos falta orquestarlo todo con una metodología definida, no una mezcla de metodologías, ni tampoco una metodología única para todos los proyectos, pero sí que es interesante que elijamos consensuadamente con el equipo de trabajo y el cliente, un sistema de trabajo de los muchos que existen en el mercado y lo sigamos.

14.   Pruebas de rendimiento (5): No es algo estrictamente necesario, pero el coste de utilizar un profiler de rendimiento, es muy bajo y nos va a aportar mucha información de la eficiencia de nuestro sistema, de las funciones o hilos de menor rendimiento. Aquí incluyo analizadores de tráfico http e incluso profilers para bases de datos.

15.   Pruebas de usabilidad (8): Igual sorprende la calificación que doy a este apartado, pero el caso es que las pruebas de usabilidad y evaluación eurística de interfaces de usuario tienen una importancia enorme. Para el que no esté familiarizado con este tipo de pruebas lo explico brevemente: se coloca a una persona o varias personas ajenas al proyecto y con cronómetro en mano se le ordenan acciones (generalmente salidas de los requisitos funcionales) y se observa donde tienen más dificultades. Esto nos va a aportar una información muy valiosa, porque de este tipo de pruebas, saldrán unas acciones correctivas que nos indicarán cuanto es de usable nuestra interfaz y que partes de ella debemos mejorar, como por ejemplo añadiendo información en globos de ayuda, iconos mas descriptivos, tool tips, asistentes, manual de usuario…

16.   Integración continua (7): Para minimizar la complejidad de un desarrollo es necesario dividirlo, ¿pero que ocurre cuando toca unir todas las partes? Que nos encontramos con muchos problemas (porque se ha cambiado el modelo de datos, la capa de negocio, el servicio ya no devuelve un entero sino un float…) el objetivo de estas herramientas es encontrar los fallos cuanto antes, porque es menos costoso realizar un cambio en lo que estás trabajando hoy, que en lo que trabajaste ayer (http://www.alcohen.com/node/8). También es interesante que, antes de compilar, verifique ciertos parámetros de calidad, que corra las pruebas unitarias, verifique el estilo y legibilidad del código fuente, que gestione y reporte los errores encontrados,… Si aún no tiene herramienta de integración continua, vaya corriendo a la farmacia de guardia más cercana a comprarse una!! Ya que las ventajas son muchas (http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix)

17.   Gestión avanzada de métricas (9): A más de uno le parecerá extraño que este punto no vaya con la gestión de proyectos o incluso la puntuación tan alta que recibe…, pero realmente es una parte de fundamental de una buena gestión de proyectos, pero lo he separado porque es una práctica poco extendida y creo que tiene una importancia tan grande que ese es el primer motivo de sacarlo fuera. El segundo motivo es que si no tenemos todo lo anterior no vamos a poder realizar una buena explotación de los datos que los diferentes sistemas nos van a aportar. Disponer de datos en tiempo real, que te indiquen cuando vas a terminar el proyecto, la velocidad del equipo de desarrollo, porcentaje real completado, la precisión de las estimaciones, la productividad de los desarrolladores, la importancia de los errores, la efectividad de los testers,… todo esto nos va a aportar algo imprescindible en el software, la visibilidad, del desarrollo y de la calidad. Lo mas importante que nos aportan las métricas son eso!! valores numéricos, ya que, lo que es medible es mejorable y, a largo plazo, vamos a saber si ha mejorado, y por el contrario lo que no se mide, es muy dificil de mejorar.

 

Espero que no se haya hecho muy pesada esta lectura. Quiero aclarar, ¡por supuesto!, que las mejoras no acaban aquí, ¡es más! Estoy seguro que alguno va a aportar algún paso más en este roadmap, que aún nos queda mucho que aprender y mejorar en el desarrollo de software. El objetivo de este artículo no es dar lecciones… el objetivo es ayudar a las personas y organizaciones con clara intención de mejora, a saber por dónde puede ir su siguiente paso en la mejora continua…, que, entre todos, vayamos dando pasitos para madurar la industria y el desarrollo de software… y que, algún día, el desarrollo de software se considere y se valore como una ingeniería, evitando así, que vuelvan los fantasmas del pasado. (http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all)

Esta mañana (Jueves 22 de Enero de 2008) tuve el placer de dar una charla a los alumnos de Ingeniería Informática del centro universitario CESINE, asistieron alumnos de 1er curso, segundo y tercero.

En la charla comentamos, con los alumnos, como aplicar procesos que mejoran la calidad del software, como el software ha evolucionado hasta la actualidad, y como controla procesos de producción críticos. Lo «verdes» e «inmaduros» que estamos en la industria del software comparada con otras industrias.
(Creo que alguno se durmió) 😉

Aquí dejo los enlaces para la descarga:

CIC-Calidad en el desarrollo de software.pdf (1 Mb), en PDF.

CIC-Calidad en el desarrollo de software.zip (2 Mb) , dentro del ZIP va el PowerPoint.

Un saludo!!

Estaba preparando un post (a petición de varias personas) de como integrar la libreria ExtJs con ASP.NET para obtener interfaces de usuario ricas en entornos web, tal y como explico en un artículo anterior: Calidad en la interfaz de usuario. Hace algún tiempo me preguntó Jorge Serrano por la integración de esta libreria con ASPNET, y supongo que también haya avanzado algo en este area… ¡seguro que también puede aportar algo!

La librería de controles o Framework Ext es algo que impresiona a primera vista, (por la riqueza visual), es muy llamativo y el rendimiento es muy bueno … El caso es que buscando, buscando… me he tropezado con el blog de Rodrigo Diniz el cual ha publicado en codeplex una API para manejar los controles ExtJs.

El primero de los links que os dejo es este, http://extendersamples.rodiniz.com/, en el podéis navegar por los diferentes controles Ext y visualizar el código html y Javascript y en otra pestaña, el código en c#… (Es probable que aquí ya nadie sigua leyendo, porque el ejemplo es tan bueno, que la mayoría ya estarán abriendo el Visual Studio, pero paciencia que aún hay mas…)

Aquí os dejo la url para descargarlo (hazme click), Es una librería muy currada, además tiene versiones para Framework 2.0 y 3.5, también ha publicado un proyecto de ejemplo donde ver el uso real.

La librería ayuda y mejora el uso de los controles Ext, no de todos los controles! pero si de los mas comunes. También quiero mencionar esta otra ExtSharp, cuyo uso, facilidad e integración con el intellisense de visual studio son estupendas.

Otro proyecto que está en periodo de pruebas es el de crear un editor gráfico, http://www.screencast.com/users/JackSlocum/folders/Default/media/f7450651-778b-4bbc-9fc4-4e921a7a2705.

Otra solución que me ha sorprendido es la de Coolite Toolkit, http://examples.coolite.com/, el cual permite desarrollar en .NET con las librerías de Ext.

Por si alguien todavía le queda alguna duda de la potencia de este Framework le recomiendo hacer click aquí y pulsar F11 en su navegador y ¡pellizcarse! y comprobar que lo que está viendo es en realidad una aplicación web!! 😉

En relación a los sistemas operativos en Web y cosas similares, quisiera ampliar este artículo, con el permiso de Pedro, Frank Torres y Juanjo Olabarria, los cuales me han aportado estos enlaces:

http://demo.eyeos.org/?lang=es, Un sistema operativo en toda regla.
http://g.ho.st/vc.html?isPopup=true&language=es (entrar como invitados) mas completo que el anterior… está hecho en flash (en versión Alfa), integra un disco duro virtual. 

Y volviendo a ExtJs… con respecto a la licencia de uso de ExtJs, no llega a 300$, algo irrisorio, valorando la «calidad» que te aporta.

Para el que esté más interesado, en nuestra experiencia, el primer proyecto que abordamos (hace ya casi un año) con tecnología ExtJs era un sistema de generación de informes, el cual integraba ASPNET, WCF, Reporting Services y el Framework en cuestión, pero el resultado ha sido tan bueno, que como consecuencia, hemos hecho mas desarrollos con la integración de estas tecnologías… Ya que hablo de estos proyectos aprovecho para agradecer y felicitar a mis compañeros por el esfuerzo y el excelente trabajo realizado (David Marín Oujo, María Galán, David Vilasack e Israel Llata) sin ellos, no hubiese sido posible nada de esto…

De la lectura de este artículo, solo espero que cuando tengamos que preparar una interfaz web nos lo pensemos dos veces y valoremos el uso de ExtJs.

Recientemente me han preguntado sobre cómo aplicar calidad en las interfaces de usuario…

 
Dejando de un lado las tecnologías para mejorar la experiencia de usuario como Ajax, Silverlight, WPF o incluso combinaciones de hardware y software como Microsoft Surface, voy a centrarme en la creación de formularios con controles genéricos y como se deben aplicar.

No voy a entrar a valorar si la mejora manera de mostrar datos a un usuario es un grid o tarjetas de presentación, solo voy a dar algunos consejos que me han servido para mejorar las interfaces de usuario… ¡Bien! Pues aquí entran en juego muchos parámetros como la accesibilidad, la usabilidad, el rendimiento… lo cierto es que existen muchos estudios de este tema, solo hay que buscar un poquito en Internet…

La premisa básica para obtener una buena interfaz de usuario es la sencillez (el mejor ejemplo: google), con el menor número de controles y opciones posibles. De echo mi opinión personal es que el éxito de google, debe mas a su interfaz de usuario que al algoritmo de búsqueda o al PageRank.
En primer lugar, como es evidente, la interfaz de usuario es dependiente del tipo de aplicación que estemos desarrollando, (web, escritorio, móvil…), ya que las aplicaciones web y las aplicaciones móviles tienen carencias por su propia arquitectura. Voy a centrarme en las aplicaciones de escritorio, que son las que mas posibilidades permiten, aunque muchos de estos consejos se pueden extender a otro tipo de aplicaciones.

Voy enumerando y aclarando:

• Interfaz homogénea: es muy importante que los formularios de nuestra aplicación (y muy recomendable que los formularios de todas nuestras aplicaciones, incluso todas las aplicaciones de nuestra compañía), sigan un patrón común de funcionamiento y un estilo visual determinado (es recomendable tener escrita un guía de estilos que aclare estos temas).


• Posicionamiento de controles: Lo natural es que el usuario vaya a buscar el botón de cerrar instintivamente en el lugar donde lo tienen el resto de aplicaciones, el botón de buscar suele estar arriba a la derecha, la ayuda se suele sacar pulsando F1, … Es muy importante no inventar nuevos métodos de trabajo sobre las aplicaciones y seguir los estándar. También es muy importante que la posición física de los controles sea siempre la misma.


• Acciones comunes: los botones de navegación, botones de visualización edición, eliminar, exportar, imprimir… las acciones típicas deberán estar en una botonera común a toda la navegación, ¡y siempre la misma!, de modo que todas las acciones frecuentes a los formularios estén accesibles desde un punto fijo, además de este modo, se clarifica el contenido. Es muy útil en formularios MDI, hacer que la botonera haga uso sobre el formulario que tiene el foco (Active Form).
  


• Sobrecarga de controles: Es muy util utilizar un botón de acciones: Las acciones específicas de un formulario nunca deberán ser botones, ya que las aplicaciones evolucionan y los mantenimientos perfectivos van a tener lugar (no olvidéis que debemos seguir una metodología de programación orientada al “cambio ágil” y el hecho de añadir controles a nuestros formularios nos obliga a rediseñarlos y a evolucionar a formularios como este o este otro). Para este tipo de problemas se suelen utilizar botones de acciones múltiples, como el que muestro aquí.


• Mantener al usuario informado, todas las acciones que se estén llevando a cabo deberán mostrar un mensaje en una zona de la pantalla común dedicada a ello. Barras de progreso, si es posible, cambiar el icono a AppStarting, deshabilitar botones que puedan dar lugar a conflicto o a sobrecargar servicios o accesos a datos. El usuario debe tener el control de la aplicación en todo momento, por lo tanto ha de tener información de todo lo que la aplicación realiza
  

Recomendaciones al rendimiento: Este es el punto más delicado y que mas “arte” requiere;

• 
  
  No sobrecargar el hilo principal de la aplicación, ¡fundamental!


• 
  
  Generar hilos por cada tarea secundaria o tareas pesadas, el objetivo es la sensación de multitarea. El objetivo es que no haya una interfaz que no responda, y provoque que el usuario se impaciente (ya sabemos lo que ocurre con un usuario impaciente, en el mejor de los casos uso descontrolado de ctrl, alt, supr y en el peor, aporreo incontrolado del teclado)


• 
  
  Uso inteligente de la memoria, no es muy recomendable declarar muchas variables globales o trabajar con objetos pesados si no se van a usar, castings innecesarios, uso adecuado de las colecciones de datos, promover el uso de arraylist en lugar de otras estructuras más rígidas o pesadas,… pero de este tema habría mucho que discutir…


• 
  
  Tacañear los accesos a datos, evitar los select * from, ser cuidadoso con las consultas y si es posible implementar una capa de servicios con cacheo de datos.
  


• 
  
  …

El listado de recomendaciones sería mucho más amplio, no obstante, espero que la lectura de este artículo haya orientado a alguien o haya dado alguna idea para crear una interfaz de usuario con calidad y por otro lado no haya aburrida demasiado 😉
En este enlace dejo un listado completo de recomendaciones en interfaces de usuario (http://www.raizlabs.com/blog/), y aquí las de Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyID=a1fe1066-bf4f-44fc-834b-676b311e83a2&DisplayLang=en).

Mas enlaces de Interés:

Principios, Prototipos y Heurísticas de Interfaces de Usuario. http://www.monografias.com/trabajos11/heuri/heuri.shtml
Estructurar una interfaz de usuario: http://www.alzado.org/articulo.php?id_art=486
Calidad y Usabilidad: http://www.torresburriel.com/weblog/2007/05/11/usabilidad-versus-calidad/
La interfaz gráfica: http://www.hipertexto.info/documentos/interfaz.htm

Para no extenderme demasiado (ya que me quedan temas de que hablar… accesibilidad, usabilidad, navegación, contenidos, organización…, pero no quiero aburrir), por último, quiero hablar un poquito de los nuevos Frameoworks AJAX que mejoran considerablemente la experiecia de usuario (GWT (http://extjs.com/products/gxt/), ExtJS (http://extjs.es/) )… recientemente hemos desarrollado una aplicación que integra ciertas tecnologías (Reporting Services, WCF, ASPNET 3.5 y ExtJS) y con respecto a la interfaz de usuario, la integración de ASPNET y controles EXT. El resultado ha sido excelente!!, una aplicación web con una riqueza visual similar a una aplicación Windows nativa.

Y ya termino… 

El desarrollo de una buena interfaz de usuario es una tarea complicada, que requiere mucho sentido común (el menos común de los sentidos), mucho pensar y ponerse en el lugar del usuario. Para el personal del equipo de desarrollo es tan complicado, porque una interfaz no son mas que controles (grids, combos, listas…) pero para el usuario, una interfaz de usuario es una pantalla donde aparecen cosas que no concuerdan con su mundo real… no aparecen destornilladores, ni grapadoras, ni archivadores… y es nuestra tarea hacer esa transición, del mundo real, a la pantalla del ordenador, lo menos traumática posible. Por eso cuando desarrollemos interfaces de usuario debemos pensar en las secretarias, funcionarios, operadores, mecánicos, carpinteros… y ponernos en su lugar!

Seguro que así vamos a mejorar la calidad de nuestras interfaces de usuario!!

El hecho de realizar un trabajo de calidad no siempre es suficiente para culminar un buen desarrollo. Suele ser habitual, que el trabajo específico que le propones a un cliente pueda ser de utilidad (al menos la esencia o la idea) para otros muchos. En un post anterior apuntaba que un índice de calidad de un producto, era el número de clientes que disfrutaban de ese producto, o mejor dicho, el número de clientes a los que propones una solución partido del número de clientes que la implantan mas el logaritmo neperiano del número de clientes satisfechos o algo así 😉 .

Recientemente nos ha ocurrido, que un desarrollo en concreto que le estábamos realizando a un cliente, se lo propones a otro y dice “¡que cosa más estupenda!”. Cuando se da esta situación (que un desarrollo puede ser de interés para varios clientes) y la ocasión lo permite (no existen impedimentos de propiedad intelectual), es habitual realizar una hoja de producto, con la que poder promocionarlo. Estas hojas las lleva el comercial en su carpeta repleta de hojas comerciales y sus PowerPoints corporativos y hasta aquí llega nuestro trabajo. El comercial como su nombre indica, intenta contar lo que hace el producto a nivel funcional, pero es muy probable que no lo cuente con la «ilusión» que lo contaría el programador que lleva dos meses trabajando en ello.

El planteamiento para los tiempos que corren debe de ser diferente.
Año 2008, las capacidades que internet (la web 2.0, b2c, comercio electrónico, blogs, youtube…), nos brindan, son ilimitadas y debemos aprovecharlas. Es muy útil abrir una web dedicada al producto, la cual puede ser consultada 24 horas al día, pero este trabajo (desde mi punto de vista) no compensa el esfuerzo de la promoción. Hoy en día es más útil realizar un «pequeño» video promocional e introductorio en el que destaque, a grandes rasgos, las capacidades del producto, seguidamente identificar los clientes que podrían estar interesados y enviarles el video (si el producto es de verdadero interés, el cliente te solicitará más información del mismo y ya podrás mandar al comercial 😉 bueno! mejor que vaya alguien que sepa de informática).

La realización de un video promocional lleva un trabajo considerable, pero es claramente menor que el de realizar una web o «adiestrar» a un comercial en una buena presentación del producto. A continuación os presento el último video promocional que hemos realizado, consiste es la personalización, instalación silenciosa y restricción de funcionalidad de la barra de Google (para el que no la conozca, similar a la de vista) y la creación de gadgets para ella.
No quiero extenderme más en el producto, ya que la promoción del producto no es el objetivo del post.

Como veis, el video tiene un objetivo claro, que es despertar la curiosidad del espectador, pero no explicarle el detallado y completo funcionamiento del sistema.
Los pasos a seguir son los siguientes:

1. 
   
   Identificar un producto de interés


2. 
   
   Concretar el mensaje a enviar


3. 
   
   Realizar el video promocional (objetivo, estilo, guión, espectador…)


4. 
   
   Identificar los posibles clientes interesados y hacerles llegar el video


5. 
   
   Esperar un tiempo prudencial


6. 
   
   Atender a los clientes interesados con una demo


7. 
   
   Sugerir y preguntar al resto de clientes por la recepción del video

Resumiendo, realizar un trabajo de calidad, tiene, en ocasiones, que culminarse con una buena labor comercial y promocional, y las ventajas que te da la realización de un video de este tipo son estupendas. El objetivo principal es vender el producto, ¡pero no es el único!, ya que, aunque con algún cliente no tengamos éxito en la venta, (no solamente es interesante vender un producto), le haremos saber, que somos capaces de realizar soluciones de todo tipo, y si la presentación audiovisual que realizamos tiene un mensaje claro, transmitir calidad al espectador.

Promoción, promoción, promoción

Cada vez que comenzamos un nuevo desarrollo, generalmente, podemos identificar una serie de tareas que son habituales y repetitivas.
Bien es cierto que, para algunas de estas tareas, son de utilidad las Software Factories, que no son más que un kit que sirve a arquitectos y desarrolladores como base para la implementación de buenas prácticas en el desarrollo de aplicaciones. Pero se quedán ahí, en la base.

El desarrollo de software moderno requiere algo más que una base…, requiere una estructura robusta, firme y estable que no sólo nos de la guía en inicio del desarrollo, sino que nos acompañe y nos obligue oriente durante todo el proceso de producción, siguiendo una metodología de base y unas buenas practicas.

Antes de continuar, quisiera aclarar, el significado de la palabra «Framework«, que no es mas que una serie de funcionalidades, previamente diseñadas, que nos ayudan en el desarrollo convencional de software, este término puede dar lugar a confusión con Framework .NET, que como su propio nombre indica también es un Framework, ya que nos provee de una serie de funcionalidades preestablecidas.

Retomando el tema de las tareas habituales y repetitivas… en la mayoría de los desarrollos, nos vamos a encontrar, con la necesidad de hacer una conexión a datos, cargar grids, filtrarlos, hacer búsquedas, que dichos grids nos lleven al detalle del registro, eliminarlo, modificarlo o añadir un nuevo registro, sacar un informe, exportarlo a Excel, pdf, una gestión de excepciones, log de acciones, un cacheo de datos… además en todo desarrollo, vamos a tener que idear un sistema de seguridad basado en roles de acceso y permisos, un modelo de entidades que facilite el acceso a datos y lo haga independiente… ¡esto para empezar! … pero también sería interesante que hubiese una capa de servicios, un generador de sentencias SQL, que todos los formularios siguiesen un patrón de diseño y comportamiento común dependiendo de los colores corporativos, que todas las aplicaciones estuvieran centralizadas, que compartir datos entre aplicaciones fuese fácil, etc…

Ahora imaginemos que diseñamos e implementamos una arquitectura que contempla todas estas ideas y todas las que se nos vayan ocurriendo, y que fuese un modelo extensible basado en interfaces, que con, simplemente, escribir una cadena de conexión, comenzásemos a tirar formularios al estilo «code and fix» … «marchando un formulario tipo listado, que contenga las columnas de número de cliente, nombre, dirección y teléfono (click), la ficha asociada tendrá el resto de campos de la base de datos«, (y fuese el Framework el encargado de gestionar las altas, bajas, modificaciones y seguridad de los registros) sería algo estupendo!! … Al final tendríamos algo parecido a una churrera de formularios, uummm… Puesss que aburrido, ¿no?, … ¡¡¡en absoluto!!! Porque todos nuestros esfuerzos se centraran, en primer lugar, en preparar la arquitectura y el modelo de datos y en segundo lugar, en enriquecer y realimentar el Framework con nueva funcionalidad y así incrementar la calidad.

 http://www.youtube.com/watch?v=DI0Bdr9QKwA

 ¿Alguna duda? ¿Sí? vamos allá…

 ¿El coste?
Evidentemente el coste de diseñar e implementar una estructura de este tipo, es grande, pero a largo plazo, merece la pena. La calidad siempre se nota a largo plazo.

¿La productividad?
La productividad es muy alta, ya que no es necesario saber tanto .NET para hacer una aplicación, con centrarse en la capa de presentación, basta.

¿La estabilidad?
La estabilidad es el punto fuerte, ya que cuantas mas aplicaciones desarrolles con un framework, mas testado, robusto y evolucionado estará. Los bugs en producción tienden a cero y el rendimiento es alto.

¿La rentabilidad?
Una vez que el framework es estable y «la churrera» funciona a la perfección, podemos reducir el tiempo de desarrollo de forma considerable.

¿El usuario?
¡Encantado!, porque todos los formularios de sus aplicaciones tienen el botón de guardar y cerrar en el mismo sitio, con el mismo color…. en definitiva el comportamiento de sus aplicaciones es el mismo.

Por lo tanto, si incrementamos todos estos factores obtendremos un producto de mayor calidad y una estructura organizada para desarrollar nuestros proyectos.

Ahora cuento mi experiencia…, adjunto presentación por si alguien quiere más detalles (Presentación CIC Framework). Desde el punto de vista del desarrollador, el aprendizaje y la evolución fue muy satisfactoria y enriquecedora… sobre todo, el tener que pensar, que cada línea de código tiene que ser genérica para todas las aplicaciones y parametrizable mediante ficheros de configuración o de recursos, te obliga a ver las cosas desde otro punto de vista, te orienta el desarrollo a la reutilización y la modularidad (dos síntomas muy bueno de calidad), el dotar a esa estructura de inteligencia dependiendo del tipo de entorno… y con respecto a la rentabilidad, pues a medio plazo grande y ahora que el producto ya tiene madurez, muy grande.

Es obvio que cada uno de nosotros tenemos nuestras funciones de uso habitual (…), pero si toda esa funcionalidad la completásemos, organizásemos y la orquestásemos, para obtener una estructura que nos guie en nuestros desarrollos, seguro que obtendríamos mayor rendimiento y calidad en los mismos.

Lo que no cabe duda que una estructura de este tipo testada, estable, confiable, modularizable, parametrizable y ampliable nos aporta calidad a los desarrollos, por ello, y como es habitual, animo a las mentes inquietas, que todavía no lo han hecho, a diseñar y estructurar un Framework que aporte calidad sus desarrollos, que les ayude a ser más eficientes y no perder el tiempo en tareas rutinarias.

 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.
  
  

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:

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 😉