La parte dificil de construir sofware es la especificación

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

Quien estima mejor?

Tu estimación del proyecto por quien ha sido realizada?

Developer / Project Manager / Project Tracker / Testing Team / Quality Assurance team.

Según los roles serán las estimaciones. Pero esto no debería ser así o es lo más lógico?

Algo de Testing Automatizado

Objetivos del Testing Automatizado

• Tests should improve quality

• Tests should help us understand the system under test

• Tests should reduce risk

• Tests should be easy to run

• Tests should require minimal maintenance as the system evolves

• Tests should be executed as part of the build process if possible

 

Tipos básicos de Testing donde se puede automatizar

• Unit tests

• Customer Test

• GUI Testing

 

Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

¿Cuales son los objetivos de nuestro Testing Automatizado?  Estos deben estar alineados con todos los objetivos de Calidad. Algunos factores que afectarían a nuestros objetivos:

Deseamos automatizar las pruebas regresivas?

Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?

Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

Comencemos a Organizarnos

Elegir una estrategia

Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización. Debería ser una combinación de aproximaciones basadas en:

• Objetivos
• Tipo de sistema que queremos Testear:
  • Testabilidad. Definir la capacidad del sistema a soportar automatización de pruebas
  • Nivel de automatización actual. Si la base es cero podría ser el peor escenario
• Podemos modificar el Proceso de Desarrollo y los Requisitos del Sistema para lograr una aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas?
• Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítmes?
• Seleccionemos un tipo de Testing Automatizado: Unitario, Integración , Requerimientos, etc.

Seleccionemos las herramientas basándonos en

• Estrategia seleccionada
• Orientación del Testing Automatizado (Aceptación del Cliente, de Componente, GUI)
• Open Source o Comercial?
• La aplicación seleccionada se adapta a nuestra aplicación o debemos hacer adaptaciones de la aplicación a la herramienta?
• Definamos cuales son nuestros costos

Dos puntos son necesarios para facilitar el mantenimiento

• Definamos las expectativas de la Gestión de las pruebas
• Definamos los estándares o patterns para implementar las pruebas automáticas.

Por ejemplo usemos Palabra Clave como patrón que puede utilizarse para reducir los costos de mantenimiento al utilizar la interfaz de usuario basada en la automatización. Algunos de los enfoques de benefician directamente con el trabajo de control de calidad.

El enfoque que realizamos afectan a las acciones 

• Los desarrolladores serán responsables de crear y mantener las Unidades de Pruebas Automatizadas, aunque puede ayudar a QA y su criterio será fundamental
• SQA puede crear los otros tres tipos de pruebas automatizadas, como siempre lo mejor es integrar directamente en el proceso de desarrollo
• Debemos asegurarnos de que el Testing Automatizado es realmente parte del proceso y se complementa con el Testing No Automatizado

Revisemos el Plan de Pruebas Automatizadas

En todos los casos se debe hacer revisiones de la efectividad del proceso y buscar la forma de mejorarlo. Las siguientes cuestiones podrían ayudarnos:

• Son lentas las automatizaciones?
• Son difíciles de mantener?
• Disminuyen la velocidad del Proceso de Desarrollo?
• Son eficaces en el logro de nuestros objetivos de calidad?

Estas pruebas tienen como principales objetivos comprobar que el código se comporta de la manera esperada y prevenir la aparición de errores inesperados al modificar o refactorizar el código. También, en algunos casos como en el desarrollo dirigido por pruebas, las pruebas unitarias ayudan a obtener el diseño del código. Las ventajas de realizar este tipo de pruebas son: código más depurado, mayor seguridad a la hora de refactorizar y mayor velocidad de desarrollo, aparte de obtener código de mayor calidad asegurando que nada se ha roto cuando cambiamos la lógica interna del software.

Actualmente las pruebas unitarias se desarrollan con herramientas tipo jUnit [3] y objetos mock [4]. Las herramientas tipo jUnit se aplican para comprobar que el estado de un objeto, los valores retornados por los métodos, excepciones lanzadas, etc, son los esperados. Los objetos ficticios o mocks, en cambio, permiten aislar el código a probar de las dependencias con otras clases colaboradoras mediante el desarrollo de clases ficticias que simulan el comportamiento de estas clases colaboradoras. Esto permite centrar la prueba sólo en el código que se desea probar.

Aquí introduzco conceptos de Testing Driven Development (TDD) tomados de un blog amigo WebTrun:

| View | Upload your own

Las organizaciones son tan eficientes como sus procesos

El diseño de un flujo de trabajo no es solamente un medio de documentar procesos, sino que es la guía de trabajo para el ambiente operativo.

Es necesario diseñar con consenso de las partes, los flujos de trabajo para los procesos de negocio que acompañen el ciclo de vida completo de las interacciones Cliente-Organización-Usuarios.

No se puede pretender eficiencia de los procesos cuando se ingresan cambios sin tener en cuenta el impacto global y particular en las distintas PA y las personas que interactúan en ellas. O solamente pensando en un resultado puntual que sirve a un propósito de corta data.

Finalmente, hay que entender el por que de hecho de que la mayoría de las empresas tomaron conciencia de lo imprescindible de contar con una herramienta que coordine el trabajo y permita compartir actividades, información y recursos en un ambiente simple de operar y monitorear.

Cronograma de proyectos, agendas de trabajo, dependiencias y criterios de completitud

Resulta importante no hacer recortes en las actividades que tienen relación con el aseguramiento de calidad y las fechas de entrega no pueden poner en riesgo el aseguramiento de calidad, y los esfuerzos correctivos deben realizarse durante el proyecto y no al final cuando es prácticamente imposible.

Esto implica que debe plantearse una estrategia que sea sostenida durante todo el ciclo de vida del proyecto y que se apliquen las tácticas adecuadas para evitar desplazamientos que pongan en riesgo tanto la fecha de entrega como la calidad en si.

Es fácil observar que las agendas particulares que genera el cronograma del proyecto, tienen fuerte dependencias con otros integrantes del equipo y no es aceptable romper esas dependencias sin considerar los impactos de esas rupturas (básicamente cambio en la agenda de algún integrante). Este tipo de ruptura implica una falta al compromiso con el recurso dependiente y principalmente con la actividad planificada, lo cual quiere decir que alguien deberá realizar mayores esfuerzos para lograr cumplir con los elementos satisfactores que darán completitud a la actividad.

Es cierto que la mayoría de las veces no son intencionales tales incumplimientos, sobre todo en algunas personas con roles específicos, que reciben pedidos en carácter de urgente. Sin embargo, si existe una planificación y se crea una agenda personal que incluye actividades con dependencias hacia otras actividades de otros recursos (agenda global), todo esto debería anteponerse a la fuerte necesidad de responder a las necesidades instantáneas de los superiores del organigrama.

De no ser posible, debe consensuarse con los involucrados y modificar las condiciones de cumplimiento y aceptación (negociación), pero esto idealmente, no debería ser una constante hacia adentro, que implosione, sino que es mucho más saludable sostener un carácter de cumplimiento con las actividades con dependencias y el carácter negociador con los que generan nuevos pedidos en forma constante.

En definitiva si permanecemos en la actitud de modificar nuestras actividades rompiendo dependencias sin negociar, vamos en contra de los principios de Completitud, que pertenecen a los axiomas del aseguramiento de calidad. ¿No es completitud la palabra más utilizada por los superiores de la organización a la hora de una refriega por incumplimiento?

Ahora que estamos obligados a trabajar con agendas visibles para La Gerencia y el resto de los integrantes de la compañía, logremos que no se nos vuelva en contra y aprendamos a manejar todos los elementos que implica llevar una “agenda de compromisos”. Que cada ítem que ingresamos deje de ser un elemento de reclamo y acusaciones constantes.

Mi rol, mi evolución, mis quedos, mi dejos

 

Como Responsable SQA y QAC, sostengo mi crecimiento permanente basándome en la vida misma de los proyectos, en las interdependencias profesionales y en la relevancia de nuestras soluciones para el usuario. 

La formación de un proceso particular y nuestra adaptación no ha sido fácil. Principalmente nos ha sido imposible automatizar las pruebas para un entorno de desarrollo basado en la API de Lotus Note, de IBM y todo lo que pueda existir para automatizar pruebas a cualquier nivel nos resultó bastante costoso, en lo que a tiempo y esfuerzo se refiere.

Es así que me he puesto en la tarea de mejorar todos los procesos intrínsecos, previos a cualquier desarrollo.

La estrategia global implicó lograr alertar fallos utilizando un símil  AMFE en los requerimientos, también en fases de Análisis y Diseño. Posteriormente establecer una cadena de revisiones para las soluciones técnicas propuestas, mas estudios de viabilidad y factibilidad de Despliegues de Productos, tratando de detectar y minimizar cualquier merma de la calidad que impacten en los eslabones finales de la cadena de producción.

Como estrategia para pruebas, generamos la cantidad de ambientes de Testing que fueran necesarios, basándonos primariamente en los ciclos que dimos de alta en el cronograma del proyecto.

Nuestra táctica implica la formación de una alta cantidad ciclos con una gran cantidad de Pruebas de Integración, que no son coincidentes con Versiones Candidatas del producto, sino que en cada integración nos vamos acercando a dichas versiones. Al lograr integrar todos los componentes que conforman un módulo testeable a nivel de pruebas funcionales, versionamos el producto y ejecutamos el ciclo funcional correspondiente.

Esto esta lejos de ser una Integración Continua, pero es la aproximación mínima que he podido idear para que la mayoría de los defectos se detecten con bastante antelación.

Conformamos un equipo chico de desarrollo, con un Responsable que hace las gestiones de seguimiento de avances de los componentes y determina en base al cronograma, el hito de integración de componentes, del mismo modo la conformación de los módulos y notificaciones al LP y SQA, de los módulos que están disponibles para pruebas de funcionales.

La envergadura del equipo exige que los mismos desarrolladores ejecuten los ciclos de pruebas integradoras y lo hacen bajo un esquema de revisiones cruzadas. SQA asigna también un equipo de Testeadores que ejecutan pruebas integrales ayudando a acelerar el proceso.

Previo a esto, sin duda alguna tuvimos que elevar el Skill de los Desarrolladores de esta tecnología tan particular, en lo que respecta a técnicas de pruebas y detección de fallos.

Todos los fallos, defectos y errores son registrados y puestos a consideración de SQA y el LP quienes en un solo lote hacen las derivaciones para resoluciones, en base a la severidad y prioridad determinada en un análisis exhaustivo.

Este accionar nos ha llevado rápidamente a una disminución significativa de fallos detectados en ciclos de pruebas funcionales de versiones candidatas y a una desaparición del 100% de fallos del tipo Invalidante y del 80% de fallos del tipo Grave.

Las actividades de Despliegue en si mejoraron y garantizaron mejores funcionamiento cuando se comenzó a utilizar el elemento "Pruebas de Campo" y finalmente nuestro equipo de Soporte cuenta con una gran biblioteca de fallos detectados los cuales alimentan su base de conocimientos a cerca de como se podría presentar un fallo y como se orienta a su rápida resolución.

Poco a poco trataré de mostrar los procesos aunque no pueda dar demasiados detalles, lo haré genérico.

Hábitos que se consideran importantes para un desarrollador (y cualquiera)

Anoche leyendo un foro de los que acostumbro, tuve la oportunidad de rescatar las siguientes líneas. Quiero comentarles que estos axiomas corresponden a apreciaciones que hacen Ingenieros, Programadores, Gerentes y Testers de varios países como España, Chile, Colombia, Perú, Argentina, y otros de habla hispana.

• "Intenta siempre buscar la simplicidad". Busca siempre y por defecto la solución más simple, más natural, más clara frente a la optimizada, compleja y eficiente. Hoy en día, el rendimiento es algo que se ha superado con creces gracias a los potentes procesadores. Intentarlo inicialmente de la manera "fácil" y, si no da buen resultado, dar un paso hacia la optimización. Pero sólo uno. Si sigue dando problemas, da otro paso.
• "Capacidad de organizar tu trabajo". Cada programador debe ser consciente de cuales son las horas más productivas del día para el y utilizarlas al máximo y dejar los momentos más flojos para tareas mecánicas. Es decir, evitar errores por cansancio que desembocan en un montón de correcciones a posteriori. (p. Ej.: para mi las primeras horas de la mañana son las más productivas y dejo para última hora de la tarde las tareas monótonas, reuniones, etc.)
• "Analizar y organizar tu trabajo antes de hacerlo". El papel suele ser un buen medio. Es importante para tener claro en tu cabeza que vas a hacer.
• "Intentar ser exigente en tu trabajo no sólo en las grandes tareas sino en todos los aspectos mínimos de un proyecto". A veces son los que marcan la diferencia. (Desde borrar variables en un fichero a optimizar los plazos de un proyecto. Todo es importante).
• "Intentar ser pausado". Es una mala costumbre dar por buena al que más teclea. El programador debe acostumbrarse a ser reflexivo. A medio plazo compensa.
• "Piensa en el test, tanto unitario como funcional". Una posibilidad es usar metodologías de desarrollo orientadas al test (Test Driven Development), pero no es la única. Lo cierto es que pensar en como vamos a verificar en el momento del desarrollo significa un ahorro importante durante fases de test y mantenimiento futuro.
• "Deberías revisar las buenas prácticas de programación que se utilizan en extreme programming"
• “Programación en pares - Reutilización -Uso de estándares”, entre otros
• "La información debe fluir". Es decir, debe pasar de unas manos a otras, de una rutina a otra. De esta forma, evitaríamos (o al menos minimizaríamos) el uso de las tan peligrosas variables globales. Como caso práctico, nosotros solemos aplicar esta regla cuando pasamos de un formulario de la aplicación a otro. En lugar de que el formulario destino "tome" la información que necesita, se la pasamos a través de un método "Execute".
• "Borrar la declaración de las variables que ya no se usan". Es práctica común ir copiando un programa de otro y comentar lo que no sirve para el nuevo pero no borrarlo, por ejemplo en lenguajes como C ó C siempre  se  tiende  a  dejar  las  variables que no se usan. Para ello las últimas versiones de los entornos de desarrollo ya incluyen ciertas herramientas de refactoring y una de ellas suele ser la de eliminar las variables no utilizadas.
• "Usar una herramienta control de versiones".
• Como dice el bueno de Steve (McConnell) en su "Code Complete 2", la clave del éxito de un producto software es la gestión contínua y correcta de la simplicidad.
• "Haz que tu código se parezca lo más posible al lenguaje normal". El mismo que utilizarías si le quieres explicar a alguien ajeno qué hace ese programa. Identifica las palabras más importantes que utilizas en la explicación y haz que salgan en el código. Volviendo al ejemplo de antes, si dices "si el fichero está abierto, lo cierro", no escribas "if CurrentFile.fOpen<>NULL" !!!
• Cuando implementes una solución, sigue el orden que cualquier ser humano esperaría. Prepara primero el trabajo y luego hazlo. Una buena idea (sugerida también por McConnell) consiste en escribir la solución en "cristiano" antes de comenzar a teclear código. Luego convierte esas frases en comentarios y, bajo él, introduce el código correspondiente.
• Explica por qué no has podido hacerlo más simple. Cuando empezamos a trabajar en un código heredado, todos los programadores deseamos encontrarnos los comentarios adecuados en el sitio adecuado. Pues acuérdate de eso cuando seas tú el que has escrito el código.
• La frase de "divide y vencerás" está tan manida que la llegamos a olvidar injustamente. ¿A que te joroba encontrar una rutina de 3 pantallas en el código ajeno? Muchas veces merece la pena hacer una rutina de una línea (del estilo "bool File.IsOpen( )") en aras de la legibilidad.
• "Fortalecer la comunicación con sus compañeros"
• "planificar su día antes de empezar a trabajar"

Fallos y defectos. Su persistencia y estrategia para mitigarlos.

Al respecto de los defectos reportados, su persistencia y/o mutación, sucede que los defectos reportados por Testing en algunos casos fueron persistentes hasta tres (3) ciclos y en algunas situaciones más. El defecto es tratado normalmente según el  proceso normal establecido. Lo cierto es que nunca tienen el mismo comportamiento ni los mismos síntomas y por lo general no se reportan como nuevos defectos sino que se le aumenta la persistencia y en el mismo defecto se reportan las No Conformidades. Así hasta que definitivamente se obtiene un resultado satisfactorio.

