Archivos para 15 marzo 2008

Definimos Pruebas de Unidad como…

Todas las modernas arquitecturas de software incorporan la modularidad como uno de sus elementos esenciales. Así tenemos la posibilidad de tener a distintos programadores trabajando en distintos módulos sin que esto signifique un problema. De la mismo forma es posible imaginar a nuestros programadores ejecutando pruebas locales sobre sus módulos, a fin de tener una comprobación del buen funcionamiento -autónomo- de lo que han estado programando.

A esta forma de prueba se le llama Pruebas de Unidad o también Prueba Unitaria. Entendiendo formalmente por esto -como para el glosario- lo siguiente:

Prueba de Unidad. Nombre que reciben los procedimientos de pruebas locales a un módulo del sistema. Por definición dichas pruebas cubren la funcionalidad propia del módulo tanto con una perspectiva de caja blanca como de caja negra; pero prestando poca o ninguna atención a la integración con otros módulos.

Esto es, nuestras pruebas de unidad son estrictamente locales, dejando el trabajo de probar la correcta interacción entre módulos a las Pruebas de Integración. Este enfoque localista, permite desarrollar pruebas de Caja Blanca exhaustivas a cada módulo de manera de descentralizar la operación y diseño de estas a los desarrolladores responsables del módulo en cuestión.

Finalmente es de observar la relación que guardan las Pruebas de Unidad con las Pruebas de Regresión. Siempre y cuando podamos contar con pruebas automáticas, vamos a poder construir nuestros conjuntos de pruebas de regresión a partir de lo pensado en las pruebas de unidad.

Nos estamos viendo.

Anuncios

, , ,

Deja un comentario

Definimos Pruebas de Humo como…

Imaginemos por un momento que estamos ante una construcción antigua. Quizás una gran casa de principios del siglo pasado, con docenas de cuartos y muchas pero muchas goteras en sus tuberías. A la hora de reparar estas goteras, lo primero que debemos hacer es determinar los puntos de fuga que es donde se escapa el liquido. Pero, ya que tenemos muchos muebles antiguos en la casa, no nos conviene dejar pasar agua por los tubos, ya que las gotas de agua nos pueden arruinar las paredes, cuadros y muebles.

Una alternativa ingeniosa, aplicada según parece por los plomeros antiguos, es dejar pasar humo en lugar de agua por las tuberías. El humo, al igual que el agua, se escapa por los puntos de fuga, pero a diferencia de esta, no hace daño en la decoración ni el mobiliario.

Esta forma de probar en busca de goteras es conocida como Prueba de Humo y es una forma efectiva y rápida de probar un amplio rango de posibles puntos de falla. Tomando esta idea, es posible imaginarnos pruebas sobre los sistemas de software que estemos desarrollando que compartan estas cualidades de amplitud y rapidez, aún en el caso en que no sean exhaustivas.

Entonces podemos definir -ahora para la ingeniería del software- lo que es una prueba de humo:

Prueba de Humo. Es un procedimiento de prueba diseñado para cubrir una amplia porción de la funcionalidad del sistema. Las pruebas así diseñadas dan prioridad al porcentaje del total del sistema que se pone a prueba, sacrificando de ser necesario la finura de estas.

Las pruebas de humo son útiles a la hora de determinar si un sistema va cumpliendo lo requerido, así como para verificar una vez ya en producción, que luego de una instalación nueva o de la recuperación de una falla catastrófica el sistema se ha devuelto a su pleno funcionamiento.

Nos estamos viendo.

, , ,

2 comentarios

Control de Calidad: Revisión por pares

Dado que el modelo de calidad generalmente aplicado al software es de naturaleza cualitativa, nunca se va a estar objetivamente seguros de haber alcanzado la plena coincidencia entre los requisitos y lo creado, es decir, la calidad. De hecho, la naturaleza subjetiva del proceso de calidad del software es tan inherente a él, que la única sugerencia sistemática sobre como lograr esta comprobación es la llamada Revisión por pares.

La idea de la Revisión por pares es permitir que otros profesionales reconocidos, diferentes a los que han creado el sistema, juzguen y den su opinión sobre el diseño u otros aspectos del mismo. De este modo se puede obtener un nivel de verificación -subjetiva- al menos independiente del juicio del autor original; de manera de tener la posibilidad de asegurar al cliente, que lo que se ha hecho es reconociblemente adecuado para lo que nos ha pedido.

