Uncategorized

Software Testing Advice for Novice Testers

Posted on 18 septiembre 2009. Filed under: Uncategorized |

Algunos me han preguntado que cosas tener en cuenta cuando se es un principiante en materia de Testing del Software. Mis respuestas particulares ya las dí, pero en viajes por Internet encontré un interesante sitio y un artículo muy bueno para tener en cuenta, aún cuando se es un experto.
Algunos conceptos solo son posibles de entender cuando los has vivido.
Software Testing Advice for Novice Testers

Anuncios
Leer entrada completa | Make a Comment ( Comentarios desactivados en Software Testing Advice for Novice Testers )

Comunidad Agile en Córdoba, Argentina??? WTF!!!

Posted on 1 abril 2009. Filed under: Uncategorized | Etiquetas: , , , |

En varias oportunidades no hice más que convocar a interesados en las metodologías Ágile de la provincia de Córdoba, Argentina. Lo hice por varios medios y de alguna manera vi que esto podía concretarse al comunicarme varias veces con algunos “Scrum Master no certificados” que habían participado en grandes eventos de Buenos Aires.
Al mismo tiempo que inicié “la movida” intentando juntarnos para generar maza crítica, conocer nuestros intereses con la agilidad, conocer nuestras problemáticas con los procesos actuales y “nacer en el grupo”, ya algunos enfocaron sus energías en Buenos Aires y abrieron un portal para “expertos en el negocio de la difusión académica”.
Dicho de otra forma y contando los hechos, el primer email masivo de la “COMUNIDAD AGILE CORDOBA” indicaba fecha, hora y duración del mega evento “Open Agile Córdoba” (evento que también difundo, hasta ahora). La primer reunión ya implicaba un grupo de acciones en la dirección del mega evento.
En mailing posteriores ya comenzaron a aparecer las opiniones de los “expertos en el negocio de la difusión académica”, alguno de ellos muy fuerte en sus intenciones de amalgamar a todos bajo un único grupo monocéfalo, proponiendo la adhesión a organizaciones que ni sabíamos que existían y evitando la formación de nuestra propia comunidad.
Fuí crítico, me opuse, los expuses y me criticaron. Mi acción posterior fue solo permanecer a la escucha, sobre todo cuando algunos me dieron a conocer sus verdaderas intenciones de negocios a futuro, luego de recibir su certificado de Scrum Master.
Allí me dí cuenta de la velocidad de acción que tienen algunos ante la oportunidad (suelo distinguir entre tener una oportunidad y el oportunismo), pero decidí que el tiempo será un gran testigo y juez a la vez.
Lo cierto es que el mega evento está en marcha, el grupo cordobés quedó reducido a unos cuantos que están en plena organización y no hay difusiones más chicas, ni convocatoria previa. También doy por descontado el éxito que el mega evento tendrá y de igual modo, que la comunidad agilísta de córdoba no existe, al menos en este momento y a menos que me haya perdido de todo.
Tal vez estoy presenciando un nuevo modo de hacer las cosas, donde la maza crítica se genera de un atracón y donde por la inercia de la convocatoria inicial, algo bueno puede quedar y así sumarse sará fácil y edificador.
Pero tengo mis dudas, por que a estas alturas hay muchos que hacen sus esfuerzos adhonorem por el mega evento, mientras un puñado más chico ya tiene los números bien controlados y muy a favor.
Una comitiva de “expertos en el negocio de la difusión académica” viaja desde Buenos Aires, costeados por el esponsoreo obtenido por estos trabajadores adhonorem. Es posible que no sean de mi convicción, solo por desconocer el esfuerzo que ellos hacen y el aporte que dan a una posible comunidad que se genere, post mega evento.
Reconozco que estas personas tienen mucha experiencia en realizar eventos donde mucha gente concurre y normalmente pagan por asistir. Reconozco que saben como manejarse y aglutinar esfuerzos. Tal vez sus propósitos son compartidos por muchos más que se suman de a poco.
Puedo reconocer también que no dejan muchas opciones, o mejor dicho que las opciones que quedan al menos para mi, son otras.
Quien esté como organizador del mega evento y pretenda criticar mi postura, por favor sea bien crítico y en el buen sentido de la palabra, por que esto que expongo, bien fue descripto con mucha brevedad por uno de los que de a poco fueron apareciendo en la lista de difusión interna y se trata de alguien a quien esa comunidad respeta. Esa persona supo decir, “en el interior no hay comunidad”.
Otro dato, El curso de Scrum Master es una aproximación a la certificación internacional, pero eso es una gestión independiente y se debe hacer ante una entidad internacional reconocida (ScrumAlliance).
Este curso a dictarse en Córdoba en el mega evento, cuesta U$D600.
Lo demás es gratis.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Comunidad Agile en Córdoba, Argentina??? WTF!!! )

Codificar a fuerza bruta – cuando mucho de algo es malo de verdad

Posted on 19 marzo 2009. Filed under: Uncategorized |

Un proyecto finaliza luego de 2675 horas invertidas y se hace el cálculo en % del consumo real por Etapas aprobadas por La Dirección.

Se observa en el primer cuadro (a la izquierda) dos tipos de %:

  1. “% en base a Total Horas” donde se indica qué fue lo que utilizó cada etapa calculando de acuerdo al total de horas del proyecto.
  2. “% en base Total Implementación” donde se indica que fue lo que utilizó cada etapa calculando de acuerdo al total de horas de Implementación.

En ambos casos los cálculos corresponden a un proceso propietario híbrido, diseñado y aprobado por La Dirección,

Cuadros comparativos de consumo de horas por Etapa en Proyecto de Software

El segundo cuadro “Duración estimada bajo Modelo CMMI” expresa la cantidad de horas que debió asignarse a cada etapa, según los % estipulados por historia de una organización que sigue el modelo CMMI y tomando como base las horas reales de Implementación de este proyecto.

  • Lo primero que se observa es que la cantidad de horas es sensiblemente superior (3597.73) si es que se hace una relación directa tomando como dato las horas reales de Implementación.

El tercer cuadro utiliza los mismos % estipulados por historia de una organización que sigue el modelo CMMI, pero se modifica las horas de Implementación para igualar el total de consumo real de horas del proyecto.
El objetivo es mantener la distribución % por etapa sugerida por la organización con historial bajo modelo CMMI. Esto no significa que el proceso de desarrollo deba ser acorde a CMMI, puesto a que seguiría siendo el proceso híbrido escogido, pero con una distribución según un modelo conocido.

se observa que:

  • el esfuerzo de Implementación es drásticamente menor (601.90) que en el proceso híbrido (1524.46) donde solo se consideró el esfuerzo de implementación
  • se sostienen los % de otras etapas críticas que dan soporte a la Implementación
  • Etapa Híbrido CMMI Diferencia
    A&D 38.94 228.67 189.73
    Despliegue 104.58 76.22 -28.36
    Implementación 1524.46 601.90 -922.56
    Requerimiento 116.55 274.40 157.87
    Testing 683.24 762.23 78.99
    UAT 103.25 350.63 247.38
    Seguimiento 104.15 381.12 276.97

Haciendo comparaciones simples, se pude concluir sencillamente que:

  • El esfuerzo de implementación sin el soporte de etapas complementarias, se transforma en un esfuerzo dramático donde se embeben en forma oculta las etapas de Requerimientos y A&D y trastoca a otros esfuerzos
  • Las etapas Requerimientos y A&D al ser utilizadas informalmente durante la Implementación, implica menos horas de codificación real por excesos de inter-consultas técnicas, re-definiciones de requisitos y por supuesto un muy bajo o escaso control de cambios
  • Al insumirse tanto tiempo en Implementación no necesariamente se esta invirtiendo en calidad, sobre todo si se hace sin un buen soporte de etapas previas, más otras complementarias como lo son el Seguimiento y Control, más validaciones y verificaciones en menor fracción de tiempo,
  • Los esfuerzos de Despliegue son mayores que los normales, lo cual se puede interpretar directamente como que se presentaron cientos de fallos en el intento de colocación del producto, retrabajo para estabilizar los procedimientos y del producto en si mismo.
  • Los bajos esfuerzos de UAT implican bajo compromiso del cliente, un proceso de validación débil e iteraciones mucho más largas que las convenientes. Estas iteraciones largas implican también un gran “tiempo muerto” o de espera para el cliente

PD/comentarios de asuntos políticos para otro artículo por favor.-

Leer entrada completa | Make a Comment ( Comentarios desactivados en Codificar a fuerza bruta – cuando mucho de algo es malo de verdad )

Conferencia GDC, SanFrancisco (EEUU) – Información valiosa sobre el futuro de los juegos

Posted on 15 marzo 2009. Filed under: Uncategorized |

gdcheader_main1
Información valiosa sobre el futuro de los juegos y las nuevas oportunidades en juegos móviles, la externalización, la distribución digital y más, son algunos de los focos de exposición que se verán este año en la GDC de Macone Center, San Francisco.
Este evento a sido valuado como el más importannte en el calendario de la industria del desarrollo de juegos en Estados Unidos (GDC 2009 ‘most important’ industry event this year) con la siguiente distribución en la votación:

  • Game Developers Conference: 40.6%
  • E3: 34%
  • GamesCom: 5.7%
  • Develop in Brighton: 3.8%
  • Nordic Game: 2.8%
  • DICE Summit: 2.8%
  • Games Convention Asia: 1.9%
  • Game Connection: 1.9%
  • GameHorizon: 0.9%
  • Other: 5.7%

Los principales interesados se encuentran en las siguientes categorias:

  • Career Seekers and Recruiters: El objetivo es conocer cara a cara a los más talentosos.
  • Studio Managers and Heads of Studios: Reunión de nuevos metodoso para gestión durante tiempos económicos inciertos y aprendizaje de nuevas técnicas para el marketing de juegos en plataformas emergentes.
  • Developers: “afilar” las habilidades utilizando las más avanzadas herramientas y técnicas utilizados en los juegos de alta gama.
  • Exhibitors and Sponsors: mostrar los productos de compañias, servicios e innovaciones para la más dinámica y concentrada comunidad de desarrolladores de juegos.
  • New Business and Venture Capitalists: tomar ventajas de una industria multi-millonaria generando una red de contactos con los estudios TOP a nivel internacional, desarrolladores e inversores.  Conocer las oportunidades del entretenimiento digital y comunidades que modelarán el futuro de los videos juegos.
Leer entrada completa | Make a Comment ( Comentarios desactivados en Conferencia GDC, SanFrancisco (EEUU) – Información valiosa sobre el futuro de los juegos )

Pruebas exploratorias Vs. Pruebas aleatorias

Posted on 26 febrero 2009. Filed under: Uncategorized |

Cuando hablo sobre la aliatoriedad de las pruebas, me estoy refiriendo la imposibilidad de repetir caminos concretos que nos permitieron detectar un fallo en particular.

Una prueba ejecutada con una variante, por más ínfima que parezca la variante, ya no es la misma prueba sino una totalmente distinta y factible de obtener otros resultados muy diferentes.

Me gusta ser aleatorio a la hora de probar, pues esto me lleva al descubrimiento de “lo inpensado”, pero suelo modelar las pruebas para mantenerlas dentro de unos límites tolerables por el sistema construido y en los márgenes de un alcance planeado.

No gusto de ser aleatorio a la hora modelar las pruebas para el contexto, de formalizar los ciclos y sus resultados esperados. De otro modo creo que promovería el caos en el Testing y lo diseminaría por todo el proceso de desarrollo. En otras palabras gusto de contar con ciclos controlados.

Ciclos bien controlados implican análisis de los requerimientos, del entorno de ejecución para el uso final, del entorno de ejecución para pruebas preliminares a las pruebas de sistemas, del entorno de ejecución para pruebas de sistemas, para pruebas de campo (post-despliegues), conocimiento de las dependencias, de las entradas y salidas y los procesos.

No deberíamos confundir “Testing aleatorio” con “Testing exploratorio”, puesto a que lo segundo aplica cierta formalidad en la técnica, aún cuando es libre de tomar algún camino alternativo no calculado o no premeditado.

La aliatoriedad del Testing no necesariamente ampliará la cobertura de pruebas, de hecho es demasiado factible que los criterios de aseguramiento de calidad (criterios de aceptación, modos de fallos-modos de pruebas) terminen siendo extraviados al violar límites y alcances por no calcularlos de antemano. Inclusive corremos demasiado el riesgo de modificar lo que se construye, si es que no mantenemos controlado el resultado de las pruebas.

¿Debemos responder al cambio? si lo antes posible. Pero no se puede hacer con pruebas no planificadas, con aliatoriedad mandatoria. Afrontar los cambios será posible a partir de la obtención de experiencia en los sistemas que necesitamos probar y garantizar y junto con esta experiencia obtenida crece la posibilidad de un Testing Exploratorio más conveniente que cualquier otro tipo de Testing.

La repetitividad de las pruebas que propongo, no van de la mano con la construcción de los casos de pruebas formales, sino del diseño que antes expliqué y la comprensión de la evidencias de construcción y de otros cientos de elementos que deberían, primero ser llevados a un nivel de abstracción dentro del contexto de las pruebas (no la abstracción típica de los requisitos y sus análisis de sistemas) y luego ser bajados al nivel de la ejecución.

En este nivel podremos configurar los distintos contextos, ya traducidos a ciclos ejecutables (hasrdware+software+testing), donde la adaptación de las pruebas será extremadamente simple aún cuando se generan nuevas características para el mismo sistema.

En conclusión, para mi el diseño de pruebas para diferentes contextos de ejecución es posible y es preferible. Las pruebas planteadas en Casos de Pruebas no sirven salvo que hablemos de productos enormes y sin posibilidades de cambios a traves del tiempo. Las pruebas aleatorias son sinónimo de pruebas sin planificación y sin conocimiento del impacto de los resultados. Las Pruebas Exploratorias son el resultado del estudio y aplicación del sistema en el contexto adecuado.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Pruebas exploratorias Vs. Pruebas aleatorias )

Webcast – Microsoft

Posted on 11 febrero 2009. Filed under: Uncategorized |

Comunicaciones Unificadas de Microsoft

Las comunicaciones unificadas transformarán los negocios en la próxima década, del mismo modo que el correo electrónico cambió el escenario comercial en los años '90.

Las Tecnologías Microsoft Comunicaciones Unificadas utilizan el poder del software para ofrecer comunicaciones completas: mensajería, voz y video en todas las aplicaciones y los dispositivos que las personas utilizan diariamente.

La integración de las experiencias relacionadas con el teléfono (llamadas telefónicas, correo de voz y conferencia) al trabajo que usted realiza en la computadora (documentos, hojas de cálculo, mensajería instantánea, correo electrónico y calendarios) tiene el poder de modificar esencialmente la manera en que funciona el mundo.

