jueves, 26 de abril de 2012

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 )

miércoles, 18 de abril de 2012

Beneficios de implantaciones CMMi

¡Ey, hoy es mi post nº 100! Pues nada, tras un auto-abrazo, paso al tema.

Recientemente he leído una presentación que mostraba, de la mano de Grupo Pragma Consultores, unos resultados de encuestas a empresas certificadas CMMi .

Las empresas estaban certificadas nivel 2 (80%) y nivel 3 (20%), y se trataba de empresas de España, Argentina y Chile.

Los resultados de la encuesta muestran, que en contra de los argumentos que esgrimen los detractores de estos marcos de trabajo, tras una implantación de CMMi se obtienen una serie de beneficios:
  • Más del 90% observó mejoras en los tiempos/plazos.
  • Alrededor del 70% observó mejoras en los costes. Esto se apreció, a pesar de considerar que una implantación CMMi tiene un alto coste inicial. Desde luego, el beneficio neto no se aprecia a corto plazo.
  • El 100% observó mejoras más que apreciables en la calidad. Esto se apreció en una gestión más transparente, y un número de errores mucho menor.
  • El 80% apreció una mejora sustancial de la satisfacción del cliente. Esto se aprecia principalmente debido a una mejor gestión del proyecto y de los requisitos, así como una planificación realista y adecuadamente comunicada a todos los involucrados.
  • Más del 90% observó una mejor alineación de los objetivos del negocio con el desarrollo.
Los detractores de CMMi suelen alegar que éste modelo supone supone burocracia, exceso de documentación y sobrecarga de trabajo. Cuándo se les preguntó a los proyectos al respecto:
  • Ante la pregunta de si se detectó sobrecarga de trabajo y en qué porcentaje, la respuesta está en todos los casos por debajo del 10%, siendo ese máximo de 10% la sobrecarga inicial en gestión. Por supuesto, una vez instaurados los procesos, la costumbre y la mejora continua producen una disminución progresiva en dicha sobrecarga de trabajo.
  • Casi un 70% de los encuestados encuentra mucho aportado valor por la documentación que se generó
  • Más de un 80% de los encuestados ve la documentación como algo provechoso (especialmente en los temas de estimaciones y métricas). 
Finalmente, comentar que los resultados de la encuesta muestran que a la empresa, le proporciona de forma global unos interesantes beneficios:
  • ROI (retorno de la inversión) se considera positivo en más del 70% de los casos
  • Se generan nuevos negocios debido a la mejor percepción de los clientes, mejora en la comunicación con dichos clientes, y posibilidad de competir en mejores condiciones para conseguir concursos públicos, etc. Hay que recordar que para muchos clientes del sector público o privado, se exige CMMi nivel 2 ó 3 para optar a ganar un proyecto.

¿Significa esto que CMMi es bonito y maravilloso? ¿Todos los que se quejan de CMMi mienten?

Pues NO. A ver, CMMi es un modelo para la implantación de un marco de trabajo, que como ya he comentado otras veces, depende en su éxito de cómo se implanta. Las empresas no siguen CMMi. Lo que siguen son metodologías y procesos basados en CMMi. Unos procesos demasiado burocráticos pueden contentar a los gerentes, pero también enfadar y sobrecargar por ejemplo a los programadores. Por eso, la responsabilidad del fracaso sería en todo caso de los procesos implantados, no de CMMi.

¿Quién se preocupa de que todos en la empresa estén contentos con su forma de trabajo?

Pues la propia empresa, en su metodología y procesos, han de buscar ese equilibrio donde el control, el ligero aumento de documentación y la mejora continua, permitan lograr los objetivos marcados. Lo que no suelen tener en cuenta los detractores de CMMi es que la metodología que se usa, no se diseña para hacerles felices a ellos (que parece que todos queremos ser el ombligo del mundo!). La metodología resultante se enfoca a cumplir una serie de objetivos, que habrá definido previamente la empresa. Y es ahí donde el programador que tiene que hacer 2 o 3 documentos nuevos, lo puede interpretar como burocracia. De eso ya hablé en otro post (El Mito de la Burocracia).

lunes, 16 de abril de 2012

Orgulloso de tus éxitos, no de tus contactos.

Hoy estaba leyendo este artículo en el blog de HBR (Harvard Business Review).

