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.