Se prueba de acuerdo a la madurez

Por todos es sabido que todo proyecto tiene un ciclo de vida, desde la iniciativa, hasta su cierre. Lo que no necesariamente se sabe es que para los evaluadores de este proyecto, uno de los temas estratégicos a considerar es el enfoque de las pruebas. Debe haber al menos cuatro enfoques:
a) Al inicio del proyecto, evaluaciones amistozas, se debe respetar que la criatura está en crecimiento y que pueden haber muchas omisiones o fallos
b) En la mitad del proyecto, las evaluaciones deben ser agresivas, es allí en donde debe dar peso a la evaluación a efecto de que el equipo a cargo tenga tiempo y posibilidades de enmendar.
c) Cerca del final las pruebas deben ser diversificadas, es decir con varias herramientas, varios enfoques, etc a efecto de verificar que se está listo para la liberación
d) Al final las pruebas deben ser meticulosas, es decir, es aqui en donde se debe concentrar en los detalles finales que son los que harán que el producto se diferencie.
En general la combinación de estas estrategias es mucho mejor que planear un único plan de pruebas, sin tener claro el enfoque.

El mal de "oir" y el "pero"

Yo creo que por todos es conocido que hay una significativamente diferencia entre oir y escuchar, lo ideal es obviamente escuchar, pero encuentro que aún hay un mal peor: oir y ya tener el pero en la mente. A veces los seres humanos con solo unas pequeñas palabras que se nos dicen, articulamos ya una posición ante la primera persepción sin haber tomado tiempo de razonar, para tener ya el pero listo, esperando unicamente que el interlocutor termine de hablar.
Ojala y todos aprendieramos a escuchar, y si nos da por oir, al menos debemos de evitar tener el pero en la mente.

Documentación en exceso.

Gracias al curso de pruebas de software, ahora veo las cosas un poco menos confusas de lo que antes estaban. Soy un fiel creyente de los sistemas de calidad y de los estándares. Reconozco que lo que no está documentado es muy difícil de mejorar, pero de allí a tratar de implementar los más altos estandares documentales en una organización, que tal vez no los necesita del todo, es un acto irresponsable si se obliga a hacer, sin econtrarle ningún valor agregado.
Lo primero que debe hacerse es un costo beneficio a la documentación que cualquier sistema de aseguramiento de la calidad requiere. Estoy seguro que ningún auditor inteligente se deja llevar por volumen. Lo que realmente les preocupa a los auditores es qué se haga y se validen los productos a entregar, con algún criterio previamente establecido y verificable.
Mucho documento más bien refleja que hay mucho ocio y que se dedicó más tiempo a escribir que ha hacer lo que esta escrito. Como dijo el jefe, nuestro sistema esta gordo de documentos y hay que ponerlo a dieta. El tener documentos sucintos refleja que se tiene claro el norte y que se ha alacanzado algún nivel de execelencia documental.

Diario de aprendizaje: un primer balance

Si bien es cierto como proyecto este blog representa realmente mi diario de aprendizaje, es bueno consignar en él primer balance a unos días de su confección.
En primer lugar debe dejarse claro que lo que realmente te puede ayudar a aprender, como ya lo dije desde las primeras entradas, es estar expuesto y esto en mi caso es posible por medio de la lectura. Por suerte he estado teniendo acceso a bueno autores que por medio de sus ideas me han ayudado a interiorizar las mias.
En segundo lugar el esfuezo de redactar unos cuantos párrafos es realmente una ayuda para la mente, aparate de fortalecer las competencias de comunicación escrita, es relevante porque fuerza a la mente a coordinar ideas y expresión.
Lo tercero y más importante es tener la capacidad de discrepar, aunque hasta ahora no he tenido mucho que aportar en este punto, el poder elegir dentro de todas las posibilidades y defenderlas teniendo que enfrentar mentes brillantes para poder alcanzar acuerdos es algo a lo que todos deberiamos estar más expuestos.

Probar un software vs revisarlo

Conforme el investigador va cambiando su fuente de información de google o wikipedia a documentos más especializados, éste se va dando cuenta que los detalles comienzan por hacerse cada vez más relevantes. Tomemos un ejemplo. Pídale a una persona que pruebe algo y luego dígale que lo revise. Observe bien. ¿Hizo algo diferente? Mi intuición me indica que en la mayoría de los casos no hay mayor diferencia en lo que se haga en una u otra solicitud. Sin embargo a nivel formal hay un mundo de diferencia entre ambas definiciones, y aún las hay más cuando se asocian a un tema de software.
Leyendo  el libro de Lewis (Software testing and continuous quality improvement) encuentro la reveladora aclaración de que "probar" es una acción que busca encontrar errores, mientas que "revisar" lo que pretende es verificar la calidad asociada a los estándares del producto. Pese a que la persona del ejemplo del párrafo anterior haya hecho prácticamente lo mismo, nótese como en el software los resultados esperados cumplen objetivos no semejantes.
Por supuesto que ambas acciones guardan varias similitudes. Buscan mejorar el software, reducen las futuras complicaciones y costos reputacionales y económicos de no aplicarse, siguen metodologías de diagnóstico equiparables, pero en última instancia su objetivo es diferente.
Si partimos de los modelos de desarrollo estándares, en donde primero surge un levantamiento de requerimientos, luego viene un diseño lógico de la aplicación, luego un diseño físico que da lugar a una programación y finalmente a un código utilizable, cada una de estás etapas tiene asociado un tipo particular de pruebas: pruebas de aceptación, pruebas de sistema, pruebas de integración y en un inicio pruebas unitarias. Lo que Lewis plantea es que cada etapa del desarrollo debe tener su correspondiente prueba, de manera que no se pueda pasar a la siguiente etapa con errores.
Por su parte la parte de la revisión puede que ni siquiera llegue a ejecutar el programa. Se concentra más bien en verificar los estándares seguidos por las partes involucradas en el desarrollo, pudiendo hacerse formal o informalmente. Las revisiones surgen para complementar las pruebas. Es importante notar que establecer que un software tiene errores puede ser una tarea titánica e infinita, con lo cual revisar las prácticas seguidas puede ser una forma operativamente más sencilla de garantizar que las condiciones para que el producto final salga bien se hayan dado.
Como pueden notar ambas, pruebas y revisiones, son necesarias y pueden hacerse en simultáneo. Lo relevante y lo que persigo con esta publicación es que entendamos, cuando alguien nos requiera una de ellas en particular, saber diferenciar lo que se nos ha pedido y no pecar de manejar un vocabulario tecnológico light.

