El vicio es, como lo dice la misma etimología de la palabra, un “vínculo, lazo o ligamen”, una cadena que esclaviza al hombre e impide o dificulta su progreso, reduciendo o atrofiando sus esfuerzos para la expresión de sus posibilidades más elevadas.
sábado, 8 de octubre de 2011
jueves, 22 de septiembre de 2011
Truco de word
Si queremos al abrir un documento en word ubicarnos en la última página vista, en la última apertura del archivo, basta con Shift + F5
jueves, 15 de septiembre de 2011
Deseo de saber
Nada podemos conocer sin antes haber obtenido el deseo de saberlo, y ninguna verdad podemos aceptar, que no venga de afuera, si esa verdad no corresponde a un deseo interior, en el cual ya se encuentra en un estado de oscura intuición.
sábado, 10 de septiembre de 2011
Agile vs. Plan-driven Development
Tomado de A Project Manager’s Survival Guide to Going Agile. Michele Sliger, Agile Coach, CSM-T, PMP
Both agile and plan-driven development recognize the triple constraint: cost, schedule, and scope. But whereas plan-driven development advocates locking down the requirements so that schedule and cost can be estimated, the agile approach says that scope is always changing and therefore schedule and cost should be fixed. This way projects don’t become death marches, and the product is developed in a fashion where it’s in a perpetual releasable state.
This basic shift in focus has a cascading effect on each subsequent practice in both approaches. Planning, executing, and controlling disciplines move from more directive, command-and-control tactics to facilitative, collaborative support. The idea being that if you give the team the tools they need, help them to understand the business problems they’ll be solving, and give them the space and time to complete the job, that they can then be self-directed and self-organizing, and become a fully engaged and motivated team that produces high-quality products at a faster clip. Clearly, for many organizations, this change in tactics also leads to a shift in the culture and in the ways success is measured.
Project managers will find themselves learning how to guide their team in responding reliably to change instead of conforming to plan, and learning how to do this in a completely new environment where the team makes decisions instead of being told what to do. It means more individual responsibility for team members, and more facilitation skills required for the project manager. Most are uncomfortable with their new roles at first, and it is the project manager’s responsibility to build team cohesion and foster good communication.
Not everyone is willing to make this paradigm shift, project managers included. But for those who are willing, they’ll find both the process and the new skills they’ve learned to be richly rewarding and well worth the effort involved.
Both agile and plan-driven development recognize the triple constraint: cost, schedule, and scope. But whereas plan-driven development advocates locking down the requirements so that schedule and cost can be estimated, the agile approach says that scope is always changing and therefore schedule and cost should be fixed. This way projects don’t become death marches, and the product is developed in a fashion where it’s in a perpetual releasable state.
This basic shift in focus has a cascading effect on each subsequent practice in both approaches. Planning, executing, and controlling disciplines move from more directive, command-and-control tactics to facilitative, collaborative support. The idea being that if you give the team the tools they need, help them to understand the business problems they’ll be solving, and give them the space and time to complete the job, that they can then be self-directed and self-organizing, and become a fully engaged and motivated team that produces high-quality products at a faster clip. Clearly, for many organizations, this change in tactics also leads to a shift in the culture and in the ways success is measured.
Project managers will find themselves learning how to guide their team in responding reliably to change instead of conforming to plan, and learning how to do this in a completely new environment where the team makes decisions instead of being told what to do. It means more individual responsibility for team members, and more facilitation skills required for the project manager. Most are uncomfortable with their new roles at first, and it is the project manager’s responsibility to build team cohesion and foster good communication.
Not everyone is willing to make this paradigm shift, project managers included. But for those who are willing, they’ll find both the process and the new skills they’ve learned to be richly rewarding and well worth the effort involved.
martes, 6 de septiembre de 2011
Manifiesto ágil
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
lunes, 29 de agosto de 2011
martes, 9 de agosto de 2011
Radiador vs Refrigerador
Uno de los temas que más preocupa a los encargados de publicar la información es el hacerla visible para el público al que ésta va dirigida. Sin duda alguna los portales, como Sharepoint, son una de las herramientas que más se ha utilizado en los últimos años para esta tarea. Sin embargo esta herramienta ha equivocado su concepto como transmisor de información al utilizar un enfoque de refrigerador.
Un enfoque de refrigerador está asociado con el almacenamiento estructurado en gavetas, en donde el contenido se congela y es responsabilidad del interesado el encontrar dentro del contenedor dónde está la información. Vean que importante este paradigma de almacenamiento, la información estará muy bien guardada, estructurada y protegida, pero dependerá del talento y conocimiento del cliente el llegarle a lo almacenado, por más buscador que se le ponga.
Por otro lado está el enfoque que usa facebook, el boom en este momento, allí el interesado es encontrado por la información. A su muro llegan en línea los temas de interés de sus amigos, conocidos, noticias, fotos, cambios de relación sentimental, etc. Este es el nuevo paradigma, el radiador de información, en donde no se debe hacer mucho esfuerzo en búsquedas ya que la información que más te puede interesar te llega cada vez que te conectas.
Para todos aquellos administradores de portales, o interesados en la distribución de información, deben preocuparse pronto por cambiar de paradigma. El cliente se los agradecerá y estarán promoviendo el mejoramiento de las herramientas informáticas.
lunes, 8 de agosto de 2011
jueves, 21 de julio de 2011
Como cambian las cosas, hasta los juguetes
Estoy un poco triste y medio molesto pues los directores de las películas de estos días están irrespetando los origenes de los comics. Me es muy doloroso ver como un Megatrón ya no es una pistola, Shockwave es ahora un tanque rarísimo, etc. La lección aprendida es que por triste que sea, el cambio, es una realidad y sólo queda guardar lo vivido como un gran tesoro, pues como tal, nunca se volverá a repetir.
PD: ¿Quien ha visto un pitufo bravo? era pitufo gruñon y como él ninguno!!!
lunes, 18 de julio de 2011
42 procesos del PMBOK
El Project Management Body of Knowledge (PMBOK) establece que existen 42 procesos que deben seguirse en la administración de proyectos (es criterio del usuario cúal le aporta y cual no), sin duda es imposible recordarlos, pero si es útil tenerlos claros y saber ordenarlos.
Adjunto la imagen que debe estar cerca de todo PManager:
Adjunto la imagen que debe estar cerca de todo PManager:
lunes, 11 de julio de 2011
Paper de pruebas de rendimiento
Este es el documento que elaboramos los compañeros del Postgrado, como ejemplo de cómo llevar adelante una evaluación sobre una herramienta en ventana, no web. Presenta un enfoque interesante y una muy buena revisión bibliográfica.
enlace
jueves, 7 de julio de 2011
viernes, 24 de junio de 2011
Abreviaturas para usar frecuentemente en publicaciones
i.e. significa "esto es", y viene del latín "id est"
e.g. significa "por ejemplo" y en latín significa "exempli gratia"
e.g. significa "por ejemplo" y en latín significa "exempli gratia"
jueves, 23 de junio de 2011
Solsticio y la metáfora de la candela.
Ayer 22 de junio el mundo en este hemisferio celebró el día con más luz del año. Como en la cultura de los antepasados vivir un día con mucha luz debe ser motivo de alegría y debe asociarse a metáforas de desarrollo personal.
La luz o claridad ha estado asociada a la inteligencia y a cosas buenas, la oscuridad se vincula contrariamente a temor o al mal.
Si los seres humanos estuviéramos en una caverna, en donde poseyéramos en nuestras manos una candela, qué pasaría si a cada uno de los que estamos allí se les fuera apagando uno a uno la luz de su candela: pues claro, poco a poco todos iríamos quedando en tinieblas. La maravilla de esto es que si en la caverna, al final sólo quedará uno con una candela encendida, el que conserva o más a cuidado su luz fácilmente podrá compartirla con los demás, si ellos lo desean y poco a poco ir multiplicando su luz nuevamente.
Lección, en la caverna donde estemos, familia, trabajo, escuela, amigos, tratemos de ser el que conserva la luz aunque los demás la vayan perdiendo, pues la vida ofrece siempre el milagro de compartir ese gran tesoro que se nos ha dado a cuidar: nuestra llama interna.
La luz o claridad ha estado asociada a la inteligencia y a cosas buenas, la oscuridad se vincula contrariamente a temor o al mal.
Si los seres humanos estuviéramos en una caverna, en donde poseyéramos en nuestras manos una candela, qué pasaría si a cada uno de los que estamos allí se les fuera apagando uno a uno la luz de su candela: pues claro, poco a poco todos iríamos quedando en tinieblas. La maravilla de esto es que si en la caverna, al final sólo quedará uno con una candela encendida, el que conserva o más a cuidado su luz fácilmente podrá compartirla con los demás, si ellos lo desean y poco a poco ir multiplicando su luz nuevamente.
Lección, en la caverna donde estemos, familia, trabajo, escuela, amigos, tratemos de ser el que conserva la luz aunque los demás la vayan perdiendo, pues la vida ofrece siempre el milagro de compartir ese gran tesoro que se nos ha dado a cuidar: nuestra llama interna.
martes, 21 de junio de 2011
El extraño horario de los computines
Computín es un término acuñado en las aulas de la escuela de computación e informática de la UCR para referirse a los estudiantes de la carrera, personas medio geek y nerd que tendrán en sus manos los fututos desarrollos de este país.
Como grupo de seres humanos hay una característica en los computines que me ha llamado poderosamente la atención, algo que he comentado con otros amigos de otras carreras, en lo cual concordamos es uno de sus rasgos más característicos –estoy hablando de promedios, no de casos particulares- esta característica tiene que ver con hacer las cosas al final, al filo de las hora, buscando siempre estar lo más cerca posible de la hora 2359 que siempre se pone para las entregas. Por más esfuerzos que haga por hacer los trabajos en grupo con suficiente tiempo, es un chip inserto en el ADN del informático, el deber de conectarse el domingo en la noche, el viernes en la noche, siempre cerca de la hora de entrega para finalizar el trabajo.
Nótese que esto no es malo, es simple y sencillamente algo cultural que a mí, como proveniente de otras latitudes me ha costado asimilar. Para todos aquellos que se adentran en las aulas de la ECCI, no les queda más que empezar a pensar en ajustar sus horarios a la norma social, que si me lo preguntan tiene algo de adrenalina: ¿Habrá llegado a tiempo? ¿Con qué hora lo registra el servidor? ¿Somos eficientes por hacerlo bien en tan corto tiempo?
Como grupo de seres humanos hay una característica en los computines que me ha llamado poderosamente la atención, algo que he comentado con otros amigos de otras carreras, en lo cual concordamos es uno de sus rasgos más característicos –estoy hablando de promedios, no de casos particulares- esta característica tiene que ver con hacer las cosas al final, al filo de las hora, buscando siempre estar lo más cerca posible de la hora 2359 que siempre se pone para las entregas. Por más esfuerzos que haga por hacer los trabajos en grupo con suficiente tiempo, es un chip inserto en el ADN del informático, el deber de conectarse el domingo en la noche, el viernes en la noche, siempre cerca de la hora de entrega para finalizar el trabajo.
Nótese que esto no es malo, es simple y sencillamente algo cultural que a mí, como proveniente de otras latitudes me ha costado asimilar. Para todos aquellos que se adentran en las aulas de la ECCI, no les queda más que empezar a pensar en ajustar sus horarios a la norma social, que si me lo preguntan tiene algo de adrenalina: ¿Habrá llegado a tiempo? ¿Con qué hora lo registra el servidor? ¿Somos eficientes por hacerlo bien en tan corto tiempo?
lunes, 20 de junio de 2011
Primera investigación de la maestría
Sólo para probar como funciona esto de poner documentos en un blog, adjunto el primer documento elaborado en los laboratorios de la Maestría de la UCR, este es un borrador muy preliminar. enlace.
Pronto habrá uno sobre pruebas de rendimiento!
Pronto habrá uno sobre pruebas de rendimiento!
domingo, 19 de junio de 2011
Examen de marcar con X
Dentro de las dificultades cotidianas de un estudiante, está el enfrentarse a un examen de marcar con equis. En este difícil tipo de preguntas se debe tener muy claros los conceptos para poder orientar el esfuerzo de selección, el cual en el mejor de los casos puede llevar a ubicar la probabilidades en el rango del 50 a 50.
En este caso desde ayer quede picado, pues aún no se si los criterios de cobertura: decisión condición cuando el test de la prueba presentaba la condición de Falso, Falso, Falso, Verdadero, debía o no considerarse en esta condición, o si más bien corresponde al criterio de cobertura de statement.
Mi argumentación lógica es que es un caso de prueba poco útil y que no debería clasificarse en ninguna categoría, en fin, seguiremos con la duda por un tiempo más.
En este caso desde ayer quede picado, pues aún no se si los criterios de cobertura: decisión condición cuando el test de la prueba presentaba la condición de Falso, Falso, Falso, Verdadero, debía o no considerarse en esta condición, o si más bien corresponde al criterio de cobertura de statement.
Mi argumentación lógica es que es un caso de prueba poco útil y que no debería clasificarse en ninguna categoría, en fin, seguiremos con la duda por un tiempo más.
viernes, 17 de junio de 2011
miércoles, 15 de junio de 2011
Valores frontera
Cuando se quiera representar en conjuntos, los valores máximos y mínimos del conjunto de números reales basta con poner:
Para el mínimo MIN_R y MAX_R para los máximo.
Para el mínimo MIN_R y MAX_R para los máximo.
lunes, 13 de junio de 2011
Cerebro
Yo no utilizo el cerebro que tengo, sino todos los que pueda pedir prestados.
Woodrow Wilson
Woodrow Wilson
miércoles, 8 de junio de 2011
Gotitas de sabiduría. Significado de Digital
En la era de la informática, la palabra digital ha conquistado una fama inusitada, merced a los sistemas informáticos basados en el sistema binario de numeración. En realidad, el adjetivo digital se aplica a los diez primeros números entre el cero y el nueve, pero la ingeniería informática se vale apenas del cero y el uno. ¿Por qué digital? Bueno, porque es el número de dedos de las manos, que nos llevó a aprender a contar con el sistema decimal de numeración. En latín, el sustantivo digitus significa 'dedo' y digitalis es un adjetivo que designa el grosor de un dedo.
Modernamente, nos hemos acostumbrado a llamar digital a aquello que se puede reducir a números dígitos y, en los últimos treinta o cuarenta años, a números binarios: cero y uno. Así, decimos que una película ha sido digitalizada cuando sus imágenes han sido reducidas a un número finito de puntos que se expresan mediante combinaciones binarias.
Esta palabra ingresó al diccionario de la Academia en 1846, como nombre de una planta cuyas flores tienen forma de dedal, y solo en la edición de 1914 pasó a significar también 'relativo a los dedos'.
Fuente: Ricardo Soca, el castellano.org
martes, 7 de junio de 2011
Somos héroes por naturaleza.
No sé si se han puesto a pensar alguna vez en el comportamiento instintivo del ser humano, ese actuar automático que ha sido puesto en nuestro cerebro por la naturaleza, del cual desprendemos mucho de nuestro actuar. Hoy quiero compartirles respecto de este punto lo que he aprendido de los instintos y del ser humano, fundamentalmente en que estamos programados para ser héroes.
El origen de la programación nace claramente de la oxitócica, una hormona que poseen las madres que hacen que en ellas se despierten comportamiento protectores impresionantes sobre sus hijos, a tal punto de poder percibir peligros y llegando incluso a poner en riesgo su propia seguridad personal por la de sus hijos o hijas. La hormona equivalente del lago masculino en cambio no va por el lado de la protección sino por la parte de la ternura y la calma. La segregación de esta hormona en el macho más bien se asocia a un amor paternal en el cual el macho renuncia a su agresividad y más bien pasa a convertirse en un animal tierno. De ambos comportamientos, el femenino y el masculino tenemos a los primeros héroes por naturaleza, los padres, quienes son los responsables de mantener a la especie.
El segundo gran vínculo heroico en la naturaleza se tiene con la familia, y tiene que ver con la protección de la herencia genética. En la mayoría de los casos, no siempre, el ser humano tiene un único hijo a la vez, el cual tiene un 50% de la información genérica del padre y un 50% del de la madre. Como un árbol, los primos tendrían algo así como el 25% de los genes del abuelo y así sucesivamente. Según ha venido demostrando la evidencia empírica, somos héroes con las personas que compartamos un mayor nivel de genes en común, y de hecho es normal que se quiera resguardar y perpetuar. Cuentan algunos historiadores de la edad media, única época en la historia en que se podía sacar algún beneficio social de matar a tu familia, que ni siquiera el peor de los tiranos, llego a matar al 100% de su familia, esto como claro reflejo de la defensa personal de los genes familiares.
El tercer nivel instintivo de heroísmo tiene que ver con la afinidad. El ser humano es el único ser vivo en el planeta con 47 músculos en la cara para poder comunicar, sentimientos, emociones, estados de ánimo, etc. Como especie la evolución nos ha provisto de un mecanismo de comunicación sin igual en el cual somos capaces de reconocer en otro cuando nuestra presencia es importante. Quien se ha acercado a alguien triste o quien no devuelve amablemente una sonrisa sin que medie más que la espontaneidad. La empatía en general es instintiva y por supuesto antecede al lenguaje y es el lenguaje el que permite que nos convirtamos en gigantes pues partimos de lo que otros nos han enseñado, estando cada vez en una grada superior.
La próxima vez que veamos a alguien en problemas, sea de nuestra familia o no, o tengamos alguna sensación a lo interno de que hay algo que debemos hacer, no nos limitemos, dejemos escapar al héroe interno que tenemos, el cual ha sido puesto en nuestro interior.
No debemos olvidar que somos seres humanos y no máquinas y que al final, quizá todos seamos de una forma u otra hermanos.
miércoles, 25 de mayo de 2011
jueves, 19 de mayo de 2011
11 consejos para los que hacen Test Plan con estandar IEEE 829
Comento a continuación algunos consejos que me han sido dados, para cuando uno hace un test plan siguiendo el estándar IEEE 829.
1. Al completar el espacio requerido de referencias, si no se cuenta con un identificador interno del documento dentro de la organización, se debe poner la referencia completa con el formato formal que incluye los autores, el título, la editorial, el lugar y el año (o si es web, el URL y la fecha en que se consultó).
2. Para probar la funcionalidad no necesitan ver la documentación interna (del código). De hecho, a menos que usen pruebas de caja blanca, tampoco se tiene la necesidad de usar el código de la aplicación, bastaría con correr el ejecutable de la aplicación.
3. La usabilidad abarca muchos aspectos más de la interfaz gráfica que sólo verificar la respuesta a las opciones del menú. De igual forma, cuando se habla de navegabilidad, se puede incluir aspectos como: si estando en una pantalla de la aplicación, siempre hay un botón que permita al usuario devolverse a la anterior o al menos a la pantalla principal de la aplicación.
4. La seguridad no es sólo verificar que los roles estén definidos correctamente, sino intentar violar los mecanismos de seguridad y control de acceso sobre esos roles.
5. ¨Altos volúmenes¨ no es medible. En general, si van a hacer pruebas de volumen es porque existen requerimientos explícitos de manejo de volúmenes mínimos para la aplicación, y en tal caso debería hacerse las pruebas contra estos requerimientos medibles (p.ej., la aplicación debe soportar hasta 100 consultas concurrentes)
6. Cuando se habla de baja prioridad, quiere decir los menos importantes, y éstos son los que se dejan para el final (si da tiempo); mientras que los de alta prioridad con los que se corren primero. Talvés la confusión está en que típicamente alta prioridad se indica con cero o uno; mientras que los de baja prioridad se indican con 2 o 3 en un test normal
7. Típicamente cuando las pruebas se suspenden, para dar el visto bueno de reanudación de pruebas se deben correr pruebas de regresión básicas (de prioridad 0) que aseguren la usabilidad del sistema.
8. El plan debe indicar el software que se necesita en el servidor y en el cliente. Por ejemplo, indicar que se necesita Microsoft SQL Server 2008 (para la base de datos) y Microsoft Team Foundation Server (para registrar todo lo concerniente a las pruebas).
9. "Herramientas" es un término demasiado general. Se debe especificar cuáles herramientas, porque si hay herramientas para las cuales necesitan licencia, o que llevan un proceso de instalación complejo y de mucho tiempo, hay que considerarlo dentro del plan de pruebas. Igualmente, hay ocasiones en que sólo la configuración del ambiente de pruebas (software, comunicación, etc) toma más tiempo que las pruebas mismas, entonces hay que indicar cuál es todo el software requerido.
10. Debe indicarse el entrenamiento o capacitación requerida por el equipo de trabajo. Si el equipo de testing necesita capacitarse en el uso de la herramienta VS2010 para poder realizar con éxito sus tareas esto debe planificarse.
11. En la sección de aprobaciones debe citarse el rol de quien tiene que aprobar el plan, no sólo su nombre. Es decir, si es el Test Managar, si es el QA Manager, el Developer Manager, etc.
Gracias a la profesora Martinez por estos consejos, los cuales obviamente son de su autoría.
1. Al completar el espacio requerido de referencias, si no se cuenta con un identificador interno del documento dentro de la organización, se debe poner la referencia completa con el formato formal que incluye los autores, el título, la editorial, el lugar y el año (o si es web, el URL y la fecha en que se consultó).
2. Para probar la funcionalidad no necesitan ver la documentación interna (del código). De hecho, a menos que usen pruebas de caja blanca, tampoco se tiene la necesidad de usar el código de la aplicación, bastaría con correr el ejecutable de la aplicación.
3. La usabilidad abarca muchos aspectos más de la interfaz gráfica que sólo verificar la respuesta a las opciones del menú. De igual forma, cuando se habla de navegabilidad, se puede incluir aspectos como: si estando en una pantalla de la aplicación, siempre hay un botón que permita al usuario devolverse a la anterior o al menos a la pantalla principal de la aplicación.
4. La seguridad no es sólo verificar que los roles estén definidos correctamente, sino intentar violar los mecanismos de seguridad y control de acceso sobre esos roles.
5. ¨Altos volúmenes¨ no es medible. En general, si van a hacer pruebas de volumen es porque existen requerimientos explícitos de manejo de volúmenes mínimos para la aplicación, y en tal caso debería hacerse las pruebas contra estos requerimientos medibles (p.ej., la aplicación debe soportar hasta 100 consultas concurrentes)
6. Cuando se habla de baja prioridad, quiere decir los menos importantes, y éstos son los que se dejan para el final (si da tiempo); mientras que los de alta prioridad con los que se corren primero. Talvés la confusión está en que típicamente alta prioridad se indica con cero o uno; mientras que los de baja prioridad se indican con 2 o 3 en un test normal
7. Típicamente cuando las pruebas se suspenden, para dar el visto bueno de reanudación de pruebas se deben correr pruebas de regresión básicas (de prioridad 0) que aseguren la usabilidad del sistema.
8. El plan debe indicar el software que se necesita en el servidor y en el cliente. Por ejemplo, indicar que se necesita Microsoft SQL Server 2008 (para la base de datos) y Microsoft Team Foundation Server (para registrar todo lo concerniente a las pruebas).
9. "Herramientas" es un término demasiado general. Se debe especificar cuáles herramientas, porque si hay herramientas para las cuales necesitan licencia, o que llevan un proceso de instalación complejo y de mucho tiempo, hay que considerarlo dentro del plan de pruebas. Igualmente, hay ocasiones en que sólo la configuración del ambiente de pruebas (software, comunicación, etc) toma más tiempo que las pruebas mismas, entonces hay que indicar cuál es todo el software requerido.
10. Debe indicarse el entrenamiento o capacitación requerida por el equipo de trabajo. Si el equipo de testing necesita capacitarse en el uso de la herramienta VS2010 para poder realizar con éxito sus tareas esto debe planificarse.
11. En la sección de aprobaciones debe citarse el rol de quien tiene que aprobar el plan, no sólo su nombre. Es decir, si es el Test Managar, si es el QA Manager, el Developer Manager, etc.
Gracias a la profesora Martinez por estos consejos, los cuales obviamente son de su autoría.
martes, 17 de mayo de 2011
+ Latex
Recién he intentado hacer un articulo que parezca lo más profesional posible, por un lado tenemos el default de kile y por otro tenemos la plantilla de la IEEE que adjunto a continuación http://mocha-java.uccs.edu/ieee/. Al final como es un trabajo en grupo el formato será una decisión colegiada, sin embargo debe decir que al publicó no lo gusta mucho el estándar IEEE, pese a que ahorra mucho espacio por las dos columnas. Creo que los estudiantes en términos generales somos muy tradicionales y encasillados en los formatos de presentación de los documentos, pero al menos debiéramos tener la capacidad de ajustar flexiblemente la presentación de nuestra obra del conocimiento.
Suerte a los que exploren los estándares no tradicionales.
Suerte a los que exploren los estándares no tradicionales.
lunes, 9 de mayo de 2011
Pruebas exploratorias
La aventura de las pruebas de software es sin duda un viaje estilo Indiana Jones: Díficil e intensiva en destrezas personales.
Su creador Cem Kaner la define como "un estilo de pruebas de software que se concentra en la libertad personal y la responsabilidad del evaluador para optimizar continuamente la calidad de su trabajo".
El hecho de que las pruebas exploratorias se lleven a cabo sin ningún guión, no significa que éste no tenga estructura ni regla alguna. Las pruebas exploratorias tiene cinco elementos externos: tiempo, probador, producto, misión y reportes. Una prueba exploratoria se lleva a cabo en un tiempo delimitado, sobre un producto específico, por medio de un tester en particular, tratando de cumplir una misión, el cual puede reportar el estado y resultados de la misma en cualquier momento.
Los elementos más importantes de esta metodología son:
Su creador Cem Kaner la define como "un estilo de pruebas de software que se concentra en la libertad personal y la responsabilidad del evaluador para optimizar continuamente la calidad de su trabajo".
El hecho de que las pruebas exploratorias se lleven a cabo sin ningún guión, no significa que éste no tenga estructura ni regla alguna. Las pruebas exploratorias tiene cinco elementos externos: tiempo, probador, producto, misión y reportes. Una prueba exploratoria se lleva a cabo en un tiempo delimitado, sobre un producto específico, por medio de un tester en particular, tratando de cumplir una misión, el cual puede reportar el estado y resultados de la misma en cualquier momento.
Los elementos más importantes de esta metodología son:
- Exploración del producto: Descubrir y almacenar los propósitos y funciones del producto, tipos de datos procesados y áreas potenciales de inestabilidad.
- Diseño de pruebas: Determinar las estrategias de operar, observar y evaluar el producto.
- Ejecución de pruebas: Operaciones sobre el producto, observar su comportamiento y utilizar la información para formar hipótesis sobre cómo el producto trabaja.
- Heurísticas: Guías y reglas de dedo que ayudan a decidir que hacer.
- Resultados revisables: Deben estar oriendados a cumplir los requerimientos o la misión.
El exploratory test es particularmente conveniente si los requisitos y las especificaciones están incompletas, o si se dispone de poco tiempo para el proceso de pruebas.
Sirve también cuando no se sabe qué es lo siguiente que se debe probar o si se debe o no probar un área del programa en particular.
El enfoque también se puede utilizar para verificar que otros tipos de pruebas han encontrado los defectos más importantes en la aplicación.
domingo, 1 de mayo de 2011
Pensamiento
“Investigación es la transformación de dinero en conocimientos."
"Innovación es la transformación de conocimientos en dinero"
Bayer AG
"Innovación es la transformación de conocimientos en dinero"
Bayer AG
Visual Studio 2010 para test
El día de ayer participe en una exposición acerca de test de software automatizados, el expositor, Don Jorge Villegas del BCCR, dio un tour por las nuevas funcionalidades incluídas en Visual Studio 2010 para probar procesos de autenticación, busquedas en web y generación de reportes con los resultados de las pruebas. El resultado impresionante!!!
Me llamó mucho la atención de la exposición la chota a un momento histórico reciente, en que para probar concurrencias y desempeño se reuniá a un grupo de usuarios y algo así como con un silbato se les decía "entre todos a la vez". Me produjo risa porqué yo he participado en pruebas con esta dinámica y aparte de las complicaciones operativas las condiciones nunca eran óptimas para emitir criterio, además de que no eran repetibles de manera semejante.
Ayer pude apreciar como la herramienta configura, cuántos usuarios virtuales participan, en qué momento entrán, hasta que cantidad, etc. Si alguien me pidiera participar nuevamente en una prueba así, me bastaría con comentar lo demostrado que a todas luces es mejor.
Lo aprendido tiene que ver con la necesidad de tener acceso a las vivencias de otros, leer revistas, participar de exposiciones, ir a talleres y no tener ostracismo en algo tan cambiante como la técnologia, si no se tiene el acceso a experiencias como las del señor Villegas se avanzará muy lentamente en los procesos de interiorización del conocimiento.
Termino con muchas espectativas de las exposiciones que vendrán!!!!
Me llamó mucho la atención de la exposición la chota a un momento histórico reciente, en que para probar concurrencias y desempeño se reuniá a un grupo de usuarios y algo así como con un silbato se les decía "entre todos a la vez". Me produjo risa porqué yo he participado en pruebas con esta dinámica y aparte de las complicaciones operativas las condiciones nunca eran óptimas para emitir criterio, además de que no eran repetibles de manera semejante.
Ayer pude apreciar como la herramienta configura, cuántos usuarios virtuales participan, en qué momento entrán, hasta que cantidad, etc. Si alguien me pidiera participar nuevamente en una prueba así, me bastaría con comentar lo demostrado que a todas luces es mejor.
Lo aprendido tiene que ver con la necesidad de tener acceso a las vivencias de otros, leer revistas, participar de exposiciones, ir a talleres y no tener ostracismo en algo tan cambiante como la técnologia, si no se tiene el acceso a experiencias como las del señor Villegas se avanzará muy lentamente en los procesos de interiorización del conocimiento.
Termino con muchas espectativas de las exposiciones que vendrán!!!!
lunes, 25 de abril de 2011
Cerebro creador de modelos
Tomado de Gestión del Conocimiento, Valhondo 2003.
Durante siglos ha prevalecido la idea de que mente del hombre trabaja en forma lineal, un error basado en la naturaleza del lenguaje hablado y de la escritura. Cuando hablamos estamos restringidos por la naturaleza del tiempo y del espacio, porque tenemos que pronunciar una palabra tras otra, es decir no podemos pronunciar dos palabras a la vez.
Hoy, sin embargo, se tienen evidencias de que el cerebro tiene otras opciones multidimensionales y se basa en patrones. Cuando oímos una frase o leemos un texto es cierto que procesamos la secuencia de palabras conforme llegan al cerebro, pero al mismo tiempo se desencadena un complejo proceso de clasificación y selección que va situando la secuencia de palabras en un entorno multidimensional que da el sentido particular de lo que se lee o se escucha, en el que el componente de experiencia y estado emocional juega un papel relevante.
Por otra parte, sabemos que cuando escuchamos o leemos algo, no es posible retener en la memoria el contenido literal, sino que nos quedamos con la síntesis en la que los conceptos clave son los que pueden perdurar y, a partir de ellos, pueden recordarse frases o párrafos de forma más extensa. En cierto modo, cuando tomamos notas en una conferencia, no estamos registrando literalmente la misma, sino que escribimos los elementos esenciales con los que estamos seguros forzaremos las asociaciones de ideas que posteriormente podamos necesitar. En las notas no sólo reproducimos palabras o términos, sino que eventualmente hacemos esquemas que sintetizan (crear un modelo) lo que escuchamos
De todo lo anterior mi comentario es que dos podemos escuchar lo mismo, pero evidentemente podemos crear modelos diferentes, lo que implica que nuestro aprendizaje es diferente aunque se tenga la misma fuente de conocimiento.
viernes, 22 de abril de 2011
De abajo pa´riba o de arriba pa'bajo
Probar el software es un arte, de eso no hay duda. Eso quiere decir que los resultados dependen de destrezas personales en mayor medida que en la mera aplicación de un procedimiento en particular, tipo paso 1, paso 2, paso 3.
Como si de por sí el llevar a cabo las pruebas no fuera algo delicado, en el sentido de que debe darse un buen veredicto lo antes posible, debe tomarse una decisión para poder empezar las pruebas lo antes posible: empezar a probar de arriba hacia abajo o de abajo hacia arriba.
Empezar de arriba hacia abajo tiene una ventaja y es que se inicia casi al mismo tiempo que la construcción de software, pero tiene la desventaja de que debe suponerse lo que vendrá a futuro, es decir tiene un sesgo de supuestos muy fuerte. En este punto sale ganando el de abajo hacia arriba.
De arriba hacia abajo permite, en la medida en que lo más complicado del software esté listo iniciar desde allí, esto implica que una vez probado puede rápidamente corregirse, mientras que si fuera de abajo hacia arriba el tiempo destinado a la corrección se daría muy avanzado el desarrollo, es decir, punto a favor de arriba hacia abajo.
Ambos enfoques son laboriosos en el sentido de que deben crearse stubs o drivers para completar las partes faltantes, lo cual implica trabajo adicional al test, en este punto no hay ventaja para ninguno de los enfoques.
Además de lo anterior está una tercera alternativa, puede que no se decida nada del todo y que se usen métodos no incrementales para la prueba, es decir partimos de una poca rigurocidad y especificidad en el orden de los elementos a probar y se descarta utilizar alguna técnica, es decir bing bang.
Cómo recomendación debería seleccionarse alguno de los dos primeros, tendiendo si el tiempo lo permite alguna inclinación por el enfoque de abajo hacia arriba, así los resultados pueden ser más robustos.
Repito como es un tema de arte, que cada artista decida como perfeccionar su técnica.
Como si de por sí el llevar a cabo las pruebas no fuera algo delicado, en el sentido de que debe darse un buen veredicto lo antes posible, debe tomarse una decisión para poder empezar las pruebas lo antes posible: empezar a probar de arriba hacia abajo o de abajo hacia arriba.
Empezar de arriba hacia abajo tiene una ventaja y es que se inicia casi al mismo tiempo que la construcción de software, pero tiene la desventaja de que debe suponerse lo que vendrá a futuro, es decir tiene un sesgo de supuestos muy fuerte. En este punto sale ganando el de abajo hacia arriba.
De arriba hacia abajo permite, en la medida en que lo más complicado del software esté listo iniciar desde allí, esto implica que una vez probado puede rápidamente corregirse, mientras que si fuera de abajo hacia arriba el tiempo destinado a la corrección se daría muy avanzado el desarrollo, es decir, punto a favor de arriba hacia abajo.
Además de lo anterior está una tercera alternativa, puede que no se decida nada del todo y que se usen métodos no incrementales para la prueba, es decir partimos de una poca rigurocidad y especificidad en el orden de los elementos a probar y se descarta utilizar alguna técnica, es decir bing bang.
Cómo recomendación debería seleccionarse alguno de los dos primeros, tendiendo si el tiempo lo permite alguna inclinación por el enfoque de abajo hacia arriba, así los resultados pueden ser más robustos.
Repito como es un tema de arte, que cada artista decida como perfeccionar su técnica.
jueves, 21 de abril de 2011
El niño que llenó una boleta
Siempre había escuchado que había mucha similitud física entre los costarricenses del norte y los nicaragüenses del sur, recientemente lo confirmé,
pero pese a que somos hermanos existe en estos momentos algunas diferencias idiosincrásicas que me llamaron la atención y aprovecho para comentarlas.
En primer lugar es indudable que somos realmente hermanos, es muy sencillo determinar por los saludos y la cercanía que nos vemos como hermanos, pero como en toda familia hay diferencias.
La frontera de los chiles es una rudimentaria cerca de tres hilos de alambre, que en algunos tractos que lo separan está en el suelo, obviamente es fácil de cruzar, sin embargo hay una diferencia: los nicaragüenses la cruzan constantemente y los costarricenses en cambio están amenazados con armas si lo hacen. La presencia del ejercito es de por sí un cambio radical para nosotros, de este lado el policía es un señor bonachón, poco atlético que comiéndose un helado vigila, mientras que del otro lado es joven soldado, vestido de fatiga, que con su sola mirada hace notar una ira por medio de la cual quiere imponer respeto.
La diferencia tiene que ver con un absurdo nacionalismo que se da a través de los ríos que conectan los países, cada embarcación posee dos banderas y al cruzar una frontera marcada por un mojón en las orillas del río, debe correrse a intercambia el símbolo que se porta de acuerdo a la embarcación, es como si cada vez que se fuera en carro uno tuviera que bajarse a cambiar de placa. ¿No son acaso dos vecinos que se frecuentan?
Los Nicaragüenses son un país pobre pero muy trabajador, me atrevería a decir que trabajan, en promedio más que los ticos de la zona, pero con menores remuneraciones. Solo un ejemplo, el bote de CR a Nic cuesta 6 mil colones, y de regreso de Nic a CR 5 mil, ambos montos cobrados en colones, es decir no hay truco de tipo de cambio.
La diferencia que más me afectó fueron las decisiones de cómo vivir la pobreza, teniendo un maravilloso lago, mucha pesca, mucho turismo, la suciedad,
los servicios de baja calidad dejan ver los pocos deseos de superación en algunos. Sé que como país Nicaragua posee un enorme potencial, pero creo que
deben enrumbar sus esfuerzos gastar menos en seguridad militar y mejorar los niveles de educación, preocuparse por limpiar más sus locales comerciales
y ser en general más serviciales con los visitantes.
Finalmente cuento la anécdota del joven que se ofrece con un lapicero a llenar las boletas de migración, él cobra por su capital humano: saber leer y escribir 300 colones, con eso y a 40 personas por bote, bien se está ganando mucho más que en la recolección de naranjas o frijoles de la zona. Un buen ejemplo de cómo se puede con inversión en educación cambiar pronto las condiciones generales que están a un pequeño paso de ellos mismos las puedan cambiar.
pero pese a que somos hermanos existe en estos momentos algunas diferencias idiosincrásicas que me llamaron la atención y aprovecho para comentarlas.
En primer lugar es indudable que somos realmente hermanos, es muy sencillo determinar por los saludos y la cercanía que nos vemos como hermanos, pero como en toda familia hay diferencias.
La frontera de los chiles es una rudimentaria cerca de tres hilos de alambre, que en algunos tractos que lo separan está en el suelo, obviamente es fácil de cruzar, sin embargo hay una diferencia: los nicaragüenses la cruzan constantemente y los costarricenses en cambio están amenazados con armas si lo hacen. La presencia del ejercito es de por sí un cambio radical para nosotros, de este lado el policía es un señor bonachón, poco atlético que comiéndose un helado vigila, mientras que del otro lado es joven soldado, vestido de fatiga, que con su sola mirada hace notar una ira por medio de la cual quiere imponer respeto.
La diferencia tiene que ver con un absurdo nacionalismo que se da a través de los ríos que conectan los países, cada embarcación posee dos banderas y al cruzar una frontera marcada por un mojón en las orillas del río, debe correrse a intercambia el símbolo que se porta de acuerdo a la embarcación, es como si cada vez que se fuera en carro uno tuviera que bajarse a cambiar de placa. ¿No son acaso dos vecinos que se frecuentan?
Los Nicaragüenses son un país pobre pero muy trabajador, me atrevería a decir que trabajan, en promedio más que los ticos de la zona, pero con menores remuneraciones. Solo un ejemplo, el bote de CR a Nic cuesta 6 mil colones, y de regreso de Nic a CR 5 mil, ambos montos cobrados en colones, es decir no hay truco de tipo de cambio.
La diferencia que más me afectó fueron las decisiones de cómo vivir la pobreza, teniendo un maravilloso lago, mucha pesca, mucho turismo, la suciedad,
los servicios de baja calidad dejan ver los pocos deseos de superación en algunos. Sé que como país Nicaragua posee un enorme potencial, pero creo que
deben enrumbar sus esfuerzos gastar menos en seguridad militar y mejorar los niveles de educación, preocuparse por limpiar más sus locales comerciales
y ser en general más serviciales con los visitantes.
Finalmente cuento la anécdota del joven que se ofrece con un lapicero a llenar las boletas de migración, él cobra por su capital humano: saber leer y escribir 300 colones, con eso y a 40 personas por bote, bien se está ganando mucho más que en la recolección de naranjas o frijoles de la zona. Un buen ejemplo de cómo se puede con inversión en educación cambiar pronto las condiciones generales que están a un pequeño paso de ellos mismos las puedan cambiar.
miércoles, 13 de abril de 2011
Paperless Office
Desde el año 2002 vengo escuchando de las grandes compañías, Microsoft, Lotus, HP, que el mundo está a punto de dar el salto hacia la oficina con cero papel. Conozco un caso en CR en donde un jerarca lo llegó a promover a tal nivel que la única impresora de una empresa de 60 funcionarios estaba dentro de su oficina. Nueve años después sigo escuchando las mismas escusas de las personas para mantener la idea de que el respaldo impreso es importante:
1. Dicen que por comodidad, es más fácil leer en una hoja de papel que en un monitor.
2. Dicen que por portabilidad, un papel se guarda en una carpeta y siempre esta disponible, no en todo lugar hay posibilidad de tener una computadora
3. Dicen que por respaldo, la famosa frase papelitos hablan, o se sigue requiriendo obtener un sello o una firma para un determinado trámite.
4. Dicen que el almacenamiento es caro, un papel con una foto es un archivo a criterio de algunos pesado.
Las cosas están cambiando, cada vez estas razones están perdiendo validez, la tecnología está transformando nuevamente al mundo, los Kindle o Ipad, la firma digital y la misma moda hace que cada día estemos más cerca de dar el gran salto de la era digital, en donde el papel por fin nos deje de desvelar.
Escribo hoy con pluma, pues sé que me tocará vivir el día en que se leerá en un monitor, en donde no se tendrá el placer exclusivo de estampar los garabatos de la firma y en lugar de cuadernos portaré un dispositivo ágil y barato en el que todos confiaremos.
Es bueno formar parte de la historia.
1. Dicen que por comodidad, es más fácil leer en una hoja de papel que en un monitor.
2. Dicen que por portabilidad, un papel se guarda en una carpeta y siempre esta disponible, no en todo lugar hay posibilidad de tener una computadora
3. Dicen que por respaldo, la famosa frase papelitos hablan, o se sigue requiriendo obtener un sello o una firma para un determinado trámite.
4. Dicen que el almacenamiento es caro, un papel con una foto es un archivo a criterio de algunos pesado.
Las cosas están cambiando, cada vez estas razones están perdiendo validez, la tecnología está transformando nuevamente al mundo, los Kindle o Ipad, la firma digital y la misma moda hace que cada día estemos más cerca de dar el gran salto de la era digital, en donde el papel por fin nos deje de desvelar.
Escribo hoy con pluma, pues sé que me tocará vivir el día en que se leerá en un monitor, en donde no se tendrá el placer exclusivo de estampar los garabatos de la firma y en lugar de cuadernos portaré un dispositivo ágil y barato en el que todos confiaremos.
Es bueno formar parte de la historia.
martes, 5 de abril de 2011
Test de volumen son diferentes a los test de estrés
Existen al menos 15 tipos diferentes de test que pueden ser aplicados al software, dos de ellos tienen a confundirse: los de volumen y los de estrés.
Un test de volumen lo que pretende es encontrar las pulgas asociadas al despliegue de gran cantidad de información, por ejemplo en un reporte, es decir si la aplicación en cuestión tolera realizar su trabajo ante algo de gran tamaño.
Por su parte los test de estrés lo que buscan es medir el desempeño por unidad de tiempo, es decir, encontrar cuanta información se puede procesar por minuto, en general todo lo que se pueda expresar por unidad de tiempo está más del lado del segundo tipo de prueba.
Un test de volumen lo que pretende es encontrar las pulgas asociadas al despliegue de gran cantidad de información, por ejemplo en un reporte, es decir si la aplicación en cuestión tolera realizar su trabajo ante algo de gran tamaño.
Por su parte los test de estrés lo que buscan es medir el desempeño por unidad de tiempo, es decir, encontrar cuanta información se puede procesar por minuto, en general todo lo que se pueda expresar por unidad de tiempo está más del lado del segundo tipo de prueba.
jueves, 31 de marzo de 2011
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.
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.
lunes, 28 de marzo de 2011
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.
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.
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.
domingo, 27 de marzo de 2011
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.
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.
martes, 22 de marzo de 2011
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.
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.
domingo, 20 de marzo de 2011
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 :)
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}
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}
Responder lo que se pregunta!!!
Esta semana tuve una comprobación de lectura que me dejó la difícil de superar nota de un 6 de 10. La retroalimentación dada por el docente fue clara, la razón de mi bajo desempeño (menos que aceptable) fue "Tu respuesta no responde de forma explícita a lo que se pedía". Esta lección aprendida la quiero extrapolar a lo que debe esperarse en todo momento de un ser racional: estar focus en lo que uno se está haciendo, no dejar que tus ideas te distraigan.
Mi intención no es justificar, es más bien auto hacerme la pregunta de cúantas veces por dejar seguir la mente con una idea, se pierde la capacidad de seguir la conversación o de prestar atención a lo que se esta haciendo. Me es normal leer párrafos, y al darme cuenta no recordar lo leído. La razón, cuando una frase de las leídas me captó, la mente inmersa en el deseo de razonar se vuela y no hay nadie que la detenga.
La única solución que se me ocurre es leer con más detenimiento lo que se le está pidiendo, usar las energías mentales para razonar, usando argumentos de lógica (premisas, conclusiones, inferencia, etc), en las cuales en el pasado no lo he hecho tan mal.
A está focus con lo que viene....
Mi intención no es justificar, es más bien auto hacerme la pregunta de cúantas veces por dejar seguir la mente con una idea, se pierde la capacidad de seguir la conversación o de prestar atención a lo que se esta haciendo. Me es normal leer párrafos, y al darme cuenta no recordar lo leído. La razón, cuando una frase de las leídas me captó, la mente inmersa en el deseo de razonar se vuela y no hay nadie que la detenga.
La única solución que se me ocurre es leer con más detenimiento lo que se le está pidiendo, usar las energías mentales para razonar, usando argumentos de lógica (premisas, conclusiones, inferencia, etc), en las cuales en el pasado no lo he hecho tan mal.
A está focus con lo que viene....
miércoles, 16 de marzo de 2011
El arte de probar el software
Siguiendo con el mismo patín de la entrada anterior, Glenford J. Myers en su libro sobre el arte de probar el software, desarrolla en su capítulo 2 una interesante guía o marco conceptual, por medio del cual entender en que consiste la responsabilidad de emitir criterio sobre una determinada aplicación.
En primer lugar el autor nos señala que puede existir un enfoque equivocado al definir qué es un test, es decir un pecado de origen. Si le pidiéramos al evaluador que "demostrará que no hay errores presentes" obtendríamos un resultado significativamente diferente de si pedimos "que encuentren todos los errores que pueda". Varias son las razones para esta diferencia. Primero, tomemos como ejemplo un enfermo que va a un Laboratorio, si el análisis indica que no hay nada mal en la persona, pero esta se siente mal, la prueba habrá sido un fracaso. El plantear como objetivo buscar que algo esté bien, no presenta oportunidades de mejora a las cuales aprovechar, es decir al paciente le interesa que le encuentren algo que lo guíe para sentirme mejor. La segunda razón por la cual la definición es importante es porque demostrar que algo está bien puede ser una tarea titánica de nunca acabar, con lo cual el costo de encontrar el error adicional puede ser tal que haga que la prueba tenga un mayor costo que la aplicación. Finalmente, la tercera razón que es relevante es la definición debe solventar el problema de demostrar no solo que el programa hace lo que debe hacer, sino que además no haga lo que se espera que no haga y esto solo es posible en un marco más flexible de buscar la mayor cantidad de errores posibles.
La segunda idea relevante que plantea el autor en su artículo es la existencia de dos tipos de pruebas: las de caja negra y las de caja blanca. Respecto de las primeras se menciona que parten del hecho de solo preocuparse de lo que entra y sale de la aplicación, sin que sea relevante la parte interna. En este tipo de pruebas deben plantearse un universo de casos exhaustivos, con inputs válidos y no validos a efecto de verificar que las salidas tenga razonabilidad. Ahora bien el universo de entradas y las correspondientes salidas pueden dar origen a infinidad de combinaciones. Respecto al segundo tipo de pruebas, el autor menciona que éstas se concentran en el interior de la aplicación, es decir en su lógica. Esto representa dos grandes retos. El primer reto consiste en identificar todas las posibles rutas por las componentes del software que se pueden presentar, para verificar que las interrelaciones ante determinadas circunstancia estén previstas en la aplicación y funcionen adecuadamente. El segundo reto tiene que ver con la prueba individual de los componentes internos, la verificación de si los componentes son todos los necesarios o si es que hacen falta y si cada uno de estos componentes es sensible a datos y como pudieran manejar las distintas excepciones. Como podrá darse cuenta el lector esta también es una tarea titánica. La conclusión acerca de cuál de los dos tipos de pruebas es más favorable no es definitiva, más bien dado el amplio espectro es que se recomienda combinarlas y tratar de aprovechar al máximo sus beneficios.
Finalmente el autor nos menciona algunos principios que toda evaluación de software debiera respetar:
1. Definir de previo los resultados esperados
2. No revisar el software que uno hace
3. Las organizaciones deberían buscar que un tercero también pruebe su software.
4. Los resultados de las pruebas deben inspeccionarse a fondo
5. Las pruebas deben contener escenarios inesperados o inválidos
6. Las pruebas deben llevarse a cabo en diferentes momentos y sobre los mismos.
7. Evitar improvisar al momento de realizar la prueba para poder repetirla posteriormente
8. Debe partirse del hecho de que hay errores
9. Al hacer la prueba en las partes, errores en un componente es proporcional a errores en el resto
10. Hacer pruebas es un trabajo creativo e intelectual.
Definitivamente estamos aprendiendo de las pruebas, cierto??
En primer lugar el autor nos señala que puede existir un enfoque equivocado al definir qué es un test, es decir un pecado de origen. Si le pidiéramos al evaluador que "demostrará que no hay errores presentes" obtendríamos un resultado significativamente diferente de si pedimos "que encuentren todos los errores que pueda". Varias son las razones para esta diferencia. Primero, tomemos como ejemplo un enfermo que va a un Laboratorio, si el análisis indica que no hay nada mal en la persona, pero esta se siente mal, la prueba habrá sido un fracaso. El plantear como objetivo buscar que algo esté bien, no presenta oportunidades de mejora a las cuales aprovechar, es decir al paciente le interesa que le encuentren algo que lo guíe para sentirme mejor. La segunda razón por la cual la definición es importante es porque demostrar que algo está bien puede ser una tarea titánica de nunca acabar, con lo cual el costo de encontrar el error adicional puede ser tal que haga que la prueba tenga un mayor costo que la aplicación. Finalmente, la tercera razón que es relevante es la definición debe solventar el problema de demostrar no solo que el programa hace lo que debe hacer, sino que además no haga lo que se espera que no haga y esto solo es posible en un marco más flexible de buscar la mayor cantidad de errores posibles.
La segunda idea relevante que plantea el autor en su artículo es la existencia de dos tipos de pruebas: las de caja negra y las de caja blanca. Respecto de las primeras se menciona que parten del hecho de solo preocuparse de lo que entra y sale de la aplicación, sin que sea relevante la parte interna. En este tipo de pruebas deben plantearse un universo de casos exhaustivos, con inputs válidos y no validos a efecto de verificar que las salidas tenga razonabilidad. Ahora bien el universo de entradas y las correspondientes salidas pueden dar origen a infinidad de combinaciones. Respecto al segundo tipo de pruebas, el autor menciona que éstas se concentran en el interior de la aplicación, es decir en su lógica. Esto representa dos grandes retos. El primer reto consiste en identificar todas las posibles rutas por las componentes del software que se pueden presentar, para verificar que las interrelaciones ante determinadas circunstancia estén previstas en la aplicación y funcionen adecuadamente. El segundo reto tiene que ver con la prueba individual de los componentes internos, la verificación de si los componentes son todos los necesarios o si es que hacen falta y si cada uno de estos componentes es sensible a datos y como pudieran manejar las distintas excepciones. Como podrá darse cuenta el lector esta también es una tarea titánica. La conclusión acerca de cuál de los dos tipos de pruebas es más favorable no es definitiva, más bien dado el amplio espectro es que se recomienda combinarlas y tratar de aprovechar al máximo sus beneficios.
Finalmente el autor nos menciona algunos principios que toda evaluación de software debiera respetar:
1. Definir de previo los resultados esperados
2. No revisar el software que uno hace
3. Las organizaciones deberían buscar que un tercero también pruebe su software.
4. Los resultados de las pruebas deben inspeccionarse a fondo
5. Las pruebas deben contener escenarios inesperados o inválidos
6. Las pruebas deben llevarse a cabo en diferentes momentos y sobre los mismos.
7. Evitar improvisar al momento de realizar la prueba para poder repetirla posteriormente
8. Debe partirse del hecho de que hay errores
9. Al hacer la prueba en las partes, errores en un componente es proporcional a errores en el resto
10. Hacer pruebas es un trabajo creativo e intelectual.
Definitivamente estamos aprendiendo de las pruebas, cierto??
martes, 15 de marzo de 2011
Probar software sin especificaciones
Estoy leyendo un artículo del señor Michael Bolton, ojo no es el cantante, publicado en junio del 2005 en http://www.stickyminds.com/, en donde desarrolla la idea de que es es posible probar el software sin tener las especificaciones desde el origen. Situación que obviamente comparto.
Lo que el señor Bolton nos plantea es que por medio de la experiencia y las destrezas personales es posible hacer un primer viaje exploratorio por la aplicación y a partir de este, formar un criterio acerca de su desempeño.
¿Por qué en un inicio no es necesario recurrir a las especificaciones? La respuesta es muy sencilla. En primer lugar, son muy pocos los casos en que tenemos acceso a todas las especificaciones, es decir, probablemente tengamos acceso a una parte del proyecto, pero no necesariamente a todo. En segundo lugar, si el software ya ha sido desarrollado hace algún tiempo, es probable que las especificaciones que encontremos no estén o se encuentren desactualizadas, y en tercer lugar los proyectos tecnológicos cambian constantemente y no necesariamente la documentación de las especificaciones se muevan al mismo ritmo.
¿Lugar de las especificaciones? El señor Bolton también nos llama la atención acerca de la fuente de las especificaciones, es decir de donde el responsable de las prueba las obtendrá, en el mejor de los casos estarán documentadas, pero puede darse el caso de que haya que recurrir a entrevistas, correos, etc, y deberán considerarse como oficiales o requerir que se oficialicen.
Técnicas de probar. Según el autor existen dos posibles categorías para agrupar las pruebas: las de oráculo y las heurísticas. La primera categoría alberga el criterio experto, el que es capaz de ver más allá de un documento con especificaciones y se deja llevar por su persepción del lugar donde el software presentará pulgas. La segunda categoría plantea que debe existir una guía provisional que facilite la exploración, la cual debe estar lista de previo.
Tips para el "tester". (Regla HIC-CUPPS) Para los que quieren obtener tips para llevar adelante una evaluación, el autor recomienda según un acrónimo, por donde entrarle al tema.
Historia: Revisar como la aplicación se ha comportado en el pasado.
Imagen: Fijarse en como el producto luce y a partir de su imagen evaluar el comportamiento.
Comparación: Buscar otros productos con funcionalidades similares para inferir las que el evaluado debe tener.
Claims: Revisar lo que se ha ofrecido que el producto haga.
Usuarios: Revisar lo que los usuarios han pedido que haga.
Producto: Verificar que lo que el producto dice que hace, lo haga.
Propósito: Verificar el propósito primario de cada función.
Statutes: Verificar lo que la regulación espera que el producto haga.
Con esto creo que somos casi unos expertos en llevar adelante una primera exploración a una determinada aplicación y estaríamos casí listos para hacer un test.
Lo que el señor Bolton nos plantea es que por medio de la experiencia y las destrezas personales es posible hacer un primer viaje exploratorio por la aplicación y a partir de este, formar un criterio acerca de su desempeño.
¿Por qué en un inicio no es necesario recurrir a las especificaciones? La respuesta es muy sencilla. En primer lugar, son muy pocos los casos en que tenemos acceso a todas las especificaciones, es decir, probablemente tengamos acceso a una parte del proyecto, pero no necesariamente a todo. En segundo lugar, si el software ya ha sido desarrollado hace algún tiempo, es probable que las especificaciones que encontremos no estén o se encuentren desactualizadas, y en tercer lugar los proyectos tecnológicos cambian constantemente y no necesariamente la documentación de las especificaciones se muevan al mismo ritmo.
¿Lugar de las especificaciones? El señor Bolton también nos llama la atención acerca de la fuente de las especificaciones, es decir de donde el responsable de las prueba las obtendrá, en el mejor de los casos estarán documentadas, pero puede darse el caso de que haya que recurrir a entrevistas, correos, etc, y deberán considerarse como oficiales o requerir que se oficialicen.
Técnicas de probar. Según el autor existen dos posibles categorías para agrupar las pruebas: las de oráculo y las heurísticas. La primera categoría alberga el criterio experto, el que es capaz de ver más allá de un documento con especificaciones y se deja llevar por su persepción del lugar donde el software presentará pulgas. La segunda categoría plantea que debe existir una guía provisional que facilite la exploración, la cual debe estar lista de previo.
Tips para el "tester". (Regla HIC-CUPPS) Para los que quieren obtener tips para llevar adelante una evaluación, el autor recomienda según un acrónimo, por donde entrarle al tema.
Historia: Revisar como la aplicación se ha comportado en el pasado.
Imagen: Fijarse en como el producto luce y a partir de su imagen evaluar el comportamiento.
Comparación: Buscar otros productos con funcionalidades similares para inferir las que el evaluado debe tener.
Claims: Revisar lo que se ha ofrecido que el producto haga.
Usuarios: Revisar lo que los usuarios han pedido que haga.
Producto: Verificar que lo que el producto dice que hace, lo haga.
Propósito: Verificar el propósito primario de cada función.
Statutes: Verificar lo que la regulación espera que el producto haga.
Con esto creo que somos casi unos expertos en llevar adelante una primera exploración a una determinada aplicación y estaríamos casí listos para hacer un test.
domingo, 13 de marzo de 2011
Conocimiento: mi definición
Estoy llevando un curso de gerencia del conocimiento y la primera pregunta del profesor me dejo "picado": ¿qué es el conocimiento?.
Por mucho tiempo deje este tipo de preguntas al apoyo de la RAE, Wikipedia o cualquier otro que haya hecho el trabajo por mi de recabar información. Sin embargo, hoy quise entrar de lleno en conocer qué es conocimiento. Adelanto que ya Platón, San Agustín o Nonaka y Takeuchi han hecho un aporte al estado del arte, del que yo jamás intentaré mejorar con este post. Mi única intensión es comentar, sólo comentar.
Conocimiento para mi tiene que ver con "capacidad de asombro". El ser humano esta expuesto durante su vida a una serie de datos, emociones y experiencia que por el simple hecho de haberlas enfrentado no entran a formar parte de un selecto grupo de "lecciones aprendidas" que llamamos conocimiento. Pienso en este momento en la experiencia de un niño recién nacido al que se le acerca una sonaja (chilindrín) y maravillado conoce el sonido, pienso en el joven médico que en su primera operación ve latir un corazón y descubre la vida y pienso en el enamorado que al dar un beso descubre el amor.
Mi hipótesis es que todo aquello que te ha asombrado ha entrado, en ese mismo momento a ser parte de tu conocimiento.
¿Como aumentar el conocimiento? Según mi hipótesis bastaría con iniciar experiencias que a cada uno lo lleven al asombro, es decir estar expuesto. Como antítesis a esta afirmación aquellas personas que no estén expuestas a situaciones de asombro verán limitadas sus posibilidades de aumentar el conocimiento.
La especialidad. Como corolario a lo dicho la innegable consecuencia de ligar el asombro al conocimiento sería que habrá especialistas, es decir personas cuyas experiencias de asombro los hayan condicionado a llegar a un determinado nivel. Será por lo tanto una persona con mucho conocimiento en música quien haya estado expuesta a las mayores emisiones de las ondas haciendo vibrar su sistema auditivo, igualmente será un chef con mucho conocimiento el que haya experimentado en su papilas gustativas los distintos sabores y texturas que este mundo puede ofrecer. Agregue el lector por favor las situaciones de asombro que los hayan hecho poseedores del más importante tesoro que siempre podrán poseer, el conocimiento.
Todos nos hemos asombrado, todos tenemos conocimiento y todos podemos mejorarlo, fundamentalmente con una receta: estar expuestos al asombro, busque cada uno en donde obtenerlo.
Por mucho tiempo deje este tipo de preguntas al apoyo de la RAE, Wikipedia o cualquier otro que haya hecho el trabajo por mi de recabar información. Sin embargo, hoy quise entrar de lleno en conocer qué es conocimiento. Adelanto que ya Platón, San Agustín o Nonaka y Takeuchi han hecho un aporte al estado del arte, del que yo jamás intentaré mejorar con este post. Mi única intensión es comentar, sólo comentar.
Conocimiento para mi tiene que ver con "capacidad de asombro". El ser humano esta expuesto durante su vida a una serie de datos, emociones y experiencia que por el simple hecho de haberlas enfrentado no entran a formar parte de un selecto grupo de "lecciones aprendidas" que llamamos conocimiento. Pienso en este momento en la experiencia de un niño recién nacido al que se le acerca una sonaja (chilindrín) y maravillado conoce el sonido, pienso en el joven médico que en su primera operación ve latir un corazón y descubre la vida y pienso en el enamorado que al dar un beso descubre el amor.
Mi hipótesis es que todo aquello que te ha asombrado ha entrado, en ese mismo momento a ser parte de tu conocimiento.
¿Como aumentar el conocimiento? Según mi hipótesis bastaría con iniciar experiencias que a cada uno lo lleven al asombro, es decir estar expuesto. Como antítesis a esta afirmación aquellas personas que no estén expuestas a situaciones de asombro verán limitadas sus posibilidades de aumentar el conocimiento.
La especialidad. Como corolario a lo dicho la innegable consecuencia de ligar el asombro al conocimiento sería que habrá especialistas, es decir personas cuyas experiencias de asombro los hayan condicionado a llegar a un determinado nivel. Será por lo tanto una persona con mucho conocimiento en música quien haya estado expuesta a las mayores emisiones de las ondas haciendo vibrar su sistema auditivo, igualmente será un chef con mucho conocimiento el que haya experimentado en su papilas gustativas los distintos sabores y texturas que este mundo puede ofrecer. Agregue el lector por favor las situaciones de asombro que los hayan hecho poseedores del más importante tesoro que siempre podrán poseer, el conocimiento.
Todos nos hemos asombrado, todos tenemos conocimiento y todos podemos mejorarlo, fundamentalmente con una receta: estar expuestos al asombro, busque cada uno en donde obtenerlo.
Inicio de una nueva aventura
Debo confesar que ya antes había tenido otros blogs, básicamente por curiosidad, pero los abandone, básicamente por poca disciplina y por no tener claro el norte.
Ante la solicitud que se me hiciera en un curso de la Universidad de crear nuevamente un blog encuentro muy interesante replantear la experiencia y formalizarla en este proyecto. La universidad me está plateando dos importantes paradigmas: el primero tiene que ver con tener un repositorio ordenado en donde poder almacenar "el conocimiento". El segundo, claro está, es llenar este repositorio con lo que vaya llegando que valga la pena compartir.
En lo personal voy a agregar un tercer paradigma que tiene que ver con la convivencia en estos espacios virtuales, en donde no sólo se vayan llenando los bytes de los servidores con temas académicos, sino que sea un diario personal en donde este proyecto tenga, a mi criterio un poco más de valor agregado en el sentido de que el conocimiento no sólo lo da la academia sino la vivencia. No sé con que periodicidad lo iré completando, pero espero que cada vez que llegue a mi mente algo relevante lo pueda publicar y así poder compartirlo con ustedes, quienes amablemente se toman su tiempo para leer mis publicaciones.
Felicito a todos los que ya han logrado avanzar en estos menesteres, pues es sin duda un trabajo muy retador.
Como en todo inicio son muchos los sueños y quien sabe hasta donde esto llegará...
Ante la solicitud que se me hiciera en un curso de la Universidad de crear nuevamente un blog encuentro muy interesante replantear la experiencia y formalizarla en este proyecto. La universidad me está plateando dos importantes paradigmas: el primero tiene que ver con tener un repositorio ordenado en donde poder almacenar "el conocimiento". El segundo, claro está, es llenar este repositorio con lo que vaya llegando que valga la pena compartir.
En lo personal voy a agregar un tercer paradigma que tiene que ver con la convivencia en estos espacios virtuales, en donde no sólo se vayan llenando los bytes de los servidores con temas académicos, sino que sea un diario personal en donde este proyecto tenga, a mi criterio un poco más de valor agregado en el sentido de que el conocimiento no sólo lo da la academia sino la vivencia. No sé con que periodicidad lo iré completando, pero espero que cada vez que llegue a mi mente algo relevante lo pueda publicar y así poder compartirlo con ustedes, quienes amablemente se toman su tiempo para leer mis publicaciones.
Felicito a todos los que ya han logrado avanzar en estos menesteres, pues es sin duda un trabajo muy retador.
Como en todo inicio son muchos los sueños y quien sabe hasta donde esto llegará...
Suscribirse a:
Entradas (Atom)