Naturalmente que una organización debe contar con al menos un tamaño mínimo para aplicar la Revisión por pares. No es valido que quien diseñe sea al mismo tiempo quien revise. Sin embargo no es necesario que esa un consultor externo al desarrollador. Se puede confiar sin problemas en la profesionalidad de los revisores.

Como en toda auditoria -y la revisión es una- el enfoque es encontrar defectos, no para señalar errores de los autores, sino para identificar oportunidades de mejorar. Nos conviene recordar esto, ya que algunos egos se pueden ver heridos durante una revisión rigurosa del diseño; y no es este el efecto que se busca. La idea es incorporar los beneficios de la critica constructiva y no la de señalar errores personales.

La mecánica de este proceso de revisión ha de consumir algunos días, ya que se deben enviar los diseños a evaluación, dando suficiente tiempo como para que sean analizados correctamente. Luego, en reunión con el equipo de diseño, los revisores pueden emitir sus opiniones y observaciones, dando la oportunidad de hablar sobre estas ideas entre todos los interesados. Además, espero sea obvio, solo es posible aplicar la revisión por pares en aquellos proyectos que estén correcta y suficientemente documentados.

El siguiente diagrama ilustra los detalles de la actividad:

Revisión por pares

Fig. 1 – Diagrama SPEM de la Actividad Revisión por Pares

En este diagrama se deja ver que quien revisa (Software Quality Control en la imagen) realiza sugerencias y emite objeciones sobre los artefactos puestos a revisión; comentarios estos que son expuestos al trabajador del proyecto relacionado con los mismos. Opcionalmente se puede informar al cliente y naturalmente, es posible emitir un informe con todo lo realizado.

, , , , , , , , , ,

6 comentarios

La pareja del Análisis

Si hacemos una pequeña encuesta, veremos que mucha gente asocia parejas de palabras como en una relación izquierda/derecha, de manera que no comprende la una sin la otra. Esto le ocurre a la palabra análisis que hace pareja, en el imaginario popular, con síntesis.

Nosotros trabajamos en la industria del software, por lo que no asociamos la síntesis como la compañera del análisis. En su lugar, ponemos a diseño, una elección que puede llevar a más de uno a confundir el diseño con alguna actividad de síntesis.

Para evitar estos peligros, veremos qué entendemos por cada una de estas palabras, en un estilo digno del glosario.

Análisis. Actividad mental de ver al todo como una colección de partes.

Síntesis. Actividad mental de poner en un todo lo que se ha visto por separado.

Diseño. Actividad mental de disponer las cosas para que al desarrollarse, se alcance la situación deseada.

Espero quede claro, que la síntesis consiste en ver desde las partes, la posibilidad de un todo; en tanto que el diseño es la disposición de estructuras temporales que son necesarias para que un algo se desarrolle según nuestros deseos.

No niego que alguien pueda ver alguna relación entre síntesis y diseño, pero espero que quede claro que al menos, son cosas diferentes. La síntesis pone juntas las partes, en tanto que el diseño manipula las partes con una intención posterior.

Nos estamos viendo.

Deja un comentario

Análisis Orientado a Objectos: Análisis Gramatical

Dije antes, que el Análisis[1] pone a descubierto las partes de un todo; sin embargo no dí sugerencia alguna sobre la naturaleza de estas partes. Esta falta es intencional. Según el tipo de análisis que se este realizando, el todo se va a ver descompuesto en partes y relaciones, objetos y mensajes, ladrillos y cemento, o cualquier otra estructura imaginable.

Una de las formas más populares de software durante finales del siglo XX, fueron los llamados programas Orientados a Objeto, y encontramos multitud de herramientas de programación que incluyen el epíteto de orientado a objetos. Así entonces, podemos hablar de un Análisis Orientado a Objetos, donde el todo se ve formado como una relación de clases, objetos y mensajes.

El reto entonces, es encontrar una forma practica, de ver clases en nuestros proyectos, de manera de pasar pronto, de la visión[2] a un diagrama que muestre la propuesta inicial de la arquitectura.

