SEPG North America 2013

Hoy he recibido un correo de notificación del CMMI Institute, recordando la celebración de un interesante evento que tendrá lugar en Pittsburg el próximo 1 y 2 de Octubre de 2013. Nada menos que el SEPG North America 2013, un evento anual (bueno, vale, hay otros similares en Europa y Asia, también anuales), donde se tratarán temas candentes y de actualidad como por ejemplo:
- Kanban y CMMi
- Flexibilidad Agile: cómo CMMi hará que Agile sobreviva y se fortalezca.
- Implementación ágil de CMMi
- Métricas.
- Desarrollo de Software seguro con Secure by Design for CMMI-DEV
- Microsoft IT Data Management Maturity
...y más.

Me parece muy interesante el esfuerzo por simplificar y acercar CMMI al movimiento ágil, y en general, al resto de iniciativas y tendencias actuales en el desarrollo de software. Espero que sean muy interesantes, y aunque no creo que esté presente, espero poder acceder al material de los eventos y poder estudiarlos. Algunas de las conferencias prometen bastante.

Aunque ya os he puesto más arriba el enlace principal al evento, os adjunto otro par de enlaces directos a:
- Agenda: Conferencias y ponentes.
- Acerca de: ¿Qué son las conferencias SEPG?

Métricas - Las 7 preguntas al analizar los datos

Los datos son los datos. Y tendemos a darles mucha importancia. Y la tienen. Sin embargo, a la hora de interpretarlos, no solemos tener la disciplina de estudiar su origen y circunstancias. Lo que es peor, no solemos tener criterio a la hora de agregarlos o no a los demás datos recopilados.

Aquí van 7 preguntas que me parecen fundamentales a la hora de analizar los datos recopilados en un proceso de MA (Medición y Análisis), o en general en cualquier proceso de Métricas:

1. ¿Quién recopiló esos datos? (Esperemos que fueran las mismas personas que se formaron en las técnicas adecuadas de recopilación de datos)
2. ¿Cómo se recopilaron los datos? (Esperemos que fuese mediante herramientas/procesos automatizados, y que no requiriesen esfuerzo adicional al trabajo diario)
3. ¿Cuándo se recopilaron los datos? (Esperemos que fuese al mismo tiempo o en el mismo día que las tareas relacionadas a dichos datos)
4. ¿Qué significan esos valores? (¿Ha habido cambios recientes en el proceso? ¿Realmente esos valores me dicen lo que quiero o necesito saber?)
5. ¿Cómo se obtuvieron esos valores calculados a partir de los datos originales?
6. ¿Qué fórmulas se usaron para calcular esos datos? (¿Están midiendo lo que necesitamos medir? ¿Funcionan? ¿Son relevantes? ¿Son obsoletos?)
7. ¿Estamos recopilando los datos de la forma correcta? ¿Son los datos correctos? Los datos deberían ser consistentes, y la forma en que se recopilan, a su vez, también debería ser consistente. Hay que asegurarse de que los datos tengan la información requerida para los análisis que necesitamos llevar a cabo.

Veamos un ejemplo:
Tenemos unos datos de defectos encontrados en pruebas unitarias. Nos haríamos cada unas de las preguntas y analizaríamos las respuestas:

1. La persona nos dará una pista de en qué circunstancias se obtuvieron los datos, si han sido automáticos, o si se han rellenado de forma asíncrona al proceso de pruebas.
2. Si el proceso no es automatizado, será más propenso a errores o a manipulación deliberada. En este caso nos va a interesar saber las ejecuciones que se han hecho de los tests, y cómo se han obtenido los defectos. ¿Se han lanzado todas las pruebas, o se ha parado al llegar a un error grave?
3. Si el proceso no es automático, habrá que ver cuándo se han rellenado esos datos. Normalmente, todo lo que no se rellene en el mismo día en que se produce, es mucho menos fiable.
4. Significado: hay que interpretar si ante las mismas pruebas, ayer hubo 5 fallos, y hoy 10. ¿Qué ha cambiado en el código? ¿Y en el proceso? ¿Se han modificado los tests para que se justifiquen ese doble nº de fallos? ¿Ha habido un programador menos experimentado que haya estado tocando hoy el código? etc, etc. Hay que tener cuidado, porque seguramente los datos no nos van a dar las respuestas a las preguntas que busquemos (en este caso, buscamos la calidad del código).
5. Similar a la siguiente.
6. Las fórmulas (manuales o automáticas), pueden haber tergiversado el significado de los datos originales, eso hay que tenerlo en cuenta.
7. Hay que ver si estamos trabajando con los datos de forma consistente. El que haya variaciones (ayer 5 fallos, y hoy 10), puede tener muchos significados. Además, es posible que errores en diversas etapas del proceso de recogida y cálculo hayan alterado los datos o pervertido su significado.