Segunda genereración de la gestión de conocimiento

Todo parece indicar que ha habido dos etapas o generaciones de la gestión del conocimiento, la primera ligada a la ya famosa frase de Albin Tofel "el dueño de la información es el dueño del poder", en donde las empresas y organizaciones centraron sus recursos en almacenar la información. Estos mega repositorios, caros y difíciles de mantener ordenados, pasaron a dar lugar a la inteligencia de negocio, que es la que da pie a la segunda generación de la gestión del conocimiento en donde se reconoce que es más bien el nuevo conocimiento que surja, a partir de los datos almacenados lo que dará lugar a la verdadera generación de valor agregado de las organizaciones a partir del reconocimiento de conocimiento como un activo estrátegico.
Esta segunda generación tiene un difícil reto por delante, descubrir cómo se genera información a partir de los datos. No creo que sea con una orden de las autoridades que le diga a los empleados inicien la generación del conocimiento y éste como si fuera una linea de producción al final de unos ciclos de operación empezará a surgir. Por el contrario encuentro tendencias que más bien buscan crear las condiciones para que el conocimiento surja, cuando, no se sabe, pero al menos se potencia.
La primera condición que encuentro que se utiliza para potenciar el conocimiento es reconocer que deben existir espacios para las criticas, es decir, se partir de la sabia idea de que lo que tenemos por conocimiento dado, puede que no esté del todo bien. Se recurre a la critica, la cual a veces es más sencilla que la creación nueva es el motor de revisión de lo que se cree es el stock de conocimiento de las organizaciones.
La segunda condición tiene que ver con identificar a que tipo de conocimiento se le debe prestar atención. Existen muchas disciplinas a las cuales darles recursos para el desarrollo, pero es un hecho que no ha todas es una buena decisión dársela. Debe por lo tanto existir un proceso de selección de las jefaturas que dirijan los esfuerzos creativos de nuevo conocimiento, declarando expresamente cuales son las líneas a las cuales es de interés de la organización que se documenten e inicie su proceso de mejora.
La tercera condición tiene que ver con fortalecer la demanda de nuevo conocimiento. Los puntos anteriores buscaban fortalecer la oferta. Por el lado de las necesidades es necesario crear los incentivos necesarias y la flexibilidad para que todo lo nuevo que se vaya generando empiece a ser aprovechado cuanto antes. De la valoración de los que lo utilizan, los creados obtendrán la primera y más importante remuneración, el recocimiento.
La cuarta condición necesaria tiene que ver con los repositorios de conocimiento, portales de conocimiento o como se les quiera llamar. Existen dos tipos de conocimiento, el tácito y el explícito, y para las empresas el mejor es segundo pues permite su fácil transmisión y revisión. Estable un piso sobre el cual es difícil descender y en teoría solo mejoras pueden existir.
La segunda generación de que estamos hablando trae consigo una distinción entre tres tipos de conocimiento según su fuente. Hay un conocimiento individual, uno colectivo y uno organizacional. en buena teoría el conocimiento trae sinergias, es decir el conocimiento de uno individualmente más otro más es mayor al individual de las partes debido a que la revisión conjunta mejora el de cada uno individualmente. A su vez el conocimiento colectivo, por ejemplo de un departamento dentro de una empresa puede entrar en relación con el de otras partes y de igual forma autoperfeccionarse y darle un mayor valor agregado.
El reto en este punto es crear los canales de comunicación entre las partes y crear la madurez para un proceso de mejora colectiva que de pie a crear las bases de un crecimiento sostenible de la innovación en la organización.
Quien dice que en estos días no estoy aprendiendo :)

Tips para el uso de latex

Guía de memoria para incluir cosas en latex, de las que uso frecuente:
Paquete para poner link en internet: \usepackage{url}
Paquete para cambiar el interlineado: \usepackage{setspace}
Por ejemplo \begin{onehalfspace}...\end {onehalfspace}
Paquete para poner imagenes: \usepackage{graphicx}
Cambiar de ingles a español la palabra Figura: \renewcommand\figurename{Figura}
Cambiar de ingles a español la palabra Referencias: \renewcommand\refname{Referencias}
Por ejemplo
\begin{thebibliography}{99}
\bibitem{Autor} XXX
\end {thebibliography}