La sugerencia más simple que conozco es el llamado Análisis Gramatical, el cual conduce el análisis con ayuda de las estructuras gramaticales que están presentes en todas las frases y oraciones que describen el problema.

El método se puede delinear en los siguientes pasos:

  1. Crear un cuerpo de documentos que declaran lo que se sabe del proyecto. El Documento de Visión y la Especificación de Requisitos del Sistema son buenos candidatos.
  2. Generar una lista de sustantivos clave, los más representativos, que hayan sido utilizados en los documentos del sistema. A esta lista la vamos a filtrar una y otra vez, a fin de eliminar las redundancias y encontrar buenas clases candidatas.
  3. Identificar los adjetivos que se utilizan a la par de nuestros sustantivos. Estos adjetivos describen posibles atributos de nuestras clases.
  4. Identificar los verbos que se utilizan en conjunto con nuestros sustantivos. Estos verbos describen posibles métodos de nuestras clases.
  5. Organizar todo en un diagrama de clases, de manera de imponer una red de relaciones, agregaciones y composiciones, que den forma inicial al sistema.

Ha de observarse aquí, que la técnica descrita es sin duda simple. De hecho es tan cercana a los análisis que se hacen sobre temas nuevos, que bien podríamos acordar en llamar primitiva a esta técnica. No por mala, sino por ser de las primeras en que uno pensaría aplicar.

Finalmente hemos de observar, que ya había comentado sobre esto, en el artículo sobre el Glosario del Sistema[3] el cual bien puede ser una pieza clave en el Análisis Gramatical.

2 comentarios

Definimos Modelo de Calidad como…

Anteriormente[1] vimos que la calidad puede incluir la satisfacción de necesidades no declaradas por los clientes. Seguramente en un ramo o sector comercial, todos los clientes van a compartir muchas de estas necesidades; por lo que es posible ir formando un cuerpo de características requeridas; lo cual en otras palabras, no es más que un modelo de calidad común al sector.

Modelo de Calidad. Hace referencia a la descripción general de las características o necesidades que son comunes a un sector productivo, de forma de lograr la calidad de los productos en términos uniformes.

La ventaja de contar con un Modelo de Calidad definido es que este nos guía durante el proceso de captura de requisitos. Simplemente nos dice qué preguntar y ya esto es una importante ayuda.

Según el sector donde nos encontremos, es posible que un Modelo de Calidad incluya mediciones, que validen que el producto cumple con lo especificado. Sin embargo es difícil sino imposible, hacer mediciones de ese estilo con el software. Por eso en esta industria se utiliza un modelo cualitativo de calidad[2], que incluye aspectos de usabilidad, extensibilidad y otros.

Lo importante con lo que nos debemos quedar, es que los aspectos de usabilidad y otros, no son la calidad en si del producto software. Simplemente es que la experiencia nos dice que ese es un aspecto a atacar. Lo mismo lo podemos decir de las otras famosas cualidad de un software de calidad… pero lo haremos en su momento.

Por hoy estamos bien con lo dicho hasta aquí.

2 comentarios

Definimos Calidad como…

Cada organización persigue la calidad. Tanto en sus productos como en sus procesos. Cada profesional se enorgullece de hacer un trabajo de calidad. Los clientes siempre se decantan por los proveedores de mayor calidad… Calidad, calidad, calidad. Sí ok, ¿pero que es calidad?

Calidad. Es la coincidencia entre las características objetivamente presentes en lo trabajado y las que se requirieron por el cliente.

Es posible hablar de la calidad de un trabajo ya que el cliente puede requerir que dicho trabajo cumpla con ciertas condiciones de tiempo y costo. Es posible también hablar de la calidad en los productos, por la misma razón. Entonces calidad no es más que satisfacer al cliente, tanto en lo que nos ha pedido, como en lo que necesita.

Con todo, cada organización debe asumir una forma personal de definir calidad ya que la naturaleza de sus servicios y productos lo demanda. Además, ya que puede ocurrir que un cliente requiera de ciertas características pero no estar consciente de esto, es necesario entonces que nuestra definición de calidad incluya cierta experiencia sobre como lograr el nivel de satisfacción requerido incluso en el caso de no haber sido solicitado por el cliente en palabras claras.

Nos estamos viendo.

5 comentarios