Cuando los servicios telefónicos se basan en software, son administrados por un servidor y llegan a las aplicaciones de escritorio, suceden muchas cosas interesantes:

  • La computadora comienza a funcionar como un teléfono
    Para llamar a alguien, sólo haga clic en su nombre y la computadora realiza la llamada. No tiene importancia si usted ve los nombres en un correo electrónico, dentro de Microsoft Office Word o en un sitio Windows SharePoint Services: la información de contacto y la capacidad de llegar a ella siempre está presente.
  • El teléfono comienza a funcionar como una computadora
    Intente esto con un teléfono de oficina estándar: llame a una persona, luego agregue a otra a la conversación. Bien, ahora agregue a diez personas. Luego, transforme la llamada en una video llamada en vivo. ¿Puede hacerlo? ¿En verdad es posible hacerlo?
    Con las tecnologías Microsoft Comunicaciones Unificadas, usted hace clic para llamar. Si hace clic nuevamente, puede iniciar una conferencia telefónica. ¿Necesita video? Con tan sólo un clic. Así de fácil.
  • El correo de voz se transforma en correo electrónico
    Llega el correo de voz a su bandeja de entrada de Microsoft Office Outlook, simplemente junto a su correo electrónico. Quizás no suene impresionante, pero ¿alguna vez intentó reenviar un correo de voz utilizando un teclado de teléfono de discado por tono?
    Cuando el correo de voz se transforma en correo electrónico, puede enviarlo simplemente como cualquier correo electrónico: a una persona, a un equipo de trabajo o a un departamento entero.
  • En el back end, las cosas son aun mejores
    Un cambio como este, por lo general, implica mucho hardware nuevo, trabajo adicional para TI y una infraestructura mucho más compleja; pero no con las tecnologías Microsoft Comunicaciones Unificadas.
  • VoIP tal como es usted
    No necesita una transición complicada para instalar las tecnologías Microsoft Comunicaciones Unificadas ya que Microsoft utiliza software en lugar de hardware. Microsoft Office Communications Server 2007, el servidor que proporciona presencia, mensajería instantánea, audio y video conferencia, integra perfectamente su infraestructura existente de telecomunicaciones, inclusive su PBX actual.
  • Las comunicaciones unificadas agilizan la infraestructura
    Las tecnologías Microsoft Comunicaciones Unificadas utilizan el Directorio activo para unificar todo el directorio corporativo: nombres, extensiones de PBX, direcciones de correo electrónico e inicios de sesión, lo que simplifica la administración de TI.
  • Las llamadas telefónicas se transforman en activos digitales
    Igual que con el correo electrónico, lo que significa que pueden ser registradas, revisadas, publicadas y archivadas. Tener un registro completo y un registro de cada llamada telefónica es cada vez más crítico en el desafío comercial relacionado con el cumplimiento de normas federales e internacionales más estrictas.
  • Flexible y de avanzada
    Al utilizar una solución de software para ofrecer comunicaciones unificadas, su negocio puede seguir siendo flexible y adoptar las innovaciones a medida que se presentan. Cuando las tecnologías emergentes y las necesidades comerciales cambiantes requieren que su infraestructura se adapte, lo único que usted debe hacer es actualizar el software, no el hardware.
 

Leer entrada completa | Make a Comment ( Comentarios desactivados en Webcast – Microsoft )

Agile. La evolución de las metodologías tradicionales?

Posted on 9 febrero 2009. Filed under: Empresa, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo, Uncategorized, Waterfall | Etiquetas: , , , , , , , , , , |

“Agile se ha vuelto tan popular entre los profesionales del software, que muchos se abstienen de criticarlo por miedo a ser etiquetados como “retrazados”, “de la vieja escuela”, o incluso “estúpido”.
Afortunadamente los profesionales IT con experiencia saben mejor y reconocen las limitaciones de Agile”

Así rezan las las declaraciones en un blog de Project Management, bastante conocido TheProjectManagmenteHut

Agile fue creado en gran parte en reacción al modelo predominante, WATERFALL, y en menor medida al resto de las tradicionales metodologías y aunque está en boca de todos y en manos de muchos, Agile hasta el día de hoy no ha demostrado ser superior a estas metodologías que le dieron razón y motivo para su existencia.
De hecho existe amplia y variada información que puede avalar tanto el éxito como el fracaso de las metodologías tradicionales, más su acoplamiento con los modelos y estándares de calidad reconocidos mundialmente y las culturas organizacionales más importantes del mundo, inclusive hablando de la industria del software.

Aunque no prentendo ser defensor de lo indefendible, ni “abogado del diablo” de Agile, es conveniente hacernos las siguientes preguntas:

  • cuando Agile es comparable con metodologías tradicionales?
  • cómo podemos combinar Agile con procesos tradicionales para abordar mejor una situación concreta?

Para responder a estas preguntas, es mejor reconocer las limitaciones de Agile

Un equipo de estrellas

Agile ha sido diseñado por experimentados y para experimentados.
Este es un aspecto a considerarse si se ha de intentar una incursión en las metodologías Agile, no como regla general, sino como un ítem de peso, sobre todo si se debe sostener el concepto de “equipo autogestionado”.

En lo personal y por la experiencia de participación en equipos Waterfall y en equipos en búsqueda de la agilidad, puedo decir que es mucho más dificil adaptarse a procesos Agile que a los procesos Waterfall, inclusive si se sigue un modelo de calidad como CMMI.

En los procesos Waterfall, el atributo de “equipos autogestionado” no es remarcable y aunque puede existir mucho trabajo individual, se hace bajo las premisas estrictas de la planificación, siguiendo los métodos y técnicas sugeridas y aceptadas por la organización. No se hace de otro modo o no lo estarías haciendo correctamente.

En estos procesos tradicionales, es cierto que existe también una gran carga administrativa pero en realidad no todos están afectados por ella y solo lleva una porción pequeña de tiempo y a muy baja complejidad realizarlas, principalmente para quienes no lideran los proyectos y solo rinden su progreso del día.

En los equipos Ágile, es un tanto más complicado la adaptación de las personas, siempre hablando de aquellas que no tienen la experiencia suficiente y el tren de trabajo disciplinado sin controles estrictos.
Aquí las entradas de algunos son fuertemente dependiente de las salidas de otros, no existe un trabajo individual o “individualista”, o no debería existir.

Las técnicas de gestión de tareas tradicionales pueden perder por completo su sentido y también debe existir una readaptación del mecanismo de estimación, de equilibrio de carga y del seguimiento. Los controles aunque parecieran ser menores, en realidad se incrementan por que el ciclo de vida en si mismo es mucho más corto y los cambios se presentan con mayor velocidad, pero parecieran ser de otra naturaleza y los resultados deben ser inmediatos, como también deben ser inmediatas las correcciones y a gran velocidad para que en la misma jornada laboral se tenga una aproximación del resultado, cuando no el resultado en si mismo.

El cáos está siempre al acecho…pero en que proyecto no lo está? La diferencia es la velocidad de detección de los inconvenientes, el análisis del problema y las soluciones, más su implementación, verificación y/o validación.
Entonces, preguntas simples pueden ser:

  • Tiene tu equipo el potencial para Agile?
  • Tienes el potencial para Agile?
  • Tienes la materia prima en las personas, para formar un equipo Agile?

Si la respuesta es “no” a algunas de estas preguntas, no significa que no puede transformase en Agile, solo quiere decir que puede haber algunos pasos intermedios a tomar antes de llegar allí.

Estos pasos suelen incluir la adaptación de la cultura del trabajo por equipos y la progresiva potenciación de los individuos, la formación y la contratación de las personas adecuadas.

Encaje con la cultura organizacional (los procesos son secundarios a la gente)

Habilitar el comportamiento Agile requiere de una gran dosis de libertad individual (no individualismo) y de equipo, que se traduce en una cruz funcional en constante adaptación del trabajo y funciones de conmutación, según sea necesario.

Se trata también de ajustar continuamente los procesos a fin de reflejar la situación actual. Más que nada, significa que los procesos son secundarios a la gente.

Otras organizaciones hacen incapié con estrechéz en los roles y responsabilidades, políticas y procesos, y han sido la clave de la supervivencia las mismas.

Aunque estas empresas estén bastante alejada de las dogmas de la agilidad, no es imposible que algunas unidades puedan realizar un trabajo diferenciado para experimentar, conocer y adaptar el nuevo paradigma.

Dado que la innovación es parte de la cultura de cualquier organización exitosa, entonces las personas que la integran tienen buenas habilidades y potencial para realizar “adaptaciones situacionales” y saltar de un modelo a otro.