Como resultado, siguiendo el ejemplo de que ayer teníamos 5 defectos en unit testing, y hoy tenemos 10, las preguntas pueden llevarnos a varias conclusiones:

• Se han alterado los casos de prueba, o el número de unit testings existentes.
• Por algún motivo, se han ejecutado más casos de prueba o más pruebas unitarias.
• El proceso automatizado o manual, ha cambiado.
• Las fórmulas usadas o la forma de recogida ha cambiado.
• Nuestra calidad de código es la mitad de ayer.

Estaremos tentados de ir directamente a la última conclusión. Sin embargo, es posible que cualquiera de las anteriores (o muchas otras), sean realmente las conclusiones. Como ingenieros de software, es nuestra responsabilidad llevar a cabo correctamente tanto el proceso como la interpretación de los resultados.

Fuente: Interpreting the CMMI: A Process Improvement Approach (by  Margaret K. Kulpa and Kent A. Johnson )

¿Cómo se mide la calidad?

... O más bien debería ser más específico: ¿cómo se mide la calidad del software?

Parece ser que la calidad es el atributo favorito a la hora de ser incluído en propuestas y propaganda variada de los productos software, pero nunca nos hemos preguntado ¿qué es la calidad? ¿cuánta calidad tiene? ¿Si no puedo medir la calidad de un producto para qué me sirve que lo pongan en un folleto o hablen de él los comerciales? (si hasta los terremotos tienen una medida universal gracias al señor Richter).

Hace poco leía un blog y me sorprendía la frase: "no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad". Por desgracia para el mundo del desarrollo de software, no es así. Claro que se puede ahorrar calidad. Simplemente, eliminando las actividades que le aportan y aseguran esa calidad.

¿Dónde está la calidad?:

• En arquitecturas conocidas, probadas y para las que se han obtenido datos de experiencias (buenas prácticas, problemas a evitar, cómo mejorar en el futuro, etc.) Es lo que se conoce como mejora continua.
• En las metodologías de trabajo conocidas y probadas. Y no sólo hablo de desarrollo. También de repositorios de documentos, tener claro quién es el responsable de qué...El tener el control de qué hay, dónde está, cómo acceder a ello, y cómo usarlo.
• En las pruebas del software antes de la entrega al cliente.
• En las pruebas del software en la implantación.
• En las auditorías de calidad.
• En las auditorías internas del equipo de desarrollo.
• En las revisiones entre pares (sí, sí, las Peer Review famosas).

¿Cómo medir la calidad? Pues midiendo la calidad de nuestro proceso de desarrollo:

• Calidad del análisis: ¿cuántos requisitos se han modificado? ¿cuántos se han añadido? ¿cuántos se han eliminado?
• Calidad del diseño: ¿cuántos cambios se han producido en el diseño técnico?
• Calidad de la arquitectura: ¿cuántos cambios de arquitectura se han producido?
• Calidad del desarrollo: ¿cuántos defectos se han detectado en pruebas unitarias?
• Calidad de las pruebas: ¿cuántos defectos ha detectado el cliente en producción vs defectos encontrados en pruebas en general? ¿cuál es el ratio nº defectos encontrados vs horas invertidas en pruebas?

¿Y la calidad del producto? Pues aunque está relacionado, tendríamos otros factores:

• Tiempo que lleva el cliente usando el producto. En mi opinión no es significativo. Por razones varias, el cliente puede verse obligado a usar un pésimo software. Realmente el problema está en la competencia y en el precio. Si es suficientemente barato un software alternativo, poco importará la calidad de nuestro software, es probable que el cliente acabe actualizándolo por otro distinto, si los costes encajan.
• Satisfacción del cliente. Bueno, volvemos a la cruda realidad. ¿Quién es el cliente? ¿El director general? ¿el que compró el software? ¿El jefe de departamento que lo usa? ¿Los usuarios finales? Al final, la satisfacción es difícil de medir. Bueno, para eso podéis leer mi anterior blog sobre encuestas de satisfacción.
• Número de fallos en producción. Realmente no sólo es una medida de calidad del software, sino de su proceso de desarrollo.
• Número de clientes. Pues ahora mismo se me ocurren unos cuantos ejemplos de software vendido por millares (por no decir millones), y de calidad pésima. Al final, el número de clientes lo deciden una serie de factores ajenos a la calidad: precio, esfuerzo comercial, renombre de la marca comercial, etc.
• Número de años en uso. Uf. Por esa regla de 3, tendríamos que el software hecho en cobol en los años 80 debía de ser de calidad asombrosa, porque se ha usado hasta hace muy poco, o sigue en uso. A la hora de la verdad, este factor no depende de la calidad, sino de la competencia, de la facilidad de actualizar el producto. Si encontramos repuestos de ruedas, las cambiaremos fácilmente. Si no encontramos repuestos, pues...habrá que fastidiarse y seguirlos usando (independientemente de su calidad).

Lo importante es destacar que no tendremos calidad del producto basándonos únicamente en tener equipos de personas buenas y maravillosas, todos senior y super-motivados, y blah, blah. La calidad se consigue a través de un método, proceso y control. Quien confunde el control con desconfianza en el equipo, tiene un problema (y más vale que se lo haga mirar).

El siguiente link está en la línea de lo que digo, aunque hay varios argumentos en los que no estoy 100% de acuerdo (ojo, no digo que él esté equivocado):
http://geeks.ms/blogs/msierra/archive/2008/08/25/_BF00_C_F300_mo-se-mide-la-calidad-en-el-software_3F00_.aspx

¿Cuándo se puede dar por terminado un proyecto?

Vaya. Esta vez he dejado pasar unos cuantos días desde mi último blog. Y es que mi últimos proyectos me estaban absorbiendo por completo.

Vamos a tratar un tema que tanto en las metodologías, como en los distintos entornos de trabajo, siempre se da por supuesto, y se deja un poco al azar. Y es que ¿tenéis claro cuándo se puede cerrar un proyecto?

Parece algo trivial, ¿no? Cuando el proyecto se termine...se habrá acabado y por tanto, se cierra. Pues no.Vamos a introducir algunos conceptos para entender de qué hablamos:

• Cierre: se denomina cierre de un proyecto, al final del desarrollo. En realidad, el desarrollo no termina cuando se produce la subida al entorno de producción. Un desarrollo termina...cuando así lo determina el contrato. Y es que por contrato (y así lo suelen recoger las metodologías), se incorpora un período de soporte distinto del de mantenimiento. Se le suele llamar soporte post-implantación (aunque el nombre puede variar según la metodología que tratemos).
• Soporte: como acabamos de comentar, se llama soporte al período posterior a la puesta en producción (el Go-Live en tecnologías SAP). El soporte lo realiza el mismo equipo de desarrollo, y aunque sus actividades suelen ser similares a las de mantenimiento, existen diferencias con la fase de mantenimiento. Por ejemplo, no aplican los ANS.
• ANS: acrónimo de "Acuerdos de Nivel de Servicio". Son las condiciones de servicio que por contrato, estipulan la forma de colaboración entre el proveedor del servicio y el contratista. Suele incluir penalizaciones y/o bonificaciones en función de varios parámetros como pueden ser el tiempo de respuesta, la calidad del servicio, etc.
• Mantenimiento: es la fase del ciclo de vida del software que tiene lugar tras el cierre (no tras la puesta en producción). Tras la puesta en producción, hay un período de soporte en el que el proveedor del desarrollo software ha estabilizado la solución, se produce el hito del cierre, y después, el inicio de la fase de mantenimiento. Esta fase de mantenimiento la puede llevar a cabo un proveedor distinto del de desarrollo (otra empresa diferente).