Casualmente, este artículo está en la línea de un tema que ya estuve comentando recientemente en otro post: y es que hay que estar orgullosos y por tanto poner en nuestro currículum, los éxitos profesionales, no tanto nuestras afiliaciones a marcas conocidas o de prestigio.

Por ejemplo: hablar o hacer publicidad de ser empleado de IBM o tener relación con esa empresa, no es un éxito como tal. Es usar una afiliación o relación profesional con una marca conocida. Está bien tratar de vincular nuestra labor profesional con un gran número de marcas de prestigio, o de sentirse orgulloso de ello, pero eso no puede estar por delante de nuestros éxitos. Si no tenemos éxitos profesionales de los que hablar…mal asunto.

Y no me refiero a que no podamos mostrar orgullo en público o jactarnos de nuestra relación con una marca, empresa o institución prestigiosa. Eso está bien. Pero parece ser que se tiende a hablar más de ello que de los éxitos y logros.

Yo no quiero en mi equipo de trabajo a una persona que haya trabajado en megaproyectos o que haya estado vinculado por el motivo que sea a grandes empresas, marcas de prestigio, etc. Yo quiero gente que haya superado retos, que haya enfrentado grandes problemas, y que pueda demostrar su éxito ante tales situaciones (su éxito, o al menos que haya podido salir airoso gracias a sus habilidades profesionales). A veces un pequeño éxito (o ausencia de fracaso) ante los problemas grandes, es mejor que un gran éxito ante un problema pequeño. Y quiero explícitamente saber si lo hizo solo o en colaboración con otras personas. No me valen los que tratan de venderme que fueron los responsables de tal o cual proyecto, cuando quizás la acción la realizaron él y otras 20 personas.

Como comentaba en mi anterior post, es esta ocultación deliberada de información la que provoca que al final todo el mundo sea el líder, héroe y único responsable de llevar a cabo grandes hitos en desarrollo, pruebas, implantación, gestión de equipos, etc.

martes, 10 de abril de 2012

Testing (II) - Planificación de las pruebas


Este es el segundo de una serie de artículos sobre el testing y el cmmi:

En las pruebas, se suele dejar de lado aspectos fundamentales como son:
  • Preparación/planificación
  • Análisis
  • Reporting de los resultados de las pruebas
Hoy voy a intentar dar un repaso al primero de ellos.

Preparación de las pruebas.

Como cualquier tarea de verificación, las pruebas de software no pueden pasar por alto estas prácticas, que se encuentran por otro lado perfectamente identificadas en el modelo CMMI. Antes de empezar con las pruebas, tiene que haber una etapa de preparación en la cual se seleccionan los productos de trabajo a probar, se establece el entorno de pruebas y se disponen los  procedimientos y los criterios a aplicar en las pruebas. Para los fanáticos anti-burocracia, esta etapa puede ser mucho más simple de lo que estáis pensando. En un proyecto pequeño puede ser unas frases y listas de requisitos. Si siempre hacemos igual las pruebas, puede bastar hacer referencia a nuestro estándar o a un proyecto anterior.

En esta etapa para cada producto a probar se tienen que identificar los requisitos que tiene que satisfacer, y se tiene que buscar la estrategia de pruebas adecuada.

Se tienen que seleccionar los métodos de pruebas que se van a usar, por ejemplo decidir si es adecuado incluir  pruebas de cobertura de caminos, de carga, de esfuerzo, de rendimiento, pruebas basadas en tablas de decisión, y en descomposición funcional, y si se van a reutilizar casos de prueba.

Otro aspecto dentro de la preparación de las pruebas es el establecimiento del entorno de pruebas. Una prueba de producto puede requerir simuladores, emuladores, generadores de escenarios, herramientas de reducción de datos, controles ambientales e interfaces con otros sistemas. De las características del entorno de pruebas se derivan las tareas necesarias para su preparación, que deberán incorporarse al calendario del proyecto.

También se tienen que establecer los criterios que se van a seguir en las pruebas. Para especificarlos es preciso consultar los requisitos del producto y de componentes de producto, estándares, políticas de la organización, tipo de prueba, parámetros de compromiso entre la calidad y el coste de las pruebas, propuestas y acuerdos. Dos de los criterios que tienen que estar fijados especialmente y con objetividad es el de finalización de las pruebas, y el de aceptación del producto. En qué momento se puede dejar  de probar y qué se tiene que cumplir para que se acepte el producto, estos criterios no tienen que ser subjetivos, deben referirse a condiciones susceptibles de ser medidas (por ejemplo: las pruebas terminarán cuando la detección del siguiente error tenga un coste superior a …)