Inicialmente puede decirse que el fallo es reportado por Testing con un bajo análisis de los defectos que lo provocan, lo cual dentro de un ciclo de pruebas de sistemas es correcto, inclusive sin ningún análisis sino la mera detección y reporte.

El o los defectos puede/n escalar a otros niveles, como por ejemplo a las prueba de campo (producción), sin ser necesariamente un fallo y ser detectado/s allí con cierto grado de mutación.
Se asume que el fallo persiste y se lo reconoce como si se tratara del mismo que alguna vez se detectó en fases anteriores de las pruebas, pero en realidad puede tener otra naturaleza. Un ejemplo son las fechas con formato invertido en algunos campos, las cuales no representan necesariamente un fallo salvo una incomodidad visual, pero que en algunas situaciones especiales pueden llevar a la toma de una decisión incorrecta si no se percibe por parte del usuario. 

Es importante notar que esta mutación de defectos se va dando a medida que se hicieron correcciones sobre los fallos reportados y es aquí mismo donde uno se detiene a pensar en el por que de la persistencia.

Me interesa analizar el contexto para reconocer esos motivos:

Motivo 1

Otro motivo importante es la falta de definición de los requerimientos, la esencia del concepto que da vida a los mismos para lograr tangibilizarlo como una funcionalidad.
Este motivo podría tener muchos frentes para atacar, sin embargo yo me centro en que se debería aumentar el análisis que nos permita conocer la mecánica de uso involucrada y como se puede agregar valor funcional.

Esto puede implicar pactar una interacción fluida con el Cliente o un Usuario Líder de modo tal que se involucre en el proyecto y valide la evolución de los requerimientos. Este mismo usuario en un esquema de validaciones y verificaciones, puede ayudarnos en gran medida a la detección temprana de cambios y principalmente al planteamiento de las estrategias para afrontarlos y establecer un criterio de fin en base a la completitud necesaria del requisito.

Motivo 2

También la falta de Estimación de Riesgos posibles para cada uno de los requisitos impacta en la aparición (formación diría yo) de los fallos y defectos, puesto a que es posible iniciar las fases de construcción sin tener conciencia de los problemas que debemos evitar para generar un componente completo. Este aspecto también favorece a la mutación de los defectos una vez que los fallos fueron detectado, reportados y "solucionados", debido que las resoluciones son encaradas del mismo modo en que se construyeron los componentes.

Se puede considerar como muy valioso reconocer en que fase impactarían los riesgos detectados y de ese modo establecer la estrategia que mejor se ajuste a la mitigación, eliminación o aceptación del riesgo.
Teniendo en cuenta que se debe evitar un impacto desfavorable, se pone en conocimiento de los riesgos detectados a los responsables de cada fase y luego al equipo involucrado en la fase. Para esto es posible que se deba tener un nombre claro del riesgo, una descripción de que lo produce y como se manifiesta (síntomas), los antecedentes de ocurrencia en caso de que los tuviera, y la cantidad de veces que se podría presentar según los antecedentes. Es importante que cada uno pueda realizar una lectura inteligente, simple y tienda a la estrategia correcta.

Motivo 3