Agile está restringido a equipos pequeños

  • Los equipos deben ser autogestionados, lo cual implica un orden eficiente emergente de un caos temporal. Este tipo de adopción del orden será mucho más prolongado en equipos grandes y perdería efectividad.
  • Los miembros del equipo de trabajo deben estar habilitados para comunicarse entre ellos espontáneamente, e inclusive con clientes y otros interesados en los proyectos.
  • La gestión diaria del equipo depende por completo de todo el equipo y no está centralizada en una sola persona. Es necesario el reconocimiento y visualización por parte de todo los miembros del equipo, de los cronogramas, tareas, cambios, impedimentos, etc.
  • Los miembros del equipo deben conocer exactamente que es lo que otros miembros están realizando, ayudar a otros que el proceso de su trabajo sea fácil, en forma colaborativa y sin un control centralizado.
  • Los miembros del equipo deben trabajar en la misma locación, facilitando el trabajo cara-a-cara y fortaleciendo los canales de comunicación inmediatos, sin tener las limitaciones típicas de las distancias, diferentes horarios e inclusive herramientas de gestión.

    Lo que se quiere expresar con estos puntos, es que equipos que superan un cierto límite en el número de integrantes (típicamente ocho) pierden eficiencia en las habilidades comunicacionales requeridas para equipos Agile. Así mismo la tarea de un Scrum Marster, se vería dificultada si tuviera que gestionar tareas, avances e inconvenientes de más cantidad de miembros y otros atributos como conocer las tareas y actividades entre todos los miembros se verían cada vez más en merma.

    Una forma de adaptación de equipos mucho más grandes, sería la división del mismo en equipos cross-funcionales más chicos y dinámicos.

    En este sentido necesariamente se deberá contar con un “nivel de gestión superior” que permita centralizar la información de todo el proyecto. Sin duda esto está lejos de ser puramente Agile, sino más bien una combinación de metodologías tradiciones y agilísmo.

    Hay que tener en cuenta también que si se divide un proyecto grande, se minimiza la dependencia arquitectónica del proyecto, para pasar de una medición del avance típicamente medido por su avances arquitectónicos, a una medición basada en la entrega de características funcionales. Esto da como resultado que la definición de “progreso” de Agile, deba ser adaptada a un nuevo contexto con un nivel de gestión superior.
    De nuevo la adaptación situacional “es un buen jugador”.

    Una gran limitación tiene que ver justamente con el especto comunicacional, dado que Agile promueve la comunicación cara-a-cara, con resoluciones dinámicas y proactivas, sin documentación más que la que oriente al desarrollo.

    El trámite comunicacional con otrás áreas es un trastorno que Agile debe aprender a dominar, puesto a que los modelos agilístas actuales exigen que otros interesados del proyecto deban siempre estar en la misma locación de trabajo, inclusive evitandose el traslado desde una oficina a otra para realizar simples consultas.

    La tecnología colaborativa y de multimedios, permiten actualmente realizar trabajos perfectamente coordinados y con esquemas de reuniones cara-a-cara, aunque virtualizadas, muy eficientes. Sin embargo esto no está bien aceptado en el mundo actual del agilísmo.

    Donde está mi metodología?

    Metodologías de desarrollo de software, tradicionalmente incluyen procesos como, Análisis, Arquitectura, Implementación, Gestión de Proyecto, Gestión de la Configuración, Gestión de Riesgos, Gestión de Cambios y una larga lista de procesos dependientes de Áreas de Procesos y Grupos de Procesos. Sin embargo, las metodologías

    Agile no promueven estos grupos de procesos y de hecho no los definen para sus marcos de trabajo, como tampoco definen un marco de gestión de proyectos.

    Esto puede verse justificado por el hecho de que las metodologías Agile tienen como insignia, que lo que demuestra y garantiza el proceso es el producto entregado y no la documentación que puedas presentarle a tu cliente.

    Las metodologías Agile delinean un marco conceptual, pero no explicitan de ninguna manera la exclusión de alguna de las prácticas tradicionales, aunque se asume que solo sobrevivirá lo estrictamente necesario para la obtención de los incrementos (entregables de software)

    Metodologías Agile completas parecen estar emergiendo y el soporte a la organización podrías ser total con adaptaciones sencillas de ambos metodologías, donde la substracción de las buenas prácticas de ambas, de como resultado el éxito y calidad total de la organización.

    Dado el contexto planteado es que me hago las siguientes preguntas para reflexionar:

    • ¿Existe la evolución de las metodologías Agiles?
    • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?
    • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?
    Leer entrada completa | Make a Comment ( 3 so far )

    “Entregar el producto” – Sacrificio del componente humano

    Posted on 24 diciembre 2008. Filed under: Uncategorized |

    Es cierto que tenemos marcada una línea de finalización, dicho en términos correctos es una “Línea de Muerte”. Allí debemos converger con un producto finalizado, listo para ser entregado.

    Desde el punto de vista tradicional significa cumplir con los requerimientos del cliente/proyecto en los términos pactados de alta calidad, tiempos acotados y a costos lo más económicos posibles, según el proyecto.

    Ahora bien, ¿como logramos obtener estos términos con la justicia necesaria tanto para el cliente como para el equipo de Ingeniería, sin que se tenga que sacrificar el componente humano para no sacrificar los componentes de Software? Una respuesta sencilla puede ser, hay que analizar los requerimientos y recién presupuestar teniendo en cuenta todos los elementos que se necesitan para una correcta estimación.

    ¿Y que pasa cuando esos elementos de análisis o yendo un poquito más atrás, la toma de requerimiento no es madura?
    ¿Que pasa con aquellos proyectos que de cuna tienen incorporado el “End Line”?
    ¿Puede la línea de muerte tener corrimiento?
    ¿Es posible sacrificar elementos de algunos de los componentes? lo cuales en definitiva significa mermar la calidad del componente.

    Por ejemplo, para cumplir con la finalización del hito de implementación, si el hito tiene desvíos significativos ¿hay que sacrificar las pruebas unitarias o de integración? ¿De que modo lo haría?

    O se debe replantear estrategias en la implementación, de modo tal que debamos agregar recursos, extender las jornadas a 16 horas de trabajo, trabajar los fines de semana. En otras palabras, sacrificar el componente humano.

    ¿Es cierto que los tiempos son nuestros?

    Leer entrada completa | Make a Comment ( Comentarios desactivados en “Entregar el producto” – Sacrificio del componente humano )

    La no calidad implícita en el proceso de trabajo

    Posted on 25 noviembre 2008. Filed under: Uncategorized |

    Luego de 10 días de haberse implementado la solución técnica en el área de Desarrollo, se hizo el despliegue correspondiente de los esquemas de base de datos y se entregó el paquete a Testing para realizar la primer prueba funcional, la cual al poco tiempo de iniciada comenzó a tener éxito al detectarse una buena cantidad de fallos de severidad graves y comunes.

    Los elementos de multitarea que el responsable de despliegue debió manejar en ese momento, le impidieron poder realizar tareas simples que habitualmente ejecuta, debiendo responder con mayor prioridad a otros eventos de su agenda laboral. Finalmente cuando pudo realizar la entrega, su trabajo no fue a conciencia y centrado como lo es normalmente, pues su agenda seguía igualmente saturada y con retrasos importantes para otras entregas de versiones de sistemas.

    Esta situación como otras similares, es ampliamente repetida en organizaciones de todo tamaño en todos los lugares del mundo y denota un importante elemento de trabajo no focalizado que disminuye la calidad del proceso de generación de soluciones integrales, evitando que el responsable tenga pleno control y conocimiento de todos los elementos desarrollados y empaquetados para ser pasados a Testing.

    Si agregamos que los ciclos de verificaciones se repitieron en N ocasiones, nos encontramos ante los síntomas de un problema de magnitud seria y al que simplemente podríamos llamar como “retrabajo”. Este término es comúnmente utilizado para minimizar lo que para mi es “la no calidad implícita en el proceso de trabajo”.

    Equipos chicos bien consolidados suelen caer en este tipo de “faltas” y hacer de ellas un estilo de trabajo perjudicial para toda la organización. ¿Cuanto más puede suceder lo mismo en equipos grandes aún con herramientas costosas de gestión?.

    Es que en realidad se trata de modos que se instalan como parte de la cultura de trabajo y poco tienen que ver con las herramientas, sino con la percepción de como deben ser las cosas y la concepción limitada de una solución de alto rendimiento, dentro del proceso de desarrollo.

    Quienes deben tomar una determinación para resolver este inconveniente, suelen estar limitados por visión de optimizar la productividad al menor costo posible y traspasan una línea casi invisible entre “la solución performante” y “la explotación del recurso”.  Esta línea suele ser de no retorno y normalmente pasa mucho tiempo hasta que se ven las verdaderas consecuencia de tal negligencia.

    Posiblemente la curva de productividad del personal decae sensiblemente (generalmente por cansancio, estrés y falta de motivación), las soluciones brindadas no son efectivas o requieren finalmente de mayor trabajo que el necesario, surgen confrontaciones entre colaboradores, también culpas son adjudicadas injustamente y esto puede culminar con despidos o renuncias abruptas y sin posibilidad de restaurar las relaciones.

    Es necesario que líderes de proyecto, jefes de áreas y directores de empresas, adviertan cual es el estado de los recursos de sus equipo de trabajo, balanceen cargar de responsabilidades y operaciones y estimen en que momento es necesario ampliar la capacidad de productividad tomando más personal y liberando a quienes ya no pueden incrementar su productividad o están en riesgo de disminuir sus potenciales.
    Al mismo tiempo conocer los elementos de motivación de los distintos grupos e individuos y promover que esos valores se dispersen por toda la organización hasta lograr un contagio en todas las áreas y en todas las personas.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en La no calidad implícita en el proceso de trabajo )

    SQL

    Posted on 18 noviembre 2008. Filed under: Uncategorized |

    Curso de SQL

    Otra vez, desempolvando mi SQL (hace más de dos años que no lo utilizo en buén nivel) decidí recurrir a un bookmark que tenía guardado desde hace tiempo. Aquí comparto este enlace al índice detallado del curso, creo que les puede ser de utilidad.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en SQL )

    New Web Note

    Posted on 18 noviembre 2008. Filed under: Uncategorized |


    Siguiendo con mi idea de compartir información que en algún momento me fue útil, les hago llegar este curso de MySQL en la red. El autor a ido incorporando paulatinamente mucha información que sirve no solo para el entorno MySQL sino para utilizar mucho mejor SQL en si mismo.
    A darle utilidad y retorno al autor.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en New Web Note )

    Búsqueda de soluciones para problemas "simples" de peso sustancial

    Posted on 10 octubre 2008. Filed under: Uncategorized |

    Gestionando el equipo de pruebas para una de los Ciclos de Pruebas de Funcionalidad de hoy, se pusieron en evidencia ciertos problemas de peso sustancial.

    En una situación especial el día de hoy tuve que desafectar a un Tester, reasignar los Script de pruebas y dejar mi gestión para asistir al nuevo probador en la ejecución de la prueba. Esto provocó una reacción un poco violenta del desafectado quien me hizo comentarios un poco fuera de lugar. Tuve la oportunidad de conversar con esa persona y plantearle nuevos puntos de vista, al menos para él.

    Al finalizar el Testing y generar los reportes de estado de las pruebas, también tuve una charla similar con la Líder de Proyecto, quien expresó que debemos hacer algo para evitar tantos errores en Desarrollo y Testing. Sin embargo quedó claro que en Testing se van a encontrar los defectos de las implementaciones y de los requisitos, ya sea directa o indirectamente, mientras que lo que hay que mejorar son elementos de la Calidad del Proceso.

    Mi forma de gestionar a partir de charlas anteriores con La Gerencia es un poco diferente y apunta a “limpiar los cuerpos de los Incidentes reportados”, dejando en esa sección solo los elementos de requisitos y análisis y separando los defectos del incidente en comentarios asociados. De esta manera se cumple con el pedido de esclarecer los Casos. 

    Dada la situación hago el siguiente análisis

    Los incidentes son dados de alta mostrando el problema, el cual en su mayoría no se entienden y tampoco especifican el modo correcto de funcionamiento.

    Esto se evidencia por comentarios de los mismos desarrolladores quienes expresan que “quizás el mayor error que se comente es que no rechazan lo que no entienden o cuando ven que la información no les alcanza”. Significa que de algún modo adquieren el conocimiento básico para poder seguir y quizás es la causa por la cual las estimaciones se duplican, triplican o más. También podría ser la causa por la cual no se dan soluciones completas y en los primeros pasos de verificación ya se pueden detectar fallos.

    Considerando el carácter escueto y hasta ausente de la documentación de referencia que indique como es la funcionalidad esperada, resulta grave no contar con las Pautas de funcionamiento normal, modos de fallos y modos de comprobación indicados en los mismos incidentes, con el criterio del que más sabe del asunto.

    El impacto es directo también en Testing dado que sin importar quienes son los involucrados, deben lidiar con la información escasa y dispersa en el incidente, desde el entendimiento del problema, el requisito si es que existiere y hasta la misma evidencia de solución.

    Así mismo no hay sección que indique como probar ni que resultado esperar y el Tester en el peor de los casos debe “inventar una secuencia de pruebas” que podría no tener la mayor ni la mejor cobertura.

    Quiero decir que los Incidentes deberían darse de alta teniendo en cuenta los siguientes puntos:

    1. Identificar claramente el Problema
      • Asunto claro que identifique unívocamente el problema
      • Descripción que indique con claridad y precisión el modo de ocurrencia
        Descripción debe identificar el modo genérico y no expresarse con un ejemplo
    2. Secuencia de pasos para reproducción del problema o reconocimiento del mismo
      Aquí puede materializarse el problema mostrando un ejemplo que puede incluir también capturas de pantallas, diagramas, prototipos, maquetas u otros elementos de valor agregado
    3. Identificar impactos directos e indirectos
      • Relacionados a la funcionalidad que contiene el problema
      • Relacionados a otras funcionalidades adyacentes o dependientes
      • Ampliación de criterios por parte de Desarrolladores luego de evaluar y estudiar el incidente y las evidencias de solución son directas para establecer un modo de verificación. Es decir que solo importa como evidencia para el Testing, el “como lo verifico” o “como lo pruebo”.

    Ya sabemos que si SQA pudiera definir criterios de calidad y Testing en forma anticipada, los resultados podrían ser mejores pero no es una situación que de mayor velocidad al proceso.
    En la mayoría de las situaciones, el criterio SQA ha sido discutido vehementemente y en base a posturas de limitaciones técnicas. Aún cuando la postura de SQA normalmente es del tipo “negocio” y apunta al “diseño” de la solución, sin pretender establecer tantos criterios técnicos.
    También en la mayoría de las situaciones SQA no cuenta con el tiempo de convivencia necesario con el problema para determinar los criterios de calidad y Testing. Esto se evidencia en la característica del “Testing de fuerza bruta”.

    En conversaciones finales con la Líder de Proyecto, coincidimos que muchas veces se pone en evidencia clara la falta de auto motivación para ejecutar la tarea particular que implica el Testing y que dada la situación actual del proceso de Testing, se necesita de mucha proactividad la cual tampoco está presente y se prefiere decir “no se entiende y esto así como está es una porquería”. Si todos sostenemos esta peculiar postura de negatividad entonces estaríamos siempre rechazando elementos que provienen de otros y son nuestra entrada de trabajo.

    La mejora de estos aspectos personales no implica dejar de lado el hecho real de que debamos mejorar la identificación del problema, los criterios de calidad, de diseño, de Testing unitario y de integración como el estilo de pruebas funcionales y sus reportes.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Búsqueda de soluciones para problemas "simples" de peso sustancial )

    No nos olvidemos de La Calidad

    Posted on 3 octubre 2008. Filed under: Uncategorized |

    Todos vivimos en el contexto de los proyectos, ya sea que se gestionen
    metódicamente o “artesanalmente”(el arte está en el conocimiento no en
    la improvisación) o en el peor de los casos, improvisadamente. También
    debemos ser muy honestos y francos admitiendo que la mayoría de las
    veces nuestros proyectos carecen de objetivos concretos de calidad y la
    misma es asumida, quizás según la influencia natural del entorno de la
    organización.
    Pero he aquí un problema, ya que internamente la calidad puede ser
    asumida en un nivel operativo de una manera, en un nivel generencial
    medio de otra manera, y en otros niveles gerenciales y comerciales se
    tiene otra expectativa y los clientes definitivamente tendrán el
    veredicto final.
    Sin embargo y a pesar de tanta diversidad perceptiva, existe una única
    verdad y es que el producto final llega con la calidad que llega según
    la cantidad de elementos de trabajo que hayan influenciado en pos de
    ella o en su detrimento, en las distintas fases del proyecto.
    Me atrevo a decir que la mayoría de las veces el grado de calidad de nuestros productos
    poco tienen que ver con la triple restricción del proyecto, puesto a
    que en relación, nuestro presupuesto es holgado, el tiempo está bien
    definido y asignado a las tareas que surgieron del análisis del
    alcance, pero nuestra calidad es pobre o baja.
    Que sucedió? nadie habló de calidad, no se hizo un Plan de Calidad, no
    todos en el equipo supieron que esperar para cada entregable, la
    organización normalmente se maneja de esta forma y el producto se
    refina en infinitas iteraciones fuera de proyecto o se consume soporte
    a grandes escalas.
    Nuestras organizaciones normalmente suelen funcionar
    así, ya que la calidad es costosa en términos de esfuerzos organizaciones y no a todos les interesa. Sus procesos suelen ser intrínsecos a los procesos de
    producción y requieren del manejo de un subproyecto para cada proyecto; Es casi como otra empresa (a veces considerada “el enemigo”) trabajando
    con la empresa que genera el producto (una visión mal entendida).
    Todos aprenderemos a gestionar proyectos, sus productos y sus
    servicios,  pero pocos entenderán de la calidad de los mismos y muchos
    menos la asumirán.

    Saludos,
    Javo.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en No nos olvidemos de La Calidad )

    La ACTITUD es todo!!!

    Posted on 18 septiembre 2008. Filed under: Uncategorized | Etiquetas: , , , , , |

    Si:
    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
    es igual a
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
    Entonces:

    Hard Work (Trabajar duro) H+A+R+D+W+O+R+K =8+1+18+4+23+15+18+11 = 98%

    Knowledge (Conocimiento) K+N+O+W+L+E+D+G+E = 11+14+15+23+12+5+4+7+5 = 96%

    ¿Y qué pasa con el amor? Love (Amor) L+O+V+E =12+15+22+5 = 54%

    ¿Y con la suerte? Luck (Suerte) L+U+C+K=12+21+3+11 = 47%

    ¿Acaso muchos de nosotros no pensamos que es lo mas importante ???

    Entonces que nos lleva al 100% ?

    ¿Acaso es el Dinero? ¿Money ? M+O+N+E+Y= 13+15+14+5+25 = 72% … NO! !

    Acaso es el Liderazgo Leadership ? L+E+A+D+E+R+S+H+I+P= 12+5+1+4+5+18+19+9+16 = 89% … Tampoco! !

    Entonces que nos lleva al 100% ?

    ATTITUDE (Actitud) A+T+T+I+T+U+D+E = 1+20+20+9+20+21+4+5 = 100%

    La ACTITUD es todo!!!
    Es nuestra ACTITUD en la vida, en el trabajo y frente a los desafíos lo que nos pone al 100% ! ! !
    Cambia tu ACTITUD y tu vida y tu estilo de dirigir cambiarán!!

    El ser humano tiene la creencia errónea
    de que necesita algo para ser feliz,
    no se da cuenta que la felicidad es una actitud.

    Una persona feliz
    no es una persona en determinadas circunstancias,
    sino una persona con determinadas actitudes.

    La actitud es una disposición mental que ejerce cierta influencia sobre las respuestas que un individuo da frente a las situaciones que le toca vivir. La actitud frente a la vida está relacionada con la visión que tenemos del mundo que nos rodea. De ahí que aquello que influye en cada uno de nosotros depende de la mirada que tengamos de los hechos y no de los hechos en si mismos.

    La actitud está relacionada con nuestros pensamientos y estos con nuestra mirada del mundo. De ahí que nuestra actitud cambiará si también lo hacen nuestras opiniones y nuestras creencias.

    Por otra parte, la actitud que puedo ver en el otro es una señal muy importante a tener en cuenta ya que manifiesta a las claras el ánimo de su disposición.

    Hay tres ámbitos en los que se constituye una actitud:

    1. A través de la conducta que nos lleva a la acción
    2. Del pensamiento que muestra como nos comunicamos con nosotros mismos
    3. Y de la emoción que nos predispone

    Solemos hablar de actitudes positivas o negativas y cuando lo hacemos a qué nos estamos refiriendo?

    La relación mas inmediata es afrontar lo que se nos aparece en el camino de los objetivos. Hay actitudes que favorecen el acercamiento a ellos y otras que no.

    Poseemos los elementos técnicos necesarios para cambiar el mundo,
    pero alguno de nosotros no tenemos las actitudes
    que pueden lograr este cambio.

    H.C. Triandis

    Jack Welch, ex CEO de General Electric y líder entre los gurúes de la administración moderna de empresas, sostiene que una actitud negativa a través del tiempo va deteriorando la confianza que se ha construido entre las personas que conforman el equipo humano de una empresa, de modo que esta confianza se va debilitando hasta desaparecer junto con el equipo, y por tanto, la capacidad que el equipo tenía para alcanzar resultados de excelencia o superiores, también se ve severamente dañada.

    A partir de esto podemos decir que las actitudes negativas afectan como un virus a una computadora, en lo que se refiere a resultados.

    Todo lo que experimentes pasa primero por el filtro de cómo es tu actitud hacia la vida


    ¿Conoce tu gente la importancia de la actitud?
    ¿Has hablado con ellos para saber qué les pasa y cómo fundan una actitud no favorecedora?
    ¿Cuáles son las actitudes positivas que, desde tu punto de vista, favorecen el logro de objetivos en tu empresa?
    ¿Cómo podrías capacitar a tu gente para desarrollarlas?
    ¿Qué conversaciones podrías abrir con la gente mas renuente?
    ¿Que prácticas podrías implementar?
    ¿Que te parece hablar de esto en tu próxima reunión con ellos?

    Actitudes positivas crean gente positiva
    Gente positiva funda empresas positivas
    Empresas positivas logran resultados positivos


    Extraído de: Conversando con un Coach # 357 “Actitud” (Newslater) de Patricia Hasuel

    Leer entrada completa | Make a Comment ( Comentarios desactivados en La ACTITUD es todo!!! )

    Calidad como Cuarta Restricción en Gestión de Proyectos?

    Posted on 17 septiembre 2008. Filed under: Calidad del Software, Project Management, Uncategorized | Etiquetas: , , , , , , , , |

    La calidad tiene cinco (5) vistas conocidas:

    1. TRASCENDENTAL (calidad = excelencia innata)
    2. BASADA EN USUARIO (adecuación al propósito)
    3. BASADA EN FABRICANTE (conformidad con requisitos)
    4. BASADA EN PRODUCTO (económica)
    5. BASADA EN VALOR (precio asequible)

    Es posible que dependiendo de cual sea el enfoque (vista) mandatorio respecto a la calidad para el proyecto en cuestión, será el alcance del mismo e impactará directamente en el alcance del proyecto en general y en toda la planificación.

    Ejemplo:
    La Gerencia general solo habilita 800 horas (tiempo) en función de los costos-beneficios (costo) para cumplir con un proyecto que naturalmente llevaría el doble de tiempo para lograr los objetivos máximos (alcance).
    Según este ejemplo, existen un fuerte enfoque orientado a la conservación del coste (vista “basada en valor”), pero los alcances serían prácticamente imposibles de lograr en el tiempo habilitado. Esta imposibilidad surge por que se asume que el producto debe contar con una calidad mínima esperada, quizás considerando los enfoques inadecuados, es decir “trascendental”, “basada en usuario” o “basada en los requisitos”, pero no se observa que las restricciones de tiempo y coste impactan directamente en el alcance.
    En conclusión, es posible que la calidad sea un atributo muy arraigado con la restricción ALCANCE y no se la deba considerar como una cuarta restricción, sino que se la debe tangibilizar dentro de uno de los elementos de la triangulación Alcance-Tiempo-Costos.

    Ver The triple constraint of the Customer versus the PM’s

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Calidad como Cuarta Restricción en Gestión de Proyectos? )

    Elementos de iniciación para la Gestión de Proyectos

    Posted on 16 septiembre 2008. Filed under: Uncategorized |

    Para aprender a aprender a gestionar proyectos es necesario que comencemos a conocer inicialmente términos comunes para cualquier administrador de proyectos:
    proyecto, programa, interesados, estructura organizacional, oficina de proyectos, restricción, triple restricción, ciclo de vida del producto y del proyecto, y áreas de conocimiento.

    También es bueno conocer los nombres de los grupos de procesos conocidos en la administración de proyectos:
    Iniciación
    Planificación
    • Ejecución
    • Monitoreo y control
    • Cierre

    También cuales son los procesos de integración:
    • Desarrollo del documento de autorización
    • Desarrollo del alcance preliminar
    • Desarrollo del plan de gestión del proyecto
    • Dirección y gestión de la ejecución del proyecto
    • Monitoreo y control del trabajo del proyecto
    • Control integrado de cambios
    • Cierre del proyecto

    Normalmente suele ser requisito que el perfil del alumno incluya conocimientos mínimos, capacidades y competencias en:
    • Estructuras organizacionales
    Administración

    Se recomienda también la lectura de la “Guía de los Fundamentos de la Dirección de Proyectos ‐ 3° Edición 2004” editada por el PMI.

    Todos estos son solo elementos de iniciación para la Gestión de Proyectos.

    Leer entrada completa | Make a Comment ( 1 so far )

    Proceso de Desarrollo OpenUP

    Posted on 2 septiembre 2008. Filed under: Uncategorized |

    Que es OpenUP?

    OpenUP/Basic es un FrameWork de procesos de desarrollo de software de código abierto. Es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software basados en desarrollo iterativo, ágil e incremental; y es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo.


    Este proceso de desarrollo unificado está basado en Rational Unified Process (RUP), desarrollado por IBM y reconocido mundialmente como uno de los procesos de desarrollo de software de mayor calidad, basándose en los principios de Adaptación, Importancia a los involucrados e interesados en los resultados del proyecto; Colaboración, Valor a la iteración; y Calidad Continua.

    OpenUP/Basic permite un abordaje ágil al proceso de desarrollo de software, con sólo proveer un conjunto simplificado de contenidos, fundamentalmente relacionados con orientación, productos de trabajo, roles, y tareas.

    OpenUP/Basic es un proceso interactivo de desarrollo de software simplificado, completo y extensible. Es un proceso para pequeños equipos de desarrollo que valoran los beneficios de la colaboración y de los involucrados con el resultado del proyecto, por encima de formalidades innecesarias.

    OpenUP está caracterizado por cuatro principios básicos interrelacionados, a saber:

    1 – Colaboración para unificar intereses y compartir conocimientos.

    2 – Equilibrio de prioridades competentes a maximizar el valor de los involucrados con el resultado del proyecto.

    3 – Enfoque en la articulación de la arquitectura.

    4 – Desarrollo continuo para obtener realimentación y realizar las mejoras respectivas. OpenUP/Basic se centra en articular la arquitectura para facilitar la colaboración técnica, reducir el riesgo y minimizar el sobreesfuerzo de desarrollo.

    OpenUP/Basic procura un equilibrio entre las necesidades de los involucrados con los resultados del proyecto y los costos técnicos, con el fin de maximizar el valor de los involucrados y las guías del proceso de desarrollo.

    OpenUP/Basic desarrolla un ciclo de vida interactivo que mitiga el riesgo a tiempo y ofrece demostrar resultados en curso al cliente del proyecto.

    Las tres capas del OpenUP

    ¿Cómo empezar con OpenUP?

    El cuarto principio de OpenUP, “Desarrollo continuo para obtener realimentación y realizar las mejoras respectivas”, sugiere un abordaje iterativo e incremental para implementar OpenUP en las organizaciones de desarrollo de software. Para ello se sugieren las siguientes actividades:

    A – Comience comprendiendo los cuatro principios básicos que propone el proceso de desarrollo de software OpenUP.

    B – Luego evalúe y compare OpenUP con el proceso que se está utilizando en su organización y luego seleccione una o dos áreas del proceso que usted desee mejorar.

    C – Aplique OpenUP/Basic en esas áreas

    D – En las últimas iteraciones del ciclo de desarrollo, realice una mejora incremental de las otras áreas del proceso adaptándolas a OpenUP/Basic.

    * Si usted no posee o tiene poca experiencia en procesos de desarrollo iterativos, selecciones un pequeño proyecto piloto que contenga un equipo de tres a cuatro personas y de duración de dos a tres meses e implemente OpenUP/Basic.

    Más información: http://es.wikipedia.org/wiki/OpenUP

    Más información del proyecto en Eclipse

    Información detallada para una buena Introducción a OpenUP

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Proceso de Desarrollo OpenUP )

    En el lugar del otro

    Posted on 28 agosto 2008. Filed under: Uncategorized |

    Cuando tú no haces algo es porque estas muy ocupado.
    Cuando el otro no lo hace, es porque está desorganizado.

    Cuando tú hablas, es una crítica constructiva.
    Cuando el otro habla, te está atacando.

    Cuando tú defiendes una idea, es convicción.
    Cuando el otro lo hace, es obstinado.

    Cuando tú no cumples, es distracción.
    Cuando el otro no cumple, quebranta tu confianza.

    Cuando tú mientes, dices que ocultas algo  
    Cuando el otro miente, dices que engaña.

    Cuando tú reclamas, luchas por tus derechos.
    Cuando el otro reclama, es perjudicial.

    Cuando tú  luchas por tus derechos, es prueba de carácter.
    Cuando el otro lo hace, es obstinado.

    Cuando tú hablas de ti mismo, es porque necesitas reconocerte.
    Cuando el otro habla sobre si mismo, es un presumido.

    Cuando tú te esfuerzas por ser agradable, eres cortés.
    Cuando el otro se conduce así, es pura actuación.

    Cuando tú encaras ambos lados de un problema, estas siendo comprensivo.
    Cuando el otro lo haces. Es confuso.

    Cuando tú haces alguna cosa sin indicación previa, es iniciativa.
    Cuando el otro lo hace, se está excediendo en sus funciones.

    Cuando tú progresas, es fruto de mucho trabajo.
    Cuando el otro progresa, tuvo suerte.

    “Un buen líder acepta más culpa
    de la que le corresponde
    y menos crédito del que merece”
    Arnold Glasow

    Leer entrada completa | Make a Comment ( Comentarios desactivados en En el lugar del otro )

    Ágile resulta más económico?

    Posted on 18 agosto 2008. Filed under: Metodologías de Desarrollo, Procesos Ágile, Uncategorized | Etiquetas: , , , , , |

    En términos de rendimientos económicos puede demostrarse con relativa facilidad la diferencia entre modelos de gestión Ágiles y Waterfall.
    Basados en la idea de que todo proyecto tiene objetivos concretos que alcanzar en tiempos y costos limitados, es fácil observar que mientras los modelos Waterfall administran sus entregables a lo largo de una escala de tiempo significativamente grande, los modelos Ágile planifican entregas a una escala mucho más corta. Siendo así es entendible que el valor apreciativo de cada entrega pactada se devalúe con el paso del tiempo, por el solo hecho de los cambios naturales en los requerimientos de los negocios que dan vida a los proyectos. Entonces son estos mismos cambios la razón principal para que una solución ofrecida para una versión de software “X.Y.Z” en poco tiempo deje de ser una solución efectiva para el negocio.
    El “
    valor esperado para una solución de negocio” es cada vez menor por cada una de las nuevas versiones promovidas por tales cambios, y aunque esta situación está presente en cualquier modelo de trabajo, hay que hacer una comparativa de la “devaluación” de la solución esperada entre entregables.
    Los modelos Waterfall típicamente tienen espacios
    de tiempos muy grandes entre entrega y entrega, y la depreciación del valor tiende a ser mayor que el revalúo que promueven las próximas entregas. Entonces la línea de valor esperado para una solución de negocio termina siendo sensiblemente menor con el transcurrir de la variable tiempo.
    Los modelos Ágile promueven entregas en iteraciones mucho más pequeñas, con lo cual si bien el cliente puede tener una baja apreciación inicial, a corta data puede observar el verdadero valor de tener soluciones efectivas en mucho menor tiempo, y aún cuando las misma no representan en si mismas la solución general, si representan soluciones integrales que para cada entrega representan mayor revalúo que depreciación.
    En lo particular tengo alta estima por los modelos ágiles, más que nada por el valor agregado que implican las iteraciones recurrentes con el cliente, quien no solo redirecciona los pasos del proceso de construcción de las soluciones, sino que revaloriza el modelo de trabajo al promover mejores alternativas para ser utilizadas en cortos plazos de tiempo. Esta iteración magnifíca la percepción del
    valor esperado” para muchas soluciones del mismo negocio.
    GoogleTech presenta en forma sintética esta idea donde se explica gráficamente como Ágile permite generar valor agregado con iteraciones más cortas:

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Ágile resulta más económico? )

    PyMes

    Posted on 12 agosto 2008. Filed under: Uncategorized |

    Pymes con alma de grandes empresas

    Pymes con alma de grandes empresas

    A pesar de que siempre se dijo y se comprobó que las Pequeñas y Medianas Empresas eran uno de los factores más dinámicos de la economía, no es sino en estos últimos años en que las Pymes han cobrado inusual protagonismo.

    La principal razón es, probablemente, la capacidad de adaptación de una compañía pequeña frente a los desafíos que les propone una crisis, un cambio de reglas de juego, una modificación de las condiciones políticas y económicas.

    De esta manera inicia el artículo que pubilica MicrosfotTechNet el 20 de febrero de 2007, donde explica cuales son los factores fundamentales que impulsan al crecimento de estas entidades y por que necesitan del escalamiento IT de modo administrado. Esta administración implica el cumplimiento de seis (6) funciones pilares para mejorar y aumentar la productividad:

    • Planificación, a partir de tener una visión global de la empresa y su entorno.
    • Organización, para el mejor aprovechamiento de las personas y de los recursos disponibles.
    • Motivación del personal.
    • Buena comunicación y ambiente de trabajo propicio.
    • Cuantificación del progreso con relación a los objetivos.
    • Representatividad del gerente ante otras organizaciones.

    La escencia de la temática es la buena elección de TICs, reforzando la confiabilidad y seguridad de la plataforma de base como el equipamiento PC y su plataforma de soporte, es decir sistemas operativos y aplicativos, sin considerar otras plataformas auxilares como las móviles, tan de moda en estos momentos. 

    Quitando las características comercializadoras de Microsoft para este artículo en particular, me centro en los aspectos genéricos de los ítems que se mencionan, tal es así que lo primero sería:

    • Correcta elección de los Sistemas Operativos, evitando sobre dimensionar o sub dimensionar esta elección. Esto implica un fuerte análisis de las necesidades de los distintos sectores operativos y gerenciales y la adecuación de las herramientas necesarias para el cumplimiento de las actividades rutinarias.

      Aqui es importante identificar las ventajas introducidas a partir de innovaciones en las interfaces para que las mismas sean más que amigables, sino inteligentes y bien contextuales, aplicativos accesorios (widgets o gadgets), interfaces de mensajería interna y externas, buscadores avanzados, conectividad, niveles de seguridad en cuentas de correo electrónico, características avanzadas de backup, diagnosticos de fallos, monitoreo de actividad de cada equipo o lotes de equipos, facilidad en la administración de todos estos elementos mencionados, etc. Todo estos aspectos básicos solo son útiles si están contemplados dentro de un marco de accesibilidad avanzada, facilidad de uso, intuitividad, amigabilidad, orientadas a experiencias de trabajo placenteras.

    • Lo segundo sería pensar en las herramientas de productividad, ya que para que una organización active sus unidades de negocio de manera eficiente, necesita el soporte operacional de herramientas especializadas para:
      administración de contactos personales y de negocios, correo electrónico, búsquedas contextualizadas, mensajería interna, oficinista, repositorio de documentación con administración de cambios y capacidades colaborativas, administración y seguimiento de actividades, entre otras especializaciones.

    Es importante tener en consideración el TARGET de cada organización PyMe y nuevamente hacer profundos análisis para el justo dimensionamiento, aunque nunca se debe dejar de estimar el crecimiento a corto, mediano y largo plazo.
    Se estima que las necesidades de negocio de una Pyme, en forma genérica son:

    • Establecer una red local entre computadoras, respetando jerarquías y controles de acceso.
    • Establecer un sistema de comunicación y colaboración efectivo entre los empleados.
    • Publicar y mantener un sitio web corporativo (y eventualmente un canal de comercio electrónico).
    • Permitir la comunicación con el exterior sin poner en riesgo la red local.

    Algunos de estos aspectos implican capacidades tales como:

    • Accesos WEB remotos a distintas capas de las soluciones de aplicativos existentes, para distintos niveles operativos
    • Publicación WEB segura para relación con proveedores
    • Conexión VPN de dos o más oficinas remotas
    • Generación de registros y reportes centralizados
    • Gestión y control de tráfico de red interna e Internet
    • Protección contra ataques de todo tipo

    Para que las decisiones a tomar sean correctas es necesario contar con los criterios de evaluación profesional que implican un marco actualización importante en TICs, no solo en materia del hardware y el software como costros visibles, sino también en materia de costos  ocultos, tales como los costos de capacitación del personal, instalaciones de equipamientos, despliegue y puesta en punto de las aplicaciones y actualizaciones, entre otros, bajo la premisa de que hoy en día la PyMe debe opera 24X7 en forma electrónica. .

    Leer entrada completa | Make a Comment ( Comentarios desactivados en PyMes )

    Accesibilidad es un componente esencial de la Usabilidad

    Posted on 12 agosto 2008. Filed under: Uncategorized |

    Tuve el agrado de participar de una encuesta realizada para la Dra. Gloria Reece, quien desde hace un tiempo atrás está haciendo investigaciones relacionadas a los atributos de Accesibilidad y Usabilidad y como las metodologías Ágile están abordando la materia, principalmente por que ve grandes lagunas al tratamiento de estos aspectos y que las soluciones técnicas ofrecidas no contemplan mínimas soluciones funcionales para personas con diferentes capacidades y necesidades

    Sus investigaciones tienen el objeto de hacer frente a las “lagunas literarias” sobre el impacto de la accesibilidad y usabilidad en entornos de desarrollo Ágile de software .

    Lo que aprecio de Gloria Rase es su punto de vista y posición No Neutral al respecto del impacto que tiene el continuo desentendimiento y descuido de los equipos de desarrollo de software, al no considerar aspectos de Accesibilidad que desde hace un buen tiempo esta plenamente legislado y va en evolución.

    Pero la pregunta principal puede ser: Qué accesibilidad?
    Moulton et al. (2002) states, “Simply put, accessibility means — providing access — making products and services available to, and usable by, everyone. Accessibility is about removing barriers. A more accessible environment benefits everyone — including people with disabilities and those without.”

    Hay muchos investigadores en la materia y todos concluyen que existen muy pocos aplicativos y sistemas que tienen un buen grado de inclusión de los aspectos de accesibilidad y en realidad los incluyeron, se podrías decir, “casi de casualidad” y son descubiertos luego de la generación del producto y su seguimiento.
    Es aquí cuando ellos definen con certeza, que “los productos son accesibles cuando pueden ser utilizados con la misma facilidad por distintas audiencias, con distintas limitaciones físicas y habilidades sensoriales y son el resultado del proceso de diseño concurrente basado en el usuario”.

    La encuesta que les muestro es sencilla pero tiene los elementos que los expertos en la materia consideran básicos y yo se las acerco para que dentro de lo posible, comencemos a hablar sobre cómo podemos mejorar la accesibilidad y la usabilidad de nuestras aplicaciones, independientemente del TARGET de nuestras aplicaciones.

    Mientras esté disponible, pueden acceder por este vínculo https://college.livetext.com/misk5/formz/public/24839/SUM25qfqLT

    También podemos acceder a las recomendaciones que hace la WAI (Web Accesibility Initiative) de la W3C para el diseño de WEB SITEs.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Accesibilidad es un componente esencial de la Usabilidad )

    Elegancia y tecnología avanzada en el cuerpo clásico de una Gibson

    Posted on 9 agosto 2008. Filed under: Uncategorized |

    La tecnología nos maravilla en ocaciones de un modo inesperado, tanto es así que cada quien encuentra algo que complementa de un modo u otro, aquello que siempre deseamos que fuera perfecto, pero que finalmente debimos dominar con dificultades.
    En mi caso particular siempre amé tocar la guitarra, pero mi caracter perfeccionista me obligaba a centrarme en los aspectos correctivos que poco tenían que ver con el arte en si mismo, como por ejemplo dominar las técnicas de afinación. Finalmente y sucede con todas las cosas, un ser humano promedio pierde tiempo y con ello sus energías, para dominar simplemente el arte y perfeccionarlo, sin lidiar con sus defectos herededados de las herramientas efímeras.
    Hoy la tecnología nos centra en la actividad que deseamos hacer, con un muy alto grado de satisfacción y puede ser simplemente conducir un automóvil, hablar por teléfono, mirar TV, utilizar una PC, diseñar un edificio o construirlo o tal vez, afinar una guitarra.
    Quiero mostrar esta vez algo que me maravilla por su simpleza, usabilidad, potencial, presición y adaptabilidad que
    garantizan robustez y estabilidad para que la funcionalidad básica sea realzada en sus aspectos de correctitud. Y por que a todo ello se le agraga valor al dar una gran fuerza de concepto a la gran combinación de elegancia y tecnología avanzada en el cuerpo clásico de una Gibson.

    Vean la gran Gibson Robot Guitar

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Elegancia y tecnología avanzada en el cuerpo clásico de una Gibson )

    A mejor Testing, peor calidad de Software?

    Posted on 22 julio 2008. Filed under: Calidad del Software, Uncategorized | Etiquetas: , , |

    Luego de altas persistencias de fallos, defectos y errores en los sucesivos ciclos de Testing para distintos proyectos y alguna cantidad de detecciones en los clientes, los reclamos con tonos elevados no se hicieron esperar. Hubo así entre dicho entre los Responsables de Despliegues, ataques entre Testers y Desarrolladores, Administradores de Pruebas y Responsables de Desarrollo y finalmente La Gerencia. Luego de planteos fuera de lugar y experiencias que nos pusieron en límites de tolerancias entre las personas, quise analizar por que estamos fracasando tan enfáticamente en lo que a calidad de los productos de software se refiere.

    Tengo mis anotaciones frescas en mi cuaderno de proyectos y en mi mente mucho más, sin embargo, luego de leer un poco de blogs que frecuento, encontré una referencia a un artículo muy interesante. El título expresa simplemente lo siguiente: “¿A mejor Testing, peor calidad de Software?”. Automáticamente me llamó la atención esta suerte de contradicción y abrí el PDF directamente desde la WEB.

    En cuanto inicié la lectura pude ver un diagrama que me refrescó los conceptos que vengo gestando desde mis análisis de problemas.

    Sucede que las metodologías, cualquiera sea, tienen ciertos elementos que si no sabemos tratar con cuidado, convierten todo un proceso en burdo y empantanado.

    Observé otra pregunta reveladora:

    “¿Cómo sabe que su Software no está en un Espiral Muerto?”

    A este respecto en el artículo se dan ciertas sugerencias como:

    • Cuenta la cantidad de fallos, errores y defectos
    • Escucha a los Testers
    • Observa los tiempos de Integración
    • Escucha a los desarrolladores
    • Presta atención a la demanda de recursos
    • Recuerda y ten en cuenta ciertos puntos de control
      • Usa una base de conocimiento de los fallos, errores y defectos entregados a producción
      • Aplica técnicas de prevención de fallos
      • Conoce el esfuerzo de implementación
      • Conoce el esfuerzo del Testing
    • Evalúa fallos conocidos
      • Los desarrolles pueden continuar con la tasa de fallos encontrados en su haber?
      • Los Testers están encontrando los fallos más importantes?
      • La Gerencia está tomando buenas decisiones al respecto de los fallos que son encontrados?
      • Los fallos son utilizados para mejorar el proceso de desarrollo en general?
    • Evalúa los Requerimientos
      • Asegúrate de que todo el mundo entiende que estamos construyendo, por que y para que
      • Convierte los requerimientos implícitos en explícitos
      • Permite y promueve que los interesados vean el software periódicamente durante la fase de desarrollo
      • Escucha cuidadosamente y cuestiona las presunciones
    • Los defectos ponen a prueba las aplicaciones
      • Define código estándar
      • Define buenas prácticas de codificación
      • Mantenga las revisiones para ver que las codificaciones siguen los estándares
      • Toma ventaja de las revisiones de código como una oportunidad para compartir sugerencias y técnicas para las pruebas de error en el entorno de desarrollo
    • No permita que un problema se transforme en el problema de alguien más
        • Mantén una cultura donde la idea viva sea la de la RESPONSABILIDAD
        • No dejes de hacer hoy lo que podrías delegar en otra persona del equipo
        • Si un problema tuyo no se convierte en un problema de alguien más, entonces no es un problema
        • Ten en cuenta que el Software es quien sufrirá los resultados
    • Detecta los fallos en forma temprana
      • Como están definidas las Pruebas de Unidad?
      • Quien es el responsable de las Pruebas de Unidad?
      • Se puede testear algunas partes del sistema en forma aislada?
      • El esfuerzo de las Pruebas Unitarias está mejorando?
      • Cuales herramientas está utilizando para ayudar al proceso de Pruebas Unitarias?
      • El sistema es construido e integrado diariamente?
    • Planifica el tiempo para el Desarrollo, Testing y Correcciones de Defectos
      • Incluye en la planificación de los desarrolladores el tiempo suficiente para realizar algunos tipos de pruebas durante la construcción de primera mano
      • Considera en la planificación de los desarrolladores el tiempo suficiente y necesario para la corrección de los defectos detectados durante sus propias pruebas
      • Presta atención a las alarmas de los desarrolladores al respecto de las presiones de tiempo que hacen que se salten etapas
    • Invierte en mayor medida en la prevención de los defectos
      • No planifiques obtener mejora de calidad solo promoviendo la mejora del esfuerzo del “Testing Independiente” (grupo separado de los Desarrolladores)
    • Luego el artículo muestra la conversación entre dos personajes que podrían ser dos actores típicos de una Software Factory, un Responsable de Pruebas y Calidad y una Gerente de Área.
      La conversación muestra con gran simpleza la evolución de la gráfica y va entrelazando los conceptos que indefectiblemente llevan a La Calidad o a la No Calidad del software.

      Queda claro el concepto de que la Calidad Percibida es inversamente proporcional a la cantidad de defectos que se dejan pasar a los entornos operativos del cliente. Es decir que a más defectos del lado del cliente, menos calidad percibida y viceversa.
      De la misma manera a mayor cantidad de defectos detectados en las pruebas de sistemas, el número de defectos posibles a ser pasados al entorno operativo del cliente es menor.
      Esto quiere decir que hay etapas que deben ser respetadas a raja tabla aún a disconformidad de alguna de las partes, como una Líder de Proyecto, Responsable de Despliegue, Comercial o inclusive La Gerencia. Una de esas etapas son las Pruebas de Sistemas. Este es el entorno operativo dentro de la organización, más cercano al entorno operativo del cliente y los resultados generados en este ambiente, se deben tomar indefectiblemente como referente directo de los resultados que se replicarán en los ambientes productivos y su consiguiente Calidad Percibida.

      Aún cuando se incremente el Esfuerzo Independiente que suponen las pruebas de sistemas, hay otras etapas previas conocidas como el “Esfuerzo del Testing del Desarrollo”, que no deben ser omitidas, pues aún estando más lejos del entorno operativo de producción, son la garantía inicial de que el producto construido cumplirá con los requisitos. Directamente estas garantías iniciales impactan en los costos de la organización.

      Leer entrada completa | Make a Comment ( Comentarios desactivados en A mejor Testing, peor calidad de Software? )

      Por favor páseme esto al español

      Posted on 22 julio 2008. Filed under: Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo, Uncategorized | Etiquetas: |

      Como parte de nuestro trabajo, el equipo de Gestión de Proyectos envía cotidianamente “reportes diarios” a La Gerencia donde expresa su evolución en las actividades del día, las actividades planificadas y un resumen de problemas que cada uno pudo haber detectado y para lo que se necesita hacer algún tipo de enfoque.

      Lo cierto es que esta gestión puede ser un arma de doble filo si no se le da la utilidad adecuada y si no se modula correctamente la sintaxis del lenguaje utilizado. Normalmente nosotros utilizamos un lenguaje simple donde identificamos los siguientes elementos:

      sujeto + situación (deseada) + acción + calendario
      Con esta sencilla fórmula nos acoplamos a la teoría del PDCA y la podemos utilizar no solo para reportar la situación deseada sino que al factor “situación” se lo puede alterar para ingresar un valor “no deseado”.
      De este modo:
      sujeto + situación (no deseada) + acción + calendario
      puede ser utilizado para indicar un problema vigente o potencial.

      Para ejemplificar, quiero mostrar una situación real presentada en mis reportes diarios y como debí modificar el lenguaje para que finalmente se entendiera:

      Situación No Deseada:

      • Catálogo de casos y/o requisitos inexistente con las correspondientes derivaciones a Desarrollado.
        Esto implica que no hay visibilidad para todo el equipo de lo que se está trabajando en el momento. Intenté localizar la información a modo de “enterarme” vía emails del Arquitecto de Sistemas pero no encontré una referencia clara.
        Igualmente accedo a los Entregables plasmados en la “herramienta de incidentes”, pero allí hay cientos de incidentes y al menos a mi no me queda del todo claro que revisar en algún orden específico. Imagino que puedo darle prioridad de revisión a las fechas de entregables vencidas.

      a las pocas horas vino la respuesta:

      Javier,
      por favor páseme esto al español.

      Gracias.

      a los minutos la contra respuesta:

      Estimado,

      es un poco complicado y requiere de mucho esfuerzo comunicacional estar al tanto de que hay pendiente, con que prioridad y con que fechas de fin esperada. Es difícil obtener con anticipación, información de los pasajes a Testing.
      Creo que puedes darte cuenta por los últimos emails que envié al Arquitecto de Sistemas informando los incidentes existentes en mi Sprint de pruebas y solicitando fecha de entregables a Testing e incidentes que aún desconozco por que se dieron de alta recientemente. Los emails de esta naturaleza son bastante regulares.
      En el mismo sentido, la Responsable de Despligues me pregunta al respecto de que cosas hay en Testing y cuando finalizan, o el estado de un incidente en particular inclusive varios días después de haberse rechazado el mismo.
      La diferencia es que ella siempre pregunta verbalmente y en instancias tardías.
      Lo que quiero expresar es que los “bloques” no viajan con la claridad, visibilidad y simpleza que nos hace falta y que las idas y vueltas del mailing  complican mucho las gestiones tanto del Arquitecto de Sistemas como las mías. Siempre sugiero que se mire el Sprint de pruebas para tener más claro el paquete, pero imagino que es una complicación en la gestión individual del otro. Insisto en que debemos centralizar la gestión de alguna manera y con las premisas de claridad, visibilidad y simpleza.

      Espero haber sido más claro.

      Saludos.

      Entonces podrán ver que de dos maneras diferentes dije lo mismo, pero fue necesario ampliar aduciendo a los conceptos fundamentales del problema y nuestro método de comunicación sencilla no sirvió. En ocasiones simplemente por que no se quiere escuchar. Otras veces por que no se comprende el contexto operacional, y muchas veces por que no se acepta el problema.

      Leer entrada completa | Make a Comment ( Comentarios desactivados en Por favor páseme esto al español )

      CONSIDERACIONES DEL ARTE DE LA GUERRA EN LA ADMINISTRACIÓN DE PROYECTOS – PARTE 1– ESTIMACIONES ESTRATÉGICAS

      Posted on 18 julio 2008. Filed under: Uncategorized |

      INTRODUCCIÓN

      Sun Tzu fue un general chino que vivió alrededor del siglo V antes de Cristo. La colección de ensayos sobre el arte de la guerra atribuida a Sun Tzu es el tratado más antiguo que se conoce sobre el tema. A pesar de su antigüedad los consejos de Sun Tzu siguen manteniendo vigencia.

      Estos principios también aplican a la Administración de Proyectos y me referiré al texto haciendo adaptaciones para nuestra área de interés.  Mostraré tachado el texto original y subrayado la adaptación que hago del tema,  mis comentarios aparecerán en cursivas.

      ESTIMACIONES ESTRATÉGICAS

      La guerra El Proyecto es un asunto de importancia vital para el Estado la organización; un asunto de vida o muerte utilidad o pérdida  el camino hacia la supervivencia o la destrucción éxito o fracaso. Por lo tanto, es imperativo estudiarla profundamente.

      Hay que valorarla en términos de cinco factores fundamentales, y hacer comparaciones entre diversas condiciones de los bandos antagonistas, de cara a determinar el resultado de la contienda del proyecto.

      Estos factores son:

      1. Política

      2. Clima

      3. Terreno

      4. Comandante

      5. Doctrina

      1.- La política significa aquello que hace que el pueblo equipo del proyecto, esté en armonía con su gobernante Líder de proyecto, de modo que le siga donde sea, sin temer por sus vidas ni a correr cualquier peligro el fracaso del proyecto.

      2.- El clima significa la noche y el día, el frío y el calor, días despejados o lluviosos, y el cambio de las estaciones. (Circunstancias en que se da el proyecto)

      3.- El terreno implica las distancias, y hace referencia a dónde es fácil o difícil desplazarse, y si es campo abierto o lugares estrechos, y esto influencia las posibilidades de supervivencia éxito.

      4.- El comandante Líder de Proyecto ha de tener como cualidades:

      • Sabiduría

      • Sinceridad

      • Benevolencia

      • Coraje

      • Disciplina.

      5.- La doctrina Las reglas del equipo han de ser comprendidas como la organización del ejército equipo del proyecto, las graduaciones y rangos entre los oficiales miembros del equipo, la regulación de las rutas de suministros, y la provisión de material militar al ejército equipo del proyecto.

      Estos cinco factores fundamentales han de ser conocidos por cada general Líder de Proyecto. Aquel que los domina, vence tiene éxito en su proyecto; aquel que no, sale derrotado fracasa en su proyecto. Por lo tanto, al trazar los planes, han de compararse los siguientes siete factores, valorando cada uno con el mayor cuidado:

      1. ¿Qué dirigente Líder de Proyecto es más sabio y capaz?

      2. ¿Qué comandante Líder de Proyecto posee el mayor talento?

      3. ¿Qué ejército Equipo de proyecto obtiene ventajas de la naturaleza y el terreno medio ambiente del proyecto (también tenemos que considerar las habilidades, conocimientos y experiencia del equipo del proyecto)?

      4. ¿En qué ejército Equipo del Proyecto se observan mejor las regulaciones y las instrucciones?

      5. ¿Qué tropas son más fuertes Equipo de Proyecto ha demostrado resultados positivos?

      6. ¿Qué ejército Equipo de proyecto tiene oficiales y tropas Líderes y miembros del Equipo mejor entrenadas?

      7. ¿Qué ejército Equipo de proyecto administra recompensas y castigos de forma más justa?

      Mediante el estudio de estos siete factores, seré capaz de adivinar cual de los dos bandos saldrá victorioso y cual será derrotado si el Equipo del Proyecto resultará exitoso.

      El general Líder de Proyecto que siga mi consejo, es seguro que vencerá tendrá éxito en su proyecto. Ese general Líder de Proyecto ha de ser mantenido al mando. Aquel que ignore mi consejo, ciertamente será derrotado fracasará en su proyecto. Ese debe ser destituido reentrenado.

      Tras prestar atención a mi consejo y planes, el general Líder de Proyecto debe crear una situación que contribuya a su cumplimiento. Por situación quiero decir que debe tomar en consideración la situación del campo proyecto, y actuar de acuerdo con lo que le es ventajoso.

      El arte de la guerra La Administración de Proyectos se basa en el engaño la organización, así como en métodos  y técnicas.

      Por lo tanto, cuando es capaz de atacar, ha de aparentar incapacidad; cuando las tropas se mueven, aparentar inactividad. Si está cerca del enemigo, ha de hacerle creer que está lejos; si está lejos, aparentar que se está cerca. Poner cebos para atraer al enemigo. Golpear al enemigo cuando está desordenado. Prepararse contra él cuando está seguro en todas partes. Evitarle durante un tiempo cuando es más fuerte. Si tu oponente tiene un temperamento colérico, intenta irritarle. Si es arrogante, trata de fomentar su egotismo. Si las tropas enemigas se hallan bien preparadas tras una reorganización, intenta desordenarlas. Si están unidas, siembra la disensión entre sus filas. Ataca al enemigo cuando no está preparado, y aparece cuando no te espera. Estas son las claves de la victoria para el estratega. (Esté párrafo es difícil de adaptar, ya que nuestro cliente NO ES NUESTRO ENEMIGO – nuestro enemigo debe ser el fracaso del proyecto)

      Ahora, si las estimaciones realizadas antes de la batalla del proyecto indican victoria éxito, es porque los cálculos cuidadosamente realizados muestran que tus condiciones son más favorables que las condiciones del enemigo; si indican derrota fracaso, es porque muestran que las condiciones favorables para la batalla el proyecto son menores. Con una evaluación cuidadosa, uno puede vencer tener éxito; sin ella, no puede. Muchas menos oportunidades de victoria éxito, tendrá aquel que no realiza cálculos en absoluto.

      Mediante todo esto, uno puede adivinar el resultado final de la batalla del proyecto.

      Publicado en www.zeusconsult.com.mx

      Leer entrada completa | Make a Comment ( 1 so far )

      “Scrum funciona con idiotas”

      Posted on 17 julio 2008. Filed under: Ingeniería del Software, Uncategorized | Etiquetas: , , |

      Tuve la suerte de dar con un Podcast en google sobre Scrum y resumir de una manera maravillosa lo que significa Scrum. Del mismo modo avalar lo bueno de nuestro modo de trabajo y lo malo que hay que corregir. En esta exposición tuve la oportunidad de escuchar a nada más y nada menos que a Ken Schawaber, quien fuera co-desarrollador de Scrum y creador de Agille Alliance, al igual que el mentor de los Manifiestos Agile.

      Básicamente explica por que Scrum es ideal para cualquier grupo de personas que trabajan en construcción de software, independientemente de la envergadura y complejidad de los proyectos que allí se ideen. Menciona a empresas de la talla de Fujitsu, Toyota, 3M y Xerox e indica el éxito magnánimo que tuvo Scrum en estas.

      Explica como trabajan en forma sinérgica todas las áreas de estas empresas independientemente de su actividad y como Scrum da gran soporte a ellas al proporcionar visibilidad de los proyectos y de la productividad real.

      Me gustó mucho el énfasis que se puso en la necesidad de utilizar solo lo necesario para construir el producto sin intermediaciones de herramientas sofisticadas, sin presentaciones de informes, reportes ni otros elementos que nada tienen que ver con la generación de los productos de software.

      Ken Schawaber explica el concepto de Time Box y como los equipos pueden ajustarse al concepto solo conociendo las mejores prácticas de la Ingeniería del Sofware, las cuales él alega, están resumidas en Scrum. También nos dice que la ingeniería del Software debe utilizar la herramienta principal de los Ingenieros de Software, que es nada más y nada menos que la inteligencia aplicada a brindar soluciones potentes, prácticas e innovadoras y no a la mera administración de proyectos, lo cual es la actual orientación de las metodologías Waterfall como RUP.

      Scrum no es una metodología, nos dice Ken Schawaber mientras indica que una metodología típica nos puede indicar quien, donde, como y cuando ejecutar algo en particular. Sin embargo Scrum por su simpleza es algo así como un “baby process” y ayuda a los Ingenieros a construir software cohesivo mientras se pueden apoyar en la administración con Scrum, de modo tal que cada uno de los involucrados en los proyectos sabe en que lugar se encuentra cada iteración del proyecto en todo el ciclo de vida.

      Los invito a escuchar esta interesante exposición: Ken Schawaber nos dice por que Scrum funciona inclusive con idiotas.

      Leer entrada completa | Make a Comment ( 1 so far )

      ¿”Pay per Defect” o elevar la conciencia creativa del acto verificador?

      Posted on 16 julio 2008. Filed under: Testing, Uncategorized | Etiquetas: , , |

      Un amigo posteó:

      ¿Como creéis que se debe incentivar a los equipos de calidad? ¿Es posible incentivar por defecto encontrado o es contraproducente?

      Imaginemos una compañía que decide incentivar por objetivos, e incentiva el equipo de desarrollo por funcionalidad implementada en el menor tiempo. ¿Como incentivamos al Tester? o dicho de otra manera como sabemos quién realiza mejor labor de verificación?

      Una respuesta de otro amigo:

      Pues yo creo que incentivar la localización de errores está bien.
      Eso sí, debe haber un “juez” que decida si cada caso es digno de contabilizar o no, es decir, que tome la decisión en los casos dudosos (“es que no estaba en los requisitos escritos” … “sí, pero es algo ‘obvio'” … y cosas de ese estilo). Ah! Y añado otra cosa : igual que se incentiva la localización de errores en el testeo creo que se debería “desincentivar” cuando un Cliente localiza el error una vez lanzada la versión.
      Luego se hacen las cuentas de la vieja y se saca balance.
      Ya verías la de errores que se encuentran !!! jejeje

      El aporte de uno más:

      ¿Qué tal un esquema intermedio?

      1) Incentivar a los desarrolladores con relación inversa al número de defectos que “les” encuentren los Testers.
      2) Incentivar a los Testers con relación al número de objetos/unidades/loquesea que pasen a producción validados
      3) E incentivarlos a todos con la “velocidad” del proceso completo, y con relación inversa a los defectos encontrados en producción.

      La “fórmula” no sería sencilla, pero puede que se lograse un resultado adecuado. ¡O que se lograse confundirles a todos!

      ¡¡¡¡me encanta este aporte!!!!

      Pero mi opinión fue la siguiente:

      Me resulta un poco extraña la cuestión de tener que incentivar a un Tester o grupos de Testers por tener que hacer su trabajo bien. Igual para los desarrolladores o cualquier otra persona que cumpla un rol específico dentro de la cadena productiva de software.
      En primer lugar considero que un plan de verificaciones y/o validaciones no puede quedar librado a la buena de un Tester, sino que debe guiar a cada uno de los involucrados en el proceso hacia los resultados esperados, también sus controles y gestiones.

      Si se considera la existencia de Testers en un equipo de producción de software, no debe ser sin la existencia de un responsable QA y la carga de gestión recae sobre los hombros de tal o tales personas. Lo que se puede hacer es “elevar la conciencia creativa del acto verificador” agregando capacitaciones especializadas en herramientas, conceptos avanzados, UML, patrones de calidad y demás elementos que existen para sumir al equipo de calidad en un estándar que desde el llano y como punto de partida sea muy alto.
      Podría agregar que es bueno tener métricas de cantidades de defectos detectados por Tester pero no podríamos dejar de mirar que tipo de defectos detecta cada uno de ellos y como es el impacto de cada uno de esos defectos detectados en los proyectos. Esto serviría para que en caso de necesitar dividir el equipo de Testing, al “mejor Tester” se le asignaría una especie de “jefatura” sobre otros que no tienen el mismo rendimiento.

      Dependiendo del entorno de trabajo, la suspicacia de las personas, los objetivos personales de cada integrante del equipo de Testers entre otros elementos RRHH, es bueno aplicar criterios de competencias operativas. Pero en otros casos no. Equipos enteros podrían desintegrarse por generarse ciertas incomodidades. No quiero ni hablar de como impactaría sobre nuestros productos.

      Entonces, pagar por defectos detectados vale para equipos de venta. Ya todos los defectos del producto fueron eliminados o se presumen eliminados y el producto de alta calidad. Ahora a generar retorno de la inversión.

      Me gusta mucho la idea de incentivar, pero sin generar competencias sino ambientes colaborativos (inclusive para eso estamos aquí nosotros) y cada uno en su puesto de trabajo debe elevar al máximo su conciencia de responsabilidad.
      Los Testers suelen encontrar fallos de severidad Invalidante o Graves a penas inician el Testing. No es mérito del Tester sino de la incompetencia de alguien en fases anteriores. No señalo a nadie, pero desde el Tester para atrás, hay muchas responsabilidades intrínsecas.

      Es cierto también que al principio el Tester se haría de una muy buena suma de dinero extra por la cantidad de detección de fallos y conforme avanzan los ciclos, deberá devolver dinero y hasta poner de su bolsillo por que no encontrará fallos que se sabe por métricas, están allí.

      Cierta oportunidad siendo Líder de Testing al finalizar uno de los proyectos postulados para certificación CMMI-4, mi equipo detectó grandes cantidades de fallos en los productos solo en los primeros ciclos, cuando había planificados 12 ciclos de pruebas. Conforme se comenzaron a resolver los fallos, previo a los ciclos subsiguientes, nuestra tasa de detección cayó significativamente para el resto de los ciclos (considerar PARETO).
      Esto me llevo a analizar la situación, a modificar definitivamente el modo en que manejamos los ciclos. Finalizado el proyecto que menciono, invité a mi equipo a un almuerzo y por supuesto al equipo de Desarrollo. Allí pude explicar lo que habíamos conseguido trabajando en equipo y como unos sin otros no pueden evidenciar su actividad hecha con responsabilidad.
      Gracias a esto pudimos mejorar nuestro proceso en forma significativa.
      Creo en definitiva, que brindar las herramientas adecuadas, la capacitación necesaria y sostener un ambiente colaborativo y ameno, son los mejores incentivos.

      Leer entrada completa | Make a Comment ( Comentarios desactivados en ¿”Pay per Defect” o elevar la conciencia creativa del acto verificador? )

      La parte dificil de construir sofware es la especificación

      Posted on 1 mayo 2008. Filed under: Uncategorized |

      La parte difícil de construir software es la
      especificación, el diseño y la verificación de esa
      trama conceptual, no la tarea de representarla y
      testear la representación.

      Esta elegante definición la pude ver en apuntes que suelo revisar sobre los distintos aspectos de la Ingeniería del Software y me dió que pensar.

      En la mayoría de las oportunidades en que hemos tenido reuniones de equipo para hablar de nuestras fortalezas y debilidades en base al éxito o al fracaso de algún proyecto reciente, se nos hizo notar que nuestro equipo debe preponderar en la intensión de hacer ingeniería.
      Son incontable las veces en que se describió mentalmente el proceso existente, en esas reuniones. Pero en cada una de las oportunidades en que se presenta

      Leer entrada completa | Make a Comment ( Comentarios desactivados en La parte dificil de construir sofware es la especificación )

      Diseño de Interfaces de Usuario – Principios, Prototipos y Heurísticas para Evaluación

      Posted on 2 abril 2008. Filed under: Uncategorized |

       

      1. Conceptos Generales

      2. Principios para el Diseño de Interfaces de Usuario

      3. Utilización de Prototipos en la Implementación de IU

      4. Heurísticas para la Evaluación de IU

      5. Caso Práctico

      6. Conclusiones

      7. Bibliografía

      Abstract

      El diseño de interfaces de usuario es una tarea que ha adquirido relevancia en el desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al éxito o al fracaso. Los principios que se presentan son de utilidad para creación de interfaces funcionales y de fácil operación. A pesar de no ser capaces de resolver todos los aspectos propios del contexto con el que se esté trabajando, pueden ser combinados con la prototipación y la aplicación de heurísticas de evaluación para facilitar el proceso de diseño. El presente artículo se centra en los componentes de software de las interfaces de usuario, quedando fuera del alcance de mismo otros aspectos, como hardware y documentación. Lo anteriormente expuesto se complementa con un caso práctico de diseño de interfaces de usuario, producto de realizar la actividad de “Definición de Interfaces de Usuario” (EFS 4) de la metodología Métrica Versión 2.

      Key words: evaluation, heuristics, principles, prototypes, user interfaces.

      1. Conceptos Generales

      La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software.

      Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a culparse a sí mismo por no saber usar el objeto.

      Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario.

      Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseñador (analogía de la construcción de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a través de su experiencia.

      El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interacción con las computadoras, de ahí su importancia.

      Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que éste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo, ya sea realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo.

      Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo típico es la metáfora del escritorio, común a la mayoría de las interfaces gráficas actuales.

      Modelo del diseñador: El diseñador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para diseñar un producto de software. Es un intermediario entre ambos.

      El modelo del diseñador describe los objetos que utiliza el usuario, su presentación al mismo y las técnicas de interacción para su manipulación. Consta de tres partes: presentación, interacción y relaciones entre los objetos (Figura 1).

      La presentación es lo que primero capta la atención del usuario, pero más tarde pasa a un segundo plano, y adquiere más importancia la interacción con el producto para poder satisfacer sus expectativas. La presentación no es lo más relevante y un abuso en la misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario.

      La segunda parte del modelo define las técnicas de interacción del usuario, a través de diversos dispositivos.

      La tercera es la más importante, y es donde el diseñador determina la metáfora adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba. Una vez definida la metáfora y los objetos del interfaz, los aspectos visuales saldrán de una manera lógica y fácil.

      clip_image001

      clip_image002

      Figura 1. Representación del modelo del diseñador: el look-and-feel iceberg, de IBM (1992)

      Estos modelos deben estar claros para los participantes en el desarrollo de un producto, de forma que se consiga una interfaz atractiva y a la vez efectiva para el trabajo con el programa.

      Una interfaz no es simplemente una cara bonita; esto puede impresionar a primera vista pero decepcionar a la larga. Lo importante es que el programa se adapte bien al modelo del usuario, cosa que se puede comprobar utilizando el programa más allá de la primera impresión.

      Modelo del programador: Es el más fácil de visualizar, al poderse especificar formalmente. Está constituido por los objetos que manipula el programador, distintos de los que trata el usuario (ejemplo: el programador llama base de datos a lo que el usuario podría llamar agenda). Estos objetos deben esconderse del usuario.

      Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema operativo, las herramientas de desarrollo y especificaciones. Sin embargo, esto no significa necesariamente que tenga la habilidad de proporcionar al usuario los modelos y metáforas más adecuadas. Muchos no consideran el modelo del usuario del programa, y sí sus propias expectativas acerca de cómo trabajar con la computadora.

      2. Principios para el Diseño de Interfaces de Usuario

      Existen principios relevantes para el diseño e implementación de IU, ya sea para las IU gráficas, como para la Web.

      Anticipación

      Las aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la información, recopilarla o invocar las herramientas que va a utilizar.

      clip_image004

      En la Figura 2 se ilustra como el procesador de texto se anticipa a las necesidades del usuario, proporcionando las características del texto seleccionado -fuente, tamaño, alineación, etc.- permitiendo que el usuario pueda modificarlas ágilmente.

      Autonomía

      La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la aplicación. Sin embargo, está comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable pero no azaroso.

      clip_image006

      En la Figura 3 se visualiza un diseño incorrecto de interfaz de usuario. La cantidad de opciones propuestas propone un grado de complejidad que no permite que el usuario pueda aprender a utilizar el sistema en forma progresiva.

      Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a los usuarios alertas e informados. No puede existir autonomía en ausencia de control, y el control no puede ser ejercido sin información suficiente. Además, se debe mantener información del estado del sistema en ubicaciones fáciles de visualizar.

      clip_image008

      En la Figura 4 se ejemplifica una incorrecta disposición de componentes en la IU. El reloj no debe ser incorporado en el menú del sistema ya que aporta confusión al usuario. Para mantenerlo informado sería mas adecuado colocarlo en la barra de estado del sistema.

      Percepción del Color

      clip_image010Aunque se utilicen convenciones de color en la IU, se deberían usar otros mecanismos secundarios para proveer la información a aquellos usuarios con problemas en la visualización de colores

      En la Figura 5 se representa un mecanismo secundario muy utilizado para ejecución de comandos: los comandos abreviados (shortcut-keys). Sin embargo la aplicación presenta un problema de inconsistencia ya que define combinaciones de teclas que difieren a lo esperado por el usuario, por ejemplo Alt+< en lugar de Alt+B.

      Valores por Defecto

      No se debe utilizar la palabra “Defecto” en una aplicación o servicio. Puede ser reemplazada por “Estándar” o “Definida por el Usuario”, “Restaurar Valores Iniciales” o algún otro término especifico que describa lo que está sucediendo. Los valores por defecto deberían ser opciones inteligentes y sensatas. Además, los mismos tienen que ser fáciles de modificar.

      Consistencia

      Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes aspectos que están catalogados en niveles. Se realiza un ordenamiento de mayor a menor consistencia:

      1. Interpretación del comportamiento del usuario: la IU debe comprender el significado que le atribuye un usuario a cada requerimiento. Ejemplo: mantener el significado de las los comandos abreviados (shortcut-keys) definidos por el usuario.

      2. Estructuras invisibles: se requiere una definición clara de las mismas, ya que sino el usuario nunca podría llegar a descubrir su uso. Ejemplo: la ampliación de ventanas mediante la extensión de sus bordes.

      3. Pequeñas estructuras visibles: se puede establecer un conjunto de objetos visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo en la ejecución de tareas específicas. Ejemplo: ícono y/o botón para impresión.

      4. Una sola aplicación o servicio: la IU permite visualizar a la aplicación o servicio utilizado como un componente único. Ejemplo: La IU despliega un único menú, pudiendo además acceder al mismo mediante comandos abreviados.

      5. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicación o servicio utilizado como un conjunto de componentes. Ejemplo: La IU se presenta como un conjunto de barras de comandos desplegadas en diferentes lugares de la pantalla, pudiendo ser desactivadas en forma independiente.

      6. Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente de trabajo. Ejemplo: La IU utiliza objetos de control como menúes, botones de comandos de manera análoga a otras IU que se usen en el ambiente de trabajo.

      7. Consistencia de la plataforma: La IU es concordante con la plataforma. Ejemplo: La IU tiene un esquema basado en ventanas, el cual es acorde al manejo del sistema operativo Windows.

      clip_image013

      En la Figura 6 puede observarse la mejora en la consistencia de las pequeñas estructuras visibles (3.) para los sistemas gráficos basados en ventanas. La inclusión de la opción X para cerrar la ventana –operación comunmente utilizada en estas aplicaciones- simplifica la operatividad del mismo.

      La inconsistencia en el comportamiento de componentes de la IU debe ser fácil de visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos deben ser consistentes con su comportamiento. Si dos objetos actúan en forma diferente, deben lucir diferentes. La única forma de verificar si la IU satisface las expectativas del usuario es mediante testeo.

      Eficiencia del Usuario

      Se debe considerar la productividad del usuario antes que la productividad de la máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado, estas pérdidas de tiempo se pueden convertir en pérdidas económicas para la organización. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Los menúes y etiquetas de botones deberían tener las palabras claves del proceso.

      clip_image015

      En la Figura 7 se demuestra como una incorrecta definición de las palabras clave de las etiquetas de los botones de comando puede confundir al usuario. Los botones OK y Apply aparentan realizar el mismo proceso. Esto puede solucionarse suprimiendo uno de ellos si realizan la misma tarea o etiquetándolos con los nombres de los procesos específicos que ejecutan.

      Ley de Fitt

      El tiempo para alcanzar un objetivo es una función de la distancia y tamaño del objetivo. Es por ello, que es conveniente usar objetos grandes para las funciones importantes.

      clip_image017

      En la Figura 8 se puede apreciar la relación entre los elementos de diseño de pantalla y su percepción visual. El número de elementos visuales que perciben son: en el caso a) 1 (el fondo); en b) 3 (la línea, lo que está encima y lo que está debajo); en c) son 5 (el espacio fuera del recuadro, el recuadro, la línea y el espacio encima y debajo de ésta); finalmente, en d) el número se eleva a 35, siguiendo el mismo criterio. Conclusión: cada elemento nuevo que se añade influye más de lo que se piensa en el usuario.

      Interfaces Explorables

      Siempre que sea posible se debe permitir que el usuario pueda salir ágilmente de la IU, dejando una marca del estado de avance de su trabajo, para que pueda continuarlo en otra oportunidad.

      Para aquellos usuarios que sean noveles en el uso de la aplicación, se deberá proveer de guías para realizar tareas que no sean habituales.

      Es conveniente que el usuario pueda incorporar elementos visuales estables que permitan, no solamente un desplazamiento rápido a ciertos puntos del trabajo que esté realizando, sino también un sentido de “casa” o punto de partida.

      La IU debe poder realizar la inversa de cualquier acción que pueda llegar a ser de riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores.

      Siempre se debe contar con un comando “Deshacer”. Este suprimirá la necesidad de tener que contar con diálogos de confirmación para cada acción que realice en sistema.

      El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello que la IU debe tener un objeto fácil de accionar con el cual poder finalizar la aplicación.

      Objetos de Interfaz Humana

      Los objetos de interfaz humana no son necesariamente los objetos que se encuentran en los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o percibidos de alguna forma. Además, estos objetos deberían ser entendibles, consistentes y estables.

      clip_image020

      En la Figura 9 se presentan barras de controles que simplifican la operación de un sistema. A través de las ilustraciones que poseen los mismos, el usuario puede aprender fácilmente su uso. Si se mantienen para estos botones las mismas asignaciones de procesos en diferentes sistemas, la comprensión del funcionamiento de los mismos se hace mas sencilla.

      Uso de Metáforas

      Las buenas metáforas crean figuras mentales fáciles de recordar. La IU puede contener objetos asociados al modelo conceptual en forma visual, con sonido u otra característica perceptible por el usuario que ayude a simplificar el uso del sistema.

      clip_image023

      En la Figura 10 se compara la aplicación de metáforas en el desarrollo de una IU. En el primer caso, se utiliza incorrectamente la metáfora de una cámara de video para representar el procesamiento de un documento por una impresora. Se puede observar que el botón << carece de sentido, ya que no se puede volver atrás un trabajo que ya ha sido impreso. En el segundo caso, la metáfora de la agenda es utilizada correctamente para la implementación de una agenda electrónica.

      Curva de Aprendizaje

      El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal es que la curva de aprendizaje sea nula, y que el usuario principiante pueda alcanzar el dominio total de la aplicación sin esfuerzo.

      Reducción de Latencia

      Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia en segundo plano (background). Las técnicas de trabajo multitarea posibilitan el trabajo ininterrumpido del usuario, realizando las tareas de transmisión y computación de datos en segundo plano.

      Protección del Trabajo

      Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su parte, problemas de transmisión de datos, de energía, o alguna otra razón inevitable.

      Auditoría del Sistema

      La mayoría de los navegadores de Internet (browsers), no mantienen información acerca de la situación del usuario en el entorno, pero para cualquier aplicación es conveniente conocer un conjunto de características tales como: hora de acceso al sistema, ubicación del usuario en el sistema y lugares a los que ha accedido, entre otros. Además, el usuario debería poder salir del sistema y al volver a ingresar continuar trabajando en lugar dónde había dejado.

      Legibilidad

      Para que la IU favorezca la usabilidad del sistema de software, la información que se exhiba en ella debe ser fácil de ubicar y leer. Para lograr obtener este resultado se deben tener en cuenta algunas como: el texto que aparezca en la IU debería tener un alto contraste, se debe utilizar combinaciones de colores como el texto en negro sobre fondo blanco o amarillo suave. El tamaño de las fuentes tiene que ser lo suficientemente grande como para poder ser leído en monitores estándar. Es importante hacer clara la presentación visual (colocación/agrupación de objetos, evitar la presentación de excesiva información.

      clip_image025

      En la Figura 11 se describe una comparación de disposición de los objetos en pantalla. La figura de la izquierda, combina una disposición asimétrica de la información con un conjunto de colores que no facilita la lectura. La figura de la derecha realiza la presentación de la información utilizando una gama de colores homogénea y una alineación del texto que favorece a la legibilidad del mismo.

      Interfaces Visibles

      El uso de Internet, ha favorecido la implementación de interfaces invisibles. Esto significa que el usuario siempre ve una página específica, pero nunca puede conocer la totalidad del espacio de páginas de Internet. La navegación en las aplicaciones debe ser reducida a la mínima expresión. El usuario debe sentir que se mantiene en un único lugar y que el que va variando es su trabajo. Esto no solamente elimina la necesidad de mantener mapas u otras ayudas de navegación, sino que además brindan al usuario una sensación de autonomía.

      3. Utilización de Prototipos en la Implementación de IU

      Niveles de Prototipado

      Se puede hacer una clasificación de los principales tipos de prototipos, variando su grado de complejidad, de acuerdo a las características que consideren y a su operabilidad para realizar simulaciones.

      § Prototipos Estáticos: son aquellos que no permiten la alteración de sus componentes, pero sirven para identificar y resolver problemas de diseño. En esta categoría se incluyen las presentaciones sobre reproductores, papel u otro medio de visualización.

      § Prototipos Dinámicos: permiten la evaluación de un modelo del sistema sobre una estación de trabajo o una terminal. Estos prototipos involucran aspectos de diseño mas detallados que los prototipos estáticos, incluyendo la validación del diseño del sistema en términos de requerimientos no funcionales, por ejemplo de performance.

      § Prototipos Robustos: deben ser relativamente completos en la simulación de las características dinámicas de la interfaz (presentación de mensajes de error, entrada y edición de datos, etc.). Esta categoría puede ser utilizada para validar los objetivos de diseño.

      El nivel de sofisticación del prototipo debería incrementarse a lo largo del proceso de diseño de interfaces de usuario. La información recolectada durante las tareas de análisis del sistema y la especificación de los requisitos del usuario constituyen los datos clave para el proceso de prototipación.

      4. Heurísticas para la Evaluación de IU

      Las heurísticas ayudan a poder analizar las IU y localizar problemas que afecten la utilización de las mismas.

      Algunas pautas para evaluar una IU son:

      § Visibilidad del estado del sistema

      § Semejanza del sistema al mundo real

      § Control y libertad por parte del usuario

      § Consistencia y estandarización

      § Prevención de Errores

      § Reconocimiento de acciones y opciones

      § Flexibilidad y eficiencia en el uso

      § Estética y diseño minimalista

      § Reconocimiento de errores, diagnóstico y recuperación

      § Ayuda y documentación

      Para establecer medidas que indiquen la severidad de los problemas en el uso de las interfaces, se deben conocer los factores que determinan el grado de un problema:

      § La frecuencia de ocurrencia.

      § El impacto que causa la ocurrencia del problema.

      § La persistencia del problema.

      § El impacto en el mercado.

      Medidas de severidad de un problema en la IU:

      0: No puede llegar a considerarse un problema.

      1: Es un problema “cosmético” que no necesita ser corregido a menos que se disponga tiempo extra en el proyecto.

      2: Es un problema menor y su corrección puede tener baja prioridad.

      3: Es un problema mayor y su corrección debería tener alta prioridad.

      4: Es una catástrofe para la utilización de la aplicación y es imperativo corregir el error.

      Para la evaluación de los problemas en las IU es conveniente que contar con mas de un evaluador; de esta forma los resultados son mas confiables.

      5. Caso Práctico

      Para complementar los aspectos teóricos, se realiza una ejemplificación de una de las actividades propuestas por la metodología Métrica Versión 2 para el diseño de interfaces de usuario.

      La metodología Métrica Versión 2 contempla la simulación de diálogos de pantalla para la actividad EFS 4 “Definir Interfaces de Usuario”, a partir de las principales funciones interactivas, eventos y consultas identificados en la fase de análisis.

      Siguiendo la metodología, la tarea 4.1 prescribe las siguientes acciones:

      § Definir los formatos individuales de las pantallas utilizadas.

      § Describir de modo detallado los diálogos entre pantallas y el encadenamiento entre las mismas.

      § Determinar los diálogos que se consideran críticos.

      § Realizar una maqueta dinámica.

      Asimismo, la tarea 4.2 indica:

      § Obtener una definición de los formatos de los informes generados.

      § Definir los formularios utilizados (si fuera necesario).

      § Verificar si los diseños realizados están de acuerdo con los estándares de la unidad y obtener la validación y conformidad de los usuarios.

      Para acotar el presente trabajo, se realiza un desarrollo del primer punto de la tarea 4.1 propuesta en la metodología, exponiendo algunos de los productos resultantes.

      § Tarea 4.1.1. Definir los formatos individuales de las pantallas utilizadas.

      Caso Práctico: Construcción de un sistema de Gestión de Alquiler de Automóviles (AGA 2000).

      Requisitos de interfaces de usuario:

      § La interfaz con el usuario se hará mediante pantallas con menús desplegables.

      Se describe a modo de ejemplo, el formato de la pantalla principal del sistema AGA 2000 y sus componentes (Figura 12).

      Descripción de componentes

      Barra de Título: se utiliza para desplegar el título de la pantalla desplegada. Si la ventana está activa, la barra de titulo tendrá un color diferente al resto de las ventanas desplegadas.

      Menú Principal: contiene un conjunto de botones que permiten desplegar la totalidad de las pantallas del sistema.

      Usuario del Sistema: indica el nombre del usuario que está utilizando el sistema, el cual ha sido previamente ingresado con una contraseña como requisito para acceder al sistema.

      Reloj del Sistema: indica la hora actual del sistema.

      Area de Trabajo: es el lugar donde se despliegan las pantallas que son activadas a través del Menú Principal.

      Maximizar/Restaurar Ventana: botón que se utiliza para ampliar o reducir el tamaño de la pantalla.

      Minimizar Ventana: control que se utiliza para quitar de primer plano de trabajo una ventana, sin cerrarla.

      Cerrar Ventana: control que se usa para cerrar una ventana.

      clip_image026

      Puede utilizarse para la descripción de las pantallas, las operaciones que se especifican en los diagramas de la Historia de Vida de las Entidades del sistema anteriormente presentado (AGA 2000). Cada operación representa una pantalla diferente, por lo que se expondrán algunas de ellas (Figuras 13 y 14) con el objeto de ilustrar el diseño de las mismas.

      Opciones de Menú

      Operaciones

      Avería

      Alta avería, Actualización período Avería, Borrado de avería.

      Cliente

      Alta cliente, Modificar dirección, Emisión tarjeta, Cancelación tarjeta, Renovación tarjeta.

      Entrega

      Alta entrega, Borrar Entrega

      Entrega/Vehículo

      Alta entrega / vehículo, Borrar entrega / vehículo

      Fabricante

      Alta fabricante, Actualizar datos

      Factura Fabricante

      Alta factura fabricante, Borrar factura fabricante

      Modelo

      Alta modelo, Borrar modelo

      Modelo/Pedido

      Alta modelo/pedido, Borrar modelo/pedido

      Oficina

      Alta oficina, Borrar oficina

      Pago Cliente

      Alta pago cliente, Borrar pago cliente

      Pago Fabricante

      Alta pago fabricante, Borrar pago fabricante

      Pedido

      Alta pedido, Borrar pedido

      Reserva vehículo

      Alta reserva vehículo, Borrar reserva vehículo

      Seguro

      Alta seguro, Modificar porcentaje seguro, Borrar seguro

      Ejemplos de pantalla para la operación de Alta de Fabricante y Alta de Pedidos

      clip_image027

      El encadenamiento de las pantallas está determinado a partir de la pantalla principal del sistema, permitiendo desplegar cualquiera de las pantallas utilizadas para las operaciones anteriormente descriptas. Dichas pantallas pueden ser activadas o cerradas en forma independiente.

      6. Conclusiones

      Las integración de los principios, prototipos y heurísticas de evaluación durante el proceso de diseño de IU permite la creación de interfaces que satisfacen las expectativas del Modelo del Usuario, el cual es el punto de vista mas importante para garantizar la aceptación de un sistema.

      Entre las características que contribuyen a construir una interfaz sencilla de utilizar, sobresale la utilización de metáforas como ayuda para simplificar al usuario en la operación del sistema.

      La prototipación es un proceso de uso frecuente durante el diseño de IU. A través diferentes niveles evolutivos de prototipos se pueden lograr simulaciones del sistema a construir con un alto grado de detalle, pudiendo validar los requisitos de diseño que se hayan propuesto.

      Las heurísticas de evaluación de IU permiten identificar problemas que interfieran en la operación del sistema, resultando de ellas un diagnóstico que puede ser utilizado como retroalimentación para una nueva versión optimizada de la interfaz de usuario.

      7. Bibliografía

      § Guía de Estudio del Módulo III “Metodología de Construcción de Sistemas de Software” de la Maestría en Ingeniería del Software, Escuela de Posgrado, Instituto Tecnológico de Buenos Aires.

      § Molich, R., y Nielsen, J.,“Improving a human computer dialogue”, Communications of the ACM 33, 3 (March), pp 338-348, 1990.

      § Molich, R., y Nielsen, J., “Heuristic evaluation of user interfaces”, Proceedings of the ACM CHI´90 Conference, pp. 249-256, 1990.

      § Molich, R., y Nielsen, J., “Enhancing the explanatory power of usability heuristics”, Proceedings of the ACM CHI´94 Conference, pp. 152-158, 1994.

      § Durrett, H.J., “General Approach to Rapid Prototyping”,

      http://swt.edu/~hd01/4326/PROTOTYP.htm, 1997.

      8. Datos del Autor

      Leopoldo Sebastián M. Gómez – Licenciado en Ciencias de la Computación (U.N.S.) – Perito Informático Oficial – Poder Judicial del Neuquén – Argentina – http://www.angelfire.com/journal2/lead/index.html
      Leopoldo Sebastián M. Gómez
      gomezsebastian@yahoo.com

      Leer entrada completa | Make a Comment ( Comentarios desactivados en Diseño de Interfaces de Usuario – Principios, Prototipos y Heurísticas para Evaluación )

      Características de un buen Negociador

      Posted on 26 marzo 2008. Filed under: Uncategorized |

      Existen características típicas de un buen negociador, que una vez que te acostumbras a detectarlas, saltan a la vista. Este artículo ha sido redactado en género masculino pero aplica por igual a los dos géneros. Veamos:

      Le gusta negociar: la negociación no le asusta, todo lo contrario, la contempla como un desafío, se siente cómodo. Tampoco le asustan las negociaciones complicadas, pueden incluso hasta motivarle más.

      Es entusiasta: aborda la negociación con ganas, con ilusión. Aplica todo su entusiasmo y energía en tratar de alcanzar un buen acuerdo.

      Es un gran comunicador: sabe presentar con claridad su oferta, consigue captar el interés de la otra parte. Se expresa con convicción.

      Es persuasivo: sabe convencer, utiliza con cada interlocutor aquellos argumentos que sean más apropiados, los que más le puedan interesar.

      Es muy observador: capta el estado de ánimo de la otra parte, cuáles son realmente sus necesidades, qué es lo que espera alcanzar. Detecta su estilo de negociación, sabe “leer” el lenguaje no verbal.

      Es sociable: una cualidad fundamental de un buen negociador es su facilidad para entablar relaciones personales, su habilidad para romper el hielo, para crear una atmósfera de confianza. Tiene una conversación interesante, animada, variada, oportuna.

      Es respetuoso: muestra deferencia hacia su interlocutor, comprende su posición y considera lógico que luche por sus intereses. Su meta es llegar a un acuerdo justo, beneficioso para todos.

      Es honesto: negocia de buena fe, no busca engañar a la otra parte, cumple lo acordado.

      Es profesional: es una persona capacitada, con gran formación. Prepara con esmero cualquier nueva negociación, no deja nada al azar.

      Detesta la improvisación, la falta de rigor y de seriedad: conoce con precisión las características de su oferta, cómo compara con la de los competidores, cómo puede satisfacer las necesidades de la otra parte.

      Es meticuloso: reúne toda la información disponible, ensaya con minuciosidad sus presentaciones, define con precisión su estrategia, sus objetivos. Le da mucha importancia a los pequeños detalles.

      Es sólido: tiene las ideas muy claras (sabe lo que busca, hasta donde puede ceder, cuáles son los aspectos irrenunciables, etc.). El buen negociador es suave en las formas pero firme en sus ideas (aunque sin llegar a ser inflexible).

      Tiene autoconfianza: el buen negociador se siente seguro de su posición, no se deja impresionar por la otra parte, no se siente intimidado por el estilo agresivo del oponente. Sabe mantener la calma en situaciones de tensión.

      Es ágil: capta inmediatamente los puntos de acuerdo y de desacuerdo. Reacciona con rapidez, encuentra soluciones, toma decisiones sobre la marcha, sabe ajustar su posición en función de la nueva información que recibe y de la marcha de la negociación. No deja escapar una oportunidad.

      Es expeditivo: busca resultados en el corto plazo, aunque sin precipitarse (sabe que cada negociación lleva su propio tiempo y que hay que respetarlo). Sabe cuales son sus objetivos y se dirige hacia ellos. Los obstáculos están para superarlos, no desiste sin plantear batalla.

      Acepta el riesgo: sabe tomar decisiones con el posible riesgo que conllevan, pero sin ser imprudente (distingue aquellas decisiones más trascendentales que exigen un tiempo de reflexión y que conviene consultar con los niveles superiores de la compañía).

      Es paciente: sabe esperar, las operaciones llevan un ritmo que conviene respetar. Uno no debe precipitarse intentando cerrar un acuerdo por miedo a perderlo.

      Es creativo: encuentra la manera de superar los obstáculos, descubre soluciones novedosas, detecta nuevas áreas de colaboración.

      Leer entrada completa | Make a Comment ( Comentarios desactivados en Características de un buen Negociador )

      « Entradas anteriores

      Liked it here?
      Why not try sites on the blogroll...