Las pruebas se desarrollan en el entorno establecido e incrementalmente durante todo el ciclo de vida del proyecto. Una organización y realización adecuada de las pruebas contribuye desde un principio a conseguir productos con la calidad acordada.

Como producto de las pruebas no solamente está el resultado de las mismas sino que también se tiene que preparar un informe sobre esos resultados, constatar las acciones a emprender seguidamente y algo que no es frecuente: un registro del método seguido, “cómo se hizo”, para asegurar que las pruebas se pueden repetir exactamente igual. Esto último es importante en labores de mantenimiento,  cuando se hacen pruebas de regresión, para evitar que una alteración en el método confunda el resultado de las pruebas.

Algo importante a tener en cuenta: es posible que por contrato, legislación, normas del cliente, etc., se nos exijan documentos y pruebas específicas que no hayamos inicialmente considerado. Por ejemplo, un cliente en la Administración Pública que use la metodología "X", si por contrato, hemos dicho que vamos a usar dicha metodología, deberemos revisar a qué documentos, tipos y ciclos de pruebas nos hemos de someter. También puede ser típico que no sea directamente el cliente, sino una empresa certificadora de aplicaciones (un proveedor externo), quien en su nombre verifique la calidad de nuestro desarrollo. Por supuesto, que deberemos recoger como requisitos, las pruebas a las que van a someter a nuestro producto.
Vamos a ver en resumen, cual podría ser (en un proyecto grande, y siempre que se estime necesario), la información a recopilar en esta fase de preparación/planificación de las pruebas:
  • Tipos de pruebas. Identificar qué pruebas vamos a realizar a nuestro desarrollo.
  • Ciclos de pruebas
  • Recursos físicos: principalmente, equipos y entornos, software. Al menos, habrá que identificar qué pruebas se realizan en cada entorno (desarrollo, pruebas, pre-producción, producción, formación...). Los recursos también pueden ser los datos de pruebas. Habrá que tener en cuenta si son necesarios, quién es el responsable de proporcionarlos, etc.
  • Recursos humanos: personal del cliente responsable o participante en las pruebas, miembros de nuestro equipo y su rol en la prueba a realizar, otras personas (proveedores externos, etc.)
  • Calendario de pruebas: tratar de ajustar a nuestro plan de trabajo, las pruebas a realizar. Con ello, no sólo tendremos un calendario orientativo de cuándo tenemos que estar disponibles para hacer las pruebas, sino que además podremos avisar con tiempo de que ciertas personas estén disponibles (por ejemplo, el responsable de sistemas del cliente), o de que se haya comprado e instalado ese servidor Unix que tenemos planificado.
  • Restricciones/limitaciones: las que se nos ocurran. Son notas a tener en cuenta para "no meter la pata".
  • Dependencias: ¿dependemos de servicios/funcionalidades que proporcionan otros proveedores? ¿Proporcionamos nosotros servicios o funcionalidades que van a requerir otros proyectos?

¿Pero tú estás loco?¿Todo esto es necesario?

La respuesta es sí y no. Es necesario tener en cuenta estas cosas, y es algo que de forma natural, los que hemos estado metidos en muchos proyectos solemos recopilar en mayor o menor grado. Para evitar que se olviden estas cosas, el CMMi (y casi todas las metodologías), nos recomiendan usar una Checklist. Por supuesto, los que nunca lo han hecho, les parecerá la primera vez un gran esfuerzo. Luego, conforme lo usas en varios proyectos, te das cuenta que normalmente sólo haces realmente una parte de lo aquí comentado (¡claro, sólo lo que aplica a tu proyecto, nunca hay que trabajar por trabajar!)

Normalmente, todas estas cosas sólo serán necesarias en proyectos grandes, complejos o con riesgos tecnológicos y/o de integración.

Aquí va una típica conversación entre programador y jefe de proyecto:
  • Jefe de Proyecto: venga, lo instalas en pruebas y le das un par de vueltas hasta que estés seguro de que funcione. (notar aquí que el Jefe de Proyecto echa la responsabilidad al programador, pero no le guía en qué, cómo, cuándo ni porqué...)
  • Programador: ¿Oye, y que pruebo?
  • Jefe de Proyecto: bah, tú simplemente revisa que todo lo que hemos tocado funciona.