Una vez que los fallos y/o defectos escalaron a un Ambiente de Producción, los mismos son reportados por los Usuarios Finales bajo algún esquema de "Mesa de Entrada al Soporte del Sistema". Allí mismo se incurre en una grave falencia al dar de alta los fallos y/o defectos, pues se lo hace sin un Subjet claro que exprese en forma simplificada del problema ("sujeto2+"situación no deseada"). Así mismo el cuerpo del reporte no es más que una descripción del incidentes sufrido por  usuario y por ende no involucra ningún análisis ni apunta a ninguna alternativa de solución.
En este sentido es prácticamente imposible diagramar próximos pasos y coordinar acciones efectivas y eficientes (teniendo en cuenta un Calendario)

Motivo 4

Un importante motivo a considerar es la falta de análisis del fallo y los defectos que lo provocan. Así mismo no reconocer su impacto en el requerimiento del cliente y en su entorno de trabajo a nivel del negocio y no solo del sistema.

El análisis de los fallos y defectos, tiene que tener al menos un responsable. Típicamente se imputa la responsabilidad a SQA, el cual debe reconocer los factores mencionados a nivel de impacto y riesgos, detectar la naturaleza de los fallos y posteriormente emitir el reporte de los mismos. Esto podría implicar también que el mismo equipo SQA es responsable de categorizar no solo el carácter de Severidad, sino también la Prioridad con la que se debe dar resolución a cada uno de los fallos.

Una estrategia de este tipo puede denotar ciertas demoras en el proceso relentizandolo por no hacerse el reporte de fallos y/o defectos en forma instantánea, una vez que son detectados en los ciclos de pruebas. Sin embargo, puede por otro lado acelerar la calidad de las resoluciones disminuyendo la persistencia de los defectos y su mutación, como también garantiza en mayor grado que se resuelven en un orden que agrega valor al proceso en general.

 

Es necesario crear una conciencia general para todos los involucrados en la Gestión de Problemas para propender a la generación de Soluciones Técnicas definidas correctamente según el propósito de cada resolución y que tomen como entrada los Subjetcs y Descripciones correctamente formados.
Esta formación impactará directamente en la mejora del trabajo proactivo evitando el trabajo en solitario y aumentando las capacidades de seguimientos anticipados. Aunque parezca contradictorio, su vez genera un buen grado de independencia de trabajo para el resto del equipo de trabajo en base a la mejora sustancial que implica en nuestra base de conocimientos.
También estimula la limpieza del proceso de la organización y facilita el conocimiento individual para fortalecer el conocimiento grupal.

Modificar el "paradigma de pruebas" por el "paradigma de evidencias".

En nuestra organización me he visto obligado a modificar el "paradigma de pruebas" por mi "paradigma de evidencias".
Movilizado por la creciente demanda de agilidad que nos impone el ritmo de obtención de proyectos, ya sean para modificaciones de productos existentes o para construcción de nuevos, SQA trabaja fuertemente al principio de los proyectos, desde las minutas de requerimientos, pasando por la ERS, ERP, documentos de análisis, diseño y arquitectura (si es que los hubiere) para localizar los puntos débiles y fortalecerlos en base a observaciones de No Conformidad que obliguen a un enriquecimiento del proyecto antes de pasar a otras fases del mismo. Eso como primera medida.
A partir de esos documentos, SQA comienza un análisis profundo con una alta tasa en la solicitud de consultas técnicas, investigaciones paralelas (documentación técnica, de negocios, de sistemas, modelos de datos, arquitecturas, patrones de diseño, etc.) entre otras actividades y empieza a formar el documento de calidad "Especificaciones SQA" si le quieres dar algún nombre. Este documento lo vamos formando y generando su trazabilidad en base a la descomposición de trabajo (WBS) que hicieron los analistas y líderes de proyectos en una fase de iniciación.
Nuestros criterios de calidad son tanto para el proyecto, para el producto o sistema, como también para los servicios aledaños y son puestos "a mano" del área de desarrollo, como documento matriz para la guía de la calidad esperada.
No generamos casos de pruebas, puestos que solicitamos EVIDENCIAS y este concepto introducido por mi, obliga al equipo de desarrollo a la generación de todos los elementos tangibles que garantizan la completitud y correctitud del componente entregable o no entregable que se construyó. Ya sea que se trate de un componente de interfase, una clase, objetos, esquemas de bases de datos, parámetros de conectividad o cualquier tipo de instanciación, debe quedar una evidencia que puede ser sujeta a una auditoría de calidad.
De este modo, SQA no forma un equipo de testing que espera un producto final desplegado en un ambiente controlado para pruebas, ni forma juegos de pruebas de funcionalidad que puedan ser ejecutados en una fase determinada, pero si ejecuta el uso del sistema bajo un fuerte y concienzudo conocimiento del mismo, debido a que pudo generar los factores de evidencias mínimas requeridas y durante toda la fase de construcción, interactúa con el área de desarrollo haciendo un seguimiento de la formación de las evidencias a satisfacerse.
Es posible que este proceder no reduzca el tamaño ni el esfuerzo de las pruebas, sino todo lo contrario, pero lo que si provoca, es una mejor distribución del esfuerzo para la obtención de calidad.
Quizás no es fácil entender mi modelo, pero es una idea que puse en práctica y esta dando buenos resultados en nuestro ambiente de trabajo. Tenemos mejor adaptación a cambios hasta el punto tal de que SQA puede inclusive no enterarse de las modificaciones introducidas a ciertos requerimientos de algún proyecto en particular, pero minutos antes de recibir el entregable consolida el conocimiento con las EVIDENCIAS y reorganiza los criterios de calidad para aceptar o rechazar el componente. Puede parecer extremista, pero lo es también la exigencia de nuestras necesidades de facturación y los mercados y el volumen de pruebas sería imposible de manejar para un equipo como el nuestro, al menos.
Así que tiro la punta del ovillo para que comencemos a debatir este modelo, si es que les parece debatible.

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

 

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.

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.

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.

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.

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

Aunque 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.

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.

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.

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.

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.

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.

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.

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

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

Evidenciar las falencias de la Integración del Código

Lamentablemente el Testing de hoy fue un éxito rotundo con los módulos puestos a pruebas de verificación, los cuales dan fallo de severidad INVALIDANTE.

Este tipo de reportes suele ser típico en la mayoría de las organizaciones dedicadas a la construcción de software y por mucho esfuerzo que se hace en introducir mejoras en los procesos a niveles de mejoras en las tomas de requerimiento, análisis, diseño y desarrollo, no se logra superar ciertas barreras que tal vez son de otra índole.

Lo que pude ver y analizas hasta ahora, esta relacionado a una grave falencia en el proceso de integración, quizás en su método, tal vez en su ambiente o en ambos, en el área de Desarrollo. ¿Por que digo esto?

Los desarrolladores juran que los fallos que resultan en Testing no se presentan en sus ambientes de desarrollo y no hay dudas de que ellos entregan los componentes con las pruebas ejecutadas que el entorno de diseño les permite, más las limitaciones que cada quien tiene en su PSP. Luego pasan a otro componente y lo entregan, siempre cumpliendo el mismo circuito.

Finalmente se integra todo y se versiona el sistema para ser entregado a SQA, quien genera los ciclos de verificaciones funcionales y donde a las primeras surgen fallos.

Esto evidencia claramente que no hay Pruebas de Integración o las mismas son muy escuetas y es por eso que el primer ciclo de “Pruebas Funcionales” que ejecuta Testing es considerado por mí como “Pruebas de Integración”.

Lo lamentable y donde se evidencia fuertemente la falta del ambiente de integración, es cuando el defecto se hace persistente y es reportado dos o tres veces sin que realmente se solucione.

Una solución posible según mi óptica, sería que se formen los ciclos de desarrollo lo suficientemente chicos como para ser integrados N veces cada vez que ese ciclo finaliza, es decir cada vez que los desarrolladores entregan los N componentes del ciclo. Así pues se los integra y los desarrolladores mismos puedan ejecutar las pruebas de integración (funcionales) y detectar los fallos lo antes posible sin tener que considerar su trabajo finalizado hasta que superen esa etapa.

Esto no implica que cada ciclo de integración deba entregarse a Testing, sino el costo de las pruebas sería muy alto, sin embargo ya tendríamos predefinidos en los cronogramas del proyecto los ciclos de pruebas funcionales para integraciones más grandes, modulares y que representen una versión del sistema en si misma.

Sin duda duda que esta referencia y análisis lo hago para ambientes de desarrollo donde existe poco y nada de automatización y no se puede trabajar con Integración Continua, siendo más primitiva la metodología de generación de versiones, aún con potentes IDES, como es el caso de Lotus Notes.

Doce características típicas de un equipo de alto rendimiento

1. Tener un propósito claro. Todos los miembros del equipo deben saber exactamente cuál es el objetivo a alcanzar. Así sabrán cómo pueden contribuir al logro del objetivo y podrán focalizar su energía y trabajo en ello.

2. Tener una comunicación efectiva hacia adentro y hacia afuera. Un intercambio ágil de la información permite asegurar que se adoptarán oportunamente las decisiones correctas y no existirán dudas en los miembros del equipo respecto a qué deben hacer, cuándo, cómo y por qué.

3. Voluntad de aprender de los demás. Todo proyecto es una iniciativa única. Por ello es importante que los integrantes del equipo tengan voluntad de aprender nuevas técnicas o métodos para ser aplicados en el proyecto. Sino, existirá la tendencia a repetir métodos de trabajo ya conocidos, los cuales no necesariamente serán los mejores.

4. Participación en el grupo. Para que los miembros del equipo del proyecto se perciban como parte de éste, es fundamental que cada uno de ellos tenga una participación activa: los miembros del equipo no solo deben tener tareas específicas a realizar, sino que deben sentirse involucrados en la discusión de los problemas y en las decisiones que se adopten.

5. Orientación a la solución de problemas. La dinámica del equipo debe tener una orientación a la solución de problemas y no a la búsqueda de culpables. Esto genera un ambiente de solidaridad y confianza que contribuye significativamente a la motivación de los miembros del equipo. Que ello ocurra depende fundamentalmente del estilo de liderazgo del gerente.

6. Búsqueda de la excelencia. No sólo en aspectos técnicos, sino también en lo referente a las relaciones entre sus integrantes y con otros involucrados, la responsabilidad por el trabajo y sus resultados.

7. Celebración de los logros. La celebración de los éxitos alcanzados es otro factor que contribuye a la motivación de los integrantes del equipo. Cuando se alcancen hitos importantes, y si estos se han logrado con la calidad esperada, el celebrar este logro como equipo hace que cada uno de los miembros de éste sienta que ha contribuido a algo bueno e importante. Estas celebraciones son también una oportunidad para que el gerente de proyecto destaque en forma especial a quienes han contribuido al éxito alcanzado más allá de lo esperado.

8. Involucrar a todas las personas relevantes. Cuando es necesario solucionar un problema y existen varios miembros del equipo que poseen conocimientos que pueden ayudar a solucionarlo, la tarea debe ser abordada por el equipo. Nadie es capaz de entender o resolver un problema solo.

9. Equipos multidisciplinarios para problemas multidisciplinarios. Cuando el problema se relacione con distintos ámbitos funcionales (por ejemplo, finanzas, recursos humanos y operaciones), la búsqueda de una solución debe ser abordada por un equipo que incorpore representantes de las distintas áreas funcionales.

10. Búsqueda de la innovación. El intercambio de ideas que se produce en un equipo multidisciplinario genera nuevas formas de ver y solucionar los problemas. Por ello un equipo de estas características es la mejor forma de innovar en la forma de ejecutar proyectos.

11. Descontento con el status quo. Queremos cambiar paradigmas. Si un proyecto se ejecutó siempre de acuerdo a una determinada metodología y queremos buscar nuevas y más eficientes formas de llevarlo a cabo, la capacidad innovadora de un equipo es la mejor forma de hacerlo.

12. Compromiso. Al trabajar en equipo los integrantes de éste sienten un compromiso no sólo con el trabajo a realizar, sino que también con sus compañeros.

Características de un buen Negociador

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.

Gestión SQA y de Proyectos en Procesos de Construcción de Software: Políticas de Seguridad Organizacional para el Desarrollo de Software

Gestión SQA y de Proyectos en Procesos de Construcción de Software: Políticas de Seguridad Organizacional para el Desarrollo de Software

Políticas de Seguridad Organizacional para el Desarrollo de Software

Me pregunto cual es el hilo conductor del ciclo de vida de desarrollo de nuestras aplicaciones y como respuesta obligada, digo a todas luces que no es una política de seguridad organizacional. Creo hoy que todos aquellos proveedores de software que no se rijan por políticas de seguridad para conducir su desarrollo de aplicaciones, están encaminados a una próxima desaparición del mercado global. Es muy posible que parezca una exageración pero, ¿cuantos de todos nosotros hemos adoptado realmente las directrices de seguridad de nuestros clientes más allá de considerarla como un importante requisito no funcional? ¿Cuantos proveedores de aplicaciones propias realmente gozan de buena salud en su políticas de seguridad para guiar desde las raíces al proceso de desarrollo? Pongo las manos en el fuego si digo que la mayoría de los arquitectos y desarrolladores construyen con solo las normativas y exigencias clásicas que cualquier aplicación exige, más no superaría una avanzada de cualquier hacker de rango medio o bajo.
Pienso que esta falencia desnudaría a cualquier fabrica de software ante un cuestionario sencillo de nuestros clientes, si estos fueran lo suficientemente cautelosos a la hora de contratar a sus proveedores.
Me pregunto también si estamos dispuestos a asumir los costos en materia de seguridad para incluirla dentro de los procesos de obtención de calidad para nuestros productos y servicios, ya que si la calidad es costosa, la seguridad por si misma lo puede ser aún más.

La visión de John Steer CISSP, Asesor Senior de Seguridad, Microsoft ACE Services a cerca de las Políticas de Seguridad adosadas al desarrollo de software

La Calidad no existe por si misma

La calidad no existe por si misma, debe ser deseada organizacionalmente, debe ser analizada, estudiada, manipulada, procesada y muchas veces para luego en algún momento pretenderla. La calidad no se tangibiliza de la noche a la mañana ni por que un equipo de desarrolladores sabe hacer testing unitario, ni por que un equipo de analistas de pruebas hagan buenas pruebas funcionales, ni por que el requerimiento este bien planteado y las funcionalidades bien definidas. La Calidad es en un principio un intangible, y pasa por muchos circuitos sin poder ser atributo de una sola área de proceso en particular, sino de todas en conjunto y esta involucrada en cada uno de los hilos conductores de un proceso y en sus nodos y en los inputs y outputs de cada componente. La calidad es una cuestión cultura también por eso alguien mencionó a un posible cliente venido de otras tierras conociendo mejores productos.
Yo analizaría todos los elementos que conforman a la calidad. La cultura empresarial, los recursos humanos involucrados, los proceso definidos, las técnicas utilizadas, las herramientas que me ayudan, los modelos que sigo, el grado de comunicación y la proactividad, las capacidades de reacción a los cambios imprevistos, entre otras cientos de cosas y recién comenzaría a plantearme un esquema de calidad.

Robustez como atributo de calidad del software

Aparentemente los argumento para definir los atributos de calidad pueden estar algo confusos en lo que a robustez se refiere. Me acoplo mejor a las mediciones empíricas que a las apreciaciones subjetivas reconociendo que hay relaciones directas e inversas entre distintos atributos para lograr definir un índice de robustez. No adopto las limitaciones que justifica a la robustez solo el comportamiento del sistema fuera de los límites, ya que esto acota mucho el criterio.
Yo particularmente ligo Robustez con Integridad como hojas de un troncal llamado Fiabilidad, el cual es hoja de un troncal llamado Usabilidad que proviene de una raíz llamada Utilidad General (modelo jerárquico de  Boehm) por lo que es más importante medir el grado de fiabilidad lo cual no puede ser obtenido por relación directa con solo esos atributos, sino que por múltiples relaciones inversas con otros atributos que transgreden a estos mencionados, terminan determinando la Utilidad General del sistema.

Ágile. Proceso o no?

En lo personal no comparto la opinión con los que emiten comentarios que hacen emblemático a un personaje en particular y por otro lado emiten comentarios que detrimentan a otro, cuando en ambos casos hablamos de personas que administran gran cantidad de personas al rededor de múltiples proyectos concurrentes y se las han arreglado para posicionarse con sus ideas y principalmente por que las desarrollaron.
Ahora yendo a lo concreto, creo de algún modo que Scrum no sirve más que para Gestionar un proyecto, es decir a niveles administrativos para seguimiento y control, tanto como para la estimación del tiempo y los recursos para la construcción, es decir que puede ser utilizado como modelo tremendamente útil en las PA Gerenciales, dependiendo de que grado de formalismo se requiera. Instruye en buenas prácticas pero no representa un proceso completo en si mismo. Scrum no facilita las herramientas utilizadas para el desarrollo en si, con lo cual mínimamente se debe utilizar un modelo de otro tipo como XP si prefieres seguir en lo Ágile.
Nosotros no nos hemos apartado de los Gant por que nos dan gran visibilidad y en forma ágil podemos ver los corrimientos o reubicamos los recursos con facilidad visual.

Por otro lado creo que la herramienta a utilizar e indistinta. Puedes tener todo tu Backlog en un Excel, en un aplicativo Access o una aplicación de construcción propia como nosotros (Lotus) y puedes tener cada uno de los Sprint en un MSProject o si prefieres el software libre en un OpenProj.

Siguen siendo los principios ágiles abiertos a múltiples interpretaciones, y las herramientas orientadas Ágiles tienden a ser cada día más complejas por que se ha dado cuenta el mundo que con pequeñeces no es posible generar inteligencia en la industria del software. Que usan para gestionar los riesgos? o para conocer la disponibilidad de los recursos IT? o para ponderar los costos? Seguramente herramientas de cualquier tipo que servirán al propósito.

transferencia al respecto de las Actividades de Soporte y Mesa de Ayuda:

 

Cinco puntos cruciales para establecer los lineamientos básicos de las actividades de Soporte y Mesa de Ayuda:

1. Adquisición de velocidad en las Operaciones

2. Mucha curiosidad para la adquisición de Conocimientos de Funcionalidad de Aplicaciones

3. Amplitud de Criterio para la adquisición de Conocimientos del Negocio asociado a las aplicaciones

4. Conocimiento de Circuito Normales y Ágiles Para Registración y Resolución de Incidentes y conveniencia de uso de uno u otro

5. Involucramiento en las Actividades de Testing para todos los Proyectos

6. Conocimiento y Monitorización de los Elementos de Despliegue

7. Conocimiento de las Actividades Genéricas que obligatoriamente pasan por SQA

8. Ser el Principal Referente para el circuito establecido para las Actividades UAT, Certificaciones, Garantías y Soporte

            Sin duda alguna que todos los elementos mencionados se expanden múltiples actividades individuales y grupales que deberemos organizar en forma conjunta y requieren de tiempo, aunque ya estamos en la senda del tiempo a partir del primer día de trabajo.

            Los puntos 1 y 2 son fundamental para cualquier transferencia que se realice al cliente al dar soporte operativo o resolver un incidente aislado. Del mismo modo el punto 3 se acopla a los dos primeros puntos.

            El punto 4 apuntala a las actividades de soporte y mesa de ayuda asegurando que nuestro servicio se brinda con la calidad de un proceso consensuado por la organización.

            El punto 5 es fundamental para incrementar la velocidad de aprendizaje de las funciones globales de las aplicaciones y las nuevas funcionalidades que son solicitadas por nuestros clientes o que generamos para potenciar un producto en particular. Por lo general son actividades cortas o que consumen poco tiempo, que inicialmente requieren de lectura de la documentación del proyecto y culminan con la ejecución de las pruebas formales definidas en los distintos planes de calidad.

            El punto 6 tiene mucho que ver con lo que formalmente se conoce como “Pruebas de Campo” donde se ejecutan verificaciones del correcto funcionamiento del producto a nivel de funcionalidades, servicios activos, agentes de procesamiento, reportes en pantalla, exportaciones, servicio de mailing y monitores de servicios. De este modo se puede garantizar que el producto desplegado en Ambientes de Producción es estable y puede iniciar fases de Garantías y Soportes sin que se presenten problemas inherentes a la implantación incorrecta.

Que repetir, que no repetir

· Que Repetir:

o Planificación y Estimación de Nivel 0 utilizando los elementos de juicio experto de los integrantes de PA (áreas de procesos) relevantes.

El problema con este punto es la no evolución de la Estimación de nivel 0 a estimaciones de mayor nivel. Esta actitud esta relacionada con la falta de seguimiento concreto de la evolución de la documentación y los distintos niveles de desgloses que se consiguen en fases de análisis, diseño y planificación QA. Las estimaciones terminan siendo exageradas o finalmente por recortes arbitrarios sin análisis concreto, las estimaciones terminan siendo cortas o subdimensionadas.

o Confección, evolución y seguimiento de documentación mínima e indispensable, que conforman las herramientas del proceso:

Minuta RQ / ERS / Documento de Análisis / Documento de Diseño y Arquitectura / Descripciones de Casos de Usos / Plan QA / Diseño de Pruebas (unitarias - integración - sistemas - UAT) / Seguimiento y métricas de pruebas / Matríz de rastreabilidad / Gestión del proyecto.

El segundo punto puede ser reemplazado por los conocidos “User Stories” pero de cualquier modo será necesario un buen grado de especificación para el desarrollador, donde se definen al inicio de la documentación los Puntos de Función (Interfaces Internas y Externas a nivel de procesos, funciones y eventos, Consultas a bases de datos que no ejecutan un caso de uso en si mismo, informes y reportes emitidos y otros elementos importantes que se deben detectar utilizando este tipo de análisis. El mismo tipo de análisis se hace en forma conjunta con SQA puesto que será la misma cantidad de entradas que utilizará para el desarrollo del Plan QA. Con esto desaparecerían los documentos de Análisis y Arquitectura & Diseño, puesto a que en el mismo “User Storie” estará descripto este tipo de elementos, sin que sea visto formalmente. Cada “User Storie” en si mismo será un UC descripto. A partir del reconocimiento de caminos alternativos y normales, mi equipo puede iniciar la fase de construcción de TC y los iremos evolucionando a medida que empecemos a disponer de prototipos de interfaces o maquetas del producto (versiones preliminares).

Es sumamente importante llegar hasta el punto de explotación de los Casos de Uso, ya que son los que le dan forma al componente a construirse y permiten al responsable de la planificación de la prueba determinar que pruebas podrían desencadenar un fallo en la estructura del sistema.

o Mejorar continuamente las iteraciones de desarrollo por módulos, de modo tal que favorezcan las planificaciones de ciclos de pruebas

El tercer punto solo puede ser atacado si hacemos buenas divisiones del producto. Inicialmente se arma un lote del producto con todos los entregables a nivel macro, pero sin dejar nada fuera. En una fase posterior se amplia la división pero se determinan grupos reducidos de entregables y se les pone fecha de inicio y fin para el desarrollo. Lo mismo para el testing. A medida que se entrega se prueba y a medida que se detectan fallos, se corrigen. El objetivo es que cada iteración se estabilice lo antes posible. Así con todas las iteraciones. A estos hitos solapados los usan mucho en metodologías Ágile.

Este punto apuntalaría a la mejora del proceso de formación de nuevos niveles de estimación.

Se que estas actividades son las que no aprecia nuestro cliente y tienen una gran carga horaria y los esfuerzos de formación de estos artefactos son importantes. Sin embargo no los podemos descartar de llano por que son los que reflejan cuanta inteligencia de ingeniería se le puso al proyecto y al producto.

· Que No Repetir:

o Desconocer avances reales en tiempo y porcientos

o No gestionar el proyecto y sus recursos por falta de interacción de la gerencia con miembros del equipo asignado. Implica: No gestionar con herramienta común para el conocimiento del equipo de los avances en horas y porcientos y prioridades

o Describir pobremente los casos de usos detectados

o No describir los casos de usos cuando se los detecta tardíamente. Implica: No ingresarlos a nuestro proceso por no actualizar la documentación

o No actualizar otra documentación relevante del proyecto como las ERS, Análisis y Diseño entre otras especificaciones del desarrollo

o Modificaciones significativas en las iteraciones al quitarse componentes y módulos en forma abrupta para alcanzar fechas límites establecidos. En caso de ser necesarias tales modificaciones todo el equipo debe reunirse para conocer los cambios y los impactos y no enterarnos sorpresivamente

o No evolucionar la estimación de nivel 0 a las estimaciones de nivel 1, 2 y 3 a pesar de que la documentación evoluciona en buen grado

o No utilización de una herramienta de gestión simple que permita tener distintas ventanas de información para los distintos niveles de personal de la empresa

o No generar anticipadamente los casos de pruebas del proyecto llegando a instancias medias y avanzadas del proyecto sin casos de pruebas

o No dejar Recursos Humanos disponibles para los ciclos programados de Pruebas Funcionales. El testing recae sobre una sola persona y eleva la Probabilidad de No Detección

o Ejecutar el testing en tiempos comprimidos sin que se respeten los ciclos planteados en la planificación. Esto hace que las pruebas no se hagan iterativas, incrementales ni regresivas. Testing/reporte defectos/resolución/verificación (sin ciclos)

o No confundir los distintos niveles de prueba, pretendiendo reemplazar pruebas de sistemas por pruebas de integración

o Corrección proactiva de defectos sin registración de los mismos y sin ingreso al proceso

o No carga de actividades en planilla de planificación

· Principalmente luego de que todos estábamos asociados al formato se hizo un gran esfuerzo en planificación y gestión

o Exceso de horas de trabajo para cumplir metas (no representa la calidad si la meta se alcanza)

· Es uno de los principales indicadores de la falta de calidad en el ciclo de vida de los proyecto y organizacional

o No establecer y definir el ambiente pruebas en los distintos niveles posibles

· Pruebas de Unidad solo son ejecutadas por algunos miembros y sin la utilización de criterios de la industria. No existe planificación antes de construir, ni se identifican fallos posibles o validaciones que son básicas y esa falta de proceso personal impacta directamente en versiones del sistema que prueba testing.

· Pruebas funcionales son diseñadas por los desarrolladores y aceptables sin dan la garantía necesaria para el desarrollador, pero no son el objeto de la prueba principal para el mismo. Son pobremente planteadas y se refuerza la falencia con la no generación de datos de pruebas y un ambiente pobremente desplagado (sin plan)

· No hay un plan de Integración para establecer con anticipación que elementos interactúan para generar un módulo testeable, donde se apliquen pruebas de regresión (funcionales) que aseguran que no se han degradado elementos anteriores a la modificaciones y que los cambios o construcciones nuevas son las correctas.

· Pruebas de sistema, en términos establecidos dentro de los ciclos planificados de testing, necesariamente previo a la implanntación del sistema en producción y en coordinación con el equipo designado en el plan.

· Que Considerar como factor de calidad

o Tiempo de Resolución por pedidos de Cambios, quejas o defectos

· En términos negociados según la verdadera capacidad de la organización

· Sin compromisos que requieran de esfuerzos extralimitados

o Características testeadas por puntos de función (cantidad de elementos que dan valor a las funcionalidades son testeados por cada Iteración en forma cíclica con un alto grado de control)

Conclusiones importantes

1. Se sugiere que todo el proceso debe ser vigilado y cumplido garantizando la circulación completa por el mismo.

1. La realidad es que el proceso sufre una gran compresión en las etapas de implementación y testing fuera de términos normales

2. Causas posibles son:

1. Innovación en momentos poco oportunos

2. Subestimación por desconocimiento de elementos más unitarios para estimar su construcción

3. Falta de aptitudes en el equipo de desarrollo

4. Mala gestión de La Gerencia que desconoce aspectos importantes como avances reales, esfuerzos consumidos entre otros factores

5. Mala distribución de tareas y actividades de implementación

6. Alta influencia de tareas de soporte que evitan que los recursos asignados tengan dedicación significativa

7. Falta de estimación de riesgos y sus impactos

8. Momentos de desconexión en la comunicación interna

§ No hay reuniones periódicas

§ Reuniones son llevadas a cabo cuando se detecta un riesgo que en realidad ya impactó en el proceso, proyecto y producto

§ No se sigue algún modelo aprobado por la industria

2. El equipo en general es altamente reactivo y muy poco gestionado

a. Las actividades de resolución de casos u Operativas se definen según el grado de importancia que le da el responsable del producto y suelen tener un gran margen de emotividad intentando en todos los casos transferir al resto del equipo, cuales serían las posibles reacciones el cliente o del Gerente (Julio)

b. La estabilidad en la participación de los desarrolladores involucrados en proyectos depende siempre del nivel emotivo que genere un incidente que requiera soporte, siendo removidos sin más durante horas o días sin considerar otros riesgos e impactos

c. Las prioridades de resolución de incidentes, liberación de entregables u operaciones de soporte, son definidas con el mismo grado de reacción emotiva y suele presentarse con demasiada frecuencia el pedido de ejecución de pruebas de verificación escuetas, rápidas o en “tiempo de ejecución de la solución”. Esta situación empobrece la independencia del área de Aseguramiento de Calidad y entorpece el accionar en contra de la liberación del entregable. La premisa parece ser “entregar a cualquier costo”.

d. Se suele proponer con rigurosidad la no resolución de defectos que pueden mal considerarse de severidad Leve o Mejora, cuando normalmente definen la calidad del producto a nivel de apreciación (primera impresión) del usuario. En situaciones de discusión se plantea la resolución en próximas versiones, pero no la exclusión.

Como verás hay una gran gama de elementos que hacen a nuestro día a día y creo que podemos hablar mucho tiempo sobre todo esto, pero lo más importante es tomar acciones para comenzar a eliminar vicios en primer lugar, falta de competencia luego y desconocimiento en tercer lugar. De este modo minimizaremos la apatía que existe en general, sobre todo cuando se proponen nuevos elementos de trabajo o modalidad u orden de prioridad, entre otro elementos que se suelen proponer.

El desconocimiento para mi es el principal enemigo. Pocos tenemos una idea de que es un modelo de trabajo y menos aún sabemos que hacer para implantarlo como parte de la cultura empresarial. Tal es así que no es posible ni encarar una conversación que inste a mejorar el proceso personal y general por que inmediatamente surge alguna cuestión que la desvía. Por lo general estas cuestiones tienen que ver con situaciones de fracaso permanente en el pasado.

Paso de mando y control a la auto-organización

Olvidarnos del modo tradicional demando y control no es una tarea sencilla, pero hay técnicas de suplantación para migrar a una modalidad de auto-gestión. Quizás podemos dar los pasos iniciales si tenemos en mente que en lugar de "gestionar" el proceso en el modo tradicional, la gestión puede ayudar mucho más por:

- Que se trata de la realización de los equipos para descubrir y hacer las mejoras, no de hacer gestión. 
- Dar a los equipos la responsabilidad de gestionar y mejorar su propia proceso personal, así como la libertad y la autoridad para hacerlo. 
- El establecimiento de un ambiente que alienta activamente a los equipos a ser totalmente honesto acerca de sus problemas y los obstáculos.

Buscar estos títulos y leerlos para mejorar la comprensión de los conceptos:

- "PeopleWare" - de Marco / Lister. Leer este primero.
- "Cómo ganar amigos e influir en las personas" - Dale Carnegie
- "Los siete hábitos de la gente altamente efectiva" - Steven Covey
- "Waltzing con osos" - de Marco / Lister
- "El 8 º hábito" - Covey
- "Convertirse en un Líder Técnico" - Weinberg
- "Software de Gestión de la Calidad - Volúmenes I-III" - Weinberg
-  "Resolución de problemas de liderazgo y la Conferencia AYE"
- "La Práctica de la Gestión" - Peter Drucker
- "Deathmarch" - Ed Yourdon
- "El Plazo" - Demarco
- "Nuestro emperadores no tienen ropa" - Alan Weiss
- "La gestión de Peak Performance" - Alan Weiss
- "Cultura Corporativa y la ejecución" - John P. Kotter

 

Las reuniones de trabajo

Las reuniones, valga el juego de palabras, están a la orden del día. Son frecuentes en todos los ámbitos. La reunión permite la comunicación de ideas y la participación de todos en las decisiones. El espíritu democrático es quien las impulsa y promueve en la actualidad en todos los órdenes de la vida.

Hay reuniones muy formales, que han de someterse a un previo y riguroso orden del día. Otras reuniones pueden permitirse ciertamente ser más informales. Pero la participación en cualquier tipo de reunión debe seguir unas ciertas pautas de comportamiento si se pretende que sean  interesantes y productivas.

La sinergia del grupo

La sinergia de un grupo se expresa así en términos matemáticos: 

2 + 2 > 4

Dos más dos suman algo más que cuatro. Esto significa que el rendimiento del grupo es superior a la simple suma de las contribuciones individuales. Lo cual es fantástico: un buen grupo produce plusvalía, genera sinergia.

Quizás esté implícito en el dicho popular, pero no es sólo que cuatro ojos vean más que dos, es que juntos pueden llegar a descubrir aspectos que ninguno de ellos sería capaz de ver por su cuenta.

La gente rinde más cuando trabaja en equipo, cuando se reúne y pone en común sus conocimientos y sus opiniones.

Lógicamente hay que tener en cuenta determinadas normas a la hora de reunirse. No vale la total espontaneidad pero tampoco hay que someterse a un riguroso procedimiento. Las reglas no tienen que echar por tierra la alegría natural que sienten, al estar juntos, quienes comparten objetivos comunes y disfrutan de la amistad.

Hay que evitar los prejuicios

Para que una reunión no derive en discusiones estériles, se recomienda no empezar por proponer cada uno su propia alternativa.

Sin embargo, a primera vista parecería lógico el procedimiento contrario: cada participante en la reunión habría definido antes su postura y luego la defendería en el grupo aportando los hechos que la apoyan y valorando los criterios que la justifican.

Pero seguramente la reunión terminaría en tablas. Cada uno se confirmaría en su propuesta inicial de solución y volvería a llevársela a casa. A menos que alguien usara de un gran poder de convicción para imponer su criterio.

Los miembros de un grupo harán bien en estudiar previamente el tema que van a tratar en la reunión, pero no han de formalizar conclusiones que serían prematuras. Hay que evitar los prejuicios y todo tipo de juicios poco fundados. Antes de la reunión sólo conviene desbrozar el camino, abrir  horizontes, documentarse en datos y hechos para poder aportarlos luego al grupo.   

El método científico de toma de decisiones

Interesa mucho que las decisiones que se toman en las reuniones sean las mejores. Por eso se propugna un procedimiento que recuerda la sistemática que observan los investigadores científicos.

Es la misma que suele seguir cualquier médico, que empieza por recoger información (los síntomas que le cuenta el enfermo, los datos que percibe mediante su exploración), llega luego a concretar un diagnóstico y finalmente busca entre los posibles remedios el que mejor se adecua.

El método científico de resolución de problemas propone este esquema de trabajo:

1. definir el problema

2. formular las posibles soluciones

3. elegir una alternativa

Y lo que más importa, que todo este proceso se siga en la reunión, abierta a la intervención de todos, sin juicios previos, tratando de ser objetivos y de descubrir entre todos la mejor solución.

La definición del problema

Es el primer paso y el más complejo. Un buen análisis del problema supone ya un avance importante en su solución.

La definición del problema empieza por constatar lo que ocurre, recopilando datos y hechos, pasa luego por definir lo que debería ocurrir, de acuerdo con los principios y los objetivos que asumen los miembros del grupo, y culmina en observar la desviación producida entre lo que ocurre y lo que debería ocurrir, entre lo que es y lo que debería ser.

· LO QUE OCURRE (recopilar hechos y datos)

· LO QUE DEBERÍA OCURRIR (determinar el ideal)

· la desviación (definir el problema)

La realidad se compara con la utopía y en el contraste se perfila el problema.

No cabe duda que la objetividad del sistema se vuelve subjetividad, en tanto que el arquetipo lo establece el propio grupo. Porque ese “deber ser” se origina en normas creadas por el grupo o en normas externas que el grupo asume como propias.

Es importante profundizar en el análisis y llegar a precisar las causas de la desviación. En muchos supuestos, el estudio de las causas va a orientar eficazmente la elección de la mejor solución, la que ataca la verdadera raíz del problema.

La formulación de alternativas

Es la fase más creativa del proceso, el momento de dejar libre paso a todas las soluciones posibles. No han de ponerse cortapisas a la imaginación. No ha de frenarse la espontaneidad de nadie. No valen las críticas en este momento. Hay que respetar todas las ideas. Ya habrá tiempo luego de entrar a valorarlas.

Una idea conduce a otra. Como al coger las cerezas, una te lleva a otra. Aunque esa primera opción no valga, aunque sea evidentemente una mala solución, puede servir sin embargo de plataforma para llegar a otra más válida. Con frecuencia, la mejor idea está escondida y sólo aparece después de que algunos sugieran otras varias “ideas-puente”.

Desde el punto de vista de la actitud con la que se ha de encarar cada etapa del proceso, se puede hablar de objetividad en la definición del problema, de creatividad en la búsqueda de soluciones y de actitud crítica y rigurosamente lógica en la toma de la decisión final.

Hay que encender la luz verde del semáforo a la hora de recopilar hechos y datos y en el momento de formular alternativas. Pero ha de tornarse roja la luz cuando se trata de valorar las distintas opciones. No deben confundirse ni mezclarse las actitudes, sino proceder sucesivamente a su utilización.  

El coste de la solución

La toma de decisiones es el objetivo de la reunión. Se ha planteado un problema y se han propuesto diversas soluciones. Es hora de elegir la mejor. Hasta este momento, el proceso seguido ha sido de índole intelectual, mientras que ahora se llega a un acto volitivo. El razonamiento anterior culmina finalmente en una decisión.

Pero hay que ser conscientes de que un auténtico problema no tiene una solución plenamente satisfactoria. Las soluciones suelen suponer la creación de otros problemas distintos. Es lo que se llama el coste de la solución. Si no hay coste se puede decir que no hay problema, todo lo más un simple malentendido fruto de una información escasa o errónea. 

Al resolver un problema, hay que ponderar el punto en el que se alcanza un máximo de ventajas con el mínimo de inconvenientes. Si se pretenden todas las ventajas, haciendo desaparecer totalmente el problema, se pueden provocar consecuencias negativas más graves que las que entrañaba el mismo problema primitivo. Es cuestión de prudencia, una virtud absolutamente necesaria para tomar buenas decisiones.

LA TOMA DE DECISIONES EN GRUPO

Existe toda una serie de vías para la toma de decisiones en un grupo.

Por imposición de uno. Es lo que se podría llamar una decisión dictatorial. La reunión ha servido para que el que detenta el poder en el grupo tome su decisión individual y los demás miembros se adhieran a ella.

Por imposición de una minoría. Una situación similar a la anterior. En el grupo hay una minoría que se une para imponer su criterio a la mayoría. En el lenguaje político se hablaría de oligarquía.

Por mayoría. El grupo asume como propia la decisión que sustenta la mayoría de sus miembros. Normalmente, los individuos que se suponen en mayoría son los que proponen la votación, en aras de lograr más eficacia o por razones democráticas. Aunque a veces no se llega a votar y basta la presión social que ejerce la mayoría para que los demás acaten su solución. Influye la conveniencia de llegar a un pronto acuerdo.

Por negociación. Los criterios se manifiestan claramente distintos, pero se llega a un pacto, se acuerda una solución de  compromiso, cediendo parte de sus opiniones y de sus derechos. A nadie convence por completo la solución adoptada. Pero todos salen moderadamente satisfechos de la negociación y aceptan el pacto. Los intereses se mantienen contrapuestos.

Por concertación. Los criterios fueron inicialmente dispares, pero tras la confrontación de opiniones, el grupo ha llegado a un consenso. Se ha llegado al convencimiento y todos asumen como propia y no impuesta la solución que finalmente adopta el grupo. Los intereses eran compatibles y se han vuelto afines.

Por unanimidad. Los intereses son ahora coincidentes desde un principio. El acuerdo se toma sin esfuerzo, todos opinan de igual forma.

Por la no oposición de nadie. No es una vía tan extraña. La reunión se ha alargado quizás demasiado o el tema no afecta a intereses vitales. Alguien propone algo y nadie se opone. Hay quien llama “plop” a esta forma de tomar decisiones, quizás porque la onomatopeya recuerda la caída a plomo de una gota en mitad de un estanque, cuyo movimiento ondulatorio se propaga silenciosamente a toda la superficie.

A nadie se le escapa que las imposiciones son funestas, que el acuerdo por mayoría no es una solución perfecta, que el pacto sólo es un mal menor, que el ideal bien puede ser la unanimidad, pero que el verdadero mérito de una reunión es llegar vía concertación al consenso.  

Escuchar mil veces sin que algo lo silencie

Surgen muchos pensamientos en mí a partir de la frustración del momento, permitiéndome asumir en parte la falla de nuestra actividad del día de hoy. Es fundamentalmente una falla de proceso por que se obvió al menos un elemento.

No faltaron de mi parte las preguntas necesarias y de base para iniciar los procedimientos de prueba.

No faltó mi criterio profesional para analizar cada uno de los pasos que se dieron tanto para las pruebas locales como para las pruebas remotas.

No faltó comunicación ni mucho menos consenso.

No evitamos desplegar cada una de las instancias técnicas que fueran necesarias para intentar llegar a un fin esperado.

Falló el proceso por que fallo al menos una cosa fundamental. Pero la intención es develar más elementos que entorpecen nuestras acciones y facilitan la omisión.

Tengo que marcar la diferencia entre haber cumplido con todos lo requerido para un proceso estándar y haber dejado de lado algo, cada vez que aquí se levanta una idea que minimiza tus planteos del proceso, por cumplimentar tus pedidos concretos de soluciones rápidas, efectivas y robustas. Esto debo hacerlo sin caer en la incoherencia de decirles que no tienen razón, pero tienen razón. Intento ser firme pero a su vez comprendo el planteo de cada uno al que le toca sufrir lo inconexo de un proceso que no se termina de amoldar a una realidad percibida, diferente.

Al fin de la reunión se planteó como inalcanzable considerar todos los posibles fallos que son heredados de una aplicación a la cual se intenta mejorar con poco y nada.

Sin embargo me opongo a la naturaleza del pensamiento que asevera tal situación y entiendo que hemos contado con todos los elementos necesarios, principalmente tiempo, más nos hizo falta dejar de temer a hacer las cosas correctamente. Esto implica dedicar el tiempo adecuado al análisis del problema, al planteo de la solución, a las verificaciones en todos sus niveles y a la aceptación de que a pesar de todo se puede presentar un defecto.

Pero si hiciéramos todo esto, ese posible defecto sería resuelto en un soplo y no nos dolería un esfuerzo, una discusión, una degradación profesional ni una lamentación.

Esto que menciono incluye a la Alta Gerencia como el elemento de mayor peso, por que se asume por parte del equipo, que las soluciones que pides deben ser reitero, rápidas, efectivas y robustas, pero nunca se cuenta con el tiempo para los elementos que se necesitan. O bien se asume lo que es más fácil (que termina siendo lo peor) ¿Sigue siendo el tiempo nuestro principal enemigo?

En líneas anteriores digo que tuvimos todos los elementos necesarios, principalmente tiempo, solo que el tiempo sufre una transformación extraordinaria cuando se lo utiliza de un modo u otro. El tiempo tiene otro precio cuando estamos intentando no quemarnos las manos con una braza que nosotros mismos encendimos por no respetar los elementos de un proceso, independientemente de los supuestos “no puede ser más de dos horas”.

En este sentido, debo oponerme a ser parte de cualquier proceso que implique mi aceptación si no tiene todos los componentes necesarios, principalmente por que cada día más me parezco al equipo y mucho menos a mi mismo, a mi rol. Si esta postura implica retrasos en los tiempos de entrega, y no es aceptable por su naturaleza, será que no hace falta mi participación como me la planteaste en sus orígenes.

Hoy concluí la charla con mis compañeros no solo marcando las diferencias que menciono antes en este mismo mensaje, sino imponiendo que nadie me pida que acepte seguir con una fase sin haberme mostrado la anterior. No me pidan pruebas de sistemas sin la evidencia de las pruebas unitarias o no me hagan participar de las soluciones técnicas que no puedo avalar, por que siempre tengo una visibilidad muy reducida y siempre la tendré en ese mismo sentido.

Acepto en parte todo por que soy o fui el principal proponente de los cambios que hoy vivimos y quiero palparlos hasta con los errores y principalmente con ellos.

Aquí se evidencian muchas cosas estimado Julio. No es la falta de interés en el trabajo, no es poco involucramiento, no es desinteligencia, tampoco mala voluntad y sigo cuestionando, no es “falta de responsabilidad”. Se evidencia un antiguo modo de trabajo reaccionario contra un modelo que nos exige ser pensantes, concluyentes e interdependientes. El llamado “proceso corto” nos esta cobrando en cada proyecto y más de un par de veces, discusiones dolorosas.

No podemos plantear la habilitación de un ambiente que no existe, sea para pruebas, para desarrollo o para despliegue, sin una estrategia que no surja en un momento caliente donde ya todo ha fallado. No es sano plantear el involucramiento de cuanto elemento se mencione por que nos sirvió en un instante o por que parece, sin análisis de todo, que nos va a venir como anillo al dedo.

Volviendo en concreto a nuestras experiencias de hoy, particularmente yo desconocía todo el contexto fuera completo. ¿Como puedo adivinar tantas cuestiones que por años ustedes manejan? Pusiste en el mensajero “que poca curiosidad”. Solo admito eso si mi mente estuviera chata después de varios años aquí en la organización y no me dedicara con entusiasmo a los que hago.

Pero mi condición es otra. Con muchos elementos que no pensaba utilizar, intento guiar a un equipo que no quiere ser guiado, pero prefiere ser golpeado por los fallos y por las críticas duras. He intentado colaborar en muchos aspectos, desde facilitar las planificaciones, ayudar en los seguimientos hasta intentar tener historia, pero no debo perder el foco en lo que vine a hacer.

Entonces quiero enfocarme y seguir ideando las mejoras, proponerlas, materializarlas, trabajarlas, sufrirlas y finalmente, disfrutarlas.

Quiero y necesito que sigamos agregando elementos de trabajo como herramientas, metodologías y procesos para algún día ser parte de una verdadera compañía que ayudé a moldear.

Espero que este mensaje no sea tomado a la tremenda ni sea de muy mal gusto para alguien, pero por ahí son cosas que quiero decir hace rato y no veo como hacerlo en un momento propicio donde se me pueda escuchar mil veces sin que algo lo silencie.

Metodología Métrica V3 - Técnicas y Prácticas

 

Wikipedia define: MÉTRICA es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de información. Promovida por el Ministerio de Administraciones Públicas del gobierno español para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas.

Es una metodología propia basada en el Modelo de Procesos del Ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination)

Ver Definición de Métrica en Wikipedia

• Se define con total claridad que modelo esta orientado al proceso, donde deben considerarse los Procesos Claves:
• (PSI) Planificación de Sistemas de Información
• (DSI) Desarrollo de Sistemas de Información, que a su vez se dividen en cinco (5) subprocesos:
• (EVS) Estudio de Viabilidad del Sistema
• (ASI) Análisis del Sistema de Información
• (DSI) Diseño del Sistema de Información
• (CSI) Construcción del Sistema de Información
• (IAS) Implantación y Aceptación del Sistema de Información
• (MSI) Mantenimiento del Sistema de Información

Todos procesos genéricos en cualquier Software Factory.

• El modelo cuenta con cuatro (4) Interfaces cuyas actividades están orientadas a la mejora y perfeccionamiento de los procesos principales, arriba mencionados:
• (GP) Gestión de Proyectos
• (SEG) Seguridad
• (CAL) Aseguramiento de Calidad
• (GC) Gestión de Configuración

 

• Se consideran las siguiente Técnicas:
• Técnicas de desarrollo (Casos de Uso, Diagramas de Clases, Diagrama de flujo de datos,...)
• Técnicas de gestión de proyectos (Técnicas de estimación, Staffing Size, Planificación,...)
• Prácticas (Análisis de impacto, Presentaciones, Prototipado,...)...

Técnicas y prácticas

• Introducción
• Técnicas de desarrollo
  • Análisis coste/beneficio
  • Casos de uso
  • Diagrama de clases
  • Diagrama de componentes
  • Diagrama de descomposición
  • Diagrama de despliegue
  • Diagrama de estructura
    • Diagrama de flujo de datos (DFD)
    • Diagrama de interacción
    • Diagrama de secuencia
    • Diagrama de colaboración
    • Diagrama de paquetes
    • Diagrama de transición de estados
• Modelado de procesos de la organización
  • SADT (Structured Analysis and Design Techniques)
  • Modelado entidad/relación extendido
  • Normalización
  • Optimización
  • Reglas de obtención del modelo físico a partir del lógico
  • Reglas de transformación
• Técnicas matriciales
  • Técnicas de gestión de proyectos
  • Técnicas de estimación
  • Método Albretch para el análisis de los puntos de función
  • Método Mark II para el análisis de los puntos de función
  • Staffing Size (Orientación a objetos)
• Planificación
  • Program Evaluation & Review Technique - PERT
  • Diagrama de Gantt
  • Estructura de descomposición de trabajo (WBS – Work Breakdown Structure)
  • Diagrama de extrapolación

El Soporte - Gestión de Mesa de Servicios e Incidentes

Debido a que desde mis primeras incursiones en la informática hice soporte técnico y soporte de sistemas, me interesa mucho desarrollar esta temática y ir incorporando herramientas que me ayuden en buen grado a desplegar las mejores soluciones orientadas al cliente, refiriéndome al cliente interno como al usuario final.

Para iniciar voy a poner a consideración este artículo que encuentro interesante como puntapié inicial El Soporte - Gestión de Mesa de Servicios e Incidentes 

Espero que alguien lo lea y haga sus comentarios en mi blog.

Estándar COBIT

Fuertes tendencias

Algunas fuertes tendencias se han marcado a lo largo de la historia de la humanidad, yo hoy quiero destacar estas:

• A desconocer un modelo o varios para establecer un proceso estándar para la organización.
• A pensar que el proceso debe ser utilizado por quienes lo establecen y quienes controlan su seguimiento.
• A creer que uno es no participe del proceso y obviar elementos básicos, mínimos y de alto impacto a corta data.
• Al trabajo sin orientación, sin procedimiento, sin organización, sin planificación y sin seguimiento.
• A criticar duramente a los que piensen en los cambios para mejorar
• A no participar ni hacer aportes para la mejora continua.
• Al desarrollo sin evidencias .
• A la integración agolpada sin planificación.
• Al testing suelto, sin métricas, sin orden.
• A los despliegues sin garantías.
• A que todos los pasos se ejecuten sin conciencia de las interrelaciones de áreas.
• Al desconocimiento de las cargas laborales.
• Al solapamiento de entregas.
• Al cambio de requerimientos sin gestión.

A eso le puedes sumar algunas pocas cosas más pero que son más que suficiente para que no tengas nada mientras crees que tienes mucho.

Técnicas para la mejora y resolución de problemas

 

Ø Brainstorming o tormenta de ideas: Es una técnica de grupo para generar ideas originales en un ambiente distendido. Persigue buscar el máximo número de ideas relacionadas con un concepto. Se basa en el respeto de todas las ideas de los participantes con la finalidad de estimular la participación y creatividad de todos los miembros del grupo.

Ø Los cinco por qués (Five whys): Técnica sistemática de preguntas utilizada en la fase de análisis para buscar posibles causas de un problema. Consiste en ir preguntando ¿por qué? hasta encontrar la causa raíz de los problemas. Normalmente es necesario preguntar cinco veces, de ahí el nombre de la herramienta, pero este número tan sólo es orientativo. Una vez que sea difícil para el equipo responder al "porqué", el origen del problema habrá sido encontrado.

Ø Reingeniería: La reingeniería de procesos es una técnica en virtud de la cual se analiza en profundidad el funcionamiento de uno o varios procesos dentro de una empresa con el fin de rediseñarlos por completo y mejorar radicalmente.

Ø Ciclo PDCA (Plan, Do, Check, Act) o Ciclo de Deming: Ciclo de planificación, realización, control y actuación que actúa como guía para llevar a cabo la mejora continua y lograr de una forma sistemática y estructurada la resolución de problemas. En este ciclo se basa el principio de mejora continua de la gestión de la calidad, es una de las bases que inspiran la filosofía de la calidad.

· Plan (P),
· Do (D),
· Check (C),
· Act (A).

Fuente:
Sangüesa Sánchez, Marta. Manual de Gestión de la Calidad. Cátedra de Calidad de Volkswagen. Universidad de Navarra

Ø Las 7 Herramientas:
Las siete herramientas tienen su origen en Japón, cuando W. Edwards Deming, a principio de los años 50 comenzó a inculcar a los japoneses los principios del análisis estadístico. Los japoneses recopilaron entonces unas técnicas o herramientas que pudieran ser usadas fácilmente por cualquier persona de la organización:

• Hoja de recogida de datos, hoja de registro o verificación: Herramienta utilizada para la recopilación ordenada y estructurada de datos relevantes que se generan en los procesos. Los datos recogidos con este instrumento suelen ser empleados posteriormente para el desarrollo de otras herramientas.
• Diagrama de flujo (Flow Chart): Es una representación gráfica de los pasos en un proceso. Es un instrumento muy útil para representar secuencias de pasos complejos. Su objetivo es determinar el funcionamiento real de un proceso para producir un resultado, este puede ser un producto, un servicio, información o una combinación de los tres.
• Histograma: Es un diagrama de barras que muestra de forma visual la distribución de frecuencias de datos cuantitativos de una misma variable. En el eje de abcisas se representan las clases o características y en el de ordenadas la frecuencia. Los histogramas suelen elaborarse mediante hojas de recogida de datos.
• Diagrama de correlación o de dispersión: Gráfico que muestra la existencia o no de una relación entre dos variables.
• Diagrama de Pareto: Es una forma particular de un histograma. A diferencia del histograma ordena los fallos no sólo respecto a su número, sino también respecto a su importancia relativa, es decir, podemos separar los problemas importantes de los triviales de modo que un equipo sepa a dónde dirigir sus esfuerzos.

Para interpretar esta herramienta se aplica la Regla de Pareto: Esta nos dice que hay muchos problemas sin importancia frente a solo unos graves, ya que por lo general, el 80% de los resultados/fallos totales se originan en el 20% de los elementos.

• Diagrama de Ishikawa, diagrama causa-efecto o diagrama de espina de pez: Representación gráfica de las relaciones lógicas que existen entre las causas y subcausas que producen un efecto determinado. Es una herramienta muy útil para desarrollar un análisis estructurado o discusión sobre un problema o tema concreto.

Fuente:
DEIOC, Departamento de estadística, investigación operativa y computación. Universidad de la Laguna

- Cartas de control de calidad: Representación gráfica de los distintos valores que toma una característica correspondiente a un proceso. Sirve para observar la evolución de este proceso en el tiempo y compararlo con unos límites de variación fijados previamente que se usan como base para la toma de decisiones.

Ø Las 7 nuevas herramientas:
Estas siete nuevas herramientas de gestión y planificación complementan a las anteriores. Nacen como un conjunto de técnicas para apoyar a gestores y directivos de las organizaciones para el mejor funcionamiento de la gestión de la calidad total para una empresa. En los años 70 la Unión Japonesa de Científicos e Ingenieros (JUSE) recopiló las siguientes herramientas como "las siete nuevas herramientas":

• Diagrama de afinidad o método KJ: Herramienta empleada para organizar la información obtenida en un brainstorming. Está diseñado para reunir opiniones, hechos e ideas sobre áreas que se encuentran desordenadas. Ayuda a agrupar elementos relacionados de manera natural. El resultado es la unión de cada grupo alrededor de cada concepto o tema.
• Diagrama de relaciones: Esta herramienta se emplea, al igual que el diagrama de afinidad, en la fase de planificación de la mejora de la calidad. Se utiliza para la exploración e identificación de las relaciones causales existentes entre distintos factores. Está especialmente indicada para aquellos casos en que se pretendan identificar relaciones complejas de causa-efecto o medios-objetivos.
• Diagrama de árbol: Herramienta cuya forma recuerda a la del organigrama funcional de una empresa, empleada para ordenar de forma gráfica las distintas actuaciones que se deben llevar a cabo para solucionar el problema o situación de análisis.
• Diagrama matricial: Se utiliza para ordenar gráficamente grupos de datos representando los puntos de conexión lógica existentes entre ellos. Las disposiciones más comunes son: diagrama matricial en “L”, diagrama en “A” o matriz triangular, diagrama matricial en “T”, diagrama matricial en “Y” y diagrama matricial en “X”.
• Diagrama matricial para el análisis de datos o matrices de priorización: Es una combinación de las técnicas de diagrama de árbol y diagrama matricial. Se emplea para la toma de decisiones en base a la priorización de actividades, temas, características de productos, etc., según criterios de ponderación conocidos.
• Diagrama de decisión: Herramienta cuyo objetivo es identificar, representar y eliminar todos los obstáculos posibles que pueden surgir en el proceso de implantación de soluciones a un problema.
• Diagrama de flechas: Es una representación gráfica en forma de red de la planificación de un proyecto, mostrando las relaciones existentes entre las distintas actividades. Para poder emplear esta herramienta necesitamos conocer las actividades o tareas correspondientes al proyecto en cuestión, su secuencia y su duración.

Técnicas para la planificación

Ø Benchmarking: Es un proceso sistemático y continuo para la medición o evaluación de las características técnicas o de calidad de una empresa comparando los resultados con sus competidores. Su objetivo es buscar información para la mejora organizativa de la empresa.

Ø DEE, Diseño de Experimentos o DOE, Design of Experiments: Herramienta empleada para optimizar los procesos. La aplicación de un DEE supone una reducción del número de pruebas y un abaratamiento en el desarrollo de los distintos productos.

Ø AMFE Análisis Modal de Fallos y Efectos o FMEA Failure Mode and Effects Analysis: Consiste en un método preventivo, que utilizadode forma sistemática permite identificar y analizar las causas y los efectos de los posibles fallos y las carencias en el producto o proceso. Su objetivo último es la aplicación de las necesarias acciones correctoras para reducir dichos efectos.
Ø QFD, Quality Function Deployment, Despliegue de la Función de Calidad: Se trata de una técnica que identifica las necesidades y exigencias del cliente. Su objetivo es incorporar los deseos y exigencias del cliente al proceso productivo de una empresa, desde su origen hasta su venta. Reduce los ciclos de desarrollo de productos, aumentando la calidad y disminuyendo los costes.

Técnicas para el control

Ø CEP, Control Estadístico de Procesos o SPC, Statistical Process Control: Esta herramienta sirve para asegurar la calidad de los productos controlando los procesos. Lo importante es la prevención de los posibles defectos antes de ser fabricado el producto. El CEP se basa en la utilización de gráficos de control adecuados a las características y la distinta naturaleza del proceso valorado.
Ø Índices de capacidad:

• Índice de capacidad de máquina: Sirve para valorar la capacidad de calidad de una máquina comparando la dispersión generada por ésta, con las tolerancias del parámetro de estudio.
• Cm: Hace una comparación entre la dispersión de la máquina y las tolerancias del parámetro.
• Cmk: Valora la dispersión y el centraje.
• Índice de capacidad de proceso: Método usado para valorar la capacidad de calidad de un proceso con respecto a un parámetro y periodo de tiempo fijados.
• Cp: Compara la dispersión del proceso con las tolerancias del parámetro.
• Cpk: Cumple la misma función que el índice Cp y valora también el centraje.

Ø Auditoría de calidad: La norma UNE-EN ISO 9000:2000 define textualmente a la auditoría de calidad como:
"Proceso sistemático, independiente y documentado para obtener evidencias de la auditoría y evaluarlas de manera objetiva con el fin de determinar la extensión en que se cumplen los criterios de auditoría".
Fuente: UNE-EN ISO 9000:2000 Apartado 3.9.1.

Se pueden diferencia por su ámbito de aplicación (auditorías de producto, auditorías de proceso y auditorías de sistema) o por su ámbito de actuación (auditorías internas y auditorías externas).

LOGs para nuestros desarrollos de Software

El control de logs en una aplicación que generamos es tan importante como lograr cumplir con las expectativas de rendimiento y almacenamiento en los aspectos funcionales y no funcionales del sistema.

Por tal motivo sugiero que den una mirada al artículo Registrando sucesos a nuestro criterio donde se muestran los lineamientos básicos de como registrar sucesos en los logs, utilizando la aplicación freeware SYSLOG.

Accedan también a la información proporcionada por Wikilearning en la monografía Control, Administración e Integridad de Logs

Que les sea útil.

QC STORY

El método de solución de problemas, llamado por los japoneses "QC STORY", es una pieza fundamental para ejercer el control de calidad por el método PCDA gerencial

EL CONTROL DE CALIDAD Y LA QC STORY

el control de calidad consta de etapas para su aplicación, la solución de problemas "QC STORY" es aplicable en el sentido de:

• Planeación de la calidad: Consiste en el establecimiento de los estándares de calidad para la satisfacción de las personas.
• Mantenimiento de la calidad: Consiste en la conservación de los estándares de la calidad con el fin de establecer una "Calidad estándar", un "costo estándar", una "Atención estándar", una "moral estándar" y una "Seguridad estándar", es aquí donde se utiliza la "QC STORY" para eliminar los desvíos crónicos de calidad.
• Mejoras de calidad: Consiste en el establecimiento  de nuevos estándares de calidad con el objeto de obtener un producto o servicio mejor. En este caso la "QC STORY" para redireccionar el proceso.

LA SOLUCIÓN DE PROBLEMAS COMO MÉTODO GERENCIAL

La gran mayoría de las decisiones gerenciales se basan en el sentido común y en la experiencia de los responsables del manejo empresarial. El análisis que se haga del problema es justamente lo que hace que se tomen las decisiones correctas y se encuentre una solución viable.

PCDA: Es el modelo gerencial de solución de problemas para todos los recursos de la empresa

Cualquier decisión que se tome en cualquier nivel, frente al gerenciamiento de la organización , debe estar orientada para la solución de problemas y por ende precedida por un análisis de proceso conducido de manera secuencial, recurriendo a todas las personas que entren dentro del proceso exigiendo un análisis completo de las tareas que cada uno realiza, siguiendo el método de manera fiel.

ANÁLISIS DE PROCESOS

Las organizaciones tienen problemas frecuentes que afectan la productividad y la calidad de los productos perjudicando así su posición frente a la competencia, si no se pone especial atención a esto la empresa tenderá a desaparecer en un corto plazo. Los gerentes deben alimentar constantemente el conocimiento y experiencia que tienen con hechos y datos que les hagan tomar las decisiones adecuadas para ejercer una dirección correcta, por ello es que surge el "Análisis de procesos" como una herramienta para la solución de problemas.

Método y herramientas del análisis de procesos

El análisis de procesos es una secuencia de procedimientos lógicos basado en hechos y datos que tiene como objetivo localizar la causa fundamental de los problemas y es utilizado en el gerenciamiento interfuncional de la empresa para hallar soluciones definitivas y alcanzar las metas directivas.

El análisis de procesos debe ser practicado por todas las personas de la empresa y es una de las actividades mas importantes del "Control Total de Calidad". En este análisis deben intervenir también todos los recursos científicos y tecnológicos de los que la empresa disponga.

Las decisiones gerenciales no deben ser tomadas sin que sean fundamentadas en un análisis de procesos, basados en hechos y datos, a través del método de solución de problemas.

APLICACIÓN DEL MÉTODO

MODELO DE SOLUCIÓN DE PROBLEMAS "QC STORY"  

PCDA
FASE
OBJETIVO

P
Identificación del problema
Definir claramente el  problema y reconocer su importancia.

P
Observación
Investigar las características específicas del problema con una visión amplia y desde diferentes puntos de vista.

P
Análisis
Descubrir las causas fundamentales.

P
Plan de acción
Concebir un plan para bloquear las causas fundamentales.

D
Acción
Bloquear las causas fundamentales.

C
Verificación
Verificar si el bloqueo fue efectivo.

A
Estandarización
Prevenir la reaparición del problema.

A
Conclusión
Recapitular todo el proceso de la solución del problema para futuros trabajos.

Comentario final

El método de solución de problemas "QC STORY" descrito anteriormente, es el método japonés de la JUSE (Union of Japanese Scientists and Enginers) y ha tenido una buena aceptación en el mercado latinoamericano y se le dio el nombre de "molino de viento". Para su aplicación el profesor Falconni recomienda para su aplicación las siguientes normas:

1. Utilizar el método en problemas pequeños y simples a nivel de cada sección.

2. Seguir el método fielmente.

3. Durante la presentación del problema se debe destacar la etapa del método que está siendo analizada.

4. Deben hacerle las observaciones necesarias a cada etapa del proceso.

Contexto del control de calidad: Debe garantizar la calidad de los productos, controlando los procesos para conseguir la satisfacción de los clientes .

 

Copia fiel de Gestipolis

Herramientas básicas para la resolución de problemas

La evolución del concepto de calidad aplicado a la industria, y ahora a los servicios, muestra claramente que se ha pasado de una etapa, en donde la calidad era aplicada totalmente al control realizado al final de las líneas de producción, a otra donde aplicamos calidad total a todo dentro de la organización. Por ende, ya se habla de calidad de vida en el trabajo, calidad de vida en los servicios y calidad ambiental.
Recordemos que el concepto de calidad hoy en día, es aplicado en el ámbito industrial, como el logro de hacer las cosas bien la primera vez. Y se aplica control de calidad sobre las operaciones desde el diseño. Hasta que se obtiene el producto final e inclusive se habla de la calidad en la atención al cliente.
El camino que nos lleva hacia la Calidad Total crea una nueva cultura, establece y mantiene un liderazgo, desarrolla al personal y lo hace trabajar en equipo, además de enfocar los esfuerzos de calidad total hacia el cliente y a planificar cada uno de los pasos para lograr la excelencia en sus operaciones.
El hacer esto exige vencer obstáculos que se irán presentando a lo largo del camino. Estos obstáculos traducidos en problemas se deben resolver conforme se presentan evitando con esto las variaciones del proceso. Para esto es necesario basarse en hechos y no dejarse guiar solamente por el sentido común, la experiencia o la audacia. Basarse en estos tres elementos puede ocasionar que al momento de obtener un resultado contrario al esperado nadie quiera asumir responsabilidades.
De allí la importancia de basarse en hechos reales y objetivos, además de que surge la necesidad de aplicar herramientas de solución de problemas adecuadas y de fácil comprensión.
Las herramientas y técnicas cualitativas y no cuantitativas son las siguientes:
1. Recolección de datos.
2. Lluvia/Tormenta de ideas (Brainstorming).
3. Diagrama de Paretto.
4. Diagrama de Ishikawa.
5. Diagrama de flujo.
6. Matriz de relación.
7. Diagrama de comportamiento
8. Diagrama de Gantt.
9. Entrevistas.
10. Listas checables.
11. Presentación de resultados.
La experiencia de los especialistas en la aplicación de estas herramientas señala que bien utilizadas y aplicadas, con la firme idea de estandarizar la solución de problemas, los equipos pueden ser capaces de resolver hasta el 95% de los problemas.
RECOLECCIÓN DE DATOS
CONCEPTO
Es una recolección de datos para reunir y clasificar las informaciones según determinadas categorías de un evento o problema que se desee estudiar. Es importante recalcar que este instrumento se utiliza tanto para la identificación y análisis de problemas como de causas.
USO
Hace fácil la recopilación de datos y su realización de forma que puedan ser usadas fácilmente y ser analizadas automáticamente. Una vez establecido el fenómeno que se requiere estudiar e identificadas las categorías que lo caracterizan, se registran los datos en una hoja indicando sus principales características observables.
Una vez que se ha fijado las razones para recopilar los datos, es importante que se analice las siguientes cuestiones:
· La información es cuantitativa o cualitativa.
· Cómo se recogerán los datos y en que tipo de documentos se hará.
· Cómo se utilizará la información recopilada.
· Cómo se analizará.
· Quién se encargará de recoger los datos.
· Con qué frecuencia se va a analizar.
· Dónde se va a efectuar.
OTROS NOMBRES
· Hoja de recogida de datos
· Hoja de registro
· Verificación
· Chequeo o Cotejo
PROCEDIMIENTO
1. Identificar el elemento de seguimiento
2. Definir el alcance de los datos a recoger.
3. Fijar la periodicidad de los datos a recolectar.
4. Diseñar el formato de la hoja de recogida de datos, de acuerdo a la cantidad de información a escoger, dejando espacio para totalizar los datos, que permita conocer: las fechas de inicio y termino, las probables interrupciones, las personas que recoge la información, la fuente etc.
LLUVIA DE IDEAS
CONCEPTO
Técnica que consiste en dar oportunidad, a todos los miembros de un grupo reunido, de opinar o sugerir sobre un determinado asunto que se estudia, ya sea un problema, un plan de mejoramiento u otra cosa, y así se aprovecha la capacidad creativa de los participantes.
USO
Se pueden tener dos situaciones ante la solución de un problema:
1. Que la solución sea tan evidente que sólo tengamos que dar los pasos necesarios para implementarla, y
2.  Que no tengamos idea de cuáles pueden ser las causas, ni las soluciones.
Es aquí donde la sesión de tormenta de ideas es de gran utilidad. Cuando se requiere preseleccionar las mejores ideas.
OTROS NOMBRES
· Brain Storming
· Tormenta de ideas
PROCEDIMIENTO
1. Nombrar a un moderador del ejercicio.
2. Cada miembro del equipo tiene derecho a emitir una sola idea por cada turno de emisión de ideas.
3. No se deben repetir las ideas.
4. No se critican las ideas.
5. El ejercicio termina cuando ya no existan nuevas ideas.
6. Terminada la recepción de las ideas, se les agrupa y preselecciona conforma a los criterios que predefina el equipo.
DIAGRAMA DE PARETTO
CONCEPTO
Gráfico cuyas barras verticales están ordenadas de mayor a menor importancia, estas barras representan datos específicos correspondientes a un problema determinado, la barra más alta esta del lado izquierdo y la más pequeña, según va disminuyendo de tamaño, se encuentra hacia la derecha.
USO
Ayuda a dirigir mayor atención y esfuerzo a problemas realmente importantes, o bien determina las principales causas que contribuyen a un problema determinado y así convertir las cosas difíciles en sencillas. Este principio es aplicable en cualquier campo, en la investigación y eliminación de causas de un problema, organización de tiempo, de tareas, visualización del antes y después de resuelto un problema, o en todos los casos en que el efecto final sea el resultado de la contribución de varias causas o factores.
PROCEDIMIENTO
1. Decidir qué problemas se van a investigar y cómo recoger los datos.
2. Diseñar una tabla de conteo de datos (totales).
3. Elaborar una tabla de datos.
· Lista de ítems
· Totales individuales
· Totales acumulados
· Composición porcentual
· Porcentajes acumulados
4. Organizar los ítems de mayor a menor.
5. Dibujar dos ejes verticales y uno horizontal  
6. Construir un diagrama de barras.
7. Dibujar la curva acumulada (curva de Pareto).
8. Escribir cualquier información necesaria.
DIAGRAMA DE ISHIKAWA
CONCEPTO
Técnica de análisis de causa y efectos para la solución de problemas, relaciona un efecto con las posibles causas que lo provocan.
USO
Se utiliza para cuando se necesite encontrar las causas raíces de un problema. Simplifica enormemente el análisis y mejora la solución de cada problema, ayuda a visualizarlos mejor y a hacerlos más entendibles, toda vez que agrupa el problema, o situación a analizar y las causas y subcausas que contribuyen a este problema o situación.
OTROS NOMBRES
· Diagrama de espina de pescado
· Diagrama Causa Efecto
PROCEDIMIENTO
1. Ponerse de acuerdo en la definición del efecto o problema
2. Trazar una flecha y escribir el “efecto” del lado derecho
3. Identificar las causas principales a través de flechas secundarias que terminan en la flecha principal
4. Identificar las causas secundarias a través de flechas que terminan en las flechas secundarias, así como las causas terciarias que afectan a las secundarias
CAUSA MAYOR
CAUSA MAYOR
DEFECTO
CAUSA MAYOR
CAUSA MAYOR
5. Asignar la importancia de cada factor
6. Definir los principales conjuntos de probables causas: materiales, equipos, métodos de trabajo, mano de obra, medio ambiente (4 M`s)
7. Marcar los factores importantes que tienen incidencia significativa sobre el problema
8. Registrar cualquier información que pueda ser de utilidad
MATRIZ DE RELACIÓN
CONCEPTO
Gráfico de filas y columnas que permite priorizar alternativas de solución, en función de la ponderación de criterios que afectan a dichas alternativas.
USO
· Cuando se requiere tomar decisiones más objetivas.
· Cuando se requiere tomar decisiones con base a criterios múltiples.
OTROS NOMBRES
· Matriz de priorización
· Matriz de selección
PROCEDIMIENTO
1. Definir las alternativas que van a ser jerarquizadas
2. Definir los criterios de evaluación
3. Definir el peso de cada uno de los criterios
4. Construir la matriz
5. Definir la escala de cada criterio
6. Valorar cada alternativa con cada criterio (usando la escala definida anteriormente)
7. Multiplicar el valor obtenido en el lado izquierdo de las casillas, por el peso de cada criterio y anotarlo a la derecha de cada casilla
8. Sumar todas las casillas del lado derecho y anotar el resultado en la casilla Total
9. Ordenar las alternativas de mayor a menor
DIAGRAMA DE COMPORTAMIENTO
CONCEPTO
Herramienta que permite graficar los puntos del comportamiento de una variable, de acuerdo a como se van obteniendo.
USO
· Para representar visualmente el comportamiento de una variable
· Evaluar el cambio de una proceso en un período
NOMBRES
· Diagrama de Tendencias
PROCEDIMIENTO
1. Decidir qué problema se va a monitorear y cómo se van a recoger los datos
2. Mantener el orden de los datos, tal como fueron recolectados
3. Dibujar un eje vertical y uno horizontal (Eje X Tiempo - Eje Y Medida)
4. Marcar los puntos. Un punto marcado indica ya sea la medición o cantidad observada en un tiempo determinado
5. Unir las líneas de puntos
6. Escribir en el diagrama cualquier información necesaria
DIAGRAMA DE GANTT
CONCEPTO
Gráfico que establece el orden y el lapso en que deben ejecutarse las acciones que constituyen un proyecto.
USO
· Permite vigilar el cumplimiento de un proyecto en el tiempo.
· Permite determinar el avance en un momento dado.
OTROS NOMBRES
· Cronograma de actividades
PROCEDIMIENTO
1. Identificar y listar todas las acciones que se deben realizar para cumplir con un proyecto
2. Determinar la secuencia de ejecución de las acciones
3. Definir los responsables de ejecutar cada acción
4. Escoger la unidad de tiempo adecuada para trazar el diagrama
5. Estimar el tiempo que se requiere para ejecutar cada acción
6. Trasladar la información anterior a las ubicaciones correspondientes en el diagrama
ENTREVISTAS
CONCEPTO
Técnica que permite reunir información directamente con el involucrado en el proceso.
USO
Obtener información de clientes o proveedores de un proceso.
PROCEDIMIENTO
1. Planear la entrevista. Determinar que información se necesita recopilar.
2. Elaborar una guía para la entrevista (introducción, preguntas relacionadas con el tema). Elaborar una prueba piloto.
3. Seleccionar las personas que más conozcan sobre el tema.
4. Programar la entrevista. Planear el tiempo necesario para realizar la entrevista.
5. Ubicar un lugar apropiado para realizar la entrevista sin interrupciones.
6. Invitar al entrevistado, informarle del objetivo, fecha y lugar donde se realizará la entrevista.
7. Realizar la entrevista (sea puntual, cordial y desarrolle la guía para la entrevista, luego resuma y permítale al entrevistado hacer comentarios. Dele las gracias.)
LISTAS CHECABLES
CONCEPTO
Método, lista u hoja de información para lograr que nada se nos olvide ni se omita, en la cual la información consignada es de fácil análisis y verificación. Las podemos encontrar con diferencias sencillas y de tres tipos:
· Guías para la realización secuencial de operaciones, observaciones o verificaciones.
· Tablas o formatos para facilitar la recolección de los datos.
· Dibujos o esquemas para señalar la localización de puntos de interés.
USO
· Muestra una secuencia sistemática de hacer las cosas.
· Facilita la recolección de datos.
· Relaciona pasos o elementos que constituyen el todo de un proyecto o de una preparación.
· Proporciona un medio de seguimiento y control del avance de un proyecto.

 

Copia fiel de Gestiopolis

Métodos de resolución de problemas

Diferentes son las técnicas de resolución de problemas que se pueden utilizar para las tareas que debe realizar un SBC. Existen ciertas técnicas generales que se pueden aplicar a diferentes tipos de dominios y tareas. De ellas destacaremos las tres más utilizadas:

• Clasificación Heurística (Heuristic Classification)
• Resolución Constructiva (Constructive Problem Solving)
• Hipótesis y Prueba Jerárquica (Hierarchical Hipotesize and Test)

Clasificación Heurística

La clasificación es un método utilizado en muchos dominios. El elemento esencial de ésta consiste en que el experto escoge una categoría de un conjunto de soluciones previamente enumerado.

En dominios simples, el disponer de las características esenciales de cada una de las categorías es suficiente para establecer la clase del problema y su solución. Esto no ocurre así cuando la complejidad del problema aumenta, pues las características esenciales son cada vez más difíciles de identificar. El objetivo de la técnica de clasificación heurística será obtener y representar el conocimiento necesario para que la asociación problema-solución se pueda realizar.

Se define como clasificación heurística a toda asociación no jerárquica entre datos y categorías que requiere de inferencias intermedias. Es decir, el establecer la clase de un problema requiere realizar inferencias y transformaciones sobre éste, para poder asociarlo con la descripción de la clase. El esquema de razonamiento para hacer estas inferencias se ha de adquirir del experto.

La clasificación heurística se divide en tres etapas:

1. Abstracción de los datos

Por lo general, se hace una abstracción del caso concreto para acercarlo a las soluciones que se poseen.

2. Asociación heurística

Se busca la mayor coincidencia entre el caso abstraído y las soluciones. Esta asociación es de naturaleza heurística, es decir, depende de conocimiento basado en la experiencia, y, por lo general, la correspondencia entre caso y soluciones no será uno a uno, existirán excepciones, y las coincidencias no serán exactas.

La solución corresponderá con la que mejor coincida con la abstracción de los datos.

3. Refinamiento de la solución

Haber identificado la abstracción de la solución reducirá el espacio de búsqueda, ahora será necesario buscar la mejor solución determinada por la solución abstracta. Esto puede necesitar de más deducciones, o de la utilización de más información. De esta manera se debe reducir el espacio de búsqueda hasta encontrar la mejor solución.

En la siguiente figura se puede ver un esquema del proceso.

Dentro de este proceso, un punto importante es la abstracción de los datos. Tres son las más utilizadas::

Abstracción definicional

Se deben extraer las características definitorias del problema y focalizar la búsqueda con éstas. Le corresponde al experto decidir cuáles son esas características.

Cualitativa

Supone abstraer sobre valores cuantitativos, convirtiéndolos en cualitativos (e.g.: Fiebre = 39 grados ===> Fiebre = alta).

Generalización

Se realiza abstracción sobre una jerarquía de conceptos (e.g.: forma = pentágono ===> forma = polígono).

Se puede ver que esta metodología de resolución de problemas capta una gran cantidad de dominios, siendo adecuada para cualquier problema en el que se pueda hacer una enumeración del espacio de soluciones. Es válida para todas las tareas de análisis.

Clasificación heurística en los sistemas de reglas

Por lo general, la construcción de un sistema mediante clasificación heurística basado en reglas es una labor iterativa. A los expertos les es difícil dar las reglas que son capaces de realizar la labor de clasificación, y además encuentran difícil el formalismo de las reglas.

El proceso de refinamiento del sistema ha de hacerse paso a paso, añadiendo nuevas reglas que cubran nuevos casos y vigilando las interacciones. La metodología que se suele seguir es la siguiente:

1. El experto da las nuevas reglas al IC.
2. El IC cambia la base de conocimiento.
3. El IC prueba casos ya resueltos para comprobar inconsistencias.
4. Si aparecen errores, se comprueba el nuevo conocimiento con el experto y se empieza de nuevo.
5. Se prueban nuevos casos.
6. Si no hay problemas se para, si los hay se retorna al principio.

Esta labor iterativa se puede dividir para cada uno de los módulos que componen el sistema, reduciendo de esta manera las interacciones entre diferentes partes del conocimiento.

Estrategias de adquisición del conocimiento con clasificación heurística

La aplicación de la clasificación heurística a diferentes problemas ha dado con métodos que permiten dirigir la explicitación del conocimiento por parte del experto de una manera más sistemática, enfocando la labor de extracción en cada uno de los elementos que componen las reglas (hipótesis, evidencias, cadenas de inferencia, hechos intermedios, confianza en las evidencias y las asociaciones evidencia-hipótesis). Algunos de los pasos que debe incluir la adquisición son los siguientes:

Diferenciación

Buscar los síntomas que distinguen entre hipótesis.

Frecuencia de condicionalización

Buscar condiciones de base que hagan a una hipótesis más o menos probable.

Distinción de síntomas

Identificar propiedades de síntomas que indican las causas originales.

Condicionalización de síntomas

Buscar las condiciones bajo las cuales se espera que aparezcan ciertos síntomas dada una hipótesis.

División de caminos

Descubrir los sucesos intermedios entre hipótesis y síntomas que son más probables.

Diferenciación de caminos

Buscar los eventos intermedios que pueden diferenciar hipótesis con similares evidencias.

Diferenciación de condiciones

Determinar el grado de confianza a aplicar al resultado de las condiciones.

Condicionalización de condiciones

Buscar las condiciones de base que afectan a la confianza de las condiciones.

La conjunción de todas estas fases permiten construir la base de conocimiento necesaria para la resolución del problema.

Aplicación de la clasificación heurística

Como ejemplo de la técnica de clasificación heurística, vamos a plantear un pequeño SBC para la concesión de créditos bancarios para creación de empresas. El propósito de este sistema será examinar las solicitudes de créditos de clientes con pretensiones de crear una empresa para determinar si se les debe conceder y qué cuantía es la recomendable respecto a la que solicitan.

El problema que se nos plantea tiene por lo tanto una labor de análisis que nos ha de predecir la fiabilidad de si cierta persona, en ciertas condiciones, será capaz de devolver un crédito si se lo concedemos. El número de soluciones a las que podemos llegar es evidentemente finito: el crédito se concede, o no se concede, y en el caso de que se conceda, se decidirá si la cuantía solicitada es adecuada o si sólo se puede llegar hasta cierto límite.

Todas estas características indican que la metodología de resolución que mejor encaja es la clasificación heurística, por lo tanto dirigiremos el planteamiento con las fases que necesita.

Deberemos plantear cuatro tipos de elementos y los mecanismos para transformar unos en otros. El primero será cómo se plantearán los problemas al sistema, es decir, qué elementos se corresponderán con los datos específicos, las solicitudes de crédito.

Esta información ha de definir el estado financiero del solicitante, el motivo por el que pide el crédito, cuánto dinero solicita, etc. Supongamos que una solicitud contiene la siguiente información:

• Si tiene avales bancarios.
• Si tiene familiares que puedan responder por él.
• Si tiene cuentas corrientes, casas, coches, fincas, etc. y su valoración.
• Si tiene antecedentes de morosidad.
• Si ha firmado cheques sin fondos.
• Si tiene créditos anteriores concedidos.
• Tipo de empresa que quiere crear.
• Cantidad de dinero que solicita.

Esta información deberá convertirse mediante el proceso de abstracción de datos en los problemas abstractos a partir de los cuales se hará el razonamiento. Podríamos decidir que nuestras soluciones abstractas quedan definidas por los siguientes atributos:

• Apoyo financiero: Valoración de la capacidad económica para responder al valor del crédito que solicita. Este apoyo se puede evaluar con la información sobre avales y personas allegadas que puedan responder por él.
• Bienes: Dinero o propiedades que puedan usarse para responder por el crédito o que se puedan embargar en caso de no devolución.
• Fiabilidad de devolución: Información sobre si el cliente tiene antecedentes económicos positivos o negativos.
• Compromiso: Información sobre si ya se tienen compromisos económicos con esa persona o si se tienen intereses especiales con ella.
• Viabilidad de la empresa: Tipo de empresa que se quiere crear y su posible futuro.

Supondremos que estos cinco atributos pueden tomar valores cualitativos que estarán dentro de este conjunto: muy bueno, bueno, normal, regular, malo, muy malo.

Para realizar la abstracción de datos se podrían dar un conjunto de reglas que harían la transformación, como por ejemplo:

• si avales > 10 millones o tío rico entonces apoyo financiero bueno
• si avales entre 10 millones y un millón entonces apoyo financiero normal
• si avales < 1 millón entonces apoyo financiero malo
• si suma bienes < 10 millones entonces bienes malo
• si suma bienes entre 10 y 20 millones entonces bienes normal
• si suma bienes > 20 millones entonces bienes bien
• si cheques sin fondos o moroso entonces fiabilidad muy mala
• si fábrica de agujeros entonces viabilidad muy mala
• si hamburguesería o heladería entonces viabilidad normal
• si grandes almacenes o proveedor de Internet entonces viabilidad muy buena
• si concedido crédito < 1 millón entonces compromiso regular
• si concedido crédito > 10 millones o hermano del director entonces compromiso bueno

El conjunto de soluciones abstractas a las que podría dar el análisis de las solicitudes podría ser el siguiente:

• Denegación: no hay crédito para el cliente.
• Aceptación: se acepta el crédito tal como se solicita.
• Aceptación con rebaja: se acepta el crédito, pero se rebaja la cantidad solicitada; harán falta reglas para crear la solución concreta indicando la cantidad final que se concede.
• Aceptación con interés preferente: se concede la cantidad solicitada, pero además se rebajan los intereses que normalmente se ponen al crédito; en este caso también hará falta generar una solución concreta.

Ahora nos faltan las reglas que nos harán la asociación heurística entre los problemas abstractos y las soluciones abstractas. Un conjunto de reglas que cubre una pequeña parte del espacio de soluciones podría ser:

• si apoyo financiero regular y bienes malo entonces denegar
• si fiabilidad mala o muy mala entonces denegar
• si apoyo financiero normal y bienes normal y viabilidad buena entonces aceptar con rebaja
• si apoyo financiero bueno y bienes normal y compromiso normal y viabilidad buena entonces aceptar
• si apoyo financiero bueno y bienes bueno y compromiso muy bueno y viabilidad muy buena entonces aceptar con interés preferente

Por último, nos hacen falta reglas para poder generar soluciones concretas en los casos que son necesarias; algunas reglas podrían ser:

• si aceptación con rebaja y petición > 5 millones y bienes = 5 millones entonces rebaja a 5 millones
• si aceptación con interés preferente y petición > 10 millones y bienes > 10 millones entonces rebaja de un 1% de interés
• si aceptación con interés preferente y hermano del director entonces rebaja de un 2% de interés.....

Resolución Constructiva

En contraste con la clasificación heurística, hay dominios en los que las soluciones no se pueden enumerar a priori, sino que la solución ha de construirse. Por ejemplo, en problemas de diseño, o de planificación, y por lo general, todos los sistemas que incluyen tareas de síntesis.

Este tipo de problemas se pueden atacar mediante métodos no guiados por conocimiento, pero obtener una solución satisfactoria es computacionalmente prohibitivo.

Construir una solución necesita que exista un modelo de la estructura y el comportamiento del objeto que se desea construir, modelo que debe contener conocimiento acerca de las restricciones que se deben satisfacer. Este conocimiento debe incluir:

1. Restricciones en la configuración de los componentes.
2. Restricciones respecto a las entradas y salidas.
3. Interacciones entre estos dos tipos de restricciones.

Dos son las estrategias generales que se siguen para la resolución de este tipo de problemas:

• Proponer y aplicar (Propose and apply).
• Mínimo compromiso (Least commitment).

Proponer y aplicar

En principio, el experto debe tener una idea clara de la descomposición en tareas del problema y de las relaciones espacio-temporales entre éstas, para de esta manera plantear las restricciones que se tienen que cumplir. Se han de definir también las operaciones que se pueden efectuar en cada estado de la resolución, cuándo se pueden aplicar y cuáles son sus efectos. Los pasos que se siguen en esta metodología son los siguientes, para cada tarea a realizar para alcanzar la solución:

• Inicializar el objetivo: se crea el elemento que define el estado actual.
• Proponer un operador: se seleccionan operaciones plausibles sobre el estado actual.
• Podar operadores: se eliminan operadores de acuerdo con criterios globales. Estos criterios globales consistirán en criterios de consistencia generales que permiten descartar operadores que, aún siendo aplicables, se ve claramente que no mejorarán la solución (e.g.: no tiene sentido escoger el operador que deshaga el efecto del último operador aplicado).
• Evaluar operadores: se comparan los efectos de los operadores sobre la solución y se evalúa su resultado. Es en este punto donde interviene el conocimiento del experto para realizar la evaluación de los operadores.
• Seleccionar un operador: se escoge el operador mejor evaluado.
• Aplicar el operador: se aplica el operador al estado actual.
• Evaluar el objetivo: Se comprueba si se ha llegado al objetivo, continuando si se ha cumplido, o reconsiderando si no.

Mínimo compromiso

Un planteamiento alternativo consiste en partir de soluciones parciales e ir reformándolas hasta llegar a la solución. La estrategia sería la siguiente:

• Partir de una solución inicial no óptima, pero que satisfaga las restricciones.
• Hacer una modificación sobre la solución. Esta modificación ha de hacerse de acuerdo con la heurística de mínimo compromiso, es decir, escoger la acción que menos restricciones imponga sobre la solución y, por lo tanto, menos restricciones imponga sobre el próximo paso.
• Si la modificación viola alguna de las restricciones, se intenta deshacer alguno de los pasos anteriores, procurando que las modificaciones sean las mínimas. Esta modificación no tiene por qué ser precisamente deshacer el último paso que se realizó.

El conocimiento del experto ha de aparecer en la evaluación de los efectos de los operadores sobre las restricciones, de manera que se pueda escoger siempre el operador con menos efecto sobre éstas y que permita más libertad de movimientos.

Hipótesis y Prueba Jerárquica

Esta metodología combina aspectos de la clasificación heurística y la resolución constructiva de problemas. Está indicado para problemas en los que:

• El espacio de soluciones es muy grande, pero enumerable.
• La solución puede ser una combinación de un conjunto de hipótesis.

Parte de la idea de que el espacio de soluciones está organizado jerárquicamente, de manera que en niveles más altos se encuentran soluciones más generales, que se deben refinar mediante el conocimiento que guiará a través del árbol de soluciones a soluciones más concretas.

La estructuración en forma jerárquica ayuda a plantear el problema y a focalizar la solución. Será labor del experto el definir la jerarquía y el conocimiento necesario para evaluar el estado de la solución en cada nodo, tanto para descender hacia soluciones más concretas como para descartar ramas.

Copia fiel de Wikipedia

Leer también Ingeniería del conocimiento

Cowboy Agile

Este término, "Cowboy Agile", tiene un origen y esta claramente explicado en Codificación Cowboy, donde se expresa lo siguiente:

"Cowboy Coding is a software development  methodology without an actual defined method – team members do whatever they feel is right."

Básicamente se llama Cowboy Agile a toda aquella organización que toma elementos sueltos de la filosofía Ágile y en forma prácticamente inconsciente comienza a hacer adaptaciones a sus procesos de trabajo para la construcción de software y adopta sin estudio ni análisis, partes de alguno de los modelos (por ejemplo Scrum) y  utiliza su propios criterios según la necesidad de la organización.

Este proceso que la organización consigue a modo de adaptación tiene graves falencias.
Podemos mencionar algunas como la no repetitividad de buenas experiencias, el constante cambio de las herramientas que hacen que también se presente un factor de no adaptabilidad a una tecnología, principalmente en lo que a gestión se refiere, los resultados siguen siendo impredecible, las estimaciones mentirosas por ser generalmente subestimadas y las entregas totalmente fuera de términos establecidos.

Por ende la ruptura de los compromisos es lógica y la carencia de calidad es altamente manifiesta, ya sea por la no existencia de  métricas, la falta de definiciones organizacionales de la calidad, la falta de mejores planes de pruebas o entre otras cosas.

Leí un comentario muy atinado, The Nokia Test, en un blog de gran difusión, lo cual me hace pensar lo cercano que nos encontramos al término Cowboy Ágile en nuestra organización. La pregunta es: ¿cuantos de nosotros somos los John Wyne del Ágile?

Que los discípulos no sean los maestros...

En todas las fases del ciclo de vida de un proyecto SW es necesario tener las habilidades y el conocimiento necesario para ejecutar cada una de las actividades atómicas requeridas por el proceso.

Sin las habilidades básicas no es posible cumplir con los requisitos de completitud para cada componente, ni aún para nuestro propio proceso personal y esto esta fuertemente ligado al concepto de la responsabilidad.

Toma del requisito, Análisis, diseño, codificación, integración, despliegues, verificaciones y validaciones son elementos de vital importancia que requieren de actitudes profesionales maduras y más allá de esos elementos la comunicación formal e informal adhieren a la necesidad de estas actitudes positivas.

Cuando se carece de esos elementos actitudinales y aptitudinales, entramos en una barrena en picada hacia controles desmesurados apuntalados por la desconfianza.

Desconfianza parece ser la palabra establecida, pero confianza es la contra palabra que debe prevalecer. Quizás por que no se puede evitar hablar de una sin la otra, pero esto traído a un marco de trabajo en nuestra industria suele ser una dicotomía dañina, una postura dual que genera el típico clima de desmotivación y desactiva los flujos de comunicación proactiva.

Esta ambigüedad de confianza y desconfianza nos vuelve reactivos y pocos tolerantes y allí mismo nuestros resultados comienzan a declinar su calidad.

En cada fase se hacen seguimientos, nuevas estimaciones, nuevas derivaciones de actividades, se exigen nuevos cumplimientos con los hitos establecidos como líneas bases y se vuelve a controlar sobre el control. Algunos roles están para eso y son necesarios.

Lo que no cabe en este trajín de la gestión, es la desconfianza. No es admisible ni el los líderes, ni en los compañeros y mucho menos en la alta gerencia.

Lo que se debe considerar es que quien no este preparado para el trabajo responsable (considere el significado de la palabra Responsabilidad) es detectado casi instantáneamente y ese podría sería uno de los atributos a favor de esta industria de construcción del software, por lo que cualquier suspicacia puede ser desechada de raíz a la hora de controlar con medidas extremas la productividad del equipo o cualquiera de sus integrantes.

No considero necesario al fisgón detrás de nuestros monitores, ni a los programas de monitorización remota, ni al informante oculto trabajando para alguien en particular. Considero mucho mejor evaluar los resultados generales e indagar sobre aquellas debilidades que saltan a la vista para hacer los ajustes necesarios, tanto en la actitud como en la aptitud, ya que las dos cosas son perfectibles.

Nuevamente en mis escritos salta a la luz la necesidad de la madurez organizacional encabezada por los de más alto rango y que los discípulos no sean los maestros del ejemplo.

Lo que se exige hacia arriba, cuesta brindar desde abajo

Estimados,

Entiendo la situación y como de repente nuestro proyecto en cuestión ya tiene que estar terminado, con testing, moño y con tarjeta navideña. Sin embargo desde antes de ayer a la tarde no logro discernir los pormenores del proyecto. Cosas como fecha de implementación, fechas de inicio de los distintos hitos, iteraciones planificadas en desarrollo, iteraciones del testing, módulos e inclusive asignaciones de actividades a los recursos son totalmente desconocidos por mí.

Desde mi humilde posición al parecer, debo encargarme de restringir, alertar, escudriñar los proyectos, casos de usos, análisis funcionales y el diseño mismo y todo transformarlo en un plan de verificaciones inteligente donde se tengan en cuenta elementos de calidad, al parecer hasta ahora incomprensibles.

¿Para que un plan? ¿Para que son las verificaciones y validaciones? ¿Lo haremos siempre así? ¿Hay cosas que puedo no verificarse según el esfuerzo que conlleve? Si busco el consenso del más fuerte, ¿puedo evitar comprender esto que esta planteado? ¿Para que las especificaciones si no las voy a evolucionar por cambios de requerimientos, nuevas alternativas, extensiones y/o usos del análisis de los requerimientos? ¿En que punto se detiene el perfeccionamiento de las especificaciones?

No importa el nombre del proceso, pero muestro modo de trabajo a algo tiene que parecerse, de allí tomar las mejores prácticas y formar las adaptaciones para poder hacer lo que queremos hacer. Esas adaptaciones pueden implicar nuevas herramientas que generemos nosotros mismos, tal es así que hasta el día de hoy modificamos “N” veces las plantillas para darle mejor formato y agilidad a nuestra toma de conocimientos.

No debemos olvidar uno de los elementos más importantes; La Gestión. ¿Es posible seguir un proceso sin gestión? ¿Es posible iniciar, seguir y finalizar proyectos sin gestión? Si, todo es posible, pero hay que entender cuales son los costos de la “no gestión” y ser contundentes al definir que ese costo es fundamentalmente la “no calidad”. Esto lo digo por que aún en este punto del tiempo, sigo igual que al principio, sin entender los pormenores.

Diseñar y utilizar el marco del proceso es fundamental para darle calce a esta ansiada calidad.

Aún cuando es muy difícil definirla, la calidad es deseada primeramente, analizada en segundo lugar y junto a ese análisis se tiene en cuenta todo el bagaje de falencias que tiene nuestro proceso general y personal. Posteriormente se toman acciones que tienden a formar parte permanente de nuestro proceso (también general y personal) y es permanente pero susceptible de perfeccionarse ciclo a ciclo. ¿Para cuando es esa gestión? Para el día en que organizacionalmente decidamos tener calidad, para hoy mismo, para ayer y mucho antes. ¿Qué o quien nos impide trabajar gestionados?

Hoy es mi intensión hacer notar que esta empresa no esta preparada para la calidad en el concepto taxativo de la palabra, y es así que ya comenzaremos a escribir código (con lo que hay) y a introducir cambios (y lo que hay se queda así) y a hacer testing (de lo que salga).

No considero importante encontrar un solo culpable, principalmente cuando es fácil ver que lo que se exige hacia arriba, cuesta brindar desde abajo.

Lo cierto es que en algún punto muy cercano (antes de antes de ayer) se decidió que la “no calidad” es admisible. Si no es así, sigamos el proceso entonces (ya sé… ¡¡¡es imposible!!!).

Saludos.

Programación en Capas

Arquitectura de Capas
http://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas http://www.ldc.usb.ve/~teruel/ci3715/clases/arqCapas.html

NO DEJAR DE PENSAR!!!!!!!!!!!!!!

Mi experiencia actual me permite razonar de la siguiente manera en pos de mejores prácticas para incrementar la productividad de todo un equipo de construcción SW, a partir de mejoras conceptuales que deben ser entendidas a nivel organizacional, con un fuerte apoyo directivo y con pasos concretos y discretos que determinen la concreción de las metas.

Recortar el proceso tanto como sea posible, dejando los elementos que son absolutamente necesarios e ir, en forma incremental y a conciencia ingresando nuevos elementos dentro del proceso.

Minimizar los procesos pero que cada integrante del equipo conozca al dedillo cuales son las actividades que le corresponden.

Entrar en un nivel de conciencia primero y luego generar workflows a los que nos adaptamos rápido y en forma normal.

Estandarizar la forma de trabajar, ser homogéneos y tener el mismo lenguaje comunicativo.

Mejorar la capacidad de visionar el caos, evitando que lo que proponemos se nos vuelva en contra. Esto sin duda implica qeu los análisis de los nuevos requerimientos ingresados por los clientes deben ser inmediatos a niveles funcionales, evitando que se generen desplazamientos siendo que los podemos anticipar con análisis.

Conocer a nivel macro todo lo que se necesita para la generación de los producto y luego tomar las vistas micro.

Eliminar todos los defectos antes de la entrega del producto, incrementando el nivel del Testeo de Unidad y de integración previo a cualquier testeo funcional aplicando todo lo referente a la mejora contínua de la calidad.

Informar los defectos conocidos y guiar al usuario para evitarlos, hasta su próxima corrección mediante una generación de Nota de Release realista.

Alcanzar los cierres en fecha pactada.

Apoyar los resultados de cada actividad con la experiencia individual y en forma organizada, para crecer y poder encarar proyectos más grandes y ambiciosos.

Tener en cuenta que disminuir la cantidad de horas para cada actividad implica mayor beneficio. Aumentar la complejidad podría disminuir el beneficio.

Proponer elementos concretos para conseguir la mejora si hacemos cambios en torno a como ejecutar los proyectos.

RITMO, COMUNICACIÓN Y PERFECCIONAMIENTO DE LAS COSAS.

NO DEJAR DE PENSAR!!!!!!!!!!!!!!

Re: ¿Cómo implantar las mejores prácticas de calidad?

Este es un simpático pero importante aporte que hizo uno de mis buenos aportantes en los post que suelo hacer en la Comunidad Nuerona y que luego de un año de intentos con aciertos y desaciertos, valoro más que nunca.

Cabe aclarar que se trata de una respuesta a mi post ¿Cómo implantar las mejores prácticas de calidad?

He leído con interés tus correos de este asunto, después de varias semanas ausente por sobrecarga de trabajo.

La respuesta a tu pregunta es:
ES POSIBLE. Aunque tenga algunas condiciones.

En primer lugar es muy deseable que haya apoyo de la dirección, aunque no es completamente necesario.
En algunos mercados la inversión en calidad se ve como un lujo, que solo genera costes; en otros, se considera que debe darse por defecto y que el buen hacer profesional ya debe ser suficiente. Es prácticamente imposible que un abogado, por ejemplo, llegue a comprender nada de lo que necesitas. En realidad es prácticamente imposible que llegue a comprender cualquier asunto técnico o de gestión.

Primera conclusión: NO PIERDAS EL TIEMPO buscando apoyos donde nunca los vas a tener.
Los equipos técnicos, que si comprenden el problema son tu mejor aliado. Ninguna dirección de ninguna empresa se enfrentará jamás a un equipo técnico cohesionado y motivado. Busca apoyos en los técnicos y gestores técnicos, y todo ira bien.

Los estándares de Calidad, hoy en día, son una jungla en la que es fácil perderse. Todos los organismos, instituciones, universidades e incluso países, tienen el mejor modelo para.......

Debes centrar el tiro en la mejora inmediata, aunque pequeña inicialmente, con resultados para mañana mismo sin coste aparente. Es lo que yo denomino (y no lo he visto escrito en ningún sitio), "Calidad Ejecutiva".
Se trata de acomodar lo mejor de algún modelo teórico de renombre, CMM, CMMI o ISO 15504 en nuestro día a día, y aplicarlo de verdad.

Conozco muchas empresas que tienen las paredes forradas de certificados de calidad de todo pelaje y condición y, no cumplen ninguno de ellos nunca.

Mi propuesta es justo la contraria. Elige un buen modelo (ISO 15504 estaría bien) y trata de ponerlo en marcha con los recursos internos de y que dispones y al mínimo coste posible. Hay que arar con lo que hay.

A todos nos encantaría arar con un tractor último modelo, pero si no hay y es necesario, se ara incluso con el pie. Eso si, tienes que hacer ver que con el pie se ara poco y torcido, comparado con el tractor. Al abogado, en general, le importará muy poco el como ares y el comercial le dirá a los clientes lo bueno que es el tractor que no tienes. Cuenta con ambas cosas.

Empieza por lo pequeño, lo inmediato y lo que puedas hacer con los recursos que tienes, aunque en la carta a los Reyes Magos, pidas un Nivel 3 CMMI.

¿Cómo generar capacidades que permitan implantar las mejores prácticas de un proceso de calidad de construcción de SW?

la implementación de prácticas SQA requiere como mínimo del reconocimiento de su importancia dentro del proceso de desarrollo del software, de conocer las necesidades reales de la compania en relación con estas prácticas y la formulación de un plan de acción. Sin embargo todo esto se dificulta el grado extremo si la organización no designa un responsable de este proceso y le asigna recursos adecuados.
La realidad es que muchas empresas asignan a un responsable de desarrollo que entre otras responsabilidades debe asumir el proceso de implantación y que generalmente no es experto en el tema. Ello determina que en muchas oportunidades el esfuerzo dedicado a la tarea se vea disminuido significativamente, a lo que se le suma la presión por obtener resultados tempranamente. Si estos resultados no son visibles, generalmente se abandona la iniciativa o se posterga por otras prioridades de corto plazo. Luego, resulta urgente apoyar la labor de este profesional.
Para asumir la implantación de este plan de acción, el profesional requiere de basicamente de información sobre las prácticas, subprácticas, actividades, tareas, procesos, procedimientos, herramientas y recursos necesarios para implementar cada práctica de SQA.
Esta información debe ser prevista de forma tal que sea lo suficientemente completa, genérica y breve como para que el responsable en poco tiempo pueda definir y establecer para cada práctica que se desea implantar, los procesos, actividades y los recursos adecuados para su organización.

Este mismo post esta vigente en Comunidad Neurona

La Importancia de una participación SQA temprana en la especificación del proyecto

Mi participación temprana como Responsable de Calidad en los proyectos, me brinda una notable mejora en la visibilidad de los aspectos de control a niveles de verificaciones y validaciones que debo considerar para cada proyecto en particular.

A diferencia de la participación en etapas medias y/o avanzadas que tuve en otros modelos de trabajo para la construcción SW, esta modalidad de participación temprana me permitió ingresar preguntas claves para la formación de los requerimientos, los modelos de analisis y diseño e inclusive para los riesgo técnicos y tecnológicos, entre otros, a considerarse por las planificaciones y presupuestaciones.

Modelos de "participación tardía" brindaron siempre grandes márgenes de incertidumbre donde mis limitaciones eran de variada magnitud según el tiempo que se me asignaba, el entendimiento que lograba en base a la documentación existente o a la capacidad de traspaso de la información vital para hacer QA, entre otras limitantes.
Por el contrario esta forma de involucramiento en fases inciales de los proyectos, me permitieron anticipar al equipo en general, los requisitos de calidad mínima a ser medidos y por ende a ser tenidos en cuentas en todas las fases del ciclo de vida de los distintos productos.

Muchas veces desde el desconocimiento y tantas otras con criterios acertados y a conciencia, desperté inquietudes para el análisis de los requisitos y empujé a pensar en los modelos arquitectónicos que "de movida" se orientan fuertemente a distintos aspectos de la solución técnica.

También es grato ir descubruiendo las sutilezas del desarrollo, las visiones de los planificadores, las espectativas de la gerencia, los berrinches de los clientes y asumir en carne propia y en sangre propia, que el producto debe tener tal o cual calidad y de ese modo despertar las distintas posibilidades a niveles de herramientas, recursos humanos y ténicas de verificación y validación.

La participación temprana de un Responsable QA asignado al proyecto, sin duda alguna promueve la elevación de los estándares de calidad en todas las fases del ciclo de vida de un proyecto SW. Lo interesante de todo este concepto es que a partir de ese momento los lineamientos de calidad son conocidos por todos por que fueron expresados en una reunión en forma fluida, sin tener que se expuestos de modo documentacional y de esta manera son mejor aceptados los "rigores SQA" por son insertados linguisticamente y por consenso general.

Con esto no pretendo decir que estamos en condiciones de despreciar la documentación formal asociada a la calidad, ni los distintos hilos comunicacionales que usualmente son definidos para cada proceso de construcción SW. Solo digo que muchos criterios son traspasados en una charla donde participamos personas de distintas áreas transversales.

Ni siquiera es necesario que el QA sea moderador, sino solo un partícipe más. Esa participación tiene que tener riqueza extrema o se pierde la oportunidad de iniciarse un proyecto rico, con resultados positivos en el balance general.