Y tras este rodeo de explicaciones, volvamos al tema. Tras el desarrollo, hay un período de soporte, normalmente de tiempo limitado. Pero...¿debemos dejar que un software erróneo, inadecuado o inestable pase a la fase de mantenimiento? ¿Cómo sabe el cliente que el producto que ha recibido y que ya está en producción, está como para dar salida al proveedor de desarrollo? Recordemos que es en este punto cuando suele terminar de cobrar el proveedor de desarrollo. El cliente no querrá terminar de pagar por un producto hasta que este no esté correcto, pero...¿qué entendemos por correcto?

Es en esta situación, en la que un proceso de cierre entra en acción, definiendo una serie de parámetros que permitan de forma cuantitativa identificar si la solución desarrollada está Ok o no. No se trata de que no tenga errores. De eso, ya se encarga el mantenimiento que se hace tras el cierre del proyecto. Se trata de demostrar estabilidad y madurez tanto en la solución desarrollada, como en su implantación.

Normalmente, en todas las metodologías, la forma de realizar verificaciones (peer review, auditorías, milestone reviews, etc) es mediante checklists de control. Sin embargo, estas checklists de control no suelen incluir factores cuantitativos. Aquí es donde las métricas suelen venir al rescate, incorporando factores cuantitativos.

Métricas: LOC

LOC es un acrónimo de "Lines of Code". Se utiliza como métrica en diversas situaciones, en las que se mide el número de líneas de código. Usualmente, se utiliza la variante "KLOC", que son miles de líneas de código.

¿Que qué le pasa a esta métrica? Pues que está maldita. Sí, sí, maldita. Ni el exhorcista más aguerrido podría devolverle el honor a esta defenestrada medida. Pero en fin, como me gustan las causas perdidas...ahí vamos.

¿Porqué está maldita? Pues porque basta presentarla para que la gente ponga caras raras, empiece a generar excusas, exponga argumentos en su contra, etc. Sin embargo, esta métrica tiene cosas a su favor, al menos en apariencia:

• Es fácil de medir. Pues sí, eso es cierto. Prácticamente cualquier entorno lo ofrece, y todos los plugins de métricas lo ofrecen.
• Es fácil de combinar: muchas otras métricas pueden venir referidas a ella (Ejemplo: "nº de defectos por cada mil líneas de código").
• Ofrece una medida aproximada del tamaño de un software, y de su complejidad. Pues vaya, esto también es cierto. Un programa de 1000 líneas no sé si será el doble de grande que otro de 500, pero más grande, sí.

Sin embargo, en este mundillo se encuentran muchos argumentos en su contra:

• No es una medida fiable de productividad personal. La respuesta obvia sería: "pues claro". En este mundillo de las métricas, uno aprende que lo primero que hace un programador es ver en qué medida la métrica puede valorar su trabajo. Es el caso típico de: "pensar mal". El problema es que las métricas están siempre para conocer el proyecto, y no siempre para ver el rendimiento de las personas. Sin embargo, sí puede obtenerse (y se debe, de hecho) métricas del estilo: LOC totales por persona, LOC modificadas por persona en un período, LOC nuevas por persona en un período, etc.
• Penaliza a lenguajes de alto nivel. Toma, pues claro. Los lenguajes de alto nivel están para eso. Para que con menos líneas, se hagan más cosas. Lo mismo que los frameworks y las librerías: para ahorrar líneas de código. Pero de nuevo volvemos a lo mismo: esta métrica permite comparar sólo en el caso de que se pueda comparar. No podemos comparar solamente lenguajes similares, sino proyectos en que la arquitectura sea equivalente.
• La complejidad de un software no depende de su tamaño. Hay programas muy pequeños, endiabladamente retorcidos, mientras que hay otros muy grandes, pero muy simples en concepción y ejecución. De nuevo, la respuesta es "pues claro". El problema es que una métrica no es más que un número. Para obtener conclusiones, normalmente hay que usar varias métricas e indicadores de los proyectos.

La conclusión vendría a ser que esta medida es para lo que es, para apoyo, para dar una visión orientativa que por sí sola nunca puede ser concluyente (lo que no deja de ser cierto en general para prácticamente todas las métricas).

Desde luego, si no podemos medir algo, no podremos decir que esté bajo control.