Bueno, seguro que vosotros os habéis visto en situaciones similares. La realidad supera como siempre, a la peor de las ficciones.

jueves, 5 de abril de 2012

Testing (I) - Las pruebas según el CMMi

Este es el primero de una serie de artículos sobre el testing y el cmmi:
Las pruebas en el modelo CMMI DEV están tratadas principalmente en las áreas de proceso "Verificación" y "Validación".

La verificación tiene como objetivo demostrar que el producto de trabajo cumple los requisitos que se especificaron para ese producto de trabajo, la validación asegura que el producto que se proporciona es adecuado para su uso previsto y en el entorno operativo previsto. Con la oportunidad que da el sintético idioma inglés, los americanos dicen que la pregunta para la verificación es Did you build the product right?, mientras que la pregunta para la validación es Did you build the right product?

La verificación se hace sobre productos de trabajo y sobre el producto final, entendiendo que los productos de trabajo son resultado de actividades diversas y no solamente de la codificación. Se tienen que verificar los documentos que se generan respecto a los requisitos que se acordaron al inicio y durante el desarrollo del proyecto. Por ejemplo, el manual de usuario deberá cumplir con algún tipo de requisito o normativa, especificado por el cliente o por la organización que hace el desarrollo. Se tendrá que comprobar que se haya escrito en el idioma o idiomas pedidos, que sigue una estructura adecuada y que está completo, que figuran los logos del cliente si así se ha especificado. Como éstos puede haber otros requisitos para este producto o para otros.

En la validación intervienen los usuarios finales u otros involucrados en el proyecto, que tienen autoridad para revisar los productos obtenidos y rechazarlos si no satisfacen las necesidades del usuario cuando se encuentran en el entorno en el que van a operar. Siguiendo con el ejemplo del Manual de Usuario, la persona que tiene que validarlo, comprobará que los resultados de las consultas le son útiles en el entorno y la función de la aplicación para las que las hace. Por ejemplo, puede encontrarse que entre los parámetros de configuración no figuran los necesarios para su sistema operativo.

El modelo CMMi considera especialmente la utilización de las revisiones entre pares como instrumento de verificación, tanto es así que la utilización de las mismas es una de las metas del área de proceso “Verificación”. Para decirlo más claramente, si una organización quiere alcanzar el nivel 3 está obligada a utilizar este método.

Las revisión entre pares es una técnica en la que el producto del trabajo de una persona se expone a la consideración de otras personas con las que no tiene relación de dependencia, es decir, son sus iguales, sus compañeros. El producto generado se revisa utilizando listas de comprobación ("checklists") en las cuales se pueden encontrar cuestiones sobre reglas de construcción, guías de diseño, facilidad de mantenimiento, tipos de defectos comunes, etc, que se van a comprobar en elementos  entre los que pueden estar los productos de trabajo claves de las actividades de especificación, de diseño, de prueba y de implementación, y sobre los productos de trabajo específicos de planificación.

Verificar es más que probar.


Solamente probar código no es verificar, las pruebas del software son una parte del concepto de verificación tal y cómo lo entiende el modelo. Todos lo productos de  trabajo del proyecto, no solamente el código, deben considerarse para decidir si se incorporan entre los que van a ser verificados, y entre ellos están los documentos técnicos, los planes, los productos COTS (*), herramientas a utilizar, e incluso elementos de formación.

Validación.


En las actividades de validación, interviene el usuario para comprobar que el producto le presta las funcionalidades pedidas en el entorno de producción. Se han llamado normalmente “pruebas de aceptación” y tradicionalmente se hacen cuando el producto está terminado y sólo sobre el software. Para evitar sustos a última hora, deberían seleccionarse productos de trabajo intermedios, susceptibles de ser validados, que puedan predecir si el producto final cumplirá las expectativas del usuario y de este modo ir validando pronto, paulatina e incrementalmente durante todo el proyecto.
Ejemplo de los productos que se pueden validar son: los requisitos, diseños, componentes de producto, interfaces de usuario, manuales de usuario, materiales de formación y documentación del proceso.
El modelo exige las mismas prácticas para validar que para verificar, excepto la revisión entre pares.

 (*) COTS: Commercial Off The Shelf; paquetes o productos comerciales, que hay que probar (al menos su integración con el resto de nuestro producto).